Mine the Harvest

Click above to get started with your 30 day trial account, which you can convert to a free forever account (limited to two projects.)

I’ve been looking for a good method for tracking time on projects and tasks. My previous solution was GnoTime, which worked relatively well, but had a few points I was unsatisfied with. Deciding to try something new Google lead to this post from which I discovered  Harvest, which is a hosted time management solution. Previously, I’ve only used desktop applications such as GnoTime, Ktimetracker, etc. though I liked the idea of a web tool, as easily accessing it from both work and home was appealing, as well as mobile support for Android.  Not having to sync files via Dropbox between systems was certainly appealing, and Harvest offers some very nice features including reporting and even invoicing capabilities.

Setting up a Harvest account takes about two minutes, and I had an initial project and tasks defined right away. The web interface is easy to navigate, and provides start / stop timers for each task, which is a feature I wanted. I should note this is a paid hosting service, however pricing is reasonable, there is a 30 day trial, and the website also is currently promoting “The Harvest FREE FOREVER Plan – 2 Projects, 4 Clients, & 1 User, absolutely FREE” – perfect.  Update:  Once signed up, you can change simply convert your 30 day trial account to the free account under you account management, upgrade settings.

But it gets better. The first day I left a timer running at work, and the next morning received an email from Harvest informing of this. Nice. Also, over the course of the first week I received some helpful emails (non-spam) to get new users started using some of the features, a web cast invite for how to do invoicing, etc. I also sent them a ticket asking about converting to the free account, and if they had a referral program, and received a response the next day. The referral program credits you time for anyone you refer, though does not credit them – though they of anyone can join the referral program. The big orange button at the top of the article is an example of one of the referral buttons you can get.

You can also export your time to a csv file, which is quite handy, and the invoicing capabilities might be extremely helpful for those needing them (I do not currently use this feature, but it is very nice it is there.)

Editing time in the web interface is flexible and easy. If a field already contains 9.43 hours, you can add or subtract time by simply appending say -4.15 and it will automatically calculate the new time, nice for reducing simple mistakes. You can use the ‘n’ hotkey to add a new task, and tab / enter to complete it.

Now, the icing on the cake would be a Linux desktop widget. While the download site has widgets for OSX and Windows, none was listed for Linux – and, unsurprisingly, the OS X one does not work when installed in plasma. However, this post pointed me to the Harvest Command Line Tool (hcl), a ruby tool designed by Zack Hobson which provides a command line interface which uses the Harvest API to allow task management via the command line. Wow. The Harvest devs are also apparently looking at providing an actual widget in the future per this feature request, but hcl is fine for me. The fact there is a useful API which is being used for tools like hcl is another huge benefit to Harvest.

Installing Harvest Command Line Tool

Installing hcl is extremely easy, as it is available as a Ruby gem. You may also install it from source via the hcl git repo.

Installing with gem was simply a matter of installing rubygems for my distro and then the hcl gem:

#zypper install rubygems
#gem install hcl

(For Ubuntu and Fedora users, this should simply be a matter of installing rubygems as well via yum or apt-get.)

Running hcl the first time prompts for your Harvest account credentials, and your Harvest subdomain  – this is the yourdomain part of you yourdomain.harvestapp.com account you created earlier. You may now list your project and start / stop tasks, etc. For example:

paracelsus@linux:~> hcl tasks
1782588 1165030 Prime Enterprises – ORNL – ARM
1782588 1165024 Prime Enterprises – ORNL – Admin
1782588 1165031 Prime Enterprises – ORNL – BDS
1782588 1165029 Prime Enterprises – ORNL – DAAC
1782588 1165032 Prime Enterprises – ORNL – GPGPU
1782588 1165034 Prime Enterprises – ORNL – ITSD
1782588 1165025 Prime Enterprises – ORNL – Project Management

You can view the time for a specific day:

paracelsus@linux:~> hcl show last friday
8:09 ORNL
————-
8:09 total (as of 10:12 am)

And of course start and stop the timer for a project / task and include a log message:

