IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 1 October 2015 (all times are UTC)
| 01:48 | gbaman has left IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk, Remote host closed the connection) | |
| 01:49 | gbaman has joined IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk) | |
| 01:54 | gbaman has left IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk, Ping timeout: 256 seconds) | |
| 02:15 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 02:16 | <fnurl> gbaman you free?
| |
| 02:22 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 272 seconds) | |
| 02:35 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 03:18 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 03:27 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 240 seconds) | |
| 03:50 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 04:24 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 04:33 | gbaman 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:19 | work_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:29 | gbaman 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:36 | gbaman 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:42 | Guest42749 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:45 | ricotz 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:04 | mikkel 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:08 | uXuss 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:09 | uXus 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:25 | khildin has joined IRC (khildin!~khildin@ip-83-134-129-97.dsl.scarlet.be) | |
| 06:31 | myrdd has joined IRC (myrdd!~quassel@55d436e3.access.ecotel.net) | |
| 06:34 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 06:41 | gbaman 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:06 | khildin 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:38 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 07:47 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 260 seconds) | |
| 08:03 | xanthi has joined IRC (xanthi!c23fefeb@gateway/web/freenode/ip.194.63.239.235) | |
| 08:04 | khildin has joined IRC (khildin!~khildin@212-166-61-33.win.be) | |
| 08:08 | <alkisg> xanthi: θες βοήθεια;
| |
| 08:21 | xanthi has left IRC (xanthi!c23fefeb@gateway/web/freenode/ip.194.63.239.235, Quit: Page closed) | |
| 08:44 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 08:52 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 246 seconds) | |
| 09:08 | vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi, Ping timeout: 246 seconds) | |
| 09:20 | vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi) | |
| 09:35 | fenixfunk5 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:49 | gbaman 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:56 | khildin has left IRC (khildin!~khildin@212-166-61-33.win.be, Ping timeout: 265 seconds) | |
| 09:56 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 250 seconds) | |
| 10:04 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 10:09 | khildin has joined IRC (khildin!~khildin@212-166-61-33.win.be) | |
| 10:11 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, ) | |
| 10:12 | fenixfunk5 has left IRC (fenixfunk5!~fenix@mail.lbathivel.com, Quit: Quitte) | |
| 10:50 | alkisg is now known as work_alkisg | |
| 10:53 | khildin has left IRC (khildin!~khildin@212-166-61-33.win.be, Quit: I'm gone, bye bye) | |
| 10:54 | fnurl has left IRC (fnurl!3cf8605f@gateway/web/freenode/ip.60.248.96.95, Ping timeout: 246 seconds) | |
| 11:27 | izzle121 has left IRC (izzle121!~izzle121@70-90-102-229-ma-ne.hfc.comcastbusiness.net, Ping timeout: 240 seconds) | |
| 11:29 | adrianorg has left IRC (adrianorg!~adrianorg@186.213.153.83, Ping timeout: 240 seconds) | |
| 11:31 | adrianorg has joined IRC (adrianorg!~adrianorg@179.182.75.70) | |
| 11:46 | Faith has joined IRC (Faith!~paty_@unaffiliated/faith) | |
| 11:47 | izzle121 has joined IRC (izzle121!~izzle121@70-90-102-229-ma-ne.hfc.comcastbusiness.net) | |
| 12:04 | Faith has left IRC (Faith!~paty_@unaffiliated/faith, Ping timeout: 240 seconds) | |
| 12:05 | Faith has joined IRC (Faith!~paty_@200.144.182.219) | |
| 12:05 | Faith is now known as Guest91580 | |
| 12:23 | izzle121 has left IRC (izzle121!~izzle121@70-90-102-229-ma-ne.hfc.comcastbusiness.net) | |
| 12:35 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
| 12:41 | Guest91580 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:54 | lbssousa 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:25 | work_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:40 | mikkel 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:46 | myrdd has left IRC (myrdd!~quassel@55d436e3.access.ecotel.net, Remote host closed the connection) | |
| 13:51 | uXus has joined IRC (uXus!~uXus@217.77.222.72) | |
| 13:52 | uXuss has left IRC (uXuss!~uXus@217.77.222.72, Ping timeout: 265 seconds) | |
| 14:06 | uXus 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:14 | Cristian- 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:32 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 16:34 | lbssousa has left IRC (lbssousa!~laercio@179.154.194.17, Quit: lbssousa) | |
| 16:47 | lbssousa 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:21 | Cristian- 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:41 | Cristian- 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:45 | gehidore has left IRC (gehidore!~username@unaffiliated/man, Quit: rebooting) | |
| 18:45 | <vagrantc> alkisg: i prefer ,
| |
| 18:45 | but i may be odd.
| |
| 18:45 | gehidore 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:51 | uXus 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:02 | ricotz 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:33 | vmlintu 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:41 | Cristian- 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:43 | vmlintu 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:10 | lbssousa 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:34 | vmlintu 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:41 | alkisg 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:28 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 23:29 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 268 seconds) | |
| 23:44 | andygraybeal has joined IRC (andygraybeal!~andy@40.133.169.240) | |