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


Channel log from 8 August 2016   (all times are UTC)

01:00vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 258 seconds)
01:44vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
02:24vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 240 seconds)
02:24vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
03:02Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 244 seconds)
03:07Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack)
03:56vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
05:26ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
05:55mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
07:42gvy has joined IRC (gvy!~mike@altlinux/developer/mike)
08:51kjackal has joined IRC (kjackal!~quassel@2a02:582:ccb:6a00:b420:9b4:2551:7b0a)
08:55Statler has joined IRC (Statler!~Georg@p5DD6E94B.dip0.t-ipconnect.de)
09:32gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: Leaving)
09:49kjackal has left IRC (kjackal!~quassel@2a02:582:ccb:6a00:b420:9b4:2551:7b0a, Remote host closed the connection)
09:50kjackal has joined IRC (kjackal!~quassel@2a02:582:ccb:6a00:54bd:509b:9561:e2d1)
11:04GodFather has joined IRC (GodFather!~rcc@96.92.43.9)
11:06GodFather has left IRC (GodFather!~rcc@96.92.43.9, Read error: Connection reset by peer)
11:09GodFather has joined IRC (GodFather!~rcc@96.92.43.9)
12:34Statler has left IRC (Statler!~Georg@p5DD6E94B.dip0.t-ipconnect.de, Quit: Leaving)
12:34Statler has joined IRC (Statler!~Georg@p5DD6E94B.dip0.t-ipconnect.de)
12:38Softeisbieger has joined IRC (Softeisbieger!~Softeisbi@ip-62-143-13-166.hsi01.unitymediagroup.de)
12:45GodFather has left IRC (GodFather!~rcc@96.92.43.9, Quit: Ex-Chat)
12:45GodFather has joined IRC (GodFather!~rcc@96.92.43.9)
13:04GodFather has left IRC (GodFather!~rcc@96.92.43.9, Ping timeout: 240 seconds)
13:21GodFather has joined IRC (GodFather!~rcc@75-145-237-204-Michigan.hfc.comcastbusiness.net)
13:49cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 260 seconds)
13:55ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
13:59GodFather has left IRC (GodFather!~rcc@75-145-237-204-Michigan.hfc.comcastbusiness.net, Ping timeout: 276 seconds)
14:01cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
14:05GodFather has joined IRC (GodFather!~rcc@75-145-237-204-Michigan.hfc.comcastbusiness.net)
14:28vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
14:45mikkel 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:43Softeisbieger has left IRC (Softeisbieger!~Softeisbi@ip-62-143-13-166.hsi01.unitymediagroup.de, Ping timeout: 276 seconds)
16:33GodFather 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:38vagrantc_ has joined IRC (vagrantc_!~vagrant@216-161-92-224.ptld.qwest.net)
16:38vagrantc_ has joined IRC (vagrantc_!~vagrant@unaffiliated/vagrantc)
16:40vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 244 seconds)
16:40vagrantc_ is now known as vagrantc
16:41
<bennabiy>
identity crisis?
16:42* vagrantc let battery drain to 0%
16:44
<bennabiy>
heh
17:41Statler has left IRC (Statler!~Georg@p5DD6E94B.dip0.t-ipconnect.de, Remote host closed the connection)
17:44Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 244 seconds)
17:48Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack)
18:50TatankaT_ has joined IRC (TatankaT_!~tim@193.190.253.114)
18:50TatankaT has left IRC (TatankaT!~tim@193.190.253.114, *.net *.split)
18:50gehidore has left IRC (gehidore!~username@unaffiliated/man, *.net *.split)
18:50gehidore_ 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:55gehidore_ 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:17robb_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:44robb_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:45ricotz 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:35Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 264 seconds)
21:46Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack)
22:12ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)
22:28vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)