This document was updated to reflect the system during Winter 2009.

Recent System Changes

There may still be bugs in the system.

We need you, the users, to report to us, the system administrators, any bugs you find with any lab image. If you don't report a bug, it won't get fixed. Simply drop by 1140 of the Talmage building or email us at system@cs.byu.edu with a description of the problem, and we'll do whatever we can to fix it. Please provide instructions to reproduce the problem. We want all of our machines to work, and work well, so please help us so we can get any bugs fixed in the system.

Accounts Page

The accounts page has had a long needed rewrite. The new accounts page is accessible at http://labs.cs.byu.edu/.

We are constantly making changes to it as bug reports come in, and we are still adding features to make it easier for you to manage your account.

Windows labs

Historically, the cs100 lab was available for only cs100 students. Now anyone with an active CS account can use the cs100 lab. The cs100 lab image is identical to the image used in other computer labs, with the addition of some software used by the cs100 class. There are fewer open labs available due to construction, and EcEn124 shifted from a Linux-oriented model to a more windows-oriented model. The demand for more windows lab machines was met by making this change to the cs100 lab.

Linux Labs

The Linux labs are still running the Fedora 9 image left over from Fall semester.

Known Issues

  • X Server failed to start

    Some lab machines are displaying an error about how gdm can't start because X can't start. This is because of a kernel/nvidia driver mismatch. The problem is triggered when a machine who has received the kernel update is rebooted. Normally machines aren't rebooted, but when they are, they may exhibit this problem. The easiest fix is to give the machine a clean install via our regular net install method.

    We've re-imaged almost every machine in the department since this happened. We've found that the installer will install a sane kernel and nvidia driver combination. Hopefully the problem won't re-manifest itself before the end of the semester.

NFS Issues:

  • NFS File locks / SVN fails to commit.

    This is caused by a problem with an individual lab machine or machines. Sometimes the NFS lock service stops working. Other NFS operations continue to work, but if an exclusive file lock is requested, it fails. The error message looks something like this when committing to an SVN repository:

    svn: Commit failed (details follow):
svn: Can't get exclusive lock on file
'/users/groups/groupname/reponame/db/transactions/32-1.txn/rev-lock': No locks available

    If this is happening, please let us know exactly what machine is affected. If you are connecting by lab name, please let us know which machine you are getting dropped on. If your are connecting to 'schizo.cs.byu.edu', please let us know. It is more difficult to tell which machine is affected, as schizo is a round robin DNS alias. If it only breaks some of the time, but not all the time, that is the round robin working to your advantage- having it work only some of the time is better than not working at all.

  • Home directory not found

    Fedora 9 has a wonderful bug where the NFS shares that hold the home directories won't get mounted at boot time. This makes the machine virtually unusable. It doesn't happen every time, and is difficult to track. The current solution is for an admin to mount the directories manually when this happens. This issue will be resolved when the next lab image is built.

  • Fail to stop quotas

    This happens when a system is given the command to halt (stop, power off or reboot.) If the quotas don't stop almost instantaneously, the machine will hang indefinitely. Hopefully this doesn't affect any students, as it is against the usage policy to reboot machines. We are aware of it, and if we reboot a machine remotely we know to come check it if it isn't coming back up.

Linux Lab Fedora 10 Test Image

We are testing a new Fedora 10 image. Currently the test machines are in the TA Cube farm in the basement. The TA machines are the brand new hp dc7900s. Cubicle numbers 13-18 currently have the new hardware and image. TAs and Faculty are encouraged to test software used for classes, and written by students.

The old Fedora 9 image had a few issues with the new hardware, specifically the netboot process for Fedora 9 is incompatible with the integrated network interface card.

The current state of the Fedora 10 image is "mostly working". Here is the list of what issues are known, as well as a list of things yet to be done:

  • Matlab is not included in the test image.

  • A few software packages have not yet been added. This includes:

    • python-biggles
    • Adobe Reader
    • Firefox flash plugin
    • Python pexpect module

  • GDM does not have the customizations needed for our environment.

  • Software power down and reboot buttons have not been removed everywhere.

