Public Repository

Last pushed: 2 years ago
Short Description
GlusterFS and NFS-Ganesha on Fedora20
Full Description

A "cover letter" to this repo (also serving as a very basic docker primer)


I published my docker images:

After installing and starting docker (docker-io package on RHEL/Fedora),
you can get it with

$ docker pull csabahenk/fedora20

As you can see at

there are 3 images in this repo, tagged base, gluster, ganesha.

These are full-fledged images, ie. they run a normal init (systemd),
capable of starting any system service (contrary to the most popular
docker image style which starts just a single service process).

As stands to reason, gluster has GlusterFS deployed, ganesha has
NFS-Ganesha deployed; base is their common ancestor with just sshd as
extra service and some customization (you can safely ignore it until
you'd experiment with creating custom images).

Basically you can fire these up as follows (giving rise to so-called

$ docker run --privileged -v /sys/fs/cgroup:/sys/fs/cgroup:ro -d csabahenk/fedora20:<tag>


  • --privileged: this grants privileges to the container that are
    equal to the host, in particular allows cgroup manipulation needed
    by systemd
  • -v /sys/fs/cgroup:/sys/fs/cgroup:ro: this makes the host's cgroups
    actually available (read-only) in the container
  • -d: we want the container to start daemonized (as it's not
    starting an interactive program, there is no point in having it in
    the foreground)

$ docker ps shows you the ids of the containers spawned. For a given
id, you can get the IP address with

$ docker inspect -f '{{.NetworkSettings}}' <id>

Once you have the IP, you can ssh to it as root, password being qwerty.

The customization I have is that I have installed tmux with zsh as
default shell. zsh is the shell I usually use for interactive purposes
because of its superior history facility. There is a single thread of
history that's commonly maintained by shell sesssions. So if you start
tmux you get a zsh prompt and there you can do interactive history
search or run "history | less" and you can see what commands I've been
using on the image. As of ganesha, you can find that usually I ran

    # ganesha.nfsd -L /dev/stdout

the systemd unit not working properly.

Ganesha config files are under

  • /etc/ganesha/ganesha.conf: main config file, probably you can
    leave it intact /etc/ganesha/exports/ganesha-export*.conf --
    config files defining the exports; customize to match the hosts,
    IPs, volume names
  • /etc/ganesha/exports/INDEX.conf: the conf file generated from the
    former kind of ones that facilitates the inclusion of them to the
    main one
  • /etc/ganesha/ the script that generates INDEX.conf; as
    argument give the directory to be indexed (/etc/ganesha/exports/);
    with -v it prints the index to stdout as well. So you can disable
    certain exports at start time by renaming them to have, say, a "~"
    appended to their name and running mkindex.

Other options for docker run you might see useful:

  • --name <name>: you can give this way human-friendly names to your
    containers (and use instead the ids; below I use <container ref>
    as either id or name)
  • --link <container ref>:<link name>: this lets you to have an
    existing container (given by <container ref>) to be named within
    the new one as <link name>; that is, <link name> will be added
    to /etc/hosts and some environment variables will be set up to
    allow scripted access to <container ref>. Practically, if you
    spawned the first container with --name foo, then in the second
    one you can use this as host name if you start it with
    --link foo:foo. In the ganesha exports you can see I have
    hostname="f20-glu";; there f20-glu was the link name of my
    gluster server container
  • -v <host dir>:<container dir>: <host dir> will be available in
    the container as <container dir>; handy as a share mechanism
    between the host and the containers

For dbus interaction I also refer you to zsh history.


Docker Pull Command

Comments (1)
2 years ago

why do these require --privileged? Can't they run as normal containers (e.g. NFS4 can sun on a single non-privileged TCP port).