As you know CentOS 5 EOL is (End-Of-Life) from March 31 2017. Which leads to the following very interesting problem:

# yum update
Loaded plugins: fastestmirror, security
Loading mirror speeds from cached hostfile
YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
 Eg. Invalid release/
YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
 Eg. Invalid release/
removing mirrorlist with no valid mirrors: /var/cache/yum/extras/mirrorlist.txt
Error: Cannot find a valid baseurl for repo: extras


The problem is that short lists of CentOS mirrors 5 already kicking in and attempt to directly get content obtained after refusal:

# curl ''
Invalid release


In general overall the most prudent idea to reinstall the tin with a normal distribution that supports working distributive upgrade. Unfortunately mine is not the case and it does not stand as an option on the table. So we had to play a little gypsy scheme – begin to use Vault mirror. At the moment completely clear creature and sanity know, I will not receive any updates that is not the aim of the exercise, and just want to have working with yum to install package that I need. For this purpose commented out all mirrorlist variables and add baseurl in /etc/yum.repos.d/CentOS-Base.repo. Finally we get yum repo on the type of

name=CentOS-$releasever - Base

#released updates
name=CentOS-$releasever - Updates

#additional packages that may be useful
name=CentOS-$releasever - Extras

Finally play a yum clean all && yum update. If everything ended without an error then we successfully completed the scheme and we can safely install outdated packages.


Mdadm is my beloved friend but something that irritates a lot – periodic inspections and resink the security health of RAID array- for example, there are data in a bad sector-and, which in turn crushed by the machine to the IO. Basically after I found čoplene guilty – branches that start usually around 1 pm every Sunday night. The idea is clear – sure that the array is in great condition and there are no dramas with the information. This is good but it seems many weekly, that's why it prekonfigurirah to r″nva of the first date of the month.

For Redhat-based derivatives path of Krone's /etc/cron.d/raid-check. For Debian based distroci's way /etc/cron.d/mdadm. Kronovete in turn called bash scripts /usr/sbin/raid-check for CentOS etc and /usr/share/mdadm/checkarray for Debian and friends. Parameters to the scripts are taken from /etc/sysconfig/raid-check or, respectively, /etc/default/mdadm where you may be banned entirely and check, that is not a very smart idea.


Anyone who deals with professional web hosting knows what a threat they represent infected users with malware, web shells etc. In the obšiât case is used maldet not a bad script. It is distinguished by 3 things

  1. Terribly slow
  2. It is horribly slow and if you drop it in the monitoring regime will mess with your server
  3. Maintain your own database with md5/hex definici for bad code.

Just his last feature makes it useful, as you can s″bmitvaš files which have not been detected so far, and at a later stage will enter into the database. As I shared in section 1 and 2 its speed is shockingly low – at low load of the machine 70 k file are scanned for about an hour and a half. For this reason I started to help my good friend by ShadowX Malmo – an alternative to the maldet written in python with a little more flexibility. Unfortunately due to lack of time (mainly but not only) We're not a finished project, which at the moment is not very usable – There are quite a few bugs that need to be cleaned. In the past few days I had problems with clients infected with CryptoPHP who had the huge public_html files ~ 60 k + inod-user. Since the total had to be scanned over 200 k file which in rough accounts would take 5+ hours I decided to Nip/Tuck maldet configuration, to reduce the files that will be scanned to a more reasonable number and time. While čopleh konfa I noticed the following lines

# Attempt to detect the presence of ClamAV clamscan binary
# and use as default scanner engine; up to four times faster
# scan performance and superior hex analysis. This option
# only uses ClamAV as the scanner engine, LMD signatures
# are still the basis for detecting threats.
# [ 0 = disabled, 1 = enabled; enabled by default ]

Interesting… Apparently, there is a possibility to use the ClamAV – who also is distinguished by its great speed but why not try. The quickly installed it

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

/scripts/check_cpanel_rpms --fix --targets=clamav

I run maldet and click the small folder – I don't see a difference in speed and behavior – He used his perl-ski scanner instead of clamav. After a brief delving through the source I found maldet the following lines

 clamscan=`which clamscan 2> /dev/null`
 if [ -f "$clamscan" ] && [ "$clamav_scan" == "1" ]; then
        eout "{scan} found ClamAV clamscan binary, using as scanner engine..." 1
    for hit in `$clamscan -d $inspath/sigs/rfxn.ndb -d $inspath/sigs/rfxn.hdb $clamav_db -r --infected --no-summary -f $find_results 2> /dev/null | tr -d ':' | sed 's/.UNOFFICIAL//' | awk '{print$2":"$1}'`; do

