Date: Thu, 28 Mar 2024 09:32:29 +0000 (UTC) Message-ID: <879112851.5887.1711618349287@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_5886_145487055.1711618349286" ------=_Part_5886_145487055.1711618349286 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Version Control is performed using git with a gitolite installation on t= he Salt Master on its own separate EBS partition at /mnt/snapshot/. Standar= d ssh-based access controls are used. This was done to make snapshots small= er 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 pl=
acing the key in /home/git/.gitolite/keydir
on the Salt Master=
(54.244.127.183).
sudo su cd /home/git/.gitolite/keydir/ cp /home/ndk/newkey.pub ./ndk.pub chown git:git ndk.pub chmod 400 ndk.pub su - git ./gitolite compile; ./gitolite trigger POST_COMPILE logout logout
On the client machine, you may need to add the following to ~/.ssh=
/config
:
Host 54= .244.127.183 =09User git =09IdentityFile /home/ndk/.ssh/id_dsa.pub
Finally, verify access works and list the repositories you have access t= o:
ssh git= @54.244.127.183
And then get working:
git clo= ne git@54.244.127.183:db-name
I built it without a gitolite-admin repo because it was much more straig= htforward to me. We can do gitolite's own configuration versioning in commi= t-config.
Three things are version controlled and each has its own repo to keep pe= rmissions separated:
1) Configuration files ( commit-config
)
2) CommIT CPR customization ( commit-cpr
)
3) CommIT IdP/uApprove GUI customization ( commit-web-shib
)<=
/p>
phlogio= s:~ ndk$ ssh git@saltmaster X11 forwarding request failed on channel 0 PTY allocation request failed on channel 0 hello ndk, this is git@ip-10-238-42-29 running gitolite3 v3.6-16-g4fefd3f o= n git 1.7.9.5 R W=09commit-config R W=09commit-cpr R W=09commit-web-shib Connection to saltmaster closed.
Repo configuration is done in /home/git/.gitolite/conf/gitolite.conf. Th= is configuration itself is version-controlled within the commit-config
To add a new user, put their certificate in the keydir
and =
recompile gitolite:
cp /hom= e/ndk/.ssh/authorized_keys /home/git/.gitolite/keydir/ndk.pub chown -R git:git /home/git/.gitolite/keydir/ su git cd ~; ./gitolite compile; ./gitolite trigger POST_COMPILE
Most servers and resources within the CommIT deployment architecture are= effectively expendable. If a working node fails, replacing it with a new w= orking 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, Cra=
shPlan PROe, for us. This does live backup as a daemon running as bac=
kupuser
in our environment with the following default paths and invo=
cation.
Important directories:
Installation:
/home/backupuser/crashplan
Logs:
/home/backupuser/crashplan/log
Default archive location:
/home/backupuser/manifest
Start Scripts:
/home/backupuser/crashplan/bin/CrashPlanEngine start|stop
/home/backupuser/crashplan/bin/CrashPlanDesktop
Periodic snapshots are taken of instances and of the database by using p= g_dump, and these snapshots are then archived in S3 or CrashPlan. Running b= ackups are kept by CrashPlan.
CrashPlan does not chase symlinks.
In order to ensure that no user data is lost and because databases are d= ifferent animals, separate strategies are used to backup the PostgreSQL dat= abase:
(master on .148 CPR node responsible for backup currently)