Site setup- Testing Before Propagation

[D9r]

OK, I apologize in advance, because I know the answer is probably staring me in the face but I didn't see it because I tried to skim through the "Manual" in about 30-60 minutes. In addition, I'm probably posting this question in the wrong place. Oh well, sorry; I'm trying to transfer a site this afternoon and it's my first experience with HostPC so I don't know my around yet. That having been said:

I created a new account for a website (within my reseller account). Obviously it isn't propagated yet. How do I access via FTP to upload and test the site?

I tried:

sitename-
207.44.208.115
207.44.208.115/~admin240/

remote folder-
/var/www/html
/var/www

For user and password, I used what I entered as "User" in the admin panel. I also tried the "Administrators name". I'm assuming the problem is with the sitename and remote folder.

[Joe]

FTP to the IP address of the server, with your username (username@domain.com) - it'll put you in your own "space". you'll want to put all the files in /var/www/html/


From your control panel, under site summary, there's a link to preview the site. This works, but there are some caveats before propogation:

1. CGI won't display
2. MySQL probably won't work
3. Front Page won't work

[D9r]

Thanks Joe. I figured it out a second ago.

After having some coffee and food, I sat and glanced at my notes and saw where I had written "user@domain.com" -- ('Oh yeah, I said to myself. I wrote that there to remind myself to include the "@domain.com" with the username, and I forgot.')

I added the "@domain.com" to the username on my FTP program and *presto* it worked. You must get that question a lot. Thanks for the quick reply.

[D9r]

I have another question I shouldn't ask either, but just figure out by reading and testing; but this topic is already started, so hey, what the heck :wink: :

The site consumes about 11MB on initial setup. How can I prune that down to 0MB or as close to 0MB as possible?

My guesses are:
disable FrontPage and remove those folders
empty out the cgi-bin

How close to 0MB can I get it to be? I'll go test and see. (testing is always more fun than work :) )

[D9r]

Stupid Question #3 -
I can't Chmod? Surely I can.

#3.b
I can't delete anything? Very strange. Have to go read more of the beloved manual.

Maybe I need to logon as the 'admistrator' and not as a 'user'. Ah ha, bet that's it. (Now it's becoming fun. I love mysteries, don't you?)

Edit:
Ooo wow, that was the answer.

[Joe]

:lol: LOL

I love trailing a conversation with a user talking to himself :)

You're fun people Dean :)

[D9r]

How do I make CGI scripts run without being in the cgi-bin? (I'm assuming I can -- I asked back in March and thought I was told I could.)

Here's the site for your viewing pleasure -- all transferred, except that the 4 cgi pages don't work:
http://207.44.208.115/~admin239/

(off to look around the site for the answer)

[Joe]

Look for .htaccess rewrite rules... It's gonna have to be done with .htaccess, but off the top of my head, I can't remember the rule.

Joe

[D9r]

Yeah, that's a file I didn't transfer. I only understand a limited amount of .htaccess, and nothing in there looked important.

I just added that file, and now it displays the entire .cgi as text (before it displayed part of the script and part of the html page). So adding the .htaccess file helped.

Correction: It still displays part of the page (the images) at first; but when you reload the page that's when it shows the entire text copy of the CGI. So I don't know if the .htaccess file or that _vti_pvt directory changed anything. I'll go look for .htaccess info at Apache.org and maybe find the directive there.

Maybe the path to Perl is wrong.
Maybe it needs a weird directory _vti_pvt which I also didn't upload (thought it was for FrontPage, I'm not using FrontPage).

Here's the .htaccess file in the meantime in case it reveals any clues. I probably shouldn't post it for security reasons, but I'll take my chances and delete it later:
# -FrontPage- *~ *#



IndexIgnore .htaccess */.??* */HEADER* */README* */_vti*



<Limit GET POST>

order deny,allow

deny from all

allow from all

</Limit>

<Limit PUT DELETE>

order deny,allow

deny from all

</Limit>

AuthName www.tuckercivic.org

AuthUserFile /www/tuckercivic/_vti_pvt/service.pwd

AuthGroupFile /www/tuckercivic/_vti_pvt/service.grp



Options +MultiViews

[D9r]

I found the following: (at http://httpd.apache.org/docs/howto/cgi.htm...liasdirectories (http://httpd.apache.org/docs/howto/cgi.html#cgioutsideofscriptaliasdirectories) )


In the .htaccess file, you'll need the following directive:

Options +ExecCGI which tells Apache that execution of CGI programs is permitted in this directory.

The above directive tells Apache to permit the execution of CGI files. You will also need to tell the server what files are CGI files. The following AddHandler directive tells the server to treat all files with the cgi or pl extension as CGI programs:
AddHandler cgi-script cgi pl
.htaccess files
A .htaccess file is a way to set configuration directives on a per-directory basis. When Apache serves a resource, it looks in the directory from which it is serving a file for a file called .htaccess, and, if it finds it, it will apply directives found therein. .htaccess files can be permitted with the AllowOverride directive, which specifies what types of directives can appear in these files, or if they are not allowed at all. To permit the directive we will need for this purpose, the following configuration will be needed in your main server configuration:
AllowOverride Options
I assume I don't need that last part, right? It's already enabled? (the AllowOverride Options)

So, theoretically, if I start fresh with an empty .htaccess file and add:
Options +ExecCGI

AddHandler cgi-script cgi
, I'll be all set. ? I'll try and see.

[D9r]

Done. Now I get the 500 Internal Server Error -- That's a good thing (never thought I'd think of a 500 Error as a good thing :) but it is). That means the server knows it's a CGI and is treating it as such. The remaining possiblities are:

1) Is the path correct? This is what's in the script:
#!/usr/local/bin/perl

2) Are permissions still correct? Did they get corrupted during download and upload? Do I need to reset them?

[D9r]

Apparently both #1 and #2 were the culprits. I checked the path in the awstats cgi and it was #!/usr/bin/perl so I changed all mine to that. Then I reset permissions to 755 and everything appears fine now.

That wasn't so bad -- 1 hour to find my way around the admin panel, 1 hour to set up the site, 1 hour to transfer the files, and 1 hour to tweak the CGIs.

[D9r]

So now all I do is point the domain to srv02.privatelabeldns.com ?

[Joe]

ns2a.privatelabeldns.com
ns2b.privatelabeldns.com

Yes :)

[D9r]

Just checking to see if you were paying attention. :wink:

I caught that right away because register.com doesn't consider "srv02.privatelabeldns.com" to be a valid DNS. The form wouldn't accept that so I went and found the correct ones. Now, if they would just let the confirmation go through! (Register.com is such a pain with their confirmation links; more than once they've not worked.)

Other than that, I'd say the transfer went well. I learned my way around the control panel and set up a site within a couple hours; and transferred the site over and troubleshooted the CGI scripts within a couple hours (which is no small task in case anyone reading this hasn't worked with CGI before. What I did today in about an hour typically could take a day to figure out. Brag, brag, brag.) Joe deserves some credit too for pointing me to .htaccess files as the solution, and for his quick replies. Thanks Joe.

Talk with you later,