Welcome to iLab!

This web page will help you in quickly getting setup and acquainted with our work environment.

Administrativia

When starting, please make sure that you check with Laurent that the following administrative matters have been taken care of:

• Building access: Please meet with our administrative assistant Laura Lopez in room HNB-05 of the Hedco Neuroscience Building, and let her know that you will be working with us, and that you would need a room key (Laurent will tell you which room) and building access code. She will give you a form that you can partially fill and should then give to Laurent for signature, and when you bring the form back you will be asked for a $10 key deposit (it will be refunded when you return your key).
• Contact information: Please send an email to Laurent (itti@usc.edu) with your full contact information.
• Lab mailing lists: We are hosting a number of mailing lists so that we can easily broadcast announcements to the various list members. When you send a message to a list, it will be forwarded to all current list members. Please no spam, no personal messages, avoid forwarding jokes, etc. these lists are strictly work and lab-related! Most attachments will be deleted. When you reply, make sure you are replying to the author and not to the whole list, unless you truly intend to reply to the whole list.

  Use the following to access a list named LIST (see below for the available lists which you can use instead of LIST):

  • Subscribe to the list: Send an email to "LIST-request@iLab.usc.edu" with "subscribe" as subject line and an empty body.
  • Un-subscribe from the list: Send an email to "LIST-request@iLab.usc.edu" with "unsubscribe" as subject line and an empty body.
  • Send an email to the members of the list: Send your email to "LIST@iLab.usc.edu". Remember, most attachments will be stripped off. So do not try to send any attachment.

  Available lists include (use these names in the commands above instead of LIST):

  • ilab -- the general list of all iLab members. For general announcements such as lab-lunch scheduling, conference submission deadlines, general suggestions for lab organization, etc.
  • beobots -- the list of all Beobot team members.
  • forum -- this is mostly a receive-only list to which a message will be sent each time a new message is posted on the iLab forum.
  • cvslog -- this is mostly a receive-only list to which a message will be sent each time a new SVN/CVS commit is posted to the iLab source code repository.

Lab lunch

We hold lab meetings at noon sharp every friday, unless otherwise announced on the iLab mailing list. Every week, one student informally presents to the group the current state of his/her research, typically explaining to the other lab members what this research is about, what the state of the art in the field is, what has been done so far by the student, what works, what needs more work, and what future plans are.

Lunch is served at lab meetings! If you exceptionally cannot attend the meeting, please let us know at least a couple of days in advance so that we plan the amount of food accordingly. You will be asked once in a while to buy lunch for the lab meeting. Please plan for $10 per person, including main course (and possibly apetizers), drinks and deserts. Please try to avoid fast food, and to avoid food that is so exotic that some lab members won't be able to eat it (e.g., extra-spicy), but we do like variety and interesting new cullinary discoveries! If you are not sure about what to buy or in what quantity, just consult with a more experienced lab member. When it is your turn to bring lunch, please make sure that the necessary utensils also are available in the small cabinet of Room HNB-30 (conference room), otherwise, buy plastic cups, knives, forks, spoons, plates, and paper napkins as needed (for your turn and a few others). Please conserve your original receipts and give them to Laura Lopez (Room HNB-05), who will process it for reimbursement. You should receive a check within approximately two weeks. If you cannot advance the amount required to purchase lunch, please consult with Laurent. Finally, when you bring food, you are also responsible for making sure that the conference room will be perfectly clean once we are done (but of course you can recruit everybody to help you clean up).

Computer setup

General organization

Below is a current map of the various machines in the lab. Click on it for a larger and more readable image.

Operation

All machines run Mandrake Linux.

Please ask Laurent assign a machine and desk to you, and to create a computer account for you.

• Network Information System: We use the Network Information System (NIS) to centralize all configuration information for the various machines in the lab. This is not important to know for routine use, except if you are looking for system configuration information in your local /etc directory. Rather, you should use the command ``ypcat''; for example, to list all the registered network services, use:

  ypcat -k services

  rather than using:

  cat /etc/services

  If you did not understand any of this, just don't worry about it! For more information, try ``man ypcat''.
  Do not create user accounts yourself! Because we use NIS, creating an account on your local machine will yield an account that can only be used on that machine, but that will not work on other machines. So, always ask Laurent to create new user accounts.
• Passwords: In order to change your password and have the changes reflected lab-wide, you need to communicate this change to our master NIS server. For that, use the command:

  yppasswd

  rather than ``passwd.''
