Last week an e-buddy of mine pointed out that she was looking at mailinabox and wondered if it was worth her time. I checked it out, and decided it was, and furthermore was worth my time too.

I spun up a new Digital Ocean droplet, followed the instructions, and it worked. It worked out of the box, just like the name. I've only been using it for a day or two but it really does feel like the complete right direction for indieweb: a black box that you own that just works.

The email portion of this product wasn't even the thing that interested me most, in fact I have a domain on it that's not even my primary email domain (I may switch to this one now though, but that's a whole other process). The part that excited me the most was that ownCloud[owncloud] is installed and activated by default for every account you add to the system. This means truly indie contacts, calendar, and most importantly data. I found a $3 app called Photosync which allows me to automatically back up all new photos to my ownCloud account.

The result of this is that I was able to move my calendar, contacts, and photos out of iCloud and off of gmail (where my calendar was). It feels good to have sliced this little piece out of my own homestead.

Last week I migrated off of docker. I also moved my repos off of my local gitlab instance back to github. The reason for both of these was the same: everything was broken. I knew there was trouble on the horizon several weeks ago when I tried pushing to one of my instances and it failed. The fix took trawling through dozens of identical issues only to find that there was a disconnect between the ubuntu version of my server and the one that docker was expecting to exist. To be fair, a lot of the problem lies with dokku, but really all I wanted was a heroku-type setup I could run on my own box. I could not get things working again and am not really feeling up to putting the amount of effort that would be required in order to get things working.

I have no idea why my gitlab instance stopped working, I suspect it is something similar between the confluence of docker requiring constant maintenance and gitlab being fragile to set up to begin with.

This blog is still using bumble, and I'm still running that on my own box, so there is at least that consolation.

This really feels like an indieweb failure, partly because I was not willing to put in the effort, and partly because I think the level of effort being asked was too great. I look forward to any advances on this front but until then I'm just running my node instances on localhost and forwarding nginx to them manually, with only a few lines of config. There is no automation: if things crash or reboot I have to start everything up again. However this feels good enough for now, even if it's not ideal.

As far as post-mortems go this one is pretty light, but then again the reasons for failure are still a mystery to me so I don't have much more to write about other than the fact that I've gone back to a different setup.

I recently registered the domain gar.zone with the intent of turning it into my own personal url shortener. Thanks to this helpful blog post by Nuno Job I found a good launching off point called tiny. I patched it up, fixed a bug, and am now using it to power my own url shortener. Yay. It doesn't do analytics or anything fancy like that but it works for me! Source is here

You can see it in action here

Earlier this week I had a silly idea and wanted to throw up a static website w/ some very basic content (much like GitHub Pages provides). I of course wanted to host this myself, not on GitHub.

After a quick search I found this is actually very easy to do if you're using dokku (which if you've been following along w/ me on this indieweb journey you may already be!)

Install buildpack-nginx

$ cd /var/lib/dokku/plugins
$ git clone https://github.com/rhy-jot/buildpack-nginx
$ dokku plugins-install

That's it! Now you can make a static site. Make a new repo with a .nginx file (it can be empty, it just has to exist) and a www folder. Everything in the www folder will be served at the root of whatever domain you point it to with dokku

Make your site

$ touch .nginx
$ mkdir www/
$ echo "<h1>Hi!</h1>" >> www/index.html
$ git add remote dokku dokku@dokku-server:hostname
$ git add .
$ git commit -m "Hello World"
$ git push dokku master

You can now to go hostname and see your html! It's that easy. To reiterate: anything you put in the www folder will be served at the configured site.

P.S. the idea that made me look into this was this one

Update Sept 2014

I am no longer using gitlab, it stopped working and I didn't have the energy to fix it. Details here.

Original article

As I've talked about before, I'm currently trying to put some of the principles of indieweb into practice. I started by hosting my own blog content, and then threw up a quick [pastebin clone][artifice] to host my own pastebin data. I decided that next up on my list of things to try to homestead would be my code.

I use git for my version control, and currently host all of my repos on github. Indieweb journey notwithstanding, I have many reasons lately to reconsider that.

Of course, with github you still can own your data, git is a decentralized version control system so you have a complete copy of everything even on your local clone. The things github provides (that are also the data you do not control) are things like issues. Things that are the real 'community' part of your project. As my friend @baldwin said to me earlier today, "It's interesting that github seems to have re-centralized git."

I actually don't know how easy gitlab makes it to do these things. If you have a relatively small project, and thus community, it's a lot to ask a person to create an account on your own little private gitlab instance just to contribute. As I write this I have no idea if it's easy to submit issues or merge requests from outside your local gitlab ecosystem. In theory it should be possible since git is decentralized to send merge requests between systems. Identity could also be handled by oauth (or even better persona) so that participating in someone's project doesn't require a dedicated account in their ecosystem. I'm hoping that these things are either already easy to do, if not they appear to be crucial to making the community portion of version control as open as git itself is.

