Home

Previous 20

Jun. 9th, 2005

PHP & PostgreSQL Woes, Part Four

OK, time for the pain!

First up, let me ensure that I've restored all the configuration files to their original state...
[tdavis@basement ~]$ su
Password: 
[root@basement tdavis]# cd /var/lib/pgsql/data/
[root@basement data]# cp pg_hba.conf.original pg_hba.conf
cp: overwrite `pg_hba.conf'? y
[root@basement data]# cp pg_ident.conf.original pg_ident.conf
cp: overwrite `pg_ident.conf'? y

Check.

And a little restart...
[root@basement data]# /sbin/service postgresql restart
Stopping postgresql service: [  OK  ]
Starting postgresql service: [  OK  ]

Check.

A little review of my test script...
[tdavis@basement 050609]$ cat insert.php 
<?php
ini_set('display_errors',true);
$dbconn=pg_connect("dbname=basement user=tdavis password=pokesmot");
$rset=pg_query($dbconn,"select * from users");
$array=pg_fetch_array($rset);
echo $array["username"];
echo "\n";
pg_close($dbconn);
?>

... and make sure it runs (it should print "tdavis")...
[tdavis@basement 050609]$ php insert.php 
Content-type: text/html
X-Powered-By: PHP/4.3.11

tdavis

Bingo!

Now let's load it up from the web...

Warning: pg_connect(): Unable to connect to PostgreSQL server: could not connect to server: Permission denied Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"? in /home/tdavis/public_html/050609/insert.php on line 3

Warning: pg_query(): supplied argument is not a valid PostgreSQL link resource in /home/tdavis/public_html/050609/insert.php on line 4

Warning: pg_fetch_array(): supplied argument is not a valid PostgreSQL result resource in /home/tdavis/public_html/050609/insert.php on line 5

Warning: pg_close(): supplied argument is not a valid PostgreSQL link resource in /home/tdavis/public_html/050609/insert.php on line 8

Curses!

Considering that it works from the command line but not from the web, I'm pretty confident that this is an 'ident' issue with PostgreSQL authentication. Essentially, the tdavis Unix account can connect to the tdavis database account, but the apache Unix account may not.

First I'll try the suggestion Larry Klug posted: changing 'ident' to 'trust', which essentially means "let anybody log in"...
[root@basement data]# diff pg_hba.conf pg_hba.conf.original 
66c66
< local  all    all             trust
---
> local  all    all             ident   sameuser

... and another restart...
[root@basement data]# /sbin/service postgresql restart
Stopping postgresql service: [  OK  ]
Starting postgresql service: [  OK  ]

... and a hit from the browser...

BAM! Same error.


Warning: pg_connect(): Unable to connect to PostgreSQL server: could not connect to server: Permission denied Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"? in /home/tdavis/public_html/050609/insert.php on line 3

Warning: pg_query(): supplied argument is not a valid PostgreSQL link resource in /home/tdavis/public_html/050609/insert.php on line 4

Warning: pg_fetch_array(): supplied argument is not a valid PostgreSQL result resource in /home/tdavis/public_html/050609/insert.php on line 5

Warning: pg_close(): supplied argument is not a valid PostgreSQL link resource in /home/tdavis/public_html/050609/insert.php on line 8

Round and round she goes. Where she stops, nobody knows!

Jun. 8th, 2005

I'll work on it tomorrow, I swear!

I spent last night with my daughter, and tonight I'm headed over to my girlfriend's to watch a movie. Tomorrow night I'm going to work on Project Basement. Really. I swear. Hmm... but I do have two new Netflix discs on my coffee table. Must resist! Must produce! We'll see :-)

Jun. 7th, 2005

Info on 3.9M Citigroup customers lost

(according to CNNMoney) and MC has only been working there a week! That's got to be a new record ;-)

Jun. 6th, 2005

PHP & PostgreSQL Woes, Part Two and One-Half

I wasted another hour banging my head against getting PHP to talk to PostgreSQL with no luck. At one point I decided to shut down the database just to see if PHP would give me a useful error message. The error changed slightly to:

Warning: pg_connect(): Unable to connect to PostgreSQL server: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

And here's the kicker: after I started the database back up again, PHP continued to say it could not connect to the server. So I restarted Apache. Nope! How about if I reboot the entire machine? Sorry. I have really screwed something up now... yet all of the configuration files have been restored to their original state (I always make backups).

PHP & PostgreSQL Woes, Part Two

