But if you do decide to write an application which takes a password (or any other sensitive information) on the command line, you can prevent other users on the system from easily seeing it like this:

#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>

int i = 0;
pid_t mypid = getpid();
if (argc == 1)
return 1;
printf("argc = %d and arguments are:\n", argc);
for (i ; i < argc ; i++)
printf("%d = %s\n" ,i, argv[i]);
printf("Replacing first argument with x:es... Now open another terminal and run: ps p %d\n", (int)mypid);
fflush(stdout);
memset(argv[1], 'x', strlen(argv[1]));
getc(stdin);
return 0;
}

A sample run looks like this:
$ ./pwhide abcd
argc = 2 and arguments are:
0 = ./pwhide
1 = abcd
Replacing first argument with x:es... Now run: ps p 27913

<In another terminal>
$ ps p 27913
PID TTY STAT TIME COMMAND
27913 pts/1 S+ 0:00 ./pwhide xxxx


In the interest of brevity, the above code isn't very portable - but it works on Linux and hopefully the point of it comes across. In other environments, such as FreeBSD, you have the setproctitle() syscall to do the dirty work for you. The key thing here is the overwriting of argv[1]
Because the size of argv[] is allocated when the program starts, you can't easily obfuscate the length of the password. I say easily - because of course there is a way.

It turns out that the grass actually IS greener. Tonight I stumbled upon this. It’s a patched version of freetype. For what I assume are political reasons (free as in speech), Fedora ships a Freetype version without subpixel rendering. These patches fixes that and other things.

With a default configuration file of 407 lines, it’s quite extensible and configurable as well. Lucky, I quite like the default!

If you’re not entirely happy with the way your fonts look on Fedora – it’s well worth a look

The only somewhat useful example of using Cassandra with C++ one can find online is this, but due to the API changes, this is now outdated (it’s still worth a read).

So in the hope that nobody else will have to spend the better part of a day piecing things together to achieve even the most basic thing, here’s an example which works with Cassandra 0.7 and Thrift 0.6.

First of all, create a new keyspace and a column family, using cassandra-cli:

[default@unknown] create keyspace nm_example;
c647b2c0-83e2-11e0-9eb2-e700f669bcfc
Waiting for schema agreement...
... schemas agree across the cluster
[default@unknown] use nm_example;
Authenticated to keyspace: nm_example
[default@nm_example] create column family nm_cfamily with comparator=BytesType and default_validation_class=BytesType;
30466721-83e3-11e0-9eb2-e700f669bcfc
Waiting for schema agreement...
... schemas agree across the cluster
[default@nm_example]


Now go to the directory where you have cassandra installed and enter the interface/directory and run: thrift –gen cpp cassandra.thrift
This will create the gen-cpp/ directory. From this directory, you need to copy all files bar the Cassandra_server.skeleton.cpp one to wherever you intend to keep your sources.
Here’s some example code which inserts, retrieves, updates, retrieves and deletes keys:

#include "Cassandra.h"

return 0;
}

Say we've called the file cassandra_example.cpp, and you have the files mentioned above in the same directory, you can comile things like this:

$ g++ -lthrift -Wall cassandra_example.cpp cassandra_constants.cpp Cassandra.cpp cassandra_types.cpp -o cassandra_example
$ ./cassandra_example
Set keyspace to 'nm_example'..
Insert key 'your_key' in column 'column_name' in column family 'nm_cfamily' with timestamp 1306008338...
Retrieve key 'your_key' from column 'column_name' in column family 'nm_cfamily' again...
Value read is 'Data for our key to go into column_name'...
Update key 'your_key' in column with timestamp 1306008339...
Retrieve updated key 'your_key' from column 'column_name' in column family 'nm_cfamily' again...
Updated value is: 'Updated data going into column_name'
Remove the key 'your_key' we just retrieved. Value 'Updated data going into column_name' timestamp 1306008339 ...

As my WP template isn't very suitable for code, I've put up the cpp file here for download
Another thing worth mentioning is Padraig O'Sullivan's libcassandra, which may or may not be worth a look depending on what you want to do and what versions of Thrift and Cassandra you're tied to.

So here’s a small tip; ensure that your developers know what they are doing! It will save you a lot of hassle and money in the long run.

Without having made a science out of it, I can confidently say that at the very least 95% of the downtime I see on a daily basis is due to faulty code in the applications running on our servers.

So after you’ve demanded dual power feeds to your rack, bonded NICs and a gazillion physical paths to your dual controller SAN, it would make sense to apply the same attitude towards your developers. After all, they are carbon based humans and are far more likely to break than your silicon NIC. Now unfortunately it is not as simple as “if I pay someone a lot of money and let them do their thing, I will get good solid code out of it”, so a great deal of due diligence is required in this part of your environment as well. I have seen more plain stupid things coming from 50k pa. people than I care to mention, and I have seen plain brilliant things coming out of college kids’ basements.

