[PROBLEM] Local UI does not start after software update

[NHWally]

Why do you think its not robust given that images are to be created with the Pi imager which only allows one userid?

For example if there are multiple userid's in /home each populated with the usual files then what logic during startup would be used to determine which one to use?

Tim,
  I know that I used Pi imager to install the previous Moode image, and so I am at a loss as to how the pi users home folder majikly appeared!
Perhaps I didn't set up the user in the imager, but did it on first boot??

In anycase, the current implementation will fail if the default user does not sort first in the file listing.

Wouldn't it be better to determine the default user directly?

The following would not have the issue (the first word is the username):
grep 1000 /etc/passwd

or (returns only the username)
awk -F":" '$3=="1000" {print $1}' /etc/passwd


-W

[NHWally]

... Also the PHP function
posix_getpwuid(1000)
should return the username (or at least the documentation says it should)
(I've not tried this, as I have never written a line of PHP in my life.)

[Tim Curtis]

Why do you think its not robust given that images are to be created with the Pi imager which only allows one userid?

For example if there are multiple userid's in /home each populated with the usual files then what logic during startup would be used to determine which one to use?

Tim,
  I know that I used Pi imager to install the previous Moode image, and so I am at a loss as to how the pi users home folder majikly appeared!
Perhaps I didn't set up the user in the imager, but did it on first boot??

In anycase, the current implementation will fail if the default user does not sort first in the file listing.

Wouldn't it be better to determine the default user directly?

The following would not have the issue (the first word is the username):
grep 1000 /etc/passwd

or (returns only the username)
awk -F":" '$3=="1000" {print $1}' /etc/passwd


-W

I dunno whether using another method to get the userid is going to accomplish anything other than masking some sort of setup or configuration breakage resulting in more than one userid in /home.

It might be worthwhile to display a notification that there are other userid's in /home, and there should only be one otherwise things like local display might not work. Then user could go in and see what's going on.

Something like that.

[NHWally]

Tim,
If your intent is to run the UI as 'root', then it is not masking any config problem to just find out who is root.
It should not matter how many users are configured... Uid 1000 is root.

Isn't looking in /home to find the root user just a workaround?
Indeed, the passwd entry also explicitly contains the path to root's home directory if you need it.

The problem that I encountered is a direct side-effect of the implementation, not a problem with the design. The code is simply finding the root user and I don't think that enforcing only one user, or that only one directory is located in /home was ever the intent of the code, just an unintended side effect.

Judging by my brief look at the code, I can tell that you are trying (and succeeding!) in doing a top-notch job with this code. It is well laid out and legible.

I really appreciate what you do, and want to say thanks!
I use my Moode constantly, and would be lost without it.

-W

[TheOldPresbyope]

Careful. The root user on a Linux system has UUID = 0.

Conventionally in modern Linux the first normal, e.g., non-system, user is assigned UUID = 1000 and by default adduser will assign additional UUIDs sequentially from there.


Other than that, I'm sympathetic to your argument. Indeed, ISTR I and several others stumbled into the local display startup code assuming user pi some years ago but I'm too groggy yet to search for the discussion. Woke up way too early and the coffee isn't made yet.


Regards,
Kent

[Tim Curtis]

Tim,
If your intent is to run the UI as 'root', then it is not masking any config problem to just find out who is root.
It should not matter how many users are configured... Uid 1000 is root.

Isn't looking in /home to find the root user just a workaround?
Indeed, the passwd entry also explicitly contains the path to root's home directory if you need it.

The problem that I encountered is a direct side-effect of the implementation, not a problem with the design. The code is simply finding the root user and I don't think that enforcing only one user, or that only one directory is located in /home was ever the intent of the code, just an unintended side effect.

Judging by my brief look at the code, I can tell that you are trying (and succeeding!) in doing a top-notch job with this code. It is well laid out and legible.

I really appreciate what you do, and want to say thanks!
I use my Moode constantly, and would be lost without it.

-W

As @TheOldPresbyope mentioned the user "root" does not exist in MoodeOS. The only user that should exist is the one created via prepping the image with Raspberry Pi Imager.

Since this image prep is REQUIRED per the Setup Guide it's perfectly safe to assume that there will only be one user sub-directory under /home.

The Pi Imager prep requirement was introduced almost a year ago (March 2023) starting with version 8.3.0 to provide improved security for the release images. Obviously there will be many users that don't go for a fresh image and instead perform an in-place update. If there is already more than one userid sub-dir in /home then there is the potential for breakage due to the assumption in the code that will only be one sub-dir.

The best way to handle this situation as I suggested earlier would be to add some code to notify the user since they are the only one that can know which id(s) to delete but I'm not sure thats even necessary at this point because we get virtually no reports of this issue anymore.

[NHWally]

Careful. The root user on a Linux system has UUID = 0.

Conventionally in modern Linux the first normal, e.g., non-system, user is assigned UUID = 1000 and by default  adduser will assign additional UUIDs sequentially from there.


Other than that, I'm sympathetic to your argument. Indeed, ISTR I and several others stumbled into the local display startup code assuming user pi some years ago but I'm too groggy yet to search for the discussion. Woke up way too early and the coffee isn't made yet.


Regards,
Kent

I stand corrected Kent,
Thanks

Tim, I obviously disagree with you, and I've said my piece.
In the end it is your call.
-W

[Kilkern]

Weird thing - I did use the image prep when I installed Moode Audio the first time, and I've never used the *pi* user on any of my raspberries, as an old sysadmin, I hate the dependencies of a particular "hardcoded" user.
I wonder *what* created the pi user in the first place.
There ought to be an override variable in a suitable persistent config file to point to the preferred user, as these raspberries get more and more powerful, and more can do more at the same time ... so there will be more users configured.

Having said that, the short term fix is to ensure your preferred user is the only user present in /home

>>>>>>>.rune
(Kilkern)

[Tim Curtis]

Weird thing - I did use the image prep when I installed Moode Audio the first time, and I've never used the *pi* user on any of my raspberries, as an old sysadmin, I hate the dependencies of a particular "hardcoded" user.
I wonder *what* created the pi user in the first place.
There ought to be an override variable in a suitable persistent config file to point to the preferred user, as these raspberries get more and more powerful, and more can do more at the same time ... so there will be more users configured.

Having said that, the short term fix is to ensure your preferred user is the only user present in /home

>>>>>>>.rune
(Kilkern)

What's the usage scenario where there would be multiple home dirs / userid's ?

In any case, during image build the moode-player package creates the home/pi dir in order to install .dircolors, .xinitrc and piano.sh files. The actual userid is not known at the time the image is built. That happens afterwords when prepping the image with the Pi Imager. The Imager creates a firstrun script that renames the userid pi to whatever was entered.

During an in-place update the moode-player package install will again create the home/pi dir if it doesn't exist. It won't exist if something other than pi was entered previously in the Imager.

The fix is to do some checking during moode startup (worker.php) and delete /home/pi if indicated. This is part of upcoming moode 9.0.5. See the code below in /var/www/inc/common.php

Code:

// Assumes only one dir under /home, the one corresponding to the userid
// entered into the Raspberry Pi Imager when prepping the image.
function getUserID() {
    // Check for and delete '/home/pi' if it has no userid. This dir is created
    // by the moode-player package install during in-place update.
    if (file_exists('/home/pi/') && empty(sysCmd('grep "pi" /etc/passwd'))) {
        sysCmd('rm -rf /home/pi/');
    }

    $result = sysCmd('ls /home/');
    return $result[0];
}