> On 17. Jan 2018, at 12:00, Edgar Fuß <e...@math.uni-bonn.de> wrote: > > I don't quite get why the ApiListener object attributes cert_path, key_path > and ca_path have been deprecated. I can understand why defaults may have been > moved, but why shouldn't I be allowed to override the defaults? > About any other server with SSL support allows me to configure where to put > the certificates and keys, why does Icinga2 want to make this impossible?
This is a matter of a smooth upgrade migration with literally no user action involved during a package update. You cannot expect that Icinga 2 just stops during “apt-get upgrade” for example, if the certificate paths are not intact. Neither do we have access to these configuration attributes and may change them during an upgrade. Moving away from those paths and ensuring that Icinga 2 can **write** its own certificates is the motivation. Believe me, this has been discussed for many days and weeks before implementing a new default path, which can be instrumented with the NodeName constant only. We didn’t have much better ideas during the design and development process which was fully visible and transparent on GitHub. There were no other obligations or suggestions made by users, so we have implemented it this way. The key fact here is that Icinga 2 has an asynchronous way of fetching certificates after the initial setup. This goes even further, it now also has a built-in mechanism to automatically renew certificates which would expire or if they are broken (that affects certificates created with clients < 2.4). > > I also don't understand how 2.8 will behave if I do configure these > attributes, but set them to non-standard values neither matching the old > defaults nor the new ones. If you keep these deprecated configuration settings, Icinga 2 will copy the certificates to the new location on startup. That’s the migration path we came up with during the design of this huge feature (CA proxy and certificate renewal). The reason for a built-in mechanism also is Windows where accompanied bash scripts won’t work. Windows clients must be fully operable after an upgrade as well. More on that can be read in the upgrading documentation: https://www.icinga.com/docs/icinga2/latest/doc/16-upgrading-icinga-2/#changed-certificate-paths and for reference, the release blog post: https://www.icinga.com/2017/11/17/icinga-2-v2-8-0-released/ Kind regards, Michael _______________________________________________ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
