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


Channel log from 11 May 2012   (all times are UTC)

00:03enyc has joined IRC (enyc!~enyc@muddle.enyc.org.uk)
00:35vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
00:41Parker955_Away is now known as Parker955
00:52Phantomas has left IRC (Phantomas!~Phantomas@unaffiliated/phantomas)
00:57cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 252 seconds)
01:03cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
03:09DIoX|DaZ has left IRC (DIoX|DaZ!~KaKa@server.civicclub.lt, Ping timeout: 245 seconds)
03:10Parker955 is now known as Parker955_Away
03:31DIoX|DaZ has joined IRC (DIoX|DaZ!~KaKa@server.civicclub.lt)
03:32trubbor has joined IRC (trubbor!~trubbor@173-21-2-181.client.mchsi.com)
04:56monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 255 seconds)
05:11monteslu has joined IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net)
05:34trubbor has left IRC (trubbor!~trubbor@173-21-2-181.client.mchsi.com, Quit: Leaving)
06:26leio has left IRC (leio!~leio@gentoo/developer/leio, Ping timeout: 252 seconds)
06:34alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
06:35
<alkisg>
knipwim: good morning, how do postinst scripts in Gentoo start services? "invoke-rc.d nbd-server start"? "service nbd-server start"?
06:35
Currently ltsp-update-image uses invoke-rc.d, but I don't see it available in Fedora...
06:44leio has joined IRC (leio!~leio@gentoo/developer/leio)
07:06ZyTer has left IRC (ZyTer!~oliv@wwwcache.univ-lr.fr, Remote host closed the connection)
07:06ZyTer has joined IRC (ZyTer!~oliv@wwwcache.univ-lr.fr)
07:11ddave7 has joined IRC (ddave7!~Miranda@ip-94-113-119-192.net.upcbroadband.cz)
07:20dobber has joined IRC (dobber!~dobber@213.169.45.222)
07:38
<Hyperbyte>
alkisg, I think most distros have "/sbin/service" commands. systemd supports that command as well
07:38
<alkisg>
In Ubuntu it's in /usr/sbin/, but I'm asking because debian policy recommends invoke-rc.d, but we're trying to be cross-distro...
07:38
So maybe using `service nbd-server start` is better
07:39
As long as Debian has that too
07:42Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@ip-80-238-8-128.bskyb.com)
07:56Da-Geek has joined IRC (Da-Geek!~Da-Geek@62.254.227.226)
08:12
<Hyperbyte>
[root@local ~]# locate invoke-rc.d
08:12
[root@local ~]#
08:12
That's Fedora. :)
08:33Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.71)
08:37ddave7 is now known as cerwi
08:38cerwi is now known as cubka
08:38cubka is now known as ddave7
08:54edubuntu has joined IRC (edubuntu!af647b5e@gateway/web/freenode/ip.175.100.123.94)
08:55edubuntu is now known as Guest11392
08:58Guest11392 has left IRC (Guest11392!af647b5e@gateway/web/freenode/ip.175.100.123.94, Client Quit)
09:15ddave7 is now known as dsorf
09:15Da-Geek has left IRC (Da-Geek!~Da-Geek@62.254.227.226, Ping timeout: 245 seconds)
09:17dsorf is now known as david_sorf
09:19david_sorf is now known as dsorf
09:30komunista has joined IRC (komunista!~slavko@adsl-195-168-232-196.dynamic.nextra.sk)
09:48Da-Geek has joined IRC (Da-Geek!~Da-Geek@62.254.227.226)
10:04komunista has left IRC (komunista!~slavko@adsl-195-168-232-196.dynamic.nextra.sk, Ping timeout: 260 seconds)
10:07komunista has joined IRC (komunista!~slavko@adsl-195-168-232-196.dynamic.nextra.sk)
10:25vmlintu__ has left IRC (vmlintu__!~vmlintu@nblzone-240-143.nblnetworks.fi, Ping timeout: 252 seconds)
10:36ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 248 seconds)
10:40vmlintu__ has joined IRC (vmlintu__!~vmlintu@nblzone-240-143.nblnetworks.fi)
10:56
<knipwim>
alkisg: rc-service nbd-server start
10:56
but it doesn't occur in the postinstall of a package
10:57
and, nbd-server has no init script in gentoo
10:59Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@ip-80-238-8-128.bskyb.com, Quit: Leaving)
11:09
<alkisg>
knipwim: so you'd need to run it manually? OK we can split it into a distro-specific, overridable function
11:14
<Hyperbyte>
nbd-server has no init script? So you'd need to manually start nbd server everytime you boot the server?
11:17Gremble has joined IRC (Gremble!~Ben@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com)
11:20
<knipwim>
i know, gentoo is a little slow
11:33LoveStorm has left IRC (LoveStorm!Storm@gateway/shell/trekweb.org/x-tupoppfrrwttdxat, Ping timeout: 272 seconds)
11:34Phantomas has joined IRC (Phantomas!~Phantomas@unaffiliated/phantomas)
11:46Da-Geek has left IRC (Da-Geek!~Da-Geek@62.254.227.226, Quit: Leaving)
12:05[GuS] has joined IRC ([GuS]!~MysT@213-117-16-190.fibertel.com.ar)
12:05[GuS] has joined IRC ([GuS]!~MysT@unaffiliated/gus/x-663402)
12:33LoveStorm has joined IRC (LoveStorm!Storm@gateway/shell/trekweb.org/x-mfquwkvsifquqlsh)
12:43bengoa has joined IRC (bengoa!~bengoa@2001:1291:229:2:216:cbff:feab:6cc9)
12:49dsorf has left IRC (dsorf!~Miranda@ip-94-113-119-192.net.upcbroadband.cz, Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
12:50ddave7 has joined IRC (ddave7!~Miranda@ip-94-113-119-192.net.upcbroadband.cz)
12:54ddave7 has left IRC (ddave7!~Miranda@ip-94-113-119-192.net.upcbroadband.cz, Ping timeout: 252 seconds)
12:58shogunx has left IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com, Ping timeout: 265 seconds)
13:19dead_inside has joined IRC (dead_inside!~dead_insi@76.75.3.174)
13:35
<alkisg>
I'm putting automatic backups in ltsp-update-image, so that it saves the old images in /opt/ltsp/images/arch.old. That can be overriden by --no-backup, but is there someone that wouldn't want that as the default?
13:36
I've also implemented a --revert switch, which reverts to the previous image, in case the new one has problems
13:36
The only downside is the bit of extra space in the server, so in that case --no-backup helps
13:37
(there have been many cases in this channel where just one chroot update + ltsp-update-image broke things...)
13:42LoveStorm has left IRC (LoveStorm!Storm@gateway/shell/trekweb.org/x-mfquwkvsifquqlsh, Ping timeout: 272 seconds)
13:46Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@ip-80-238-8-128.bskyb.com)
13:49vmlintu__ has left IRC (vmlintu__!~vmlintu@nblzone-240-143.nblnetworks.fi, Ping timeout: 248 seconds)
13:55shogunx has joined IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com)
14:04vmlintu__ has joined IRC (vmlintu__!~vmlintu@nblzone-240-143.nblnetworks.fi)
14:15Phantomas has left IRC (Phantomas!~Phantomas@unaffiliated/phantomas, Read error: Operation timed out)
14:16Phantomas has joined IRC (Phantomas!~Phantomas@unaffiliated/phantomas)
14:20trubbor has joined IRC (trubbor!~trubbor@173-21-2-181.client.mchsi.com)
14:22vmlintu__ has left IRC (vmlintu__!~vmlintu@nblzone-240-143.nblnetworks.fi, Ping timeout: 260 seconds)
14:24vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net)
14:24vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
14:27ddave7 has joined IRC (ddave7!~Miranda@ip-94-113-119-192.net.upcbroadband.cz)
14:35Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@ip-80-238-8-128.bskyb.com, Quit: Leaving)
14:48
<||cw>
alkisg: does it just keep one backup?
14:48
<alkisg>
||cw: yup
14:48
just the last one
14:49
To avoid having the users delete old backups etc after some time period
14:49
<||cw>
that sounds fine if it's done as a mv, leaving a client hanging for a while after an update eats the disk space anyway
14:49
and this way you'd also be able to see that in lsof
14:49
<alkisg>
True, but that space is freed after reboot, while now it won't
14:50
<||cw>
what's a reboot? :P
14:50
<alkisg>
Well, even a client reboot :) (for all of them, so that the old image isn't used anymore)
14:50
<||cw>
just saying, one kind of needs to leave 2-3x the image size as free space anyway, and this wouldn't really use any more
14:51
<alkisg>
Right
14:59
<Hyperbyte>
Does --revert unpack the image back to the chroot?
14:59
Because if you destroy your chroot with a chroot upgrade, you can --revert to the old image, but you'll still have a broken chroot.
15:00
<alkisg>
Hyperbyte: nope, the user can decide to do that manually, or decide to run `diff -r` to see wth broke it :)
15:01daya has joined IRC (daya!~daya@unaffiliated/daya)
15:01Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@ip-80-238-8-128.bskyb.com)
15:01
<alkisg>
Hyperbyte: sometimes we need uptime, a --revert helps there. Troubleshooting is another story.
15:01daya has left IRC (daya!~daya@unaffiliated/daya, Max SendQ exceeded)
15:01trubbor has left IRC (trubbor!~trubbor@173-21-2-181.client.mchsi.com, Remote host closed the connection)
15:02daya has joined IRC (daya!~daya@unaffiliated/daya)
15:02
<wafflecone>
I am seeking to have a boot splash screen on my thin clients. I messed with plymouth a bit yesterday and discovered that I have absolutely no clue what I am doing
15:02highvolt1ge has joined IRC (highvolt1ge!~highvolta@modemcable104.153-23-96.mc.videotron.ca)
15:03
<wafflecone>
does anyone here have boot splash screens working on the clients?
15:04
I was splasherrific on the server by the time I was done ... but the clients remained completely without splash
15:04
<alkisg>
wafflecone: is that debian? do non-ltsp debian installations have splash screens?
15:04
Ah, if by installing plymouth on the server you got the splash screen you want, then you just need to install it in the chroot and update your initramfs
15:05highvoltage has left IRC (highvoltage!~highvolta@ubuntu/member/highvoltage, Read error: Connection reset by peer)
15:06
<vagrantc>
alkisg: so, we gonna break things today? :)
15:07
<alkisg>
vagrantc: sure, do you have time for a joined try to create an ltsp-server-dnsmasq package?
15:07
I have some code here and there... :D
15:07
<vagrantc>
i should have most of the day
15:07
<alkisg>
vagrantc: the new ltsp-update-image parameters: http://paste.debian.net/168328/
15:08highvolt1ge has left IRC (highvolt1ge!~highvolta@modemcable104.153-23-96.mc.videotron.ca, Ping timeout: 260 seconds)
15:08
<alkisg>
...after thinking about it a bit more, I decided that I prefered to have the chroots as unnamed parameters... like `ls files`, we do need something to act upon, not just options... and it was already there in ltsp-update-image
15:09
But if you insist on --chroot, no other objections from me :)
15:09highvoltage has joined IRC (highvoltage!~highvolta@ubuntu/member/highvoltage)
15:09
<wafflecone>
alkisg It is debian. Debian does not feature a splash screen from a base install, but plymouth is available and seems to work on non-ltsp debian systems
15:10
it is entirely possible for me to use another distibution for ltsp. All it is doing is the rdesktop script.
15:11
<vagrantc>
wafflecone: have you installed plymouth in the LTSP chroot?
15:11
<wafflecone>
yes
15:11
<alkisg>
Did you update your initramfs after that?
15:11
...and ran ltsp-update-kernels etc?
15:12LoveStorm has joined IRC (LoveStorm!Storm@gateway/shell/trekweb.org/x-ndicnndczcvfmuho)
15:12
<wafflecone>
I think the update initramfs might be the gotcha
15:12
I will proceed for the assumption that that is what I missed
15:13
I have vmware snapshots all over the place, so it is a matter of selecting the right one
15:13
is plymouth necessary only in the chroot? or does it need to be in both?
15:14
<alkisg>
Chroot only
15:15
<wafflecone>
I will flail away at that a bit.
15:16
If I say anything apart from "SUCCESS!!!" in the next hour or two, remind me that I am not trying hard enough :)
15:19F-GT has left IRC (F-GT!~phantom@ppp121-44-133-130.lns20.syd7.internode.on.net, Read error: Operation timed out)
15:20Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@ip-80-238-8-128.bskyb.com, Quit: Leaving)
15:21
<alkisg>
vagrantc: should we start talking about the ltsp-server-dnsmasq packaging? Or would you like me to have something ready first? I can also continue with ltsp-update-kernels if you want to do it later on...
15:22
<vagrantc>
alkisg: sure, i can talk
15:24
<alkisg>
OK, what I'd like is for ltsp-server-dnsmasq to ship an /etc/dnsmasq.d/boot-server.conf configuration file, like that one, : http://paste.debian.net/168334/
15:24
...and to generate an /etc/dnsmasq.d/dhcp-ranges.conf file on postinst, with the current net id, and to restart dnsmasq, so that it works by default in proxy mode and in 192.168.67.x
15:26
/usr/share/ltsp/update-dhcp-ranges: http://paste.debian.net/168335/
15:26
The rest is trivial packaging... and we can postpone the pxe menus after debian freeze
15:27
<vagrantc>
want menus now! :)
15:28
<alkisg>
Haha you'd have to work for them, not enough time to get them ready on time, but I do have much code in ltsp-pnp trunk for that
15:28
I just wanted to rethink it a bit, in case a different package should be generated
15:28
And to think how those would bind with ltsp-update-image/kernels etc
15:29
<vagrantc>
sure
15:29
pxe-service line ... /pxelinux ... is the pxelinux.0 assumed?
15:29
<alkisg>
E.g. I'm about to remove --timeout from ltsp-update-kernels, I don't think it belongs there but in the pxe menus instead
15:29
Yes
15:30
But without the menus we'll use ltsp/<server-arch>/pxelinux instead, like we do now
15:30
If we want it to be a conffile, we'd have to do it in debian/rules, otherwise we can generate it on postinst
15:31
<vagrantc>
just making sure it's /pxelinux and not /pxelinux.0
15:31
<alkisg>
Yup
15:32
In PXE services, .0 is automatically added
15:32dobber has left IRC (dobber!~dobber@213.169.45.222, Remote host closed the connection)
15:32
<vagrantc>
i'd also name the dnsmasq.d files something with less potential for namespace collision ... ltsp-pnp-foo.conf
15:32
<alkisg>
About the depends/recommends part, I'd like to avoid isc-dhcp and tftp and just use dnsmasq out of the box, user can customize later if he wants
15:33
Sure
15:33
Not pnp, just ltsp
15:33* vagrantc already has such files
15:33
<vagrantc>
but you check for the presence, so thats fine
15:33dobber has joined IRC (dobber!~dobber@213.169.45.222)
15:35
<alkisg>
Some dnsmasq directives like e.g. tftp-root give syntax errors if they're defined multiple times
15:35
<vagrantc>
regarding dependencies, yeah, i'd just hard-depend on dnsmasq
15:35
<alkisg>
That's why I assumed that only one "boot-server.conf" file should exist
15:36
Would you have time to do part of the packaging, or only for review? /me is trying to gain some time for ltsp-update-kernels, testing etc...
15:37
<vagrantc>
i could work on the packaging ... you have a branch pushed somewhere?
15:37
also, do you have your new ltsp-update-image pushed somewhere?
15:37
<alkisg>
Currently for dnsmasq I only have the ltsp-pnp code, so the -pnp and pxe-menus parts need to be removed: https://code.launchpad.net/~alkisg/+junk/ltsp-pnp
15:38
I want to finish ltsp-update-kernels before pushing all the new stuff, i.e. ltsp-update-image, ltsp-update-kernels, and ltsp-cleanup
15:38
<vagrantc>
and should it be it's own source package?
15:38
<alkisg>
So I hope tomorrow
15:38
No, generated from the upstream LTSP source, with an ltsp-server dependency
15:38
The pxemenus could be a separate package, dunno
15:39
(ok lets leave those for later, too many changes right now to do them all concurrently)
15:39
<vagrantc>
so a new package, from the ltsp source. sounds good.
15:39
<alkisg>
Right
15:40
<vagrantc>
yes, let's forcus on wrapping up the dnsmasq hooks.
15:40
so the dnsmasq hooks currently default to the top-level pxelinux.0 ... which doesn't get generated by default
15:40
<alkisg>
We'd need to push update-dhcp-ranges, update our dnsmasq.conf example (so that we can copy that on postinst),
15:40
(it's essentially the same as my boot-server.conf above)
15:41
...that's about it from upstream, the rest would go in debian/
15:41
<vagrantc>
so we could make tthe dnsmasq.conf example a conffile, or do you think we'll need to edit it too often?
15:42
<alkisg>
I think the users would mostly edit the dhcp-ranges.conf, which would be dynamically generated
15:43
But for dnsmasq.conf to be a conffile, the correct architecture should be included there, /ltsp/i386/pxelinux
15:43
Hm, and some users might want an i386 chroot in an amd64 server, so those would change it anyway
15:43
<vagrantc>
ir it could manage a symlink from /pxelinux.0 to the appropriate places
15:43
<alkisg>
Maybe generate it on postinst for now, by sed'ing the example dnsmasq?
15:44
<vagrantc>
can use sed if we make it a conffile
15:44
can't
15:44
<alkisg>
I think I'd leave that part for the pxemenus package
15:44
(the /pxelinux.0 symlink)
15:44
<vagrantc>
makes sense ... but then we can't have a sane default
15:45
<alkisg>
We can make ltsp-update-kernels create a symlink if it's not there, and pxemenus will be ran afterwards anyway, so they'll update it
15:46
But we'd also need a /pxelinux.cfg symlink then
15:46
<vagrantc>
right
15:47
<alkisg>
It's getting a bit complicated, I think we should postpone it for when we start the pxemenus package
15:47
And default to <i386> or <arch> in the dnsmasq.conf for now
15:47
<vagrantc>
hmmm...
15:48
so, the complication is for the dhcp-boot= parameter?
15:49
we're already shipping ranges in a different file
15:49
<alkisg>
If we're not making it a conffile, there's no point in generating an "external" dhcp-ranges.conf, we can put those lines inside our dnsmasq.conf too
15:50
The arch (or path) is needed in the following lines:
15:50
dhcp-boot=/ltsp/pnp/pxelinux.0
15:50
dhcp-option=17,/opt/ltsp/i386
15:50
pxe-service=X86PC, "Boot from network", /ltsp/i386/pxelinux
15:50
<vagrantc>
then we need to manage it properly
15:50
i.e. respect admin changes and so on
15:51
which means we need to track admin changes
15:52
<alkisg>
Or we could just not ship an update-dhcp-ranges tool, and only generate dnsmasq.conf on postinst
15:52
<vagrantc>
i.e. if we're going to change it, we'd need to track it with ucf ...
15:52
generate once, then expect the admin to manually update it ... that's safe
15:52
<alkisg>
Yup, good enough for me
15:53
<vagrantc>
though if we introduce changes that we want the admin to include, it's ugly.
15:53F-GT has joined IRC (F-GT!~phantom@ppp121-44-125-132.lns20.syd6.internode.on.net)
15:53
<alkisg>
(06:53:05 μμ) vagrantc: though if we introduce changes that we want the admin to include, it's ugly. ==> /me didn't get that part
15:54
<vagrantc>
say you change the defaults... i.e. dhcp-option=17,/opt/ltsp/crazynewpath/i386
15:54
or you've got dhcp-boot=/ltsp/pnp/pxelinux.0 to dhcp-boot=/ltsp/i386/pxelinux.0
15:54
or gpxelinux.0
15:55toscalix has joined IRC (toscalix!~toscalix@114.202.219.87.dynamic.jazztel.es)
15:55
<alkisg>
If we only generate /etc/dnsmasq.d/ltsp-something.conf on ltsp-server-dnsmasq.postinst, and only if it doesn't exist, and if we never change it again, is there a problem?
15:55
<vagrantc>
nope
15:56
other than our potential foolish assumption that we'll never want to change it again :)
15:56
so we just need to be careful about what we put in there, then.
15:57markit has joined IRC (markit!~marco@88-149-177-66.staticnet.ngi.it)
15:57
<alkisg>
I don't think we're ready to ship a conffile yet, as it'd be better to do it when the pxelinux menus package is ready, and after some user feedback for the default dnsmasq we ship...
15:57
...so yup let's try to be careful about what we put there
15:58
<vagrantc>
sounds good.
15:59
<alkisg>
So we only need to update ./server/doc/examples/dhcpd-dnsmasq and copy it on postinst, and add the proxy dhcp-ranges at the end of it
15:59
The code to detect the proxy dhcp ranges is in update-dhcp-ranges, but we don't need all that file, just the loop
15:59
<vagrantc>
why not the whole file?
16:00
<alkisg>
It creates an /etc/dnsmasq.d/dhcp-ranges.conf, we decided using a single file instead, right?
16:00
<vagrantc>
ah, yes, we could go that route
16:02freedomrun has joined IRC (freedomrun!~quassel@BSN-142-160-67.dial-up.dsl.siol.net)
16:02
<alkisg>
I don't think we have any missing bits, do we?
16:02
<vagrantc>
nope
16:02
<alkisg>
It's a simple package, depend: dnsmasq, conflict: isc-dhcp, copy the dnsmasq.conf on postinst, put the range, restart dnsmasq, done
16:03
(and of course depend:ltsp-server)
16:03
<vagrantc>
alkisg: what if the entire thing was a script that we call from postinst?
16:03
so we force isc-dhcp-server out ... ok.
16:03
<alkisg>
That's why I created a separate update-dhcp-ranges script, but now by only keeping the loop it seems too small to be a separate file...
16:04freedomrun is now known as freedomrun_
16:04freedomrun_ is now known as freedomrun
16:05
<vagrantc>
well, having it as a script means it can be manually re-run more easily than as a postinst script
16:05
and also slightly more cross-distro, if other distros support /etc/dnsmasq.d/
16:07
<alkisg>
So basically it's this: http://paste.debian.net/168339/
16:07
<vagrantc>
even if it's just a cp example.conf /etc/dnsmasq.d/ltsp.conf ; sed -i -e "s,dhcp-ranges=,dhcp-ranges=..."
16:07
<alkisg>
s/boot-server.conf/some-other-name.conf/
16:08
<vagrantc>
sure
16:08freedomrun has left IRC (freedomrun!~quassel@BSN-142-160-67.dial-up.dsl.siol.net, Remote host closed the connection)
16:08
<vagrantc>
i think that makes sense as a separate script
16:08
<alkisg>
OK, we can push that upstream then
16:08
generate-dnsmasq-conf or something
16:09
<vagrantc>
update the existing ltsp-dnsmasq.conf (or whatever it's called?)
16:09
<alkisg>
I thought we wouldn't ever change it, only generate it if it doesn't exist...
16:09
<vagrantc>
alkisg: so, you want me to make the commits, or you got it?
16:09
alkisg: update in ltsp-trunk
16:10
<alkisg>
If you could, I'd be grateful, my thoughts are in ltsp-update-image/kernels now
16:11
<vagrantc>
alkisg: hopefully i've got this right, then :)
16:14
<alkisg>
Ouch, I think client/update-kernels will need some updating too... :-/ Hope to have all of them ready in 2 days
16:14
<vagrantc>
cool
16:15ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de)
16:15
<vagrantc>
oh, this makes me want to implement your new directory layout...
16:16
<alkisg>
Yes please :D
16:17
When we're done with ltsp-server-dnsmasq and I try to make a diff for stgraber to include it to Ubuntu, I'd like to try to minimize the debian packaging delta as well, so that would help
16:17
<vagrantc>
i'll restructure later ... one thing at a time
16:19
<[GuS]>
Hi
16:19
knipwim: are you there?
16:21
<knipwim>
yeah
16:22
just came out of work and did the groceries :)
16:22
<[GuS]>
knipwim: :) how are you?
16:22
<knipwim>
fine i guess, busy and tired from the workweek
16:23
you?
16:23
<[GuS]>
knipwim: well, you know me... i have a new LTSP5 problem :P
16:24
Fails in kernel compilation... don't know why...
16:24
<vagrantc>
alkisg: /etc/dnsmasq.d/ltsp-server-dnsmasq.conf ?
16:24
alkisg: then it matches the package name
16:25
<alkisg>
vagrantc: sure, then it can have the same name in the upstream tree too
16:25
<vagrantc>
ltsp-update-dnsmasq-conf ?
16:25
<[GuS]>
knipwim: just in case http://pastebin.com/mxaaaakL
16:25
<vagrantc>
for the script name
16:25
<[GuS]>
knipwim: my server is Gentoo 64, recently installed
16:26
brb
16:26
<vagrantc>
alkisg: we should probably leave it out of doc/examples, just in case one of the debhelper things decides to compress it.
16:28
<alkisg>
vagrantc: we can use zcat in that case though, or tell debhelper not to compress examples
16:29
<vagrantc>
alkisg: well, i'm thinking that ltsp-server should ship it in examples, but ltsp-server-dnsmasq should shhip it's own copy in /usr/share/ltsp/ ?
16:29* alkisg leaves it up to vagrantc to decide as he's more experienced with packaging :)
16:30daya has left IRC (daya!~daya@unaffiliated/daya, Quit: Leaving)
16:31
<boospy>
Does anybody use Thinclients with someone Fatclientapplication?
16:31
<vagrantc>
alkisg: it keeps the code a lot simpler :)
16:31
<boospy>
For example a 3D Game?
16:32
<vagrantc>
boospy: that's called localapps
16:32
!localapps
16:32
<ltsp`>
vagrantc: localapps: to access a tutorial on setting up localapps on jaunty, see https://help.ubuntu.com/community/UbuntuLTSP/LTSPLocalAppsJaunty
16:33
<vagrantc>
wow. jaunty.
16:33
<alkisg>
vagrantc: man dh_compress => files in usr/share/doc that are larger than 4k in size ==> I don't think we'll ever pass that size
16:33
<vagrantc>
alkisg: that's what it does currently. with putting it in /usr/share/ltsp we'll know it will stay safe
16:33mikkel has joined IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk)
16:34
<Gremble>
well here we go, I have a server that needs updating to the latest Ubuntu LTS from the last one
16:34
chroot first?
16:34
<vagrantc>
alkisg: so the old config has a few special cases for pxe, etherboot, ltsp for the dhcp-boot line
16:35
<boospy>
ltsp: Thanks i will test it this day :)
16:35
<alkisg>
vagrantc: I think those should be kept, they're nice even though etherboot isn't supported and the ltsp line won't work in proxydhcp mode as the dhcp server isn't contacted
16:35
vagrantc: ah let's remember to put IPAPPEND=3 in /etc/ltsp/ltsp-update-image.conf too
16:35
<vagrantc>
alkisg: oh.
16:35
<alkisg>
On postinst
16:36
<vagrantc>
that's the one that passes all the network configuration?
16:36
<alkisg>
Yes, it's necessary in proxy mode
16:36
<vagrantc>
or just thhe mac address?
16:36
<alkisg>
The mac is IPAPPEND=2
16:36
<vagrantc>
i didn't remember that ipappend=3 was necessary for proxy mode
16:36
otherwise you might get a different dhcp server...
16:36
<alkisg>
Either that, or to declare nbdboot=<ip>
16:37
*nbdroot=
16:37
<vagrantc>
it's always seemed kind of silly to run dhcp twice
16:37
<alkisg>
pxelinux is trying to pass the dhcp info to the kernel
16:37
Then we can write the lease to the chroot and call dhclient from the real root
16:39
<vagrantc>
we'll also need to conflict with tftpd-hpa and atftpd
16:40
<alkisg>
I'm not sure about that, if someone wants to add them manually later on maybe we should allow him to
16:40
<vagrantc>
if dhclient gets a different ip, though, things will not be good.
16:40
<alkisg>
(by also disabling #enable-tftp in dnsmasq)
16:40
<vagrantc>
alkisg: hmmmm...
16:40
alkisg: the same logic could apply for DHCP, no?
16:40
<alkisg>
Not until isc-dhcp supports proxy...
16:41
I imagine that one would install ltsp-server-dnsmasq primarily for its dhcp functionality
16:41
<vagrantc>
and what about port=0 ?
16:41
<alkisg>
Otherwise he can install ltsp-server-standalone, which depends on isc-dhcp
16:41
<vagrantc>
so dnsmasq will fail to start if they have tftp or bind or dhcp running.
16:41
if we went with the default config
16:42
<alkisg>
I think we shouldn't provide DNS server functionality in our dnsmasq configuration
16:42Gremble has left IRC (Gremble!~Ben@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com, Quit: I Leave)
16:42
<alkisg>
If someone wants that, he can add it in a separate file (e.g. sch-scripts), or edit the configuration manually
16:42
And it also has problems with ubuntu and the local resolver, so I'd prefer to avoid activating dns by default
16:43
<vagrantc>
so we leave it commented out? or we disable it?
16:43
<alkisg>
Ah sorry, dns is on by default
16:43
Hm
16:43
<[GuS]>
knipwim: in fact, is failing in Building initramfs
16:45
<knipwim>
[GuS]: i looked at your log, but couldn't find anything ltsp related
16:45
<[GuS]>
yeah :(
16:45
<knipwim>
iin fact, i couldn't find any obvious error
16:45
<markit>
alkisg: I had to surrender to the resolver mechanism with my dnsmasq install
16:45
<knipwim>
[GuS]: did you ask in #gentoo?
16:45
<[GuS]>
knipwim: weird, since that kernel compiles just fine
16:46
is the kernel i have in the server
16:46
knipwim: i will now
16:46
<alkisg>
vagrantc: ...I think dns caching will help fat clients a lot, so I'd go with this, if it's good enough for you too: http://paste.debian.net/168342/
16:46
<knipwim>
[GuS]: i gather you use the kernel config in the build process?
16:46
<alkisg>
vagrantc: Unfortunately that leaves thin clients out, but there are security concerns there, so it might be for the best to leave them out by default
16:46
<knipwim>
and have the gentoo-sources version to download hardcoded in your config?
16:47
<[GuS]>
knipwim: yes i do, and that config works
16:47
<alkisg>
vagrantc: either that, or port=0, whichever you prefer
16:47
<[GuS]>
Also trieed already without the config
16:47
knipwim: is not related that the server has gentoo 64 bits right?
16:48
<alkisg>
markit: with that conflg the resolver works fine
16:48
With network-manager and everything, no conflicts
16:48
<markit>
alkisg: also, don't know if you have ad a look at it, or is not interesting for you since you leave networkmanager, the only "safe" place to put upstream dns is in /etc/network/itnerfaces
16:48
<vagrantc>
alkisg: just trying to merge your new config into the existing dhcpd-dnsmasq config
16:49
<knipwim>
[GuS]: hmm, could be, i don;t know if the config files are interchangeable
16:49
<alkisg>
markit: we're not using /etc/network/interfaces, teachers don't like to edit configuration files and the nm-applet is handy to see if you're online, see your IP etc
16:49
<[GuS]>
knipwim: the config file is for x86
16:51
<knipwim>
[GuS]: http://forums.gentoo.org/viewtopic-t-772442-start-0.html
16:52
<[GuS]>
lets see
16:52
knipwim: but the kernel config is from x86 kernel
16:53
Indeed i use it on 32bits instalations
16:55monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 255 seconds)
16:57
<knipwim>
[GuS]: i see no reason why that shouldn't work
16:58
<[GuS]>
yeah... :S
16:58ddave7 has left IRC (ddave7!~Miranda@ip-94-113-119-192.net.upcbroadband.cz, Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
16:59ddave7 has joined IRC (ddave7!~Miranda@ip-94-113-119-192.net.upcbroadband.cz)
17:00
<knipwim>
[GuS]: any luck on #gentoo?
17:01
<[GuS]>
knipwim: nobody replies
17:01
I am trying again with not config...
17:01
but anyways, is not the kernel that fails
17:01
as far i can see, when building initramfs
17:02
<knipwim>
http://forums.gentoo.org/viewtopic-p-7025856.html
17:03ddave7 has left IRC (ddave7!~Miranda@ip-94-113-119-192.net.upcbroadband.cz, Ping timeout: 252 seconds)
17:04
<[GuS]>
knipwim: ok, i should add that in the the quickstart profile then
17:07
<knipwim>
what?
17:09ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Excess Flood)
17:09
<knipwim>
[GuS]: something like http://pastebin.com/EQXNwdaP ?
17:10zrpmz has joined IRC (zrpmz!d170f8b2@gateway/web/freenode/ip.209.112.248.178)
17:10
<[GuS]>
knipwim: yes
17:10
mm is already?
17:10ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de)
17:11
<[GuS]>
bash.. i didnt saw it in profile.
17:11
bah*
17:11
<zrpmz>
Is it possible to take a chromium .img file and rename it to i386.img and then put it in the /opt/ltsp/images folder and have ltsp boot straight into chromium?
17:13
<knipwim>
[GuS]: what are you saying?
17:14
[GuS]: what profile are you using?
17:14
<[GuS]>
quickstart
17:14
<knipwim>
ltsp-server 5.2 or 5.3 ?
17:14
<[GuS]>
5.2
17:15
<knipwim>
my lines should by somewhere in the pre_install_portage_tree() function
17:15
in your quickstart profile file
17:17
<zrpmz>
Is there a way to create a custom ltsp pxe boot image? not one that is downloaded during setup. If so is there a writeup somewhere?
17:18
<[GuS]>
knipwim: yep, added there. Now will see
17:18* [GuS] >>> Emerging (2 of 2) sys-kernel/genkernel-3.4.21.2
17:18
<[GuS]>
:D
17:19monteslu has joined IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net)
17:20
<knipwim>
[GuS]: if it works it's pretty weird
17:20
i rebuild a client just a week ago with probably a similar stage3
17:21
<[GuS]>
yeah :S
17:21
will see
17:21
<vagrantc>
alkisg: ok, so i've got the update script, and i've updated the dhcpd-dnsmasq config file in ltsp-trunk ... the rest is just packaging, yes?
17:22
<alkisg>
vagrantc: yup... /me checks.....
17:24
vagrantc: sed -i -e "s/dhcp-range=.*,proxy.*/dhcp-range=$subnet,proxy/g" "$conf"
17:24* vagrantc wonders if ftp-masters will balk at a package with a single script
17:24
<alkisg>
So that it doesn't override the 192.168.67.x subnet of the second nic
17:24
<vagrantc>
doh.
17:24
<alkisg>
Untested though
17:24
<vagrantc>
you can have multiple dhcp-range stanzas?
17:25
<alkisg>
Yup
17:25
pxe-service=X86PC, "Boot from network", /pxelinux ==> /ltsp/i386/pxelinux
17:25
<vagrantc>
oh, that's a bit different, then
17:25
<alkisg>
Or just add it at the end of the file (put the other dhcp-ranges near the end to match)
17:26
<vagrantc>
yeah, i assumed you could only have one.
17:26
alkisg: i also wanted to have the proxy entry show up near the proxy comments
17:26
<alkisg>
Those can be moved at the end too
17:27
(in the example)
17:27
<vagrantc>
in the example, though, for not using dnsmasq-conf ... you'd want them to be near the top of the config so that they're more visible
17:28
alkisg: i can do a sed more like what you've got there.
17:28
<alkisg>
OK, don't forget to change the grep above too
17:28
<vagrantc>
i might ditch the grep and just rewrite them all
17:28
since we're copying from a template
17:29
hm... we'll see.
17:29
<alkisg>
Just sed specifically "#dhcp-range=10.0.2.2,proxy" then
17:30
<vagrantc>
or #dhcp-range.*proxy"
17:30
we just need to make sure we don't break the templtae
17:31
<alkisg>
vagrantc: since you went for port=0, there's no need for the last 3 lines
17:31
Remove them completely
17:31
<vagrantc>
i might avoid use the the continue inn the case statement
17:32
<[GuS]>
knipwim: worked
17:32
<vagrantc>
alkisg: but if someone comments it out, they'd be good to have there?
17:32
alkisg: does it hurt to have them there still?
17:32
<alkisg>
vagrantc: if they're commented out by default, it's fine, otherwise we lose some functionality
17:32
<[GuS]>
knipwim: ltsp installation finished, but didnt installed any package :S
17:33
<alkisg>
vagrantc: qemu and whatever else might use lo for internal networking
17:33
<vagrantc>
alkisg: ok.
17:34
<knipwim>
[GuS]: you build from binary packages?
17:34
<[GuS]>
knipwim: yes, but my server is 64 bts
17:34
i will check if everything is fine
17:34
<knipwim>
[GuS]: i mean, do you use binary packages from /usr/portage/packages/i686?
17:34
in the client install
17:35
<vagrantc>
alkisg: so, we can assume to leave in the 192.168.67 dhcp-range entry? we don't have to re-add it?
17:37
<[GuS]>
knipwim: i dont know...
17:38
<knipwim>
what does ls /usr/portage/packages/i686 give ?
17:38
<[GuS]>
and i dont have packages there, only the ones from ltsp
17:38
Packages app-admin app-arch sys-kernel
17:38
<vagrantc>
alkisg: ah, so we'll have to add the dhcp-proxy entries, in case they have multiple networks
17:38artista_frustrad has joined IRC (artista_frustrad!~fernando@200.247.43.2)
17:38
<vagrantc>
alkisg: actually, this will break if they change networks, won't it ?
17:39
<[GuS]>
since my installation is 64 bits, i do have under packages/
17:39
<knipwim>
[GuS]: after which step does it actually start closing?
17:40
it seems like it fails after building the kernel, those packages are already in your packages/i686 dir
17:40
<vagrantc>
alkisg: and the way it's currently written, won't fix it by running again
17:40
<[GuS]>
knipwim: http://pastebin.com/9A6xAVG0
17:41
also: install_extra_packages(): no extra packages specified
17:41
weird
17:43
<knipwim>
can you post your quickstart profile?
17:43
<[GuS]>
yes
17:43
<zrpmz>
Is there a way to create a custom ltsp pxe boot image? not one that is downloaded during setup. If so is there a writeup somewhere?
17:44
<||cw>
zrpmz: not sure what you mean
17:45
<[GuS]>
knipwim: http://pastebin.com/FA8DzJ9c
17:45
<||cw>
you have to download a certain amount of kernels and packages at a minimum anyway
17:45
<zrpmz>
||cw: when you install ltsp you have to download a chroot for the thin clients, is there a way to create one from scratch?
17:45
Hope that clarifies
17:46
<||cw>
using ltsp-build-client?
17:47
<zrpmz>
yes
17:49
<alkisg>
(08:35:34 μμ) vagrantc: alkisg: so, we can assume to leave in the 192.168.67 dhcp-range entry? we don't have to re-add it? => yes
17:49
(08:38:39 μμ) vagrantc: alkisg: ah, so we'll have to add the dhcp-proxy entries, in case they have multiple networks ==> yes
17:49
<||cw>
I'm not familiar with the details, but pretty it uses debootstrap and download packages and installs them in a chroot
17:49
<alkisg>
(08:38:58 μμ) vagrantc: alkisg: actually, this will break if they change networks, won't it ? ==> yes
17:50
<zrpmz>
Do you know where I can find a good writeup on how to do that?
17:50
<||cw>
the man page?
17:50
<alkisg>
vagrantc: but we don't want to ever modify the file after postinst, right? So that part would go in the wiki, not in a script...
17:51
zrpmz: you can chroot into the image and add/remove packages as you wish
17:51
No need to search for an "alternative way to build it"
17:51
There's also support for additional packages in the ltsp-build-client commandline
17:51
<vagrantc>
alkisg: seems to be the ltsp-update-sshkeys problem all over again
17:51
<alkisg>
vagrantc: the proxy mode isn't for "roaming ltsp servers", that's another part
17:52
It's supposed to be a static network, same as in isc-dhcp
17:52
<vagrantc>
ok.
17:52
<zrpmz>
Thanks alkisg, I have done that but I was hoping to learn how to build one from scratch. Is ther any information on the net other than the debootstrap manpage?
17:52
<||cw>
zrpmz: the client image is pretty minimal by default, what problem are you trying to solve?
17:52
<vagrantc>
we'll just have to document the behavior
17:52
<alkisg>
vagrantc: Otherwise if I go to a cafe and get to the internet with my laptop, I'd be a proxy dhcp server there too, and I wouldn't want that
17:53
zrpmz: to build ltsp chroots, or chroots in general?
17:53
<||cw>
zrpmz: instead of building from scratch, moding ltsp-build-client to suit probably make more sense, and in the process you'd likely learn a lot about how it works
17:53
<knipwim>
[GuS]: anything special in your ${PACKAGES}?
17:53
<zrpmz>
||cw: I am trying to learn to build an image so I can use ltsp with any flavor of linux, including those that that don't have packages for ltsp.
17:54develtech has joined IRC (develtech!~develtech@39.47.221.165)
17:54
<[GuS]>
knipwim: nope
17:54
<zrpmz>
alkisg: both ltsp chroots and chroots in general
17:54
<||cw>
zrpmz: ah, that's quite a different question. you'd need to port the ltsp-client components to that distro's config and scripting layouts
17:54
<[GuS]>
knipwim: # PACKAGES="xterm rdesktop"
17:54
didnt touched
17:55
<alkisg>
zrpmz: for chroots in general you should be asking in your distro channel, while for ltsp chroots you should be reading the ltsp-build-client code to add support in it for you distro of choice
17:56
<||cw>
the main core distro's are all there, so adding support for Mint or Scientific, for example, should really be pretty easy
17:56
Slack could be a fun one though
17:56
and by fun I mean OH DEAR GOD WHY
17:57
<[GuS]>
knipwim: the list of packages are included in quickstart install_step module?
17:57
<knipwim>
yes
17:57
i was just reading through the code myself
17:58
<[GuS]>
me too..
17:58
<knipwim>
did you do any modding on quickstart?
17:58
<vagrantc>
alkisg: i guess i'll add a --regenerate option that will overwrite the changes
17:59develtech has left IRC (develtech!~develtech@39.47.221.165, Ping timeout: 260 seconds)
17:59
<zrpmz>
So what I am getting from this is I need to be able to look at the code for ltsp-build-client and understand what I am looking at. I think that is a little over my head at this point so I guess that is what I needed to know, thanks!
17:59
<vagrantc>
alkisg: what's the *[!0-9.]* match for ?
17:59
alkisg: ipv6 networks?
18:00
<alkisg>
vagrantc: also the line with the "default" on top
18:00
zrpmz: if you ask more specific questions, like "I want to run ltsp on this distro", you might get more specific answers
18:00
Or, "I don't want to run ltsp, I just want to do this ...xxx..."
18:01
<[GuS]>
knipwim: nope, just what you told me about genkernel
18:01
<boospy>
ltsp: Oh my god localapps works fine, great, many thanks!
18:02
<knipwim>
[GuS]: i mean the quickstart tool and modules themselves
18:02
<[GuS]>
knipwim: not at all
18:02
my version sys-apps/quickstart -> 20101128-r2
18:02
<||cw>
zrpmz: it's just bash scripts
18:02
<vagrantc>
alkisg: i'm switching back to just echo the proxy line at the bottom for now... having a hard time getting sed to insert where i want it.
18:03
<alkisg>
vagrantc: sounds good, if people want to regenerate they can just delete the file before running it
18:04
<vagrantc>
alkisg: what about an --overwrite parameter?
18:04
alkisg: just so they don't have to know which file to delete
18:04
or --regenerate
18:04
<zrpmz>
||cw: That I could probably do, Where can I get the scripts. alkisg: I was wanting to try and use chromiumOS with ltsp,
18:04
<[GuS]>
knipwim: dont worry to much anyways, i will try to figure it by myself. I will mount chroot and see. I dont want to take your time
18:04
<alkisg>
Sure, that'd work too, we could also refine it later, don't worry too much about it
18:04
vagrantc: ^
18:04
<vagrantc>
sure
18:04
<knipwim>
[GuS]: it's cool
18:05
[GuS]: you could try kicktoo also
18:05
that's stable also nowadays, 0.4.2
18:06
zrpmz: here's the code https://code.launchpad.net/ltsp
18:06
<[GuS]>
Ok, i will test now
18:06
<knipwim>
zrpmz: ltsp-trunk to start with
18:06
<zrpmz>
thanks knipwm
18:07
<alkisg>
zrpmz: making chromiumos netboot would be rather easy, while porting ltsp to chromiumos sounds much harder
18:07
<zrpmz>
alkisg: how would I go about that, or where is there info on netbooting?
18:08
<alkisg>
For netbooting chromiumos, you should be asking in their channel, not here
18:08
It's distro-specific
18:08
You'd need support from whatever they use as the initramfs etc
18:08
Maybe they already support it, ask and see
18:09
<zrpmz>
alkisg: Alright, I'll give that a shot. Thanks for the info guys!
18:10
<vagrantc>
alkisg: with --overwrite we could have an if-up.d hook that runs whenever an interface goes up/down
18:10
<knipwim>
zrpmz: in the process of making our new wiki, we also plan to have packaging instructions
18:10
<vagrantc>
alkisg: for people who want it to "just work"
18:11
which is maybe slightly evil, but often probably fine.
18:11
<knipwim>
zrpmz: for other distro's
18:11
<alkisg>
vagrantc: http://bazaar.launchpad.net/~alkisg/+junk/ltsp-pnp/view/head:/debian/if-up
18:11
vagrantc: if we're going there, we might as well use a dhcp-ranges.conf file
18:11
<vagrantc>
alkisg: i don't think it should be enabled by default
18:11
alkisg: for the reasons you suggested
18:11
<knipwim>
zrpmz: if you're serious about packaging for another distro, i can let you proofread something in a couple of days
18:12
<vagrantc>
alkisg: although maybe we should split the config out ...
18:12
<alkisg>
vagrantc: true, maybe with an option in /etc/ltsp/ltsp-update-dhcp-ranges.conf or so, but the if-up script can still be there and do nothing
18:12
<vagrantc>
alkisg: right.
18:13
<alkisg>
vagrantc: In ltsp-pnp I think I put that option in /etc/default/ltsp-pnp
18:13
http://bazaar.launchpad.net/~alkisg/+junk/ltsp-pnp/view/head:/debian/default
18:13
<zrpmz>
Knipwim: Not sure I am qualified to proofread(might be over my head) it but I am serious about packaging for another distro so if you don't mind I'd love to see it.
18:16markit has left IRC (markit!~marco@88-149-177-66.staticnet.ngi.it, )
18:20
<zrpmz>
knipwim:What do you need from me in order to let me read it? email address, or should I just check back in a couple days to ask for it then?
18:22
<knipwim>
zrpmz: the latter
18:23
currently there's only an idea :)
18:23
but this is a good reason to start
18:24
<zrpmz>
Awesom, I'll try back wednesday or thursday next week. If it's not ready thanks anyway. Until then, take care!
18:24
<knipwim>
zrpmz: wait
18:25
<zrpmz>
ok
18:25
<knipwim>
better pm me your email
18:25
i'll mail you the link in a few days then
18:25
not behind the screen a lot next week
18:26
<zrpmz>
How do I pm you from the irc webclient?
18:26
sorry, don't use it alot.
18:26
<knipwim>
like /msg knipwim <msg>
18:27
<zrpmz>
just type that in?
18:27
<knipwim>
i guess, or doubleclick my name
18:28
zrpmz: i just pm'ed you
18:28alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
18:29
<wafflecone>
This is one of those good news/bad news things. The clients now have a splash screen ... but X fails to start
18:29
:)
18:30
<[GuS]>
knipwim: is this normal? at the beginning of the ltsp client build: http://pastebin.com/PHEyGcVT with kicktoo
18:30
<zrpmz>
Thanks again to everyone that helped, bye
18:30zrpmz has left IRC (zrpmz!d170f8b2@gateway/web/freenode/ip.209.112.248.178)
18:31
<knipwim>
[GuS]: yeah it is
18:32
<[GuS]>
oks!
18:32
<knipwim>
[GuS]: nothing to worry though, it actually finds the correct module in a second run
18:32
<[GuS]>
Right
18:38boospy has left IRC (boospy!~loma@2001:470:1f0a:569:21f:1fff:fe71:faf3, Quit: Konversation terminated!)
19:05
<[GuS]>
knipwim: kicktoo is installing packages :)
19:05
weird that quickstart does not
19:12Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com)
19:16Parker955_Away is now known as Parker955
19:27Trixboxer has left IRC (Trixboxer!~Trixboxer@115.124.115.71, Quit: "Achievement is not the end, its the beginning of new journey !!!")
19:29
<[GuS]>
knipwim: with kicktoo works just fine :) Thanks!
19:32
<knipwim>
cool, nice to hear
19:34* vagrantc wonders if alkisg will be back later
19:47
<Hyperbyte>
mhmm
19:51risca has joined IRC (risca!~risca@wnpgmb0903w-ds01-249-233.dynamic.mtsallstream.net)
19:52filpx01 has joined IRC (filpx01!~phil@c-98-218-36-102.hsd1.va.comcast.net)
19:52filpx01 has left IRC (filpx01!~phil@c-98-218-36-102.hsd1.va.comcast.net)
19:56Parker955 is now known as Parker955_Away
20:00[GuS] has left IRC ([GuS]!~MysT@unaffiliated/gus/x-663402, Quit: Konversation terminated!)
20:07filpx01 has joined IRC (filpx01!~phil@c-98-218-36-102.hsd1.va.comcast.net)
20:19filpx01 has left IRC (filpx01!~phil@c-98-218-36-102.hsd1.va.comcast.net, Quit: Leaving.)
20:24sbalneav has left IRC (sbalneav!~sbalneav@mail.legalaid.mb.ca, Remote host closed the connection)
20:28stgraber has left IRC (stgraber!~stgraber@ubuntu/member/stgraber, Ping timeout: 272 seconds)
20:40Phantomas has left IRC (Phantomas!~Phantomas@unaffiliated/phantomas, Ping timeout: 250 seconds)
20:41stgraber has joined IRC (stgraber!~stgraber@ubuntu/member/stgraber)
20:50bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
20:58bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 248 seconds)
21:11bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
21:19artista_frustrad has left IRC (artista_frustrad!~fernando@200.247.43.2, Quit: Leaving)
21:23komunista has left IRC (komunista!~slavko@adsl-195-168-232-196.dynamic.nextra.sk, Quit: Leaving.)
21:26bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 252 seconds)
21:32mikkel has left IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk, Quit: Leaving)
21:41Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Quit: Leaving)
21:44dead_inside has left IRC (dead_inside!~dead_insi@76.75.3.174, Quit: Leaving...)
21:46ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Excess Flood)
21:47ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de)
21:55alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
21:56
<alkisg>
19:34* vagrantc wonders if alkisg will be back later => yup ;)
21:56
Ooh lots of commits, looking...
21:57
<vagrantc>
alkisg: nothing too fancy
21:58
alkisg: i was wondering if we might want a more generic package name ... ltsp-server-dnsmasq kind of limits us to dnsmasq ... maybe ltsp-server-autoconfig ?
21:58
<alkisg>
vagrantc: that would imply that it can be used with isc-dhcp too though...
21:58
<vagrantc>
that sounds kinda silly, too, though, and maybe too broad (like someone would expect it to automatically build the chroot or something)
21:59
<alkisg>
I think that the debian dependencies system restrict us a bit, so if we want dnsmasq, we can't autoconfigure many more things
21:59
<vagrantc>
sure, but we don't (in debian) have a way to autoconfigure with isc
21:59
<alkisg>
But if in a few months isc-dhcp grows a .d directory, we'll change the package name?
21:59
<vagrantc>
alkisg: also, the dependencies of ltsp-server-standalone on debian allow for dnsmasq ... was wondering if ltsp-server-dnsmasq should recommend ltsp-server-standalone
21:59
<alkisg>
Or if we make ltsp-server-standalone.postinst generate an "autoconfigured" /etc/ltsp/dhcpd.conf?
22:00
<vagrantc>
alkisg: that's the theory i'm considering
22:00
if we wanted to change the backend implementation
22:00
<alkisg>
dep: isc-dhcp-server ISC DHCP server for automatic IP address assignment
22:00
...that would conflict with dnsmasq, wouldn't it?
22:01
<vagrantc>
alkisg: for that portion of it's functionality, yes.
22:01
<alkisg>
Ah you have "or dnsmasq" there, sorry
22:01
<vagrantc>
though by default, dnsmasq doesn't conflict with isc-dhcp-server
22:01
for ltsp-server-dnsmasq, i put a breaks: isc-dhcp-server
22:02
<alkisg>
vagrantc: yup you're right, it would make sense to depend on ltsp-server-standalone in debian, I wonder if stgraber would accept some changes in ltsp-server-standalone so that the same was true in ubuntu too. stgraber?
22:02
E.g. depends: isc-dhcp | dnsmasq...
22:03
<vagrantc>
alkisg: i wouldn't want a strict dependency, but a recommends.
22:04
as ltsp-server-dnsmasq would still be very useful without ltsp-server-standalone.
22:04
<alkisg>
OK, np from me, as long as it works out of the box when someone installs it, I have no other objections
22:05ddave7 has joined IRC (ddave7!~Miranda@ip-94-113-119-192.net.upcbroadband.cz)
22:05
<vagrantc>
if they've disabled recommends, it obviously won't work "out of the box", but that's not the default on Debian, so they've "asked for it" so to speak.
22:06
i guess it would also allow ltsp-server-standalone to get removed during an upgrade if ltsp-server-standalone conflicted with something
22:06
alkisg: so you're thinking stick with ltsp-server-dnsmasq?
22:06
<alkisg>
Sure, it's the default on Ubuntu too. So, what about the name? I still kinda like ltsp-server-dnsmasq, I can't think of something better...
22:07
<vagrantc>
ironically, we use dnsmasq for everything but DNS :)
22:07
it's grown a lot of functionality since it was originally written
22:07
<alkisg>
Hehe, well they can enable it if they want it. And if Ubuntu precise didn't have all those local resolver hacks, I'd vote to enable dnsmasq's dns by default, even if it's a bit unsafe...
22:08
I'll probably sed through our dnsmasq configuration and enable it for greek schools anyway, from sch-scripts.postinst
22:09
<vagrantc>
can you specify it from a dnsmasq.d hook that's later?
22:11
<alkisg>
* Restarting DNS forwarder and DHCP server configuration syntax check [fail]
22:11
Nope
22:11
<vagrantc>
grumble.
22:13
<alkisg>
It's not a conffile so it doesn't matter, just a simple sed to comment out the dnsmasq.conf port on sch-scripts.portinst and the local resolver in /etc/NetworkManager/ and everything is ok
22:14
vagrantc: so do depend on ltsp-server-standalone, I think stgraber won't object to recommend isc-dhcp | dnsmasq
22:15
<vagrantc>
alkisg: that wouldn't fly in debian, but yes.
22:16
re: editing other packages configuration files
22:16
<alkisg>
Ah of course I never want to make sch-scripts an official package, it's by design a package just to cover whatever local needs we have
22:16
<vagrantc>
just reacting to "It's not a conffile so it doesn't matter" :P
22:17
<alkisg>
Whatever functionality gets tested and can become an upstream package, it's later on extracted, e.g. epoptes,
22:17
and later on the user-administration tool we're integrading now
22:17
We'll test it for a few months and then we'll extract it and look for kind packaging sponsors ;)
22:18
<vagrantc>
for example, non-conffiles that are managed with ucf will have the same basic issue that editing a conffile would have.
22:18
heh :)
22:18
<alkisg>
Is ucf editing policy compliant?
22:19
<vagrantc>
using ucf properly is policy compliant, but it's easy to use it wrongly
22:19
and the "don't touch other package's configuration" rule still applies.
22:19
ucf is used for a package to edit it's own configuration file dynamically
22:19
and to manage that in a way similar to dpkg conffile handling
22:20
which basically comes down to "annoy the admin when unexpected changes are present"
22:21
it does handle expected changes very nicely.
22:21
<alkisg>
"...facility is better than the one offered by dpkg while transitioning a file from a non-conffile to conffile status" ==> dpkg has such a facility?! Wow, we might need that in the future...
22:21* vagrantc prefers to maintain things in such a way as to limit the need for conffiles
22:22
<vagrantc>
as it's easy to handle that stuff poorly ...
22:24
<alkisg>
Ah I forgot to ask you about the ltsp-update-kernels --copytftp parameter... its sole purpose is for when someone puts TFTP==$CHROOT/boot, right?
22:24
I'm thinking it could be autodetected and not needed anymore...
22:24
(e.g. with stat, to see if the source/target files are the same)
22:26
In other words, here are the old and the proposed new parameters for ltsp-update-kernels: http://paste.debian.net/168401/
22:26
<vagrantc>
alkisg: yes, that's pretty much the purpose.
22:27
the paths change
22:27
<alkisg>
I'll put all cmdline (or bootprompt_options) handling in ltsp-update-kernels, but not the pxelinux menus stuff, so no timeout
22:28
<vagrantc>
i.e. instead of /ltsp/i386/pxelinux.0 it would be /i386/boot/pxelinux.0
22:28
if someone pointed tftp to /opt/ltsp
22:29
i just gave up on using it, though. we could probably just remove the functionality
22:29
<alkisg>
Ah he would use the whole /opt/ltsp? OK, I'll comment about the needed parameters for that
22:29
OK and if someone needs it we can easily put it later, with no parameter, just stat for same dir autodetection
22:30* alkisg is also wondering if it makes sense to update $CHROOT/etc/update-kernels.conf when ltsp-update-kernels is ran
22:31
<alkisg>
Currently ltsp-update-image does that (not ltsp-update-kernels), but it would only make a little sense in the .nbi (etherboot) case, and it's currently broken...
22:32
<vagrantc>
right
22:33
<alkisg>
I think we should make a generic .nbi that just loads pxelinux, so that the boot process, kernel parameters etc are common from there, and so that we don't need to have .nbi related code anymore
22:33
I mean, outside of the ltsp tree, for people that still have old etherboot clients
22:35
I think I'll start without updating $CHROOT/etc/update-kernels.conf, and if complains arise, I'll handle them later on
22:35
<vagrantc>
a generic .nbi that loads pxelinux?
22:36
you mean ipxe?
22:36
<alkisg>
Yes, or ipxe, or whatever else
22:39
<vagrantc>
the .nbi image generation for other architectures is mostly broken, too.
22:40
<alkisg>
A bug report was filed 3 years ago in launchpad, so I'm pretty sure noone's maintaining it
22:41
<vagrantc>
i've never tested the code for mips or arm, though sparc and alpha was mostly working at one point.
22:42
given what i've seen with arm and mips, neither likely have a "standard" way to load a kernel, so the nbi code is pointless.
22:43
<alkisg>
...sounds like time to remove it :)
22:43
<vagrantc>
yup
23:11ZyTer has left IRC (ZyTer!~oliv@wwwcache.univ-lr.fr, Quit: bye)
23:14alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
23:18ddave7 has left IRC (ddave7!~Miranda@ip-94-113-119-192.net.upcbroadband.cz, Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
23:19bengoa has left IRC (bengoa!~bengoa@2001:1291:229:2:216:cbff:feab:6cc9, Quit: Leaving.)
23:45vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
23:48ddave7 has joined IRC (ddave7!~Miranda@ip-94-113-119-192.net.upcbroadband.cz)