02:10 | GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 246 seconds) | |
02:17 | GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com) | |
03:36 | GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Quit: Ex-Chat) | |
03:36 | GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com) | |
03:45 | nek has joined IRC (nek!9d13686b@gateway/web/freenode/ip.157.19.104.107) | |
03:45 | <nek> hi
| |
03:45 | nek is now known as Guest45623 | |
03:46 | <sbalneav> Hello
| |
03:46 | <Guest45623> Hi sbalneav
| |
03:47 | Can I ask about my trouble here?
| |
03:47 | <sbalneav> Yes
| |
03:48 | <Guest45623> Now I try to construct LTSP Server on Ubuntu 16.04
| |
03:48 | And I could install ltsp-server.
| |
03:49 | But I had the error when "ltsp-build-client" for fat client was done.
| |
03:49 | <sbalneav> What was the error
| |
03:50 | <Guest45623> The hash sum of some packages mismatch and stopped...
| |
03:50 | I can find these packages on http://archive.ubuntu.com/.....
| |
03:50 | <sbalneav> Try rebuilding it. Sounds like some packages may have updated on the server while you were building.
| |
03:51 | <Guest45623> Ok. I would!
| |
03:52 | Now I run. Until now, I tried to rebuild over 5 times on Ubuntu Desktop 16.04 and over 3 times on Ubuntu Server 16.04....
| |
03:55 | Usually, can people build fat client on ubuntu 16.04 without errors ?]
| |
03:56 | <sbalneav> I use debian personally, but I'd assume so
| |
03:59 | <Guest45623> I don't have any knowledge about the relation between server and client. If use debian, what version of client will be ?
| |
04:01 | <sbalneav> debian
| |
04:01 | Jessie. That's what I use
| |
04:02 | <Guest45623> Oh, ...ltsp-build-client stopped... Perhaps, around ldm-ubuntu-theme. For setting ldm-ubuntu-theme(2:2.0.47), ltsp-build-client tried to read package list, and read information about dependency and failed to find packeges...
| |
04:03 | Is server debian Jessi? So what is client? Ubuntu? Ubuntu mate?
| |
04:03 | <sbalneav> Jessie
| |
04:03 | Both the server and client are debian jessie
| |
04:03 | <Guest45623> Oh, both
| |
04:04 | Ok, I understood... Is there way to use ubuntu 16.04 as client...?
| |
04:05 | <sbalneav> Not that I'm aware of.
| |
04:05 | Wait around for alkisg to show. He's more knowledgable of ubuntu
| |
04:06 | <Guest45623> Yes, thank for your kind! I will wait and keep searching :)
| |
04:27 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 250 seconds) | |
04:30 | zamba has left IRC (zamba!marius@flage.org, Ping timeout: 268 seconds) | |
04:34 | zamba has joined IRC (zamba!marius@flage.org) | |
04:39 | Guest45623 has left IRC (Guest45623!9d13686b@gateway/web/freenode/ip.157.19.104.107, Ping timeout: 260 seconds) | |
05:41 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
05:44 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
06:06 | Statler has joined IRC (Statler!~Georg@p4FC87630.dip0.t-ipconnect.de) | |
06:14 | gdi2k has joined IRC (gdi2k!~gdi2k@119.94.27.63) | |
06:42 | dshah has joined IRC (dshah!5549015b@gateway/web/freenode/ip.85.73.1.91) | |
07:15 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
07:15 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 246 seconds) | |
07:29 | mikkel_ has joined IRC (mikkel_!~mikkel@mail.dlvs.dk) | |
07:58 | forum has joined IRC (forum!~Icedove@192-164-141-163.hdsl.highway.telekom.at) | |
08:44 | forum has left IRC (forum!~Icedove@192-164-141-163.hdsl.highway.telekom.at, Quit: forum) | |
09:10 | Statler has left IRC (Statler!~Georg@p4FC87630.dip0.t-ipconnect.de, Quit: Leaving) | |
09:56 | markus_e92 has left IRC (markus_e92!~markus_e9@194-166-99-245.adsl.highway.telekom.at, Ping timeout: 260 seconds) | |
09:58 | markus_e92 has joined IRC (markus_e92!~markus_e9@193-154-230-142.adsl.highway.telekom.at) | |
10:06 | forum has joined IRC (forum!~Icedove@81-5-201-115.hdsl.highway.telekom.at) | |
10:12 | Statler has joined IRC (Statler!~Georg@mail.lohn24.de) | |
10:44 | forum1 has joined IRC (forum1!~Icedove@81-5-201-115.hdsl.highway.telekom.at) | |
10:44 | forum has left IRC (forum!~Icedove@81-5-201-115.hdsl.highway.telekom.at, Read error: Connection reset by peer) | |
10:44 | forum1 is now known as forum | |
11:24 | schlady has joined IRC (schlady!~schlady@141-53-220-160.ip.uni-greifswald.de) | |
11:56 | forum has left IRC (forum!~Icedove@81-5-201-115.hdsl.highway.telekom.at, Remote host closed the connection) | |
11:58 | forum has joined IRC (forum!~Icedove@81-5-201-115.hdsl.highway.telekom.at) | |
12:33 | zamba has left IRC (zamba!marius@flage.org, Ping timeout: 260 seconds) | |
12:38 | forum has left IRC (forum!~Icedove@81-5-201-115.hdsl.highway.telekom.at, Remote host closed the connection) | |
12:38 | forum has joined IRC (forum!~Icedove@81-5-201-115.hdsl.highway.telekom.at) | |
12:43 | forum has left IRC (forum!~Icedove@81-5-201-115.hdsl.highway.telekom.at, Remote host closed the connection) | |
12:44 | forum has joined IRC (forum!~Icedove@81-5-201-115.hdsl.highway.telekom.at) | |
12:49 | zamba has joined IRC (zamba!marius@flage.org) | |
13:13 | forum has left IRC (forum!~Icedove@81-5-201-115.hdsl.highway.telekom.at, Remote host closed the connection) | |
13:13 | forum has joined IRC (forum!~Icedove@81-5-201-115.hdsl.highway.telekom.at) | |
13:15 | GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Remote host closed the connection) | |
13:24 | GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com) | |
13:29 | fred has joined IRC (fred!5a2176ca@gateway/web/freenode/ip.90.33.118.202) | |
13:29 | fred is now known as Guest68466 | |
13:30 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
13:30 | Guest68466 has left IRC (Guest68466!5a2176ca@gateway/web/freenode/ip.90.33.118.202, Client Quit) | |
13:31 | forum has left IRC (forum!~Icedove@81-5-201-115.hdsl.highway.telekom.at, Quit: forum) | |
13:40 | eu^cpe-98-30-172 has joined IRC (eu^cpe-98-30-172!621eacd7@gateway/web/freenode/ip.98.30.172.215) | |
13:43 | eu^cpe-98-30-172 has left IRC (eu^cpe-98-30-172!621eacd7@gateway/web/freenode/ip.98.30.172.215, Client Quit) | |
13:52 | schlady_ has joined IRC (schlady_!~schlady@141-53-220-160.ip.uni-greifswald.de) | |
13:54 | schlady has left IRC (schlady!~schlady@141-53-220-160.ip.uni-greifswald.de, Ping timeout: 248 seconds) | |
14:05 | <sbalneav> vagrantc: Hey hey
| |
14:06 | You still with alkisg? Or heading home?
| |
14:15 | <jammcq> Scotty !!!!!!!!!!!!!!!!!!!!!!!!!
| |
14:17 | <vagrantc> sbalneav: roughly 24 more hours in alkisg's good care.
| |
14:18 | jammcq: heya!
| |
14:18 | we actually set up an LTSP lab in a small mountain village this morning, so didn't have much time to test
| |
14:18 | sbalneav: test ltsp-pam improvements
| |
14:18 | really nice to see LTSP in real-world use!
| |
14:19 | <jammcq> vagrantc: HEY !
| |
14:19 | what city are you guys in?
| |
14:19 | <vagrantc> ionnina now
| |
14:19 | oops, misspelled
| |
14:20 | <jammcq> ok... what country ? :)
| |
14:20 | * vagrantc pulls the proper spelling from debian/changelog | |
14:20 | <vagrantc> Ιωάννινα
| |
14:20 | as the saying goes, looks greek to me.
| |
14:20 | <jammcq> in greece ?
| |
14:21 | <vagrantc> i guess that's only one of the proper spellings
| |
14:21 | jammcq: nai!
| |
14:21 | (a.k.a. yes)
| |
14:21 | <jammcq> found it on google maps
| |
14:21 | looks cool
| |
14:22 | <vagrantc> it has been a wonderful visit, and we've made some good progress on the ltsp PAM integration
| |
14:22 | mostly sbalneav writing stuff, and alkisg and I testing
| |
14:23 | sbalneav: what's your august looking like? maybe we could do a hackfest in montreal piggy-backing on debconf :)
| |
14:29 | robb_nl has joined IRC (robb_nl!~robb_nl@ip-80-236-244-200.dsl.scarlet.be) | |
14:32 | * vagrantc tests the latest and greatest ltsp-pam | |
14:33 | <vagrantc> sbalneav: ooh, ooh! i was able to log into mate twice in a row!
| |
14:34 | no luck on the console login though ...
| |
14:45 | gp has joined IRC (gp!~gp@104-14-168-137.lightspeed.rcsntx.sbcglobal.net) | |
14:52 | robb_nl has left IRC (robb_nl!~robb_nl@ip-80-236-244-200.dsl.scarlet.be, Ping timeout: 245 seconds) | |
14:56 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
15:04 | * alkisg tries debuild'ing ltsp-pam... | |
15:07 | mikkel_ has left IRC (mikkel_!~mikkel@mail.dlvs.dk, Quit: Leaving) | |
15:12 | <alkisg> vagrantc: if [ "$PAM_TYPE" = "close_session" ]; then
| |
15:12 | sleep 10
| |
15:12 | Does that sleep 10 at that point, give you a 10 sec console?
| |
15:12 | I was able to login and work fine, and then after 10 sec it exited
| |
15:13 | sbalneav: I'm having the same issue as vagrantc, i.e. my console logins immediately exit
| |
15:13 | And additionally the user is not removed from extrausers on logout
| |
15:15 | Hmmm actually that "sleep" there, increases the lightdm login time, not the logout time
| |
15:15 | Sounds like "close_session" is called at the wrong time?!
| |
15:19 | <sbalneav> Hmm, dunno, I'll dig into it today, see if I can get terminal logins working.
| |
15:19 | back, was out for a bit.
| |
15:20 | The cleanup code on close_session should now be shutting down any stray procs
| |
15:25 | <alkisg> Ah, maybe it's called for the lightdm user... let me check
| |
15:27 | sbalneav: I see pam-session being called for the lightdm user ==> close_session,
| |
15:27 | and then for the "administrator" user ==> open session
| |
15:27 | Maybe we want to ignore all lightdm events?
| |
15:28 | <sbalneav> This is in the console?
| |
15:28 | <alkisg> No I was trying from lightdm currently, now I'll try from the console
| |
15:29 | So, logging in from the console immediately calls pam-session open_session and pam-session close_session
| |
15:29 | <sbalneav> The session stuff's contingent on the socket existing. For the lightdm user, there'll be no socket
| |
15:30 | Right, why, I don't know.
| |
15:30 | <alkisg> If I put a "sleep 10" in close_session, then I can work in the console just fine for 10 seconds
| |
15:30 | <sbalneav> For a console login, do we want the ssh tunnel to start, and the sshfs homedir to mount?
| |
15:30 | <alkisg> Does the pam-session script need to return 0?
| |
15:31 | <sbalneav> Or do we just want to have the user logged into an empty directory?
| |
15:31 | <alkisg> I think I would do it like this: if the user account exists, don't fetch it from the server (e.g. ldap)
| |
15:31 | if the home dir exists, don't use sshfs
| |
15:31 | else => do those
| |
15:31 | That should allow multiple console logins etc too
| |
15:32 | <sbalneav> Well, we always remove the homedir on exist
| |
15:32 | *exit
| |
15:32 | <alkisg> Currently we pkill everything
| |
15:32 | <sbalneav> correct.
| |
15:32 | <alkisg> If we see that killing systemd only kills the cgroup processes,
| |
15:33 | then we can check after killing systemd if there are other processes of that same user
| |
15:33 | <sbalneav> I've added in further cleanup code.
| |
15:33 | It's already there now.
| |
15:33 | <alkisg> (or ask logind directly if there's another session for that user),
| |
15:33 | so, if he's logged in another time, we don't want to unmount it
| |
15:33 | <sbalneav> Not sure how to ask logind such things :
| |
15:34 | <alkisg> loginctl --help will tell us
| |
15:34 | There's also loginctl kill-session, if we prefer it to pkill
| |
15:36 | <vagrantc> that sounds more robust, if implementation specific
| |
15:36 | GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Read error: Connection reset by peer) | |
15:36 | <alkisg> Ideally we don't want to kill anything; we only want pam or systemd to notify us when a session has closed
| |
15:39 | <sbalneav> ok
| |
15:39 | <alkisg> sbalneav: could you give us a small description of which parts run at which point? Like, user authenticates in lightdm => ssh.py gets called as root with that param ==> session starts etc etc?
| |
15:39 | And which of them run as root, and which as the user?
| |
15:40 | <sbalneav> User enters username
| |
15:40 | pam_open is called
| |
15:40 | <alkisg> Ah, that's before he enters the password?!
| |
15:40 | <sbalneav> pam prompts for "Password"
| |
15:40 | Correct
| |
15:40 | PAM asks for the password
| |
15:40 | If you look in the ssh.py code, you'll see under "password" authentication where it asks for it.
| |
15:41 | pam recieves password
| |
15:41 | <alkisg> That runs as root or as lightdm?
| |
15:41 | <sbalneav> We're root right now, yes
| |
15:41 | <alkisg> ok
| |
15:41 | <sbalneav> pam does whatever necessary to check password is ok
| |
15:41 | password's fine, we're finished with auth
| |
15:41 | now we call pam_acct_mgmt
| |
15:42 | whatever acct mgmt stuff needs to happen goes on (usually nothing)
| |
15:42 | That closes
| |
15:42 | open_session is called.
| |
15:42 | Whatever stuff's in the open session happens (we're still root)
| |
15:42 | open_session finishes.
| |
15:43 | lightdm DROPS PRIVS. we're now the user
| |
15:43 | whatever lightdm xsession is going on runs.
| |
15:43 | GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com) | |
15:43 | <sbalneav> lightdm xsession terminates (user selects SYstem->Logout>
| |
15:43 | pam close_session is now called AS THE USER
| |
15:44 | that finishes
| |
15:44 | pam_close is called
| |
15:44 | go back to the top
| |
15:44 | <alkisg> pam_close runs as root?
| |
15:44 | <sbalneav> The problem that's always present is:
| |
15:44 | No, pam_close runs as user.
| |
15:44 | auth, and open_session run as root
| |
15:44 | <alkisg> So at what point do we have the rights to remove the home dir?
| |
15:44 | <sbalneav> close_session runs as user
| |
15:45 | You can do it in close session, but you have to do it AS THE USER
| |
15:45 | You never get root back
| |
15:45 | <alkisg> But the user cannot remove his own home dir...
| |
15:45 | Hmm...
| |
15:45 | <sbalneav> That's the problem.
| |
15:45 | That's why we have to make sure the user owns his or her home dir, since they cannot remove it if it's root owned
| |
15:46 | that's also why we can't clean up nss-extrausers
| |
15:46 | <alkisg> If that fails, we could have some root process listening for logout signals, and doing the "right" thing for them...
| |
15:46 | <sbalneav> once you drop the privs, they're gone and you never get them back
| |
15:47 | The *easy* solution would be to just have some setuid program that does LTSP specific cleanup. But distros are VERY hinky about letting setuid binaries into the filesystem
| |
15:47 | <alkisg> We can keep some script running as root, listening for signals from its childs...
| |
15:48 | <sbalneav> That complicates things. And for the moment, I don't think we'll need it.
| |
15:48 | <alkisg> It shouldn't require more than 10-20 lines of code to implement that wrapper... without counting the cleanup code
| |
15:48 | That could also clean up extrausers
| |
15:48 | <sbalneav> What I need to do is write the code necessary to MERGE new data into extrausers, and not just overwrite
| |
15:49 | <alkisg> I think I've already done that in the past in x01-localapps
| |
15:49 | <sbalneav> then we wouldn't need to clean up; extrausers would just cleanly grow during the course of multiple people logging in and out.
| |
15:49 | <alkisg> But is that a wise thing to do?
| |
15:49 | A user that is removed from the server, will never get removed from the client's lightdm list
| |
15:49 | <sbalneav> I can't see why it wouldn't be: take my scenario...
| |
15:50 | Yes, but if it's removed from the server, it can't AUTHENTICATE anymore
| |
15:50 | Since the authentication doesn't happen with the local extrausers stuff, only from the remote ssh
| |
15:50 | <alkisg> True, it wouldn't be a security risk, just an annoying GUI thing
| |
15:51 | <sbalneav> It shouldn't even be annoying gui wise.
| |
15:51 | Lets say user bob, uid 1000 logs in to a thin client, and then logs out
| |
15:51 | <alkisg> OK, at that point lightdm keeps him as the preselected user
| |
15:51 | <sbalneav> now on the server, we delete bob, and add bill, uid 1000
| |
15:51 | ah, well, that's a function of the GREETER.
| |
15:51 | <alkisg> Yup
| |
15:52 | Sorry, should have said lightdm-greeter instead of just lightdm
| |
15:52 | <sbalneav> remember, I want us to eventually switch to using lightdm-webkit-greeter
| |
15:52 | <alkisg> Ideally, don't we want to support any greeter?
| |
15:52 | <sbalneav> We do, but gtk-greeter doesn't support password aging.
| |
15:53 | <alkisg> sry, phone, brb...
| |
15:53 | <sbalneav> np
| |
15:54 | in your scenario, true, gtk-greeter would keep "bob" as the default user, but but that would be the case if bob and bill both did exist anyway, so... it's not really a big issue, as far as I can see.
| |
15:54 | and as soon as bill logs in, if we're properly merging the extrausers files, bob will simply get replaced at that point.
| |
15:54 | since they both have uid 1000
| |
15:55 | since there's no local password stored, I don't see that it's a security problem.
| |
15:57 | btw, if I remove the "ltsp" parameter from the common-auth ssh.py line, I can log in to the console. So it's something with the code that launches the tunnel that's causing the console hang.
| |
15:57 | That narrows it down... :D
| |
15:57 | <vagrantc> huh
| |
15:58 | why would launching the tunnel work for lightdm but not for getty login?
| |
15:58 | <sbalneav> *shrug*, I guess I'll figure it out :D
| |
15:59 | there's a lot of forking and execing in there. chances are I've got something ever-so-slightly wrong.
| |
16:00 | <vagrantc> sbalneav: removing "ltsp" from the auth line didn't work for m
| |
16:00 | me
| |
16:01 | <sbalneav> hmm
| |
16:01 | odd
| |
16:01 | worked for me
| |
16:01 | * vagrantc moves on to using the sshauth with sshd :) | |
16:01 | <vagrantc> sbalneav: did you have the user logged in via lightdm at the same time?
| |
16:01 | <sbalneav> No
| |
16:02 | a dual login like that's gonna fail for sure
| |
16:02 | <vagrantc> well, it has it's issues
| |
16:02 | but actually works
| |
16:02 | until one of them logs out
| |
16:02 | <sbalneav> right
| |
16:02 | since we just kill everyone's processes with our userid
| |
16:03 | wonder if loginctl can give us a list of what a particular sessions' pids are.
| |
16:03 | <vagrantc> thre's got to be a way to only kill a particular tree of processes
| |
16:03 | <sbalneav> Oh, I'm sure.
| |
16:04 | <alkisg> back, reading...
| |
16:07 | <sbalneav> brb, coffee
| |
16:10 | <alkisg> sbalneav: maybe it has something to do about closing stdio descriptors?
| |
16:16 | <sbalneav> alkisg: That's.... a possibility
| |
16:17 | Anyway, I know both your time there is fleeting, but I think we've made some really good progress
| |
16:18 | We've kind of gone from "a bunch of ideas and dreams" to "a mostly working implementation"
| |
16:19 | So, I'm planning on setting up a server here to be my new testbed
| |
16:20 | My question is: what's the *preferred* way now, if we're getting rid of ltsp-build-client (or trying to) to do ltsp? I've never done the ltsp-pnp stuff. How do you get started with that?
| |
16:20 | <alkisg> !ltsp-pnp
| |
16:20 | <ltsp> ltsp-pnp: ltsp-pnp is an alternative (upstream) method to maintain LTSP installations for thin and fat clients that doesn't involve chroots: https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
| |
16:20 | <alkisg> I think I kept this up to date even for 16.04
| |
16:21 | Ah, sorry, some ubuntu specific bits there
| |
16:21 | vagrantc has one for debian as well, I dunno if it's up to date...
| |
16:21 | If you have a working ltsp setup, you rm -rf /opt/ltsp, and run ltsp-update-image -c /
| |
16:21 | That should mostly do it...
| |
16:22 | The rest of the parts are for setting up proxydhcp instead of normal dhcp etc, you don't really need to switch to those
| |
16:29 | <sbalneav> ok
| |
16:29 | I'll try setting something up
| |
16:35 | <vagrantc> sbalneav: https://wiki.debian.org/LTSP/Howto has a description using the LTSP-PNP method
| |
16:36 | mgith be slightly out of date ...
| |
16:36 | some of the steps are no longer necessary with Debian stretch or jessie-backports
| |
16:37 | and some of them you can omit (e.g. DHCP if you have that on your own)
| |
16:38 | the main part is "ltsp-update-image --cleanup /"
| |
16:47 | <alkisg> if not os.path.exists(pamh.env[SOCKET]):
| |
16:47 | debug('Control socket did not start')
| |
16:47 | # return pamh.PAM_AUTH_ERR
| |
16:47 | I commented out that line
| |
16:47 | Then I tried putting a "return" right above the forking code
| |
16:47 | And console logins work
| |
16:48 | Then I moved the "return" right below the forking code
| |
16:48 | And console logins fail
| |
16:48 | I'm guessing that something's going wrong at the forks...
| |
16:55 | A single fork works, a double fork causes issues
| |
17:13 | schlady_ has left IRC (schlady_!~schlady@141-53-220-160.ip.uni-greifswald.de, Remote host closed the connection) | |
17:14 | schlady has joined IRC (schlady!~schlady@141-53-220-160.ip.uni-greifswald.de) | |
17:18 | schlady has left IRC (schlady!~schlady@141-53-220-160.ip.uni-greifswald.de, Ping timeout: 258 seconds) | |
17:51 | robb_nl has joined IRC (robb_nl!~robb_nl@ip-80-236-244-200.dsl.scarlet.be) | |
18:08 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 245 seconds) | |
18:09 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
18:25 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
19:21 | dshah has left IRC (dshah!5549015b@gateway/web/freenode/ip.85.73.1.91, Ping timeout: 260 seconds) | |
19:56 | <Statler> alkisg, do you have upgraded nbd-client?
| |
19:58 | robb_nl_ has joined IRC (robb_nl_!~robb_nl@ip-80-236-222-109.dsl.scarlet.be) | |
20:01 | robb_nl has left IRC (robb_nl!~robb_nl@ip-80-236-244-200.dsl.scarlet.be, Ping timeout: 248 seconds) | |
20:14 | <Statler> alkisg, I have found it!
| |
20:14 | strace on the nbd-server shows the problem
| |
20:15 | Kernerl 4.8 or the nbd-client strips the first / from the path of the nbd-export-name
| |
20:21 | Statler has left IRC (Statler!~Georg@mail.lohn24.de, Remote host closed the connection) | |
20:21 | alkisg_web has joined IRC (alkisg_web!d510e916@gateway/web/freenode/ip.213.16.233.22) | |
20:22 | <alkisg_web> Statler, yup, known issue and bug report filed for that
| |
20:24 | Statler, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846998
| |
20:40 | alkisg_web has left IRC (alkisg_web!d510e916@gateway/web/freenode/ip.213.16.233.22, Quit: Page closed) | |
21:08 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
21:11 | GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 250 seconds) | |
21:22 | schlady has joined IRC (schlady!~schlady@ip1f12125a.dynamic.kabel-deutschland.de) | |
21:22 | schlady has joined IRC (schlady!~schlady@ip1f12125a.dynamic.kabel-deutschland.de) | |
21:24 | schlady_ has joined IRC (schlady_!~schlady@2a03:2260:200e:0:949b:3a4e:72f0:10a2) | |
21:26 | GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com) | |
21:27 | schlady has left IRC (schlady!~schlady@ip1f12125a.dynamic.kabel-deutschland.de, Ping timeout: 250 seconds) | |
21:34 | robb_nl_ has left IRC (robb_nl_!~robb_nl@ip-80-236-222-109.dsl.scarlet.be, Quit: robb_nl_) | |
22:04 | adrianor1 has joined IRC (adrianor1!~adrianorg@177.134.63.142) | |
22:07 | adrianorg has left IRC (adrianorg!~adrianorg@187.58.140.220, Ping timeout: 246 seconds) | |
22:38 | schlady has joined IRC (schlady!~schlady@p200300CB8BC4D900685CF2AA5960BC50.dip0.t-ipconnect.de) | |
22:41 | schlady_ has left IRC (schlady_!~schlady@2a03:2260:200e:0:949b:3a4e:72f0:10a2, Ping timeout: 260 seconds) | |
22:49 | schlady has left IRC (schlady!~schlady@p200300CB8BC4D900685CF2AA5960BC50.dip0.t-ipconnect.de, Remote host closed the connection) | |
23:01 | jammcq has left IRC (jammcq!~jam@c-68-40-171-103.hsd1.mi.comcast.net, Ping timeout: 260 seconds) | |
23:06 | GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Quit: Ex-Chat) | |
23:06 | GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com) | |
23:41 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |
23:53 | GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 250 seconds) | |