7665
Comment:
|
11881
|
Deletions are marked like this. | Additions are marked like this. |
Line 15: | Line 15: |
= Step 1: Get a mire account = | = Getting started = == Step 1: Get a mire account == |
Line 30: | Line 32: |
= Step 2: Try logging in = | == Step 2: Try logging in == |
Line 36: | Line 38: |
= Step 3: Visit the new portal = | If you fail to log in correctly a few times the DenyHosts scripts will lock you out. Currently any blocked IP's are purged after a week, so if you don't want to wait you'll need to submit a ticket, or if you can't access the portal to do this you'll need to send an email to hcoop-sysadmin@hcoop.net. == Step 3: Visit the new portal == |
Line 42: | Line 46: |
= Step 3: Have your mail dual-delivered = | == Step 4: Have your mail dual-delivered == |
Line 54: | Line 58: |
= Step 4: Copy your existing email = | and you mail will be dual-delivered. == Step 5: Copy your existing email == |
Line 59: | Line 65: |
rsync -are ssh --progress --verbose ~/Maildir/ mire.hcoop.net:Maildir/ | rsync -are ssh --no-g --progress --verbose ~/Maildir/ mire.hcoop.net:Maildir/ |
Line 64: | Line 70: |
We have a [https://bugzilla.hcoop.net/ Bugzilla] that we plan to use for managing support requests that don't fit into the special categories handled by the portal. Bugzilla accounts for all migrated members will be coming soon. It will use the same usernames and passwords as for login and the portal. | We have a [https://bugzilla.hcoop.net/ Bugzilla] that we are using for managing support requests that don't fit into the special categories handled by the portal. If you've completed the migration steps above that create your mire account, then you can use the same username and password to access Bugzilla. You can also start from the portal, which links to Bugzilla from the support page. |
Line 76: | Line 82: |
The `createdb <DBNAME>` command creates a database named `<USERNAME>_<DBNAME>`. | The `createdb <DBNAME>` command creates a database named `<USERNAME>_<DBNAME>`, and `dropdb <DBNAME>` drops a database. For security/accounting reasons, you won't be granted permissions to drop a database in the usual way, through an SQL session. |
Line 78: | Line 84: |
To access your database use the following on mire: `mysql -p -h deleuze` or `psql -h deleuze USERNAME_DBNAME` | Sometimes we update our policies for which permissions users are granted on their databases. To re-set the permissions for a database after such a change, run `grant <DBNAME>`. At the moment, this can only ever be necessary for MySQL databases. To access your database use the following on mire: `mysql -p -h mysql <USERNAME>_<DBNAME>` or `psql -h postgres <USERNAME>_<DBNAME>` |
Line 116: | Line 124: |
== Virtual mailboxes == The `vmail` program from fyodor has been updated for the new servers. Here's a quick run-through of how to invoke the new version. Like before, you always invoke it with `vmail $DOMAIN $COMMAND`, which indicates that you are configuring the virtual mailboxes for domain `$DOMAIN` for which you have DomTool permissions. The valid commands are: * `list`: Print the mapping from usernames to mailbox directories for `$DOMAIN`. * `add $USER $MAILBOX`: Add a mapping from `$USER@$DOMAIN` to a Maildir directory `$MAILBOX`. You'll be prompted to enter a password for the user, which he can then use to access IMAP, POP, or restricted SMTP services. * `passwd $USER`: Reset a virtual user's password. * `rm $USER`: Remove a mapping. The mailbox directory remains for you to deal with as you like. |
|
Line 120: | Line 137: |
= security = | = Security = |
Line 122: | Line 139: |
See RealSecurity for some notes on security. | See RealSecurity for some technical notes on security. == Securing Directories == First of all, UNIX permissions carry no weight with AFS -- therefore they are useless to you. Instead, use Access Control Lists (ACL), which are a far more powerful way of restricting access to parts of a file tree. That said, when a new directory is created inside $HOME, its ACL defaults to allow listing by any authenticated party on HCoop. Note that ACLs cannot be set on individual files. They inherit the ACL from its parent directory. If you wish to make a directory within your $HOME completely private so that only you can list, read, and write, do this: {{{ mkdir ~/private fs setacl -clear ~/private <USERNAME> all }}} Note that {{{-clear}}} removes any previously set ACLs and {{{<USERNAME> all}}} sets full access to the directory's contents to the specified user. Therefore, if you have a directory in $HOME that you wish to make only accessible to you (such as ~/.ssh or ~/documents), use: {{{fs setacl -clear ~/<DIRECTORY> <USERNAME> all}}}. '''NOTE''': ''do not'' apply any ACLs to ~/domtool or ~/public_html, as they may become inaccessible to necessary services such as a webserver. If you wish to view the ACLs on a specific directory, such as any you have just applied an ACL, use: {{{fs la <DIRECTORY>}}} == Log-In Security == We use the [http://denyhosts.sourceforge.net/ DenyHosts] package to help prevent user accounts from brute-force attacks. If a user fails to login within several attempts, then the offending originating IP will be blacklisted in order to prevent additional attempts. If the individual attempts to login again, then he will see something similar to the following: {{{ssh_exchange_identification: Connection closed by remote host}}} The blacklist expires IPs after a predetermined period if time. Typically, most users will not be affected by the blacklisting, but if you are, you will want to contact a sysadmin to remove your IP from the list. = WebDAV = WebDAV is accessible at https://dav.hcoop.net/. WebDAV is useful when working on a website using systems that cannot mount an AFS share. For details on how to setup WebDAV, take a look at http://research.cs.berkeley.edu/doc/dav/ Note that you can only use WebDAV on directories that have {{{system:anyuser rl}}} as part of its ACL. You'll be able to write even if {{{system:anyuser}}} does not. See Securing Directories on this page for additional details on directory ACLs. |
For the purposes of this page, we'll use the name New to refer to the servers hosted at Peer 1 (which are deleuze, mire, and eventually abulafia) and Old to refer to any servers that we've used previously.
Note: We are in the process of migrating people who have signed up as guinea pigs. We are not currently accepting new domain requests or providing help to non-guinea-pigs. This will change once we have made reasonable progress in working out the kinks of the new setup.
1. Summary of what exactly is going on here
We are now offering limited-access accounts on the new infrastructure (see NewServersSetup) on a "beta test" basis to all users who have accounts on fyodor. These accounts come with no uptime or service guarantee; during the next few weeks we may need to temporarily disable them from time to time. Please do not use them for anything important.
These accounts will allow you full access to your space in AFS (currently 400MB per user) and the ability to log in to mire.hcoop.net via ssh. Currently NO OTHER SERVICES are officially supported on the new infrastructure (for example, email or serving HTTP), although we hope to make these available soon.
Requesting an account on the new infrastructure will not affect your fyodor account. You will have access to both accounts until after all migration is complete.
2. Getting started
2.1. Step 1: Get a mire account
We have created a file in each fyodor user's home directory called .mire-password. This file is readable only by you and the admin who will be processing the account creations.
If you would like to get a mire account, please put your desired password in the file ~/.mire-password. Please be VERY careful not to delete this file or change its permissions. The recommended procedure is to type:
cat > ~/.mire-password
and then type your desired password, press enter, and then press control-D. After you do this, please run the command:
ls -l ~/.mire-password
and make sure that the permission bits are -rw-rw---- (user and group can read and write) and the group for the file is set to megacz.
We will be running an account-creation script approximately once a day. After you put your password in ~/.mire-password, your account will be created the next time the script is run, typically no more than 24 hours after you specify your password. An email will be sent to your hcoop account to let you know that your account has been created. Your .mire-password file WILL BE DELETED when your account is created, so please make sure you memorize it before writing it to the file.
2.2. Step 2: Try logging in
If you've always been typing a password to log in via SSH and don't care to do otherwise, then you don't need to bother reading this section!
You can't use SSH public key authentication anymore. Kerberos authentication ("ssh -K") is supported, for passwordless log-in. Some day, someone might implement the Kerberos support needed to make SSH public key auth work again. See RealSecurity for more information on all of this.
If you fail to log in correctly a few times the DenyHosts scripts will lock you out. Currently any blocked IP's are purged after a week, so if you don't want to wait you'll need to submit a ticket, or if you can't access the portal to do this you'll need to send an email to hcoop-sysadmin@hcoop.net.
2.3. Step 3: Visit the new portal
[https://members2.hcoop.net/ The new portal] uses the same password you use to log in to mire. That is, if you haven't created a mire account yet, then you can't access the new portal.
You should use the new portal for all administrative requests related to the new servers, except for...
2.4. Step 4: Have your mail dual-delivered
We recommend that you tell fyodor to dual-deliver all of your mail so that one copy goes to deleuze and one copy goes to fyodor. That way you can start reading your email via deleuze, but if anything goes wrong you can just switch back to fyodor.
To do this, put the following lines in your ~/.forward file on fyodor. Note that the comment on the first line is mandatory -- it tells exim that this forward file uses special exim features. If your username was fred, you would put this in your ~/.forward:
# Exim filter deliver fred deliver fred@deleuze.hcoop.net
and you mail will be dual-delivered.
2.5. Step 5: Copy your existing email
You can also copy the contents of your mailboxes from fyodor to deleuze. To do this, log in to fyodor and type:
rsync -are ssh --no-g --progress --verbose ~/Maildir/ mire.hcoop.net:Maildir/
3. Bugzilla
We have a [https://bugzilla.hcoop.net/ Bugzilla] that we are using for managing support requests that don't fit into the special categories handled by the portal. If you've completed the migration steps above that create your mire account, then you can use the same username and password to access Bugzilla. You can also start from the portal, which links to Bugzilla from the support page.
4. Databases
Here lie interim dbtool docs until migration is done, at which time they will probably move to UsingDatabases.
To manage your database user and databases, the basic syntax is dbtool <DBTYPE> <COMMAND>, where <DBTYPE> is postgres or mysql.
The adduser command creates a database user for you, with the same name as your UNIX log-in name. In the case of mysql, you will be prompted for a password and confirmation re-entry in the usual manner.
The passwd command allows you to reset the password. (Useless for postgres, where we use only ident authentication)
The createdb <DBNAME> command creates a database named <USERNAME>_<DBNAME>, and dropdb <DBNAME> drops a database. For security/accounting reasons, you won't be granted permissions to drop a database in the usual way, through an SQL session.
Sometimes we update our policies for which permissions users are granted on their databases. To re-set the permissions for a database after such a change, run grant <DBNAME>. At the moment, this can only ever be necessary for MySQL databases.
To access your database use the following on mire: mysql -p -h mysql <USERNAME>_<DBNAME> or psql -h postgres <USERNAME>_<DBNAME>
5. DNS
We are purposely not sending any DNS data from New to Old, which means that you need to change domains at your registrar if you want New to be authoritative for them. The proper nameservers are ns1.hcoop.net and ns3.hcoop.net, in that order. Keeping ns.hcoop.net and ns2.hcoop.net will not work.
6. Domains
See the DomTool page for instructions on managing your domains with the new setup. The configuration files are in a vastly different format, but they have a better-defined syntax that should be relatively easy to understand.
7. Home
Your home directory is now managed by AFS. You will enter it by default when logging in to mire.hcoop.net via ssh. Type pwd to see what the path is. It will look like /afs/hcoop.net/user/u/us/username. Some directories have been created for you already, so that they have the correct permissions for things like serving web pages and delivering mail.
8. Email
8.1. .forward
~/.forward files should have the same effect that they do with our old setup.
8.2. IMAP
SSL IMAP is available via SSL at port 993, using hostname deleuze.hcoop.net.
STARTTLS IMAP is available on port 143, using hostname deleuze.hcoop.net.
8.3. POP3
POP3 access is available via SSL at port 995, using hostname deleuze.hcoop.net. If you're using Thunderbird, make sure to uncheck "Use secure authentication". Do not use port 110; it is not available, because no good way of securing normal POP3 has been found by the admins.
8.4. procmail
The page ProcmailExample has been updated for the new setup. Basically:
Use the file ~/.procmail.d/procmailrc instead of ~/.procmailrc.
Write any procmail logs in ~/Maildir rather than elsewhere.
Use appropriate values for the HOME, MAILDIR, and DEFAULT options, based on those in ProcmailExample.
8.5. Virtual mailboxes
The vmail program from fyodor has been updated for the new servers. Here's a quick run-through of how to invoke the new version. Like before, you always invoke it with vmail $DOMAIN $COMMAND, which indicates that you are configuring the virtual mailboxes for domain $DOMAIN for which you have DomTool permissions. The valid commands are:
list: Print the mapping from usernames to mailbox directories for $DOMAIN.
add $USER $MAILBOX: Add a mapping from $USER@$DOMAIN to a Maildir directory $MAILBOX. You'll be prompted to enter a password for the user, which he can then use to access IMAP, POP, or restricted SMTP services.
passwd $USER: Reset a virtual user's password.
rm $USER: Remove a mapping. The mailbox directory remains for you to deal with as you like.
9. rsync
If you're using rsync to transfer data to the new servers, the "-a" option by itself won't work properly because rsync attempts to chgrp the transferred files. Use "-a --no-g" instead of "-a".
10. Security
See RealSecurity for some technical notes on security.
10.1. Securing Directories
First of all, UNIX permissions carry no weight with AFS -- therefore they are useless to you. Instead, use Access Control Lists (ACL), which are a far more powerful way of restricting access to parts of a file tree.
That said, when a new directory is created inside $HOME, its ACL defaults to allow listing by any authenticated party on HCoop. Note that ACLs cannot be set on individual files. They inherit the ACL from its parent directory.
If you wish to make a directory within your $HOME completely private so that only you can list, read, and write, do this:
mkdir ~/private fs setacl -clear ~/private <USERNAME> all
Note that -clear removes any previously set ACLs and <USERNAME> all sets full access to the directory's contents to the specified user. Therefore, if you have a directory in $HOME that you wish to make only accessible to you (such as ~/.ssh or ~/documents), use: fs setacl -clear ~/<DIRECTORY> <USERNAME> all.
NOTE: do not apply any ACLs to ~/domtool or ~/public_html, as they may become inaccessible to necessary services such as a webserver.
If you wish to view the ACLs on a specific directory, such as any you have just applied an ACL, use: fs la <DIRECTORY>
10.2. Log-In Security
We use the [http://denyhosts.sourceforge.net/ DenyHosts] package to help prevent user accounts from brute-force attacks. If a user fails to login within several attempts, then the offending originating IP will be blacklisted in order to prevent additional attempts. If the individual attempts to login again, then he will see something similar to the following: ssh_exchange_identification: Connection closed by remote host
The blacklist expires IPs after a predetermined period if time. Typically, most users will not be affected by the blacklisting, but if you are, you will want to contact a sysadmin to remove your IP from the list.
11. WebDAV
WebDAV is accessible at https://dav.hcoop.net/. WebDAV is useful when working on a website using systems that cannot mount an AFS share. For details on how to setup WebDAV, take a look at http://research.cs.berkeley.edu/doc/dav/
Note that you can only use WebDAV on directories that have system:anyuser rl as part of its ACL. You'll be able to write even if system:anyuser does not. See Securing Directories on this page for additional details on directory ACLs.