Upcoming moOde 8.3.0 release (Q1 2023)

[Tim Curtis]

Thanks for the explanation Tim, all very clear now.

Out of interest how is this fact:

Note that the userid pi should not be renamed because there are still a few hard coded "/home/pi" paths left in the code. A future release will address this :-)

dealt with on new systems where the default user is specified?  Is there still a /home/pi created even without a pi user?

This is the main issue: since there are hardcoded references to /home/pi, and from now on such user is not automatically created, it should be specified so with the installer, otherwise such folder won't be found... until we eventually remove all such entries, and replace them with "~/".
At least this is how I understand it...

See post number 10 regarding presence of /home/pi on the ISO image.

A global search of the code base listed only 22 occurrences of /home/pi and most of them are used in paths to various moOde log files for example /home/pi/autocfg.log. These can just be replaced by the standard /var/log directory.

The remaining few that reference things like scripts for example /home/pi/.xinirc can be replaced by the environment variable HOME or possibly ~/ but I think ~ can't be used in certain circumstances.

In either case its something that wait for a post r830 release.

[the_bertrum]

I think I'll be taking a backup of my configuration, applying a fresh image using the RaspberryPI Imager to take advantage of the new security and then restoring settings from the backup this time out then, to get the maximum effect. I assume in-place thereafter will "Just Work" ™...

[Tim Curtis]

I think I'll be taking a backup of my configuration, applying a fresh image using the RaspberryPI Imager to take advantage of the new security and then restoring settings from the backup this time out then, to get the maximum effect.  I assume in-place thereafter will "Just Work" ™...

Yes, in-place updates will continue to be provided, plus for all updates after 8.3.0 the progress of the update can be monitored via the "VIEW status" button on System Config. No more need to drop to SSH :-)

[TheOldPresbyope]

There is at least one reference to user pi in a less obvious place: /lib/systemd/system/localui.service wants to start the Xserver as user pi

Code:

...
# start xserver
ExecStart=/usr/bin/xinit -- -nocursor

User=pi
...

I stumbled on this when I tried the "brute force and ignorance" approach to the user naming issue. I used the RaspberryPi Imager to burn a copy of image_2023-01-20-moode-r825-arm64-lite.zip to a uSD card. I used the Imager to create user kreed rather than user pi.

The resulting filesystem does not contain a /home/pi directory and user kreed has userid:groupid 1000:1000.

Code:

kreed@moode:~ $ ls -la
total 40
drwxr-xr-x 2 kreed kreed 4096 Mar 10 19:02 .
drwxr-xr-x 3 root  root  4096 Jan 20 15:57 ..
-rw------- 1 kreed kreed   42 Mar 10 19:02 .bash_history
-rw-r--r-- 1 kreed kreed  220 Jan 20 15:05 .bash_logout
-rw-r--r-- 1 kreed kreed 3523 Jan 20 15:05 .bashrc
-rwxr-xr-x 1 root  root  4681 Jan 20 14:35 .dircolors
-rwxr-xr-x 1 root  root  1516 Jun  5  2022 piano.sh
-rw-r--r-- 1 kreed kreed  807 Jan 20 15:05 .profile
-rwxr-xr-x 1 root  root  1218 Jan 20 14:35 .xinitrc

Naturally the LocalUI feature doesn't work. Quoting from kern.log [as an aside, note too the 'marked executable' message.]

Code:

Mar 10 23:37:18 moode systemd[1]: Configuration file /lib/systemd/system/localui.service is marked executable. Please remove executable permission bits. Proceeding anyway.
Mar 10 23:37:18 moode systemd[1]: Started Start Chromium Browser.
Mar 10 23:37:18 moode systemd[1460]: localui.service: Failed to determine user credentials: No such process
Mar 10 23:37:18 moode systemd[1460]: localui.service: Failed at step USER spawning /usr/bin/xinit: No such process
Mar 10 23:37:18 moode systemd[1]: localui.service: Main process exited, code=exited, status=217/USER
Mar 10 23:37:18 moode systemd[1]: localui.service: Failed with result 'exit-code'.

Once we get these ankle-biter issues fixed, the only problem I'll have is remembering to reach for Imager instead of my long-time fav Balena Etcher. Old habits die hard.

Regards,
Kent

[DRONE7]

the only problem I'll have is remembering to reach for Imager instead of my long-time fav Balena Etcher

Aye..and before that we bemoaned the change from dd to the newcomer Balena  

[Tim Curtis]

There is at least one reference to user pi in a less obvious place: /lib/systemd/system/localui.service wants to start the Xserver as user pi

Code:

