On Thu, 2012-01-26 at 15:49 +0100, Reindl Harald wrote:
Am 26.01.2012 15:07, schrieb Nils Philippsen:
> On Thu, 2012-01-26 at 14:19 +0100, Reindl Harald wrote:
>>
>> Am 26.01.2012 14:08, schrieb Nils Philippsen:
>>> For the sake of completeness:
>>>
>>> On Thu, 2012-01-26 at 03:22 +0100, Reindl Harald wrote:
>>>> after a yum upgrade you can verify that the most important
>>>> things are fine BEFORE reboot (bootloader-config,
>>>> package-cleanup --problems, ....), optimize/correct things
>>>> you know are not fine after the upgrade (active services
>>>> after transition to systemd as example) and then you reboot
>>>> ONCE in a clean starting system instead a boot in the blue
>>>
>>> ... as can be done on VC2 after updating with anaconda
>>
>> while the system and services are running?
>> show me how you will do this!
>
> This not what I wrote.
you did - you wrote "as can be done"
Then, this is not what you wrote :-). I was referring to what I quoted
above: "after a yum upgrade you can verify that the most important
things are fine BEFORE reboot..., optimize/correct things... and then
you reboot..." Nowhere in the quoted text did you mention services that
keep running, which I grant is a huge difference between upgrades done
in yum and anaconda. Whether keeping services running while the world
changes around them is a good idea, however, I doubt it.
> I am well aware of the differences between doing an upgrade
with
> anaconda and doing it with yum in a live system. I've done enough of the
> latter to at least shut down critical processes (e.g. MTA, database
> server software) before doing a yum upgrade, because stuff tends to
> hick-up if you pull the rug from underneath it (e.g. if files get moved
> around, renamed, dynamically loaded modules are replaced by newer
> versions with new API, data formats change, ...). What you described
> sounds too non-deterministic for my taste. Granted, you reduce the
> amount of planned downtime with this scheme, but you trade that in for a
> heightened risk of unplanned downtime should stuff break in the process.
> And testing only buys you a limited sense of security here.
we build critical server packages usually on our own infrastructure
and do version changes sepearted from the dist-upgrade as also
the automatic restart on update is removed from all packages
as example we had MySQL 5.5 on F13
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 -- 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.
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.
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
here again?
Nils
[1]:
http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Upgrading_Fedora...
[2]:
https://fedoraproject.org/wiki/Remix
[3]:
http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_F...
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils(a)redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011