Skip navigation

India Regional Group

3 Posts authored by: rocker88

Hardware Requirements

Posted by rocker88 Jan 15, 2012

Your application server, cache server, Activity Engine, and database machines have different suggested hardware specifications.

Jive is compatible with a number of hardware configurations as well as network topologies. The following tables provide suggested hardware specifications.

Network Technology and Topology

 

  • Required: One box for each application, database, Activity Engine, and cache server.
  • Recommended: At least two app nodes with a cache server for redundancy and load balancing. If you have Document Conversion enabled, you need to store that on a separate server.
  • Gigabit Ethernet hardware gear (NICs, switches).
  • One local network for any multi-box deployments.

Application Machine

CPUs
  • Multicore - 2 chips with multicore optimal
  • 2 Ghz Minimum
  • x86 architecture
Memory
  • 3-4 GB physical RAM
  • 2 GB memory heap (configured by default)
Storage
  • Use a RAID configuration for best performance and reliability.
  • For the database server machine, be sure you have enough available disk space to allow for your community's growth. For example, a new community might start out with 10 GB of free space, which you should monitor and increase as the community grows.

 

 

Activity Engine Machine

CPUs
  • Multicore - 2 chips with multicore optimal
  • 2 Ghz Minimum
  • x86 architecture
Memory
  • 2 GB physical RAM; 4 recommended
  • 1 GB memory heap (configured by default). 2+ GB recommended for sites with large amounts of content.
Topology
  • Activity Engine on a single machine separate from clustered application servers.

 

 

Cache Server Machine

CPUs
  • Multicore - 2 chips with multicore optimal
  • 2 Ghz Minimum
  • x86 architecture
Memory
  • 2 GB physical RAM; 4 recommended
  • 1 GB memory heap (configured by default). 2+ GB recommended for sites with large amounts of content.
Topology
  • Cache server on a single machine separate from clustered application servers. If you're setting up more than one cache server machine, you should use three or more. Using only two cache servers can be less efficient than using one.

 

 

Database Machine -- for configurations where the application and Activity Engine share a database.

CPUs
  • Multicore - 4 chips with multicore optimal
  • 2 Ghz Minimum
  • x86 architecture
Memory
  • 6-8 GB physical RAM
  • 4 GB memory heap (configured by default)
Storage
  • Use a RAID configuration for best performance and reliability.
  • For the database server machine, be sure you have enough available disk space to allow for your community's growth. For example, a new community might start out with 20 GB of free space, which you should monitor and increase as the community grows.

 

 

Separate Application and Activity Engine Database Machines -- for configurations where the application and Activity Engine will each have their own database machine.

CPUs
  • Multicore - 2 chips with multicore optimal
  • 2 Ghz Minimum
  • x86 architecture
Memory
  • 3-4 GB physical RAM
Storage
  • Use a RAID configuration for best performance and reliability.
  • For the database server machine, be sure you have enough available disk space to allow for your community's growth. For example, a new community might start out with 10 GB of free space, which you should monitor and increase as the community grows.

 

Binary Storage Considerations

If your community will include a large amount of binary data, you should consider configuring a binary storage provider that is outside the application database (the default).

For example, consider the load you need to account for if you have document conversion enabled. The stored footprint for each version of each converted document is about 130 percent of the size of the uploaded document. So, for example, a 5MB document uploaded by the user will mean about 6.5MB of storage needed for each version of the document in your binary storage provider. That's because for each document for which the application generates a preview -- for each version of that document -- the application generates a preview, thumbnail images, and PDFs.

Additional System Recommendations

When you run a server-side application, you should also have a daily backup solution. At a minimum you should back up your database on a regular basis as well as the configuration files for Jive (note that those are stored in one directory).

 

source http://docs.jivesoftware.com/jive_sbs/5.0/index.jsp?topic=/com.jivesoftware.help.sbs.online_5.0/developer/DevelopersCommunityDocuments.html

 

Summary

Jive 5 is not supported in a Windows environment.  The best way to set up a developer environment for Windows users is to create a local Virtual Box VM with Cent OS.  This allows you to build and run the app from Linux while developing on your Windows machine.

 

1. Download and Install Virtual Box.

a. Download and Install virtual Box(Virtual Box 4.0.10 for Windows hosts x86/amd64)

b. After installing virtual box, create the VM with 800 MB system memory and virtual hard disk for 8 GB.

 

 

2. Install Cent OS VM set up

You can download the latest release of CentOS 5 here.

