[debian-lan-devel] When I shoot myself in the foot with a softupdate

[Andreas B. Mundt]

Hi Julien,

On Fri, Jul 12, 2013 at 05:42:46PM +0200, Julien Lambot wrote:

> I'm working on the update of debian-lan version 0.12
> The release that I installed was the one available around end of April.
>
> The recommendation you gave earlier were already helpful. Some scripts are
> already slightly modified to include a "DLUpdate=true" environment variable
> to allow executing fai -Nv softupdate correctly.
[...]
>
> Though, during the update process I'm facing an issue with Kerberos, slapd
> and nslcd, which I still can't correctly identify.
> This translate into the fact that the session is opened and directly closed
> on the workstation.
> The krb5.keytab of the workstation was correctly transfered. However it
> seems to remain an inconsistency in Kerberos.
> I still have to test the fix for fai/config/scripts/DNS_SERVER/10-zones in
> the logs hereafter (which might be the cause of the problem, indeed)
>
> from kdc.log
> Jul 12 16:06:14 mainserver krb5kdc[2847](info): preauth
> (encrypted_timestamp) verify failure: Decrypt integrity check failed
[...]
>
> Thereby, since there is a change in slapd certificates location, there was
> an issue with TLS wich is mostly fixed (within ldap.conf, slapd.conf and
> nslcd.conf.)
> I can successfully execute the following command (as root and without
> kerberos ticket)
> ldapsearch -x -b "dc=intern" -H 'ldap://ldap/' -ZZ
> but I can't do a kinit for root. This results in :
> root at mainserver:/var/log# kinit
> Password for root at INTERN:
> kinit: Password incorrect while getting initial credentials

Can you check with a normal user?  I am not sure about root's kerberos
password here.  I think the root password is only locally available
(from /etc/shadow), and not set in the KDC, if not set by hand.

>
> Any hint would be greatly appreciated.
>

If the DNS setup is not working propperly, kerberos fails too.  You
can try without propper DNS by defining the domain in
/etc/idmapd.conf:
                  Domain = intern

By default, this is taken from the DNS FQDN of the host, if DNS fails
for some reason, it is needed.  The log line:
    Jul 12 16:04:55 workstation00 rpc.idmapd[1564]: nss_getpwnam: name 'nobody' does not map into domain 'intern'
points to that issue.

>
> On the other side of the force :)
> If we look at the above, updating from one release to another is not an
> easy process.
> Could we consider to put a "debian-lan.release" containing the release tag
> in /etc in order to ease the updates. This file could then be tested by the
> scripts for the necessary updates.
> I suppose there should be a good way to use some git features to create
> patches or simply add checks in the scripts. I'm a beginner on the git
> part, so any advise is welcome.
> What would be your preference?

I think it causes a lot of work to make the config space 'upgradable'.
It's easy if a new class is added or a new machine type, but for
involved changes like DNS, DHCP or LDAP it is really hard to do, as
changes would have to be made on the System already modified by the
user (DNS/DHCP entries, LDAP data base).  I don't think we can and
want to  apply ldifs to the LDAP tree to modify it after the
installation for example.
We need to mostly freeze the developement of a installed system and
only us the standard Debian packet update system.  Debian-LAN provides
the 'architecture' of the system, and it's hard to change that after
the system is set up.  In some cases it might work - like for the
clients which can be reinstalled or a package/class in addition.
But on the level of fundamental services, we cannot migrate to a later
config space by default.

Unfortunatelly, with the modification of the DNS/DHCP setup (which in
the end simplifies the setup, as machines are handled only in the
DHCP configuration) rather fundamental changes have been made (only
LDAP would be worse).  I guess the best thing to do is to fix your
setup by hand now and start with the latest config space for all
future installations.  After installation, only cherry-pick from
further modifications of the config space.

> How can I provide you with the corrections I already implemented within my
> git repo.
> In a clue:
> I made a copy of my current install's configuration, created a repository
> (say: DLCustomer)
> I cloned the current branch in another repository (say: debian-lan) and
> compared the first one with this one
> Then, all changes have been made in a branch DLCustomer/DLupdates.
>
You can make a diff of the two branches (git help diff):

       Comparing branches

               $ git diff topic master    (1)
               $ git diff topic..master   (2)
               $ git diff topic...master  (3)

           1. Changes between the tips of the topic and the master
           branches.
           2. Same as above.
           3. Changes that occurred on the master branch since when
           the topic branch was started off it.

[...]

OK, so far for now.  Please keep us up to date if the above
(idmapd.conf, DNS) helps in order to make your system working fine
again.

Best regards,

     Andi