Shutting Down Service

VPS

When someone cancels, they must be authorized to do so. The request must come from the owner or an admin contact. If not, email the owner to confirm.

Once you have an authorized request from an authorized contact, setup the server for shutdown on the day before the next bill is due- use the "cancel" link adjacent to their system in mgmt. Assuming the cancel date is at least 1 day in the future, the customer will receive shutdown notices at: 10 5 2 1 days before shutdown, as well as the day of shutdown ("Shutown Today"). If they are paying via paypal subscription, you should email the billing handler (sales@johncompanies.com) to cancel their paypal subscription to prevent future/further payments. If they are paying via cc or paypal billing agreement, as long as we shut their system down before the next bill date, their billing will cease- no more service charges on the ledger = no more payments taken from payment sources on file. It's also possible to cancel the sub associated with their account or set the next bill date into the future, but this is only recommended if there is an exception where their shutdown date is after the next billing date.

In response to the authorized cancellation request, we send them the paste for "cancel". You will need to edit it to reflect,

1. any domains we may be hosting for them (listdomains <CID>), if they have none remove the line.
2. if they are not paying via pp sub, remove the line referring to a cancelled payment and email confirmation (their credit card or paypal billing agreement will simply stop billing).

Once you receive the "Shutdown Today" email or if you see their shutdown date has come (seen in green on the mgmt main/login screen) or if they reply at any point saying you can shut down their server now, you may proceed with actually stopping their server.

Linux:

1. cancelve <VEID>
2. you will be reminded to remove domains (rmdomains <CID>) (if any domains are listed, must also be removed from named.conf) NOTE- only remove them if the customer if after shutting down his CT he will no longer have any services with JC
3. you will be reminded to check for firewall rules on the firewall machine: g <ip>, ipfw del <rule id> <rule id> (NOTE: make sure to check that only 1 IP is defined by each rule you’re going to delete)
4. you will be prompted to remove backups, if any
5. you will be reminded to ptr(s), if any: ptr <ip>
6. use the "stop" link in mgmt to set him as down/done.
7. if his pp subscription is still active- take action to get that cancelled (email billing person at JC or tell customer to cancel it)

FreeBSD:

Automated method:
1. g <customerID>
2. canceljail <hostname>
3. you will be reminded to remove domains (rmdomains CID) (if any domains are listed, must also be removed from named.conf: vi ../named.conf; rr)
NOTE- only remove them if the customer if after shutting down his jail he will no longer have any services with JC
4. you will be reminded to check for firewall rules on the firewall machine: g <ip>, ipfw del <rule id> <rule id> (NOTE: make sure to check that only 1 IP is defined by each rule you’re going to delete)
5. you will be prompted to remove backups, if any
6. you will be reminded to ptr(s), if any: ptr <ip> on ns1c
7. use the "stop" link in mgmt to set him as down/done.
8. if their pp subscription is still active- take action to get that cancelled (email payments@johncompanies.com)

Manual method:
1. g <customerID>
2. jailkill <hostname>
3. unmount /mnt/dataX/1.1.1.1-col0XXXX
On >=6.x: unmount /mnt/dataX/1.1.1.1-col0XXXX/dev
4. On 4.x: vnconfig –u /dev/vnN
On >=7.x: mdconfig –d –u N
On 6.x: gconcat volume:

gconcat list /dev/concat/vX-vY

gconcat stop /dev/concat/vX-vY

gconcat clear /dev/gvinum/vX /dev/gvinum/vX

gvinum single volume:

cleargv 12 (if you want to clear /dev/gvinum/v12)

5. rename vn/md file (include date!), ex: mv /mnt/data1/1.2.3.4-col00241 /mnt/data1/old-col00241-vnfile-cxld-20041220
6. edit quad, comment out jail config entries and note, ex: # cancelled col00241
7. run buildsafe (copies changes made to quad into safe file)
8. check backups, gb <customerID>, if any listed edit backup config (vb) and remove backups from backup1 (or run mvbackups if moving to another server)
9. remove the mountpoint dir: rm –fr /mnt/data1/1.2.3.4-col00241-DIR
10. use the "stop" link in mgmt to set him as down/done.
11. IF no longer going to be a customer, remove zones from ns1c: rmdomains col00241 (if any domains are listed, must also be removed from named.conf and the nameserver should be HUP'd: vi ../named.conf; rr)
12. remove any firewall rules: g <ip>, ipfw del <rule id> <rule id> (NOTE: make sure to check that only 1 IP is defined by each rule you’re going to delete)
13. remove ptr(s), if any: ptr <ip> on ns1c

Dedicated Server

When a dedicated customer shuts down service, we use the cancel date in management as the reminder date to shut the server off. When the "SHUTDOWN TODAY" email is received, the server should be powered down by NOC staff on that day (unless prior arrangements have been made to keep the server up or down for another reason). Also, billing should be stopped on that date to avoid future billing. You may remove the next bill date, or delete the sub to stop billing.

The server should remain in cancelled but not stopped status until the server is physically pulled from the DC. The reason for this is the cancelled status is a reminder that we need to pull the hardware out of the DC.

After the hardware is pulled the following steps should be taken:

• stop the system in management (this will mark the customer as cancelled if this was the last active server)

• remove the description label for the switch port:

Assuming they're on port 21 on switch p23:

en
conf t
interface fa0/21
no description
exit
write memory

If they also had an RMM/DRAC repeat the process for the other port. Running a show run should show you which ports the customer is labeled for.

• destroy the nfs data mount and data, if applicable:

umount /data/customers/col00xxx
rmdir /data/customers/col00xxx
rm /data/customers/col00xxx-file
vi /etc/exports (remove entry)
vi  /etc/nfs_backup_mounts.sh (remove entries - 2)

If the umount fails, restart the nfsd:

/etc/init.d/nfs-kernel-server restart

• remove DNS entries:

rmdomains col00xxx
vi /etc/namedb/named.conf (remove all domains for customer)

See if they have a reverse/PTR setup: host x.x.x.x If so,

ptr x.x.x.x

And set back to default

• remove the server from the Cabinetmap