A lot of Sudo password requests on Debian

[eduardomozart]

Hello, I know that Debian 12 isn't officially supported yet, but I'm facing an issue that I believe isn't related to Debian 12 at all, but with how sudo commands are being handled on Debian systems. When running the install command, it doesn't allow to run as root, so I'm using my user instead, and I'm facing errors and multiple password requests. I believe the way that "sudo" works on Debian differs from Ubuntu, as Ubuntu ask only one time and allow further sudo requests without requesting user password into the same console session, but it didn't seem to be the case on Debian.

Here's the command output of the 1st screen of the setup:

Itiligent VDI & Jump Server Appliance Setup.
                               Powered by Guacamole

Ctrl+Z now to exit if you wish to edit any 1-setup.sh options for an unattended install.

[sudo] senha para unifi:
Sorry, user unifi is not allowed to execute '/usr/bin/chmod -R 770 /home/unifi/guac-setup/tmp' as root on unifi.
[sudo] senha para unifi:
Sorry, user unifi is not allowed to execute '/usr/bin/chown -R :root /home/unifi/guac-setup/tmp' as root on unifi.
Update Linux system HOSTNAME [Enter to keep: unifi]
                        Enter new HOSTNAME :

[sudo] senha para unifi:
[sudo] senha para unifi:
[sudo] senha para unifi:
[sudo] senha para unifi:
Update Linux LOCAL DNS DOMAIN [Enter to keep: robertinho.com]
                        Enter FULL LOCAL DOMAIN NAME:

[sudo] senha para unifi:
Sorry, user unifi is not allowed to execute '/usr/bin/sed -i /192.168.0.127/d /etc/hosts' as root on unifi.
[sudo] senha para unifi:
Sorry, user unifi is not allowed to execute '/usr/bin/sed -i /domain/d /etc/resolv.conf' as root on unifi.
[sudo] senha para unifi:
Sorry, user unifi is not allowed to execute '/usr/bin/sed -i /search/d /etc/resolv.conf' as root on unifi.
[sudo] senha para unifi:
[sudo] senha para unifi:
[sudo] senha para unifi:
[sudo] senha para unifi:

The questions from 2nd screen (Domain names, NGINX, etc.) happens without any sudo request.

But it fails on the 3rd one:

Itiligent VDI & Jump Server Appliance Setup.
                               Powered by Guacamole

Beginning Guacamole setup...

Checking Linux distro specific dependencies...
OK

[sudo] senha para unifi:
Sorry, user unifi is not allowed to execute './2-install-guacamole.sh' as root on unifi.
2-install-guacamole.sh FAILED. See /home/unifi/guac-setup/guacamole_1.5.3_setup.log

Even with sudo password being filled correctly, some commands still fails to run if the binary isn't set on sudoers file for the user, as can be seen above for chmod and chown commands, and even for the 2-install-guacamole.sh script itself.

For properly running the installer without those multiple password requests, I had to create a file at /etc/sudoers.d/20_guacamole with the following content:

unifi ALL=(ALL:ALL) ALL

So the script requests the password one time as expected on 1st screen and it works as it should. I believe the script should setup the sudoers file with the commands it executes so the user doesn't need to fill their credentials every time when running sudo on Debian systems or the script should allow it to run as root.

[itiligent]

Thats interesting. I actually do the majority of my testing on Debian, especially 11, and now also on 12. I see no such sudo issues on either Debian or any flavour of ubuntu ever with this script in the year or so its been in use. I have never had to enter credentials more than once ever in many hundreds of deployments, and you're the first person to report this behaviour. The script has to do a number of things noth as sudo and also as the local user. Sudo -E is used to keep exported variables all under the same environemnt context else SSL certificates and cron jobs end up being setup and saved under the root user etc. My test images are vanilla server minimal network installations with only sudo installed / root disabled and an apt update applied. My test user is the sudi enabled user created at first install.

edit: Just has a thought.... make sure you've not added sudo in front of any commands that previously did not... the earlier pull request adding systemctl lines did this, and this may break things from the env with all the correct exported variables. The user that runs the script is assumed in the sudo group. Not sure if I've documeted that anywhere... I'll check

[eduardomozart]

I installed the system using a clean minimal install of Debian 12. The UniFi package (https://help.ui.com/hc/en-us/articles/220066768-UniFi-Network-Updating-Third-Party-non-Console-UniFi-Network-Applications-Linux-Advanced-) seems to handle this by creating a custom sudoers file during the installation of unifi DEB package. It creates the file /etc/sudoers/10_unifi with the following content, where unifi is my user and there's some tools that it allows my user to run as root.

unifi ALL=(ALL:ALL) NOPASSWD:/usr/bin/update-alternatives, /usr/bin/test, /sbin/ubnt-systool, /sbin/ubnt-tools, /usr/lib/unifi/bin/ubnt-apttool

[eduardomozart]

I believe it's happens when setting up the root password during Debian setup. I was able to run the script with only one sudo password request on Debian after adding the user to the sudo usergroup, as stated on Debian Wiki.

# addgroup unifi sudo

I believe the script should be updated to check if current users belongs to the sudo usergroup as a pre-req to start the setup.

[itiligent]

Yes, on Debian disablng root at install triggers sudo to be installed and enabled for the first user. This seems to be the root cause of this issue and why your user is not a default sudo member.

When I get some time I will update the script to check if the curent user is already a member of sudo, and if not add them. The downside is that if the user must be added to sudo group then the script will need to exit and be restarted. In the meantime I'll update the prerequisites to mention it.

Thanks very much for the good suggestions!