FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 02-10-2012, 04:16 AM
David
 
Default Yum and Fedora 16 -- focus on "new/moved filesystems"

On 2/9/2012 11:51 PM, Paul Allen Newell wrote:
> On 2/9/2012 8:31 PM, David wrote:
>> Paul,
>>
>> I have yet to see a fresh install of Rawhide or Fedora 17. The current
>> nightly Rawhide build ISOs will not install at all, for me, for some
>> reason, and there are no as of yet ISOs available of Fedora 17 that I
>> know of.
>>
>> I would expect the Fedora 17 install, with this /usrmove in it, would
>> work. I have yet, as I wrote, to have great success with the conversion
>> phase. 25%, one success out of four attempts, is not good.
>>
>> I would not expect a 'new install' user to even notice. I would,
>> however, expect to see the 'update installers' have problems at this
>> time. At least with what is not working today. And fedora 17 is
>> scheduled for release on May 5, 2012. Hopefully they fix it by then
>>
>
> David:
>
> I am very much hoping they fix it and well before May 5th. Getting it
> working for "update installations" is the robust stress test of the
> whole implementation.
>
> Rawhide is too bleeding edge for me. But I am glad to be aware of this
> as I certainly will be checking for comments on or after May 5th when I
> consider whether I move to F17 or wait for F18. I skipped F15 for
> similar reasons ... I just didn't like what I was seeing posted as folks
> discovered what was there in the release version.


Understood. As I said it appears, and I would expect, that a 'fresh
install' does work with no problems. And I am not saying that the update
path does not, or will not, work. Only that I did not have much success
with it.

And, as I recall, the 'problems' in the several previous Fedora releases
you mentioned were with update installs. And those updates were to highly
modified (user configured) systems.
--

David

"May your road lead you to warm sands."
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
 
Old 02-10-2012, 04:25 AM
Paul Allen Newell
 
Default Yum and Fedora 16 -- focus on "new/moved filesystems"

On 2/9/2012 9:16 PM, David wrote:

Understood. As I said it appears, and I would expect, that a 'fresh
install' does work with no problems. And I am not saying that the update
path does not, or will not, work. Only that I did not have much success
with it.

And, as I recall, the 'problems' in the several previous Fedora releases
you mentioned were with update installs. And those updates were to highly
modified (user configured) systems.


Hence why I prefer fresh installs ... I like to remove those issues so I
can evaluate what's in the new release independent of "can older version
be update". I've already qualified my comments on that to acknowledge
that there are folks who can't take the "fresh install" approach, so I
am only speaking for myself.


I do prefer it when update installs work as it makes me believe the QA
has been through.

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
 
Old 02-10-2012, 06:35 AM
Joe Zeff
 
Default Yum and Fedora 16 -- focus on "new/moved filesystems"

On 02/09/2012 01:57 PM, Reindl Harald wrote:

so tame one seocond and imagine how it should work
copy all this files and maintain them twice with yum

sorry, but this makes no sense at all


Whoever said that the old versions were to be maintained? My thought
was that they might be sitting there, unused, wasting disk space.

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
 
Old 02-10-2012, 10:34 AM
Reindl Harald
 
Default Yum and Fedora 16 -- focus on "new/moved filesystems"

Am 10.02.2012 08:35, schrieb Joe Zeff:
> On 02/09/2012 01:57 PM, Reindl Harald wrote:
>> so tame one seocond and imagine how it should work
>> copy all this files and maintain them twice with yum
>>
>> sorry, but this makes no sense at all
>
> Whoever said that the old versions were to be maintained? My thought was that they might
> be sitting there, unused, wasting disk space.

well, i am frustrated about the way radical changes are done
in fedora with closed eyes and trough the wall the last releases
but this is a impossible expectation because no one ever would
act in such a stupid ay - really this is unthinkable from
any pint of view

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
 
Old 02-10-2012, 12:43 PM
Timothy Murphy
 
Default Yum and Fedora 16 -- focus on "new/moved filesystems"

Reindl Harald wrote:

> sorry, but permanently reinstall the OS is a windows-thing
> and especially unnaceptable if all 6 months a new version
> is available and you have to maintain 2, 5, 10, 20 machines