Install Cent OS with the default settings.  Install either the Desktop or Server configuration of CentOS.  If you are proficient in Linux, you may want to use the Server version as it will use less memory.  Installing the Server version will require you to perform step 8.

 

 

3. Install Maven on Cent OS

a. Download Apache Maven.

 

b. Change permission to 700:

  1. # chmod 700 apache-maven-2.2.1-bin.tar.gz 

     c. Extract the files from above archive. Below command will create a apache-maven-2.2.1 directory in your current directory.

  1. # tar xzf apache-maven-2.2.1-bin.tar.gz 

d. Move the above directory /usr/local directory by command:

  1. # mv ../apache-maven-2.2.1 /usr/local 

e. Create Symbolic link for maven by :

  1. # ln -s apache-maven-2.2.1 maven 
f. Now you need to add maven your system path, so that you call it from anywhere. Open .bashrc file :
  1. # vi ~./.bashrc 
g. Add following to the end of file
  1. export M2_HOME=/usr/local/maven 
  2. export PATH=${M2_HOME}/bin:${PATH} 
Save the changes by pressing escape key and then :wq!. h. Source the .bashrc file to load your changes.
  1. # source ~/.bashrc 
i. Confirm your maven version by running the following command
  1. # mvn –version 
  1. Apache Maven 2.2.1 (r801777; 2009-08-06 23:16:01+0400) 
  2. Java version: 1.6.0_24 
  3. Java home: /opt/jdk1.6.0_24/jre 
  4. Default locale: en_US, platform encoding: UTF-8 
  5. OS name: “linux” version: “2.6.18-194.26.1.el5.028stab070.14? arch: “amd64? Family: “unix” 
Now you are ready to compile and build your maven projects. 

 

 

4. Install Tomcat on CentOS

Download this file and extract it to /opt/.

  1. wget http://mirror.uoregon.edu/apache/tomcat/tomcat-6/v6.0.32/bin/apache-tomcat-6.0.32.tar.gz 
  2. tar -xzf apache-tomcat-6.0.32.tar.gz 
  3. sudo mv apache-tomcat-6.0.32 /opt/ 

 

5. Install Postgres on the VM

Following are the steps to install Postgres here.

Troubleshooting

    I faced auth failed problem while creating database : followed this link to fix the problem- http://www.cyberciti.biz/faq/psql-fatal-ident-authentication-failed-for-user/     Following are the steps from the above mentioned link to fix this problem.      It gives me an error that read as follows:

psql: FATAL:  Ident authentication failed for user "username"

To fix this error open PostgreSQL client authentication configuration file /var/lib/pgsql/data/pg_hba.conf :

  1. # vi  /var/lib/pgsql/data/pg_hba.conf 

This file controls:

 

  1. Which hosts are allowed to connect.
  2. How clients are authenticated.
  3. Which PostgreSQL user names they can use.
  4. Which databases they can access .

By default Postgresql uses IDENT-based authentication. All you have to do is allow username and password based authentication for your network or webserver.

IDENT will never allow you to login via -U and -W options. Append following to allow login via localhost only:

local     all     all     trust
host     all     127.0.0.1/32     trust

 

 

6.  Install pgAdmin III (optional, Desktop CentOS only)

This link describes installling PG Admin III on CentOS.

 

pgAdmin III is a Desktop application which allows you to easily acces and manipulate your Postgres database.

 

Alternatively, you can use the Postgres terminal commands: psql, createdb, dropdb, pg_dump, and pg_restore

 

 

7. Share Windows Folder

a. Install Guest Addition using the following these steps.

b. In the shared folders add the Windows folder name and location that is to be shared with centos VM.

c. Mount the shared folder in centos using the command

  1. mount -t vboxsf  sharename  mountpoint 

               •    sharename – Name of the shared folder mentioned in the Virtual Box shared folder settings.

               •    mountpoint – directory  where you want your shared folder contents to appear.

 

Since the files are in the windows shared folder those can be edited in Windows using any IDE of your choice.

 

 

8. Setup Port Forwarding (optional for Desktop)

Set up Port Forwarding for port 80 and 22.  To do this, select your VM while it is stopped, then Settings > Network > Advanced > Port Forwarding.  You will need to stop your VM to access this.  Under Port Fowarding Rules create the following rules:

  • Tomcat Forarding: Host Port: 8081, Guest Port: 8080, Protocol: TCP
  • SSH Forwarding: Host Port: 2222, Guest Port: 22, Protocol: TCP

