moodeutl -i removes home directories

[redlegoman]

I've been trying to automate moodeaudio installs by using moodeutl -e to dump out a moodecfg.ini file and then using moodeutl -i to read it back in. However, when I do this, moodeutl -i removes some users home directories from /home. Is it supposed to do this?

Steps to reproduce on brand new install from raspberry pi imager (9.3.0)
I created a user called "moodeaudio" during pi imaging, rather than the "pi" user, but it is the same with the pi user

login as moodeaudio user 
sudo useradd -m  test
verify /home/test exists
sudo moodeutl -e /boot/moodecfg.ini 
sudo moodeutl -i
see that /home/moodeaudio has gone but /home/test is still there!

In fact, during testing, I found it deletes all user's home dirs that come alphabetically before, well I'm not sure what.

After doing the above steps, I was left with only /home/test.

I then created a user called "test2", home dir - /home/test2 and after running moodeutl -i it deleted /home/test and left behind /home/test2

I should note that the users are still in /etc/passwd, just the home dirs in /home.

If I create a user with its home dir outside /home, it is not removed.

It seems to leave the /home dir of the user highest up the alphabet. I created a user called "zzzz" and it removed all the /home dirs except /home/zzzz.

[Tim Curtis]

What's the usage scenario where automated installs are needed?

[redlegoman]

What's the usage scenario where automated installs are needed?

I am going to build one moodeudio pi for many rooms, probably about 6 or 7. I'd like to not have to visit the web page of each device to set them up. I want to use ansible to do it. And if I want to change anything later, say enable UPNP on each pi, I can do so from Ansbile and not have to visit each in turn.

Bearing in mind what moodeutl does to the home dirs, I have worked around it, and as long as I connect as the "pi" user (or whatever I choose) when running the playbook, then it works. What I was doing was creating an "ansible" user to run the playbooks, as I do for my other linux hosts, but if I did that, the moodeutl removed the ansible user's home dir (if it was in /home - I suppose another workaround is to put the ansible user's home outside /home).

But it seems very odd behaviour. Is it supposed to do what I describe?

[Tim Curtis]

IIRC it's actually the -e (extract) option that results in homedir being "cleaned". It makes a call to the getUserId() function in inc/common.php.

Code:

// Assumes only one dir under /home, the one matching the userid entered into
// the Raspberry Pi Imager when making the image.
function getUserId() {

Moode will only function correctly if there is a single home directory and corresponding userid, the one created in the Pi Imager. This is normally not a problem since moode is headless a single user OS. The function getUserId() asserts this condition or aborts the startup sequence.

[redlegoman]

the "-e" does not remove any contents of /home on my pi. And I've re-imaged it a few times now. It is definitely the "-i"...

(I tried to add a screenshot, but it made the message too big)

but that's fine. If it's working as you intended, I will work around it.

[redlegoman]

I think the problem is in /var/www/util/sysutil.sh
this line

Code:

  HOME_DIR=$(ls /home/)

sets HOME_DIR to an ls of /home, which if there is another dir in there, say /home/ansible, HOME_DIR becomes
  

Code:

  HOME_DIR=ansible
  moodeaudio

   
including the linebreak

then the line 

Code:

  rm -rf /home/$HOME_DIR/.config/chromium/Singleton*

  
is actually 

Code:

  rm -rf /home/ansible
  moodeaudio/.config/chromium/Singleton* 

  
because it expands $HOME_DIR with the line break, meaning it tries to delete    

Code:

  /home/ansible

and

Code:

  moodeaudio/.config/chromium/Singleton* 

from the current working dir, and fails (if CWD is not /home), but it does delete /home/ansible

if my current working dir is /home, which is was when I was testing, means it deletes all the home dirs except for moodeaudio because that was the user created by the imager.

[redlegoman]

But, I can also see that you are using the presence of /home/USER to work out which user is the one created by the raspberry pi imager. So, as you say, we can't really have extra users, not in /home anyway.
So I'll shut up.

[TheOldPresbyope]

But, I can also see that you are using the presence of /home/USER to work out which user is the one created by the raspberry pi imager. So, as you say, we can't really have extra users, not in /home anyway.
So I'll shut up.

Remember that the user and group names are just a convenience included for humans. What counts for almost all Linux system functions is the numeric UID and GID. If you use "ls -n" you'll see the actual UID:GID ownership of files and directories. 

In Debian, the non-system users and groups are assigned beginning at 1000 with 1000 typically being the "default" user. That's the UID to which the Imager program assigns whatever username it creates. If you change a username after the fact, the UID:GID of its files and directories will remain the same.

Some years ago, I toyed with reworking some of the moOde code to enforce the rule that UID:GID 1000:1000 would always be the default user in order to get around the problem of determining which user was which. This was because I'd also run into the problem of having created more than one user. In my case, I realized I was better off keeping moOde as a packaged single-user system and setting up a separate server(s) for some other services I was interested in. I stopped toying.

ISTM you could make your user "ansible" be some UID:GID other than 1000:1000 and modify moOde code mutatis mutandis (that's a clever Latin phrase roughly meaning "as is except for whatever changes are necessary") to get what you want.

Then post a git pull request

Regards,
Kent