So I wrote a short script to handle the situation. When initialized at boot time through init.d or rc.d, it’ll first attempt to mount the share, but then times out in two seconds (this is a LAN NFS share so if the system offering the share is up there should not be a longer delay than that) and so the boot sequence is not slowed down terribly. (see update below) Once boot is complete, the script is run via cron every five minutes. Depending on the criticality of the share you may want to make that time shorter or longer. In this case it is a backup share which is not critical for the system’s functioning.

This technique would handle circular mounts, too, but obviously you would run into trouble if the mounts are required for successful system boot.

For this to work successfully add a marker file, such as “.myremoteservertransfers” in my example script below, in the share folder on the system exporting the share. I usually set the undeletable attribute on the file to make sure it doesn’t get accidentally deleted.

Update: Even with this code the boot sequence appears to hang until portmap times out (which takes quite a while) if the NFS share is not available at boot time. I removed the rc.d mount attempt and just shortened the cron poll period to 1 minute. That way the share will be up very quickly once it becomes available, yet the overhead caused by the periodic ping is minimal (both servers are on local LAN).

#!/bin/sh
 
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin
 
# remote system name
remotesystem=myremoteserver
 
# remote share name
remoteshare=/nfsexports/backupshare
 
# local mount point
mountpoint=/localbackups/TRANSFERS/${myremoteserver}
 
# file to indicate local mount status
testfile=$mountpoint/.myremoteservertransfers
 
# --- end variables ---
 
# ping result to the remote system (2 sec timeout); not empty is OK
remoteping=`ping -c1 -o -q -t2 ${remotesystem} | grep " 0.0%"`
 
if [ "${remoteping}" != "" ] ; then
 
   # server is available so query availability of the remote share; not empty is OK
   offsiteshare=`showmount -e ${remotesystem} | grep "${remoteshare}"`
 
   if [ "${offsiteshare}" != "" ] ; then
      if [ ! -e ${testfile} ] ; then
         mount -r -t nfs ${remotesystem}:${remoteshare} ${mountpoint}
      fi
   fi
fi
 
exit 0

However, outsourced email is not without its pitfalls, too. Even with a reasonably fast network connection there is more noticeable latency when accessing a remote email server as opposed to a LAN-based solution. Then there is the issue of outsourced service quality vs. the cost. Some services like Fusemail or Rackspace offer reasonable quality and fairly customizable features. But when something does go wrong you’re dependent on their response time. You’ve essentially handed away control of your email reception, for better or for worse.

Mostly, however, reception uptime is good with most well-run outsourced mail services, and the issues that more commonly crop up are related to latency and in some cases (like with Fusemail from time to time) apparent capacity issues. And if you access Fusemail with Outlook 2010′s IMAP client, you may have noticed frequent spontaneously changing message ID’s which repeatedly pop up a notification on Outlook.

The client-side issues are easy to remedy by caching inbound email on your local server. It gives you the best of both worlds: quick access to email and safety of someone monitoring mail reception 24/7 with multiple redundancies. If your local caching mail server goes down even for an extended amount of time, all you need to do is to repoint your clients to the external provider’s IMAP or POP server and you’re back in business. You may also opt to use your own outbound SMTP service (assuming you have a static IP in use) which makes it possible to isolate your domains’ SPF records to the IPs you own (as opposed to allowing anyone with an account, for example, at Fusemail to spoof mail from your domains without an SPF penalty). And if you use Fusemail, your own SMTP server will give you a peace of mind so that your outbound emails won’t trigger suspension of your account like happened to me soon after I first signed up with them (see Fusemail auto-suspends spam-suspect accounts!). Perhaps they’ve fixed that issue since then.

Setting up a caching mail service on your LAN is fairly easy with Postfix. The following tutorial assumes you already have a functioning Postfix/Dovecot setup where you’re able to send and receive email based on your requirements.

To start with, configure and test local users that you would like to correspond to outsourced email service’s mailboxes. They do not need to have the same login name, and you can also consolidate multiple external accounts to one local account. In smaller setups it’s the easiest to simply create a flat-file for user Dovecot passwords lookups.

Assuming you like to receive all email through an outsourced service (which, if you use an outsourced service, is the preferred option), you will want to restrict mail reception from the outside world only to the sending mail servers of the external mail provider of your choice. To accomplish this some restrictions are added to the local cache server’s main.cf file. The following is the configuration I use; I’ve carefully given thought of the restrictions not being too constrictive as to unnecessarily prevent connections, but on the other hand cut off connections that would not result in a successful or desired mail transit.

