Project 314 - Services Unit Desktop SL7 work

See project description at, but basically make sure that whatever the Services Unit is responsible works on the forth coming SL7 desktop.

We reckon this boils down to:

  • AFS client
  • mail component
  • CUPS client
  • rsync component

Fortunately AFS and mail client have been taken care of by the work done by the MPU. However we will just double check things are working as expected. Leaving just CUPS and rsync as the main work.

The first step will be to get a EL/SL7 machine to work on.

Summary Status and Actions

component status MPU informed Notes
AFS client done yes basically works, but should look at unit file for better integration with systemd
mail done yes Checked behaviour and changes made by cc
CUPS client ongoing no  
rsync done yes  
rmirrorclient done yes has dependencies on kstart and components remctl and kerberos
autofs ongoing no replacement for amd

Actions from dev meetings or similar

  • Automounter - Craig
    • [ACTION] Agreed maps to perpetuate and how and those to delete, will document what was agreed.
    • [ACTION] Maps will stay in LDAP as before but will implement an RFE trigger to propogate.
  • AFS - Neil
    • [ACTION] investigate changing AFS component to use systemd unit config and starting daemon via systemd
    • [ACTION] inform MPU when port of a component to SL7 is complete (so they can make dice header available)
    • [ACTION] review components for whether now (port to SL7) is a good time to split into client and server instances
      • It is a good idea to split, but I doubt we'll prioritise time to do it for SL7.

Activity 30/9/2014

The first thing to do was to create an EL/SL7 machine for us to work on. Stephen from the MPU had prepared several circlevmX profiles, so we took circlevm2 as our machine to test on. The minimal LCFG looks like:


#include <inf/os/el7.h>
#include <inf/hw/kvm.h>
#include <inf/options/server.h>
#include <inf/options/serialconsole.h>
#include <live/wire_at1.h>

!profile.release mSET(develop)
dhclient.mac            52:54:00:13:c6:02

Installing the VM with these resources, gives you a machine that connects to DICE LDAP and some of the kerberos infrastructure, but as it doesn't register the host with the KDC (you're not prompted for your admin principle during the install) you have to give your DICE password when you ssh to it.

That's as far as we've got so far. A quick check seems to confirm that mail and AFS are working as expected. The next thing will be to look at CUPS, as it is more important than rsync.

Activity 1/10/2014

At the this mornings Dev meeting, it was suggested that we consider splitting openafs into two components, client and server, though not necessarily in time for SL7.

Also, looking at, we can see that there is a systemd "unit" file for openafs. We should look at perhaps using that (what ever it is! - must do some reading on systemd).

Craig is going to look at cups, I (Neil) will look at rsync.

Activity 22/10/2014

Added the dice/options/rsync.h header. It didn't "just work", profile compiled OK, but perhaps unsurprisingly, it didn't find the rsync component RPM. Perhaps more surprisingly is that there is a 2.2.10 version available, but the header is looking for 2.2.9 (the SL6 current version). 2.2.10 was created when Chris mass built all the component RPMs for EL7. Forcibly installing that version of the RPM, and it does "just work". Again thanks to the MPU (Stephen) updating lcfg/defaults/rsync.h to use systemd stuff rather than for EL7.

I plan to make 2.2.10 the default version for SL6 (and SL7) so that things are consistent. Actually it will be 2.2.11 after I submit a version with Stephen's latest fixes for post install and "isstarted" changes. Note to self pkgforge submit -B lcfg -p sl6,el7 SRPM_FILE to build both sl7 and el7.

Also, in hindsight, it would probably be better to make sure the rmirrorclient-SITE.h headers work for EL7, rather than just the rsync component (which the rmirrorclient headers use). This will mean checking the rmirrorclient component on EL7 too.

The rmirrorclient component and headers now basically work for EL7. Unfortunately I can't test the "report" method as it needs k5start, which seems to be missing at the moment.

Activity 31/10/2014

Managed to do a little bit of work, to convince myself that the report method would work if the surrounding k5start and remctl stuff it needs was there. After a bit of realisation that "whererpms" no longer gives meaningful results on SL7 (look at fixing that some other time) I manually installed kstart-4.1-1.inf.x86_64 and remctl-3.9-2.el7.x86_64. And copied /etc/mreport.keytab from jings. After doing that "om report report" ran.

[root@circlevm2 neilb]# om rmirrorclient report
SUCCESS circlevm2::test on Mirrored recently
[OK] rmirrorclient: report

Activity 12/1/2015

Looking at systemd "unit" file for afs client. The openafs-client RPM ships /usr/lib/systemd/system/openafs-client.service which looks like the right thing. Now what do you do with it? If the unit file is responsible for starting and stop the daemon, how does this affect component start/stop/configure calls?

