Administering the Platform - Documentation - Jive Software

newshumansvilleΔιαχείριση Δεδομένων

16 Δεκ 2012 (πριν από 4 χρόνια και 10 μήνες)

503 εμφανίσεις

Platform Administration
| TOC | 2
Contents
Administering the Platform............................................................................................................4
Jive Platform Overview.........................................................................................................................................4
System Components..................................................................................................................................4
List of Required Ports and Domains.........................................................................................................5
Platform Conventions, Management and Tools........................................................................................7
What Happened to jiveHome?..................................................................................................................9
Jive Security........................................................................................................................................................10
Security and Internal Development Processes........................................................................................10
In-product Security Features...................................................................................................................11
Jive and Cookies......................................................................................................................................14
Security of Public Cloud Communities...................................................................................................17
Security of Private Cloud Communities..................................................................................................17
Security of Cloud-Delivered Services.....................................................................................................18
Security Recommendations.....................................................................................................................19
Security FAQ...........................................................................................................................................21
Platform Run Book (Linux)................................................................................................................................23
Jive HTTPD.............................................................................................................................................23
Jive HTTPD Networking.........................................................................................................................24
Jive HTTPD Log Files............................................................................................................................24
Jive-Managed Applications.....................................................................................................................25
Jive Database Server...............................................................................................................................27
Operations Cookbook..........................................................................................................................................29
Enabling SSL Encryption........................................................................................................................29
Configuring a Persistent Session Manager..............................................................................................29
Forcing Traffic to HTTPS.......................................................................................................................30
Restricting Admin Access by IP.............................................................................................................30
Disabling the Local Jive System Database..............................................................................................30
Changing the Configuration of an Existing Instance..............................................................................31
Performing a Jive System Database Backup...........................................................................................32
Performing Database Maintenance.........................................................................................................32
Backup and Storage Considerations........................................................................................................32
Using an External Load Balancer............................................................................................................34
Enable Application Debugger Support....................................................................................................34
Setting Up Document Conversion...........................................................................................................34
Configuration Support for External Client Access..................................................................................35
Adding Fonts to Support Office Document Preview..............................................................................36
Monitoring Your Jive Environment....................................................................................................................36
Basic Monitoring Recommendations......................................................................................................36
Advanced Monitoring Recommendations...............................................................................................40
Fine-Tuning Performance....................................................................................................................................41
Client-Side Resource Caching.................................................................................................................41
Server-Side Page Caching.......................................................................................................................41
Configuring External Static Resource Caching.......................................................................................42
Adjusting the Java Virtual Machine (JVM) Settings..............................................................................43
Performance Tuning Tips........................................................................................................................45
Search Index Rebuilding.........................................................................................................................45
Using a Content Distribution Tool with Jive..........................................................................................46
Clustering in Jive.................................................................................................................................................48
Clustering Best Practices.........................................................................................................................49
Clustering FAQ.......................................................................................................................................49
Managing an Application Cluster............................................................................................................50
| TOC | 3
In-Memory Caching............................................................................................................................................51
Parts of the In-Memory Caching System................................................................................................51
How In-Memory Caching Works............................................................................................................51
Cache Server Deployment Design..........................................................................................................52
Choosing the Number of Cache Server Machines..................................................................................52
Adjusting Cache-Related Memory..........................................................................................................53
Managing In-Memory Cache Servers.....................................................................................................53
Configuring In-Memory Caches.............................................................................................................54
Clustering and In-Memory Caching: Rationale and Design for Changing Models................................55
Troubleshooting Caching and Clustering................................................................................................58
Application Management Command Reference.................................................................................................59
appadd Command....................................................................................................................................60
appls Command.......................................................................................................................................62
apprestart Command................................................................................................................................62
apprm Command.....................................................................................................................................62
appsnap Command..................................................................................................................................63
appstart Command...................................................................................................................................63
appstop Command...................................................................................................................................64
appsupport Command..............................................................................................................................64
dbbackup Command................................................................................................................................65
manage Command...................................................................................................................................65
upgrade Command..................................................................................................................................66
| Administering the Platform | 4
Administering the Platform
Learn how to administer and manage the platform. This section includes run books, configuration information, and
performance tuning help.
Jive Platform Overview
The platform introduced in version 3 includes important changes that affect the way you install and administer the
application. This topic provides an overview of those changes, the platform, and the tools that come with it.
Through a design that supports a more focused set of components (in particular, application server and database
servers), the platform provides a standard, reliable, and better-integrated environment that makes it easier to optimize
the applications deployed on it. The platform -- especially its deployment as an package -- also makes installation
much easier by removing the need to follow instructions (including component-specific issues and limitations)
specific to particular combinations of application server, DBMS, and so on.
Note: If you're upgrading, Jive Software provides tools for migrating your existing deployment. Be sure to
see the Installation Guide for more on Migrating Data from an Unsupported DBMS and the contents of your
jiveHome directory.
Here's a high-level list of the things that are new or changed with the platform's introduction:
• System Components were chosen to create an integrated, standard platform that can be more fully optimized.
• Database server support was tuned to the PostgreSQL and Oracle DBMSes.
• Application server support is optimized to the Apache Tomcat instance included with the platform. Other
application servers aren't supported.
• Supported operating systems include Red Hat and SuSE Enterprise Linux.
• Tools were included to make managing the application easier and more reliable.
• The jiveHome directory became the jive.instance.home environment variable.
Related Content
You might be interested in other documentation related to the platform. The following topics include references and
guides for making the most of the platform and applications installed on it.
Document
Description
Platform Run Book (Linux)
Basic system commands for managing the platform. If you need to handle
something quickly, start here.
Operations Cookbook
Sample configurations and script examples for long-term operations.
Application Management
Commands
A reference for commands you can use to maintain your managed instance.
System Requirements
System components and technologies supported in this release.
Installing
Step by step instructions for installing the platform.
Upgrading
Step by step instructions for upgrading the platform.
System Components
The Jive platform consists of several high-level components that work together to provide overall system
functionality. The following sections provide an overview of these components and their role in the architecture. By
default, the platform will install the following components to start and stop in the correct order during system startup
and shutdown.
| Administering the Platform | 5
Apache HTTPD Server
The platform contains a customized version of the Apache Foundation’s Apache HTTPD web server software.
Among other things, this software is used to process HTTP and HTTPS-encrypted requests between the platform
and end users. The Apache HTTPD server uses the JK protocol to communicate with the back-end application server
described in the next section.
Tomcat Application Server
The Apache Tomcat application server is used to host back-end application and business logic as well as to generate
dynamic HTTP traffic served by the Apache HTTPD Server. The application server is also responsible for processing
email delivered by the system, and for scheduling background tasks such as search index management and integration
with third-party applications and systems.
PostgreSQL Database Server
The PostgreSQL database server is an RDBMS (Relational Database Management Server) service that is hosted
internally within the platform. You can use this service or a PostgreSQL or Oracle system of your own.
Important: The pre-packaged PostgreSQL DBMS is for evaluation purposes and should not be used for
production instances.
Jive System Configuration
As part of the platform installation, the Jive package will tune various settings such as shared memory and maximum
file handles. The details of these changes can be found in the “jive-system” script, located in the standard “/etc/init.d”
directory.
List of Required Ports and Domains
The following tables show the ports you need to open in order to enable key Jive components. For services that are
hosted by Jive, you also need to ensure access to certain domains or IP addresses. These addresses are shown where
required.
Jive Core Components
Component
Port(s)
Direction
Domain(s) or
IP(s)
Jive - Tomcat
• HTTP monitor port: 9000 (does
not need to be opened outside)
• Server port: 9100 (does not need
to be opened outside)
• HTTP port: 9200 (does not need
to be opened outside)
• JMS port: 61616 (required for
DocVerse, but needed on only
one node)
Open
Jive - Apache
HTTP port: 80
Open and public-
facing
Activity Engine
7020
Open
JMX
7021
Open
Jive Genius Recommender Service
443
Open
in.genius.jivesoftware.com,
out.genius.jivesoftware.com
Analytics
none
Inbound
| Administering the Platform | 6
Component
Port(s)
Direction
Domain(s) or
IP(s)
Jive Apps Market
none
n/a
market.apps.jivesoftware.com,
gateway.jivesoftware.com,
apphosting.jivesoftware.com,
developers.jivesoftware.com
Licensing
443
Outbound
https://
license.jivesbs.com
Cluster Node Communication
• Do not put a firewall between your cache servers and your Jive application servers. If you do so, caching will not
work. A firewall is unnecessary because your application servers will not be sending untrusted communications
to the cache servers, or vice versa. There should be nothing that might slow down communication between the
application servers and the cache servers.
• All ports between the cache and web application servers must be open.
• Port 6650 should be blocked to external access (but not between the cluster nodes!) so that any access outside
of the datacenter is disallowed. This is to prevent operations allowed by JMX from being executed on the cache
server.
Databases and Database Servers
Component
Port(s)
Direction
Database - PostgreSQL
5432
Open/bidirectional
Database server - SQL
1433
Open/bidirectional
Database server - MySQL
3306
Open/bidirectional
Database server - Oracle
1521
Open/bidirectional
Jive Plugins (all optional)
Component
Port(s)
Direction
Domain(s) or IP(s)
Document Conversion
• Jive Document
Conversion Daemon
(JDCD): 8200
• Jive OpenOffice
Daemon: 8850 (older
versions) or 8300 (newer
versions)
• OpenOffice: 8820, 8821,
8822, 8823, 8824
• JDCD callback: 80
Open
Jive Connects for Office
80 or 443 (we recommend
using 443 to transmit
content)
Open
Jive for SharePoint
443
Inbound to public SSL-
enabled VIP for Jive
instance
Mobile (all locations,
including EMEA)
443 if you use SSL, 80 if not
Inbound to Jive instance
out.jive-mobile.com
(204.93.64.112)
| Administering the Platform | 7
Component
Port(s)
Direction
Domain(s) or IP(s)
Mobile (all locations,
including EMEA)
443
Outbound from Jive
instance
gateway.jive-mobile.com
(204.93.64.255 and
204.93.64.252)
Mobile (EMEA only)
443 if you use SSL, 80 if not
Inbound to Jive instance
213.212.109.84
Openfire
9090 and/or 9091
Open
Video
1935 (RTMP) (if this is not
available, then use port 80)
(RTMPT)
Open/outbound
80 and 443 to a
specific IP range (for
example, 208.122.31.1 -
208.122.31.250)
Open/inbound
208.122.47.241
208.122.47.242
208.122.47.243
74.63.51.50
74.63.51.55
Platform Conventions, Management and Tools
The "jive" User
By default, Jive will attempt to install a local system user named “jive” belonging to group “jive” with a home
directory of “/usr/local/jive”. If a user named jive already exists on the system where the installation is being
performed, the platform will use the existing user. Most binaries, scripts and configurations used by the platform are
owned by the jive user with a small number of files owned by root.
Application Abstractions
The Jive platform is designed to manage one or more logical “application” servers, each serving a variety of
functional concerns.
Master Application Template
The master application template is the core set of Jive software used to create all subsequent instances. By
convention, the files in the master template are stored in the jive user’s “applications” directory located at:
/usr/local/jive/applications/template
Application Instances
Upon installation, and at the request of system administrators, the platform will create instances of the master
application template, each with a unique name. Each instance is managed, configured and runs independently of
other applications. By design, an instance of an application runs in a dedicated operating system process, providing
separation between applications such that one application instance cannot directly exhaust the resources of another in
a way that cannot be stopped with standard operating system commands (such as kill).
Managed Application Instances
An application instance is considered managed if it is created, updated, and its lifecycle controlled by the platform
tooling (appadd, appstop, appstart, etc.). Managed applications are automatically upgraded when the platform is
upgraded.
In some circumstances, you might want to create applications that are not fully managed. For example, applications
created with the “—no-link” options to the appadd tool will not be directly upgraded by platform upgrades. Non-
managed applications are not directly upgraded by the Jive tooling and must be upgraded manually by a system
administrator.
| Administering the Platform | 8
System Management Tools
Ultimately, most Jive tools delegate to standard Linux systems management tools such as bash scripts, the “ps”
command, and so on. It is possible to monitor Jive-managed components using standard tools such as ps and top as
described in the Platform Run Book (Linux).
Database Management Tools
When using the local database (installed as part of Jive) as the system of record for a deployment, the platform will
make an attempt to tune and back up the underlying database. While sufficient for smaller databases, larger databases
will have storage and backup considerations unique to their individual deployments; you'll likely want to alter the
platform defaults.
Auto Backups
Upon installation, the Jive platform database is scheduled for daily full backups via an entry in the cron.daily section
of the system cron task scheduler. Specifically, the installation process creates a symlink that maps /usr/local/jive/bin/
dbmaint to /etc/cron.daily/jive-dbmaint. This script performs a full analysis and backup of the contents of the local
database. Backups are stored to /usr/local/jive/var/data/backup/postgres/full and are stamped with the date that the
backup began. Logs for the backup and maintenance are stored in the standard platform location at /usr/local/jive/var/
logs, in files dbmaint.log, dbback.log and dbanalyze.log.
In addition to full backups, the platform captures PostgreSQL WAL (Write-Ahead Log) segments to /usr/local/jive/
var/data/backup/postgres/wal. For more information about WAL segments, see the PostgreSQL documentation.
Important: The pre-packaged PostgreSQL DBMS is for evaluation purposes and should not be used for
production instances.
Database Storage Considerations
The platform backup infrastructure will purge full backups that are 30 days or more old. The platform will not purge
WAL segment backups described in the previous section. As a general rule, you can safely remove WAL segments
older than the most recent full backup. You should keep WAL segments since the previous full backup so that you
have it for a partial recovery of the database in the event of corruption.
System administrators should evaluate the storage capacity of their systems and the size consumption to arrive at the
best strategy for purging backup files.
Application Management
The platform manages one or more instances of the Jive software. Each instance represents a dedicated Apache
Tomcat application server that ultimately runs as a dedicated server process, independent of other application
servers on the host machine. By convention, each application instance is represented by a directory entry beneath the
“applications” directory located in the jive user’s home directory (/usr/local/jive/). For example, an application named
“biodome” will have a corresponding application directory located at:
/usr/local/jive/applications/biodome
Each application has a standard set of subdirectories beneath its top-level application directory:
• <app_name>/bin – Scripts and environment configuration used by this instance. Notably:
• manage – Used to start, stop and restart the application server instance in a graceful manner and intended to
minimize the possibility of data loss.
• setenv – Script for failsafe environment configuration invoked by the manage script. This script should not be
edited except under the direction of Jive support.
• instance – Per-instance configuration information. The contents of this script customize the environment for
the named application instance. For example, to change the HTTP address the application server listens on, the
platform will write shell script environment variables to this file.
• <app_name>/conf – Application server runtime configuration files as well as container logging configuration
(log4j.properties)
| Administering the Platform | 9
• <app_name>/home – Application instance home directory. This directory represents the instance-specific storage
for items such as search indexes, local file system caches, plugin caches, and database configuration.
• <app_name>/application – Commonly a symbolic link to the shared Jive application binaries. If an application
instance is created by the appadd tool with the “–no-link” option, the application directory will be a full copy of
the shared application binaries at the time the application was created and will not be upgraded during a package
upgrade.
Troubleshooting and Snapshot Utilities
The Jive platform installation captures meaningful system data to various log files as well as providing application
and system snapshot capabilities. With these, Jive support can more easily diagnose issues with the platform.
Support Information Gathering
The primary mechanism for gathering support-related information on the platform is via the appsupport command,
typically executed as the jive user.
When run, the appsupport command will combine multiple useful data points from the system and application logs,
then aggregate the data to the console’s standard output stream. Alternatively, you can use the “-o” flag, along with
the path to a file where the aggregate system information should be appended (if the file does not exist, it will be
created).
System Thread Dumps
In some cases, Jive support may suggest that you capture application thread dumps from a running system. The
platform includes the appsnap tool for this purpose. As with other commands, appsnap is commonly performed as the
jive user.
The most common options used with the appsnap tool are the "—count" and "—interval" options. Count determines
the number of samples taken. The interval option determines the number of seconds between successful samples. The
tool writes snapshot output to the console’s standard output or appends it to the file given for the "-o" option.
What Happened to jiveHome?
If you're upgrading from a version prior to version 3, you might wonder about the jiveHome directory. The jiveHome
directory was where you put (and found) the working files for your community. Caches, themes, plugins, logs -- that
sort of thing.
As of version 3, the jiveHome directory is replaced by the jive.instance.home environment variable. Each instance
depends on three environment variables to identify its place in the bigger picture of its environment:
• jive.home -- The root of all Jive software on the filesystem. Shared resources like Apache and Tomcat binaries are
found here, as are individual instances.
• jive.name -- Unique, human-readable identifier of an instance within the local deployment (and importantly, not
across all deployments); this value influences where the instance lives in a managed deployment (i.e., platform)
and various other subtle artifacts like log file names.
• jive.instance.home -- Previously jiveHome. This is where the application puts working files, including caches,
plugins, themes, etc. For example, by default this would be /usr/local/jive/applications/sbs/home/.
When you migrate your application to the platform, the contents of the jiveHome directory are distrbuted to places
that are better suited to the platform. The following table list the new locations of resources previous found in
jiveHome.
Important: The pre-packaged PostgreSQL DBMS is for evaluation purposes and should not be used for
production instances.
Resource
Location Prior to Version 3
Location in the Platform
Application logs (including those
for database backups)
<jiveHome>/logs
/usr/local/jive/var/logs
| Administering the Platform | 10
Resource
Location Prior to Version 3
Location in the Platform
Installed plugins
<jiveHome>/plugins
/usr/local/jive/applications/<app_name>/
home/plugins
User-created themes
<jiveHome>/themes
/usr/local/jive/applications/<app_name>/
home/themes
Cached attachments
<jiveHome>/attachments
/usr/local/jive/applications/<app_name>/
home/attachments
Cached images
<jiveHome>/images
/usr/local/jive/applications/<app_name>/
home/images
Cached data
<jiveHome>/cache
/usr/local/jive/applications/<app_name>/
home/caches
Resources directory
<jiveHome>/resources
/usr/local/jive/applications/<app_name>/
home/resources
Local system database
<jiveHome>/database
/usr/local/jive/var/work/sbs/data/postgres-8.3
jive_startup.xml file
<jiveHome>/jive_startup.xml
/usr/local/jive/applications/<app_name>/
home/jive_startup.xml
Setting jive.instance.home
Jive uses the following convention to determine where jive.instance.home actually exists on the file system. These
rules follow the general notion of more to less specific -- for example, if a user has gone to the trouble of specifying a
JNDI property for the home directory, honor that over a more generic system property, honor that over a more generic
environment property.
1.JNDI environment property named "jive.instance.home" in the context "java:comp/env/"
2.System property named "jive.instance.home"
3.JNDI legacy environment property named "jiveHome" in the same context as #1
4.System property named "jiveHome"
5.Default to OS default (/usr/local/jive/applications/${name}/home or c:\jive\applications\${name}\home} -
${name} is described above represents the -Djive.name property with a default of "sbs"
Jive Security
Deployed inside or outside firewalls, Jive's security and privacy features are designed to meet the requirements of the
most tightly regulated global industries and government agencies. Jive Software continually evaluates the security of
current and past product versions to protect your organization's data.
Jive Software makes every effort to protect the confidentiality, integrity, and availability of its public and private
cloud communities, as well as its cloud-delivered services.
Jive Software's public cloud platform, private cloud platform, and cloud-delivered services use the same core data
center architecture and security model.
Note: This security section describes only the Jive application. It does not describe the security features of
third-party products.
Security and Internal Development Processes
Throughout the product development lifecycle, application security is continuously tested and improved.
Jive Software audits all new feature designs for high-level security considerations. Implementations of these features
are validated for potential security issues throughout the development phase. Existing features are audited for security
| Administering the Platform | 11
vulnerability regressions. Application-wide audits are performed to ensure that feature integration is secure. Third-
party components used by Jive are researched and tracked over time for vulnerabilities and license compliance.
Development includes the following security checks:
• Source code reviews - if you'd like to see screenshots from our source code review tool, contact your Jive
Software representative.
• Automated penetration testing - each release of the application is tested with IBM's state-of-the-art security
product, AppScan. In addition, we offer AppScan test results from your instance. Contact your Jive Software
representative about this service.
• Vulnerability management - Jive Software relies on its own documented release procedure to manage
vulnerabilities, which includes a timeline for fixing issues, communicating them to customers, and providing
patches.
• Third-party audits - Jive Software performs annual audits across the core product for each hosted service,
including black box and white box analyses. If you would like to see these reports, please contact your Jive
Software representative.
In-product Security Features
Several built-in security features allow you to configure your Jive community for the appropriate level of security for
your organization.
Authentication Features
Login Security
Using the Admin Console, you can configure Jive
to strongly discourage automated (computer-driven)
registration and logins. Automated registration is usually
an attempt to gain access to the application for malicious
reasons. By taking steps to make registering and logging
in something that only a human being can do, you help
to prevent automated attacks. We recommend using the
following tools, all of which are available as options in
the Admin Console:
• Login Throttling: Enabling login throttling slows
down the login process when a user has entered
incorrect credentials more than the specified number
of times. For example, if you set the number of failed
attempts to 5 and a forced delay to 10 seconds and
a user fails to log in after more than 5 attempts, the
application would force the user to wait 10 seconds
before being able to try again.
• Login Captcha: Enabling login Captcha will display a
Captcha image on the login page. The image displays
text (distorted to prevent spam registration) that
the user must enter to continue with registration.
This discourages registration by other computers
to send spam messages. The login Captcha setting
is designed to display the Captcha image when
throttling begins. In other words, after the number of
failed attempts specified for throttling, the Captcha
image is displayed and throttling begins. You cannot
enable the login Captcha unless login throttling is
enabled. The Captcha size is the number of characters
that appear in the Captcha image, and which the user
must type when logging in. A good value for this is 6,
which is long enough to make the image useful, but
short enough to make it easy for real humans.
| Administering the Platform | 12
• Password Strength: You can choose to enforce strong
passwords via the Admin Console. The following
options are available out of the box:
• a minimum of 6 characters of any type
• a minimum of 7 characters including 2 different
character types (uppercase, lowercase, number,
punctuation, and/or special characters)
• a minimum of 7 characters including 3 different
character types
• a minimum of 8 characters, including all 4
character types
To learn more about configuring login and password
security, see Configuring Login Security and Configuring
User Registration.
Email Validation
You can configure Jive to require email validation for
all new accounts. This setting helps to prevent bots from
registering with the site and then automatically posting
content. When you configure email validation, Jive will
require a new user to complete the registration form and
retrieve an email with a click-through link to validate
their registration. To learn how to enable this setting, see
Configuring User Registration.
Account Lockout
Jive does not offer account lockout as an out-of-the-box
feature. However, you can configure Jive to authenticate
against a thirty-party IDP that will perform account
lockout. If this is not something you want to implement,
you can request the account lockout feature from Jive's
Professional Services team as a customization.
SSO
As of Jive 5.0, the application includes support for
SAML out-of-the-box and can also be implemented as
a customization from Jive's Professional Services team,
a Jive partner, or an engineer of your choice. Be sure to
read Getting Ready to Implement SAML SSO.
Delegated Authentication
When delegated authentication is enabled and
configured, Jive makes a simple Web Service call out
to the configured server whenever a user attempts to log
in. This allows administrators to control the definition
of users outside of the community. To learn more about
this, see Configuring Delegated Authentication.
Authorization Features
Jive includes powerful built-in end user and admin permissions matrices, as well as customizable permissions.
Depending on the assigned role, users can see or not see specific places and the content posted there. In addition,
administrative permissions can be used to limit the access level of administrators. Jive administrators control user
and admin permissions through the Admin Console. To learn more about how permissions work, see Managing
Permissions.
Moderation and Abuse Features
Moderation
Jive administrators can enable moderation so that
designated reviewers view and approve content before
| Administering the Platform | 13
it is published in the community. This can be useful for
places that contain sensitive information. In addition
to content moderation, administrators can enable
moderation for images, profile images, avatars, and
user registrations. For more about moderation, see
Moderating Content.
Abuse Reporting
Administrators can enable abuse reporting so that users
can report abusive content items. To learn more about
abuse reporting, see Setting Up Abuse Reporting.
Banning Users
Administrators can block a person's access to Jive so that
they are no longer able to log in to the community. For
example, if someone becomes abusive in their messages
(or moderating their content is too time-consuming),
administrators may choose to ensure that the user can no
longer log in. Users can be banned through their login
credentials or their IP address. Be sure to read Banning
People for more information.
Interceptors
Interceptors can be set up to perform customizable
actions on incoming requests that seek to post content.
Administrators can set up interceptors to prevent specific
users from posting content or to filter and moderate
offensive words, anything from specific IP addresses,
or the posting frequency of specific users. To learn
more about how interceptors work, see Configuring
Interceptors.
Encryption
HTTPS and Browser Encryption
You can configure Jive to encrypt HTTP requests using
SSL. Documentation and instructions for configuring
SSL is available in Enabling SSL Encryption.
Additionally, you can configure Jive to use three
different HTTP/HTTPS configurations:
• Allow both HTTP and HTTPS
• Force HTTPS
• Force HTTPS on secure pages (login, registration,
change password, etc.)
Data Encryption
Jive supports anything the JVM does at the application
level and anything OpenSSL does at the HTTPD level.
We actively use Blowfish/ECB/PKCS5P, AES-256
for symmetric key encryption, SHA-256 for one-
way hashing, and we support and recommend Triple-
DES ciphers at the HTTPD server for TLS encrypted
channels.
• SHA-256 -- Jive user passwords are stored in the
database as salted SHA-256 hashes.
• AES-256 -- Bridging credentials, License Metering
information, and iPhone UDIDs are all encrypted
with AES-256.
| Administering the Platform | 14
• Blowfish/ECB/PKCS5Padding -- Used for storing
LDAP administrator credentials and OpenSearch
credentials in the database.
Cookies
Jive uses HTTP cookies in several places in the application to provide a better user experience. To learn more about
how the application uses cookies, be sure to read Jive and Cookies.
Note: The Jive Professional Services team can deliver security customizations if the out-of-the-box security
features do not meet the specific requirements of your organization.
Jive and Cookies
Jive uses HTTP cookies in several places in the application to provide a better user experience.
Jive does not set third-party cookies as part of the core product offering; however, it is possible for you to configure
the application so that third-party cookies are set. For example, you can configure the application to use a Web-
tracking tool such as Google Analytics or Webtrends, each of whom may set a third-party cookie.
Jive does not set the "domain" attribute of an HTTP cookie.
Starting with Jive version 4.5.7, all Jive cookies that are set by the server (not via the client or browser) have the
HttpOnly flag.
Setting Up Secure Cookies
Out of the box, Jive is not configured to set the "secure" attribute for cookies that should only be sent via HTTPS
connections. You can configure Jive to send only allowed, secure cookies through the following process:
1.Set the Jive system property "jive.cookies.secure" to the value "true". This results in all Jive-specific cookies
(not including JSESSIONID) having the "secure" attribute set on the cookie (Admin Console: System >
Management > System Properties).
2.Configure both Apache and Tomcat to only allow HTTPS connections. To understand these configurations, see
Forcing Traffic to HTTPS and Enabling SSL Encryption.
3.Finally, configure Tomcat with the "secure" attribute set to "true" in the server.xml configuration file,
specifically the "server/connector" element.
How Jive Sets Cookies
Jive performs an audit by searching for all instances of "setCookie" in the source code, and then sets the following
cookies.
Note: Except where noted, all of the following cookies do not contain user-identifiable information. This
behavior meets European Union privacy laws.
SPRING_SECURITY_REMEMBER_ME_COOKIE
This cookie is used on the front-end as part of the
security authentication process to denote whether or not
the user wants to have their credentials persist across
sessions. It is part of the Spring Security specification;
details are available here.
• Possible values: string, the Base64 encoded username
and expiration time combined with an MD5 hex
hash of the username, password, expiration time, and
private key.
• Expiration: defaults to 14 days.
• Encryption: none. This is an MD5 hex hash.
| Administering the Platform | 15
• Example:
SPRING_SECURITY_REMEMBER_ME_COOKIE="YWFyb246MTMxNTU4MjUzNTI3MDoyZDUyODNmZjhhNjExZTdlMTcyMGZhYjVhNWNkNjI0Yg"
JSESSIONID
This cookie is used on the front-end and the Admin
Console to identify a session. It is part of the Java Servlet
specification.
• Possible values: string, the unique token generated by
Apache Tomcat.
• Expiration: at session end.
• Encryption: none.
• Example:
JSESSIONID="1315409220832msB9E3A98AA1F2005E61FA975963FA4D12.node01"
jive.server.info
This cookie is used on the front-end in combination with
Content Distribution Networks (CDN) like Akamai to
associate the user with a specific server (also known as
"session affinity").
• Possible values: string, a combination of the
serverName, serverPort, contextPath, localName,
localPort, and localAddr.
• Expiration: at session end.
• Encryption: none.
• Example:
jive.server.info="serverName=community.example.com:serverPort=443:contextPath= :localName=localhost.localdomain:localPort=9001:localAddr=127.0.0.1"
jive.user.loggedin
This cookie is used on the front-end in combination with
Content Distribution Networks (CDN) to denote the
status of the current request.
• Possible values: string, true if the current request
originates from a browser where the user is logged in.
• Expiration: at session end.
• Encryption: none.
• Example: jive.user.loggedin="true"
jive_wysiwygtext_height
This cookie is used on the front-end to persist the height
of the editor window across sessions.
• Possible values: integer, the height in pixels of the
editor after the user chooses to expand the editor
window.
• Expiration: one year.
• Example: jive_wysiwygtext_height="500"
jive_default_editor_mode
This cookie is used on the front-end for guest/anonymous
users who choose to use an editor mode other than the
default editor mode.
• Possible values: string, advanced.
• Expiration: 30 days.
• Encryption: none.
• Example: jive_default_editor_mode="advanced"
clickedFolder
This cookie is used in the Admin Console to persist the
open/closed status of the current folder as used in various
tree-view portions of the Admin Console.
| Administering the Platform | 16
• Possible values: string, true, or false.
• Expiration: at session end.
• Encryption: none.
• Example: clickedFolder="true"
highlightedTreeviewLink
This cookie is used in the Admin Console to persist the
current folder as used in various tree-view portions of the
Admin Console.
• Possible values: integer, the DOM ID of the clicked
folder.
• Expiration: at session end.
• Encryption: none.
• Example: highlightedTreeviewLink="23"
jiveLocale
This cookie is used on the front-end for guest/anonymous
users who choose a locale setting.
• Possible values: string, locale code.
• Expiration: 30 days.
• Encryption: none.
• Example: jiveLocale="en_US"
jiveTimeZoneID
This cookie is used on the front-end for guest/anonymous
users who choose a timezone setting.
• Possible values: string, timezone ID.
• Expiration: 30 days.
• Example: jiveTimeZoneID="234"
jive-cookie
This cookie is used in the Admin Console to temporarily
persist an encrypted username/password when creating a
bridge between two sites. The information in the cookie
is first encrypted with AES/256 encryption and then
Base64 encoded.
• Possible values: string, Base64 encoded, encrypted
username/password of remote site.
• Expiration: at session end.
• Encryption: yes.
• Example: jive-
cookie="YWFyb246MTMxNTU4MjUzNTI3MDoyZDUyODNmZjhhNjExZTdlMTcyMGZhYjVhNWNkNjI0Yg"
jive.user.lastvisited
This cookie is used on the front-end to store the last time
the user visited the site.
• Possible values: long, value in milliseconds that
represents the time of the login.
• Expiration: 30 days.
• Encryption: none.
• Example: jive.user.lastvisited="1315292400000"
JCAPI-Token
This cookie is used to avoid CSRF attacks when the UI
layer uses session-based authentication.
| Administering the Platform | 17
Security of Public Cloud Communities
The application's secure data architecture and Safe Harbor certification ensures maximum security and privacy of
your public cloud (hosted) instance.
Secure Data Architecture
Virtualization technology and multi-tenancy architectures at the security, storage, and network layers ensure
separation between each public cloud instance and SaaS-delivered feature. Jive Software follows several industry
best practices to harden all cloud operating systems and databases that support all of the layers of the platform. All
hosts use security-hardened Linux distributions with non-default software configurations and minimal processes, user
accounts, and open network ports. Jive Software's cloud engineers never execute at root and all log activity is stored
remotely as an additonal security precaution.
Jive Software's public cloud instances and SaaS services hosts include various encryption methods to protect data
transmission over untrusted networks. We use SSL or HTTPS for all public cloud instances. Additionally, Jive
Software has implemented encryption for both the data transmission and storage of offsite backups in our remote data
center(s).
We use a variety of automatic tools and manual techniques to ensure our environment is secure.
Secure Data Center
All of Jive Software's hosting data centers have central surveillance monitoring, key cards for initial access, and other
mechanisms such as biometrics or two-factor authentication systems to ensure that only authorized personnel have
access to the physical machines. Only authorized data center personnel are granted access credentials to our data
centers. No one can enter the production area of the data center without prior clearance and an authorized escort. All
Jive Software office locations adhere to similar security controls to limit access to active employees only.
Jive’s network infrastructure was designed to eliminate single points of failure. Each data center leverages multiple
internet feeds from multiple providers, ensuring that in the event of a carrier outage, our public cloud (hosted) sites
and SaaS-delivered services are still available. The switching and routing layers within our data centers are designed
so that device or network link failure does not impact service, and ensures that public cloud customers have the
highest level of availability.
Jive Software's public cloud and SaaS-delivered services are backed up regularly to guard against data loss. All
instances are backed up to an offsite location using an electronic backup and recovery system. All backed-up
information is transmitted and stored in an encrypted format. The Jive Software public cloud team performs failure
and redundancy testing during the implementation phase and as needed throughout the equipment lifecycle.
Jive Software is Safe Harbor and TRUSTe certified and our data centers are either SAS 70, SSAE 16 SOC2, or ISO
27001 certified, depending on the location.
Public Cloud FAQ
For more questions and answers about our public cloud platform, see Public Cloud FAQ in the Jive Community. You
will need to be a registered user of the community to view this document.
Security of Private Cloud Communities
Our private cloud offering provides you with all of the features and security of the public cloud product, but deployed
behind your firewall.
Here's how it works (click the image to enlarge it):

