archive/phabricator
1
0
Fork 0
Code Issues 1 Pull Requests Packages Projects Releases Wiki Activity

Organize, update, and improve some documentation.

Browse Source
This commit is contained in:
epriestley
2011-06-25 20:33:25 -07:00
parent 405b05a490
commit 54b6e7fdbc
16 changed files with 198 additions and 148 deletions
Download Patch File Download Diff File Expand all files Collapse all files

145
src/docs/configuration/configuration_guide.diviner Normal file
View File

@@ -0,0 +1,145 @@
@title Configuration Guide
@group config
This document contains basic configuration instructions for Phabricator.
= Prerequisites =
This document assumes you've already installed all the components you need.
If you haven't, see @{article:Installation Guide}.
= Configuring MySQL =
Get MySQL running and verify you can connect to it. Consult the MySQL
documentation for help. When MySQL works, you need to load the Phabricator
schemata into it. First, load the initial database schema.
mysql -uroot < path/to/phabricator/resources/sql/init/initialize.sql
After this you need to upgrade the schema (see @{article:Upgrading Schema}),
but you need to finish the rest of the configuration first.
= Configuring Phabricator =
Create a new file here:
path/to/phabricator/conf/custom/myconfig.conf.php
...where ##myconfig## is some name which identifies your installation. Put this
in the file:
<?php
return array(
// Important! This will put Phabricator into setup mode to help you
// configure things.
'phabricator.setup' => true,
// This will be the base domain for your install, and must be configured.
// Use "https://" if you have SSL. See below for some notes.
'phabricator.base-uri' => 'http://phabricator.example.com/',
) + phabricator_read_config_file('production');
For the last line, you can also use ##'development'## instead of
##'production'## if you are planning to develop Phabricator itself. This will
turn on some debugging features.
= Configuring Apache =
Get Apache running and verify it's serving a test page. Consult the Apache
documentation for help. Make sure ##mod_php## and ##mod_rewrite## are enabled,
and ##mod_ssl## if you intend to set up SSL.
If you haven't already, set up a domain name to point to the host you're
installing on. You can either install Phabricator on a subdomain (like
phabricator.example.com) or an entire domain, but you can not install it in
some subdirectory of an existing website. Navigate to whatever domain you're
going to use and make sure Apache serves you something to verify that DNS
is correctly configured.
Now, either create a VirtualHost entry (to put Phabricator on a subdomain)
or edit the Directory entry for the DocumentRoot. It should look something like
this:
<VirtualHost *>
# Change this to the domain which points to your host, i.e. the domain
# you set as "phabricator.base-uri".
ServerName phabricator.example.com
# Change this to the path where you put 'phabricator' when you checked it
# out from github when following the Installation Guide.
DocumentRoot /path/to/phabricator/webroot
RewriteEngine on
RewriteRule ^/rsrc/(.*) - [L,QSA]
RewriteRule ^/favicon.ico - [L,QSA]
RewriteRule ^(.*)$ /index.php?__path__=$1 [L,QSA]
# This will use the config file you set up in the previous step. If you
# called it something other than 'myconfig', put that here.
SetEnv PHABRICATOR_ENV custom/myconfig
</VirtualHost>
Now, restart apache and navigate to whichever subdomain you set up. You should
either see the Phabricator setup screen, which is a simple text page that looks
something like this:
PHABRICATOR SETUP
This setup mode will guide you through setting up your Phabricator
configuration.
>>> REQUIRED PHP EXTENSIONS ------------------------------------------------
...
If you see this, you're in good shape. Follow the instructions and correct any
problems setup detects. If you don't see it but you do see a useful error
message, try to fix that. If neither of these cover you, something is wrong.
If you can't figure it out, come get help in IRC or on the mailing list (see
http://phabricator.org/ for links).
= Configuring Phabricator =
Now that basic setup is complete, you should configure Phabricator for your
installation. Phabricator configuration options which control how the
applications behave are documented here:
/path/to/phabricator/conf/default.conf.php
There are several builtin configurations:
- ##default.conf.php##: root configuration, lists every configuration option
and sets some default for it. Look in this file to figure out what you can
configure.
- ##development.conf.php##: pulls in ##default.conf.php##, but overrides some
configuration options to better values for doing development on Phabricator.
You probably don't need to even look at this file unless you're making
changes to Phabricator itself.
- ##production.conf.php##: pulls in ##default.conf.php##, but overrides some
configuration options to provide better values for a production install.
To actually configure your install, edit your ##custom/myconfig.conf.php## file
and override values from either the ##'production'## or ##'development'##
configurations. You should not edit the builtin configurations directly because
that will make upgrading Phabricator more difficult in the future.
= Upgrading Schema =
After you have configured Phabricator, you need to upgrade the database
schema -- see @{article:Upgrading Schema}. You'll also need to do this after you
update the code in the future.
= Next Steps =
Continue by:
- upgrading the database schema with @{article:Upgrading Schema}; or
- setting up your admin account and login/registration with
@{article:Configuring Accounts and Registration}; or
- configuring Phabricator so it can send mail with
@{article:Configuring Outbound Email}; or
- configuring inbound mail with @{article:Configuring Inbound Email}; or
- learning about daemons with @{article:Managing Daemons with phd}; or
- contributing to Phabricator with @{article:Contributor Introduction}.

