Hi,
I was trying to setup a local BrutaLinks instance on my desktop for
testing, and I was getting all sorts of weird issues.
As it turns out, these issues occurred since the ENV environment
variable was set in my .profile, overwriting the value in .env.
This seems like a bad name for that variable IMO, since AFAICT it has
nothing to do with the original use of the ENV variable.
Other than that the process was extremely easy BTW, way easier than any
other web service I ever tried setting up. Of course, this was just a
local instance for experimentation, so I don't know what issues might
arise when actually deploying it, but still - I see great potential in
selfhosting this in the future, when compared to stuff like Lemmy or Kbin.
Daniel
On 23-07-04 23:20:42, Daniel Semyonov wrote:
> Hi,
Hi Daniel, thank you for your interest in BrutaLinks. :)
> As it turns out, these issues occurred since the ENV environment> variable was set in my .profile, overwriting the value in .env.> This seems like a bad name for that variable IMO, since AFAICT it has> nothing to do with the original use of the ENV variable.
True, however both project support prefixes to the variable names -
which I guess I haven't documented anywhere. The current preffix that
you can use is "BRUTAL_" for BrutaLinks and "FEDBOX_" for FedBOX,
so for the ENV variable you can use "BRUTAL_ENV" and "FEDBOX_ENV".
If you feel like contributing to the project I would appreciate a
patch for adding this information about the prefixes in the
documentation or, in the .env.dist file.
> Other than that the process was extremely easy BTW, way easier than any> other web service I ever tried setting up.
Thank you, this means a lot, I spent a lot of time thinking about how to
keep the installation as simple as possible. I feel like in some
respects I failed (there isn't - yet - a way to deploy BrutaLinks with
FedBOX and the Webfinger server bundled together) but I'd like to have
that at some point. The best I can provide at the moment is this repo[1]
based on some older community help.
> I see great potential in> selfhosting this in the future, when compared to stuff like Lemmy or Kbin.
Thank you for the kind words. :)
You need to keep in mind that currently FedBOX and BrutaLinks do not
play nice with Mastodon. However a federation of BrutaLinks servers
should be fine. (Let me know if you set up a public server, even if it's
a test one.)
Cheers,
/Marius
[1] https://git.sr.ht/~mariusor/brutalinks-dockerized
>>>>> Marius Orcsik writes:
> On 23-07-04 23:20:42, Daniel Semyonov wrote:
>> As it turns out, these issues occurred since the ENV environment
>> variable was set in my .profile, overwriting the value in .env.
>> This seems like a bad name for that variable IMO, since AFAICT it
>> has nothing to do with the original use of the ENV variable.
> True, however both project support prefixes to the variable names
> - which I guess I haven't documented anywhere. The current preffix
> that you can use is "BRUTAL_" for BrutaLinks and "FEDBOX_" for
> FedBOX, so for the ENV variable you can use "BRUTAL_ENV" and
> "FEDBOX_ENV".
That's good to know, thanks.
> If you feel like contributing to the project I would appreciate a
> patch for adding this information about the prefixes in the
> documentation or, in the .env.dist file.
I'll do this when I have the time (if I don't forget), I actually found
quite a few small mistakes in the docs which I don't mind fixing.
I've also been interested in learning Go for a while, so I might take a
stab at actual development too at some point.
> You need to keep in mind that currently FedBOX and BrutaLinks do
> not play nice with Mastodon.
I'm guessing the same is true for Lemmy/Kbin?
I should really read up on ActivityPub, I had assumed this kinda stuff
is basically automatic once you have a working implementation - though I
guess it doesn't really make sense when you consider the widely
different types and formats of data available through different
ActivityPub services.
> However a federation of BrutaLinks servers should be fine. (Let me
> know if you set up a public server, even if it's a test one.)
It probably won't be anytime soon, but I'll be sure to let you know.
> Cheers, /Marius
Thanks,
Daniel