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


Channel log from 27 December 2010   (all times are UTC)

00:08JohnB112 has quit IRC
01:02MorningSon has quit IRC
01:41alkisg has joined #ltsp
01:54Mava has joined #ltsp
02:41vagrantc has quit IRC
03:15Guest44117 has joined #ltsp
03:15Guest44117 is now known as ogra
03:15ogra has joined #ltsp
04:30artista_frustrad has joined #ltsp
04:42johnny has left #ltsp
04:42johnny has joined #ltsp
04:54ponny_ has joined #ltsp
05:07daya has quit IRC
05:15johnny has left #ltsp
05:16johnny has joined #ltsp
05:36alkisg has quit IRC
05:42Kicer86 has joined #ltsp
05:49artista_frustrad has quit IRC
06:45
<ponny_>
anyone have experience with xlite (or similiar) on ltsp?
06:51
<Appiah>
think I've seen someone type about it here..
06:52
and on the mailinglist
06:54zz_evil_root is now known as evil_root
06:55
<ponny_>
okay, i'll check it out
06:55
its kind of semi works right now:)
07:09
<Appiah>
what's the problem?
07:09
I remeber a someone having problems with ekiga that was solved
07:11evil_root is now known as zz_evil_root
07:12
<ponny_>
the problem is that xlite doesnt recognise any audio device
07:12
i do have sound working, i can play mp3 and stuff
07:13
and from ekiga i can make calls, and the one on the other side can hear me
07:13
but alot of noise
07:15johnny has left #ltsp
07:15johnny has joined #ltsp
07:19
<Appiah>
is it installed as a localapp ponny_ ?
07:22Kicer86 has quit IRC
07:22sutula has quit IRC
07:26Kicer86 has joined #ltsp
07:26sutula has joined #ltsp
07:31
<ponny_>
Appiah: no, i havent figured that out yet
07:31
i just saw that suggestion
07:32
<Appiah>
Try it , I think it will find the device then :)
07:33m4xx has quit IRC
07:52Hyperbyte has quit IRC
08:01alkisg has joined #ltsp
08:07rjune has quit IRC
08:15alkisg has quit IRC
08:17Faithful has joined #ltsp
08:21alkisg has joined #ltsp
08:38alkisg has quit IRC
08:38alkisg has joined #ltsp
08:40Gadi has joined #ltsp
08:46[GuS] has joined #ltsp
08:56cliebow has joined #ltsp
09:12_UsUrPeR_ has quit IRC
09:13_UsUrPeR_ has joined #ltsp
09:31JohnB112 has joined #ltsp
09:33JohnB112 has left #ltsp
09:34litlebuda has joined #ltsp
09:35zz_evil_root is now known as evil_root
10:22johnny has left #ltsp
10:22johnny has joined #ltsp
10:34Faithful has quit IRC
10:48Gadi has left #ltsp
10:51otavio has joined #ltsp
10:51otavio has joined #ltsp
12:02Trixboxer has joined #ltsp
12:04MorningSon has joined #ltsp
12:18Kicer86 has quit IRC
12:18sutula has quit IRC
12:47vagrantc has joined #ltsp
12:57cliebow has quit IRC
13:01Kicer86 has joined #ltsp
13:03
<alkisg>
I've started implementing a new shell/inetd based configuration daemon that I want to propose for LTSP (low cpu/ram for both the server and the clients, and it'll also be backwards compatible). I'm thinking of providing the following configuration directories/files:
13:03
# This is global, affects all clients
13:03
/etc/ltsp/config.d
13:03
# Global entries are overriden by the following, in order:
13:03
/etc/ltsp/config.d/by-ip/xxx.xxx.xxx.xxx
13:03
/etc/ltsp/config.d/by-mac/ma-c0-ad-dr-es-s0
13:03
/etc/ltsp/config.d/by-hostname/hostname
13:03
All those dirs contain shell scripts sourced by the daemon.
13:03
Instead of LIKE statements, symlinks or sourcing (.) of other configuration files can be used.
13:03
The hostnames are matched exactly, while mac and IP addresses can be matched partially (at their beginnings).
13:03
Does it sound OK?
13:03sutula has joined #ltsp
13:04
<alkisg>
The server gets installed in inetd.conf like this:
13:04
9573 stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/ltspcfgd
13:04otavio has quit IRC
13:04
<alkisg>
And it is called by ltsp clients like this:
13:04
eval $(nc server 9573 <<EOF
13:04
HOSTNAME $HOSTNAME
13:04
MAC $MAC
13:04
IP $IP
13:04
RAM $RAM
13:04
...
13:04
EOF)
13:05
If getltscfg is available on the server, it'll use it to also parse lts.conf for backwards compatibility.
13:05
Thoughts?
13:05
<hahlo>
time in my fatclient is wrong, despite bios clock is right and server clock too, how can I correct that?
13:11
<vagrantc>
hahlo: probably wrong timezone ... what distro?
13:12
<hahlo>
ubuntu
13:12
<alkisg>
hahlo: grep UTC /opt/ltsp/i386/etc/default/rcS
13:12
<vagrantc>
alkisg: sounds fairly good ... curious about the order of the sourcing bit?
13:12
<hahlo>
from server?
13:12
<alkisg>
hahlo: yes
13:12
<vagrantc>
alkisg: and what does it spit out?
13:13
<alkisg>
vagrantc: I just thought to put them in order of how specific the info is... e.g. 192.168.x is less specific than some mac address or a hostname...
13:13
<vagrantc>
alkisg: obviously wouldn't work very well to set the hostname using that... :)
13:13
<alkisg>
vagrantc: it spits out VAR=value lines, to be eval'ed by the clients
13:13
<hahlo>
UTC=yes
13:14
<vagrantc>
alkisg: wouldn't mac address be more specific than hostname?
13:14
<alkisg>
Juts for the specific client that asked the configuration, so getltscfg won't be needed in the clients in the future
13:14
<vagrantc>
alkisg: also, i use partial matching on hostname a lot
13:15
<alkisg>
vagrantc: I thought that macs can be specified partially, e.g. "all intels get this config", while hostnames would be specific... e.g. "0c-0a-0b" vs "ltsp151"... but of course if it's better to parse the hostnames first, it'll be very easy
13:15
vagrantc: how does partial hostname matching currently work?
13:16
hahlo: what timezone are you in, e.g. UTC+8, and how much different is your time now on your client, by how many hours?
13:17
vagrantc: e.g. if you had an /etc/ltsp/by-hostname/ltsp file, would it match only ltsp141 or would it also match myltsp?
13:18
<hahlo>
I'm in EET utc +2 and fatclient time is 00:18 real local time is 21:18
13:18
<vagrantc>
alkisg: well, i do some of my hostname matching in shell scripts ... but getltscfg supports it
13:18
alkisg: not sure how it works with multiple possible matches
13:19
alkisg: but i'm not sure how it handles multiple matches of anything in general
13:20
<alkisg>
vagrantc: The file system supports wildcards in filenames, e.g. /etc/ltsp/by-hostname/ltsp*, but I'm not sure if that's a reasonable implementation :(
13:21
hahlo: try setting UTC=no and running ltsp-update-image
13:21
<hahlo>
ok
13:21
<vagrantc>
alkisg: does it support multiple in each category?
13:21
<alkisg>
Multiple what?
13:22
<vagrantc>
alkisg: multiple matches ... i.e. if you had /etc/ltsp/by-ip/192.168.0 and /etc/ltsp/192.168.0.100 for a machine with 192.168.0.100
13:22
<alkisg>
Sure I can do that
13:23
I just don
13:23
<vagrantc>
would have to source the last one last, of course
13:23
er, the longest one last
13:23
<alkisg>
I just can't think of a good file-system-based way to specify wildcards for hostnames
13:23
<vagrantc>
192.168.0.10 shouldn't be matched with 192.168.0.100
13:24Gadi_eeepc has joined #ltsp
13:24
<vagrantc>
alkisg: i usually use it with networks like ltspXXX and fooXXX and testXXX where XXX is a bunch of numbers
13:24
<alkisg>
The file system allows a configuration script to be named 'ltsp?123*', which anyone could easily understand what it means, but I don't think putting wildcards in filenames is a good idea...
13:24
<vagrantc>
indeed
13:25
<alkisg>
Maybe we could borrow something from SQL, e.g. % instead of *
13:25
ltsp%
13:26
http://www.techonthenet.com/sql/like.php
13:26* Gadi_eeepc just read backlog - alkisg, are you aware of what stgraber is working on?
13:26
<Gadi_eeepc>
ltsp-cluster-agent-thinclient
13:26
<alkisg>
Gadi_eeepc: I think he's writing a python-based configuration system, right? I like the shell idea better, and it's really easy to implement, I'll propose it and you guys can choose...
13:27
<Gadi_eeepc>
his implementation caches to a shell file that can be sourced
13:27
<alkisg>
Sourcing 1000 shell files needs 0.086 in my pc
13:27
So I think it'll be very, very fast
13:27
<Gadi_eeepc>
not faster than sourcing 1
13:27
:)
13:28
<alkisg>
You can't cache everything... how about server load?
13:28
<Gadi_eeepc>
that you can query
13:28
<alkisg>
Shell scripts can also use caching... ;)
13:28
But you can't cache *code*
13:29
E.g. what if the admin wants to put a script to determine the client configuration dynamically?
13:29
<Gadi_eeepc>
well, before you go too far, you might not want to duplicate efforts
13:29
<alkisg>
It'll be too easy to implement, I think I can do it in 2 days - I'll propose it and you can simply discard it then, np
13:30
I like the idea of giving the admin the ability to specify the configuration using shell scripts
13:30
<Gadi_eeepc>
okey dokey
13:30
<alkisg>
E.g. to decide the hostname based on the client IP address, can the python-based configuration system do that?
13:30
<vagrantc>
Gadi_eeepc: where's stgraber's implementation pull the configuration from?
13:31
<Gadi_eeepc>
vagrantc: either tftp or an xmlrpc request to a control center
13:31
its on lp
13:31
it is plugin-based
13:31
so, itsextensible
13:32
<alkisg>
Python can't source shell files, though...
13:32
<Gadi_eeepc>
it wouldnt have to
13:33
it would cache to a file that can be sourced by shell files
13:33
<alkisg>
How could I say "if it's a thin client, use default color = 16 bit"?
13:33
I'd have to learn python to do it?
13:33
(and for fat clients to not specify the color depth)
13:34
<Gadi_eeepc>
right - i guess the qu is where to put the logic
13:34
<alkisg>
test -n "$FAT_CLIENT" || echo "X_COLORDEPTH=16"
13:35
That's how it would be done by the admin on a shell configuration script...
13:35
<Gadi_eeepc>
u cando that now
13:35
<alkisg>
How?
13:35
<Gadi_eeepc>
in ltsp-config.d
13:35
<alkisg>
And compress the image? Isn't it better to do it in the server /etc?
13:36
Or what if I want to decide something based on a server resource?
13:36
<Gadi_eeepc>
thats the role of the control center
13:37
<alkisg>
The shell-based daemon would be able to do both, keeping the configuration more centralized and easy
13:37
No ltsp-update-image necessary to change a configuration...
13:37
<Gadi_eeepc>
u are basically proposing a control center in bash
13:37
<alkisg>
Right
13:37
Isn't that what sysadmins know better?
13:38
(i.e. instead of python?)
13:38
<Gadi_eeepc>
the python one has a gui
13:38
lol
13:38
<alkisg>
You can make a gui for simple var=value shell scripts easily ;)
13:38
But if you want something more, you can do it with a shell script, instead of a python script
13:39
<Gadi_eeepc>
howdoes the client gett ur scripts?
13:39
tftp?
13:39
<alkisg>
(09:04:49 PM) alkisg: And it is called by ltsp clients like this:
13:39
(09:04:49 PM) alkisg: eval $(nc server 9573 <<EOF
13:39
(09:04:49 PM) alkisg: HOSTNAME $HOSTNAME
13:39
(09:04:49 PM) alkisg: MAC $MAC
13:39
(09:04:49 PM) alkisg: IP $IP
13:39
(09:04:49 PM) alkisg: RAM $RAM
13:39
(09:04:49 PM) alkisg: ...
13:39
(09:04:49 PM) alkisg: EOF)
13:40
I.e. the client gives with nc some info to the server, the server decides, and answers with VAR=value lines
13:40
It's really simple to implement + maintain, both by devs + sysadmins...
13:42
<Gadi_eeepc>
how about secure?
13:42
<alkisg>
Well it's a local network, any client can fake an IP and ask for its configuration...
13:42
You mean ssl etc?
13:42
<Gadi_eeepc>
yeah
13:43
<alkisg>
Then we'd need socat or something on the client... how is the python implementation handling that?
13:43
(socat + openssl)
13:43
+certificate
13:43
<Gadi_eeepc>
they use https and un/pw
13:44
<alkisg>
That's going to be the default for all LTSP? Or only for -cluster?
13:45
Gadi_eeepc: but if any client can boot + take whatever IP it wants, what's the meaning of ssl/https etc?
13:45
It's that just misleading sysadmins to think that it's secure?
13:45
<Gadi_eeepc>
well, its not about the client
13:46
its about spoofing the control center
13:46
and making the client do things
13:46
<alkisg>
If I'm able to spoof the control center, can't I just send an nbd image that I want?
13:47
<Gadi_eeepc>
who says the control center is ur boot server
13:47
<alkisg>
Well we can sign the VAR=value keys with the server ssh key, if it makes you feel better...
13:47
But to me it's just hiding the real problem
13:48
<Gadi_eeepc>
could be
13:49
<alkisg>
So anyway this way the default LTSP installation can continue without Depends:apache
13:49
(is this really going to happen? Depends:apache? no problem from me, I'm just wondering...)
13:49
<Gadi_eeepc>
true
13:49* Gadi_eeepc shrugs
13:51
<Gadi_eeepc>
alkisg: so u would have a daemon client side that nc's the server every n seconds?
13:51
<alkisg>
For the first implementation I'd just replace the getltscfg calls with the nc call
13:51
<Gadi_eeepc>
or only when getltscfg is called?
13:51
<alkisg>
But I think it'll be better if more calls were added
13:52mymrhelpdesk has joined #ltsp
13:52
<Gadi_eeepc>
how about rpcs?
13:52[GuS] has quit IRC
13:52
<mymrhelpdesk>
anyone availaple for a few quiestions
13:52
<Gadi_eeepc>
like 'shutdown' or 'reboot'?
13:52
<mymrhelpdesk>
*questions
13:52
<alkisg>
Nope, it just means to replace getltscfg
13:53
<Gadi_eeepc>
ok
13:53
brb
13:53
<alkisg>
Gadi_eeepc: I have a system for RPCs in my sch-scripts, but I wouldn't put it in ltsp without serious thought about security..
13:54
!ask
13:54
<ltspbot`>
alkisg: "ask" :: Don't ask to ask a question, simply ask it, and if someone knows the answer, they'll respond. Please hang around for at least 15 minutes after asking a question, as not everybody constantly monitors the channel.
13:54
<alkisg>
mymrhelpdesk: ^^
13:54
<mymrhelpdesk>
I just setup a kiwi-ltsp using the dvd, my networks seems fine clients are pulling an ip but not loading image seems to tftp timeout i have disabled firewall still same result any help would be appreciated
13:54
<alkisg>
!kiwi-ltsp
13:54
<ltspbot`>
alkisg: "kiwi-ltsp" :: for kiwi-ltsp related questions, you can also ask in the #kiwi-ltsp freenode IRC channel, or visit http://en.opensuse.org/LTSP
13:55
<alkisg>
Not many people here know the kiwi-related bits...
13:55vagrantc has quit IRC
13:55
<mymrhelpdesk>
perhaps just ltsp why an client wouldn't pull an os if is recieving an ip?
13:56
<alkisg>
mymrhelpdesk: for example, here's the page for tftp troubleshooting in ubuntu: https://help.ubuntu.com/community/UbuntuLTSP/Troubleshooting/TFTP
13:56
Maybe that can help you, but I don't know how well it applies to opensuse + kiwi...
13:57
<mymrhelpdesk>
I'm also willing to wipe this maching and start over again can choose a diffirent build if you have a suggestion i'm not a fan of suse anyyways
13:57
*machine
13:57
<alkisg>
!distro
13:57
<ltspbot`>
alkisg: Error: "distro" is not a valid command.
13:57
<alkisg>
!distribution
13:57
<ltspbot`>
alkisg: Error: "distribution" is not a valid command.
13:57
<alkisg>
Bah
13:58
<mymrhelpdesk>
lol
13:58
<alkisg>
:) anyway the topic says that ubuntu, debian and fedora have good implementations and opensuse has also a good implementation but uses kiwi
13:58
<mymrhelpdesk>
yeah anyways i'm not a great fan of opensuse linux
13:59
yeah i'm using a gigabyte ga-965-ds3 motherboard and for whatever reason ubuntu dosen't see my harddrive to install
13:59
is reason i tried opensuse
13:59
ubuntu was my first choice
14:00
<alkisg>
Try lspci to see the module, and search for it with "ubuntu" on google
14:00
Maybe you were just missing some firmware...
14:00
Or you didn't have a recent enough kernel, i don't know...
14:01
<mymrhelpdesk>
is weird i can leave the install environment and use qparted and see my hardware
14:01
<alkisg>
Well then install with the alternate cd
14:01
<mymrhelpdesk>
but ubuntu 10.10 install dosen't see it
14:01
yeah i tried cd and dvd installation and 64bit someone suggested
14:02
all acted the same
14:02
<alkisg>
The alternate cd is text-based, it doesn't have a graphical environment during the installation, did you try it?
14:02
It's actually the recommented way to install ubuntu/ltsp
14:03
<mymrhelpdesk>
no i'm not a brand new user to linux but my experiences are somewhat limited
14:03
<alkisg>
https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall
14:03
You just press "install an ltsp server" and it's ready
14:03
No need to manually call ltsp-build-client..
14:04
<mymrhelpdesk>
let me give it a try only thing cost me is time
14:04
thanks for your time
14:04
<alkisg>
np
14:05mymrhelpdesk has quit IRC
14:05vagrantc has joined #ltsp
14:05cliebow has joined #ltsp
14:16
<alkisg>
Hmmm or a set of match* functions could be provided, e.g. a configuration file could start with `match_hostname '*ltsp*' || return 0`... maybe that's too weird though
14:17
(/etc/grub.d/40_custom currently uses that)
14:17
<vagrantc>
if you want a really, really slow boot, you can use grub2 instead of pxelinux :)
14:19
<alkisg>
Really? Does it finally work?!
14:19
(pxe booting with grub...)
14:19
<vagrantc>
i tested it not too long ago ... unfortunately, the entire /etc/grub.d infrastructure doesn't work right
14:20
i also talked to the syslinux/pxelinux maintainer about implementing a .d infrastructure for pxelinux (already does so for extlinux)
14:21m4xx has joined #ltsp
14:21
<alkisg>
Where? Inside the tftp dir?
14:21
Or in /etc?
14:22
<vagrantc>
in /etc
14:22
<alkisg>
What would be configured there? Example?
14:23* alkisg would love it if tftpd-hpa provided a method to dynamically generate pxelinux.cfg/default from /etc/... :D
14:23
<vagrantc>
alkisg: same things you see in grub.d, only for network boot :)
14:24
<alkisg>
Ah, ok, that's good too, pxelinux.cfg/default wouldn't be dynamic but it would still be generated from /etc, nice
14:24
<vagrantc>
configuring a kernel, that sort of thing
14:25
basically, if done right, we could drop ltsp's configuration of pxelinux
14:25
<alkisg>
And just drop some files in /etc/pxelinux.d, good
14:25
<vagrantc>
something like that
15:00
<alkisg>
Is it possible to have both some VAR=value pairs _and_ LIKE statements in an lts.conf section? And, are multiple or recursive LIKE statements possible?
15:04
<vagrantc>
i've used LIKE statements with other values
15:04
in fact, that's where it's most useful
15:05
don't know how recurse it gets or if it handles multiple
15:07evil_root is now known as zz_evil_root
15:08Faithful has joined #ltsp
15:10
<alkisg>
The shell-daemon implementation is quite easy... the difficult part is finding a good structure for the /etc/ltsp/config.d directory :D
15:21johnny has left #ltsp
15:22
<Gadi_eeepc>
alkisg: why not have a config.d and a rules.d? config.d = static config, rules.d = rules applied after config.d values are loaded
15:23
<alkisg>
rules = scripts?
15:23
<Gadi_eeepc>
y
15:23Trixboxer has quit IRC
15:23
<alkisg>
I was just thinking about that... :)
15:23
And an "INCLUDE" directive in config.d files
15:23
(instead of LIKE)
15:24
<Gadi_eeepc>
either that or LIKE = foo just sources a file config.d/foo
15:24
<alkisg>
How would the initramfs know about the server certificates?
15:24
<Gadi_eeepc>
or some such
15:25
<alkisg>
Right, LIKE=foo sounds better, it's similar to how it is now
15:25
<Gadi_eeepc>
like you say, worry about that later
15:25
:)
15:25
<alkisg>
Well up to here it's very easy, I think I can do most of it tomorrow
15:26
It can even replace ldminfo (same port) in a compatible way...
15:26
(if the client doesn't send the RAM/CPU etc variables, then send the old info, else send the new)
15:27
<Gadi_eeepc>
well, i would make only mac required
15:28
we can add/subtract from all other values passed to the server
15:28
<alkisg>
Why not at least mac, ram and hostname?
15:28
So that config.d matching can be done?
15:28
<Gadi_eeepc>
config.d only needs mac to match
15:29
a central server may get two requests with the same IP
15:29
<alkisg>
there's also config.d/by-ip and config.d/by-hostname...
15:29
<Gadi_eeepc>
yeah, maybe
15:29
<alkisg>
Ooops sorry /me has to leave asap
15:29* Gadi_eeepc waves
15:29
<alkisg>
bbl, bye all, thansks for the feedback
15:29alkisg has quit IRC
15:29
<vagrantc>
alkisg: the daemon should also require some sort of variable name ... i.e. mac=$MAC ip=$IP passed on the commandline, so we don't have to worry about getting the order right
15:30
doh.
15:30
then it could add new values without breaking the old
15:52cliebow has quit IRC
16:21Kicer86 has quit IRC
16:23mymrhelpdesk has joined #ltsp
16:35m4xx has quit IRC
16:40mymrhelpdesk has quit IRC
16:59Gadi_eeepc has left #ltsp
17:00JohnB112 has joined #ltsp
17:14ogra has quit IRC
17:26ogra has joined #ltsp
17:27ogra is now known as Guest31934
18:07litlebuda has quit IRC
18:29Faithful has quit IRC
18:40Guest31934 is now known as ogry
18:40ogry is now known as ogra
18:40ogra has joined #ltsp
18:46mymrhelpdesk has joined #ltsp
18:47
<mymrhelpdesk>
ok anyone have any experience with ubuntu ltsp?
18:51
can anyone tell me why i get a cannot connect to nbd error on a client or usual reasons?
18:51shogunx has quit IRC
18:52shogunx has joined #ltsp
18:59
<mymrhelpdesk>
anyone around for some help?
19:00
<vagrantc>
!question
19:00
<ltspbot`>
vagrantc: "question" :: if you have a question about ltsp, please go ahead and ask it, and people will respond if they can. please also mention the linux distro and release you're using. :)
19:02
<mymrhelpdesk>
I already asked but I'll ask again I'm using Ubuntu 10.10 with LTSP prebuilt i have installed it and my clients seem to find server pull an ip attempts to load and i get an error cannot communicate to nbd server
19:02* vagrantc notes more information this time
19:02
<vagrantc>
also, have patience...
19:03
<mymrhelpdesk>
np
19:23JohnB112 has left #ltsp
19:26mymrhelpdesk has quit IRC
19:27mymrhelpdesk has joined #ltsp
19:58
<mymrhelpdesk>
hi i just installed ubuntu 10.10 and after ltsp-update-image -- arch i386 my client's can now login but now i have a very interesting thing happening my client logs in to a desktop that seems to be upsidedown and inverted somehow any help would be appreciated
20:03mymrhelpdesk has quit IRC
20:16mymrhelpdesk has joined #ltsp
20:39Faithful has joined #ltsp
21:37daya has joined #ltsp
21:48shogunx has quit IRC
21:54shogunx has joined #ltsp
22:29alkisg has joined #ltsp
22:32RiXtEr has joined #ltsp
22:56
<alkisg>
mymrhelpdesk: known bug with intel clients + nvidia drivers on the server
22:56
Either uninstall the nvidia drivers from the server, or disable compiz on the server (so that users don't have compiz)
22:56
!compiz
22:56
<ltspbot`>
alkisg: "compiz" :: the default window manager in gnome is gnome-wm, which automatically chooses compiz if it thinks that the card supports it. Compiz is causing login problems to some clients (LP #673072). To disable it, see !disable_compiz. To restore it, see !restore_compiz
22:56
<alkisg>
!disable_compiz
22:56
<ltspbot`>
alkisg: "disable_compiz" :: To disable compiz, try: sudo gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type string --set /desktop/gnome/session/required_components/windowmanager metacity
22:57
<alkisg>
vagrantc: the client would send MAC value and IP value pairs in separate lines, so the server would read them in a `read var value` loop...
22:58
<vagrantc>
alkisg: i think it would be better if the order didn't matter
22:58
<alkisg>
The order doesn't matter, the loop can process them in any order
22:58
<vagrantc>
how's that?
22:59
<alkisg>
while read var value; do
22:59
eval var=value etc
22:59
<vagrantc>
it indicates on the same line somehow what type of value it is?
22:59
<alkisg>
i.e. read all the input until EOF
22:59
If var=mac, then the mac variable is set
23:00
So that loop sets the MAC, IP, HOSTNAME etc variables in whatever order the client sends them
23:00
And if the client sends more, it sets more variables...
23:00
<vagrantc>
so the client can send any variable and it gets set server-side?
23:00Faithful has quit IRC
23:00
<alkisg>
Right (unless if we don't want that)
23:01
<vagrantc>
that sounds exploitable somehow...
23:01
<alkisg>
We can prevent stuff like PATH, or we can restrict them to only MAC/IP/HOST etc
23:02
while read var value; do case "$var" in MAC) MAC="$value"...
23:02
So with a case there we can restrict them to only known vars
23:02
<vagrantc>
right
23:02
seems a little safer ...
23:03
<alkisg>
Do the /etc/ltsp/config.d and /etc/ltsp/rules.d paths sound OK? With by-ip / by-mac / by-host subdirs?
23:03
And % standing for wildcard?
23:03
<vagrantc>
it runs as what user?
23:04
<alkisg>
If nobody can get all the necessary server info, then nobody...
23:04
ldminfod runs as nobody, so that should do it
23:04
<vagrantc>
heh
23:05
<alkisg>
And I can reimplement ldminfod in a shell script so that we only have 1 daemon (with backwards compatibility, if the client doesn't send a mac/ip/hostname then it only answers the old-styl ldminfod output)
23:05
<vagrantc>
this is actualyl very similar to the direction lessdisks was going when i ditched it
23:05
<alkisg>
:)
23:05
<vagrantc>
although it was still client-side
23:06
<alkisg>
The objective is to have the configuration in /etc without needing a web server
23:06
and to also allow shell scripts for the configuration
23:06
<vagrantc>
in the server's /etc
23:06
<alkisg>
Yup
23:06
I'll implement a draft tomorrow and send it to the ML...
23:09
rules.d == scripts, config.d == simple VAR=value text files. Since packages can drop their configuration in rules.d, I"m not sure if config.d is needed or if a single file like lts.conf can be used for the sysadmin...
23:09
<vagrantc>
why have a distinction?
23:09
<alkisg>
To make it easier for admins that don't know bash
23:10
<vagrantc>
but they don't have to use it
23:10
there's no technical difference in the implementation, it's just to separate the two uses?
23:11
<alkisg>
The scripts would be sourced, and the text files would be "parsed"
23:11
E.g. for LIKE=statements
23:11
<vagrantc>
oh, there would be technical differences...
23:11
<alkisg>
But I just thought of another way, dumping `set` in the end of the sourcing of the scripts...
23:12
So maybe it's doable without distinction...
23:12
If a file contains X_COLORDEPTH=16, then sourcing it is not enough, we'd have to "echo" it
23:12
...and the user can't really use `echo X_COLORDEPTH=16`
23:12
...and cat <<EOF in the beginning of a config file would seem strange,
23:13
...but I just thought that we can just dump `set` at the end of the sourcing, while removing some vars like "PATH, PS1" etc
23:13
Yup, maybe that's the best way
23:13
...and it ensures that no code is sent to the client
23:14
<vagrantc>
might be a little hairy
23:15
<alkisg>
Or "for var in all_possible_lts_conf_entries; if isset $var; echo it"
23:15
That "all_possible_lts_conf" would need a lot of digging though :D
23:15
<vagrantc>
egads
23:15
<alkisg>
...but it would help in maintaining a good documentation of lts.conf :P
23:16
<vagrantc>
server-side, i don't think we need to worry about people hacking the files ... if they can edit /etc/* that's not ltsp's problem ...
23:17
it's more sanitizing the input one can send via inetd i would worry about
23:17RiXtEr has quit IRC
23:18RiXtEr has joined #ltsp
23:18
<alkisg>
I think bash has some functions to save/restore variables
23:19
If we use #!/bin/bash, then we can use those for the "tranfer"
23:19
*transfer
23:20
(it quotes the values so that they're sourcable later)
23:22zz_evil_root has quit IRC
23:31
<alkisg>
Ah, there can never be a complete list of all possible lts.conf variables because sound vars depend on the soundcard controls names
23:32
So it would either have to be like /etc/grub.d/40_custom does it, exec tail -n +3 $0, (or cat <<EOF), or rules.d / config.d...
23:37johnny has joined #ltsp
23:43Faithful has joined #ltsp
23:43
<alkisg>
Ouch. Only 500 `getltscfg -a` can be executed on my intel core2duo per second...
23:46
Heh, and only 37 ldminfod, so np :D
23:47
So the server can just source scripts in rules.d and execute getltscfg -a on the existing lts.conf, done
23:47
<vagrantc>
this is, of course, going to require splitting out an ltsp-common package
23:47
and also make architecture-dependent stuff server-side.
23:48
<alkisg>
Ooops
23:48* alkisg will check how fast a bash implementation of getltscfg would be...
23:48
<vagrantc>
heh
23:49
i remember trying to re-write it in bash
23:49
<alkisg>
How did that go?
23:49
<vagrantc>
it was much slower
23:49
<alkisg>
Did you use case for wildcard matching?
23:49
<vagrantc>
i didn't even do anything fancy like wildcard matching
23:49
<alkisg>
Urm
23:50
<vagrantc>
but who knows, maybe you'd do a lot better :)
23:50Faithful has quit IRC