IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 10 January 2010 (all times are UTC)
| 00:23 | makghosh has quit IRC | |
| 00:28 | vagrantc has joined #ltsp | |
| 00:33 | <vagrantc> alkisg: so, it's interesting that you think the in-chroot pxelinux.cfg/default generation doesn't have enough information to generate the configuration file ... originally it was generated outside of the chroot, and i moved it into the chroot to better be able to represent accurate information
| |
| 00:33 | i don't remember what all...
| |
| 00:35 | <alkisg> Hi vagrantc. Well, I think the chroot knows a lot, and it should note them down in a automatically managed configuration file, but there's also some knowledge outside of the chroot, so the generated pxelinux.cfg/default should be done by ltsp-update-kernels (maybe with a possible --only-generate-pxecfg option)
| |
| 00:35 | E.g. the chroot can't know about the nbd port number in inetd.conf
| |
| 00:35 | <vagrantc> i think i wanted to have the chroot be a complete environment you could copy to another server...
| |
| 00:36 | * vagrantc always thought the nbd information should be passed via dhcp | |
| 00:36 | <alkisg> I don't think you'll loose that functionality the way I say
| |
| 00:36 | <vagrantc> alkisg: probably not, i'm looking at the patch now
| |
| 00:37 | makghosh has joined #ltsp | |
| 00:37 | <alkisg> The patch is for the case where you *wouldn't* like my more drastic proposal :)
| |
| 00:37 | <vagrantc> oh
| |
| 00:37 | <alkisg> (back to the proposal) I.e. the chroot will say "I want the kernel parameters = quiet splash". You could move that in a different machine.
| |
| 00:37 | <vagrantc> sure
| |
| 00:37 | <alkisg> But ltsp-update-kernels may deside to serve that in port=2000 in one server, and port=2001 in another server
| |
| 00:38 | So it's complimentary information.... cleanly seperated
| |
| 00:38 | <vagrantc> but i'm sure as soon as it gets switched back out of the chroot, it'll become obvious why i moved it into the chroot :)
| |
| 00:38 | i had fantasies of cross-architecture stuff...
| |
| 00:39 | which have only recently been partially realized.
| |
| 00:39 | <alkisg> I'll keep the same functionality, and then add some... could you give me an example of what could not be done with the "new way"?
| |
| 00:39 | <vagrantc> alkisg: i can't give you any examples... like i said, it's more a gut feeling
| |
| 00:39 | well, i didn't say it before, but i'm saying it now :)
| |
| 00:40 | alkisg: it sounds good to me...
| |
| 00:41 | * vagrantc struggles a little with what appear to be trivial changes mixed in with other changes | |
| 00:41 | <alkisg> Let me rephrase my proposal, because my English sometimes sucks: I propose for the chroot to run whatever code it wants, and then mark down the results in update-kernels.conf. But the actual pxelinux.cfg/default generation to happen from server code. Since code runs in both chroot + server, I don't think any functionality will be lost...
| |
| 00:41 | <vagrantc> well, you can't copy binaries into update-kernels.conf
| |
| 00:42 | so if you need to generate a binary, you get cross-chroot dependencies
| |
| 00:42 | i.e. the server needs to know about modifications that the chroot wants done to the file that may not be representable in variables it already knows about
| |
| 00:43 | so then you develop a chroot -> server communication problem
| |
| 00:43 | <alkisg> But I'm only talking about pxelinux.cfg/default, I'm not talking about any binaries... the whole tftp dir will still be copied
| |
| 00:43 | <vagrantc> toss aside the binaries idea
| |
| 00:43 | <alkisg> I just don't want to generate a text file (/default) from the chroot, because that's harder to parse/edit than a settings file (update-kernels.conf)
| |
| 00:43 | <vagrantc> the main point still holds
| |
| 00:43 | assuming you know all the possible settings in advance.
| |
| 00:44 | you could have a server with 3 different releases of different chroots, and the server-side code would have to know the appropriate variable settings in the chroots' update-kernels.conf
| |
| 00:45 | i guess you could always have a "don't mess with my pxelinux.cfg/default" option in the chroot :)
| |
| 00:45 | <alkisg> I probably lost you :)
| |
| 00:45 | OK, we're still talking about ONLY the /default file, right?
| |
| 00:45 | <vagrantc> alkisg: sure.
| |
| 00:46 | <alkisg> So, in what case would a chroot need some additional setting that it couldn't mark down in update-kernels.conf ?
| |
| 00:46 | <vagrantc> alkisg: generating only the pxelinux.cfg/default, i'm saying the chroot might have configuration options that the server's code didn't yet know about.
| |
| 00:46 | <alkisg> Why wouldn't that code be on the server instead?
| |
| 00:47 | <vagrantc> say, you want a newer chroot on an older server.
| |
| 00:47 | keeping it all in the chroot means the chroot's code will be able to handle all the options it needs to know about.
| |
| 00:48 | * vagrantc isn't a fan of tweaking nbdroot/nbdport in pxelinux.cfg/default | |
| 00:48 | <alkisg> OK, say the opposite: you want an older chroot in a newer server that automatically manages everything and creates graphical menus etc. How would that server parse an arbitrary pxelinux.cfg/default file?
| |
| 00:49 | Or, you want *the user* to be able to modify his pxelinux.cfg file. Now we don't allow that, we blindly overwrite it
| |
| 00:50 | We could have an update-kernels.conf option for "blindly use that /default file and don't mess with it" if you want, but I don't like the idea of it being the default..
| |
| 00:50 | <vagrantc> alkisg: buy "the user" you mean system administrator?
| |
| 00:50 | <alkisg> Or we could have an option for including another file (pxelinux allows includes)
| |
| 00:50 | Yes, the system administrator
| |
| 00:50 | <vagrantc> yeah, but arbitrary includes could get messy
| |
| 00:51 | <alkisg> That what I'm trying to avoid, by having a settings file...
| |
| 00:51 | <vagrantc> alkisg: you can always generate the server-side stuff anyways.
| |
| 00:52 | ignore the chroot's pxelinux.cfg/default
| |
| 00:52 | generate your own menu however you want...
| |
| 00:52 | <alkisg> But ltsp-update-kernels just does a `cp -a`, overwriting everything...
| |
| 00:53 | So the only real alternative is to use another tftp directory, but then you lose automatic port settings etc
| |
| 00:54 | <vagrantc> i don't see how using another tftp directory looses automatic port settings
| |
| 00:54 | <alkisg> ltsp-update-image updates tftp/pxelinux.cfg/default. It wouldn't look in the sysadmin's new directory.
| |
| 00:55 | (we have 3 seperate scripts messing with that file :()
| |
| 00:55 | <vagrantc> i never liked ltsp-update-image.
| |
| 00:55 | <alkisg> I agree, that code should be moved to ltsp-update-kernels instead
| |
| 00:55 | <vagrantc> alkisg: what are the 3?
| |
| 00:56 | <alkisg> update-kernels in the chroot, ltsp-update-kernels, and ltsp-update-image
| |
| 00:56 | I think only ltsp-update-kernels should touch that file.
| |
| 00:56 | <vagrantc> chroot's update-kernels generates it, ltsp-update-kernels copies it, and then ltsp-update-image does who knows what
| |
| 00:57 | <alkisg> Adds info that the chroot doesn't know about
| |
| 00:57 | That's why I propose that the chroot shouldn't generate it, but mark settings instead.
| |
| 00:58 | Another example: suppose I have to put nfs=<server-ip> as a kernel parameter. Only the server can put that.
| |
| 00:58 | <vagrantc> i see some good ideas in your proposal, and it sounds better than it was when i re-wrote it to be more chroot-focused... but i'm just nervous about flip-flopping all the time :)
| |
| 00:59 | * alkisg is has been programming for too long and understands the feeling perfectly... :) | |
| 00:59 | <vagrantc> alkisg: i really like cleaning up ltsp-update-image!
| |
| 01:00 | but since i don't use it, i haven't really taken the time to do so
| |
| 01:00 | <alkisg> Is there a reason for ltsp-update-image to not call ltsp-update-kernels at the end?
| |
| 01:00 | <vagrantc> no
| |
| 01:00 | not that i can think of, that is
| |
| 01:01 | <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...
| |
| 01:02 | 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?
| |
| 01:02 | <vagrantc> the whole tftp/pxe population is a mess. let's re-write it from scratch, nice and clean, learning from our past mistakes :)
| |
| 01:02 | <alkisg> Yey! :)
| |
| 01:02 | <vagrantc> i remember one reason i moved it into the chroot...
| |
| 01:03 | 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.
| |
| 01:04 | makghosh has quit IRC | |
| 01:04 | <vagrantc> in fact, i think that's *the* reason i re-wrote it.
| |
| 01:05 | <alkisg> Hmmm....
| |
| 01:05 | <vagrantc> the whole approach of ltsp-update-kernels always felt like a regression to me.
| |
| 01:06 | <alkisg> The server knows stuff that the chroot doesn't, that's a fact...
| |
| 01:06 | E.g. its IP, its ports...
| |
| 01:07 | <vagrantc> and the client knows stuff that the server can't easily know (like the client's kernel was just upgraded)
| |
| 01:07 | <alkisg> So I think ltsp-update-kernels is needed in general, and not-using it should be just one case
| |
| 01:07 | The kernel upgrade of the client is always triggered by the server, though
| |
| 01:08 | The case you say is *partially* solved if update-kernels.conf supports a "local tftp" setting,
| |
| 01:09 | which ltsp-update-kernels would read, and know that it should generate pxelinux.cfg/default locally instead
| |
| 01:09 | So, you could use a chroot/tftp dir, but you'd still need to call ltsp-update-kernels
| |
| 01:11 | <vagrantc> to tell you the honest truth, i never really used the feature i worked so hard to create :)
| |
| 01:11 | <alkisg> Heh... :)
| |
| 01:11 | <vagrantc> the no ltsp-update-kernels approach
| |
| 01:12 | <alkisg> So should we go for the change (back)?
| |
| 01:12 | <vagrantc> there's also the cross-architecture support...
| |
| 01:13 | <alkisg> That's still better supported by the server
| |
| 01:13 | <vagrantc> how do you detect the sub-architecture of your chroot fromt the server?
| |
| 01:13 | <alkisg> By looking at update-kernels.conf :)
| |
| 01:14 | <vagrantc> ah, so the kernel post-inst hooks would populate all those variables in update-kernels.conf ...
| |
| 01:14 | <alkisg> Yup
| |
| 01:14 | <vagrantc> still has the issue of the chroot generating variables that the server doesn't necessarily know about
| |
| 01:15 | or know what to do with, rather.
| |
| 01:15 | why can't the server populate values in the chroots?
| |
| 01:15 | <alkisg> I think it's safe to assume that *usually* the server has newer code than the chroot
| |
| 01:15 | <vagrantc> same problem, other direction
| |
| 01:16 | alkisg: i think that's a very unsafe assumption
| |
| 01:16 | alkisg: i would frequently want a server with a very stable version, and a chroot that has the newest versions of X.org available.
| |
| 01:16 | <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?
| |
| 01:17 | <vagrantc> alkisg: yeah, that's one down-side.
| |
| 01:17 | <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?
| |
| 01:18 | <vagrantc> alkisg: every day of the week.
| |
| 01:18 | <stgraber> every day ;)
| |
| 01:18 | <alkisg> Usually, when someone has e.g. hardy and wants a karmic chroot, he also updates ltsp on the server, doesn't he?
| |
| 01:18 | <vagrantc> every single day.
| |
| 01:19 | <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
| |
| 01:19 | <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.
| |
| 01:19 | <stgraber> (backup, production and test chroots)
| |
| 01:20 | <alkisg> OK, sorry for the wrong assumption
| |
| 01:20 | <vagrantc> alkisg: :)
| |
| 01:20 | <alkisg> Still. It's just settings. All of the current use cases will be supported.
| |
| 01:20 | <vagrantc> sure hope so
| |
| 01:20 | <alkisg> And I think the "up" sides are more significant than the "down" sides...
| |
| 01:21 | <johnny> /me really likes the "point tftp at chroot"
| |
| 01:24 | * 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 :) | |
| 01:24 | <johnny> it's what i did when doing the initial gentoo development
| |
| 01:25 | i had not tested ltsp-update-image, as we can't rely on our kernels having nbd..
| |
| 01:25 | altho.. i should try it again someday.. when i get a new pc
| |
| 01:29 | <vagrantc> alkisg: that's only because ltsp-update-image has some fixable faults.
| |
| 01:31 | <alkisg> vagrantc: sure, but the fact is that a newer chroot generates a pxelinux.cfg that an older server breaks
| |
| 01:31 | So that breaking can happen both ways...
| |
| 01:32 | 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?
| |
| 01:33 | * 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 | |
| 01:34 | <vagrantc> alkisg: the only breakage is in ltsp-update-kernels, no?
| |
| 01:34 | er, ltsp-update-image
| |
| 01:37 | <alkisg> vagrantc: yes, because that's where the "additional server knowledge" is applied
| |
| 01:37 | My main request is that we shouldn't have the code divided in many places
| |
| 01:38 | 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 ?
| |
| 01:38 | (and then copies the result?)
| |
| 01:40 | <vagrantc> seems like less disruption from the current behavior
| |
| 01:40 | has some drawbacks
| |
| 01:42 | <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.
| |
| 01:43 | 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".
| |
| 01:43 | <vagrantc> yes!
| |
| 01:43 | that was what i was trying to get at when i mentioned binaries
| |
| 01:45 | <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?
| |
| 01:46 | <vagrantc> oh!
| |
| 01:46 | is it really that slow?
| |
| 01:46 | i mean, ltsp-update-kernels is already rather slow... i can't imagine it gets any slower.
| |
| 01:47 | * alkisg looks at the current update-kernels hook code... | |
| 01:47 | <vagrantc> the slowest thing is the nbi.img creation... but that's not particularly slow
| |
| 01:47 | <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?)
| |
| 01:48 | OK... why not split it, and avoid creating an nbi.img whenever ltsp-update-kernels/image is ran?
| |
| 01:49 | Bah no that's not possible
| |
| 01:49 | An i386 server can't run something in a mac chroot
| |
| 01:50 | So ltsp-update-kernels/image can't rely on calling a script from the chroot
| |
| 01:51 | gfarras has quit IRC | |
| 01:51 | <alkisg> So it has no way to invoke a pxelinux.cfg/default update. It has to reuse what's already there.
| |
| 01:52 | gfarras has joined #ltsp | |
| 01:52 | <alkisg> So if it wants to update an IP, it'll have to sed through the file, resulting in the same problems.
| |
| 01:53 | <vagrantc> it's a mess
| |
| 01:55 | johnny has left #ltsp | |
| 02:00 | <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.
| |
| 02:03 | <vagrantc> alkisg: and will have to download a different script for each incompatible version? :)
| |
| 02:03 | <alkisg> vagrantc: do you imagine a settings file breaking so often?
| |
| 02:04 | <vagrantc> i sure hope not.
| |
| 02:04 | i've managed to keep the current approach for 3 years :)
| |
| 02:04 | maybe only 2.5
| |
| 02:05 | <alkisg> The opposite approach is on the patch I've sent: http://launchpadlibrarian.net/37642647/patch
| |
| 02:06 | I.e. the server putting the port in update-kernels.conf, and `sed`ing through the pxelinux.cfg/default file.
| |
| 02:06 | <vagrantc> the sed business is unpleasant...
| |
| 02:07 | <alkisg> Right. It should *at least* move to ltsp-update-kernels
| |
| 02:07 | <vagrantc> at any rate... i've got to get some sleep
| |
| 02:07 | <alkisg> OK, thank you for listening :)
| |
| 02:07 | <vagrantc> i'm sure in the end it'll be better than anyone expected :)
| |
| 02:07 | <alkisg> Should I start something?
| |
| 02:08 | <vagrantc> i'd say go for it.
| |
| 02:08 | <alkisg> Uhm... which one?
| |
| 02:08 | :D
| |
| 02:08 | <vagrantc> though all the current code is about pxelinux generation, which is really i386/x86_64 specific
| |
| 02:09 | <alkisg> Yeah, I'm uncomfortable with not knowing anything about powerpc etc
| |
| 02:09 | OK let's leave it for now and give it some more thought
| |
| 02:09 | Good night :)
| |
| 02:09 | <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...
| |
| 02:10 | there's nothing like writing code a few implementations in search of the best :)
| |
| 02:11 | <alkisg> Heh, ok then, I'll go for what I said earlier:
| |
| 02:11 | 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.
| |
| 02:11 | ...and I hope it'll always be text files, not binaries :)
| |
| 02:11 | <vagrantc> have fun!
| |
| 02:12 | vagrantc has quit IRC | |
| 02:12 | * alkisg forgot nbi.img, though... well I guess it'll be easily constructed from the update-kernels.conf file. | |
| 02:54 | alkisg has quit IRC | |
| 02:54 | alkisg has joined #ltsp | |
| 02:55 | alkisg has quit IRC | |
| 02:58 | alkisg has joined #ltsp | |
| 03:01 | makghosh has joined #ltsp | |
| 03:56 | makghosh has quit IRC | |
| 04:45 | alkisg has joined #ltsp | |
| 05:16 | alkisg has quit IRC | |
| 05:18 | alkisg has joined #ltsp | |
| 05:21 | Faithful has joined #ltsp | |
| 05:24 | ogra_ has quit IRC | |
| 05:25 | ogra_ has joined #ltsp | |
| 06:02 | alkisg has quit IRC | |
| 06:05 | alkisg has joined #ltsp | |
| 06:08 | highvolt1ge has joined #ltsp | |
| 06:12 | highvoltage has quit IRC | |
| 06:15 | johnny has joined #ltsp | |
| 06:20 | F-GT has joined #ltsp | |
| 06:36 | highvolt1ge has quit IRC | |
| 06:44 | sene has joined #ltsp | |
| 06:57 | <knipwim> thx for the commit access guys
| |
| 06:57 | the first ones are in
| |
| 07:39 | Selveste1_ has quit IRC | |
| 07:40 | highvoltage has joined #ltsp | |
| 07:57 | gfarras has quit IRC | |
| 07:58 | gfarras has joined #ltsp | |
| 08:00 | Faithful has quit IRC | |
| 08:03 | Faithful has joined #ltsp | |
| 08:14 | alkisg has quit IRC | |
| 08:20 | mikkel has joined #ltsp | |
| 08:29 | alkisg has joined #ltsp | |
| 08:37 | Ahmuck-Jr has quit IRC | |
| 08:37 | hersonls has joined #ltsp | |
| 08:41 | gfarras has quit IRC | |
| 08:42 | gfarras has joined #ltsp | |
| 08:43 | Selveste1_ has joined #ltsp | |
| 08:46 | alkisg1 has joined #ltsp | |
| 08:48 | alkisg has quit IRC | |
| 08:55 | highvoltage has quit IRC | |
| 09:02 | ltspbot has joined #ltsp | |
| 09:02 | <moldy> hi
| |
| 09:02 | hmm, dbus-daemon is running crazy here.. this happens occasionaly. ubuntu karmic. does anyone have any idea on what to do about this?
| |
| 09:03 | System load: 579.86
| |
| 09:05 | Selveste1_ has quit IRC | |
| 09:18 | highvoltage has joined #ltsp | |
| 09:20 | highvoltage has quit IRC | |
| 09:20 | highvoltage has joined #ltsp | |
| 09:22 | highvoltage has quit IRC | |
| 09:36 | highvoltage has joined #ltsp | |
| 09:38 | Kicer86 has joined #ltsp | |
| 09:46 | hersonls_ has joined #ltsp | |
| 09:46 | hersonls_ has joined #ltsp | |
| 09:54 | fritz has joined #ltsp | |
| 09: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".
| |
| 09:57 | The system is openSuSE 11.2 x64, btw.
| |
| 09:59 | <moldy> fritz: not familiar with kiwi-ltsp, but check the ssh keys
| |
| 10:00 | <fritz> How do I do that?
| |
| 10:00 | <moldy> fritz: ltsp-update-sshkeys
| |
| 10:00 | fritz: and afterwards, ltsp-update-image
| |
| 10:01 | <fritz> This is not known by kiwi-ltsp. :(
| |
| 10:02 | <moldy> fritz: also check the ssh log on the server
| |
| 10:03 | hersonls has quit IRC | |
| 10:04 | <fritz> sshd was not started. I startzed it now, and it looked better then. But finally the same.
| |
| 10:05 | <alkisg1> fritz: not many people here have experience with kiwi, maybe you can try asking in #kiwi-ltsp for this.
| |
| 10:05 | <fritz> Oh, thank you!
| |
| 10: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...
| |
| 10:14 | <fritz> I have to login on vt2., Which username&password must I use?
| |
| 10:15 | otavio has joined #ltsp | |
| 10: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... :-/
| |
| 10:26 | <moldy> fritz: if in doubt, set the password in the chroot and rebuild the image
| |
| 10:26 | fritz: the root password, that is.
| |
| 10:26 | you might also need to activate/unexpire the root account
| |
| 10:29 | DarKnesS_WolF has joined #ltsp | |
| 10:38 | fritz has quit IRC | |
| 10:46 | <DarKnesS_WolF> this is he channel for ltsp-cluster?
| |
| 10:49 | <alkisg1> I don't think a seperate channel exists, so yeah, this is it... not many people are around at weekends though.
| |
| 10:50 | <DarKnesS_WolF> :)
| |
| 10:50 | i do not have questions till now :)
| |
| 10:50 | i am just following the howto
| |
| 10:50 | but i am intersted in the project used to build lab for eductional using fat clients and now checking the new managment interface and such .
| |
| 10:51 | * alkisg1 also wants to check the fat client plugin, but couldn't make ldm work so far... | |
| 10:52 | <DarKnesS_WolF> alkisg1: what is ldm ?
| |
| 10:52 | <alkisg1> The login manager
| |
| 10:52 | alkisg1 is now known as alkisg | |
| 10:52 | <DarKnesS_WolF> alkisg1: fatclient was so easy to get it up and running. some problem but a hint , u need to mount proc inside the chroot manualy
| |
| 10:52 | ah did not reach that point now :)
| |
| 10:53 | will boot the virtual env. and check if i can get the 2nd node of the cluter running so i can test the whole system.
| |
| 10:53 | <alkisg> How did you get the fat client up and running? ltsp-build-client --fat-client?
| |
| 10:58 | Selveste1_ has joined #ltsp | |
| 11:03 | Selveste1_ has quit IRC | |
| 11:05 | hersonls_ has quit IRC | |
| 11:05 | hersonls_ has joined #ltsp | |
| 11:24 | Selveste1_ has joined #ltsp | |
| 11:24 | hersonls_ has quit IRC | |
| 11:25 | hersonls_ has joined #ltsp | |
| 11:27 | Selveste1_ has quit IRC | |
| 11:44 | sbalneav has joined #ltsp | |
| 11:46 | Selveste1_ has joined #ltsp | |
| 11:49 | alkisg has quit IRC | |
| 12:08 | Selveste1_ has quit IRC | |
| 12:13 | DarKnesS_WolF has quit IRC | |
| 12:27 | Ahmuck-Jr has joined #ltsp | |
| 12:31 | alkisg has joined #ltsp | |
| 12:33 | Ahmuck-Jr has quit IRC | |
| 13:16 | DarKnesS_WolF has joined #ltsp | |
| 13:23 | Ahmuck-Jr has joined #ltsp | |
| 13:49 | <stgraber> DarKnesS_WolF: hello, we don't have a separate channel for ltsp-cluster as most is common with LTSP (it's just a few more components to run standard LTSP). Though we are currently investing a lot of effort to improve it and make it a lot more user friendly ;) (understand that as in "full rewrite")
| |
| 13:54 | bobby_C has joined #ltsp | |
| 14:00 | Roel___ has joined #ltsp | |
| 14:02 | Kicer86 has quit IRC | |
| 14:08 | vagrantc has joined #ltsp | |
| 14:11 | <vagrantc> knipwim: ah, another pointer ... set your email in ~/.bazaar/bazaar.conf
| |
| 14:11 | email=Your Name <your@email>
| |
| 14:12 | <knipwim> done
| |
| 14:14 | <vagrantc> glad to see more work on Gentoo :)
| |
| 14:14 | <knipwim> also set append_revisions_only = True
| |
| 14:14 | * vagrantc dances | |
| 14:14 | <johnny> vagrantc, one day.. i'll get a new laptop and be able to work on it again..
| |
| 14:14 | now if only gentoo would just switch to upstart..
| |
| 14:15 | or even just use dracut for initramfs..
| |
| 14:15 | <vagrantc> we should probably come up with some coding guidelines, intro to our vcs repos, for new committers and such
| |
| 14:15 | * vagrantc feels like dracut is initramfs-tools done more ugly | |
| 14:16 | <johnny> coding guidelines.. i guess i don't ever tend to need explicit ones.. i just follow for the format in the most popular, often modified files..
| |
| 14:16 | <vagrantc> sure
| |
| 14:16 | <johnny> knipwim, just don't use bashisms and you'll probably be ok
| |
| 14:17 | <knipwim> so you told, only posix compliant stuff right?
| |
| 14:17 | <johnny> yes
| |
| 14:17 | <knipwim> working on a way to pass a built kernel to quickstart
| |
| 14:18 | and actually skip building the kernel, while still being able to emerge fuse
| |
| 14:18 | <johnny> i thought fuse could use build kernels?
| |
| 14:18 | isn't fuse in the default genkernel kernel?
| |
| 14:18 | Roel__ has quit IRC | |
| 14:18 | <johnny> we should probably just use the same kernel they use on the livecd.. that should definitely come with fuse
| |
| 14:18 | and also get squashfs as well
| |
| 14:20 | DarKnesS_WolF has quit IRC | |
| 14:21 | <knipwim> but if you want to build an environment without a kernel
| |
| 14:21 | because you already have a working kernel and initramfs
| |
| 14:21 | <johnny> use the one from the livecd..
| |
| 14:21 | err the same one they use for the livecd that is..
| |
| 14:21 | and then just emerge -B it
| |
| 14:22 | err
| |
| 14:22 | -K
| |
| 14:22 | iirc
| |
| 14:22 | <vagrantc> Ryan52: i'm wondering how difficult it'd be to write a program that edits /etc/password and /etc/group in C when /etc/ isn't writeable ... or how hard it would be to make a patch for usermod and company to not require a writeable /etc
| |
| 14:23 | <johnny> isn't there a reason they rename it to something else?
| |
| 14:23 | guess it should use /tmp
| |
| 14:23 | yeah.. why doesn't it use /tmp..
| |
| 14:23 | must be some good reason?
| |
| 14:23 | <vagrantc> johnny: there *might* be some security argument...
| |
| 14:24 | or it might just be legacy ugly behavior that nobody's bothered to fix.
| |
| 14:24 | i sohuld certainly file a bug.
| |
| 14:24 | <johnny> yeah.. ask a maintainer.. :)
| |
| 14:24 | gentgeen__ has quit IRC | |
| 14:25 | <knipwim> johnny: the minimal cd is used in the installer
| |
| 14:25 | <johnny> that's why i said livecd
| |
| 14:26 | <knipwim> just for a kernel with fuse compiled in?
| |
| 14:26 | <johnny> just for a kernel already compiled.. i thought that was the main point
| |
| 14:26 | passing a prebuild kernel
| |
| 14:27 | <knipwim> i'm doing a bind mount now
| |
| 14:27 | <johnny> knipwim, the common case is amd64 server, and i386 kernels
| |
| 14:27 | we can't just use the server kernel
| |
| 14:27 | so i don't see how that would help
| |
| 14:27 | <knipwim> good point, damn, didn't think of that
| |
| 14:27 | <johnny> err i386 clients..
| |
| 14:28 | <knipwim> hmmm, i'm only faking the fuse ebuild checks
| |
| 14:28 | not using the kernel for somthing else
| |
| 14:29 | i think it only checks the kernel config, and whether a kernel sources exists in /var/db/pkg
| |
| 14:36 | alkisg_ has joined #ltsp | |
| 14:46 | rhodan has joined #ltsp | |
| 14:50 | rhodan has quit IRC | |
| 14:50 | rhodan has joined #ltsp | |
| 14:51 | Ahmuck-Jr has quit IRC | |
| 14:53 | <Ryan52> vagrantc: I'm sure it's trivial.
| |
| 14:54 | <vagrantc> Ryan52: that's what i figured. i was thinking it would be really good to write something up for the non-writeable /etc case, and if it's good enough, use it in all cases.
| |
| 14:55 | though ideally, we'd get patches upstream to avoid the need for it
| |
| 15:01 | ltspbot has joined #ltsp | |
| 15:15 | ltspbot has joined #ltsp | |
| 15:24 | ltspbot has joined #ltsp | |
| 15:38 | Selveste1_ has joined #ltsp | |
| 15:46 | gentgeen__ has joined #ltsp | |
| 15:53 | bobby_C has quit IRC | |
| 16:06 | mikkel has quit IRC | |
| 16:08 | bobby_C has joined #ltsp | |
| 16:27 | bobby_C has quit IRC | |
| 16:40 | gfarras has quit IRC | |
| 16:40 | gfarras has joined #ltsp | |
| 16:46 | alkisg has quit IRC | |
| 17:08 | evilx has quit IRC | |
| 17:08 | evilx_ has joined #LTSP | |
| 17:20 | johnny has left #ltsp | |
| 17:47 | johnny has joined #ltsp | |
| 17:59 | vagrantc has quit IRC | |
| 18:56 | try2free has joined #ltsp | |
| 19:00 | sbalneav has joined #ltsp | |
| 19:15 | mushroomblue has quit IRC | |
| 19:16 | try2free has left #ltsp | |
| 19:18 | mushroomblue has joined #ltsp | |
| 19:21 | hersonls has joined #ltsp | |
| 19:26 | vagrantc has joined #ltsp | |
| 19:27 | lucascoala has joined #ltsp | |
| 19:29 | <sbalneav> Huh. Well, just got my first successful authentication attempt from libpam-sshauth.
| |
| 19:41 | <vagrantc> wow!
| |
| 19:41 | makin progress
| |
| 20:05 | <sbalneav> got somethin.
| |
| 20:05 | needs a ton more work.
| |
| 20:17 | alexqwesa has quit IRC | |
| 20:26 | alexqwesa has joined #ltsp | |
| 20:30 | lucascoala has quit IRC | |
| 20:34 | sene has quit IRC | |
| 20:53 | <sbalneav> \o/
| |
| 20:53 | * sbalneav dances like a madman | |
| 20:54 | <sbalneav> So, the libpam_sshauth that's currently in the tree can authenticate via ssh.
| |
| 20:54 | AND
| |
| 20:55 | if one turns on ChallengeResponseAuthentication yes in the sshd_config file
| |
| 20:55 | if you're password's expired it does a PROPER PAM PASSWORD CHANGE
| |
| 20:56 | Over the ssh connection.
| |
| 20:56 | No prompt scraping
| |
| 20:56 | no jiggery-pokery
| |
| 20:56 | * sbalneav is so happy | |
| 21:03 | johnny has left #ltsp | |
| 21:06 | vagrantc has quit IRC | |
| 21:06 | yanu has quit IRC | |
| 21:06 | Patina has quit IRC | |
| 21:06 | highvoltage has quit IRC | |
| 21:06 | staffencasa has quit IRC | |
| 21:06 | panthera has quit IRC | |
| 21:06 | Sarten-X2 has quit IRC | |
| 21:06 | Wastrel_ has quit IRC | |
| 21:06 | cyberorg has quit IRC | |
| 21:06 | knipwim has quit IRC | |
| 21:06 | jcastro has quit IRC | |
| 21:06 | loather-work has quit IRC | |
| 21:06 | sep_home has quit IRC | |
| 21:06 | primeministerp has quit IRC | |
| 21:07 | highvoltage has joined #ltsp | |
| 21:07 | staffencasa has joined #ltsp | |
| 21:07 | panthera has joined #ltsp | |
| 21:07 | Sarten-X2 has joined #ltsp | |
| 21:07 | Wastrel_ has joined #ltsp | |
| 21:07 | cyberorg has joined #ltsp | |
| 21:07 | primeministerp has joined #ltsp | |
| 21:07 | sep_home has joined #ltsp | |
| 21:07 | loather-work has joined #ltsp | |
| 21:07 | jcastro has joined #ltsp | |
| 21:07 | knipwim has joined #ltsp | |
| 21:09 | vagrantc has joined #ltsp | |
| 21:09 | yanu has joined #ltsp | |
| 21:09 | Patina has joined #ltsp | |
| 21:09 | <stgraber> sbalneav: yeah !
| |
| 21:11 | * stgraber got the new loadbalancer manager for ltsp-cluster to work as he wanted: https://ltsp-control01.stgraber.org/loadbalancer/overview (had to do a ton of JS ...) | |
| 21:18 | <sbalneav> COOL
| |
| 21:26 | <Ryan52> vagrantc: oh, sorry I forgot about our mini-conversation earlier (I had to leave). anyways, do you want me to do something?
| |
| 21:31 | johnny has joined #ltsp | |
| 21:45 | <stgraber> sbalneav: btw, that's using libssh2 right ?
| |
| 22:04 | <sbalneav> libssh
| |
| 22:04 | libssh2 didn't support challenge response authentication. :(
| |
| 22:14 | Well, that's enough for today.
| |
| 22:14 | yawn, to bed.
| |
| 22:27 | <Ryan52> huh. libssh. never heard of that before.
| |
| 22:36 | <vagrantc> sbalneav: rockin!
| |
| 22:37 | Ryan52: if you wouldn't mind looking into it ... the current approach with the passwd/group editing is *really* slow. slow enough that i complain.
| |
| 22:38 | Ryan52: so slow that i disabled localapps at freegeek so that it wouldn't do that
| |
| 22:38 | * Ryan52 wonders how we do it currently.. | |
| 22:39 | * vagrantc looks | |
| 22:40 | <vagrantc> Ryan52: ltsp-trunk/localapps/X01-localapps
| |
| 22:41 | Ryan52: the bulk of the code is what handles it ... and there's all sorts of crazy corner cases with usernames and groups with caps or no caps or mixed caps or spaces in them...
| |
| 22:42 | Ryan52: seems like it's the sort of thing that might be stretching the limits of shell...
| |
| 22:42 | <Ryan52> oh that's beautiful
| |
| 22:43 | <vagrantc> you see why i was thinking it might be worth looking at doing it another way :)
| |
| 22:45 | <Ryan52> ya. however I don't see why the poor person who wrote that didn't just fix usermod..
| |
| 22:46 | <vagrantc> i think it was myself and warren who wrote it ... and definitely the long-term approach would be to fix usermod.
| |
| 22:47 | <Ryan52> vagrantc: so what specifically is the problem with usermod?
| |
| 22:47 | <vagrantc> Ryan52: i think it writes a temporary file in /etc/
| |
| 22:49 | <Ryan52> so only lines 130 to 150 would be replaced?
| |
| 22:49 | <vagrantc> i think so, though there's possibly other optimizations that would be good too...
| |
| 22:49 | but i think that's the slowest bits
| |
| 22:54 | <Ryan52> I'll look later, I'm going out.
| |
| 22:54 | <vagrantc> Ryan52: thanks!
| |
| 23:30 | gfarras has quit IRC | |
| 23:33 | gfarras has joined #ltsp | |
| 23:40 | alkisg has joined #ltsp | |
| 23:57 | alkisg has quit IRC | |
| 23:59 | alkisg has joined #ltsp | |