Preserved Topic: Sendmail, PHP and Apache (Page 1 of 1)

I've been trying to get the mail function in PHP to work, which is doesn't, so I figured this must the problem, right?
I have never set up PHP with Apache. My problem is that in PHP, the path to sendmail doesn't seem to be correct.
When I run phpinfo(), it gives me this path: /usr/sbin/sendmail -t but the command which perl says it's in /usr/bin/sendmail

How can I fix this?

my boyfriend says: edit your php.ini, and look for the path to sendmail. dont you mean "which sendmail" instead of "which perl"?

------
Hell hath no fury like a woman scorned

No, I mean sendmail, I'm not using Perl. I can't find a php.ini file, isn't that just for Windows? I forgot to mention, the server is a Linux machine. I was hoping to find a text file that tells me the path (like an ini file) but I don't know if there is one or where to look for it. Really, the server admin should fix this, but it takes forever and since I have access, I wanna fix it (or muck it up? heh) myself.

my boyfriend says: "updatedb" will update the locate database and then "locate php.ini" will tell you where it is. php.ini isn't always in the same spot, depending on the OS and the way php was installed. its usually in /usr/local/lib though.

------
Hell hath no fury like a woman scorned

mr.maX says: php.ini is also available on Linux and it is probably located in the same folder where Apache configuration files are...

I know you mean sendmail dude, that's what I was saying. You wrote "but the command which perl says it's in /usr/bin/sendmail". Which perl will give you the location of perl, obviously. Hence the "don't you mean which sendmail, instead of which perl".

And MrMax, php.ini isn't "available" anywere, its a required part of php, its always put on the system when php is installed, and it isn't put in apache's conf dir, that makes no sense at all. On most unix systems it goes into /usr/local/lib.

And as for your being a wiseass, the reason she was doing the "my boyfriend says" is cause I was at work and just IM'd her the answer cause I didn't have time to register here and post. Heaven forbid someone try to help huh?

Thanks GenericPlayer, and welcome to the Asylum, I really appreciate your help. Sorry, I meant to write which sendmail ... you are absolutely right. I sometimes read what I *think* it says, not what it *really* says. I tried "locate php.ini " but it didn't return anything though.
Anyways, thanks for helping me out! (no hard feelings, I hope?)

GenericPlayer, I never said that php.ini is available anywhere (read my reply again). On older systems (i.e. RH6), php.ini is located in the same folder where Apache configuration files are. Using "/usr/local/lib" is a new trend (and not widely used, yet), before it was "/etc" (for configuration files)....



[This message has been edited by mr.maX (edited 03-24-2001).]

Hey GenericPlayer...on your site "my-balls.com"...you might not want to leave phpinfo() in your index page...some "malicious person" could have quite a bit of fun with all of that pretty information...and by the way...calm down, the wise ass crack wasn't needed, take a joke...

Did you do an "updatedb" first? Locate just looks through a pre-built database to find what you are looking for, so if that database is old, you won't find what you want that way.

MrMax, only packages ever put it in /etc or other random places depending on the weird tendencies of whoever built the package. Its in /etc for you, not because its an old redhat 6 box, but because someone was silly enough to use RPMs. Its not a trend that's changing either, packages always put stuff in weird places. If you compile it, it goes where it belongs.

And tim, I appreciate the concern, but any malicious person can go ahead and try to have whatever fun they like with that info. Anyone and everyone who has an account on that box can get exactly the same info and more about the system, doesn't bother me.

Packages can save some time (especially when tracking dependencies). Anyway, I was talking about RPMs from RedHat's RawHide, so it was RedHat's decision to put config files in /etc and not someone else's. Oh, and when I said "new trend", I was meant to say that RedHat has changed some locations in their packages for the latest release(s) of RH Linux.

All this is not really important, as long as everything works as it should...

Redhat is someone else, that's what I mean. RPMs are bad because they don't let you control your system, and as a packing sytem, it has alot of issues with different versions of different dependencies breaking too many things. I misunderstood your new trend comment because I sometimes forget people think unix is redhat and redhat is unix. What redhat does with their packages is meaningless, there are still filesystem hierarchy standards, just because a certain package by a certain company does things weird, doesn't make it a trend.

Well, I figured it out now. I had to look for "php3.ini".... and it was located nowhere near where it should be, far down in some obscure directory that the admin had hid away.

Doh! I should have thought of that. Did you get the mail function working now?

You know, this is bloody strange. I've been trying to get the so simple mail function in php to work for me, and it used but somehow stopped functioning. So I've been messing around plenty trying to figure out why it doesn't work. The php3.ini file was fine, so I just happened to try with Netscape instead of with IE. Then it worked... it seems that IE 5.5 was using the cached script file instead of the fresh version on the website. I haven't changed anything except emtying the IE cache, and it now works fine.

It's a wonderful life.

Another question though - I'm trying out using .htaccess with user authentication. Can a person still guess the name of a file in the directory and run it by typing in the address in the location bar? Or do they always get the login prompt first? I am writing some php and mysql stuff where I want to protect my insert and delete pages. I know how to require a login screen for each script, but if it works the same way with the directory protection with .htaccess and user auth, that would be much more convenient.

Yep, auth directives will protect your whole directory, and depending on how you set it, can also protect subdirectories. If someone knows the name of the file, and they try to go to it directly, it'll still prompt for their password. You can either put it in a .htaccess, or you can just stick it right in the httpd.conf if you are on your own server.