IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 8 December 2014 (all times are UTC)
| 00:49 | freedomrun has left IRC (freedomrun!~quassel@unaffiliated/freedomrun, Read error: Connection reset by peer) | |
| 01:14 | AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-cgcswnnkmpgksfje, Quit: Connection closed for inactivity) | |
| 04:31 | metal-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:06 | work_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:43 | metal-machine has left IRC (metal-machine!~metal-mac@117.205.71.230, Ping timeout: 255 seconds) | |
| 06:18 | freedomrun has joined IRC (freedomrun!~quassel@unaffiliated/freedomrun) | |
| 06:34 | alkisg is now known as work_alkisg | |
| 06:42 | mealstrom 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:38 | mealstrom has joined IRC (mealstrom!~Thunderbi@46.63.71.254) | |
| 08:00 | khildin has joined IRC (khildin!~khildin@ip-213-49-87-33.dsl.scarlet.be) | |
| 08:10 | khildin has left IRC (khildin!~khildin@ip-213-49-87-33.dsl.scarlet.be, Remote host closed the connection) | |
| 08:18 | ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz) | |
| 08:20 | metal-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:24 | work_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:34 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 08:36 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 08:36 | metal-machine_ has joined IRC (metal-machine_!~metal-mac@59.91.252.1) | |
| 08:39 | metal-machine has left IRC (metal-machine!~metal-mac@117.205.77.198, Ping timeout: 250 seconds) | |
| 08:41 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
| 08:44 | moldy has left IRC (moldy!~rene@unaffiliated/moldy) | |
| 08:45 | alkisg is now known as work_alkisg | |
| 09:00 | ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 250 seconds) | |
| 09:00 | vmlintu has joined IRC (vmlintu!~vmlintu@82-181-214-103.bb.dnainternet.fi) | |
| 09:01 | metal-machine_ has left IRC (metal-machine_!~metal-mac@59.91.252.1, Quit: Leaving) | |
| 09:22 | AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-jreltmmnogvbjnuk) | |
| 09:28 | AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-jreltmmnogvbjnuk, Excess Flood) | |
| 09:29 | AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-ssiculaynwegeysf) | |
| 09:30 | freedomrun has left IRC (freedomrun!~quassel@unaffiliated/freedomrun, Remote host closed the connection) | |
| 09:31 | JuJuBee has left IRC (JuJuBee!~mike_knic@24-148-115-153.ip.mhcable.com, Ping timeout: 258 seconds) | |
| 09:52 | ame 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:07 | markit has joined IRC (markit!~marco@88-149-177-66.v4.ngi.it) | |
| 10:09 | pstaeheli 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:49 | Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net) | |
| 10:56 | freedomrun has joined IRC (freedomrun!~quassel@unaffiliated/freedomrun) | |
| 11:02 | ame 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:44 | adrianorg has left IRC (adrianorg!~adrianorg@177.156.228.250, Quit: leaving) | |
| 11:58 | mealstro1 has joined IRC (mealstro1!~Thunderbi@46.63.71.254) | |
| 12:00 | mealstrom has left IRC (mealstrom!~Thunderbi@46.63.71.254, Ping timeout: 252 seconds) | |
| 12:07 | work_alkisg has left IRC (work_alkisg!~alkisg@194.63.234.224, Ping timeout: 255 seconds) | |
| 12:10 | work_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:18 | adrianorg has joined IRC (adrianorg!~adrianorg@177.156.228.250) | |
| 12:32 | pstaeheli 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:26 | adrianorg has left IRC (adrianorg!~adrianorg@177.156.228.250, Ping timeout: 245 seconds) | |
| 13:28 | adrianorg has joined IRC (adrianorg!~adrianorg@177.134.57.10) | |
| 13:48 | mikkel 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:04 | markit has left IRC (markit!~marco@88-149-177-66.v4.ngi.it, ) | |
| 14:05 | telex has left IRC (telex!teletype@freeshell.de, Ping timeout: 264 seconds) | |
| 14:15 | Faith has joined IRC (Faith!~paty@unaffiliated/faith) | |
| 14:32 | telex has joined IRC (telex!teletype@94.247.40.146) | |
| 14:45 | mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving) | |
| 15:30 | here_and_there has left IRC (here_and_there!~ivaylo@193.54.153.250, Remote host closed the connection) | |
| 15:33 | Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Quit: I Leave) | |
| 15:52 | mealstro1 has left IRC (mealstro1!~Thunderbi@46.63.71.254, Ping timeout: 252 seconds) | |
| 16:18 | mealstrom has joined IRC (mealstrom!~Thunderbi@46.63.63.163) | |
| 16:26 | khildin has joined IRC (khildin!~khildin@ip-213-49-87-33.dsl.scarlet.be) | |
| 16:43 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
| 17:19 | cliebow has joined IRC (cliebow!~cliebow@gw-rsu24-co.rsu24.org) | |
| 17:32 | vmlintu has left IRC (vmlintu!~vmlintu@82-181-214-103.bb.dnainternet.fi, Ping timeout: 272 seconds) | |
| 18:02 | telex has left IRC (telex!teletype@94.247.40.146, Ping timeout: 244 seconds) | |
| 18:15 | telex has joined IRC (telex!teletype@94.247.40.146) | |
| 18:34 | AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-ssiculaynwegeysf, Quit: Connection closed for inactivity) | |
| 19:35 | khildin has left IRC (khildin!~khildin@ip-213-49-87-33.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
| 19:52 | freedomrun has left IRC (freedomrun!~quassel@unaffiliated/freedomrun, Read error: Connection reset by peer) | |
| 20:11 | vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-70.elisa-laajakaista.fi) | |
| 20:18 | ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
| 20:24 | Faith has left IRC (Faith!~paty@unaffiliated/faith, Quit: Saindo) | |
| 20:27 | tkii 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:28 | ogra_ 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:32 | AlexPortable 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:45 | talntid 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:00 | alkisg 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:27 | adrianorg 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:01 | vmlintu 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:26 | tkii 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:35 | alkisg has left IRC (alkisg!4d31f704@gateway/web/freenode/ip.77.49.247.4, Quit: Page closed) | |
| 22:37 | dsugar100 has left IRC (dsugar100!~dsugar@columbia.tresys.com, Quit: dsugar100) | |
| 22:38 | dsugar100 has joined IRC (dsugar100!~dsugar@columbia.tresys.com) | |
| 22:46 | adrianorg has joined IRC (adrianorg!~adrianorg@177.156.56.16) | |
| 23:16 | ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat) | |
| 23:44 | AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-cufnvoidbtbqtnmx, Quit: Connection closed for inactivity) | |