I have a python script (details not important for now).
I fetched it from Github several years ago and it worked perfectly.
It hasn’t been updated in YEARS.
It no longer works on the latest version of Raspberry Pi OS (Bullseye).
I think I have worked out what the issue is.
The script contains a library of conf files.
These duplicate the default (working) conf files in /etc.
The script works by replacing these files and then putting the original back.
Here is an example from the install.py file:
import os
os.system('mv /etc/dhcpcd.conf /etc/dhcpcd.conf.original')
os.system('cp /usr/lib/raspiwifi/reset_device/static_files/dhcpcd.conf /etc/')
When I run the mv and cp commands in the terminal, they fail with permission denied.
If I change the command to 'sudo mv… then it works.
print (os.environ) confirms that the environment user is the username set during the Raspberry Pi configuration.
In older versions of Raspbian that was set to pi.
The newer versions require that you set it.
Question 1: Does this sound like a plausible diagnosis? I lack the technical terms to Google it myself. Any explanations or links would be appreciated.
Question 2: What do I do about it? I’m assuming that adding sudo to all os.system commands will work but may not be the right approach.
this sounds like with the new OS version there are new permissions on the folder.( verify with “ls -la”)
you can use chmod or chown to set the files to be able to be run by the user you are running the script as (this would be my suggestion). The easiest option for the file would be to use ‘chmod 777 /etc/dhcpcd.conf’ but don’t tell any linux people I suggested this, changing anything in /etc/ to 777 seems like a big security hole.
the other option could be to use ‘su’ and a username to run the script as a user who can already change the file permissions.
Thanks. All over the web I see people using os.system('sudo name_of_command) so this is either OK, or widespread bad practice. I don’t know enough to use su on the python script, but I’ll keep that on my list for further research.
Interesting. It works. However, the scripts are several files that call each other, and write cron files that call themselves etc. I’m going to have to trace each call and sudo it.
I am still very curious to find out what change in Raspbian led to the breaking of this script.
There are several comparable scripts out there (independent, not forks).
All ceased development at around the same time, and all broke at the same time.
I am completely confused because my use case is very common, and I cannot find a workable solution.
My use case is a Raspberry Pi Zero W being used in IoT applications.
The Pi is completely enclosed and inaccessible (so no pulling the SD card).
The Pi is shipped to a random location where a non-technical user has to connect it to the local wifi.
RaspiWifi used to do this perfectly.
Switch to AP mode when wifi connection fails
User connects via a phone to a captive portal on the Pi
User selects the local wifi and enters the credentials
The Pi reboots into wifi mode and connects
Now I cannot find any solution that works.
People point me to solutions for permanent AP setups, which I don’t want - the phone needs to connect literally once to pass over the wifi credentials.
They point me to Bluetooth connections. However, these all require actions to be taken on the Pi.
Since it is headless, there is no way to take those actions!
My guess, your previous Raspberry Pi OS (formerly known as Raspbian) install had the user pi in the sudoers group with NO password set. That was not ideal, understandably - but since hobbyists are not necessarily linux users, this was a little workaround that worked for a while.
Your script obviously has to have root level access since it is messing with config files and wifi.
You don’t need to amend the script with individual sudo commands, simply run it with sudo, that’s what it is there for.
BTW, that’s also mentioned in the README.md from the RaspiWiFi repo.
No need for paranoia since RaspiWiFi is opensource, very broadly used and nothing harmful can happen when it is run as sudo, it actually has to have root access to work properly.