napalm-ios leaves "file prompt quiet" in startup configuration

[tjhannin]

Description of Issue/Question

Note: Please check https://guides.github.com/features/mastering-markdown/ to see how to properly format your request.

Did you follow the steps from https://github.com/napalm-automation/napalm#faq

(Place an x between the square brackets where applicable)

• [x] Yes
• [] No

Setup

napalm version

(Paste verbatim output from pip freeze | grep napalm between quotes below)

napalm==2.4.0

Network operating system version

(Paste verbatim output from show version - or equivalent - between quotes below)

Cisco IOS Software [Denali], ISR Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 16.3.6, RELEASE SOFTWARE (fc3)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2018 by Cisco Systems, Inc.
Compiled Wed 28-Feb-18 16:17 by mcpre

Steps to Reproduce the Issue

It looks like the IOS module leaves "file prompt quiet" in the startup configuration after a configuration merge operation. This seems to happen because the "no file prompt quiet" state is restored in the close function, and the commit_config function stores the configuration before the connection is closed.

The mismatch between running and startup configuration this leaves can then cause issues with other IOS functionality, such as automatic configuration saving when a PKI certificate is renewed.

[ktbyers]

Can you expand a bit on the this causes issues with other IOS functionality, such as automatic configuration saving when a PKI certificate is renewed?

Mostly as I am interested in knowing what the secondary consequences of this are (i.e. not saying the reported issue is not an issue).

[tjhannin]

Sure - the specific feature I have in mind is 'Certificate Autoenrollment with Key Regeneration'.

See https://www.cisco.com/c/en/us/td/docs/ios/ios_xe/sec_secure_connectivity/configuration/guide/convert/sec_pki_xe_3s_book/sec_cert_enroll_pki_xe.html: "autoenrollment will not update NVRAM if the running configuration has been modified but not written to NVRAM. "

So if there's been a configuration change that hasn't been stored, autoenrollment won't be able to store the certificate which then leads into issues if the router is reloaded. From past experience the change doesn't really need to be a change either - it's enough for something to have been changed and reverted back for the router to do this.

[ktbyers]

Okay, makes sense...thanks.