Feature request: installing and running ajenti as its own user in a venv

[ag88]

I wanted to run ajenti as a user in /home/ajenti.
The motivations are:

• between distribution release upgrades, ajenti and its plugins can be 'left alone' and won't be 'flushed' with a new install.
• to run it with an unprivileged user (for safety/security)
• have all the plugins bundled together in its own venv

I downloaded the script as given in the install guide
https://docs.ajenti.org/en/latest/man/install.html#automatic-installation-in-virtual-environment

running in Ubuntu 22.04.4
created user ajenti
however, I'm intending to install ajenti to /home/agenti and to run it on its own user id in its own venv setup in a subdir within /home/ajenti

• removing 'script must be run as root'

I found myself doing a few things, remove 'script must be run as root' codes.
I'm mainly interested in the pip3 install parts.
but that the script does some other useful stuff, such as to create a systemd unit service file.
I'd think that file can be created as an example rather than set straight in /etc/systemd/system
e.g. I edited like such, note I did not use forking

[Unit]
Description=Ajenti panel
After=network.target
After=network-online.target

[Service]
Type=simple
User=ajenti
WorkingDirectory=/home/ajenti
ExecStart=/home/ajenti/venv/bin/python3 /home/ajenti/venv/bin/ajenti-panel

[Install]
WantedBy=multi-user.target

in addition, the script or I'm not sure if it is ajenty itself created the config files in /etc/ajenti
those config files can be created as examples without root access and with instructions to create and move them to /etc/ajenti

I'm thinking perhaps this can be done as a different install script rather than patching into the existing for venv.
or perhaps that they can simply be documented as part of the install instructions

• 'fixing' pid file requirement

Ajenti insist on a pid file, which isn't strictly necessary with systemd.
I ended up editing in my site packages aj/entry.py

    if daemonize:
        context = daemon.DaemonContext(
            #pidfile=PidFile('/var/run/ajenti.pid'),
            pidfile=PidFile('/home/ajenti/.ajenti.pid')

and later run without the -d option

• log directories /var/log/ajenti and config dir /etc/ajenti

while starting up
I actually ended up changing the user and groups for /var/log/ajenti and /etc/ajenti so that the user ajenti can read and edit those. I ran into some permission errors

I found it coded in aj/log.py

LOG_DIR = '/var/log/ajenti'
LOG_NAME = 'ajenti.log'

I'm thinking that perhaps this can goto /etc/ajenti/config.yml as a config option.

and to fix one of the permission errors starting as a user, i ended doing this fix

*** log.py      2024-03-21 15:51:23.718018794 +0800
--- log.py.orig 2024-03-21 18:17:56.443586216 +0800
***************
*** 107,111 ****
      if not os.path.exists(LOG_DIR):
          os.mkdir(LOG_DIR)
!     os.chmod(LOG_DIR, 0o750)
  
  
--- 107,111 ----
      if not os.path.exists(LOG_DIR):
          os.mkdir(LOG_DIR)
!     os.chmod(LOG_DIR, 0o640)

this is reasonably a bug, the execute permission is needed to operate in the log dir, hence the permissions 0o750

• missing 'users' authentication provider

I had errors using provider: users; users_file: /etc/ajenti/users.yml; and /etc/ajenti/users.yml.

it turns out this is needed

pip install ajenti.plugin.auth-users

after that, I managed to get the 'user' authorization provider working.
Initially I couldn't figure out how to generate the password.
it turns out this is it:

ajenti/plugins/auth_users/api.py

Line 30 in 77be350

def hash_password(self, password, salt=None):

I manually updated /etc/ajenti/users.yml and used the codes to generate a password so that I can log in.

That could perhaps be made into a command line utility, perhaps for the user to generate a user in
/etc/ajenti/users.yml

---

I'm still struggling with other stuff, but that I managed to start Ajenti and login to the web.
I'm getting 'superuser access' needed for practically every other menu option, including 'Settings'. I'm not sure how to go about fix that.

I did a hack, I made

class UsersAuthenticationProvider(AuthenticationProvider):
   def authorize( ... ) :

simply return True

but that didn't made the 'superuser access needed' go away
in fact, I even tried elevate and got root and that isn't enough to make 'superuser access needed' go away lol

[kiarn]

Hello,

I think it will be difficult to avoid superuser permission because it's the kernel of Ajenti to handle softwares which require root access. But it's possible to handle the user permissions via the Users plugin.

Making the UsersAuthenticationProvider will not make the trick, because the user is still limited to the server permissions, and the started worker for the user has the same uid/gid as the user himself.

Since it's not an issue, I'm converting it as a discussion ;)

Regards

Arnaud

[ag88]

hi, my apologies for my late response.
I've been thinking a little about d-bus, but that really I'm not sufficiently familiar with d-bus as well.
such a setup will make the design 'significantly more complicated', but if Agenti does d-bus, it won't be the first to do that.
cockpit is one of them that does lots of d-bus, it is practically designed around it
https://cockpit-project.org/

but that python is really more moduler vs c/c++ based implementations. it is easier to design python modules as plugins.
Octoprint which is 'famous' in the 3d printing world
https://octoprint.org/
exemplify this concept, everythig is a module / plugin

a difficulty with d-bus is to make sure that everything is authenticated and secure, and that alone increase the difficulty significantly e.g. even with PKS authentication, all the modules and Ajenti will need to be paired as such.