Best common practices
From AdminWiki
(→Best common practices) |
(ntp) |
||
Line 1: | Line 1: | ||
This should give you a rundown on the absolute minimum ''every'' server should have. | This should give you a rundown on the absolute minimum ''every'' server should have. | ||
+ | |||
+ | = Time issues = | ||
+ | |||
+ | There is absolutely ''no'' excuse for not having a correctly synchronized clock. The problem gets even worse when you are administrating multiple servers which interact with each other and you've to compare logfiles from those machines. | ||
+ | |||
+ | The problem got worse in the last years (at least that's my impression) because processors got faster and time-keeping-mechanisms ''sloppier''. What the operating system basically does <ref> I'm not completely sure about that. If I'm horribly wrong here, please tell me so ;) </ref> when booting up is fetching the current time and date from the realtime clock, then taking a wild guess how many CPU cycles (or any other time source, e.g. HPET) are approximately one second and then using this value as long as the OS runs. Excessive IRQ usage, cpu cycle modulation (power saving) and other factors might also aid the inaccuracy. | ||
- | |||
* backup | * backup | ||
* monitoring | * monitoring | ||
* sane logging | * sane logging | ||
* handling of (security) updates | * handling of (security) updates |
Revision as of 17:01, 24 May 2006
This should give you a rundown on the absolute minimum every server should have.
Time issues
There is absolutely no excuse for not having a correctly synchronized clock. The problem gets even worse when you are administrating multiple servers which interact with each other and you've to compare logfiles from those machines.
The problem got worse in the last years (at least that's my impression) because processors got faster and time-keeping-mechanisms sloppier. What the operating system basically does [1] when booting up is fetching the current time and date from the realtime clock, then taking a wild guess how many CPU cycles (or any other time source, e.g. HPET) are approximately one second and then using this value as long as the OS runs. Excessive IRQ usage, cpu cycle modulation (power saving) and other factors might also aid the inaccuracy.
- backup
- monitoring
- sane logging
- handling of (security) updates