Wednesday, September 26, 2012

What the Higgs Boson Particle Could Mean for Cloud Computing

Most businesses have come to realize the cost-saving potential of using cloud computing. Large and reliable resources for data storage have become essential, whether a company specializes in sales, marketing or particle acceleration. Making use of the cloud typically involves allotting resources over a network, while grid computing is a similar concept, but involves computing resources outside of a single network.

Both of these systems have been widely analyzed for managing data and computing resources. Companies can outsource their computing needs to a third party, just as an SEOcompany can be enlisted for online marketing, website creation and traffic monitoring. Small businesses and big corporations alike benefit from such services, even a company like the European Organization for Nuclear Research (CERN). The company recently used its Large Hadron Collider in the discovery of a once theoretical particle.

Cloud Computing and Particle Physics

With a 17-mile-long tunnel and repeated experiments, CERN produces a lot of data. As much as 1 GB per second is recorded in the facility’s datacenter. This adds up to so much data that even Moore’s Law, the principle that states memory capacity should double every 18 months, is not enough to keep up. Data are measured in petabytes, one of which is equal to a million gigabytes. Time during experiments is measured in nanoseconds; with an estimated 600 million particle collisions per second during experiments, up to a petabyte of information can be collected during each run.

Many businesses use a public cloud, but CERN has created a grid network consisting of 150 different computer systems spread around the world. Ethernet connections link most of them, allowing for the use of 300,000 cores to drive computational operations. When the Higgs boson particle, theoretically the generator of mass, was found, enormous quantities of data were created for collision analysis, particle path tracking and statistical analysis.

Progressive Efforts

European research organizations and CERN have begun experimenting with a cloud resource called Helix Nebula – The Science Cloud. The project was implemented in March 2012 and is a partnership between various research groups, IT businesses and cloud vendors. Simulations from the particle collider have already been run through this network as part of a two-year study.

Many scientists consider the particle discovery one of the most important in recent times, while the cloud has become perhaps the most significant aspect of computing for businesses. The Higgs boson particle itself may not yet have applications directly related to IT, but the research surrounding it seems to be driving a push to advance public computing resources on a wide scale. Data security is important for businesses no matter what their focus is.

Byline: My best friend Michelle is a Content Specialist and Blogger with a passion for the Internet, specifically social media and blogging. She loves how social media connects people across the globe, and appreciates that blogging gives her the opportunity to voice her thoughts and share advice with an unlimited audience.

Wednesday, September 19, 2012

How to renew Alfresco Solr SSL certificate

This information is only applicable to Alfresco (Enterprise) 4.x versions
There needs to be two-way communication between the Alfresco server and the SOLR server. So that no one else can abuse this communication channel, it must be secured by means of HTTPS encryption and a mutual client certificate authentication.
There are three important points involved in setting up this mutual trust relationship:
  • Creating a 'keystore directory' and configuring the Alfresco and Solr servers to use it.
  • Generating and installing your own 'secure certificates'.
  • Replacing default certificates and handling 'certificate expiry'.

If you installed Alfresco and SOLR via the Installation Wizard, there is no need to perform step 1, as the directory and associated configuration will already be present. You can proceed straight to step 2.
If you installed SOLR manually, then please carefully review steps 1 and 2 - as otherwise, without configuring your own keystore directory, you may be picking up expired, default keys.

1. Creating a keystore directory and configuring the Alfresco and Solr Servers to use it
The following instructions assume SOLR has already been extracted and configured.
We will use to refer to the tomcat directory where Alfresco is installed and to the tomcat directory where Solr is installed. These may be the same or different directories, depending on whether you have chosen to install Solr on a standalone server or the same server as Alfresco.
  • Ensure that Alfresco has already been started at least once, i.e. the /webapps/alfresco/WEB-INF directory exists.
  • Create and populate a keystore directory for the Alfresco and SOLR servers. By convention, we will create this in /alf_data/keystore. Please note that at this stage the keystore directory will just be a template, containing standard keys available to everybody. To secure the installation you must carry out the steps to generate new keys, specified in section 2.
    • Linux/Unix:

          mkdir -p /alf_data/keystore
          cp /webapps/alfresco/WEB-INF/classes/alfresco/keystore/* /alf_data/keystore

    • Windows
                    mkdir \alf_data\keystore
                    copy \webapps\alfresco\WEB-INF\classes\alfresco\keystore\* \alf_data\keystore

  • Configure the Alfresco and SOLR tomcats to use the keystore and truststore for https requests, by editing the specification of the connector on port 8443 in /conf/server.xml and /conf/server.xml as follows, remembering to replace /alf_data/keystore with the full path to your keystore directory

< maxThreads="150" scheme="https" keystoreFile="/alf_data/keystore/ssl.keystore" keystorePass="kT9X6oe68t" keystoreType="JCEKS"
secure="true"connectionTimeout="240000" truststoreFile="/alf_data/keystore/ssl.truststore"truststorePass="kT9X6oe68t" truststoreType="JCEKS"
clientAuth="false" sslProtocol="TLS" />
  • Configure Alfresco itself to use the keystore and truststore for client requests to SOLR, by specifying dir.keystore in ALFRESCO_TOMCAT_HOME/shared/classes/, remembering to replace /alf_data/keystore with the full path to your keystore directory
  • Configure an identity for the Alfresco server. In /conf/tomcat-users.xml, add the following. Note that you can choose a different username, such as the host name of the Alfresco server, but it must match the REPO_CERT_DNAME you will later specify in the keystore in section 2.
  • Configure an identity for the Solr server. In /conf/tomcat-users.xml, add the following. . Note that you can choose a different username but it must match the SOLR_CLIENT_CERT_DNAME you will later specify in the keystore in section 2.
  • To complete the installation, it’s necessary to secure communications by generating your own keys. See section 2.
2. Generating and installing your own secure certificates
Use these instructions to replace or update the keys used to secure communications between Alfresco and SOLR, using secure keys specific to your Alfresco installation.
NOTE: If applying these instructions to a clustered installation, the steps should be carried out on a single host and then the generated .keystore and .truststore files must be replicated(used) on all other hosts in the cluster.
The following instructions assume that solr has been extracted and a keystore directory has already been created, either automatically by the Alfresco installer, or manually by following the instructions in section 1.
  • Obtain the file (for Linux and Solaris) orgenerate_keystores.bat (for Windows) from the Customer Support website under 'Online Resources > Downloads > Alfresco Enterprise 4.x > '
  • Edit the environment variables at the beginning of the file to match your environment
If you are updating an environment created by the Alfresco installer, you will only need to edit ALFRESCO_HOME to specify the correct installation directory
For manual installations, carefully review ALFRESCO_KEYSTORE_HOME, SOLR_HOME, JAVA_HOME, REPO_CERT_DNAME and SOLR_CLIENT_CERT_DNAME and edit as appropriate.
  • Run the edited script
  • You should see the message 'Certificate update complete' and another message reminding you what dir.keystore should be set to in
3. Replacing default certificates and handling certificate expiry
If you see errors such as the following in the logs, it means that the expiry date set in one or more of your SSL certificates has passed.
21:52:14,109 ERROR [org.quartz.core.ErrorLogger] Job ( threw an exception. 
org.quartz.SchedulerException: Job threw an unhandled exception. [See nested exception: org.alfresco.error.AlfrescoRuntimeException: 07180158 Bakup for core archive feailed .... ] 
at org.quartz.simpl.SimpleThreadPool$ 
Caused by: org.alfresco.error.AlfrescoRuntimeException: 07180158 Backup for core archive failed .... 
... 1 more 
Caused by: org.apache.solr.client.solrj.SolrServerException: PKIX path validation failed: timestamp check failed

It is recommend to generate new secure certificates following the instructions in section 2 
As a temporary measure, you can substitute all your existing .keystore, .truststore and .p12 files with the new Alfresco default files. These can be found in zip file'' available in the support website download section with the generate keystore scripts.

There are numerous locations for these files in the Alfresco/SOLR install, you must find and replace all the .keystore, .truststore and .p12 files with the new secure certificates

This is an example list of typical (v4.0.2.x ) file paths to be updated is below, but please be aware these files may be located in different relative locations in your system:
Use the generate keystore script provided with the Alfresco Enterprise version you are updating
In the case of version 4.0.2, ideally it is best to update your install to, else use the scripts found under downloads for 4.0.2 secure certificate generation
The /alf_data/solr/templates directory does not exist in 4.0, 4.0.1 installs.
Users connecting directly to SOLR web app will need to replace their browser.p12 file with the new one (
(cluster) If applying these instructions to a clustered installation, the .keystoreand .truststore files must be replicated (used) on all other hosts in the cluster.

Your Reviews/Queries Are Accepted