[ISyE Helpdesk] Recently Updated Articles

Using WinSCP

Wed, 01 May 2013 16:09:42 GMT

Problem:

I need to use a secure client to access an ISyE server. Do you have any suggestions? I heard WinSCP is an alternative.

Solution:

What is WinSCP?

WinSCP is a freeware SCP (Secure CoPy) client for Windows 95/98/NT/2000/XP/ME using SSH (Secure SHell). Its main function is safe copying of files between a local and a remote computer. Beyond this basic function, WinSCP manages some other actions with files.

How do I use WinSCP to connect to an ISyE UNIX server?

There are many advanced options available with WinSCP, but to connect to an ISyE server(e.g. castle.isye.gatech.edu) for a simple interactive login, fill in the information as shown below. Click Save if you'd like to save this connection for later use.

Verify the connection and choose Yes or No accordingly.

Once you enter the program, drag and drop files between your local computer and the remote machine.

For more information or to download the software, please visit the WinSCP Sourceforge area located at http://winscp.sourceforge.net/eng/. WinSCP can also be downloaded from the Georgia Tech OIT Software Download page.

Why did my job die?

Wed, 24 Apr 2013 12:58:49 GMT

There is no limit to the number of jobs you can submit. If there are no resources to run jobs, they will simply wait in the queue until resources are made available. There are a number of reasons jobs might be killed. The most common reason is that a job used more memory than was available on the machine. When this happens, the job will be killed in order to preserve the usability of the system. In addition, the job would most likely not have completed in a reasonable amount of time due to swapping to disk, having used up all available physical memory. Another possible reason is that the job ran on a private node and the owner logged in or submitted a job to that node. Private nodes, when not in use by their owners, are in the general cluster. When a node's owner logs into it, or submits jobs to it, community jobs on the node will be pre-empted in favor of the owner's jobs. The final reason for a job being killed is that a parallel job was submitted and your job was running on the boyles/wilkins and took longer than 5 calendar days to complete. These are the parallel machines and will kill serial jobs in favor of a parallel job, but they do have a grace period of 5 calendar days in order to allow the serial jobs to try to reach completion.

You can see your job history with the condor_history command. Like so:

condor_history <username>

You can then see the specifics about the job using the -long modifier with the job number. e.g.

condor_history -long <jobID>

That's the first place to start.

There is also the log in /tmp. That gives some very basic info about job statuses.

If you find more specific details, I may be able to help you interpret them.

Running out of memory

Mon, 25 Feb 2013 21:19:06 GMT

Most of the time, if a program is compiled in C and it is using an unusually large amount of memory, then there is a memory leak. Unless you have some specific reason to expect a very large data set in memory, you should first attempt to find the memory leak.

In most cases, there are techniques you can utilize to optimize your code and reduce your memory footprint. You might also need to change your strategy for handling your computations. Perhaps you can slice your dataset and run more smaller jobs to achieve your results. This is going to give you much more redundancy and a better chance of completing your work, simply because you'll be less vulnerable to losing a lot of work when one job is somehow killed.

It is not unreasonable to need more than a couple of GB of memory these days, especially if you are using Matlab or another product which can add a fair amount of overhead. In those cases, you should run a test job to determine the size of your memory footprint. Run a job and then use the condor_history -long command to view the classed attributes of the job. Look for image_size. This is the maximum observed image size reported in KB. Use this as a guide for setting the image_size attribute in your command file. That attribute is set in KB as well. This attribute tells condor that your job may use up to the amount of memory specified. Condor will use this attribute to match appropriate resources so that you job will not run on a machine with too little memory.

START HERE: How to run Unix/Linux compute jobs using Condor

Mon, 25 Feb 2013 21:07:53 GMT

Instructions for the use of ISyE's computational Linux cluster:

Initial requirements

You need an ISyE Unix Account.

Logging in

