Am 27.01.2012 14:15, schrieb Nils Philippsen: > On Thu, 2012-01-26 at 15:49 +0100, Reindl Harald wrote: >> there is no limited sense of security >> each machine has a clone for backup-reasons >> this clones are updated first >> so after that i know the exactly behavior > > In a strict sense, no, you don't. Assuming that your servers have users > that keep on using them while they're being upgraded (everything else is > pointless), their actions are a big unknown bullshit - on web and fileservers their actions are exactly known and users have NEVER shell access on a server the services are running with the old versios of the service and all libraries - you can physically remove the whole httpd while it will run for days as long it is not stopped > -- you can't know ahead of > time what they'll do during the machine is upgraded, and this may > trigger behavior in the running software which you did not test before. as said above - NO >> there is ALWAYS the internal build/repo-cache server between >> and that is why anaconda is unuseable and it would be >> a shame damage this capabilities > > First, upgrading with yum never was fully supported[1], probably to > cater for situations like this one. Second, as you described it above it > seems you're not running Fedora, but your own forked off distribution (a > "Fedora Remix"[2] if you want to give it a nice-sounding moniker). You > could even forego UsrMove in your fork -- though that'd be a lot of > work: right now in F16/x86_64, there are 261 affected packages, so you > probably don't want to do that. this is only needed because fedora packages restarting services while updateing them what is UNACEPPTABLE even if yu are not doing a dist-upgrade becuse normally you test packages, deploy them and later in the evening do the restart the second problem is that most services are not converted to systemd and my old watchdog-scripts restarting crashed servcies are no longer work on top of systemd so no i gave no fork, i only solve currently design bugs in fedora and that is why i would not be amused introduce new ones instead solve the existing like set a var in /etc/sysconfig to restart services on update or not instead a braindead hardcoded restart in each SPEC-file > Anyway, I wonder what the drama is all about (and this goes to larger > parts of the audience)... I think a lot of this is based on > misunderstandings and conjecture: You already need to do certain > preparatory steps before doing a yum upgrade (e.g. install repository > GPG keys, disable and remove SELinux policy from F-13 to F-14). This > time you have additional steps[3] in order to run a script which moves > stuff about, preparing the system in a way which can't sanely be done in > RPM/YUM (re headless: AIUI this doesn't really need physical presence in > front of the box, and regardless: a serial console or similar is a good > thing to have). Then you do the upgrade as usual. What's the big deal it takes much longer to shutdown the virtual machine, add a dvd-rom, insert a iso-image, bott from this crap and hope that the system afterwards will build as a whole dist-upgrade at all normally a dist-upgarde takes 4-6 minutes per server and 20-30 secods for the reboot - believe it or not, with a stripped down installation-base on a HP ProLiant DL 380G7 , a SAN-Storageand VMware ESXi on top this are normal values
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
