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

1.1. Create a Client

  • As admin, create a client.
You can use a predefined template (or create a new client-template first).
 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.

1.2. 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.

1.3. Create a DB

Create a database user first: "Sites > Databases : Database Users > Add new User"

Click to expand
Click to expand


Then, add a database: "Sites > Databases : Databases > Add new Database"

Click to expand
Click to expand


1.4. 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"

1.5. 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

Copy to clipboard
/home/xavi/tiki09svn

1.6. 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:

command server side to edit your default php.ini settings for all sites
Copy to clipboard
pico /etc/php5/cgi/php.ini


And change these two settings

Copy to clipboard
upload_max_filesize 12M post_max_size 10M


1.7. 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":

Click to expand
Click to expand


1.7.1. 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:

Copy to clipboard
/var/www/clients/clientN/webM/


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:

Copy to clipboard
/var/www/clients/client1/web8/


And when he logs in through ssh, he will be at the apparentpath for him:

Copy to clipboard
/home/smithjohn/


His website http://tiki01.example.com will be initially fed with the contents at the file (chrooted, apparently absolute path for him):

Copy to clipboard
/web/index.html


Which in fact, will be the real paths at the server for his home directory and website are:

Copy to clipboard
/var/www/clients/client1/web8/home/smithjohn/ /var/www/clients/client1/web8/web/index.html

1.8. 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:

Copy to clipboard
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


If you check the attributes of those folders, they all seem ok:

Copy to clipboard
root@server:/var/www/clients/client1/web8# lsattr ---------------- ./private ---------------- ./cgi-bin ---------------- ./log ---------------- ./ssl ---------------- ./web ---------------- ./tmp ---------------- ./webdav


However, if you check the attributes of the parent folder web8, you will see that it has the immutable bit enabled:

Copy to clipboard
root@server:/var/www/clients/client1# lsattr (...) ----i----------- ./web8 (...)


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:

  1. 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:
      Copy to clipboard
      sudo chattr -i /var/www/clients/client1/web8/
    • Then proceed to remove the web subfolder
      Copy to clipboard
      sudo rm /var/www/clients/client1/web8/web/* -R sudo rmdir /var/www/clients/client1/web8/web/
  2. create a symlink from the multitiki installation to that web folder.
    • If the multitiki installation is at: /var/www/multitiki/, then run:
      Copy to clipboard
      sudo ln -s /var/www/multitiki/ /var/www/clients/client1/web8/web/
  3. 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:
      Copy to clipboard
      sudo chattr +i /var/www/clients/client1/web8/
  4. 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, ...
  5. Then you can proceed with the installation of your tiki at each domain, as usual.

1.9. 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

1.10. 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:

Copy to clipboard
/var/www/clients/client1/web8/private/


Therefore, for file galleries, we could use the folder "tiki_file_gals", with an ending slash, and therefore, the absolute path would be:

Copy to clipboard
/var/www/clients/client1/web8/private/tiki_file_gals/


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"

Click to expand
Click to expand


Permissions of the folders and files under this folder can be set to 750 for user web8 and client1, following with the previous example.

Copy to clipboard
drwxr-x--- 8 web8 client1 4096 des 12 17:06 tiki_file_gals/


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).

Copy to clipboard
drwxrwx--- 8 web8 client1 4096 des 12 17:06 tiki_file_gals/

1.11. 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:

Click to expand
Click to expand


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.

1.12. ISPConfig Manual Notes

1.12.1. Documentation pages about jailrooted ssh users

[+]

1.13. 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:

Copy to clipboard
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.


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

Click to expand
Click to expand


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).

1.14. Grant SVN to chrooted users


Run this:

Copy to clipboard
root@server:/# jk_cp /var/www/clients/client1/web8 /usr/bin/svn


Some users have reported to get error messages reporting that some folders are not owned by root:root, like this one below,

Copy to clipboard
ERROR: /var/www/clients/client1/web8/etc is not owned by root:root!


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:

Copy to clipboard
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#

1.15. 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.

Click to expand
Click to expand


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.

1.15.1. Using PHP mode PHP-FCGI

1.15.1.1. 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:

Copy to clipboard
mod_fcgid: HTTP request length 131665 (so far) exceeds MaxRequestLen


then you need to increase this directive in your vhost, to something like 2MB (131Kb by default)

Copy to clipboard
FcgidMaxRequestLen 2000000


More in:
http://www.howtoforge.com/apache2-mod_fcgid-http-request-length-exceeds-maxrequestlen

1.15.2. 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:

Commands in a terminal
Copy to clipboard
sudo apt-get install php5-fpm sudo /etc/init.d/php5-fpm restart sudo apt-get install fcgiwrap


1.15.2.1. 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:

Copy to clipboard
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


As indicated 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:

File edited: /etc/suphp/suphp.conf
Copy to clipboard
check_vhost_docroot=false


And restart Apache.

Copy to clipboard
sudo service apache2 restart


You will get then this other error when visiting any url of the tiki site:

Copy to clipboard
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


As indicated 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.

File edited: /etc/suphp/suphp.conf
Copy to clipboard
; Minimum UID ;min_uid=100 min_uid=33 ; Minimum GID ;min_gid=100 min_gid=33


Restart Apache, and you'll be able to replace files in file galleries again.

Errors

1.15.2.2. 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:

Copy to clipboard
Handler for (null) returned invalid result code 70007


or

Copy to clipboard
Handler for (null) returned invalid result code 70014


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:

Copy to clipboard
tiki-editpage.php?page=Session%2018&page_ref_id=860 tiki-editpage.php?page=Students



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 here):

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.



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:
ISPConfig3