the echothis blog

Today I had to get PHP upgraded from 5.1 to 5.2.X on someone else’s server and didn’t have time to screw around. I have a PHP configuration that I’ve used in the past but it frankly can take too long to get set up, if time is of the essence. So here are my “quickie steps” (tested for the current release, 5.2.11 on CentOS 32- and 64-bit). Follow these and you can be running in 20 minutes (if you type fast!):

Download the latest stable PHP build from http://php.net and extract.

# back stuff up, just in case
cp -rv /usr/lib/php/modules /usr/lib/php/modules-bak
cp -v /usr/lib/httpd/modules/libphp5.so  /usr/lib/httpd/modules/libphp5.so.bak
 
# or, if you're on 64-bit:
mv /usr/lib64/php/modules /usr/lib64/php/modules-bak
ln -s /usr/local/lib/20090626/ /usr/lib/php64/modules
cp -v /usr/lib64/httpd/modules/libphp5.so  /usr/lib64/httpd/modules/libphp5.so.bak
 
# the ones after mysql-devel might be optional if you're pressed for time, but they're needed by phpmyadmin etc.
yum install httpd-devel mysql-devel libmcrypt-devel libxml2-devel zlib-devel libmhash curl-devel
 
# you may need to do the following, if compiling on 64-bit
export LDFLAGS=-L/usr/lib64/mysql
 
./configure --with-apxs2 --with-mysql=shared --with-mcrypt --enable-mbstring --with-curl --with-zlib
make clean && make install
 
# if the build fails, you may need to recompile libmcrypt as per http://marc.info/?l=php-install&m=108030891925096&w=2
wget http://sourceforge.net/projects/mhash/files/mhash/0.9.9.9/mhash-0.9.9.9.tar.gz/download
./configure
make clean && make install
wget http://sourceforge.net/projects/mcrypt/files/Libmcrypt/2.5.8/libmcrypt-2.5.8.tar.gz/download
./configure --disable-posix-threads
make clean && make install
cd libltdl
./configure --enable-ltdl-install
make clean && make install
 
# now for some reason by default PHP might be looking in /usr/local/lib for the php.ini, so symlink to it
cd /usr/local/lib
ln –s /etc/php.ini

Also add the following to /etc/php.ini (in case it doesn’t know to scan /etc/php.d by default):

...
[MySQL]
extension=mysql.so
; Allow or prevent persistent links.
mysql.allow_persistent = On
...

You’ll need to add the same for mbstring.so, etc. if you built them as well.

Got a few minutes left? If so install eaccelerator:

./configure
make
make install
cp /usr/local/lib/php/extensions/no-debug-non-zts-20060613/eaccelerator.so  /usr/lib/php/modules
 
mkdir /tmp/eaccelerator
chmod 777 /tmp/eaccelerator

and add the following to /etc/php.ini:
...
[eaccelerator]
extension=eaccelerator.so
eaccelerator.cache_dir = "/tmp/eaccelerator"
eaccelerator.enable = "1"
eaccelerator.debug = "0"
eaccelerator.optimizer = "1"

Update 12/12/2010: To build a more sophisticated 32-bit version of PHP 5.3.4, do the following:

yum install httpd-devel mysql-devel libmcrypt-devel libxml2-devel zlib-devel libmhash curl-devel libtidy-devel pcre-devel libjpeg-devel libpng-devel freetype-devel gmp-devel
 
