Controlled activation includes additional options:

The Deliver screen also provides the opportunity for independent activation of sections on subscribers.

The Publishing Progress Display screen provides the Continue button so you can by-pass a publishing initiation or activation delay.

Comparing controlled and independent activation

In order to understand the independent activation features, it is important to understand the controlled activation process.

• In controlled activation, the publishing process moves the entire publication together through the process strictly one phase at a time. The controller does not start a new phase until it completes the previous phase. Therefore, the controller does not activate a section's content on a subscriber until all the content of all the other sections has first been copied to the subscriber.
• Independent activation allows each section to independently move into the activation phase as soon as the controller completes that section's copy phase.

Both controlled and independent modes of activation are available for either manual or scheduled publications.

Options for controlled activation

With the GLOBAL-SITE Controller, you decide how the controller activates subscribers. These control options are on the New Publication and Publication Options screens under Activating New Content. (For details on how to use these options, see the online help on either screen.) By default, the GLOBAL-SITE Controller tries to activate all subscribers simultaneously.

You can change the default behavior and specify that only some of the subscribers should be activated together. In addition to all subscribers, you can choose one half or one quarter of the subscribers. This option is most useful in conjunction with control of the BIG-IP.

When you are accessing some of the subscribers with a distributor, you can use the Activate through one distributor at a time check box to specify that the GLOBAL-SITE Controller should activate subscribers through one distributor at a time. If you use this option, the subscriber activation percentage specifies what fraction per distributor to activate together.

Working with the BIG-IP and virtual servers

A powerful feature of the GLOBAL-SITE Controller is the integration of publishing with the BIG-IP. (The GLOBAL-SITE Controller can communicate with the BIG-IP, version 3.1 and above.) Typically, the BIG-IP is used to load balance an array of servers. You can increase your publishing scope and control over your publications if you set up a virtual server subscriber on the BIG-IP, and use the GLOBAL-SITE Controller to control it and the nodes behind it as a single entity.

When the GLOBAL-SITE Controller accesses a virtual server subscriber on a BIG-IP, you have the option to maintain the subscriber site performance by removing the virtual server nodes from user access while updating the contents of the site. The restriction of web access to subscribers in conjunction with a BIG-IP reduces the risk of exposing a possibly inconsistent mix of old and new content to web users during the activation process.

The GLOBAL-SITE Controller Administrator Guide does not provide details on the BIG-IP platform functionality. You may want to refer to your BIG-IP user guides for details of setting up the BIG-IP and virtual server nodes.

Use the GLOBAL-SITE Controller browser interface to:

• Set up a BIG-IP as a virtual server
• Remove the unused BIG-IP units
• Change settings for the current BIG-IP units
• Mark the BIG-IP nodes as down during publishing

Guidelines for BIG-IP and GLOBAL-SITE Controller cooperation

Before you create a virtual server subscriber on the GLOBAL-SITE Controller, be sure to follow these guidelines:

• The GLOBAL-SITE Controller must be configured on the same BIG-IP interface as the virtual server nodes. This is typically the internal interface (the network interface through which a BIG-IP distributes connections). In newer releases of the BIG-IP, that interface must have admin access.
• The GLOBAL-SITE Controller must have FTP or WebDAV access to the virtual server nodes using the same node IP address that the BIG-IP has configured for the virtual server. The GLOBAL-SITE Controller in turn uses that IP address to create a virtual server subscriber.
• If you are using this controller as a distributor for another GLOBAL-SITE Controller, you need to define a virtual server on the BIG-IP for port 2792 (for GLOBAL-SITE Controller to GLOBAL-SITE Controller communication, using the F5-GLOBAL-SITE protocol).
• If the GLOBAL-SITE Controller (that you are using with the BIG-IP) is to be used as a publisher, you must configure on the BIG-IP a virtual server to the controller for port 443 (HTTPS) for access to the web browser. You probably also need a secure NAT (SNAT) so that the GLOBAL-SITE Controller can get FTP access to systems, such as section sources, through the BIG-IP.
• Once you have completed the preceding tasks, you need to inform the GLOBAL-SITE Controller about the BIG-IP by using the Add a BIG-IP screen, which also indicates whether communication works or not.

Creating a BIG-IP on the GLOBAL-SITE Controller

To add a new BIG-IP to the GLOBAL-SITE system, use the Add a BIG-IP screen (from the navigation pane, click Add a BIG-IP). You can add a BIG-IP only if the BIG-IP is up and available locally or through a distributor.

To add a BIG-IP

1. Type the name of the BIG-IP that you want to add. This is the internal IP address, or alias of the BIG-IP.
2. Type a description for the BIG-IP. This identifier may make it easier for you to recognize each BIG-IP unit. (This step is optional.)
3. Select a BIG-IP distributor from the list of available BIG-IP units.
4. Click the Add button to add this BIG-IP distributor.
   The BIG-IP List screen displays.
   
   

   Once you have added the BIG-IP, you can see it listed on the BIG-IP List screen, where you can delete any BIG-IP that has no references. You can also review or change the BIG-IP settings on the BIG-IP Detail screen. If the BIG-IP Detail screen does not show any virtual servers, then the BIG-IP is set up incorrectly.

Setting up a virtual server subscriber

If you have one or more BIG-IP units set up on the GLOBAL-SITE Controller, you have the option of setting up a virtual server subscriber. If the GLOBAL-SITE Controller is not aware of any BIG-IP units, your option is to set up a normal server subscriber. To set up any subscriber, start with the Publication Subscriber screen, see Figure 4.2 .

Figure 4.2 Selecting a virtual server subscriber on the Publication Subscriber screen

To add a new subscriber

1. From the Add subscriber type box, select Virtual Server.
2. Click the Add a Subscriber button.
   The Add Virtual Server Subscriber screen displays.
3. Fill in the form with subscriber access details, sections to include, and section paths.
4. Click Add.

Marking BIG-IP nodes down while updating content

The GLOBAL-SITE Controller can have the BIG-IP disable web access to the individual nodes of the virtual server while it activates the content. This prevents web clients from seeing a mix of old and new content. Once the content has been successfully activated, the controller instructs the BIG-IP to re-enable web access. Use the BIG-IP Virtual Server Control options on the Publication Options screen for these settings.

Figure 4.3 BIG-IP Virtual Server Controls on the Publication Options screen

If you set up a virtual server subscriber, you can specify that 50% of the subscribers are to be activated together and that access to them be disabled during the activation phase. Using this method, no single virtual server node is enabled with a mix of old and new content at the same time. Because they are accessed by a virtual IP server address, any single subscriber may show old pages while the first files are being updated, but then has a new page once the new content is available.

A final option, under BIG-IP Virtual Server Control, reduces the likelihood of mismatched content. The Time out persistent connections check box under BIG-IP Virtual Server Control can temporarily enable simple persistence before disabling any of the nodes. This helps to lock each web user into a single node and reduce the chances that a BIG-IP load balances the user from a system with old content to one with new content.

If you choose the Independent Activation mode, the BIG-IP is instructed to disable and re-enable web access for each subscriber section independently. We do not recommend that you use the persistence option in conjunction with independent activation mode.

Working with the EDGE-FX Cache and cache subscribers

As an administrator performing routine publication management, you can populate or expire cached content on the EDGE-FX Cache from the GLOBAL-SITE Controller. When the GLOBAL-SITE Controller completes publishing content to its subscribers (which the EDGE-FX Cache calls origin servers), it can immediately notify cache subscribers to update stored content from those servers. Integration between these products:

• Improves content delivery
  Newly-published content can be automatically cached before it is requested so content gets to the end-user faster.
• Consumes less bandwidth
  The cache is told when content has expired, eliminating the need for constant freshness checks.

  You can also create cache subscribers from the GLOBAL-SITE Controller. Cache subscribers receive information on the status of new content from the controller. This eliminates the cache's need to poll the origin servers to check for new content, and consumes less bandwidth. The caches can then get new content prior to any request for that content, or can remove outdated content as soon as it expires.

  In order for the GLOBAL-SITE Controller to manage your cache, you must make sure that you have configured the EDGE-FX Cache to external validation mode. Please refer to the EDGE-FX Cache documentation for this information.

Supported URL schemes

The GLOBAL-SITE Controller, and the EDGE-FX Cache manage three different URL schemes: http://, mms://, and ftp://. The exact behavior of the Expire and Populate modes is slightly different for each one.

• http://
  The Expire mode purges any new, changed, or removed file from the EDGE-FX Cache. A failure of the purge command to the EDGE-FX Cache is considered a delivery failure by the GLOBAL-SITE Controller. The reason is that until the purge command is known to succeed, an EDGE-FX Cache could be retaining stale data. The GLOBAL-SITE Controller reissues the same purge command until it succeeds, depending on how its normal error handling options have been configured for the publication.
  
  The Populate mode causes an immediate get for the specified URL. A failure to actually retrieve the URL (a 404 error) is not considered a publication failure, because in that event, the EDGE-FX Cache does not serve up stale content either. Such an error probably represents an overall configuration failure, because it means that the EDGE-FX Cache was instructed to get data not available from the origin servers. Such a scenario is very unlikely if the GLOBAL-SITE Controller is managing the content on multiple origin servers behind a BIG-IP and a 3-DNS Controller, but not all sites are so well architected.
• mms://
  This is the scheme used for Windows media files. The Expire mode simply purges data from the media cache, without prepopulating.
  
  The Populate mode actually pre-positions the data to the EDGE-FX Cache. The data is delivered directly by way of iControl without getting it from the origin server. This avoids the need for the EDGE-FX Cache to ever get (potentially) large media files from the origin server at all. The GLOBAL-SITE Controller retrieves the data once from the origin server, and then directly delivers it to the specified set of caches. You can configure multiple GLOBAL-SITE Controllers, as you would with any subscriber, in a primary-distributor relationship to scale up delivery capability to large numbers of subscribers.
