Problem Publishing To New Server

[Craig Walsh]

We have been running Actinic for several years on a shared web host. As we have a dedicated Linux server (with 24/7 live support) already, I thought I could save a few pounds by moving our e-commerce store over to our dedicated server.

First we established a test site on the new server, using an IP numeric address. We had some problems getting the Actinic site to publish correctly on the new server, but finally managed to get it working. The test e-commerce site (using the IP address) worked fine: we even placed a couple of test orders.

Feeling confident we then discontinued our shared hosting, and changed the name servers over. We got rid of the IP numeric address, and thing should have been fine. But they're not. We now can't republish the site on the new server. And the site works but only up to a point: the shopping cart doesn't seem to function.

The website is at www.luciesfarm.co.uk

I have asked the server support personnel to assist me. They have tried pretty much everything without success. Here's what they say -- and what the error logs show:

To recap what I was able to fix for you -- the 500 error that was being displayed on the site was caused by the scripts trying to include other files in the same directory. The location that Perl was looking for files to include (known as @INC) did not specify the directory your sites were in. I added the path to the cgi-bin directory to @INC with directives in your Apache configuration.

One thing you might want to mention when you contact Actinic about this is that it looks like their script tries to include the local directory with "." -- this may need to be changed to "./"

After that was fixed, the site was (as far as I can tell) working properly. However, you are still having difficulty publishing the files to the site. The errors in the server logs when you try to merge are as follows:

[Wed Jan 31 18:44:57 2007] [error] [client 81.168.115.231] Can't open perl script "\r": No such file or directory.
[Wed Jan 31 18:44:57 2007] [error] [client 81.168.115.231] Use -S to search $PATH for it.
[Wed Jan 31 18:44:57 2007] [error] [client 81.168.115.231] Premature end of script headers: nq000001.pl [Wed Jan 31 18:45:13 2007] [error] [client 81.168.115.231] Can't open perl script "\r": No such file or directory.
[Wed Jan 31 18:45:13 2007] [error] [client 81.168.115.231] Use -S to search $PATH for it.
[Wed Jan 31 18:45:13 2007] [error] [client 81.168.115.231] Premature end of script headers: md000001.pl [Wed Jan 31 18:45:18 2007] [error] [client 81.168.115.231] Can't open perl script "\r": No such file or directory.
[Wed Jan 31 18:45:18 2007] [error] [client 81.168.115.231] Use -S to search $PATH for it.
[Wed Jan 31 18:45:18 2007] [error] [client 81.168.115.231] Premature end of script headers: nq000001.pl

This is over my head, I'm afraid.

Does anyone know what this means? Can anyone help me try to fix this?

Our dedicated server is managed by our hosting company, so I just need to tell them what needs to be fixed and they will (hopefully) fix it. They aren't familiar with Actinic, and keep wanting me to tell them what error messages I receive when I try to publish with Actinic. But all I get is a box telling me the files didn't merge.

In moving to the new server, I created all the scripts, generated the website, and then published it. I did not simply use the up-button.

Any assistance would be most appreciated. Thanks!

[RuralWeb]

Compact your database and then try a purge and refresh. If that fails show us your network settings.

[jont]

In moving to the new server, I created all the scripts, generated the website, and then published it. I did not simply use the up-button.

Have you tried the simple upload button?

If all your network settings are correct and pointing to the correct paths on the new server this is the best way to go. Generating locally was meant for backwards compatibility and not the best option for creating the site I believe.

[Craig Walsh]

Problems Uploading to New Server

Thank you for your help.

There was a problem compacting the database
C:\PROGRA~\Actinic v7\Sites\Site1\ActinicCatalog.mdb
with the database
C:\PROGRA~\Actinic v7\Sites\Site1\tempActinicCatalog.mdb
The reported error was: Driver's ConfigDSN, ConfigDriver, or ConfigTranslator failed.
Please use Explorer to investigate the problem.
Actinic will now close and must be restarted.

Ohmygosh!

How do I use Explorer to "investigate the problem?"

Actinic v7 has been working fine (as best I can tell) on my computer. I have had no problem publishing changes to our website --- which we do every week or two --- and no problems downloading orders from our server. The problems that have occurred in the past couple of days have related to publishing our e-commerce site on our new dedicated Linux server.

