anchor.diff:  set lww.truststore '/path/to/solr-ssl.truststore.jks'
   set lww.truststore.password 'secret'
   
  -[TIP]
  -====
  -The path (and secret configurations) should be the same in all YARN/MapReduce hosts.
  -====
  -
  -//end::ssl-pig[]
  -
  +TIP: The paths (and secret configurations) should be the same in all YARN/MapReduce hosts.
  +
  +// end::pig-solr[]
  +
  +// tag::pig-fusion[]
  +=== Indexing Data to Fusion
  +When indexing data to Fusion, there are several parameters to pass with your script in order to output data to Fusion for indexing.
  +
  +These parameters can be made into variables in the script, with the proper values passed on the command line when the script is initiated. The example script below shows how to do this for Solr. The theory is the same for Fusion, only the parameter names would change as appropriate:
  +
  +`fusion.endpoints`::
  +The full URL to the index pipeline in Fusion. The URL should include the pipeline name and the collection data will be indexed to.
  +
  +`fusion.realm`::
  +This is used with `fusion.user` and `fusion.password` to authenticate to Fusion for indexing data. Two options are supported, `KERBEROS` or `NATIVE`.
  ++
  +Kerberos authentication is supported with the additional definition of a JAAS file. The properties `java.security.auth.login.config` and `fusion.jaas.appname` are used to define the location of the JAAS file and the section of the file to use. These are described in more detail below.
  ++
  +Native authentication uses a Fusion-defined username and password. This user must exist in Fusion, and have the proper permissions to index documents.
  +
  +`fusion.user`::
  +The Fusion username or Kerberos principal to use for authentication to Fusion.
  ++
  +If a Fusion username is used (`'fusion.realm' = 'NATIVE'`), the `fusion.password` must also be supplied.
  +
  +`fusion.pass`::
  +This property is not shown in the example above. The password for the `fusion.user` when the `fusion.realm` is `NATIVE`.
  +
  +==== Indexing to a Kerberized Fusion Installation
  +When Fusion is secured with Kerberos, Pig scripts must include the full path to a JAAS file that includes the service principal and the path to a keytab file that will be used to index the output of the script to Fusion.
  +
  +Additionally, a Kerberos ticket must be obtained on the server for the principal using `kinit`.
  +
  +`java.security.auth.login.config`::
  +This property defines the path to a JAAS file that contains a service principal and keytab location for a user who is authorized to write to Fusion.
  ++
  +The JAAS configuration file *must* be copied to the same path on every node where a Node Manager is running (i.e., every node where map/reduce tasks are executed). Here is a sample section of a JAAS file:
  ++
  +[source]
  +Client { --<1>
  +  com.sun.security.auth.module.Krb5LoginModule required
  +  useKeyTab=true
  +  keyTab="/data/fusion-indexer.keytab" --<2>
  +  storeKey=true
  +  useTicketCache=true
  +  debug=true
  +  principal="fusion-indexer@FUSIONSERVER.COM"; --<3>
  +};
  ++
  +<1> The name of this section of the JAAS file. This name will be used with the `fusion.jaas.appname` parameter.
  +<2> The location of the keytab file.
  +<3> The service principal name. This should be a different principal than the one used for Fusion, but must have access to both Fusion and Pig. This name is used with the `fusion.user` parameter described above.
  +
  +`fusion.jaas.appname`::
  +Used only when indexing to or reading from Fusion when it is secured with Kerberos.
  ++
  +This property provides the name of the section in the JAAS file that includes the correct service principal and keytab path.
  +
  +// end::pig-fusion[]
  +//end::use-pig[]
   
   // tag::example-pig[]
   === Sample CSV Script
  
positive.code: [listing, subs="attributes"]
  solr-pig-functions/build/libs/{packageUser}-pig-functions-{connectorVersion}.jar
  
  The .jar is required to use Pig functions to index content to Solr.
  
  === Troubleshooting
  
  If GitHub + SSH is not configured the following exception will be thrown:
  
  
negative.code: // tag::use-pig[]
  == Using the Functions
  
  // tag::pig-register[]
  === Register the Functions
  There are two approaches to using functions in Pig: `REGISTER` them in the script, or load them with your Pig command line request.
  
  If using `REGISTER`, the Pig function jars must be put in HDFS in order to be used by your Pig script. It can be located anywhere in HDFS; you can either supply the path in your script or use a variable and define the variable with `-p` property definition.
  
  The example below uses the second approach, loading the jars with the `-Dpig.additional.jars` system property when launching the script. With this approach, the jars can be located anywhere on the machine where the script will be run.
  // end::pig-register[]
  
  // tag::pig-solr[]
  === Indexing Data to Solr
  
  There are a few required parameters for your script to output data to Solr for indexing.
  
  These parameters can be defined in the script itself, or turned into variables that are defined each time the script runs. The example Pig script below shows an example of using these parameters with variables.
  
  `solr.zkhost`::
  The ZooKeeper connection string if using Solr in SolrCloud mode. This should be in the form of `server:port,server:port,server:port/chroot`.
  
  If you are not using SolrCloud, use the `solr.server.url` parameter instead.
  
  `solr.server.url`::
  The location of the Solr instance when Solr is running in standalone mode. This should be in the form of `\http://server:port/solr`.
  
  `solr.collection`::
  The name of the Solr collection where documents will be indexed.
  
  ==== Indexing to a Kerberos-Secured Solr Cluster
  
  When a Solr cluster is secured with Kerberos for internode communication, Pig scripts must include the full path to a JAAS file that includes the service principal and the path to a keytab file that will be used to index the output of the script to Solr.
  
  