|
|
Posted by klenwell on 04/03/07 17:39
I was researching some of these same issues a while ago and came
across this site:
http://www.nyphp.org/phundamentals/ini.php
Gives some good advice on PHP initialization for cases when you do and
do not control the server.
Tom
On Apr 3, 4:50 am, Schraalhans Keukenmeester <bitbuc...@invalid.spam>
wrote:
> hansBKK wrote:
> > OK, at the risk of driving all of you (and myself) nuts, here are some more
> > questions, sorry if there's some overlaps I missed in my earlier hysteria,
> > I'd composed these earlier when I was feeling saner:
>
> > Is there a way to have script-sent emails come from a specified Return-path
> > email address in the mod_php environment, or do they **have to** come from
> > nobody/Apache/web user?
>
> > Next area - phpsuexec, suExec, SUhosin and suphp - I've mostly seen these
> > discussed relative to CGI mode. If my host is running php as a module, then
> > is it safe for me to ignore these, or should I also ask if they are using
> > any of these?
>
> > What should I be looking for in regards to open_basedir and
> > register_globals? I believe the former can't be switched locally, only
> > server-wide right? And I believe I should look for a host that allows me to
> > switch register_globals? Along with things like memory_limit, magic_quotes,
> > upload-related variables, etc.
>
> > Some hosts state that their customers can choose to run either v4 or 5, by
> > simply changing the file extension on the scripts - e.g. *.php runs version
> > 4, use *.php5 to run v5. This seems like a good thing, right?
>
> > What accelerator(s) should I be looking for - good performance without
> > causing problems?
>
> > Finally, if the host will give me access to phpinfo(), can I figure out for
> > myself how all these factors are configured on their servers without my
> > having to ask them such a long list of questions?
>
> All the issues regarding functions allowing access to the host os's
> commands (the exec and suexec family etc) don't have to be a
> dealbreaker. Just beware if _you_ can use them, so can all the other
> customers on that server. How you use them yourself (if at all) is your
> responsibility. But shared servers with well over 500 concurrent
> customers isn't an exception, and 500 people can do a real lot of bad
> things, even if only out of stupidity. So factor in the risk your pages
> suddenly have gone one day and are replaced by whatever nasty you can
> think off.
>
> phpinfo() tells you a whole lot about the server's features and ini
> vars. Not per se whether or not you get to set your own for each
> specific one. It definitely is a good start, before you burden their
> helpdesk.
>
> The 'auto' select feature between 4 and 5 at first seemed brilliant to
> me (only that was when it was between 3 and 4), but soon I found out it
> can be a nightmare as well. If you use other people's packages you may
> end up having to manually change all references and extensions to fit
> the correct versions. I'd prefer having separate directories for example.
>
> register_globals should, imho, never be on in a prod environment.
> period. Open_basedir restrictions are good, but they can sometimes be
> too strict as well. My host did not allow me to write to ANY dirs above
> the wwwroot, thus more or less forcing me to have a wide-open upload
> directory accessible by web use. (with .htaccess limiting to a given
> host or ip range for instance you CAN safeguard the dir after all, but I
> did get them to have an accessible directory above my webroot. Similar
> for include files (they are nothing Imore than php scripts in my case
> with my own library of functions, classes and variables), it's safer to
> have them outside your webroot, so they NEVER can be opened directly by
> a browser.
>
> I'm not an expert by any standards on php and mail. Blunt logic would
> have me think it SHOULD be possible to have a custom Return path, but
> there may be restrictions I am unaware of. Can't help you there.
>
> Things like a preset max memory limit never have been a burden for me
> yet. In a shared environment I'd be surprised to find I could change it
> myself.
>
> HTH
>
> Sh
Navigation:
[Reply to this message]
|