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


Channel log from 20 May 2016   (all times are UTC)

00:43
<sbalneav>
Evening all
01:05
<Leolo_2>
hello
01:19
<sbalneav>
Hey Leolo_2
03:24
ls
03:37rac__ has left IRC (rac__!71148af6@gateway/web/freenode/ip.113.20.138.246, Ping timeout: 250 seconds)
03:38rac_ has left IRC (rac_!71148af6@gateway/web/freenode/ip.113.20.138.246, Ping timeout: 250 seconds)
04:54ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
05:04alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 276 seconds)
06:00kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:8d78:d090:dc40:ca8e)
06:18mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
06:50kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:8d78:d090:dc40:ca8e, Ping timeout: 260 seconds)
07:01alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
07:04kjackal has joined IRC (kjackal!~quassel@onopfy.static.otenet.gr)
07:50gdi2k has left IRC (gdi2k!~gdi2k@49.151.17.102, Ping timeout: 276 seconds)
08:03ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
08:03ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
09:12Buho has joined IRC (Buho!533cc51c@gateway/web/freenode/ip.83.60.197.28)
09:18badgerbailey has joined IRC (badgerbailey!31e48b8a@gateway/web/freenode/ip.49.228.139.138)
09:19
<badgerbailey>
Hi, I wonder if someone could help, I installed LTSP-server-standalone, installed the ltsp image I think I setup my 2 onboard lan correctly but I cannot connect to server via virtualbox on my laptop
09:20
DHCP timeouts happening
09:22
I have a staic IP on the first network port eno1 which connects to my router for outside internet access, on my second eno2 port I set a static IP but the virtualbox doesn't seem to get an IP or begin to download the image
09:23
eno1 ststic IP is 192.168.1.50 for outside access, eno2 static IP is 192.168.0 1, anyone have any idea how to test to see where the propblem lies?
09:23
<alkisg>
badgerbailey: dhcp broadcasts don't go to bridged adapters, if that's what you're asking
09:24
That's a #vbox issue though
09:24
If you were using an external dhcp server, it would work fine
09:24
<badgerbailey>
the guide I followed suggested to set it up this way, and test with a bridged adapter from my windows laptop
09:24
<alkisg>
Or an internal network vbox client
09:25
Are you setting up ltsp for the first time?
09:25
<badgerbailey>
yes
09:25
trying
09:25
<alkisg>
!ltsp-pnp
09:25
<ltsp`>
ltsp-pnp: ltsp-pnp is an alternative (upstream) method to maintain LTSP installations for thin and fat clients that doesn't involve chroots: https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
09:25
<alkisg>
This is the best guide, if it fit your needs
09:25
<badgerbailey>
thanks I'll take a look now
09:25
<alkisg>
What are your client specs?
09:25
cpu/ram and how many?
09:26
<badgerbailey>
25 clients running chrome browser and a simple office suite, thats all
09:26
my server has xeon e3 1231v2, 32gb ram
09:27
<alkisg>
badgerbailey: how much ram do your clients have? and what cpu?
09:28
<badgerbailey>
I am trying to test with pretty basic thin clients see here: http://www.inctel.com.cn/product/detail/39
09:29
<alkisg>
It's best if the clients have enough cpu/ram to run the os locally
09:29
They'll still be diskless and netbooted, but they won't use the server cpu/ram
09:29
We call that "ltsp fat clients", it works much better than ltsp thin clients
09:29
ltsp-pnp supports both models out of the box
09:30
But if you have already bought the clients and they're allwinner, then no, fat clients won't do for you
09:32
Hmm also, those are ARM, right? Did you create an armhf chroot?
09:32
<badgerbailey>
okay, before starting from scratch do you know of any guide to help me fix what I have now and check the situation to see if my NIC's are configured correctly?
09:33
<alkisg>
badgerbailey: do you know that your clients have an ARM cpu and that you need an ARM chroot to boot them?
09:33
<badgerbailey>
no i didn't, is it possible to add in this feature or will I need to start from scratch?
09:34
<alkisg>
It makes things much more difficult for you
09:34
And guides more hard to find
09:34
How many of those clients do you already have?
09:35
<badgerbailey>
only 1 for test so its not an issue to change, I'm just trying to keep the costs down, its for a charity so I am bearing the whole cost of this project
09:35
<alkisg>
These things are like raspberry pis
09:35
They have special processors and it's more hard to manage them
09:35
It's much much easier if you have PCs as clients, x86 based
09:36
For example, those are x86: http://www.inctel.com.cn/product/35
09:36
So what I'm suggesting to you is this:
09:36
1) Start from scratch and follow the ltsp-pnp guid
09:36
e
09:37
2) Test with some PCs that you have around to verify that fat clients work best
09:37
3) Buy x86 clients as your ltsp clients
09:37
(and throw away that ARM client that you have, it's not worth the trouble)
09:38
<badgerbailey>
these are pretty cheap also, I guess x86 x64
09:38
http://www.lazada.co.th/mini-pc-silver-4246460.html
09:39
<alkisg>
To evaluate clients, mark their CPUs and look it up in this site:
09:39
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Atom+Z3735F+%40+1.33GHz
09:39
So the clients that you said now, have 909 score
09:39
They will work. But my 7 year old laptop has 1500 score.
09:40
So they're similar to buying an 8-10 year old computer...
09:40
For *light* surfing, 1000 score is acceptable. Normally we only buy new clients with score > 2000.
09:40
E.g. core i3 has 5000 score
09:40
<badgerbailey>
okay got it
09:41
<alkisg>
Btw with ltsp fat clients, your server can be a simple PC, it doesn't need to be expensive
09:43
<badgerbailey>
okay, thanks for your info
09:45
<alkisg>
You're welcome
09:54
<Hyperbyte>
Hello mr alkisg!
09:54
<alkisg>
Haha, hello Hyperbyte, it looks like I'm the only one he wants to speak to :D
10:01eu^ip-92-42-113- has joined IRC (eu^ip-92-42-113-!5c2a716b@gateway/web/freenode/ip.92.42.113.107)
10:01
<eu^ip-92-42-113->
hi all
10:02
problem: epoptes verify error:num=18:self signed certificate
10:03
..and client is not visible by epo-server...but Successfully fetched certificate from 192.168.1.140:789
10:06
<alkisg>
Hello eu^ip-92-42-113-
10:07
Do you have something weird with regards to your root certificates?
10:07
Is your computer date/time ok?
10:09lbssousa has joined IRC (lbssousa!~lbssousa@177.143.28.213)
10:10badgerbailey has left IRC (badgerbailey!31e48b8a@gateway/web/freenode/ip.49.228.139.138, Quit: Page closed)
10:12
<eu^ip-92-42-113->
time from internet
10:13
epoptes-client run great on lubuntu 15.04 but this problem is with ubuntu 15.10
10:14
<alkisg>
eu^ip-92-42-113-: what is your server called? Did you put "server" in /etc/hosts?
10:15
<eu^ip-92-42-113->
yes same on ubuntu & lubuntu...
10:15
<alkisg>
OK, can you try this from your client?
10:15
EPOPTES_CLIENT_VERIFY_CERTIFICATE=False epoptes-client
10:15
This is a single command, copy/paste it
10:15
If you run that, can you then see the client in the epoptes UI?
10:17
<eu^ip-92-42-113->
ok server can see my ub 15.10 great thnx ;)
10:17
<alkisg>
Wait
10:17
This was temporary
10:17
<eu^ip-92-42-113->
ok
10:17
<alkisg>
You need to upgrade your epoptes client to 0.5.10
10:17
Use the epoptes PPA to do that
10:18
Do you know how?
10:19
<eu^ip-92-42-113->
put ppa to apt-get, update, iremove old ver, instal new?
10:20
<alkisg>
sudo add-apt-repository ppa:epoptes; sudo apt-get update; sudo apt-get dist-upgrade
10:20
That's all
10:20
The problem was in socat, we've fixed it in newer epoptes versions
10:21
<eu^ip-92-42-113->
upgrading now........
10:29robb_nl has joined IRC (robb_nl!~robb_nl@ip-83-134-2-72.dsl.scarlet.be)
10:39kjackal_ has joined IRC (kjackal_!~quassel@onopfy.static.otenet.gr)
10:39kjackal has left IRC (kjackal!~quassel@onopfy.static.otenet.gr, Read error: Connection reset by peer)
10:58adrianorg has left IRC (adrianorg!~adrianorg@179.187.25.178.dynamic.adsl.gvt.net.br, Ping timeout: 260 seconds)
11:00adrianorg has joined IRC (adrianorg!~adrianorg@177.18.169.131)
11:03eu^ip-92-42-113- has left IRC (eu^ip-92-42-113-!5c2a716b@gateway/web/freenode/ip.92.42.113.107, Ping timeout: 250 seconds)
11:20adrianorg has left IRC (adrianorg!~adrianorg@177.18.169.131, Ping timeout: 244 seconds)
11:22adrianorg has joined IRC (adrianorg!~adrianorg@177.134.56.43)
11:34adrianorg has left IRC (adrianorg!~adrianorg@177.134.56.43, Ping timeout: 276 seconds)
11:36adrianorg has joined IRC (adrianorg!~adrianorg@177.18.99.189)
11:36Statler_ has joined IRC (Statler_!~Georg@p54BFB071.dip0.t-ipconnect.de)
11:37
<Statler_>
ltsp-localapps seems not to retrun exit code?
11:37
something like "ltsp-localapps firefox || firefox" doesn't work
11:38
I have x2go-clients on the same server, where ltsp-localapps cannot have success
11:38
in these case I want to define a "fallback" to the serverside app
11:42robb_nl has left IRC (robb_nl!~robb_nl@ip-83-134-2-72.dsl.scarlet.be, Quit: I'm gone, bye bye)
11:45xenthree3 has joined IRC (xenthree3!~xenthree3@h42-57.pool95-168.dyn.tolna.net)
11:45xenthree3 has left IRC (xenthree3!~xenthree3@h42-57.pool95-168.dyn.tolna.net)
11:45kjackal_ has left IRC (kjackal_!~quassel@onopfy.static.otenet.gr, Ping timeout: 252 seconds)
11:48Faith has joined IRC (Faith!~paty_@unaffiliated/faith)
11:51adrianorg has left IRC (adrianorg!~adrianorg@177.18.99.189, Ping timeout: 260 seconds)
11:52adrianorg has joined IRC (adrianorg!~adrianorg@186.213.154.21)
12:07Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
12:12GodFather_ has joined IRC (GodFather_!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com)
12:14GodFather_ has left IRC (GodFather_!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Client Quit)
12:14GodFather_ has joined IRC (GodFather_!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com)
12:14GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 260 seconds)
12:14GodFather_ is now known as GodFather
12:15adrianorg has left IRC (adrianorg!~adrianorg@186.213.154.21, Ping timeout: 240 seconds)
12:16kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:e420:9361:bc6d:ca35)
12:17adrianorg has joined IRC (adrianorg!~adrianorg@177.134.62.136)
12:17GodFather is now known as GodFodder
12:56Leolo_2 has left IRC (Leolo_2!~fil@24-54-31-128.mg.cgocable.ca, Ping timeout: 260 seconds)
13:28gdi2k has joined IRC (gdi2k!~gdi2k@49.151.17.102)
13:32
<sbalneav>
Statler_: You're right, it doesn't, but there's no easy way to make it to.
13:33
ltsp-localapps just sets an xprop, then asynchronously, the command is run.
13:34
There isn't a good way to pass the exit code of the program back to ltsp-localapps.
13:38
<||cw>
does it need to be async?
13:40
<sbalneav>
The thin client doesn't have an ssh server running on it. So the only method of communication to go back from the server to the client is via the X server itself.
13:40
X itself doesn't have any provision for an "exec" function, so what we did was define an X prop that sits on the root window.
13:40
We have a "server" that runs on the thin client, that listens for changes to this property
13:41
On the LTSP server, you essentially just change this property with the name of the program you want to execute.
13:42
On the thin client, this server process that's listening to the property changes then executes the program requested.
13:43
So the ltsp-localapps script isn't actually doing any executing, it's just setting an xprop.
13:44
So long as it succeeds at setting the xprop, ltsp-localapps "succeeds"
13:44
if the server process running on the thin client can't execute the program, the ltsp-localapps script doesn't know about it.
13:45
<||cw>
ah
13:45jamorais has joined IRC (jamorais!bb4c818e@gateway/web/freenode/ip.187.76.129.142)
13:46
<jamorais>
ok! Good morning!
13:46
<sbalneav>
Morning jamorais
13:46
<||cw>
so to make it async, you'd need the script to wait for the client to send something back over ssh or whatever, maybe look for a file to be touched, with a timeout, which could get error prone
13:47
<sbalneav>
It would be much harder to do, yes.
13:47
<jamorais>
My english is very poor, but let's go to chat
13:47
<||cw>
woulnd't be hard to implement, but would be hard to make reliable, and would likely slow down the non-thin clients a lot
13:47
<jamorais>
This IRC is about Epoptes?
13:48
<sbalneav>
jamorais: It's about LTSP, and Epoptes. I don't know anything about Epoptes myself, however.
13:49
But ask your question, and hang around several hours for the answer, and hopefully when someone who does know sees it, they'll respond.
13:50
<jamorais>
There any version of Epoptes that have options put time on clients?
13:50
<sbalneav>
"Put time"?
13:50
You mean set the clock?
13:51
<jamorais>
Yes! thirty minutes for exemple
13:51
Here is a computers labs
13:51
<sbalneav>
Oh, you mean set a login limit.
13:52
I don't know. alkisg would be the fellow to ask.
13:52
<jamorais>
Yes!
13:52
Here labs computers at school
13:52
<sbalneav>
alkisg would know. Hang around and wait for him to become active.
13:53
<jamorais>
And the students, do not stop use a computers
13:54
Here I am testing Epoptes wiht LTSP.
13:57jamorais has left IRC (jamorais!bb4c818e@gateway/web/freenode/ip.187.76.129.142)
14:16ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
14:18
<alkisg>
jamorais, it wasn't an epoptes issue, the easiest way to do what you wanted would be to set a screensaver that exited the session, i.e. an ltsp issue :)
14:22
<||cw>
so much for "hang around several hours"
14:22mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
14:22
<alkisg>
Statler_: it's possible to patch ltsp-localapps / ltsp-localappsd to support an additional LTSP_COMMAND_RESULT xprop that travels the other way
14:23
If you send a proper implementation of that, I don't see why it wouldn't get accepted
14:29
<sbalneav>
alkisg: Problem with that would be, you'd somehow have to queue results.
14:29
<||cw>
how quickly does the client side get the message?
14:29
<sbalneav>
right now, if you do "ltsp-localapps xxx; ltsp-localapps yyy; ltsp-localapps zzz", all 3 will launch fine.
14:30
<alkisg>
sbalneav: one easy way would be to use mktemp to get a random LTSP_COMMAND_RESULT_XXXXX name, and pass it to ltsp-localappsd
14:30
<||cw>
sbalneav: no it would still work fine since ltsp-localapps would wait for the reply before exiting
14:31
<alkisg>
||cw: many processes can run in parallel though
14:31
Even from different user shells
14:31
<sbalneav>
||cw: That means you can only run one localapp at a time, though.
14:31
alkisg: Not sure how we'd do the server side, registering and listening for xprops.
14:32
<alkisg>
Similar to how ltsp-localappsd does it, i.e. wait for LTSP_COMMAND_RESULT_XXXX to change, but only for 1-2 seconds, and return failure if the timeout passes
14:32
<||cw>
would a file be simpler?
14:33
<alkisg>
I see this as a minor feature request, so no worries I'm not suggesting to implement it :D
14:33
But I wouldn't object to a proper patch that does implement it if Statler_ wanted to do it
14:33
<sbalneav>
Agreed.
14:33MRH2 has joined IRC (MRH2!~Thunderbi@233.47.187.81.in-addr.arpa)
14:33
<||cw>
server touches a temp file, sends filename with the xprop, client deletes file, server sees it and returns success, but with a X second timeout where server deletes the file and returns fail
14:34
<Statler_>
another way was to clear determine if the client is really a ltsp-client
14:34
<alkisg>
||cw: yup, ssh can be used for that, listening on a socket is easy too
14:35
<MRH2>
general q does the greek schools ppa get updated in to the main ltsp package?
14:35
<alkisg>
localapps could also be implemented by listening to the ltsp's ssh stdin, i.e. right after the "echo LTSPROCKS" part
14:35
MRH2: I'm updating the greek schools ppa whenever there are significant changes in ltsp, yes
14:37
<Statler_>
is there something in the environment variables that I can evaluate to determine if I have a ltsp-client or something else?
14:39
<MRH2>
sorry i meant the other way around as the greek ppa seems to lead at least when i last tested the 2. or does development from the greek schools go directly in to ltsp.
14:40
<alkisg>
MRH2: I'm an ltsp developer and I'm also maintaining the greek schools ppa. When some significant work is done in ltsp, I'm releasing new versions to the PPA. After some time, distros also get it. For Ubuntu 16.04, those two are temporarily in sync.
14:41
Statler_: echo $LTSP_CLIENT
14:41
<MRH2>
ok cool so u release to both
14:41
i was wondering how they stay in sync
14:43
<alkisg>
I'm not in charge of releasing to any distros, those happen by their maintainers
14:43
Although I'll probably start to maintain ltsp in ubuntu since 16.04...
14:46
<Statler_>
tank you alkisg
14:46
thank
14:47
I see my problem: I'm via x2go logged in ;)
14:47
I must take a thin client to test the environment
14:48
<MRH2>
i guess i see development more on ur side and concerned about things becoming diverged
14:48
:)
14:54
even an official ltsp-non-chroot
14:55
<alkisg>
MRH2: all my ltsp development goes upstream, or locally in "sch-scripts", none of it goes only to the ppa
14:55
<MRH2>
ah
14:55
cool
14:56
thanks for clearing that up alkisg :)
15:08lmds_ has left IRC (lmds_!~lmds@tui.pi-et-ro.net, Ping timeout: 240 seconds)
15:18metaf5 has left IRC (metaf5!~metaf5@31.220.42.38, Ping timeout: 260 seconds)
15:26kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:e420:9361:bc6d:ca35, Quit: No Ping reply in 180 seconds.)
15:27kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:790f:ff4d:499c:57c2)
15:31kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:790f:ff4d:499c:57c2, Client Quit)
15:32kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:790f:ff4d:499c:57c2)
15:34GodFodder has left IRC (GodFodder!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Remote host closed the connection)
15:45GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com)
16:22Leolo_2 has joined IRC (Leolo_2!~fil@24-54-31-128.mg.cgocable.ca)
16:28kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:790f:ff4d:499c:57c2, Ping timeout: 260 seconds)
16:34kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:e420:9361:bc6d:ca35)
16:35Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas, Remote host closed the connection)
16:40GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 276 seconds)
16:45kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:e420:9361:bc6d:ca35, Ping timeout: 260 seconds)
16:48kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:790f:ff4d:499c:57c2)
16:49GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com)
17:28lmds_ has joined IRC (lmds_!~lmds@tui.pi-et-ro.net)
17:35
<vsuojanen>
Hi, has anyone played with Edubuntu Live USB?
17:35
https://edubuntu.org/documentation/ltsp-live
17:35
<alkisg>
vsuojanen: edubuntu isn't really active any longer
17:35
<vsuojanen>
is it still ..ok ? :)
17:36
<alkisg>
No, it didn't even ship a 16.04 version
17:36
That said, it's really easy to ship a live ltsp in a usb stick
17:36Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving)
17:36
<vsuojanen>
it was 6th or 7th in google results for 'ltsp'
17:40
alkisg: I tried the live ltsp method and I liked it. There were cons also
17:41
<alkisg>
vsuojanen: I'm usually having a full ltsp installation in a usb stick, but instead of using /opt/ltsp/images/i386.img, I'm directly exporting /dev/sdb1, so that more caching is done, and it's a lot faster that way, and saves a lot of space
17:44
<vsuojanen>
it's easy and fast to setup but there is ldm that needs connection to the server and then there is grub with default recovery feature. it has some annoyant issue with the server when it boots overlayfs
17:44
<alkisg>
LDM on the stick? No, it's using lightdm
17:44
<vsuojanen>
the annoyant issue is default grub recovery
17:45
<alkisg>
I've never seen the issues you say, I don't know what method you used
17:45
I've never used edubuntu's live ltsp usb stick method
17:46
<vsuojanen>
I followed your mehthod... it was couple months back that you mentioned that
17:47
http://irclogs.ltsp.org/?d=2015-09-17
17:47
<alkisg>
Was it the "regular installation" method, or the "nbd image in a stick" method? looking...
17:48
Ah, that's the cow method, to prevent the stick from being overused
17:48
<vsuojanen>
anyways i did not use ldm but switched to lightdm. yes. nbd image in stick method :)
17:48
<alkisg>
No no that's a third method
17:48
It's a regular installation with cow booting
17:49
It's hard to set it up properly, but it's very flexible
17:50
To omit LDM, you create /etc/lts.conf with a couple of directives
17:51
That way you can use lightdm in cow mode
17:51
<vsuojanen>
i would set up it for first ltsp installation or demo
17:51
<alkisg>
KEEP_DEFAULT_DISPLAY_MANAGER=True or something
17:52
Also I don't see why grub recovery would be activated, I never got that bug either
17:56
<vsuojanen>
to me it didn't activate grub recovery because grub or ubuntu/debian developers have made default GRUB_RECORDFAIL_TIMEOUT=30 when recordfail=1. and grub or ubuntu sets recordfail=1 in /etc/grub.d/00-header
17:57
so the annoyance was 30s timeout for booting after the very first boot
18:00
i did not go further with such small issue but I think that was related to overlayfs and ubuntu grub2 configs
18:01
<alkisg>
It sounds reasonable... I didn't use the ubuntu grub2 configuration that's probably why I didn't see it
18:01
It would be easy to remove recordfail, or to reset it from the ltsp initramfs script
18:01
<vsuojanen>
yeah. I really missed syslinux when i searched the reason for that issue
18:04MRH2 has left IRC (MRH2!~Thunderbi@233.47.187.81.in-addr.arpa, Quit: MRH2)
18:39Statler_ has left IRC (Statler_!~Georg@p54BFB071.dip0.t-ipconnect.de, Remote host closed the connection)
19:18
<Leolo_2>
can things like LDM_FORCE_SESSION=xfce get set in lts.conf?
19:32
<sbalneav>
Leolo_2: Is that currently something we honour?
19:38
<alkisg>
Yup to both questions :)
19:39
Actually putting it in lts.conf is exactly what it was coded for
19:39
<sbalneav>
I can't remember all the lts.conf variables anymore :D
19:39
<alkisg>
I don't think anyone ever has, we didn't even manage to document all of them!
19:40
<sbalneav>
https://code.launchpad.net/~ltsp-upstream/+git/libpam-external
19:41
<alkisg>
sbalneav: external? what's that for?
19:41
Hehe, git!
19:41
<sbalneav>
So, one of the issues is always the C coding.
19:42
we're hoping to reduce it down to libpam-sshauth, but then I got the brilliant idea.
19:42
<alkisg>
"Can't do it. I hate the switch statement." Hahaha
19:42
<sbalneav>
What if I wrote a pam module.... that wasn't a pam module?
19:42
<alkisg>
And code the rest of it in shell?
19:43
<sbalneav>
Instead, it just acts as a shim... and passes pam messages, via stdin and stdout, to some external program
19:43
right.
19:43
!paste
19:43
<ltsp`>
paste: the LTSP pastebin is at http://ltsp.pastebin.com. Please paste all text longer than a line or two to the pastebin, as it helps to reduce traffic in the channel. Don't forget to paste the URL of the text here.
19:43
<alkisg>
I was thinking to implement ldm in shell, and keep the greeter in python...!
19:43
<sbalneav>
http://pastebin.com/KKWEmvhU
19:44
It's not complete, but with libpam_external, and that bit of python, it does most of what libpam_sshauth does.
19:44
And all the ssh-y bits are in python.
19:44
<alkisg>
That's a very good idea :)
19:44
<sbalneav>
So:
19:45
I've got lightdm-webkit(2)-greeter whipped into shape
19:45
So we can write greeters in html/js
19:45
<quinox>
:o
19:46
<sbalneav>
I've now got (or in the process of getting) libpam_external and libnss_external close to being in testable condition, so we can script PAM and NSS stuff in scripting language.
19:46ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
19:47
<sbalneav>
So, apart from nss/pam_external all the stuff that LTSP6 could use would be... scripts.
19:47
We shall see. Some more work left to do. Some, haha. Lots.
19:47
But, I'm excited.
19:49
I'm writing the man page for libpam_external now.
19:49
<alkisg>
Cool!! Hopefully me and vagrantc will make it to debconf16 and make some progress with the pam integration there
19:49* alkisg needs to go pick up the kids, later! :)
19:49
<sbalneav>
WHere's that?
19:50
ah, yeah, sa
19:59lbssousa has left IRC (lbssousa!~lbssousa@177.143.28.213, Quit: Leaving)
20:02epoptes_user9 has joined IRC (epoptes_user9!b187c003@gateway/web/freenode/ip.177.135.192.3)
20:03kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:790f:ff4d:499c:57c2, Ping timeout: 260 seconds)
20:10
<Leolo_2>
alksig : having PAM run shell code is about as secure as something very unsecure
20:11kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:790f:ff4d:499c:57c2)
20:13
<sbalneav>
Leolo_2: There are already several pam modules that execute shell code.
20:13
One ships as part of pam.
20:14
pam_exec, pam_script, etc.
20:14
In fact, pam_script sets PAM_AUTHTOK and PAM_OLDAUTHTOK as environment variables :D
20:14
Which, I'd like to point out, I'm not doing. :D
20:15
Leolo_2: https://code.launchpad.net/~ltsp-upstream/+git/libpam-external
20:15
If you have any comments or would like to make suggestions to the code, feel free. I'm developing it now.
20:16
<Leolo_2>
just the general idea that PAM is running a shell script rubs me all wrong
20:16
yeah, pam_exec can do that... but pam_exec can't authorize anyone
20:17
<sbalneav>
pam_script can
20:17* Leolo_2 shakes his head in disbelief
20:17
<Leolo_2>
what is the world coming to !
20:17
<sbalneav>
So, do you have an *actual* objection, or do you just not like it?
20:19
Like I say, have a look at the code, and if you feel something's not right, I'm all ears.
20:19
<Leolo_2>
I thought it was clear from the begining that it was "just not like it"
20:20
I've been reading LTSP code for the last week. It's very well writen
20:20
I just feel shell scripts are to fragile for something as important as PAM authentification
20:20
I am perfectly prepared to be wrong on this point
20:21
<sbalneav>
No, you said it was "about as secure as something very unsecure". I'm asking, specifically, how calling an externel helper program to do the authentication is any less secure than, say writing a pam module in pure C and verifying there's no null pointer exceptions, buffer overflows, etc?
20:22
<Leolo_2>
C programs get static checks, shell scripts don't
20:22
so typos are caught early
20:23
C programers know about security issues, and while coding a PAM module (one hopes) put them utmost in their mind
20:23
<sbalneav>
I did, when I wrote libpam_sshauth
20:24
I just recently had to file a security bug for unintended root escalation in the module.
20:24
<Leolo_2>
yeah, then you get libpam_sshauth which is pretty complex and depends on openssh not having errors in it (safish bet)
20:24
<sbalneav>
So? Libpam_ldap is pretty complex and depends on ldap not having errors in it :D
20:25
Errors happen, regardless. And being able to write an authentication module in a modern scripting language without buffer overflow probelms, proper exception handling, etc. Might, in the long run, be *more safe* than custom-coding a pam module in C from scratch every time.
20:26
I'm simply playing devils advocate here.
20:26
<Leolo_2>
and I'm listening
20:26
your points are not invalid
20:27
<sbalneav>
To the extent that libpam_external would be "error free" and "secure", it then places any potential bugs in an authentication mechanism in a much-easier-to-understand-and-debug program than wading through a PAM module's C source.
20:45
<Leolo_2>
if I have an issue with ssh sockets and fuse.unionfs, who should I file a bug with?
20:45
or do I just not bother - pretty sure everyone is going to say "not our problem"
20:46
<sbalneav>
https://github.com/rpodgorny/unionfs-fuse?
20:47
That the source for it?
20:47
What's the issue?
20:50
<Leolo_2>
ssh -S socket does a bind/listen on socket.RANDOM it then does link( "socket.RANDOM", "socket" ); unlink( "socket.RANDOM" )
20:50
this fails to create a usable socket
20:51
<sbalneav>
ok, is that the source? If so, I can dig into it this long weekend, and try to find where the problem is.
20:52
Always easier to get a problem looked at if you can a) identify exactly where in the code the problem is or b) (ideally) include a patch in the bug report :D
20:53
<Leolo_2>
well if I change the link/unlink to rename, it works
20:54
<sbalneav>
in ssh? Unlikely they'll accept a patch; the openssh guys are very unwilling to accept any input from outside the "golden circle" of ssh devels.
20:55
So it'd be far easier to find out what in the unionfs-fuse semantics causes it to fail, and fix that.
20:55
We've tried before to get things looked at in ssh here in ltspland :D
21:05
<Leolo_2>
another work around would be to have LDM_SSH_EXEC=/opt/openssh/ssh
21:05
and have plugins/ssh/ssh.c respect that
21:08
https://github.com/rpodgorny/unionfs-fuse/issues/46
21:52
<alkisg>
(11:11:00 μμ) Leolo_2: alksig : having PAM run shell code is about as secure as something very unsecure ==> security isn't in the language, it's in the programmer
21:57
Leolo_2: btw, can't you use some more recent kernel now that overlayfs is mainlined? doesn't centos have backported kernels?
22:04
!learn alkisg-todo as test the null cipher with https://launchpad.net/~yoda-jazz-kc/+archive/ubuntu/hpn-ssh
22:04
<ltsp`>
The operation succeeded.
22:04
<alkisg>
!alkisg-todo
22:04
<ltsp`>
alkisg-todo: (#1) support xnbd-proxy for local caching: https://bitbucket.org/hirofuchi/xnbd/wiki/Home#!scenario-2-simple-proxy-server-distributed-copy-on-write, or (#2) Support UEFI, or (#3) support for per-user login commands in lts.conf, or (#4) put panic=60 in the kernel cmdline, or (#5) document bind-interfaces, or (#6) test aes-ni instruction set for faster ssh, or (#7) test the null cipher with https://launchpad.net (1 more message)
22:04
<alkisg>
!more
22:04
<ltsp`>
/~yoda-jazz-kc/+archive/ubuntu/hpn-ssh
22:05
<alkisg>
!forget alkisg-todo 6
22:05
<ltsp`>
The operation succeeded.
22:05
<Leolo_2>
alkisg - maybe
22:06
iirc, elrepo has more recent kernels
22:06
<alkisg>
Leolo_2: It would make it more aligned with ltsp upstream
22:07
E.g. ltsp-update-image --cleanup also uses overlayfs, it's not only about the initramfs
22:07
How are things looking so far? Ready to ditch ltsp and go for drbl yet? :)
22:08
<Leolo_2>
everything is working to my satisfaction
22:08
next week at some point I deploy
22:09
<alkisg>
Nice! If you have any patches that should make it upstream, either under the shared dir or under redhat/ etc, do file bug reports/merge requests etc
22:09
<Leolo_2>
one thing is that some of the problems are the LTSP+CentOS is too old (nbd v2 for instance)
22:10
some of the problems is that LTSP does things in ways I don't like, so I do them myself the way I like (/etc/dhcp/dhcpd.conf vs /etc/ltsp/dhcpd.client)
22:10* alkisg thinks dnsmasq should be the default instead of isc-dhcp...
22:11
<Leolo_2>
and some problems are because of my current set up (select french vs english based on the province a host boots in)
22:11
<alkisg>
or at least someone that uses isc-dhcp, should support it like we do with `ltsp-config dnsmasq`
22:11
<Leolo_2>
and further problems because I'm an old crmugdeon
22:12
btw ltsprepo.s3.amazonaws.com seems to be gone
22:13
http://ltsprepo.s3.amazonaws.com/rpm/el6 at least doesn't work
22:13
<alkisg>
I don't think we have anyone at the centos/fedora/rhel etc front anymore
22:13
The only one still working with RPMs would be cyberorg, for openSUSE
22:14
So I've never even heard of those repositories
22:15
I think opensuse does offer a cross-distro build service that comes with a repository that you might be able to use...
22:18GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 246 seconds)
22:24GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com)
22:26GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Remote host closed the connection)
22:27GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com)
23:27* Leolo_2 makes the mistake of running dracut -v
23:28
<Leolo_2>
all that cruft... back in my day you could boot off a floppy !
23:37
so nbd v3 doesn't work on CentOS 6
23:50
nbd-client runs fine
23:51
dd if=/dev/nbd9 of=/dev/stdout count=1024 bs=1 | hexdump -C
23:51
hangs