paracelsus@linux:~> hcl start 1782588 1165032 Testing hcl
Started timer for Prime Enterprises – ORNL – GPGPU (0:00) (at 10:21 am)

Additional options are available via hcl –help and further usage examples are available in the documentation at git hub, such as: https://github.com/zenhob/hcl/blob/master/README.markdown

Summary

So far I am quite impressed with Harvest. It provides the features I needed, and the inclusion of an API and tools like hcl are all I needed. I’m looking forward to using it over the next few weeks on my projects.

The referral program is a nice bonus. I had very good success with the Dropbox referral program, so we will see how this one goes.

If you are looking for a time tracking tool, Harvest might well be worth test driving.

We provide users with a visualization system with IDL, MatLab, and Visit. X-Forwarding can be painfully slow, and we have found that using NXServer, or Googles open source NeatX equivalent, can provide much faster performance.

However, VisIt would launch when X-Forwarded, but not when using NXClient & NeatX. The only messages were:
…
Running: mdserver2.3.2 -host 127.0.0.1 -port 5601
VisIt's viewer exited abnormally! Aborting the Graphical User Interface. VisIt's developers may be reached via the visit-users mailing list.  Please see:
htttp://visit.llnl.gov/FAQ.html#1

I also found that glxinfo would return:

$ glxinfo
name of display: :826.0
Error: couldn't find RGB GLX visual or fbconfig

Solution:

First, I created an xorg.conf to ensure GLX was actually being loaded. (It turned out this was not required as X was autodetecting everything fine without an explicit xorg.conf, but I include it here as it may be helpful in some cases to have an explicit xorg.conf)

Xorg -configure
(renamed xorg.conf and moved to /etc/X11. Ensured Section “Module” included Load “glx”, etc.)

glxinfo still would not work. I then set the following environmental variable:

export  LIBGL_ALWAYS_INDIRECT=yes

Which allowd glxinfo, glxgears, etc. to work. For more information on this environmental, see:

http://unix.stackexchange.com/questions/1437/what-does-libgl-always-indirect-1-actually-do
https://bugs.launchpad.net/xorg-server/+bug/384001

This could then be made into a Gnome Desktop Launcher:

cat VisIt.desktop
[Desktop Entry]
Version=1.0
Type=Application
Terminal=false
Icon[C]=gnome-panel-launcher
Name[C]=VisIt
Exec=env LIBGL_ALWAYS_INDIRECT=yes /usr/local/visit/bin/visit
Name=VisIt
Icon=/usr/share/icons/visit.jpg
Categories=GNOME;Application;Development;

Perhaps the above may be useful to other VisIt users.

I’ve been waiting 27 years to see this:

joshua@jaguarpf-login2:~> date
Thu Mar 10 16:04:31 EST 2011
joshua@jaguarpf-login2:~>

Translated from Old High Geek (derived from early proto Unix) that output is similar in magnitude to the fabled Enochian Emerald Tablets of Hermes Trismegistus. But to explain how cool this was for me, a bit of a narrative is needed, but there won’t be much computer speek or techno mumbo jumbo in this post.

In 1983, when I was 12 years old, the movie War Games came out. Of course, I was already deeply in love with computers and had spent endless hours already using my 8 Mhz, 8-bit Atari 400 with 24K as well as my Vic 20 with 3K. Naturally, being a geek, I knew about Cray Supercomputers. (The word was pronounced with a slight pause and inflection when uttered, if indeed the ineffable need be put in human words.) The anecdotal relationship in War Game’s between professor Falken (John wood) and the real life Seymour Cray was  also common geek lore – cannon in fact. Cray was THE supercomputing company – the gold standard of computing.

My love for Cray systems continued unabated from that time, and I would always keep an eye on what the company, and there computers, were doing. Of course, the story of the visisituedes of the company and its founder are near legendary. But like a favorite sports team or rock band I was always a loyal fan – even though I had never once used a Cray system. Neither did I own any platinum, or anti-matter, but one need not have something to know its worth.

