Main page
[01:01] frederickjh1 (~fhenderso@84-73-254-211.dclient.hispeed.ch) joined #ltsp.
[01:02] frederickjh1 (fhenderso@84-73-254-211.dclient.hispeed.ch) left #ltsp.
[01:02] frederickjh1 (~fhenderso@84-73-254-211.dclient.hispeed.ch) joined #ltsp.
[01:04] frederickjh1 (fhenderso@84-73-254-211.dclient.hispeed.ch) left #ltsp.
[01:07] alkisg (~alkisg@ubuntu/member/alkisg) left irc: Quit: Leaving.
[01:09] alkisg (~alkisg@ubuntu/member/alkisg) joined #ltsp.
[01:17] gnunux (~emmanuel@194.167.18.244) joined #ltsp.
[01:19] frederickjh (~frederick@84-73-254-211.dclient.hispeed.ch) joined #ltsp.
[02:06] avolkovi (~alex@41.182.204.91) joined #ltsp.
[02:18] [frederickjh] Anyone here using the new ltsp cluster packages with Ubuntu LTSP on Karmic 9.10?
[02:19] [frederickjh] I have a Karmic LTSP install now and am wondering about the upgrade path to ltsp cluster?
[02:24] [appiah] upgrade?
[02:38] ogra (~ogra@ubuntu/member/ogra) left irc: Ping timeout: 256 seconds
[02:47] ogra (~ogra@ubuntu/member/ogra) joined #ltsp.
[03:00] bobby_C (~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) joined #ltsp.
[03:06] ogra (~ogra@ubuntu/member/ogra) left irc: Ping timeout: 248 seconds
[03:14] ogra (~ogra@ubuntu/member/ogra) joined #ltsp.
[03:24] frederickjh (~frederick@84-73-254-211.dclient.hispeed.ch) left irc: Remote host closed the connection
[03:28] [alkisg] stgraber, highvoltage: just noticing that I did try adding `dpkg-divert initctl` to 000-daemon-handling, and while the clients boot fine with the diversion, that didn't solve the problem of $CHROOT/proc being in use right after a fat client installation. So I forced umount -l in ltsp-update-image for now. :-(
[03:38] [highvoltage] alkisg: ok
[03:42] [ogra] alkisg, meh, cant you do it from the plugin in the finalization stage instead ?
[03:44] [alkisg] ogra: there was already a call to umount in ltsp-update-image...
[03:44] [ogra] yes, but a proper one
[03:44] [alkisg] Hmmm how proper is it? :)
[03:44] [ogra] -l should really only be used as a workaround ...
[03:44] [alkisg] If the user installed something in the chroot manually, ltsp-update-image will still have problems
[03:44] [ogra] so if your plugin makes it break, your plugin should have the workaround as well
[03:45] [alkisg] It's not exactly a problem with the plugin. The same can happen if the user installs something manually in the chroot.
[03:45] [ogra] (the filesystem stays physically mounted with -l ... its just hidden everywhere)
[03:45] [ogra] (in case of proc that will damage your server)
[03:45] [alkisg] We need to find which daemon does that, and a way to bypass it
[03:46] [alkisg] It isn't upstart - related, and it isn't hal. I don't know what it is.
[03:46] [ogra] you need to fix the daemon handling indeed
[03:46] [ogra] not using -l in ltsp-update-image was done deliberately though
[03:46] [ogra] to save the user from wiping his server setup
[03:46] [alkisg] How would not using it save the user?
[03:46] [ogra] it blocks
[03:47] [alkisg] It doesn't...
[03:47] [ogra] so the user has to unmount it in the chroot first
[03:47] [alkisg] It just causes a hell of errors in the squashfs
[03:47] [ogra] ltsp-update-image will fail rolling the squashfs
[03:47] [alkisg] It didn't fail for me
[03:47] [ogra] it should
[03:47] [alkisg] It just created a squashfs with a lot of /proc/* empty files in it
[03:48] [ogra] then something changed and nobody updated the code accordingly
[03:48] [ogra] in any case ltsp-build-client shouldnt move on if /proc is still mounted
[03:48] [ogra] since that can severely damage the host
[03:48] [alkisg] build-client? or update-image?
[03:48] [ogra] update-image, sorry
[03:49] [alkisg] I'm not sure I understand this
[03:49] [ogra] too many tools with similar names :)
[03:49] [alkisg] The problem is there, sure. But how can creating a squashfs damage the server?
[03:49] [ogra] having proc mounted gives you full access to the server HW and all running processes of the host system
[03:49] [alkisg] But ltsp-update-image runs *on the server* not on the chroot...
[03:50] [alkisg] It already has full access.
[03:51] [alkisg] So now I'm just generating a visible error on the user, instead of a filesystem with /proc in it..
[03:56] [ogra] wow, ltsp-update-image changed a lot ... so the proc unmounting doesnt block anymore apparently ... and the forcefully excluding of proc in the mksquashfs call was dropped as well
[03:56] [ogra] (it used to have -e cdrom proc)
[03:57] [ogra] and "umount ${CHROOT}/proc" used to be "umount ${CHROOT}/proc || exit"
[03:59] hersonls (~hersonls@187.40.57.195) joined #ltsp.
[03:59] [alkisg] Ugh :)
[04:00] [alkisg] I also proposed excluding proc from the squashfs command line...
[04:01] [alkisg] If `umount ${CHROOT}/proc || exit` was still there, I'd just modify the finalization plugin... :-/ anyway
[04:02] [ogra] either way i wouldnt use -l
[04:02] [alkisg] The main problem is that I have no clue on how to find what uses /proc
[04:02] [ogra] only for temporary workarounds
[04:02] [alkisg] And without umount -l, the fat client plugin wouldn't work in many cases...
[04:03] [ogra] right, as i said ... temporary ... but that should definately be solved before releasing it
[04:03] [alkisg] How? :)
[04:03] *** alkisg is all ears!
[04:03] [ogra] no idea, i have no time to work on ltsp atm
[04:03] [ogra] else i'D do some testbuilds
[04:04] [alkisg] I even tried killing almost everything on the server when $CHROOT/proc was in use, but that didn't help!
[04:04] [ogra] unlikely that its something that runs on the server
[04:04] [alkisg] I wonder if it's some mysterious upstart interprocess communication with sockets involved in this...
[04:05] [ogra] might be
[04:05] [ogra] look at the code :)
[04:05] [alkisg] Right... only 10.000.000 lines of code, shouldn't take long... :D
[04:05] [ogra] upstart isnt that big
[04:06] [alkisg] I did try dpkg-divert'ing upstart (initctl) like the karmic release notes advice. To no avail...
[04:06] [ogra] and grepping for proc shouldnt take long in upstarts source
[04:06] [ogra] but i doublt upstart uses proc ... its more likely using something in /var for IPC
[04:07] *** alkisg thinks that the correct solution will be when we use lxc or qemu to build/test/update the chroot :D
[04:08] [ogra] ugh, why qemu ?
[04:08] [ogra] thats definately a waste over a chroot
[04:08] [ogra] i see a reason to use lxc with chroots in general though
[04:14] [alkisg] Doesn't qemu also emulate different architectures?
[04:15] [ogra] it does
[04:15] [alkisg] (for e.g. powerpc clients...)
[04:15] [ogra] but there is no reason to use it if you dont need to
[04:16] [ogra] i.e. waste all the computing power (and slow down everything significantly) surely makes no sense if you build on x86 compatible HW for x86 compatible clients
[04:17] mikkel (~mikkel@130.226.36.170) joined #ltsp.
[04:38] pmatulis (~peter@mail.papamike.ca) joined #ltsp.
[05:01] avolkovi (~alex@41.182.204.91) left irc: Quit: leaving
[05:32] pmatulis (~peter@mail.papamike.ca) left irc: Quit: leaving
[05:43] vvinet (~vince@modemcable244.133-202-24.mc.videotron.ca) left irc: Ping timeout: 264 seconds
[05:58] [alkisg] Hrm. It seems like the tftpd-hpa problem also affects debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551828
[05:58] [alkisg] Up until Karmid, tftpd-hpa.postinst used inetd and /var/lib/tftpboot
[05:58] [alkisg] Now it runs as a daemon by default, and uses /srv/tftp
[05:59] [alkisg] That debconf setting also has a high priority, so the user is prompted to verify that this is the correct directory.
[06:00] [alkisg] So should LTSP in Ubuntu switch to /svr/tftp as well?!
[06:01] gnunux (~emmanuel@194.167.18.244) left irc: Ping timeout: 265 seconds
[06:02] lucascoala (~lucascoal@201-68-165-120.dsl.telesp.net.br) joined #ltsp.
[06:03] gnunux (~emmanuel@194.167.18.244) joined #ltsp.
[06:06] [_UsUrPeR_] good morning
[06:07] jammcq (~jam@c-76-112-250-102.hsd1.mi.comcast.net) left irc: Quit: leaving
[06:07] lucascoala (~lucascoal@201-68-165-120.dsl.telesp.net.br) left irc: Quit: Leaving
[06:07] [ogra] alkisg, if tftp-hps is used it should pull the settings from /etc/default imho
[06:07] [ogra] at least for new builds
[06:08] [alkisg] ogra, I installed Lucid 3 days ago...
[06:08] [ogra] existing installs should be covered by the tftp-hpa fix
[06:08] [alkisg] (re-installed :))
[06:08] [ogra] (which might not have entered lucid yet)
[06:09] [alkisg] Hmmm
[06:09] [alkisg] Got it, thanks. Looking...
[06:09] [ogra] hmm, nov 2009 ... that should definately be in testing and thus in lucid
[06:09] [ogra] probably the fix didnt work right
[06:09] [ogra] but the file shouldnt be touched on upgrades
[06:11] [ogra] if you see issues with upgrades, file a bug :)
[06:11] [alkisg] ogra, but what about new installations?
[06:12] [alkisg] Is the user expected to manually modify the path to /var/lib/tftpboot ?
[06:12] [alkisg] (and also put it to inetd.conf?)
[06:12] [ogra] no
[06:12] Last message repeated 1 time(s).
[06:12] [ogra] ltsp should properly follow the new defaults
[06:13] [ogra] but definately not break on upgrades
[06:13] [alkisg] Then I should probably file a bug in LTSP for it
[06:13] [ogra] check with vagrant what he did for debian
[06:13] [alkisg] ...and we should also modify a lot of wiki pages... hmm... :-/
[06:13] [ogra] definately
[06:14] [alkisg] k, I'll try to contact stgraber and vagrantc later on. Ty! :)
[06:14] [ogra] i'm sure vagrant already dealt with that for debian/testing
[06:14] [ogra] should just be an issue of copying some code
[06:15] *** alkisg is modifying sch-scripts to conflict with tftpd-hpa and use only dnsmasq for the time being... Good thing that stgraber lowered tftpd-hpa to recommends! :D
[06:20] etyack (~etyack@173-10-34-145-Michigan.hfc.comcastbusiness.net) joined #ltsp.
[06:21] shawnp0wers (~spowers@linuxjournal/staff/shawnp0wers) joined #ltsp.
[06:27] Kicer86 (~kicer@host-5db0eeee.sileman.net.pl) joined #ltsp.
[06:28] cliebow (~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us) joined #ltsp.
[06:28] [cliebow] a
[06:38] [appiah] b
[06:40] [ogra] c
[06:41] [alkisg] d
[06:43] [alincoln] f
[06:43] [alincoln] oops
[06:43] highvoltage (~highvolta@ubuntu/member/highvoltage) left irc: Ping timeout: 252 seconds
[06:45] [ogra] you broke at !
[06:45] [ogra] *it
[06:45] highvoltage (~highvolta@ubuntu/member/highvoltage) joined #ltsp.
[06:45] [alincoln] ah, darnit!
[06:45] [alincoln] :P
[06:49] cliebow (~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us) left irc: Remote host closed the connection
[06:49] cliebow (~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us) joined #ltsp.
[07:00] cliebow (~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us) left irc: Remote host closed the connection
[07:00] cliebow (~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us) joined #ltsp.
[07:05] cliebow (~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us) left irc: Remote host closed the connection
[07:05] cliebow (~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us) joined #ltsp.
[07:08] slidesinger (~slidesing@c-68-44-99-50.hsd1.nj.comcast.net) joined #ltsp.
[07:08] slidesinger (~slidesing@c-68-44-99-50.hsd1.nj.comcast.net) left irc: Client Quit
[07:12] highvoltage (~highvolta@ubuntu/member/highvoltage) left irc: Ping timeout: 260 seconds
[07:26] Gadi (~romm@ool-18bbe47a.static.optonline.net) joined #ltsp.
[07:29] pmatulis (~peter@64.34.151.178) joined #ltsp.
[07:31] GodFather (~rcc@173-10-34-145-Michigan.hfc.comcastbusiness.net) joined #ltsp.
[07:32] highvoltage (~highvolta@ubuntu/member/highvoltage) joined #ltsp.
[07:36] [sbalneav] Morning all
[07:38] [alkisg] Good morning sbalneav
[07:40] [sbalneav] looks like tftp-hpa's changed?
[07:40] [alincoln] yeah, an update to that broke my lucid stuff.
[07:44] cliebow (~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us) left irc: Remote host closed the connection
[07:44] [alkisg] Heh, LTSP 5.2 will also need a tftp dir change :)
[07:44] cliebow (~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us) joined #ltsp.
[07:44] [alkisg] (for debian/ubuntu, that is....)
[07:45] [alkisg] I think it's a good time to get rid of that 2000 port as well :D
[07:45] CAN-o-SPAM (~chatzilla@fw.acurrus.com) joined #ltsp.
[07:52] [sbalneav] alkisg: What we ought to do is apply to IANA and get an assigned port number.
[07:52] [alkisg] sbalneav: hmmm I just happen to know the right person to do that... :D
[07:53] [alkisg] But we might need more than one number
[07:53] [alkisg] (i.e more than one chroots)
[07:53] [sbalneav] Yeah,we'd need 2
[07:53] [sbalneav] Well, I don't think you can be greedy
[07:54] [sbalneav] I think one for root and one for swap's all you can pretty much ask for.
[07:54] [alkisg] 2 for chroots + 1 for nbdswapd?
[07:54] [sbalneav] one for i386, one for x64?
[07:54] [alkisg] one for fat, one for nvidia clients... whatever
[07:54] [alkisg] Usage cases might vary
[07:55] [sbalneav] Well, the specifiction process doesn't go like that.
[07:55] [alkisg] I wonder if we should always be passing the port as a kernel parameter...
[07:55] [sbalneav] You have to be VERY explicit about what each port's going to be used for
[07:55] [sbalneav] You can't just say "We want 3 ports"
[07:56] [sbalneav] IANA says, "yeah, you and everyone else. There's 65535 of 'em, why should we assign you 3? " :)
[07:56] [alkisg] Roger that. I'm just saying that it would be nice to have swapd first and nbdroot second, so that we may... abuse the ports a little to add extra chroots
[07:57] [alkisg] Those extra chroots will be per-site anyways...
[07:57] [sbalneav] Well, iana aside, where would we put them?
[07:57] [alkisg] 9571 + ?
[07:57] [ogra] just make sure to properly handle upgrades :)
[07:58] [sbalneav] i.e. what number/range do we want?
[07:58] [alincoln] are there stretches in the port numbers that IANA sets aside that they won't assign?
[07:58] [alincoln] possibly those can be assumed to be "clearer".
[07:58] [alkisg] 9571 = ldminfod, 9572 = nbdswapd, 9573 = nbd-server
[07:58] [sbalneav] ogra: Would "properly handle upgrades" mean, you need to re-run ltsp-update-image to install the image on the new port?
[07:59] [sbalneav] or something more automagic?
back next →
1 2 3 4 5 6
up
Generated by logs2html module for eggdrop v.2.3.4
Find latest version at http://sourceforge.net/projects/logs2html or http://shmupsik.osetia.org