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


Channel log from 23 March 2016   (all times are UTC)

00:13vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
00:32Ark74 has joined IRC (Ark74!~Luis@189.220.253.111)
04:11MCMXI|2 has joined IRC (MCMXI|2!~kvirc@v-74-91-112-62.unman-vds.internap-atlanta.nfoservers.com)
04:15MCMXI has left IRC (MCMXI!~kvirc@v-74-91-112-62.unman-vds.internap-atlanta.nfoservers.com, Ping timeout: 252 seconds)
04:28MCMXI has joined IRC (MCMXI!~kvirc@v-74-91-112-62.unman-vds.internap-atlanta.nfoservers.com)
04:31MCMXI|2 has left IRC (MCMXI|2!~kvirc@v-74-91-112-62.unman-vds.internap-atlanta.nfoservers.com, Ping timeout: 264 seconds)
05:46
<highvoltage>
maldridge: I agree, but it's been coming for a while. I'm sure there will be a successor :)
05:58
<maldridge>
I hope so, linux in schools needs to happen
05:59
I dunno if a built distro is the best way anymore though. Maybe massive meta packages
06:03
<highvoltage>
it really just needs to be easy and intuitive and easy to maintain
06:03
(imho)
06:04MCMXI has left IRC (MCMXI!~kvirc@v-74-91-112-62.unman-vds.internap-atlanta.nfoservers.com, Ping timeout: 246 seconds)
06:05
<maldridge>
I think it depends on what its being used for
06:05
I'm looking at what it would take to do managed linux for schools
06:19alkisg_away is now known as alkisg
06:23
<alkisg>
maldridge: since different regions/countries/districts of schools need different default apps and different settings etc, I was thinking that the best way to serve them would be to show an option in the installer about which of those regions this setup is in,
06:24
and then to have one developer per region maintain an edubuntu-ppa-region PPA, providing a package override for edubuntu-default-apps
06:25
For example, the greek-schools-ppa then would be edubuntu-el (same for all Greece), and it would offer different packages for primary, secondary etc education, even using our own local packages here that are not in the ubuntu archives
06:26
That would be the essence of edubuntu, and it would allow small communities to develop and support their own micro-flavor
06:26ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
06:27
<highvoltage>
nice idea
06:28
<alkisg>
I've asked stgraber if he wanted to go for it, but he didn't want to, that's why I didn't invest on edubuntu much time the last years...
06:34
<highvoltage>
I'm not sure if PPAs are the best way to go about it per sé either, but if it's easy to upload/update in the archives and if it's easy to give upload rights of those packages then that could work well
06:46
<stgraber>
highvoltage: would have to be in the archive or entirely out of it. it's not allowed to have a package in the archive add package sources or pull packages from ppas
06:46
anyway, I'm not here, it's almost 3am here and I should be sleeping :)
06:47
<highvoltage>
stgraber: heh, goodnight!
07:01
<alkisg>
Then that policy would need to be changed for edubuntu to have an active audience... :)
07:02
Or maybe something debian-based could be spinned
07:02
<maldridge>
eh, I run a lab where we maintain our own mirror, our official policy is that no other mirror exists, but then again, the distro we use doesn't have a concept of PPAs
07:02
only full repos
07:03
<alkisg>
maldridge: imagine that you maintain your own ppa, e.g. call it edubuntu-maldridge. And you put your metapackages there in order to override the ones shipped by edubuntu. Those metapackages would include your mirror etc.
07:03
That means that you could have your setup ready to run right out of the edubuntu installer
07:04
And since you'd be the only uploader to your own ppa, there wouldn't be any security risks
07:04
<maldridge>
well in our case, we also have software that is against the main mirror's policies, its kind of nice in that we can have stuff whose license would otherwise forbid distribution, since we are using it solely as an install mechanism
07:04
<alkisg>
The ppa would have the metapackage
07:04
Your mirror would have your software
07:04
The metapackage would add your own mirror
07:04
That's also what we're doing here
07:04
And it works remarkably well
07:05
<maldridge>
interesting, I may have to look into ubuntu again, but the systemd stuff honestly just turned me off of it. Not even from a high and mighty ideological point, just the effort to retool everything only to keep getting 4 year old software
07:05
<alkisg>
We have 20 GB of proprietary software, some in our own repository, and some in our privater repository with ip address checking for clients
07:05
stgraber just said that ubuntu doesn't allow that
07:06
<maldridge>
dang that's a lot of software, I assume its mostly stuff for site specific stuff?
07:06
<alkisg>
So for a distro was to utilize that idea, either the ubuntu policy would need to be changed, or some other derivative would need to be used
07:06
It's greek educational software, originally built for windows, then packaged in .deb format by us
07:07
<maldridge>
I really liked ubuntu for several years, we even used it to bootstrap our linux labs, but once people got over the "its not windows" bit, they got tired of things either being old
07:07
<highvoltage>
maldridge: systemd is pretty hard to avoid these days
07:08
<maldridge>
highvoltage: in the mainstream, but there are plenty of stable distros that fill the systemd-free niche
07:08
<highvoltage>
maldridge: not many worth using though
07:08
<maldridge>
and like I said, it was mainly the effort of retooling for it that was the issue
07:08
I agree, I believe though that the one we have settled on is quite workable
07:09
ofc for one offs or new sites that have a business need, I tend to stick closer to EL7, but then its easy since there's no baggage that needs to be brought along
07:11
alkisg: "greek educational software". I assume this boils down to things like classroom management, testing, and custom companion software for things?
07:12
<alkisg>
brb, phone...
07:12
<maldridge>
k
07:23
<alkisg>
maldridge: no, it's software for teaching lessons, foreign languages, mathematics, geography etc etc
07:23
Our classroom management tools are open source, epoptes and sch-scripts
07:43
<maldridge>
ok, cool
07:43
do you do any online testing?
07:55
<alkisg>
maldridge: what kind of online testing?
07:55
<maldridge>
like end of course exams or reading benchmarks, things like that
07:58
<alkisg>
Several of the educational apps are web based and some of them do have tests for exams etc
07:59
We're packaging them, and any school that wants to use them, do so
07:59
It's up to the schools which apps they want to use, if any
08:00kjackal has left IRC (kjackal!~kjackal@2a02:587:3101:3500:ad6e:e2c4:4e3a:1330, Ping timeout: 246 seconds)
08:10
<maldridge>
ok, I'm more used to the system where all our schools are on one platform and they all have the same tests that are mandated by the state. More of those are going digital
08:23kjackal has joined IRC (kjackal!~kjackal@onopfy.static.otenet.gr)
08:25
<vsuojanen>
it would be very cool to see how this packaging of software would go from separate packages to snaps/images. so one site would have one favorite snap/image and maintenance could be by anyone/anywhere. then site can get new snap/image on the server(s)
08:26
<alkisg>
One installation plus a metapackage is 15 minutes
08:27
I don't see why snaps or images are needed
08:27
I do see the need for tools like e.g. ansible though
08:29
<vsuojanen>
site admins would not need to know all different package names
08:30
<alkisg>
What's the difference between 'package-for-secondary-schools' and 'image-for-secondary-schools'?
08:30
It's still one name they need to know
08:31
(or ppa-for-secondary-schools...)
08:31
<vsuojanen>
it sounds like a snap when you put it like that
08:32
<alkisg>
The good thing with metapackages is that you don't have to worry about security issues like you do with snaps or clones
08:32
E.g. same ssh keys anywhere
08:33
Packages do have postinst scripts to (re)generate keys etc, while clones don't
08:33
<vsuojanen>
is this metapackage like a file containing a list (metadata) of different packages?
08:33
<alkisg>
This can be whatever a site maintainer wants, e.g. a collection of other packages and even some postinst settings
08:34
E.g. our sch-scripts package contains a user administration tool, a collection of software (ltsp, epoptes etc), and some default settings to have a school up and running without the admin doing anything other than installing sch-scripts
08:35
<vsuojanen>
ok. cool. because i very much like the idea of less maintenance on sites, also with the servers on different sites.
08:35
<alkisg>
Right, here we have one server per school, and the school IT teacher maintains it by installing our tools and following some simple instructions from a wiki
08:36
This model works very well, our support tickets dropped down 80% or so
08:37
<vsuojanen>
this idea of improving maintenance costs is really worth, always
08:47gvy has joined IRC (gvy!~mike@altlinux/developer/mike)
08:50
<vsuojanen>
it's hard to implement snaps when you run servers on different sites but it could be just server reboot or restarting the snap compared to package running local installation. both snaps and packages could fail but what about recovery..
08:51
<alkisg>
All package-based distros have fine mechanisms for recovery
08:52
E.g. if you reboot your server while installing a package, you can then just reinstall it
08:52
<vsuojanen>
all host security on sites could be on smart cards or keys, using client keys
08:52
<alkisg>
Or run `apt-get install -f` to finish what it started
08:54
<vsuojanen>
yes. I know package maintenances is working like a charm but what if in some day with some user it doesn't? local admin doesn't know what he is doing and trying to reinstall a package get always same result
08:55
<alkisg>
When package installation breaks or xorg doesn't start or the kernel doesn't see the usb ports etc etc, the user asks for remote support
08:55
!vnc-dide
08:55
<ltsp>
vnc-dide: To share your screen with me, run this: sudo apt-get --yes install x11vnc; x11vnc -connect srv1-dide.ioa.sch.gr - this is a reverse connection, it doesn't need port forwarding etc.
08:56
<alkisg>
I support 1000+ schools here and I still have time for development
08:57
<vsuojanen>
i don't have them :)
08:58
<alkisg>
I mean that this model works so well that we don't have many support issues anymore
08:58
I imagine if we were working with snap packages instead, we'd need tens of persons doing remote support
09:01
<vsuojanen>
I would not say package model is bad or unnecessary. How is that snap would do more work for you?
09:02
it's still same place where you package. sites just get the new software differently
09:02
<alkisg>
It would require us creating, testing, uploading and deploying a new snap, possibly very large, when shipping a new postinst script would be enough
09:04
<vsuojanen>
the snap i referred to is something like Docker and Snappy images
09:05
<alkisg>
Docker images contain the whole OS, don't they?
09:05
<vsuojanen>
so it's just antoher apt/yum for maintenance work
09:05
<alkisg>
Ubuntu snappy images can do a subset of what .deb packages can do, indeed, but of course they have a lot less infrastructure for deploying them
09:06
<vsuojanen>
not the whole OS but yes they need the whole depencies (images) docked before that what you want to run works
09:07
<alkisg>
My postinst can e.g. modify /etc/default/rcS which isn't even in the same package
09:07
It's a bit against the policy and it wouldn't go into Debian etc, but it's fine for site administration
09:07
I don't know if docker or snappy images support that
09:08
Ansible of course does support it, but it requires me having root ssh to each school, which isn't something that we want to impose to schools
09:09
<vsuojanen>
I haven't used the docker much either. They fit much more with internet of things and web services
09:14
i look forward with this LTSP development. I was just thinking that local adminstrations could live without package installations
09:14
<alkisg>
That idea was related to edubuntu, not to LTSP
09:15
But edubuntu doesn't want it, so it'll stay an idea, unless maybe if the debian-edu people like it or something
09:15
For us here it works fine, we do have our ppa and local private repository etc etc, but we don't have anything to lose if others don't want to use it
09:20
<vsuojanen>
np. i don't have anything to lose with the idea either. i could us it very well
09:22
* I could use the metadatapackage
10:10gvy has left IRC (gvy!~mike@altlinux/developer/mike, Ping timeout: 240 seconds)
10:16fnurl has left IRC (fnurl!3cf8605f@gateway/web/cgi-irc/kiwiirc.com/ip.60.248.96.95, Ping timeout: 264 seconds)
10:22gvy has joined IRC (gvy!~mike@altlinux/developer/mike)
10:25robb_nl has joined IRC (robb_nl!~robb_nl@ip-80-236-222-56.dsl.scarlet.be)
10:26adrianorg has left IRC (adrianorg!~adrianorg@186.215.23.220, Ping timeout: 240 seconds)
10:28adrianorg has joined IRC (adrianorg!~adrianorg@189.58.183.198.dynamic.adsl.gvt.net.br)
10:45robb_nl has left IRC (robb_nl!~robb_nl@ip-80-236-222-56.dsl.scarlet.be, Ping timeout: 248 seconds)
11:44Faith has joined IRC (Faith!~paty_@unaffiliated/faith)
11:50kjackal has left IRC (kjackal!~kjackal@onopfy.static.otenet.gr, Ping timeout: 240 seconds)
12:06markit has joined IRC (markit!~marco@host179-38-static.243-95-b.business.telecomitalia.it)
12:06robb_nl has joined IRC (robb_nl!~robb_nl@ip-80-236-222-56.dsl.scarlet.be)
12:39kjackal has joined IRC (kjackal!~kjackal@2a02:587:3101:3500:3914:7f2a:68cb:8b51)
12:45bennabiy has left IRC (bennabiy!~bennabiy@unaffiliated/bennabiy, Remote host closed the connection)
12:50bennabiy has joined IRC (bennabiy!~bennabiy@unaffiliated/bennabiy)
12:53robb_nl has left IRC (robb_nl!~robb_nl@ip-80-236-222-56.dsl.scarlet.be, Ping timeout: 248 seconds)
13:08mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Read error: Connection reset by peer)
13:11mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy)
13:15robb_nl has joined IRC (robb_nl!~robb_nl@ip-80-236-222-56.dsl.scarlet.be)
13:20robb_nl has left IRC (robb_nl!~robb_nl@ip-80-236-222-56.dsl.scarlet.be, Ping timeout: 252 seconds)
13:29zama has left IRC (zama!~zama@unaffiliated/stryx/x-3871776, Ping timeout: 276 seconds)
13:31zama has joined IRC (zama!~zama@unaffiliated/stryx/x-3871776)
13:43robb_nl has joined IRC (robb_nl!~robb_nl@ip-80-236-222-56.dsl.scarlet.be)
13:57Softeisbieger has joined IRC (Softeisbieger!~Softeisbi@ip-88-152-12-13.hsi03.unitymediagroup.de)
13:57ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
14:13zamba has left IRC (zamba!marius@flage.org, Ping timeout: 268 seconds)
14:13Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving)
14:15zamba has joined IRC (zamba!marius@flage.org)
14:23gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: Leaving)
14:39professor_ has joined IRC (professor_!bb422a82@gateway/web/freenode/ip.187.66.42.130)
15:50markit has left IRC (markit!~marco@host179-38-static.243-95-b.business.telecomitalia.it, Ping timeout: 276 seconds)
16:14moricef has joined IRC (moricef!~fab2@95-210-220-208.ip.skylogicnet.com)
16:21
<moricef>
Hi I want to install a chroot thin client educational distro based on a debian jessie on a debian jessie headless amd64 server. but I don't how to do that because ltsp-build-client use the root of the server to build the client.
16:27
<||cw>
moricef: a thin client by definition logs into the server's GUI, so you need the server to have a GUI setup even if you don't ever locally start an X screen
16:28
if you're making a fat client, that's different...
16:29
https://help.ubuntu.com/community/UbuntuLTSP/FatClients
16:30
even with thin, it's mostly just some extra disk space
16:32
<moricef>
That's mean I can't have a raspberry as terminal and a fat client on the server?
16:49
<sbalneav>
moricef: No, ltsp-build-client doesn't use the server's root, it builds a separate chroot filesystem for the thin client.
16:50
<moricef>
it's means i can't have ... (sorry for my english)
16:51
<sbalneav>
Can't have what?
16:51vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
16:51
<moricef>
but ltsp-build-client install something like a x server in the separate chroot ? I can't have a raspberry as terminal and a fat client on the server?
16:52themis21 has joined IRC (themis21!2506199a@gateway/web/freenode/ip.37.6.25.154)
16:52
<sbalneav>
The server is the server; it isn't a client for anything.
16:53
You can have a mix of both fat and thin clients, if you do the work to set it up that way.
16:53
And yes, ltsp-build-client will install the X server in the chroot.
16:55
<moricef>
so I can have a separate chroot filesystem with a distro wich is different than the server?
16:56
<sbalneav>
Yes. You'll have to set that chroot up on a server that's the same distro, but after you have the chroot, you can serve it from a different server.
16:56
<moricef>
for example a server with jessie and a client with gentoo, fedora or suze?
16:56
<sbalneav>
It'll take some work to set up, but there's no reason in principle why it wouldn't work.
16:57
You'd obviously have to do a lot of work to make it happen.
16:59
Back in a bit; have to go visit my mom.
17:00
<moricef>
the distro i want to install as client is based on jessie but have some extras repositery like ubuntu and others. it's a french educationnal distro Primtux
17:18dtcrshr has joined IRC (dtcrshr!~datacrush@2801:88:f7a:100:240:a7ff:fe2d:d7c0)
17:18dtcrshr has joined IRC (dtcrshr!~datacrush@unaffiliated/datacrusher)
17:36
<gehidore>
alkisg: bossman says he wants 10 of those machines...
17:37
@ 122USD each shipped 4G ram with a this case/psu: http://www.newegg.com/Product/Product.aspx?Item=N82E16811154107
17:58alkisg_web has joined IRC (alkisg_web!4d31fc7d@gateway/web/freenode/ip.77.49.252.125)
17:59alkisg_web has left IRC (alkisg_web!4d31fc7d@gateway/web/freenode/ip.77.49.252.125, Client Quit)
18:24
<alkisg>
gehidore: nice! :)
18:24
moricef: it's possible to have a headless server with xorg install and just not use xorg on the server
18:25
That will make it much easier for you, the clients will use the server's xorg, while the server will not use it
18:31
<moricef>
alkisg: Ok
18:31
<alkisg>
moricef: what are you client specs? cpu and ram?
18:31
raspberry pi 2 only?
18:31
<moricef>
raspberry pi 2 only
18:32
so no fat client i think
18:32
<alkisg>
I think you want it to be fat, but let's see
18:32
Fat clients are diskless netbooted clients
18:32
Thin clients the same
18:32
The difference is that thin clients run the apps of the server
18:32
Fat clients run the apps of the chroot, locally on the client
18:33
So if you want to use a distribution designed for pi, with access to gpio etc, you want a fat chroot
18:33
If you want the raspberry to be only a keyboard and a monitor and to run the apps of the server and only transmit the screen to the client monitor, you want a thin chroot
18:35
Is primtux available for raspberry?
18:35
<moricef>
yes, it's the second case : thin client
18:35
no it's an i386 debian
18:35
<alkisg>
OK, then the easiest way is to install primtux on the server, with xorg and everything, and create a thin chroot
18:36
!raspberrypi
18:36
<ltsp>
raspberrypi: (#1) Ubuntu/LTSP on Pi 2: https://help.ubuntu.com/community/UbuntuLTSP/RaspberryPi, or (#2) Debian/LTSP (with raspbian chroot) on Pi: http://cascadia.debian.net/trenza/Documentation/raspberrypi-ltsp-howto/, or (#3) unofficial Ubuntu/LTSP (with raspbian chroot) on Pi: http://pinet.org.uk/
18:36
<alkisg>
The #2 option there
18:39
<vagrantc>
oh, that documentation is a bit rusty
18:39
more of a proof of concept than documentation
18:39Softeisbieger has left IRC (Softeisbieger!~Softeisbi@ip-88-152-12-13.hsi03.unitymediagroup.de, Ping timeout: 276 seconds)
18:41
<moricef>
no i don't want to install primtux on the server because it's a young distro (2015) with extra repositories. Not enough stable for a server. And in the future, maybe the server will be use for another things. primtux is too specific
18:42
raspberry can use a i386 thin chroot
18:44
<vagrantc>
raspberry pi needs to run a raspberry pi compatible operating system ... but that operating system can connect to servers of other architectures
18:45
<alkisg>
moricef: if you run raspberry as a thin client, then it needs to connect to the server and run primtux on the server
18:45
That can happen if the server installation is primtux, which is the easiest way,
18:45
or it can happen in a virtual machine on the server that runs primtux,
18:46
or in a fat primtux chroot on the server with a special sshd configuration with chrootdirectory etc, which is a rather advanced setup
18:47
so better separate your ltsp server from any other "more stable" services that you want, and just run primtux on the server
18:49
<moricef>
but with fat client, are raspberry ressources sufficient?
18:49
<alkisg>
thin client, not fat
18:50
<moricef>
separate physically?
18:50
<alkisg>
run primtux on the server and use a thin chroot
18:50
if you want *other* services not related to ltsp, use another server or virtual machines
18:50
<moricef>
ok
18:53
but with "a fat primtux chroot on the server with a special sshd configuration with chrootdirectory etc, which is a rather advanced setup", it's possible to run primtux without installed it on the server
18:55
<alkisg>
Yes, well basically you need some kind of virtual machine, either chroot, schroot, lxc, kvm, vbox...
18:56
You need to run the chroot on the server in order for the clients to connect to it
18:57Ark74 has left IRC (Ark74!~Luis@189.220.253.111, Ping timeout: 248 seconds)
18:59
<moricef>
ok thanks. I must go now. thanks again.
18:59moricef has left IRC (moricef!~fab2@95-210-220-208.ip.skylogicnet.com, Remote host closed the connection)
19:00moricef has joined IRC (moricef!~fab2@95-210-220-208.ip.skylogicnet.com)
19:02Ark74 has joined IRC (Ark74!~Luis@189.220.253.111.cable.dyn.cableonline.com.mx)
19:08robb_nl has left IRC (robb_nl!~robb_nl@ip-80-236-222-56.dsl.scarlet.be, Ping timeout: 252 seconds)
19:10alkisg is now known as alkisg_away
19:20
<gehidore>
alkisg_away: in your testing did you test with both 4 and 8G or only 8G?
19:20
<vagrantc>
alkisg_away: was ltsp-trunk ready for release as far as you're concerned?
19:22robb_nl has joined IRC (robb_nl!~robb_nl@ip-80-236-222-56.dsl.scarlet.be)
19:53Ark74 has left IRC (Ark74!~Luis@189.220.253.111.cable.dyn.cableonline.com.mx, Ping timeout: 248 seconds)
20:07kjackal has left IRC (kjackal!~kjackal@2a02:587:3101:3500:3914:7f2a:68cb:8b51, Ping timeout: 246 seconds)
20:19
<alkisg_away>
gehidore: I only tested with 8 GB and only for a while, I'll test it as an LTSP server in a school in a week though
20:19alkisg_away is now known as alkisg
20:19
<alkisg>
vagrantc: yup, ltsp-trunk is ready to go
20:19
epoptes-trunk too, if you have some more time... :)
20:22
!nbd-client
20:22
<ltsp>
nbd-client: To try mounting the NBD image from the client initramfs: nbd-client 192.168.67.1 -N /opt/ltsp/i386 /dev/nbd0
20:22
<vagrantc>
alkisg: ok, will try to work them in :)
20:22
<alkisg>
Nice!!
20:22
<vagrantc>
alkisg: i overhead the conversation the other day about dropping the ubuntu-specific changes to ltsp?
20:25robb_nl has left IRC (robb_nl!~robb_nl@ip-80-236-222-56.dsl.scarlet.be, Quit: I'm gone, bye bye)
20:26
<alkisg>
vagrantc: yup!! Hopefully I'll be able to just run syncpackage now, if I have enough rights for it...
20:26
If not, we'll have to call the big guns again... stgraber :)
20:31
vagrantc: at some point I was asking to commit this, wrt LDM_AUTOLOGIN: http://paste.debian.net/418440/
20:31
I think it belongs in ltsp, but I also think you don't like that particular implementation there, so I'll keep it in sch-scripts, right?
20:32
For the use case where one does want to autologin or guestlogin in all the subnet (no hostnames set), then he'd have to use a different HOSTNAME_BASE
20:38
<vagrantc>
alkisg: that snippet looks like it unsets LDM_AUTOLOGIN/LDM_GUESTLOGIN if HOSTNAME isn't ltsp* ?
20:39
<alkisg>
...if it *is*
20:40
If the hostname is "random" then it's probably a new client that was added in the lab, but not in lts.conf, so the automatic LDM_USERNAME won't work
20:40
The user either needs to define LDM_USERNAME explicitly, or set a HOSTNAME, or use a different HOSTNAME_BASE to notify that it's not a "random" hostname
20:41
<vagrantc>
so that would break labs where we've set it up to autologin on ltsp*
20:41
<alkisg>
Right
20:41
And it will fix the aforementioned issue
20:42
<vagrantc>
(or guestlogin)
20:42
<alkisg>
So on those labs, sysadmins will need to define for example HOSTNAME_BASE=pc
20:42
<vagrantc>
it seems overly complicated
20:43
for default behavior, anywys
20:43
<alkisg>
I've settled with that after getting 10+ times the same issue from IT teachers
20:43
<vagrantc>
feature to enable this new behavior?
20:43
<alkisg>
They were thinking that xorg was broken because it was constantly restarting
20:44
They didn't understand that it was LDM_AUTOLOGIN=True in an unknown client
20:44
<vagrantc>
autologin doesn't handle login failures well at all
20:44
generally prefer guestlogin for that reason
20:45
<alkisg>
And I really don't want to patch LDM for that :) I've decided to settle for those 5 lines, it's only a matter if it'll go in sch-scripts or if you want it in ltsp
20:45
np from me
20:45
I don't want to invest time in getting ldm to handle autologin/guestlogin gracefully...
20:45
<vagrantc>
i can see the value of solving that issue in LTSP, though i'd like to not break backwards compatibility
20:46
<alkisg>
How many sysadmins have implemented the "have a user for all the subnet" idea? Maybe four? They'll see that it no longer logs in, and they'll ask here and put HOSTNAME_BASE, end of story :D
20:47
<vagrantc>
no idea how many ... i've seen more than 4 questions on ltsp-discuss, for sure
20:47
and there are instructions for configuring such an environment
20:48
<alkisg>
I feel that those who have been bitten from xorg restarting on unknown clients would be at least 10 times more than that
20:48
But again, np from, it's your call
20:48
*from me
20:49
My users will get it from sch-scripts so I don't mind at all
20:50
<vagrantc>
it's a change in defaults, and there's no way to override it ... i guess that's what's frustrating
20:51
even adding an additional configuration option to disable/enable the behavior would be good enough from my perspective
20:51
(although i'd rather rewrite as a case statement for the matching)
20:51
<alkisg>
They can put LDM_USERNAME="$HOSTNAME" in lts.conf :)
20:51
The case doesn't match digits
20:52
case ltsp[0-9]* means any character can follow after the digit
20:52
It's not a regexp
20:52
<vagrantc>
sure
20:52
a lot more legible, though.
20:53
alkisg: having to put LDM_USERNAME in lts.conf for every machine seems way too much.
20:53
<alkisg>
We can write it as a function in ltsp-common-functions if necessary
20:53
Under [Default]
20:53
Not for every machine
20:53
<vagrantc>
that actually works?
20:53
i didn't think it expanded variables
20:53
<alkisg>
Yup... it also allows running things :)
20:54
The curse of eval
20:54
<vagrantc>
needs the "" though?
20:55
<alkisg>
No no that's just there to prevent globbing
20:55
<vagrantc>
i still would prefer adding an option to enable the behavior, then i'd be fine with ti.
20:56
<alkisg>
...how would you call such an obscure option?
20:56
LDM_ALLOW_AUTOLOGIN_WITH_UNSET_USERNAME?
20:56
nah it's not even that
20:57
LDM_ALLOW_AUTOLOGIN_WITH_UNSET_USERNAME_ON_UNKNOWN_CLIENT=True.....
20:58
<vagrantc>
LDM_AUTOLOGIN_EXCLUDE=ltsp*
20:58* alkisg would prefer the "LDM_USERNAME=auto" syntax there, but you don't like it when our booleans become tristate or strings :D
20:59
<alkisg>
OK, and then they would just unset LDM_AUTOLOGIN_EXCLUDE?
20:59
(and GUESTLOGIN too?)
20:59
<vagrantc>
or set ...
20:59
<alkisg>
(10:58:13 μμ) ***alkisg would prefer the "LDM_USERNAME=auto" ==> sorry I meant LDM_AUTOLOGIN=auto there
21:00
OK, I can do that, should I have two of them, one for AUTOLOGIN and one for GUESTLOGIN?
21:00
<vagrantc>
that is awkward, isn't it...
21:01
<alkisg>
I wouldn't want to document those in lts.conf, but they could be documented in the source for those that need that particular use case
21:04
"If LDM_AUTOLOGIN=True and LDM_USERNAME/LDM_PASSWORD are not set, then they default to HOSTNAME. If HOSTNAME is also not set, then it is assumed to be an "unknown" client that is not defined in lts.conf, so LDM_AUTOLOGIN is automatically unset. To bypass that protection, set HOSTNAME_BASE="something other than ltsp". The previous paragraph applies for LDM_GUESTLOGIN as well."
21:04
That, I could see in lts.conf...
21:05
*in the docs
21:06ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 276 seconds)
21:06
<alkisg>
Anyway, I leave it up to you to commit it however you like it, or not at all :) Or postpone it for some other time...
21:07ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
21:13
<vagrantc>
alkisg: clearly, i'm inclined to postpone it indefinitely ... though i see the value in solving the issue somehow
21:13
<alkisg>
No worries then, let's just leave it in sch-scripts until ltsp 6
21:14
At that point it won't even say "LDM_" anymore, so there won't be any compatibility to break
21:15
<vagrantc>
we've certainly postponed a lot for LTSP6 :)
21:15
i think we should just jump to 7.
21:15
<alkisg>
LTSP 6 will break compatibility
21:15
And you want to be compatible to ... ltsp 1 :P
21:15
<vagrantc>
pfft.
21:16
i made some effort to be compatible with 4.x, though wasn't set on perfect compatibility
21:16
i only got involved when the LTSP5 idea was in development
21:17
but LTSP5 should at least be consistant with LTSP5 ... which other people haven't shared my opinion :/
21:19
<alkisg>
We introduced e.g. 50 more lts.conf variables since ltsp 5.0.0, we could easily have bumped the number to 6 or 7 and tell sysadmins to re-read the lts.conf docs once in a while
21:19
<maldridge>
reading docs, what arcane magic is that...
21:19
<vagrantc>
alkisg: that would also require writing them :)
21:19
<alkisg>
It's not like we made a consistent api that we don't want to break, a lot of the variables were introduced after a couple of minutes' thought...
21:20
<vagrantc>
i've done my share of them, i'm sure, but in general, tried not to introduce things that broke compatibility
21:29ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)
21:40alkisg is now known as alkisg_away
21:47ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
23:49ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
23:51ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)