Cron scheduling for first Sunday of the month

For everyone who uses cron, you are familiar with the job schedule form:

min hr day-of-month month day-of-week <command>

A problem with cron job scheduling is if you want to schedule something, like backups or updates, for "the first Sunday of the month".  The job spec "0 0 1-7 * Sun" will run every Sunday and every day on the 1st to the 7th of the month.

The way to work around this is schedule the job for the possible days to run and then as part of the command, check the date before running the command.  I've just seen what is The Best format for this:

0 9 1-7 * * [ "$(date '+%a')" == "Sun" ] && <path>/script.sh

This solution comes from LinuxQuestions.org user kakapo in the post here:

http://www.linuxquestions.org/questions/linux-software-2/scheduling-a-cron-job-to-run-on-the-first-sunday-of-the-month-524720/#post4533619

Up until now I used a slightly different form of this using the day of the week in the cron job and then testing  date %d to test the day of the month.  But the above form is far clearer and easier to schedule jobs with.

So props to kakapo for sharing that form and until cron changes how the day-of-the-month and the day-of-the-week fields are used, this will be the best way to schedule a job on the first Sunday of the month.

Nagios and SensorProbe

Nagios rules all and has great agents and plugins and also checks clusters.  One of the things we have got recently at #dayjob is a generator for emergency power.  Well, how do you know if the generator is running, is healthy, etc?  Sure, there's routine checks that someone has to do, weekly, monthly, seasonally, etc but how do you know what's going on in real-time?

Like much machinery, generators don't always have a nice web-based monitoring system or even an SNMP interface - they have "dry contacts".  Dry contacts, for those of you like me who think a voltmeter is something used by parking enforcement, is a simple electrical circuit which is either "open" and not passing current or "closed" and passing usually 5 volts.  Usually it is something like a screw which you thread a sensor through.

Okay, so no IP interface.  What do you use?  Well, we're using these AKCP SensorProbe devices which come in a variety of shapes and sizes.  For our generator we used the SensorProbe2DC to which you can connect two sensors supporting 5 dry contacts each.  It's a little IP device you need to feed a data run and power to and then you screw in the leads from the sensor to the dry contacts on the generator - your installer can help with the latter.

The SensorProbe is a monitoring device so you can configure the alerts and view status from there.  But the other thing is that it has an SNMP interface so you can now monitor your generator status from your regular network monitoring system, by which I mean of course Nagios.  Good old check_snmp, tell it which OID is which, and you're off to the races!

So now we've got in Nagios a host (the sensorpobe) which has service checks telling us whether the transfer switch is on mains or generator power, if the generator is running, if the generator is set to "auto start", or having any other problems.  

AKCP makes various other SensorProbe devices.  The SensorProbe8 has 8 ports to which you can connect various sensors for temperature and humidity, airflow, water detectors, etc or single-port dry-contacts.  If you look hard, you'll find also that your AC units and other equipment also have dry contacts. Avid readers who crack their equipment manuals will also find that dry contacts can also be used as output triggers not just receiving status.  Once you have a lot of dry contacts, you can check out the SensorProbe8 x20 and x60 which come with a whole lot more dry contacts to check everything in your datacenter.

Mmm, generator power, yum.

Autofs and a couple tricks with NFS shares

Autofs is great especially for NFS mounts between systems.  Autofs will mount file systems on demand and then un-mount them again when they are not needed.  This is especially a nice trick where servers are sharing NFS shares compared to putting the shares in fstab which mounts the file system on boot potentially putting you in a deadlock where server A is waiting on a share from server B and server B is waiting on a share from server A... A common issue for example is mounting /home from a shared location but then no other server can boot until the home file server is up and deadlocks are bad, um 'kay?

"yum install autofs" as needed, use your package manager of choice.  Once you fire up the automount daemon, you can poke around in the configuration.

First thing you'll want to try with is in auto.master enabling the net (or nfs) -hosts line.  This will create a multi-mount in /net where you can access shares via /net/<hostname>/<share path>.

That's really it.  You can directly access files, for example in /net/homefs/data/home/username.  Automount will automatically mount that share when it is accessed and remove it after it's been left idle.

What's it doing?

First, it will look up shares for you.  When you do `ls /net/hostname`, it will return a list of shares available from the server "hostname".  It's really that easy.

