IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 2 June 2012 (all times are UTC)
| 00:01 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
| 00:12 | khildin has left IRC (khildin!~khildin@ip-80-236-227-228.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
| 00:32 | risca has joined IRC (risca!~risca@81-233-43-131-no18.tbcn.telia.com) | |
| 00:42 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 252 seconds) | |
| 01:19 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 01:30 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 240 seconds) | |
| 01:38 | alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47) | |
| 01:38 | SmallR2002 has joined IRC (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net) | |
| 01:43 | andygraybeal has joined IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net) | |
| 02:59 | risca has left IRC (risca!~risca@81-233-43-131-no18.tbcn.telia.com, Quit: Lämnar) | |
| 03:05 | vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net) | |
| 03:05 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
| 03:06 | andygraybeal has left IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net, Ping timeout: 246 seconds) | |
| 03:18 | Damianos has left IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com, Ping timeout: 244 seconds) | |
| 03:24 | Damianos 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:58 | sha has left IRC (sha!~sha@e177119119.adsl.alicedsl.de, Ping timeout: 240 seconds) | |
| 03:59 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 04:00 | sha 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:06 | adrianorg_ has left IRC (adrianorg_!~adrianorg@177.18.171.174, Read error: Operation timed out) | |
| 04:07 | Damianos 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:10 | VectorX 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:13 | Damianos 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:36 | staffencasa 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:44 | komunista 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:53 | VectorX 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:02 | LoveStorm has left IRC (LoveStorm!Storm@gateway/shell/trekweb.org/x-gjvkderelmmzdwng, Changing host) | |
| 06:02 | LoveStorm has joined IRC (LoveStorm!Storm@unaffiliated/lovestorm) | |
| 06:02 | LoveStorm 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:11 | Parker955_Away is now known as Parker955 | |
| 06:23 | Damianos_ 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:24 | Damianos_ has left IRC (Damianos_!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com, Read error: Connection reset by peer) | |
| 06:24 | Damianos_ 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:26 | Damianos 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:29 | Damianos_ 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:50 | bobby_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:03 | vagrantc 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:06 | Parker955 is now known as Parker955_Away | |
| 07:08 | <Hyperbyte> Meh... off to the radio station...
| |
| 07:24 | alexqwesa 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:33 | tarzeau_ 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:24 | alexqwesa 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:38 | bobby_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:02 | Steve_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:12 | rhorstkoetter has joined IRC (rhorstkoetter!~rhorstkoe@opensuse/member/rhorstkoetter) | |
| 10:20 | Trixboxer 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:23 | toscalix has joined IRC (toscalix!~toscalix@109.144.24.70) | |
| 10:24 | andygraybeal has joined IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net) | |
| 10:30 | andygraybeal has left IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net, Ping timeout: 246 seconds) | |
| 10:41 | F-GT has left IRC (F-GT!~phantom@ppp121-44-97-140.lns20.syd6.internode.on.net, Quit: Leaving) | |
| 10:43 | F-GT has joined IRC (F-GT!~phantom@ppp121-44-97-140.lns20.syd6.internode.on.net) | |
| 10:55 | awilliam1 has joined IRC (awilliam1!mistik1@unaffiliated/mistik1) | |
| 10:56 | awilliams has left IRC (awilliams!mistik1@unaffiliated/mistik1, Ping timeout: 248 seconds) | |
| 10:56 | awilliam1 is now known as awilliams | |
| 11:04 | staffencasa has joined IRC (staffencasa!~staffenca@128.193.8.220) | |
| 11:07 | Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Remote host closed the connection) | |
| 11:09 | toscalix_ has joined IRC (toscalix_!~toscalix@212-166-142-231.red-acceso.airtel.net) | |
| 11:11 | toscalix 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:27 | staffencasa has left IRC (staffencasa!~staffenca@128.193.8.220, Ping timeout: 244 seconds) | |
| 11:30 | mikkel has joined IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk) | |
| 11:31 | ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 252 seconds) | |
| 11:34 | nenenaiad 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:06 | toscalix_ 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:15 | nenenaiad has left IRC (nenenaiad!540d6e6e@gateway/web/freenode/ip.84.13.110.110, Quit: Page closed) | |
| 12:26 | nenenaiad has joined IRC (nenenaiad!540d6e6e@gateway/web/freenode/ip.84.13.110.110) | |
| 12:38 | nenenaiad 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:50 | awilliam1 has joined IRC (awilliam1!mistik1@unaffiliated/mistik1) | |
| 12:50 | awilliams has left IRC (awilliams!mistik1@unaffiliated/mistik1, Ping timeout: 252 seconds) | |
| 12:51 | awilliam1 is now known as awilliams | |
| 13:02 | <alkisg> nenenaiad: are you using a 2-nic setup?
| |
| 13:03 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Read error: Operation timed out) | |
| 13:05 | alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47) | |
| 13:09 | awilliams has left IRC (awilliams!mistik1@unaffiliated/mistik1, Ping timeout: 240 seconds) | |
| 13:27 | <nenenaiad> Thanks Alkisg - Yes I am
| |
| 13:30 | mikkel 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:09 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 14:11 | nenenaiad has left IRC (nenenaiad!540d6e6e@gateway/web/freenode/ip.84.13.110.110, Quit: Page closed) | |
| 14:15 | rhorstkoetter has left IRC (rhorstkoetter!~rhorstkoe@opensuse/member/rhorstkoetter, Quit: Leaving.) | |
| 14:21 | litlebuda has joined IRC (litlebuda!~litlebuda@204.0.166.178.rev.vodafone.pt) | |
| 14:30 | litlebuda has left IRC (litlebuda!~litlebuda@204.0.166.178.rev.vodafone.pt, Remote host closed the connection) | |
| 14:32 | litlebuda has joined IRC (litlebuda!~litlebuda@204.0.166.178.rev.vodafone.pt) | |
| 14:45 | Phantomas has joined IRC (Phantomas!~Phantomas@unaffiliated/phantomas) | |
| 14:53 | toscalix has joined IRC (toscalix!~toscalix@153.176.219.87.dynamic.jazztel.es) | |
| 15:28 | komunista has left IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk, Ping timeout: 260 seconds) | |
| 16:03 | toscalix has left IRC (toscalix!~toscalix@153.176.219.87.dynamic.jazztel.es, Read error: Connection reset by peer) | |
| 16:03 | toscalix_ has joined IRC (toscalix_!~toscalix@153.176.219.87.dynamic.jazztel.es) | |
| 16:07 | toscalix_ has left IRC (toscalix_!~toscalix@153.176.219.87.dynamic.jazztel.es, Remote host closed the connection) | |
| 16:09 | toscalix_ has joined IRC (toscalix_!~toscalix@153.176.219.87.dynamic.jazztel.es) | |
| 16:15 | Parker955_Away is now known as Parker955 | |
| 16:17 | toscalix_ has left IRC (toscalix_!~toscalix@153.176.219.87.dynamic.jazztel.es, Remote host closed the connection) | |
| 16:20 | rhorstkoetter has joined IRC (rhorstkoetter!~rhorstkoe@opensuse/member/rhorstkoetter) | |
| 16:28 | monteslu_ is now known as monteslu | |
| 16:29 | komunista has joined IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk) | |
| 16:29 | adrianorg_ 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:41 | Damianos 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:50 | F-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:54 | Damianos has left IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com, Remote host closed the connection) | |
| 16:57 | Damianos has joined IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com) | |
| 16:59 | Damianos_ has joined IRC (Damianos_!~damianos@68-186-144-58.dhcp.kgpt.tn.charter.com) | |
| 17:06 | Parker955 is now known as Parker955_Away | |
| 17:16 | Damianos__ has joined IRC (Damianos__!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com) | |
| 17:17 | Damianos has left IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com, Ping timeout: 240 seconds) | |
| 17:17 | Damianos__ is now known as Damianos | |
| 17:18 | Damianos_ has left IRC (Damianos_!~damianos@68-186-144-58.dhcp.kgpt.tn.charter.com) | |
| 17:21 | awilliams has joined IRC (awilliams!mistik1@unaffiliated/mistik1) | |
| 17:23 | Trixboxer has left IRC (Trixboxer!~Trixboxer@115.124.115.71, Quit: "Achievement is not the end, its the beginning of new journey !!!") | |
| 17:28 | Parker955_Away is now known as Parker955 | |
| 17:36 | Damianos has left IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com, Ping timeout: 244 seconds) | |
| 17:43 | Gremble has joined IRC (Gremble!~Ben@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com) | |
| 17:51 | Ryan52 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:18 | Parker955 is now known as Parker955_Away | |
| 18:19 | Damianos has joined IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com) | |
| 18:19 | Parker955_Away is now known as Parker955 | |
| 18:23 | Damianos_ has joined IRC (Damianos_!~damianos@68-186-144-58.dhcp.kgpt.tn.charter.com) | |
| 18:24 | Damianos has left IRC (Damianos!~Damianos@68-186-144-58.dhcp.kgpt.tn.charter.com, Quit: Damianos) | |
| 18:24 | Damianos_ is now known as Damianos | |
| 18:39 | litlebuda has left IRC (litlebuda!~litlebuda@204.0.166.178.rev.vodafone.pt, Remote host closed the connection) | |
| 18:47 | yalu has left IRC (yalu!~yalu@189.8-200-80.adsl-dyn.isp.belgacom.be, Ping timeout: 252 seconds) | |
| 18:49 | yalu has joined IRC (yalu!~yalu@192.24-200-80.adsl-dyn.isp.belgacom.be) | |
| 19:05 | komunista has left IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk, Read error: Operation timed out) | |
| 19:30 | komunista has joined IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk) | |
| 19:33 | Damianos has left IRC (Damianos!~damianos@68-186-144-58.dhcp.kgpt.tn.charter.com, Read error: Connection reset by peer) | |
| 19:33 | Damianos has joined IRC (Damianos!~damianos@68-186-144-58.dhcp.kgpt.tn.charter.com) | |
| 19:41 | Damianos has left IRC (Damianos!~damianos@68-186-144-58.dhcp.kgpt.tn.charter.com, Quit: Colloquy for iPhone - http://colloquy.mobi) | |
| 19:45 | bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) | |
| 19:56 | komunista has left IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk, Quit: Leaving.) | |
| 20:00 | vagrantc has joined IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net) | |
| 20:00 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
| 20:15 | Parker955 is now known as Parker955_Away | |
| 20:29 | Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com) | |
| 21:01 | rhorstkoetter has left IRC (rhorstkoetter!~rhorstkoe@opensuse/member/rhorstkoetter, Quit: Leaving.) | |
| 21:03 | Ryan52 has left IRC (Ryan52!~ryan52@freegeek/ryan52) | |
| 21:05 | uskerine 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:16 | bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 265 seconds) | |
| 21:30 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 21:31 | Steve_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:38 | ricotz 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:04 | alexqwesa 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:09 | alexqwesa 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:16 | loather 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:37 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
| 22:38 | <uskerine> pgrep nbd shows nothing, why?
| |
| 22:41 | vagrantc 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:55 | ricotz 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:02 | Damianos 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:06 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |