moat-kv 0.70.24__py3-none-any.whl → 0.71.0__py3-none-any.whl

debian/control

@@ -0,0 +1,43 @@
+Source: moat-kv
+Maintainer: Matthias Urlichs <matthias@urlichs.de>
+Section: python
+Priority: optional
+Build-Depends: dh-python, python3-all, debhelper (>= 13), debhelper-compat (= 13),
+  python3-setuptools,
+  python3-wheel,
+Standards-Version: 3.9.6
+Homepage: https://github.com/smurfix/moat
+
+Package: moat-kv
+Architecture: all
+Depends: ${misc:Depends}, ${python3:Depends},
+  moat-mqtt (>= 0.38),
+  python3-anyio (>= 4),
+  python3-asyncclick (>= 1:8),
+  python3-asyncactor (>= 0.20),
+  python3-asyncscope (>= 0.5.5),
+  python3-attr (>= 19),
+  python3-systemd,
+  python3-range-set (>= 0.3),
+  python3-ruyaml (>= 0.89),
+  python3-simpleeval (>= 0.9.10),
+  moat-util,
+  moat-mqtt,
+  moat-main,
+  python3-moat-lib-diffiehellman,
+  systemd (>= 241),
+Recommends:
+  python3-trio (>= 0.22),
+Replaces: python3-distkv
+Conflicts: python3-distkv
+Description: A distributed no-master key-value store
+ MoaT-KV is a master-less distributed key-value storage system. It
+ circumvents the CAP theorem by assuming that keys are usually only changed
+ by one node. It is resistant to partitioning and intended to be always-on;
+ while it might delay – but will not lose – any updates.
+ .
+ MoaT-KV does not support data partitioning. Every node stores the whole
+ data set and can instantly deliver mostly-uptodate data.
+ .
+ MoaT-KV does not have a disk-based storage backend; periodic snapshots and/or
+ its event log are used to restore a system, if necessary.

debian/moat-kv/usr/lib/python3/dist-packages/moat/kv/_cfg.yaml

@@ -26,7 +26,6 @@ runner: # for moat.kv.runner.RunnerRoot
   state: !P :.moat.kv.state"
 
   name: "run"
-  # Serf event name, suffixed by subpath
 
   start_delay: 1
   # time to wait between job starts. Not optional.
@@ -56,9 +55,6 @@ server:
   # default
   mqtt:
     uri: "mqtt://localhost:1883"
-  serf:
-    host: "localhost"
-    port: 7373
 
   # event message path/topic prefix
   root: !P moat.kv
@@ -79,10 +75,10 @@ server:
   ping:
     cycle: 10
     gap: 2
-    # asyncserf.Actor config timing for server sync
+    # asyncactor config timing for server sync
   # ping also controls minimum server startup time
   delete:
-    # asyncserf.Actor config timing for deletion
+    # asyncactor config timing for deletion
     cycle: 100
     gap: 10
     version: 1

debian/moat-kv/usr/lib/python3/dist-packages/moat/kv/backend/mqtt.py

@@ -11,9 +11,6 @@ from . import Backend
 
 logger = logging.getLogger(__name__)
 
-# Simply setting connect=asyncserf.serf_client interferes with mocking
-# when testing.
-
 
 class MqttMessage:
     def __init__(self, topic, payload):

debian/moat-kv.postinst

@@ -0,0 +1,3 @@
+#!/bin/sh
+
+/usr/lib/moat/kv/init

debian/rules

@@ -0,0 +1,20 @@
+#!/usr/bin/make -f
+
+# This file was automatically generated by stdeb 0.8.5 at
+# Sun, 21 Apr 2019 07:51:58 +0200
+export PYBUILD_NAME=moat-kv
+export LOG_CFG=$(shell pwd)/tests/logging.cfg
+export MSGPACK_PUREPYTHON=1
+%:
+	dh $@ --with python3 --buildsystem=pybuild
+
+override_dh_install:
+	dh_install
+	$(MAKE) install PREFIX=debian/moat-kv
+
+override_dh_python3:
+	dh_python3
+	rm -f debian/moat-kv/usr/lib/python3/dist-packages/test.log
+
+override_dh_auto_test:
+	: skip

debian/source/format

@@ -0,0 +1 @@
+3.0 (quilt)

debian/watch

@@ -0,0 +1,4 @@
+# please also check http://pypi.debian.net/distkv/watch
+version=3
+opts=uversionmangle=s/(rc|a|b|c)/~$1/ \
+http://pypi.debian.net/distkv/distkv-(.+)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))

