I was too addled to actually get any work done, but I did try to fiddle with my work environment on my laptop. At some point, I found myself browsing through Homebrew to see if there were any tools I hadn't been using that would spark my interest. I quickly got tired of using brew search, brew info and then popping the URL into Chrome to see what the package was all about.

Of course, there is braumeister.org to browse through Homebrew packages online, but I'm the obsessive sort. Particularly when I have nothing better to do. I wanted to go through as much as I could. That's when I decided to automate.

brewCheck runs through every package listed by your local brew search command, and opens up the package's listed URL in Chrome for you to take a look at. It then asks if it looks like something you want to install. Type y/Y and it will add the package to a running list in a .brewInstall file kept in the local user's home directory. Any other input, and the script closes the tab in Chrome, and goes to the next available package to start the process anew.

Since there are over 3000 packages to go through, I figured it would be nice to be able to stop/resume this at any time. That's accomplished by keeping track of what packages were checked in a .brewChecked file, also kept in the local user's home directory. Any packages listed there will not be checked on subsequent runs of the script. This also means that as new packages are added, it will remain a quick and useful way to go through them.

The script does have three dependencies that aren't provided by default on OS X:

• Google Chrome
• chrome-cli
• vramsteg

I also included the ability to have it do the same thing with brew-cask or any other similar brew subcommand, by calling the script with the subcommand as an argument (i.e: brewCheck cask).

Honestly, this is a total timewaster of a script. The majority of the packages are libraries of one sort or another. That being said, it did lead to me stumbling on allegro, and tinkering with that was a fun diversion during the Memphis Grizzlies/Portland Trialblazers blowout.

Notice:

For a while now, I've been wanting to try out one of the self-hosted alternatives to DropBox. As it stands, I've made do with the 10GB of free storage I've accumulated on DropBox, and when necessary I've dabbled in a few of the other free alternatives like Google Drive, OneDrive and Box. Ultimately though, I'm the sort that likes to roll my own when I can, so I will.

I did some reading, and settled on trying out Seafile. I figure I might be able to run this on my usual VPS within a Docker container. A quick search on Docker Hub brings up a few existing repos for deploying Seafile, but all of them assume you'll be using MySQL/MariaDB and/or require you to shell into the container to run the interactive install/setup scripts for Seafile.

For my use case, I figure I'll probably be ok with SQLite, and doing so would reduce the memory footprint I need to run it, which will keep my VPS costs down. And as for the interactive install script, I was curious so I quickly dove into the code for those, and I'm thinking we don't need no stinking interactive install script.

The instructions provided for setting up a personal instance of Seafile up on a Linux box are actually pretty good. They're pretty straight-forward, and hold your hand with all the commands you'll likely need. Most of the configuration is done through an interactive shell script that calls a Python script behind the scenes to do the dirty work.

This is all well and good, but unfortunately Docker doesn't do interactive scripts, so I'm going to have to work out what I need to get things configured up front. Off the top of my head, this might require some user-defined environment variables, and a custom non-interactive script that runs at build time.

Of course, I might end up finding out exactly why no one else has done this yet. All part of the fun.

Initial Dockerfile

To start off with, we're basing from the official Ubuntu 14.04 repo, and then some boilerplate. If you're wondering what the REFRESHED_AT declaration is about, I'd recommend you read James Turnbull's Docker Book.

First things first, I create and set my working directory.

I follow the install manual pretty closely here. I just make sure to set up my python/sqlite3 dependencies before anything else.

After building this image, I can jump into an interactive container with the usual docker run -it <image> /bin/bash to poke around and experiment.

Let's Look At Configuration

In the documentation, there is a section about the config files and how they're set up, but a quick look over that and a manual run of the installation flow makes it seem like there might be a thing or two I'm missing. That and I'm bored, and I could use an excuse to flex my Bash/Python comprehension muscles.

Our first installation script is setup-seafile.sh. Quick skim and it looks like some effort was made to keep things tidy, with default settings and utility functions up top, and a decent amount of documentation/commenting. Said comments helpfully point out that the "main workflow of this script" starts on line 354. I'm not going to deep dive into any of this, so if you're interested in implementation details, you can look at the code yourself. At a glance, it all looks pretty straightforward.

The first few function calls do a bit of sanity/dependency checking. They warn if you run as root, make sure the filetree in the install path looks sane, and make sure you have the necessary system dependencies (i.e. python & sqlite). For our purposes, we can skip all this.

The next bits check to see if there is an existing ccnet config file, and if not, prompts for the information it needs. In this case, it's asking for:

• A name for the Seafile server
• The IP or domain for the server
• The port to use for the ccnet server

The name & IP/domain should probably be handled as an environment variable in the Dockerfile. The port we'll leave as the default 10001, which we'll expose in the Dockerfile for the end-user.

Here we see a similar pattern, however in this case, the user is always prompted for the desired path for the data directory. It will then check to see if the directory has any data, and prompts accordingly depending on what it finds. Again, we can skip all of this, and move on to where it prompts for the info it needs to fill out the config:

• The port to use for the seafile server
• The port to use for the seafile fileserver

And for posterity, let's not forget:

• The path for the Seafile data directory

Again, we'll set an environment variable for the data directory, and expost the default ports (12001 & 8082, respectively) in the Dockerfile.

In fact, this is a good place to pause and get back to our Dockerfile:

Some of those environment variables are obvious placeholders. I'll make sure to note in the eventual README that they really need to be defined at build time. I've also exposed the ports we need so far at their respective default values.

Back to it then.

Create ccnet conf

Now, we skip past the script confirming the data provided, and on to the helpfully titled "Create ccnet conf" section.

