I've updated the version of Firefox in
/shared/local to 1.5, which is the latest release.
You can run Firefox by typing firefox at a terminal
prompt or by creating a GNOME Panel launcher by right-clicking on a
panel, choosing Add to Panel, then choosing Custom Application
Launcher and filling in the fields in the dialog box that will
appear.
You can find a Firefox icon in
/shared/local/firefox/icons. The canonical path to the
application until such time as it is installed by default on
individual machines is /shared/local/firefox/firefox.
For most people (unless you've tinkered with your
PATH), just putting firefox in the
Command field will do the trick.
Among other improvements, Firefox 1.5 supports RSS, Atom, and other feed protocols in a much more convenient way than previous versions of Firefox did.
Despite the dramatic-sounding title of this entry, I expect that there will be little or no actual change in the way that the system works for about 99% of the affected users.
As another short-term way of dealing with the ongoing disk space
crisis on /home/faculty, I have migrated the emeritti
and former-faculty accounts that had their home directories in
/home/faculty to a new partition on the server.
Practically speaking, there should be no real impact from this change for anyone, even the people whose accounts were moved, as I have added links to preserve the appearance of the file system.
If your account has been moved (you can tell by logging in and
running pwd, which will tell you your present working
directory) and you notice some issues, or if you try to reach a
personal web resource (i.e., one that has a URL similar to
http://www.math.hmc.edu/~someaccount) that is
no longer available, please report the problem to me so I can track
it down and fix it.
If you're interested in the details of what was done, most of it is pretty visible, kind of like post-surgical scars.
/home/guests is now a link farm, with symbolic
links pointing to actual directories that are located in
/home/guests-one or /home/guests-two. The
account database has been set up so that home directories for
migrated accounts are in /home/guests (that is, they
point to the links that point to the real directories).
Because of the limitations of NFS, we now have to export
/home/guests, /home/guests-one, and
/home/guests-two, and mount all three of those shares
on each machine that is available for general use.
The original directories in /home/faculty have been
replaced with links that point to the directories in
/home/guests, so any web-related links will still
work.
Because of the links, everything should work as it always has. At some point down the road, however, I hope to be able to add some additional disk space, which will allow me to do some rejuggling of account locations. At that point I will probably try to clean up some of the remaining links to make everything neat and less complex.
With the removal of the links, scripts or other materials that refer to hard-coded, complete paths to your home directory or directories within your home directory may break. In other words, if you had a script that looked for files in your home directory and specified them as
/home/faculty/username/some/directory/or/file
(where username is your username), but
your physical home directory is now located in
/home/guests-two/username, and is referred to
by the system as /home/guests/username, you
will have problems when one or more of the links is removed or
changed.
If you're working with shell scripts, the best way to refer to
your home directory is with the environment variable
$HOME, which is pretty much guaranteed to resolve to
the correct answer no matter what shell you or your script use. For
many modern shells (and scripts written in those shell's language),
you can use the tilde (~) to refer to your home
directory, but $HOME is safer and more likely to work
no matter what. (You'll want to use ~ on the command
line, of course.)
This mess will be cleaned up after we've obtained more disk space, which is on the agenda for a departmental computing-committee meeting on Friday. I hope that we will be able to find the money to move quickly on that project, and that I will be able to put additional disk space online over spring break (March 10 - 19).
In the meantime, keeping an eye on your disk usage and avoiding excessive disk usage (which I would define as usage that's significantly more than others with home directories in your partition) is, and will always be, a good thing to do that will benefit everyone else all the time, and you when you have a sudden, short-term need for a larger amount of disk space.
Thanks for your cooperation.
Version 1.5 of Mozilla Thunderbird, the Mozilla Foundation's e-mail client, was released today.
I have installed it in /shared/local/thunderbird,
where it takes the place of the previous release (which was 1.0.7).
The old release will still be available in
/shared/local/thunderbird-1.0.7 for at least a couple
of weeks.
Please enjoy the new release, and let me know about any problems that you have with it.
I have updated the version of Maple installed on our server to
10.02. It's set as the default, so just typing maple
or xmaple should launch the latest version.
If you have problems, (1) please
tell me, and then (2) run the previous version by specifying
the full path to the maple or xmaple
executables, as in
/shared/local/maple10.01/bin/{maple|xmaple}.
I noticed that there was support for the AMD 64/x86_64 64-bit processors in the update, but found that I didn't have the original installation media for the 64-bit version of Maple. I got a copy from CIS, so we now have both 32-bit and 64-bit versions of Maple available for your use (assuming you're using one of the 64-bit workstations the department has, of course).
To be honest, I'm not sure what having the 64-bit version buys you, as Maple is a symbolic math application rather than a major number cruncher, but 64-bits must be cooler than 32-bits, right?
As I've mentioned before, work is underway to replace the "brains" of the air conditioning system in the department's machine room and hook it into the general HVAC monitoring system.
Among the other things we keep in that room is a magic button that cuts the power for the servers in that room, a relic of the days when water-cooled mainframe computers might need to be shut down all at once to prevent electrocution.
These days, of course, our systems are air cooled. And they're all on UPS power, which means that hitting the panic button just switches them onto battery power. But the button is still there, waiting to be pressed....
Which is what happened this morning. The Physical Plant folks working on the air conditioning accidentally triggered the power cutoff. To make matters worse (and more confusing), the cutoff doesn't just affect the power in our machine room, but also the power in the scientific-computing lab, the publications room, and, I believe, at least one or two of the biology labs nearby.
Our servers, with their UPSs, were fine. But any jobs that were running on the scientific-computing lab machines were stopped when the power went out and the machines crashed. The machines rebooted, as they were set to, but they didn't restart your jobs -- you'll have to restart them yourselves.
Before you do that, however, I encourage you to review the department's policy on long jobs. Let me summarize for you: You're not supposed to leave processes running when you're not sitting in front of a machine unless you check with me first. The lab machines are meant for use by people sitting in front of them first, with people logging in remotely to run interactive jobs next. Long, unattended jobs should be run so that they don't dominate the processing power of the machine when someone is trying to do things at the console.
That means that you should
nice command, as in
nice -n 19
your_process_name
Ideally, you should also write your code so that it periodically writes out its status and results, and can resume by reading in that information and starting from where it left off. Writing such code is a bit more difficult, but it might save you from having to redo hours of computations when the power fails, someone reboots the machine because its running too slowly, or other unforeseen events stop your job from running.
If you're still looking for reasons to tell me about your long jobs, let me point out that I routinely update packages on the lab machines for security issues, and some of those updates require a reboot to take effect. If I don't know your job is running, I might reboot the machine without checking with you first. Letting me know means that I can maintain a list of machines to avoid rebooting without notice.
Please remember that the lab machines are a shared resource, and sharing requires that everyone using them behave responsibly and respect the other users.
I have updated our network install of Maple to 10.01, as mentioned in a previous entry.
I also have updates for standalone copies, so if you have one and you haven't updated by choosing the ``Check for Updates...'' option from the Tools menu, you can download the updates and apply them manually using the links in the previous entry.
Just in time for the new semester, both MathWorks, makers of MATLAB, and MapleSoft, makers of Maple, came out with new updates for their products.
Details about Service Pack 3 are available. The network install
has been updated; if you type matlab to start MATLAB
on a math Linux system, you'll get the service pack 3 version.
I haven't yet figured out what the best way of distributing updates to locally installed copies of MATLAB is; although it sounds like we're going to basically need to reinstall the app on each machine.
See our MATLAB support page for information and ways to run different versions (including the classroom or research licenses or older versions).
As of this writing, Maplesoft only has updates for the
single-user version of Maple. If you have Maple 10 installed on
your system and you would like to update it yourself, you can
download the
updates from our site (this link will only work for machines
with an hmc.edu address) or
get the updates direct from Maplesoft.
We will be updating our network install of Maple as soon as the media are available. Check back here for updates.
Our Maple support page may have additional information you might find interesting or useful.
Bringing us along into 2005, I have installed Firefox, the official Mozilla standalone web browser; Thunderbird, the Mozilla project's standalone mail client; and Nvu, the Linspire web-page editor, which happens to be based on Mozilla code.
All of these programs are installed in the
/shared/local partition, and should be usable from any
math department Linux system by simply typing firefox,
thunderbird, or nvu, respectively.
If you want to add an icon to your GNOME Panel or KDE Kicker,
please do so. Icons are hiding in sneakily named icons
directories inside the installation directories in
/shared/local.
I would strongly encourage you to consider using Thunderbird
with our IMAP server,
imap.math.hmc.edu, which will allow you to read mail
with Thunderbird while you're at a machine in your office or one of
the labs, but also read mail from a text-based mail client if
you're so inclined, and read mail using an IMAP mail client from
home.
Apparently the problems I was having getting Maple 10 working on the cluster were related to the problems with getting Maple 10 running on other machines. But they're sorted out now, so I have made Maple 10 the default Maple installation on the mathematics cluster!
Maple 10's interface has changed dramatically. Not surprisingly, it has lots of new features (and probably some new bugs, too). So I am keeping Maple 9.5 around for a while.
Running maple or xmaple will now
launch Maple 10. If you need to run the older version, you can do
so by typing the full path to the command, as in
/shared/local/maple9.5/bin/{,x}maple
or by adding the old path to your PATH environment
variable using one of the following methods:
setenv PATH /shared/local/maple9.5/bin:$PATH(fortcsh,csh)
or
set PATH=/shared/local/maple9.5/bin:$PATH(forbash,zsh,sh, etc.)
I expect that Maple 9.5 will be removed sometime before the end of the fall semester or whenever CIS's license server stops working for Maple 9.5.
I have installed the latest versions of Intel's FORTRAN and C++ compilers for
32-bit architectures in /shared/local/intel.
You can use the compilers by running
For the Intel C++ compiler
/shared/local/intel/bin/iccvars.csh /shared/local/intel/bin/iccvars.shFor the Intel FORTRAN compiler
/shared/local/intel/bin/ifortvars.csh /shared/local/intel/bin/ifortvars.sh
These commands set various environment variables
(PATH, MANPATH,
LD_LIBRARY_PATH, etc.) to include directories needed
to run the compilers. Their effects end when you quit the shell you
run them in (e.g., log out, close the terminal window). If you
should find yourself using these compilers all the time, you can
add the contents of these files to your own startup files.
The main advantages of the Intel compilers over the GNU Compiler Collection (gcc) compilers is that, in theory, Intel compilers take better advantage of the quirks in various CPU models. In practice, most code will not see a significant performance change when compiled with the Intel compilers, but there are exceptions. YMMV.
The Intel FORTRAN compiler also supports FORTRAN90 and
FORTRAN95, whereas g77, the GNU FORTRAN compiler, only
supports FORTRAN77 (as its name implies).
I have also installed the Intel Math Kernel Library, which provides mathematical functions optimized for use on Intel processors.
Documentation for these compilers and the Intel Math Kernel
Library is available in /shared/local/intel/doc, and
includes PDF and HTML manuals and training material.
Please note that our license for using these materials requires that they be used solely for noncommercial purposes. If you're planning to compile code that you hope to make money on, please use the standard GCC compilers or download your own Intel compilers. (Even better, don't do commercial work on our systems.)
Enjoy!
I've just purged the system of accounts that were marked as
expired as of 2004. The purge has gained us about 14 GB of space on
the /home/students partition, and bits and pieces
elsewhere.
If, by chance, I accidentally deleted an account that should still exist, please let me know as soon as possible. I can still restore such accounts from our disk or tape backups.
Faculty folks: If you end up working with a student whose account has been removed, we have a tape archive of the older accounts, so we can restore their contents if need be. There will be a delay, however, as I plan to store that tape in another physical location.
There's been a problem with the open file dialog in MATLAB ever
since we upgraded to MATLAB 7. The problem manifests itself as
follows: you click on File->Open from the menu bar or you click
on the open icon on the tool bar. You get a file picker dialog. You
move to the directory where your .mat file lives, then
click it to select it and click open or simply double-click the
file name. One of two things then happens: You get a dialog telling
you ``File not Found'' or you get an error message similar to
java.lang.InterruptedException at javax.swing.filechooser.FileSystemView.getFiles(Unknown Source) at javax.swing.plaf.basic.BasicDirectoryModel$LoadFilesThread.run(Unknown Source)
It turns out that this problem is somehow triggered by the
LANG environment variable (it looks like something to
do with Unicode). There are a couple of workarounds:
load or edit commands in the
MATLAB Command Windowscd in your terminal window or with the
navigation buttons in the MATLAB Current Directory browser pane)
and open files from the Current Directory browserLANG environment variable before
starting MATLABI have replaced the link to the latest MATLAB binary in
/shared/local/bin with a small script that unsets the
LANG environment variable and then starts MATLAB. The
change should be transparent to end users, but it should be
possible to open files directly from the open file dialog with this
change.
Note that if you start MATLAB in any way other than using the
matlab in /shared/local/bin, this change
won't help you. You can check to see what your shell thinks it
should run when you type matlab by typing the
following:
linux% which matlab
You should see
/shared/local/matlab/bin/matlab
If you don't, you can get the same effect by typing something similar to
For csh variants:
linux% ( unsetenv LANG ; /path/to/my/matlab ) &For Bourne-shell variants:
linux$ ( unset LANG ; /path/to/my/matlab ) &
Last night around 5:30 we had some issue with the department's
main server. They originally manifested as problems reading mail;
investigation showed that there was something up with
NIS, which
caused problems logging in, lsing files, and so
forth.
The server seemed to be thrashing badly; most of the systems
resources appeared to be devoted to the kswapd daemon.
ypserv was running, but not listening to any network
ports.
After trying various less drastic means to try to get the system
working properly (including dumping it down to single-user mode and
then back to network-server level, which initially seemed to work
but didn't last), I rebooted the server. When it came back up, it
(of course) had to run a check on the various /home
filesystems. As these total around 200 GB, this process took a
considerable amount of time. Once the checking was complete, the
server came back up and appears to be running normally at this
time.
I had been thinking about scheduling a reboot for this system in the near future, after classes and exams were over, so actually having to reboot it wasn't the worst thing in the world. (It had been running for 186 days without a reboot.) I do, however, apologize for any inconvenience you may have experienced when the server was unavailable.
If you notice any problems, please let me know ASAP so that I can take a look at them and get them resolved as quickly as possible.
There's probably no good time to upgrade your operating system, and I think that goes quadruple or more for a systems administrator. Suddenly your familiar working environment is completely different. Icons and menus have changed or are in different places. Some bits are missing. New functionality has replaced the old, familiar (working) functionality. Keys are remapped so they don't do the same things. Programs you used to have aren't there any more, because you don't have packages for this OS....
Of course, given a couple of days to concentrate, you could clear up the problem in no time. Just write that script to clean up old SRPMs and build shiny new RPMs you can install. Take the time to port your old configuration files over to the new system. Figure out where they moved things (and speculate on why). But a couple of days off are pretty rare in this biz, and when a user asks you a question, it's hard to say no. So you stumble along from issue to issue (A computer just died! No, two! Someone needs an application built! Someone else needs some technical advice on a paper they're writing! The printers aren't working! The mail system is broken!) and gradually piece your world back together.
All that is my way of saying, relax, I'll get back to you as soon as I can. As soon as I can get my editor work, the mail server to send mail, printers to print, TeX to TeX, and so on.... Just relax....
The mathematics department hasn't had any systems running Red Hat Linux 7.3 for almost a year now. Accordingly, we are announcing the end of support for Red Hat Linux 7.3, and we are removing packages built for Red Hat Linux 7.3 from our mirror server.
The removal of these obsolete packages will free up some space for supported systems and will also allow us to clean up our directory structure a bit.
Support for Red Hat Linux 9 and the Fedora Legacy packages for RHL 9 will continue until sometime this summer, when the last of our RHL 9 systems will be retired, replaced, or rebuilt.
CNet's news.com's Stephen Shankland has
an article on RHEL rebuilds. (I'm quoted!)
I have updated the versions of Sun's Java Software Devlopment Kits (SDKs) to the latest versions -- 1.4.2_07 and 1.5.0_02. The permission-elevation problem in the 1.4.2 series is addressed in the 07 update.
The standard Java remains 1.4.2. To use Java 5 (really 1.5), you
will have to run the binaries by typing their full pathnames or add
the Java 5 directory to your PATH. I recommend that
rather than using the release-specific directory, you use
/shared/local/java5, which is a link that will be
updated to point to the latest version installed on the system.
MathWorks has announced the release of Service Pack 2 for Release 14 of MATLAB. I will be installing it as soon as I get hold of the media, but in the meantime, you can read about the changes in this release.
Please note that I will be installing the new release in
parallel with the existing release. To use it, you will need to
specify the complete path to the new version of MATLAB on the
command line, or add the new directory to your PATH
before the old directory.
If you're in the habit of connecting to your dorm room machine
as name.st, you should be aware that a recent
change in the domain-name system means that you may not end up
connected to the machine you meant to reach.
The DNS system allows partial domains to be completed, so typing
dormbox.st on a math department system would cause the
resolver to try dormbox.st, then
dormbox.st.math.hmc.edu, and finally
dormbox.st.hmc.edu.
The people responsible for the .st domain -- is a
top-level country domain (TLD) meant for use by Saotome and
Principe, an island nation in the Gulf of Guinea, near Africa --
have changed the behavior of their server so that any hostname
ending in .st now resolves to a real site or to a site
offering people the chance to buy that domain name. This change
breaks the shortcut behavior you may have grown used to.
If you try to ssh to your dorm machine and you see
something like the following:
[user@mathhost]% ssh dormbox.st The authenticity of host 'dormbox.st (195.178.186.40)' can't be established. DSA key fingerprint is 48:fe:31:ba:16:9b:a2:ae:16:6d:f6:1f:cc:46:38:50. Are you sure you want to continue connecting (yes/no)?
There are a couple of clues here. The first is that SSH is telling you that it doesn't know about the host you're trying to connect to. It does that if it's never connected to a particular machine before, or if the host key has changed (e.g., because the machine's operating system was reinstalled). The second is that the IP address -- 195.178.186.40 -- is not within the Claremont Colleges' IP address space, which starts with 134.173.
Notice that SSH gives you a ``key fingerprint'' to check the authenticity of the host. The SSH fingerprints of the machines in the mathematics department are available for you to check on our security information page, which will help you if you're connecting to them from another machine.
Shell aliases offer a quick and easy way of defining a shortcut
for reaching your dorm machine or other machines you connect to
frequently. In addition to the hostname, you can also include other
parameters that you would have to specify on the command line. For
example, you might define an alias called home that
actually runs the command ssh -X
me@dormbox.st.hmc.edu, which can be especially handy if your
username on the other machine is different than your username on
the math cluster.
You can define such an alias with the following commands:
alias home 'ssh -X me@dormbox.st.hmc.edu (for
csh/tcsh)
alias home='ssh -X me@dormbox.st.hmc.edu (for
sh/bash/zsh)
You can define those aliases every time you log in by adding
them to your ~/.tcshrc, ~/.cshrc,
~/.bashrc, or ~/.zshrc, depending on
which shell you're running. And, of course, you can define as many
as you like for any machines you routinely connect to.
Red Hat released version 4 of their Red Hat Enterprise Linux products last week. RHEL 4 is based on Fedora Core, Red Hat's ``free'' distribution, and includes features such as GNOME 2.8, SELinux, and the 2.6 Linux kernel.
RHEL 4 also drops the Mozilla suite in favor of Firefox and Thunderbird, and changes a whole bunch of other stuff in ways I haven't yet discovered.
CentOS 4 will be coming out soon, incorporating these changes.
I have been running a release candidate of CentOS 4 on a machine in my office, and thus far my impression is that it has many shiny improvements over CentOS 3, but that the changes may cause some issues if they aren't handled carefully. I expect to install CentOS 4 on my workstation and run it for a while before making a decision about rolling the new version of the OS out onto desktops. (Among other things, there's a fair amount of locally built and deployed software that will need to be rebuilt, updated, or replaced before a rollout can happen.)
Exactly when we upgrade workstations to CentOS 4 is unclear at this time, although it's likely that the upgrade will happen this summer at the latest, and probably sooner than that for lab workstations.
I may update the Amber cluster sooner, to see whether the changes affect some problems that have been seen there. Our servers will remain on CentOS 3 until I can see clear evidence that updating them would add enough valuable features to be worthwhile.
As usual, if you have any questions or comments, please feel
free to write to me at cmc@math.hmc.edu.
One of the MCM/ICM contest participants just brought a problem
with the shell startup scripts to my attention. The basic problem
was that there were no .tcshrc or .login
files in the home directories for accounts created since
mid-September, which, coincidentally, was when I upgraded our main
server from Red Hat Linux 9 to CentOS.
The result was that new accounts weren't sourcing the
global.tcshrc and global.login scripts,
which meant that their PATHs and other important
variables and aliases weren't being initialized properly.
I've fixed the problem. The longer term solution is to actually modify the default startup scripts on the machines, which is the ``right'' way to do things, and I will get around to doing that before too terribly long. I hope.
In the meantime, all should be back to normal. Remember, if you can't run standard software such as MATLAB, Maple, Java, and Acrobat Reader, please let me know. Making things work, and fixing them when they break, is why I'm here. But I don't use every tool available on the system, and I'm not always aware when things break.
To my amazement, New Egg
came through incredibly quickly and elijah and
ramandu are now back on line with shiny new video
cards and readable screens. Enjoy!
Both elijah and ramandu have bad video
cards. As a result, they're pretty much unusable interactively
until I can find replacements, get them ordered, installed, and
configured. Sorry for the inconvenience.
You can help avoid equipment downtime in the future by actually reporting it!
Yes, it's true, now that my office is no longer inside the lab, I don't get into the lab as much these days. That means that I rely on you, the users of the Scientific Computing Lab, to let me know when something's a bit funky. If the machine is reachable on the network and responds to various network-oriented tests, I'll have little reason to assume it's not working fine. But you can tell me if its keyboard is sticky, or the mouse is wonky, or the video is all wavy, or some other problem that's only obvious from sitting directly in front of the machine is present. Please tell me. I won't get mad (unless you tell me you deliberately poured a soda into the keyboard to see what would happen -- please don't do that). And the sooner I know about the problem, the sooner I can try to get it fixed.
Thanks.
Over a long break, students, staff, and faculty scatter around the country and the globe, visiting friends and family, and encountering new variants of diseases that they bring with them on their return.
Those of us who took our computers with us may well be exposing other computers at the college to similar risks. If your anti-virus software wasn't up to date before you left, plugging into dad's company's network, your brother's LAN party system, or your high-school friend's DSL line may have infected your machine with a virus or worm that you've brought back to share with everyone else at Mudd.
Now that you're back, take a minute to make sure that your anti-virus software is updated, and run a full scan on your machine. Make sure that there's nothing (unintentionally) weird going on with your machine.
You might not care what infects your machine, but your neighbors (and CIS) might.
If you don't already have anti-virus software on your machine, CIS provides Sophos anti-virus software for the Mudd community.
They have detailed instructions for installing it for Windows.
Much to my surprise, Firefox 1.0 seems to work on my machine. I've been having problems getting any recent version of Mozilla itself to work -- rebuilding packages from Fedora has resulted in mysterious ``nothing happens'' errors, which have left me without a fully functional web browser, which is not a good thing.
But Mozilla's prepackaged Firefox seems to work fine, so I'm happy for now!
As the end of the semester rapidly approaches, you may be considering creating more portable archives of your files (especially if you're graduating -- remember that accounts of graduating students expire on July 1!)
Happily, I bought and installed a 52X CD-ROM burner in
tumnus, one of the machines in the scientific
computing lab. Anyone sitting at the console of this machine should
be able to create and burn CDs using gtoaster or
xcdroast.
See Burning CDs for more information on how to burn CDs with this drive.
Printing is back. Tape backup system restored. Spamassassin running again. Other backend services restored/adjusted.
Lab and faculty machines are now rebooted. If you have problems reaching them, with file access, or with anything else that doesn't seem to work the way it used to, please let me know ASAP. Thanks.
Please remember that during the remainder of the break access may still be suspended temporarily while I do minor maintenance. Significant service breaks will be announced here and by e-mail at least a day before they happen.
Incoming and outgoing mail working. Authentication working. UPS working. NFS working. Time to go home. More testing and configuration tomorrow.
Temporarily restored mail and printing service while prebackup copies complete.
Many services have been shutdown in preparation for the final backups. These services include:
Mail should be picked up by an alternate server and delivered when our main server is up again.
I will be performing an upgrade of the operating system on the department's main server, esme, on December 29, 2003. The upgrade itself should be fairly straightforward, but I am reserving the following two days for reconfiguring services and testing. Access to the department's systems will be undependable during this time period.
Services affected will include: file service (home directories), remote login, e-mail, and printing. I will be shutting down nonessential workstation systems during the outage.
I plan to temporarily relocate the core of the department's
website to the web server, so access to the website should continue
during the service outage (with the exception of personal websites
located in ~/public_html directories).
Because the web server will remain available, you will be able
to check in on progress on the computing support page, <http://www.math.hmc.edu/computing/>
(i.e., right here).
I will be performing other work during the break that may make access unreliable or impossible. I will send out mail in advance of such work, but it's safe to assume that if you can't log in to a workstation (directly or remotely), it's work-related. Feel free to send me e-mail if an outage lasts for longer than a couple of hours (or call me, if e-mail is affected).
I've installed version 1.0.3.1 of OpenOffice on the department's server. If you're already an OpenOffice user, you'll find that starting one of its programs will cause the installer to start. You'll need to go through the same steps you went through when you first installed OpenOffice -- for a refresher, be sure to check our OpenOffice installation page.
Meanwhile, I'm working on cleaning up some older software.
OpenOffice is an improved version of StarOffice, which we currently
have installed, so StarOffice is on the chopping block. If you use
StarOffice (soffice) and haven't installed OpenOffice,
please install OpenOffice and use that instead. I will be removing
StarOffice at the end of June.
We have doubled the RAM in the OptiPlex GX400 and Precision Workstation machines in the Scientific Computing Lab to 512 MB each. The increase should give users a bit more headroom for large computational jobs, and might also make some other things a bit more zippy.
Mathematics department computer systems will be unavailable from roughly 10:00 PM Saturday, 2003 May 24 through noon on Sunday, 2003 May 25 while Southern California Edison does some work that requires shutting off power to the Claremont Colleges campuses.
Please be sure to log out of all department computers before 10:00 PM on Saturday. I will be logging in remotely to shut down all Linux workstations at that time.
Please shut down any Windows computers, printers, or other electrical equipment you have in your office that might be damaged by a power outage.
Systems may be available after 7:00 AM on Sunday when the Colleges' generators start running, depending on whether the servers are still running at that time. You can check server status by
sshing to shell.math.hmc.edu. If your
home directory is available, things are working.I will be in around 11:00 AM on Sunday to start any servers that were powered down during the power outage.
OpenOffice installation instructions available. If you have ideas about other applications that need documentation, let me know.
I have installed Spamassassin, a spam-filtering package, on the department's mail server. I've added some information about SpamAssassin to the e-mail section of the department'ssupport area.
Accounts for Harvey Mudd students who are graduating in 2003 will expire on 2003 July 1, as will all accounts belonging to non-Mudd students. Please be sure to copy anything that you want to keep to some other location before July 1.
Guest accounts and student accounts whose expirations have been extended will also expire on 2003 July 1.
If you need access to your account after July 1, brief access will be granted on a case-by-case basis. Password resets will require you to see the systems administrator in person, with a photo ID.
If you need longer-term access, please talk with a faculty member about getting an extension. You should fill out another account-request form (PDF) and obtain the necessary signatures. Renewed guest accounts will be good until 2004 July 31.
The machines in the Scientific Computing Lab have been upgraded to Red Hat Linux 7.3. As a result, there are several changes that will affect your interaction with the systems:
xpp anywhere you would ordinarily use
lpr, and you'll get a graphical print dialog similar
to the ones you get with Mac OS or Windows.dvips behavior has changed so that
dvips, by default, produces a PostScript file rather
than dumping output to your default printer.
To get the old behavior, edit your ~/.tcshrc and
add the following line:
alias dvipsp 'dvips -o|lpr'
There are many other changes -- subtle and otherwise -- that I can't easily summarize here. For more information, you may want to read Red Hat's release notes for 7.3.
If you notice any problems, please let me know by sending mail
to system@math.hmc.edu.