I don't agree - at least if one has 2 or 5 machines to deal with.
I always do a fresh install on a new partition,
leaving the /home partition untouched.
(I don't think this is a "Windows thing";
I don't even know if it is possible under Windows.)

One reason is that in my experience there is a non-zero probability
that the new version will not work, perhaps because of a driver problem.
In fact I would guess that over all the Fedora systems I have installed
there has been a 25% initial failure rate,
usually to do with video card drivers.

> a scripted dist-upgrade for 20 servers with yum takes around
> two hours (proveable by logs) inlcuding download from local
> repo-cache

What is the script?
It seems to me it would have to be pretty complicated.
I certainly wouldn't trust any script I wrote to do this.

--
Timothy Murphy
e-mail: gayleard /at/ eircom.net
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College Dublin


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
 
Old 02-10-2012, 12:57 PM
Reindl Harald
 
Default Yum and Fedora 16 -- focus on "new/moved filesystems"

Am 10.02.2012 14:43, schrieb Timothy Murphy:
> Reindl Harald wrote:
>
>> sorry, but permanently reinstall the OS is a windows-thing
>> and especially unnaceptable if all 6 months a new version
>> is available and you have to maintain 2, 5, 10, 20 machines
>
> I don't agree - at least if one has 2 or 5 machines to deal with.
> I always do a fresh install on a new partition,
> leaving the /home partition untouched.
> (I don't think this is a "Windows thing";
> I don't even know if it is possible under Windows.)

you are a simple desktop-user with your stuff
in /home, if you are develop software and
integrate workflows in a system for managment
and so on /home does not interest you much

> One reason is that in my experience there is a non-zero probability
> that the new version will not work, perhaps because of a driver problem.
> In fact I would guess that over all the Fedora systems I have installed
> there has been a 25% initial failure@machine rate,
> usually to do with video card drivers.
>
>> a scripted dist-upgrade for 20 servers with yum takes around
>> two hours (proveable by logs) inlcuding download from local
>> repo-cache
>
> What is the script?
> It seems to me it would have to be pretty complicated.
> I certainly wouldn't trust any script I wrote to do this.

* prepare the dist-upgrade
* test it with snapshots
* rebuild weak packages (missing unit-files, dependencie problems..)
* build up an internal repo
* have all machines ONLY this repo as source
* have all machines cloned from the same master
* have all machines exepct the repo-cache never seen external repos

after that you can test a dist-upgrade until your finger bleeds
and you are knowing EXACTLY what will happen on the live-machine

you can prepare even configurations for services before
rollout - again you know exatly what happens, what have
to be prepared and what excatly commands you have to type
after the dist-upgrade before the reboot and put
them in a script on each target machine
_________________________

finally a simple shell scipt
"ssh root@taget-machine1 'yum -y commands; /finish-script.sh"
"ssh root@taget-machine2 'yum -y commands; /finish-script.sh"
"ssh root@taget-machine 3'yum -y commands; /finish-script.sh"
_________________________

i have done my homework in 2008 and planned a working infrastructure
where new servers are cloned from the same master and i did EVERY
dist-upgrade (F10, F11, F12, F13, F14) this way without a single
problem because i know what i am doing and holding my machines clean

and that is why my understanding breaking this in one or
the other way is simply not existent and called an unacceptable
step backwards, and yes i have a VOIP-Server which has seen every
single update since FC7 until F15 via yum because as said i
know what i am doing and i take the time to prepare things
well BEFORE they are needed

that is also the reason for my non existing understanding
for put dumb service restarts on yum update in every package
instead a global 0/1 setting forxing me tu rebuild each
damned server-package and bringing no benefit at all because
it is not well thought believing in better security doing
this automaticallyl in the case of security updates not realizing
that this would as example not help if a php-security update
arrives which does not restart httpd, or a gd-library update
fixing security bugs and affecting all sorts of other packages
including php and at least apache

such things are low-brained decisions without looking
at the big picture

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
 
Old 02-10-2012, 02:14 PM
Timothy Murphy
 
Default Yum and Fedora 16 -- focus on "new/moved filesystems"

Reindl Harald wrote:

>>> sorry, but permanently reinstall the OS is a windows-thing
>>> and especially unnaceptable if all 6 months a new version
>>> is available and you have to maintain 2, 5, 10, 20 machines
>>
>> I don't agree - at least if one has 2 or 5 machines to deal with.
>> I always do a fresh install on a new partition,
>> leaving the /home partition untouched.
>> (I don't think this is a "Windows thing";
>> I don't even know if it is possible under Windows.)
>
> you are a simple desktop-user with your stuff
> in /home, if you are develop software and
> integrate workflows in a system for managment
> and so on /home does not interest you much

I don't understand this.
Do you mean you don't have a separate /home partition?
Don't you get any email?
(I keep my email in ~/Maildir/ on my server.)

>>> a scripted dist-upgrade for 20 servers with yum takes around
>>> two hours (proveable by logs) inlcuding download from local
>>> repo-cache
>>
>> What is the script?
>> It seems to me it would have to be pretty complicated.
>> I certainly wouldn't trust any script I wrote to do this.
>
> * prepare the dist-upgrade
> * test it with snapshots
> * rebuild weak packages (missing unit-files, dependencie problems..)
> * build up an internal repo
> * have all machines ONLY this repo as source
> * have all machines cloned from the same master
> * have all machines exepct the repo-cache never seen external repos

This illustrates the difference between us.
It would take me at least 2 days to do the above, not 2 hours.
And when I had done it I would have zero confidence it would work.
In fact I would put money on it not working.

--
Timothy Murphy
e-mail: gayleard /at/ eircom.net
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College Dublin


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
 
Old 02-10-2012, 02:54 PM
Reindl Harald
 
Default Yum and Fedora 16 -- focus on "new/moved filesystems"

Am 10.02.2012 16:14, schrieb Timothy Murphy:
> Reindl Harald wrote:
>> you are a simple desktop-user with your stuff
>> in /home, if you are develop software and
>> integrate workflows in a system for managment
>> and so on /home does not interest you much
>
> I don't understand this.
> Do you mean you don't have a separate /home partition?
> Don't you get any email?
> (I keep my email in ~/Maildir/ on my server.)

on a webserver? no!

i mean that /home and the datadrive at all is
the smallest problem, configurations and well
thought and over years polished automation
are the things which are the hard work

>>>> a scripted dist-upgrade for 20 servers with yum takes around
>>>> two hours (proveable by logs) inlcuding download from local
>>>> repo-cache
>>>
>>> What is the script?
>>> It seems to me it would have to be pretty complicated.
>>> I certainly wouldn't trust any script I wrote to do this.
>>
>> * prepare the dist-upgrade
>> * test it with snapshots
>> * rebuild weak packages (missing unit-files, dependencie problems..)
>> * build up an internal repo
>> * have all machines ONLY this repo as source
>> * have all machines cloned from the same master
>> * have all machines exepct the repo-cache never seen external repos
>
> This illustrates the difference between us.
> It would take me at least 2 days to do the above, not 2 hours.
> And when I had done it I would have zero confidence it would work.
> In fact I would put money on it not working.

and i put money that it works if i do it because i
am there since because i did this six times and it
worked form the first time perfectly, it is well
proven that it works and i am responsible for more
than 500 domains and all sort of services you can
imagine

but this is the differnce between me and many developers
out there - i know my respsonibility for the things i do
and and do never release half baken things to my users

and yes, i am developer too maintaning a whole cms-system
with > 200 instances on the mainserver and this does
alos get DAILY updates with one click as rolling release
and if i change things needing config-changes i am
responsible to prepare this and i do this since
nearly ten years with no mistake producing more
than a handfull php-warnings while error_reoprting
E_ALL + E_STRICT + E_DEPRECATED is active on ALL
machines

so there is a differnece how pepole act and seeing how fedora currently
acts makes people like me simply sad and angry
_____________________________________

yes it takes 2 days to prepare

but it takes me two days for every single machine reinstall it
and restore all sort of configurations, scripts, cronjobs

so with 20 machines it would take me around 40 days resinstall
them, so it takes me two days upgrade them all, having in mind
that each dist-upgrade would take 40 days this would take
at least 80 days each year for fresh installs - unacceptable

4 days for two distupgrades are nothing
AND the infrastructure is growable!

it does not bother me if i have 20, 30 or 40 servers
they can be all maintained the same way, there are perfectly
wroking scripts on the admin-machine to start each sort of
commands / scripts on the production hosts to deploy and maintain
anything

but this does only work as long fedora is not destroying
the distribution slowly


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
 

Thread Tools




All times are GMT. The time now is 06:40 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org