Major upgrade failure -> people maintain > 1 computer

[Reindl Harald]

Am 08.12.2011 03:20, schrieb Marko Vojinovic:
> Sure, if you know what you are doing, you are welcome to do it. But it may 
> just happen that future Fedora releases prove you wrong later on. Fedora is a 
> fast-moving target, and you can never be sure in which direction it is going 
> to go in a year or more.

since RHEL is based on fedora you will get this
changes there also, only later


>> because using stoneold software like RHEL is not a option here
> 
> What, you are missing the latest Gnome3.2 on your production servers? :-)

no , PHP 5.3 / MySQL 5.5 / Dovecot 2.0.16 / Postfix 2.8

PHP 5.4 as soon as it is stabilized because if your are
hosting hundrets of domains where all your software is
inhouse-developed it is easy to upgrade and benefit of
new features instead wait 5 years

> More seriously, I agree that sometimes there is a legitimate need for the 
> latest software in production, but those cases are exceptional rather than 
> typical.

typical for what?

look at current web-development and tell me again you are
right to use 5 years old software in this business-class

>>> And yes, that's exactly what I mean --- *work* --- create and execute a
>>> script to chown across all disks on all machines, update/modify all
>>> /etc/passwd and /etc/group to reflect the UID+500 change on all systems
>>
>> for exactly what reason?
>> because anybody thought it has to be changed?
> 
> And what do you think, *why* did Fedora decide to raise the limit on UID's in 
> this release? Is it not reasonable to assume that they have a plan to actually 
> *use* more than 500 system-reserved UID's in some future release? My guess is 
> that in a couple more Fedora releases there will be *no* *choice* but to raise 
> the UID limit. Consequently, hoping that you can get away with current UID's 
> in the long term, while upgrading through Fedora releases, is not very wise 
> IMHO.

what is not very wise?

not change the uids for nonsense on 20 production servers running since years
becasue MAYBE somewhere in time it COULD be necessary? what does this bother
me NOW?

> It's great if you can do that. But there are also other usecases, where 
> serious downtime may be necessary.

then you did prepare the upgrades wrong

>>> rebooting of all servers (maybe  simultaneously)
>>
>> hopefully you are not responsible for production environment
> 
> Hopefully you are aware that Fedora 16 has gone through at least four kernel 
> versions already, since it first came out (might be even more, I didn't count 
> too carefully).

so what?

> And please don't tell me that you don't need to run the latest kernel on 
> production systems where the latest software is an absolute must-have. I know 
> that in some cases you can get away with that, but again it's an exceptional 
> rather than a typical usecase.

"hopefully you are not responsible for production environment" was meant to
"maybe  simultaneously" because NOBODY restarts all his servers at the same
time because if something goes wrong you are on the road to hell und
if you have a netwrok with nameservers/dhcp and such nice components
you must be totally crazy restart the whole infrastructure at the same time

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20111208/2c0b0380/attachment.bin