• ftp://
  The Expire mode behaves the same as the others, simply purging any cached data when new, changed, or removed files are delivered.
  
  The Populate mode gets the file from the specified (ftp://server.com/directory) using anonymous access only. If anonymous access is not configured for the FTP server, this process fails. The GLOBAL-SITE Controller treats such failures as a delivery failure, and retries delivery in subsequent delivery attempts.

Warning: Only EDGE-FX Caches that are configured in forward mode have the ability to either expire or populate ftp:// requests. If you attempt to use this scheme for caches in reverse mode, the process results in delivery failures.

Guidelines for EDGE-FX Cache and GLOBAL-SITE Controller cooperation

In order for you to effectively use the GLOBAL-SITE Controller and EDGE-FX Cache arrangement, you must be aware of certain details:

• The EDGE-FX Cache can run in external validation mode. This means that regardless of what is in the headers, only the GLOBAL-SITE Controller can expire content on the cache. There are pros and cons to setting up the cache this way. You do not have to have the cache in external validation mode to be able to prepopulate the cache with content. See the EDGE-FX Cache Administrator Guide, chapter 12, Plug-ins for more information on External Validation Mode.
• All content on the cache for a domain that is in external validation mode, must be managed (expired/populated) by an external agent (the GLOBAL-SITE Controller). If non-managed content for that domain gets into the cache, it never expires.
• You must have permission for each cache operation. Permissions are set on the EDGE-FX Cache machine. See the EDGE-FX Cache documentation for information on how to do this.
• Cacheable dynamic content cannot be expired, however most dynamic content is not cacheable.

Managing a cache subscriber

The GLOBAL-SITE Controller supports the EDGE-FX Cache subscribers using the iControl system. A cache subscriber is generally different from other subscribers in the following ways:

• A cache subscriber exclusively uses the iControl system for data management, unlike other subscribers which may use either FTP or WebDAV for data management. The username and password specified for the cache subscriber must be a valid iControl account on the EDGE-FX Cache system. See the EDGE-FX Cache documentation for details on configuring such accounts.
• Cache subscribers are handled only after all other subscribers have had their content delivered and activated. This is because the EDGE-FX Cache is presumed to be configured to get needed data from an origin server that is represented by one or more of the non-cache subscribers to a publication. This allows a single publication to deliver updates to origin servers, and update caches with fresh content, in a single delivery cycle.
• A cache subscriber does not specify a file system directory as a destination for file delivery. Instead, a URL base is specified for each section. This URL base specifies the scheme, domain, and a directory path. Each file being updated in the section is appended to this root to form a complete URL for presentation to the cache. This, in turn, presumes a one-to-one mapping between files in the section and the URL to which the origin server responds for that data.
• A cache subscriber supports two mutually exclusive modes, Expire and Populate, for managing cached content.
  
  
  • The Expire mode is the closest approximation to typical cache behavior. In the Expire mode, a new or changed file causes the GLOBAL-SITE Controller to send an iControl command to purge the synthesized URL (as explained previously) from the EDGE-FX Cache. This, in turn, forces the next access attempt by a cache client to get the URL from the origin server, even though freshness heuristics may have otherwise determined that previously-cached content could be served. This ensures that the cache never serves stale content.
  • The Populate mode takes the idea further by instructing the EDGE-FX Cache not only to expire any cached copy immediately, but also to immediately get a new copy. This allows the GLOBAL-SITE Controller to effectively prepopulate new content into an EDGE-FX Cache so that fresh, cached, content is served from the EDGE-FX Cache on the very next client request, without the need to proxy that initial request back to the origin server. Combine this with the GLOBAL-SITE Controller's scheduled content delivery capabilities, and you can update a large set of EDGE-FX Caches with new content overnight, or whenever network load is light, to minimize surges in demand on origin servers when newly updated content is accessed on a daily cycle.

    When setting up a cache subscriber, you have the option of setting it to expire content or populate content. Once you have entered the URL root and the section path, you need to choose between expire and populate:

• Choose Expire if you want the cache to delete the content.
• Choose Populate if you want the cache to immediately get new content (before a request is made for it).

In order for the GLOBAL-SITE Controller to manage the cache, you must have the correct permissions set on the cache, and you must have correctly configured the EDGE-FX Cache. For details, please see the EDGE-FX Cache documentation and Guidelines for EDGE-FX Cache and GLOBAL-SITE Controller cooperation, on page 4-12 of this chapter.

Creating a cache subscriber

There are three ways to create a cache subscriber in the GLOBAL-SITE Controller. All are effective, however some are easier to do. Depending on the situation, you can:

• Create a cache subscriber from a server subscriber
• Create a brand new cache subscriber
• Clone an existing cache subscriber

Creating a new cache subscriber

Use this procedure if you are creating a cache subscriber that is not based on a server or virtual subscriber. When you create a new cache subscriber, you have to fill in all the fields and paths manually. You must make sure you enter paths and directories exactly, or the GLOBAL-SITE Controller cannot contact the cache.

To create a new cache subscriber

1. From any of the Publication detail screens, click the Subscribers tab.
   The Publication Subscribers screen opens.
2. In the Add subscriber type box, select Cache.
3. Click the Add a Subscriber button.
   The Add a Cache Subscriber screen opens.
4. Fill in the information as required. Paths must be URLs.
5. Once the subscriber is created, you can click the Test Connection button to verify that the GLOBAL-SITE Controller can successfully log into the specified server using the user account and manage the specified domain. This is a good thing to do at this point and any time you make changes to the subscriber definition.

Cloning a cache subscriber

Before you can clone a cache subscriber, you must already have a cache subscriber created. The list of subscribers is found on the Subscribers tab. You cannot have an exact duplicate of any subscriber, therefore when you clone a cache subscriber, the controller clears the Subscriber box and the Cache box, and you need to provide new information for these boxes. Change any other boxes on the screen as necessary.

To clone a cache subscriber

1. From the Cache Subscriber Detail screen, click the Clone button at the bottom of the screen.
   A new Cache Subscriber Detail screen opens. All the boxes have data except for Subscriber and Cache.
2. Enter a new name in the Subscriber box for this cache subscriber. You can use only alphanumeric characters, spaces, dashes (-), and underscores (_).
3. Enter a new host name in the Cache box.
4. Change the data in the other boxes as necessary.
5. Click Update to save your new subscriber.

Creating non-archived publications

Non-archived publication is basic, fundamental content replication. It takes content directly from the user's source and moves it directly to the location where it can be accessed by the customer-viewers. It does not keep copies of the content on the GLOBAL-SITE Controller.

Non-archived publication uses the same process as archived publications to determine which files have changed since the last publication. Once it determines which files have changed, it copies the new files to the subscribers and activates them. Activating files is the process of changing them from temporary status, not viewable by users, to permanent and available to the viewer on the subscriber.

Non-archived publication is the right choice when you are looking for speed of publishing over guaranteed backup and the ability to revert to a previous version of a publication. Because the GLOBAL-SITE Controller does not keep copies of the files, the publishing process is not constrained by the size of the GLOBAL-SITE Controller disk, but only by the subscriber capacity.

Note: If you are running the GLOBAL-SITE option on an EDGE-FX Cache, you can create only non-archived publications.

Looking at benefits of non-archived publications

Non-archived publishing retains many of the benefits of archived publishing:

• The GLOBAL-SITE Controller replicates only content that has changed since the last publishing cycle.
• You can cancel the process at any time.
• Files are moved through a secure channel to all distributors.
• You can schedule publishing.
• You can configure the publishing process to pause or continue when encountering errors.

Planning for non-archived publications

For your planning purposes, remember that archived publications and non-archived publications are mutually exclusive. Archived publications have only archived sections. You can create non-archived sections only within a non-archived publication.

To change an archived publication to a non-archived publication, you need to recreate the publication with a new name, and then delete the old one.

Considering the details of non-archived publishing

Before creating non-archived publications, there are a few things you might want to think about. These details can affect the efficiency and performance of your non-archived publications.

• How do you organize your files and directories?
• What is the usual size of your sections?
• What is the typical amount of activity in your files?
• What is the capacity of your subscriber server?

Organizing files and directories

Before copying content to the subscriber, the GLOBAL-SITE Controller reviews all content at the source, looking for things that have changed between the new content and the content the subscriber has. It does this by comparing a list of files, sizes, and dates (that are tracked by the GLOBAL-SITE Controller) to the list of files, sizes, and dates on the source. The time it takes for this comparison depends on how the content is organized. The fewer directories you have in the section, the less time it takes to complete the comparison. For instance, publishing fewer than 100 directories seems rapid, and publishing more than100 directories takes noticeably longer. Because the important element here is not the number of files but the number of directories, you may want to structure your publications with this in mind.

Reviewing section size

During the content copy, for each file that has changed, the entire file is copied to any distributors, and then to any subscribers. (Compare this to the archived publishing process, where only the changes are sent to the distributor, and the entire file is sent to subscribers.) Each file within a section is copied sequentially from the source to the subscriber. During this process, it is the larger sections that determine how fast the copy phase can go. Therefore, it is more efficient to have roughly equal section sizes. This improves the performance of the copy process over having several small and one really large section.

This information is provided to help you set expectations based on your own file structure and organization, and not as a suggestion that you change your publication structure.

Checking file activity

During the update process, the directory list is created and then the files are retrieved. During the time that files are being copied to the subscriber, each file is compared to how it was at the initial comparison. If the file has been removed or becomes empty, the GLOBAL-SITE Controller ignores it, and does not copy it to the subscriber during the current publishing cycle. The subscriber keeps the old file, which the controller updates on the next publishing cycle. The reason the GLOBAL-SITE Controller ignores it at this point, is that the GLOBAL-SITE Controller assumes the file may be in flux and possibly incomplete.

When you set up your publication, you need to watch for very active files, and be careful to schedule publishing for times when they are most likely to be static. If you publish when these files are changing, you may find that the subscribers do not get an updated version of that file. For additional details, refer to Scheduling the publishing process, on page 4-2 of this guide.

Assessing subscriber capacity

During the copy phase, the changed files are copied into a temporary directory of the subscriber. These files are not available to the viewers until they are activated. During this time, the subscriber server contains all the old content and all the changed content. Therefore, the subscriber server capacity must be large enough for the old content and the changes to co-exist temporarily.

Using procedures for non-archived publications

Creating, managing, and publishing non-archived publications is very much like dealing with archived publications. The New Publication screen is the same for archived and non-archived publications. To make a publication non-archived you must clear the Archive publication editions and section versions check box at the top of the New Publications screen.

There are a few differences on various application screens. Most noticeable is the fact that when you are dealing with non-archived publications, you do not see the Editions tab as you do when working with archived publications. And, because non-archived publications have no editions and no versions, there are other small differences on some screens. These differences are noted in the online help pages for each screen.

One important difference is the delivery screen. Non-archived publications allow the following actions: Deliver, Ignore, or Remove for each section on a subscriber. You must choose the same action for all sections that share the same subscriber's path.

Note: Once you have created a publication, you cannot change its archived or non-archived state.

To create a non-archived publication

1. Start at the New Publication screen. (From the navigation pane, click Add a Publication, or from the Publication List screen, click the Add a Publication button.)
2. At the top of the screen, clear the Archive publication editions and section versions check box.
3. Complete the settings as required and click the Add button.
   The Publication Sections screen opens.

Refer to the online help for this screen if you need additional details. Remember that you do not have to specify all options when you create the publication; you can return later and set scheduling and error-handling options.

Note: The Editions tab does not display, as there are no editions of a non-archived publication.

To create a non-archived section

1. On the Publication Sections screen for your non-archived publication, click the Create New Section button.
   The Create a New Section screen displays.
2. Create a section as you would normally.
   Any section you create here is automatically non-archived.

Procedures for dealing with non-archived sections are detailed in the online help for the specific screens. Most procedures are the same for archived and non-archived sections and the online help pages point out any differences.

Understanding file transfer methods

The GLOBAL-SITE Controller offers five transfer methods: FTP, FTP-Push, WebDAV, WebDAV-SSL and HTTP. Each method has its advantages and disadvantages. This section of the guide helps you choose the right transfer method for your needs. Following the transfer method sections is a section detailing how to choose a port based on the transfer method you chose.

Warning: Changing the transfer method of an existing section can have serious consequences if the services the controller is communicating with has different root directories.
For example, a problem occurs if you changed transfer methods from FTP to WebDAV and your FTP server had a different root directory than your HTTP server.
In particular, changing an existing section to FTP-Push requires copying the section's files to the GLOBAL-SITE Controller. See Switching sections in an existing publication to use FTP-Push transfer method, on page 5-8 of this guide.

FTP

The GLOBAL-SITE Controller functions as an FTP client and initiates contact with FTP servers where content is picked up. FTP is familiar to most users, is readily accessible, and available on all platforms. However, FTP does have its limitations, which include:

• Opening a new connection for most commands, which increases overhead, and slows the operating system
• Transferring passwords and files with no encryption or error checking
• Requiring manual intervention on each subscriber to run CGI, and other normally executable files, because many FTP servers cannot set the execute permission on transferred files

FTP-Push

There are two main differences between FTP and FTP-Push:

• With FTP-Push, the machine associated with a section contacts the GLOBAL-SITE Controller when content has changed and pushes content to the GLOBAL-SITE Controller (the controller is the FTP server in this case). The content is stored on the GLOBAL-SITE Controller. (For more information, see To add content to an FTP-Push section, on page 4-35 of this chapter.)
• Once content is updated on the GLOBAL-SITE Controller, an FTP-Push section can be set to trigger the GLOBAL-SITE Controller to push the new content out to the subscribers. If you set up your FTP-Push this way, you do not need any manual intervention to deliver the publication. FTP-Push has the same inherent disadvantages as standard FTP. (For more information, see Section updates using FTP-Push, on page 4-34 of this chapter.)

WebDAV

To use WebDAV (World Wide Web Distributed Authoring and Versioning) to transfer files, you must either have a web server that supports it (IIS5.x or Apache HTTP Server with mod_dav), or use the GLOBAL-SITE agent. If you install the GLOBAL-SITE agent, you can use WebDAV to transfer files even if your web server does not support it. (For more information please see RFC 2518.)

Note: When you use WebDAV to transfer files to an IIS server, some file extensions cannot be transferred. This may have to do with the IIS server settings. Please see that product's documentation for more information.

WebDAV reuses connections, resulting in efficient use of the operating system and firewalls. WebDAV with digest authentication encrypts passwords and performs file checking, making it easier to discover files that have changed in transit. (For more information on digest authentication, please see RFC 2617.) WebDAV can maintain the execute permission on files.

To use digest authentication with a Windows 2000 server, the server must be configured as a domain controller. For more information, see Transferring files using WebDAV and WebDAV-SSL, on page 4-30 of this chapter.

For file transfers for either sections or subscribers, on Windows NT/2000 machines, you can use WebDAV if you install the GLOBAL-SITE agent. For more information, see Controlling servers with the GLOBAL-SITE agent, on page 4-21 of this chapter. For subscribers, if you are going to use any agent actions, you must install the GLOBAL-SITE agent, and you must choose WebDAV for your file transfer method.

WebDAV-SSL

WebDAV-SSL adds security to WebDAV file transfers by encrypting both passwords and files using secure socket layer (SSL) features. However, you trade increased security for file transfer performance. For more information, see Transferring files using WebDAV and WebDAV-SSL, on page 4-30 of this chapter.

HTTP

If you want to prepopulate a cache using the content from an existing web server, choose the HTTP transfer method to set up section content. When you use the HTTP method, the controller goes through the web server directories and files, and downloads the files as section content. The controller then uses this information to push content to its cache subscribers.

You can use the HTTP transfer method only to send content from a web server to the GLOBAL-SITE Controller. It is not an option for sending content from the controller to subscribers. For more information, see Understanding the HTTP transfer method, on page 4-31 .

Warning: You should use the HTTP transfer method to gather content for publication to caches only.

Choosing a port for the file transfer method

You must use the correct port number for successful file transfer. Each transfer method has a default port as follows:

• FTP = Port 21
• FTP-Push = Port 21
• WebDAV = Port 80
• WebDAV-SSL = Port 443
• HTTP = Port 80

In general you should use the default ports. However, if you are using the GLOBAL-SITE agent, use the port number that you entered when you installed the agent (the default is 50,000).

Controlling servers with the GLOBAL-SITE agent

When you install the GLOBAL-SITE agent on a server, it gives you the ability perform certain necessary tasks remotely from the GLOBAL-SITE Controller. The following are tasks you can perform remotely when you install the GLOBAL-SITE agent:

• Stop HTTP Server before activating content
  Allows you to stop the web server on the subscriber when you deliver new content or components. Stopping and restarting the server allows the server to recognize new files. The ability to stop the server also allows you to get around locked files, as stopping the server unlocks the files.
• Initiate scripts
  Allows you to run a user-defined script, at a specified time during the publishing process. Scripts reside in a particular directory. When it is time to run the scripts, the agent runs all executables that it finds in the specified directory. Please see Installing and configuring the GLOBAL-SITE agent and scripts, on page 4-27 for more information about user-defined scripts.
• Reboot machine after activating content
  Allows you to reboot the subscriber (server) so it recognizes newly registered components.
• Register components
  Allows you to register components of your web site that need to register with the operating system or the web server.

The GLOBAL-SITE agent also allows you to use WebDAV as your transport mechanism even if your web server does not support WebDAV. WebDAV provides safer communication of passwords and content than standard FTP.

You must install the GLOBAL-SITE agent on each machine that you want to use it on.

Once you install the agent on a section or subscriber machine, you need to modify the settings for the section or the subscriber to enable its use. The Connection Test results have also been expanded to include information on the agent, where appropriate (see To test an agent for a subscriber or section, on page 4-27 ).

Installing the GLOBAL-SITE agent on the subscriber

The Windows agent installer is an InstallShield® application. See To install an agent on a Windows server , following. On Solaris and Linux you get the GLOBAL-SITE agent in a tar file that has the image and the installation program with which to install and configure the agent. You run the installation program, gsAgentInstall from the command line as the root user. The installation program also looks for the installation image, GlobalSite.tar, in its current directory. See To install an agent on a Solaris or Linux server following.

The Solaris and Win32 installation prompts are almost identical. The Solaris installation prompts you for the command to stop the web server and the command to start the web server.

If you enable scripting support, the installation creates a virtual directory, UserScripts, under the document root directory. The virtual directory points to the UserScripts directory under the agent installation root directory. See Installing the scripts on the subscriber, on page 4-29 for more information on scripts.

After you install the agent, you can modify the configuration by running the configuration program, installationRoot/bin/gsAgentConfig.

To install an agent on a Windows server

Run the following installation on each Windows server that you want to install the GLOBAL-SITE agent on. You do not install this on the GLOBAL-SITE Controller.

Following are step-by-step instructions for running global-siteagent.exe.

1. Log on to the server using an account in the Administrators group, and exit from all other Windows applications.
2. Connect to the setup program on the GLOBAL-SITE Controller. From a browser on the server, use the name of the GLOBAL-SITE Controller in the following URL:
   
   

   https://<GLOBAL-SITE-CONTROLLER>

3. On the opening screen, click Agents.
   The Agent Download screen opens.
4. Click Windows.
5. Select Run this program from its current location, and confirm it in the next popup screen.
6. Read the Welcome screen and click the Next button.
7. Read the license and click Yes if you agree to the terms.
8. Read the acknowledgement screen and click Next.
9. Accept the default destination folder or browse to select an alternative, and then click Next. The default destination folder is
   
   

   c:\Program Files\F5 Networks\Global-Site Agent

10. Press Enter to accept the default of a non-SSL-enabled agent, or type y and press Enter to enable SSL on the agent.
    
    Note: If you enable SSL for your agent, every section or subscriber that uses this agent must use the WebDAV-SSL transfer method (see WebDAV-SSL, on page 4-20 ). If you disable SSL for your agent, every section or subscriber that uses this agent must use the WebDAV transfer method (see WebDAV, on page 4-19 ).
11. Type the port the agent monitors. The range is 1-65535 and the default is 50000. You need to use the same port number for every section or subscriber that gets this agent, so please make a note of it.
12. Type the directory to which files are delivered. This usually matches your IIS DocumentRoot directory. The default is:
    
    

    c:\inetpub\wwwroot

13. Select the hosts that can access the agent (it is safer to limit access to the IP address of the GLOBAL-SITE Controller):
    
    
    • all
      All hosts with a password can access the agent (the default.
    • domain.com
      Only hosts in domain.com can access the agent.
    • IP address
      Only one host can access the agent (the hostname does not work).
14. Select one or more of the following options to restrict the agent:
    
    
    • Restart the web server and reboot the computer
    • Register and unregister components
    • Deliver and activate files on this computer
15. Add users and passwords in the Agent Password Manager popup screen.
16. When you finish typing names and passwords, click Exit.

To install an agent on a Solaris or Linux server

Run the following installation on each Linux or Solaris server that you want to install the GLOBAL-SITE agent on. You do not install this on the GLOBAL-SITE Controller.

Following are step by step instructions for running gsAgentInstall.

1. From the GLOBAL-SITE Controller home page, (https://<GLOBAL-SITE Controller>), click Agents.
   The Agent Download screen opens.
2. Click the appropriate agent for your server: SolarisAgent2.6.tar or LinuxAgent.tar.
3. Copy the agent tar file to your server.
4. Log in as root to the directory on your server where the agent tar file has been copied to.
5. Run the following commands:
   
   

   tar -xvf LinuxAgent.tar

   ./gsAgentInstall

6. Press Enter to accept the default destination directory, or enter a different directory in which to install the agent. The default destination directory is /var/f5.
7. Press Enter to accept the default of a non-SSL-enabled agent, or type y and press Enter to enable SSL on the agent.
   
   Note: If you enable SSL for your agent, every section or subscriber that uses this agent must use the WebDAV-SSL transfer method. If you disable SSL for your agent, every section or subscriber that uses this agent must use the WebDAV transfer method.
8. Type the port the agent monitors, or press Enter to accept the default of 50000. The range is 1-65535. You need to use this same port number for every section or subscriber that uses this agent, so please make a note of it.
9. Type the base directory to which files are delivered (for subscribers) or read from (for sections). Press Enter to accept the default of /var/www.
10. To be more secure, limit access to the IP address of the GLOBAL-SITE Controller that uses this agent. Type the hosts that can access the agent or press Enter to accept the default of all.
    
    
    • all - All hosts with a password can access the agent.
    • domain.com - Only hosts in domain.com can access the agent.
    • IP address - Only one host can access the agent (the host name does not work).
11. The following four choices restrict the agent's access to the server. Choose y to permit the agent (the default) or n to prevent it on the following actions:
    
    
    • Reboot the server
    • Restart the Web server
      If you chose to allow the agent to restart the web server, enter the commands to stop and start the web server on the following two prompts:
      
      

      /etc/rc.d/init.d/httpd start

      /etc/rc.d/init.d/httpd stop

    • Deliver and activate files on this machine
      For subscriber(s), you must accept the default or the GLOBAL-SITE Controller can not deliver files to the subscriber.
      
      If you are installing the agent for sections only, then you
      choose n.
    • Run custom scripts
12. Your entries are displayed on the screen. (If they are not, press Enter to re-enter the correct values.) Type y and press Enter to commit your entries and continue with agent installation.
13. The controller now generates a self-signed certificate.
14. When prompted, enter a user name and password to use for the agent. This must match the user name and password that you use for your section or subscriber.
15. Press Enter to complete installation and start the agent immediately, or type n and press Enter to complete installation, but not start the agent.
    
    

    To enable an agent for a subscriber

    This procedure is done on the GLOBAL-SITE Controller from a browser anywhere in the network.

16. In the navigation pane, click List Publications.
    The Publication List screen opens.
17. Click the name of the publication you are working with.
    The Publication Editions screen opens (for archived publications) or the Publication Sections screen opens (for non-archived publications).
18. Click the Subscribers tab.
    The Publication Subscribers screen opens.
19. Click a subscriber in the Name column or create a new subscriber (see To add a subscriber, on page 2-13 ).
    The Subscriber Detail screen opens. This screen has two tabs, Content Delivery and Agent Actions.
20. On the Content Delivery tab, select the transfer method WebDAV.
    A default Port setting appears.
21. Type the same port setting you specified when you ran the global-siteagent.exe program.
22. Type a user ID. This should be the user ID you use for WebDAV access to this subscriber.
23. Type a password. The agent uses the user ID and password to authenticate file transfers.
24. Click the Agent Actions tab.
    If you selected WebDAV on the Content Delivery tab, then the box for Use Content Delivery connection settings is checked.
25. In the Actions area, check one or more of the following boxes to remotely administer the services the agent provides to each subscriber. Note that the agent restarts all web services when finished.
    
    
    • Check Stop HTTP Server before activating content to stop the web services on the subscriber, enabling the agent to receive files and register components.
    • Check Reboot machine after activating content to allow the agent to reboot the subscriber to make it recognize newly registered components.
    • Check Initiate Scripts and choose the phase in which to run the scripts. Scripts are user defined and must reside in the correct directory to work properly. Please see Creating the scripts, on page 4-28 for more information about scripts.
    • (For Windows agents only) Check Register Components to allow the agent to register newly copied components on the subscriber. If the publication contains sections that have Register Components checked (on the Section Detail screen), then the Path field on the Subscriber Detail screen displays where components should be registered.
26. Click Update if you are making changes to an existing subscriber.
    Complete the settings on the screen if you are creating a new subscriber. Click the Help button for more information on this screen.

To enable an agent for a section

1. In the navigation pane, click List Publications.
   The Publication List screen opens.
2. Click the name of the publication you are working with.
   The Publication Editions screen opens (for archived publications) or the Publication Sections screen opens (for non-archived publications).
3. Click the Sections tab if you working with an archived publication. For non-archived publications you are already at this screen.
4. In the Name column, click the section name or create a new section (see To create a section, on page 2-8 ).
   The Section Detail screen opens.
5. Select the transfer method WebDAV.
   A default Port setting appears.
6. Type the same port setting you specified when installing the agent.
7. Click Save.
   The Section Detail screen refreshes to display your changes.

To test an agent for a subscriber or section

It is a good idea to check your connections once you have made changes to a section or a subscriber to make sure that everything is working well before you start sending files.

To do this, click the Test Connection button found on either the Section Detail or Subscriber Detail screen.
The Connection Test screen opens.

There are several possible test messages, but the most common are:

• The Contacting Agent on <server> on port <port number> line displays one of the following test messages:
  
  
  • Success
  • Error connecting to server
• The Authenticating to Agent as <userid> line displays one of the following test messages:
  
  
  • Success
  • No agent present
  • Stop and start Server (OK or DENIED)
  • Reboot Server (OK or DENIED)
  • Deliver Files (OK or DENIED)
    
    

    · Register components (OK or DENIED)

Installing and configuring the GLOBAL-SITE agent and scripts

The GLOBAL-SITE Controller can run custom scripts, during specified phases and on specified publications, on subscribers running Microsoft Windows NT, Microsoft Windows 2000, Sun Solaris, and Red Hat Linux. This feature requires user configuration on both the subscriber and the GLOBAL-SITE Controller. The GLOBAL-SITE Controller configuration is documented in the online help for the Subscriber screen. This section describes how to configure the subscriber to match the GLOBAL-SITE agent script configuration.

Configuring the subscriber

You must install the GLOBAL-SITE agent on every subscriber that has been configured; you can use the steps described in the section Installing the GLOBAL-SITE agent on the subscriber, on page 4-22 of this chapter. You configure the agent to run scripts on the server. You must also copy, to each subscriber, the scripts that need to run. The following sections describe the phases at which you can run the scripts and provide an example of the directory structure that you must use.

In the example that follows, <agent installation directory> is the directory where the agent software gets installed, and not the directory where data files are accessed. Installing the agent creates the <agent installation directory>/cgi-bin/UserScripts directory, however you must create the <publication name>/<publication phase > directory before you copy scripts into it. For example, any scripts you want to run in the Before Copy phase must be copied into the following directory:

<agent installation directory>/cgi-bin/UserScripts/<publication name>/BeforeCopy

Following is the list of publication phases. The name of the directory you need to create for each phase is listed with the phase name.

• Before Copy
  The Before Copy publication phase runs the scripts before any files are copied to the subscriber. You can run any number of scripts during this phase. Name the directory BeforeCopy.
• Before Activate
  The Before Activate phase runs the scripts before any files are activated on the subscriber. You can run any number of scripts during this phase. Name the directory BeforeCommit.
• After Activate
  The After Activate phase runs the scripts after all files are activated on the subscriber. You can run any number of scripts during this phase. Name the directory AfterCommit.
• After Publication Success
  The After Publication Success phase runs the scripts after a publication is successful. You can run any number of scripts during this phase. Name the directory OnSuccess.
• After Publication Fail
  The After Publication Fail phase runs the scripts after a publication fails. You can run any number of scripts during this phase. Name the directory OnFail.

Creating the scripts

Any scripts that you want the GLOBAL-SITE agent to use must have the following characteristics.

• The scripts must be executable, in their directory, by the default web server user.
• On UNIX systems, the default user is typically nobody.
• The scripts must return a status code value of zero on success, and a non-zero value on failure.
• Successful script completion is logged. However, the status of the script completion does not affect the status of the publication.

When there are multiple scripts in a directory, the agent tries to run all the scripts. You cannot control the order in which the agent runs the scripts. The controller reports success only when all scripts in the directory return a zero value. If one or more of the scripts exits with a non-zero value, the behavior of the scripts and the returned error value is <. If you want to control the execution of multiple scripts in the same directory, we recommend that you create a master script, in a script directory, that executes the other scripts (which are placed in a private directory) in an ordered fashion.

If a script is not successful, you may want to verify the following potential problems: the script is not set as executable, the script has a dependency on a different directory, and whether there are files in the directory that are not scripts.

Installing the scripts on the subscriber

You can manually copy the scripts into the UserScripts directory on the subscriber, or you can deploy the scripts using the GLOBAL-SITE Controller.

To copy the scripts to the subscriber from the command line

1. Locate the installationRoot/cgi-bin/UserScripts directory.
2. Create a directory for each publication group that requires scripts.
3. Beneath the publication group directory, create a directory for the phase in which to run the script.
4. Copy the script to the newly created directory.
5. The GLOBAL-SITE agent expects to find scripts in the following directories: BeforeCopy, BeforeCommit, AfterCommit, OnSuccess, and OnFail.

The following is an example of a correct directory structure:

/var/f5/agent/cgi-bin/UserScripts/Pub1/BeforeCopy/precpy.sh

A GLOBAL-SITE publication can deliver scripts to the target directories by using the WebDAV transfer method.

To deliver scripts to the target directories

1. Create a publication that has a section for each phase that requires scripts.
2. Create subscribers that use the WebDAV transfer method.
3. The path section mapping should look similar to the following example:

   Section Destination path

   secPreCpy /UserScripts/<PubGrp>/BeforeCopy

   secPreCommit /UserScripts/<PubGrp>/BeforeCommit

   secPostCommit /UserScripts/<PubGrp>/AfterCommit

   secOnSuccess /UserScripts/<PubGrp>/OnSuccess

   secOnFail /UserScripts/<PubGrp>/OnFail

4. Run test connections to create the directory hierarchy.

Running the scripts using the GLOBAL-SITE Controller

You can run scripts using the GLOBAL-SITE Controller by checking the Initiate Scripts option on the Agent Actions tab on the Subscriber Detail screen. Click the Detail button next to the Initiate Scripts option to display the phases at which to run the scripts. The details of these screens are described in the online help for those screens.

Transferring files using WebDAV and WebDAV-SSL

WebDAV offers several advantages over traditional FTP:

• WebDAV uses HTTP/1.1, which uses network connections more efficiently than FTP.
• WebDAV can use either basic or digest authentication; digest authentication provides more secure password transfers. (To use digest authentication with a Windows 2000 server, the server must be configured as a domain controller.)
• WebDAV can set the execute permission on files, enabling you to deliver and run scripts on every web server.
• WebDAV on top of SSL can encrypt content as well as passwords.
  
  

  WebDAV-SSL offers one significant advantage over regular WebDAV: encrypted content files. WebDAV applies secure socket layer (SSL) encryption to both passwords and content files, adding significant security to file transfers. This level of security, however, adds overhead that reduces file transfer performance.

  Using the GLOBAL-SITE agent requires that sections use either the WebDAV or WebDAV-SSL transfer method. For more information, see Controlling servers with the GLOBAL-SITE agent, on page 4-21 .

  WebDAV uses HTTP/1.1 to transfer files. If you have installed the GLOBAL-SITE agent, you can use WebDAV even if your web server does not support it. The web servers that do support WebDAV are IIS5.x or Apache HTTP Server with mod_dav. For more information on WebDAV in general, see http://www.webdav.org.

Section updates using HTTP

We designed the HTTP transfer method to be used to push content to EDGE-FX Caches. Using the HTTP transfer method offers many advantages over other transfer methods you could use to populate EDGE-FX Caches. First, when you use the HTTP method, regardless of the number of caches you have, the web server is only polled once for content, instead of once for each cache; the controller then pushes the content out to the caches. Second, if the web server is password protected, only the controller needs to have the user name and password pair to access the server. The caches do not need to have this information. Third, you can prepopulate the caches with content, allowing the cache to serve pages much more quickly and to use less bandwidth since it does not need to poll the web server to check for new content.

Note: The HTTP transfer method is only available to transfer data from the web server to the GLOBAL-SITE Controller. The controller does not use this method to send files to subscribers.

Understanding the HTTP transfer method

For the HTTP transfer method, the controller uses a spider application (also known as a webcrawler), which goes through the web server's directories and files, collects the content, and downloads it to the controller. What the spider application gathers, depends on how the web server configuration is set up for default entry pages. The spider application works one of two ways.

• If you use a default entry page (for example, index.html), the controller (through the spider application) follows all the links that it finds in that file and downloads them.
• If there is no default entry page, and the web server allows directory access, the spider application returns a directory listing of the URL path to the controller. The controller subsequently downloads all the links in the directory listing, including files and directories. The controller recursively scans HTML files and downloads the links as well. The controller also traverses the directories looking for default files. The cycle continues until the controller finds no more new files (or until it reaches its download limit of 128 levels of the web tree).
  
  

  There are some content download restrictions that you should understand to ensure that the controller collects the content you expect.

• The controller does not follow or download links that are above the directory you specified in the URL.
• The controller does not follow or download links that point to a host that is not the section host.

Why use a web server

The content on your web server is the content you want on your cache. We designed the HTTP transfer method to work with web servers and caches. You can use your existing web server and the GLOBAL-SITE Controller to push your web content to your caches, eliminating the need for your caches to poll your web server.

Configuring an HTTP section

There are a few rules that you must follow to successfully use the HTTP method for transferring section content to the controller:

• The server that the content comes from must be a web server.
• The cache subscribers must be EDGE-FX Caches.
• The URL specified for the section (which is a concatenation of the user interface fields: Server, Port, and Path) must be valid. In other words, if you type it into the Address field on a browser, the web page opens.
• The path the you enter in the Path field is equivalent to <path> in the following:
  
  

  http://<hostname>:<port>/<path>

  We strongly recommend that you use this method for cache subscribers only. The reason is that storing dynamic content, such as queries and scripts on the cache might not make sense since the content might need to be generated in real time or the cache may not be configured to cache dynamic content. The other available transfer methods are better suited to create sections for server subscribers.

Using the HTTP transfer method

The most efficient use of the GLOBAL-SITE Controller is using it to publish to your web server, and then using the fresh content on the web server to create HTTP sections, which are then in turn, pushed to your caches. To do this, you create two separate publications, which use different types of sections, and create the subscribers (both server and cache) to receive the content. You then publish first to the web server, and then push content to the caches.

Following are the recommended procedures to follow to successfully use the HTTP transfer method:

• Create a publication that gets published to your web server (see Defining publications, on page 2-3 ). This publication does not use the HTTP transfer method sections. It can use any of the other four transfer methods for its sections. (See Understanding file transfer methods, on page 4-18 for more information.) The host for these sections is your staging server.
• Create a web server as a server subscriber (See Specifying subscribers, on page 2-12 for details on how to create a server subscriber.)
• Create a publication that uses HTTP transfer method sections (see To create an HTTP section, on page 4-33 ). The host for this publication's sections is the web server that is the server subscriber mentioned in the previous bullet.
• Create cache subscribers for each of your EDGE-FX Caches. For details on how to create cache subscribers, please see Specifying subscribers, on page 2-12 .
  
  Tip: After you create your first cache subscriber, use the Clone button to create a cache subscriber for each of your EDGE-FX Caches that need to receive the publication.
• Publish to the web server.
• Once the controller finishes publishing to the web server, push the HTTP publication to the caches.

Tip: You should create publications that use HTTP sections as non-archived publications. There is little reason to keep this type of record of content that goes to the cache. You can create the server subscriber version of the publication as archived if required. Non-archived publications are published much faster than archived.

To create an HTTP section

1. From the Publication List screen, click the name of the publication you created to be your HTTP section publication.
   If you created this publication as non-archived (recommended), the Publication Sections screen opens.
2. Click the Create New Section button.
   The Create a New Section Screen opens.
3. In the Section Name box, type a descriptive name for the section.
4. In the Server box, type the fully qualified domain name of the web server. This host name, when combined with the path you enter on this screen (see step 9) must create a viable URL. The spider application uses this information to find its starting place on the web server. This URL also shows up on the Add a Cache Subscriber screen.
5. Check the Enabled box.
6. Leave the default (check box cleared) for Delivery Actions.
7. In the Transfer Method box, select HTTP.
   The port automatically changes to 80.
8. If your web server is password protected, fill in the User ID and Password boxes. If you do not have the web server password protected, you can skip these two boxes.
9. Type the path for this section. The path should start at the point at which you want the spider application to begin getting content. Usually this is the directory that contains your default entry page. See Understanding the HTTP transfer method, on page 4-31 for information how the path affects the spider application.
   
   For example, if your URL is:

   http://company.domain.com/index.html

   then your path is:

   /

10. Type any paths or use the Browse button to eliminate any paths that you do not want the spider application to get content from.
11. Type any file extensions that you want included in or excluded from the section.
12. Click the Create button to create the section.

Section updates using FTP-Push

FTP-Push is a file transfer method to the GLOBAL-SITE Controller that is based on basic FTP. FTP-Push enables sections to push content to the GLOBAL-SITE Controller. When using FTP-Push, the GLOBAL-SITE Controller acts as an FTP server. You can also configure FTP-Push sections to trigger the delivery of a publication.

FTP-Push has two distinct purposes:

• You can use FTP-Push to transfer files to the GLOBAL-SITE Controller to await publication. FTP-Push sections contact the GLOBAL-SITE Controller and transfer files when content has changed.
• You can use FTP-Push sections to trigger the delivery of new content to the subscribers if you are using FTP-Push to move files to the GLOBAL-SITE Controller.

Warning: We recommend that you attempt to use FTP-Push only if you are familiar with FTP commands.

You must follow this sequence to create an FTP-Push section.

• First, create the publication (see To add a publication, on page 2-4 ) if one does not already exist. You can share FTP-Push sections on more than one publication.
• Second, create a section and specify FTP-Push as the transfer method.
• Third, add content to the FTP-Push section (see To add content to an FTP-Push section, on page 4-35 ). (You can use FTP-Push in conjunction with a web development environment to FTP files directly to the GLOBAL-SITE Controller.)
• Fourth, set up the FTP-Push section to trigger delivery of content to subscribers. This step is optional.
  
  

  Note: The GLOBAL-SITE Controller derives the user ID and path from the section name.

To create an FTP-Push section

1. From the Create a New Section screen, select FTP-Push as your Transfer Method. (You must select the transfer method first when setting up FTP-Push.)
   The screen refreshes when you select FTP-Push, and the only available boxes are Section Name, Description, and Password.
2. Fill in the available boxes. For more information, click the Help button on the top right of the screen.
3. Click the Create button.
   The Section Detail screen opens with the modified information.

To modify an FTP-Push section

You can modify only Description, Enabled, and Password on the Section Detail screen for FTP-Push.

1. In the navigation pane, click List Sections.
   The Sections List screen opens.
2. In the Publication Membership column, click a publication name associated with the FTP-Push section.
   The Publication Sections screen opens.
3. In the Name column, click the section name.
   The Section Detail screen opens.
4. Make any necessary changes to the available attributes. For more information about this screen, click the Help button at the top right of the screen.

To add content to an FTP-Push section

You add content to an FTP-Push section by opening an FTP session on the GLOBAL-SITE Controller using the FTP-Push section's user ID, password, and path. Using standard FTP commands, create and remove directories, add and remove files. If you are using a graphical user interface for FTP, follow your software's directions for moving files.

1. Start an FTP client (not on the GLOBAL-SITE Controller) on the machine with the content and open a connection to the GLOBAL-SITE Controller.
2. Log in using the user name and password you specified when you created the section.
3. Use the FTP command PUT to deliver files to the correct directories on the GLOBAL-SITE Controller machine that is publishing the content. (You may have to use the FTP command MKDIR to make directories before you copy files to them.)
   The files are transferred to the GLOBAL-SITE Controller machine.

To retrieve a previous file version from an archived FTP-Push session

You can use FTP to retrieve files from a previous version of an archived FTP-Push section.

1. Using FTP, log on to the GLOBAL-SITE Controller using the FTP-Push user ID and password.
2. Create the FTP version directory by appending a plus sign (+) and the version number to the FTP-Push section path.
   
   

   /<section name>+<version#>

   /section+28

3. Use FTP to change the working directory to the FTP version directory.

Setting up FTP-Push to trigger section delivery

If you set up an FTP-Push section in a publication to trigger delivery, once the FTP client delivers the files for that section, and the it logs off the FTP session, the GLOBAL-SITE Controller delivers all the sections of that publication to the subscribers.

You may have five sections with content that comes in at different times, but you want to publish all the sections concurrently after they all have updated content.

To control when FTP-Push sections publish, you can set up a section that has no content. You configure only this section to trigger delivery (see To use an FTP-Push section to trigger a publishing cycle following). When you are ready to deliver the publication, you transfer a dummy file to this section, triggering the delivery of all sections for that publication to the subscribers.

Delivery of a publication to subscribers starts after FTP logout. How long after FTP logout depends on how you set Initiate ___ minutes after FTP logout on the Publication Options screen. If other FTP sessions log in before the delay times out, the timer starts anew after that session logs out.

If you do not want to use FTP-Push to trigger delivery, you have the option of starting the delivery manually or on a schedule (see Scheduling the activation of new content, on page 4-4 ).

Warning: FTP-Push does not trigger delivery until after FTP logout. If another FTP session starts before Initiate ___ minutes after FTP logout times out, the timer resets and does not restart until after the current FTP session logs out. If FTP sessions keep logging in before the timeout, it is possible to never propagate the section.

To use an FTP-Push section to trigger a publishing cycle

1. In the navigation pane, click List Publications.
   The Publication List screen opens.
2. In the Name column, select an existing publication.
   A Publication detail screen opens.
3. Click the Pub. Options tab.
   The Publication Options screen opens.
4. Under Initiating Publishing Process, click the FTP-Push button to choose FTP-Push to trigger publishing.
   The Initiating Sections box becomes available.
5. Click the FTP-Push section(s) that you want to trigger a publishing cycle for this publication. To select more than one name, hold down the Shift or Ctrl key as you click.
   
   

   If you are using a dummy page to trigger publishing, select only that section. (See Setting up FTP-Push to trigger section delivery, on page 4-36 of this chapter.)

6. If you want to delay delivery after the FTP session logs off, type the number of minutes (0-60) you want to wait.
7. Click the Apply Changes button.
   The Publication Options screen refreshes.

Defining exceptions to sections

As you set up your basic publications and create various sections, you may want to create exceptions to the section. Exceptions instruct the GLOBAL-SITE Controller to disregard specific subdirectories. An exception is a way of excluding a subdirectory from being published as part of a section.

The most challenging part of setting up exceptions is planning the publication in advance, so that sections and exceptions work to your benefit. Remember that, when first created, each section includes all files and directories at the given path. To exclude a subdirectory from the section, you must clear the box for that subdirectory. Note that you cannot exclude files, only directories, on the Section Browser screen. See Including or excluding file extensions, on page 4-39 for information on listing file extensions to include or exclude.

Creating exception paths

There are two ways to create exception paths: for one, you can browse the directories, for the other, you need to know the directory path that you want to exclude.

Example

In this example, the source directory /home/webcontent/testsite contains a subdirectory /home/webcontent/testsite/images that we want to manage with a separate section.

Assuming you have already created your initial section, start at the Section Detail screen to create an exception path (in our example, it is sec1).

Figure 4.4 The Section Browser screen, showing clear boxes for exceptions

To create an exception using the Section Browser screen

Start at the Section Detail screen.

1. Next to the Path box, click the Browse button.
   The Section Browser screen opens.
   
   

   This example assumes the path is already defined. The four boxes at the top of the screen display the content server address, the user ID and password needed to access the server, and the path.

2. In the Path area at the lower left, the path appears in the top line: /home/webcontent/testsite. The remaining lines contain the names of the subdirectories in the path. Clear the box in front of the images subdirectory.
   The exception path appears in the Exception area to the right.
3. To save your settings, click the Update button.
   The Section Detail screen opens again, with the exception path listed below the Path box.

To create an exception using the New Exception box

We recommend you use this method to create exceptions when you have a lot of directories. Start at the Section Detail screen.

1. In the New Exception box, type the name of the directory you want to exclude. For this example, it is /home/webcontent/testsite/images.
2. Click the Add button directly to the right of the New Exception box.
3. Click the Save button to commit the changes to the section.

Tip: In all cases, the directory path for all section sources and subscribers must already exist on the specified servers. The GLOBAL-SITE Controller does not create them. For subscribers, it can create subdirectories, but it cannot create the initial root path.

A little more about exceptions

You may have questions about directory paths when you are setting up multiple sections that use exception paths. The typical situation is that one section's exception is another section's root. Even in that context, that path must already exist, or you must first create it manually on the subscriber.

For example, say that section1 goes to /root/section1. It seems reasonable that /root/section1 must already exist. You cannot assume you have permission to make it, especially on NT servers where it might be virtual.

Including or excluding file extensions

Within the directories where you store your content, you may also have files that you do not want to publish or deliver to your subscribers. With the GLOBAL-SITE Controller you can exclude files by their file type for this reason. Or you may have all types of files in a directory, but only want to publish the .html files. The GLOBAL-SITE Controller also allows you to include only file types that you specify.

To include or exclude file extensions

1. In the File Filter(s) box, type one or more file extensions, separated by spaces. For example, cgi gif html.
2. Click Exclude to keep files with these extensions out of the path, or Include to add files with these extensions to the path.