# Vault 7: Projects

This publication series is about specific projects related to the Vault 7 main publication.

### Cherry Blossom

# CherryBomb -- CherryBlossom - CherryTree Upgrade Test Procedures (CDRL-14b)

8 August, 2012

- 1
- 2
…
- 4
- 5
- 6
- 7
- 8
…
- 12
- 13

UNCLASSIFIED
Cherry Bomb Program Cherry Blossom Cherry Tree Upgrade Test Procedures
2 Production Server Installation and Upgrade Tests
This section describes tests that must be run after an installation/upgrade is performed on
the production servers.
In most cases, the tests should be run sequentially (starting with test 2.1) after the backend
servers (cb-cc master, cb-cc slave, cb-vpn master, cb-vpn slave) have been upgraded.
NOTE: that for more major upgrades (e.g., OS change), it may be desirable to have an
easy “fallback” position, which typically means the slave server is not immediately
upgraded, but kept at the current version so it could easily be switched to the master. In this
case, tests that pertain to the master (excluding failover tests) should be run first. If all of
these tests pass, then the slave can be upgraded, and tests pertaining to the slave and
failover should then be run.
These tests require one contractor personnel logged on to a control terminal.
NOTE: it is desirable to perform all CherryWeb actions (e.g., planning and assigning
Missions) as a “Test” user (as in section 2.6) to avoid potential clutter of Missions/etc. See
the Cherry Blossom User’s Guide for instructions on creating a Test user.
2.1 Reboot “master cb-cc server” Test
Description: Tests that the cb-cc master server can be rebooted and that on power-
up, proper services are running, and the firewall and routing rules for each PoP are
properly configured.
Setup: From a control terminal, open an ssh console (using PuTTy) to the master
cb-cc server as root (consult “CB Installation Guide” for IP address and root linux
user credentials). Dump the iptables rules to a file (/sbin/iptables –L –n >
~/iptables_before_reboot.out), and dump the routing entries to a file (/sbin/route >
~/routes_before_reboot.out). Gracefully reboot the system (/sbin/reboot).
Run: Verify that the sponsor SNMP monitoring system is reporting the cb-cc master
server down. Once the server is back online, verify that the sponsor SNMP
monitoring system is reporting the cb-cc master server up. Dump the iptables rules
(/sbin/iptables –L –n > ~/iptables_after_reboot.out) and the routing entries
(/sbin/route > ~/routes_after_reboot.out) and compare to the respective
*_before_reboot files. Verify that the server role is “master” by running the
/usr/local/bin/check_cb_role script. Verify mysql by running the
/usr/local/bin/check_cb_mysql script (should report “master”, mysql up with no
errors). Verify CherryTree by running the /usr/local/bin/check_cherrytree.sh script
(should report “CherryTree OK”). Verify CherryWeb by running the
/usr/local/bin/check_cherryweb.sh script (should report “CherryWeb OK”). Verify no
errors were reported to the log files during startup (visually inspect
/var/log/cherrytree/CherryTree.log,
UNCLASSIFIED
6

- 1
- 2
…
- 4
- 5
- 6
- 7
- 8
…
- 12
- 13