ConfD User Community

How to check the running db mode or access

Hi All,

I am working with external Db and also enabled the Candidate CDB.
In the confd.conf ,we are setting the running datastore as “writable-through-candidate” and in confd status command , I see one of the session as “read_write”
Is this expected ? How can i check the Running db mode ?

Below is the snapshot of the confd.conf

  <!--
      Disable cdb only if you're using your own configuration database
      to store all data, including the AAA data.
  -->
  <cdb>
    <enabled>true</enabled>
    <dbDir>../var/confd/cdb</dbDir>

    <!--
        During development it can be useful to set a low timeout to
        catch programming errors. In a production system use
        "infinity" (default) or a high timeout so as not to timeout
        during high CPU load.
    -->
    <clientTimeout>PT30S</clientTimeout>

    <!--
        The operational datastore is used when operational data is to be
        stored in CDB.
    -->
    <operational>
      <enabled>true</enabled>
    </operational>

  </cdb>

  <!-- Defines which datastores confd will handle. -->
  <datastores>
    <!--
        'startup' means that the system keeps separate running and
        startup configuration databases.  When the system reboots for
        whatever reason, the running config database is lost, and the
        startup is read.
        Enable this only if your system uses a separate startup and
        running database.
    -->
    <startup>
      <enabled>false</enabled>
    </startup>

    <!--
        The 'candidate' is a shared, named alternative configuration
        database which can be modified without impacting the running
        configuration.  Changes in the candidate can be commit to running,
        or discarded.
        Enable this if you want your users to use this feature from
        NETCONF, CLI or Web UI, or other agents.
    -->
    <candidate>
      <enabled>true</enabled>
      <!--
          By default, confd implements the candidate configuration
          without impacting the application.  But if your system
          already implements the candidate itself, set 'implementation' to
          'external'.
      -->
      <implementation>confd</implementation>
      <storage>disk</storage>
      <filename>../var/confd/candidate/candidate.db</filename>
    </candidate>

    <!--
        By default, the running configuration is writable.  This means
        that the application must be prepared to handle changes to
        the configuration dynamically.  If this is not the case, set
        'access' to 'read-only'.  If running is read-only, 'startup'
        must be enabled, and 'candidate' must be disabled.  This means that
        the application reads the configuration at startup, and then
        the box must reboot in order for the application to re-read its
        configuration.

        NOTE: this is not the same as the NETCONF capability
              :writable-running, which merely controls which NETCONF
              operations are allowed to write to the running configuration.
    -->
    <running>
      **<access>writable-through-candidate</access>**
    </running>

  </datastores>

Below Snapshot of System session :

system sessions:
  sessionId=1 2020-08-14 13:46:16 system@0.0.0.0 system/system
       no locks set
       no transactions
  **sessionId=10 2020-08-14 13:46:18 system@0.0.0.0 system/system**
**       no locks set**
**       transactions:**
**          tid=6 db=running mode=read_write**

  sessionId=11 2020-08-14 13:47:07 system@127.0.0.1 system/tcp ./netconf/netconf_pub.c:139
       no locks set
       no transactions

@mnovak @per @cohult :
Can you please help on this query ?

I think you should not worry about that session. It is there after a fresh start and I suppose it is a ConfD internal thing (note also system/system - the second system indicates CONFD_PROTO_SYSTEM which is supposed to be used by ConfD initiated transactions, as written in the documentation; though ConfD allows you to start your own “system” transactions).

As for the runtime status, you can look at the reported capabilities, e.g. like

$ netconf-console --hello | egrep 'candidate|running'
    <nc:capability>urn:ietf:params:netconf:capability:candidate:1.0</nc:capability>
    <nc:capability>urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&amp;revision=2011-06-01&amp;features=confirmed-commit,candidate,rollback-on-error,validate,xpath</nc:capability>

This is for system with running set to writable-through-candidate, the important part is the candidate capability (and feature) and the absence of writable-running among capabilities (and features).