IRC chat logs for #ltsp on irc.freenode.net (webchat)


Channel log from 10 January 2010   (all times are UTC)

00:23makghosh has quit IRC
00:28vagrantc 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:37makghosh 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:04makghosh 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:51gfarras 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:52gfarras 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:55johnny 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:12vagrantc 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:54alkisg has quit IRC
02:54alkisg has joined #ltsp
02:55alkisg has quit IRC
02:58alkisg has joined #ltsp
03:01makghosh has joined #ltsp
03:56makghosh has quit IRC
04:45alkisg has joined #ltsp
05:16alkisg has quit IRC
05:18alkisg has joined #ltsp
05:21Faithful has joined #ltsp
05:24ogra_ has quit IRC
05:25ogra_ has joined #ltsp
06:02alkisg has quit IRC
06:05alkisg has joined #ltsp
06:08highvolt1ge has joined #ltsp
06:12highvoltage has quit IRC
06:15johnny has joined #ltsp
06:20F-GT has joined #ltsp
06:36highvolt1ge has quit IRC
06:44sene has joined #ltsp
06:57
<knipwim>
thx for the commit access guys
06:57
the first ones are in
07:39Selveste1_ has quit IRC
07:40highvoltage has joined #ltsp
07:57gfarras has quit IRC
07:58gfarras has joined #ltsp
08:00Faithful has quit IRC
08:03Faithful has joined #ltsp
08:14alkisg has quit IRC
08:20mikkel has joined #ltsp
08:29alkisg has joined #ltsp
08:37Ahmuck-Jr has quit IRC
08:37hersonls has joined #ltsp
08:41gfarras has quit IRC
08:42gfarras has joined #ltsp
08:43Selveste1_ has joined #ltsp
08:46alkisg1 has joined #ltsp
08:48alkisg has quit IRC
08:55highvoltage has quit IRC
09:02ltspbot 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:05Selveste1_ has quit IRC
09:18highvoltage has joined #ltsp
09:20highvoltage has quit IRC
09:20highvoltage has joined #ltsp
09:22highvoltage has quit IRC
09:36highvoltage has joined #ltsp
09:38Kicer86 has joined #ltsp
09:46hersonls_ has joined #ltsp
09:46hersonls_ has joined #ltsp
09:54fritz 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:03hersonls 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:15otavio 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:29DarKnesS_WolF has joined #ltsp
10:38fritz 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:52alkisg1 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:58Selveste1_ has joined #ltsp
11:03Selveste1_ has quit IRC
11:05hersonls_ has quit IRC
11:05hersonls_ has joined #ltsp
11:24Selveste1_ has joined #ltsp
11:24hersonls_ has quit IRC
11:25hersonls_ has joined #ltsp
11:27Selveste1_ has quit IRC
11:44sbalneav has joined #ltsp
11:46Selveste1_ has joined #ltsp
11:49alkisg has quit IRC
12:08Selveste1_ has quit IRC
12:13DarKnesS_WolF has quit IRC
12:27Ahmuck-Jr has joined #ltsp
12:31alkisg has joined #ltsp
12:33Ahmuck-Jr has quit IRC
13:16DarKnesS_WolF has joined #ltsp
13:23Ahmuck-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:54bobby_C has joined #ltsp
14:00Roel___ has joined #ltsp
14:02Kicer86 has quit IRC
14:08vagrantc 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:18Roel__ 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:20DarKnesS_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:24gentgeen__ 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:36alkisg_ has joined #ltsp
14:46rhodan has joined #ltsp
14:50rhodan has quit IRC
14:50rhodan has joined #ltsp
14:51Ahmuck-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:01ltspbot has joined #ltsp
15:15ltspbot has joined #ltsp
15:24ltspbot has joined #ltsp
15:38Selveste1_ has joined #ltsp
15:46gentgeen__ has joined #ltsp
15:53bobby_C has quit IRC
16:06mikkel has quit IRC
16:08bobby_C has joined #ltsp
16:27bobby_C has quit IRC
16:40gfarras has quit IRC
16:40gfarras has joined #ltsp
16:46alkisg has quit IRC
17:08evilx has quit IRC
17:08evilx_ has joined #LTSP
17:20johnny has left #ltsp
17:47johnny has joined #ltsp
17:59vagrantc has quit IRC
18:56try2free has joined #ltsp
19:00sbalneav has joined #ltsp
19:15mushroomblue has quit IRC
19:16try2free has left #ltsp
19:18mushroomblue has joined #ltsp
19:21hersonls has joined #ltsp
19:26vagrantc has joined #ltsp
19:27lucascoala 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:17alexqwesa has quit IRC
20:26alexqwesa has joined #ltsp
20:30lucascoala has quit IRC
20:34sene 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:03johnny has left #ltsp
21:06vagrantc has quit IRC
21:06yanu has quit IRC
21:06Patina has quit IRC
21:06highvoltage has quit IRC
21:06staffencasa has quit IRC
21:06panthera has quit IRC
21:06Sarten-X2 has quit IRC
21:06Wastrel_ has quit IRC
21:06cyberorg has quit IRC
21:06knipwim has quit IRC
21:06jcastro has quit IRC
21:06loather-work has quit IRC
21:06sep_home has quit IRC
21:06primeministerp has quit IRC
21:07highvoltage has joined #ltsp
21:07staffencasa has joined #ltsp
21:07panthera has joined #ltsp
21:07Sarten-X2 has joined #ltsp
21:07Wastrel_ has joined #ltsp
21:07cyberorg has joined #ltsp
21:07primeministerp has joined #ltsp
21:07sep_home has joined #ltsp
21:07loather-work has joined #ltsp
21:07jcastro has joined #ltsp
21:07knipwim has joined #ltsp
21:09vagrantc has joined #ltsp
21:09yanu has joined #ltsp
21:09Patina 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:31johnny 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:30gfarras has quit IRC
23:33gfarras has joined #ltsp
23:40alkisg has joined #ltsp
23:57alkisg has quit IRC
23:59alkisg has joined #ltsp