Silki
view release on metacpan or search on metacpan
lib/Silki/Manual/Admin.pod view on Meta::CPAN
hostname. Of course, this may not be true.
This is important because Silki generates URIs with the hostname when it
issues a redirect, and when it sends invitation and registration confirmation
emails.
A site admin can edit the exisiting domain.
Domains can have separate web and email hostnames. The email hostname is not
currently used, but will be used in the future for emailing content into the
wiki.
Silki will throw an error if you attempt to access it from a domain it does
not know about. If the default domain chosen when the system was installed is
not being used, you can edit the domain manually using the C<psql> command
line tool. In the future, the default domain will be made configurable during
the installation process.
=head2 Multiple Domains
If you set up Silki for some sort of wiki hosting system, you may want to
operate with multiple domains. When you create a wiki, you will assign it to a
specific domain.
Of course, you will also need to configure the web server side to work with
multiple domains.
=head1 WEB SERVER CONFIGURATION
With Catalyst, you have a number of options when deciding how to integrate
Silki with your web server, including FastCGI, mod_perl, PSGI, and more.
While you can, in theory, run Silki as a vanilla CGI, this is not recommended,
as it will be quite slow.
Silki uses the X-Sendfile header when users download attachments. This means
you will need to configure your web server to support this.
=head2 Apache 2 and Starman
Since there are so many options, we'll cover just one in depth, running Silki
with Apache 2 serving static content, and L<Starman> as the app server.
In order to support the X-Sendfile header, you will need the
L<mod_xsendfile|http://tn123.ath.cx/mod_xsendfile/> Apache module installed.
You should configure Apache to serve the css, images, and javascript files
statically. In production, Silki prepends the css and javascript URIs with the
Silki version number. This helps ensure that these files are reloaded when a
new version of Silki is installed. Assuming you installed the share files in
F</usr/local/share/silki>, this would look like:
AliasMatch ^/[^/]+/css(.+) /usr/local/share/silki/css$1
AliasMatch ^/[^/]+/js(.+) /usr/local/share/silki/js$1
AliasMatch ^/images(.+) /usr/local/share/silki/images$1
All other URIs should simply be passed to the Starman server. For testing, you
can start the server from the command line:
sudo -u www-data \
starman --listen 127.0.0.1:13000 \
--workers 5 \
--preload-app \
/usr/local/bin/silki.psgi
You can adjust the value of C<--listen>, but it is recommended that you only
listen on the localhost interface. There's no reason to expose the app server
to the world at large. You can also adjust C<--workers> as needed.
You also need to enable support for the X-Sendfile header in your Apache
config file:
XSendFile on
XSendFileAllowAbove on
Finally, you can use mod_rewrite to pass all non-static URIs to the Starman
server:
RewriteEngine On
RewriteRule !^/images - [C]
RewriteRule !^/[^/]+/css - [C]
RewriteRule !^/[^/]+/js - [C]
RewriteRule (.*) http://localhost:13000$1 [P,L]
The whole thing, wrapped in a virtual host, looks like this:
<VirtualHost *:80>
ServerName silki.test
DocumentRoot /usr/local/share/silki
ErrorLog /var/log/apache2/error.log
CustomLog /var/log/apache2/access.log combined
AliasMatch ^/[^/]+/css(.+) /usr/local/share/silki/css$1
AliasMatch ^/[^/]+/js(.+) /usr/local/share/silki/js$1
AliasMatch ^/images(.+) /usr/local/share/silki/images$1
XSendFile on
XSendFileAllowAbove on
RewriteEngine On
RewriteRule !^/images - [C]
RewriteRule !^/[^/]+/css - [C]
RewriteRule !^/[^/]+/js - [C]
RewriteRule (.*) http://localhost:13000$1 [P,L]
</VirtualHost>
=head1 AUTHOR
Dave Rolsky <autarch@urth.org>
=head1 COPYRIGHT AND LICENSE
This software is Copyright (c) 2011 by Dave Rolsky.
This is free software, licensed under:
The GNU Affero General Public License, Version 3, November 2007
=cut
( run in 0.653 second using v1.01-cache-2.11-cpan-e93a5daba3e )