I am not a system administrator
Monday, January 12 2015
By the time I got out of bed this morning, there was a light rain falling on wet snow, indicating a fairly substantial increase in the temperature over what it had been for days. Not that it was pleasant outside, but just the fact that temperatures were above freezing greatly diminished the amount of firewood I had to burn to keep the house comfortable.
By profession, I am a web developer. When I was a kid, I never said that when I grew up I wanted to be a web developer (or even a computer programmer), but that is how I have earned most of the money that I have made in my life. Most of the jobs I work on are ones involving small teams, where I'm usually the most technically-versatile (if not always the most professional) team member, and so I suppose it should come as no surprise that I am often called upon to do work that is more properly the province of a system administrator. System administrators deal with the arcania of everyday computer (particularly server) function. Their job is usually more about configuration, installation, and backups than it is about writing code (although most system administrators can write scripts when the need arises). In working with systems, especially systems of a familiar type, on a repeated basis, they amass large vocabularies of server commands and know how to get those commands to do specific things without needing to constantly look things up on Google. By contrast, when I am called upon to do system administration work, every server is something of a mystery. This is partly because, due to the number of jobs I do, I find myself administering a wide range of servers (from those running flavors of Windows NT to those running Linux to those running OpenBSD). Nearly all the servers I work with these days run Linux, but there are so many flavors of Linux and they're all so different from each other (particularly in terms of directory structure, the code installed, and the means by which services are started and stopped) that every new server initially presents itself as a puzzle. And it's rare that I work with a server long enough to become truly comfortable with it.
I've found that taking careful notes of my interactions with each server is essential to building a proper management relationship. After several hours of work, those notes will contain 90% of the commands I'll need for that server. From then on I can just scan through the text file of the notes, copy various commands as needed, and paste them into a Putty window to execute.
For the past several days I've been hired on to do some emergency system administration for a site that I had a hand in developing over the course of at least two different phases dating back to 2008. The owner of the site never bothered to update the Cpanel administration software, and somehow a hacker got in and began using the server as part of a distributed denial of service (DDoS) attack. Initially my job was to get rid of any malware and then get the site running again (it had been defensively reset to factory conditions by the host, Spry.net). But then it proved impossible to get the site working on Spry.net, and I found Spry's system of technical support broken and useless, so the owner abandoned it and I was given a new server at MediaTemple.net. I managed to get the site up and working there, but then I ran into a problem. Some of the codebase relied on an old version of a shopping cart system called XCart, and that version depended on an old PHP directive called register_long_arrays, one that is no longer supported by modern versions of PHP (part of the software stack the site runs on). This meant that I had to install an old version of PHP on the new host, but yesterday I'd been unable to do this due to unexpected server issues, so I'd hired one of the MediaTemple people to do it for a fixed price of $79. This morning, though, the MediaTemple people apologetically said that they couldn't install an old version of PHP either; there was something damaged in the virtual server and it would have to be reset to factory (they also refunded the $79). So today, I reset the server to factory, successfully installed the old version of PHP, and got the site working again, all for a fixed job cost of $850. I don't consider myself a server administration, but when I do site administration for money, it's the most lucrative thing I do.
I should mention that installing an old version of PHP required that I download the source and compile it on the server. This is something I will avoid whenever possible (using such helpful Linux tools as yum or apt-get), but in this case nothing else would do the job. I don't really know in detail what happens when I install code from source. I just follow a basic formula which I've learned from Google searches: ./configure, make, and then finally make install. But in this case, the basic formula was not enough. I had to also install a c++ compiler (yum install gcc), a libxml development environment (yum libxml2-devel), and I had to pass a lot of parameters into ./configure. I'd do a compile, find something was broken on the website (first it was mysql, then it was mysqli, then it was soap, and then finally it was openssl), I'd add parameter, recompile, and try the site again. By the time I was done, the configuration command looked like this:
./configure --with-libdir=lib64 --with-mysql --with-mysql=/usr/bin/mysql_config --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd --prefix /usr/local/php5.3.27a --enable-soap --enable-libxml --with-openssl
For linking purposes this article's URL is:feedback
previous | next