[edit] What to do if something goes wrong
See our Frequently Asked Questions to begin with, as many questions are answered there.
You can always restart the configuration process by powering down your machine, removing the USB flash disk and powering it back up. If you encounter a problem, try that. If the problem persists, please contact us at 
[edit] Why do I have to write-protect the floppy only to write-enable it later?
We connect your machine to the network to test the network configuration in the middle of the configuration process. The floppy or USB flash disk should not be write enabled while the machine is connected to the network for security reasons.
[edit] Why does it take so long to boot or reboot LOCKSS?
The initial boot builds a file system on your disk. Subsequent boots may run "fsck" to check the structural integrity (but not the content) of the directories and files on the disk. On a large disk, this takes a while, especially if the machine was shut down without use of the "shutdown" command. You can tell that this is happening if there is a long pause after "Automatic boot in progress: starting file system checks." Also, every time the system is booted it installs a fresh copy of OpenBSD into a temporary file system on the disk.
[edit] I am having problems configuring LOCKSS mail. Any hints?
The LOCKSS box uses e-mail to send alerts and other status e-mail (only to the LOCKSS team and to you). It doesn't receive e-mail. Due to the diversity of anti-spam configuration in institutional mail relays, some sites have had problems with mail not being accepted for relaying from a LOCKSS box. We are working on a configuration which will be less problematic.
[edit] How do I change the configuration of the LOCKSS box after the initial configuration?
Remove the configuration device (floppy or USB) and reboot. (If using config-on-CD, reboot with the CD from the originally downloaded ISO image.) The previous configuration values will be supplied as defaults; enter the ones you wish to change and accept the rest.
To reboot, login as root on the console or via ssh, and type
halt. Wait for "The operating system has halted." before
powering off or rebooting.
Currently, we recommend you not change the IP address, as this will effectively erase the machine's reputation with other LOCKSS boxes, and put the content more at risk until the reputation can be reestablished at the new IP address. This restriction will be removed in an upcoming release. If you must change the IP address, please contact us.
[edit] Can I edit the N response to "Should this e-mail get daily system mail?" I would like to receive these mails in the first stages of "production", just to make sure my machine is up and running correctly.
Yes. You can just reboot with no floppy or USB flash disk - your old answers will be remembered and you can make a new floppy with any changes you need.
[edit] What should I do if prompted for "Ethernet interface"?
This should only happen when our attempt to auto-detect the ethernet interface fails. If you have some comfort with OpenBSD, you may be able to figure out what the interface should be by looking at the "Ethernet Adapters" section at http://www.openbsd.org/i386.html. Otherwise, let us know what kind of ethernet card you are using and we can tell you the interface to use.
However, drivers for some newer ethernet adapters may not be available yet for OpenBSD. In this case it will be necessary to replace the card with a different, supported card. This is particularly a problem with 3COM, which introduces minor incompatible technological "improvements" frequently, without changing model numbers. Because of this it is unlikely that a system with a brand-new 3COM NIC will work. If you have a brand-new 3COM card we suggest removing it before trying to run LOCKSS and replacing it with an old one. If you have an on-board 3COM interface, try disabling it and adding a NIC card, either an older 3COM card, or one from another manufacturer.
We have tested the NetGear FA312, and found that it works. You can buy it online here.
[edit] I see an error like: "savecore: can't find device 17/1 building ps databases: kvmkvm_mkdb: can't open /dev/ksyms" or "setting kernel security level: Dec 11 03:17:06 lockss savecore: can't find device 17/1"
These error messages are expected but not significant. For now, please ignore them.
[edit] When the system reached the stage of writing the config file, it gave a network error "?ifconfig fxp0: bad value?" or "Configuring unknown: ifconfig: SIOCGIFFLAGS: Device not configured"
(note: it actually says "CGIF" not "CFIG" FLAGS -- a typo)
It looks very likely that the fxp driver on the CD is too old for both the on-board NIC and the card. The next step is to find an older NIC card and try again. One site took the network card out of the previous LOCKSS box and put it in the new machine. There is always going to be some possibility when using brand-new hardware that it is ahead of the OpenBSD drivers.
[edit] I receive daily email with the message listed below ("daily insecurity output"), are those devices vulnerable?
machine name daily insecurity output Block device changes: brw-r----- 1 root operator 6, 0 Dec 6 21:11:03 2002 /dev/cd0a brw-r----- 1 root operator 6, 0 Dec 10 18:13:42 2002 /dev/cd0a brw-r----- 1 root operator 6, 2 Dec 6 21:11:03 2002 /dev/cd0c ...
No. The mail is generated whenever anything security-related changes on the system. The first time the mail is generated all the devices are a "change" - subsequent mails will happen only if something changes.
[edit] I got the following email ("JVM watchdog"), what should I do?
The JVM watchdog mechanism on beta4.lockss.org killed daemon process 24195 at Sun Jul 20 17:15:01 GMT 2003. The watchdog file information that caused the daemon to be killed was: -rw-r--r-- 1 lcap wheel 0 Jul 20 15:45 /tmp/lcap.dog -rw-r--r-- 1 root wheel 0 Jul 20 16:15 /tmp/lcap.time Please forward this mail to xxx@xxx for analysis.
Simply forward this message to us. The software monitors the daemon's java process through a watchdog. Sometimes the daemon "hangs". The watchdog fixes this by initiating a process to stop and restart the daemon. It also sends you a notification email. By the time you receive this email your LOCKSS box should be behaving normally.
Please send us this notification email; we believe this daemon hangs are caused by bugs in the JVM and we want to monitor how often they happen.
[edit] I forgot my root password, does the Stanford team have it?
We don't have access to your root password. To get another one, you'll need to reconfigure the machine:
- reboot the machine without a floppy
- follow the configuration instructions, supplying a new root password when prompted
[edit] How do I change the Admin UI password?
Reconfigure the machine, as above.
[edit] I accidentally removed my IP address from the admin access list. How can I add an address to the list if I can't access the UI?
- Login as root on the console
- Run
lynx http://localhost:8081/ - When prompted for Username, enter
lockss - When prompted for Password, enter the admin UI password you chose during configuration
- Move the cursor to Admin Access Control using the ↓ key, then type <Enter>
- Using the <space> and ↓ keys, move the cursor to the first blank line under Allow Access
- Enter the IP address or subnet mask of your workstation
- Move the cursor to the Update button (type <tab> twice)
- Type <Enter>
You should now be able to access the UI from your workstation.
[edit] Is LOCKSS compatible with RAID?
LOCKSS does not currently support RAID (hardware or software). Although it would be possible for someone to modify it to do so, the redundancy offered by RAID is unnecessary, as LOCKSS already has redundancy built in. The content stored on a single LOCKSS cache is meant to be replicated in many LOCKSS caches across the world. These caches vote on the hash value of the content regularly; caches that find they have damaged content will repair it from other caches or from the publisher's site.
[edit] How do I use ps to determine whether the server is running correctly?
Log or ssh in to the machine as root, using the password you supplied during installation. Type ps ax at the shell prompt. If the server is running correctly, the ps output should look something like this:
# ps ax
PID TT STAT TIME COMMAND
1 ?? Is 0:00.04 /sbin/init
14159 ?? Is 2:11.40 /sbin/mount_mfs -o rw -o nodev -s 1000000 swap /dist
1855 ?? Is 0:00.37 syslogd: [priv] (syslogd)
29925 ?? I 0:02.59 syslogd -a /var/empty/dev/log
23464 ?? Is 0:00.96 ntpd: [priv] (ntpd)
14245 ?? I 0:05.68 ntpd: ntp engine (ntpd)
9165 ?? Is 0:00.01 inetd
30828 ?? Is 0:00.82 /usr/sbin/sshd
8611 ?? Is 0:01.37 /usr/local/sbin/swdtd
15220 ?? Is 0:03.45 cron
7704 ?? I 0:00.04 /bin/sh /usr/local/lcap/test/startdaemon.sh
30401 ?? I 624:49.83 /usr/local/jre-1.4.2/bin/java -server -Xmx250m -Dsun.
12635 ?? Is 0:00.13 sshd: lcap [priv] (sshd)
19719 ?? I 0:00.14 sshd: lcap@ttyp0 (sshd)
24185 p0 Is 0:00.03 -sh (sh)
28329 p0 R+ 0:00.00 ps -ax
4337 C0- I 0:00.27 sh /etc/rc /etc/rc
775 C0 Is+ 0:00.01 /usr/libexec/getty Pc ttyC0
The important process is the one starting with /usr/local/jre-1.4.2/bin/java. (It will not have used as much time as shown here until the system has been up for several days.)
[edit] Can I run LOCKSS on another operating system, for example on one of our central servers?
Preservation in LOCKSS involves a number of activities:
- collecting new content
- delivering content to readers
- auditing content to detect damage
- repairing damaged content
All these functions are implemented in a single process that runs continuously and autonomously (a daemon, in the jargon). The daemon is implemented in Java and can, in theory, run in a wide variety of software and hardware environments.
The daemon has to communicate with other LOCKSS daemons over the public internet in a peer-to-peer configuration. It is therefore necessary to take the most stringent security precautions to prevent the machine running the daemon being attacked and subverted. It is very difficult even for skilled system administrators to secure a system adequately, especially one running a variety of services.
The LOCKSS team strongly recommends that the machine running LOCKSS be dedicated to that task and not be used to provide any other services.
The LOCKSS team provides the daemon packaged up on a CD image with a specially configured OpenBSD operating system. This CD boots and runs the daemon on a generic PC. It does not "install" the daemon on the disk in the conventional way - the system in effect runs from the CD. Rebooting the system returns the system to a known state, because all software is reinitialized from read-only media.
The LOCKSS team have taken great care to select the most secure available OS, to configure the system on the CD to minimize the risk of security breaches, and to provide mechanisms for updating the system to respond to any vulnerabilities that are detected. With our limited manpower, we are at present only able to support sites that run the daemon in this CD image environment.