'./configure' '--build=i686-redhat-linux-gnu' '--host=i686-redhat-linux-gnu' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' \
'--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' \
'--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' \
'--disable-rpath' '--with-pear' '--with-curl' '--with-exec-dir=/usr/bin' \
'--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-kerberos' \
'--with-iconv' '--with-openssl' '--with-zlib' '--with-layout=GNU' \
'--enable-magic-quotes' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg'  \
'--enable-ucd-snmp-hack'  '--without-sqlite' \
'--with-libxml-dir=/usr' '--enable-pcntl' \
'--enable-mbstring=shared' '--enable-mbregex'  \
'--with-gd=shared' '--enable-dba=shared' '--with-xmlrpc=shared' '--with-ldap=shared' \
'--with-mysql=shared,/usr' '--with-mysqli=mysqlnd' '--enable-dom=shared'  \
'--enable-soap=shared' '--enable-xmlreader=shared' '--enable-xmlwriter=shared' '--with-mcrypt'  '--with-mhash'  \
'--with-freetype-dir=/usr/lib' \
'--with-apxs2=/usr/sbin/apxs' \
'--disable-pdo' '--without-pdo-sqlite' '--with-tidy' '--with-pcre-dir' '--with-jpeg-dir' '--enable-zip'

From Part I, I now have a working backup device sitting in the closet, that is running rsync, just waiting to connect to the NAS. Time to hack the Mini.

1. The basic instructions are extremely well-written here. My model is, I think, the Etherdisk Mini V1 and these instructions are for the V2, but for the most part they work.
2. As I don’t have a full-time Linux desktop PC sitting around, I used my Knoppix 5.1 LiveCD to run Linux on the box I am using to mount and hack the Mini drive. It mounted the drive just fine, but I did have to switch the /dev/hda7 partition to be mounted read/write.
3. I extracted the tarball (with startup scripts and the rsync and dropbear binaries) located conveniently at the link above, and added the cgi-bin exploit described in the article to /www/cgi-bin/admin/. I suggest also adding it to /www/cgi-bin/public/ (see below).
4. Now a few more steps while the drive is open (will save you some headaches):
   1. I thought I was done hacking at this point. I put the drive back into the case, rebooted twice (it seemed to make some odd noises) and was able to access the exploit: http://192.168.2.34/cgi-bin/admin/exploit?ls –l
   2. Sadly, though, I was ultimately unable to get dropbear configured to use SSH keys. I tried
      http://192.168.2.34/cgi-bin/admin/exploit?dropbearkey -t dss -f /etc/dropbear/dropbear_dss_host_key
      which gave an output of
      Will output 1024 bit dss secret key to '/etc/dropbear/dropbear_dss_host_key'
Generating key, this may take a while...
Public key portion is:
ssh-dss XXXXXXXXX...long key string...XXXXXXXXXXXXXXXXX
Fingerprint: md5 XX:XX:XX:XX:...
      But I was unable to successfully use this to connect.
   3. So I was forced to use a password to log in. I figured that I could log in via SSH with my existing, usual Etherdisk Mini user (created with the factory web interface), but that fails because its shell is set to /bin/false automatically upon creation. I suppose this is to prevent you from doing what I am doing – but given no SSH daemon is normally running on the device anyway, what’s the point?
   4. Thus I needed to have a user account (with a password I knew – turns out empty passwords would get rejected) who had a shell set to /bin/sh. Since I was afraid of changing the root password for fear of bricking the drive, I tried to create new accounts as newuser/secret via
      http://192.168.2.34/cgi-bin/admin/exploit?(echo secret; echo secret!)|adduser -H -D newuser
      But that didn’t work for me since the desired password was not getting set. Didn’t work either if I tried to make it into a shell script.
   5. So in the end, I reopened the case, remounted the drive, and edited the /etc/passwd file directly. I changed, for my known user, the shell from /bin/false to /bin/sh as follows:

      root:x:0:0:root:/root:/bin/sh
bin:x:1:1:bin:/bin:/bin/sh
daemon:x:2:2:daemon:/sbin:/bin/sh
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
operator:x:11:0:operator:/var:/bin/sh
nobody:x:65534:65534:Nobody:/:/bin/sh
admin:x:500:100:LaCie Ethernet Disk mini Admin:/home:/bin/sh
visitor:x:501:100:rw,xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:/home:/bin/sh
myknownuser:x:502:100:rw,xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:/home:/bin/sh
      I did this for both /dev/hda7/etc and /dev/hda8/etc.

