Microsoft FrontPage ExtensionsThe Zeus Web Server User Guide provides a basic guide to using Zeus Web Server with Microsoft FrontPage Extensions. This document is designed to raise awareness of some the real-world issues to consider when using FrontPage. Sections * Overview
OverviewMany Zeus customers have reported problems with FrontPage Extensions. From these, Zeus have determined that there are a number of problems within the design and implementation of this this technology. Please be aware that Zeus Technology are not responsible for any problems arising from such errors within Microsoft supplied software. We have put together this guide to help customers become aware of the issues as well as to offer advice on how to avoid and recover from FrontPage-related problems. Before installing FrontPage1. Ensure that you are running the latest version of Zeus Web Server. Please see this page to find the latest version:
http://support.zeus.com/doc/zws/v4/changes.html
2. Ensure that you have downloaded the latest version of the FrontPage Extensions:
http://msdn.microsoft.com/library/en-us/dnservext/html/fpse02unix.asp
Ready To Run Software (who wrote the UNIX FrontPage Extensions for Microsoft) supply more recent versions of the FrontPage Extensions. Their alternative platform compatibility list can be found here:
http://www.rtr.com/fpsupport/faq2002g.htm
(The Apache download will be suitable for use with Zeus Web Server.) 3. By using the links in item 2 ensure that you have a supported OS and version for the If you try to install the Extensions on an unsupported platform, you may receive a message similiar to this when running the fpinst.sh script:
Creating Web <website_name>
owsadm.exe failed
It is possible that the installation stage may succeeed on an unsupported platform... This does not mean that there will be no future problems Please be aware that if you choose to use FrontPage Extensions in these circumstances, then it will be at your own risk, and that our Support Team may need to refer you to our Consultancy Services to provide any help with subsequent problems you might experience with this third party product. Installation
Runtime ProblemsYou may recieve reports of clients failing to publish FrontPage webs with an error message similar to the following: Cannot run the FrontPage Server Extensions on this page The FrontPage extension error messages typically do not provide any meaningful output other than to indicate that something has gone wrong. Unfortunately there are a number of different situations in which you may see this error message. The FrontPage binaries store configuration information in the directories named _vti_* within the user's document root. It seems that this information can often become corrupted. The client software may report a "failure to publish" message if the _vti_ directories contain broken configuration information. In such a situation it is neccessary to remove all _vti_ directories, re-enable the website for FrontPage Extensions and then re-publish the website: 1. Enter the document root of the affected site belonging to the user who has been reporting problems. 2. Delete or move the directories that start with _vti_
e.g. find . -name "_vti_*" -exec rm -rf {} \;
3. Re-initialize the FrontPage Extensions for the website. This can be done by restarting the virtual server. If you are using subservers, use the fpinst.sh script instead. 4. Re-publish the website. Other causes of these "Cannot run the Frontpage Server Extensions" error messages may be caused by:
1. Document Root contents, including .htaccess 2. /usr/local/frontpage/ <website_name>:<port>.cnf 3 /usr/local/frontpage/zeus/<website_name>/ Common QuestionsQuestion 1How can I publish to an alias of website rather than using its virtual server name? My website is called www.example.com but I want to publish to its alias example.com. ... or ... I get this error when submitting a form: FrontPage Error. User: please report details to this site's webmaster. Webmaster: please see the server's system log for more details. Answer 1The FrontPage Extensions are not aware of any aliases that you may have defined for a website. The only site names that the Extensions will be available on are those listed in the following directories: /usr/local/frontpage/ /usr/local/frontpage/zeus/ To enable aliases, you will need to create symbolic links inside these two directories from the site name to its corresponding alias name. e.g. /usr/local/frontpage: ln -s <website_name>:80.cnf <alias>:80.cnf /usr/local/frontpage/zeus: ln -s <website_name>:80 <alias>:80
Question 2Is there a way to use the FrontPage forms interface to configure FrontPage webs? Answer 2Symlink /usr/local/frontpage/currentversion/admin into your document root directory and use the Admin Interface to add a MIME type to specify that ".exe" files are CGIs by using MIME Type "application/x-httpd-cgi". Then you can use the Microsoft supplied web forms to administer your FrontPage webs. Note you should apply access control to these pages to prevent unauthorized access. If you get '501 Not Implemented' errors when trying to access these scripts, it is possible that the files are still not being treated as CGIs. In this case also add an .htaccess file into the scripts directory containing the line: addtype application/x-httpd-cgi exe
Question 3I would like to secure my FrontPage installation, how is this best achieved? Answer 3The FrontPage Extensions are a collection of CGIs which can be restricted as to the amount of system resource that they use through the CGI Sandboxing Module. For this solution to work, each FrontPage-enabled document root for a given Virtual- or Sub- Server must be owned by a unique OS User ID and a unique OS Group ID. Note that after installation the UID/GID combination does not have to exist in the /etc/passwd or /etc/group files - no user lookup is performed on the values used. So long as both numbers are unused and unique, no problems should be encountered. Although not well defined, all Unix platforms should today support at least 32bit UID and GID values - making this solution suitable for even very large installations. The one problem with the above approach is that, due to a perceived bug in the FrontPage owsadm.exe binary, initial FrontPage installation will fail if the document root owner does not exist in the /etc/passwd file. The workaround is to install FrontPage into a document root owned by a "real" user, and then once complete, perform the command: "chown -R <UID>:<GID> $DOCROOT". Zeus consultants have previously implemented secured FrontPage installations with over 100,000 individual users - but you may wish to contact our sales department if you plan to implement a system for more than 20,000 users, as we have developed in-house tools for certain platforms which remove the performance problems that are encountered as the number of users increases above this threshold. Once each document root is owned by a unique UID/GID, then simply enable the "Run CGIs as owner of the document root" option of the CGI sandboxing module. This will prevent any user from being able to damage or overwrite any other user's data, even if trying to take advantage of a FrontPage exploit. Question 4How and where are FrontPage passwords stored? If I move my FrontPage installation, will my users' passwords remain intact? Answer 4FrontPage stores passwords in standard .htpasswd format: <user1>:<encrypted_password1>
<user2>:<encrypted_password2>
etc. FrontPage uses several files to store this data, all stored within $DOCROOT/_vti_pvt. The files are named service.pwd, service,grp and .roles - a vital file that is hidden by default. The service.pwd file, in the format above, stores the known users and their passwords. The service.grp file contains known groups and a whitespace seperated list of the users belonging to these groups. FrontPage recognizes two groups: Authors and Administrators. Authors can publish pages and alter content, whilst Administrators can change site-wide settings and manage users: Authors: <user1> <user2>
Administrators: <user3> The most important file, without which FrontPage publishing will fail, is the .roles file. This file will be similar to the following:
[Roles]
advauthor=0CEEEE02| |View, add, and change pages, documents, themes, and borders; recalculate hyperlinks.
admin=FFFFFF03| |View, add, and change all server content; manage server settings and accounts.
author=0C80EC02| |View, add, and change pages and documents.
browser=08008800| |View pages and documents.
[Anonymous]
AnonymousRole=browser
[Users]
<user1>=admin|FFFFFF03
etc.
This file (re)defines which users belong to which internal FrontPage groups. Passwords are determined by service.pwd, and .roles should be kept synchronized with service.grp, as the interaction between the two is ill-defined. Using the FrontPage client application or the management forms will automatically update these files as necessary. As all user, group, and password information is kept within the document root, this makes migrating the FrontPage installation is very easy - so long as none of these files is changed or removed, all authentication data is kept intact. Question 5When configuring FrontPage support I'm adding values into the "Extra FrontPage Extension Directives" section, but these changes are not having any affect! Answer 5If you are using subservers, then it is not possible to use "Extra FrontPage Extension Directives" to specify additional options. The solution is to enter the directives into the /usr/local/frontpage/<subserver_name>:<port>.cnf file directly. Question 6I see that a new version of frontpage has been released - how should I go about upgrading? Answer 6This is a relatively simple process: Unpack the tarball containing the new release to a temporary directory (not over your existing FrontPage installation). Rename /usr/local/frontpage/version5.0 to /usr/local/frontpage/version5.0.old Move the version5.0 directory from your temporary directory into /usr/local/frontpage/. Merge changes from /usr/local/frontpage/version5.0.old/frontpage.cnf into /usr/local/frontpage/version5.0/frontpage.cnf. This last step is necessary to ensure that the previous FrontPage configuration is maintained, whilst any new directives that have been added between releases are not lost. Question 7I've decided to change the hostname of a FrontPage-enabled virtual server, or have enabled SSL. Can I reconfigure FrontPage without having to reinstall it? Answer 7You will need to perform the following steps to acheive this:
Question 8I would like to share my FrontPage-enabled document root over a cluster via NFS. How do I do this? Answer 8To enable a shared document root, it is also necessary to keep the contents of the /usr/local/frontpage/ directory synchronized - either by distributing any changes made within /usr/local/frontpage/ to all webserver machines, or by also sharing /usr/local/frontpage/ by NFS. Zeus provides a script named fpinst.sh to deploy FrontPage to one or more machines. Unfortunately, this is only a wrapper for a Microsoft-supplied binary, which does not correctly copy the configuration files with the FrontPage core files. There are also some considerations that must be taken into account with NFS - some customers have reported file locking problems or strange transient errors occuring when using FrontPage over NFS. This problem seems to be largely dependant upon the NFS client software being used. Because of this, we would strongly advise that any deployment of FrontPage over NFS is thoroughly stress-tested before going into production use. A possible workaround on Linux systems is to use the "nolock" option for NFS, which removes the possibility of locking problems by not performing any locking! If this solution is used, great care must be taken to ensure that files are never concurrently updated.
Content Manager
[Administrator] 08 November 2005
|
Recent Articles
Other Resources
|
