You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lucene.apache.org by ho...@apache.org on 2017/05/05 17:11:07 UTC
lucene-solr:jira/solr-10290: manual cleanup of w-z
Repository: lucene-solr
Updated Branches:
refs/heads/jira/solr-10290 adf8959db -> bf84e407e
manual cleanup of w-z
Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/bf84e407
Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/bf84e407
Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/bf84e407
Branch: refs/heads/jira/solr-10290
Commit: bf84e407e6111a694f689cd2a7fc34c1376d9b17
Parents: adf8959
Author: Chris Hostetter <ho...@apache.org>
Authored: Fri May 5 10:09:26 2017 -0700
Committer: Chris Hostetter <ho...@apache.org>
Committed: Fri May 5 10:10:57 2017 -0700
----------------------------------------------------------------------
solr/solr-ref-guide/src/working-with-dates.adoc | 10 +++++-----
.../src/working-with-external-files-and-processes.adoc | 13 ++++++++++---
solr/solr-ref-guide/src/zookeeper-access-control.adoc | 12 ++++++------
3 files changed, 21 insertions(+), 14 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/bf84e407/solr/solr-ref-guide/src/working-with-dates.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/working-with-dates.adoc b/solr/solr-ref-guide/src/working-with-dates.adoc
index 09cac9c..7d45034 100644
--- a/solr/solr-ref-guide/src/working-with-dates.adoc
+++ b/solr/solr-ref-guide/src/working-with-dates.adoc
@@ -53,7 +53,7 @@ Solr's `DateRangeField` supports the same point in time date syntax described ab
* `[2014 TO 2014-12-01]` – From the start of 2014 till the end of the first day of December.
* `[* TO 2014-12-01]` – From the earliest representable time thru till the end of the day on 2014-12-01.
-Limitations: The range syntax doesn't support embedded date math. If you specify a date instance supported by TrieDateField with date math truncating it, like `NOW/DAY`, you still get the first millisecond of that day, not the entire day's range. Exclusive ranges (using `{` & }) work in _queries_ but not for _indexing_ ranges.
+Limitations: The range syntax doesn't support embedded date math. If you specify a date instance supported by TrieDateField with date math truncating it, like `NOW/DAY`, you still get the first millisecond of that day, not the entire day's range. Exclusive ranges (using `{` & `}`) work in _queries_ but not for _indexing_ ranges.
[[WorkingwithDates-DateMath]]
== Date Math
@@ -106,12 +106,12 @@ By default, all date math expressions are evaluated relative to the UTC TimeZone
For example, the following request will use range faceting to facet over the current month, "per day" relative UTC:
-[source,java]
+[source,text]
----
http://localhost:8983/solr/my_collection/select?q=*:*&facet.range=my_date_field&facet=true&facet.range.start=NOW/MONTH&facet.range.end=NOW/MONTH%2B1MONTH&facet.range.gap=%2B1DAY
----
-[source,java]
+[source,xml]
----
<int name="2013-11-01T00:00:00Z">0</int>
<int name="2013-11-02T00:00:00Z">0</int>
@@ -125,12 +125,12 @@ http://localhost:8983/solr/my_collection/select?q=*:*&facet.range=my_date_field&
While in this example, the "days" will be computed relative to the specified time zone - including any applicable Daylight Savings Time adjustments:
-[source,java]
+[source,text]
----
http://localhost:8983/solr/my_collection/select?q=*:*&facet.range=my_date_field&facet=true&facet.range.start=NOW/MONTH&facet.range.end=NOW/MONTH%2B1MONTH&facet.range.gap=%2B1DAY&TZ=America/Los_Angeles
----
-[source,java]
+[source,xml]
----
<int name="2013-11-01T07:00:00Z">0</int>
<int name="2013-11-02T07:00:00Z">0</int>
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/bf84e407/solr/solr-ref-guide/src/working-with-external-files-and-processes.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/working-with-external-files-and-processes.adoc b/solr/solr-ref-guide/src/working-with-external-files-and-processes.adoc
index c8ef653..9ad960c 100644
--- a/solr/solr-ref-guide/src/working-with-external-files-and-processes.adoc
+++ b/solr/solr-ref-guide/src/working-with-external-files-and-processes.adoc
@@ -41,7 +41,12 @@ If any files using the name pattern `.*` (such as `.txt`) appear, the last (afte
The file contains entries that map a key field, on the left of the equals sign, to a value, on the right. Here are a few example entries:
-`doc33=1.414` `doc34=3.14159` `doc40=42`
+[source,text]
+----
+doc33=1.414
+doc34=3.14159
+doc40=42
+----
The keys listed in this file do not need to be unique. The file does not need to be sorted, but Solr will be able to perform the lookup faster if it is.
@@ -141,8 +146,7 @@ The fully qualified class name to use when specifying this format via the `parse
The serialization format supported by this parser is as follows:
-*Serialization format*
-
+.Serialization format
[source,text]
----
content ::= version (stored)? tokens
@@ -193,6 +197,9 @@ Token positions are tracked and implicitly added to the token stream - the start
[[WorkingwithExternalFilesandProcesses-Exampletokenstreams]]
==== Example token streams
+// TODO: in cwiki each of these examples was in it's own "panel" ... do we want something like that here?
+// TODO: these examples match what was in cwiki, but I'm honestly not sure if the formatting there was correct to start?
+
[source,text]
----
1 one two three
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/bf84e407/solr/solr-ref-guide/src/zookeeper-access-control.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/zookeeper-access-control.adoc b/solr/solr-ref-guide/src/zookeeper-access-control.adoc
index 55c2b68..c5befa6 100644
--- a/solr/solr-ref-guide/src/zookeeper-access-control.adoc
+++ b/solr/solr-ref-guide/src/zookeeper-access-control.adoc
@@ -63,8 +63,8 @@ You control which ACLs will be added by configuring `zkACLProvider` property in
You can always make you own implementation, but Solr comes with:
-* `org.apache.solr.common.cloud.DefaultZkACLProvider: `It returns a list of length one for all `zNodePath`-s. The single ACL entry in the list is "open-unsafe". This is the default.
-* `org.apache.solr.common.cloud.VMParamsAllAndReadonlyDigestZkACLProvider:` This lets you define your ACLs using system properties. Its `getACLsToAdd()` implementation does not use `zNodePath` for anything, so all znodes will get the same set of ACLs. It supports adding one or both of these options:
+* `org.apache.solr.common.cloud.DefaultZkACLProvider`: It returns a list of length one for all `zNodePath`-s. The single ACL entry in the list is "open-unsafe". This is the default.
+* `org.apache.solr.common.cloud.VMParamsAllAndReadonlyDigestZkACLProvider`: This lets you define your ACLs using system properties. Its `getACLsToAdd()` implementation does not use `zNodePath` for anything, so all znodes will get the same set of ACLs. It supports adding one or both of these options:
** A user that is allowed to do everything.
*** The permission is "```ALL```" (corresponding to all of `CREATE`, `READ`, `WRITE`, `DELETE`, and `ADMIN`), and the schema is "digest".
*** The username and password are defined by system properties "```zkDigestUsername```" and "```zkDigestPassword```", respectively.
@@ -73,7 +73,7 @@ You can always make you own implementation, but Solr comes with:
*** The permission is "```READ```" and the schema is "digest".
*** The username and password are defined by system properties "```zkDigestReadonlyUsername```" and "```zkDigestReadonlyPassword```", respectively.
*** This ACL will not be added to the list of ACLs unless both username and password are provided.
-* `org.apache.solr.common.cloud.SaslZkACLProvider:` Requires SASL authentication. Gives all permissions for the user specified in system property `solr.authorization.superuser` (default: `solr`) when using SASL, and gives read permissions for anyone else. Designed for a setup where configurations have already been set up and will not be modified, or where configuration changes are controlled via Solr APIs. This provider will be useful for administration in a kerberos environment. In such an environment, the administrator wants Solr to authenticate to ZooKeeper using SASL, since this is only way to authenticate with ZooKeeper via Kerberos.
+* `org.apache.solr.common.cloud.SaslZkACLProvider`: Requires SASL authentication. Gives all permissions for the user specified in system property `solr.authorization.superuser` (default: `solr`) when using SASL, and gives read permissions for anyone else. Designed for a setup where configurations have already been set up and will not be modified, or where configuration changes are controlled via Solr APIs. This provider will be useful for administration in a kerberos environment. In such an environment, the administrator wants Solr to authenticate to ZooKeeper using SASL, since this is only way to authenticate with ZooKeeper via Kerberos.
If none of the above ACLs is added to the list, the (empty) ACL list of `DefaultZkACLProvider` will be used by default.
@@ -84,7 +84,7 @@ You can give the readonly credentials to "clients" of your SolrCloud cluster - e
// OLD_CONFLUENCE_ID: ZooKeeperAccessControl-bin/solr&solr.cmd,server/scripts/cloud-scripts/zkcli.sh&zkcli.bat
[[ZooKeeperAccessControl-bin_solr_solr.cmd_server_scripts_cloud-scripts_zkcli.sh_zkcli.bat]]
-=== `bin/solr` & `solr.cmd`,` server/scripts/cloud-scripts/zkcli.sh` &` zkcli.bat`
+=== `bin/solr` & `solr.cmd`, `server/scripts/cloud-scripts/zkcli.sh` & `zkcli.bat`
These Solr scripts can enable use of ZK ACLs by setting the appropriate system properties: uncomment the following and replace the passwords with ones you choose to enable the above-described VM parameters ACL and credentials providers in the following files:
@@ -141,9 +141,9 @@ Over the lifetime of operating your Solr cluster, you may decide to move from an
Changing ACLs in ZK should only be done while your SolrCloud cluster is stopped. Attempting to do so while Solr is running may result in inconsistent state and some nodes becoming inaccessible.
-The VM properties `zkACLProvider` and` zkCredentialsProvider`, included in the `SOLR_ZK_CREDS_AND_ACLS` environment variable in `zkcli.sh/.bat`, control the conversion:
+The VM properties `zkACLProvider` and `zkCredentialsProvider`, included in the `SOLR_ZK_CREDS_AND_ACLS` environment variable in `zkcli.sh/.bat`, control the conversion:
* The Credentials Provider must be one that has current admin privileges on the nodes. When omitted, the process will use no credentials (suitable for an unsecure configuration).
* The ACL Provider will be used to compute the new ACLs. When omitted, the process will set all permissions to all users, removing any security present.
-The uncommented `SOLR_ZK_CREDS_AND_ACLS` environment variable in` zkcli.sh/.bat` sets the credentials and ACL providers to the `VMParamsSingleSetCredentialsDigestZkCredentialsProvider` and `VMParamsAllAndReadonlyDigestZkACLProvider` implementations, described earlier in the page.
+The uncommented `SOLR_ZK_CREDS_AND_ACLS` environment variable in `zkcli.sh/.bat` sets the credentials and ACL providers to the `VMParamsSingleSetCredentialsDigestZkCredentialsProvider` and `VMParamsAllAndReadonlyDigestZkACLProvider` implementations, described earlier in the page.