- Article Ref
- Written By
- Philip Slater
- Date Created
- Thu, 26th Jan 2012
- Updated By
- Josh Olson
- Date Modified
- Mon, 6th Feb 2012
CGP Startup Parameters: Documented/Undocumented & Startup.sh
How to change certain CGP behaviors automatically upon startup of CGP?
There are two items that must be read to understand the manner in which CGP starts up at launch.
The first article can be found at http://www.communigate.com/CommuniGatePro/SysAdmin.html#Options. This section primarily concerne standard startup parameters and explains what each one accomplishes.
The seceond is found at http://www.communigate.com/CommuniGatePro/Scalability.html. This covers a number of OS and tuning related options for the various supported OS's.
The main thing that one should gain from these articles is that while a number of these can be accomplished by editing files within the application directory or in the OS control panel, is that it is possible to create a Startup.sh file in the CGP Base Directory. By creating the Startup.sh, this means that you have a permanent file for the startup parameters as an upgrade to CGP destroys the modified application directory. This is highly recommended for any location running CGP Dynamic Clusers. This way the startup parameters are never affected by an upgrade.
There are also two undocumented, at this writing, startup parameters that have been needed after the release of 5.4.x
This one has been added as the workaround for problems accepting TLS connection requests from clients that used older versions og OpenSSL libraries and advertize support for some TLS extensions which are not really supported. Examples of this are financial institutions unable to send mail to your CGP server. Connection is made but TLS fails to negotiate. More on what the TLS Extensions are (and in turn what is disabled when you use the above parameter) can be found here: http://www.ietf.org/rfc/rfc3546.txt
This has been added as a workaround for the problem that some CallDAV clients have working with CGpro 5.4 that started to advertize the DAV "autosched" capability. Seeing it, the clients won't sent meeting requests when a new meeting is added to a calendar - expecting the server to do that. But the implementation seems to be incomplete and the server does not sent the invitation. With this option use for CGPro startup, the "autosched" capability is not advertized and the CalDAV clients submit invitation e-mails themselves.
There are currently no comments.