Friday, June 9, 2017

How to Disable AutoCAD Drawing Property Extraction

One of the features of the Formtek EDM Module is the ability to extract AutoCAD block attributes when a drawing or drawing version is uploaded to the Alfresco repository. The extracted attribute values are stored as metadata (or properties) on the repository drawing per a configurable mapping. The following illustration shows several AutoCAD attributes in a drawing’s title block and how they could be stored as properties in the Alfresco repository:


In addition to AutoCAD block attributes, the EDM Module extracts the Title, Subject, and Author drawing properties (shown below) and stores them in the standard Alfresco Title (cm:title), Description (cm:description), and Author (cm:author) properties:



If you prefer not to have the AutoCAD drawing properties automatically extracted from DWG and DXF files, you can disable their extraction by following these steps:


1.     Edit the module-context.xml file in the tomcat/webapps/alfresco/WEB-INF/classes/alfresco/module/
org.formtek.edm.repo directory.

2.     Comment out the following lines for both the EDM_DWGExtractor and EDM_DXFExtractor beans:
<!--
                <prop key="prop_subject">cm:description</prop>
                <prop key="prop_title">cm:title</prop>
                <prop key="prop_author">cm:author</prop>    
-->
3.       Save the changes.

4.       Restart Alfresco.


These properties will no longer be extracted from DWG and DXF files.

NOTE:  If you ever redeploy the alfresco.war file, this change will be undone and will need to reapplied.

Thursday, May 25, 2017

Alfresco SSL with Apache Proxy Server

In this post we’ll see how to set up a proxy server that will enable Alfresco to be accessed via SSL.

We’ll use an Apache server as the proxy server running on Ubuntu Linux 14.04.

Alfresco 5.2 documentation describes two ways to set up SSL:

The first method requires only changes to the standard Tomcat configuration.  This method is recommended for use in a test environment because, while the method may be simpler than the second, the change can affect performance.

The second method  is to set up SSL is by using a proxy server that handles all incoming traffic. This method is recommended for production environments.  It adds an extra layer of security between the application server and incoming requests.  You should note that Alfresco now requires the server to be configured to use SSL in order to enable Alfresco Office Services (AOS) functionality (for AOS 1.1.3+).

In this article we’ll look in detail at the second of these two methods, enabling SSL by using a proxy server.

Note that no changes are made to the standard Alfresco installation that will be fronted by the Apache proxy server.  The default configuration for Tomcat in Alfresco is to use AJP on port 8009, as defined in the Tomcat configuration file server.xml.

Install Needed Software

Ideally the proxy server should run on separate server hardware or another VM.

First, install the Apache server and mod_jk software:

sudo apt-get update
sudo apt-get install apache2
sudo apt-get install libapache2-mod-jk

Then, enable mod_jk, mod_ssl and mod_rewrite:


sudo a2enmod jk
sudo a2enmod ssl
sudo a2enmod rewrite


Then, restart the Apache service:


sudo /etc/init.d/apache2 restart 

Generate SSL Certificate and Key

For a production system, you would obtain a public key certificate for SSL from a certificate authority.  For initial testing, the proxy server can be set up using self-signed certificates.

Skip this section if you already have a public certificate.

Create a self-signed certificate as follows:


mkdir /tmp/certs
cd /tmp/certs

# Generate a key with a passphrase
openssl genrsa -des3 -out server.key 1024 

# Create a key
openssl rsa –in server.key -check

# Create an insecure key [A copy of the key that doesn’t use a passphrase]
openssl rsa -in server.key -out server.key.nopassphrase

# Rename the key files
mv server.key server.key.passphrase
mv server.key.nopassphrase server.key

# Create the Certificate Signing Request (CSR)
#   Enter requested information
openssl req -new -key server.key -out server.csr

# Test the signing request
openssl req -noout -text -in server.csr

# Create a self-signed certificate
openssl x509 -req -days 9999 -in server.csr -signkey server.key -out server.crt

# Test self-signed certificate:
openssl x509 -in server.crt -noout -text

Installing the Certificate and Key

Ubuntu stores certificates in the /etc/ssl/certs directory.
Keys are stored in the directory /etc/ssl/private.

Move the certificate and key to these directories.
For the self-signed certificates created in the previous section, we would do the following:


cd /tmp/certs
sudo chmod 600 *.key
sudo cp *.crt /etc/ssl/certs
sudo cp *.key /etc/ssl/private

Configure Apache to know about Alfresco

Edit file 000-default.conf

We can configure Apache to intercept https services and redirect them to Alfresco in the 000-default.conf file:


cd /etc/apache2/sites-enabled
sudo vi 000-default.conf

At the top of the 000-default.conf file, edit the section <VirtualHost *:80>:


<VirtualHost *:80>
    RewriteEngine On
    RewriteRule ^(.*) https://%{SERVER_NAME}/$1 [R,L]
…
</VirtualHost>

You can copy this code as-is. There is no need to edit the value SERVER_NAME.

At the bottom of the file, add the following new section:

<VirtualHost *:443>
          ServerName {servername}
          SSLEngine On
          SSLCertificateFile /etc/ssl/certs/server.crt
          SSLCertificateKeyFile /etc/ssl/private/server.key 
          <Location />
              SSLRequireSSL On
              SSLVerifyClient optional
              SSLRenegBufferSize 104860000
              SSLVerifyDepth 1
              SSLOptions +StdEnvVars +StrictRequire
          </Location>
          # Send everything for the context / to worker named worker1 via ajp13
          JkMount /* ajp13_worker
</VirtualHost>

Edit the worker file workers.properties

Edit the default workers file.


cd  /etc/libapache2-mod-jk
sudo vi workers.properties 

This file contains an entry for the hostname.  The default is localhost.  Change the value for host to be the hostname of the machine where Alfresco is running.  

worker.list=ajp13_worker
worker.ajp13_worker.port=8009
worker.ajp13_worker.host=your-internal-alfresco-host-name
worker.ajp13_worker.type=ajp13
worker.ajp13_worker.lbfactor=1

Edit the Apache file httpd.conf

cd /etc/apache2
sudo vi httpd.conf

This file may not already exist and need to be created.
Add the following line to the bottom of that file:

ServerName {your-server-name}

Restart Apache 

Then, restart the Apache service:


sudo /etc/init.d/apache2 restart 

Access Alfresco via SSL

SSL should now be configured.

The URL https://{hostname}/share will take you to the Share login page. 

This URL will get you to the general welcome page at the top level of Alfresco: https://{hostname}. 

References

Monday, April 10, 2017

Alfresco Troubleshooting: JMX Settings

The alfresco-global.properties file is a central place for Alfresco configuration and extension.  This properties file is created automatically during the Alfresco wizard installation.

While the use of a single central file for configurations simplifies management of Alfresco, any changes to settings made to the alfresco-global.properties file require that the server be restarted before the changes become effective.  In most cases, the global properties file is changed infrequently, so having to do a restart is not that much of a problem.

But if changes to the alfresco-global.properties file need to be made frequently, especially in a critical production system, it isn't desirable to have to restart the server whenever a configuration change is needed.

To enable configuration updates while the server is still running, Alfresco provides JMX as an alternative method for being able to change configuration settings on a system that is running.  Using a JMX client like JConsole, you can edit any configuration setting, and those changes then are persisted into the database and override any setting in the alfresco-global.properties file.

Note that JMX settings stored in the database take precedent over the settings found in the alfresco-global.properties file and that the alfresco-global.properties file does not get updated after a parameter is changed by JMX. 

What this means is that JMX is the ultimate source of the current settings and any other settings found in alfresco-global.properties. Note that configuration files may not be accurate because they have been overridden or outdated by JMX.  This is why very often when a troubleshooting case is submitted to Alfresco Support the first request from the Alfresco support team is to see a dump of your JMX system settings.

Instructions for how to download the JMX settings dump differ depending on which version of Alfresco you are running:
In earlier versions of Alfresco, JConsole was automatically included as part of a complete Alfresco stack install.  It was located in the java/bin directory of the Alfresco home area.  In Alfresco 5.2.x, you will need to download JConsole or other JMX tool.

Detailed instructions for how to access Alfresco via JMX can be found here, and a useful blog post about how to troubleshoot JMX setup issues can be found here.

The standard URL for accessing JMX on Alfresco is:

service:jmx:rmi:///jndi/rmi://<hostname>:50500/alfresco/jmxrmi

Default credentials to access Alfresco JMX are:

userid: controlRole
password: change_asap

One project for troubleshooting Alfresco is the GitHub project called Alfresco Support Tools. This project includes a number of useful tools for troubleshooting Alfresco systems.  The tools are available from the Enterprise Alfresco Admin Console.  After installing the AMP from this project, the following options become available, as shown below.



One feature of the Alfresco Support Tools project called JMX Settings.  This option shows a list of the parameters that have been overridden with JMX settings.
An example screenshot is shown below.



Monday, April 3, 2017

How can I reset the Batch Instance Identifier (ID) value in Ephesoft?

Sometimes, for an Ephesoft deployment, it is advantageous to reset the Batch Instance Identifier (ID) or BI#. This might also be required because there is a "feature", some would say a bug, in MariaDB where the sequence value will reset to '1' when there are no batches in the queue and the DB is bounced.

First, we should determine the current BI# using the following command:

            select ID from BATCH_INSTANCE;

NOTE: It will be the highest value returned.

Remember the Batch Instance Identifier is displayed in Hexadecimal format when viewed in the Ephesoft interface. However, we will use an integer when updating the BI# at the DB level and Ephesoft will convert it to a Hexa Decimal value.  In this first example, we will set the BI# to '40001'. Ephesoft will display this as 'BI9C41'.

           alter table BATCH_INSTANCE auto_increment = 40001;

You can check the value using the previous select statement after you submit your next batch.

If you want to start with a specific Hexadecimal value, say A100, you will need to first convert it to a decimal. In this case, the decimal value '41216' would be used.

            alter table BATCH_INSTANCE auto_increment = 41216;

NOTE: To verify that the change has occurred you will need to process a new Ephesoft batch.