More years past until in October of 1996, while driving to work, I heard the news of the unexpected death of Seymour Cray. Wow, that sucked. The father of supercomputing was killed in a car crash, apparently by a drunk driver. I thought about it for days, with the surreal feeling you get when a hero figure is made so painfully mortal, and who’s life need not have been ended. It was just one of those days you will always remember.

Over the years computers kept changing. The age of the custom “big iron” vector supercomputers waned, replaced by commodity hardware running thousands of CPUs and powered by a little OS called Linux. Now, if there was one thing I liked equally as much as Cray’s, it would have to be Linux.

One thing lead to another, and I was recently offered a position at Oak Ridge, the home of Jaguar – a Cray XT5  system with over 220,000 cores running at 2.3 PF (2.3 quadrillion calculations a second).  Jaguar, my favorite computer in the World, running my favorite OS, on a Cray platform, was what lead me to the Lab and I’ve been quite happy with my position there.

So, while that output might seem like any other login, or some boring computer output, for me it had a bit more emerald tablet like glow to it.

Today is another one of those days I’ll remember.

Thanks Seymour.

Recently I decided to revive my interest in playing the guitar. I took a few lessons back around 1988, but didn’t stick with it. Over the years  my desire to pick it up again has cropped up here and there, but either I was too busy with life and college, or my guitar was in another state, or whatnot. However, I was recently reunited with my guitar, but not my old amp. I decided to see how I might use my Linux box to allow my to play through it, and perhaps have some effects processing as well. I quickly discovered the rich extent of audio tools available for Linux, and even for the guitar specifically. I hit a gold mine.

I quickly found several USB sound cards with 1/4″ jack inputs, which were well supported under Linux, were readily available – and at a modest price. I ordered a Behringer UCG 102 off Amazon for all of $29.

Behringer UCG 102

I also discovered Rakarrack, an full featured guitar effects processing suite for Linux.  I had no issues getting Rakarrack installed, and anxiously awaited the arrival of the new sound card. If you play the guitar, you really have to check out Rakarrack – it is amazing.

Rakarrack - Sound Like a God

When the Behringer arrived I was shocked to discover the EnergyXT2 recording software it came with nativity supported Linux. Displayed right on the CD sleeve was a an nice capital “L” and advertised Linux support:

Yep - it runs on Linux.

This, of course, I would have to try – simply as a matter of principle. I soon discovered however several issues with this software, and my solutions to them are below.

NOTE: I should say however that the Behringer Guitar to USB interface worked flawlessly, and in short order I had connected my guitar, fired up the Jack audio server, launched Rakarrack and was playing. The effects provided by Rakarrack include: distortion, chorus, reverb, flanger, digital delay and many others. Wow – this is like having an array of effects pedals for free, and they sound great.  And it should be mentioned as well that the open source Ardour recording software worked without requiring anything beyond finding and installing the RPM. So . . . why even bother with getting EnergyXT2 to work? Well, because it’s there. I loved the idea of getting Linux software with a product I bought, and by God I intended to see it work.

Do you need to do this too? Well, that’s up to you. You can certainly use Ardour to record with, and it works extremely well. But if you want to try out EnergyXT, and use it with Jack, and with MIDI, and especially if you are running 64-bit – then read on.

If all you want is a basic working EnergyXT2 without Jack support, that should not be too difficult:

0) First – you need to download the latest version of EnergyXT2 for the website. The version which was shipped has a bug which caused it to fail returning:

X Error of failed request: BadImplementation (server does not implement operation)
Major opcode of failed request: 139 (MIT-SHM)
Minor opcode of failed request: 5 (X_ShmCreatePixmap)
Serial number of failed request: 382
Current serial number in output stream: 384
X Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
Major opcode of failed request: 55 (X_CreateGC)
Resource id in failed request: 0x2a000a4
Serial number of failed request: 383
Current serial number in output stream: 384

This is easily solved by downloading the updated version. You might want to grab the manual too.

At this point it should start and work correctly, but you will not have Jack support. For that you need to continue with the next steps. This assumes some familiarity with compiling things, obtaining required libraries, and some basic debugging – it is not really difficult, but if you have not compiled things much it may be a learning experience.