smtpd_helo_restrictions =
        permit_mynetworks
        reject_invalid_helo_hostname
        permit_sasl_authenticated
        reject_non_fqdn_helo_hostname
 
smtpd_client_restrictions =
        permit_mynetworks
        permit_sasl_authenticated
        check_client_access hash:$config_directory/tables/smtpd_client_access
        check_client_access cidr:$config_directory/tables/smtpd_client_access.cidr
        reject
 
smtpd_etrn_restrictions =
        permit_mynetworks
        reject
 
smtpd_sender_restrictions =
        reject_non_fqdn_sender
        reject_unknown_sender_domain
 
smtpd_recipient_restrictions =
        reject_non_fqdn_recipient
        reject_unknown_recipient_domain
        permit_mynetworks
        reject_unlisted_recipient
        permit_sasl_authenticated
        check_recipient_access hash:$config_directory/tables/smtpd_recipient_access
        #the following also permits mynetworks!
        check_recipient_access pcre:$config_directory/tables/smtpd_recipient_access.pcre
        reject_unauth_destination
 
smtpd_data_restrictions =
        reject_multi_recipient_bounce
        reject_unauth_pipelining

You will notice external hash and PCRE lookup tables “smtpd_client_access”, “smtpd_client_access.cidr”, “smtpd_recipient_access”, and “smtpd_recipient_access.pcre”. Let’s look at them next.

smtpd_client_access (hash) and smtpd_client_access.cidr (example below) list the external IP addresses you allow to connect and hence relay mail to your cache server. If the external IPs are not on this list, the connection is terminated.

Here’s an example smtpd_client_access (hash, so it’s converted to smtpd_client_access.db with postmap):

# some individual external server I want to allow to connect
100.200.100.200 PERMIT

And here’s an example smtpd_client_access.cidr:

1.2.3.4/24      OK
10.20.30.40      OK
100.200.201.0/21      OK

While the sending servers of an outsourced service don’t change often, they may change at any time without a warning. Thus maintaining the above list manually would be a frustrating task. To automate the process, you can cull this information from the outsourced mail service’s SPF records with a cron-scheduled shell script (note that paths relate to FreeBSD; if you run Linux, adjust them to the taste/requirements):

#!/bin/sh
 
ORIGINAL=/usr/local/etc/postfix/tables/smtpd_client_access.cidr
NEW=/tmp/postfix_clients.tmp
 
dig +short fusemail.net TXT | grep 'v=spf1' | egrep -o 'ip4:[0-9./]+' | sed 's/^ip4://' | sed 's/$/      OK/' > $NEW
 
ORIGINAL_CK=`cksum $ORIGINAL | awk '{print $1}'`
NEW_CK=`cksum $NEW | awk '{print $1}'`
 
if [ -s $NEW ] ; then
  if [ $ORIGINAL_CK != $NEW_CK ] ; then
    cp -f $NEW $ORIGINAL
    postfix reload > /dev/null 2>&1
  fi
fi
 
rm $NEW
 
exit 0

The above example is obviously for Fusemail, but you can modify it for other providers simply by replacing the provider domain name on the dig line.

In my configuration smtpd_recipient_access (hash) lists simply the nullroute that is often required – such as in php.ini mail configuration where you might put:

sendmail_path = /usr/sbin/sendmail -t -i -f nullroute@mydomain.com

So in smtpd_recipient_access (hash) I list:

nullroute@mydomain.com  PERMIT

Meanwhile, smtpd_recipient_access.pcre lists the users who’re allowed to receive mail externally, from the IPs you defined with smtpd_client_access/smtpd_client_access.pcre:

if !/^(nullroute|abuse|postmaster|user1|user2|user3)@mydomain\.com$/
/^/ internal
endif

Again, the above is sufficient for small configurations, but if you have dozens or more users whose external email you’re caching you may be better off storing the client_access table on a database server.

Finally, as you notice the ‘internal’ keyword being added above to user addresses that are not matched by smtpd_client_access.pcre, you want to add the following in main.cf:

smtpd_restriction_classes = internal, public
internal = permit_mynetworks, reject
public = permit

With these in place you will now receive email only from your external mail provider (and perhaps some other authorized servers if you defined one with smtpd_client_access hash table). This is important because you’re likely using your outsourced mail provider’s spam filtering, and you don’t want spammers contacting your cache mail server directly.

With the local server configured (and hopefully sufficiently tested ) you can then go ahead and create mail forwarding rules at the external provider of your choice. You would simply copy any arrived email to the corresponding email address at your local cache server. I have additionally created a rule at the external provider which prunes the mailbox after given number of time since the users will not go through and delete read email there.

