(Updated: As v4.6.12 and 4.7.0, these directions have been simplified slightly.)
If you're working on a site with CiviCRM v4.6.5+ and rely on StackExchange, IRC, JIRA, or other community media for support, then you should consider making an anonymized site profile. You can prepare one with a few clicks and paste it into any support requests. This will provide a report of key technical details (such as the exact versions of CiviCRM, PHP, MySQL) which may assist others in diagnosing your problem.
How To
Log into CiviCRM as an administrator. Navigate to "Administer => System Settings => Connections".
This page will display an option called "Site Profile" with a "Connect" button. Click it.
Review the information and continue.
Next, open "Settings"
The link provides a snapshot of the site's configuration. You can review this link and copy/paste it into any online discussion forum (StackExchange, IRC, JIRA, email).
For an example profile, this one was generated for civicrm.org:
https://mycivi.org/profile/snapshot/edsZn-JB1GM-LhOmm-PpDna
In-Depth: Question and Answer
Q: What information is shared in a site profile?
A: Check out an example: https://mycivi.org/profile/snapshot/edsZn-JB1GM-LhOmm-PpDna
The specific fields may change depending on your version of CiviCRM. To audit the precise list, you may review the files "api/v3/System/*-whitelist.txt" (e.g. master or 4.6.x).
Q: What is the "History" for?
Problems often arise after making a change -- after switching to a new server, after upgrading PHP, after upgrading CiviCRM, etc. The Site Profile system takes a periodic snapshot of the configuration; when a new problem arises, you'll have some reference points for comparison.
Q: How do I get rid of a profile?
A: Disconnect the "Site Profile". The data will be deleted.
Q: How safe is it to share a site profile?
A: Reasonably safe, but nothing on the Internet is absolutely safe. In online support forums, we often share these software details piecemeal without a second thought. However, there are ways to abuse the information when it's standardized/systemized. The site profile system adds safe-guards to prevent systemic abuse.
The primary risk of sharing these software details is that they could allow attackers to perform cheaper, more efficient scans. For example, if an attacker knows that "http://example.org" runs PHP 5.3.7, then he can focus his scan on vulnerabilities in PHP 5.3.7 (and skip vulnerabilities that only apply to PHP 5.2 or 5.5). Similarly, if an attacker has a database of all sites currently running PHP 5.3.7, then he can direct attacks at those sites (and skip other sites).
For an attacker to do this, he must have two pieces of correlated information: the address or identity of the target, and the software details about it. In our public support forums, we'll often post details (like the PHP version) but won't share our addresses. The site profile system enforces this practice. If you give someone a site profile, it will not reveal the address. Similarly, if you know the site's address, there's no way to guess the profile. This is enforced by passing the data through an external, anonymizing URL (mycivi.org).
For an extra level of paranoia, you can set an expiration on the profile data (e.g. share the profile for two weeks and then hide it). This limits the timeframe where others might harvest the data.
All of this, of course, is precautionary. I'm perfectly happy to tell you that a snapshot of the civicrm.org configuration is published at:
https://mycivi.org/profile/snapshot/edsZn-JB1GM-LhOmm-PpDna
Why is it OK for you to know this? If someone wants this information about civicrm.org specifically, there are plenty of other ways to figure it out (with bit of targetted probing and educated guessing). Moreover, the information will grow stale quickly, and it's difficult to harvest in a systemic, actionable way. Finally, sharing some metadata about the software doesn't compromise the true sources of security -- site security rests on passwords, crypto keys, patch policies, and organizational polices.
Q: What are alternative ways to facilitate diagnostics?
When reaching out for help, there are a few ways to collect and assess diagnostic data:
1. The easiest way is to give an admin account to someone experienced and trustworthy (like a colleague or a professional consultant) and let them handle it. This is useful when you have a working relationship with someone specific... but doesn't work when reaching out through public media.
2. System administrators can use commands like PHP's "phpinfo()", MySQL's "SHOW VARIABLES", or "drush cvapi system.get". This can be useful when the system is totally broken and when you have the technical expertise to run/interpret the commands. If sharing the data publicly, you may need to cherry-pick/redact data by hand.
3. One can prepare a standard questionnaire ("What versions of CiviCRM, Drupal, Joomla, WordPress, PHP, MySQL are you using?", "What modules are enabled?", etc). Depending on your expertise and memory, it may take a while to piece together the information.
The Site Profile system is basically a standard questionnaire -- filled out automatically. It won't answer every question or provide every detail, and it won't resolve every bug, but it gives a decent baseline so that we don't have to any spend time on the most obvious questions.
Q: Should I have a profile for my local dev site or firewalled site?
A: The Site Profile system works with sites on the public Internet.... so I hope you don't need it for a private site. ;)
More earnestly, local dev sites often differ from production sites, and it's usually more useful to get a profile from production. Firewalled sites are often firewalled for a good reason, and I'm not looking for site-profiles to make an end-run around anyone's firewall.
If you do have a good reason to publish a profile for a private site, it will be possible in v4.6.11+, as discussed in:
https://github.com/civicrm/civicrm-cxn-rpc/blob/master/doc/proxy.md
Q: What is a connection? What is CiviConnect?
CiviConnect provides a way for your CiviCRM site to exchange data with an external application, such as the anonymizing "Site Profile" service (aka "mycivi.org"). In this case, your CiviCRM site executes the "System.get" API to generate a redacted profile and passes the data to the "Site Profile" service, which then publishes it using an anonymized URL.
Q: How do I connect on an older version?
The main technology was available in CiviCRM v4.6.5, but it has only be displayed in the menu since v4.6.12. To access it in Civi v4.6.5, login as administrator. In the URL bar, change the address to "civicrm/a/#/cxn". For example, if your website is based at "https://example.org", the URL would be:
| Drupal | https://example.org/civicrm/a/#/cxn |
| Joomla | https://example.org/administrator/?option=com_civicrm&task=civicrm/a/#/cxn |
| WordPress | https://example.org/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fa#/cxn |
Comments
Sounds interesting. I tried on a 4.6.10 public site, waited a few seconds before the Site profile ... Connect popped in to view after a few seconds (did i miss a spinner) clicked on Connect, then Continue - got green Connecting in top right, then got back 'Received garbled message' as the Error.
In drupal logs there are a bunch of errors starting with "Warning: file_get_contents(): SSL: crypto enabling timeout in Civi\Cxn\Rpc\Http\PhpHttp->send() (line 28 of/srv/www/xxx/xxx.org/sites/all/modules/civicrm/vendor/civicrm/civicrm-cxn-rpc/src/Http/PhpHttp.php)."
I checked the link above https://mycivi.org/profile/snapshot/edsZn-JB1GM-LhOmm-PpDna and got 'timed out, page not available'
Ooof, the box seems to have gone down.
This is the second service I've tried running on Google Compute Engine, but the first time with their minimal option. The outage looks weird... may take an hour or two sort out.
unless it is just my experience but it takes a while for the information to load and a spinner would provide some encouragement to sit and wait rather than assume nothing is loading is head elsewhere.