Software Installation
We've tried very hard to ensure that this software will run on commodity
hosting platforms - such as those used to host Wordpress blogs and Drupal
websites. It will run on most any Linux VPS system. Windows LAMP platforms
such as XAMPP and WAMP are not officially supported at this time - however
we welcome patches if you manage to get it working.
Be aware that this software is more than a simple web application. It is a
complex communications and content management system which more closely
resembles an email server than a web server. For reliability and performance,
messages are delivered in the background and are queued for later delivery
when sites are down. This kind of functionality requires a bit more of the
host system than the typical blog. Not every PHP/MySQL hosting provider will
be able to support Hubzilla. Many will - but please review the requirements
and confirm these with your hosting provider prior to installation. (And
preferably before entering into a long-term contract.)
If you encounter installation issues, please let us know via the issue
tracker at https://framagit.org/hubzilla where you downloaded the software.
Please be as clear as you can about your operating environment and provide as
much detail as possible about any error messages you may see, so that we can
prevent it from happening in the future. Due to the large variety of operating
systems and PHP platforms in existence we may have only limited ability to
debug your PHP installation or acquire any missing modules - but we will do
our best to solve any general code issues.
**Before you begin**
Choose a domain name or subdomain name for your server.
The software can only be installed into the root of a domain or
sub-domain, and can not be installed using alternate TCP ports. These
restrictions may be relaxed in the future, but will be inconvenient to work
with, so we still STRONGLY recommend you abide by them.
Decide if you will use SSL and obtain an SSL certificate before software
installation. You SHOULD use SSL. If you use SSL, you MUST use a
"browser-valid" certificate. You MUST NOT use self-signed certificates!
Please test your certificate prior to installation. A web tool for testing your
certificate is available at "http://www.digicert.com/help/". When visiting your
site for the first time, please use the SSL ("https://") URL if SSL is
available. This will avoid problems later. The installation routine will not
allow you to use a non browser-valid certificate.
This restriction is incorporated because public posts from you may contain
references to images on your own hub. Other members viewing their stream on
other hubs will get warnings if your certificate is not trusted by their web
browser. This will confuse many people because this is a decentralised network
and they will get the warning about your hub while viewing their own hub and
may think their own hub has an issue. These warnings are very technical and
scary to some folks, many of whom will not know how to proceed except to
follow the browser advice. This is disruptive to the community. That said, we
recognise the issues surrounding the current certificate infrastructure and
agree there are many problems, but that doesn't change the requirement.
Free "browser-valid" certificates are available from providers such as ZeroSSL,
LetsEncrypt and a few others.
If you do NOT use SSL, there may be a delay of up to a minute for the initial
install script - while we check the SSL port to see if anything responds there.
When communicating with new sites, Hubzilla always attempts connection on the
SSL port first, before falling back to a less secure connection. If you do not
use SSL, your webserver MUST NOT listen on port 443 at all.
If you use LetsEncrypt to provide certificates and create a file under
.well-known/acme-challenge so that LetsEncrypt can verify your domain
ownership, please remove or rename the .well-known directory as soon as the
certificate is generated. The software will provide its own handler for
".well-known" services when it is installed, and an existing directory in this
location may prevent some of these services from working correctly. This
should not be a problem with Apache, but may be an issue with nginx or other
web server platforms.
**Installation**
1. Requirements
- Apache with mod-rewrite enabled and "AllowOverride All" so you can use a
local .htaccess file. Some folks have successfully used nginx and lighttpd.
Example config scripts are available for these platforms in the install
directory. Apache and nginx have the most support.
- PHP 8.1 or later.
- PHP *command line* access with register_argc_argv set to true in the
php.ini file - and with no hosting provider restrictions on the use of
exec() and proc_open().
- curl, gd (with at least jpeg and png support), mysqli, mbstring, xml,
xmlreader (FreeBSD), zip, openssl, iconv, intl, sodium, bcmath (or gmp) extensions.
The imagick extension MAY be used instead of gd, but is not required and MAY also be disabled via
configuration option.
- some form of email server or email gateway such that PHP mail() works.
- MySql version >= 8.0.22 or MariaDB version >= 10.6 or PostgreSql version >= 12 database server
- ability to schedule jobs with cron.
- Installation into a top-level domain or sub-domain (without a
directory/path component in the URL) is REQUIRED.
2. Unpack the project files into the root of your web server document area.
If you copy the directory tree to your webserver, make sure that you
also copy .htaccess - as "dot" files are often hidden and aren't normally
copied.
- If you are able to do so, we recommend using git to clone the source
repository rather than to use a packaged tar or zip file. This makes the
software much easier to update. The Linux command to clone the repository
into a directory "mywebsite" would be
git clone https://framagit.org/hubzilla/core.git mywebsite
- and then you can pick up the latest changes at any time with
git pull
- make sure folders *store/[data]/smarty3* and *store* exist and are
writable by the webserver
mkdir -p "store/[data]/smarty3"
chmod -R 777 store
[This permission (777) is very dangerous and if you have sufficient
privilege and knowledge you should make these directories writeable
only by the webserver and, if different, the user that will run the
cron job (see below). In many shared hosting environments this may be
difficult without opening a trouble ticket with your provider. The
above permissions will allow the software to work, but are not
optimal.]
- For installing addons
- First you should be **on** your website folder
cd mywebsite
- Then you should clone the addon repository (separately). We'll give this repository
a nickname of 'hzaddons'. You can pull in other hubzilla addon repositories by
giving them different nicknames.
util/add_addon_repo https://framagit.org/hubzilla/addons.git hzaddons
- For keeping the addon tree updated, you should be on your top level website
directory and issue an update command for that repository.
cd mywebsite
util/update_addon_repo hzaddons
- Once the software is configured and the database installed, create searchable
representations of the online documentation. You may do this any time
that the documentation is updated.
cd mywebsite
util/importdoc
3. Create an empty database and note the access details (hostname, username,
password, database name). The PDO database libraries will fallback to socket
communication if the hostname is 'localhost' and some people have reported
issues with the socket implementation. Use it if your requirements mandate.
Otherwise if the database is served on the local server, use '127.0.0.1' for
the hostname.
Internally we now use the PDO library for database connections. If you
encounter a database configuration which cannot be expressed on the setup form
(for instance using MySQL with an unusual socket location); you can supply
the PDO connection string as the database hostname. For instance
:/path/to/socket.file
You should still fill in all other applicable form values as needed.
4. If you know in advance that it will be impossible for the web server to
write or create files in your web directory, create an empty file called
.htconfig.php and make it writable by the web server.
5. Visit your website with a web browser and follow the instructions. Please
note any error messages and correct these before continuing. If you are using
SSL with a known signature authority, use the https: link to your
website.
6. *If* the automated installation fails for any reason, check the following:
- ".htconfig.php" exists
If not, edit htconfig.php and change system settings. Rename
to .htconfig.php
- Database is populated.
If not, import the contents of "install/schema_xxxxx.sql" with phpmyadmin
or mysql command line (replace 'xxxxx' with your DB type).
7. At this point visit your website again, and register your personal account.
Registration errors should all be recoverable automatically.
If you get any *critical* failure at this point, it generally indicates the
database was not installed correctly. You might wish to move/rename
.htconfig.php to another name and empty (called 'dropping') the database
tables, so that you can start fresh.
In order for your account to be given administrator access, it should be the
first account created, and the email address provided during registration
must match the "administrator email" address you provided during
installation. Otherwise to give an account administrator access,
add 4096 to the account_roles for that account in the database.
For your site security there is no way to provide administrator access
using web forms.
****************************************************************************
****************************************************************************
******** THIS NEXT STEP IS IMPORTANT!!!! ***********
****************************************************************************
****************************************************************************
8. Set up a cron job or scheduled task to run the Cron manager once every 10-15
minutes to perform background processing and maintenance. Example:
cd /base/directory; /path/to/php Zotlabs/Daemon/Master.php Cron
Change "/base/directory", and "/path/to/php" as appropriate for your situation.
If you are using a Linux server, run "crontab -e" and add a line like the
one shown, substituting for your unique paths and settings:
*/10 * * * * cd /home/myname/mywebsite; /usr/bin/php Zotlabs/Daemon/Master.php Cron > /dev/null 2>&1
You can generally find the location of PHP by executing "which php". If you
have troubles with this section please contact your hosting provider for
assistance. Hubzilla will not work correctly if you cannot perform this step.
You should also be sure that App::$config['system']['php_path'] is set correctly
in your .htconfig.php file, it should look like (changing it to the correct
PHP location):
App::$config['system']['php_path'] = '/usr/local/php80/bin/php';
#####################################################################
If things don't work...
#####################################################################
#####################################################################
- If you get the message
"System is currently unavailable. Please try again later"
#####################################################################
Check your database settings. It usually means your database could not be
opened or accessed. If the database resides on the same machine, check that
the database server name is "127.0.0.1" or the word "localhost".
#####################################################################
- 500 Internal Error
#####################################################################
This could be the result of one of our Apache directives not being
supported by your version of Apache. Examine your apache server logs.
Also check your file permissions. Your website and all contents must generally
be world-readable.
It is likely that your web server reported the source of the problem in
its error log files. Please review these system error logs to determine what
caused the problem. Often this will need to be resolved with your hosting
provider or (if self-hosted) your web server configuration.
#####################################################################
- 400 and 4xx "File not found" errors
#####################################################################
First check your file permissions. Your website and all contents must
generally be world-readable.
Ensure that mod-rewite is installed and working, and that your
.htaccess file is being used. To verify the latter, create a file test.out
containing the word "test" in the top directory of the Hubzilla, make it world
readable and point your web browser to
http://yoursitenamehere.com/test.out
This file should be blocked. You should get a permission denied message.
If you see the word "test" your Apache configuration is not allowing your
.htaccess file to be used (there are rules in this file to block access
to any file with .out at the end, as these are typically used for system logs).
Make certain the .htaccess file exists and is readable by everybody, then
look for the existence of "AllowOverride None" in the Apache server
configuration for your site. This will need to be changed to
"AllowOverride All".
If you do not see the word "test", your .htaccess is working, but it is
likely that mod-rewrite is not installed in your web server or is not working.
On most flavours of Linux,
% a2enmod rewrite
% /etc/init.d/apache2 restart
Consult your hosting provider, experts on your particular Linux
distribution or (if Windows) the provider of your Apache server software if
you need to change either of these and can not figure out how. There is
a lot of help available on the web. Google "mod-rewrite" along with the
name of your operating system distribution or Apache package.
#####################################################################
- If you see an error during database setup that DNS lookup failed
#####################################################################
This is a known issue on some versions of FreeBSD, because
dns_get_record() fails for some lookups. Create a file in your top webserver
folder called '.htpreconfig.php' and inside it put the following:
<?php
App::$config['system']['do_not_check_dns'] = 1;
This should allow installation to proceed. Once the database has been
installed, add the same config statement (but not the '<?php' line) to the
.htconfig.php file which was created during installation.
#####################################################################
- If you are unable to write the file .htconfig.php during installation
due to permissions issues:
#####################################################################
create an empty file with that name and give it world-write permission.
For Linux:
% touch .htconfig.php
% chmod 777 .htconfig.php
Retry the installation. As soon as the database has been created,
******* this is important *********
% chmod 755 .htconfig.php
#####################################################################
- Some configurations with "suhosin" security are configured without
an ability to run external processes. Hubzilla requires this ability.
Following are some notes provided by one of our members.
#####################################################################
On my server I use the php protection system Suhosin
[http://www.hardened-php.net/suhosin/]. One of the things it does is to block
certain functions like proc_open, as configured in /etc/php5/conf.d/suhosin.ini:
suhosin.executor.func.blacklist = proc_open, ...
For those sites like Hubzilla that really need these functions they can be
enabled, e.g. in /etc/apache2/sites-available/hubzilla:
<Directory /var/www/hubzilla/>
php_admin_value suhosin.executor.func.blacklist none
php_admin_value suhosin.executor.eval.blacklist none
</Directory>
This enables every function for Hubzilla if accessed via browser, but not for
the cronjob that is called via php command line. I attempted to enable it for
cron by using something like
*/10 * * * * cd /var/www/hubzilla/ && sudo -u www-data /usr/bin/php
-d suhosin.executor.func.blacklist=none -d suhosin.executor.eval.blacklist=none
-f include/poller.php
This worked well for simple test cases, but the cron job still failed with
a fatal error:
suhosin[22962]: ALERT - function within blacklist called: proc_open() (attacker
'REMOTE_ADDR not set', file '/var/www/hubzilla/boot.php', line 1341)
After a while I noticed, that include/poller.php calls further php script via
proc_open. These scripts themselves also use proc_open and fail, because they
are NOT called with -d suhosin.executor.func.blacklist=none.
So the simple solution is to put the correct parameters into .htconfig.php:
// Location of PHP command line processor
App::$config['system']['php_path'] = '/usr/bin/php -d suhosin.executor.func.blacklist=none
-d suhosin.executor.eval.blacklist=none';
This is obvious as soon as you notice that the cron uses proc_open to
execute php-scripts that also use proc_open, but it took me quite some time to
find that out. I hope this saves some time for other people using suhosin with
function blacklists.
#####################################################################
- Apache processes hanging, using as much CPU as they can
#####################################################################
This seems to happen sometimes if you use mpm_prefork and the PHP process
started by Apache cannot get database access.
Consider the following settings:
In /etc/apache2/mods-enabled/mpm_prefork.conf (Debian, path and file name
may vary depending on your OS and distribution), set
GracefulShutdownTimeout 300
This makes sure that Apache processes that are running wild will not do so
forever, but will be killed if they didn't stop five minutes after a
shutdown command was sent to the process.
If you expect high load on your server (public servers, e.g.), also make
sure that Apache will not spawn more processes than MySQL will accept
connections.
In the default Debian configuration, in
/etc/apache2/mods-enabled/mpm_prefork.conf the maximum number of workers
is set to 150:
MaxRequestWorkers 150
However, in /etc/mysql/my.cnf the maximum number of connection is set to
100:
max_connections = 100
150 workers are a lot and probably too much for small servers. However you
set those values, make sure that the number of Apache workers is smaller
than the number of connections MySQL accepts, leaving some room for other
stuff on your server that might access MySQL, and Hubzilla's poller which
needs MySQL access, too. A good setting for a medium-sized hub might be to
keep MySQL's max_connections at 100 and set mpm_prefork's
MaxRequestWorkers to 70.
Here you can read more about Apache performance tuning:
https://httpd.apache.org/docs/2.4/misc/perf-tuning.html
There are tons of scripts to help you with fine-tuning your Apache installation.
Just search with your favorite search engine 'apache fine-tuning script'.
