notagit

Utilities for managing Git repositories and servers using only bash and ssh.

• Repository
• Documentation

Read below for a quick description of each utility.

Installation

gsb.sh and gitsync.sh can be run directly from the repo directory.

On a production server, they probably belong in /usr/sbin. To put them there, you can run

make test && make sudo make install

gsb.sh (git-shell_bind)

A bash script to administer Git repos on a server; accessed via ssh keypairs only.

Why

Setting up and administering a secure git server can be kind of a pain.

This is solved by gsb.sh, which was thought up to be:

• Secure
• Simple
• Use existing mechanisms only: introduce no new (bug-prone) code

How

1. Putting each bare repo inside the root-only /usr/src/git location.
2. Making a system group for each repo.
3. Giving each user a system account allowing only:
   • git-shell
   • ssh login with keypairs
4. Selectively bind-mounting authorized repos into the relevant user’s home dir to give read access.
5. Selectively adding the user to the supplementary group of the git repo to give write access.
6. Using ONLY existing system mechanisms to manage this
   • do not write anything
   • do not require sysadmins to track another config file

See the gsb.sh documentation for details and examples.

gitsync.sh

Continuously updating a git repo from a remote source … safely.

There seems to be no tool for this; especially one which handles bare repos (synchronizing servers between each other).

This is requires care when development/commits may be happening in either (or both) locations and the wish is to avoid any unexpected behavior.

Use this script (e.g. as a cron job) to:

• Syncronize multiple development machines in the background, while you’re working on any one of them.
• Have a server pull changes from an upstream repo (e.g. for CI work, using a post-merge hook).
• Synchronize bare repos of two gsb.sh servers both ways, to make them redundant.

See the gitsync.sh documentation.

Contribution

Contributions are always welcome, in order of preference:

• Fork and send a pull request
• Open an issue
• send me a mail at sirio.bm@gmail.com

Documentation

Docs are written in Markdown and then auto-generated with Jekyll.

If you would like to hack on the documentation:

• place any new files in the docs directory
• files should have an .md extension
• make any links relative to the root of the repo; e.g.: [gsb](/notagit/docs/gsb.html)
• please put a title: frontmatter at the top of every file

TODO

• Quotas on .git repos (to stop users from crashing server)
• Possible to have a dedicated directory for .git temp files when read-only users are pulling?
• Pen testing
• Tab completion for gsb.sh
• How to represent/handle sync of deletions (users, repos, keys, auths)?

Naming

I called it notagit since by using these utilities, sysadmins everywhere can demonstrate their outstanding, pragmatic intelligence and deep wisdom in the way of unix things ;)

Also, it is literally not a Git, nor is it some extension to Git in yet-another-language-with-dependencies.