• runcmd: A tool to run other commands with many useful options. runcmd is particularly useful for running experiments. Supported options include
• Setting a timeout value for the spawned command.
• Setting the cpu affinity.
• Recording the spawned command’s exit value and resource usage to a file.
• grep-recursive: A tool that combines grep and find to perform a recursive grep. It allows options such as only searching in files with specific file types. For example, a developer may only want to search in .h, .c, and .cpp files.
• replace: A tool that performs global replacements in files, for those that don’t know sed/awk.
• getctypeinfo: A program that prints out the number of bits in and the min and max values of many common C types.

• When I first installed NWN2 on Windows 7, I received a warning toward the end of the installation giving me an ERROR_DX_INSTALL message; however, the installation seamed to finish.  When I launched the game, Windows complained that the game had stopped working.  So, after searching on the internet, I did the following to get it working.  I am not sure if the first step needs to be performed, but I will list it in case it is needed.

1. The first thing I did was install the DirectX 9 redistributable package, located at http://www.microsoft.com/downloads/details.aspx?familyid=04ac064b-00d1-474e-b7b1-442d8712d553&displaylang=en. I realize that Windows 7 is being bundled with DirectX 11, but the above package will not conflict with it.
2. The next thing I did was manually patch NWN2 as far as I could, as the game’s automatic updater would not patch the game until the game had been run once, and as you know, I could not run the game.  You can find NWN2 manual patches at http://nwvault.ign.com/View.php?view=NWN2Other.Detail&id=19.  If you know how to manually patch NWN2 you can skip the following details.
   1. Obtain and run the NWN2 manual patcher.
   2. Note the version of NWN2 that you have installed, located in the bottom right had corner of the manual patcher, when it is launched.
   3. Assuming you don’t have any expansions installed yet, you need patches with the following naming convention: nwn2_pc_<language>_from<starting version>_to<ending version>.zip.  You need to download and install consecutive patches starting with the version you noted above.  Install up to the highest version you can get to, but make sure that each patch is an nwn2_pc patch, you install patches consecutively, and there are no gaps between patches.  There is a gap between patches if you install patches A and B, one right after another, and the ending version number of patch A does not match the starting version number of patch B.
      • At the advice of a friend, I unzipped each patch into my NWN2′s installation directory before installing them.  However, I’m not sure if that is necessary.
      • I was able to install patches from version 104870 to version 1111115.

• After performing the steps above I was able to launch NWN2.  So, I tried to install the Mask of the Betrayer expansion.  After doing so, I tried to launch the game and again Windows complained that the game had stopped working.  So, as before, I manually patched NWN2 as far as I could.  This time, patches should be of the form  nwn2_pcx1_<language>_from<starting version>_to<ending version>.zip. pcx1 stands for expansion 1.  You will have to check the version of NWN2 as you did before to know which patch to begin with.  I installed patches starting with version 1101115 and ending with version 1211549.
• At this point, NWN2 with Mask of the Betrayer patches launched and played.  However, roughly 15-20 minutes into creating a character in multiplayer mode, it crashed.  So, I launched NWN2 in administrator mode, made it through character creation, saved, and relaunched without being in administrator mode.  That seamed to fix all of the problems.  I’m not sure why administrator mode fixed the problems, but I will hazard two guesses as to why.

1. There was some save file to which NWN2 was trying to write, and it did not have permissions to create the file.  After having run the game in administrator mode, the file was successfully created.
2. There is a bug in NWN2 character creation that administrator mode somehow overcomes.

