next »

[dink]

::background music = theme from The Twilight Zone

What a strange evening I've had.

Been playing around with my brandy new vps.  Fun learning experience.  It's the Ubuntu 7.10 server based on Debian, so it's very much like my dev virtual here on the home pc.

Got things going my way with the email, ftp server, mysql, all the goodies I need/want.
Put up a nifty little intro page as the index.php.  Things looking good.

This afternoon I decided to install a SMF forum.  So, I did so.  Went pretty well I thought.  The docs at SMF gave a good list of the changes needed for php.ini.  Went to the admin page and set things up, you know, setting permissions and adding sections.  Pretty nifty.

I thought.

I tried to access the forum without my cookie.  Just to see what the default login page looked like.  Guess what?  403 forbidden.  WTF?

So off I go to the SMF forum to get the low down on the fix.  Shittah.  The gurus over there say that there is a problem with a module called mod_security.c.  So, I opens up a blank .htaccess and paste in their remedy.  All fixed up, right?  Not on your sweet ass!

Now I've got a 500 internal server error.  WTF? X 2 = wtf wtf?

Back to the SMF forum.  Not much in the way of help there.  So, I go back to my box and remove the fix in .htaccess.  Back to a 403 again.  Well, says I, that's a permission prob.  I hack around with chown for a while.  Back to the index page.  Still 403.  Just on the off chance, I changed the url from www.mysite.com to mysite.com.  Up pops the Apache default page.  WTF?

Open up .htaccess again and post the old remedy in there.

Code:

Options +FollowSymlinks
RewriteEngine on
rewritecond %{http_host} ^example.com [nc]
rewriterule ^(.*)$ http://www.example.com/$1 [r=301,nc]

Ha, says I, gotcha now big boy.  El wrongo.  Now I'm back to the 500 error again.

::increase the volume of background music::

I decide to let the server tell me what's going on so I go read the apache log.  Guess what?  Found a whole bunch of this:  "caught SIGWINCH, shutting down gracefully".  Gooogled around a while for what that means (still don't know) and how to fix it.

One site had a reasonable sounding solution:
sudo apt-get remove --purge php5 libapache2-mod-php5
then reinstall with
sudo apt-get install libapache2-mod-php5

His comment was "Bingo.  Works fine now".  I cry Bull Shit.  It don't work for this old man.  Upon trying the reinstall I got a message from hell.  "Your apache configuration is like a pool of putrid snot lying on a dung heap and we ain't re starting it.  So there."

Just exactly what I wanted to hear.  I tried another removal and re install of the php5 package.  Seemed like it went thru fine, but didn't change the results at all.