docs/Makefile

@@ -0,0 +1,20 @@
+# Minimal makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS    =
+SPHINXBUILD   = sphinx-build
+SPHINXPROJ    = MoaT-KV
+SOURCEDIR     = source
+BUILDDIR      = build
+
+# Put it first so that "make" without argument is like "make help".
+help:
+	@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
+
+.PHONY: help Makefile
+
+# Catch-all target: route all unknown targets to Sphinx using the new
+# "make mode" option.  $(O) is meant as a shortcut for $(SPHINXOPTS).
+%: Makefile
+	@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)

docs/make.bat

@@ -0,0 +1,36 @@
+@ECHO OFF
+
+pushd %~dp0
+
+REM Command file for Sphinx documentation
+
+if "%SPHINXBUILD%" == "" (
+	set SPHINXBUILD=sphinx-build
+)
+set SOURCEDIR=source
+set BUILDDIR=build
+set SPHINXPROJ=MoaT-KV
+
+if "%1" == "" goto help
+
+%SPHINXBUILD% >NUL 2>NUL
+if errorlevel 9009 (
+	echo.
+	echo.The 'sphinx-build' command was not found. Make sure you have Sphinx
+	echo.installed, then set the SPHINXBUILD environment variable to point
+	echo.to the full path of the 'sphinx-build' executable. Alternatively you
+	echo.may add the Sphinx directory to PATH.
+	echo.
+	echo.If you don't have Sphinx installed, grab it from
+	echo.http://sphinx-doc.org/
+	exit /b 1
+)
+
+%SPHINXBUILD% -M %1 %SOURCEDIR% %BUILDDIR% %SPHINXOPTS%
+goto end
+
+:help
+%SPHINXBUILD% -M help %SOURCEDIR% %BUILDDIR% %SPHINXOPTS%
+
+:end
+popd

docs/source/TODO.rst

@@ -0,0 +1,61 @@
+Open issues
+===========
+
+* Exchange a version code on startup
+
+* CBOR
+
+* Ping: ignore messages with decreasing tock (per node)
+
+* chroot operation: add and test proper sub-roots, including auth and
+  whatnot
+
+* We need path translation. Idea: store an extension element in the
+  destination path, which would pick the appropriate parts from the
+  source path when processed.
+
+  2-element tuples would probably work also, given that it's unlikely that
+  people use complex elements in their path, but why limit ourselves?
+
+* ACLs for system data, i.e. those stored below ``None``.
+
+* after starting with initial data, wait until the Actor is up and we're
+  synced to the other nodes
+
+* Teach the server to also run an executor (or two or three or …)
+
+* Rather than mangling split messages, use a MsgPack extension type.
+
+* AnyRunner: Do proper load balancing; the leader should be able to tell
+  some other node to run a job if it's busy.
+
+* Keep an error index on the server?  Something more general?
+
+* Restart code that's been changed (without waiting for restart/retry).
+
+* Use cryptography.hazmat.primitives.asymmetric.x25519 instead of
+  Diffie-Hellman to send passwords to the server.
+
+* Implement a shared secret to sign server-to-server messages.
+
+* Runner: switch to monotonic time (except for target time!)
+
+* Error consolidation: if a conflict doesn't get resolved on its own, do it
+  anyway when we are "it" next and >1 cycle has passed
+
+* Add a command to cleanly flush the server log and stop the server.
+
+* Test iterator on changed config entries
+
+* errors: better display
+
+* errors: manually acknowledge and delete them
+
+* errors: add a web service to monitor them?
+
+* Runner: store the number of active group members / actor config in the group
+
+* Restore passing positional parameters as keywords (to code entries)
+
+* Add a maintainer mode (user flag) that allows limited access when data is missing
+

docs/source/acls.rst

