Merge EE docs

.gitmodules

@@ -16,3 +16,18 @@
 [submodule "modules/tntcxx"]
 	path = modules/tntcxx
 	url = https://github.com/tarantool/tntcxx.git
+[submodule "modules/task"]
+	path = modules/task
+	url = https://github.com/tarantool/task.git
+[submodule "modules/odbc"]
+	path = modules/odbc
+	url = https://github.com/tarantool/odbc.git
+[submodule "modules/ldap"]
+	path = modules/ldap
+	url = https://github.com/tarantool/ldap.git
+[submodule "modules/oracle"]
+	path = modules/oracle
+	url = https://github.com/tarantool/oracle.git
+[submodule "modules/space-explorer"]
+	path = modules/space-explorer
+	url = https://github.com/tarantool/space-explorer.git

conf.py

@@ -40,6 +40,7 @@
 
 extlinks = {
     'tarantool-issue': ('https://github.com/tarantool/tarantool/issues/%s', 'gh-'),
+    'tarantool-ee-issue': ('https://github.com/tarantool/tarantool-ee/issues/%s', 'gh-'),
     'tarantool-release': ('https://github.com/tarantool/tarantool/releases/%s', 'v. '),
     'tt-release': ('https://github.com/tarantool/tt/releases/v%s', 'v. '),
     'doc-issue': ('https://github.com/tarantool/doc/issues/%s', 'doc-'),

doc/book/admin/access_control.rst

@@ -78,7 +78,7 @@ Tarantool supports two protocols for authenticating users:
     In this case, password hashes are stored in the ``_user`` space `unsalted <https://en.wikipedia.org/wiki/Salt_(cryptography)>`_.
     If an attacker gains access to the database, they may crack a password using, for example, a `rainbow table <https://en.wikipedia.org/wiki/Rainbow_table>`_.
 
-*   `PAP <https://en.wikipedia.org/wiki/Password_Authentication_Protocol>`_ with ``SHA256`` hashing (Tarantool Enterprise)
+*   `PAP <https://en.wikipedia.org/wiki/Password_Authentication_Protocol>`_ with ``SHA256`` hashing (Enterprise Edition)
 
     For PAP, a password is salted with a user-unique salt before saving it in the ``_user`` space.
     This keeps the database protected from cracking using a rainbow table.
@@ -90,7 +90,7 @@ There are two functions for managing passwords in Tarantool:
 
 *   :doc:`/reference/reference_lua/box_schema/user_password` returns a hash of a user's password.
 
-Tarantool Enterprise also allows you to improve database security by enforcing the use of strong passwords, setting up a maximum password age, and so on. Learn more from the `Access control <https://www.tarantool.io/en/enterprise_doc/security/#access-control>`__ section.
+Tarantool Enterprise Edition also allows you to improve database security by enforcing the use of strong passwords, setting up a maximum password age, and so on. Learn more from the :ref:`Access control <enterprise-access-control>` section.
 
 
 

doc/book/connectors/python.rst

@@ -188,6 +188,6 @@ Last update: September 2023
         -   No
         -   `Yes <https://github.com/tarantool/tarantool-python/wiki/PEP-249-Database-API>`__
 
-    *   -   `Encrypted connection (Tarantool Enterprise) <https://www.tarantool.io/en/enterprise_doc/security/#enterprise-iproto-encryption>`__
+    *   -   :ref:`Encrypted connection (Enterprise Edition) <enterprise-iproto-encryption>`
         -   No (`issue #22 <https://github.com/igorcoding/asynctnt/issues/22>`__)
         -   Yes

doc/concepts/data_model/migrations.rst

@@ -15,8 +15,8 @@ that do not require data migration:
 
 ..  note::
 
-    Check the `Upgrading space schema <https://www.tarantool.io/en/enterprise_doc/space_upgrade/>`__
-    section in the Enterprise version. With the help of ``space:upgrade()`` feature,
+    Check the :ref:`Upgrading space schema <enterprise-space_upgrade>` section.
+    With the help of ``space:upgrade()``,
     you can enable compression and migrate, including already created tuples.
 
 

doc/concepts/replication/repl_architecture.rst

@@ -29,7 +29,7 @@ the update operations to save space.
 
 .. NOTE::
 
-    `WAL extensions <https://www.tarantool.io/en/enterprise_doc/wal_extensions/>`_ available in Tarantool Enterprise enable you to add auxiliary information to each write-ahead log record.
+    :ref:`WAL extensions <wal_extensions>` available in Tarantool Enterprise Edition enable you to add auxiliary information to each write-ahead log record.
     This information might be helpful for implementing a CDC (Change Data Capture) utility that transforms a data replication stream.
 
 The following are specifics of adding different types of information to the WAL:

doc/contributing/docs/localization/locstate.rst

@@ -11,7 +11,7 @@ State of localization
             -   State
             -   Volume, words
 
-        *   -   Tarantool Community
+        *   -   Tarantool Community Edition
             -   |doc|
             -   352 000
 
@@ -27,7 +27,7 @@ State of localization
             -   |cartridge-cli|
             -   6 500
 
-        *   -   Tarantool Enterprise
+        *   -   Tarantool Enterprise Edition
             -   |tarantool-enterprise|
             -   6 000
 

doc/enterprise/admin.rst

@@ -0,0 +1,119 @@
+.. _enterprise-admin:
+
+===============================================================================
+Cluster administrator's guide
+===============================================================================
+
+This guide focuses on Enterprise-specific administration features available
+on top of Tarantool Community Edition with Tarantool Cartridge framework:
+
+* :ref:`space explorer <space_explorer>`
+* :ref:`upgrade of environment-independent applications in production <enterprise-production-upgrade>`
+
+Otherwise, consult the following documentation for:
+
+* basic information on
+  :doc:`deploying and managing a Tarantool cluster </book/cartridge/cartridge_admin>`
+* more information on
+  :doc:`managing Tarantool instances </book/admin/index>`
+
+.. _space_explorer:
+
+-------------------------------------------------------------------------------
+Exploring spaces
+-------------------------------------------------------------------------------
+
+The web interface lets you connect (in the browser) to any instance in the cluster
+and see what spaces it stores (if any) and their contents.
+
+To explore spaces:
+
+#. Open the **Space Explorer** tab in the menu on the left:
+
+   .. image:: images/space_explr_tab.png
+      :align: center
+      :scale: 80%
+
+#. Click **connect** next to an instance that stores data. The basic sanity-check
+   (``test.py``) of the example application puts sample data to one replica
+   set (shard), so its master and replica store the data in their spaces:
+
+   .. image:: images/spaces_with_data.png
+      :align: center
+      :scale: 80%
+
+   When connected to a instance, the space explorer shows a table with basic
+   information on its spaces. For more information, see the
+   :doc:`box.space reference </reference/reference_lua/box_space>`.
+
+   To see hidden spaces, tick the corresponding checkbox:
+
+   .. image:: images/hidden_spaces.png
+      :align: center
+      :scale: 80%
+
+#. Click the space's name to see its format and contents:
+
+   .. image:: images/space_contents.png
+      :align: center
+      :scale: 70%
+
+   To search the data, select an index and, optionally, its iteration type from
+   the drop-down lists, and enter the index value:
+
+   .. image:: images/space_search.png
+      :align: center
+      :scale: 80%
+
+.. _enterprise-production-upgrade:
+
+-------------------------------------------------------------------------------
+Upgrading in production
+-------------------------------------------------------------------------------
+
+To upgrade either a single instance or a cluster, you need a new version of the
+packaged (archived) application.
+
+A single instance upgrade is simple:
+
+#. Upload the package (archive) to the server.
+#. Stop the current instance.
+#. Deploy the new one as described in :ref:`deploying packaged applications <enterprise-packaged-app>`
+   (or :ref:`archived ones <enterprise-archived-app>`).
+
+.. _enterprise-cluster-upgrade:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Cluster upgrade
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To upgrade a cluster, choose one of the following scenarios:
+
+* **Cluster shutdown**. Recommended for backward-incompatible updates, requires
+  downtime.
+
+* **Instance by instance**. Recommended for backward-compatible updates, does
+  not require downtime.
+
+To upgrade the cluster, do the following:
+
+#. Schedule a downtime or plan for the instance-by-instance upgrade.
+
+#. Upload a new application package (archive) to all servers.
+
+Next, execute the chosen scenario:
+
+* **Cluster shutdown**:
+
+  #. Stop all instances on all servers.
+  #. Deploy the new package (archive) on every server.
+
+* **Instance by instance**. Do the following in every replica set in succession:
+
+  #. Stop a replica on any server.
+  #. Deploy the new package (archive) in place of the old replica.
+  #. Promote the new replica to a master (see
+     :ref:`Switching the replica set's master <cartridge-switch-master>`
+     section in the Tarantool manual).
+  #. Redeploy the old master and the rest of the instances in the replica set.
+  #. Be prepared to resolve possible logic conflicts.

doc/enterprise/audit.rst

@@ -0,0 +1,185 @@
+Security audit
+==============
+
+This document will help you audit the security of a Tarantool cluster.
+It explains certain security aspects, their rationale, and the ways to check them.
+For details on how to configure Tarantool Enterprise Edition and its infrastructure for each aspect,
+refer to the :doc:`security hardening guide <security>`.
+
+Encryption of external iproto traffic
+-------------------------------------
+
+Tarantool uses the
+:doc:`iproto binary protocol </dev_guide/internals/box_protocol>`
+for replicating data between instances and also in the connector libraries.
+
+Since version 2.10.0, the Enterprise Edition has the built-in support for using SSL to encrypt the client-server communications over binary connections.
+For details on enabling SSL encryption, see the :ref:`enterprise-iproto-encryption` section of this document.
+
+In case the built-in encryption is not enabled, we recommend using VPN to secure data exchange between data centers.
+
+Closed iproto ports
+-------------------
+
+When a Tarantool cluster does not use iproto for external requests,
+connections to the iproto ports should be allowed only between Tarantool instances.
+
+For more details on configuring ports for iproto,
+see the ``advertise_uri`` section in the Cartridge documentation.
+
+
+HTTPS connection termination
+----------------------------
+
+A Tarantool instance can accept HTTP connections from external services
+or access the administrative web UI.
+All such connections must go through an HTTPS-providing web server,
+running on the same host, such as nginx.
+This requirement is for both virtual and physical hosts.
+Running HTTP traffic through a few separate hosts with HTTPS termination
+is not sufficiently secure.
+
+
+Closed HTTP ports
+-----------------
+
+Tarantool accepts HTTP connections on a specific port, configured with
+``http_port: <number>`` value
+(see :ref:`configuring Cartridge instances <cartridge-config>`).
+It must be only available on the same host for nginx to connect to it.
+
+Check that the configured HTTP port is closed
+and that the HTTPS port (``443`` by default) is open.
+
+Restricted access to the administrative console
+-----------------------------------------------
+
+The :doc:`console </reference/reference_lua/console>` module provides
+a way to connect to a running instance and run custom Lua code.
+This can be useful for development and administration.
+The following code examples open connections on a TCP port and on a UNIX socket.
+
+..  code-block:: lua
+
+    console.listen(<port number>)
+    console.listen('/var/lib/tarantool/socket_name.sock')
+
+Opening an administrative console through a TCP port is always unsafe.
+Check that there are no calls like ``console.listen(<port_number>)``
+in the code.
+
+Connecting through a socket requires having the write permission on the
+``/var/lib/tarantool`` directory.
+Check that write permission to this directory is limited to the ``tarantool`` user.
+
+Limiting the guest user
+-----------------------
+
+Connecting to the instance with ``tt connect`` or ``tarantoolctl connect`` without
+user credentials (under the ``guest`` user) must be disabled.
+
+There are two ways to check this vulnerability:
+
+*   Check that the source code doesn't grant access to the ``guest`` user.
+    The corresponding code can look like this:
+
+    ..  code-block:: lua
+
+        box.schema.user.grant('guest',
+            'read,write',
+            'universe',
+            nil, { if_not_exists = true }
+        )
+
+    Besides searching for the whole code pattern,
+    search for any entries of ``'universe'``.
+
+*   Try connecting with ``tt connect`` to each Tarantool node.
+
+For more details, refer to the documentation on
+:ref:`access control <authentication>`.
+
+Authorization in the web UI
+---------------------------
+
+Using the web interface must require logging in with a username and password.
+See more details in the documentation on
+:ref:`configuring web interface authorization <cartridge-auth-enable>`.
+
+Running under the tarantool user
+--------------------------------
+
+All Tarantool instances should be running under the ``tarantool`` user.
+
+Limiting access to the tarantool user
+-------------------------------------
+
+The ``tarantool`` user must be a non-privileged user without the ``sudo`` permission.
+Also, it must not have a password set to prevent logging in via SSH or ``su``.
+
+
+Keeping two or more snapshots
+-----------------------------
+
+In order to have a reliable backup, a Tarantool instance must keep
+two or more latest snapshots.
+This should be checked on each Tarantool instance.
+
+The :ref:`snapshot_count <cfg_checkpoint_daemon-checkpoint_count>` value
+determines the number of kept snapshots.
+Configuration values are primarily set in the configuration files
+but :doc:`can be overridden </book/cartridge/cartridge_api/modules/cartridge.argparse>`
+with environment variables and command-line arguments.
+So, it's best to check both the values in the configuration files and the actual values
+using the console:
+
+..  code-block:: tarantoolsession
+
+    tarantool> box.cfg.checkpoint_count
+    ---
+    - 2
+
+
+Enabled write-ahead logging (WAL)
+---------------------------------
+
+Tarantool records all incoming data in the write-ahead log (WAL).
+The WAL must be enabled to ensure that data will be recovered in case of
+a possible instance restart.
+
+Secure values of ``wal_mode`` are ``write`` and ``fsync``:
+
+..  code-block:: tarantoolsession
+
+    tarantool> box.cfg.wal_mode
+    ---
+    - write
+
+An exclusion from this requirement is when the instance is processing data,
+which can be freely rejected.
+For example, when Tarantool is used for caching.
+Then WAL can be disabled to reduce i/o load.
+
+For more details, see the
+:ref:`wal_mode reference <cfg_binary_logging_snapshots-wal_mode>`.
+
+The logging level is INFO or higher
+-----------------------------------
+
+The logging level should be set to 5 (``INFO``), 6 (``VERBOSE``), or 7 (``DEBUG``).
+Application logs will then have enough information to research a possible security breach.
+
+..  code-block:: tarantoolsession
+
+    tarantool> box.cfg.log_level
+    ---
+    - 5
+
+For a full list of logging levels, see the
+:ref:`log_level reference <cfg_logging-log_level>`.
+
+
+Logging with journald
+---------------------
+
+Tarantool should use ``journald`` for logging.