Domino on Linux/Unix, Troubleshooting, Best Practices, Tips and more ...

    Domino Catalog vs Domain Catalog

    Daniel Nashed  11 June 2016 16:50:33
    I while ago I ran into this and I did analyse how it works in detail. But I never posted this information.

    Today we ran into this again and I looked for my old documentation.

    -- Daniel

    Here is how it is intended to work and how most admins are currently using it.


    I was very surprised when I figured out how the catalog and domain catalog really work.

    My impression was always that the catalog.nsf is a replica that is replicated everywhere.


    But there are two different types of catalogs:


    Normal Catalog


    - Content resist only on one server and is not replicated. Local server will update the data.

    - Other servers have reader access and nobody beside the own server can update it.


    Domain Catalog


    - Contains database information for many or all servers

    - Other servers have editor access and database information is pulled from other replicats to the central database

    - If a server has no replica of the catalog.nsf the catalog on the Domain catalog server will spider the server and collect databases, else the catalog task will replicate the database!



    So in any case the catalog.nsf should be a replica on each server -- actually it is derived from the replica of the server's names.nsf (it's one of the special replicas).

    Each replica maintains it separate ACL and each server should only have manager access on his own replica.
    The catalog.nsf is designed to have different ACLs so that only the Domain catalog servers will contain all data.


    When the catalog task starts it will check if the config document document has the "domain catalog" enabled.

    In that case LocalDomainServers, LocalDomainCatalogServers will be editor access in catalog.nsf on the local server Else both groups are set to reader access instead!


    That would mean if you add an admin server or have a catalog.nsf created on a server in a way that other servers have manager access to the database the ACL it might replicate all data and the concept of the catalog distribution will not work in most cases!


    Normally an Administrator would expect that LocalDomainServers are manager on catalog.nsf and the HUB server is admin server of the database with manager access and the ACL should be the same on all servers.

    But the catalog.nsf is intended to have a different ACL on each server instead. That was complete news for me. I was often wondering what is happening with the LocalDomainServers and LocalDomainCatalogServers all the time in some cases.


    Because LocalDomainServers, LocalDomainCatalogServers ACL entries are always checked and updated when needed by the catalog servertask, you should not change those ACL entries!
    And in case you want your own group to control replication of catalog.nsf in your own way, you should not use those two ACL entries but create your own group.


    In case a server has manager rights in the remote database it would push his ACL to the other server or if the other server has manager access, receive the ACL changes -- depending also on the time-stamps in the ACL.

    So what could happen is that you end up with a permanently changing ACL and potentially all catalog entries on all servers in your Domino domain -- depending which server is domain catalog server.


    This is not the intended way the catalog should work! It is intended to have separate ACLs settings on each replica and every server manages it's own ACL settings.

    Also the mentioned two ACL entries should not be removed from the ACL because that causes the catalog task to fail updating the ACL and does stop the catalog task before updating the catalog content.


    What might happen in many cases is that you create a "normal" replica of your catalog.nsf. In that case you could already run into trouble because the ACL might contain an admin server entry that is copied.

    That means the server you replicated the catalog.nsf from will be able to update documents on that new server -- which is not the intended way it should work.


    The best way would be just to start the catalog servertask and have the server create an empty replica based on the derived replica id from the names.nsf.

    Catalog.nsf will than only be replicated to a Domain catalog replica instead to all servers.


    Again I was very surprised when I figured out the logic behind it in detail and how it is intended to work.

    If you ran into this situation the best way would be to start from scratch.

    You remove the catalog.nsf databases on all servers, verify the right settings for the "Domain catalog" in server document and plan your catalog.nsf distribution that way.

    Once you are done you can just run the catalog task on each catalog server to populate it.

    When that is done, you can start the catalog task again on all the domain catalog servers.


    Take care: If you start it before a server has a new replica the Domain catalog server would spider the server manually and you could end up with duplicate documents in the catalog once the catalog task has been started on the local server later on.

    As a trick you could set the "Limit domain cataloging to the following servers:" field next to the Domain Catalog field in the Servertasks / Domain Catalog tab. This field limits which servers should be queried.

    Also take care that an administrator with manager access should never replicate the catalog.nsf because that would also potentially break the ACL and the replication scheme.


    Comments

    1Stephen Bailey  13.06.2016 18:39:12  Domino Catalog vs Domain Catalog

    Interesting. I've never seen this subject defined so well. That said, the logic seems a bit ridiculous.

    I changed my config so that all servers have Editor access (with one admin hub having Manager), and a common catalog.nsf across the domain.

    If I want information by server, by title or whatever, there's a view for that in the catalog.nsf.


    • [IBM Lotus Domino]
    • [Domino on Linux]
    • [Nash!Com]
    • [Daniel Nashed]