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

Request log from specific day:

Channel log from 1 November 2015 (all times are UTC)

00:37	robbie has joined IRC (robbie!~rob@ec2-54-253-120-233.ap-southeast-2.compute.amazonaws.com)
01:14	robbie has left IRC (robbie!~rob@ec2-54-253-120-233.ap-southeast-2.compute.amazonaws.com, Quit: robbie)
03:00	andygraybeal has left IRC (andygraybeal!~andy@h52.205.189.173.dynamic.ip.windstream.net, Ping timeout: 240 seconds)
04:20	cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 260 seconds)
07:09	alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
07:14	<alkisg> Is anyone using LTSP in some non-deb based distro? If yes, what's your $CHROOT/etc/ltsp/update-kernels.conf like?
07:27	<maldridge> looked at it, was having a lot of trouble with getting my distro of choice to pxe boot
09:46	khildin has joined IRC (khildin!~khildin@ip-62-235-40-58.dial.scarlet.be)
10:04	khildin has left IRC (khildin!~khildin@ip-62-235-40-58.dial.scarlet.be, Remote host closed the connection)
10:40	ricotz has joined IRC (ricotz!~ricotz@p5B2AAD3A.dip0.t-ipconnect.de)
10:40	ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
10:42	yanu_ has left IRC (yanu_!~yanu@178-116-58-90.access.telenet.be, Remote host closed the connection)
10:42	yanu has left IRC (yanu!~yanu@178-116-58-90.access.telenet.be, Read error: Connection reset by peer)
11:17	alkisg is now known as work_alkisg
11:48	andygraybeal has joined IRC (andygraybeal!~andy@h52.205.189.173.dynamic.ip.windstream.net)
11:53	daniel has joined IRC (daniel!~dash@keewi.tootai.net)
11:53	daniel is now known as Guest32827
11:56	cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
11:59	cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Remote host closed the connection)
12:04	Guest32827 has left IRC (Guest32827!~dash@keewi.tootai.net, Ping timeout: 264 seconds)
12:08	Guest32827 has joined IRC (Guest32827!~dash@keewi.tootai.net)
12:18	Guest32827 has left IRC (Guest32827!~dash@keewi.tootai.net, Ping timeout: 250 seconds)
12:44	daniel has joined IRC (daniel!~dash@guava.tootai.net)
12:44	daniel is now known as Guest2237
12:59	Guest2237 has left IRC (Guest2237!~dash@guava.tootai.net, Ping timeout: 268 seconds)
13:20	daniel has joined IRC (daniel!~dash@guava.tootai.net)
13:20	daniel is now known as Guest42017
13:43	cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
15:01	work_alkisg is now known as alkisg
15:44	vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
15:44	<vagrantc> alkisg: curious about the LTSP_CLIENT_MAC change ...
15:45	<alkisg> Hi vagrantc
15:45	Let me check...
15:45	Ah, it didn't make it to the environment
15:45	So e.g. epoptes-client in user sessions was not running, if not installed in the chroot
15:45	* vagrantc was surprised to see alkisg move something from init-ltsp.d to ltsp_config.d ... :)
15:45	<alkisg> Hehe
15:45	I really don't like that config framework there
15:45	<vagrantc> which?
15:46	<alkisg> ltsp_config
15:46	We set things in init-ltsp.d, we also set some in ltsp_config,
15:46	<vagrantc> it's an incomplete transition
15:46	<alkisg> ...to ltspd? :D
15:47	<vagrantc> that would be a third method...
15:47	<alkisg> set_lts_var was supposed to make things faster, now it always writes to a file,
15:47	I don't know I really want to throw all of it and start over with ltspd and clearly defined phases where ltsp runs and gets the configuration
15:47	<vagrantc> alkisg: so, it used to work with LTSP_CLIENT_MAC from init-ltsp.d ... so i'm wondering what changed.
15:48	<alkisg> epoptes had a script that made it work
15:48	If one didn't install epoptes-client to the chroot, it didn't work
15:48	<vagrantc> alkisg: also, it's switched from using the detected network boot device to a hard-coded eth0 ... :(
15:48	<alkisg> Use case: "user X installes epoptes+epoptes-client in the LTSP server, but not in the chroot,
15:49	ouch that's a "typo"
15:49	...the user X is supposed to see the clients in epoptes UI after login, but he doesn't
15:49	...now he does see them. Sorry about eth0, I'll fix it.
15:50	<vagrantc> alkisg: not feasible to do properly from init-ltsp.d ? seems like a regression to move it into ltsp_config.d
15:50	<alkisg> No, because it needs to be saved in order to be used from LDM
15:50	<vagrantc> alkisg: ah, i see the use-case you're talking about now
15:51	<alkisg> LDM does not source /var/cache/ltsp/ltsp_config
15:51	* vagrantc could've sworn that init-ltsp.d variables stashed somewhere should be respected from ltsp_config
15:51	andygraybeal has left IRC (andygraybeal!~andy@h52.205.189.173.dynamic.ip.windstream.net, Quit: Ex-Chat)
15:51	<alkisg> I don't know why it doesn't source it, or what the exact difference of /var/cache/ltsp/ltsp_config vs /var/cache/ltsp/ltsp_config_env is...
15:51	Chaos :D
15:52	* alkisg wishes Gadi was still around though :D
15:52	<vagrantc> alkisg: it should source it in ltsp_config.d/00-ltspconfig-cache
15:53	which should be exported to LDM's environment
15:53	<alkisg> Try it, it doesn't.
15:53	<vagrantc> but the whole framework is kind of perplexingly complex.
15:53	* alkisg hopes the bug was not ubuntu-specific...
15:54	* vagrantc found the set_lts_var stuff to make things far more complicated than it used to be
15:54	<vagrantc> used to just have a few files with variable=value and source them ...
15:55	<alkisg> Now we'll directly send code to the clients and call it a day (like epoptes does) :P :D
15:55	FrankBlues has joined IRC (FrankBlues!~alex@c-67-171-127-41.hsd1.ut.comcast.net)
15:55	* vagrantc suspects the initramfs-tools might not be exporting DEVICE on ubuntu ...
15:55	<vagrantc> that's my hunch, at least
15:55	<alkisg> No, DEVICE was set
15:56	<vagrantc> hrm.
15:56	<alkisg> The MAC was there in /var/cache...
15:56	But LDM was not sourcing that file
15:56	vagrantc: here's something more interesting: http://paste.ubuntu.com/13065556/
15:57	I'll commit that after testing it a bit more
15:58	cyberorg: please also have a look at this ^ too, I'll push it to the main init-ltsp.d dir, not as debian specific
15:58	To be called 45-update-kernels
16:00	<vagrantc> alkisg: nice.
16:01	alkisg: if the device is specified and present, but fails to mount, there's no error handling...
16:01	<alkisg> vagrantc: what error handling? A message? We just continue booting...
16:02	I thought that the previous message "trying to update..." is enough, if we consider that it's not followed by a reboot...
16:02	<vagrantc> alkisg: continue booting while the kernel remains not updated?
16:02	<alkisg> Yes, it's like it is now. We cannot do anything better. Do we want to panic?
16:03	E.g. that can happen now if the tftp kernel does not exist in the chroot
16:04	(for whatever reason, e.g. error while running ltsp-update-image/kernels...)
16:05	<vagrantc> sure, it can happen now, but we don't have any kernel updating feature yet ... but once they set the configuration to say "update the kernels please" ... it seems bad to silently fail to update them ...
16:06	could pause the process with an error ...
16:07	alkisg: it also could boot an old kernel that still has the modules present and not update to the most current kernel ...
16:07	<alkisg> I'm not sure if we can easily pause the boot process with plymouth, systemd etc getting in the way
16:07	That's by design
16:07	Someone might want a few clients to boot with the older kernels because they don't work with the new ones
16:07	As long as the older kernels are not removed, we don't upgrade
16:08	* vagrantc would think updating to the current kernel would be a default, and hanging onto older kernels should require explicit configuration
16:09	<alkisg> That would require version checking
16:09	It's difficult to do it reliably in a cross-distro manner
16:09	It also minimizes the sd card writes :)
16:11	Eh, let me also give you yet another thing to think, and we can talk about all of them...
16:11	So, we cannot support proxydhcp with those local kernels (at least until we patch udhcpc/ipconfig to support proxydhcp)
16:12	<vagrantc> alkisg: so, as you've written it, this feature is only triggered when the booted kernel doesn't have corresponding modules, and $KERNEL_DEVICE exists?
16:12	<alkisg> Right
16:13	So if we're using NBD, and the server's 10809 port isn't open, I want to have `nc` in the initramfs, and do a loop for ip=1.2.3.x, where x=1..255, in the background, and stop in the first NBD server that I find
16:13	* vagrantc blinks
16:13	<alkisg> It's not a well designed solution that would use a broadcast etc, but it's good enough for many cases, and it will allow me to not put an IP in the pi's sd cards
16:14	nbdroot=1.2.3.4/opt/ltsp/armhf
16:14	I tested it and it works and it only takes 1 second
16:15	<vagrantc> alkisg: and it just assumes it's an NBD server if the port is open?
16:15	<alkisg> I'll also use it with win32-loader and (a) compex cards that ipxe doesn't support, or (b) uefi environments where ipxe can't be installed/started
16:15	Right, if it finds 10809 open, it will continue with running nbd-client etc
16:15	If nbd-client then fails, it will produce the usual message
16:15	<vagrantc> alkisg: if that port happens to be in use by something else, should it go back to port scanning and try the next available ip?
16:15	<alkisg> I'll also show some appropriate messages like "port 10809 in $SERVER isn't open, trying to autodetect, ah, found it at IP=xxx"
16:16	I tried with `nc -z`, which only opens the port without sending data
16:16	<vagrantc> e.g. if nbd-client fails to connect
16:16	<alkisg> That step will be in our udhcpc script
16:16	In init-premount, before the local-top/nbd-client script
16:17	I'll just set ROOTSERVER if it's not set
16:17	(I already set ROOTPATH to /opt/ltsp/$(dpkg --print-architecture) if it's not set)
16:17	<vagrantc> alkisg: can't you get udhcpc to try the proxydhcp port first?
16:18	<alkisg> I don't know of any dhcp clients that support proxydhcp
16:18	<vagrantc> or is the proxydhcp port not just DHCP protocol?
16:18	<alkisg> We only get the proxydhcp info with IPPAPPEND 3
16:18	* vagrantc vaguely thought it was simply running DHCP on another port
16:18	<alkisg> Nope
16:18	<vagrantc> hrm.
16:18	<alkisg> It's a separate part of the pxe protocol
16:18	Only NIC ROMs and iPXE support it, client-side
16:19	<vagrantc> well, actually, that is an option ... we could configure a DHCP server on an alternate port
16:19	and query on an alternate port
16:19	<alkisg> Well sure, we can also use a second IP, 192.168.67.1 on the ltsp server
16:19	And configure dnsmasq to reply only on pxe clients there
16:19	This solves all the issues, except for authoritative dhcp servers
16:19	<vagrantc> but then you need to hard-code networking
16:20	<alkisg> No, network-manager allows a second ip
16:20	eth0=dhcp AND 192.168.67.1
16:20	<vagrantc> but you've still hard-coded 192.168.67.*
16:20	<alkisg> Or static AND 192.168.67.1
16:20	Only for the initial pxe request
16:20	<vagrantc> and it would only break with networks that use 192.168.67.* for something else. :)
16:21	<alkisg> It doesn't have to be .67
16:21	<vagrantc> as opposed to an alternate DHCP port, which would only break with networks that query DHCP on an alternate port...
16:21	(which seems far less likely
16:21	<alkisg> Many dhcp clients refused/dropped patches for alternate dhcp ports
16:21	About 5 years ago...
16:22	Hmmm
16:22	<vagrantc> any ones we care about? :P
16:22	* alkisg checks udhcpc...
16:22	<alkisg> I think ipconfig...
16:23	https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/198356
16:23	<vagrantc> i mean, we're talking about workarounds on top of workarounds ... so
16:23	<alkisg> Comments #5 and #6
16:24	* alkisg tries ipconfig -p...
16:26	<alkisg> https://github.com/codehelp/klibc-aarch64/blob/master/usr/kinit/ipconfig/README.ipconfig
16:26	-p port Send bootp/dhcp broadcasts from PORT, to PORT - 1.
16:27	It might still be supported... but I'm not sure how we could use that server-side
16:29	dnsmasq supports --dhcp-alternate-port[=<server port>[,<client port>]]
16:30	* vagrantc nods
16:30	<alkisg> ...but that would probably disable proxydhcp and normal dhcp support
16:30	<vagrantc> you can run multiple dnsmasq instances
16:31	seems nominally cleaner than port scanning entire network ranges...
16:31	<alkisg> Just the 1-255 range, it takes 1 second
16:32	It covers most of the cases; the bigger ones can have a sysadmin and a real dhcp server :)
16:35	* alkisg tries to sum up the server-side changes needed...
16:35	<alkisg> So, 2 IPs on the server. Let's say 10.x.y.z and 192.168.67.1
16:35	A proxydhcp dnsmasq in 10.x.y.z
16:35	And a second, non-proxy dnsmasq in 192.168.67.1:1067
16:36	* vagrantc wonders about simply using a firewall-side port-forward for the oddball ports
16:36	<alkisg> The client would then get an ip lease in 192.168.67.x, with a next-server of 10.x.y.z
16:36	That next-server would be put there with an if-up.d script to allow for dynamic server IPs
16:37	And the client would ignore that ip lease and just set ROOTSERVER=10.x.y.z
16:37	(a backup/restore of /run/net-eth0.conf would be needed)
16:37	I don't know it seems very complicated to me...
16:38	How about using a specific IP? E.g. if 10.x.y.1 doesn't have the NBD port open, then just assume that ROOTSERVER=10.x.y.10 ?
16:38	...and we'll tell the affected users, "put your server in the .10 IP"
16:38	<vagrantc> alkisg: that sure does sound complicated to me.
16:39	alkisg: i think you could just port-forward 1067->67 and 1068->68 on the server's firewall to dnsmasq and be done with it.
16:39	<alkisg> But dnsmasq won't offer an IP at that range
16:39	<vagrantc> at what range?
16:40	<alkisg> At its proxydhcp range
16:40	<vagrantc> why not?
16:40	<alkisg> Let's go with an example
16:40	My router=10.161.254.1, my server=10.161.254.10
16:40	On dhcp requests, my router answers, and my server only sends a proxydhcp reply
16:41	So even if I forward 1067=>67, my server will still not answer
16:41	To have it answer, I would need a separate range, e.g. 192.168.67.x, with a second IP of 192.168.67.1
16:41	And some logic to answer only to the 1067 port, not to the 67 one
16:42	<vagrantc> that can be handled on the firewall...
16:42	<alkisg> But dnsmasq won't answer in the 10.161.254.x range
16:43	So it doesn't matter what the firewall will do
16:43	<vagrantc> alkisg: according to the manpage, --dhcp-alternate-port doesn't impact proxydhcp ports...
16:43	* alkisg isn't even sure that firewalls can redirect broadcasted ethernet messages
16:43	<alkisg> There's no proxydhcp request in ipconfig
16:43	<vagrantc> alkisg: so you could actually configure it to respond on the alternate ports with the 10.161.254.x range
16:43	<alkisg> And give what ip?
16:44	On the same range that the router does?
16:44	<vagrantc> sure
16:44	<alkisg> It will cause a chaos of IPs
16:44	It's conflicting dhcp servers
16:44	<vagrantc> dhcp servers seem to check for conflicting IPs these days... if you're lucky :)
16:44	<alkisg> It can give an ip of .20
16:45	And half an hour later, the server with a static ip of .20 be powered up
16:45	==> big problems :)
16:45	We can't have dnsmasq give IPs in the same range as the router
16:46	<vagrantc> so, a proxydhcp-aware dhcp client would solve this sanely?
16:46	<alkisg> Yup
16:46	Even a dummy one that only gets the server IP, not the whole packet
16:46	<vagrantc> that very well might be easier to implement than all these crazy workarounds
16:46	* alkisg implemented the nc workaround in 1 minute :)
16:46	<vagrantc> ok, eay was the wrong word...
16:47	easy
16:48	supporting proxydhcp would make it a lot more flexible that the nc workaround ... and a lot less special-casing.
16:48	<alkisg> Yes, but it would require a week for programming it and it would involve a lot of bug reports over the next years
16:48	<vagrantc> it would behave just like all the other network booted machines, just happens to get the kernel locally
16:48	<alkisg> Creating a dhcp client in .c isn't that easy
16:51	It would be easier to create a special dhcp server on the server, that sends some special replies on the 1067 port
16:52	Hmm that's not a bad idea actually...
16:53	So, new logic: "the client sets up networking as usual, with ipconfig/udhcpc. Then we have a special script that checks if ROOTSERVER is missing. If so, it does a second, "special" ipconfig -p 1067 request. Our "special" dhcp server then only fills the needed bits"
16:53	<vagrantc> that sounds better.
16:54	<alkisg> I'll see if Phantomas can help with this. In the meantime, I'll tell the rpi users to hardcode the server IP in cmdline.txt... :-/
16:54	<vagrantc> alkisg: actually, why stick with DHCP at that point
16:55	<alkisg> Because of its broadcasted nature
16:55	<vagrantc> alkisg: could just be a one-off LTSP thing
16:55	cuz we love those
16:55	<alkisg> Client-side, in the initramfs, we don't have many ip utilities
16:55	There's ipconfig, udhcpc and busybox wget
16:55	Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
16:55	<alkisg> Of those, only the first 2 allow broadcasting
16:55	Haha, Phantomas we were just talking about you :D
16:56	Check irclogs.ltsp.org, starting from bottom... :)
16:56	<Phantomas> I'm innocent!
16:56	It's a feature, not a bug
16:56	<alkisg> Prove it! Implement a small dhcp server in python! :P :D
16:57	<vagrantc> alkisg: i confirmed the LTSP_CLIENT_MAC missing on Debian jessie thin client
16:57	<alkisg> vagrantc: ...did you find out why?
16:57	Maybe there are other vars missing as well
16:57	<vagrantc> alkisg: no, but looking into it
16:58	<alkisg> thanks
17:03	<vagrantc> alkisg: i think LTSP_CLIENT_MAC isn't exported in /var/cache/ltsp/ltsp_config
17:04	* alkisg doesn't see any "exports" in that file...
17:04	<alkisg> Also, I call a `set -a` that automatically exports vars, somewhere...
17:04	*recall
17:04	<vagrantc> right ...
17:05	hrm.
17:05	<alkisg> That file has NBD_ROOT_HOST, NBD_ROOT_NAME, SERVER, and LTSP_CLIENT_MAC
17:06	SERVER is also defined in ltsp_client_env
17:06	NBD_ROOT_* too
17:06	<Phantomas> alkisg: So, a dhcp server in python. OK, as long as you are going to use it :P
17:06	<alkisg> Phantomas: not a full dhcp server
17:07	We want it to send a fake ip without managing ranges etc, the same ip to all the clients
17:07	The clients will be programmed to ignore that IP, and only use some of the other parts like e.g. next-server, rootpath etc
17:07	FrankBlues has left IRC (FrankBlues!~alex@c-67-171-127-41.hsd1.ut.comcast.net, Ping timeout: 240 seconds)
17:08	<alkisg> Phantomas: how long do you think that would take? We'll surely use it, but the use case is small; it's for clients that can't boot with "boot from lan" or ipxe
17:09	<Phantomas> Well, I can start working on it now. Shouldn't take more than 1-2 weeks, I guess
17:10	<vagrantc> rpi, maybe some boards that boot from u-boot ...
17:10	<Phantomas> twisted is pretty handful on this stuff
17:10	* alkisg was looking at https://github.com/flan/staticdhcpd
17:10	klausade has joined IRC (klausade!~klaus@cm-84.215.169.187.getinternet.no)
17:10	<Phantomas> helpful
17:11	<alkisg> Also some clients that ipxe doesn't support, like compex cards, or even uefi clients, which can't pxe boot with dnsmasq/ltsp currently
17:11	So, about 10 users worldwide :P :D
17:12	<Phantomas> Great, we'll become famous!!
17:12	:P
17:12	* alkisg would really prefer the 1 minute workaround instead of the 2 weeks of programming...
17:17	klausade has left IRC (klausade!~klaus@cm-84.215.169.187.getinternet.no, Quit: leaving)
17:18	klausade has joined IRC (klausade!~klaus@cm-84.215.169.187.getinternet.no)
17:25	<Phantomas> Well, if you conclude on the need for the not-really-a-dhcp (found it a name: nradhcp :P), you can tell me to start working on it.
17:26	<alkisg> Hahaha, nice one
17:27	Phantomas: I think we can merge that request with the ltspd one
17:27	I.e. ltspd can have an https front-end for client requests for settings,
17:28	and a "fake-dhcp" request for client requests for initramfs settings (where we might not know the server ip yet)
17:31	<Phantomas> sounds good
17:54	<vagrantc> python-pydhcplib is already in debian...
17:58	alkisg: i bet the "set -a" bit was scoped inside the function...
18:01	<alkisg> x() { set -a; y=1; }
18:01	x; echo "$y"
18:01	1
18:01	AFAIK, exported variables are global. Unless there's a subshell somewhere, so they don't reach back to the parent shell.
18:11	<vagrantc> hrm. so init-ltsp.d/01-clean-cache does: rm -f /var/cache/ltsp/ltsp_config /var/cache/ltsp/ltsp_config_env
18:11	shouldn't that with out /var/cache/ltsp/ltsp_config
18:11	??
18:12	<stgraber> alkisg: I just updated the seeds in xenial to drop LTSP from the non-existing Ubuntu alternate media, this should result in it being demoted to universe over the next few days which will then give you upload rights to it
18:13	alkisg: I still have to find a new home for that postinst code we have in there so until that happens we can't do a clean sync from Debian, but I'll hopefully have time to do that over the next few weeks
18:13	<alkisg> stgraber: thanks! Sure, we can do that with a bit of help from vagrantc.
18:13	stgraber: you'll still oversee the edubuntu 16.04 release, right?
18:14	<stgraber> yep
18:14	<alkisg> Cool
18:14	<stgraber> the code we've got is edubuntu specific so it'll move into one of the edubuntu-* packages, shouldn't need any changes on the Debian side, assuming the rest of the delta (depends/recommends) made it to Debian but I thought it all did last I checked
18:16	<alkisg> Okey, and we can improve the edubuntu bits after 16.04 (e.g. to add fat client support in the live cd + installer)
18:17	vagrantc: I don't think we're missing any values from the initramfs... the mac address is written there after 01-clean-cache
18:17	<vagrantc> LTSP being demoted to universe ...
18:17	* vagrantc doesn't really know if that's a good or bad thing
18:17	<vagrantc> alkisg: ah ... that's probably why it's not used then
18:18	alkisg: it's written after ltsp_config_env is created ...
18:18	<alkisg> vagrantc: It mainly means you'll have me as the ubuntu ltsp maintainer instead of stgraber... stgraber did a very fine job but he lacks time to invest in ltsp currently, so I think it's a good thing.
18:18	<vagrantc> alkisg: nice!
18:19	<alkisg> So, e.g. when I want a new release because of the 16.04 feature freeze, I'll prepare the upstream code, ping you to do a debian release (or you could teach me how to do it myself), and then syncpackage to ubuntu
18:20	* alkisg needs to go, thank you guys, later!
18:20	<vagrantc> alkisg: we get you DM status, and then i can retire!
18:20	<alkisg> Haha
18:20	Nope I won't let you do that, you're way younger than me! :D
18:22	<vagrantc> getting older all the time!
18:22	alkisg is now known as work_alkisg
18:31	<vagrantc> work_alkisg: well, it's a one-liner ... change ltsp_config to ltsp_config_env ...
18:50	alternately, just moving it before init-ltsp.d/05-getltsconffile
19:03	markit has joined IRC (markit!~marco@88-149-177-66.v4.ngi.it)
19:34	<highvoltage> vagrantc: the universe won't let you retire.
20:35	work_alkisg is now known as alkisg
20:35	<alkisg> vagrantc: change ltsp_config to ltsp_config_env where?
20:44	cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 260 seconds)
20:46	cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
20:50	ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:10	alkisg is now known as work_alkisg
21:19	<vagrantc> work_alkisg: reverting your LTSP_CLIENT_MAC and changing ltsp_config to ltsp_config_env in init-ltsp.d/50-client-mac
21:19	work_alkisg: or moving init-ltsp.d/50-client-mac to init-ltsp.d/04-client-mac
21:19	not sure which is "better"
21:36	markit has left IRC (markit!~marco@88-149-177-66.v4.ngi.it, )
21:46	gdi2k has left IRC (gdi2k!~gdi2k@180.191.106.186, Ping timeout: 240 seconds)
21:59	gdi2k has joined IRC (gdi2k!~gdi2k@119.94.19.39)
23:07	gdi2k has left IRC (gdi2k!~gdi2k@119.94.19.39, Ping timeout: 264 seconds)
23:19	gdi2k has joined IRC (gdi2k!~gdi2k@180.191.106.186)