Hi Mike, thanks for your reply.
Please see my comments below.
2014/3/30 下午9:59 於 "Mike Gabriel" <mike.gabriel@das-netzwerkteam.de> 寫道：
>
> Hi Frenklin,
>
>
> On Sa 22 Mär 2014 14:56:43 CET, Franklin Weng wrote:
>
>> 4. Then we found that, it might be the time problem. At first installing,
>> the time on the main server was 8 hours faster than normal time. When
>> importing the user, I manually set the time back to normal. It may cause
>> the time in the LDAP database become "future", hence the whole LDAP system
>> was unusable.
>>
>> 5. I then manually set the time to one day fast (to make the LDAP time
>> "normal"). It worked. I could login successfully.
>
>
> Was that login on another client on the Debian Edu network that failed or user/admin login on TJENER?
>
On tjener.
> 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.
>
>> 1. I know that the system may have troubles if the timestamp of some files
>> are at the future, but I really have no idea why. This caused the whole
>> LDAP system unusable.
>
>
> I am actually not sure, if LDAP is that time sensitive. Make sure to clearly differentiate between LDAP and Kerberos here. And: the clocks should go right in the first place. This is a presumption that we have to make.
>
Yes, I agree. I didn't notice the time problem at the first time. I was also wondering if LDAP would be that time sensitive. That's an important experience for us.
>
>> 2. I didn't assign ldap ip when running subnet_change. After subnet change
>> the LDAP was unusable unless I explicitly assign the ldap ip in /etc/hosts.
>> Would anyone know why?
>
>
> Everything in the Debian Edu setup is based on a properly working DNS. If DNS is broken, then you are lost and have to fix DNS first.
>
> The DNS information is stored in LDAP again, so maybe we a have cat and tail issue here (LDAP becomes inaccessible, BIND configuration is not updated anymore, DNS fails to work, LDAP won't become accessible unless BIND gets fixed before which obtains its fixes from LDAP...)
>
>
Uh... DNS is in LDAP, and if LDAP was inaccessible due to DNS issues… Looks a bit strange.
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.
>> 3. The performance was not as good as our last test. We wondered if it was
>> because of the quality of the LAN. One of the client could boot and logged
>> 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 rebooted.
>> 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 a
>> 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 ?
Thanks,
Franklin