This is the chapter of the MemberManual that describes things that new and current members must know about HCoop's setup. It is considered required reading before contacting HCoop administrators or filing support requests.

Joining HCoop

The pages in this section describe the joining process. If you are an HCoop member who is familiar with the portal and is getting announcement email from us, you may skip this section and move on to the good stuff.

• Prospective Member FAQ: Learn more about HCoop.

• Join HCoop: Join HCoop by completing a web form.

• New member: After your request is approved, you need to complete the joining process by making an account.

• Account created: After completing the joining process and making an account, you need to read a very quick summary about email forwarding, pledges, and mailing lists. These are the absolute essentials for being an up-to-date member.

AFS: A distributed filesystem

HCoop now uses AFS, a distributed filesystem, to implement much of our infrastucture. Home directories and email are stored in AFS. AFS allows for fine-grained access control and the ability to access your files from any machine that has an AFS/Kerberos client (including your local workstation, thus avoiding the need for SSH-ing in). That said, chmod and chgrp are not used at all. Read more to learn what this means.

Permissions in AFS are a bit different than standard UNIX file permissions. Basically, the group of a file and the standard read/write/execute permissions do not matter at all. In place of these, there is an access control list (called an ACL) for each directory, which is a listing of a role or person and the permissions that it has. An AFS ACL uses seven types of permissions: r (read), l (lookup), i (insert), d (delete), w (write), k (lock), and a (administer). "Read" and "write" are the same as their UNIX equivalents, and "lookup" is similar to the "execute" permission in UNIX -- it permits the files contained in the directory to be accessed. If you want to learn more about AFS permissions, see the relevant section of the AFS User Guide.

When a new directory is created inside $HOME, it receives a clone of the ACL for its parent directory. Every member's home directory starts life initialized with an ACL that allows listing by any authenticated party on HCoop, without granting any other permissions. However, you can change the ACL for your home directory or any of its subdirectories. Just remember that, if you don't take special actions to the contrary, every subdirectory of your home directory will be listable by anyone, and no file will be readable by anyone but you and the HCoop admins.

Individual files do not have ACLs; instead, files inherit the ACLs of the directories they are in. This is worth repeating: despite what you may be used to in UNIX, it's impossible to set per-file permissions in AFS. Instead, set permissions on the directories where files are found. This may require thinking about rearranging your directory structure.

If you wish to view the ACL of a specific directory, use:

fs listacl <DIRECTORY>

Please continue on to the AFS examples page for some annotated examples on how to set AFS permissions.

Kerberos: An authentication mechanism

SSH access to our system, as well as authentication to anything else at HCoop, is managed by Kerberos. You get a Kerberos ticket automatically whenever you log in. Tickets expire in 10 hours, and can also keep automatically renewing to last you a week. After 7 days since creation, your Kerberos tickets will expire and it will not be able to renew the any more; you'll have to create them anew manually, by providing the password. To see your Kerberos tickets, run klist -5 and to invoke initialization or renewal, run:

kinit

and type your password.

Kerberos and AFS work together. So if your Kerberos ticket expires, so will your "token" for access to AFS. Such an expiration isn't abnormal; you should expect it to happen to SSH sessions less than a day after log-in (after 10 hours, to be specific). That's worth saying again in bold: It's expected that long-running ssh sessions will stop working unless you take special action.

To get AFS access back after renewing your Kerberos ticket with kinit, be sure to type

aklog

At this point, please read the Distributed Security page to understand the consequences that using AFS and Kerberos may have on your HCoop experience. We feel the gains in security to be worth the slight learning curve.

More information on automatic token renewal can be found in MemberManual/RunningUnattendedCommands. You mostly just need to run the k5start program with the proper arguments. This section of this page could probably stand to be improved, as its topic is a common source of confusion.

Also note that ssh public key authentication won't work as you might expect on our servers. You can log in just fine, but you won't have any AFS tokens. You can still grab them manually with kinit and aklog, but this won't work so well with non-interactive users of ssh like scp. You can do passwordless login with the -K flag to ssh, which enables Kerberos authentication. See MemberManual/ShellAccess for more information.

Domtool: Manage domain-specific DNS/email/web

To manage all aspects of the Internet domains that our members own, we use a software suite called Domtool that we developed and maintain. Domtool allows us to easily share services among our members and enforce standards of correctness and security on configuration provided by members. Domtool facilitates DNS, email, and web serving, provided that you have a domain.

You may perhaps be familiar with Domtool version 1, which was used on our old setup. What we currently use is Domtool version 2, which is a complete rewrite. The syntax for these files has changed dramatically, in favor of more uniform syntax and semantics. A major benefit to this new format is that you only have to edit one file per domain, rather than an entire directory.

Please consult the Domtool User Guide at this point, so you can get an idea of what Domtool configuration files look like. When you are ready to set up your domain, the Domtool examples page should prove helpful.

Portal: Manage balance, request domains and packages

Our web portal at https://members.hcoop.net is where you will go to manage your account balance, request new domains, request Debian packages to be installed on our systems, and view various statistics about your website. You can log into the portal with the same username and password that you use to ssh to our machines.

Getting help from the admins

Whenever you have any problem using your HCoop account, first ask yourself this question:

• Is this problem specific to HCoop, or is the answer probably general knowledge among people familiar with Linux and the Internet?

If your problem falls into the "general knowledge" category, feel free to ask about it on our hcoop-misc mailing list or in our IrcChannel. However, we don't consider our admins to hold any responsibility for answering this sort of question.

If you have a genuine HCoop-specific problem, you should poke around this wiki some first to see if the solution is already documented. You might also try our IrcChannel, if you aren't sure that a solution requires admin intervention. If neither of these approaches helps, then visit the support page on the portal, which will direct you to the proper place to report your issue.

Please never e-mail any of our admins directly about any problem. The support page leads you to several automated systems that help us manage workflow much better than we can with ad-hoc e-mail. Only in the event that some of our web-based support machinery is unavailable should you use e-mail, and then you should e-mail all admins at once at admins@hcoop.net . You will often find admins in our IrcChannel, but they are under no obligation to provide any support there, as managing support tickets through IRC is close to impossible.

It's worth stating explicitly that the support policy is no different for billing issues and other social administrative concerns. The same support page is the right place to start to report this kind of problem, and you will probably end up following the link to report a Bugzilla bug. Please use the "Financial" Bugzilla component for billing inquiries.

Denyhosts: Protection from SSH attacks

We use the DenyHosts package to help protect your account from brute-force SSH attacks. If someone fails to log in as a particular user several times in a row, the original IP address will be blacklisted in order to prevent additional attempts within a certain time period. If this happens to you and you try to log in again, you will see something similar to this:

ssh_exchange_identification: Connection closed by remote host

The blacklist expires IPs after a predetermined period of time. Typically, most users will not be affected by the blacklisting, but if you are, you will want to file a report.

CategoryMemberManual