Wednesday, February 26, 2014

nfsen nfdump all x's and 'File not Found' for recent netflows

On my NFSEN system, I recently had a problem where all the current data flows showed "x" on the channels' traffic speed columns.

Also when I ran reports (filter processing), I'd get an error stating an nfdump data file was not found.

stat() error 'path/nfsen/profiles-data/live/channel/year/month/day/nfcapd.yearmonthdaytime': File not found!

It turned out that at some point I set my TimeZone in the OS, but php/apache did not use the same TimeZone.

In, CentOS, I checked /etc/sysconfig/clock which contained:

However, my /etc/php.ini had nothing set. So I replaced the timezone line with
date.timezone = America/Chicago

Then I restarted apache with:
service httpd restart

Woot, that fixed it!

Your Linux distribution may have different files/paths, but the concept should work the same.

Good Luck!

Saturday, February 22, 2014

Password Protect Microsoft Remote Desktop Client for OSX

Microsoft Remote Desktop client version 8.x for OSX was released and I find it particularly nice. (Way better than v. 2.1.1 anyway).

One thing I tend to do is store my passwords, but this can be a bad habit for an enterprise environment.

I've found a way to password protect launching the RDP client, and furthermore, close it when the computer sleeps -- very convenient.

Essentially, what we'll do is create an encrypted storage container, move the app inside, and launch kill/eject scripts when entering sleep-mode.

This write-up assumes OSX 10.5+; I'm on 10.9.1 (Mavericks).

First, I used Disk Utility to create an encrypted .dmg file:

Launch the Disk Utility via Applications>Utility>Disk Utility.

Select File>New>Blank Disk Image.

In the "Save As" field, find your home directory or any other preferred area.  Name it "RDP.dmg".

In then "Name" field, name it "RDP" -- we will reuse this name for the eject-function later.

I found that "Microsoft Remote" was 67.7MB, so I opted to set the "Size" field as 72MB.  You can try 68MB if you like, I assume it would be fine.

For the "Format" field, I chose "Mac OSX Extended" as i do not need it journaled.

In the "Encryption" field, I chose 128-bit AES, but you may choose 256 if you are paranoid.

For "Partitions" and "Image Format", I chose the defaults of Single GUID and read/write respectively.

You will be asked for a password.  This is permanent so choose wisely.  Also, for the "Check-box" elect NOT to "Remember Password in my keychain" so that you are required to enter your password with each launch.

Once the RDP.dmg file is created, open it with Finder if it's not already open.  Again do NOT check to "Remember password".  Using Finder, drag the Microsoft Remote Desktop application into your new RDP.dmg file.  MS-RD should be in your Applications folder if you've installed it, or in the installer .dmg if you have not.

Once you have MS-RD inside the RDP.dmg file, go ahead and launch that copy.  Now to simplify things for future usage, on OSX's Dock, right click "Microsoft Remote Desktop", select Options, and select "Keep in Dock".

Now let's test your new password protected RDP Client.  First, close the MS-RD application.  Then eject "RDP".

Now using the Dock shortcut, click to open "Microsoft Remote Desktop" -- it should again ask for your password.  Voila, you have a password protected RDP client!  The key to this is to never check-on "Remember password in my keychain."

If everything works as expected, you should delete the original MS-RD app from your applications folder if you had previously installed it.  (And remove the original Keep in Dock if you had such.)

Now the interesting part of the project -- the RDP.dmg remains mounted even if you close MS-RD.  This mean the app could be re-lauched without the password. To protect from this, you could manually eject RDP.dmg after each usage (blah), or we can find a way to both close MS-RD and eject RDP.dmg when the machine goes into sleep mode (way more convenient). 

Now there may be ways to execute the process for a screensaver trigger, but I happened across a sleep-mode trigger solution first using SleepWatcher.  In fact, upon reading, SleepWatcher does indeed have an idle-mode trigger too, but this write-up will not utilize such as I have done this on a MacBook-Air and opted for sleep-trigger due to the ability to close the screen-lid to enter sleep-mode.

This configuration process will be mostly command line oriented.

Go ahead and download and extract SleepWatcher to your ~/Desktop.  You can delete the folder/files after the configuration process. Be certain to read the ReadMe.rtf file within.  If you do not already have SleepWatcher, then do not perform the first tasks listed, instead be sure to jump to the "Installation for new SleepWatcher users" section. Go ahead and skim through the readme first; The commands are listed below for convenience.

I elected to use the "user" mode .plist and therefore this resulted in my functions to be created in the ~/.sleep file.

If you elect the same, then as per the ReadMe.rtf file, do the following:

sudo mkdir -p /usr/local/sbin /usr/local/share/man/man8

sudo cp ~/Desktop/sleepwatcher_2.2/sleepwatcher /usr/local/sbin/

sudo cp ~/Desktop/sleepwatcher_2.2/sleepwatcher.8 /usr/local/share/man/man8/

cp ~/Desktop/sleepwatcher_2.2/config/de.bernhard-baehr.sleepwatcher-20compatibility-localuser.plist ~/Library/LaunchAgents/

launchctl load ~/Library/LaunchAgents/

Be careful copy-pasting, the five commands above are all ONE LINE each. You may opt to copy-paste into a text editor first to verify ONE-LINERS.

My ~/.sleep file consisted of the following:

killall "Microsoft Remote Desktop"
/usr/sbin/diskutil eject /Volumes/RDP

