Mircea wrote: >Subject: Re: [sipX-dev] XX-7213: HA - Install of new >certificate authoritiesneeded on Distributed Servers as well >// Question > >On Tue, Feb 23, 2010 at 12:11 PM, Mircea Carasel ><[email protected]> wrote: >> Hi, >> >> During patch review, I noticed that after the certificate is >pushed to >> secondary hosts, sipXecs from these hosts is restarted. >> >> I am wondering if this is really needed or not. >> >> Based on discussions and agreements here: >> http://list.sipfoundry.org/archive/sipx-dev/msg21469.html >> >> we decided only to mark for restart the services (java >based) that may >> need the newly imported certificate (From Scott I understood that: >> C/C++ based services don't need restart in order to pick/use a new >> certificate) >> >> For instance, for the primary host, where sipXconfig runs >> (configuration service) we identified for restart the configuration >> service and SIP Trunking (sipXbridge) service. >> >> I believe that the same approach should be taken also for secondary >> hosts. We should identify what services we need to mark for restart >> and that's all. >> >> Please let me know what do you think. Also, what other >services do you >> think we should mark for restart, besides SIP Trunking? >> The Master server is slightly different than the distributed servers in that it can issue commands to do a rehash (needed for Openssl to recognize new authorities) of the Authorities directory as well as regenerate the Java Keystores/Truststore directly. We don't have this luxury (at least today) to do this on the distributed servers so in order to trigger the rehash of the Authorities directory and regeneration of the Java Keystores and Truststore, I restart (not reboot) SipXecs using the SwAdminApi restart capability I introduced a while back. The restart will automatically perform the rehash and regeneration for us as its done on every startup.
I believe that in the future, we should have some sort of mechanism in sipXconfig to indicate a restart (or even reboot) of a server is required much like we do today for services but at a higher level. If this capability were in place, we could avoid the restart until they trigger it from sipXconfig. In addition, this could allow us to import a number of new Certificate Authorities and then do a restart as opposed to a restart after each new one is added. Raymond _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
