Bug 206835 - devel/phabricator phd daemon missing conf/local/local.json file
Summary: devel/phabricator phd daemon missing conf/local/local.json file
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Michael Gmelin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-02 05:17 UTC by knezour
Modified: 2016-02-02 22:57 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (grembo)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description knezour 2016-02-02 05:17:27 UTC
Fresh installation of the Phabricator with phd_enable="YES" in the /etc/rc.conf file can't start the phd daemon because of the conf/local/local.json file missing. I was not able to found any information what is necessary to include in this file in the port, Phabricator docs site nor the Internet. However daemon happily starts when empty file is created.

There should be better documented if anything is mandatory to include in this file. Alternatively, empty file may be installed during package installation or the user may be notified in the pkg-message to do so.
Comment 1 Michael Gmelin freebsd_committer freebsd_triage 2016-02-02 19:49:47 UTC
local.json stores essential configuration like database server credentials, timezone, base URI etc.. It's written by bin/config.

Without those basic configuration settings, Iphabricator can't do anything useful, so not being able to run the daemons makes sense (well, AFAIK, please correct me if I'm wrong or if things have changed lately).
Comment 2 knezour 2016-02-02 20:07:18 UTC
Looks like daemons are able to get config somehow, because with empty local.json file I see 3 daemons running in the /daemon console and grep -i err|warn in the phd logs returns only missing base-uri, which is outstanding setup task site-wide.

It is of course possible, that my daemons instances are not able to do anything useful, some daemons are not running etc., but it is hard to say with no documentation what is necessary, what processes should be running and so on and that is main point of my bug report :)

However it is probably upstream problem, because my not-so-basic Google-fu didn't reveal anything useful even at the Phabricator docs site.
Comment 3 Michael Gmelin freebsd_committer freebsd_triage 2016-02-02 20:43:08 UTC
(In reply to knezour from comment #2)
Once you configured phabricator according to upstream documentation, local.json should be populated.

Mind if I close this as "works as intended"?
Comment 4 knezour 2016-02-02 20:48:24 UTC
No, after completing the "setup wizard" I ended without any local.json file.

May you provide link to mentioned documentation? I wasn't able to find anything useful.

I don't mind if the ticket get closed as it works for me now, however I still see little room for improvement regarding better describing necessary steps to get phd daemon running for those who will come in our steps.
Comment 5 Michael Gmelin freebsd_committer freebsd_triage 2016-02-02 20:51:28 UTC
(In reply to knezour from comment #4)
Could you share some details about your setup? Is there a (populated) config.json or some other configuration file around?
Comment 6 knezour 2016-02-02 20:58:54 UTC
I think nothing special. Fresh 10.2-RELEASE in VM, pkg install php5-phabricator, mysql56-server, nginx, couple of the PHP extensions.

There is no config file under the conf directory, only some README, .keep and __init_conf__.php files. ./bin/config list lists 199 variables, none has any value set. 

Out of curiosity I also tried this right now:
 ./bin/config migrate
Migrating file-based config to more modern config...
Skipping config of source type PhabricatorConfigDatabaseSource...
Skipping config of source type PhabricatorConfigLocalSource...
Skipping config of source type PhabricatorConfigDefaultSource...
Done. Migrated 0 keys.
Comment 7 knezour 2016-02-02 21:00:21 UTC
And to be clear - there is also empty /conf/local/json.local file created by me to proceed with the phd startup.
Comment 8 Michael Gmelin freebsd_committer freebsd_triage 2016-02-02 21:04:24 UTC
How do you connect to your mysql server? In my setup local.json has mysql_host/password etc.
Comment 9 knezour 2016-02-02 21:15:37 UTC
(In reply to Michael Gmelin from comment #8)

I was not asked for DB login info during setup. MySQL listen only on unix socket - no networking and phabricator probably used root account without password. At least I don't see any other accounts in the DB defined (except two nameless). And while there, I see 58 phabricator_* databases, so there is definitely some communication between phabricator and DB.
Comment 10 Michael Gmelin freebsd_committer freebsd_triage 2016-02-02 21:50:19 UTC
Could you try to run

/usr/local/lib/php/phabricator/bin/config set mysql.user root

(or some other user) and see if that touches local.json?
Comment 11 knezour 2016-02-02 21:53:39 UTC
(In reply to Michael Gmelin from comment #10)
Yes, it does.

# ./bin/config set mysql.user root
Set 'mysql.user' in local configuration.

# cat conf/local/local.json
{
  "mysql.user": "root"
}
Comment 12 commit-hook freebsd_committer freebsd_triage 2016-02-02 22:54:22 UTC
A commit references this bug:

Author: grembo
Date: Tue Feb  2 22:53:23 UTC 2016
New revision: 407898
URL: https://svnweb.freebsd.org/changeset/ports/407898

Log:
  Add local.json.sample, so that phabricator daemons start ok in simple
  out-of-the-box configurations.

  PR:		206835
  Approved by:	mentors (implicit)

Changes:
  head/devel/phabricator/Makefile
  head/devel/phabricator/files/local.json.sample
  head/devel/phabricator/pkg-plist
Comment 13 Michael Gmelin freebsd_committer freebsd_triage 2016-02-02 22:57:08 UTC
(In reply to knezour from comment #11)

Ok, I created a sample file that is installed with the port, which is setting mysql.user to root and an empty password. Using @sample, this file is also duplicated to local.json and - if the contents of the file didn't changed - it's removed, otherwise it will stay there, even after removing the package.

I didn't bump the revision, as this is a change existing installations won't benefit from.