Be sure to chmod +x ~/.sleep to make it executable.

The above ~/.sleep script will close MS-RD and also eject the RDP.dmg file.

If you've done the above configuration properly, then you can test the scenario by launching MS-RD and then closing your laptop lid or waiting for sleep-mode to trigger.  Your power settings in OSX are in Applications>System Preferences>Energy Saver.

Quite cool, no?

Good Luck!

Thursday, February 20, 2014

Replacing LogMeIn with TeamViewer on OSX and Linux

LogMeIn is no longer free and I'm not paying!

There are many remote desktop solutions and I have multiple ways of seeing my Linux desktop in emergency, but I've found TeamViewer (free for personal use) is a great replacement of LogMeIn on OSX.

I was accustomed to LogMeIn on OSX because it was always running and quite simple to remote from the web-console, LogMeIn Ignition, or even Android and iOS.  TeamViewer, although not the prettiest interface, works the same, supports multiple monitors, and even supports Linux. It also has advanced features such as file-transfer, meeting-mode, and video/audio conferencing -- but I'm not one to utilize such. TeamViewer does indeed have Android and iOS clients as well.

Go ahead and install the "All-In-One: TeamViewer full version" from for either Linux or OSX or both. If you choose, make them run at startup (as a daemon (service)). I also have a way around this as you will see further down.

Now the key settings to make TeamViewer work like LogMeIn is the following:

1) Create an account on !
2) Assign your client(s) to your account: TeamViewer>Preferences>General>Assign to account.
3) Set your client to unattended mode: TeamViewer>Preferences>Security>Password.

Presto change-o -- a LogMeIn replacement!

TeamViewer screencap


* The issue mentioned below seems to be fix in recent versions; However, I'll keep this info available: 

I had one issue that bugged me: On Linux, the client constantly bugged me with a pop-up and reported "click to disable" (the pop-up).  But it would never disable, no matter what.  So my solution is to NOT run TeamViewer upon startup; HOWEVER, I can still launch it via remote SSH login.

The key to this is that I still run LogMeIn Hamachi (Mesh VPN) on all my machines so that I always have SSH access to any of them (as long as Hamachi doesn't fail).

Now, from a remote machine, SSH into the Linux machine and perform the following:

env DISPLAY=:0 teamviewer

Don't close your SSH (preferably, run it from screen). This will set the GUI of TeamViewer to the default display (the monitor) and launch it properly -- now TeamViewer should be ready for a client connection.  (If it does not launch, see below regarding the daemon start command)


Similarly, this can be done with OSX, but there seems to be a bug that requires a particular work-around that I was lucky to notice.  TeamViewer will need to be run twice -- once as sudo, and another as the user:

SSH into the OSX machine and run TeamViewer like so:

sudo /Applications/ 

It should fail and report:
com.teamviewer.desktop: Invalid argument
com.teamviewer.teamviewer: Invalid argument

Now run it again without sudo:


This should launch TeamViewer and make it ready for a client connection.

If for some reason it fails to launch, try setting the display first with:

export DISPLAY=:0


I've had some occasions where the programs stay running or won't relaunch properly.  It's probably best to quit the program from the desktop GUI, but if all else fails, in Linux, we can use the killall command to stop the processes:

killall teamviewer
killall wineserver
killall TeamViewer.exe
sudo killall teamviewerd

(It turns out TeamViewer for Linux actually runs a custom version of wine to emulate the windows version.)

You should restart the daemon service after any kills, as the GUI client will not run without:

sudo teamviewer --daemon start

In OSX, it seems I could only quit TeamViewer from the Desktop and unfortunately not use the killall nor the kill commands.

You may have better success, you can find the processes with the following command:

ps aux | grep [Tt]eam[Vv]iewer


Other free options that you may research -- but likely require direct network connectivity or VPN and therefore do not work like LogMeIn or TeamViewer for "from anywhere" remote access:

Both Linux and OSX:
X11 Forwarding over SSH (NXRemote) -- I had played with version 3 which was SSH secure and as fast as RDP.  It created virtual desktops like RDP, but I had issues keeping it working.  Version 4 is now available and works differently -- it now connects to the actual desktop much as LogMeIn or x11vnc.  It is, however, direct access only until they release "NoMachine Anywhere." Android and iOS clients are in Alpha and not yet released.

Preferences>Sharing>Screen Sharing (VNC) (There commandlines/files to enable, but different versions of OSX have different commands, so you may research that on your own.)

Linux (likely in your repositories) :
xrdp - RDP for X !
A ton of different VNC servers, but i like x11vnc best.


Related to the subject, here are RDP Clients:

Microsoft RDP Client v2.1.1
Microsoft RDP Client v8.x (on a domain, use the "DOMAIN\username" syntax) ; Available on iOS also!

Linux (likely in your repositories):
Remmina+freerdp (xfreerdp) -- supports Microsoft's Network Level Authentication (NLA).


Related to the subject, here are alternatives to Hamachi (listing only cross-platform solutions):

ZeroTier One (RECOMMENDED - i have move off of hamachi onto this; with great success)
n2n - a Layer Two Peer-to-Peer VPN
SoftEther VPN Project
tinc vpn
freelan (no redhat, et al?)
Remobo -- I had tried this a long time ago, but didn't like it so much.  It might be worth a revisit.
NeoRouter Free (as opposed to the Mesh and Pro versions)

Good Luck!