support maverick commands

[SamuelDudley]

control services

maverick start ..
maverick stop ..
maverick status ..

[fnoop]

Note that maverick start .. etc are just wrappers for systemctl. It prefixes 'maverick-' to each systemd manifest name, so:
maverick status nginx
actually refers to the system service 'maverick-nginx'. the actual system command that is then run is:
sudo systemctl status maverick-nginx
All the maverick manifests are in /etc/systemd/system, and are all prefixed with 'maverick-'

The same kind of thing happens with maverick start .. and maverick stop ... The maverick script itself (~/software/maverick/bin/maverick) is the reference.

Given that, it might be better for python/-api to use systemd directly using pythonic modules:
https://github.com/mosquito/cysystemd
https://github.com/systemd/python-systemd

[fnoop]

Also a lot of the maverick services are controlled through puppet, ie through localconf.json. So as well as starting/stopping services, they should also be set in localconf.json to persist the change. Or maybe that's not always wanted.
Also note there are two different levels of service activation:

• start/stop - this refers to the current status of the service - whether it is running or not right now
• enable/disable - this refers to the persistent state of the service - ie whether it should start or not at boot or at runlevel target change

[SamuelDudley]

re interacting with systemd directly, that was my plan where possible. Last time I had a look at options this one was at the top of my list: https://github.com/facebookincubator/pystemd

[fnoop]

Ooh interesting. Can we guarantee all the platforms will have dbus?

[fnoop]

Also note that maverick status will show all running status. It used to be that all the services were manually maintained in the bin/maverick script, but now there is a parsed file hierarchy in ~/software/maverick/bin/status.d/. Each directory in their represents a 'section', and each file within each directory represents a service within that section.

[SamuelDudley]

mav@dev:~/software/python/bin$ sudo python3.7 <-- must be sudo :(

from pystemd.systemd1 import Unit
import glob
glob.glob('/etc/systemd/system/maverick*')

unit = Unit(b'maverick-webdev.service')
unit.load()

unit.Service.GetProcesses()

unit.Unit.Names
[b'maverick-webdev.service']

unit.Unit.ActiveState
b'active'

unit.Unit.SubState
b'running'

unit.Service.GetProcesses()
[(b'/system.slice/maverick-webdev.service', 4917, b'node /usr/bin/yarn run serve'), (b'/system.slice/maverick-webdev.service', 4949, b'/bin/sh -c vue-cli-service serve'), (b'/system.slice/maverick-webdev.service', 4950, b'/usr/bin/node /srv/maverick/code/maverick-web/node_modules/.bin/vue-cli-service serve')]

unit.Unit.Stop('replace')

unit.Unit.ActiveState
b'failed'

unit.Unit.SubState
b'failed'

unit.Unit.Start('replace')

hmmmm

not sure if this is worth it... we have to run -api as sudo and we cant enable / disable services... just stick to subprocess...

[fnoop]

Interesting OK, we'll hit this problem with whatever we use to control systemd. There are ways we can provide sufficient granular root access to a process.
Alternatively we can subprocess out to the maverick command, but it should be noted that the maverick command (well OK let's be honest the entire mav user) has unrestricted root access. Which really should be changed at some point. There is a parameter that controls this: base::users::mav_sudopass. And it's of course less efficient and pythonic.
Perhaps we could create a microservice that runs as root that just deals with systemd - that would make @cglusky incredibly happy.

[SamuelDudley]

I like the idea of a microservice here. I'll put something together. Preferences on the communication? Rest, graphql, something else?
I'm leaning towards a simple rest interface that we can await on using async calls for -api.

[fnoop]

If we used dbus, we could use the permissions manager in that instead, which is more flexible:
https://github.com/facebookincubator/pystemd

But then that means depending on dbus, which isn't always a given in non-desktop environments. Probably not a good idea.

[fnoop]

Looks like systemd requires dbus..

One option is to add a PolicyKit pkla:

[dev] [root@maverick-raspberrylite ~]# cat /etc/polkit-1/localauthority/50-local.d/org.freedesktop.systemd1.pkla
[Allow user mav to run systemctl commands]
Identity=unix-user:mav
Action=org.freedesktop.systemd1.manage-units
ResultInactive=yes
ResultActive=yes
ResultAny=yes

This allows us to start/stop/restart (any) services as the mav user:
[dev] [mav@maverick-raspberrylite /usr/share/polkit-1/actions]$ systemctl restart maverick-visiond

Unfortunately it doesn't allow us to specify which services can be controlled (allows all system services), and also doesn't allow us to enable/disable services, which requires root filesystem access (to change the symlinks in /etc/systemd/system/multi-user.target.wants/):

[dev] [mav@maverick-raspberrylite /usr/share/polkit-1/actions]$ systemctl disable maverick-visiond
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-unit-files ===
Authentication is required to manage system service or unit files.
Authenticating as: root
Password:

But it's an option - the enable/disable could be done separately through maverick configure which always runs as root.

[fnoop]

Another option is to create user systemd manifests, by putting them in ~/.config/systemd/user. This is possibly a cleaner way of doing it, although might be a bit more confusing for people used to looking for them in /etc/systemd/system.

This allows control through the mav user without any escalated privileges, however not sure if it allows processes to be run as root, which some of the mav processes do.

[fnoop]

Using subprocess and just calling maverick [command] [service] or sudo systemctl [command] service] and creating specific sudo rules for maverick-* services may well just be the easier thing to do in the short term. It's a bit messier, but it's an awful lot simpler as it's already all working, doesn't require separate python modules/code, doesn't require a microservice, doesn't require redoing the privilege escalation.