# ThreatQ Notes

## Compilation Notes

### Packer things

We have a specific packer build for the TQ AMI.  It's (mostly) unlike any other we have.

## Setup Steps

### Firstboot

When doing firstboot on our TQ AMI, there are some un-hardenings in place.
TQ expects during firstboot that the root password is a known value, that
apache has the rights to `su` to root using that password, and that
selinux is permissive.

After the GUI panel during firstboot is filled out (setting a new root
password, a mysql root password, and an initial admin account), then we can
undo the un-hardenings.

If you're doing a firstboot as part of restoring a backup from another TQ
system, then please skip this part and come back!

```
gpasswd -d apache sugroup
echo "root:*" | chpasswd -e
systemctl mask cockpit.service
systemctl mask cockpit.socket
shutdown -r now
```

Now hopefully you can enable a salt minion without breaking anything

### Restoring a backup

You have to go through firstboot first, but DO NOT DO the unhardening
above yet!

Take the backup of the old TQ, make it available on the new one.  Also
save the contents of `/etc/threatq/env/app-id.conf` from the old TQ.
It will look like

```
APP_INSTANCE_ID=18112b11-a13a-414b-93e8-b6b87adf27a5
```

Now to do the restore ... docs are at https://helpcenter.threatq.com/index.htm#t=ThreatQ_Platform%2FBackup_and_Restore%2FBackup_and_Restore.htm
but there are couple of things not there.

```
$ sudo -i
# umask 0022
# cd /var/www/api
# php artisan threatq:restore </PATH/TO/BACKUP/FILE>
# php artisan threatq:update-events
# sed -i "s/^APP_INSTANCE_ID=.*/APP_INSTANCE_ID=18112b11-a13a-414b-93e8-b6b87adf27a5/" /etc/threatq/env/app-id.conf
# shutdown -r now
```

Now go back up and look at the un-hardening above and do that.  You probably don't
have to reboot twice.


## Patching Notes

TQ patching is a little different (of course).  You have to be very careful about
how you patch it because TQ provides a whole set of centos RPMs, and centos is trying
very hard to infect our RHEL build with their RPMs.

Always read the TQ upgrade notes at https://helpcenter.threatq.com when you're upgrading
TQ or when you're patching the base OS.  They may change from time to time things
like RPM excludes during updates.

Where TQ may do an explicit exclude of a package during an upgrade, I (Duane) will
versionlock it instead.  And, sometimes, other versionlocks are needed as well.  As
of now I am versionlocking the Java runtime (because TQ packages expect a SPECIFIC patch
level of Java) and the redhat-rpm-config package so that it's not replaced by a centos
package

ALWAYS do a `yum check-update` and make sure everything looks reasonable and that
Centos packages aren't replacing their RHEL equivalents.
