Navigate to your webThen 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::
There is a shell script in (``.homeinstall/hubzilla-setup.sh``) that will install $Projectname and its dependencies on a fresh installation of Debian 8.3 stable (Jessie). It should work on similar Linux systems but your results may vary.
The installation script was originally designed for a small hardware server behind your home router. However, it has been tested on several systems running Debian 8.3:
* Home-PC (Debian-8.3.0-amd64)
* Internet connection and router at home
* Mini-pc connected to your router
* USB drive for backups
* Fresh installation of Debian on your mini-pc
* Router with open ports 80 and 443 for your Debian
$Projectname can be configured in many different ways. One of the configurations available at installation is to select a 'server role'. There are currently three server roles. We highly recommend that you use 'standard' unless you have special needs.
#### Basic
The 'basic' server role is designed to be relatively simple, and it doesn't present options
or complicated features. The hub admin may configure additional features at a site level.
This role is designed for simple social networking and social network federation. Many features
which do not federate easily have been removed, including (and this is somewhat important)
"nomadic identity". You may move a channel to or from a basic server, but you may not clone
it. Once moved, it becomes read-only on the origination site. No updates of any kind will be
provided. It is recommended that after the move, the original channel be deleted - as it is
no longer useable. The data remains only in case there are issues making a copy of the data.
This role is supported by the hubzilla community.
#### Standard
The 'standard' server role is recommended for most sites. All features of the software are
available to everybody unless locked by the hub administrator. Some features will not federate
easily with other networks, so there is often an increased support burden explaining why
sharing events with Diaspora (for instance) presents a different experience on that network.
Additionally any member can enable "advanced" or "expert" features, and these may be beyond
their technical skill level. This may also result in an increased support burden.
This role is supported by the hubzilla community.
#### Pro
The 'pro' server role is primarily designed for communities which want to present a uniform
experience and be relieved of many federation support issues. In this role there is
**no federation with other networks**. Additional features **may** be provided, such
as channel ratings, premium channels, and e-commerce.
By default a channel may set a "techlevel" appropriate to their technical skill. Higher
levels provide more features. Everybody starts with techlevel 0 (similar to the 'basic'
role) where all complicated features are hidden from view. Increasing the techlevel provides
more advanced or complex features.
The hub admin may also lock individual channels or their entire site at a defined techlevel
which provides an installation with a selection of advanced features consistent with the
perceived technical skills of the members. For instance, a community for horse racing might
have a different techlevel than a community for Linux kernel developers.
This role is not supported by the hubzilla community.
Techlevels is a unique feature of Hubzilla 'pro'. It is not available in other server_roles, although it expands on the concepts introduced in $Projectname 'basic'.
We've implemented several different mechanisms in order to reduce the apparent complexity and learning curve presented to new members. At the same time, we do not wish to limit any functionality for people who are able to grasp some slightly advanced technical technical features. The first mechanism was to move several features to an optional 'Features' page where they could be enabled at will; with the default interface kept somewhat lean.
The problem we had now is that the number of features began to grow dramatically, and the Feature page is daunting in possibilities. There are also features present which probably should not be available to all members, but may be extremely useful to those with technical backgrounds.
The techlevels seeeks to remedy this by grouping features within different levels of technical ability; starting at 0 (uncomfortable with technology), and up to 5 (Unix wizard or equivalent).
When a new member registers, their account is provided a techlevel setting of 0. On the account settings page they may change this to any available level. A higher level opens more advanced features and possible interactions.
The account administrator may also lock a particular level, lock a maximum level, or change/re-arrange the features available to any level. Those with the minimum level are typically not very exploratory and are unlikely to discover the advanced modes. This is by design. Those that look around and desire more interactions will find them. In the absence of administrator defaults they may choose any level. As they look at the features available to the level in question, it is generally expected that they will discover some features are beyond their comprehension and it is hoped they will back off to a level where the interface and features are comfortable to their skill level. This is somewhat experimental at present and for that reason is not part of the 'standard' server role. The standard server role is preset to level '5', and the basic server role is preset to level '0', with no possibility of change. Members in these roles may find themselves overwhelmed or underwhelmed by the feature set and complexity.
Service classes allow you to set limits on system resources by limiting what individual
accounts can do, including file storage and top-level post limits. Define custom service
classes according to your needs in the `.htconfig.php` file. For example, create
a _standard_ and _premium_ class using the following lines:
// Service classes
App::$config['system']['default_service_class']='standard'; // this is the default service class that is attached to every new account
// configuration for parent service class
App::$config['service_class']['standard'] =
array('photo_upload_limit'=>2097152, // total photo storage limit per channel (here 2MB)
'total_identities' =>1, // number of channels an account can create
'total_items' =>0, // number of top level posts a channel can create. Applies only to top level posts of the channel user, other posts and comments are unaffected
'total_pages' =>100, // number of pages a channel can create
'total_channels' =>100, // number of channels the user can add, other users can still add this channel, even if the limit is reached
'attach_upload_limit' =>2097152, // total attachment storage limit per channel (here 2MB)
'chatters_inroom' =>20);
// configuration for teacher service class
App::$config['service_class']['premium'] =
array('photo_upload_limit'=>20000000000, // total photo storage limit per channel (here 20GB)
'total_identities' =>20, // number of channels an account can create
'total_items' =>20000, // number of top level posts a channel can create. Applies only to top level posts of the channel user, other posts and comments are unaffected
'total_pages' =>400, // number of pages a channel can create
'total_channels' =>2000, // number of channels the user can add, other users can still add this channel, even if the limit is reached
'attach_upload_limit' =>20000000000, // total attachment storage limit per channel (here 20GB)
'chatters_inroom' =>100);
To apply a service class to an existing account, use the command line utility from the
web root:
`util/service_class`
list service classes
`util/config system default_service_class firstclass`
set the default service class to 'firstclass'
`util/service_class firstclass`
list the services that are part of 'firstclass' service class
1. Clone the channel by opening an account on a $Projectname hub and performing a basic import (not content) from the original RedMatrix hub. Give your new clone time to sync connections and settings.
1. Export individual channel content from your RedMatrix hub to a set of JSON text files using the red.hub/uexport tool. Do this in monthly increments if necessary.
1. On the $Projectname server visit new.hub/locs and upgrade to your channel to a primary one. And when the old Redmatrix server is still listed delete them here as well. Press "Sync" to inform all other server in the grid.
The system logfile is an extremely useful resource for tracking down things that go wrong. This can be enabled in the admin/log configuration page. A loglevel setting of LOGGER_DEBUG is preferred for stable production sites. Most things that go wrong with communications or storage are listed here. A setting of LOGGER_DATA provides [b]much[/b] more detail, but may fill your disk. In either case we recommend the use of logrotate on your operating system to cycle logs and discard older entries.
At the bottom of your .htconfig.php file are several lines (commented out) which enable PHP error logging. This reports issues with code syntax and executing the code and is the first place you should look for issues which result in a "white screen" or blank page. This is typically the result of code/syntax problems.
Database errors are reported to the system logfile, but we've found it useful to have a file in your top-level directory called dbfail.out which [b]only[/b] collects database related issues. If the file exists and is writable, database errors will be logged to it as well as to the system logfile.
In the case of "500" errors, the issues may often be logged in your webserver logs, often /var/log/apache2/error.log or something similar. Consult your operating system documentation.
**The first is the database failure log**. This is only used if you create a file called specifically 'dbfail.out' in the root folder of your website and make it write-able by the web server. If we have any database failed queries, they are all reported here. They generally indicate typos in our queries, but also occur if the database server disconnects or tables get corrupted. On rare occasions we'll see race conditions in here where two processes tried to create an xchan or cache entry with the same ID. Any other errors (especially persistent errors) should be investigated.
**The second is the PHP error log**. This is created by the language processor and only reports issues in the language environment. Again these can be syntax errors or programming errors, but these generally are fatal and result in a "white screen of death"; e.g. PHP terminates. You should probably look at this file if something goes wrong that doesn't result in a white screen of death, but it isn't uncommon for this file to be empty for days on end.
There are some lines at the bottom of the supplied .htconfig.php file; which if uncommented will enable a PHP error log (*extremely* useful for finding the source of white screen failures). This isn't done by default due to potential issues with logfile ownership and write permissions and the fact that there is no logfile rotation by default.
**The third is the "application log"**. This is used by $Projectname to report what is going on in the program and usually reports any difficulties or unexpected data we received. It also occasionally reports "heartbeat" status messages to indicate that we reached a certain point in a script. **This** is the most important log file to us, as we create it ourself for the sole purpose of reporting the status of background tasks and anything that seems weird or out of place. It may not be fatal, but maybe just unexpected. If you're performing a task and there's a problem, let us know what is in this file when the problem occurred. (Please don't send me 100M dumps you'll only piss me off). Just a few relevant lines so I can rule out a few hundred thousand lines of code and concentrate on where the problem starts showing up.
These are your site logs, not mine. We report serious issues at any log level. I highly recommend 'DEBUG' log level for most sites - which provides a bit of additional info and doesn't create huge logfiles. When there's a problem which defies all attempts to track, you might wish to use DATA log level for a short period of time to capture all the detail of what structures we were dealing with at the time. This log level will use a lot of space so is recommended only for brief periods or for developer test sites.
I recommend configuring logrotate for both the php log and the application log. I usually have a look at dbfail.out every week or two, fix any issues reported and then starting over with a fresh file. Likewise with the PHP logfile. I refer to it once in a while to see if there's something that needs fixing.
If something goes wrong, and it's not a fatal error, I look at the application logfile. Often I will
```
tail -f logfile.out
```
While repeating an operation that has problems. Often I'll insert extra logging statements in the code if there isn't any hint what's going wrong. Even something as simple as "got here" or printing out the value of a variable that might be suspect. You can do this too - in fact I encourage you to do so. Once you've found what you need to find, you can
```
git checkout file.php
```
To immediately clear out all the extra logging stuff you added. Use the information from this log and any detail you can provide from your investigation of the problem to file your bug report - unless your analysis points to the source of the problem. In that case, just fix it.
When reporting issues, please try to provide as much detail as may be necessary for developers to reproduce the issue and provide the complete text of all error messages.
We encourage you to try to the best of your abilities to use these logs combined with the source code in your possession to troubleshoot issues and find their cause. The community is often able to help, but only you have access to your site logfiles and it is considered a security risk to share them.
If a code issue has been uncovered, please report it on the project bugtracker (https://github.com/redmatrix/hubzilla/issues). Again provide as much detail as possible to avoid us going back and forth asking questions about your configuration or how to duplicate the problem, so that we can get right to the problem and figure out what to do about it. You are also welcome to offer your own solutions and submit patches. In fact we encourage this as we are all volunteers and have little spare time available. The more people that help, the easier the workload for everybody. It's OK if your solution isn't perfect. Every little bit helps and perhaps we can improve on it.