Hi Petter, hi Andi, On So 09 Jan 2011 22:40:18 CET Petter Reinholdtsen wrote:
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.
It is always good to know the history of choices and decisions... I do get Petters point here.
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.
As I have not been up-to-date concerning an already existing subnet-change script, I think we should not at all break this. Any means for IP-flexibility should be kept in SL.
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.
[So the next paragraph has become a little commercial add-in, but may be the info might be helpful to one or another person...]
I am not quite sure how you approach LDAP changes in SL. I may make you aware of a Python module I have once written (and would like to see continued):
python-easyldap (http://das-netzwerkteam.de/site/?q=node/73)Python easyLDAP unfortunately has become a bit abandoned currently and is not at all ready for Debian ITP, yet... However, with Python easyLDAP you can e.g. bind to an LDAP subtree, rename the subtree base DN and it consequently rewrites all child node DNs (i.e. moves the subtree within the LDAP DIT). The last project I used it for was an ,,Active-Directory-to-LDAP-,,partial-synchronization''-script (customer project).
As I am currently working on a Python X2go implementation (http://das-netzwerkteam.de/site/?q=node/71) I will need LDAP support in the near future for Python X2go and this will probably continue my work on easyLDAP. As I am planning to file an ITP for Python X2go in the near future, there will consequently be an ITP for python-easyldap some time in the future, as well.
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. :/
Here is another idea about the host/service principals...If the number of diskless clients is endless then there could be a prepared NFS service principal for each diskless client provided ready-for-use in LDAP.
One diskless client then could boot with its own KADMIN/KDC service which then has access to the LDAP tree. With local Kerberos services it might be easier to derive the service principal keytabs from LDAP (by calling kadmin.local). Just a blind shot, though, never done that before...
Mike -- DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419 GnuPG Key ID 0x1943CA5B mail: m.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
pgp3JScMtCTsA.pgp
Description: Digitale PGP-Unterschrift
