IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 11 August 2016 (all times are UTC)
| 01:25 | Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 240 seconds) | |
| 01:28 | Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack) | |
| 01:45 | GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 258 seconds) | |
| 03:02 | Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 244 seconds) | |
| 03:07 | Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack) | |
| 03:09 | adrianorg has left IRC (adrianorg!~adrianorg@189.58.230.109.dynamic.adsl.gvt.net.br, Ping timeout: 240 seconds) | |
| 03:11 | adrianorg has joined IRC (adrianorg!~adrianorg@191.32.102.53) | |
| 04:38 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 244 seconds) | |
| 04:45 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 04:47 | bennabiy has joined IRC (bennabiy!~bennabiy@unaffiliated/bennabiy) | |
| 05:19 | pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 252 seconds) | |
| 05:34 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 05:43 | K0HAX_ has joined IRC (K0HAX_!~michael@shellhost.home.englehorn.com) | |
| 05:46 | TatankaT has joined IRC (TatankaT!~tim@193.190.253.114) | |
| 05:48 | K0HAX has left IRC (K0HAX!~michael@shellhost.home.englehorn.com, Ping timeout: 250 seconds) | |
| 05:48 | TatankaT_ has left IRC (TatankaT_!~tim@193.190.253.114, Ping timeout: 250 seconds) | |
| 06:09 | laprag has joined IRC (laprag!~ragnar@user.skolelinux.no) | |
| 06:11 | laprag has left IRC (laprag!~ragnar@user.skolelinux.no, Client Quit) | |
| 06:47 | mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk) | |
| 06:49 | vmlintu has joined IRC (vmlintu!~vmlintu@a91-153-33-91.elisa-laajakaista.fi) | |
| 08:15 | vmlintu has left IRC (vmlintu!~vmlintu@a91-153-33-91.elisa-laajakaista.fi, Ping timeout: 260 seconds) | |
| 08:29 | vmlintu has joined IRC (vmlintu!~vmlintu@a91-153-33-91.elisa-laajakaista.fi) | |
| 09:01 | Statler has joined IRC (Statler!~Georg@p54BFBE20.dip0.t-ipconnect.de) | |
| 10:49 | budgee has left IRC (budgee!~root@static.210.94.47.78.clients.your-server.de, Quit: leaving) | |
| 11:00 | vmlintu has left IRC (vmlintu!~vmlintu@a91-153-33-91.elisa-laajakaista.fi, Quit: Leaving) | |
| 11:00 | vmlintu has joined IRC (vmlintu!~vmlintu@a91-153-33-91.elisa-laajakaista.fi) | |
| 11:08 | GodFather has joined IRC (GodFather!~rcc@96.92.43.9) | |
| 11:30 | julienfayad has joined IRC (julienfayad!~julienfay@94.187.66.230) | |
| 12:10 | julienfayad has left IRC (julienfayad!~julienfay@94.187.66.230, Quit: julienfayad) | |
| 12:30 | GodFather has left IRC (GodFather!~rcc@96.92.43.9, Ping timeout: 276 seconds) | |
| 12:49 | GodFather has joined IRC (GodFather!~rcc@75-145-237-204-Michigan.hfc.comcastbusiness.net) | |
| 13:09 | vmlintu has left IRC (vmlintu!~vmlintu@a91-153-33-91.elisa-laajakaista.fi, Read error: Connection reset by peer) | |
| 13:26 | keyboardKat has left IRC (keyboardKat!ad0bffe9@gateway/web/freenode/ip.173.11.255.233, *.net *.split) | |
| 13:32 | forum has joined IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at) | |
| 13:47 | julienfayad has joined IRC (julienfayad!~julienfay@46.19.196.200) | |
| 13:55 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
| 14:02 | K0HAX_ is now known as K0HAX | |
| 14:09 | mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving) | |
| 14:10 | forum has left IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at, Ping timeout: 252 seconds) | |
| 14:29 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 14:33 | forum has joined IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at) | |
| 14:37 | forum has left IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at, Client Quit) | |
| 14:56 | forum has joined IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at) | |
| 14:59 | forum has left IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at, Remote host closed the connection) | |
| 14:59 | forum has joined IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at) | |
| 15:05 | julienfayad has left IRC (julienfayad!~julienfay@46.19.196.200, Ping timeout: 250 seconds) | |
| 15:14 | julienfayad has joined IRC (julienfayad!~julienfay@82.112.162.224) | |
| 15:44 | julienfayad has left IRC (julienfayad!~julienfay@82.112.162.224, Quit: julienfayad) | |
| 15:53 | julienfayad has joined IRC (julienfayad!~julienfay@82.112.162.224) | |
| 15:53 | <julienfayad> hey, I made an interesting discovery, changing the hostname of an ltsp client seems to be breaking nbd
| |
| 15:54 | (I’m talking about changing it from the command line after the client booted through the hostname {new name} command)
| |
| 16:05 | forum1 has joined IRC (forum1!~Icedove@212-183-84-50.adsl.highway.telekom.at) | |
| 16:05 | forum has left IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at, Read error: Connection reset by peer) | |
| 16:05 | forum1 is now known as forum | |
| 16:06 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 16:18 | <julienfayad> any idea what’s the best approach to have a specific change applied to the /etc/hosts file of ltsp clients so that their IP point to their hostname ? (other than 127.0.0.2 as it it now)
| |
| 16:21 | forum has left IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at, Ping timeout: 258 seconds) | |
| 16:33 | kjackal has left IRC (kjackal!~quassel@2a02:582:ccb:a00:6081:e8d2:35cb:6965, Ping timeout: 260 seconds) | |
| 16:33 | kjackal has joined IRC (kjackal!~quassel@2a02:582:cd4:b500:5c44:70e8:cba4:27dd) | |
| 16:53 | GodFather has left IRC (GodFather!~rcc@75-145-237-204-Michigan.hfc.comcastbusiness.net, Ping timeout: 244 seconds) | |
| 16:59 | <bennabiy> Does anyone have experience with Qotom clients?
| |
| 17:00 | I am looking for a good thinclient / fat client option for sub 150US
| |
| 17:14 | <julienfayad> hi bennabiy, good is a relative perception it really depends on what you are looking to achieve with your client
| |
| 17:14 | for instance, for software development, an intel nuc i5 6th generation with a decent amount of RAM is excellent and cost effective
| |
| 17:15 | <bennabiy> back in a bit
| |
| 17:16 | <julienfayad> Folks, I’m having some new information about how to let Kerberos and LTSP work together
| |
| 17:17 | it seems that the way LTSP handles login might be causing some troubles
| |
| 17:24 | normally when logging in a kerberos ccache is being stored on the machine so that kerberized services can authenticate the access to the user
| |
| 17:24 | in my setup these ccache files are being stored in the /tmp folder
| |
| 17:24 | I noticed that when a user logs in on an ltsp client
| |
| 17:25 | a new ccache file for that user is being stored on the /tmp folder of the LTSP Server (and nothing on the client)
| |
| 17:46 | Statler has left IRC (Statler!~Georg@p54BFBE20.dip0.t-ipconnect.de, Quit: Leaving) | |
| 17:53 | forum has joined IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at) | |
| 17:54 | K0HAX has left IRC (K0HAX!~michael@shellhost.home.englehorn.com, Quit: ZNC 1.7.x-git-631-88a8675 - http://znc.in) | |
| 17:54 | K0HAX has joined IRC (K0HAX!~michael@shellhost.home.englehorn.com) | |
| 17:56 | K0HAX has left IRC (K0HAX!~michael@shellhost.home.englehorn.com, Client Quit) | |
| 17:56 | K0HAX has joined IRC (K0HAX!~michael@shellhost.home.englehorn.com) | |
| 17:57 | <alkisg> (06:53:43 μμ) julienfayad: hey, I made an interesting discovery, changing the hostname of an ltsp client seems to be breaking nbd ==> just doing `hostname asdf` breaks nbd?!
| |
| 17:58 | (07:18:07 μμ) julienfayad: any idea what’s the best approach to have a specific change applied to the /etc/hosts file of ltsp clients so that their IP point to their hostname ? (other than 127.0.0.2 as it it now) ==> you can put an HOSTS_x line in lts.conf
| |
| 17:58 | (08:00:03 μμ) bennabiy: I am looking for a good thinclient / fat client option for sub 150US ==> why not a real client with cpu >= 2000 so that it will perform much better and last for years?
| |
| 17:58 | <julienfayad> well that was one test I made, but yeah basically hostname asdf will have many side effects on the client
| |
| 17:59 | as for the HOSTS_x line in lts.conf, this isn’t documented http://manpages.ubuntu.com/manpages/wily/man5/lts.conf.5.html
| |
| 17:59 | what’s the format of the line ?
| |
| 17:59 | (as if I was writing inside the /etc/hosts file ?)
| |
| 18:00 | and this leads to another question, how can I get the assigned IP address of the client inside the lts.conf ?
| |
| 18:00 | so that I could put the IP as a variable that is provided at boot time
| |
| 18:01 | forum has left IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at, Ping timeout: 265 seconds) | |
| 18:02 | <alkisg> The format is like writing a hosts file, and the ip is: $ip
| |
| 18:02 | Sorry, $IPV4ADDR
| |
| 18:02 | <julienfayad> that’s awesome, should be documented online :-)
| |
| 18:02 | <alkisg> Noone really cares about documentation :D
| |
| 18:02 | <julienfayad> ohh no you can’t say that I’ve been using it to do my FSTAB cooking
| |
| 18:03 | and assign a custom hostname to my client based on its IP (as I wanted to test something quickly before going into dnsmasq configuration)
| |
| 18:03 | :-D
| |
| 18:03 | <alkisg> Hehe ok everyone has written a bit of documentation, but when the manpower is low, we mostly focus on development and less on documentation
| |
| 18:04 | <julienfayad> yeah I can understand that
| |
| 18:05 | I’m trying this as we speak
| |
| 18:08 | <alkisg> julienfayad: changing the hostname doesn't cause any issues with nbd for me
| |
| 18:09 | <julienfayad> alkisg i’ll try to reproduce the issue
| |
| 18:09 | as I’m now not changing the hostname anymore *used lts.conf doc to do it dynamically :-)*
| |
| 18:10 | <bennabiy> alkisg: what did you mean?
| |
| 18:11 | <julienfayad> alkisg remember yesterday you shared something about /media not being loaded
| |
| 18:11 | I can’t manage to retrieve it
| |
| 18:11 | The /media folder is not included, check /etc/ltsp/ltsp-update-image.excludes
| |
| 18:11 | that was it
| |
| 18:12 | but then how come I have one folder that is being retrieved
| |
| 18:12 | and not the other ?
| |
| 18:12 | <alkisg> bennabiy: I mean that clients with cpu < 2000 and $$ < 150 are barely workable now. While a bit more expensive clients with cpu > 2000 will work better now and will last for more years, they won't be unusably slow.
| |
| 18:13 | (09:12:09 μμ) julienfayad: but then how come I have one folder that is being retrieved => I would need to take a look to answer that faster
| |
| 18:13 | <julienfayad> hmm except if
| |
| 18:13 | the mount i’ve put in the FSTAB is actually creating the folder?
| |
| 18:14 | <bennabiy> alkisg: We are not using the clients in the way that typically would be used... Mostly just doing email and looking up things, and typing.
| |
| 18:14 | No movies etc,
| |
| 18:14 | or gaming
| |
| 18:14 | <alkisg> bennabiy: I can't imagine clients that don't do browsing
| |
| 18:14 | If you don't use a browser there, then OK, but that's not typical use
| |
| 18:15 | <julienfayad> if bennabiy is doing email
| |
| 18:15 | <bennabiy> My current clients are Atom N280 (which rates in the 200s)
| |
| 18:15 | <julienfayad> I guess an email client is necessary or a browser (If it’s a SaaS email account)
| |
| 18:15 | <bennabiy> so I use thin clients
| |
| 18:16 | alkisg, what would you recommend?
| |
| 18:16 | <alkisg> Well, that's my advice, for new clients that need to at least open a browser, I ask for cpu > 2000 benchmark score.
| |
| 18:16 | Which brand or model doesn't matter much
| |
| 18:17 | They usually all have 2 or 4 GB RAM and a gigabit ethernet nowadays, so the cpu is the main thing to look for
| |
| 18:18 | <julienfayad> I’ll be right back
| |
| 18:18 | alkisg there is an issue with kerberos that needs your attention (or vagrantc maybe)
| |
| 18:18 | I have to go now, be back in a few minutes
| |
| 18:19 | julienfayad has left IRC (julienfayad!~julienfay@82.112.162.224, Quit: julienfayad) | |
| 18:28 | <alkisg> bennabiy: http://www.gearbest.com/tv-box-c_11262/nt6_mini~pc/
| |
| 18:29 | <bennabiy> alkisg: which one on that page? Lots of options...
| |
| 18:29 | <alkisg> bennabiy: depends on your available budget
| |
| 18:29 | E.g. how about this one? http://www.gearbest.com/tv-box-mini-pc/pp_361276.html
| |
| 18:31 | 2883 passmark, and core i3 client graphics should be supported for many years...
| |
| 18:32 | And the internal ssd means that you can cache the squashfs image and have 50+ fat clients from the same server
| |
| 18:36 | <bennabiy> I am not needing 50 in one location :) I would be fine with that if I could get it without the SSD, or straight barebones
| |
| 18:37 | <alkisg> When I say "you can serve 50", that additionally means that "your 10 or xxx<50 that you need will need lower network bandwidth, they'll go faster"
| |
| 18:37 | For example, loading libreoffice needs 120 MB of bandwidth
| |
| 18:37 | Why not save it, if you can?
| |
| 18:38 | And let the bandwidth available for faster sshfs/home access?
| |
| 18:39 | You're spending money to speed up the user experience, using an ssd for local cache can be a big speedup no matter how many clients you have
| |
| 18:40 | SSDs currently have 500 MB transfer rates, that's 40 gbps for 10 clients, which is 40 times faster than a gigabit network
| |
| 18:43 | <bennabiy> So how would you cache to the local ssd?
| |
| 18:44 | <alkisg> I already have a script in upstream ltsp that updates a local kernel+initrd
| |
| 18:44 | For nbd, it's just a "check if /dev/nbd0 is newer than what we have, and if so, copy it to /dev/sda2", i.e. a couple of commands away
| |
| 18:45 | And of course such scripts can be upstreamed, they interest lots of people
| |
| 18:46 | Ideally it would use either the old local copy, or /dev/nbd0 directly, until the new one is synced, so no waiting at all is involved
| |
| 18:48 | forum has joined IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at) | |
| 18:51 | <bennabiy> Hmm. Interesting
| |
| 18:52 | And this would be for a fat client, right?
| |
| 18:54 | forum has left IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at, Quit: forum) | |
| 18:56 | <alkisg> Yup
| |
| 18:56 | Personally I only recommend reusing old clients as thins, almost never buying new thin clients except for really special environments that don't need browsing etc
| |
| 19:00 | <bennabiy> alkisg: what do you think of this? https://www.amazon.com/barebone-Qotom-M310-i3-5005U-Processor-computers/dp/B01EA4TBKQ/ref=sr_1_4?ie=UTF8&qid=1470941832&sr=8-4&keywords=mini+pc+i3
| |
| 19:01 | I can get 4G ram for $15-$17 and if I needed, I could get 32G SSD for about the same.
| |
| 19:02 | <alkisg> bennabiy: sounds fine. And you can of course leave the ssd for later, when a bit more speed up will be needed (due to applications getting slower), and ssd's will be a bit cheaper
| |
| 19:03 | <bennabiy> true
| |
| 19:06 | kjackal_ has joined IRC (kjackal_!~quassel@2a02:582:cea:d100:5c44:70e8:cba4:27dd) | |
| 19:07 | kjackal has left IRC (kjackal!~quassel@2a02:582:cd4:b500:5c44:70e8:cba4:27dd, Ping timeout: 264 seconds) | |
| 19:15 | julienfayad has joined IRC (julienfayad!~julienfay@94.187.66.230) | |
| 19:17 | julienfayad has left IRC (julienfayad!~julienfay@94.187.66.230, Client Quit) | |
| 19:20 | julienfayad has joined IRC (julienfayad!~julienfay@94.187.66.230) | |
| 19:21 | <julienfayad> Sorry was longer than I though, I’m back
| |
| 19:22 | alkisg you here ? available to talk about what I think is an LTSP issue ?
| |
| 19:25 | <alkisg> julienfayad: if it's about kerberos only, I'm not sure how much I would care... :D
| |
| 19:25 | * alkisg hasn't used kerberos at all | |
| 19:26 | <julienfayad> hehe
| |
| 19:27 | Well let’s say that I could spot the problem because I’m using kerberos but I think it’s a login mechanism issue
| |
| 19:27 | <alkisg> LDM is going to be completely dropped in ltsp 6
| |
| 19:28 | So noone is willing to do much maintenance there
| |
| 19:28 | <julienfayad> I see, then can we make sure that what will replace LDM will solve this issue ?
| |
| 19:28 | I do have a quick fix that I can apply and would happily document to the community
| |
| 19:28 | <alkisg> What is the usse?
| |
| 19:29 | *issue
| |
| 19:29 | <julienfayad> ok here is the thing. When a machine belongs is attached to a KDC, at login there is what we call a ccache that is being generated
| |
| 19:30 | this is what is being by other service to verifiy access permission to resources (in my case it was NFS)
| |
| 19:30 | with my configuration this ccache file was being stored in the /tmp folder
| |
| 19:30 | but for some reason, it was stored in the /tmp folder of the LTSP server, not the client
| |
| 19:30 | as if the login was being done on the server and not the client itself
| |
| 19:31 | <alkisg> Maybe because the client has the server kerberos configuration due to ltsp-pnp
| |
| 19:31 | <julienfayad> it does and this is correct
| |
| 19:31 | <alkisg> E.g. it may send the server hostname to the kerberos server
| |
| 19:31 | <julienfayad> since the kerberos server is the same for all
| |
| 19:31 | (and it is another machine not related to LTSP)
| |
| 19:31 | <alkisg> So the solution there is to have an init-ltsp.d script to properly do the kerberos configuration
| |
| 19:31 | Different for each client
| |
| 19:32 | <julienfayad> well no, the kerberos configuration is the same for all machines
| |
| 19:32 | <alkisg> And an ltsp-pnp cleanup.d script (or ltsp-update-image.excludes entry) to remove the server kerberos config
| |
| 19:32 | <julienfayad> in the config file you basically declare what is called a REALM and the KDC with other parameters that are global for all Kerberos Clients (The ltsp server is a kerberos client)
| |
| 19:33 | <alkisg> I think that when a client joins a domain or whatever, it stores the result somewhere
| |
| 19:33 | So I'm talking about *that* config. It might even be in /var.
| |
| 19:33 | <julienfayad> actually the communication with the Kerberos server works well on the LTSP clients (I can get Kerberos tickets etc…)
| |
| 19:33 | <alkisg> But how can you be sure that you're not using the server's credentials for kerberos?
| |
| 19:34 | <julienfayad> because the specific ccache file that is not being copied in the right location is the one for the user
| |
| 19:34 | it’s not a machine credential
| |
| 19:34 | <alkisg> That's a second issue
| |
| 19:34 | <julienfayad> the machine ccache file is being copied in the right location (/tmp of the client)
| |
| 19:34 | <alkisg> That may result from the main, first issue
| |
| 19:35 | Anyway, so the workaround that you speak of is to direct the file to the tmp of the client?
| |
| 19:36 | <julienfayad> actually an scp do the trick, that’s ok I think I can manage to implement it on my local env. But I wanted to discuss with you to see if the way login will be handled in LTSP6 will be different in a way that this issue won’t occur ?
| |
| 19:36 | <alkisg> I don't think that's a login issue
| |
| 19:36 | I think the solution would be the 2 things I said above
| |
| 19:37 | One init-ltsp.d script and one cleanup.d script
| |
| 19:37 | <julienfayad> hmm but what would that script be doing ?
| |
| 19:38 | <alkisg> Joining kerberos on a per client basis
| |
| 19:38 | <julienfayad> you think there is a variable being set that indicate to Kerberos where to send the ccache file to?
| |
| 19:38 | <alkisg> Something like that, yes
| |
| 19:39 | <julienfayad> let me check at #kerberos (I’m not very familiar with the inner mechanism of Kerberos myself…
| |
| 19:40 | <alkisg> I don't think it will be specific to the ccache file
| |
| 19:41 | So the question at #kerberos should be, "if I configure only one template client to use kerberos, and then clone it exactly as it is in 10 other workstations, what do I need to do in order to have things running smoothly?"
| |
| 19:44 | <julienfayad> I relayed your question, but from an intial answer it seems the ccache is being built on the Kerberos client machine after the Kerberos server send a reply to a request. Which would translate into (the LTSP server requested this ccache to the Kerberos Server, which replied positively so the LTSP server generated it)
| |
| 19:44 | let’s see what will be the answer to your specific question
| |
| 19:48 | alkisg, questions are being asked about the login process on ltsp clients
| |
| 19:48 | someone is wondering if the login is happening on the client or the server ?
| |
| 19:49 | <alkisg> The LTSP display manager is basically a GUI to "ssh user@server"
| |
| 19:49 | So the login happens on the server
| |
| 19:49 | LTSP 6 will hopefully use PAM to login on the client (even though behind PAM it will be still using ssh)
| |
| 19:50 | <julienfayad> so if LTSP 6 uses PAM, regardless of what service PAM will use to authenticate, the login will actually happen on the client ?
| |
| 19:50 | <alkisg> After login, we "su" to the client, so a proper local login happens as well
| |
| 19:50 | LTSP6 => yes
| |
| 19:50 | <julienfayad> that is in LTSP5 ? (su to the client)
| |
| 19:51 | <alkisg> After we use ssh user@server to authenticate the user, we then transfer the user account locally, and use "su" to login locally on the client
| |
| 19:51 | So that policykit, systemd-logind etc properly see the local user login
| |
| 19:52 | That means that in the end the user has logged in to the server with ssh, and locally with su.
| |
| 19:52 | <julienfayad> Ok, I’ll check what does this mean for Kerberos and also check if using PAM would solve the problem
| |
| 19:52 | <alkisg> What was the answer to my more general question?
| |
| 19:53 | <julienfayad> the question itself was kinda dismissed because the problem is for user ccaches not machine ccaches
| |
| 19:53 | <alkisg> I think you're ignoring the core of all the possible issues
| |
| 19:54 | And you're only focusing on one little detail
| |
| 19:54 | <julienfayad> well I’m actually forwarding your questions as they are
| |
| 19:54 | here were the answers
| |
| 19:54 | tlyu: the KDC doesn't really care about environment variables in the client
| |
| 19:54 | tlyu: the KDC also doesn't send a ccache file. that's something the client constructs after processing a network message it receives from the KDC
| |
| 19:55 | sorry that was actually before I asked your question
| |
| 19:55 | when your question has been asked
| |
| 19:55 | tlyu: the difficulties you're having are with user ccaches, not machine ccaches, right?
| |
| 19:56 | <alkisg> So he was basically trying to solve the issue you reported, instead of answering the more general question
| |
| 19:56 | <julienfayad> yeah kinda
| |
| 19:56 | <alkisg> You should probably ask that question later on, and completely unrelated to your initial question
| |
| 19:56 | Because they were confused now
| |
| 19:57 | <julienfayad> you are probably right, they are trying to help me solve the initial issue I had (ccache file not being in the right location)
| |
| 20:02 | alkisg, I’ll continue the conversation with Kerberos people, thanks for the clarifications on how login happens
| |
| 20:02 | <alkisg> np
| |
| 20:03 | <julienfayad> in the meantime, can you put me in the right directions as to where (which file) is best to write a small scp command so I can copy this ccache file from the server:/tmp directory to the client /tmp directory after a succesful login ?
| |
| 20:03 | pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme) | |
| 20:04 | <alkisg> julienfayad: grep -r scp /usr/share/ldm/rc.d/
| |
| 20:06 | <julienfayad> alkisg an answer about PAM *I don’t fully understand it* (geekosaur: PAM has its own weirdnesses, but it's possible. (actually discussing that currently in another channel...) the login process in the auth stack gets credentials, which have to be stashed in the PAM state and regurgitated into the user's session in the session stack)
| |
| 20:07 | for scp I can are the files X02-genmenu and X01-remoteapps from the LTSP project ?
| |
| 20:08 | <alkisg> Create your own X file, and use scp code similar to those examples
| |
| 20:08 | E.g. X03-fix-kerberos
| |
| 20:08 | <julienfayad> ok
| |
| 20:08 | <alkisg> I don't know the pam question you asked, and I don't think it points to the right way to solve your issue
| |
| 20:08 | <julienfayad> then I have a last question, how can I get the user id of the user who just logged in the LTSP client ?
| |
| 20:09 | <alkisg> $ grep -rw id /usr/share/ldm/rc.d
| |
| 20:09 | <julienfayad> for PAM that’s the question I asked julienfayad: for instance, LTSP6 plans on using PAM as its login manager, would that blend well with how Kerberos request tickets and ccaches at login ?
| |
| 20:09 | <alkisg> Yup, I don't think that's related to the issue
| |
| 20:10 | <julienfayad> for the user id that would make it: id_u=$(ssh_run '/usr/bin/id -u')
| |
| 20:10 | <alkisg> Yup
| |
| 20:10 | <julienfayad> one last question (so I could write something that I could submit as a patch eventually)
| |
| 20:11 | <alkisg> I'm not sure an scp patch will be accepted upstream, I think it's more of a hack than a proper fix
| |
| 20:11 | <julienfayad> the user id for user ABC will be the same on the LTSP server and on the LTSP client all the time ?
| |
| 20:11 | hmm well at least that will be documented somewhere and will be taken into consideration for LTSP6
| |
| 20:12 | vmlintu has joined IRC (vmlintu!~vmlintu@a91-153-33-91.elisa-laajakaista.fi) | |
| 20:12 | <julienfayad> or do you suggest doing this differently ?
| |
| 20:12 | <alkisg> We try to make it so, but it's not guaranteed, e.g. user alkisg's id may already exist locally, so then a new one will be used
| |
| 20:12 | Yes, I suggest what I already suggested twice above :)
| |
| 20:13 | One cleanup.d script to exclude the server kerberos info, and one init-ltsp.d script to properly join kerberos on a per-client basis
| |
| 20:14 | It might even be a security issue if you leave the server info there on the client image
| |
| 20:15 | azwieg103 has joined IRC (azwieg103!~andrew@office.zwiegnet.com) | |
| 20:16 | <julienfayad> for user id that is in the case of chroot ? or even in pnp mode ?
| |
| 20:16 | <alkisg> Normally it shouldn't be an issue in either case
| |
| 20:17 | In problematic setups, it may be the case in both methods
| |
| 20:17 | <vmlintu> julienfayad: are you setting up kerberized nfs4 for ltsp clients?
| |
| 20:18 | <julienfayad> as for the fix itself, from all the configuration i’ve made of kerberos I can’t see what would the init-ltsp.d script doing. But my visibility on this isn’t super clear yet
| |
| 20:18 | vmlintu, indeed that’s what I did
| |
| 20:18 | need help ?
| |
| 20:19 | <vmlintu> julienfayad: no, I've been using that already
| |
| 20:19 | <julienfayad> ohh my god then where were you all this time ? :-D
| |
| 20:19 | <vmlintu> julienfayad: on vacation ;)
| |
| 20:19 | <julienfayad> hehe
| |
| 20:19 | <vmlintu> julienfayad: did you end up putting a machine keytab in the image?
| |
| 20:20 | Or doing the mount with just the user ccache?
| |
| 20:21 | <julienfayad> by machine keytab do you mean having the client’s host principal in its keytab? because that showed no difference when I did or did not
| |
| 20:21 | yet, on the mount, a machine ccache file was being generated
| |
| 20:21 | my issue is not on the mount as it succeeds
| |
| 20:21 | <vmlintu> julienfayad: yes, the host principal..
| |
| 20:22 | <julienfayad> it’s with users that should have access and were being refused access
| |
| 20:24 | after logging with rpc.gssd -vvv
| |
| 20:24 | <vmlintu> So you do the mount without kerberos and then use the user credentials only to access the share? That sounds the same as I ended up doing it
| |
| 20:24 | <julienfayad> it appeared that when that user was trying to access the share, kerberos was unable to athenticate the user and thus refusing the access
| |
| 20:24 | no actually I mount with the -o sec=krb5
| |
| 20:24 | and that workds
| |
| 20:27 | <vmlintu> and you don't have /etc/krb5.keytab in the image?
| |
| 20:28 | <julienfayad> I do but it contains principal for the LTSP server’s host
| |
| 20:28 | when I rebuilt the keytab with the client’s host principal it didn’t change a thing
| |
| 20:29 | (this is because I use LTSP-pnp) so all config. files are being copied from the LTSP server
| |
| 20:29 | <vmlintu> with that principal in the image anyone can pretend to be the ltsp server, I think
| |
| 20:30 | <julienfayad> I guess so but that isn’t a major issue in my current setup
| |
| 20:30 | <alkisg> If it needs to be omitted, just put it in ltsp-update-image.excludes
| |
| 20:31 | <vmlintu> you can actually get the mount working without /etc/krb5.keytab at all in the image
| |
| 20:32 | <julienfayad> I think you are right vmlintu, I’ll need to try that tomorrow at the office
| |
| 20:32 | that would be safer indeed
| |
| 20:32 | <alkisg> For quicker testing, INIT_COMMAND_RM_KRB5="rm -f /etc/krb5.keytab" (so that you don't have to rebuild the image)
| |
| 20:33 | <vmlintu> But if you don't have /etc/krb5.keytab in the image, the mount -o sec=krb5 probably fails as SETCLIENTID fails..
| |
| 20:33 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 20:33 | <vmlintu> Or it could be that rpc.gssd got some changes when I reported those way back
| |
| 20:34 | <julienfayad> I’ll have to test vmlinut and let you know how it behaves
| |
| 20:34 | <vmlintu> http://markmail.org/message/tgvzw7isjq4choyi
| |
| 20:34 | <julienfayad> but my remote access is quite slow (it appeared xrdp is way slower than MS or Mac rdp)
| |
| 20:35 | <vmlintu> You can also play with rpc.gssd option -n that uses root ccache instead of /etc/krb5.keytab to do the mount
| |
| 20:37 | <julienfayad> well vmlintu if removing the LTSP host credential is causing troubles, at this stage I will prefer to keep it since this won’t cause any major security issue
| |
| 20:37 | but I’m curious to know how did you manage to get the users ccaches to be stored in the /tmp of the ltsp client ?
| |
| 20:37 | because that is my main issue now
| |
| 20:38 | <vmlintu> where do they end up in your system?
| |
| 20:38 | and are you using pam_krb5 or pam_sss or something else to get the tickets?
| |
| 20:39 | <julienfayad> basically now, I start the LTSP client, the share is already mounted but only root can access it
| |
| 20:40 | <vmlintu> root uses probably /etc/krb5.keytab then, I'd guess
| |
| 20:40 | <julienfayad> I need to copy the krb5cc_uid ccache file from the LTSP server /tmp directory to the LTSP client /tmp directory
| |
| 20:40 | so that the logged in user can access it
| |
| 20:40 | <vmlintu> Are you using ldm?
| |
| 20:40 | <julienfayad> otherwise the logged in user gets a permission denied when trying to ls the share
| |
| 20:41 | ldm ? I think so
| |
| 20:41 | I set LTSP up following this https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
| |
| 20:41 | <vmlintu> I had to switch to lightdm to get the kerberos tickets on the client
| |
| 20:41 | <julienfayad> and it worked almost out of the box
| |
| 20:42 | ldm <> lightdm ?
| |
| 20:42 | <vmlintu> I think in your case pam_krb5 is run on the server and that's why you get the ccache there
| |
| 20:44 | ldm provides the login screen for ltsp clients, normal ubuntu uses lightdm
| |
| 20:45 | <julienfayad> vmlintu if pam_krb5 is run on the server (and that’s probably the case since ltsp-pnp doesn’t depend on chroot) would using lightdm solve the issue ?
| |
| 20:47 | <vmlintu> with lightdm it's possible as that's what I'm running, but it certainly requires other changes too
| |
| 20:50 | the fastest solution might be to patch ldm to run kinit on the client when it calls ssh, but that's certainly not nice
| |
| 20:51 | <julienfayad> yeah I don’t know… kinit will request a password too
| |
| 20:52 | <vmlintu> you might be able to pass the password from ldm to kinit also
| |
| 20:53 | <julienfayad> then that would work
| |
| 20:53 | <vmlintu> What I'm running now uses lightdm + customised pam stack that mounts the kerberized nfs share when user logs in. So it first authenticates with kerberos and get the ticket, then uses that ticket to do the mount from the server and then continues with the login
| |
| 20:54 | So there's no ssh call to the server to authenticate the user in this case
| |
| 20:54 | <julienfayad> it sounds clean :-)
| |
| 20:54 | <vmlintu> This is the pam stack: https://github.com/opinsys/puavo-ltsp/blob/master/client/templates/etc/pam.d/lightdm-fatclient
| |
| 20:55 | <julienfayad> alkisg could that be useful for LTSP6 ?
| |
| 20:55 | <vmlintu> and this does the nfs mount during pam session phase: https://github.com/opinsys/puavo-ltsp/blob/master/client/puavo-ltsp-init-nfs
| |
| 20:56 | But this requires kerberos to work, so using that for LTSP6 would mean that kerberos is required
| |
| 21:00 | <julienfayad> and changin from ldm to lightdm is *easy* ?
| |
| 21:00 | <vmlintu> no
| |
| 21:01 | I really don't know what would be the easiest solution for you to get the ccache files on the client with ldm
| |
| 21:02 | <julienfayad> mmm well the quickest fix I have in mind now is to simply copy the file form the LTSP server to the client
| |
| 21:03 | I did it manually and tested, that worked
| |
| 21:03 | but I have to admin that having a structure that blends better with Kerberos or other login mechanism would be nice for LTSP6
| |
| 21:03 | <vmlintu> so every time someone logs in they copy the file?
| |
| 21:04 | <julienfayad> well as alkisg pointed out I can do it in an ldm/rc.d script
| |
| 21:04 | <vmlintu> ok, then that's certainly the best for you
| |
| 21:05 | that's something I've never used
| |
| 21:06 | <julienfayad> it’s not super clean, but it can get me going for now
| |
| 21:06 | <vmlintu> if you want to be done before christmas, it's most probably a good decision ;)
| |
| 21:08 | <julienfayad> hehe I need to be done before EOD tomorrow
| |
| 21:13 | julienfayad_ has joined IRC (julienfayad_!~julienfay@94.187.109.97) | |
| 21:13 | julienfayad has left IRC (julienfayad!~julienfay@94.187.66.230, Ping timeout: 276 seconds) | |
| 21:13 | julienfayad_ is now known as julienfayad | |
| 21:18 | <julienfayad> I will test it out tomorrow and let you know how it goes
| |
| 21:34 | julienfayad has left IRC (julienfayad!~julienfay@94.187.109.97, Quit: julienfayad) | |
| 21:35 | julienfayad has joined IRC (julienfayad!~julienfay@94.187.109.97) | |
| 21:39 | GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com) | |
| 21:48 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |
| 22:01 | GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 244 seconds) | |
| 22:03 | GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com) | |
| 22:11 | vmlintu has left IRC (vmlintu!~vmlintu@a91-153-33-91.elisa-laajakaista.fi, Ping timeout: 240 seconds) | |
| 22:30 | julienfayad has left IRC (julienfayad!~julienfay@94.187.109.97, Quit: julienfayad) | |
| 22:31 | julienfayad has joined IRC (julienfayad!~julienfay@94.187.109.97) | |
| 22:43 | kjackal_ has left IRC (kjackal_!~quassel@2a02:582:cea:d100:5c44:70e8:cba4:27dd, Ping timeout: 260 seconds) | |
| 23:14 | GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 244 seconds) | |