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

Request log from specific day:

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

00:27	dtcrshr has left IRC (dtcrshr!~datacrush@unaffiliated/datacrusher, Quit: Saindo)
01:09	BuddyButterfly has left IRC (BuddyButterfly!~BuddyButt@h1359005.stratoserver.net, Quit: Leaving.)
02:20	danau111 has joined IRC (danau111!~durban@66.251.57.114)
02:23	Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 250 seconds)
02:23	bitchecker_ has left IRC (bitchecker_!~bitchecke@31.131.20.132, Ping timeout: 250 seconds)
02:23	TatankaT has left IRC (TatankaT!~tim@193.190.253.114, Ping timeout: 250 seconds)
02:23	bitchecker has joined IRC (bitchecker!~bitchecke@31.131.20.132)
02:24	TatankaT has joined IRC (TatankaT!~tim@193.190.253.114)
02:26	Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack)
05:24	adrianorg has left IRC (adrianorg!~adrianorg@177.18.176.206, Ping timeout: 272 seconds)
05:25	adrianorg has joined IRC (adrianorg!~adrianorg@186.215.19.254)
05:27	lmds__ has left IRC (lmds__!~lmds@tui.pi-et-ro.net, Read error: Connection reset by peer)
06:12	work_alkisg is now known as alkisg
06:38	ricotz has joined IRC (ricotz!~ricotz@p5B2A999D.dip0.t-ipconnect.de)
06:38	ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
07:28	vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
07:50	mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
08:03	uXus has left IRC (uXus!~uXus@217.77.222.72, Remote host closed the connection)
08:05	uXus has joined IRC (uXus!~uXus@217.77.222.72)
08:10	<alkisg> !alkisg-todo
08:10	<ltsp> alkisg-todo: (#1) support xnbd-proxy for local caching: https://bitbucket.org/hirofuchi/xnbd/wiki/Home#!scenario-2-simple-proxy-server-distributed-copy-on-write, or (#2) replace "kernel memtest86+.bin" with "linux memtest86+.bin", see r1516, or (#3) LDM_GUESTLOGIN=auto, or (#4) Support UEFI, or (#5) make KEEP_SYSTEM_SERVICES override user-defined RM_SYSTEM_SERVICES, or (#6) add forcepae, or (#7) overlayfs with workdir: (1 more message)
08:10	<alkisg> !more
08:10	<ltsp> https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-October/010686.html
08:10	<alkisg> !forget alkisg-todo 7
08:10	<ltsp> The operation succeeded.
08:19	vickymnt has joined IRC (vickymnt!c23fefeb@gateway/web/freenode/ip.194.63.239.235)
08:19	<vickymnt> alkisg: Καλημέρα Άλκη
08:19	<alkisg> Καλημέρα vickymnt
08:19	!greek
08:19	<ltsp> greek: Στο παρόν κανάλι μιλάνε μόνο Αγγλικά, για υποστήριξη στα Ελληνικά από την υπηρεσία Τεχνικής Στήριξης ΣΕΠΕΗΥ διαβάστε το http://ts.sch.gr/wiki/IRC και στη συνέχεια πληκτρολογήστε /j #ts.sch.gr
08:20	<vickymnt> Milame mono agglika?
08:20	<alkisg> vickymnt: είσαι σε λάθος κανάλι
08:21	Γράψε /j #ts.sch.gr για να μπεις στο ελληνικό κανάλι
08:21	<vickymnt> Εδώ με έβγαλε ο Επόπτης
08:21	<alkisg> Από τα sch-scripts να μπαίνεις
08:21	Όχι από τον Επόπτη
08:21	<vickymnt> οκ
08:21	<alkisg> Ο Επόπτης είναι διεθνής
08:21	<vickymnt> Βγαίνω
08:21	<alkisg> οκ
08:21	vickymnt has left IRC (vickymnt!c23fefeb@gateway/web/freenode/ip.194.63.239.235, Client Quit)
08:31	schlady has joined IRC (schlady!~schlady@ip1f111304.dynamic.kabel-deutschland.de)
08:33	Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
08:36	khildin has joined IRC (khildin!~khildin@ip-62-235-40-242.dial.scarlet.be)
08:51	adrianorg has left IRC (adrianorg!~adrianorg@186.215.19.254, Ping timeout: 265 seconds)
08:51	adrianorg has joined IRC (adrianorg!~adrianorg@186.215.19.254)
09:52	schlady has left IRC (schlady!~schlady@ip1f111304.dynamic.kabel-deutschland.de, Remote host closed the connection)
10:05	gchaos has left IRC (gchaos!~administr@187.87.208.114, Quit: Leaving)
10:50	Faith has joined IRC (Faith!~paty_@unaffiliated/faith)
11:17	dtcrshr has joined IRC (dtcrshr!~datacrush@unaffiliated/datacrusher)
11:25	schlady has joined IRC (schlady!~schlady@141-53-211-199.ip.uni-greifswald.de)
11:43	khildin has left IRC (khildin!~khildin@ip-62-235-40-242.dial.scarlet.be, Ping timeout: 255 seconds)
11:51	pc-prova has joined IRC (pc-prova!1fc20ea9@gateway/web/freenode/ip.31.194.14.169)
11:52	pc-prova has left IRC (pc-prova!1fc20ea9@gateway/web/freenode/ip.31.194.14.169, Client Quit)
12:04	alkisg is now known as work_alkisg
12:58	lucascastro has joined IRC (lucascastro!~lucas@186.227.185.10)
13:11	ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 240 seconds)
13:12	ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
13:17	khildin has joined IRC (khildin!~khildin@ip-62-235-40-242.dial.scarlet.be)
13:19	gchaos has joined IRC (gchaos!~administr@border-ave.qnet.com.br)
13:19	<gchaos> hello there
13:20	does anyone has experience with LTSP cluster with home shared via NFS through LTSP farm?
13:20	would it be too slow?
13:46	danau111 has left IRC (danau111!~durban@66.251.57.114)
13:53	epoptes_user4 has joined IRC (epoptes_user4!c23fefeb@gateway/web/freenode/ip.194.63.239.235)
14:00	gp has joined IRC (gp!~gp@104-14-168-137.lightspeed.rcsntx.sbcglobal.net)
14:00	gp_alt has joined IRC (gp_alt!~gp@104-14-168-137.lightspeed.rcsntx.sbcglobal.net)
14:00	gp is now known as Guest88893
14:00	gp_alt is now known as Guest93403
14:09	Guest88893 has left IRC (Guest88893!~gp@104-14-168-137.lightspeed.rcsntx.sbcglobal.net, Quit: Leaving)
14:09	Guest93403 has left IRC (Guest93403!~gp@104-14-168-137.lightspeed.rcsntx.sbcglobal.net, Quit: Leaving)
14:10	gp_alt_ has joined IRC (gp_alt_!~gp@104-14-168-137.lightspeed.rcsntx.sbcglobal.net)
14:25	gp_alt_ has left IRC (gp_alt_!~gp@104-14-168-137.lightspeed.rcsntx.sbcglobal.net, Quit: Leaving)
14:25	gp_alt_ has joined IRC (gp_alt_!~gp@104-14-168-137.lightspeed.rcsntx.sbcglobal.net)
14:32	loganfive has joined IRC (loganfive!~loganfive@s72-38-119-242.static.comm.cgocable.net)
14:35	schlady has left IRC (schlady!~schlady@141-53-211-199.ip.uni-greifswald.de, Remote host closed the connection)
14:39	schlady has joined IRC (schlady!~schlady@141-53-211-199.ip.uni-greifswald.de)
14:47	<\|\|cw> gchaos: depends on the IO workload and if you're clients are gigE or not
14:48	and also if you mean /home on the client or just the server
14:48	server with gigE or better would likely be fine
14:58	ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
15:15	lbssousa has joined IRC (lbssousa!~laercio@177.143.56.59)
15:18	work_alkisg is now known as alkisg
15:19	<alkisg> lbssousa: hello! In which case do you need to tune TIMEOUT?
15:20	afmorro has joined IRC (afmorro!bffd2f65@gateway/web/freenode/ip.191.253.47.101)
15:25	fnurl has left IRC (fnurl!3cf8605f@gateway/web/freenode/ip.60.248.96.95, Ping timeout: 246 seconds)
15:31	mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
15:31	<lbssousa> alkisg: Hi! I'm doing some tests here. For small timeouts, my epoptes-client daemon keeps respawning even if no disruption occurs in my network. The smallest value I could find here to keep epoptes-client stable is 10 seconds, but I suppose this value may change depending on network conditions. Anyway, I've just realized that it respawns almost instantaneously after I disconnect network cable (i.e. I don't need to wait for full TIMEOUT). I'm trying to find
15:31	a case (if any) where a larger timeout can leave my clients to take a too long time to reconnect. If there's not such a case, then I'll revoke my proposal for customizing TIMEOUT.
15:32	<alkisg> lbssousa: the 10 seconds timeout exists because it's the interval of the pings that the epoptes service sends to the clients
15:32	That's why we've set the default timeout to 20 seconds
15:33	<lbssousa> alkisg: OK
15:33	<alkisg> About taking a lot of time to reconnect, there's a 60 second interval in socat
15:33	If we need to lower something, it would be that
15:33	E.g. suppose that you restart the epoptes service on the server
15:34	That's a normal "quit" on the client side, so it gets relaunched
15:34	If it reacts too fast, then epoptes service hasn't started yet, and socat fails and retries after 60 seconds
15:34	So if you're seeing reconnections that need longer than 20 seconds, it's because of that
15:35	<lbssousa> alkisg: Understood. I'll play with this timeout as well.
15:37	<alkisg> lbssousa: have you seen any issues with timeout==20?
15:38	Note also that we don't want the reconnect to be too soon, because when a user tries to logout, socat gets kills, and that triggers an epoptes-client relaunch, and we don't want to react on that while xorg is still alive, we want xorg to die first
15:39	bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
15:39	<alkisg> *killed
15:42	<lbssousa> alkisg: I've noticed here a ~13 seconds delay between "epoptes-client got signal 15. Relaunching..." and the efective respawning of epoptes-client. In this proposital (related to what you just said)?
15:42	<alkisg> Yup, we don't want to lower that one
15:44	We don't have a way to cleanly check if socat was killed because of a clean session exit, so we want to wait a bit and check if xorg is still alive before reconnecting
15:45	And the same issue happens with shutdown as well, for the root epoptes-client
15:46	In the future with systemd we might be able to lower that timeout a lot
16:06	<lbssousa> alkisg: OK. Thank you for explanations! I'll try to lower this one in my local fork, then.
16:18	<m3741> hey everyone. when i run ltsp-config nbd-server it doesn't seem to be setting the permissions correctly on files it generates. it sets /etc/nbd-server/config as 640 for example
16:20	running ltsp-config 5.5.1-1ubuntu2 on 14.04.3 x64
16:20	<alkisg> Maybe your umask is wrong?
16:21	sudo -i; umask ==> 0022
16:22	<m3741> sigh, thx. mines set to 0027
16:22	head -> desk
16:22	<alkisg> :)
16:27	ke4nhw has joined IRC (ke4nhw!ke4nhw@unaffiliated/xanthaos)
16:28	<ke4nhw> I tried loading the repos in CentOS 7 from the website, and it came up with an error. Is there another link to the repo install or is there another way I can get ltsp for CentOS 7?
16:28	<alkisg> ltsp isn't really maintained on centos/fedora/rhel etc
16:28	Try some deb-based distribution
16:29	<ke4nhw> Okay
16:29	Thanks
16:30	<alkisg> !ltsp-pnp
16:30	<ltsp> ltsp-pnp: ltsp-pnp is an alternative (upstream) method to maintain LTSP installations for thin and fat clients that doesn't involve chroots: https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
16:30	<alkisg> That's an easy way to get ltsp up and running ^
16:34	<ke4nhw> is ltsp-pnp the same as ltsp? I'm going to be playing with this in a VM, so I'll get Debian installed in a VM and go from there
16:34	<alkisg> It's the same, yes, it's just a bit easier if you match its use case
16:35	If you tell us your end goal, we can proposed if it fits you or not
16:36	*propose
16:38	<ke4nhw> Right now, the end goal is to use a netbook without an OS by net booting it to an OS, preferredly CentOS or Windows 7. Later, I may want to expand this to include several other devices at different locations. I'd likely have a small server running at each site that I could push an image to whenever I needed to update the image, then clients could boot from those images. Each server would never
16:38	handle more than a couple of devices, and right now it's just for personal interest and to see if it could be useful for anything bigger.
16:39	<alkisg> If it's for single targets, then you might want to look at iscsi instead of ltsp
16:39	ltsp is about booting linux into any number of clients
16:39	On top of that one can run a windows VM or RDP
16:40	<ke4nhw> Well, initially it's for single targets, like I said it may expand a few clients later
16:40	<alkisg> You can copy iscsi disks server-side, to expand to a few more clients
16:40	You'd need one virtual disk per client
16:40	LTSP has one virtual disk for e.g. 100 clients
16:40	Not one per client
16:41	You can get ltsp up and running in less than an hour (including the os installation) if you follow the ltsp-pnp page
16:41	<ke4nhw> Okay, what about ease of setup and use, is ltsp or iscsi going to be easier to get running?
16:42	<alkisg> Well if you want centos or windows (native, not on top of ltsp), then iscsi is easier, even if it takes a few days
16:43	If you want ubuntu/ltsp ==> 1 hour, and possibly debian/ltsp ==> 2 hours
16:43	Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
16:43	<ke4nhw> So it's looking like debian or ubuntu lstp is easier, and I'm assuming if it'll work for 100 clients then it'll work for one or two, right?
16:44	<alkisg> Sure
16:44	Put your VM in bridged mode and follow the wiki page
16:45	<ke4nhw> Okay, I'll look over all of the docs for ltsp first and decide where to go from there
16:45	<alkisg> The docs are a mess
16:45	I'd advice to follow the ltsp-pnp page first, and read the docs later
16:45	<ke4nhw> Okay, I'll pull that page first and go from there
16:45	<alkisg> ok
16:52	<afmorro> Hey Guys, just another simple question. I've searched a few forums, but haven't found a good answer
16:53	the ltsp server won't be the same as firewall, but I would wan't to control access with squid and stuff. Is it possible? Like, 1 Router/Firewall/Proxy, 1 LTSP-Server, and diskeless workstations internet access managed by my firewall
16:53	don't know if made myself clear
16:54	<alkisg> Sure, a single subnet with everything inside it, and your router controlling internet access
16:54	I.e. single NIC ltsp setup, not dual nic
17:01	<afmorro> nice
17:01	dhcp will be controlle by my router then?
17:02	<alkisg> Yup
17:02	You can put dhcp wherever you like
17:02	You can also put proxydhcp in the ltsp server
17:02	<afmorro> nice.
17:02	<alkisg> It's best if you leave tftp to the ltsp server, so that you don't have to copy the kernels around
17:03	toyotahead has joined IRC (toyotahead!1846806a@gateway/web/freenode/ip.24.70.128.106)
17:03	<toyotahead> hello
17:04	<alkisg> Hi
17:05	<toyotahead> I have been trying an edbuntu ltsp installation. It installs fine, but my thin clients dont seem to PXE boot... Fat clients load just fine. I have been searching the internet for ages for a possible solution. Has this been observed by anyone else?
17:06	<alkisg> When you say fat clients, do you mean local installations on PCs with hard disks?
17:06	Because in LTSP we call fat clients the diskless clients that boot from the ltsp server, but run the OS with their own CPU/RAM
17:07	<toyotahead> by fat client i mean a full blown pc that is on the same network as the thin client. the fat client boots via PXE just like the thin client would.
17:07	ok my terminology is wrong then... what would you define the full blow pc booting with pxe then?
17:07	<alkisg> Fat client
17:07	And I would say "standalone client" if the OS was local, on the client hard disk
17:08	So you're saying that your server works fine, as ltsp fat clients boot from it, but your thin clients have issues?
17:08	<toyotahead> uhh the pc, has no OS installed. it is booting via PXE
17:08	<alkisg> What kind of thin clients are they? Do they support PXE?
17:09	<toyotahead> wyse c10le
17:09	yes pxe supported
17:09	<alkisg> And do they show any error message?
17:09	<toyotahead> the thin clients obtain ip, and tftp files...
17:11	then the screen shows somthing about memory allocation (as does the pc pxe booting). I can witness network traffic still at this point. no updates on the thin client screen - goes blank with cursor at top left - eventrully screen goes completely black when the network traffic stops
17:11	<alkisg> Do you know how to edit lts.conf?
17:11	Which version of edubuntu is that? dpkg -l ltsp-server
17:12	Try XSERVER=vesa in lts.conf
17:12	<toyotahead> Desired=Unknown/Install/Remove/Purge/Hold \| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend \|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) \|\|/ Name Version Architecture Description +++-=================-=============-=============-======================================= ii ltsp-server 5.5.1-1ubuntu all basic LTSP server environment
17:12	schlady has left IRC (schlady!~schlady@141-53-211-199.ip.uni-greifswald.de, Remote host closed the connection)
17:13	<alkisg> 14.04 without the ppa then? ok
17:13	<toyotahead> i have a ssh access to the ltsp server at the moment... where is lts.conf located?
17:13	<alkisg> In /var/lib/tftpboot/ltsp/i386/lts.conf
17:14	<toyotahead> # lts.conf, provided by Edubuntu installer # see http://edubuntu.org/documentation for more information [default] LDM_THEME=edubuntu LANG=en_US.UTF-8 LANGUAGE=en_CA.UTF-8 LDM_LANGUAGE=en_CA.UTF-8 LDM_SESSION=gnome-fallback
17:15	<alkisg> At the end of the file, try:
17:15	<toyotahead> that didnt paste very well...
17:15	<alkisg> XSERVER=vesa
17:15	<toyotahead> ok
17:15	<alkisg> See if your thin clients boot that way
17:15	<toyotahead> do i need to restart the ltsp server for this change to take effect?
17:15	<alkisg> No, only the clients
17:16	<toyotahead> ok. will try. brb
17:21	that worked! Thank you so much!
17:22	<alkisg> toyotahead: you don't want to leave that there though
17:22	It's using vesa for the graphics of the clients, which is slow
17:22	<toyotahead> oh?
17:22	<alkisg> You at least want to restrict it to the thin clients, not to the desktops
17:22	You can filter that via a [mac:address] section
17:23	I.e. [default] options here, then [mac:address:for:thin:clients:*] XSERVER=vesa
17:23	You should first find the common prefix for the thin client mac addresses
17:23	ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)
17:23	<toyotahead> ok i understand.
17:24	do you have any idea why these thin clients can not use the non xserver-vesa ?
17:24	<alkisg> First, login to one of them
17:24	Inside the user session, run: ltsp-localapps xterm
17:25	An xterm will open. There, run: lspci -nn -k \| grep -A 2 VGA
17:25	You'll see the graphics card that they have. The problem is that it's not well supported in that ubuntu version.
17:26	<toyotahead> ah so the c10le is just old hardware
17:26	<alkisg> Not necessarily, I have 20 year-old cards here working fine
17:26	It's probably not very open source friendly
17:26	<toyotahead> so perhaps a kernal upgrade down the road may resolve this
17:27	<alkisg> If you actually do what I said, we'll find your answers more easily
17:27	Without first telling us the graphics card, it's difficult to guess
17:27	<toyotahead> ok sec... the thin client is in another area.. takes me a bit to run back and forth. brb
17:27	<alkisg> You could use epoptes :)
17:27	!epoptes
17:27	<ltsp> epoptes: Epoptes is a computer lab administration and monitoring tool. It works on Ubuntu and Debian based labs with LTSP or non-LTSP servers, thin and fat clients, standalone workstations, NX clients etc. More info: http://www.epoptes.org
17:27	<alkisg> I think it's even preinstalled in edubuntu
17:28	<toyotahead> checking...
17:28	<alkisg> epoptes > right click on the client > open terminal > root, locally
17:28	It's under the network submenu
17:34	<toyotahead> ok... will take me a bit to type it over.. can not cut copy paste...
17:35	bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Quit: Goin' down hard)
17:35	<alkisg> toyotahead: select + middle mouse click
17:36	It's the xorg method for copy/paste
17:36	select the text, then go to irc and press middle mouse button for paste
17:37	<toyotahead> 00:01 VGA compatible controller [0300]: VIA Technologies, Inc. VX855/VX875 Chrome 9 HCM Integrated Graphics [1106:5122]
17:38	<alkisg> Yup, that's very open source unfriendly :)
17:38	<toyotahead> ok
17:39	<alkisg> https://help.ubuntu.com/community/OpenChrome
17:39	Leave it with vesa
17:40	Or create an ubuntu 9.04 chroot :D (it's not worth it)
17:41	<toyotahead> so its not worth the effort of trying this chrome driver... to just leave it using vesa and mac filter it?
17:43	<alkisg> You could also try a few more options mentioned in http://manpages.ubuntu.com/manpages/trusty/man4/openchrome.4.html
17:43	Or, 12.04 and the XAA acceleration
17:43	!noaccel
17:43	<ltsp> noaccel: Some graphics cards, e.g. SiS [1039:6325] on 14.04, require this setting in lts.conf: X_OPTION_01="\"NoAccel\""
17:43	<alkisg> Try replacing XSERVER=vesa with that ^ one
17:43	It will be a bit better
17:44	You can also ask in the #ubuntu-x channel, maybe someone there knows more details about the broken openchrome driver
17:47	<toyotahead> gotcha!
17:47	you have been an amazing help!!!
17:48	<alkisg> :)
17:49	<toyotahead> thank you so much for your help! very insightful!
17:49	<alkisg> You're welcome
18:04	yanu_ has left IRC (yanu_!~yanu@178-116-58-90.access.telenet.be, Remote host closed the connection)
18:14	telex has joined IRC (telex!teletype@94.247.40.156)
18:29	vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
18:44	khildin has left IRC (khildin!~khildin@ip-62-235-40-242.dial.scarlet.be, Remote host closed the connection)
18:52	<alkisg> vagrantc: I'm thinking of allowing INIT_COMMAND_, XRANDR_COMMAND_, FSTAB_* etc instead of just [0-9]
18:52	So one could e.g. do INIT_COMMAND_FOR_RASPBERRY_PIS_0=xxx
18:52	and have it in a special [section] without caring about overlapping with other sections having INIT_COMMAND_0-9
18:54	E.g. env \| sort -V \| sed -n 's/^FSTAB_.=//p' instead of the current env \| sort -V \| sed -n 's/^FSTAB_[0-9]=//p'
18:58	<vagrantc> alkisg: seems reasonable
18:58	<alkisg> Cool
18:58	<vagrantc> alkisg: maybe INIT_COMMAND_*[0-9] ?
18:58	<alkisg> Why restrict it? Leave it up to the users... they can even use A-Z if the prefer
18:59	<vagrantc> not strongly opinionated, really
18:59	<alkisg> Cool
19:00	!learn alkisg-todo as INIT_COMMAND_* instead of [0-9]
19:00	<ltsp> Error: "0-9" is not a valid command.
19:00	<vagrantc> it does allow the users to shoot themselves in the foot with sort order
19:00	<alkisg> !learn alkisg-todo as `INIT_COMMAND_* instead of [0-9]`
19:00	<ltsp> The operation succeeded.
19:01	<alkisg> !alkisg-todo
19:01	<ltsp> alkisg-todo: (#1) support xnbd-proxy for local caching: https://bitbucket.org/hirofuchi/xnbd/wiki/Home#!scenario-2-simple-proxy-server-distributed-copy-on-write, or (#2) replace "kernel memtest86+.bin" with "linux memtest86+.bin", see r1516, or (#3) LDM_GUESTLOGIN=auto, or (#4) Support UEFI, or (#5) make KEEP_SYSTEM_SERVICES override user-defined RM_SYSTEM_SERVICES, or (#6) INIT_COMMAND_* instead of [0-9]
19:01	<vagrantc> is that all of the options that support XYZ_[0-9] ?
19:01	<alkisg> It would make sense to do it for all of them, yup
19:02	HOSTS, CRONTAB, MODULE, RCFILE, ...
19:03	<vagrantc> i can't really come up with a solid reason, but i feel like we should keep the numbers ...
19:03	<alkisg> We can keep them in the docs, but not restrict it in the code
19:04	<vagrantc> that seems like the worst of both worlds
19:04	we have plenty of accidentally hidden features
19:04	well, lazily hidden features
19:05	lbssousa has left IRC (lbssousa!~laercio@177.143.56.59, Quit: lbssousa)
19:07	* alkisg wouldn't want HOSTS_PC12=xxx to work, and HOSTS_OFFICE_PC=yyy to be excluded without warnings
19:09	<vagrantc> HOSTS_[0-9]* then?
19:10	<alkisg> I think HOSTS_.* is fine
19:10	<vagrantc> we don't have any other variables where the namespace will conflict?
19:11	e.g. HOSTS_BLAH_.* vs. HOSTS_.* ?
19:11	<alkisg> Exposed in the environment? I surely hope not...
19:14	* vagrantc is thinking of things like LOCALDEV_DENY vs. LOCALDEV_DENY_USB ... but so far i haven't seen any of the proposed variables to e impacted in that way
19:15	<alkisg> ltsp-trunk$ grep -rw env . \| grep sed
19:15	That shows the directives I'm talking about
19:15	<vagrantc> X_OPTION_ and X_MONITOR_OPTION_ comes close but should be fine
19:17	<alkisg> !learn alkisg-todo as change /var/cache/ltsp to /run/ltsp
19:17	<ltsp> The operation succeeded.
19:17	<vagrantc> they all match beginning so should be fine
19:18	<alkisg> It will also solve the problem with FSTAB_0 vs HOSTS_00
19:22	<vagrantc> heh
19:22	<alkisg> About the two monitors patch, when applying the patch, the second monitor is completely black
19:22	Maybe it would be better to have a background color there
19:22	Is there one defined in the ldm theme?
19:23	loganfive has left IRC (loganfive!~loganfive@s72-38-119-242.static.comm.cgocable.net, Quit: Leaving)
19:30	<vagrantc> alkisg: don't know how that all works.
19:30	<alkisg> highvoltage: ^ ?
19:31	Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
19:32	ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
19:34	<highvoltage> alkisg: I believe that can be set in scott's evilwm, but haven't looked into it
19:35	(wlthough I don't know how thath multimonitor patch works)
19:35	<alkisg> highvoltage: I meant, if there's somewhere in the theme where the background color is declared, white, or black etc
19:37	<highvoltage> alkisg: yes that can be defined in the greeter-gtkrc file, it can be a gradient too.
19:48	<alkisg> Nice, yup I think that would look better than completely black
19:52	<vagrantc> as long as it's consistant with whatever is on the login screen...
19:55	<alkisg> Well if it's not, it can be set (or default to) black
19:57	<vagrantc> couldn't it just display the same graphic/gradient/whatever that's on the login screen?
19:57	minus the widgets?
19:57	<alkisg> Sure, would that look better?
19:57	...probably...
19:57	<vagrantc> i guess you'd get some strange aesthetic issues, such as the debian swirl showing up twice and whatnot
19:58	* vagrantc also wonders if it scales to an arbitrary number of screens
20:07	lucascastro has left IRC (lucascastro!~lucas@186.227.185.10, Remote host closed the connection)
20:12	afmorro has left IRC (afmorro!bffd2f65@gateway/web/freenode/ip.191.253.47.101, Ping timeout: 246 seconds)
20:24	alkisg is now known as work_alkisg
20:50	NeonLicht has left IRC (NeonLicht!~NeonLicht@darwin.ugr.es, Ping timeout: 260 seconds)
20:54	dtcrshr has left IRC (dtcrshr!~datacrush@unaffiliated/datacrusher, Remote host closed the connection)
20:58	<ke4nhw> I've been looking over the setup info for ltsp on debian, and I am wondering if it's necessary to run a DHCP, DNS, or DNSMASQ on the server, as all DHCP and net addressing functions are handled in the router, and I'd rather keep it that way so that the router's security protocols can be preserved
20:59	<vagrantc> sure, you can separate all those functions out
20:59	ke4nhw: you'll need to be able to configure your DHCP server to pass the right dhcp options
21:01	LTSP doesn't typically need DNS
21:02	dnsmasq can be configured easily to use your regular DHCP server, but add the extra stuff LTSP needs to boot
21:02	<ke4nhw> I most likely can do that, I've got pretty good flexibility in my setup. What dhcp options would I need to pass to the ltsp server and to the intended client (I'd prefer to setup a fat client to take the load off the server cpu and ram)
21:03	<vagrantc> dnsmasq proxydhcp mode is really useful if your router is unconfigurable, or hard to configure
21:03	next-server, root-path ... maybe others
21:09	danau11 has joined IRC (danau11!~durban@66.251.57.114)
21:11	danau11 has left IRC (danau11!~durban@66.251.57.114)
21:26	ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:45	Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving)
21:52	ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)
22:12	Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
22:16	danau111 has joined IRC (danau111!~durban@66.251.57.114)
22:16	danau111 has left IRC (danau111!~durban@66.251.57.114)
22:18	FrozenZia has left IRC (FrozenZia!pbrown@evo.paivola.fi, Ping timeout: 260 seconds)
22:23	danau11 has joined IRC (danau11!~durban@66.251.57.114)
22:23	danau11 has left IRC (danau11!~durban@66.251.57.114)
23:29	<maldridge> pretty sure its just those two, I think I set option 43 as well (I think that's the right option number) which turns off slow tftp modes