432016-09-13 03:37:37cpe-76-182-123-219.nc.res.rr.comPassword reset instructions on this page were out of date. Link to the GettingHelp page instead.422013-01-14 09:24:32ClintonEbadicat412011-04-30 03:15:46RichardDarstRevert to true latest version402011-04-22 22:50:26ClintonEbadiRevert to revision 38.392011-04-21 16:29:12li243-120.members.linode.comL1VSnN <a href="http://avfjtuxectow.com/">avfjtuxectow</a>382011-04-21 10:29:1482.160.79.187Wow! Great thnkiing! JK372011-03-30 18:43:22user-0c8h24l.cable.mindspring.comremove fyodor migration info362010-03-29 12:22:09DavorOcelic352010-03-29 12:21:12DavorOcelic342009-11-18 13:30:43DavorOcelic332009-11-18 13:18:38DavorOcelic322008-12-19 00:44:21dhcp-37-70.EECS.Berkeley.EDU312008-12-19 00:36:36dhcp-37-70.EECS.Berkeley.EDU302008-12-19 00:35:11dhcp-37-70.EECS.Berkeley.EDU292008-12-06 00:46:02hgwm3.oceanic.com282008-12-06 00:43:04hgwm3.oceanic.com272008-12-03 16:55:00MichaelOlsonAdd FAQ item about ssh public keys262008-07-07 04:28:18localhostconverted to 1.6 markup252008-01-01 21:27:25AdamChlipalaClarify BIND semantics242007-12-29 02:05:23AdamChlipalaDomtool hints232007-12-29 00:09:08AdamChlipalaReorganize and add "Internal Server Error"222007-12-27 04:12:52MichaelOlsonAdd Email quota FAQ item and reword title212007-12-16 19:08:10RyanMikulovskystress that kinit, krenew can be used in regular shell sessions202007-12-04 14:27:21MichaelOlsonDestroy existing tickets for screen FAQ item before acquiring new ones192007-11-30 13:56:15JustinLeitgebAnswer question related to domtool changes from old infrastructure182007-11-30 05:17:13cpe-66-27-155-248.socal.res.rr.com172007-11-29 14:10:30RyanMikulovskyreplace "things" with "services"162007-11-29 14:09:47RyanMikulovskyadd key phrase permission denied152007-11-18 17:43:36RyanMikulovskymake running screen session on mire sound easy!142007-11-18 17:40:15RyanMikulovskyadd part about having commands in its own window132007-11-18 17:38:11RyanMikulovskyadd a few more details to the screen session part122007-11-18 17:34:31MichaelOlsonNo need for pagsh after all112007-11-18 17:24:25MichaelOlsonAdd kinit command to the screen FAQ, so that it actually works102007-11-16 22:59:21MichaelOlsonRemove notice about needing verification92007-11-16 22:56:46bzq-84-108-20-56.cablep.bezeqint.net82007-11-16 22:54:45bzq-84-108-20-56.cablep.bezeqint.netsimplified screen example72007-11-16 22:13:16MichaelOlsonUse pagsh for now62007-11-16 21:39:05MichaelOlsonAdd references, and add item for screen and long-lived sessions52007-11-14 15:24:18MichaelOlsonclarify apache logs42007-11-14 15:23:23MichaelOlsonAdd to .domtool explanation32007-11-14 15:20:27MichaelOlsonAdd apache logs question22007-11-14 15:13:37MichaelOlson12007-11-14 15:11:45MichaelOlsonInitial contentsThis page contains answers to questions often asked about DomTool and our setup.

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.

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. 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

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.

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.

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

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

Check your quota on your e-mail volume by doing If it is too low, then you will need to request an increase in disk quota. Reference: MemberManual/Email

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 ]]>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.

If you've forgotten your HCoop password, please see that password reset instructions CategoryMemberManual