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


Channel log from 11 August 2016   (all times are UTC)

01:25Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 240 seconds)
01:28Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack)
01:45GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 258 seconds)
03:02Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 244 seconds)
03:07Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack)
03:09adrianorg has left IRC (adrianorg!~adrianorg@189.58.230.109.dynamic.adsl.gvt.net.br, Ping timeout: 240 seconds)
03:11adrianorg has joined IRC (adrianorg!~adrianorg@191.32.102.53)
04:38cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 244 seconds)
04:45cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
04:47bennabiy has joined IRC (bennabiy!~bennabiy@unaffiliated/bennabiy)
05:19pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 252 seconds)
05:34ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
05:43K0HAX_ has joined IRC (K0HAX_!~michael@shellhost.home.englehorn.com)
05:46TatankaT has joined IRC (TatankaT!~tim@193.190.253.114)
05:48K0HAX has left IRC (K0HAX!~michael@shellhost.home.englehorn.com, Ping timeout: 250 seconds)
05:48TatankaT_ has left IRC (TatankaT_!~tim@193.190.253.114, Ping timeout: 250 seconds)
06:09laprag has joined IRC (laprag!~ragnar@user.skolelinux.no)
06:11laprag has left IRC (laprag!~ragnar@user.skolelinux.no, Client Quit)
06:47mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
06:49vmlintu has joined IRC (vmlintu!~vmlintu@a91-153-33-91.elisa-laajakaista.fi)
08:15vmlintu has left IRC (vmlintu!~vmlintu@a91-153-33-91.elisa-laajakaista.fi, Ping timeout: 260 seconds)
08:29vmlintu has joined IRC (vmlintu!~vmlintu@a91-153-33-91.elisa-laajakaista.fi)
09:01Statler has joined IRC (Statler!~Georg@p54BFBE20.dip0.t-ipconnect.de)
10:49budgee has left IRC (budgee!~root@static.210.94.47.78.clients.your-server.de, Quit: leaving)
11:00vmlintu has left IRC (vmlintu!~vmlintu@a91-153-33-91.elisa-laajakaista.fi, Quit: Leaving)
11:00vmlintu has joined IRC (vmlintu!~vmlintu@a91-153-33-91.elisa-laajakaista.fi)
11:08GodFather has joined IRC (GodFather!~rcc@96.92.43.9)
11:30julienfayad has joined IRC (julienfayad!~julienfay@94.187.66.230)
12:10julienfayad has left IRC (julienfayad!~julienfay@94.187.66.230, Quit: julienfayad)
12:30GodFather has left IRC (GodFather!~rcc@96.92.43.9, Ping timeout: 276 seconds)
12:49GodFather has joined IRC (GodFather!~rcc@75-145-237-204-Michigan.hfc.comcastbusiness.net)
13:09vmlintu has left IRC (vmlintu!~vmlintu@a91-153-33-91.elisa-laajakaista.fi, Read error: Connection reset by peer)
13:26keyboardKat has left IRC (keyboardKat!ad0bffe9@gateway/web/freenode/ip.173.11.255.233, *.net *.split)
13:32forum has joined IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at)
13:47julienfayad has joined IRC (julienfayad!~julienfay@46.19.196.200)
13:55ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
14:02K0HAX_ is now known as K0HAX
14:09mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
14:10forum has left IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at, Ping timeout: 252 seconds)
14:29vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
14:33forum has joined IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at)
14:37forum has left IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at, Client Quit)
14:56forum has joined IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at)
14:59forum has left IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at, Remote host closed the connection)
14:59forum has joined IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at)
15:05julienfayad has left IRC (julienfayad!~julienfay@46.19.196.200, Ping timeout: 250 seconds)
15:14julienfayad has joined IRC (julienfayad!~julienfay@82.112.162.224)
15:44julienfayad has left IRC (julienfayad!~julienfay@82.112.162.224, Quit: julienfayad)
15:53julienfayad 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:05forum1 has joined IRC (forum1!~Icedove@212-183-84-50.adsl.highway.telekom.at)
16:05forum has left IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at, Read error: Connection reset by peer)
16:05forum1 is now known as forum
16:06vagrantc 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:21forum has left IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at, Ping timeout: 258 seconds)
16:33kjackal has left IRC (kjackal!~quassel@2a02:582:ccb:a00:6081:e8d2:35cb:6965, Ping timeout: 260 seconds)
16:33kjackal has joined IRC (kjackal!~quassel@2a02:582:cd4:b500:5c44:70e8:cba4:27dd)
16:53GodFather 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:46Statler has left IRC (Statler!~Georg@p54BFBE20.dip0.t-ipconnect.de, Quit: Leaving)
17:53forum has joined IRC (forum!~Icedove@212-183-84-50.adsl.highway.telekom.at)
17:54K0HAX has left IRC (K0HAX!~michael@shellhost.home.englehorn.com, Quit: ZNC 1.7.x-git-631-88a8675 - http://znc.in)
17:54K0HAX has joined IRC (K0HAX!~michael@shellhost.home.englehorn.com)
17:56K0HAX has left IRC (K0HAX!~michael@shellhost.home.englehorn.com, Client Quit)
17:56K0HAX 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:01forum 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:19julienfayad 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:48forum 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:54forum 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:06kjackal_ has joined IRC (kjackal_!~quassel@2a02:582:cea:d100:5c44:70e8:cba4:27dd)
19:07kjackal has left IRC (kjackal!~quassel@2a02:582:cd4:b500:5c44:70e8:cba4:27dd, Ping timeout: 264 seconds)
19:15julienfayad has joined IRC (julienfayad!~julienfay@94.187.66.230)
19:17julienfayad has left IRC (julienfayad!~julienfay@94.187.66.230, Client Quit)
19:20julienfayad 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:03pppingme 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:12vmlintu 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:15azwieg103 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:33ricotz 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:13julienfayad_ has joined IRC (julienfayad_!~julienfay@94.187.109.97)
21:13julienfayad has left IRC (julienfayad!~julienfay@94.187.66.230, Ping timeout: 276 seconds)
21:13julienfayad_ is now known as julienfayad
21:18
<julienfayad>
I will test it out tomorrow and let you know how it goes
21:34julienfayad has left IRC (julienfayad!~julienfay@94.187.109.97, Quit: julienfayad)
21:35julienfayad has joined IRC (julienfayad!~julienfay@94.187.109.97)
21:39GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com)
21:48ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)
22:01GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 244 seconds)
22:03GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com)
22:11vmlintu has left IRC (vmlintu!~vmlintu@a91-153-33-91.elisa-laajakaista.fi, Ping timeout: 240 seconds)
22:30julienfayad has left IRC (julienfayad!~julienfay@94.187.109.97, Quit: julienfayad)
22:31julienfayad has joined IRC (julienfayad!~julienfay@94.187.109.97)
22:43kjackal_ has left IRC (kjackal_!~quassel@2a02:582:cea:d100:5c44:70e8:cba4:27dd, Ping timeout: 260 seconds)
23:14GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 244 seconds)