Ohio University - HomeApply Online Now!
Search
Ohio.edu Sites
Name Directory
Oak, Email, Identifications (IDs)Internet, Network and TelephonesComputers and Computer LabsSoftware and DownloadsWebsite DevelopmentAcademic ServicesAdministrative ServicesSecurity and PoliciesHelp and Support
Office of Information Technology at Ohio Universitycomputer purchase programService Desk
System Status (BigBrother)Outage InformationNew to OU? Here's what you need...search all IT pages
You are here: Ohio University :: Technology :: transition 

 Advanced Search

VMS Front Door Server Retirement

Scope   Follow-Up   Other Info   Changes   Schedule   Preparation   Pre-Migration   Deployment


Scope

The old CSCWWW server has now been permanently retired. Therefore, the sections of this page, below, entitled Schedule, Preparation, Pre-Migration, and Deployment are all of historical interest only. This section, and the two immediately following sections, however, are still of some continuing interest.

This information is intended for those who were responsible for pages published on the server that had been known as "CSCWWW" or as "the VMS Front Door server." Those pages displayed with URLs that started:

  • http://www.ohiou.edu/

  • http://www.cats.ohiou.edu/

  • http://cscwww.cats.ohiou.edu/

Although reachable with URLs that started http://www.ohio.edu/, all of these pages had been displayed after the browser had been redirected to one of the three variations above (usually the first one), so if you inspected the browser's address box while looking at the page, you could confirm which server it came from.

The changes described here do not apply to pages on the OAK server, nor to pages on the CommonSpot Front Door server or that have migrated to the new static-page server, whose URLs start:

  • http://oak.cats.ohiou.edu/

  • http://www.ohio.edu/


Post-Migration Follow-Up

There are several items you should address promptly now that your pages are migrated, and the old server is permanently offline:

  1. Review all links on your pages to find any whose HREF values use absolute URLs with any of the three server name variations called out in the Scope section, above. Except for archival pages (e.g., back editions of a department newsletter), all of those links should be changed promptly:

    • if it has a tilde ("~"), then the URL has changed, so follow the link now, and wait to see where it lives;

    • if it is already tilde-free, then just substitute "www.ohio.edu" instead of any of the old server names.

  2. Review all of the files (HTML pages, images, and binary documents) in your subsite, and remove any relics that should no longer be part of your subsite. If any of those relic items is an HTML page, consider replacing it with an HTML page that reports the fact that it has been retired, and provides a link (possibly also a Refresh META tag) to go to the most appropriate surviving page.

  3. Cross-check with both of the archival versions of your subsite that you saved during the pre-migration, to confirm that no item is missing from the production server that should still be included.

  4. Unlike the old server, the new server will permit you to upload folders and files whose names contain spaces, multiple periods, and a variety of other unfortunate characters. Building your site that way will generate ugly, hard-to-type URLs (e.g., every space character in a folder or file name turns into a "%20" in the URL) and will compromise your ability to migrate smoothly to possible future servers.

    Please keep your folder and file names "server agnostic":

    • use only letters, digits, hyphens ("-"), and underscores ("_");

    • keep the case of letters in the HTML (HREF= and SRC=) consistently matched to the file and folder names on your disk drive;

    • have no periods in folder names;

    • have exactly one period in file names, with the part that comes after the period in the file name being the conventional "extension" or "type" for that kind of file (e.g., ".htm" or ".html" for HTML files; ".jpg" or ".jpeg" for JPEG image files; etc.);

    • have no other punctuation marks, nor any spaces, in folder or file names.

  5. We will be running regular checks of folder and file names on the new server, to help pagemasters weed out any file or folder names with spaces or tildes.


Other Information

Other information is available online, linked from

In particular, if you have a custom search that is still trying to use the old Thunderstone search engine (which has been shut down), then you should immediately re-code it to use our new Google Search Appliance.

Likewise, if you have a form that collects information and uses either of the obsolete scripts (on OUVAXA or ILIAD) to transcribe it into an e-mail, then you should immediately re-code it to use the new MAILER script.


Changes [retained for historical interest only]

The Office of Information Technology has retired the server that had published these pages, and replaced it with a new one.

The new server does not run the VMS operating system, so, from now on, we will refer to the new and old servers as the "Static-Page" Front Door servers. This terminology is based on the fact that these pages are pre-built by the pagemaster, and uploaded to the server's disk drives, where they are immediately available when requested. They are not created by server software at the time they are requested (".CFM," ".PHP," and ".ASP" pages, on the other hand, are assembled -- "dynamically" -- when they are requested).

The following describes the changes involved in this retirement and replacement:

  1. The transition process started over the Labor Day weekend. We are migrating one subsite at a time (we intend to average about a dozen subsites a day until the process is complete).

  2. Until it is time for your subsite to migrate, the details of uploading your files to the old server will not change.

  3. The details of uploading your files to the new servers (staging and then production) will be different: you will connect to a different server name (ww2.ohio.edu), use Secure FTP instead of standard FTP, and use your OAK login ID and password, instead of a username and password specific to the server. Your subsite's files no longer live in the "WWW" folder inside your personal login folder. Instead, all Web files on the server are collected into one place (a folder on the server's E: drive named "ww2.ohio.edu," inside of which is a folder for each subsite), in folders named and organized to match their URLs exactly.

    • Using SFTP will permit uploading through an on-campus wireless connection, which is not possible with the old server.

    • Using OAK login IDs will permit us to contact the responsible pagemaster quickly in the event of problems with your site. Using OAK passwords will mean that you don't have to remember yet another different password.

    • If you have not changed your password since October 1, 2007, then you must do so before it will work with the new server. You can follow the "Change Your Password" link in the upper-left of http://technology.ohio.edu/myaccount/.

    • We have confirmed that the current versions of Fetch on Macintosh and FileZilla on Windows can be configured to work, and we have documented the new configuration and upload procedures, step-by-step.

    • We anticipate that the SFTP software built-in to DreamWeaver and other page-editing tools, as well as a wide variety of other SFTP packages, will also be usable. If you encounter problems with other SFTP software, please confirm that you can succeed with FileZilla or Fetch, and then report any problem you continue to encounter.

    • We will use "groups" on the server to control upload access to the web folders:

      • You will only be able to upload files and folders into your subsite's folder on the server.

      • Other pagemasters will be able to see that your subsite's folder exists, but will not be able to see what is inside it, except through the web.

      • Collaborative work on subsites will simply involve more than one person being in the pagemaster group for that subsite.

      • Pagemaster turnover will simply involve moving people out of and into the pagemaster group for that subsite.

  4. Tildes ("~") will never occur in URLs on the new server:

    • Student Organizations (whose subsites are the vast majority of the tilde-based subsites now in place) will by default keep the other characters of their name, and when they migrate, they will migrate into the new subsite "orgs"; for example:

      http://www.ohiou.edu/~aphio/

      will become

      http://www.ohio.edu/orgs/aphio/

    • Other tilde-based subsites will be handled on a case-by-case basis. If your pages currently display only with a URL that includes a tilde, please let us know your preferred tilde-free URL, by e-mail to webteam@ohio.edu.

    The vanishing of tildes does not at this time apply to personal or organizational pages on OAK, only to pages on www.ohiou.edu and any of the server name variations called out in the Scope section, above.

  5. Throughout the process and after it is finished, the primary URLs for your page will continue to work to bring up your pages (including URLs formed with all three of the server name variations called out in the Scope section, above). Secondary URLs, such as the old tilde-based ones that most official subsites stopped using long ago, will eventually stop working to bring up your pages; we will announce the timetable for expiration of secondary URLs as soon as it is established.

  6. We have installed the new Static-Page server, but not the old Static-Page server, behind the same "load-balancer" that is used by the new CommonSpot Front Door servers. See the diagram and discussion that is online in the new pagemasters material. As a result:

    • anyone looking for any migrated page using a URL with "www.ohio.edu" will see the page with that URL, with no delay for a redirect to "www.ohiou.edu";

    • anyone looking for any migrated page using a URL with "www.ohiou.edu" (or either of the other server name variations called out in the Scope section, above) will be redirected to "www.ohio.edu" and will see the page with that URL;

    • pages that have not yet migrated will continue to be seen at any of the three server name variations called out in the Scope section, above (after a redirect, if they are requested from www.ohio.edu);

    • by the time the transition is complete, everyone looking at your pages (or any other Front Door server pages), will see the browser showing a URL that uniformly uses the server name, "www.ohio.edu," instead of any of the server name variations called out in the Scope section, above; and

    • you will be able to replicate the standard look-and-feel of CommonSpot pages built with the "official_pages1" template, including the site-wide nav bar, as demonstrated at http://www.ohio.edu/transition/blank.html, which is on the new static-page server.

  7. The new environment includes a separate staging server (wws2.ohio.edu), rather than having a test folder for each account on the production server. The staging server is configured identically to the production server, except for its name, and the fact that you can see its pages directly, unlike the production server, whose pages are seen only as part of www.ohio.edu.

  8. If any of your pages are currently password-protected, your subsite will be among the later subsites to migrate, but when they are migrated, the protected pages will be served securely (https://, instead of http://), and you will be able to control access to those pages in terms of OAK login IDs (you won't have to maintain files with usernames and passwords).


Schedule [retained for historical interest only]

The various subsites were migrated from the old server to the new one between Labor Day, 2008, and the end of April, 2009.


Preparation [retained for historical interest only]

There are several steps you should take, starting now, that will reduce the intensity of the work you need to do when the time comes to move your own pages onto the new server:

  1. If you are using Windows, and uploading files with any software other than FileZilla, Version 3.0.9.3 or later, then obtain, install, configure, and practice uploading files to the current server using FileZilla. We have confirmed that FileZilla can be adjusted to work properly with both the old server and the new server, and it is free.

  2. If you are using Macintosh, and uploading files with anything other than Fetch, Version 5.3 or later, then obtain, install, configure, and practice uploading files to the current server using Fetch. We have confirmed that Fetch can be adjusted to work properly with both the old server and the new server, and it is free.

  3. Please promptly send e-mail to webteam@ohio.edu:

    • confirming which subsite(s) you are responsible for; and

    • providing the name and OAK login ID of any others who will also be working on those pages.

In mid-July, we migrated a copy of every subsite (except those that contain password-protected pages) from the old server to the new staging server. In that process, we saved the most recent version of each file from the old server, removed the semicolon and version number, and shifted all uppercase letters in folder and file names to lowercase.

We have migrated and deployed pages maintained by the Front Door Web Team and the OIT Web Services staff onto the new staging and production servers first, for practice, to confirm that it works as planned, and to provide the maximum opportunity to fine-tune the process and the documentation: we were the primary experimental subjects! Now, we are working with each pagemaster to complete your own migration and deployment.


Pre-Migration Outline [retained for historical interest only]

This section and the following section provide outlines of the process. Detailed instructions are now available online.

During the later parts of this stage, you will be working with two online versions of your subsite, one on the old server, and one on the new. Therefore, you will have to upload all changes twice: once to the old server, and once to the new server. The more promptly you move through this stage, the less such duplicate effort will be needed.

You will pre-migrate your subsite, as described in the detailed instructions. Having a pre-migration followed by a deployment is designed to minimize the time when you are not able to update your pages. The following steps outline the process:

  1. You will have the opportunity to save, on your disk drive, two separate, archival copies of the pre-migration subsite:

    • as it exists on your disk drive already, and

    • as it exists on the old server (either the mid-July version, or a newly migrated version, from the staging server).

    The detailed instructions include specific steps in the process when these archival copies should be saved.

  2. You re-create your subsite, up to date, on the new staging server (wws2.ohio.edu), and confirm by direct experiment that you have correctly adjusted the configuration of your SFTP software, so that you will be able to resume authoring activities promptly on the new production server when the migration is complete.

    • In many cases, the quickest and simplest approach will be for you to login to the staging server, navigate to your subsite's folder, remove the mid-July files, and upload the full, current subsite from the working copy on your disk drive.

    • In other cases, the best approach will be for us to agree on a time for a temporary authoring freeze, during which we remove the mid-July files from the staging server and then re-migrate the current version of your subsite from the old server to the staging server by our standard technique.

      After we have re-populated the staging server with current copies of your files, you will upload at least one HTML file and at least one binary file, and then confirm that they are displayed correctly.

  3. You inspect the pages on the staging server to see whether they appear to be intact. If there are problems, we work together to address them, without feeling the anxiety that we would feel if those problem pages were already visible to the public from the new production server.

  4. You tell us that the copy of your subsite on the new staging server is ready for deployment, and stop updating your pages.


Deployment Outline [retained for historical interest only]

At this time, we anticipate that typical deployments will complete the first four of the following steps in less than a day:

  1. OIT staff copy your subsite from the new staging server to the new production server.

  2. OIT staff use privileged access (bypassing the load-balancer) to confirm that your pages are displaying properly from the new production server (you can't do that, because at this stage the load-balancer is still redirecting everyone to the old server's copy of your subsite).

  3. OIT staff adjust the server and load-balancer configurations so that the world no longer sees your pages from the old server, but instead sees them from the new server. From now on, everyone looking at your pages will see that their browser displays the URL with the uniform server name, www.ohio.edu.

  4. You resume authoring, using SFTP with your OAK login ID and password to connect to the new production server, ww2.ohio.edu, but otherwise configured as you did for the staging server during the Preparation and Pre-Migration stages.

  5. We will disable your account on the old server promptly after the last subsite it controls has been migrated. We will eventually remove your files and account from the old server, erasing them permanently: the archives you saved during the Pre-Migration stage will be your long-term backup.


Dick Piccard revised this file (http://www.ohio.edu/transition/vmsretirement.html) on July 27, 2009.
Office of Information Technology
Ohio University
Athens, OH 45701
Service Desk:   servicedesk@ohio.edu   or   (740) 593-1222
Copyright © 2009 Ohio University.
 All Rights Reserved.