Open hongquan opened 5 years ago
Thanks for the ideas, I agree with the general proposal, but want to point out a few things
I have already packaged susi_server
as Debian packages, that works easily.
I recommend calling the user _susi
(as I did) or similar, because susi
might be a valid user name a user might want to take. To avoid collision, the underscore is often used. My susi-server package uses _susiserver
(see below why)
While installing susi_linux
via deb etc is ok, we cannot run it as other user, because this might block access to sound devices on desktop.
To fall in line with what you proposed, we should
susi_liniux
part as the desktop user (desktop environment) and as dedicated user pi
on the raspberrypi
user is in the gpio
group on Raspbiansusi_linux
startup on the Desktop if no sound card are found/accessibleActually git grepping through susi_linux git it is not so bad ... most sudos can be categorized into the following categories:
sudo systemctl
enabling/disabling services, most of them related again to wlan setupwifi_search
, wap
, rwap
sudo python3 authentication_script
not necessary?sudo python3 configuration_script
: not necessary?So I think that getting rid of the sudo
calls will not be that bad once we have installation done.
That is BTW the biggest problem with packaging susi_linux
, the horde of pip3 install dependencies. There it would be better to have again one Debian package for each of it ...
@norbusan Could you explain why
we cannot run it as other user, because this might block access to sound devices on desktop.
About using _
prefix to avoid collision, I feel it looks weird and ugly. Many softwares like PostgreSQL, MySQL, Redis come with dedicated username without that underscore. But yes, because we want to support normal desktop user, we should think about this. How about susiai
?
@norbusan Could you explain why
we cannot run it as other user, because this might block access to sound devices on desktop.
On current desktop, the pulseaudio deamon is often started in the user session, that is, when a user logs in, Other users, in our case the susi
user will most probably not have access to the microphone or loudspeaker (access denied).
About using
_
prefix to avoid collision, I feel it looks weird and ugly. Many softwares like PostgreSQL, MySQL, Redis come with dedicated username without that underscore. But yes, because we want to support normal desktop user, we should think about this. How aboutsusiai
?
That is true. The underscore is not a required option. It is one option to make sure that we don't create a username that might be taken at the moment or in the future. susiai
might be also fine. I just wanted to be sure.
Concerning ugly
: This is the least I care for, because the actual desktop user never sees that, and we only use it in the postinstall/postrm scripts etc. So there is no need whatsoever to remember or make it beautiful.
Hope that explains my intentions
Sorry I don't have enough time to think carefully to give a proper proposal, so I just give brief of my thinking here and we will discuss about new project layout for SUSI.
Why we need it?
My suggestion:
Object is to transform SUSI Server, SUSI Linux, so that it can be packaged to *.deb. We then setup a repo to distribute the updates in form of deb. Other than deb, recently there are new packaging mechanism like snap, flatpak. The later try to isolate the application in a sandbox environment. This sounds secure, but in fact, that isolated environment causes many bugs that prevent the app from accessing other system's resource. So I decide to stay with deb. We also deliver the RaspberryPi box with just enough software and don't want user to install more to it, so we don't really need an isolated environment for our SUSI apps in that box.
When packaged in deb, our app will be installed in system folders (/etc, /usr/share, /var/lib) where normall user cannot overwrite. That prevents user from modifying our code (and break the app) by accident.
With deb package, the factory reset is easy: Just reinstall the app with
apt install --reinstall
. Resetting configuration is also easy:dpkg-reconfigure
.Being installed to system folder, our app needs a dedicated user for it. I suggest to create a user
susi
with home folder in/var/lib/susi
to run our app. This user can be created by postinst script of deb package. Other than that, we will add this user togpio
group so that it can access GPIO without "sudo". That "adding user to group" step can also be done automatically with postinst script.To be simple, we let both SUSI Server and SUSI Linux run in
susi
user.