This is important not only from an availability point of view, it’s also about running cost. The amount of hardware in our data centers which is completely redundant, and would easily be made obsolete with a bit of code and database tweaking is frightening. So you think you may have cut a great deal when someone said they could build your e-commerce system in 3 months for 10k less than other people have quoted you. But in actual fact, all you have done is got someone to effectively re-brand a bloated, way too generic, stock framework/product which the developer has very little insight into and control over. Yes, it works if you “click here, there and then that button”, the right thing does appear on the screen. But only after executing hundreds of SQL queries, looking for your session in three different places, done four HTTP redirects, read five config files and included 45 other source files. Needless to say, those one-off 10k you think you have saved, will be swallowed in recurring hardware cost in no time. You have probably also severely limited your ability to scale things up in the future.

So in summary, don’t cheap out on your development but at the same time don’t think that throwing money at people will make them write good code. Ask someone else to look things over every now and then, even if it will cost you a little bit. Use the budget you were planning on spending on the SEO consultant. Let it take time.

So all of you who emailed me positive feedback and asked to make it a tuneable in the translator config (thanks!) – please check out  the above link to the git repository.

On another note, it seems as if they’re breaking away from having the protocol version bound to the release version, good progress in my opinion!

I’ve got four machines set up, two acting as redundant servers. Since they’re effectively acting as a RAID 1, each write is done twice over the wire, but that’s kind of inevitable. They’re all connected in a private isolated gigabit network. When dealing with larger files (a la `cp yourfavouritedistro.iso /mnt/gluster`) the throughput is really good at around 20-25 MB/s leaving the client. CPU usage on the client doing the copy was in the realms of 20-25% on a dual core. Very good so far! 

Then I tried many frequent filesystem operations, untarring the 2.6.9 linux kernel from and onto the mount.  Not so brilliant! It took 23-24 minutes from start to finish. The 2.6.9 kernel contain 17477 files and the average size is just a few kilobytes. This is obviously a lot of smaller bursts of network traffic!

After seeing this, I dove into the source code to have a look, when I reached the socket code, I realised that the performance for smaller files would probably be improved by a lot if Nagle’s algorithm was disabled on the socket. Said and done, I added a few setsockopt()s and went to test. The kernel tree now extracted in 1m 20s!

Of course there’s always the drawback.. In this case it is that larger files take longer to transfer as the raw throughput is decreasing (kernel buffer is a lot faster than a cat5!). Copying a 620 MB ISO from local disk onto the mount takes 1.20 s with the vanilla version of GlusterFS, and 3m 34s with Nagle’s algorithm disabled. 

I’m not seeing any performance hit on sustained transfer of larger files, but at the moment I’m guessing I’m hitting another bottleneck before that becomes a problem, as it “in theory” should have a slight negative impact in this case.

If you want to have a look at it, you can find the patch here. Just download to the source directory and do patch -p1 < glusterfs-2.0.1-patch-erik.diff  and then proceed to build as normal.

Until I’ve done some more testing on it and received some feedback, I won’t bother making it a tuneable in the vol-file just in case it’d be wasted effort!

So as of now, you can safely use one varnish instance for several front-ends, thus eliminate double-caching (memory waste, unnecessary load on back-ends), reduce network traffic, do rudimentary load balancing, ease management etc.
With the obscene amount of traffic Varnish can push without putting a fairly basic system under any load worth mentioning, you can use a single front-end to serve several nodes in most setups.

Here’s an elementary sample VCL for how to do this:

backend node0 {
  .host = "127.0.0.1";
  .port = "80";
  .probe = {
           .url = "/";
           .timeout = 50 ms;
           .interval = 1s;
           .window = 10;
           .threshold = 8;

  }
}

backend node1 {
  .host = "10.0.0.2";
  .port = "80";
  .probe = {
#           .url = "/";
           .timeout = 100 ms;
           .interval = 1s;
           .window = 10;
           .threshold = 8;
        .request =
            "GET /healthcheck.php HTTP/1.1"
            "Host: 10.0.0.2"
            "Connection: close"
            "Accept-Encoding: foo/bar" ;
  }
}
director cl1 random {
    { .backend = node0; .weight = 1; }
    { .backend = node1; .weight = 1; }
}

#director cl1 round-robin {
#   { .backend = node1; }
#   { .backend = node0; }
#}

sub vcl_recv {
        set req.backend = cl1;
}

