Skip to content


Switch branches/tags

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time

Smeagol galore

Build Status

A lightweight version of cloudogu's git-based wiki system smeagol, the lightning-fast alternative to gollum.

GIF showcasing smeagol-galore

Runs without a full Cloudogu ecosystem, but still features

  • Markdown,
  • WYSIWYG Editors,
  • PlantUML,
  • SCM-Manager as Git backend,
  • Single Sign On using CAS,
  • built-in let's encrypt support,
  • everything deployed on an Apache Tomcat and
  • neatly packed into a docker image.

Diagram showing components and their relationships

Table of contents


Getting started

docker run -p 8443:8443

Note that

  • SCM-Manager installs plugins via the internet on first startup, so it might take some time.
    You can choose which plugins are installed by editing plugin-config.yml, e.g. by mounting your own version into the container: -v your-plugin-config.yml:/etc/scm/plugin-config.yml.
    See SCM-Jenkins for available plugins.
  • A self-signed certificate will be created on startup. These will result in warnings in your browser.
    See bellow for custom certificates.
  • Smeagol galore will be available on https://localhost:8443 (and via /smeagol).
    SCM-Manager will be available on https://localhost:8443/scm.
  • Default user/pw: admin/admin (see bellow for custom credentials)
  • PlantUML Rendering uses by default. Note that this might be blocked by browser plugins such as uBlock 🤔 You can use your own instance with a custom image, though. See Building.
  • You might find older versions of smeagol galore on DockerHub, if they haven't been deleted by their image retention policy.

Persist state

SCM-Manager (Repos/Wikis)

Mount SCMM Volume to persist your repos/wikis: -v $(pwd)/dev/scm:/home/tomcat/.scm . This will also persist SCMM plugins, so the second start will be much faster.

Make sure the smeagol galore container use (UID 1001) is allowed to write to this folder by either chowning or chmod. For development the following will do

mkdir -p dev/scm
chmod 777 dev/scm
docker run --rm --name smeagol-galore -p 8443:8443 -v $(pwd)/dev/scm:/home/tomcat/.scm schnatterer/s

Smeagol's Repo Cache

Although not strictly necessary, it is recommended to persist Smeagol's repo Cache at /home/tomcat/.smeagol. Without it smeagol will have to clone every repo from SCM-Manager again. Especially for large repos (100MB+) this will slow down the first request to each repo after the container has been restarted.

Custom Certificate

The self-signed certificate that is generated on startup by default is only a valid option for trying out and development. In production, you should provide a proper certificate, which can be done by either:

  • mounting your certs
  • enabling built'in Lets's Encrypt support

Note that smeagol, cas and SCMM communicate with each other via HTTPS. If you're certificate is not trusted by the JVM you should add it to the trust store and then mount it like so: -v $(pwd)/dev/cacerts:/opt/java/openjdk/lib/security/cacerts.

See for an example.

Mount your own certs

Just mount your certs into the container like so: -v $(pwd)/certs:/config/certs/${FQDN}.

Smeagol galore's server loads the certs from the following files inside the /config/certs/${FQDN} folder:

  • cert.pem
  • fullchain.pem
  • privkey.pem

Built-in Let's Encrypt support

If you don't have any reverse proxy infrastructure that handles TLS temrination, the most convenient way of handling TLS is to use Smeagol Galore's built-in Let's Encrypt support.

Before getting started, make sure

  • to set the DNS record to match the external IP address of your host and
  • that ports 80 and 443 are routed to the container ports. By default:
    • external port 443 to container port 8443 (-p443:8443) and
    • external port 80 to container port 8080 (-p80:8080)

Then just enable let's encrypt via the environment:

  • -e ENABLE_LETSENCRYPT=true - enable let's encrypt support
  • - determines the domain to request the cert for
  • -eSTAGING=true - If set to true creates certs against Lets Encrypt's staging, which has no rate limit but is not accepted by your browser.

For a full example see examples.

