Getting Finished: Preparing to leave

Contacting us

As now, if you need to reach us after you leave you can do so at help@csail.mit.edu. You should let us know what your CSAIL username was (and if relevant who your advisor and/or research group were).

INQUIR

When you leave, you normally lose access to your CSAIL Kerberos account – and with it, your ability to access password-protected CSAIL web services.

Before you leave, you should make sure you’ve connected a GitHub or Google account with your INQUIR account, so you have another way to authenticate to INQUIR and change things like your phone number, location, and PGP key, but most importantly your email forwarding.

(You can also connect an MIT account to your INQUIR account, but since most people leaving CSAIL are also leaving MIT and will lose their MIT Kerberos accounts, that’s less likely to be useful.)

To connect a GitHub or Google account, log into WebINQUIR in the normal way (using your existing CSAIL account, and providing your CSAIL Kerberos password), and choose “Link a non-CSAIL account” from the menu (at the bottom of the first group of links).

Once you’ve done that, you will be able to use the non-CSAIL account to log into INQUIR and “View and edit your personal information”.

Email

Email forwarding

If your email is forwarded elsewhere, you can expect that forwarding to continue after you leave. Email forwarding can be complex, though, so you should make sure you understand exactly how your mail is reaching the place where you actually read it.

(If your CSAIL INQUIR entry says your mail is forwarded to your Gmail account, and that’s where you read it, for instance, then your situation is pretty simple. But if your CSAIL INQUIR entry says your mail is delivered to your @csail.mit.edu IMAP mailbox, and on your CSAIL IMAP account you have filtering set up such that your mail is forwarded to your @mit.edu address, and that address forwards to your Gmail address, then forwarding will be broken when you leave MIT and lose your @mit.edu address.)

If you’ve linked a GitHub or Google account to your INQUIR entry, you’ll be able to change forwarding of your CSAIL email address via INQUIR in the future.

IMAP server filter rules

If INQUIR shows your email forwarding as going to _yourusername_`@csail.mit.edu`, then your mail is being delivered to our IMAP server (although you may have filter rules defined that forward or copy it elsewhere). If you have an IMAP account and know your IMAP password, you can fiew and edit your filter rules at https://webmail.csail.mit.edu/horde/ingo/basic.php?page=filters.

CSAIL IMAP accounts

If your email is delivered to our IMAP server and you read it there (either via a dedicated email application like Thunderbird or Mac Mail, or via our webmail server here), then you have a CSAIL IMAP email account, with its own password distinct from your Kerberos account.

(It’s also possible to have an IMAP account, but have filter rules configured so that all your mail is forwarded elsewhere. If that’s your situation, switching to INQUIR-based forwarding before you leave might make updating things in the future simpler, and takes one step and one possible source of failure out of your forwarding chain.)

At present, CSAIL IMAP accounts typically stay active when people graduate and leave CSAIL, so under normal circumstances you’ll still be able to authenticate to our mail servers and read and send mail through them after you leave. However:

• This policy might change in the future,
• If your IMAP account causes problems (e.g. if your password leaks and spammers start using it, or if there’s a forwarding loop that causes problems), we may need to disable it, and may not have another way of reaching you to let you know what’s going on, and
• You may find it more reliable and more convenient to forward your CSAIL mail directly to wherever you normally read mail, rather than remembering to check it on our server from time to time.

So you might want to consider forwarding it elsewhere.

Closing/disabling your CSAIL email address

If you’ve never given out your CSAIL email address, or if you have but all your correspondents (and mailing lists) now reach you at another address, or if it’s been years since you’ve used your CSAIL address and now it just gets spam, you may want us to deactivate it for you. You can send mail to help@csail.mit.edu to initiate that process. (We’ll obviously need some sort of proof of identity, which we can work out after you contact us.)

Mailing lists you manage

When you lose your CSAIL (login/Kerberos) account, you will no longer be able to create new CSAIL mailing lists, but any mailing lists you’ve already created continue to exist and (since mailing-list moderator and administrator passwords are completely independent of our account system), you’ll be able to continue to administer any mailing lists you administer now (although getting help from TIG to reset any passwords you forget may be more complicated).

That said, there are some things you should do with any lists you manage before you leave:

• If possible, it’s a good idea to make sure any mailing lists you manage that relate to your research here at CSAIL and/or to any remaining CSAIL members – i.e., lists that anybody at CSAIL will continue to care about – have somebody at CSAIL managing them (perhaps with your help). This is as simple as giving one of your colleagues who’s not leaving yet the list admin password and adding them to the “owner” field in the list config. That gives us (TIG) a local contact in case we need to ask questions about the list, and gives listmembers at CSAIL somebody to go to if they’re having problems.
• Make sure your list has a meaningful description phrase and info paragraphs, so people can figure out what it’s for and whom it serves. In particular, you should make sure it’s clear which group(s) at CSAIL (if any) the list is for, so if TIG can’t reach any of the list owners we know who to ask about the list. If your list is not for a community of current CSAIL users, it’s still useful for TIG to have some idea who and what the list is for.
• Make sure your address(es?) in the owner and/or moderator fields point someplace you’ll regularly check! (This can be your CSAIL address if you’ll continue to read it regularly, but it might be useful to add another address.)
• For any lists that aren’t needed any more (for any reason), please send mail to help@csail.mit.edu and let us know to delete them. Unmanaged unmaintained lists are a spam and security risk.
• Make sure you know the list manager passwords for any lists you haven’t already passed on to others (and aren’t asking us to delete).

