The Stevens Linux Lab is a set of virtual machines (VMs), running on Computer Science (CS) Educational server, which is located in our data center on lower level of Library. The Linux Lab servers are available for both faculty and students. All Linux Lab VMs have a similar configuration:
OS: Ubuntu Server 16.04 LTS Number of virtual CPUs: 2 Memory: 2048 MB or 4096 MB Disk space: 20.00 GB
The Linux lab consists of these 9 virtual machines:
9 Ubuntu Server 16.04 Linux virtual machines Authentication: LDAP/Kerberos Installed extra software: # Oracle JDK 8 # GNU C++ compiler g++-5 # GNU C compiler gcc-5 # Build tools, like configure and make # Python python2.7 and python3.5 # python-pip - alternative Python package installer # bc - An arbitrary precision calculator language # expect - programmed dialogue with interactive programs, Version 5 # alpine - Text-based email client # sendmail - powerful, efficient, and scalable Mail Transport Agent # clang - C, C++ and Objective-C compiler (LLVM based) # emacs - GNU Emacs editor # git - fast, scalable, distributed revision control system # pwgen - Automatic Password generation # tmux - terminal multiplexer # valgrind - instrumentation framework for building dynamic analysis tools # wget - retrieves files from the web # curl - command line tool for transferring data with URL syntax # apache2-utils - Apache HTTP Server (utility programs for web servers) # subversion - Advanced version control system # mutt - text-based mailreader supporting MI # libssh2-1-dev - SSH2 client-side library (development headers) # libssl-dev - Secure Sockets Layer toolkit - development files # aws - The AWS Command Line Interface is a unified tool to manage your AWS services. # ec2-api-tools - Amazon EC2 API tools # libpcap-dev - development library for libpcap (transitional package) # tcpdump - command-line network traffic analyzer
The Linux Lab is open to all users who have accounts on the Stevens Research Computing Information Technology (SRCIT) LDAP/Kerberos system during Stevens operational hours.
Please contact US for further information and request an SRCIT (Linux Lab) account.
Linux Lab Detailed Information
Your username is typically the same as your pipeline username. However, once it is a completely independent account, the username may be different. SRCIT (Linux lab) username is NOT a Stevens account username.
- Password Requirements
SRCIT requires that all account passwords be at least twelve (12) characters in length and contain at least three password character classes for password strength
You may generate your password from the command line by using the following command:
pwgen -s 12
which will generate a password such as: p7FBWvNikEWP
or, if you wish to be a little more adventurous with your password, try:
pwgen -syC 12
which will generate something like this: u=U~;*1?.f86
- If you would like to generate a still more complex password, please read the man page for pwgen
- Human generated random passwords are not advisable, as they tend not to be particularly random
- Information on changing your password may be found by visiting the SRCIT wiki on changing your password
- More detailed information of Kerberos functionality regarding passwords may be found here
If you have a problem or request concerning the Linux Lab systems, please visit the Stevens Helpdesk website and file a ticket.
Primary access to the SRCIT Linux Lab network round robin system is through remote access. As such, the following are detailed instructions on various means of remote access.
Note: For those requiring physical access, the lab is located in data center on library's lower level.
Connecting to your account by console
Using an SSH client, (or SCP client for file transfer access ONLY), you can log into your account from home or from other remote locations.
For Windows system, the generally preferred SSH client is putty. Download this ssh client and follow the instructions below.
For Mac and Linux systems, you simply need to open a Terminal and follow the instructions below.
Once you have completed one of the above options, you may access Linux Lab in the following manner:
Login to any of 9 Linux Lab servers, using the following command (from the command line):
If, for some reason, you can not connect to nemo.srcit.stevens-tech.edu, try connecting to the other client that makes up Linux lab. For example,
Running ssh in verbose mode '-vv' may help in troubleshooting, in case you get a connection problem.
Connecting to your account via GUI
There are two methods for connecting to the SRCIT Linux Lab via Graphical User Interface (GUI)
nx client (recommend)
- downloaded nx client from nomachine (supported platform: Windows, Linux, Mac OS, Solaris)
- launch 'NX Client'
- input the value for following parameters:
Host: rainman.srcit.stevens-tech.edu Desktop: Unix Gnome or KDE Display: Available Area Login: your srcit username Password: your srcit password
- Recommended software: putty + Xming
- Launch Xming on windows
- Config putty to enable X11 forward. Launch putty
Navigate to Connection => SSH => X11
select Enable X11 forwarding X display location: localhost:0
or run command
putty -X firstname.lastname@example.org
- Recommended software: putty + Free Edition vncviewer
- Setup vncserver for the first time run(If you did this before, please ignore this step and go to Step 3 X11 forward)
Step 1: Logon shell.srcit.stevens-tech.edu from your Windows station (assume putty.exe is saved on c:\, use command 'cd' to change directory if this is not the case)
c:\> putty email@example.com
Step 2: Set password for vnc session
Step 3: create vnc startup script ~/.vnc/xstartup like below
for gnome desktop $ vi ~/.vnc/xstartup #!/bin/sh [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources gnome-session &
for kde desktop $ vi ~/.vnc/xstartup #!/bin/sh [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources startkde &
Step 4: set above script file executable
$ chmod u+x ~/.vnc/xstartup
3. Setup ssh-tunnel to connect to remote vnc server
Step 1: On your windows station, ssh to shell.srcit.stevens-tech.edu and start vncserver(assume putty.exe is saved on c:\, use command 'cd' to change directory if this is not the case)
c:\> putty firstname.lastname@example.org [ash:~]$ vncserver If the application runs successfully, the following message is expected. New 'hostname:session_num (username)' desktop is hostname:session_num.
Note: The hostname and session_num are important and will be used later
New 'ash:1(username)' desktop is ash:1
(Optional) you can close the window now by running exit [ash:~]$ exit
Step 2: set ssh-tunnel, launch putty
Host Name: the same hostname in Step 1, like ash.cs.stevens.edu Navigate to Connection => SSH => Tunnels Source Port: 5900 + session_num (for example: 5901) Destination: localhost:5900+session_num (for example: localhost:5901) click button 'Add'
or run command
c:\> putty -L Source_Port:localhost:Destination_Port email@example.com
where Source_Port: 5900+session_num; Destination_Port: 5900+session_num
for example: c:\> putty -L 5901:localhost:5901 firstname.lastname@example.org
4. Launch vncviewer on windows
Server: localhost:session_num (for example: localhost:1)
or run command
c:\> vncviewer localhost:session_num (for example: c:\> vncviewer localhost:1)
5. (IMPORTANT) When finished, please remember to kill vncserver
$ vncserver -kill :session_num
TERMS OF SERVICE
- I understand that Stevens Research Computing Information Technology grants computer accounts for the exclusive use of the recipient. I will not authorize or facilitate the use of my account or files by any other person, nor will I divulge my password to any other person under any circumstances. This includes fellow students, colleagues, TAs, significant others, spouses or others.
- I will not access, or attempt to gain access to any computer, computer account, network or files without proper and explicit authorization.
- I understand that some of the software and data that resides on file systems that I may access are protected by copyright and other laws, licenses or other contractual agreements; I will use the software according to these laws and licenses and will not breach or attempt to circumvent these regulations.
- I will not use Stevens Research Computing Information Technology resources for obtaining, making, running or distributing unauthorized copies of any data.
- I undertake to maintain the highest standard of honesty and personal integrity in relation to my usage of computing and network facilities. I further warrant that I will avoid any actions in relation to my usage of the Department's computing or network facilities that may bring any disrepute upon the Department or the University.
- I understand that any processes I have running on any Stevens Research Computing Information Technology supported may be interrupted at any time if said process affects the work of others in any way.
- I understand that my keyboard input may be monitored in the event of a real or perceived security incident.
- I understand that acting in breach of any of the principles set out above will incur severe penalties including, but not limited to the suspension or termination of access to the computing facilities, suspension or exclusion from the University, imposition of fines and/or legal actions taken.
Why does my password have to be so long and hard to remember?
SRCIT requires a certain level of password strength for user passwords in order to make the system more secure. Of course, passwords are only as strong as the method by which users remember them. For that reason SRCIT suggests that you review memory techniques for remembering your password.
Why don't my pipeline credentials work on the SRCIT system?
Campus pipeline uses a separate authentication system.
My colleague/friend/roommate gave me her account credentials, but I am having trouble logging in. What should I do?
First of all, tell your colleague/friend/roommate that it is bad practice to share account credentials and a violation of most every account Terms of Service, including ours. Then, you should visit the Helpdesk ticketing system and request an account.
Why shouldn't I share my account credentials? I am working on a collaborative project.
There are simply better ways to work on collaborative projects than sharing account credentials. For example, collaboration is easy if you and your colleagues request a Subversion or Git repository.
OK, I requested an account, but I have not received my credentials. Are you going to create an account for me already?
Please login to the Helpdesk ticketing system and check the status of your account request. We change the status of the account request to private so that your unique password string is not communicated through email.
I have heard that I can login to the linux lab using ssh keys. How do I do that?
You can take a look at the manual page for ssh-keygen if you are on a Linux or Mac system, or for Windows download PuttyGen. Instructions for generating your ssh keys may be found here.
Once you key has been generated, file a Helpdesk ticket. Attach your _public_ key to the ticket. Please remember to save the private key -- you will need it to authenticate and log in later.
How do I change my shell?
You can change your shell by following these instructions.
How do I change my locale?
Please review these instructions on changing your locale.
What are the SSH Fingerprints for the Linux Lab systems?
The ssh fingerprints for the the Linux Lab systems are available here.
Is there a 'known hosts' file that I can append to my ~/.ssh/known_hosts?
Yes. It is located here.
I am trying to log in to linux lab and my connection is timing out. What is going on?
Linux Lab is a collection of a number of host systems housed in a public computer lab. From time to time, a system will hang or not behave normally due to (but not limited to) the following reasons:
- System Crash
- Load spike
- Shutdown/Reboot by end user
If you have a problem where your system is failing to connect to linux lab, it is advisable to try and flush your DNS cache if you are using a Windows or Mac system, as these systems will attempt to connect to the same host repeatedly in a DNS round robin. This is not necessary if you are logging in from a Linux system.
If you are logging in from a Linux system, please try to make a connection again.
I am having a problem running firefox. When I try to open it, I receive the following error message: "Firefox is already running, but is not responding." What should I do?
This is well known issue with firefox that can be dealt with by the following procedure:
-cd into .mozilla/firefox/*.default in your home directory (where the name *.default is a random string created by firefox)
-Copy the file 'places.sqlite' from your .mozilla/firefox/*.default to elsewhere in your home directory
-rm -rf *.default
Note: If you are specifically saving any profile data here, you should make a backup of the file first, then remove the old file. Alternatively, you can edit the profiles.ini file to remove references to the previously deleted *.default directory in your .mozilla/firefox/
-copy 'places.sqlite' previously saved to your new .mozilla/firefox/*.default, which will preserve your previously saved bookmarks.