At startup Smeagol Galore still generates self-signed certs, if none are there, as it needs cert files to get the server started.
Once the server is up, a background process queries the certs from Let's Encrypt, if their validity is less than 30 days. The process checks once a day if the certs are valid less than 30 days and renews them, if necessary.

Create more wikis

Note that the git arg -c http.sslVerify=false is only necessary for testing with a self-signed cert . If you use an official TLS cert this won't be necessary.

  • Go to https://localhost:8443/scm
  • Log in as administrator
  • Create a git repo
  • Clone into git wiki, e.g. for localhost: git -c http.sslVerify=false clone https://admin@localhost:8443/scm/git/test
  • Add empty .smeagol.yml file: touch .smeagol.yml && git add .smeagol.yml && git commit -m 'Create smeagol wiki'
  • Push, e.g. for localhost: git -c http.sslVerify=false push
  • Go to https://localhost:8443/smeagol

All in one:

git -c http.sslVerify=false clone https://admin@localhost:8443/scm/git/test
cd test
touch .smeagol.yml
git add .smeagol.yml
git commit -m 'Creates smeagol wiki'
git -c http.sslVerify=false push --set-upstream origin master


Default user/pw: admin/admin

Credentials defined in /etc/cas/users.txt and /etc/cas/attributes.xml. Custom ones can be mounted into the container like so for example: -v $(pwd)/dev/users.txt:/etc/cas/users.txt.

See users.txt and attributes.xml.

CAS has "pluggable authentication support (LDAP, database, X.509, 2-factor)" see CAS 4 docs. Get started at deployerConfigContext.xml


Via Environment Variables:

  • Set the name of SCM-Manager's ADMIN_GROUP
  • Set your Fully Qualified Domain name (including Port) - FQDN
    Note that the smeagol galore container must be able to resolve this address as well, because the webb apps communicate with each other (smeagol -> cas, smeagol -> scm, scm -> cas). You can try this out locally, by adding the following entry to your /etc/hosts: smeagol and then passing the following parameters to the container: -v /etc/hosts:/etc/hosts -e FQDN=smeagol:8443. You can then reach smeagol at https://smeagol:8443.
  • HTTP_PORT and HTTPS_PORT. Ports to listen on. Note that FQDN contains the HTTPS port (if != 443).
    For now, the tomcat user is allowed to listen on ports 80,443 and of course > 1024.
    Other ports are only possible when run as root (docker run -u0), which you shouldn't.
    *Note: This seems to only work when the image is built with newer versions of docker (tested with 19.03.08) but not with the one use by DockerHub. As the image is built from source there, these image will result in Socket bind failed: [13] [Permission denied].
    To showcase the feature I pushed an image with tag 0.2.0-SNAPSHOT-2e1ec28f. If this works for you, you might want to build the most recent version from source yourself.
  • -e DEBUG=true exposes port 8000 as Tomcat debug port
  • Additional arguments can be passed to tomcat, or the webapps (CAS, smeagol, SCM-Manager)
    • As Docker CMD, e.g.
      docker run '-Xmx1g -Dabc=def'
    • Via env var EXTRA_JVM_ARGUMENTS, e.g.
      docker run -e EXTRA_JVM_ARGUMENTS='-Xmx1g -Dabc=def'
    • Examples:
      • -XmX2g to virtual machine / tomcat process
      • See CAS's and
      • Smeagol's application.yml
      • for options. These can either be set
        • as System Property, e.g. docker run -e EXTRA_JVM_ARGUMENTS=''...) or
        • Environment Variable, e.g. (docker run -e -e PROPERTY_NAME=value ...).
      • This is used in the example to increase session timeout / token expiration.
  • Via SMEAGOL_GALORE_LOGIN_WELCOME you can customize the welcome message on the login screen. Default is Smeagol Galore

The container is run as with UID and GID = 1000. If you want to run it as a different user you pass -u param when running the container. However, you should make sure that the user exists (e.g. mount /etc/passwd).

Another option is to build your own image and set --build-arg USER_ID and GROUP_ID to your liking.