• Automounter: All directories that are shared over the network (including your home directory) are accessed using the Linux automounter, autofs. This means that a shared directory will not be mounted on your machine unless you request it, and if you do not access it for a few minutes, it will automatically be un-mounted. To access a shared directory, simply issue a command that will use it, for example a ``cd'' or a ``ls'' on it. The base directory for all automounted directories is ``/lab''. The following automounted directories are useful:
  • /lab/memberloginname/ is the home directory of a lab member whose login name is ``memberloginname''. This is the way you should call your home directory (even if it also appears as /home/yourloginname on your local machine) when you write scripts or config files, if you want them to transparently work on any machine in the lab, and not only the machine on which your home directory physically resides (typically, your desktop).
  • /lab/local/ contains various software packages that are not part of the standard Linux Mandrake distributions. It is a good idea to put /lab/local/bin/ in your path so that you can easily access these packages. These include Matlab, some Beowulf tools, StarOffice, some bibliography search tools, etc.
  • /lab/packages/ contains the RPMs for all the additional packages which we typically install on our machines in addition to the standard Linux Mandrake distributions.
  • /lab/images/ contains a large collection of images for use, e.g., to train or test visual models.
  • /lab/linux/ contains various Linux distributions being used in the lab.
  • /lab/httpd/ is our iLab.usc.edu web site, seen from the inside.
  • /lab/sdoc/ is our iLab.usc.edu/sdoc/html/ web site (documentation of the neuromorphic vision toolkit), seen from the inside.
  • /lab/tmp/ is a directory for temporary files, and resides on a 233 GB RAID-5 partition (RAID-5 is redundant RAID, in which data is split onto three disks, two for actual data and the third for parity. This makes the system robust to the failure of any one disk), so that there should always be plenty of space available. It is not backed-up. It contains four subdirectories into which you can write temporary files:
    • 1/ for files that will be automatically deleted after they have become more than 1-day old at the time the cleanup script runs (4:00am). Be careful, this is not a joke! Even if you try to protect your files, they will be deleted by a script running as root when they are more than one day old. This is really for temporary files (e.g., transfers from one machine to another, results from uncompressing a large movie into individual frames that you want to immediately burn on CD, etc.) Please avoid creating subdirectories in here, or delete them manually once you are done.
    • 7/ for files that will be automatically deleted after 7 days.
    • 30/ for files that will be automatically deleted after 30 days.
    • u/ for files that will never be automatically deleted, but do not need to be backed-up (typically, lots of images automatically generated by some program, that you could easily re-generate if the disk crashes). Please try to use this rather than your home for any large dataset that would be easy to re-create or re-download in case of disk crash, so that you do not saturate the backup disk (see below for more on backups). In this one, please create a subdirectory to keep your stuff separate from other people's stuff.

  • /lab/tmp01/ through /lab/tmp16/ function in the same manner as /lab/tmp but are local to the corresponding Beowulf node (n01.beo.usc.edu through n16.beo.usc.edu).
  • /lab/tmpi[X]/ where X is a number function in the same manner as /lab/tmp/ but reside on the disks of machine iLab[X].usc.edu.
  • /lab/cdwriter/ is Laurent's cd-recorder (if mounted).
  • There are a few more that you will deal with if you have to.

• High-speed network: Most machines are equipped with a local triple 100 Mbps network that is configured in such a way that it appears as a single 300 Mbps network. See the Beowulf page for more information. By default, the high-speed network is used for all communication between the lab's machines. For communication to the outside, a fourth ethernet board is used, that is connected to the Internet. Having multiple ethernet boards in your machine means that you have multiple IP addresses: one is in the 128.125.X.X range, and is the one that corresponds to your machine as seen from outside. One is in the 192.168.0.X range and is your address on the local network.
• Backups: We do not have a formal backup procedure yet, so you are responsible for backing-up your data. The machine iLab6 is equipped with a CD burner and Laurent can give you blank disks. See below for how to use the CD burner. We have an unofficial backup scheme that consists of the following: every weeknight a level-1 dump will backup all files that changed since the previous sunday night, onto the disk of one of the Beowulf nodes (which disk exactly is computed by a black-magic formula), and it will stay there for 30 days. The backup will thus be in /lab/tmpXX/30 where XX is between 01 and 16. Every sunday at 4:00am a full level-0 dump (all files) is made and similarly saved on a Beowulf disk for 30 days. These disks are about 25 GB in size each. Thus, it is critical that you keep disk usage to a minimum, otherwise you will break everybody's backups by saturating the Beowulf disks. Please record all files which you are not using on a regular basis onto CDs.
• CD recording: To record a CD, place all your files in a folder, then use ``du -ks myfolder '' to make sure that it will fit on a CD, then type the following while logged on iLab4 and with a blank CD in the drive:

  mkisofs -rJ myfolder | cdrecord -v dev=0,0,0 -

  If the drive is not found, try a:

  cdrecord -scanbus

  and note the 3 SCSI device numbers; use these with the "dev=x,x,x" argument to cdrecord. When you try this for the first time, it's better to try it on a CD-RW; then you will probably need to lower the recording speed (default is 10x) according to what is specified on your CD-RW). Add a ``speed=4'' argument to cdrecord to record at 4x. To blank a CD-RW, use:

  cdrecord blank=fast

  For more information, try ``man mkisofs'' and ``man cdrecord'' while logged on iLab6.
