These are things worth thinking about, but by now the server should be working.
Backups
We have set up a single server, if something goes wrong it not only goes offline, but we risk losing any data not kept elsewhere. Git by it’s nature is distributed, but only when the code is checked out, and in use. I’m not going to offer a guide to setting up backups here, there are numerous ways to do so. Most hosting providers will offer some form of backup option for an extra fee for example. Please do think about this, and set up some backups or you risk losing data.
ssh keys
So you have a user account that you ssh too, and that account is using a secure password (hopefully). However ssh keys are a more secure way of authenticating against a host. To set up ssh key based authentication on your local host you need to generate an ssh public and private key pair, how will depend on your platform of choice. Then when you log into your server you will need to create an authorized_keys file using the folowing comands
mkdir ~/.ssh
touch ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh
you will then need to edit ~/.ssh/authorized_keys and put the contents of the public key file you generated earlier in there, one key per line. Each key that you add will be able to login to that user account.
Time Keeping
The clock on any computer can drift away from the actual time, and for most purposes as long as the time the computer thinks it is progresses forwards, and is reasonably close to the current time nothing is going to go wrong. However keeping the clock accurate isn’t particularly difficult, and there are circumstances where it may be important that it is, especially with something that may be coordinating a distributed software repository. If you have followed this guide you may have noticed that we allowed something called NTP in our iptables rules right at the start. NTP is a protocol for keeping the clocks of computers in sync. Fortunately for us this includes networks like the internet. Volunteers open up their accurate clocks to use by the rest of the internet in pools, and we are going to take advantage of that by installing ntp.
sudo apt-get install ntp
It’s that simple, our computer will now keep it’s clock accurate
Updates
If you’ve fully followed this guide you should now have a working git server, however software is not perfect and over time bugs will be found and fixed in the packages running on our server, and in the gitea binary we are running. It would be a good idea to be notified when these changes are available to install so that we can keep our server up to date. For the debian packages I use apticron to inform me via email when updates are available.
sudo apt-get install apticron
cat << EOF | sudo tee -a /etc/apt/apt.conf.d/10periodic > /dev/null
APT::Periodic::Enable "1";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::CleanInterval "10";
EOF
sudo sed -i 's/EMAIL="root"/EMAIL="user@example.com"/' /etc/apticron/apticron.conf
This will send an email to user@example.com once a day if there are any updates available. You should substitute user@example.com for a valid email address. Unfortunately as we have installed gitea from binary this will not update gitea. You will need to download the latest binary and replace the one on disk when it becomes available, if you follow the gitea blog they announce new releases. At the time of writing the latest version was 1.13.0, but if when you follow this guide a newer version is available you should use that instead. To update gitea when a new version is available you need to stop gitea, and replace the binary on disk and restart gitea.
sudo service gitea stop
VERSION=1.13.0 wget -O gitea https://dl.gitea.io/gitea/$VERSION/gitea-$VERSION-linux-amd64
sudo rm /usr/local/bin/gitea
sudo chown root:root gitea
sudo mv gitea /usr/local/bin/
sudo chmod +x /usr/local/bin/gitea
sudo service gitea start
You will need to substitute 1.13.0 with the version you are wanting to install.