The central 64-bit compute server is wren.isye.gatech.edu (or just "wren" if you are on ISyE's subnets).
You should be able to access wren via ssh using your usual ISyE Unix account and password. Your Unix home directory will be mounted and accessible.

Compute cluster hierarchy

The central server, Wren, is called the "head node". When compute jobs are ready to be run, the head node assigns execution of them to subordinate servers which are called "compute nodes".
Users only need to log into the head node. The compute nodes do not support direct logins, and they cannot mount home directories. Compute jobs must be submitted to them through the Condor batch queue scheduler.

Development

Development for 64-bit Linux compute jobs should be done on wren, and short interactive test runs can be performed there. You should test your program "locally" on the head node before submitting it to Condor. By "local" we mean executing the program in your login shell on wren.
You want to make sure your code starts and runs as you expect for at least a few minutes locally on wren, before you submit it to Condor. By testing the program locally first, you will save yourself and everyone a lot of headaches. Condor works great once your code is ready to go, but it's a very frustrating way to debug!
Long-running compute jobs and large batches of unattended short-running jobs are not allowed on the head node.
GUI development interfaces can be exported to the local X Windows desktop via ssh X forwarding (the ssh -X option).

Condor commands

Condor's executables are located in /opt/condor/bin, which should be in your default command path on wren, with man pages available for most important commands.

Generally the most useful Condor commands are:


   condor_submit -- submit jobs to the condor batch scheduler.

   condor_status -- show overall cluster status.

   condor_q      -- show current job queue and status of jobs.

   condor_rm     -- remove jobs from the condor queue.

Job submission

For most compute jobs, you will need to create a condor submit description file (a ".cmd" file) and then run "condor_submit .cmd".
An example .cmd file is listed below. Other examples can be found in /opt/condor/examples, and the syntax for .cmd files is documented in the condor_submit man page.
In the simplest cases, you can submit a job to condor by running "consub filename". This will work for a simple program that has no options, no input and output files (so if run locally, output would go to the screen). consub will create a simple filename.cmd file, copy the executable to a compute node and run the job, and then copy the output back to filename.out.

File accessibility on the compute nodes

You can run jobs directly from your Unix home directory tree, and all your files will be accessible to the compute nodes.
If you need more space than currently allocated, request it from IT.
It is possible to transfer files to the nodes, and then back to wren upon completion (should_transfer_files). On dedicated compute clusters like ours this is generally not the desired method. Your home directory is mounted on the compute nodes just as it is on wren or castle, so there is really no need to transfer files.

Log files

The Condor log file should be written to /tmp, rather than to your home directory tree. Any user can create a directory in /tmp. Typically just create /tmp/ and use that as an output path for the "log" directive (see example below).

Condor universe

You must specify a "universe" to run a condor job in. For basic compute jobs written in any language, add a line to use the "vanilla" universe. If you do not explicitly specify the universe, it will default to "standard" universe which will not work without special compile-time options.

Example .cmd file


    universe        = vanilla
    executable      = foo
    output          = foo.out
    error           = foo.err
    log             = /tmp//foo.log
    arguments       = 10 20 30
    queue

This command file should be called "foo.cmd" and placed in the same global scratch space subdirectory as the program "foo". You will then type "condor_submit foo.cmd" to run this compute job. Normal screen output will go to to "foo.out" and stderr will go to "foo.err". The program expects three command-line arguments which are "10", "20", and "30".

Note that the log file is placed in /tmp! This is very important! Log files written to NFS-mounted home or scratch directories will often break condor due to NFS locking problems. So, once again, create a directory for yourself in /tmp, and write your log files there.

Any other input and output files generated by the program will be accessed normally, as long as the path is accessible to the program (normally, this means in your home or scratch directory).

In many cases you may also need to run jobs that won't work correctly without your login environment variables (such as PATH, LD_LIBRARY_PATH, or software-specific environment variables). Since these won't be available by default on the compute nodes, you need to explicitly add them via the submit file using this line:


     getenv = true

Notification

The cluster will not normally notify you of job completion. If you'd like notification, you should add one of the following lines depending on the level of notification you would like:


    notification = error        
    notification = complete
    notification = always

The default email address for these notifications is the ISyE email address of the user submitting the jobs. If you'd like mail sent to an alternate address, add the following line:


    notify_user = my.email@domain.com

More on Condor

For further documentation, please see the Condor User's Manual.

Why is my job stuck in idle?

Mon, 25 Feb 2013 13:39:34 GMT

There are any number of reasons a job can remain idle. The first thing to do is check the job's output files, then use the command "condor_q -l" to get a long format job listing.

One common reason for idle jobs is running out of memory, which is usually due to memory leaks. The condor_q -l output contains the "ImageSize" attribute, expressed in KB. If this amount is larger than 12000000 (12GB) then you know you have a problem; and it could be a problem even at "only" 8GB.

For more detailed information, please see the appropriate section of the condorHT manual 2.6.5 Why is the job not running?

Tracking time in condor

Mon, 25 Feb 2013 02:11:52 GMT

Condor tracks a number of different elapsed time counters. This page details the different time counters that condor maintains.

http://research.cs.wisc.edu/htcondor/manual/v7.6/26ManagingJob.html

Mapping a Network Drive

Thu, 14 Feb 2013 21:25:51 GMT

Problem:

I am working on a Windows machine and need access to a SAMBA share.

Solution:

What is SAMBA?

Samba is a suite of Unix applications that speak the SMB (Server Message Block) protocol. Many operating systems, including Windows and OS X, use SMB to perform client-server networking. By supporting this protocol, Samba allows Unix servers to get in on the action, communicating with the same networking protocol as Microsoft Windows products. Thus, a Samba-enabled Unix machine can masquerade as a server on your Microsoft network and offer the following services:

Share one or more filesystems
Share printers installed on both the server and its clients
Assist clients with Network Neighborhood browsing
Authenticate clients logging onto a Windows domain
Provide or assist with WINS name server resolution

Specific to ISyE, UNIX account holders can use SAMBA to access their UNIX home directories and file shares from various Windows PCs on the ISyE network. Also, please note SAMBA access is only available from within the ISyE network.

How to map a samba share:

1. Open Windows Explorer on the local machine.
2. Select Tools->Map Network Drive (Windows XP). Select Map network drive (Windows 7).
3. Enter \\[server name][share name]. Share name is the directory that you want to map to, server name is the name of the samba server. To map to your ISyE UNIX home directory, either use your UNIX account name or the word "homes".

e.g. \\samba.isye.gatech.edu\homes

4. Click Finish.

View the Video

Running multiple iterations in condor

Thu, 06 Dec 2012 16:25:56 GMT

Many ISyE research problems involve running many separate iterations of the same code with either random or predetermined inputs. Condor excels at these types of problems.

When running on a single computer, the most common solution is set up loops and let just one or a few processes iterate through the inputs (sometimes generating random inputs along the way).

However, it is much more convenient and faster to let Condor handle the looping. If you can feed Condor multiple small jobs - anywhere from a minute to an hour in expected run time - it can spread them out onto all available resources and finish them very quickly.

Example 1: C program

We need to process 1000 different sets of input constraints using a compiled executable named "program0", written in C with the first argument being the input file.

First in our working directory we do 'mkdir in; mkdir out'. Put the data in 1000 separate files in the input directory, with names containing the integers 0 through 999. Here we will use 0.in through 999.in.

Then create the Condor submit file, 'program0.cmd':


universe    = vanilla
executable  = program0
arguments   = in/$(Process).in
output      = out/$(Process).out
error       = out/$(Process).err
queue 1000

Submit this script, and you should have 1000 jobs queued up that will iterate through your data and create 1000 output files.

Example 2 : Matlab

First, we need for our Matlab program to have an input variable for the process number, taken from Condor's $(Process) macro. Then we use that variable within the Matlab program to determine the name of the file to read.

Then the Condor submit file looks like this:


universe = vanilla
executable  = /usr/local/bin/matlab
arguments   = -singleCompThread -r clear -r procnum=$(Process)
input       = program0.m
output      = out/$(Process).out
error       = out/$(Process).err
queue 1000

Random inputs:

The above examples assume that the user has a predetermined set of input data to use, but what about generating the data at random in the program?

That can be done, but there is a major catch: the random seed needs to be the same to ensure valid randomness.

This could be accomplished by importing a constant random seed within the program. But the far easier method is to use a single program to generate the random input data you need, then set it up as in the examples above.

Why do my jobs keep restarting in condor?

Thu, 06 Dec 2012 13:56:09 GMT

Jobs in the normal Condor queues (those on Wren) are subject to preemption. When a job is preempted, it is vacated from the node and restarted elsewhere.

Jobs are usually stopped and restarted on Condor for one of four reasons:

Someone logs in locally to the execute machine. Many of our Condor compute nodes were bought by individual faculty members for their own research, and a direct shell login by one of their users will cause jobs to vacate.
You're running your job on the boyles and someone submitted an MPI job. While we have turned off priority pre-emption, parallel universe jobs will still pre-empt other jobs. The time to vacate is set at 5 calendar days. If your job does not complete within 5 calendar days, it will be vacated from the nodes in deference to the parallel universe job.
The job ran out of memory. Initially the process will be killed and the job will be restarted on another machine with more available memory. If memory usage keeps rising, eventually the job will just remain idle.
The node died while your job was running on it. This usually happens due to memory errors, which could be either yours or another user's.

How can I avoid pre-emption of my long-running jobs?

Fri, 30 Nov 2012 17:51:42 GMT

The best way to use Condor, when possible, is to break down large tasks into smaller ones and submit many small jobs rather than a few large ones. This makes preemption irrelevant because it's not a big deal if small jobs are restarted from the beginning.

For longer jobs, checkpointing is recommended.

If a job can't be easily broken down into smaller components, and it isn't checkpointed, then routine preemption can be prevented by running in the dedicated queue on hooke.

Matlab in condor

Fri, 30 Nov 2012 17:48:05 GMT

Matlab must have threading disabled for use in the normal Condor queue. To do tihs, use the command line argument "-singleCompThread".

Under Condor we can achieve total higher compute throughput without threading, and will finish more jobs faster.

When launching Matlab in batch mode from the Unix shell, the program name is piped from STDIN rather than being an argument as in some other languages.

Thus for the Matlab program "program0.m", the command line for testing would be:

matlab -singleCompThread < program0.m

Then the Condor submit script would look like this:


universe = vanilla
executable  = /usr/local/bin/matlab
arguments   = -singleCompThread
input       = program0.m
output      = program0.out
error       = program0.err
queue

CPLEX in condor

Fri, 30 Nov 2012 17:45:57 GMT

Disabling threading in CPLEX

Since version 12.2, CPlex defaults to multithreading its executables.

This is a problem for several reasons and multithreading should be disabled in almost all cases. Not only does Condor handle single threaded jobs much better, but they will usually produce better performance.

We've modified the default environment in several places but it doesn't seem to work consistently. Thus users need to manually add a line to their C/C++ programs before compilation to turn off threading.

The C function call to disable threading should be put at the beginning of main():

CPXsetintparam(env, CPX_PARAM_THREADS, 1);

In an AMPL batch file the command to turn off multithreading is:

option cplex_options 'threads=1';

Timing processes

Fri, 30 Nov 2012 17:44:16 GMT

Determining process compute time is a common need in ISyE for such tasks as comparing algorithm efficiency. However, use of real time is likely to give erroneous results due to variations in compute environment, such as higher load and more context switching on some nodes than others. It is also possible that jobs can be suspended briefly without restarting from the beginning, which could greatly throw off compute times.

If you need to measure the compute time, you should use the USER time of the process to get the actual time it has been running on the processor.

In C, this value can be extracted with the getrusage() function.

The following example program runs three counting loops, but each subsequent step includes a longer sleep(). Nevertheless, the same elapsed time is reported for each step (within a millisecond). The function timeval_subtract() is taken from this GNU tutorial determining on elapsed CPU time.


#include 
#include 
#include  

int main() {
  int i, j, k;
  struct rusage usage;
  struct timeval current;
  struct timeval previous = {0, 0}; 

  for (i=0; i<3; i++)  {
     k=0;
     for (j=0; j<100000000; j++) {
        k++;
     }
     printf("Sleeping for %d seconds after counting\n", i);
     sleep(i);
     getrusage(RUSAGE_SELF, &usage);
     timeval_subtract (¤t, &usage.ru_utime, &previous);
     printf("Part %d took %d.%06d seconds of CPU time\n",i+1,  current.tv_sec,current.tv_usec);
     previous=usage.ru_utime;
  }
} 

int timeval_subtract (result, x, y)
struct timeval *result, *x, *y;
{ 

 /* Perform the carry for the later subtraction by updating y. */
  if (x->tv_usec < y->tv_usec) {
     int nsec = (y->tv_usec - x->tv_usec) / 1000000 + 1;
     y->tv_usec -= 1000000 * nsec;
     y->tv_sec += nsec;
  }
  if (x->tv_usec - y->tv_usec > 1000000) {
     int nsec = (x->tv_usec - y->tv_usec) / 1000000;
     y->tv_usec += 1000000 * nsec;
     y->tv_sec -= nsec;
  } 

  /* Compute the time remaining */
  /* tv_usec is certainly positive */
  result->tv_sec = x->tv_sec - y->tv_sec;
  result->tv_usec = x->tv_usec - y->tv_usec; 

 /* Return 1 if result is negative. */
  return x->tv_sec < y->tv_sec;
}

Condor and library paths

Fri, 30 Nov 2012 17:42:17 GMT

Sometimes a condor job will return an error beginning with:

condor_exec.exe: error while loading shared libraries

This can happen because the software you need is not installed on the execute node, in which case you should exclude that execute node in your submit file and let us know about the problem. You can safely assume that is the problem if you're still getting the error after following the steps outlined below.

More often, the software is on the execute node but is not in its default library search path. All third-party software is installed in /opt, which is a shared network filesystem common to all execute nodes as well as some other machines, including hooke. Thus if the program works in one place, it should work everywhere IF the default library paths are the same. Sometimes they aren't. We try to keep the nodes consistent, but there are over 100 of them in many different small clusters, and sometimes they diverge.

Fortunately, the problem can be easily remedied in the user's shell environment. The search path will add the paths in the environment variable LD_LIBRARY_PATH.

Here is an example using Gurobi 4.5:

condor_exec.exe: error while loading shared libraries: libgurobi45.so: cannot open shared object file: No such file or directory

The problem here is most likely that the execute node doesn't know where to find the shared library file it needs, libgurobi45.so. It should be able to, if wren could, but sometimes that doesn't happen even though the software is actually there.

Fortunately, this is a very easy fix. We only need to find the location of libgurobi45.so, and add that directory path to our environment on the execute node.

The library should be in a fairly obvious place. All special third-party applications are installed in /opt, and most libraries are in a "lib" or "lib64" subdirectory somewhere in their application's directory tree. If we do an "ls" in /opt we find that Gurobi 4.5 is in /opt/gurobi450. It's quickly obvious from there that the most likely library path is /opt/gurobi450/linux64/lib, and an "ls" on that directory does in fact show that it contains libgurobi45.so.

Alternatively, we could use the "find" command, like this:


wren:~ $ cd /opt/gurobi
wren:/opt/gurobi $ find . -name libgurobi45.so 2>/dev/null
./linux64/lib/libgurobi45.so

Once we know the directory that contains the needed library, we need to add it to the environment variable LD_LIBRARY_PATH on the execute node. This in can be done in two ways:

1. Add it to your login profile (usually via .profile, .bashrc, or .bash_profile) and ensure "getenv = True" is in your submit file so that the execute node uses your login environment. The syntax in your login profile is:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/gurobi450/linux64/lib

This is usually the best method.

2. If for some reason you don't want your entire login environment exported on the submit node, you could add the needed environment variable to the submit file explicitly:

Environment LD_LIBRARY_PATH=/opt/gurobi450/linux64/lib

Condor submit file examples

Fri, 30 Nov 2012 17:36:24 GMT

Some example submit file syntax all would go before the "queue" command.

Force a job to run on a single node:

+Requirements = Machine == "boyle16.isye.gatech.edu"

Allow each queued process to run on any one of a specified set of multiple nodes:

+Requirements = (Machine == "boyle1.isye.gatech.edu" || Machine == "boyle2.isye.gatech.edu" || Machine == "boyle3.isye.gatech.edu")

Thus far the only method we've gotten to work is the use of a separate full test statement for each desired machine. We've seen no examples using wildcard or syntax shortcuts, and the obvious guesses fail.

Also, if all specified nodes are unavailable, the job will remain idle with LastRejMatchReason = "no match found"

To disallow specific nodes, simply replace the operator:

+Requirements = (Machine != "goddard1.isye.gatech.edu" || Machine != "goddard2.isye.gatech.edu")

This can be useful if you find that software is misconfigured on a given set of nodes, etc. We try to avoid this but it does occasionally happen.

Dedicated Queue

Fri, 30 Nov 2012 17:31:41 GMT

Condor's primary queue is oriented towards cycle harvesting. This means that jobs running in the vanilla universe on Wren are subject to preemption for one of several reasons.

Some users need to run long jobs without checkpointing, where preemption means restarting from the beginning and losing days of computing time. As a practical matter it can often mean never finishing the job at all.

To alleviate this problem we have provided a dedicated queue. This queue runs from a different submission machine, hooke (hooke.isye.gatech.edu). The queue does have a disadvantage in that it has fewer assigned machines and you may have to wait longer for a slot to open up. However, if you have just a few long-running jobs, it's the way to go.

Submitting from hooke requires only a couple of changes.

First, obviously, you must log into hooke to submit the job. This can be done simply by doing "ssh hooke" whenever your code is ready to go. You don't need to do any of the development on hooke; that should be done on wren and then just log into hooke when you're ready to submit. Once you've submitted the job, you will need to monitor it on hooke as well. Wren's queue and history will not contain the details of the job.

Finally, the submit file requires a couple of changes. The universe should be changed to "parallel", and the line "machine count = 1" needs to be added before the"queue" statement.

So an example submit file for the dedicated queue from hooke looks like this:


universe   = parallel
executable = mycode
output     = mycode.out
error      = mycode.err
arguments  = 10 20
machine_count = 1
queue

Once you have this in place you can submit the job normally via "condor_submit", and the job should normally run to completion rather than being subject to preemption.

MPI Jobs

Fri, 30 Nov 2012 17:25:14 GMT

Condor supports high-speed distributed parallel computing using OpenMPI. MPI jobs require use of the dedicated queue on hooke, and can't be submitted from wren.

MPI jobs are run on the Boyle nodes, consisting of 16 eight-core machines with a low-latency Infiniband cross-connect between the nodes. OpenMPI jobs automatically use the fastest available transport method for message passing between processes.

Condor handles MPI jobs via a front end wrapper script called ompiscript (full path: /usr/local/bin/ompiscript). This wrapper is submitted as the executable name, and the submitter's MPI executable becomes the first command line argument. The wrapper automates all of the usual tasks associated with starting an MPI job: creates a hosts file, does the "mpirun" command, and takes care of passwordless ssh access.

Of course it remains crucial that users make sure their MPI code works in the shell before submitting it to Condor.

Submit file examples follow.

Example 1: running on any available nodes

The generic form of MPI submission will run on any available CPU (currently this means just on the boyle nodes). Contact IT first if you intend to submit an MPI job to more than 32 CPUs.

universe = parallel
executable = /usr/local/bin/ompiscript
arguments = exe1 argv1 argv2 ....
getenv = True          ## needed for your env to be present on execute nodes
output = exe1.out   ## stdout
error = exe.err    ## stderr
machine_count = 32
queue

If you want separate output files for each process, you can use a macro like this:

output = out/exe1.out.$(NODE)
error = out/exe1.err.$(NODE)

Example 2: Running a job on a specific node

If a job is run on 8 CPUs it can be kept on a single node, which will produce slightly faster interprocess communication. The user will need to find a node with no jobs currently running on it and specify that node in the command file.

universe = parallel
executable = /usr/local/bin/ompiscript
arguments = exe2 argv1 argv2 ....
getenv = True

output = exe2.out
error = exe2.err
machine_count = 8
queue

Using the ISyE Virtual Private Network (VPN)

Tue, 06 Nov 2012 23:28:07 GMT

Problem:

I am a faculty or staff member and need access to the ISyE network (VPN access is not available to students).

Solution:

For anyone connecting to the internet, through any means and from any location, running the VPN client software provides a secure virtual connection between your computer and the ISyE computer network. This technology allows you to take advantage of all network related services offered within the department from any location. Please note that VPN accounts are available for ISyE faculty and staff only.

Receiving and sending email is easier (with no 'server' configuration changes as are required currently), SAMBA (remote file sharing services) will now be available from remote locations as well as a number of other services coming on line over the next year. One last significant benefit is that VPN encrypts all data transferred between your computer and the ISyE network. This helps to protect your passwords, email and any other sensitive data that might be transmitted. If you would like more information on VPN, or are interested in getting setup to use VPN from home or from a laptop, please read the following.

NEW Cisco ISYE VPN Installation Instructions

Direct your browser to http://vpn.isye.gatech.edu.
Log in with your ISyE username and password.
The system will check to see if the client is installed. If it is not, it will prompt you to download and install it.
When the client is installed, the web page will start the client and begin the connection process.
The Cisco client is the same one used by Georgia Tech for campus-wide VPN access. Sometimes, if you have accessed the Georgia Tech VPN, it can overwrite the ISyE settings. If you see anyc.vpn.gatech.edu then the ISyE settings have been overwritten by the OIT settings. Visiting http://vpn.isye.gatech.edu again will direct the client back to ISyE.

OLD Nortel ISYE VPN Installation Instructions

1. Before proceeding, please contact Allen Belletti @4-6221 to obtain a username and ask to be added to the system. Without this step, you will not be able to access the ISyE network using the software. If you have a previous version of the VPN Client already installed, please remove it using add/remove programs under the windows control panel before installing the new version. Also, if this is the case, use the password assigned to you, not the initial password as noted below.

2. Download and run the file named VPN_Client_4_91_021.exe (3.3MB). Please note that you must have administrator rights on the local machine to install the software.

3. Accept all the installation defaults by clicking on the YES and NEXT buttons.

4. When the installation has completed, restart the computer.

5. After restart, run the Contivity VPN Client program located on the desktop or in the Nortel Networks Program Group within the Start Menu.

6. Click on NO when asked to use the Connection Wizard to create a connection.

7. Enter the following information into the appropriate fields:

Connection: Georgia Tech ISyE VPN
Description: Georgia Tech ISyE VPN
Dial-up: (None)
User Name: (Enter your current ISYE User ID)
Password: gtisyevpn (initial password only - should be changed on first connection)
Save Password: (Click on the box to place a check inside it.)
Destination: 130.207.91.149

8. Click on the SAVE button.
9. Click on the CONNECT button.
10. Change your password on first connection. To change the password, right-click on the VPN icon in the lower right corner of the screen and choose "Change Password".

***Please do not set the Contivity software to automatically load every time Windows is started. This would be quite detrimental to a laptop that was brought back onto campus, because it would needlessly route all network traffic through the VPN server.

Using SecureCRT

Thu, 20 Sep 2012 15:18:25 GMT

Problem:

I need to use an SSH client to access an ISyE server. Do you have any suggestions? I heard SecureCRT is available at ISyE.

Solution:

Access to ISyE UNIX servers is available from anywhere in the world via the ssh2 protocol. There are free and commercial ssh clients available for most platforms (UNIX/Linux, Windows and Macintosh). SecureCRT is available on most all ISyE supported computers.

Using SecureCRT to connect to an ISyE UNIX server

There are many advanced options available with ssh, but to connect to an ISyE server (e.g. castle.isye.gatech.edu) for a simple interactive login, fill in the information as shown below.

You may wish to save the session as "castle" or "ISyE" so you don't need to configure it each time you use the program. The first time you connect, the program will prompt you with this message:

If you select Accept & Save, you will not be prompted again.

NOTE:

SecureCRT supports secure file transfers, from the windows command line which can be used as a substitute for FTP. See SecureCRT-VCP File Transfer Utility for specific information on VCP.

WinSCP can also be used for secure file transfers. See WinSCP for specific information on WinSCP.

Georgia Tech Faculty & Staff can download SecureCRT and WinSCP at https://software.oit.gatech.edu/.

Securely Connecting to ISyE Servers

Thu, 20 Sep 2012 15:18:01 GMT

Problem:

I heard that telnet access was being turned off in favor of SSH2. How do I connect to an ISyE server now that this is the case?

Solution:

The main points of this article are as follows:

Use ssh instead of telnet, rlogin, or rsh when possible (these services have been turned off on many of the ISyE servers)
For a single file, use scp instead of ftp
For multiple files, use sftp instead of ftp

The problem with telnet, rlogin, rsh, and ftp is that they are not secure. Anyone who is monitoring the packets sent by your computer across the network will see everything you're doing, since it's all unencrypted. This may seem far-fetched, but it is relatively easy to monitor all traffic in a local network.

Still, you may object that you're not doing anything top-secret, so you don't mind if anyone's watching. The problem is that in addition to the work you're doing, your password is sent unencrypted across the network. That's the biggest reason for prefering a secure connection.

So, rather than use telnet, rlogin, or rsh, you should use ssh, which stands for "secure shell". All communication is encrypted using ssh. This may make logging-in a tad slower, but will be unnoticeable once you're logged in.

If you're connecting from a unix machine, it probably has ssh available already. Just type

ssh username@hostname.edu

Note that ssh won't ask you for your username like telnet does, so you need to specify it in your command. Also notice that this won't look just like your email address, since your email address doesn't really give the name of a specific computer. For example, if I wanted to log in to castle, I'd have to use:

ssh myname@castle.isye.gatech.edu

not my email address:

ssh myname@isye.gatech.edu

If you have a fast connection (not dial-up) and want to run some graphical jobs on the remote machine and have them show up on your local machine, use the -X option (capital X): ssh -X myname@host. This is called X forwarding.

If you're connecting from a PC, then ssh probably isn't present by default. Most Georgia Tech PCs have a program called SecureCRT, however, which implements the ssh protocol. Just use SecureCRT instead of whatever you used to use.

Transferring Files

For transferring files, there are two secure facilities: scp and sftp. They stand for ``secure copy'' and ``secure ftp''. scp will only do one file at a time so you have to enter your password each time:

scp localfile myname@host.edu:path/to/directory/newname

scp myname@host.edu:path/to/directory/remotefile local/dir/newname

Of course, you can leave the new name out if you want. Check the man page for more info. If you're used to ftp, it may just be easiest to use sftp, which works very similarly.

Final Advice

In order to use any of these secure protocols, computers on both ends of the connection must support them. If one of them does not, you're just going to have to revert to unencrypted methods. However, I'd contact the administrator of the uncooperative computer and let them know that you'd like ssh support added.

Good luck, and be glad that you're now using encrypted communication.

Feeling Comfortable with the Command Line

Thu, 20 Sep 2012 15:17:34 GMT

Problem:

Do you have any tips relating to feeling comfortable with using UNIX?

Solution:

If you're not already comfortable using the unix command line, this should be your first goal. As in any other environment, comfort will take time, but here are some of the basic tasks that you will want to become familiar with:

changing directories (cd)
creating, moving, and removing directories (mkdir, mv, rmdir)
listing the contents of a directory (ls)
copying, moving, and removing files (cp, mv, rm)
running programs
reading manual pages (man)
editing text files

If you're using a graphical user interface, you may be able to perform some of these tasks using graphical tools, but I recommend that you learn how to do them from the command line as well. Otherwise you may find yourself at a disadvantage if you ever log in from a PC or a remote location.

You can learn all of the above commands and more from these online tutorials on unix:

How to Run Long Jobs on the UNIX Systems

Thu, 20 Sep 2012 15:16:46 GMT

Problem:

I need to run a long job on one of the UNIX systems. What do I need to know to do this most efficiently?

Solution:

Often there is a requirement to run jobs that so long to run that sitting in front of the terminal waiting for the results is not practical. This document is intended to help users run large jobs in the "background" in such a way as to not negatively impact other users on the computers.

Most users in ISyE run the Korn Shell, thus this document assumes such use. There are a few steps to the process of running large/long jobs.

Starting the job in the "Background" so that it will continue to run after the user logs off of the computer.
Setting the running priority so the job will not negatively impact other users "interactive" use of the same computer.
Monitoring the job to make sure it is running properly and is not out of control.

The text below uses examples based on the execution of a job named myprog which requires an argument of myargs. myprog can be any program or script and myargs can be any argument or list of arguments.

Running in the Background

There are three standard ways to put a job into the Background.

Use of the nohup command
Use of the bg command
Use of an &

Using nohup

The nohup command is the preferred method for running a job in the background on any UNIX system. It is the best method for allowing the job to continue running in the background even after the user logs off of the system.

Usage: nohup myprog myargs&

The nohup command will then execute the program in the "background" and return the user to a normal command prompt. This allows the user to log off of the computer without having the job terminate.

The nohup command will trap any output to STDOUT (usually what would display to the screen) and save it in a file called nohup.out which will be located in the directory in which the command was executed.

On the Korn Shell, when the user runs the exit command to log off, the following warning message will be displayed:

You have jobs running

Typing exit a second time will successfully log off the user. Despite the warning message, the nohuped job will continue to run. Look at the manual pages for nohup for more information(man nohup).

Under some circumstances nohup can act a bit odd and hang ssh (secure shell) connections when exiting or will allow the job to be killed when the user logs out. If you experience this problem, the work around is to "double nohup" the job....

Create a script (here I name it myscript) that will run the job. It should contain something like:

#!/bin/ksh nohup myprog myargs&

chmod +x myscript to make the script executable

Then run the script:

nohup myscript&

Then log out.

exit
exit

Using bg

Jobs can be placed in the background by running them interactively:

myprog myargs

Then halting the program with a CNTRL-Z ^Z and then executing the "bg" command

bg

Which takes that last halted program and starts it running again, but now in the background.

This does NOT allow the user to log out, and thus should never be used for running Long jobs, use nohup in such circumstances. For more information on "bg" see the manual pages man bg for information on how to take a background process and make it once again the forground process, see the manual pages for the "fg" command.

Using &

Jobs can be pushed directly into the background as follows:

myprog myargs&

The end result is identical to using cntrl-Z followed by the bg command. This does NOT allow the user to log out and thus should never be used for running long jobs. Use nohup in such circumstances.

Setting Job Execution Priorities

Any jobs run in the background for an extended period of time (anything over twenty minutes as a guideline) must have their run priority changed to avoid causing other users problems.

The renice command is used to set the priority for a process.

First, the process ID number must be found:

ps -e|grep myprog

Will give output such as:

23452 pts/9 0:00 myprog

where 23452 (in this example) is the process ID number. The job can be "niced" with:

renice 10 23452

A nice value of 10 is typical for a background process. It will allow Interactive users to function properly while still giving a large portion of the CPU compute cycles to myprog.

Any background jobs not run at a nice value of 10 or higher on general access ISyE UNIX machines are subject to termination when a complaint is received. So, it is very important to use the nice command. It is the nice thing to do; hence it's name.

For more information on nicing programs see the manual pages (man) for nice and renice.

Monitoring a Background Job

The easiest way to keep an eye on a background process is with the top command. The output looks like the following:

$ top

last pid: 25120; load averages: 2.53, 1.92, 1.43
16:40:48
59 processes: 56 sleeping, 2 running, 1 on cpu
CPU states: 0.0% idle, 99.8% user, 0.2% kernel, 0.0% iowait, 0.0% swap
Memory: 512M real, 200M free, 49M swap in use, 1347M swap free

PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
23452 myuser 1 40 10 2008K 1608K run 108:10 74.08% myprog
25079 root 1 30 0 2256K 1640K run 0:02 10.29% patchadd
25009 root 1 58 0 2816K 2064K cpu 0:00 0.57% top
24993 root 1 48 0 312K 312K sleep 0:00 0.04% sh
23336 myuser 8 59 0 8968K 7560K sleep 0:01 0.02% dtwm
24991 root 1 38 0 1784K 1296K sleep 0:00 0.02% in.rlogind
178 root 1 48 0 2184K 1624K sleep 0:00 0.00% inetd
203 root 1 59 0 4680K 2920K sleep 12:26 0.00% egd.pl
188 root 5 58 0 3624K 2568K sleep 2:06 0.00% automountd
229 root 1 48 0 1696K 816K sleep 1:37 0.00% prngd
248 root 1 58 0 2688K 1352K sleep 1:24 0.00% sshd
224 root 10 53 0 3832K 3368K sleep 0:10 0.00% nscd
23006 root 1 59 0 125M 30M sleep 0:04 0.00% Xsun
199 root 9 58 0 4288K 2280K sleep 0:01 0.00% syslogd
1 root 1 58 0 816K 384K sleep 0:01 0.00% init

Notice that PID 23452 is myprog, running with a nice value of 10, accumulating 74% of the CPU time (since there are no other users on the system, the percentage if very high, it would be more evenly split if another user was on the machine). Myprog is using 2008K or 2 megabytes of memory.

The important things to look for are: that the runtime is in the range of what you expect (to make sure the job is not hung, or not working correctly). that the memory use of the program is reasonable and what you expect and that the amount of memory available on the system is much less than the maximum amount your program will require.

On the Memory: line, the first number is the real memory size of the machine and will not change. The second number is the amount of this "real" memory that is free or available to new or growing programs. If this amount is much less than what your program will need, then it should be run on a different computer.

The third line is the amount of Hard Disk space that is being used as though it were real memory. If this number is comparable to the amount of real memory (it is not in this case as 49M is much less than 512M), then the computer is over-laden with large jobs and another system should be used instead. Finally the last number is the amount of Hard Disk space that is allocated to be used as memory, but is not actively in use by the system.

The one critical factor is that the user must know the approximate amount of memory that their job will require. Then, this must be compared to the "free memory" plus the "swap free" number (the last number on the Memory: line).

If the amount of memory needed is more than ~70% of the sum of the fee swap and free memory, then the job should not be run on the given system. For this machine the calculation is:

200MB + 1347MB = 1547MB 1547MB * 0.7 = 1082.9MB

If a job will require more that 1000MB or 1GB, then the system above would be a poor choice. Keep in mind that the machine runs 100 times Slower when using the Swap (or Hard Disk) for memory. To get decent performance from the computer system, then the active memory required by the job should be no more than 120% of the free memory amount. In this case 240MB.

Matlab - running in the background.

Thu, 20 Sep 2012 15:15:46 GMT

Problem:

How do I run Matlab in the background on UNIX machines so my job will run after I log out?

Solution:

This is possible for any job that does not require a Window to be opened (no plots to the screen etc).

nohup matlab -nojvm -nodisplay < myprog.m >& myprog.log &

nohup is a generic UNIX program for running any job in the background such that the job will not terminate when the user logs out.
Without nohup, the job might run in the background just fine, but could terminate as soon as the user logs out.

-nojvm tells Matlab not to use Java Virtual Machine, which it uses to spawn windows
-nodisplay tells Matlab not to attempt to open the GUI desktop
< myprog.m feeds Matlab the program to run
>&myprog.log tells the system to write any text output by Matlab and any error messages to the file myprog.log
& tells the operating system to run the job in the background

Determining hardware and OS info on Unix servers.

Thu, 20 Sep 2012 15:14:43 GMT

Problem:

Users often need to know hardware and OS specs for Unix machines. Common needs include determining which version of software to run, documenting hardware used for computations in papers, and comparing servers to determine which is likely to run a compute job faster.

GT ISyE runs Sun Solaris and Red Hat Linux in both its commercial and free versions -- Red Hat Enterprise Linux (RHEL) and Fedora. However there is a wide mix of versions and hardware that can be confusing for users.

Solution:

To determine hardware and OS info on Linux:

"uname -a" will show kernel version and hardware platform.
"cat /etc/issue" will show the distribution and version.
"cat /proc/cpuinfo" will show processor information.
"free" will show physical RAM.

To determine this info on Solaris:

"uname -a" will print the OS version and hardware platform.
"isainfo -v" will show platform type and whether it's 32-bit or 64-bit.
"psrinfo -v" will show processor information.
"top" will show physical RAM (along with a good bit of process information).

Linux examples:

wren:~ $ uname -a
Linux wren 2.6.18-8.1.8.el5 #1 SMP Mon Jun 25 17:06:07 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux

This shows Linux kernel 2.6.18 running on a 64-bit x86 processor.

wren:~ $ free
total used free shared buffers cached
Mem: 8178540 983992 7194548 0 147216 144348
-/+ buffers/cache: 692428 7486112
Swap: 4194296 615092 3579204

The "total" column indicates the machine has 8GB physical RAM and 4GB swap space.

Solaris examples:

castle:~ $ uname -a
SunOS castle 5.9 Generic_118558-06 sun4u sparc SUNW,Ultra-4

Solaris 9 is listed as SunOS 5.9, Solaris 10 is SunOS 5.10, etc.

So Castle is a Solaris 9 server running on the UltraSparc platform, but this doesn't show whether the machine can run 64-bit code. To find out, do:

castle:~ $ isainfo -v
64-bit sparcv9 applications
32-bit sparc applications

Password Protecting an Area of your Web Site

Thu, 19 Jan 2012 20:50:34 GMT

Problem:

How can I password protect an area of my website?

Solution:

Create an .htaccess File

An .htaccess file must be created in the directory that the user wants to secure. (Multiple directories can have .htaccess files, but there can only be one .htaccess file per directory.)

Important:Access restriction applies to a certain directory, not a certain file or HTML document. Documents that are to be restricted should be put in directories separate from those you want unrestricted.

While in the directory you want to secure, create/edit a file called .htaccess using your favorite text editor.

AuthUserFile /www/users/andyh/private/.htpasswd (path to .htpasswd file) AuthGroupFile /dev/null (path to .htgroup file) AuthName "Secure Area" (title for dialog box) AuthType Basic require valid-user

(Access alternatives)

Create an encrypted password

The .htpasswd file should contain a list of usernames and passwords. The format of the password file is straightforward, one line per user, with the line containing the user name, followed by a colon, followed by the user's password encrypted with the standard Unix password encryption.

In other words, an .htpasswd can look like this:

testuser1:jKXVnZH6eXR7 testuser2:taeWr6tbTZKO6

with one line for each user.

To generate an encrypted password, visit https://www.isye.gatech.edu/intranet/modules/encrypt/
- Type in a username and password to use.
- Copy the DES encrypted password into your .htpasswd file
- For additional users, use the form again and add a line for that user to the .htpasswd file.

Check File Permissions

Make sure both the .htpasswd and .htaccess files are readable by the web server (chmod og+r .htaccess .htpasswd)

Additional Sources of Information

Apache HTTP documentation (http://httpd.apache.org/docs/howto/auth.html)
ApacheWeek article (http://www.apacheweek.com/features/userauth)
Zend article (http://www.zend.com/zend/trick/tricks-august-2001.php)

The "Limit" Statement

The set of instructions that are placed between the and statements determine how the directory can be accessed.

Here are some example situations that require different sets of instructions:

Allow access to a single user: require user [username] where username is an entry in the .htpasswd file.
Allow access to a group of people: require group [groupname] where groupname is the name of a group in the .htgroup file.
Allow access to any user inside a certain domain:
order deny,allow deny from all allow from [domain name]
where domain name is the name of the domain to allow access to (e.g. isye.gatech.edu)
Deny access to any user inside a certain domain:

order allow,deny allow from all deny from [domain name]

where domain name is the intended domain name to deny access to.