I cannot "publish" using FrontPage

[xivaro]

I enabled FrontPage extensions, but when I hit the "Publish" button, I get this message:

"An error occurred accessing your FrontPage web files. Authors - if authoring against a web server, please contact the webmaster for this server's site. WebMasters - please see the server's system log for more details."

Unfortunately, I don't even know which files contain the above-referenced "system log".

I followed the steps at http://site-helper.com/uploading.html#frontpage, using both "http://www.mydomain.com" and "http://www.mydomain.com/" (with & without the trailing slash) in step 3. I also enabled the option to "publish only changed pages" (and tried it the other way too).

But I don't get to step 4; instead, I get the above message before anything else happens. That is, I never get the opportunity to enter my username and password. Kinda baffling. Seems to be a simple thing, hopefully there's a simple solution.

For now I have "manually" ftp'ed my files into my domain, but even using the publish via ftp option in FrontPage does not work correctly. The files end up in

http://www.mydomain.com:2222/CMD_FILE_MANAGER/

instead of

http://www.mydomain.com:2222/CMD_FILE_MANAGER/domains/mydomain.com/public_html/

Is this a DirectAdmin issue, or is it an issue that needs to be dealt with by my webhosting provider? Thanks for your help.

[DirectAdmin Support]

Hello,

Ask your webhost to check:

/var/log/httpd/suexec_log
/var/log/httpd/fpexec_log

He might need to set apache to run as nobody (instead of apache).

As for FrontPage's FTP feature, You have to specify the base ftp directory:

ftp://www.domain.com/domains/domain.com/public_html

John

[xivaro]

I am using a Compaq Presario 2100US laptop: 1.6MHz Celeron, 256MB RAM, 30GB HD, Windows Home XP, Windows Office 2000 (i.e., FrontPage 2000), and I install all the MS patches and service packs as soon as they are available.

My ISP is Verizon and I have a DSL connection (512kpbs down/128kpbs up).

[xivaro]

Hi John,

Thanks for the reply. One question: what should my webhost be checking for in the logs?

Thanks,

Juan

Originally posted by DirectAdmin Support
Hello,

Ask your webhost to check:

/var/log/httpd/suexec_log
/var/log/httpd/fpexec_log

He might need to set apache to run as nobody (instead of apache).

[DirectAdmin Support]

I'm not sure :) Errors in the logs will generally stand out. Normally it's just permission issues or similar things.

John

[xivaro]

The guy at my webhosting site said that it ain't that easy to change apache's user, so I'll probably just stick with FTP publishing, now that I know how to make it work right.

Thanks for your help!

Juan

[BugLight]

I checked his logs, his unix user has nothing in suexec_log but I have fpexec_log full of:

[2003-10-22 00:31:23]: user mismatch (apache instead of nobody)
...

I read elsewhere that one solution is to run httpd as user nobody. Another solution is to recompile FP to run as user apache. I'd opt for the latter if possible since FP seems to be the only one griping.

Does your new customapache build script support the recompile/build of FP?

[DirectAdmin Support]

Yes, the customapache builds frontpage. It extracts it each time, so you would either have to compile it manually, or add the changes into the script. I'll look into adding it to the script, as it should be set to apache anyway.

John

[DirectAdmin Support]

Hello,

I've changed the script to force frontpage to use "apache".. so if you do
cd /usr/local/directadmin/customapache
./build clean
./build update
./build all

Side note: Actually, doing a repeat ./build all would have fixed the problem, as the "nobody" is retrieved from the stock httpd.conf, which we overwrite *after* mod_frontpage is compiled. So in theory, if you would have just recompiled it, it would have found "apache" in our version of the httpd.conf. Anyway, all new installs should no longer see this.

John

[BugLight]

Thanks for the quick reply. I must be calling at a bad time though...

[root@da12 customapache]# ./build update
--15:18:24-- http://files.directadmin.com/services/customapache/build
=> `/usr/local/directadmin/customapache/build.new'
Resolving files.directadmin.com... done.
Connecting to files.directadmin.com[66.28.214.33]:80... connected.
HTTP request sent, awaiting response...
15:18:25 ERROR -1: No data received.

[root@da12 customapache]# wget http://files.directadmin.com/services/customapache/README
--15:20:19-- http://files.directadmin.com/services/customapache/README
=> `README.1'
Resolving files.directadmin.com... done.
Connecting to files.directadmin.com[66.28.214.33]:80... connected.
HTTP request sent, awaiting response...
15:20:19 ERROR -1: No data received.

[root@da12 customapache]# ll build
-rwxr-xr-x 1 root root 0 Oct 23 15:18 build

[DirectAdmin Support]

Yes, as a rules always restart apache after compiling things. That rules applies to us as well, or apache segfaults :)

John

[BugLight]

Ok I'm a bit confused here.

I did a build clean which I figure just nukes object files (no compiling), and a build update. It was in the build update dialog I got that.

I sorta assumed the update just went out and wget'd the new build script.

End result right now is I have a zero length build script. I could copy one from another DA server but I figure I'll wait to see if you have anything to add first.

Thanks.

[DirectAdmin Support]

Hello,

I meant our files.directadmin.com apache was down for a bit :). You can get/run the new build by running:
cd /usr/local/directadmin/scripts
./customapache.shJohn

[BugLight]

Har...

Okay thanks John.