00:34 | RiXtEr has joined #ltsp | |
00:55 | alkisg has joined #ltsp | |
02:10 | mymrhelpdesk has joined #ltsp | |
02:44 | daya has quit IRC | |
02:57 | daya has joined #ltsp | |
03:07 | Guest58620 is now known as ogra | |
03:07 | mymrhelpdesk has quit IRC | |
03:07 | ogra has quit IRC | |
03:07 | ogra has joined #ltsp | |
03:48 | mymrhelpdesk has joined #ltsp | |
03:58 | obruT has joined #ltsp | |
03:59 | obruT has left #ltsp | |
04:24 | klausade has quit IRC | |
04:31 | Trixboxer has joined #ltsp | |
04:35 | nelson_ has joined #ltsp | |
04:36 | <nelson_> hi all, i have a problem setting up italc client in al ltsp environment
| |
04:36 | ltsp works well, but i can't figure out how to start ica on clients
| |
04:37 | <alkisg> distro/version?
| |
04:38 | <nelson_> ubuntu lucid
| |
04:39 | ltsp5 - italc 1.0.12
| |
04:39 | <alkisg> How did you install italc?
| |
04:39 | <nelson_> i install italc on the server
| |
04:39 | <alkisg> OK, did you logoff both on the server and the clients?
| |
04:40 | The teacher needs to be in the "admin" group to be able to control the clients. And both teacher + students need to logoff after installing italc-master
| |
04:41 | <nelson_> the teacher is in admin group
| |
04:42 | <alkisg> (12:41:00 PM) alkisg: OK, did you logoff both on the server and the clients?
| |
04:43 | <nelson_> ehm, now i do it
| |
04:51 | Gremble has joined #ltsp | |
05:21 | <nelson_> i notice that i receive this segfault in ica (italc client connection daemon) kernel: [ 382.357379] ica[6218]: segfault at 18 ip 00007f1f47607cec sp 00007ffffefbb670 error 4 in libgtk-x11-2.0.so.0.2000.1[7f1f4754a000+417000]
| |
05:27 | <alkisg> italc has many stability problems
| |
05:27 | daya has quit IRC | |
05:27 | <alkisg> In some of my labs it was working, in others it was crashing after a few minutes, in others it couldn't even start
| |
05:27 | So I stopped using it :)
| |
05:28 | <nelson_> :)
| |
05:28 | and do you use some other software as a substitute, alkisg ?
| |
05:29 | <alkisg> I developed one of my own, but it's too suited to our local needs, not ready for broad use
| |
05:29 | <nelson_> :)
| |
05:34 | Trixboxer has quit IRC | |
05:40 | Phantomas has joined #ltsp | |
06:00 | Phantomas has quit IRC | |
06:01 | [GuS] has joined #ltsp | |
06:01 | [GuS] has joined #ltsp | |
06:04 | Gremble has quit IRC | |
06:15 | Phantomas has joined #ltsp | |
06:25 | Phantomas has quit IRC | |
06:29 | <muppis> This is just freak.. I booted my workstation as ltsp client to vm server.
| |
06:30 | [GuS] has quit IRC | |
06:30 | |GuS| has joined #ltsp | |
06:41 | Phantomas has joined #ltsp | |
06:48 | alexqwesa has quit IRC | |
07:04 | Phantomas has quit IRC | |
07:06 | Phantomas has joined #ltsp | |
07:11 | klausade has joined #ltsp | |
07:33 | alkisg has quit IRC | |
07:36 | |GuS| has quit IRC | |
07:38 | [GuS] has joined #ltsp | |
07:51 | alexqwesa has joined #ltsp | |
08:11 | m4xx has joined #ltsp | |
08:34 | F-GT has quit IRC | |
08:34 | zz_evil_root is now known as evil_root | |
08:37 | alkisg_debian has joined #ltsp | |
08:43 | Faithful has joined #ltsp | |
08:47 | F-GT has joined #ltsp | |
08:54 | F-GT has quit IRC | |
08:56 | |GuS| has joined #ltsp | |
08:58 | [GuS] has quit IRC | |
09:06 | F-GT has joined #ltsp | |
09:08 | rjune has quit IRC | |
09:10 | |GuS| is now known as [GuS] | |
09:18 | [GuS] has quit IRC | |
09:19 | C_Tek has joined #ltsp | |
09:21 | C_Tek has left #ltsp | |
09:25 | alkisg has joined #ltsp | |
09:31 | arvin_ has joined #ltsp | |
09:33 | alkisg_debian has quit IRC | |
09:34 | <arvin_> Hi guys, I chrooted into /opt/ltsp/<arch>/ and created a new user, but I can't seem to be able to log on to tty on the clients. How can I enter a tty?
| |
09:35 | <alkisg> Don't create users on the chroot, they're not needed
| |
09:35 | To get a user tty, try this:
| |
09:35 | !localxterm
| |
09:35 | <ltspbot`> alkisg: "localxterm" :: while sitting on a thin client, open a gnome terminal. In that, run: ltsp-localapps xterm. An xterm will open. That xterm runs locally, so any commands you enter there are executed directly on the client.
| |
09:35 | <alkisg> To get a root tty, this:
| |
09:35 | !SCREEN_02
| |
09:35 | <ltspbot`> alkisg: "SCREEN_02" :: to get a root shell on an Ubuntu thin client: https://help.ubuntu.com/community/UbuntuLTSP/ClientTroubleshooting#Using%20a%20shell%20SCREEN
| |
09:36 | <arvin_> That's exactly what I need. :)
| |
09:36 | Thanks alkisg!
| |
09:38 | No wonder I couldn't find any information regarding user creation in LTSP...
| |
09:39 | So the soundcard was installed.
| |
09:40 | Now to see why rdesktop doesn't play sounds...
| |
09:42 | evil_root is now known as zz_evil_root | |
09:44 | Pweg has joined #ltsp | |
09:56 | [GuS] has joined #ltsp | |
09:56 | [GuS] has joined #ltsp | |
10:02 | Phantomas has quit IRC | |
10:11 | zz_evil_root is now known as evil_root | |
10:15 | <alkisg> How does this GUI look for configuring the clients, with something like a new lts.conf? http://imagebin.org/index.php?mode=image&id=130256
| |
10:16 | __nelson__ has joined #ltsp | |
10:17 | <muppis> alkisg, looks suitable.
| |
10:17 | Phantomas has joined #ltsp | |
10:17 | <alkisg> Good, I'll send a mail to the devs list
| |
10:18 | nelson_ has quit IRC | |
10:22 | leio has quit IRC | |
10:28 | phpdevel_ has joined #ltsp | |
10:31 | phpdevel has quit IRC | |
10:34 | Phantomas has quit IRC | |
10:39 | litlebuda has joined #ltsp | |
10:46 | staffencasa has joined #ltsp | |
10:50 | [GuS] has quit IRC | |
10:50 | Phantomas has joined #ltsp | |
10:59 | Phantomas1 has joined #ltsp | |
10:59 | Phantomas has quit IRC | |
10:59 | alkisg has quit IRC | |
11:02 | johnny has joined #ltsp | |
11:09 | Phantomas1 is now known as Phantomas | |
11:09 | leio has joined #ltsp | |
11:12 | johnny has left #ltsp | |
11:12 | johnny has joined #ltsp | |
11:13 | litlebuda has quit IRC | |
11:15 | litlebuda has joined #ltsp | |
11:17 | __nelson__ has quit IRC | |
11:25 | alkisg has joined #ltsp | |
11:53 | litlebuda has quit IRC | |
11:55 | litlebuda has joined #ltsp | |
11:58 | otavio has joined #ltsp | |
11:58 | otavio has joined #ltsp | |
12:53 | MorningSon has joined #ltsp | |
13:04 | <alkisg> stgraber: ping?
| |
13:04 | Got a few minutes?
| |
13:16 | FrtizTheCat has joined #ltsp | |
13:29 | vagrantc has joined #ltsp | |
13:39 | Phantomas has quit IRC | |
13:39 | Phantomas has joined #ltsp | |
14:12 | FrtizTheCat has quit IRC | |
14:18 | markit has joined #ltsp | |
14:22 | johnny has quit IRC | |
14:23 | spectra has quit IRC | |
14:23 | spectra_ has joined #ltsp | |
14:23 | shogunx has quit IRC | |
14:36 | shogunx has joined #ltsp | |
14:43 | Phantomas has left #ltsp | |
14:56 | leio has quit IRC | |
14:59 | leio has joined #ltsp | |
15:04 | Da-Geek has joined #ltsp | |
15:14 | <stgraber> alkisg: pong
| |
15:14 | <alkisg> Hey man
| |
15:14 | <stgraber> alkisg: I'm kind of around, still at the office but not really working anymore :)
| |
15:14 | alkisg: hey, how are things going ?
| |
15:15 | DaGeek_ has joined #ltsp | |
15:15 | <alkisg> Nice... I had some free time on holidays so I came up with that bash/inetd daemon ;)
| |
15:15 | stgraber: so I was thinking... why not allow http requests from your server?
| |
15:15 | This way the client could get its config with a simple wget, even from the initramfs
| |
15:16 | DaGeek_ has quit IRC | |
15:18 | <stgraber> it's certainly possible to make a plugin like the socket plugin to have the daemon listen on regular http as well, thought modifying the socket plugin might be a better solution as then you won't even need to use wget, nc should be enough
| |
15:18 | <alkisg> Both are available with busybox so any of those would do
| |
15:19 | So this way, even if the client xmlrpc python daemon is not available/enabled, getltscfg could be substituted with a simple nc/wget
| |
15:19 | <stgraber> right and the processing would be done server side instead of client side
| |
15:20 | <alkisg> Right, and that's a good think imho because (a) the server knows more, (b) keeps the client simpler (no getltscfg executable in the initramfs), and (c) the server might not want to send the LDM_PASSWORD or other sensitive data to another client
| |
15:20 | <stgraber> the current ltscfg plugin is basically a plugin for ltsp-agent which runs on the thin client itself and gets a new "source" lts.conf every 30s, parse it and then generate a .sh script on-disk that can be sourced instead of using getltscfg.
| |
15:21 | <alkisg> That can be done on the server, saving the client from processing it itself. And the server can do better caching as it knows better when things have changed...
| |
15:21 | So I think the ltscfg plugin should move to the server
| |
15:22 | And later maybe a new plugin could be written that would allow the sysadmin to send vars based on simple rules
| |
15:22 | <stgraber> well, for ltsp-cluster it'll still make sense of having the logic on the thin client as we want to support multiple sources for lts.conf (with inheriting) and stuff like overidding with a lts.conf on a usb stick, but we can clearly make the logic common and have it on both side
| |
15:22 | still making sure the code fallbacks properly if the agent isn't there
| |
15:22 | Da-Geek has quit IRC | |
15:22 | <alkisg> Why not override with simple shell scripts instead of lts.conf?
| |
15:23 | They also can do inheritance and can reside on usb sticks...
| |
15:23 | This way the client can be really simple
| |
15:25 | <stgraber> it's possible to do it this way, though we very likely will stick with the daemon on the thin clients as it'll be there anyway for ltsp-cluster but will be optional for non-cluster deployments. The caching and asyncronous update + having the processing done on the thin client is things we need to keep the load down on the servers
| |
15:25 | <markit> alkisg: hi, how are you? (I'm going to bed in some minutes time)
| |
15:26 | <alkisg> Hi markit
| |
15:26 | <stgraber> but I agree having the parsing done server-side for regular LTSP is probably a good idea and we should make sure we have the common parts in a separate module that both implementation use, so we reduce code duplicaton and make it easier to change logic upstream
| |
15:27 | <alkisg> Right. If you like, and if others agree, I'd suggest making my idea the "base ltsp-fallback" one, and yours the additional bit that -cluster needs...
| |
15:27 | <vagrantc> processing should be done wherever the admin wants it to be done
| |
15:28 | <stgraber> vagrantc: having it done on the thin client will be a simple matter of having ltsp-agent start at boot time, so it should be good enough for everyone
| |
15:28 | <alkisg> Processing = 0.001 msec for simple script sourcing... I don't think it matters for CPU, and chroot/ltsp_config.d will still be there...
| |
15:29 | Gremble has joined #ltsp | |
15:30 | markit has quit IRC | |
15:30 | Gremble has quit IRC | |
15:31 | <alkisg> But right now, the admin *can't* choose to do the processing on the server
| |
15:32 | <vagrantc> sure they can
| |
15:32 | ltsp_config.d
| |
15:32 | <alkisg> ?
| |
15:32 | That's on the chroot
| |
15:32 | <vagrantc> and in the chroot they can put something that queries the server
| |
15:32 | <alkisg> And then write a daemon
| |
15:32 | That's not a sysadmin task :)
| |
15:33 | <vagrantc> they can still choose to do it :P
| |
15:33 | <alkisg> What are the downsides of providing a bash/inetd daemon for lts.conf?
| |
15:33 | <vagrantc> a service running server-side that needs to do input validation
| |
15:34 | it may cause load on the server, depending on what sorts of hooks are used, which may be an issue for an overloaded server
| |
15:35 | <alkisg> So if the sysadmin writes his own daemon and makes bad hooks, it's ok, but if he writes bad hooks on a daemon that we offer to him, it isn't ok?
| |
15:36 | <vagrantc> it's just a consideration, not an end-all-be-all
| |
15:36 | <alkisg> I think in 99% of the cases the sysadmin will use simple rules
| |
15:37 | In the 1% of the cases where the sysadmin wants to do something fancy, he should be able to do something fancy and not break everything... :)
| |
15:37 | If that's considered a problem, we can prevent scripts and only allow rules
| |
15:37 | They'll still be much more powerful than the current mac/ip maching...
| |
15:38 | But many programs allow script hooks, even udhcpc...
| |
15:39 | <vagrantc> don't get all worked up over it :)
| |
15:39 | <alkisg> OK :)
| |
15:39 | Just trying to see if you guys want it because now I have some free time to finish it
| |
15:40 | <knipwim> i can see how administrators with a large number of client could benefit from it
| |
15:40 | <vagrantc> my bigger concern is securely handling the input, since that's a common security issue
| |
15:41 | <alkisg> Security from reading /etc? Didn't you say that's not LTSP's problem?
| |
15:41 | <vagrantc> alkisg: no, from the input passed via inetd
| |
15:41 | the client's input
| |
15:41 | <alkisg> That's only var=values
| |
15:41 | <knipwim> alkisg: don't the clients send their specs in the lts.conf requesT?
| |
15:42 | <vagrantc> alkisg: that's the theory, but i suspect there may be ways to exploit it
| |
15:42 | <alkisg> We can either (a) sign it with the server ssh key or something, or (b) not eval it, just parse it and export it
| |
15:42 | knipwim: right
| |
15:42 | How much harm can env vars do? They get those currently with lts.conf...
| |
15:42 | <vagrantc> alkisg: if a client sends ;/bin/sh for a variable setting
| |
15:43 | <alkisg> IFS='='
| |
15:43 | while read var value; do
| |
15:43 | <vagrantc> ok, a client sends =/bin/sh
| |
15:43 | <alkisg> $var="$value"
| |
15:43 | That can't execute anything...
| |
15:44 | No matter what the client sends, if eval is not used, no execution happens
| |
15:44 | (or the server)
| |
15:47 | And the server only accepts specific vars in a case statement, so the client can't send arbitrary vars like PATH..
| |
15:48 | case mac) mac="$value"
| |
15:48 | <vagrantc> sounds reasonably safe
| |
15:48 | still makes me nervous
| |
15:49 | <alkisg> :)
| |
15:49 | Well, if the sysadmin does "eval something=$mac", then that can be exploited
| |
15:50 | But we can even check for specific patterns in each accepted var so that idiot sysadmin that uses eval can still use it safely...
| |
15:51 | <knipwim> there should be more generic checks against idiotic sysadmins :)
| |
15:51 | <alkisg> Or we can disallow bash scripts and only allow rules + vars setting
| |
15:52 | <vagrantc> not sure to what great lengths we should go to prevent people from shooting themselves in the foot
| |
15:52 | just as long as we're not handing them something stupid
| |
15:53 | * alkisg will check each var we get from the client for a specific pattern, e.g. "arch"=[letter|digit]*, "ram"=[digit]*, etc | |
15:53 | hahlo has quit IRC | |
15:55 | <alkisg> Well the question remains, if we want that as the base ltsp configuration system, and stgraber can add the python daemon for ltsp-cluster setups
| |
16:30 | Selveste1 has quit IRC | |
16:34 | Selveste1 has joined #ltsp | |
16:35 | m4xx has quit IRC | |
16:43 | vagrantc has quit IRC | |
17:23 | ogra has quit IRC | |
17:23 | alkisg has quit IRC | |
17:37 | Pweg has quit IRC | |
18:47 | mymrhelpdesk has quit IRC | |
18:50 | staffencasa has quit IRC | |
18:56 | vagrantc has joined #ltsp | |
19:06 | F-GT has quit IRC | |
19:17 | vagrantc has quit IRC | |
19:18 | F-GT has joined #ltsp | |
19:26 | Faithful has quit IRC | |
19:27 | evil_root is now known as zz_evil_root | |
19:38 | RiXtEr has quit IRC | |
19:38 | RiXtEr has joined #ltsp | |
19:40 | Faithful has joined #ltsp | |
20:20 | johnny has joined #ltsp | |
21:14 | litlebuda has quit IRC | |
21:28 | daya has joined #ltsp | |
21:47 | daya has quit IRC | |
22:56 | Faithful has quit IRC | |
23:07 | F-GT has quit IRC | |
23:28 | F-GT has joined #ltsp | |
23:36 | Faithful has joined #ltsp | |
23:39 | alkisg has joined #ltsp | |
23:47 | mymrhelpdesk has joined #ltsp | |
23:51 | zz_evil_root is now known as evil_root | |
23:57 | mymrhelpdesk has quit IRC | |
23:59 | mymrhelpdesk has joined #ltsp | |