Private git server with gitea

PURPOSE

With Microsoft acquiring GitHub (for $7.5 BILLION), I now have incentive to host my own Git repositories. For the longest time I had thought that GitHub was an Open Source project, but then I was stymied when I tried to find a way to host my own GitHub server (it seems you need to be an Enterprise to host a proper private GitHub).

Fast forward a couple of years, and Vivek Gite’s *nixcraft blog post on the subject was linked to me via email. The purpose of this article is to document my efforts to install Gitea. I had tried to install it at https://eldon.me/git/, but that would require retooling the other web application at https://eldon.me/ (WordPress). The folks on IRC (#nginx@freenode) said to make a subdomain, rather than a subdirectory. After being reminded that it’s easy to add CNAMEs to my DNS records, I now have https://git.eldon.me.

Why do this? I’d like to start using git more for my personal projects. I’d rather not store sensitive materials anywhere but something I fully control. Also, being able to link folks to my own repository rather Debian’s (or whoever’s) paste bin when I’m having issues is quite attractive to me.

PREREQUISITES

  • A Linux server (mine is a ChunkHost chunk running Debian 9.4 [stretch])
  • nginx installed (with optional SSL/TLS certificates [HIGHLY RECOMMENDED])
  • A database engine (I already have MariaDB [10.1.26-MariaDB] installed). If in doubt, go with Gitea’s built-in SQLite3 database
  • SSH service enabled on the target host (at an optional nonstandard port)

PROCEDURE

The following instructions use non-root user and host in the commands. Change accordingly.

  1. Log into the target host via SSH (user will be assumed to *NOT* be root):
    ssh host -l user
  2. Make a staging directory and change to it:
    mkdir -p ~/src/gitea && cd ~/src/gitea
  3. Install prerequisite packages git, golang (from stretch-backports), wgetand zip:
    sudo apt install git wget zip
    sudo apt -t stretch-backports install golang
  4. Add a new user for Gitea
    sudo adduser --disabled-login --gecos 'Gitea' git
  5. Change this new user git:
    sudo -u git -i
  6. Get the latest version of gitea (currently v1.4.2)
    mkdir -p bin
    wget -O bin/gitea https://dl.gitea.io/gitea/1.4.2/gitea-1.4.2-linux-amd64
    chmod +x bin/gitea
  7. Exit the git user shell
    exit
  8. Create systemd service file /etc/systemd/system/gitea.service for Gitea:
          [Unit]
          Description=Gitea
          After=syslog.target
          After=network.target
          After=mariadb.service mysqld.service postgresql.service memcached.service redis.service
        
          [Service]
          # Modify these two values and uncomment them if you have
          # repos with lots of files and get an HTTP error 500 because
          # of that
          ###
          #LimitMEMLOCK=infinity
          #LimitNOFILE=65535
          Type=simple
          User=git
          Group=git
          WorkingDirectory=/home/git
          ExecStart=/home/git/bin/gitea web
          Restart=always
          Environment=USER=git HOME=/home/git
        
          [Install]
          WantedBy=multi-user.target
  9. Start Gitea:
          sudo systemctl enable gitea
          sudo systemctl start gitea
          
  10. Create an nginx site configuration file /etc/nginx/sites-available/git.host:
    server {                                                                                                                                                                                      
        listen 80;                                                                                                                                                                            
        listen [::]:80;                                                                                                                                                                       
        server_name git.host;                                                                                                                                                             
        return 301 https://git.host;                                                                                                                                          
                                                                                                                                                                                                  
        # Redirect non-https traffic to https                                                                                                                                                     
        # if ( != https) {                                                                                                                                                               
        #     return 301 https://;                                                                                                                                               
        # } # managed by Certbot                                                                                                                                                                  
                                                                                                                                                                                                  
    }                                                                                                                                                                                             
                                                                                                                                                                                                  
    server {                                                                                                                                                                                      
        listen 443 ssl;                                                                                                                                                                           
        server_name git.host;
        ssl_certificate /etc/letsencrypt/live/host/fullchain.pem; # managed by Certbot                                                                                                     
        ssl_certificate_key /etc/letsencrypt/live/host/privkey.pem; # managed by Certbot                                                                                                   
                                                                                                                                                                                                  
        root /var/www/git.host/;                                                                                                                                                              
        location / {                                                                                                                                                                              
                client_max_body_size 364M;                                                                                                                                                        
                proxy_set_header Host ;                                                                                                                                                      
                proxy_set_header X-Real-IP ;                                                                                                                                          
                proxy_pass http://localhost:3000;                                                                                                                                                 
                proxy_connect_timeout 600;                                                                                                                                                        
                proxy_send_timeout 600
        }
    }
    
  11. Enable the new git.host:
    ln -s /etc/nginx/sites-{available,enabled}/git.host
  12. Restart nginx
    sudo systemctl restart nginx
  13. Enter MariaDB client shell (admin account)
    mysql -u root -p'password'
  14. Add gitea database
    CREATE DATABASE gitea;
  15. Add gitea user
    CREATE USER 'gitea' IDENTIFIED BY 'new_password';
  16. Grant privileges to gitea user
    GRANT ALL PRIVILEGES ON gitea.* TO 'gitea'@localhost IDENTIFIED BY 'new_password';
  17. Exit the MariaDB mysql client shell
    exit
  18. Now, you’re ready to configure Gitea at https://git.host/!

