Installing Go and Gogs on Webfaction
Oct 17, 2015Since getting Gogs running on Webfaction took me quite some googling and I found eerily little info avaialble on the subject matter (like looking at the second page of google results little) so here is a no frills instruction to do just that.
All things considered its rather simple procedure.
Preparing the account
Since Gogs likes to have it’s own user account to run on and when given a chance takes over the accounts ssh access I found it best do just that and run it on a separate account. Luckily Webfaction has us covered here and making a separate account is as easy as logging into your admin panel and heading over to “Account | SSH/SFTP users”.
Add a new user and select “bin/bash” for shell. We will be using this to set up everything and later for uploading git repos also. FYI this username will become part of your remote repository urls.
Since we are already in the admin panel go ahead and create all the usual pieces needed for webfaction applications (domain, application, website and database) for application category choose “Custom” and type “Custom app (listening on port). Take note of the port that gets assigned to your custom app. We will need this later to tell Gogs which port to listen on.
Installing Go
The simplest way to install Go I found is just to download the Linux binary from Go website and unpack it to your new accounts ~/lib/go. But first lets make some preparations so go would feel right at home.
SSH into the new account and make the needed directories.
$ ssh gogs@gogs.yourdomain.com
$ mkdir tmp
$ mkdir lib
$ mkdir gocode
Download and unpack latest Go binary into ~/lib/go/
$ cd lib
$ mkdir go
$ wget https://storage.googleapis.com/golang/goX.X.X.linux-amd64.tar.gz
$ tar -C go -zxvf goX.X.X.linux-amd64.tar.gz
Edit ~/.bash_profile to add all the needed environment variables
export TMPDIR=$HOME/tmp
export GOROOT=$HOME/lib/go
export GOPATH=$HOME/gocode
export PATH=$PATH:$HOME/bin:$GOROOT/bin
Newer instructions for Go tell that it is no longer needed to specify $GOROOT but since we are using a precompiled binary that expects $GOROOT to be “/user/local/bin/go” we have to override the default.
This is all it takes to get GO running just logout/login the session to give bash a chance to learn the new env variables and Go should be ready to go ha. You can run “go version” to make sure
$ go version
$ go version go1.5.1 linux/amd64
Installing Gogs
This might be going against some Go philosophy but again the easiest way I found to get things working was to download the binary and unpack it into its own directory.
$ cd ~/
$ wget https://github.com/gogits/gogs/releases/download/vX.X.X/linux_amd64.zip
$ unzip inux_amd64.zip gogs
$ mkdir gogs-repositories
This should unpack the application files into “~/gogs” ready for us to run it. Since there is no app.ini configuration file yet lets specify the port manually for the first time
$ cd gogs
$ ./gogs web -p "XXXX"
Where “XXXX” is the port number specified in the description of Custom applicaion we created earlier in Webfaction admin panel.
Configuring Gogs
If everything went as expected your brand new Gogs installation should be now accessible from the domain specified for your application in Webfaction website config earlier.
On first run Gogs will redirect Us to the installation page where all the fields should be quite self explanatory. Just keep in mind that Webfaction automatically configures a nginx instance to sit in front of the application and redirect all requests coming from http towards Gogs app domain to the port specified for the custom application.
Thus the custom app port number should only be use for the HTTP_PORT option so Gogs will know what port to listen. Erything else should be filled in from the perpective of an outside visitor.
After the finishing the installation it is no longer necessary to specify the port number manually. You can also use “./gogs web &” to send the gogs process to background thus enabling You to exit the ssh session without killing the application. It is probably a good idea to make a cron task that keeps your Gogs process running if it should stop but that is out of the scope of this article.
SSH remote GIT repository access.
All that is left to do is to create your first project. Open your Gogs use profile settings, paste in the public SSH key of your workstation and git remote push away.
But if You are lazy like me and could not be bothered to set up a cron task on the first time You might discover that after the inevitable has happend and the Gogs process has stopped and You try to log back in to start it. It is no longer possible to SSH into your gogs account. Instead You see a message like that.
$ ssh gogs@gogs.yourdomain.com
PTY allocation request failed on channel 0
Hi there, You've successfully authenticated, but Gogs does not provide shell access.
If this is unexpected, please log in with password and setup Gogs under another user.
Connection to gogs.yourdomain.com closed.
What has happened is Gogs has ‘hijacked’ the accounts “~/.ssh/authorized_keys” file and filled it in with somethin along the lines to this
command="/home/gogs/gogs/gogs serv key-0 --config='/home/gogs/gogs/custom/conf/app.ini'",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3MdaZ8yc2EAAEADA0...
Thus effectively disabling SSH terminal access to any PC having that public key. You could go and remove the key from You Gogs profile and restore access but that would break using git remotes.
So far the only solution I have come up with is to make a separate rsa key for my Gogs profile and limit my workstations public keys depending on the domain being accessed.
Luckily it is really simple to do. Just specify in your workstations “.ssh/config” file what keys should match with what domains.
Host gogs.yourdomain.com
IdentityFile ~/.ssh/gogs_id_rsa
IdentitiesOnly yes
Host yourdomain.com
IdentityFile ~/.ssh/id_rsa
IdentitiesOnly yes
This way You can use the website full domain “gogs@gogs.yourdomain.com:username/project.git” when assigning remote repositories. And “ssh gogs@yourdomain.com” when needing to access the server terminal and avoiding the limits set in authorized_keys for the gogs public key.