IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 11 July 2015 (all times are UTC)
| 00:23 | gbaman has joined IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com) | |
| 00:27 | gbaman has left IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com, Ping timeout: 246 seconds) | |
| 00:33 | Guest56386 has left IRC (Guest56386!73465b95@gateway/web/freenode/ip.115.70.91.149, Ping timeout: 246 seconds) | |
| 00:54 | gbaman has joined IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com) | |
| 02:07 | dberkholz has left IRC (dberkholz!~dberkholz@gentoo/developer/dberkholz, Ping timeout: 276 seconds) | |
| 02:07 | dberkholz has joined IRC (dberkholz!~dberkholz@gentoo/developer/dberkholz) | |
| 02:12 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 256 seconds) | |
| 02:14 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 02:58 | gdi2k has left IRC (gdi2k!~gdi2k@203.177.248.238, Ping timeout: 244 seconds) | |
| 03:26 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 256 seconds) | |
| 03:47 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 240 seconds) | |
| 04:05 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 04:41 | gbaman has left IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com, Ping timeout: 255 seconds) | |
| 05:23 | gdi2k has joined IRC (gdi2k!~gdi2k@203.177.251.132) | |
| 05:29 | gdi2k has left IRC (gdi2k!~gdi2k@203.177.251.132, Ping timeout: 255 seconds) | |
| 05:38 | gbaman has joined IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com) | |
| 05:53 | gbaman has left IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com, Ping timeout: 264 seconds) | |
| 05:58 | gdi2k has joined IRC (gdi2k!~gdi2k@203.177.251.132) | |
| 06:05 | gdi2k has left IRC (gdi2k!~gdi2k@203.177.251.132, Ping timeout: 250 seconds) | |
| 07:09 | work_alkisg is now known as alkisg | |
| 07:38 | * alkisg waves to vagrantc | |
| 07:38 | <Hyperbyte> Not to me? :(
| |
| 07:38 | <alkisg> Haha, I wanted to talk about a new ltsp configd, but I can also talk about the boat!!! :D
| |
| 07:38 | Very nice pic of it!!!
| |
| 07:38 | <Hyperbyte> No, let's talk about the ltsp configd instead!
| |
| 07:39 | Hehe, thanks.
| |
| 07:39 | How's the configd thing going? :-)
| |
| 07:39 | * alkisg is thinking of breaking that up to a new, separate project from ltsp | |
| 07:39 | <Hyperbyte> Why on earth would you do that?
| |
| 07:39 | <alkisg> There are several projects that try to configure things on boot
| |
| 07:39 | ltsp-client, casper, debian's liveboot...
| |
| 07:40 | And there are also *additional* needs, for example there's no project to configure a classroom of standalone clients
| |
| 07:40 | And, our configuration names will need to change anyway because we won't have LDM anymore, so no LDM_USERNAME but plain USERNAME or something...
| |
| 07:40 | It would make sense to have one project for all of those needs, either netboot + configuration, or livecd boot + configuration, or standalone boot + configuration
| |
| 07:41 | So I was thinking of starting that part outside of the ltsp sources, and ltsp could in the future depend on it...
| |
| 07:46 | * vagrantc is too tired to talk about anything | |
| 07:46 | * vagrantc has been busy suffering a broadening of skills | |
| 07:46 | <alkisg> np another time, there's no hurry....
| |
| 07:47 | What new skills?! Mountain climbing? :D
| |
| 07:47 | * vagrantc hides | |
| 07:47 | <alkisg> 'night vagrantc
| |
| 07:48 | <vagrantc> the cool stuff is ansible...
| |
| 07:50 | <alkisg> It's not related to ltsp etc, is it?
| |
| 07:50 | https://en.wikipedia.org/wiki/Comparison_of_open-source_configuration_management_software
| |
| 07:52 | ...can any of those allow me to set the xorg resolution and the lightdm's autologin name to a bunch of PCs?
| |
| 07:53 | <vagrantc> possibly
| |
| 07:53 | <alkisg> Then I need to look into that list before any implementation starts
| |
| 08:04 | <maldridge> alkisg: what are you trying to do?
| |
| 08:04 | <alkisg> maldridge: I want to have something similar to lts.conf, but for standalone (or even livecd) clients as well
| |
| 08:05 | <maldridge> so just some way to get the values out on a per client level?
| |
| 08:05 | <alkisg> The hard part is applying the settings
| |
| 08:05 | gbaman has joined IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com) | |
| 08:05 | <maldridge> what about saltstack combined with redis
| |
| 08:05 | <alkisg> E.g. "USERNAME" for autologin needs to support a few *DMs... lightdm, gdm, kdm...
| |
| 08:06 | <maldridge> or just saltstack for that matter, then you have your "classes" of machines that get state loaded into them
| |
| 08:07 | <alkisg> maldridge: does saltstack have the client configuration part?
| |
| 08:08 | I.e. can I tell it to configure the client at 1024x768@85Hz?
| |
| 08:08 | <maldridge> not sure what you mean by that, but it has a half that goes on the client
| |
| 08:08 | <alkisg> XRANDR_MODE_0=1024x768
| |
| 08:08 | <maldridge> it depends on what you are using to configure the screen
| |
| 08:08 | <alkisg> LDM_GUESTLOGIN=True
| |
| 08:08 | FSTAB_0="nfs... params..."
| |
| 08:08 | Things like that
| |
| 08:08 | <maldridge> but assuming that it supports setting things from a file, yes you could do that with saltstack or ansible very easily
| |
| 08:09 | I prefer ansible personally because you can have blank machines do a git checkout from a central repository to do initial config
| |
| 08:09 | <alkisg> Getting the configuration to the clients would be the easy part, publishing with avahi, signing directives with keys, whatever,
| |
| 08:09 | The hard part is finding a tool that implements those directives
| |
| 08:09 | I.e. some tool that contains code to set the client resolution
| |
| 08:09 | gbaman has left IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com, Ping timeout: 252 seconds) | |
| 08:10 | <maldridge> I can really only speak for ansible, but the idea is that you give it a state, and it tries to get the machine to that state
| |
| 08:10 | so in this case you could pass it your resolution, and using some regex/awk/sed magic, you could pass that as an xrandr modeline in an ansible task that would set the resolution
| |
| 08:10 | <alkisg> But it doesn't have a script that sets xorg's PreferredMode or runs xrandr in the login manager's callback scripts, right?
| |
| 08:10 | The hard part is finding where to put that command
| |
| 08:10 | <maldridge> no, I don't think there's anything currently available that can do that
| |
| 08:10 | <alkisg> Right, that's what I was thinking
| |
| 08:11 | <maldridge> there are lots of things that let you put together lists of things to go run on the endpoints, but I'm pretty sure you still have to build those lists
| |
| 08:11 | <alkisg> That's the main task though
| |
| 08:11 | <vagrantc> alkisg: can't define it in xorg.conf.d ?
| |
| 08:11 | <alkisg> vagrantc: it would need much code
| |
| 08:11 | <maldridge> vagrantc: depending on the distro that isn't actually parsed
| |
| 08:11 | <alkisg> For example, if it's not xrandr 2.0 compliant, then it would need an xrandr command hook
| |
| 08:11 | <maldridge> s/distro/gfx env/
| |
| 08:12 | <alkisg> PreferredMode wouldn't have any effect on e.g. vbox guests
| |
| 08:12 | As it's not xrandr 2.0 compliant
| |
| 08:12 | Each of the lts.conf directives needs some hours to get them properly implemented
| |
| 08:12 | That's the hard part
| |
| 08:12 | * vagrantc nods | |
| 08:12 | <alkisg> Getting the configuration to the clients is the easy part...
| |
| 08:13 | <maldridge> you could pretty easily do the fstab and default graphical environment stuff with ansible or similar, its setting things on the fly that I'm not sure you could easily do
| |
| 08:13 | <alkisg> Another example, finding the appropriate login manager hook to add that xrandr command is quite time consuming
| |
| 08:13 | <maldridge> the lab I'm responsible for has to wait for maintenence windows to change things like login shell because it requires a DM reload
| |
| 08:13 | <alkisg> Many of the commands would need to run at the init phase, before services start running
| |
| 08:13 | <maldridge> and lightdm will kill all running sessions to do that
| |
| 08:14 | <alkisg> Right, in the config daemon I was thinking , the clients would all have a hook at login to ask for newer configuration
| |
| 08:14 | Hooks for initramfs/init/service start/xorg start/login/logout etc
| |
| 08:14 | <maldridge> but how would you apply it without a quick restart of services
| |
| 08:14 | <alkisg> E.g. autologin username would get applied just before the dm starts
| |
| 08:14 | <maldridge> lightdm and gdm3 both statically define available sessions and themes at startup
| |
| 08:14 | <alkisg> So it wouldn't require a restart
| |
| 08:15 | <maldridge> ah, I see
| |
| 08:15 | <alkisg> And of course it wouldn't function if one was already logged in...
| |
| 08:15 | Each of the directives would have similar issues
| |
| 08:15 | "when to apply the xorg change? when to select the login server for load balancing?"
| |
| 08:15 | <maldridge> I think the problem with stuff that is already out there is that it expects the network to be up
| |
| 08:15 | <alkisg> That's what makes the client configuration difficult, it's not about a general configuration framework
| |
| 08:16 | <maldridge> and some of the things you need to change have to happen before the network is up
| |
| 08:16 | <alkisg> For ltsp, the network is always up
| |
| 08:16 | But I'd like to support standalone clients as well...
| |
| 08:16 | Or roaming "ltsp" clients, that use extensive local caching
| |
| 08:17 | (e.g. laptops over wifi, with local home)
| |
| 08:17 | OK so the basic questions are, "is this useful outside ltsp? and, something similar already exist?"
| |
| 08:18 | And I think it's very useful outside of ltsp, and nothing like that really exist, ltsp-client and casper and live-boot are a bit similar, but they're too focused on their own use cases
| |
| 08:21 | <maldridge> alkisg: what you are describing sounds very much like group policy, and I think you're right that there isn't anything like that yet
| |
| 08:21 | but at the same time, I don't know that there's a draw for that on regular *nix
| |
| 08:22 | <alkisg> What does "draw" mean in this context? That people might not want that?
| |
| 08:22 | (sorry sometimes my english fail me)
| |
| 08:23 | It does sound a bit like group policy, you're right... although it could do a lot more in the unix world... e.g. in windows, you can't have a live cd mount /home from elsewhere and use your local samba server for authentication
| |
| 08:25 | <maldridge> in this case I mean draw as in, a marketable need for such a service
| |
| 08:25 | <alkisg> I'm quite sure there is
| |
| 08:25 | <maldridge> really? Aren't most standing labs static though?
| |
| 08:25 | <alkisg> Schools here need it... and I think skolelinux even supports some of those things, although not on a "on boot" basis, but on a "install + configure" basis
| |
| 08:26 | http://www.ltsp.org/stories/widget-map/?location=Greece
| |
| 08:26 | All those are dynamic
| |
| 08:26 | <maldridge> yeah, certainly lots of schools, and I agree that this would be the ideal solution for thin systems
| |
| 08:26 | or even systems that reconfigure on boot
| |
| 08:26 | <alkisg> There are more than 1000 schools here that voluntarily selected netbooted pcs to standalone workstations, for ease of maintainance
| |
| 08:26 | <maldridge> but I question if traditional systems would use such a service
| |
| 08:27 | for the record, if I could do netboot, I would in a heartbeat
| |
| 08:27 | <alkisg> The problem is that good networking is not always feasible
| |
| 08:27 | <maldridge> just too many issues with it right now
| |
| 08:27 | <alkisg> And ssd disks now have 500+ mbps bandwidth
| |
| 08:27 | So, netbooting should be complimented with local caching
| |
| 08:27 | <maldridge> indeed, though for that to really matter, you would have to have a decent in place LAN, right?
| |
| 08:28 | the data has to get there somehow
| |
| 08:28 | <alkisg> Imagine that you could plug in a laptop via wifi to your lab, and it would take 2 minutes to boot the first time because it would load 50mb of the OS via wifi, but in the next time, it would need 20 seconds
| |
| 08:29 | The idea there is, "the first time you need to read a disk ...cluster/sector, read it over the network, but then cache it locally until the sysadmin publish a newer client image, in which case you need to delete your local cache"
| |
| 08:29 | *publishes
| |
| 08:29 | And of course local caching would be optional, it's just one of the available directives
| |
| 08:30 | <maldridge> so from the admin side of that, do I now have to be concerned about data on clients? How am I garenteed that sensitive data is never cached?
| |
| 08:30 | <alkisg> All these are implementation specific. In ltsp currently we have a cleanup phase, which deletes passwd entries etc, and of course doesn't publish /home over mksquashfs/nbd
| |
| 08:31 | But if the sysadmin wants to use local /homes, because clients do video processing, which means many GB of data, he would use FSTAB="some local partition", and then the sensitive data (/home/username/.*) would be local to the clients
| |
| 08:33 | <maldridge> so how would you specify the local cache?
| |
| 08:33 | <alkisg> ltsp, and also the new config daemon I'm talking about, would offer some options, each one of them with some pros and cons, and it would be up to the sysadmin to select which ones to use
| |
| 08:34 | <maldridge> does a partition have to already exist
| |
| 08:34 | <alkisg> That's just one of the many directives
| |
| 08:34 | <maldridge> I see
| |
| 08:34 | <alkisg> It's not important to go to in depth discussions just for one of them
| |
| 08:34 | liveboot uses a partition label for that
| |
| 08:34 | <maldridge> this all sounds very interesting, It just seems to require a lot of systems to work in slightly different ways from how they seem to be designed
| |
| 08:34 | <alkisg> I think it needs it to be called "persistence" or something
| |
| 08:35 | <maldridge> yeah, liveboot persistence uses a cache file
| |
| 08:36 | <alkisg> http://manpages.debian.org/cgi-bin/man.cgi?query=persistence.conf&sektion=5&apropos=0&manpath=Debian+8+jessie&locale=
| |
| 08:36 | The main benefit, like in ltsp, is that the sysadmin would only maintain one computer
| |
| 08:36 | one image
| |
| 08:37 | The additional benefit to ltsp, is that it would also work with a slow local network
| |
| 08:37 | And it could probably even work without network after the first boot...
| |
| 08:39 | dberkholz has left IRC (dberkholz!~dberkholz@gentoo/developer/dberkholz, Ping timeout: 246 seconds) | |
| 08:39 | <alkisg> In Finland they're using ltsp + a lot of custom scripts and they're already supporting some of those use cases (roaming laptops etc)
| |
| 08:43 | <maldridge> I used to work at a site where we did thin clients roaming, but we solved it by installing a site wide wireless grid so the clients never disconnected
| |
| 08:43 | <alkisg> !flash
| |
| 08:43 | <ltsp`> flash: Yes, flash sucks. An HD full screen 30 fps video needs 2.5 Gbps bandwidth (1920×1080×4×30)! Make sure you have LDM_DIRECTX=True in your lts.conf file, or if it's just youtube you're after, try some flash replacing plugin like http://linterna-magica.nongnu.org
| |
| 08:43 | <alkisg> Wifi will never be good enough without local caching and local cpu processing...
| |
| 08:44 | <maldridge> yeah, we only had I think 5 people that needed that
| |
| 08:44 | <alkisg> I really think that fat clients with local caching is the best way to manage computer labs
| |
| 08:45 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 08:46 | <maldridge> yeah, standing labs really should be fat imho
| |
| 09:35 | gbaman has joined IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com) | |
| 09:43 | alkisg has left IRC (alkisg!~alkisg@srv1-dide.ioa.sch.gr, Ping timeout: 252 seconds) | |
| 09:58 | work_alkisg has joined IRC (work_alkisg!~alkisg@81.186.145.154) | |
| 10:14 | work_alkisg is now known as alkisg | |
| 10:41 | gdi2k has joined IRC (gdi2k!~gdi2k@203.177.248.238) | |
| 10:47 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 10:48 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 10:54 | gdi2k has left IRC (gdi2k!~gdi2k@203.177.248.238, Ping timeout: 264 seconds) | |
| 10:59 | alkisg is now known as work_alkisg | |
| 11:07 | gdi2k has joined IRC (gdi2k!~gdi2k@203.177.248.238) | |
| 11:24 | gdi2k has left IRC (gdi2k!~gdi2k@203.177.248.238, Ping timeout: 244 seconds) | |
| 11:28 | gbaman has left IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com, Remote host closed the connection) | |
| 11:30 | adrianorg has left IRC (adrianorg!~adrianorg@201.22.229.47.dynamic.dialup.gvt.net.br, Ping timeout: 276 seconds) | |
| 11:31 | adrianorg has joined IRC (adrianorg!~adrianorg@187.115.107.192) | |
| 12:28 | gbaman has joined IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com) | |
| 12:37 | gbaman has left IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com, Ping timeout: 246 seconds) | |
| 12:58 | AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-xkawlbscnkdctaiw) | |
| 13:49 | gdi2k has joined IRC (gdi2k!~gdi2k@203.177.12.122) | |
| 13:50 | <clarkhaos> has anyone set up a LTSP cluster, limiting login into ltsp app groups?
| |
| 13:55 | gdi2k has left IRC (gdi2k!~gdi2k@203.177.12.122, Ping timeout: 246 seconds) | |
| 14:28 | uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek) | |
| 14:31 | uXus has joined IRC (uXus!~uXus@217.77.222.72) | |
| 15:08 | work_alkisg is now known as alkisg | |
| 15:08 | * alkisg thinks ltsp-cluster isn't really maintained anymore... | |
| 15:27 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 15:34 | gbaman has joined IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com) | |
| 15:39 | gbaman has left IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com, Ping timeout: 250 seconds) | |
| 16:11 | ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz) | |
| 16:32 | book` has left IRC (book`!~book`@105.ip-167-114-152.net, Ping timeout: 248 seconds) | |
| 16:35 | book` has joined IRC (book`!~book`@105.ip-167-114-152.net) | |
| 17:21 | gbaman has joined IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com) | |
| 17:38 | sutula has left IRC (sutula!~sutula@207-118-178-64.dyn.centurytel.net, Quit: ZNC - http://znc.sourceforge.net) | |
| 17:41 | sutula has joined IRC (sutula!~sutula@207-118-178-64.dyn.centurytel.net) | |
| 17:47 | sutula has left IRC (sutula!~sutula@207-118-178-64.dyn.centurytel.net, Ping timeout: 256 seconds) | |
| 17:47 | sutula_ has joined IRC (sutula_!~sutula@207-118-178-64.dyn.centurytel.net) | |
| 17:47 | sutula_ is now known as sutula | |
| 20:02 | vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-70.elisa-laajakaista.fi) | |
| 20:04 | <vmlintu> alkisg: I was just reading through the logs and noticed the discussion about ltspd.. With current knowledge I think one-time-boottime configuration is bad and all settings should be dynamically loaded from config file when they are needed
| |
| 20:06 | e.g. when lightdm starts, it should run a script that does the tricks needed instead of writing some file during boottime and then relying on that until next boot
| |
| 20:07 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 20:08 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 20:16 | <alkisg> vmlintu: each directive is special, not all of them can be handled the same
| |
| 20:16 | FSTAB just needs to be written to /etc/fstab, it's a one-time thing
| |
| 20:16 | XRANDR_MODE_0 can be read either on xorg init, or even on user login
| |
| 20:17 | USERNAME probably on xorg init, and written to /etc/lightdm/users.conf
| |
| 20:17 | ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat) | |
| 20:18 | <vmlintu> yes, there're cases that need to be done during boottime, but quite many can be done dynamically later
| |
| 20:18 | <alkisg> So the documentation should mention the directive name, its purpose, the files it changes, on which stage it's applied etc
| |
| 20:18 | The stages are initramfs/init/service start/xorg init/login/logout/poweroff
| |
| 20:18 | ...and I think I'm forgetting a couple more
| |
| 20:19 | <vmlintu> but not even /etc/fstab is needed if you run mount command from somewhere else
| |
| 20:19 | <alkisg> yes, but in some cases you don't have hooks
| |
| 20:19 | <vmlintu> e.g. if you want to encrypt nfs homes with kerberos, the mount needs to be done at login time from pam
| |
| 20:19 | <alkisg> E.g. you can't tell lightdm the autologin user name without writing a configuration file
| |
| 20:20 | Phantomas1 has joined IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas) | |
| 20:20 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Disconnected by services) | |
| 20:20 | <alkisg> Ah yes the login hook there should actually be two hooks, one from pam and one from /etc/xdg/autostart
| |
| 20:20 | Phantomas1 is now known as Phantomas | |
| 20:21 | <alkisg> So that it's possible to init the user's home dir with stuff, but also possible to run things inside the user session
| |
| 20:22 | Anyway the main question now is if we should start a separate project, outside of ltsp, or not...
| |
| 20:23 | The specific directives will be implemented the same way in either case, whether it's inside ltsp or outside of it
| |
| 20:23 | <vmlintu> If done properly - so that it works on local booting workstations too - this brings back the question on what LTSP means.. the terminal server part of it..
| |
| 20:23 | <alkisg> I'm just thinking that it should support non netbooted clients as well...
| |
| 20:24 | Well, if the config daemon is a separate project, then ltsp is just a glue to set up tftp, dnsmasq, nbd...
| |
| 20:24 | And to call debootstrap
| |
| 20:24 | <vmlintu> LTSP to boot thin clients is probably < 100 lines in total
| |
| 20:24 | <alkisg> It depends, if you care about "ltsp-build-client" then it's more
| |
| 20:25 | * alkisg doesn't care about bootstrapping chroots though | |
| 20:25 | <alkisg> it's easier to use VMs and normal installation methods
| |
| 20:25 | Also, ltsp-update-image needs to clean up a chroot and publish it
| |
| 20:26 | To be able to read chroots, .vdi images etc, set up an overlay, temporarily clear the users etc
| |
| 20:26 | There's also the pxelinux configuration... you know the scripts
| |
| 20:26 | It's small, but it needs to be there
| |
| 20:28 | <vmlintu> Do you want to support laptops through nbd caching or using some other method?
| |
| 20:29 | More than half of laptops using the images here never see an nbd server after they've been installed
| |
| 20:29 | <alkisg> I'd like to support at least xnbd-proxy
| |
| 20:29 | Which allows local-caching...
| |
| 20:30 | But it's easy to also add "sync on boot"
| |
| 20:30 | If the framework is there, it would be easy to add support for any number of things
| |
| 20:32 | <vmlintu> we went with background updates for the laptops
| |
| 20:33 | And we don't require the laptops to be connected to any specific network. But it requires that there's a server somewhere in public internet that provides the updates
| |
| 20:34 | But none of this really has anything to do with terminal servers
| |
| 20:35 | <alkisg> Sure
| |
| 20:35 | The name isn't important
| |
| 20:35 | Netbooting is just one of the use cases...
| |
| 20:36 | <vmlintu> Most of the functionality you are looking for is already in our repos in github, but I really don't want to call it LTSP as it's something else
| |
| 20:37 | <alkisg> vmlintu: you have a configuration daemon?
| |
| 20:37 | <vmlintu> yes
| |
| 20:37 | also everything ltsp-cluster is in there
| |
| 20:37 | <alkisg> Is it http-based?
| |
| 20:37 | <vmlintu> yes
| |
| 20:38 | <alkisg> Do you have a list of the available directives?
| |
| 20:38 | <vmlintu> It's called puavo-rest and it uses LDAP as its backend: https://github.com/opinsys/puavo-users/tree/master/rest
| |
| 20:39 | <alkisg> And the setup, is it as easy as e.g. apt-get install puavo-server? Or does it need the user to follow some wiki page?
| |
| 20:39 | Why don't you push it to e.g. debian repositories?
| |
| 20:40 | <vmlintu> It gives out json that describes the client devices desired status
| |
| 20:41 | It's built using ruby and quite a few gems are missing from ubuntu repos, so we just build it with all dependencies in our repos: http://archive.opinsys.fi/git-master/pool/precise/main/p/puavo-users/
| |
| 20:41 | So the current packages break debian policy
| |
| 20:43 | Here's the code that gives our the device settings: https://github.com/opinsys/puavo-users/blob/master/rest/resources/devices.rb
| |
| 20:43 | <alkisg> Gotcha... do you think there's some collaboration chance there? E.g. do you care for help in getting it to debian?
| |
| 20:50 | <vmlintu> That has been one of our long time goals, but we've been more busy with functionality so far
| |
| 20:51 | So it definitely would need others to work on it too
| |
| 20:55 | but it's getting late, so I need to get off now.. I can get you more information about the configuration part tomorrow
| |
| 20:56 | But like said - it's all based on ldap - so it's not a direct replacement for current lts.conf
| |
| 21:00 | vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-70.elisa-laajakaista.fi, Ping timeout: 256 seconds) | |
| 21:10 | <alkisg> No worries I'm not looking for an lts.conf replacement, I'm looking to break compatibility as LDM_* vars won't make sense there anyway
| |
| 21:10 | But I'm worried if LDAP will be difficult to set up...
| |
| 21:10 | (for users)
| |
| 21:10 | later!
| |
| 21:10 | alkisg is now known as work_alkisg | |
| 21:18 | gbaman_ has joined IRC (gbaman_!~gbaman@host81-139-247-109.in-addr.btopenworld.com) | |
| 21:18 | gbaman has left IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com, Read error: Connection reset by peer) | |
| 21:30 | Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 248 seconds) | |
| 21:35 | Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack) | |
| 21:43 | Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Remote host closed the connection) | |
| 21:44 | Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack) | |
| 22:01 | <maldridge> work_alkisg: ldap is a pain, my team got it boiled down to an ansible module, but building out the schemas needs someone who knows that they are doing
| |
| 23:02 | gbaman_ has left IRC (gbaman_!~gbaman@host81-139-247-109.in-addr.btopenworld.com, Remote host closed the connection) | |
| 23:27 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Read error: Connection reset by peer) | |
| 23:28 | staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu) | |