MemberManual/FAQ

Can I use an ssh public key to log in?

SSH public key authentication will not work. This is a consequence of using Kerberos and AFS. However, you can obtain tickets and tokens on your personal computer (i.e. the machine you're sitting in front of), and use those tickets to log in to mire without using a password. For more information, see MemberManual/ShellAccess/PasswordlessLogin.

If you would like to know why things are this way, please see MemberManual/DistributedSecurity. The "short" answer is that sshd public key authentication only works when the fileservers grant admin access to anybody with root access to any of the shell servers; this is a major security risk that we do not take.

How do I run a shell session for a long time on mire?

If you want to have a long-running session with or without screen, there are simple ways to avoid AFS permission denied errors due to expiring tokens.

If you don't use screen, just pay attention to the kinit and krenew commands. krenew can be a daemon by using the -b argument.

screen
# Once screen has loaded (or you have begun a regular shell session),
# then execute the following commands, or place them in a script.
kdestroy
unlog
kinit -l 10d
krenew -K 540 -t -b

This will last until the ticket can no longer be renewed (approximately 8 days). However, you can kinit and krenew again while in the screen session to restart the clock. If the ticket expires while in a screen session, then you need to repeat those steps while in screen but be sure to add aklog for AFS ticket. You do not have to restart the screen session. In fact, you can dedicate a screen window just for monitoring and using kinit, aklog, and krenew. With this simple method, your screen session can run indefinitely with minimal weekly input.

Reference: MemberManual/TransferringFiles/OpenAFS/Debian

Domains

I created Domtool configuration for my domain and ran the domtool program on it, but my domain doesn't work at all.

Did you use the domain directive instead of the dom directive? domain is the primitive directive, where you must specify all details manually. If you're using domain and haven't listed the right nameservers manually, then your domain will definitely not work. Instead, use dom, which includes our current idea of the proper base configuration. We can change this later without any need for you to change your configuration.

There are various other ways that you could run afoul of this general problem, which is that our DNS servers won't answer any queries for zones that don't have some nameservers set. This behavior comes from BIND.

I changed my Domtool configuration file, but the changes don't seem to have taken effect.

You must always rerun the domtool program to publish changes. You can run it on an individual file, or you can run it without arguments to reload all configuration in your ~/.domtool directory.

Web Sites

How do I read my Apache logs?

They are stored in ~/.logs/apache in subdirectories corresponding to machine and domain, and are updated every 20 minutes.

Reference: MemberManual/ServingWebsites.

I get a very unhelpful "Internal Server Error" page from Apache when I try to access my dynamic web site content.

Check error.log in your virtual host's log directory. See the last answer for where that is.

E-mail

I can't access my e-mail via IMAP anymore.

Check your quota on your e-mail volume by doing

fs listquota ~/Maildir

If it is too low, then you will need to request an increase in disk quota.

Reference: MemberManual/Email

Custom Daemons

Services that worked fine yesterday suddenly don't work anymore.

The most likely reason for IMAP, DNS, and web hosting to suddenly stop working is that there is a syntax error in one of the files in your ~/.domtool directory. Admins sometimes need to regenerate all domtool configuration files after making a change to domtool; if one of the files in your ~/.domtool directory has errors, it could prevent other files in that directory from being activated.

To figure out whether this was the problem: for each file <FILE> in your ~/.domtool directory, run

domtool -tc ~/.domtool/<FILE>

If you see any problems, either move the file into a different directory, or fix the problems.

When done, run domtool on each file in your ~/.domtool directory, and everything should be back to normal.

It is highly recommended to keep files in a different directory while testing them, and then copy them to ~/.domtool once you are certain that they are error-free.

If you don't find any errors in your domtool configuration, then you might want to file a support request.

Reference: MemberManual/UsingDomtool.

Shell Access