The machines do not synchronize their clocks properly, and if the time is too far off, kerberos authentication won't work. If a machine can't log in, and the time displayed seems incorrect, let a System Administrator know and they can synchronize the clock manually.

If you use one of the machines running the test image, and you find an issue. Please e-mail us at system@cs.byu.edu and we'll fix it as soon as we can.

Mac Labs

The macs haven't had any recent updates. Currently the mac lab is inaccessible due to the construction in the basement. There are, however, three open lab macs running in 2212 for the iPhone development group.

Not so Recent Changes

Password Requirements

A security audit a while back has resulted in our current policy in creating passwords. We realize that it may be frustrating when creating a password, but it protects your account, your files, and our servers from attackers.

We enforce fascistly secure passwords. Some tips to keep in mind:

  • Special Characters in passwords: Every password must have at least one, if

System Message: WARNING/2 (<string>, line 154)

Bullet list ends without a blank line; unexpected unindent.

not two, special characters. By "special character" I mean the following symbols (double quotes will not work):

';:[{]}\|=+-_)(*&amp;^%$#@!`~,&lt;.&gt;/?

  • Numbers in passwords: Use numbers, not just straight letters. "mymotherisahamster!" is not good enough. Instead try: "mym07er1s4h4m573r!" (neither of these would pass the tests though). This is called "l33t sp33k" (elite speak), and is a easy way to convert words. Just using this method is not enough though, and will fail our tests.

  • Spaces: Spaces, are allowed and can be quite helpful in passwords

  • How to get a password to pass the tests:

    1. Special characters in the middle of a password: "myf4th3r,sm3lt0f3ld3r-b3rr135!"
    2. Avoiding using single dictionary words, Book of Mormon words, Bible words, Star Trek words, and English and Non-English names
    3. If you do use words, use more than one. You're more likely to pass with 2 or more words involved in a password (as long as they only meet the dictionary word requirement). For all practical purposes, words like "if" "a" "the" do not count towards the number of words you've used.
    4. Avoid using things in your account (ie username, student id, email address, route-y id, etc).
    5. Use both upper- and lower-case letters.
    6. Try using acronyms, like "mmwahamfsoe-b!gaysek!" or "mMw4H4mF503-b!Gay53k!" (An acronym for: "My Mother was a Hamster and my Father smelt of elder-berries! Go away you silly English knights!").

  • Minimum Password length: 6

  • Maximum Password length: 16

Default Permissions

To increase the security of the system we've changed the default permissions of files and directories you create. They will now be created with the Unix permissions of 600 for files and 700 for directories. There are a few issues you need to be aware of. Please note, these tips are for Linux only.

Web pages

The default permissions are too strict for files that go into your public_html directory. If you want a file to be accessible for you web-page, open up a terminal and do the following:

cd public_html
find . -type d | xargs chmod a+rx
find . | xargs chmod a+r

That should fix your permission problems, and your student web-page should be viewable.

Do NOT under ANY circumstance change your public_html permissions to 777. This seems to be a possible hitch that has allowed some attacks on student web pages. Don't let it happen to your account.

Account Time-to-Live Policy

We enforce the CS account time to live policy. In other words, your account will be disabled and deleted according to a standard schedule.

  • At the end of every summer term CS undergrad's will have their accounts disabled.
  • At the end of every semester/term all guest accounts will be disabled
  • Any account that has been disabled for the period of a year will be deleted at the beginning of a new semester/term.
  • At the start of every semester/term we re-enable, automatically, all accounts of people who are enrolled in CS classes.
  • Once your account has been disabled, your student web page and email will still work, but if you're not coming back to BYU, we advise you to move to a new web page and email service, as they will cease to function after one year.

Student Webserver

The student webserver has been upgraded. It now uses php5, apache2.2, perl 5.10, and python 2.5.

Known Issues

If you are using php with the cgi-script handler (you give your php file a .cgi extension), make sure you use:

#!/usr/bin/php-cgi

One of the changes in php 5 is that the php executable doesn't output the headers. Things like POST ing to a php cgi script that isn't using the php-cgi binary won't work either.

If you don't do this, you'll get an apache 500 error saying that apache received an invalid header from your script.