Version Control is performed using git with a gitolite installation on the Salt Master on its own separate EBS partition at /mnt/snapshot/. Standard ssh-based access controls are used. This was done to make snapshots smaller and more reliable.
For access to a repository, please supply the CommIT technical team with your preferred SSH key. This public key will be imported to gitolite by placing the key in
/home/git/.gitolite/keydir on the Salt Master(126.96.36.199).
On the client machine, you may need to add the following to
Finally, verify access works and list the repositories you have access to:
And then get working:
I built it without a gitolite-admin repo because it was much more straightforward to me. We can do gitolite's own configuration versioning in commit-config.
Three things are version controlled and each has its own repo to keep permissions separated:
1) Configuration files (
2) CommIT CPR customization (
3) CommIT IdP/uApprove GUI customization (
Repo configuration is done in /home/git/.gitolite/conf/gitolite.conf. This configuration itself is version-controlled within the commit-config
To add a new user, put their certificate in the
keydir and recompile gitolite:
Most servers and resources within the CommIT deployment architecture are effectively expendable. If a working node fails, replacing it with a new working node using Salt is the first preference and default course of action.
Four pieces of the architecture do require comprehensive backup, though, because they do manage important data:
1) Salt Master
2) gitolite repo (on the Salt Master atm)
3) rsyslogd server's received logs
4) PostgreSQL database
Internet2 built a custom installer for our licensed backup solution, CrashPlan PROe, for us. This does live backup as a daemon running as
backupuser in our environment with the following default paths and invocation.
Default archive location:
Periodic snapshots are taken of instances and of the database by using pg_dump, and these snapshots are then archived in S3 or CrashPlan. Running backups are kept by CrashPlan.
CrashPlan does not chase symlinks.
In order to ensure that no user data is lost and because databases are different animals, separate strategies are used to backup the PostgreSQL database:
- Add an additional replica.
- Ensure that cpruser cannot drop and delete tables and that no entity is using the admin user for anything.
- Use pg_dump to backup the database.
(master on .148 CPR node responsible for backup currently)