113
src/docs/configuration/configuring_accounts_and_registration.diviner Normal file
View File

@@ -0,0 +1,113 @@
@title Configuring Accounts and Registration
@group config
Describes how to configure user access to Phabricator.
= Overview =
Phabricator supports a number of login systems, like traditional
username/password, Facebook OAuth, and GitHub OAuth. You can enable or disable
these systems to configure who can register for and access your install, and
how users with existing accounts can login.
By default, only username/password auth is enabled, and there are no valid
accounts. Start by creating a new account with the
##phabricator/bin/accountadmin## script.
= Using accountadmin =
##accountadmin## is a user-friendly command line interface for creating and
editing accounts. To use ##accountadmin##, just run the script:
$ ./phabricator/bin/accountadmin
Enter a username to create a new account or edit an existing account.
Enter a username:
This will walk you through the process of creating an initial user account.
Once you've created an account, you can login with it and use the web console
to create and manage accounts more easily (provided you make your first account
an administrator).
You can use this script later to create or edit accounts if you, for example,
accidentally remove your admin flag.
= Managing Accounts with the Web Console =
To manage accounts from the web, login as an administrator account and go to
##/people/## or click "People" on the homepage. Provided you're an admin,
you'll see options to create or edit accounts.
= Configuring Facebook OAuth =
You can configure Facebook OAuth to allow login, login and registration, or
nothing (the default). If registration is not allowed, users must have an
existing account in order to link a Facebook account to it, but can use
Facebook to login once the accounts are linked.
To configure Facebook OAuth, create a new Facebook Application:
https://www.facebook.com/developers/createapp.php
You should set these things in your application:
- **Site URL**: Set this to your full domain with protocol, like
"##https://phabricator.example.com/##".
- **Site Domain**: Set this to the entire domain, like ##example.com##. You
might be able to get away with including the subdomain if you want to
scope more tightly.
Once that is set up, edit your Phabricator configuration and set these keys:
- **facebook.auth-enabled**: set this to ##true##.
- **facebook.application-id**: set to your Facebook application's ID. Make
sure you set this as a string.
- **facebook.application-secret**: set to your Facebook application's
secret key.
- **facebook.registration-enabled**: set this to ##true## to let users
register for your install with a Facebook account (this is a very open
setting) or ##false## to prevent users from registering with Facebook.
- **facebook.auth-permanent**: you can set this to prevent account unlinking.
It is unlikely you want to prevent it, but Facebook's internal install uses
this option since Facebook uses Facebook as its only auth mechanism.
= Configuring GitHub OAuth =
You can configure GitHub OAuth to allow login, login and registration, or
nothing (the default).
To configure GitHub OAuth, create a new GitHub Application:
https://github.com/account/applications/new
You should set these things in your application:
- **URL**: Set this to the full domain with protocol, like
"##https://phabricator.example.com/##".
- **Callback URL**: Set this to your domain plus "##/oauth/github/login/##",
like "##https://phabricator.example.com/oauth/github/login/##".
Once you've created an application, edit your Phabricator configuration and
set these keys:
- **github.auth-enabled**: set this to ##true##.
- **github.application-id**: set this to your application/client ID.
- **github.application-secret**: set this to your application secret.
- **github.registration-enabled**: set to ##true## to let users register with
just GitHub credentials (this is a very open setting) or ##false## to
prevent users from registering. If set to ##false##, users may still link
existing accounts and use GitHub to login, they just can't create new
accounts.
- **github.auth-permanent**: set to ##true## to prevent unlinking Phabricator
accounts from GitHub accounts.
Note that you can see a list of your GitHub applications here, although it's not
immediately clear how to get there via the UI:
https://github.com/account/applications/
= Next Steps =
Continue by:
- returning to the @{article:Configuration Guide}.

204
src/docs/configuration/configuring_inbound_email.diviner Normal file
View File

@@ -0,0 +1,204 @@
@title Configuring Inbound Email
@group config
This document contains instructions for configuring inbound email, so users
may update Differential and Maniphest by replying to messages.
= Preamble =
This can be extremely difficult to configure correctly. This is doubly true if
you use sendmail.
There are basically a few approaches available:
- Use SendGrid (<http://sendgrid.com/>), which is very easy but is not free.
- Run your own MTA, which can be quite harrowing to configure but is free.
- Tell the Phabricator devteam about another service you'd like support for,
this stuff is seriously terrible to configure on your own.
= Configuring Phabricator =
By default, Phabricator uses a "noreply@example.com" email address as the 'From'
(configurable with ##metamta.default-address##) and sets 'Reply-To' to the
user generating the email (e.g., by making a comment), if the mail was generated
by a user action. This means that users can reply (or reply-all) to email to
discuss changes, but the conversation won't be recorded in Phabricator and users
will not be able to take actions like claiming tasks or requesting changes to
revisions.
To change this behavior so that users can interact with objects in Phabricator
over email, set these configuration keys:
- ##metamta.differential.reply-handler-domain##: enables email replies for
Differential.
- ##metamta.maniphest.reply-handler-domain##: enables email replies for
Maniphest.
Set these keys to some domain which you configure according to the instructions
below, e.g. "##phabricator.example.com##". You can set these both to the same
domain, and will generally want to. Once you set these keys, emails will use a
'Reply-To' like "##T123+273+af310f9220ad@example.com##", which -- when
configured correctly, according to the instructions below -- will parse incoming
email and allow users to interact with Maniphest tasks and Differential
revisions over email.
= Security =
The email reply channel is "somewhat" authenticated. Each reply-to address is
unique to the recipient and includes a hash of user information and a unique
object ID, so it can only be used to update that object and only be used to act
on behalf of the recipient.
However, if an address is leaked (which is fairly easy -- for instance,
forwarding an email will leak a live reply address, or a user might take a
screenshot), //anyone// who can send mail to your reply-to domain may interact
with the object the email relates to as the user who leaked the mail. Because
the authentication around email has this weakness, some actions (like accepting
revisions) are not permitted over email.
This implementation is an attempt to balance utility and security, but makes
some sacrifices on both sides to achieve it because of the difficulty of
authenticating senders in the general case (e.g., where you are an open source
project and need to interact with users whose email accounts you have no control
over).
If you leak a bunch of reply-to addresses by accident, you can change
##phabricator.mail-key## in your configuration to invalidate all the old hashes.
NOTE: Phabricator does not currently attempt to verify "From" addresses because
this is technically complex, seems unreasonably difficult in the general case,
and no installs have had a need for it yet. If you have a specific case where a
reasonable mechanism exists to provide sender verification (e.g., DKIM
signatures are sufficient to authenticate the sender under your configuration,
or you are willing to require all users to sign their email), file a feature
request.
= Testing =
You can view a log of received mail by going to MetaMTA -> Received in the
Phabricator web interface. This can help you determine if mail is being
delivered to Phabricator or not.
You can also use the "Test Receiver" button, but note that this just simulates
receiving mail and doesn't send any information over the network. It is
primarily aimed at developing email handlers: it will still work properly
if your inbound email configuration is incorrect or even disabled.
= SendGrid =
To use SendGrid, you need a SendGrid account with access to the "Parse API" for
inbound email. Provided you have such an account, configure it like this:
- Configure an MX record according to SendGrid's instructions, i.e. add
##phabricator.example.com MX 10 mx.sendgrid.net.## or similar.
- Go to the "Parse Incoming Emails" page on SendGrid
(<http://sendgrid.com/developer/reply>) and add the domain as the
"Hostname".
- Add the URL ##https://phabricator.example.com/mail/sendgrid/## as the "Url",
using your domain (and HTTP instead of HTTPS if you are not configured with
SSL).
- If you get an error that the hostname "can't be located or verified", it
means your MX record is either incorrectly configured or hasn't propagated
yet.
- Set ##metamta.maniphest.reply-handler-domain## and/or
##metamta.differential.reply-handler-domain## to
"##phabricator.example.com##" (whatever you configured the MX record for),
depending on whether you want to support email replies for Maniphest,
Differential, or both.
That's it! If everything is working properly you should be able to send email
to ##anything@phabricator.example.com## and it should appear in the "Received"
tab of MetaMTA within a few seconds.
= Installing Mailparse =
If you're going to run your own MTA, you need to install the PECL mailparse
extension. In theory, you can do that with:
$ sudo pecl install mailparse
You may run into an error like "needs mbstring". If so, try:
$ sudo yum install php-mbstring # or equivalent
$ sudo pecl install -n mailparse
If you get a linker error like this:
COUNTEREXAMPLE
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/lib64/php/modules/mailparse.so' - /usr/lib64/php/modules/mailparse.so:
undefined symbol: mbfl_name2no_encoding in Unknown on line 0
...you need to edit your php.ini file so that mbstring.so is loaded **before**
mailparse.so. This is not the default if you have individual files in
##php.d/##.
= MTA: Configuring Sendmail =
Before you can configure Sendmail, you need to install Mailparse. See the
section "Installing Mailparse" above.
Sendmail is very difficult to configure. First, you need to configure it for
your domain so that mail can be delivered correctly. In broad strokes, this
probably means something like this:
- add an MX record;
- make sendmail listen on external interfaces;
- open up port 25 if necessary (e.g., in your EC2 security policy);
- add your host to /etc/mail/local-host-names; and
- restart sendmail.
Now, you can actually configure sendmail to deliver to Phabricator. In
##/etc/aliases##, add an entry like this:
phabricator: "| /path/to/phabricator/scripts/mail/mail_handler.php <ENV>"
...where <ENV> is the PHABRICATOR_ENV the script should run under. Run
##sudo newaliases##. Now you likely need to symlink this script into
##/etc/smrsh/##:
sudo ln -s /path/to/phabricator/scripts/mail/mail_handler.php /etc/smrsh/
Finally, edit ##/etc/mail/virtusertable## and add an entry like this:
@yourdomain.com phabricator@localhost
That will forward all mail to @yourdomain.com to the Phabricator processing
script. Run ##sudo /etc/mail/make## or similar and then restart sendmail with
##sudo /etc/init.d/sendmail restart##.
= MTA: Configuring Lamson =
Before you can configure Lamson, you need to install Mailparse. See the section
"Installing Mailparse" above.
In contrast to Sendmail, Lamson is relatively easy to configure. It is fairly
minimal, and is suitable for a development or testing environment. Lamson
listens for incoming SMTP mails and passes the content directly to Phabricator.
To get started, follow the provided instructions
(<http://lamsonproject.org/docs/getting_started.html>) to set up an instance.
One likely deployment issue is that binding to port 25 requires root
privileges. Lamson is capable of starting as root then dropping privileges, but
you must supply ##-uid## and ##-gid## arguments to do so, as demonstrated by
Step 8 in Lamson's deployment tutorial (located here:
<http://lamsonproject.org/docs/deploying_oneshotblog.html>).
The Lamson handler code itself is very concise; it merely needs to pass the
content of the email to Phabricator:
import logging, subprocess
from lamson.routing import route, stateless
from lamson import view
PHABRICATOR_ROOT = "/path/to/phabricator"
PHABRICATOR_ENV = "custom/myconf"
LOGGING_ENABLED = True
@route("(address)@(host)", address=".+")
@stateless
def START(message, address=None, host=None):
if LOGGING_ENABLED:
logging.debug("%s", message.original)
process = subprocess.Popen([PHABRICATOR_ROOT + "scripts/mail/mail_handler.php",PHABRICATOR_ENV],stdin=subprocess.PIPE)
process.communicate(message.original)

172
src/docs/configuration/configuring_outbound_email.diviner Normal file
View File

@@ -0,0 +1,172 @@
@title Configuring Outbound Email
@group config
Instructions for configuring Phabricator to send mail.
= Overview =
Phabricator can send outbound email via several different adapters:
- by running ##sendmail## on the local host with SMTP; or
- by using Amazon SES (Simple Email Service); or
- by using SendGrid's REST API; or
- via a custom adapter you write; or
- by dropping email into a hole and not delivering it.
Of these, ##sendmail## is the default but requires some configuration. SES and
SendGrid are easier, but cost money and have some limitations. Writing a custom
solution requires digging into the code. See below for details on how to set up
each method.
Phabricator can also send outbound email in two ways:
- immediately, when messages are generated (default); or
- in the background, via a daemon.
Sending mail in the background requires more configuration, but will greatly
improve the performance of the application if your mail handler is slow. Note
that Amazon SES commonly takes 1-2 seconds per email. If you use SES,
**strongly consider** configuring the daemon. You should also configure the
daemon if commenting on Revisions or Tasks feels slow, as it may significantly
improve performance.
= Basics =
Regardless of how outbound email is delivered, you should configure these keys
in your configuration file:
- **metamta.default-address** determines where mail is sent "From" by
default. If your domain is ##example.org##, set this to something like
"##noreply@example.org##".
- **metamta.domain** should be set to your domain, e.g. "##example.org##".
- **metamta.can-send-as-user** should be left as ##false## in most cases,
but see the documentation in ##default.conf.php## for details.
= Configuring Mail Adapters =
To choose how mail will be sent, change the **metamta.mail-adapter** key in
your configuration. Possible values are:
- ##PhabricatorMailImplementationPHPMailerLiteAdapter##: default, uses
"sendmail", see "Adapter: Sendmail".
- ##PhabricatorMailImplementationAmazonSESAdapter##: use Amazon SES, see
"Adapter: Amazon SES".
- ##PhabricatorMailImplementationSendGridAdapter##: use SendGrid, see
"Adapter: SendGrid".
- ##Some Custom Class You Write##: use a custom adapter you write, see
"Adapter: Custom".
- ##PhabricatorMailImplementationTestAdapter##: this will
**completely disable** outbound mail. You can use this if you don't want to
send outbound mail, or want to skip this step for now and configure it
later.
= Adapter: Sendmail =
This is the default, and selected by choosing
##PhabricatorMailImplementationPHPMailerLiteAdapter## as the value for
**metamta.mail-adapter**. This requires a 'sendmail' binary to be installed on
the system. Most MTAs (e.g., sendmail, qmail, postfix) should do this, but your
machine may not have one installed by default. For install instructions, consult
the documentation for your favorite MTA.
Since you'll be sending the mail yourself, you are subject to things like SPF
rules, blackholes, and MTA configuration which are beyond the scope of this
document. If you can already send outbound email from the command line or know
how to configure it, this option is straightforward. If you have no idea how to
do any of this, consider using Amazon SES.
= Adapter: Amazon SES =
Amazon SES is Amazon's cloud email service. It is not free, but is easier to
configure than sendmail and can simplify outbound email configuration. To use
Amazon SES, you need to sign up for an account with Amazon at
<http://aws.amazon.com/ses/>.
To configure Phabricator to use Amazon SES, set these configuration keys:
- **metamta.mail-adapter**: set to
"PhabricatorMailImplementationAmazonSESAdapter".
- **amazon-ses.access-key**: set to your Amazon SES access key.
- **amazon-ses.secret-key**: set to your Amazon SES secret key.
NOTE: Amazon SES **requires you to verify your "From" address**. Configure which
"From" address to use by setting "##metamta.default-address##" in your config,
then follow the Amazon SES verification process to verify it. You won't be able
to send email until you do this!
NOTE: Amazon SES is slow to accept mail (often 1-2 seconds) and application
performance will improve greatly if you configure outbound email to send in
the background.
= Adapter: SendGrid =
SendGrid is an email delivery service like Amazon SES. You can learn more at
<http://sendgrid.com/>. It is easy to configure, but not free.
You can configure SendGrid in two ways: you can send via SMTP or via the REST
API. To use SMTP, just configure ##sendmail## and leave Phabricator's setup
with defaults. To use the REST API, follow the instructions in this section.
To configure Phabricator to use SendGrid, set these configuration keys:
- **metamta.mail-adapter**: set to
"PhabricatorMailImplementationSendGridAdapter".
- **sendgrid.api-user**: set to your SendGrid login name.
- **sendgrid.api-key**: set to your SendGrid password.
If you're logged into your SendGrid account, you may be able to find this
information easily by visiting <http://sendgrid.com/developer>.
= Adapter: Custom =
You can provide a custom adapter by writing a concrete subclass of
@{class:PhabricatorMailImplementationAdapter} and setting it as the
**metamta.mail-adapter**.
TODO: This needs to be better documented once extending Phabricator is better
documented.
= Adapter: Disable Outbound Mail =
You can use the @{class:PhabricatorMailImplementationTestAdapter} to completely
disable outbound mail, if you don't want to send mail or don't want to configure
it yet. Just set **metamta.mail-adapter** to
"PhabricatorMailImplementationTestAdapter".
= Configuring the MetaMTA Daemon =
Regardless of how you are sending outbound email, you can move the handoff to
the MTA out of the main process and into a daemon. This will greatly improve
application performance if your mailer is slow, like Amazon SES. In particular,
commenting on Differential Revisions and Maniphest Tasks sends outbound email.
To use the MetaMTA daemon:
- set **metamta.send-immediately** to ##false## in your configuration; and
- launch a ##metamta## daemon with ##phabricator/bin/phd launch metamta##.
For more information on using daemons, see @{article:Managing Daemons with phd}.
= Testing and Debugging Outbound Email =
Phabricator has a mail log and test console at ##/mail/##, or click the
**MetaMTA** link from the homepage. This console shows all the mail Phabricator
has attempted to deliver, plus debugging and error information.
You can use the "Send New Message" button to send mail using the current
configuration. This can help test that your setup is correct.
NOTE: when you send mail, "to" and "cc" must be valid users of the system, not
arbitrary email addresses.
You can monitor daemons using the Daemon Console (##/daemon/##, or click
**Daemon Console** from the homepage).
= Next Steps =
Continue by:
- @{article:Configuring Inbound Email} so users can reply to email they
receive about revisions and tasks to interact with them; or
- learning about daemons with @{article:Managing Daemons with phd}; or
- returning to the @{article:Configuration Guide}.

72
src/docs/configuration/managing_daemons.diviner Normal file
View File

@@ -0,0 +1,72 @@
@title Managing Daemons with phd
@group config
Explains Phabricator daemons and the daemon control program ##phd##.
= Overview =
Phabricator uses daemons (background processing scripts) to handle a number of
tasks, like:
- tracking repositories and discovering new commits;
- sending mail;
- updating objects in the search index; and
- custom tasks you define.
Daemons are started and stopped with **phd** (the **Ph**abricator **D**aemon
launcher). Daemons can be monitored via a web console.
You do not need to run daemons for most parts of Phabricator to work, but a few
features (principally, repository tracking with Diffusion) require them and
several features will benefit in performance or stability if you configure
daemons.
= phd =
**phd** is a command-line script (located at ##phabricator/bin/phd##). To get
a list of commands, run ##phd help##:
phabricator/ $ ./bin/phd help
NAME
phd - phabricator daemon launcher
...
Generally, you will use:
- **phd launch** to launch daemons;
- **phd debug** to debug problems with daemons;
- **phd status** to get a list of running daemons; and
- **phd stop** to stop all daemons.
NOTE: When you upgrade Phabricator or change configuration, you should restart
the daemons by stopping and relaunching them.
NOTE: When you **launch** a daemon, you can type any unique substring of its
name, so **phd launch metamta** will work correctly.
= Daemon Console =
You can view status and debugging information for daemons in the Daemon Console
via the web interface. Go to ##/daemon/## in your install or click
**Daemon Console** from the homepage.
The Daemon Console shows a list of all the daemons that have ever launched, and
allows you to view log information for them. If you have issues with daemons,
you may be able to find error information that will help you resolve the problem
in the console.
NOTE: The easiest way to figure out what's wrong with a daemon is usually to use
**phd debug** to launch it instead of **phd launch**. This will run it without
daemonizing it, so you can see output in your console.
= Available Daemons =
You can get a list of launchable daemons with **phd list**:
- **libphutil test daemons** are not generally useful unless you are
developing daemon infrastructure or debugging a daemon problem;
- **PhabricatorMetaMTADaemon** sends mail in the background, see
@{article:Configuring Outbound Email} for details;
- **PhabricatorTaskmasterDaemon** runs a generic task queue; and
- **PhabricatorRepository** daemons track repositories, descriptions are
available in the @{article:Diffusion User Guide}.

29
src/docs/configuration/upgrade_schema.diviner Normal file
View File

@@ -0,0 +1,29 @@
@title Upgrading Schema
@group config
This document describes how to upgrade the database schema.
= Prerequisites =
This document assumes you've already initialized the MySQL database and
configured your Phabricator environment. If you haven't, see
@{article:Configuration Guide}.
= Loading patches =
To upgrade your database schema to the latest version, just run this command:
PHABRICATOR_ENV=<your_config> path/to/phabricator/scripts/sql/upgrade_schema.php
This will install all the patches that are new since you installed, or since the last time you ran this script.
If your configuration uses an unprivileged user to connect to the database, you
may have to override the default user so the schema changes can be applied with
root or some other admin user:
PHABRICATOR_ENV=<your_config> path/to/phabricator/scripts/sql/upgrade_schema.php -u <user> -p <pass>
You can avoid the prompt the script issues by passing the ##-f## flag (for
example, if you are scripting the upgrade process).
PHABRICATOR_ENV=<your_config> path/to/phabricator/scripts/sql/upgrade_schema.php -f