|
|
The SAS Information Delivery Portal Web Application enables you to offer Web access to information and applications that are required for workers to perform their jobs. Each installation of the Portal yields a custom Web application. These instructions step you through the Portal installation. When you have finished, you have a demo Portal that you can use to test your installation. The demo Portal is also an extremely useful tool to help you configure and customize the portal for your enterprise.
The SAS Information Delivery Portal, Release 1.1.3 (hot fix 3) is a hot fix that is applied to an existing 1.1 (or a subsequent hot fix release) installation. After unpacking the SAS Information Delivery Portal, Release 1.1, unpack the hot fix into the same location. If this is a new installation, follow the instructions outlined in this document. If this is an upgrade for an existing 1.1 installation, follow the same instructions as a new installation, with minor exceptions. These exceptions are pointed out in the sections marked Upgrade Note. These notes describe installation differences between upgrading and a new install.
To install the SAS Information Delivery Portal Web Application, do the following:
To successfully complete the Portal installation, you must have access to your LDAP server, your Web server and servlet container, your Java 2 SDK, and your SAS server. To successfully configure the Portal installation, you must be familiar with the configuration of each server.
If you do not have a servlet container installed or you would like to run the Portal in a controlled environment, we recommend that you use the Tomcat Servlet container, version 3.2, available from the Apache Jakarta project to get running quickly. This is a free Java Servlet, version 2.2 compliant container. See Installing a Servlet Container for details. Please review your requirements when deciding on a servlet container to use in your production environment.
If you do not have an LDAP server installed, we recommend that you use the Netscape Directory Server. See Setup Your LDAP Server for details.
Upgrade Note: This step is not required if you already have release 1.1 (or a subsequent hot fix release) installed and the setup directory still exists. Please use the existing setup directory when applying the 1.1.3 hot fix.
In the original 1.1 readme, we instructed you to unpack the idportal archive into a temporary location. We now recommend using a permanent location for the reasons described below.
To install the idportal.zip archive, use an unzip utility to unpack the idportal.zip file. You should unpack to a permanent location because you will use this directory to redeploy the Portal Web application when configuration changes are needed, when upgrades are available, or when certain types of content need to be deployed.
To install the idportal.tar archive, use the tar utility to unpack the idportal.tar file. You should unpack to a permanent location because you will use this directory to redeploy the Portal Web application when configuration changes are needed, when upgrades are available, or when certain types of content need to be deployed.
When you unpack the archive, the files are extracted to a directory named Portal1.1, which is created in the location you specify. This directory will be referred to as the Portal setup directory. This directory contains the Portal configuration tool and the following subdirectories: LDAP, Portal, JavaExtensions, SASUpdates, SASDemos, and ServletDemos.
Upgrade Note: The 1.1.3 hot fix is a cumulative hot fix. It includes all the updates from the 1.1.1 and 1.1.2 hot fixes and all the new updates from the 1.1.3 hot fix. Since it is a hot fix, it only contains updated files. When unpacked, the hot fix files will replace existing files in the 1.1 setup directory. Since existing 1.1 files are replaced, it is critical that you backup the 1.1 setup directory to avoid loosing any customization. All customization changes will need to be re-applied to the new hot fix files. If the 1.1 setup directory no longer exists, you will need to unpack release 1.1, unpack the 1.1.3 hot fix, and then re-apply any customization changes.
After unpacking the SAS Information Delivery Portal, Release 1.1, unpack the hot fix into the same location. When unpacking the hot fix, make sure your unzip or tar utility overwrites existing files.
Upgrade Note: Replace the install.properties unpacked during the installation of the hot fix with the backup copy you made.
The SAS Information Delivery Portal contains components that have been updated since the 1.1 release of the Portal. This section highlights updates that are available.
The SAS Information Delivery Portal Server Component, Integration Technologies, has a hot fix to resolve issues with publishing and non-Latin 1 character sets. This hot fix, 82IH03, can be downloaded from the SAS Technical Support Hot Fix Web site.
Release 1.1 of the SAS Information Delivery Portal includes AppDev Studio, release 2.0. The Portal web application also includes two JAR files, webAF.jar and webAFServerPages.jar, that correspond to those released with AppDev Studio, release 2.0. The 1.1.3 hot fix includes JAR files that update the Portal web application to those shipped with AppDev Studio, release 2.0.2.
In the future, you can make use of more recent AppDev Studio fixes in the Portal by copying the webAF.jar and webAFServerPages.jar files into the Portal1.1/Portal/WEB-INF/lib subdirectory of the setup directory before creating and deploying the Portal WAR file.
Release 1.1 of the SAS Information Delivery Portal includes Enterprise Guide, release 1.2. A new release of Enterprise Guide is now available.
The SAS Information Delivery Portal ships with a configuration tool that streamlines the configuration of property files and LDIF files, and the creation of a Web archive, WAR, file. A WAR file is a Web application deployment mechanism introduced in the Java Servlet Specification, version 2.2.
When a WAR file is deployed into a servlet container, the name of the WAR file determines the name of the Web application. By default, the Portal configuration tool generates the file Portal.war. When deployed, this creates a Web application named Portal. If you wish to use a name other than Portal or you wish to have more than one instance of the Portal installed in a servlet container, you can do this. First, you must use the new name instead of Portal when configuring the $DOC_BASE$, $SERVLET_CONFIG_DIR$, and $SERVLET_URL$ properties. Second, you will need to rename the Portal.war file generated by the Portal configuration tool to use the new name instead of Portal before deploying the Web application. The new name is case sensitive.
Upgrade Note: If you already have release 1.1 installed, you can use your existing install.properties. To do this, copy the version of install.properties that you backed up into the Portal1.1 setup directory. After copying the file, skip to step 3 to continue.
enablePersonEntries property with false. If your site has not defined a People organizational unit in LDAP, leave the value of this property as true.
enableGroupEntries property with false. If your site has not defined a Groups organizational unit in LDAP, leave the value of this property as true.
enableMddbEntries property with true. If you wish to disable the MDDB and webEIS document demos, leave the value of this property as false.
enableSamples property with false. If you wish to enable the samples, leave the value of this property as true.
enableDemo property with false. If you wish to enable the demo, leave the value of this property as true.
$SERVLET_FILE_SEPARATOR$ property with the appropriate file separator for the operating system that the servlet container is running on. On Microsoft® Windows® platforms, this value should be \\; on UNIX® platforms, it should be /.
$SAS_FILE_SEPARATOR$ property with the appropriate file separator for the operating system that the SAS server is running on. On Microsoft Windows platforms, this value should be \\; on UNIX platforms, it should be /.
$SAS_CONTEXT$ property with the appropriate naming context for your server. If you have already installed and configured an LDAP server for use with Integration Technologies, you must use the same value that you provided for $SAS_CONTEXT$ when you edited the containers.ldif file. The default value for $SAS_CONTEXT$ is o=ACE Industries,c=US.
$PERSON_CONTEXT$ property with the appropriate naming context where person entries are stored on your server. The default value for $PERSON_CONTEXT$ is ou=People,o=ACE Industries,c=US.
$GROUP_CONTEXT$ property with the appropriate naming context where group entries are stored on your server. The default value for $GROUP_CONTEXT$ is ou=Groups,o=ACE Industries,c=US.
$SAS_INSTALL_DIR$ property with the location of your SAS server installation. For example, your SAS installation directory might be c:\\program files\\sas institute\\sas\\v8 on Windows platforms or /usr/local/sas on UNIX platforms. Note that the backslash character (\) is a special character in a properties file; therefore, you must escape it with a second backslash (\\).
$SAS_DEMO_DIR$ property with the location of the demo files on your SAS server. For example, your demo directory might be c:\\portal\\Portal1.1\\SASDemos on Windows platforms or /portal/Portal1.1/SASDemos on UNIX platforms. This example assumes you are using the portal setup directory, which was installed in the portal directory. Note that the backslash character (\) is a special character in a properties file; therefore, you must escape it with a second backslash (\\).
$SERVLET_DEMO_DIR$ property with the location of the demo files on your servlet container server. For example, your demo directory might be c:\\portal\\Portal1.1\\ServletDemos on Windows platforms or /portal/Portal1.1/ServletDemos on UNIX platforms. This example assumes you are using the portal setup directory, which was installed in the portal directory. Note that the backslash character (\) is a special character in a properties file; therefore, you must escape it with a second backslash (\\).
$SAS_SERVER$ property with the fully qualified name of the machine where your SAS server is running. For example, if your SAS server is running on sasserver.ace.com then the value for $SAS_SERVER$ is sasserver.ace.com.
$SAS_SERVER_PORT$ property with the port number that the object spawner is listening on. The default value for $SAS_SERVER_PORT$ is 5307.
$SAS_OPERATOR_PORT$ property with the object spawner operator port. The default value for $SAS_OPERATOR_PORT$ is 5308.
$SAS_DOMAIN$ property with the fully qualified domain name of the machine where your SAS server is running. For example, if your SAS server is running on sasserver.ace.com then the value for $SAS_DOMAIN$ is ace.com.
$SAS_LOGIN_NAME$ property and the $SAS_LOGIN_PASSWORD$ property with a valid login (user name and password) for the operating system that the SAS server is running on. For example, you might replace the value of $SAS_LOGIN_NAME$ with sasuser and the value of $SAS_LOGIN_PASSWORD$ with sasuser1.
The Portal Web application uses the defined user name and password when logging in to the SAS server (through an object spawner) on behalf of the requesting Portal user.
$LDAP_HOST$ property with the location to your LDAP directory server. For example, the value of $LDAP_HOST$ might be ldapserver.ace.com.
$LDAP_PORT$ property with the port your LDAP directory server uses. For example, the value of $LDAP_PORT$ might be 389, the directory server default.
$CONTENT_DIR$ property with the directory on the servlet container server that the Portal should use to cache content files. Make sure that the directory you specify is in a secure location to prevent unauthorized access to the cached content. For example, the value of $CONTENT_DIR$ might be c:\\portal\\content on Windows platforms or /portal/content on UNIX platforms. Note that the backslash character (\) is a special character in a properties file; therefore, you must escape it with a second backslash (\\).
$SERVLET_PREFIX$ property with the URL to the servlet as defined in the servlet container installation. The following list shows values for select servlet containers.
Installation Tip for Apache Tomcat 3.2: Leave $SERVLET_PREFIX$ blank.
Installation Tip for Apache Tomcat 4.0: Leave $SERVLET_PREFIX$ blank.
Installation Tip for Allaire JRun 3.0: Leave $SERVLET_PREFIX$ blank.
Installation Tip for BEA WebLogic 5.1: Leave $SERVLET_PREFIX$ blank.
Installation Tip for BEA WebLogic 6.1: Leave $SERVLET_PREFIX$ blank.
Installation Tip for iPlanet WebServer 4.1: Leave $SERVLET_PREFIX$ blank.
Installation Tip for IBM WebSphere 3.5: Leave $SERVLET_PREFIX$ blank.
Installation Tip for IBM WebSphere 4.0: Leave $SERVLET_PREFIX$ blank.
$DOC_BASE$ property with the Web server relative path to the Portal images and help files. The default value is /Portal. Change this value to specify the location of the Portal directory if you did not copy it to the root directory of your Web server.
$SERVLET_CONFIG_DIR$ property with the directory on the servlet container server where Portal properties files are located. The location of this directory depends on where your servlet container is installed and where that servlet container deploys the contents of the Portal WAR file. In most cases the directory will end with Portal\\WEB-INF on Windows platforms and Portal/WEB-INF on UNIX platforms. The following list shows possible values for select servlet containers running on Windows platforms.
Installation Tip for Apache Tomcat 3.2: Set to: $SERVLET_CONFIG_DIR$: c:\\jakarta-tomcat\\webapps\\Portal\\WEB-INF
Installation Tip for Apache Tomcat 4.0: Set to: $SERVLET_CONFIG_DIR$: c:\\jakarta-tomcat\\webapps\\Portal\\WEB-INF
Installation Tip for Allaire JRun 3.0: Set to: $SERVLET_CONFIG_DIR$: c:\\Program Files\\Allaire\\JRun\\servers\\default\\Portal\\WEB-INF
Installation Tip for BEA WebLogic 5.1: Set to: $SERVLET_CONFIG_DIR$: c:\\Weblogic\\myserver\\public_html\\Portal\\WEB-INF
Installation Tip for BEA WebLogic 6.1: Set to: $SERVLET_CONFIG_DIR$: c:\\bea\\wlserver6.1\\config\\mydomain\\applications\\Portal\\WEB-INF
Installation Tip for iPlanet WebServer 4.1: Set to: $SERVLET_CONFIG_DIR$: c:\\Netscape\\Server4\\docs\\Portal\\WEB-INF
Installation Tip for IBM WebSphere 3.5: Set to: $SERVLET_CONFIG_DIR$: c:\\Websphere\\AppServer\\hosts\\default_host\\Portal\\web\\WEB-INF
Installation Tip for IBM WebSphere 4.0: Set to: $SERVLET_CONFIG_DIR$: c:\\WebSphere\\AppServer\\installedApps\\Portal.ear\\Portal.war\\WEB-INF
Note that the backslash character (\) is a special character in a properties file; therefore, you must escape it with a second backslash (\\).
$SERVLET_URL$ property with the URL used to access the Portal. The location of this URL depends on where the Portal is installed in your servlet container. The following list shows possible values for select servlet containers.
Installation Tip for Apache Tomcat 3.2 (standalone): Set to: $SERVLET_URL$: http://webserver.ace.com:8080/Portal/idp
Installation Tip for Apache Tomcat 3.2: Set to: $SERVLET_URL$: http://webserver.ace.com/Portal/servlet/idp
Installation Tip for Apache Tomcat 4.0 (standalone): Set to: $SERVLET_URL$: http://webserver.ace.com:8080/Portal/idp
Installation Tip for Apache Tomcat 4.0: Set to: $SERVLET_URL$: http://webserver.ace.com/Portal/idp
Installation Tip for Allaire JRun 3.0: Set to: $SERVLET_URL$: http://webserver.ace.com:8100/Portal/idp
Installation Tip for BEA WebLogic 5.1: Set to: $SERVLET_URL$: http://webserver.ace.com:8080/idp
Installation Tip for BEA WebLogic 6.1: Set to: $SERVLET_URL$: http://webserver.ace.com:7001/idp
Installation Tip for iPlanet WebServer 4.1: Set to: $SERVLET_URL$: http://webserver.ace.com/Portal/idp
Installation Tip for IBM WebSphere 3.5: Set to: $SERVLET_URL$: http://webserver.ace.com/Portal/idp
Installation Tip for IBM WebSphere 4.0: Set to: $SERVLET_URL$: http://webserver.ace.com/Portal/idp
$PORTAL_USER_PASSWORD$ property with the password for the privileged Portal user. The default value for $PORTAL_USER_PASSWORD$ is portal1.
$PORTAL_GUEST_PASSWORD$ property with the password for the Portal guest account. The default value for $PORTAL_GUEST_PASSWORD$ is guest1.
$PORTAL_DEMO_PASSWORD$ property with the password for the Portal Demo user. The default value for $PORTAL_DEMO_PASSWORD$ is demo1.
$PORTAL_ADMIN_PASSWORD$ property with the password for the Portal Admin user. The default value for $PORTAL_ADMIN_PASSWORD$ is admin1.
$PORTAL_DWADMIN_PASSWORD$ property with the password for the DW Admin user. The default value for $PORTAL_DWADMIN_PASSWORD$ is dwadmin1.
$DEFAULT_LOCALE$ property with the locale that users will see if their browser is not set to request a locale available in the $SUPPORTED_LOCALES$ list. The default value for $DEFAULT_LOCALE$ is en_US.
$SUPPORTED_LOCALES$ property with a comma separated list of locales that are supported at the installation site. The default value for $SUPPORTED_LOCALES$ is en_US.
Installation Tip for BEA WebLogic 6.1: In order for the Portal to display correctly, an extra servlet needs to be defined and mapped. Save a copy of this file before modifying it.
Modify ...\Portal1.1\Portal\WEB-INF\web.xml.orig by making three changes. First, insert the following after the last servlet definition (Document) which is about in the middle of the file.
<servlet>
<servlet-name>ContentServlet</servlet-name>
<servlet-class>com.sas.servlet.util.ContentServlet</servlet-class>
</servlet>
Second, insert the following after the last servlet mapping (Document) which is about in the middle of the file.
<servlet-mapping>
<servlet-name>ContentServlet</servlet-name>
<url-pattern>/servlet/com.sas.servlet.util.ContentServlet</url-pattern>
</servlet-mapping>
Installation Tip for IBM WebSphere 3.5 and 4.0: In order for the Portal to display correctly, an extra servlet needs to be defined and mapped. Save a copy of this file before modifying it.
Modify ...\Portal1.1\Portal\WEB-INF\web.xml.orig by making three changes. First, insert the following after the last servlet definition (Document) which is about in the middle of the file.
<servlet>
<servlet-name>ContentServlet</servlet-name>
<servlet-class>com.sas.servlet.util.ContentServlet</servlet-class>
</servlet>
Second, insert the following after the last servlet mapping (Document) which is about in the middle of the file.
<servlet-mapping>
<servlet-name>ContentServlet</servlet-name>
<url-pattern>/servlet/com.sas.servlet.util.ContentServlet</url-pattern>
</servlet-mapping>
Third, because the tag library will not be honored unless it is located in WEB-INF, change the sasads.tld location from
/META-INF/sasads.tld
to
/WEB-INF/sasads.tld
Once all the changes have been made, save and close the file. Next, move sasads.tld from
...\Portal1.1\Portal\META-INF
to
...\Portal1.1\Portal\WEB-INF\
Upgrade Note: This step is only required if you have release 1.1 installed and you have not applied either the 1.1.1 or 1.1.2 hot fixes. If this is a new installation, skip to step 5.
In the hot fix the RDNs for the portal person entries changed from cn=Portal User,... to uid=portaluser,... This change results in consistent usage of the RDNs for all person entries. The recommended upgrade process does not require any changes to entries in the LDAP directory server. However, the Portal1.1/Portal/WEB-INF/Portal.properties.orig file, which is upgraded as part of the hot fix, must be changed to be compatible with the existing release 1.1 LDAP entries. To do this, change the following line from:
Servlet.Principal=uid=portaluser,$PERSON_CONTEXT$to:
Servlet.Principal=cn=Portal User,$PERSON_CONTEXT$
Make sure you change both uid to cn and portaluser to Portal User. When you are finished editing the file, save it.
This step is only required if you are running the IBM SecureWay Directory Server. If you are running the Netscape Directory Server, skip to step 6.
The security implementation varies from directory server to directory server. To allow the Portal to modify ACI entries when running in the IBM SecureWay Directory Server, change the following line from:
Servlet.SecurityClass=com.sas.edir.ldap.NetscapeEnterpriseDirectorySecurityto:
Servlet.SecurityClass=com.sas.edir.ldap.IbmEnterpriseDirectorySecurity
When you are finished editing the file, save it.
The configuration tool will apply the properties in install.properties to the .orig templates shipped with the Portal and generate properly configured properties, xml, schema and LDIF files. It will also generate a Portal.war file used to deploy the Portal Web application in a 2.2 compliant servlet container.
The configuration tool uses the jar executable that is found in the JDK, but not in the JRE. If you have not installed the Java 2 JDK, version 1.3.0_01, do so at this time. See Installing the Java 2 SDK, Standard Edition, version 1.3.0_01 for details.
java and jar executables, in your path.
java PortalConfigure
Upgrade Note: If you are upgrading from the SAS Information Delivery Portal, release 1.1 (or a subsequent hot fix release), you have already installed and configured your LDAP server. Unless you remove all existing Portal users, groups, and SAS entries, which will result in the loss of all existing data stored in the directory, you should not reinstall containers.ldif, portal.ldif, and portal_*_aci.ldif. However, changes introduced in the 1.1.2 hot fix require the addition of one new entry in the directory and, for SecureWay servers, the addition of three new acls. If you have not installed this update as part of a 1.1.2 hot fix installation, skip to step 6 to make these changes.
Before you configure your LDAP server for use with the Portal, be sure that you have installed and configured your server using the instructions from the Setting up an LDAP Directory Server section of the SAS Integration Technologies Web site. If you are setting up the LDAP directory server to support Integration Technologies for the first time, you should use the containers.ldif and schema files generated by the PortalConfigure tool instead of those recommended by the "Setting up an LDAP Directory Server" instructions. When you complete these instructions, you will have a working LDAP directory server that is configured with the SAS schema and you will have loaded the SAS Portal structure.
To set up your LDAP server for use with the Portal:
If you installed the LDAP directory server with the containers.ldif and schema files generated by the PortalConfigure tool, you may continue with step 4. Otherwise, continue with step 1.
| Netscape Directory Server, version 4 | nsslapd.sas_at.conf nsslapd.sas_oc.conf |
| Sun ONE Directory Server, version 5.1 | 75sas.ldif |
| IBM SecureWay, version 3 | V3.sas.oc |
| OpenLDAP, version 1.2 | slapd.sas_at.conf slapd.sas_oc.conf |
| OpenLDAP, version 2.0 | slapv2.sas.schema |
These files update the configuration files that you copied from the Integration Technologies Administrator package when you configured your LDAP server.
Note: Before the containers.ldif file can be loaded into your LDAP server, you need to make sure the $SAS_CONTEXT$ entry defined during the configuration process has been created. The creation of this entry is covered in the
Setting up an LDAP Directory Server section of the SAS Integration Technologies Web site.
If you create a new root node, you will need to set the appropriate administrative ACIs on this node so that you can use the LDAP directory console to edit the tree. These ACIs are server and site specific and should be added by your LDAP administrator.
Import the LDIF entries into your LDAP directory server using the LDAP directory console or tools provided by your server vendor. If you are using ldapmodify, which is the standard command line tool used to import LDIF data into a server, run the following command to import the entries:
ldapmodify -h host -a -c -D privilegedDN -w password < containers.ldif
If you have already install the entries in containers.ldif into your LDAP directory server, a large number of entries may fail to load.
Import the LDIF entries into your LDAP directory server using the LDAP directory console or tools provided by your server vendor. If you are using ldapmodify, which is the standard command line tool used to import LDIF data into a server, run the following command to import the entries:
ldapmodify -h host -a -c -D privilegedDN -w password < portal.ldif
Consult your server's administration guide for instructions on setting access control, then set controls as necessary. Proper access controls are essential to the operation of the Portal. Be sure to read Setting Proper Access Controls for User Identities for detailed information about the access permissions that are required for the Portal User, Portal Guest User, and Portal Demo User identities.
Installation Tip for Netscape Directory Server
If you are running the Netscape Directory Server and you are not familiar with setting access control, the Portal ships with an LDIF file that can be used to set default values. Load the portal_nsslapd_aci.ldif file from the LDAP subdirectory of the Portal setup directory into your LDAP server.
Import the LDIF entries into your LDAP directory server using the LDAP directory console or tools provided by your server vendor. If you are using ldapmodify, which is the standard command line tool used to import LDIF data into a server, run the following command to import the entries:
ldapmodify -h host -c -D privilegedDN -w password < portal_nsslapd_aci.ldif
Installation Tip for IBM Secureway
If you are running the IBM Secureway server and you are not familiar with setting access control, the Portal ships with an LDIF file that can be used to set default values. Load the portal_V3_aci.ldif file from the LDAP subdirectory of the Portal setup directory into your LDAP server. You must use the directory manager ID and password since the directory manager and the entry owner are the only two users that can modify the owner property or the access control attributes of an entry.
Import the LDIF entries into your LDAP directory server using the LDAP directory console or tools provided by your server vendor. If you are using ldapmodify, which is the standard command line tool used to import LDIF data into a server, run the following command to import the entries:
ldapmodify -h host -c -D privilegedDN -w password < portal_V3_aci.ldif
After the installation, the root user will be the owner of everything in the LDAP directory server. In most cases, access control is set on specific entries rather than containers. As a directory manager you will need to decide it you want to set access control on new entities or put access control on the containers.
This step is only required if you are upgrading from the SAS Information Delivery Portal, release 1.1 (or 1.1.1). If you installed portal.ldif from the 1.1.2 hot fix (or a subsequent hot fix release), then you do not need to install portal_updates.ldif.
Upgrade Note: If you are upgrading from the SAS Information Delivery Portal, release 1.1 (or 1.1.1), then your LDAP server should already be populated with data from the previous install. However, a change in the 1.1.2 hot fix requires the addition of one new entry in the directory.
Import this LDIF entry into your LDAP directory server using the LDAP directory console or tools provided by your server vendor. If you are using ldapmodify, which is the standard command line tool used to import LDIF data into a server, run the following command to import the entry:
ldapmodify -h host -a -c -D privilegedDN -w password < portal_updates.ldif
This step is only required if you meet all three of the following criterion: (1) you are running an IBM SecureWay directory server, (2) you are upgrading from the SAS Information Delivery Portal, release 1.1 (or 1.1.1), and (3) the RDNs for the portal person entries are still in the form cn=Portal User,... . If you installed portal_V3_aci.ldif from the 1.1.2 hot fix (or a subsequent hot fix release), then you do not need to install portal_V3_aci_updates.ldif.
Upgrade Note: If you are upgrading from the SAS Information Delivery Portal, release 1.1 (or 1.1.1), then your LDAP server should already be populated with data from the previous install. However, a change in the 1.1.2 hot fix requires the addition of three new acls in the directory.
Import this LDIF entry into your LDAP directory server using the LDAP directory console or tools provided by your server vendor. If you are using ldapmodify, which is the standard command line tool used to import LDIF data into a server, run the following command to import the entry:
ldapmodify -h host -c -D privilegedDN -w password < portal_V3_aci_updates.ldif
Use the instructions that are available from Installing Portal Files in the Servlet Container to install the Portal in your servlet container.
Upgrade Note: If you are upgrading from the SAS Information Delivery Portal, release 1.1 (or a subsequent hot fix release), you have already installed demo files on the SAS Server. You may skip this section and continue with Start the SAS Object Spawner.
Note: This step is recommended, but is required only if you want to use the archive and report examples that are provided as part of the demo Portal.
If the SAS server does not have access to the Portal setup directory, you must install the demo files on your SAS server. To do this, locate the Portal setup directory and copy the SASDemos subdirectory and it's contents to a location that is accessible to your SAS server. You specified this location when defining the $SAS_DEMO_DIR$ property during the configuration process.
For the data source viewer to communicate with the SAS server, it is necessary to update SAS. This update is required for the SAS System, Release 8.2 or greater. To install the update on your SAS server:
Upgrade Note: If you are upgrading from the SAS Information Delivery Portal, release 1.1 (or a subsequent hot fix release), you have already upgraded the SAS Server. You may skip this section and continue with Start the SAS Object Spawner.
filename updates 'path-to-transport-file';
proc cimport library=sashelp infile=updates force; run;
To use all of the features in the Portal, you must start the SAS object spawner. Instructions on administering and starting an object spawner are available from the Starting and Administering an Object Spawner section of the SAS Integration Technologies Web site.
Upgrade Note: If you are upgrading from the SAS Information Delivery Portal, release 1.1 (or 1.1.1) and your portal person entry RDNs changed from "cn=Portal User,.." to "uid=portaluser,...", then you will also need to update the value of your ldap_binddn option in your spawner invocation command as seen below.
An example of a spawner command that works with the SAS System, Release 8.2 running the Portal Demo on the Windows platform is
del /q c:\temp\obj.log
"c:\program files\sas institute\sas\v8\inttech\sasexe\objspawn"
-sasverbose -saslogfile c:\temp\obj.log
-ldaphost ldapserver.ace.com -ldapport 389
-ldapbase "sascomponent=sasServer,cn=SAS,o=ACE Industries,c=US"
-ldap_binddn "uid=portaluser,ou=People,o=ACE Industries,c=US"
-ldap_bindpw portal1 -sasspawnercn "Portal Demo Spawner"
An example of a spawner command that works with the SAS System, Release 8.2 running the Portal Demo on the UNIX platform is
rm /tmp/obj.log
/usr/local/sas8/utilities/bin/objspawn
-sasverbose -saslogfile /tmp/obj.log
-ldaphost ldapserver.ace.com -ldapport 389
-ldapbase "sascomponent=sasServer,cn=SAS,o=ACE Industries,c=US"
-ldap_binddn "uid=portaluser,ou=People,o=ACE Industries,c=US"
-ldap_bindpw portal1 -sasspawnercn "Portal Demo Spawner"
Note: If you change sasLogin, sasServer, or sasSpawner definitions in the LDAP directory server, you must shut down the servlet container, shut down the object spawner, restart the object spawner, and restart the servlet container for the changes to take effect.
Start the demo Portal to test your installation.
To start the Portal:
The Portal should display in the browser window. If it does not display, see the troubleshooting guide on the Portal Web site for information about possible problems. For information about running the demo Portal, see Stepping Through the Demo Portal on the Portal Web site.
|
|