[Solr Wiki] Update of "Editing configuration files in the admin UI" by ErickErickson

[Apache Wiki <wi...@apache.org>]

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=4&rev2=5

Comment:
Removed all the text and put in warning so people don't try this as it doesn't work.

  = Editing configuration files in the admin UI =
  
- <<TableOfContents>>
  
+ {{{#!wiki red/solid
+ {X} X-( '''This capability was removed before release for security reasons. If we bring it back, we can revert this edit. See the discussion at: ''' https://issues.apache.org/jira/browse/SOLR-5287 {X} X-(
- 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.
- 
- But you're not quite done once you've saved the files.
- 
- == 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 work?".
- 
- (TBD) There is a button on the edit screen to issue the reload command.
- 
- <!> 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 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>
-     </lst>
-   </requestHandler>
- }}}
- 
- Currently there's no provision for specifying something like "only these files may be edited".
- 
- 
- == File permissions ==
- 
- Depending on how your system is set up, the user that Solr is running as may or may not have permissions to write to the conf directory for one or more cores and/or ZooKeeper. It is your responsibility to insure that the user configured to run Solr has the correct permissions else this will fail.
- 
- == Testing your changes ==
- 
- If we blindly put the files up in your collection, you could get into a state where you could no longer edit the files via the admin UI. The core must be successfully loaded to use the edit functionality, so if you couldn't load the core, you couldn't edit the file to correct the problem through the admin UI. To prevent this, when you save a file the following happens:
- 
-  * A temporary directory for a test core is created, using org.apache.commons.io.FileUtils.getTempDirectory()
-  * All of the configuration files for the current core are copied to that directory, either from local disk or from ZooKeeper
-  * Your new file is copied to the temporary directory
-  * The core will be loaded. NOTE: This core is '''not''' loaded the "regular" way, it is completely outside of the working cores. It will '''not''' appear in any dropdowns, you may not query it etc.
-  * If the test core is successfully loaded with the new changes, then (and only then) is the file saved to the core you're working on (local conf directory or ZooKeeper).
-   * Note that your 'live' core is ''not'' yet reloaded, you must do that as a separate action.
- 
- One consequence of this is that, especially in SolrCloud mode, saving changes may take a while.
- 
- == SolrCloud .vs. non-SolrCloud ==
- 
- These two modes behave a bit differently, you should be aware of the differences.
- 
- === SolrCloud ===
- 
- When you save a file when running in SolrCloud mode, that change is pushed to ZooKeeper. Changes will be distributed to all the replicas for the cluster ''when they reload or restart''. So it's important to understand that when you edit config files:
-  * You will be affecting all the replicas for that collection (upon reload/restart)
-  * When you reload the ''collection'' (as opposed to the core), all of the changes will be loaded onto all your replicas and they will be restarted. Neither the replica you're working on directly, nor any other nodes will have the new information until they're reloaded (or restarted).
- 
- === non-SolrCloud ===
- 
- For a single stand-alone node, reloading the core is sufficient to see all your changes take effect. If you have more than one node in your setup (master slave or shards), it's more complicated.
-  * 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 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 ==
- 
- There's the new "managed schema" kid in town that's really cool, especially for wizards & etc. The ability we're talking about here is a sledgehammer in comparison; it just blasts the entire file up to the server.
- 
- The managed schema relies on being able to effectively write out an in-memory structure to the managed-schema file.  If you manual edit the managed-schema file, your changes will be overwritten by any schema modification performed via the Schema REST API, or via Schemaless Mode.
- 
- It should be OK to use the managed schema alongside this all-file configuration editing as long as you don't edit the managed-schema file in the admin UI.
-