As you know CentOS 5 е EOL (End-Of-Life) from March 31st 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 short, that lists the CentOS mirrors 5 they are already lost and when we try to take content directly we get the following refusal:

# curl ''
Invalid release

In general, the most sensible idea is to reinstall the tin with a normal distribution., which supports a working distribution upgrade. Unfortunately, this is not the case with me, and this is not an option on the table at all. So we had to play a bit of a gypsy scheme – we start using Vault mirror. In a moment of perfectly clear creature and common sense I know, that I will not receive, any updates that are not the purpose of the exercise, а искаме просто да има работещ yum с, който да инсталирам пакет, който ми е необходим. За целта за коментираме всички mirrorlist променливи и добавяме baseurl в /etc/yum.repos.d/CentOS-Base.repo. Накрая получаваме yum repo от вида на

name=CentOS-$releasever - Base

#released updates
name=CentOS-$releasever - Updates

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

Finally we play a yum clean all && yum update. If everything ends without getting an error, then we have successfully completed the scheme and we can safely install the obsolete packages.

I had to make a bootable USB under OS X. To my great surprise, I found that the copy speed with DD is disgustingly low ~ 600KB / s 😕 . After a short search I found, that I should use rdiskX instead of diskX. The idea is that rdisk is synonymous with raw device. So far, I immediately added an r to the block device to which I copied the ISO and then found that the speed is even lower ~ 150-200KB / s 😡 . The mystique is now complete and previous information has been confirmed by many sources!!!! Everything fell into place after I put the bs directive.

bs=n Set both input and output block size to n bytes, superseding the ibs and obs operands. If no conversion values other than noerror, notrunc or sync are specified, then
each input block is copied to the output as a single block without any aggregation of short blocks.

After I put 1M for the size of bs I achieved the speeds I expected from my USB. Then I tested and the difference between disk and rdisk definitely the difference was about 10-12 times in speed in favor of rdisk. A very cultural way to monitor the speed and progress of dd can be achieved with the following pipeline

sudo dd if=Downloads/ bs=1M | pv | sudo dd of=/dev/rdisk2 bs=1M

2 fast RAID 5 advice

  1. If you have RAID 5 system keep the disks in MBR instead of in GPT – at least he gave it to me +10 – +15% difference
  2. Be sure to set / sys / block / md0 / md / stripe_cache_size because it is too small by default. Here the values ​​are according to depends on me 32768 gave the most decent result

From about 2 weeks php 5.3 enters history slowly but surely. On the 11th, it announced the end of its support and that only security patches would be released for 1 year. In general, PHP 5.4 goes into old stable stages and PHP 5.5 becomes stable, which is a bit fun because some of the add-ons and plugins of php still do not work quite correctly but also a version 5.5 is quite new so I will refrain from migrating to it.

So let me tell you about my migration to 5.4 from 5.3. I had released it in advance information for obsolete features, those that have changed dramatically and those that will no longer be maintained so that we do not have drama on both sides whether it will ignite or not 😉 So this morning I chose the time to start the migration around 7 as he got up, that there is minimal pain during migration if it does not go smoothly. To my great surprise, everything went more than smoothly – I compiled my PHP 5.4.17 I started apache and oh heavens everything is there. A quick look through the logs has no roar of depricated or unfamiliar features at all – apparently the boys did a good job. Then all I had to do was recompile the add-ons that were compiled with the old API like APC, RAR and others. Second restart and everything fell asleep. Separately, I expect improvements in performance because everywhere people point with their thumb to some tablets that show how PHP 5.4 consumes less RAM and executes scripts faster.


I had a pretty interesting tease tease – I had to create a huge number of randomly generated passwords as I was required to be of a certain length to contain large lowercase letters and numbers, normal things. Sounds easy, doesn't it?. I used /dev/urandom for the main generation and then with a short pipeline I filtered to the desired number of characters and types of characters to be used. As long as I'm screwed into the main script is the pipeline :

cat /dev/urandom | tr -dc '[:alnum:]' | fold -w 20| head -n 1

So let's take a closer look at what's going on here. We take the output of cat / dev / urandom. Then we filter it to show only small ones, capital letters and numbers. Then with fold we limit the length of the strings to the desired number. Finally, we limit the display only 1 row of the entire output. Basically easy as 1-2-3. If you want to increase the complexity of the password and with special characters in the regular expression of tr can be used :graph: or :print: instead :scooping:, which include all characters without or with space.

cat /dev/urandom | tr -dc '[:graph:]' | fold -w 20 | head -n 1
Enhanced by Zemanta