Have you tried the simple upload button?

Yes, about a dozen times. We've removed all the files from the server, re-published, etc. We've tried everything we can think of.

When we try to publish, we get the error message:

An error occurred while sending the merge request.

From another posting on this forum, I gather that this is the point that the PERL script is activated. From the server error logs, the gurus at our serving company have advised me that the PERL script is trying to open PERL script "\r" --- which they tell me isn't a script at all, but simply a carriage return. The hosting folks seem to think this is a problem with the PERL script, but (of course) this script worked just fine on our previous server --- up until a few days ago.

I only have a vague, and probably largely wrong, idea of what a PERL script is. Any suggestions on what to do next please?

Once again, thank you for your assistance. I appreciate it very much.

[clefty]

There was a problem compacting the database
C:\PROGRA~\Actinic v7\Sites\Site1\ActinicCatalog.mdb
with the database
C:\PROGRA~\Actinic v7\Sites\Site1\tempActinicCatalog.mdb
The reported error was: Driver's ConfigDSN, ConfigDriver, or ConfigTranslator failed.
Please use Explorer to investigate the problem.
Actinic will now close and must be restarted.

Craig,

When you re-open Actinic and repeat the compact process, does this error repeat itself?

Chris

[Craig Walsh]

Sadly, Yes . . .

When you re-open Actinic and repeat the compact process, does this error repeat itself?

Sadly, yes. I tried this several times. Even re-booted my computer for good measure, just-in-case. Same error message each time, I'm afraid.

[clefty]

It looks like you may have a corruption in your MDAC, a Microsoft component of Windows that allows applications to connect to MS databases. The Actinic program uses this to connect to the Access database it uses.

Firstly, export a full snapshot somewhere safe.

If you're running XP with SP2, you can force a reinstallation of the MDAC component:

Locate the mdac.inf file in c:\windows\inf right click and choose install
When prompted for a location goto c:\windows\servicepackfiles\i386 then when promtped for the XP cd, load the CD

This reinstalls / repairs MDAC 2.8

If you're using a version of XP prior to SP2, you can download MDAC from MS's website. You can't (apparently) use this version however on SP2, hence the method above.

If this fails, you'll need to reinstall Actinic to the current version you're using and reimport your snapshot

I had a similar problem with my MDAC and the repair did the trick.

Please make sure you a have a full backup before trying this!

HTH

[Craig Walsh]

I've Tried Everything . . But What Will Fix This...

Thanks, Chris, for your suggestions. My evening's homework!

Firstly, export a full snapshot somewhere safe.

Done, to an external hard drive and to my internal hard drive.

If you're using a version of XP prior to SP2, you can download MDAC from MS's website. You can't (apparently) use this version however on SP2, hence the method above.

Drat! I am using XP SP2. And could I find a CD-ROM for SP2? Could I heck! All I could find were a half-dozen original XP CD-ROM's. As I recall, we upgraded XP by downloading the two service packs.

I followed your instructions: when I got to the bit about inserting my CD-ROM I tried the ones I have. All of them. Even an OEM CD-ROM for my newest computer. But none of them worked.

I downloaded MDAC 2.8 from the Microsoft website, but, as you said, it didn't work. The error message told me that MDAC 2.8 is not needed with SP2 because the components are already part of the SP2 package.

If this fails, you'll need to reinstall Actinic to the current version you're using and reimport your snapshot

I uninstalled Actinic, re-booted. Did a fresh install from the Actinic CD-ROM and imported my snapshot. Took a deep breath and tried (first) to compress the database. The same error message as before. Tried to publish the website. The same error message as before.

