NSClient++ and registry keys to allow arguments

Setting up new NSClient++ on WIndows servers, trying to check the status of just one service, ut keep getting the dreaded :

Exception processing request: Request contained arguments (not currently allowed, check the allow arguments option).

SO plenty of people out there with hints for this, but they all involve editing the .ini file - great, except I used the registry method to configure NSClient++. Hmmm. Clint Boessen's blog pointed me in the right direction - set the config key "allow arguments = 1" so I did the closest thing I could think of in the registry, and it worked. Cool:

Email from Solaris to Exchange distribution groups

So yes, I need to send email, via mailx, from Solaris boxes, to Exchange distribution groups. Seemed like a better way than embedding a bunch of email addresses into my scripts. Seemed so simple. So wasn't.

I tested:

w | mailx -s "test to one email" me@mywork.com.au

And it works fine.

Then I created an Exchange distribtution group, with me as the sole member, and tested:

w | mailx -s "test to group" DST-Pinnacle_Backups-ROV@mywork.com.au

Didn't work. Why?

The trick turns out to be that Exchange distribution groups have, by default, a setting that requires senders to "authenticated" - this seems to mean "part of my Windows domain" - in that they have to be authenticated as Windows users. Clearly, sendmail on Solaris isn't going to to meet this criterion.

The solution: open properties for the distribution group, and click the "MailFlow Settings":

Then double-click "Message Delivery Restrictions":

Un-select "Require that all senders are authenticated". Simples!

Space out on Solaris 10

Removing spaces from file names... seems like everyone has their own way to do it. Here's what I ended up putting in my Solaris 10 ~/.bashrc :

function despace()
{
    while IFS='' read FILE
    do
        NEWFILE=`echo "$FILE" | sed -e 's/ /_/g'`

        if [ "$FILE" = "$NEWFILE" ]
        then
            echo "No spaces detected in [$FILE]"
            continue
        fi

        if [ -e "$NEWFILE" ]
        then
            echo "$NEWFILE already exists, not going to overwite it"
        else
            echo "Renaming [$FILE] to [$NEWFILE]"
            mv "$FILE" "$NEWFILE"
        fi
    done
}

Use the command like this:

$ ls * | despace
Renaming [CT.SABR test 5.1.dcm] to [CT.SABR_test_5.1.dcm]
Renaming [CT.SABR test 5.10.dcm] to [CT.SABR_test_5.10.dcm]
Renaming [CT.SABR test 5.100.dcm] to [CT.SABR_test_5.100.dcm]

If a file by the name we're changing to already exists, it will not get over-written:

$ ls * | despace
Renaming [CT.SABR_test_5.1.dcm] to [CT.SABR_test_5.1.dcm]
CT.SABR_test_5.1.dcm already exists, not going to overwite it

The IFS='' is needed to catch trailing spaces on filenames (I know, no sane person would do that, but included for the sake of completeness). If you pass it filenames without spaces, it tells you and skips them.

Note: on Linux you can use rename, but that doesn't live on Solaris 10 by default, and I'm working with the tools I have

Stat - just the facts, ma'am

Stat is a useful tool on Linux that wraps the stat system call to return all available info about a file, and prints it out neatly. I wanted an abbreviated output - just atime, mtime and ctime. Rather than pipe stat's output through something else to strip out the lines I didn't want. I used the stat utility's --printf option to output just the bits I wanted:

$ stat --printf="atime: %x\nmtime: %y\nctime: %z\n" /tmp/testfile
atime: 2014-12-02 09:57:01.890339130 +1100
mtime: 2014-12-02 09:58:31.066781362 +1100
ctime: 2014-12-02 09:58:31.066781362 +1100


Yay for stat (and reading the man page once in a while!)

Fun with tar

I had an interesting challenge today: we use an application (Pinnacle) that uses tar files to save a collection of patient files as an archive. How can we tell which tar file contains which patients?

For each patient in the archive, there's a file called "Patient", so I initially started by getting these out and grepping them. Because tar doesn't allow a wildcard operator, you have to first build a list of the files (one per patient) in a sub-shell, then pass it to tar:

tar xfO 20131025_03_HD1.1.tar `tar tf 20131025_03_HD1.1.tar| grep 'Patient$'` | grep -i lastname