Yes I did a which clamscan and to my great surprise I discovered that clamav is not in PATH-what a stupid Cpanel has left him only in/usr/local/cpanel/3rdparty/bin/from where he uses binarkite. A quick fix the problem ln:

ln -s /usr/local/cpanel/3rdparty/bin/clamscan /usr/bin/clamscan

In re scan now maldet top reports

{scan} found ClamAV clamscan binary, using as scanner engine...

After already uses ClamAV maldet ends your scan 3-4-5 times faster than before. The test showed – 70k-izt″rkla inod them for about 25 min which is about 3 and a half times faster than before.

Before I start with another random hate toward 50 with OS ’ found that inside the cave I mean, that daily have to administriram her and know her from the first person singular quite well. Today I took my time to iztestvam the new magical unheard and unseen distrubitiven feature upgrade (pseudo) 😀 . The first thing that amazed me is, that RedHat in their infinite wisdom have decided to cease support for the x 86 architecture 🙄 . I am fully aware that we are 2014 and server processors 32 bits long are missing instructions. Yes but what users do on a small VPS and – h64 paw more RAM, However you look at it if you thin virtual machine with 512MB-1 GB of RAM will fight for every megabaj out of it and I'm not going to waste 20-30% from her just to use on the big set of instructions. Prepsuvah as I instalil x 86 and CentOS pulled a h64. Immediately I saw a difference in ISO's – ~ 100MB at minimal 6.5. Prepsuvah one more time. I installed again as virtualkata decided to see how well the RedHat have done their job – I took/var and/usr individual 😈 LVM partitions . After the installation I've updated all the packages I installed apache and, php, bind and mysql – It was interesting if they s″rvisite. I opened as a good student guide of CentOS for the update and started diligently to follow him step by step. When I reached the moment to start the actual upgrade this sloppy excuse me, I have a critical problem 🙄 . Review the detailed output – Yo/usr can't be on a separate partition, I knew 😆, you won't be disappointed in Jim Whitehurst and company. In addition to “extreme” There were a lot of problem messages for unsigned packages, konfizi files which do not match, etc.. WTF I didn't even use 3rd all repositories from their mirrors pulled down I hadn't done any settings just a simple yum install. It was already clear so quite bluntly forsirah upgrade. They freeze back diligently as finally asks me the script and it's over for/usr shares. I was too lazy, I try to fiksna it, either way, it was only for scientific research purposes there's no product to server nadgraždam at the moment. I caught my virtualkata I have reinstalled this time everything I pushed it in 1 share. Also I took a lesson, no updates any extra s″rv″si, After the installation a direct upgrade. The final step came up again dialogue dosaniât who told me, I have a pretty High problems – invalid packets, konfizi and so on and so forth but can continue. I knew from the start they don't make them like you have things. They freeze over and waited for the – Oh what a miracle the upgrade completed successfully. And everything worked, or at least the boot loader and I tried to install additional packages, but his command halt zavisvaše – huh has still had to bug 💡 . After this the whole crowded I decided to install a clean Centos 7 see if it growls for LVM partition in/boot – 6.5 does not allow such Audacity. I started my ISO's and I was mildly shocked by the installer – It was extremely convenient not “tidy”, but in order to fully is beautiful. After some struggle I managed with the cherished goal and Yes to install gasket, You should put out/boot-and beyond-👿 a LVM This is extremely serious and not annoying, If for some reason you forget to increase the size of the boot partition by 200MB and some old cores what happens.

Basically, I didn't expect anything and I'm still disappointed in CentOS.

As CentOS and RHEL curse shit-and there are some things they invented quite literate. For example, the addition of a large number of additional IP is quite a nice job. In General, if you need to add a large number of addresses I'd signed a bash script in that period to carry out the operation in question that the hand is not working. Under Centos/RHEL people have figured it out quite nice range file. Basically we create file/etc/sysconfig/network-scripts/ifcfg-eth0-range0. Here replace eth0 with the network adapter name if not eth0. Then add the following content


as the arguments are

  • IPADDR_START – starting IP address
  • IPADDR_END – final address
  • NETMASK – subnet mask
  • CLONENUM_START – numbering to begin network adapter eth0:0 in our case