In desperation (it's been like six hours now) I tried my old Windoxe trick.  Re boot the whole shebang.  Dint worky.

So where are things now?  Dabbed if I know.  I came over here to cry on your shoulders.  Guess I'll delete the whole mess and start over again.  Sigh....

I don't know if it is a problem with the SMF 2.0 beta thingie, but I believe it is.
If I decide to go back with SMF, I think I'll try to find one of the earlier versions.

I bare my backsides and smile.  Once again.

Ratz.  Big farking ratz with tails this...............farking long.

[perkiset]

Have you confirmed that PHP is working really well Dink?

Since this is your box, start working with the httpd.conf file, rather that .htaccess. It's way faster and a better way to do things.

There's a couple things we should do to create a solid server and triage situation.

First off, are you supporting virtual hosts on that box? What you want is a directive in your httpd.conf file like this: (Assume that 1.2.3.4 is your public-facing IP address on that box)

NameVirtualHost 1.2.3.4:80

Now create yourself another virtual host, something like this:

<VirtualHost 1.2.3.4:80>
   ServerName  dinktest.testdomain.com
   DocumentRoot  /www/sites/testing
</VirtualHost>

Another things we need to look at is the default directories for that server. There are two place in the httpd.conf file that you've got to monkey with to get your essential directory tree OK. First off, is the default/root document directory for the server. This will look something like this:

DocumentRoot /www/sites/default

Note that this is MY default directory - Apache installs with something like /usr/local/apache2/httpdocs or WTFE. The second place we need to adjust in the conf file is AFTER the rule that locks down the entire drive. The rule you DONT touch looks like this:

# First, we configure the "default" to be a very restrictive set of
# features.   
# 
<Directory />
   Options FollowSymLinks
   AllowOverride None
   Order deny,allow
   Deny from all
</Directory>

... the rule we DO muck with looks like this:

# 
# This should be changed to whatever you set DocumentRoot to.
# 
<Directory "/www/sites">

Now: your forum should be deeper on the tree down THAT path for example, the directory for this board is /www/sites/perkiset/forum - so as you can see, the rule that allows Apache access falls under the /www/sites directory, which is where we've opened up access.

So now you can see that we've created a virtual host named dinktest.testdomain.com and it points to a directory /www/sites/testing - obviously this needs to be adjusted for your setup, but I'm hoping you get the gist.

You'll need to cycle Apache to implement the changes:

/usr/local/apache2/bin/apachectl -k graceful

If it restarts with no complaints, then we're doing well.

Now on YOUR MACHINE AT HOME edit your hosts file - adding the IP address of your server to it with the name we used for the domain ie.,

1.2.3.4    dinktest.testdomain.com

you should be able to ping dinktest.testdomain.com and get right to your VPS box.

Now on your VPS, create a little file in the /www/sites/testing directory:

Code:

<?php

phpinfo();

?>

and save that as phpinfo.php.

Now from a browser you should be able to go to:

http://dinktest.testdomain.com/phpinfo.php

and get a pretty full featured screen of exactly how PHP is running on your box. If we get this far and PHP is all good, then the problem is with SMF and we move to phase two. If we can't get this working, the the problem is more fundamental.

Good luck, ping with symptoms,
/p

[perkiset]

Reading back over that, I forgot to clarify one thing: the reason we go with the dinktest.testdomain.com is that unless someone knows your "pseudo-domain-name" and points that exact name at your server address, this information will not be public. So although I do not recommend leaving a phpinfo script out there in production for any length of time, this is a great way to be able to open up a semi-private test space on a public server for a while.

Hope that makes it clearer...

/p

[dink]

Have you confirmed that PHP is working really well Dink?

Nope, instead, confirmed that it was fubar.  That's part (maybe all) of the problem caused by me mucking around in the php.ini like SMF suggested.

I've gone to a restore point before the SMF install, so it won't take long to get back to square 1.0.0.1.

I hadn't considered a virtual box there to test in.  Good idea.  I'll get that done.  Thanks.

Did your install of SMF need any php.ini changes?

[perkiset]

No, SMF 1.4 does not require any php.ini changes and I am really curious and concerned about what they want you to change... I've not ever had a PHP app that required one, with the exception of a REALLY memory-heavy reporting app I wrote...

[jammaster82]

even I got smf 1.1.4 installed no hangups,
 and we all know im 'tarded. its pretty nifty
and has 'karma' where admins can applaud
or smite users to adjust their 'alignment'

[perkiset]

even I got smf 1.1.4 installed no hangups, and we all know im 'tarded.

Hardly, that.
Stoned to the gills, perhaps. But 'tarded? I think not

[dink]

No, SMF 1.4 does not require any php.ini changes and I am really curious and concerned about what they want you to change... I've not ever had a PHP app that required one, with the exception of a REALLY memory-heavy reporting app I wrote...

My install was the new one 2.0.  Here is the doc page:
http://docs.simplemachines.org/index.php?topic=7

Here's the stuff they said to change:

Code:

PHP 4.3.10 or higher, with the following set in php.ini:

the max_input_time directive set to a value of at least 30.
the post_max_size and upload_max_filesize directives set to the size of the largest attachments you wish to be able to upload.
the memory_limit directive set to at least 8M.
the max_execution_time directive set to at least 15.
the register_globals directive set to Off.
safe mode disabled, or PHP suExec enabled.