Another fruitless day trying to get PHP talking to PostgreSQL.

It seems there's two approaches to this.

The first is to tell PostgreSQL to allow the Unix account running PHP (Apache) to connect to the database.

This is, according to my Googles, configured in a file called pg_hba.conf
[tdavis@basement ~]$ sudo find / -name pg_hba.conf >find 2>errors; cat find
/var/lib/pgsql/data/pg_hba.conf

This file contains a single line:
local  all    all             ident   sameuser

And the documentation explains that this tells PosgreSQL to allow any local users to connect to any database and assume their Unix username is the same as their PostgreSQL username:

ident

Obtain the operating system user name of the client (for TCP/IP connections by contacting the ident server on the client, for local connections by getting it from the operating system) and check if the user is allowed to connect as the requested database user by consulting the map specified after the ident key word. See Section 19.2.4 for details.

So what I need to do, apparently, is to create a new mapping that says Unix account 'apache' is allowed to log in as PostgreSQL user 'tdavis'...

19.2.4.3. Ident Maps

When using ident-based authentication, after having determined the name of the operating system user that initiated the connection, PostgreSQL checks whether that user is allowed to connect as the database user he is requesting to connect as. This is controlled by the ident map argument that follows the ident key word in the pg_hba.conf file. There is a predefined ident map sameuser, which allows any operating system user to connect as the database user of the same name (if the latter exists). Other maps must be created manually.

So I added the new line to pg_hba.conf and added the user mapping to pg_ident.conf and restarted PostgreSQL... no luck. Same error.

The second option is to create a new user for the 'apache' account to use.
[root@basement data]# su postgres
bash-3.00$ createuser
Enter name of user to add: apache
Shall the new user be allowed to create databases? (y/n) n
Shall the new user be allowed to create more new users? (y/n) n
CREATE USER

And give it access to the basement database:
postgres=# grant all on database basement to apache;
GRANT

Now this sucks. I don't want this account to have complete access to the database. I want this account to be able to select, insert, update, and delete, but not create new tables or drop existing tables, etc. But in order to achieve that level of access, I would have to grant it per table! OMG!

Sanity check:
[tdavis@basement ~]$ psql basement
Welcome to psql 7.4.8, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help on internal slash commands
       \g or terminate with semicolon to execute query
       \q to quit

basement=> \du
              List of database users
 User name | User ID |         Attributes         
-----------+---------+----------------------------
 apache    |     101 | 
 postgres  |       1 | superuser, create database
 tdavis    |     100 | 
(3 rows)

Restart PostgreSQL... nope. Still no access. Sucks. Sigh.

P. S. I'm an old emacs fanatic, but for today's session I used vi just to see what all the fuss was about. I'll use it again in future sessions before I make any judgements. So far I'm neither impressed nor disappointed.

Jun. 5th, 2005

PHP & PostgreSQL Woes, Part One

I'll spare you the twelve-page narration of my trials and tribulations and tell you simply that I am working on Project Basement this afternoon and I've not yet figured out how to connect to the PostgreSQL database from PHP.

Here's my code:
<?php
ini_set('display_errors',true);
$dbconn=pg_connect("dbname=basement");
pg_insert($dbconn,'users',$_POST);
pg_close($dbconn);
?>

And here's my error message:

Warning: pg_connect(): Unable to connect to PostgreSQL server: could not connect to server: Permission denied Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"? in /home/tdavis/public_html/censored_for_my_protection.php on line 3

I'm Googling for a solution at the moment.

Jun. 2nd, 2005

In case any of my WoW buddies read this...

http://www.thinkgeek.com/pennyarcade/swag/76e8/

I'll send you 400G in game for one of these ;-)

Another Lull

Fear not, faithful readers. Project Basement is not yet dead, just suffering another lull as work saps me of all my energy and traveling this weekend will prohibit any productivity. I plan to throw together some user account creation and log-in scripts as my next feet-whetting project, then I'll set up some revision control system to preserve my work (and my sanity).

Jun. 1st, 2005

Showering makes you fat!

I have a digital scale right next to my shower. This morning when I dragged my ass out of bed I stepped on. It read 138.5. I stepped off, waited for it to reset, then stepped on again. I always weigh myself twice to ensure the first reading wasn't a fluke. 138.5 again. OK. That's cool. I took my shower. After I dried off and stepped out, I thought, why not weight myself again just for laughs. 140.0. Then again. 140.0 both times. I gained 1.5 pounds in the shower. My only hypothesis is that my body absorbed that much water; but that seems like an awful lot. Wild.