@@ -0,0 +1,80 @@
+==============
+Access control
+==============
+
+MoaT-KV employs a two-step access control scheme.
+
+First, you define an ACL hierarchy which controls which items may be
+accessed using a particular named ACL. Then you associate that ACL
+with users that shall be bound by it.
+
+
+ACLs
+====
+
+An ACL entry controls these access modes:
+
+* a: acl: retrieve the ACL flags for this node
+* r: read: retrieve the data at this node
+* w: write: change the data at this node
+* c: create: add new data to this node
+* d: delete: remove the data at this node
+* x: access: read specific sub-nodes below this one
+* e: enumerate: list sub-nodes of this one
+* n: new: create new nodes below this one
+
+In the MoaT-KV sources you'll also encounter these modes in calls to
+``follow_acl`` (i.e. these flags can be checked for but you cannot set
+them):
+
+* W: check 'c' if the node is new or has no data, else 'w'
+
+ACLs can use wildcards '+' (one level) and '#' (one or more levels).
+Search is depth-first; more specific keys are checked first.
+
+
+Association
+===========
+
+You change a user's ACL entry by adding an "acl=ACLNAME" field to the
+user's aux data. The user is affected as soon as they log back in.
+
+Updated ACL records are effective immediately.
+
+
+Putting it all together
+=======================
+
+Given the following data structure, the user "aclix" will only be able to
+write initial data to ``one`` and ``one two``. They can also read the data
+back. However, any other access is not possible::
+
+    null:
+      auth:
+        _:
+          current: _test
+        _test:
+          user:
+            aclix:
+              _:
+                _aux:
+                  acl: foo
+            std:
+              _:
+                _aux: {}
+      acl:
+        foo:
+          one:
+            _: rxnc
+            two:
+              _: rc
+    one:
+      _: 10
+      two:
+        _: 11
+    
+
+The above is the server content at the end of the testcase
+``tests/test_feature_acls.py::test_81_basic``, when
+dumped with the command ``moat kv : get -rd_``.
+

docs/source/auth.rst

@@ -0,0 +1,84 @@
+=========================
+MoaT-KV and authentication
+=========================
+
+MoaT-KV ships with a couple of rudimentary auth modules.
+
+The server's initial message lists the accepted authentication methods
+(``auth`` entry).
+
+Depending on the server version, auth requests may be answered with a
+stream even if the method doesn't actually require it. Login is successful
+if the reply (or stream-end message) doesn't contain an error.
+
+Included user auth methods
+==========================
+
+root
+----
+
+No access control. There is one possible user named "*"::
+
+    <<< {'seq': 0, 'version': (0, 58, 12), 'node': 'dev', 'auth': ('root',), …}
+    >>> {'typ': 'root', 'ident': '*', 'action': 'auth', 'seq': 1}
+    <<< {'state': 'start', 'seq': 2, 'wseq': 1, 'tock': 123}
+    <<< {'state': 'end', 'seq': 2, 'wseq': 2, 'tock': 124}
+
+password
+--------
+
+This is the standard "username plus password" method. Passwords are hashed
+and salted on the server; transmission of the cleartext password is
+protected with a separate shared secret (Diffie-Hellman).
+
+This method currently is a bit slow, unless you use test mode (in which
+case it's a bit insecure).
+
+The client initiates a Diffie-Hellman handshake if required, then wraps the
+SHA256 of the password in a ``SecretBox`` (using a random nonce) and sends
+that to the server. Logging in as ``root``::
+
+    <<< {'seq': 0, 'version': (0, 58, 12), 'node': 'dev', 'auth': ('password',), …}
+    >>> {'pubkey': b'[256 bytes]', 'length': 1024, 'action': 'diffie_hellman', 'seq': 1}
+    <<< {'pubkey': b'[256 bytes]', 'seq': 1, 'tock': 999}
+    >>> {'typ': 'password', 'ident': 'root', 'password': b'[data]', 'action': 'auth', 'seq': 2}
+    <<< {'state': 'start', 'seq': 2, 'wseq': 1, 'tock': 1001}
+    <<< {'state': 'end', 'seq': 2, 'wseq': 2, 'tock': 1002}
+
+_test
+-----
+
+This is a test method that's suitable for experiments and testing.
+
+Users do not have a password.
+
+
+API
+===
+
+The authorization code is modular. MoaT-KV allows loading multiple auth
+methods, one of which is active. A method may use more than one record type
+(think "user" or "group"). Each of those records has a name.
+
+The "user" type is only special because server and client use that to
+process login requests.
+
+Multiple distinct MoaT-KV domains or subdomains are possible, by adding an
+additional meta-root record anywhere in the entry hierarchy.
+
+
+.. module:: moat.kv.auth
+
+.. autofunction:: loader
+
+.. autoclass:: BaseServerAuth
+   :members:
+
+.. autoclass:: BaseClientAuth
+   :members:
+
+.. autoclass:: BaseServerAuthMaker
+   :members:
+
+.. autoclass:: BaseClientAuthMaker
+   :members: