Page MenuHomePhorge
Files F117754365

No OneTemporary
Actions

Authored By
Unknown
Size
27 KB
Referenced Files
None
Subscribers
None

View Options

diff --git a/docsrc/imap/reference/admin/sop/replication.rst b/docsrc/imap/reference/admin/sop/replication.rst
index 451d48888..821460f6b 100644
--- a/docsrc/imap/reference/admin/sop/replication.rst
+++ b/docsrc/imap/reference/admin/sop/replication.rst
@@ -1,447 +1,453 @@
.. _replication:
============================================
Replication: Installation and Administration
============================================
Architecture
============
:ref:`Overall structure of replication <architecture_replication>`.
Terminology
===========
Host
A computer chassis, slot or cabinet. A machine.
Server or Service
A program or process which "serves" a particular protocol.
Typically a server will listen on a network port or Unix socket
for communications from a client (local or remote).
Client
A program or process which talks to a server or servers for a given
protocol. The initiator of a client/server session.
Instance
A particular instance or iteration of a program, which may be one,
or one of many, providing similar services to different consumers.
Master
In this document, Master always means the source of data to be
replicated.
Replica
The target of data replication is the Replica, which refers both to
an instance of sync_server and to the resultant dataset.
Operating Modes
===============
Cyrus replication supports two modes of operation: Rolling and
Periodic. The difference is that rolling replication is a more or less
continuous process whereas periodic replication occurs on demand,
triggered by some manual or automated process such as
:manpage:`cron(8)`.
Rolling Replication
-------------------
Rolling replication is enabled by setting ``sync_log`` to True in
:cyrusman:`imapd.conf(5)`. With ``sync_log: true``, any process which
alters the mail spool will update the ``sync_log`` files with details
as to which mailbox(es) or users have been affected by their actions.
In this way the ``sync_log`` acts as a command file for the
:cyrusman:`sync_client(8)` process(es).
The log files are stored in ``{configdirectory}/sync/log`` for single
channel systems (see :ref:`replication-channels` for more information)
and are rotated on a regular basis by Cyrus. Multi-channel deployments
will have a separate ``sync_log`` file for each, stored as
``{configdirectory}/sync/<channel>/log``.
Upon completing a log file, ``sync_client`` will go to sleep, or, if
processing took longer than ``sync_repeat_interval`` seconds, will
start over again on the next log.
.. Note::
Any unsuccessful run of sync_client will result in the incomplete
remains of the original log file being left behind as "log-<$PID>".
This may be re-run as needed.
.. Note::
Please also see :ref:`below for other uses of sync_log
<replication-other-uses>`.
Periodic Replication
--------------------
With ``sync_log`` set to the default False, replication must be
triggered either by manually running :cyrusman:`sync_client(8)`, or by
doing so via ``cron`` or an entry in :cyrusman:`cyrus.conf(5)`.
In either event, command line switches control the operation of
``sync_client``.
Once the process completes its work, it will exit.
Idempotency
-----------
Synchronization itself is idempotent in either mode, so log files may
be "replayed" without concern of damage to the replica's mail spools.
Sync Chains
-----------
Cyrus supports chained replication, in which one replica replicates to
another. I.e. A replicates to B; B replicates to C. If you wish to
use this approach, please see the ``sync_log_chain`` setting:
.. include:: /imap/reference/manpages/configs/imapd.conf.rst
:start-after: startblob sync_log_chain
:end-before: endblob sync_log_chain
Note that sync_log_chain is to be set on the middle server(s) in a
chain, not on the first or last.
Transport
=========
Older versions (pre-3.0) of Cyrus used the dedicated ``csync``
transport -- typically over TCP port 2005 -- and server process --
:cyrusman:`sync_server(8)` -- for replication. This is no longer
necessary.
From v3.0 forward, the :cyrusman:`sync_client(8)` will default to using
IMAP protocol for transport, and an IMAP instance on the replica will
process the synchronization instructions. If you wish, you may
override this by setting the ``sync_try_imap`` setting in
:cyrusman:`imapd.conf(5)` to False.
.. include:: /imap/reference/manpages/configs/imapd.conf.rst
:start-after: startblob sync_try_imap
:end-before: endblob sync_try_imap
Installation
============
One must :ref:`build Cyrus IMAPd <compiling>` with the
``--enable-replication`` configure option. This builds the replication
client/server applications and utilities.
.. Note::
Those using their distribution's packages may need to install a
separate package for replication support. For example, on Debian
and derived distros, install the ``cyrus-replication`` package.
Requirements
------------
1. At least one Cyrus IMAP server instance to be the **master**.
2. At least one Cyrus IMAP server instance to be the **replica**.
.. Note::
Sample configurations for both "master" and "replica" instances are
included in the standard distribution.
Replica server configuration
----------------------------
The **replica** is a standalone server instance which listens for and
processes synchronization messages from a single **master** server. The
replica server needs to be configured to accept synchronization
messages via IMAP or the (deprecated) :cyrusman:`sync_server(8)`
process.
.. Important::
Within a Cyrus :ref:`Murder <architecture_murder>` environment,
replicas must **not** be configured to invoke
:cyrusman:`ctl_mboxlist(8)` on startup (pushing the local mailbox
list to the **Mupdate Master**). This may only be done on the
Master instance.
.. Important::
It is critically important that all partitions existing on a master
server instance also be present on all replica instances. Failure
to ensure this will result in crashes and could lead to lost data
on the replicas.
1. :ref:`Configure a standalone server <installing>`.
2. If using the deprecated sync_server scheme, add the following line
to the ``/etc/services`` file. Note that the port number is
arbitrary as long as its not being used by any other services on the
network.
::
csync 2005/tcp
3. If using the deprecated sync_server scheme, add a line similar to
the following in the SERVICES section of :cyrusman:`cyrus.conf(5)`:
::
syncserver cmd="/usr/cyrus/bin/sync_server" listen="csync"
4. Start/restart ``/usr/cyrus/bin/master``.
Master server configuration
---------------------------
The **master** server is a standalone or backend Cyrus IMAP server
instance which is actively serving mailboxes to clients. This server
needs to be configured to synchronize its mailstore with a **replica**
server via an instance of :cyrusman:`sync_client(8)`.
If using the deprecated sync_server scheme, add the following line to
the ``/etc/services`` file.
::
csync 2005/tcp
.. Note::
The port number **MUST** be the same as that used on the replica
server.
Specify the hostname of the replica server and how to authenticate to
it in :cyrusman:`imapd.conf(5)` using these options:
* sync_host
* sync_port
* sync_authname
* sync_realm
* sync_password
.. Note::
``sync_authname`` **MUST** be an ``admin`` user on the replica.
.. Note::
``sync_realm`` and ``sync_password`` may not be necessary
depending on the SASL mechanism used for authentication.
.. Note::
See :ref:`replication-channels`, below, for details on how to use
these settings to control syncing to multiple replicas.
+.. Important::
+ If using sync_log_channels for any other purpose, such as
+ specifying the sync_log used by :cyrusman:`squatter(8)` command,
+ you must *also* either specify a sync_log channel for replication,
+ or specify the default "" (the two-character string U+22 U+22).
+
Add invocation specifications to :cyrusman:`cyrus.conf(5)` to spawn
:cyrusman:`sync_client(8)` as desired (for each channel used) as
described below in Rolling Replication or Periodic Replication.
Compression
-----------
If one runs replication over a WAN link, the trade-off between
bandwidth and CPU usage will tilt strongly in favour of enabling
compression to save bandwidth at a slight increase in CPU cost. Set
the ``sync_compress`` value in :cyrusman:`imapd.conf(5)`::
sync_compress: On
or pass the ``-z`` flag to :cyrusman:`sync_client(8)` in the service
spec in :cyrusman:`cyrus.conf(5)`::
syncclient cmd="/usr/cyrus/bin/sync_client -r -z"
Rolling Replication Configuration
---------------------------------
**Rolling Replication** means that the master instance continuously
synchronizes itself with a replica.
To configure rolling replication, perform the following:
1. Enable the ``sync_log`` option in :cyrusman:`imapd.conf(5)`. This
allows the imapd, pop3d, nntpd, and lmtpd services to log
synchronization actions which will be periodically serviced by
sync_client::
sync_log: On
2. Optionally, adjust the ``sync_repeat_interval`` in
:cyrusman:`imapd.conf(5)`::
sync_repeat_interval: 300
3. Add a line similar to the following in the STARTUP section of
:cyrusman:`cyrus.conf(5)`::
syncclient cmd="/usr/cyrus/bin/sync_client -r"
Start/restart ``/usr/cyrus/bin/master``.
.. Hint::
In a multi-channel mesh, the channel to be used by a given
sync_client must be specified via the "-n <channel>" argument on
the command line::
syncclient cmd="/usr/cyrus/bin/sync_client -r -n channel1"
Terminating Rolling Replication
-------------------------------
To be able to stop rolling replication at any time, configure the
``sync_shutdown_file`` option in :cyrusman:`imapd.conf(5)` to point to
a non-existant file, the appearance of this file will trigger a
shutdown of a :cyrusman:`sync_client(8)` instance::
sync_shutdown_file: /var/lib/imap/syncstop
Tweaking Rolling Replication
----------------------------
The default frequency of replication runs is 3 seconds. Lengthening
this produces higher efficiency at the cost of slightly more stale data
on the replica. Alter this via the sync_repeat_interval in
:cyrusman:`imapd.conf(5)` or by using the "-d" argument in the
invocation of :cyrusman:`sync_client(8)`.
Periodic Replication Configuration
----------------------------------
In Periodic Replication the sync_client instance must be spawned
from time to time, causing replication to start at that time. This may
be handled via a :manpage:`cron(8)` job, or by adding an entry to the
EVENTS section of :cyrusman:`cyrus.conf(5)` like any of these::
EVENTS {
<...>
# Periodically sync ALL user mailboxes every 4 hours
syncclient cmd="/usr/cyrus/bin/sync_client -A" period=240
# Periodically sync changes at specific times
syncclient cmd="/usr/cyrus/bin/sync_client -A" at=0800
syncclient cmd="/usr/cyrus/bin/sync_client -A" at=1200
syncclient cmd="/usr/cyrus/bin/sync_client -A" at=1800
<...>
}
.. Note::
When using the "-A" flag (sync all users) no non-user
mailboxes are synced. As the man page :cyrusman:`imapd.conf(5)`
notes, "... this could be considered a bug and maybe it should do
those mailboxes independently."
Tweaking Replication
--------------------
You may control the number of messages replicated in each batch, via
the ``sync_batchsize`` setting:
.. include:: /imap/reference/manpages/configs/imapd.conf.rst
:start-after: startblob sync_batchsize
:end-before: endblob sync_batchsize
.. _replication-channels:
Channels
========
The Cyrus replication scheme is very flexible, and supports meshes in
which masters running on various hosts may replicate to instances on
other hosts. This is achieved by use of the Channels feature of the
replication system.
To employ channels, prefix any of the following sync\_ configuration
options in :cyrusman:`imapd.conf(5)` with the channel name and an
underscore "_" character as needed::
sync_authname
sync_password
sync_realm
sync_host
sync_port
sync_repeat_interval
sync_shutdown_file
Then add the setting ``sync_log_channels`` with a list of the channels::
sync_log_channels: chan1 chan2 chan3
For example, a site using the same auth credentials for all servers has
no need to specify unique per-channel settings for ``sync_authname``,
``sync_password`` or ``sync_realm``, but might do the following for the
rest of the sync related settings in :cyrusman:`imapd.conf(5)`::
sync_authname: replman
sync_password: <secret>
sync_log_channels: repl1 repl2 offsite
##
# The main replica
repl1_sync_host: mailrepl1.example.org
repl1_sync_repeat_interval: 180
repl1_shutdown_file: /run/cyrus/sync/repl1_shutdown
##
# A second replica used to feed the tape backup system
repl2_sync_host: mailrepl2.example.org
repl2_sync_repeat_interval: 180
repl2_shutdown_file: /run/cyrus/sync/repl2_shutdown
##
# An offsite replica which needs a different port and uses a slower
# cycle rate
offsite_sync_port: 19205
offsite_sync_host: mailoffsite.example.org
offsite_sync_repeat_interval: 360
offsite_shutdown_file: /run/cyrus/sync/offsite_shutdown
Then these entries in :cyrusman:`cyrus.conf(5)` would complete the
exercise::
repl1sync cmd="/usr/cyrus/bin/sync_client -r -n repl1"
repl2sync cmd="/usr/cyrus/bin/sync_client -r -n repl2"
offsitesync cmd="/usr/cyrus/bin/sync_client -r -n offsite"
Again, this is just an example for illustration. The system provides so
much flexibility, and one can combine channels with chaining to achieve
even more.
.. _replication-other-uses:
Other Considerations
====================
.. Important::
This section is currently under development. If you believe you
are impacted by these considerations, please check back with each
release, follow the mailing list and check in on IRC.
The infrastructure provided by ``sync_log`` has now been leveraged by
the Rolling Indexing capability introduced in v3.0. See
:cyrusman:`squatter(8)` for more details (see the fourth mode synopsis).
Specifically, the following new settings have been added to
:cyrusman:`imapd.conf(5)` in support of this new use of ``sync_log``:
.. include:: /imap/reference/manpages/configs/imapd.conf.rst
:start-after: startblob sync_log_unsuppressable_channels
:end-before: endblob sync_log_unsuppressable_channels
Administration
==============
Manual replication
------------------
To manually synchronize any part of the mailstore, run
:cyrusman:`sync_client(8)` with the appropriate command line options.
Note that manual synchronization DOES NOT interfere with rolling
replication.
For example:
::
[root@skynet ~]# /usr/lib/cyrus-imapd/sync_client -S cyrus-replica.example.org -v -u john.doe@example.org
USER john^doe@example.org
One can run :cyrusman:`cyr_synclog(8)` instead, which will insert the
record into the rolling replication log.
Failover
--------
.. :todo:
Hmm! How does failover work?
Clue: It's not automated (yet)...
diff --git a/docsrc/imap/reference/manpages/systemcommands/squatter.rst b/docsrc/imap/reference/manpages/systemcommands/squatter.rst
index 48ddc5fb3..fe97624b0 100644
--- a/docsrc/imap/reference/manpages/systemcommands/squatter.rst
+++ b/docsrc/imap/reference/manpages/systemcommands/squatter.rst
@@ -1,338 +1,342 @@
.. cyrusman:: squatter(8)
.. author: Nic Bernstein (Onlight)
.. _imap-reference-manpages-systemcommands-squatter:
============
**squatter**
============
Create SQUAT indexes for mailboxes
Synopsis
========
.. parsed-literal::
general:
**squatter** [ **-C** *config-file* ] [**mode**] [**options**] [**source**]
i.e.:
**squatter** [ **-C** *config-file* ] [**-v**]
**squatter** [ **-C** *config-file* ] [ **-a** ] [ **-i** ] [**-N** *name*] [**-S *seconds*] [ **-r** ] *mailbox*...
**squatter** [ **-C** *config-file* ] [ **-a** ] [ **-i** ] [**-N** *name*] [**-S *seconds*] [ **-r** ] **-u** *user*...
**squatter** [ **-C** *config-file* ] **-R** [ **-n** *channel* ] [ **-d** ]
**squatter** [ **-C** *config-file* ] **-f** *synclogfile*
**squatter** [ **-C** *config-file* ] **-I** *file*
**squatter** [ **-C** *config-file* ] **-t** *srctier*... **-z** *desttier* [ **-F** ] [ **-T** *dir* ] [ **-X** ] [ **-o** ]
Description
===========
.. Note::
The name "**squatter**" once referred both to the SQUAT indexing
engine and to the command used to create indexes. Now that Cyrus
supports more than one index type -- SQUAT and Xapian, as of this
writing -- the name "**squatter**" refers to the command used to
control index creation. The terms "SQUAT" or "SQUAT index(es)"
refers to the indexes used by the older SQUAT indexing engine.
Post v3 the *search_engine* setting in *imapd.conf* determines
which search engine is used.
**squatter** creates a new text index for one or more IMAP mailboxes.
The index is a unified index of all of the header and body text
of each message in a given mailbox. This index is used to significantly
reduce IMAP SEARCH times on a mailbox.
By default, **squatter** creates an index of ALL messages in the
mailbox, not just those since the last time that it was run. The
**-i** option is used to select incremental updates. Any messages
appended to the mailbox after **squatter** is run, will NOT be included
in the index. To include new messages in the index, **squatter** must
be run again.
In the first synopsis, **squatter** indexes all mailboxes.
In the second synopsis, **squatter** indexes the specified mailbox(es).
In the third synopsis, **squatter** indexes the specified user(s)
mailbox(es).
For any of those three source modes (default=all, mailbox, user) one
may optionally specify **-r** to recurse from the specified start, or
**-a** to limit action only to mailboxes which have the shared
*/vendor/cmu/cyrus-imapd/squat* annotation set to "true".
In the fourth synopsis, **squatter** runs in rolling mode. In this
mode **squatter** backgrounds itself and runs as a daemon (unless
**-d** is set), listening to a sync log channel chosen using the **-n**
option, and set up using the *sync_log_channels* setting in
:cyrusman:`imapd.conf(5)`. Very soon after messages are delivered or
uploaded to mailboxes **squatter** will incrementally index the
affected mailbox (see notes, below).
In the fifth synopsis, **squatter** reads a single sync log file and
performs incremental indexing on the mailbox(es) listed therein. This
is sometimes useful for cleaning up after problems with rolling mode.
In the sixth synopsis, **squatter** reads *file* containing *mailbox*
*uid* tuples and performs indexing on the specified messages.
In the seventh synopsis, **squatter** will compact indices from
*srctier(s)* to *desttier*, optionally reindexing (**-X**) or filtering
expunged records (**-F**) in the process. The optional **-T** flag may
be used to specify a directory to use for temporary files. The **-o**
flag may be used to direct that a single index be copied, rather than
compressed, from *srctier* to *desttier*. The **-U** flag may be used
to only compact if re-indexing.
For all modes, the **-S** option may be specified, causing squatter to
pause *seconds* seconds after each mailbox, to smooth loads.
.. Note::
Incremental updates are very inefficient with the SQUAT search
engine. If using SQUAT for large and active mailboxes, you should
run **squatter** periodically as an EVENT in ``cyrus.conf(5)``.
.. Note::
Messages and mailboxes that have not been indexed CAN still be
SEARCHed, just not as quickly as those with an index.
**squatter** |default-conf-text|
Options
=======
.. program:: squatter
.. option:: -C config-file
|cli-dash-c-text|
.. option:: -a
Only create indexes for mailboxes which have the shared
*/vendor/cmu/cyrus-imapd/squat* annotation set to "true".
The value of the */vendor/cmu/cyrus-imapd/squat* annotation is
inherited by all children of the given mailbox, so an entire
mailbox tree can be indexed (or not indexed) by setting a single
annotation on the root of that tree with a value of "true" (or
"false"). If a mailbox does not have a
*/vendor/cmu/cyrus-imapd/squat* annotation set on it (or does not
inherit one), then the mailbox is not indexed. In other words, the
implicit value of */vendor/cmu/cyrus-imapd/squat* is "false".
.. option:: -d
In rolling mode, don't background and do emit log messages on
standard error. Useful for debugging.
|v3-new-feature|
.. option:: -F
In compact mode, filter the resulting database to only include
messages which are not expunged in mailboxes with existing
name/uidvalidity.
|v3-new-feature|
.. option:: -f synclogfile
Read the *synclogfile* and incrementally index all the mailboxes
listed therein, then exit.
|v3-new-feature|
.. option:: -h
Display this usage information.
.. option:: -I file
Read from *file* and index individual messages described by
mailbox/uid tuples contained therein.
.. option:: -i
Incremental updates where indexes already exist.
.. option:: -N name
Only index mailboxes beginning with *name* while iterating through
the mailbox list derived from other options.
.. option:: -n channel
In rolling mode, specify the name of the sync log *channel* that
**squatter** will listen to. The default is "squatter". This
channel **must** be defined in :cyrusman:`imapd.conf(5)` before
being used.
|v3-new-feature|
.. option:: -o
In compact mode, if only one source database is selected, just copy
it to the destination rather than compacting.
|v3-new-feature|
.. option:: -R
Run in rolling mode; **squatter** runs as a daemon listening to a
sync log channel and continuously incrementally indexing mailboxes.
See also **-d** and **-n**.
|v3-new-feature|
.. option:: -r
Recursively create indexes for all sub-mailboxes of the user,
mailboxes or mailbox prefixes given as arguments.
.. option:: -S seconds
After processing each mailbox, sleep for "seconds" before
continuing. Can be used to provide some load balancing. Accepts
fractional amounts. |v3-new-feature|
.. option:: -T directory
When indexing, work on a temporary copy of the search engine
databases in *directory*. That directory would typically be on
some very fast filesystem, like an SSD or tmpfs. This option may
not work with all search engines, but it's only effect is to speed
up initial indexing.
|v3-new-feature|
.. option:: -t srctier...
In compact mode, the source tier(s) for the compacted indices.
At least one source tier must be specified in compact mode.
|v3-new-feature|
.. option:: -u
Extra options refer to usernames (e.g. foo@bar.com) rather than
mailbox names.
|v3-new-feature|
.. option:: -U
In compact mode, only compact if re-indexing.
|master-new-feature|
.. option:: -v
Increase the verbosity of progress/status messages.
.. option:: -X
Reindex all the messages before compacting. This mode reads all
the lists of messages indexed by the listed tiers, and re-indexes
them into a temporary database before compacting that into place.
.. option:: -z desttier
In compact mode, the destination tier for the compacted indices.
This must be specified in compact mode.
|v3-new-feature|
.. option:: -Z
When indexing messages, use the Xapian internal cyrusid rather than
referencing the ranges of already indexed messages to know if a
particular message is indexed. Useful if the ranges get out of
sync with the actual messages (e.g. if files on a tier are lost)
|master-new-feature|
Examples
========
**squatter** is typically deployed via entries in
:cyrusman:`cyrus.conf(5)`, in either the DAEMON or EVENTS sections.
For the older SQUAT search engine, which offers poor performance in
rolling mode (-R) we recommend triggering periodic runs via entries in
the EVENTS section, as follows:
Sample entries from the EVENTS section of :cyrusman:`cyrus.conf(5)` for
periodic **squatter** runs:
::
EVENTS {
# reindex changed mailboxes (fulltext) approximately every three hours
squatter1 cmd="/usr/bin/ionice -c idle /usr/lib/cyrus/bin/squatter -i" period=180
# reindex all mailboxes (fulltext) daily
squattera cmd="/usr/lib/cyrus/bin/squatter" at=0117
}
For the newer Xapian search engine, and with sufficiently fast storage,
the rolling mode (-R) offers advantages. Use of rolling mode requires
that **squatter** be invoked in the DAEMON section.
Sample entries for the DAEMON section of :cyrusman:`cyrus.conf(5)` for
rolling **squatter** operation:
::
DAEMON {
# run a rolling squatter using the default sync_log channel "squatter"
squatter cmd="squatter -R"
# run a rolling squatter using a specific sync_log channel
squatter cmd="squatter -R -n indexer"
}
.. Note::
- When using the *-R* rolling mode, you MUST enable sync_log operation
- in :cyrusman:`imapd.conf(5)` via the `sync_log: on` setting, and
- MUST define a sync_log channel via the `sync_log_channels:`
- setting.
+ When using the *-R* rolling mode, you MUST enable sync_log
+ operation in :cyrusman:`imapd.conf(5)` via the `sync_log: on`
+ setting, and MUST define a sync_log channel via the
+ `sync_log_channels:` setting. If also using replication, you must
+ either explicitly specify your replication sync_log channel via the
+ `sync_log_channels` directive with a name, or specify the default
+ empty name with "" (the two-character string U+22 U+22). [Please
+ see :cyrusman:`imapd.conf(5)` for details].
.. Note::
When configuring rolling search indexing on a **replica**, one must
consider whether sync_logs will be written at all. In this case,
please consider the setting `sync_log_unsuppressable_channels` to
ensure that the sync_log channel upon which one's squatter instance
depends will continue to be written. See :cyrusman:`imapd.conf(5)`
for details.
.. Note::
When using the Xapian search engine, you must define various
settings in :cyrusman:`imapd.conf(5)`. Please read all relevant
Xapian documentation in this release before using Xapian.
[NB: More examples needed]
History
=======
Support for additional search engines was added in version 3.0.
The following command-line switches were added in version 3.0:
.. parsed-literal::
**-R -u -d -O -F -A**
The following command-line settings were added in version 3.0:
.. parsed-literal::
**-S** *<seconds>*, **-T** *<directory>*, **-f** *<synclogfile>*, **-n** *<channel>*, **-t** *srctier*..., **-z** *desttier*
Files
=====
/etc/imapd.conf,
/etc/cyrus.conf
See Also
========
:cyrusman:`imapd.conf(5)`, :cyrusman:`cyrus.conf(5)`

File Metadata

Mime Type
text/x-diff
Expires
Sat, Apr 4, 6:52 AM (1 w, 2 d ago)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
18822925
Default Alt Text
(27 KB)

Event Timeline