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


Channel log from 18 March 2009   (all times are UTC)

00:02Faithful has quit IRC
00:04Faithful has joined #ltsp
01:01cyberorg has quit IRC
01:01cyberorg has joined #ltsp
01:09pembo13 has joined #ltsp
01:10
<pembo13>
I tried out K12Linux, worked very well
01:10
i ran into the multi network card issue however
01:10
ie. connecting to a secondary NIC and having the initrd later fail
01:11
in some cases I simply couldn't PXE at all, in other cases initrd would fail
01:11
is the solution to just use the primary card?
01:16alkisg has quit IRC
01:30Faithful has quit IRC
01:43alkisg has joined #ltsp
01:51shrek_ has joined #ltsp
02:09shrek has quit IRC
02:21pembo13 has quit IRC
02:31shrek has joined #ltsp
02:36Faithful has joined #ltsp
02:39alkisg has quit IRC
03:16tjikkun_work has joined #ltsp
03:27ScorpKing has joined #ltsp
03:30craver has joined #ltsp
03:34try2free has quit IRC
03:34nicros_ has quit IRC
03:55dirigeant has joined #ltsp
04:05shrek_ has joined #ltsp
04:06shrek_ has quit IRC
04:21bobby_C has joined #ltsp
04:23shrek has quit IRC
04:24gfarbal2 has joined #ltsp
04:25ScorpKing has left #ltsp
04:33bobby_C has quit IRC
04:42gfarbal2 has left #ltsp
04:43alkisg has joined #ltsp
04:49bobby_C has joined #ltsp
05:05alkisg has quit IRC
05:31shrek has joined #ltsp
05:51EXP__ has joined #ltsp
05:51
<EXP__>
has anyone tried to play dvd on client
05:52
i can getit work, but I can play obly single files. Menu does not work
06:01greenmang0 has joined #ltsp
06:01
<greenmang0>
cyberorg:
06:03EXP__ has quit IRC
06:03
<greenmang0>
what is the maximum number of client supported by LTSP?
06:03
<ogra>
there is none
06:04
though there is a limit of sessions you can run per amount of ram on a server
06:04
<greenmang0>
ogra: can I know what's that limit?
06:05
<ogra>
for a gnome or KDE session you can count 128M x running sessions plus about 256M to have the server itself running
06:05
<greenmang0>
basically i want to decide the configuration of ltsp server
06:05
<ogra>
i.e. 10 sessions would mean 1280M+256M
06:06
<greenmang0>
ogra: what about openbox ? :D
06:06
<ogra>
if you pick smaller desktops you indeed get a smaller footprint ...
06:06
no idea, i havent measured how much a single session eats ... install htop and run a single session ;)
06:07
<greenmang0>
ogra: ok
06:07
<ogra>
and sum up how the ram used for processes the user claims, that should get you an idea
06:18pmatulis has joined #ltsp
06:30dipeshmehta has joined #ltsp
06:31
<dipeshmehta>
hello all, at my PXE client, I am able to LDM login screen, when I issue username/passwd, it gets authenticated (I checked the auth.log) but then the login screen re-appears... there is error message like "unable to start X session --- no "/home/user1/.xsession"" in user's home folder, can any body help me please?
06:32
<ogra>
do you have a desktop installed ?
06:37dirigeant has quit IRC
06:40
<dipeshmehta>
orga:I am installing LTSP on 8.04 server, followed https://help.ubuntu.com/community/ThinClientHowto
06:40
<ogra>
did you read the top note on that page ?
06:40
please dont use it
06:41
and you cant install on a server, you need a desktop
06:41
i mean, you can install on a server, but you will still need a desktop to log in to
06:42
<dipeshmehta>
how do I have a desktop on my server?
06:42
<ogra>
use: https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall
06:44
<dipeshmehta>
thanks for link, but it also mentioned to 1. apt-get install ltsp-server, and 2. ltsp-build-client, I have done the same.... however, I do not have desktop installed on my server, it is CLI only
06:49
<ogra>
you can install ubuntu-desktop on your server, but the results might differ from using a real desktop CD for installation
06:52
<dipeshmehta>
in fact, I do not want to use desktop on my server, but as you said I would be needing to have desktop installed to run LTS, I want to install it... I just want thinclients to work, without disturbing my server's actual jobs...
06:57dirigeant has joined #ltsp
07:09Nubae has joined #ltsp
07:14Egyptian[Home] has quit IRC
07:19The_Code has joined #ltsp
07:20dirigeant has quit IRC
07:22cliebow has joined #ltsp
07:22craver has quit IRC
07:24CAN-o-SPAM has joined #ltsp
07:25dirigeant has joined #ltsp
07:28roblimo has quit IRC
07:34dipeshmehta has left #ltsp
07:35Egyptian[Home] has joined #ltsp
07:58ScorpKing has joined #ltsp
08:00ScorpKing has quit IRC
08:01ScorpKing has joined #ltsp
08:04Nubae1 has joined #ltsp
08:05Nubae has quit IRC
08:09ScorpKing has quit IRC
08:09pmatulis has quit IRC
08:10ScorpKing has joined #ltsp
08:10pmatulis has joined #ltsp
08:14dirigeant has quit IRC
08:14dirigeant has joined #ltsp
08:18bobby_C has quit IRC
08:18Gadi has joined #ltsp
08:37jammcq has joined #ltsp
08:37
<jammcq>
good morning everybody
08:37shrek has quit IRC
08:46shogunx has quit IRC
08:47
<stgraber>
morning jammcq
08:50
<jammcq>
hey stgraber
08:50Faithful1 has joined #ltsp
08:51alkisg has joined #ltsp
08:59shogunx has joined #ltsp
09:02Syntony has joined #ltsp
09:02
<Syntony>
hello....only english speaking here`?
09:03
perhaps someone can help me...
09:04
how can i manage userrights for thin clients on my ltsp-server?
09:05
<ScorpKing>
Syntony: what kind of userights?
09:05
userrights*
09:06
<Syntony>
hm?...for the terminal-user
09:08
<ScorpKing>
Syntony: restrict direcoties? restrict site?
09:08
programs?
09:08
directories*
09:08* ScorpKing can't spell today..
09:08
<Syntony>
aaah okay...for programms and directories
09:08
sorry i missunderstood :)
09:08
<ScorpKing>
np
09:08
<Syntony>
my english is not so good :D
09:09
<ScorpKing>
can you explain in detail what you want to do?
09:09
Syntony: neither are myne ;)
09:09
<Syntony>
i can try :)
09:10greenmang0 has quit IRC
09:11
<Syntony>
alright...the users, that r using my thin-clients should not allowed to do everything...okay?...they should only surfing, writing some documents and so on...
09:12
but they should not allowed to change something on the system...
09:12alkisg has quit IRC
09:13
<Syntony>
i hope u know what i mean :D
09:13
<ScorpKing>
Syntony: you can restrict users in derectories with filepermissions.
09:13
<Syntony>
aha...okay...on the server-site?
09:13
<ScorpKing>
Syntony: you are using it for an internet kiosk right?
09:13
yes
09:14
<Syntony>
no its an study-project
09:14
<ScorpKing>
ah
09:14
<Syntony>
for a cluster-room
09:14
<ScorpKing>
hmm..
09:14
<Syntony>
15 thin clients
09:14
1 server
09:15
<ScorpKing>
you only need to fiddle with the server
09:15
i'm not sure if it is possible to chroot the clients. i've never done it myself
09:16
<Syntony>
yeah...hmm....but the clients must be manage
09:16nicoAMG has joined #ltsp
09:16
<ScorpKing>
users will not be able to change the filesystem unless they are in the admin group or root
09:16
<Syntony>
ok
09:16
hmm....
09:16
<ScorpKing>
Syntony: you can use lts.conf file for special client config's
09:17
configurations*
09:17
<Syntony>
the ltsp.conf or lts.conf?
09:17
<ScorpKing>
lts.cont in the tftboot directory
09:18
<Syntony>
hehe u have some fast fingers :D
09:18
<ScorpKing>
not really. haha
09:18
<Syntony>
:)
09:19
also...i can edit the restrict rights for the users in the lts.conf in the tftboot dircetory...right?
09:19
<ScorpKing>
i have to go to gym now but i'm sure if you hang around here someone else might add something usefull or give you a better option
09:20
<Syntony>
hehe okay...thanks alot :)...
09:20
have fun :)
09:20
<ScorpKing>
Syntony: not restrictions. look on the ltsp website documentation for all the things you can put in lts.conf
09:20
cheers
09:20ScorpKing has left #ltsp
09:35rjune has joined #ltsp
09:43evilx_ has quit IRC
09:56Syntony has quit IRC
09:59mikkel has joined #ltsp
10:06bobby_C has joined #ltsp
10:08Faithful1 has quit IRC
10:22Ryan52 has quit IRC
10:22F-GT has quit IRC
10:23mikkel has quit IRC
10:23Ryan52 has joined #ltsp
10:24F-GT has joined #ltsp
10:26dirigeant has quit IRC
10:27dirigeant has joined #ltsp
10:39Comete has joined #ltsp
10:39
<Comete>
hi
10:41mikkel has joined #ltsp
10:41hanthana has joined #ltsp
10:43
<Comete>
i've set up a small network of 16 thinclients and a server with Edubuntu 8.10 but i can't boot correctly more than 3 thinclients, all the others hangs during the boot process. It's well explain in this post:http://www.mail-archive.com/ltsp-discuss@lists.sourceforge.net/msg35552.html
10:44
my problem is exactly the same
10:45
as this guy did, i've tested the network components and the server memory, all is ok.
10:45
i even replaced the NIC on the server
10:47
i can boot without problem each thinclient separately
10:49
<NeonLicht>
so, what's your problem?
10:52
<Comete>
NeonLicht: network connections stop working after more than 3 thinclients were started
10:53
<NeonLicht>
any of them? I mean, you can start any 3 and they work and the 4th doesn't?
10:55
<Gadi>
Comete: if you enabled remote logging, turn it off
10:55
<Comete>
yes
10:55
Gadi: remote login ? what's this ?
10:55
<Gadi>
ie: /etc/default/syslogd (or whatever its called)
10:55
adding "-r" to syslog
10:56
to have it accept logging from the terminals
10:56
that floods the network with traffic
10:56
and can interfere with everything
10:56
some people turn this on for debugging and then forget to turn it off
11:00
<Comete>
Gadi: no, no remote logging
11:12
Gadi: you give me an idea... :) that was LDM_SYSLOG=true in lts.conf
11:12
Gadi: thank a lot !
11:13
<NeonLicht>
do more than 3 terminals come up now?
11:14
<Comete>
yes almost all of them
11:14
but it's still slow
11:14
<NeonLicht>
excellent, so remote logging was the problem, then
11:16
<Comete>
some of them still hangs
11:17etyack has joined #ltsp
11:17
<NeonLicht>
have you tried not to boot all of them at once?
11:18
<etyack>
Is is possible to disable Select Session and Select Language in LDM? Running ubuntu 8.10, ldm 2.0.14
11:18
<NeonLicht>
when I run 20 clients out of one server (4.x times), sometimes a few of the clients couldn't finish booting when all the students on the classroom fired up the boxes at once
11:19
<Comete>
NeonLicht: i will try it tomorrow, i must leave now... thanks !
11:19
<NeonLicht>
good luck
11:19Comete has quit IRC
11:27japerry has joined #ltsp
11:29carniel has joined #ltsp
11:31
<Shingoshi>
Is there anything that would prevent a host to network boot from it's own disks? Where the host was just another client of the system itself?
11:32
It wouldn't actually need to boot from the network.
11:32
I'm just curious how global the LTSP configuration can be made.
11:34
<Gadi>
etyack: I don't believe so - but, it is one of the wishlist features. For now, you would need to change greeter.c
11:34vagrantc has joined #ltsp
11:35
<Shingoshi>
Thanks!! I was hoping no one would think I was CRAZY!!
11:35
LOL
11:36
Where can I get explicit details on the filesystem itself?
11:36
<etyack>
Gadi: ok. I c editor I shall become
11:37evilx has joined #LTSP
11:38
<Shingoshi>
Gadi: Oh wait. Maybe I am CRAZY!! Your answer was for etyack!
11:38* Gadi wasn't going to be the one to point that out
11:38* Gadi slowly steps away
11:38
<Gadi>
:)
11:39
Shingoshi: you can boot a virtual machine thin client to the server real easily
11:40
you could also run ldm on its own without *too* much hacking
11:40
<Shingoshi>
Ok. So I'm possibly, marginally crazy!
11:40
lol
11:42
The thing that I realize, is that if the main server boots from the network, it wouldn't (might not) have access to files on it's own drive outside of it's own root.
11:42carniel has quit IRC
11:42
<Gadi>
damn it, Jim, I'm a doctor not a bricklayer
11:42
<Shingoshi>
lol
11:43* Gadi has no clue what you are saying
11:43* Gadi smiles and nods
11:43
<Shingoshi>
Let me try again.
11:44
I'm thinking of creating a root filesystem, where each ARCH has it's own root.
11:44
Given that case, the main server could either boot locally or from the network.
11:45
If locally, it could create a mount in memory, giving it access to all the files on the system.
11:45
If by network, it might be able to do the same thing. But not sure yet.
11:46
By "mount in memory", I mean something like squashfs in memory.
11:47
Or a loop mount.
11:47
<Gadi>
the *server* network boots?
11:47
or the client?
11:48
<Shingoshi>
The server would be just another client. So the system would have the same boot procedure for all ARCHs.
11:48
<Gadi>
The server is a client to what?
11:48
another server?
11:49
<Shingoshi>
To the files served on it's own disks.
11:49
It's kind of like "the snake eating it's tail"
11:50
Just trying to relate the concept.
11:50tjikkun_work has quit IRC
11:50
<Gadi>
what is the goal here?
11:50
why would you want the i386 client filesystem to have i386 server tools, as well?
11:51
just so a client could be a server to another client?
11:51
<Shingoshi>
Having the same boot procedure copied to all machines. So no one machine would boot differently from another.
11:51
How many different ARCHs are supported by LTSP?
11:52
<Gadi>
as many as the distro supports
11:52
<Shingoshi>
Where is the list so that I can look at it.
11:52
??
11:52
<Gadi>
pick a distro
11:52
<vagrantc>
not exactly true- debian only supports it on i386, amd64 and powerpc, currently
11:52
<Gadi>
LTSP uses the host distro's tools to create a chroot
11:53
<vagrantc>
although it used to support all arches supported by debian, and it's really just a matter of "turning on" all the other arches
11:53
<Gadi>
vagrantc: I suppose it depends how you define "support"
11:53
:)
11:53
<ogra>
for ubuntu officially its only i386 and amd64
11:53
<Shingoshi>
I would mean the ability to boot them.
11:54alkisg has joined #ltsp
11:54
<vagrantc>
Gadi: yeah, i basically disabled all the obscure architectures that i had no way of testing, as it was holding up progress for the other arches...
11:54
<ogra>
if i finally find the time (very unlikely) i will implement ltsp for arm on ubuntu
11:54
<Shingoshi>
I'm looking for: i386, amd64, powerpc(64), sparc, etc/
11:55
<ogra>
(which debian should be able to just take then)
11:56
<Shingoshi>
Hi ogra! Long time since I've chatted with you. Years in fact.
11:56
<vagrantc>
i've got this mipsel machine sitting around...
11:56
there's some mips based laptops and thin clients from lemote.com
11:57
the ltsp upload in debian/unstable actually allows any architecture, but the buildd's don't build it...
11:58
<ogra>
Shingoshi, yeah, and i'm not doing much in ltsp anymore apart from annoying Gadi since he needs that like bread :)
11:59
<vagrantc>
i should poke the mips*/armel buildd's and ask them to start building ltsp again ... of course, those architectures are often the hold-ups.
11:59
Shingoshi: i actually get sparc hardware now and again, but there's one outstanding bug that hasn't gotten fixed that makes ltsp fail to work on debian sparc
11:59
<Shingoshi>
lol
11:59
<Gadi>
its a drug I cannot seem to do without
11:59
<vagrantc>
http://bugs.debian.org/444087
12:00
<ogra>
:)
12:00
<vagrantc>
without that fixed, i have little energy for working with sparc
12:00
<Shingoshi>
vagrantc: Is that limited to Debian?
12:00
<Gadi>
vagrantc: that a driver bug
12:00
<vagrantc>
Shingoshi: probably any distro using klibc for ipconfig
12:00
<Shingoshi>
Does Suse work.
12:01
<vagrantc>
Gadi: in the network card driver?
12:01
<Shingoshi>
Can klibc be replaced with something else instead?
12:01
<vagrantc>
Gadi: it works fine with dhclient
12:01
Shingoshi: yes, but that's more work than i want to bother with.
12:01
<Gadi>
oh? nm - I missed the: DonUnimplemented SPARC system call 97
12:01
:)
12:01dirigeant has quit IRC
12:02
<Gadi>
stgraber reports udhcpc as being much better than ipconfig, anyway
12:02
faster
12:02
only its in universe
12:02
:P
12:02* vagrantc suffers a flashback
12:02
<Gadi>
seems klibc needs more loving in general
12:02
<vagrantc>
used udhcpc with lessdisks
12:03
<Gadi>
bak to the future, baby
12:03
*back
12:03
<vagrantc>
overall, initramfs-tools has "just worked" for the vast majority of cases, and i'd like to stick with whatever it's using.
12:07* Shingoshi looks at udhcpc.
12:07
<Gadi>
indeed - who cares if its slow and poorly written
12:07
:)
12:07
like everything else, we can make options
12:08* Gadi recalls stgraber whipping up some code to use udhcpc if it is installed in the chroot, and ipconfig otherwise
12:09
<SDuensin>
Anybody have a recommendation for logging in to a LTSP server remotely (as in, across the internet where PXE is insane)?
12:09
<vagrantc>
well, i'd hate to make a change to fix a corner case if it breaks things for a larger number of cases.
12:10
<NeonLicht>
SDuensin, gPXE
12:10
<SDuensin>
Yea, but how crazy is that? Would it be useable, or just a glorified tech demo?
12:11
<NeonLicht>
SDuensin, no idea, haven't tried it yet
12:11* SDuensin is reading.
12:12
<SDuensin>
My other idea was to come up with some minimal Linux install of X11 and ssh and run it in a VM.
12:12* NeonLicht looks forwards to SDuensin to stop reading and start trying and telling us the results XDD
12:12
<Gadi>
SDuensin: dont do *X* over the internet
12:12
thats the insane part
12:12
use NX
12:12
<SDuensin>
Yea, I know. But nothing else seems stable.
12:12Lns has joined #ltsp
12:12
<Shingoshi>
NX?
12:13
<Gadi>
www.nomachine.com
12:13
<NeonLicht>
use FreeNX instead :-)
12:13
<SDuensin>
I've used NX and it's pretty zippy. I didn't like all the server side stuff. Never seemed to work right. So maybe just the NX proxy part and LTSP behind it. But then I still need a way to get that on the remote machine.
12:14
<NeonLicht>
I hate the server side of NX
12:15
<SDuensin>
Me too. Which is why I don't want to use it.
12:15
<Shingoshi>
I have freenx installed here.
12:15
<Gadi>
you mean server-side tools?
12:15
<NeonLicht>
starting by the fact that it installs itself on /usr/NX :(((
12:15
<Shingoshi>
freenx-server.
12:16
<SDuensin>
I always have issues with it not catching disconnects and just generally being weird.
12:21spectra has joined #ltsp
12:26din_os has joined #ltsp
12:27The_Code has quit IRC
12:27F-GT has quit IRC
12:32davidj has joined #ltsp
12:32
<davidj>
Hey, guys.
12:34
<SDuensin>
Howdy.
12:35Subhodip has joined #ltsp
12:36Appiah_ has joined #ltsp
12:36Appiah has quit IRC
12:37
<Lns>
morning
12:37
<davidj>
Anything going on?
12:37* SDuensin is trying to gpxe over the internet
12:38* NeonLicht impatiently waits for SDuensin's results
12:38
<Lns>
might take a while to broadcast across the whole inet ;)
12:39
<NeonLicht>
Lns, he's not broadcasting, that's why he uses gPXE instead of plain PXE :-)
12:39
<Lns>
NeonLicht: i know.. :) just joshin
12:39* Lns steps back from his outdated term
12:40
<NeonLicht>
hahaha
12:41Appiah_ has quit IRC
12:41Appiah has joined #ltsp
12:44F-GT has joined #ltsp
12:44
<SDuensin>
Well, I can get the image to load. Dunno how to boot it yet.
12:45
Whoa! Got it. Except it's the wrong image. :-)
12:45
<NeonLicht>
hahahahaha
12:45* SDuensin has two PXE servers - trying to get to the "non-standard" one.
12:46Appiah has quit IRC
12:46
<Lns>
SDuensin: how's the boot/load speed? what kind of wan link are you on?
12:46johnny has left #ltsp
12:46
<davidj>
SDuensin: How does your client find the gpxe server?
12:47
<SDuensin>
Right now, I'm just bangin' commands into the gPXE command line.
12:47
Lns - This first test is over my wifi, so it doesn't really count for speed. If I can get it to work at all, then I'll move on.
12:47
<NeonLicht>
davidj: there are no gPXE servers, it's just a PXE server, it's the gPXE the one which is instructed to query a (particular) PXE server
12:48
<Lns>
SDuensin: cool. what's your intention of doing this in the long term?
12:49
<SDuensin>
I want remote access to my LTSP box.
12:49
<davidj>
SDuensin: You don't need pxe for remote access to ltsp
12:49
<NeonLicht>
Lns, his intention is to inform me about hes results, since I'm being too lazy to try gPXE myself XDDDD
12:49
<SDuensin>
davidj - Then tell me a good way to do it!
12:50
<Lns>
SDuensin: vnc over ssh?
12:50
<davidj>
NX, VNC, or a simple "X -query"
12:50
VNC over ssh is simplest.
12:50
<Lns>
or do you want a true thin-client over a wan. if so, why?
12:50
<davidj>
run "vncclient --via MyLtspServer :1
12:50
<NeonLicht>
davidj, from a local thin client with no OS nstalled locally?
12:51
<SDuensin>
I don't care how it works, I just want to get remotely the same thing my users attached to terminals see.
12:51
<davidj>
A true thin client over a wan is likely to be too slow to be fun.
12:51
<Lns>
or look at the vnc/inetd/ssh/gdm howto i wrote :) https://help.ubuntu.com/community/UbuntuLTSP/GDMVNCInetdssh
12:51
<davidj>
SDuensin: Does the remote machine have linux on it?
12:51
<NeonLicht>
davidj: maybe not, once the image and X are running locally on RAM
12:51
<SDuensin>
Lns - Looked at, read, and implemented. :-)
12:52
davidj - It'll likely be in a VM, so sure, Linux. :-)
12:52Appiah has joined #ltsp
12:52
<Lns>
SDuensin: so you're wanting a TRUE thin-client session..
12:52
<davidj>
NeonLicht: But who wants to wait 20 minutes for the client to boot?
12:52
<SDuensin>
Lns - Yes.
12:52
davidj - I can keep the boot image. It doesn't have to drag it across the net every time.
12:53
<davidj>
SDuensin: The simplest way to do it is to ssh $server -l $youraccount, then run vncserver :3.
12:53
<SDuensin>
I also saw an NX proxy hack to put NX between the terms and the server. That'd be good for this.
12:53
<davidj>
Then run "vncclient -via $server :3" locally.
12:54
<SDuensin>
davidj - That's fine for me. Heck, the howto Lns wrote is ok for me. I want road warriors to get the same thing on a laptop they get at their desk.
12:54
<davidj>
SDuensin: Ah.
12:54
That's a bit different.
12:55
<Lns>
yeah..well let us know how it performs. I'd have to think that it'd be pretty darn slow myself, but i'm probably wrong =)
12:55
<alkisg>
SDuensin: kernel /ltsp/i386/vmlinuz ro ip=${ip}:${next-server}:${gateway}:${netmask}:${hostname}:eth0:none filename=${filename} can get you past the ipconfig dhcp request - if you're using ubuntu or debian.
12:55
<davidj>
Doing it for a single user is one thing. Doing it for a group is likely to be a problem.
12:55
<SDuensin>
davidj - Yes, it is. :-)
12:55
<davidj>
I'd suggest you use something like openvpn to create a secure tunnel from each laptop back to the office.
12:56
<SDuensin>
alkisg - Toss that in grub or what?
12:56
<alkisg>
In the gpxe command line
12:56
<Lns>
or you could ask Gadi about their LTSP bootstick
12:56
<davidj>
Give each laptop a different openvpn key so when one gets lost you can "change the locks"
12:56
Gadi's bootstick is one option.
12:56
SDuensin: A few things to consider:
12:56
<alkisg>
SDuensin: of course you should set all the variables first (ip, gateway, dns etc)
12:57
<SDuensin>
alkisg - ah! thanks.
12:57
<Lns>
I'd say that's probably best. You're booting the chroot locally, so it won't take so long
12:57
<davidj>
If your road warriors are using LTSP, everything's going to run over the network.
12:57Appiah has quit IRC
12:57Appiah has joined #ltsp
12:57
<SDuensin>
davidj - Yea, but with nx proxy, it's zippy.
12:58
<davidj>
Zippy or not isn't the biggest problem.
12:58
<alkisg>
SDuensin: and here is a patched gpxe versions that can load gpxe scripts from files: https://help.ubuntu.com/community/UbuntuLTSP/grubgpxe
12:58
<davidj>
You need to consider security
12:58
also consider printing (if a user prints, it comes out at the office)
12:58
<SDuensin>
Don't need printing so much.
12:59
<davidj>
Can you install linux on each laptop, then configure it to automatically mount /home from your LTSP server via openvpn?
12:59
Then you get security, speed, and access to the office.
13:00
<SDuensin>
that eliminates the nice central management though
13:00
<NeonLicht>
SDuensin, already got the right server/image?
13:00
<SDuensin>
NeonLicht - For?
13:01* SDuensin has an LTSP running.
13:01
<NeonLicht>
SDuensin, you said you got the wrong one b4
13:01
<SDuensin>
Oh! Off my PXE stuff. Still fartin' with it.
13:01
<NeonLicht>
SDuensin, you mean a gXPE booted over the iNet one?
13:02
<davidj>
SDuensin: What central management do you loose?
13:02
SDuensin: Do the laptops come to the office on a schedule, or are they always in the field?
13:02
<SDuensin>
davidj - Maybe I'm misunderstanding. If I just mount /home for them, they don't get the apps installed on the server. Just their local ones.
13:02
I may never see the person. Remote people helping on a project could be anywhere.
13:03
That's why I was looking at a VM with something in it. "Here, download this. Double-click it."
13:06Appiah has quit IRC
13:06Appiah has joined #ltsp
13:07
<SDuensin>
See? This is not so easy! :-P
13:07Remaille has joined #ltsp
13:07
<SDuensin>
What is this mythical magical Gadi boot stick?
13:11Appiah has quit IRC
13:12Appiah has joined #ltsp
13:14The_Code has joined #ltsp
13:14din_os has left #ltsp
13:14twinprism has quit IRC
13:16ogra has quit IRC
13:19ogra has joined #ltsp
13:20
<Lns>
ogra !
13:20rjune has quit IRC
13:21rjune has joined #ltsp
13:23
<Gadi>
SDuensin: http://www.thesymbiont.com/index.php?option=com_content&task=blogcategory&id=137&Itemid=145
13:23
<SDuensin>
Gadi - Interesting.
13:25
<davidj>
Hello, Gadi. How are you?
13:25
rjune: You here?
13:25
<Gadi>
davidj: cant complain
13:25
wrestling with usplash of all things
13:25
:P
13:26
<ogra>
do you win ?
13:26
<davidj>
heh
13:26
<Gadi>
rarely
13:26
I always forget the magic to make the stars align so it actually produces an image
13:26
:)
13:27
<ogra>
heh
13:27
well, KK will likely have KMS
13:27Subhodip has quit IRC
13:27
<Gadi>
great! by then, I'll have moved from gutsy!
13:27
;)
13:27
<ogra>
heh, you will have to
13:27
<Gadi>
ogra, you're not my real mother!
13:28
<ogra>
how do you know? did you even ask your father ? :)
13:28
<NeonLicht>
is it possible to indicate on lts.cnf to run a vncviewer proccess on a VT as you do with rdesktop?
13:28
<ogra>
no
13:28
but we accept patches
13:28
<davidj>
You could do it with ltsp 4
13:29
but you don't want to go down that road...
13:29
<ogra>
you can surely script something for ltsp5 as well
13:29
<NeonLicht>
I think I did it at some point, but I couldn't remember how
13:29
<ogra>
by just grabbing the redesktop scripts
13:29
<Gadi>
NeonLicht: you can write a screen script
13:29
its trivial
13:29
<NeonLicht>
Gadi, I'm not very good at coding, I'm afraid :(
13:30
<Gadi>
NeonLicht: copy rdesktop, as ogra says
13:30
/usr/share/ltsp/screen.d/rdesktop
13:30
<NeonLicht>
I just do some PHP for databases web interfaces :-)
13:30
<ogra>
i think it only has two or three lines
13:30
<NeonLicht>
Gadi, ok, I try and see what I get
13:30
<Gadi>
cp /usr/share/ltsp/screen.d/rdesktop /usr/share/ltsp/screen.d/vncviewer
13:30
<ogra>
just replace them with the call for vnc
13:31
<Gadi>
then: SCREEN_07=vncviewer
13:31cliebow has quit IRC
13:32
<NeonLicht>
mmhhhh... there is a commented line on "rdesktop" which goes "#/usr/bin/x11vnc -display ${DISP} -passwd password -httpport 5800"
13:33
<Gadi>
yeah, the rdesktop script has some artifacts from days gone by
13:34
<ogra>
bah, usplash on ARM doesnt work :(
13:34
<Gadi>
ogra: do you know of a way to test why a usplash theme .so file would fail?
13:34
or do I need to resort to trial and error
13:34
:)
13:35
<ogra>
i think the latter, did you resort to 256 colors ?
13:35
<Gadi>
16 colors
13:36
file usplash_primary.png
13:36
usplash_primary.png: PNG image data, 1600 x 1200, 4-bit colormap, non-interlaced
13:36
<ogra>
indexed ?
13:36
<Gadi>
yeah
13:36
should it be RGB?
13:36
<ogra>
no, indexed
13:37
strange
13:37
should actually work then
13:37
<Gadi>
hmm...
13:37
<ogra>
do you build it properly ?
13:37
<Gadi>
I use the usplash-theme deb
13:37
so, I think I do
13:40
<ogra>
did you follow the wiki ?
13:40The_Code has quit IRC
13:40
<Gadi>
which one?
13:40
:P
13:41
<ogra>
https://help.ubuntu.com/community/USplashCustomizationHowto
13:42
<Gadi>
yeah
13:42
but the steps in that are handled by dpkg-buildpackage
13:42
:)
13:42
and these days, it uses pngtousplash
13:53
<rjune>
davidj, sup!
13:53
!g
13:53
<ltspbot>
rjune: "g" is Gadi!!!!!!!!!!!!!!!!!!!!!!!!
13:54
<davidj>
rjune: Hey!
13:54
How are you?
13:54
<rjune>
meh, same old same old.
13:55
looking to hang out the shingle again
13:56
<Lns>
Can you specify params in lts.conf RCFILE_NN - i.e. "RCFILE_01 = crontab /etc/ltsp/root.crontab" ?
13:59
<vagrantc>
Lns: RCFILE_01 = /full/path/to/script
13:59
Lns: relative to the chroot
13:59
<Lns>
vagrantc: right...but can i specify parms to the script?
13:59
<vagrantc>
Lns: i.e. /opt/ltsp/i386/etc/foobar would be RCFILE_NN = /etc/foobar
13:59
Lns: no.
13:59
<davidj>
rjune: Got a sec?
13:59
<Lns>
vagrantc: ok..so i'll have to write a wrapper script
13:59
<ogra>
write a wrapper script
13:59
<vagrantc>
Lns: write a custom script.
13:59
<Lns>
thx =)
14:00* Lns is revamping automated shutdown to allow admins to disable / modify times if desired
14:17
<Lns>
Any special considerations when installing openssh-server in client chroot?
14:17
<ogra>
apart from no security ?
14:17
<Lns>
ogra: ?
14:17
<ogra>
(all your clients have the same key)
14:18
<vagrantc>
and regenerating the keys on the fly wouldn't give you any way to verify them
14:18
<Lns>
ogra: they do by default, for LDM ssh stuff right?
14:18
<vagrantc>
Lns: that's going the other direction
14:18
<ogra>
right
14:18
<vagrantc>
although the key verification is still suspect
14:18
<ogra>
indeed
14:19
but not as insecure as running a server on the clienzt
14:19
<vagrantc>
i.e. possible to do a man-in-the-middle attack by hacking NBD/NFS to return an invalid known_hosts
14:19
ogra: agreed.
14:19
<Lns>
hmm.
14:19
<vagrantc>
well, it depends on what you're doing, really.
14:19
<Lns>
well i need a way to execute commands on all clients at once...
14:19
<vagrantc>
i mean, if you just need a way to trigger certain commands, and you lock the keys down to run only those commands...
14:19
<ogra>
restrict to a single user key
14:19
<Lns>
kinda like what 4.2 did i guess. but i'd like to make it as secure as possible
14:19
<ogra>
copy that into the chroot as well
14:20
<Lns>
ogra: sounds like a plan
14:20
<ogra>
that gives you at least some security
14:20
<Lns>
yeah i was going to create a root-based ssh key and use auth for that
14:21
<vagrantc>
for security, it's basically worthless ... for testing purposes or experimentation, no big deal
14:21
Lns: i'd experiment with locking the keys down to particular commands, if you can.
14:21
<Lns>
vagrantc: ok, never thought you could do that - i'll google it =)
14:22
<vagrantc>
in ~/.ssh/authorized_keys: command="exact_command --with --exact arguments" SSH_KEY
14:22
<Lns>
vagrantc: noooice. =) thanks!
14:22
<vagrantc>
Lns: but you can't securely pass it arguments that way ...
14:23
i.e. any command you try to run will run the command specified in authorized_keys
14:23
with the arguments specified there
14:23
<Lns>
vagrantc: well it'll be to do a single command (disable root's one active cronjon on the client) so there wont' be any custom params
14:23
<Gadi>
whose key are you worried is spoofed?
14:23
<Lns>
cronjob*
14:23
<Gadi>
authorized_keys has public keys
14:23
<vagrantc>
the client's host keys
14:24
<Gadi>
and say someone spoofs the clients keys
14:24
then, what?
14:24
they can have a command happen to them?
14:25
<ogra>
you still need the root key from the initiating side
14:25
<vagrantc>
that's why i say use authorized_keys
14:25
so you're not running arbitrary commands from the commandline on a spoofed client.
14:25
feel free to call me paranoid.
14:26
<Lns>
better paranoid than microsoft security practice =p
14:26* Gadi just wants to understand the security hole
14:26
<Lns>
ba-da-pssshhhh
14:26
<Gadi>
:)
14:27
I suppose I could make a computer that I have root access to look like a thin client so that the arbitrary command runs on me
14:27
<vagrantc>
i think you might run into issues where ssh defaults will complain a lot, but not positive ... i.e. you're trying to log into thinclient1 with ssh key foo, but known_hosts says thinclient2 has that key
14:27
<Gadi>
of course, that requires root access
14:27
<vagrantc>
well, you can mount the filesystem and emulate a thin client pretty easily...
14:28RobertLaptop has quit IRC
14:28
<Gadi>
right, in which case the arbitrary command intended for any thin client runs on me
14:28
which does not seem like a security hole
14:29
<vagrantc>
if that arbitrary command is soemthing like "ssh root@someserver" and it logs your keystrokes ...
14:29
that's a stupid thing to do, which is why i don't want to give anybody the opportunity to do something like that.
14:29
<Lns>
vagrantc: well that'd be a pretty bad thing to do in the first place, regardless of what facilities you use
14:30
<Gadi>
I see
14:30RobertLaptop has joined #ltsp
14:30
<vagrantc>
so forced commands prevent you from running stupid things from an interactive commandline
14:30
<Gadi>
not really
14:30
<Lns>
lemme clarify a bit - I want to log into the thin-client from the ltsp server via ssh by using priv/pub keys and no password
14:30
<Gadi>
because the same person that sets the command sets what commands can be set
14:30
<vagrantc>
right
14:31
<Lns>
i install openssh-server in chroot, create a new priv/pub keypair
14:31
set it up so only that key can be authed, to run a very specific command only
14:31
<vagrantc>
Gadi: well, sure, they could fire up a shell or some other interactive command to do something stupid
14:32
if you use very specific commands, designed for particular tasks, you limit the risk significantly.
14:32
<Lns>
vagrantc: how could someone get access to the chroot in the first place without a password?
14:32
<Gadi>
no, I mean, the same admin that sets up the ssh key to run command foo, is the same one that runs command foo at regular intervals
14:32
regardless of the authenticity of the client
14:32
we are not worried about the root key being compromised
14:32
<vagrantc>
well, there's thousands of root exploits for users with shell access, and localapps now gives everyone shell access to the thin client.
14:32
<Gadi>
only the host keys
14:33
<Lns>
vagrantc: well good thing i'm running hardy =p~~ ~
14:33
Gadi: ah
14:33
<Gadi>
I dont see how that exploit impacts the root ssh-key being exploited
14:33
but, I must be missing something obvious
14:34
<vagrantc>
Gadi: yes, but running foo from authorized_keys doesn't give you the ability to log in to an interactive shell, run foo, and then think "oh, while i'm here i may was well do ..."
14:34
you have to think about what commands you're going to allow in advance
14:34
<Gadi>
but, only root on the server cn run foo
14:34
<vagrantc>
which hopefully will prevent you from putting stupid things in authorized_keys
14:36
Gadi: by running arbitrary commands as root on the interactive commandline, on a machine which is fairly easy to man-in-the-middle, they can log the commands and keystrokes you type ...
14:37
which may be something stupid
14:37
<Gadi>
but that is an exploit of local apps
14:37
not of a root ssh key exchange
14:37
<vagrantc>
not necessarily... anyone can mount NBD/NFS and pretend to be a thin client.
14:37
<Gadi>
because it is an exploit of the local root user
14:37
not the server root user
14:37
<vagrantc>
anyone has root access to the thin client.
14:38
<Gadi>
right
14:38
<vagrantc>
and the thin client's host keys
14:38
<Gadi>
but the NFS root only has a public root ssh key
14:38
not the private one
14:38ByPasS has joined #ltsp
14:38
<Gadi>
only the server would have the private one
14:38
<vagrantc>
and anything you do on that spoofed thin client could be logged.
14:39
<Gadi>
ok...
14:39
<vagrantc>
which could include logging into other machines on the network...
14:39
or any number of other things best to avoid
14:40
could even be done accidentally
14:40
<Gadi>
indeed
14:40
we need more skulls and crossbones over LTSP
14:40
:)
14:40
<vagrantc>
heh
14:40hanthana_ has joined #ltsp
14:41
<vagrantc>
granted, all of this is fairly corner-case
14:41
<ogra>
Gadi, you didnt submit that logo :P
14:41
<vagrantc>
but running ssh/sshd on a thin-client isn't nearly as secure as people normally expect ssh connections to be. that's the basic point.
14:42* ogra wonders what came out of the contest ... i voted looong ago
14:42
<ogra>
CAN-o-SPAM, ^^^ was there any outcome yet ?
14:44
<Lns>
me too! can't find results.
14:46
<vagrantc>
given the number of logos compared to the number of votes, i wouldn't be surprised if there was no clear winner.
14:48* Gadi just voted today *blush*
14:52
<Lns>
lol
14:54
<ByPasS>
I'm trying to get an HP Laserjet 1000(USB) to work on a thinclient, I had no problems so far with parallel printers this is my first attempt on a USB one
14:55
I've added in lts.conf PRINTER_0_TYPE = U & PRINTER_0_DEVICE = /dev/usblp0
14:55
added the printer in cups as hp laserjet 1000 but each time I send something or simply try to print test page
14:55
<vagrantc>
i had a clear favorite logo, and a handful of 2nds and 3rds ... i had a hard time making up my mind.
14:56dirigeant has joined #ltsp
14:56
<ByPasS>
I get an error saying unable to write print data: broken pipe
14:56
<Gadi>
ByPasS: HPLJ1000 is not supported
14:56
by jetdirect
14:56
<ByPasS>
maybe worth mentioning that jetpipe dies on the client
14:56* jammcq is sitting on the edge of his seat, waiting for the outcome of the logo contest
14:56
<ByPasS>
ohhhh :(
14:56
<Gadi>
it is not a real printer
14:57
<ByPasS>
good thing Ive been on to ask I've been fooling around quite a while on it eh
14:57
<Gadi>
http://h10025.www1.hp.com/ewfrf/wc/fastFaqLiteDocument?lc=en&cc=uk&dlc=en&docname=bpj06101
14:59
<ByPasS>
thanks alot gadi :)
14:59
<Lns>
I can't believe anyone (well, ok, it's HP after all) thought it would be a good idea to have a firmware-less printer. Like Winmodems...screams vendor lock-in
15:00
it's too bad they were so popular. I had to face one not working in ltsp myself
15:02hanthana has quit IRC
15:02
<Gadi>
ByPasS: np
15:02
I think the 1000 was a best seller
15:02
comes up a lot in ltsp
15:02
:)
15:02din_os has joined #ltsp
15:03
<Lns>
so it looks like with using command="string" in authorized keys, you're effectively limiting yourself to a single command when logging in (i.e. can't specify *which* command="string" to use i'm presuming)
15:03
so I could craft my deal to do that, but then i can't expand it at all in the future without some hackery
15:04
swapping out different authorized_keys with different commands on the fly or something dumb like that
15:05
<vagrantc>
Lns: use a separate key for each command...
15:05* Gadi curses usplash
15:06
<Lns>
vagrantc: ah =) *slaps head*
15:06* CAN-o-SPAM lets everyone know outcome of the logo contest coming tomorrow
15:06* CAN-o-SPAM thinks get developers to cast votes sometimes isn't easy ;)
15:09
<vagrantc>
CAN-o-SPAM: well, as far as i know, this is the first time LTSP has really had a vote, at least since i've been involved.
15:09
much more used to interactive discussion and dialogue
15:10
<epsas>
where are the contestants?
15:10
<jammcq>
we've got all the contestants trapped on a cruise liner, floating off of the bahamas
15:14
<CAN-o-SPAM>
http://www.disklessworkstations.com/cgi-bin/web/contestlogos.html
15:14
<rjune>
jammcq!
15:14
<CAN-o-SPAM>
if you want to see the logos ^
15:14
<jammcq>
rjune!
15:14
<rjune>
how goes it?
15:14
<jammcq>
going well.
15:14
how's by you?
15:15* rjune likes http://www.disklessworkstations.com/web/images/logos/sBalneaves1.png best
15:15
<rjune>
been alright
15:17
<jammcq>
rjune: yeah, that was my 1st choice too
15:20
<rjune>
what do we know, eh?
15:23hanthana_ has quit IRC
15:23twinprism has joined #ltsp
15:27makghosh has joined #ltsp
15:30mahdi_ja has joined #ltsp
15:30
<mahdi_ja>
hi all.
15:30
can i use my pc instead of a thin client.
15:32
<CAN-o-SPAM>
mahdi_ja: sure, as long as your PC can PXE boot
15:35CAN-o-SPAM has quit IRC
15:48etyack has left #ltsp
15:51ByPasS has quit IRC
15:52evilx has quit IRC
15:53mahdi_ja has quit IRC
16:05Nubae has joined #ltsp
16:05
<Lns>
If I were to want IP addresses of connected clients, would this be the best way to do it (particularly regarding the sed cmds)? :
16:05
arp -an | cut -d " " -f 2 | sed s/"("//g | sed s/")"//g
16:05
(I just want to strip out the parentheses)
16:05Nubae1 has quit IRC
16:06
<Lns>
I'm sure there's a cleaner way to do it...
16:07
<vagrantc>
you could do a single call to sed by using sed -e s/"("//g -e s/")"//g
16:07
<Lns>
vagrantc: ah thx
16:15ccherret1 has joined #ltsp
16:15spectra has quit IRC
16:16ccherrett has quit IRC
16:19alkisg has quit IRC
16:20
<din_os>
vagrantc: thx from me too, I was looking for that one, I'll try it tomorrow
16:24alkisg has joined #ltsp
16:25alkisg has joined #ltsp
16:30Remaille has quit IRC
16:46alkisg has quit IRC
16:57din_os has left #ltsp
17:02nicros is now known as nicros_away
17:08
<Lns>
vagrantc: i'm really sorry if i'm bugging you and/or being stupid - but can you tell me again, why restricting "authorized_keys" to certain commands, given the ASSUMPTION that whoever is sitting at a root shell is ALREADY authorized since they've got access to said shell, would be beneficial?
17:09
I'm trying to justify adding keys && rebuilding a chroot every time i want to add a command to my script would be worth it, instead of just using ssh commands in my script alone.
17:09
<vagrantc>
Lns: because the ssh host keys (private and public) of the thin client are available to anyone on the network via NBD
17:10
Lns: so someone could "pretend" to be the thin client you're trying to log into by stealing it's ip address and ssh host key
17:10jammcq has quit IRC
17:11
<Lns>
vagrantc: ok...but host key security aside, i'm talking strictly about restricting authorized_keys to specified commands
17:11
<vagrantc>
Lns: and then they can log any commands or keystrokes on any sessions you run.
17:11
depends on what your threat level is.
17:11
<Lns>
in all reality isn't what you're talking about a wider security issue, given anyone can boot a computer via pxe on the local net?
17:12
(at least in my situation :) )
17:12
<vagrantc>
sure, it's a wider issue.
17:12
<Lns>
ok... i do see your point
17:12
<vagrantc>
the issue is really that people expect ssh to be secure, and you need to know that this is a compromised ssh connection.
17:12
<Lns>
vagrantc: but just in the sense that you might run a command on an 'evil' client
17:13
<vagrantc>
and if you understand all the implications of that, and don't make mistakes, you'll probably be fine.
17:13
Lns: yes. in particular, don't ever do anything on one client that could give you access to other machines on the network...
17:14
but it really depends on your risk assessment...
17:14
<Lns>
vagrantc: cool. Ok, so i'm going to rewrite my little doodad to just use a single userkey instead of making one for each command to be executed, since what your'e saying is outside that scope of security
17:14
<vagrantc>
the worst case scenario is someone can use it to gain root on your whole network :)
17:14
<Lns>
vagrantc: right. this is for simple commands like shutting a system down
17:15
vagrantc: well if they have root on the ltsp server, i'd have to say that's the case anyway :)
17:15
<vagrantc>
Lns: well, you're opening some additional possibilities to gain root on the ltsp server, even if they may be highly unlikely.
17:16
<Lns>
vagrantc: such as?
17:16
<vagrantc>
basically, all security issues come down to creating additional possibilities to gain root.
17:16
<Lns>
ah
17:16twinprism has quit IRC
17:17
<Lns>
well thank you vagrantc that makes it more understandable
17:17
<vagrantc>
Lns: person boots their evil thin client, you log into their evil thin client and run a command as root, you accidentally type in your user or root password, and they use it to log into the server...
17:17
or you log into the thin client and ssh to another machine from it, type in your password ...
17:18
i'm not even realy savvy with this stuff :)
17:18
<Lns>
vagrantc: ok so you're saying basically anything that you do remotely on a TC is vulnerable since it could be potentially comprimised/spoofed by an evil client
17:19
<vagrantc>
Lns: basically
17:19
<Lns>
ok cool.
17:19
that's totally sane
17:19
<vagrantc>
so be careful.
17:19
<Lns>
i will - in a nutshell i'm making a simple menu-driven script that has predefined commands on the ssh commandline already, the techs that will use it won't even have the ability to change it (from the script)
17:20
or at least the knowledge.. and if they did have the knowledge, they'd have the knowledge to compromise a lot more than that alone
17:20
given they have 'sudo' rights
17:20mikkel has quit IRC
17:21
<Lns>
i hate leaving it up to "they won't know how to do that" but an admin acct. is an admin acct...
17:21
i can't take that away from them ;)
17:22
<vagrantc>
there's enough user-level exploits that user access isn't far from root access
17:23
<Lns>
very true
17:24
<Lumiere>
Lns: give limited sudo
17:25
sudo is inredibly flexible ;)
17:25
Lns: what commands do you want them to access
17:25
<Lns>
Lumiere: sudo is limited
17:26
only the on-site techs and I have sudo/root
17:26
<Lumiere>
I am saying for the techs
17:26
if they only need to run a few commands
17:26
<Lns>
Lumiere: i'm creating a script to automate shutdown of all thin clients, as well as other things i can come up with
17:26
<Lumiere>
limit their sudo access to those commands
17:27
<Lns>
Lumiere: that's a very good idea, though the techs need unrestricted access...i'm a subcontractor, but they're the techs that are learning to care for the network in the long term
17:27
<Lumiere>
ah
17:27
<Lns>
i don't really have the right to say "you can only do this"
17:27
i'm just trying to make these processes as foolproof and simple as possible for them
17:27
<Lumiere>
yea
17:28
<Lns>
having an ssh server in the chroot really is so valuable imho. that opens the door to all sorts of administration goodies :)
17:28
as long as you restrict that access as much as possible
17:28
<vagrantc>
sure opens doors, yes. :)
17:28
<Lns>
vagrantc: lol, yes...
17:29
but you can always restrict access to a certain admin workstation, a single user account
17:29
of course you can only do so much
17:31* Lns wonders how iTalc does all it does on the clientside, and if that's any more secure
17:36
<Lumiere>
if it were me
17:37
I'd do the opposite
17:37
I would do something where clients that are logged in
17:37
check some sort of server side
17:37
for administration goodies
17:38CAN-o-SPAM has joined #ltsp
17:38nicoAMG has quit IRC
17:41
<Lns>
Lumiere: i don't follow
17:46Gadi has left #ltsp
17:47
<Lumiere>
Lns: something like cfengine does
17:47
where the client polls a server app for things to do
17:47
every x minutes
17:47
sshd on clients has private key issues
17:48
<Lns>
ah, i see..i was thinking about that too, though ianap.. some sort of ltsp API for client commands, etc.
17:48
right?
17:48
<Lumiere>
yea
17:48
<Lns>
gotcha
17:48
that would be nifty
17:48Faithful has quit IRC
18:19vvinet has joined #ltsp
18:23
<Lns>
LOL - http://www.youtube.com/watch?v=UjRdA25yauU
18:39Lns has quit IRC
18:48Ahmuck has joined #ltsp
18:52laprag has joined #ltsp
18:53Faithful has joined #ltsp
18:59
<Faithful>
nComputing boxes work with LTSP ???
19:02bobby_C has quit IRC
19:04vagrantc has quit IRC
19:13craver has joined #ltsp
19:13craver is now known as nicros
19:19ccherret1 is now known as ccherrett
19:20CAN-o-SPAM has quit IRC
19:24nicros has quit IRC
19:27nicros has joined #ltsp
19:44Faithful has quit IRC
20:13japerry has quit IRC
20:27laprag has left #ltsp
20:56dirigeant has quit IRC
20:59japerry has joined #ltsp
21:28vagrantc has joined #ltsp
21:32pmatulis has quit IRC
21:41michelboaventura has joined #ltsp
21:49makghosh has quit IRC
23:02CaScAdE^FarAway has joined #ltsp
23:05try2free has joined #ltsp
23:13try2free has left #ltsp
23:17vagrantc has quit IRC
23:18CaScAdE^1arAway has quit IRC
23:19faustino3331 has quit IRC
23:20faustino333 has joined #ltsp
23:23nicros has quit IRC
23:24nicros has joined #ltsp
23:36Egyptian[Home]1 has joined #ltsp
23:48safqvbss has joined #ltsp
23:53safqvbss has quit IRC