It is not just a directory. There is a security feature that only
allows to read from several file locations (configurable in solr.xml).
Userfiles is part of default list, so whatever replacement is there
will need to be explicitly-named as well.

Regards,
   Alex.

On Fri, 25 Sep 2020 at 11:43, Jason Gerlowski <[email protected]> wrote:
>
> > You're left with the <solrhome>/filestore/ dir to put there what you want 
> > in standalone mode.
> That's fine by me as that's effectively what "userfiles" provides now.
> The main difference I imagine is that the 'filestore' directory won't
> exist at all in standalone? In that case standalone users will have to
> know where to create the dir if they want to reference 'filestore'
> files in their streaming expressions.  But that's not all that much
> more to ask I guess.
>
> I'm curious - is the filestore unimplemented in standalone because no
> one prioritized it, or is there a specific technical blocker?
>
> On Fri, Sep 25, 2020 at 11:24 AM David Smiley <[email protected]> wrote:
> >
> > The "userfiles" thing is merely a directory.  There's no CRUD API on it.  
> > Even if the CRUD API of the file store isn't active in standalone -- I 
> > think that doesn't matter.  You're left with the <solrhome>/filestore/ dir 
> > to put there what you want in standalone mode.
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
> >
> > On Fri, Sep 25, 2020 at 11:00 AM Ishan Chattopadhyaya 
> > <[email protected]> wrote:
> >>
> >> Standalone isn't supported.
> >>
> >> We need to transition away from the standalone mode and get rid of it 
> >> completely.
> >>
> >> On Fri, 25 Sep, 2020, 7:50 pm Jason Gerlowski, <[email protected]> 
> >> wrote:
> >>>
> >>> I don't know much about the new package/file-store, but it does sound
> >>> like a good replacement for 'userfiles' (which Eric is right- is
> >>> pretty awkward to work with).
> >>>
> >>> My only concerns with using the filestore would be around its
> >>> availability.  Is it enabled by default (or will it be in an upcoming
> >>> release)?  Does it work in standalone as well as SolrCloud?  If the
> >>> answer to those questions are both "yes", then it makes sense to me as
> >>> a replacement on the face of things.
> >>>
> >>> Jason
> >>>
> >>> On Fri, Sep 25, 2020 at 9:39 AM Eric Pugh
> >>> <[email protected]> wrote:
> >>> >
> >>> > +1.  I’ve found the user files really useful when doing things with 
> >>> > streaming, but it’s also awkward to reach to put files into.
> >>> >
> >>> >
> >>> > On Sep 25, 2020, at 8:47 AM, David Smiley <[email protected]> wrote:
> >>> >
> >>> > Yes.  And I think it's high time that coreRootDirectory default to 
> >>> > <solrhome>/something (e.g. "cores")
> >>> >
> >>> > ~ David Smiley
> >>> > Apache Lucene/Solr Search Developer
> >>> > http://www.linkedin.com/in/davidwsmiley
> >>> >
> >>> >
> >>> > On Fri, Sep 25, 2020 at 8:42 AM Alexandre Rafalovitch 
> >>> > <[email protected]> wrote:
> >>> >>
> >>> >> Would that file store also be under solr.home? Because if it is and
> >>> >> the user can upload core.property into it as well as other things that
> >>> >> core discovery will then load bypassing security....
> >>> >>
> >>> >> Regards,
> >>> >>   Alex.
> >>> >>
> >>> >> On Fri, 25 Sep 2020 at 08:32, David Smiley <[email protected]> wrote:
> >>> >> >
> >>> >> > I'm looking to see that we can deprecate "userfiles" and remove for 
> >>> >> > 9.0
> >>> >> >
> >>> >> > Solr has a "userfiles" directory under Solr home that Jason added in 
> >>> >> > some issue relating to streaming expressions accessing a local file. 
> >>> >> >  I bet only a few of you have even heard of it.  I think the "File 
> >>> >> > Store" that came along with the package manager obsoletes 
> >>> >> > "userfiles".  If you have not heard of the file store either, I 
> >>> >> > wouldn't be surprised -- it's new and it's name was changed from 
> >>> >> > "package store" last minute, since it's general purpose, with 
> >>> >> > "packages" being a directory at the root of the file store for 
> >>> >> > packages.  It's documented as the "package store" (should be 
> >>> >> > renamed) on the package manager internals doc: 
> >>> >> > https://lucene.apache.org/solr/guide/8_6/package-manager-internals.html#package-store
> >>> >> > However IMO it's worthy of its own doc page as it's a very useful 
> >>> >> > new component of the Solr platform.  It can store "user files" 
> >>> >> > (hence obsoleting the userfiles dir), ML models, or basically any 
> >>> >> > file that's too large to put in ZK.  I'd be nice if 
> >>> >> > SolrResourceLoader could resolve resources from it -- an issue for 
> >>> >> > another day.  That would be another avenue of use separate from the 
> >>> >> > configSet.  You can already upload single files to the file store :-)
> >>> >> >
> >>> >> > ~ David Smiley
> >>> >> > Apache Lucene/Solr Search Developer
> >>> >> > http://www.linkedin.com/in/davidwsmiley
> >>> >>
> >>> >> ---------------------------------------------------------------------
> >>> >> To unsubscribe, e-mail: [email protected]
> >>> >> For additional commands, e-mail: [email protected]
> >>> >>
> >>> >
> >>> > _______________________
> >>> > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 
> >>> > | http://www.opensourceconnections.com | My Free/Busy
> >>> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> >>> > This e-mail and all contents, including attachments, is considered to 
> >>> > be Company Confidential unless explicitly stated otherwise, regardless 
> >>> > of whether attachments are marked as such.
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [email protected]
> >>> For additional commands, e-mail: [email protected]
> >>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to