Note: you'll need to use gtar if you're on Solaris (on Solaris 10 boxes it's installed at /usr/sfw/bin/gtar) so you can extract the file's contents to STDOUT using xfO (that's a capital letter Oh, not a zero).

However, there's an easier way to manage this. At the start of each tar file, there's a file called Institution which stores header information about the patients contained in this archive file. The section we're interested in looks like this:

  PatientLite ={
    PatientID = 98765;
    PatientPath = "Institution_123/Mount_0/Patient_98765";
    MountPoint = "Mount_0";
    FormattedDescription = "CLAUS&&Santa&&&&098765&&SL&&2013-10-23 11:20:03";
    DirSize = 349.607;
  };
  PatientLite ={
    PatientID = 12345;
    PatientPath = "Institution_123/Mount_0/Patient_12345";
    MountPoint = "Mount_0";
    FormattedDescription = "CHRISTMAS&&Mary&&&&012345&&MAG&&2013-10-23 11:20:14";
    DirSize = 262.177;
  };

OK, so it shouldn't be too hard to get this info:

$ gtar xfO 20131025_03_HD1.1.tar Institution | awk -F'=' '$1 ~ /FormattedDescription/ {print $2}'

 "CLAUS&&Santa&&&&098765&&SL&&2013-10-23 11:20:03";
 "CHRISTMAS&&Mary&&&&012345&&MAG&&2013-10-23 11:20:14";
... clean up those ampersands:

$ gtar xfO 20131025_03_HD1.1.tar Institution | awk -F'=' '$1 ~ /FormattedDescription/ {print $2}' | sed -e 's/&/ /g'

 "CLAUS  Santa    098765  SL  2013-10-23 11:20:03";
 "CHRISTMAS  Mary    012345  MAG  2013-10-23 11:20:14";

Now let's write something to catalog a directory full of these tar files:

$ for TARFILE in *.tar; do echo "Filename: $TARFILE"; (gtar xfO "$TARFILE" Institution | awk -F'=' '$1 ~ /FormattedDescription/ {print $2}' | sed -e 's/&/ /g'); done

Filename: 20131025_03_HD1.1.tar
 "EXAMPLE  Fred    012345  SL  2013-10-23 11:20:03";
 "EG  Robert    123456  MAG  2013-10-23 11:20:14";
  [etc]
Filename: 20131025_04_HD1.1.tar
 "CITIZEN  Jeanette    234567  SL  2013-10-23 11:20:03";
 "ALIAS  Dean    345678  MAG  2013-10-23 11:20:14";
  [etc]
Filename: 20131025_05_HD1.1.tar
 "MANCHU  Fu    456789  SL  2013-10-23 11:20:03";
 "KHAN  Ghengis    567890  MAG  2013-10-23 11:20:14";

Hey presto!

Firefox - running multiple instances

If you've ever logged on to the same host from two different displays and tried to run Firefox, you will probably have seen:

Firefox is already running but is not responding. To open a new window, you must first close the existing Firefox process or restart your system

It's because two instances of the Firefox application are attempting to share ~/.mozilla/firefox/some-default-profile. No matter how many combinations of -no-remote and -new-instance I tried, same problem.

Solution: small shell script that creates a new profile each time (we don't need any bookmarks imported or anything, we just want a simple browser to display an HTML page) then deletes it afterwards:

#!/bin/bash

FIREFOX=/usr/lib/firefox/firefox

TEMP_PROFILE=`mktemp -d`
PROFILE_NAME=`basename $TEMP_PROFILE`
$FIREFOX -CreateProfile "$PROFILE_NAME $TEMP_PROFILE" 2>/dev/null
$FIREFOX -profile $TEMP_PROFILE
rm -rf $TEMP_PROFILE

Tested and working on Linux and Solaris 10. The idea came from here but I couldn't get to the shell script from that post (busted link?) but I figured this was probably what he/she meant :-)

What window is that?

Somtimes, in this wonderful Unix-Linux world, I want to know "what is the name of the executable application that popped open that window?" - this is especially helpful on user-friendly Linux distros that try to hide the gory details for the user. For example, what is the name of the application being used to open my PDF file by Nautilus here?







The answer is /usr/bin/evince, but it's not that easy to figure that out, now is it? The trick is to allow the window to open, then use... something... to identify the executable that opened it.

Some good folks came up with a neat answer over here which works pretty well. Use xprop to get the PID of the window, look up /proc/PID/exe and hey presto, you have the name of the executable (in most cases). I slightly adapted the second answer (I like shell aliases!) to come up with this addition to my Linux ~/.bashrc:

alias xident='ls -l /proc/$(xprop _NET_WM_PID | awk "{print \$NF}")/exe | awk "{print \$NF}"'

And for Solaris 10 and 11 we can do similar. There's no /proc/PID/exe, but pargs tells us the name of the executable. Note that this doesn't work in CDE, but does for Java Desktop/Gnome Desktop:

alias xident='pargs $(xprop _NET_WM_PID | awk "{print \$NF}") | awk "\$1 ~ /argv\[0\]/ {print \$2}"'