Revision control is used to manage and track changes to configurations. The repositories are hosted externally from the main service hosts.
Network access (over HTTPS or SSH) to repositories requires whitelisting in an IPSET - so servers or home IPs will need to be included in the firewall rules to run git commands.
(for access to https:<nowiki>//</nowiki>config.tombstones.org.uk:23000/ from 4.3.2.1 = firewall-cmd –ipset=tombstones-admins –add-entry=4.3.2.1, no need to make it persistent)
The base revision control system uses the git protocol, communicating with Gitea which wraps hosting, auth and organisation management around the base project.
Each project used in this solution is well documented (see the references section), only basic process will be documented here as it pertains specifically to our service.
Gitea is a self-hosted 'github'esque service, meaning we are running "our own Github" - see information below.
Once logged into the repo, add a (public) key so that pushes/pulls (content to/from the repo) can take place over SSH:
[ add image here]
Two basic scenarios are:
<HTML><ol start="2"></HTML> <HTML><li></HTML>get git installed. Use git –version to check the client is working.<HTML></li></HTML><HTML></ol></HTML>
<HTML><ol start="3"></HTML> <HTML><li></HTML>create a new directory, initialise git in there, e.g.:<HTML></li></HTML><HTML></ol></HTML>
mkdir myproject cd myproject git init
<HTML><ol start="4"></HTML> <HTML><li></HTML>relate the repo to this directory, using the URL:<HTML></li></HTML><HTML></ol></HTML>
git remote add origin ssh://git@config.tombstones.org.uk:22122/dave/newRepo.git
Note: setting the origin is a one-off job - one done, it needn't be changed from this point on.
<HTML><ol start="5"></HTML> <HTML><li></HTML>create a file that will be version-controlled, e.g.: vi testfile.ini (and add content)<HTML></li></HTML><HTML></ol></HTML>
<HTML><ol start="6"></HTML> <HTML><li></HTML>check which files git knows exists: git status (this should show that testfile.ini is "untracked")<HTML></li></HTML><HTML></ol></HTML>
<HTML><ol start="7"></HTML> <HTML><li></HTML>Instruct git to add this file to the commit so that changes are tracked. "commit" means "record to the repo". This can be done on a file-by-file basis, or the whole directory can be added:<HTML></li></HTML><HTML></ol></HTML>
git add testfile.ini = adds just this file
git add . = adds all contents of this directory.
<HTML><ol start="8"></HTML> <HTML><li></HTML>Check that git knows about this file:<HTML></li></HTML><HTML></ol></HTML>
git status = should receive a message that git is aware, but the contents have not been committed yet (uploaded to the repo).
<HTML><ol start="9"></HTML> <HTML><li></HTML>now create a commit (a snapshot of these changes, read for a "upload" or "push"<HTML></li></HTML><HTML></ol></HTML>
git commit -a "Comment explaining why this commit was made"
<HTML><ol start="10"></HTML> <HTML><li></HTML>Check progress so far: git status = should show uncommitted change to be pushed.<HTML></li></HTML><HTML></ol></HTML>
<HTML><ol start="11"></HTML> <HTML><li></HTML>Now to do a "push" to upload committed content to the repo: git push<HTML></li></HTML><HTML></ol></HTML>
<HTML><ol start="12"></HTML> <HTML><li></HTML>check progress: git status = should show everything's up to date.<HTML></li></HTML><HTML></ol></HTML>
When participating with work in an existing repo, make a note of the URL to that repo (should be mentioned on the dashboard). Note: keys will need to be sorted first to facilitate file transfer.
Also note: it is safer to branch from master then submit a pull request to have new work reviewed then merged.
<HTML><ol start="2"></HTML> <HTML><li></HTML>git clone ssh://some_url - provide the URL to the repo (use the SSH protocol, not HTTPS). The URL<HTML></li></HTML><HTML></ol></HTML>
<HTML><ol start="3"></HTML> <HTML><li></HTML>git status - check everything is okay (all up to date)<HTML></li></HTML><HTML></ol></HTML>
<HTML><ol start="4"></HTML> <HTML><li></HTML>Work on the files! Either add new files, or modify content of existing ones.<HTML></li></HTML><HTML></ol></HTML>
<HTML><ol start="5"></HTML> <HTML><li></HTML>git status - will show red files:<HTML></li></HTML><HTML></ol></HTML>
<HTML><ol start="6"></HTML> <HTML><li></HTML>git add . - includes this directory (and all contents) into the commit.<HTML></li></HTML><HTML></ol></HTML>
<HTML><ol start="7"></HTML> <HTML><li></HTML>git status - files should now show as green, "changes to be committed"<HTML></li></HTML><HTML></ol></HTML>
<HTML><ol start="8"></HTML> <HTML><li></HTML>git commit -m "Committing changes from the clone" - add a suitable comment (which is displayed against changed files on the dashboard)<HTML></li></HTML><HTML></ol></HTML>
<HTML><ol start="9"></HTML> <HTML><li></HTML>git push - update repo with committed changes.<HTML></li></HTML><HTML></ol></HTML>
<HTML><ol start="10"></HTML> <HTML><li></HTML>git status - should reflect that everything is good.<HTML></li></HTML><HTML></ol></HTML>
Gitea is deployed from the official Docker image targeting tag latest, using a local datastore attached to ensure persistent data between restarts (so any container restarts won't lose repo information).
The service starts from systemd in which the service file executes a docker pull of the latest images at startup. A custom docker network is setup for the service, so systemd defines the container's static IP within the custom docker network.
By default all repositories are forced to be private.
Our setup details are below.
The docker configuration can be viewed using the standard docker tools e.g. docker inspect <container> for additional details
Grant the user and server IP firewall access to the service by adding them to the ipset: ipset add <ipset name> <ip address>
Post the initial login (and password reset) grant the user the appropriate organization memberships
Each server has their own user account that has the username formatted as <server shortname>_s these accounts are restricted. This provides us flexibility in allowing servers to access private repositories should the need arise.
Do this before starting work on your fork to pickup recent changes from the upstream project
This just represents a list of things that have been recovered for Gitea.
The following repos have been created and their contents populated:
Work2do (Dave's notes):
1. all servers have a basic Postfix config to forward mail OFF the server; refactor Hal & Albert's configs to set up a basic mail forwarding system that does the following:
2. shift camp2postfix into the 10_email.pp file for puppet-common; work on that file to ensure the basic stuff is setup
3. test this on albert. Should also work on tupper, too.
4. Add further configs for Xavier to act as a mail recipient also; build on top of current postfix setup to extend full mail server capability.