Re: Some notes on LTSP client boot speed
> Not quite sure how we can fix this, but it seem to me that the
> dynamic lookup stuff for LTSP need to be changed to get the clients
> booting faster. I suspect we need to change the dynamic stuff to
> not run when the clients boot but when the LTSP server is installed
> or boot.
I've looked more into this, I tried to improve the situation.
The DNS lookup stuff originially was added in Lenny to work around the
fact that LTSP was failing to generate resolv.conf based on the DHCP
information provided when it booted. This seem to be a bug in LTSP,
and I've reported #593770 against ltsp-client-core to track this
problem. Vagrant is on the case, and I hope we can get the fix into
Squeeze. While we wait for that to happen, I added a workaround in
debian-edu-config. The workaround make sure the values fetched via
DHCP is passed on to the LTSP code generating resolv.conf, and thus
remove the need to trying to search for the DNS server. The DNS
related lookup code is removed from ltsp_config.d, and this slowdown
should thus be no more. This change would be useful in Lenny too.
For the LDAP lookup code, I changed it to not run before resolv.conf
is generated, making sure DNS lookup work. I also added caching to
make sure it only try to connect to the LDAP server once, to make sure
the slowdown during boot is neglectable. There is something wrong
with the caching code, as the script seem to run 15 times when I test
it, but the operation seem to be quick with my virtual machines. I
hope the same is true when I test with real hardware. :)
Please give squeeze-test a try and let me know if the LTSP clients
boot as they should when you test it? I wonder if clients booted of
standalone LTSP server boot as well as clients booted of a combined
main-server+thin-client-server machine. There were some issues with
powerdns replying using one address and replying using another in
Lenny, which caused glibc to reject the DNS replies, and I hope this
is no longer the case in Squeeze.