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


Channel log from 20 March 2010   (all times are UTC)

00:56alkisg has quit IRC
01:07alkisg has joined #ltsp
01:58FGXR6 has quit IRC
02:16FGXR6 has joined #ltsp
02:45FGXR6 has quit IRC
02:49cyberorg has quit IRC
03:02FGXR6 has joined #ltsp
03:18cyberorg has joined #ltsp
03:30FGXR6 has quit IRC
03:32bobby_C has joined #ltsp
03:46FGXR6 has joined #ltsp
04:01otavio has quit IRC
04:21FGXR6 has quit IRC
04:39FGXR6 has joined #ltsp
04:55mikkel has joined #ltsp
05:10kusznir has quit IRC
05:12kusznir has joined #ltsp
05:24otavio has joined #ltsp
05:50bobby_C has quit IRC
05:58hersonls has joined #ltsp
06:21alkisg has quit IRC
06:23FGXR6 has quit IRC
06:31ogra has quit IRC
06:34ogra has joined #ltsp
06:40alkisg has joined #ltsp
06:40FGXR6 has joined #ltsp
06:43abeehc has quit IRC
06:45abeehc has joined #ltsp
07:33leio has quit IRC
07:34leio has joined #ltsp
07:42alkisg has quit IRC
08:28pmatulis has joined #ltsp
08:47litlebuda has joined #ltsp
08:48bobby_C has joined #ltsp
09:28moldy has joined #ltsp
09:29hersonls has quit IRC
09:31Ctek has joined #ltsp
09:34hersonls has joined #ltsp
09:35
<Ctek>
Hy guys, has anyone used Easy-LTSP on ubuntu ?
09:38ogra_cmpc has quit IRC
09:39ogra_cmpc has joined #ltsp
10:38alkisg has joined #ltsp
10:46pmatulis has quit IRC
10:53slidesinger has joined #ltsp
10:58vagrantc has joined #ltsp
10:59alkisg has quit IRC
11:00slidesinger has quit IRC
11:01alkisg has joined #ltsp
11:28bobby_C has quit IRC
11:37ogra_cmpc has quit IRC
11:38ogra_cmpc has joined #ltsp
11:44nubae_ has joined #ltsp
11:45nubae has quit IRC
11:49zirconiumks has joined #ltsp
11:53plasticdoc has joined #ltsp
11:58
<plasticdoc>
Could someone, please, point me to documentation about the lts.conf options? Were there any changes in the latest 5.2?
12:02
<alkisg>
!lts.conf
12:02
<ltspbot`>
alkisg: "lts.conf" :: http://manpages.ubuntu.com/lts.conf
12:02
<alkisg>
plasticdoc: many, many options are undocumented...
12:02
So yes, there were changes for 5.2, but the only way to be sure would be to read the sources :)
12:08
<johnny>
perhaps we have too many..
12:09
<alkisg>
The worst thing is that we have them in a single file... we must make it http based asap
12:09
(reuse cluster code or merge the two methods in a new one or something...)
12:11
<vagrantc>
bah
12:12
the insistance on "worst" and "must" is wearisome :P
12:12
<alkisg>
Excuse my lack in english, but we can't even make a proper GUI now
12:12
<vagrantc>
?
12:13
<alkisg>
Given an lts.conf, it's really difficult to parse it and then save it properly
12:13
<vagrantc>
ah, i see what you mean
12:14
it is a very standard configuration file format... there must be tools to parse that sort of thing.
12:14
<alkisg>
I've been trying with python's ConfigParser, but it doesn't help...
12:15
We "should" ;) allow for an lts.conf.d/ directory, where vendors/packages/sysadmins could drop files there...
12:18
<vagrantc>
i'm generally fond of .d directories ... almost to a fault :)
12:18
<alkisg>
(and not only configuration files, but code as well - if client_ram < xxx then param123=yyy...)
12:18
<vagrantc>
alkisg: well, we've got ltsp_config.d ... that should handle code-side.
12:18
<alkisg>
That's on the client, not on the server
12:18
<vagrantc>
ah, back to this thing :)
12:19
<alkisg>
It can't decide what username to send based on ip/time/class...
12:19
<vagrantc>
but it could be a plugin that asks the server
12:21
<alkisg>
Indeed, a plugin could send some information to the server and get some configuration values
12:21
But that plugin would offer more than lts.conf itself, so it could just replace it completely...
12:22
<vagrantc>
why bother replacing it?
12:22
that's the part i just don't get.
12:22
we already have the infrastructure to make it unecessary... to force it to disappear seems gratuitous
12:23
<alkisg>
What's the point of supporting html 3 when html 5 is out?
12:24
Given the right tools, ltsp.conf.d, GUI editing etc, why would we need to keep supporting the old lts.conf syntax, and depend on bison/flex etc?
12:24
<vagrantc>
what's the point of dropping support?
12:24
the code has barely needed changes for some 10 years now... it's not like it's a high-maintenance piece of code.
12:25
<alkisg>
Anyway my point is not in dropping support or not - it's that we need some additional functionality
12:25
<vagrantc>
sure
12:25
:)
12:32hersonls has quit IRC
12:34hersonls has joined #ltsp
12:42Egyptian[Home]1 has joined #ltsp
12:42Egyptian[Home]1 has left #ltsp
13:00ludug3r0 has joined #ltsp
13:06wwx_ has joined #ltsp
13:08wwx has quit IRC
13:14
<alkisg>
vagrantc, about ltsp_config.d, shouldn't that dir be created by ltsp-client-core?
13:17ogra_cmpc has quit IRC
13:24
<vagrantc>
alkisg: only if it puts something in there by default...
13:24
<alkisg>
Couldn't it be in debian/dirs?
13:24
<vagrantc>
alkisg: why do you even need it?
13:25
<alkisg>
For example, to provide some side-wide defaults
13:25
<vagrantc>
packages that need to put something in there will create it ... admins can create it
13:25
<alkisg>
E.g. LDM_DIRECTX=${LDM_DIRECTX:-True}
13:25
<vagrantc>
yes, i understand how to use it :)
13:25
<alkisg>
Heh, yeah, I'm the one that tries to understand here :)
13:26
<vagrantc>
although admins should really be creating custom ones in /etc/ltsp/ltsp_config.d, though i didn't add support for that (yet)
13:27
<alkisg>
vagrantc: so, for example, could I move there some upstream code to provide some defaults for fat clients?
13:27
(move the existing code from ltsp_config, that is...)
13:27
<vagrantc>
sure
13:27
<alkisg>
E.g. if LTSP_FATCLiENT then LOCALDEV=False...
13:27
OK, thanks
13:28
<vagrantc>
i was tempted to split ltsp_config into snippets in ltsp_config.d ... but i resisted the change just to keep it minimal
13:29
<alkisg>
It would be better imho - e.g. we could provide an "ltsp-fat-client" package that way, which could be added/removed at anytime, not only on ltsp-build-client...
13:29
<vagrantc>
yes, that sounds like a much better way to handle it
13:30
then you get dependency resolution for package dependencies, which is much easier than hard-coding it in the plugins and such
13:30ogra_cmpc has joined #ltsp
13:32Egyptian[Home]1 has joined #ltsp
13:34Egyptian[Home]1 has quit IRC
13:34Egyptian[LapTop] has joined #ltsp
13:36nubae has joined #ltsp
13:37nubae_ has quit IRC
13:47zirconiumks has quit IRC
13:49
<plasticdoc>
Do you know if in LTSP 5.2 we still do need to use X_RAMPERC=80 to avoid the Firefox/Openoffice "Pixmap caching" bug?
13:49pmatulis has joined #ltsp
13:51
<vagrantc>
plasticdoc: it's not so much LTSP but the firefox or openoffice versions
13:52
<plasticdoc>
vagrantc: sorry? I did not understand what you meant.
13:53
<vagrantc>
plasticdoc: it is bugs in firefox or openoffice that make setting X_RAMPERC necessary, so the versions of those is what matters, not the version of LTSP
13:54
<plasticdoc>
vagrantc: Oh, I see. Thank you.
13:54
<vagrantc>
haven't heard recent noise about the issue, so hopefully it's at least partially resolved in recent versions
13:54
<plasticdoc>
vagrantc: I am just trying to get rid of lots of config tweaks that linger around my lts.conf files
13:55
<vagrantc>
plasticdoc: nothing like testing to verify for sure
13:55
<plasticdoc>
vagrantc: I am very afraid to upset my users and delete those lines, just to discover latter that they are still needed.
13:56
<vagrantc>
plasticdoc: so, configure one machine to not use it and test it
13:56
or leave it in :)
13:58ludug3r0 has quit IRC
13:59
<plasticdoc>
vagrantc: ...configure one machine... I have it in the [default] section. To change I will have to create lots of [aa:bb:cc:dd:ee:ff] LIKE = SomeOldSettingsMachine.
14:00
vagrantc: but I will give it a try.
14:00
vagrantc: Thank you.
14:01
<vagrantc>
plasticdoc: you can do the other way around ... just configure one machine with X_RAMPERC=100
14:02php_szg has joined #ltsp
14:06ogra_cmpc has quit IRC
14:08ogra_cmpc has joined #ltsp
14:10
<plasticdoc>
vagrantc: X_RAMPERC=100 ? Will it work like that?
14:11
<vagrantc>
plasticdoc: that's what i'm trying to tell you :P
14:13
<plasticdoc>
vagrantc: After all it seems that there is an easy way... I will try that with a few users and see if they start reporting problems. Thank you.
14:14
<php_szg>
hi folks, I'm a little confused about LTSP's boot process; the subnet I want (and right now, have) to use is behind NAT.
14:15
there are 2 DHCP servers running there, I have access only to one of those
14:15
I have only dumb switches
14:16
what I'm confused about is the behavior of the 2 DHCP requests
14:17
both servers respond to PXE queries, but my client always boots (w/PXE) from the "right" one and always gets an IP from the another during bootup
14:18
of course, it boots fine if I unplug my uplink connection
14:20
I'm just trying to come up with a solution to this issue. Is there any way to set a static IP as the server address
14:21
so the client can connect to the "right" box and won't bail out to an initramfs prompt?
14:22
<vagrantc>
php_szg: i have to run soon, but you'll probably want to use IPAPPEND in your pxelinux.cfg/default menu
14:22
alkisg is the master of IPAPPEND
14:22
<php_szg>
vagrantc: thanks; I'll check that
14:25
<alkisg>
php_szg: why do you have 2 dhcp servers?
14:25
If one of them is the ltsp server, you'd better just turn it off
14:25
Or, isolate it to a separate subnet
14:26Egyptian[LapTop1 has joined #ltsp
14:27ogra_cmpc has quit IRC
14:27johnny has left #ltsp
14:28Egyptian[LapTop] has quit IRC
14:28johnny has joined #ltsp
14:28Egyptian[LapTop] has joined #ltsp
14:28ogra_cmpc has joined #ltsp
14:33Egyptian[LapTop1 has quit IRC
14:34
<moldy>
alkisg: hi
14:35
(a
14:35
oops :)
14:35
<alkisg>
Hi moldy :)
14:35
<moldy>
alkisg: about your question in #lns: yes, we have been thinking about doing this
14:35
<alkisg>
Did you find any good way?
14:36
(for the server to send commands to the clients...)
14:36
<moldy>
i haven't really put any research into this yet
14:36
i did experiment with a helper daemon running inside the user session at some point
14:37plasticdoc has left #ltsp
14:37
<moldy>
alkisg: but if you just want to run some command like firefox in the user session, we have a working implementation for that
14:38
alkisg: right now, it only works for gnome sessions, though
14:38
<alkisg>
moldy: but it only works for thin clients, right?
14:38
I.e. it wouldn't work for fat clients...
14:39
<moldy>
alkisg: right
14:39
alkisg: for fat client, you would use ssh, i guess
14:39
<alkisg>
I'd prefer something like (from the client): ssh <use-control-socket> server command-listener | command-executioner
14:40
Currently I'm installing openssh-server on the thin/fat clients, but it's not a good approach...
14:40
I'd like to use reverse connections instead, the clients should connect to the server
14:41vagrantc has quit IRC
14:41
<alkisg>
I've been looking at socat, xmlrpc, ssh -R, gabriel and other alternatives, but I'm not sure what's the best solution here
14:41
(I'd also like it to be extra slim, to keep the thin client requirements low)
14:46
<php_szg>
alkisg: I have access to only one of those. Provided that I'm the only one using the whole infrastructure, "ipappend 1" turned out to be a painless and fast solution :)
14:48plasticdoc has joined #ltsp
14:49din_os has joined #ltsp
14:50Egyptian[LapTop1 has joined #ltsp
14:52moldy has quit IRC
14:54Egyptian[LapTop] has quit IRC
14:57php_szg has quit IRC
15:13Selveste1 has joined #ltsp
15:22vagrantc has joined #ltsp
15:26wwx_ has quit IRC
15:26wwx has joined #ltsp
15:30plasticdoc has quit IRC
15:31Selveste1 has quit IRC
15:40bobby_C has joined #ltsp
15:44mordocai has joined #ltsp
15:45Selveste1 has joined #ltsp
15:56alexqwesa__ has quit IRC
15:57alexqwesa has joined #ltsp
15:57pths has quit IRC
15:58pths has joined #ltsp
16:13mordocai has quit IRC
16:20Egyptian[LapTop1 is now known as Egyptian[Laptop]
16:26ogra_cmpc has quit IRC
16:27epaphus has joined #ltsp
16:27ogra_cmpc has joined #ltsp
16:48pmatulis has quit IRC
16:52bobby_C has quit IRC
16:58moldy has joined #ltsp
16:58
<moldy>
hi
16:59
alkisg: hi again. sorry, the box that runs my irc client got into trouble.
16:59
<alkisg>
np
16:59
<moldy>
alkisg: alkisg i don't have irc logs, can you repeat your last 2 or so messages? :)
17:01
<alkisg>
moldy: http://paste.ubuntu.com/398488/
17:04Lumiere has quit IRC
17:04Lumiere has joined #ltsp
17:05epaphus has quit IRC
17:09nubae_ has joined #ltsp
17:10nubae has quit IRC
17:17
<moldy>
alkisg: thanks. ssh <use-control-socket> server command-listener | command-executioner <-- that sounds good to me
17:17
alkisg: i talked to yanqui about xmlrpc over ssl, but i would prefer to use ssh if possible
17:18
<alkisg>
moldy: that's what I'd like too, but I haven't sorted out the redirections yet
17:18
<moldy>
but well, tcm development is more or less stalled at the moment, anyway
17:18
<alkisg>
It doesn't matter, if we find a good way I could implement it and then you could copy the code whenever you continue with tcm
17:18
<moldy>
yanqui is very busy, and it's not much different with me
17:18
yup, that would be nice
17:19
<alkisg>
The problem is that the | operator is one-way
17:20
So I probably need to code it in some programming language for a 2 way communication, so that the server not only sends commands, but it also receives the output
17:20
E.g. echo hostname
17:20
read output ==> the client hostname
17:20
echo whoami
17:20
read output ==> the user, etc
17:20
I've currently implemented this with openbsd-inet and with nc on the client, but I'd like to use the ssh channel instead of nc
17:22moldy has quit IRC
17:22moldy_ has joined #ltsp
17:22moldy_ is now known as moldy
17:22
<moldy>
grmbl
17:22
<alkisg>
Heh
17:22
<moldy>
this box is having routing trouble... stupid hoster uses broken dhcp
17:23
<alkisg>
http://alkisg.pastebin.com/2JarZyHC
17:24
<moldy>
thx. yep, yep.
17:25
i might be on-and-off another 2 times or so :)
17:31moldy has quit IRC
17:31moldy has joined #ltsp
17:52hersonls has quit IRC
17:54alkisg has quit IRC
18:10
<Ctek>
If i move the image created from the LTSP server to a machine with just PXE and share the image via FTP will it work ?
18:11
I mean i only use the ltsp server to create the image and then use another machine to serv the pxe image and the client image via shares or ftp
18:12shamino_ has joined #ltsp
18:12abeehc_ has joined #ltsp
18:12|Ryan52 has joined #ltsp
18:12
<johnny>
huh
18:12
you can move the tftp image to another server sure
18:12
but is there a reason you want to do that?
18:13
why not just point your dhcp server at your ltsp machine? or are you already running a tftp server on that machine?
18:13
Ctek, ^
18:13
<Ctek>
yes... to use just one machine
18:13
<johnny>
huh?
18:13
do you already have a tftp server?
18:13Ryan52 has quit IRC
18:13
<Ctek>
yes, and a ldap and samba DC
18:13|Ryan52 is now known as Ryan52
18:13
<johnny>
you can't serve ltsp from windows
18:14
<Ctek>
the machine is linux
18:14
<johnny>
you can't serve anything ltsp related on shares for regular ftp
18:14
<Ctek>
I use ebox from ebox-platform
18:14
<johnny>
not sure why you would imagine you could
18:14
<Ctek>
hm...
18:14
<johnny>
sorry.. that's impossible unless they have an ltsp 5 package
18:14
in which case you would just install ltsp 5 on that server
18:15
<Ctek>
i'm afraid that if i install the ltsp server into the ebox server (most likely) i'll broke it
18:15
<johnny>
you can certainly serve the tftp files from that server
18:15
i would recommend against it
18:15
as then you would have to install a gui on the server too
18:15
<Ctek>
i wanted to do something like so on a image and authenticate against the ebox ldap and use the roaming profiles ...
18:16
<johnny>
you can still do auth via ldap and roaming profiles
18:16
but really ltsp is roaming
18:16
already
18:16
if you wanted to
18:16
but sure.. you could use ltsp cluster perhaps
18:16
<Ctek>
hm, i see what you say...
18:16
<johnny>
check out ltsp-cluster.org
18:16abeehc has quit IRC
18:16shamino has quit IRC
18:16jcastro has quit IRC
18:17
<Ctek>
i think that i'll do a custom image of "damn small linux" integrated into my domain and serv it via pxe
18:18
my need was to just "shove" the so to the fat clients and use the ebox as DC + profiles... but i think it dosen't work like i wanted :D
18:20
Anyway thank you for the advices and i'll keep on reading maybe i reach my goal afterall
18:24jcastro has joined #ltsp
18:31plasticdoc has joined #ltsp
18:36FGXR6 has quit IRC
18:39
<plasticdoc>
stgraber: could you point me to an howto or something like that, on how to SSH log into the main server from a thin client, and perform all the admin activities like if I were at the server keyboard & screen (i.e., at the real server, not the thin client chrooted environment)?
18:40
<vagrantc>
plasticdoc: that's the normal behavior of LTSP.
18:40
plasticdoc: you're usually logged into the server, the thin client is just a monitor/keyboard/mouse essentially.
18:45Egyptian[Home] has quit IRC
18:45Egyptian[Laptop] has quit IRC
18:46
<vagrantc>
stgraber: i just uploaded ltsp-docs to debian/sid ... you might want to pull it if you can still
18:46
<plasticdoc>
vagrantc: You mean: if I am an user listed at admin in the server's /etc/group file, if I issue an sudo aptitude update; sudo aptitude install some_program, I will be doing that at the server and not inside the chrooted env?
18:47
<moldy>
plasticdoc: exactly
18:47
plasticdoc: once you logged in, all programs you run run on the server
18:50
<vagrantc>
plasticdoc: sounds like you've got it. :)
18:51
<plasticdoc>
moldy: You mean that I may admin/update/install/uninstall from any thin client terminal, and not at the server room at the server's screen/keyboard/mouse?
18:51
<moldy>
plasticdoc: yes
18:51
<vagrantc>
yes :)
18:52
<moldy>
plasticdoc: if you want to run stuff on the client, then you need to do something "special". the normal case is that everything runs on the server.
18:53FGXR6 has joined #ltsp
18:54
<plasticdoc>
If I told you that I am successfully administering a rather complex LTSP for almost 3 years, and suffering with a rather noisy pair of high availability servers each time I need to upgrade/install/remove software... WOULD YOU BELIEVE?
18:55
<vagrantc>
heh
18:55
<plasticdoc>
:'(
18:56
<vagrantc>
the suffering ends here :)
18:56
welcome to one of the best features of LTSP.
18:56
<plasticdoc>
Am I happy!
18:59
But wait, I am sure that there are apps, right now I remember OpenBravo (Java based), that if you install/reconfigure from a terminal it will be jammed and not work anymore.
19:00
Are there any known problems with Java Tomcat served apps that you know of?
19:09
vagrantc: One other rather annoying problem are the exact ports that one must keep open in order to feed the thin clients and keep them happy. Could you, please, point me to credible info on what is really needed in LTSP 5.2? Is it 22, 53, 69 (or is it 67-69?), 137-139, 445, 514, 9571-9572, 9100?
19:10pmatulis has joined #ltsp
19:10
<vagrantc>
ltsp5 with ldm uses port 22 for sure. 9571-9572 are used for ldminfod and maybe nbdswapd? 2000 is used for NBD images on ubuntu, at least. don't remember what ports NFS uses, but some distros (debian) still use NFS by default.
19:11
<moldy>
53 is dns, iirc
19:12
so you only need to keep that open if your server is the dns server for your network
19:12
137-139 and 445 are smb/cifs/samba
19:19din_os has quit IRC
19:19
<plasticdoc>
moldy: do we still need 137-139 and 445, even if we do not have anything windows/MSFT at our network?
19:20Selveste1 has quit IRC
19:21
<plasticdoc>
What about 69/tcp tftp, 67/udp, 68/udp for dhcp?
20:04plasticdoc has left #ltsp
20:04shawnp0wers has joined #ltsp
20:04litlebuda has quit IRC
20:05plasticdoc has joined #ltsp
20:08plasticdoc has left #ltsp
20:13shawnp0wers has quit IRC
20:23mikkel has quit IRC
20:50pmatulis has quit IRC
21:01
<moldy>
plasticdoc: no, you don't need 137-139 and 445 unless you do samba
21:08Ctek has quit IRC
22:40weenus has joined #ltsp
22:47weenus has left #ltsp
23:03vagrantc has quit IRC
23:06vagrantc has joined #ltsp
23:11vagrantc has quit IRC
23:22vagrantc has joined #ltsp
23:33vagrantc has quit IRC
23:33vagrantc has joined #ltsp
23:41alkisg has joined #ltsp
23:56vagrantc has quit IRC