Renewing my Free SSL certificate with StartCom

Since my Secure Sockets Layer (SSL) certificate needs are quite modest, I use the free SSL certificates from StartCom. Here are my instructions for renewing it, which is almost identical to the process for creating an SSL certificate with StartCom.

  1. Go to the main site, and log in with your StartSSL Open Identity certificate. Create one if need be.
  2. Validate your email address in the resulting dashboard. The validation will be in force for 30 days.
  3. Validate every domain you wish to renew.
  4. Generate the certificate for the domain you are renewing.
    1. Select the StartCom SSL Certificates Wizard.
    2. Choose Web Server SSL/TLS Certificate, and click Continue.
    3. Your validated domain should show in the list. Enter the domain you’re generating the keys for into the “Please enter your full hostname here” input field.
    4. Under “Please submit your Certificate Signing Request (CSR):” select “Generated by Myself”. You can use the form, but generally I remember reading that it’s more secure for you to generate your Certificate Request (CSR) and private key from it yourself, using an offline OpenSSL script invocation. The present a suitable openssl command invocation, to which I added the -subj option to avoid having it prompt me for that information:
      openssl req -new -newkey rsa:2048 -nodes -out eldon.me.csr -keyout eldon.me.key -subj "/C=US/ST=Georgia/L=Mableton/O=Eldon Carl Blancher III/CN=eldon.me"
      
    5. Copy the content of the CSR into the resulting form. It will look something like this:
      • -----BEGIN CERTIFICATE REQUEST-----
        BLAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
        OBFUSCATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTEDDD
        BLAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
        OBFUSCATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTEDDD
        BLAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
        OBFUSCATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTEDDD
        BLAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
        OBFUSCATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTEDDD
        BLAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
        OBFUSCATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTEDDD
        BLAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
        OBFUSCATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTEDDD
        BLAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
        OBFUSCATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTEDDD
        BLAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
        OBFUSCATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTEDDD
        BLAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
        OBFUSCATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTED==
        -----END CERTIFICATE REQUEST-----

        The actual code has been obfuscated to protect it, I highly doubt that’s a valid CSR now.

    6. Click “Submit.” If the CSR is accepted, the resulting page should provide a link to the new certificate files (the “here” link), as a ZIP archive.
    7. Download and unpack the archive. There are several ZIP archives with in it, one for some possible web servers. The Apache.zip file contained two files:
      • 1_root_bundle_crt, renamed to startcom.crt
      • 2_eldon.me.crt, renamed to eldon.me.crt

        Now that the certificates are generated, I need to add them to my apache2 web server.

      1. My current sites-available/eldon.me apache2 configuration looks like this:
        <VirtualHost *:80>
        DocumentRoot /var/www/eldon.me
        ServerName www.eldon.me
        ServerAlias eldon.me
        ServerAdmin trey@blancher.net
        ErrorLog /var/log/apache2/eldon.me-error.log
        TransferLog /var/log/apache2/eldon.me-access.log
        RedirectPermanent / https://eldon.me/
        </VirtualHost>
        
        <VirtualHost *:443>
        ServerName www.eldon.me
        ServerAlias eldon.me
        ServerAdmin trey@blancher.net
        SSLEngine on
        SSLProtocol all -SSLv2 -SSLv3
        SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM
        SSLCertificateFile /etc/ssl/certs/eldon.me.pem
        SSLCertificateKeyFile /etc/ssl/private/eldon.me.key
        SSLCertificateChainFile /etc/ssl/certs/startcom_sub.class1.server.ca.pem
        SSLCACertificateFile /etc/ssl/certs/startcom_ca.pem
        DocumentRoot /var/www/eldon.me
        Customlog /var/log/apache2/eldon.me-access.log combined
        ErrorLog /var/log/apache2/eldon.me-error.log
        HostnameLookups On
        </VirtualHost>
        
        <Directory /var/www/eldon.me>
                Options FollowSymLinks            
        #       AllowOverride Limit Options FileInfo
          AllowOverride All
                DirectoryIndex index.php
        </Directory>                                  
        
      2. I changed these three lines:
        SSLCertificateFile /etc/ssl/certs/eldon.me.crt
        SSLCertificateKeyFile /usr/local/apache/conf/eldon.me.key
        SSLCertificateChainFile /usr/local/apache/conf/startcom.crt
        
      3. Reload apache2, and the new SSL certificate is loaded!