Here's where it gets interesting. It uses a binary to generate our ccnet config file, and passes the information needed (i.e. server name/port/ip/domain) via CLI arguments. However, it prepends the call with a declaration for LD_LIBRARY_PATH. A quick test confirms that without that environment variable set, the binary won't run:

A quick search for SEAFILE_LD_LIBRARY_PATH, and there it is on line 11.

Let's try prepending that environment variable manually:

Let's see what happens when we run it with some arguments:

OK, now we can get this in to our Dockerfile:

Wait, there's no build-time env option?

Now our Dockerfile build generates a ccnet config for us. Of course, the problem here is that since the configuration is set at build time, the end-user is going to be stuck with the defaults if they try to docker pull this image in the future.

Here we have the inherent dilemma that probably prevented this from being pushed up to Docker Hub by anyone. An alternative option would be to provide a boilerplate ccnet.conf in the repo, provide instructions on customizing the file, and including the file with an ADD command in the Dockerfile.

It would be a lot more elegant however, if we could just provide environment variables at docker build time like we already can at docker run time. I was all ready to storm into the Docker repo to submit a Feature Request when:

Glory be, it's already on the way.

As such, I'm going to go ahead and continue down this path rather than try to refactor this. For now, people will have to grab the Dockerfile and build on their own if they want to crib this. In the hopefully near future, we'll all have better options.

Create seafile conf

Onward.

This looks awfully familiar. Let's give that binary a go, with the required environment variable already set in our container:

Oooh, verbose. We can have some fun here.

I suppose there wasn't much to be verbose about.

Back to the Dockerfile:

Since we're doing multiple things from the seafile-server-* directory, I decided to DRY it up a little.

Skipping ahead to the brief "Write seafile.ini" section:

This is easy enough to include in our Dockerfile:

Create seafevents.conf

The next section is a one-line function call, so let's just go straight to that function

Looks like it's just creating a conf directory and generating a static file. Getting that into the Dockerfile is simple enough.

We'll just add the static seafdav.conf in as part of the repo, alongside the Dockerfile.

Create seahub/settings.py

Next section:

Again, simple enough. We just need to call this python script to generate a key and pipe that into a file. Let's get that in the Dockerfile:

Seahub configuration

There's some interesting code that's commented out in the "Seahub related config" section. It looks like at some point, they were setting up the initial admin user authentication credentials for the Seahub web UI through some functions in this script. The functions never get called though, as that batch of code is completely commented out.

Skipping ahead we get to the generation of the Seahub database in sqlite3:

Into the Dockerfile:

Now for some media folder shenanigans:

Not sure about all that relative traversal for the link, but sure. Into the Dockerfile we go:

Now, a seafile-server-latest symlink:

Dockerfile:

Some file permissions:

Dockerfile:

And finally, some user manuals get moved around:

Last dance:

Final Seahub configs

Looking at the startup script for Seahub, it seems to set its port interactively at startup. However, it defaults to 8000, so we'll just expose that in the Dockerfile:

Finally, we still need to setup that initial admin user for Seahub. When actually using the scripts provided, the seahub.sh startup script actually checks for an existing admin user and prompts for the information needed to set one up if one doesn't exist:

The function actually just calls a separate Python script to handle this task, so let's dive into that one:

The main program flow is actually contained within an if __name__ == '__main__': block, which is a nice Python idiom for only executing the program if the script is called directly. This means we can import the file and make use of the script's functions in our own script without invoking the original program flow.

A quick glance over the main() function and we can spot a call to create_admin(email, passwd). That definitely looks like what we need:

Let's give this a whirl in a Python REPL:

We're missing some libraries. A quick skim of the calling seahub.sh reveals a before_start function:

A quick grep in those lib directories, and I find the culprit:

Another try:

CCNET_CONF_DIR was also declared in before_start().

With that, we can finally import the create_admin function:

Only to bump into another error. Looking through the traceback it seems to be trying to connect to another service. Best guess is that it expects the Seafile server to be running.

Back in the REPL:

And there we go. Now to get all of this into our Dockerfile build.

We

• create some environment variables for setting the admin email & password
• import create_admin.py
• start up the Seafile server
• run create_admin.py with the appropriate environment variables set
• delete create_admin.py

create_admin.py:

Looks good to me. Now to have it start the server and the UI together at container boot.

Dockerfile:

For the start_services.sh script, I had the problem that Seafile's startup scripts aren't continually running processes. So, if I simply called ./seafile.sh start && ./seahub.sh start, the container would boot Seafile & Seahub, but would then stop the container, as the process was successfully finisehed at that point. To fix that, I decided the simplest method would be to provide some sort of sleep infinite while loop that would keep the process going indefinitely.

I also noticed that Seafile's startup scripts don't provide any logging, so to both keep the container running as a daemon and provide a barebones look into if the Seafile processes are actually running, I provided some basic output to the container's stdout:

That will be the extent of it unless the script detects a change in the running process list. In that case, it will alert that a change was detected, and will show the “Running Seafile processes” again.

Wrap-up

Thinking it over, I would say that it would be worth looking into separating out each process into its own container and then linking them together. At the very least, seafile-server and seahub could probably be separated and linked. Maybe even a third container to handle a shared /seafile volume for the two. A project for another day perhaps.

While this isn't a production ready Seafile server, and the image probably won't be useful with the defaults set up in the Dockerfile's ENV calls, this may still be of some use to someone. As such, I'll be writing up a quick README, and pushing this up to Github, and I'll probably link the Github repo to Docker Hub in case anyone wants to play with it for some reason.

And hey, if that build-time ENV feature gets merged into the next revision of Docker, we can revisit and maybe make it a viable public image after all.

• https://github.com/andres-rojas/seafile-docker