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


Channel log from 29 April 2019   (all times are UTC)

02:39snurl has left IRC (snurl!snurl@host81-154-10-106.range81-154.btcentralplus.com, Ping timeout: 246 seconds)
02:41fnurl has joined IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com)
03:38fnurl has left IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com, Ping timeout: 258 seconds)
03:39fnurl has joined IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com)
04:06vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
05:42fnurl has left IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com, Ping timeout: 244 seconds)
05:43fnurl has joined IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com)
06:00ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
09:03woernie has joined IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de)
10:30fnurl has left IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com, Ping timeout: 250 seconds)
10:49fnurl has joined IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com)
11:59SYS64738 has joined IRC (SYS64738!~jhonny5@159.213.93.166)
12:06mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy)
12:07Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:19fnurl has left IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com, Ping timeout: 250 seconds)
12:21fnurl has joined IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com)
12:24SYS64738 has left IRC (SYS64738!~jhonny5@159.213.93.166, Ping timeout: 244 seconds)
12:49fnurl has left IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com, Ping timeout: 250 seconds)
12:59fnurl has joined IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com)
13:23fnurl has left IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com, Ping timeout: 250 seconds)
13:26fnurl has joined IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com)
13:29fnurl has left IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com, Client Quit)
13:51spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut)
14:06woernie has left IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de, Remote host closed the connection)
14:42fnurl has joined IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com)
15:32josefig has joined IRC (josefig!~josefig@unaffiliated/josefig)
15:55woernie has joined IRC (woernie!~werner@pD9E8BADB.dip0.t-ipconnect.de)
16:06xit_ has joined IRC (xit_!683390e5@gateway/web/freenode/ip.104.51.144.229)
16:08
<xit_>
I am working on setting up LTSP on Ubuntu 18.04 but am having trouble with the PXE booting of clients. Anyone want to try to give me some pointers?
16:11
<josefig>
xit_, what kind of problems?
16:15
<xit_>
I followed the instructions at http://wiki.ltsp.org/wiki/Installation/Ubuntu but I don't see instructions on configuring dnsmasq for PXE booting.
16:17
The clients connect, but then no pxelinux.0 file is found on the server.
16:22
josefig, thank you for responding, btw.
16:23
josefig, is the PXE booting setup outside the scope of the LTSP installation?
16:24
<josefig>
no, it's not
16:24
there is a script that you have to download and it will set it up the DNS.
16:25
do you have 2 NICs or only 1 ?
16:25
<xit_>
2 NIC setup
16:29
Is that the 'sch-scripts' mentioned in the installation page?
16:32
<alkisg>
(07:15:06 PM) xit_: I followed the instructions at http://wiki.ltsp.org/wiki/Installation/Ubuntu but I don't see instructions on configuring dnsmasq for PXE booting.
16:32
==> the 4 commands at http://wiki.ltsp.org/wiki/Installation/Ubuntu#b.29_Dual_NIC_.28Classic_DHCP.29
16:33
<xit_>
Yes, I did execute those commands. But they seem to be mostly relating to firewall settings for the interface traffic.
16:34
to allow clients to have internet access through the server
16:35
<alkisg>
xit_: the first command configures pxe booting
16:35
The other 3 are for the clients to see the internet
16:35
(07:17:10 PM) xit_: The clients connect, but then no pxelinux.0 file is found on the server. ==> did you run ltsp-update-image?
16:36
http://wiki.ltsp.org/wiki/Installation/Ubuntu#a.29_Installing_LTSP_in_.22chrootless.22_.28previously_pnp.29_mode
16:36
ltsp-update-image --cleanup /
16:37
<josefig>
xit_, you must check if something is blocking the internet, in my case i use ltsp for development teams and i had the issue that systemd-resolved was listening in the same port than dnsmasq
16:37
s/than/that
16:37
<alkisg>
josefig: if he doesn't have pxelinux.0, he probably didn't build the image at all
16:37
I don't think it's related to networking, but to the image
16:37
<josefig>
ah, you're right.
16:38
you have to create the image, also, the correct architecture.
16:38
<alkisg>
xit_: in general it's best to start by doing ALL the steps, not half of them; this should work out of the box. If you need customizations, it's best to do them later on
16:38
<josefig>
it happened to me the first time
16:40vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
16:44
<xit_>
Alright, I will scratch what I have done and do it again.
16:45
a question though...how does building/updating the image make the 'pxelinux.0' file appear on the server? That doesn't make sense to me.
16:47
<Sleaker>
xit_: hmm, I don't use dnsmasq. mine boots and grabs via tftp-hpa and I have the pxe files in the root of the tftp server
16:47
<xit_>
the dnsmasq config file specifies "dhcp-boot=net:pxe,/ltsp/amd64/pxelinux.0", at the tftp-root of "/var/lib/tftpboot/", but no such file is found there.
16:48
Yes, using the tftp-hpa was the way I did this years ago, but I saw that LTSP has recommended using dnsmasq instead...see instructions
16:48
<vagrantc>
ltsp-update-image may call ltsp-update-kernels
16:49
which is what copies the pxelinux* files into place
16:50
<xit_>
Ah, yes...that 'ltsp-update-kernels' was missing from the instructions..but I should have remembered to execute it myself..ugh.
16:51
<vagrantc>
shouldn't need to execute it manually
16:52
<alkisg>
xit_: nothing is missing, many people have followed that successfully. I think you missed the ltsp-update-image part, OR it failed and you didn't see the failure
16:52
xit_: did you use ltsp-build-client, or ltsp-update-image -c /?
16:52
<xit_>
Ah yes, I see my mistake now, I did neglect to run ltsp-update-image because I had skipped the step to install a desktop into the chroot.
16:53
<vagrantc>
chroots are too much trouble
16:53
<alkisg>
So, chroot mode... ltsp-build-client should have created pxelinux.0 for you then
16:53
<xit_>
I had used the --fat-client-desktop option on the ltsp-build-client instead
16:54
<vagrantc>
ltsp-build-client is basically deprecated
16:54
<alkisg>
So I'm guessing that ltsp-build-client actually failed and you didn't see the error
16:54
So it never compressed the image, and never called ltsp-update-kernels
16:54
And, your chroot might be in a somewhat broken state
16:55
<xit_>
when I said, chroot I was referring to the 'ltsp-chroot -m apt install ubuntu-mate-desktop' command I skipped in the instructions.
16:55
<vagrantc>
why not run chrootless?
16:56
<alkisg>
xit_: in that page, there's "a) Installing LTSP in "chrootless" (previously pnp) mode" and "b) Installing LTSP in "chroot" mode "
16:56
We're proposing (a), and we're thinking that you followed (b)
16:56
In (b), there's an ltsp-build-client command, which probably failed in your setup
16:56
That failure is before the ltsp-chroot step
16:57
<xit_>
Oh..well, it's just that when I did this years ago, it was with chroot, I was just following the steps that seemed closest to what I was familiar with, to avoid too many learning tangents.
16:57
I will follow your advice and try it the chrootless way
16:57
<alkisg>
You can also try single nic, it's easier
16:57
<vagrantc>
most testing and development happens in chrootless mode these days
16:57
<alkisg>
chrootless and single nic is the easiest setup
16:58
<Sleaker>
hmm. might need to try and swap over to that then
16:59
<xit_>
I have to go now, but you guys are all champs, you have helped me a lot, thank you all.
17:42
<mwalters>
How could I check that a script is being executed on a fat client and not the server?
17:43
I guess a simple hostname check...
17:43
(I'm half thinking outloud, and half wonder if someone has something in place that definitely works)
18:19
<alkisg>
mwalters: usually, $LTSP_FATCLIENT is set; also, grep init=/sbin/init-ltsp /proc/cmdline
18:19
<mwalters>
Thanks!
18:20
<alkisg>
In the future I think the ltsp test will be just "test -d /run/ltsp"
18:20
<mwalters>
Trying to write a couple scripts for checking password age/updating on all of our LTSP boxes... ldap/freeipa just rubs me the wrong way ;)
18:21
<alkisg>
mwalters: if you could write a small "how to ldap", it would help a lot for the newer ltsp
18:23
<mwalters>
oh, I'm avoiding ldap!
18:27mwalters has left IRC (mwalters!~ubox@c-73-152-61-86.hsd1.va.comcast.net, Ping timeout: 264 seconds)
18:29mwalters has joined IRC (mwalters!~ubox@c-73-152-61-86.hsd1.va.comcast.net)
18:29
<mwalters>
whoops, home server lost connection
18:29
I'm not doing ldap, trying to avoid it
18:31
Last time I tried ldap w/ linux was like 2009... we had a factory in Israel, and we needed to stand up a RHEL server to put our financial software on because of local laws... connected samba to active directory... it was a mess D:
18:31
I was the only person in the entire company with any real linux experience, so I got stuck with it :D
18:32
unfortunately... looks like password -S outputs the date the fat client was booted :D
18:33
or probably more accurately, the date the user logged into the fat client
18:48
<alkisg>
mwalters: how are you planning to do this/
18:48
You can allow the users to change password graphically, with remoteapps
18:49
<mwalters>
so, I have age checking working w/ a bash script right now
18:49
ltsp-remoteapps mate-terminal -- /my/script.sh
18:50
the script uses passwd -S to check age, if the age is greater than some specified value... call passwd
18:50
at least that's what I have roughed out right now
18:51
<alkisg>
mate-about-me allows the users to change the password graphically
18:51
<mwalters>
sprinkle in some user friendly echo messages and things, use read -s to get old/new passwd
18:51
are ideas
18:51
<alkisg>
You can do the check with a remoteapps script that calls that, to avoid showing a terminal to the users
18:51
<mwalters>
I need to "force" them to complete the process
18:51
<alkisg>
Terminals can be scary to new linux users...
18:51
<mwalters>
as part of our agency policies
18:51
no doubt
18:51
communication will be key
18:51
<alkisg>
You can pop graphical programs as many times as you like, until they do change the password
18:52
<mwalters>
lol
18:52
<alkisg>
And even show zenity dialogs, if needed
18:52
<mwalters>
yeah, I have a few scripts that use zenity already, I'm just kinda proof of concepting as well
18:52
we also have 4 different LTSP boxes... ideally I want the password to be synced between all of them
18:52
<alkisg>
Btw, all that because ldm doesn't allow to change aged passwords?
18:52
<mwalters>
basically
18:53
<alkisg>
Eh, it'd be much more convenient to fix that then
18:53
<mwalters>
Probably :)
18:53
On my end, this is driven by licensing requirements/federal law
18:54
we need to put forth at least a basic effort
18:54
due to the nature of what we do
18:54
(I'm assuming you have various privacy laws in Greece/EU regarding student privacy... similar to that)
18:55
<alkisg>
I mean, if you enforced "passwords are aged after 1 month" normally on the server, and solved the "update password at login" issue, shouldn't it be the best solution?
18:55
<mwalters>
yes, it would
18:55
However, I know nothing about ldm... and can muddle through some bash scripts ;)
18:56
<alkisg>
ok
18:56
<mwalters>
to be honest, my development experience is in webapps and things like that
18:57
(and bash scripting to support deployment/automation of that type of stuff)
18:58
so, what I'm saying is... I can get this running "good enough", nowish... versus putting an unknown quantity of time and effort into getting LDM to do what I want ;)
18:59
even in the case of LDM honoring password aging and supporting changes... I'd still need to develop the scripts to update the shadow hashes across 4 servers
19:00
<alkisg>
But you wouldn't need that if you used ldap, right?
19:00
Is ldap really that hard? I was wondering if it could be the "secure default" for the next ltsp...
19:00
<mwalters>
yes, but I'm a department of one... it's upfront cost, vs maintenance
19:00
another server, another OS, another thing to keep updated
19:00
<alkisg>
Like `ltsp-config ldap` and it would configure everything in a sensible way
19:01
<mwalters>
replace server with vm/container/whatever
19:01
<vagrantc>
we've done a lot to try and avoid ldap ... maybe we should explore what it takes to use it :)
19:01
<mwalters>
lol
19:02
A lot of it is not wanting YAVM ;)
19:02
<vagrantc>
well, many people have explored it ... but it's been a while
19:02
<mwalters>
or YAC
19:02
<alkisg>
(while the unsecure default could be nfsv3+copying passwd/shadow to the clients; only after reaaaly notifying the sysadmin about the security implications)
19:02
<vagrantc>
and many horror stories...
19:02
<mwalters>
I don't use NSF
19:02
eer nfs
19:03
<alkisg>
It's just that the ssh/sshfs thing is ltsp specific, it's not widely used
19:04
while things like "oh password aging doesn't work with lightdm" as solved rather fast
19:04
<mwalters>
sure... I mean... ldap is probably the "right" solution for my problem when it comes right down to it... I'm struggling with scale... standing up a whole new service for 4 other servers just seems silly to me
19:04
<alkisg>
*with lightdm and ldap
19:04
<mwalters>
if I had 10 ltsp servers, I'd probably be doing it
19:04
but honestly, we'll be down to 3 in the next year I think
19:12
<alkisg>
vagrantc: do you think we could rename the old source package to ltsp5, and keep it around for a few years, while the new source package that would be named ltsp, would only produce one binary package named ltsp, which would conflict with ltsp-client-core, ltsp-server, ltspfs, ldm etc etc?
19:13
So that people could still use ltsp5 for a few years, until the newer ltsp gets all the bells and whistles needed for production
19:14
<vagrantc>
conceptually possible, devil in the details :)
19:14
<alkisg>
Hehe, always :D
19:15
<vagrantc>
should only need to conflict with ltsp-client-core and ltsp-server
19:15
though maybe we'd want it to block other things ...
19:15
having ldm and ltspfs installed should be harmless, hopefully
19:16
since they don't enable any services by default...
19:16
<alkisg>
Possibly, but why not get rid of them anyway...
19:16
E.g. in the initial release we might say "it defaults to nfs3 and passwd/shadow copying which very insecure; use nfsv4/kerberos/ldap for proper security"; but that would be hard for our users, until ltsp-config is able to automatically configure all these
19:16
<vagrantc>
ugh.
19:16
not real fond of this copyring around shadow.
19:17
nfs3 for homedirs?
19:17
<alkisg>
Indeed; but if we're going for proper pam, it might be the quick workaround until that proper pam thing is implemented
19:18
Or, we could keep it in experimental for some time, until those things are implemented
19:18
I was reading a bit about nis; it's not much safer than just copying shadow
19:19
<vagrantc>
yeah, no reason to try nis
19:19
<alkisg>
So of the existing pam modules, I think ldap would work; but of course we wouldn't have sshfs then; so... nfsv4; and to protect that => kerberos
19:20
So it's getting complicated, and it needs a lot of experience in that field to define good defaults for ltsp-config
19:20
<vagrantc>
right
19:20
although we should still be able to do sshfs with ldap ?
19:20
<mwalters>
getting freeipa to work correctly and fully is... odd... I have mucked about with openldap in a while, though
19:21
(work correctly and fully on ubuntu)
19:21
(haven't mucked about with openldap)
19:21
<alkisg>
vagrantc: we'd need a pam hook to get the ldap password and then do an ssh connection, to be able to have the sshfs home
19:21
<vagrantc>
i seem to recall using samba's ldap implementation a few years back, but i wasn't the primary person working on it
19:21
<mwalters>
generally ldap won't disclose the password, only if the authentication request succeeded
19:22
<vagrantc>
hence libpam-sshauth ... but that's got it's own complications...
19:22
<mwalters>
e.g., client makes a request to the server, the server turns it around and asks the ldap server to verify the request
19:22
<alkisg>
sshfs by itself has a lot of issues (e.g. no ~/.dmrc); libpam-sshauth has a lot more
19:22
mwalters: one can get the password that the user typed to the DM, from a pam hook, without involving ldap
19:23
<vagrantc>
i didn't even think ~/.dmrc was used anymore, or certainly not consistantly
19:23
<alkisg>
vagrantc: there's also /var/lib/accountservice etc; but we don't have those dirs on the clients either; while ldap supposedly has solutions for such things
19:23
<mwalters>
Yeah, that's where my knowledge thins out... I've done nodejs applications authing against active directory... but I haven't dealt with pam at all beyond enabling the samba module
19:24woernie has left IRC (woernie!~werner@pD9E8BADB.dip0.t-ipconnect.de, Remote host closed the connection)
19:24
<alkisg>
E.g. maybe the last session is saved on ldap itself; dunno
19:24
<vagrantc>
alkisg: out of all of this, i get the impression kerberos is hardest to get right
19:25
alkisg: needs server-side configuration per client
19:25
<mwalters>
ldap also has the concept of the computer/client too... generally you register the computers themselves
19:25
<alkisg>
Heh, we might need to keep ldm around for a bit then, until all these things are resolved
19:25
<mwalters>
I'm not sure if that extends to kerberos, but I thought it did
19:26
<vagrantc>
LDM is the part i most want to deprecate ... but also has a lot of challenges
19:27
hence ... where we've been for the last few years
19:27
i'm just not sure how much longer we'll be able to keep LDM limping along ... a lot of services are getting more and more integrated into the display manager
19:28
<mwalters>
so libpam-ssh or similar would have full pam/local auth on the client, just configured to connect to the ltsp server?
19:29
s/connect/auth against the ssh server on the ltsp server
19:30
I wonder if that would be chainable... have a primary and several secondary servers...
19:31
<vagrantc>
should be chainable, sure
19:32
libpam-sshauth runs locally, and connects to the server via ssh ... if you successfully connect to the configured ssh server, pam treats it as a successful login
19:33
and sets up an ssh socket that you can do other ssh actions with
19:33
(e.g. sshfs, remoteapps, etc.)
19:33
<mwalters>
nice
19:33
<vagrantc>
but... it's a complicated world
19:33
<mwalters>
:D
19:34
<vagrantc>
we've definitely had it working as a proof of concept, but in practice there are lots of quirks
19:34
<mwalters>
there always are
19:39
all these threats of broken thumbs and fingers. I don't really want to touch ldm now
19:39
:D
20:07* alkisg wonders if scotty is still using ltsp anywhere, and if he'd be willing to spend some time on libpam-sshauth, once the rest of the things are ready...
20:14
<mwalters>
as long as he stays away from my fingers
20:18xit_ has left IRC (xit_!683390e5@gateway/web/freenode/ip.104.51.144.229, Quit: Page closed)
20:19
<vagrantc>
alkisg: haven't really gotten much response from scotty in a long while ...
20:22
<alkisg>
I wonder if the *@ltsp.org mails stopped working; jim only answered in his other mail
20:50Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
20:50ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection)
20:53
<josefig>
I'm trying to set up the screensaver to do the auto log off once the iddle time reaches 5 minutes but i don't find to how to do it.
20:54
<vagrantc>
you could write up a script with xautolock and such
20:54
did something like that years ago
20:59
<josefig>
yes, i'm reading about autolock
20:59
xautolock
21:11
<alkisg>
josefig: i imagine that if you e.g. set mate-screensaver-preferences to "floaters", then you can write your logout script at /usr/lib/mate-screensaver/mate-screensaver/floaters
21:11
I.e. the screensaver just calls an executable, and you can replace it with your logout script
21:12
Another way is to monitor `mate-screensaver-command -t` which tells you when screensaver got active, but that requires polling, it's not event driven
21:14
And /usr/share/applications/screensavers/gnomelogo-floaters.desktop should give you an example on how to create your own screensaver script for logout, without overriding an existing one
21:17
<quinox>
Currently I use login-via-LDAP for many things including LTSP, and I'm looking forward to using LDAP + NFSv4 (no experience with Kerberos yet, but I'm gonna get some)
21:17
<alkisg>
quinox: do you think some standard ldap schema could be selected as the default for ltsp users?
21:18
Or is it so varied that it should be up to the sysadmin?
21:18
<quinox>
with LDAP you leave it up to the user: you allow them to configure some search query and use that
21:19
<alkisg>
So we wouldn't be able to implement something like `ltsp-config ldap` for newbies?
21:20
<quinox>
that would set up a new LDAP server, or configure for an existing one?
21:20
<alkisg>
It would make the ltsp server an ldap server
21:21
<quinox>
I think we can make that work, if the user doesn't have LDAP yet he won't care how we structure it
21:21
<alkisg>
And then if the user wants to ...add a few users, what does he need to do?
21:21
What's the easiest way there?
21:21
<quinox>
currently I myself use https://www.ldap-account-manager.org/lamcms/
21:22
straight from Ubuntu's package manager, but it's poorly maintained
21:22
nobody seems to test it, so with new releases I sometimes have to hack the code a bit
21:22
<alkisg>
Ouch
21:22
OK maybe we could modify sch-scripts / ltsp-manager to work with ldap there
21:23
<quinox>
we could add some small command line scripts for it
21:23
<alkisg>
We developed that for schools, to be able to easily create new users and groups, with templates etc
21:23
Like, "create classes a1, a2, b1, b2, c1, c2, and 20 users in each of them, and shared folders for each class"
21:24
quinox: it's late here so I need to leave, but hopefully you could point me in the right direction some time in the coming months, when I'll have the first new-ltsp bits ready
21:24
Good night all :)
21:24
<quinox>
sure thing
21:24
nn
21:45
<josefig>
thank you, im reading about it
22:04
I did the lock on one pc, but when I tried to type the password it doesn't allow the user to login again