CGI Space changes ...

[#1]

Sorry about this but I am experiencing a complete mental block following these domain redirect instructions.
my plusnet domain is sunwheel.force9.co.uk.
I have a domain, jacksrake.co.uk, hosted by 1and 1 which is currently pointed to: ccgi.sunwheel.f9.co.uk
I have, since the migration [I think!] made changes (mostly changes to pictures) to the website which appeared to show up properly but now it appears to have reverted to the old version.
Could some kind soul please tell me exactly what I need to change at 1and1?
"Do this as follows:

www CNAME <your_domain>.

<your_domain> A 91.136.8.9"  Makes no sense to me.  Sorry if I'm a bit thick!

[#2]

Based on my interpretation of current DNS records I think jacksrake.co.uk and www.jacksrake.co.uk point to what I assume is shared space on a 1&1 server. Do you have a .htaccess access file there that redirects to ccgi.sunwheel.force9.co.uk?
The images displayed on the site and all the links appear to reference ccgi.sunwheel.force9.co.uk and clicking on the Home menu item probably displays the page from that server.
Is the problem that what shows initially is the page on the 1&1 server?
David
Edit: Looking at the page source shows a Frameset redirect is being used. I would expect this to continue working with the new server.

[#3]

Thanks for your input David.
My previous post was made at work where I first noticed the website seemed to have reverted to the previous version.
I'm now at home and have checked the uploaded files and the they are indeed the files of the previous vesion.  I have started to re-upload the new version and all seems well so, clearly nothing needed changing at my domain host. 
I'm still at a loss to explain why the new files have disappeared to be replaced by the old ones.  I uploaded the update, via the new control panel, around three weeks ago, after receiving my migration confirmation email.  Everything worked at the time and I only noticed today that the old version of the website was loading ... even though I had deleted the old files.  Is it possible plusnet have restored some sort of backup?
jim:quote

[#4]

Quote from: sunwheel

I'm still at a loss to explain why the new files have disappeared to be replaced by the old ones.  I uploaded the update, via the new control panel, around three weeks ago, after receiving my migration confirmation email.  … Is it possible plusnet have restored some sort of backup?

Three weeks ago could be the key here.
Over the weekend 28/02-03/03/2014 Hostopia mounted week old versions of our file systems. This was corrected on the Monday afternoon but as a consequence any changes made over that weekend were lost. Unfortunately if  your changes were made that weekend you will have been affected.

[#5]

Yep, I suspect David's right here. If you uploaded the new content over that weekend then (at no fault of your own) you'll have been writing to the wrong storage devices. When we corrected the error the following Monday things would have reverted to how they were before the weekend in question.

[#6]

David & Bob,
Aha!  It all makes sense now; it will have been that weekend.
No worries, I have uploaded all the new stuff again and all is fine now.
Thanks, as usual, for the speedy and useful input.
Cheers!
Mark.

[#7]

I have a few old bits and bobs in my CGI space and have just tried to tackle getting the first to work, an old counter script. Getting that working might provide clues for getting my other stuff sorted out. It's only a simple .pl file but I'm not having any luck with it. I've copied it from my /public/CGI-BIN/foldername/counter folder into /cgi-bin/foldername/counter. The .pl file is found hence at /cgi-bin/foldername/counter/gcounter.pl
It requires two lines, $basedir/ and $baseurl to be edited. Under the old setup, I had this configured as follows:

$basedir = "/files/home1/username/cgi-bin/foldername/counter";
$baseurl = "http://ccgi.username.plus.com/cgi-bin/foldername/counter";

I've tried all sorts of variations, including the path on hostedc50.megawebservers.eu to /services/webpages/c/c/ccgi.username.plus.com, but nothing makes the counter work. I would have thought that it's only the former of these two lines that needs changing. But to what?
This file is referenced by an HTML file in my homepages webspace, via lines such as

<img src="http://ccgi.username.plus.com/cgi-bin/foldername/counter/gcounter.pl?countername&amp;d&amp;0&amp;5">

[#8]

It seems to me that the presence of /public/CGI-BIN is just causing confusion and things would be easier to follow if you reverted to /cgi-bin being a proper /cgi-bin with the pseudo /cgi-bin at /public/CGI-BIN not used. In fact that seems to be what you are trying to do, but probably without making the key change described in the next paragraph.
The key change is to find the /.htaccess in your root directory and disable it by renaming it (eg add something before the leading '.') or deleting it. This will stop web/url references to /cgi-bin being redirected to /public/CGI-BIN with the real /cgi-bin being ignored.
Then move any cgi scripts (and associated data/image files) to (folders) within /cgi-bin with .pl and .cgi scripts executable (chmod 700).
To ensure /public/CGI-BIN can't be used I suggest renaming it (or deleting it if empty), along with a possible /public/cgi-bin soft link to /public/CGI-BIN if there is one.
The full path to files in the real /cgi-bin will then be /services/webpages/c/c/ccgi.username.plus.com/cgi-bin/... (whatever)*
and their urls http://ccgi.username.plus.com/cgi-bin/... (whatever)
I think these are what you expect, and they should work once the crucial step of removing /.htaccess is done.
* You might sometimes see /util/ included in the path as in /services/webpages/util/c/c/ (etc). Strictly /util/ shoud be included, but it works without it too.
David

[#9]

Thanks David. It's working now.
I'd had a good look through all of this thread, one or two others, the help page linked in my email and various bits of the PDF docs relating to the new service (the kind of insightful documentation that suggests things like: 'Change Password: Clicking this button provides a function to change your password'), etc., but hadn't seen anywhere that mentioned the 'real' cgi-bin had to be activated by disabling the 'fake' one.
A few other questions whilst I'm here:
I renamed the .htaccess file, but trying to delete it or another directory in my /public folder doesn't work. My FireFTP client merely indicates
'Error message= NS_ERROR_NOT_AVAILABLE:
URL= chrome://fireftp/content/js/remote/remoteTree.js
Line Number= 489'
Is there a complication with deleting CGI files via FTP or is this an issue with my client?
Somebody earlier in this thread mentioned they'd been able to create an extra FTP user in addition to the master, who had permissions to all directories. How? When I tried to do that it would only let me pick one subfolder, and leaving the field blank or adding a / resulted in a 'directory not valid' error. (That Master FTP password really should be at the top of that page with additional restricted users underneath, but there's no point venting my spleen about that here).
The other default subdirectories of 'private' and 'secure' - do they have any particular function / recommended use or are they just there as generic template folders to give users ideas?

[#10]

If renaming a file works one must have write permission to its directory so I would expect deleting the file to work too. That suggests inability to do this is FTP client related. It's a bit more complicated with folders since the folder has to be empty first. This means if it contains files it has to be writeable itself. Can you delete the files/folders using File Manager in Control Panel?
FTP Manager lets me create an additional Directory FTP user with access to /, which should mean all directories (I haven't tried using it). To do this I click the Create button to display additional form fields. Fill in name and password twice on the left, don't click any directories in the list on the right, just type / in the textbox. Finally click the Create button and it does.
This also works with a test account I have access to, though from memory I previously got the "directory not valid" error you mention with that test account. Did you have anything selected/highlighted in the directory list when you tried with just / in the textbox?
The /private directory is used by the system to hold phpMyAdmin configuration files when you "install" (ie initialise/configure) it using the Control Panel tool. There will also be a /public/phpmyadmin link - your choice of name - (in /public of course) which points to the system phpmyadmin directory. Files in /private are not accessible from the Internet (the web root is /public).
I think /secure might be a placeholder for HTTPS access (which we don't have). On my test account /secure is a link to /public and I have a second similarly named directory which is a link to /cgi-bin. I expect the server configuration would use these if we had HTTPS access.
David

[#11]

Well I've just spent the remainder of what might have otherwise been a pleasant weekend banging my head against this infuriating brick wall that the good folks at plusnet have forced me to try and vault over. Attempting to get a couple of my form mailing scripts working again but failing for no obvious reason. This is the Tectite FormMail as recommended to me by PlusNet themselves many years ago when some changes made meant my old form mailing service was no longer any good.
I've updated the forms from my old 8.22 version to the latest 9.06 version available at tectite.com, which now use PHP5 instead of PHP4. Should be no problem, and I've not made any other configuration changes aside from modifying the paths. I've initially picked a form that doesn't rely on any image captchas just to avoid one further stumbling block straight away. The old PHP scripts had been moved automatically into /public/CGI-BIN/path/to/old_scripts.php, but I tried to put my new one in /public/path/to/script.php. Obviously I also updated my HTML form with the new path, but upon submission I get an error:
Not Found
The requested URL /public/path/to/script.php was not found on this server.
In case this was PHP5 related or an issue with the new script, I tried redirecting the HTML form to the old one in /public/CGI-BIN/path/to/script.php. I get the same error. What's going on?
Regarding the other points, I still could not get the additional restricted user to have access to /, so I just deleted the account. And I can delete files from the File Manager in Control Panel that can't be deleted in my client, FireFTP. No idea why, it can delete fine from my www webspace.

[#12]

Since the webroot is /public the URL for your new form should be http://ccgi.username.plus.com/path/to/script.php. The /public component is omitted just as /htdocs is omitted on Homepages. Similarly the old version is at http://ccgi.username.plus.com/CGI-BIN/path/to/script.php.
I've just downloaded formmail.zip from www.tectite.com to take a look at it but got version 8.36. How did you get version 9.06?
David

[#13]

Aha. Thanks for that insight. Yes I'd probably seen somewhere a comment about /public being the root but amidst trying to wrap my head around the whole switching process I'd not considered that. That raises another issue: the PHP script file includes my email address in it, but apparently such files get executed and not read by the user (despite 644 permissions) so it should be safe. But alongside that file I have an .ini file where my email is referenced but by using the 'AT MANGLE' function to mask the full address. The bit that gets replaced is contained in the PHP script. Since I obviously don't want the address revealed to bots or hackers, are both these files safe enough residing at some level within /public with 644 permissions, or is there a better arrangement? I guess the PHP file has to stay where it is, but I don't know if moving the .ini file makes any difference.
As for the script version, I noticed it said the latest version is 8.36 on the FormMail homepage, but when I went to upload and convert an existing one, it offered me either 8.36 or 9.06, with the latter already highlighted by default. There was some reference to the new version being beta but that was seemingly the 9.0 version, not 9.06. I don't know why the new one isn't made more visible unless it's either not fully stable or because they regard dropping PHP4 support as too problematic for the time being.
Edit: pasted appended phrase at semi-nonsensical place.

[#14]

PHP files are read, compiled and executed by the PHP application but only their output (to SYSOUT) is served to browsers. So the contents of .php files should not be exposed.
However depending on their extension included files might be. If their extension is .php their contents should be safe, but if .inc or .ini (say) they might be viewable. It might require guesswork but someone might guess correctly. For example having sensitive information in a file called formmail.ini would probably be pushing your luck. If it was called dlmxxpkvrf.ini it is less likely to be discovered, but that possibility still exists.
You could move included files to subdirectories (preferably not called ./includes) and/or use .htaccess directives to deny direct browser access to all *.ini files, but moving such included files into a folder above the webroot should protect them. Which method to choose depends perhaps on your sense of paranoia.
David

[#15]

After my www.reptonresourcepage.co.uk stopped working (or rather, was reported not working last night), I set about trying to fix it. I've changed the DNS records to what has been suggested in this long thread, but still does not work…I guess I need to wait for the records to propagate. I've got them set to:
reptonresourcepage.co.uk. a 91.136.8.9
www cname ccgi.geraldholdsworth.free-online.co.uk.
Also, I've tried to log into the Control Panel, with the supplied username and password, and am told that it is an Invalid Username or Password! However, I can log into my FTP space, using Firefox FTP, using these credentials fine.