lucene-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Solr Wiki] Update of "Editing configuration files in the admin UI" by ErickErickson
Date Sat, 16 Nov 2013 19:52:53 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The "Editing configuration files in the admin UI" page has been changed by ErickErickson:
https://wiki.apache.org/solr/Editing%20configuration%20files%20in%20the%20admin%20UI?action=diff&rev1=1&rev2=2

  = Editing configuration files in the admin UI =
  
- New to Solr 4.7 is the ability to edit the various files in a core (or collection) via the
admin UI. After you select a core in the admin UI, you should see a link to "TBD". Clicking
on this link will allow you to traverse the files in the conf directory and sub-directories.
Clicking on a file will open up an editable text box and you'll be able to edit the contents
of the file. When you're done editing you can click the "save" button. Yes, it's that simple.
+ <<TableOfContents>>
  
- <<TableOfContents>>
+ New to Solr 4.7 is the ability to edit the various files in a core (or collection) via the
admin UI. After you select a core in the admin UI, you should see a link to "files". Clicking
on this link will allow you to traverse the files in the conf directory and sub-directories.
Clicking on a file will open up an editable text box and you'll be able to edit the contents
of the file. When you're done editing you can click the "Save File" button. Yes, it's that
simple.
  
  This works in both stand-alone and SolrCloud mode.
  
@@ -12, +12 @@

  
  == Reload your core or collection ==
  
- You ''must'' reload your core (or collection) to have your changes take effect. Failing
to do this will cause you to ask "why didn't my changes take effect?".
+ You ''must'' reload your core (or collection) to have your changes take effect. Failing
to do this will cause you to ask "why didn't my changes work?".
  
  (TBD) There is a button on the edit screen to issue the reload command.
  
- <!> Note: reloading a ''core'' only reloads that instance. Other shards/replicas,
whatever will not have these changes. However, reloading a ''collection'' in SolrCloud mode
will cause the saved changes to be loaded on all the replicas of the collection.
+ <!> Note: Reloading a ''collection'' in SolrCloud mode will cause the saved changes
to be loaded on all the replicas of the collection. When operating in non-SolrCloud mode,
you need to insure that your changes are propagated to all the shards/slaves in your cluster,
see the section ''SolrCloud .vs. non-SolrCloud''
  
  == Disabling ==
  
- This capability is enabled by default. It can be disabled by defining the "admin/file" file
handler. The stock example solrconfig.xml file has a commented-out section that shows how
to do this, but here's what you need to do:
+ This capability is enabled by default. It can be disabled by configuring the "admin/file"
file handler. The stock example solrconfig.xml file has a commented-out section that shows
how to do this; here's an example:
  
+ {{{
+   <requestHandler name="/admin/file" class="solr.admin.ShowFileRequestHandler" >
+     <lst name="invariants">
+       <str name="hidden">*</str>
+     </lst>
+   </requestHandler>
+ }}}
+ 
+ The regex is really stupid, the ''only'' pattern currently supported is a single asterisk.
Patterns like *.xml are '''not''' supported at this point. 
+ 
+ You can disable individual files by creating entries with specific names, e.g. 
  {{{
    <requestHandler name="/admin/file" class="solr.admin.ShowFileRequestHandler" >
      <lst name="invariants">
        <str name="hidden">synonyms.txt</str>
        <str name="hidden">anotherfile.txt</str>
-       <str name="hidden">*</str>
      </lst>
    </requestHandler>
  }}}
  
- The glob pattern currently ''only'' supports a single asterisk. Patterns like *.xml are
'''not''' supported at this point.
+ Currently there's no provision for specifying something like "only these files may be edited".
+ 
  
  == File permissions ==
  
@@ -61, +72 @@

   * Master/slave, 1 shard.
    * In this case, if you have configured your replication to replicate the files you're
changing ''and'' are editing on the master, the next replication will push the changes to
the slaves.
    * Otherwise, you'll need to manually distribute the changes to all the nodes.
-  * Multiple shards (master/slave or not). Personally, I wouldn't use this capability in
this situation on my live cluster. I'd get my configurations right on a stand-alone, single-shard
machine and then use whatever automated scripts (you are automating pushing configs to all
the nodes, right?) to push the changes out once I was satisfied with them.
+  * Multiple shards (master/slave or not). Personally, I wouldn't use this capability in
this situation on my live cluster. I'd get my configurations right on a stand-alone, single-shard
machine and then use whatever automated scripts (you ''are'' automating pushing configs to
all the masters, and you ''have'' configured your replication to bring down all the config
files you care about, right?) to push the changes out once I was satisfied with them.
  
  
  == Managed schemas ==

Mime
View raw message