[ 
https://issues.apache.org/jira/browse/SOLR-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson updated SOLR-5287:
---------------------------------

    Attachment: SOLR-5287.patch
                SOLR-5287.patch

This may be ready to commit, running tests now.

It allows for disabling modifying conf files through through the admin/file 
handler. It allows updates of arbitrary files in the conf directory (e.g. 
velocity/error.vm).

I'm a little askance at the name of the file, ShowFileRequestHandler is a bit 
misleading, is it worth renaming to something like "ConfFileRequestHandler"?

It works with SolrCloud. Reloading the collection is required of course.

So if some kind person is able to make the Solr admin UI do some of things:
1> list files either in the conf directory or subdirectories and allow someone 
to pick one to edit.
2> post the edited files to Solr
3> perhaps provide a reload button on the editing page that may have to be 
sensitive to whether we're in SolrCloud mode or not, i.e. reload core or 
collection depending.
4> Extra special bonus: Do some kind of XML validation on the "save" step to 
insure it's well-formed.

Then we can wrap this up and put it out into the wild.

I think the UI work should be a separate JIRA.

This pretty much ignores the managed schema issues. But I _think_ that it's OK 
[~sarowe] do you agree? If people edit schema.xml without doing a reload, then 
use the managed schema stuff, then their edits are lost. That seems OK to me..

If there are no objections, I'll commit this over the weekend and we can make 
separate UI issues. I _really_ need somebody to step up and take the admin UI 
work [~steffkes] Are you there :). Or anyone else who really understands 
browsers.



> Allow at least solrconfig.xml and schema.xml to be edited via the admin screen
> ------------------------------------------------------------------------------
>
>                 Key: SOLR-5287
>                 URL: https://issues.apache.org/jira/browse/SOLR-5287
>             Project: Solr
>          Issue Type: Improvement
>          Components: Schema and Analysis, web gui
>    Affects Versions: 4.5, 5.0
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>         Attachments: SOLR-5287.patch, SOLR-5287.patch, SOLR-5287.patch
>
>
> A user asking a question on the Solr list got me to thinking about editing 
> the main config files from the Solr admin screen. I chatted briefly with 
> [~steffkes] about the mechanics of this on the browser side, he doesn't see a 
> problem on that end. His comment is there's no end point that'll write the 
> file back.
> Am I missing something here or is this actually not a hard problem? I see a 
> couple of issues off the bat, neither of which seem troublesome.
> 1> file permissions. I'd imagine lots of installations will get file 
> permission exceptions if Solr tries to write the file out. Well, do a 
> chmod/chown.
> 2> screwing up the system maliciously or not. I don't think this is an issue, 
> this would be part of the admin handler after all.
> Does anyone have objections to the idea? And how does this fit into the work 
> that [~sar...@syr.edu] has been doing?
> I can imagine this extending to SolrCloud with a "push this to ZK" option or 
> something like that, perhaps not in V1 unless it's easy.....
> Of course any pointers gratefully received. Especially ones that start with 
> "Don't waste your effort, it'll never work (or be accepted)"...
> Because what scares me is this seems like such an easy thing to do that would 
> be a significant ease-of-use improvement, so there _has_ to be something I'm 
> missing.
> So if we go forward with this we'll make this the umbrella JIRA, the two 
> immediate sub-JIRAs that spring to mind will be the UI work and the endpoints 
> for the UI work to use.
> I think there are only two end-points here
> 1> list all the files in the conf (or arbitrary from <solr_home>/collection) 
> directory.
> 2> write this text to this file
> Possibly later we could add "clone the configs from coreX to coreY".
> BTW, I've assigned this to myself so I don't lose it, but if anyone wants to 
> take it over it won't hurt my feelings a bit....



--
This message was sent by Atlassian JIRA
(v6.1#6144)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to