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


Channel log from 8 December 2014   (all times are UTC)

00:49freedomrun has left IRC (freedomrun!~quassel@unaffiliated/freedomrun, Read error: Connection reset by peer)
01:14AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-cgcswnnkmpgksfje, Quit: Connection closed for inactivity)
04:31metal-machine has joined IRC (metal-machine!~metal-mac@117.205.71.230)
04:34
<metal-machine>
I want to setup LDAP for LTSP. I am done with Debian amd-64 on root and i-386 on application server. Please give me the link where I can find the required packages to install and the configuration files
04:42
is the following source fine for LDAP setup?
04:42
http://ltsp4.2.revamp-it.ch/twiki/bin/view/ltsp/LDAP
04:46
<vagrantc>
ltsp 4.2 is pretty outdated
04:46
!ldap
04:46
<ltsp>
I do not know about 'ldap', but I do know about these similar topics: 'ldm', 'ltsp'
04:46
<vagrantc>
not sure there is any good documentation about configuring LDAP
04:47
the debian-edu project does LTSP with an LDAP configuration
04:49
<metal-machine>
As I told I have one root and 2 application servers with debian wheezy
04:50
<vagrantc>
can't give you documentation i don't have
04:50
<metal-machine>
i have to make able thin-client machine to login to server.
04:51
any idea where to loook for?
04:51
<vagrantc>
essentially, as long as you can ssh into the application server, you should be able to login with LTSP using LDM
04:51
so find documentation for configuring ssh to authenticate against LDAP
04:53
<metal-machine>
so you meanI don't need ldap?
05:01
vagrantc: Thanks for clearing the concept. I just misunderstood the things. :)
05:06work_alkisg is now known as alkisg
05:06* alkisg waves
05:10
<alkisg>
vagrantc: could you remind me how you'd feel if we relied on samba 4 as the default ltsp 6 authentication mechanism as opposed to e.g. libpam_sshauth? (Phantomas is visiting me for a week and we want to do some hacking, and this is one of the things we're considering to work on... :))
05:24
<vagrantc>
alkisg: i don't know enough about samba to say much... just the standard questions
05:25
alkisg: what are the security implications, what's the dependency chain look like?
05:25
<alkisg>
sudo apt-get install samba4 installs those here: attr bind9 bind9utils ldb-tools libdcerpc-server0 libdcerpc0 libgensec0 libhdb9-heimdal libkdc2-heimdal libldb1 libndr-standard0 libndr0 libregistry0 libsamba-credentials0
05:25
libsamba-hostconfig0 libsamba-policy0 libsamba-util0 libsamdb0 libsmbclient-raw0 libtevent0 python-dnspython python-ldb python-samba python-talloc python-tdb samba-dsdb-modules samba4 samba4-common-bin tdb-tools
05:26
bind9 is the main thing, afaik...
05:26
security ==> dunno, i'm expecting samba to be secure, it's a large project, and we'll use it as is, with no special custom options...
05:28
Now on the plus sides, things like "integration with accountsservice" or "user list in lightdm" are supposed to work (whereas with libpam_sshauth I'm afraid we might run into issues), and we redirect any bugs to samba, instead of having to deal with them ourselves
05:28
And we also get the ability to have windows clients logins - which is good but isn't for everyone
05:33
Another thing we may work on, if it sounds like a better investment of our time currently, is ltspd. I would prefer that to land with ltap6, but we can finish it now and commit it when the ltsp 6 authentication scheme is implemented...
05:35
Any other ideas that we can currently work on?
05:35
vagrantc, sbalneav: btw, this week is the "hour of code - http://hourofcode.com", if you guys want we can do that hackfest we wanted now...
05:43metal-machine has left IRC (metal-machine!~metal-mac@117.205.71.230, Ping timeout: 255 seconds)
06:18freedomrun has joined IRC (freedomrun!~quassel@unaffiliated/freedomrun)
06:34alkisg is now known as work_alkisg
06:42mealstrom has left IRC (mealstrom!~Thunderbi@46.63.63.163, Ping timeout: 256 seconds)
06:49|Paradox| has left IRC (|Paradox|!~iamparado@pool-96-253-95-95.rcmdva.fios.verizon.net, Ping timeout: 272 seconds)
06:55|Paradox| has joined IRC (|Paradox|!~iamparado@pool-96-253-95-95.rcmdva.fios.verizon.net)
07:38mealstrom has joined IRC (mealstrom!~Thunderbi@46.63.71.254)
08:00khildin has joined IRC (khildin!~khildin@ip-213-49-87-33.dsl.scarlet.be)
08:10khildin has left IRC (khildin!~khildin@ip-213-49-87-33.dsl.scarlet.be, Remote host closed the connection)
08:18ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)
08:20metal-machine has joined IRC (metal-machine!~metal-mac@117.205.77.198)
08:21
<vagrantc>
work_alkisg: certainly sounds worth exploring...
08:23
work_alkisg: though getting ssh tunnels and whatnot might still require elements of libpam_sshauth
08:24work_alkisg is now known as alkisg
08:25
<alkisg>
vagrantc: you can copy ssh keys from samba and do passwordless ssh
08:25
Or even use kerberos for SSO
08:25
<vagrantc>
sure
08:26
i'm probably not going to be a driving force in any of this, but happy to test and do bugfixes and bounce ideas around
08:26
<alkisg>
I feel that the main drawback is that the server will have more services, like bind, and more requirements, like static ip
08:26
<vagrantc>
bind... that's kind of surprising
08:26
<alkisg>
It's for proper DNS with dynamic updates etc
08:26
dnsmasq is cool for quick dns, but it lacks features
08:27
I don't know if samba can be set up with dnsmasq
08:27
<vagrantc>
ideally we'd be able to use arbitrary pam authentication methods ... samba, ldap, *sql, kerberos, etc.
08:27
<alkisg>
Yes, but it's the default that we mostly care
08:27
<vagrantc>
sure
08:28
<alkisg>
The main reason I'm looking for some default other than libpam_sshauth, is that we can redirect the bugs we find to them
08:29
E.g. "libpam_sshauth doesn't work with accountsservice" is an ltsp problem, while "samba doesn't work with accountsservice" is an accountsservice problem, because samba is more common/famous
08:29
Sucks, but true...
08:31
<vagrantc>
anything we can do to more easily integrate with existing systems while reducing our codebase... generally sounds like a good idea to me.
08:34telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
08:36telex has joined IRC (telex!teletype@freeshell.de)
08:36metal-machine_ has joined IRC (metal-machine_!~metal-mac@59.91.252.1)
08:39metal-machine has left IRC (metal-machine!~metal-mac@117.205.77.198, Ping timeout: 250 seconds)
08:41vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
08:44moldy has left IRC (moldy!~rene@unaffiliated/moldy)
08:45alkisg is now known as work_alkisg
09:00ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 250 seconds)
09:00vmlintu has joined IRC (vmlintu!~vmlintu@82-181-214-103.bb.dnainternet.fi)
09:01metal-machine_ has left IRC (metal-machine_!~metal-mac@59.91.252.1, Quit: Leaving)
09:22AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-jreltmmnogvbjnuk)
09:28AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-jreltmmnogvbjnuk, Excess Flood)
09:29AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-ssiculaynwegeysf)
09:30freedomrun has left IRC (freedomrun!~quassel@unaffiliated/freedomrun, Remote host closed the connection)
09:31JuJuBee has left IRC (JuJuBee!~mike_knic@24-148-115-153.ip.mhcable.com, Ping timeout: 258 seconds)
09:52ame has joined IRC (ame!75c13f13@gateway/web/freenode/ip.117.193.63.19)
09:53
<ame>
i have installed Libre office in chroot and how to make Libre office to work locally ??
10:07markit has joined IRC (markit!~marco@88-149-177-66.v4.ngi.it)
10:09pstaeheli has joined IRC (pstaeheli!~alphanume@62-167-11-36.static.adslpremium.ch)
10:10
<pstaeheli>
Hey, folks
10:11
Does anybody know if it's possible to somehow record an LTSP client's screen, with audio? (using Debian wheezy)
10:49Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net)
10:56freedomrun has joined IRC (freedomrun!~quassel@unaffiliated/freedomrun)
11:02ame has left IRC (ame!75c13f13@gateway/web/freenode/ip.117.193.63.19, Ping timeout: 246 seconds)
11:09
<work_alkisg>
pstaeheli: the same way that you record non-ltsp clients?
11:29
<pstaeheli>
I did try that, but vokoscreen and recordmydesktop are telling me there's neither a sound device nor a screen present
11:34
<work_alkisg>
Tell them to use pulseaudio and xorg without shared memory (shm)
11:34
Not alsa
11:44adrianorg has left IRC (adrianorg!~adrianorg@177.156.228.250, Quit: leaving)
11:58mealstro1 has joined IRC (mealstro1!~Thunderbi@46.63.71.254)
12:00mealstrom has left IRC (mealstrom!~Thunderbi@46.63.71.254, Ping timeout: 252 seconds)
12:07work_alkisg has left IRC (work_alkisg!~alkisg@194.63.234.224, Ping timeout: 255 seconds)
12:10work_alkisg has joined IRC (work_alkisg!~alkisg@194.63.234.224)
12:11
<markit>
hi work_alkisg :) you'd better change nick in alkisg_work, I can hardly find you otherwise at first sight (maybe is what you want being busy, lol)
12:18adrianorg has joined IRC (adrianorg!~adrianorg@177.156.228.250)
12:32pstaeheli has left IRC (pstaeheli!~alphanume@62-167-11-36.static.adslpremium.ch, Quit: Verlassend)
12:51
<vmlintu>
bind with dynamic updates is nice - you can update dhcp addresses to dns and use those instead of listing static addresses for each client. If you want names in dns for your clients, that is. Makes administrator's job easier..
13:26adrianorg has left IRC (adrianorg!~adrianorg@177.156.228.250, Ping timeout: 245 seconds)
13:28adrianorg has joined IRC (adrianorg!~adrianorg@177.134.57.10)
13:48mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
13:53
<markit>
vmlintu: what are you talking about and how config it?
13:55
<vmlintu>
markit: I just read the logs from earlier today where alkisg and vagrantc were discussing samba4 that requires bind..
13:55
<markit>
vmlintu: ah, yes, for samba4 AD is a requirement
13:56
and you have to choose a updated version of bind or use samba internal dns
13:56
<vmlintu>
markit: to use dynamic updates with dhcpd, you can use configuration like this to call a script that does anything you want: https://github.com/opinsys/puavo-ltsp/blob/master/bootserver/templates/etc/dhcp/dhcpd.conf#L24
13:56
<markit>
I've been digging a little about AD (active directory), how deploy config across all the domain, how update software in a centralized manner... shocked how far GNU/Linux is from that, AFAIK
13:58
<vmlintu>
markit: we use currently a script like this to update bind ddns records: https://github.com/opinsys/puavo-ltsp/blob/master/bootserver/sbin/puavo-update-ddns
13:58
markit: that updates both forward and reverse records
13:58
<markit>
I'll have a look later, I've to run in a short time
13:58
great
13:59
<vmlintu>
markit: we solved the centralised update problem by running same ltsp image everywehere - ltsp servers, thin/fat clients, laptops.. etc..
13:59
Even wifi access points are now running the same image..
14:04markit has left IRC (markit!~marco@88-149-177-66.v4.ngi.it, )
14:05telex has left IRC (telex!teletype@freeshell.de, Ping timeout: 264 seconds)
14:15Faith has joined IRC (Faith!~paty@unaffiliated/faith)
14:32telex has joined IRC (telex!teletype@94.247.40.146)
14:45mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
15:30here_and_there has left IRC (here_and_there!~ivaylo@193.54.153.250, Remote host closed the connection)
15:33Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Quit: I Leave)
15:52mealstro1 has left IRC (mealstro1!~Thunderbi@46.63.71.254, Ping timeout: 252 seconds)
16:18mealstrom has joined IRC (mealstrom!~Thunderbi@46.63.63.163)
16:26khildin has joined IRC (khildin!~khildin@ip-213-49-87-33.dsl.scarlet.be)
16:43vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
17:19cliebow has joined IRC (cliebow!~cliebow@gw-rsu24-co.rsu24.org)
17:32vmlintu has left IRC (vmlintu!~vmlintu@82-181-214-103.bb.dnainternet.fi, Ping timeout: 272 seconds)
18:02telex has left IRC (telex!teletype@94.247.40.146, Ping timeout: 244 seconds)
18:15telex has joined IRC (telex!teletype@94.247.40.146)
18:34AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-ssiculaynwegeysf, Quit: Connection closed for inactivity)
19:35khildin has left IRC (khildin!~khildin@ip-213-49-87-33.dsl.scarlet.be, Quit: I'm gone, bye bye)
19:52freedomrun has left IRC (freedomrun!~quassel@unaffiliated/freedomrun, Read error: Connection reset by peer)
20:11vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-70.elisa-laajakaista.fi)
20:18ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
20:24Faith has left IRC (Faith!~paty@unaffiliated/faith, Quit: Saindo)
20:27tkii has joined IRC (tkii!32fef513@gateway/web/freenode/ip.50.254.245.19)
20:27
<sbalneav>
Meh, my nss_ssh idea hasn't panned out.
20:28
I'll have to do it a different way.
20:28ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Remote host closed the connection)
20:28
<vagrantc>
sbalneav: dunno if you caught alkisg's idea of using samba for auth...
20:29
which would probably also have the nss components more fleshed out already
20:29
<sbalneav>
I could, but what I want is something that's minimalistic.
20:30
Here's what I'm looking for...
20:30
We often have the use case where we have a single person setting up a single LTSP server.
20:30
<vagrantc>
right
20:31
<sbalneav>
Now, the problem is, wether we ask them to set up ldap, or ask them to set up samba, that's a steep learning curve.
20:31
As opposed to "adduser user1, passwd user1"
20:31
Now, libpam-sshauth will do the authentication part just fine.
20:32
<vagrantc>
having learned neither, is it still such a steep learning curve, or have frontends been developed to simplify it?
20:32
<sbalneav>
But we need something equally simple for the NSS (shared passwd and group)
20:32AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-cufnvoidbtbqtnmx)
20:33
<sbalneav>
ldap is ugly. I know it well, but there's no "simple" way to do it that you won't end up REdoing because you didn't get it right the first time.
20:33
And samba is... well, samba.
20:33
it's got all kinds of ugliness.
20:33
<cliebow>
ldap is cute and elegant..under its ugly hide
20:33
<sbalneav>
So, now what I'm looking at doing is writing something along these lines:
20:34
<tkii>
LTSP over VPN from a remote site. Is there anything that would need to change for this to work? Right now it doesn't but works fine onsite.
20:34
<sbalneav>
tkii: you'd have to change just about everything :D
20:34
so, sitting on a standalone box, you can type things like "getent passwd" "getent passwd sbalneav" "getent group www-data" etc.
20:35
ALL we want is to extend that out to the thin client in as lightweight a way as possible.
20:36
So, I'm going to write a small daemon that will accept "getent <dbname> [value]" requests
20:36
<vagrantc>
tkii: that's just remote login, you don't need LTSP
20:36
tkii: LTSP is about booting clients over the network
20:36
<sbalneav>
and return the value as a standard text string.
20:36
This will just happen over a standard socket.
20:37
If, later, you make the server part of an LDAP pool, or what have you, NOTHING has to change.
20:37
<vagrantc>
sbalneav: you've got a bit of an information disclosure issue there
20:37
<sbalneav>
How so?
20:38
<vagrantc>
sbalneav: can easily disclose the names of accounts ... "ooooh look, username test ... i bet the password is ... test!"
20:38
<sbalneav>
You can get the same info from ldap with anonymous binds
20:39
So that danger doesn't go away.
20:40
<vagrantc>
sbalneav: so essentially it's a daemon that proxies local "getent" calls?
20:40
<cliebow>
my universe has dwindled to one tiny galaxy..the ldap galaxy..and i m so rusty now i d never get it running again cuase it just cxhugs away for years without tending
20:41
<sbalneav>
well, it'll make getent calls on the server appear on the thin client.
20:41* vagrantc txhugs
20:41
<cliebow>
heheh
20:41
<sbalneav>
What you want is to be able to type "getent passwd" on the thin client and get the same one as on the server with the minimum of fuss.
20:41
<cliebow>
i got several words here right the very first time
20:43
<vagrantc>
sbalneav: ok, so, how do you do that before you know which server you're logging into?
20:44
<sbalneav>
I'd assume you'd go after the boot server.
20:44
If you've got a pool of servers, presumably THOSE servers would all have something like ldap.
20:44
so they'd all be the same.
20:45
I'm just trying to avoid pushing LDAP all the way down to the thin client itself.
20:45
<vagrantc>
well, in my typical setup, the boot server had no logins, it was all done with separate application servers
20:45talntid has joined IRC (talntid!~talntid@216.229.186.226)
20:45
<talntid>
installing a fresh LTSP server - what's the recommended host OS?
20:46
<vagrantc>
talntid: whatever works for you...
20:46
<talntid>
all my other servers are ubuntu 14.04
20:46
<sbalneav>
So how would libpam_sshauth work in your setup?
20:46
<vagrantc>
talntid: sounds like i'd recommend ubuntu 14.04 then
20:46
<talntid>
roger that :)
20:46
<cliebow>
Debian is also biddable 8~)
20:47
<vagrantc>
sbalneav: that's something we haven't figured out yet ... works great with LDM with ltsp5 ...
20:47
sbalneav: so i'd say it's a regression
20:47
sbalneav: well, server selection works with libpam-sshauth
20:48
sbalneav: er, there is no current method to select server with libpam_sshauth ... but a workaround would be to set up one session for each server
20:48
<tkii>
vagrantc: We're trying to get thin clients to work over a point to point vpn, I think I understand what you mean by "LTSP is about booting clients over the network", so maybe I should rephrase... is there anything that needs to happen with LTSP config to work across different subnets? routing between the subnets works just fine.
20:48
<vagrantc>
sbalneav: i.e. Select Session: GNOME (server1)
20:49
tkii: you're going to need enough bandwidth and probably more importantly, latency ... but as long as you can shunt NFS/NBD and ssh traffic around at acceptible speeds, then there's nothing technically blocking it.
20:49
tkii: i guess also tftp for initial boot
20:50
tkii: probably a few other protocols
20:50
<sbalneav>
vagrantc: hmm. OK, well, I'll have to think some more
20:50
<cliebow>
tftp is what would throw me..
20:51
<vagrantc>
sbalneav: more *thinking* ... i see where this is going! :)
20:51
sbalneav: probably going to drag me with you, too!
20:51
<sbalneav>
vagrantc: On a related note...
20:51
<talntid>
vagrantc, interested in doing some consulting work over the next week? Just little things that I know I am going to run into as problems rebuilding this LTSP setup (LDAP auth, NFSMount homedirs, applying default theme to all new logins)? I could either pay you directly or donate to the charity of your choice :)
20:51
<vagrantc>
tkii: main question i would have ... what exactly are you trying to do
20:51
<sbalneav>
I have a fat client setup, but for some reason, lightdm doesn't start automatically.
20:52
What am I missing?
20:52
<vagrantc>
talntid: sure
20:53
sbalneav: LTSP has probably disabled it
20:54
<sbalneav>
I set LTSP_FATCLIENT to True, thought that would fix it.
20:54
<vagrantc>
sbalneav: i'll look up the instructions
20:55
<tkii>
boot the thin clients up via a point to point vpn. technically it should work as anything else I do works (SMB, HTTP, VNC.. etc) i'm not blocking anything over the VPN. It is open vpn so I'll switch it to bridged mode and see if the double nat is causing an issue.
20:55
vagrantc: boot the thin clients up via a point to point vpn. technically it should work as anything else I do works (SMB, HTTP, VNC.. etc) i'm not blocking anything over the VPN. It is open vpn so I'll switch it to bridged mode and see if the double nat is causing an issue.
20:59
<vagrantc>
tkii: NAT would almost certainly be an issue
20:59
<tkii>
that's what i was afraid of...
21:00
<vagrantc>
tkii: dhcp is probably another thing that will need to hand out the right information
21:00alkisg has joined IRC (alkisg!4d31f704@gateway/web/freenode/ip.77.49.247.4)
21:01
<tkii>
it works fine onsite, ltsp server is a single nic server. stand alone DHCP server
21:04
<alkisg>
sbalneav: /usr/share/ltsp/init-ltsp.d/50-default-display-manager ==> DEFAULT_DISPLAY_MANAGER=/usr/sbin/lightdm
21:04
What's wrong with samba? Should we avoid it?
21:05
<vagrantc>
sbalneav: gah, sorry, got distracted by three threads at once
21:05
sbalneav: but alkisg pointed you in the right direction
21:05
<sbalneav>
alkisg: Yeah, got that, doesn't seem to work.
21:05
Not sure why.
21:05
<vagrantc>
sbalneav: http://wiki.ltsp.org/wiki/Dev:LTSPPamNotes
21:06
sbalneav: SCREEN_02=shell|null ?
21:06
<sbalneav>
Don't have a "SCREEN_02"
21:06
Need it to be shell or null?
21:07
<vagrantc>
it just needs to avoid triggering the default of SCREEN_07=ldm when there's no SCREEN_* set
21:07
<sbalneav>
ah, ok.
21:07
lemme tru
21:07
try
21:10
hmm
21:10
now I just get the shell on 2
21:10
one sec, I'll paste my lts.conf
21:10
<vagrantc>
i haven't actually tried that stuff in a while, maybe i should
21:11
<sbalneav>
http://pastebin.com/sTJrrj6W
21:13
<vagrantc>
sbalneav: i'm forgetting if i tested fat client support or not
21:13
sbalneav: with libpam-sshauth
21:13
sbalneav: i presume you have the ltsp-pam package installed?
21:20
<sbalneav>
No
21:20
Not at the moment.
21:21
I mean, I can make it work by modifying the init-ltsp.d/50-remove-system-services file, but that seems kinda hokey
21:21
<vagrantc>
sbalneav: you're trying to set up a fat client with libpam_sshauth?
21:22
using lightdm?
21:23
<sbalneav>
No, I haven't started on that yet
21:23
for right now, I've actually set a userid and password in the chroot.
21:24
<vagrantc>
well, you might want to look at the ltsp-pam package to see what it does ... maybe there's something implemented in there i don't remember
21:25
sbalneav: set KEEP_SYSTEM_SERVICES=lightdm
21:26
sbalneav: which is implemented in one of the ltsp-pam hooks
21:26
sbalneav: which is easier than editing the init-ltsp.d script directly
21:27adrianorg has left IRC (adrianorg!~adrianorg@177.134.57.10, Ping timeout: 240 seconds)
21:29
<vagrantc>
basically, i made conditional hooks to override the "normal" ltsp behavior for everything
21:29
<vmlintu>
alkisg: would the plan to be to use ldap/kerberos with samba server?
21:30
<alkisg>
vmlintu: I imagine an "ltsp-config samba" that would do that. I don't know what exactly, I'm looking for the standard/best samba setup, something that most people would be happy with.
21:31
So it would be both easy (just an ltsp-config command), with no learning curve (due to the sch-scripts user manager GUI, or other tools), and "famous" enough so that we don't need to worry...
21:31
<vmlintu>
alkisg: we did try using cifs with samba3 for ltsp servers and fat clients for a while, but that wasn't too stable, so I'd recommend against that
21:31
<alkisg>
...about every new "accountsservice" etc breaking our logins
21:31
<vmlintu>
for home directories, that was
21:32
I don't really know, what accountsservice does..
21:32
<alkisg>
vmlintu: sshfs could still be the default for /home, and maybe if there's a "good way for secure nfs4" we can implement an ltsp-config nfs-home too
21:33
There are services that break the concept of remote authentication
21:33
accountsservice is supposed to list the users, and tell the DM some more info about them, wallpaper, face.png etc
21:34
So e.g. to make lightdm properly list the users on ltsp clients, we'd have to copy some *directories* from the server, /var/lib/AccountsService etc
21:34
<vmlintu>
I just read the discussion earlier about having a daemon on the server serving getent requests. We are now running a web service behind nginx on the bootserver that is authenticated with kerberos. So when user logs in on the thin client, pam_krb5.so gets a kerberos ticket and that is used to authenticate the request for getent information that is then written to nss-extrausers file.
21:35
<alkisg>
I don't know enough about pam, kerberos, authentication etc to comment. But I do feel that implementing a custom pam is the wrong way to go,
21:36
because it won't be easy to convince people that their new innovative software like accountsservice is breaking our logins
21:36
But if we're using more "famous" software like samba, kerberos etc, I think it's more probable that they'll listen and be compatible with them
21:37
<vmlintu>
copying directories and files over from the server does not sound good..
21:38
<alkisg>
Yes, that's why I would prefer samba there
21:38
So, currently I'm just trying to collect information, see the pros/cons of every method
21:38
E.g. "ldap has a learning curve" => ok we can solve that with ltsp-config and a gui for user management
21:39
"samba's got all kinds of ugliness." ==> sbalneav what did you mean with that?
21:39
<vmlintu>
I really cannot say whether samba4 would be easy or not as I haven't used it..
21:40
<alkisg>
If we managed to make samba very very easy to integrate with ltsp, would it still have issues that would make it not appropriate?
21:40
Easy or not doesn't matter, we can automate it
21:41
"not stable", "not secure", "breaks other things" etc would be real reasons
21:42
vmlintu: what are you using for authentication in most of your installations?
21:42
<vmlintu>
it's all kerberos
21:42
mit kerberos + openldap
21:42
also laptops running the images
21:43
<alkisg>
Suppose that ltsp 6 supported samba 4 (==ldap) and kerberos, would that suit you?
21:43
Do you also use credential caching for the laptops?
21:43
<vmlintu>
samba4 supports now only heimdal and we use mit
21:44
yes, offline logins work with sssd
21:44
<sbalneav>
alkisg: Samba's got all kinds of setup variations that you can get into, and bluntly, I don't want to run a file-sharing service so I can get logins :D
21:44
<alkisg>
sbalneav: you'll also get windows clients logins :) It's not only about file sharing
21:45
<sbalneav>
alkisg: I don't have any of those.
21:45
So for me, it's not a good use case.
21:45
<alkisg>
You don't have to use file sharing
21:45
<sbalneav>
I don't have to use samba :D
21:45
<alkisg>
And, if one doesn't need a feature, it doesn't mean it's a reason to prohibit others that need that feature
21:46
It's about the default, not about the only supported method
21:46
<sbalneav>
Didn't say it did. If someone WANTS to use samba, we should support that.
21:46
I don't want to use samba :D
21:47
<alkisg>
I don't want to have to convince accountsservice developers that their program should be compatible with libpam_sshauth
21:47
<sbalneav>
Nor should you.
21:47
<alkisg>
Nor to go through hoops to make ltsp clients work with that
21:47
Right, but that's the case now
21:48
We'll bump into a *lot* of problems there
21:48
<vmlintu>
alkisg: one thing about samba - it supports only one domain per installation if I've understood correctly.. Currently we are running multiple ldap databases and kerberos realms on a single server with Puavo.
21:48
<sbalneav>
but pam auth should work anywhere. If your server supports pam auth via samba, so long as it's also got ssh installed on it, it should work.
21:48
<vmlintu>
I don't know if there's anyone else on the planet doing that
21:49
<alkisg>
sbalneav: it's not only about pam anymore
21:49
They need wallpaper configuration, face.png etc
21:49
So they're implementing other account services
21:49
We have to offer those over the network too
21:49
E.g. you select alkisg in lightdm
21:50
<sbalneav>
OK, well, that's fine. But *I* care about pam, so that's the bit *I*'m working on.
21:50
<alkisg>
You're supposed to see my wallpaper before you login
21:50
And get my language layout
21:50
And see my face icon
21:50
So implementing pam isn't enough
21:51
<sbalneav>
It is for me.
21:51
<alkisg>
(a pam module)
21:51
But it won't work...
21:51
Will you keep using ldm?
21:51
<sbalneav>
No, I'm going to switch to a fatclient model
21:51
here, locally.
21:51
<vmlintu>
at which point are icon and wallpaper needed?
21:52
<alkisg>
vmlintu: if you select a user in lightdm, you see its wallpaper etc
21:52
<vagrantc>
wow. accountservice sounds awful.
21:52
<vmlintu>
alkisg: hmm.. I'm not sure if I've ever seen that
21:52
<alkisg>
This is just an example, the problem is that there are account services that try to add things that pam didn't cover on its design
21:52
<sbalneav>
And I don't want people's faces or wallpaper showing up, I need them to type their username and password.
21:53
So for me, pam will work just fine.
21:53
<alkisg>
sbalneav: no it won't
21:53
<vagrantc>
not that i use wallpapers at all, but i wouldn't want an unauthenticated user to be able to see wallpapers of users...
21:53
<alkisg>
Currently it doesn't
21:53
The login breaks because of the other services
21:53
Pam works, login breaks
21:53
And you'd need to file bugs against those other services
21:53
Sure, libpam_sshauth will not be to blame
21:54
What I'm trying to say is that the "other services" developers won't care much if their software breaks libpam_sshauth,
21:54
they'll care more if their software breaks samba
21:54
(logins with ssh_auth/samba)
21:54
<sbalneav>
But all libpam_sshauth does is return a "pam says your authenticated"
21:55
<alkisg>
Yes pam is only one part of the login process with lightdm and other modern display managers
21:55
Logins can break elsewhere too
21:55
<vagrantc>
alkisg: how modern are we talking? i tested libpam-sshauth on Jessie back in October and it worked fine
21:55
<alkisg>
I'm not saying they're correct to do that... but they do
21:55
<sbalneav>
So you're saying I won't be able to get libpam-sshauth to work with lightdm from an LTSP fatclient?
21:55
<vagrantc>
alkisg: using lightdm
21:56
<alkisg>
I'm saying that there will be several issues, not all fatal, that we'll need to report to other packages
21:56
<sbalneav>
Well, I guess I'll just have to try, and see what I come up with :D
21:56
<alkisg>
And I'd prefer it if we didn't have to do that
21:57
If samba or ldap did that instead of us
21:57
<vagrantc>
alkisg: but won't those cases also break samba, ldap, etc. ?
21:57
ah.
21:57
<alkisg>
vagrantc: yes, there are several reports on accountsservice breaking ldap and samba
21:57
<sbalneav>
Because lightdm, if it interacts with samba, will interact via pam.
21:58
by accountservice, are we talking systemd here?
21:58
<vagrantc>
alkisg: so, it seems like these changes will already be needed ... if they fix it for ldap or samba won't it likely get fixed for libpam-sshauth?
21:58
alkisg: and libpam-sshauth might just be one more piece of software saying "yes, this needs to be fixed"
21:59
<alkisg>
vagrantc: I imagine for most cases, yes, I don't know if there will be cases where it will only break our own software,
22:00
...but, I hate it when I report a bug and say "accountsservice breaks logins with pam ssh auth"
22:00
<vagrantc>
alkisg: i understand the point you're making about being a small player
22:00
<alkisg>
and they reply "what's that? I don't care, it has a small user base",
22:00
<sbalneav>
Well, I'll work on that over the next few days, see if I can get it working
22:00
<alkisg>
and I have to configure something else (samba, ldap) just to prove them that it affects more famous software too, to get them to work on that bug
22:01vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-70.elisa-laajakaista.fi, Ping timeout: 260 seconds)
22:01
<alkisg>
If there's a downside to samba, sure, let's scratch it from the available options
22:01
But so far I don't have concrete reasons
22:02
(as a default case, of course not as the only supported one)
22:02
I don't think any files are shared by default
22:02
<vagrantc>
basically, i would like to see it work with arbitrary PAM/NSS implementations ... so let's each scratch the itches that bother us the most
22:02
<sbalneav>
Oh, I'm not saying we should scratch it from the options, by any means
22:03
<vagrantc>
and i'll happily experiment with at least 2-3 options that get proposed
22:03
<alkisg>
Let's sum up...
22:04
We default to libpam_sshauth, but we allow things like ltsp-config samba4?
22:04
<sbalneav>
I don't even care if we default to samba4
22:04
just so long as pam works :D
22:04
<alkisg>
Sure, that's a granted :)
22:04
<sbalneav>
That's all I'm saying :D
22:05
<vagrantc>
i think there's broad agreement here on that point.
22:05
<alkisg>
I don't really care about the default either, I can easily change that with a local package,
22:05
<sbalneav>
right.
22:05
<alkisg>
sbalneav, I was mostly asking about your opinion on why samba sucks, to avoid invensting in it
22:05
<sbalneav>
I just hate samba. I can never get the config files right :D
22:05
<alkisg>
Haha
22:06
<sbalneav>
Completely personal bias, admittedly
22:06
I make no bones about it :D
22:08
<alkisg>
OK another quick question to both of you... it might take us a lot of time to get ltsp + pam working fine (mostly worried about those other stupid services etc),
22:08
...is it a good idea to implement other things like ltspd while we're still on ltsp5?
22:10
<sbalneav>
Sure. We should always just implement as much as we can, when we are able, IMHO
22:11
<alkisg>
sbalneav: there are 3-4 possible implementations
22:11
ltspd could be simplehttpserver
22:11
an "ltsp" user on the server that we could access with ssh before login (you proposed that a few days back)
22:11
or the web service for getent that you proposed today
22:12
I think we only need 1 of the 3 above ideas
22:13
(and a 4th idea for sshd on the clients with two-way access from the server I proposed a few days ago)
22:13
<sbalneav>
If we have the "ltsp" user, that would tie in nicely with what I'm trying to accomplish, IF we don't feel that's a security risk.
22:13
<alkisg>
vagrantc: ?
22:14
<vagrantc>
i'm not keen on the dedicated user accounts
22:14
<alkisg>
x2go has "x2gouser" for that reason
22:15
daemons also have dedicated accounts
22:15
<vagrantc>
it's too easy for sloppy code to land in the restricted shell ... although perhaps the same could be said of a server daemon
22:15
<alkisg>
x2gouser is a system account of course
22:15
<vagrantc>
sure, i understand that
22:15
<alkisg>
I think the key there is about using ssh
22:16
software like ltsp or x2go or nx that uses ssh as their main ...gate to the server, may decide to reuse it instead of requiring another port
22:17
It offers a secure connection so why not prefer it over an https service, if that user doesn't have a login shell...
22:17
vagrantc: it's mostly your call, you're our "packaging voice" :)
22:18
<vagrantc>
setting up the authentication for the ssh key is kind of messy
22:18
admins might edit AuthorizedKeysFile to something other than what we're assuming
22:19
so it requires configuration of sshd_config ... which i'd rather avoid as a package maintainer
22:19
people get touching about mucking with sshd_config
22:19
touchy
22:19
for some reason :)
22:20
i'd rather use a dedicated daemon...
22:20
<alkisg>
OK
22:20
<vagrantc>
from a security perspective, ldminfod is nice in that it doesn't take arguments
22:20
input validation is mostly a non-issue
22:20
<alkisg>
We'll need arguments though
22:20
<vagrantc>
but that obviously limits it's interactivity
22:21
<alkisg>
OK we can e.g. have ltspd offer http (for initramfs etc) and https for later on
22:21
<vagrantc>
why not https in the initramfs too?
22:21
<alkisg>
If it's supported, sure, but I'm not sure busybox supports it
22:22
<vagrantc>
iPXE can be configured to boot over https ... we could actually, for once, have a secure booting stack.
22:22
alkisg: we can put whatever we want into the initramfs
22:22
<alkisg>
sbalneav: suppose you have ltspd, a python-based simplehttp(s)server, would that help you with the getent plan?
22:23
<vagrantc>
what we do get into by implimenting any of these methods is compatibility issues and API issues
22:23
we handled that reasonably well with ldminfod, by mostly adding new methods, but keeping the older ones
22:24
(actually, i think we completely broke compatibility at one point ...)
22:24
<alkisg>
ltspd won't run in the same port - if someone wants he can keep running ltspinfod too
22:24
<vagrantc>
ldminfod
22:24
<alkisg>
so it won't need to support output in the format of ldminfod
22:25
<vagrantc>
no, i'm just talking about implementing features in ltspd and maintaining an eye for forwards and backwards compatibility
22:25
i.e. an API
22:26
<alkisg>
Sure, we'll try that as best as we can...
22:26tkii has left IRC (tkii!32fef513@gateway/web/freenode/ip.50.254.245.19, Ping timeout: 246 seconds)
22:26
<alkisg>
vagrantc: the new pxelinux imitates ipxe a bit and supports http, right?
22:27
<vagrantc>
with ltsp5 we required very little compatibility between the server and client, for the most part you could run pretty disparate versions and they would gracefully handle not having all the desired information
22:27
<alkisg>
I'm wondering if we can only have pxelinux to the tftp folder and use ltspd/https for the rest?
22:27
<vagrantc>
alkisg: no idea
22:27
would be nice to get rid of tftpd, while we're at it
22:28
<alkisg>
I don't think it's possible to completely remove tftpd...
22:28
<vagrantc>
i've always found ltsp-update-kernels to be annoying ... copying files all over the place just to satisfy the tftp default locations
22:28
<alkisg>
We at least need to send pxelinux.0 to pxe clients (not ipxe)
22:28
<vagrantc>
alkisg: alternately, a tftp server that selected or generated the files to load ...
22:29
<alkisg>
Well if the kernel/initrd is inside /opt/ltsp/images/i386.img (which came e.g. from virtualbox), then copying is necessary...
22:29
vmlintu has that, puevo-tftpd or something, in ruby
22:30
<vagrantc>
it could still load them from the image and cache them intelligently, rather than manually having to copy them out
22:32
<alkisg>
True
22:32
vagrantc: http://www.syslinux.org/wiki/index.php/PXELINUX#HTTP_and_FTP
22:32
lpxelinux.0
22:34
So I'm imagining we'll be able to only put lpxelinux.0 and pxelinux.cfg/default to tftp, and serve everything else via ltspd/http
22:34
I don't know about arm though
22:34
<vagrantc>
yeah, arm still probably will need tftp
22:35
<alkisg>
Thanks guys, time to hit the bed... /me waves
22:35
<vagrantc>
for what it's worth, the best ARM client i've come across so far is definitely the wandboard
22:35
alkisg: see ya
22:35alkisg has left IRC (alkisg!4d31f704@gateway/web/freenode/ip.77.49.247.4, Quit: Page closed)
22:37dsugar100 has left IRC (dsugar100!~dsugar@columbia.tresys.com, Quit: dsugar100)
22:38dsugar100 has joined IRC (dsugar100!~dsugar@columbia.tresys.com)
22:46adrianorg has joined IRC (adrianorg!~adrianorg@177.156.56.16)
23:16ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat)
23:44AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-cufnvoidbtbqtnmx, Quit: Connection closed for inactivity)