FAQ
To pass from Centos 5.5 to 5.6 it was easy as an upgrade.

Will it be the same from 5.6 to 6.0 or a full install will be better.

---
Michel Donais
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.centos.org/pipermail/centos/attachments/20110414/8d100c75/attachment.html

Search Discussions

  • Eero Volotinen at Apr 15, 2011 at 2:19 am

    2011/4/15 Michel Donais <donais at telupton.com>:
    To pass from Centos 5.5 to 5.6 it was easy as an upgrade.

    Will it be the same from 5.6 to 6.0 or a full install will be better.
    well, usually upgrading major version is not easy or preferred method.
    use full install instead.

    --
    Eero
  • Barry Brimer at Apr 15, 2011 at 2:41 am
    Will it be the same from 5.6 to 6.0 or a full install will be better.
    Full installs are always recommended between major versions.
  • Michel Donais at Apr 15, 2011 at 10:40 pm

    Will it be the same from 5.6 to 6.0 or a full install will be better.
    Full installs are always recommended between major versions.

    Thank's all for the advise; but is there any easy way to install a newer
    version while keeping all configuration changes that have been made on a
    previous one as for 'sendmail', 'sshd.conf','firewalls', etc...


    ---
    Michel Donais
  • John R Pierce at Apr 15, 2011 at 10:53 pm

    On 04/15/11 7:40 PM, Michel Donais wrote:
    Will it be the same from 5.6 to 6.0 or a full install will be better.
    Full installs are always recommended between major versions.
    Thank's all for the advise; but is there any easy way to install a newer
    version while keeping all configuration changes that have been made on a
    previous one as for 'sendmail', 'sshd.conf','firewalls', etc...
    have all your configuration under a change management system, with an at
    least semi-automated installation procedure, such as kickstart.
  • Michel Donais at Apr 16, 2011 at 12:20 am

    have all your configuration under a change management system, with an at
    least semi-automated installation procedure, such as kickstart.
    I nerver think kikstart was I need.
    I will check what it is and how it work.

    Thank's for the info.

    ---
    Michel Donais
  • Devin Reade at Apr 16, 2011 at 1:18 am

    John R Pierce wrote:

    have all your configuration under a change management system, with an at
    least semi-automated installation procedure, such as kickstart.
    Or have the self discipline to keep a text file (or other record) of
    *all* changes you make to a system as root or other role account.
    I always keep a running log, complete with dates and who makes the
    change, as /root/`hostname`-mods. Trivial operations (that any junior
    sysadmin would be expected to know) get described. Anything more complex
    gets the actual commands entered (minus passwords).

    It's extra work, however not only has it saved my bacon a lot over the
    years in figuring out, after the fact, what caused something to break
    but even more often it has been invaluable in recreating a system or
    quickly implementing similar functions on other systems.

    Yes, this is a form of a change management system, just with little
    overhead. It is also more suited to server environments where each
    one might be slightly different as opposed to (for example) corporate
    workstation environments where you can have a large number of homogeneous
    machines. In that case, there are many other tools more suitable,
    with higher setup costs, but the amortized cost is lower.

    Devin
    --
    When I was little, my grandfather used to make me stand in a closet for
    five minutes without moving. He said it was elevator practice.
    - Stephen Wright
  • Johnny Hughes at Apr 16, 2011 at 9:31 am

    On 04/16/2011 12:18 AM, Devin Reade wrote:
    John R Pierce wrote:
    have all your configuration under a change management system, with an at
    least semi-automated installation procedure, such as kickstart.
    Or have the self discipline to keep a text file (or other record) of
    *all* changes you make to a system as root or other role account.
    I always keep a running log, complete with dates and who makes the
    change, as /root/`hostname`-mods. Trivial operations (that any junior
    sysadmin would be expected to know) get described. Anything more complex
    gets the actual commands entered (minus passwords).

    It's extra work, however not only has it saved my bacon a lot over the
    years in figuring out, after the fact, what caused something to break
    but even more often it has been invaluable in recreating a system or
    quickly implementing similar functions on other systems.

    Yes, this is a form of a change management system, just with little
    overhead. It is also more suited to server environments where each
    one might be slightly different as opposed to (for example) corporate
    workstation environments where you can have a large number of homogeneous
    machines. In that case, there are many other tools more suitable,
    with higher setup costs, but the amortized cost is lower.
    I guess this depends on what you need to accomplish.

    If I am running the machine, I normally know what it is doing. You can
    do some things up front to make it easy to upgrade a machine.

    Lets take, as an example, a web server.

    You can change ONLY the things that are necessary inside httpd.conf (and
    then only remark out things that are in httpd.conf) and instead try to
    make all your changes to new config files that you place in
    /etc/httpd/conf.d/

    By doing this, it is easy to move your new config files to a new machine
    and start with a default httpd.conf on the new server.

    Another technique I use is to do a "diff" between a new config file and
    the original. Then I can then incorporate the diff into the original on
    the other server ... something like this:

    diff -uNrp my.conf.orig my.conf > my.conf.diff

    if you did not save the unmodified config file before you modified it
    (shame on you :D) ... then you can just download the applicable RPM and
    use the rpm2cpio command to extract the file from the original RPM
    (after placing it in a directory by itself) like this:

    rpm2cpio mysql-server-5.0.77-4.el5_5.4.x86_64.rpm | cpio -idv

    You can then got to <your_directory>/etc/ and get the original my.conf file.

    The real issue with upgrades between major branches is that things that
    are within a branch (that is, the EL4 branch or the EL5 branch) are
    designed to work together for the entire lifetime of that branch by the
    upstream provider. They do not release items where you have to make
    major changes in the config files, etc. However when moving between
    major versions (from EL4 TO EL5 or EL5 to EL6) that is not the case.
    There can be (and usually is) major changes required because of the
    major bumps in things. For example, mysql-server in EL 4 goes from
    mysql-server-4.1.7 in the 4.0 release to mysql-server-4.1.22 currently
    in 4.9 ... no major changes. For CentOS-5 it went from
    mysql-server-5.0.22 in the 5.0 release to mysql-server-5.0.77 currently
    in 5.6, still no major changes. But if you move from mysql-server-4.1.7
    to mysql-server-5.0.77 (CentOS-4.0 to CentOS-5.6) then there would
    likely be major changes required in the configuration options.

    The bottom line is this ... no it will not be "easy" to upgrade between
    main branches because there is no ABI or configuration compatibility
    between main branches as there is inside a particular branch.

    Can you try to "UPGRADE" from 5.x (or even 4.x) to 6.x ... sure. If you
    were to type this at the boot screen:

    linux upgradeany

    Then it would allow you to try an upgrade. I would never do this to a
    machine that I cared about though ... bite the bullet and create a VM or
    buy a machine to upgrade into, then once working you can move it back to
    the original machine if required.


    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 253 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20110416/e393fe5c/attachment.bin
  • Les Mikesell at Apr 16, 2011 at 11:32 am

    On 4/16/11 12:18 AM, Devin Reade wrote:
    John R Piercewrote:
    have all your configuration under a change management system, with an at
    least semi-automated installation procedure, such as kickstart.
    Or have the self discipline to keep a text file (or other record) of
    *all* changes you make to a system as root or other role account.
    I always keep a running log, complete with dates and who makes the
    change, as /root/`hostname`-mods. Trivial operations (that any junior
    sysadmin would be expected to know) get described. Anything more complex
    gets the actual commands entered (minus passwords).

    It's extra work, however not only has it saved my bacon a lot over the
    years in figuring out, after the fact, what caused something to break
    but even more often it has been invaluable in recreating a system or
    quickly implementing similar functions on other systems.

    Yes, this is a form of a change management system, just with little
    overhead. It is also more suited to server environments where each
    one might be slightly different as opposed to (for example) corporate
    workstation environments where you can have a large number of homogeneous
    machines. In that case, there are many other tools more suitable,
    with higher setup costs, but the amortized cost is lower.
    This is all good advice, but you really should be able to figure things out if
    you know what services the old system was running and you have a backup of your
    old /etc directory. At least for the rpm-packaged programs in the base and most
    3rd party repos, all of the configuration files will be under /etc, and most
    will have the part where you make local changes abstracted out into a file under
    /etc/sysconfig. Having a better change management system would let you diff
    your current files against the original distribution copies to easily see the
    specific changes you made. This may be a little harder if there are big changes
    in the distribution versions but still not impossible to figure out.

    If you have compiled anything yourself it probably installed under /usr/local
    and you are on your own at reproducing that, but if it is old enough to forget
    you probably want to see if RPM packaged versions are available now that would
    be easier to maintain.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • John R Pierce at Apr 16, 2011 at 1:52 pm

    On 04/16/11 8:32 AM, Les Mikesell wrote:
    At least for the rpm-packaged programs in the base and most
    3rd party repos, all of the configuration files will be under /etc
    one notable exception to that is postgresql, its config files are
    normally in the postgres data directory, nominally /var/lib/postgresql/data

    since its config is quite closely tied to its data files and its
    datafiles are very version specific, you really need to pg_dumpall the
    old and restore it to the new.

    now, I do note that debian/ubuntu move these conf files to
    /etc/postgresql/$version/... but we have to mimic upstream
  • Mister IT Guru at Apr 16, 2011 at 12:46 pm

    On Fri, 2011-04-15 at 19:53 -0700, John R Pierce wrote:
    On 04/15/11 7:40 PM, Michel Donais wrote:
    Will it be the same from 5.6 to 6.0 or a full install will be better.
    Full installs are always recommended between major versions.
    Thank's all for the advise; but is there any easy way to install a newer
    version while keeping all configuration changes that have been made on a
    previous one as for 'sendmail', 'sshd.conf','firewalls', etc...
    have all your configuration under a change management system, with an at
    least semi-automated installation procedure, such as kickstart.

    +1
  • Przemyslaw Bak at Apr 18, 2011 at 3:53 am

    On Fri, Apr 15, 2011 at 07:53:34PM -0700, John R Pierce wrote:
    On 04/15/11 7:40 PM, Michel Donais wrote:
    Will it be the same from 5.6 to 6.0 or a full install will be better.
    Full installs are always recommended between major versions.
    Thank's all for the advise; but is there any easy way to install a newer
    version while keeping all configuration changes that have been made on a
    previous one as for 'sendmail', 'sshd.conf','firewalls', etc...
    have all your configuration under a change management system, [...]
    ^^^^^^^^^^^^^^^^^^^^^^^^
    Any recommendations ?

    Regards
    Przemek


    ------------------------------------------------------------
    Jak zdobyc 2766 zl dofinansowania na obs??uge ksiegowa firmy?
    http://linkint.pl/f2969
  • Christopher J. Buckley at Apr 18, 2011 at 2:32 pm

    2011/4/18 <przemolicc at poczta.fm>:
    On Fri, Apr 15, 2011 at 07:53:34PM -0700, John R Pierce wrote:
    On 04/15/11 7:40 PM, Michel Donais wrote:
    Will it be the same from 5.6 to 6.0 or a full install will be better.
    Full installs are always recommended between major versions.
    Thank's all for the advise; but is there any easy way to install a newer
    version while keeping all configuration changes that have been made on a
    previous one as for 'sendmail', 'sshd.conf','firewalls', etc...
    have all your configuration under a change management system, [...]
    ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^^^^^^^^^^^^^^^^^^^^^^^^
    Any recommendations ?
    Puppet. http://www.puppetlabs.com/


    --
    Kind Regards,
    Christopher J. Buckley
  • Ljubomir Ljubojevic at Apr 15, 2011 at 4:36 am

    Michel Donais wrote:
    To pass from Centos 5.5 to 5.6 it was easy as an upgrade.

    Will it be the same from 5.6 to 6.0 or a full install will be better.

    ---
    There is so big difference between them (base packages, package and
    system design, dependencies) that full install will be necessary, not
    only recommended. I think upgrade might be even impossible.

    Ljubomir

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos @
categoriescentos
postedApr 14, '11 at 11:03p
activeApr 18, '11 at 2:32p
posts14
users11
websitecentos.org
irc#centos

People

Translate

site design / logo © 2022 Grokbase