Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Document using doas instead of sudo for Alpine Installation method #16391

Open
JacksonChen666 opened this issue Sep 27, 2023 · 3 comments
Open
Labels
A-Docs things relating to the documentation A-Packaging Our Debian packages, docker images; or issues relevant to downstream packagers O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Tolerable Minor significance, cosmetic issues, low or no impact to users. T-Task Refactoring, removal, replacement, enabling or disabling functionality, other engineering tasks.

Comments

@JacksonChen666
Copy link

sudo apk add synapse

sudo must be explicitly installed by the user (or through a dependency), so it will not be available. Alpine Linux actually uses doas instead of sudo.

doas is part of the main repository, and sudo is only part of the community package. (See Repositories for difference between main and community repo)

doas is installed when necessary (unprivileged user setup during setup-alpine), sudo is only installed either explicitly by the user or indirectly through a package that depends on it (2 of them), so sudo will not be available and will cause problems if the command is copied as is.

I'd suggest changing sudo to doas for the Alpine Linux install.

Also, the community repository needs to be enabled explicitly too, which isn't part of the instruction.

@DMRobertson DMRobertson added A-Packaging Our Debian packages, docker images; or issues relevant to downstream packagers A-Docs things relating to the documentation labels Sep 27, 2023
@clokep clokep added S-Tolerable Minor significance, cosmetic issues, low or no impact to users. T-Task Refactoring, removal, replacement, enabling or disabling functionality, other engineering tasks. O-Uncommon Most users are unlikely to come across this or unexpected workflow labels Sep 27, 2023
@sosnik
Copy link

sosnik commented Sep 30, 2023

sudo must be explicitly installed by the user

This is not unique to Alpine. For instance, sudo must be installed explicitly in Arch as well. This is not something that needs documentation. I hate to sound elitist but if someone needs documentation for how to install sudo, they should not be hosting a public-facing server with all the security considerations such entails.

Also, the community repository needs to be enabled explicitly too, which isn't part of the instruction.

I do not recall needing to do that on my Alpine VM. This is root's history:

1 apk update
1 apk upgrade
3 apk add sudo
4 adduser -G wheel nikita
5 passwd nikita
6 echo -e "[user]\ndefault=nikita" >> /etc/wsl.conf
7 exit

As you can see, I did nothing to enable the community repo — unless it came pre-enabled on the rootfs I used to create this VM.


In general, I am fond of using the proper prompt indicator ($/#) to indicate which commands should be run with elevated privileges and leave it up to the user to figure out how to achieve it.

@JacksonChen666
Copy link
Author

sudo must be explicitly installed by the user

This is not unique to Alpine. For instance, sudo must be installed explicitly in Arch as well. This is not something that needs documentation.

Alpine Linux does not officially support sudo (i.e. not part of the main repository).

I also wrote this:

doas is installed when necessary (unprivileged user setup during setup-alpine), sudo is only installed either explicitly by the user or indirectly through a package that depends on it (2 of them), so sudo will not be available and will cause problems if the command is copied as is.


Also, the community repository needs to be enabled explicitly too, which isn't part of the instruction.

I do not recall needing to do that on my Alpine VM. This is root's history:

1 apk update
1 apk upgrade
3 apk add sudo
4 adduser -G wheel nikita
5 passwd nikita
6 echo -e "[user]\ndefault=nikita" >> /etc/wsl.conf
7 exit

As you can see, I did nothing to enable the community repo — unless it came pre-enabled on the rootfs I used to create this VM.

It's possible that the community repo has been enabled already, but that may be by necessity for your VM image. Check /etc/apk/repositories right after creating the new VM.

I tested installing sudo in a VM with an image from the Alpine Linux website (after setup-interface then setup-apkrepos). Conclusion was sudo didn't exist, but doas did. Only the main repository was enabled.

In general, I am fond of using the proper prompt indicator ($/#) to indicate which commands should be run with elevated privileges and leave it up to the user to figure out how to achieve it.

That is a reasonable solution as well, but makes copying commands massively inconvenient. Something like "Run as root" that's not part of the commands is probably better.

@sosnik
Copy link

sosnik commented Oct 1, 2023

It's possible that the community repo has been enabled already, but that may be by necessity for your VM image.

I think that is the case. I have never actually gone through a 'proper' installation of Alpine. I only use it in docker containers and in VMs created out of docker containers (as is the case for my WSL VM). Given that, I wasn't aware that setup-alpine even existed. I do all my setup with traditional methods. TIL.

But I don't think that

# apk add <whatever>

is particularly inconvenient to copy. You just copy everything right of the # or delete it after pasting. Ideally, one should not be blindly copying commands off of websites without understanding what they do.

Having said that, perhaps some users won't be aware of the subtleties between $ and # and your suggestion of 'Run as root' is more appropriate for general audiences.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-Docs things relating to the documentation A-Packaging Our Debian packages, docker images; or issues relevant to downstream packagers O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Tolerable Minor significance, cosmetic issues, low or no impact to users. T-Task Refactoring, removal, replacement, enabling or disabling functionality, other engineering tasks.
Projects
None yet
Development

No branches or pull requests

4 participants