There are two supported versions of CentOS in the wild now.
Note that I exclude CentOS6 as that is pretty much end of support now. So we have only versions 7 and 8 to play with.
Version 7 is EOL in 2024, 8 is EOL in 2029.
My reason for requiring CentOS was that Docker does not run out-of-the-box on Fedora31 so I was dubious about any future support for it there, and it was safer to move to a supported OS rather than just pray that the Docker team would bother with updating their packages for Fedora.
RHEL8 (and therefore CentOS8 also) has dropped support for docker within their repositories so I had to rule out CentOS8. I may revisit that if the Docker packaging teams ever create their own upstream repository to support RHEL8.
So this post is on installing CentOS7 and the required packages I needed to migrate my webserver from F30 to CentOS7.
The conversion was relatively painless.
- all my custom C compiled binaries simply copied across from Fedora30 and ran on CentOS7, a great benefit as I can for now keep my dev machine on Fedora
- mysqldump of databases on Fedora loaded into CentOS7 perfectly
- all the PHP based applications could simply have their directories (and http conf.d entries as appropriate) copied to the new server and worked with the loaded database entries… after PHP was upgraded of course
The major steps needed for the conversion are documented below.
Issues with creating the virtual machine under Fedora31
My host machines are currently both on Fedora31, the ISO I was using was CentOS-7-x86_64-Everything-1503-01.iso.
There was a rather large issue in building the VM, but I got there in the end.
- virt-manager does not allow configuration of IDE disks
- the CentOS7 install requires IDE disks, it could not locate disks created by virt-manager as virtio (or sata)
- to have IDE disks available requires the emulator /usr/bin/qemu-kvm but virt-manager on f31 only uses /usr/bin/qemu-system-x86_64
The resolution to this was to manually create a VM XML file (based on a CentOS7 VM I created a looong time ago when virt-manager did allow IDE, just updating things like name, uuid, disk name, mac address etc to match values used in the failed Centos7 attempt), precreate the qcow2 disk and simply ‘virsh define xx.xml’ to define the VM.
At that point I could use virt-manager to select the cdrom as the boot device and install CentOS7 without further problems. I was also able to check that CentOS7 had all the packages available that I would need to migrate my webserve from Fedora to CentOS. Remembering of course to use ‘yum -y install epel-release’.
Upgrading PHP to 7.3
CentOS7 shipped with php5.4 which is no longer supported, and most web applications will not even run on such and old version.
php7.4 is available for CentOS7, but I chose to use 7.3 to match what was already running on my existing webserver.
Rather than rewrite existing documentation this ecternal post on installing php 7.3 on CentOS7 covers all the steps needed. The procedure worked without error… although I did one additional step before following the procedure whist was to remove all the php5.4 packages installed by default with CentOS7.
Installing Jetty
A “yum search jetty” did not find an all encompassing package that would install Jetty, and I was not keen on just installing every package beginning with jetty.
Instead I followed the documentation on installing jetty on CentOS7 from the linuxhelp site. The procedure documented there worked without any problems.
The only additional step I had to do was move my apps from /var/lib/jetty/webapps (where F30 required them) to /opt/jetty/webapps where the manual install expects Jetty apps.
The EFF Certbot
I chose to install the version of Certbot recomended for CentOS8, the best choice as I had upgraded php.
Again the documentation on installing certbot is easy to follow.
After downloading the certbot-auto file I chose perform only the “certbot-auto –install-only -v” step, which worked without issues.
I have not yet tried the “certbot-auto renew” comamnd to obtain new certificates as the ones I use are nowhere near their expiry date.
Puppet Agent
I use puppet for configuring my servers, installing the puppet agent was simply
rpm -Uvh https://yum.puppetlabs.com/puppetlabs-release-pc1-el-7.noarch.rpm yum install puppet-agent systemctl enable puppet
MariaDB Databases
The mariadb databases were simple to migrate as my webserver takes hourly database dumps.
On the new CentOS7 server it was simple a case of installing mariadb-server and starting the mariadb service, and running the secure setup script to get a nice clean setup.
Then sourcing (\.) the latest dump file from the Fedora30 server. This completed with no errors and all users, databases and database grants etc. were in place and working; tested by logging onto all the apps that use the database to confirm stored app userids worked and apps behaved as expected.
PHP based applications
All the PHP based applications (including wordpress) I use were able to be simply migrated across to the new server as part of the httpd directory structure copy, with the following additional steps
- webcollab: simply required “yum install php-mbstring”
- owncloud: “yum install php-pecl-zip php-intl php-xml”, but see notes below
Owncloud server components do not exist in OS distribution repositories. You obtain the owncloud-files package from https://download.owncloud.org/download/repositories/production/owncloud/.
As I was installing onto CentOS7 I downloaded the rpm file for CentOS8 and manually installed it (rpm -i xxx.rpm), it matched the version used on Fedora30 so should work with the existing databases once the DNS entries for the server are changed so your clients point to it.
I chose to create a completely new database and re-install as I only one sync user (myself) so I could just re-add my credentials..
Snort intrusion detection system (IDS)
This was simply a case of “yum -y install libtool libpcap-devel libdnet-devel bison flex” then recompiling the DAQ and snort binaries.
As I installed using the default configuration files (mainly to allow me to document the changes) rather than just copy across my existing configurations there was also a bit of manual customisation needed as shown below.
Assuming you have downloaded the snort and daq static source from the snort website (and installed the packages listed two paragraphs up) the steps to get snort installed are below; note that I placed the sources in /home/mark/installs/snort so change that location to the one you used.
cd /home/mark/installs/snort/daq-2.0.6 ./configure make make install make clean cd /home/mark/installs/snort/snort-2.9.12 ./configure --enable-sourcefire --disable-open-appid make make install make clean mkdir /etc/snort cd /etc/snort cp /home/mark/installs/snort/snort-2.9.12/etc/* .
And you will need to add a user and group for snort, the group snort is added automatically when the user is added with system defaults.
Simply “useradd snort”. Do that at this point as we will be changing filesystem permissions to this user in later steps.
Using the community rules (the free rule packages for snort) quite a bit of editing of the snort.conf file. As you should edit it to define a trusted home network anyway lets edit the snort.conf file.
Rather than go into details, as this post is not about installing snort, below is a “diff” between the supplied snort.conf and my customised one ( < is my changes, > is the origional line ).
< #ipvar HOME_NET any
< ipvar HOME_NET 192.168.1.0/24
> ipvar HOME_NET any
< #ipvar EXTERNAL_NET any
< ipvar EXTERNAL_NET !$HOME_NET
> ipvar EXTERNAL_NET any
< var RULE_PATH /etc/snort/community-rules
< var SO_RULE_PATH /etc/snort/so_rules
< var PREPROC_RULE_PATH /etc/snort/preproc_rules
> var RULE_PATH ../rules
> var SO_RULE_PATH ../so_rules
> var PREPROC_RULE_PATH ../preproc_rules
< var WHITE_LIST_PATH /etc/snort/community-rules
< var BLACK_LIST_PATH /etc/snort/community-rules
> var WHITE_LIST_PATH ../rules
> var BLACK_LIST_PATH ../rules
< include $RULE_PATH/community.rules
> include $RULE_PATH/local.rules
A N D -------- comment out all folowing includes after the community.rules
entry as they are not provided with the community rules.
As mentioned above I use the community rules. To install those simply follow the below steps.
mkdir /tmp/snort cd /tmp/snort wget https://www.snort.org/rules/community cd /etc/snort tar -zxvf /tmp/snort/community /bin/rm /tmp/snort/community rmdir /tmp/snort mkdir /usr/local/lib/snort_dynamicrules touch /etc/snort/community-rules/black_list.rules touch /etc/snort/community-rules/white_list.rules mkdir /var/log/snort chown snort:snort /var/log/snort
The commands in emphasis above should be placed into a weekly cron job along with a restart of snort to ensure you keep the rules up to date.
You will need to create a startup/shutdown script. The start command is (replace ens3 with your interface name)
/usr/local/bin/snort -D -A fast -b -d -i ens3 -u snort -g snort -c /etc/snort/snort.conf -l /var/log/snort -b
Note: for testing run in foreground with “/usr/local/bin/snort -A fast -b -d -i eth0 -u snort -g snort -c /etc/snort/snort.conf -l /var/log/snort -b” so all errors are written to your terminal.
Summary
Conversion from Fedora30 to CentOS7 is a fairly painless exercise. Most of the work needed I did in two days to get a fully working server. I spent an additional three days was spent on customising/testing puppet rules for this CentOS7 system (as some packages are different to Fedora), testing bacula backups/restores, penetration testing etc; basically a lot of stuff most users do not need to do.
Was the conversion sucessfull ?. You are viewing this post on the CentOS7 server, so yes :-).
