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


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

02:32
<sbalneav>
alkisg: ping
05:05alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 260 seconds)
05:36ricotz has joined IRC (ricotz!~ricotz@p5B2A97D8.dip0.t-ipconnect.de)
05:36ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
06:06cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 240 seconds)
06:07cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
06:56kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:d05c:ad72:368e:269c)
07:01alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
07:15kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:d05c:ad72:368e:269c, Ping timeout: 264 seconds)
07:25kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:d05c:ad72:368e:269c)
14:54
<alkisg>
sbalneav: eh, that was 5:32 in the morning, not too likely for me to pong :)
14:55adrianorg has left IRC (adrianorg!~adrianorg@189.58.225.235.dynamic.adsl.gvt.net.br, Ping timeout: 244 seconds)
14:55
<sbalneav>
alkisg: Quick questionfor you
14:55
for libpam-external
14:56
right now, the "command" is a single character
14:56
<alkisg>
Sure, shoot! Although I'd imagine I'd be asking the questions to you... :D
14:56
<sbalneav>
So > for a username prompt
14:56
: for a password prompt.
14:56
etc
14:56
So if you want a password prompt, you'll do:
14:56
:Password:
14:57
Or
14:57adrianorg has joined IRC (adrianorg!~adrianorg@189.58.226.223.dynamic.adsl.gvt.net.br)
14:57
<sbalneav>
>Username:
14:57
Now, would it be more intuitive, in your opinion, if I changed those from single characters, into simple commands:
14:57
pwprompt Password:
14:57
userprompt Username:
14:58
etc.
14:58
<alkisg>
I'm missing some background so I can't yet imagine exactly how this works
14:58
<sbalneav>
OK
14:58
So pam-external calls an external script.
14:58
<alkisg>
Where is libpam-external's branch?
14:59
<sbalneav>
launchpad.net/~ltsp-upstream/+git/libpam-external
14:59
So, pam-external's just a shim: it calls an external program that actually drives the pam authentication process
14:59
<alkisg>
The plan is for that to "replace" libpam-sshauth, right?
15:00
along with the external script
15:00
<sbalneav>
Right.
15:00
libpam-external is like a "pam toolkit"
15:00
You tell it to do things like prompt the user, get a password, etc.
15:00
<alkisg>
I'm also missing a few bits on how pam works. This will only work for auth, to authenticate users and maybe passwd, to let them change their password, but it won't support listing users etc?
15:01
<sbalneav>
Right, that's what the companion "libnss-external" is for
15:01
<alkisg>
Nice
15:01
So e.g. lightdm wants to authenticate a user
15:01
It shows a prompt, gets a username, calls the pam stack
15:01
<sbalneav>
right
15:02
<alkisg>
You have a hook there and you get what, just the username at that point, or the combination username/password?
15:02
<sbalneav>
Well, the way pam works is this.
15:02
You call pam
15:02
Pam says "ask for a username"
15:02
lightdm asks for a username
15:02
passes result back to pam
15:02
pam asks for password
15:02
lightdm prompts for password
15:03
returns result to pam
15:03
pam does the authentication
15:03
off you go.
15:03
what *pam-external* does, is hand off those bits to an external script.
15:04
the *script* says (on stdout) "prompt for a username"
15:04
pam-external translates this into a pam call
15:04
and so on, up to lightdm
15:04
<alkisg>
static int usernameprompt_cb (pam_handle_t *pamh, char **output, char *input); ==> is that a standarized name by pam, or did you name it that way yourself?
15:04
<sbalneav>
That's my callbac
15:05
*it* calls pam_get_user
15:05
See, I read stdin
15:05
get an "instruction"
15:05
Call the appropriate pam call
15:05
get the result
15:05
put it on stdout
15:06
So the script just talks on stdin and stdout
15:06
and it *drives* the pam authentication process
15:06
So right now, the "instructions" are single characters
15:07
What I'm wondering is: would it be clearer to actually make the instructions strings
15:07
i.e. instead of ':' for "get a password", it's "pwprompt" or whatever
15:07
<alkisg>
I'm trying to see if you're mapping from some standarized pam command names to stdio, then yeah it would indeed make sense to use those #defines in stdio as well
15:08
<sbalneav>
I suppose I could use something close to the pam names
15:08
pam_get_user
15:08
pam_get_user Username:
15:08
<alkisg>
(06:02:37 μμ) sbalneav: Pam says "ask for a username" ==> is that a special function? or a const string parameter?
15:09
<sbalneav>
That's a special function.
15:09
It either pulls the pam username from the stack if it's already defined, or prompts the user for it.
15:09
That's how pam modules "stack"
15:10
I.e. once the first modules prompted for a username, the resto of the modules in the stack don't need to anymore.
15:10
<alkisg>
So lightdm would prompt for a username, not the script. The script would just get a ... notification?
15:11
<sbalneav>
No, the script prompts for the username
15:11
have a look at:
15:11
launchpad.net/~ltsp-upstream/+git/pamexternal-sshauth for an example script
15:12
but now that I think about it, you're right, I should probably make the instructions close to the pam library names as I can.
15:12
easy to change
15:13
<alkisg>
if prompt[1]: print '>' + prompt[0] else: print ':' + prompt[0]
15:13
This is hard to read, yeah
15:14
<sbalneav>
right.
15:14
ok, human readable names it is :D
15:14
I'm easily convinced :D
15:14
<alkisg>
But I still haven't understood the whole thing...
15:15
Can we start the events from lightdm again?
15:15
I haven't understood at all when the ssh call comes in (paramiko, I assume)
15:16
<sbalneav>
Right, paramiko's the python ssh library
15:16
ok
15:16
lightdm starts
15:16
calls pam_start
15:16
pam_start loads pam_external
15:17
pam_external spawns sshauth script
15:17
<alkisg>
(thanks, this is exactly how I wanted to hear it in order to get a better understanding of pam...)
15:17
<sbalneav>
script prompts "Username?"
15:17
pam_external calls pam_get_user
15:17
pam_get_user asks lightdm to prompt for username
15:17
lightdm prompts
15:17
user enters
15:18
lightdm hands username to pam
15:18
pam hands username to pam_external
15:18
pam_external prints username on stdout
15:18
script reads it. Now script has username
15:18Fenuks has joined IRC (Fenuks!~Fenuks@95.191.242.41)
15:18
<sbalneav>
script prompts: "Password?"
15:19
pam_external reads it on stdin
15:19
translates to pam call
15:19
pam tells lightm to prompt for password
15:19
lightdm prompts "Password?"
15:19
user enters
15:19
passes back to pam
15:19
pam -> pam_external
15:19
prints on stdout
15:19
script reads it
15:20
now script has username, password
15:20
does auth
15:20
auth works
15:20
script prints PAM_SUCCESS
15:20
passes back to pam_external
15:20
<alkisg>
Ah, you're translating a big part of the pam stack to stdio conversation... wouldn't it be easier to e.g. use some python pam bindings directly? I imagine python does have pam bindings...
15:20
<sbalneav>
It does
15:20
but now you're limited to writing in python.
15:21
pam external allows you to write in ANYTHING
15:21
C
15:21
Python
15:21
Perl
15:21
Shell script
15:21
whatever
15:21
since you conduct the conversation via text on stdin/stdout
15:22
<alkisg>
True, but we mostly care about implementing the ssh part, right? Do you think we'll be using it to implement other methods of authentication as well?
15:22
<sbalneav>
Right, *we* only care about the ssh part. But if I'm gonna write a tool... I want to write a general purpose one :D
15:23
<alkisg>
If python (or even your initial .c code) can handle the ssh authentication, do you think it makes sense to have a bigger layer/library there?
15:23
For example, ldm was rewritten to support plugins
15:23
That reduced the code readability though
15:23
<sbalneav>
Well, pam_external's actually pretty small. It's less than 1000 lines of code.
15:24
And it's a general purpose shim, so all the authentication work is done in the script.
15:24
<alkisg>
E.g. suppose we want to implement the ssh auth/passwd/nss part. How long would that be (a) with python bindings, and (b) with libpam_external?
15:24
<sbalneav>
Roughly equal
15:24
BUT
15:25
<alkisg>
So we just have an additional 1000 lines to learn, and a new "protocol"...
15:25
<sbalneav>
The advantage is, you can TEST your pam-external scripts just at the command line, they don't have to run under pam
15:25
since they just talk via stdin/out
15:25
so, you want to test: it says "Username:?" you just *type* the username
15:26
with pam python bindings you'd *have* to test them via running lightdm in a test window, or something.
15:26
<alkisg>
...or a fake stdio-dm, yeah
15:27
Some hundreds lines would be needed to implement that as well
15:27
<sbalneav>
You can simply take that python script and just run it as is.
15:28
ssh_authenticate.py host=blah
15:28
It'll say ")Username:"
15:28
You say "alkisg"
15:28
It'll say ":Password:"
15:28
you say "i'm too sexy for my clothes" or whatever :D
15:28
Then it'll do the auth
15:28
<alkisg>
I can't really give good advice on that, the pam callbacks haven't yet settled down in my brain... :)
15:29
I need to read more about it and maybe even code a little to grasp the whole concept
15:29* quinox tests PAM stuff from the command line with http://pamtester.sourceforge.net/
15:29
<sbalneav>
So do I, quinox
15:29
But with this scheme, you don't even need that :D
15:30
<alkisg>
sbalneav: me and vagrantc and Phantomas will probably make it to debconf16, so do have some things ready till then, for us to play with... and hopefully integrate them to ltsp
15:31
<sbalneav>
That's my goal
15:31
I'm workin' like a madman :D
15:31* alkisg needs to help his daughter with her studies, bb for now guys!
15:31
<sbalneav>
Cheers
15:35Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 260 seconds)
15:35kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:d05c:ad72:368e:269c, Quit: No Ping reply in 180 seconds.)
15:37kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:d05c:ad72:368e:269c)
15:40Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack)
16:05ltsp_fan has joined IRC (ltsp_fan!29320220@gateway/web/freenode/ip.41.50.2.32)
16:07
<ltsp_fan>
Hi everybody, thanks for your all your help: I am helping out at a school that has 20 RPI loaded with berryterminal connecting to an edubuntu server
16:07
everything worked in 2014
16:07
then this year I did a fresh install of edubuntu 12.04.05 and now sound is choppy
16:08
vlc says pulseaudio is to blame
16:08
any suggestions?
16:09
then my second question is: I came across UbuntuLTSP/RaspberryPi (I think by alkisg), but that requires RPI2 or higher which we don't have
16:10
<sbalneav>
ltsp_fan: https://wiki.archlinux.org/index.php/PulseAudio/Troubleshooting#Choppy.2Fdistorted_sound
16:11
<ltsp_fan>
"https://help.ubuntu.com/community/UbuntuLTSP/RaspberryPi" mentions Berryterminal and Pinet as alternatives, is Pinet better?
16:12
<sbalneav>
Define "better"
16:12
<alkisg>
(07:08:00 μμ) ltsp_fan: then this year I did a fresh install of edubuntu 12.04.05 and now sound is choppy => how did you install it, with berryterminal?
16:12
<ltsp_fan>
edubuntu 12.04.05 is on the server, the I left the rpi's as they were
16:13
apparently berryterminal has no updates since 2013
16:13
<alkisg>
Yeah
16:13
!raspberrypi
16:13
<ltsp>
raspberrypi: (#1) Ubuntu/LTSP on Pi 2: https://help.ubuntu.com/community/UbuntuLTSP/RaspberryPi, or (#2) Debian/LTSP (with raspbian chroot) on Pi: http://cascadia.debian.net/trenza/Documentation/raspberrypi-ltsp-howto/, or (#3) unofficial Ubuntu/LTSP (with raspbian chroot) on Pi: http://pinet.org.uk/
16:13
<alkisg>
So, rpi1 requires special compilation for arm6
16:13
And most distros don't bother with that
16:14
That's what raspbian did, it provided a repository for armv6
16:14
So for rpi1, you need something raspbian based
16:14
<ltsp_fan>
berryterminal worked
16:14
<alkisg>
Yup, arm6 too, but unmaintained
16:14
While raspbian is maintained
16:15
Normal debian and ubuntu support arm7, i.e. rpi2 and rpi3
16:15
So the best route is to build a raspbian chroot, i.e. (#2) or (#3)
16:15
The server works fine with either ubuntu or debian, you choice
16:15
<ltsp_fan>
my first question, I suppose is, how come everything worked before and now it doesn't, what about 12.04.05 is different from 12.04.x that made things stop working
16:16
<alkisg>
I don't think you'll find anyone willing to help with kernel/sound issues on a deprecated (berryterminal ) software, when there is other software (raspbian) that is maintained
16:16
<ltsp_fan>
@sbalneav, i did play around with pulseaudio settings
16:17
sure, that's fair, I was just curious. So on to my second question
16:17
<sbalneav>
ltsp_fan: What did you do?
16:17
<alkisg>
With raspbian you'll even get the new KMS driver, which in time will even get 3D acceleration etc. Maintained...
16:19
(one reason why it could have failed, is that the old installation was 12.04.1, i.e. kernel 3.2, while 12.04.5 comes with kernel 3.13)
16:19
<ltsp_fan>
@sbalneav I lowered the sampling rate and it did help, but not perfectly, it was just strange how things worked well before and then stopped working, I realise that 12.04.5 must be very different from versions before.
16:19
ahh exactly
16:20
so a newer kernel can make some things worse ? it seems.
16:20
<sbalneav>
Of course :D
16:20
<alkisg>
Sure, it can break graphics, cpu, file system, all of it
16:20
<sbalneav>
Kernels keep getting bigger
16:20
<alkisg>
It's called "regressions" :)
16:20
<sbalneav>
So do all the user programs :D
16:20
If your cpu stays the same..... performance will suffer :D
16:20
<ltsp_fan>
man that's sad, I thought the point of an LTS release is to avoid this
16:21
<alkisg>
3.2 wouldn't boot with new hardware
16:21
<sbalneav>
You moved from one LTS release to another
16:21
<alkisg>
That's the point of LTS releases, to provide new kernels for new hardware
16:21
<sbalneav>
It's still an upgrade.
16:21
<alkisg>
You can just install the 3.2 kernel on 12.04.5, it's easy
16:21
<ltsp_fan>
ahhh, I didn't know that
16:21
<alkisg>
*if* that's the issue...
16:21
The best route is to install 16.04 on the server, and a raspbian chroot
16:22
That's a maintained combination :)
16:22
<ltsp_fan>
ok thank you, you have both satisfied my curiosity, so onto the better solution
16:22
ok so raspbian chroot
16:22
is that what pinet does?
16:23
<alkisg>
pinet is about raspbian chroot on ubuntu server, yes
16:23
<ltsp_fan>
great!
16:24
<alkisg>
It basically uses ltsp, but has a script for autoconfiguration
16:25
<ltsp_fan>
ok, we're honing in on a solution
16:25
<alkisg>
I don't know more about it, I stopped caring when I read its users say "ltsp is dead, long live pinet" in some forums, which is totally inaccurate since pinet is just a couple of scripts on top of ltsp. :)
16:26
<ltsp_fan>
those are very ungrateful users, I'm sure it is not from the pinet author.
16:27
<alkisg>
I'm sure too, we spend months helping him implement it :)
16:28
<ltsp_fan>
my final decision I suppose is should I try raise funds to get newer pi's and use UbuntuLTSP/RaspberryPi or will pinet produce the same acceptable (though mediocre) experience I had before in 2014?
16:28
with the current 20 rpi's
16:29
<alkisg>
What are your server specs?
16:29
Exact cpu model and ram?
16:30
rpi3's can almost work as ltsp fat clients, which makes a big difference from thin clients as they run things locally with their own cpu/ram
16:30
But in general, core i3's are the best clients :D
16:30
<ltsp_fan>
i7 3.6 Ghz 16Gb Ram
16:30
a good server
16:31
<alkisg>
OK that server with 2-3 bonded gigabit NICs and a good switch should give a good experience for *thin* clients that rpi's are
16:31
!flash
16:31
<ltsp>
flash: Yes, flash sucks. An HD full screen 30 fps video needs 2.5 Gbps bandwidth (1920×1080×4×30)! Make sure you have LDM_DIRECTX=True in your lts.conf file, or if it's just youtube you're after, try some flash replacing plugin like http://linterna-magica.nongnu.org
16:31
<alkisg>
You'll never be able to properly watch full screen youtube etc
16:31
Thin clients have limitations
16:31
<ltsp_fan>
sure our main use case was reduced quality ka-lite videos
16:31
<alkisg>
So yeah go for the 16.04 server / raspbian chroot for now, and when you upgrade, try to get diskless *fat* clients
16:32
Even window scrolling may require a lot of bandwidth, it's still pixels
16:32
That's what fat clients avoid
16:33
<ltsp_fan>
ok thank's that's solid advice
16:33
<alkisg>
You're welcome :)
16:34
<ltsp_fan>
btw can't the rpi1's function as fat clients considering they have a dedicated video decoding chip and ephiphany web browser supports it?
16:35
<alkisg>
I usually check CPU scores in cpubenchmark.net to decide which clients are good and which are not
16:35robb_nl has joined IRC (robb_nl!~robb_nl@62.235.103.52)
16:35
<alkisg>
I advice people to get new clients with at least 2000 score
16:35
1000 score is acceptable fat client
16:35
rpi1 would score about 100
16:36
Your i7 server would score around 5000, depending on the model
16:36
So it's faster than all of your pis together
16:36
<ltsp_fan>
wow!
16:37
oh but again doesn't the video decoding change this calculation?
16:37
<alkisg>
For starters, you won't be able to scroll a window since it doesn't involve decoding :)
16:38
There are a couple of applications that support decoding video, e.g. omxplayer and patched vlc
16:38
But in general I doubt any browser can ask the vc4 of rpi to decode e.g. youtube flash or html5 content
16:39
<ltsp_fan>
apparently epiphany does
16:39
<alkisg>
Unfortunately the APIs that linux has there, are way behind than those of e.g. android
16:39
I couldn't see any fullscreen videos with epiphany
16:39
Did you manage to see any fullscreen videos with it?
16:40
<ltsp_fan>
well, I haven't tried. we're mainly interested in videos on the ka-lite interface
16:40
do you know if pinet supports fat client?
16:40
<alkisg>
I don't know the ka-lite interface. Is it html5-based? flash-based?
16:40
<ltsp_fan>
html5
16:41
video-js player I think
16:41
<alkisg>
pinet is just a wrapper around ltsp and raspbian, both of them support fat clients
16:41
<ltsp_fan>
oh yes, of course :)
16:42
but pinet itself as a wrapper, does it have an option for fat clients?
16:43
wait why am I asking that here, sorry
16:43
you've helped enough already
16:43
I have a solution to my hair-pulling problem
16:43
<alkisg>
I don't know if it has an option or if it just says "here, I ran ltsp-chroot for you, now you type: apt install ubuntu-mate-desktop" :)
16:43
<ltsp_fan>
let me implement it before I worry about fat clients!
16:44
haha!
16:45
ok thanks guys, you're life-savers
16:45
all the best!
16:45
<alkisg>
bb
16:46ltsp_fan has left IRC (ltsp_fan!29320220@gateway/web/freenode/ip.41.50.2.32, Quit: Page closed)
17:01robb_nl has left IRC (robb_nl!~robb_nl@62.235.103.52, Ping timeout: 246 seconds)
17:07robb_nl has joined IRC (robb_nl!~robb_nl@62.235.103.52)
17:24kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:d05c:ad72:368e:269c, Ping timeout: 260 seconds)
17:27kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:d05c:ad72:368e:269c)
17:29Fenuks has left IRC (Fenuks!~Fenuks@95.191.242.41, Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/)
17:38robb_nl has left IRC (robb_nl!~robb_nl@62.235.103.52, Quit: I'm gone, bye bye)
19:28kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:d05c:ad72:368e:269c, Ping timeout: 264 seconds)
20:18kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:d05c:ad72:368e:269c)
21:43kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:d05c:ad72:368e:269c, Ping timeout: 260 seconds)
21:45ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
22:14vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
22:32vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 260 seconds)
22:44vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
23:10
<sbalneav>
vagrantc: https://code.launchpad.net/~ltsp-upstream/+git/pamexternal-sshauth
23:16
<vagrantc>
sbalneav: that's now at least 3 or so of your newish projects i need to package up! :)
23:17
sbalneav: you think pamexternal-sshauth might be able to included with the libpam-external as an example implementation?
23:17
<sbalneav>
yeah, probably could
23:17
<vagrantc>
sbalneav: or will they need to grow independently?
23:18
<sbalneav>
It's not done yet, still got more work to do before it's a point-for-point replacement for libpam-sshauth
23:18
<vagrantc>
sbalneav: so, those two basically replace libpam-sshauth?
23:18
ah.
23:18
<sbalneav>
Yes, ultimately.
23:18
Prolly need another weeks worth of work.
23:18
<vagrantc>
i should probably try and get this stuff moving into debian experimental, at least
23:19
<sbalneav>
Gimme another week to get things stabalized.
23:19
I'm still in the "rapidly changing everything" phase.
23:19
Today, I moved from single character commands in pam_external to actual human readable commands.
23:19
<vagrantc>
sbalneav: i'll gladly give a week or two, as i clearly haven't been keeping pace with you :)
23:19
<maldridge>
ah, the break and fix phase where fun things happen