IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 26 July 2015 (all times are UTC)
| 01:30 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 01:32 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 01:52 | AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-gskjudcituelpyfr, ) | |
| 04:24 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 04:28 | lmds__ has left IRC (lmds__!~lmds@tui.pi-et-ro.net, Ping timeout: 246 seconds) | |
| 04:52 | gbaman has joined IRC (gbaman!~gbaman@82.20.71.114) | |
| 05:23 | ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz) | |
| 05:32 | gbaman has left IRC (gbaman!~gbaman@82.20.71.114, Remote host closed the connection) | |
| 07:34 | gehidore has left IRC (gehidore!~username@unaffiliated/man, Quit: WeeChat 1.2) | |
| 07:34 | Phantomas has joined IRC (Phantomas!~phantomas@ubuntu/member/phantomas) | |
| 07:34 | gehidore has joined IRC (gehidore!~username@unaffiliated/man) | |
| 10:10 | gbaman has joined IRC (gbaman!~gbaman@dab-ntm1-h-75-10.dab.02.net) | |
| 10:43 | gbaman has left IRC (gbaman!~gbaman@dab-ntm1-h-75-10.dab.02.net, Ping timeout: 244 seconds) | |
| 11:04 | warren_2 has joined IRC (warren_2!~warren@fedora/wombat/warren) | |
| 11:05 | kwmiebach has left IRC (kwmiebach!sid16855@gateway/web/irccloud.com/x-xqgxjwqqxlatxfjn, *.net *.split) | |
| 11:05 | warren has left IRC (warren!~warren@fedora/wombat/warren, *.net *.split) | |
| 11:05 | warren_2 is now known as warren | |
| 11:14 | kwmiebach has joined IRC (kwmiebach!sid16855@gateway/web/irccloud.com/x-rdpwbczlrlnabqbc) | |
| 11:15 | gdi2k has left IRC (gdi2k!~gdi2k@180.191.116.224, Remote host closed the connection) | |
| 11:33 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 11:34 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 11:46 | work_alkisg has joined IRC (work_alkisg!~alkisg@clnt-dide.ioa.sch.gr) | |
| 11:49 | work_alkisg is now known as alkisg | |
| 11:51 | <alkisg> 13:29 <Hyperbyte> work_alkisg, hey hey. Any idea about how LTSP works on Ubuntu MATE 15.04?
| |
| 11:51 | Hyperbyte: I'm on Ubuntu mate 14.04.2, it works fine with only a few fixable glitches
| |
| 11:52 | I've no idea about non-LTS Ubuntu versions though, I don't use them except sometimes for debugging
| |
| 11:53 | I'm guessing that it will have a few issues with overlayfs...
| |
| 12:16 | FGXR6 has joined IRC (FGXR6!~phantom@ppp121-44-94-168.lns20.syd4.internode.on.net) | |
| 12:17 | F-GT has left IRC (F-GT!~phantom@ppp121-44-29-57.lns20.syd4.internode.on.net, Ping timeout: 244 seconds) | |
| 12:17 | adrianorg has left IRC (adrianorg!~adrianorg@186.215.16.42, Ping timeout: 246 seconds) | |
| 12:20 | adrianorg has joined IRC (adrianorg!~adrianorg@177.204.78.198.dynamic.adsl.gvt.net.br) | |
| 13:04 | <Hyperbyte> alkisg, overlayfs, why?
| |
| 13:05 | <alkisg> Overlayfs has been upstreamed and it started using a different syntax
| |
| 13:05 | So the old Ubuntu syntax (without workdir=) is now incompatible
| |
| 13:05 | (upstreamed in the kernel)
| |
| 13:06 | <Hyperbyte> mhmmmm
| |
| 13:15 | alkisg has left IRC (alkisg!~alkisg@clnt-dide.ioa.sch.gr, Quit: Leaving.) | |
| 13:17 | work_alkisg has joined IRC (work_alkisg!~alkisg@srv1-dide.ioa.sch.gr) | |
| 13:38 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 13:42 | work_alkisg is now known as alkisg | |
| 13:42 | * alkisg waves to vagrantc | |
| 13:43 | <alkisg> Long time no see :)
| |
| 13:43 | Our time difference is starting to show, in the past it didn't matter much... :D
| |
| 13:43 | *timezone
| |
| 13:45 | <vagrantc> heh
| |
| 13:45 | i've not been on irc as consistantly lately
| |
| 13:46 | <alkisg> So, are we doing any ltsp hackfests around debcamp?
| |
| 13:46 | Or bug squashing, whatever...
| |
| 13:57 | <vagrantc> yes, please!
| |
| 13:58 | august 9th through 14th is the debcamp portion, which i'll have the most flexibility on
| |
| 13:58 | less likely to be conflicting talks and such
| |
| 13:59 | <alkisg> Cool, I'll try to reserve those dates for ltsp. Phantomas, will you also be available then?
| |
| 13:59 | vagrantc: any specific things that you'd like us to work on?
| |
| 14:00 | <vagrantc> alkisg: i think the biggest blocker to ltsp moving forward is the lack of support for pam-based authentication
| |
| 14:01 | <alkisg> True, but is it something that we can work on in the hackfest, or is it more of a one-man-show, to be solved by whoever has time to find and code a proper solution?
| |
| 14:02 | <vagrantc> alkisg: so i don't know about figuring out how to hook the parts of libpam-sshauth into other pam modules that we need...
| |
| 14:03 | <alkisg> Is libpam-sshauth the correct way to go, and we're only lacking a few integration info?
| |
| 14:03 | Or should we be looking into some more mature solution, like samba, ldap, whatever?
| |
| 14:03 | <vagrantc> alkisg: honestly, anything we can do that's moving forward and showing innovation might be enough to rekindle interest in LTSP in general
| |
| 14:03 | <alkisg> E.g. `ltsp-config nis` or `ltsp-config samba`...
| |
| 14:03 | <vagrantc> alkisg: yeah, that's my question
| |
| 14:04 | i now have some experience with samba's AD support ... though i'm not sure that's a good approach either
| |
| 14:04 | <alkisg> A couple of years ago I asked Phantomas to check samba 4, and he did, and he told me it could work fine as an authentication mechanism for ltsp
| |
| 14:05 | <vagrantc> ah, so this gets to the idea of "support one authentication method by default out of the box without making it difficult to use others"
| |
| 14:06 | <alkisg> Right, whoever knows how to configure ldap should be able to do so without ltsp getting in his way
| |
| 14:06 | <vagrantc> i have a lot to learn about samba's authentication methods ... haven't really found ways to fully support it without running windows GUI tools, but i think that's just a matter of research.
| |
| 14:07 | <alkisg> I think it's a very big topic to cover in debcamp though...
| |
| 14:07 | And, it's possible to keep working in ltsp ...5, without solving the authentication problem yet
| |
| 14:07 | <vagrantc> other things like ltspd ...
| |
| 14:08 | <alkisg> Right
| |
| 14:08 | <vagrantc> i guess there just seems to be a lack of inspiration around LTSP... so i guess i'm grasping at what exciting new feature would get people excited
| |
| 14:08 | reinvigorate interest
| |
| 14:09 | (while at the same time re-using more existing code, rather than writing it ourself)
| |
| 14:09 | <alkisg> I was thinking that a "boot configuration daemon" and a "boot configuration client" are more general concepts that should be separate by ltsp, but used by it
| |
| 14:10 | "flexible boot" could be a name for the sub-project
| |
| 14:10 | <vagrantc> and so there's the rub. we could probably implement LTSP with ansible, puppet, chef, etc.
| |
| 14:10 | <alkisg> Liveboot, casper, standalone computer labs could benefit from it
| |
| 14:10 | <vagrantc> and people will be highly opinionated on which approaches to use
| |
| 14:10 | dracut, initramfs-tools, etc.
| |
| 14:11 | <alkisg> I don't think ansible, puppel, chef etc can configure a system for different boot needs
| |
| 14:11 | They're mostly about post-boot configuration, aren't they?
| |
| 14:11 | <vagrantc> yes, i've often thought live iage boot projects, such as deian-live and casper could really be merged into LTSP
| |
| 14:11 | alkisg: what exactly do you mean about "boot needs" ?
| |
| 14:12 | <alkisg> Where is the root file system? nfs, nbd...
| |
| 14:12 | Where is /home?
| |
| 14:12 | Where is the swap?
| |
| 14:12 | <vagrantc> they can be used to configure the server, which can tell the clients their initial boot setup
| |
| 14:12 | <alkisg> What user authentication scheme should I use?
| |
| 14:12 | Which resolution? Which user to autologin?
| |
| 14:12 | All the things that ltsp-client currently implements, and more
| |
| 14:13 | <vagrantc> all of those things seem very configurable with any of the above-mentioned tools
| |
| 14:13 | <alkisg> You can tell ansible to configure a xorg mode?
| |
| 14:13 | <Hyperbyte> alkisg, any tips upgrading 12.04 Gnome classic LTSP to 14.04 MATE LTSP (thin clients)? Can I just do upgrade of the OS and see everything work at once, or should I do a clean install?
| |
| 14:13 | <alkisg> Hyperbyte: it should work, but it's ubuntu, sometimes it just breaks :)
| |
| 14:14 | Backup, upgrade, install mate-desktop, and test
| |
| 14:14 | (and rebuild chroot)
| |
| 14:14 | <vagrantc> alkisg: i'm most familiar with ansible having worked with it a couple weeks now, but basically you tell it what state you want and possibly how to get there, and it checks that that state is present.
| |
| 14:14 | <alkisg> vagrantc: the problem isn't how to get to some state, is how to define the state
| |
| 14:15 | With ansible, the ltsp users would have to re-write all the init-ltsp.d code themselves...
| |
| 14:15 | <vagrantc> alkisg: it provides many modules that make it easier to define states, configuration, etc.
| |
| 14:15 | <alkisg> Let's take one example, autologin
| |
| 14:15 | Suppose that we want to support lightdm and gdm
| |
| 14:15 | <vagrantc> we could write a set of ansible bits that re-implement init-ltsp.d, yes.
| |
| 14:16 | <alkisg> So there, the biggest part is to find which files to touch in which versions of lightdm and gdm
| |
| 14:16 | Once you have that, the implementation is trivial
| |
| 14:16 | I think ansible will only help us in the "trivial" part
| |
| 14:16 | Not in the real work, i.e. to find which files we need to configure and on what conditionals
| |
| 14:17 | <vagrantc> sure, though it provides a fairly elegant way of defining those trivial bits.
| |
| 14:17 | <alkisg> For example?
| |
| 14:17 | Things like "append that string to that file"?
| |
| 14:17 | <vagrantc> as opposed to a bunch of random sed or shell scripts
| |
| 14:17 | yes, a lot of that sort of thing
| |
| 14:17 | <alkisg> That's our coding decision, we could easily have a library instead
| |
| 14:18 | <vagrantc> sure, but it handles a lot of the checks such as "file already contains that line" or "exactly where in the file should that line be" and such
| |
| 14:18 | <alkisg> The real work is the parts that check if lightdm > xxx_version is installed, then modify that file, otherwise modify the other file, but if gdm is installed then modify yet another file...
| |
| 14:18 | <vagrantc> right, that's the harder work
| |
| 14:19 | <alkisg> I think the file "sed'ding" can be implemented with a small library, I don't think it's a big deal
| |
| 14:19 | <vagrantc> i've even seen nightmarish things like gnome3 behaves badly when started from lightdm, so depending on the desired desktop, it should probably even start a different display manager...
| |
| 14:19 | <alkisg> python has shell file parsers, ini-file parsers etc
| |
| 14:19 | <vagrantc> yes, but ansible has already done a lot of that parsing
| |
| 14:20 | there are libraries to do all that stuff, but ansible is a reasonably nice user-interface to those libraries
| |
| 14:20 | <alkisg> How would you say in ansible, "add or modify LDM_AUTOLOGIN=True under [mac:address:xxx] in the lts.conf file, which is ini-like"?
| |
| 14:20 | <vagrantc> but, like i said, some people probably hate ansible and want chef, or puppet, or whatever, and i don't want to commit us to a single codebase ...
| |
| 14:21 | <alkisg> I think we just need 10 such functions
| |
| 14:21 | <vagrantc> but it does feel like we'll be reimplementing a lot of things
| |
| 14:21 | <alkisg> I can implement them in python, you can implement them in ansible, and we can let others implement them however they want
| |
| 14:21 | I think that's a couple of days work, not a big deal
| |
| 14:21 | I don't think it's significant...
| |
| 14:22 | <vagrantc> sure.
| |
| 14:22 | alkisg: although the example you give is exactly the sort of thing ansible is good at
| |
| 14:22 | i suspect puppet and chef also
| |
| 14:22 | <alkisg> The hard work is finding which files to edit, not the editing part per se
| |
| 14:22 | <vagrantc> or propellor! :)
| |
| 14:22 | <alkisg> I think that's what "flexible-boot" should target
| |
| 14:23 | To define a set of directives that could come either from a server/daemon or from static files in /etc, and to transform them to file edits
| |
| 14:23 | Then ltsp, casper, liveboot, and even other distros could use it
| |
| 14:24 | And I think it should have minimal dependencies
| |
| 14:25 | I think that we can implement the daemon and the client part in a week, not all of it, but enough to be the ..new ltsp-client
| |
| 14:25 | <vagrantc> minimal dependencies meaning what?
| |
| 14:26 | server-side python, client-side shell?
| |
| 14:26 | <alkisg> I don't mind about client-side python either
| |
| 14:26 | But not xorg or gtk or other DE-specific things
| |
| 14:27 | Modifying ini files from shell doesn't sound like a good idea, so the sed'ding library would probably not be written in shell
| |
| 14:27 | <vagrantc> so, essentially, just doing all the stuff we're doing in init-ltsp.d (or should be), and some server-client interaction ?
| |
| 14:28 | <alkisg> Right
| |
| 14:28 | The server daemon will allow us for a lot more flexibility that lts.conf though
| |
| 14:28 | *than
| |
| 14:28 | It's essentially what we were planning about ltspd
| |
| 14:29 | <vagrantc> sure
| |
| 14:29 | <alkisg> So for example we can check server load balancing, we can keep track of which clients have booted and in which state they are,
| |
| 14:29 | and we can even loop-mount .vdi images and serve the kernel/initrd via http
| |
| 14:30 | (so ltsp-update-kernels wouldn't be necessary, tftp would only be needed to download undionly.kpxe)
| |
| 14:30 | <vagrantc> ah, so it would even handle the OS boot?
| |
| 14:30 | <alkisg> It's possible, if we want it to...
| |
| 14:30 | <vagrantc> could even implement a tftp server in python, if we really needed to
| |
| 14:30 | <alkisg> I don't think we need it though,
| |
| 14:31 | because it's mostly used for x86, where undionly.kpxe works fine,
| |
| 14:31 | <vagrantc> we're seeing more and more interest in arm, with raspberry pi and some other things springing up
| |
| 14:31 | or perhaps i'm only seeing the parts i'm interested in :)
| |
| 14:31 | <alkisg> while for e.g. pi the kernel/initrd is local to the sdcard, and once the initrd is loaded it can then access the configuration from http directly from the daemon...
| |
| 14:32 | vervelak has left IRC (vervelak!~vervelak@139.91.248.3, Remote host closed the connection) | |
| 14:32 | <alkisg> The flexible-boot client can have a script to update the local kernel/initrd from the image, if it's newer
| |
| 14:32 | And automatically reboot to load the newer versions
| |
| 14:32 | <vagrantc> there are a number of promising ARM LTSP clients that could network boot with only u-boot on local media, but would require tftp
| |
| 14:33 | <alkisg> If they have local media, they can have a kernel/initrd there, automatically updated
| |
| 14:33 | Is there any non-x86 architecture that uses PXE and that doesn't need local media?
| |
| 14:34 | <vagrantc> why download 1-20MB of files to local media when .5MB will do?
| |
| 14:34 | actually, even debian is a 3MB kernel with a 18MB initrd now...
| |
| 14:35 | <alkisg> For example, ipxe supports 50 NICs. The linux kernel supports 500 NICs.
| |
| 14:35 | Putting ipxe on local media covers a lot less cases than putting the linux kernel on local media
| |
| 14:35 | And, it supports a lot less architectures
| |
| 14:36 | The kernel is what will drive the media; relying on its network drivers to access the network does make sense...
| |
| 14:36 | <vagrantc> i guess i'm just talking about arm, which doesn't typically support PXE (although there's some PXE-like behavior implemented in u-boot for many boards).
| |
| 14:36 | <alkisg> Is there any use cases where the client will have a 10 MB sdcard and not fit the kernel/initrd?
| |
| 14:36 | It's also faster for the clients to cache the slow tftp part locally...
| |
| 14:37 | <vagrantc> it's just the local media is often very slow, so updates would take maybe a minute or two vs. a couple seconds
| |
| 14:37 | <alkisg> The oldest sdcards have 10MB/sec, about 100 mbps, don't they?
| |
| 14:37 | <vagrantc> and u-boot updates less often that the kernel ... mind you, i'm talking about some pretty niche stuff here
| |
| 14:38 | i don't think we should spend the bulk of the time discussing ARM booting, but i am interested in it and have a fair amount of experience at this point
| |
| 14:38 | <alkisg> I think if we put code for automatic updates of a local kernel+initrd, we'll support all of the architectures while requiring only 30 mb of local media...
| |
| 14:39 | Anyway that's just one of the things the daemon might do in the future, if we want it to
| |
| 14:39 | <vagrantc> oh, you mean as a standard practice?
| |
| 14:39 | <alkisg> Yes, by an init-ltsp.d or initramfs script in the ltsp code base
| |
| 14:39 | ltsp.update-local-kernel=/dev/sda1 or something
| |
| 14:40 | <vagrantc> i must say, one of the things i've always advocated for LTSP as being safe to try it out as it won't mess with your local filesystems by default ... so would want safeguards there
| |
| 14:41 | <alkisg> Anyway, the main question is... we're looking to code ltspd and to update ltsp-client so that we remove all LDM_* directives etc. I think we should take the chance and re-develop them as a separate project, used by ltsp and possibly others.
| |
| 14:41 | Question, do we want to do that? If yes, I'll tell Phantomas to prepare so that we have something workable at the end of debcamp
| |
| 14:42 | It won't conflict with ltsp-client, both can be installed simultaneously
| |
| 14:42 | <vagrantc> sounds good, although i'm not sure how likely we'll be integrating all the other projects that do some of that kind of thing
| |
| 14:42 | <alkisg> So people can migrate in their own time
| |
| 14:43 | <vagrantc> now you're talking! :)
| |
| 14:44 | <alkisg> E.g. if we have init=/sbin/init-ltsp, we're calling ltsp-client which is using lts.conf, if we have init=/sbin/flexible-boot, then we're calling the newer client...
| |
| 14:44 | The newer client gets its configuration from the daemon, while ltsp-client will keep using lts.conf
| |
| 14:44 | <vagrantc> alkisg: i'm almost wondering if we don't implement an API and then an implementation, which could be compatible with other backends...
| |
| 14:44 | makes sense to me!
| |
| 14:45 | <alkisg> I think the implementation has 3 main parts:
| |
| 14:45 | <vagrantc> we basically need hooks into the bootloader, the initramfs, and the init wrapper...
| |
| 14:45 | <alkisg> 1) define the directives that we want, and document them. E.g. AUTOLOGIN_USER=xxx, XRANDR_MODE_0=yyy
| |
| 14:46 | 2) find the files that we need to edit in order to implement them
| |
| 14:46 | 3) ...do the actual implementation
| |
| 14:46 | <vagrantc> me would like to drop the ALL_CAPS trend
| |
| 14:46 | <alkisg> The (3) part is actually the easiest... :)
| |
| 14:47 | I'd love to drop the caps as well, but that would mean that we switch to configuration files that don't have shell syntax anymore
| |
| 14:47 | I.e. directive != environment variable
| |
| 14:47 | <Phantomas> Which is great :P (Hello)
| |
| 14:48 | I'll be available alkisg, yes
| |
| 14:48 | <alkisg> With the proper sed'ding library, most of the directives implementation would be small... add that line to that file... the programming language wouldn't be significant there, we could easily use python without imposing a big learning curve
| |
| 14:48 | Hi Phantomas, nice!
| |
| 14:50 | The client implementation is mostly /usr/share/ltsp/init-ltsp.d/ and /usr/share/ldm/rc.d/. Most of them are small scripts. The large ones like X01-localapps shouldn't be shell scripts anyway...
| |
| 14:52 | vagrantc: so, do we have the OK to start coding flexible-boot? :)
| |
| 14:54 | <vagrantc> alkisg: huh? shell doesn't require ALL_CAPS
| |
| 14:55 | alkisg: how did i get the hat of authority?
| |
| 14:55 | <alkisg> Exported environment variables in shell are in CAPS, not because of syntax requirements but because of programming style...
| |
| 14:55 | vagrantc: you'll be the one to package it and push it to debian :D
| |
| 14:55 | <vagrantc> aha.
| |
| 14:56 | alkisg: ok, this sounds good.
| |
| 14:56 | alkisg: and honestly, it will probably make it easier to move towards the pam auth stuff
| |
| 14:56 | <alkisg> I think so too
| |
| 14:57 | vagrantc: if you have any good ideas about the project (flexible-boot) name... :)
| |
| 14:57 | <vagrantc> alkisg: so, are you talking about the clients running code handed off from the server, rather than scripts on the filesystem?
| |
| 14:57 | <alkisg> Scripts on the filesystem
| |
| 14:57 | <vagrantc> alkisg: it would make things like NBD image regneration less necessary if we could pass the scripts dynamically
| |
| 14:58 | <alkisg> Each script would implement *and* document (doxygen-style) a directive
| |
| 14:58 | We can send code to the client if we want to, but I also want to support server-less configuration, e.g. from cached files or from files in /etc/flexible-boot
| |
| 14:58 | <vagrantc> alkisg: one thing that storing boot stuff in local media allows for is storing security certificates and actually having a secured network boot
| |
| 15:00 | another "desired feature" but we should support insecure booting too, of curse :)
| |
| 15:01 | <alkisg> We can also have the server sign the scripts or files that it sends to the clients, if we want to
| |
| 15:01 | And even encrypt them...
| |
| 15:01 | <vagrantc> right
| |
| 15:02 | <alkisg> E.g. when the client arrives at the login manager, it can ask the server for the whole user list, and it can put it in passwd... authentication problem solved :P
| |
| 15:02 | and then we can use something like LDM_PASSWORD_HASH for the shadow entry, after login
| |
| 15:02 | <vagrantc> alkisg: so basically we'll want to do a review of what's in init-ltsp.d and ldm/rc.d and decide what needs to be re-used, dropped or re-implemented
| |
| 15:03 | <alkisg> OK I'm just joking, but it could help while moving to lightdm, and before a real solution is found...
| |
| 15:03 | Right
| |
| 15:03 | I think we should start with a wiki page that mentions the directives and what they're supposed to do
| |
| 15:04 | * vagrantc wonders about authentication credentials for wiki.ltsp.org | |
| 15:04 | <vagrantc> alkisg: admittedly, my head has been in ansible so much the past few weeks, i can't help but thinking of re-implementing LTSP in ansible.
| |
| 15:04 | <alkisg> I do have an account there, I think you have one too
| |
| 15:04 | <vagrantc> i have one, i just don't remember if i know how to log in
| |
| 15:04 | <alkisg> vagrantc: can you give me an example of ansible syntax?
| |
| 15:05 | It's quite possible that we can use the same syntax in our "scripts"...
| |
| 15:05 | <vagrantc> https://docs.ansible.com/ansible/ini_file_module.html
| |
| 15:05 | it's mostly a lot of yaml entries
| |
| 15:06 | it uses all sorts of templating substitutions
| |
| 15:07 | <alkisg> It seems fine to me
| |
| 15:07 | <vagrantc> {{ variable }} {{ dictionary.foo.value }}
| |
| 15:07 | <alkisg> Rewriting init-ltsp.d in ansible should only take an afternoon
| |
| 15:07 | And then rewritting it to "other-framework" another afternoon
| |
| 15:08 | I think it's one of the smallest tasks that we'll have to do...
| |
| 15:08 | vagrantc: is there any way to do conditionals, like, "if lightdm version is > xxx then do this, otherwise do that"?
| |
| 15:09 | conditionals based on the output of some command
| |
| 15:09 | vmlintu_ has joined IRC (vmlintu_!~vmlintu@dsl-jnsbrasgw2-58c07e-86.dhcp.inet.fi) | |
| 15:14 | <vagrantc> alkisg: yes, there are conditionals
| |
| 15:15 | alkisg: there's "when" conditionals that can respond to values in variables, and you can set variables in earlier stanzas
| |
| 15:16 | or from other data sources
| |
| 15:17 | for a simple example, you'd have a stanza that sets the variable, a stanza that responds when variable == x, and a stanza that responds when variable == y ... and you can fire off additional stanzas when a particular line succeeds
| |
| 15:17 | vmlintu_ has left IRC (vmlintu_!~vmlintu@dsl-jnsbrasgw2-58c07e-86.dhcp.inet.fi, Ping timeout: 240 seconds) | |
| 15:18 | khildin has joined IRC (khildin!~khildin@ip-80-236-214-53.dsl.scarlet.be) | |
| 15:19 | <alkisg> Cool. I wonder if sysadmins find it simpler than e.g. ...python code that uses a library
| |
| 15:20 | <vagrantc> variables are defined like {{ foo }} and it supports lists and dicts.
| |
| 15:21 | it's certainly easier to read that shell code... :)
| |
| 15:22 | - name: add users to src group
| |
| 15:22 | user: name={{ item }} append=yes groups=src
| |
| 15:22 | with_items:
| |
| 15:22 | - vagrant
| |
| 15:22 | - alkisg
| |
| 15:22 | a lot of that sort of code.
| |
| 15:25 | <alkisg> Well, it does save us from reimplementing and documenting a lot of stuff, so /me is fine with it
| |
| 15:25 | * alkisg waves | |
| 15:25 | alkisg is now known as work_alkisg | |
| 15:26 | <vagrantc> yeah, not sure if it's a good fit or not, but it would be easy to do.
| |
| 15:27 | if written correctly, it's also idempotent, so you can re-run it multiple times
| |
| 15:41 | khildin has left IRC (khildin!~khildin@ip-80-236-214-53.dsl.scarlet.be, Ping timeout: 246 seconds) | |
| 15:51 | vervelak has joined IRC (vervelak!~vervelak@139.91.248.3) | |
| 16:32 | Joito has joined IRC (Joito!3f87ff77@gateway/web/freenode/ip.63.135.255.119) | |
| 16:32 | <Joito> hello Im new
| |
| 16:34 | I made a computer lab in my school, and setting up edubuntu with ltps was very easy. But i wish to install LTSP in Xubuntu. Ive been trying for weeks and no luck.
| |
| 16:34 | does ltsp works only in 64 bit pc?
| |
| 16:40 | <vagrantc> no, it works on any architecture
| |
| 16:41 | !ltsp-pnp
| |
| 16:41 | <ltsp> ltsp-pnp: ltsp-pnp is an alternative (upstream) method to maintain LTSP installations for thin and fat clients that doesn't involve chroots: https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
| |
| 16:41 | khildin has joined IRC (khildin!~khildin@ip-80-236-214-53.dsl.scarlet.be) | |
| 16:41 | <vagrantc> Joito: check that out ^^
| |
| 16:41 | it's one of the easiest methods to do ltsp.
| |
| 16:42 | <Joito> pnp = plug and play?
| |
| 16:43 | <vagrantc> yeah, that's the idea
| |
| 16:43 | i fin the most important part of it is the chrootless image creation, but the whole "ltsp-pnp" idea also involves the dnsmasq proxydhcp configuration
| |
| 16:44 | <Joito> ok thanks a lot i will try that now
| |
| 16:56 | Joito has left IRC (Joito!3f87ff77@gateway/web/freenode/ip.63.135.255.119, Ping timeout: 246 seconds) | |
| 17:21 | Joito has joined IRC (Joito!3f87ff77@gateway/web/freenode/ip.63.135.255.119) | |
| 17:31 | khildin has left IRC (khildin!~khildin@ip-80-236-214-53.dsl.scarlet.be, Ping timeout: 244 seconds) | |
| 17:37 | gbaman has joined IRC (gbaman!~gbaman@host31-53-72-7.range31-53.btcentralplus.com) | |
| 17:42 | khildin has joined IRC (khildin!~khildin@ip-80-236-214-53.dsl.scarlet.be) | |
| 17:55 | gbaman has left IRC (gbaman!~gbaman@host31-53-72-7.range31-53.btcentralplus.com, Remote host closed the connection) | |
| 17:58 | Joito has left IRC (Joito!3f87ff77@gateway/web/freenode/ip.63.135.255.119, Ping timeout: 246 seconds) | |
| 18:52 | khildin has left IRC (khildin!~khildin@ip-80-236-214-53.dsl.scarlet.be, Ping timeout: 246 seconds) | |
| 20:10 | AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-vgpybdotbmhiawqg) | |
| 20:48 | ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat) | |
| 20:49 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 20:50 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 21:47 | AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-vgpybdotbmhiawqg, ) | |
| 21:50 | gbaman has joined IRC (gbaman!~gbaman@host109-155-155-132.range109-155.btcentralplus.com) | |
| 22:04 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 23:04 | Phantomas has left IRC (Phantomas!~phantomas@ubuntu/member/phantomas, Quit: Leaving.) | |
| 23:21 | gbaman has left IRC (gbaman!~gbaman@host109-155-155-132.range109-155.btcentralplus.com, Remote host closed the connection) | |
| 23:30 | gbaman has joined IRC (gbaman!~gbaman@host109-155-155-132.range109-155.btcentralplus.com) | |
| 23:36 | gbaman has left IRC (gbaman!~gbaman@host109-155-155-132.range109-155.btcentralplus.com, Remote host closed the connection) | |