Bug#311188: Draft proposal for handling configuration file manipulations in Debian blends
On Thu, Jan 26, 2012 at 04:27:40PM +0100, Jonas Smedegaard wrote: On 12-01-26 at 12:24pm, Mike Gabriel wrote: I am talking about each single Debian package. Not the whole system. And every package in this model can be in non-blended mode or in blend mode for _one_ blend. Thanks for the clarification. I just work down my backlog after traveling to Southport where we have the second Debian Med sprint and followed your interesting discussion. Example: if we install d-e-c, we have to tweak apache2 configuration. For this we would set apache2 into ,,edu'' blend mode. If apache2 is in ,,edu'' blend mode it cannot be set into ,,gis'' blend mode etc. You can unblend apache2 and blend it with some other blend only then. My opinion about having two (or more) Blends cooexisting on one machine we need to differentiate between practical application and theoretical implementation. I doubt that there is any *existing* machine which has a need to have a real need to install two or more Blends and its configuration files. This doubt is based on the fact that currently only Debian Edu provides specific configuration at all (which probably will change in the future). However, I would really love to see the chance to enable the peaceful coexistence if possible at all so in other words I think we should care for an implementation which enables the theoretical chance to install more than one Blend on one machine. So if edu wants to tweak a single option and gis wants to tweak a single _other_ option, those two tweaks cannot both be applied if edu and gis both use your proposed mechanism? Seems bad design to make blends mutually exclusive at the core of the blend mechanism. Sure it might be sensible for one blend to conflict with another, but some blends might go well together, so should not technically be hindered in doing so by the underlying mechanisms IMO. BTW, it might perfectly be the case that two Blends need the very same change in the config and can not coexist just because we found a mechanism which excludes two Blends on one machine. This would be an unnecessary restriction. Makes sense for me that a blend maintains _what_ should be tweaked, but _how_ it is tweaked is better maintained by the package maintainer than blend maintainers or dpkg maintainers IMHO. ACK When a blend includes full config files or scripted config tweaks then the package _maintainers_ are kept out of the loop of _maintaining_ those config choices, and the config options are not offered individually by Debian, e.g. for tools like piuparts to regression test in automated ways. I highly recommend to instead help make it easier for package maintainers to implement and _maintain_ config handling. ACK I believe that if it was easier to implement and maintain debconf interfaces to config files, we would have less of a problem convincing them to offer config options for the tweaks we need for various blends. Specifically I believe that work to integrate debconf with Config::Model could help improve the situation. More on Config::Model here: http://wiki.debian.org/PackageConfigUpgrade I also would like to add the following: Mike's suggestion needs some dpkg/apt/whatever coding first. It does not help to make good suggestions if you will not come up with patches which you tested for some time and than make the maintainers of this core functionality accepting these patches. This is not an easy job and according to my experience this takes ages. I'm comparing with how long it took to make apt aware about description translations - and translations is a feature about 50% of all Debian users might really *want*. Unfortunately we need to realise that Blends is - like it or not - a quite unknown topic in the Debian universe even if I try my best to talk about it at any DebConf and other events. I like to quote Peter Eisentraut: You are talking about something which does not exist. Well, it is not that drastical, but changing the Debian infrastructure on behalf of the needs of Blends is at current state not realistic. However, if we are talking about #311188 I think what we could try to approach is making config issues of Blends RC critical and thus making the bugs we filed against those packages RC critical which in turn would enable us NMUing packages of maintainers which are not willing to help us otherwise. I know that's also not very nice but would solve the problem we are facing and is way more realistic to be solved until June (suggested freeze time). I am pretty sure that anyone interested in blending would be excited if you invent/refine needed mechanisms for above two needs. ...if done Policy compliant - which does *not* mean weaken Policy but (understand reasons for and) obey Policy. I am less sure that anyone else will volunteer to do the work for you, if that's what you are asking. Personally I would not, because I cannot imagine
Re: Thoughts on roaming laptop setup for Debian Edu
[Petter Reinholdtsen 2010-07-10] * The wicd package is installed (instead of network-manager). Not sure if this is a good idea or not, but the report from Extremadura made me put it in there as a test. Based on todays tests, I am starting to suspect it might be better to use network-manager. I installed a roaming workstation using PXE in a Debian Edu/Squeeze network today, and the installation worked fairly well (partition size issues - updated d-e-install with new sizes). After installation, I can log in with the first user, and a local home directory is created and used after I log in for the second time. I can disconnect the network cable and still log in using cached credentials. All good so far. But, when I try to connect to the wireless networks around me, wicd do not see anything. I had to manually configure wicd to use wlan0 as the wireless interface to be able to see the wireless networks. And when I try to select the non-encrypted network I want to use, I am unable to get any IP address. After removing the wicd package and installing the network-manager-kde instead to get a KDE panel widget to control network-manager, I am able to connect to the wireless network. Anyone want to debug wicd in this setup, or should we just switch to network-manager on Roaming Workstation profiles? Possible advantages: - It will discover wireless interfaces without any configuration. - Roaming Workstation will use network manager the same way Standalone (and all other profiles?) do it now. Possible problems - Roaming Workstation will not work for new users because the network is not enabled at boot but only after first login, and thus no connection to LDAP and Kerberos can be made. The problems I see might be because wicd and network-manager are confusing each other. I did not have much time to debug. -- 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/2flzkd92y2z@diskless.uio.no
Re: Thoughts on roaming laptop setup for Debian Edu
I also would argue that wicd is fairly less efficient than network manager. I've tested it recently on an fresh Wheezy-XFCE but at school I wasn't able to connect and had to replace it with n-m. Cheers Giorgio On Fri, Jan 27, 2012 at 12:18:12PM +0100, Petter Reinholdtsen wrote: [Petter Reinholdtsen 2010-07-10] * The wicd package is installed (instead of network-manager). Not sure if this is a good idea or not, but the report from Extremadura made me put it in there as a test. Based on todays tests, I am starting to suspect it might be better to use network-manager. I installed a roaming workstation using PXE in a Debian Edu/Squeeze network today, and the installation worked fairly well (partition size issues - updated d-e-install with new sizes). After installation, I can log in with the first user, and a local home directory is created and used after I log in for the second time. I can disconnect the network cable and still log in using cached credentials. All good so far. But, when I try to connect to the wireless networks around me, wicd do not see anything. I had to manually configure wicd to use wlan0 as the wireless interface to be able to see the wireless networks. And when I try to select the non-encrypted network I want to use, I am unable to get any IP address. After removing the wicd package and installing the network-manager-kde instead to get a KDE panel widget to control network-manager, I am able to connect to the wireless network. Anyone want to debug wicd in this setup, or should we just switch to network-manager on Roaming Workstation profiles? Possible advantages: - It will discover wireless interfaces without any configuration. - Roaming Workstation will use network manager the same way Standalone (and all other profiles?) do it now. Possible problems - Roaming Workstation will not work for new users because the network is not enabled at boot but only after first login, and thus no connection to LDAP and Kerberos can be made. The problems I see might be because wicd and network-manager are confusing each other. I did not have much time to debug. -- 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/2flzkd92y2z@diskless.uio.no -- Sysadmin SPSE-Tenero Ufficio: +41 91 735 62 48 Cellulare: +41 79 629 20 63 -- 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/20120127140121.ga3...@ticino.com
debian-edu-config_1.449~svn75814_i386.changes ACCEPTED
Accepted: debian-edu-config-gosa-netgroups_1.449~svn75814_all.deb to pool/local/d/debian-edu-config/debian-edu-config-gosa-netgroups_1.449~svn75814_all.deb debian-edu-config_1.449~svn75814.dsc to pool/local/d/debian-edu-config/debian-edu-config_1.449~svn75814.dsc debian-edu-config_1.449~svn75814.tar.gz to pool/local/d/debian-edu-config/debian-edu-config_1.449~svn75814.tar.gz debian-edu-config_1.449~svn75814_all.deb to pool/local/d/debian-edu-config/debian-edu-config_1.449~svn75814_all.deb Override entries for your package: debian-edu-config-gosa-netgroups_1.449~svn75814_all.deb - extra local/misc debian-edu-config_1.449~svn75814.dsc - extra local/misc debian-edu-config_1.449~svn75814_all.deb - extra local/misc Announcing to comm...@skolelinux.org Thank you for your contribution to Debian-Edu/Skolelinux archive. -- 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/e1rqlsu-0006cf...@administrator.skolelinux.no
debian-edu-install_1.524~svn75816_i386.changes ACCEPTED
Accepted: debian-edu-install-udeb_1.524~svn75816_all.udeb to pool/local/d/debian-edu-install/debian-edu-install-udeb_1.524~svn75816_all.udeb debian-edu-install_1.524~svn75816.dsc to pool/local/d/debian-edu-install/debian-edu-install_1.524~svn75816.dsc debian-edu-install_1.524~svn75816.tar.gz to pool/local/d/debian-edu-install/debian-edu-install_1.524~svn75816.tar.gz debian-edu-install_1.524~svn75816_all.deb to pool/local/d/debian-edu-install/debian-edu-install_1.524~svn75816_all.deb debian-edu-profile-udeb_1.524~svn75816_all.udeb to pool/local/d/debian-edu-install/debian-edu-profile-udeb_1.524~svn75816_all.udeb Override entries for your package: debian-edu-install-udeb_1.524~svn75816_all.udeb - optional local/debian-installer debian-edu-install_1.524~svn75816.dsc - extra local/misc debian-edu-install_1.524~svn75816_all.deb - extra local/misc debian-edu-profile-udeb_1.524~svn75816_all.udeb - optional local/debian-installer Announcing to comm...@skolelinux.org Thank you for your contribution to Debian-Edu/Skolelinux archive. -- 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/e1rqlsv-0006ew...@administrator.skolelinux.no
Re: Change IP - LDAP and DNS
[Giorgio Pioda] Hi Petter, Hi. :) I'll do some test in the next weeks. I've got today a clean Mainserver running in qemu. A couple of times the installation hanged, thus I removed the thiny client server option. Was the LTSP progress bar at 85%? If so, it isn't hanging, it is just using a long time. It is installing ~3 GB of compressed software into the chroot, and this take a while. :) On a test laptop I installed today, this step took almost 34 minutes. :) Next I'll install a client workstation in qemu and I'll begin to play with the configs. I'll take your assist if needed, Thanks again. I look forward to hear what you have figured out. Perhaps we see you on IRC? Putting debian-edu@ back on the to list, to make sure everyone understand that hanging at 85% is normal. -- 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/20120127142328.ga1...@login2.uio.no
Bug#657474: debian-edu-artwork: leaves diversion after upgrade from squeeze
tags 657474 pending tags 657474 patch thanks Hi, I've prepared an NMU for debian-edu-artwork (versioned as 0.0.33-2.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Thanks. -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane diff -u debian-edu-artwork-0.0.33/debian/changelog debian-edu-artwork-0.0.33/debian/changelog --- debian-edu-artwork-0.0.33/debian/changelog +++ debian-edu-artwork-0.0.33/debian/changelog @@ -1,3 +1,12 @@ +debian-edu-artwork (0.0.33-2.1) unstable; urgency=low + + * Non-maintainer upload. + * debian/debian-edu-artwork.prerm +- fix leaves diversion after upgrade from squeeze + (Closes: #657474) + + -- Hideki Yamane henr...@debian.org Fri, 27 Jan 2012 23:51:20 +0900 + debian-edu-artwork (0.0.33-2) unstable; urgency=low [ Andreas B. Mundt ] diff -u debian-edu-artwork-0.0.33/debian/debian-edu-artwork.prerm debian-edu-artwork-0.0.33/debian/debian-edu-artwork.prerm --- debian-edu-artwork-0.0.33/debian/debian-edu-artwork.prerm +++ debian-edu-artwork-0.0.33/debian/debian-edu-artwork.prerm @@ -5,7 +5,13 @@ -#DEBHELPER# - case $1 in remove) -/usr/share/debian-edu-artwork/update-artwork remove +# avoid puring problem with version in squeeze +if dpkg-divert --listpackage /usr/share/desktop-base/grub_background.sh.orig /dev/null; then + dpkg-divert --package debian-edu-artwork \ +--rename --remove /usr/share/desktop-base/grub_background.sh +fi + +/usr/share/debian-edu-artwork/update-artwork $1 ;; esac + +#DEBHELPER#
Processed: Re: debian-edu-artwork: leaves diversion after upgrade from squeeze
Processing commands for cont...@bugs.debian.org: tags 657474 pending Bug #657474 [debian-edu-artwork] debian-edu-artwork: leaves diversion after upgrade from squeeze Added tag(s) pending. tags 657474 patch Bug #657474 [debian-edu-artwork] debian-edu-artwork: leaves diversion after upgrade from squeeze Added tag(s) patch. thanks Stopping processing here. Please contact me if you need assistance. -- 657474: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657474 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13276785844499.transcr...@bugs.debian.org
Processing of debian-edu-artwork_0.0.33-2.1_amd64.changes
debian-edu-artwork_0.0.33-2.1_amd64.changes uploaded successfully to localhost along with the files: debian-edu-artwork_0.0.33-2.1.dsc debian-edu-artwork_0.0.33-2.1.diff.gz debian-edu-artwork_0.0.33-2.1_all.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- 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/e1rqnt7-0005ar...@franck.debian.org
Diskless clients: NFSv4 mounting with sec=krb5p and no machine creds
Hi everybody! Since quite some time we have been thinking about how to make kerberized NFSv4 mounting of home directories work with diskless clients, where no machine credentials (keytab) are available. It was mentioned [1] that using -n for gssd on the diskless client might help, however this seems not to be enough. I finally figured out a way now, which works here and is not too invasive: First, make sure you have the package libpam-script available at the diskless client's chroot. libpam-script allows to run a script after successfull authentication. The script executed can be created by running: #!/bin/sh # set -e FILE=/usr/share/libpam-script/pam_script_auth cat $FILE EOF #!/bin/sh # set -e if [ \$PAM_USER = root ] || ls /tmp/krb5cc_diskless /dev/null 21; then exit 0 fi FILE=/tmp/krb5cc_diskless cp -v /tmp/krb5cc_pam_* \$FILE /etc/init.d/autofs restart /dev/null exit 0 EOF chmod 0755 $FILE # The script executed right after authentication copies the user's Kerberos ticket to the file krb5cc_diskless which is owned by root. This ticket will be picked up by gssd to create the security context needed. However, it's needed to restart autofs, I am not exactly sure why. It looks like autofs caches failures in mounting a directory (which it tries earlier in the login process), and does not try again immediately when the ticket is available. In addition, add the line RPCGSSDOPTS=-n to /etc/default/nfs-common and the line authoptional pam_script.so to /etc/pam.d/common-auth. With these modifications fully kerberized NFSv4 mounting should be possible on all machines if there are no other issues like those reported in URL:http://bugs.debian.org/613167#30 (pending?). I did not test LTSP diskless clients but a home-made chroot in combination with aufs. Best regards, Andi [1] http://lists.debian.org/debian-edu/2010/07/msg00065.html -- 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/20120127161853.GA17722@flashgordon
Re: Thoughts on roaming laptop setup for Debian Edu
2012/1/27 Giorgio Pioda g...@ticino.com: I also would argue that wicd is fairly less efficient than network manager. I've tested it recently on an fresh Wheezy-XFCE but at school I wasn't able to connect and had to replace it with n-m. Cheers I agree. Things have changed in the latest two years. The development of n-m has continued improving the application, while wicd has stalled, keeping some ugly bugs for months. I still think wicd has a more friendly interface for non-geek users, specially when you want the computer to get a network connection before login. That's something that will require root access in n-m while it's easy for any user without root access using wicd. However , the bugs wicd is keeping are making it less efficient with some wireless encription methods, so we have been migrating our machines to n-m in the last months. Regards. Giorgio On Fri, Jan 27, 2012 at 12:18:12PM +0100, Petter Reinholdtsen wrote: [Petter Reinholdtsen 2010-07-10] * The wicd package is installed (instead of network-manager). Not sure if this is a good idea or not, but the report from Extremadura made me put it in there as a test. Based on todays tests, I am starting to suspect it might be better to use network-manager. I installed a roaming workstation using PXE in a Debian Edu/Squeeze network today, and the installation worked fairly well (partition size issues - updated d-e-install with new sizes). After installation, I can log in with the first user, and a local home directory is created and used after I log in for the second time. I can disconnect the network cable and still log in using cached credentials. All good so far. But, when I try to connect to the wireless networks around me, wicd do not see anything. I had to manually configure wicd to use wlan0 as the wireless interface to be able to see the wireless networks. And when I try to select the non-encrypted network I want to use, I am unable to get any IP address. After removing the wicd package and installing the network-manager-kde instead to get a KDE panel widget to control network-manager, I am able to connect to the wireless network. Anyone want to debug wicd in this setup, or should we just switch to network-manager on Roaming Workstation profiles? Possible advantages: - It will discover wireless interfaces without any configuration. - Roaming Workstation will use network manager the same way Standalone (and all other profiles?) do it now. Possible problems - Roaming Workstation will not work for new users because the network is not enabled at boot but only after first login, and thus no connection to LDAP and Kerberos can be made. The problems I see might be because wicd and network-manager are confusing each other. I did not have much time to debug. -- 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/2flzkd92y2z@diskless.uio.no -- Sysadmin SPSE-Tenero Ufficio: +41 91 735 62 48 Cellulare: +41 79 629 20 63 -- 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/20120127140121.ga3...@ticino.com -- 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/CAHpm-q2htMGc5odB-9B=whd6nlr4h_yq_q_-lqpwfdnnx9o...@mail.gmail.com
Re: Allow me to take over debian-edu-commits@?
Petter Reinholdtsen wrote: Hi, Joey. We are discussing to finally move comm...@skolelinux.no to URL: http://lists.alioth.debian.org/mailman/listinfo/debian-edu-commits , as the mailman server currently hosting commits@ is going to die. Can you add me as a list admin and send me the password, or just hand the list over to me if you do not want to be involved with its maintenance in the future? CC to debian-edu@, to make this new development known. I'd be happy to have to manage/own the list. However, I don't know the password any longer, and as I am not a member of the debian-edu project on alioth, I cannot get at the list management interface that way either. Perhaps the alioth admins will need to transfer it to you. -- see shy jo signature.asc Description: Digital signature
Re: Allow me to take over debian-edu-commits@?
[Joey Hess] I'd be happy to have to manage/own the list. Good. :) However, I don't know the password any longer, and as I am not a member of the debian-edu project on alioth, I cannot get at the list management interface that way either. Perhaps the alioth admins will need to transfer it to you. Well, that is the strange thing. I am admin on the debian-edu project and the list do not show up as one of the project lists. :/ No one on #alioth really could tell why this was so. So the project admins can not do anything. Can you talk to the Alioth admins to see what they can do? -- 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/20120127200211.ga17...@login2.uio.no
Re: Diskless clients: NFSv4 mounting with sec=krb5p and no machine creds
[Andreas B. Mundt] I finally figured out a way now, which works here and is not too invasive: Cool. First, make sure you have the package libpam-script available at the diskless client's chroot. libpam-script allows to run a script after successfull authentication. The script executed can be created by running: We already use libpam-python for libpam-mklocaluser, which allow a python script to provide a pam module. Perhaps it is better to rewrite as python to avoid pulling in another dependency? The script executed right after authentication copies the user's Kerberos ticket to the file krb5cc_diskless which is owned by root. This ticket will be picked up by gssd to create the security context needed. However, it's needed to restart autofs, I am not exactly sure why. It looks like autofs caches failures in mounting a directory (which it tries earlier in the login process), and does not try again immediately when the ticket is available. I guess we also need to remove the file when the user log in, to make sure other users can't use another users ticket to mount? With these modifications fully kerberized NFSv4 mounting should be possible on all machines if there are no other issues like those reported in URL:http://bugs.debian.org/613167#30 (pending?). I did not test LTSP diskless clients but a home-made chroot in combination with aufs. This approach look really promosing. What about just dropping autofs and mount the NFS volume in the pam module instead, like pam-mount? -- 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/20120127201920.gb17...@login2.uio.no
Skolelinux/Debian Edu developer gathering in Oslo, Norway, February 10-12.
There's again time for a Skolelinux/Debian Edu developer gathering in Norway, and Redpill-Linpro in Oslo have gracefully offered their space to us. The gathering will take place between Friday the 10th to Sunday the 12th, so book your transportation now. We will try to cover a lot of subjects during this weekend, so anyone should find something of interest. As usual this is both a social event and a place to endorse free and open software, so don't be shy about your own abilities to contribute. Due to safety guidelines and restrictions, the conference room have limited space, so contact one of us to make sure there's a spot for you as well. Contact information and schedule are available at http://friprogramvareiskolen.no/Gathering/2012-02-10-12-Oslo We look forward to seeing you there! Sincerely, Olav Dahlum – FRISK
(fwd) Skolelinux/Debian Edu developer gathering in Oslo, Norway, February 10-12.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Passing this on with GPG signature to get it into the announce list. - - Forwarded message from Olav Dahlum odah...@gmail.com - Date: Fri, 27 Jan 2012 21:04:22 +0100 From: Olav Dahlum odah...@gmail.com To: debian-ble...@lists.debian.org Subject: Skolelinux/Debian Edu developer gathering in Oslo, Norway, February 10-12. There's again time for a Skolelinux/Debian Edu developer gathering in Norway, and Redpill-Linpro in Oslo have gracefully offered their space to us. The gathering will take place between Friday the 10th to Sunday the 12th, so book your transportation now. We will try to cover a lot of subjects during this weekend, so anyone should find something of interest. As usual this is both a social event and a place to endorse free and open software, so don't be shy about your own abilities to contribute. Due to safety guidelines and restrictions, the conference room have limited space, so contact one of us to make sure there's a spot for you as well. Contact information and schedule are available at http://friprogramvareiskolen.no/Gathering/2012-02-10-12-Oslo We look forward to seeing you there! Sincerely, Olav Dahlum ??? FRISK - - End forwarded message - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFPIwnd20zMSyow1ykRAvCPAKC3W2pqC+nblEphcivKKxMqBvuXuwCgrEns sADDzUGJfEM1MZikwmWj8+s= =C67E -END PGP SIGNATURE- -- 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/20120127203351.gc17...@login2.uio.no
Re: Diskless clients: NFSv4 mounting with sec=krb5p and no machine creds
Hi, On Fri, Jan 27, 2012 at 09:19:21PM +0100, Petter Reinholdtsen wrote: [Andreas B. Mundt] [...] The script executed right after authentication copies the user's Kerberos ticket to the file krb5cc_diskless which is owned by root. This ticket will be picked up by gssd to create the security context needed. However, it's needed to restart autofs, I am not exactly sure why. It looks like autofs caches failures in mounting a directory (which it tries earlier in the login process), and does not try again immediately when the ticket is available. I guess we also need to remove the file when the user log in, to make sure other users can't use another users ticket to mount? I think the ticket is used as if it where root's ticket, as the automounter runs under root's ID. If the ticket is removed and the automounter umounts the NFS after some time, accessing the home directory again will fail, because there is no ticket anymore to remount. The trick is a bit dirty, but so far I could not think of any way to misuse the copied ticket, as it's only accessible by root. A user logging in later or in parallel has no access. With these modifications fully kerberized NFSv4 mounting should be possible on all machines if there are no other issues like those reported in URL:http://bugs.debian.org/613167#30 (pending?). I did not test LTSP diskless clients but a home-made chroot in combination with aufs. This approach look really promosing. What about just dropping autofs and mount the NFS volume in the pam module instead, like pam-mount? I don't know if pam-mount has any disadvantages compared to autofs (umounting after some time of 'silence' on the file system?), but if not, it's probably a good idea to switch. 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/20120127211156.GA9727@flashgordon
Re: Diskless clients: NFSv4 mounting with sec=krb5p and no machine creds
HI, your solution seems more or less an unavoidable hack. Nice would be to tell Kerberos to avoid service check and control only user ID. What about this: http://docs.oracle.com/cd/E19963-01/html/821-1456/setup-148.html#gihyu Maybe could be a solution, but I don't know exactly if it works as I think it should: client # cat /etc/krb5/krb5.conf [libdefaults] default_realm = EXAMPLE.COM verify_ap_req_nofail = false ... It should be possible to do it in a separate thiny client realm Cheers Giorgio On Fri, Jan 27, 2012 at 06:18:31PM +0100, Andreas B. Mundt wrote: Hi Giorgio, On Fri, Jan 27, 2012 at 05:59:41PM +0100, Giorgio Pioda wrote: What does autofs manage? / or only /home0 ? Only home0 It shuldn't be that difficoult to mount / without kerberos with plain nfs mounting at boot time and /home0 with a securized env. later on login How to make the securized env. ? As far as I know for mounting NFSv4 with sec=krb5 usually machine credential are needed i.e. /etc/krb5.keytab. But /etc/krb5.keytab must not be in the chroot, because it will be readable by everyone in the network. Do you know another solution to this problem? Cheers, Andi On Fri, Jan 27, 2012 at 05:18:53PM +0100, Andreas B. Mundt wrote: Hi everybody! Since quite some time we have been thinking about how to make kerberized NFSv4 mounting of home directories work with diskless clients, where no machine credentials (keytab) are available. It was mentioned [1] that using -n for gssd on the diskless client might help, however this seems not to be enough. I finally figured out a way now, which works here and is not too invasive: First, make sure you have the package libpam-script available at the diskless client's chroot. libpam-script allows to run a script after successfull authentication. The script executed can be created by running: #!/bin/sh # set -e FILE=/usr/share/libpam-script/pam_script_auth cat $FILE EOF #!/bin/sh # set -e if [ \$PAM_USER = root ] || ls /tmp/krb5cc_diskless /dev/null 21; then exit 0 fi FILE=/tmp/krb5cc_diskless cp -v /tmp/krb5cc_pam_* \$FILE /etc/init.d/autofs restart /dev/null exit 0 EOF chmod 0755 $FILE # The script executed right after authentication copies the user's Kerberos ticket to the file krb5cc_diskless which is owned by root. This ticket will be picked up by gssd to create the security context needed. However, it's needed to restart autofs, I am not exactly sure why. It looks like autofs caches failures in mounting a directory (which it tries earlier in the login process), and does not try again immediately when the ticket is available. In addition, add the line RPCGSSDOPTS=-n to /etc/default/nfs-common and the line authoptional pam_script.so to /etc/pam.d/common-auth. With these modifications fully kerberized NFSv4 mounting should be possible on all machines if there are no other issues like those reported in URL:http://bugs.debian.org/613167#30 (pending?). I did not test LTSP diskless clients but a home-made chroot in combination with aufs. Best regards, Andi [1] http://lists.debian.org/debian-edu/2010/07/msg00065.html -- 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/20120127161853.GA17722@flashgordon -- Sysadmin SPSE-Tenero Ufficio: +41 91 735 62 48 Cellulare: +41 79 629 20 63 -- -- A N D R E A S B. M U N D T Auf dem Rucken 68 89143 Blaubeuren phone priv.: 0049 (0)7344 17 909 38 mobile: 0049 (0)1577 29 222 42 VoIP: sip:andi.mu...@ekiga.net email: andi.mu...@web.de andreas.b.mu...@web.de and...@web.de GPG key: 4096R/617B586D 2010-03-22 Andreas B. Mundt--andreas.b.mu...@web.de Andreas B. Mundt--andi.mu...@web.de -- Sysadmin SPSE-Tenero Ufficio: +41 91 735 62 48 Cellulare: +41 79 629 20 63 -- 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/20120127221404.ga1...@ticino.com
