[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 -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110109214018.gw...@login1.uio.no
