IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 27 December 2010 (all times are UTC)
| 00:08 | JohnB112 has quit IRC | |
| 01:02 | MorningSon has quit IRC | |
| 01:41 | alkisg has joined #ltsp | |
| 01:54 | Mava has joined #ltsp | |
| 02:41 | vagrantc has quit IRC | |
| 03:15 | Guest44117 has joined #ltsp | |
| 03:15 | Guest44117 is now known as ogra | |
| 03:15 | ogra has joined #ltsp | |
| 04:30 | artista_frustrad has joined #ltsp | |
| 04:42 | johnny has left #ltsp | |
| 04:42 | johnny has joined #ltsp | |
| 04:54 | ponny_ has joined #ltsp | |
| 05:07 | daya has quit IRC | |
| 05:15 | johnny has left #ltsp | |
| 05:16 | johnny has joined #ltsp | |
| 05:36 | alkisg has quit IRC | |
| 05:42 | Kicer86 has joined #ltsp | |
| 05:49 | artista_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:54 | zz_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:11 | evil_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:15 | johnny has left #ltsp | |
| 07:15 | johnny has joined #ltsp | |
| 07:19 | <Appiah> is it installed as a localapp ponny_ ?
| |
| 07:22 | Kicer86 has quit IRC | |
| 07:22 | sutula has quit IRC | |
| 07:26 | Kicer86 has joined #ltsp | |
| 07:26 | sutula 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:33 | m4xx has quit IRC | |
| 07:52 | Hyperbyte has quit IRC | |
| 08:01 | alkisg has joined #ltsp | |
| 08:07 | rjune has quit IRC | |
| 08:15 | alkisg has quit IRC | |
| 08:17 | Faithful has joined #ltsp | |
| 08:21 | alkisg has joined #ltsp | |
| 08:38 | alkisg has quit IRC | |
| 08:38 | alkisg has joined #ltsp | |
| 08:40 | Gadi has joined #ltsp | |
| 08:46 | [GuS] has joined #ltsp | |
| 08:56 | cliebow has joined #ltsp | |
| 09:12 | _UsUrPeR_ has quit IRC | |
| 09:13 | _UsUrPeR_ has joined #ltsp | |
| 09:31 | JohnB112 has joined #ltsp | |
| 09:33 | JohnB112 has left #ltsp | |
| 09:34 | litlebuda has joined #ltsp | |
| 09:35 | zz_evil_root is now known as evil_root | |
| 10:22 | johnny has left #ltsp | |
| 10:22 | johnny has joined #ltsp | |
| 10:34 | Faithful has quit IRC | |
| 10:48 | Gadi has left #ltsp | |
| 10:51 | otavio has joined #ltsp | |
| 10:51 | otavio has joined #ltsp | |
| 12:02 | Trixboxer has joined #ltsp | |
| 12:04 | MorningSon has joined #ltsp | |
| 12:18 | Kicer86 has quit IRC | |
| 12:18 | sutula has quit IRC | |
| 12:47 | vagrantc has joined #ltsp | |
| 12:57 | cliebow has quit IRC | |
| 13:01 | Kicer86 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:03 | sutula 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:04 | otavio 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:24 | Gadi_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:52 | mymrhelpdesk 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:55 | vagrantc 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:05 | mymrhelpdesk has quit IRC | |
| 14:05 | vagrantc has joined #ltsp | |
| 14:05 | cliebow 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:21 | m4xx 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:07 | evil_root is now known as zz_evil_root | |
| 15:08 | Faithful 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:21 | johnny 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:23 | Trixboxer 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:29 | alkisg 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:52 | cliebow has quit IRC | |
| 16:21 | Kicer86 has quit IRC | |
| 16:23 | mymrhelpdesk has joined #ltsp | |
| 16:35 | m4xx has quit IRC | |
| 16:40 | mymrhelpdesk has quit IRC | |
| 16:59 | Gadi_eeepc has left #ltsp | |
| 17:00 | JohnB112 has joined #ltsp | |
| 17:14 | ogra has quit IRC | |
| 17:26 | ogra has joined #ltsp | |
| 17:27 | ogra is now known as Guest31934 | |
| 18:07 | litlebuda has quit IRC | |
| 18:29 | Faithful has quit IRC | |
| 18:40 | Guest31934 is now known as ogry | |
| 18:40 | ogry is now known as ogra | |
| 18:40 | ogra has joined #ltsp | |
| 18:46 | mymrhelpdesk 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:51 | shogunx has quit IRC | |
| 18:52 | shogunx 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:23 | JohnB112 has left #ltsp | |
| 19:26 | mymrhelpdesk has quit IRC | |
| 19:27 | mymrhelpdesk 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:03 | mymrhelpdesk has quit IRC | |
| 20:16 | mymrhelpdesk has joined #ltsp | |
| 20:39 | Faithful has joined #ltsp | |
| 21:37 | daya has joined #ltsp | |
| 21:48 | shogunx has quit IRC | |
| 21:54 | shogunx has joined #ltsp | |
| 22:29 | alkisg has joined #ltsp | |
| 22:32 | RiXtEr 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:00 | Faithful 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:17 | RiXtEr has quit IRC | |
| 23:18 | RiXtEr 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:22 | zz_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:37 | johnny has joined #ltsp | |
| 23:43 | Faithful 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:50 | Faithful has quit IRC | |