Re: DNS broken (was: NFS4 and Kerberos: A-records for same IP inflate the need for service principals)
[Andreas B. Mundt]
> So I conclude, that the current DNS setup, as a mixture of ldap
> objects prepared for bind with extra attributes to make powerDNS
> (sort of) work, is broken.
It is not quite as you expect it to be, but I would not go as far as
claiming it is broken. It was broken and the installation failed
completely (DNS failed to look up any info in LDAP) after you replaced
the original powerdns tree with the gosa dns setup tree, but as you
have noticed, I adjusted the gosa tree to get it to work again with
powerdns.
The issues with the current setup is that there is a unused reverse
map in LDAP, and because we need several A records to point to
10.0.2.2 and we use powerdns in strict mode, we get several PTR
records from 10.0.2.2 pointing to the names we need A records for.
Nothing really serious so far, but the Kerberos requirements might
make these a bit more problematic.
> In addition, there is absolutely no use of GOsa with regard to DNS,
> as modifications are not accepted by GOsa with the added powerDNS
> attributes.
Unless we add our own gosa module (or adjust the existing module) for
updating DNS with the two extra attributes. Should not be too hard.
I had a look at the source, and suspect it should be possible to get
working in a day or two. Have not been able to find the two spare
days so far, but hope someone will in time for squeeze.
> With such a system, it's extremely hard to stay motivated, because
> you waist your time fixing things that are "known not to work
> properly" instead of really being able to test new things.
Yes, but I managed to stay motivated anyway, even if you broke the
installation by inserting a DNS LDAP tree that did not work with the
packages we install. I hope you will manage the same, and keep up
your good work while testing changes and ensuring that the
installation keep working.
> I propose three choices:
>
> 1) We move powerDNS to its own tree (as before) and switch of the
> "systems"-stuff in GOsa. This means we don't have a GUI to make
> changes, but hopefully a working DNS again that doesn't block all
> other activities.
>
> 2) We drop powerDNS and give bind a try. This means merely installing
> bind instead of powerDNS, appending a line to a configuration file and
> touching another one [1]. Regarding the simplicity, it could also be
> considered as an intermediate solution until we have something else.
Both these options have their own set of problems, and I would rather
see work done on this option:
> 3) Someone has time and volunteers to cooperate with Alejandro
> (<URL:http://lists.debian.org/debian-edu/2010/12/msg00117.html>) to
> implement powerDNS in GOsa properly. This should happen soon, because
> the current broken system only leads to frustration.
Part of the reason we went with powerdns is that it fetches
information directly from LDAP, so changes done to LDAP take effect
imediately. A reason we moved the DNS from files to LDAP is to allow
dynamic updates of DNS information without having to edit other
packages conffiles to easy upgrades and stay within the Debian policy
requirements. It is also the DNS server used by the Extremadura
installation, and we belive their claims that powerdns scale better.
They have >80 000 clients using powerdns. The reason I switched
powerdns to strict mode was to make it easier to change the IP range
used. We used the non-strict mode earlier, with separate forward and
reverse entries in LDAP.
The script /usr/share/debian-edu-config/tools/subnet-change in
debian-edu-config handle this transformation (changing the subnet)
already, but there are a few files in /etc/ left to edit and more
testing to be done before it is complete. Also, I started to suspect
it would be better to adjust this during installation by adding a
filter to the LDAP loading process, and thus am unsure if the design
is the correct one.
I believe we should ensure that all of these features are kept when we
consider our DNS setup. The bind setup uses regular dumps from LDAP
to files, thus adding a delay from DNS changes are done in LDAP to the
show up in DNS. It also make it a lot more complex to change the
subnet used as both forward and reverse maps need to be rewritten, and
rewriting the reverse maps require moving LDAP subtrees to different
names.
As for NFS4 and Kerberos, we do not really want to authenticate hosts,
we want to authenticate users, to ensure home directory mounting also
work on the stateless diskless clients. If we can't get this working,
we might have to look at other solutions for home directory mounting,
as we can't really drop the diskless workstation feature. :/
Happy hacking,
--
Petter Reinholdtsen
Reply to: