Don’t worry … it’s really quit simple. If you can use FTP (File Transfer Protocol), you can handle this bit of server management. Depending on the exact problem, we might instruct you to free up space by removing files in one of the following directories:

• /var/log
• /usr/local/cpanel
• /usr/local/apache/logs
• /usr/local/apache/domlogs

The reason these directories are usually overlooked is because they are not accessible by normal FTP users — users who only upload website content. When you upload website content to the server via FTP, the FTP user is limited to the directory structure for that website. Directories starting with “/var” and “/usr” cannot be accessed by these non-root users (The “root” user can access anything). And while root is a powerful user, for the sake of security, it is not normally allowed to log in over FTP because FTP is not secure … That’s where SFTP (Secure File Transfer Protocol) comes in.

Most FTP clients support SFTP, so you don’t have to learn a new environment to securely access any file on the server. Every FTP client is different, but I’ll illustrate with FileZilla because it’s free and available on Mac, Windows and Linux. If you don’t already have an FTP client, I highly recommend FileZilla. Because there are a few ways to use FileZilla to get an SFTP connection, I can share different options for you to try:

Quick Connect

The Quick Connect bar is the quickest way to connect to your server. Start FileZilla and look immediately under the toolbar for the Quick Connect bar:

Enter the hostname (IP address or domain name), “root” in the Username field, the root password in the Password field, and “22″ in the port field. Remember, port 22 is for SFTP, the same as SSH. Click the Quickconnect button to connect.

Using the Site Manager

The Site Manager lets you save your login details. Start FileZilla and you’ll see the following:

To open the Site Manager, click the left-most icon in tool bar or go to File >> Site Manager in the menu.

Enter an IP address or domain name for your server in the Host field, and select “SFTP” as your protocol. You’ll enter the root user’s login information, and you’re ready to connect by clicking the “Connect” button or you can click the “OK” button to save and close the dialog box.

If you just saved your settings and the Site Manager is not open, click the Site Manager icon again. From there, you can select the site under the “Select Entry” box, and you just have to click “Connect” to initiate the SFTP connection with your saved settings.

If you see a pop-up that warns of an “Unknown host key,” clicking the “Always trust this host, add this key to the cache” option will prevent this interruption from showing in the future. Once you click “OK” to complete the connection, your FileZilla screen should look like this:

Notice the “Remote site” section on the middle right of the FileZilla screen:

This area in FileZilla is the directory and file listing of the server. Navigate the server’s file structure here, and click “/” to access the top of the folder structure. You should see the “/usr” and “/var” directories, and you can explore the filesystem to delete the files technical support recommended to create space!

Message Log

If you have a problem connecting to your server by FTP or SFTP, the open area below the Quickconnect bar is the Message Log. If you can copy and paste this text into a ticket, you’ll help technical support troubleshoot your connection problems. Below is an example log of a successful FTP session:

Status: Connecting to server.example.com...
Response:   fzSftp started
Command:    open "root@server.example.com" 22
Command:    Trust new Hostkey: Once
Command:    Pass: **********
Status: Connected to server.example.com
Status: Retrieving directory listing...
Command:    pwd
Response:   Current directory is: "/root"
Command:    ls
Status: Listing directory /root
Status: Calculating timezone offset of server...
Command:    mtime ".lesshst"
Response:   1326387703
Status: Timezone offsets: Server: -21600 seconds. Local: -21600 seconds. Difference: 0 seconds.
Status: Directory listing successful

And here’s an example of a failed connection:

Status: Resolving address of example.com
Status: Connecting to 192.0.43.10:21...
Error:  Connection timed out
Error:  Could not connect to server
Status: Waiting to retry...
Status: Resolving address of example.com
Status: Connecting to 192.0.43.10:21...
Error:  Connection attempt interrupted by user

If you have any questions, leave them in a comment below. Enjoy your new-found SFTP powers!

-Lyndell

Shortly before that scene was another scene and catchphrase that should resound with familiarity to system administrators around the world. In the face of marauding dinosaurs and computer sabotage, the character John Arnold, played by Samuel L. Jackson, must sacrifice what I’m sure was an absurd amount of uptime by killing the power and rebooting the mainframe. Would the system come back up? Would everything load up as needed to get the park’s systems back online? John’s mantra was simple: “Hold on to your butts!”

Every day as a Systems Administrator I’m faced with a comparable (though far less exhilarating) situation. Linux is an extremely stable operating system, and I have logged into systems that have been online for quite literally years. Eventually, though, kernel updates or stray mounts necessitate a reboot. Will the server’s filesystems need a check on reboot? Will the server even come back up? When a server’s been online for that long, the only way to know is to “throw the switch” and cross your fingers.

One way to have a better idea of how your system will behave during reboots in a production environment is to take the time to update your kernel once a month or so and perform a reboot to make sure the update sticks. This allows routine file system checks to take place as necessary and keeps your system abreast of the latest kernel updates. It also familiarizes you with how long the process takes, what sort of caveats you may run into, and reduces the overall surface area of your server to outside attackers.

In the last year, I have seen at least two exploits that can give an attacker root access to a server running an outdated kernel using common toolkits that can attack commonly deployed Content Management Systems with trivial effort. Compromising an unprivileged user account gives an attacker even more leverage against unpatched systems. Google CVE-2009-2695 and CVE-2010-3081 if you don’t believe me.

If you run a production system or even a backend system that is exposed to the big, bad Internet, it is absolutely essential to make sure that your kernel, software, and security measures are up to date. Today’s Slashdot article is tomorrow’s exploit.

What lesson can we learn from the unfortunate folks at Jurassic Park? Don’t assume your server is safe and don’t wait until there are velociraptors roaming your halls looking for a snack to perform proper maintenance on your system.

-Adam