Hi,
Anyone got a clue? is there some tool for it? couldnt find it in apt get, anyway i hope so cos i must build a patch management tool for work:P
Greetz.
I found only 2 reasons to reboot my Debian system so far:
- Hardware change[*] Kernel update
Well i didnt know quite were to post it, cos the program should work cross platform, so also fedora redhat, sun solaris and others should be covered...
So you are saying that except those 2 there never is a reboot needed? that should safe me from a lot of trouble 
For most UNIXes I know there's usually no reason to reboot except for those two. Whether or not any services have to be (manually) restarted depends on the package management system and the distributor. (but most do it themselves)
If you manage to include kexec properly you can even save a lot of time on kernel updates on Linux machines.
Thanks for your response, and how about information about services being stopped? A lot of servers on which to install packages are customers of the business and dont want any services to be stopped or restarted (for example apache). is there any way to find out if a service needs to be restarted in the packafe info?
Greetz and thanks in advance.
On the two most prevalent package management systems for Linux (deb and rpm) that information isn't really accessible, but depends on what the pre-/postinstall scripts embedded in the package do and how the maintainer wrote those.
As for downtime: a typical Apache upgrade for me never resulted in more that 30 seconds downtime (which was on a P90, long ago). Since an upgrade should be done between business hours anyways (in case somethings goes terribly wrong) a blip of about 5 minutes shouldn't do too much of an impact on business. If it would I suggest investing in redundancy and update only one node at a time.
Thanks for the information, i was already guessing there was no easy way around it really, well this prolly means we prolly have to dry run packages and check for any errors, if so they have to install manually i guess,
I forgot to meantion that it was going to be an automated patch management tool really 
May I suggest an alternative route to that end: Build a small network containing those OSs and applications that you have in production, plus a dedicated server to roll out updates. When the distributor puts new updates online, apply them to the test environment first. If they still behave well after a certain period (eg. 2 weeks), put them on your internal update server, from which your other machines can automatically update. Those that don't work just get skipped.
As for the test environment: if you don't have any special hardware needs, virtualization works just fine (VirtualBox, VMware, ...)
Thanks for you information, this will prolly mean we will schedule all patches for between business times. Though this makes me think of security patches, since you want them to be installed straight away how can u see if a package or patch is related to security issues?
Don't know about Fedora, ... but for Debian there are always 2 update sources (see sources.list)
deb ftp://ftp.<tld>.debian.org/debian {sarge|etch|lenny|stable} main contrib [non-free]
deb ftp://security.debian.org/ {sarge|etch|lenny|stable}/updates main contrib [non-free]
The second entry here is the update site for security patches that aren't already incorporated into the usual updates. Same goes for Ubuntu (and most other Debian-based distributions)
I already had those links in my sources.list on the test server,
Anyway thanks for the info,