1) The version of libaam.so provided with the software has several limitations, the most significant of which is that it does not support the Jack audio server.  Now – there are two routes to take here:

A) Download the source for libaam.so from the EnergyXT libaam site and compile using the instruction there, or:

B) Download and compile the source for from the libaam Jack Sourceforge project. This is most certainly the better route to take as it supports more MIDI channels and also can build a QT Interface to configure it to work with Jack. Simply download, untar and continue with the steps below.  Note this contains its own readme and make file, and QT interface, unlike the basic version for the EnergyXT site.

2) Next, I was building this on a 64-bit OpenSuse 11.3 system. The fact of building this on a 64-bit platform introduces a number of additional factors which have to be addressed. If you were to build this on a 32-bit platform, it would be easier.  If using a 64-bit environment (perhaps like Studio64) the first thing you need to do is ensure you have the 32-bit versions of the libraries you will need, AS WELL AS 32-bit versions of gcc, glibc, etc. These are going to be called different things depending on your distro, but you are looking for things like:

libasound2-devel
libjack-devel-1.9.5-2.8.i586 (get 32-bit version from webpin)
alsa-plugins-jack qjackctl
libqt4-devel-4.6.3-2.1.1.i586
alsa-devel-1.0.23-2.12.x86_64
glibc-32bit-2.11.2-3.3.1.x86_64
gcc45-32bit-4.5.0_20100604-1.12.x86_64
gcc-c++-32bit-4.5-4.2.x86_64

And maybe . . .

libSDL_mixer-1_2-0-32bit
libSDL_mixer-1_2-0

Should you receive any build errors complaining about libs you know you have, may need to make some symlinks for several of the libraries, such as:

sudo ln -s /usr/lib/libasound.so.2.0.0 /usr/lib/libasound.so
sudo ln -s /usr/lib/libjack.so.0.1.0 /usr/lib/libjack.so
sudo ln -s /lib/libgcc_s.so.1 /lib/libgcc_s.so

Getting all the 32-bit libraries you need may take a few tries – each time you compile you may be presented with some new library needed – but you should be able to work through them and fortunately there are a limited number required.

If you do not have 32-bit gcc, you may get messages similar to:

