welcome: please sign in

Diff for "MemberManual/FAQ"

Differences between revisions 40 and 41
Revision 40 as of 2011-04-22 22:50:26
Size: 49
Editor: ClintonEbadi
Comment:
Revision 41 as of 2011-04-30 03:15:46
Size: 5896
Editor: RichardDarst
Comment: Revert to true latest version
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Wow! Great thnkiing! JK
----
CategoryCategory
#pragma section-numbers off
This page contains answers to questions often asked about DomTool and our setup.

<<TableOfContents>>

= Shell Access =

== 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 [[https://members.hcoop.net/portal/quota|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.

= Password recovery =

If you've forgotten your HCoop password, here's a simple and secure procedure to reset it:

 1. Visit Secure HTTP URL [[https://members.hcoop.net/passgen]]
 2. Remember or write down the request ID and the associated password that will be generated for you and shown on the page
 3. E-mail admins@hcoop.net with the request ID (NOTE: tell us only the request ID, not the password! We already know which password matches the ID, and sending the password over an unencrypted link (e-mail) defeats the whole purpose of password IDs.)
 4. When we process your request, a confirmation email will be sent to your @hcoop.net email address
 5. You can then log in with the password obtained in step 2.

This page contains answers to questions often asked about DomTool and our setup.

Shell Access

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.

Password recovery

If you've forgotten your HCoop password, here's a simple and secure procedure to reset it:

  1. Visit Secure HTTP URL https://members.hcoop.net/passgen

  2. Remember or write down the request ID and the associated password that will be generated for you and shown on the page
  3. E-mail admins@hcoop.net with the request ID (NOTE: tell us only the request ID, not the password! We already know which password matches the ID, and sending the password over an unencrypted link (e-mail) defeats the whole purpose of password IDs.)

  4. When we process your request, a confirmation email will be sent to your @hcoop.net email address
  5. You can then log in with the password obtained in step 2.

MemberManual/FAQ (last edited 2016-09-13 03:37:37 by JackHill)