Main page
[00:00] *** alkisg is has been programming for too long and understands the feeling perfectly... :)
[00:01] [vagrantc] alkisg: i really like cleaning up ltsp-update-image!
[00:01] [vagrantc] but since i don't use it, i haven't really taken the time to do so
[00:01] [alkisg] Is there a reason for ltsp-update-image to not call ltsp-update-kernels at the end?
[00:01] [vagrantc] no
[00:01] [vagrantc] not that i can think of, that is
[00:02] [alkisg] We could add an `ltsp-update-kernels --pxecfg-only` option if there was, but I also can't think of any reason not to call all of it...
[00:03] [alkisg] I'm more or less free today. If you agree, I could come up with a complete solution. All those 3 scripts would need to be modified, but I think the end result would be cleaner. What do you say?
[00:03] [vagrantc] the whole tftp/pxe population is a mess. let's re-write it from scratch, nice and clean, learning from our past mistakes :)
[00:04] [alkisg] Yey! :)
[00:04] [vagrantc] i remember one reason i moved it into the chroot...
[00:05] [vagrantc] it was so that the kernel's post-install hooks could generate everything needed, and you could configure a tftp server to point to the chroot directly, and never have to run ltsp-update-kernels again.
[00:05] makghosh (n=Joy@fedora/makghosh) left irc: Read error: 60 (Operation timed out)
[00:05] [vagrantc] in fact, i think that's *the* reason i re-wrote it.
[00:07] [alkisg] Hmmm....
[00:07] [vagrantc] the whole approach of ltsp-update-kernels always felt like a regression to me.
[00:07] [alkisg] The server knows stuff that the chroot doesn't, that's a fact...
[00:07] [alkisg] E.g. its IP, its ports...
[00:08] [vagrantc] and the client knows stuff that the server can't easily know (like the client's kernel was just upgraded)
[00:08] [alkisg] So I think ltsp-update-kernels is needed in general, and not-using it should be just one case
[00:09] [alkisg] The kernel upgrade of the client is always triggered by the server, though
[00:10] [alkisg] The case you say is *partially* solved if update-kernels.conf supports a "local tftp" setting,
[00:10] [alkisg] which ltsp-update-kernels would read, and know that it should generate pxelinux.cfg/default locally instead
[00:11] [alkisg] So, you could use a chroot/tftp dir, but you'd still need to call ltsp-update-kernels
[00:12] [vagrantc] to tell you the honest truth, i never really used the feature i worked so hard to create :)
[00:12] [alkisg] Heh... :)
[00:13] [vagrantc] the no ltsp-update-kernels approach
[00:13] [alkisg] So should we go for the change (back)?
[00:14] [vagrantc] there's also the cross-architecture support...
[00:14] [alkisg] That's still better supported by the server
[00:15] [vagrantc] how do you detect the sub-architecture of your chroot fromt the server?
[00:15] [alkisg] By looking at update-kernels.conf :)
[00:15] [vagrantc] ah, so the kernel post-inst hooks would populate all those variables in update-kernels.conf ...
[00:15] [alkisg] Yup
[00:16] [vagrantc] still has the issue of the chroot generating variables that the server doesn't necessarily know about
[00:16] [vagrantc] or know what to do with, rather.
[00:16] [vagrantc] why can't the server populate values in the chroots?
[00:16] [alkisg] I think it's safe to assume that *usually* the server has newer code than the chroot
[00:16] [vagrantc] same problem, other direction
[00:17] [vagrantc] alkisg: i think that's a very unsafe assumption
[00:17] [vagrantc] alkisg: i would frequently want a server with a very stable version, and a chroot that has the newest versions of X.org available.
[00:17] [alkisg] E.g. suppose you have a new pxelinux version being installed on the server, which needs some modification done to pxelinux.cfg/default. ltsp-server could also be updated to cope with that and generate a new pxelinux.cfg/default. Now, imagine the opposite: that you need to update a mac chroot with new boot setting... How would you do that if you don't even have a mac?
[00:18] [vagrantc] alkisg: yeah, that's one down-side.
[00:19] [alkisg] I'm talking about ltsp settings versioning, not general software versions... at which time did you use a newer ltsp version on the chroot and an older on the server?
[00:19] [vagrantc] alkisg: every day of the week.
[00:19] [stgraber] every day ;)
[00:19] [alkisg] Usually, when someone has e.g. hardy and wants a karmic chroot, he also updates ltsp on the server, doesn't he?
[00:19] [vagrantc] every single day.
[00:20] [stgraber] currently I have Jaunty's LTSP for my chroot storage VM (ia64 VZ I can't easily upgrade because it's itanium) and it stores hardy, jaunty, karmic and lucid chroots
[00:21] [vagrantc] alkisg: one of the ltsp servers at freegeek is running debian's stable release, including ltsp, and have chroots with newer versions of ltsp.
[00:21] [stgraber] (backup, production and test chroots)
[00:21] [alkisg] OK, sorry for the wrong assumption
[00:21] [vagrantc] alkisg: :)
[00:21] [alkisg] Still. It's just settings. All of the current use cases will be supported.
[00:22] [vagrantc] sure hope so
[00:22] [alkisg] And I think the "up" sides are more significant than the "down" sides...
[00:22] [johnny] /me really likes the "point tftp at chroot"
[00:25] *** alkisg also notes that we currently *don't* have that feature - e.g. the old ltsp-update-image breaks pxelinux.cfg because it adds "nbdport=2001" in all of its lines :)
[00:26] [johnny] it's what i did when doing the initial gentoo development
[00:27] [johnny] i had not tested ltsp-update-image, as we can't rely on our kernels having nbd..
[00:27] [johnny] altho.. i should try it again someday.. when i get a new pc
[00:31] [vagrantc] alkisg: that's only because ltsp-update-image has some fixable faults.
[00:32] [alkisg] vagrantc: sure, but the fact is that a newer chroot generates a pxelinux.cfg that an older server breaks
[00:32] [alkisg] So that breaking can happen both ways...
[00:33] [alkisg] What if we made "update-pxecfg" a seperate script? That way it could be manually, but easily, upgraded by whoever sysadmin needs newer *and incompatible* (which I imagine will be rare) chroots?
[00:34] *** alkisg also notes that we now have a *broken* pxelinux.cfg/default, while if the server generated it from update-kernels.conf, we'd have an older, but syntactically correct, pxelinux.cfg/default
[00:35] [vagrantc] alkisg: the only breakage is in ltsp-update-kernels, no?
[00:35] [vagrantc] er, ltsp-update-image
[00:38] [alkisg] vagrantc: yes, because that's where the "additional server knowledge" is applied
[00:38] [alkisg] My main request is that we shouldn't have the code divided in many places
[00:39] [alkisg] OK, how about the opposite scenario you said earlier? I.e. the server puts whatever info it has to update-kernels.conf, and calls chroot $chroot/update-kernels whenever he wants to update pxelinux.cfg/default ?
[00:40] [alkisg] (and then copies the result?)
[00:42] [vagrantc] seems like less disruption from the current behavior
[00:42] [vagrantc] has some drawbacks
[00:43] [alkisg] The main downside is that this is much slower. But it solves the problem you mention (newer chroots), and it has an additional benefit: pxelinux.cfg/default is generated from the chroot, on which the ltsp version is updated whenever pxelinux is also updated. What I mean is that if pxelinux is upgraded on the chroot, and needs a different file format, at the same time ltsp is also updated on the chroot (if ever...), and can provide that newer format.
[00:44] [alkisg] I can't express this correctly... :( I mean that pxelinux itself and the ltsp script that generates /default are of the same distro/version and are updated "together".
[00:44] [vagrantc] yes!
[00:44] [vagrantc] that was what i was trying to get at when i mentioned binaries
[00:46] [alkisg] I think we'll need a seperate script for creating /default thought, for speed reasons, otherwise ltsp-update-kernels/ltsp-update-image performance will suck. Is that acceptable?
[00:47] [vagrantc] oh!
[00:47] [vagrantc] is it really that slow?
[00:48] [vagrantc] i mean, ltsp-update-kernels is already rather slow... i can't imagine it gets any slower.
[00:48] *** alkisg looks at the current update-kernels hook code...
[00:49] [vagrantc] the slowest thing is the nbi.img creation... but that's not particularly slow
[00:49] [alkisg] (I mean that those scripts would have to run the hook, in order for the /default to be updated, and maybe that hook does additional, not needed stuff?)
[00:49] [alkisg] OK... why not split it, and avoid creating an nbi.img whenever ltsp-update-kernels/image is ran?
[00:50] [alkisg] Bah no that's not possible
[00:51] [alkisg] An i386 server can't run something in a mac chroot
[00:51] [alkisg] So ltsp-update-kernels/image can't rely on calling a script from the chroot
[00:52] gfarras (n=gerard@41.Red-79-145-19.dynamicIP.rima-tde.net) left irc: Read error: 110 (Connection timed out)
[00:53] [alkisg] So it has no way to invoke a pxelinux.cfg/default update. It has to reuse what's already there.
[00:53] gfarras (n=gerard@41.Red-79-145-19.dynamicIP.rima-tde.net) joined #ltsp.
[00:53] [alkisg] So if it wants to update an IP, it'll have to sed through the file, resulting in the same problems.
[00:55] [vagrantc] it's a mess
[00:57] johnny (i=spectrum@franklin.localmomentum.net) left #ltsp.
[01:01] [alkisg] I'll *mostly* be backwards compatible. So I vote this: a) update-kernels generates only a settings file, update-kernels.conf, b) *only* ltsp-update-kernels generates pxelinux.cfg/default. c) ltsp-update-image calls ltsp-update-kernels. d) If ever compatibility is broken between some versions, and the sysadmin needs to use them, he'd have to manually download and use a newer ltsp-update-kernels script.
[01:04] [vagrantc] alkisg: and will have to download a different script for each incompatible version? :)
[01:05] [alkisg] vagrantc: do you imagine a settings file breaking so often?
[01:05] [vagrantc] i sure hope not.
[01:05] [vagrantc] i've managed to keep the current approach for 3 years :)
[01:06] [vagrantc] maybe only 2.5
[01:06] [alkisg] The opposite approach is on the patch I've sent: http://launchpadlibrarian.net/37642647/patch
[01:07] [alkisg] I.e. the server putting the port in update-kernels.conf, and `sed`ing through the pxelinux.cfg/default file.
[01:08] [vagrantc] the sed business is unpleasant...
[01:08] [alkisg] Right. It should *at least* move to ltsp-update-kernels
[01:08] [vagrantc] at any rate... i've got to get some sleep
[01:08] [alkisg] OK, thank you for listening :)
[01:08] [vagrantc] i'm sure in the end it'll be better than anyone expected :)
[01:09] [alkisg] Should I start something?
[01:09] [vagrantc] i'd say go for it.
[01:09] [alkisg] Uhm... which one?
[01:09] [alkisg] :D
[01:09] [vagrantc] though all the current code is about pxelinux generation, which is really i386/x86_64 specific
[01:10] [alkisg] Yeah, I'm uncomfortable with not knowing anything about powerpc etc
[01:10] [alkisg] OK let's leave it for now and give it some more thought
[01:10] [alkisg] Good night :)
[01:11] [vagrantc] well, i guess my favorite approach so far was to have the server-side stuff update update-kernels.conf and call the code in the chroot...
[01:12] [vagrantc] there's nothing like writing code a few implementations in search of the best :)
[01:12] [alkisg] Heh, ok then, I'll go for what I said earlier:
[01:12] [alkisg] a) update-kernels generates only a settings file, update-kernels.conf, b) *only* ltsp-update-kernels generates pxelinux.cfg/default. c) ltsp-update-image calls ltsp-update-kernels. d) If ever compatibility is broken between some versions, and the sysadmin needs to use them, he'd have to manually download and use a newer ltsp-update-kernels script.
[01:13] [alkisg] ...and I hope it'll always be text files, not binaries :)
[01:13] [vagrantc] have fun!
[01:13] vagrantc (n=vagrant@c-76-27-239-73.hsd1.or.comcast.net) left irc: "night"
[01:13] *** alkisg forgot nbi.img, though... well I guess it'll be easily constructed from the update-kernels.conf file.
[01:55] alkisg (n=alkisg@ubuntu/member/alkisg) left irc: "Leaving."
[01:55] alkisg (n=alkisg@ubuntu/member/alkisg) joined #ltsp.
[01:56] alkisg (n=alkisg@ubuntu/member/alkisg) left irc: Client Quit
[01:59] alkisg (n=alkisg@ubuntu/member/alkisg) joined #ltsp.
[01:59] alkisg (n=alkisg@ubuntu/member/alkisg) left irc: Client Quit
[02:02] makghosh (n=Joy@fedora/makghosh) joined #ltsp.
[02:57] makghosh (n=Joy@fedora/makghosh) left irc: Read error: 110 (Connection timed out)
[03:46] alkisg (n=alkisg@ubuntu/member/alkisg) joined #ltsp.
[04:18] alkisg (n=alkisg@ubuntu/member/alkisg) left irc: "Leaving."
[04:20] alkisg (n=alkisg@ubuntu/member/alkisg) joined #ltsp.
[04:22] Faithful (n=Faithful@ns.linuxterminal.com) joined #ltsp.
[04:25] ogra_ (n=ogra@p5098ed03.dip0.t-ipconnect.de) left irc: Read error: 104 (Connection reset by peer)
[04:26] ogra_ (n=ogra@p5098ed03.dip0.t-ipconnect.de) joined #ltsp.
[05:03] alkisg (n=alkisg@ubuntu/member/alkisg) left irc: Read error: 110 (Connection timed out)
[05:06] alkisg (n=alkisg@ubuntu/member/alkisg) joined #ltsp.
[05:09] highvolt1ge (n=highvolt@196-210-177-89-wblv-esr-3.dynamic.isadsl.co.za) joined #ltsp.
[05:13] highvoltage (n=highvolt@ubuntu/member/highvoltage) left irc: Read error: 60 (Operation timed out)
[05:16] johnny (i=spectrum@franklin.localmomentum.net) joined #ltsp.
[05:21] F-GT (n=phantom@ppp121-44-12-57.lns20.syd6.internode.on.net) joined #ltsp.
[05:37] highvolt1ge (n=highvolt@196-210-177-89-wblv-esr-3.dynamic.isadsl.co.za) left irc: "bbl"
[05:46] sene (n=sene@unaffiliated/sene) joined #ltsp.
[05:59] [knipwim] thx for the commit access guys
[05:59] [knipwim] the first ones are in
[06:41] Selveste1_ (n=Selveste@88.83.86.20.static.dong.customer.smilecontent.dk) left irc: Read error: 113 (No route to host)
[06:41] highvoltage (n=highvolt@ubuntu/member/highvoltage) joined #ltsp.
[06:59] gfarras (n=gerard@41.Red-79-145-19.dynamicIP.rima-tde.net) left irc: Read error: 110 (Connection timed out)
[06:59] gfarras (n=gerard@41.Red-79-145-19.dynamicIP.rima-tde.net) joined #ltsp.
[07:01] Faithful (n=Faithful@ns.linuxterminal.com) left irc: Read error: 113 (No route to host)
[07:04] Faithful (n=Faithful@ns.linuxterminal.com) joined #ltsp.
[07:16] alkisg (n=alkisg@ubuntu/member/alkisg) left irc: Read error: 110 (Connection timed out)
[07:21] mikkel (n=mikkel@84-238-113-66.u.parknet.dk) joined #ltsp.
[07:30] alkisg (n=alkisg@ubuntu/member/alkisg) joined #ltsp.
[07:38] Ahmuck-Jr (n=chatzill@p222n22.ruraltel.net) left irc: "ChatZilla 0.9.86 [Firefox 3.5.3/20090824101458]"
[07:39] hersonls (n=hersonls@187.40.75.221) joined #ltsp.
[07:42] gfarras (n=gerard@41.Red-79-145-19.dynamicIP.rima-tde.net) left irc: Read error: 110 (Connection timed out)
[07:43] gfarras (n=gerard@111.Red-79-152-171.dynamicIP.rima-tde.net) joined #ltsp.
[07:45] Selveste1_ (n=Selveste@cpe.atm2-0-1171062.alb2nxx15.customer.tele.dk) joined #ltsp.
[07:48] alkisg1 (n=alkisg@ubuntu/member/alkisg) joined #ltsp.
[07:49] alkisg (n=alkisg@ubuntu/member/alkisg) left irc: Read error: 104 (Connection reset by peer)
[07:56] highvoltage (n=highvolt@ubuntu/member/highvoltage) left irc: Read error: 110 (Connection timed out)
[08:01] sbalneav (n=sbalneav@S010600902754713b.wp.shawcable.net) left irc: Remote closed the connection
[08:01] ltspbot (n=supybot@S010600902754713b.wp.shawcable.net) left irc: Read error: 54 (Connection reset by peer)
[08:02] ltspbot (n=supybot@S010600902754713b.wp.shawcable.net) joined #ltsp.
[08:02] [moldy] hi
[08:02] [moldy] hmm, dbus-daemon is running crazy here.. this happens occasionaly. ubuntu karmic. does anyone have any idea on what to do about this?
[08:03] [moldy] System load: 579.86
[08:05] Selveste1_ (n=Selveste@cpe.atm2-0-1171062.alb2nxx15.customer.tele.dk) left irc: Read error: 113 (No route to host)
[08:18] highvoltage (n=highvolt@ubuntu/member/highvoltage) joined #ltsp.
[08:20] highvoltage (n=highvolt@ubuntu/member/highvoltage) left irc: Client Quit
[08:20] highvoltage (n=highvolt@ubuntu/member/highvoltage) joined #ltsp.
[08:22] highvoltage (n=highvolt@ubuntu/member/highvoltage) left irc: Client Quit
[08:36] highvoltage (n=highvolt@ubuntu/member/highvoltage) joined #ltsp.
[08:38] Kicer86 (n=kicer@host-5db0eeee.sileman.net.pl) joined #ltsp.
[08:46] hersonls_ (n=hersonls@187.40.75.221) joined #ltsp.
[08:46] hersonls_ (n=hersonls@187.40.75.221) left irc: Read error: 104 (Connection reset by peer)
[08:46] hersonls_ (n=hersonls@187.40.75.221) joined #ltsp.
[08:54] fritz (n=fritz@82-149-101-182.wco.wellcom.at) joined #ltsp.
[08:56] [fritz] Hello, is somebody here who cvan help me with trouble-shooting KIWI-LTSP ? I can boot up the client to the login screen, but when I enter the correct username + password, I get "No response from server".
[08:57] [fritz] The system is openSuSE 11.2 x64, btw.
[08:59] [moldy] fritz: not familiar with kiwi-ltsp, but check the ssh keys
[09:00] [fritz] How do I do that?
[09:00] [moldy] fritz: ltsp-update-sshkeys
[09:00] [moldy] fritz: and afterwards, ltsp-update-image
[09:01] [fritz] This is not known by kiwi-ltsp. :(
[09:02] [moldy] fritz: also check the ssh log on the server
[09:03] hersonls (n=hersonls@187.40.75.221) left irc: Read error: 110 (Connection timed out)
[09:04] [fritz] sshd was not started. I startzed it now, and it looked better then. But finally the same.
[09:05] [alkisg1] fritz: not many people here have experience with kiwi, maybe you can try asking in #kiwi-ltsp for this.
[09:05] [fritz] Oh, thank you!
[09:06] [alkisg1] Maybe you may also try putting SCREEN_02=shell and SCREEN_08=ldm in lts.conf, and then reboot the client, switch to vt2 with alt+ctrl+f2, and try `ssh user@server` from there...
[09:14] [fritz] I have to login on vt2., Which username&password must I use?
[09:15] otavio (n=otavio@debian/developer/otavio) joined #ltsp.
[09:21] [alkisg1] You shouldn't be prompted for username/password... either you didn't put those in the correct place, or kiwi-ltsp is too different, sorry... :-/
[09:26] [moldy] fritz: if in doubt, set the password in the chroot and rebuild the image
[09:26] [moldy] fritz: the root password, that is.
[09:26] [moldy] you might also need to activate/unexpire the root account
back next →
1 2 3
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