IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 8 January 2010 (all times are UTC)
| 00:09 | alkisg has joined #ltsp | |
| 00:11 | <alkisg> !ltsp-source
| |
| 00:11 | <ltspbot> alkisg: "ltsp-source" :: at http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/files
| |
| 00:21 | MaRX-Mode has quit IRC | |
| 00:21 | MaRX-Mode has joined #ltsp | |
| 00:47 | gfarras has joined #ltsp | |
| 00:52 | alkisg has quit IRC | |
| 01:06 | GGD has joined #ltsp | |
| 01:09 | Kicer86 has joined #ltsp | |
| 01:16 | shawnp0wers has joined #ltsp | |
| 01:20 | F-GT has quit IRC | |
| 01:21 | F-GT has joined #ltsp | |
| 01:23 | GGD_ has quit IRC | |
| 01:28 | shawnp0wers has quit IRC | |
| 01:43 | alkisg_ has joined #ltsp | |
| 01:52 | alkisg_ has left #ltsp | |
| 02:06 | alkisg_ has joined #ltsp | |
| 02:07 | Appiah has quit IRC | |
| 02:17 | Gadi has quit IRC | |
| 02:18 | Gadi has joined #ltsp | |
| 02:25 | Appiah has joined #ltsp | |
| 02:32 | alkisg_ has quit IRC | |
| 02:35 | F-GT has quit IRC | |
| 02:36 | alkisg has joined #ltsp | |
| 02:38 | * alkisg tries the fat client plugin for the 3rd time... :( | |
| 02:49 | F-GT has joined #ltsp | |
| 02:54 | elias_a has joined #ltsp | |
| 03:11 | alkisg has quit IRC | |
| 03:16 | alkisg has joined #ltsp | |
| 03:23 | vagrantc has quit IRC | |
| 03:28 | Kicer86 has quit IRC | |
| 03:29 | Selveste1 has quit IRC | |
| 03:35 | Faithful has quit IRC | |
| 03:35 | Faithful has joined #ltsp | |
| 04:03 | Roel_ has joined #ltsp | |
| 04:14 | hersonls has quit IRC | |
| 04:37 | alkisg has quit IRC | |
| 04:44 | alkisg has joined #ltsp | |
| 04:45 | Selveste1 has joined #ltsp | |
| 04:46 | alkisg has joined #ltsp | |
| 04:58 | alkisg has quit IRC | |
| 05:01 | alkisg has joined #ltsp | |
| 05:11 | markit has joined #ltsp | |
| 05:12 | <markit> hi, debian sid, stable ltsp chroot, I've LTSP_CONFIG=True in lts.conf, but can't find doc about it's meaning, any clue?
| |
| 05:18 | and I've pressed ctrl+alt+f1 and I'm in the console login, but does not let me login with username and password I've just used for X login
| |
| 05:19 | ok, seen in teh doc :)
| |
| 05:19 | only the first question remains :) (ltsp_config stuff)
| |
| 05:22 | <alkisg> markit: why would you need LTSP_CONFIG? What do you want to do?
| |
| 05:22 | <markit> alkisg: is in the default config, and I don't want to remove since I don't know what is there for
| |
| 05:23 | I've looked ad man lts.conf but is not mentioned
| |
| 05:23 | nor in the upstream ltspmanual.pdf (probably is a debian stuff)
| |
| 05:23 | alkisg: do you use debian also?
| |
| 05:23 | <alkisg> markit: if ! boolean_is_true "$LTSP_CONFIG" ; then
| |
| 05:23 | . /usr/share/ltsp/ltsp_config
| |
| 05:23 | fi
| |
| 05:23 | That's its meaning... no I'm not using Debian
| |
| 05:24 | <markit> alkisg: so? I'm not a guru... skips a config file in /usr/share..? why on earth should be put there?
| |
| 05:24 | <alkisg> markit: that's all I know about it :)
| |
| 05:25 | <markit> alkisg: well, thanks a lot :)
| |
| 05:26 | <alkisg> markit: btw, that file is in the chroot, so: /opt/ltsp/i386/usr/share/ltsp/ltsp_config
| |
| 05:27 | # set to determine if ltsp_config has already been sourced
| |
| 05:27 | export LTSP_CONFIG=${LTSP_CONFIG:-"True"}
| |
| 05:27 | <markit> ah, because I have in "host" /usr/share/ltsp/, so thought I could create a ltsp_config file there, but seemd of no usefull use
| |
| 05:27 | what is the file you are finding this code into?
| |
| 05:27 | <alkisg> /opt/ltsp/i386/usr/share/ltsp/ltsp_config
| |
| 05:28 | <markit> I mean, where did you find "if ! boolean_is_true "$LTSP_CONFIG" ; then" etc?
| |
| 05:28 | <alkisg> That was in ltsp-trunk/client/screen-x-common
| |
| 05:28 | So I guess this whole LTSP_CONFIG thing is the equivelant of #ifdef / #include that C uses
| |
| 05:29 | hersonls has joined #ltsp | |
| 05:30 | <markit> yes, can't understand the logic... since is set to =True by default, means it skips all the /opt/ltsp/i386/usr/share/ltsp/ltsp_config stuff
| |
| 05:30 | but there is a lot of settings there... in any case, it works :)
| |
| 05:38 | <alkisg> markit: so I guess with LTSP_CONFIG=True in lts.conf you're saving some milliseconds, as this script runs one additional time :)
| |
| 05:40 | *doesn't run an additional time
| |
| 05:44 | <markit> alkisg: what distro (host distro) do you use? ubuntu?
| |
| 05:44 | <alkisg> markit: yup
| |
| 05:45 | <markit> have you tried to install a more recent kernel in chroot environment?
| |
| 05:45 | I've a eeebox that requires a driver that is only in recent (2.6.30) kernel
| |
| 05:45 | <alkisg> Yeah sure lots of times
| |
| 05:46 | I recently learned that it's even "normal" to have more recent distro versions in the chroot :)
| |
| 05:46 | I.e. you could have a squeeze chroot on a lenny server
| |
| 05:46 | <markit> I've a bit confused by the info I've got from internet, and me being ignorant in linux way of manage kernels/boots/initram whatever
| |
| 05:46 | alkisg: in fact, I've a sqeeze chroot in a sid server :)
| |
| 05:46 | btw, dist=testing did not worked, had to say dist=sqeeze
| |
| 05:47 | I've tried dist=sid but at the moment dependencies seem to be broken, and I don't know how to fix since the installation did not finished
| |
| 05:47 | in any case
| |
| 05:47 | from a sqeeze chroot
| |
| 05:47 | do I have to simply chroot in /opt/ltsp/i386
| |
| 05:48 | aptitude update && aptitude install newkernel ?
| |
| 05:48 | <alkisg> Won't you need to change your sources to find the new kernel?
| |
| 05:48 | <markit> do I need a ltsp-kernel-rebuild from the server then?
| |
| 05:48 | tarzeau has quit IRC | |
| 05:48 | <alkisg> No no no rebuilds needed
| |
| 05:48 | <markit> alkisg: yes, sure, add sid sources
| |
| 05:49 | <alkisg> It sounds fine to me (just be careful not to update the whole chroot to sid :))
| |
| 05:49 | <markit> no? but then tfpt will point to old kernels, no?
| |
| 05:49 | <alkisg> Remember to run ltsp-update-kernels afterwards
| |
| 05:49 | That'll update the kernels in the tftp dir
| |
| 05:49 | <markit> ah, yes, update kernels
| |
| 05:50 | chroot /opt/ltsp/i386 update-initramfs -u isn't needed also?
| |
| 05:51 | <alkisg> Afaik there's a hook that takes care of this, so it shouldn't be needed
| |
| 05:51 | <markit> and no need for mount -t proc /proc /proc ?
| |
| 05:52 | my problem is that I've a mix of info, don't knwo what are obsolete, what are not for debian, etc
| |
| 05:52 | <alkisg> I'm not sure if the postinst of the new kernel needs it. Better do it, just in case.
| |
| 05:52 | !docs
| |
| 05:52 | <ltspbot> alkisg: "docs" :: For the most current documentation, see https://sourceforge.net/apps/mediawiki/ltsp/index.php?title=Ltsp_LtspDocumentationUpstream
| |
| 05:52 | <alkisg> ^^^ all the info there should be up to date
| |
| 05:52 | (mostly :D)
| |
| 05:53 | * alkisg reboots to test the new ltsp fat-client script, brb... | |
| 05:53 | alkisg has quit IRC | |
| 05:55 | alkisg has joined #ltsp | |
| 06:07 | Selveste1 has quit IRC | |
| 06:25 | hersonls has quit IRC | |
| 06:39 | scottmaccal has joined #ltsp | |
| 06:41 | <scottmaccal> Morning all.
| |
| 06:42 | Faithful has quit IRC | |
| 06:43 | hersonls has joined #ltsp | |
| 06:43 | Faithful has joined #ltsp | |
| 06:43 | <sbalneav> Morning all. I'll be afk most of the day, as I'll be in a management training course most of the day
| |
| 06:44 | <scottmaccal> Ahh, management.
| |
| 06:49 | sene has quit IRC | |
| 06:53 | Selveste1 has joined #ltsp | |
| 06:54 | Faithful has quit IRC | |
| 06:56 | Faithful has joined #ltsp | |
| 06:57 | klausade has quit IRC | |
| 07:00 | <markit> mmm I've got a series of "grep: /proc/modules: No such file or directory" during kernel installation
| |
| 07:02 | hersonls has quit IRC | |
| 07:02 | hersonls has joined #ltsp | |
| 07:12 | Selveste1 has quit IRC | |
| 07:14 | <markit> ok, the mount -t /proc stuff is needed
| |
| 07:14 | _gentgeen_ has joined #ltsp | |
| 07:16 | <_UsUrPeR_> g'morning all
| |
| 07:16 | Selveste1 has joined #ltsp | |
| 07:22 | <markit> in the manual there is a chapter "using nfs instead of nbd", but I want to do the opposite, any tip?
| |
| 07:22 | (debian uses nfs by default)
| |
| 07:24 | <alkisg> markit: I think if you follow it the other way around, you should be fine. See also: https://help.ubuntu.com/community/UbuntuLTSP/LTSPWithoutNFS
| |
| 07:27 | highvoltage: in the 010-fat-client script, e.g. ubuntu-desktop is installed, then gdm is removed (and that also removes ubuntu-desktop) and then `apt-get autoremove` is executed, which removes almost everything that was installed by ubuntu-desktop... ?
| |
| 07:29 | sene has joined #ltsp | |
| 07:32 | <markit> alkisg: thanks, I have to improve my skill in retriving info from internet :(
| |
| 07:32 | shawnp0wers has joined #ltsp | |
| 07:33 | <alkisg> markit: mainly the upstream docs, and that UbuntuLTSP wiki (even if it's mainly Ubuntu-oriented) are the best sources I found
| |
| 07:33 | <markit> alkisg: btw, considering that with nfs there is no need of ltsp-image-build (or whatever) at every lts.conf change, I wonder if does worth the trouble
| |
| 07:34 | <alkisg> markit: I imagine the client will need about half the time for booting... and that's about it. But if you also want localapps, the speed after the booting will also be affected...
| |
| 07:34 | <markit> alkisg: the link about "withoutNFS" tells just that THEY have dropped nfs and how to restore, sigh
| |
| 07:34 | <alkisg> Yes, again, you need to do the opposite :)
| |
| 07:34 | <markit> there is no "opposite" possible
| |
| 07:34 | <alkisg> Why not?
| |
| 07:36 | <markit> root_write_method="bind_mounts" instead of "unionfs", but my setup is "", that means that a) bind_mounts is the default b) has to be defined elsewhere
| |
| 07:36 | <alkisg> purge nfs from the chroot, put root_write_method="", remove /opt/ltsp/i386/etc/initramfs-tools/conf.d/ltsp, regenerate initramfs etc
| |
| 07:36 | <highvoltage> alkisg: hmm, one moment..
| |
| 07:36 | <markit> purge nfs from the chroot? or from the server?
| |
| 07:37 | <alkisg> Well never mind, leave it without purging :D
| |
| 07:37 | It shouldn't make any difference
| |
| 07:38 | highvoltage: an idea is to "analyze" all the ubuntu-desktop dependencies, then `grep -v` gdm*, networkmanager* etc, and install what packages are left...
| |
| 07:39 | markit: the Debian-wise people are usually here later on, e.g. in about 10 hours...
| |
| 07:44 | <markit> alkisg: thanks (was on the phone, back now)
| |
| 07:44 | <highvoltage> alkisg: what you're saying is making complete sense, I'm just trying to figure out why it worked for me and stgraber :)
| |
| 07:46 | <alkisg> highvoltage: hmm maybe by default it's ran as a task, while I had to run it manually with apt-get install ubuntu-desktop?
| |
| 07:47 | Ah, no...
| |
| 07:47 | <stgraber> that's interesting, I didn't see the issue though I perfectly understand why it'd happen
| |
| 07:47 | <highvoltage> alkisg: just to be clear, what happened is that the autoremove removed *everything* that was originally installed by the ubuntu-desktop meta-package?
| |
| 07:48 | <stgraber> highvoltage: we should actually do: tasksel --install ubuntu-desktop instead of the apt-get install ubuntu-desktop
| |
| 07:48 | that should avoid that kind of issue
| |
| 07:48 | <highvoltage> indeed. still just weird that it didn't happen with us :)
| |
| 07:48 | <stgraber> yep
| |
| 07:48 | <alkisg> highvoltage: I'm not really sure. After the 3-4 problems I experienced and the workarounds I had to do, I was left with a chroot without edubuntu-desktop. So I tried to run the script commands manually, and that's what I got
| |
| 07:49 | stgraber: but that won't work with edubuntu-desktop, will it?
| |
| 07:49 | <stgraber> edubuntu-desktop also exists as a task
| |
| 07:49 | <alkisg> tasksel --task-packages edubuntu-desktop ==> nothing
| |
| 07:49 | <stgraber> weird
| |
| 07:50 | ah, right, edubuntu-desktop-gnome
| |
| 07:50 | <alkisg> Ah, better :)
| |
| 07:50 | OK, /me tries manually with tasksel...
| |
| 07:51 | Faithful has quit IRC | |
| 07:52 | <alkisg> :( it downloads them all even though most of them are already install, this will take some time.... :-/
| |
| 07:52 | Faithful has joined #ltsp | |
| 07:55 | panthera has quit IRC | |
| 07:55 | panthera has joined #ltsp | |
| 07:55 | panthera has quit IRC | |
| 07:57 | dro has joined #ltsp | |
| 07:58 | panthera has joined #ltsp | |
| 08:04 | Selveste1_ has joined #ltsp | |
| 08:06 | Selveste1 has quit IRC | |
| 08:12 | johnny has left #ltsp | |
| 08:24 | dro_ has joined #ltsp | |
| 08:24 | dro has quit IRC | |
| 08:25 | hersonls has quit IRC | |
| 08:28 | hersonls has joined #ltsp | |
| 08:31 | dro_ has quit IRC | |
| 08:32 | mgariepy has joined #ltsp | |
| 08:33 | <mgariepy> good morning all
| |
| 08:35 | dro has joined #ltsp | |
| 08:38 | <dro> cisco vpn issue, it's probably something simple I just don't see it
| |
| 08:45 | <Appiah> hmm?
| |
| 08:46 | <dro> i've ran the cisco asa asdm vpn wizard and I can actually connect to the vpn now
| |
| 08:46 | problem is that I can't see the inside network
| |
| 08:46 | <alkisg> highvoltage, stgraber: apt-get --force-yes -yy --purge remove gdm network-manager.* modemmanager ubufox apport-gtk apport apport-symptoms jockey-common jockey-gtk
| |
| 08:46 | E: Couldn't find package network-manager.*
| |
| 08:46 | <dro> lol wrong room lol
| |
| 08:46 | sorry
| |
| 08:46 | <alkisg> Maybe that's why it worked for you, I think I corrected that manually ...
| |
| 08:47 | <Appiah> dro: :D
| |
| 08:47 | <dro> <----tired
| |
| 08:47 | lol
| |
| 08:50 | dro_ has joined #ltsp | |
| 08:50 | dro has quit IRC | |
| 08:51 | markit has quit IRC | |
| 08:51 | dro_ has quit IRC | |
| 09:02 | Gadi1 has joined #ltsp | |
| 09:02 | <stgraber> alkisg: are you using a custom mirror or something ?
| |
| 09:03 | alkisg: seems like broken sources.list to me
| |
| 09:03 | <alkisg> stgraber: deb http://gr.archive.ubuntu.com/ubuntu/ lucid
| |
| 09:03 | (=the default for my region)
| |
| 09:03 | stgraber: I don't think purge accepts wildcards
| |
| 09:04 | Q-FUNK has joined #ltsp | |
| 09:04 | <Q-FUNK> ahoy
| |
| 09:05 | stgraber: still alive? :)
| |
| 09:05 | hersonls has quit IRC | |
| 09:06 | <alkisg> stgraber: or, it was already removed, and that's what caused the error. Here's the full output: http://ltsp.pastebin.com/m382ac86a
| |
| 09:08 | gfarras has quit IRC | |
| 09:11 | gfarras has joined #ltsp | |
| 09:13 | <alkisg> highvoltage, stgraber: after manually installing / removing the packages, I'm getting an ldm segfault right after inputting my username/password. Any help welcome :)
| |
| 09:19 | <highvoltage> alkisg: ouch, sorry no idea
| |
| 09:19 | <alkisg> OK, I'll try installing the debug versions
| |
| 09:19 | <highvoltage> my guess is that there's probably something that ldm needs that's gone, but that doesn't help much :)
| |
| 09:22 | hersonls has joined #ltsp | |
| 09:26 | <Roel_> hi guys
| |
| 09:26 | I get the following in xorglog : Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices
| |
| 09:26 | anyone any idea why that is... it seems to detect everything by itself
| |
| 09:29 | <Appiah> is it trying to use openchrome?
| |
| 09:30 | <Roel_> no I don't think so
| |
| 09:30 | shall I pastebin the full xorg log?
| |
| 09:30 | <Appiah> please do so
| |
| 09:31 | <Roel_> http://pastebin.org/72517
| |
| 09:31 | <Appiah> sis O_o
| |
| 09:32 | <Roel_> :)
| |
| 09:32 | that crap has got to work
| |
| 09:33 | <Appiah> so it fails at sis , then tries vesa , fails , and goes to fbdev
| |
| 09:34 | What dist are you running?
| |
| 09:34 | and what version
| |
| 09:34 | <Roel_> gentoo
| |
| 09:34 | <Appiah> chroot too?
| |
| 09:34 | <Gadi1> Roel_: try loading the sisfb module
| |
| 09:35 | <Roel_> hmm so where do I set that stuff for ltsp...
| |
| 09:35 | <Appiah> you can force x settings in lts.conf
| |
| 09:36 | <Gadi1> Roel_: in you lts.conf, add MODULE_01 = sisfb
| |
| 09:36 | <Roel_> thx
| |
| 09:36 | I can't seem to find the old pages where all the documentation about lts.conf is gone
| |
| 09:37 | <Appiah> checked the new?
| |
| 09:38 | <alkisg> !lts.conf
| |
| 09:38 | <ltspbot> alkisg: "lts.conf" :: http://manpages.ubuntu.com/lts.conf
| |
| 09:38 | <Roel_> !docs
| |
| 09:38 | <ltspbot> Roel_: "docs" :: For the most current documentation, see https://sourceforge.net/apps/mediawiki/ltsp/index.php?title=Ltsp_LtspDocumentationUpstream
| |
| 09:38 | <Roel_> !lts.conf
| |
| 09:38 | <ltspbot> Roel_: "lts.conf" :: http://manpages.ubuntu.com/lts.conf
| |
| 09:38 | <Gadi1> Roel_: create a file in /var/lib/tftpboot/ltsp/i386/lts.conf (or whatever is suitable for gentoo)
| |
| 09:38 | <Roel_> yeah, I have that file
| |
| 09:38 | Otherwise I don't think it would be running as far as it does ;)
| |
| 09:39 | <Gadi1> well, lts.conf is not strictly needed
| |
| 09:39 | without it, it uses defaults
| |
| 09:40 | <Roel_> true
| |
| 09:41 | btw: those ubuntu docs are really complete
| |
| 09:41 | :) great work
| |
| 09:41 | <alkisg> They're upstream docs, not ubuntu-specific :)
| |
| 09:41 | But they're not yet in the sf site, so I put the ubuntu manpages link instead...
| |
| 09:46 | Can someone help with LDM-crash debugging? I've set LDM_DEBUG=True, but I'm not seeing anything different in /var/log/ldm.log... How would I get a stack trace?
| |
| 09:47 | Roel__ has joined #ltsp | |
| 09:47 | <Roel__> that means I shouldn't be loading sisfb?
| |
| 09:47 | johnny has joined #ltsp | |
| 09:48 | <Gadi1> huh?
| |
| 09:48 | gfarras has quit IRC | |
| 09:49 | <Roel__> > I think I have the driver compiled in the kernel
| |
| 09:49 | <Gadi1> the sisfb driver?
| |
| 09:50 | brb
| |
| 09:50 | Gadi1 has left #ltsp | |
| 09:51 | <Roel__> yes the sisfb driver is it possible it's already included in the kernel
| |
| 09:51 | Ahmuck has quit IRC | |
| 09:52 | <Roel__> I have compiled it in the kernel... or is sisfb a specific one for xorg?
| |
| 09:52 | alkisg has quit IRC | |
| 09:52 | Gadi1 has joined #ltsp | |
| 09:53 | Ahmuck has joined #ltsp | |
| 09:54 | Faithful has quit IRC | |
| 09:54 | alkisg has joined #ltsp | |
| 09:55 | Faithful has joined #ltsp | |
| 10:00 | Roel_ has quit IRC | |
| 10:03 | <Roel__> c
| |
| 10:06 | gfarras has joined #ltsp | |
| 10:10 | staffencasa has joined #ltsp | |
| 10:12 | Selveste1_ has quit IRC | |
| 10:12 | grey-monkey has left #ltsp | |
| 10:12 | <Roel__> I still can't seem to get it to work
| |
| 10:13 | my xorg log is still the same and I think my sisfb is compiled-in
| |
| 10:13 | http://pastebin.org/72532
| |
| 10:13 | http://pastebin.org/72517
| |
| 10:13 | can someone check the files and see what I am missing here
| |
| 10:13 | ?
| |
| 10:13 | Selveste1_ has joined #ltsp | |
| 10:15 | <Gadi1> Roel__: at the console on the thin client, can you modprobe sisfb?
| |
| 10:15 | or does it give you an error?
| |
| 10:16 | <Roel__> I didn't compile those as modules so I can't
| |
| 10:16 | <Gadi1> so, you have all frameboffers statically compiled in the kernel?
| |
| 10:16 | <Roel__> it says there is no modules.dep or something which is correct :)
| |
| 10:16 | <Gadi1> ah
| |
| 10:16 | you have no modules at all
| |
| 10:17 | Q-FUNK has quit IRC | |
| 10:18 | alkisg has quit IRC | |
| 10:18 | <Roel__> indeed
| |
| 10:18 | I compiled it all in avoiding the manual stuff to be copied
| |
| 10:19 | but I think dmesg clearly states the driver is loaded
| |
| 10:20 | I think I should manually add a busID or something
| |
| 10:20 | alkisg has joined #ltsp | |
| 10:20 | <Roel__> could that be possible, I remeber my old 4.2 working
| |
| 10:20 | johnny has left #ltsp | |
| 10:21 | johnny has joined #ltsp | |
| 10:21 | <Gadi1> Roel__: can you get the bus id for the vga card?
| |
| 10:22 | <Roel__> eeu
| |
| 10:22 | like doing lspci?
| |
| 10:23 | <Gadi1> yeah - then you can try: X_OPTION_01 = "BusID \"PCI:1:0:0\""
| |
| 10:23 | (or X_DEVICE_OPTION_01)
| |
| 10:25 | <Roel__> brb
| |
| 10:25 | 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 550 PCI/AGP VGA Display Adapter
| |
| 10:29 | something like this X_DEVICE_OPTION_01 = "BusID \"PCI:01:00.0\""
| |
| 10:29 | or should that last dot be a :
| |
| 10:41 | Selveste1_ has quit IRC | |
| 10:46 | gfarras has quit IRC | |
| 10:48 | gfarras has joined #ltsp | |
| 10:54 | <Roel__> That did work man
| |
| 10:54 | Gadi1 : thx alot ... it just needed that busID
| |
| 10:54 | <Ahmuck> alkisg: u gave me a command once to put on a cd that would boot to an ip address
| |
| 10:54 | this allowed me to boot an iso to a partiucular ltsp server address on the network
| |
| 10:57 | <alkisg> Ahmuck: do you mean a customized gpxe cd ?
| |
| 10:58 | <Ahmuck> yes, perhaps. it was a script, which i changed the address to and then booted from the cd
| |
| 11:00 | etyack has joined #ltsp | |
| 11:00 | <alkisg> RIght... well then it's like this: you go to rom-o-matic.net, and you press the [customize] button, and there you put a custom gpxe script, and finally you click on [get image]
| |
| 11:00 | But I don't have that script handy, it would take me maybe 10 minutes to locate it. Could you look at the ltsp logs instead?
| |
| 11:00 | vagrantc has joined #ltsp | |
| 11:01 | <highvoltage> alkisg: did you get your ldm going again?
| |
| 11:01 | <alkisg> highvoltage: no, but it's probably a Lucid (or edubuntu?) problem, as it does that in my normal chroot as well
| |
| 11:02 | I'll have to find a way to see why it segfaults...
| |
| 11:03 | There are "how to get a stack trace" instructions somewhere, I'll find them next time I try it.
| |
| 11:04 | <highvoltage> yeah strace is probably the way to go
| |
| 11:05 | Gadi1 has left #ltsp | |
| 11:06 | <alkisg> Would you guys accept some code to manage tftpboot/pxelinux* automatically?
| |
| 11:07 | I.e. there are different pxelinux.cfg/default files for each arch, maybe we could have a central tftpboot/pxelinux.cfg which would be generated automatically, would present a menu, and would enable the user to select any of them?
| |
| 11:08 | That way if there was only one arch, it would work like it does now. If they were more, we'd get a menu. And of course if someone hand-codec the mac addresses in dhcpd.conf, it would still work as it does now...
| |
| 11:08 | Gadi1 has joined #ltsp | |
| 11:09 | <ogra> why do you need a menu ?
| |
| 11:09 | isnt there a chance to find that data from dhcp replies ?
| |
| 11:10 | <Ahmuck> alkisg: ah, i know, it was the embeded script portion that i did not know how to do
| |
| 11:10 | <alkisg> ogra: OK, lets see some use cases. Why would someone have 2 chroots?
| |
| 11:10 | <ogra> because he has ppc clients
| |
| 11:11 | along with x86 ones
| |
| 11:11 | <alkisg> OK, then he'd have to hard code all mac addresses to dhcpd, right? So he wouldn't be shown a menu
| |
| 11:11 | <vagrantc> someone wants a network booted debian installer and ubuntu installer
| |
| 11:11 | <alkisg> So that doesn't bother him
| |
| 11:11 | <vagrantc> in additionm to LTSP
| |
| 11:11 | <ogra> what scares me in this setup is that you present a blak/white terminal menu to endusers
| |
| 11:11 | <vagrantc> ogra: you can easily set up a graphical menu
| |
| 11:11 | <Ahmuck> why can't you code it to boot by vendor id?
| |
| 11:12 | <alkisg> ogra: it doesn't need to be black white. E.g. in Ubuntu we already have the netboot code we can use
| |
| 11:12 | <ogra> Ahmuck, ++
| |
| 11:12 | <Ahmuck> each mac address has a vendor id and apple computers would have a vendor id wouldn't they?
| |
| 11:12 | <alkisg> It's graphical, it has help screens etc, it's fine
| |
| 11:12 | Ahmuck: I may want to boot a different OS on the *SAME PC* at different times
| |
| 11:12 | <vagrantc> powerpc doesn't use pxelinux at all
| |
| 11:12 | <ogra> alkisg, i admit that i like Ahmuck's idea better
| |
| 11:12 | <alkisg> How could I do that with mac addresses?
| |
| 11:13 | Or verdor IDs?
| |
| 11:13 | <vagrantc> i want to have memtest available everywhere
| |
| 11:13 | network booted
| |
| 11:13 | <ogra> oh, you want to select the chroot
| |
| 11:13 | hersonls has quit IRC | |
| 11:13 | <alkisg> Right
| |
| 11:13 | And I want to have fat clients / thin clients selectable by the user
| |
| 11:13 | Etc etc...
| |
| 11:13 | hersonls has joined #ltsp | |
| 11:13 | <vagrantc> alkisg: what i don't want is to steal a more generic location for the pxe menu ... so if you do code it, please keep it in tftpboot/ltsp/pxelinux*
| |
| 11:14 | <alkisg> I'm willing to give some time to code it as properly as I can, provided there is interest in this...
| |
| 11:14 | <vagrantc> user wants an amd64 node as a computer cluster...
| |
| 11:15 | there's all sorts of crazy ways people *have* used LTSP
| |
| 11:15 | * Gadi1 is fascinated at the sophisticated level of everyone's users | |
| 11:15 | <Gadi1> :)
| |
| 11:15 | <Ahmuck> first six digits in a mac address is the vendor id
| |
| 11:15 | so any thing that matches that vendor id would chroot to ppc
| |
| 11:15 | am i lost yet?
| |
| 11:16 | <vagrantc> Ahmuck: ok, based on that, how will you determine if they want to run a fat client today, or a thin client?
| |
| 11:16 | <ogra> Ahmuck, alkisg means you probably have three ppc chroots :)
| |
| 11:16 | <vagrantc> or memtest, or amd64?
| |
| 11:16 | <ogra> and want to select one of them
| |
| 11:16 | <vagrantc> or debian-installer, or ubuntu-installer...
| |
| 11:16 | <ogra> right
| |
| 11:16 | Faithful has quit IRC | |
| 11:16 | <vagrantc> or (pardon the heresey) some other thin client system
| |
| 11:16 | <alkisg> I also used a menu to enable the users to triple-boot ltsp, local linux, and windows (chain.c32 hd0 1). The *possibility* to have a menu is nice - now we don't have that possibility..
| |
| 11:17 | <Ahmuck> vagrantc: well, that would need a specific mac address i suppose, or use a thumb drive for booting would be a easier idea?
| |
| 11:17 | <vagrantc> Ahmuck: why not a network menu?
| |
| 11:17 | <vmlintu> There's one more use case for pxe menus - when turning old windows boxes to ltsp clients, one often wants to dualboot to windows once in a while..
| |
| 11:17 | <vagrantc> Ahmuck: all of these things can be loaded over the network.
| |
| 11:17 | <Ahmuck> vmlintu: heh, that's me
| |
| 11:17 | <alkisg> vmlintu: right, I just said that use case above :)
| |
| 11:17 | * alkisg has used that in many labs | |
| 11:17 | <Ahmuck> i'm booting to kubuntu on my desktop, but need to boot to ltsp for the lab
| |
| 11:18 | <ogra> the only thing bothering me about PXE menus is the uglyness
| |
| 11:18 | <Ahmuck> two sepearte offices
| |
| 11:18 | <vmlintu> alkisg: sorry, must have missed that earlier
| |
| 11:18 | <Ahmuck> but i'm doing virtalbox machine to do that i suppose
| |
| 11:18 | <vagrantc> ogra: it's no uglier than the ubuntu CD menus...
| |
| 11:18 | <alkisg> Sure - I was just saying that it's not a rare need :D
| |
| 11:18 | <vagrantc> ogra: you could even use the same artwork
| |
| 11:18 | <ogra> vagrantc, they bother me too :)
| |
| 11:18 | <vagrantc> oh
| |
| 11:18 | <ogra> luckily i dont have to see them anymore ...
| |
| 11:18 | <vagrantc> heh
| |
| 11:18 | <ogra> arm doesnt have options :)
| |
| 11:19 | unless you hack into serial
| |
| 11:19 | <vagrantc> freedom is for the weak
| |
| 11:19 | <ogra> yeah !
| |
| 11:19 | well, in my case freedom is for the really advanced ones ...
| |
| 11:19 | <Roel__> !docs
| |
| 11:19 | <ltspbot> Roel__: "docs" :: For the most current documentation, see https://sourceforge.net/apps/mediawiki/ltsp/index.php?title=Ltsp_LtspDocumentationUpstream
| |
| 11:19 | <ogra> knowing how to re-config their bootloaders
| |
| 11:20 | <alkisg> So, I'm thinking that ltsp-update-kernels would internally call ltsp-update-pxelinux, which would construct a tftpboot/ltsp/menu/pxelinux.cfg/default file. Any user that wanted it, could use that file instead of the arch-specific ones.
| |
| 11:20 | <Ahmuck> if it were me, i'd put one of those small usb keys on the back of the machine with coded instructions on how i want that pc to boot. i've been looking at using some type of hardware inventory manager such as ocs inventory to determine if it's a fat client or thin client
| |
| 11:20 | <vagrantc> alkisg: seems reasonable, but how do you determine which chroots are even supportable by pxelinux?
| |
| 11:20 | <Ahmuck> using a hardware inventory, one wouldn't need to code any mac address, but read a text file to determine what pcs are in what section that the hardware inventory client has written them to based on their specifications
| |
| 11:20 | <vmlintu> I'm using my own script to generate the dualboot menus at the moment based on the mac addresses. We combined our image for fat and thin clients, so that doesn't need it anymore..
| |
| 11:21 | <Ahmuck> a exported file of sorts from the hardware inventory client
| |
| 11:21 | cmm1 has joined #ltsp | |
| 11:21 | * vagrantc shudders at the though of needing a usb stick to boot | |
| 11:21 | <alkisg> vagrantc: I'll just gather whatever I find in ltsp/<*>/pxelinux.cfg/default...
| |
| 11:21 | <vagrantc> i'm lucky if there's still a mouse at every machine.
| |
| 11:22 | <Ahmuck> theft?
| |
| 11:22 | <alkisg> Ahmuck: with a menu, I'm able to specify *from the server* what I want the clients to boot. So I don't have to even get up from my chair to turn on all PCs in the morning, and decide that I want to boot them with local linux...
| |
| 11:22 | <vagrantc> Ahmuck: yeah
| |
| 11:22 | Ahmuck: or just stupidity
| |
| 11:22 | <Ahmuck> vagrantc: use usb internally?
| |
| 11:22 | <vagrantc> Ahmuck: i don't see why i'd even bother.
| |
| 11:22 | <Ahmuck> anywho
| |
| 11:22 | <vagrantc> network menu's are *perfect*
| |
| 11:22 | <Ahmuck> i assume your end users know what choice to pick
| |
| 11:23 | <vagrantc> that's what defaults are for.
| |
| 11:23 | <Ahmuck> ah, you defualt to thin client or is the default different based on mac address?
| |
| 11:23 | <vagrantc> 99% defaults, based on mac otherwise
| |
| 11:26 | <johnny> alkisg, that's why i think http booting is awesome
| |
| 11:26 | you could run a webserver to generate whatever you wanted..
| |
| 11:26 | i think..
| |
| 11:26 | plus the lts.conf ish stuff could be generated on the fly
| |
| 11:26 | instead of hardcoded
| |
| 11:27 | http booting would be much better than tftp booting :(
| |
| 11:27 | too bad we can't just force that :(
| |
| 11:27 | <ogra> force, bah
| |
| 11:27 | <vagrantc> yeah.
| |
| 11:27 | <Ahmuck> how does one http boot?
| |
| 11:28 | <ogra> write the core, make it an option !
| |
| 11:28 | *code
| |
| 11:29 | <vagrantc> and make sure it's an obscure and poorly documented option, otherwise it won't be up to my standards :)
| |
| 11:30 | * alkisg was on the phone, sorry, reading up... | |
| 11:32 | <vagrantc> i think i can count the times on two fingers that i've remembered to document a newly introduced lts.conf option
| |
| 11:33 | <knipwim> one?
| |
| 11:33 | ;)
| |
| 11:35 | <alkisg> OK, so, would that menu code be considered for inclusion, if it was up to vagrantc's standards? :D Or would someone oppose to it, so I shouldn't waste any time on it?
| |
| 11:36 | etyack has quit IRC | |
| 11:36 | otavio has quit IRC | |
| 11:37 | <johnny> folks, i'd like knipwim to have commit access to ltsp repo..
| |
| 11:37 | can some admin do that?
| |
| 11:38 | knipwim, i do like to review your code.. but i think you should be able to commit
| |
| 11:38 | loathing has quit IRC | |
| 11:38 | <knipwim> sound fine to me
| |
| 11:39 | <vagrantc> johnny: you don't have admin rights?
| |
| 11:39 | <johnny> i didn't think i would
| |
| 11:39 | <vagrantc> johnny: ah, i suppose it was dberkholz from the gentoo side of things
| |
| 11:39 | <ogra> yup
| |
| 11:39 | <johnny> sure.. but i wrote most of the code
| |
| 11:40 | so.. i think my say should be enough
| |
| 11:40 | <vagrantc> johnny: well, yeah. we should sync the theoretical state with the actual state.
| |
| 11:40 | <johnny> please do
| |
| 11:41 | <Ahmuck> dhcp net0; set filename tftp://ip.of.your.server/filename.img; autoboot ?
| |
| 11:41 | <johnny> vagrantc, when i aquire another computer.. i will be able to actually run gentoo again..
| |
| 11:41 | i'm told i'll get a new one in the next 2 or 3 months..
| |
| 11:42 | <alkisg> highvoltage: (unrelated) could FAT_CLIENT default to "True" for fat client chroots? (determined from some ltsp-config file on the fat chroot or similar). E.g. if the same server serves both a thin and a fat client lab, we'd have to specify all mac addresses in dhcpd.conf for them to get a different chroot - it'd be nice if we didn't have to do that in lts.conf as well...
| |
| 11:42 | <vagrantc> heh. it lists stgraber as "recently approved"
| |
| 11:42 | _gentgeen_ has quit IRC | |
| 11:43 | _gentgeen_ has joined #ltsp | |
| 11:43 | <vagrantc> hrm. i always have to struggle with "yet another website with it's own authentication system"
| |
| 11:44 | <ogra> you dont like openid ?
| |
| 11:48 | <vagrantc> ogra: it supports it finally?
| |
| 11:48 | "since years" i suppose.
| |
| 11:48 | <ogra> i use it since about two years now for nearly all my online accounts, yes
| |
| 11:49 | <vagrantc> use launchpad's openid to connect to other sites, or my own openid to connect to launchpad?
| |
| 11:49 | <ogra> the first
| |
| 11:50 | https://help.launchpad.net/YourAccount/OpenID
| |
| 11:50 | Can I log into Launchpad with my existing OpenID?
| |
| 11:50 | Not at this time. Launchpad is currently an OpenID Provider (OP) and not a consumer (RP).
| |
| 11:50 | FAQ
| |
| 11:51 | <vagrantc> bah. what good is it then :P
| |
| 11:51 | <ogra> pfft
| |
| 11:52 | <vagrantc> well, now i have to maintain an openid site for all the openid sites that don't accept openid?
| |
| 11:52 | that's just plain useless.
| |
| 11:52 | <ogra> just use your LP account as your main account and you are good
| |
| 11:52 | or download the LP code and send patches to change the situation ;)
| |
| 11:52 | <vagrantc> except for all the other sites that behave like launchpad.
| |
| 11:53 | <Roel__> do I need hal to let X find my keyboard and mouse?
| |
| 11:53 | <ogra> yes
| |
| 11:53 | unless you run any development distro with the very latest X
| |
| 11:54 | <Roel__> is there no othe way to define it manually?
| |
| 11:54 | <vagrantc> well, you could run debian stable, which doesn't have support for hal in X :)
| |
| 11:54 | <Roel__> I can't do anything on my client now to see exact problems, but it's not willing to start hald and I can't get out of the gui now
| |
| 11:55 | <ogra> you can override it with a static xorg.conf
| |
| 11:55 | but i'd rather fix the actual problem and make hal run :)
| |
| 11:55 | <Roel__> I don't know all the other options, so that is not really an option for me
| |
| 11:57 | X_MOUSE_DEVICE could this be used for anything, or not really?
| |
| 11:57 | <ogra> it sets a hal property iirc
| |
| 11:57 | unless you use a serial mouse
| |
| 11:57 | then it runs inputattach
| |
| 11:57 | <Roel__> so not really .. its PS2?
| |
| 11:58 | <ogra> fix hal
| |
| 11:58 | <Roel__> I don't know how, I can't get out of LDM without my keyboard
| |
| 11:58 | otavio has joined #ltsp | |
| 11:58 | <ogra> how did you manage to break it ?
| |
| 11:58 | <Roel__> I didn't break it, it didn't start at default, so I added it and I can see it's not starting
| |
| 11:59 | but I understand now why I had to manually add the BUSID to get my screen working
| |
| 11:59 | <ogra> set SCREEN_07=shell in your lts.conf
| |
| 11:59 | then you can start debugging
| |
| 11:59 | <Roel__> aha
| |
| 11:59 | so that cancels all X
| |
| 12:00 | <ogra> check if dbus runs
| |
| 12:00 | <Roel__> let me try that
| |
| 12:00 | <ogra> it boots into shell
| |
| 12:00 | if dbus runs properly, check why hal doesnt start
| |
| 12:00 | <Roel__> dbus is not started
| |
| 12:00 | so that could be the big problem then
| |
| 12:00 | <ogra> what distro is that ? that it doesnt install hal and dbus by default
| |
| 12:00 | <Roel__> Gentoo
| |
| 12:01 | :)
| |
| 12:01 | <ogra> oh, ok
| |
| 12:01 | <Roel__> but I'm getting close to getting it to work
| |
| 12:01 | <ogra> then you asked for issues :P
| |
| 12:01 | <Roel__> but I have no real expierence on X dependencies
| |
| 12:01 | <ogra> well, they change a lot recently
| |
| 12:01 | with the whole input redesign
| |
| 12:01 | <vagrantc> the gentoo port is a work in progress... and right now progress is stalled on getting knipwim commit access?
| |
| 12:01 | <ogra> i guess vagrant is a lucky guy having such a slow release schedule
| |
| 12:02 | <Roel__> it's quite working out of the box... just some manual copied files and you're set
| |
| 12:02 | <ogra> he will just switch from the old to the new
| |
| 12:02 | <vagrantc> it ain't luck, it's choice :)
| |
| 12:02 | <ogra> .... and not understand how it got there :P
| |
| 12:02 | <Roel__> let me check now I added dbus, if those things work
| |
| 12:02 | <vagrantc> :)
| |
| 12:03 | ogra: i hear y'all squabble about the latest things enough to have some idea how it got there.
| |
| 12:03 | <ogra> doesnt getoo have any kind of dependency system ?
| |
| 12:03 | vagrantc, haha
| |
| 12:03 | <vagrantc> ogra: and usually i get to skip 1-2 of them
| |
| 12:03 | * ogra hugs vagrantc | |
| 12:03 | <knipwim> ogra: it does
| |
| 12:04 | i don't need hal or dbus to get X working with input devices
| |
| 12:04 | <ogra> then it should have warned or something, hal cant run without dbus
| |
| 12:04 | the defaults are that way upstream ... so you should have hal
| |
| 12:05 | well, they arent anymore today ... but were until recently
| |
| 12:06 | now you need devicekit/udev/xinput
| |
| 12:06 | <vagrantc> kittyCatKit
| |
| 12:06 | <johnny> ogra, it does warn
| |
| 12:06 | actually.. it should have started it
| |
| 12:06 | if it was installed
| |
| 12:06 | and warn if it isn't
| |
| 12:06 | <Ahmuck> #!gpxe
| |
| 12:06 | dhcp net0
| |
| 12:06 | set filename /ltsp/i386/pxelinux.0
| |
| 12:06 | set next-server <<<your ltsp server external nic ip>>>
| |
| 12:06 | <johnny> the gentoo init is dependency based
| |
| 12:08 | <Roel__> true
| |
| 12:09 | it got started (dbus) but still hal doesn't start which he is already complaining for at boot
| |
| 12:09 | <johnny> find out why
| |
| 12:10 | try starting it from the cli with the same args as the init script
| |
| 12:10 | <Roel__> I' trying , just a sec
| |
| 12:10 | <johnny> or even just look in the logs
| |
| 12:19 | <Roel__> /etc/init.d/hald[3511]: ERROR: hald failed to start <-- that didn't really help
| |
| 12:19 | only thing I can find in the logs
| |
| 12:19 | <johnny> well.. open up the init script
| |
| 12:19 | and try starting it manually
| |
| 12:20 | by using the same args
| |
| 12:20 | i think there's also some --no-daemon option you should try to use
| |
| 12:21 | <Ahmuck> alkisg: i found the logs so to speak, however it appears you droped the info in a pastebin which no longer exists :( did you ever write up a wiki on this?
| |
| 12:22 | <alkisg> Ahmuck: Nope... proxydhcp is usually much better suited for such situations
| |
| 12:23 | What's your network setup? What exactly do you want to do?
| |
| 12:23 | <Ahmuck> router --> serves an dhcp address to me
| |
| 12:23 | router --> servers a dhcp address to ltsp server
| |
| 12:23 | <alkisg> And the ltsp server has only 1 nic?
| |
| 12:23 | <Ahmuck> ltsp server (2nd nic) serves dhcp address to thin clients
| |
| 12:23 | ltsp server is at a fixed address
| |
| 12:24 | <alkisg> And your client is on the internet-facing NIC of the ltsp server?
| |
| 12:24 | <Ahmuck> my computer runs kubuntu and i have a vbox guest
| |
| 12:24 | so, vbox guest --> router --> ltsp server
| |
| 12:25 | <alkisg> Right... yeah, proxydhcp is fine for that as well.
| |
| 12:25 | <Ahmuck> where the router is on the same subnet
| |
| 12:25 | <alkisg> dnsmasq could serve both your ltsp clients, as a normal dhcp server, and your vbox client, as a proxydhcp server
| |
| 12:25 | <Ahmuck> ltsp server --> switch --> dhcp clients
| |
| 12:25 | <vagrantc> though you'll want to make sure the ltsp server always gets the same ip address from the router
| |
| 12:25 | <alkisg> vagrantc: it has static IP...
| |
| 12:26 | (08:24:57 μμ) Ahmuck: ltsp server is at a fixed address
| |
| 12:26 | <Ahmuck> ah, sorry, the ltsp server ip address is hard set
| |
| 12:26 | <vagrantc> but it has two NICs?
| |
| 12:26 | <Ahmuck> yes
| |
| 12:26 | one in from router for inet access, and one out to switch then to clients
| |
| 12:26 | <vagrantc> both static? plugged into different physical networks?
| |
| 12:26 | <Ahmuck> yes
| |
| 12:27 | server in is 192.168.10.x
| |
| 12:27 | <vagrantc> proxydhcp is the way to go, like alkisg says :)
| |
| 12:27 | <Ahmuck> server out is 192.168.0.x
| |
| 12:27 | before i had a bridge router, and connected to the ltsp server wireless through the bridged router
| |
| 12:28 | me --> wireless bridged router --> base router --> ltsp server (nic1)
| |
| 12:28 | where i was booting from an iso
| |
| 12:28 | via cdrom
| |
| 12:29 | <vagrantc> and this is just to test that it works?
| |
| 12:29 | <Roel__> johnny .. any other idea?
| |
| 12:29 | <Appiah> hmm, I'm setting here trying to setup SPICE meanwhile someone drops a mail to ltsp-discuss asking stuff about SPICE
| |
| 12:30 | <highvoltage> alkisg: you could just put it under [default] and it would apply to all the thin clients
| |
| 12:30 | <Ahmuck> vagrantc: nope, i'd like to connect via a vm to the ltsp server so i don't have to run down the hall
| |
| 12:30 | <vagrantc> Ahmuck: fair enough
| |
| 12:31 | <alkisg> highvoltage: is there some use case where someone would create a fat client chroot, and then *not* want to use it on fat clients?
| |
| 12:31 | <highvoltage> alkisg: yep,
| |
| 12:31 | alkisg: Sandy has 8 new Core 2 Duo machines that she boots from the network with her 20 other Celeron 400mhz machines with 128MB RAM....
| |
| 12:32 | alkisg: if the rest isn't obvious I'll type it out :)
| |
| 12:32 | <alkisg> highvoltage: and wouldn't Sandy use 2 different chroots?
| |
| 12:32 | But I'm optimizing for this case, as my 64Mb clients won't boot with a fat client chroot :)
| |
| 12:32 | *because
| |
| 12:32 | <highvoltage> why would she? she could use the one chroot for all of her machines and just specify the machines that she'd like to use as fat clients
| |
| 12:33 | alkisg: ah
| |
| 12:33 | <alkisg> highvoltage: I imagine that a fat client chroot won't work with 64 Mb clients, as a thin client chroot does, because of the additional services...
| |
| 12:33 | <highvoltage> (I'm glad I upped the RAM a bit in my example)
| |
| 12:33 | <alkisg> Heh
| |
| 12:34 | I was actually thinking Sandy all this time, as it's my usual use case here in Greece :D
| |
| 12:34 | <highvoltage> alkisg: I wonder if there's more junk that starts up or if loading the filesystem metadata for a larger chroot is causing the problem
| |
| 12:35 | my psychic abilities is quite sharp tonight, I just watched a music program on tv and I knew some answers before the song even played :)
| |
| 12:35 | <alkisg> Haha
| |
| 12:35 | <highvoltage> (not that I really believe in that stuff)
| |
| 12:36 | <alkisg> highvoltage: if someone's going for fat clients, he'll add much more stuff in the chroot that the default install. I really don't believe he'll be able to boot (really) thin clients with that, he'll have to go for double chroot... so it'd be better if it worked without an lts.conf in that case (2 chroots).
| |
| 12:36 | <Ahmuck> vagrantc: so the idea is ... virtualbox vm (thin client) using host nic via bridged nic booting from cdrom --> router --> ltsp server (nic1)
| |
| 12:36 | anywho, /me must feed cattle again in this very cold day
| |
| 12:36 | <highvoltage> alkisg: why wouldn't the bigger chroot work?
| |
| 12:37 | <alkisg> highvoltage: Sandy on the other hand will have to specify FAT_CLIENT=True on a *per mac address basis* in lts.conf. So it wouldn't matter to (him? her?) whether the default is true or false.
| |
| 12:37 | Roel_ has joined #ltsp | |
| 12:37 | <alkisg> So I don't see any benefit for Sandy, while I see a benefit for the dual chroot usage...
| |
| 12:37 | <highvoltage> alkisg: why would she need to do that?
| |
| 12:38 | <johnny> Roel_i just told you
| |
| 12:38 | try starting it manually based on the args in the init script
| |
| 12:38 | <alkisg> How else would she tell the system that she needs 8 of the clients to be fat and 20 of them to be thin?
| |
| 12:38 | <highvoltage> if most of her clients are fat she can put it in default and put the thin clients' mac addresses in
| |
| 12:38 | <alkisg> Right, so 20 thin clients mac addresses
| |
| 12:38 | <highvoltage> ah yes, well for that she'd need to feed in the 8 mac addresses yes
| |
| 12:39 | so how would 2 chroots solve that?
| |
| 12:39 | <alkisg> And, putting an extra "FAT_CLIENT=True/False" on the default section wouldn't make much of a difference for her
| |
| 12:39 | <highvoltage> you'd still need to specify them to mac addresses somehow
| |
| 12:39 | <alkisg> Right. Let's take this step by step.
| |
| 12:39 | So, for Sandy there's no real benefit.
| |
| 12:39 | <johnny> Roel_i don't have a gentoo system.. so i can't offer much more than "try this, then try that"
| |
| 12:40 | <alkisg> highvoltage: Now, for the dual chroots: we have to declare the mac addresses in dhcpd.conf (or in pxelinux.cfg), no way around that
| |
| 12:40 | The benefit is that we don't need an lts.conf in that case.
| |
| 12:40 | <highvoltage> alkisg: I think it would be nicer if there was something in lts.conf that said that if a machine's memory is less than 500MB, make it a thin client, if it's more, make it a fat client
| |
| 12:41 | <vagrantc> alkisg: i'd like to code up some sort of test mechanism in lts.conf ...
| |
| 12:41 | Roel__ has quit IRC | |
| 12:41 | <alkisg> highvoltage: ok, that would solve my problem, and is easily programmable. But I'd still use two chroots, as I don't think that the fat chroot would boot with 64 ram.
| |
| 12:42 | <vagrantc> alkisg: i.e. LTSP_FATCLIENT= /path/to/something/that/outputs/value
| |
| 12:42 | <highvoltage> alkisg: how so? I've asked you before... does a bigger filesystem scale directly to more memory usage?
| |
| 12:42 | <alkisg> highvoltage: it's not the size I'm worried about, it's the additional services.
| |
| 12:43 | E.g. if you install devscripts or something like that on the chroot, they depend on postfix. That would need ram
| |
| 12:43 | <highvoltage> alkisg: imho those extra services that start when FAT_CLIENT=false is specified that starts should probably be filed as a bug against ltsp
| |
| 12:44 | <vagrantc> highvoltage: no, it would have to be filed as a bug in each package that implements init/upstart scripts.
| |
| 12:44 | distro-wide.
| |
| 12:44 | not gonna happen.
| |
| 12:44 | <highvoltage> good point, it could be improved on quite a lot though
| |
| 12:45 | <alkisg> highvoltage: ok, extreme case: Sandy has a lab of fat clients, where she wants to run apache on each of them, for some class. And 10 other thin clients. How would you tell apache not to start on the thin clients?
| |
| 12:45 | <vagrantc> debian-edu does it by setting up different services in different runlevels ... a little awkward, but it works.
| |
| 12:45 | <highvoltage> I always wondered why LTSP didn't ever use a custom run-level for booting from the ch....
| |
| 12:45 | <vagrantc> that's how i used to do it for lessdisks, for that matter...
| |
| 12:45 | <highvoltage> vagrantc: ok I didn't realise anyone actually does that :)
| |
| 12:45 | <vagrantc> runlevels are so last millenia
| |
| 12:46 | <highvoltage> yeah
| |
| 12:47 | <vagrantc> what we really need is eventDrivenFatClientKit
| |
| 12:47 | <alkisg> Another scenario: a lab of nvidia fat clients, and another lab of ati fat clients. Two chroots are a fine way to get speed on those. Why should I need to specify FAT_CLIENT=True on those, as I specifically created fat client chroots?
| |
| 12:48 | johnny has left #ltsp | |
| 12:48 | johnny has joined #ltsp | |
| 12:50 | <alkisg> I think multiple chroots are going to be used more and more in the future, so it'd be nice if we made them easy to use.
| |
| 12:51 | <highvoltage> vagrantc: well all major distributions are starting to (or have already) adopt event-based booting systems, so it should get much more better over the next few years right?
| |
| 12:53 | <vagrantc> highvoltage: you have a "oh, this isn't a very powerful computer" event?
| |
| 12:54 | <alkisg> (and even if that was possible, how would Sandy specify that she does want the ssh service on the not powerful pcs, but she doesn't want the apache service?)
| |
| 12:54 | <highvoltage> vagrantc: no but once you've defined what a "not so powerful computer" is it's not hard to do
| |
| 12:55 | <vagrantc> though you'd still have the same problem- having all the various event-driven scripts run or not based on capabilities of the hardware
| |
| 12:57 | <highvoltage> I guess I'd just do a grep MemTotal /proc/meminfo | awk blah blah blah and then export FAT_CLIENT=false and if it is I'd run some teardown script or something that would disable all scripts that aren't required to get the system up
| |
| 12:57 | s/scripts/events/
| |
| 12:58 | <johnny> well.. it would be nice if you could set a group in lts.conf.. and then set that group to run
| |
| 12:58 | instead of replicating the settings
| |
| 12:58 | <alkisg> I think service selection is something that has to be decided by the user. So I think that in that case, the user should be able to specify in lts.conf which services he wants based on the capabilities of the hardware.
| |
| 12:59 | <johnny> perhaps ldminfod should be talked to earlier.. and do more
| |
| 13:00 | <alkisg> The client could send all its data to ldminfod (ram, cpu, etc) and ldminfod could reply with a dynamically generated lts.conf...
| |
| 13:01 | * vagrantc would like to note that that has nothing to do with ldm | |
| 13:02 | <vagrantc> ldminfod is also one-way communication for security reasons ... not having to parse anything saves a whole lot of trouble.
| |
| 13:03 | * alkisg sees both lts.conf and ldminfod as a conversation that results in some settings... | |
| 13:05 | <vagrantc> sure
| |
| 13:05 | but to write a secure piece of code that takes arguments, input, whatever, is much harder than to write code that simply outputs data like ldminfod does.
| |
| 13:06 | <alkisg> Why would it need to be secure?
| |
| 13:06 | (I mean, more secure than the lts.conf transfer is, now)
| |
| 13:06 | <vagrantc> both of those are downloading a single thing from the server... but if you were passing arguments to scripts run on the server itself, you could remotely root the server.
| |
| 13:07 | <alkisg> That's true for any web page
| |
| 13:07 | <vagrantc> sure, but we're not writing web server software, or even tftp software. we're simply using it.
| |
| 13:08 | <alkisg> Doesn't cluster-ltsp contain php code?
| |
| 13:08 | <vagrantc> maybe so.
| |
| 13:08 | but i don't think that code is integrated into ltsp ...
| |
| 13:10 | <alkisg> I don't think that sanitizing a web form input is something so scary that would prevent it from being used...
| |
| 13:11 | * vagrantc *really* hopes we don't start integrating PHP apps into ltsp. | |
| 13:11 | <Appiah> php apps?
| |
| 13:12 | <alkisg> How about python? :P :D
| |
| 13:12 | highvolt1ge has joined #ltsp | |
| 13:12 | <vagrantc> alkisg: why do it server side?
| |
| 13:12 | <alkisg> vagrantc: for the same reason ldminfod runs server side. More data to decide there.
| |
| 13:13 | I could decide based on client mac address, on server load, on client RAM, etc etc.
| |
| 13:13 | <vagrantc> other than server load, i don't see anything you couldn't specify client-side in that case.
| |
| 13:14 | <alkisg> On the server, I have access to dhcpd.conf. So I can save myself from "repeating" some mac-address-specific info.
| |
| 13:15 | The client could request that he wants a Greek interface, I could direct him to a server with Greek installed.
| |
| 13:15 | (that from the ldm gui)
| |
| 13:15 | The client could request a specific app.. etc etc
| |
| 13:15 | <vagrantc> alkisg: you could also say duplicating the mac address from lts.conf in dhcpd.conf isn't necessary.
| |
| 13:16 | <alkisg> vagrantc: but it is, how else am I going to boot different architectures?
| |
| 13:16 | <vagrantc> fair enough :)
| |
| 13:16 | i'm not saying there's no use for server-side stuff, but most of it could easily be done client-side.
| |
| 13:17 | <alkisg> So such a service would "substitute" ldminfod, lts.conf, and the ltsp-cluster php scripts...
| |
| 13:17 | I think that'd make it both more powerful and simpler (just talking, I don't plan on implementing any of these... :D)
| |
| 13:17 | tstafford has quit IRC | |
| 13:19 | <vagrantc> alkisg: which is why i'd like to be able to specify scripts to run from lts.conf ... you could have a one-liner lts.conf that queries the server in the way you want...
| |
| 13:19 | <Ahmuck-Jr> quote - "I typically don’t do thin client because of “in-country” support."
| |
| 13:20 | folks, these are people who could benefit from thin clients but won't use it because of the above reason.
| |
| 13:20 | <vagrantc> Ahmuck-Jr: what's the reason?
| |
| 13:20 | <alkisg> vagrantc: OK, but that would require updating the chroot for every little change in scripts, and also maybe the server daemons... why not standarize it with a well-known http-based framework?
| |
| 13:20 | <vagrantc> alkisg: tradition!
| |
| 13:21 | <alkisg> Isn't https traditional enough? :D
| |
| 13:21 | <Appiah> what does "in-country" mean?
| |
| 13:21 | * vagrantc isn't so afraid of updating the chroot | |
| 13:21 | <vagrantc> Appiah: locally available tech support?
| |
| 13:21 | <Appiah> oh
| |
| 13:21 | <vagrantc> that's just a guess
| |
| 13:21 | <Appiah> maybe they should look for a better IT-Partner/Support
| |
| 13:21 | plenty of companies out there
| |
| 13:21 | <Ahmuck-Jr> vagrantc: “in-country” support.
| |
| 13:22 | African school districts
| |
| 13:22 | <Appiah> and if there isnt , there's a oppertunity to start a busniess
| |
| 13:22 | :)
| |
| 13:22 | <Ahmuck-Jr> it's about training. some of these school districts are lucky to have nurses, let alone doctors
| |
| 13:23 | <Appiah> then I belive a terminal solution in a classroom is less of an priority
| |
| 13:23 | <Ahmuck-Jr> if the support isn't there, the configuration/support a high learning curve, and training not available, it's not going to fly
| |
| 13:23 | were shipping windows xp pcs
| |
| 13:24 | <vagrantc> alkisg: could fairly easily do what you want now by having the server generate an lts.conf that the client writes to /etc/lts.conf
| |
| 13:24 | highvoltage has quit IRC | |
| 13:24 | <alkisg> vagrantc: ok, but wouldn't you also send some client data to the server for it to generate an lts.conf?
| |
| 13:25 | <vagrantc> alkisg: that's one option, yes :)
| |
| 13:25 | <alkisg> (which wouldn't be an lts.conf anymore - just a VARIABLE=value set of lines, easier to parse...)
| |
| 13:25 | <vagrantc> alkisg: what i'm trying to define is an approach that could integrate into existing infrastructure while being nearly infinitely flexible.
| |
| 13:25 | <alkisg> vagrantc: so, you're not opposed to the idea - just the web-based implementation?
| |
| 13:26 | <vagrantc> alkisg: i see use-cases, sure.
| |
| 13:26 | <alkisg> I'd like either ssh-based or https-based "conversation", for safety reasons...
| |
| 13:26 | (and for easier ltsp-over-the-wan, if the speed is sufficient...)
| |
| 13:31 | <johnny> https is nice
| |
| 13:33 | gfarras has quit IRC | |
| 13:35 | tstafford has joined #ltsp | |
| 13:36 | <alkisg> wget supports https... would it work if one puts it in an initramfs?
| |
| 13:36 | <vagrantc> setting up certificates is a bit messier for https than for ssh
| |
| 13:36 | <johnny> why wouldn't it?
| |
| 13:36 | vagrantc, perhaps for you.. :)
| |
| 13:36 | <alkisg> So even lts.conf with all the autologin passwords etc could be transferred securely...
| |
| 13:36 | cliebow has joined #ltsp | |
| 13:37 | <vagrantc> generating a certificate is simple. registering that as a CA from an initramfs is another story.
| |
| 13:37 | <johnny> vagrantc, ... we still have no proof the tftp server is who it says it is
| |
| 13:37 | same with https.. but at least we'd know the contents were secure
| |
| 13:37 | <vagrantc> johnny: sure. but there's no illusion that it's secure either
| |
| 13:38 | <johnny> yes.. the contents are secure
| |
| 13:38 | they may not be right.. but they are secure
| |
| 13:38 | <vagrantc> the contents aren't secure if it's triviall spoofable
| |
| 13:38 | the contents sent from an unknown server that appears to be the correct server?
| |
| 13:38 | <alkisg> At least other people in the network won't be able to "listen" to the transferred data, to see the passwords...
| |
| 13:39 | <vagrantc> but they can
| |
| 13:39 | it just raises the bar
| |
| 13:39 | <alkisg> I mean without spoofing
| |
| 13:39 | <johnny> only if they connect to another server instaed of the server..
| |
| 13:39 | actual server
| |
| 13:39 | vagrantc, but it could happen at the initramfs level too.. by providing a fake one
| |
| 13:39 | <vagrantc> sure
| |
| 13:39 | <johnny> with a cert that points to a diferent server..
| |
| 13:39 | <vagrantc> but there's no illusion that that's secure
| |
| 13:39 | <alkisg> vagrantc: heh, you contradict yourself, last year you told me that "some security is better than no security" :P :D
| |
| 13:39 | <johnny> so.. what's the diff :)
| |
| 13:40 | <vagrantc> alkisg: of course i contract myself. i am always consistant.
| |
| 13:40 | contradict.
| |
| 13:40 | <johnny> it would still be better than nothing
| |
| 13:40 | <alkisg> :)
| |
| 13:40 | <johnny> and the important thing about the http transfer is that the server can generate an lts.conf dynamically
| |
| 13:40 | not whether it's https .. i could personally care less about that
| |
| 13:40 | <vagrantc> i wouldn't get lost in https vs. http ...
| |
| 13:41 | shawnp0wers has quit IRC | |
| 13:41 | <johnny> i would put the ssh key in the chroot, just like i do now
| |
| 13:41 | i just want lts.conf to be generated dynamically
| |
| 13:41 | alkisg, you could put together an http server that did that very simply..
| |
| 13:42 | <alkisg> johnny: it's a one-liner in python
| |
| 13:42 | SimpleHttpServer :D
| |
| 13:42 | <johnny> the server yes, but making it actually do what you want.. no
| |
| 13:42 | <alkisg> Yup, sure
| |
| 13:42 | <johnny> alkisg, probably would be good to make easyltsp talk to it
| |
| 13:42 | if they have an lts.conf generator
| |
| 13:42 | <alkisg> I'd also put the logic for getltscfg on the server instead of on the client
| |
| 13:43 | <johnny> yes
| |
| 13:43 | cliebow has quit IRC | |
| 13:43 | <johnny> a little sqlite db with all the configs stored..
| |
| 13:43 | indexed by mac address
| |
| 13:43 | that'd be fun
| |
| 13:43 | of course you could store it in ldap too
| |
| 13:43 | <alkisg> I don't care about the storage, I don't have thousands of clients... simple txt or xml files would do for me :D
| |
| 13:44 | The same lts.conf could also be used, maybe with an additional "run this script and get the value" semantic
| |
| 13:53 | hersonls has quit IRC | |
| 14:00 | gfarras has joined #ltsp | |
| 14:08 | hersonls has joined #ltsp | |
| 14:12 | <Ahmuck-Jr> how often does spoofing of a ltsp server happen?
| |
| 14:15 | alkisg has quit IRC | |
| 14:16 | etyack has joined #ltsp | |
| 14:17 | alkisg has joined #ltsp | |
| 14:23 | Roel__ has joined #ltsp | |
| 14:24 | Gadi1 has left #ltsp | |
| 14:26 | hersonls has quit IRC | |
| 14:28 | scottmaccal has quit IRC | |
| 14:29 | hersonls has joined #ltsp | |
| 14:33 | etyack has left #ltsp | |
| 14:36 | etyack has joined #ltsp | |
| 14:41 | Roel_ has quit IRC | |
| 14:46 | highvolt1ge is now known as highvoltage | |
| 14:54 | hersonls has quit IRC | |
| 14:54 | klausade has joined #ltsp | |
| 15:02 | etyack is now known as YodaNot | |
| 15:11 | gfarras has quit IRC | |
| 15:12 | gfarras has joined #ltsp | |
| 15:21 | Gadi has left #ltsp | |
| 15:39 | <stgraber> sbalneav: ping
| |
| 15:43 | MagicFab has joined #ltsp | |
| 15:44 | <MagicFab> Hi all - I need to setup remote access to an LTSP server. When setting up PasswordAuthentication=no, it breaks the thinclients auth. What's best practice to have secure remote access to such a server ?
| |
| 15:51 | <alkisg> One way could be to restrict PasswordAuthentication=yes to your local users only, with an ip-based match directive in sshd_config... but lets hear what others have to say :)
| |
| 15:54 | <MagicFab> alkisg, tx. I hear I can also run two sshd instances and bind them to specific NICs, with different configs.
| |
| 16:03 | <stgraber> MagicFab: network range is probably the easiest
| |
| 16:03 | PasswordAuthentication no
| |
| 16:03 | Match Address 10.* PasswordAuthentication yes
| |
| 16:03 | Match Address 172.31.* PasswordAuthentication yes
| |
| 16:03 | * stgraber hates irssi ... | |
| 16:04 | <Appiah> dont be a hater :)
| |
| 16:04 | <stgraber> here you go: http://pastebin.com/m1a9a9842
| |
| 16:04 | Appiah: it always drop the end of line when I copy/paste ...
| |
| 16:05 | <MagicFab> stgraber, thanks. I guess that's when you start reading about LDAP ? :)
| |
| 16:05 | (or rather, me)
| |
| 16:18 | YodaNot has quit IRC | |
| 16:25 | <highvoltage> stgraber: I don't think I ever heard you say you hate something before!
| |
| 16:25 | stgraber: must be really bad than :)
| |
| 16:41 | bobby_C has joined #ltsp | |
| 16:45 | bobby_C has quit IRC | |
| 17:02 | mgariepy has quit IRC | |
| 17:13 | japerry has joined #ltsp | |
| 17:24 | otavio has quit IRC | |
| 17:46 | alkisg has quit IRC | |
| 17:51 | Faithful has joined #ltsp | |
| 17:52 | <johnny> the other idea is just AllowUsers
| |
| 17:52 | MagicFab, you can distribute ssh keys to your thin client users..
| |
| 18:28 | cmm1 has quit IRC | |
| 18:45 | Selveste1_ has joined #ltsp | |
| 19:14 | vagrantc has quit IRC | |
| 19:14 | Ahmuck has quit IRC | |
| 19:17 | Ahmuck has joined #ltsp | |
| 19:40 | gfarras has quit IRC | |
| 19:48 | ogra has quit IRC | |
| 19:49 | ogra has joined #ltsp | |
| 19:50 | gfarras has joined #ltsp | |
| 19:55 | alexqwesa has quit IRC | |
| 20:10 | alexqwesa has joined #ltsp | |
| 20:36 | _gentgeen_ has quit IRC | |
| 20:38 | _gentgeen_ has joined #ltsp | |
| 20:40 | <sbalneav> Evening all
| |
| 20:40 | stgraber: Heya
| |
| 20:46 | etyack has joined #ltsp | |
| 20:47 | etyack has left #ltsp | |
| 21:12 | _gentgeen_ has quit IRC | |
| 21:42 | sbalneav has quit IRC | |
| 23:04 | shawnp0wers has joined #ltsp | |
| 23:17 | Egyptian[Home] has left #ltsp | |
| 23:26 | shawnp0wers has quit IRC | |
| 23:33 | GGD has quit IRC | |
| 23:39 | gfarras has quit IRC | |
| 23:40 | gfarras has joined #ltsp | |
| 23:58 | intelliant_ has joined #ltsp | |