01:00 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 258 seconds) | |
01:44 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
02:24 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 240 seconds) | |
02:24 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
03:02 | Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 244 seconds) | |
03:07 | Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack) | |
03:56 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
05:26 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
05:55 | mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk) | |
07:42 | gvy has joined IRC (gvy!~mike@altlinux/developer/mike) | |
08:51 | kjackal has joined IRC (kjackal!~quassel@2a02:582:ccb:6a00:b420:9b4:2551:7b0a) | |
08:55 | Statler has joined IRC (Statler!~Georg@p5DD6E94B.dip0.t-ipconnect.de) | |
09:32 | gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: Leaving) | |
09:49 | kjackal has left IRC (kjackal!~quassel@2a02:582:ccb:6a00:b420:9b4:2551:7b0a, Remote host closed the connection) | |
09:50 | kjackal has joined IRC (kjackal!~quassel@2a02:582:ccb:6a00:54bd:509b:9561:e2d1) | |
11:04 | GodFather has joined IRC (GodFather!~rcc@96.92.43.9) | |
11:06 | GodFather has left IRC (GodFather!~rcc@96.92.43.9, Read error: Connection reset by peer) | |
11:09 | GodFather has joined IRC (GodFather!~rcc@96.92.43.9) | |
12:34 | Statler has left IRC (Statler!~Georg@p5DD6E94B.dip0.t-ipconnect.de, Quit: Leaving) | |
12:34 | Statler has joined IRC (Statler!~Georg@p5DD6E94B.dip0.t-ipconnect.de) | |
12:38 | Softeisbieger has joined IRC (Softeisbieger!~Softeisbi@ip-62-143-13-166.hsi01.unitymediagroup.de) | |
12:45 | GodFather has left IRC (GodFather!~rcc@96.92.43.9, Quit: Ex-Chat) | |
12:45 | GodFather has joined IRC (GodFather!~rcc@96.92.43.9) | |
13:04 | GodFather has left IRC (GodFather!~rcc@96.92.43.9, Ping timeout: 240 seconds) | |
13:21 | GodFather has joined IRC (GodFather!~rcc@75-145-237-204-Michigan.hfc.comcastbusiness.net) | |
13:49 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 260 seconds) | |
13:55 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
13:59 | GodFather has left IRC (GodFather!~rcc@75-145-237-204-Michigan.hfc.comcastbusiness.net, Ping timeout: 276 seconds) | |
14:01 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
14:05 | GodFather has joined IRC (GodFather!~rcc@75-145-237-204-Michigan.hfc.comcastbusiness.net) | |
14:28 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
14:45 | mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving) | |
15:01 | <bennabiy> alkisg: The issue has been patched upstream and will be released with python-xlib-0.17
| |
15:01 | no hacks needed
| |
15:09 | <vagrantc> yay!
| |
15:43 | Softeisbieger has left IRC (Softeisbieger!~Softeisbi@ip-62-143-13-166.hsi01.unitymediagroup.de, Ping timeout: 276 seconds) | |
16:33 | GodFather has left IRC (GodFather!~rcc@75-145-237-204-Michigan.hfc.comcastbusiness.net, Ping timeout: 276 seconds) | |
16:35 | <bennabiy> vagrantc: that is what I said!@
| |
16:36 | vagrantc: I am about to go to lunch, but thought I would say hi :)
| |
16:36 | progress towards ltsp 6?
| |
16:38 | vagrantc_ has joined IRC (vagrantc_!~vagrant@216-161-92-224.ptld.qwest.net) | |
16:38 | vagrantc_ has joined IRC (vagrantc_!~vagrant@unaffiliated/vagrantc) | |
16:40 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 244 seconds) | |
16:40 | vagrantc_ is now known as vagrantc | |
16:41 | <bennabiy> identity crisis?
| |
16:42 | * vagrantc let battery drain to 0% | |
16:44 | <bennabiy> heh
| |
17:41 | Statler has left IRC (Statler!~Georg@p5DD6E94B.dip0.t-ipconnect.de, Remote host closed the connection) | |
17:44 | Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 244 seconds) | |
17:48 | Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack) | |
18:50 | TatankaT_ has joined IRC (TatankaT_!~tim@193.190.253.114) | |
18:50 | TatankaT has left IRC (TatankaT!~tim@193.190.253.114, *.net *.split) | |
18:50 | gehidore has left IRC (gehidore!~username@unaffiliated/man, *.net *.split) | |
18:50 | gehidore_ has joined IRC (gehidore_!~username@unaffiliated/man) | |
18:51 | <alkisg> (07:36:27 μμ) bennabiy: progress towards ltsp 6? ==> nah, I don't think this will ever get implemented without funding :)
| |
18:52 | <bennabiy> alkisg: is there a todo / roadmap posted somewhere?
| |
18:53 | <alkisg> We do have a somewhat clear roadmap but we haven't written it down in the wiki
| |
18:54 | There are only some old notes in the Dev namespace, e.g.: wiki.ltsp.org/wiki/Dev:Ltspd
| |
18:55 | <bennabiy> Now that I am more in a place to do some dev work, I would like to see it, to see if anything I could do to help
| |
18:55 | gehidore_ is now known as gehidore | |
18:55 | <bennabiy> *see if there is anything I could do
| |
18:56 | * vagrantc wonders if wiki.ltsp.org is down | |
18:58 | <vagrantc> bennabiy: the kill off LDM thread basically amounts to using libpam-sshauth or libpam-python and sbalneav's python scripts with libnss-extrafiles and a bunch of hooks to use any display manager
| |
18:58 | <bennabiy> vagrantc: have you all documented recent work more than just IRC conversations?
| |
18:58 | <vagrantc> possibly getting lightdm-webkit*-greeter to default to lightdm with a greeter
| |
18:59 | sbalneav: did you ever commit your libpam-python scripts?
| |
18:59 | bennabiy: https://code.launchpad.net/~ltsp-upstream/+git
| |
19:00 | bennabiy: although libpam-external and libnss-external turned out to be dead ends ...
| |
19:00 | * alkisg restarted apache @ ltsp.org... | |
19:00 | <vagrantc> bennabiy: libpam-sshauth is already in Debian/Ubuntu ... though libpam-python *might* be a better option.
| |
19:01 | <bennabiy> and your thoughts on it are?
| |
19:01 | what would be it's benefit over libpam-sshauth
| |
19:01 | ?
| |
19:01 | <vagrantc> https://code.launchpad.net/~sbalneav/ltsp/lightdm-webkit-greeter or it's kissing cousin, webkit2-greeter (or webkit-greeter2?)
| |
19:02 | bennabiy: i think it'll be more maintainable and debuggable written in python than in C.
| |
19:03 | hopefully not a lot of maintenance, either way ... but we did just encounter a severe security issue in libpam-sshauth
| |
19:03 | <alkisg> In the first case, we'll only need a .c module, while in the second, both a .c module and a python module, right?
| |
19:04 | <vagrantc> except someone else maintains the .c bits.
| |
19:05 | * bennabiy likes debugging c better than python... | |
19:05 | <bennabiy> but I am willing to change my ways
| |
19:05 | I just had to debug python-xlib ... bleh
| |
19:06 | but I guess there probably are *more* people who would be willing to debug python code and contribute compared to C
| |
19:07 | <vagrantc> that's the hope ...
| |
19:07 | * vagrantc shrugs | |
19:07 | <alkisg> vagrantc: someone else meaning sbalneav, right?
| |
19:07 | <vagrantc> alkisg: no
| |
19:07 | <bennabiy> libpam ?
| |
19:07 | <alkisg> Won't we need the pam wrapper that allows python modules to be executed?
| |
19:07 | ...which is developed by sbalneav?
| |
19:07 | <vagrantc> libpam-python is in debian
| |
19:07 | not developed or maintained by sbalneav
| |
19:08 | <alkisg> ...hmm, I do think sbalneav was developing a module in .c in order to be able to call the pam one
| |
19:08 | <vagrantc> yes, and last i heard, abandoned it
| |
19:08 | especially when finding libpam-python
| |
19:08 | <alkisg> And I think in the end he wasn't able to make the python nss module work correctly at all...
| |
19:09 | <vagrantc> right ... so libnss-extrafiles + libpam-python + pyton-script(s)
| |
19:09 | or libnss-extrafiles + libpam-sshauth
| |
19:11 | https://github.com/Antergos/lightdm-webkit2-greeter was the other variant
| |
19:12 | <alkisg> vagrantc: so you're saying that we won't need any pam related .c code in ltsp? Nothing of what sbalneav developed so far?
| |
19:12 | <vagrantc> alkisg: possibly
| |
19:12 | sbalneav: any updates? :)
| |
19:12 | alkisg: if libpam-python doesn't turn out, we'd need to use libpam-sshauth
| |
19:13 | <alkisg> Got it
| |
19:13 | Sounds good
| |
19:13 | Then it may be possible to have ltsp 6 developed in python only... :D
| |
19:14 | <vagrantc> switch ltsp-build-client to ansible ... and systemd units for everything else ... we're done!
| |
19:14 | * vagrantc finds systemd a very mixed blessing | |
19:14 | <alkisg> Drop ltsp-build-client, and only send an initrd script for init-ltsp.d :)
| |
19:15 | <vagrantc> we'll still probably have a bunch of shell
| |
19:15 | although could probably replace all that with ansible, too :)
| |
19:15 | <alkisg> ip | sed | grep | awk? Those can easily be replaced with a python lib
| |
19:15 | I don't know where ansible can help
| |
19:15 | <maldridge> depends on how much you embrace systemd, I imagine you could do it all with some ansible, some python glue, and then just hooking into systemd for the rest of it
| |
19:15 | <vagrantc> well, ansible already implemented some version-compatibility breakages, so i'm not hyper-keen on it at the moment
| |
19:16 | <alkisg> I think we only need a small lib for file manipulation
| |
19:16 | <vagrantc> yet-another-configuration-management-system
| |
19:16 | <alkisg> A small part of this is available in ansible, but I don't think it's worth it to have ansible just for this
| |
19:17 | robb_nl has joined IRC (robb_nl!~robb_nl@ip-80-236-222-86.dsl.scarlet.be) | |
19:18 | <maldridge> I think the only thing you'd gain from ansible would be being able to setup all the network services and the pam files and then setup the images in a dynamic way after fingerprinting the host OS
| |
19:18 | there's a lot to be said for single command deployment
| |
19:18 | <alkisg> I don't understand what that meant
| |
19:19 | "able to setup all the network services and the pam files and then setup the images in a dynamic way after fingerprinting the host OS"
| |
19:19 | LTSP works with a single image and dynamic config on boot, while ansible with different images
| |
19:20 | <maldridge> alkisg: you could set it up so that ansible would setup dnsmasq and the optional routing for a host as well as building the image
| |
19:20 | <alkisg> maldridge: where would ansible help in configuring dnsmasq?
| |
19:20 | <vagrantc> alkisg: you could run ansible at boot
| |
19:20 | <alkisg> All the code in ltsp-config dnsmasq would need to be there, ansible doesn't provide it
| |
19:20 | <maldridge> ...
| |
19:20 | <alkisg> And it gets created in a separate file, so no config file editing
| |
19:21 | I really don't understand which part would ansible replace there
| |
19:21 | <vagrantc> it could install a template and do more intelligent replaces and loops and such
| |
19:21 | e.g. for all the various networks
| |
19:21 | <maldridge> it could replace all of ltsp-config
| |
19:21 | <vagrantc> probably, yes.
| |
19:22 | <maldridge> then there is no shell to be maintained in that component
| |
19:22 | <alkisg> maldridge: I think you mean "we could re-write all of ltsp-config with ansible modules"
| |
19:22 | <vagrantc> there are some conditionals which get a little ugly in ansible
| |
19:22 | <alkisg> *as ansible modules
| |
19:22 | <maldridge> no, I mean you could do basic logic
| |
19:22 | if you're writing modules you're using ansible wrong
| |
19:22 | <alkisg> Can you have a look at ltsp-config dnsmasq?
| |
19:22 | Because the problem is how to get the network mask etc
| |
19:22 | * vagrantc suspects alkisg means modules in a less-specific sense than ansible-specific meaning of modules | |
19:23 | <maldridge> sure, can you point me to a link? I'm not on debian box or anything with ltsp at the moment
| |
19:23 | <vagrantc> alkisg: that's really easy in ansible
| |
19:23 | <alkisg> I mean that ansible allows you to edit files
| |
19:23 | It doesn't provide you with what to put there
| |
19:23 | You still need to write code for what to put in those files
| |
19:23 | <vagrantc> alkisg: you can write a template, parse some code for the networking information on the host, etc.
| |
19:24 | alkisg: instead of grepping/sedding/awking for networking information, ansible provides it as parseable variables structures
| |
19:24 | <alkisg> vagrantc: I think that what we need won't be available in stock ansible
| |
19:24 | <maldridge> yeah, your default upstream routable address is {{ ansible_default_ipv4.address }}
| |
19:24 | <vagrantc> alkisg: how experienced are you with ansible?
| |
19:24 | <alkisg> And that we'll need to do the same things in plain python or custom ansible modules instead of shell
| |
19:25 | In which case, I'd prefer to do it without ansible
| |
19:25 | vagrantc: only what you showed me, nothing more
| |
19:25 | <maldridge> one moment while I go find the 'flips table' meme
| |
19:25 | <vagrantc> alkisg: i didn't show you much
| |
19:26 | alkisg: so i'm not sure what you're basing your assertions on
| |
19:26 | <alkisg> vagrantc: can you write ltsp-config dnsmasq in ansible, as a test?
| |
19:26 | <vagrantc> alkisg: i could try
| |
19:26 | i am, admittedly, a little concerned with typing too close to one configuration management system, though ... there are so many
| |
19:26 | s,typing,tying,
| |
19:26 | <alkisg> There was one python lib for config file editing
| |
19:27 | <vagrantc> i'm still a novice with ansible, at any rate
| |
19:27 | <alkisg> I wouldn't mind relying on that one
| |
19:27 | But I think ansible is about maintaining many systems, which in ltsp isn't what we want
| |
19:27 | <maldridge> RH bought it, so at least you know it would work well with systemd
| |
19:29 | <alkisg> http://augeas.net/
| |
19:30 | * vagrantc vaguely recalls getting burned by augeas many years ago... | |
19:30 | <vagrantc> but many years, so who knows no
| |
19:30 | now
| |
19:31 | <maldridge> ionno, I tend to not like blazing trails with system level technologies
| |
19:31 | <alkisg> If ansible has 80% of what ltsp needs, and we only need a few custom ansible modules, I would consider it
| |
19:31 | But I don't think that's the case... let's see
| |
19:32 | <maldridge> alkisg: I found the function that configures dnsmas btw, I don't see what it does beyond copying in a file
| |
19:32 | am I missing something?
| |
19:32 | <alkisg> maldridge: that, and proxy_subnets() {
| |
19:32 | <maldridge> I'll go look at that
| |
19:32 | <alkisg> Which gets the routes except for the local network ones
| |
19:32 | I don't think ansible will have those routes, we'll still need code to isolate the ones we want
| |
19:33 | even if it has all the system routes, it won't have the ones we want
| |
19:33 | So if, from all this code, ansible only replaces `ip route show`, it doesn't help much
| |
19:34 | We can get those from native python libs as well
| |
19:34 | <maldridge> I'm still not seeting what that does, does it literally just get the upstream route?
| |
19:35 | <alkisg> It creates a "dhcp-range=1.2.3.4,proxy" line for each route,
| |
19:35 | except for those ones: 127.0.0.1|169.254.0.0|192.168.67.0
| |
19:35 | and it puts them in the specific section of the config file
| |
19:36 | <maldridge> ok, I understand now
| |
19:44 | robb_nl has left IRC (robb_nl!~robb_nl@ip-80-236-222-86.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
19:46 | <bennabiy> so libnss-extrafiles + libpam-python + pyton-script(s) is what we are looking at being the most potential?
| |
19:46 | so no avoiding libnss-extrafiles?
| |
19:47 | Is it possible to develop ltsp 6 as a second project, with a dedicated starting codebase?
| |
19:50 | per pam-python docs... "Writing PAM modules from Python incurs a large performance penalty and requires Python to be installed, so it is not the best option for writing modules that will be used widely."
| |
19:52 | <alkisg> ltsp 6 will require python in any case, so both points aren't very significant
| |
19:52 | since python will already be installed *and* loaded
| |
19:52 | <bennabiy> true
| |
19:52 | <vagrantc> and the pam queries aren't going to be frequent ... presumably
| |
19:52 | <bennabiy> python 3 or 2.7?
| |
19:53 | <alkisg> I think initially a proof of concept should be done, that all thoose nss/pam scripts work fine
| |
19:54 | Not much code up to that point
| |
19:54 | Then issues like "how will we implement the xsessions for ldm" should be addressed
| |
19:54 | Coding can start later
| |
19:54 | *for lightdm
| |
19:56 | <bennabiy> but targeting python 2.7 or 3?
| |
19:56 | it makes a difference
| |
19:56 | * vagrantc struggles a bit with jinja templating | |
19:56 | <bennabiy> trying to do the ansible dnsmasq
| |
19:56 | ?
| |
19:56 | <vagrantc> definitely python3 ... python 2.x is deprecated in a few years
| |
19:57 | no sense starting something new with python2
| |
19:57 | bennabiy: yeah
| |
19:57 | <bennabiy> vagrantc: can you paste up what you did so far?
| |
19:59 | <vagrantc> bennabiy: https://paste.debian.net/787499
| |
19:59 | bennabiy: need to get the value out of the variable, and then need to add some comparisons
| |
20:01 | <bennabiy> vagrantc: one minute
| |
20:01 | <maldridge> bennabiy: you can also do ansible_interfaces[interface].ipv4.network if you want a more pythonic syntax
| |
20:01 | sorry, not bennabiy, vagrantc
| |
20:03 | <alkisg> But how can you do "except for 127.0.0.1|169.254.0.0|192.168.67.0" ?
| |
20:03 | <vagrantc> alkisg: with conditionals
| |
20:04 | i need somethng like shell eval
| |
20:06 | alkisg: i'm pretty sure that's the easy part
| |
20:07 | <maldridge> vagrantc: what do you need eval for?
| |
20:09 | <alkisg> vagrantc: OK, there are other parts like e.g. HOSTNAME_EXTRA=$(echo "$IPV4ADDR.$IPV4NETMASK" | awk -F "." '{ print (($1%(256-$5)*256+$2%(256-$6))*256+$3%(256-$7))*256+$4%(256-$8) }'), hopefully ansible also allows for substrings and arithmetics
| |
20:09 | <maldridge> wtf does that monstrosity do
| |
20:11 | <alkisg> The end result is something like "ltsp123" or "ltsp123456", where the number is based on the subnet
| |
20:11 | <vagrantc> alkisg: let me get one thing working before piling it all on :P
| |
20:11 | <alkisg> For small subnets, it's 1 to 255, for larger ones, it detects it from the netmask
| |
20:11 | It essentially means "the n-th ip available on that given network"
| |
20:12 | <vagrantc> maldridge: basically, i'm trying to loop through the interfaces, and then get a value from ansible_{{ interface }}.ipv4.network ... but i'm not clueful about how to get the value out yet
| |
20:12 | <maldridge> alkisg: ah, I see
| |
20:13 | vagrantc: you can't embed jinja variables in other jinja variables, you need for format it like I showed above when I got the ping wrong
| |
20:14 | <alkisg> I think I would prefer the ltsp code to be plain python, with a library for what we need, e.g. the network interfaces. That library can use ansible if you want, or it can run `ip show | sed`, or it can use native python libraries to detect the interfaces... I don't care much about that library as long as it keeps the main code readable even from people that don't know ansible
| |
20:14 | <vagrantc> maldridge: i tried using what you were proposing, but that just showed the plain text
| |
20:14 | <maldridge> vagrantc: you wrapped it in {{ }} ?
| |
20:16 | <vagrantc> maldridge: dhcp-range={{ ansible_[interface].ipv4.network }},proxy
| |
20:16 | maldridge: i've tried other permutations as well ...
| |
20:17 | <maldridge> vagrantc: {{ ansible_interfaces[interface].ipv4.network }}
| |
20:17 | its a python dictionary
| |
20:19 | to be clear though, I've never tried indexing all the interfaces like that, I usually go at it from an addressing perspective since I have a lot of boxes where not all the interfaces are up
| |
20:21 | <vagrantc> maldridge: that spits out lots of errors
| |
20:22 | <maldridge> vagrantc: ah, I see what you're accessing now
| |
20:24 | <vagrantc> maldridge: i can get a list of interfaces, but i haven't figured out how to loop through the list of interfaces and get the networks corresponding to those interfaces
| |
20:24 | i could also get ansible_all_ipv4_addresses
| |
20:24 | but then i don't know what networks they're associated with
| |
20:25 | <maldridge> yeah, I think I'd probably index the main facts dictionary upon knowing the available interfaces
| |
20:25 | <vagrantc> e.g. depending on subnet...
| |
20:25 | <maldridge> but it seems there's low buy in to using ansible and I have my own network playbooks I need to debug today
| |
20:26 | <vagrantc> heh
| |
20:27 | * vagrantc suspects it will be obvious at some point | |
20:31 | <maldridge> perhaps, in the mean time I'll continue with my own "version" of ltsp for my preferred distro
| |
20:35 | <bennabiy> I tend to think that unless we had something rock solid, or possibly changed the way it was used, straight python code might be easier to begin with
| |
20:37 | * vagrantc shrugs | |
20:45 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
20:47 | <vagrantc> bennabiy: at any rate ... the pam support idea is basically described here: http://wiki.ltsp.org/wiki/Dev:LTSPPamNotes
| |
20:47 | not sure if it's working this week
| |
20:50 | it is frustrating, because the information is clearly there...
| |
20:51 | (regarding the ansible dnsmasq stuff)
| |
20:55 | <bennabiy> vagrantc: I agree
| |
20:56 | vagrantc: I might be able to work with it at well some time this week... we are busy building another deli, but I do get moments here and there
| |
20:57 | LTSP communications in here are funny... One speaks greek, the other speaks geek and without them both, we are all up a creek!
| |
21:01 | * bennabiy hears the crickets... | |
21:01 | <bennabiy> I meant that in the most respectful way possible
| |
21:35 | Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 264 seconds) | |
21:46 | Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack) | |
22:12 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |
22:28 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |