More file path and name updates

Author: arlake228

Diff for: config_bwctl.rst

@@ -2,7 +2,7 @@
 BWCTL Server Configuration File
 *********************************
 
-By default, the /etc/bwctld/bwctld.conf on the perfSONAR toolkit uses the following ports:
+By default, the /etc/bwctl-server/bwctl-server.conf on the perfSONAR toolkit uses the following ports:
 
    .. code-block:: none
 
@@ -15,8 +15,8 @@ By default, the /etc/bwctld/bwctld.conf on the perfSONAR toolkit uses the follow
 You can edit that file if you want to change those port ranges. Note that if you make the port
 range too small, tests to/from your host will fail. 
 
-You can also control what tests are allowed using bwctld.conf. For example, if want to allow
-bwctld to run low bandwidth tools like ping and owping, but not throughput tools, you can use 'disable_[tool name]'.
+You can also control what tests are allowed using bwctl-server.conf. For example, if want to allow
+bwctl-server to run low bandwidth tools like ping and owping, but not throughput tools, you can use 'disable_[tool name]'.
 For example:
 
    .. code-block:: none
@@ -27,6 +27,6 @@ For example:
     disable_nuttcp
 
 
-More information on bwctld.conf is available at:
+More information on bwctl-server.conf is available at:
   * http://software.internet2.edu/bwctl/bwctld.conf.man.html
 

Diff for: config_bwctl_limits.rst

@@ -2,14 +2,14 @@
 BWCTL Limits File
 ******************
 
-You can control access to the bwctl server via the file /etc/bwctld/bwctld.limits.
+You can control access to the bwctl server via the file /etc/bwctl-server/bwctl-server.limits.
 
 Information on how to use this file can be found at:
   * http://software.internet2.edu/bwctl/bwctld.limits.man.html
 
 By default, the perfSONAR toolkit allows access from anywhere, and limits TCP tests to 30 seconds, and UDP tests to 900Mbps and 30 seconds.
 
-ESnet generates a nighly update of bwctld.limits that allows testing from all Research and Education networks around the world, and nothing else.
+ESnet generates a nighly update of bwctl-server.limits that allows testing from all Research and Education networks around the world, and nothing else.
 
 Information on how to use this file is available at:
   * http://fasterdata.es.net/performance-testing/perfsonar/esnet-perfsonar-services/esnet-bwctld-limits-file/

Diff for: config_files.rst

@@ -52,7 +52,7 @@ Log Files
 Primary Log file
 ##########################
 :Description: BWCTL servers and clients can each write to log files. The location of the log file is dependent on your syslog configuration. The entries in this table assume a default configuration. 
-:RedHat: **RPM Only**: ``/var/log/messages`` **Toolkit or Complete Install:** ``/var/log/perfsonar/owamp_bwctl.log``
+:RedHat: **RPM Only**: ``/var/log/messages`` **Toolkit:** ``/var/log/perfsonar/owamp_bwctl.log``
 :Debian: ``/var/log/messages`` 
 
 
@@ -337,7 +337,7 @@ Log Files
 Primary Log file
 ##########################
 :Description: OWAMP servers and clients can each write to log files. The location of the log file is dependent on your syslog configuration. The entries in this table assume a default configuration. 
-:RedHat: **RPM Only**: ``/var/log/messages`` **Toolkit or Complete Install:** ``/var/log/perfsonar/owamp_bwctl.log``
+:RedHat: **RPM Only**: ``/var/log/messages`` **Toolkit:** ``/var/log/perfsonar/owamp_bwctl.log``
 :Debian: ``/var/log/messages`` 
 
 Regular Testing

Diff for: config_ls_registration.rst

@@ -5,7 +5,7 @@ Lookup Service Registration Daemon Configuration File
 Overview
 ========
 
-The file *ls_registration_daemon.conf* is used to define what gets registered into the lookup service. The file allows a degree of flexibility in what is manually defined versus what is automatically discovered. In most cases, the defaults of this file will be suitable and you should not need to make any changes. Some situations where you might want to edit this file though are (this is not an exhaustive list):
+The file *lsregistrationdaemon.conf* is used to define what gets registered into the lookup service. The file allows a degree of flexibility in what is manually defined versus what is automatically discovered. In most cases, the defaults of this file will be suitable and you should not need to make any changes. Some situations where you might want to edit this file though are (this is not an exhaustive list):
 
 * You have a private lookup service and would like to only register to that service. See :ref:`config_ls_registration-ls_instance`
 * You have a host with multiple network interfaces and would like to choose the interface on which a particular service or set of services run
@@ -19,9 +19,9 @@ The basic structure of the file is as follows:
 * A list of :ref:`host <config_ls_registration-host>` directives within those sites that represent the host to be registered. If the host in question is the host on which the LS Registration Daemon is running, than many of the values can be auto-discovered. 
 * A list of :ref:`service <config_ls_registration-service>` directives within those hosts that represent the services to be registered. 
 
