Is there a way to block a container from being available on CLI? I want it to be still available as API and NETCONF.
I understand I can hide it, but that means its’ still available if the user enters full CLI command.
Is there a way to block a container from being available on CLI? I want it to be still available as API and NETCONF.
I understand I can hide it, but that means its’ still available if the user enters full CLI command.
I’m not sure what you mean here. If you insert the tailf:hidden statement in a container, the container and everything below is hidden from user interfaces (CLI and WebUI) but visible from machine interfaces (NETCONF, RESTCONF or SNMP) and if you don’t add the hide group to confd.conf there is no way to make the container visible.
If you want to prevent a whole module from being used in CLI, you can use the export option of confdc. “man confdc”
Otherwise, you can use a data rule in NACM to control read and write permissions on a specific data path.
Hide groups are useful to hide nodes and protect them with passwords, like diagnostic commands.
I suspect @shrakuma may be thinking of the clispec directive /clispec/$MODE/cmd/options/hidden
, which behaves like that - if you know that the command exists, you can use it. But of course this directive only applies to the command defined by the parent /clispec/$MODE/cmd
element, and isn’t relevant for hiding an auto-rendered container.
Otherwise, you can use a data rule in NACM to control read and write permissions on a specific data path.
Hide groups are useful to hide nodes and protect them with passwords, like diagnostic commands.
That is absolutely correct, but I’m not sure it is good advice in this context - I would recommend @jjohansson’s suggestion of using tailf:hidden
with a hide group that isn’t listed in confd.conf - this is a good way to hide data nodes from user interfaces without any possibility of access.
NACM rules are very powerful and can definitely be used to achieve the same effect - but I think it is good to keep in mind that their purpose really is to specify access rights, not to give a specific “user experience”. E.g. in this case, if a given user can access a node via NETCONF but not via CLI, it isn’t really a matter of access rights. Having a large number of NACM rules for the purpose of “hiding” is also likely to have a bigger performance impact than using tailf:hidden
on the corresponding nodes.