UMIACS - User contributions [en]

SLURM/JobSubmission

2017-06-28T18:30:39Z

Claw:

=Job Submission=

SLURM offers a variety of ways to run jobs. It is important to understand the different options available and how to request the resources required for a job in order for it to run successfully. All job submission should be done from submit nodes; any computational code should be run in a job allocation on compute nodes. The following commands outline how to allocate resources on the compute nodes and submit processes to be run on the allocated nodes.

==srun==
srun is the command used to run a process on the compute nodes in the cluster. It works by passing it a command (this could be a script) which will be run on a compute node and then srun will return. srun accepts many command line options to specify the resources required by the command passed to it, some common command line arguments are listed below and full documentation of all available options is available in the man page for srun which can be accessed by running <code>man srun</code>.
<pre>
tgray26@opensub01:srun --mem=100mb --time=1:00:00 bash -c 'echo "Hello World from" `hostname`'
Hello World from openlab06.umiacs.umd.edu
</pre>
It is important to understand that srun is an interactive command. By default input to srun is broadcast to all compute nodes running your process and output from the compute nodes is redirected to srun, this behavior can be changed; however, '''srun will always wait for the command passed to finish before exiting, so if you start a long running process and end your terminal session, your process will stop running on the compute nodes and your job will end'''. To run a non-interactive session that you can submit to the cluster and will remain running after you logout, you will need to wrap your srun commands in a batch script and submit it with [[#sbatch | sbatch]]
===Common srun arguments===
* <code>--mem=1gb</code> ''if no unit is given MB is assumed''
* <code>--nodes=2</code> ''if passed to srun, the given command will be run concurrently on each node''
* <code>--qos=dpart</code>
* <code>--time=hh:mm:ss</code> ''time needed to run your job''
* <code>--job-name=helloWorld</code>
* <code>--output filename</code> ''file to redirect stdout to''
* <code>--error filename</code> ''file to redirect stderr''
* <code>--partition $PNAME</code> ''request job run in the $PNAME partition''
* <code>--ntasks 2</code> ''request 2 "tasks" which map to cores on a CPU, if passed to srun the given command will be run concurrently on each core''

===Interactive Shell Sessions===
An interactive shell session on a compute node can be useful for debugging or developing code that isn't ready to be run as a batch job. To get an interactive shell on a node, use srun to invoke a shell:
<pre>
tgray26@opensub01:srun --pty --mem 1gb --time=01:00:00 bash
tgray26@openlab06:
</pre>
'''Please do not leave interactive shells running for long periods of time when you are not working. This blocks resources from being used by everyone else.'''

==salloc==
The salloc command can also be used to request resources be allocated without needing a batch script. Running salloc with a list of resources will allocate the resources you requested, create a job, and drop you into a subshell with the environment variables necessary to run commands in the newly created job allocation. When your time is up or you exit the subshell, your job allocation will be relinquished.
<pre>
tgray26@opensub00:salloc -N 1 --mem=2gb --time=01:00:00
salloc: Granted job allocation 159
tgray26@opensub00:srun /usr/bin/hostname
openlab00.umiacs.umd.edu
tgray26@opensub00:exit
exit
salloc: Relinquishing job allocation 159
</pre>
'''Please note that any commands not invoked with srun will be run locally on the submit node. Please be careful when using salloc.'''

==sbatch==
The sbatch command allows you to write a batch script to be submitted and run non-interactively on the compute nodes. To run a simple Hello World command on the compute nodes you could write a file, helloWorld.sh with the following contents:
<pre>
#!/bin/bash

srun bash -c 'echo Hello World from `hostname`'
</pre>
Then you need to submit the script with sbatch and request resources:
<pre>tgray26@opensub00:sbatch --mem=1gb --time=1:00:00 helloWorld.sh
Submitted batch job 121
</pre>
SLURM will return a job number that you can use to check the status of your job with squeue:
<pre>
tgray26@opensub00:squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
121 dpart helloWor tgray26 R 0:01 2 openlab[00-01]
</pre>
====Advanced Batch Scripts====
You can also write a batch script with all of your resources/options defined in the script itself. This is useful for jobs that need to be run 10s/100s/1000s of times. You can then handle any necessary environment setup and run commands on the resources you requested by invoking commands with srun. The srun commands can also be more complex and be told to only use portions of your entire job allocation, each of these distinct srun commands makes up one "job step". The batch script will be run on the first node allocated as part of your job allocation and each job step will be run on whatever resources you tell them to. In the following example I have a batch job that will request 2 nodes in the cluster, then I load a specific version of Python into my environment and submit two job steps, each one using one node. Since srun is blocks until the command finishes, I use the '&' operator to background the process so that both job steps can run at once; however, this means that I then need to use the wait command to block processing until all background processes have finished.
<pre>
#!/bin/bash

# Lines that begin with #SBATCH specify commands to be used by SLURM for scheduling

#SBATCH --job-name=helloWorld # sets the job name
#SBATCH --output helloWorld.out.%j # indicates a file to redirect STDOUT to; %j is the jobid
#SBATCH --error helloWorld.out.%j # indicates a file to redirect STDERR to; %j is the jobid
#SBATCH --time=00:05:00 # how long you think your job will take to complete; format=hh:mm:ss
#SBATCH --qos=dpart # set QOS, this will determine what resources can be requested
#SBATCH --nodes=2 # number of nodes to allocate for your job
#SBATCH --ntasks=4 # request 4 cpu cores be reserved for your node total
#SBATCH --ntasks-per-node=2 # request 2 cpu cores be reserved per node
#SBATCH --mem 1gb # memory required by job; if unit is not specified MB will be assumed

module load Python/2.7.9 # run any commands necessary to setup your environment

srun -N 1 --mem=512mb bash -c "hostname; python --version" & # use srun to invoke commands within your job; using an '&'
srun -N 1 --mem=512mb bash -c "hostname; python --version" & # will background the process allowing them to run concurrently
wait # wait for any background processes to complete

# once the end of the batch script is reached your job allocation will be revoked
</pre>
====More Examples====
More examples of how to use batch scripts to setup your environment for processing will be coming soon
===scancel===
The scancel command can be used to cancel job allocations or job steps that are no longer needed. It can be passed individual job IDs or an option to delete all of your jobs or jobs that meet certain criteria.
*<code>scancel 255</code> ''cancel job 255''
*<code>scancel 255.3</code> ''cancel job step 3 of job 255''
*<code>scancel --user tgray26 --partition dpart</code> ''cancel all jobs for tgray26 in the dpart partition''

=Identifying Resources and Features=
The sinfo can show you additional features of nodes in the cluster but you need to ask it to show some non-default options using a command like this
<code>sinfo -o "%15N %10c %10m %25f %10G"</code>.

<pre>
$ sinfo -o "%15N %10c %10m %25f %25G"
NODELIST CPUS MEMORY AVAIL_FEATURES GRES
openlab[00-07] 8 7822 (null) (null)
openlab08 16 128720 (null) gpu:k20:2
openlab09 16 128722 (null) gpu:3
</pre>

You can also identify further specific information about a node using [https://wiki.umiacs.umd.edu/umiacs/index.php/SLURM/ClusterStatus#scontrol scontrol].

=Requesting GPUs=
If you need to do processing on a GPU, you will need to request that your job have access to GPUs just as you need to request processors or cpu cores. You will also need to make sure that you submit your job to the correct partition since nodes with GPUs are often put into their own partition to prevent the nodes from being tied up by jobs that don't utilize GPUs. In SLURM, GPUs are considered "generic resources" also known as GRES. To request some number of GPUs be reserved/available for your job you can use the flag <code>--gres:gpu:2</code> or if there are multiple types of GPUs available in the cluster and you need a specific type, you can provide the type option to the gres flag <code>--gres:k20:1</code>
<pre>
tgray26@opensub01:srun --pty --partition gpu --gres=gpu:2 nvidia-smi
Wed Jul 13 15:33:18 2016
+------------------------------------------------------+
| NVIDIA-SMI 361.28 Driver Version: 361.28 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Tesla K20c Off | 0000:03:00.0 Off | 0 |
| 30% 24C P0 48W / 225W | 11MiB / 4799MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
| 1 Tesla K20c Off | 0000:84:00.0 Off | 0 |
| 30% 23C P0 52W / 225W | 11MiB / 4799MiB | 93% Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
</pre>
Please note that your job will only be able to see/access the GPUs you requested. If you only need 1 GPU, please request only 1 GPU and the other one will be left available for other users:
<pre>
tgray26@opensub01:srun --pty --partition gpu --gres=gpu:k20:1 nvidia-smi
Wed Jul 13 15:31:29 2016
+------------------------------------------------------+
| NVIDIA-SMI 361.28 Driver Version: 361.28 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Tesla K20c Off | 0000:03:00.0 Off | 0 |
| 30% 24C P0 50W / 225W | 11MiB / 4799MiB | 92% Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
</pre>
The <code>--gres</code> flag may also be passed to [[#sbatch | sbatch]] and [[#salloc | salloc]] rather than directly to [[#srun | srun]]

=MPI example=
<pre>
#!/usr/bin/bash
#SBATCH --job-name=mpi_test # Job name
#SBATCH --nodes=4 # Number of nodes
#SBATCH --ntasks=8 # Number of MPI ranks
#SBATCH --ntasks-per-node=2 # Number of MPI ranks per node
#SBATCH --ntasks-per-socket=1 # Number of tasks per processor socket on the node
#SBATCH --time=00:30:00 # Time limit hrs:min:sec

module load mpi

srun --mpi=openmpi /nfshomes/derek/testing/mpi/a.out
</pre>

Main Page

2016-05-25T20:30:39Z

Claw: /* Announcements */

==Announcements==
<startFeed />

Please see our [https://intranet.umiacs.umd.edu intranet] page for announcements.

<endFeed />

==Technical Reference==

Welcome to UMIACS Wiki. This is the main place to find documentation and information about your account and the technical services that UMIACS offers. If this is your first time please start here [[GettingStarted| Getting Started]].

We provide many [[CoreServices|Core Services]] which include [[EMail]], [[Backups]] and [[VPN]].

We have lots of specific [[LabFacilities|Lab Facilities]] that you may be interested in.

Please check here if you are interested in [[OrderingEquipment|Ordering Equipment]].

If you would like to open a support ticket, please contact the UMIACS [[HelpDesk]].

__NOTOC__

Main Page

2016-05-25T20:27:17Z

Claw: /* Announcements */

==Announcements==
<startFeed />

Please see our [https://intranet.umiacs.umd.edu intranet] page for announcements..

<endFeed />

==Technical Reference==

Welcome to UMIACS Wiki. This is the main place to find documentation and information about your account and the technical services that UMIACS offers. If this is your first time please start here [[GettingStarted| Getting Started]].

We provide many [[CoreServices|Core Services]] which include [[EMail]], [[Backups]] and [[VPN]].

We have lots of specific [[LabFacilities|Lab Facilities]] that you may be interested in.

Please check here if you are interested in [[OrderingEquipment|Ordering Equipment]].

If you would like to open a support ticket, please contact the UMIACS [[HelpDesk]].

__NOTOC__

FileTransferProtocol

2015-10-12T19:22:52Z

Claw:

UMIACS provides FTP services for transferring data to and from external collaborators. Since the FTP protocol is conducted entirely in plaintext, external users login to the service as anonymous, and internal users can access the file directories internally. Users will never authenticate over FTP with their UMIACS account. Please see [[SFTP]] for more information on a secure file transfer protocol.

==Getting data from Collaborators==

Collaborators can drop data for users into their FTP incoming file system, located from the FTP service at

<pre>ftp://ftp.umiacs.umd.edu/incoming/<username>/</pre>

FTP logins can write to this space to upload data, but cannot list the files they have placed there. Users can then access the data in their ftpincoming space from

* '''/fs/ftp/incoming/<username>''' from supported unix machines
* '''\\umiacs-webftp\ftp-umiacs\incoming\<username>''' - from supported windows machines

/fs is an automounted file system. This means it will mount other file systems on demand. Although the ftp directory may not be visible to an ls command while in fs, one can still cd into ftp.

Please move your data as soon as possible after it is left for you - files older than 15 days are subject to deletion as necessary.

==Publishing data sets via FTP==

Users can place data to be externally accessible in their public FTP space, which is located from the FTP service as

<pre>ftp://ftp.umiacs.umd.edu/pub/<username>/</pre>

To upload data to your public site, you can upload data to,

* '''/fs/ftp/pub/<username>''' from supported unix machines
* '''\\umiacs-webftp\ftp-umiacs\pub\<username>''' - from supported windows machines

==Effects of tmpwatch==
There is a configuration of tmpwatch[http://linux.die.net/man/8/tmpwatch] in place on our FTP service that will remove any files, regardless of owner or permissions, from any /fs/ftp/incoming/ directory that have not been accessed in 30 days.

FileTransferProtocol

2015-10-12T19:22:41Z

Claw:

FileTransferProtocol

2015-10-09T15:21:40Z

Claw:

UMIACS provides FTP services for transferring data to and from external collaborators. Since the FTP protocol is conducted entirely in plaintext, external users login to the service as anonymous, and internal users can access the file directories internally. Users will never authenticate over FTP with their UMIACS account. Please see [[SFTP]] for more information on a secure file transfer protocol.

==Getting data from Collaborators==

Collaborators can drop data for users into their FTP incoming file system, located from the FTP service at

<pre>ftp://ftp.umiacs.umd.edu/incoming/<username>/</pre>

FTP logins can write to this space to upload data, but cannot list the files they have placed there. Users can then access the data in their ftpincoming space from

* '''/fs/ftp/incoming/<username>''' from supported unix machines
* '''\\umiacs-webftp\ftp-umiacs\incoming\<username>''' - from supported windows machines

/fs is an automounted file system. This means it will mount other file systems on demand. Although the ftp directory may not be visible to an ls command while in fs, one can still cd into ftp.

Please move your data as soon as possible after it is left for you - files older than 15 days are subject to deletion as necessary.

==Publishing data sets via FTP==

Users can place data to be externally accessible in their public FTP space, which is located from the FTP service as

<pre>ftp://ftp.umiacs.umd.edu/pub/<username>/</pre>

To upload data to your public site, you can upload data to,

* '''/fs/ftp/pub/<username>''' from supported unix machines
* '''\\umiacs-webftp\ftp-umiacs\pub\<username>''' - from supported windows machines

==Effects of tmpwatch==
There is a configuration of tmpwatch[http://linux.die.net/man/8/tmpwatch] in place on our FTP service that will remove any files, regardless of owner or permissions, from the shared resource that have not been accessed in 30 days.

Screen

2015-01-06T23:23:48Z

Claw: /* .screenrc */

=== Introduction ===
GNU Screen, or "screen", is a window management program available on UMIACS Linux hosts that allows multiplexing of a single terminal between multiple virtual consoles. Screen is also capable of separating programs from the shell that initially started it which allows a program to continue running even if the connection to the host has been lost. For this reason screen is typically used when a network connection is unstable and the process must remain running even if an SSH connection has dropped.

=== Usage ===
To invoke screen, simply use the following command in a terminal:
# screen

Alternatively, to start a program with screen:
# screen vi program.c
This will invoke screen and, in the newly-created window, start editing the file program.c in vi.

You can have as many screen sessions as you’d like on a single host, however, keeping track of many sessions can become difficult. As a way to solve this screen offers the capability to give each session a unique name when you start it using the following:
# screen -S [session name]

If you need to end your ssh session, but want your processes to keep running you can detach the screen session with:
# screen -d
Then exit as normal.

If you have multiple screen sessions you can detach and reattach them at any time. To list the current screen sessions running on a host use:
# screen -ls

The output will be similar to this:
# claw@idaho:~$ screen -ls
# There are screens on:
# 26598.screenTest1 (Detached)
# 18457.pts-0.idaho (Detached)
# 2 Sockets in /var/run/screen/S-claw.

To reconnect to a specific screen session you may use either the screen number or name to reconnect using ‘screen -r’
# claw@idaho:~$ screen -r 26598

or

# claw@idaho:~$ screen -r screenTest1

===Common Keyboard Shortcuts===
Ctrl-A is the metacharacter for commands in screen; press it before every key command. Some useful commands in screen:

* Ctrl-A + c (Creates a new window.)
* Ctrl-A + d (detach from current session)
* Ctrl-A + [0-9] (Switches to the window corresonding to the number, window 0 is the first window initialized by screen.)
* Ctrl-A + " (Presents a selection of screen windows from which to choose.)
* Ctrl-A + Shift-A Rename the current screen window
* Ctrl-A + <SPC> / Ctrl-A + <BKSPC> (Switch to the next / previous window.)
* Ctrl-A + k (Kill the current window.)
* Ctrl-A + \ (Kill the screen session and all its windows.)

See the documentation [http://www.gnu.org/software/screen/manual/screen.txt here] to see a full list of Ctrl-A commands (Section 5.1: Default Key Bindings).

=== Important Notes ===
If you start a screen session that will run a program within a session that has only one window, such as by issuing the command
# screen program.c
then when the program exits the screen session will terminate as well. This has the potential to hide any output you may want from your program since the screen session will exit. To solve this issue you can either make sure your shell is not set to auto-logout, or ensure that you have multiple windows open in the screen session so that it will not terminate when the program exits.

=== .screenrc ===
Similar to .bashrc, the file .screenrc in a user's home directory can be used to customize a screen session's startup behavior. Commands listed in this file will be executed upon starting screen, and can be useful to set up your environment to display important information such as the window number and name, the name of the host you're connected to, or altering the key sequences for screen commands. See the link [http://www.gnu.org/software/screen/manual/screen.txt here] for more information about screen commands (Section 5.2: Command Summary).

=== Useful Links ===
* [http://www.gnu.org/software/screen/ The main page at www.gnu.org.]
* [http://www.gnu.org/software/screen/manual/screen.txt GNU Screen documentation] (also accessed through '''man screen''').

Screen

2015-01-06T23:23:17Z

Claw:

=== Introduction ===
GNU Screen, or "screen", is a window management program available on UMIACS Linux hosts that allows multiplexing of a single terminal between multiple virtual consoles. Screen is also capable of separating programs from the shell that initially started it which allows a program to continue running even if the connection to the host has been lost. For this reason screen is typically used when a network connection is unstable and the process must remain running even if an SSH connection has dropped.

=== Usage ===
To invoke screen, simply use the following command in a terminal:
# screen

Alternatively, to start a program with screen:
# screen vi program.c
This will invoke screen and, in the newly-created window, start editing the file program.c in vi.

You can have as many screen sessions as you’d like on a single host, however, keeping track of many sessions can become difficult. As a way to solve this screen offers the capability to give each session a unique name when you start it using the following:
# screen -S [session name]

If you need to end your ssh session, but want your processes to keep running you can detach the screen session with:
# screen -d
Then exit as normal.

If you have multiple screen sessions you can detach and reattach them at any time. To list the current screen sessions running on a host use:
# screen -ls

The output will be similar to this:
# claw@idaho:~$ screen -ls
# There are screens on:
# 26598.screenTest1 (Detached)
# 18457.pts-0.idaho (Detached)
# 2 Sockets in /var/run/screen/S-claw.

To reconnect to a specific screen session you may use either the screen number or name to reconnect using ‘screen -r’
# claw@idaho:~$ screen -r 26598

or

# claw@idaho:~$ screen -r screenTest1

===Common Keyboard Shortcuts===
Ctrl-A is the metacharacter for commands in screen; press it before every key command. Some useful commands in screen:

* Ctrl-A + c (Creates a new window.)
* Ctrl-A + d (detach from current session)
* Ctrl-A + [0-9] (Switches to the window corresonding to the number, window 0 is the first window initialized by screen.)
* Ctrl-A + " (Presents a selection of screen windows from which to choose.)
* Ctrl-A + Shift-A Rename the current screen window
* Ctrl-A + <SPC> / Ctrl-A + <BKSPC> (Switch to the next / previous window.)
* Ctrl-A + k (Kill the current window.)
* Ctrl-A + \ (Kill the screen session and all its windows.)

See the documentation [http://www.gnu.org/software/screen/manual/screen.txt here] to see a full list of Ctrl-A commands (Section 5.1: Default Key Bindings).

=== Important Notes ===
If you start a screen session that will run a program within a session that has only one window, such as by issuing the command
# screen program.c
then when the program exits the screen session will terminate as well. This has the potential to hide any output you may want from your program since the screen session will exit. To solve this issue you can either make sure your shell is not set to auto-logout, or ensure that you have multiple windows open in the screen session so that it will not terminate when the program exits.

=== .screenrc ===
Similar to .bashrc, the file .screenrc in a user's home directory can be used to customize a screen session's startup behavior. Commands listed in this file will be executed upon starting screen, and can be useful to set up your environment to display important information such as the window number and name, the hostname you're connected to, or altering the key sequences for screen commands. See the link [http://www.gnu.org/software/screen/manual/screen.txt here] for more information about screen commands (Section 5.2: Command Summary).

=== Useful Links ===
* [http://www.gnu.org/software/screen/ The main page at www.gnu.org.]
* [http://www.gnu.org/software/screen/manual/screen.txt GNU Screen documentation] (also accessed through '''man screen''').

Screen

2015-01-06T23:18:37Z

Claw:

=== Introduction ===
GNU Screen, or "screen", is a window management program available on UMIACS Linux hosts that allows multiplexing of a single terminal between multiple virtual consoles. Screen is also capable of separating programs from the shell that initially started it which allows a program to continue running even if the connection to the host has been lost. For this reason screen is typically used when a network connection is unstable and the process must remain running even if an SSH connection has dropped.

=== Usage ===
To invoke screen, simply use the following command in a terminal:
# screen

Alternatively, to start a program with screen:
# screen vi program.c
This will invoke screen and, in the newly-created window, start editing the file program.c in vi.

You can have as many screen sessions as you’d like on a single host, however, keeping track of many sessions can become difficult. As a way to solve this screen offers the capability to give each session a unique name when you start it using the following:
# screen -S [session name]

If you need to end your ssh session, but want your processes to keep running you can detach the screen session with:
# screen -d
Then exit as normal.

If you have multiple screen sessions you can detach and reattach them at any time. To list the current screen sessions running on a host use:
# screen -ls

The output will be similar to this:
# claw@idaho:~$ screen -ls
# There are screens on:
# 26598.screenTest1 (Detached)
# 18457.pts-0.idaho (Detached)
# 2 Sockets in /var/run/screen/S-claw.

To reconnect to a specific screen session you may use either the screen number or name to reconnect using ‘screen -r’
# claw@idaho:~$ screen -r 26598

or

# claw@idaho:~$ screen -r screenTest1

===Common Keyboard Shortcuts===
Ctrl-A is the metacharacter for commands in screen; press it before every key command. Some useful commands in screen:

* Ctrl-A + c (Creates a new window.)
* Ctrl-A + d (detach from current session)
* Ctrl-A + [0-9] (Switches to the window corresonding to the number, window 0 is the first window initialized by screen.)
* Ctrl-A + " (Presents a selection of screen windows from which to choose.)
* Ctrl-A + Shift-A Rename the current screen window
* Ctrl-A + <SPC> / Ctrl-A + <BKSPC> (Switch to the next / previous window.)
* Ctrl-A + k (Kill the current window.)
* Ctrl-A + \ (Kill the screen session and all its windows.)

See the documentation [http://www.gnu.org/software/screen/manual/screen.txt here] to see a full list of Ctrl-A commands (Section 5.1: Default Key Bindings).

=== Important Notes ===
If you start a screen session that will run a program within a session that has only one window, such as by issuing the command
# screen program.c
then when the program exits the screen session will terminate as well. This has the potential to hide any output you may want from your program since the screen session will exit. To solve this issue you can either make sure your shell is not set to auto-logout, or ensure that you have multiple windows open in the screen session so that it will not terminate when the program exits.

=== .screenrc ===
Similar to .bashrc, the file .screenrc in a user's home directory can be used to customize a screen session's startup behavior. Commands listed in this file will be executed upon starting screen, and can be useful to set up your environment the same way for each session. See the link [http://www.gnu.org/software/screen/manual/screen.txt here] for more information about screen commands (Section 5.2: Command Summary).

=== Useful Links ===
* [http://www.gnu.org/software/screen/ The main page at www.gnu.org.]
* [http://www.gnu.org/software/screen/manual/screen.txt GNU Screen documentation] (also accessed through '''man screen''').

Screen

2015-01-06T23:16:01Z

Claw:

=== Introduction ===
GNU Screen, or "screen", is a window management program available on UMIACS Linux hosts that allows multiplexing of a single terminal between multiple virtual consoles. Screen is also capable of separating programs from the shell that initially started it which allows a program to continue running even if the connection to the host has been lost. For this reason screen is typically used when a network connection is unstable and the process must remain running even if an SSH connection has dropped.

=== Usage ===
To invoke screen, simply use the following command in a terminal:
# screen

Alternatively, to start a program with screen:
# screen vi program.c
This will invoke screen and, in the newly-created window, start editing the file program.c in vi.

You can have as many screen sessions as you’d like on a single host, however, keeping track of many sessions can become difficult. As a way to solve this screen offers the capability to give each session a unique name when you start it using the following:
# screen -S [session name]

If you need to end your ssh session, but want your processes to keep running you can detach the screen session with:
# screen -d
Then exit as normal.

If you have multiple screen sessions you can detach and reattach them at any time. To list the current screen sessions running on a host use:
# screen -ls

The output will be similar to this:
# claw@idaho:~$ screen -ls
# There are screens on:
# 26598.screenTest1 (Detached)
# 18457.pts-0.idaho (Detached)
# 2 Sockets in /var/run/screen/S-claw.

To reconnect to a specific screen session you may use either the screen number or name to reconnect using ‘screen -r’
# claw@idaho:~$ screen -r 26598

or

# claw@idaho:~$ screen -r screenTest1

===Common Keyboard Shortcuts===
Ctrl-A is the metacharacter for commands in screen; press it before every key command. Some useful commands in screen:

* Ctrl-A + c (Creates a new window.)
* Ctrl-A + d (detach from current session)
* Ctrl-A + [0-9] (Switches to the window corresonding to the number, window 0 is the first window initialized by screen.)
* Ctrl-A + " (Presents a selection of screen windows from which to choose.)
* Ctrl-A + Shift-A Rename the current screen window
* Ctrl-A + <SPC> / Ctrl-A + <BKSPC> (Switch to the next / previous window.)
* Ctrl-A + k (Kill the current window.)
* Ctrl-A + \ (Kill the screen session and all its windows.)

See the documentation [http://www.gnu.org/software/screen/manual/screen.txt here] to see a full list of Ctrl-A commands (Section 5.1: Default Key Bindings).

=== Important Notes ===
If you start a program within a screen session that has only one window then when the program exits the screen session will terminate as well. This has the potential to hide any output you may want from your program since the screen session will exit. To solve this issue you can either make sure your shell is not set to auto-logout, or ensure that you have multiple windows open in the screen session so that it will not terminate when the program exits.

=== .screenrc ===
Similar to .bashrc, the file .screenrc in a user's home directory can be used to customize each screen session's startup behavior. Commands listed in this file will be executed upon starting screen. See the link [http://www.gnu.org/software/screen/manual/screen.txt here] for more information about screen commands (Section 5.2: Command Summary).

=== Useful Links ===
* [http://www.gnu.org/software/screen/ The main page at www.gnu.org.]
* [http://www.gnu.org/software/screen/manual/screen.txt GNU Screen documentation] (also accessed through '''man screen''').

Screen

2015-01-05T21:13:04Z

Claw:

=== Introduction ===
GNU Screen, or "screen", is a window management program available on UMIACS Linux hosts that allows multiplexing of a single terminal between multiple virtual consoles. Screen is also capable of separating programs from the shell that initially started it which allows a program to continue running even if the connection to the host has been lost. For this reason screen is typically used when a network connection is unstable and the process must remain running even if an SSH connection has dropped.

=== Usage ===
To invoke screen, simply use the following command in a terminal:
# screen

Alternatively, to start a program with screen:
# screen vi program.c
This will invoke screen and, in the newly-created window, start editing the file program.c in vi.

You can have as many screen sessions as you’d like on a single host, however, keeping track of many sessions can become difficult. As a way to solve this screen offers the capability to give each session a unique name when you start it using the following:
# screen -S [session name]

If you need to end your ssh session, but want your processes to keep running you can detach the screen session with:
# screen -d
Then exit as normal.

If you have multiple screen sessions you can detach and reattach them at any time. To list the current screen sessions running on a host use:
# screen -ls

The output will be similar to this:
# claw@idaho:~$ screen -ls
# There are screens on:
# 26598.screenTest1 (Detached)
# 18457.pts-0.idaho (Detached)
# 2 Sockets in /var/run/screen/S-claw.

To reconnect to a specific screen session you may use either the screen number or name to reconnect using ‘screen -r’
# claw@idaho:~$ screen -r 26598

or

# claw@idaho:~$ screen -r screenTest1

===Common Keyboard Shortcuts===
Ctrl-A is the metacharacter for commands in screen; press it before every key command. Some useful commands in screen:

* Ctrl-A + c (Creates a new window.)
* Ctrl-A + d (detach from current session)
* Ctrl-A + [0-9] (Switches to the window corresonding to the number, window 0 is the first window initialized by screen.)
* Ctrl-A + " (Presents a selection of screen windows from which to choose.)
* Ctrl-A + Shift-A Rename the current screen window
* Ctrl-A + <SPC> / Ctrl-A + <BKSPC> (Switch to the next / previous window.)
* Ctrl-A + k (Kill the current window.)
* Ctrl-A + \ (Kill the screen session and all its windows.)

See the documentation [http://www.gnu.org/software/screen/manual/screen.txt here] to see a full list of Ctrl-A commands (Section 5.1: Default Key Bindings).

=== .screenrc ===
Similar to .bashrc, the file .screenrc in a user's home directory can be used to customize each screen session's startup behavior. Commands listed in this file will be executed upon starting screen. See the link [http://www.gnu.org/software/screen/manual/screen.txt here] for more information about screen commands (Section 5.2: Command Summary).

=== Useful Links ===
* [http://www.gnu.org/software/screen/ The main page at www.gnu.org.]
* [http://www.gnu.org/software/screen/manual/screen.txt GNU Screen documentation] (also accessed through '''man screen''').

Screen

2015-01-05T21:06:52Z

Claw:

=== Introduction ===
GNU Screen, or "screen", is a window management program available on UMIACS Linux hosts that allows multiplexing of a single terminal between multiple virtual consoles. Screen is also capable of separating programs from the shell that initially started it which allows a program to continue running even if the connection to the host has been lost. For this reason screen is typically used when a network connection is unstable and the process must remain running even if an SSH connection has dropped.

=== Usage ===
To invoke screen, simply use the following command in a terminal:
# screen

Alternatively, to start a program with screen:
# screen vi program.c
This will invoke screen and, in the newly-created window, start editing the file program.c in vi.

You can have as many screen sessions as you’d like on a single host, however, keeping track of many sessions can become difficult. As a way to solve this screen offers the capability to give each session a unique name when you start it using the following:
# screen -S [session name]

If you need to end your ssh session, but want your processes to keep running you can detach the screen session with:
# screen -d
Then exit as normal.

If you have multiple screen sessions you can detach and reattach them at any time. To list the current screen sessions running on a host use:
# screen -ls

The output will be similar to this:
# claw@idaho:~$ screen -ls
# There are screens on:
# 26598.screenTest1 (Detached)
# 18457.pts-0.idaho (Detached)
# 2 Sockets in /var/run/screen/S-claw.

To reconnect to a specific screen session you may use either the screen number or name to reconnect using ‘screen -r’
# claw@idaho:~$ screen -r 26598

or

# claw@idaho:~$ screen -r screenTest1

===Common Keyboard Shortcuts===
Ctrl-A is the metacharacter for commands in screen; press it before every key command. Some useful commands in screen:

* Ctrl-A + c (Creates a new window.)
* Ctrl-A + d (detach from current session)
* Ctrl-A + [0-9] (Switches to the window corresonding to the number, window 0 is the first window initialized by screen.)
* Ctrl-A + " (Presents a selection of screen windows from which to choose.)
* Ctrl-A + Shift-A Rename the current screen window
* Ctrl-A + <SPC> / Ctrl-A + <BKSPC> (Switch to the next / previous window.)
* Ctrl-A + k (Kill the current window.)
* Ctrl-A + \ (Kill the screen session and all its windows.)

See the documentation linked in this page to see a full list of Ctrl-A commands (5.1 Default Key Bindings).

=== .screenrc ===
Similar to .bashrc, the file .screenrc in a user's home directory can be used to customize each screen session's startup behavior. Commands listed in this file will be executed upon starting screen. See the link to documentation on screen at the bottom of this page for more information about screen commands (5.2 Command Summary).

=== Useful Links ===
* [http://www.gnu.org/software/screen/ The main page at www.gnu.org.]
* [http://www.gnu.org/software/screen/manual/screen.txt GNU Screen documentation] (also accessed through '''man screen''').

SecureShell

2015-01-05T18:12:51Z

Claw: /* Unstable Connections */

Secure Shell (or [http://en.wikipedia.org/wiki/Secure_Shell SSH]) is a network protocol allowing two computers to exchange data securely over an insecure network. By default, use of SSH brings the user to a terminal, but the protocol can be used for other types of data transfer such as [[SFTP]] and [[SCP]].

==Connecting to an SSH Server==
Under Linux and Mac OS X, the following command from a terminal will connect a client computer to the UMIACS [[OpenLAB]].
# ssh bkirz@openlab.umiacs.umd.edu
This will give you access to a terminal on any one of the [[OpenLAB]] servers. Note that by default you will not have access to applications that require X11 to run.

All UMIACS Windows hosts are installed with SSH Secure Shell Client. Alternatively, users can install these software on their personal machines:

* [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY]
* [http://ttssh2.sourceforge.jp/ ttssh2]

Alternatively, all users can launch terminal sessions [[JuniperVPNTerminalSession| through the Juniper VPN web interface.]]

==X11 Forwarding==
By default, SSH only gives the user shell access to a host. Enabling X11 Forwarding allows users to run applications with Graphical User Interfaces.

Under Linux and Mac OS X, the following command from a terminal will connect a client computer to the UMIACS [[OpenLAB]] using X11 Forwarding.
# ssh '''-Y''' bkirz@openlab.umiacs.umd.edu

If you do not have Cygwin, you will need to forward X through
[http://sourceforge.net/projects/vcxsrv/ VcXsrv] or
[http://www.straightrunning.com/XmingNotes/ Xming].
First, enable X forwarding on your secure ssh client. The option is under tunneling in the ssh client settings, shown below. This only has to be done once.

[[Image:sshXForward.jpg]]

Next, click save in the main ssh appication window to save this setting.

After this has been done, every time you want to use X forwarding, you need to make sure VcXsrv or Xming has been started (it will appear in your task tray) through the start menu programs.
Now, you will be able to use Xwindow programs from your ssh client.

==SSH Tunneling==

You can tunnel one or more ports through an SSH connection such that your packets will look like they are coming from the host you are tunneling to. This is helpful for services that you would be normally blocked by a firewall.

Please see the [[SecureShellTunneling]] page for more information.

==SSH Keys (and Passwordless SSH)==

There are some situations where it is important to be able to ssh without entering a password. This is mostly required when working in clusters. This is done using ssh keys. Instead of authenticating with a password, ssh can use a pre-defined set of encryption keys to establish an authorized connection.
To setup passwordless ssh, do the following.

First, you will need to create a ssh [http://en.wikipedia.org/wiki/Key_pair key pair]. It is possible to use a password that you will need to enter at the beginning of your work session. This is preferable as it is more secure but may cause problems for some clustered work, particularly our TORQUE/MAUI clusters. If you simply hit '''[enter]''', you will never be prompted for a password when ssh'ing which can lead to security problems.

# To create a '''''passwordless''''' key, type the following. '''NOTE: This is ''REQUIRED'' for our [[ClusterGuide|TORQUE/MAUI]]-based clusters!''' <pre> # ssh-keygen -N ""</pre>
#: Alternatively, to create a '''''passphrase-protected''''' (more-secure) key, type the following. Do not use this option if you plan to use any of our [[ClusterGuide|TORQUE/MAUI]]-based clusters.<pre> # ssh-keygen</pre>
#This will produce two files, '''id_rsa''' and '''id_rsa.pub''', the private and public keys, respectively. The default location will be ~/.ssh/. For the purposes of this tutorial we'll assume this default. Once you've created the keys, you will need to put them into place as follows:
# chmod 700 ~/.ssh
# chmod 600 ~/.ssh/id_rsa
# touch ~/.ssh/authorized_keys2
# chmod 600 ~/.ssh/authorized_keys2
# cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys2
# rm ~/.ssh/id_rsa.pub

*It is '''very''' important that you keep your private key secure! Ensure that it is chmod'd to 600 and that you do not put it anywhere visible to other users!
*You must also make sure that no other users may write to your .ssh directory. This includes making sure that your home directory is not writable by group. Your home directory should be chmod'd to 750 or 700 to make sure of this. If the group write bit is set, your ssh keys '''WILL NOT WORK'''

If you did not select a passphrase when you generated your keys, you can now ssh without a password. If you did select a passphrase, you will need to activate the keys as follows:

# ssh-agent [SHELL]
# ssh-add -t [TIME]

In this case, "[SHELL]" is your preferred shell and "[TIME]" is the amount of time you'd like the key to be active in seconds. So, the following would start a bash shell with passwordless ssh active for 30 minutes:

# ssh-agent bash
# ssh-add -t 1800

You will be prompted for your passphrase and, when entered correctly, you will be able to ssh without entering a password.

To disable this functionality, simply delete your private key file ('''~/.ssh/id_rsa''') and remove the public key from your '''~/.ssh/authorized_keys2''' file.

==Unstable Connections==
If you are dealing with an unstable connection you may want to run your processes inside a screen on the host that you're connecting to. This way, if the connection is dropped for any reason the screen session will automatically detach on the host and will continue running so that you can reattach it at a later time when you've connected again. Please see our documentation on [[Screen | GNU Screen]] for more information.

==Further Information==
[http://www.openssh.org/ OpenSSH]

[http://www.openssh.com/windows.html Windows Clients]

SecureShell

2015-01-05T18:12:09Z

Claw:

Secure Shell (or [http://en.wikipedia.org/wiki/Secure_Shell SSH]) is a network protocol allowing two computers to exchange data securely over an insecure network. By default, use of SSH brings the user to a terminal, but the protocol can be used for other types of data transfer such as [[SFTP]] and [[SCP]].

==Connecting to an SSH Server==
Under Linux and Mac OS X, the following command from a terminal will connect a client computer to the UMIACS [[OpenLAB]].
# ssh bkirz@openlab.umiacs.umd.edu
This will give you access to a terminal on any one of the [[OpenLAB]] servers. Note that by default you will not have access to applications that require X11 to run.

All UMIACS Windows hosts are installed with SSH Secure Shell Client. Alternatively, users can install these software on their personal machines:

* [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY]
* [http://ttssh2.sourceforge.jp/ ttssh2]

Alternatively, all users can launch terminal sessions [[JuniperVPNTerminalSession| through the Juniper VPN web interface.]]

==X11 Forwarding==
By default, SSH only gives the user shell access to a host. Enabling X11 Forwarding allows users to run applications with Graphical User Interfaces.

Under Linux and Mac OS X, the following command from a terminal will connect a client computer to the UMIACS [[OpenLAB]] using X11 Forwarding.
# ssh '''-Y''' bkirz@openlab.umiacs.umd.edu

If you do not have Cygwin, you will need to forward X through
[http://sourceforge.net/projects/vcxsrv/ VcXsrv] or
[http://www.straightrunning.com/XmingNotes/ Xming].
First, enable X forwarding on your secure ssh client. The option is under tunneling in the ssh client settings, shown below. This only has to be done once.

[[Image:sshXForward.jpg]]

Next, click save in the main ssh appication window to save this setting.

After this has been done, every time you want to use X forwarding, you need to make sure VcXsrv or Xming has been started (it will appear in your task tray) through the start menu programs.
Now, you will be able to use Xwindow programs from your ssh client.

==SSH Tunneling==

You can tunnel one or more ports through an SSH connection such that your packets will look like they are coming from the host you are tunneling to. This is helpful for services that you would be normally blocked by a firewall.

Please see the [[SecureShellTunneling]] page for more information.

==SSH Keys (and Passwordless SSH)==

There are some situations where it is important to be able to ssh without entering a password. This is mostly required when working in clusters. This is done using ssh keys. Instead of authenticating with a password, ssh can use a pre-defined set of encryption keys to establish an authorized connection.
To setup passwordless ssh, do the following.

First, you will need to create a ssh [http://en.wikipedia.org/wiki/Key_pair key pair]. It is possible to use a password that you will need to enter at the beginning of your work session. This is preferable as it is more secure but may cause problems for some clustered work, particularly our TORQUE/MAUI clusters. If you simply hit '''[enter]''', you will never be prompted for a password when ssh'ing which can lead to security problems.

# To create a '''''passwordless''''' key, type the following. '''NOTE: This is ''REQUIRED'' for our [[ClusterGuide|TORQUE/MAUI]]-based clusters!''' <pre> # ssh-keygen -N ""</pre>
#: Alternatively, to create a '''''passphrase-protected''''' (more-secure) key, type the following. Do not use this option if you plan to use any of our [[ClusterGuide|TORQUE/MAUI]]-based clusters.<pre> # ssh-keygen</pre>
#This will produce two files, '''id_rsa''' and '''id_rsa.pub''', the private and public keys, respectively. The default location will be ~/.ssh/. For the purposes of this tutorial we'll assume this default. Once you've created the keys, you will need to put them into place as follows:
# chmod 700 ~/.ssh
# chmod 600 ~/.ssh/id_rsa
# touch ~/.ssh/authorized_keys2
# chmod 600 ~/.ssh/authorized_keys2
# cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys2
# rm ~/.ssh/id_rsa.pub

*It is '''very''' important that you keep your private key secure! Ensure that it is chmod'd to 600 and that you do not put it anywhere visible to other users!
*You must also make sure that no other users may write to your .ssh directory. This includes making sure that your home directory is not writable by group. Your home directory should be chmod'd to 750 or 700 to make sure of this. If the group write bit is set, your ssh keys '''WILL NOT WORK'''

If you did not select a passphrase when you generated your keys, you can now ssh without a password. If you did select a passphrase, you will need to activate the keys as follows:

# ssh-agent [SHELL]
# ssh-add -t [TIME]

In this case, "[SHELL]" is your preferred shell and "[TIME]" is the amount of time you'd like the key to be active in seconds. So, the following would start a bash shell with passwordless ssh active for 30 minutes:

# ssh-agent bash
# ssh-add -t 1800

You will be prompted for your passphrase and, when entered correctly, you will be able to ssh without entering a password.

To disable this functionality, simply delete your private key file ('''~/.ssh/id_rsa''') and remove the public key from your '''~/.ssh/authorized_keys2''' file.

==Unstable Connections==
If you are dealing with an unstable connection you may want to run your processes inside a screen on the host that you're connecting to. This way, if the connection is dropped for any reason the screen session will automatically detach from the host and will continue running so that you can reattach it at a later time when you've connected again. Please see our documentation on [[Screen | GNU Screen]] for more information.

==Further Information==
[http://www.openssh.org/ OpenSSH]

[http://www.openssh.com/windows.html Windows Clients]

R

2014-12-02T22:41:38Z

Claw:

R installation instructions for Windows

==Basic Installation==
#To retrieve the latest version of R from here: http://cran.r-project.org/
#Select "Download R for Windows" from the top of the screen
#Then click "Install R for the first time" on the first line
#This will take you to a download page, click "Download R<version number> for Windows" to begin the installation
#Navigate to the directory you downloaded the installer to.
#Run the .exe and step through the installer.
[[Image:R_Install_1.PNG]]

*Note: There will be a warning when you start the installer that says the full installation requires administrative privileges, disregard this message.
[[Image:R_Install_2.PNG]]

*Accept the License Agreement and continue.
[[Image:R_Install_3.PNG]]

*When prompted, choose an installation folder wherever you would like it within your home directory.
[[Image:R_Install_4.PNG]]

*Select the components that you wish to install, the defaults for this is fine.
[[Image:R_Install_5.PNG]]

*If you wish to customize the options for the startup environment then click Yes when prompted. If you are unsure what these are select "No", the defaults can be altered later.
[[Image:R_Install_6.PNG]]

For customized options see the section below

*Name the folder that will appear in the start menu, the default "R" is acceptable for this.
[[Image:R_Install_10.PNG]]

*Finalize your installation options and hit Next to begin the installation.
[[Image:R_Install_11.PNG]]

*After stepping through the dialog R will install itself to the folder you specified.

*Finish and close the setup. R is now installed locally on your account.
[[Image:R_Install_12.PNG]]

==Customized Startup Environment==
*From the customized startup environment options prompt, if you wish to go through the customized startup environment dialog select "Yes" here. Any of these options can be altered at a later time after installation if you decide you have a change in preference.
[[Image:R_Install_6.PNG]]

*The first prompt will determine which interface you wish to use. MDI (one main window for all R programs) or SDI (separate windows for each R program) If you have a preference, select which option you prefer.
[[Image:R_Install_7.PNG]]

*Next, determine how you wish the help format to be displayed. You can choose from either plain text format or HTML formatted.
[[Image:R_Install_8.PNG]]

*Finally, determine how you would like R to handle the proxy settings in Internet Explorer, whether you would like to use the standard settings or make use of internet2.dll.
[[Image:R_Install_9.PNG]]

*That concludes the startup environment customization options for R. The following steps are the same as the above.

==Opening R scripts with RScript==
Users can open a file with R to a command terminal window via RScript.
From within the \bin\x64 folder at the location that you installed R to you can run:
<pre>
RScript path\to\file\test.R
</pre>

Ubuntu/SoftwareCenter

2014-11-20T21:20:39Z

Claw:

The Ubuntu Software Center provides a mechanism to install many different applications and libraries to your Ubuntu desktop without requiring 'su' or 'sudo' (administrative) access. More information can be found at the features page [http://www.ubuntu.com/ubuntu/features/find-more-apps here]

===Permissions and Troubleshooting===
If your Ubuntu machine is UMIACS-supported and you are the primary user, access to the Software Center should have been granted to you at the time the machine was installed. If you find that you do not have adequate permissions to install software from this portal, please send mail to the [[HelpDesk|UMIACS Helpdesk]], [mailto:staff@umiacs.umd.edu staff@umiacs.umd.edu]. Please provide both your hostname and username.

===Launching Software Center in Ubuntu===
One way of launching the Ubuntu Software Center is by using the Dashboard. The dashboard can be opened by typing the meta key (commonly referred to as the Windows key). This will provide you with a search box. Type in "Software Center" and it should be within the first few results. You can alternatively launch it from the terminal by typing "software-center" (if it's not in your path, the location is /usr/bin/software-center)

===Known Issues===
Due to the limitations of X forwarding, the Ubuntu Software Center cannot be used via X11 Forwarding. Any updates using the Ubuntu Software Center will therefore have to be done using the method mentioned above on the physical machine.

BarracudaSpamFirewall/QuarantinePassthrough

2014-11-14T17:19:43Z

Claw:

===Quarantine Passthrough===
*If you wish to have the mail that would ordinarily be quarantined by Barracuda delivered to your mailbox instead you can configure this using the Barracuda web configuration.
*First log into any of the following Barracuda interfaces using your full UMIACS email and Unix password: [http://pompom.umiacs.umd.edu:8000/cgi-mod/index.cgi pompom], [https://homsar.umiacs.umd.edu/cgi-mod/index.cgi homsar], [https://bubs.umiacs.umd.edu/cgi-mod/index.cgi bubs]
[[image:BarracudaLogin.png]]

*Once you have successfully logged in, click the Preferences tab at the top of the screen. Then select Quarantine Settings.
[[Image:BarracudaPreferences.png]]

*On this screen there is a selection box for Quarantine Enable/Disable. By changing this option to "No" all mail that would be captured by the Barracuda quarantine filter will instead be delivered to your mailbox with the tag [QUAR] prepended to the subject line. Click Save Changes and you're done.
[[Image:BarracudaQuarantinePassthrough.png]]

===Filtering the Quarantined messages from your inbox===
*Since the quarantine filter will no longer catch mail that would have been previously removed from your inbox you may wish to set up a filter to redirect these messages to an appropriate folder.
*Filter setup instructions can be found at [[MailFiltering]].

BarracudaSpamFirewall/QuarantinePassthrough

2014-11-14T17:18:38Z

Claw: Created page with "===Quarantine Passthrough=== *If you wish to have the mail that would ordinarily be quarantined by Barracuda delivered to your mailbox instead you can configure this using the..."

===Quarantine Passthrough===
*If you wish to have the mail that would ordinarily be quarantined by Barracuda delivered to your mailbox instead you can configure this using the Barracuda web configuration.
*First log into any of the following Barracuda interfaces using your full UMIACS email and Unix password: [http://pompom.umiacs.umd.edu:8000/cgi-mod/index.cgi pompom], [https://homsar.umiacs.umd.edu/cgi-mod/index.cgi homsar], [https://bubs.umiacs.umd.edu/cgi-mod/index.cgi bubs]
[[image:BarracudaLogin.png]]

*Once you have successfully logged in, click the Preferences tab at the top of the screen. Then select Quarantine Settings.
[[Image:BarracudaPreferences.png]]

*On this screen there is a selection box for Quarantine Enable/Disable. By changing this option to "No" all mail that would be captured by the Barracuda quarantine filter will instead be delivered to your mailbox with the tag [QUARANTINE] prepended to the subject line. Click Save Changes and you're done.
[[Image:BarracudaQuarantinePassthrough.png]]

===Filtering the Quarantined messages from your inbox===
*Since the quarantine filter will no longer catch mail that would have been previously removed from your inbox you may wish to set up a filter to redirect these messages to an appropriate folder.
*Filter setup instructions can be found at [[MailFiltering]].

BarracudaSpamFirewall

2014-11-14T17:13:53Z

Claw:

===Introduction===

UMIACS has deployed a system with 3 Barracuda Networks spam firewalls. This allows for enterprise level Virus and Spam scoring and filtering for our email architecture.

===Mail Flow Through Barracudas===
*Currently users that receive mail at Exchange or our new IMAP service will be serviced by the Barracudas.

*The first time your mail flows through one of the Barracudas it will send you a mail with a new username and password. Subsequently you will receive every day (unless you configure otherwise) a mail at approx. 3:30 EST from the Barracuda with your quarantine summary.

===Quarantine===
*Mail that has been deemed as spam will be kept on the Barracudas in quarantine. It will not be delivered to your mailbox unless you configure the Barracudas to do so.
*Your quarantine will be preserved for '''21 days'''. If mail is held for longer, then it will be purged. At the bottom of your 3:30 quarantine mail you will see a link that will take you straight to your quarantine.
**If you receive a security warning in your browser after clicking this link, you may need to [[AddingUMIACSCertificateAuthority|add the UMIACS Certificate Authority]]
*You can search your spam quarantine with the following steps [[BarracudaSpamFirewall/SearchingQuarantine]]

===Quarantine Passthrough===
*If you wish to have the mail that would ordinarily be quarantined by Barracuda delivered to your mailbox instead you can configure this using the Barracuda web configuration.
*You can enable this functionality with the following guide [[BarracudaSpamFirewall/QuarantinePassthrough]]

===Whitelists, Blacklists & Bayesian Filtering===
*You may also setup whitelists, blacklists, and Bayesian filtering options through the Preferences tab at the top of the Barracuda web portal.

===More Information===
*For more information on how to use the Barracuda please download the user's guide:

https://wiki.umiacs.umd.edu/umiacs/images/5/5a/Barracuda_usersguide.pdf

R

2014-10-24T17:34:57Z

Claw:

R installation instructions for Windows

==Basic Installation==
#To retrieve the latest version of R from here: http://cran.r-project.org/
#Select "Download R for Windows" from the top of the screen
#Then click "Install R for the first time" on the first line
#This will take you to a download page, click "Download R<version number> for Windows" to begin the installation
#Navigate to the directory you downloaded the installer to.
#Run the .exe and step through the installer.
[[Image:R_Install_1.PNG]]

*Note: There will be a warning when you start the installer that says the full installation requires administrative privileges, disregard this message.
[[Image:R_Install_2.PNG]]

*Accept the License Agreement and continue.
[[Image:R_Install_3.PNG]]

*When prompted, choose an installation folder wherever you would like it within your home directory.
[[Image:R_Install_4.PNG]]

*Select the components that you wish to install, the defaults for this is fine.
[[Image:R_Install_5.PNG]]

*If you wish to customize the options for the startup environment then click Yes when prompted. If you are unsure what these are select "No", the defaults can be altered later.
[[Image:R_Install_6.PNG]]

For customized options see the section below

*Name the folder that will appear in the start menu, the default "R" is acceptable for this.
[[Image:R_Install_10.PNG]]

*Finalize your installation options and hit Next to begin the installation.
[[Image:R_Install_11.PNG]]

*After stepping through the dialog R will install itself to the folder you specified.

*Finish and close the setup. R is now installed locally on your account.
[[Image:R_Install_12.PNG]]

==Customized Startup Environment==
From the customized startup environment options prompt, if you wish to go through the customized startup environment dialog select "Yes" here. Any of these options can be altered at a later time after installation if you decide you have a change in preference.
[[Image:R_Install_6.PNG]]

*The first prompt will determine which interface you wish to use. MDI (one main window for all R programs) or SDI (separate windows for each R program) If you have a preference, select which option you prefer.
[[Image:R_Install_7.PNG]]

*Next, determine how you wish the help format to be displayed. You can choose from either plain text format or HTML formatted.
[[Image:R_Install_8.PNG]]

*Finally, determine how you would like R to handle the proxy settings in Internet Explorer, whether you would like to use the standard settings or make use of internet2.dll.
[[Image:R_Install_9.PNG]]

*That concludes the startup environment customization options for R. The following steps are the same as the above.

R

2014-10-24T17:05:57Z

Claw:

R installation instructions for Windows

==Basic Installation==
#To retrieve the latest version of R from here: http://cran.r-project.org/
#Select "Download R for Windows" from the top of the screen
#Then click "Install R for the first time" on the first line
#This will take you to a download page, click "Download R<version number> for Windows" to begin the installation
#Navigate to the directory you downloaded the installer to.
#Run the .exe and step through the installer.
[[Image:R_Install_1.PNG]]

*Note: There will be a warning when you start the installer that says the full installation requires administrative privileges, disregard this message.
[[Image:R_Install_2.PNG]]

*Accept the License Agreement and continue.
[[Image:R_Install_3.PNG]]

*When prompted, choose an installation folder wherever you would like it within your home directory.
[[Image:R_Install_4.PNG]]

*Select the components that you wish to install, the defaults for this is fine.
[[Image:R_Install_5.PNG]]

*If you wish to customize the options for the startup environment then click Yes when prompted. If you are unsure what these are select "No", the defaults can be altered later.
[[Image:R_Install_6.PNG]]

For customized options see the section below

*Name the folder that will appear in the start menu, the default "R" is acceptable for this.
[[Image:R_Install_10.PNG]]

*Finalize your installation options and hit Next to begin the installation.
[[Image:R_Install_11.PNG]]

*After stepping through the dialog R will install itself to the folder you specified.

*Finish and close the setup. R is now installed locally on your account.
[[Image:R_Install_12.PNG]]

==Customized Startup Environment==
From the customized startup environment options prompt, if you wish to go through the customized startup environment dialog select "Yes" here. Any of these options can be altered at a later time after installation if you decide you have a change in preference.
[[Image:R_Install_6.PNG]]

*The first prompt will determine which interface you wish to use. MDI (one main window for all R programs) or SDI (separate windows for each R program) If you have a preference, select which option you prefer.
[[Image:R_Install_7.PNG]]

*Next, determine how you wish the help format to be displayed. You can choose from either plain text format or HTML formatted.
[[Image:R_Install_8.PNG]]

*Finally, determine how you would like R to handle the proxy settings in Internet Explorer, whether you would like to use the standard settings or make use of internet2.dll.
[[Image:R_Install_9.PNG]]

*That concludes the startup environment customization options for R. The following steps are the same as the above.

File:R Install 12.PNG

2014-10-24T16:37:08Z

Claw: Claw moved page File:RInstall12.PNG to File:R Install 12.PNG without leaving a redirect

Ending prompt for R 3.1.1 Windows Installation

File:R Install 12.PNG

2014-10-24T16:33:11Z

Claw: Claw moved page File:R Install 12.PNG to File:RInstall12.PNG without leaving a redirect

Ending prompt for R 3.1.1 Windows Installation

File:R Install 12.PNG

2014-10-24T16:22:42Z

Claw: Ending prompt for R 3.1.1 Windows Installation

Ending prompt for R 3.1.1 Windows Installation

File:R Install 11.PNG

2014-10-24T16:20:30Z

Claw: Finalization prompt for R 3.1.1 Windows Installation

Finalization prompt for R 3.1.1 Windows Installation

File:R Install 10.PNG

2014-10-24T16:16:45Z

Claw: Start menu naming prompt for R 3.1.1 Windows Installation

Start menu naming prompt for R 3.1.1 Windows Installation

File:R Install 9.PNG

2014-10-24T16:16:06Z

Claw: Internet explorer proxy settings for R 3.1.1 Windows Install. Uses either internet2.dll or standard settings.

Internet explorer proxy settings for R 3.1.1 Windows Install. Uses either internet2.dll or standard settings.

File:R Install 8.PNG

2014-10-24T16:14:49Z

Claw: Help menu HTML or Plain Text environment variable prompt for R 3.1.1 Windows Install

Help menu HTML or Plain Text environment variable prompt for R 3.1.1 Windows Install

File:R Install 7.PNG

2014-10-24T16:13:56Z

Claw: MDI (one window) or SDI (separate windows) startup environment prompt for R 3.1.1 Windows Installation

MDI (one window) or SDI (separate windows) startup environment prompt for R 3.1.1 Windows Installation

File:R Install 6.PNG

2014-10-24T16:12:40Z

Claw: Startup customization prompt for R 3.1.1 Windows Installation

Startup customization prompt for R 3.1.1 Windows Installation

File:R Install 5.PNG

2014-10-24T16:12:00Z

Claw: Installation component prompt for R 3.1.1 Windows Installation

Installation component prompt for R 3.1.1 Windows Installation

File:R Install 4.PNG

2014-10-24T16:10:53Z

Claw: Location of installation prompt for R 3.1.1 Windows Installation

Location of installation prompt for R 3.1.1 Windows Installation

File:R Install 3.PNG

2014-10-24T16:10:15Z

Claw: License Agreement for R 3.1.1 Windows Install

License Agreement for R 3.1.1 Windows Install

File:R Install 2.PNG

2014-10-24T16:09:17Z

Claw: Administrator rights warning for R for Windows install.

Administrator rights warning for R for Windows install.

File:R Install 1.PNG

2014-10-24T15:57:42Z

Claw: Opening prompt for installing R 3.1.1 on Windows

Opening prompt for installing R 3.1.1 on Windows

CDebuggers

2014-10-21T21:57:19Z

Claw:

We currently have the following C/C++ debuggers on the following platforms:

===RHEL5===

* gdb 7.0.1-42.el5 - /usr/bin/gdb
* valgrind 3.5.0 - /usr/bin/valgrind

===RHEL6===

* gdb 7.2-50.el6 - /usr/bin/gdb
* valgrind 3.6.0 - /usr/bin/valgrind

===Ubuntu 12.04===

* gdb 7.4-2012.04 - /usr/bin/gdb
* valgrind (must be installed via [[Ubuntu/SoftwareCenter | the Ubuntu Software Center]])

Also see: [[CCompilers]]

CCompilers

2014-10-21T21:56:59Z

Claw:

We currently have the following C/C++ compilers on the following platforms:

===RHEL5===

* gcc 4.1.2 - /usr/bin/gcc
* gcc 3.4.6 - /usr/bin/gcc34
* gcc 3.3.6 - /usr/local/stow/gcc-3.3.6
* gcc 4.0.4 - /usr/local/stow/gcc-4.0.4
* gcc 4.2.4 - /usr/local/stow/gcc-4.2.4
* gcc 4.5.1 - /usr/local/stow/gcc-4.5.1
* [[IntelCompilers|Intel Compilers]]
* [[PGICompilers|Portland Group Compilers]]

===RHEL6===

* gcc 4.4.4 - /usr/bin/gcc
* [[IntelCompilers|Intel Compilers]]
* [[PGICompilers|Portland Group Compilers]]

===Ubuntu 12.04===
* gcc 4.6.3 - /usr/bin/gcc
* [[IntelCompilers|Intel Compilers]]
* [[PGICompilers|Portland Group Compilers]]

Also see: [[CDebuggers]]

LinuxFAQ

2014-10-21T21:26:41Z

Claw:

* How do I use [[umask]]s and [[SetGID]] bits for group control under UNIX?
* How do I add a path to my [[Shell]] in UNIX?
* Where do I find locally compiled software?
** [[RHEL6]] see [[OptLocal]]
** [[RHEL5]] see [[UsrLocal]]

R

2014-10-20T20:08:13Z

Claw: Created page with "R installation instructions for Windows Installation #Retrieve the latest version of R from here: http://cran.r-project.org/ #Navigate to the directory you downloaded the ins..."

R installation instructions for Windows

Installation
#Retrieve the latest version of R from here: http://cran.r-project.org/
#Navigate to the directory you downloaded the installer to.
#Run the .exe and step through the installer. (Note: There will be a warning when you start the installer that says the full installation requires administrative privileges, disregard this message)
#When prompted, choose an installation folder wherever you would like it within your home directory.
#The defaults for installation components are fine.
#After stepping through the dialog R will install itself to the folder you specified.
#Finish and close the setup. R is now installed locally on your account.

Programming

2014-10-20T19:43:31Z

Claw:

* C/C++
** [[CCompilers|C/C++ Compilers]]
** [[CDebuggers|C/C++ Debuggers]]
* Java
** [[JavaVersions|Java Versions]]
** [[JavaDevelEnvironment|Java Development Environment]]
* Perl
** [[PerlVersions|Perl 5 Versions]]
** [[PerlDevelEnvironment|Perl Development Environment]]
** [[PerlModules|Perl Missing Modules]]
* [[Python]]
** [[PythonVersions | Python Versions]]
** [[PythonModDev | Python Modules and Development Environment]]
** [[WindowsPython | Windows Python ]]
* OpenCV
** [[OpenCVVersions | OpenCV Versions]]
*CMake
** [[CMake]]
*R
** [[R | R for Windows]]

File:EvolutionAcctSummary.png

2014-10-02T21:33:46Z

Claw: Account summary screen of Evolution mail client at account creation.

Account summary screen of Evolution mail client at account creation.

File:EvolutionDone.png

2014-10-02T21:33:21Z

Claw: Done screen of Evolution mail client at account creation.

Done screen of Evolution mail client at account creation.

File:EvolutionIdentity.png

2014-10-02T21:32:50Z

Claw: Identity prompt of Evolution mail client at account creation.

Identity prompt of Evolution mail client at account creation.

File:EvolutionIncoming.png

2014-10-02T21:32:22Z

Claw: Incoming server settings of Evolution mail client at account creation.

Incoming server settings of Evolution mail client at account creation.

File:EvolutionOutgoing.png

2014-10-02T21:31:46Z

Claw: Outgoing server settings of Evolution mail client at account creation.

Outgoing server settings of Evolution mail client at account creation.

File:EvolutionReceivingOptions.png

2014-10-02T21:31:23Z

Claw: Receiving options prompt of Evolution mail client at account creation.

Receiving options prompt of Evolution mail client at account creation.

File:EvolutionRestoreBackup.png

2014-10-02T21:30:48Z

Claw: Restore backup prompt of the evolution mail client at account creation.

Restore backup prompt of the evolution mail client at account creation.

File:EvolutionWelcome.png

2014-10-02T21:30:14Z

Claw: Welcome screen of the Evolution mail client on account creation.

Welcome screen of the Evolution mail client on account creation.

Email

2014-10-02T21:22:33Z

Claw:

__NOTOC__
===Introduction===

Depending on the environment you'll be working in, you have two primary choices for mail. You can decide on our PC based solution Microsoft Exchange or a [[UNIXEmail|IMAP Email]] solution. Both provide scanning for Virus and Spam through our [[BarracudaSpamFirewall|Barracuda Spam Firewall]]

Alternatively if you already have a Email provider you like we offer the ability to forward your Email.

You can update your Email preference through our [https://intranet.umiacs.umd.edu/chinfo Directory Profile] Tool.

===Microsoft Exchange Email===
If you are accustomed with Microsoft Outlook and/or need a shared calendar then we offer the UMIACS Exchange service. If you work primarily on a PC, collaborate with primarily PC-based users, expect to email MIME attachments or just feel most comfortable with a PC based mail solution, the exchange mailserver is likely the best solution for you. Among other things, it also supports IMAP, vacation (auto-response) and virus filtering capabilities.

[[SettingUpOutlook2007/2010withExchange|Setting Up Outlook 2007/2010 with Exchange]]

[[SettingUpOutlook2003withExchange|Setting Up Outlook 2003 with Exchange]]

[[SettingupiPhoneAccesstoExchange|Setting Up iPhone Access with Exchange]]

[[AccessingExchangeviaThunderbird|Setting Up Thunderbird with Exchange]]

[[WorkingWithEvolution|Setting Up Evolution]]

[[WorkingWithOutlook|Working with Outlook]]

The link for the Exchange web interface is https://exchange.umiacs.umd.edu/owa. It is also on the front page of our intranet site (https://intranet.umiacs.umd.edu). Please note that the web interface works best in IE.

===[[IMAPEmail|IMAP Email]]===
Our IMAP service is available as a simple multi-platform way of reading your mail. It provides powerful server-side mail filtering and vacation support. You can configure you own IMAP client (see below for a list of supported clients) or use our [[Webmail]] server to read your email.

===Support Matrix===

{|style="color:green;background-color:#ffffcc;" cellpadding="10" cellspacing="0" border="1"
|-style="color:black;"
|
|Pine
|Mutt
|Thunderbird
|Evolution
|Mail.app
|Outlook/Exchange
|-
|Windows 7
|Yes(1)
|
|Yes
|
|
|Yes
|-
|RHEL 5
|Yes
|Yes
|Yes
|
|
|Yes(2)
|-
|RHEL 6
|Yes (4)
|Yes (5)
|Yes
|
|
|Yes(2)
|-
|RHEL 7
|Yes
|Yes
|
|Yes(6)
|
|Yes(2)
|-
|Ubuntu 12.04
|Yes (4)
|Yes
|Yes
|
|
|Yes(2)
|-
|Ubuntu 14.04
|Yes (4)
|Yes
|Yes
|
|
|Yes(2)
|-
|Mac OS X
|Yes
|Yes
|Yes
|
|Yes
|Yes(3)
|}

# - We support pine on Windows through [http://www.washington.edu/pine/getpine/pcpine.html PC Pine]
# - Microsoft Exchange support is only available through the Outlook Web Access which is severely limited on non-IE browsers.
# - Microsoft Exchange support for Mail/Contacts/Calendar requirers Mac OS X 10.6 or later.
# - On later RHEL or Ubuntu hosts, pine is no longer supported, and has been replaced by alpine
# - On RHEL 6 hosts, Mutt is no longer installed by default. Please contact staff for install if need on host
# - On RHEL 7 hosts, Thunderbird is no longer supported and has been replaced by Evolution

Email

2014-10-02T21:10:59Z

Claw:

__NOTOC__
===Introduction===

Depending on the environment you'll be working in, you have two primary choices for mail. You can decide on our PC based solution Microsoft Exchange or a [[UNIXEmail|IMAP Email]] solution. Both provide scanning for Virus and Spam through our [[BarracudaSpamFirewall|Barracuda Spam Firewall]]

Alternatively if you already have a Email provider you like we offer the ability to forward your Email.

You can update your Email preference through our [https://intranet.umiacs.umd.edu/chinfo Directory Profile] Tool.

===Microsoft Exchange Email===
If you are accustomed with Microsoft Outlook and/or need a shared calendar then we offer the UMIACS Exchange service. If you work primarily on a PC, collaborate with primarily PC-based users, expect to email MIME attachments or just feel most comfortable with a PC based mail solution, the exchange mailserver is likely the best solution for you. Among other things, it also supports IMAP, vacation (auto-response) and virus filtering capabilities.

[[SettingUpOutlook2007/2010withExchange|Setting Up Outlook 2007/2010 with Exchange]]

[[SettingUpOutlook2003withExchange|Setting Up Outlook 2003 with Exchange]]

[[SettingupiPhoneAccesstoExchange|Setting Up iPhone Access with Exchange]]

[[AccessingExchangeviaThunderbird|Setting Up Thunderbird with Exchange]]

[[AccessingExchangeviaEvolution|Setting Up Evolution with Exchange]]

[[WorkingWithOutlook|Working with Outlook]]

The link for the Exchange web interface is https://exchange.umiacs.umd.edu/owa. It is also on the front page of our intranet site (https://intranet.umiacs.umd.edu). Please note that the web interface works best in IE.

===[[IMAPEmail|IMAP Email]]===
Our IMAP service is available as a simple multi-platform way of reading your mail. It provides powerful server-side mail filtering and vacation support. You can configure you own IMAP client (see below for a list of supported clients) or use our [[Webmail]] server to read your email.

===Support Matrix===

{|style="color:green;background-color:#ffffcc;" cellpadding="10" cellspacing="0" border="1"
|-style="color:black;"
|
|Pine
|Mutt
|Thunderbird
|Evolution
|Mail.app
|Outlook/Exchange
|-
|Windows 7
|Yes(1)
|
|Yes
|
|
|Yes
|-
|RHEL 5
|Yes
|Yes
|Yes
|
|
|Yes(2)
|-
|RHEL 6
|Yes (4)
|Yes (5)
|Yes
|
|
|Yes(2)
|-
|RHEL 7
|Yes
|Yes
|
|Yes(6)
|
|Yes(2)
|-
|Ubuntu 12.04
|Yes (4)
|Yes
|Yes
|
|
|Yes(2)
|-
|Ubuntu 14.04
|Yes (4)
|Yes
|Yes
|
|
|Yes(2)
|-
|Mac OS X
|Yes
|Yes
|Yes
|
|Yes
|Yes(3)
|}

# - We support pine on Windows through [http://www.washington.edu/pine/getpine/pcpine.html PC Pine]
# - Microsoft Exchange support is only available through the Outlook Web Access which is severely limited on non-IE browsers.
# - Microsoft Exchange support for Mail/Contacts/Calendar requirers Mac OS X 10.6 or later.
# - On later RHEL or Ubuntu hosts, pine is no longer supported, and has been replaced by alpine
# - On RHEL 6 hosts, Mutt is no longer installed by default. Please contact staff for install if need on host
# - On RHEL 7 hosts, Thunderbird is no longer supported and has been replaced by Evolution