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? > > Thanks, > > Mircea
Another question: The Raymond's patch uses replication mechanism to push certificates to secondary hosts. I really like this idea, but this opens a new question that I would like to clarify. In sipXconfig, the file replication mechanism transforms the file content into a base 64 encoded String, and pushes this content to a location. >From ReplicationManagerImpl: byte[] payloadBytes = outStream.toByteArray(); String content = encodeBase64(payloadBytes); FileApi api = m_fileApiProvider.getApi(locations[i].getProcessMonitorUrl()); success = api.replace(getHostname(), file.getPath(), PERMISSIONS, content); This would work fine for PEM certificates I suppose. I don't know if we already have support for DER certificates import, but I suppose that at least we will have in the future, and I think that it is not OK to take DER encoded content and make a String of it during replication. What do you think? Is there any replication support available for binary files, or we should go ahead and use current replication mechanism ? Thanks, Mircea _______________________________________________ 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/
