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


Channel log from 26 December 2013   (all times are UTC)

00:06gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)
00:37gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
00:42gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Read error: Operation timed out)
01:08nocturn has left IRC (nocturn!~nocturn@unaffiliated/nocturn, Ping timeout: 265 seconds)
01:13nocturn has joined IRC (nocturn!~nocturn@unaffiliated/nocturn)
01:17nocturn has left IRC (nocturn!~nocturn@unaffiliated/nocturn, Ping timeout: 260 seconds)
01:24nocturn has joined IRC (nocturn!~nocturn@unaffiliated/nocturn)
02:08clepto has joined IRC (clepto!~chadlepto@unaffiliated/chadlepto)
02:11ChadLepto has left IRC (ChadLepto!~chadlepto@unaffiliated/chadlepto, Ping timeout: 248 seconds)
02:20nocturn has left IRC (nocturn!~nocturn@unaffiliated/nocturn, Ping timeout: 240 seconds)
02:21nocturn has joined IRC (nocturn!~nocturn@unaffiliated/nocturn)
02:23freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
02:24SmallR2002 has joined IRC (SmallR2002!~Robert@c-98-253-173-240.hsd1.il.comcast.net)
02:31mattcen_ has joined IRC (mattcen_!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au)
02:34sbalneav has left IRC (sbalneav!~sbalneav@50.71.200.173, *.net *.split)
02:34mattcen has left IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au, *.net *.split)
02:34SmallR2003 has left IRC (SmallR2003!~Robert@c-98-253-173-240.hsd1.il.comcast.net, *.net *.split)
02:34mattcen_ is now known as mattcen
02:41sbalneav has joined IRC (sbalneav!~sbalneav@50.71.200.173)
02:42gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
02:43* vagrantc waves to sbalneav
02:44
<vagrantc>
sbalneav: alkisg and i have been doing a virtual hackfest this week!
02:47gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 264 seconds)
03:44gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
03:48gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 272 seconds)
04:45gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
04:50gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 248 seconds)
04:56alkisg has joined IRC (alkisg!~alkisg@ppp089210206186.access.hol.gr)
04:56alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
04:57
<alkisg>
Good morning
04:59* vagrantc waves
04:59* vagrantc noticed a half-dozen failed builds
04:59
<vagrantc>
can i unsubscribe from some of those?
05:00
it's basically because the changes in ltsp-trunk require changes to the packaging...
05:01
but i don't want to make the corresponding changes to the packaging until I upload the next ltsp version
05:01
also fixed the one bug i found in cdpingerless ltspfs
05:02
<alkisg>
vagrantc: I disabled them so that they don't send mails to ltsp-committers
05:02
<vagrantc>
alkisg: have you gotten a chance to test newish ltspfs?
05:02
<alkisg>
I'll either temporarily change their owner, or create my own so that they don't bother people with mails
05:02
<vagrantc>
alkisg: ok, thanks.
05:03
in theory, i like the idea of automated builds, but my packaging branch isn't always targetted at -trunk
05:03
and it'd be a bit too much work to maintain multiple packaging branches
05:03
<alkisg>
No, I was thinking of doing as many changes as I could now that I still have some time to code, and test/debug all of them a bit later, as testing time is more easy for me to find than development time...
05:04
<vagrantc>
alkisg: i was thinking of trying to wrap up the ltsp-update-kernels stuff and uploading a new version...
05:04
<alkisg>
I.e. finish pxelinux first...
05:04
Cool
05:04
<vagrantc>
also, ltspfs could use a new point release with that bugfix and additional cdpinger removal cleanups
05:05
<alkisg>
If you get the packaging ready without bumping the changelog, it makes it much easier for me to test it...
05:05
<vagrantc>
that i could probably finish up pretty quickly
05:05
haven't been bumping the changelog lately
05:06
<alkisg>
What I mean is, let's try to finish ltsp-trunk, ltspfs-trunk, AND their packaging, and test them, and _then_ to do the new releases...
05:06
<vagrantc>
basically, ltsp needs packaging changes tha taccount for -trunk's lack of xatomwait
05:07
<alkisg>
vagrantc: so, does http://wiki.ltsp.org/wiki/Dev:PXEConfig sound sane? Is it time to send a mail to ltsp-devs?
05:08
<vagrantc>
alkisg: i *think* ltspfs is ready, no packaging changes needed.
05:08
alkisg: the overall premise is sane, i'd like to re-use the old variables for CMDLINE_*
05:08
<alkisg>
OK let me update the page for that...
05:09
<vagrantc>
and leave the initrd= out of the CMDLINE_, that way it's easier to remove it if there's no initrd.
05:10
and the server-side reads /etc/ltsp/ltsp-update-kernels.conf, as well as the /opt/ltsp/*/etc/ltsp/update-kernels.conf ?
05:10
ah, it already mentions the latter part
05:12
<alkisg>
I think I mention both of them, just in separate places
05:12
<vagrantc>
hrm.
05:12
<alkisg>
vagrantc: is ip=dhcp necessary? isn't it the default anyway?
05:12
<vagrantc>
alkisg: the first server-mention only mentions update-kernels.conf, not ltsp-update-kernels.conf ... want to mak sure i'm not misunderstanding
05:12
<alkisg>
That's because it the "client-side" paragraph
05:12
<vagrantc>
alkisg: for the theoretic initrd-less install, it should be there.
05:13
<alkisg>
So it only mentions update-kernels and update-kernels.conf, not ltsp-update-kernels
05:13
<vagrantc>
server-side mentions update-kernels.conf
05:13
<alkisg>
Sorry let me re-read...
05:13
<vagrantc>
first paragraph... just making sure it's a typo vs. a misunderstanding of implementation
05:14
alkisg: so both pxelinux.cfg/ltsp and ltsp-all are always regenerated?
05:15
<alkisg>
Yup
05:15
vagrantc: copy/paste the line that you're mentioning, I'm still not getting it
05:15
For each chroot (or loop-mounted image), ltsp-update-kernels sources $CHROOT/etc/ltsp/update-kernels.conf, if it exists, and does the following steps:
05:15
This one?
05:15
<vagrantc>
The ltsp-server package may ship /etc/ltsp/update-kernels.conf,
05:16
first paragraph in the server section
05:16
<alkisg>
Right, the BOOT_METHODS go there
05:16
And the distro may or may not decide to ship it
05:16
<vagrantc>
shouldn't they go in ltsp-update-kernels.conf ?
05:16
<alkisg>
Meh
05:16
<vagrantc>
since it's being implemented by ltsp-update-kernels?
05:16
<alkisg>
OK something's really wrong here. Probably lack of coffee. :D
05:17
Sorry!
05:17
<vagrantc>
it's a minor detail, really.
05:18* alkisg is more worried about the time it took him to understand what vagrantc was saying :D
05:18
<alkisg>
OK, updated
05:19
If we're not careful in the code, the (older) chroot BOOT_METHODS might end up being interpreted as server-side BOOT_METHODS... maybe we should rename that?
05:19
<vagrantc>
both the client and server-side will have BOOT_METHODS defined
05:19* vagrantc nods
05:20
<vagrantc>
same thought process :)
05:20
it'd be good to know what the client's preferred BOOT_METHODS are
05:20
so maybe SERVER_BOOT_METHODS ?
05:20
or BOOT_METHODS_SERVER ?
05:20
that can be how the client tells the server which methods it can support.
05:21
maintains full backkwards compatibility
05:21
the server can choose to honor them or not
05:21
but especially, it should error out if there are no matches, but both are defined
05:22
<alkisg>
OK, when I was writting it I was trying to eliminate the need to ship a config file, but yeah if we're shipping it/upgrading it anyway what you're saying does make more sense
05:23
<vagrantc>
well, in absense of a defined value, we use the defaults.
05:23
and if the defaults don't work, the sysadmin with a corner-case situation needs to specify something :)
05:23
which is reasonable
05:24
<alkisg>
vagrantc: why does the client need to list BOOT_METHODS, if it lists the CMDLINE_* variables? Just to make it easier to loop through them?
05:24
<vagrantc>
alkisg: are we putting off supporting /opt/ltsp/i386 and /opt/ltsp/images/i386.img till ltsp6, you think?
05:24
alkisg: preference order
05:25
alkisg: i.e. BOOT_METHODS="NFS NBD" tells it to default to NFS
05:25* alkisg was thinking where it's the correct place to declare the preference, server-side or chroot-side...
05:25
<vagrantc>
alkisg: also, it's currently used to determine which CMDLINE_* variables to look for.
05:25
alkisg: both can declare their preferences
05:27
alkisg: a little curious why splitting pxelinux.cfg/ltsp and pxelinux.cfg/ltsp-all into separate files ... could just define ltsp-all as a submenu ...
05:27
<alkisg>
vagrantc: for translation
05:27
"Previous Linux Versions" => submenu
05:27
<vagrantc>
alkisg: the server shouldn't serve up chroots the client doesn't know how to support, and vice-versa.
05:27
<alkisg>
And include ltsp-all
05:28
But I do want to test INCLUDEs a bit before going ahead with the implementation...
05:28
<vagrantc>
alkisg: ok, not attached either way, really.
05:28
INCLUDES work pretty well.
05:28
i used them extensively at freegeek
05:28
maybe painfully so
05:29
https://github.com/freegeek-pdx/netboot-config/tree/master/pxelinux.cfg
05:30
the only downside i see with includes is multiple tftp hits, but i'd be surprised if that was what overloaded your server compared to nfsroot/nbdroot
05:31
the other downside is you can loose yourself in complexity :)
05:31
layers upon layers of includes
05:32
alkisg: another minor thing, regarding the chroot generating pxelinux.cfg ... it shouldn't generate it, but if it does, it won't hurt anything, other than wasted time
05:32
i.e. old chroots that do generate it
05:33
<alkisg>
Yes, that's what I meant, not sure what I wrote though... /me looks...
05:33
<vagrantc>
like i said, minor
05:35mattcen has left IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au, Read error: Connection reset by peer)
05:36
<alkisg>
Updated... btw vagrantc wherever my wording isn't good enough, feel free to update it: http://wiki.ltsp.org/mediawiki/index.php?title=Dev:PXEConfig&action=edit
05:36
<vagrantc>
this is not far off from what I implemented for wheezy, but I made the mistake of wanting to avoid using the includes and always regenerating all the files...
05:36* vagrantc rummages around for login credentials
05:37
<vagrantc>
alkisg: partly, i'm just checking in to make sure it's not just a misunderstanding :)
05:39
just to minimize downtime, we should probably update all the files in a separate dir...
05:39
and then move it into place when everything is done
05:39mattcen has joined IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au)
05:39
<vagrantc>
handling multiple tftp dirs also really is starting to feel stupid.
05:40
<alkisg>
If we're shipping ltsp-update-kernels.conf, we can easily drop support for multiple tftp dirs ...
05:41
<vagrantc>
i think it already allows overriding the tftp dirs
05:41
but safer to support all of them by default
05:41* alkisg would even prefer NOT updating the files that are the same in CHROOT vs TFTP
05:42
<alkisg>
I've seen people that have 30 older kernels in their tftp...
05:42* vagrantc nods
05:42cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 246 seconds)
05:42
<alkisg>
rsync could easily do that,
05:43
...and cp does have an "update only" parameter, but then it's difficult to see which files to delete in TFTP
05:47gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
05:51gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 260 seconds)
06:17
<alkisg>
Maybe we should postpone changing our tftp cleanup code until all the configuration files have been moved out of TFTP/ltsp/ARCH and into /etc/ltsp/lts.conf and TFTP/pxelinux.cfg...
06:48
<vagrantc>
it seems like what you have is actually fine
06:49gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
06:49
<vagrantc>
we can get a list of files we're going to include, and then delete all the other files, and then run cp -u
06:49
but it does lack simplicity
06:49
rsync --delete?
06:50
well, really, the only problem is re-copying everything
06:50
which yeah, 30 some kernels/initrds would be kind of wasteful...
06:51
and time consuming, at some point, when you account for multiple chroots
06:51* alkisg would leave the cleanup code as it is for ltsp5, and for ltsp6 he'd use rsync -delete, yeah
06:51
<vagrantc>
honestly, the purge and re-copy isn't so awful.
06:51
<alkisg>
Or cp --update, and rm the non-existing files via shell afterwards
06:52
<vagrantc>
yeah, that's not too bad
06:52
whitelist it from the old dir.
06:53gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 240 seconds)
06:53
<vagrantc>
oh, if the server creates the symlinks in the tftp dir, then it needs to exclude them from the purge
06:54
that's what got me started on the whole purging code
06:54
because it was deleting the symlinks created in the chroot
06:54
but if you create them on the server, the symlinks need to be excluded from the purge patterns
06:55
<alkisg>
Aren't they created after the purging?
06:55
<vagrantc>
this seems like 95% done... i think we can come up with something
06:55
alkisg: ah, you could do that on the server-side, sure.
06:55
alkisg: although it increases the amount of time the missing symlinks are there.
06:55
er, arren't there
06:55
<alkisg>
We don't touch $CHROOT/boot/*, do we?
06:56
<vagrantc>
with the new implementation, not yet
06:56
<alkisg>
I mean, ltsp-update-kernels will be the only thing creating symlinks... ok
06:56
<vagrantc>
but say someone boots a client near the time you're running ltsp-update-kernels ... we want the window of time for files to be missing to be small
06:57
that's why i was thinking some sort of copy to a tempdir and move approach
06:57
as long as it's on the same filesystem, the move can happen very quickly
06:57
<alkisg>
The temp dir would be under $TFTP, to ensure it's in the same disk and fast to move afterwards?
06:57* vagrantc nods
06:57
<alkisg>
Sounds good
06:58
<vagrantc>
which in general, i'm not fond of tempdirs in tftp
06:58
but it doesn't solve the problem of copying redundant data multiple times
06:59
is there some way to do a copy that uses a dir as a reference dir, but copies the changed files to a different location?
06:59
<alkisg>
What if we whitelist files to keep instead of blacklisting files to delete?
06:59
I.e. TFTP_WHITELIST="pxelinux.cfg,lts.conf" in /etc/ltsp/ltsp-update-kernels.conf
06:59
<vagrantc>
we'd have to generate the list of files to whitelist dynmaically, since we don't have static symlink names
07:00
<alkisg>
Symlinks shouldn't be hard to maintain separately
07:00
I.e. just run the symlinking code and remove all dangling symlinks after that
07:01
<vagrantc>
could generate the list of files to be symlinked from $chroot/boot/ ...
07:01
and/or updated
07:01* alkisg doesn't follow
07:01* vagrantc is chasing vagrantc's own tail
07:02
<vagrantc>
to generate a whitelist, we can basically whitelist lts.conf, pxelinux*, the symlinks we're going to generate, and the files from $chroot/boot
07:02
all other files should be purged, yes?
07:03
<alkisg>
Yes, we're saying the same thing, except I define the whitelist as the 2 first things you're saying, and just special-case the 2 last ones
07:03
cp --update from boot to TFTP, then create symlinks, then delete all files that only exist in tftp and not in boot, then delete all dangling symlinks
07:03
<vagrantc>
that sounds good.
07:05
the current code would delete the symlinks... well, i actually committed a workaround to that
07:06
it just doesn't bother purging symlinks, but leaves dangling symlinks around
07:06
<alkisg>
With that last line I said above ^, do we still need the temp dir?
07:06
Or we can do it in-place?
07:07
<vagrantc>
i think that works fine without the temp dir.
07:07
<alkisg>
(to avoid re-copying everything...)
07:07
<vagrantc>
somewhere in there we should (re)generate the pxelinux
07:07
i liked the complete purge for how simple it was to implement, but has the drawback of re-copying too much data.
07:08
<alkisg>
Btw can we depend on rsync?
07:08
Maybe it has a one-line for what we want...
07:08
<vagrantc>
alkisg: pxelinux.cfg updates should happen in between creating symlinks and purging files
07:09
<alkisg>
Yeah deletions should be last
07:09
<vagrantc>
i think that makes sure everything is always in a bootable state.
07:09
i would be fine with depending on rsync, but i'm not sure it actually gains us much.
07:09
<alkisg>
I think some race conditions exist, but they should be rare...
07:10
<vagrantc>
what it could gain us is more cpu-intensive, i think.
07:11
unless we put the symlinks back into the chroot ....
07:11
then it would be pretty simple to use.
07:11
<alkisg>
vagrantc: the concept is the same wheather we use a whitelist or a blacklist (cp --update etc etc), which one would you prefer? I think I prefer the internal blacklist...
07:12
vagrantc: touching the chroot means we assume it's readable...
07:12
That's not the case for ltsp-pnp (cow), for .vdi, nfs exports...
07:12
(touching the chroot from ltsp-update-kernels, that is...)
07:13
<vagrantc>
right, i was talking about from a kernel install hook
07:13
$chroot/usr/share/ltsp/update-kernels
07:13
<alkisg>
Hmm sure why not, that does make sense
07:14
<vagrantc>
since the symlinks only need to be (re)generated when you install or update a kernel...
07:14
but it doesn't have backwards compatibility with old chroots
07:14
since the old chroots won't generate them
07:14
but then you can just fall back to newest kernel version
07:14
yes?
07:14
or the sysadmin installs a hook in the chroot to generate them...
07:15* alkisg would prefer to have the symlink generating code *once*, not both in the server and the client
07:15* vagrantc nods
07:15
<alkisg>
Ah, another thing... suppose I run ltsp-update-kernels,
07:15
then realize my chroot is broken, then restore a backup, then run ltsp-update-kernels again,...
07:15
<vagrantc>
this little bit of code is sure getting a lot of airtime :)
07:16
<alkisg>
...that won't work with cp --update, will it?
07:16
<vagrantc>
yeah, cp --update will need to have a force-overwrite mode or something
07:16
i.e. ltsp-update-kernels --force-update or something
07:16
<alkisg>
So, simplicity +1, let's go with the copying everything idea
07:16* vagrantc forgets what we do now...
07:17
<vagrantc>
cp -a "$chroot/boot/." "$tftpboot/$name/"
07:17
so that wouldn't be a regression
07:17
<alkisg>
Why -a instead of -r?
07:18
<vagrantc>
yeah, that's what i'm wondering
07:19
i think -r might "fix" our "chmod +r" problem.
07:19
<alkisg>
Yup
07:20
So, ltsp-update-kernels copys boot to tftp/ltsp/arch.NEW, creates pxe configuration, symlinks etc etc, everything ready,
07:20
<vagrantc>
still might want --no-dereference
07:21
subdirs can be copied too.
07:21
oh, but you wanted to save some space...
07:21
i.e. /boot/grub and whatnot
07:22
<alkisg>
I don't mind
07:22
That was back when we wanted to avoid copying pxelinux.cfg
07:22
Now we're keeping it until ltsp6
07:22
<vagrantc>
but we're still planning on generating it server-side?
07:22
and wiping out the client-side generated pxelinux.cfg stuff?
07:22
<alkisg>
Yes, we'll overwrite any files there
07:23
<vagrantc>
even default?
07:23
<alkisg>
Ouch
07:23
<vagrantc>
well, that's easy enough to support
07:24ChadLepto has joined IRC (ChadLepto!~chadlepto@c-71-237-229-76.hsd1.or.comcast.net)
07:24ChadLepto has joined IRC (ChadLepto!~chadlepto@unaffiliated/chadlepto)
07:24
<vagrantc>
part of updating tftp/ltsp/arch.NEW involves cp tftp/ltsp/arch/pxelinux.cfg/default tftp/ltsp/arch/pxelinux.cfg/default
07:24
we can copy over whatever whitelist we want to "save"
07:25
same with lts.conf
07:26
<alkisg>
The problem is that we won't generate the first appropriate pxelinux.cfg/default then
07:26
<vagrantc>
so: cp -r "$chroot/boot/." "$tftpboot/$name.NEW/" ; cp $tftpboot/$name/$WHITELIST $tftpboot/$name.NEW/ ; generate symlinks ; update updated pxelinux.cfg*
07:26
<alkisg>
We'll use the old one from the chroot
07:26
Nah, I think I prefer it if chroot doesn't have anything to do with pxelinux
07:26
I.e. it can even not have syslinux installed
07:26
<vagrantc>
sure, that's fine.
07:27
but that seems like a non-sequitor :P
07:27
<alkisg>
So, for simplicity again, I say that we shouldn't have an update-kernels in the chroot at all... :D
07:27
<vagrantc>
blashpemy
07:27
<alkisg>
Just a .conf file
07:27
Haha
07:27clepto has left IRC (clepto!~chadlepto@unaffiliated/chadlepto, Ping timeout: 264 seconds)
07:27
<alkisg>
OK ok we need it for nbi etc
07:27
<vagrantc>
it's like the one stable thing in ltsp5
07:29
<alkisg>
For ltsp6, will we be using pxelinux.0 from the server or from some random chroot?
07:29* vagrantc wonders how the various parallel universes have turned out that have used all the various schemes we've come up with in the last 24 hours
07:29
<alkisg>
Hehehe!!
07:29
<vagrantc>
alkisg: at least on debian, pxelinux.0 is installable on any architecture, so that shouldn't be a problem
07:29
i mean, it's an arch:all package
07:30
and even it if wasn't, worst case is you could install it multi-arch, i think.
07:30
<alkisg>
OK back to where we were... do we copy subdirs or not? If yes, how do we handle pxelinux.cfg/default?
07:30
I vote for "we don't copy subdirs"
07:31
<vagrantc>
i don't have any installs with stuff in subdirs...
07:31* vagrantc wonders about other distros
07:32* vagrantc downloaded a bunch of live CDs earlier today
07:32
<vagrantc>
although who knows how "normal" those are.
07:32
alkisg: what's wrong with copying the pxelinux.cfg/default from an existing tftp dir?
07:32
i guess, upgrading from an older chroot?
07:33
<alkisg>
vagrantc: so you would "merge" tftp.new with tftp.old and boot ?
07:33
Err I didn't say that correctly
07:34
<vagrantc>
merging individual files, i.e. lts.conf and pxelinux.cfg/default
07:34
<alkisg>
Suppose you have a pxelinux.cfg/default in boot, and one in (the older) tftp
07:34
And also suppose that you have some 01-mac-address files there
07:34
<vagrantc>
manual configuration for the sysadmin to support old choorts is not unreasonable.
07:34
ah, yes, other random files...
07:35
ok, so copy pxelinux.cfg/* and regenerate the files we know are safe to regenerate
07:35
<alkisg>
Copy pxelinux.cfg from where? the chroot?
07:35
<vagrantc>
the tftp dir
07:35
tftp.old to tftp.new
07:36
<alkisg>
Sure, but what do you copy from the chroot the first time?
07:36
You have a clean tftp and an old chroot with pxelinux.cfg/default
07:37
The correct thing to do there is to generate a new default
07:37
<vagrantc>
copy $chroot/boot to $tftpdir/$arch.new, copy $tftpdir/$arch/lts.conf $tftpdir/$arch/pxelinux.cfg/* $tftpdir/$arch/, regenerate auto-generated pxelinux.cfg/ stuff
07:37
<alkisg>
That leaves you with the old default
07:37
<vagrantc>
yes, so if there's no file in $tftpdir/$arch/pxelinux.cfg/default, generate it
07:38
<alkisg>
OK
07:38
<vagrantc>
copy $chroot/boot to $tftpdir/$arch.new, copy $tftpdir/$arch/lts.conf $tftpdir/$arch/pxelinux.cfg/* $tftpdir/$arch/, generate pxelinux.cfg/default if not present, regenerate auto-generated pxelinux.cfg/ stuff
07:39
that's fairly simple for what we're trying to accomplish
07:39
<alkisg>
tftpdir/$arch/lts.conf $tftpdir/$arch/pxelinux.cfg/* $tftpdir/$arch/, ==> do you mean $arch.new there?
07:39
<vagrantc>
oops, yeah.
07:40
<alkisg>
So you'd generate pxelinux.cfg/default in the .new directory?
07:40
<vagrantc>
yes.
07:40
<alkisg>
That might make the paths a bit complicated, but only a bit
07:40
<vagrantc>
unless it was already present in the old directory
07:40
not if they're relative
07:40
<alkisg>
/ltsp/arch.new/file
07:41
While the correct would be /ltsp/arch/file
07:41
Ah we don't have a master pxelinux yet
07:41* vagrantc nods
07:41
<vagrantc>
that's for ltsp6... unless it isn't.
07:41
<alkisg>
Sure, sure
07:42
<vagrantc>
this is a bit simpler from a "what to purge" perspective
07:42
<alkisg>
I think it still has a problem
07:42
<vagrantc>
downsides would be upgrading a server with old chroots ... sysadmin will need to regenerate pxelinux.cfg/default
07:42
or remove it, and let ltsp-update-kernels update it
07:42
<alkisg>
And the fact that I'm not sure if it does, ...tells me it's not as simple as it sounds at first glance....
07:43
Right, that problem
07:43
<vagrantc>
it gives us a very simple set of whitelist files
07:43
lts.conf, pxelinux.cfg/* (pxelinux.cfg/default is a little bit special) ... everything else must go!
07:45
<alkisg>
So we'd delete the user'ss "lts.original"?
07:45
<vagrantc>
guess so.
07:45
<alkisg>
..when he's just testing with an empty lts.conf?
07:45* alkisg likes the blacklist better, until ltsp6
07:46
<vagrantc>
so, at this point, we're trying to get to ... an editable pxelinux.cfg/default ... that's the only remaining goal, yes?
07:46
or the semi-stable symlinks?
07:46
<alkisg>
I think our main difference is that I prefer to keep the existing blacklist, while you prefer to switch it to a whitelist...
07:47
That then differentiates the implementation just a bit, on the order of copies/deletions etc
07:47
<vagrantc>
sure.
07:47
overall, i'm not attached either way, honestly.
07:48
i just want some clarification on what the exact problem we're trying to solve, at this point, since we've kind of gone around in circles a bit
07:48
<alkisg>
For ltsp6 I'd go with "no blacklist, no whitelist - delete everything"
07:48
For now, I'd just try to keep things similar to what they currently are, and only change the stuff that will bring us something that we want
07:49* vagrantc chants "what do we want?"
07:49
<alkisg>
So, goals: (1) symlinks, (2) static pxelinux.cfg/default
07:49
We don't care about whitelisting or blacklisting, so I wouldn't change that without good reason
07:50
...more so when we'll change that again for ltsp6, to "no list at all, delete everything"
07:50
<vagrantc>
sounds good.
07:50
or we'll probably come up with something else in a week or two :P
07:50
<alkisg>
Haha
07:50gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
07:50
<vagrantc>
that we'll postpone for ltsp7
07:51
<alkisg>
Yeah I'm starting to wonder if ltsp5 is worth it, to get those pxe configuration changes
07:52
<vagrantc>
well, the symlinks are not that hard.
07:52
well, the symlinks are not that hard.
07:52
oops
07:52* alkisg said that 2 days ago too, that he mainly cares about the symlinks :)
07:52
<vagrantc>
we've already got a partial implementation in the chroot-code, which is more similar to currently released ltsp 5.4.x implementations
07:53
that's because ubuntu changes versions all the time, isn't it?
07:54
<alkisg>
Yup
07:54
<vagrantc>
debian doesn't break abi compatibility very often at all ... often not even once during a release cycle
07:54
<alkisg>
So if a client needs "nomodeset", the teacher has no real way to handle it
07:54
<vagrantc>
only a single client... right
07:55
<alkisg>
...ok, there's a vmlinuz symlink, but if one wants pae/non-pae then he can't do it
07:55
<vagrantc>
so, maybe we focus on integrating the symlinks, and treat the other re-work separately
07:55gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 248 seconds)
07:55
<vagrantc>
if it's even worth doing
07:55
(i mean, the pxelinux.cfg/default changes)
07:55
<alkisg>
I think it's worth doing, but now I don't think it's worth doing anything related about it for ltsp5...
07:56
I do think we should move to a static /pxelinux.cfg
07:56
<vagrantc>
abandoning it during ltsp5 ?
07:56
wait for ltsp6, rather?
07:56
<alkisg>
Yup
07:56
<vagrantc>
feel like we're so close...
07:56
<alkisg>
New branch time? :)
07:56
<vagrantc>
the symlinks are already there in trunk ...
07:57
just needs better code for version-splitting
07:57
<alkisg>
vagrantc: will we still have the vmlinuz symlink for ltsp5?
07:57
Or did that change to vmlinuz-generic-pae now?
07:58
<vagrantc>
alkisg: it won't break any of those
07:58
alkisg: i.e. if it was there before, it doesn't get rid of it
08:00
<alkisg>
OK, nice. So, everything is supposed to be working, and we only need testing.
08:00staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)
08:00
<alkisg>
And then we can fork to ltsp6...
08:00
Right?
08:00
<vagrantc>
that's my hope
08:00
the pxelinux.cfg/default stuff isn't there at all, though.
08:00
and dangling symlinks aren't dealt with
08:00
<alkisg>
Same as it was before, isn't it?
08:01
<vagrantc>
think so
08:01
<alkisg>
Sounds fine
08:02
<vagrantc>
so really, at this point, it's just a matter of tweaking the symlink code in client/share/ltsp/update-kernels
08:03
the menu generation code doesn't use the symlinks
08:04
it only uses versioned kernels
08:05
but you could create pxelinux.cfg/01-$macaddr that uses the symlink
08:06
<alkisg>
Right, that's more than enough, we can leave the rest for ltsp 6:)
08:06
<vagrantc>
it's also hardcoded for vmlinuz and initrd-img
08:07
probably wouldn't be too hard to generate an unversioned pxelinux.cfg
08:08* alkisg would just ship it from the distro and let the user do whatever changes he wanted, manually... :D
08:08
<alkisg>
Hehe
08:08staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 272 seconds)
08:09
<alkisg>
Editing menu.lst with the vmlinuz symlinks was way easier than now with grub2,
08:09
where we need to edit /etc/default/grub, /etc/grub.d/*, run update-grub... it sucks
08:10
So, I'd generate the symlinks and provide a static pxelinux.cfg file, and whatever else the user wants, nbd, nfs, pae etc, he'd do them manually, it's just static content with the symlinks there
08:11
Anyways, our current plan is good enough, let's not change it
08:11
<vagrantc>
it's way easier for packages to add menu entries with the grub2 hooks, though.
08:11
<alkisg>
But there are no packages that add menu entries to ltsp
08:11
<vagrantc>
alkisg: so, just symlinks, no pxelinux.cfg/default ?
08:12
<alkisg>
For ltsp5? Yup.
08:12
<vagrantc>
alkisg: sure, but i appreciate the grub2 menu generation method
08:12
<alkisg>
That would be up to pxelinux to define a menu generation method, not up to ltsp
08:12
<vagrantc>
yes
08:13
didn't get much response when i asked about that
08:13
so we have to write a bunch of code to generate the menus...
08:14
while we change our minds all the time, at least syslinux hasn't changed syntax much
08:15
if we're putting symlinks in the last ltsp 5.x generations, we may as well generate the corresponding menus.
08:15
<alkisg>
We support menus in the current code, right?
08:15
<vagrantc>
yes.
08:15
actually ...
08:16
it woudln't be hard to make pxelinux.cfg/default not autogenerated anymore
08:16
would be trivial, actually
08:16
because it's regenerated every time now...
08:17
<alkisg>
To make it not-autogenerated, you need to put INCLUDE in it
08:17
<vagrantc>
right. which shouldn't be hard at all.
08:17
<alkisg>
But how do you know if that's the last auto-generated version, that you need to overwrite with the static content?
08:18
grep for this? # This file is regenerated when update-kernels runs.
08:19
<vagrantc>
yup.
08:20
i'll give it a shot, it's what i should've done last time we did this.
08:22
<alkisg>
Actually `head` should be a bit safer than `grep` in this...
08:38
<vagrantc>
alkisg: think this should do it: http://paste.debian.net/72589/
08:39
i guess ltsp-update-kernels also needs some special-casing to copy and/or not copy it over
08:39* vagrantc -> sleep
08:41
<vagrantc>
well, that handles the pxelinux.cfg/default being editable
08:41
it doesn't add the symlinked versions in
08:42
and doesn't handle yaboot or the other boot methods :)
08:45
<alkisg>
Good night vagrantc, see you tomorrow
08:46* alkisg is doing morning chores...
08:47
<vagrantc>
we could also just symlink pxelinux.cfg/default -> pxelinux.cfg/ltsp ...
08:47
and if the sysadmin wants to use includes, they could
08:47
by deleting the symlink and updating the file.
08:48
would be virtually identical to now, but easier to convert into an editable mode.
08:48
hrm... but then we're back to is the chroot the editable version, or the tftp dir ... hrm.
08:48
it's still more feasible to fix.
08:52gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
08:56gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 240 seconds)
09:04bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 272 seconds)
09:04bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
09:07
<vagrantc>
alkisg: i'd like to upload ltspfs-trunk as 1.2.1-1 soonish, if you could test on ubuntu, that'd be good to know. otherwise i might just patch in a fix or two for 1.2-2
09:07
alkisg: i know you wanted to test stuff later
09:07
<alkisg>
vagrantc: i'll test this evening
09:07
<vagrantc>
but i'm curious if it works at all.
09:08
and agains tmy better judgement, i've got a branch with the editable pxelinux.cfg/default ... although there's still the problem of the cchroot overwriting the tftp dir.
09:09
i think that's the thing i never resolved and why i decided to not bother with editability.
09:10
i guess the chroot could just not generate pxelinux.cfg/default at all, and rely on ltsp-update-kernels to do it...
09:10
and by default, it could just symlink pxelinux.cfg/ltsp -> default
09:10
that's pretty simple. and doesn't much change behavior
09:11
then it doesn't even need to get into includes.
09:11
and ltsp-config pxe could replace the symlink with an editable include-based config.
09:11
and then we throw it all away for ltsp6 :)
09:13
<alkisg>
Hahaha
09:14
Yeah you're putting way too much though into it, when it'll not be an issue for ltsp 6
09:14
*thought
09:16
<vagrantc>
well, i think that'll work, and it's an improvement, and fixes what felt like unfinished business, without getting too messy.
09:17
it has some of the qualities of the new system, without totally breaking compatibility with the old.
09:18
aaaaanyways...
09:18* vagrantc waves
09:18vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
09:21alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)
09:37gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
09:42imox has joined IRC (imox!~imox@p4FC5D41D.dip0.t-ipconnect.de)
09:43gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 240 seconds)
10:08freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
10:27gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
10:36Gremble has joined IRC (Gremble!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net)
10:36Gremble is now known as Guest59986
11:20freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Ping timeout: 248 seconds)
11:35freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
11:43Guest59986 has left IRC (Guest59986!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net, Quit: I Leave)
12:41khildin has joined IRC (khildin!~khildin@ip-213-49-87-118.dsl.scarlet.be)
14:32nocturn has left IRC (nocturn!~nocturn@unaffiliated/nocturn, Quit: ZNC - http://znc.in)
14:49bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Quit: http://www.twelvetribes.org)
15:00freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
15:11imox has left IRC (imox!~imox@p4FC5D41D.dip0.t-ipconnect.de, Quit: imox)
15:20imox has joined IRC (imox!~imox@p57A1F1E2.dip0.t-ipconnect.de)
15:33PhoenixSTF has joined IRC (PhoenixSTF!~rudi@78.29.154.124)
15:41cliebow has joined IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us)
15:57staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)
16:03staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 260 seconds)
17:25bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
17:32vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
18:25imox has left IRC (imox!~imox@p57A1F1E2.dip0.t-ipconnect.de, Quit: imox)
18:40adrianorg has left IRC (adrianorg!~adrianorg@187.113.249.22, Ping timeout: 272 seconds)
18:42adrianorg has joined IRC (adrianorg!~adrianorg@177.156.58.138)
19:20gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)
19:29gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
19:58cliebow has left IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us, Remote host closed the connection)
20:06PhoenixSTF has left IRC (PhoenixSTF!~rudi@78.29.154.124, Quit: Leaving)
20:43Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
20:53alexqwesa_ has left IRC (alexqwesa_!~alex@109.172.12.47, Ping timeout: 246 seconds)
20:55gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)
20:56gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
21:00gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 252 seconds)
21:00gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
21:19Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Quit: Leaving.)
22:10gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)
22:21gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
22:25khildin has left IRC (khildin!~khildin@ip-213-49-87-118.dsl.scarlet.be, Quit: I'm gone, bye bye)
23:05clepto has joined IRC (clepto!~chadlepto@unaffiliated/chadlepto)
23:05shogunx has left IRC (shogunx!~shogunx@rrcs-67-79-182-229.se.biz.rr.com, Read error: Operation timed out)
23:06shogunx has joined IRC (shogunx!~shogunx@rrcs-67-79-182-229.se.biz.rr.com)
23:06mmetzger has left IRC (mmetzger!~mmetzger@99-71-214-107.lightspeed.mdldtx.sbcglobal.net, Ping timeout: 240 seconds)
23:06mmetzger has joined IRC (mmetzger!~mmetzger@99-71-214-107.lightspeed.mdldtx.sbcglobal.net)
23:07ChadLepto has left IRC (ChadLepto!~chadlepto@unaffiliated/chadlepto, Ping timeout: 240 seconds)
23:22gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)