Re: [CentOS] Upgrade Question
On 01/10/2012 12:55 PM, Gene Poole wrote: We've got about 200 existing servers running CentOS/RHEL 5.6 and all new servers are being provisioned using CentOS/RHEL 6.1. So that everything is consistent we need to upgrade the servers running CentOS/RHEL 5.6. I've searched the CentOS wiki, the Red Hat site, and the internet looking for something official on upgrading/migrating from CentOS/RHEL 5.x to CentOS/RHEL 6.x. There's got to be a way other than having 2 times hardware. Any ideas??? Note, it does not take 2x the hardware ... you only need 1 extra machine to convert 1 server at a time from 5.x to 6.x and when you get done, use that do the next one. You can do more than one on a machine with VMs as well (or as suggested, backup, format and bring on data, reconfigure) You CAN (unsupported :D) also use a 6.x disc and run an upgrade over top the old machine. (It should offer that as an option for the install). But RH does not recommend or support upgrades done that way if using RHEL, so use at your own risk. Also please understand that things are not going to just work after an upgrade from CentOS 5.x to 6.x. For example, if you have php based websites using php-5.1.6-x in CentOS-5, you are likely going to have issues running them on php-5.3.x in CentOS-6. The bottom line is that CentOS provides 7 years of support, but moving between major versions requires that you reconfigure everything. You can still get support for CentOS-5.x through 31 Mar 2014, so you have time before you need to move those 5.x servers to 6.x. signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Upgrade Question
On Tue, 10 Jan 2012 13:55:05 -0500 Gene Poole wrote: We've got about 200 existing servers running CentOS/RHEL 5.6 and all new servers are being provisioned using CentOS/RHEL 6.1. So that everything is consistent we need to upgrade the servers running CentOS/RHEL 5.6. I've searched the CentOS wiki, the Red Hat site, and the internet looking for something official on upgrading/migrating from CentOS/RHEL 5.x to CentOS/RHEL 6.x. There's got to be a way other than having 2 times hardware. Backup your data/configurations, reformat, re-install your data/configurations. There is no other official way to change from v5 to v6. -- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com www.creekfm.com - FIFTY THOUSAND WATTS of POW WOW POWER! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Upgrade Question
Gene Poole wrote: We've got about 200 existing servers running CentOS/RHEL 5.6 and all new servers are being provisioned using CentOS/RHEL 6.1. So that everything is consistent we need to upgrade the servers running CentOS/RHEL 5.6. I've searched the CentOS wiki, the Red Hat site, and the internet looking for something official on upgrading/migrating from CentOS/RHEL 5.x to CentOS/RHEL 6.x. There's got to be a way other than having 2 times hardware. Any ideas??? What we do is build one, then create /boot/new and /new on the next server, rsync over to them, then mkdir /boot/old and /old, and (using zsh with modules loaded) mv * old, mv old/lost+found ., mv old/new/* ., make sure a few things are correct (for example, ifcfg-eth*, /etc/ssh/), and sync, then reboot. All your other stuff is fine mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Upgrade Question
On Tue, Jan 10, 2012 at 1:35 PM, m.r...@5-cent.us wrote: We've got about 200 existing servers running CentOS/RHEL 5.6 and all new servers are being provisioned using CentOS/RHEL 6.1. So that everything is consistent we need to upgrade the servers running CentOS/RHEL 5.6. I've searched the CentOS wiki, the Red Hat site, and the internet looking for something official on upgrading/migrating from CentOS/RHEL 5.x to CentOS/RHEL 6.x. There's got to be a way other than having 2 times hardware. Any ideas??? What we do is build one, then create /boot/new and /new on the next server, rsync over to them, then mkdir /boot/old and /old, and (using zsh with modules loaded) mv * old, mv old/lost+found ., mv old/new/* ., make sure a few things are correct (for example, ifcfg-eth*, /etc/ssh/), and sync, then reboot. All your other stuff is fine Have you looked at http://rear.sourceforge.net/ (and in EPEL) as a potential backup/clone/rollout mechanism? It seems like something that might suit your sensibilities, but I'm not sure what kind of contortions you would need to do to boot into its recovery image remotely.For anyone too lazy to look, it builds a bootable iso containing your own current system's tools to re-install itself, recreating the filesystem (LVM/raid/partitions) and dropping in a backup that can be included or separate. It is intended for mostly automated restores back onto the same system but I think it can be abused for cloning and there is a point where you can adjust the filesystem layout. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Upgrade Question
Les Mikesell wrote: On Tue, Jan 10, 2012 at 1:35 PM, m.r...@5-cent.us wrote: We've got about 200 existing servers running CentOS/RHEL 5.6 and all new servers are being provisioned using CentOS/RHEL 6.1. So that everything is consistent we need to upgrade the servers running CentOS/RHEL 5.6. snip Any ideas??? What we do is build one, then create /boot/new and /new on the next server, rsync over to them, then mkdir /boot/old and /old, and (using zsh with modules loaded) mv * old, mv old/lost+found ., mv old/new/* ., make sure a few things are correct (for example, ifcfg-eth*, /etc/ssh/), and sync, then reboot. All your other stuff is fine Have you looked at http://rear.sourceforge.net/ (and in EPEL) as a potential backup/clone/rollout mechanism? It seems like something snip The one difference with the method we use is that you *don't* have to format /, and so anything you have under it is still safe. We normally have a few directories that are local, and so need to be saved (web, a temp that everyone can use that is guaranteed *not* to go away, etc). It's also pretty quick: you don't affect the running system while you're rsyncing over, so then the rotation takes long enough to issue the few commands, check grub and fstab, and reboot. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Upgrade Question
On Tue, Jan 10, 2012 at 3:35 PM, m.r...@5-cent.us wrote: What we do is build one, then create /boot/new and /new on the next server, rsync over to them, then mkdir /boot/old and /old, and (using zsh with modules loaded) mv * old, mv old/lost+found ., mv old/new/* ., make sure a few things are correct (for example, ifcfg-eth*, /etc/ssh/), and sync, then reboot. All your other stuff is fine Have you looked at http://rear.sourceforge.net/ (and in EPEL) as a potential backup/clone/rollout mechanism? It seems like something snip The one difference with the method we use is that you *don't* have to format /, and so anything you have under it is still safe. We normally have a few directories that are local, and so need to be saved (web, a temp that everyone can use that is guaranteed *not* to go away, etc). But that also means you don't get to re-arrange your filesystem layout to set up a bigger /boot, change filesystem types, or fix something you've learned could be better in the years of running the previous version. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] upgrade question. - when to reboot
On 1/15/09, Kenneth Burgener kenn...@mail1.ttak.org wrote: On 1/9/2009 9:49 AM, Robert Nichols wrote: If a hard reboot is what you are attempting to avoid, with 'kexec' even the Linux kernel can be reloaded without a hardware reset. This is convenient if you want to avoid the long system reset time. Kexec is a patch to the Linux kernel that allows you to boot directly to a new kernel from the currently running one. In the boot sequence described above, kexec skips the entire bootloader stage (the first part) and directly jumps into the kernel that we want to boot to. There is no hardware reset, no firmware operation, and no bootloader involved. The weakest link in the boot sequence -- that is, the firmware -- is completely avoided. The big gain from this feature is that system reboots are now extremely fast. For enterprise-class systems, kexec drastically reduces reboot-related system downtime. For kernel and system software developers, kexec helps you quickly reboot your system during development or testing efforts without having to go through the costly firmware stage every time. [1] if you really have to have as perfect an uptime as possible then you can actually patch a running kernel using ksplice http://www.ksplice.com/ should only be used for critical security updates but useful nonetheless mike ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] upgrade question. - when to reboot
Michael Simpson wrote: if you really have to have as perfect an uptime as possible then you can actually patch a running kernel using ksplice http://www.ksplice.com/ should only be used for critical security updates but useful nonetheless mike ___ Its not that I want a perfect uptime, I just want to make sure I reboot when needed and not reboot when it is not necessary. Thank you all for your input. Brian. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] upgrade question. - when to reboot
On 1/9/2009 9:49 AM, Robert Nichols wrote: Brian wrote: Is there a list of packages that after update require a reboot, other then kernel? For updates other than the kernel, there is almost always an answer short of a full reboot. But, finding that answer and being 100% certain that it is a complete answer can be a challenge, and is, say, bringing the system down to single-user mode momentarily all that much better than simply rebooting? If a hard reboot is what you are attempting to avoid, with 'kexec' even the Linux kernel can be reloaded without a hardware reset. This is convenient if you want to avoid the long system reset time. Kexec is a patch to the Linux kernel that allows you to boot directly to a new kernel from the currently running one. In the boot sequence described above, kexec skips the entire bootloader stage (the first part) and directly jumps into the kernel that we want to boot to. There is no hardware reset, no firmware operation, and no bootloader involved. The weakest link in the boot sequence -- that is, the firmware -- is completely avoided. The big gain from this feature is that system reboots are now extremely fast. For enterprise-class systems, kexec drastically reduces reboot-related system downtime. For kernel and system software developers, kexec helps you quickly reboot your system during development or testing efforts without having to go through the costly firmware stage every time. [1] Kenneth [1] http://www.ibm.com/developerworks/linux/library/l-kexec.html ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] upgrade question.
Brian wrote: I've did some googling and have not came up with and answer yet. Is there a list of packages that after update require a reboot, other then kernel? That is a difficult question, and the answer depends on how certain you need to be that no running process is still using the old version. For system daemons, a restart is typically done in the post-install script, provided that can be done non-disruptively. Long-running user processes (shells, browsers, mail readers, etc., etc.) will still be using the old versions of executables, libraries, and other resources until the user terminates the process or logs out. Library updates in particular are a big problem because there is no reliable way to know whether the (now unlinked) old version is still in use. For a lot of files, lsof | egrep 'DEL|deleted' will show deleted versions still in use, but libraries in particular are typically mmap()ed and closed, so lsof won't pick them up even though they are still in use. For updates other than the kernel, there is almost always an answer short of a full reboot. But, finding that answer and being 100% certain that it is a complete answer can be a challenge, and is, say, bringing the system down to single-user mode momentarily all that much better than simply rebooting? -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