-The *ls_registration_daemon.conf* has the feature that almost any directive can be defined at a higher level in the configuration hierarchy and be inherited by all the descendents. For example, one can define the :ref:`latitude <config_ls_registration-latitude>` and :ref:`longitude <config_ls_registration-longitude>` directives at the top-level of the file. All registered hosts and services will in turn inherit these properties. In contrast, you can define them directly in each host directive if you want each individual host to have different values. You can even define both and have the more specific values in the host directive override the ones defined at a higher level in the hierarchy. 
+The *lsregistrationdaemon.conf* has the feature that almost any directive can be defined at a higher level in the configuration hierarchy and be inherited by all the descendents. For example, one can define the :ref:`latitude <config_ls_registration-latitude>` and :ref:`longitude <config_ls_registration-longitude>` directives at the top-level of the file. All registered hosts and services will in turn inherit these properties. In contrast, you can define them directly in each host directive if you want each individual host to have different values. You can even define both and have the more specific values in the host directive override the ones defined at a higher level in the hierarchy. 
 
-With these items in mind the remainder of this section contains a full reference of the options available in the *ls_registration_daemon.conf* file. 
+With these items in mind the remainder of this section contains a full reference of the options available in the *lsregistrationdaemon.conf* file. 
 
 
 

Diff for: config_mesh.rst

@@ -204,7 +204,7 @@ write_url Directive
 :Occurrences:  Exactly one
 :Compatibility: 3.3, ignored in 3.4, supported again in 3.5 or later
 
-This is the URL where tools, such as regular_testing on the perfSONAR Toolkit, should send results. This value is only useful if your measurement archive is using IP authentication. if using API key authentication, you will need to define the measurement archive in your local regular_testing.conf file. This is because it is not safe for the MeshConfig to share login credentials in it's current form and would be difficult to manage in a large mesh. 
+This is the URL where tools, such as regular-testing on the perfSONAR Toolkit, should send results. This value is only useful if your measurement archive is using IP authentication. if using API key authentication, you will need to define the measurement archive in your local regulartesting.conf file. This is because it is not safe for the MeshConfig to share login credentials in it's current form and would be difficult to manage in a large mesh. 
 
 Defining Test Parameters
 ========================

Diff for: config_owamp.rst

@@ -2,7 +2,7 @@
 OWAMP Server Configuration File
 *************************************
 
-By default, the /etc/owampd/owampd.conf on the perfSONAR toolkit uses the following ports:
+By default, the /etc/owamp-server/owamp-server.conf on the perfSONAR toolkit uses the following ports:
 
    .. code-block:: none
 
@@ -11,6 +11,6 @@ By default, the /etc/owampd/owampd.conf on the perfSONAR toolkit uses the follow
 You can edit that file if you want to change those port ranges. Note that if you make the port
 range too small, tests to/from your host will fail.
 
-More information on owampd.conf is available at:
+More information on owamp-server.conf is available at:
   * http://software.internet2.edu/owamp/owampd.conf.man.html
 

Diff for: config_owamp_limits.rst

@@ -2,7 +2,7 @@
 OWAMP Limits Configuration File
 **************************************
 
-You can control the total traffic load to the owamp server via the file /etc/owampd/owampd.limits.
+You can control the total traffic load to the owamp server via the file /etc/owamp-server/owamp-server.limits.
 
 By default, the perfSONAR Toolkit allows up to 10Mbps of owamp traffic.
 

Diff for: multi_ma_install.rst

@@ -208,15 +208,9 @@ Given all the information above, lets look at an example where we want to regist
 
 After adding the above to you configuration you will need to restart your regular testing:
 
-**RedHat/CentOS**::
-
-    /sbin/service regular_testing restart
-    
-**Debian**::
-
     /etc/init.d/perfsonar-regulartesting restart
 
-.. note:: If you central measurement archive goes down for any reason, the regular_testing daemon will queue results on the local disk under the :ref:`test results directory <config_regular_testing-test_result_directory>` as specified in your :ref:`regular_testing.conf <config_files-regtesting-conf-main>` file. It will try to register any results on disk when your measurement archive returns. Since accumulating too many files can cause trouble for disk space and/or the regular_testing daemon's ability to keep up with registering data, these files are cleaned nightly on toolkit installations. 
+.. note:: If you central measurement archive goes down for any reason, the regular_testing daemon will queue results on the local disk under the :ref:`test results directory <config_regular_testing-test_result_directory>` as specified in your :ref:`regulartesting.conf <config_files-regtesting-conf-main>` file. It will try to register any results on disk when your measurement archive returns. Since accumulating too many files can cause trouble for disk space and/or the regular_testing daemon's ability to keep up with registering data, these files are cleaned nightly on toolkit installations. 
 
 Registering to Multiple Measurement Archives
 --------------------------------------------

Diff for: multi_mesh_autoconfig.rst

@@ -273,7 +273,7 @@ You'll also want to make sure the following is set if you would like to use the
 
 .. note:: This *configure_archives* option assumes the measurement archive provided by the mesh configuration file has :ref:`IP authentication <multi_ma_install-auth_ip>` setup for this host. This is because the mesh configuration cannot securely distribute usernames and API keys. See the :ref:`measurement archive documentation <multi_ma_install-auth_ip>` for information on how to configure IP authentication on your archive server. 
 
-You'll also want to set the following if you are NOT using a Toolkit deployment or the perfSONAR-Complete bundle::
+You'll also want to set the following if you are NOT using a Toolkit deployment::
 
     use_toolkit 0