[bug] Guide suggests installing frontend via source without sudo command

shadowjonathan commented

2024-04-19 08:40:58 +00:00

At the end of the current install guide, under frontend installs, via source, the guide is currently missing sudo -Hu akkoma before the mix commands.

Have you searched for this issue?

I have double-checked and have not found this issue mentioned anywhere.

At the end of the [current install guide](https://docs.akkoma.dev/stable/installation/debian_based_en/), under frontend installs, via source, the guide is currently missing `sudo -Hu akkoma` before the mix commands. ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.

shadowjonathan added the

bug

label 2024-04-19 08:40:58 +00:00

floatingghost commented

2024-04-19 08:49:17 +00:00

Owner

not an issue, these commands are common between install guides and some do not use sudo (Alpine uses doas)

floatingghost closed this issue

2024-04-19 08:49:17 +00:00

shadowjonathan commented

2024-04-19 08:57:57 +00:00

Author

it is an issue, as it installs the frontend under root, and chokes when the current directory is not /opt/akkoma

the rest of the install guide never mentions that the user needs to change their directory to /opt/akkoma, the sudo -H option does that implicitly

why break consistency now?

it is an issue, as it installs the frontend under `root`, and chokes when the current directory is not `/opt/akkoma` the rest of the install guide never mentions that the user needs to change their directory to `/opt/akkoma`, the `sudo` `-H` option does that implicitly why break consistency now?

shadowjonathan reopened this issue

2024-04-19 08:57:59 +00:00

floatingghost commented

2024-04-19 09:00:23 +00:00

Owner

as i say, these commands are not unique to this guide

they are shared across all guides - changing them here will break the alpine guide

which i think is rather worse than having a little inconsistency that any user that has any right to be hosting a fedi instance should be able to easily understand

as i say, these commands are _not unique to this guide_ they are shared across all guides - changing them here will break the alpine guide which i think is rather worse than having a little inconsistency that any user that has any right to be hosting a fedi instance should be able to easily understand

shadowjonathan commented

2024-04-19 09:02:49 +00:00

Author

why are the same commands linked across all of the guide variants like that? i can understand not wanting to break the commands themselves, but going out of the way to card consistency over platform quirks will not work here

at least add a cd /opt/akkoma command in front of it, even if it then installs it under root, it should then work

with the way it does, it guides the user to veer their car straight into a tree, off the road, which is an incredibly frustrating experience (as i have a friend who just did that, and got caught multiple times on the install guide telling them to do something that messed up their install, or just didnt work)

why are the same commands linked across all of the guide variants like that? i can understand not wanting to break the commands themselves, but going out of the way to card consistency over platform quirks will not work here at least add a `cd /opt/akkoma` command in front of it, even if it then installs it under root, it should then work with the way it does, it guides the user to veer their car straight into a tree, off the road, which is an incredibly frustrating experience (as i have a friend who just did that, and got caught multiple times on the install guide telling them to do something that messed up their install, or just didnt work)

floatingghost commented

2024-04-19 09:04:20 +00:00

Owner

because, quite honestly, it's already a massive pain to keep documentation up to date

keeping documentation up-to-date across multiple very slight variants is even more work taking up even more time that i have vanishingly little of

what i'm saying is, i'm waiting patiently for your contribution

because, quite honestly, it's already a massive pain to keep documentation up to date keeping documentation up-to-date across multiple very slight variants is even more work taking up even more time that i have vanishingly little of what i'm saying is, i'm waiting patiently for your contribution

shadowjonathan commented

2024-04-19 09:07:50 +00:00

Author

i'm at least noting the issue down, since i haven't seen it mentioned anywhere else

i'll poke some PRs once i have the energy to, but yeah

i'm at least noting the issue down, since i haven't seen it mentioned anywhere else i'll poke some PRs once i have the energy to, but yeah

Oneric commented

2024-04-19 15:36:36 +00:00

Member

Would it be fine to just note how to run commands as root, akkoma and postgres once upfront and then e.g. prefix each command with root#, akkoma$ etc? This would allow duplicating even more stuff.
Or will this be too confusing and end up with people copying the prefix into the terminal as well?

(Also, Debian ships doas and Alpine ships sudo. Likely most distro offer both and only their default/recommended choice differs, meaning either variant may appear on any system. In practice though i’m guessing 90+% just use the default and those who don’t will know how to adapt things)

keeping documentation up-to-date across multiple very slight variants

It seems there’s (if the above suggestion or something similar works) even more parts we can dedupe. At first glance:

“Install AkkomaBE” appears to be identical across variants except for doas/sudo and the initial 3 user/group setup commands
Maybe we can move those three to “Prepare the system”?
“Finalize installation”
- except for doas/sudo the only difference across Linux systems appears to be:
  - installing nginx + certbot (move this to “Prepare the system?”)
  - registering a system service with systemd or openrc
  We could either include all other parts individually in each guide, or if we move the install part out of it maybe even fully share this section with a variant selector for system service like we do for OTP vs Docker vs Source later for frontends?
- *BSDs have a couple more differences due to /usr/locale/paths, different init systems each, etc; they might need to remain separate

Having pre-existing knowledge of what needs to happen works against me here in judging what’s the right level of verbosity and (de)duplication. If you could send patches to improve things it would be really great

Would it be fine to just note how to run commands as root, akkoma and postgres once upfront and then e.g. prefix each command with `root#`, `akkoma$` etc? This would allow duplicating even more stuff. Or will this be too confusing and end up with people copying the prefix into the terminal as well? *(Also, Debian ships `doas` and Alpine ships `sudo`. Likely most distro offer both and only their default/recommended choice differs, meaning either variant may appear on any system. In practice though i’m guessing 90+% just use the default and those who don’t will know how to adapt things)* > keeping documentation up-to-date across multiple very slight variants It seems there’s (if the above suggestion or something similar works) even more parts we can dedupe. At first glance: - **“Install AkkomaBE”** appears to be identical across variants except for `doas`/`sudo` and the initial 3 user/group setup commands Maybe we can move those three to “Prepare the system”? - **“Finalize installation”** - except for `doas`/`sudo` the only difference across Linux systems appears to be: - installing nginx + certbot *(move this to “Prepare the system?”)* - registering a system service with `systemd` or `openrc` We could either include all other parts individually in each guide, or if we move the install part out of it maybe even fully share this section with a variant selector for system service like we do for OTP vs Docker vs Source later for frontends? - *BSDs have a couple more differences due to `/usr/locale/`paths, different init systems each, etc; they might need to remain separate Having pre-existing knowledge of what needs to happen works against me here in judging what’s the right level of verbosity and (de)duplication. If you could send patches to improve things it would be really great

[bug] Guide suggests installing frontend via source without sudo command #748

Have you searched for this issue?