Colorizing messages in mutt index

I’d heard a long time that if I’m a self-respecting Linux or UNIX geek I should use a terminal-based email client. My options are Alpine and mutt, and it seemed that while mutt was the hardest to get up and running, it was also the most flexible and powerful. I have drunk the Google Kool-Aid, so I had been loath to switch from Gmail, my workflow habits (in both personal and work Gmail) depending on certain features.

The first feature of Gmail (available in the “Labs” section) that I used very heavily was the multi-colored stars feature. At home, I use six different stars (green-check, yellow-bang, red-star, blue-info, purple-question, and green-star, in this order). At work I use eight (these and yellow-star, and blue-star). One thing I always hated about Gmail, is that I had to repeatedly click on the empty star icon in Gmail to cycle to the star I wanted. For seldom-used stars, this meant that I might not remember where it is in the list, so I’d accidentally cycle past it, sometimes multiple times until I got the star I wanted. Another problem with these stars is that they don’t translate to any other mail client. It would be really nice if Google would add something like “X-Gmail-red-star” or something to the email headers, but that isn’t what happens now (not sure if that would violate an RFC).

The other feature I use is the priority inbox, which separates the inbox into “Important and Unread,” “Starred,” and “Everything else.” I use this especially at work to help me triage email. I get a lot of stuff which isn’t junk, but that isn’t addressed (To: or Cc:) to me, so I don’t read it. All messages To or Cc’d to me get an automatic star (Gmail only has the capability to add yellow-star to messages automatically, something I hope to rectify with mutt. One day….).

The only thing I’ve figured out how to do in mutt thus far is at least a first stab at achieving the multi-colored stars feature. This time, it’s all tied to key macros, so no having to cycle through until I find the color I want. The way it works is through mutt’s scoring feature. At least for now, each score range (100-199, 200-299, 300-399, etc.) gets set to whatever color that score range gets. Whenever I run the macro to color a message, I pipe it (<pipe-entry>) into a bash script I wrote which greps for the Message-ID, filters out the Message-ID’s angle brackets (‘<' or '>‘), adds the relevant score, and then writes a score configuration command to a separate rc file (~/.mutt/stars). Then, I have mutt reload it’s configuration (thankfully score isn’t something that requires a complete restart).

First, the section of .muttrc I have for stars:

# Star scoring 
source ~/.mutt/stars

set my_red_star = 1000
set my_magenta_question = 800
set my_yellow_bang = 600
#set my_green_star = 400
set my_green_check = 200
set my_blue_info = 100
set my_del_star = 0

