IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 23 March 2016 (all times are UTC)
| 00:13 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 00:32 | Ark74 has joined IRC (Ark74!~Luis@189.220.253.111) | |
| 04:11 | MCMXI|2 has joined IRC (MCMXI|2!~kvirc@v-74-91-112-62.unman-vds.internap-atlanta.nfoservers.com) | |
| 04:15 | MCMXI has left IRC (MCMXI!~kvirc@v-74-91-112-62.unman-vds.internap-atlanta.nfoservers.com, Ping timeout: 252 seconds) | |
| 04:28 | MCMXI has joined IRC (MCMXI!~kvirc@v-74-91-112-62.unman-vds.internap-atlanta.nfoservers.com) | |
| 04:31 | MCMXI|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:04 | MCMXI 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:19 | alkisg_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:26 | ricotz 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:00 | kjackal 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:23 | kjackal 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:47 | gvy 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:10 | gvy has left IRC (gvy!~mike@altlinux/developer/mike, Ping timeout: 240 seconds) | |
| 10:16 | fnurl has left IRC (fnurl!3cf8605f@gateway/web/cgi-irc/kiwiirc.com/ip.60.248.96.95, Ping timeout: 264 seconds) | |
| 10:22 | gvy has joined IRC (gvy!~mike@altlinux/developer/mike) | |
| 10:25 | robb_nl has joined IRC (robb_nl!~robb_nl@ip-80-236-222-56.dsl.scarlet.be) | |
| 10:26 | adrianorg has left IRC (adrianorg!~adrianorg@186.215.23.220, Ping timeout: 240 seconds) | |
| 10:28 | adrianorg has joined IRC (adrianorg!~adrianorg@189.58.183.198.dynamic.adsl.gvt.net.br) | |
| 10:45 | robb_nl has left IRC (robb_nl!~robb_nl@ip-80-236-222-56.dsl.scarlet.be, Ping timeout: 248 seconds) | |
| 11:44 | Faith has joined IRC (Faith!~paty_@unaffiliated/faith) | |
| 11:50 | kjackal has left IRC (kjackal!~kjackal@onopfy.static.otenet.gr, Ping timeout: 240 seconds) | |
| 12:06 | markit has joined IRC (markit!~marco@host179-38-static.243-95-b.business.telecomitalia.it) | |
| 12:06 | robb_nl has joined IRC (robb_nl!~robb_nl@ip-80-236-222-56.dsl.scarlet.be) | |
| 12:39 | kjackal has joined IRC (kjackal!~kjackal@2a02:587:3101:3500:3914:7f2a:68cb:8b51) | |
| 12:45 | bennabiy has left IRC (bennabiy!~bennabiy@unaffiliated/bennabiy, Remote host closed the connection) | |
| 12:50 | bennabiy has joined IRC (bennabiy!~bennabiy@unaffiliated/bennabiy) | |
| 12:53 | robb_nl has left IRC (robb_nl!~robb_nl@ip-80-236-222-56.dsl.scarlet.be, Ping timeout: 248 seconds) | |
| 13:08 | mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Read error: Connection reset by peer) | |
| 13:11 | mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy) | |
| 13:15 | robb_nl has joined IRC (robb_nl!~robb_nl@ip-80-236-222-56.dsl.scarlet.be) | |
| 13:20 | robb_nl has left IRC (robb_nl!~robb_nl@ip-80-236-222-56.dsl.scarlet.be, Ping timeout: 252 seconds) | |
| 13:29 | zama has left IRC (zama!~zama@unaffiliated/stryx/x-3871776, Ping timeout: 276 seconds) | |
| 13:31 | zama has joined IRC (zama!~zama@unaffiliated/stryx/x-3871776) | |
| 13:43 | robb_nl has joined IRC (robb_nl!~robb_nl@ip-80-236-222-56.dsl.scarlet.be) | |
| 13:57 | Softeisbieger has joined IRC (Softeisbieger!~Softeisbi@ip-88-152-12-13.hsi03.unitymediagroup.de) | |
| 13:57 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
| 14:13 | zamba has left IRC (zamba!marius@flage.org, Ping timeout: 268 seconds) | |
| 14:13 | Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving) | |
| 14:15 | zamba has joined IRC (zamba!marius@flage.org) | |
| 14:23 | gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: Leaving) | |
| 14:39 | professor_ has joined IRC (professor_!bb422a82@gateway/web/freenode/ip.187.66.42.130) | |
| 15:50 | markit has left IRC (markit!~marco@host179-38-static.243-95-b.business.telecomitalia.it, Ping timeout: 276 seconds) | |
| 16:14 | moricef 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:51 | vagrantc 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:52 | themis21 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:18 | dtcrshr has joined IRC (dtcrshr!~datacrush@2801:88:f7a:100:240:a7ff:fe2d:d7c0) | |
| 17:18 | dtcrshr 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:58 | alkisg_web has joined IRC (alkisg_web!4d31fc7d@gateway/web/freenode/ip.77.49.252.125) | |
| 17:59 | alkisg_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:39 | Softeisbieger 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:57 | Ark74 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:59 | moricef has left IRC (moricef!~fab2@95-210-220-208.ip.skylogicnet.com, Remote host closed the connection) | |
| 19:00 | moricef has joined IRC (moricef!~fab2@95-210-220-208.ip.skylogicnet.com) | |
| 19:02 | Ark74 has joined IRC (Ark74!~Luis@189.220.253.111.cable.dyn.cableonline.com.mx) | |
| 19:08 | robb_nl has left IRC (robb_nl!~robb_nl@ip-80-236-222-56.dsl.scarlet.be, Ping timeout: 252 seconds) | |
| 19:10 | alkisg 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:22 | robb_nl has joined IRC (robb_nl!~robb_nl@ip-80-236-222-56.dsl.scarlet.be) | |
| 19:53 | Ark74 has left IRC (Ark74!~Luis@189.220.253.111.cable.dyn.cableonline.com.mx, Ping timeout: 248 seconds) | |
| 20:07 | kjackal 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:19 | alkisg_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:25 | robb_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:06 | ogra_ 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:07 | ogra_ 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:29 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |
| 21:40 | alkisg is now known as alkisg_away | |
| 21:47 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 23:49 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
| 23:51 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |