After the future removal of the classic playbook editor, your existing classic playbooks will continue to run, However, you will no longer be able to visualize or modify existing classic playbooks.
For details, see:
Set up an external PostgreSQL server
uses a PostgreSQL 11 database. In many installations, the database runs on the same server as . It is possible to put the database on its own server. For more information about configuring and operating a PostgreSQL database, consult the PostgreSQL website and their documentation.
Limited Support for PostgreSQL 12
If your organization requires PostgreSQL 12, can provide limited support. Follow the directions in this topic, substituting PostgreSQL 12.9 for PostgreSQL 11.16.
If you choose to use PostgreSQL 12.9 instead of PostgreSQL 11.16, you must be aware of the following limitations:
- PostgreSQL 12 is only supported for new, unprivileged deployments. Do not upgrade an existing external PostgreSQL 11.16 database to PostgreSQL 12.9.
- PostgreSQL 12 is only supported as an external service. Do not upgrade the embedded PostgreSQL 11 database to PostgreSQL 12.
- You cannot use the following features of Splunk SOAR (On-Premises) if you use PostgreSQL 12:
- Backup and restore. You must use another solution to backup or restore your PostgreSQL 12 database.
- Warm standby
Install and configure PostgreSQL
If you run the PostgreSQL database on its own server, install and configure PostgreSQL before you install Splunk SOAR (On-premises).
These instructions are based on CentOS 7 or Red Hat Enterprise Linux 7. If you choose to to install PostgreSQL on another operating system, consult the documentation on the PostgreSQL website.
- Install one of the operating systems supported by PostgreSQL 11. PostgreSQL 11.16 is recommended, but you may use any release of PostgreSQL 11.x. Configure the operating system according to your organization's requirements. See Supported Platforms on PostgreSQL.org.
- Update the kernel semaphore parameters and refresh the system configuration.
echo "kernel.sem=250 32000 32 5000" >> /etc/sysctl.conf sysctl --system
- Configure your firewall to allow access. For a complete list of ports, see required ports.
- Add any additional yum repositories that you need. Use the tool on the Linux downloads (Red Hat family) page to identify the correct repository for your architecture and operating system combination.
yum install <URL>
- Install the PostgreSQL server.
yum install postgresql11-server-11.16
- Initialize the PostgreSQL database.
/usr/pgsql-11/bin/postgresql-11-setup initdb
- Set PostgreSQL to start when the system starts.
systemctl enable postgresql-11
- Start the PostgreSQL database.
systemctl start postgresql-11
- Change to the postgres user.
su - postgres
- Change to the PostgreSQL data directory.
cd /var/lib/pgsql/11
- Generate the SSL certificate PostgreSQL uses.
openssl req -new -x509 -days 3650 -nodes -text -out server.crt -keyout server.key -subj "/CN=postgres.cluster1"
You can use an SSL certificate purchased from a Certificate Authority instead of generating a self-signed certificate.
- Set the permissions on the server.key file.
chmod og-rwx server.key
- Run a PostgreSQL shell as the
postgres
user.You should already be the postgres user.
psql - Set the postgres user password, if it has not already been set.
ALTER USER postgres PASSWORD '<postgrespassword>';
- Create the pgbouncer user.
CREATE USER pgbouncer PASSWORD '<pgbouncerpassword>';
- Set PostgreSQL to use SSL. Provide the keys and cipher level.
ALTER SYSTEM SET ssl = on; ALTER SYSTEM SET ssl_cert_file = '/var/lib/pgsql/11/server.crt'; ALTER SYSTEM SET ssl_key_file = '/var/lib/pgsql/11/server.key'; ALTER SYSTEM SET ssl_ciphers = 'HIGH:+3DES:!aNULL';
- Exit the PostgreSQL shell by typing CTRL+D.
- Change back to the
root
user.exit - Edit the
pg_hba.conf
file to enable access to the database. must be able to connect as both thepostgres
andpgbouncer
users. In each entry, supply the IP range that will be used by your install or cluster.# TYPE DATABASE USER ADDRESS METHOD local all all peer hostssl all postgres <IP Range>/<XX> md5 hostssl phantom pgbouncer <IP Range>/<XX> md5
- Edit
postgresql.conf
. Set values formax_connections
,work_mem
,shared_buffers
, andlisten_address
.max_connections=2500 work_mem=2796kB shared_buffers=2GB listen_addresses = '*' # what IP address(es) to listen on;
Several factors can influence the amount of memory dedicated to the
work_mem
setting. Larger, high event volume deployments will want significantly more, while smaller, lower volume deployments may use slightly less. The setting above assumes a medium sized deployment with a moderate event volume.For
listen_address
set a value that matches your security requirements. Valid settings are:*
for all addresses, 0.0.0. for all IPv4 addresses::
for all IPv6 addresses- specific addresses you supply.
- Restart the PostgreSQL service.
systemctl restart postgresql-11
Backup a Splunk SOAR (On-premises) database and restore to an external database
To backup a database and restore it on an external database, use the ibackup.pyc tool. See backup and restore overview in Administer .
Create an external PostgreSQL database in AWS RDS
Some deployments, especially those in Amazon Web Services, may want to put the PostgreSQL database on its own host using AWS's Relational Database Service (RDS). These steps can also be used to migrate a standalone instance to an instance using a PostgreSQL database hosted in AWS' RDS.
For more information on building a PostgreSQL database host in RDS, see the Amazon Relational Database Service documentation.
Set the statement_timeout parameter to "0" when creating an external PostgreSQL database in AWS RDS. See the Amazon Working with parameters on your RDS for PostgreSQL DB instance documentation for more information.
Checklist
Number | Task | Description |
---|---|---|
1 | Create a PostgreSQL database in AWS. | Create the external PostgreSQL database with the Relational Database System |
2 | Create the pgbouncer user account. | Create the pgbouncer user for the RDS |
3 | Back up the instance's PostgreSQL database, then restore it to the AWS RDS instance. | Backup a database and restore to an external database |
Create the external PostgreSQL database with the Relational Database System (RDS)
uses a PostgreSQL 11.16 database. In many installations, the database runs on the same server as . If you opt to run the PostgreSQL database on its own Amazon Web Services RDS instance, follow the procedures here. These instructions assume you already have an AWS account and VPCs established for your organization's resources.
These instructions use PostgreSQL version 11.16. You may use any PostgreSQL 11.x release. If you do use a different release, you must to use matching parameters for your release where PostgreSQL 11.16 is specified in these instructions.
- From your EC2 dashboard, click Services in the menu bar, and under Database choose RDS.
- Click Create database.
- Select Standard Create.
- Under Engine options, select PostgreSQL.
- For Version, select 11.16 from the menu.
- For Templates, select either Production for production environments or Dev/Test for development/testing or Proof of Value environments.
- Under Settings, type a name for your DB instance identifier. Make sure that the name is unique across all DB instances owned by your AWS account.
- Under Credential Settings:
- Master username: postgres
- Make sure the Auto generate a password checkbox is not selected.
- Type and confirm the Master password in the fields provided. Record this password. You will need it later.
- Under DB instance size, select the radio button that matches your organization's needs.
Warning: Instances below db.t2.large may deplete their available connections before installation of Splunk SOAR (On-premises) is complete.
- Under Storage, select a Storage type based on your organization's needs.
- For Allocated storage, set a number of GiB that matches your organization's needs.
Databases with less than 500 gigabytes of storage are not supported for production use.
- Select the Enable storage autoscaling check box.
- Set Maximum storage threshold to 1000 (GiB).
- For Allocated storage, set a number of GiB that matches your organization's needs.
- Under Availability & durability, select the Do not create a standby instance radio button.
- Under Connectivity, select the same VPC as you used for your instance.
- Under the Additional connectivity configuration section:
- Select the correct Subnet group. The available groups depend on your VPC selection.
- Under Publicly accessible, select the No radio button.
- Under VPC security group, select Choose existing.
- Select the appropriate security group from the menu.
- Click the X icon to remove any unwanted security groups that were added by default.
- Make sure the Database port is set to 5432.
- Under Additional configuration, Database options:
- Type phantom for Initial database name.
- Make sure the DB parameter group is set to default.postgres11.16.
- Under Additional configuration, Backup, leave everything at the defaults.
- Click Create Database.
Create the pgbouncer user for the RDS
interacts with the PostgreSQL database using the pgbouncer user account. This account needs to be created for the database you built in RDS.
- SSH to the operating system of your instance and use the user was installed with. For privileged installs, this will be the root user.
- Create the pgbouncer user. psql --host <DNS name for RDS instance> --port 5432 --username postgres --echo-all --dbname phantom --command "CREATE ROLE pgbouncer WITH PASSWORD '<pgbouncer password>' login;"
- Make the pgbouncer user a superuser. psql --host <DNS name for RDS instance> --port 5432 --username postgres --echo-all --dbname phantom --command "GRANT rds_superuser TO pgbouncer;"
Backup the external PostgreSQL database with the Relational Database System (RDS)
To backup an external PostgreSQL database with the RDS, you can perform the following steps as the root user or a user with sudo permissions for privileged deployments. For unprivileged deployments, you can use the unprivileged user.
You must use identical versions of Splunk SOAR (On-premises) for this procedure. For example, if your PostgreSQL backup is from Splunk SOAR (On-premises) 5.0.1, you must restore it to use with an instance of Splunk SOAR (On-premises) 5.0.1.
- Backup the database.
cd <PHANTOM_HOME>/bin phenv python backup.pyc --all
- Copy the file path that shows the backup file that was created to use in a future step.
All data backed up to <PHANTOM_HOME>/data/phantom_backups/phantom_backup_2017-07-15-20-47-04.126913.tgz
- Edit the
/etc/pgbouncer/pgbouncer.database.ini
(privileged deployments) or<PHANTOM_HOME>/etc/pgbouncer/pgbouncer.database.ini
(unprivileged deployments) file as shown in the following code.host
is the IP address or DNS name of the database server.[databases] phantom = user=pgbouncer password=<pgbouncerpassword> host=<pg server> postgres = user=postgres password=<postgrespassword> host=<pg server> [pgbouncer] server_tls_sslmode = require
Amazon Web Services RDS PostgreSQL databases do not need the
server_tls_sslmode = require
entry. - Stop all services.
<PHANTOM_HOME>/bin/stop_phantom.sh
- Reload pgbouncer. For all deployments, use the following command:
<PHANTOM_HOME>/bin/phsvc restart pgbouncer
- Test the connection to the database server.
Privileged deployments:sudo -u postgres psql -h /tmp -p 6432
Unprivileged deployments:
<PHANTOM_HOME>/bin/phenv psql -h /tmp -p 6432 -d postgres
If connectivity is successful, you will see the following message:
psql (11.16) Type "help" for help. postgres=#
To exit from psql, use
\q
. - Initialize the database to use with .
cd <PHANTOM_HOME>/bin phenv prepare_db --db-exist-ok
- Start all services.
<PHANTOM_HOME>/bin/start_phantom.sh
- Restore the backup using the file name you copied in step 2.
cd <PHANTOM_HOME>/bin phenv python restore.pyc --file <PHANTOM_HOME>/data/phantom_backups/phantom_backup_2017-07-15-20-47-04.126913.tgz
- Connect to the server's web user interface.
Run make_cluster_node.pyc | Set up external file shares using GlusterFS |
This documentation applies to the following versions of Splunk® SOAR (On-premises): 5.3.1, 5.3.2, 5.3.3, 5.3.4, 5.3.5
Feedback submitted, thanks!