Any access to a share is automatically mounted.  A shared folder, call it "work", will be mounted on the first user request for a file from that share.  Whether that's someone using 'ls' or else writing a file to a specified path.

For convenience, my first tip is that you use symlinks to point to specific shares or locations.  Rather than using the path "/net/workfs/export/work", do something like `ln -s /net/workfs/export/work $HOME/work`.   Another example is for shared home directories, super common in UNIX environments.  So link /home to /net/<server>/path/to/shared/home.  It will bring up the shared home directories when a user tries to logon and will unmount the home share after the users are logged out.

This brings me to my next tip: the automatic timeout.  Autofs will un-mount the share after an idle period.  10 minutes by default (depending on your platform).  This may cause you some grief, for example if you have a job that runs every 10 minutes.  You should adjust this timeout based on your needs (either up or down) but unless your running something on a schedule every 10 minutes, you probably won't have much of a problem with this default.

You can also tune your NFS settings in your auto.master config file.  The defaults should work for most systems but if you do have to do NFS tuning, you can do this with autofs either for all NFS mounts or you can create specific mounts as needed.

The interesting thing with autofs is you don't have to use it just for network shares.  You can use it for regular devices as well.  One of the main things is that again, anything in automount will be mounted on demand and not at boot time.  So if you have a large data volume, you can add it specifically to the auto.misc file instead of fstab.

From time to time autofs can get a bit mucked up.  Usually when "you screw around too much".  If stopping autofs and umounting any left-over shares doesn't work, remember "umount -f -l" which is force lazy unmount.  Very useful.  If the folders don't go away, like /net/server/path/to/share, try doing umount on them and then you can remove them (rm -Rf), just be careful.  It depends whether rebooting is more risky than an rm -Rf.

Useful trick for sending HTML email

Sometimes you want to send an email as HTML from a script or from script output anyhow.  There's a couple ways to get the HTML page to the recipient.  You can attach the HTML page or you can set your Content-Type to HTML.  In my case, we're looking at scraping a web page as a cron job and sending it to some recipient(s) - the mainstay is:

curl 'http://server/web/page.html'
Attaching an HTML file is safe, but recipients may not like "opening attachments".  For HTML email, the security risk is the same, but there's a perception that "opening attachments is bad" which I wouldn't discourage as a general practice.  Rambling aside, "uuencode" will encode an attachment, any attachment, and can be used in general (word doc, zip file, etc).

curl 'http://server/web/page.html' | uuencode attachmentname.html

The other way is to set the content type to HTML and the HTML becomes the body of the email.  On some operating systems, namely Debian and Ubuntu, the mail / mailx command can add a header with the -a switch.  This is pretty simple.

curl 'http://server/web/page.html' | mail -a "Content-Type: text/html" -s "An HTML email" some-recipient@example.com

However if you are on a Red Hat / Fedora / CentOS system, your mail command does not support the -a switch.  Here you can use mutt and the mutt method will work in general.

curl 'http://server/web/page.html' | mutt -e "my_hdr Content-Type:text/html" -e "set charset=\"utf-8\"" -s "An HTML email" some-recipient@example.com

There you have it.  Personally not a fan of HTML email (since it opens the doors to a lot of malware attacks), but if you've got to generate HTML email, using standard tools instead of writing your own perl script to wrap the scraping of a web page and generating an email is going to be much simpler.

Thanks to the "telinit q" blog for helping with this answer.  http://blog.telinitq.com/?p=137

Blocking applications with AppLocker

I've just been in a situation where there was a particular user whom we wanted to give some access to but needed to limit their general access which in Windows 7 and Windows Server 2008 R2 you can do with "AppLocker" in a very clear way.  AppLocker sets rules that look much like firewall rules allowing or denying access to run different programs and this can be controlled either locally or through Group Policy Objects.

For example, you have a consultant helping you with your new ERP system (just saying).  They need to launch the ERP application but you really don't want them firing up a browser or the RDP client and checking things out on your network.

Getting started with AppLocker is pretty simple:

• Launch the local group policy management tool
• Enable auditing only initially for exe/dll control
• Create the default rules to allow basic or general access (if applicable)

Then you want to create your specific allow / deny rules.  The AppLocker rules are going to be a collection of rules saying if they are allow or deny rules, who they apply to, what type of matching they use (path, or publisher), and then actual match.  So you might have a rule like

