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


Channel log from 3 September 2015   (all times are UTC)

00:08Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack)
01:28AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-xuztxchcqskbmcsh, Quit: Connection closed for inactivity)
01:58dgroos has joined IRC (dgroos!~dgroos@mail.troop187.org)
02:02dgroos_ has joined IRC (dgroos_!~dgroos@vpn.mpls.k12.mn.us)
02:03dgroos has left IRC (dgroos!~dgroos@mail.troop187.org, Ping timeout: 255 seconds)
02:03dgroos_ is now known as dgroos
04:04dgroos has left IRC (dgroos!~dgroos@vpn.mpls.k12.mn.us, Quit: dgroos)
04:08telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
04:10telex has joined IRC (telex!teletype@freeshell.de)
05:00ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)
05:08work_alkisg is now known as alkisg
05:20cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 246 seconds)
06:02
<alkisg>
Hyperbyte: I still haven't been able to make systemd unmount nbd before poweroff. So much for systemd being easy. :)
06:03
No help from their IRC/ML either
06:05vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi)
06:09mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
06:35pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 264 seconds)
06:40pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)
07:35
<alkisg>
!nbd-client
07:35
<ltsp`>
nbd-client: To try mounting the NBD image from the client initramfs: nbd-client 192.168.67.1 -N /opt/ltsp/i386 /dev/nbd0
08:04cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
08:12
<Hyperbyte>
alkisg, systemd doesn't unmount nbd at all?
08:13
<alkisg>
Hyperbyte: nope, it does swapoff but not nbd-client -d, thus leaving the temporary swap files on the server
08:16
<Hyperbyte>
I'd have look into your configuration.
08:16
Do you have an ltsp service in systemd?
08:17
<alkisg>
Hyperbyte, currently we don't have anything at all systemd-related in ltsp
08:17
If there's an upstream method to mount/unmount nbd, then we could use that one
08:17
But I didn't see any...
08:18
I'm trying to create an override .conf file for dev-nbd1.swap.d/ltsp.conf, but it's not called... maybe it needs to be called dev-nbd1.device.d/ltsp.conf instead...
08:19
<Hyperbyte>
https://bugzilla.redhat.com/show_bug.cgi?id=1214466
08:19
See that.
08:20
systemd does take care of unmounting network filesystems before shutting down network, but there's a bug presently where it only works over lan and not wireless.
08:20
It wouldn't surprise me if there was a bug as well that it only works with nfs currently and not nbd, but you'd have to check that. If it does have that bug, then you should file a report.
08:21
In the meantime, you can create a workaround easily - there's some suggestions in that bug report I linked.
08:21
But what I would do, is create an ltsp-client.service for systemd, which is dependant on network.target, and do all your stuff in there.
08:22
Basically it's what you do right now as well with init. Just have a single script handle everything on startup and shutdown.
08:24
If you want I can log in and take a look at your configuration, help you set up service files, etc...
08:24
<alkisg>
It just sounds silly to have a "service" in order to put some workarounds for shutdown... but I've tried Before=halt.target etc and they don't work properly, so I'm guessing it's worth a shot
08:24
<Hyperbyte>
I see a post from you earlier on Gmane where you have problems with your .service files.
08:25
<alkisg>
Ideally I shouldn't need any .service files at all, those were my attempts to work around the issue
08:26NeonLicht has joined IRC (NeonLicht!~NeonLicht@darwin.ugr.es)
08:27
<Hyperbyte>
alkisg, how long does this swap file stay active on the server anyways?
08:28
<alkisg>
I don't remember, either 2h 11m or until server reboot
08:28
<Hyperbyte>
mhm
08:34
<alkisg>
Hyperbyte: the swap is only 1/2 of the problem, the other half is that systemd brings down the network so /sbin/poweroff cannot be accessed and the clients don't shut down
08:34
I'll check the bug report in case I can find any workarounds
08:35
As for a test environment, just install ubuntu 15.10 with ltsp and try to shut down a client...
08:37
<Hyperbyte>
systemd has been made so it cleanly unmounts nfs as well, so it should also be able to work with nbd. What we're doing with LTSP isn't of course common usage, so it's not surprising we run into bugs.
08:37
But I think if you file clean reports for those in RedHat's bugzilla they might just be fixed quicker than you think.
08:39
<alkisg>
One problem is that we're using nbd as the root device. I don't think nfs as the root device is supported by systemd, is it?
08:39
And a second problem is that I cannot file bugs against fedora without porting ltsp there... what would I mention, that I'm using ubuntu?
08:42
bb in 30'...
08:42alkisg is now known as work_alkisg
08:42
<Hyperbyte>
You don't need to file bugs against Fedora?
08:42
<work_alkisg>
Against redhat's bugzilla?
08:44
<Hyperbyte>
I meant Freedesktop: https://bugs.freedesktop.org/buglist.cgi?component=general&product=systemd&resolution=---
08:44
That's systemd bugtracker.
08:45
And can't just file bugs against Ubuntu 15.10 systemd as well?
09:03
<work_alkisg>
Ubuntu rarely fixes upstream bugs
09:03work_alkisg is now known as alkisg
09:04
<alkisg>
OK let me try with a startup service instead of a shutdown service...
09:06
Hyperbyte: ah, another issue with the startup service is that then I cannot see if the system reboots or shuts down
09:06
`runlevel` at that point doesn't return 0/6
09:06
So I was trying to have 2 services, one for reboot and one for shutdown, which isn't possible with one startup ltsp service
09:53
Hyperbyte: https://paste.debian.net/310193/
09:54
With that, it _sometimes_ works properly
09:54
I.e. there's still a race condition involved
09:55
If I use RCFILE_01="sleep 10; RUNLEVEL=6 nbd-disconnect", then I can verify that nbd-disconnects works properly, e.g. after 100 client reboots I don't have any extra nbd-server processes,
09:55
but if I use RCFILE_01="reboot", and use that ^ unit which then calls nbd-disconnect, it does have a few extra nbd-server processes, e.g. 10%
09:56
So one out of ten times, systemd reboots without letting nbd-disconnect finish its job
09:56
Do you think that I also need a "wants" directive?
10:00* alkisg will also check if having /dev/nbd0 with _netdev in /etc/fstab, helps...
10:01alkisg is now known as work_alkisg
10:01maldridge has left IRC (maldridge!~maldridge@69.13.217.92, Remote host closed the connection)
10:07maldridge has joined IRC (maldridge!~maldridge@69.13.217.92)
10:25maldridge has left IRC (maldridge!~maldridge@69.13.217.92, Ping timeout: 250 seconds)
10:31maldridge has joined IRC (maldridge!~maldridge@69.13.217.92)
10:40
<fiesh>
hmm, after my update, despite still having X_COLOR_DEPTH=24, my X is started with -depth 16 -- any hints?
10:54Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net)
10:54
<Hyperbyte>
work_alkisg, sure you can see if it's shutting down or starting up
10:55
For starters, you can have a service execute different commands on startup/shutdown
10:55
ExecStart ExecStop
10:55
Just pass it as a parameter, or better yet, have one script for startup and one script for shutdown
10:57
Like I said, you could have me ssh in so we can take a look together. I don't have a 15.10 machine handy and I haven't seen systemd on Ubuntu before.
10:58
cyberorg posted his ltsp .service file here a while back
10:58
It was clean and simple, just ltsp service that executes one command on startup to init the client and one on shutdown to cleanup all the client stuff
10:59
If you just do the swap unmount/nbd disconnect from the ltsp cleanup script (which kinda makes sense, because you're doing the connect & mounting of the swap from the init script, everything should work fine methinks.
11:01khildin has joined IRC (khildin!~khildin@ip-80-236-242-25.dsl.scarlet.be)
11:09Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Quit: I Leave)
11:22
<fiesh>
hmm, if I change /usr/share/ltsp/screen-session.d/XS95-colordepth by hand, it's all fine...
12:12
hmm I think my lts.conf is not found any more when I change the root mount point? how is the path of lts.conf determined?
12:18vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
12:31ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
12:50vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi, Read error: Connection reset by peer)
13:56telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
13:58telex has joined IRC (telex!teletype@freeshell.de)
14:10mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
14:18work_alkisg is now known as alkisg
14:19
<alkisg>
Hyperbyte: the problem is not about running different commands on startup/shutdown, but on shutdown/reboot
14:19
We essentially need to run `poweroff -fp` or `reboot -fp` depending on the runlevel
14:19
And with a plain ltsp.service file, I can't get separate "events" for poweroff vs reboot
14:20
And `runlevel` doesn't produce the correct results
14:20
So I was trying to create an ltsp-reboot.service and an ltsp-shutdown.service files, but that doesn't work correctly either
14:22
About the swap, I just checked and if a client constantly reboots, it causes about 100-200 nbd-server processes on the server before they automatically time out after 2 hours
14:22
So if one has plenty of space on the server, unmounting the swap isn't of paramount importance,
14:23
but, being able to reboot and shutdown surely is...
14:25
So to sum up I think we'll need 4 different systemd units, one for ltsp startup/shutdown, one for swap, one for reboot, and one for shutdown... and I'm worried that the last 3 won't work properly...
14:25
fiesh: it's deduced from the tftp boot file name
14:26
E.g. /ltsp/i386/pxelinux.0 ==> /ltsp/i386/lts.conf
14:26
<fiesh>
hmm ok, so then it shouldn't depend on the root mount point, thanks
14:33AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-eupbxwjlkjxrmxiw)
16:08dgroos has joined IRC (dgroos!~dgroos@2607:ea00:103:4802::28)
16:09
<dgroos>
maldridge: clients now booting AND clients can login to their session!
16:11
The problem with the login was that the tool that connected me to our AD servers used /etc/skel/ as its template for creating home folders for new users.
16:12
And that template folder was too sparse so a sessions couldn't be started for people who didn't already have a complete home folder. So, I just copied in a freshly created home folder into /etc/skel/ and first time logins now work!
16:13
I do have a problem with browser on client--they can't access the internet yet.
16:15
I think the problem might be that to get PowerBroker (the tool to connect to AD) to work, I need to include a dns entry in: /etc/resolvconf/resolv.conf.d/head. I use the school districts dns address, but the ltsp-pnp fix uses 8.8.8.8
16:15
Might that be a problem, anyone? Any other ideas?
16:16
(fyi this is my lunch break so I have to leave in 13 minutes but will be back an hour later.)
16:17
<alkisg>
dgroos, just put your DNS_SERVER in lts.conf...
16:17
Replace 8.8.8.8 with the one you want
16:17
<dgroos>
alkisg: Cool, will try!
16:21
(booting client... do I need to restart networking? computer? dns?)
16:24_UsUrPeR_ has joined IRC (_UsUrPeR_!~jsass@12.187.125.2)
16:24
<dgroos>
hmmm... I'll try rebooting later, clients can't yet access internet via browser.
16:26_UsUrPeR_ has left IRC (_UsUrPeR_!~jsass@12.187.125.2, Client Quit)
16:27
<dgroos>
bblater
16:36
<alkisg>
dgroos: You only need to restart the client
16:45NeonLicht has left IRC (NeonLicht!~NeonLicht@darwin.ugr.es, Ping timeout: 260 seconds)
17:42
<dgroos>
hmmm... no access to internet on client yet--that must not have been the problem.
17:43
Also, am finding there still are issues with the AD binding. Be back in 2 hours...
17:43
Thanks alkisg
17:44gothaggis has left IRC (gothaggis!~growland@corp.heavyhammer.com, Remote host closed the connection)
17:49
<alkisg>
dgroos: single NIC setup, and the client can't ping 8.8.8.8?
17:50
On a fat client, try: (1) ping 8.8.8.8, and (2) host www.google.com
17:50
If (1) works and (2) doesn't, it's a dns issue, maybe your lts.conf isn't correct
18:39alkisg is now known as work_alkisg
18:40Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net)
18:54lavarenne has joined IRC (lavarenne!51f9da54@gateway/web/freenode/ip.81.249.218.84)
18:59
<lavarenne>
Hi i try to configure epoptes following the documentation http://www.epoptes.org/installation but i get the error epoptes-client ERROR: Failed to fetch certificate from 192.168.1.13:789 when i run epoptes-client -c thx :-)
19:07Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Quit: I Leave)
20:09Junior has joined IRC (Junior!bd4b5d2c@gateway/web/freenode/ip.189.75.93.44)
20:11
<Junior>
hi, im using epoptes fat clients, all working normally until 3 days ago when 2 of the clients now appear as red on the server, already reinstalled and reconfigured epoptes-client on both machines. epoptes v. 0.5.7
20:21lavarenne has left IRC (lavarenne!51f9da54@gateway/web/freenode/ip.81.249.218.84, Ping timeout: 246 seconds)
20:35
<dgroos>
work_alkisg: I can't use the single NIC setup as the IT people want me on a completely isolated (bridged?) LAN.
20:36
<maldridge>
dgroos: do you have rules then that implement NAT on your segment?
20:36
<dgroos>
Neither pinging IP nor domain name gets a response.
20:36
Hi maldridge! Ummm... don't think so.
20:37
<maldridge>
so your ltsp server has 2 nics and can talk to the outside world, but clients can't?
20:37
<dgroos>
correct.
20:38
<Junior>
nic confs ?
20:39
<maldridge>
so, assuming that you have eth0 on the outside and eth1 on the inside, this guide will give you the 4 commands you need: http://www.revsys.com/writings/quicktips/nat.html
20:39
<dgroos>
I'll check it out!
20:40
<Junior>
maldrige can you help me
20:40
?
20:40
<maldridge>
Junior: what is your issue?
20:40
ah, just read scrollback; I'm afraid I don't use epoptes
20:40
<Junior>
ahh ok
20:40
ty
20:42dgroos has left IRC (dgroos!~dgroos@2607:ea00:103:4802::28, Quit: Leaving.)
20:42dgroos has joined IRC (dgroos!~dgroos@2607:ea00:103:4802::28)
20:43
<maldridge>
Junior: only thing I can think of is that they either didn't, or couldn't, pull down the server's cert
20:47
<Junior>
already pulled
20:56telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
20:58telex has joined IRC (telex!teletype@freeshell.de)
21:00
<dgroos>
Junior: A person who knows the ins and outs of epoptes lives in Greece and right now it's probably around midnight there. But if you get in this room sometime in their daytime he would most likely help you out on this issue.
21:01
maldridge: I followed the directions with the 4 commands but it doesn't seem to work yet... Should I restart networking or reboot client?
21:02
<Junior>
ty dgroos will try again
21:03
<dgroos>
good luck! h
21:03
<Junior>
how i got a private chat ?
21:03
<dgroos>
... His name is alkisg
21:04
<Junior>
ty
21:04
<dgroos>
Junior: right click on a person's name and choose it?
21:05
<Junior>
i dont know how to use this client :p
21:06
answer me on private
21:06
:p
21:15ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat)
21:24
<dgroos>
Whenever I use this irc I have to tunnel out via a vpn connection since our district blocks this port (don't ask me why). Might that be making the commands I executed on that page behave strangely?
21:25
<vagrantc>
maybe they're trying to contain an irc botnet
21:25
<dgroos>
;-)
21:26
we are blocked from youtube as well...
21:27
I remember when I had to NAT the server, but since using network manager and checking the box "available to all users" I've not had to worry about NATting.
21:28
But I see the 14.04 NM doesn't have that check box? How do I indicate on the 14.04 to forward packets?
21:29
(as shown in the screen shot/instructions on this page: UbuntuLTSP/StaticIP - Community Help Wiki <https://help.ubuntu.com/community/UbuntuLTSP/StaticIP>
21:36vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
21:39Junior has left IRC (Junior!bd4b5d2c@gateway/web/freenode/ip.189.75.93.44, Quit: Page closed)
21:49khildin has left IRC (khildin!~khildin@ip-80-236-242-25.dsl.scarlet.be, Quit: I'm gone, bye bye)
21:52dgroos has left IRC (dgroos!~dgroos@2607:ea00:103:4802::28, Read error: Connection reset by peer)
21:56
<maldridge>
ah, missed him by a small margin
22:09dgroos has joined IRC (dgroos!~dgroos@2607:ea00:103:4803::e)
22:13
<dgroos>
Has anyone had to NAT an ltsp-pnp 14.04 server when using network-manager and 2 nics?
22:17
<maldridge>
dgroos: while I think its possible to do that with network-manager, its probably not worth it
22:18
did you get any errors running the iptables commands?
22:18
<dgroos>
maldridge: OK
22:18
none
22:22
<maldridge>
can you pastebin an iptables -nvL
22:24
<dgroos>
http://paste.ubuntu.com/12267910/
22:27
<maldridge>
ah, you have cisco vpn stuff
22:28
I've never worked with the automated rules that cisco puts in, afraid I can't be of much help without risking breaking the VPN connection
22:28
<dgroos>
Well, only so that I can use this irc pidgin.
22:28AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-eupbxwjlkjxrmxiw, Quit: Connection closed for inactivity)
22:29
<dgroos>
That is complicating things, let me get off, see if I stay connected, if not I can do a work-around, just a sec.
22:32dgroos has left IRC (dgroos!~dgroos@2607:ea00:103:4803::e, Read error: Connection reset by peer)
22:51dgroos has joined IRC (dgroos!~dgroos@x-134-84-1-193.vpn.umn.edu)
22:52
<gehidore>
people still use pidgin?
22:52
;)
22:53
<dgroos>
gehidore: It helps me fly to other parts of the world, quickly :-)
22:54ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)
22:54
<gehidore>
fair enough
22:55
<dgroos>
maldridge: wish I had an ethernet adapter for laptop to connect to internal network and see if I could get out on that, no luck though…
22:55
gehidore: what do you use?
22:55
<gehidore>
I stopped using them all :|
22:56
I use weechat for irc and GV/Hangouts for everything from voice to sms to messaging
22:56
finally became skype free at the beginning of last month, felt liberating
22:58
<dgroos>
Can hangouts call a phone in another country?
23:01
<gehidore>
not without charging you for it :(
23:02
but my setup isn't for everyone, just hadn't heard someone talk about pidgin in a long time
23:02
<dgroos>
alas
23:02
<gehidore>
now if that person also has hangouts... you can voice or video call regardless of location
23:03
<maldridge>
dgroos: any one of the clients should be able to do it
23:03
<dgroos>
My wife needs to call to rural guatemala—computers with internet are rare but cell phones abundant.
23:06
maldridge: I went to the old https://help.ubuntu.com/community/UbuntuLTSP/ThinClientHowtoNAT and it reminded me that a valuable test is to see if the problem is just on the clients or on their internal LAN.
23:11
<maldridge>
ah, yeah that article has some good tips
23:11
so its working on your setup now?
23:12
<dgroos>
no, not yet…
23:13
not sure where to go now to trouble shoot w/out being able to connect a full computer (non-pxe-booting) computer to the LAN
23:13
try to ping 8.8.8.8 at a client and it goes nowhere
23:16
<maldridge>
does it at least make it to the server
23:16
?
23:16
and to be sure, you are in fact running a dual nic setup, right?
23:16
<gehidore>
dgroos: understood
23:19
<dgroos>
at client: ping 192.168.67.1 And yes, it does make it to the server.
23:19
Yes, Dual NIC setup. eth0 to external eth1 to internal just like in the page you linked above.
23:24
<maldridge>
work_alkisg could explain it better, but I'm pretty sure that for the dual nic setup, ltsp has a nice autoconf script that sets up the network parameters as well as the tftp business
23:27
<dgroos>
maldridge: OK, I’ll get here early in the AM and try and connect w/him. I’m a little concerned about the commands from that page: http://www.revsys.com/writings/quicktips/nat.html would you double check that I don’t have to un-do something I did there? Looking at those 4 commands…
23:28
<maldridge>
well iptables isn't persistent across reboots, so as long as you didn't write those rules to a file anywhere, you can just reboot
23:29
<dgroos>
:-( but I did… (commands 3 and 4)
23:29
I guess
23:29
<maldridge>
ah, then just go edit those files, and remove the rules from them
23:29
or if those are the only things in the files, remove the files themselves
23:30
<dgroos>
I’ll check, what exactly do I look for from one of those commands?
23:33
and, I’m looking for the files at /sbin/iptables ?
23:33
sorry
23:34
<maldridge>
probably in /etc/iptables-restore I think
23:35
you don't need to back out your edits to syctl.conf
23:35
those need to be there either way
23:35
<dgroos>
k
23:36
don’t have /etc/iptables-anything
23:36
<maldridge>
alternatively if you edited /etc/sysconfig/iptables-config that file doesn't do anything on ubuntu
23:37
<dgroos>
don’t have /etc/sysconfig… either
23:39
<maldridge>
looking at that guide, I don't see any other file paths you could have edited
23:40
<dgroos>
this command alters which file: /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
23:44vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
23:48
<maldridge>
it alters no files
23:48
it only alters the state of the firewall as it sits in memory
23:49
(this is the reason that iptables can be confusing as it can be working, then you reboot and it doesn't since the rules don't get saved anywhere)
23:50
<dgroos>
Cool to know, thanks.
23:50
<maldridge>
np
23:51
<dgroos>
I now understand what they are saying on the page—the instructions to make these rules permanent are the editing of the following files, not the previous commands — I’m relaxing now :-)
23:55
<maldridge>
yeah, and iptables is pretty hard to brick, as you can always flip the chains to a default policy of accept and only things in the mangle chain won't work
23:55
s/chain/stage/