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


Channel log from 2 June 2012   (all times are UTC)

00:01vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
00:12khildin has left IRC (khildin!~khildin@ip-80-236-227-228.dsl.scarlet.be, Quit: I'm gone, bye bye)
00:32risca has joined IRC (risca!~risca@81-233-43-131-no18.tbcn.telia.com)
00:42cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 252 seconds)
01:19cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
01:30alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 240 seconds)
01:38alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
01:38SmallR2002 has joined IRC (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net)
01:43andygraybeal has joined IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net)
02:59risca has left IRC (risca!~risca@81-233-43-131-no18.tbcn.telia.com, Quit: Lämnar)
03:05vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net)
03:05vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
03:06andygraybeal has left IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net, Ping timeout: 246 seconds)
03:18Damianos has left IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com, Ping timeout: 244 seconds)
03:24Damianos has joined IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com)
03:28
<vagrantc>
why is it always editing the changelog tht feels like the hardest part of an LTSP upload?
03:29
<stgraber>
dch -i "We changed everything, again..." && debuild -S -sa && dput ../*.changes
03:29
what's difficult with that :)
03:32
<vagrantc>
it would be a wild change of style... and i'm too curmudgeonly to change.
03:34
so, about to tag ltsp 5.4.0 ...
03:35
it's been busy.
03:47
tagged ltsp 5.4.0 ...
03:58sha has left IRC (sha!~sha@e177119119.adsl.alicedsl.de, Ping timeout: 240 seconds)
03:59alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
04:00sha has joined IRC (sha!~sha@d151092.adsl.hansenet.de)
04:01* alkisg loves time zone differences, when he wakes up and sees 5.4.0 tagged already :D
04:02
<vagrantc>
about to upload to debian sid, too
04:03* alkisg uploads to the greek schools ppa...
04:04
<vagrantc>
alkisg: i spent a little while longer on trying to resolve the "ltsp-update-image --cleanup /" with a split boot issue ... i did manage to manually mount a second aufs on top of i386/boot to make it work.
04:05
alkisg: --rbind didn't work.
04:06
aufs seems to refuse to acknowledge the existance of sub-mounts
04:06
<alkisg>
But does it support mounting multiple submounts by itself?
04:06
<vagrantc>
alkisg: so, one could iterate through and make another aufs for each mountpoint ... but i wanted to get this uploaded today.
04:06adrianorg_ has left IRC (adrianorg_!~adrianorg@177.18.171.174, Read error: Operation timed out)
04:07Damianos has left IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com, Ping timeout: 252 seconds)
04:07
<vagrantc>
alkisg: i managed to graft /boot onto i386/ (*not* i386/boot)
04:07
<alkisg>
Meh. Then we'd need to bind them to $tmp/point1 point2 point3 before actually merging all the mounts into an aufs call
04:08
<vagrantc>
alkisg: i also didn't resolve your issue with debuild -b -tc ... even though i did make a change on a related subject...
04:08
alkisg: no need to merge all the mounts
04:08
<alkisg>
vagrantc: you didn't yet put "5.4.0" anywhere in debian/ yet, right?
04:09
<vagrantc>
alkisg: any second now
04:09
<alkisg>
E.g. bind mount /boot to $tmp/rofs/1/boot (needs a mkdir before that) so that one can use rofs/1 as the mount base, in order for /boot to go in its correct path
04:09
<vagrantc>
looks like someone submitted some patches for ldm, too ... was hoping to tag & upload ldm on sunday
04:10VectorX has joined IRC (VectorX!VectorX@220.247.236.182)
04:11
<vagrantc>
alkisg: yeah, i did something like that ... but not merged into one aufs, i just mounted another aufs on top of the other one.
04:11
<alkisg>
I guess it would be faster to use one aufs instead of multiple ones
04:11
<VectorX>
i got the utubuntu 12.04 alternative, but the F4 mode to install a LTSP server is not there, is that not the right version of the distro iso ?
04:12
<vagrantc>
alkisg: faster than what?
04:13Damianos has joined IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com)
04:13
<alkisg>
vagrantc: I feel that using a single aufs instance that manages 5 branches would be faster than 5 aufs instances managing 2 branches each
04:13
<vagrantc>
alkisg: if you can figure it out, good :)
04:17
bah. now is the moment where i look at all the patches i forgot to include.
04:17
http://bugs.debian.org/591608 ?
04:18
and the bugs i forgot to close ... though that is easy enough to handle after the fact.
04:19* vagrantc wonders if anything uses anything from iproute anymore
04:19
<alkisg>
While it'd be nice to fix #591608, I don't think it's a blocker
04:20
We do use `ip` in many cases
04:21
<vagrantc>
no, not a blocker
04:21
which is why i keep forgetting to include it all these... months... years?
04:23
<alkisg>
:)
04:23
vagrantc: looking at the aufs manpage... for squashfs the default mount option is "rr" (real read-only) and we're using "ro" instead, which is slower
04:24
(just a note for the future, nothing that needs fixing now)
04:24
<vagrantc>
oh.
04:25
<alkisg>
Whoah. aufs supports caching the nbd mount into a local device!!!
04:25* alkisg thinks about local disk and local ram as well
04:27
<vagrantc>
oops, we still send ESPEAKER environment variable.
04:28
<alkisg>
vagrantc: if you're doing changes before the upload, I'd prefer to have LDM_DEFAULT_DESKTOP in the example lts.conf instead of LDM_SESSION
04:28
As it does check for the session existence
04:29
<vagrantc>
alkisg: it's uploaded already
04:29
<alkisg>
k, np
04:29
<vagrantc>
i forsee a few more smaller uploads over the next few weeks
04:36staffencasa has left IRC (staffencasa!~staffenca@128.193.8.220, Ping timeout: 250 seconds)
04:39
<alkisg>
The ldm patches in ltsp-developer also look interesting
04:44komunista has joined IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk)
04:52
<vagrantc>
oh, i should've prepared the tarball with mkdst so it had all the autofoo
04:53VectorX has left IRC (VectorX!VectorX@220.247.236.182, )
04:55
<vagrantc>
alkisg: i didn't highlight the "ltsp-update-image ---config /" feature in the changelog either ... although that's a significant new feature.
04:55
<alkisg>
--cleanup :P
04:55
<vagrantc>
alkisg: it's part of my mission to convinnce you it deserves it's own option
04:56
though not a conscious one
04:56
<alkisg>
I'm not sure that it really needs a separate option, as people could use it for .vdi images too
04:56
vdfuse ....mount path/to/vdi /opt/ltsp/i386; ltsp-update-image --cleanup /opt/ltsp/i386
04:57
I think that a separate option for / would confuse people there
04:57
<vagrantc>
more, i'm feeling like i'll never remember --c*
04:57
<alkisg>
It's even possible to boot with a live cd and run ltsp-update-image /, without --cleanup
04:57
(after chrooting to the disk of course)
04:57
<vagrantc>
i know it's possible
04:58
but it seems like the default case actually should run --cleanup
04:58
<alkisg>
But ok I wouldn't oppose to having a "shortcut" option for --cleanup /
04:58
<vagrantc>
and have a --no-cleanup
04:58
to disable
04:58
<alkisg>
Once we see that it works fine everywhere, aufs and all, sure
04:58
<vagrantc>
i can remember: ltsp-update-image / or ltsp-update-image /opt/ltsp/foobar
04:58
<alkisg>
ltsp-update-imageg -c /
04:59
<vagrantc>
i guess i always remember the "c"
04:59
<alkisg>
Or you can put CLEANUP=true in the configuration file
04:59* vagrantc generally prefers --long options because they're more memorable
05:00
<alkisg>
The downside of --cleanup is that it requires the ability to chroot, which isn't always the case
05:00
E.g. arm chroots on i386 server
05:00
<vagrantc>
alkisg: also, i think even before we get the pxemenu stuff working well ... i'll consider shipping a default update-kernels.conf ... if only to hae the NBD options commented out and the NFS options uncommented.
05:01* vagrantc chroots to arm chroots on x86 servers all the time
05:01
<vagrantc>
it's one of my test cases for ltsp :)
05:01
<alkisg>
With qemu?
05:01
<vagrantc>
yeah.
05:01
<alkisg>
OK, but that's not always an option
05:01
<vagrantc>
yes, i know, it was just the one option that actually works well as a bad example :)
05:01
<alkisg>
If you'll be shipping an update-kernels.conf, I think it should list all the available cmdlines uncommented
05:02
NFS_CMDLINE=xxx, NBD_CMDLINE=xxx, AOE_CMDLINE....
05:02
Then ltsp-update-image can pick up the NBD one
05:02
<vagrantc>
alkisg: i was thinking of layering it ... i.e. BOOTPROMPT_OPTS="$DEFAULT_LTSP_OPTS $MOUNT_METHOD_OPTS" and then define a few variables to comment/uncomment
05:03
<alkisg>
NFS_CMDINE="$GENERIC_OPTIONS more options", sure
05:04
<vagrantc>
well, i want something that works with BOOTPROMPT_OPTS as it stands now, but still can change by commenting and uncommenting lines in the file, without having to mess with the common options.
05:04
and if it will support other options later, great.
05:04
<alkisg>
That would require editing the file before ltsp-update-image though
05:05
...and then again before reusing it as nfs
05:05
<vagrantc>
which isn't any worse than it is now.
05:05
actually, it's easier, because the comments are already there.
05:05
<alkisg>
Of course, but it doesn't make it work out of the box though
05:05
<vagrantc>
no, but it's easier to figure out what should be there.
05:06
as it stands, i've got to grep through likely files in order to figure out what the various default commandlines are...
05:07
<alkisg>
We can also set variables from ltsp-update-image, e.g.
05:07
CHROOT=i386 ... update-kernels, and inside update-kernes.conf:
05:07
<vagrantc>
alkisg: right now i handle it in the ltsp-build-client plugins when creating NBD images
05:07
<alkisg>
BOOTPROMPT_OPTS="... ${CHROOT:-i386}"
05:08
ltsp-build-client shouldn't care if the image being created will be export with NBD or NFS...
05:08
<vagrantc>
that would be ideal, yes.
05:09
i dunno if we can get something closer to just seamlessly supporting both options for 5.4.1 ... or if that's further down the line
05:12
BOOTPROMPT_OPTS_* where * gets transformed into a pxe menu entry, and you can set BOOT_DEFAULT=NFS
05:13
so BOOTPROMPT_OPTS_NFS=' root=/dev/nfs ... ' with BOOT_DEFAULT=NFS and BOOTPROMPT_OPTS_NBD=' root=/dev/nbd0 ...' and then generate pxe configuration for each
05:14
this way it could support arbitrary types ... BOOTPROMPT_OPTS_X BOOT_DEFAULT=X
05:15
the chroot itself can generate the pxelinux.cfg and the server could have some mechanism to override BOOT_DEFAULT
05:15
or to show a preference of BOOT_DEFAULT
05:16
<alkisg>
cyberorg uses an option in pxelinux that allows specifying a top-level default
05:17
I didn't know that was supported by pxelinux, but it is
05:17
http://cyberorg.co.in/default
05:17
ONTIMEOUT kiwi-ltsp
05:17
So we can use that to easily define defaults and override them by the server
05:18
Now, the `env` command lists the variables in the order that they were exported
05:18
So, we could use "env | grep ^BOOTPROMPT_OPTS_' to list NFS, NBD etc in the order they were declared in update-kernels.conf
05:18
(in pxelinux.cfg/default)
05:19
...and use ONTIMEOUT to select which of those is the default
05:19
Doesn't sound too hard to do for 5.4.1
05:21
Actually if we're using the order that they're declared in the .conf file, we don't need a default on the chroot, only on the server
05:21
Do you want to list all the available kernels?
05:21
Or just the first one, and have a submenu at the bottom with all the previous linux versions?
05:25
...or we could have numbers on them and sort them, instead of using the order in which they were declared
05:26
<vagrantc>
submenus with previous versions sounds good
05:26
<alkisg>
..let's write down some ideas to the pad
05:26
!pad
05:26
<ltsp`>
alkisg: pad: http://pad.ubuntu-uk.org/ltsp
05:26
<vagrantc>
hmmm.. how to integrate the amd64/pae/other detection
05:27
i would like to be able to define default=AUTODETECTION
05:27
because the kernel is going to be ifcpu64.c32
05:28
label autodetection
05:28
kernel ifcpu64.c32
05:29
append ltsp64 -- ltsppae -- ltsp
05:29
<alkisg>
vagrantc: join the pad
05:29
<vagrantc>
and ltsp64, ltsppae and ltsp would all be other menu entries
05:30
javascript, boo!
05:34
<alkisg>
Haha
05:39
vagrantc: since we're reusing the pxelinux var names there, I'd prefer them to have the same meaning
05:39
<vagrantc>
alkisg: yeah, that's the obvious advantage
05:39
<alkisg>
That also requires less documentation in our part
05:39
<vagrantc>
i always found it absurd that pxelinux defines it in tenths of a second ...
05:39
if they really wanted that, use a decimal point ... eesh.
05:40
so ... BOOTPROMPT_OPTS now becomes CMDLINE_
05:40
so ... BOOTPROMPT_OPTS now becomes CMDLINE_XXX where XXX is actually arbitrarily definable ...
05:41
<alkisg>
vagrantc: I think the "splash/quiet" part should be global, not per CMDLINE
05:41
So Ubuntu would use it even for NFS
05:41
<vagrantc>
alkisg: seems reasonable.
05:41
alkisg: so how do we support multiple DEFAULT entries?
05:42
<alkisg>
vagrantc: each chroot puts a default option, and the server uses the ONTIMEOUT default option instead
05:42
<vagrantc>
i mean, multiple default entries ... i could see it being useful to have a submenu that disables splash, for example
05:44
alkisg: maybe it shouldn't include $CMDLINE_DEFAULTS in it, but iterate through and append them.
05:45
<alkisg>
vagrantc: what about memlinux and additional non-ltsp entries? Do we care about them?
05:45
<vagrantc>
i.e.. CMDLINE_DEFAULTS_FOO, CMDLINE_DEFAULTS_BAR , and then you iterate thhrough each of those and prepend them to CMDLINE_NFS, CMDLINE_NBD
05:45
alkisg: i do care about those!
05:45
<alkisg>
No I mean from the ltsp code side
05:45
Of course the pxelinux package would include them
05:45
<vagrantc>
we currently support memtest
05:46
and support menu/vesamenu
05:46
<alkisg>
Well... we currently don't support menus, so it's not really selectable, is it?
05:46
Hm
05:46
<vagrantc>
CUSTOM_CMDLINE_XXX ?
05:46
with a custom kernel?
05:55
alkisg: that's looking pretty good
05:55
flexible, fairly easy to be backwards compatible ...
05:57
<alkisg>
Let's talk about the displayed menu order/organization
05:58
NFS entry NFS recovery entry, NBD entry, NBD recovery entry, memtest, memtest (serial console), Previous Linux versions ?
05:58
Ah and maybe localboot somewhere
05:58
<vagrantc>
can the "recovery" entries actually also be arbitrary variables?
05:59
<alkisg>
I think we should do it like grub does it in debian,
05:59
<vagrantc>
it only has two options
05:59
default and other
05:59
<alkisg>
Right, the ones selectable with dpkg-reconfigure grub-pc
06:00
It'll make more sense for the users, lower learning curve etc
06:00
We can add more stuff, but I'd like it if we defaulted to what grub does
06:01
<vagrantc>
if we implemented it as a _RECOVERY variable i think it would be clear and still allow for other arbitrary ones
06:01
<alkisg>
Right
06:01
So e.g. one additional entry that I want is "Local boot windows from partition 2", that's not something that we can detect, but we can have a comment for the user that he can easily adapt
06:01
<vagrantc>
but the default config, yes, you wouldn't have to document all the arbitrary possibiilities
06:02LoveStorm has left IRC (LoveStorm!Storm@gateway/shell/trekweb.org/x-gjvkderelmmzdwng, Changing host)
06:02LoveStorm has joined IRC (LoveStorm!Storm@unaffiliated/lovestorm)
06:02LoveStorm has joined IRC (LoveStorm!Storm@gateway/shell/trekweb.org/x-gjvkderelmmzdwng)
06:03* alkisg checks /etc/default/grub...
06:04
<alkisg>
Ah yeah we need a name to display too, e.g. "Ubuntu 12.04 (precise), with Linux xxx"
06:04
<vagrantc>
that comes later.
06:06
alkisg: i'm still focusing on the pxelinux.cfg generated in the chroot itself.
06:07
just a basic config
06:08
<alkisg>
vagrantc: that's still chroot stuff, the server doesn't know about e.g. fat gentoo chroots
06:08
Of course we don't know what LDM_SERVER the user will connect to, but we should display something, might as well default to the chroot distributor...
06:10
<vagrantc>
ok, makes sense
06:11Parker955_Away is now known as Parker955
06:23Damianos_ has joined IRC (Damianos_!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com)
06:23
<alkisg>
vagrantc: about additional kernels, do you just want to keep PXELINUX_APPEND_FILE?
06:24Damianos_ has left IRC (Damianos_!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com, Read error: Connection reset by peer)
06:24Damianos_ has joined IRC (Damianos_!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com)
06:26
<vagrantc>
alkisg: i'd really like something that didn't require a lot of manual finnagling ... though maintaining PXELINUX_APPEND_FILE isn't a bad idea
06:26Damianos has left IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com, Ping timeout: 260 seconds)
06:27
<knipwim>
ah, you tagged
06:27
<alkisg>
hi knipwim
06:28
<vagrantc>
knipwim: yup.
06:28
<knipwim>
if i'd known that, i would have finished the distro service()
06:28
<vagrantc>
knipwim: sorry
06:28
<alkisg>
vagrantc: I think "PREPEND_FILE" might be useful too, for those that want to display a local "boot windows" entry on top
06:28
<vagrantc>
knipwim: there's always a point release :)
06:28
<knipwim>
hehe :)
06:29Damianos_ has left IRC (Damianos_!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com, Ping timeout: 265 seconds)
06:29
<alkisg>
vagrantc: how about special boot method, e.g. BOOT_METHODS="localboot NFS NBD memdisk"?
06:29
<knipwim>
but congrats guys, vagrant and alkis
06:29
you did a lot of work
06:29
<alkisg>
Yeah, good release, congrats to all
06:30
<vagrantc>
alkisg: special casing a few boot methods?
06:30
<alkisg>
Yes, it'd make it easier to do ordering + disabling for them
06:30
<vagrantc>
alkisg: maybe special-cased lowercase, not special-cased UPPERCASED ?
06:31
<alkisg>
Maybe... /me thinks about how the user can add custom entries in BOOT_METHODS...
06:32
We could also generate many files, not just one, and include them as appropriate
06:32
<vagrantc>
knipwim: we clearly haven't stopped at 5.4.0 :)
06:32
<alkisg>
Ah, then the user could just create files in /boot/pxelinux.cfg/default himself, and just list them in BOOT_METHODS
06:33
No need for prepend/append this way
06:33
<vagrantc>
and yes, it's been a pleasure cramming 5.4.0 with alkisg and you too knipwim :)
06:33* alkisg likes the multiple files idea
06:33
<vagrantc>
alkisg: multiple files is great.
06:34
<alkisg>
We can also generate everything, and only have an INCLUDE="" variable instead of "BOOT_METHODS"
06:34
<vagrantc>
sure
06:36* vagrantc wonders about something other than INCLUDE
06:36
<alkisg>
You mean about the variable name?
06:36
<vagrantc>
yeah
06:36
<alkisg>
Sure
06:36
<vagrantc>
it makes some sense to call it INCLUDE ... in that we're both including support for x, y and z, as well as literally including the files we'll generate :)
06:37
<alkisg>
INCLUDE="localboot NBD NFS memtest previous_kernels boot_windows_from_partition2"
06:37
We'd generate all of them except for the last one, which would be created by the user
06:38
<vagrantc>
INCLUDE="detect_kernel"
06:38
<alkisg>
What would that do?
06:38
<vagrantc>
use ifcpu64.c32 to detect which of the other options it should support
06:39
which kernel to boot based on amd64, pae or other
06:39
<alkisg>
Ah, sure, sounds fine
06:40
<vagrantc>
the extra complication, which isn't relevent here ... is each of those could also have different boot options, i.e. nbdroot=/opt/ltsp/amd64
06:40
(it isn't relevent until we jump outside the chroot with pxemenus)
06:40
<alkisg>
And we can list "header" in INCLUDEs, which will contain the TIMEOUT etc, and always rewrite that file, and the user can change it to a custom my_header if he wants to have custom backgrounds or anything else
06:41
(or he can do that from tftp, his choice)
06:42
...or we can generate /boot/pxelinux.cfg/header if it doesn't exist, and let the user edit it from there, and never modify it again ourselves
06:42* alkisg likes that better
06:43
<vagrantc>
might be confusing what's editable and what's "not"
06:43
<alkisg>
CAPS==autogenerated, lowercase==editable?
06:44
<vagrantc>
maybe the CAPS/lowercase distinction isn't obvious enough
06:44
<alkisg>
We create once header, localboot, memtest. We always regenerate NBD, NFS
06:47
...how will we handle the default kernel to use (-pae or not) without the DETECT_KERNEL code? Just sort -frV with the non-pae kernels on top?
06:48
Is KERNELS_ORDER="generic generic-pae ..." good enough?
06:49* alkisg has never used anything else than pae + non-pae kernels...
06:50bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
06:50
<vagrantc>
alkisg: it's more complicated on debian
06:50
<alkisg>
...some examples from the ubuntu packages: linux-image-3.2.0-24-generic linux-image-3.2.0-24-generic-pae linux-image-3.2.0-23-lowlatency linux-image-3.2.0-23-lowlatency-pae
06:50
<vagrantc>
there's no "generic"
06:51* alkisg checks http://packages.debian.org/search?keywords=linux-image ...
06:51
<vagrantc>
and we're only talking about i386/amd64 here, thankfully :)
06:53
<alkisg>
vagrantc: is there a kernel that doesn't have a -name at its end?
06:53
E.g. -486, -686...
06:54
<vagrantc>
mainly, there's -486 (nonpae) -686 (kinda non-pae), -686-pae (pae), -amd64 (amd64)
06:54
<alkisg>
So, we can use those in the sorting list
06:54
If the sorting list is empty, we'd list all of them in sort -frV order, and if it exists, we'd only list the ones matching, and in that order
06:55
knipwim: what's a usual gentoo kernel filename like, again?
06:55
Does it have a distinctive ending?
06:55
<vagrantc>
alkisg: there's also -rt-amd64 and there's a few -xen- variants
06:56
<alkisg>
for variant in $KERNELS_ORDER; do for kernel in /boot/vmlinuz*-$variant; do ...
06:57
INCLUDE_KERNELS= or something, a better name for it is needed
06:58
<vagrantc>
and 686-bigmem
06:59
<alkisg>
Ah I think gentoo has the arch inside the filename instead of at its end, but it should still be able to use the ordering list to only match those kernels
07:01
So, I'm thinking LIST_KERNELS="-486 -686-pae", with it defaulting to "*".
07:01
<knipwim>
alkisg: for instance kernel-genkernel-x86-3.0.6-gentoo
07:01
<alkisg>
Does it sound good enough?
07:02
Right, gentoo would then use find -name /boot/kernel-$arch-* and sort -frV the results in the internal loop
07:02* Hyperbyte yawns
07:02
<alkisg>
LIST_KERNELS="x86 x64" (or however else the amd64 variant is called)
07:03
<knipwim>
Hyperbyte: good morning :)
07:03vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Ping timeout: 248 seconds)
07:03
<Hyperbyte>
Goedemorgen!
07:03
Boy do I feel horrible... I feel like a truck drove over me... everything in my body hurts...
07:04
Worst part is: I have no idea why I feel this way.
07:05
<alkisg>
...girlfriend drugged you to take advantage of you? :P
07:06
<Hyperbyte>
If that was the case I wouldn't feel horrible!
07:06Parker955 is now known as Parker955_Away
07:08
<Hyperbyte>
Meh... off to the radio station...
07:24alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 260 seconds)
07:37
<alkisg>
knipwim: so would something like that work for gentoo too, with a different template for the filename?
07:37
http://paste.ubuntu.com/1019167/
07:43
<knipwim>
check, and ltsp-server 5.4.0 released on gentoo!
07:44
alkisg: i'll check
07:46
<alkisg>
Cool, gentoo is really up to date with LTSP :)
07:46
<knipwim>
not all stuff is implemented
08:00
alkisg: what does the awk %s do?
08:00
<alkisg>
knipwim: you mean the printf?
08:00
<knipwim>
yes
08:00
<alkisg>
$ printf "hi %s, how are you?\n" "knipwim"
08:00
hi knipwim, how are you?
08:00
It allows to include a string (%s) in any place of the template
08:01
So you just need to call list_kernels "kernel-template%s" "x86 x64
08:02
You shouldn't need to modify the function
08:02
listkernels "kernel-genkernel-%s-*" "x86 x64", maybe
08:04
The idea there is to have a distro-specific template (can even be a function if we don't like it to be a variable), and have a common code then to handle the kernels and the menu generation
08:04
<knipwim>
cool, it works
08:05
putting the highest kernel on top
08:05
<alkisg>
Nice, ok, I'll start with something based on that
08:06
So if the user wants to order his kernels in a specific way, he'd put in update-kernels.conf a single line like INCLUDE_KERNELS="generic-pae pae *"
08:06
By omitting the *, he'd restrict the listed kernels
08:09
knipwim: you're not using update-kernels, are you? What are you using instead?
08:10
(seeing that it has initrd.img hardcoded...)
08:10
Or you're generating an initrd.img symlink?
08:20
<knipwim>
no, what does it do?
08:21
<alkisg>
knipwim: it mainly generates the pxelinux.cfg/default file, and it also creates .nbi images etc
08:21
How do you generate pxelinux.cfg/default?
08:21
<knipwim>
by hand
08:22
at least, i'm only using default for testing
08:22
<alkisg>
OK, if you want we can try to make it more distro agnostic
08:22
...for testing?
08:22
What does the normal boot use then, if not pxelinux.cfg/default?
08:22
<knipwim>
specific machines run from C0A80018 for instance
08:23
which are symlinked to a specific config
08:23
<alkisg>
And that specific config is manually created?
08:23
<knipwim>
:) yes
08:23
<alkisg>
OK, if you want we can generate it with update-kernels
08:23
<knipwim>
i think my problem is that i don't run any large scale environment
08:24
and don't really have different use cases
08:24
so i only develop on stuff i want fixing for my own use case
08:25
<alkisg>
np with that, I'm just trying to make update-kernels a bit less distro specific, but other distros don't _have_ to use it...
08:25
<knipwim>
it's a nice feature, just haven't come around to implementing/looking at it yet
08:26
and distro-common separation helps all distro's
08:33tarzeau_ has left IRC (tarzeau_!~gurkan@mail.aiei.ch, Quit: Lost terminal)
08:42
<knipwim>
alkisg: shouldn't --base be transferred from ltsp-update-image to ltsp-config?
09:24alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
09:31
<alkisg>
knipwim: Yup. Or we could stop supporting some global parameters like base or the tftpdirs and tell the user to create an /etc/ltsp/common.conf with the values he needs, if he ever wants to modify them
09:32
(assuming people don't use different BASEs but a single one with multiple subdirs there)
09:32
And of course BASE=xx would also be supported this way
09:32
BASE=xx ltsp-update-image, I mean
09:38bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Read error: Operation timed out)
09:42
<knipwim>
yes, and that might make even more sense for tftpdirs
10:02Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com)
10:07
<knipwim>
okay to remove any commandline tftpdir options?
10:12rhorstkoetter has joined IRC (rhorstkoetter!~rhorstkoe@opensuse/member/rhorstkoetter)
10:20Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.71)
10:21
<alkisg>
Maybe we should discuss it with vagrantc first as it involves editing manpages etc as well
10:21
<knipwim>
that's cool
10:23toscalix has joined IRC (toscalix!~toscalix@109.144.24.70)
10:24andygraybeal has joined IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net)
10:30andygraybeal has left IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net, Ping timeout: 246 seconds)
10:41F-GT has left IRC (F-GT!~phantom@ppp121-44-97-140.lns20.syd6.internode.on.net, Quit: Leaving)
10:43F-GT has joined IRC (F-GT!~phantom@ppp121-44-97-140.lns20.syd6.internode.on.net)
10:55awilliam1 has joined IRC (awilliam1!mistik1@unaffiliated/mistik1)
10:56awilliams has left IRC (awilliams!mistik1@unaffiliated/mistik1, Ping timeout: 248 seconds)
10:56awilliam1 is now known as awilliams
11:04staffencasa has joined IRC (staffencasa!~staffenca@128.193.8.220)
11:07Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Remote host closed the connection)
11:09toscalix_ has joined IRC (toscalix_!~toscalix@212-166-142-231.red-acceso.airtel.net)
11:11toscalix has left IRC (toscalix!~toscalix@109.144.24.70, Ping timeout: 265 seconds)
11:15
<alkisg>
knipwim: that works for you too? http://paste.ubuntu.com/1019385/
11:16
With that you need to specify the KERNEL_PREFIX and KERNEL_SUFFIX instead of a template, I thought that would be easier to read
11:18
KERNEL_PREFIX="kernel-genkernel-", KERNEL_SUFFIX="*-gentoo"
11:27staffencasa has left IRC (staffencasa!~staffenca@128.193.8.220, Ping timeout: 244 seconds)
11:30mikkel has joined IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk)
11:31ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 252 seconds)
11:34nenenaiad has joined IRC (nenenaiad!540d6e6e@gateway/web/freenode/ip.84.13.110.110)
11:35
<knipwim>
alkisg: with those settings, it shows arch-version, like x86-3.0.6
11:36
<nenenaiad>
Intend to use the Ubuntu 10.04 alternate disk to set up LTSP - could anyone tell me what Ip addresses and the number of ip addresses it will setup by default
11:41
I could have explained this better - What ip address will it assume for the Internet connection - what ip address will it assume for the LTSP server and also for ltsp clients
11:49
<knipwim>
i think the clients will look for the server at 192.168.0.1 by default
11:51
the ips for the rest of your machines are dependent on your internal dns settings and modem/router/isp
12:06toscalix_ has left IRC (toscalix_!~toscalix@212-166-142-231.red-acceso.airtel.net, Read error: Connection reset by peer)
12:12
<alkisg>
knipwim: cool, I'll fix update-kernels to use that function
12:13
<nenenaiad>
Thanks knipwim will start from there
12:15nenenaiad has left IRC (nenenaiad!540d6e6e@gateway/web/freenode/ip.84.13.110.110, Quit: Page closed)
12:26nenenaiad has joined IRC (nenenaiad!540d6e6e@gateway/web/freenode/ip.84.13.110.110)
12:38nenenaiad has joined IRC (nenenaiad!540d6e6e@gateway/web/freenode/ip.84.13.110.110)
12:40
<nenenaiad>
I had to set up LTSP using 10.04 in a different location from where it will actually be used. In its final destination
12:42
the router is on the other side of some switches. Is it possible to change the ip address of the router/Internet NIC to suit the router and if so what is changed?
12:50awilliam1 has joined IRC (awilliam1!mistik1@unaffiliated/mistik1)
12:50awilliams has left IRC (awilliams!mistik1@unaffiliated/mistik1, Ping timeout: 252 seconds)
12:51awilliam1 is now known as awilliams
13:02
<alkisg>
nenenaiad: are you using a 2-nic setup?
13:03alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Read error: Operation timed out)
13:05alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
13:09awilliams has left IRC (awilliams!mistik1@unaffiliated/mistik1, Ping timeout: 240 seconds)
13:27
<nenenaiad>
Thanks Alkisg - Yes I am
13:30mikkel has left IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk, Quit: Leaving)
13:48
<alkisg>
nenenaiad: then you don't have to change anything for the internet-facing NIC, you can leave it to use dhcp
13:48
And the internal nic will keep the same IP, 192.168.0.1
13:58
<nenenaiad>
I ran ip route on the server and it reads as follows :-
13:58
192.168.22.0/24 dev eth0 proto kernal scope link src 192.168.22.1
13:59
169.254.00/16 dev eth1 proto kernal scope link src 169.254.6.176
14:00
169.254.0.0/16 dev eth0 scope link metric 1000
14:02
If I recall correctly a change was made to the ip address of the server
14:03
<alkisg>
That probably means that your eth0 got an IP from DHCP, and that you need to set eth1=192.168.0.1
14:06
<nenenaiad>
Info from /etc/network/interfaces is :-
14:06
auto lo
14:07
iface lo inet loopback
14:07
auto eth0
14:07
iface eth0 inet static
14:07
address 192.168.22.1
14:07
netmask 255.255.255.0
14:07
autoeth1
14:08
iface eth1 inet dhcp
14:08
Does that help
14:09alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
14:11nenenaiad has left IRC (nenenaiad!540d6e6e@gateway/web/freenode/ip.84.13.110.110, Quit: Page closed)
14:15rhorstkoetter has left IRC (rhorstkoetter!~rhorstkoe@opensuse/member/rhorstkoetter, Quit: Leaving.)
14:21litlebuda has joined IRC (litlebuda!~litlebuda@204.0.166.178.rev.vodafone.pt)
14:30litlebuda has left IRC (litlebuda!~litlebuda@204.0.166.178.rev.vodafone.pt, Remote host closed the connection)
14:32litlebuda has joined IRC (litlebuda!~litlebuda@204.0.166.178.rev.vodafone.pt)
14:45Phantomas has joined IRC (Phantomas!~Phantomas@unaffiliated/phantomas)
14:53toscalix has joined IRC (toscalix!~toscalix@153.176.219.87.dynamic.jazztel.es)
15:28komunista has left IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk, Ping timeout: 260 seconds)
16:03toscalix has left IRC (toscalix!~toscalix@153.176.219.87.dynamic.jazztel.es, Read error: Connection reset by peer)
16:03toscalix_ has joined IRC (toscalix_!~toscalix@153.176.219.87.dynamic.jazztel.es)
16:07toscalix_ has left IRC (toscalix_!~toscalix@153.176.219.87.dynamic.jazztel.es, Remote host closed the connection)
16:09toscalix_ has joined IRC (toscalix_!~toscalix@153.176.219.87.dynamic.jazztel.es)
16:15Parker955_Away is now known as Parker955
16:17toscalix_ has left IRC (toscalix_!~toscalix@153.176.219.87.dynamic.jazztel.es, Remote host closed the connection)
16:20rhorstkoetter has joined IRC (rhorstkoetter!~rhorstkoe@opensuse/member/rhorstkoetter)
16:28monteslu_ is now known as monteslu
16:29komunista has joined IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk)
16:29adrianorg_ has joined IRC (adrianorg_!~adrianorg@189.58.224.221.dynamic.adsl.gvt.net.br)
16:37
<rhorstkoetter>
hi. may you tell me how to hide the sessions menu in LDM? I configured LDM_SESSION in lts.conf and don't want to selection menu to appear at all, i.e. hide this option from users
16:37
s/to/the
16:41Damianos has joined IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com)
16:43
<komunista>
rhorstkoetter: I cannot help you, but I am curious about the reason for this
16:43
<rhorstkoetter>
komunista: the reason I'd like to hide it?
16:43
<komunista>
yes
16:44
<rhorstkoetter>
I'd like to provide users with a default session (did this with LDM_SESSION in lts.conf). now I'd like to make sure users don't "see" and thus are able to use other sessions available on the server
16:46
at the moment users are able to switch from the default session by using the sessions menu and this isn't desired
16:47
<komunista>
of course, but why?
16:48
my users have default one too, but they have freedom in session selection...
16:50
<rhorstkoetter>
the setup I'm building is for a school and I need to rather highly customize, i.e. lock down the session for a group of users (the pupils) and I certainly would like to do tzhis for just one session, in this case lxde, and not for numerous ones (unity, gnome) available at the server
16:50F-GT has left IRC (F-GT!~phantom@ppp121-44-97-140.lns20.syd6.internode.on.net, Ping timeout: 248 seconds)
16:51
<rhorstkoetter>
also, I may have certain thinclient not even able to effectively utilize sessions like unity
16:51
thus I decided to go for lxde for everyone
16:51
to save resources and maintain a single environment
16:54Damianos has left IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com, Remote host closed the connection)
16:57Damianos has joined IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com)
16:59Damianos_ has joined IRC (Damianos_!~damianos@68-186-144-58.dhcp.kgpt.tn.charter.com)
17:06Parker955 is now known as Parker955_Away
17:16Damianos__ has joined IRC (Damianos__!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com)
17:17Damianos has left IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com, Ping timeout: 240 seconds)
17:17Damianos__ is now known as Damianos
17:18Damianos_ has left IRC (Damianos_!~damianos@68-186-144-58.dhcp.kgpt.tn.charter.com)
17:21awilliams has joined IRC (awilliams!mistik1@unaffiliated/mistik1)
17:23Trixboxer has left IRC (Trixboxer!~Trixboxer@115.124.115.71, Quit: "Achievement is not the end, its the beginning of new journey !!!")
17:28Parker955_Away is now known as Parker955
17:36Damianos has left IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com, Ping timeout: 244 seconds)
17:43Gremble has joined IRC (Gremble!~Ben@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com)
17:51Ryan52 has joined IRC (Ryan52!~ryan52@freegeek/ryan52)
17:52
<Ryan52>
How is the password for guest users set nowadays? I thought it used to default to the username that seems to not work on my installation.
17:53
!guest
17:53
<ltsp`>
Ryan52: Error: "guest" is not a valid command.
17:56
<Ryan52>
ah, I found the ssh keys, fancy. Sorry for the noise guys.
18:18Parker955 is now known as Parker955_Away
18:19Damianos has joined IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com)
18:19Parker955_Away is now known as Parker955
18:23Damianos_ has joined IRC (Damianos_!~damianos@68-186-144-58.dhcp.kgpt.tn.charter.com)
18:24Damianos has left IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com, Quit: Damianos)
18:24Damianos_ is now known as Damianos
18:39litlebuda has left IRC (litlebuda!~litlebuda@204.0.166.178.rev.vodafone.pt, Remote host closed the connection)
18:47yalu has left IRC (yalu!~yalu@189.8-200-80.adsl-dyn.isp.belgacom.be, Ping timeout: 252 seconds)
18:49yalu has joined IRC (yalu!~yalu@192.24-200-80.adsl-dyn.isp.belgacom.be)
19:05komunista has left IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk, Read error: Operation timed out)
19:30komunista has joined IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk)
19:33Damianos has left IRC (Damianos!~damianos@68-186-144-58.dhcp.kgpt.tn.charter.com, Read error: Connection reset by peer)
19:33Damianos has joined IRC (Damianos!~damianos@68-186-144-58.dhcp.kgpt.tn.charter.com)
19:41Damianos has left IRC (Damianos!~damianos@68-186-144-58.dhcp.kgpt.tn.charter.com, Quit: Colloquy for iPhone - http://colloquy.mobi)
19:45bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
19:56komunista has left IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk, Quit: Leaving.)
20:00vagrantc has joined IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net)
20:00vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
20:15Parker955 is now known as Parker955_Away
20:29Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com)
21:01rhorstkoetter has left IRC (rhorstkoetter!~rhorstkoe@opensuse/member/rhorstkoetter, Quit: Leaving.)
21:03Ryan52 has left IRC (Ryan52!~ryan52@freegeek/ryan52)
21:05uskerine has joined IRC (uskerine!~uske@80.30.244.131)
21:05
<uskerine>
hi
21:05
after installing "apt-get install ltsp-server"
21:05
i try "ltsp-build-client --arch i386"
21:05
but i get the following error: E: Failed getting release file http://archive.ubuntu.com/ubuntu/dists/precise/Release"
21:07
server is ubuntu, alternate disk (64 bits)
21:07
sorry
21:07
xubuntu
21:16bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 265 seconds)
21:30alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
21:31Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Quit: Leaving)
21:37
<alkisg>
vagrantc: http://paste.ubuntu.com/1020348/ kernel version ordering, is it ok?
21:38ricotz has joined IRC (ricotz!~rico@unaffiliated/ricotz)
21:40
<alkisg>
So I'm thinking we can keep the first one in the main menu (with entries for all BOOT_METHODS for it), and the rest ones can go in a "Other/previous Linux versions..." submenu
21:41
<vagrantc>
alkisg: i'm thinking you'll want the most compatible variant to be default, even if it's an older version ... hence my desire for ifcpu64.c32 integration
21:42
alkisg: so -486 or -generic should take precedence always
21:42
<alkisg>
vagrantc: the ifcpu64.c32 is a different boot menu. To make -486 or -generic have precedence, you'd set a distro default for LIST_KERNELs
21:43
<vagrantc>
alkisg: looking at that code makes my head spin ... :)
21:43
<alkisg>
Hehe took me some time but it's the fastest + smallest I could make it
21:44
<vagrantc>
might be worth commenting some of the variable substitutions and what they're doing
21:44
<alkisg>
Leave the final awk out to understand it faster
21:45
(by running it, I mean)
21:45
The kernel_prefix/suffix is needed because gentoo has the arch before the version in the kernel name
21:46
But overall, it's only controlled by 3 variables, 2 set by distro and the other either as a distro default or overriden by the user
21:47
...and the substitutions are weird again because gentoo has different arch/version ordering
21:48
<vagrantc>
alkisg: so the $i is just essentially an arbitrary key
21:48
<alkisg>
Yes, anything descending would do, just to sort them according to the LIST_KERNELS order
21:49
<vagrantc>
alkisg: so LIST_KERNELS controls preference for, say -486 ?
21:49
<alkisg>
If you put LIST_KERNELS="486 686 *" you get the kernels "newest kernel first, but also 486 first"
21:49
If you omit the *, you restrict to those 2 arches only
21:50
<uskerine>
hi, after installing dnsmasq and configuring /etc/dnsmasq.d/ltsp.conf
21:50
i can no longer resolve addresses
21:50
<vagrantc>
so the newest versions always appear first, regardless of LIST_KERNELS=" 486 686 *" ?
21:50
<uskerine>
(that's why my apt does not work)
21:51
<alkisg>
vagrantc: right. LIST_KERNELS only sorts the kernels of the same version
21:51
<vagrantc>
uskerine: is /etc/resolv.conf pointing to 127.0.0.1 for name resolution?
21:52
<uskerine>
it is
21:52
yes it is
21:52
<vagrantc>
uskerine: is there a port=0 setting in /etc/dnsmasq.d/ltsp.conf ? you might want to comment that out if so.
21:52
<uskerine>
yes there is
21:52
<vagrantc>
and restart dnsmasq
21:52
<uskerine>
should i comment it out?
21:52
<vagrantc>
"you might want to comment that out if so."
21:53
<uskerine>
i am doing it right now
21:53
:)
21:53
<vagrantc>
hopefully that fixes it ...
21:53
alternately, you could configure dnsmasq to not be a dns resolver.... but if it works fine as a dns caching proxy for you, ddisabling port=0 would be the easiest.
21:54
<uskerine>
now it works
21:54
but i am not sure of understanding what the hell i have done
21:54
i am a bit confused on resolvconf and dnsmasq functions
21:55
<vagrantc>
dnsmasq by default will set itself up as a resolver and cache DNS queries for you.
21:55
<uskerine>
is it installed by default?
21:55
<vagrantc>
the example dnsmasq.d/ltsp.conf snippet you used disabled DNS resolution, but resolvconf still configured it to use dnsmasq
21:55
<alkisg>
uskerine: 12.04?
21:55
<uskerine>
right
21:55
12.04
21:56
<alkisg>
uskerine: if you see problems after server reboot, read this bug report: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/959037
21:56
<vagrantc>
alkisg will of course be more knowledgeable about the details on ubuntu :)
21:56
<alkisg>
They made a mess by starting a dns server to solve libc shortcomings :(
21:57
<uskerine>
i actually think i saw the issues after reboot
21:57
<alkisg>
So starting dnsmasq as an actual dns server introduces conflicts
21:57
<uskerine>
which is what i have done by commenting "port 0" out
21:58
is that correct?
21:58
<vagrantc>
oh, so maybe that's not a good resolution, then.
21:58
<uskerine>
i will try and reboot
21:58
<alkisg>
Not really... commenting out port=0 will make the problem appear randomly
21:58
(if you're using network-manager, that is)
21:58
<vagrantc>
hah
21:59
<uskerine>
i have just installed "apt-get install dnsmasq" and included ltsp.conf to allow my network router act as DHCP
21:59
<alkisg>
Whichever dnsmasq instance starts first gets to do the resolving, but the network-manager -spawned dnsmasq only resolves for local clients
21:59
uskerine: do you have network manager installed?
21:59
<uskerine>
i don't know
21:59
i have a standard installation
22:00
<alkisg>
With the desktop CD?
22:00
<uskerine>
alternate CD (I needed the software RAID)
22:00
i am using Xubuntu Alternate 12.04
22:00
<alkisg>
I'm not sure about the alternate cd and xubuntu
22:00
How did you setup the network connection?
22:00
<uskerine>
i setup static IP address
22:00
<alkisg>
From the network applet, or from /etc/network/interfaces
22:00
?
22:00
<uskerine>
"/etc/network/interfaces
22:00
<alkisg>
Dual or single nic?
22:00
<uskerine>
I added 192.168.200.1 (the router IP) as DNS server
22:01
i have 4 NICs but I am only using one
22:01
so there is "eth2" plus "lo"
22:01
<alkisg>
dpkg -l network-manager
22:02
<uskerine>
i restarted and i got blank screen :$
22:02
hold on
22:02
could it be it is trying to resolve something?
22:02
<alkisg>
I don't think so
22:02
<uskerine>
no
22:02
it was just rebooting
22:02
it is ok
22:04
loading
22:04
hold on
22:04alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 244 seconds)
22:04
<uskerine>
seems like installed
22:04
i got "ii" network-maange 0.9.4.0
22:05
resolution works after reboot
22:05
but i am a bit scared on your "random" behaviour
22:05
:)
22:05
on what you mention as "random" behaviour
22:05
<alkisg>
OK if you see any problems after a few reboots read the bug report, otherwise leave it as is
22:06
<uskerine>
ok
22:09
btw, i noticed that chrome was much slower than ff when executed in the thin client (chrome executed locally worked faster)
22:09
is there any specific reason for that?
22:09
<alkisg>
X pixmap caching
22:09alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
22:09
<alkisg>
Firefox uses local X RAM to speed up things. That's good if you have thin clients with enough RAM, and bad if they only have little RAM
22:10
<uskerine>
i have 1gb ram thin clients
22:10
so chrome uses less memory on the thin client X server than ff, right?
22:10
<vagrantc>
it's also bad if firefox doesn't uncache the un-used pixmaps
22:10
<uskerine>
does that usually happen?
22:12
<vagrantc>
it's been a problem in the past ... hopefully they have proper checks for it in future code
22:13
<uskerine>
what happens if thin client memory is exhausted?
22:14
<vagrantc>
whichever application asks for more ram than is available crashes
22:14
so it's the luck of the draw, there.
22:14
<uskerine>
is there any place where thin client memory and cpu usage can be check?
22:16loather has joined IRC (loather!~khudson@wsip-98-175-250-115.sd.sd.cox.net)
22:19
<alkisg>
!localxterm
22:19
<ltsp`>
alkisg: localxterm: Any applications that you launch on a thin client actually runs on the server, not on the client itself. If you want to open a program on the client locally, you can type 'ltsp-localapps <program>' in a run dialog or in a terminal. For example, 'ltsp-localapps xterm' to open a terminal running on the client.
22:19
<uskerine>
i mean remotely
22:20
i will manage this stuff from a different city where the thin clients will be located
22:20
<alkisg>
You can either install ssh in the chroot or use a monitoring software like epoptes
22:20
!epoptes
22:20
<ltsp`>
alkisg: epoptes: Epoptes is a computer lab administration and monitoring tool. It works on Ubuntu and Debian based labs with LTSP or non-LTSP servers, thin and fat clients, standalone workstations, NX clients etc. More info: http://www.epoptes.org
22:21
<uskerine>
good thanks
22:21
one more question, ltsp uses ssh x11 tunneling by default
22:21
how complex or easy is to set to boot a thin client from a WAN interface?
22:22
<alkisg>
Line speed?
22:22
<uskerine>
ADSL for the thin client, FTTH for the server
22:22
<vagrantc>
latency is likely to be the killer more than raw bandwidth.
22:22
<uskerine>
FFTH has good latency, ADSL does not
22:22
<alkisg>
Not really worth it for ADSL, use x2go instead
22:23
<uskerine>
x2go what is that?
22:23
<alkisg>
!x2go
22:23
<ltsp`>
alkisg: x2go: x2go is an NX-based suite of applications that allow logging in to a remote X server from any OS. It's much more efficient than VNC over slow network. More info: http://www.x2go.org/
22:23
<uskerine>
can LTSP work with x2go instead of with ssh?
22:24
<alkisg>
With x2go you connect to your server from a remote location, it's unrelated to LTSP. Sure, it works if you have LTSP installed on your server.
22:24
<uskerine>
but i do not have to install LTSP
22:24
<alkisg>
Yes
22:24
<uskerine>
it is separate stuff
22:24
<alkisg>
Yes
22:24
<uskerine>
like vnc
22:24
<alkisg>
Right
22:24
<uskerine>
understood thanks
22:27
<alkisg>
vagrantc: so, about the pxe menus... I still think that it's best for the user to edit the files directly from pxelinux.cfg/default, i.e. to generate them the first time update-kernels runs, and then to never touch them except for "ltsp" and "ltsp-old" (kernels), which are always regenerated.
22:27
We could include some comments on top of those 2 files to make it clear for the user that he's not supposed to edit them.
22:29
So to edit the timeout, the user would edit pxelinux.cfg/default. From the same file he could remove some "include" directives, or add any custom ones he wants.
22:36
<vagrantc>
alkisg: so all the automatically updated stuff wouuld be in included files, but other files would only be generated initially?
22:37
brb
22:37vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
22:38
<uskerine>
pgrep nbd shows nothing, why?
22:41vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
22:46
<alkisg>
vagrantc: yup
22:46
I'm thinking we need those files: ltsp, ltsp-old, default, memtest, other (empty template with comments about localboot etc)
22:47
All can go in pxelinux.cfg. default can have both the header and the footer, and the includes
22:48
The user can customize the order by swapping the includes (e.g. if he wants localboot first)
22:49
ltsp will have only the newest kernel, for all boot methods. ltsp-old will have the non-default kernel (e.g. 686) and all the previous kernels, again for all boot methods.
22:49
...and will be shown in a submenu
22:50
So to change the timeout, background etc the user just edits pxelinux.cfg/default, it should be easier to understand than a custom /etc/ltsp/pxemenu.d scheme
22:52[GuS] has left IRC ([GuS]!~gustavo@unaffiliated/gus/x-663402, Quit: Konversation terminated!)
22:52
<vagrantc>
alkisg: that sounds pretty good
22:53
<alkisg>
Cool, if you also agree with the LIST_KERNELS="..." approach, I think I can have something ready soonish
22:54
<vagrantc>
i don't fully grok the LIST_KERNELS stuff yet
22:54
<alkisg>
Tell me about the autodetection stuff first
22:55ricotz has left IRC (ricotz!~rico@unaffiliated/ricotz, Quit: Ex-Chat)
22:55
<alkisg>
You can tell if the client supports pae, if it's 486/686 etc?
22:55
32bit, 64 bit...
22:55
<vagrantc>
alkisg: the easiest thing is using ifcpu64.c32 ... you can distinguish between amd64, pae and other.
22:56
<alkisg>
But you can't construct a menu out of that, you can only select the default kernel, right?
22:56
So the "other/older linux versions" will still be useful to select something else...
22:56
<vagrantc>
no, you select other menu items with it:
22:56
kernel ifcpu64.c32
22:57
append lenny64 -- lenny32
22:57
where lenny64 and lenny32 are other menu entries
22:58
or: append foo64 -- foopae -- foo32
22:58
<alkisg>
OK first of all we'll need a feature => kernel name function there
22:58
<vagrantc>
yup
22:59
<alkisg>
Does ifcpu64 work without problems? Can we default to it?
22:59
<vagrantc>
something similar to LIST_KERNELS, maybe?
22:59
alkisg: i've never seen ifcpu64 fail in such a way it couldn't boot.
22:59
<alkisg>
Cool
23:00
<vagrantc>
alkisg: there might be some possibility it boots a pae or amd64 system as other, though i haven't actually noticed.
23:00
<alkisg>
So yes, something similar to LIST_KERNELS, but for all features that ifcpu64 supports
23:00
E.g. PAE_LIST_KERNELS="generic-pae pae realtime"
23:00
<vagrantc>
essentially, which kernels support 64bit, pae, and other...
23:00
<alkisg>
*I meant plain generic there
23:01
<vagrantc>
i'd treat "other" as the lowest common denominator
23:01
<alkisg>
NONPAE_LIST_KERNELS="generic realtime"
23:01
Etc
23:01
We'll need two files for each feature
23:01* vagrantc heads to a meeting
23:01
<alkisg>
ok, cu in the morning
23:02Damianos has joined IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com)
23:03
<alkisg>
So ifcpu64 supports 3 different labels, 64bit, pae, 32bit
23:03
<vagrantc>
yup.
23:03
<alkisg>
6 ltsp* files then
23:03
3 for the "default" menu, and 3 for the "old" submenus
23:03
<vagrantc>
there's ifcpu that can break it down by processor features, but that's a bit more than i'd want to get into
23:05
<alkisg>
And we'd want 3 list similar to LIST_KERNELS provided by each distro
23:05
...and the user can override them if he wants to
23:05
I think that's the best plan for pxemenus we had so far, let's implement it :)
23:06
'night all
23:06alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)