History: ISPConfig
Source of version: 44 (current)
Copy to clipboard
! ISPConfig
ISPConfig is an open source hosting control panel for Linux which is capable of managing multiple servers from one control panel. ISPConfig is licensed under the BSD license.
http://www.ispconfig.org/
This page is the document optimal configuration for Tiki. For general info about ISPConfig, please link to ispconfig.org
!!# Create a Client
* As admin, create a client.
You can use a predefined template (or create a new client-template first). {REMARKSBOX(type="note" title="Please Note")}It seems ISPConfig allows to omit that and then there is sort-of default client0 but that can cause troubles later with databases e.g. so yes please, create one.{REMARKSBOX}
!!# Create a web space
* Create a website for that client. You need to have a client first, if you don't have one already.
** Go to tab "sites", create a Website.
!!# Create a DB
Create a database user first: "__Sites > Databases : Database Users > Add new User__"
{img src="display815" link="display815" width="400" rel="box[g]" imalign="center" desc="Click to expand" align="center" styleimage="border"}
Then, add a database: "__Sites > Databases : Databases > Add new Database__"
{img src="display816" link="display816" width="400" rel="box[g]" imalign="center" desc="Click to expand" align="center" styleimage="border"}
!!# Adding JailRoot SSH users
* And making sure they have access to SVN
The client needs to have the option ssh-chroot option set to "Jailkit" mode.
Log in as a client (if permissions are granted for such task), or as ISPConfig admin, and go to "__Sites > Command line > Shell user > Add new Shell-user__"
!!# Installing Tiki
Get your tiki as usual. See, for instance:
http://dev.tiki.org/Get+code
In this example, we will consider that you have fetched Tiki9 LTS into the folder
{CODE()}
/home/xavi/tiki09svn
{CODE}
!!# PHP Tweaks
Remember that most php modes in ISP Config do not allow tweaking php options in a .htaccess, but they need to be set on a per-directory php.ini file. See the ISP config manual for more information.
In case you want to change some settings for all your sites, like rising the minimum upload size in php for all sizes, you can edit:
{CODE(colors="shell", caption="command server side to edit your default php.ini settings for all sites")}
pico /etc/php5/cgi/php.ini
{CODE}
And change these two settings
{CODE()}
upload_max_filesize 12M
post_max_size 10M
{CODE}
!!# Backups
You can setup that per site, at: "__Sites > Websites : Website > Add new website__ (or edit a previous one by clicking on its name in the list)", and go to the tab "backup":
{img src="display817" link="display817" width="400" rel="box[g]" imalign="center" desc="Click to expand" align="center" styleimage="border"}
!!!# Paths inside and outside the chrooted environment
New sites are associated with clients, and some ssh users can be created associated with that client and site.
ssh users have their chrooted environents in this absolute path in the server:
{CODE()}
/var/www/clients/clientN/webM/
{CODE}
For instance, for the test case of the tiki01 site (http://tiki01.example.com) for user 'john', client 'smith' is #1 (N in hte path above), ssh user smithjohn, and the website is #8 (M in the path above). Therefore, his website will be here:
{CODE()}
/var/www/clients/client1/web8/
{CODE}
And when he logs in through ssh, he will be at the apparentpath for him:
{CODE()}
/home/smithjohn/
{CODE}
His website http://tiki01.example.com will be initially fed with the contents at the file (chrooted, apparently absolute path for him):
{CODE()}
/web/index.html
{CODE}
Which in fact, will be the real paths at the server for his home directory and website are:
{CODE()}
/var/www/clients/client1/web8/home/smithjohn/
/var/www/clients/client1/web8/web/index.html
{CODE}
!!# Multitiki setup and permissions
Which permissions does the web folder have by default for a site?
For instance, web8 from client 1 will have these permissions at the web folder by default:
{CODE(colors="scss")}
root@server:/var/www/clients/client1/web8# ls -l
total 24
drwxr-xr-x 2 web8 client1 4096 abr 8 08:51 cgi-bin
drwxr-xr-x 2 root root 4096 abr 8 08:51 log
drwx--x--- 2 web8 client1 4096 abr 8 08:51 private
drwxr-xr-x 2 root root 4096 abr 8 08:51 ssl
drwxrwx--- 2 web8 client1 4096 abr 8 08:51 tmp
drwx--x--- 4 web8 client1 4096 abr 8 08:51 web
drwx--x--- 2 web8 client1 4096 abr 8 08:51 webdav
{CODE}
If you check the attributes of those folders, they all seem ok:
{CODE(colors="shell")}
root@server:/var/www/clients/client1/web8# lsattr
---------------- ./private
---------------- ./cgi-bin
---------------- ./log
---------------- ./ssl
---------------- ./web
---------------- ./tmp
---------------- ./webdav
{CODE}
However, if you check the attributes of the parent folder web8, you will see that it has the immutable bit enabled:
{CODE(colors="shell")}
root@server:/var/www/clients/client1# lsattr
(...)
----i----------- ./web8
(...)
{CODE}
Therefore, you need to change that immutable bit attribute, in order to be able to remove the web subfolder and replace it with a symlink to the multitiki installation.
Do these steps:
# remove the default initial web folder
** if you can't remove it as root, try removing the attribute "immutable" that you might have set in the parent folder ( -+/var/www/clients/client1/web8/+- ), with this command:
++ {CODE()}
sudo chattr -i /var/www/clients/client1/web8/
{CODE}
** Then proceed to remove the web subfolder
++ {CODE()}
sudo rm /var/www/clients/client1/web8/web/* -R
sudo rmdir /var/www/clients/client1/web8/web/
{CODE}
# create a symlink from the multitiki installation to that web folder.
** If the multitiki installation is at: -+/var/www/multitiki/+-, then run:
++ {CODE(colors="bash")}
sudo ln -s /var/www/multitiki/ /var/www/clients/client1/web8/web/
{CODE}
# Set the attributes back for the parent folder, if you changed them
** if you removed the attribute "immutable" for the parent folder, set it back, with this command:
++ {CODE()}
sudo chattr +i /var/www/clients/client1/web8/
{CODE}
# run -+sh setup.sh+- on the multitiki base folder, so that
** you indicate as user -+www-data+-,
** but as group: -+client1+- instead of the default www-data.
** As sites, provide your domains for each tiki in the multitiki install: site1.example.com, site2.example.com, ...
# Then you can proceed with the installation of your tiki at each domain, as usual.
!!# Where to store files outside the web root
See below "__Open_basedir restrictions for storing uploaded files on disk__"
Or add an .htaccess to avoid browsing
!!# Open_basedir restrictions for storing uploaded files on disk
If you plan to setup file galleries, wiki attachments, tracker file uploads, etc., to use storage on disk instead of in database, then you are recommended to indicate a subfolder with the base path __private__ of the site folder, with the absolute path:
{CODE()}
/var/www/clients/client1/web8/private/
{CODE}
Therefore, for file galleries, we could use the folder "tiki_file_gals", with an ending slash, and therefore, the absolute path would be:
{CODE()}
/var/www/clients/client1/web8/private/tiki_file_gals/
{CODE}
This seems to be necessary to comply with the few open_basedir folders allowed by ISPConfig.
Alternatively, you could add new folders to the PHP open_basedir param in the ISPConfig Admin Panel: "__ISPConfig > Sites > (click on a web site name) > Options (tab) > PHP open_basedir__"
{img fileId="911" thumb="y" rel="box[g]" width="400" imalign="center" desc="Click to expand" align="center" styleimage="border"}
Permissions of the folders and files under this folder can be set to 750 for user web8 and client1, following with the previous example.
{CODE(colors="scss")}
drwxr-x--- 8 web8 client1 4096 des 12 17:06 tiki_file_gals/
{CODE}
But if you plan to setup several sites based on a multitiki install, and having two different sites (different domains, and site folders on disk, except that web folder will be a symplink to the real multitki installation, etc), then you have to set permissions of the -+tiki_file_gals+- and subfolders to 770 for user web8 and client1, following with the previous example. The second site could be web9 and client1, and since both have the same client (unix group), you have to set that the group can write to those folders (and that's why the second 7 in 770, or rwx for group instead of r-x).
{CODE(colors="scss")}
drwxrwx--- 8 web8 client1 4096 des 12 17:06 tiki_file_gals/
{CODE}
!!# Fix 'No input file specified.' from web sites in subfolders of a previous site
If the website to be allowed in a subfolder of another one, is a symlink to another folder in the different path, you need to add that other path in the Open_Basedir directive of PHP. You can do so thorugh the ISP_Config interface for that parent website (mysite.example.com, in this case) which hosts a web site in a subfolder (mysite.com/mysubsite/ for instance), because -+mysubsite+- is a symlink to -+/var/www/tiki12svnfarm_subdir+- .
In this case, we had to add: __/var/www/tiki12svnfarm_subdir:__ to __PHP open_basedir__ parameter for the site mysite.example.com:
{img src="display1249" link="display1249" width="400" rel="box[g]" imalign="center" desc="Click to expand" align="center" styleimage="border"}
Another approach, if the site is not in a multitiki installation, like the mrbs (for the mysite.example.com/bookings/ ) is to move the external file tree inside the path of the parent site, so that you avoid using symlinks. this way, no need to tweak the open base dir directive.
!!# ISPConfig Manual Notes
!!!-# Documentation pages about jailrooted ssh users
Rellevant pages at the current manual (ISPconfig v3.0.5.2),
* p103: (Limits)
** SSH-Chroot Options: Specify which SSH modes should be available for the reseller when he creates/modifies a shell account. The None mode means that the shell user can browse the whole file system and is limited only by file/directory permissions - this can be a security risk. The Jailkit mode means that the shell user will be limited to his home directory (chrooted) and can only browse directories inside his home directory
* p139-143: 4.6.4. Command Line > 4.6.4.1. Shell-User:
+ "To create a new shell user, click the Add new Shell-User button. This will lead you to the Shell User form with the tabs Shell User and Options."
+ ...
* p235: JailKit (configuration)
!!# Adding Tiki to Client Websites
For instance, to copy the svn installation of tiki12 under the user 'xavi' home folder over the website of a client (lets say: client1 (smith) web8 (john) (i.e. http://tiki01.example.com ), you can do that with:
{CODE(colors="shell")}
xavi@r:~# sudo su
root@r:~# cd /home/xavi/tiki12svn
root@r:~/tiki12svn# svn export --force . /var/www/clients/client1/web8/web/
Export complete.
root@r:~/tiki12svn# cd /var/www/clients/client1/web8/web/
root@r:/var/www/clients/client1/web8/web# mv .htaccess .htaccess_old
root@r:/var/www/clients/client1/web8/web# cp _htaccess .htaccess
root@r:/var/www/clients/client1/web8/web# sh setup.sh
User [www-data]: web8
> Group [www-data]: client1
> Multi []:
Checking dirs :
db ... ok.
dump ... ok.
img/wiki ... ok.
img/wiki_up ... ok.
img/trackers ... ok.
modules/cache ... ok.
temp ... ok.
temp/cache ... ok.
temp/public ... ok.
templates_c ... ok.
templates ... ok.
styles ... ok.
maps ... ok.
whelp ... ok.
mods ... Creating directory ok.
files ... ok.
tiki_tests/tests ... ok.
temp/unified-index ... Creating directory ok.
Fix global perms ...
Change user to web8 and group to client1... done.
Fix normal dirs ... done.
Fix special dirs ... done.
{CODE}
The force option is needed since the destination folder already exists.
And the svn export is preferred (if no svn is needed) because of the space savings reducing it down to aprox. 40% of the initial size on disk (As a simple reference, 453 Mb for the svn-enabled version of tiki09svn, 181 Mb for the non-svn-enabled version).
At this point, the client user can proceed with the installation of Tiki as usual through the web interface that he will see when he goes to his website url; in this example: http://tiki01.example.com
{img src="display818" link="display818" width="500" rel="box[g]" imalign="center" desc="Click to expand" align="center" styleimage="border"}
Later on in step4 of the installation, he will need to provide the db credentials that were create for him in earlier step by the ispconfig admin (see above; in this example, db name: c1tiki01, db user: c1tiki01, and the db password you used at that step).
!!# Grant SVN to chrooted users
Run this:
{CODE(colors="shell")}
root@server:/# jk_cp /var/www/clients/client1/web8 /usr/bin/svn
{CODE}
Some users have reported to get error messages reporting that some folders are not owned by root:root, like this one below,
{CODE(colors="shell")}
ERROR: /var/www/clients/client1/web8/etc is not owned by root:root!
{CODE}
In such case, the problem was solved by changing ownership to root for these folders like etc, and running the first command jk_cp again:
{CODE(colors="shell", ln="1")}
root@server:/var/www/clients/client1/web8# chown -R root:root etc usr var bin dev
root@server:/var/www/clients/client1/web8# jk_cp /var/www/clients/client1/web8 /usr/bin/svn
Copying /usr/bin/svn to /var/www/clients/client1/web8/usr/bin/svn
Creating symlink /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1 to libsvn_client-1.so.1.0.0
Copying /usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1.0.0 to /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1.0.0
Creating symlink /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_wc-1.so.1 to libsvn_wc-1.so.1.0.0
Copying /usr/lib/x86_64-linux-gnu/libsvn_wc-1.so.1.0.0 to /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_wc-1.so.1.0.0
Creating symlink /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_ra-1.so.1 to libsvn_ra-1.so.1.0.0
Copying /usr/lib/x86_64-linux-gnu/libsvn_ra-1.so.1.0.0 to /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_ra-1.so.1.0.0
Creating symlink /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_delta-1.so.1 to libsvn_delta-1.so.1.0.0
Copying /usr/lib/x86_64-linux-gnu/libsvn_delta-1.so.1.0.0 to /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_delta-1.so.1.0.0
Creating symlink /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_diff-1.so.1 to libsvn_diff-1.so.1.0.0
Copying /usr/lib/x86_64-linux-gnu/libsvn_diff-1.so.1.0.0 to /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_diff-1.so.1.0.0
Creating symlink /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_subr-1.so.1 to libsvn_subr-1.so.1.0.0
Copying /usr/lib/x86_64-linux-gnu/libsvn_subr-1.so.1.0.0 to /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_subr-1.so.1.0.0
Creating symlink /var/www/clients/client1/web8/usr/lib/libapr-1.so.0 to libapr-1.so.0.4.6
Copying /usr/lib/libapr-1.so.0.4.6 to /var/www/clients/client1/web8/usr/lib/libapr-1.so.0.4.6
Creating symlink /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_ra_local-1.so.1 to libsvn_ra_local-1.so.1.0.0
Copying /usr/lib/x86_64-linux-gnu/libsvn_ra_local-1.so.1.0.0 to /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_ra_local-1.so.1.0.0
Creating symlink /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_ra_svn-1.so.1 to libsvn_ra_svn-1.so.1.0.0
Copying /usr/lib/x86_64-linux-gnu/libsvn_ra_svn-1.so.1.0.0 to /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_ra_svn-1.so.1.0.0
Creating symlink /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_ra_neon-1.so.1 to libsvn_ra_neon-1.so.1.0.0
Copying /usr/lib/x86_64-linux-gnu/libsvn_ra_neon-1.so.1.0.0 to /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_ra_neon-1.so.1.0.0
Creating symlink /var/www/clients/client1/web8/usr/lib/libaprutil-1.so.0 to libaprutil-1.so.0.3.12
Copying /usr/lib/libaprutil-1.so.0.3.12 to /var/www/clients/client1/web8/usr/lib/libaprutil-1.so.0.3.12
Creating symlink /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsqlite3.so.0 to libsqlite3.so.0.8.6
Copying /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6 to /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
Creating symlink /var/www/clients/client1/web8/lib/x86_64-linux-gnu/libuuid.so.1 to libuuid.so.1.3.0
Copying /lib/x86_64-linux-gnu/libuuid.so.1.3.0 to /var/www/clients/client1/web8/lib/x86_64-linux-gnu/libuuid.so.1.3.0
Creating symlink /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_repos-1.so.1 to libsvn_repos-1.so.1.0.0
Copying /usr/lib/x86_64-linux-gnu/libsvn_repos-1.so.1.0.0 to /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_repos-1.so.1.0.0
Creating symlink /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_fs-1.so.1 to libsvn_fs-1.so.1.0.0
Copying /usr/lib/x86_64-linux-gnu/libsvn_fs-1.so.1.0.0 to /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_fs-1.so.1.0.0
Creating symlink /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsasl2.so.2 to libsasl2.so.2.0.25
Copying /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25 to /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25
Creating symlink /var/www/clients/client1/web8/usr/lib/libneon-gnutls.so.27 to libneon-gnutls.so.27.2.6
Copying /usr/lib/libneon-gnutls.so.27.2.6 to /var/www/clients/client1/web8/usr/lib/libneon-gnutls.so.27.2.6
Creating symlink /var/www/clients/client1/web8/lib/x86_64-linux-gnu/libcrypt.so.1 to libcrypt-2.15.so
Copying /lib/x86_64-linux-gnu/libcrypt-2.15.so to /var/www/clients/client1/web8/lib/x86_64-linux-gnu/libcrypt-2.15.so
Creating symlink /var/www/clients/client1/web8/lib/x86_64-linux-gnu/libexpat.so.1 to libexpat.so.1.5.2
Copying /lib/x86_64-linux-gnu/libexpat.so.1.5.2 to /var/www/clients/client1/web8/lib/x86_64-linux-gnu/libexpat.so.1.5.2
Creating symlink /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_fs_fs-1.so.1 to libsvn_fs_fs-1.so.1.0.0
Copying /usr/lib/x86_64-linux-gnu/libsvn_fs_fs-1.so.1.0.0 to /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_fs_fs-1.so.1.0.0
Creating symlink /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_fs_base-1.so.1 to libsvn_fs_base-1.so.1.0.0
Copying /usr/lib/x86_64-linux-gnu/libsvn_fs_base-1.so.1.0.0 to /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_fs_base-1.so.1.0.0
Creating symlink /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_fs_util-1.so.1 to libsvn_fs_util-1.so.1.0.0
Copying /usr/lib/x86_64-linux-gnu/libsvn_fs_util-1.so.1.0.0 to /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libsvn_fs_util-1.so.1.0.0
Copying /usr/lib/x86_64-linux-gnu/libdb-4.8.so to /var/www/clients/client1/web8/usr/lib/x86_64-linux-gnu/libdb-4.8.so
root@server:/var/www/clients/client1/web8#
{CODE}
!!# PHP modes
PHP-FCGI is the default PHP mode used in ISPConfig3 admin panels. But you can change it to other PHP modes if desired.
{img fileId="939" thumb="y" rel="box[g]" width="600" imalign="center" desc="Click to expand" align="center" styleimage="border"}
The other PHP modes are:
* FastCGI
* CGI
* Mod-PHP
* SuPHP
* PHP-FPM
We'll show how to fix some usual errors with some of them.
!!!# Using PHP mode PHP-FCGI
!!!!# Error 500 in PHP mode PHP-FCGI: Allow uploading bigger files than 1Mb
If you hit error 500 when attempting to upload files bigger than 1 Mb, and error.log shows something like:
{CODE()}
mod_fcgid: HTTP request length 131665 (so far) exceeds MaxRequestLen
{CODE}
then you need to increase this directive in your vhost, to something like 2MB (131Kb by default)
{CODE()}
FcgidMaxRequestLen 2000000
{CODE}
More in:
http://www.howtoforge.com/apache2-mod_fcgid-http-request-length-exceeds-maxrequestlen
!!!# Using PHP mode PHP-FPM
You might want to use another PHP mode for your website. For instance, PHP-FPM (FastCGI Process Manager), which is an alternative PHP FastCGI implementation with some additional features useful for sites of any size, especially busier sites..
According to the ISPConfig3 pdf manual, you need to install these packages:
{CODE(colors="shell", ln="1", caption="Commands in a terminal")}
sudo apt-get install php5-fpm
sudo /etc/init.d/php5-fpm restart
sudo apt-get install fcgiwrap
{CODE}
!!!!# Error 500 in PHP mode PHP-FPM: File is not in document root of Vhost
You may choose another PHP mode for your site. For instance, suPHP, or PHP-FPM. In such case, some features like replacing a file in a file gallery might produce this type of error 500:
{CODE()}
root@example:/# tail /var/log/ispconfig/httpd/mysite.example.com/error.log
(...)
SoftException in Application.cpp:221: File "/var/www/c1tiki12farm/tiki-list_file_gallery.php" is not in document root of Vhost "/var/www/clients/client1/web6/web", referer: http://example.com/tiki-list_file_gallery.php
{CODE}
As indicated [http://www.crazysquirrel.com/computing/debian/servers/ubuntu-mail-server.jspx|here], the solution to this is to pop open the suphp config file (/etc/suphp/suphp.conf) and tell it to stop checking that scripts are under the document root like this:
{CODE(caption="File edited: /etc/suphp/suphp.conf")}
check_vhost_docroot=false
{CODE}
And restart Apache.
{CODE()}
sudo service apache2 restart
{CODE}
You will get then this other error when visiting any url of the tiki site:
{CODE()}
root@example:/# tail /var/log/ispconfig/httpd/mysite.example.com/error.log
(...)
SoftException in Application.cpp:350: UID of script "/var/www/clients/client1/web6/web/tiki-list_file_gallery.php" is smaller than min_uid
Premature end of script headers: tiki-list_file_gallery.php
{CODE}
As indicated [http://www.crazysquirrel.com/computing/debian/servers/ubuntu-mail-server.jspx|here], Suphp, by default, won't allow any scripts to run with a user or group ID under 100. Since Tiki has all its files installed owned by the user www-data (UID 33) when it's installed, this poses quite a problem. One solution is to set the min_uid and min_gid values in the suphp config file to 33 which allows the scripts to run as www-data.
{CODE(caption="File edited: /etc/suphp/suphp.conf")}
; Minimum UID
;min_uid=100
min_uid=33
; Minimum GID
;min_gid=100
min_gid=33
{CODE}
Restart Apache, and you'll be able to replace files in file galleries again.
!!!! Errors
!!!!# Unsolved error: Handler for (null) returned invalid result code 70007/14
These errors are produced on some pages in one ISPConfig3-powered Tiki 12.x site, on intervals, and it doesn't seem an easily reproducible scenario to reproduce the errors:
{CODE()}
Handler for (null) returned invalid result code 70007
{CODE}
or
{CODE()}
Handler for (null) returned invalid result code 70014
{CODE}
Looking at the apache log, they seem to be triggered by tiki-register.php (when we had real users attempting to register to a course site), and edits to simple pages:
{CODE()}
tiki-editpage.php?page=Session%2018&page_ref_id=860
tiki-editpage.php?page=Students
{CODE}
Those wiki pages contain some plugins, but they have been edited dozens of times, in a server without ISPConfig3, and in Tiki versions <= 11.x, and they never produced an error 500.
PHP mode for that site is PHP-FPM.
Googlging for these type of errors, nothing conclusive was found; just this type of information (e.g., from [http://serverfault.com/questions/231331/handler-for-null-returned-invalid-result-code-70007-causing-error-500|here]):
{QUOTE()}
7 is "time up" and 14 is "EOF", so the root cause of this is probably a read timeout during the upload.
The 70000 prefix means they are APR status codes.
They are logged poorly here because they the core of apache is expecting a different type of error code then what is returned -- these are APR or "filter" return codes but the core of httpd is expecting a HTTP status code or 0 for OK.
{QUOTE}
The most odd, is that, just waiting 5 minutes or so, and doing an F5 (browser refresh) of that edition of a wiki page, produced a normal output: page edited saved and shown, with no issues at all.
So something related to server load? Internal Timeout? ...
Hints welcome at xavi (a) tiki.org
Alias names for this page:
(alias(ISPConfig3))