Disabling Quotas on a ReadyNAS Ultra NAS

If you have a ReadyNAS Ultra you may want to disable quotas in order to eliminate some issues.  I’ve experienced issues myself where CIFS copies would fail due to the filesystem being out of space even though quotas are set insanely high and the ReadyNAS interface is reporting plenty of space left on the device.  Often there are no needs for the quotas and the easiest thing is to simply remove them altogether.

Removing quotas in ReadyNAS (RAIDiator) is actually pretty easy but you have to know where to go and be confident that you are not going to break anything.  The filesystem data is kept in the /etc/fstab file.  The /c mount is the one about which we are concerned.  This is the mount that is used for our NAS shares.  In /etc/fstab it should look like this:

/dev/c/c  /c   ext4  defaults,acl,user_xattr,usrjquota=aquota.user,
grpjquota=aquota.group,jqfmt=vfsv1,noatime,nodiratime 0 2

All we need to do is to edit that line to remove the three arguments that refer to the quote.  For safety, make a copy of the original line before making any edits so that you can easily put it back exactly as it was.  The modified line will look like this:

/dev/c/c  /c   ext4  defaults,acl,user_xattr,noatime,nodiratime 0 2

Simply reboot and, if all is well, you will no longer have to put up with quotas and previously failing file copies will now work smoothly.

PHP Fatal error: Call to undefined function posix_getpwuid()

I found that this error appears rather often online but almost no one has any idea why it would come up.  I found this error myself today while doing an install of FreePBX on Fedora 14.  My full error was:

Checking user..PHP Fatal error:  Call to undefined function posix_getpwuid() in /usr/src/freepbx-2.8.1/install_amp on line 728

This seems like it must be a permissions error.  But more than likely you are simply missing the PHP Posix library.  You can resolve this on Fedora with

yum -y install php-posix

Ta da!

Latency and Software Developers

I was recently having a conversation where someone asked me to compare real time and low latency Linux kernels.  I used the phrase “real time is the enemy of low latency.”  This caught some attention and I was asked to explain what I meant.  In order to accommodate the needs of real time processing we need to add a certain amount of overhead so that we can accurately and reliably predicate the amount of time that a procedure will take to complete.  In order to do this we incur a certain amount of overhead and this overhead contributes to latency.  In order to move as quickly as possible we would have to remove this overhead and thereby decrease latency but without having the predictability for which the overhead had allowed.

Today I was reading a paper on Agile development and traditional software development methodologies and it occurred to me that we were essentially talking about the same concept.  Programmers are a lot like organic, squishy CPUs chugging along churning out data.  The concept behind traditional development methodologies (or schedulers, if you will) was to make sure that developers were able to turn out a project or a piece of a project in a predictable nature – so predictable that projects could be projected years in advance with meeting rooms scheduled and the caterers hired for the release party.  This predictability is provided by the inclusion of a large amount of management overhead that hinders rapid development.  All of those status meetings don’t come for free and incur large amounts of lost productivity in exchange for keeping management up to date as to the release schedule.

Agile development takes the opposite approach.  In Agile the idea is not predictability, at least not to the same extreme level.  Agile really focuses on producing software with minimal latency – getting it done and out the door as quickly as possible even if that ends up surprising the marketing and sales departments and no box art has been approved yet.  It does this by lowering the management overhead and reducing artifacts that interfere with the actual job of producing a product allowing the team to move more quickly.

Testing Socket Connections Programmatically

Often we have to use “telnet remotehost.somewhere.com 80” to test if a remote socket connection can be established.  This is fine for one time tests but can be a problem when it comes time to test a number of connections – especially if we want to test them programmatically from a script.  Perl to the rescue:

use IO::Socket;

my $sock = new IO::Socket::INET (
                   PeerAddr => $ARGV[0],
                   PeerPort => $ARGV[1],
                   Proto => tcp,

if ($sock) { print "Success!\n" } else { print "Failure!\n" };

Just copy this code into a file called “sockettest.pl” and “chmod 755 sockettest.pl” so that it is executable and you are ready to go.  (This presumes that you are using UNIX.  As the script is Perl, it should work anywhere.)
To use the code to test, for example, a website on port 80 or an SSH connection on port 22 just try these:

./sockettest.pl www.yahoo.com 80
./sockettest.pl myserver 22

You aren’t limited to known services.  You can test any socket that you want.  Very handy.  Now, if you have a bunch of servers, you could test them from a simple, one line BASH command like so (broken so as not to be one line here for ease of reading…)

for i in myserver1 myserver2 yourserver1 yourserver2 someoneelsesserver1
  echo $i $(./sockettest.pl "$i" 80)

Windows Server 2008 R2 on Xen

Having poked around in the forums I have found that no one seems to believe, at least not at the time of this writing, that Windows Server 2008 R2 can be deployed on Xen or, if it can, that you cannot do so using the Xen package available in Red Hat Linux 5.  I am proud to announce that Windows Server 2008 R2 does indeed run just fine on RHEL 5.4.  I believe that the update to the latest 5.4 package is likely required here and, as Server 2008 R2 is 64bit only, you have no choice but to be running on x64 hardware.  But work it does and 2K8 R2 on Xen on Red Hat Linux is very much a reality.