You may want to allow authenticated client access to your local users so that they can access their email via IMAP or POP remotely, and perhaps over the web (like via locally installed Squirrelmail). It is also a consideration that the email at the external provider will not be synced back – if users delete email from their locally cached mailbox it will not be deleted from the mailbox at the external provider, so under normal circumstances your cached email server should be the only access point for mail. But in an event of the server melt-down it is a minor inconvenience that the external provider’s mailbox would have older emails (that perhaps were deleted locally) in it – at least the users can continue to access email while you’re getting the caching server back online!

** NOTE: I’m using the current GA/Stable version of Postfix (2.7.0). If you’re using an older version, double-check that the configuration options I propose above are available before using them! This is one reason for why I prefer to use FreeBSD for mail; the ports version of Postfix is kept well up-to-date while CentOS/RHEL Postfix package is — as you would expect from an Enterprise Linux — currently at 2.3.3. You could compile it yourself, I suppose, but I’m not up to the task since I’m not a full-time Postfix admin.

First (the reason for the reinstall), if there is plenty of hard drive space available, it’s good idea not to deplete it all for the sytem installations. I split a 1.3Tb RAID 5 array between the two operating systems until I realized that 1) you can’t shrink vmfs partitions and 2) by consuming all hard drive space one limits the flexibility of the system down the line. Let’s say you want to install a newer version of an operating system and decide to do a fresh install. You need space for it while you want to keep the old version around at least long enough to migrate settings and data over.

Second, while I was aware of that ESXi doesn’t offer console access beyond the “yellow and grey” terminal, I didn’t realize you have no access to the VM consoles, either. So, with CentOS or FreeBSD installed, the only way to access their consoles is via the vSphere client (someone correct me if I’m wrong — I wish I were as I’d like to have local console access to the guest OS’es).

Finally, VMware Go “doesn’t currently support ESXi servers with multiple datastores”. So if you have, say, a 3ware/LSI/AMCC RAID controller which isn’t currently supported under ESXi as a boot device but which you likely still want to use as a datastore, you’ll end up with at least two datastores. So vSphere is really the only way to go for VM management also for this reason (since LSI provides a vmware-specific driver, one may also be able to direct-connect the LSI RAID array to the VM without it being an ESXi datastore, but that’s not the configuration I’m looking for—the boot device is small and houses just ESXi while the VMs and their associated datastores are located on the array).

In the end everything’s working quite well. I like the flexibility virtualization offers.. and consolidation is useful even in a small environment (one dev machine is less than two or three dev machines ).

To enable P2012′s automatic duplexing on Windows 7 go to Devices and Printers, highlight the P2015, right click, and select Printer Properties from the context popup menu. Go to Device Settings tab and look for “Duplex Unit (for 2-Sided Printing)” option. It’s set to “Not Installed” by default. Change it to “Installed” and click on “OK”. Now when you go to Preferences when getting ready to print, the automatic (not “manually”) option is available on the Finishing tab, and automatic duplexing works.

Also if you use the excellent priPrinter utility, P2015 honors the “Double Sided” toggle on the Page Layout tab. Same goes for the “Double-sided” checkbox on FinePrint utility, and other applications that provide the option to turn automatic duplexing on or off.

After some more Googling later I happened on this page that outlines a simple way to add “flatten” options to the Acrobat document menu. The associated script to be placed in “Program Files/Adobe/Acrobat 9.0/Acrobat/Javascripts/” folder (the script works with older Acrobat versions, too, as the mentioned instructions are for Acrobat 7.0) is just two lines long:

app.addMenuItem({ cName: "Flatten page", cParent: "Document", cExec: "flattenPages(this.pageNum)",cEnable: 1, nPos: 16});
app.addMenuItem({ cName: "Flatten document", cParent: "Document", cExec: "flattenPages()",cEnable: 1, nPos: 17});

If $b is true, print “true”, otherwise print “false”. Echo doesn’t work here.

$b ? print "true" : print "false";

Here’s something I learned today: it’s possible to assign a complex variable to an “internal” shorthand, and then in turn use the shorthand for the final assignment (based on the comparison). This way it’s not necessary to repeat the complex variable in the assignment section which makes the ternary much shorter and thus cleaner.

So instead of this:

$a = ($myObject->anotherObject->arr['somekey'] > 7 ? 7 : $myObject->anotherObject->arr['somekey']);

You can do this:

