No netconf configuration until atleast one subscriber is available


I have a query, Is it possible to make confd server reject any netconf configuration for the installed data models unless at least one subscriber application is running and subscribed to the DB changes.


You can declare a subscriber to be mandatory using cdb_mandatory_subscriber; if that subscriber crashes, it needs to be restarted (or other subscriber needs to use the name provided in the function) before any transactions can be committed - see the documentation. Does this work for you?


Yes I am already using cdb_mandatory_subscriber() with cdb_subscribe2() and TWO PHASE protocol. If application crashes then the above mentioned behavior is achieved.
What I need is even without the application crashes/stops, i.e. when only confd server is running and application/subscriber is yet to be started first time, even in that case no configuration shall be allowed.
I was thinking of a naïve way, to start a small daemon application, with mandatory subscriber and kill it immediately. Then start the main subscriber application with same name.
It would be good to know In case there is some better way to achieve this.


You can have a two-phase subscriber that, in the prepare phase, does a maapi_eval_xpath_expr() with a count(/confd-state/internal/cdb/client[type="subscriber"])>1 XPath expression.

If the string “res” from the maapi_eval_xpath_expr() call is NULL there is only one subscriber registered and the two-phase subscriber can abort the transaction with a suitable error message. If “res” is “true” there is more than one subscriber registered,

Hi Conny,

Thanks for sharing this information and API details. Will try this.

Just one query, is there any parameter that we can set in confd server configuration which disables the confd server to accept any configuration. When we start our Application then resets/enable confd server to accept configuration.

This way we might not need to have any additional subscription/application.


Hi Ankit

When starting ConfD and your applications you would typically use start-phases. See ConfD UG chapter “Starting ConfD”, the confd(1) man page section “COMMUNICATING WITH CONFD”, the confd_lib_maapi(3) man page under maapi_start_phase() + maapi_wait_phase(), the confd_lib_cdb(3) man page under cdb_get_phase() + cdb_wait_start(), and the examples.confd/cdb_subscription/trigger example for details.