If you need any help with this, contact help@csail.mit.edu. For instance, we can generate a list of all the mailing lists you’re listed as an owner or moderator for, and/or any mailing lists you’ve created.

Mailing lists you’re on

A few CSAIL mailing lists (like csail-all and grads or postdocs) only allow current CSAIL members to be on them; you’ll be automatically removed from those when your CSAIL appointment ends. Other CSAIL mailing lists, like seminars and cyclists, you’re welcome to stay on after you leave (but you might want to take yourself off of). For more details, see our mailing-list documentation, especially our list of Popular Lab Mailing Lists.

You may wish to unsubscribe from some of your mailing lists, and/or change your subscription address. If you need help with that, or if you’d like to find out all the CSAIL mailing lists a given email address of yours is on, send mail to help@csail.mit.edu.

Shared and group computing resources

OpenStack

You should not assume that OpenStack instances you’ve launched will stay up after you leave. If other people in your research group (or the general public, for that matter!) depend on instances you’ve launched, you should probably snapshot them and have another colleague in your research group (and in the same OpenStack “project”) re-launch them, so that they’re associated in OpenStack with the account of a current CSAIL member. If that’s a hassle, please send email to help@csail.mit.edu with the instance name (or preferably UUID) the project name and the username of the new owner and we can help get it sorted out.

Note instances in your personal “sandbox” project cannot be preserved in this way.

We may make some effort to find out whether others in your OpenStack project care about your instances before terminating it after you’ve left, but we make no promises. Anything in your “usersandbox” project is definitely likely to get terminated.

Research-group servers

If you manage any of your research-group’s servers, services, or software, you should make sure one or more of your remaining colleagues knows what you’ve been responsible for and is ready to take over for you. (Since research-group servers can be configured in all sorts of ways, what this entails is necessarily pretty open-ended, but it might involve things like managing who else is allowed to sudo on a machine, applying patches to your custom software, restarting a long-running server that occasionally runs out of memory, managing UROPs’ access to your code repository as they come and go, and so on.)

Other shared computing

Given the range and flexibility of the CSAIL computing environment, it’s hard to give an exhaustive list, but here are a few of the sort of things you might want to clean up before leaving:

• Slurm jobs that won’t have completed before you leave, or that are queued to start after you leave
• Cron jobs
• Screen or tmux sessions
• Other long-running processes (e.g. a webserver you manually started, etc.)

Hosts on the CSAIL network

When you’re about to leave is a good time to go through the hosts you’ve registered in DHreg and WebDNS and clean up any old hosts you’ve registered that are no longer up. (You can get a list of your WebDNS registrations via the “Show all my registrations” button; anything you delete from DHreg should also get deleted from WebDNS. Unfortunately there’s no corresponding feature for WebDNS, but if you send mail to help@csail.mit.edu we can give you a list of all the remaining WebDNS entries you’ve created.)

Of course, it’s normal that some hosts you’ve registered may need to stay up, if they’re servers or devices other people in your research group depend on. But going over the list of hosts you’ve registered in WebDNS (which you need to ask us for) and DHreg (which you can get for yourself) is also a good way to remind yourself of any hosts you need to make sure somebody is taking over responsibility for.

Web pages and websites

You won’t be able to make changes after you leave

Since we (TIG) don’t delete data from AFS (including home directories and research-group space), any websites you’ve created at CSAIL will not immediately go down when you leave. However, when your CSAIL Kerberos password stops working, you no longer have a way to make changes to files on AFS, including websites.

Given that, you might want to preemptively redirect your site (especially if it’s more tied to you individually than to your research group at CSAIL, like a CV or a portfolio of your work) to some outside website that you control. Alternatively, you might want to add content saying when you’re leaving CSAIL and giving visitors pointers to new ways to reach you or to other websites that are likely to be more up to date, and go over the language and make sure it will still sound sensible in five or ten years.

For sites that your research colleagues at CSAIL care about keeping up, you need to make sure your colleagues know how to update content as needed and do maintenance and upgrades on the sites, and have appropriate privileges to do so.

Static vs. dynamic sites

Purely static sites (dependent only on unmodified serving of static files like HTML, CSS, and image files) should continue to work indefinitely (at least until standards have changed enough that browsers stop supporting the current file formats).