1. Drivers must be signed to use them in Windows 7.  ATT uses unsigned drivers, most likely because driver signing costs money, and Ray Adams is giving ATT away for free!  So, if you want to use ATT, then you need to disable the driver signing requirement in Windows 7.  You can find instructions for doing so at http://arbitraryusefulinfo.wordpress.com/2010/01/23/using-unsigned-drivers-in-windows-7/.
2. In my experience, you need to use the latest beta of ATT if you’re using it with Windows 7.  You can download the latest beta from: http://cid-a50350ea7a969f0c.skydrive.live.com/self.aspx/Public/attsetup.exe.  Being a security guy, if some posted an odd link like the one I just posted, I’d be a little leery that it was valid.  So I’ll post a link to the thread where Ray states the location of the latest ATT beta: http://forums.guru3d.com/showthread.php?t=275077.

To disable the driver signing requirement, open a dos prompt as administrator and enter the following commands:

bcdedit.exe /set loadoptions DDISABLE_INTEGRITY_CHECKS
bcdedit.exe /set TESTSIGNING ON

To check the values of these settings, open a dos prompt as administrator and run:

bcdedit.exe /enum

To undo these settings, open a dos prompt as administrator and run:

bcdedit.exe /deletevalue loadoptions
bcdedit.exe -set TESTSIGNING OFF

• Download statusbar: This add-on creates a status-bar at the bottom of the browser to manage downloads, rather than popping up a separate window to manage them, as firefox normally does. Not only does the status-bar save screen real estate, but it also keeps the download manager out of your way.
• NoScript: This is a great add-on for managing which sites can run java, and javascript.  It does this by assuming that a site is forbidden from running java and javascript unless you add the site to a whitelist.  Not only is this add-on good from a security point of view, but it also helps limit how annoying a website can be.
• Swift tabs: Firefox has integrated lots of the support that tabbing add-ons provide, but it still does not have support for keyboard shortcuts to switch between tabs.  This add-on allows you assign such shortcuts.
• Snap links: This allows you to use the mouse to draw a rectangle around a group of links on a website, that you wish to view, and each of those links will be opened in separate tabs. This is particularly useful when using search engines.

Before I detail the steps for the howto, I want to setup some terminology:

• Local-initiation host: A local-initiation host is any host that you locally log into and from which you wish to log into remote hosts without a password.
• Target host: A target host is any host into which you wish to login using ssh. A local-initiation host may also be a target host.

Here are the steps for setting up passwordless login. These steps should can be run from a local-initiation host.

1. Create a DSA public-private key pair.
   • Please use the most up-to-date OpenSSH implementation if you are generating your keys on a Debian-based machine (including Ubuntu) because there is a known openssh bug on Debian-based Linux distributions released between September 2006 and May 13, 2008.
   • Run: ssh-keygen -t dsa
   • By default it will ask to place your private key in ~/.ssh/id_dsa, which is where you want it.
   • Then it will ask you for a passphrase. It is my understanding that an empty passphrase is less secure than a non-empty passphrase, so use an empty passphrase at your own risk.
2. Create an authorized keys file and disseminate it to target hosts.
   • Ssh uses a file called ~/.ssh/authorized_keys on target hosts to determine if incoming hosts can login without a password . The authorized keys file contains a set of public keys. Any incoming host using an unlocked private key that is paired with a public key in the authorized keys file, will be granted access without a password.
   • To create the authorized keys file, run the following commands:

     touch ~/.ssh/authorized_keys
     chmod 600 ~/.ssh/authorized_keys
     cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

     Note, this adds your public key to the set of authorized keys.

   • Remotely copy the authorized keys file to the ~/.ssh directory of all your target hosts. If the current host is not a target host, then you can delete it from your local host. Make sure the permissions on the authorized keys file on all target hosts is 600.
3. Optional: Disseminate your private key to local-initiation hosts.
   • If you have more than one local-initiation host, then copy ~/.ssh/id_dsa to the ~/.ssh directories of all your local-initiation hosts, and make sure it has 600 permissions on each host.
