Skip to content

Uninstall a facility

This page removes one facility from a host and from the database server: its records, its database account, its settings, its server, its release pointer and its web address. One command does all of it, reports what it found before it touches anything, and asks you to type the facility's name back.

Use it for a facility that should not exist — a rehearsal, a test, or a name typed wrong. A facility whose people have simply stopped using it is a different matter, and this is the wrong page for it: their records are usually wanted for years afterwards, and all such a facility needs is for its server to be stopped.

What this destroys. A facility's records are its researchers, its stocks, its tanks and its own users. This drops the database holding them, and the _bak database beside it holding what they were before the facility was last upgraded. Nothing is dumped first and nothing is kept anywhere. Take a dump of whatever you might want before you run it.

Prerequisites

  • The release is on this host, from Install it on a host. The command travels inside a release, like every other command a host runs.
  • This host has mysql, from Prepare the hosts. The databases are dropped from here.
  • The admin db user name and the admin db password — the account on the database server that may drop databases and the accounts that use them. You are asked for both when you run the command. They are used and kept nowhere.

What happens, in order

Everything found is printed before anything is removed, so the list you confirm is the thing that goes.

  1. The host is surveyed: the facility's settings file, its web address, its port, whether its server is running and enabled, which release it is pointed at, and whether it is closed to its people right now.
  2. The database server is surveyed, as the admin db user: how many tables and roughly how many rows its database and the _bak database beside it hold, and whether its account exists. A mistyped admin db password stops the command here, with nothing removed.
  3. You type the facility's name to confirm. Anything else stops the command.
  4. Its web address stops being served, first, so that nobody reaches a facility whose records are on their way out.
  5. Its server is stopped and disabled, so it does not come back after a reboot.
  6. Its database and the _bak database are dropped, and then its account, which can afterwards log in nowhere.
  7. Its settings file and its release pointer are removed — last, because while its settings are there the facility is still described, and a database that would not drop is something a person can still look into.
  8. What is left is checked. Anything still there is named, and the command fails rather than reporting a removal it did not finish.

Uninstalling

sudo /srv/zfm/releases/<version>/deploy/uninstall-facility.sh <facility>

Two options, neither usually wanted:
--database <name> the facility's database, for the case where this host no longer states it. Otherwise the facility's own settings say, and failing that the name is its own with zf_ in front and its dashes turned into underscores
--yes remove it without the confirmation. The facility's name on the command line still has to be right

Am I ready to move on?

The command's own last step reports what is left, and fails if anything is. Ask the host and the database server once more, independently of the command that did the removing:

sudo /srv/zfm/releases/<version>/deploy/check-facilities.sh \
  --release /srv/zfm/releases/<version>

The facility you removed should not be listed, and every other facility on the host should still be up, yes, read, ok and reached — removing one facility touches nothing that belongs to another.

What it leaves alone

  • The facility's DNS record, which is not on this host. A name still pointing here will reach the host and be answered by no facility.
  • Any dump of the facility that lives elsewhere. This is what you restore from if the removal turns out to have been a mistake, and the reason to take one first.
  • What its server wrote to this host's journal, which ages out on the host's own schedule.