IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 5 October 2015 (all times are UTC)
| 00:26 | andygraybeal 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:45 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Remote host closed the connection) | |
| 01:56 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 01:58 | work_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:00 | gbaman 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:43 | cyberorg 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:49 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 02:57 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 03:01 | djohnston has left IRC (djohnston!~david@24.224.88.203, Quit: leaving) | |
| 03:03 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 256 seconds) | |
| 03:03 | alkisg is now known as work_alkisg | |
| 04:00 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 04:05 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 265 seconds) | |
| 05:01 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 05:06 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 252 seconds) | |
| 05:09 | work_alkisg is now known as alkisg | |
| 05:30 | vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi) | |
| 05:33 | ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz) | |
| 05:55 | eemeli has left IRC (eemeli!3e94cd0c@gateway/web/freenode/ip.62.148.205.12, Quit: Page closed) | |
| 05:59 | fnurl has joined IRC (fnurl!3cf8605f@gateway/web/freenode/ip.60.248.96.95) | |
| 06:03 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 06:08 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 264 seconds) | |
| 07:05 | mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk) | |
| 07:05 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 07:09 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 240 seconds) | |
| 07:09 | Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net) | |
| 07:20 | gdi2k has joined IRC (gdi2k!~gdi2k@180.190.69.83) | |
| 07:31 | uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek) | |
| 08:30 | uXus has joined IRC (uXus!~uXus@217.77.222.72) | |
| 09:06 | lee has left IRC (lee!~lee@loathe.ms, Ping timeout: 240 seconds) | |
| 09:07 | vervelak has left IRC (vervelak!~vervelak@139.91.248.3, Ping timeout: 246 seconds) | |
| 09:07 | lee has joined IRC (lee!~lee@loathe.ms) | |
| 09:08 | vervelak has joined IRC (vervelak!~vervelak@139.91.248.3) | |
| 09:38 | khildin has joined IRC (khildin!~khildin@ip-62-235-41-6.dial.scarlet.be) | |
| 09:40 | Grembler 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:47 | maven 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:17 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 10:22 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 255 seconds) | |
| 10:35 | lbssousa has joined IRC (lbssousa!~laercio@179.154.212.133) | |
| 10:36 | lbssousa has left IRC (lbssousa!~laercio@179.154.212.133, Client Quit) | |
| 10:37 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 10:46 | lbssousa has joined IRC (lbssousa!~lbssousa@179.154.212.133) | |
| 10:52 | alkisg is now known as work_alkisg | |
| 10:53 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Read error: Connection timed out) | |
| 10:54 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 10:55 | fnurl has left IRC (fnurl!3cf8605f@gateway/web/freenode/ip.60.248.96.95, Ping timeout: 246 seconds) | |
| 11:19 | uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek) | |
| 11:22 | uXus has joined IRC (uXus!~uXus@217.77.222.72) | |
| 11:29 | adrianorg has left IRC (adrianorg!~adrianorg@177.204.77.140.dynamic.adsl.gvt.net.br, Ping timeout: 240 seconds) | |
| 11:31 | adrianorg has joined IRC (adrianorg!~adrianorg@177.204.149.125.dynamic.adsl.gvt.net.br) | |
| 11:45 | yanu has joined IRC (yanu!~yanu@178-116-58-90.access.telenet.be) | |
| 11:46 | yanu has joined IRC (yanu!~yanu@178-116-58-90.access.telenet.be) | |
| 11:59 | Faith has joined IRC (Faith!~paty_@unaffiliated/faith) | |
| 12:10 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Remote host closed the connection) | |
| 12:26 | yanu has left IRC (yanu!~yanu@178-116-58-90.access.telenet.be, Quit: leaving) | |
| 12:27 | yanu has joined IRC (yanu!~yanu@178-116-58-90.access.telenet.be) | |
| 12:31 | Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas) | |
| 12:41 | khildin has left IRC (khildin!~khildin@ip-62-235-41-6.dial.scarlet.be, Ping timeout: 240 seconds) | |
| 13:11 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 13:17 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Remote host closed the connection) | |
| 13:17 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 13:43 | danau111 has joined IRC (danau111!~durban@66.251.57.114) | |
| 13:43 | danau111 has left IRC (danau111!~durban@66.251.57.114) | |
| 13:55 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Remote host closed the connection) | |
| 13:57 | ben_roose has joined IRC (ben_roose!~roose@156.26.10.48) | |
| 13:59 | danau11 has joined IRC (danau11!~durban@66.251.57.114) | |
| 13:59 | danau11 has left IRC (danau11!~durban@66.251.57.114) | |
| 14:08 | mikkel 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:38 | khildin has joined IRC (khildin!~khildin@ip-62-235-41-6.dial.scarlet.be) | |
| 14:58 | Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net) | |
| 15:08 | Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas, Quit: Leaving.) | |
| 15:12 | work_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:15 | gbaman 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:56 | maven 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:37 | khildin has left IRC (khildin!~khildin@ip-62-235-41-6.dial.scarlet.be, Ping timeout: 246 seconds) | |
| 16:39 | khildin has joined IRC (khildin!~khildin@ip-62-235-41-6.dial.scarlet.be) | |
| 16:46 | vagrantc 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:54 | FrozenZia 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:49 | Grembler 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:01 | gbaman 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:20 | gbaman has joined IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk) | |
| 18:52 | grimeton 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:09 | lbssousa has left IRC (lbssousa!~lbssousa@179.154.212.133, Quit: Saindo) | |
| 19:13 | lbssousa has joined IRC (lbssousa!~laercio@179.154.212.133) | |
| 19:28 | lbssousa has left IRC (lbssousa!~laercio@179.154.212.133, Quit: lbssousa) | |
| 19:28 | lbssousa has joined IRC (lbssousa!~laercio@179.154.212.133) | |
| 19:32 | lbssousa has left IRC (lbssousa!~laercio@179.154.212.133, Client Quit) | |
| 19:32 | lbssousa has joined IRC (lbssousa!~laercio@179.154.212.133) | |
| 19:34 | lbssousa has joined IRC (lbssousa!~laercio@179.154.212.133) | |
| 19:37 | lbssousa has left IRC (lbssousa!~laercio@179.154.212.133, Client Quit) | |
| 19:38 | lbssousa has joined IRC (lbssousa!~laercio@179.154.212.133) | |
| 19:43 | gbaman has left IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk, Remote host closed the connection) | |
| 19:44 | vmlintu 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:49 | gbaman has joined IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk) | |
| 19:51 | gbaman_ has joined IRC (gbaman_!~gbaman@dab-ell1-h-20-9.dab.02.net) | |
| 19:51 | gbaman has left IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk, Read error: Connection reset by peer) | |
| 19:52 | gbaman has joined IRC (gbaman!~gbaman@104.40.144.249) | |
| 19:52 | gbaman_ 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:00 | ricotz 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:05 | lbssousa has left IRC (lbssousa!~laercio@179.154.212.133, Quit: lbssousa) | |
| 20:14 | FrozenZia has joined IRC (FrozenZia!pbrown@evo.paivola.fi) | |
| 20:22 | gbaman_ has joined IRC (gbaman_!~gbaman@members.unit1.farsetlabs.org.uk) | |
| 20:26 | alkisg is now known as work_alkisg | |
| 20:26 | gbaman has left IRC (gbaman!~gbaman@104.40.144.249, Ping timeout: 264 seconds) | |
| 20:35 | maxfromparis 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:41 | gbaman_ has left IRC (gbaman_!~gbaman@members.unit1.farsetlabs.org.uk, Remote host closed the connection) | |
| 20:44 | maxfromparis has left IRC (maxfromparis!b0ba7809@gateway/web/freenode/ip.176.186.120.9, Quit: Page closed) | |
| 20:54 | khildin has left IRC (khildin!~khildin@ip-62-235-41-6.dial.scarlet.be, Remote host closed the connection) | |
| 21:01 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 21:23 | Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving) | |
| 21:24 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Remote host closed the connection) | |
| 21:25 | gbaman 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:14 | ben_roose has left IRC (ben_roose!~roose@156.26.10.48, Remote host closed the connection) | |