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


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

01:48gbaman has left IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk, Remote host closed the connection)
01:49gbaman has joined IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk)
01:54gbaman has left IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk, Ping timeout: 256 seconds)
02:15gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
02:16
<fnurl>
gbaman you free?
02:22gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 272 seconds)
02:35vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
03:18gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
03:27gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 240 seconds)
03:50vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
04:24gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
04:33gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 272 seconds)
05:14
<thedarkener>
What would people here say the most used DE or WM is used currently in LTSP?
05:18
<maldridge>
thedarkener: my sites all run xfce4, with a temp setup that runs lxde
05:18
<quinox>
we run a mix of awesome, mate and KDE
05:19work_alkisg is now known as alkisg
05:19
<maldridge>
quinox: how well do your users take to awesome?
05:19
<quinox>
KDE was nonexisted back when Gnome was still decent
05:19
<alkisg>
gnome-flashback here, starting to check out mate-desktop
05:19
<quinox>
people can choose their WM themselves, so if they choose awesome they are pretty happy with it
05:20
<alkisg>
The main thing is to stay away from 3d desktops if you have thin clients
05:20
Anything else goes..
05:20
Ah, and I've heard KDE having real problems with fat clients due to hundreds of MB generated in /var upon login
05:21
<quinox>
there are some hacks you have to use with KDE, yeah
05:21
<alkisg>
quinox: if you know them, file a bug to have them submitted upstream in ltsp, if that'd doable from init-ltsp.d...
05:21
<quinox>
https://help.ubuntu.com/community/UbuntuLTSP/FatClients#KDE_4.x_special_notes
05:23
<alkisg>
Is that the correct way to do it? Or is SSHFS_EXTRAMOUNTS=/var/tmp better?
05:24
If an sshfs mount at /var/tmp/kdecache-$USER works, then there wouldn't be need for those workarounds...
05:24
It could be done on login when session=kde
05:24
<quinox>
I'm not sure - this works decent but I could try that
05:25
I don't like KDE much
05:25
there's now also a bug with Baloo running even though it's not supposed to
05:25
pointlessly indexing files
05:26
<alkisg>
lame
05:26
<cyberorg>
alkisg, hi, you still develop epoptes?
05:26
<alkisg>
cyberorg: yes, we're preparing to release a new version
05:26
Is it still working ok in opensuse?
05:26
<cyberorg>
"Since version 1.7.3.0 socat checks the peer certificate for match with the <host> parameter or the value of the openssl-commonname option"
05:27
man socat ^^
05:27
<alkisg>
We've reported a bug for that using 100% cpu when not found
05:27
It's solved upstream but not released yet
05:27
<cyberorg>
so certificate needs to be regenerated
05:27
<alkisg>
No, it has an option to ignore it
05:27
<cyberorg>
nopes, not solved, tried bzr version
05:27
<alkisg>
http://bazaar.launchpad.net/~epoptes/epoptes/trunk/revision/428
05:28
It puts an empty commonname there
05:28
<cyberorg>
ah, I worked out regeneration of certs
05:29
<alkisg>
http://packages.ubuntu.com/wily/socat ==> 1.7.3. Epoptes now works fine in Wily, except for the other bug I mentioned (which is solved upstream in socat but not published)
05:29gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
05:30
<cyberorg>
there is another issue, with tigervnc(vncviewer) connecting to client does not seem to work, don't have any clue why
05:30
works with old tightvnc
05:30
<alkisg>
Do you have a test environment that we could vnc to?
05:31
<cyberorg>
i can set it up later
05:32
<alkisg>
Cool. Phantomas usually works more on Epoptes, but I could do the tigervnc troubleshooting...
05:32
(i.e. if you happen to find both me and phantomas online at the same time, that would be best)
05:32
<cyberorg>
one more issue, epoptes from suse client to deb based still gets error about log_end_msg not being there
05:33
<alkisg>
Had you filed a bug report for that?
05:33
<cyberorg>
so best if you remove deb specific functions from epoptes completely and use "echo"?
05:33
<alkisg>
I remember the issue, but not how it was supposed to be solved
05:34
Supposedly they are "lsb compliant", not debian specific, but sure let's do something for that
05:34
<cyberorg>
no, just discovered all this while writing https://sourceforge.net/p/kiwi-ltsp/wiki/Install%20on%20other%20distributions/
05:34
everyone seems to ignore lsb these days :)
05:35
<alkisg>
if [ -f /lib/lsb/init-functions ]; then
05:35
. /lib/lsb/init-functions
05:35
else
05:35
alias log_begin_msg="echo -n"
05:35
fi
05:35
log_begin_msg "Epoptes-client connecting to $SERVER:$PORT..."
05:35
<cyberorg>
systemd
05:35
<alkisg>
So opensuse provides init-functions, but log_begin_msg isn't there?
05:35
<cyberorg>
yes, i know where it comes from, issue is fixed suse-suse, not suse-client to deb server
05:36
when suse client connect to deb server, the server still has the function, in reply to client it sends log_end_msg
05:36gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 252 seconds)
05:37
<alkisg>
Ah I see where that is
05:37
data/client-functions
05:37
<cyberorg>
client-functions on the server
05:37
<alkisg>
cyberorg: could you file a bug report for that?
05:37
<cyberorg>
sure
05:39
<alkisg>
Thanks :)
05:40
We'll fix it before releasing the new epoptes version
05:40
cyberorg: just to be clear, you don't have lib/lsb/init-functions , right?
05:41
<cyberorg>
not in client
05:42
<alkisg>
OK
05:42Guest42749 has left IRC (Guest42749!Guest42749@c-73-0-240-215.hsd1.fl.comcast.net, )
05:44
<cyberorg>
forgot launchpad pass, now trying to reset, no matter what I try i get Bad bot, go away!
05:44
<alkisg>
Hahaha!!!
05:45ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)
05:46
<cyberorg>
alkisg, see PM
06:00
alkisg, added to https://bugs.launchpad.net/epoptes/+bug/1226094
06:01
alkisg, fixed login, used chromium, something in firefox it disliked
06:02
<alkisg>
cyberorg: thanks - wow, I didn't remember that one was still left in the "new" state, we had pushed fixes for that ages ago...
06:04mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
06:07
<cyberorg>
alkisg, was testing kiwi-ltsp on mint live iso booted in virtualbox when i came across this bug
06:08uXuss has joined IRC (uXuss!~uXus@217.77.222.72)
06:08
<cyberorg>
is there easier way to disable dnsmasq started from network-manager? that is from nm itself?
06:09uXus has left IRC (uXus!~uXus@217.77.222.72, Ping timeout: 268 seconds)
06:10
<alkisg>
cyberorg: in mint, it should be in /etc/NetworkManager/NetworkManager.conf ==> dns=dnsmasq
06:10
You just comment that one
06:11
<cyberorg>
alkisg, i know :) have added this link http://askubuntu.com/questions/233222/how-can-i-disable-the-dns-that-network-manager-uses
06:25khildin has joined IRC (khildin!~khildin@ip-83-134-129-97.dsl.scarlet.be)
06:31myrdd has joined IRC (myrdd!~quassel@55d436e3.access.ecotel.net)
06:34gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
06:41gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 246 seconds)
07:03
<cyberorg>
alkisg, let me know when you want vnc access
07:06
<alkisg>
cyberorg: is it possible to do it later on in a few hours, when phantomas will also be here?
07:06khildin has left IRC (khildin!~khildin@ip-83-134-129-97.dsl.scarlet.be, Quit: I'm gone, bye bye)
07:09
<cyberorg>
alkisg, sure, just ping me
07:13
<alkisg>
thanks :)
07:38gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
07:47gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 260 seconds)
08:03xanthi has joined IRC (xanthi!c23fefeb@gateway/web/freenode/ip.194.63.239.235)
08:04khildin has joined IRC (khildin!~khildin@212-166-61-33.win.be)
08:08
<alkisg>
xanthi: θες βοήθεια;
08:21xanthi has left IRC (xanthi!c23fefeb@gateway/web/freenode/ip.194.63.239.235, Quit: Page closed)
08:44gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
08:52gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 246 seconds)
09:08vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi, Ping timeout: 246 seconds)
09:20vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi)
09:35fenixfunk5 has joined IRC (fenixfunk5!~fenix@mail.lbathivel.com)
09:41
<fenixfunk5>
hello! I just had an issue after using ltsp-update-kernels, due to a wrong nbdport number in the file "/var/lig/tftpboot/ltsp/i386/pxelinux.cfg/default". i made it work again by editing the pxelinux.cfg/default file in chroot and rebuilt/reupdated everything. my question is why did I end up with a wrong port number ? i use to use default port 2000, and this time port 2001 ended in my pxelinux.cfg/default file
09:42
<alkisg>
fenixfunk5: nbd stopped using port numbers 5 years ago
09:42
It's using paths now
09:42
Which distro/version are you on?
09:44
<fenixfunk5>
buntu 10.04...
09:45
<alkisg>
I think it had some logic about selecting unused port numbers there
09:45
By looking at /etc/inetd.conf
09:45
But we rewritten that code ages ago, I don't remember... :)
09:46
<fenixfunk5>
yeah that's what i thought, given it only increased the currently used port by 1... i was wondering why this happened this time
09:47
<alkisg>
Even if it was a bug, it doesn't matter much to report it for code that no longer exists...
09:49gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
09:51
<fenixfunk5>
5 years tho, maybe this time my boss will accept a system upgrade ;)
09:51
thank you alkisg !
09:51
<alkisg>
You're welcome
09:56khildin has left IRC (khildin!~khildin@212-166-61-33.win.be, Ping timeout: 265 seconds)
09:56gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 250 seconds)
10:04gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
10:09khildin has joined IRC (khildin!~khildin@212-166-61-33.win.be)
10:11gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, )
10:12fenixfunk5 has left IRC (fenixfunk5!~fenix@mail.lbathivel.com, Quit: Quitte)
10:50alkisg is now known as work_alkisg
10:53khildin has left IRC (khildin!~khildin@212-166-61-33.win.be, Quit: I'm gone, bye bye)
10:54fnurl has left IRC (fnurl!3cf8605f@gateway/web/freenode/ip.60.248.96.95, Ping timeout: 246 seconds)
11:27izzle121 has left IRC (izzle121!~izzle121@70-90-102-229-ma-ne.hfc.comcastbusiness.net, Ping timeout: 240 seconds)
11:29adrianorg has left IRC (adrianorg!~adrianorg@186.213.153.83, Ping timeout: 240 seconds)
11:31adrianorg has joined IRC (adrianorg!~adrianorg@179.182.75.70)
11:46Faith has joined IRC (Faith!~paty_@unaffiliated/faith)
11:47izzle121 has joined IRC (izzle121!~izzle121@70-90-102-229-ma-ne.hfc.comcastbusiness.net)
12:04Faith has left IRC (Faith!~paty_@unaffiliated/faith, Ping timeout: 240 seconds)
12:05Faith has joined IRC (Faith!~paty_@200.144.182.219)
12:05Faith is now known as Guest91580
12:23izzle121 has left IRC (izzle121!~izzle121@70-90-102-229-ma-ne.hfc.comcastbusiness.net)
12:35ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
12:41Guest91580 has left IRC (Guest91580!~paty_@200.144.182.219, Quit: Leaving)
12:54
<cyberorg>
work_alkisg, there are some patches and systemd related stuff in out package, please take if it is useful
12:54
https://build.opensuse.org/package/show/server:ltsp/epoptes
12:54lbssousa has joined IRC (lbssousa!~laercio@179.154.194.17)
12:59
<cyberorg>
work_alkisg, most of those is written by lbssousa
13:00
lbssousa, just mentioned to work_alkisg that we have systemd stuff in our epoptes package
13:00
<lbssousa>
Ah, ok
13:02
<cyberorg>
lbssousa, also reported https://bugs.launchpad.net/epoptes/+bug/1501747
13:03
<lbssousa>
cyberorg, work_alkisg: latest version of my service files are posted at https://bugs.launchpad.net/epoptes/+bug/1447321
13:05
<cyberorg>
lbssousa, are they in https://build.opensuse.org/package/show/server:ltsp/epoptes as well?
13:06
lbssousa, the package needs your love :)
13:08
<lbssousa>
cyberorg: epoptes-client.service is up to date
13:09
cyberorg: in epoptes-server.service, I propose a ExecStartPre stanza to auto generate Epoptes certificate, dropping it from post-install tasks.
13:10
<cyberorg>
lbssousa, feel free to do whatever is needed, you know more about it :)
13:12
btw, I added openssl.cnf due to socat checking commonname, but found that epoptes in bzr has changes to disable that check
13:12
<lbssousa>
cyberorg: sorry, but, after asking my coworkers, we decided to migrate our schools from openSUSE to Debian, so I abdicate epoptes package maintainance in openSUSE:Education.
13:13
<cyberorg>
lbssousa, is https://build.opensuse.org/package/view_file/server:ltsp/epoptes/epoptes-client-auto-reconnect.patch?expand=1 upstreamed?
13:13
lbssousa, ah ok :)
13:14
<lbssousa>
cyberorg: Not yet.
13:15
none of my merge requests in Lauchpad was upstreamed yet.
13:16
<cyberorg>
lbssousa, you have created quite a few patches, ping phantomas and work_alkisg when they are around to get it merged faster
13:17
lbssousa, you can check progress of ltsp on suse from debian server https://sourceforge.net/p/kiwi-ltsp/wiki/Trying%20KIWI-LTSP%20from%20existing%20LTSP%20server/
13:20
<lbssousa>
cyberorg, oh thanks! Currently we don't work with LTSP (due to lack of systemd-logind multi-seat support in LDM, for example), but I wanna try it as soon as possible.
13:21
About auto-reconnect, see my last post at https://bugs.launchpad.net/epoptes/+bug/1011482
13:24
<cyberorg>
lbssousa, we don't use nm on suse client so your patch works better
13:25work_alkisg is now known as alkisg
13:27* alkisg reads the logs...
13:27
<alkisg>
lbssousa: epoptes-client doesn't need a service, it runs from if-up
13:27
The init file is provided only for very old ltsp clients, 5+ years ago, which had a bug and didn't run ifup scripts
13:29
About reconnections, I think that the patch should check for a sigterm in the shell process vs the socat process, not use systemd/loginctl to see the state
13:31
About the epoptes service file, thanks, we'll migrate from sysvinit to systemd in a year or so, when most people will be using systemd
13:31
The sysvinit script still runs fine, doesn't it?
13:32
<cyberorg>
alkisg, we don't use those, see .service files https://build.opensuse.org/package/show/server:ltsp/epoptes
13:33
<alkisg>
cyberorg: why is there an "Epoptes-client service for enabling WOL on %i"? Doesn't ethtool handle that?
13:33
<cyberorg>
if-up is not there in suse, and in ltsp client network is initialized in initrd, there is no nm or any other network service in the client
13:33
<alkisg>
In Debian, ethtool has a configuration file just for that
13:34
cyberorg: opensuse doesn't support sysvinit files?
13:34
Or you selected not to use the one in epoptes?
13:35
<cyberorg>
alkisg, it does, but why use them when we got systemd service files?
13:35
https://build.opensuse.org/package/view_file/server:ltsp/epoptes/epoptes-server.service?expand=1
13:35
<alkisg>
Well, so far we had upstart in ubuntu
13:35
<cyberorg>
so much simpler too :)
13:35
<alkisg>
With the same logic, we wouldn't ship sysvinit files at all
13:35
But compatibility periods exist for a reason
13:36
As long as sysvinit is supported, and not everyone has systemd, there's no reason to have different code paths
13:36
And have to support/troubleshoot both of them
13:36
<lbssousa>
alkisg, cyberorg: that WOL service could be merged with epoptes-client.service as a ExecStartPost stanza.
13:36
<alkisg>
lbssousa: why would WOL go in epoptes?
13:36
That should be a module configuration. In Debian, it's an ethtool configuration option.
13:37
<cyberorg>
alkisg, i mean, now that almost all distros support systemd better to include systemd service files and put sysvinit for legacy/compat purpose
13:37
<alkisg>
cyberorg: there's no LTS ubuntu release yet with systemd support
13:37
When 16.04 is out and tested, the next epoptes releases will drop sysvinit support, sure
13:37
No reason to hurry for that
13:37
<lbssousa>
alkisg: I've just copied it from epoptes-client ifup script (or /etc/init.d script).
13:38
<alkisg>
lbssousa: epoptes-client ifup script is only there for ubuntu 10.04 suport
13:38
It's not used in 10.10+ till now
13:38
Sorry
13:38
I meant the init.d scrpit
13:39
The if-up hook should certainly be there
13:39
systemd doesn't replace ifup, does it?
13:40mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
13:40
<lbssousa>
alkisg, cyberorg: one of them has a ethtool call to enable WOL. If it's not used anymore, that service unit can be dropped as well.
13:40
<alkisg>
WOL and flow control can be done in ltsp or in epoptes startup scripts, but only as workarounds. Their proper place is not there.
13:41
(epoptes uses broadcasting, which benefits from a disabled flow control as much as ltsp; yet vagrantc was reluctunt to allow a flow control script in ltsp)
13:42
!learn epoptes-opensuse-patches as https://build.opensuse.org/package/show/server:ltsp/epoptes
13:42
<ltsp>
The operation succeeded.
13:42
<alkisg>
cyberorg: thanks for the link, we'll look over them to see what can go upstream
13:43
The code rewrite is making the other tasks go slow, though...
13:46myrdd has left IRC (myrdd!~quassel@55d436e3.access.ecotel.net, Remote host closed the connection)
13:51uXus has joined IRC (uXus!~uXus@217.77.222.72)
13:52uXuss has left IRC (uXuss!~uXus@217.77.222.72, Ping timeout: 265 seconds)
14:06uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek)
14:06
<lbssousa>
alkisg: about your remark in auto-reconnect patch, are you referring to something like this? http://veithen.github.io/2014/11/16/sigterm-propagation.html
14:07
<alkisg>
lbssousa: when a session terminates, all processes receive a sigterm signal
14:07
So I believe that both the epoptes-client and the socat process will receive such a signal
14:08
The problem now is that we don't know when to quit. E.g. if socat returns with an error "DNS not found", we need to retry, maybe DNS will be fixed.
14:08
But if the epoptes-client process got a SIGTERM, then we shouldn't try again, the loop should end
14:09
Now, I'm not sure what goes on wrt child processes
14:09
I.e. it's possible that socat will receive the SIGTERM, but not the parent process, because it's spawned a child process and is waiting for it
14:09
That part is specific to shell scripts
14:09
If so, then we may need to put the socat call in the background, and `wait` for it
14:10
I was hoping to get away from all that by doing it properly
14:10
I.e. the epoptes-client service should only connect to the epoptes-root service via a socket, it shouldn't use the network at all, neither should it use socat
14:11
But due to the redesign, those plans are put off for a bit...
14:12
(epoptes-client should be something like session-dbus, while epoptes-root should be something like system-dbus, and epoptes-root should even support multiple epoptes-clients...)
14:14
<lbssousa>
alkisg: I'll try to rewrite my auto-reconnect patch to use that SIGTERM-propagation scheme, rather than explicitly check if logind session is gone.
14:14
<alkisg>
Thanks, if that works, it would be directly upstream-able, it should work for all distros
14:15
Btw, instead of checking for logind, it would be possible to use xprop and check for Xorg
14:16
(assuming that if we no longer have access to xorg, the session has died)
14:16
On the plus side, in our forum, about 10 people have come to complain about epoptes disconnections,
14:17
and they discovered that they had networking issues, with their cabling infrastructure :D
14:17
...so it's not a bug, it's a feature :P :D
14:18
<lbssousa>
It's a very common problem in wireless networks.
14:18
<alkisg>
lbssousa: ah, note also this,
14:18
there's a logic in epoptes that says "if the client can't send us a thumbnail of its screen for 3 times",
14:18
"i.e. 3 * 5 seconds == 15 seconds",
14:19
"that means that it's really really stressed, maybe out of ram, and we should quit epoptes to make it easier for it to recover"
14:19
"so, tell epoptes-client ot exit"
14:19
So it actually tells epoptes-client to run `exit 0`
14:19
If you re-run it at that point, the logic doesn't make sense any more and should be removed
14:20
So the reconnection logic should also take care of exiting when requested
14:21
<lbssousa>
alkisg: thanks for the tip! I'll take a look.
14:21
<alkisg>
lbssousa: thanks for everything, and please don't take it personally that we haven't integrated your patches, it's just because of the very very long redesign
14:22
We appreciate your feedback
14:22
<lbssousa>
alkisg: I know ;-)
14:22
<alkisg>
:)
14:27
<lbssousa>
alkisg: anyway, could you please review at least my shutdown patch for now? My Debian Jessie XFCE refuses to power off without it. https://code.launchpad.net/~oiteam/epoptes/systemd-logind-shutdown/+merge/193897
14:32
<alkisg>
lbssousa: ubuntu wily 15.10 shuts down fine though
14:32
So maybe it's related to XFCE and not to systemd?
14:32
(ubuntu 15.10 uses logind)
14:33
Does systemctl reboot call inhibitors?
14:33
I.e. if you have unsaved changes in LibreOffice, do you get a "Cancel logout" dialog in order for you to continue editing?
14:34
Maybe Epoptes never worked properly in XFCE, and was using console-kit instead of the XFCE dbus call for logout?
14:34
<lbssousa>
It's possible.
14:34
<alkisg>
But if systemd-login does check for inhibitors, then we can put it in any case, even if we also find the xfce dbus call
14:35
Could you check what happens when you have unsaved work?
14:36* alkisg also wonders if it would be appropriate to include a final fallback of `killall -u $USER` :)
14:37
<alkisg>
Sometimes some logout processes just hang, it would be nice for e.g. teachers to be able to kill them by just clicking logout in epoptes a couple of times...
14:37
We could have a variable, TRIED_LOGOUT=False at first, True after the first try, and if the logout button is clicked once more after TRIED_LOGOUT=True, we could fall back to pkills :)
14:38
<lbssousa>
Interesting...
14:39
About inhibitors, I'll check it later.
14:40
<alkisg>
np, please mention the result in the merge request
14:46
<lbssousa>
Another patch I need a lot here is for lock-pointer: https://code.launchpad.net/~oiteam/epoptes/lock-pointer/+merge/251742. It may depend on this one, too: https://code.launchpad.net/~oiteam/epoptes/fix-get-display/+merge/244765
14:50
<alkisg>
lbssousa: I don't get it, afaik x11vnc does have an option to not allow local mouse movements, right?
14:50
Why not just pass it that option?
14:52
Ah, you don't want the pointer to not have any effect, but you want to hide it too?
14:55
Wouldn't "-nocursor" do that?
14:57
<lbssousa>
No, no. I just want to keep my children from moving their mouses while I'm assisting them.
14:58
-grabptr option doesn't do all the work
14:58
<alkisg>
Doesn't it prohibit the clients from moving the mouse?
14:59
Also, not all people want that, I think the default should still be to allow local mouse movement
14:59
<lbssousa>
No. See http://www.karlrunge.com/x11vnc/x11vnc_opts.html
14:59
<alkisg>
E.g. I want to help a student, and he wants to show me something while I'm helping him
14:59
So, some epoptes option should select between these 2 use cases
15:01
lbssousa: so what does grabptr do if it doesn't prohibit mouse input?
15:01
<lbssousa>
Epoptes already has an option to toggle input grabbing (keystrokes/mouse clicks). Are you suggenting another option to toggle mouse movement grabbing as well?
15:02
<alkisg>
He mentions there that grabkbd prohibits keyboard input, and that grabptr is similar to grabkbd but for mouse
15:02
<lbssousa>
grabptr only prohibit mouse clicks, not movoment.
15:03
"Unfortunately due to the way the X server works, the mouse can still be moved around by the user at the physical display, but he will not be able to change window focus with it."
15:07
<alkisg>
I thought that that doesn't interfere with where the teacher clicks/moves
15:07
E.g. if I go to click a menu, and the user moves the mouse all that time, I can't click it? I thought that I could...
15:07
OK I'll check about that. But why are you slowing down the mouse instead of disabling it?
15:08
xinput .. "Device Enabled"... 0?
15:08
Will that make the vnc input stop working too?
16:14Cristian- has joined IRC (Cristian-!cvillegas@186-129-251-218.static.speedy.com.ar)
16:14
<Cristian->
hi everybody
16:15
is it possible to run a command when the user log's out, im using ltsp on ubuntu 14.04 with mate desktop.
16:15
?
16:15
sry for my english, I want to run a script at user logout
16:15
<alkisg>
You can create an /usr/share/ldm/rc.d/Kxx script
16:17
<Cristian->
and it would be able to take some env variables from the user sesion?
16:17
let me explain, i have a script that runs on login and takes some env vars and register the user in a databasa
16:17
<alkisg>
The user session is possible to have crashed at that point, right?
16:18
<Cristian->
i need to delete that register at user logoff
16:18
<alkisg>
The proper way to do these things is with pam
16:18
<Cristian->
dont really know.
16:18
<alkisg>
pam is what takes care of logins, logouts etc
16:19
<Cristian->
I've read something about that, indeed, i was able to achieve this but it was almost 4 years ago and i dont remeber what I did
16:19
ok, so PAM
16:32vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
16:34lbssousa has left IRC (lbssousa!~laercio@179.154.194.17, Quit: lbssousa)
16:47lbssousa has joined IRC (lbssousa!~laercio@179.154.194.17)
17:06
<lbssousa>
alkisg: I didn't know "Device Enabled" before :-) It seems it works, but I cannot test it fully in the moment because I'm experiencing some trouble server-side.
17:06
I'll update my patch when I can test it properly.
17:23* vagrantc keeps thinking to get around to an ltsp update...
17:23
<vagrantc>
and then epoptes this weekend?
17:26
<alkisg>
vagrantc: I think Phantomas still has some things to do with epoptes...
17:28
<vagrantc>
alkisg: phantomas was planning on this weekend, last we talked
17:33* alkisg hopes so, but he's seen many delays to actually expect it so soon :)
17:34
<alkisg>
For LTSP I have a couple of fixes I want to push, but it's not a problem to push them after the release...
17:35
CUPS_SERVER=$SERVER as the default, to make it work again because now we need hostname=server,
17:35
and chmod -x gnome-keyring-daemon to prevent thousands of files being created in .gnome2/keyrings
17:36* vagrantc cringes at the mention of that awful bug
17:36
<alkisg>
Ah, and the ifup fix for systemd poweroff
17:37
Hrm, ok, maybe these 3 should be in the new release
17:37
I can have them ready on sunday or monday
17:37* vagrantc wants to fix the issue introduced with making ltsp-config more noisy when run from ltsp-update-image
17:38
<vagrantc>
or just revert it...
17:38
<alkisg>
Phantomas is good with python but not so much with shell...
17:39
<vagrantc>
it was a very reasonable commit ... just didn't think of all the repercussions.
17:39
nor did i when i merge it :)
17:39
too reasonable to deny
17:45
<alkisg>
/etc/nbd-server/config isn't owned by nbd-server, right? So why would it cause issues on upgrades?
17:47
What was the initial problem, that ltsp-config nbd-server didn't support --overwrite?
17:48
Why would --overwrite be needed there?
17:49* alkisg votes to just revert that one...
18:02
<vagrantc>
it isn't *owned* by nbd-server, but it *is* nbd-server's file to manage.
18:02
it's not registered as a conffile, but it is nbd-server's configuration file.
18:03
alkisg: yes, ltsp-config nbd-server silently ignored overwriting files
18:03
alkisg: more specifically, /etc/nbd-server/conf.d/ltsp*.conf and /etc/nbd-server/conf.d/*swap.conf
18:04
my change was to not mess with nbd-server's managed file
18:04
<alkisg>
vagrantc: who creates that file? only ltsp, right? or also nbd-server postinst?
18:04
<vagrantc>
but still if you run: "ltsp-config nbd-server --overwrite" i would expect it to make appropriate changes to /etc/nbd-server/conf.d/*.conf
18:04
<alkisg>
It ignored them because they were already configured
18:04
We do ship newer lts.conf versions, we haven't yet shipped any new nbd-server configuration file
18:04
<vagrantc>
alkisg: /etc/nbd-server/config isn't the issue i'm worried about.
18:05
<alkisg>
That's why --overwrite didn't make much sense for nbd
18:05
<vagrantc>
alkisg: well, if they're configured wrongly, it should overwrite them as requested...
18:05
alkisg: it shouldn't just silently do nothing
18:06
<alkisg>
E.g. ltsp-config nfs doesn't overwrite the file
18:06
It just edits it
18:06
(/etc/exports)
18:06
overwritting isn't always desirable...
18:06
If for some reason we want it, then ok we should overwrite them, but I don't see much point in it,
18:06
although, why wouldn't we override /etc/nbd-server/config, when it's us that created it...
18:07
So, we'll need another option? --quiet?
18:07
I.e. don't complain if we don't pass overwrite and the files do exist?
18:07
<vagrantc>
the only time ltsp-config should ever create /etc/nbd-server/config is when nbd-server isn't installed, or an *ancient* version is installed
18:08
so ancient that i think we should remove the code that touches /etc/nbd-server/config, personally...
18:08
<alkisg>
OK, nbd-server does have code now that generates it
18:08
Using /usr/share/nbd-server/nbd-server.conf.tmpl as the template
18:08
<vagrantc>
now, as in for the past 5 years or so
18:09
<alkisg>
Agreed, we can completely remove our code that touches nbd-server/config
18:09
In sch-scripts, I have this logic for configuration files:
18:10
I calculate the contents of the file that I want to generate
18:10
If they're the same as the existing file, I do nothing
18:10
If they're different, (and --overwrite is used), then I write the configuration file, restart the service etc
18:10
<vagrantc>
i guess it could check if /etc/nbd-server/config isn't configured, and issue a warning...
18:11
<alkisg>
So, instead of --quiet, we can just check if what we want to write is already there
18:11
<vagrantc>
alkisg: that seems reasonable.
18:21Cristian- has left IRC (Cristian-!cvillegas@186-129-251-218.static.speedy.com.ar, )
18:37
<alkisg>
OK, 1 down, 2 to go...
18:40
http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/2670
18:41Cristian- has joined IRC (Cristian-!cvillegas@186-129-251-218.static.speedy.com.ar)
18:44
<alkisg>
vagrantc: what do you prefer for sed when there are lots of slashes? , or @ ?
18:45gehidore has left IRC (gehidore!~username@unaffiliated/man, Quit: rebooting)
18:45
<vagrantc>
alkisg: i prefer ,
18:45
but i may be odd.
18:45gehidore has joined IRC (gehidore!~username@unaffiliated/man)
18:45
<alkisg>
np, I just want to be consistent :)
18:48
<vagrantc>
alkisg: your cups commit changed some of the logic
18:48
<alkisg>
The bind mounts?
18:48
Or the "if browsing is on..."?
18:48
<vagrantc>
that
18:48
<alkisg>
No worries, I was the one that committed that, and I accept that I was wrong there :)
18:48
First of all now browsing is on by default, it doesn't help
18:49
<vagrantc>
ok.
18:49
<alkisg>
Second, in ltsp-pnp we enable it on the server and it goes to the chroot, thus it doesn't help,
18:49
<vagrantc>
just wanted to make sure it wasn't an oversight.
18:49
<alkisg>
but most importantly, adding new printers is a lot more difficult on fat clients than it is on the server
18:49
Due to drivers etc
18:50
So even if we have printers connected to fat clients, it's easier to publish them with jetpipe to the server and install them there
18:50
(although I'm not sure if ubuntu is using jetpipe, I think the fix hasn't made it to the upstart job...)
18:51uXus has joined IRC (uXus!~uXus@217.77.222.72)
18:55
<Cristian->
hey, do you know why I have to restart tftp after reboot? service start at boot, but it doesnt work
18:56
clients get timeout, but they work ok if service is restarted
18:57
<alkisg>
2 down, 1 to go... http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/2671
18:57
Cristian-: is that tftpd-hpa on ubuntu?
19:00
<vagrantc>
alkisg: using "getent hosts" introduces a DNS delay if it doesn't resolve...
19:00
<alkisg>
vagrantc: ah... I can background it afaik
19:01
Although if LDM_SERVER doesn't resolve, that would be really bad, right?
19:02
<Cristian->
yeo
19:02
<alkisg>
...hmm `getent hosts asdf` is fast for me...
19:02
<Cristian->
in ubuntu
19:02
<alkisg>
Cristian-: tftpd-hpa?
19:02
<Cristian->
yes sir
19:02
<alkisg>
It's broken due to upstart
19:02
You can use dnsmasq if you like
19:02
<vagrantc>
alkisg: it should resolve if it's in /etc/hosts, yes?
19:02
<alkisg>
Or wait for a newer version with systemd
19:02ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat)
19:02
<alkisg>
vagrantc: yes, it checks /etc/hosts first
19:03
I don't know what will happen if it can't contact the dns servers
19:03
Maybe dns timeout...
19:03
<vagrantc>
alkisg: try getent hosts 1.2.3.4
19:03
<alkisg>
I think we can safely background all that though
19:03
It returns instantly for me
19:03
Hmm I do have dnsmasq though
19:03* vagrantc shrugs
19:03
<alkisg>
How much is the delay?
19:04
A couple of seconds, or longer?
19:04
<vagrantc>
a couple seconds
19:04
typical DNS
19:04
<Cristian->
im sorry, im a bit confused between chats
19:04
<alkisg>
Cristian-: when someone writes your name in front, he's speaking with you, until he writes another name in front
19:04
<Cristian->
ok
19:05
long time without using irc
19:05
sry.
19:05
<alkisg>
np
19:05
<vagrantc>
well, people are admittedly lazy sometimes... if there are many conversations i'll usually try to always specify names directly :)
19:07
alkisg: shouldn't we instead install a blank or dummy systemd service in /etc/systemd instead of mangling files in /lib/systemd ?
19:08
<alkisg>
That's a big topic :)
19:08
There will surely be a case where we want to change something that is not overridable in /etc
19:09
We're a special case. We know we're using a cow file system
19:09
The end result can easily be seen by checking the /cow dir
19:09
<vagrantc>
i think systemd is pretty good about respecting /etc, though
19:09
<alkisg>
Also, systemd doesn't ifdown interfaces, that's a bug in debian
19:09
<vagrantc>
in theory i agree, but i'd like to try and avoid mangling anything anywhere it ought not be mangled when possibl
19:09
<alkisg>
And I'm expecting that ExecStop to be deleted in the future
19:10
That's why I also included the =/sbin/ifdown part
19:10
(maybe they'll want to put some special checks, ExecStop=/sbin/our-careful-ifdown)
19:10
When that happens, we will no longer want to override ExecSTop
19:10
So, we should definately check /lib... before writing the /etc/... file
19:11
At that part in my thoughts, I got too complicated and I said to my self, just go ahead and edit it :)
19:11
*it
19:11
The networking sysvinit script, and the upstart script, both respect manual interfaces and don't run ifdown on them
19:12
And pitti said he'll probably do the same for the ExecStop= stanza
19:12
<vagrantc>
alkisg: could easily sed 's,dfggsdfg,#commented by ltsp,g > /etc/systemd/system/ifup...
19:12
<alkisg>
That would generate an identical file without reason, if there's no match
19:13
<vagrantc>
true true...
19:13
<alkisg>
And mkdirs, greps... I don't know it seemed too much... we're ltsp, we can edit whatever we want :P :D
19:13
<vagrantc>
i think that's less bad than mangling a file outside places where files should be mangled
19:13
<alkisg>
We already mangle files in /usr and /lib
19:14
It depends on if we consider ltsp to be a "package", a "sysadmin", or a "patch things that are broken for netbooting" software...
19:14
packages ship in /usr
19:14
sysadmin edits in /etc
19:14
...patching happens everywhere...
19:15* vagrantc would like to consider LTSP to operate by the logic of "least intrusive or unexpected change possible to accomplish the task"
19:16
<alkisg>
Let's move on to the next topic
19:16
It's related :)
19:16
So, gnome-keyring-daemon...
19:16
It broke somewhere after 12.04 and before 14.04
19:16
It's still broken
19:16
<vagrantc>
also exhibited on Debian?
19:16
<alkisg>
I believe so
19:17
Let me see the upstream bug report..
19:17
<vagrantc>
easy to reproduce?
19:17
<alkisg>
https://bugzilla.gnome.org/show_bug.cgi?id=730587
19:17
<vagrantc>
certainly disasterous to reproduce, from the sounds of it
19:17
<alkisg>
Yes, very easy
19:17
The people commenting there seem to all use ubuntu
19:17
It's still broken in 15.10
19:18
So, what I'm thinking is to run gnome-keyring-daemon --version, and if it's a known version, chmod -x it
19:18
Now, tell me about mangling with /usr again... :D
19:18
...or how to do it with /etc...
19:19
<vagrantc>
on debian systems, you could dpkg-divert ...
19:19
but sure, sometimes you have to make intrusive changes.
19:20
<alkisg>
The reason for not editing /usr is that it's supposed to be able to be read-only, right?
19:20
<vagrantc>
that's one reason ...
19:20
<alkisg>
dpkg-divert needs it writeable, it's distro-specific... I don't see its benefits from chmod -x in this case
19:20
ls /cow lists the changes
19:20
We don't need to see the dpkg-divert output and compare the big output there to find out what ltsp did..
19:20
<vagrantc>
and this only applies for sshfs homedirs?
19:21
<alkisg>
Yes, in nfs it works ok
19:21
<vagrantc>
(possibly other wcky filesystems)
19:21
wcky
19:21
wacky.
19:21
<alkisg>
fusebased, probably
19:21* vagrantc glares at the "a" key
19:21
<alkisg>
haha
19:22
Should I put a limit to the upper version of gnome-keyring?
19:22
I'm thinking "no", when we find out that it works again, we'll update ltsp...
19:22
<vagrantc>
so there are a range of versions you know cause the problem...
19:22
<alkisg>
...which isn't fixed yet
19:22
<vagrantc>
in theory it could be fixed in the future... but upstream has been kind of silent
19:22
<alkisg>
And I don't see interested either upstream or in the sshfs mailing list
19:23
I asked miklos about it, no response... maybe he can't do anything about file locks or doesn't want to debug gnome-keyring
19:23
<vagrantc>
we probaly need to move away from sshfs homedirs...
19:23
<alkisg>
In theory, they started using /var/user
19:23
<vagrantc>
but that's the forever lagging LTSP6 future...
19:23
<alkisg>
Which is usually ext*, while $HOME can even be samba now
19:24
<vagrantc>
alkisg: gnome-keyring started using /var/user ?
19:24
<alkisg>
And I think they propose "put all locks etc in /var/user"
19:24
I don't think so yet, no
19:24
<vagrantc>
using homedirs for state is quite stupid, really.
19:24* alkisg apt-get sources keyring...
19:26* vagrantc wonders if roping the debian maintainers into it with a new bug report might stir some interest
19:27
<alkisg>
https://bugzilla.gnome.org/show_bug.cgi?id=613644
19:28
They added support for custom dirs (XDG*)
19:30
That's ~/.local/share... but hmm, also /var/user in ltsp would be sshfs
19:31
So no real way around it other than fixing the keyring code
19:33vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi, Ping timeout: 246 seconds)
19:37
<vagrantc>
how would /var/user be sshfs ?
19:37
<alkisg>
It's still happening on 15.10, but in a new path, ~/.local/share/keyrings
19:38
If it had data for users, we would need to mount it from the server
19:38
...but sorry I misspoken, that would be /run/user, so it's temporary, no need to mount it
19:39
KDE does have something in /var/cache for users though
19:39
<vagrantc>
persistant data? lockfiles seem to only be appropriate to the running system
19:39
<alkisg>
keyrings are persistent
19:39
They do some wcky things when updating them :)
19:40
OK fortunately the keyring issue stops at the first run at 65001 files
19:40
In the second run it continues though :(
19:40
I wonder if they would at least accept a patch about cleaning up their temp files and not trying this forever...
19:40
It can stay broken as long as it doesn't mess up our disks
19:41Cristian- has left IRC (Cristian-!cvillegas@186-129-251-218.static.speedy.com.ar, )
19:42
<alkisg>
vagrantc: about the dns lookup:
19:42
if mkdir -p /etc/cups; then
19:42
CUPS_SERVER=${CUPS_SERVER:-$LDM_SERVER}
19:42
CUPS_SERVER=$({ getent hosts "$CUPS_SERVER" || echo "$CUPS_SERVER";} | awk '{ print $1 }')
19:42
echo "ServerName $CUPS_SERVER" > /etc/cups/client.conf
19:42
fi & # Background it in case DNS lookup takes a long time
19:42
Does that look ok?
19:42* vagrantc forgets where this is running
19:43
<alkisg>
In X01-localapps
19:43
Upon login
19:43
It shouldn't matter if cups.conf is written e.g. 1 m later
19:43vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi)
19:43
<alkisg>
The printers list will be updated then
19:44
<vagrantc>
sounds fine to me then
19:44
<alkisg>
OK, pushing.
19:44
Now about the keyring, I think I"ll only put a lower version bound there
19:44
And only put an upper bound when we know it's been fixed
19:45
<vagrantc>
i guess that's reasonable.
19:45
although i'd be in bad form to upload to debian without reporting a bug in debian on the appropriate packages
19:45
and without verifying in debian
19:45
so that's on my todo list...
19:46
<alkisg>
OK, then I won't commit it yet
19:46
I'll try to spend sunday on sending a patch in keyring
19:46
...who would at least stop after a couple of retries
19:47
If you have a debian bug until then, it will make my case stronger...
19:47
s/who/which/...
19:47
<vagrantc>
go ahead and commit the code, makes it easier for me to verify the issue
19:48
or at least a separate branch
19:49
i can revert it in the debian packaging if i have to...
19:49
<alkisg>
Ah, cyberorg, could you verify that bug in opensuse?
19:49
https://bugzilla.gnome.org/show_bug.cgi?id=730587
19:50
If it's an issue in opensuse, I should push the fix in the common dir, otherwise only in debian
19:50
I'm guessing that all distros would be affected...
19:55
<vagrantc>
whoah. i never did any backports of ltsp for wheezy...
19:57
<alkisg>
vagrantc: I don't know if wheezy is affected or not, I know about gnome 3.2 (not) and 3.10 (yes)
19:57
wheezy has 3.4
19:57
For now I'll put 3.10 in the check, tell me if you need 3.4 instead
19:58* vagrantc was just commenting on the lack of backports
19:59
<vagrantc>
it used to be a big priority for me ... guess it's clear i haven't really been actively maintaining a real-world LTSP environment for a while
19:59
<alkisg>
Version checking in shell: if [ $({ echo '3.10'; gnome-keyring-daemon --version | awk '/gnome-keyring-daemon/ { print $2 }';} | sort -V | head -n 1) = "3.10" ]; then echo needs chmod; fi
19:59
Clearly readable :P :D
19:59
(dpkg --compare-versions isn't available everywhere sadly)
20:00
<vagrantc>
egads.
20:00
very intersting way of implementing it, though
20:08
<alkisg>
OK, that's all from me, eagerly awaiting the new ltsp version now :)
20:09
<vagrantc>
hah
20:09
<quinox>
sort -V <-- oh nice, didn't know that one
20:10lbssousa has left IRC (lbssousa!~laercio@179.154.194.17, Quit: lbssousa)
20:10
<vagrantc>
sort's conceptions of versions aren't always right ... but in many cases it works.
20:20
alkisg: i guess one thing i hadn't thought about was other distros and support of /etc/nbd-server/conf.d/ ... but the ltsp-config code doesn't handle that much
20:34vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi, Ping timeout: 260 seconds)
20:34
<alkisg>
vagrantc: I don't get it, why would other distros be different there?
20:35
And if they were, why wouldn't they submit patches....
20:35
<vagrantc>
that's roughly equivalent to "why doesn't the right thing always happen?" :)
20:36
answer is usually some comination of lazy, foolish and tired
20:39
<alkisg>
nbd-server ships a configuration template...
20:39
If they can't manage that, I'd be inclined to tell them to file a bug against their nbd-server packaging...
20:41* alkisg waves, enough for one day... :)
20:41alkisg is now known as work_alkisg
20:44* vagrantc has seen a lot of people do "disto X doesn't, work, I guess I'll try distro Y ... distro Y doesn't work, I guess I'll try distro Z ..."
20:45
<vagrantc>
"i swear feature Q used to work... oh, maybe that was when i was using distro X ..."
22:26* gehidore swears
22:44
<vagrantc>
ok, ENCRYPT_SWAP=true hangs on Debian stretch, and NFS with overlay FS still doesn't work.
22:44
hrmpf.
22:45
and NFSIMG doesn't work due to lack of implementation in initramfs-tools
22:46* vagrantc sighs
22:49* vagrantc has resisted the switch to NBD for quite some time....
23:17
<maldridge>
vagrantc: come to the dark side!
23:21
<vagrantc>
i mean, i've *used* NBD, but making it the default is a whole different game...
23:28vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
23:29cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 268 seconds)
23:44andygraybeal has joined IRC (andygraybeal!~andy@40.133.169.240)