$a = (($b = $myObject->arr['somekey']) > 7 ? 7 : $b);

Awesome!!

The replacement – a reconditioned unit – arrived yesterday. First thing I noticed that the “WARRANTY VOID IF BROKEN OR REMOVED” sticker was, well, broken. Hm. So today I went ahead and installed it back into the original system, taking out the temporary PSU. I really hate replacing power supplies when the case is even slightly congested and this one was pretty tough to get to. Finally, the replacement PSU was in place and I hit the power button. Nothing!

Few moments of testing later I had determined that the unit OCZ sent as a replacement was DOA. I had to rip it out and put the temp PSU back in. Note to self: from now on the PSU replacement protocol will include stand-alone testing the new unit before I touch the target system.

I very much doubt the unit broke in transit; I’m guessing they either didn’t test it after repairs were completed, or for some reason the unit was never serviced and so I got someone else’s failed PSU in exchange to PSU I sent in for warranty service. The only way OCZ can salvage the situation at this point and avoid getting on my bad list is if they offer to pay shipping both ways. It’s not that much money, but the time wasted on this far exceeded what the replacement is worth.

Many companies forget that the value of warranty they offer not only comes from what they can advertise but also from the PR – positive or negative – depending how they handle warranty.

UPDATE 21 January 2010: Five Star Damage Control

OCZ handled the situation about the only way they could’ve handled it to minimize the negative impression that had already been created: they offered a free upgrade to a new product, or a pre-paid shipping label to return the DOA unit to service/exchange (apparently in case I had to keep the same model, such as a component for a tightly specified system). I chose the upgrade. Let’s hope the new unit works!

UPDATE 22 January 2010: Not so fast, my friend

More to come. Dealing with OCZ tech support turned out to be less than what the first impression promised.

Simply add the following to $(document).ready(function() { … } on the page you have reCAPTCHA on:

$(document).ready(function() {
   $("#recaptcha_reload_btn, #recaptcha_switch_audio_btn, #recaptcha_whatsthis_btn").attr("tabindex", -1);
}); 

From time to time – usually when I’ve been getting ready to upgrade to the next major revision of FreeBSD – I’ve taken some time to research what the current pros and cons are for FreeBSD vs. some Linux distro. Always, in the end, FreeBSD has won. However, a development project I’m starting to work on will utilize Zend Server, which is only supported on handful of common Linux distros and on Windows (which is, by default, not an option as I strongly maintain that Windows is not suitable as a web server platform). There is, of course, Linux compatibility layer in FreeBSD, but as Zend doesn’t currently support it as a platform for Zend Server, I wouldn’t feel comfortable using it in a production environment.

So even though I find FreeBSD superior to Linux in many ways, I’ve now spent some time getting acquainted with Linux. I first started with Red Hat, then moved to CentOS which is the Linux distribution I’m currently testing. Now it’s not bad, per se, but I frequently come back to the thought: “Why would someone, anyone prefer THIS over a BSD system?!” The package management with yum, rpm, and the GUI overlays is easy enough, but it’s chaotic! Having to enable and disable repos, set their priorities, etc. seems unnecessarily complicated. On the FreeBSD side there is the ports collection which provides most of the software that one can imagine ever needing. The odd few items that either aren’t available in ports, or whose configuration is somehow not complete enough through ports can be easily compiled from the source tarball. Everything’s quite easy to keep track of, and to duplicate if one’s building a new system.

I’m sure some of this feeling stems from the fact that I have been using a BSD system for so long, and from the fact that I probably don’t yet know Linux well enough (say, to build the system from a scratch..). But as far as I can tell, package management is done with yum and rpm (on CentOS, say), by adjusting repository priorities, and enabling/disabling repositories. That is messy!

Well, I now have a functional development server running Zend Server with Apache, Subversion, and MySQL, and as the vendor (Zend) dictates the rules, I must continue development on Linux. Perhaps in six months time I’ll have more favorable comments about it as compared to FreeBSD… but I sort of doubt it. My guess is I’ll just learn to live with it, every now and then wistfully glancing to the direction of the BSD server.

For reference, if you’re planning to use a Windows system with a KVM switch, make sure its BIOS has the following options:

• HALT ON ERROR: All but keyboard (usually in Standard CMOS settings)
• PnP OS: yes (usually in PnP/PCI settings)
• USB IRQ: enabled (usually in PnP/PCI settings)

Without these options set the only way to find out whether a specific motherboard will or will not work with a USB KVM switch, is to try. Gigabyte GA-EP45T-UD3LR does not.