You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@brooklyn.apache.org by ri...@apache.org on 2017/10/16 13:45:07 UTC
[13/18] brooklyn-docs git commit: Update for karaf
Update for karaf
Project: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/repo
Commit: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/commit/972aa0d7
Tree: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/tree/972aa0d7
Diff: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/diff/972aa0d7
Branch: refs/heads/master
Commit: 972aa0d74ca601e71ff6edb7f420fd33d7f32960
Parents: e73b66e
Author: Duncan Godwin <du...@cloudsoftcorp.com>
Authored: Tue Sep 26 14:24:10 2017 +0100
Committer: Duncan Godwin <dr...@googlemail.com>
Committed: Tue Sep 26 15:25:44 2017 +0100
----------------------------------------------------------------------
guide/ops/configuration/brooklyn_cfg.md | 18 +--
guide/ops/configuration/cors.md | 2 +-
guide/ops/configuration/https.md | 21 +++-
guide/ops/configuration/index.md | 99 ++++++++++++++-
guide/ops/configuration/osgi-configuration.md | 119 -------------------
.../high-availability-supplemental.md | 14 +--
guide/ops/security-guidelines.md | 2 +-
guide/start/brooklyn.properties | 4 +-
guide/start/running.md | 6 +-
9 files changed, 129 insertions(+), 156 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/972aa0d7/guide/ops/configuration/brooklyn_cfg.md
----------------------------------------------------------------------
diff --git a/guide/ops/configuration/brooklyn_cfg.md b/guide/ops/configuration/brooklyn_cfg.md
index bd70ea6..11af09b 100644
--- a/guide/ops/configuration/brooklyn_cfg.md
+++ b/guide/ops/configuration/brooklyn_cfg.md
@@ -12,7 +12,7 @@ children:
{% include fields.md %}
-The file brooklyn.cfg is read when Apache Brooklyn starts in order to load any server configuration values. It can be found in the Brooklyn configuration folder. You can check [here](../paths.html) for the location of your Brooklyn configuration folder
+The file `brooklyn.cfg` is read when Apache Brooklyn starts in order to load any server configuration values. It can be found in the Brooklyn configuration folder. You can check [here](../paths.html) for the location of your Brooklyn configuration folder
## Quick Setup
@@ -28,10 +28,6 @@ brooklyn.webconsole.security.user.admin.password=AdminPassw0rd
brooklyn.webconsole.security.user.bob.password=BobPassw0rd
{% endhighlight %}
-The config file *must* have permissions 600
-(i.e. readable and writable only by the file's owner),
-for some security.
-
In many cases, it is preferable instead to use an external credentials store such as LDAP.
Information on configuring these is [below](#authentication).
@@ -50,8 +46,8 @@ More information, including setting up a certificate, is described [further belo
Values in `brooklyn.cfg` can use the Camp YAML syntax. Any value starting `$brooklyn:` is
parsed as a Camp YAML expression.
-This allows [externalized configuration]({{ site.path.guide}}/ops/externalized-configuration.html) to be used from
-brooklyn.cfg. For example:
+This allows [externalized configuration]({{ site.path.guide }}/ops/externalized-configuration.html) to be used from
+`brooklyn.cfg`. For example:
{% highlight properties %}
brooklyn.location.jclouds.aws-ec2.identity=$brooklyn:external("vault", "aws-identity")
@@ -204,12 +200,4 @@ or
See [HTTPS Configuration](https.html) for general information on configuring HTTPS.
-To enable HTTPS in Brooklyn, add the following to your brooklyn.cfg:
-
-{% highlight properties %}
-brooklyn.webconsole.security.https.required=true
-brooklyn.webconsole.security.keystore.url=<path-to-keystore-directory>/server.key
-brooklyn.webconsole.security.keystore.password=mypassword
-brooklyn.webconsole.security.keystore.certificate.alias=brooklyn
-{% endhighlight %}
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/972aa0d7/guide/ops/configuration/cors.md
----------------------------------------------------------------------
diff --git a/guide/ops/configuration/cors.md b/guide/ops/configuration/cors.md
index 03fefd6..ab2cd05 100644
--- a/guide/ops/configuration/cors.md
+++ b/guide/ops/configuration/cors.md
@@ -4,7 +4,7 @@ layout: website-normal
---
To enable / configure [cross-origin resource sharing (CORS)](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing).
-The following file must be added to [`<brooklyn-config-directory>/org.apache.brooklyn.rest.filter.cors.cfg`](../paths.html)
+The following file must be added to [`org.apache.brooklyn.rest.filter.cors.cfg`](../paths.html)
{% highlight properties %}
# Enables experimental support for Cross Origin Resource Sharing (CORS) filtering in Apache Brooklyn REST API.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/972aa0d7/guide/ops/configuration/https.md
----------------------------------------------------------------------
diff --git a/guide/ops/configuration/https.md b/guide/ops/configuration/https.md
index debb4f0..12515c5 100644
--- a/guide/ops/configuration/https.md
+++ b/guide/ops/configuration/https.md
@@ -21,7 +21,7 @@ The passwords above should be changed to your own values. Omit those arguments
You will then be prompted to enter your name and organization details. This will use (or create, if it does not exist)
a keystore with the password `mypassword` - you should use your own secure password, which will be the same password
-used in your brooklyn.cfg (below). You will also need to replace `<path-to-keystore-directory>` with the full
+used in your `brooklyn.cfg` (below). You will also need to replace `<path-to-keystore-directory>` with the full
path of the folder where you wish to store your keystore. The keystore will contain the newly generated key,
with alias `brooklyn` and password `password`.
@@ -44,9 +44,20 @@ and then convert it into a keystore `keystore.jks` as follows:
{% endhighlight %}
-## Configuring Brooklyn for HTTPS
+## HTTPS Configuration
-How to do this depends on whether you are using the traditional or the Karaf distribution. See either of
+In [`org.ops4j.pax.web.cfg`](../paths.html) in the Brooklyn distribution root, un-comment the settings:
-* [Traditional Distribution](brooklyn_cfg.html#https-configuration)
-* [Karaf Distribution](osgi-configuration.html#https-configuration)
+{% highlight properties %}
+org.osgi.service.http.port.secure=8443
+org.osgi.service.http.secure.enabled=true
+org.ops4j.pax.web.ssl.keystore=${karaf.home}/etc/keystores/keystore.jks
+org.ops4j.pax.web.ssl.password=password
+org.ops4j.pax.web.ssl.keypassword=password
+org.ops4j.pax.web.ssl.clientauthwanted=false
+org.ops4j.pax.web.ssl.clientauthneeded=false
+{% endhighlight %}
+
+replacing the passwords with appropriate values, and restart the server. Note the keystore location is relative to
+the installation root, but a fully qualified path can also be given, if it is desired to use some separate pre-existing
+store.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/972aa0d7/guide/ops/configuration/index.md
----------------------------------------------------------------------
diff --git a/guide/ops/configuration/index.md b/guide/ops/configuration/index.md
index 327d55c..fde9d89 100644
--- a/guide/ops/configuration/index.md
+++ b/guide/ops/configuration/index.md
@@ -7,7 +7,6 @@ children:
- { section: Authentication }
- brooklyn_cfg.md
- https.md
-- osgi-configuration.md
- cors.md
---
@@ -18,6 +17,34 @@ to a [brooklyn.cfg](brooklyn_cfg.html) file when the Karaf release became the de
The configurations for [persistence](../persistence/index.html) and [high availability](../high-availability/index.html) are described
elsewhere in this manual.
+Configuration of Apache Brooklyn when running under Karaf is largely done through standard Karaf mechanisms.
+The Karaf "Configuration Admin" subsystem is used to manage configuration values loaded at first boot from the
+`.cfg` files in the `etc` directory of the distribution. In the Karaf command line these can then be viewed
+and manipulated by the `config:` commands, see the [Karaf documentation](https://karaf.apache.org/manual/latest/) for full details.
+
+## Configuring Brooklyn Properties
+
+To configure the Brooklyn runtime create an `etc/brooklyn.cfg` file. If you have previously used `brooklyn.properties` it follows the same
+file format. Values can be viewed and managed dynamically via the OSGI configuration admin commands in Karaf,
+e.g. `config:property-set`. The global `~/.brooklyn/brooklyn.properties` is still supported and has higher
+priority for duplicate keys, but it's values can't be manipulated with the Karaf commands, so its use is
+discouraged.
+
+You can use the standard `~/.brooklyn/brooklyn.properties` file to configure Brooklyn. Alternatively
+create `etc/brooklyn.cfg` inside the distribution folder (same file format). The keys in the former override
+those in the latter.
+
+Web console related configuration is done through the corresponding Karaf mechanisms:
+
+ * The port is set in `etc/org.ops4j.pax.web.cfg`, key `org.osgi.service.http.port`.
+ * For authentication the JAAS realm "webconsole" is used; by default it will use any
+ SecurityProvider implementations configured in Brooklyn falling back to auto generating
+ the password. To configure a custom JAAS realm see the `jetty.xml` file in
+ `brooklyn-server/karaf/jetty-config/src/main/resources`
+ and override it by creating a custom one in `etc` folder. Point the "webconsole" login service
+ to the JAAS realm you would like to use.
+ * For other Jetty related configuration consult the Karaf and pax-web docs.
+
### Memory Usage
The amount of memory required by Apache Brooklyn process depends on the usage - for example the number of entities/VMs under management.
@@ -46,5 +73,71 @@ Users and passwords for Brooklyn can be configured in the brooklyn.cfg as detail
### HTTPS Configuration
-For information on securing your Apache Brooklyn installation with HTTPS, please refer to the pages on [setting up a certificate and keystore](https.html) and
-[configuring this in Brooklyn](osgi-configuration.html#https-configuration).
\ No newline at end of file
+See [HTTPS Configuration](https.html) for general information on configuring HTTPS.
+
+
+<!--
+----------
+-- NOTE: comment out this section on catalog as the behaviour described is not enabled by default since
+-- https://github.com/apache/brooklyn-server/pull/233; re-enable this when that changes
+----------
+## Catalog in Karaf
+With the traditional launcher, Brooklyn loads the initial contents of the catalog from a `default.catalog.bom` file
+as described in the section on [installation](/guide/ops/production-installation.html). Brooklyn finds Java
+implementations to provide for certain things in blueprints (entities, enrichers etc.) by scanning the classpath.
+
+In the OSGI world this approach is not used, as each bundle only has visibility of its own and its imported Java packages.
+Instead, in Karaf, each bundle can declare its own `catalog.bom` file, in the root of the bundle,
+with the catalog declarations for any entities etc. that the bundle contains.
+
+For example, the `catalog.bom` file for Brooklyn's Webapp bundle looks like (abbreviated):
+
+ brooklyn.catalog:
+ version: ...
+ items:
+ - id: org.apache.brooklyn.entity.webapp.nodejs.NodeJsWebAppService
+ itemType: entity
+ item:
+ type: org.apache.brooklyn.entity.webapp.nodejs.NodeJsWebAppService
+ name: Node.JS Application
+ ...
+ - id: resilient-bash-web-cluster-template
+ itemType: template
+ name: "Template: Resilient Load-Balanced Bash Web Cluster with Sensors"
+ description: |
+ Sample YAML to provision a cluster of the bash/python web server nodes,
+ with sensors configured, and a load balancer pointing at them,
+ and resilience policies for node replacement and scaling
+ item:
+ name: Resilient Load-Balanced Bash Web Cluster (Brooklyn Example)
+
+In the above YAML the first item declares that the bundle provides an entity whose type is
+`org.apache.brooklyn.entity.webapp.nodejs.NodeJsWebAppService`, and whose name is 'Node.JS Application'. The second
+item declares that the bundle provides a template application, with id `resilient-bash-web-cluster-template`, and
+includes a description for what this is.
+
+## Configuring the applications in the Catalog
+
+When running some particular deployment of Brooklyn it may not be desirable for the sample applications to appear in
+the catalog (for clarity, "application" here in the sense of an item with `itemType: template`).
+For example, if you have developed
+some bundle with your own application and added it to Karaf then you might want only your own application to appear in
+the catalog.
+
+Brooklyn contains a mechanism to allow you to configure what bundles will add their applications to the catalog.
+The Karaf configuration file `/etc/org.apache.brooklyn.core.catalog.bomscanner.cfg` contains two properties,
+one `whitelist` and the other `blacklist`, that bundles must satisfy for their applications to be added to the catalog.
+Each property value is a comma-separated list of regular expressions. The symbolic id of the bundle must match one of
+the regular expressions on the whitelist, and not match any expression on the blacklist, if its applications
+are to be added to the bundle. The default values of these properties are to admit all bundles, and forbid none.
+
+## Caveats
+
+In the OSGi world specifying class names by string in Brooklyn's configuration will work only
+for classes living in Brooklyn's core modules. Raise an issue or ping us on IRC if you find
+a case where this doesn't work for you. For custom SecurityProvider implementations refer to the
+documentation of BrooklynLoginModule.
+
+ END Catalog in Karaf comment -->
+
+
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/972aa0d7/guide/ops/configuration/osgi-configuration.md
----------------------------------------------------------------------
diff --git a/guide/ops/configuration/osgi-configuration.md b/guide/ops/configuration/osgi-configuration.md
deleted file mode 100644
index 2dfa681..0000000
--- a/guide/ops/configuration/osgi-configuration.md
+++ /dev/null
@@ -1,119 +0,0 @@
----
-title: OSGi Configuration
-layout: website-normal
----
-
-Configuration of Apache Brooklyn when running under Karaf is largely done through standard Karaf mechanisms.
-The Karaf "Configuration Admin" subsystem is used to manage configuration values loaded at first boot from the
-`.cfg` files in the `etc` directory of the distribution. In the Karaf command line these can then be viewed
-and manipulated by the `config:` commands, see the [Karaf documentation](https://karaf.apache.org/manual/latest/) for full details.
-
-## Configuring Brooklyn Properties
-
-To configure the Brooklyn runtime create an `etc/brooklyn.cfg` file, following the standard `brooklyn.properties`
-file format. Values can be viewed and managed dynamically via the OSGI configuration admin commands in Karaf,
-e.g. `config:property-set`. The global `~/.brooklyn/brooklyn.properties` is still supported and has higher
-priority for duplicate keys, but it's values can't be manipulated with the Karaf commands, so its use is
-discouraged.
-
-You can use the standard `~/.brooklyn/brooklyn.properties` file to configure Brooklyn. Alternatively
-create `etc/brooklyn.cfg` inside the distribution folder (same file format). The keys in the former override
-those in the latter.
-
-Web console related configuration is done through the corresponding Karaf mechanisms:
-
- * The port is set in `etc/org.ops4j.pax.web.cfg`, key `org.osgi.service.http.port`.
- * For authentication the JAAS realm "webconsole" is used; by default it will use any
- SecurityProvider implementations configured in Brooklyn falling back to auto generating
- the password. To configure a custom JAAS realm see the `jetty.xml` file in
- `brooklyn-server/karaf/jetty-config/src/main/resources`
- and override it by creating a custom one in `etc` folder. Point the "webconsole" login service
- to the JAAS realm you would like to use.
- * For other Jetty related configuration consult the Karaf and pax-web docs.
-
-## HTTPS Configuration
-
-See [HTTPS Configuration](https.html) for general information on configuring HTTPS.
-
-In `etc/org.ops4j.pax.web.cfg` in the Brooklyn Karaf distribution root, un-comment the settings:
-
-{% highlight properties %}
-org.osgi.service.http.port.secure=8443
-org.osgi.service.http.secure.enabled=true
-org.ops4j.pax.web.ssl.keystore=${karaf.home}/etc/keystores/keystore.jks
-org.ops4j.pax.web.ssl.password=password
-org.ops4j.pax.web.ssl.keypassword=password
-org.ops4j.pax.web.ssl.clientauthwanted=false
-org.ops4j.pax.web.ssl.clientauthneeded=false
-{% endhighlight %}
-
-replacing the passwords with appropriate values, and restart the server. Note the keystore location is relative to
-the installation root, but a fully qualified path can also be given, if it is desired to use some separate pre-existing
-store.
-
-
-<!--
-----------
--- NOTE: comment out this section on catalog as the behaviour described is not enabled by default since
--- https://github.com/apache/brooklyn-server/pull/233; re-enable this when that changes
-----------
-## Catalog in Karaf
-With the traditional launcher, Brooklyn loads the initial contents of the catalog from a `default.catalog.bom` file
-as described in the section on [installation](/guide/ops/production-installation.html). Brooklyn finds Java
-implementations to provide for certain things in blueprints (entities, enrichers etc.) by scanning the classpath.
-
-In the OSGI world this approach is not used, as each bundle only has visibility of its own and its imported Java packages.
-Instead, in Karaf, each bundle can declare its own `catalog.bom` file, in the root of the bundle,
-with the catalog declarations for any entities etc. that the bundle contains.
-
-For example, the `catalog.bom` file for Brooklyn's Webapp bundle looks like (abbreviated):
-
- brooklyn.catalog:
- version: ...
- items:
- - id: org.apache.brooklyn.entity.webapp.nodejs.NodeJsWebAppService
- itemType: entity
- item:
- type: org.apache.brooklyn.entity.webapp.nodejs.NodeJsWebAppService
- name: Node.JS Application
- ...
- - id: resilient-bash-web-cluster-template
- itemType: template
- name: "Template: Resilient Load-Balanced Bash Web Cluster with Sensors"
- description: |
- Sample YAML to provision a cluster of the bash/python web server nodes,
- with sensors configured, and a load balancer pointing at them,
- and resilience policies for node replacement and scaling
- item:
- name: Resilient Load-Balanced Bash Web Cluster (Brooklyn Example)
-
-In the above YAML the first item declares that the bundle provides an entity whose type is
-`org.apache.brooklyn.entity.webapp.nodejs.NodeJsWebAppService`, and whose name is 'Node.JS Application'. The second
-item declares that the bundle provides a template application, with id `resilient-bash-web-cluster-template`, and
-includes a description for what this is.
-
-## Configuring the applications in the Catalog
-
-When running some particular deployment of Brooklyn it may not be desirable for the sample applications to appear in
-the catalog (for clarity, "application" here in the sense of an item with `itemType: template`).
-For example, if you have developed
-some bundle with your own application and added it to Karaf then you might want only your own application to appear in
-the catalog.
-
-Brooklyn contains a mechanism to allow you to configure what bundles will add their applications to the catalog.
-The Karaf configuration file `/etc/org.apache.brooklyn.core.catalog.bomscanner.cfg` contains two properties,
-one `whitelist` and the other `blacklist`, that bundles must satisfy for their applications to be added to the catalog.
-Each property value is a comma-separated list of regular expressions. The symbolic id of the bundle must match one of
-the regular expressions on the whitelist, and not match any expression on the blacklist, if its applications
-are to be added to the bundle. The default values of these properties are to admit all bundles, and forbid none.
-
-## Caveats
-
-In the OSGi world specifying class names by string in Brooklyn's configuration will work only
-for classes living in Brooklyn's core modules. Raise an issue or ping us on IRC if you find
-a case where this doesn't work for you. For custom SecurityProvider implementations refer to the
-documentation of BrooklynLoginModule.
-
- END Catalog in Karaf comment -->
-
-
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/972aa0d7/guide/ops/high-availability/high-availability-supplemental.md
----------------------------------------------------------------------
diff --git a/guide/ops/high-availability/high-availability-supplemental.md b/guide/ops/high-availability/high-availability-supplemental.md
index 33f597f..8cd564b 100644
--- a/guide/ops/high-availability/high-availability-supplemental.md
+++ b/guide/ops/high-availability/high-availability-supplemental.md
@@ -3,7 +3,7 @@ title: Configuring HA - an example
layout: website-normal
---
-This supplements the [High Availability](../) documentation
+This supplements the [High Availability](./) documentation
and provides an example of how to configure a pair of Apache Brooklyn servers to run in master-standby mode with a shared NFS datastore
### Prerequisites
@@ -12,14 +12,14 @@ and provides an example of how to configure a pair of Apache Brooklyn servers to
- An NFS folder has been mounted on both VMs at `/mnt/brooklyn-persistence` and both machines can write to the folder
\* Brooklyn can be configured to use either an object store such as S3, or a shared NFS mount. The recommended option is to use an object
-store as described in the [Object Store Persistence]({{ site.path.operations }}/ops/persistence/#object-store-persistence) documentation. For simplicity, a shared NFS folder
+store as described in the [Object Store Persistence](../persistence/#object-store-persistence) documentation. For simplicity, a shared NFS folder
is assumed in this example
### Launching
To start, download and install the latest Apache Brooklyn release on both VMs following the instructions in
-[Running Apache Brooklyn]({{ site.path.tutorials }}/start/running.html)
+[Running Apache Brooklyn]({{ site.path.guide }}/start/running.html)
-On the first VM, which will be the master node, set the following configuration options:
+On the first VM, which will be the master node, set the following configuration options in [`org.apache.brooklyn.osgilauncher.cfg`](../paths.html):
- highAvailabilityMode: MASTER
- persistMode: AUTO
@@ -31,10 +31,10 @@ Then launch Brooklyn with:
$ bin/start
{% endhighlight %}
-If you are using RPMs/deb to install, please see the [Running Apache Brooklyn]({{ site.path.tutorials }}/start/running.html)
+If you are using RPMs/deb to install, please see the [Running Apache Brooklyn]({{ site.path.guide }}/start/running.html)
documentation for the appropriate launch commands
-Once Brooklyn has launched, on the second VM, set the following configuration options ([`org.apache.brooklyn.osgilauncher.cfg`](../paths.html)):
+Once Brooklyn has launched, on the second VM, set the following configuration options in [`org.apache.brooklyn.osgilauncher.cfg`](../paths.html):
- highAvailabilityMode: AUTO
- persistMode: AUTO
@@ -51,7 +51,7 @@ When running as a HA standby node, each standby Brooklyn server (in this case th
every one second to determine the state of the HA master. If no heartbeat has been recorded for 30 seconds, then an election will be performed
and one of the standby nodes will be promoted to master. At this point all requests should be directed to the new master node.
If the master is terminated gracefully, the secondary will be immediately promoted to mater. Otherwise, the secondary will be promoted after
-heartbeats are missed for a given length of time. This defaults to 30 seconds, and is configured in brooklyn.cfg using
+heartbeats are missed for a given length of time. This defaults to 30 seconds, and is configured in `brooklyn.cfg` using
`brooklyn.ha.heartbeatTimeout`
In the event that tasks - such as the provisioning of a new entity - are running when a failover occurs, the new master will display the current
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/972aa0d7/guide/ops/security-guidelines.md
----------------------------------------------------------------------
diff --git a/guide/ops/security-guidelines.md b/guide/ops/security-guidelines.md
index 453612c..5dddf9b 100644
--- a/guide/ops/security-guidelines.md
+++ b/guide/ops/security-guidelines.md
@@ -37,7 +37,7 @@ relevant mount points, disks and directories.
For credential storage, users are strongly encouraged to consider using the "externalised
configuration" feature. This allows credentials to be retrieved from a store managed by you,
-rather than being stored within YAML blueprints or brooklyn.cfg.
+rather than being stored within YAML blueprints or `brooklyn.cfg`.
A secure credential store is strongly recommended, such as use of
[HashiCorp's Vault](https://www.vaultproject.io) - see
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/972aa0d7/guide/start/brooklyn.properties
----------------------------------------------------------------------
diff --git a/guide/start/brooklyn.properties b/guide/start/brooklyn.properties
index fc23bc9..c1e4ab4 100644
--- a/guide/start/brooklyn.properties
+++ b/guide/start/brooklyn.properties
@@ -17,8 +17,8 @@
# under the License.
#
# This is Brooklyn's dot-properties file.
-# It should be located at "brooklyn.cfg" for automatic loading,
-# or can be specified as a CLI option with --localProperties /path/to/these.properties.
+# It should be located at "~/.brooklyn/brooklyn.properties" for automatic loading. It is
+# now deprecated, please refer to brooklyn.cfg on http://brooklyn.apache.org for more information.
################################## Welcome! ############################################
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/972aa0d7/guide/start/running.md
----------------------------------------------------------------------
diff --git a/guide/start/running.md b/guide/start/running.md
index a8d5032..7298ec3 100644
--- a/guide/start/running.md
+++ b/guide/start/running.md
@@ -182,7 +182,7 @@ Apache Brooklyn should now have been installed and be running as a system servic
$ systemctl start|stop|restart|status brooklyn
{% endhighlight %}
-The application should then output its logs to `/var/log/brooklyn/brooklyn.debug.log` and `/var/log/brooklyn/brooklyn.info.log`.
+The application should then output its logs to `brooklyn.debug.log` and `brooklyn.info.log`, please refer to the [paths]({{ site.path.guide }}/ops/paths.html) page for the locations of these.
</div>
<div id="impl-3" class="tab-pane fade">
@@ -195,7 +195,7 @@ Apache Brooklyn should now have been installed and be running as a system servic
$ sudo service brooklyn start|stop|restart|status
{% endhighlight %}
-The application should then output its logs to `/var/log/brooklyn/brooklyn.debug.log` and `/var/log/brooklyn/brooklyn.info.log`.
+The application should then output its logs to `brooklyn.debug.log` and `brooklyn.info.log`, please refer to the [paths]({{ site.path.guide }}/ops/paths.html) page for the locations of these.
</div>
<div id="impl-4" class="tab-pane fade">
@@ -208,7 +208,7 @@ Now start Apache Brooklyn with the following command:
$ bin/start
{% endhighlight %}
-The application should then output its log to `./data/log/brooklyn.debug.log` and `./data/log/brooklyn.info.log`
+The application should then output its log to `brooklyn.debug.log` and `brooklyn.info.log`, please refer to the [paths]({{ site.path.guide }}/ops/paths.html) page for the locations of these.
</div>
<div id="impl-5" class="tab-pane fade">