I've seen that RHEL 7 beta is out for some time now: is there a CentOS version of that beta? If not, is it likely to be a real pain, once CentOS 7 is released, to upgrade from RHEL 7 beta to CentOS 7?
Reason for this: at one of my local sf clubs, I've been trying to install Evergreen, F/OSS library software, on a system, and it's a nightmare. They seem to have been building it for Ubuntu whateverthelatestanimalis. The biggest problem is, IIRC, eventhandler and memchached; oh, and it uses postgresql 9, and nothing else. PGSQL 9 was not a big deal to install, but the other stuff.... Even trying to build it in /usr/local is a royal mess: though I've got the dbi installed, ./configure can't find it.
I do see, with a little googling, that everything I need for an older release of Evergreen should be installable without all this mess.....
mark
On 13 January 2014 14:33, m.roth@5-cent.us wrote:
I've seen that RHEL 7 beta is out for some time now: is there a CentOS version of that beta? If not, is it likely to be a real pain, once CentOS 7 is released, to upgrade from RHEL 7 beta to CentOS 7?
Check the progress on http://seven.centos.org/
As for the latter question - too early to tell.
On 1/13/2014 07:33, m.roth@5-cent.us wrote:
is there a CentOS version of that beta?
Not yet publicly available.
I've heard they have something running in the development environment, but that they're still working on getting some of the RPMs to build. That's a prerequisite for generating ISOs.
If not, is it likely to be a real pain, once CentOS 7 is released, to upgrade from RHEL 7 beta to CentOS 7?
Anything that makes a RHEL7 -> C7 transition more difficult also makes the reverse transition more difficult. In this new world of Red Hat / CentOS collaboration, that would be a Bad Thing. I'd be surprised if the transition was more difficult than just a forced upgrade of the centos-release RPM.
How bad is the worst case -- reinstall the OS and rebuild the software -- anyway? By doing your initial work on the RHEL 7 beta, you learn what you need to know to quickly redo the work on CentOS 7.
Reason for this: at one of my local sf clubs, I've been trying to install Evergreen, F/OSS library software, on a system, and it's a nightmare. They seem to have been building it for Ubuntu whateverthelatestanimalis. The biggest problem is, IIRC, eventhandler and memchached; oh, and it uses postgresql 9, and nothing else. PGSQL 9 was not a big deal to install, but the other stuff.... Even trying to build it in /usr/local is a royal mess: though I've got the dbi installed, ./configure can't find it.
Post an actual error message, and someone may be able to help.
On Tue, Jan 14, 2014 at 2:27 PM, Warren Young warren@etr-usa.com wrote:
How bad is the worst case -- reinstall the OS and rebuild the software -- anyway? By doing your initial work on the RHEL 7 beta, you learn what you need to know to quickly redo the work on CentOS 7.
Is there anything to simplify the process of duplicating the set of installed packages when you didn't pay that much attention the first time around? It seems like taking the list from 'rpm -qa' on a running machine and feeding it to 'yum install ....' on a new minimal install should get pretty close, but then you need to find all of your locally modified config files. Most of that should be under /etc/sysconfig for an easy diff, but not everything.
Since RH7 is built on Fedora 19 and f19 is available for arm boards, will we see a RH7 for arm boards?
I would spend time on the beta if I could get an arm build for a reasonable arm board. Target application is a PBX.
On 1/14/2014 13:41, Les Mikesell wrote:
It seems like taking the list from 'rpm -qa' on a running machine and feeding it to 'yum install ....'
I suspect it's not actually that simple. I think you'd need to do a fair bit of processing on the rpm -qa list to be able to build a yum command that will succeed. Consider the RPM "provides" mechanism, which allows two different RPMs to provide the same capability under different names. {redhat,centos}-release is this way, for example.
One of the reasons I'm playing with RHEL 7 right now is that my end purpose is to be able to modify the documentation and scripts our system installers will use to build new CentOS 7 systems. So, I'm already recording all of the changes needed, partly on paper, partly in a Subversion repository. My RHEL 7 VM is disposable.
then you need to find all of your locally modified config files.
Whenever I'm faced with a system with unknown changes which has to be nuked and rebuilt, I tar up /etc, /home, and *maybe* /var and/or /usr/local.
I usually don't bother with /var, since the irreplaceable things under /var get backed up separately: DB tables, the web tree, etc.
There are exceptions. The Bind zone files on the primary DNS server are essentially unique, for example. (The cached version on the secondary DNS server(s) isn't identical to the primary copy. It's stripped of comments, the formatting is a bit different, etc.)
I scp the backup tarball off to a file server somewhere, then replace the hard drive and start fresh. The extra HDD and disk space for the backups are cheap insurance.
The replaced HDD can be given another mission once you're satisfied that everything's migrated. Put it in an external USB case and use it for the new system's off-site backup, for example.
Most of that should be under /etc/sysconfig for an easy diff, but not everything.
Not a lot of things. I regularly modify things under
/etc/ssh/ /etc/httpd/ /etc/pki/ /etc/{init.d, rc.d}/ (via chkconfig and yum) /etc/yum.repos.d/ /etc/samba/
Plus there's plenty at the top level that changes occasionally:
/etc/{hosts,services} /etc/{group,passwd,shadow} /etc/sudoers
No, I'll stand by my current practice: tar up all of /etc and /home, at minimum.
On 14 January 2014 20:41, Les Mikesell lesmikesell@gmail.com wrote:
Is there anything to simplify the process of duplicating the set of installed packages when you didn't pay that much attention the first time around? It seems like taking the list from 'rpm -qa' on a running machine and feeding it to 'yum install ....' on a new minimal install should get pretty close, but then you need to find all of your locally modified config files. Most of that should be under /etc/sysconfig for an easy diff, but not everything.
Well one bit is /root/anaconda-ks.cfg to see what the kickstart to duplicate the install of the system would look like ...
As for config files well behaved RPMs should mark their config files in the manifest so a rpm -Va and parsing the output to look for config files changed from install should help ...
In addition you could do something like find /etc -type f -exec rpm -qf {} ; | grep -i 'not owned by' to find any config files in /etc that are properly marked in the spec files for a package...
There are probably a few special cases like postgresql having the postgres,conf file in the data directory for the service but you should be able to catch most config files to back up by combining the two tricks...
-
James Hogarth -
Les Mikesell -
m.roth＠5-cent.us -
Robert Moskowitz -
Warren Young