Do's and Don'ts during installation/upgrade

Here’s a list of dos, don’ts and points to remember when you install or upgrade TeamForge.

• Understand TeamForge installation requirements.
• Get your TeamForge license key and keep it handy.
• Installing or upgrading TeamForge needs root privileges. You must log on as root or use a root shell to install or upgrade TeamForge.
• Verify your basic networking setup before installing or upgrading TeamForge. See Set up Networking for TeamForge.
• If you have SELinux in "enforcing" mode, you must either disable SELinux or switch to "permissive" mode (recommended) before running the /opt/collabnet/teamforge/bin/teamforge provision command. TeamForge create runtime fails otherwise.
• SSL is enabled by default and a self-signed certificate is auto-generated. However, you can use a few site-options.conf tokens to adjust this behavior. To generate the SSL certificates, see Generate SSL certificates.
• Do not customize your operating system installation. Select only the default packages list.
• You need to add the SSL certificate to the Java keystore if the site uses a self-signed certificate. For instructions on adding the self-signed certificate to the Java keystore, see Protect Integrations with SSL.
• For the ETL service to run as expected in a distributed TeamForge installation, all servers must have the same time zone.
• If you have Git integration on a separate server, both TeamForge and Git servers must have their time and date synchronized.
• While you can run both EventQ and TeamForge on the same server, CollabNet recommends such an approach only for testing purposes. It’s always recommended to run EventQ on a separate server for optimal scalability.
• Look for new or modified site-options.conf tokens and update your site-options.conf file as required during the upgrade process. See Site Options Change Log.
• Do not manually modify TeamForge-managed site option tokens such as the AUTO_DATA token. See . for more information.
• No backup is required for same hardware upgrades. However, you can create a backup as a precaution. See Backup and Restore TeamForge and EventQ for more information.
• Always use compatible JDBC drivers meant for specific database versions. See JDBC Drivers Reference for more information. Also see: Why do ETL jobs fail post TeamForge upgrade?
• You can run the initial load job any time after the installation of TeamForge. We recommend that you run it before you hand over the site to the users. For more information, see When do I run the initial load job?
• Set up a TeamForge Stage Server before you upgrade your Production Server.
• Stop TeamForge services on all servers in a distributed setup while upgrading to TeamForge 17.4.
• Uninstall hot fixes and add-ons, if any, before you start the TeamForge 17.4 upgrade procedure.
• SOAP50 APIs and event handlers are no longer supported in TeamForge 16.10and later. Use the latest TeamForge SOAP/REST APIs.
• TeamForge installer has been optimized quite a bit. It’s likely that you might come across a lot of warning messages while upgrading from TeamForge 16.3 (or earlier) to TeamForge 17.4 on the same hardware (when you run the yum install teamforge command). You can safely ignore such warning messages and proceed with the upgrade.
• TeamForge 17.4 installer expects the system locale to be LANG=en_US.UTF-8. TeamForge create runtime (/opt/collabnet/teamforge/bin/teamforge provision) fails otherwise.