script depends on uid 1000

Bug #2004543 reported by Peter Jose De Sousa
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
maas-cert-server
New
Undecided
Unassigned

Bug Description

hello,

when running the maniacs-setup the script will stop on UID 1000 - if this uid does not exist the script will exit.

[workaround]

set your current user to have uid 1000:

$ sudo usermod -u 1000 $USER

Thanks,
Peter

Related branches

Revision history for this message
Jeff Lane  (bladernr) wrote :

We look for UID1000 as that is the UID for the default user created during install, as seen over several MAAS and ISO installs. has that behaviour changed?

I wonder if this can't be handled better by grabbing the first user account at 1000 or higher... or perhaps providing a list of options like:

We discovered the following user accounts: which one should be used as the admin account?

1: myuser uid 1001
2: ubuntu uid:1002

Pick one: __

Revision history for this message
Rod Smith (rodsmith) wrote :

The maniacs_setup code currently uses the following line to determine the "default" user:

DEFAULT_USER=$(getent passwd | awk -v val=1000 -F ":" '$3==val{print $1}')

I don't know why it uses this method, offhand; the more obvious, and simpler, method would be:

DEFAULT_USER=$(whoami)

This alternative method would set up MAAS using the currently-logged-in user account rather than the account with UID 1000. Offhand, that seems like a better approach. When following MANIACS to the letter, the two should produce identical results, but if one were to deviate (say, by creating two accounts and using the second one, with UID 1001, to run maniacs-setup), setting DEFAULT_USER to the value of $(whoami) should work better. Obviously, this should be tested before committing a change.

Revision history for this message
Jeff Lane  (bladernr) wrote (last edit ):

whoami won't work since the script has to be run via sudo:

bladernr@galactica:~/development/maas-cert-server$ whoami
bladernr
bladernr@galactica:~/development/maas-cert-server$ sudo whoami
root

And in fact, we actually use whoami earlier in the script to ensure we're running as root:
1166 if [ `whoami` != "root" ] ; then
1167 echo "This script must be run via sudo. Exiting!"
1168 exit 1
1169 fi

I think though, that before this can be really resolved, we need to know why it happened in the first place:

1: why does uid 1000 not exist, when that is the default uid for pretty much any Ubuntu installatiuon I've seen (via either MAAS or ISO)
2: If uid 1000 isnt' the default, then what is?

The DEFAULT_USER is used to set up the maas admin account, and set up SSH keys for the default user (which means that user should have a shell...)

Another idea would be "if 'ubuntu' exists as a user, use THAT UID whatever it is, and if not, then create the ubuntu user from scratch and use the newly created user UID."

Or just create a maasadmin account on the server by default, and a corresponding maasadmin user in MAAS...

But the simplest may be to switch just to using logname instead which DOES get the man username when sudo is used:

bladernr@galactica:~/development/maas-cert-server$ logname
bladernr
bladernr@galactica:~/development/maas-cert-server$ sudo logname
bladernr
bladernr@galactica:~/development/maas-cert-server$ sudo whoami
root

Revision history for this message
Rod Smith (rodsmith) wrote :

I'd forgotten about the sudo issue; you're right that whoami won't work reliably -- but as you say, logname should do the trick instead.

AFAIK, UID 1000 is always the default user ID in Ubuntu. That's certainly been true even on my most recent installations of 22.04. (I haven't yet done many installs of 22.10.) I did some Googling and found some posts suggesting that people sometimes try to get clever and change their default UID to 0 in an effort to get around the need to enter a password when doing sudo, but that of course creates its own problems. UID 1000 could also be missing if somebody did account maintenance post-installation -- say, by creating a second account (UID 1001) and then deleting the first (UID 1000).

Learning what went wrong from @Peter De Sousa might indeed be informative, but I expect we'll be able to reproduce and fix the bug without that feedback. Of course, that would run the risk of fixing a subtly different bug....

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.