Your Bugzilla buglist needs attention.
[This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bug tracking system (http://bugs.skolelinux.org/) that require attention. All of these bugs are in the NEW or REOPENED state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to default assignee of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW/REOPENED bugs, you can use this URL (bookmark it if you like!): http://bugs.skolelinux.org/buglist.cgi?bug_status=NEW&bug_status=REOPENED&assigned_to=debian-...@lists.debian.org Or, you can use the general query page, at http://bugs.skolelinux.org/query.cgi Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! installer ignores mirror/http/proxy preseeding -> http://bugs.skolelinux.org/show_bug.cgi?id=1458 ignores mirror/http/hostname preseed -> http://bugs.skolelinux.org/show_bug.cgi?id=1459 package firmware-linux-nonfree missing in ltsp chroot -> http://bugs.skolelinux.org/show_bug.cgi?id=1460 -- 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/e1pcww6-0006mp...@maintainer.skolelinux.no
Re: DNS broken (was: NFS4 and Kerberos: A-records for same IP inflate the need for service principals)
Hi Petter, I don't want to discuss the technical points, but: On Sun, Jan 09, 2011 at 10:40:18PM +0100, Petter Reinholdtsen wrote: > [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. > I have the greatest respect for your work and experience, and all the time you have devoted to debian-edu. Without that, skolelinux would not be where and what it is today. By calling the setup "broken", I did in no way want to decry the quality of your work. However, you blame me here for breaking stuff and caring a shit about it. The changes you probably mean can be found here, committed on 2010-11-10: http://svn.debian.org/wsvn/debian-edu/trunk/src/debian-edu-config/ldap-tools/?rev=71084&sc=1 Two days before that commit, on 2010-11-09, we had an irc meeting where we discussed how to proceed. http://lists.debian.org/debian-edu/2010/11/msg00090.html (The discussion/decision that we continue with GOsa was even earlier around 2010-10-20). In the meeting I clearly stated: "and1bm I do not have the time to work on the pdns issue (and I am not sure if it's that easy)." Already on 2010-10-29, about two weeks before the commit, I provided the solution to solve the DNS problem with packages available in Debian and minimal modifications as repeated yesterday: http://lists.debian.org/debian-edu/2010/10/msg00209.html What should I have done instead of committing the changes? Waiting for the implementation of powerDNS in general? Doesn't the commit also pave the way to start with the powerDNS implementation on the problem itself and on other improvements? [...] > > 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. If this is taken as an argument, I hope debian-edu does not evolve into some kind of "intellectual masochism-club". Please compare with my comment above. The solution was provided way in advance. If it's not acceptable and technical arguments are not really convincing (at least not for the temporary solution, if not at all), I don't see it as my job (and I clearly expressed that, see also above) to provide the solution that suits you. > I hope you will manage the same, and keep up > your good work while testing changes and ensuring that the > installation keep working. Well, I have to say that in my daily work (that started today again, btw), I have already a sufficiently high frustration potential, and I don't think it's a good idea to further increase that in my spare time. (It's already above the point where it can be seen as a good exercise to push that level). [...] > 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. I don't see the need for immediate updates. In most schools the system will be set up and not changed that often. The Debian Policy is a rather funny argument. There is a directory full of cf-rules that violates this policy. But we pick probably one of the minest issues (adding a line in a config-file that includes another file; isn't that almost .d-directory-like?) and use it to promote source-code modification of packages. Or the use of modified extra packages not in Debian. I whished we could use the time and energy spent for these discussions to work on technical problems the violation of Debian Policy (and that's the reason for the Policy) causes. However, I am looking forward to the time where powerDNS works nicely in combination with GOsa. Best regards, Andi -- 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/20110110191208.ga7...@flashgordon
Re: DNS broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09. jan. 2011 22:40, Petter Reinholdtsen wrote: > [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. if we have to add a module to do it... we could make the module work for powerdns tree mode as well. My feeling when it comes to strict mode is that while it's not "broken" acording to the DNS RFC's the multiple PTR answers are "broken" on the internet. several applications will have serious problems (like mail, kerberos and some ssl'd applications) or beeing annoying (like logging of all kinds) the added work when it comes to easier ip renumbering is worth the expence if we can get a "sane" revers lookup imho. > >> 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 >> (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,
Re: NFS4 and Kerberos
On Sat, Jan 08, 2011 at 12:31:16AM +0100, Mike Gabriel wrote: Hi Andi, On Fr 07 Jan 2011 10:41:41 CET "Andreas B. Mundt" wrote: Take a look at http://svn.debian.org/wsvn/debian-edu/trunk/src/debian-edu-config/cf/cf.homes>, i.e. our exports file. If a machine want's to mount the home directories, it first has to be added to a netgroup that allows mounting the share. So if you walk into the school with your Laptop to fake an identity on the net, it will not work the first time, because your MAC address will be differerent from the machines in the netgroup you need the membership of. The next day you walk into school you will be better prepared, you modified the Laptop's MAC. Now, just plug off the machine you got the MAC from and use your Laptop instead with the nice user ID. I guess that's how current security is thought to be. This setup is not really secure. If you have access to one of the school computers (Skolelinux clients) you boot it, use ifconfig and look up its IP. Then you shut the Skolelinux client down, take over its IP (static IP, not DHCP) and then you can mount the NFS share(s) on tjener. Inspired by your recent comment, Mike, on appreciating historical reasonings, I can shed some light on the above: Historically (i.e. 2003-2004 timeframe at least[1][2]) Skolelinux thin clients was assumed to be served in a non-hostile environment. You might find interest in (re)reading that old discussion, which also touches Kerberos (although only briefly - I had and still have too little experience in that area). My interest in raising it here is not fingerpointing but potential for enlightenment. If anyone non-scandinavian are curious about the first (heated) discussion then tell me what kind of details you are interested in and I shall try to summarize in english. Kind regards, - Jonas Very very happy to follow this current effort on integrating Kerberos! [1] https://init.linpro.no/pipermail/skolelinux.no/linuxiskolen/2003-April/009981.html [2] http://lists.debian.org/msgid-search/404d0bee.5010...@jones.dk -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: DNS broken (was: NFS4 and Kerberos: A-records for same IP inflate the need for service principals)
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