May. 31st, 2005

Oh yeah, I ran a 5K

On Monday I ran my first 5K of 2005. It was the one-year anniversary of my first 5K ever. It was the first 5K I'd run since the Firefighter 5K in September of last year. During the winter months I stopped running and put on some extra poundage. I can't stand running in cold weather; breathing in the cold air makes me feel like crap. A couple months ago I started running again, but nowhere near the rigorous schedule of last year. I expected to do mediocre in the race on Monday, but surprisingly I ran my best time ever (just over 29 minutes). I guess I just might have to run a few more races this summer.

May. 29th, 2005

PHP Woes, Part One

I whipped up the obligatory "hello world" PHP script and... it worked! I didn't have to futz with anything! I'm speechless.

My first order of business was to figure out how includes worked. You know, code re-use and all that jazz. I want to be able to write a piece of code once and then import it into all the pages that need it.

Not surprisingly, the keyword for including another source file is "include". Surprisingly, there's four variations of it. WTF!? Get this...

include()

- Imports and executes another source file.

include_once()

- Imports and executes another source file only one time in case it's imported multiple times. Oh ho ho. This just stinks of a bug that was promoted to a feature. Importing external sources multiple times is going to cause namespace collisions and wreak all sorts of havoc. This should have been the default implementation IMHO. Backwards compatibility is a bitch; you have to keep big bugs and crappy APIs around just for the sake of not pissing off your user base. Yeah Java, I'm looking at you too.

require()

- This does almost the exact same thing as include, but it throws a "fatal exception" if there's a problem with the external file, as opposed to include's "warning". That's a nice hack.

require_once()

- You should be able to figure out what this one does.

I think I'm going to play it safe and use require_once exclusively (if I can). It seems to be the most logical implementation, and I'm betting it was the last version of this debacle added to the language. I can see why you might want to include and execute and external file multiple times, but those are extreme cases and there are certainly other (cleaner) ways to accomplish the same thing. And I'm a big proponent of code breaking rather than limping along. If something isn't right, I want the flow to stop immediately before more potential damage can be done.

So I added a couple includes to my test script. I intentionally included a non-existent file. No fatal error reported. WTF? It seems PHP by default doesn't dump error diagnosis to the web page for security reasons. I can agree with that. But where the frick are the errors logged? I've not yet figured that out. And even though the error isn't detailed on the page, I'd at least like to see notification that something is amiss. I'm researching those API calls now...

The first candidate seemed to be display_errors, which is documented to "determine whether errors should be printed to the screen as part of the output", but if you keep reading, there's a catch: "it won't have any affect if the script has fatal errors." Remember that "require" throws a fatal error. Oops. No help there.

The next candidate seems to be log_errors, which is documented to "Tell whether script error messages should be logged to the server's error log or error_log." And if you follow up on error_log you discover that it is the "name of the file where script errors should be logged. The file should be writable by the web server's user." Alright, I'll give that a whirl.
<?php
error_log('/home/tdavis/public_html/error.log');
log_errors(true);
require_once 'missing.php';
?>

Create the file...
[tdavis@basement public_html]$ echo > /home/tdavis/public_html/error.log
[tdavis@basement public_html]$ chmod 666 error.log 
[tdavis@basement public_html]$ ls --scontext | grep error
user_u:object_r:httpd_sys_content_t error.log

Hit the page and check the log...
[tdavis@basement public_html]$ cat error.log 

Nothing. Empty. Nada. Are you starting to grasp the beauty of this? I can't figure out how to get error logging working... and there's no way to debug it because none of the errors are being logged! I just might beat myself senseless... oh, too late.

Fortunately for me, I have root access, so I can peek at the Apache logs.
[client 24.233.173.197] /home/tdavis/public_html/error.log
[client 24.233.173.197] PHP Fatal error:  Call to undefined function:  
    log_errors() in /home/tdavis/public_html/test.php on line 3

Er... it seems that my call to error_log simply printed the string to the main log rather than setting the file path... wtf? Also, log_errors is undefined? Grr.

Oh, error_log is not a function name, well it is, but it's also a property name, and the latter is what I want. Now how do I set it? I haven't yet figured that out. Supposedly I can set it at run time using ini_set(), but as already stated above, in the case of a "fatal" error, as require_once throws, runtime settings are a moot point. Sigh.