4. Set up Gentoo’s keychain on local-initiation hosts.
   • First, let me explain what keychain does, so you’ll understand the setup.
     • If there is not an ssh-agent process running (for the local user), then keychain starts a persistent ssh-agent process.
     • Keychain saves environment variables in ~/.keychain/${HOST}-* files with information about the currently running ssh-agent.
     • Keychain make private keys know to the currently running ssh-agent, if they are not already known. If the keys are not already known, you are prompted for your passphrase, so they can be loaded.
   • Setup steps
     • Install Gentoo’s keychain on each of your local-initiation hosts.
     • Automatically run keychain. There are two methods to run keychain.
       1. The first method is to run keychain every time a shell is created. For example, I add the following lines to my ~/.cshrc file to do that:

          if (!($?SSH_CONNECTION)) then
            if (-X keychain) then
              keychain ~/.ssh/id_dsa
              source ~/.keychain/${HOST}-csh
            endif
          endif

          This code checks to see if the shell is local or remote(i.e., invoked through an ssh connection). If the connection is local, the shell runs keychain and reads in environment variables identifying where the local ssh-agent is running. (Note, if keychain has already been run, it is actually redundant to run it in every shell.)

       2. The second method is to run keychain once when you log into a local-initiation host, not every time a shell starts up.  This can be accomplished in a few steps.  To run keychain once when you login, create the following keychain-startup.pl script:

          #!/usr/bin/env perl
          # Import HOST
          use Env;
          Env::import();
          $cmd = "rm -f ~/.keychain/" . $ENV{HOST} . "-*";
          `$cmd`;
          $cmd = "keychain ~/.ssh/id_dsa";
          `$cmd`;

          Then set up your current windowing environment to call that script on startup. In Gnome, you can do this if you go through the following menu progression: Ubuntu Main Menu->System->Preferences->Sessions->Startup Programs. In your shell configuration script you need to read the appropriate keychain generated file for your shell, created in ~/.keychain. I do this by adding the following code to my ~/.cshrc file:

          if (!($?SSH_CONNECTION)) then
            if (-e ~/.keychain/${HOST}-csh) then
              source ~/.keychain/${HOST}-csh
            endif
          endif

     • In both methods above, we only run keychain if we are on a local host.  If you are on a remote host, i.e., one that you’ve logged into via ssh, there is no need to run keychain on it because you can forward the ssh-agent from the local host, through ssh.  That is done by calling ssh with the -A option or by setting up agent forwarding in your <code>~/.ssh/config</code> file.  In addition, this eliminates you having to type your passphrase on the remote host. Note, the use of agent forwarding implies that if you start at a local-initiation host, you can type your passphrase once on that host, log into target host A without a password, and then log into target host B from the just-created ssh connection to target host A, also without a password.
5. Test your setup.

Troubleshooting:

• Remote host identification has changed: If you try to ssh into a machine and get a warning about the remote host’s identification changing, see this site for an explanation.
• Permission problems: If you’re having troubles, you may want to check the permissions of your ~/.ssh directory and of the files in it. Most notably, your private keys should not be readable by anyone but yourself, and neither your ~/.ssh directory nor the files in it should be writable by anyone but yourself.

Setting up RSA keys in addition to your DSA key:

1. Generate the RSA keys similarly to how you generated the DSA key above, except you pass -t rsa1 to ssh-keygen to generate an RSA key for ssh1 and -t rsa to generate an RSA key for ssh2. Note, private RSA keys for ssh1 are stored in ~/.ssh/identity and private RSA keys for ssh2 are stored in ~/.ssh/id_rsa
2. Similarly to what you did with your public DSA key, add your public RSA keys to your authorized keys file and disseminate it to your target hosts.
3. Optional: Disseminate your private RSA keys to local-initiation hosts.
4. Modify the keychain code you added to your shell configuration file so that keychain is also called with your private RSA keys. For example, I would change the keychain line in my ~/.cshrc file to read: keychain ~/.ssh/id_dsa ~/.ssh/id_rsa ~/.ssh/identity.

For more information:

• Run man on the following: keychain, ssh-keygen, and ssh-agent.
• Visit the following websites:
  • Gentoo keychain project