Tanked Server Information

User Tools

Site Tools

You are here: start » Contents of x0blr » infrastructure » Infrastructure: Revision Control
Trace: • Infrastructure: Revision Control
trac.x0blr.com:infrastructure:infrastructure_revision_control

Table of Contents

Infrastructure: Revision Control

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

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]

Basic usage.

Two basic scenarios are:

  1. Creating a new repo to manage your files
  2. Participating in an existing repo to contribute to changes

1. New Repo

  1. Log into the repo, and use the + button to create a new repo. This registers a space in Gitea for files to be versioned, and will also provide a URL to this repo, e.g.: ssh://git@config.tombstones.org.uk:22122/dave/newRepo.git

<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>

2. Collaborating with an existing repo

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.

  1. mkdir folder - probably not needed, as the git clone statement usually creates a subdirectory anyway.

<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>

  • new files will show as "Untracked" and will need git add to include them in the commit.
  • changed files will show as "modified:" - but will still need to be added so they're included in the commit.

<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>

Details

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.

General

Docker

  • container: tombstones-gitea
  • network: tombstones-gitea
  • ip: 172.18.0.16
  • volume: /srv/tombstones/gitea/

Gitea

  • admin: queeg

The docker configuration can be viewed using the standard docker tools e.g. docker inspect <container> for additional details

Accessing

Grant the user and server IP firewall access to the service by adding them to the ipset: ipset add <ipset name> <ip address>

  1. Login as an admin and manually add the user account to the service with a random password (registration is disabled)
  2. Ensure "Require user to change password (recommended)" is ticked and Authentication source is local.
  3. Do not assign any new permissions to the user if prompted this will be done post initial login
  4. Click create account
  5. Untick May Create Organization
  6. Click Update User Account
  7. Provide the temporary details to the user for initial login

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.

Update a fork to upstream

Do this before starting work on your fork to pickup recent changes from the upstream project

  1. Change to your fork dir
  2. Check for upstream git remote -v
  3. Add upstream git remote add upstream <gitrepo>
  4. Config addition git remote -v
  5. Pull down the upstream repo git fetch upstream
  6. Checkout your local master branch git checkout master
  7. Merge the upstream project into you local branch git merge upstream/master
  8. Push the updated to your remote branch git push origin master

References

TODO

  • Look at some SSO solution in general then integrate it into Gitea
  • Investigate the builtin letsencrypt support already present in Gitea

ChangeLog

This just represents a list of things that have been recovered for Gitea.

The following repos have been created and their contents populated:

  • puppet-common - common to ALL VMs
  • puppet-content - Tupper only
  • puppet-couchpotato - Tupper only
  • puppet-docker - Tupper only
  • puppet-gtombstones - Xavier only
  • puppet-media-network - Tupper only
  • puppet-pureftpd - Tupper only
  • puppet-sabnzbd - Tupper only
  • puppet-sickgear - Tupper only
  • kickstarts - HAL only (for image deployment

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:

  • translates local names using the canonical sender file - so FROM address are correct
  • accepts locally-sent mail and forwards it accordingly - using /etc/aliases

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.

/var/www/wiki.darrenwindle.co.uk/public_html/data/pages/trac.x0blr.com/infrastructure/infrastructure_revision_control.txt · Last modified: 2024/12/01 08:40 by 127.0.0.1
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki