[
https://issues.apache.org/jira/browse/SOLR-17671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17927824#comment-17927824
]
ASF subversion and git services commented on SOLR-17671:
--------------------------------------------------------
Commit fa099a0e7505e6de0fa487ce326f3031d8654cd4 in solr's branch
refs/heads/main from Bruno Roustant
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=fa099a0e750 ]
SOLR-17671: Replication and Backup use an unwrapped Directory to copy files.
(#3185)
New extensible method CachingDirectoryFactory.filterDirectory.
> Replication and Backup should use an unwrapped Directory when copying files.
> ----------------------------------------------------------------------------
>
> Key: SOLR-17671
> URL: https://issues.apache.org/jira/browse/SOLR-17671
> Project: Solr
> Issue Type: Improvement
> Reporter: Bruno Roustant
> Priority: Major
> Labels: pull-request-available
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> Currently Replication and Backup copy files using a Directory created with
> the configured DirectoryFactory. This Directory may be a FilterDirectory that
> adds additional logic (e.g. encryption) that should not run when copying
> files (e.g. do not decrypt).
> The proposal is to add a new REPLICATE value in the
> DirectoryFactory.DirContext that would be used by replication and a new
> BACKUP for backup to get the Directory to use. The DirectoryFactory would
> unwrap the Directory in this case.
> One could expect that only one REPLICATE could be enough, but backup requires
> more inner checksum verifications that may need to differentiate the logic
> between the two (this is the case for encryption).
> Example:
> In the solr-sandbox encryption module, we would need a way to unwrap the
> Directory used to copy files during index fetching. Otherwise the files are
> decrypted by the EncryptionDirectory seamlessly during the files copy, ending
> up with follower replicas having cleartext index.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
