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


Channel log from 8 January 2010   (all times are UTC)

00:09alkisg 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:21MaRX-Mode has quit IRC
00:21MaRX-Mode has joined #ltsp
00:47gfarras has joined #ltsp
00:52alkisg has quit IRC
01:06GGD has joined #ltsp
01:09Kicer86 has joined #ltsp
01:16shawnp0wers has joined #ltsp
01:20F-GT has quit IRC
01:21F-GT has joined #ltsp
01:23GGD_ has quit IRC
01:28shawnp0wers has quit IRC
01:43alkisg_ has joined #ltsp
01:52alkisg_ has left #ltsp
02:06alkisg_ has joined #ltsp
02:07Appiah has quit IRC
02:17Gadi has quit IRC
02:18Gadi has joined #ltsp
02:25Appiah has joined #ltsp
02:32alkisg_ has quit IRC
02:35F-GT has quit IRC
02:36alkisg has joined #ltsp
02:38* alkisg tries the fat client plugin for the 3rd time... :(
02:49F-GT has joined #ltsp
02:54elias_a has joined #ltsp
03:11alkisg has quit IRC
03:16alkisg has joined #ltsp
03:23vagrantc has quit IRC
03:28Kicer86 has quit IRC
03:29Selveste1 has quit IRC
03:35Faithful has quit IRC
03:35Faithful has joined #ltsp
04:03Roel_ has joined #ltsp
04:14hersonls has quit IRC
04:37alkisg has quit IRC
04:44alkisg has joined #ltsp
04:45Selveste1 has joined #ltsp
04:46alkisg has joined #ltsp
04:58alkisg has quit IRC
05:01alkisg has joined #ltsp
05:11markit 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:29hersonls 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:48tarzeau 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:53alkisg has quit IRC
05:55alkisg has joined #ltsp
06:07Selveste1 has quit IRC
06:25hersonls has quit IRC
06:39scottmaccal has joined #ltsp
06:41
<scottmaccal>
Morning all.
06:42Faithful has quit IRC
06:43hersonls has joined #ltsp
06:43Faithful 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:49sene has quit IRC
06:53Selveste1 has joined #ltsp
06:54Faithful has quit IRC
06:56Faithful has joined #ltsp
06:57klausade 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:02hersonls has quit IRC
07:02hersonls has joined #ltsp
07:12Selveste1 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:16Selveste1 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:29sene has joined #ltsp
07:32
<markit>
alkisg: thanks, I have to improve my skill in retriving info from internet :(
07:32shawnp0wers 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:51Faithful has quit IRC
07:52
<alkisg>
:( it downloads them all even though most of them are already install, this will take some time.... :-/
07:52Faithful has joined #ltsp
07:55panthera has quit IRC
07:55panthera has joined #ltsp
07:55panthera has quit IRC
07:57dro has joined #ltsp
07:58panthera has joined #ltsp
08:04Selveste1_ has joined #ltsp
08:06Selveste1 has quit IRC
08:12johnny has left #ltsp
08:24dro_ has joined #ltsp
08:24dro has quit IRC
08:25hersonls has quit IRC
08:28hersonls has joined #ltsp
08:31dro_ has quit IRC
08:32mgariepy has joined #ltsp
08:33
<mgariepy>
good morning all
08:35dro 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:50dro_ has joined #ltsp
08:50dro has quit IRC
08:51markit has quit IRC
08:51dro_ has quit IRC
09:02Gadi1 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:04Q-FUNK has joined #ltsp
09:04
<Q-FUNK>
ahoy
09:05
stgraber: still alive? :)
09:05hersonls 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:08gfarras has quit IRC
09:11gfarras 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:22hersonls 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:47Roel__ has joined #ltsp
09:47
<Roel__>
that means I shouldn't be loading sisfb?
09:47johnny has joined #ltsp
09:48
<Gadi1>
huh?
09:48gfarras 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:50Gadi1 has left #ltsp
09:51
<Roel__>
yes the sisfb driver is it possible it's already included in the kernel
09:51Ahmuck has quit IRC
09:52
<Roel__>
I have compiled it in the kernel... or is sisfb a specific one for xorg?
09:52alkisg has quit IRC
09:52Gadi1 has joined #ltsp
09:53Ahmuck has joined #ltsp
09:54Faithful has quit IRC
09:54alkisg has joined #ltsp
09:55Faithful has joined #ltsp
10:00Roel_ has quit IRC
10:03
<Roel__>
c
10:06gfarras has joined #ltsp
10:10staffencasa has joined #ltsp
10:12Selveste1_ has quit IRC
10:12grey-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:13Selveste1_ 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:17Q-FUNK has quit IRC
10:18alkisg 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:20alkisg has joined #ltsp
10:20
<Roel__>
could that be possible, I remeber my old 4.2 working
10:20johnny has left #ltsp
10:21johnny 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:41Selveste1_ has quit IRC
10:46gfarras has quit IRC
10:48gfarras 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:00etyack 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:00vagrantc 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:05Gadi1 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:08Gadi1 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:13hersonls 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:13hersonls 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:16Faithful 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:21cmm1 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:36etyack has quit IRC
11:36otavio 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:38loathing 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:58otavio 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:37Roel_ 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:41Roel__ 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:48johnny has left #ltsp
12:48johnny 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:12highvolt1ge 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:17tstafford 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:24highvoltage 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:33gfarras has quit IRC
13:35tstafford 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:36cliebow 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:41shawnp0wers 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:43cliebow 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:53hersonls has quit IRC
14:00gfarras has joined #ltsp
14:08hersonls has joined #ltsp
14:12
<Ahmuck-Jr>
how often does spoofing of a ltsp server happen?
14:15alkisg has quit IRC
14:16etyack has joined #ltsp
14:17alkisg has joined #ltsp
14:23Roel__ has joined #ltsp
14:24Gadi1 has left #ltsp
14:26hersonls has quit IRC
14:28scottmaccal has quit IRC
14:29hersonls has joined #ltsp
14:33etyack has left #ltsp
14:36etyack has joined #ltsp
14:41Roel_ has quit IRC
14:46highvolt1ge is now known as highvoltage
14:54hersonls has quit IRC
14:54klausade has joined #ltsp
15:02etyack is now known as YodaNot
15:11gfarras has quit IRC
15:12gfarras has joined #ltsp
15:21Gadi has left #ltsp
15:39
<stgraber>
sbalneav: ping
15:43MagicFab 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:18YodaNot 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:41bobby_C has joined #ltsp
16:45bobby_C has quit IRC
17:02mgariepy has quit IRC
17:13japerry has joined #ltsp
17:24otavio has quit IRC
17:46alkisg has quit IRC
17:51Faithful 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:28cmm1 has quit IRC
18:45Selveste1_ has joined #ltsp
19:14vagrantc has quit IRC
19:14Ahmuck has quit IRC
19:17Ahmuck has joined #ltsp
19:40gfarras has quit IRC
19:48ogra has quit IRC
19:49ogra has joined #ltsp
19:50gfarras has joined #ltsp
19:55alexqwesa has quit IRC
20:10alexqwesa 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:46etyack has joined #ltsp
20:47etyack has left #ltsp
21:12_gentgeen_ has quit IRC
21:42sbalneav has quit IRC
23:04shawnp0wers has joined #ltsp
23:17Egyptian[Home] has left #ltsp
23:26shawnp0wers has quit IRC
23:33GGD has quit IRC
23:39gfarras has quit IRC
23:40gfarras has joined #ltsp
23:58intelliant_ has joined #ltsp