A lightweight version of cloudogu's git-based wiki system smeagol, the lightning-fast alternative to gollum.
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.
docker run -p 8443:8443 ghcr.io/schnatterer/smeagol-galore
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 editingplugin-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 plantuml.com 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.
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 chown
ing 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
meagol-galore
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.
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 entrypoint.sh for an example.
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
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
)
- external port 443 to container port 8443 (
Then just enable let's encrypt via the environment:
-e ENABLE_LETSENCRYPT=true
- enable let's encrypt support-eFQDN=example.com
- determines the domain to request the cert for-eSTAGING=true
- If set totrue
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.
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
:127.0.0.1 smeagol
and then passing the following parameters to the container:-v /etc/hosts:/etc/hosts -e FQDN=smeagol:8443
. You can then reach smeagol athttps://smeagol:8443
. HTTP_PORT
andHTTPS_PORT
. Ports to listen on. Note that FQDN contains the HTTPS port (if != 443).
For now, thetomcat
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 inSocket bind failed: [13] [Permission denied].
To showcase the feature I pushed an image with tag0.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 ghcr.io/schnatterer/smeagol-galore '-Xmx1g -Dabc=def'
- Via env var
EXTRA_JVM_ARGUMENTS
, e.g.
docker run -e EXTRA_JVM_ARGUMENTS='-Xmx1g -Dabc=def' ghcr.io/schnatterer/smeagol-galore
- Examples:
-XmX2g
to virtual machine / tomcat process- See CAS's
cas.properties
and - Smeagol's application.yml
- for options. These can either be set
- as System Property, e.g.
docker run -e EXTRA_JVM_ARGUMENTS='-Dproperty.name=value'...
) or - Environment Variable, e.g. (
docker run -e -e PROPERTY_NAME=value ...
).
- as System Property, e.g.
- This is used in the example to increase session timeout / token expiration.
- As Docker
- Via
SMEAGOL_GALORE_LOGIN_WELCOME
you can customize the welcome message on the login screen. Default isSmeagol 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.
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.
- 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 anrename
orgit 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 (likehttps://mygoll.um/uploads
) or relative links starting in/
(like/uploads
) you should change all touploads
.
You can find them like so:grep -r https://mygoll.um/uploads/
andgrep -r /uploads/
.
- For example, find files that end with a blank before the file extension:
- 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.
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
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.