| Administering the Platform | 18

Security of Cloud-Delivered Services
Some of the application's services are cloud-delivered to your instance and updated regularly via our private network.
Here's how it works (click the image to enlarge it):

| Administering the Platform | 19

Web Services
Web services requests fully respect the configured
permissions of Jive. As such, if web services are fully
enabled for all users, there is no risk of private content
exposure or invalid content manipulation. Users will
only be able to view and modify content they have access
to in the application. However, web services do give
users a mechanism for creating and downloading content
en masse. If you do not want users to have the ability
to quickly download all of the content they are able to
access, consider enabling web services only for specific
users. To learn how to do this, see Setting Access for Web
Service Clients.
Video
Video Plugin Security
Mobile
Mobile Security
Jive Apps Market
Jive Apps Security
Jive Genius and Recommender Service
Jive Genius Security
Security Recommendations
These security recommendations depend on your community's specific configuration.
Caution: Each community can be configured differently. Because of this, not all of these recommendations
apply to all communities. If you have any questions about these recommendations, please contact your Jive
Software representative.
Internal communities are typically for employees only.
External communities are typically for customers, vendors, and other external audiences.
| Administering the Platform | 20
Security Recommendation:
Applies to:
Description:
Configure user login security
External Communities
Login security can include throttling, Captcha, and
password strength requirements.
For implementation details:
See Configuring Login Security and Configuring User
Registration.
Enable SSO
Internal Communities
A single-sign on solution can help you provide a consistent
login experience for your users while providing identity
management for your organization via a third-party vendor.
Jive Software strongly recommends using a single sign-
on solution for access to internal communities. In addition
to the out-of-the-box SSO options in the application, our
Professional Services team can create customizations to
meet almost any single sign-on requirement.
For implementation details:
See the Single Sign-On section, or, if you need an SSO
customization, contact your Jive Software account
representative.
Add an extra layer of
security with SSL
External and Internal
Communities
SSL will enable you to encrypt HTTP requests. Over the
past few years it's become more common for public sites
that request a username and password to give the user the
option to browse the site in either HTTP or HTTPS. For
security and ease of use, we believe that authenticated users
should always be browsing the community via HTTPS
because it's become commonplace to browse the Internet
via insecure wifi access points. Any community that allows
its authenticated users to browse via HTTP is open to
session hijacking.
For implementation details:
See Enabling SSL Encryption.
Add VPN
Internal Communities
If you use both SSO login and SSL/HTTPS user access,
you shouldn't need VPN, too. However, VPN-only access
to the community can be configured for your community in
both public and private cloud communities.
For implementation details:
Contact your IT department to set up VPN-only access to
the Jive application.
Prevent spam in your
community
External Communities
Everyone hates spam, and it can also present security risks.
Limit it in your community as much as you can.
For implementation details:
Preventing Spam includes several suggestions for dealing
with spammers and preventing spam in your community.
Understand administrative
permissions and how they
work
External and Internal
Communities
Administrative permissions can be a powerful tool for
limiting who can make changes to your community.
For implementation details:
See the Managing Administrative Permissions section.
| Administering the Platform | 21
Security Recommendation:
Applies to:
Description:
Add an extra username/
password verification step
for Admin Console access
via Apache
External and Internal
Communities
Apache includes a couple of features that can help you
keep Jive more secure. Jive runs on Tomcat behind an
Apache HTTP web server. You can set up Apache features
such as IP restrictions or basic authentication for specific
URLs using standard Apache HTTP configurations.
The main Apache HTTP configuration file for the Jive
application is /usr/local/jive/etc/httpd/
conf/httpd.conf.
For requests inside your network, Apache should remain
totally open. The security for specific requests (admin
pages, file attachments, hidden content) is all executed at
the Tomcat/Java level. For every request that comes in,
the user's account is looked up and the permissions are
checked against the specific request. Because of this, users
are only able to access URLs which they have permission
to view. Some system administrators choose to set IP
filtering or basic authentication (via Apache) on the Admin
Console. This is primarily useful for externally-oriented
Jive communities (those that allow employees, as well as
vendors and customers as community users) so that users
are unaware of an Admin Console. There is no security
risk of leaving the /admin URL exposed. If you implement
this, users trying to access any of the Admin Console pages
must successfully enter their external username/password
combo to gain access.
For implementation details:
See Apache's documentation.
Understand the security
of the Jive Genius
Recommender Service
External and Internal
Communities
This cloud-delivered service communicates between your
community and Jive Software via a secure proxy and state-
of-the-art encryption protocols.
For more details:
See Jive Genius Security.
Block search robots
External Communities
Search robots can wreak havoc in your community, so it's a
good idea to set up robot blockers.
For implementation details:
See this tutorial.
Security FAQ
Does Jive Software access data from my public cloud instance?
Jive Software aggregates data from our public cloud customer instances. The kinds of data we collect include
usage statistics, user travel patterns, adoption statistics, and other anonymous information. Among other things,
this information helps us to make decisions about future product development and improvement. In addition, your
contract sets forth how we protect your user-generated content (i.e., we access this data solely to provide support and
other services to you as you request).
| Administering the Platform | 22
How does the application prevent cross-site request forgeries (CSRF) using request-based tokens?
Every form throughout the application is protected from CSRF by a token scoped to each request which prevents
forgery attempts. The server requires the token on any request that can change data. If the token is not present or does
not match, the HTTP request will fail.
Are web services tested?
Yes. All web services are tested as part of an automated monthly security scan process.
Why do you zip or compress certain types of files when a user uploads them to Jive?
There are a number of known security issues with Internet Explorer (IE). In particular, IE will attempt to display or
execute a file even if the web server sends an HTTP header indicating that the browser should download, instead
of display, the file. This behavior, also known as "content sniffing" or "MIME sniffing," allows attackers to upload
seemingly okay files (for example, an MS Word file) that actually contain malicious HTML. An IE user would then
attempt to view the file. If the file is not zipped, IE will "sniff" the contents of the file, determine that the file is
HTML, and then attempt to render the HTML instead of opening the file with MS Word.
The following types of files are zipped by Jive when they are attached to content: text/plain and text/HTML. Jive uses
a magic number process to determine the correct MIME type of an uploaded file. For example, if a document called
mydocument.doc is uploaded, the magic number process will validate the document. If the file is actually an HTML
file, then Jive zips the file as a security precaution.
Does Jive use Sun's Java Virtual Machine (JVM)?
Yes. Jive uses Sun's JVM 1.6 and the Java Secure Socket Extension (JSSE), which is FIPS 140-compliant.
Which cryptographic technologies are used in Jive?
Jive supports anything the JVM does at the application level and anything OpenSSL does at the HTTPD level. We
actively use Blowfish/ECB/PKCS5P, AES-256 for symmetric key encryption, SHA-256 for one-way hashing, and we
support and recommend Triple-DES ciphers at the HTTPD server for TLS encrypted channels.
• SHA-256 -- Jive user passwords are stored in the database as salted SHA-256 hashes.
• AES-256 -- Bridging credentials, License Metering information, and iPhone UDIDs are all encrypted with
AES-256.
• Blowfish/ECB/PKCS5Padding -- Used for storing LDAP administrator credentials and OpenSearch credentials in
the database.
If your product uses cryptography, has this cryptography been certified under the Cryptographic
Module Validation Program or is it in the process of CMVP certification? If yes, which
Cryptographic Module Testing (CMT) Laboratory are you using and what is your Cryptographic
Module Security Level?
Jive uses Sun's JVM 1.6 and the Java Secure Socket Extension (JSSE).
Is the product public-key enabled and is it interoperable with the DoD PKI?
Jive supports X.509-based PKI. However, extra configuration steps are required; we recommend a Jive Professional
Services customization.
I am a public cloud hosted customer. Can you encrypt my data at rest?
Yes. We can encrypt your dedicated databases that reside in our hosting data centers. Contact your Jive Software
representative to request this additional service and pricing schedules. Note that this service may require additional
lead time depending on the size and traffic of your community.
| Administering the Platform | 23
Platform Run Book (Linux)
This document covers basic system-administration commands for managing the platform.
Use the information here for tasks that an average system administrator would need to perform without familiarity
of the actual functionality of the system. This guide assumes a basic understanding of common Unix or Linux
commands and concepts. You'll find the application management commands mentioned here documented in
Application Management Commands.
For a higher-level look at the platform, be sure to see the Platform Overview.
Jive HTTPD
The Jive HTTPD service is the main access point for HTTP and HTTPS access to the Jive system by web browser.
Start Jive HTTPD
To start the jive-httpd service, execute the following command as root:
[root@biodome:~]$ /etc/init.d/jive-httpd start
Starting jive-httpd:
OK
If the command completes successfully, an OK message will be printed to the console and the exit code of the
command will be zero.
Restart Jive HTTPD
To restart the jive-httpd service, execute the following command as root:
[root@biodome:~]$ /etc/init.d/jive-httpd restart
Stopping jive-httpd:
OK
Starting jive-httpd:
Stop Jive HTTPD
To stop the jive-httpd service, execute the following command as root:
[root@biodome:~]$ /etc/init.d/jive-httpd stop
Stopping jive-httpd:
OK
If the command completes successfully, an OK message will be printed to the console and the exit code of the
command will be zero.
Monitoring Jive HTTPD
The jive-httpd service supports a "status" command issued to the standard init script located at "/etc/init.d/jive-httpd".
An example of checking the serivce status as the root user:
[root@biodome:~]$ /etc/init.d/jive-httpd status
JIVE_HOME set to /usr/local/jive
Running: 2393 (2396, 2397)
In the above example, the parent process of the jive-httpd system daemon is 2393, with child processes of 2396 and
2397.
| Administering the Platform | 24
In addition to the status script, it is possible to check the status of the jive-httpd daemon using standard Unix
commands. For example, the following ps command will list all jive-httpd processes running on the host:
[root@biodome:~]$ ps -ef | grep jive-httpd | grep -v grep
root 2393 1 0 14:41 ? 00:00:00 /usr/local/jive/httpd/bin/
jive-httpd -f /usr/local/jive/etc/httpd/conf/httpd.conf -k start
jive 2395 2393 0 14:41 ? 00:00:00 /usr/local/jive/httpd/bin/
jive-httpd -f /usr/local/jive/etc/httpd/conf/httpd.conf -k start
jive 2396 2393 0 14:41 ? 00:00:00 /usr/local/jive/httpd/bin/
jive-httpd -f /usr/local/jive/etc/httpd/conf/httpd.conf -k start
jive 2397 2393 0 14:41 ? 00:00:00 /usr/local/jive/httpd/bin/
jive-httpd -f /usr/local/jive/etc/httpd/conf/httpd.conf -k start
jive 2398 2393 0 14:41 ? 00:00:00 /usr/local/jive/httpd/bin/
jive-httpd -f /usr/local/jive/etc/httpd/conf/httpd.conf -k start
jive 2399 2393 0 14:41 ? 00:00:00 /usr/local/jive/httpd/bin/
jive-httpd -f /usr/local/jive/etc/httpd/conf/httpd.conf -k start
Jive HTTPD Networking
The jive-httpd server by default listens for connections on port 80, on all available network interfaces. If configured
for SSL (see the Operations Cookbook), the server will also listen for connections on port 443. The following
commands will show if the jive-httpd service is listening on the designated ports.
[root@melina ~]# lsof -n -i TCP:80 -i TCP:443
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
jive-http 3094 root 3u IPv6 30661 TCP *:http (LISTEN)
jive-http 3098 jive 3u IPv6 30661 TCP *:http (LISTEN)
jive-http 3099 jive 3u IPv6 30661 TCP *:http (LISTEN)
jive-http 3100 jive 3u IPv6 30661 TCP *:http (LISTEN)
jive-http 3101 jive 3u IPv6 30661 TCP *:http (LISTEN)
jive-http 3102 jive 3u IPv6 30661 TCP *:http (LISTEN)
jive-http 3104 jive 3u IPv6 30661 TCP *:http (LISTEN)
jive-http 3105 jive 3u IPv6 30661 TCP *:http (LISTEN)
jive-http 3273 jive 3u IPv6 30661 TCP *:http (LISTEN)
jive-http 3274 jive 3u IPv6 30661 TCP *:http (LISTEN)
jive-http 3275 jive 3u IPv6 30661 TCP *:http (LISTEN)
In the above example, multiple jive-httpd processes are providing the "http" service. If listening for SSL or TLS
connections, the "https" service will also be present.
Jive HTTPD Log Files
All log files for jive-httpd are stored in the standard platform log directory - /usr/local/jive/var/logs. The following
command illustrates how to view the available logs.
[root@melina logs]# ls -l /usr/local/jive/var/logs/*http*
-rw-r--r-- 1 root root 224 Feb 23 16:12 /usr/local/jive/var/logs/httpd-
error.log
-rw-r--r-- 1 root root 19454 Feb 26 08:25 /usr/local/jive/var/logs/jive-
httpd-access.log
-rw-r--r-- 1 root root 854 Feb 23 16:13 /usr/local/jive/var/logs/jive-
httpd-error.log
-rw-r--r-- 1 root root 854 Feb 23 16:13 /usr/local/jive/var/logs/jive-
httpd-ssl-access.log
-rw-r--r-- 1 root root 854 Feb 23 16:13 /usr/local/jive/var/logs/jive-
httpd-ssl-error.log
In the above example, startup logs are captured to the "httpd-error.log" file. Requests handled by the standard jive-
httpd server are maintained in "jive-httpd-access.log" file while errors during normal runtime are captured to "jive-
| Administering the Platform | 25
httpd-error.log". Likewise, SSL or TLS encrypted requests are captured to the corresponding log files with "ssl"
appended to the name of the file.
Jive-Managed Applications
An installation of the Jive platform will host one or more distinct applications. All managed applications have both
system-level scripts that are invoked at system startup and shutdown, as well as scripts locally available to the
"jive" system user created when the platform is installed. The following operations are available for managing and
monitoring managed applications.
Start Jive-Managed Applications
To start all Jive-managed applications, a standard "init" script is avialable for use by the root user. This script is
invoked at system boot to start all managed applications.
[root@biodome:~]$ /etc/init.d/jive-application start
JIVE_HOME set to /usr/local/jive
Starting jive-application:
All applications started successfully (1 total).
In addition to the system scripts, the jive user may start any individual application or all managed applications using
the appstart command. The appstart command is automatically added to the jive user's interactive shell path and may
be run after becoming the jive user (commonly via the "su" command). The following example demonstrates the
root user using the "su" command to become the jive user and then the use of the appstart command to start the "sbs"
application.
[root@biodome:~]$ su - jive
[1456][jive@biodome:~]$ appstart --verbose sbs
Handling applications ['sbs']
Starting sbs...
Executing /usr/local/jive/applications/sbs/bin/manage start
sbs started successfully.
Stop Jive-Managed Applications
To stop all Jive-managed applications, execute the system stop script.
[root@biodome:~]$ /etc/init.d/jive-application stop
JIVE_HOME set to /usr/local/jive
Stopping jive-application:
All applications stopped successfully (1 total).
Similar to the appstart command, the appstop command may be executed to stop managed applications as the jive
user.
[1457][jive@biodome:~]$ appstop --verbose
Stopping sbs...
Executing /usr/local/jive/applications/sbs/bin/manage stop
sbs stopped successfully.
Cleaning sbs application work directory at /usr/local/jive/var/work/sbs.
All applications stopped successfully (1 total).
Monitoring Jive-Managed Applications
To show all running Jive-managed applications, execute the appls command with the "--running" flag as the jive user
as in the following example.
[1507][jive@biodome:~]$ appls --running
| Administering the Platform | 26
stage running (pid=2799)
In this example, the "stage" application is currently running with a process ID of 2799. To monitor the individual
process, standard tools like the "ps" command can be used with the process ID from appls output as in the following
example.
[1542][jive@biodome:~]$ ps -ef | grep 2799 | grep -v grep
jive 2799 1 0 15:06 pts/0 00:00:16 /usr/local/jive/java/
bin/java -XX:+PrintClassHistogram -XX:+PrintTenuringDistribution
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Djava.awt.headless=true
-Djava.net.preferIPv4Stack=true -Xloggc:/usr/local/jive/var/logs/
stage-gc.log -Xmx2048m -Xms2048m -XX:MaxPermSize=512m -Djive.home=/
usr/local/jive -Djive.instance.home=/usr/local/jive/applications/
stage/home -Djive.name=stage -Djive.context=/stage -Djive.logs=/usr/
local/jive/var/logs -Djive.application=/usr/local/jive/applications/
stage/application -Djive.work=/usr/local/jive/var/work/stage -
Djive.app.cache.ttl=10000 -Djive.app.cache.size=10240 -Dserver.port=9500
-Dhttp.addr='127.0.0.1' -Dhttp.port=9502 -Dajp.addr=127.0.0.1
-Dajp.port=9501 -Dajp.buffer.size=4096 -Dajp.max.threads=50 -
Dlog4j.configuration=file:///usr/local/jive/applications/stage/conf/
log4j.properties -Dtangosol.coherence.clusteraddress='224.224.224.224'
-Dtangosol.coherence.clusterport=9503 -Dcatalina.base=/usr/local/jive/
applications/stage -Dcatalina.home=/usr/local/jive/tomcat -Djava.io.tmpdir=/
usr/local/jive/var/work/stage -classpath /usr/local/jive/applications/stage/
bin//bootstrap.jar:/usr/local/jive/applications/stage/bin/tomcat-juli.jar::/
usr/local/jive/java/lib/tool.jar org.apache.catalina.startup.Bootstrap start
Alternatively, the following example combines both operations into a single command.
[1539][jive@biodome:~]$ ps -ef | grep 'appls --running | awk -F'=' '{print
$2}' | tr -cd '[:digit:]''
jive 2799 1 0 15:06 pts/0 00:00:16 /usr/local/jive/java/
bin/java -XX:+PrintClassHistogram -XX:+PrintTenuringDistribution
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Djava.awt.headless=true
-Djava.net.preferIPv4Stack=true -Xloggc:/usr/local/jive/var/logs/
stage-gc.log -Xmx2048m -Xms2048m -XX:MaxPermSize=512m -Djive.home=/
usr/local/jive -Djive.instance.home=/usr/local/jive/applications/
stage/home -Djive.name=stage -Djive.context=/stage -Djive.logs=/usr/
local/jive/var/logs -Djive.application=/usr/local/jive/applications/
stage/application -Djive.work=/usr/local/jive/var/work/stage -
Djive.app.cache.ttl=10000 -Djive.app.cache.size=10240 -Dserver.port=9500
-Dhttp.addr='127.0.0.1' -Dhttp.port=9502 -Dajp.addr=127.0.0.1
-Dajp.port=9501 -Dajp.buffer.size=4096 -Dajp.max.threads=50 -
Dlog4j.configuration=file:///usr/local/jive/applications/stage/conf/
log4j.properties -Dtangosol.coherence.clusteraddress='224.224.224.224'
-Dtangosol.coherence.clusterport=9503 -Dcatalina.base=/usr/local/jive/
applications/stage -Dcatalina.home=/usr/local/jive/tomcat -Djava.io.tmpdir=/
usr/local/jive/var/work/stage -classpath /usr/local/jive/applications/stage/
bin//bootstrap.jar:/usr/local/jive/applications/stage/bin/tomcat-juli.jar::/
usr/local/jive/java/lib/tool.jar org.apache.catalina.startup.Bootstrap start
List Jive-Managed Applications
A list of all managed applications can be obtained by executing the appls command as the jive user as shown in the
following example.
[1507][jive@biodome:~]$ appls
stage running (pid=2799)
development stopped (pid=None)
| Administering the Platform | 27
In the output above, the "stage" application is running with process ID 2799, the "development" application is not
running.
Jive-Managed Application Networking
The network ports and addresses used by a managed Jive application will vary depending on usage. The default Jive
application will work on the following addresses and ports.
Service
Protocol
Address
Application server management
TCP
127.0.0.1:9000
HTTP
TCP
127.0.0.1:9001
AJP
TCP
127.0.0.1:9002
Multicast Cluster
UDP/Multicast
224.224.224.224:9003
Note that managed applications should not be accessed directly via the HTTP 9001 port and it is recommended that a
firewall prevent access to that port. Its existence is for troubleshooting and support purposes only and is not intended
for production use.
To validate that the TCP services are present for a default install, execute the following command.
[root@melina ~]# lsof -n -P | grep jive | grep java | grep LISTEN
java 3204 jive 30u IPv6 31631 TCP
127.0.0.1:9001 (LISTEN)
java 3204 jive 31u IPv4 31632 TCP
127.0.0.1:9002 (LISTEN)
java 3204 jive 39u IPv4 38046 TCP
127.0.0.1:9000 (LISTEN)
Jive-Managed Application Logs
Log files for Jive-managed applications are located in the var/logs directory of the jive user's home directory (/
usr/local/jive/var/logs). The following log files can be consulted for further information on the status of individual
applications. Each file will be prefixed with the name of the corresponding application. For example, for the "stage"
application, the container log file will be named "stage-container.log".
• <name>.log - Primary log file for a managed application; most log entries will be located here.
• <name>-container.log - Early bootstrap log file for the application server container hosting the web application.
• <name>-session.log - Log file capturing creation and eviction of user session data.
• <name>.out - Redirection of standard out and standard error for the application process; may contain data not in
the main log file.
• <name>-gc.log - Java garbage collection logs for the application.
Jive Database Server
The Jive platform ships with a local PostgreSQL database server. The following operations are available for the
database server.
Important: The pre-packaged PostgreSQL DBMS is for evaluation purposes and should not be used for
production instances.
Start Jive Database Server
To start the database server, execute the following system command as the root user.
[root@biodome:~]$ /etc/init.d/jive-database start
JIVE_HOME set to /usr/local/jive
| Administering the Platform | 28
Starting jive-database:
server starting
Stop Jive Database Server
To stop the database server, execute the following system command as the root user.
[root@biodome:~]$ /etc/init.d/jive-database stop
JIVE_HOME set to /usr/local/jive
Stopping jive-database:
waiting for server to shut down.... done
server stopped
Note that stopping the database while managed applications are using the database will result in applications that
cannot service requests. Additionally, stopping the database while applications are connected may result in a lengthy
shutdown time or a failed shutdown.
Monitoring Jive Database Server
Monitoring the database server can be done as the root user with system scripts, or with traditional Unix commands.
To check the status of the jive database, execute the following command as the root user.
[root@biodome:~]$ /etc/init.d/jive-database status
pg_ctl: server is running (PID: 3211)
/usr/local/jive/postgres/bin/postgres "-D" "/usr/local/jive/var/data/
postgres-8.3"
The output of the above command lists the parent process of the database system (3211 in this example) and shows
the command used to start the database.
A healthy, running database system will have multiple processes. The following command will show all running
database processes on the system:
[root@biodome:~]$ ps -ef | grep post | grep -v grep
jive 3211 1 0 17:13 ? 00:00:00 /usr/local/jive/postgres/
bin/postgres -D /usr/local/jive/var/data/postgres-8.3
jive 3214 3211 0 17:13 ? 00:00:00 postgres: writer process