macro index,pager sr "<pipe-entry>~/bin/stars $my_red_star<enter><enter-command>source ~/.muttrc<enter>" "Mark the current message with RED"
macro index,pager sm "<pipe-entry>~/bin/stars $my_magenta_question<enter><enter-command>source ~/.muttrc<enter>" "Mark the current message with MAGENTA"
macro index,pager sy "<pipe-entry>~/bin/stars $my_yellow_bang<enter><enter-command>source ~/.muttrc<enter>" "Mark the current message with YELLOW"
macro index,pager sc "<pipe-entry>~/bin/stars $my_green_check<enter><enter-command>source ~/.muttrc<enter>" "Mark the current message with GREEN"
macro index,pager si "<pipe-entry>~/bin/stars $my_blue_info<enter><enter-command>source ~/.muttrc<enter>" "Mark the current message with BLUE"
macro index,pager sd "<pipe-entry>~/bin/stars $my_del_star<enter><enter-command>source ~/.muttrc<enter>\
<pipe-entry>~/bin/del_stars<enter>\
<enter-command>source ~/.muttrc<enter>" "Remove color marking from the current message"

color index default brightred '~n 1000-1100'  # Mark the message with red!
color index magenta default '~n 800-999'  # Mark the message with magenta!
color index black brightyellow '~n 600-799'  # Mark the message with yellow!
#color index default green '~n 400-599'  # Mark the message with green!
color index green default '~n 200-399'  # Mark the message with green (check)!
color index brightblue default '~n 100-199'  # Mark the message with blue!

And my stars script:

#!/bin/bash                                          
                                                     
msgid=$(grep -m 1 '^Message-I[Dd]' | awk '{print $2}' 
                                   | sed 's/[<>]//g')                                                                                                                                                                                        
echo "score \"~i $msgid\" $1" >> ~/.mutt/stars       

My delete stars (del_stars) script (which doesn’t work all the time, but I haven’t been able to investigate why):

#!/bin/bash

msgid=$(grep -m 1 '^Message-I[Dd]' | awk '{print $2}' | sed 's/[<>]//g')
sed -i "/$msgid/d" ~/.mutt/stars

Now the stars script doesn’t always work, either. I think I’ve tracked it down to Message-IDs which use nonalphanumeric symbols in them (like pipe ‘|’ and dollar-sign ‘$’). I might not be quoting the “~i $msgid” correctly (single-quotes, maybe?). Not terrible for a first stab at this. I wonder if any old mutt hands will have a fit if they see this, but I’m too tired to investigate further. It works well enough for my purposes right now. Also, I don’t know the performance ramifications of an ever growing ~/.mutt/stars file. We’ll have to see how that goes.

Backup WordPress Files and Database

I’ve been meaning to create a backup of my WordPress files and databases on my VPS (ChunkHost). After a minimal amount of digging (on WordPress’s Codex site), I wrote this script:

#!/bin/bash

WPBAK=/var/backups/wordpress
tar -cvJf $WPBAK/$(date +%F)_files.tar.xz /var/www || exit 1
mysqldump --all-databases --verbose | xz -c > $WPBAK/$(date +%F)_databases.sql.xz || exit 2

Just change the “$WPBAK” variable to where on the server you want to store the backups. Also, you’ll need to create the ~/.my.cnf file (I did it for the root user):

[mysqldump]
user=root
password=secret

You’ll need to change user to the appropriate MySQL user, and the password accordingly. Be sure to set .my.cnf to have the permissions 600 (“chmod 600 ~/.my.cnf”), that way the script doesn’t need to contain the MySQL user password in order to make the dump.

I put all of this in /etc/cron.daily/wordpress, and made it executable (“chmod +x /etc/cron.daily/wordpress”). This way my system will back up automatically on a daily basis.

The next step is to update my rsnapshot configuration so it will store the backup on my Network Attached Storage (NAS). First, I had to copy the SSH public key for my NAS admin user to my VPS, and add it to the user doing the work. Then, I added a single line (port number changed to protect the innocent):

backup  root@eldon.me:/var/backups/wordpress    eldon.me/       ssh_args=-p 4321

I’m waiting for another rsnapshot backup process to start naturally, rather than kicking off a manual run. I’m curious to see if this works as well as I thought.

The next step is to write a cron job that will remove old backups. This is simple enough (put in /etc/cron.daily/wordpress_backup-cleanup, and make executable, as above):

#!/bin/bash
find /var/backups/wordpress/ -mtime +7 -exec rm {} \;

This will delete backup files greater than seven days old. This will hopefully keep my li’l VPS’s disk from filling up. And that’s it!