Mailman

Why

Creating mailman accounts is a regular occurrence which we decided we could automate via sending ssh commands to the mailman server.

How

We talk directly to mailman via commands executed on a linux server over ssh.  There is no development or test environment.  This service is on the chopping block eventually.

Authentication

Authentication is done via ssh keys.  Properties contain information about where the key is, the endpoint, the account name, etc...  The ssh key is installed on the ServiceNow mid server which is used when connecting to the mailman server.

Loading of existing mailman accounts

A scheduled workflow called Get mailman lists executes every morning at 4 to build a local list of mailman accounts.  This is done so we can check on the client side if an account already exists.  There isn't a good real-time way of doing this against mailman.  There is also a check in the provisioning workflow, but this is a better customer experience. 

Automated Provisioning

The RITM_YALE_Mailman contains all of the provisioning logic.  This is executed when someone makes a mailman request.  I'm not going to document the whole thing here, but basically this is done via executing a series of shell commands against the mailman server.

Troubleshooting

If the mid server goes down and there are requests, they may stall.  Here's how to get them back if the mid server goes down.

• Check for active requests by going to this link.
• For each active one
  • Open the item
  • Click 'Workflow Context'
  • Click 'Delete' 
  • Go back to the item and set the approval to 'Requested', this will start a new workflow instance
  • The workflow should re-execute
• You can delete the workflow contexts via a background script, but only restart a handful at a time to not overwhelm the mailman server