00:36 | cshubhamrao has left IRC (cshubhamrao!~shubham@117.198.102.163, Ping timeout: 240 seconds) | |
00:38 | cshubhamrao has joined IRC (cshubhamrao!~shubham@117.198.102.163) | |
03:00 | ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 240 seconds) | |
03:00 | ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
04:27 | cshubhamrao has left IRC (cshubhamrao!~shubham@117.198.102.163, Ping timeout: 240 seconds) | |
05:05 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 256 seconds) | |
05:39 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3106:a00:10e6:a89b:a4b0:9c3b) | |
05:40 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
06:16 | Statler|Home has joined IRC (Statler|Home!~Georg@p5B30E954.dip0.t-ipconnect.de) | |
06:40 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
07:00 | zamba has left IRC (zamba!marius@flage.org, Ping timeout: 264 seconds) | |
07:03 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
07:34 | kjackal_ has joined IRC (kjackal_!~quassel@2a02:587:3106:a00:10e6:a89b:a4b0:9c3b) | |
07:56 | kjackal has left IRC (kjackal!~quassel@2a02:587:3106:a00:10e6:a89b:a4b0:9c3b, Remote host closed the connection) | |
08:36 | zamba has joined IRC (zamba!marius@flage.org) | |
08:42 | kjackal has joined IRC (kjackal!~quassel@athedsl-237682.home.otenet.gr) | |
08:42 | kjackal_ has left IRC (kjackal_!~quassel@2a02:587:3106:a00:10e6:a89b:a4b0:9c3b, Ping timeout: 256 seconds) | |
10:14 | Statler|Home has left IRC (Statler|Home!~Georg@p5B30E954.dip0.t-ipconnect.de, Remote host closed the connection) | |
11:09 | epoptes_user4 has joined IRC (epoptes_user4!5118d30c@gateway/web/freenode/ip.81.24.211.12) | |
11:09 | epoptes_user4 has left IRC (epoptes_user4!5118d30c@gateway/web/freenode/ip.81.24.211.12, Client Quit) | |
11:20 | <fiesh> alkisg: also, unfortunately, setting the lease time to a ridiculously high value did not mitigate the problem :(
| |
11:21 | alkisg: I haven't checked the source, since changing it did change something it might be they have a hard coded maximum
| |
11:21 | or something else comes into play as well
| |
11:21 | either way, our clients freeze every other day or so
| |
11:33 | <alkisg> fiesh: did you try with a VM client?
| |
11:33 | I'll try to reproduce it locally, boot a gentoo client and leave it on for days, but I'm afraid my dhcp setup is different (a router is the dhcp server)
| |
12:06 | zwiebelbot has joined IRC (zwiebelbot!~awszgikm@103.102.15.139) | |
12:09 | <fiesh> alkisg: no, I didn't go for the vm any more because I thought the problem would be mitigated... what would the VM allow us to do that the native client doesn''t?
| |
12:27 | <alkisg> fiesh: a VM would *ensure* it's not related to your networking hardware
| |
12:27 | Also, an NFS-booted fat client would be a useful case
| |
12:29 | I'll check if it happens here in my setup; if it doesn't, it would be a useful clue
| |
12:35 | <fiesh> alkisg: but the network goes down and stays down --- so NFS will not survive either, and it cannot be the hardware because the thin client doesn't have this issue
| |
12:35 | <alkisg> fiesh: it's software, lots of things can happen :D
| |
12:35 | For example, suppose that a switch goes of for 1 sec
| |
12:36 | This can send and if-down event that can crash nbd but not nfs
| |
12:36 | <fiesh> true, but it doesn't crash the kernel, neither does it crash the running ping
| |
12:36 | ping would have to resume successfully
| |
12:36 | <alkisg> If there was an if-up event, sure
| |
12:36 | But if the disk access is blocked and if-up can't run... then no
| |
12:37 | <fiesh> I can actually test that, I'll start the ping, unplug the network cable, and plug it back in
| |
12:37 | I'll do that right now
| |
12:37 | <alkisg> I'm booting a VM gentoo client; that I can do remotely
| |
12:38 | <fiesh> ok, so even a network disconnect for 20 seconds doesn't cause any problems
| |
12:38 | it seems even NBD is fine with it,
| |
12:39 | but in particular both the kernel and the working ping don't mind
| |
12:39 | <alkisg> Can you think of anything gentoo-specific that would issue an if-down?
| |
12:40 | <fiesh> no, in particular I think it would have to occur with the thin client as well
| |
12:40 | <alkisg> The major different between thin and fat is the initramfs
| |
12:40 | genkernel vs dracut
| |
12:40 | Ah, and, dhclient installed in the chroot vs not
| |
12:42 | <fiesh> I guess I could remove dhclient
| |
12:42 | but it's not run, so not sure if that plays a role
| |
12:42 | <alkisg> We put that to get the system properly booted
| |
12:42 | Because your thin chroot is broken, it doesn't completely boot
| |
12:42 | <fiesh> oh ok
| |
12:42 | that might be a good thing :)
| |
12:42 | <alkisg> If you run openrc status or what you call it, it says degraded state
| |
12:43 | Haha, proper boot adds troubleshooting, yeah, but it's supposed to be the right thing to do
| |
12:43 | <fiesh> judging by dhcpd's source, there is no override for the value that's set
| |
12:43 | but maybe the client doesn't like too big a value, not sure
| |
12:43 | <alkisg> You did see an improvement when you changed the lease time, right?
| |
12:44 | <fiesh> yes
| |
12:44 | <alkisg> Or do you now think it was a coincidense?
| |
12:44 | <fiesh> but now changing it to something like 200 days didn't help any more
| |
12:44 | I don't think so, but of course I don't know for sure
| |
12:44 | <alkisg> Maybe that's a syntax error
| |
12:44 | <fiesh> is there a way to set a static ip address for one client and see if that helps?
| |
12:44 | to make sure it's dhcp
| |
12:44 | <alkisg> Yes, I think ltsp does have an example dhcpd.conf for that
| |
12:45 | Although I'm using dnsmasq so I don't know the dhcpd.conf syntax...
| |
12:45 | <fiesh> but then it's still assigned via dhcpd?
| |
12:45 | <alkisg> Yes
| |
12:45 | <fiesh> it would be even better to take dhcpd out of the picture completely
| |
12:45 | <alkisg> Theoretically, IPAPPEND 3 tells the client to assign a static IP
| |
12:45 | <fiesh> ah ok
| |
12:45 | <alkisg> But dracut chokes on that, Ifiled a bug report about it,
| |
12:46 | so you'd need to do it manually, ip=x:x:x:x:x:x
| |
12:47 | ip=10.161.254.3:10.161.254.11:10.161.254.1:255.255.255.0:pc01:eth0:none:dns0:dns1
| |
12:47 | All this in the command line is properly parsed by dracut
| |
12:47 | dns0 and dns1 are IPs
| |
12:47 | (ignore the following:)
| |
12:47 | !tftp
| |
12:47 | <ltsp> tftp: Here's a page to help you troubleshoot TFTP problems in Ubuntu: https://help.ubuntu.com/community/UbuntuLTSP/Troubleshooting/TFTP
| |
12:55 | <alkisg> OK, I booted a gentoo VM in fat client mode and I'll leave it open with `ping` and `dmesg -w` for a couple of days
| |
12:58 | fiesh: another helpful thing would be to boot a thin and a fat client, without logging in in either, and send/compare the output of ps faux
| |
12:58 | We might see something running in the fat client that is not running in the thin client, e.g. ntpd, and suspect something
| |
12:59 | Btw, does the problem happen even on fat clients that have not logged in, i.e. were booted only up to the LDM login screen?
| |
13:04 | * alkisg is suspecting /etc/init.d/net.eth0... | |
13:07 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
13:52 | <fiesh> hmmm, the client that I just wanted to log in to had issues and needed to be rebooted, but I didn't properly check if it was the network problem because I just assumed so -- will check that again
| |
14:02 | alkisg: this ip= line, what are the three IP addresses?!
| |
14:02 | and why do you have a netmask of /24 for a 10. network?
| |
14:02 | if that's the netmask
| |
14:02 | and they're put into pxelinux's APPEND?
| |
14:24 | <alkisg> fiesh: client/server/gateway/netmask etc
| |
14:24 | they're put there, yues
| |
14:27 | /24 networks are used here for schools, as part of a bigger 10. network
| |
14:29 | <fiesh> ok, thanks, I'll give it a shot
| |
14:36 | nehemiah has joined IRC (nehemiah!~nehemiah@137.26.129.150) | |
14:39 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 240 seconds) | |
14:45 | gp has joined IRC (gp!~gp@96.71.93.13) | |
14:46 | <gp> I am trying to work out an issue with freerdp crashing. Trouble is the logs are difficult to retreive. Has anyone done something like this before https://urbanautomaton.com/blog/2014/09/09/redirecting-bash-script-output-to-syslog/ and set clients up to syslog to the ltsp host server?
| |
14:47 | or something along the lines of making client logs easier to get at
| |
16:08 | alkisg has joined IRC (alkisg!~alkisg@2a02:2149:8481:6000:59b7:31a5:3795:b7da) | |
16:08 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
16:10 | <alkisg> !rsyslog | echo gp:
| |
16:10 | <ltsp> gp: rsyslog: To enable remote client logging in Ubuntu (it possibly also works on Debian), see https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/697387/comments/9
| |
17:01 | <gp> alkisg: Thanks. I saw the options for it. I was talking more about wrapping the xfreerdp screen script to output to syslog. And if anyone had any feedback or thoughts before I played with it
| |
17:04 | Madars940 has joined IRC (Madars940!~xhhsr@191.35.37.189) | |
17:12 | gp has left IRC (gp!~gp@96.71.93.13, Ping timeout: 256 seconds) | |
17:19 | gp has joined IRC (gp!~gp@96.71.93.13) | |
17:22 | nehemiah has left IRC (nehemiah!~nehemiah@137.26.129.150, Quit: Leaving.) | |
17:54 | lucascastro has left IRC (lucascastro!~lucas@201.182.221.14, Remote host closed the connection) | |
18:36 | cshubhamrao has joined IRC (cshubhamrao!75c666a3@gateway/web/freenode/ip.117.198.102.163) | |
18:44 | lucascastro has joined IRC (lucascastro!~lucas@201.182.221.154) | |
19:00 | eemeli has joined IRC (eemeli!d442dd17@gateway/web/freenode/ip.212.66.221.23) | |
19:07 | eemeli has left IRC (eemeli!d442dd17@gateway/web/freenode/ip.212.66.221.23, Ping timeout: 260 seconds) | |
19:25 | cshubhamrao has left IRC (cshubhamrao!75c666a3@gateway/web/freenode/ip.117.198.102.163, Ping timeout: 260 seconds) | |
19:35 | lucascastro has left IRC (lucascastro!~lucas@201.182.221.154, Remote host closed the connection) | |
19:35 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
19:46 | lucascastro has joined IRC (lucascastro!~lucas@200.141.207.18) | |
20:21 | lucascastro has joined IRC (lucascastro!~lucas@201.182.221.154) | |
20:23 | kjackal has left IRC (kjackal!~quassel@athedsl-237682.home.otenet.gr, Ping timeout: 248 seconds) | |
20:32 | kjackal has joined IRC (kjackal!~quassel@athedsl-237682.home.otenet.gr) | |
20:46 | nehemiah has joined IRC (nehemiah!~nehemiah@137.26.129.150) | |
20:49 | <nehemiah> Can the script that's called with 'LDM_SESSION' somehow know the password and username that was just used to log in? I was hoping to have make some webdav mounts. The username and password will be the same for each user.
| |
20:50 | I mean the username and password to mount the webdav share will be the same as for logging into the client since we use LDAP.
| |
20:52 | lucascastro has left IRC (lucascastro!~lucas@201.182.221.154, Remote host closed the connection) | |
20:54 | <vagrantc> it's not made available
| |
20:55 | that would be more possible with the plans to replace LDM with a proper pam environment ... but that's been in progress for ... too many years now
| |
21:03 | gp has left IRC (gp!~gp@96.71.93.13, Ping timeout: 246 seconds) | |
21:33 | kjackal has left IRC (kjackal!~quassel@athedsl-237682.home.otenet.gr, Ping timeout: 240 seconds) | |
21:47 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Read error: Connection reset by peer) | |
22:02 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |
22:06 | gp has joined IRC (gp!~gp@2600:1005:b008:f7c8:d09d:82c5:dce7:867d) | |
22:43 | lucascastro has joined IRC (lucascastro!~lucas@201.182.221.14) | |
22:46 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
23:22 | gp has left IRC (gp!~gp@2600:1005:b008:f7c8:d09d:82c5:dce7:867d, Read error: Connection reset by peer) | |