But wait a second. How often is the documentation correct, much less consistent? Hell, I'm going to try it...
<?php
ini_set('display_errors',true);
require_once 'missing.php';
?>

Bam!

Warning: main(missing.php): failed to open stream: No such file or directory in /home/tdavis/public_html/test.php on line 3

Fatal error: main(): Failed opening required 'missing.php' (include_path='.:/usr/share/pear') in /home/tdavis/public_html/test.php on line 3

Bingo!

The day the Klug saved Christmas

It's 12:30AM, Saturyday night (Sunday morning). I made the mistake of checking my e-mail right before bed. Lo and behold I had a comment in my blog from a very old friend and colleague, Larry Klug.

Larry and I worked together at the beginning of the dot com explosion. I remember Larry as a young Visual Basic coder who pined about his days of airbrushing t-shirts and serving customers the "onion of the day"... and of course the management of the official Gram Parson's web site and fan club.

Many years ago, when our dot com baby went bust, we went our separate ways. But a year or so ago I rediscovered Larry through his blog. I discovered, from his writings, that he'd become quite the accomplished tech guru, jetsetting about and dabbling with, hell mastering wonderful niche technologies that I can only dream about having (making?) the time to explore. His rants about synching his iPod from Linux left me dumbfounded. He was "in the shit" (as you might hear from a cliche Vietnam war movie) in regards to coding. He was getting down and dirty with device drivers and code on the bleeding edge. I silently envied him from afar.

And on this fateful night, my dear friends, Larry enlightened me. He pulled my head out of the sand and showed me the path that I had lost. He earned his sainthood this evening by exposing the solution to my Apache problem that I now realize I was nowhere close to resolving on my own and probably would not have for a very long painful time to come...

Subject: Sealed for your protection

One word: SELinux

Fedora Core 3 ships with an SELinux kernel. SELinux (Security Enhanced Linux) is essentially a way to add an additional layer of file permissions over and above the normal users/groups permissions. In short, chmod will not help you. You should instead use the command chcon to change the security context of the directory you want to use. Apache should really add this to their FAQ. Even though RedHat is really to blame, the Apache FAQ is the first place someone might look for a solution. Unfortunately, this one is too new to be easy to find in the usual places. You can disable SELinux completely, or try something like: "chcon -t httpd_sys_content_t /home/tdavis/basement".

Wow. That sounds like good stuff. A little googling turned up this gem which corroborates Larry's explanation:

http://www.networkclue.com/os/Linux/commands/chcon.php

So let's play with this...
[tdavis@basement ~]$ ls --scontext
user_u:object_r:user_home_t      Desktop
user_u:object_r:user_home_t      errors
user_u:object_r:user_home_t      find
user_u:object_r:user_home_t      public_html

Interesting...
[tdavis@basement ~]$ ls --scontext /var/www
system_u:object_r:httpd_sys_script_exec_t cgi-bin
system_u:object_r:httpd_sys_content_t error
system_u:object_r:httpd_sys_content_t html
system_u:object_r:httpd_sys_content_t icons
system_u:object_r:httpd_sys_content_t manual
system_u:object_r:httpd_sys_content_t usage

Yes indeed it seems httpd_sys_content_t is the magic value. Let's give it a whirl...
[tdavis@basement ~]$ chcon --type httpd_sys_content_t public_html

Nope, but it gave me a different error message, which is promising. Let's try a little deeper.
[tdavis@basement ~]$ cd public_html/
[tdavis@basement public_html]$ chcon --type httpd_sys_content_t index.html 

HALLELUJAH!!!

Thanks Larry! I owe you one. I owe you a big one!

Firefly

After reading all the "gull ram" hype about this TV series on Slashdot, and the news of the upcoming feature film Serenity (the name of the space ship, and the pilot episode), I rented the first (and only) season on DVD to see what it's all about. It started out good and got better. It's not a "great" show in my book, but it breaks a lot of cliches for it's genre. It's the anti-Roddenberryian space adventure. The captain kills with little remorse. You won't see any Wrath of Kahn spin-offs from this show -- you cross the captain and he leaves you stone cold dead. His crew doesn't follow him blindly like mindless puppies -- hell one of them even tries to turn the others in for their bounties. Romances aren't wrapped up in single episodes, nor are they clean and pretty. People get shot; both good and bad. People die; both good and bad. The acting is solid. The writing is solid. It's a nice piece of entertainment and I can certainly see why it had such a passionate following. There's no grand sub-plot like Babylon 5 or the X-Files. It's pretty episodic with most continuity simply preserved for humor value -- the crew doesn't let each other forget their embarrassing faux pas from past adventures. I don't know anything about the upcoming movie, but I hope it wraps up some of the dangling threads from the series... and in some way I hope it leaves a few of those threads still dangling. For example, I want to know what's wrong with the lobotomized chick, but I don't care to see the captain and the on-board whore confess their hidden love for each other. I guess it all depends on how much control the originator (Josh Whedon) is able to preserve when the big movie studio execs decide to step in and candy coat everything. If I had a nickel for every DVD I've rented that has the bonus track with the "original ending the studio made us rewrite" that made me gasp in awe at how much better the film would have been if they didn't all sail off into the sunset at the end and live happily every after.