As you can see I’m defining the backends slightly differently. You need to define one of .url or .request, but not both for obvious reasons. If you go for the slighly simpler .url the default request looks like this:

GET / HTTP/1.1
Host: something
Connection: close

If this does not suit your need, comment out .url and use .request to roll your own. This aspect of Varnish is actually quite well documented, so I won’t repeat what’s on the trac page.

There is clearly a lot more you can and, more often than not, should do in the VCL than the above. This is a stripped down version which only pertains to the backend polling functionality.

btrfs, like ZFS, implements copy-on-write model, so yes – it will be able to do snapshots! Writeable ones at that. In fact, it’s got the ability to do snapshots of snapshots! Quasi-MVC filesystem!
COW unfortunately makes a filesystem more prone to fragmentation, but luckily btrfs comes with online defragmentation and fs check abilities. The speed of read and write operations will obviously be impaired during such operations, but there’s always ways around that in most performance sensitive setups! If not, there should be!
Sadly, COW isn’t that good of a choice for database workloads. But fret not, COW can be disabled with a mount option (-o nodatacow). This doesn’t mean you will lose the snapshot ability, as btrfs ignores this option if a data extent is referenced by more than one snapshot, so COW will, as far as I understand, be enabled from that you initiate a snapshot and stay that way until you’re done with it.

Early benchmarks show that btrfs is extremely fast at writing, and a little poorer at reading. It will be interesting to see how these numbers change as development proceeds. If added features will have any negative impact on performance. As a side note – I was quite surprised to see the poor numbers for ext3 in these benchmarks!

So if you’re a DBA and your data fits in memory, this filesystem will be right up your alley. With a reasonable amount of tables and some proper values for innodb_open_files and table_cache, I wouldn’t expect any remarkable difference in day-to-day database operation since the real bottleneck usually is in the hardware.
This is generally speaking of course. I’m sure there are workloads out there which will benefit a lot more than “the norm”. Likewise, people with awkward read heavy setups with a lot of data in a lot of files may probably be better off not using btrfs.
If you, like myself, often use blinks of an eye as a unit, you know what I’m talking about.

Yet another interesting functionality built in is the multiple device support. I will not call it a substitute for proper hardware based RAID, but could well be one for LVM (bearing the snapshots in mind as well)!

Another thing worth keeping an eye on is a related project; CRFS which may turn out to be a worthy NFS replacement. While it’s planned to get failover capabilities, I would much rather have seen a client-agnostic MogileFS- style implementation.

Sadly, they are not production ready yet. By far. But it’s something to look forward to. I’ll give it a version or two until I will put it under the microscope further and chuck some real world load onto it. Can’t wait!

Here’s some example output from the inotifywatch utility during a mysqlslap run:

# inotifywatch  /var/lib/mysql/mysqlslap/*
Establishing watches...
Finished establishing watches, now collecting statistics.
total  access  modify  close_write  close_nowrite  open  delete_self  filename
728    450     274     1            0              1     1            /var/lib/mysql/mysqlslap/t1.MYD
241    0       238     1            0              0     1            /var/lib/mysql/mysqlslap/t1.MYI
5      1       0       0            1              1     1            /var/lib/mysql/mysqlslap/t1.frm
2      0       0       0            0              0     1            /var/lib/mysql/mysqlslap/db.opt
.

Granted – as far as MySQL is concerned – most information is accessible through SHOW GLOBAL STATUS and/or SHOW ENGINE INNODB STATUS commands. But if you for instance have an erratic fear of the key_read_requests variable, you could always look at how often your MYI files are accessed. You catch my drift..

If you’re only interested in certain file operations, you can apply filters. If you for instance only have interest in file writes, your run would look like this:

# inotifywatch -e modify -e delete_self /var/lib/mysql/mysqlslap/*
Establishing watches...
Finished establishing watches, now collecting statistics.
total  modify  delete_self  filename
49     47      1            /var/lib/mysql/mysqlslap/t1.MYI
44     42      1            /var/lib/mysql/mysqlslap/t1.MYD
2      0       1            /var/lib/mysql/mysqlslap/db.opt
2      0       1            /var/lib/mysql/mysqlslap/t1.frm
.

You can monitor pretty much any file operation, so this tool can be used in a whole range of scenarios. Ever wondered just how many temp files your application creates or? Are you sure it doesn’t open and close the file handle for each operation? Do you want to know which file on your website is the most popular download at the moment but can’t wait until the webstats crontab has ran? I could go on…

inotify-tools come with another utility inotifywait. This tool looks for activity on a specified file or directory and instantly tells you which operation was performed. Nothing amazing, but I can see a few areas of use for that as well, though most of them have tools for that purpose already.