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


Channel log from 3 January 2014   (all times are UTC)

00:00gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Read error: Operation timed out)
00:16freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
00:22PhoenixSTF has left IRC (PhoenixSTF!~rudi@78.29.154.124, Quit: Leaving)
00:30
<alkisg>
Pushed, I hope there are no regressions
00:31freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
00:39alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
00:59Guest14883 is now known as ageis
01:45GEEGEEGEE has left IRC (GEEGEEGEE!~Charles@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net, Quit: Leaving)
01:45GEEGEEGEE has joined IRC (GEEGEEGEE!~Charles@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net)
01:50ageis has left IRC (ageis!kevin@ageispolis.net, Remote host closed the connection)
01:51ageis has joined IRC (ageis!kevin@ageispolis.net)
02:01gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
02:05bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 240 seconds)
02:05bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
02:06gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 264 seconds)
02:14bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 240 seconds)
02:16bennabiy has joined IRC (bennabiy!~Thunderbi@24.181.55.79)
02:24awilliams has left IRC (awilliams!~awilliams@unaffiliated/mistik1, Ping timeout: 246 seconds)
02:29awilliams has joined IRC (awilliams!~awilliams@unaffiliated/mistik1)
03:03gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
03:06gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Read error: Operation timed out)
05:05gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
05:06alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
05:10gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 246 seconds)
05:29bennabiy has left IRC (bennabiy!~Thunderbi@24.181.55.79, Ping timeout: 263 seconds)
05:33bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
05:38alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
05:43
<gdi2k>
I have one machine which is not showing up on epoptes for some reason - there is nothing unique about this machine - it doesn't have its own lts.conf section or anything like that. it's always the same machine. any ideas?
06:08gdi2k has left IRC (gdi2k!~gdi2k@222.127.254.113, Ping timeout: 240 seconds)
06:13gdi2k has joined IRC (gdi2k!~gdi2k@222.127.254.113)
06:33pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Read error: Connection reset by peer)
06:37pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)
07:02gdi2k has left IRC (gdi2k!~gdi2k@222.127.254.113, Ping timeout: 240 seconds)
07:08gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
07:14gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 264 seconds)
07:30bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 240 seconds)
07:34bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
07:41gdi2k has joined IRC (gdi2k!~gdi2k@222.127.254.113)
07:41freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
07:59alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
08:01* alkisg waves to vagrantc
08:02
<gdi2k>
alkisg, good morning! :) I'm trying to get a fat client with two monitors to accept my xrandr line with XRANDR_COMMAND_01 - can I do that with fat clients?
08:02
<alkisg>
Sure, I think it's _1 though
08:02
<gdi2k>
(I saw you committed that bug fix, so you're probably the right guy to talk to)
08:03* vagrantc waves to alkisg
08:03
<alkisg>
And for the fun of it, some hours ago I pushed a fix that accepts _01 too :D
08:03
<gdi2k>
lol - ok trying with 1
08:03
<alkisg>
Errrr although not for XRANDR_COMMAND, I need to do that too :(
08:04
vagrantc: do you have some time to talk about directive names?
08:04
We want to run scripts on these phases: INITRD/INIT/RC/DM/AUTH/LOGIN/SESSION/PERIODIC/LOGOUT/SHUTDOWN
08:04
(or in general, have hooks there)
08:04
ltsp-cluster has boot, prompt, login|ldm, logout, refresh
08:04
RUN_PHASE_0? Or PHASE_COMMAND_0?
08:04
And, if the PHASE names are OK...
08:04
E.g. I don't like PERIODIC at all
08:05
<gdi2k>
alkisg, thank you, it works with 1, not 01
08:06
<vagrantc>
alkisg: periodic ~= cron ?
08:06
<alkisg>
vagrantc: yes, ask the server periodically to check for new things to do
08:06
E.g. shutdown_time=now
08:08
The shutdown event is to notify the server to release possible resources (swap? dns entries?) that the client needed
08:13* alkisg wants to start cleaning up the "get configuration from the server" part, so that then applying ltspd client-side is the same as changing 1 function only
08:17
<alkisg>
vagrantc: isn't /run a better place for ltsp_config_env, than /var/cache ?
08:20
<vagrantc>
alkisg: sure, it's just /var/cache was there long before /run existed
08:20
<alkisg>
vagrantc: /var/run ?
08:20
<vagrantc>
well, we decided on cache
08:21
since it was... cached values
08:21
obviouslt couldn't survive a reboot
08:21
<alkisg>
Are they supposed to survive reboots?
08:21
<vagrantc>
that's what /var/cache is for
08:21
<alkisg>
Also, they're not cached values
08:21
<vagrantc>
data that could be recreated, but nice to cache if you can
08:21
<alkisg>
They can't be recreated
08:22
<vagrantc>
but sure, /run would be a better place for it
08:22
you feed them the same input, and they'll produce the same data.
08:25* vagrantc hopes most distros have adopted /run by now
08:26
<vagrantc>
or at least /var/run
08:26
<alkisg>
We already rely on it... if it doesn't exist somewhere, we can create/symlink it on boot
08:27
<vagrantc>
what relies on /run in the current code that isn't related to initramfs-tools ?
08:27* alkisg was thinking initramfs tools, sorry :)
08:27
<vagrantc>
which is pretty distro-specific
08:28
<alkisg>
The dir doesn't matter much, the main thing I want to do is to clean up our client-side configuration code
08:28
For example, to merge all ltsp-cluster calls with the main "ltsp_config" calls
08:29
ltsp-cluster was right there, we do need to poll lts.conf in various phases
08:29
<vagrantc>
right
08:30
<alkisg>
So basically ltsp_config will somehow grow a parameter, for the phase where we're calling it from
08:32
vagrantc: what's the difference between /var/cache/ltsp/ltsp_config and /var/cache/ltsp/ltsp_config_env ?
08:34
Hehe, ALTLinux is always special!... ./client/ALTLinux/initscripts/ltsp-client-setup.default:temp_copy_dirs="/var/cache/ltspconf"
08:34
<vagrantc>
alkisg: i don't remember
08:35
<alkisg>
vagrantc: I think init-ltsp.d/04-server just needs to call set_lts_var instead of echo >> ltsp_config
08:35
<vagrantc>
there was some login to ltsp_config ltsp_config_env
08:37
<alkisg>
$ grep -rl /var/cache/ltsp/ltsp_config .
08:37
./client/getltscfg-cluster/getltscfg-cluster
08:37
./client/share/ltsp/init-ltsp.d/04-server
08:37
./client/share/ltsp/init-ltsp.d/01-clean-cache
08:37
./client/share/ltsp/init-ltsp.d/03-kernel-cmdline
08:37
./client/share/ltsp/ltsp_config
08:37
./client/share/ltsp/ltsp_config.d/00-ltspconfig-cache
08:37
./client/Debian/share/ltsp/init-ltsp.d/50-client-mac
08:38
I think these need to be "converted" to use set_lts_var
08:39
<vagrantc>
some logic to the two files...
08:39
but i don't remember, and i'll sleep on it. :)
08:39* vagrantc thinks this is some code that has flip-flopped several times
08:40
<alkisg>
...and it still doesn't make sense :)
08:40
Goodnight vagrantc
08:43gdi2k has left IRC (gdi2k!~gdi2k@222.127.254.113, Quit: Leaving)
08:45vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Ping timeout: 246 seconds)
08:46gdi2k_ has joined IRC (gdi2k_!~gdi2k@222.127.254.113)
08:49
<gdi2k_>
alkisg, I have one fat client not showing up in epoptes - how can I go about diagnosing the issue? it isn't different to other clients and has no specific lts.conf entry etc.
09:03bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 240 seconds)
09:04gdi2k_ has left IRC (gdi2k_!~gdi2k@222.127.254.113, Ping timeout: 240 seconds)
09:06bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
09:12gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
09:13gdi2k_ has joined IRC (gdi2k_!~gdi2k@222.127.254.113)
09:14
<alkisg>
gdi2k_: try putting this in lts.conf: EPOPTES_CLIENT_VERIFY_CERTIFICATE=False
09:14
...and reboot client
09:17gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 264 seconds)
09:28
<gdi2k_>
alkisg, still the same
09:28
<alkisg>
gdi2k_: it doesn't show up at all after the reboot?
09:29
Or it shows up for a while, and then disconnects?
09:30
<gdi2k_>
alkisg, no, it never shows up. I just rebooted and watched carefully
09:31
<alkisg>
gdi2k_: ok, login and run /usr/sbin/epoptes-client manually, and see its output
09:34
<gdi2k_>
alkisg, it shows "Connecting to [serverip]:789... done...
09:34
nothing more
09:34
<alkisg>
gdi2k_: it says done, and you still don't see it in the ui?
09:34
<gdi2k_>
yes, not showing up still
09:35
<alkisg>
It's an ltsp fat client, right?
09:35
<gdi2k_>
yes
09:35
like the others, but all the others show up
09:35
<alkisg>
OK I don't know, want me to check with remote support (vnc)?
09:35
<gdi2k_>
that would be fantastic! do you have x2go ?
09:35
<alkisg>
x11vnc -connect alkisg.dyndns.org, both from the client and the pc where the epoptes ui runs
09:36
<gdi2k_>
ah ok
09:36
<alkisg>
It's also in the epoptes ui help menu :)
09:36
<gdi2k_>
hehe
09:37
client missing is 164 - connecting now...
09:41
<alkisg>
gdi2k_: ok,
09:41
it was a known problem (2 vga cards) that was solved 2 years ago
09:41
You just have an old epoptes version
09:41
I manually applied the fix,
09:41
<gdi2k_>
alkisg, ah ok, thanks so much!
09:41
<alkisg>
now you need to (1) reboot clients (2) while they're rebooting, run sudo service epoptes restart, (3) restart epoptes UI
09:45
<gdi2k_>
alkisg, magic, working now :)
09:45
<alkisg>
:)
09:46
<gdi2k_>
and you're right, it does have two graphics cards! from the days I was playing with multi-seat configs
09:47
good idea to update epoptes using the ppa? https://launchpad.net/~epoptes/+archive/ppa
09:49freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
09:50khildin has joined IRC (khildin!~khildin@ip-80-236-219-142.dsl.scarlet.be)
09:56
<alkisg>
Yes it's a good idea
09:56
It's stable
09:56
<gdi2k_>
ok will do, thank you
10:20christophe_y2k1 has joined IRC (christophe_y2k1!~christoph@man06-3-78-237-22-85.fbx.proxad.net)
10:38gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
11:02willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
11:12GrembleBean has joined IRC (GrembleBean!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net)
11:47gbaman_ has joined IRC (gbaman_!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
11:51gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 240 seconds)
11:51gbaman_ has left IRC (gbaman_!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 240 seconds)
12:12gdi2k_ has left IRC (gdi2k_!~gdi2k@222.127.254.113, Ping timeout: 240 seconds)
12:12GrembleBean has left IRC (GrembleBean!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net, Ping timeout: 264 seconds)
12:25gbaman has joined IRC (gbaman!~gbaman@host81-147-184-194.range81-147.btcentralplus.com)
12:40
<alkisg>
http://lartc.org/howto/lartc.ratelimit.single.html
12:45khildin has left IRC (khildin!~khildin@ip-80-236-219-142.dsl.scarlet.be, Quit: I'm gone, bye bye)
12:47bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 240 seconds)
12:47andygraybeal has left IRC (andygraybeal!~andy@h107.218.213.151.dynamic.ip.windstream.net, Ping timeout: 245 seconds)
12:48bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
13:02
<alkisg>
http://serverfault.com/questions/174010/limit-network-bandwith-for-an-ip
13:02
# tc qdisc del dev vboxnet0 root
13:02
# tc qdisc add dev vboxnet0 root handle 1: htb default 1
13:02
# tc class add dev vboxnet0 parent 1: classid 1:1 htb rate 1mbps ceil 2mbps
13:09alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)
13:42bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 240 seconds)
13:50gbaman has left IRC (gbaman!~gbaman@host81-147-184-194.range81-147.btcentralplus.com, Remote host closed the connection)
13:53other_other_joe has joined IRC (other_other_joe!~joe@c-50-148-87-93.hsd1.il.comcast.net)
13:53bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
13:57gbaman has joined IRC (gbaman!~gbaman@host81-147-184-194.range81-147.btcentralplus.com)
14:05freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
14:11willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Quit: Computer has gone to sleep.)
14:16cliebow has joined IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us)
14:30freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
14:45GEEGEEGEE has left IRC (GEEGEEGEE!~Charles@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net, Ping timeout: 246 seconds)
14:46GEEGEEGEE has joined IRC (GEEGEEGEE!~PrepareYo@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net)
14:46gbaman has left IRC (gbaman!~gbaman@host81-147-184-194.range81-147.btcentralplus.com, Remote host closed the connection)
14:47gbaman has joined IRC (gbaman!~gbaman@host81-147-184-194.range81-147.btcentralplus.com)
14:49gbaman has left IRC (gbaman!~gbaman@host81-147-184-194.range81-147.btcentralplus.com, Remote host closed the connection)
15:14
<other_other_joe>
does anyone know the specifics on how the /etc/passwd file in the chroot is put together, post boot?
15:14
it looks to be a composit of the ltsp servers passwd and it's own?
15:18work_alkisg has joined IRC (work_alkisg!~alkisg@194.63.234.224)
15:19work_alkisg has joined IRC (work_alkisg!~alkisg@194.63.234.224)
15:29
<||cw>
other_other_joe: yeah, the info for the logged in user only is copied to it durring client setup process
15:30
<work_alkisg>
Yey!!! TCP rate limiting worked around the notorious ethernet flow control issue!!!
15:30work_alkisg is now known as alkisg
15:36
<alkisg>
Before tcp rate limiting:
15:36
[ 5] 0.0-10.2 sec 18.5 MBytes 15.3 Mbits/sec
15:36
[ 4] 0.0-10.1 sec 18.0 MBytes 14.9 Mbits/sec
15:36
After:
15:36
[ 5] 0.0-10.0 sec 66.1 MBytes 55.3 Mbits/sec
15:36
[ 4] 0.0-10.0 sec 66.1 MBytes 55.3 Mbits/sec
15:38
<||cw>
so I got pulled away yesterday.... I have a dhcpd process running, and 'service isc-dhcp-server' starts and stops the process but with errors in the log, but process still runs. but /etc/init.d/isc-dhcp-server stop errors without stopping, and start errors out and same errors in the log but no process running. is that a isc-dhcp-server scripts packaging issue, or is ltsp modifying the upstart config and not the init.d config?
15:39
<alkisg>
||cw: paste some logs and errors, it sounds like an issue in your configuration...
15:39
<||cw>
also on the errors in the logs, "No subnet declaration for eth1 (10.213.1.1)" but ltsp/dhcpd.confg has a "subnet 10.213.1.0 netmask 255.255.255.0" section, and eth1 has the IP mentioned
15:40
I had this working 2 weeks ago, but had to start over and I'm totally failing to see what I've done different
15:40
<alkisg>
Put all of your configuration to pastebin
15:40
dhcpd.conf, ip addresses etc etc
15:42
<other_other_joe>
the logged in user does get appened, yea. some extra goodies are making there way into etc password somehow though and I'm trying to figure out from where
15:42
<||cw>
http://pastebin.com/sTZ0skhq
15:42
ifconfig and route both show what I'd expect for that interfaces file
15:42
<other_other_joe>
a user that was in my servers /etc/passwd but has since been dropped is still making his way into the /etc/passd on the booted fat client
15:43
<alkisg>
||cw: also the /etc/default/*dhcp* file
15:43
(don't remember the exact name, it's been years since I've switched to dnsmasq)
15:43
<||cw>
I added eth1 to interfaces, this is the process that's running: dhcpd -user dhcpd -group dhcpd -f -q -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/ltsp/dhcpd.conf eth1
15:45
/etc/default/isc-dhcp-server has INTERFACES="eth1"
15:45
<alkisg>
I think you're supposed to leave that empty for an easier configuration, but ok that sounds fine
15:45
And the output of service isc stop / start?
15:45
<||cw>
sure, but I don't want it listening on eth0
15:45
<alkisg>
It won't, since it doesn't have a subnet there
15:45
From dhcpd.conf
15:46
<||cw>
isc-dhcp-server start/running, process 23990
15:46
<alkisg>
...so it runs fine?!
15:46
<||cw>
but gives that error in the logs
15:47
<alkisg>
The exact error is this? "No subnet declaration for eth1 (10.213.1.1)"
15:47
<||cw>
ah, so now taking like out of the defaults file, it no longer errors on eth1, but does on eth0, which I guess is OK
15:47Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
15:47
<||cw>
weird.
15:49
<alkisg>
I think the correct way to edit that file is with sudo dpkg-reconfigure isc*
15:52
<other_other_joe>
indeed
15:54
<||cw>
k, so on the init vs init.d, is it ltsp that adds the /etc/ltsp/dhcpd.conf check to the script, or is that in the isc-dhcp-server package? the 2 scripts are out of sync.
15:55
i know service is the preferred way, but if init.d is broken it should say so, or just call the service commands
15:55
but is that an ltsp issue or an isc issue?
15:56
hm the 2 script don't even keep the pid in the same place, so i'm guessing it's a bigger isc issue.
15:59gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
16:04
<alkisg>
||cw: ah, isc ships both a sysvinit script and an upstart job, and they don't even match each other/
16:05
<||cw>
yeah, i think that confused me at the start and got me off track
16:05
<alkisg>
Yeah it sounds like you should file a bug report to dhcp
16:05
<||cw>
yup, doing it now
16:05
<alkisg>
I think that it shouldn't have 2 scripts
16:05
If built on debian, it should ship the sysvinit script, and if built on ubuntu, the upstart job
16:06
I wonder if you have both of them because of some upgrade?
16:06* alkisg hopes ltsp doesn't have anything to do with all that...
16:13
<||cw>
well, the sysvinit doens't do ltsp/dhcpd.conf detection...
16:14
at least ubuntu's version doens't
16:15
ubuntu's samba package just puts "if upstart bail" code in the sysvinit script, which would be good enough for me
16:17
it's not an upgrade, started from 13.10 mini.iso and installed minimal, then added ltsp-server-standalone
16:18
even if it were an upgrade, good packaging would remove unmodified obsolete scripts
16:18
<alkisg>
Sure, I'm just trying to help pinpoint where the blame is
16:19
<other_other_joe>
alksig: do you know off the top of your head what files are parsed to build the /etc/password file when a client boots?
16:20
<alkisg>
other_other_joe: the server's /etc/passwd and group
16:21
<other_other_joe>
it then combines it with the /etc/passwd in the choot and then tacks on the ldm logged in user?
16:22James_Epp has left IRC (James_Epp!~Thunderbi@001dcf920408.cpe.westmancom.com, Quit: James_Epp)
16:22
<alkisg>
Yes, it keeps a backup of the client's /etc/passwd in /var/ltsp/somewhere, and merges them with what it gets from the server
16:25
<other_other_joe>
there's my culprit
16:25
$CHROOT:/var/cache/ltsp-localapps/passwd
16:25
it doesn't seem to be re-caching these
16:26
<alkisg>
It only gets them once, it needs rebooting to get them again
16:26
<other_other_joe>
they're in my chroot for some reason
16:26
I'm assuming they shouldn't be...
16:26
so they're there perminantly
16:27
<alkisg>
OK, that would cause problems... ltsp should delete them on boot though, but never mind, we'll be switching to libpam-sshauth anyway :)
16:27
<other_other_joe>
haha
16:28
with ltsp6?
16:28
<alkisg>
Yup
16:28
<other_other_joe>
hope that plays nice with ldap :)
16:29
<alkisg>
Making ltsp work with pam means that you'll only need to change a couple of lines to switch from libpam-sshauth to ldap, samba etc
16:31
<other_other_joe>
If I remember correctly I already needed to play with pam in the chroot a bit to get it to play nice with ldap in order to get the screenlock to correctly unlock
16:31
since it re-auth's an' all
16:31
so I'm not scared
16:32
<||cw>
pam is really pretty awesome, really long lived without any perceptible major changes
16:34
<other_other_joe>
either of you using NFS for your root still or strickly NBD?
16:35
<alkisg>
NBD, AOE, NFS... sure
16:35
<other_other_joe>
i was reading about the kiwi folks using AOE
16:36
NFS seems nice and resilient though
16:36
<alkisg>
Speed: AOE > NBD > NFS
16:37
Stability: AOE ~= NFS > NBD
16:37
<other_other_joe>
NBD will choke if my server dies though, yea?
16:37
it won't re-connect when the server comes back up I mean?
16:37
<alkisg>
If your server dies, ssh, X, and pretty much everything in the running client will die too
16:37
So it doesn't matter anyway
16:37
<other_other_joe>
well, they're fat
16:37
so, none of that really matters
16:37
<alkisg>
The ssh connection won't get reestablished
16:38
So you'll lose the sshfs home under your running processes
16:38
And all the data will get lost
16:38
<other_other_joe>
home's are nfs too
16:38
<alkisg>
That's a bit better then
16:38
<other_other_joe>
I can reboot my server now, they'll freeze, but then pick up where they left off just fine
16:39
<alkisg>
NFS is the best way to share /home, indeed. We only have sshfs to compare it to, not NBD nor AOE.
16:39
<other_other_joe>
I'd like to force nfsv4 for the root though
16:39
it's defaulting to v3
16:40
<alkisg>
FSTAB_x in lts.conf for /home?
16:40
Ah, for the root
16:40
<other_other_joe>
oh, for home v4 is working fine
16:40
<alkisg>
initramfs-tools don't support nfs4
16:40
<other_other_joe>
oh
16:40
<alkisg>
You'd need dracut for that or something
16:40
<other_other_joe>
hmm
16:41
I was reading up on pNFS after we talked about it a while back
16:41
I couldn't really work out a good way to implement it without building out a reasonably expensive storage cluster
16:42
<||cw>
stgraber: really? "you get errors because you're running the wrong script" is the solution? I've using debian so long that /etc/init.d/ is something my fingers do on their own, leaving that file there to do something unexpected is a bug.
16:43
<other_other_joe>
my fingers just don't wanna type service etc etc
16:43
<alkisg>
other_other_joe: where would you use pNFS? To balance /home into different servers?
16:43
E.g. locally too?
16:44
<other_other_joe>
yea I was thinking that
16:44
for high availability
16:44
<||cw>
at least service has tab completion now, maybe I can start to re-train now.
16:44
<alkisg>
But then if one client had an issue, the user would go to another client, and ...wouldn't find his /home/username? Or does it do duplication too?
16:45
<other_other_joe>
yea, it would duplication amount 3 servers
16:45
if you were using ceph or gluster or something
16:46
I've decided to go another route though. I've got 2 nodes clustered together sharing a primary/primary drbd volume
16:46
home is mirrored to both nodes
16:47
<alkisg>
How many clients do you have?
16:47
<other_other_joe>
if one dies, traffic is auto routed to the other with 30 seconds
16:47
about 70
16:47
<stgraber>
||cw: removing those scripts will just make our delta with Debian worse so I won't do that, checking for every non-sysvinit init system in the init script isn't very practical either so that's being discouraged. The real fix would be to have lsb's init-functions do the check and show an error message at that point (which would magically consistently apply to all existing init scripts)
16:47
<alkisg>
other_other_joe: and e.g. 2 bonded gigabit nics + an ssd disk for /home aren't enough?
16:48
<other_other_joe>
have those as well
16:48
<||cw>
stgraber: oh I'm not suggesting to remove it, but should not be feature equivalent? they aren't
16:48
<stgraber>
||cw: but all of that mess is currently tied into the systemd vs upstart discussion so nobody really wants to do anything until it's settled
16:48
<other_other_joe>
each box has 2 bound gigabit NICs in mode and 2 SSD's in RAID1
16:48
<||cw>
stgraber: it's not just that it fails, it's that what the 2 scripts do is out of sync
16:49
<other_other_joe>
my whole operation is running on them though
16:49
<stgraber>
||cw: if Debian had an active maintainer who cared about the init.d script, they may end up being in sync, unfortunately that's not the case and I only care about the upstart jobs
16:49
<other_other_joe>
they have to be fast as sh** and always up
16:49
<||cw>
stgraber: once has ltsp/dhcpd.conf detection, one doens't
16:49
and would it be horrible if they used the same PID file?
16:49
given those 2 things, you could run either and it would behave as expected
16:52
<other_other_joe>
the NFS read/writes from web browsers are still adding a bunch of traffic I'd like to cut down though
16:52
<stgraber>
||cw: so to clarify, the policy is that when something is upstartized, Ubuntu no longer cares about the init.d (sysvinit) script and simply let Debian deal with those. Debian doesn't want ltsp/dhcpd.conf so that file isn't there, as for the pid file location, Ubuntu needs it in a separate dir as we run our daemon unprivileged, Debian doesn't drop privileges so uses the default pid file locaiton.
16:52
<other_other_joe>
I'm trying to work out a good implementation of profile-sync-daemon or similar into my setup
16:53
and dump browser cache to a tmpfs
17:06alkisg is now known as work_alkisg
17:29khildin has joined IRC (khildin!~khildin@ip-80-236-219-142.dsl.scarlet.be)
17:35Phantomas1 has joined IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas)
17:35gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, )
17:37Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 252 seconds)
17:44GrembleBean has joined IRC (GrembleBean!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net)
17:55b3x has joined IRC (b3x!~brian@out.ewbc.com)
18:04christophe_y2k1 has left IRC (christophe_y2k1!~christoph@man06-3-78-237-22-85.fbx.proxad.net, Quit: Leaving.)
18:06GrembleBean has left IRC (GrembleBean!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net, Quit: I Leave)
18:12laprag has joined IRC (laprag!~ragnar@ti0071a380-dhcp1620.bb.online.no)
18:12GEEGEEGEE has left IRC (GEEGEEGEE!~PrepareYo@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net, Ping timeout: 272 seconds)
18:53ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 260 seconds)
18:54ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
19:00vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
19:01cliebow has left IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us, Quit: Ex-Chat)
19:39judy_ has joined IRC (judy_!c98f4fd3@gateway/web/freenode/ip.201.143.79.211)
19:39
<judy_>
hello
19:39
we are looking for LTSP for SUSE 11
19:39
could you help us with the link to download the package
19:41
<vagrantc>
!opensuse
19:41
<ltsp>
opensuse: http://en.opensuse.org/LTSP
19:41
<vagrantc>
!kiwi-ltsp
19:41
<ltsp>
kiwi-ltsp: for kiwi-ltsp related questions, you can also ask in the #kiwi-ltsp freenode IRC channel, or visit http://en.opensuse.org/LTSP
19:41
<vagrantc>
judy_: ^^
19:41
<judy_>
and it will be the same in SUSE 11 ??
19:42||cw has left IRC (||cw!~chris@phpgroupware/cw, Ping timeout: 260 seconds)
19:42* vagrantc doesn't use suse...
19:44
<vagrantc>
cyberorg: does the kiwi-ltsp opensuse stuff work on suse as well?
19:53||cw has joined IRC (||cw!~chris@phpgroupware/cw)
19:54
<||cw>
stgraber: is /var/lib/dhcp/dhcpd.leases supposed to be chown root:root? seems odd since it runs under user dhcpd
20:01
<stgraber>
||cw: I'd have to re-read the code to refresh my memory there but I think it was a change which happened between the switch from the Ubuntu patch to upstream's paranoid option. In the past the lease file would be opened after privileges were dropped (so owned dhcpd:dhcpd) but nowadays dhcpd drops privileges after opening the fd so the file can be root owned.
20:02
though if you got an actual error from dhcpd saying it couldn't open it, then maybe that changed again somehow...
20:04khildin has left IRC (khildin!~khildin@ip-80-236-219-142.dsl.scarlet.be, Quit: I'm gone, bye bye)
20:10
<||cw>
yeah, it's failing. each new client I get dhcpd: Can't create new lease file: Permission denied
20:10
and I'm not the only one http://ubuntuforums.org/showthread.php?t=2141740
20:11
<vagrantc>
sounds like it should be a bug report rather than a forum post...
20:13
<||cw>
I think that was just trying to gauge if it was a bug or him doing something dumb... like I do here :)
20:14
I'm going to comment out the chown root code and run a while and see what happens.
20:17
what's bugging me about this... I have this basic server vm, copied to a new host but kept the original, config'd everything, no issues that I noticed. raid card flacked and lost it all. go back to the original and copy again and all these issues.
20:17
so did i just ignore them the first time, or did i do something different to screw it up?
20:18
<vagrantc>
did the mac addresses change at all?
20:18
<||cw>
no, but I'm not sure that would mater
20:19
<vagrantc>
it could end up rearranging the device order
20:19
<||cw>
it started with a single nic
20:19
<vagrantc>
but that would cause other issues, not what you're experiencing
20:20
<||cw>
I added the 2nd nic just before installing the ltsp package
20:20vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
20:20
<||cw>
well, mostly I'm experiencing issues with dhcpd packaging, but it seems if i'd ignored them it would work properly, at least for a while
20:26freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
20:29Phantomas1 has left IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas)
20:57b3x has left IRC (b3x!~brian@out.ewbc.com, Quit: Leaving)
21:10vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
21:19alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
21:25
<alkisg>
Anyone knows `tc` well, to help in scripting the solution to the ethernet flow control issue? https://www.mail-archive.com/ltsp-discuss@lists.sourceforge.net/msg41605.html
21:29freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Ping timeout: 245 seconds)
21:30
<alkisg>
lartc.pdf... 150 pages... ok how bad can that be? :P
21:33
<vagrantc>
has this always been a problem? or is it some recent change?
21:33
<alkisg>
It's always been a problem
21:33
<vagrantc>
did something make it worse, or did someone just finally figure it out
21:33
<alkisg>
And we had to throw away some hardware like e.g. gigabit atheros NICs
21:34
I figured out a way to work around broken cases where the flow control can't be disabled
21:34
Now I need to find a good way to script the solution
21:34
Either as part of epoptes, or as part of ltsp (optional setting)
21:37
<vagrantc>
the problem is essentially a gigabit nic on the server sending data too fast for the 100mb nic on the client, and the switch throttles the server?
21:37
<alkisg>
Basically it was possible for a gigabit server <=> switch connection to only work at 100 mbps or even less, because of bad firmware in nic and switch
21:37
Yup, like you said it
21:38
Good switches or good server NICs can solve the problem, but when those don't exist, a workaround is needed, and I think I just found one...
21:38
Previously, a teacher that had a laptop with atheros nic couldn't make it an ltsp server with 100mbps clients, now he'll hopefully be able too..
21:43freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
22:03
<||cw>
alkisg: does it need to match client ip's, or could it match protocols instead?
22:04
<alkisg>
||cw: currently I made it work by matching client IPs and sending them to their own class that limits the bandwidth
22:04
If I used a single class for all of them, I couldn't limit the bandwidth per client
22:04
<||cw>
ah
22:05
<alkisg>
I do hope there's another way that doesn't involve finding out the client IPs...
22:06
<||cw>
does dhcpd support any hooks that could add a class and filter when handing out a new ip?
22:08
<alkisg>
We can use the nbd server hooks, or we can implement that in epoptes which manages all the client IPs anyway,
22:09
but first I want to see if it's doable with some other way...
22:22alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
22:40judy_ has left IRC (judy_!c98f4fd3@gateway/web/freenode/ip.201.143.79.211, Quit: Page closed)
23:16andygraybeal has joined IRC (andygraybeal!~andy@h96.194.213.151.dynamic.ip.windstream.net)
23:24laprag has left IRC (laprag!~ragnar@ti0071a380-dhcp1620.bb.online.no, Quit: Lost terminal)
23:48GEEGEEGEE has joined IRC (GEEGEEGEE!~PrepareYo@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net)