This will allow you to SSH into your VM via your Windows Machine by SSH'ing into localhost over port 2222.You will also be able to access your test environment in your web browser by visiting http://localhost:8081/ If you choose to not set up port forwarding, you will need to access your instance via the web browser available in Cent OS. 

9. Start Developing

                                Reference source:-     https://community.jivesoftware.com/docs/DOC-46147

There are several rules of thumb  for deciding what features you need, the best being “Waste not, want  not” and “Say what you mean and eat what you take.” OK, seriously  though… to answer this question we need to understand what features are,  and where they are defined.

 

A  feature is the way an application tells the container (in this case the  Jive instance/app-sandbox) what capabilities it needs to function  properly. For example, if you are going to get information about people,  activities, etc. you need to tell the container that you REQUIRE the  OPENSOCIAL APIs.

<Require feature="osapi"/>

When the  container processes the application definition, it looks at the features  the app requires and compares it with the features it supports. If  there’s a match, life is good and your app is rendered. If not, then an  error is returned.

 

In  some cases you can incorporate logic in your app that tells the  container that it’d be nice to have a feature, but it’s not required.  That is, support for the feature is OPTIONAL. For example, you might  want to use minimessge, but if the container does not support it, you  put some branching logic in your code to display a dialog box.

<Optional feature="minimessage"/>

 

You can find out if a container has the feature by issuing the hasFeature call.

    gadgets.util.hasFeature(“minimessage”);

If the feature has parameters, you can get this by a similar call:

    gadgets.util.getFeatureParameters(“somefeaturename”)

 

 

To  understand what features are available to you, let’s look at where they  get defined. The first place they get defined is in the OpenSocial specification.  In addition to the base set of capability you get just by being an app  (e.g. what's available in the gadgets namespace), you can look in the Core Gadget specification, section C.  The Social Gadget specification explains the OSAPI calls that are in  that feature. OpenSocial layered the specification in such a way that if  you had the case where you used no social data, you did not have to  bring along a bunch of extra stuff you don’t need. 

 

The  nice thing about features is that they provide a clean way for  container providers, e.g. Jive to extend the system. This is exactly  what the jive core and jive connects features are. Because OpenSocial  doesn’t define everything that’s in Jive, e.g. no blogs, discussions, we  wanted a way to provide access to that information using the EXACT SAME  PROGRAMMING MODEL. This allows the app developer (you) all kinds of  benefits, not the least of which is having to learn only one way of  doing something.There is a table below that contains a list of the Jive features.

 

One  last note about features: even though we are dealing with applications,  notice that I did not make a direct correlation between a feature and a  javascript file. This is for several reasons.

First, under the  covers there’s often more than one javascript file that implements a  feature.  When the app definition is process, all of the required  javascript is woven into the gadget and/or page that renders it.

Second,  features can depend on other features, e.g. the minimessage feature  depends on a core.config feature.  The container provider handles all of  this for you, but keep in mind that there’s a dependency tree and you  are bringing in more javascript.

Third, a feature may use no  javascript at all and simply be a way to tell the container that it  needs to do something when processing the gadget definition.  Content-rewriting is an example of one of these kinds of features.

 

So  now that we know what features are, how do I know which ones I need?  I’ll go back to my initial comments, “Waste not, want not” and “Say what  you mean and eat what you take.” That is, when you understand what you  want your app to do, find the right features to help you accomplish it,  and don’t REQUIRE anything more.

 

Jive Features

The following tables identify extensions, features, services, and views that Jive provides beyond the OpenSocial Services:

 

FeatureDescription
jquery-1.4.2

The JQuery 1.4.2  library. Simplifies JavaScript development. Used by the Jive-connects  and Jive-core features.

jive-namespace

Internal. Adds the jive.namespace() function for creating additional namespaces under jive.*

jive-connects

The JavaScript API for Jive Connects. Dependencies: jquery-1.4.2,  jive-namespace

jive-core

The JavaScript  API for Jive Core. Dependencies: jquery-1.4.2, jive-namespace

jive-custom-settings-1.0.0An extension used to close the popover, refresh the app and show a success message. This is typically uses with OpenSocial's setprefs feature.

jive-storage

The JavaScript API for binary storage. Adds functionality for uploading binary files via a dialog box.

You   can use the jive-storage extension, which extends JavaScript API for   binary storage by specifying  <Require   feature="jive-storage-1.0.0"/> and then adding the functionality for   uploading binary files using a dialog box.