I have enabled candidate DB and set it to be managed by CDB
on the netconf interactive console I have , I am trying the below command
and seem to be getting syntactical errors ,
* Enter a NETCONF operation, end with an empty line
<delete-config>
<target>
<candidate/>
</target>
</delete-config>
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
<rpc-error>
<error-type>protocol</error-type>
<error-tag>missing-element</error-tag>
<error-severity>error</error-severity>
<error-path>
/rpc/delete-config/target/url
</error-path>
<error-info>
<bad-element>url</bad-element>
</error-info>
</rpc-error>
</rpc-reply>
* Enter a NETCONF operation, end with an empty line
------------------------------------------------------------------------------------------
You need to have both /confdConfig/datastores/candidate/enabled and /confdConfig/netconf/capabilities/candidate/enabled set for the candidate to be available via netconf. If neither startup nor candidate is enabled under /confdConfig/netconf/capabilities, the only remaining possibility for <target> is <url>.
That said, why are you attempting <delete-config> on the candidate? It’s not a very useful operation - typically you want to update running via edit of the candidate, and then you’ll want to start out with a candidate that is a copy of running. <discard-changes> will achieve this.
<discard-changes/> worked and it served the purpose to throw away all changes done in candidate db
But just to understand the error response better,
both the data store and capability were enabled , so was suspecting is needed , but not sure why it has to be given ,since the intention was to delete the entire candiate db and revert it to its default values ,
Which is nothing but the running db.
also brings me to another question ,
when does someone really need to use <delete-config>, netconf RFC prevents it to be ran on running datastore ( looks like we can’t run it on candidate datastore) ??
Your final question is actually quite to the point - the original implementor of the ConfD NETCONF server didn’t think that <delete-config> on the candidate (or startup) made any sense, so simply didn’t include the possibility (unfortunately without documenting this deviation from the standard - though actually it may not have been a formal standard at that point). I.e. the only allowed child of <delete-config> is actually <url>, regardless of which capabilities are enabled in confd.conf - sorry for the misleading first part of my previous reply.
In hindsight, this decision was probably correct - I don’t recall this “problem” having surfaced at any time before in the 10 years that the ConfD NETCONF server has existed - you may actually be the first one to attempt it. The idea of deleting one of the “logical” data stores (as opposed to deleting the configuration “within” a data store) is rather dubious, and the RFC gives no guidance as to what it is actually supposed to mean. And the answer to your question is “never”. In case you actually want to delete all the config in the candidate (or running) for some reason, <copy-config> with an inline empty source should do it (not tested:-).
I also believe this part of the RFC could have been better clarified, It mentions explicitly that running db is NOT supposed to be an argument to <delete-config>, but remains silent about other datastores (like candidate datastore).
~ascesh
P.S noticed my earlier post is looking odd because the text within xml tags got striped out
Well, as far as that goes, I think it should be interpreted to mean that the other data stores can be deleted. But it doesn’t say what it means… “Delete all the config in the data store” could be an interpretation, but that’s not what it says. And that is probably not what you want/expect for <url> (e.g. you want ‘rm file’, not ‘cp /dev/null file’).
Yeah, I did the same mistake - but I noticed it “quickly” and used the edit function (which I otherwise don’t really like) to fix it. Will probably do the same mistake again next time I write an xml tag…
Well, what did you give for <source> in the copy-config? Looking at the “unformatted” version of your message, it looks like < > - what’s that supposed to mean? From RFC 6241 - Network Configuration Protocol (NETCONF)
source: Name of the configuration datastore to use as the source
of the <copy-config> operation, or the <config> element
containing the complete configuration to copy.
Thus an empty “complete configuration” can be given as <config/>, or for the complete rpc:
Try netconf-console -h to see all the nifty options.[quote=“Hatim5253, post:8, topic:565”]
it seems that the RPC is not displayed:
[/quote]
Yes, the forum software “eats” everything that looks like XML - check the preview before you post, and use the </> “Preformatted text” option for XML chunks (for “inline” preformatted text, you can just enclose it in “back-tics”, i.e. ``` characters).
HI,
I use the command:
netconf-console --copy-config=/dev/null --db=running
to delete the running datastore, but after I delete, the netconf-console can’t connect the the confd server now, it always reports the “Authentication failed”, what’s the root cause? Thanks!
I believe @mnovak’s reply to your same question in the other thread is right on target - if you delete all the config in the running datastore, obviously the AAA rules are also gone.