May. 28th, 2005

Apache Woes, Part Four

Because I'm a glutton for punishment, I press on...

Maybe the problem is specific to the special index.html file name.
[tdavis@basement ~]$ cd public_html/
[tdavis@basement public_html]$ echo "hello world" > snafu.html
[tdavis@basement public_html]$ ls -al snafu.html 
-rw-rw-r--  1 tdavis tdavis 12 May 28 19:56 snafu.html

http://basement.dnsalias.net/~tdavis/snafu.html

Forbidden

You don't have permission to access /~tdavis/snafu.html on this server.

Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

Apache/2.0.52 (Fedora) Server at basement.dnsalias.net Port 80

Nope.

Mabye if I kill httpd I can su into the apache user and test the file access.
[tdavis@basement public_html]$ sudo /sbin/service httpd stop
Stopping httpd: [  OK  ]
[tdavis@basement public_html]$ su
Password: 
[root@basement public_html]# su apache
This account is currently not available.

Nope.

This has got to be a farking configuration problem! Right? Oh what I wouldn't pay for some... oh wait, paying would defeat the purpose of using free software. Ah, the fool I am.

I'm peeking at the configuration file again... because I'm stubborn like that. Time to delve a little deeper into each part of the access control settings.

http://httpd.apache.org/docs-2.0/mod/core.html#limit

http://httpd.apache.org/docs-2.0/mod/core.html#limitexcept

http://httpd.apache.org/docs-2.0/mod/mod_access.html#order

http://httpd.apache.org/docs-2.0/mod/core.html#options

It all looks good. Argh.

Is there anything more frustrating than something that should work doesn't? My problem is probably something incredibly simple that a veteran Apache administrator would notice in a blink of the eye, but it's stumped me for days now, and I'm no closer to a solution.

Apache Woes, Part Three

OK let's get this file permission theory settled once and for all...
[tdavis@basement conf]$ su
Password: 
[root@basement conf]# su apache
This account is currently not available.

Sigh. So much for that idea.

Maybe I need an .htaccess file. Oh this is going to get ugly.

http://httpd.apache.org/docs-2.1/howto/htaccess.html

OK that was nigh-useless. How about another?

http://httpd.apache.org/docs-2.1/sections.html

Nope, not much help either. The core configuration file implies that my directory should be wide open to the world. I'm frustrated and infuriated at this point.

How about another trip to the FAQ?

Why do I get a "Forbidden/You don't have permission to access / on this server" message whenever I try to access my server?

Search your conf/httpd.conf file for this exact string: <Files ~>. If you find it, that's your problem -- that particular <Files> container is malformed. Delete it or replace it with <Files ~ "^\.ht"> and restart your server and things should work as expected.

This error appears to be caused by a problem with the version of linuxconf distributed with Redhat 6.x. It may reappear if you use linuxconf again.

OK, that sounds promising...
[tdavis@basement public_html]$ grep "<Files" /etc/httpd/conf/httpd.conf
<Files ~ "^\.ht">

Nope, we're fine there.

How can a tool as prevalent as Apache be so convoluted to configure and so damn hard to troubleshoot!? This is fscking ridiculous! I've now lost days of potential productivity because I can't figure out how to publish a damn file.

Once again I bang my head against the configuration file to reiterate the obvious...
# The path to the end user account 'public_html' directory must be
# accessible to the webserver userid.  This usually means that ~userid
# must have permissions of 711, ~userid/public_html must have permissions
# of 755, and documents contained therein must be world-readable.
# Otherwise, the client will only receive a "403 Forbidden" message.