• Email: Configure your email client such that:
  • user-domain = iLab.usc.edu
  • smtp-server = iLab.usc.edu
  • inbox-path = /lab/mail/yourlogin
  and you should be set. Your email address is yourlogin@iLab.usc.edu
• Personal Web Page: Create a directory named public_html in your home directory and do a "chmod 755 public_html" so that the web server program can access it (make sure that you also have made a chmod 755 on your home directory and on any subdirectory in your public_html). Then place your html files in there. Please only professional-looking, decent material! The address for your home page is http://iLab.usc.edu/~yourlogin/
• Remote login and FTP: Telnet and FTP are insecure protocols that send your password in clear over the network, so they are disabled on all machines (as servers; clients still work, so you can telnet and ftp from your machine to anywhere, but cannot from anywhere to your machine). Instead, we use ssh (secure shell), which works just like telnet and allows you to securely transfer files too. To remote login onto an iLab machine, use:

  ssh machine.usc.edu

  if you are currently logged under the same login name as your iLab account, or

  ssh machine.usc.edu -l your_iLab_login_name

  if you are currently logged with a different login name. Free ssh client software for windoze is available, for example from www.ssh.com.
• Anonymous FTP: It is often useful to have some temporary public ftp space to transfer files between various machines in an asynchronous manner. Machine iLab.usc.edu runs an anonymous ftp server, so ftp iLab.usc.edu will work (login as user ``ftp'' and provideyour email address as password). To avoid that various hackers dump mp3 and other files onto our site, you will not be able to browse the top directory. There is a hidden directory, z/1/ in which you can put/retrieve files. Files written to there will be automatically deleted after 24 hours.
• Remote display: if you are logged on a remote machine and want to run X-based programs, make sure that: First, your local machine will accept remote windows by typing ``xhost +'' (or ``xhost +remote_machine''), second that in the shell on your remote machine you have the environment variable DISPLAY set to the name of your local machine followed by a `` :0 ''. To do that, if you use bash as shell:

  export DISPLAY=machine.usc.edu:0

  or if you use csh/tcsh:

  setenv DISPLAY machine.usc.edu:0

  Here is a script that will automatically do that for you (for csh/tcsh; place in your .cshrc):

  setenv REMOTEHOST `who -lm | awk '{ print $6 }' | tr -d '()'`
  setenv DISPLAY ${REMOTEHOST}:0.0

  you can easily translate it to bash syntax if you use bash (see above).
• Running Eagle schematics/printed-circuit-board (PCB) software: Use the command "/lab/local/bin/eagle". If you want to play with the examples, first copy them to your local project directory, as follows: "cp -r /lab/eagle/projects/examples ~/eagle/". For documentation, please check www.cadsoft.de, in the download section. All user-contributed files are already installed, under a contrib category for UPLs, projects, and libraries.
• Running Matlab: try /lab/local/bin/matlab to start it. If the program seems to not respond to your keystrokes, try turning your NumLock off on your keyboard. This is a known bug in Matlab.
• Running VNC: VNC stands for Virtual Network Computing. It is a remote display system that allows you to interact with a computing 'desktop' environment not only on the machine where it is running, but from anywhere on the Internet and from a wide variety of machine architectures. Excellent documentation that will get you started on using VNC in a jiffy is available at: http://www.uk.research.att.com/archive/vnc/start.html.

  It is strongly recommended that you tunnel your VNC session(s) thru SSH, especially when connected remotely, because the VNC protocol by itself is not very secure. Concise and straight-forward instructions on how to set up SSH tunneling for VNC connections are available at: http://www.uk.research.att.com/archive/vnc/sshvnc.html.

  If you intend to run a vncserver on a shared machine (such as ilab6), you should first ask Laurent to assign dedicated ports to you (usually, one port per machine you want to access would be all you need). This step would insure that when you run a vncserver, you don't accidentally grab a port that was previously assigned to someone else, and would also protect you from such grabs by other users. There is no automatic mechanism in place that prevents users from taking ports that were not assigned to them, so the responsibility for respecting the port assignments falls on each and every user.