paracelsus@Callandor:~/energyXT/libaam-0.0.2> g++ -m32 -shared -lasound -ljack jack.cpp -o libaam.so
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld:
i386:x86-64 architecture of input file `/usr/lib64/gcc/x86_64-suse-linux/4.3/crtbeginS.o’ is incompatible with i386 output

This is simply due to missing the proper gcc and g++ 32-bit packages – oops. (While I had the necessary 32-bit libs for qt and Jack, I  inadvertently had not installed 32-bit gcc and g++ libs, so it indeed was missing the 32-bit version of crtbeginS.o, just like it says.

2) This then allowed libaam.so to build, and you should be able to use the library at this point. You most likely want the configuration interface too, but building xt2-config failed with a missing qmake-qt4, though it was installed. That was corrected with a symlink:

ln -s /usr/lib/qt4/bin/qmake /usr/bin/qmake-qt4

3) The next problem building xt2-config was with it expecting a 32-bit build environment – Note that -m32 is specified in the Makefile for libaam, but NOT in the config/Makefile for xt2-config, thus:

g++ -c -m32 -pipe -g -Wall -W -D_REENTRANT -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include -I. -I. -o moc_configw.o moc_configw.cpp
g++  -o xt2-config main.o configw.o moc_configw.o    -L/usr/lib -lQtGui -L/usr/lib -L/usr/X11R6/lib -lQtCore -lpthread
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libQtGui.so when searching for -lQtGui
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libQtGui.so when searching for -lQtGui
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libQtGui.so when searching for -lQtGui
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: cannot find -lQtGui

Now, I can see that g++ is not being called with -m32 when it links the three compiled files main.o configw.o moc_configw.o To get this to build correctly I modified the Makefile in config/Makefile (which is called from the Makefile in the build root), and added:

#CFLAGS        = -pipe -g -Wall -W -D_REENTRANT $(DEFINES)
CFLAGS        =  -m32 -march=i386 -pipe -g -Wall -W -D_REENTRANT $(DEFINES)
#CXXFLAGS      = -pipe -g -Wall -W -D_REENTRANT $(DEFINES)
CXXFLAGS      =  -m32 -march=i386 -pipe -g -Wall -W -D_REENTRANT $(DEFINES)

And . . .

####### Build rules

all: Makefile $(TARGET)

$(TARGET): ui_config.h $(OBJECTS)
        $(LINK) $(LFLAGS) $(CXXFLAGS) -o $(TARGET) $(OBJECTS) $(OBJCOMP) $(LIBS)

The result is a working libaam.so you can copy to your energyXT folder (backup and replace the existing) which supports Jack, and a working xt2-config (move it from config/ to /usr/bin)

xt2-config for Jack Audio

Of course on a 32-bit OS EnergXT2 should just run out of the box (as long as you have downloaded an updated copy) but you still would not have Jack support (which is really the way to go), or the QT config interface, and as more users move to 64-bit and RT kernels for audio applications, this may come in handy.

It seems we are  always reading  update notes saying:

“Fixed a potential buffer overrun condition which if exploited could result in the attacker executing arbitrary code and possibly escalating privileges.”

These exploits are extremely common, and of course patches and updates to correct such are equally common, regardless of the OS platform.

I of course had a generalized understanding of how these exploits worked – but I’ve recently decided to really dive in and greatly increase my knowledge in this area. A superficial understanding was no longer sufficient and I wanted to not only understand better, I wanted to learn how to leverage such exploits with hands on hacks.

So – I armed myself with some material, starting with “Hacking:  The Art of Exploitation” by Jon Erickson loaned by a colleague. As it turned out the first edition of this book was published in 2003. Since then there have been many changes in both gcc and recent versions of the 2.6 kernel that greatly improve stack security. Thus the sample code in the book is no longer capable of simply being compiled and executed to achieve the desired result.

I ended up learning just as much getting the first exploits to work correctly in more modern distros as from the text itself. But its all part of the educational process and I certainly understand the current kernel and gcc operations a bit better. And I was able to make the first lessons work.

Making Old Hacks Work

The best way I found to get the code to compile and run as intended was to use an older OS and Kernel in Virtual Box. I installed a basic install of Ubuntu 6.06 and used that. The 6.2.15 kernel it had allowed the exploits to run, if you tweaked it.

By disabling randomize_va_space in /proc/sys/kernel and by compiling with an earlier version of gcc (3.3 and 4.0) the results were achieved:

The exploit is a simple one, but a classic. It simply rewrites the return address by over flowing the buffer, taking control of the execution flow of the program that calls it and directing it to run a snip of shellcode. The shellcode is a self contained piece of assembly that spawns a shell. Because the program that is called is an suid root program, and runs as root, a root shell is opened.  (Note there are several suid binaries installed on most systems and a similar exploit against any of them could potentially achieve the same.)

The source for the two programs for this exploit can be found here and here.
(Ensure vuln is owned by root and has the suid bit set with chmod +s)

To Learn More

I recommend the new second edition of Hacking The Art of Exploitation by No Starch Press, which you can review here.  The new version looks like it takes more modern compiler and kernel design into account and has expanded content as well.

Current GCC and Kernel Operation

Note that more recent versions of gcc (4.2 and higher I believe) compile with stack protection enabled by default. To compile without use:

user@system:~/$ gcc-4.3  -fno-stack-protector -o exploit exploit.c

Also, you may find reading up on stack protection and the following kernel options to be helpful:

root@paracelsus-laptop:~/hacking# cat /proc/sys/vm/mmap_min_addr
0
root@paracelsus-laptop:~/hacking# cat /proc/sys/vm/vdso_enabled
0
root@paracelsus-laptop:~/hacking# cat /proc/sys/kernel/randomize_va_space
0