smaller reset larger        English         

Main Menu

All times are in GMT -8 (DST) :: The time is now 4:57 am.

Sub Menu

Article Data
Article Ref
2558-RPGZ-2772
Written By
Philip Slater
Date Created
Thu, 26th Jan 2012
Updated By
Josh Olson
Date Modified
Mon, 6th Feb 2012
 
(Lost?)

   CGP Startup Parameters: Documented/Undocumented & Startup.sh

Question 

How to change certain CGP behaviors automatically upon startup of CGP?

Answer 

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

 

--TLSServerHelloExtensions NO

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

 

--CalDAVAutoSched NO

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.

How Useful Was This Article?      (Rating: 100%    Votes: 70)  

Select a Rating

Article Comments 

There are currently no comments.