Installation

I knew that I wanted to be able to use docker to run gitlab. I was already using it if you'll recall from my previous posts. Fortunately there is a gitlab-endorsed docker config. Unfortunately it doesn't work out of the box (the firstrun.sh file tries to build assets before mysql is running) and parts are super confusing (ssh port forwarding for instance is completely hand-wavy). It is also out of date and uses mysql. So like the bad-decision-making person I am, I forked it to get it on the latest versions of things, use postgresql, and most importantly actually work. You are welcome to try your luck w/ the original. Examples here will be using my fork.

The first step is to tell docker about the image:

$ cd /var/local
$ git clone https://github.com/wraithgar/gitlab-docker.git gitlab
$ cd gitlab
$ docker build -t gitlab .

This part takes awhile so maybe go read a book while you wait. Might I suggest Something Greater than Artifice? It may help you decide after all that silos are real.

Configuration

Now it's time to go into your newly cloned gitlab-docker repo and change the settings. in config/gitlab.yml just change the host: config under gitlab: to whatever hostname you are going to want to run gitlab on (I used code.danger.computer). pick a port you want to use on your host machine for git ssh, 222 is a common alternative. Uncomment and set the ssh_port under Advanced settings to this number. Unfortunately this is not something you can configure in docker so you'll have to pick a port number, set it in the config file, and remember that port number later when you forward it to this image. in config/nginx.conf change YOUR_SERVER_FQDN to the same hostname as you put in config/gitlab.yml in config/nginx.conf change PATH_TO_GITLAB_DOCKER to whatever folder you cloned the gitlab-docker repo into (heads up it's in there several times, change them all)

There are a lot of things to configure in config/gitlab.yml not the least of which could be omniauth settings. These settings are not trivial if you are unfamiliar w/ rails and gems. That kind of thing feels like a "future" post instead of trying to work it into this one. If you are feeling adventurous try this post. I hope to revisit this file in a separate post.

I won't be adding omniauth to my initial run of this image because I think config items like that should be changeable after the fact, so I want to try changing them and seeing where the pain points are.

Moving on, the next config item is setting passwords for the gitlab user. Set that in firstrun.sh (and of course pick a good password, c'mon now).

Running

In dockerland, running an image is referred to as 'making a container'. This is when your code starts to run and is where you enter the last bit of configuration items (which other than environment variables sadly all appear to be CLI only).

If you've set everything up right, you should be able to run your image in a new container. However there's one more thing missing from the instructions for gitlab-docker. Remember the port number you configured in config/gitlab.yml that I said to remember? You're going to need to tell docker to forward that from the host machine to the container. In this example I've used port 222. Note that -name is depricated and my example uses --name (the cd into your gitlab-docker folder in the instructions also appears to be superfluous)

$ docker run -d -v /var/local/gitlab:/srv/gitlab:rw -p 222:22 gitlab

Wrapping up

All that's left is for you to let nginx know how to serve gitlab. Copy your edited config/nginx.conf file to /etc/nginx/conf.d/gitlab.conf and restart nginx. If everything worked well (fingers crossed) you should be able to go to the hostname you set up and log in as the predefined user admin@local.host with password 5iveL!fe. You'll be prompted to change that password of course.

You can check out the fruit of my labor at code.danger.computer

The Future

Up next I will actually have to run gitlab and try to get my code into it, including using git over ssh. After that, it's likely making auth happen in a distributed way, and other configuration tweaks.

A small nitpick is that gitlab prompts for login by default rather than redirecting to /public. I will see if that can be changed.

Also I know you can publish docker images but I just didn't have the energy to figure that out after finally getting things working. If I get that working I'll update the readme and this post.

Finally, there is a docker file for the gitlab-ci service. The ci portion of gitlab looks like it will be very useful and I can't wait to dive into that eventually.

After this experience it is apparent that neither gitlab nor docker is really ready for primetime. You can get it to work, eventually but it took me the hobby time of a better part of a week to get things even running for the first time. Hopefully my efforts can be built upon now, with the end goal being even more people being able to host their own code.

A note about swapfiles

In some of the documentation for gitlab I was reading, it was mentioned that if you don't have a lot of memory on your system (say, for instance you went with the small 512MB of ram for your droplet) you may have problems running gitlab, especially the first time. Following the basics in this howto I added a 512MB swapfile to my droplet. The only difference between that howto and what I did was that I set count=512k instead of count=256k in the dd command that created the swapfile. Your environment may not need this but if you're copying what I am doing then it's good to know that I took this step locally.

Update:

After only a few days of running my droplet ran out of memory and I couldn't even publish to this blog w/o dokku crashing. I would definitely go for a slice w/ at least 1GB. I will be upgrading my own shortly.