home

Compiling And Running GAMESS-US (1 May 2013(R1)) On 64-bit Ubuntu 12.X/13.X In SMP Mode

April 5th, 2014

Author’s Note 1: It is my standard policy to put too much info into guides so that those who are searching for specific problems they come across will find the offending text in their searches. With luck, your “build error” search sent you here.

Author’s Note 2: It’s not as bad as it looks (I’ve included lots of output and error messages for easy searching)!

Author’s Note 3: I won’t be much help for you in diagnosing your errors, but am happy to tweak the text below if something is unclear.

Conventions: I include both the commands you type in your Terminal and some of the output from these commands, the output being where most of the errors appear that I work on in the discussion.

Input is formatted as below:

username – your username (check your prompt)
machinename – your hostname (type hostname or check your prompt)

Text you put in at the (also shown, so you see the directory structure) prompt (copy + paste should be fine)

Text you get out (for checking results and reproducing errors)

Having just recently downloaded the newest version of GAMESS-US (R1 2013), my first few passes at using it under Linux (specifically, Ubuntu 12.04) ran into a few walls that required some straightforward modifications and a little bit of system prep planning. As my first few passes before successful execution are likely the same exact problems you might have run into in your attempts to get GAMESS-US to run (after a successful compilation and linking), I’m posting my problems and solutions here.

Qualifier 1 – My concern at the moment has been to get GAMESS-US to run under 64-bit Ubuntu 12.04 on a multi-core board (ye olde symmetric multiprocessing (which I always called single multi-processor, or SMP)). While some answers may follow in what’s below, this post doesn’t cover MPI-specific builds (nothing through a router, that is). SMP is the only concern (which is to say, I likely won’t have good answers if you send along an MPI-specific question). Also, although I’m VERY interested in trying it, I’ve not yet attempted to build a GPU-capable version (but plan to in the near future).

Qualifier 2 – It is my standard policy to install apps into /opt, and my steps below will reflect that (specifically because there’s a permission issue that needs to be addressed when you first try to build components). You can default to whatever you like, but keep in mind my tweaks when you try to build your local copy.

So, with the qualifiers in mind…

1. Prepping The System (apt-get)

There are few things better than being able to apt-get everything you need to prep your machine for an install, and I’m pleased to report that the (current) process for putting the important files onto Ubuntu 12.X/13.X is easy. Assuming you’re not going the Intel / PGI / MKL route, you can do everything by installing gfortran (compiler, presently installing 4.4) and the blas and atlas math libraries.

username@machinename:~$ sudo apt-get install gfortran libblas-dev libatlas-base-dev

Note: your atlas libraries will be installed in /usr/lib64/atlas/ – this will matter when you run config.

After these finish, run the following to determine your installed gfortran version (will be asked for by the new GAMESS config)

username@machinename:~$ gfortran -dumpversion

