luk Wed Mar 13 16:43:21 2002 EDT
Added files:
/phpdoc/cs/faq installation.xml
Log:
Index: phpdoc/cs/faq/installation.xml
+++ phpdoc/cs/faq/installation.xml
<?xml version="1.0" encoding="iso-8859-2"?>
<!-- EN-Revision: 1.13 Maintainer: luk Status: mixed -->
<chapter id="faq.installation">
<title>Instalace</title>
<titleabbrev>Instalace</titleabbrev>
<para>
Tato část se zabývá častými otázkamni ohledně způsobu instalace PHP.
PHP je dostupné pro většinu OS (v podstatě kromě MacOS pře OSX) a většinu
webovských serverů.
</para>
<para>
Při instalaci PHP postupujte podle instrukcí v souboru
<ulink url="&faqurl.file.installation;">INSTALL</ulink> v příslušné
distribuci. Uživatelé Windows by si také měli přečíst soubor
<ulink url="&faqurl.file.readmewin;">install.txt</ulink>.
Existuje také soubor s různými fintami pro Windows - najdete ho
<link linkend="install.windows">tady</link>.
</para>
<qandaset>
<qandaentry id="faq.installation.phpini">
<question>
<para>
Unix/Windows: Where should my php.ini file be located?
</para>
</question>
<answer>
<para>
By default on UNIX it should be in <filename>/usr/local/lib</filename>.
Most people will want to change this at compile-time with the
<link
linkend="install.configure.with-config-file-path">--with-config-file-path</link>
flag. You would, for example, set it with something like:
<programlisting>
--with-config-file-path=/etc
</programlisting>
And then you would copy <filename>php.ini-dist</filename> from
the distribution to <filename>/etc/php.ini</filename> and
edit it to make any local changes you want.
</para>
<para>
On Windows the default path for the <filename>php.ini</filename>
file is the Windows directory.
</para>
</answer>
</qandaentry>
<qandaentry id="faq.installation.nodata">
<question>
<para>
Unix: I installed PHP, but every time I load a document, I get the
message 'Document Contains No Data'! What's going on here?
</para>
</question>
<answer>
<para>
This probably means that PHP is having some sort of problem
and is core-dumping. Look in your server error log to see if
this is the case, and then try to reproduce the problem with
a small test case. If you know how to use 'gdb', it is very
helpful when you can provide a backtrace with your bug report
to help the developers pinpoint the problem. If you are using
PHP as an Apache module try something like:
<itemizedlist>
<listitem>
<para>
Stop your httpd processes
</para>
</listitem>
<listitem>
<para>
gdb httpd
</para>
</listitem>
<listitem>
<para>
Stop your httpd processes
</para>
</listitem>
<listitem>
<para>
> run -X -f /path/to/httpd.conf
</para>
</listitem>
<listitem>
<para>
Then fetch the URL causing the problem with your browser
</para>
</listitem>
<listitem>
<para>
> run -X -f /path/to/httpd.conf
</para>
</listitem>
<listitem>
<para>
If you are getting a core dump, gdb should inform you of this now
</para>
</listitem>
<listitem>
<para>
type: bt
</para>
</listitem>
<listitem>
<para>
You should include your backtrace in your bug report. This should be
submitted to
<ulink url="&faqurl.php.bugs;">&faqurl.php.bugs;</ulink>
</para>
</listitem>
</itemizedlist>
</para>
<para>
If your script uses the regular expression functions
(<function>ereg</function> and friends), you should make sure
that you compiled PHP and Apache with the same regular
expression package. This should happen automatically with
PHP and Apache 1.3.x
</para>
</answer>
</qandaentry>
<qandaentry id="faq.installation.processing">
<question>
<para>
Unix: I installed PHP using RPMS, but Apache isn't processing the
PHP pages! What's going on here?
</para>
</question>
<answer>
<para>
Assuming you installed both Apache and PHP from RPM packages,
you need to uncomment or add some or all of the following lines
in your <filename>http.conf</filename> file:
<programlisting>
# Extra Modules
AddModule mod_php.c
AddModule mod_php3.c
AddModule mod_perl.c
# Extra Modules
LoadModule php_module modules/mod_php.so
LoadModule php3_module modules/libphp3.so /* for PHP 3 */
LoadModule php4_module modules/libphp4.so /* for PHP 4 */
LoadModule perl_module modules/libperl.so
</programlisting>
And add:
<programlisting>
AddType application/x-httpd-php3 .php3 /* for PHP 3 */
AddType application/x-httpd-php .php /* for PHP 4 */
</programlisting>
... to the global properties, or to the properties of the
VirtualDomain you want to have PHP support added to.
</para>
</answer>
</qandaentry>
<qandaentry id="faq.installation.compile">
<question>
<para>
Unix: I installed PHP 3 using RPMS, but it doesn't compile with
the database support I need! What's going on here?
</para>
</question>
<answer>
<para>
Due to the way PHP 3 built, it is not easy to build a
complete flexible PHP RPM. This issue is addressed in PHP 4.
For PHP 3, we currently suggest you use the mechanism described in the
INSTALL.REDHAT file in the PHP distribution. If you insist on using
an RPM version of PHP 3, read on...
</para>
<para>
The RPM packagers are setting up the RPMS to install
without database support to simplify installations <emphasis>and</emphasis>
because RPMS use /usr/ instead of the standard /usr/local/ directory for
files. You need to tell the RPM spec file which databases to support
and the location of the top-level of your database server.
</para>
<para>
This example will explain the process of adding support for the
popular MySQL database server, using the mod installation for Apache.
</para>
<para>
Of course all of this information can be adjusted for any database
server that PHP supports. We will assume you installed MySQL and Apache
completely with RPMS for this example as well.
<itemizedlist>
<listitem>
<para>
First remove mod_php3 :
<programlisting>
rpm -e mod_php3
</programlisting>
</para>
</listitem>
<listitem>
<para>
Then get the source rpm and INSTALL it, NOT --rebuild
<programlisting>
rpm -Uvh mod_php3-3.0.5-2.src.rpm
</programlisting>
</para>
</listitem>
<listitem>
<para>
Then edit the <filename>/usr/src/redhat/SPECS/mod_php3.spec</filename>
file
</para>
<para>
In the %build section add the database support you want, and the path.
</para>
<para>
For MySQL you would add
<programlisting>
--with-mysql=/usr \
</programlisting>
The %build section will look something like this:
<programlisting>
./configure --prefix=/usr \
--with-apxs=/usr/sbin/apxs \
--with-config-file-path=/usr/lib \
--enable-debug=no \
--enable-safe-mode \
--with-exec-dir=/usr/bin \
--with-mysql=/usr \
--with-system-regex
</programlisting>
</para>
</listitem>
<listitem>
<para>
Once this modification is made then build the binary rpm as follows:
<programlisting>
rpm -bb /usr/src/redhat/SPECS/mod_php3.spec
</programlisting>
</para>
</listitem>
<listitem>
<para>
Then install the rpm
<programlisting>
rpm -ivh /usr/src/redhat/RPMS/i386/mod_php3-3.0.5-2.i386.rpm
</programlisting>
</para>
</listitem>
</itemizedlist>
Make sure you restart Apache, and you now have PHP 3 with MySQL support
using RPM's. Note that it is probably much easier to just build
from the distribution tarball of PHP 3 and follow the instructions in
<filename>INSTALL.REDHAT</filename> found in that distribution.
</para>
</answer>
</qandaentry>
<qandaentry id="faq.installation.frontpage">
<question>
<para>
Unix: I patched Apache with the FrontPage extensions patch, and
suddenly PHP stopped working. Is PHP incompatible with the
Apache FrontPage extensions?
</para>
</question>
<answer>
<para>
No, PHP works fine with the FrontPage extensions. The problem
is that the FrontPage patch modifies several Apache structures,
that PHP relies on. Recompiling PHP (using 'make clean ; make')
after the FP patch is applied would solve the problem.
</para>
</answer>
</qandaentry>
<qandaentry id="faq.installation.blankscreen">
<question>
<para>
Unix/Windows: I have installed PHP, but when I try to
access a PHP script file via my browser, I get a blank screen.
</para>
</question>
<answer>
<para>
Do a 'view source' in the web browser and you will probably
find that you can see the source code of your PHP script.
This means that the web server did not send the script to
PHP for interpretation. Something is wrong with the server
configuration - double check the server configuration against
the PHP installation instructions.
</para>
</answer>
</qandaentry>
<qandaentry id="faq.installation.500error">
<question>
<para>
Unix/Windows: I have installed PHP, but when try to
access a PHP script file via my browser, I get a
server 500 error.
</para>
</question>
<answer>
<para>
Something went wrong when the server tried to run PHP. To
get to see a sensible error message, from the command line,
change to the directory containing the PHP executable
(<filename>php.exe</filename> on Windows) and run
<literal>php -i</literal>. If PHP has any problems running,
then a suitable error message will be displayed which will
give you a clue as to what needs to be done next. If you
get a screen full of html codes (the output of the
<function>phpinfo</function> function) then PHP is working,
and your problem may be related to your server configuration
which you should double check.
</para>
</answer>
</qandaentry>
<qandaentry id="faq.installation.undefinedsyms">
<question>
<para>
Some operating systems: I have installed PHP without errors,
but when I try to start apache I get undefined symbol errors:
<programlisting>
[mybox:user /src/php4] root# apachectl configtest
apachectl: /usr/local/apache/bin/httpd Undefined symbols:
_compress
_uncompress
</programlisting>
</para>
</question>
<answer>
<para>
This has actually nothing to do with PHP, but with the MySQL
client libraries. Some need --with-zlib, others do not. This
is also covered in the MySQL FAQ.
</para>
</answer>
</qandaentry>
<qandaentry id="faq.installation.cgierror">
<question>
<para>
Windows: I have installed PHP, but when I to access
a PHP script file via my browser, I get the error:
<programlisting>
cgi error:
The specified CGI application misbehaved by not
returning a complete set of HTTP headers.
The headers it did return are:
</programlisting>
</para>
</question>
<answer>
<para>
This error message means that PHP failed to output anything
at all. To get to see a sensible error message, from the
command line, change to the directory containing the PHP
executable (<filename>php.exe</filename> on Windows) and run
<literal>php -i</literal>. If PHP has any problems running,
then a suitable error message will be displayed which will
give you a clue as to what needs to be done next. If you
get a screen full of html codes (the output of the
<function>phpinfo</function> function) then PHP is working.
</para>
<para>
Once PHP is working at the command line, try accessing the
script via the browser again. If it still fails then it
could be one of the following:
</para>
<itemizedlist>
<listitem>
<simpara>
File permissions on your PHP script,
<filename>php.exe</filename>, <filename>php4ts.dll</filename>,
<filename>php.ini</filename> or any PHP extensions you are
trying to load are such that the anonymous internet user
<literal>ISUR_<machinename></literal> cannot access them.
</simpara>
</listitem>
<listitem>
<simpara>
The script file does not exist (or possibly isn't where you
think it is relative to your web root directory). Note that
for IIS you can trap this error by ticking the 'check file
exists' box when setting up the script mappings in the
Internet Services Manager. If a script file does not exist
then the server will return a 404 error instead. There is
also the additional benefit that IIS will do any
authentication required for you based on the NTLanMan
permissions on your script file.
</simpara>
</listitem>
</itemizedlist>
</answer>
</qandaentry>
<qandaentry id="faq.install.phpandiis">
<question>
<para>
Windows: I've followed all the instructions, but still can't
get PHP and IIS to work together!
</para>
</question>
<answer>
<para>
Make sure any user who needs to run a PHP script has the rights
to run <filename>php.exe</filename>! IIS uses an anonymous user
which is added at the time IIS is installed. This user needs
rights to <filename>php.exe</filename>. Also, any authenticated
user will also need rights to execute <filename>php.exe</filename>.
And for IIS4 you need to tell it that PHP is a script engine.
</para>
</answer>
</qandaentry>
</qandaset>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"../manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
-->
