Merge mgmt-design into admin-api

services/admin-api.md

@@ -5,17 +5,61 @@ permalink: /doc/admin-api/
 redirect_from:
 - /doc/mgmt/
 - /doc/mgmt1/
+- /doc/mgmt-architecture/
+- /doc/admin-api-architecture/
 ---
 
-# Admin API
+# Qubes OS Admin API
 
 *(This page is the current draft of the proposal. It is not implemented yet.)*
 
-The API should be implemented as a set of qrexec calls. This is to make it easy
+## Goals
-to set the policy using current mechanism.
+
+The goals of the Admin API system is to provide a way for the user to manage
+the domains without direct access to dom0.
+
+Foreseen benefits include:
+
+- Ability to remotely manage the Qubes OS.
+- Possibility to create multi-user system, where different users are able to use
+  different sets of domains, possibly overlapping. This would also require to
+  have separate GUI domain.
+
+The API would be used by:
+
+- Qubes OS Manager (or any tools that would replace it)
+- CLI tools, when run from another VM (and possibly also from dom0)
+- remote management tools
+- any custom tools
+
+## Threat model
+
+TBD
+
+## Components
+
+![Admin API Architecture][admin-api-architecture]
+
+A central entity in the Qubes Admin API system is a `qubesd` daemon, which
+holds information about all domains in the system and mediates all actions (like
+starting and stopping a qube) with `libvirtd`. The `qubesd` daemon also manages
+the `qubes.xml` file, which stores all persistent state information and
+dispatches events to extensions. Last but not least, `qubesd` is responsible for
+querying the RPC policy for qrexec daemon.
+
+The `qubesd` daemon may be accessed from other domains through a set of qrexec
+API calls called the "Admin API". This API is the intended
+management interface supported by the Qubes OS. The API is stable. When called,
+the RPC handler performs basic validation and forwards the request to the
+`qubesd` via UNIX domain socket. The socket API is private and unstable. It is
+documented [FIXME currently it isn't -- woju 20161221] in the developer's
+documentation of the source code.
 
 ## The calls
 
+The API should be implemented as a set of qrexec calls. This is to make it easy
+to set the policy using current mechanism.
+
 | call                                  | dest      | argument  | inside                                    | return                                                    | note |
 | ------------------------------------- | --------- | --------- | ----------------------------------------- | --------------------------------------------------------- | ---- |
 | `admin.vmclass.List`                   | `dom0`    | -         | -                                         | `<class>\n`                                               |
@@ -188,3 +232,7 @@ a&nbsp;default Qubes OS installation. However, they are created anyway.
   `qrexec-client-vm`
 
 <!-- vim: set ts=4 sts=4 sw=4 et : -->
+
+[admin-api]: ../admin-api/
+[admin-api-architecture]: /attachment/wiki/AdminAPI/admin-api-architecture.svg
+

services/mgmt-design.md

@@ -1,57 +0,0 @@
----
-layout: doc-full
-title: Admin API architecture
-permalink: /doc/admin-api-architecture/
-redirect_from:
- - /doc/mgmt-architecture/
----
-
-# Qubes OS Admin API Architecture
-
-*(This page is the current draft of the proposal. It is not implemented yet.)*
-
-## Goals
-
-The goals of the Admin API system is to provide a way for the user to manage
-the domains without direct access to dom0.
-
-Foreseen benefits include:
-
-- Ability to remotely manage the Qubes OS.
-- Possibility to create multi-user system, where different users are able to use
-  different sets of domains, possibly overlapping. This would also require to
-  have separate GUI domain.
-
-The API would be used by:
-
-- Qubes OS Manager (or any tools that would replace it)
-- CLI tools, when run from another VM (and possibly also from dom0)
-- remote management tools
-- any custom tools
-
-## Threat model
-
-TBD
-
-## Components
-
-![Admin API Architecture][admin-api-architecture]
-
-A central entity in the Qubes Admin API system is a `qubesd` daemon, which
-holds information about all domains in the system and mediates all actions (like
-starting and stopping a qube) with `libvirtd`. The `qubesd` daemon also manages
-the `qubes.xml` file, which stores all persistent state information and
-dispatches events to extensions. Last but not least, `qubesd` is responsible for
-querying the RPC policy for qrexec daemon.
-
-The `qubesd` daemon may be accessed from other domains through a set of qrexec
-API calls called the [Admin API][admin-api]. This API is the intended
-management interface supported by the Qubes OS. The API is stable. When called,
-the RPC handler performs basic validation and forwards the request to the
-`qubesd` via UNIX domain socket. The socket API is private and unstable. It is
-documented [FIXME currently it isn't -- woju 20161221] in the developer's
-documentation of the source code.
-
-[admin-api]: ../admin-api/
-
-[admin-api-architecture]: /attachment/wiki/AdminAPI/admin-api-architecture.svg