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


Channel log from 26 February 2013   (all times are UTC)

00:17Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
00:31anunnaki has left IRC (anunnaki!~anunnaki@174.55.35.255, Read error: Connection reset by peer)
00:35anunnaki has joined IRC (anunnaki!~anunnaki@174.55.35.255)
00:42Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
00:55
<warren>
sbalneav: where is ${PAM_SSHAUTH_DIR} typically located?
01:12gentgeen__ has left IRC (gentgeen__!~kevin@c-98-236-71-64.hsd1.pa.comcast.net, Remote host closed the connection)
01:23Parker955_Away is now known as Parker955
01:51anunnaki has left IRC (anunnaki!~anunnaki@174.55.35.255, Read error: Connection reset by peer)
01:54anunnaki has joined IRC (anunnaki!~anunnaki@c-174-55-35-255.hsd1.pa.comcast.net)
01:55vicd has joined IRC (vicd!~user@212.49.98.98)
02:04anunnaki has left IRC (anunnaki!~anunnaki@c-174-55-35-255.hsd1.pa.comcast.net, Read error: Connection reset by peer)
02:05anunnaki has joined IRC (anunnaki!~anunnaki@174.55.35.255)
02:20monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 256 seconds)
02:25adrianorg_ has left IRC (adrianorg_!~adrianorg@177.156.59.36, Ping timeout: 276 seconds)
02:32monteslu has joined IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net)
03:05shawnp0wers has left IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers, Remote host closed the connection)
03:27
<sbalneav>
warren: /tmp
03:28
<warren>
sbalneav: waitfor for a socket sounds like a classic race condition vulnerability
03:28
<sbalneav>
How so?
03:28
<warren>
sbalneav: but that wouldn't be our worst security issue...
03:28
normally I'd say "any user can write to /tmp" but if you have other users on your client, you have bigger problems
03:28
<sbalneav>
If I'm going to block until I see it, or a timeout of 20 seconds
03:29
<warren>
sbalneav: something of the expected name can appear, when it isn't what you expect
03:29
<sbalneav>
That's what the timeout's for :)
03:29
and it creates a 600 directory in /tmp
03:29highvoltage has joined IRC (highvoltage!~highvolta@ubuntu/member/highvoltage)
03:29
<sbalneav>
socket's underneath that.
03:30
so, unless you've got root on the workstationm should be ok. each user dir is created with mktmpnam, so it's userid.XXXXX
03:31
So we should even be able to handle multiple logins on a workstation (i.e. dm's on vt7, vt8, vt9...)
03:31
<warren>
nevermind
03:31
you're right
03:33
<sbalneav>
Playing around, or just looking at the code? How's it looking so far?
03:34
<warren>
sbalneav: i'm really stressed out and looked at a random URL in IRC
03:34
<sbalneav>
Anything I can do to help?
03:35
<warren>
not really
03:35
unless you know US patent law
03:39
<sbalneav>
Are you applying for a patent? Or has someone accused you of violating one?
03:45
<warren>
sbalneav: thesis
03:45
sbalneav: I have two patents, both bad
03:46
sbalneav: I dare you to infringe it. It's impossible.
03:48
<sbalneav>
Impossible to infringe on a patent? ... One supposes it can be done. If, say, one patents time travel, or the like :)
03:49
My knowledge of patents is directly proportional to the number that I own.
03:49
Currently zero :)
03:50
<warren>
sbalneav: somehow the zero is in a denominator here
03:50
kaboom
03:50
<sbalneav>
Well, I think 0/0 is specially defined to be zero :)
03:51
Oop! No, it's "indeterminite"
03:52
So my knowledge of patents is indeterminite. Although I can't determine it, it feels rather close to zero.
03:53
So lim(Scott's knowledge of patents -> 0/0) = 0
03:53
I could get a job at XKCD with these math jokes.
03:57
<warren>
XKCD pays /0
04:03alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
04:04* alkisg waves
04:07
<jammcq>
sbalneav: Scotty !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
04:07seamuz has left IRC (seamuz!~seamus@89.237.49.94, Quit: Lost terminal)
04:17jammcq has left IRC (jammcq!~jam@c-69-245-75-255.hsd1.mi.comcast.net, Quit: leaving)
04:19vagrantc has joined IRC (vagrantc!~vagrant@c-98-232-129-196.hsd1.or.comcast.net)
04:19vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
04:21
<alkisg>
Hey vagrantc
04:22
In yesterday's ltsp meeting sbalneav suggested that we start LTSP 6 with a clean tree,
04:22
and only commit whatever we actualy want to support there
04:22
And since we'll be breaking backwards compatibility anyway (e.g. we won't even have an LDM_DIRECTX variable),
04:23
maybe it's a good time to introduce the new configuration system I was talking about?
04:23
<vagrantc>
hm.
04:23
<alkisg>
And only support documented configuration options, etc, etc...
04:24Parker955 is now known as Parker955_Away
04:25
<alkisg>
(and get rid of the non-working dirs like altlinux... at least until they want to work on and support ltsp again...)
04:26
If we want that, I think we should start the tree sooner than the hackathon
04:26
A week is a very small period for such a big rewrite
04:26
So we should at least have the first steps ready by the start of the hackathon...
04:27* alkisg thinks we probably won't finish that until the end of the summer...
04:28
<alkisg>
So for example, we don't include nbd-proxy.c and getltscfg.c, but we do include xatomwait.c
04:28* vagrantc has always thought most of those should be separate sources anyways..
04:29
<alkisg>
And I vote we also temporarily remove support for ltsp-cluster, I think that can be very easily reimplemented upon the daemon-based configuration
04:29* vagrantc nods
04:29
<alkisg>
I.e. that it won't even require an ltsp-cluster-client package, that ltsp-client will suffice for its needs and it'll only need a server
04:30
So.... who gets to do the honors and creates a bzr tree? sbalneav? jammcq?
04:30
vagrantc? alkisg?
04:31* alkisg thinks most probably it will be vagrantc and alkisg...
04:31
<cyberorg>
alkisg, yes, 2 am :)
04:31
<alkisg>
cyberorg: hehe :) Good morning
04:31
<vagrantc>
alkisg: i
04:31
alkisg: i won't have time till the following week, so if you want it done soon... :)
04:31
<alkisg>
Nope
04:32
But if we want to change anything in the source stucture, now it will be the time for that too
04:33
vagrantc: the big question is... you're OK with breaking backwards compatibility with ltsp 6, right?
04:33
I think the changes will be too great to try to keep it compatible, and it's also a chance to remove obsolete code...
04:33
<vagrantc>
ah, as in ltsp 6 servers won't support ltsp 5 thin clients, and vice-versa?
04:34
<alkisg>
Right
04:34
And all the sysadmins will have to revisit their configuration, no upgrade paths offered
04:34
<vagrantc>
so, you're proposing to process more server-side?
04:34
<alkisg>
I'm proposing that "ldm-server" and "lts.conf" be combined in an "ltsp-config" daemon
04:35
Which can be installed in any app server
04:35
<vagrantc>
which essentially spits out shell-compatible variables?
04:35
<alkisg>
Right
04:35
Client does: wget http://server:1234/config?phase=initramfs&arch=i386&ip=xxx&mac=xxx&hostname=xxx&... -O config
04:35
<cyberorg>
alkisg, can you add !suse-troubles as https://en.opensuse.org/SDB:KIWI-LTSP_troubleshooting
04:35
<alkisg>
And then it sources the result, ". config"
04:35
cyberorg: type: !learn suse-troubles as ...
04:36
<cyberorg>
!learn suse-troubles as https://en.opensuse.org/SDB:KIWI-LTSP_troubleshooting
04:36
<ltsp>
The operation succeeded.
04:36
<cyberorg>
!suse-troubles
04:36
<ltsp>
suse-troubles: https://en.opensuse.org/SDB:KIWI-LTSP_troubleshooting
04:36
<cyberorg>
cool, thought only ops could do that :)
04:37
<vagrantc>
no, we allow any wingnut
04:39
<cyberorg>
vagrantc, now lets keep that secret ;)
04:40* alkisg doesn't think he has #op in #ltsp...
04:45
<alkisg>
vagrantc: btw, that daemon will also allow per-user configuration
04:45
Our pam scripts will just send &phase=login&user=xxx, and source whatever results the server sends them
04:45
<vagrantc>
nice.
04:45* vagrantc has long wanted that sort of feature
04:46
<alkisg>
OK I didn't hear you object tooo much about breaking backwards compatibility yet, so that's a very good sign... if our debian guys doesn't complain, I don't think anyone else will :D
04:46
*guy
04:47
<vagrantc>
i'm also distracted at the moment ...
04:47
i think it would be good to ask the wider community, really.
04:48
<alkisg>
I'll first write some specs at the wiki, and then send a mail for comments at the ltsp-developers ML
04:48
<vagrantc>
the biggest debian folks that i'm aware of are involved with the debian-edu community
04:48
or at least, the biggest debian-based LTSP installations i know of
04:50* alkisg waves again, later...
04:50alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
04:59sha_ has left IRC (sha_!~sha@e177172035.adsl.alicedsl.de, Ping timeout: 276 seconds)
05:00sha has joined IRC (sha!~sha@e177161165.adsl.alicedsl.de)
05:02map7 has joined IRC (map7!~map7@teksup41.lnk.telstra.net)
05:07vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
05:13map7 has left IRC (map7!~map7@teksup41.lnk.telstra.net, Quit: Leaving)
05:37vmlintu has joined IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi)
05:37vmlintu has left IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi, Remote host closed the connection)
06:25work_alkisg has joined IRC (work_alkisg!~alkisg@plinet.ioa.sch.gr)
06:57work_alkisg is now known as alkisg
07:05awilliams has left IRC (awilliams!mistik1@unaffiliated/mistik1, Ping timeout: 260 seconds)
07:18
<Enslaver>
Has anyone successfully compiled lightdm?
07:21
<knipwim>
sure
07:21
i'm fairly confident it will compile on gentoo
07:21
lightdm-1.4.0 is stable here
07:21
<Enslaver>
it doesnt on el6
07:23
and the only rpm's ive found are for fc19
07:24
<knipwim>
it's not a compile from source directly, some patches and changes are made
07:24
don't know what your troubles are
07:25
<Enslaver>
well the major one is the requirement of glib 2.4
07:25
but that was after correcting bugs and typos
07:30
<knipwim>
you can always use another one, you have slim available?
07:32awilliams has joined IRC (awilliams!mistik1@unaffiliated/mistik1)
07:34
<Enslaver>
slim?
07:34
just really needed for greeter right?
07:35
I'd prefer something with a chooser
07:39Enslaver has left IRC (Enslaver!~Enslaver@c-98-196-42-169.hsd1.tx.comcast.net, *.net *.split)
07:39leio has left IRC (leio!~leio@gentoo/developer/leio, *.net *.split)
07:44Enslaver has joined IRC (Enslaver!~Enslaver@c-98-196-42-169.hsd1.tx.comcast.net)
07:51leio has joined IRC (leio!~leio@gentoo/developer/leio)
08:07sep has joined IRC (sep!~sep@217.17.211.37)
08:08sep has left IRC (sep!~sep@217.17.211.37, Client Quit)
08:45dobber_ has joined IRC (dobber_!~dobber@89.190.199.210)
08:47
<alkisg>
!nbd-client
08:47
<ltsp>
nbd-client: To try mounting the NBD image from the client initramfs: nbd-client 192.168.67.1 -N /opt/ltsp/i386 /dev/nbd0
09:08highvoltage has left IRC (highvoltage!~highvolta@ubuntu/member/highvoltage, Ping timeout: 276 seconds)
09:13cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Remote host closed the connection)
09:13Gremble has joined IRC (Gremble!~Ben@92.236.91.208)
09:17cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
09:22awilliams has left IRC (awilliams!mistik1@unaffiliated/mistik1, Ping timeout: 255 seconds)
09:33dievel has joined IRC (dievel!~dievel@2-229-104-66.ip196.fastwebnet.it)
09:52highvoltage has joined IRC (highvoltage!~highvolta@ubuntu/member/highvoltage)
09:53awilliams has joined IRC (awilliams!mistik1@unaffiliated/mistik1)
10:16khildin has joined IRC (khildin!~khildin@80.236.227.148)
10:21monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 252 seconds)
10:28lmds_ has joined IRC (lmds_!~lmds@tui.pi-et-ro.net)
10:29monteslu has joined IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net)
10:30vicd has left IRC (vicd!~user@212.49.98.98, Quit: Leaving.)
10:42biomorph has joined IRC (biomorph!~biomorph@91.85.204.16)
11:01highvoltage has left IRC (highvoltage!~highvolta@ubuntu/member/highvoltage, Ping timeout: 272 seconds)
11:03highvoltage has joined IRC (highvoltage!~highvolta@ubuntu/member/highvoltage)
11:17administrator has joined IRC (administrator!c23fa1c6@gateway/web/freenode/ip.194.63.161.198)
11:18administrator is now known as Guest72591
11:25highvoltage has left IRC (highvoltage!~highvolta@ubuntu/member/highvoltage, Ping timeout: 244 seconds)
11:27highvoltage has joined IRC (highvoltage!~highvolta@ubuntu/member/highvoltage)
11:30alkisg is now known as work_alkisg
11:30Guest72591 has left IRC (Guest72591!c23fa1c6@gateway/web/freenode/ip.194.63.161.198, Quit: Page closed)
11:32highvoltage has left IRC (highvoltage!~highvolta@ubuntu/member/highvoltage, Read error: Operation timed out)
11:35highvoltage has joined IRC (highvoltage!~highvolta@ubuntu/member/highvoltage)
11:39adrianorg_ has joined IRC (adrianorg_!~adrianorg@177.134.61.227)
11:48andygraybeal has joined IRC (andygraybeal!~andy.gray@50.42.0.34)
12:10Gremble has left IRC (Gremble!~Ben@92.236.91.208, Quit: I Leave)
12:13highvoltage has left IRC (highvoltage!~highvolta@ubuntu/member/highvoltage, Quit: bbl)
12:19cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Remote host closed the connection)
12:27cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
12:38shawnp0wers has joined IRC (shawnp0wers!~spowers@151.236.4.166)
12:38shawnp0wers has joined IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers)
12:42baptiste has left IRC (baptiste!baptiste@paul-sud.asso.ups-tlse.fr, Ping timeout: 252 seconds)
12:47shawnp0wers has left IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers, Quit: leaving)
12:48shawnp0wers has joined IRC (shawnp0wers!~spowers@151.236.4.166)
12:48shawnp0wers has joined IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers)
12:57gentgeen__ has joined IRC (gentgeen__!~kevin@98.236.71.64)
12:58gentgeen__ has left IRC (gentgeen__!~kevin@98.236.71.64, Remote host closed the connection)
13:04adrianorg_ has left IRC (adrianorg_!~adrianorg@177.134.61.227, Ping timeout: 248 seconds)
13:18Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
13:23alexqwesa_ has joined IRC (alexqwesa_!~alex@109.172.12.47)
13:26bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
13:32alexqwesa_ has left IRC (alexqwesa_!~alex@109.172.12.47, Quit: Хана X'ам !!!)
13:57garymc has joined IRC (garymc!~chatzilla@host81-148-67-235.in-addr.btopenworld.com)
13:57dead_inside has joined IRC (dead_inside!~dead_insi@76.75.3.174)
14:01Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
14:16monteslu_ has joined IRC (monteslu_!~monteslu@ip68-109-174-213.ph.ph.cox.net)
14:20monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 260 seconds)
14:22
<sbalneav>
Morning all
14:25highvoltage has joined IRC (highvoltage!~highvolta@ubuntu/member/highvoltage)
14:29
<knipwim>
hey scotty
14:29
looks like posting to the mailinglist already paid off :)
14:40awilliams has left IRC (awilliams!mistik1@unaffiliated/mistik1, Ping timeout: 248 seconds)
14:42
<sbalneav>
Which list? dev?
14:48dievel has left IRC (dievel!~dievel@2-229-104-66.ip196.fastwebnet.it, Ping timeout: 248 seconds)
14:50
<knipwim>
yep
14:50
9 replies to jim's post
14:51dievel has joined IRC (dievel!~dievel@2-229-104-66.ip196.fastwebnet.it)
14:52
<sbalneav>
Well, he's right. And besides, we're not going to re-write *everything*, large parts will come over as-is. I was just suggesting we start with a clean tree.
14:54
<knipwim>
that will be a complex operation, since we're also integration Enslaver's code
14:59adrianorg_ has joined IRC (adrianorg_!~adrianorg@187.115.111.69)
15:01Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
15:02
<sbalneav>
Yup.
15:21jammcq has joined IRC (jammcq!~jam@c-69-245-75-255.hsd1.mi.comcast.net)
15:22
<jammcq>
good morning friends
15:26
<sbalneav>
hey jammcq
15:31alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
15:32* alkisg waves
15:33* knipwim waves back
15:35
<alkisg>
I think we need to start preparing for the hackathon
15:36
LDM is everywhere in the LTSP code, if we're going to remove it, we'll need some big changes
15:36
It doesn't matter if it will be "half of the code base" like I said or "0.3 of the code base" or whatever, it'll be a very big change
15:37
And I think it's a chance to break backwards compatibility, as we'll stop having LDM* lts.conf directives anyway...
15:39
<sbalneav>
That was why I was suggesting starting with a fresh tree :)
15:39
<alkisg>
I totally agree
15:40
Do we also want to do the new configuration scheme change, as part of the partial rewrite?
15:40
We'll have to look and hopefully document many of the lts.conf options anyway with the LDM removal...
15:40
<sbalneav>
That's a bit we don't have yet. I'd suggest sticking with lts.conf for the moment. Here's what I have in my mind.
15:41meamy has joined IRC (meamy!~hannes@pd95cdee4.dip0.t-ipconnect.de)
15:41
<alkisg>
I've written test code for the daemon and the client parts, and it'll help in removing the ltsp-cluster bits as well
15:41
<sbalneav>
1) Get the tree to the point where we can boot a "Pure" thin client; no localapps, no localdevs, no fat clients. To start.
15:41
2) Add back localdevs. Remove cdpinger, sub in whatever for jetpipe.
15:42
3) Add back in localapps. Get xatomwait going, and whatever elese.
15:42
4) fat clients.
15:42
In each phase, we bring across the bits we need from the old tree, abandoning what we don't.
15:43
It's quite possible, by the end of the week, we might be at 4.
15:43
I've "more or less" got 1 going.
15:43
<alkisg>
I agree, but I'd still stick the new configuration system there. I can have a basic implementation for it ready *before* the hackathon.
15:43
We'll be reading all the scripts we import; it's a great opportunity to do both at the same time
15:43
<sbalneav>
We just need to get the build-client stuff fixed up.
15:44
<alkisg>
We'll need to rewrite ldm-server anyway
15:44
So the new config system task overlaps with much of the things we'll be doing anyway
15:45
Replace ldm-server with _something_, remove LDM* variables, rethink the ltsp-cluster approach...
15:45
<sbalneav>
OK, if you've got it going before the hackathon, great. But if not, then I'd suggest sticking with what we've got. Right now, we have a box full of functioning lego pieces. We just need to stick them together in a new order. If you manage to get that new lego piece done, fine. If not, we can just stick with the old lego piece for now, and sub it in later on.
15:45
<alkisg>
That's all I can ask for :)
15:45meamy has left IRC (meamy!~hannes@pd95cdee4.dip0.t-ipconnect.de, Ping timeout: 272 seconds)
15:46
<alkisg>
I'll put up a wiki page so that we have a specific design to talk about
15:46
<sbalneav>
Sure. I was just going to say I'll post this idea. Either you or I is fine.
15:46
But I think it makes sense to do it in phases.
15:47
<alkisg>
It's a nice approach; otherwise we'll get lost with all the changes
15:47
<sbalneav>
otherwise, if we try to solve all use cases at once, we'll get bogged down too fast.
15:47
<alkisg>
With the init-ltsp.d change, I proposed it, but for some future ltsp version,
15:47
and I didn't even have time to work on that,
15:47
<sbalneav>
Well, now's the time :)
15:47
<alkisg>
and then Gadi went ahead and implemented a part of it, breaking upstream ltsp, and then found a new job,
15:48
and we spend months to get ltsp in shape for 12.04 and wheezy releases... :-/
15:48
Without even wanting to do it then!
15:48
<sbalneav>
Well, we can clean some of that up now.
15:48
<alkisg>
So sure I very much agree with an implementation based on phases
15:49
<sbalneav>
Also, if we run into a show-stopper, we'll run into it sooner (hopefully)
15:49
No point in worrying about localapps if we can't even get a simple login going, for instance :)
15:49
<alkisg>
True
15:50
And if we start with a big tree with all the LDM references etc inside it, it'll be a very long time before we even get it up and running without LDM
15:50
<sbalneav>
right. So if we start clean, bring across the minimum we need for each phase at each point, we won't overwhelm ourselves.
15:51
<alkisg>
Not to mention that we'll get rid some of the not-maintained code... at least until those maintainers decide that they want to work on ltsp again
15:51
<sbalneav>
Also, we're going to be building packages/testing/etc. as we go along.
15:51
<alkisg>
The good thing is that we moved most of the "chroot destructive" operations to ltsp-client-* packages, instead of ltsp-build-client
15:52
So we can just upgrade the ltsp-client* packages, no need to rebuild chroots
15:52
*actually we moved them to init-ltsp.d, at the boot phase
15:52
<sbalneav>
right.
15:52
<alkisg>
So e.g. the pam configuration changes, will probably be init-ltsp.d scripts
15:53
<sbalneav>
right. pam, any changes to lightdm.conf/any other dm, etc.
15:53
<alkisg>
Enslaver: have you thought over how you want to proceed with your merge requests? Are you targetting LTSP 5 and then 6, or directly LTSP 6?
15:54
For us, it'll be easier if we don't have to do the merge twice...
15:54
But on the other hand, you already done a lot of work on LTSP 5...
15:55
I don't know what's best there... maybe you can have a local ltsp5 branch somewhere, with your changes committed however you wish, and then we can only merge your code upstream in LTSP 6?
15:56
<Enslaver>
I have a nice guide reflecting what needs to be modified in the main brsnch
15:56
Most of those ive commited
15:56
If lights
15:56
Lightdm is required for 6 we cant use it
15:57
<alkisg>
Supposedly any DM can be used
15:58
<Enslaver>
Without a rewrite of lightdm
15:58
<alkisg>
We'll have pam hooks and session hooks (the /usr/share/xsessions/*.desktop Exec entries)
15:59
Hopefully those will be enough to take care of everything, so it'll work with any PAM-aware DM
15:59
If not, and we require DM patches... it'll be hard even for LightDM
15:59
GDM and LightDM also provide some hooks themselves, I don't know about other DMs
16:01
I hope that in the end, we won't have any mention of "lightdm" or its configuration dirs anywhere in the LTSP code
16:01meamy has joined IRC (meamy!~hannes@pd95cdee4.dip0.t-ipconnect.de)
16:02
<Enslaver>
I gotta check but I'm pretty sure GDM in el6 supports pam, and its the default
16:02
<alkisg>
Sure, GDM supports PAM
16:04
<Enslaver>
for the integration part if my code changes currently are functional for the other distro's then just including the commit i'm doing today everything will work, everything I add later can be over-written using the rpm installs
16:05
The only thing left I need to do during the hackathon is write up some documentation and a few things here and there on my end
16:06
<alkisg>
Do you have a tree ready for the merge proposal?
16:08
<Enslaver>
yes, just pushed up latest commit
16:09
Should i change my branch to re-start at revision 1 once this is released?
16:10bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 252 seconds)
16:10mikkel has joined IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk)
16:18
<alkisg>
Enslaver: no I don't think you should start at revision 1... maybe start from the current ltsp trunk, and have a few clean commits on top of that
16:19
Ideally, common-code commits would be different than distro-specific commits... so that it's easier to review them
16:20
Then distro maintainers can just focus on verifying that the common-code commits doesn't break anything on their distros... and not care much about el6 specific commits
16:20
<Enslaver>
ok i'll start a separate branch for my upstream requests
16:20
<knipwim>
Enslaver: i can merge your distro specific changes, and you can build your common-code changes on those for discussion
16:20
<alkisg>
bbl
16:20
<knipwim>
Enslaver: so you only have the common-code diffs to worry about
16:21alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
16:22
<knipwim>
i probably can do most of that tonight (17:22 here)
16:22
if you are available to asnwer some questions i have
16:22
<Enslaver>
yeah it's not a whole lot of changes to the common code
16:22
i'll start on that branch after this meeting
16:23
Tonight after 5pm CST i'll be at the rodeo
16:23
<knipwim>
i would start the branch tomorrow
16:23
<Enslaver>
tomorrows better
16:23
<knipwim>
so you can use a fresh pull of the trunk
16:23
with your distro specific changes merged in
16:24
<Enslaver>
well its not a lot of changes, i can go over the few I have with you relatively quickly
16:25
basically my tree is laid out like the other distro's, everything in server/Redhat or client/Redhat and ./server/share/ltsp/plugins/ltsp-build-client/Redhat
16:28
<knipwim>
what does the client/Redhat/chroot-setup do?
16:30dievel has left IRC (dievel!~dievel@2-229-104-66.ip196.fastwebnet.it, Ping timeout: 252 seconds)
16:32
<Enslaver>
./server/share/ltsp/plugins/ltsp-build-client/Fedora
16:32
oops
16:32
http://fpaste.org/Pvjz/
16:32
check that out
16:32
its a diff
16:33
got a meeting, be back in an bit
16:34
<knipwim>
nice
16:34dievel has joined IRC (dievel!~dievel@2-229-104-66.ip196.fastwebnet.it)
16:46dobber_ has left IRC (dobber_!~dobber@89.190.199.210, Remote host closed the connection)
16:51dievel has left IRC (dievel!~dievel@2-229-104-66.ip196.fastwebnet.it, Quit: Leaving)
17:18meamy has left IRC (meamy!~hannes@pd95cdee4.dip0.t-ipconnect.de, Quit: meamy)
17:23andygraybeal is now known as nullbytes
17:23nullbytes is now known as andygraybeal
17:30garymc_ has joined IRC (garymc_!~chatzilla@host81-148-8-179.in-addr.btopenworld.com)
17:30garymc has left IRC (garymc!~chatzilla@host81-148-67-235.in-addr.btopenworld.com, Ping timeout: 256 seconds)
17:30garymc_ is now known as garymc
17:34komunista has joined IRC (komunista!~slavko@87.244.209.121)
17:37alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
17:41garymc has left IRC (garymc!~chatzilla@host81-148-8-179.in-addr.btopenworld.com, Ping timeout: 252 seconds)
17:44Gremble has joined IRC (Gremble!~Ben@212.183.128.19)
17:54biomorph has left IRC (biomorph!~biomorph@91.85.204.16, Ping timeout: 248 seconds)
18:02vagrantc has joined IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net)
18:03vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
18:10Gremble has left IRC (Gremble!~Ben@212.183.128.19, Ping timeout: 276 seconds)
18:12
<alkisg>
knipwim: where would I put a wiki page for the new configuration system I want to propose?
18:13khildin has left IRC (khildin!~khildin@80.236.227.148, Quit: I'm gone, bye bye)
18:16
<alkisg>
jammcq: from your replies at #ltsp-developers, I'm getting the feeling that you oppose the new configuration system
18:16
E.g. puppet is completely unsuitable for our configuration needs
18:17
We can't use it from our custom init, it's used as a service...
18:17
Is there any issue that I'm missing?
18:18
Any reason that you oppose that specific part so much, while e.g. last year we rewrote most server-side tools and much of the client-side startup process without any opposition?
18:25
<jammcq>
alkisg: i'm against recreating the wheel, when there's plenty of perfectly fine wheels out there already
18:25
<alkisg>
jammcq: care to talk about it? Because I don't think that's true
18:25
<jammcq>
and my understanding of Puppet is that it would work for this
18:25
<alkisg>
E.g. puppet is for managing several clients, taking care that they have the same set of apps installed, propagating settings...
18:25
It's not suitable to our needs at all
18:26
We don't want to have programs installed as part of the boot process
18:26
<Enslaver>
back
18:26
<alkisg>
And we certainly don't need complicated configuration systems
18:26
<jammcq>
no, but the 'propagating settings'... that's the part that fits
18:26
<Enslaver>
talking about puppet? I messed with that, too in depth
18:26
<alkisg>
As for the existing solution, ltsp_config is pretty much broken
18:27
It does a file write for each var we set
18:27
<Enslaver>
I liked cobbler
18:27
<alkisg>
It was supposed to do caching, but it does so in a very insufficient way
18:27
Then, there's ltsp-cluster control center, which is similar to what I'm looking to implement
18:27
I just want to do it in a more ...upstream way and not so as an external product
18:27shogunx has left IRC (shogunx!~shogunx@2001:4978:106:1:e596:27a9:7e4b:acad, Ping timeout: 245 seconds)
18:28
<alkisg>
So that the new system can cover the -cluster needs as well
18:28
And, cover the needs of the people that asked here for new things the last 4-5 years
18:28
E.g. per user configuration, or load balancing, or different settings per time of day
18:28
The implementation is rather simple, python already has a simplehttpserver module
18:29
<Enslaver>
http://cobbler.github.com
18:29
<alkisg>
And, we already have a python daemon (ldminfod) that we need to replace since LDM is going away
18:29
And I really don't think anyone of us is willing to write the code to replace ldminfod with puppet... when it doesn't even list the server sessions, languages, do load balancing, etc etc
18:30
I really don't understand why you oppose that
18:30shogunx has joined IRC (shogunx!~shogunx@2001:4978:106:1:a1c6:79a9:704b:6dbd)
18:30
<alkisg>
But if it's an issue, it'll be much easier for me to just develop what I need on a tree separate to ltsp, really no problem there,
18:30
although those issues that I'm talking about would have to be solved upstream anyway (e.g. ldminfod rewritten)
18:30
<jammcq>
you clearly have the votes from the other developers to move forward. I'm not the sole decider here
18:31
and believe me, it won't hurt my feelings if you do it.
18:31
and i don't think you need to make it separate
18:32
<alkisg>
It might be that I'm too sensitive, but I don't like doing things when the decision is not unanimous
18:33
So I'll postpone the whole thing until the replacements that we'll need have the votes of all the developers
18:33* jammcq thinks that's a mistake
18:34
<jammcq>
imagine if we waited for unanimity in Washington
18:34
<alkisg>
That's why I never want to become a politician :) I know myself, and I really feel better that way.
18:34
OK, np, let's move on to other things
18:34
<jammcq>
well... if it makes you feel better, i'm starting to understand the value of changing the current system
18:35
maybe i just need more time to absorbe it
18:35
<sbalneav>
http://bazaar.launchpad.net/~sbalneav/ltsp/ltsp-pam-examples/view/head:/ltsp-pam/xsession
18:35
<alkisg>
I can write that wiki page with the why we need it at the first place, what are the expected benefits, draft the implementation etc, if you want to talk about it more...
18:36Gremble has joined IRC (Gremble!~Ben@212.183.128.19)
18:36
<jammcq>
sure, lets' start with that
18:36
<alkisg>
'k
18:36
<sbalneav>
Auto figure out if the X server is listening to the TCP port, and set $DISPLAY accordingly, including handling the xauth keys.
18:36
<jammcq>
I should hold any doubts until I see the whole picture
18:38
<knipwim>
alkisg: i would put it somewhere in the Dev namespace, like "http://wiki.ltsp.org/wiki/Dev:Config Rewrite" or something
18:39
<alkisg>
knipwim: ty :)
18:40
<knipwim>
Enslaver: i merged the first part, going to do the ltsp-build-client plugins next
18:40
but i had a couple of questions about them
18:43
<Enslaver>
ok
18:49
<knipwim>
ok, is 010-chroot-creator supposed to return?
18:49
# 02/22/13 - Mock still in testing
18:50
<Enslaver>
yes
18:50
mock is the new chroot-creator
18:51
eventually 010-chroot-creator will be removed
18:53
<knipwim>
is 009-mock-chroot supposed to be executable?
18:54
<Enslaver>
doesn't need to be
18:54
that shows up on launchpad?
18:55
<knipwim>
ok, i'll change that
18:55
i don't know, it pulled your version
18:55
<Enslaver>
neat
18:55
<knipwim>
i saw it by accident actually, to check if 010-etc-hosts was really empty
18:56
can i remove that one?
18:56
<Enslaver>
no
18:56
that is an over-ride to the common
18:58
<knipwim>
kk
18:58
so 010-mountproc also i prosume
19:00
<Enslaver>
yeah
19:00
<knipwim>
in 020-cleanup-chroot one line is commented i'd like to make sure
19:00
#[ ! -d /opt/ltsp/$ARCH ] && mv /var/cache/mock/$ARCH /opt/ltsp/$ARCH
19:01
<Enslaver>
yup, supposed to be, thats done in the 009-mock file now
19:02
<knipwim>
i'll add a comment about that
19:02
<Enslaver>
its safe to remove the entire line
19:02
<knipwim>
kk
19:04
for 020-rootpath, you can also use the common one
19:04
and have the --purge option
19:05monteslu_ is now known as monteslu
19:05
<Enslaver>
k
19:06
i'll test it here, if it works i'll remove that file
19:06
<knipwim>
sure, it does exactly the same, exits when there is a chroot
19:07
but offers the option --purge to remove it automatically
19:08
hmm, i see now it exports ROOT
19:08
the common one
19:08
so if you need that later, use your own for now
19:21vmlintu has joined IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi)
19:24bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
19:27
<knipwim>
Enslaver: and 030-resolvconf-hack, you could symlink the one in Ubuntu/010-set-resolver
19:31
<Enslaver>
The other distro files get removed at install by my rpms, i could copy it first but i like having the rh specific files in 1 place, plus if i forget later and change it i might forget its synlimked
19:35komunista has left IRC (komunista!~slavko@87.244.209.121, Quit: Leaving.)
19:37
<knipwim>
i'm not familiar with how one creates an rpm, they are archives right?
19:38
on you create those from source using some kind of recipy
19:42
<Enslaver>
yes
19:43
almost like debian does, just 1 spec (config) to define everything
19:43
<knipwim>
so, when you copy the files from source, it copies the symlink, not the file?
19:43
<Enslaver>
correct
19:43
unless you dereference it
19:45
<knipwim>
so, can't you copy all Redhat plugins dereferenced?
19:48
i can put a big header in the file saying it's used by Ubuntu and Redhat, so everyone editing remembers
19:51
<Enslaver>
yeah I can do that
19:52
So looking at libpam_sshauth it uses libssh, not libssh2 :/
19:53Gremble has left IRC (Gremble!~Ben@212.183.128.19, Quit: I Leave)
19:53Gremble has joined IRC (Gremble!~Ben@212.183.128.19)
19:53
<Enslaver>
http://www.libssh2.org/libssh2-vs-libssh.html
19:55
<sbalneav>
Enslaver: is there a problem with libssh?
19:55
<Enslaver>
sbalneav: yes, no ssh2 support :(
19:55
el6 doesn't use libssh
19:56
<sbalneav>
libssh has ssh2 support. http://www.libssh.org/features/
19:56
<Enslaver>
in 0.5?
19:57
<sbalneav>
sbalneav@phobos:~$ dpkg -l | grep libssh
19:57
ii libssh-4:amd64 0.5.3-1
19:58
Any other issues with it?
19:58bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 248 seconds)
19:59
<sbalneav>
http://rpmfind.net/linux/RPM/dag/redhat/el6/x86_64/libssh-devel-0.5.0-1.el6.rf.x86_64.html
19:59
Does that mean it's available in el6?
20:00
<Enslaver>
http://download.opensuse.org/repositories/network:/synchronization:/files/RedHat_RHEL-6/x86_64/ has better rpms
20:01
<sbalneav>
So is it available?
20:01
<Enslaver>
problem is that getting LTSP into EPEL is i'll also need to get libssh into EPEL
20:01
<jammcq>
wouldn't libssh2 work ?
20:03
<sbalneav>
They are two different libraries by different projects.
20:03
<jammcq>
oh
20:03
<sbalneav>
They ultimately do the same thing, but have different API's.
20:04
I chose libssh because it had both client and server sides, which meant if we had to write something server side, we could do so and use the same api.
20:04
also, at the time I started this, libssh was the more mature product.
20:05
<jammcq>
which one is more mature/popular now?
20:06
<Enslaver>
libssh is newer, but requires newer libraries
20:06
0.4 didn't support ssh2, thats why they made libssh2
20:07
libssh isn't in el6 because their code isn't considered 'stable' yet
20:07
<sbalneav>
isn't considered stable by who?
20:07
<Enslaver>
and has security flaws
20:08
redhat
20:08
<sbalneav>
Then that's redhat's problem.
20:08
<jammcq>
ummm
20:08
<sbalneav>
Seems to be available everywhere else.
20:08
<Enslaver>
well considering they just had a security release 1/22/2013
20:09
and thats 0.5.4, which i see you're not even on yet
20:09
<jammcq>
well... maybe with some pushing, we can get redhat to accept libssh
20:10
<sbalneav>
I don't see where I'm specifically requiring a version of libssh in my code.
20:10
<Enslaver>
true, it's a 3-6 month test cycle before they deploy anything that's in EPEL
20:10
<jammcq>
redhat tends to be conservitive, but I like it
20:11
<Enslaver>
Once i issue a fedora release i'll have all that neat cool stuff in it, but company's want stable versions that will last them 4-5 years, thats my first goal
20:13
If you decide to stick with libssh i'll have no choice but to push the LTSP6 release for EL down the line 6+ months
20:14
<sbalneav>
I've written what I've written.
20:15
<Enslaver>
afk lunch
20:15
<vmlintu>
Enslaver: if you can require kerberos usage, you can open the ssh connections with it without libpam-sshauth
20:17
<Enslaver>
My ultimate goal is to have exactly that, having authentications through kerberos or any authentication service for that matter with an LDAP backend
20:17
<vmlintu>
Enslaver: that's what we are using now in our setups
20:17
<Enslaver>
vmlintu: same, we have it working nicely with 389
20:18
not with kerberos though
20:18
<vmlintu>
Enslaver: https://github.com/opinsys/puavo-ltsp
20:18
<Enslaver>
nice, i'll check that out
20:18
<vmlintu>
https://github.com/opinsys/ltsp-lightdm
20:18
there's the lightdm stuff we are using with it
20:18
<knipwim>
Enslaver: i'd like to put the dracut modules in /client instead of the /client/Redhat/share
20:18
<Enslaver>
knipwim: awesome =)
20:18
<knipwim>
they are common enough
20:19
i hope we can add them to dracut upstream eventually
20:19
<vmlintu>
Enslaver: we are using openldap + mit krb5 + smbkrb5pwd and manage it with Puavo
20:22yalu has left IRC (yalu!~yalu@109.134.164.244, Quit: leaving)
20:32bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
20:36
<vmlintu>
Lots of interesting LTSP6 talk today
20:38
jammcq: did you mean earlier using Puppet to create the chroot or to configure the LTSP server?
20:39
<alkisg>
vmlintu: would you feel confident enough to ship + support your tftpd server as the default ltsp configuration system? Do you think it's stable and fast enough?
20:40
<vmlintu>
alkisg: we are installing the first production system using it this week, so we'll soon know how it performs
20:40
<alkisg>
A tftpd is the only server in ltsp that can take care of everything, from sending pxelinux, the kernel and its parameters, to sending configuration... but even good servers like tftpd-hpa have had problems in the past...
20:40
E.g. some people observed that dnsmasq was twice as slow as tftpd-hpa, until some upstream fix solved that
20:41
Cool, let us know about how it goes
20:41
<vmlintu>
puavo-tftpd is slower that tftpd-hpa, but that's because it's interpreted and not compiled c
20:42
<alkisg>
Not slower in response times, but in bandwidth
20:42
E.g. if it sends a kernel in 5 seconds or in 10
20:42
(talking about a kernel because it's big, of course configuration files are smaller)
20:43
<vmlintu>
I have never used dnsmasq's tftp server so I don't know how it behaved. Was it because of missing tsize support?
20:43
<alkisg>
I think it was something about negotiating the transfer block size with the clients, not the tsize which is about the file size...
20:43
...but I'm not really sure, I haven't looked into it
20:43
<vmlintu>
sorry, yes, I'm mixing the terms now
20:44
It is blksize, I think
20:46
<alkisg>
Right, I think that was it
20:50
<vmlintu>
But we'll see next week how well it performs. We'll do whatever it takes to get it fast enough
20:53
alkisg: are all your systems now using ltsp-pnp?
20:53
<alkisg>
vmlintu: no, not all of them, some teachers were reluctant about the ubuntu 12.04 problems and stayed with 10.04
20:53
But all the 12.04 installations do use ltsp-pnp, yeah
20:54
<vmlintu>
alkisg: what kind of problems have there been?
20:54
<alkisg>
The ldm/sshfs issue, gnome-panels dissappearing, more RAM required with 12.04,
20:54
nbd-server crashing,
20:55
Now the non-pae ubuntu kernels get mixed with the -pae ones (in 12.04.2),
20:55
gnome-fallback doesn't offer 100% of what gnome2 did,
20:56
...I think those are the most pressing ones
20:56
And of course we had to workaround lots of other ones
20:57
<vmlintu>
did you try the nbd-server fix?
20:57
<alkisg>
No, not yet, I'm still trying to find time for the ldm/sshfs issue
20:58
<vmlintu>
We'll be also using now lightdm with this new installation so it'll be interesting to see how it performs
20:58
<alkisg>
vmlintu: you said something about lightdm ram requirements
20:58
But after login, its RAM usage is quite small, right?
21:00
Ah, and some other problems with the 12.04.2 new kernel+xorg stack is that vbox and samba no longer work at all
21:01
<vmlintu>
samba?
21:01
<alkisg>
I really can't understand how such big projects can be completely broken with an lts release...
21:01
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1016895
21:01
<vmlintu>
that's something I haven't noticed yet
21:01
<alkisg>
And vbox: https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1081307
21:02
Samba works only once, it crashes on the second use
21:02
!kvm
21:02
<ltsp>
kvm: To boot a fake thin client with kvm: kvm -ctrl-grab -net nic -net user,tftp=/var/lib/tftpboot,bootfile=/ltsp/i386/pxelinux.0
21:03
<vmlintu>
I'm not using virtualbox for anything, so I wouldn't have noticed that..
21:04
<alkisg>
We're starting to use it to provide windows VMs to LTSP fat clients
21:06
<vmlintu>
We did that some years ago, but not anymore
21:07
alkisg: I cannot find the test results for lightdm ram/cpu usage right now. I know that they are somewhere, but just cannot find them now..
21:09bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Read error: Connection reset by peer)
21:09
<vmlintu>
alkisg: There are so many new things being tested right now that I'm getting lost here. We are now using a single image to run thin/fat clients, ltsp servers and laptops..
21:11
After this I'm all for LTSP rewrite.. ;)
21:11
<alkisg>
root 1989 0.0 0.4 14476 1528 tty7 Sl 23:06 0:00 /usr/sbin/ldm
21:11
root 1263 0.0 0.0 34040 3152 ? Ssl 19:28 0:00 lightdm
21:11
root 1628 0.0 0.1 23544 4400 ? Sl 19:28 0:00 lightdm --session-child 14 17
21:11
Damn we'll have to raise the minimum client specs again :-/
21:12
<vmlintu>
which lightdm greeter are you using?
21:12
<alkisg>
The stock ubuntu one, with autologin even
21:12
The greeter gets shut down after login afaik though
21:12
And only the DM process remains... no?
21:13
But no problem there if it all works out one can even use XDM if he has to
21:14
<vmlintu>
we have tested also gdm, so I cannot see why it wouldn't work
21:14
<alkisg>
Which hooks do you use to run the login scripts?
21:14
E.g. the ones from ldm/rc.d?
21:15
<vmlintu>
do you mean these?
21:15
https://github.com/opinsys/ltsp-lightdm/tree/master/rc.d
21:15
<alkisg>
Also, vmlintu, could you arrange to be lurking here at the ltsp hackathon? I think you could provide valuable feedback for such topics...
21:16
Right, those ones
21:17
<vmlintu>
Yes, I'm hoping that I could participate in it in some way
21:17
When was it again?
21:17
<alkisg>
!hackathon
21:17
<ltsp>
hackathon: http://wiki.ltsp.org/wiki/Dev:Hackathon_2013.03
21:18
<vmlintu>
Yes, I should be able to make it that week
21:19
Has there been any discussion on how fat client images should be built?
21:20
now there's ltsp-build-client and ltsp-pnp..
21:20
<alkisg>
So you're calling a renamed version of ldm-script from https://github.com/opinsys/ltsp-lightdm/blob/master/puavo-ltsp-session...
21:20
But you don't have the init and stop phases... ok shouldn't matter much
21:20
<jammcq>
vmlintu: I meant in place of lts.conf
21:21
<alkisg>
(11:19:46 μμ) vmlintu: Has there been any discussion on how fat client images should be built? => I don't think anyone has in mind to implement something different... do you have any ideas to discuss? Like, the puppet one?
21:22
<jammcq>
I think using puppet to build the image seems interesting
21:22Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
21:22
<jammcq>
I don't know enough about puppet to really understand that, but it sounds interesting
21:22* alkisg isn't interested at all in image building since he's using ltsp-pnp, and leaves that part to others... :)
21:23
<vmlintu>
alkisg: puavo-ltsp-session is called from pam: https://github.com/opinsys/puavo-ltsp/blob/master/client/templates/etc/pam.d/lightdm-thinclient
21:26
alkisg: jammcq: What we are now doing is that we use Puppet to build one image that supports four modes: thin/fat/ltspserver/laptop. The mode is selected using a kernel parameter, so e.g. on laptop mode initramfs doesn't try dhcp. LTSP servers are also PXE booting, so they use exactly the same image as fat clients.
21:26
<alkisg>
vmlintu: I think the phases should be: initramfs (e.g. select server), init(-ltsp.d) (to prepare client system), run_services (e.g. jetpipe, screens), xorg init (e.g. xrandr), login (per user config), logout, and shutdown
21:26
If we can have hooks for those, we're completely fine
21:26
<vmlintu>
alkisg: jammcq: The goal here is that we can be sure that the applications on the server and on the clients match.
21:27
For laptops we copy the image as-is on the hard drive and install grub 2.0 on MBR and it scans the images and loads the kernel from inside the squashfs images.
21:28
I wouldn't dare to do all this using bash scripts..
21:28* alkisg will really pass on that subject, ltsp-pnp takes care of the "chroot" applications without any code at all...
21:30mikkel has left IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk, Quit: Leaving)
21:30
<vmlintu>
We have applications that just don't work if installed ltsp-pnp style, so we have no option here..
21:31
<alkisg>
What do you mean with that? For example?
21:32
<vmlintu>
Interactive whiteboard drivers are probably the worst.. they have all kinds of nasty things..
21:32
<alkisg>
What we tell teachers here is "install anything you want normally, using software center, apt-get or ./install.sh, we don't care - then just publish your server disk"
21:32
So that works even for interactive boards or device drivers that can't be installed in a chroot
21:33
So I'd say the opposite, that it wouldn't be possible to do it with a chroot or with puppet, not with ltsp-pnp...
21:33
<vmlintu>
Some of them conflict and cannot be installed on the same machine. Similar to nvidia/fglrx..
21:33
<alkisg>
How do you install them both in a single chroot then?
21:34
<vmlintu>
We configure them during boot time
21:34
<alkisg>
But e.g. nvidia puts stuff in the initramfs
21:35
You also have different initramfs's in order for the nvidia module to get loaded before puppet starts executing?
21:35
<vmlintu>
https://github.com/opinsys/ltsp-build/blob/master/ltsp-build-client/puppet/ltsp/graphics_drivers/manifests/init.pp
21:35
We use puppet only during chroot creation
21:35
We have just one image and one initramfs that supports both fglrx and nvidia
21:36
<alkisg>
So, you just have custom code there, that's not related to puppet
21:36
If you have a single chroot, then you could do the same stuff with ltsp-pnp too
21:36
And even use puppet if you like, there
21:36
Anyways, off to bed... bb all
21:37iphar has left IRC (iphar!hara@gateway/shell/devio.us/x-pcfklflbwahnksmg, Remote host closed the connection)
21:37
<vmlintu>
I'm sure it'd be possible with ltsp-pnp too, but not out-of-the-box
21:37
<alkisg>
You can't have both fglrx and nvidia out of the box with puppet either, you write custom code
21:38
That will only be possible if they repackage the xorg drivers for them
21:38* alkisg waves
21:38alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
21:38
<vmlintu>
yes, everything Puppet does can be done with bash
21:39
jammcq: how do you see these other uses of the client image besides thin/fat clients?
21:41Gremble has left IRC (Gremble!~Ben@212.183.128.19, Quit: I Leave)
21:41bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
21:54infania has joined IRC (infania!~Infania@moe.infania.net)
22:02
<jammcq>
vmlintu: I don't understand your question
22:04
<vmlintu>
jammcq: we are now testing a scenario where there's no ltsp server that has applications installed, but ltsp server pxe boots using the same image as thin/fat clients
22:05
jammcq: so ltsp server is actually a netboot device just like thin/fat clients
22:05
<jammcq>
ummm, sounds interesting I guess, but not something that I need
22:06
<Enslaver>
puppet's a neat product
22:06
<vmlintu>
jammcq: the same image works also on laptops so that one can just copy the image on the hard drive and it works
22:06
<Enslaver>
i played with it some a few years back and again recently
22:06
We've been in talks with puppet labs about purchasing
22:07
<vmlintu>
jammcq: installing a laptop takes some 5-10 minutes which is nice in school environment
22:08
Enslaver: puppet is good for many things, but not all
22:09
<Enslaver>
it needs a better interface to it, most system admins don't have the time to spend learning it
22:10
<vmlintu>
We've been managing LTSP servers with it, but I cannot trust it to run in the background to do updates automatically
22:10
<Enslaver>
vmlintu: you tried cobbler?
22:10
<vmlintu>
Enslaver: no
22:10
<Enslaver>
i've started looking into that recently
22:12
<vmlintu>
I guess Puppet fits nicely in environment where one uses disposable installations, e.g. virtual/cloud servers. In desktop installations old settings start piling up and the machines are not the same after a year..
22:12bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 255 seconds)
22:13
<vmlintu>
If I install a server today and a new one in three months, those won't be identical, so some rules will fail eventually..
22:14
<Enslaver>
is this your repo? the opinsys?
22:14
<vmlintu>
Enslaver: yes, that's the company repo
22:14
<Enslaver>
lots of good stuff here
22:14
whats the base linux distro?
22:15
<vmlintu>
Ubuntu
22:15
http://www.opinsys.fi/en/
22:15
<jammcq>
gotta run, see ya'll later
22:15
<vmlintu>
http://labs.opinsys.com/
22:15jammcq has left IRC (jammcq!~jam@c-69-245-75-255.hsd1.mi.comcast.net, Quit: leaving)
22:16
<Enslaver>
looks nice
22:17
never been a big ubuntu fan tho
22:17
<vmlintu>
Schools have some applications that come only in Ubuntu .deb packages..
22:19
Enslaver: are you planning to support also fat clients on fedora/redhat?
22:19
<Enslaver>
yes, fat client support is now complete
22:19
<vmlintu>
do you use sshfs or nfs for home mounts?
22:20
<Enslaver>
ability to use both
22:20
ltspfs/nfs
22:20
soon gonna have iscsi root's mounting NFS home dirs with local app support
22:21
<vmlintu>
iscsi would be nice as nbd-server is kinda buggy..
22:21
<Enslaver>
yeah and the transition to it is actually really easy, i've already started developing the code for it
22:21
<vmlintu>
But then again kernel 3.7 broke nfs4 kerberos mounts for diskless clients..
22:22
So it seems like everything needs some fixing..
22:22
<Enslaver>
http://bazaar.launchpad.net/~enslaver-l/ltsp/ltsp-redhat/view/head:/server/Redhat/scripts/iscsi-update
22:23
<vmlintu>
So it just needs kernel parameters + iscsi server?
22:24
I've never used iscsi myself
22:24Gremble has joined IRC (Gremble!~Ben@212.183.128.19)
22:24
<Enslaver>
just like nbd, with iscsi you have an initiator / target
22:24
target = server, initiator = client
22:24
but it will give the ability to serve up more than 1 image at a time, via LUNS
22:24
so you map each image to a LUN
22:25
LUN: 1 Backing store path: /opt/ltsp/images/i386.img
22:25
etc..
22:25
<vmlintu>
ok
22:25
I should really give it a try
22:26
<Enslaver>
Then your ltsp initrd just needs to load the iscsi module and call the target, which it can scan for dynamically or be specified
22:26
by dhcp
22:26
<vmlintu>
Was it so that there can be multiple servers serving the same image?
22:26
Or was it AoE..
22:27
We have now the nbd image name stored in LDAP for each client so I'd need some way to map the names to LUNs..
22:29
<Enslaver>
http://fpaste.org/CGD9/
22:30
<vmlintu>
can the client then ask for the image using the backing-store name?
22:37
<Enslaver>
The client gets offered all of them
22:37
So if you have 10 LUNS (backing stores) in 1 target the client will see all of them
22:38
<vmlintu>
ok
22:38
<Enslaver>
and they will appear as sda/sdb/sdc etc. to initram
22:38
<vmlintu>
I think I have to try it myself to fully understand the terms
22:39
<Enslaver>
which makes using something like dracut really easy
22:39
yeah, make sure you don't use the BSD target daemon, its a bit.. limited
22:39
but stable
22:40
but if your setting up schools i recommend the open scsi target utils
22:40
http://iscsitarget.sourceforge.net/
22:41
<vmlintu>
that seems to be in ubuntu too
22:50ltspuser_41 has joined IRC (ltspuser_41!250698e5@gateway/web/freenode/ip.37.6.152.229)
22:51
<ltspuser_41>
hi guys
22:51ltspuser_41 is now known as bobpit
22:51
<bobpit>
may I ask, is there an easy way to block facebook in ltsp 12.04 ?
22:55
<vagrantc>
there's nothing LTSP-specific about blocking sites, really. (you mean ubuntu 12.04?)
22:55
<bobpit>
yes ubuntu
22:55
I am new to ubuntu and ltsp
22:56
I saw a solution with squid, but it was too complicated for me
22:56
I run a school lab, and I need to block some sites
22:56
<Enslaver>
squid is good, iptables can also block it, but the smart will just go through a web redirector
22:56dead_inside has left IRC (dead_inside!~dead_insi@76.75.3.174, Read error: Operation timed out)
22:57
<bobpit>
you mean an anonymous proxy server
22:57
<Enslaver>
yes
22:57
<bobpit>
they are not that smart
22:57
<Enslaver>
your best bet is a firewall solution then
22:58
<bobpit>
ok, any links/tutorials guys?
22:58
something simple I hope....
22:58
<vmlintu>
Easiest would probably be putting facebook.com pointing to 127.0.0.1 in /etc/hosts
22:59
<bobpit>
sounds easy. But I don;t know the syntax
23:00
googling for a related article right now
23:00
<Enslaver>
or you can do something like: iptables -A OUTPUT -p tcp -m string --string "facebook.com" --algo kmp -j DROP
23:01
that will block anything with the word facebook.com
23:01
<vmlintu>
Someone has taken it a bit further with /etc/hosts: http://someonewhocares.org/hosts/
23:02
<Enslaver>
if you don't mind spending a little money check out Palo Alto networks
23:04
<bobpit>
so a simple line like this would sufice? 127.0.0.1 facebook.com ?
23:05
<vmlintu>
bobpit: you probably want also www.facebook.com in there
23:05
but users will find out ways around that
23:06
<bobpit>
well, there is also http://facebook.com
23:07
so I thought there must be a way to use WILDCHARS ?
23:07
so that any site including FACEBOOK will be blocked?
23:14
vmlintu, besides going through a web proxy server, what other ways are to fight this ?
23:14
<vmlintu>
running local dnsmasq might work
23:14
proxy won't work if users use https
23:16
<bobpit>
there is no way my users (students) will think of using dnsmasq
23:16
<Enslaver>
proxy works with https
23:17
<bobpit>
I'll try the etc/hosts guys, seems simple and effective
23:18
<Enslaver>
bobpit: try squidguard as an alternative
23:21
<bobpit>
Enslaver, I had used squid/squidguard recently, I must have made a mistake and my server was blocked
23:21
this is why I asked fopr a SIMPLE solution
23:22
<Enslaver>
Sorry bud, there is nothing more simple on linux, maybe you should look into mac's
23:23
<bobpit>
well, I am using ubuntu 12.04 ltsp now, I cannot change this
23:23
<vagrantc>
simple solution to a complex problem?
23:24
sometimes they exist, but there's usually a lot to compromise to get it.
23:24
<bobpit>
i'll try the etc/hosts
23:24
<Enslaver>
simple solution, pay someone who knows linux to set it up for you
23:24
<bobpit>
may I ask something else guys, if you know
23:25
how do we implement something like DEEPFREEZE?
23:25
ie to reset user changes in every reboot
23:25
I do not want to keep any user changes , preferences, downloaded files etc
23:25
<Enslaver>
bobpit: a copy on write filesystem with non-persistent changes
23:25
<bobpit>
I think something simple like erase user directories ....
23:25
<vagrantc>
or rsync /etc/skel on each login...
23:25
there's a hook to do that from ldm
23:26
though i don't know if we ever included it in ldm/ltsp directly...
23:26
<Enslaver>
i haven't seen that one?
23:26
<bobpit>
vagrantc, are you a developer of ubuntu?
23:27
<vagrantc>
bobpit: no, debian.
23:27
<bobpit>
wow!
23:27
<vagrantc>
and ltsp :)
23:27
<bobpit>
wow x 2 !!
23:27
you guys do a GREAT job
23:27
<Enslaver>
you forgot ldm, ltspfs and nbd =)
23:27
<vagrantc>
plenty of good folks around here :)
23:28
<bobpit>
I decided to learn ubuntu and I respect the job you guys do on open source software
23:28Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
23:29
<bobpit>
so for the solutions you proposed, would you have a handy tutorial?
23:29
I mean, it is difficult to google for these terms
23:29
<vagrantc>
Enslaver: that's just the broader part of LTSP (although i only submit occasional patches for NBD)
23:30
bobpit: there's some post on ltsp-developer a while back ... maybe we should include the hook in examples somewhere...
23:31
<bobpit>
you mean a post in the forum?
23:32
<vagrantc>
er, ltsp-discuss mailing list
23:32
i use a modified version of it at freegeek...
23:35
<bobpit>
I am sorry, I do not know it. I am googling right now....
23:35
<vagrantc>
bobpit: http://paste.debian.net/plain/238439
23:35
i wisely included a link to the original source
23:36
bobpit: it's a simple 3-line shell script ...
23:37
bobpit: you'll need to adapt the "ltsp[1-2][0-9][0-9]|diskless[1-2][0-9][0-9]|build[1-2][0-9][0-9]|class[1-2][0-9][0-9])" part to match the usernames you want to be included.
23:38
<bobpit>
I have seen a similar script, I think I know what to do.
23:39
Where do I place this script?
23:39
Actually this is my problem with the script solution that I tried to use
23:39Enslaver has left IRC (Enslaver!~Enslaver@c-98-196-42-169.hsd1.tx.comcast.net)
23:39
<bobpit>
the instructions told me to put it at a non-existent directory
23:41
my usernames are guest01 .. guest14
23:43
vagrantc, TRHE SECOND LINE SHOULD BECOME guest[0-1][0-9])
23:43
right?
23:43vmlintu has left IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi, Ping timeout: 252 seconds)
23:46
<bobpit>
that's my problem: I do not have such a directory: /opt/ltsp/i386/usr/share/ldm/rc.d/
23:46
maybe this works for an older version of ltsp?
23:48
vagrantc, could you tell me where to place this script?
23:50
maybe I should crete the entire thing? /opt/ltsp/i386/usr/share/ldm/rc.d/
23:50
create
23:56
<vagrantc>
no, that's the right directory ... unless you've got /opt/ltsp/amd64 ...
23:56
or /usr/share/ldm/rc.d if you're using ltsp-pnp
23:57
or /opt/ltsp/i386/etc/ldm/rc.d
23:57
bobpit: the directory should be there, but you'll have to create it otherwise.
23:58
i.e. there are other files that should be in it by default
23:58
<bobpit>
vagrantc, I THINK I only have an EMPTY /opt/ltsp/ directory
23:58
I definetely DO NOT have this long /opt/ltsp/i386/usr/share/ldm/rc.d/
23:59
<vagrantc>
bobpit: /opt/ltsp/images/ ?
23:59
<bobpit>
I am not on the server right now, can;t tell
23:59
I'll check tomorow
23:59
<vagrantc>
that's what you'll have to look for
23:59
<bobpit>
but this waa the reason I could not implement this solution
23:59
<vagrantc>
it should be in some ldm/rc.d directory