And for sanity sake...
[tdavis@basement public_html]$ pwd
/home/tdavis/public_html
[tdavis@basement public_html]$ ls -al
total 24
drwxr-xr-x   2 tdavis tdavis 4096 May 28 17:06 .
drwx--x--x  17 tdavis tdavis 4096 May 28 08:34 ..
-rw-rw-r--   1 tdavis tdavis   12 May 28 08:34 index.html

Yup, exactly what it says.

http://basement.dnsalias.net/~tdavis/index.html


Forbidden

You don't have permission to access /~tdavis/index.html on this server.

Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

Apache/2.0.52 (Fedora) Server at basement.dnsalias.net Port 80

Sigh. Huh? What's that part about an error trying to use an ErrorDocument? Something else is broken too? Or is this perhaps related?

I don't know why Apache isn't/can't/won't serve the error documents, but I found it on the drive and read the contents:

You don't have permission to access the requested directory.
There is either no index document or the directory is read-protected.

The first part is obvious; I know it's not permitting me to access the directory. The second part is quite simply wrong; there is an index document and it is not read-protected. WTF!?

I'm too pissed to continue.

Katamari Damacy

I got this game for my daughter for her birthday. We've been playing it all day. It's fantastic. It's a testament to the old adage that simplicity is king. The goal of the game: roll a ball around and things stick to it. That's it! It's easy. It's fun. It's entertaining. Even the head-to-head is a blast. You can get your opponent's ball stuck to your ball if you've got the size advantage, then they have to shake themselves off while you use your temporarily boosted girth to stick even bigger stuff. Oh, and the soundtrack is mostly classic big-band jazz tunes sung in Japanese -- hilarious! My daughter sings along with the scatting sections. The plot, if you can call it that, is animated like it was ripped out of an old Beatles animation (like Yellow Submarine or Sergeant Pepper). It's psychedelic! We're loving every second of it.

Apache Woes, Part Two

It suddenly came back to me. I recall in the olden days of yore, you could configure Apache to let users host websites from their home directories as long as they all followed the convention of created a directory under their relative home directory named public_html. This probably isn't enable by default, but let's clean up my former mess and try it...
[tdavis@basement ~]$ rm basement/test.html 
[tdavis@basement ~]$ rmdir basement/
[tdavis@basement ~]$ mkdir public_html
[tdavis@basement ~]$ cd public_html/
[tdavis@basement public_html]$ echo "hello world" > index.html
[tdavis@basement public_html]$ ls -al
total 24
drwxrwxr-x   2 tdavis tdavis 4096 May 28 08:34 .
drwxr-xr-x  17 tdavis tdavis 4096 May 28 08:34 ..
-rw-rw-r--   1 tdavis tdavis   12 May 28 08:34 index.html

That all looks good.

http://basement.dnsalias.net/~tdavis/index.html

I'm starting to wonder if the user account that's running Apache simply doesn't have permission to read the tdavis files and directories... but before I investigate that, I'm going to take one more crack as the configuration file.

Oh yeah, I forgot to clean up one thing.
[tdavis@basement public_html]$ cd /var/www/html/
[tdavis@basement html]$ ls -al
total 20
drwxr-xr-x  2 root root 4096 May 26 21:32 .
drwxr-xr-x  8 root root 4096 Nov 11  2004 ..
lrwxrwxrwx  1 root root   21 May 26 21:32 basement -> /home/tdavis/basement
[tdavis@basement html]$ sudo rm basement

