foosel
commented
1 year ago As already told you via DM, I totally lost sight of this with everything else going on and only now finally got around to testing this. Big big sorry for that.
However, I sadly have to report, that octopi-password.txt does not work (32bit), contrary to your comment https://github.com/guysoft/OctoPi/issues/788#issuecomment-1285508388. It may very well be showing as being executed, but it is not doing anything. My testrig setup involves flashing an image and then setting the hostname and password via octopi-hostname.txt and octopi-password.txt. Hostname setting worked. However, upon attempting to log into the machine with the newly set password, access was denied. Using the default raspberry instead however worked, so something is broken there.
Can also be confirmed by these lines in the motd:
SSH is enabled and the default password for the 'pi' user has not been changed.
This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password.And OctoPrint also warns about this:
Meanwhile:
root@octopia:/home/pi# systemctl status change_password | cat
● change_password.service - LSB: Change pi's password via /boot/octopi-password.txt
Loaded: loaded (/etc/init.d/change_password; generated)
Active: active (exited) since Thu 2022-09-22 01:23:58 BST; 2 months 16 days ago
Docs: man:systemd-sysv-generator(8)
Tasks: 0 (limit: 1472)
CPU: 0
CGroup: /system.slice/change_password.service
Sep 22 01:23:56 octopia systemd[1]: Starting LSB: Change pi's password via /boot/octopi-password.txt...
Sep 22 01:23:58 octopia systemd[1]: Started LSB: Change pi's password via /boot/octopi-password.txt.-- Journal begins at Thu 2022-09-22 01:23:40 BST, ends at Thu 2022-12-08 11:19:00 GMT. --
Sep 22 01:23:46 octopi systemd[1]: Starting LSB: Change pi's password via /boot/octopi-password.txt...
Sep 22 01:23:48 octopi systemd[1]: change_password.service: Succeeded.
Sep 22 01:23:48 octopi systemd[1]: change_password.service: Unit process 442 (change_password) remains running after unit stopped.
Sep 22 01:23:48 octopi systemd[1]: change_password.service: Unit process 444 (chpasswd) remains running after unit stopped.
Sep 22 01:23:48 octopi systemd[1]: Stopped LSB: Change pi's password via /boot/octopi-password.txt.
Sep 22 01:23:49 octopi chpasswd[444]: pam_unix(chpasswd:chauthtok): password changed for pi
Sep 22 01:23:49 octopi change_password[442]: Password for user pi changed and change file deleted.The change_password service basically consists of this:
do_start () {
text_file="/boot/octopi-password.txt"
if [ ! -f "$text_file" ]
then
exit 0
fi
new_password=`head -n1 "$text_file" | sed -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//' | tr -d '\n'`
if [ ! -n "$new_password" ]
then
log_failure_msg "No new password provided, refusing to change to empty password"
exit 1
fi
(echo "pi:$new_password" | chpasswd && rm "$text_file" && log_success_msg "Password for user pi changed and change file deleted") || log_failure_msg "Could not change password"
}Running echo "pi:newpassword" | chpasswd manually from a root prompt works and does what it's supposed to do, so I frankly have NO idea right now what's going wrong here. I wonder if it could be solved by getting rid of the init script and converting that into a proper unit instead.
A quick test with this seems to work at least:
/etc/systemd/system/change-password
[Unit]
Description=Allow changing the main user's password via /boot/octopi-password.txt
DefaultDependencies=no
Before=network-pre.target
Wants=network-pre.target
After=local-fs.target
Wants=local-fs.target
[Service]
Type=oneshot
ExecStart=/root/bin/change-password
[Install]
WantedBy=multi-user.target/root/bin/change-password
#!/usr/bin/env bash
set -e
USERID=1000
FIRSTUSER=`getent passwd $USERID | cut -d: -f1`
PASSWORD_FILE="/boot/octopi-password.txt"
if [ ! -f "$PASSWORD_FILE" ]
then
exit 0
fi
# read password from file
new_password=`head -n1 "$PASSWORD_FILE" | sed -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//' | tr -d '\n'`
if [ ! -n "$new_password" ]
then
echo "No new password provided, refusing to change to empty password"
exit 1
fi
# change password
(echo "$FIRSTUSER:$new_password" | chpasswd && rm "$PASSWORD_FILE" && echo "Password for user $FIRSTUSER changed and change file deleted") || echo "Could not change password for $FIRSTUSER"
-- Journal begins at Thu 2022-09-22 01:23:40 BST, ends at Thu 2022-12-08 11:20:00 GMT. --
Dec 08 11:14:11 octopia systemd[1]: Starting Allow changing the main user's password via /boot/octopi-password.txt...
Dec 08 11:14:13 octopia chpasswd[273]: pam_unix(chpasswd:chauthtok): password changed for pi
Dec 08 11:14:13 octopia change-password[271]: Password for user pi changed and change file deleted
Dec 08 11:14:13 octopia systemd[1]: change-password.service: Succeeded.
Dec 08 11:14:13 octopia systemd[1]: Finished Allow changing the main user's password via /boot/octopi-password.txt.I haven't yet been able to test this against a completely fresh image however and also don't know if I will get around to doing that.
guysoft
wtremmel
CoryCharlton
badnetmask
dchauran
rubyredrick
loskexos
kevinwright
bsimmo
Third release candidate for OctoPi 1.0.0
As before, there are both 32bit and 64bit images available. The 64bit image is based on on RpiOS 64bit.
Raspsberrypi 3 and up can try the 64bit version. No performance gain in normal OctoPi is expected. It might help future plugins.
Please try the release candidate so we know it works.
32bit armf: Download it at: https://unofficialpi.org/Distros/OctoPi/nightly/2022-10-27_2022-09-22-octopi-bullseye-armhf-lite-1.0.0.zip
Md5:
88135c1af2491aa4f114190c728d5fa2.64bit arm64/aarch64: Download it at: https://unofficialpi.org/Distros/OctoPi/nightly-arm64/2022-10-27_2022-09-22-octopi-bullseye-arm64-lite-1.0.0.zip
Md5:
a0fe9dd406f7bb4f8bf0a3d0af1d4582.Changes since RC2
Changes in the image since RC1
/opt/ffmpeg-hls/ffmpeg#784Changes in the image