Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
Note

This is Joe's modified version of Hunter's Alfresco Install document.  It describes how to install Alfresco WCM plus local MIT modifications.  Note that this document describes only version 2.1.1 3 Enterprise.

...


Note:    Next revision cycle, start building everything into
$HOME/\[app\]-\[version#\] and creating a symlink to $HOME/\[app\] so that there is
no question about what the current, in use, directory is.

Note: When downloading software to install in these instructions, unless
otherwise indicated, always download the tomcat tarball, and avoid binary
installers.  Binary installers tend to make inaccurate assumptions about what
libraries you have installed on your system, as well as other problems.

...

  1a.  You need the MIT modified version of Alfresco WCM from somewhere.  The name of the file is:
             alfresco-enterprise-tomcat-wcm-mitmods-2.1.3.tar.gz
        Note, you can also get this from our subversion repository:
             svn+ssh://svn.mit.edu/alfresco-dev/tags/release/alfresco-enterprise-tomcat-wcm-mitmods-2.1.3.tar.gz

  1b.  Log into http://customers.alfresco.com using provided Alfresco username and
   password.   Get a license from:

Wiki Markup   \   [Company Home\] - \ [Downloads\] - \ [Limited Downloads\]

   Such as:

   enterprise-network-developer-unlimited.lic

...

   2a. Suspend any services directly dependent upon Alfresco, such as Thalia
       IME.  This is highly dependent upon what that service is.

   2b. Suspend Alfresco.

Wiki Markup       cd        cd /home/alfresco-\[current version\]        ]
       ./alfresco.sh stop

   2c. Scan the process list to see when the Alfresco processes finish
       shutting down and terminate.  Repeat until no alfresco processes are left.

...

       This may take some time to do.  If it takes longer then 5 minutes, kill
       the process directly.

Wiki Markup       kill \-9 \[process number\       kill -9 [process number]

   2d. Back up the current repository, and copy the backup to a backup storage
       server.

3. Prepare the home directories.  If this system had previous installations of
   Alfresco, move the previous repository stores and database to a backup
   location.  Then create the home directories.

Wiki Markup   cd /home    mkdir    cd /home
   mkdir /home/alfresco-\[new version\]    mkdir /home/alf_data
   If this is going to be a clustered machine, create the cluster directories. Wiki Markup   mkdir /home/alf_data/cluster-A    mkdir /home/alf_data/cluster-B    mkdir /home/alf_data/cluster-\[repeat for each stack in cluster\]    mkdir /home/alf_data/replication

   Note: NO CLUSTERING

4. Unpack the software into the correct directory.

Wiki Markup   cd    cd /home/alfresco-\[new version\]    tar \]
   tar -xzvf /root/alfresco/alfresco-enterprise-tomcat-wcm-mitmods-2.1.13.tar.gz

5. Copy the alfresco.sh file from the ISDA software repository to the new
   Alfresco home directory.

Wiki Markup
   scp \[krb-id\]@\[software-repository\]:alfresco.sh /home/alfresco-\[new-version\]

   Edit the alfresco.sh file to use the local file paths.

6. Copy the license to the license directory.

Wiki Markup   cp    cp /root/alfresco/enterprise-network-developer-unlimited.lic  \    lic  \
   /home/alfresco-\[new version\]/tomcat/shared/classes/alfresco/extension/license

76. Set up the dir.root location by adding it to the
   custom-repository.properties file.

   dir.root=/home/alfresco-2.1.1-enterprise[new version]/alf_data

87. Setup MySQL database to be used by this system, if this is a new install.
   If this is an upgrade, backup the database with mysqldump.

   8a7a. Login to MySQL server as root and connect to the MySQL database

   8b7b. If this is a new install, create a new database and setup a user.

      8b17b1. Create the database.

         create database alfresco;   Where alfresco is the name of the
                                     database to create

      8b27b2. Grant permissions to user.

...

         Replace the database, password and user names as needed, to match
         the alfresco server.  Select a password that will be secure.

9.  If this is going to be the second independent instance of Alfresco on a
    server, then edit the files:

    $ALF_HOME/tomcat/webapps/alfresco/WEB-INF/classes/alfresco/alfresco-shared.properties
    $ALF_HOME/tomcat/webapps/alfresco/WEB-INF/classes/alfresco/web-client-config-wcm.xml

    Alter the option avm.remote.port to have a unique port number, and the
    ports for RMI and JMX.

8.  ONLY ONE INSTANCE PER SERVER PLEASE

9.10.  Edit the virtualization server properties file and change the server address.

...

      Edit alfresco.virtserver.domain to have the IP address of the server
      receiving the Alfresco software:

      example:  alfresco.virtserver.domain=18-92-1-223.ip.alfrescodemo.net

9a. Generate a strong password for admin and edited alfresco-virtserver.properties to set "alfresco.server.password" to this value.  

 10 11. Note: you do not need to upgrade TinyMCE or edit any jsp files.12

11. Configure the deployment script(s) and remote (deployed-to) server.  This is very dependent on the configuration of the remote server, which we don't necessarily know.  It may require more extensive changes to the script, if the remote server isn't what we expect.  If this is going to be a clustered system, move or alter the following
     files to make a cluster configuration.

    12a.  Move the following files in
          $ALF_HOME/tomcat/share/classes/alfresco/extension

       cp replicating-content-services-context.xml.sample \
           replicating-content-services-context.xml
       cp ehcache-custom.xml.sample.cluster ehcache-custom.xml
       

...

so, skip this step or pass it on to someone who knows more about the remote server.  For each deployment scenario:

  11a. Identify or create an Alfresco deployment user which has read access to the web project to be deployed. (This requires that the user has a sandbox in the web project as at least a Content Reviewer).  Note the Alfresco username and password of this user.  The password should probably be strong (e.g., random and long)

  11b. On the remote (linux) server, identify or create a remote user with write access to the desired deployment destination path.  Ensure that the root account on the Alfresco server can ssh as this user to the remote server without being prompted for a password.  If this is not already set up, you should do the following:

  • On the Alfresco server as root, run "ssh-keygen -t dsa" and accept the default location.  Also, leave the passphrase blank (maybe not the best advice but I want to ensure that the script will not be prompted for a password)
  • Copy the generated public key file (~/.ssh/id_dsa.pub) to the remote server (e.g., "scp ~/.ssh/id_dsa.pub REMOTESERVER:")
  • Log into the remote (assumed linux) server as the remote user.  (If the user doesn't exist, first log in as root and create the account with "adduser USERNAME")
  • If it does not exist, create the remote user's .ssh directory and make sure its permissions are properly set. ("mkdir ~/.ssh" and "chmod 700 ~/.ssh") 
  • Append the generated public key file you copied to the end of .ssh/authorized_keys, and make sure its permissions are properly set.  ("cat id_dsa.pub >> ~/.ssh/authorized_keys" and "chmod 600 ~/.ssh/authorized_keys")
  • Remove the generated public key file from the remote server ("rm id_dsa.pub")

Example:

Code Block

adduser deploy_bot    ###note, this is the WEB SERVER "deploy_bot" account, not the ALFRESCO "deploy_bot" account
 mkdir /home/deploy_bot/.ssh;
 chown deploy_bot /home/deploy_bot/.ssh
 chmod 700 /home/deploy_bot/.ssh;
 cat ~/id_dsa.pub >> /home/deploy_bot/.ssh/authorized_keys
 chown deploy_bot /home/deploy_bot/.ssh/authorized_keys
 chmod 600 /home/deploy_bot/.ssh/authorized_keys
 rm ~/id_dsa.pub
 chmod a+rx /home/www
 chmod a+rx /home/www/sash-server
 chmod a+rx /home/www/sash-server/servers/
 chmod a+rx /home/www/sash-server/servers/alumni/
 chown deploy_bot /home/www/sash-server/servers/alumni/webapps
 chown deploy_bot /home/www/sash-server/servers/alumni/webapps/ROOT
  • Log out of the remote server
  • Test by logging into the Alfresco server as root and running "ssh -l USERNAME REMOTESERVER".  If you get in as the remote user without being prompted for a password, congratulations.   Note: in this step, accept the host key.  This stores the host key in known_hosts and is actually important, since you don't want the deployment script to be prompted to accept or not accept the host key.

  11c. Copy ${ALF_HOME}/deploy/deploy.sh to a scenario-specific file, like ${ALF_HOME}/deploy/deploy-to-someplace.sh

   There are four environment variables we care about. 

    DEPLOY_REMOTE_SERVER is the fully qualified hostname of the remote server.  (e.g., "export DEPLOY_REMOTE_SERVER=isda-ist1.mit.edu")
    DEPLOY_REMOTE_USER is the username (from 13b.) of an account on the remote server with passwordless ssh login access.  (e.g., "export DEPLOY_REMOTE_USER=deploy_bot")
    DEPLOY_REMOTE_DESTPATH is the path to the directory on the remote machine to which you want to deploy.  (e.g., "export DEPLOY_REMOTE_DESTPATH=/home/apache-tomcat-5.5.23/webapps/ROOT")
 

    DEPLOY_ALFRESCO_USER is the username (from 13a.) for the Alfresco account with read access to the web project to be deployed (e.g., "export DEPLOY_ALFRESCO_USER=deploy_bot")
    DEPLOY_PASSWORD is the Alfresco password for the DEPLOY_ALFRESCO_USER user.  (e.g., "export DEPLOY_PASSWORD=deploy_bot_password_or_something")

  11d. Edit $ALF_EXT/web-client-config-custom.xml and change the <deployment> element to include the deployment command(s)

Code Block

<commands>
...
         <command name="deploy-to-someplace" program="bash">
                       <param>-c</param>
                       <param>${ALF_HOME}/deploy/deploy-to-someplace.sh</param>
                   </command>
...
         </commands>





12. Edit $ALF_EXT/custom-authority-services-context.xml and add any new administrators (e.g. <value>jcalz_admin</value>) to the admin list. 
13. Do a /$ALF_HOME/alfresco.sh start, and wait for the server to come up.
14.  FROM THE WEB BROWSER, log into alfresco with the admin/admin password

15.  Go into User Management and set the admin account password to the strong password from step 9a.

16  Create any deployment accounts, and set their passwords, from step 11a.

17 Create any other admin user accounts from step 12.

HOW TO MAKE ALFRESCO RUN AS NON-ROOT

1.      Enable IP forwarding

2.      In fileservers-custom.xml:

   <config evaluator="string-compare" condition="CIFS Server">
          <serverEnable enabled="true"/>
     <tcpipSMB port="1445" platforms="linux"/>
     <netBIOSSMB sessionPort="1139" namePort="1137" datagramPort="1138" platforms="linux"/>
    </config>

3.      Set up iptables redirects:

iptables -t nat -A PREROUTING -p tcp --dport 445 -j REDIRECT --to-ports 1445
iptables -t nat -A PREROUTING -p tcp --dport 139 -j REDIRECT --to-ports 1139
iptables -t nat -A PREROUTING -p udp --dport 137 -j REDIRECT --to-ports 1137
iptables -t nat -A PREROUTING -p udp --dport 138 -j REDIRECT --to-ports 1138

4.      chown repos:repos /var/run/alfresco.pid

5.      Make sure the path through /home/www/apache/modules/* is readable/executable by repos

6.      /sbin/mount.cifs should be root:repos, SUID, and o-rwx

7.      In /etc/fstab:

//localhost/avm  /home/repos/mnt/this-avm       cifs    user,noauto     0 0

8.      chown root:repos /sbin/mount.cifs

9.      chmod u+s,o-rwx /sbin/mount.cifs

10.    Note that the deploy scripts need to be updated to use the 1445 port for cifs (since local traffic is not forwarded).  Also, the mount point for cifs needs to be under /home/repos, not /mnt.  For whatever reason, we need to use "mount.cifs" directly instead of "mount", which always wants you to be root no matter if the SUID bit is there or not.  Finally, the sharename must be "//localhost/avm" to match the fstab entry.  Relevant changes in script:

   export MOUNT_POINT=~/mnt/this-avm
    #instead of /mnt/this-avm

   umount -t cifs //localhost/avm ${MOUNT_POINT}/ 
     #instead of //${HOSTNAME}/avm

   mount.cifs //localhost/avm ${MOUNT_POINT}/ -o port=1445,user=${DEPLOY_ALFRESCO_USER}%${DEPLOY_ALFRESCO_PASSWORD} 
     #"mount.cifs" instead of "mount -t cifs"; "localhost" instead of "${HOSTNAME}"; "port=1445" instead of default behavior (445)

11.     Since we're now authenticating to remote servers as repos@hostname.mit.edu instead of root@hostname.mit.edu, we need to repeat step 11b from the original document to reflect that. Here's the new version:

Panel

  11b. On the remote (linux) server, identify or create a remote user with write access to the desired deployment destination path.  Ensure that the root account on the Alfresco server can ssh as this user to the remote server without being prompted for a password.  If this is not already set up, you should do the following:

  • On the Alfresco server as repos, run "ssh-keygen -t dsa" and accept the default location.  Also, leave the passphrase blank (maybe not the best advice but I want to ensure that the script will not be prompted for a password)
  • Copy the generated public key file (~/.ssh/id_dsa.pub) to the remote server (e.g., "scp ~/.ssh/id_dsa.pub REMOTESERVER:")
  • Log into the remote (assumed linux) server as the remote user.  (If the user doesn't exist, first log in as root and create the account with "adduser USERNAME")
  • If it does not exist, create the remote user's .ssh directory and make sure its permissions are properly set. ("mkdir ~/.ssh" and "chmod 700 ~/.ssh") 
  • Append the generated public key file you copied to the end of .ssh/authorized_keys, and make sure its permissions are properly set.  ("cat id_dsa.pub >> ~/.ssh/authorized_keys" and "chmod 600 ~/.ssh/authorized_keys")
  • Remove the generated public key file from the remote server ("rm id_dsa.pub")

Example:

Code Block

adduser deploy_bot    ###note, this is the WEB SERVER "deploy_bot" account, not the ALFRESCO "deploy_bot" account
 mkdir /home/deploy_bot/.ssh;
 chown deploy_bot /home/deploy_bot/.ssh
 chmod 700 /home/deploy_bot/.ssh;
 cat ~/id_dsa.pub >> /home/deploy_bot/.ssh/authorized_keys
 chown deploy_bot /home/deploy_bot/.ssh/authorized_keys
 chmod 600 /home/deploy_bot/.ssh/authorized_keys
 rm ~/id_dsa.pub
 chmod a+rx /home/www
 chmod a+rx /home/www/sash-server
 chmod a+rx /home/www/sash-server/servers/
 chmod a+rx /home/www/sash-server/servers/alumni/
 chown deploy_bot /home/www/sash-server/servers/alumni/webapps
 chown deploy_bot /home/www/sash-server/servers/alumni/webapps/ROOT
  • Log out of the remote server
  • Test by logging into the Alfresco server as repos and running "ssh -l USERNAME REMOTESERVER".  If you get in as the remote user without being prompted for a password, congratulations.   Note: in this step, accept the host key.  This stores the host key in known_hosts and is actually important, since you don't want the deployment script to be prompted to accept or not accept the host key.