It looks like currently the service lcfg-openafs.service is enabled that does the usual component start/stop/reload as required. And though systemctl list-units shows the openafs-client.service as loaded and active, it isn't actually enabled according to systemctl list-unit-files or systemctl is-enabled openafs-client.service, but again "status openafs-client.service" seems to give conflicting info, eg it is loaded disabled, and active (running). Perhaps it's is just smart enough to see the afsd process running.

So if the plan is to "disable lcfg-openafs.service" and "enable openafs-client.service" what will happen if the component gets a "configure". Will it be happy to do what's necessary even if it wasn't started by the component Start method? I presume this is the significance to the "IsStarted" LCFG method from last year.

Notes: Alastair's slides linked from, a systemd cookbook is developing

Activity 21/1/2015

Last week Stephen added

to lcfg/options/openafs-client.h, so that the client unit file is now used explicitly.

As we now seem to have an SL7 desktop, I may try upgrading my desktop - jings.

Activity 10/2/2015

Not sure if this actually counts as activity towards this project, but yesterday I re-installed my desktop as SL7. It's not a drop-in replacement, yet, and there are some issues. I'm keeping a note of some of those issues on my blog at but also discovered the RAT unit page SL7DICEEnvironment.

Activity 11/2/2015

Just so I have a note, these are the RPMs I built and/or installed for a nearly working fvwm on SL7.

!profile.packages       mEXTRA( \
        +dice-fvwm-startup-1.2.0-1 \
        +dice-dcs-Xstartup-1.1.1-1 \
        +fvwm-icons-20060712-2/noarch \
        +fvwm-2.6.5-9.inf.1 \
          +perl-File-MimeInfo-0.21-1.el7/noarch \
            +perl-File-DesktopEntry-0.08-1.el7/noarch \
            +perl-File-BaseDir-0.03-14.el7/noarch \
          +fribidi-0.19.4-6.el7 \
          +xlockmore-5.45-1.inf \
          +pyxdg-0.25-5.el7/noarch \
        +xcal-4.1.p95-4.1.inf )
However I've now moved them to (hopefully) the correct package lists, namely:



Activity 24/2/2015

No component specific SL7 activity, but I've been using SL7 for a couple of weeks now as my desktop, and adding missing RPMs as I need them.

Recently became aware of a problem that's been noted already, about the openafs component not coping correctly with the afs daemons being started by systemd. The problem only really is noticed after the install of a new SL7 machine, afs does not work as expected. This is because the various configuration settings in LCFG have not been turned into the corresponding config files in the filesystem (/usr/vice/etc/). The problem seems to be that systemd starts the afs daemons, then the component thinks about starting (and creating the config files), but doesn't as it sees the daemon already there. But the daemon are running without our cell config. Once this has been spotted and the component force-ably started/configured the config files are then created. Subsequent reboots suffer the same problem of the daemons being started, but not the component, but generally you don't notice anymore, as the configuration files are now in place.

I need to speak to Stephen to see if this behaviour is for us to fix, or if it's systemd related and therefore MPU.

Activity 8/3/2015

On Friday Stephen spotted an issue with the mail component on SL7. It seems similar to other gotcha's we've been missing. systemd was starting the sendmail daemon before the component was started. Due to the code in the Configuire() method at the time, this meant that the running sendmail was not told of the new (at first boot) sendmail configuration. This meant that sendmail would be running with the OS default configuration, which was to deliver mail to local inboxes in /var/spool/mail/. Following the next reboot, the daemon would find the LCFG sendmail config and work as we'd expect. But again due to the ordering any LCFG sendmail changes would not be picked up until a reboot or sendmail happened to be restarted.

The logic and checks in the Configure() method have now been changed to cope with the daemon already running, even though the component may not have yet been started.

While looking at this problem, it was also noted that template file changes were not being spotted. This was due to a little known "skip section" markup <%{%>this_bit_ignored<%}%> that was inserted by the component code. This no longer works reliably, and won't be fixed due to LCFG Template being deprecated. The fix for now was to just remove this markup.

Finally the mail logrotate.cin template seems to have re-materialised, when it was supposedly removed years ago, this mean it was missing some extra directives that the ngeneric logrotate gives you for free, the template was removed and standard ngeneric resources used instead.

Activity 29/3/2015

I think Craig and I believe that the Unit specific bits of SL/EL7 for the Desktop are complete (if that is indeed the case Craig, then we should update the status table at the top of this page) . Therefore we should see about doing whatever is necessary to get this project marked as complete and signed off.

-- NeilBrown - 30 Sep 2014

Topic revision: r14 - 29 Mar 2015 - 22:09:17 - NeilBrown
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies