The flow.xml.gz file which defines the flow does contain these paths. You could automate the flow change via Puppet (keeping in mind that other values will change as you modify NiFi flows via the canvas), or you could define these values as parameters [1] within NiFi and have each of the components reference those parameters in the path properties.
[1] https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#Parameters Andy LoPresto alopre...@apache.org alopresto.apa...@gmail.com He/Him PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Oct 15, 2020, at 7:45 AM, Michael Di Domenico <mdidomeni...@gmail.com> > wrote: > > On Wed, Oct 14, 2020 at 3:59 PM Nathan Gough <thena...@gmail.com> wrote: >> >> Is there a reason each ListenHTTP has a unique SSLContextService if they're >> all using the same certificates? >> >> If it were me, I'd use a single shared SSLContextService, and when I needed >> to update the certificate in the keystore/truststore, I would change it on >> disk by renaming the old file and putting the new file in place with the >> original name. Now NiFi and the context service refers to the updated >> certificates and no NiFi configuration changed. Does this work for you? > > Possibly. Its likely the sslcontext documentation wasn't clear when i > read it and didn't realize i could do this. > > and yes i came to same conclusion about symlinking the keystores on > the local filesystem, which should also work. > > ideally, these parameters would be managed via some xml file that i > could have puppet control. so when the certs change, puppet can push > out the changes and update everything. yes i can do this with a > symlink, but it's not my preferred method to declare the resources and > changes.
