create new tag
view all tags

LCFG Annual Review 2017

On Friday 8th December 2017 instead of our normal monthly Deployers Meeting (which should have been on the Thursday the day before) we will be holding our traditional Annual Review session. This will start at 2pm and we aim to be finished by 5pm. This year it will be hosted by Information Services in Argyle House, Floor E, Rooms 14 & 15.

All users of LCFG are encouraged to attend this meeting to hear about what has been happening over the last year and what developments they can look forwards to in the next year. This is also an excellent opportunity to raise issues that are important to you, put forward ideas for future developments you would like to see and chat about all things LCFG!

As is traditional the meeting will be followed by a social event and we will go for dinner somewhere. Even if you cannot attend the meeting in the afternoon you are very welcome to join us for the social event in the evening.

If you have any topics you are particularly keen to have discussed then please edit this page and add them to the General Discussion section below with a brief summary.

Core project

Final report

Component changes

This has been a fairly quiet year in terms of component changes, here is a summary of the larger changes:

New component from IS for managing MariaDB installations.

Various improvements...

A couple of important bugs resolved (bug#673 and bug#1011), also improved the robustness. Considering switching from at to systemd-run for issuing the shutdown command.

Added support for creating user home directories when they do not exist. Like useradd this will use /etc/skel but it's also possible to specify an alternate skeleton directory.

New purgecache method which can be used to completely clear the cache. This can save a lot of wasted disk space.

Rewritten into Perl and configs now generated using Template Toolkit. Other than the defaults all the LCFG managed config is now placed in /etc/sudoers.d/lcfg so that it is easier to find. It appears I might have slightly broken things for MDP users, is there a reason the standard lcfg/options/sudo.h header is not being used?

Various updates to keep up with the ever-changing mock tool. Improved support for Fedora. SL6 chroots now need the use_nspawn option to be disabled. Can now correctly specify boolean values (bug#1015)



Informatics now have approximately 20 SL6 machines remaining so testing for security updates is likely to end within a few months. It is likely that when EL 6.10 is released there will be the usual avalanche of security updates which will be backported to 6.8, that is probably the point at which all support for SL6 will be dropped.


This year has seen two minor releases - 7.3 and 7.4.


Still no sign of an alpha for EL8 and little in the way of helpful information on when this might appear. Surely we will see something in 2018? There is still the question of whether we use Centos or ScientificLinux for the next platform. Given we have had problems with recent large groups of backported packages for security updates (7.3 is really more like "7.3 and a half") would we be better off with a different approach? Would it be better to effectively "freeze" the package lists when a new minor release comes out and just cherry-pick any critical/important updates?

Upcoming Development

Next year we hope to spend time on enhancing the security of the way data is passed between the client and server. In particular we would like to improve the SSL support with an eye to being able to disable http access. We also need to do some work on improving the support for IPv6.

General Discussion

systemd timers
It might be worthwhile switching from cron to systemd timers for the jobs managed via the cron component. In particular it might be sensible for components where we don't want to try to call a method if the same service is already running.

We would like to see more bug reports! We all know about various bugs (whether trivial or important) or have features we would like to see. It would be very helpful if we could get these recorded. We can't promise they will get fixed but just having them in https://bugs.lcfg.org/ would be a great start. I propose that to make them more useful and improve response times at each monthly meeting we review all newly submitted bugs from the previous month.

Zero code components
It would be nice to make it much easier/faster to create new components. Most components do pretty much the same thing - configure a bunch of files and possibly restart a service in response to change. It should be possible to create a framework which allows us to have zero code components. We already do this to some extent by sub-classing the file or inifile components but it should be possible to take this a step further.

We would like to move the LCFG source code repository from svn.lcfg.org onto a separate host. This might provide us with an opportunity to switch revision-control system to something like git. SEE are using gitea so we could provide an interface like that. We would also like to make the LCFG code more accessible/searchable so a mirror on a hosted service such as gitlab.com would be nice, this might help raise the profile of the project. It would also be somewhere we could upload source tar files to make bootstrapping new platforms simpler.

-- squinney - 2017-10-05

Topic revision: r8 - 2017-12-08 - squinney
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback