00:00 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Read error: Operation timed out) | |
00:16 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
00:22 | PhoenixSTF has left IRC (PhoenixSTF!~rudi@78.29.154.124, Quit: Leaving) | |
00:30 | <alkisg> Pushed, I hope there are no regressions
| |
00:31 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish) | |
00:39 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
00:59 | Guest14883 is now known as ageis | |
01:45 | GEEGEEGEE has left IRC (GEEGEEGEE!~Charles@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net, Quit: Leaving) | |
01:45 | GEEGEEGEE has joined IRC (GEEGEEGEE!~Charles@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net) | |
01:50 | ageis has left IRC (ageis!kevin@ageispolis.net, Remote host closed the connection) | |
01:51 | ageis has joined IRC (ageis!kevin@ageispolis.net) | |
02:01 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
02:05 | bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 240 seconds) | |
02:05 | bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com) | |
02:06 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 264 seconds) | |
02:14 | bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 240 seconds) | |
02:16 | bennabiy has joined IRC (bennabiy!~Thunderbi@24.181.55.79) | |
02:24 | awilliams has left IRC (awilliams!~awilliams@unaffiliated/mistik1, Ping timeout: 246 seconds) | |
02:29 | awilliams has joined IRC (awilliams!~awilliams@unaffiliated/mistik1) | |
03:03 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
03:06 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Read error: Operation timed out) | |
05:05 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
05:06 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
05:10 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 246 seconds) | |
05:29 | bennabiy has left IRC (bennabiy!~Thunderbi@24.181.55.79, Ping timeout: 263 seconds) | |
05:33 | bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com) | |
05:38 | alkisg 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:08 | gdi2k has left IRC (gdi2k!~gdi2k@222.127.254.113, Ping timeout: 240 seconds) | |
06:13 | gdi2k has joined IRC (gdi2k!~gdi2k@222.127.254.113) | |
06:33 | pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Read error: Connection reset by peer) | |
06:37 | pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme) | |
07:02 | gdi2k has left IRC (gdi2k!~gdi2k@222.127.254.113, Ping timeout: 240 seconds) | |
07:08 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
07:14 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 264 seconds) | |
07:30 | bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 240 seconds) | |
07:34 | bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com) | |
07:41 | gdi2k has joined IRC (gdi2k!~gdi2k@222.127.254.113) | |
07:41 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
07:59 | alkisg 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:43 | gdi2k has left IRC (gdi2k!~gdi2k@222.127.254.113, Quit: Leaving) | |
08:45 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Ping timeout: 246 seconds) | |
08:46 | gdi2k_ 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:03 | bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 240 seconds) | |
09:04 | gdi2k_ has left IRC (gdi2k_!~gdi2k@222.127.254.113, Ping timeout: 240 seconds) | |
09:06 | bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com) | |
09:12 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
09:13 | gdi2k_ 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:17 | gbaman 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:49 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish) | |
09:50 | khildin 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:20 | christophe_y2k1 has joined IRC (christophe_y2k1!~christoph@man06-3-78-237-22-85.fbx.proxad.net) | |
10:38 | gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
11:02 | willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116) | |
11:12 | GrembleBean has joined IRC (GrembleBean!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net) | |
11:47 | gbaman_ has joined IRC (gbaman_!~gbaman@host81-130-35-88.in-addr.btopenworld.com) | |
11:51 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 240 seconds) | |
11:51 | gbaman_ has left IRC (gbaman_!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 240 seconds) | |
12:12 | gdi2k_ has left IRC (gdi2k_!~gdi2k@222.127.254.113, Ping timeout: 240 seconds) | |
12:12 | GrembleBean has left IRC (GrembleBean!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net, Ping timeout: 264 seconds) | |
12:25 | gbaman 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:45 | khildin has left IRC (khildin!~khildin@ip-80-236-219-142.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
12:47 | bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 240 seconds) | |
12:47 | andygraybeal has left IRC (andygraybeal!~andy@h107.218.213.151.dynamic.ip.windstream.net, Ping timeout: 245 seconds) | |
12:48 | bennabiy 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:09 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection) | |
13:42 | bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 240 seconds) | |
13:50 | gbaman has left IRC (gbaman!~gbaman@host81-147-184-194.range81-147.btcentralplus.com, Remote host closed the connection) | |
13:53 | other_other_joe has joined IRC (other_other_joe!~joe@c-50-148-87-93.hsd1.il.comcast.net) | |
13:53 | bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com) | |
13:57 | gbaman has joined IRC (gbaman!~gbaman@host81-147-184-194.range81-147.btcentralplus.com) | |
14:05 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
14:11 | willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Quit: Computer has gone to sleep.) | |
14:16 | cliebow has joined IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us) | |
14:30 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish) | |
14:45 | GEEGEEGEE has left IRC (GEEGEEGEE!~Charles@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net, Ping timeout: 246 seconds) | |
14:46 | GEEGEEGEE has joined IRC (GEEGEEGEE!~PrepareYo@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net) | |
14:46 | gbaman has left IRC (gbaman!~gbaman@host81-147-184-194.range81-147.btcentralplus.com, Remote host closed the connection) | |
14:47 | gbaman has joined IRC (gbaman!~gbaman@host81-147-184-194.range81-147.btcentralplus.com) | |
14:49 | gbaman 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:18 | work_alkisg has joined IRC (work_alkisg!~alkisg@194.63.234.224) | |
15:19 | work_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:30 | work_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:47 | Phantomas 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:59 | gbaman 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:22 | James_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:06 | alkisg is now known as work_alkisg | |
17:29 | khildin has joined IRC (khildin!~khildin@ip-80-236-219-142.dsl.scarlet.be) | |
17:35 | Phantomas1 has joined IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas) | |
17:35 | gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, ) | |
17:37 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 252 seconds) | |
17:44 | GrembleBean has joined IRC (GrembleBean!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net) | |
17:55 | b3x has joined IRC (b3x!~brian@out.ewbc.com) | |
18:04 | christophe_y2k1 has left IRC (christophe_y2k1!~christoph@man06-3-78-237-22-85.fbx.proxad.net, Quit: Leaving.) | |
18:06 | GrembleBean has left IRC (GrembleBean!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net, Quit: I Leave) | |
18:12 | laprag has joined IRC (laprag!~ragnar@ti0071a380-dhcp1620.bb.online.no) | |
18:12 | GEEGEEGEE has left IRC (GEEGEEGEE!~PrepareYo@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net, Ping timeout: 272 seconds) | |
18:53 | ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 260 seconds) | |
18:54 | ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
19:00 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
19:01 | cliebow has left IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us, Quit: Ex-Chat) | |
19:39 | judy_ 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:04 | khildin 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:20 | vagrantc 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:26 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
20:29 | Phantomas1 has left IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas) | |
20:57 | b3x has left IRC (b3x!~brian@out.ewbc.com, Quit: Leaving) | |
21:10 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
21:19 | alkisg 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:29 | freedomrun 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:43 | freedomrun 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:22 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
22:40 | judy_ has left IRC (judy_!c98f4fd3@gateway/web/freenode/ip.201.143.79.211, Quit: Page closed) | |
23:16 | andygraybeal has joined IRC (andygraybeal!~andy@h96.194.213.151.dynamic.ip.windstream.net) | |
23:24 | laprag has left IRC (laprag!~ragnar@ti0071a380-dhcp1620.bb.online.no, Quit: Lost terminal) | |
23:48 | GEEGEEGEE has joined IRC (GEEGEEGEE!~PrepareYo@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net) | |