New code layout for SUSI application

[hongquan]

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?

• To help easier upgrade.
• Reset feature: Reset configuration and reset the whole code files (factory reset).
• To avoid hardcoding "sudo" in our code.

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 to gpio 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.

[norbusan]

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

• run the susi_liniux part as the desktop user (desktop environment) and as dedicated user pi on the raspberry
• make sure that the pi user is in the gpio group on Raspbian
• warn on susi_linux startup on the Desktop if no sound card are found/accessible

[norbusan]

Actually 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 setup
• wlan setip (wifi_search, wap, rwap
• sudo python3 authentication_script not necessary?
• sudo python3 configuration_script: not necessary?
• installation of packages via apt-get and pip

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 ...

[hongquan]

@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]

@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 about susiai?

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