b6d46c212e
* unannex, uninit: Avoid committing after every file is unannexed,
for massive speedup.
* --notify-finish switch will cause desktop notifications after each
file upload/download/drop completes
(using the dbus Desktop Notifications Specification)
* --notify-start switch will show desktop notifications when each
file upload/download starts.
* webapp: Automatically install Nautilus integration scripts
to get and drop files.
* tahoe: Pass -d parameter before subcommand; putting it after
the subcommand no longer works with tahoe-lafs version 1.10.
(Thanks, Alberto Berti)
* forget --drop-dead: Avoid removing the dead remote from the trust.log,
so that if git remotes for it still exist anywhere, git annex info
will still know it's dead and not show it.
* git-annex-shell: Make configlist automatically initialize
a remote git repository, as long as a git-annex branch has
been pushed to it, to simplify setup of remote git repositories,
including via gitolite.
* add --include-dotfiles: New option, perhaps useful for backups.
* Version 5.20140227 broke creation of glacier repositories,
not including the datacenter and vault in their configuration.
This bug is fixed, but glacier repositories set up with the broken
version of git-annex need to have the datacenter and vault set
in order to be usable. This can be done using git annex enableremote
to add the missing settings. For details, see
http://git-annex.branchable.com/bugs/problems_with_glacier/
* Added required content configuration.
* assistant: Improve ssh authorized keys line generated in local pairing
or for a remote ssh server to set environment variables in an
alternative way that works with the non-POSIX fish shell, as well
as POSIX shells.
# imported from the archive
47 lines
1.9 KiB
Markdown
47 lines
1.9 KiB
Markdown
This special remote stores file contents using
|
|
[Tahoe-LAFS](http://tahoe-lafs.org/). There are a number of commercial
|
|
providers, or you can build your own tahoe storage grid.
|
|
|
|
Since Tahoe-LAFS encrypts all data stored in it, git-annex does not do any
|
|
additional encryption of its own.
|
|
|
|
Note that data stored in a tahoe remote cannot be dropped from it, as
|
|
Tahoe-LAFS does not support removing data once it is stored in the Tahoe grid.
|
|
This, along with Tahoe's ability to recover data when some nodes fail,
|
|
makes a tahoe special remote an excellent choice for storing backups.
|
|
|
|
Typically you will have an account on a Tahoe-LAFS storage grid, which
|
|
is represented by an "introducer furl". You need to supply this to
|
|
git-annex in the `TAHOE_FURL` environment variable when initializing the
|
|
remote. git-annex will then generate a tahoe configuration directory for
|
|
the remote under `~/.tahoe/git-annex/`, and automatically start the tahoe
|
|
daemon as needed.
|
|
|
|
## configuration
|
|
|
|
These parameters can be passed to `git annex initremote` to configure
|
|
the tahoe remote.
|
|
|
|
* `shared-convergence-secret` - Optional. Can be useful to set to
|
|
allow tahoe to deduplicate information. By default, a new
|
|
shared-convergence-secret is created for each tahoe remote.
|
|
|
|
* `embedcreds` - Optional. Set to "yes" embed the tahoe credentials
|
|
(specifically the introducer-furl and shared-convergence-secret)
|
|
inside the git repository, which allows other clones to also use them
|
|
in order to access the tahoe grid.
|
|
|
|
Think carefully about who can access your git repository, and
|
|
whether you want to give them access to your tahoe system before
|
|
using embedcreds!
|
|
|
|
Setup example:
|
|
|
|
# TAHOE_FURL=... git annex initremote tahoe type=tahoe embedcreds=yes
|
|
|
|
## old version of tahoe special remote
|
|
|
|
An older implementation of tahoe for git-annex used
|
|
the hook special remote. It is not compatible with this newer
|
|
implementation. See
|
|
[[tahoe-lafs|forum/tips:_special__95__remotes__47__hook_with_tahoe-lafs]].
|