CERN Accelerating science

Resolving differences between Deployment instructions and the admin Quickstart

I’m trying to resolve the differences between the QuickStart guide: EOS admin configuration — EOS CITRINE documentation
and the more detailed deployment guide (under the Development information)
Develop — EOS CITRINE documentation
to understand how the whole system gets setup and possibly post pull-requests on updates to the documentation.

  1. The development indicates that you need to setup a QuarkDB server first, but there is no mention of setting up a QuarkDB server at all in the quickstart. Why is it needed? Why does eos work without it?

  2. The quickstart sets up authentication with just sss sec.protbind * only sss unix but the deployment guide has:

    sec.protbind * only sss unix
    sec.protbind localhost unix sss
    sec.protbind localhost.localdomain unix sss

which in the .rpm packages has them in the reverse order (the last line might not match exactly because I don’t have an unmodified one lying around):

sec.protbind localhost.localdomain unix sss
sec.protbind localhost unix sss
sec.protbind * only krb5 sss unix

Hi Joseph,

Initially, eos was developed with a in-memory namespace but we soon reached the limitation of that design so we needed to move out the NS component from the MGM daemon for multiple reasons.
It works for you without QuarkDB since the default is still to load the in-memory namespace. This is handled by the following config in /etc/

mgmofs.nslib /usr/lib64/
#mgmofs.nslib /usr/lib64/

Note that the first one is uncommented. You can find more info about QuarkDB here:

Then for what authentication method you set up it’s up to you, you have several options like: krb5, gsi, sss or unix. You can find them explained in the link below.

You can run just one QuarkDB node for testing purposes you don’t need the full setup with three instances.

The correct order for the sec.protbind is most general first and least general last. You can find more info here:


Hi Elvin
Are there guidelines of when you should switch from in-memory namespace to the QuarkDB implementation? (number of clients, files, etc.)

As for the security bindings, most general first would be the wildcards, right?

sec.protbind * only sss unix
sec.protbind localhost unix sss
sec.protbind localhost.localdomain unix sss

Kind regards,

Hi Joe,

We plan to drop support for the in-memory namespace with eos version 5. The limitation of the in-memory namespace comes from the size of RAM required by the MGM since all the namespace in booted in memory, and actually the bootup time - reading the entries from the changelog files and constructing the c++ data structures. For example a 0.5B entries namespace can take up to 45-60 min to start up and requires hundreds (~500) for GB of RAM.

QuarkDB avoids these issue by relying on functionality provided by RocksDB which takes care of moving data from RAM to disk as necessary.


That is very good to know! I would guess the quickstart will need updating at the same time (or a little before)