5. I install the drive back into the case, a boot up, and bingo, it worked. I can log in with WinSCP and PuTTy. I get an error upon login:

   Command 'groups'
failed with return code 127 and error message
-sh: groups: not found.

   But it works. I now have SSH access!

6. I check to make sure rsyncd is running on the Mini, and indeed it is. I log into the FreeNAS box, and it’s the moment of truth:
   
freenas:/mnt/data/docs# rsync -avzn --progress --stats myknownuser@192.168.2.34:'"/home/docs/"' .


Enter the password for the Mini user, and bam: it works. For some reason I have to connect to the Mini via IP address rather than hostname, but who cares!

Now all I need to do is write a backup shell script based on the above, set it to run on boot of the FreeNAS box, set the FreeNAS BIOS to wake up every night at 2am, and then I can forget about this whole episode.

Epilogue

I hope that some product marketing guy for a hardware company happens across this post, and sees the lengths to which a normal person will go to prevent their data from being lost again in the future. The hardware already exists on the market capable of doing what I want to do with it. As I showed, I’m willing to buy it too. So why are you unnecessarily blocking me from using it as I see fit, and instead forcing me into a free open-source alternative?

I thought I had a pretty good data backup strategy for my home network. I have several PC’s that all access a central NAS as a fileserver (a 250GB La Cie Etherdisk Mini), which is a nice little Linux-based device that has been running like clockwork for years. This was manually backed up, along with Vista Complete PC Backup Images of each, to a 500GB Western Digital My Book external USB drive. The latter I usually kept unplugged, in a drawer, so it wouldn’t get any wear and tear.

This is fine for years, then one day I made the mistake of leaving out the My Book, it got bumped by a houseguest, and the drive started making clicking noises and then couldn’t mount to my PC anymore. I tried removing the drive and manually connecting it to a Linux PC (running the Knoppix 5.1 Live CD), but that had no luck either.

So began the quest for a better backup strategy. I figured that in this day and age I would be able to buy a cheap little box that would sit powered off most of the time, but be able to automatically power itself up in the middle of the night to backup my NAS drive, then turn itself off to save energy (and the drives). So in order of priority:

1. It must run rsync, immediately knocking out the Windows-based solutions like Windows Home Server. I have tried SyncToy (and even programmed with the Microsoft Sync Framework SDK) and am not impressed with it. It may work fine for small syncs, but I have a lot of files, and it doesn’t scale well in my experience.
2. I must be able to open an SSH console to the box in case I want/need to change something. It will otherwise, of course, sit “headless” in a closet in the dark. This requirement implies that there is an active community of people that hack this particular model (since for some reason, no NAS manufacturers offer this out of the box).
3. It must be cheap (i.e., under 150 bucks).
4. (Nice to Have) It should be able to function as well as an NTFS-based external USB drive, so I can put Vista Complete PC backups on it for each of my PC’s (the NAS only has my documents, so I would hate to have to reinstall all my programs if one of my PC’s died). For Vista, I’ll have to manually plug it into each PC periodically to do this, but when I ultimately upgrade to Windows 7, apparently that lets you do a complete PC backup over a network, so the box will be able to stay in its closet all the time.

I figured this would be easy to find in this day and age, right? Wrong. Based on #2, the most active community seemed to be the one for Buffalo devices like the LinkStation. I came across a new model from them, the 1TB HD-CELU2 DriveStation FlexNet, which was designed to function as a NAS or a standalone USB drive. And it was cheap. So I picked one up and took it home, figuring I could hack it open, install rsync like people had done, configure some setup scripts, and then put this in the closet and let it do its thing every night.

I’ll go into more detail another time, but long story short, the LinkStation FlexNet doesn’t do any of that. Turned out that no one has had any success hacking this model, and neither did I. I’m not even sure of the tech specs. Some Japanese guy was nice enough to show how to safely open the box though. I was unable to mount the root filesystem in my Linux PC, I couldn’t use any of the hacked firmware developed for the other LinkStations, and I couldn’t use the apc_commander exploit. After a week of getting really low-level (i.e., fdisk, parted, dd, and dd_rescue). I learned some neat stuff about digital forensics though.

