After account transfer (transfer tool), Perl scripts won't run

[swbrains]

After transferring my main domain using the Transfer Tool, I can't run any Perl scripts from the browser on my main domain. I can log into SSH (Putty) and execute a test Perl script on the account successfully (it outputs the expected text), but the same script generates a 500 error from the browser. In the account's error page, it says: [Tue Jan 03 17:29:43.972733 2023] [cgi:error] [pid 1033656] [client xxx.xxx.xxx.xxx:52210] AH01215: (2)No such file or directory: exec of '/home/xxxxxxx/public_html/cgi-bin/testperl.pl' failed: /home/xxxxxx/public_html/cgi-bin/testperl.pl

Currently the domain (example.com) is on the new server, but this domain is also the domain used for the nameservers for all hosted accounts (ns1.example.com and ns2.example.com). It looks like the nameservers still resolve to the old server although the domain's A record points to the new server. Could this be an issue? I still haven't updated the nameservers at the registrar to point to the new server IPs; I'm waiting until all accounts are transferred. Other hosted sites with domains using those nameservers work fine after transfer, as well as hosted sites using subdomains of example.com. The only difference I can think of was this account was transferred to a dedicated IP (unique to this account) and it had "reseller privileges" enabled when setting the transfer options since it is the reseller account.

The other odd thing about this account was that I can't log into its individual cpanel account -- it returns a bad password message. I reset the password for this account while logged in as root and it still won't let me in using that password. Other hosted accounts did retain their password properly after migration and I can log into their individual cpanel accounts properly using their original passwords.

I checked the account's owner/group settings and they are set to itself (its own user id) which is how it was on the old server before migration.

I have also transferred a number of other sites using the transfer tool so far and they can all run scripts successfully from the browser.

I'm stumped. And it's my main website for my business which the other hosted accounts call scripts on as part of their operation. Those script calls to the main domain are failing now, even though other script (that don't call out to the main domain) work fine.

Any help is greatly appreciated...

 

[swbrains]

Ok, so I figured out what was going on, but I don't know why it happens.

On the main domain account, I had done a transfer as usual but then I had updated a bunch of scripts because Perl changed from 5.16 on the old server to 5.26 on the new server and some additional code changes were needed. When I uploaded the modified files to the new server, I logged in using FileZilla as "root" and changed to the domain's cgi-bin dir and uploaded them.

On my local PC, my scripts have CR/LF at the end of every line when I edit them and look at the local copy in hex mode. Uploading to the server using FileZilla while logged in as root seems to keep the CR/LF which causes the Perl interpreter to issue the "no such file or directory" error.

If I then log in to the domain account with FileZilla but as the user id for that account, then uploading the same script from my local PC, the file is somehow translated from CR/LF to just LF, which Perl likes and runs the script properly.

The strange part is, if I log into the account as "root" and just open and view a remote Perl file from the server, it shows up as "UNIX" format in my editor and in hex mode it only has a LF character.

But if I then log into the account as the user id and just open and view a remote Perl file from the server, my editor says "PC" format (CR/LF in hex mode). I can even modify it and re-upload it to the server and it still works, even though the editor shows CR/LFs when I edit it.

Somehow, being logged in as "root" vs. the account's user id changes how the FTP process uploads the file in FileZilla (or so it seems), since I know my local hard drive copy has CR/LF in every file. It seems that FileZilla might be rewriting the CR/LFs during the upload in the case of the user id login, but not in the case of the "root" login. I do have separate saved logins for the user id login vs the root server login. However, all of my login configurations in FZ have the remote server type set to "Default (autodetect)", so that doesn't seem to be an issue.

Since I didn't re-upload any script on the new server for the other hosted accounts I transferred, they ran properly. I only modified the main domain's scripts and re-uploaded them as root, which did not translate the CR/LFs, so only that account had the issue.

What also threw me off was that the scripts executed properly from the shell; just not from the browser.

So my guess is that this is something in my FileZilla configuration but I haven't found out what it could be. I don't know of any server-side transliteration that would occur during uploading of files, so I assume this is an FTP app (FileZilla) thing. I'm curious, though, where the setting is that is doing that translation in some cases...

UPDATE: It looks like my account login in FileZilla uses FTP and the root login used SFTP, so that may be the difference in how the server handles the CRLF translation...

 

[cPRex]

I'm glad you found that issue!