Alrighty. I found and un-commented the following section of the configuration file:
#
# Control access to UserDir directories.  The following is an example
# for a site where these directories are restricted to read-only.
#
<Directory /home/*/public_html>
    AllowOverride FileInfo AuthConfig Limit
    Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
    <Limit GET POST OPTIONS>
        Order allow,deny
        Allow from all
    </Limit>
    <LimitExcept GET POST OPTIONS>
        Order deny,allow
        Deny from all
    </LimitExcept>
</Directory>

And a quick restart.
[tdavis@basement conf]$ sudo /sbin/service httpd restart

Nope. Perhaps I missed something else... ah, here we go:
<IfModule mod_userdir.c>
    #
    # UserDir is disabled by default since it can confirm the presence
    # of a username on the system (depending on home directory
    # permissions).
    #
    UserDir disable

    #
    # To enable requests to /~user/ to serve the user's public_html
    # directory, remove the "UserDir disable" line above, and uncomment
    # the following line instead:
    #
    #UserDir public_html

</IfModule>

Another restart and... bam! Hmm, still can't load the page, but the error message changed from "Not Found" to "Forbidden". That's a good sign... isn't it?

Here's another clue...
# The path to the end user account 'public_html' directory must be
# accessible to the webserver userid.  This usually means that ~userid
# must have permissions of 711, ~userid/public_html must have permissions
# of 755, and documents contained therein must be world-readable.
# Otherwise, the client will only receive a "403 Forbidden" message.
#
# See also: http://httpd.apache.org/docs/misc/FAQ.html#forbidden

This points back to my original theory that the user running Apache doesn't have access to my home directory. But it is world readable, so I'm stumped. Let's check out the URL listed in the comments...

14. Why do I get a "Forbidden" message whenever I try to access a particular directory?

This message is generally caused because either

* The underlying file system permissions do not allow the User/Group under which Apache is running to access the necessary files; or
* The Apache configuration has some access restrictions in place which forbid access to the files.

You can determine which case applies to your situation by checking the error log.

In the case where file system permission are at fault, remember that not only must the directory and files in question be readable, but also all parent directories must be at least searchable (i.e., chmod +x /directory/path) by the web server in order for the content to be accessible.

Ah, there's an error log? Duh! Let's check that out...
[tdavis@basement public_html]$ cd /etc/httpd/logs/
-bash: cd: /etc/httpd/logs/: Permission denied

Grr...
[tdavis@basement public_html]$ su
Password: 
[root@basement public_html]# cd /etc/httpd/logs
[root@basement logs]# ls
access_log    error_log    ssl_access_log  ssl_request_log
access_log.1  error_log.1  ssl_error_log
[root@basement logs]# tail error_log
...
[Sat May 28 11:54:18 2005] [error] [client 24.233.173.197] (13)Permission 
    denied: access to /~tdavis denied

OK, permission denied, by what? The file access settings? The httpd configuration settings? No help there. So much for "You can determine which case applies to your situation by checking the error log." Lies, all lies!

The file access settings look fine to me. Everything is world-readable.
[tdavis@basement public_html]$ ls -al
total 24
drwxr-xr-x   2 tdavis tdavis 4096 May 28 08:34 .
drwx--x--x  17 tdavis tdavis 4096 May 28 08:34 ..
-rw-rw-r--   1 tdavis tdavis   12 May 28 08:34 index.html

One more peek at the configuration file... nope, nothing evident there. Another frustrating fruitless session. Sigh.

May. 27th, 2005

RedHat Woes Update

Through the window manager, I found a GUI that allowed me to make Apache and PostgreSQL start up when the machine boots. I have no idea WTF it did behind the scenes. If I didn't have access to the GUI, if this box had been racked a couple weeks ago like I had planned, I'd still be screwed. Let's hear it for procrastination!

RedHat Woes, Part One

Before I continue, I need to fix something that's irking me. Apache and PostgreSQL are not starting up when the machine reboots. I have Googled my nads off and come up dry with a solution to this (much to my dismay -- can my faith in FOSS dwindle any more?). No help from RedHat's knowledge base, none from Apache, not even PostgreSQL's web site. I tried all the cockamamie Apache suggestions from non-official blogs and forums and none have worked. Here's the less cryptic of them all...

http://sol4.net/linux/apache1.shtml

Starting Apache under Redhat

Under Redhat, to start Apache at boot time you, after logging in as root, you need to create the following link.

ln -s /usr/local/apache/bin/apachectl /etc/rc.d/init.d/apache

... but, it didn't work. So I'm moving on to PostgreSQL. This one solution looks promising...

http://www.openmicroscopy.org/install/redhat.html

You will probably want PostgreSQL to start on boot. The init script, which automates startup and shutdown, is already copied to the init.d directory by the rpm install. You just have to turn it on to the appropriate run levels.

chkconfig --level 345 postgresql

[tdavis@basement init.d]$ sudo /sbin/chkconfig --level 345 postgresql
only one runlevel may be specified for a chkconfig query

Oh really? That's not what the man page says...
--level levels
    Specifies the run levels an operation should pertain  to.  It  is
    given as a string of numbers from 0 to 7. For example, --level 35
    specifies runlevels 3 and 5.

Sigh. Chalk up yet another soul-crushing defeat at the hands of FOSS. This is depressing.

May. 26th, 2005

Apache Woes, Part One

OK, I've got a default RedHat Linux install with a default Apache install. Let's see what going on there...

http://basement.dnsalias.net/

"The operation timed out when attempting to contact basement.dnsalias.net."

Hmm, that's a good sign that Apache isn't running. Fortunately for me, I've worked with Apache before, so this shouldn't be too hard to figure out...
[tdavis@basement ~]$ sudo /usr/sbin/apachectl start

Much better. Now I can see the Fedora Core Test Page. We're rolling now. Let's set up a working directory in my home directory and see if I can get Apache to serve it...
[tdavis@basement ~]$ pwd
/home/tdavis
[tdavis@basement ~]$ mkdir basement
[tdavis@basement ~]$ ls -al basement
total 16
drwxrwxr-x   2 tdavis tdavis 4096 May 26 21:19 .
drwx------  17 tdavis tdavis 4096 May 26 21:19 ..

There's the directory, and it's got good permissions (everybody can read). Now I need to find the Apache configuration file...
[tdavis@basement ~]$ find / -name httpd.conf > find 2> errors; cat find
/etc/httpd/conf/httpd.conf

I really should macro that command; I use it all the time since I can never remember where anything is.

Time to load up emacs and take a peek...

Wow! Look at the bazillion configuration variables. Holy macaroni! There are 1005 lines in the configuration file.
#
# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "/var/www/html"

Okie dokie, so that's where it's looking...
[tdavis@basement ~]$ cd /var/www/html
[tdavis@basement html]$ ls -al
total 16
drwxr-xr-x  2 root root 4096 Nov 11  2004 .
drwxr-xr-x  8 root root 4096 Nov 11  2004 ..

Er... where's the Fedora Core Test Page that's being served? This directory is empty!

Ah, well, I'll worry about that later. Let's see if I can create a symbolic link to the directory in my home directory and load a test page...
[tdavis@basement html]$ su
Password: 
[root@basement html]# ln /home/tdavis/basement basement
ln: `/home/tdavis/basement': hard link not allowed for directory

Apparently I don't remember how to create a symbolic link.
[root@basement html]# ln /home/tdavis/basement basement --symbolic
[root@basement html]# ls -al
total 20
drwxr-xr-x  2 root root 4096 May 26 21:32 .
drwxr-xr-x  8 root root 4096 Nov 11  2004 ..
lrwxrwxrwx  1 root root   21 May 26 21:32 basement -> /home/tdavis/basement

OK, that's better.
[root@basement html]# exit
[tdavis@basement html]$ cd
[tdavis@basement ~]$ cd basement/
[tdavis@basement basement]$ echo "hello world" > test.html

http://basement.dnsalias.net/basement/test.html

"Forbidden -- You don't have permission to access /basement/test.html on this server."

Gah! Perhaps Apache is configured to not follow symbolic links.

Nope, I see "FollowSymLinks" for the root level directories in the config file.

Perhaps I screwed up the permissions on my file or home directory.
[tdavis@basement basement]$ ls -al
total 24
drwxrwxr-x   2 tdavis tdavis 4096 May 26 21:33 .
drwx------  17 tdavis tdavis 4096 May 26 21:21 ..
-rw-rw-r--   1 tdavis tdavis   12 May 26 21:34 test.html

Yup, that looks like it. My home directory is locked up.
[tdavis@basement basement]$ chmod 755 ..
[tdavis@basement basement]$ ls -al
total 24
drwxrwxr-x   2 tdavis tdavis 4096 May 26 21:33 .
drwxr-xr-x  17 tdavis tdavis 4096 May 26 21:21 ..
-rw-rw-r--   1 tdavis tdavis   12 May 26 21:34 test.html

Hmm, that didn't fix it. Perhaps Apache needs to be restarted. I can't imagine that's the case, but my Unix-fu is very rusty, so I might as well try.
[tdavis@basement basement]$ sudo /sbin/service httpd restart
Stopping httpd: [  OK  ]
Starting httpd: [  OK  ]

Note that I used the RedHat convenience tool "service" this time. But alas it did not solve the problem. I still can't access my test page.

Hmm, I have a theory that /var/www/html is not the correct directory. My first clue is that it's empty yet Apache is serving a default page.
[tdavis@basement ~]$ find / -name index.html >find 2>errors; cat find
/var/www/usage/index.html
/var/www/manual/index.html
...
..
.

115 files and none of them look to be my target. Grr. OK, Apache, you've won this battle, but I'll be back to fight another day. Mark my words!

Previous 20

June 2005

S M T W T F S
   1234
567891011
12131415161718
19202122232425
2627282930  

Advertisement

Syndicate

RSS Atom
Powered by LiveJournal.com