TWiki> DICE Web>Project312InfSL7 (revision 12)EditAttach

inf-unit initial SL7 work

Project description

There's some inf-unit work required in order to get the DICE SL7 port up and running, specifically making bare minimum desktop/client versions of the LDAP, DNS and Kerberos LCFG components.


Functional DICE SL7 LDAP, DNS and Kerberos


The project description is quite vague. We'll attempt to track here all the parts and sub-parts required to produce our deliverables.

All components

  • Inform MPU when port of a component to SL7 is complete (so they can make dice header available)
  • Review components for whether now (port to SL7) is a good time to split into client and server instances


  • build/test lcfg-openldap
    • modify for new Service() function in ngeneric
    • remove half-hearted attempt to manage caching daemon
    • make sure client side operation works correctly
    • longer term, think about split into client/server components
  • build/test latest openldap packages
  • get current default client set up (slaprepl-slave) working
    • build/test openldap-schema
    • build/test slaprepl
  • sssd
    • configure for systemd
    • test service discovery configuration
    • test lcfg-inifile component suitability for sssd.conf
    • write new component if required
    • test tls certificate change procedure
    • test load-balancing
    • test failover


  • build/test lcfg-kerberos
    • modify for new Service() function in ngeneric
  • build/test kdcregister
  • test client-side startup (creation of hostclient principal, etc.)


  • EL7 version of bind is 9.9.4
    • some configuration defaults have changed
    • component may need additions for these, backward-compatibly
    • defaults for any new configuration options need checked
  • is distributed init-script suitable?
    • can we convert to use it backward-compatibly
    • what if it doesn't do all we need?
  • chroot??
  • fallback position is to continue with lcfg-resolvconf
    • SL6 operation is more important at the moment
    • breaks trusted path between resolver and stub-resolver in glibc


It might make some sense to refactor the component so that it uses the standard thing-starting mechanism, with us just generating a configuration file. However we do need to take into account the way the current component allows for the use of ntpdate through the Run() method instead, and knows how to manage the two options without conflct.


Desktop machines would be expected to run router discovery. There's no configuration actually required for this, so there's probably a case for just using the standard stuff directly. Routers could then use the lcfg-routing component instead as required. (There's presumably also some RIP support in the distribution, which non-routers at other sites could use as required.)

Update 2014-09-26

Note that, despite the name of the project, all current work is being done on EL7 (SL7 isn't out yet).

All testing has been taking place on circlevm3.

Note that all components have required the lcfg-build-deps change.


openldap RPMs have been built for EL7 (version 2.4.39-3.inf).

Our plan for LDAP client configuration under EL7/SL7 is to run standard desktops in TLS client/server configuration, using sssd to provide caching. See discussion paper and the minutes from the discussion.

The standard DICE client set up, where the host runs a full version of slapd, with hourly replication using slaprepl, has been ported and tested and seems to work correctly.

Most of the investigation work so far has been with sssd. We have a working client-side configuration, talking to LDAP servers tlsdirx[01].

sssd.conf is currently being configured via the file component. IS have a component to manage ini-style syntax configuration files (lcfg-inifile). As sssd uses this syntax, it seems sensible to test whether lcfg-inifile can be used to manage sssd.conf, rather than writing a custom component.

A devel version of lcfg-openldap is being used - it's hard-coded to restart sssd, rather than nslcd, using Service(). As mentioned in the plan above, we intend to remove all management of caching/connection daemons from the openldap component. This will remove the need for the use of Service() in lcfg-openldap.

In previous tests using service discovery (DNS SRV records) with sssd, failover was found not to work correctly. This is down to this upstream bug. We have back-ported the patch to the version of sssd on EL7 (sssd-1.11.2-65.el7). It seems to now failover correctly.


The version of krb5 on EL7 is currently 1.11.3-49.el7.

A devel version of lcfg-kerberos has been built and seems to populate configuration files correctly.

On starting the component with client-side resources, appropriate hostclient, etc. principals are created (kdcregister had already been ported (thanks mpu)).

Client-side kerberos seems to be largely complete, pending a properly built version of the component and headers.

Update 2014-11-12

We have a working openldap/sssd client configuration and a working kerberos client configuration. This has been added to the dicehacks.h header for testing. e.g.

#include <inf/options/dicehacks.h>

Update 2014-11-13

Two new blog posts talking about kdcregister and openldap/sssd:

Update 2015-02-13

We have added a wrapper script (thanks Stephen) to kdcregister to protect against mistyping principal name or password during a machine install. This is in kdcregister-1.19.0-1.

We have also written a new sssd component which sub-classes lcfg-inifile. Details here:

Update 2015-03-03

Current status:

  • Kerberos - client side done
  • LDAP/sssd - client side configuration done; need to test certificate change failover; need to add servers to pool
  • routing - router discovery working, others still to be built and/or tested
  • dns - works when started by hand, needs integration testing
  • ntp - working

Are routing and dns sequenced properly? routing should wait for a working network, dns should wait for routing, and everthing else should wait for dns.

Update 2016-05-17

  • DNS: potential fix is in the component now, but needs hooked in to systemd and tested. Discussions with MPU likely to be required.
  • iptables: working sufficiently for the lab exams. Needs systemd integration tidied up.

Both of these will be progressed now that the lab exams are (mostly) over.

It's still unclear whether the start-ordering of components and daemons is correct. There are definite dependencies which may not be accurately captured in the current configuration.

-- TobyBlake - 04 Mar 2015

Edit | Attach | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r12 - 17 May 2016 - 11:13:58 - GeorgeRoss
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