UNIX Utilities: Echo

This is the first post of what I hope to be many describing UNIX command line utilities, first up is the "echo" command:

/**
 * A copy of the "echo" command on UNIX, missing a few options, but it
 * does what is normally asked of it.
 * 
 * Copyright 2011-12-23 Joseph Lewis <joehms22 gmail com>
 */
#include <iostream>

using namespace std;

int main(int nargs, char* vargs[])
{
 for(int i = 0; i < nargs - 1; i++)
 {
  if(i != 0)
   cout << " ";
  cout << vargs[i + 1];
 }
 cout << "\n";
}

Speed up SSH and FTP logins

Scenario: You're working in the office, and a foot of snow comes down out side, killing your Internet connection, all of a sudden, your FTP server on the local network starts timing out, and SSHing in to the server is unbearably slow to get to the password prompt.

What happened is that FTP and SSH services do a reverse DNS query to ensure that hosts actually are who they say they are, when your connection went out, they were no longer able to do this, but keep trying anyway, slowing things down to the point of frustration or timeout.

The fix is simple, but makes your connections a little less secure, as this check won't be performed on all connections, not a big deal if your boxes only face internal networks.

First, (assuming you're using openssh) fix SSH:

echo "UseDNS no" >> /etc/ssh/sshd_config

Next (assuming your're using pure-ftpd) fix FTP:

echo 'yes' > /etc/pure-ftpd/conf/DontResolve

Restart both services through /etc/init.d or upstart and you're set!

Watching A Directory For Changes

This is a very simple VALA script that watches a directory for changes (not including sub-directories) then prints out the changed files.

Usage: changewatch /path/to/folder/to/watch

/**
 * Watches a directory for changes:
 * 
 * compile: valac changeWatch.vala --pkg gio-2.0
 * Copyright 2011-12-09 Joseph Lewis
 * Apache License
 */

using GLib;

void on_change (File f) {
    print(f.get_path() + "\n");
}

void main (string[] argv) {
    
    if(argv[1] == null)
    {
        print("Usage: "+argv[0]+" /path/to/file/to/watch\n");
        return;
    }
    
    GLib.File fp = File.new_for_path(argv[1]);
 
    GLib.FileMonitor mon1;
 
    try {
        mon1 = fp.monitor_directory(
            GLib.FileMonitorFlags.NONE
        );
        mon1.changed.connect(on_change);
        print("Monitoring: "+fp.get_path()+"\n");
    } catch (GLib.Error e) {
        print("Error: "+e.message+"\n");
    }
    GLib.MainLoop loop = new GLib.MainLoop();
    loop.run();
}

Choosing Your Next Webserver

Being an occasional web developer, I like to be able to debug on my local machine. My old friend Apache just wasn't doing it anymore however, because it made my computer boot incredibly slow, I didn't need the power, and the configuration was giving me a headache.

I went in to Synaptic Package Manager and pulled out three others (nginx which I had heard good things about, Cherokee which seemed to have a bunch of packages, and nanoweb a PHP based server that I had never heard of).

Apache
I used gnome-system-monitor for profiling each of the programs as they were running, Apache had 3 threads/child processes running at 7Mb and 4 at 5Mb. That, along with a hefty and often confusing configuration is why I dropped it.

The amount of RAM to beat then was 41 Mb.


Nginx (Engine X)
I first tried a server that I had been dying to give a go for quite some time, Nginx, it runs popular sites such as http://dearblankpleaseblank.com and according to its online site excels at serving static pages.

The configuration didn't really seem like anything I had dealt with before, it was kind of like JSON, kind of like INI and took quite a bit to understand, the online manual wasn't much help and the examples in the file were minimal.

I wasn't able to get PHP running with it even after following a few tutorials. I'm sure you can, but I decided to move on.

The rest of the directory structure was kind of like Apache, with the same sites_available folders and such. However the default site was in /usr/ somewhere rather than /var/www, bizarre.

While it was running it had 5 threads/child processes running at about 2Mb a piece, 10Mb, not bad.


nanoweb
Next up I installed "nanoweb" a simple webserver written in PHP5. After rebooting I found that the default page provided some help on getting things configured, and there was some kind of configuration library that was available as a secondary package, although this would have also been available outside of localhost, and therefore exposed your server to threats.

I took a look at the configuration files and found three, much nicer than Apache. One seemed to be for CGI, I didn't have a reason to look at that, but I was able to see it had support for vhosts (in a very simple ini style file, it looked like each vhost would have taken something like five lines to set up).

I configured my site through the main file replacing all of the default "It Works" style site's values with mine. A reboot worked flawlessly and I was able to start working on my site right away. The file had lots of documentation and tips for configuration.

Using my profiling tool I saw that nanoweb used 3 threds/subprocesses with an average of 7Mb overhead each, undoubtedly due to PHP being a scripted language. 21Mb, not as good as nginx, but not as bad as Apache.

Cherokee
I didn't want to give up the nice nanoweb configuration I had, but I had read some things about it and I wanted to try it.

The install went really fast, unlike nanoweb that took about 20Mb of packages Cherokee must have taken more like four. Probably due to it's base requirements being no more than the C standard library.

I found that to configure you had to run a utility called "cherokee-admin" once run it gives you a username, temporary password, and opens a server on port 9090 until you close the admin interface.

Once logged in the GUI is amazingly nice, giving a nice profile of your machine, easy access to all virtual hosts, and wizards to set up most things. Enabling PHP on my site took four clicks, and it seems that most things are configured for security. Even applying the changes was nearly instantaneous as the web-server can do a restart from the interface.

While running the whole thing has two threads of 2Mb each, 4Mb.