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

iso-generator assumes sudo is already configured #878

Open
popey opened this issue Sep 30, 2019 · 3 comments
Open

iso-generator assumes sudo is already configured #878

popey opened this issue Sep 30, 2019 · 3 comments
Labels
bug Bugs and errors

Comments

@popey
Copy link

popey commented Sep 30, 2019

Basic info:

Anarchy version: git master

Installation method (VM/Host): inside lxd

System specifications (Processor, GPU, RAM ...): i7 / 32GB

What you expected would happen

I spun up a clean arch linux container in which I wanted to test building the installer iso.

lxc launch images:archlinux/current/amd64 arch

Jump in the container, install git, clone this repo and then run the installer.

lxc shell arch
pacman -Syyu git
git clone https://github.com/AnarchyLinux/installer
cd installer/
./iso-generator.sh

At this point I'd expect it to fail because sudo isn't setup.

What actually happened

It does indeed prompt to install many dependencies, but perhaps should do a pre-flight check on sudo.

-- Anarchy Linux --

30/09/2019 21:48 : Checking dependencies ...
error: package 'wget' was not found
error: package 'libisoburn' was not found
error: package 'squashfs-tools' was not found
error: package 'p7zip' was not found
error: package 'xxd' was not found
error: package 'gtk3' was not found
error: package 'pacman-contrib' was not found
error: package 'pkgconf' was not found
error: package 'patch' was not found
error: package 'gcc' was not found
error: package 'make' was not found
error: package 'binutils' was not found
error: package 'go' was not found
30/09/2019 21:48 : Missing dependencies: wget libisoburn squashfs-tools p7zip xxd gtk3 pacman-contrib pkgconf patch gcc make binutils go
Install them now? [y/N]: 
y
30/09/2019 21:48 : Chose to install dependencies
30/09/2019 21:48 : Installing wget ...
./iso-generator.sh: line 170: sudo: command not found
30/09/2019 21:48 : User force stopped the script

Steps needed to reproduce the bug

These assume you have configured lxd/lxc correctly already.

lxc launch images:archlinux/current/amd64 arch
lxc shell arch
pacman -Syyu git
git clone https://github.com/AnarchyLinux/installer
cd installer/
./iso-generator.sh

## Possible fixes

Check early on in the script to see if we're root or if sudo is available, and abort with an appropriate error message.

## Bug report checklist

* [X] I've checked for any existing issues similar to mine and tried the solutions provided there
* [X] I've checked online for any existing fixes to my issue and added the link above
* [X] I've tried taking logs and submitting them above
@popey popey added the bug Bugs and errors label Sep 30, 2019
@erazemk
Copy link
Member

erazemk commented Oct 1, 2019

We need sudo as a prerequisite to install other dependencies with pacman at the moment, but I am adjusting the script for use with docker (and potentially other containers).

If you've got experience with those, your help at AnarchyLinux/docker would be much appreciated.

Currenty there is also a problem of the container needing to be privileged, since we use arch-chroot, but that will possibly be replaced with fakechroot.

If we were to force the user to run the script as root, instead of with sudo, then they would not be able to make the packages from the AUR with makepkg, because it doesn't permit root users to build them.

Do you recommend we check for the presence of sudo on the system or check if the script was run with sudo?

@popey
Copy link
Author

popey commented Oct 1, 2019

Thanks for the prompt reply to my issue.

Technically I didn't need git, but installed it so I could clone the repo. I could just as easily have used something like curl or wget to grab the release tarball or scp.

It failed later on anyway as it doesn't like running as root, which inside the container is the default. I'll try re-running as non-root and see how far I get.

So as later steps you call fail as root, I think you're better to check that the running user a) is not root, and b) has sudo capabilities. You can first check for the sudo binary in the path which is a good step, and should get most people setup correctly.

@erazemk
Copy link
Member

erazemk commented Oct 1, 2019

So as later steps you call fail as root, I think you're better to check that the running user a) is not root, and b) has sudo capabilities. You can first check for the sudo binary in the path which is a good step, and should get most people setup correctly.

Great idea, I'll try and add it.

Edit: If we can figure it out I think it would be better to run the whole script as root (since I'm guessing most containers do this by defaut) and then make the packages in a subshell without root privileges or take that part out entirely.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Bugs and errors
Projects
None yet
Development

No branches or pull requests

2 participants