jive 3215 3211 0 17:13 ? 00:00:00 postgres: wal writer process

jive 3216 3211 0 17:13 ? 00:00:00 postgres: autovacuum
launcher process
jive 3217 3211 0 17:13 ? 00:00:00 postgres: archiver process

jive 3218 3211 0 17:13 ? 00:00:00 postgres: stats collector
process
Jive Database Server Networking
In the default configuration, the included database service listens for connections on TCP address 127.0.0.1 port 5432.
To verify that the database is listening for connections, execute the following command.
[root@melina ~]# lsof -n -P | grep jive | grep postgres | grep LISTEN
postgres 2990 jive 3u IPv4 21499
TCP 127.0.0.1:5432 (LISTEN)
Jive Database Server Logs
Logs for the database server are maintained in the platform log directory at "/usr/local/jive/var/logs/postgres.log".
| Administering the Platform | 29
Operations Cookbook
This section is intended to provide sample configurations and script examples common to long-term operation of a
Jive installation.
As opposed to the Platform Run Book (Linux), these operations are common to a new installation, but generally not
for day-to-day operation of the platform.
Enabling SSL Encryption
The Jive platform is capable of encrypting HTTP requests via SSL or TLS. Enabling encryption of HTTP traffic
requires the following steps on a platform-managed host.
Note: To ensure consistent results, you should enable SSL for your UAT environment as well as your
production instance of Jive. As of Jive 5, the Apps Market requires an additional domain. To properly
test and implement SSL, then, you'll need certificates for community.yourdomain.com and
apps.community.yourdomain.com (Production) as well as community-uat.yourdomain.com
and apps.community-uat.yourdomain.com (UAT). To secure these domains, you should purchase
two Multiple Domain UC certificates with SAN entries for the Apps domain. If you're a hosted customer, you
can contact Support instead of using the steps below to apply the certificates.
1.Copy cryptographic materials to the host. By default, the Jive HTTPD server attempts to load an X.509 certificate
file from the path /etc/jive/httpd/ssl/jive.crt and the corresponding key from /etc/jive/httpd/ssl/jive.key. The
paths to these files are configured in the default Apache HTTPD virtual host file located at /etc/jive/httpd/sites/
default.conf and can be changed to any path desired.
2.Import the jive.crt into the Java Tomcat keystore. For example, run the following command as root, then restart
the application:
/usr/local/jive/java/jre/bin/keytool -import -alias jiveCert -file /usr/
local/jive/etc/httpd/ssl/jive.crt -keystore /usr/local/jive/java/jre/lib/
security/cacerts
3.Enable SSL in the HTTPD server by specifying the -D SSL option in the Apache HTTPD configuration extension
file located at /etc/jive/conf/jive-httpd. To enable SSL, open (or create) this file and add OPTIONS="-D SSL" to
the file.
4.With either Jive's HTTP server or behind a third-party load balancer, add three attributes to the file at /usr/
local/jive/applications/<app_name>/conf/server.xml. To the first (HTTP) /Server/Connector element, add this:
scheme="https" proxyPort="443" proxyName="your.domain.com" -- where your.domain.com is the domain
of your application.
5.After making the changes above, restart the Jive HTTPD server as described in the runbook for Linux. Restart the
Tomcat server.
6.Update the jiveURL in the Admin Console: System Management > System Properties.
Note: Except where noted above, if a third-party load balancer or external HTTP proxy is performing SSL
termination upstream of the Jive HTTPD server, it is not necessary to configure the Jive HTTPD server for
HTTP encryption in addition to the load balancer.
Note: If the private key file installed to the server is encrypted, the HTTPD server will interactively prompt
for the password to decrypt the key. The default password is changeit.
Configuring a Persistent Session Manager
Configure a persistent session manager by modifying the context.xml file.
The Jive package includes a persistent session manager. To use it, you'll need to edit the /usr/local/jive/
applications/sbs/conf/context.xml file to include your core database's relevant information. If you've
installed Jive on a cluster, you'll need to modify the context.xml file for each node of the cluster.
| Administering the Platform | 30
In the context.xml file, add a <Context> method that includes your database information. Here is an example:

<!-- The contents of this file will be loaded for each web application -->
<Context>
<!-- Default set of monitored resources -->
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<!-- prevent tomcat from saving HTTP session -->
<Manager
className="com.jivesoftware.catalina.session.JivePersistentManager"
saveOnRestart="true" maxActiveSessions="-1" minIdleSwap="-1"
maxIdleSwap="-1" maxIdleBackup="1" processExpiresFrequency="1">
<Store
className="com.jivesoftware.catalina.session.store.JiveJDBCSessionStore"

driverName=""
connectionURL=""
connectionName=""
connectionPassword=""
sessionTable="jivesession" />
</Manager>
</Context>
Forcing Traffic to HTTPS
You can configure the platform so that all requests are routed through HTTPS by default.
Before going through the following steps, be sure to enable SSL (HTTPS). For more information, please see Enabling
SSL Encryption.
1.Locate the file /usr/local/jive/etc/httpd/sites/default.conf and open it with with a text editor.
2.In the file, look for the text "RewriteEngine On". After that line, add the following lines:
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
3.Restart the Jive HTTPD (Linux) service by running the restart command as root.
Restricting Admin Console Access by IP Address
You can secure the admin console by allowing or denying specific IP addresses.
To specify who can access the admin console based on IP address:
1.Locate the /usr/local/jive/etc/httpd/sites/default.conf file.
2.Allow or deny IP addresses by adding and modifying the following code.
<Location /admin> Order Deny,Allow Allow from <IP ADDRESS> Allow from <IP
ADDRESS> Allow from <IP ADDRESS> Allow from <IP ADDRESS> Allow from <IP
ADDRESS> Deny from all </Location>
Disabling the Local Jive System Database
Many deployments will not wish to use the locally managed platform database instead, choosing to use an RDBMS
that is controlled by an internal corporate IT group. In this case, the Jive local database should be disabled. To disable
the database, as the root user, execute the following script:
The following terminal output demonstrates deactivation and of the Jive database service:
[root@biodome ~]# /etc/init.d/jive-database deactivate
Jive Database deactivated.
[root@biodome ~]# /etc/init.d/jive-database activate
| Administering the Platform | 31
Jive Database activated. The database will start automatically on the next
system restart.
Note: Disabling the database does not stop the service if it is running. Likewise, re-enabling the database
does not start the database service. Also, disabling the local system database will unscheduled all standard
local system database maintenance tasks.
Changing the Configuration of an Existing Instance
Update environment variables in your /usr/local/jive/applications/<app_name>/bin/instance
file to reflect new configuration settings.
In some circumstances, it may be desirable to change the default configuration of platform-managed application
server instances. For example, on a larger server-class machine, an application instance will benefit from allocation of
more RAM for the JVM heap.
To change this or other settings, edit the instance file for the desired application (sbs by default) located at /
usr/local/jive/applications/<app_name>/bin/instance.
The contents of this file will vary from release to release. Generally, the entries in this file correspond to either:
• Environment variable values in the setenv script located in the same directory
• Tokenized configuration attributes for the conf/server.xml file in the application directory
For any managed application, all files except the binaries for the web application (by default, each application is
linked to these binaries located at /usr/local/jive/applications/template/application) are not
managed by the application platform. As a result, any changes to files such as instance will be durable across
application upgrades.
Changing the Port
As an example, to change the port that the managed application listens for AJP connections, edit the instance file
to alter the port for AJP_PORT.
Prior to edit, the instance file will look similar to the following.
[0806][jive@melina:~/applications/sbs/bin]$ cat instance
export JIVE_HOME="/usr/local/jive"
export AJP_PORT="9002"
export APP_CLUSTER_ADDR="224.224.224.224"
export JIVE_APP_CACHE_TTL="10000"
export APP_CLUSTER_PORT="9003"
export HTTPD_ADDR="0.0.0.0"
export AJP_BUFFER_SIZE="4096"
export HTTP_ADDR="127.0.0.1"
export JIVE_APP_CACHE_SIZE="10240"
export SERVER_PORT="9000"
export JIVE_NAME="sbs"
export HTTP_PORT="9001"
export AJP_ADDR="127.0.0.1"
export JIVE_CONTEXT=""
export AJP_THREADS_MAX="50"
To alter the AJP_PORT to listen on port 11000, edit the instance file to appear similar to the following:
[0806][jive@melina:~/applications/sbs/bin]$ cat instance
export JIVE_HOME="/usr/local/jive"
export AJP_PORT="11000"
export APP_CLUSTER_ADDR="224.224.224.224"
export JIVE_APP_CACHE_TTL="10000"
export APP_CLUSTER_PORT="9003"
export HTTPD_ADDR="0.0.0.0"
export AJP_BUFFER_SIZE="4096"
| Administering the Platform | 32
export HTTP_ADDR="127.0.0.1"
export JIVE_APP_CACHE_SIZE="10240"
export SERVER_PORT="9000"
export JIVE_NAME="sbs"
export HTTP_PORT="9001"
export AJP_ADDR="127.0.0.1"
export JIVE_CONTEXT=""
export AJP_THREADS_MAX="50"
Changing the Heap Min/Max Values
To change the JVM min/max values, see Adjusting Java Virtual Machine (JVM) Settings.
Configuring the JVM Route Name of a Node(s)
To configure the route name of your web application node(s), add a line(s) to the instance file in /usr/local/
jive/applications/<app_name>/bin as follows, where "node01" is your desired route name:
export APP_CLUSTER_JVMROUTE="node01"
When configuring multiple nodes with jvmRoute attributes, each node should have a different value.
Performing a Jive System Database Backup
Jive-managed databases will perform automatic backups as described in Auto Backups in the Platform Overview.
In some situations, for example prior to an upgrade of the platform, you should perform a full database backup
manually.
Important: The pre-packaged PostgreSQL DBMS is for evaluation purposes and should not be used for
production instances.
To manually perform a full backup of the managed database, execute the dbbackup script as the jive user.
[0801][jive@melina:~]$ ./bin/dbbackup
/bin/tar: Removing leading '/' from member names
The command will not produce any further output if successful and will return zero if successful, non-zero otherwise.
You can restore from a backup by using PostgreSQL commands. In the PostgreSQL documentation, the section on
recovering from your backup is probably the most specific. For a broader view, be sure to see the contents of their
documentation on backing up and restoring.
Performing Database Maintenance
Any time you restart or shutdown your Jive database, you must restart the Jive web application nodes as follows:
1.Take down all the web application nodes.
2.Restart or shut down the database.
3.Bring up all the web application nodes.
Backup and Storage Considerations
Storage Reliability
It is highly recommended that the Jive system home directory (/usr/ local/jive) be mounted on redundant external
storage (preferably SAN storage via redundant HBAs and SAN fabric). When redundant external storage is not