NSO error recovery audit log - wrong action name: The audit log under /var/log/ncs on NSO VM shows different name for some actions. "Sync-from", "Sync-to" shows "error-recovery""Re-deploy Dry Run" shows "re-deploy""Re-deploy Reconcile" shows "re-deploy"The same action name should be seen the audit log for easy debugging.Attached is the actions with audit log messages.Please let me know if there is a concern to open a CDETS.
 Hi Crystal, Please provide NSO API invoked from CNC UI for the each of scenarios that you reported the issue.Thanks,LinhThanks Mukul.Hi Linh,From end users point of view, they will not know the internal implementation. All of the actions are error recovery includes the one highlighted the ones have matching action names. It would be great if we can add more details to distinguish different actions. And that is the purpose of having audit log.What do you think?Thanks.-CrystalFrom: "Mukul Shukla (mukshukl)" <mukshukl@cisco.com>Date: Friday, August 6, 2021 at 1:07 PMTo: Crystal Yu <cyu2000@cisco.com>, "nso-ned-jira.gen -X (Generic User at Cisco)" <nso-ned-jira.gen@cisco.com>Cc: "cat-ui-dev(mailer list)" <cat-ui-dev@cisco.com>Subject: Re: NSO error recovery audit log - wrong action nameHello Crystal,I think this makes sense. The sync-from and sync-to are actually part of error-recovery actions of a service and sync-from and sync-to are actually just sync directions being passed -Here is a sample call for L3VPN for sync-to We call - /ietf-l3vpn-ntw:l3nm-actions/error-recoveryWith payload - {"sync-direction": "sync-to" , "service": serviceName}For sync-from the payload changes to reflect sync-direction, the URL doesnt. So its actually an error recovery call.For Redeploy maybe the message can be improved from NSO, but here again the call is always to redeploy We POST to serviceKey + "/re-deploy". Only the payload (type of redeploy) changes in payload Normal redeploy no payloadRe-deploy Dry run - { "dry-run": { "outformat": "cli" } }Redeploy Reconcile - { "reconcile": { "keep-non-service-config":{} } }Thanks,MukulFrom: Crystal Yu (cyu2000) <cyu2000@cisco.com>Date: Friday, August 6, 2021 at 12:11 PMTo: nso-ned-jira.gen -X (Generic User at Cisco) <nso-ned-jira.gen@cisco.com>, Mukul Shukla (mukshukl) <mukshukl@cisco.com>Subject: Re: NSO error recovery audit log - wrong action nameHi Linh,I am including Mukul here to help me for the information you requested.Hi Mukul,I tried all the error recovery actions from Provision UI page. And found some of them does not have the right action name in NSO audit log. Linh is looking for the APIs invoked from CNC UI. Can you help to share the info.? Mainly for the highlighted ones.Here is the description for the JSD request in case you can not access the link:The audit log under /var/log/ncs on NSO VM shows different name for some actions."Sync-from", "Sync-to" shows "error-recovery""Re-deploy Dry Run" shows "re-deploy""Re-deploy Reconcile" shows "re-deploy"The same action name should be seen the audit log for easy debugging.Attached is the actions with audit log messages.Please let me know if there is a concern to open a CDETS.Thanks.-CrystalHi Crystal,I'm not too sure what the ask here is? Are the actions requested incorrect or just not showing up properly in the audit.log?First of all let me say, that T-SDN does not manage `/var/log/ncs/audit.log`, this log is managed by the NSO Platform as such if there are issues with the logging an RT with the platform team would need to be filed; however, ifthe issue is incorrect actions are being requested, then that means the at the NB interface which is sending the wrong commands to NSO as these are POST requests.As far as incorrect logging is concerned, I would need reproduction steps with NSO directly since I was unable to reproduce the issue by manually sending POST requests.<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"><pre>curl -X POST http://127.0.0.1:8080/restconf/data/cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-policies:policies/policy=SRv6-701-igp-absolute-disjoint/re-deploy --user admin:admin</pre></div></div>audit.log output<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"><pre><INFO> 9-Aug-2021::09:03:32.321 pop-os ncs[39559]: audit user: admin/153 RESTCONF: request with http: POST /restconf/data/cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-policies:policies/policy=SRv6-701-igp-absolute-disjoint/re-deploy HTTP/1.1 trace-id=299decb2-bfa0-465a-824d-44bef4219945 <INFO> 9-Aug-2021::09:03:32.326 pop-os ncs[39559]: audit user: admin/155 assigned to groups: admin <INFO> 9-Aug-2021::09:03:32.326 pop-os ncs[39559]: audit user: admin/155 created new session via rest from 127.0.0.1:43212 with http <INFO> 9-Aug-2021::09:03:32.592 pop-os ncs[39559]: audit user: admin/155 terminated session (reason: normal) <INFO> 9-Aug-2021::09:03:32.592 pop-os ncs[39559]: audit user: admin/153 terminated session (reason: normal) <INFO> 9-Aug-2021::09:03:32.592 pop-os ncs[39559]: audit user: admin/153 RESTCONF: response with http: HTTP/1.1 /restconf/data/cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-policies:policies/policy=SRv6-701-igp-absolute-disjoint/re-deploy 204 duration 307963 ms trace-id=299decb2-bfa0-465a-824d-44bef4219945</pre></div></div>Thanks,RegiI should say the above output was created using NSO 5.5.2.3. It would be good if you can provide the details outlined for support: Thanks,RegiHi Reginald,We have a test case to test audit log for NSO actions triggered from CNC UI. What I am checkin is the audit log message itself not the action request is incorrect. Based on the information you shared. The audit log has to be handled by NSO team. Do you happened to know the CDETS's product and component to use for NSO platform.Hi Crystal,Let's first narrow down the issue and see if its actually a bug with NSO or not. Can you please share a screenshot of the action information in CNC UI?Submitter wanted logging for not just the RESTCONF API, but the payload pushed as well. This sort of logging can be enabled but should be done so in production settings.<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"><pre>from ncs.conf(5):/ncs-config/logs/webui-access-log/traffic-log (boolean) [false] Is either true or false. If true, all HTTP(S) traffic towards the embedded Web server is logged in a log file named traffic.trace. The log file can be used to debugging JSON-RPC/REST/RESTCONF. Beware: Do not use this log in a production setting. This log is not enabled by default and is not rotated, i.e. use logrotate(8).</pre></div></div>The log output is as follows:1. Send RESTCONF POST request with payload<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"><pre>curl -X POST http://127.0.0.1:8080/restconf/data//cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-policies:policies/policy=SR-CLI-DYNAMIC/re-deploy --user admin:admin -d {"dry-run":{"outformat":"cli"}} --header "Content-Type:application/yang-data+json"</pre></div></div>2. Output from logs/trace_.traffic<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"><pre>POST /restconf/data//cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-policies:policies/policy=SR-CLI-DYNAMIC/re-deploy HTTP/1.1 Accept: */*^M Host: 127.0.0.1:8080^M User-Agent: curl/7.74.0^M Content-Length: 31^M Content-Type: application/yang-data+json^M Authorization: Basic YWRtaW46YWRtaW4=^M [2021-08-10 13:42:56.940] ===== CLI -> SRV ===== {"dry-run":{"outformat":"cli"}} [2021-08-10 13:42:57.327] ===== SRV -> CLI ===== HTTP/1.1 200 OK^M Date: Tue, 10 Aug 2021 20:42:56 GMT^M Cache-Control: private, no-cache, must-revalidate, proxy-revalidate^M Content-Length: 69^M Content-Type: application/yang-data+json^M X-Cisco-NSO-Trace-ID: 867356d5-7953-42da-af8d-d7720c8b4c19^M Pragma: no-cache^M Content-Security-Policy: default-src 'self'; block-all-mixed-content; base-uri 'self'; frame-ancestors 'none';^M Strict-Transport-Security: max-age=15552000; includeSubDomains^M X-Content-Type-Options: nosniff^M X-Frame-Options: DENY^M X-XSS-Protection: 1; mode=block^M ^M { "cisco-sr-te-cfp-sr-policies:output": { "cli": { } } }</pre></div></div>