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


Channel log from 11 July 2015   (all times are UTC)

00:23gbaman has joined IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com)
00:27gbaman has left IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com, Ping timeout: 246 seconds)
00:33Guest56386 has left IRC (Guest56386!73465b95@gateway/web/freenode/ip.115.70.91.149, Ping timeout: 246 seconds)
00:54gbaman has joined IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com)
02:07dberkholz has left IRC (dberkholz!~dberkholz@gentoo/developer/dberkholz, Ping timeout: 276 seconds)
02:07dberkholz has joined IRC (dberkholz!~dberkholz@gentoo/developer/dberkholz)
02:12cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 256 seconds)
02:14cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
02:58gdi2k has left IRC (gdi2k!~gdi2k@203.177.248.238, Ping timeout: 244 seconds)
03:26Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 256 seconds)
03:47vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 240 seconds)
04:05vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
04:41gbaman has left IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com, Ping timeout: 255 seconds)
05:23gdi2k has joined IRC (gdi2k!~gdi2k@203.177.251.132)
05:29gdi2k has left IRC (gdi2k!~gdi2k@203.177.251.132, Ping timeout: 255 seconds)
05:38gbaman has joined IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com)
05:53gbaman has left IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com, Ping timeout: 264 seconds)
05:58gdi2k has joined IRC (gdi2k!~gdi2k@203.177.251.132)
06:05gdi2k has left IRC (gdi2k!~gdi2k@203.177.251.132, Ping timeout: 250 seconds)
07:09work_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:05gbaman 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:09gbaman 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:39dberkholz 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:45vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
08:46
<maldridge>
yeah, standing labs really should be fat imho
09:35gbaman has joined IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com)
09:43alkisg has left IRC (alkisg!~alkisg@srv1-dide.ioa.sch.gr, Ping timeout: 252 seconds)
09:58work_alkisg has joined IRC (work_alkisg!~alkisg@81.186.145.154)
10:14work_alkisg is now known as alkisg
10:41gdi2k has joined IRC (gdi2k!~gdi2k@203.177.248.238)
10:47telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
10:48telex has joined IRC (telex!teletype@freeshell.de)
10:54gdi2k has left IRC (gdi2k!~gdi2k@203.177.248.238, Ping timeout: 264 seconds)
10:59alkisg is now known as work_alkisg
11:07gdi2k has joined IRC (gdi2k!~gdi2k@203.177.248.238)
11:24gdi2k has left IRC (gdi2k!~gdi2k@203.177.248.238, Ping timeout: 244 seconds)
11:28gbaman has left IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com, Remote host closed the connection)
11:30adrianorg has left IRC (adrianorg!~adrianorg@201.22.229.47.dynamic.dialup.gvt.net.br, Ping timeout: 276 seconds)
11:31adrianorg has joined IRC (adrianorg!~adrianorg@187.115.107.192)
12:28gbaman has joined IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com)
12:37gbaman has left IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com, Ping timeout: 246 seconds)
12:58AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-xkawlbscnkdctaiw)
13:49gdi2k 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:55gdi2k has left IRC (gdi2k!~gdi2k@203.177.12.122, Ping timeout: 246 seconds)
14:28uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek)
14:31uXus has joined IRC (uXus!~uXus@217.77.222.72)
15:08work_alkisg is now known as alkisg
15:08* alkisg thinks ltsp-cluster isn't really maintained anymore...
15:27Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
15:34gbaman has joined IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com)
15:39gbaman has left IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com, Ping timeout: 250 seconds)
16:11ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)
16:32book` has left IRC (book`!~book`@105.ip-167-114-152.net, Ping timeout: 248 seconds)
16:35book` has joined IRC (book`!~book`@105.ip-167-114-152.net)
17:21gbaman has joined IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com)
17:38sutula has left IRC (sutula!~sutula@207-118-178-64.dyn.centurytel.net, Quit: ZNC - http://znc.sourceforge.net)
17:41sutula has joined IRC (sutula!~sutula@207-118-178-64.dyn.centurytel.net)
17:47sutula has left IRC (sutula!~sutula@207-118-178-64.dyn.centurytel.net, Ping timeout: 256 seconds)
17:47sutula_ has joined IRC (sutula_!~sutula@207-118-178-64.dyn.centurytel.net)
17:47sutula_ is now known as sutula
20:02vmlintu 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:07telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
20:08telex 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:17ricotz 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:20Phantomas1 has joined IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas)
20:20Phantomas 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:20Phantomas1 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:00vmlintu 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:10alkisg is now known as work_alkisg
21:18gbaman_ has joined IRC (gbaman_!~gbaman@host81-139-247-109.in-addr.btopenworld.com)
21:18gbaman has left IRC (gbaman!~gbaman@host81-139-247-109.in-addr.btopenworld.com, Read error: Connection reset by peer)
21:30Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 248 seconds)
21:35Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack)
21:43Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Remote host closed the connection)
21:44Freejack 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:02gbaman_ has left IRC (gbaman_!~gbaman@host81-139-247-109.in-addr.btopenworld.com, Remote host closed the connection)
23:27staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Read error: Connection reset by peer)
23:28staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)