[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Today's experiences installing skolelinux at a school

Hi Frenklin,

On  So 30 Mär 2014 16:46:45 CEST, Franklin Weng wrote:

Was that login on another client on the Debian Edu network that failed or
user/admin login on TJENER?

On tjener.

Hmmm... ok. Then KDC would normally not notice that (because the times on client and server (same machine) are identical). Maybe there indeed is some timestamp issue in recent OpenLDAP versions that I have not stumbled upon, yet.

The time critical service is the KDC (Kerberos) daemon. If a client
differs in time by more than five minutes, Kerberos will deny login.

Got it.  Thanks for the information.

Time differences between client+server is actually the first issue I check when having Kerberos ticket retrieval problems.

Uh... DNS is in LDAP, and if LDAP was inaccessible due to DNS issues…
Looks a bit strange.

DNS information is stored in LDAP and via GOsa² hooks synced to files in /etc/bind. Check ldap2bind and ldap2zone scripts in package ldap2zone.

For this problem now I can assign the ip of ldap and ldap.intern in
/etc/hosts as a workaround.  I just don't know if this should be reported
as a bug or not.

It actually should be handled by the subnet-change script. Probably indeed by adding ldap.intern to /etc/hosts for the interim phase of everything being rattled to pieces before it is re-assembled with the new IP adress scheme.

3. The performance was not as good as our last test.  We wondered if it
because of the quality of the LAN.  One of the client could boot and
into the system, but when operating (for example, browsing web pages or
using some software) it disconnected with the main server, hence had
problems writing configs back to home folder.

Urgh... that is strange. Maybe DNS problems, as well. I noticed earlier,
that Debian Edu systems behave weirdly, if upstream (internet) DNS is
unavailable. Not sure why.

DNS worked that time I think.


Yesterday we went there again and was sure that LAN is gigabit and worked
well.  It means that we still didn't find out why.

Another problematic scenario was that, the teacher asked (about nearly 30)
students to download a video clip from youtube. Then 10 of them experienced
network problem.  They could no longer connect to anywhere until they

A classroom full of youtube watchers is not a good idea, at all. But the system should slow down, rather then break.

Have you tried setting the NFSv4 options setup from sync to async? In another post from Wolfgang Schweer I read today that there is such an issue in the Debian Edu wheezy system.

4. When clicking the menu icon, it would sometimes show the menu very
slowly, maybe after 5 or more seconds.  Also when I pointed the mouse to
category, it would sometimes show the second layer menu very slowly.  Was
it because the home folder was remotely mounted?  Is there any way to
improve this?

This happens, because on first menu clicks the .desktop files are read
from disk/NFS. Next time, menus are obtained from the diskless client's RAM
cache. You could try to read-ahead the .desktop files somehow.

Thanks for the information.

BTW, I tried to improve NFS performance in a gigabit environment but didn't
know where to put NFS parameters.  Could you please tell me how to improve
NFS performance ?

On the server (TJENER) it is /etc/exports (of course).

For the clients, you have to dive into the LDAP DIT (use ldapvi for it and set env var VISUAL=<editor-of-my-choice>).

The command line for me is

VISUAL=mcedit ldapvi --discover -D cn=admin,ou=ldap-access,dc=skole,dc=skolelinux,dc=no

The original bootstrapping of those LDAP objects responsible for AutoFS mounts is derived from these files [1]. Search for the corresponding entries in your LDAP data.


[1] http://anonscm.debian.org/viewvc/debian-edu/branches/wheezy/debian-edu-config/ldap-bootstrap/autofs.ldif?view=markup

PS: your mail client seems to break mail quoting when viewing the mail in plain text. Not sure if you post your mails as HTML or plaintext, but you may consider sending plain text mails (if you don't do that already).

mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de


Attachment: pgpRXHOSWVMGv.pgp
Description: Digitale PGP-Signatur

Reply to: