Install and configure Front Page 5.0 (2002) extensions [HOWTO]

Customization Hacks / Tools / Tips / Tricks
1

I know all you linuxie types out there (like me) think Front Page is the devil. I agree with you, it IS the devil. However, The Customer Is Always Right, and the customer wants to use front page. Many people are in this situation. Right now it’s keeping me on the line about purchasing another Interworx license, or going with another product that supports front-page out of the box.

Today I had an excellent support experiance with the Interworx staff (great job guys!), that really pushed me towards purchasing another Interworx license… but the Front Page issue loomed its’ head. Many of my customers use FrontPage extensions to publish their websites. It is simply not an option for me - I must support this feature on my server.

So, I set out to make it work. I had to use a hatchet to get it done, too.

Here’s a general synopsis of what I did:

  1. Installed frontpage 5.0 with the archive and installer from RTR software.
  2. Compiled the apache DSO by doing:

cd /usr/local/frontpage/version5.0/apache2
chmod +x /home/interworx/bin/httpd/apxs
chmod +x /home/interworx/etc/httpd/build/instdso.sh
/home/interworx/bin/httpd/apxs -c mod_frontpage.c mod_fpcgid.
/home/interworx/bin/httpd/apxs -i -a -n frontpage ./mod_frontpage.la
apachectl restart
chmod -x /home/interworx/bin/httpd/apxs
chmod -x /home/interworx/etc/httpd/build/instdso.sh

The above steps properly build the module and install it.

  1. Add the following to /etc/httpd/conf/httpd.conf (at the end of the file)

Include srm.conf
Include access.conf

As far as I can tell, it doesn’t actually use these files, but checks for them; so you may only need to create them, not include them in the apache configuration. After configuring a test domain all the way to making front page log in to it, these files are EMPTY.

  1. Create the main “admin” web:

cd /usr/local/frontpage/version5.0/bin
./owsadm.exe -o setadminport -p <PORT> -s /etc/httpd/conf/httpd.conf
-username <USERNAME> -PW <PASSWORD> -t apache-2.0

A side thought would be to modify the configuration this puts in httpd.conf to lock it down to a specific domain, and restrict access to administrative personell only, since the admin program is SUID root.

  1. Take a hatchet to some files that aren’t in the right places:

cd /usr/local/frontpage/version5.0
cp -R admin/1033 admin-exes/_vti_bin/_vti_adm/
cp admin-exes/_vti_bin/images/* admin-exes/_vti_bin/

not all of the images are required, but it’s easier to copy them all

#now copy the help:
mkdir -p /usr/local/frontpage/version5.0/admin-exes/_vti_bin/_vti_adm/help/1033/publish
cp -R /usr/local/frontpage/version5.0/help/1033/* /usr/local/frontpage/version5.0/admin-exes/_vti_bin/_vti_adm/help/1033/publish/

Watch your apache error log for other missing files, they exist in odd places and need pushed around a bit. Note: while reviewing this post before submitting the final version, late at night, I think I might have missed a step or two here.

I’m not sure why all the butchering is needed on the files - maybe it’s because I made a mis-step or missed something earlier in the process.

Anyways, at this point if you’re lucky you can go to the admin web, and click on “extend a virtual server”, but this is where it starts getting really tricky.

The software looks in the config file you specify for ServerRoot and/or Port (which are in /etc/httpd/conf/httpd.conf) and the VirtualHost directives configuring the domain you put in for “Host Name” - which are in seperate files under Interworx. In my opinion the seperation Interworx makes is the proper way of doing this. I don’t know why the RTR people were so short sighted as to write the software this way, but we have to use what they gave us (and it doesn’t look like they’ll be fixing it with the EOL notices).

I don’t know what a permenant solution is, but I short-circuited it by copying the configuration for a test domain from its’ dedicated conf file into the main httpd.conf file (and renaming the domains’ .conf to .bak). At this point, fpadmcgi.exe would ‘extend’ the web.

However, if I click on administration for the web, it 500’s out… because it doesn’t actually copy any of the frontpage files over. With more butchering:

cd /usr/local/frontpage/version5.0
cp -fR exes/_vti_bin/* /home/<domain>/public_html/_vti_bin/
cp -R admin/1033 /home/<domain>/public_html/_vti_bin/_vti_adm/
cp -R admin-exes/_vti_bin/images/* /home/<domain>/public_html/_vti_bin/
chown -R <user>:<group> /home/<domain>/public_html/_vti_bin/

additionally, I had to edit /etc/http/conf/httpd.conf, in the <VirtualDomain> section of the test domain and change AllowOverride to “All” and add “AddHandler cgi-script .exe”. Then, edit /home/<domain>/public_html/_vti_bin/_vti_adm/.htaccess and change “Options None” to “Options ExecCGI”

At this point, I was able to log in to the domain level administration link (yay!), however I could /not/ open the web with front page (boo!).

I checked the log file. It looks like all of the .htaccess files that frontpage creates need the “Options None” set to “Options ExecCGI”:

_vti_bin/.htaccess
_vti_bin/_vti_adm/.htaccess
_vti_bin/_vti_aut/.htaccess

At this point, I can now log in to the site with Microsoft Frontpage 2003, however I have yet to do any extensive testing and/or debugging.

This is also not an optimal solution for a couple of reasons:

  1. so much hatchet work to make it happen
  2. it requires the .conf file for the domain to be merged with the httpd.conf file. I do not know the ramifications this may have on Interworx.

If an Interworx staff member could give me some feedback on #2 I would appreciate it very much :slight_smile:

2

Sorry this is so messy, but it’s late and I’m tired :slight_smile: . I’m going to have to re-do this whole process again on another server (very) soon, so I will be able to go over my own instructions making changes and additional notes; as well as clean it up into a better format.

The main thing that needs to be addressed with this solution is the apache configuration files. I really think that it will end up being a problem.

3

First problem, found

I already found a problem.

I tried to create a subweb. It has exactly the same problem as the initial creation: the files aren’t copied over. By following the same process as above, the subweb becomes functional. The behaviour is identical in the web admin as well as from the frontpage 2003 client.

4

Second Problem:

On-Line help in the web admin 404’s. I’m sure it’s more files to move around, I’ll figure it out later since it’s just the help (not functionality).

Edit: fixed -

mkdir -p /usr/local/frontpage/version5.0/admin-exes/_vti_bin/_vti_adm/help/1033/publish
cp -R /usr/local/frontpage/version5.0/help/1033/* /usr/local/frontpage/version5.0/admin-exes/_vti_bin/_vti_adm/help/1033/publish/

I also added this to the main posting above.

5

Third Problem:

I invited myself to the web, seems to have worked; but if I click on the “Click here to change your password” link in the email, it 404’s.

Partially Fixed:

cd /home/<domain>/public_html/_vti_bin
cp _vti_adm/1033/passwd.htm .
cp _vti_adm/1033/webadmin.css .
cp bluedot.giv …/images
cp _vti_aut/author.exe .

Head -> Wall

At this point, author.exe gets a premature end of script headers error I don’t know how to solve.

Sidenote: It really seems like all these problems are just path errors and fairly simple propgramming bugs in RTR’s software…

6

Sidenote: It really seems like all these problems are just path errors and fairly simple propgramming bugs in RTR’s software…

I couldn’t agreee more. Their system is far from ideal which just adds irritation to anyone trying to get it to work :(.

Thank you as well for posting your progress.

Chris

7

Yes, their software is quite frustrating. It always has been… Even on windows servers!

From my point of view, I’ve got the software in a useful state with the instructions above. The password changer thing doesn’t work, but that’s a minor problem from my point of view.

8

The solution above removes the /etc/httpd/conf.d/<domain>.conf file and puts the directives from that file in to /etc/httpd/conf/httpd.conf

Any throughs from the Interworx staff what having the configuration for the virtual domain moved to httpd.conf will do to Nodeworx/siteworx? I haven’t ventured that far yet, I will probably monkey with it tonight.

Obviously that would be a problem if Nodeworx or Siteworx goes to look for the <domain>.conf file :slight_smile:

9

Obviously that would be a problem if Nodeworx or Siteworx goes to look for the <domain>.conf file

Indeed it will. RTR’s software can’t handle the broken up .conf files so our original plan for FP was simple to write a wrapper to do the work of the RTR FP install script but edit the .conf files directly.

If you get the system working by hand-editing the .conf files then it’s pretty easy for us to add this to the system itself so no main httpd.conf editing is needed.

We’re trying to keep everything in separate files for ease of (well, there’s too much to list) :).

Chris

10

I’ll mess with it. The interesting part is that there’s only a slight modification to the .conf file (and that has to be made by hand, the frontpage installer doesn’t do it), the stupid thing is that RTR’s software looks for “ServerRoot” and “Port” when I think it probably doesn’t need to, thus forcing things. I wonder what would happen if I put those in to the .conf file for the domain, but commented out …

I understand keeping everything in seperate files - that’s the /proper/ way to do it in my opinion.

I’m going to try to figure out the following:

  1. Some way to work around the .conf issue
  2. any way possible to edit the system so that not so much stuff has to be moved around by hand.

Here’s what I’m thinking though: If I can figure out how to get around the .conf issue, a script could be concocted to do the rest behind the scenes, the trick will just be getting the frontpage administrator kajigger to fire the script.

11

Here’s what I’m thinking though: If I can figure out how to get around the .conf issue, a script could be concocted to do the rest behind the scenes, the trick will just be getting the frontpage administrator kajigger to fire the script.

All the FP bin scripts are doing is editing files so we can replace them entirely if you figure out what changes when you add or remove a web using them. Ideally when we get this into the software we won’t need their bins at all, simply mod_frontpage and the fpexec if that’s still used for the 2.x series of Apache.

Chris

12

I have read this thread with both interest and Horror! I agree FP is nothing but a Pain in the the “you know what”! But like nbright says customers want to use that stuff and like nbright says again the customer is correct.

I have a interworx server now mainly for my own sites and a couple others, none use FrontPage. But beginning the first of 2006 I was planning to go with nothing but InterWorx Control panels (Current Use Ensim, still a pain but for most part FrontPage seems to work ok on Ensim).

Now you have me thinking a thought form long ago, If I want to offer FrontPage Extensions if I shouldnt do it with a Windows server.

Chris any thoughts on this as to FrontPage and InterWorx in the near future? In the next couple of months I really need to make a decision.

EDITED to say: I dont want to take this thread off topic, I guess I was thinking out load.

Thanks for any feedback

13

Chris any thoughts on this as to FrontPage and InterWorx in the near future? In the next couple of months I really need to make a decision.

We’ll sure be looking into it r-n-r and will make a decision soon.

Chris

14

Hi all

Well Nbright, did you find a final “acceptable” solution ?

no news for a long time… Just wondering what is the state of your tests now

Pascal

15

Unfortunately I haven’t had much time to work on this through the fall and holiday season. It seems like every time I get going on it, there is a different set of errors.

I think that going for Front Page version 4.0 support being built in to iworx might be much easier, but alas, I do not have a V4 package for linux!

16

thanks for your return. It was just to have news :slight_smile:

17

FPSE 2002 may have a silver lining after all…

It turns out that Ready-To-Run software isn’t completely at fault here… Apache has issues (SuExec) that are anti-FP friendly!

First, copying over the _vit_xxx directories are not a good idea as this will give the user access to binaries which have apache/root access and thus if replaced with a hacked CGI and/or EXE this leads to security issues. This isn’t R2R’s doing - it’s Magic! Replace the httpd.conf entry for the MagicMimeFile chroot to /dev/null and the problem goes away for that.

Secondly, I do not yet have sources for the SuExec replacement (sorry!) nor have I created a fix for R2R’s source, but there’s two things that need to be done to make FPSE compliant…

  1. The mod_fpcgi.c file has a string problem (currently it’s set to szBuf[10] which allows a string for up to ten characters) which isn’t enough - resetting this to [12] takes care of the 500 error - or at least the first step of it.
  2. The SuExec module has a problem within it that I have not tracked down as of yet in relation to ownership and/or account privies… SuExec is running as ROOT while FPSE is expecting to run as APACHE (see your suexec.log file if #1 doesn’t fix your 500 errors.) If you see an error indicating front page is running as root, SuExec has to be fixed. (I downloaded a replacement SuExec RPM from the Plesk web site and it fixed the problem - however I do not yet know WHAT it is they did to it.)

Complete steps for installing FPSE:

  1. Install Apache, MySQL, etc. and test your installation
  2. Update the AllowOverride settings for the DOC PATH in httpd.conf to all AND replace the Magic Mime chroot to /dev/null (this prevents MIME from causing permission problems that breaks the files/images from working correctly.)
  3. Download FPSE 2002 - Extract the tar file and edit apache2/mod_fpcgid.c replacing szBuf[10] with szBuf[12] and re-create the tar.gz file
  4. Proceed with the installation script and create everything UP TO virtual (I just prefer to have FPAdmin install the Virtual Servers)
  5. Download the SuExec replacement and install
  6. Create the Admin user account (or use an existing account) and set up the admin port with owsadm.exe (this creates the httpd.conf entry for <port> and also creates the admin-exes directory under front page.
  7. Restart apache - log into FPSE - test and enjoy.

For Red Hat I’m creating an automation script to do all of this for us however this forum has helped point me in a couple of the needed directions in order to track down the flaws we’ve been experiencing for the past two weeks and as such this is my little donation back saying thanks. I can’t promise this will work for EVERYONE and on EVERY OS but it should hopefully help. Hopefully R2R reads this as well and updates their tiny issue with the buffer (mainly seen with GCC4 since it’s much more strict on buffer overruns) and it DOES apply to the R2R download available today; so hopefully it’s updated on their site as well.

If anyone DOES track down the SuExec issue please enlighten us (the system WORKS for now so it’ll be a lower priority for us, but it would truly be nice to have ALL of the pieces of this puzzle figured out before Apache comes out with another overhaul release!!! :stuck_out_tongue: ) Thanks to nbright and the others listed here for all of their help! (I’m not an InterWorx customer, sorry to say.)

Warmest regards and a WONDERFUL New Year to all of you!

T.J. Rode - President
American Networks, Assoc.
CentralWare, Inc.

18

Nice, you’ve done a much better job of getting this to work than I’ve been able to. Though I /have/ made it work, it’s a total kluge; your method strikes me as much better as it fixes the actual problems, rather than the symptoms :wink:

I hope that Interworx can use your method to integrated frontpage support into Interworx-CP.

Interworx guys: My thoughts on this is that all the features of the front-page web admin jigger, should be rolled into nodeworx/siteworx as appropriate… but It would probably be easier to just put links to the frontpage web-admin for initial versions.

Whatever gets support fastest, is my vote. I’m just waiting for frontpage support so I can grab another license for a server - I have to have it. Not optional. No frontpage, no Interworx.

19

FPSE 5 Update

I’ve sent a request to the makers of Plesk/Virtuozzo asking them if they’ll “share the wealth” in regards to the SuExec file - however I HAVE the RPM (binary) in case you want to experiment using it (under RH/FC it works splendidly and the pair work even better if you’re running RH or Fedora.)

http - www <dot> americonnex <dot> net / dl /
They’ll be online for the next few days - then to prevent ‘issues’ the DL directory will be removed before everyone and their brother are hammering here on the test machine.

Minor update to the installation method - I created a shell script that does the entire job (based on the URL above) and here’s all I’m doing…

  1. Remove any possible existing RPMs related to FPSE or the SuExec patch.
  2. Create the “default” (DocumentRoot) directory under /home/vhosts/default/public_html
  3. Create a generic “all-purpose” httpd.conf (taking out the masses of notes, tips, etc.) and specific to our layout prior to any domains going in.
  4. Install FPSE 5.0 (either via compile or RPM - the package is quicker and easier for me thus it’ll do the job! :slight_smile:
  5. Install the SuExec patch (RPM also) or basically all that’s needed is to replace the existing SuExec (/sbin) after creating a backup copy.
  6. Create the Admin Port (can’t just be added to httpd.conf - otherwise permissions are wrong) using the standard methods from RTR.
  7. Update httpd.conf (unless you use a generic version like I created already including the Override All updates) changing only those related to Document Root (you may also want to enable the default cgi-bin however FPSE doesn’t need it and there’s only a few rare occasions where FPSE users have any CLUE as to how to use FTP :wink:
  8. Restart httpd and log into yourdomain.com:<port> (default 8090) - if failed - check to make sure you punched a hole into ipTables (or other firewall) for the <port> you specified when creating the Admin Port. If the system answers, check images - if they’re missing, MIMEMagicFile must be changed/checked - by default the RPM disables the magic module however there’s a simple bypass if magic is needed for some reason just by setting its chroot to /dev/null and chmod to 755.

Generally, two apache .conf files are needed and missing for FPSE to work (as you noted) - just ‘touch’ the files and leave all else alone (prevents configuration issues since FPSE DOES NOT follow Apache includes.) If images are still not functioning, be sure to set the fp config file to indicate followsymlinks:1 near the end of the file and if necessary, depending on the OS, you may want to create aliases to the admin-exes/_vti_bin directory (pointing it as /_vti_bin = /usr/local/frontpage/version5.0/admin-exes/_vti_bin) and set the directory privies accordingly along with setting the index file to point to the fpadmin.exe)

Hopefully this helps! Keep your fingers crossed that the boys at Plesk will play nice and offer us all a tip on what may be a permanent solution!

Best regards and a wonderful New Year!

T.J. Rode - President
American Networks, Assoc.
CentralWare, Inc.

20

Hi all

A big thanks to CWC/nbright that have done a great job !

Is this solution is interworx compatible and may work with existing Apache/mysql interworx instal ?

Pascal