I was forced to admit failure. Oh, and by the way, I also discovered that if I was to change the filesystem type from FAT to NTFS so I could do the Vista backups, I could no longer use the box as a NAS. So it turns out that for all my needs, the NAS function of this device was worthless and I was left with a rather expensive USB drive.

So on to plan B – time to build my own backup device. I had some old hardware lying around, a PC and a few fairly large old IDE drives so my new plan was to convert a low-end PC to a NAS box, install as many drives as I could, and then use that as my backup device. Enter the excellent FreeNAS project.

It’s not hard to do this, and dare I say, after all the experience I had with commercial products, it’s rather satisfying as well. And I didn’t spend a dime to do it.

Here are the steps:

1. First, burn an ISO of FreeNAS. The official FreeNAS site is a more extensive resource but in my experience was a little dated on some of the details.
2. On the box you want to use, you will need a working CD-ROM. Set the BIOS to boot the CD-ROM first, then stick in your disk and go. I did find one PC that wouldn’t boot FreeNAS (it was a 2-year old Dell that halted on boot because of, if I recall, some USB problem), but an older Dell Dimension that I tried booted like a charm. FreeNAS is designed to run on almost anything so my experience there may have been unusual.
3. You can run FreeNAS as a LiveCD, but I chose to just install it to the primary hard drive for simplicity. I followed the instructions to install it to the drive, removed the CD, rebooted, and was done. In the space of a few minutes I had a functioning NAS that was running Samba (so it could be mounted as a network drive by my PC’s), was running rsync, and was running sshd so I could log in and check it out. With that, the box was promptly moved to the closet.
4. Now it was time to configure the drives. Just followed the directions, with one note: since I had installed both the FreeNAS root partition and my data partition to a single disk, when I mounted the data partition, I chose “MBR Partition”, Partition # 2, UFS file system type (this isn’t clearly documented). The other drives I had stuffed into the box were just mounted as single UFS partitions.
5. A nice little configuration that you can make is to set the drives’ standby behavior. I set them all to spin down after 5 minutes, which should extend their lifetime.

And so I now have a backup device. Next step – after all this, actually backing up the NAS via rsync. That means I have to hack the Etherdisk Mini.

I had to copy the contents of a drive on an XP box to another network drive (which was actually a FreeNAS box) on my LAN yesterday (part of a longer story involving a crashed backup disk – but that’s a tale for another time). It was over my LAN network and involved a zillion files. So I wanted:

1. Copy entire directories
2. Per-file progress feedback since some of the files are big
3. The fasted protocol possible. Since it was going to a NAS I could try copying over SSH, FTP, and TFTP in addition to simple Windows share copying (SMB).
4. Resumability of transfers
5. Must run on XP. I came across RichCopy, which is a multithreaded successor to RoboCopy, which actually works pretty well. In my case though it wouldn’t help me since I am bandwidth-constrained more than anything else.

I tried a number of ways to do this, namely:

1. FTP – couldn’t get the server working on FreeNAS (apparently due to a DHCP-related bug)
2. TFTP – the Windows client doesn’t look like it can do whole directories, only single files at a time
3. SSH – works but is dog-slow (I was getting about 150KB/s on my LAN)
4. Simple drag-and-drop copying over SMB – kept crapping out unexplainably.

So in the end I went with Robocopy, a free command-line tool from Microsoft. Built into Vista, you can install it from the Windows Server 2003 Resource Kit on XP. The simple command was:

robocopy c:\source\path\to\dir z:\dest\path\to\dir /mir /zb

Make sure your destination path doesn’t exist first. If you cancel out and run it again it picks up where it left off which is nice.

It wasn’t particularly fast, but at least it wasn’t as slow as SSH.