...
# start xserver
ExecStart=/usr/bin/xinit -- -nocursor

User=pi
...

I stumbled on this when I tried the "brute force and ignorance" approach to the user naming issue. I used the RaspberryPi Imager to burn a copy of image_2023-01-20-moode-r825-arm64-lite.zip to a uSD card. I used the Imager to create user kreed rather than user pi.

The resulting filesystem does not contain a /home/pi directory and user kreed has userid:groupid 1000:1000.

Code:

kreed@moode:~ $ ls -la
total 40
drwxr-xr-x 2 kreed kreed 4096 Mar 10 19:02 .
drwxr-xr-x 3 root  root  4096 Jan 20 15:57 ..
-rw------- 1 kreed kreed   42 Mar 10 19:02 .bash_history
-rw-r--r-- 1 kreed kreed  220 Jan 20 15:05 .bash_logout
-rw-r--r-- 1 kreed kreed 3523 Jan 20 15:05 .bashrc
-rwxr-xr-x 1 root  root  4681 Jan 20 14:35 .dircolors
-rwxr-xr-x 1 root  root  1516 Jun  5  2022 piano.sh
-rw-r--r-- 1 kreed kreed  807 Jan 20 15:05 .profile
-rwxr-xr-x 1 root  root  1218 Jan 20 14:35 .xinitrc

Naturally the LocalUI feature doesn't work. Quoting from kern.log [as an aside, note too the 'marked executable' message.]

Code:

Mar 10 23:37:18 moode systemd[1]: Configuration file /lib/systemd/system/localui.service is marked executable. Please remove executable permission bits. Proceeding anyway.
Mar 10 23:37:18 moode systemd[1]: Started Start Chromium Browser.
Mar 10 23:37:18 moode systemd[1460]: localui.service: Failed to determine user credentials: No such process
Mar 10 23:37:18 moode systemd[1460]: localui.service: Failed at step USER spawning /usr/bin/xinit: No such process
Mar 10 23:37:18 moode systemd[1]: localui.service: Main process exited, code=exited, status=217/USER
Mar 10 23:37:18 moode systemd[1]: localui.service: Failed with result 'exit-code'.

Once we get these ankle-biter issues fixed, the only problem I'll have is remembering to reach for Imager instead of my long-time fav Balena Etcher. Old habits die hard.

Regards,
Kent

Good catch. That can prolly be addressed via an env variable.

The Imager dev considered the fact there is a need to support /home/pi and so the UID:GID is preserved and the dir is renamed. Thats why you still see the piano.sh in /home/kreed.

[TheOldPresbyope]

the only problem I'll have is remembering to reach for Imager instead of my long-time fav Balena Etcher

Aye..and before that we bemoaned the change from dd to the newcomer Balena  

I grew to hate dd way last century when I had Unix-like (SunOS, Solaris, AIX, IRIX, HP-UX) workstations in my lab. It will always be my tool of last resort. A friend likened dd to double-edged razor blades and recommended keeping both out of reach.

Live long and prosper  

Regards,
Kent

[Tim Curtis]

the only problem I'll have is remembering to reach for Imager instead of my long-time fav Balena Etcher

Aye..and before that we bemoaned the change from dd to the newcomer Balena  

I grew to hate dd way last century when I had Unix-like (SunOS, Solaris, AIX, IRIX, HP-UX) workstations in my lab. It will always be my tool of last resort. A friend likened dd to double-edged razor blades and recommended keeping both out of reach.

Live long and prosper  

Regards,
Kent

lol, dd stands for "data destroyer".

[TheOldPresbyope]

@Tim Curtis 

I think you and I are looking through the telescope from opposite ends  

From my perspective, it's not that the Imager dev chose to support /home/pi but that by default in Linux new user accounts are assigned uid:gid in numeric order beginning at 1000:1000. Thus I have trouble with wording like "aliasing". There is no user pi (see /etc/passwd) to alias to.

Regards,
Kent

[Tim Curtis]

@Tim Curtis 

I think you and I are looking through the telescope from opposite ends  

From my perspective, it's not that the Imager dev chose to support /home/pi but that by default in Linux new user accounts are assigned uid:gid in numeric order beginning at 1000:1000. Thus I have trouble with wording like "aliasing". There is no user pi (see /etc/passwd) to alias to.

Regards,
Kent

Right but our release image contains /home/pi with piano.sh, .dircolors and .xinitrc files. These are preserved if something other than pi is chosen as the userid in the Pi Imager which suggests that it's intelligently renaming /home/pi to /home/USERID instead of just creating an empty /home/USERID and leaving /home/pi as-is.