Posts in category system

First official extension: openssh

Tonight I sprint-coded the  OpenSSH extension, removed all openssh-related code in LMC.configuration, and added system-service-related code to  SystemController class.

Guess what:

  • It works like a charm :-)
  • I readded the missing functionnalities from previous releases (the AllowGroups configuration directive), and added much more (enable/disable ssh extension and service, check other configuration directives, verify the sshd is running...)

By the way, members of remotessh are allowed to connect, and members of admins too (regardless of their remotessh member status: this is cool because you (the reader) are probably already a member of admins, and you won't ever notice the sshd group-authorization enforcement ;-)

The  OpensshExtension module can serve as an extension model: it seems quite clean (and short) to me.

This work would not have been so easy without the ConfigFile class Robin wrote. I enhanced it a little, but it's so practical!!

Removed silly limitations on system groups with LDAP backend enabled

Responding to changeset 279 and explaining the reasons of changeset 304, there is now no more limitations when creating system groups.

If the LDAP backend is enabled, the newly created system group will go into the LDAP backend.

This makes NFS works perfectly on LDAP-enabled clients, which now see all groups when listings ACLs and standard posix perms.

Now, the licorn-ldap-server debian package tries to move every important pre-existing system group (acl, licorn-wmi) from the Unix backend to the LDAP one. This will implicitly install them network-wide and avoid the need to create them on every ALT®. Finally this will help propagate admin privileges on every client.

Two small changes worth noticing in add user/group

two points which were pushed in revision 279, because bzr don't know anything about cherry picking (or I don't know how to use it):

  • system users/groups are now always created in the Unix backend. this is far from perfect because they have to be replicated for ACLs to work and this will NEED to be done for the cluster, but the cluster doesn't exist yet, so don't bother. This is needed for groups like acl, remotessh and admins, which NEED to be created in /etc/group on the local system before the LDAP backend is activated (they are checked/created before the LDAP setup). This is kind of a workaround because it should work event with these groups in LDAP, but this implies some deep reorganization in the LicornConfiguration class, which will be done later (see #170).
  • add a --force argument to add user/group, for the particular case of user/group with same name. This was trigerring a bug on old debian/ubuntu systems, but should be bypassable nowadays, because I expect adduser tools to have been fixed on this particular point.