Now I’m facing some scenarios which need to do some extra process based on syntactic validation result (not the semantic validation) against the YANG schemas. The UG looks like doesn’t involve this topic, so some thoughts just came to my mind but needing the team’s valuable suggetions:
Is it possible that using “confd_register_user_hook” to capture the standard RPC request & reply message, like get, edit-config? If possible, then I can try to parse xml content and use *_cs_node relevant APIs to do the syntactic validation.
Or, is there a way to let application inject a callback function(c-api, econfd/Erlang api, whatever) into ConfD during syntactic validation process?
This depends on what you mean by “syntactic validation”. Strictly speaking, syntactically valid request is a request that adheres to the YANG model; and ConfD takes care of that, nothing else is necessary. This includes stuff like pattern statement that can do quite a lot in validating string-based leaf values. If that is not enough you can implement your custom types that further restrict values. If validating individual values is not what you are looking for, there are leafref type, must or when statements, and finally heavy guns like validation callpoints. Does any of those work for you?
I don’t think there’s an official built-in way/hooks to affect the same running transaction on this level - e.g. to allow to build custom error message with suggestion on how to fix incorrect paths according to loaded models etc.
We are in the same line with “syntactic validation” – I’m referring to it as adhereing to the YANG model on shema tree hierarchy. Actually we got a requirement that needs to trigger a event upon a northbound message “edit-config” or “get-config” trying to access a non-existing branch or node against the YANG models. As for validity check over leaf node value, like “pattern”, “range”, and data type consistency, etc., we can ignore all of those things now.
we’re using validation callback heavilly and it’s powerful for executing application level logic validation, and for now we’re looking for if there are any interact points when ConfD process the incoming rpc request, like callback, notification, or even intercepting the rpc message content prior to ssh forwarding it to ConfD deamon.
Now I’m thinking about the following solutions:
adding some code to otp/ssh, which intercepts the netconf message, parses it and do the syntactic validation against YANG models;
intercepting the netconfTrace Log output of ConfD and extract the xml message content, and then doing the parse and validation.
Thanks josephm,
This is from customer and we have to seek any possible solutions to support it. and that’s why I’m so crazily digging into ConfD currently.
Somewhat desperate option is to put OpenSSH in charge of terminating SSH sessions and hook into its netconf subsystem - you can access unencrypted NETCONF data there. But not only you would have to deal with stuff like NETCONF framing mechanisms, you would need to implement changes completely unrelated to what you are trying to achieve (unless you have OpenSSH already). Read more about using OpenSSH in the documentation.
To me this sounds like opening a huge can of worms, maybe using the NETCONF trace log is actually a better option. There might be other options if you are really interested in logging access to particular paths; otherwise, I can’t see anything reasonable.
I believe you should to say no to those type of requirements and refer to the NETCONF RFC 6241. E.g. The <edit-config>section under “Attributes”, the <get-config>section, and <get>section.
As for using “NETCONF trace log”, thinking about it twice, looks like it has the following drawbacks:
controlled by the gating flag netconfTraceLog/enabled;
we have to handle the increasingly log file very carefully(even with a rotation) in a production environment;
For now the xml request message can be captured w/ econfd/erlang interfaces and the RPC content is extracted by using RE – so that the NETCONF framing can be skipped, especially for the difference of version 1.0/1.1 – thanks your reminding again. Now, validation against YANG-models after pasering it with xmerl is also almost done and I’m trying to record a netconf log which going into the file of /confdConf/logs/netconfLog, like: