Quản lý cấu hình web - part 42 pptx

It is useful to maintain your customization files in some configuration management system such as CVS or SVN, which helps you to easily maintain and back up.. Alfresco deployed as a Repo

The process you follow to maintain and back up your customization files depends upon the development process you follow within your organization It is useful to maintain your customization files in some configuration management system such as CVS or SVN, which helps you to easily maintain and back up

Membership data

If you have used the Alfresco out-of-the-box membership system, then the data is stored in the relational database You don't have to do any special task to back up the data as you are already backing up the relational database tables

If you have used an external membership system such as Active Directory or

OpenLDAP to have a single sign-on or centralized identity management system, then you must consider backup of your membership data as well

You will have access to back-up tools based on the membership system you have used Ensure that the data in the external membership system is backed up

Log files

The location of the log files depend upon the application server For the Tomcat installation, the log files are located at <install_folder> itself Tomcat application server creates a log file per day The current log file is named alfresco.log and at the end of the day, the log file will be backed up as alfresco.log.YYYY-MM-DD (for example, alfresco.log.2010-03-25)

Based on the usage of the system and on the logging level, the size of these log files might be pretty big Hence, it is a good practice to back up the older log files and remove them from the current location to save hard disk space

Backup frequency

The frequency at which you take backup really depends upon the nature of the application, your high availability requirements, and the Alfresco deployment option you have chosen

For example, you can consider only a one-time backup of customization files

You can back up the files whenever you enhance the application or upgrade the application to newer versions

Since the content, metadata, and tasks change very frequently, regular backup

of the Alfresco filesystem and relational database is required You have to consider the business risk and system resources availability while deciding on the

back-up frequency

Backup is based on Alfresco deployment

If your application is highly accessed by thousands of users, then it is important for you to deploy Alfresco in a clustered environment If it is a critical application such

as finance or insurance, then you should consider deploying Alfresco in hot back-up mode with master-slave configuration The data backup policy and process might be different based on the way you have deployed Alfresco

The typical process to back up Alfresco repository is as follows:

1 Stop Alfresco to ensure that no one can make changes during the backup

2 Export the MySQL (or other) database

3 Back up the Alfresco alf_data directory

4 Start Alfresco

To restore Alfresco repository:

1 Stop Alfresco

2 Delete the alf_data folder and restore the alf_data folder that you backed

up earlier

3 Drop the database and import the database that you have exported

4 Start Alfresco

Alfresco deployed as a Repository Application

Server

In this deployment (shown in the following figure), the web application becomes the host for an embedded repository and remote access is via the application, that is, HTTP This is the default deployment option chosen by the Alfresco installer This means the repository automatically benefits from any enhanced features provided by higher-end web application servers For example, the repository can be embedded inside Apache Tomcat for the lightest weight deployment, but also embedded inside J2EE-compliant application servers from JBoss, Oracle, or IBM to take advantage of distributed transactions, and much more:

In this deployment option, you need to take the backup of the alf_data folder and the database There will be one copy of customization files

Alfresco deployed as a hot backup

In this deployment, as shown in the following figure, one Repository server is

designated the master and another completely separate Repository server is

designated the slave The live application is hosted on the master, and as it is used, synchronous and asynchronous replication updates are made to the slave, that is, the backup The backup remains in read-only mode If for some reason, the master breaks down, it is a relatively simple task to swap over to the slave to continue operation

In this deployment option, you don't need to take a regular backup as the data is getting backed up automatically

Upgrading to new versions of Alfresco

You can consider upgrading to a new version of Alfresco if you are expecting one of the following benefits:

• Security patches

• Bug fixes

• New features

• Compatibility with other systems

Even if you are not getting the benefits listed earlier, sometimes you might consider upgrading to a newer version, as you do not want to maintain a big gap between the Alfresco version on which your application is currently running and the latest Alfresco version If this gap is too big, it might be very expensive for you to upgrade later on This is the scenario with most enterprise software

Alfresco has upgrade scripts, which helps you to upgrade to newer versions

automatically However, it is essential to follow certain best practices while upgrading your system Always try upgrading the test or staging server first before trying on production server It is essential that you back up your existing data before attempting

an upgrade Follow the information and instructions given in the Data backup section.

Upgrading to a minor release

An Alfresco minor (or dot) release typically contains bug fixes and minor

enhancements There will not be any new features An example is upgrading from Alfresco 3.2 to 3.2.1 release

Since there are no new features, typically, the database schema remains the same In this situation, you can replace only the web application (WAR) file to upgrade The WAR file (alfresco.war) for Tomcat installation is located in the <install_ folder>/tomcat/webapps folder

Follow these steps for minor upgrades:

1 Download the latest alfresco.war file from the Alfresco website

2 Stop Alfresco

3 Back up all of the data including customization files (as explained in the earlier sections)

4 Delete the web application folder <install_folder>/tomcat/

webapps/alfresco

5 Replace the alfresco.war file in the <install_folder>/tomcat/webapps

folder with the latest one

6 Restore the customization files

7 Start Alfresco

Test your application after upgrading it to ensure that the upgrade is successful

Upgrading to a major release

An Alfresco major release typically contains new features, performance enhancements, and bug fixes An example is upgrading from Alfresco 2.x to 3.x releases

The upgrade scripts will be executed automatically by the server when starting up

For example, let us assume that you are using the Tomcat bundle of Alfresco 2.1 (installed in C:\alfresco2.1 folder) on a Microsoft Windows operating system, and you want to upgrade to Alfresco 3.3 release

Follow these steps for major upgrades:

1 Stop Alfresco in your current installation folder C:\alfresco2.1

2 Back up all of the data, including customization files (as explained in the earlier sections)

3 Download the complete Alfresco package, Tomcat bundle for the Microsoft Windows operating system

4 Perform a new installation in a different folder (say C:\alfresco3.3)

5 Copy the older Alfresco file content folder to the newer installation (copy the

C:\alfresco2.1\alf_data folder to C:\alfresco3.3\alf_data)

6 Create a new database table and restore the relational database content from the older database Update the Alfresco configuration file in the new installation to point to this new database

7 Restore the customization files in the new installation

8 Start Alfresco in the new installation

Though most of the upgrade happens automatically, you might have to perform some manual steps to restore your customization files in a new installation

There are some configuration files and a properties file in Alfresco's config folder (/tomcat/webapps/alfresco/WEB-INF/classes/alfresco/), which you might have updated, which require manual updates

While I was writing this book, I upgraded the example application from Alfresco 2.1 version to Alfresco 3.3 version I used the following script to restore some of the customization files I manually updated some of the configuration files Refer to the batch file that I used to restore the customization files on the Windows platform

rem -rem Replaces/Adds Alfresco Custom Files to new Alfresco installation rem -set L_LOCALDIR=%CD%

set L_SRCDIR=C:\alfresco_book_21

set L_DESTDIR=C:\alfresco_book_30

rem - Replace Logos

-CD %L_DESTDIR%\tomcat\webapps\alfresco\images\logo

move AlfrescoLogo32.png AlfrescoLogo32.png-ORIGINAL

move AlfrescoLogo200.png AlfrescoLogo200.png-ORIGINAL

copy %L_SRCDIR%\tomcat\webapps\alfresco\images\logo\AlfrescoLogo32.png

copy %L_SRCDIR%\tomcat\webapps\alfresco\images\logo\AlfrescoLogo200 png

copy %L_SRCDIR%\tomcat\webapps\alfresco\images\logo\AlfrescoFadedBG png

rem - Copy files in extension folder

-CD %L_DESTDIR%\tomcat\shared\classes\alfresco\extension

copy %L_SRCDIR%\tomcat\shared\classes\alfresco\extension\custom-model-context.xml

copy %L_SRCDIR%\tomcat\shared\classes\alfresco\extension\customModel xml

copy %L_SRCDIR%\tomcat\shared\classes\alfresco\extension\web-client-config-custom.xml

CD %L_LOCALDIR%

echo I am done

pause

You can create your own batch scripts to automatically restore your customization files Typically, most of the developers use tools such as Eclipse to build and deploy the customization files to the newer installations

Test your application after upgrading it to ensure that the upgrade is successful

Cleaning up deployment history

There are two ways to clean out old deployment reports in WCM:

• Using Alfresco Explorer

• Using scheduler

Using Alfresco Explorer

Administrator and Content Managers of the web project have the right to delete the Deployment Reports Follow these steps:

1 Go to the Staging Sandbox area of the web project

2 Click on the Actions menu.

3 Click on the Delete All Deploy Reports submenu.

4 It will ask for confirmation; click on Yes to delete the reports.

Using scheduler

Using scheduler you can delete the reports older than the given number of days You can configure this scheduler to run on a periodic basis Follow the next steps to configure this scheduler

1 Rename the file deployment-attempt-cleaner-context.xml.sample

to deployment-attempt-cleaner-context.xml specified at the location

<alfresco_home>/tomcat/shared/classes/alfresco/extension

2 Configure the following highlighted changes:

<bean id="avmDeploymentAttemptCleaner"

class="org.alfresco.repo.avm.AVMDeploymentAttemptCleaner"> <! number of days to keep deployment attempts >

<property name="maxAge">

<value>1</value>

</property>

<property name="nodeService">

<ref bean="NodeService" />

</property>

<property name="transactionService">

<ref bean="TransactionService" />

</property>

<property name="searchService">

<ref bean="SearchService" />

</property>

<property name="importerBootstrap">

</property>

</bean>

<bean id="avmDeploymentAttemptCleanup"

class="org.alfresco.util.CronTriggerBean">

<property name="jobDetail">

<bean id="avmDeploymentAttemptCleanerDetail"

class="org.springframework.scheduling.quartz.JobDetailBean">

<property name="jobClass">

<value>

org.alfresco.repo.avm.AVMDeploymentAttemptCleanerJob

</value>

</property>

<property name="jobDataAsMap">

<map>

<entry key="deploymentAttemptCleaner">

<ref bean="avmDeploymentAttemptCleaner" /> </entry>

</map>

</property>

</bean>

</property>

<property name="scheduler">

<ref bean="schedulerFactory" />

</property>

<! trigger at 5:00am each day >

<property name="cronExpression">

<value>0 0 5 * * ? </value>

</property>

</bean>

This will purge all deployment attempt nodes older than one day at 5 a.m

every morning

Deployment report 1 day before

Go to the Staging Sandbox of the web project Click on the View Deployments link.

You will find the history of all of the deployment reports on that page as shown next:

Deployment report 1 day after

Since we have configured to clean up reports that are one day older, on the next day,

we can see only those reports which are deployed today All other reports, which are shown in the previous screenshot, have been purged

General maintenance tips

If you maintain the system regularly by cleaning up the database and fixing the system errors, your system runs faster Some of the tips are given in this section

Examine log files

Your log files tell you very important issues and problems about your system The level of details logged will be based on the level of logging (INFO, ERROR, and DEBUG) The log files are named as alfresco.log (current one) or

alfresco.log.YYYY-MM-DD (older ones) Examine one of the log files and you will notice the log entries made

in the following categories

• ERROR: Error occurred (requires FIX)

• WARN: Warning messages (requires your attention)

• INFO: General information about the system