Then I thought, "Why not install Actinic on your new computer?" I've had a new PC for about five months now --- dual this, faster that --- but I haven't installed Actinic on my new computer. I sit here with my KVM switch using the old Dell and the new one. (I fractured my back last May and still haven't recovered, so can only do short stints at the computer at any one time.)

Anyway, I did a fresh Actinic install on my new computer (also running XP SP2) tonight. Imported the site snapshot. Admired at how much faster Actinic works on my new computer. And, presto, I was able to compact the database in a flash.

So with my fingers and toes crossed I tried to re-publish the site to the new server. No joy. Exactly the same "merge" error message at exactly the same place.

I think, therefore, we can safely conclude that the inability of my "old" computer to compact the Actinic database and/or problems with my MDAC 2.8 are not the cause of my publishing problems.

I tried the Generate Scripts > Generate Website > Send Files approach, and I tried the simple up-arrow approach. Unfortunately, both bombed out.

I still wonder if there's not a problem on the server itself --- but our support folks have combed the thing and they say the PERL script is wrong. And they point to the error logs at the top of this thread.

Any other suggestions?

[wjcampbe]

What error messages do you get when you click the Test button in Advanced | Network Settings?

Can you publish those settings here [after removing IDs and Passwords]

Has the amount of memory and time allocated for perl scripts to run on the server been eliminated as a probable cause?

[Craig Walsh]

Error Messages and More Error Messages

What error messages do you get when you click the Test button in Advanced | Network Settings

I am running Actinic v7 --- the "test" button seems to be in Network Setup.

When I run the test, I get this message:

The test script failed to execute on the web server. The error could be caused by several things. Check the path to the Perl shell, the CGI script extension, the path to CGI-BIN, and the CGI-BIN URL. This error could also occur if your web site is out of disk space or your web server is not configured to accept POSTs to CGI scripts.

I have been assured by our hosting company that they have checked, and double-checked, issues of memory and time allocation, and that all is well.

I renewed my Actinic Cover and spoke with Actinic this morning. They uploaded a "hello world" script into our cgi-bin, and couldn't get this to run. I made another call to our hosting company, and the PERL guru is expected in within the hour. I've asked them to please get the "hello world" script to work, and the hope is that the e-commerce site will follow thereafter.

Fingers crossed . . .

[Craig Walsh]

Solved By Our Hosting Company -- Finally

The non-functioning "hello world" script (see my earlier posting) gave me the needed ammunition to go back to my hosting company. They looked at this script, and said that it had code on the second line of the script --- and that the second line should be blank. When they fixed it, the "hello world" script worked perfectly. When they removed the second line of all the Actinic PERL scripts (I think there are 17) our website worked just fine.

This certainly seemed a weird solution. Surely other Actinic customers publish their websites without having to remove the second line from 17 scripts. I called Actinic back and was told this was not a known problem, and that I should consider a change of hosting companies.

In the meantime (I was starting to get a little peeved, and hence became more than a little persistent) I received this e-mail from HostMySite:

I discussed this with a fellow Dedicated Server / Escalation Engineer, and we concluded that it's not really the blank line that's needed after the first line that I used to believe it was - the reason why the Perl scripts keep breaking is due to extra Windows-based characters that are added to the script.

I knew of this Perl Windows-to-Linux issue before, but didn't realize that instead of adding a blank line which I normally do, all you need to do is open the file in a Linux text editor and save the file. It will then work. I've done some tests on my own Linux site hosted here, and found this to be the case. An alternate fix for this is to run a command called "dos2unix" on the Perl scripts. This program removes the Windows characters from a Perl scripts, allowing it to work properly on Linux.

Normally the fix for this is to start using an editor that doesn't add the extra Windows characters (i.e. don't use Notepad, Wordpad, Word, etc.). There are many free text editors (e.g. UltraEdit) available that don't add these characters, and thus won't create issues when you upload the files to a Linux server.

In your case, however, I assume in order for you to make changes to your store, you login to an admin interface. Then you make changes, and publish your store, which uploads the updated Perl scripts to your site. So you don't really have a choice to use a different text editor.

In this case, what we can do setup a scheduled task to run the dos2unix program on all of your Perl scripts in the cgi-bin folder. We can set this to run once a minute. I'm really not sure what else can be done to remove these characters before you publish it to your site. I saw that Actinic says their software is supported on either Windows or Linux. I would definitely tell them about this issue - I would think they would have a fix for this from within their program, so you can publish to a Linux server. I know you've contacted them several times already, but this is a known issue which they *should* be able to work around.

Please feel free to call back and ask for me if any of this is unclear, which very may well be! Thank you and have a great day.

