2012-11-20 20:43:58 +00:00
|
|
|
{- Amazon Glacier remotes.
|
|
|
|
-
|
2021-01-07 14:37:43 +00:00
|
|
|
- Copyright 2012-2021 Joey Hess <id@joeyh.name>
|
2012-11-20 20:43:58 +00:00
|
|
|
-
|
2019-03-13 19:48:14 +00:00
|
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
2012-11-20 20:43:58 +00:00
|
|
|
-}
|
|
|
|
|
incremental verify for byteRetriever special remotes
Several special remotes verify content while it is being retrieved,
avoiding a separate checksum pass. They are: S3, bup, ddar, and
gcrypt (with a local repository).
Not done when using chunking, yet.
Complicated by Retriever needing to change to be polymorphic. Which in turn
meant RankNTypes is needed, and also needed some code changes. The
change in Remote.External does not change behavior at all but avoids
the type checking failing because of a "rigid, skolem type" which
"would escape its scope". So I refactored slightly to make the type
checker's job easier there.
Unfortunately, directory uses fileRetriever (except when chunked),
so it is not amoung the improved ones. Fixing that would need a way for
FileRetriever to return a Verification. But, since the file retrieved
may be encrypted or chunked, it would be extra work to always
incrementally checksum the file while retrieving it. Hm.
Some other special remotes use fileRetriever, and so don't get incremental
verification, but could be converted to byteRetriever later. One is
GitLFS, which uses downloadConduit, which writes to the file, so could
verify as it goes. Other special remotes like web could too, but don't
use Remote.Helper.Special and so will need to be addressed separately.
Sponsored-by: Dartmouth College's DANDI project
2021-08-11 17:43:30 +00:00
|
|
|
{-# LANGUAGE RankNTypes #-}
|
|
|
|
|
2015-02-06 18:39:27 +00:00
|
|
|
module Remote.Glacier (remote, jobList, checkSaneGlacierCommand) where
|
2012-11-20 20:43:58 +00:00
|
|
|
|
|
|
|
import qualified Data.Map as M
|
2012-12-01 18:11:37 +00:00
|
|
|
import qualified Data.Text as T
|
2021-02-09 21:03:27 +00:00
|
|
|
import qualified Data.ByteString as S
|
2014-08-02 20:47:21 +00:00
|
|
|
import qualified Data.ByteString.Lazy as L
|
2012-11-20 20:43:58 +00:00
|
|
|
|
2016-01-20 20:36:33 +00:00
|
|
|
import Annex.Common
|
2012-11-20 20:43:58 +00:00
|
|
|
import Types.Remote
|
|
|
|
import qualified Git
|
|
|
|
import Config
|
2013-03-13 20:16:01 +00:00
|
|
|
import Config.Cost
|
2020-01-14 19:41:34 +00:00
|
|
|
import Annex.SpecialRemote.Config
|
2012-11-20 20:43:58 +00:00
|
|
|
import Remote.Helper.Special
|
2019-02-20 19:55:01 +00:00
|
|
|
import Remote.Helper.ExportImport
|
2012-11-20 20:43:58 +00:00
|
|
|
import qualified Remote.Helper.AWS as AWS
|
|
|
|
import Creds
|
2013-03-28 21:03:04 +00:00
|
|
|
import Utility.Metered
|
2013-09-07 22:38:00 +00:00
|
|
|
import Annex.UUID
|
2014-01-14 20:42:10 +00:00
|
|
|
import Utility.Env
|
2020-01-10 18:10:20 +00:00
|
|
|
import Types.ProposedAccepted
|
Fix build with ghc 9.0.1
Continuing along the same lines as commit
2739adc25814633b18174982977e00e809cb789e, it seems that
while Remote -> Retriever expands to the same data type this changes
it to, ghc 9.0.1 refuses to consider them equiviant. I guess it has
something to do with the forall?
The rest of the build all succeeds, although the stack build then crashes:
Linking .stack-work/dist/x86_64-linux-tinfo6/Cabal-3.4.0.0/build/git-annex/git-annex ...
Completed 233 action(s).
Prelude.chr: bad argument: 2214592520
This issue seems likely to be about it:
https://github.com/commercialhaskell/stack/pull/5508
I'm building with stack from debian, version 2.3.3, so a newer stack
probably avoids that. Anyway, despite that stack problem,
the git-annex binary is built, and works.
The stack.yaml I used for this build was patched as follows:
diff --git a/stack.yaml b/stack.yaml
index 8dac87c15..62c4b5b9d 100644
--- a/stack.yaml
+++ b/stack.yaml
@@ -1,6 +1,6 @@
flags:
git-annex:
- production: true
+ production: false
assistant: true
pairing: true
torrentparser: true
@@ -14,7 +14,7 @@ flags:
httpclientrestricted: true
packages:
- '.'
-resolver: lts-18.13
+resolver: nightly-2021-09-07
extra-deps:
- IfElse-0.85
- aws-0.22
Sponsored-by: Graham Spencer on Patreon
2021-12-08 19:08:02 +00:00
|
|
|
import Utility.Hash (IncrementalVerifier)
|
2012-11-20 20:43:58 +00:00
|
|
|
|
|
|
|
type Vault = String
|
|
|
|
type Archive = FilePath
|
|
|
|
|
|
|
|
remote :: RemoteType
|
2020-01-14 19:41:34 +00:00
|
|
|
remote = specialRemoteType $ RemoteType
|
2017-09-07 17:45:31 +00:00
|
|
|
{ typename = "glacier"
|
|
|
|
, enumerate = const (findSpecialRemotes "glacier")
|
|
|
|
, generate = gen
|
2020-01-14 19:41:34 +00:00
|
|
|
, configParser = mkRemoteConfigParser
|
|
|
|
[ optionalStringParser datacenterField
|
2020-01-20 19:20:04 +00:00
|
|
|
(FieldDesc "S3 datacenter to use")
|
2020-01-14 19:41:34 +00:00
|
|
|
, optionalStringParser vaultField
|
2020-01-20 19:20:04 +00:00
|
|
|
(FieldDesc "name to use for vault")
|
2020-01-14 19:41:34 +00:00
|
|
|
, optionalStringParser fileprefixField
|
2020-01-20 19:20:04 +00:00
|
|
|
(FieldDesc "prefix to add to filenames in the vault")
|
|
|
|
, optionalStringParser AWS.s3credsField HiddenField
|
2020-01-14 19:41:34 +00:00
|
|
|
]
|
2017-09-07 17:45:31 +00:00
|
|
|
, setup = glacierSetup
|
|
|
|
, exportSupported = exportUnsupported
|
2019-02-20 19:55:01 +00:00
|
|
|
, importSupported = importUnsupported
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
, thirdPartyPopulated = False
|
2017-09-07 17:45:31 +00:00
|
|
|
}
|
2012-11-20 20:43:58 +00:00
|
|
|
|
2020-01-14 19:41:34 +00:00
|
|
|
datacenterField :: RemoteConfigField
|
|
|
|
datacenterField = Accepted "datacenter"
|
|
|
|
|
|
|
|
vaultField :: RemoteConfigField
|
|
|
|
vaultField = Accepted "vault"
|
|
|
|
|
|
|
|
fileprefixField :: RemoteConfigField
|
|
|
|
fileprefixField = Accepted "fileprefix"
|
|
|
|
|
fix encryption of content to gcrypt and git-lfs
Fix serious regression in gcrypt and encrypted git-lfs remotes.
Since version 7.20200202.7, git-annex incorrectly stored content
on those remotes without encrypting it.
Problem was, Remote.Git enumerates all git remotes, including git-lfs
and gcrypt. It then dispatches to those. So, Remote.List used the
RemoteConfigParser from Remote.Git, instead of from git-lfs or gcrypt,
and that parser does not know about encryption fields, so did not
include them in the ParsedRemoteConfig. (Also didn't include other
fields specific to those remotes, perhaps chunking etc also didn't
get through.)
To fix, had to move RemoteConfig parsing down into the generate methods
of each remote, rather than doing it in Remote.List.
And a consequence of that was that ParsedRemoteConfig had to change to
include the RemoteConfig that got parsed, so that testremote can
generate a new remote based on an existing remote.
(I would have rather fixed this just inside Remote.Git, but that was not
practical, at least not w/o re-doing work that Remote.List already did.
Big ugly mostly mechanical patch seemed preferable to making git-annex
slower.)
2020-02-26 21:20:56 +00:00
|
|
|
gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
|
2023-01-12 17:42:28 +00:00
|
|
|
gen r u rc gc rs = do
|
|
|
|
c <- parsedRemoteConfig remote rc
|
|
|
|
cst <- remoteCost gc c veryExpensiveRemoteCost
|
|
|
|
return (new c cst)
|
2012-11-30 04:55:59 +00:00
|
|
|
where
|
fix encryption of content to gcrypt and git-lfs
Fix serious regression in gcrypt and encrypted git-lfs remotes.
Since version 7.20200202.7, git-annex incorrectly stored content
on those remotes without encrypting it.
Problem was, Remote.Git enumerates all git remotes, including git-lfs
and gcrypt. It then dispatches to those. So, Remote.List used the
RemoteConfigParser from Remote.Git, instead of from git-lfs or gcrypt,
and that parser does not know about encryption fields, so did not
include them in the ParsedRemoteConfig. (Also didn't include other
fields specific to those remotes, perhaps chunking etc also didn't
get through.)
To fix, had to move RemoteConfig parsing down into the generate methods
of each remote, rather than doing it in Remote.List.
And a consequence of that was that ParsedRemoteConfig had to change to
include the RemoteConfig that got parsed, so that testremote can
generate a new remote based on an existing remote.
(I would have rather fixed this just inside Remote.Git, but that was not
practical, at least not w/o re-doing work that Remote.List already did.
Big ugly mostly mechanical patch seemed preferable to making git-annex
slower.)
2020-02-26 21:20:56 +00:00
|
|
|
new c cst = Just $ specialRemote' specialcfg c
|
2020-05-13 15:50:31 +00:00
|
|
|
(store this)
|
|
|
|
(retrieve this)
|
|
|
|
(remove this)
|
|
|
|
(checkKey this)
|
2012-11-20 20:43:58 +00:00
|
|
|
this
|
2012-11-30 04:55:59 +00:00
|
|
|
where
|
2014-12-16 19:26:13 +00:00
|
|
|
this = Remote
|
|
|
|
{ uuid = u
|
|
|
|
, cost = cst
|
|
|
|
, name = Git.repoDescribe r
|
|
|
|
, storeKey = storeKeyDummy
|
2020-05-13 21:05:56 +00:00
|
|
|
, retrieveKeyFile = retrieveKeyFileDummy
|
|
|
|
, retrieveKeyFileCheap = Nothing
|
2018-06-21 15:35:27 +00:00
|
|
|
-- glacier-cli does not follow redirects and does
|
2018-06-21 18:14:56 +00:00
|
|
|
-- not support file://, as far as we know, but
|
|
|
|
-- there's no guarantee that will continue to be
|
|
|
|
-- the case, so require verifiable keys.
|
2018-09-25 19:32:50 +00:00
|
|
|
, retrievalSecurityPolicy = mkRetrievalVerifiableKeysSecure gc
|
2014-12-16 19:26:13 +00:00
|
|
|
, removeKey = removeKeyDummy
|
2015-10-08 19:01:38 +00:00
|
|
|
, lockContent = Nothing
|
2014-12-16 19:26:13 +00:00
|
|
|
, checkPresent = checkPresentDummy
|
|
|
|
, checkPresentCheap = False
|
2017-09-01 17:02:07 +00:00
|
|
|
, exportActions = exportUnsupported
|
2019-02-20 19:55:01 +00:00
|
|
|
, importActions = importUnsupported
|
2014-12-16 19:26:13 +00:00
|
|
|
, whereisKey = Nothing
|
|
|
|
, remoteFsck = Nothing
|
|
|
|
, repairRepo = Nothing
|
|
|
|
, config = c
|
2018-06-04 18:31:55 +00:00
|
|
|
, getRepo = return r
|
2014-12-16 19:26:13 +00:00
|
|
|
, gitconfig = gc
|
|
|
|
, localpath = Nothing
|
|
|
|
, readonly = False
|
2018-08-30 15:12:18 +00:00
|
|
|
, appendonly = False
|
2020-12-28 19:08:53 +00:00
|
|
|
, untrustworthy = False
|
2023-08-16 18:31:31 +00:00
|
|
|
, availability = pure GloballyAvailable
|
2014-12-16 19:26:13 +00:00
|
|
|
, remotetype = remote
|
|
|
|
, mkUnavailable = return Nothing
|
|
|
|
, getInfo = includeCredsInfo c (AWS.creds u) $
|
|
|
|
[ ("glacier vault", getVault c) ]
|
|
|
|
, claimUrl = Nothing
|
|
|
|
, checkUrl = Nothing
|
add RemoteStateHandle
This solves the problem of sameas remotes trampling over per-remote
state. Used for:
* per-remote state, of course
* per-remote metadata, also of course
* per-remote content identifiers, because two remote implementations
could in theory generate the same content identifier for two different
peices of content
While chunk logs are per-remote data, they don't use this, because the
number and size of chunks stored is a common property across sameas
remotes.
External special remote had a complication, where it was theoretically
possible for a remote to send SETSTATE or GETSTATE during INITREMOTE or
EXPORTSUPPORTED. Since the uuid of the remote is typically generate in
Remote.setup, it would only be possible to pass a Maybe
RemoteStateHandle into it, and it would otherwise have to construct its
own. Rather than go that route, I decided to send an ERROR in this case.
It seems unlikely that any existing external special remote will be
affected. They would have to make up a git-annex key, and set state for
some reason during INITREMOTE. I can imagine such a hack, but it doesn't
seem worth complicating the code in such an ugly way to support it.
Unfortunately, both TestRemote and Annex.Import needed the Remote
to have a new field added that holds its RemoteStateHandle.
2019-10-14 16:33:27 +00:00
|
|
|
, remoteStateHandle = rs
|
2014-12-16 19:26:13 +00:00
|
|
|
}
|
fix encryption of content to gcrypt and git-lfs
Fix serious regression in gcrypt and encrypted git-lfs remotes.
Since version 7.20200202.7, git-annex incorrectly stored content
on those remotes without encrypting it.
Problem was, Remote.Git enumerates all git remotes, including git-lfs
and gcrypt. It then dispatches to those. So, Remote.List used the
RemoteConfigParser from Remote.Git, instead of from git-lfs or gcrypt,
and that parser does not know about encryption fields, so did not
include them in the ParsedRemoteConfig. (Also didn't include other
fields specific to those remotes, perhaps chunking etc also didn't
get through.)
To fix, had to move RemoteConfig parsing down into the generate methods
of each remote, rather than doing it in Remote.List.
And a consequence of that was that ParsedRemoteConfig had to change to
include the RemoteConfig that got parsed, so that testremote can
generate a new remote based on an existing remote.
(I would have rather fixed this just inside Remote.Git, but that was not
practical, at least not w/o re-doing work that Remote.List already did.
Big ugly mostly mechanical patch seemed preferable to making git-annex
slower.)
2020-02-26 21:20:56 +00:00
|
|
|
specialcfg = (specialRemoteCfg c)
|
|
|
|
-- Disabled until jobList gets support for chunks.
|
|
|
|
{ chunkConfig = NoChunks
|
|
|
|
}
|
2012-11-20 20:43:58 +00:00
|
|
|
|
2017-02-07 18:35:58 +00:00
|
|
|
glacierSetup :: SetupStage -> Maybe UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
|
|
|
|
glacierSetup ss mu mcreds c gc = do
|
2013-09-07 22:38:00 +00:00
|
|
|
u <- maybe (liftIO genUUID) return mu
|
2017-02-07 18:35:58 +00:00
|
|
|
glacierSetup' ss u mcreds c gc
|
|
|
|
glacierSetup' :: SetupStage -> UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
|
|
|
|
glacierSetup' ss u mcreds c gc = do
|
fix embedcreds=yes reversion
Fix bug that made enableremote of S3 and webdav remotes, that have
embedcreds=yes, fail to set up the embedded creds, so accessing the remotes
failed.
(Regression introduced in version 7.20200202.7 in when reworking all the
remote configs to be parsed.)
Root problem is that parseEncryptionConfig excludes all other config keys
except encryption ones, so it is then unable to find the
credPairRemoteField. And since that field is not required to be
present, it proceeds as if it's not, rather than failing in any visible
way.
This causes it to not find any creds, and so it does not cache
them. When when the S3 remote tries to make a S3 connection, it finds no
creds, so assumes it's being used in no-creds mode, and tries to find a
public url. With no public url available, it fails, but the failure doesn't
say a lack of creds is the problem.
Fix is to provide setRemoteCredPair with a ParsedRemoteConfig, so the full
set of configs of the remote can be parsed. A bit annoying to need to
parse the remote config before the full config (as returned by
setRemoteCredPair) is available, but this avoids the problem.
I assume webdav also had the problem by inspection, but didn't try to
reproduce it with it.
Also, getRemoteCredPair used getRemoteConfigValue to get a ProposedAccepted
String, but that does not seem right. Now that it runs that code, it
crashed saying it had just a String.
Remotes that have already been enableremoted, and so lack the cached creds
file will work after this fix, because getRemoteCredPair will extract
the creds from the remote config, writing the missing file.
This commit was sponsored by Ilya Shlyakhter on Patreon.
2020-05-21 18:34:29 +00:00
|
|
|
(c', encsetup) <- encryptionSetup (c `M.union` defaults) gc
|
|
|
|
pc <- either giveup return . parseRemoteConfig c'
|
|
|
|
=<< configParser remote c'
|
2021-03-17 13:41:12 +00:00
|
|
|
c'' <- setRemoteCredPair ss encsetup pc gc (AWS.creds u) mcreds
|
fix embedcreds=yes reversion
Fix bug that made enableremote of S3 and webdav remotes, that have
embedcreds=yes, fail to set up the embedded creds, so accessing the remotes
failed.
(Regression introduced in version 7.20200202.7 in when reworking all the
remote configs to be parsed.)
Root problem is that parseEncryptionConfig excludes all other config keys
except encryption ones, so it is then unable to find the
credPairRemoteField. And since that field is not required to be
present, it proceeds as if it's not, rather than failing in any visible
way.
This causes it to not find any creds, and so it does not cache
them. When when the S3 remote tries to make a S3 connection, it finds no
creds, so assumes it's being used in no-creds mode, and tries to find a
public url. With no public url available, it fails, but the failure doesn't
say a lack of creds is the problem.
Fix is to provide setRemoteCredPair with a ParsedRemoteConfig, so the full
set of configs of the remote can be parsed. A bit annoying to need to
parse the remote config before the full config (as returned by
setRemoteCredPair) is available, but this avoids the problem.
I assume webdav also had the problem by inspection, but didn't try to
reproduce it with it.
Also, getRemoteCredPair used getRemoteConfigValue to get a ProposedAccepted
String, but that does not seem right. Now that it runs that code, it
crashed saying it had just a String.
Remotes that have already been enableremoted, and so lack the cached creds
file will work after this fix, because getRemoteCredPair will extract
the creds from the remote config, writing the missing file.
This commit was sponsored by Ilya Shlyakhter on Patreon.
2020-05-21 18:34:29 +00:00
|
|
|
pc' <- either giveup return . parseRemoteConfig c''
|
|
|
|
=<< configParser remote c''
|
2017-09-04 16:40:33 +00:00
|
|
|
case ss of
|
fix embedcreds=yes reversion
Fix bug that made enableremote of S3 and webdav remotes, that have
embedcreds=yes, fail to set up the embedded creds, so accessing the remotes
failed.
(Regression introduced in version 7.20200202.7 in when reworking all the
remote configs to be parsed.)
Root problem is that parseEncryptionConfig excludes all other config keys
except encryption ones, so it is then unable to find the
credPairRemoteField. And since that field is not required to be
present, it proceeds as if it's not, rather than failing in any visible
way.
This causes it to not find any creds, and so it does not cache
them. When when the S3 remote tries to make a S3 connection, it finds no
creds, so assumes it's being used in no-creds mode, and tries to find a
public url. With no public url available, it fails, but the failure doesn't
say a lack of creds is the problem.
Fix is to provide setRemoteCredPair with a ParsedRemoteConfig, so the full
set of configs of the remote can be parsed. A bit annoying to need to
parse the remote config before the full config (as returned by
setRemoteCredPair) is available, but this avoids the problem.
I assume webdav also had the problem by inspection, but didn't try to
reproduce it with it.
Also, getRemoteCredPair used getRemoteConfigValue to get a ProposedAccepted
String, but that does not seem right. Now that it runs that code, it
crashed saying it had just a String.
Remotes that have already been enableremoted, and so lack the cached creds
file will work after this fix, because getRemoteCredPair will extract
the creds from the remote config, writing the missing file.
This commit was sponsored by Ilya Shlyakhter on Patreon.
2020-05-21 18:34:29 +00:00
|
|
|
Init -> genVault pc' gc u
|
2017-09-04 16:40:33 +00:00
|
|
|
_ -> return ()
|
fix embedcreds=yes reversion
Fix bug that made enableremote of S3 and webdav remotes, that have
embedcreds=yes, fail to set up the embedded creds, so accessing the remotes
failed.
(Regression introduced in version 7.20200202.7 in when reworking all the
remote configs to be parsed.)
Root problem is that parseEncryptionConfig excludes all other config keys
except encryption ones, so it is then unable to find the
credPairRemoteField. And since that field is not required to be
present, it proceeds as if it's not, rather than failing in any visible
way.
This causes it to not find any creds, and so it does not cache
them. When when the S3 remote tries to make a S3 connection, it finds no
creds, so assumes it's being used in no-creds mode, and tries to find a
public url. With no public url available, it fails, but the failure doesn't
say a lack of creds is the problem.
Fix is to provide setRemoteCredPair with a ParsedRemoteConfig, so the full
set of configs of the remote can be parsed. A bit annoying to need to
parse the remote config before the full config (as returned by
setRemoteCredPair) is available, but this avoids the problem.
I assume webdav also had the problem by inspection, but didn't try to
reproduce it with it.
Also, getRemoteCredPair used getRemoteConfigValue to get a ProposedAccepted
String, but that does not seem right. Now that it runs that code, it
crashed saying it had just a String.
Remotes that have already been enableremoted, and so lack the cached creds
file will work after this fix, because getRemoteCredPair will extract
the creds from the remote config, writing the missing file.
This commit was sponsored by Ilya Shlyakhter on Patreon.
2020-05-21 18:34:29 +00:00
|
|
|
gitConfigSpecialRemote u c'' [("glacier", "true")]
|
|
|
|
return (c'', u)
|
2012-11-20 20:43:58 +00:00
|
|
|
where
|
2019-10-10 17:08:17 +00:00
|
|
|
remotename = fromJust (lookupName c)
|
2012-11-20 20:43:58 +00:00
|
|
|
defvault = remotename ++ "-" ++ fromUUID u
|
|
|
|
defaults = M.fromList
|
2020-01-15 15:05:07 +00:00
|
|
|
[ (datacenterField, Proposed $ T.unpack $ AWS.defaultRegion AWS.Glacier)
|
|
|
|
, (vaultField, Proposed defvault)
|
2012-11-20 20:43:58 +00:00
|
|
|
]
|
|
|
|
|
2020-05-13 15:50:31 +00:00
|
|
|
store :: Remote -> Storer
|
|
|
|
store r k b p = do
|
|
|
|
checkNonEmpty k
|
|
|
|
byteStorer (store' r) k b p
|
2014-08-02 20:47:21 +00:00
|
|
|
|
2020-05-13 15:50:31 +00:00
|
|
|
checkNonEmpty :: Key -> Annex ()
|
|
|
|
checkNonEmpty k
|
|
|
|
| fromKey keySize k == Just 0 =
|
|
|
|
giveup "Cannot store empty files in Glacier."
|
|
|
|
| otherwise = return ()
|
2012-11-25 17:42:28 +00:00
|
|
|
|
2020-05-13 18:03:00 +00:00
|
|
|
store' :: Remote -> Key -> L.ByteString -> MeterUpdate -> Annex ()
|
2020-05-13 15:50:31 +00:00
|
|
|
store' r k b p = go =<< glacierEnv c gc u
|
2012-11-25 17:27:20 +00:00
|
|
|
where
|
2012-11-30 04:55:59 +00:00
|
|
|
c = config r
|
2016-05-23 21:03:20 +00:00
|
|
|
gc = gitconfig r
|
2012-11-25 17:27:20 +00:00
|
|
|
u = uuid r
|
|
|
|
params = glacierParams c
|
2012-11-20 20:43:58 +00:00
|
|
|
[ Param "archive"
|
|
|
|
, Param "upload"
|
|
|
|
, Param "--name", Param $ archive r k
|
2012-11-30 04:55:59 +00:00
|
|
|
, Param $ getVault $ config r
|
2012-11-25 17:27:20 +00:00
|
|
|
, Param "-"
|
2012-11-20 20:43:58 +00:00
|
|
|
]
|
2020-05-13 18:03:00 +00:00
|
|
|
go Nothing = giveup "Glacier not usable."
|
2020-06-04 19:36:34 +00:00
|
|
|
go (Just e) =
|
2014-08-02 20:47:21 +00:00
|
|
|
let cmd = (proc "glacier" (toCommand params)) { env = Just e }
|
2020-06-04 19:36:34 +00:00
|
|
|
{ std_in = CreatePipe }
|
|
|
|
in liftIO $ withCreateProcess cmd (go' cmd)
|
2020-06-05 21:27:49 +00:00
|
|
|
go' cmd (Just hin) _ _ pid = do
|
2021-02-09 21:03:27 +00:00
|
|
|
meteredWrite p (S.hPut hin) b
|
2020-06-05 21:27:49 +00:00
|
|
|
hClose hin
|
|
|
|
forceSuccessProcess cmd pid
|
2020-06-04 19:36:34 +00:00
|
|
|
go' _ _ _ _ _ = error "internal"
|
2012-11-20 20:43:58 +00:00
|
|
|
|
Fix build with ghc 9.0.1
Continuing along the same lines as commit
2739adc25814633b18174982977e00e809cb789e, it seems that
while Remote -> Retriever expands to the same data type this changes
it to, ghc 9.0.1 refuses to consider them equiviant. I guess it has
something to do with the forall?
The rest of the build all succeeds, although the stack build then crashes:
Linking .stack-work/dist/x86_64-linux-tinfo6/Cabal-3.4.0.0/build/git-annex/git-annex ...
Completed 233 action(s).
Prelude.chr: bad argument: 2214592520
This issue seems likely to be about it:
https://github.com/commercialhaskell/stack/pull/5508
I'm building with stack from debian, version 2.3.3, so a newer stack
probably avoids that. Anyway, despite that stack problem,
the git-annex binary is built, and works.
The stack.yaml I used for this build was patched as follows:
diff --git a/stack.yaml b/stack.yaml
index 8dac87c15..62c4b5b9d 100644
--- a/stack.yaml
+++ b/stack.yaml
@@ -1,6 +1,6 @@
flags:
git-annex:
- production: true
+ production: false
assistant: true
pairing: true
torrentparser: true
@@ -14,7 +14,7 @@ flags:
httpclientrestricted: true
packages:
- '.'
-resolver: lts-18.13
+resolver: nightly-2021-09-07
extra-deps:
- IfElse-0.85
- aws-0.22
Sponsored-by: Graham Spencer on Patreon
2021-12-08 19:08:02 +00:00
|
|
|
retrieve :: forall a. Remote -> Key -> MeterUpdate -> Maybe IncrementalVerifier -> (ContentSource -> Annex a) -> Annex a
|
2020-05-13 15:50:31 +00:00
|
|
|
retrieve = byteRetriever . retrieve'
|
2014-08-02 20:47:21 +00:00
|
|
|
|
2021-09-07 20:53:07 +00:00
|
|
|
retrieve' :: forall a. Remote -> Key -> (L.ByteString -> Annex a) -> Annex a
|
2020-05-13 15:50:31 +00:00
|
|
|
retrieve' r k sink = go =<< glacierEnv c gc u
|
2012-11-25 17:42:28 +00:00
|
|
|
where
|
2012-11-30 04:55:59 +00:00
|
|
|
c = config r
|
2016-05-23 21:03:20 +00:00
|
|
|
gc = gitconfig r
|
2012-11-25 17:42:28 +00:00
|
|
|
u = uuid r
|
|
|
|
params = glacierParams c
|
2012-11-20 20:43:58 +00:00
|
|
|
[ Param "archive"
|
|
|
|
, Param "retrieve"
|
2012-11-25 17:42:28 +00:00
|
|
|
, Param "-o-"
|
2012-11-30 04:55:59 +00:00
|
|
|
, Param $ getVault $ config r
|
2012-11-20 20:43:58 +00:00
|
|
|
, Param $ archive r k
|
|
|
|
]
|
2016-11-16 01:29:54 +00:00
|
|
|
go Nothing = giveup "cannot retrieve from glacier"
|
2020-05-13 21:05:56 +00:00
|
|
|
go (Just environ) = do
|
2020-06-04 16:13:26 +00:00
|
|
|
let p = (proc "glacier" (toCommand params))
|
2020-05-13 21:05:56 +00:00
|
|
|
{ env = Just environ
|
2014-10-20 19:11:01 +00:00
|
|
|
, std_out = CreatePipe
|
|
|
|
}
|
2020-06-04 16:13:26 +00:00
|
|
|
bracketIO (createProcess p) cleanupProcess (go' p)
|
|
|
|
go' p (_, Just h, _, pid) = do
|
2020-05-13 21:05:56 +00:00
|
|
|
let cleanup = liftIO $ do
|
|
|
|
hClose h
|
2020-06-04 16:13:26 +00:00
|
|
|
forceSuccessProcess p pid
|
2020-05-13 21:05:56 +00:00
|
|
|
flip finally cleanup $ do
|
|
|
|
-- Glacier cannot store empty files, so if
|
|
|
|
-- the output is empty, the content is not
|
|
|
|
-- available yet.
|
|
|
|
whenM (liftIO $ hIsEOF h) $
|
|
|
|
giveup "Content is not available from glacier yet. Recommend you wait up to 4 hours, and then run this command again."
|
|
|
|
sink =<< liftIO (L.hGetContents h)
|
2020-06-04 16:13:26 +00:00
|
|
|
go' _ _ = error "internal"
|
2012-11-20 20:43:58 +00:00
|
|
|
|
run Preparer to get Remover and CheckPresent actions
This will allow special remotes to eg, open a http connection and reuse it,
while checking if chunks are present, or removing chunks.
S3 and WebDAV both need this to support chunks with reasonable speed.
Note that a special remote might want to cache a http connection across
multiple requests. A simple case of this is that CheckPresent is typically
called before Store or Remove. A remote using this interface can certianly
use a Preparer that eg, uses a MVar to cache a http connection.
However, it's up to the remote to then deal with things like stale or
stalled http connections when eg, doing a series of downloads from a remote
and other places. There could be long delays between calls to a remote,
which could lead to eg, http connection stalls; the machine might even
move to a new network, etc.
It might be nice to improve this interface later to allow
the simple case without needing to handle the full complex case.
One way to do it would be to have a `Transaction SpecialRemote cache`,
where SpecialRemote contains methods for Storer, Retriever, Remover, and
CheckPresent, that all expect to be passed a `cache`.
2014-08-06 18:28:36 +00:00
|
|
|
remove :: Remote -> Remover
|
toward SafeDropProof expiry checking
Added Maybe POSIXTime to SafeDropProof, which gets set when the proof is
based on a LockedCopy. If there are several LockedCopies, it uses the
closest expiry time. That is not optimal, it may be that the proof
expires based on one LockedCopy but another one has not expired. But
that seems unlikely to really happen, and anyway the user can just
re-run a drop if it fails due to expiry.
Pass the SafeDropProof to removeKey, which is responsible for checking
it for expiry in situations where that could be a problem. Which really
only means in Remote.Git.
Made Remote.Git check expiry when dropping from a local remote.
Checking expiry when dropping from a P2P remote is not yet implemented.
P2P.Protocol.remove has SafeDropProof plumbed through to it for that
purpose.
Fixing the remaining 2 build warnings should complete this work.
Note that the use of a POSIXTime here means that if the clock gets set
forward while git-annex is in the middle of a drop, it may say that
dropping took too long. That seems ok. Less ok is that if the clock gets
turned back a sufficient amount (eg 5 minutes), proof expiry won't be
noticed. It might be better to use the Monotonic clock, but that doesn't
advance when a laptop is suspended, and while there is the linux
Boottime clock, that is not available on other systems. Perhaps a
combination of POSIXTime and the Monotonic clock could detect laptop
suspension and also detect clock being turned back?
There is a potential future flag day where
p2pDefaultLockContentRetentionDuration is not assumed, but is probed
using the P2P protocol, and peers that don't support it can no longer
produce a LockedCopy. Until that happens, when git-annex is
communicating with older peers there is a risk of data loss when
a ssh connection closes during LOCKCONTENT.
2024-07-04 16:23:46 +00:00
|
|
|
remove r _proof k = unlessM go $
|
2020-05-14 18:08:09 +00:00
|
|
|
giveup "removal from glacier failed"
|
|
|
|
where
|
|
|
|
go = glacierAction r
|
|
|
|
[ Param "archive"
|
|
|
|
, Param "delete"
|
|
|
|
, Param $ getVault $ config r
|
|
|
|
, Param $ archive r k
|
|
|
|
]
|
2012-11-20 20:43:58 +00:00
|
|
|
|
run Preparer to get Remover and CheckPresent actions
This will allow special remotes to eg, open a http connection and reuse it,
while checking if chunks are present, or removing chunks.
S3 and WebDAV both need this to support chunks with reasonable speed.
Note that a special remote might want to cache a http connection across
multiple requests. A simple case of this is that CheckPresent is typically
called before Store or Remove. A remote using this interface can certianly
use a Preparer that eg, uses a MVar to cache a http connection.
However, it's up to the remote to then deal with things like stale or
stalled http connections when eg, doing a series of downloads from a remote
and other places. There could be long delays between calls to a remote,
which could lead to eg, http connection stalls; the machine might even
move to a new network, etc.
It might be nice to improve this interface later to allow
the simple case without needing to handle the full complex case.
One way to do it would be to have a `Transaction SpecialRemote cache`,
where SpecialRemote contains methods for Storer, Retriever, Remover, and
CheckPresent, that all expect to be passed a `cache`.
2014-08-06 18:28:36 +00:00
|
|
|
checkKey :: Remote -> CheckPresent
|
remove "checking remotename" message
This fixes fsck of a remote that uses chunking displaying
(checking remotename) (checking remotename)" for every chunk.
Also, some remotes displayed the message, and others did not, with no
consistency. It was originally displayed only when accessing remotes
that were expensive or might involve a password prompt, I think, but
nothing in the API said when to do it so it became an inconsistent mess.
Originally I thought fsck should always display it. But it only displays
in fsck --from remote, so the user knows the remote is being accessed,
so there is no reason to tell them it's accessing it over and over.
It was also possible for git-annex move to sometimes display it twice,
due to checking if content is present twice. But, the user of move
specifies --from/--to, so it does not need to display when it's
accessing the remote, as the user expects it to access the remote.
git-annex get might display it, but only if the remote also supports
hasKeyCheap, which is really only local git remotes, which didn't
display it always; and in any case nothing displayed it before hasKeyCheap,
which is checked first, so I don't think this needs to display it ever.
mirror is like move. And that's all the main places it would have been
displayed.
This commit was sponsored by Jochen Bartl on Patreon.
2021-04-27 16:50:45 +00:00
|
|
|
checkKey r k = go =<< glacierEnv (config r) (gitconfig r) (uuid r)
|
2012-11-20 20:43:58 +00:00
|
|
|
where
|
2016-11-16 01:29:54 +00:00
|
|
|
go Nothing = giveup "cannot check glacier"
|
2012-11-25 17:27:20 +00:00
|
|
|
go (Just e) = do
|
2012-11-20 20:43:58 +00:00
|
|
|
{- glacier checkpresent outputs the archive name to stdout if
|
|
|
|
- it's present. -}
|
2014-08-06 17:45:19 +00:00
|
|
|
s <- liftIO $ readProcessEnv "glacier" (toCommand params) (Just e)
|
2019-01-14 17:03:35 +00:00
|
|
|
let probablypresent = serializeKey k `elem` lines s
|
2014-08-06 17:45:19 +00:00
|
|
|
if probablypresent
|
2021-01-07 14:37:43 +00:00
|
|
|
then giveup untrusted
|
2014-08-06 17:45:19 +00:00
|
|
|
else return False
|
2012-11-20 20:43:58 +00:00
|
|
|
|
2014-03-05 03:22:24 +00:00
|
|
|
params = glacierParams (config r)
|
2012-11-20 20:43:58 +00:00
|
|
|
[ Param "archive"
|
|
|
|
, Param "checkpresent"
|
2012-11-30 04:55:59 +00:00
|
|
|
, Param $ getVault $ config r
|
2012-11-21 23:35:28 +00:00
|
|
|
, Param "--quiet"
|
2012-11-20 20:43:58 +00:00
|
|
|
, Param $ archive r k
|
|
|
|
]
|
|
|
|
|
2014-08-06 17:45:19 +00:00
|
|
|
untrusted = unlines
|
2012-11-20 20:43:58 +00:00
|
|
|
[ "Glacier's inventory says it has a copy."
|
|
|
|
, "However, the inventory could be out of date, if it was recently removed."
|
|
|
|
]
|
|
|
|
|
|
|
|
glacierAction :: Remote -> [CommandParam] -> Annex Bool
|
2016-05-23 21:03:20 +00:00
|
|
|
glacierAction r = runGlacier (config r) (gitconfig r) (uuid r)
|
2012-11-20 20:43:58 +00:00
|
|
|
|
2020-01-14 19:41:34 +00:00
|
|
|
runGlacier :: ParsedRemoteConfig -> RemoteGitConfig -> UUID -> [CommandParam] -> Annex Bool
|
2016-05-23 21:03:20 +00:00
|
|
|
runGlacier c gc u params = go =<< glacierEnv c gc u
|
2012-11-20 20:43:58 +00:00
|
|
|
where
|
|
|
|
go Nothing = return False
|
2012-11-25 17:27:20 +00:00
|
|
|
go (Just e) = liftIO $
|
|
|
|
boolSystemEnv "glacier" (glacierParams c params) (Just e)
|
2012-11-20 20:43:58 +00:00
|
|
|
|
2020-01-14 19:41:34 +00:00
|
|
|
glacierParams :: ParsedRemoteConfig -> [CommandParam] -> [CommandParam]
|
2012-11-25 17:27:20 +00:00
|
|
|
glacierParams c params = datacenter:params
|
|
|
|
where
|
2012-11-20 20:43:58 +00:00
|
|
|
datacenter = Param $ "--region=" ++
|
2020-01-14 19:41:34 +00:00
|
|
|
fromMaybe (giveup "Missing datacenter configuration")
|
|
|
|
(getRemoteConfigValue datacenterField c)
|
2012-11-20 20:43:58 +00:00
|
|
|
|
2020-01-14 19:41:34 +00:00
|
|
|
glacierEnv :: ParsedRemoteConfig -> RemoteGitConfig -> UUID -> Annex (Maybe [(String, String)])
|
2016-05-23 21:03:20 +00:00
|
|
|
glacierEnv c gc u = do
|
2015-02-06 18:39:27 +00:00
|
|
|
liftIO checkSaneGlacierCommand
|
2016-05-23 21:03:20 +00:00
|
|
|
go =<< getRemoteCredPairFor "glacier" c gc creds
|
2012-11-20 20:43:58 +00:00
|
|
|
where
|
|
|
|
go Nothing = return Nothing
|
|
|
|
go (Just (user, pass)) = do
|
2012-11-25 17:27:20 +00:00
|
|
|
e <- liftIO getEnvironment
|
2014-01-14 20:42:10 +00:00
|
|
|
return $ Just $ addEntries [(uk, user), (pk, pass)] e
|
2012-11-20 20:43:58 +00:00
|
|
|
|
|
|
|
creds = AWS.creds u
|
|
|
|
(uk, pk) = credPairEnvironment creds
|
|
|
|
|
2020-01-14 19:41:34 +00:00
|
|
|
getVault :: ParsedRemoteConfig -> Vault
|
|
|
|
getVault = fromMaybe (giveup "Missing vault configuration")
|
|
|
|
. getRemoteConfigValue vaultField
|
2012-11-20 20:43:58 +00:00
|
|
|
|
|
|
|
archive :: Remote -> Key -> Archive
|
2019-01-14 17:03:35 +00:00
|
|
|
archive r k = fileprefix ++ serializeKey k
|
2012-11-20 20:43:58 +00:00
|
|
|
where
|
2020-01-14 19:41:34 +00:00
|
|
|
fileprefix = fromMaybe "" $
|
|
|
|
getRemoteConfigValue fileprefixField $ config r
|
2012-11-20 20:43:58 +00:00
|
|
|
|
2020-01-14 19:41:34 +00:00
|
|
|
genVault :: ParsedRemoteConfig -> RemoteGitConfig -> UUID -> Annex ()
|
2016-05-23 21:03:20 +00:00
|
|
|
genVault c gc u = unlessM (runGlacier c gc u params) $
|
2016-11-16 01:29:54 +00:00
|
|
|
giveup "Failed creating glacier vault."
|
2012-11-20 20:43:58 +00:00
|
|
|
where
|
|
|
|
params =
|
|
|
|
[ Param "vault"
|
|
|
|
, Param "create"
|
2012-11-29 18:49:20 +00:00
|
|
|
, Param $ getVault c
|
2012-11-20 20:43:58 +00:00
|
|
|
]
|
2012-11-29 18:49:20 +00:00
|
|
|
|
|
|
|
{- Partitions the input list of keys into ones which have
|
|
|
|
- glacier retieval jobs that have succeeded, or failed.
|
|
|
|
-
|
|
|
|
- A complication is that `glacier job list` will display the encrypted
|
|
|
|
- keys when the remote is encrypted.
|
2014-08-02 20:47:21 +00:00
|
|
|
-
|
|
|
|
- Dealing with encrypted chunked keys would be tricky. However, there
|
|
|
|
- seems to be no benefit to using chunking with glacier, so chunking is
|
|
|
|
- not supported.
|
2012-11-29 18:49:20 +00:00
|
|
|
-}
|
|
|
|
jobList :: Remote -> [Key] -> Annex ([Key], [Key])
|
2016-05-23 21:03:20 +00:00
|
|
|
jobList r keys = go =<< glacierEnv (config r) (gitconfig r) (uuid r)
|
2012-11-29 18:49:20 +00:00
|
|
|
where
|
|
|
|
params = [ Param "job", Param "list" ]
|
|
|
|
nada = ([], [])
|
2012-11-30 04:55:59 +00:00
|
|
|
myvault = getVault $ config r
|
2012-11-29 18:49:20 +00:00
|
|
|
|
|
|
|
go Nothing = return nada
|
|
|
|
go (Just e) = do
|
|
|
|
v <- liftIO $ catchMaybeIO $
|
|
|
|
readProcessEnv "glacier" (toCommand params) (Just e)
|
|
|
|
maybe (return nada) extract v
|
|
|
|
|
|
|
|
extract s = do
|
|
|
|
let result@(succeeded, failed) =
|
|
|
|
parse nada $ (map words . lines) s
|
|
|
|
if result == nada
|
|
|
|
then return nada
|
|
|
|
else do
|
|
|
|
enckeys <- forM keys $ \k ->
|
2014-07-27 00:21:36 +00:00
|
|
|
maybe k (\(_, enck) -> enck k)
|
2016-05-23 21:27:15 +00:00
|
|
|
<$> cipherKey (config r) (gitconfig r)
|
2012-11-29 18:49:20 +00:00
|
|
|
let keymap = M.fromList $ zip enckeys keys
|
2013-09-26 03:19:01 +00:00
|
|
|
let convert = mapMaybe (`M.lookup` keymap)
|
2012-11-29 18:49:20 +00:00
|
|
|
return (convert succeeded, convert failed)
|
|
|
|
|
|
|
|
parse c [] = c
|
|
|
|
parse c@(succeeded, failed) ((status:_date:vault:key:[]):rest)
|
|
|
|
| vault == myvault =
|
2019-01-14 17:03:35 +00:00
|
|
|
case deserializeKey key of
|
2012-11-29 18:49:20 +00:00
|
|
|
Nothing -> parse c rest
|
|
|
|
Just k
|
|
|
|
| "a/d" `isPrefixOf` status ->
|
|
|
|
parse (k:succeeded, failed) rest
|
|
|
|
| "a/e" `isPrefixOf` status ->
|
|
|
|
parse (succeeded, k:failed) rest
|
|
|
|
| otherwise ->
|
|
|
|
parse c rest
|
|
|
|
parse c (_:rest) = parse c rest
|
2015-02-06 18:39:27 +00:00
|
|
|
|
|
|
|
-- boto's version of glacier exits 0 when given a parameter it doesn't
|
|
|
|
-- understand. See https://github.com/boto/boto/issues/2942
|
|
|
|
checkSaneGlacierCommand :: IO ()
|
|
|
|
checkSaneGlacierCommand =
|
|
|
|
whenM ((Nothing /=) <$> catchMaybeIO shouldfail) $
|
2016-11-16 01:29:54 +00:00
|
|
|
giveup wrongcmd
|
2015-02-06 18:39:27 +00:00
|
|
|
where
|
|
|
|
test = proc "glacier" ["--compatibility-test-git-annex"]
|
2020-06-04 19:36:34 +00:00
|
|
|
shouldfail = withNullHandle $ \nullh ->
|
|
|
|
let p = test
|
|
|
|
{ std_out = UseHandle nullh
|
|
|
|
, std_err = UseHandle nullh
|
|
|
|
}
|
|
|
|
in withCreateProcess p $ \_ _ _ -> forceSuccessProcess p
|
2015-02-06 18:39:27 +00:00
|
|
|
wrongcmd = "The glacier program in PATH seems to be from boto, not glacier-cli. Cannot use this program."
|