Dynamic sites (including any site that generates content on the fly or pulls it from a database) are much more demanding to keep up long-term, and absolutely require somebody still at CSAIL (or with an active CSAIL login account and sufficient time and attention to dedicate) to perform ongoing maintenance and upgrades as needed. Over a longer timescale, this is likely to be much more demanding than you’ve experienced here; keeping a dynamic site running across OS upgrades, language and development framework updates, and content-management system upgrades, and in the face of ongoing security threads and new exploits, is a lot easier for a year or two than it is for a decade or two.

(This is one of many reasons we recommend static websites.)

If you leave a dynamic site behind without making arrangements with your colleagues to keep it secure, up to date, and upgraded as needed to keep up with our environment, we (TIG) won’t immediately take it down, but we won’t hesitate to disable it without warning if we notice problems with it.

Also, we anticipate making significant architectural changes to how we host dynamic websites at CSAIL in the medium-term future, so there’s a good chance that dynamic or active-content websites that don’t have local maintainers will stop working altogether at some point.

(You might want to drop README’s or similar into the top level of your site’s AFS directory, or alongside it, to point your colleagues at documentation and to point us at your current contact information and at the people within CSAILresponsible for ongoing maintenance. Be careful not to put any security-relevant information into a file that’s served on the web, though! You wouldn’t, for instance, want to say that your site is served in version X.Y of system Foo, because that means that down the road when vulnerabilities are discovered in that version, attackers could just search Google to find your vulnerable site.)

Contacting us down the road

In a pinch, if you leave your website up here and later decide it’s not worth keeping up in it’s archived form (and you don’t have then-current CSAIL colleages who are maintaining it for you), we may be able to drop a redirect in place to point visitors to a new URL elsewhere. You can send us mail at help@csail.mit.edu to do that; please let us know what your CSAIL username was (if you remember) and exactly where your website is by URL. (We’ll need to confirm that it’s actually your website.)

We will not be able to make minor changes for you; all we can do is redirect the whole site. (We may be able to help you with permission changes you forgot to make before leaving so your colleagues can update the site.)

Home directories

You’ll lose access to your home directory

Your AFS home directory will not go away when you leave, but when your INQUIR/Kerberos account expires, you’ll no longer be able to log in to get to it. (Your remaining colleagues, and our webservers, will still have whatever access to subdirectories of your home directory they had while you were here.) You should copy anything you want to keep elsewhere.

You may want to clean it up before leaving

Other than your CSAIL personal website (and any research data or code you were keeping in your home directory that your colleagues might still need access to), there’s probably nothing that needs to stay in your home directory after you leave, so it would be nice if you cleaned it up before departure, so we aren’t backing up stuff like your Firefox cache and a bunch of old software builds in perpetuity.

If you do clean up your home directory, you may find that much of the space used is in dot-directories like .cache. If you’re in the top level of your home directory (as after typing cd), the command

    du -ha --exclude .snapshot | sort -h

will show you (at the bottom of the output) where the most space is being taken up. (We exclude .snapshot because it’s a daily read-only snapshot of your home directory.)

That command may take a very long time; fs listquota . is a much quicker command that won’t tell you where the space is being used, but will tell you the overall size of your home directory.

Security implications

You might want to make a particular point of removing anything from your home directory that has any security sensitivity before you leave, such as SSH or PGP keys or any file that might have a password in it (such as email configuration or web-browser caches).

Getting rid of your home directory altogether

This is not normal procedure, but if you know for sure that none of your CSAIL colleagues need anything from your CSAIL home directory, and you don’t have personal web pages you want to keep up, you can let us know (and prove your identity to us, if you’ve left already), and we can delete it for you.

Research data and collaboration

As for websites you’ve hosted at CSAIL, make sure your remaining colleagues know where any research data or code they need is, and that they have appropriate privileges to access it.

Especially if you reorganize anything to prepare for your departure, make sure everything’s tested in its final resting place (e.g. if you move stuff from your home directory to your group’s AFS space preparatory to leaving, make sure your colleagues can actually use it where you’ve put it).

Please delete any temporary/scratch junk you no longer need – both in AFS and in NFS – before you leave, so we’re not backing up the 150GB from that aborted build you realized you did in the wrong directory for the foreseeable future. (You might want to let your colleagues know what you plan to delete.)

Keeping your Kerberos (login) account

Sometimes, CSAIL members continue to actively collaborate on research with CSAIL colleagues after they leave, and sometimes the research groups they’re continuing to work with would like to continue to sponsor their accounts after they leave. (In this case the account type should be changed, say from “Graduate Student” to “Collaborating Researcher”, but the username, password, and home directory stay the same.) That decision is up to your listed supervisor, who is responsible for your account; they can renew your account if they choose to. (If you need to switch supervisors, e.g. you were in the Baking Robotics Group, but your ongoing collaboration is going to be with the Confectionary Printing Group, you should ask your new supervisor to contact us to let us know they want to take over responsibility for your account from your present supervisor when you leave.)