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


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

00:26andygraybeal has joined IRC (andygraybeal!~andy@40.133.184.123)
01:05
<vagrantc>
work_alkisg: with your update for X.org ... it's a little confusing to what it applies
01:05
work_alkisg: might be easier to switch from using a negated boolean_is_true statement...
01:06
work_alkisg: on ldm ...
01:45gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Remote host closed the connection)
01:56gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
01:58work_alkisg is now known as alkisg
01:58
<alkisg>
vagrantc: is this more readable? https://paste.debian.net/314439/
01:59
I didn't like the nesting very much...
01:59
<vagrantc>
alkisg: that looks *way* better to me...
02:00gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 244 seconds)
02:00* alkisg always uses the other method, but feel free to rewrite it!
02:00
<vagrantc>
alkisg: although using both "; then" and "\nthen" are annoying.
02:00
<alkisg>
I'm using \nthen when the condition spans more than one line
02:00
so that it's separated from the commands that follow
02:01
<vagrantc>
alkisg: given that you've used this new version-checking code in at least two places now, maybe it should be a common function?
02:01
<alkisg>
This is ldm though, can it depend on ltsp common functions?
02:01
(maybe it already does, I don't remember0
02:01
<vagrantc>
depends on where it is in the code
02:02
<alkisg>
boolean_is_true is there... let me check
02:02
<vagrantc>
i think in a screen.d script, we can assume the ltsp functions are there
02:02
since, that's only intended to be used by ltsp
02:03
<alkisg>
it loads /usr/share/ltsp/screen-x-common which loads ltsp-client-functions
02:04
So yup it can be so, although it would require bumping the dependencies
02:04
ldm to depend on ltsp-client >= xxx
02:06
<vagrantc>
sure
02:06
<alkisg>
er, which isn't there at all now
02:06
<vagrantc>
well, technically, that part of LDM requires LTSP, but in theory it could be run standalone
02:06
<alkisg>
Yes, but it won't run with older ltsp versions anymore
02:07
<vagrantc>
can bump the versioned breaks
02:07
<alkisg>
Feel free to commit that, but it involves packaging changes which I'm not comfortable doing, me not being an ltsp maintainer in any distro etc...
02:07
<vagrantc>
probably should be bumped already
02:11
<alkisg>
vagrantc: do you have any release plans for ltsp/ldm/epoptes? Do I have more time for more commits before that?
02:14
<vagrantc>
didn't get much time to work on it this weekend
02:14
but was planning on diving in tomorrow
02:14
alkisg: and my days end later than yours :)
02:15
<alkisg>
Cool
02:15
There is one problem that I'm not sure how to handle
02:16
<vagrantc>
alkisg: i would love to get them uploaded in roughly 24 hours...
02:16
<alkisg>
Teachers here set LDM_AUTOLOGIN=true globally, then define LDM_USERNAME and password under [macs]
02:16
<vagrantc>
but i don't know if it's realistic
02:16
<alkisg>
So for new PCs that don't have [mac] sections, this causes a login/fail loop
02:16
<vagrantc>
ah, right.
02:16
<alkisg>
I was thinking of: unset LDM_AUTOLOGIN if LDM_USERNAME and passwords are unset, and hostname starts with ltsp*,
02:17
...but I think that edubuntu uses that case, creating multiple ltsp* users?
02:17
<vagrantc>
that may be a legitimate configuration
02:17
<alkisg>
for all the subnet...
02:17
<vagrantc>
right
02:17
<alkisg>
So maybe edubuntu and other users of that case, could at least set an lts.conf with a common LDM_PASSWORD for all?
02:18* vagrantc only uses ssh keys
02:18
<alkisg>
or, if LDM_AUTOLOGIN is true, and it fails, then it could be unset in the second time?
02:18
highvoltage, stgraber: how does that ^ sound? Will it break any existing use cases?
02:18
<vagrantc>
or at least providing the user with some information about why it failed, and stopping
02:19
<alkisg>
I don't know if I can easily detect why autologin failed though
02:19
<vagrantc>
rather than unsetting LDM_AUTOLOGIN, it could present something on the screen that the autologin failed
02:19
timing?
02:20
<alkisg>
I've seen logins/logouts needing more than 30 seconds
02:20
<vagrantc>
with the autologin failure case, the start of autologin to the end of autologin would most likeyl be very brief
02:20
<alkisg>
...and it would be possible to do a legitimate login/logout test faster than that...
02:21
<vagrantc>
but what about legitimate logins that lasted only 1 second?
02:21
<alkisg>
I think checking if ssh authentication succeeded is less error prone
02:21
<vagrantc>
yes
02:21
there's the check for the SENTINEL
02:22
<alkisg>
bash can grep through /var/log/ldm, but I think that it should better be inside the .c code
02:22
...hence my hesitation :)
02:23
So I was thinking that we could document that LDM_AUTOLOGIN needs LDM_PASSWORD to be set at all times
02:23
<vagrantc>
yes.
02:23
meh.
02:23* vagrantc has used LDM_AUTOLOGIN with no password
02:23
<vagrantc>
totally legitimate configuration
02:24
<alkisg>
ssh keys, hmm, right
02:24
Btw, I didn't find where LDM_USERNAME and LDM_PASSWORD are set to default to HOSTNAME
02:24
<vagrantc>
in the c code, it might not be too hard to behave differently in the case of a login failure when LDM_AUTOLOGIN is set
02:24
<alkisg>
That would be the proper place, true...
02:25
<vagrantc>
alkisg: it defaults to hostname...
02:25
<alkisg>
what part of the code does that?
02:25
ldm.c?
02:26
<vagrantc>
src/plugins/ssh/ssh.c
02:27
get_guest function
02:28
if (!sshinfo->username) {
02:28
gchar hostname[HOST_NAME_MAX + 1]; /* +1 for \0 terminator */
02:28
gethostname(hostname, sizeof hostname);
02:28
sshinfo->username = g_strdup(hostname);
02:28
<alkisg>
OK got it
02:29
Here's a thought, bash could assume that the authentication did not succeed, and then one rc.d/S* script can mark that it did succeed
02:29
It could use an xprop or temp file or `set_lts_var` for that
02:30
<vagrantc>
alkisg: why not just fix it where it should be fixed?
02:30
<alkisg>
Is the ssh plugin able to draw in the xorg screen?
02:31* alkisg hates dealing with ldm.c, ssh.c etc :)
02:31
<alkisg>
I think it'd be way easier to write the greeter in python and ldm in shell :D
02:32
We're already launching python, it wouldn't need more time or ram... anyway, ltsp6 ahead etc etc
02:33
<vagrantc>
yes, every time i fix anything in LDM i kind sigh a long sigh
02:34
alkisg: to workaround the problem, why don't the schools only set LDM_AUTOLOGIN in the mac-defined section in lts.conf?
02:35
or fix it at the end of the ssh_chat function in src/plugins/ssh/ssh.c
02:35
set something that then pops up an ldm-dialog or something
02:38
<alkisg>
There are 3 different messages there
02:38
It would be difficult to decide if the problem is due to autologin or due to LDM_SERVER pointing to a non-existing dns value
02:40
We could change our example lts.conf so that LDM_AUTOLOGIN and LDM_GUESTLOGIN are only set under [mac] sections
02:40
(upstream in ltsp)
02:40
<vagrantc>
but when autologin is set, you don't have to tell them *why* it didn't work, just tell them that AUTOLOGIN failed
02:40
it doesn't matter why autologin failed, retrying repeatedly isn't a good default...
02:41
or at least ldm-dialog with a 30 second timeout or something
02:41
<alkisg>
With a set_message? at that point, the greeter exits, people don't have much time to see the message there
02:41
<vagrantc>
could tell them the username and servername it attempted to connect to
02:41
there's no greeter with autologin
02:42
with guest login there's a greeter
02:42
<alkisg>
That's true... then set_message there is worthless with autologin, people don't see it at all
02:43
<vagrantc>
right, which is why you'd need to call ldm-dialog or something
02:43cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
02:43
<alkisg>
vagrantc: when you're using autologin with keys, what do you define on a per-mac basis?
02:43
<vagrantc>
alkisg: nothing.
02:44
<alkisg>
They're all using the same user account?
02:44
Or are you creating 255 users, for ltsp*?
02:44
<vagrantc>
alkisg: they're using the autogenerated hostname
02:44
alkisg: yes, create all the potential users for a subnet
02:45* vagrantc wouldn't try that with a class C ...
02:45
<alkisg>
How about if we required the use of HOSTNAME_BASE in that use case?
02:45
HOSTNAME_BASE=guest, anything at all except for unset...
02:45* vagrantc doesn't see the need
02:47
<alkisg>
Suppose I don't want to use lts.conf mac sections at all, but dns entries. So, I'm sending pcXX with dnsmasq to all known clients. For unknown clients, I don't want them to even try to autologin and show a message.
02:47
<vagrantc>
it seems like a bug to me that LDM_AUTOLOGIN repeatedly retries indefinitely with no feedback to the user ... proposing to require various things that shouldn't be required seems like a poor workaround.
02:47
<alkisg>
So basically what I'm asking for is an LDM_AUTOLOGIN=smart/auto option
02:48
To only enable itself based on some conditions
02:48
The xorg loop and message is related, but not exactly what I'm asking for
02:48
<vagrantc>
this is where a hook in ltsp_config.d would work...
02:49
<alkisg>
Right, and I'm trying to see if it can go upstream
02:49* vagrantc has to head to dinner
02:49* alkisg waves :)
02:49vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
02:57gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
03:01djohnston has left IRC (djohnston!~david@24.224.88.203, Quit: leaving)
03:03gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 256 seconds)
03:03alkisg is now known as work_alkisg
04:00gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
04:05gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 265 seconds)
05:01gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
05:06gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 252 seconds)
05:09work_alkisg is now known as alkisg
05:30vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi)
05:33ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)
05:55eemeli has left IRC (eemeli!3e94cd0c@gateway/web/freenode/ip.62.148.205.12, Quit: Page closed)
05:59fnurl has joined IRC (fnurl!3cf8605f@gateway/web/freenode/ip.60.248.96.95)
06:03gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
06:08gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 264 seconds)
07:05mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
07:05gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
07:09gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 240 seconds)
07:09Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net)
07:20gdi2k has joined IRC (gdi2k!~gdi2k@180.190.69.83)
07:31uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek)
08:30uXus has joined IRC (uXus!~uXus@217.77.222.72)
09:06lee has left IRC (lee!~lee@loathe.ms, Ping timeout: 240 seconds)
09:07vervelak has left IRC (vervelak!~vervelak@139.91.248.3, Ping timeout: 246 seconds)
09:07lee has joined IRC (lee!~lee@loathe.ms)
09:08vervelak has joined IRC (vervelak!~vervelak@139.91.248.3)
09:38khildin has joined IRC (khildin!~khildin@ip-62-235-41-6.dial.scarlet.be)
09:40Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Quit: I Leave)
09:41
<alkisg>
gdi2k: can you please file a bug report for chmod +r not working?
09:41
And that it should be a+r to accomodate for when umask=0077?
09:41
!ltsp-bug
09:41
<ltsp>
ltsp-bug: To file a bug report for upstream LTSP, go to https://bugs.launchpad.net/ltsp
09:44
<gdi2k>
https://bugs.launchpad.net/ltsp/+bug/1502824
09:47maven has joined IRC (maven!d53a91ed@gateway/web/freenode/ip.213.58.145.237)
09:47
<alkisg>
gdi2k: ok, fix committed
09:48
3.5 minutes, not bad... :D
10:10
!ssh-keys
10:10
<ltsp>
I do not know about 'ssh-keys', but I do know about these similar topics: 'sshkeys'
10:10
<alkisg>
!sshkeys
10:10
<ltsp>
sshkeys: If you changed your LTSP server IP on Ubuntu, your clients will be unable to login. To fix this, you need to run: sudo ltsp-update-sshkeys && sudo ltsp-update-image
10:10
<alkisg>
nah
10:11
!ssh_known_hosts
10:11
<ltsp>
Error: "ssh_known_hosts" is not a valid command.
10:17gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
10:22gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 255 seconds)
10:35lbssousa has joined IRC (lbssousa!~laercio@179.154.212.133)
10:36lbssousa has left IRC (lbssousa!~laercio@179.154.212.133, Client Quit)
10:37gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
10:46lbssousa has joined IRC (lbssousa!~lbssousa@179.154.212.133)
10:52alkisg is now known as work_alkisg
10:53gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Read error: Connection timed out)
10:54gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
10:55fnurl has left IRC (fnurl!3cf8605f@gateway/web/freenode/ip.60.248.96.95, Ping timeout: 246 seconds)
11:19uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek)
11:22uXus has joined IRC (uXus!~uXus@217.77.222.72)
11:29adrianorg has left IRC (adrianorg!~adrianorg@177.204.77.140.dynamic.adsl.gvt.net.br, Ping timeout: 240 seconds)
11:31adrianorg has joined IRC (adrianorg!~adrianorg@177.204.149.125.dynamic.adsl.gvt.net.br)
11:45yanu has joined IRC (yanu!~yanu@178-116-58-90.access.telenet.be)
11:46yanu has joined IRC (yanu!~yanu@178-116-58-90.access.telenet.be)
11:59Faith has joined IRC (Faith!~paty_@unaffiliated/faith)
12:10cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Remote host closed the connection)
12:26yanu has left IRC (yanu!~yanu@178-116-58-90.access.telenet.be, Quit: leaving)
12:27yanu has joined IRC (yanu!~yanu@178-116-58-90.access.telenet.be)
12:31Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
12:41khildin has left IRC (khildin!~khildin@ip-62-235-41-6.dial.scarlet.be, Ping timeout: 240 seconds)
13:11cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
13:17cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Remote host closed the connection)
13:17cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
13:43danau111 has joined IRC (danau111!~durban@66.251.57.114)
13:43danau111 has left IRC (danau111!~durban@66.251.57.114)
13:55gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Remote host closed the connection)
13:57ben_roose has joined IRC (ben_roose!~roose@156.26.10.48)
13:59danau11 has joined IRC (danau11!~durban@66.251.57.114)
13:59danau11 has left IRC (danau11!~durban@66.251.57.114)
14:08mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
14:21
<lbssousa>
work_alkisg, Phantomas, I'm searching for an alternative solution for auto-reconnecting in Epoptes without need to hack epoptes-client code. I've found a relatively simple solution (at least for the system epoptes-client instance):
14:22
I've installed and configured ifplugd in my Debian system (alternatively I could use Network Manager dispatcher scripts).
14:23
The only missing part is a if-down script that kills socat instance launched by if-up script.
14:29
For user instance, we may need a wrapper script around epoptes-client.
14:38khildin has joined IRC (khildin!~khildin@ip-62-235-41-6.dial.scarlet.be)
14:58Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net)
15:08Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas, Quit: Leaving.)
15:12work_alkisg is now known as alkisg
15:12
<alkisg>
lbssousa: epoptes-client cleans up its previous instances
15:12
and it already runs from if-up
15:12
So if you unplug the network cable and then re-plug it, it will run a new instance
15:15gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
15:32
<lbssousa>
alkisg, in my tests, if I disconnect from network, current socat instance keeps running, and if I reconnect, that socat instance is terminated, but the new instance fails to start.
15:33
However, if I manually kill socat before reconnecting, the new instance starts properly.
15:36
<maldridge>
when you guys use cups in a lab, do you have the clients printing back to a central print server, or to the printer directly?
15:40
<alkisg>
lbssousa: if you re-run epoptes-client without disconnecting, does it kill the previous epoptes+socats?
15:40
maldridge: so far we were using the normal cups way, i.e. all clients running cupsd locally and seeing all printers and printing to them directly,
15:41
<maldridge>
alkisg: ah, so you guys don't use any centralized billing?
15:41
<alkisg>
but we saw that it was difficult to install printers under ltsp, when the drivers need to be manually installed
15:41
so we are now trying to use jetpipe + manage everything from the server
15:41
I.e. the classic ltsp method
15:41
<maldridge>
ha, fair; that is reasonably fast? I am seeing massive slowdowns running cups on both ends
15:42
<alkisg>
We solved a couple of printing related bugs in ltsp recently, I don't know if you have them or need them
15:42
I don't have more info than "tested a few pages and it worked fast"
15:43
I've set it up that way in 3-4 schools, they didn't complain so far..
15:43
<maldridge>
fair, I'll test that and see if it improves the print times. currently taking >30 seconds to spool a job
15:44
<alkisg>
job size, network speed?
15:45
<maldridge>
looking at a 19M job spooled currently, gigabit network
15:45
really curious how that job wound up that big
15:45
<alkisg>
and how long does the same job need to be spooled in a local printer?
15:46
an uncompressed image of 5000x5000x32bpp needs 100 MB
15:46
<maldridge>
well, to the same network printer but bypassing the central print server it takes ~4 seconds to spool and begin printing
15:47
<alkisg>
Are you sure you don't have any flow control issues? No 100mbps devices on your network?
15:50
<maldridge>
very sure, its a reasonably small network, and I can iperf end to end at the speed I expect
15:51
<alkisg>
Sounds like you need to ask in #cups then...
15:54
<maldridge>
yeah, just figured I'd ask here first. schools seem to breed wierd technology issues
15:56maven has left IRC (maven!d53a91ed@gateway/web/freenode/ip.213.58.145.237, Quit: Page closed)
16:22
<alkisg>
lbssousa: https://bugs.launchpad.net/epoptes/+bug/980141 about multiseat and systemd-logind, what's the current status?
16:22
does it work out of the box? what is missing from the epoptes side?
16:37khildin has left IRC (khildin!~khildin@ip-62-235-41-6.dial.scarlet.be, Ping timeout: 246 seconds)
16:39khildin has joined IRC (khildin!~khildin@ip-62-235-41-6.dial.scarlet.be)
16:46vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
16:50
<lbssousa>
alkisg, about multi-seat support in epoptes, I say it works almost out-of-box.
16:51
The main missing part (which would make other things easier) is the ability of a single system epoptes-client daemon can handle multiple displays.
16:53
It could talk to systemd-logind to get current seat list, current sessions open for each seat, and corresponding displays.
16:54FrozenZia has left IRC (FrozenZia!pbrown@evo.paivola.fi, Ping timeout: 250 seconds)
16:54
<alkisg>
I'm trying to convince phantomas of a new design that would work without even needing to know about seats :)
16:55
a single root epoptes client, and multiple user epoptes clients connecting via a socket (like reverse connections) to the root epoptes client
16:55
<lbssousa>
Meanwhile, there's a workaround needed to make broadcasting work properly in multi-seats.
16:55
<alkisg>
in logind multiseats?
16:56
<lbssousa>
replace that EM_SYSTEM_OR_SESSION occurence with EM_SESSION_OR_SYSTEM in epoptes/ui/gui.py.
16:56* alkisg was looking at the 2 bugs you filed about multiseat, to see if something could be committed now for the upcoming epoptes release
16:56
<alkisg>
No that can't be done unconditionally...
16:56
It will hurt thin client performance a whole lot
16:57
<lbssousa>
If system epoptes-client daemon could handle multiple displays, that change wouldn't be necessary.
16:58
<alkisg>
The system epoptes client can't know about x2go etc
16:58
The multiseat is only one use case, there's ltsp, x2go and a lot of others
16:58
All of them can be handled without any special casing at all with that new design
16:59
<lbssousa>
It would also allow access to each seat's login screen via VNC.
17:00
<alkisg>
That's easy, you just put epoptes-client in the gdm/lightdm autostarted things
17:01
<lbssousa>
Have you seen my fix-get-display branch? Would you think it's important?
17:03
<alkisg>
for p in $(pgrep -x 'ldm|gdmgreeter|kdm_greet|lxdm-greeter-gt|dbus-daemon'); do
17:03
you just need to add one process there
17:04
the ck-list-sessions part can be replaced with the logind part though, np with that
17:08
Btw, in which environment dbus-daemon doesn't contain the path to xauthority?
17:08
xfce?
17:09
I thought I tried xubuntu and it worked there at some point...
17:10
lbssousa: at first, try to find simple reproducable cases where epoptes fails, instead of sending pathes
17:10
*patches
17:11
E.g. if I can see epoptes failing to get xauthority in the latest kde, I could then probably find a small patch to fix that...
17:24
vagrantc: the if-up systemd bug was fixed in http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=7b9a61f1
17:25
So if you're saying that jessie is not affected, I'm inclined to revert it from ltsp; only 15.04 is affected, and it has a broken ltsp anyway there, without many chances for a backport
17:26
(there's a debian bug report for this there though)
17:31
<vagrantc>
alkisg: i haven't seen it on jessie
17:32
<alkisg>
Cool, reverting..
17:32
<vagrantc>
alkisg: the issue is NBD hanging on shutdown?
17:33
because it brings the interfaces down?
17:34
<alkisg>
vagrantc: yes, but the debian bug report was filed for nfs
17:34* vagrantc should also check with stretch
17:34
<alkisg>
stretch will get the fix
17:34
No need to check there
17:34
<vagrantc>
fixed in systemd?
17:34
<alkisg>
Yes
17:35
(in the debian packaging, it was a debian-specific bug)
17:43
vagrantc: let me try to make a final attempt to persuade you about LDM_AUTOLOGIN etc... :)
17:43
What I want is to allow someone to say "enable autologin in all known clients". It's not some weird request, e.g. dnsmasq supports it with the !known tag. I don't think we'll argue that this is useful.
17:43
I think we argue about what is a "known client". For me, known == specific hostname, other than ltspXXX.
17:43
And of course it should always work if both LDM_USERNAME and LDM_PASSWORD are set and not assumed to be =hostname.
17:43
The problem is that it breaks yours, and edubuntu's, use case. I think that the best solution here would be for your and ltsp to use HOSTNAME_BASE=something different than the default, which will mean that you have a user for any autogenerated hostname there.
17:44
I really think that is the most logical way to implement it, but if you don't like it, I could work around it for greek users in sch-scripts and ignore global ltsp users...
17:45
s/for your and ltsp/for you and edubuntu/
17:45
<vagrantc>
i only disagree for two reasons, it doesn't solve the *real* problem, and it breaks existing configuration....
17:46
<alkisg>
I'm asking for a feature. You're saying that the real problem is some related LDM bug, but it's not the feature I'm asking for.
17:46
<vagrantc>
the real problem is that autologin respawns repeatedly with no user feedback when it's not working
17:46
<alkisg>
There's no existing configuration broken in edubuntu live CDs. Newer live CDs will just use the newer way.
17:46
There's no apt-get update for already burned live cds...
17:46
No, this is not the real problem
17:47
I want to be able to put a laptop in a classroom without having to specify an autologin name there
17:47
And I don't want to put [mac] sections in lts.conf at all
17:47
<vagrantc>
ok, now we're getting somewhere
17:48
<alkisg>
(that laptop will just show ldm without autologin and without guest login)
17:48
<vagrantc>
so, what is "known" from an ltsp perspective without lts.conf configuration?
17:48
<alkisg>
I assume that I've sent the correct hostname somehow. Let's say with dnsmasq.
17:49
So in this case, "known" == not automatically generated hostname.
17:49
<vagrantc>
how about a regexp that maches known hostnames?
17:49Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Remote host closed the connection)
17:49
<alkisg>
I thought about it, it does the trick, but it doesn't help users that already have that issue
17:49
<vagrantc>
keeps old behavior, creates a one-line configuration for your goal...
17:49
<alkisg>
They'll need to read up and modify their lts..conf
17:50
I'll accept such a solution though if you don't like my preferred ^ one
17:50
<vagrantc>
as opposed to users that will need to read up and modify their lts.conf on upgrading to a new behavior
17:50
<alkisg>
Do you think that there are others that have all users defined for their subnet?
17:51
I'm sure that there are several teachers that do call me for support when they put new clients and have xorg loops...
17:51
:)
17:52
<vagrantc>
well, i made several posts documenting such a configuration to ltsp-discuss over the years
17:52
<alkisg>
(edubuntu only does that in the live cd demo, never in the installed system - and existing live cds surely won't break with upgrades)
17:52
<vagrantc>
i've even met people who implemented them later
17:53
<alkisg>
OK, understood
17:53
So, something like LDM_KNOWN_HOSTS="pc*" ?
17:54
<vagrantc>
alkisg: that's more-or-less what i was thinking
17:54
alkisg: could it also support LDM_KNOWN_HOSTS="student*|staff*"
17:54
?
17:55
<alkisg>
And document that if LDM_[AUTO|GUEST]LOGIN=True , and LDM_USERNAME="", and LDM_PASSWORD="", then autologin will be cancelled unless LDM_KNOWN_HOSTS matches the hostname?
17:55
<vagrantc>
or "student* staff*"
17:55
or LDM_KNOWN_HOSTS is unset
17:55
er, uh...
17:55
<alkisg>
Why just not specify that it needs to be different than the default "ltsp*"?
17:56
<vagrantc>
because that's a behavior changing new requirement
17:57
<alkisg>
So LDM_KNOWN_HOSTS will default to ltsp* to keep the existing implementation working?
17:58
<vagrantc>
that could work, sure
17:58
well, no
17:58
because the existing implementation would default to "*"
17:58
<alkisg>
Or do you think there are implementations that have LDM_AUTOLOGIN=True, all users defined, _and_ they have changed the HOSTNAME_BASE/?
17:58
Ah
17:59
<vagrantc>
there is(was) at least one network i was maintaining where some networks used HOSTNAME_BASE, and some didn't.
17:59
all supported GUESTLOGIN (with a few random AUTOLOGIN)
18:00
<alkisg>
Cool, I'll upload an implementation in 2 days and you can patch it if you find anything not to your liking (or any bugs) :)
18:00
Thank you vagrantc, as always!
18:01gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Remote host closed the connection)
18:03
<vagrantc>
alkisg: same to you! :)
18:05
<alkisg>
vagrantc: you wouldn't like a new LDM_AUTOLOGIN=known which wouldn't break existing setups, would you? I think you don't like to mix "booleans" with "strings"...
18:06
<vagrantc>
yeah, i prefer to keep booleans boolean.
18:06
<alkisg>
OK
18:06
<lbssousa>
alkisg, I've reverted partially my fix-get-display branch. I'm keeping loginctl part, but I've removed that GDM/KDE custom paths part. I can't assure they're still needed.
18:06
<alkisg>
lbssousa: is the loginctrl part needed?
18:06
In which DE?
18:07
AFAIK, all modern DEs should have dbus-daemon inside the user session...
18:07
<lbssousa>
Hmm...
18:08
If logitctl fallback isn't needed,
18:08* alkisg is postponing the move to systemd until an ubuntu lts release fully supports systemd
18:13
<lbssousa>
OK. I've just proposed it as an analogous to ck-list-sessions fallback. Remember that Ubuntu Trusty does support logind (although not systemd at all). I'm not familiar with CK-logind coexistence in Trusty.
18:15
btw, did you cancel 0.5.8 release?
18:15
<alkisg>
Only for a few days, phantomas has a few extra fixes that I was not aware of
18:15
*had
18:15
<lbssousa>
Ah, OK.
18:15
<alkisg>
Trusty does have systemd-logind, but not systemd
18:15
So we can't have the sysvinit => systemd move yet
18:17
consolekit doesn't exist in trusty, yup, that code path is never executed there (but it shouldn't be needed except for some weird fltk sessions or so)
18:20gbaman has joined IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk)
18:52grimeton has joined IRC (grimeton!~ruth@2a01:4f8:160:41e3:0:dead:beef:cafe)
18:52
<grimeton>
hi
18:52
<alkisg>
Hello
18:52
<grimeton>
is there a way to keep a session alive if a user disconnects, e.g. the client crashes or something like that?
18:53
<alkisg>
Not with plain X windows, you need something like x2go or some x proxy or vnc
18:53
<grimeton>
is there a prefered way that works best with ltsp?
18:54
<alkisg>
No, ltsp doesn't have any integration for that, it's up to the user to set it up
18:54
And of course you'll lose a lot of performance
18:55
<grimeton>
yeah i know ...
18:56
ok, thanks, i'll look into it
18:57
<alkisg>
np
19:09lbssousa has left IRC (lbssousa!~lbssousa@179.154.212.133, Quit: Saindo)
19:13lbssousa has joined IRC (lbssousa!~laercio@179.154.212.133)
19:28lbssousa has left IRC (lbssousa!~laercio@179.154.212.133, Quit: lbssousa)
19:28lbssousa has joined IRC (lbssousa!~laercio@179.154.212.133)
19:32lbssousa has left IRC (lbssousa!~laercio@179.154.212.133, Client Quit)
19:32lbssousa has joined IRC (lbssousa!~laercio@179.154.212.133)
19:34lbssousa has joined IRC (lbssousa!~laercio@179.154.212.133)
19:37lbssousa has left IRC (lbssousa!~laercio@179.154.212.133, Client Quit)
19:38lbssousa has joined IRC (lbssousa!~laercio@179.154.212.133)
19:43gbaman has left IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk, Remote host closed the connection)
19:44vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi, Ping timeout: 265 seconds)
19:47
<vagrantc>
grimeton: the RDP support in LDM does allow session reconnections, but you loose some other features
19:47
grimeton: with xrdp
19:49gbaman has joined IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk)
19:51gbaman_ has joined IRC (gbaman_!~gbaman@dab-ell1-h-20-9.dab.02.net)
19:51gbaman has left IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk, Read error: Connection reset by peer)
19:52gbaman has joined IRC (gbaman!~gbaman@104.40.144.249)
19:52gbaman_ has left IRC (gbaman_!~gbaman@dab-ell1-h-20-9.dab.02.net, Remote host closed the connection)
19:54
<lbssousa>
alkisg, I've just realized that ifplugd-like approach deosn't solve all of my problems with epoptes-client auto-reconnection. In particular, it just doesn't work if I simply reboot my server.
19:55
I've just updated my auto-reconnect branch with latest changes following your advice.
19:56
<alkisg>
lbssousa: does your branch work correctly with logouts? does epoptes-client exit properly then?
19:56
<lbssousa>
Yes!
19:59
<alkisg>
So you put an xprop or similar test? could you give me the branch link again?
20:00ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat)
20:00
<alkisg>
https://code.launchpad.net/~epoptes/epoptes/trunk/+activereviews
20:05
<lbssousa>
Merge request re-proposed. I need to go now. Talk to you tomorrow!
20:05lbssousa has left IRC (lbssousa!~laercio@179.154.212.133, Quit: lbssousa)
20:14FrozenZia has joined IRC (FrozenZia!pbrown@evo.paivola.fi)
20:22gbaman_ has joined IRC (gbaman_!~gbaman@members.unit1.farsetlabs.org.uk)
20:26alkisg is now known as work_alkisg
20:26gbaman has left IRC (gbaman!~gbaman@104.40.144.249, Ping timeout: 264 seconds)
20:35maxfromparis has joined IRC (maxfromparis!b0ba7809@gateway/web/freenode/ip.176.186.120.9)
20:35
<maxfromparis>
help !
20:36
my client has a pxe connection, but no transfer
20:41gbaman_ has left IRC (gbaman_!~gbaman@members.unit1.farsetlabs.org.uk, Remote host closed the connection)
20:44maxfromparis has left IRC (maxfromparis!b0ba7809@gateway/web/freenode/ip.176.186.120.9, Quit: Page closed)
20:54khildin has left IRC (khildin!~khildin@ip-62-235-41-6.dial.scarlet.be, Remote host closed the connection)
21:01gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
21:23Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving)
21:24gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Remote host closed the connection)
21:25gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net)
22:37
<vagrantc>
well, maxfromparis, first thing to do is hang around in irc longer ...
23:14ben_roose has left IRC (ben_roose!~roose@156.26.10.48, Remote host closed the connection)