GNU Fortran (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3 Copyright (C) 2010 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING

4.4 And you’re ready for GAMESS.

2. Downloading GAMESS-US, Placing Into /opt, And Changing Permissions

First, obviously, get the GAMESS source (click on the red text).

After downloading, copy/move gamess-current.tar.gz into /opt

username@machinename:~$ cd ~/Downloads
username@machinename:~/Downloads$ sudo cp gamess-current.tar.gz /opt
username@machinename:~/Downloads$ cd /opt
username@machinename:/opt$ sudo gunzip gamess-cuerent.tar.gz
username@machinename:/opt$ sudo tar xvd gamess-current.tar

gamess/ gamess/gms-files.csh gamess/tools/ ... gamess/misc/count.code gamess/misc/vbdum.src gamess/Makefile.in

At this point, if you go through the config process and get to the point of building ddikick.x, you will get an error when you first try to run ./compddi

username@machinename:/opt/gamess/ddi$ sudo ./compddi >& compddi.log &
[1] 4622 -bash: compddi.log: Permission denied

The problem is with the permission of the entire gamess folder:

drwxr-xr-x  4 root        root              4096 2014-04-04 21:43 . drwxr-xr-x 22 root        root              4096 2013-12-27 16:17 .. drwxr-xr-x 14 1300 504              4096 2014-04-04 21:43 gamess -rw-r--r-- 1 root        root         198481920 2014-04-04 21:42 gamess-current.tar

Which you remedy before running into this error by changing the permissions:

username@machinename:/opt$ sudo chown -R username gamess

The next step is recommended when you run config, so I’m performing the step here to get it out of the way. With the atlas libraries installed, generate two symbolic links.

username@machinename:/opt$ cd /usr/lib64/atlas
username@machinename:/usr/lib64/atlas$ sudo ln -s libf77blas.so.3.0 libf77blas.so
username@machinename:/usr/lib64/atlas$ sudo ln -s libatlas.so.3.0 libatlas.so

And, at this point, you’re ready to run the new (well, new to me) config script that preps your system install.

3. Building GAMESS-US

Back to the GAMESS-US folder.

username@machinename:/usr/lib64/atlas$ cd /opt/gamess
username@machinename:/opt/gamess$ sudo ./config
This script asks a few questions, depending on your computer system, to set up compiler names, libraries, message passing libraries, and so forth. You can quit at any time by pressing control-C, and then . Please open a second window by logging into your target machine, in case this script asks you to 'type' a command to learn something about your system software situation. All such extra questions will use the word 'type' to indicate it is a command for the other window. After the new window is open, please hit to go on.

You can open that second window or blindly assume that what I include below is all you need.

[enter]

GAMESS can compile on the following 32 bit or 64 bit machines: axp64 - Alpha chip, native compiler, running Tru64 or Linux cray-xt - Cray's massively parallel system, running CNL hpux32 - HP PA-RISC chips (old models only), running HP-UX hpux64 - HP Intel or PA-RISC chips, running HP-UX ibm32 - IBM (old models only), running AIX ibm64 - IBM, Power3 chip or newer, running AIX or Linux ibm64-sp - IBM SP parallel system, running AIX ibm-bg - IBM Blue Gene (P or L model), these are 32 bit systems linux32 - Linux (any 32 bit distribution), for x86 (old systems only) linux64 - Linux (any 64 bit distribution), for x86_64 or ia64 chips AMD/Intel chip Linux machines are sold by many companies mac32 - Apple Mac, any chip, running OS X 10.4 or older mac64 - Apple Mac, any chip, running OS X 10.5 or newer sgi32 - Silicon Graphics Inc., MIPS chip only, running Irix sgi64 - Silicon Graphics Inc., MIPS chip only, running Irix sun32 - Sun ultraSPARC chips (old models only), running Solaris sun64 - Sun ultraSPARC or Opteron chips, running Solaris win32 - Windows 32-bit (Windows XP, Vista, 7, Compute Cluster, HPC Edition) win64 - Windows 64-bit (Windows XP, Vista, 7, Compute Cluster, HPC Edition) winazure - Windows Azure Cloud Platform running Windows 64-bit type 'uname -a' to partially clarify your computer's flavor. please enter your target machine name:

We’re doing a linux64 build, so type the following at the prompt:

linux64
Where is the GAMESS software on your system? A typical response might be /u1/mike/gamess, most probably the correct answer is /opt/gamess GAMESS directory? [/opt/gamess]

Who is this mike and where is my folder u1? We’ll get to that in rungms. For now, I’m installing in /opt, so the default directory is fine:

[enter]

Setting up GAMESS compile and link for GMS_TARGET=linux64 GAMESS software is located at GMS_PATH=/opt/gamess Please provide the name of the build locaation. This may be the same location as the GAMESS directory. GAMESS build directory? [/opt/gamess]

Fine as selected.

[enter]

Please provide a version number for the GAMESS executable. This will be used as the middle part of the binary's name, for example: gamess.00.x Version? [00]

Is this important? Maybe, if you plan on building multiple versions of GAMESS-US (you might want a GPU-friendly version, one with a different compiler, one with MPI, etc.). Number as you wish and remember the number when it comes to rungms. That said, the actual linking step seems to really want to produce a 01 version (we’ll get to that). Meantime, default value is fine.

[enter]

Linux offers many choices for FORTRAN compilers, including the GNU compiler set ('g77' in old versions of Linux, or 'gfortran' in current versions), which are included for free in Unix distributions. There are also commercial compilers, namely Intel's 'ifort', Portland Group's 'pgfortran', and Pathscale's 'pathf90'. The last two are not common, and aren't as well tested as the others. type 'rpm -aq | grep gcc' to check on all GNU compilers, including gcc type 'which gfortran' to look for GNU's gfortran (a very good choice), type 'which g77' to look for GNU's g77, type 'which ifort' to look for Intel's compiler, type 'which pgfortran' to look for Portland Group's compiler, type 'which pathf90' to look for Pathscale's compiler. Please enter your choice of FORTRAN:

We’re using gfortran (currently 4.4.3):

gfortran

gfortran is very robust, so this is a wise choice. Please type 'gfortran -dumpversion' or else 'gfortran -v' to detect the version number of your gfortran. This reply should be a string with at least two decimal points, such as 4.1.2 or 4.6.1, or maybe even 4.4.2-12. The reply may be labeled as a 'gcc' version, but it is really your gfortran version. Please enter only the first decimal place, such as 4.1 or 4.6:
4.4

Alas, your version of gfortran does not support REAL*16, so relativistic integrals cannot use quadruple precision. Other than this, everything will work properly. hit to continue to the math library setup.

If this was my biggest concern I’d be a happy quantum chemist. Obviously you can try to install other flavors of gfortran and, possibly, by the time you need the procedure I’m following, a newer version of gfortran will be apt-gotten.

[enter]

Linux distributions do not include a standard math library. There are several reasonable add-on library choices, MKL from Intel for 32 or 64 bit Linux (very fast) ACML from AMD for 32 or 64 bit Linux (free) ATLAS from www.rpmfind.net for 32 or 64 bit Linux (free) and one very unreasonable option, namely 'none', which will use some slow FORTRAN routines supplied with GAMESS. Choosing 'none' will run MP2 jobs 2x slower, or CCSD(T) jobs 5x slower. Some typical places (but not the only ones) to find math libraries are Type 'ls /opt/intel/mkl' to look for MKL Type 'ls /opt/intel/Compiler/mkl' to look for MKL Type 'ls /opt/intel/composerxe/mkl' to look for MKL Type 'ls -d /opt/acml*' to look for ACML Type 'ls -d /usr/local/acml*' to look for ACML Type 'ls /usr/lib64/atlas' to look for Atlas Enter your choice of 'mkl' or 'atlas' or 'acml' or 'none':
atlas

Where is your Atlas math library installed? A likely place is /usr/lib64/atlas Please enter the Atlas subdirectory on your system:

Our location is, in fact, /usr/lib64/atlas, so we type it in accordingly.

NOTE: If you don’t type anything but [enter] below, the script closes (/usr/lib64/atlas is listed as the expected location, but it is not defaulted by the script. You need to type it in.

/usr/lib64/atlas
 
The linking step in GAMESS assumes that a softlink exists within the system's /usr/lib64/atlas from libatlas.so to a specific file like libatlas.so.3.0 from libf77blas.so to a specific file like libf77blas.so.3.0 config can carry on for the moment, but the 'root' user should chdir /usr/lib64/atlas ln -s libf77blas.so.3.0 libf77blas.so ln -s libatlas.so.3.0 libatlas.so prior to the linking of GAMESS to a binary executable. Math library 'atlas' will be taken from /usr/lib64/atlas please hit to compile the GAMESS source code activator

The symbolic linking was performed before the GAMESS steps.

[enter]

gfortran -o /home/username/gamess/tools/actvte.x actvte.f unset echo Source code activator was successfully compiled. please hit to set up your network for Linux clusters.
[enter]

If you have a slow network, like Gigabit Ethernet (GE), or if you have so few nodes you won't run extensively in parallel, or if you have no MPI library installed, or if you want a fail-safe compile/link and easy execution, choose 'sockets' to use good old reliable standard TCP/IP networking. If you have an expensive but fast network like Infiniband (IB), and if you have an MPI library correctly installed, choose 'mpi'. communication library ('sockets' or 'mpi')?

Again, I’m not building an mpi-friendly version, so am using sockets.

sockets

64 bit Linux builds can attach a special LIBCCHEM code for fast MP2 and CCSD(T) runs. The LIBCCHEM code can utilize nVIDIA GPUs, through the CUDA libraries, if GPUs are available. Usage of LIBCCHEM requires installation of HDF5 I/O software as well. GAMESS+LIBCCHEM binaries are unable to run most of GAMESS computations, and are a bit harder to create due to the additional CUDA/HDF5 software. Therefore, the first time you run 'config', the best answer is 'no'! If you decide to try LIBCCHEM later, just run this 'config' again. Do you want to try LIBCCHEM? (yes/no):
no

Your configuration for GAMESS compilation is now in /home/username/gamess/install.info Now, please follow the directions in /home/username/gamess/machines/readme.unix username@machinename:~/gamess$

At this stage, you’re ready to build ddikick.x and continue with the compiling.

4. Build ddikick.x

username@machinename:/opt/gamess$ cd ddi
username@machinename:/opt/gamess/ddi$ sudo ./compddi >& compddi.log &

Will dump output into compddi.log (which will now work with the correct permissions).

username@machinename:/opt/gamess/ddi$ sudo mv ddikick.x ..
username@machinename:/opt/gamess/ddi$ cd ..
username@machinename:/opt/gamess$ sudo ./compall >& compall.log &

Feel free to follow along as compall.log dumps results. You’re also welcome to follow the readme.unix advice:

This takes a while, so go for coffee, or check the SF Giants web page.

Upon completion, the last step is to link the executable.

Now, it used to be the case that you specified the version number in the lked step. So, if you wanted to stick with the 00 version from the config file, you’d type

username@machinename:/opt/gamess$ sudo ./lked gamess 00 >& lked.log &

When you do that at present, you get

[1] 7626 username@machinename:/opt/gamess$ [1]+ Stopped sudo ./lked gamess 00 &>lked.log

This then leads you to use the lked call from the readme.unix file.

username@machinename:/opt/gamess$ sudo ./lked gamess 01 >& lked.log &

Which then produces lked.log and gamess.01.x.

Now, if you run with 00 again, you get a successful linking of gamess.00.x . Not sure why this happens, but the version number isn’t important so long as you specify the right one when you use rungms (so I’ve not diagnosed it further).

At this point, you have a gamess.00.x and/or gamess.01.x executable in your /opt/gamess folder:

30828747 2014-04-04 22:41 gamess.01.x

I’m going to ignore the 00 issue out of the config file and use the gamess.01.x executable.

We’re ready to run calculations and work through the next set of errors you’ll receive if you don’t properly modify files.

5. PATH Setting

First, we copy rungms to our home folder, then add /opt/gamess to the PATH:

username@machinename:/opt/gamess$ cp rungms ~/
username@machinename:/opt/gamess$ cd ~/
username@machinename:~$ nano .bashrc

Add the following to the bottom of .bashrc (or extend your PATH)

PATH=$PATH:/opt/gamess

Quit nano and source.

username@machinename:~$ source .bashrc
[OPTIONAL] username@machinename:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:.../opt/gamess:

6. rungms (Probably Why You’re Here)

If you just go blindly into a run, you’ll get the following error:

username@machinename:~$ ./rungms test.inp

----- GAMESS execution script 'rungms' ----- This job is running on host machinename under operating system Linux at Fri Apr 4 22:47:55 EDT 2014 Available scratch disk space (Kbyte units) at beginning of the job is df: `/scr/username': No such file or directory df: no file systems processed GAMESS temporary binary files will be written to /scr/username GAMESS supplementary output files will be written to /home/username/scr Copying input file test.inp to your run's scratch directory... cp test.inp /scr/username/test.F05 cp: cannot create regular file `/scr/username/test.F05': No such file or directory unset echo /u1/mike/gamess/gms-files.csh: No such file or directory.

As is obvious, rungms needs some modifying.

username@machinename:~$ nano rungms

Scroll down until you see the following:

set TARGET=sockets set SCR=/scr/$USER set USERSCR=~$USER/scr set GMSPATH=/u1/mike/gamess

Given that it’s just me on the machine, I tend to simplify this by making SCR and USERSCR the same directory, and I make them both /tmp. If you intend on keeping all of the files, you’ll need to make rungms specific for each run case. My only concerns are .dat and .log, so /tmp dumping is fine. Furthermore, we must change GMSPATH from how the ever-helpful Mike Schmidt (he got me through some early issues when I started my GAMESS-US adventure 15ish years ago. Won’t complain about his continued default-ed presence in the scripts) has it set up at Iowa to how we want it on our own machines (in my case, /opt/gamess)

set TARGET=sockets set SCR=/tmp set USERSCR=/tmp set GMSPATH=/opt/gamess

With these modifications, your next run will be a bit more successful:

username@machinename:~$ ./rungms test.inp

----- GAMESS execution script 'rungms' ----- This job is running on host machinename under operating system Linux at Fri Apr 4 22:51:35 EDT 2014 Available scratch disk space (Kbyte units) at beginning of the job is Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda2 1905222596 249225412 1559217460 14% / GAMESS temporary binary files will be written to /tmp GAMESS supplementary output files will be written to /tmp Copying input file test.inp to your run's scratch directory... cp test.inp /tmp/test.F05 unset echo /opt/gamess/ddikick.x /opt/gamess/gamess.00.x test -ddi 1 1 machinename -scr /tmp Distributed Data Interface kickoff program. Initiating 1 compute processes on 1 nodes to run the following command: /opt/gamess/gamess.00.x test ****************************************************** * GAMESS VERSION = 1 MAY 2013 (R1) * * FROM IOWA STATE UNIVERSITY * * M.W.SCHMIDT, K.K.BALDRIDGE, J.A.BOATZ, S.T.ELBERT, * * M.S.GORDON, J.H.JENSEN, S.KOSEKI, N.MATSUNAGA, * * K.A.NGUYEN, S.J.SU, T.L.WINDUS, * * TOGETHER WITH M.DUPUIS, J.A.MONTGOMERY * * J.COMPUT.CHEM. 14, 1347-1363(1993) * **************** 64 BIT LINUX VERSION **************** ... INPUT CARD> DDI Process 0: shmget returned an error. Error EINVAL: Attempting to create 160525768 bytes of shared memory. Check system limits on the size of SysV shared memory segments. The file ~/gamess/ddi/readme.ddi contains information on how to display the current SystemV memory settings, and how to increase their sizes. Increasing the setting requires the root password, and usually a sytem reboot. DDI Process 0: error code 911 ddikick.x: application process 0 quit unexpectedly. ddikick.x: Fatal error detected. The error is most likely to be in the application, so check for input errors, disk space, memory needs, application bugs, etc. ddikick.x will now clean up all processes, and exit... ddikick.x: Sending kill signal to DDI processes. ddikick.x: Execution terminated due to error(s). unset echo ----- accounting info ----- Files used on the master node machinename were: -rw-r--r-- 1 username username 0 2014-04-04 22:51 /tmp/test.dat -rw-r--r-- 1 username username 1341 2014-04-04 22:51 /tmp/test.F05 ls: No match. ls: No match. ls: No match. Fri Apr 4 22:51:36 EDT 2014 0.0u 0.0s 0:01.08 9.2% 0+0k 0+8io 0pf+0w

Things worked, but with a memory error. This issue is discussed at the Baldridge Group wiki: ocikbapps.uzh.ch/kbwiki/gamess_troubleshooting.html

From the wiki:

If you are sure you are not asking for too much memory in the input file, check that your kernel parameters are not allowing enough memory to be requested. You might have to increase the SHMALL & SHMAX kernel memory values to allow GAMESS to run. (See http://www.pythian.com/news/245/the-mysterious-world-of-shmmax-and-shmall/ for a better explanation.)
For example, on a machine with 4GB of memory, you might add these to /etc/sysctl.conf:
# cat /etc/sysctl.conf | grep shm
kernel.shmmax = 3064372224
kernel.shmall = 748137
Then set the new settings like so:
# sysctl -p
Since they are in /etc/sysctl.conf, they will automatically be set each time the system is booted.

In our case, we modify sysctl.conf with the recommendations from the wiki:

username@machinename:~$ sudo nano /etc/sysctl.conf

Add the following to the bottom of the file:

kernel.shmmax = 3064372224 kernel.shmall = 748137

Save and exit.

username@machinename:~$ sudo sysctl -p

net.ipv4.ip_forward = 1 kernel.shmmax = 3064372224 kernel.shmall = 748137

These memory values will change depending on your system.

Now we empty the /tmp and rerun.

username@machinename:~$ rm /tmp/*
username@machinename:~$ ./rungms test.inp

If your input file is worth it’s salt, you’ll have successfully run your file on a single processor (single core, that is). If you run into additional memory errors, increase kernel.shmmax and kernel.shmall.

Now, onto the SMP part. My first attempt to run games in parallel (on 4 cores using version 00) produced the following error:

username@machinename:~$ rm /tmp/*
username@machinename:~$ ./rungms test.inp 00 4

----- GAMESS execution script 'rungms' ----- This job is running on host machinename under operating system Linux at Fri Apr 4 22:52:52 EDT 2014 Available scratch disk space (Kbyte units) at beginning of the job is Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda2 1905222596 249225416 1559217456 14% / GAMESS temporary binary files will be written to /tmp GAMESS supplementary output files will be written to /tmp Copying input file test.inp to your run's scratch directory... cp test.inp /tmp/test.F05 unset echo I do not know how to run this node in parallel.

I tried a number of stupid things to get the run to work, finally settling on modifying the rungms file properly. To make gamess know how to run the node in parallel, we need only make the following changes to our rungms file.

username@machinename:~$ nano rungms

Scroll down until you find the section below:

# 2. This is an example of how to run on a multi-core SMP enclosure, # where all CPUs (aka COREs) are inside a -single- NODE. # At other locations, you may wish to consider some of the examples # that follow below, after commenting out this ISU specific part. if ($NCPUS > 1) then switch (`hostname`) case se.msg.chem.iastate.edu: case sb.msg.chem.iastate.edu: if ($NCPUS > 2) set NCPUS=4 set NNODES=1

The change is simple. We remove the cases for $NCPUS > 1 in the file and add the hostname of our linux box (and if you don’t know this or it’s not in your prompt, simply type hostname at the prompt first). We’ll disable the two cases listed and add our hostname to the case list.

# 2. This is an example of how to run on a multi-core SMP enclosure, # where all CPUs (aka COREs) are inside a -single- NODE. # At other locations, you may wish to consider some of the examples # that follow below, after commenting out this ISU specific part. if ($NCPUS > 1) then switch (`hostname`) case machinename: # case se.msg.chem.iastate.edu: # case sb.msg.chem.iastate.edu: if ($NCPUS > 2) set NCPUS=4 set NNODES=1

This gives you parallel functionality, but it’s still not using the machine resources (cores) correctly when I ask for anything more than 2 cores (always using only 2 cores).

[minor complaint]
Admittedly, I don’t immediately get the logic of this section as currently coded, as one cannot get more than 2 cores to work in this case given how the if statements are written (so far as I can see now. I will assume I am the one missing something but have not decided to ask about it, instead changing the rungms text to the following). You can check this yourself by running top in another window. This is the most simple modification, and assumes you want to run N number of cores each time. Clearly, you can make this more elegant than it is (my modification, that is). Meantime, I want to run 4 cores on this machine, so I change the section to reflect a 4-core board (and commented out much of this section).
[/complaint]

# 2. This is an example of how to run on a multi-core SMP enclosure, # where all CPUs (aka COREs) are inside a -single- NODE. # At other locations, you may wish to consider some of the examples # that follow below, after commenting out this ISU specific part. if ($NCPUS > 1) then switch (`hostname`) case machinename # case se.msg.chem.iastate.edu: # case sb.msg.chem.iastate.edu: # if ($NCPUS > 2) set NCPUS=2 # set NNODES=1 # set HOSTLIST=(`hostname`:cpus=$NCPUS) # breaksw # case machinename # case br.msg.chem.iastate.edu: if ($NCPUS >= 4) set NCPUS=4 set NNODES=1 set HOSTLIST=(`hostname`:cpus=$NCPUS) breaksw case machinename # case cd.msg.chem.iastate.edu: # case zn.msg.chem.iastate.edu: # case ni.msg.chem.iastate.edu: # case co.msg.chem.iastate.edu: # case pb.msg.chem.iastate.edu: # case bi.msg.chem.iastate.edu: # case po.msg.chem.iastate.edu: # case at.msg.chem.iastate.edu: # case sc.msg.chem.iastate.edu: # if ($NCPUS > 4) set NCPUS=4 # set NNODES=1 # set HOSTLIST=(`hostname`:cpus=$NCPUS) # breaksw # case ga.msg.chem.iastate.edu: # case ge.msg.chem.iastate.edu: # case gd.msg.chem.iastate.edu: # if ($NCPUS > 6) set NCPUS=6 # set NNODES=1 # set HOSTLIST=(`hostname`:cpus=$NCPUS) # breaksw default: echo I do not know how to run this node in parallel. exit 20 endsw endif #

And, with this set of changes, I’m using all 4 cores on the board (but have some significant memory issues when running MP2 calks. But that’s for another post).

The typical user will never be able to do what the GAMESS group has done in making an excellent program that also happens to be free. That said, the need to make changes to the rungms file is something that would be greatly simplified by having N number of rungms scripts for each case instead of a monolithic file that is mostly useless text to users not using one of the system types. This, for instance, would make rungms modification much easier. If I streamline rungms for my specific system, I may post a new file accordingly.

CudaMiner Installation In Ubuntu 12.04 LTS Using CUDA Toolkit 5.5 And “Additional NVIDIA Drivers”

December 28th, 2013

Author’s Note 1: It is my standard policy to put too much info into guides so that those who are searching for specific problems they come across will find the offending text in their searches. With luck, your “build error” search sent you here.

Author’s Note 2: It’s not as bad as it looks (I’ve included lots of output and error messages for easy searching)!

Author’s Note 3: I won’t be much help for you in diagnosing your errors, but am happy to tweak the text below if something is unclear.

Conventions: I include both the commands you type in your Terminal and some of the output from these commands, the output being where most of the errors appear that I work on in the discussion.

Input is formatted as below:

Text you put in (copy + paste should be fine)

Output is formatted as below:

Text you get out (for checking results and reproducing errors)

1. Introduction

This work began as an attempt to build a CUDA-friendly version of the molecular dynamics package GROMACS (which will come later) but, for reasons stemming from a new local Syracuse Meetup Group (Bitcoin’s of New York – Miner’s of Syracuse. Consider joining!), the formation of our very own local mining pool (Salt City Miners, miner.saltcityminers.com. Consider joining!), plus a “what the hell” to see if it was an easy build or not, transformed into the CudaMiner-centric compiling post you see here.

NOTE: This will be a 64-bit-centric install but I’ll include 32-bit content as I’ve found the info on other sites.

2. Installing The NVIDIA Drivers (Two Methods, The Easy One Described)

Having run through this process many times in a fresh install of Ubuntu 12.04 LTS (so nothing else is on the machine except 12.04 LTS, its updates, a few extra installs, and the CUDA/CudaMiner codes), I can say that what is below should work without hitch AFTER you install the NVIDIA drivers. Once your NVIDIA card is installed and Ubuntu recognizes it, you’ve two options.

2A. Install The Drivers From An NVIDIA Download (The Hard Version)

A few websites (and several repostings of the same content) describe the process of installing the NVIDIA drivers the olde-fashioned way, in which you’ll see references to “blacklist nouveau,” “sudo service lightdm stop,” Ctrl+Alt+F1 (to get you to a text-only session), etc. You hopefully don’t need to do this much work for your own NVIDIA install, as Ubuntu will do it for you (with only one restart required).

2B. Install The Drivers After The “Restricted Drivers Available” Pop-Up Or Go To System Settings > Available Drivers (The Easy, Teenage New York Version)

I took the easy way out by letting Ubuntu do the dirty work. The result is the installation of the (currently, as of 28 Dec 2013) v. 319 NVIDIA accelerated graphics driver. For my NVIDIA cards (GTX 690 and a GTX 650 Ti, although I assume it’s similar for a whole class of NVIDIA cards), you’re (currently, check the date again) given the option of v. 304. Don’t! I’ve seen several mentions of CudaMiner (and some of the cuds toolkit) requiring v. 319.

2013dec28_nvidia_1

Caption: You may see it in the upper right (after an install or if you’ve not clicked on it before)

2013dec28_nvidia_2

Caption: Or System Settings > Additional Drivers

2013dec28_nvidia_3

Caption: Either way, you’ll hopefully get to an NVIDIA driver list like above.

3. Pre-CUDA Toolkit Install

There are a few apt-get’s you need to do before installing the CUDA Toolkit (or, at least, the consensus is that these must be done. I’ve not seen a different list in any posts and I didn’t bother to install one-by-one to see which of these might not be needed).

If you perform the most commonly posted apt-get (plus and update and upgrade if you’ve not done so lately):

user@host:~/$ sudo apt-get update
user@host:~/$ sudo apt-get upgrade
user@host:~/$ sudo apt-get install freeglut3-dev build-essential libx11-dev libxmu-dev libxi-dev libgl1-mesa-glx libglu1-mesa libglu1-mesa-dev

You’ll get the following error from a fresh 12.04 LTS install:

Reading package lists… Done
Building dependency tree
Reading state information… Done
libglu1-mesa is already the newest version.
libglu1-mesa set to manually installed.
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
libgl1-mesa-glx : Depends: libglapi-mesa (= 8.0.4-0ubuntu0.6)
Recommends: libgl1-mesa-dri (>= 7.2)
E: Unable to correct problems, you have held broken packages.

The solution here is simple. Add libglapi-mesa and libgl1-mesa-dri to your install.

user@host:~/$ sudo apt-get install freeglut3-dev build-essential libx11-dev libxmu-dev libxi-dev libgl1-mesa-glx libglu1-mesa libglu1-mesa-dev libglapi-mesa libgl1-mesa-dri

Doing this will add a bunch of programs and libraries (listed below):

The following extra packages will be installed:
dpkg-dev freeglut3 g++ g++-4.6 libalgorithm-diff-perl libalgorithm-diff-xs-perl
libalgorithm-merge-perl libdpkg-perl libdrm-dev libgl1-mesa-dev libice-dev libkms1 libllvm3.0
libpthread-stubs0 libpthread-stubs0-dev libsm-dev libstdc++6-4.6-dev libtimedate-perl libx11-doc
libxau-dev libxcb1-dev libxdmcp-dev libxext-dev libxmu-headers libxt-dev mesa-common-dev
x11proto-core-dev x11proto-input-dev x11proto-kb-dev x11proto-xext-dev xorg-sgml-doctools
xserver-xorg xserver-xorg-core xserver-xorg-input-evdev xtrans-dev
Suggested packages:
debian-keyring g++-multilib g++-4.6-multilib gcc-4.6-doc libstdc++6-4.6-dbg libglide3
libstdc++6-4.6-doc libxcb-doc xfonts-100dpi xfonts-75dpi
The following packages will be REMOVED:
libgl1-mesa-dri-lts-raring libgl1-mesa-glx-lts-raring libglapi-mesa-lts-raring
libxatracker1-lts-raring x11-xserver-utils-lts-raring xserver-common-lts-raring
xserver-xorg-core-lts-raring xserver-xorg-input-all-lts-raring xserver-xorg-input-evdev-lts-raring
xserver-xorg-input-mouse-lts-raring xserver-xorg-input-synaptics-lts-raring
xserver-xorg-input-vmmouse-lts-raring xserver-xorg-input-wacom-lts-raring xserver-xorg-lts-raring
xserver-xorg-video-all-lts-raring xserver-xorg-video-ati-lts-raring
xserver-xorg-video-cirrus-lts-raring xserver-xorg-video-fbdev-lts-raring
xserver-xorg-video-intel-lts-raring xserver-xorg-video-mach64-lts-raring
xserver-xorg-video-mga-lts-raring xserver-xorg-video-modesetting-lts-raring
xserver-xorg-video-neomagic-lts-raring xserver-xorg-video-nouveau-lts-raring
xserver-xorg-video-openchrome-lts-raring xserver-xorg-video-r128-lts-raring
xserver-xorg-video-radeon-lts-raring xserver-xorg-video-s3-lts-raring
xserver-xorg-video-savage-lts-raring xserver-xorg-video-siliconmotion-lts-raring
xserver-xorg-video-sis-lts-raring xserver-xorg-video-sisusb-lts-raring
xserver-xorg-video-tdfx-lts-raring xserver-xorg-video-trident-lts-raring
xserver-xorg-video-vesa-lts-raring xserver-xorg-video-vmware-lts-raring
The following NEW packages will be installed:
build-essential dpkg-dev freeglut3 freeglut3-dev g++ g++-4.6 libalgorithm-diff-perl
libalgorithm-diff-xs-perl libalgorithm-merge-perl libdpkg-perl libdrm-dev libgl1-mesa-dev
libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libglu1-mesa-dev libice-dev libkms1 libllvm3.0
libpthread-stubs0 libpthread-stubs0-dev libsm-dev libstdc++6-4.6-dev libtimedate-perl libx11-dev
libx11-doc libxau-dev libxcb1-dev libxdmcp-dev libxext-dev libxi-dev libxmu-dev libxmu-headers
libxt-dev mesa-common-dev x11proto-core-dev x11proto-input-dev x11proto-kb-dev x11proto-xext-dev
xorg-sgml-doctools xserver-xorg xserver-xorg-core xserver-xorg-input-evdev xtrans-dev

And, remarkably, that’s it for the pre-install.

4. CUDA Toolkit 5.5(.22) Install

The CUDA Toolkit install starts with its 810 MB download at developer.NVIDIA.com/cuda-downloads.

Obviously, be aware of the 32- and 64-bit options. Also, the .deb doesn’t currently download, leaving you to grab the .run file (same difference, I haven’t bothered to find out why the .deb doesn’t fly yet).

Off to your Terminal and into the Downloads folder:

user@host:~/$ cd Downloads
user@host:~/Downloads$ chmod +x cuda_5.5.22_linux_64.run
user@host:~/Downloads$ sudo ./cuda_5.5.22_linux_64.run

Which will produce:

Logging to /tmp/cuda_install_14755.log
Using more to view the EULA.
End User License Agreement
————————–
. . .
and cannot be linked to any personally identifiable
information. Personally identifiable information such as your
username or hostname is not collected.

————————————————————-

Finally, some input to be had after the scrolling:

Do you accept the previously read EULA? (accept/decline/quit): accept     
Install NVIDIA Accelerated Graphics Driver for Linux-x86_64 319.37? ((y)es/(n)o/(q)uit): n
Install the CUDA 5.5 Toolkit? ((y)es/(n)o/(q)uit): y
Enter Toolkit Location [ default is /usr/local/cuda-5.5 ]: 
Install the CUDA 5.5 Samples? ((y)es/(n)o/(q)uit): y
Enter CUDA Samples Location [ default is /home/user/NVIDIA_CUDA-5.5_Samples ]: 

NOTE 1: Don’t install the NVIDIA Accelerated Graphics Driver!
NOTE 2: Yes, install the Toolkit.
NOTE 3: I will assume this location for all of the below, setting the location in the PATH.
NOTE 4: I installed the samples for testing (and found a few extra things that need installation for them).
NOTE 5: Default is fine. Once built and tested, can be deleted (although the Mandelbrot is a keeper)

Installing the CUDA Toolkit in /usr/local/cuda-5.5 …
Installing the CUDA Samples in /home/user/NVIDIA_CUDA-5.5_Samples …
Copying samples to /home/user/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples now…
Finished copying samples.

===========
= Summary =
===========

Driver: Not Selected
Toolkit: Installed in /usr/local/cuda-5.5
Samples: Installed in /home/user/NVIDIA_CUDA-5.5_Samples

* Please make sure your PATH includes /usr/local/cuda-5.5/bin

* Please make sure your LD_LIBRARY_PATH
* for 32-bit Linux distributions includes /usr/local/cuda-5.5/lib
* for 64-bit Linux distributions includes /usr/local/cuda-5.5/lib64:/lib
* OR
* for 32-bit Linux distributions add /usr/local/cuda-5.5/lib
* for 64-bit Linux distributions add /usr/local/cuda-5.5/lib64 and /lib
* to /etc/ld.so.conf and run ldconfig as root

* To uninstall CUDA, remove the CUDA files in /usr/local/cuda-5.5
* Installation Complete

Please see CUDA_Getting_Started_Linux.pdf in /usr/local/cuda-5.5/doc/pdf for detailed information on setting up CUDA.

***WARNING: Incomplete installation! This installation did not install the CUDA Driver. A driver of version at least 319.00 is required for CUDA 5.5 functionality to work.
To install the driver using this installer, run the following command, replacing with the name of this run file:
sudo
.run -silent -driver

Logfile is /tmp/cuda_install_14755.log

And ignore the WARNING.

As per the “make sure” above, add the CUDA distro folders to your path and LD_LIBRARY_PATH (I chose not to modify ld.so.conf)

user@host:~/Downloads$ cd
user@host:~/$ nano .bashrc

Add the PATH and LD_LIBRARY_PATH as follows:

PATH=$PATH:/usr/local/cuda-5.5/bin
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda-5.5/lib64:/lib

And then source the .bashrc file.

user@host:~/$ source .bashrc

5. NVIDIA_CUDA-5.5_Samples (And Finishing The Toolkit Install To Build CudaMiner)

The next set of installs and file modifications came from attempting to build the Samples in the NVIDIA_CUDA-5.5_Samples (or NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples depending on how your install did it) library, during which time I think I managed to hit all of the post-Toolkit install modifications needed to make the CudaMiner build problem-free. The OpenMPI install is optional, but I do hate error messages.

5A. Error 1: /usr/bin/ld: cannot find -lcuda

My first make attempt produced the following error:

user@host:~/$ cd NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples
user@host:~/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples$ make

make[1]: Entering directory `/home/user/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples/0_Simple/asyncAPI’
“/usr/local/cuda-5.5″/bin/nvcc -ccbin g++ -I../../common/inc -m64 -gencode arch=compute_10,code=sm_10 -gencode arch=compute_20,code=sm_20 -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=\”sm_35,compute_35\” -o asyncAPI.o -c asyncAPI.cu
. . .
“/usr/local/cuda-5.5″/bin/nvcc -ccbin g++ -I../../common/inc -m64 -o vectorAddDrv.o -c vectorAddDrv.cpp
“/usr/local/cuda-5.5″/bin/nvcc -ccbin g++ -m64 -o vectorAddDrv vectorAddDrv.o -L/usr/lib/NVIDIA-current -lcuda
/usr/bin/ld: cannot find -lcuda
collect2: ld returned 1 exit status
make[1]: *** [vectorAddDrv] Error 1
make[1]: Leaving directory `/home/user/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples/0_Simple/vectorAddDrv’
make: *** [0_Simple/vectorAddDrv/Makefile.ph_build] Error 2

This is solved by making a symbolic link for libcuda.so out of /usr/lib/NVIDIA-319/ and into /usr/lib/

NOTE: It doesn’t matter what directory you do this from. I’ve left off the NVIDIA_CUDA-5.5_Samples/ yadda yadda below.

user@host:~/$ sudo ln -s /usr/lib/NVIDIA-319/libcuda.so /usr/lib/libcuda.so

If you’re working through the build process and hit the error, run a “make clean” before rerunning.

5B. WARNING – No MPI compiler found.

The second build attempt produced the MPI Warning above.

user@host:~/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples$ make

make[1]: Entering directory `/home/user/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples/0_Simple/asyncAPI’
“/usr/local/cuda-5.5″/bin/nvcc -ccbin g++ -I../../common/inc -m64 -gencode arch=compute_10,code=sm_10 -gencode arch=compute_20,code=sm_20 -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=\”sm_35,compute_35\” -o asyncAPI.o -c asyncAPI.cu
“/usr/local/cuda-5.5″/bin/nvcc -ccbin g++ -m64 -o asyncAPI asyncAPI.o
. . .
cp simpleCubemapTexture ../../bin/x86_64/linux/release
make[1]: Leaving directory `/home/user/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples/0_Simple/simpleCubemapTexture’
———————————————————————————————–
WARNING – No MPI compiler found.
———————————————————————————————–
CUDA Sample “simpleMPI” cannot be built without an MPI Compiler.
This will be a dry-run of the Makefile.
For more information on how to set up your environment to build and run this
sample, please refer the CUDA Samples documentation and release notes
———————————————————————————————–
make[1]: Entering directory `/home/user/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples/0_Simple/simpleMPI’
[@] mpicxx -I../../common/inc -o simpleMPI.o -c simpleMPI.cpp
. . .
mkdir -p ../../bin/x86_64/linux/release
cp histEqualizationNPP ../../bin/x86_64/linux/release
make[1]: Leaving directory `/home/user/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples/7_CUDALibraries/histEqualizationNPP’
Finished building CUDA samples

But otherwise finishes successfully.

To get around this warning, install OpenMPI (which is needed for multi-board GROMACS runs anyway. But, again, not needed for CudaMiner). The specific issue is the need for mpicc, which is in libopenmpi-dev (not openmpi-bin or openmpi-common).

user@host:~/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples$ mpicc
The program ‘mpicc’ can be found in the following packages:
* lam4-dev
* libmpich-mpd1.0-dev
* libmpich-shmem1.0-dev
* libmpich1.0-dev
* libmpich2-dev
* libopenmpi-dev
* libopenmpi1.5-dev
Try: sudo apt-get install

For completeness, I grab all three (and I’m ingnoring the NVIDIA_CUDA-5.5_Samples directory structure below).

user@host:~/$ sudo apt-get install openmpi-bin openmpi-common libopenmpi-dev

Running mpicc will now produce the following (so it’s there):

user@host:~/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples$ mpicc
gcc: fatal error: no input files
compilation terminated.

Now run a “make clean” if needed and make. The build should go without problem.

user@host:~/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples$ make

make[1]: Entering directory `/home/user/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples/0_Simple/asyncAPI’
“/usr/local/cuda-5.5″/bin/nvcc -ccbin g++ -I../../common/inc -m64 -gencode arch=compute_10,code=sm_10 -gencode arch=compute_20,code=sm_20 -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=\”sm_35,compute_35\” -o asyncAPI.o -c asyncAPI.cu
“/usr/local/cuda-5.5″/bin/nvcc -ccbin g++ -m64 -o asyncAPI asyncAPI.o
mkdir -p ../../bin/x86_64/linux/release
. . .
mkdir -p ../../bin/x86_64/linux/release
cp histEqualizationNPP ../../bin/x86_64/linux/release
make[1]: Leaving directory `/home/user/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples/7_CUDALibraries/histEqualizationNPP’
Finished building CUDA samples

5C. Needed post-processing (lib glut, cuda.conf, NVIDIA.conf, and ldconfig)

The next round of problems stemmed from not being able to run the randomFog program in the new ~/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples/bin/x86_64/linux/release folder. I suspect the steps taken to remedy this also make all future CUDA-specific work easier, so list the issues and clean-up steps below.

Out of the list of build samples, I selected a few that worked without issue and, finally, randomFog that decidedly had issues:

user@host:~/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples/$ cd bin/x86_64/linux/release
user@host:~/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples/bin/x86_64/linux/release$ ls
alignedTypes HSOpticalFlow simpleCUBLAS
asyncAPI imageDenoising simpleCUDA2GL
bandwidthTest imageSegmentationNPP simpleCUFFT
batchCUBLAS inlinePTX simpleDevLibCUBLAS
bicubicTexture interval simpleGL
bilateralFilter jpegNPP simpleHyperQ
bindlessTexture lineOfSight simpleIPC
binomialOptions Mandelbrot simpleLayeredTexture
BlackScholes marchingCubes simpleMPI
boxFilter matrixMul simpleMultiCopy
boxFilterNPP matrixMulCUBLAS simpleMultiGPU
cdpAdvancedQuicksort matrixMulDrv simpleP2P
cdpBezierTessellation matrixMulDynlinkJIT simplePitchLinearTexture
cdpLUDecomposition matrixMul_kernel64.ptx simplePrintf
cdpQuadtree MC_EstimatePiInlineP simpleSeparateCompilation
cdpSimplePrint MC_EstimatePiInlineQ simpleStreams
cdpSimpleQuicksort MC_EstimatePiP simpleSurfaceWrite
clock MC_EstimatePiQ simpleTemplates
concurrentKernels MC_SingleAsianOptionP simpleTexture
conjugateGradient mergeSort simpleTexture3D
conjugateGradientPrecond MersenneTwisterGP11213 simpleTextureDrv
convolutionFFT2D MonteCarloMultiGPU simpleTexture_kernel64.ptx
convolutionSeparable nbody simpleVoteIntrinsics
convolutionTexture newdelete simpleZeroCopy
cppIntegration oceanFFT smokeParticles
cppOverload particles SobelFilter
cudaOpenMP postProcessGL SobolQRNG
dct8x8 ptxjit sortingNetworks
deviceQuery quasirandomGenerator stereoDisparity
deviceQueryDrv radixSortThrust template
dwtHaar1D randomFog template_runtime
dxtc recursiveGaussian threadFenceReduction
eigenvalues reduction threadMigration
fastWalshTransform scalarProd threadMigration_kernel64.ptx
FDTD3d scan transpose
fluidsGL segmentationTreeThrust vectorAdd
freeImageInteropNPP shfl_scan vectorAddDrv
FunctionPointers simpleAssert vectorAdd_kernel64.ptx
grabcutNPP simpleAtomicIntrinsics volumeFiltering
histEqualizationNPP simpleCallback volumeRender
histogram simpleCubemapTexture

user@host:~/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples/bin/x86_64/linux/release$ ./randomFog

And you get the following error:

./randomFog: error while loading shared libraries: libcurand.so.5.5: cannot open shared object file: No such file or directory

I originally thought this error might have something to with libglut based on other install sites I ran across. I therefore took the step of adding the symbolic link from /usr/lib/x86_64-linux-gnu to /usr/lib

user@host:~$ sudo ln -s /usr/lib/x86_64-linux-gnu/libglut.so.3 /usr/lib/libglut.so

That said, same issue:

user@host:~/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples/bin/x86_64/linux/release$ ./randomFog
./randomFog: error while loading shared libraries: libcurand.so.5.5: cannot open shared object file: No such file or directory

I then found references to adding a cuda.conf file to /etc/ld.so.conf.d – and so did that (doesn’t help but it came up enough that I suspect it doesn’t hurt either).

user@host:~$ sudo nano /etc/ld.so.conf.d/cuda.conf 

This file should contain the following:

/usr/local/cuda-5.5/lib64
/usr/local/cuda-5.5/lib

Which also didn’t help.

user@host:~/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples/bin/x86_64/linux/release$ ./randomFog 

./randomFog: error while loading shared libraries: libcurand.so.5.5: cannot open shared object file: No such file or directory

To find the location (or presence) of libcurand, ldconfig -v

user@host:~/$ ldconfig -v

user@host:~/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples/bin/x86_64/linux/release$ ldconfig -v
/sbin/ldconfig.real: Path `/lib/x86_64-linux-gnu’ given more than once
/sbin/ldconfig.real: Path `/usr/lib/x86_64-linux-gnu’ given more than once
/usr/local/cuda-5.5/lib64:
libcuinj64.so.5.5 -> libcuinj64.so.5.5.22
libcufft.so.5.5 -> libcufft.so.5.5.22
libcurand.so.5.5 -> libcurand.so.5.5.22
libcusparse.so.5.5 -> libcusparse.so.5.5.22
. . .
libnvToolsExt.so.1 -> libnvToolsExt.so.1.0.0
/usr/local/cuda-5.5/lib:
libcufft.so.5.5 -> libcufft.so.5.5.22
libcurand.so.5.5 -> libcurand.so.5.5.22
libcusparse.so.5.5 -> libcusparse.so.5.5.22
. . .
/usr/lib/NVIDIA-319/tls: (hwcap: 0×8000000000000000)
libNVIDIA-tls.so.319.32 -> libNVIDIA-tls.so.319.32
/usr/lib32/NVIDIA-319/tls: (hwcap: 0×8000000000000000)
libNVIDIA-tls.so.319.32 -> libNVIDIA-tls.so.319.32
/sbin/ldconfig.real: Can’t create temporary cache file /etc/ld.so.cache~: Permission denied

Present twice. Instead of risking making multiple symbolic links as I walked through the dependency gauntlet, I stumbled across another reference in the form of a new /etc/ld.so.conf.d/NVIDIA.conf that contains the same content as cuda.conf (so one may not be needed, but I didn’t bother to backtrack to see. Happy to change the page if someone says otherwise).

user@host:~/$ sudo nano /etc/ld.so.conf.d/NVIDIA.conf

/usr/local/cuda-5.5/lib64
/usr/local/cuda-5.5/lib

Then run ldconfig.

user@host:~/$ sudo ldconfig

With that, randomFog works just fine (and you can assume that a problem in one is a problem in several. Having not taken the full symbolic link route in favor of adding to /etc/ld.so.conf.d, I’m assuming I hit most of the potential errors for the other programs.

user@host:~/NVIDIA_CUDA-5.5_Samples/NVIDIA_CUDA-5.5_Samples/bin/x86_64/linux/release$ ./randomFog 

Random Fog
==========

CURAND initialized

Random number visualization

6. Build CudaMiner

The good news is that there are only a few more steps. The bad news is that any errors you come across in your attempt to build CudaMiner that relate to NOT having done the above are (likely) not represented here, so hopefully your search was sufficiently vague.

Download CudaMiner-master.zip from Christian Buchner’s github account. Extracting CudaMiner-master.zip (with unzip, not gunzip. Damn Windows users) and running configure produces only one obvious error.

user@host:~/WHEREVER_YOU_ARE/$ cd
user@host:~/$ cd Downloads
user@host:~/Downloads$ unzip CudaMiner-master.zip 
user@host:~/Downloads$ cd CudaMiner-master/
user@host:~/Downloads/CudaMiner-master$ chmod a+wrx configure
user@host:~/Downloads/CudaMiner-master$ ./configure

checking build system type… x86_64-unknown-linux-gnu
checking host system type… x86_64-unknown-linux-gnu
checking target system type… x86_64-unknown-linux-gnu
checking for a BSD-compatible install… /usr/bin/install -c
. . .
checking for gawk… (cached) mawk
checking for curl-config… no
checking whether libcurl is usable… no
configure: error: Missing required libcurl >= 7.15.2

This error is remedied by installing libcurl4-gnutls-dev.

user@host:~/Downloads/CudaMiner-master$ sudo apt-get install libcurl4-gnutls-dev 

Which adds and modifies the following from my clean 12.04 LTS install and update

The following packages were automatically installed and are no longer required:
gir1.2-ubuntuoneui-3.0 libxcb-dri2-0 libxrandr-ltsr2 libubuntuoneui-3.0-1 libxvmc1 thunderbird-globalmenu
libllvm3.2
Use ‘apt-get autoremove’ to remove them.
The following extra packages will be installed:
comerr-dev krb5-multidev libgcrypt11-dev libgnutls-dev libgnutls-openssl27 libgnutlsxx27 libgpg-error-dev
libgssrpc4 libidn11-dev libkadm5clnt-mit8 libkadm5srv-mit8 libkdb5-6 libkrb5-dev libldap2-dev
libp11-kit-dev librtmp-dev libtasn1-3-dev zlib1g-dev
Suggested packages:
krb5-doc libcurl3-dbg libgcrypt11-doc gnutls-doc gnutls-bin krb5-user
The following NEW packages will be installed:
comerr-dev krb5-multidev libcurl4-gnutls-dev libgcrypt11-dev libgnutls-dev libgnutls-openssl27
libgnutlsxx27 libgpg-error-dev libgssrpc4 libidn11-dev libkadm5clnt-mit8 libkadm5srv-mit8 libkdb5-6
libkrb5-dev libldap2-dev libp11-kit-dev librtmp-dev libtasn1-3-dev zlib1g-dev

After a make clean, configure and make for CudaMiner went without problem.

user@host:~/Downloads/CudaMiner-master$ make clean
user@host:~/Downloads/CudaMiner-master$ ./configure

checking build system type… x86_64-unknown-linux-gnu
checking host system type… x86_64-unknown-linux-gnu
checking target system type… x86_64-unknown-linux-gnu
checking for a BSD-compatible install… /usr/bin/install -c
checking whether build environment is sane… yes
checking for a thread-safe mkdir -p… /bin/mkdir -p
. . .
configure: creating ./config.status
config.status: creating Makefile
config.status: creating compat/Makefile
config.status: creating compat/jansson/Makefile
config.status: creating cpuminer-config.h
config.status: cpuminer-config.h is unchanged
config.status: executing depfiles commands

user@host:~/Downloads/CudaMiner-master$ make

make all-recursive
make[1]: Entering directory `/home/user/Downloads/CudaMiner-master’
Making all in compat
make[2]: Entering directory `/home/user/Downloads/CudaMiner-master/compat’
Making all in jansson
make[3]: Entering directory `/home/user/Downloads/CudaMiner-master/compat/jansson’
. . .
./spinlock_kernel.cu(387): Warning: Cannot tell what pointer points to, assuming global memory space
./spinlock_kernel.cu(387): Warning: Cannot tell what pointer points to, assuming global memory space
./spinlock_kernel.cu(387): Warning: Cannot tell what pointer points to, assuming global memory space
. . .
nvcc -g -O2 -Xptxas “-abi=no -v” -arch=compute_10 –maxrregcount=64 –ptxas-options=-v -I./compat/jansson -o legacy_kernel.o -c legacy_kernel.cu
./legacy_kernel.cu(310): Warning: Cannot tell what pointer points to, assuming global memory space
./legacy_kernel.cu(310): Warning: Cannot tell what pointer points to, assuming global memory space
./legacy_kernel.cu(310): Warning: Cannot tell what pointer points to, assuming global memory space
. . .
g++ -g -O2 -pthread -L/usr/local/cuda/lib64 -o cudaminer cudaminer-cpu-miner.o cudaminer-util.o cudaminer-sha2.o cudaminer-scrypt.o salsa_kernel.o spinlock_kernel.o legacy_kernel.o fermi_kernel.o kepler_kernel.o test_kernel.o titan_kernel.o -L/usr/lib/x86_64-linux-gnu -lcurl -Wl,-Bsymbolic-functions -Wl,-z,relro compat/jansson/libjansson.a -lpthread -lcudart -fopenmp
make[2]: Leaving directory `/home/user/Downloads/CudaMiner-master’
make[1]: Leaving directory `/home/user/Downloads/CudaMiner-master’

A few warnings (well, several hundred of the same warnings) appeared during the build process (but don’t affect the program operation. Just pointing them out above).

With luck, you should be able to run a benchmark calculation immediately.

user@host:~/Downloads/CudaMiner-master$ ./cudaminer -d 0 -i 0 --benchmark

*** CudaMiner for NVIDIA GPUs by Christian Buchner ***
This is version 2013-12-18 (beta)
based on pooler-cpuminer 2.3.2 (c) 2010 Jeff Garzik, 2012 pooler
Cuda additions Copyright 2013 Christian Buchner
My donation address: LKS1WDKGED647msBQfLBHV3Ls8sveGncnm

[2013-12-25 00:05:38] 1 miner threads started, using ‘scrypt’ algorithm.
[2013-12-25 00:05:58] GPU #0: GeForce GTX 690 with compute capability 3.0
[2013-12-25 00:05:58] GPU #0: the ‘K’ kernel requires single memory allocation
[2013-12-25 00:05:58] GPU #0: interactive: 0, tex-cache: 0 , single-alloc: 1
[2013-12-25 00:05:58] GPU #0: Performing auto-tuning (Patience…)
[2013-12-25 00:05:58] GPU #0: maximum warps: 447
[2013-12-25 00:07:40] GPU #0: 288.38 khash/s with configuration K27x4
[2013-12-25 00:07:40] GPU #0: using launch configuration K27x4
[2013-12-25 00:07:40] GPU #0: GeForce GTX 690, 6912 hashes, 0.06 khash/s
[2013-12-25 00:07:40] Total: 0.06 khash/s
[2013-12-25 00:07:40] GPU #0: GeForce GTX 690, 3456 hashes, 141.56 khash/s
[2013-12-25 00:07:40] Total: 141.56 khash/s
[2013-12-25 00:07:43] GPU #0: GeForce GTX 690, 708480 hashes, 251.11 khash/s
[2013-12-25 00:07:43] Total: 251.11 khash/s
[2013-12-25 00:07:48] GPU #0: GeForce GTX 690, 1257984 hashes, 251.19 khash/s
[2013-12-25 00:07:48] Total: 251.19 khash/s
. . .

Then spend the rest of the week optimizing parameters for your particular card and mining proclivity:

user@host:~/Downloads/CudaMiner-master$ ./cudaminer -h
	   *** CudaMiner for NVIDIA GPUs by Christian Buchner ***
	             This is version 2013-12-18 (beta)
	based on pooler-cpuminer 2.3.2 (c) 2010 Jeff Garzik, 2012 pooler
	       Cuda additions Copyright 2013 Christian Buchner
	   My donation address: LKS1WDKGED647msBQfLBHV3Ls8sveGncnm

Usage: cudaminer [OPTIONS]
Options:
  -a, --algo=ALGO       specify the algorithm to use
                          scrypt    scrypt(1024, 1, 1) (default)
                          sha256d   SHA-256d
  -o, --url=URL         URL of mining server (default: http://127.0.0.1:9332/)
  -O, --userpass=U:P    username:password pair for mining server
  -u, --user=USERNAME   username for mining server
  -p, --pass=PASSWORD   password for mining server
      --cert=FILE       certificate for mining server using SSL
  -x, --proxy=[PROTOCOL://]HOST[:PORT]  connect through a proxy
  -t, --threads=N       number of miner threads (default: number of processors)
  -r, --retries=N       number of times to retry if a network call fails
                          (default: retry indefinitely)
  -R, --retry-pause=N   time to pause between retries, in seconds (default: 30)
  -T, --timeout=N       network timeout, in seconds (default: 270)
  -s, --scantime=N      upper bound on time spent scanning current work when
                          long polling is unavailable, in seconds (default: 5)
      --no-longpoll     disable X-Long-Polling support
      --no-stratum      disable X-Stratum support
  -q, --quiet           disable per-thread hashmeter output
  -D, --debug           enable debug output
  -P, --protocol-dump   verbose dump of protocol-level activities
      --no-autotune     disable auto-tuning of kernel launch parameters
  -d, --devices         takes a comma separated list of CUDA devices to use.
                        This implies the -t option with the threads set to the
                        number of devices.
  -l, --launch-config   gives the launch configuration for each kernel
                        in a comma separated list, one per device.
  -i, --interactive     comma separated list of flags (0/1) specifying
                        which of the CUDA device you need to run at inter-
                        active frame rates (because it drives a display).
  -C, --texture-cache   comma separated list of flags (0/1) specifying
                        which of the CUDA devices shall use the texture
                        cache for mining. Kepler devices will profit.
  -m, --single-memory   comma separated list of flags (0/1) specifying
                        which of the CUDA devices shall allocate their
                        scrypt scratchbuffers in a single memory block.
  -H, --hash-parallel   1 to enable parallel SHA256 hashing on the CPU. May
                        use more CPU overall, but distributes hashing load
                        neatly across all CPU cores. 0 is now the default
                        which assigns one static CPU core to each GPU.
  -S, --syslog          use system log for output messages
  -B, --background      run the miner in the background
      --benchmark       run in offline benchmark mode
  -c, --config=FILE     load a JSON-format configuration file
  -V, --version         display version information and exit
  -h, --help            display this help text and exit

I’ve only had a few problems with CudaMiner to date. The most annoying problem has been the inability to run tests to optimize card performance without having to put the machine to sleep and wake it back up again (better than a full restart). CudaMiner will, without this, simply hang on a script line:

[2013-12-25 00:49:08] 1 miner threads started, using ‘scrypt’ algorithm.

The sleep + wake does the trick, although I’d love to find out how to not have this happen.

The second annoying problem was:

“. . . result does not validate on CPU (i=NNNN, s=0)!

This error is due to your “K16x16″ configuration (the most prominent one I’ve found in google searches, so placed here to help others find it. Your values may vary) being too much for the card (so vary them down a spell until you don’t get there error). There’s a wealth of proper card settings available on the litecoin hardware comparison site, so I direct you there:

litecoin.info/Mining_hardware_comparison

7. And Finally. . .

By all accounts, CudaMiner is a much faster mining tool for NVIDIA owners. To that end, please note that Christian Buchner has made your life much easier (and your virtual wallet hopefully a little fuller). As mentioned above, his donation address is:

LKS1WDKGED647msBQfLBHV3Ls8sveGncnm

Do consider showing him some love.

This post was made in the interest of helping others get their mining going. If this guide helped and you score blocks early, my wallet’s always open as well (can’t blame someone for trying).

LTmicpwpGgrZiyiJmMUdyqq4CG8CqiBqrm

The timing for getting the guide up is based on a new mining operation here in Syracuse, NY in the form of Salt City Miners, currently the Cloud City of mining operations (also appropriate for the weather conditions). Parties interested in adding their power to the fold are more than welcome to sign up at miner.saltcityminers.com/.

2013dec28_scm_logo

And don’t forget the Meetup group: Syracuse Meetup Group – Bitcoin’s of New York – Miner’s of Syracuse

Experimental And Theoretical Studies Of Tetramethoxy-p-benzoquinone: Infrared Spectra, Structural And Lithium Insertion Properties

December 20th, 2013

Published earlier this year in RSC Advances (RSC Adv., 2013, 3, 19081-19096), a follow-up (for my part) to the study The Low-/Room-temperature Forms Of The Lithiated Salt Of 3,6-dihydroxy-2,5-dimethoxy-p-benzoquinone: A Combined Experimental And Dispersion-Corrected Density Functional Study in CrystEngComm last year. The theoretical section for this paper is a tour-de-force of Crystal09 solid-state optimizations, density functional and dispersion-correction dependence, and post-processing using Carlo Gotti’s TOPOND software. In brief, the combination of vibrational spectra, electochemical measurements, and solid-state density functional theory tests are used to predict the structure of the previously unknown lithiated tetramethoxy-p-benzoquinone structure based on the good-to-excellent agreement with two known TMQ crystal structures (the testing of density functionals and dispersion corrections being a very good survey of the pros and cons of the varied methods. If you were pondering an approach to follow to perform the same kind of theoretical analysis, the procedure set up by Gaëtan and Christine in this paper is fully worth your consideration).

2013dec20_rscadvances

Gaëtan Bonnard, Anne-Lise Barrès, Yann Danten, Damian G. Allis, Olivier Mentré, Daniele Tomerini, Carlo Gatti, Ekaterina I. Izgorodina, Philippe Poizot and Christine Frayret*

In the search for low-polluting electrode materials for batteries, the use of redox-active organic compounds represents a promising alternative to conventional metal-based systems. In this article we report a combined experimental and theoretical study of tetramethoxy-p-benzoquinone (TMQ). In carbonate-based electrolytes, electrochemical behaviour of this compound is characterized by a reversible insertion process located at approximately 2.85 V vs. Li+/Li0. This relatively high potential reactivity, coupled with our effort to develop computational methodologies in the field of organic electrode materials, prompted us to complement these experimental data with theoretical studies performed using density functional theory (DFT). Single crystals of TMQ were synthesized and thoroughly characterized showing that this quinonic species crystallised in the P21/n space group. The experimental crystal structure of TMQ was then used to assess various DFT methods. The structural features and vibrational spectra were thus predicted by using as a whole five common density functionals (PBE, LDA, revPBE, PBEsol, B3PW91) with and without a semi-empirical correction to account for the van der Waals interactions using either Grimme’s (DFT-D2) or Tkatchenko–Scheffler (TS) scheme. The most reliable combination of the DFT functional and the explicit dispersion correction was chosen to study the Li-intercalated molecular crystal (LiTMQ) with the view of indentifying Li insertion sites. A very close agreement with the experiment was found for the average voltage by using the most stable relaxed hypothetical LiTMQ structure. Additionally, a comparison of vibrational spectra gained either for TMQ molecule and its dimer in gas phase or through periodic calculation was undertaken with respect to the experimentally measured infrared spectra. The topological features of the bonds were also investigated in conjunction with estimates of net atomic charges to gain insight into the effect of chemical bonding and intermolecular interaction on Li intercalation. Finally, π-electron delocalization of both quinone and alkali salts of p-semiquinone were determined using the Harmonic Oscillator model of Aromaticity (HOMA) or aromatic fluctuation index (FLU) calculations.

Commensurate Urea Inclusion Crystals With The Guest (E,E)‐1,4-Diiodo-1,3-Butadiene

December 20th, 2013

Published in Crystal Growth & Design (Cryst. Growth Des., 2013, 13 (9), pp. 3852–3855) earlier this year. The theory work is less impressive than the successful crystal growth, with initial solid-state efforts in Crystal09 only very recently now producing good results (leaving the molecular calculations to Gaussian09 in this paper). The procedure leading to the observed crystal structure of this inclusion complex is a significant step in the direction of testing the theory proposed in Bond Alternation In Infinite Periodic Polyacetylene: Dynamical Treatment Of The Anharmonic Potential published earlier this year in J. Mol. Struct.

2013dec20_DIBD_UIC

Caption: Two views along the ba and ca crystal axes of the (E,E)‐1,4-Diiodo-1,3-Butadiene : Urea Inclusion Complex.

Amanda F. Lashua, Tiffany M. Smith, Hegui Hu, Lihui Wei, Damian G. Allis, Michael B. Sponsler, and Bruce S. Hudson

Abstract: The urea inclusion compound (UIC) with (E,E)-1,4-diiodo-1,3-butadiene (DIBD) as a guest (DIBD:UIC) has been prepared and crystallographically characterized at 90 and 298 K as a rare example of a commensurate, fully ordered UIC. The crystal shows nearly hexagonal channels in the monoclinic space group P21/n. The DIBD guest molecules are arranged end-to-end with the nonbonding iodine atoms in the van der Waals contact. The guest structure is compared with that for DIBD at 90 K and with computations for the periodic UIC and isolated DIBD molecule.

“From Kurdistan With Love” or Some Things To Do Before And/Or After Your WordPress Site Gets Hacked

December 12th, 2013

“Hopefully, because he’s busy.” – Commissioner Gordon, The Dark Knight

On the plus side, www.somewhereville.com received its first update in just over 5 months. On the minus side, the new post was less than useful in many ways. I received a timely email from Dr. Obi Griffith of the Washington University in St. Louis Division of Oncology noting that my entire site was differently-down (thanks to the hijacking of my Sanger (And Illumina 1.3+ (And Solexa)) Phred Score (Q) ASCII Glyph Base Error Conversion Tables page that he linked to on a biostars site thread – so my thanks to Obi for catching something I likely would have gone weeks without noticing!).

The snapshot below shows the state of swv as of 3 December 2014. On the bright side (minus a friendly conspiracy to get someone else in trouble), I can say with some certainty that Serwan performed the content-ectomy (twitter: @S3RW4N, current email (although I suspect it won’t last long): serwan_007 – at cymbal – hotmail.com, on the Facebook, etc. All sites subject to change as people try to track him/her down post-attack (he/she’s been prolific if nothing else)).

2013dec11_serwan_hack

Exhibit A. Flag is waving in the actual version.

Several problems. To begin, it’s a gaudy hack, complete with rolling text and techno music. Second, the Television New Zealand (TVNZ) news service thought this hack to be significant enough to warrant actual coverage on their website when a similar file-swap on a WordPress (or WordPress-esque) site brought down the Health and Sports Fitness Club in Sandringham (syracuse.com didn’t give me the time of day). I commend this Kurdish hacker group for their ratings. Third, the manner in which files were replaced in the blog (specifically meaning the index.php file) blocked every other post on the site from being accessed, so every link anyone had posted to a page anywhere else on the Internets was made useless.

That said, I appreciate that Serwan generally performs fairly benign attacks on websites. File replacements were clearly identified from a simple date sorting, the important MySQL database content wasn’t touched, and Serwan even went as far as to set up a second Admin account so that I could quickly retake control of the site.

So, in light of the plight of the Kurdish people, I left the hacked version up for a few hours as I pondered what to do, which I discuss below.

My Spotty Procedure For Recovery:

What follows is a list of obvious and less obvious things to consider when recovering your WordPress blog from a hack. There are plenty of websites that show how to protect your site in the first place, then others that explain how to revive it (provided you do your own due diligence and back your site up regularly enough). What’s below is not complete, but you can rest assured that google is your friend in such matters, so keep your keywords targeted and see what comes up.

General Considerations:

1. Don’t use your blog. My last post at the time dated back to June 25th, during which time I’ve made several full backups (and kept WordPress up-to-date, the last time being 7 November 2013) of my entire site. In this respect, I was well set up to quickly recover from a hacking incident.

2. Keep a copy of your current running version of WordPress handy for file replacements. In my case, index.php was written over. All I had to do to recover was uncompress my WordPress  3.7.1 download, upload index.php to my server, and the site was back and running.

3. Have you backed up lately? This phrase has been in the .sig of my emails for many, many years. If your entire life is lived in the Googleverse (email, images, documents, etc.), then you’re fine until the Earth’s magnetic poles shift and wipe all the hard drives out (just kidding. I think). If you’re a computational scientist and have TBs of data, it’s up to you to make sure you have access to it all again. Same applies to WordPress. I’ve a biweekly alarm that tells me to back up several websites and I’ve an encrypted .txt file with all of the login info and steps needed to perform this backup. You should absolutely be doing the same if you’re not.

4. Set up an additional Administrator. In my case, my admin account was hacked to change the associated user email address to Serwan’s email. Obviously, attempting to log in, change the password, or what have you simply sent little pings of your futile attempts to the hacker. Having that second admin account will allow you to reroute your login efforts (and if they’re both hacked into, there’s still a way around. Will get to below).

5. Make a real password. At the risk of de-securing my sites by providing personal info, my typical password looks something like this:

d@!25fj014or&ydoSDfu

20 characters long, upper and lower, numbers, and non-alphanumeric characters. If you care about your site security, stay the hell away from the dictionary.

6. Dry-run your SHTF moment. Are you a survivalist? Can you identify edible berries by sight, build a lean-to, or stitch an open wound? Or are you the Marty Stouffer of the camping section at Target? If you’ve never had to work your way back from a complete disaster, you likely won’t know how to do it either quickly, efficiently, or securely.

Ergo, do another WordPress installation in a sub-folder of your main installation, create a new database, make your site pretty, perform a full backup of your database and uploaded media, then break it, either by deleting core files or corrupting your database (deleting a table would do the trick). If you can put the site back together again (the uploading of the database back onto your server likely being the worst part of the whole process), you’re likely in good shape for the real deal.

7. Harden WordPress. The good people at WordPress even tell you how to (although, admittedly, I thought I did all of this, so maybe there’s something being missed that will go into a future iteration of this page).

8. Get rid of “admin.” Several of the sites discussing WordPress hacks report that having this default account (or account default’ed) is a top-5 problem when trying to keep people out of your site. So get rid of it. Easily. Set up a new account, give it administrative privileges, then delete the admin account, which will ask you to attribute the current admin posts to another admin account.

9. Delete deactivated plugins if you’re not going to use them. Plugins are developed by people. People often have lives that keep them from timely updates of security exploits. If you’re using a plugin, that’s one thing. If a deactivated plugin languishes in your plugins folder, never gets updated, and some hacker writes something specifically to exploit a security flaw in that old, poorly maintained plugin, that’s all on you. So don’t risk your pocket knife being a projectile as you walk into the MRI room and get rid of the knife before it comes a problem.

10. I know nothing about it yet, but am giving Wordfence a whirl presently.

11. Hey, check your blog every once in a while to make sure it’s still you and not Serwan.

For The Specific Attack (From Easy To Harder):

1. FTP in and check file dates. The offending .php files (index.php and a hello.php containing the techno) were both dated 3 December 2013. Everything else was, at its newest, 7 November 2013 (from my last WordPress update). This made finding the hacked and previously not-present files easy. A cluster of important files with identically modification times and dates is an easy giveaway.

2. FTP in and check ALL the file dates. One never knows when something else is going to be placed into a themes folder, plugin folder, etc., to keep track of site access (that’s why I delete all deactivated plugins). So, sort by date and scour the whole site for modifications and new files.

3. If you make it into your site, go right to your User Settings, change the email address, then change your password.

4. Check out something like Sucuri SiteCheck. Hopefully, this search will complement your initial search as well as test against known threats. I ran a Sucuri on a similarly-hacked site (in this case, indoorstinkbugtrap.com) and received the following notification of defacement (so the check worked).

2013dec11_securi_results

securi.net results for fellow victim indoorstinkbugtrap.com.

5. If you can’t make it in the front door, crawl through the plumbing. You can change your admin account from within MySQL using, for instance, phpMyAdmin (check your hosting provider for details if this is new information to you). In the case of phpMyAdmin, you can modify the admin account in six easy steps.

1. Log in to phpMyAdmin

2. Click on the Structure Button in wp_users (red circle)

2013dec11_serwan_hack_mysql_1

3. Click on Browse (told you this was easy)

2013dec11_serwan_hack_mysql_2

4. Click the edit button for your administrative account (red circle)

2013dec11_serwan_hack_mysql_3

5. Change the email address back to your email and delete the current password.

2013dec11_serwan_hack_mysql_4

6. Save and go back to our WordPress site, then request a new password.

And, While We’re At It:

Serwan’s twitter image currently features a white hat (the Gandalf-ian sign of a good guy/gal hacker) and a long list of sites that have been defaced with otherwise useless, feral medadata promoting Kurdish Hackers for google to get confused by. A search for somewhereville.com in google left the following bad taste in its results page for a week after:

Hacked By Serwan. Allah Is Greatest. Long Live Kurdistan. Thanks To All Kurdish Hackers. Follow @S3RW4N FB.com/Mr.S995

If I may be so bold (and I’ve told Serwan the same), the Kurdish people had a long history of getting steamrolled by an oppressive regime that, regretfully, first-world countries didn’t put enough into stopping or acknowledging until the tanks rolled South into Kuwait. If you’re gong to label yourself an ethical hacker, fine. Mangle the front-end of someone’s WordPress site. That said, you could be educating others on the Kurdish people by including a few links into your hack. I live in America, where certain news services use “Muslim” and “Islam” in headlines purely for shock value when they want to appeal to an audience so narrow-minded that their hearing is susceptible to the Casimir Effect. I recommend adding the wikipedia article on Kurdistan and the Al-Anfal Campaign to future hacks (and I’m sure Serwan could find more) to provide a little substance to your efforts unless, of course, your goal is just to be a stupid-ass script-kiddie hacker.

If you’re gonna hack, at least try to be productive. Meantime, this was a valuable lesson for myself on what to do to try to keep WordPress from falling into the same limbo during a time when I might not have had an hour to fix it.

Obligatory

  • CNYO

  • Sol. Sys. Amb.

  • Salt City Miners

  • Ubuntu 4 Nano

  • NMT Review

  • N-Fact. Collab.

  • T R P Nanosys

  • Nano Gallery

  • nano gallery
  • Aerial Photos

    More @ flickr.com

    Syracuse Scenes

    More @ flickr.com