More substantial example

See example for a more substantial example using docker-compose.


There was an example on how to deploy to kubernetes see this revision. It was no longer maintained, so if needed it could be used as a starting point. Even more convenient would be a helm chart. PRs welcome.

Import from Gollum

  • Just create a new repo in SCM-Manager and push Gollum's wiki there. Then do the following, add and commit each step. Finally push.
  • touch .smeagol.yml
  • mkdir docs
  • Move all files to /docs
    mkdir docs
    git mv -k * docs #-k ignores errors such as moving docs to docs
    git mv -k .* docs #hidden files
  • There are a couple of limitations regarding file names.
    Find an rename or git mv them.
    • For example, find files that end with a blank before the file extension: ll | grep ' \.md'.
    • Find files that do not match the character whitelist of smeagol: find ./ -printf "%f\n" | grep -Pv '^[\w\.\-_/ ]+$'.
      You could just replace them: rename 's/[(),#+~&]/_/g' * (add more characters to replace in the first part of the regex, if needed).
      But keep in mind that changing the name of a file might break links to those.
    • If you used uploads in Gollum, you might have to change the links.
      If you used fully qualified (absolute) links (like or relative links starting in / (like /uploads) you should change all to uploads.
      You can find them like so: grep -r and grep -r /uploads/.
  • For some reason the version overview in smeagol shows only changes occurred after moving the files.
    However, the history can still be found in git via scm-manager.
  • Note that it is also possible to run Gollum and Smeagol in parallel:
    • Just add a git origin to Gollum's Git repo pointing to the Git Repo in SCM-Manager.
    • You can then sync via push and pull in Gollum's git repo.


Extend Log output

Details for SCM-Manager, CAS, and Smeagol bellow. Process is the same for each component:

  • Copy log files from source
  • Increase levels for appenders
  • Mount into container

See also more substantial example using docker-compose.


  • logback.xml
  • Run Container with -v $(pwd)scm-logback.xml:/tomcat/webapps/scm/WEB-INF/classes/logback.xml
  • See also


  • logback.xml
  • Run Container with -v $(pwd)/smeagol-logback.xml:/tomcat/webapps/smeagol/WEB-INF/classes/logback.xml
  • See also


  • log4j.xml
  • Run Container with -v $(pwd)/cas-log4j.xml:/tomcat/webapps/cas/WEB-INF/classes/log4j.xml


  • Start container with -p8000:8000 -e DEBUG=true
  • Load sources for SCM-Manager and related plugins, CAS from this repo and/or smeagol into your IDE.
  • Start debugger, e.g. in IntelliJ on port 8000


Log4Shell / CVE-2021-44228


Smeagol-galore does not use Log4j version 2, so it is not affected.

  • CAS includes log4j version 1, Smeagol includes log4j-api and log4j-to-slf4j and SCM-Manager uses logback which all are not vulnerable in terms of CVE-2021-44228.
  • However, when an attacker has write access to the cas log4j config, the JMSAppender class could abused for an attack similar to log4shell.
    This class was removed preventively in 1.6.1-1-r1.
  • A similar attack vector exists in Logback used in SCM-Manager, which was patched in version 2.27.3 of SCM-Manager, contained in galore 1.6.1-1-r1.
    The above link states that SCM-Manager plugins might be affected, which you should check via script plugin.

So in Smeagol galore >= 1.6.1-1-r1, with default SCM-Manager plugins there is no vulnerability similar to log4shell, according to current knowledge, as of 22 December, 2021.


Unidata/tomcat-docker: Security-hardened Tomcat container




docker build -t smeagol-galore .

  • Optionally, you can choose your own PlantUML server like so: --build-arg PLANTUMLSERVER="https://[...]/png/"


  • Convert to a more 12-factor-like app using multiple containers and docker-compose
  • Create helm chart
  • Maybe persist CAS Tickets, so we can stay logged in even in case of a restart? HSQL stored to file= Docs seem a bit unconsistent for cas 4.0.x, though. Better with 4.1.x.