After another telephone call to HostMySite I learned that this is a reasonably common problem when editing scripts on a Windows computer --- and then publishing them to a Linux server.

I use Actinic v7 on a Windows XP computer, so I suppose the internal script editor within Actinic --- if there is such a thing --- is adding the extra characters. I am guessing that our previous shared hosting arrangement, with another company, may have been on a Windows server.

When I did a "Refresh Website" from within Actinic it published new script files to our Linux server. Because these script files were created on a Windows-based computer (my desktop computer) they had these extra Windows characters. And Linux gets confused by these characters.

Once our server company ran the dos2unix script on our cgi-bin, everything worked perfectly. When I use the simple up arrow in Actinic to publish incremental changes, it does not appear that the scripts are updated (at least not yet). So it's not necessary to run the dos2unix script every time I publish a change to our e-commerce website.

I received this follow-up message from HostMySite:

I'm glad we seem to have figured out the issue that causes your store to break. As I mentioned, if you ever do a "full publish" in the future and it breaks your store, just email or call us and reference this ticket:

T3*****

Tell us to run the command documented as a note on the ticket to fix the store's Perl scripts. Also, if your store breaks after an "incremental publish", make note of what changes you made to the store that caused the incremental publish to overwrite any of the Perl scripts. We'll make a note of that in this ticket so we can see if the same functions seem to overwrite certain Perl files using the incremental publish.

Again I apologize for the time it's taken to get this issue resolved and I completely understand your frustration with us. Hopefully doing incremental publishes won't overwrite any of the Perl scripts, and we won't run into this issue again. Thank you and have a great day!

I'll raise this with Actinic early next week.

Surely it should be possible to add some form of the dos2unix script when publishing a website? Why not ask, as part of the Network Configuration routine in Actinic, "Do you have a Linux server?"

Anybody out there use a Windows computer to publish an Actinic website to a Linux web server? Just curious . . . .

[wjcampbe]

Anybody out there use a Windows computer to publish an Actinic website to a Linux web server?

Myself and something like 90% of the installed user base I warrant.

If you have been editing the scripts with Word or some other non-text based editor, these could (and probably did) add extra garbage into the file(s). If you use a basic text editor [nothing wrong with Notepad in this respect], then nothing gets added.

[clefty]

Anybody out there use a Windows computer to publish an Actinic website to a Linux web server? Just curious . . . .

Craig,

This will be the vast majority of Actinic users - we all run Actinic on Windows and I suspect most of us upload to a *nix server.

I renewed my Actinic Cover and spoke with Actinic this morning. They uploaded a "hello world" script into our cgi-bin, and couldn't get this to run

How come Actinic's "hello world" test script broke, completely independently of your system? This would lead me to suspect a problem with the mode used to upload the pl scripts - they should be uploaded in ascii mode (the end of line translations from win -> unix will get done).

Uploading pl in binary mode will cause errors.

As Actinic's upload and a manual upload via FTP are both failing, a configuration with the FTP daemon on the server would seem more likely than a Windows issue.

As far as I'm aware, Actinic will autodetect the pl extension and upload in ascii (as will most ftp clients)

I think you'll be hard pushed to find any other users having a host running a cron job to "tidy up" Actinic's perl scripts. This all seems very strange .....

[Craig Walsh]

If you have been editing the scripts with Word or some other non-text based editor

I haven't been editing the scripts at all. I wouldn't know how to find them to edit them, and wouldn't know what to do with them if I did.

All publishing has been from Actinic itself.

The "hello world" script was uploaded by Actinic staff.

a configuration with the FTP daemon on the server would seem more likely than a Windows issue

Ah ha! Please tell me more. Is this something that our hosting company can check, and, if necessary, amend?

We run about a dozen other websites on the same server --- content management sites (using Article Manager software), forums, a couple of blogs, online photo galleries (using Coppermine), and even a bespoke site or two. We don't have this problem with dos2unix anywhere else, so this all does seem, as you say, "very strange."

[RuralWeb]

Anybody out there use a Windows computer to publish an Actinic website to a Linux web server? Just curious

100% of my websites are published this was and I never have problems - I would take a hard look at your host and stop playing with the scripts.