Today our team installed skolelinux at a school. 30 client computers, with one PC as main / LTSP server. Here are the summary of our experiences today:
1. It spent us 1.5 hour to install a native debian-edu system. We used clonezilla to backup the native system. We've been sure that the system works.
2. When importing users into LDAP, it became inaccessible in the middle of importing. Then LDAP became totally unusable. I tried to assign ldap and ldap.intern IP in /etc/hosts, but still of no use.
3. We tried to recover the native system from clonezilla, but still failed to login.
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.
6. Then I changed the IP subnet. The reason was that, the ip 10.0.2.2/8
at eth0 would conflict with the IP (10.160.0.0/16
) at eth1, which was controlled by the "upstream" unit. I mean, originally the computers in this computer classroom would get 10.160.0.0/16
from upstream DHCP server. At the main server I installed the second NIC and connected it to the upstream. If I didn't change the subnet it would not be able to access the internet.
7. After changing the IP subnet, the LDAP became unusable again. Then I assigned the IP of ldap and ldap.intern to the ip of tjener.intern. It worked.
8. I then used ltsp-chroot -a i386 to switch to the client system and installed some packages like icedtea-7-jre and flash-plugin-nonfree. The etckeeper trigger in /etc/apt/apt.conf.d would *always* fail to execute.
Here are the summary of the problems we saw today:
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.
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?
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.
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?
5. Another question is that, how can I assign the group when importing mass users into LDAP? We'd like to split users into different (POSIX) groups to easily control the permissions of folders. However we didn't find out how.
Any suggestion and help will be very appreciated.