• Allow
• Consultants
• Path
• Program Files\ERP\bin\*

If the consultant only matches this one rule, they will be allowed to launch binaries in the ERP's installation path and will be blocked from anything else.

The first thing to do is set your rules in audit-only which creates event logs for all access that is controlled by AppLocker.  You can test out your rules very easily this way as there will be two types of events to look for: "access granted" and "access granted BUT applocker rules will block this when set to enforcing".  Once you are satisfied you are not going to can all access to your regular users and that you are locking down the consultant sufficiently, switch to enforcing and you're golden.

Or for another example, maybe you just want to block an out of date version of Acrobat Reader from running on your network.  You can set a rule to deny "Acrobat" publisher's "Acrobat Reader" program from running "9.0 or older".  Again, easy to test using "audit only" before setting enforcing.

Looks like a dummy apparmor or selinux maybe?  Honestly, I never made too much progress selinux.  I would figure out how to get something working then wouldn't use it for a while and forget out how to work with selinux and have to start all over again.

End of Free Google Apps

It's official - there's no more free Google Apps.  Google started by limiting free GA accounts from 50 users to 10 and now to 0.  "thenibble.org" was registered in the magical times of 50 free users on your domain and has been grand-fathered in but there will be no new free GA accounts.  Domain aliases can still be added to existing accounts and other features, however I suspect it's only a matter of time before Google stops porting "Enterprise" features into the free service.  Fingers crossed!

Official Google Enterprise Blog: Changes to Google Apps for businesses: Posted by Clay Bavor, Director of Product Management, Google Apps Google Apps started with the simple idea that Gmail could help business...

Simple Shared Storage

Many cluster applications require, or significantly benefit from, shared storage so what is the easiest way to do shared storage?  Whether you want High Availaiblity in VMware or distributed computing on a Beowulf cluster, sharing storage across nodes is useful if not essential.

The first question you need to ask is whether you can do direct connect or not.  Directly connected storage is going to be simpler and more reliable but limits the number of connected nodes and the distance from the nodes to the storage.  There's SCSI or SAS storage which is going to be fast and reliable.  Dell sells an array, the PowerVault MD3000/3200 series, which you can connect up to 4 hosts on each of 2 controllers so either 4 hosts with redundant connections or 8 hosts with non-redundant connections.  The limit of a SAS cable length is 10m (steadfast.net) so if you need longer runs, you start looking at Fibre Channel or Ethernet connections.

Fibre Channel is well established and with link speeds at 4Gbps and 8Gbps these days it's fast.  But it's expensive and suffers from the complexity issue that unless the stars align and you sacrifice a pig, nothing will work.

iSCSI is suprisingly popular.  Encapsulating SCSI devices / commands inside an IP packet seems kind of like a lot of overhead and it really is.  ATA over Ethernet (AoE) makes more sense as you're only going so far as layer 2 - what kind of mad person would run shared storage across separate subnets which need to be routed? It just seems like a big slap in the face for storage when you could use a regular file server protocol like NFS.

Ah, NFS, you've been around for a while.  Frankly, it doesn't get any easier or cheaper than NFS.  Any system can share NFS - every UNIX flavour and GNU/Linux distribution will come with an NFS server out-of-the-box.

It's a one-liner config and you're off to the races.  Put LVM on there and you can expand sotrage as needed, do snapshots, heck add DRBD if you want replication.

You can run NFS (or iSCSI) on any Ethernet connection from just sharing the main interface on the system to dedicated redundant 10Gbps ports.

NFS is well established with plenty of support for optimazation to get over a lot of the limitations of TCP.

Backups for the data, take your snapshot (LVM or VMware, etc) and a plain old cp / rsync will be sufficient to get the files you need off there.


And there's one other benefit of using NFS over others - if you have a lot of concurrency like many virutal machines or compute nodes accessing storage simulataneously, there is (usually) only 1 lock per storage device with the block storage protocols whereas NFS is one lock per file.

But NFS certainly will require at least the addition of a switch and potentially several and some complexity with redundant network links etc etc it can also suffer from the same complexity issue that unless the stars align, you're going to have a bad time.

So in short, NFS is hella awesome and you should use it wherever you can.  Depending on the scale of what you're doing, directly connected storage is going to be simpler and more reliable, possibly cheaper.