From 1b51f04b0abab9ffd56e084785592bf21ed14603 Mon Sep 17 00:00:00 2001 From: Silvio Rhatto Date: Sun, 1 Oct 2017 17:21:45 -0300 Subject: Change markdown extension to .md --- analisys.md | 151 ++++++++++++++++++++++++++++++++++++++++++++ analisys.mdwn | 151 -------------------------------------------- index.md | 200 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ index.mdwn | 200 ---------------------------------------------------------- 4 files changed, 351 insertions(+), 351 deletions(-) create mode 100644 analisys.md delete mode 100644 analisys.mdwn create mode 100644 index.md delete mode 100644 index.mdwn diff --git a/analisys.md b/analisys.md new file mode 100644 index 0000000..8a6534d --- /dev/null +++ b/analisys.md @@ -0,0 +1,151 @@ +# Analysis + +For those who need a detailed explanation about what RSP is and why it can be useful, the following sections cover the economic aspects of resource sharing for system administration. + +# The Problem + +Sometimes free software projects face a resource crisis than can be understood as a lack of means to keep their efforts going on, but at the same time can be understood as a crisis of the current paradigm of organization (maybe both technological and social). + +That happens especially with softwares which are part of the long part of the tail and if they're not willing to use a too much standardized hosting service such as Sourceforge or Google Code. + +Maybe wouldn't be too hard to do a paradigm shift, not a profound one, but one that can address the current precarity of the server infostructure. + +Some kind of coordination/organization and/or even a standard or protocol can help to to facilitate the resource sharing because currently things are done more or less loosely among different groups that share things -- not exactly because people are "loose" but maybe because that was the way that worked very well until the community realizes that they need something better -- and then things can get easily messed with stuff such as no one knowing whether some system is updated, has backups or if the disks are failing. + +For groups which depend on servers, its possible to frame the problem in an economic fashion, where we consider some limited resources, usually like: + +* Servers + * Bandwidth + * Disk + * CPU + * Memory +* Operational: number of people and hours/week they can help. +* Financial +* Legal + +The possible solutions for the group organization are sets of ways these resources can be combined in a given group or group of groups in order to maximize the resource usage. + +One approach is to build social organizations that help to use better the resources, like the sharing of protocols, software, configurations or even the physical resources. Softwares are useful ways to "encode" in a package some efforts that can be easily replicated and the same happens with protocols and configurations. + +# Organizational crisis + +When such things happen, the groups pass from an accumulation "level" to another. A tech-infrastructure crisis can be understood as a failure to sustain an accumulation level: groups so far accumulated a lot of (sometimes sensitive) data the we try to protect from an hostile environment. + +The current way groups organize their resources usage might be insufficient to protect them from multiple different threats (data loss, centralization, etc). + +Maybe this happens because they're still not so used to share they physical resources. Sharing a software solution is way easier because one just needs to make a regular package and give it to people, while sharing concurrent/rival resources seens to be a lot more complex. + +So, in short: a resource crisis can be seem as a failure to organize the resource usage inside a group or among a group of groups. While groups are partially successfull is sharing non-rival goods (protocols, software, configurations, and partially because its possible to do it better), they are still failing in sharing our concurrent/rival resources like diskspace and bandwidth. + +It's not just a way to just have a big server and create a lot of vservers and give it to groups because a solution that scales in a way that can be easily managed and doesn't need more workload is still needed. + +Each group usually can take care physically of just one or two servers/racks in the same or different locations. But having just servers in two locations is still not so safe, so an easy way to share this physical resource would be to let other groups give and get virtual spaces inside the real boxes. This way, a group with just one server can have lots of virtual spaces in friend's groups. + +# Virtualization Alliance + +Some "alliance" assumes some sort of mutual benefit -- altough there are groups can't or don't need to give retributions for received help. There are groups that can help each other (but not a requisite for participation) and a coordination goes beyond a given technology such as server virtualization and then needs also a social technology. + +Usually, replication of virtualization technologies consists basically of backing up both the server space and the configuration needed to run it. There are advantages and disadvantages of each virtualization platform (vserver uses a lot less resources while other platforms allows running things in kernel mode like file system encryption independently from the host). + +Considering a group that requests virtual space and depending in the use the group want to give, it doesn't matter too much whether their virtual space uses technology X or Y (as virtual spaces are intended to act as independent servers anyway). + +So a general "Virtualization Alliance" could be formed by + +* Groups that hosts virtualized environments using technology X. +* Groups that hosts virtualized environments using technology Y. +* [...] +* Groups that needs virtualized environments using technology X. +* Groups that needs virtualized environments using technology Y. +* [...] +* Groups that needs virtualized environments with no tech. preference. + +So groups using the same technology perhaps could be grouped toghether to share data, specific configurations, etc. + +# Backups of virtualized environments + +As an example, for backup purposes, we could consider the following options: + +* External backups (i.e, backups made from the host server by the group hosting the virtual space): + * Groups that hosts virtualized environments and make backups of them. + * Groups that hosts virtualized environments and do not make backups of them. +* Internal backups: those made from inside a virtual environment to somewhere else made by the hosted group. + +Note that its possible that a given virtual environment be backed up by both "external" and "internal" methods, they're not mutual exclusive methods. + +# Labor + +There's also some other parameters to consider: how much labor is needed to keep a server running? Considering a debian box with vservers, how much work is needed to: + +* Install/reinstall a system? +* Keep the system up to date? +* Change configurations? +* Emergencies? + +Sure these points depend in the configuration (eg. with puppet perhaps the cost of install/reinstall falls to near zero). Crossing this information with the nummber of available people (and how much work they can do) can help to shape if the group is ready to have more boxes. + +If the server setup is scalable and easy to maintain, maybe a small group can do the job, but one important point is to shape everything to minimize points of failures (like systems depending on single servers or in just a small number of people to operate). + +# Towards a resource sharing protocol + +If the problems is restricted just to virtualized environments, a lot of effort can be lost in system and service replication while saving labour. Its importante to note that there are groups that can deal with: + +* Hardware. +* Sysadmin (hosts or virtual spaces). +* Applications (websites, mailing lists, etc). +* Other stuff. + +Maybe there are groups that can do all, but we can assume that these are three big types of labor so we'll have groups that can/want to do just one, two or all these jobs. So the problem would be to combine these resources and specializations together. + +In order to integrate groups working at different "levels" and allow then to share resources, lets start thinking about layers and a protocol to help them to share things among different layers. + +# Layer-based replication + +Spliting resources in service layers helps not just groups sharing their resources but also ease the task of service and data replication. That's not new: the whole OSI model address at least part of these goals. + +As an example, consider two different machines composed by service layers like in the diagram below: + + _________ _________ + | | replication | | + | service |------------>| service | + |_________| .------>|_________| + | |----' | | + |_________|------------>|_________| + + machine 1 machine 2 + +We can even consider that: + +* Each service can inherit some characteristics from the lower layers. +* Hence, each service can depend on some set of characteristics from the lower layers. +* Service/data replication can be deal as backups and vice-versa. +* Layers usually can "see" and access each other, but usually an upper layer cannot replicate the lower ones, but the contrary is generally true. + +Then, replication can in general take place from a layer who copies itself to another layer it has read/write access or lower layers that can copy themselves and the upper layers to other places. There's not even the requisite to a layer (eg. a vserver) to copy itself to another vserver: it can copy itself to wherever it has access to, altough some groups might prefer to set some layer hierarchy and replication rules to avoid confusion. + +A consequence of property inheritance between layers should be considered when replicating a layer: the overall layer characteristics depends on the characteristics of the layers below. + +Layers can be even virtual: consider the equivalence of these two systems: + + _________ + | | + | email | + |_________| ____________ + | | | | + | Zone | equivalence | OS / Email | + |_________| --------------> |____________| + | | | | + | OS | | Machine | + |_________| |____________| + | | + | Machine | + |_________| + +Then, for a layer sitting on top of one or another system there's not much difference in terms of property inheritance. + +# How RSP fits into all this mess + +The RSP can be used to help the groups: + +* Evaluate their available resources and possible uses for it, like establishing classes of resources with similar metadata which fits sets of uses. +* Inform other groups about the resources they have and need. +* Set their layer/replication policy. diff --git a/analisys.mdwn b/analisys.mdwn deleted file mode 100644 index 8a6534d..0000000 --- a/analisys.mdwn +++ /dev/null @@ -1,151 +0,0 @@ -# Analysis - -For those who need a detailed explanation about what RSP is and why it can be useful, the following sections cover the economic aspects of resource sharing for system administration. - -# The Problem - -Sometimes free software projects face a resource crisis than can be understood as a lack of means to keep their efforts going on, but at the same time can be understood as a crisis of the current paradigm of organization (maybe both technological and social). - -That happens especially with softwares which are part of the long part of the tail and if they're not willing to use a too much standardized hosting service such as Sourceforge or Google Code. - -Maybe wouldn't be too hard to do a paradigm shift, not a profound one, but one that can address the current precarity of the server infostructure. - -Some kind of coordination/organization and/or even a standard or protocol can help to to facilitate the resource sharing because currently things are done more or less loosely among different groups that share things -- not exactly because people are "loose" but maybe because that was the way that worked very well until the community realizes that they need something better -- and then things can get easily messed with stuff such as no one knowing whether some system is updated, has backups or if the disks are failing. - -For groups which depend on servers, its possible to frame the problem in an economic fashion, where we consider some limited resources, usually like: - -* Servers - * Bandwidth - * Disk - * CPU - * Memory -* Operational: number of people and hours/week they can help. -* Financial -* Legal - -The possible solutions for the group organization are sets of ways these resources can be combined in a given group or group of groups in order to maximize the resource usage. - -One approach is to build social organizations that help to use better the resources, like the sharing of protocols, software, configurations or even the physical resources. Softwares are useful ways to "encode" in a package some efforts that can be easily replicated and the same happens with protocols and configurations. - -# Organizational crisis - -When such things happen, the groups pass from an accumulation "level" to another. A tech-infrastructure crisis can be understood as a failure to sustain an accumulation level: groups so far accumulated a lot of (sometimes sensitive) data the we try to protect from an hostile environment. - -The current way groups organize their resources usage might be insufficient to protect them from multiple different threats (data loss, centralization, etc). - -Maybe this happens because they're still not so used to share they physical resources. Sharing a software solution is way easier because one just needs to make a regular package and give it to people, while sharing concurrent/rival resources seens to be a lot more complex. - -So, in short: a resource crisis can be seem as a failure to organize the resource usage inside a group or among a group of groups. While groups are partially successfull is sharing non-rival goods (protocols, software, configurations, and partially because its possible to do it better), they are still failing in sharing our concurrent/rival resources like diskspace and bandwidth. - -It's not just a way to just have a big server and create a lot of vservers and give it to groups because a solution that scales in a way that can be easily managed and doesn't need more workload is still needed. - -Each group usually can take care physically of just one or two servers/racks in the same or different locations. But having just servers in two locations is still not so safe, so an easy way to share this physical resource would be to let other groups give and get virtual spaces inside the real boxes. This way, a group with just one server can have lots of virtual spaces in friend's groups. - -# Virtualization Alliance - -Some "alliance" assumes some sort of mutual benefit -- altough there are groups can't or don't need to give retributions for received help. There are groups that can help each other (but not a requisite for participation) and a coordination goes beyond a given technology such as server virtualization and then needs also a social technology. - -Usually, replication of virtualization technologies consists basically of backing up both the server space and the configuration needed to run it. There are advantages and disadvantages of each virtualization platform (vserver uses a lot less resources while other platforms allows running things in kernel mode like file system encryption independently from the host). - -Considering a group that requests virtual space and depending in the use the group want to give, it doesn't matter too much whether their virtual space uses technology X or Y (as virtual spaces are intended to act as independent servers anyway). - -So a general "Virtualization Alliance" could be formed by - -* Groups that hosts virtualized environments using technology X. -* Groups that hosts virtualized environments using technology Y. -* [...] -* Groups that needs virtualized environments using technology X. -* Groups that needs virtualized environments using technology Y. -* [...] -* Groups that needs virtualized environments with no tech. preference. - -So groups using the same technology perhaps could be grouped toghether to share data, specific configurations, etc. - -# Backups of virtualized environments - -As an example, for backup purposes, we could consider the following options: - -* External backups (i.e, backups made from the host server by the group hosting the virtual space): - * Groups that hosts virtualized environments and make backups of them. - * Groups that hosts virtualized environments and do not make backups of them. -* Internal backups: those made from inside a virtual environment to somewhere else made by the hosted group. - -Note that its possible that a given virtual environment be backed up by both "external" and "internal" methods, they're not mutual exclusive methods. - -# Labor - -There's also some other parameters to consider: how much labor is needed to keep a server running? Considering a debian box with vservers, how much work is needed to: - -* Install/reinstall a system? -* Keep the system up to date? -* Change configurations? -* Emergencies? - -Sure these points depend in the configuration (eg. with puppet perhaps the cost of install/reinstall falls to near zero). Crossing this information with the nummber of available people (and how much work they can do) can help to shape if the group is ready to have more boxes. - -If the server setup is scalable and easy to maintain, maybe a small group can do the job, but one important point is to shape everything to minimize points of failures (like systems depending on single servers or in just a small number of people to operate). - -# Towards a resource sharing protocol - -If the problems is restricted just to virtualized environments, a lot of effort can be lost in system and service replication while saving labour. Its importante to note that there are groups that can deal with: - -* Hardware. -* Sysadmin (hosts or virtual spaces). -* Applications (websites, mailing lists, etc). -* Other stuff. - -Maybe there are groups that can do all, but we can assume that these are three big types of labor so we'll have groups that can/want to do just one, two or all these jobs. So the problem would be to combine these resources and specializations together. - -In order to integrate groups working at different "levels" and allow then to share resources, lets start thinking about layers and a protocol to help them to share things among different layers. - -# Layer-based replication - -Spliting resources in service layers helps not just groups sharing their resources but also ease the task of service and data replication. That's not new: the whole OSI model address at least part of these goals. - -As an example, consider two different machines composed by service layers like in the diagram below: - - _________ _________ - | | replication | | - | service |------------>| service | - |_________| .------>|_________| - | |----' | | - |_________|------------>|_________| - - machine 1 machine 2 - -We can even consider that: - -* Each service can inherit some characteristics from the lower layers. -* Hence, each service can depend on some set of characteristics from the lower layers. -* Service/data replication can be deal as backups and vice-versa. -* Layers usually can "see" and access each other, but usually an upper layer cannot replicate the lower ones, but the contrary is generally true. - -Then, replication can in general take place from a layer who copies itself to another layer it has read/write access or lower layers that can copy themselves and the upper layers to other places. There's not even the requisite to a layer (eg. a vserver) to copy itself to another vserver: it can copy itself to wherever it has access to, altough some groups might prefer to set some layer hierarchy and replication rules to avoid confusion. - -A consequence of property inheritance between layers should be considered when replicating a layer: the overall layer characteristics depends on the characteristics of the layers below. - -Layers can be even virtual: consider the equivalence of these two systems: - - _________ - | | - | email | - |_________| ____________ - | | | | - | Zone | equivalence | OS / Email | - |_________| --------------> |____________| - | | | | - | OS | | Machine | - |_________| |____________| - | | - | Machine | - |_________| - -Then, for a layer sitting on top of one or another system there's not much difference in terms of property inheritance. - -# How RSP fits into all this mess - -The RSP can be used to help the groups: - -* Evaluate their available resources and possible uses for it, like establishing classes of resources with similar metadata which fits sets of uses. -* Inform other groups about the resources they have and need. -* Set their layer/replication policy. diff --git a/index.md b/index.md new file mode 100644 index 0000000..be9f6d0 --- /dev/null +++ b/index.md @@ -0,0 +1,200 @@ +# The protocol + +The **Resource Sharing Protocol** (RSP) is a set of metadata intended to help free software groups and was **replaced in favour of** [ISO 1312](https://iso1312.fluxo.info). + +* Share their available resources and also +* Find groups that can host services for them given their needs and requirements. + +The RSP splits each resource in a layer or set of service layers. You can think of service layers something very general, ranging from servers, databases, websites. If you need to, you can even consider stuff such as tables and bicycles as layers that provide some kind of service to a hosted group. ;) + +The core protocol is composed by the following metadata: + +* Version: RSP version. +* Date: when this metadata was generated. +* Next audit: time where metadata update will happen (if applicable). +* Layer type. +* Layer name (if applicable). +* Layer implementation (eg. if virtual zone: distro name, version, etc). +* Available disk space. +* Available memory. +* Available CPU. +* UPS capacity/characteristics. +* Average downtime. +* Timezone. +* Available system capabilities. +* Networking + * Available bandwidth. + * Real IP availability. + * Proxy availability. + * Firewall/routing availability. + * VPN availability. +* Who admins/updates the layer: + * The hosting group? + * The hosted group? +* Security: + * Security and privacy policy for the layer. + * Crypto + * Implementation. + * Cipher. + * Used procedure. + * Shared password? Which sharing scheme? + * Boot procedure: + * The host has automatic boot loading. + * No boot loading in the host, manual boot. +* Backups + * Backup availability + * No backups. + * Local backups. + * Remote backups in more than a single place but in the same building/jurisdiction/etc. + * Remote backups in more than a single place and also in other countries. + * Backup security + * Have unencrypted backups. + * Have encrypted backups only. + * Have encrypted backups only with a key that needs more than one sysadmin to unlock. + * Have encrypted backups only with a key that the sysadmins do not have access to. + * Backup integrity + * No integrity checking. + * Signed backups only. + * Push and signed backups. + * Pull and signed backups only. + * Backup and users + * Users are informed whether their private data are being backed up and in which ways. + * Have backup data always available to private download by users and/or groups with admin aid. + * Have backup data always available to private download by users and/or groups without admin aid. + * Users and/or groups can choose to not have backups of their data. +* Legal + * Applicable law where layer is located. + * Hosting group has legal team/support? + * Available copyright licenses allowed in the layer. +* Financial + +# Packages + +Even if the metadata supports different configurations, it can be unsuitable to use all set for each application or layer specificiation, especially if you're dealing with multiple layers, one atop of another. Then, it is possible to have a more generic list of prerequisite information, along the lines of a debian package. these are the debian headings: + + Package: + State: + Automatically installed: + Version: + Priority: + Section: + Maintainer: + Uncompressed Size: + Depends: + Suggests: + Conflicts: + Replaces: + Provides: + Description: + +So possible descriptions for a layer could be something like: + + Package: [generic name/category]{server-vserver} + State: [hardware, software, network, labor, physical item]{hardware} + Reusable: [limited availability or recurring possibility?]{continuing} + Version: [specific 'local' name]{project_name_1.0} + Priority: [required/important/standard/optional/extra]{required} + Section: [admin/backups/mirrors/doc/comms]{admin} + Maintainer: [host/user]{host} + Size: [amount or n/a]{10GB} + Depends: + Suggests: network-traffic (=project_name_*), encryption-policy (=project_name_*), + reciprocation-policy (>=1.2) + Conflicts: server-*, + Replaces: vserver + Provides: vserver, server-encryption + Description: encrypted vserver + This package provides a 10 GB vserver hosted on an + individually encrypted single partition. Root administrative + access is provided via ssh using key-based authentication, in + line with standard encryption policy. Bandwidth can be added + by using the network-bw_project_name_* packages. + +Where + + key: [text in square brackets] = comment or possible options + {text in squiggly brackets} = example + +This way, RSP metadata is encapsulated in resource packages that can be announced, distributed or kept for internal use, alowing a given resource to have it's own dependency set and property inheritance. + +# Rulesets + +It is not strict builtin in the protocol but your group can also adopt internal rules regarding what goes at each layer. As an example, a group can adopt a data persistence rule such as data in a layer with a given level of security cannot be moved to a layer with a lower security level, except in cases it is temporarily or permanently declassified. + +# Implementation + +The RSP implementation does not come directly from the protocol. It can be implemented several ways, like keeping tables or wiki pages with detailed information about each layer a given group (or groups) have, can offer or needs. You could even consider to write a script to keep this data updated, although this can be very difficult. One of the best ways to keep the metadata updated is through periodical audits in each layer. + +RSP is meant to be simple enough to be both human and machine readable. So, when considering an implementation, think about those two main types of readability. + +# Applications + +* Ask for resources. +* Resource announcement: + * Offer a resource. + * Ask others to copy a resource. +* Check if a resource exist (ping a website, etc). + +# Metadata examples + +A Linux-VServer instance could hold the following metadata values: + +* Version: 01. +* Date: 20090409. +* Next audit: 20090820. +* Layer type: Linux VServer. +* Layer name: layer.example.org. +* Layer implementation: Debian 5.0. +* Available disk space: 20GB. +* Available memory: 500MB. +* ... + +Another example could be a database: + +* Version: 01. +* Date: 20090409. +* Next audit: 20090820. +* Layer type: SQL. +* Layer name: dbname@layer.example.org. +* Layer implementation: MySQL 5.1. +* ... + +# Version + +This is RSP Version: 0.1. + +# Development + +RSP development and maintenance ins't a hard task: it's just a matter of: + +* Keep a backward-compatible list of metadata. +* Try to fit all needs into the set. +* KISS. + +# Analysis + +See [[analysis|analisys]]. + +# License + +RSP is distributed under the [GNU Affero General Public License](http://www.gnu.org/licenses/agpl-3.0.html): + + Resource Sharing Protocol - RSP + Copyright (C) 2009 RSP Development Team + + This program is free software: you can redistribute it and/or modify + it under the terms of the GNU Affero General Public License as + published by the Free Software Foundation, either version 3 of the + License, or any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU Affero General Public License for more details. + + You should have received a copy of the GNU Affero General Public License + along with this program. If not, see . + +---- + +This wiki is powered by [ikiwiki](http://ikiwiki.info). diff --git a/index.mdwn b/index.mdwn deleted file mode 100644 index be9f6d0..0000000 --- a/index.mdwn +++ /dev/null @@ -1,200 +0,0 @@ -# The protocol - -The **Resource Sharing Protocol** (RSP) is a set of metadata intended to help free software groups and was **replaced in favour of** [ISO 1312](https://iso1312.fluxo.info). - -* Share their available resources and also -* Find groups that can host services for them given their needs and requirements. - -The RSP splits each resource in a layer or set of service layers. You can think of service layers something very general, ranging from servers, databases, websites. If you need to, you can even consider stuff such as tables and bicycles as layers that provide some kind of service to a hosted group. ;) - -The core protocol is composed by the following metadata: - -* Version: RSP version. -* Date: when this metadata was generated. -* Next audit: time where metadata update will happen (if applicable). -* Layer type. -* Layer name (if applicable). -* Layer implementation (eg. if virtual zone: distro name, version, etc). -* Available disk space. -* Available memory. -* Available CPU. -* UPS capacity/characteristics. -* Average downtime. -* Timezone. -* Available system capabilities. -* Networking - * Available bandwidth. - * Real IP availability. - * Proxy availability. - * Firewall/routing availability. - * VPN availability. -* Who admins/updates the layer: - * The hosting group? - * The hosted group? -* Security: - * Security and privacy policy for the layer. - * Crypto - * Implementation. - * Cipher. - * Used procedure. - * Shared password? Which sharing scheme? - * Boot procedure: - * The host has automatic boot loading. - * No boot loading in the host, manual boot. -* Backups - * Backup availability - * No backups. - * Local backups. - * Remote backups in more than a single place but in the same building/jurisdiction/etc. - * Remote backups in more than a single place and also in other countries. - * Backup security - * Have unencrypted backups. - * Have encrypted backups only. - * Have encrypted backups only with a key that needs more than one sysadmin to unlock. - * Have encrypted backups only with a key that the sysadmins do not have access to. - * Backup integrity - * No integrity checking. - * Signed backups only. - * Push and signed backups. - * Pull and signed backups only. - * Backup and users - * Users are informed whether their private data are being backed up and in which ways. - * Have backup data always available to private download by users and/or groups with admin aid. - * Have backup data always available to private download by users and/or groups without admin aid. - * Users and/or groups can choose to not have backups of their data. -* Legal - * Applicable law where layer is located. - * Hosting group has legal team/support? - * Available copyright licenses allowed in the layer. -* Financial - -# Packages - -Even if the metadata supports different configurations, it can be unsuitable to use all set for each application or layer specificiation, especially if you're dealing with multiple layers, one atop of another. Then, it is possible to have a more generic list of prerequisite information, along the lines of a debian package. these are the debian headings: - - Package: - State: - Automatically installed: - Version: - Priority: - Section: - Maintainer: - Uncompressed Size: - Depends: - Suggests: - Conflicts: - Replaces: - Provides: - Description: - -So possible descriptions for a layer could be something like: - - Package: [generic name/category]{server-vserver} - State: [hardware, software, network, labor, physical item]{hardware} - Reusable: [limited availability or recurring possibility?]{continuing} - Version: [specific 'local' name]{project_name_1.0} - Priority: [required/important/standard/optional/extra]{required} - Section: [admin/backups/mirrors/doc/comms]{admin} - Maintainer: [host/user]{host} - Size: [amount or n/a]{10GB} - Depends: - Suggests: network-traffic (=project_name_*), encryption-policy (=project_name_*), - reciprocation-policy (>=1.2) - Conflicts: server-*, - Replaces: vserver - Provides: vserver, server-encryption - Description: encrypted vserver - This package provides a 10 GB vserver hosted on an - individually encrypted single partition. Root administrative - access is provided via ssh using key-based authentication, in - line with standard encryption policy. Bandwidth can be added - by using the network-bw_project_name_* packages. - -Where - - key: [text in square brackets] = comment or possible options - {text in squiggly brackets} = example - -This way, RSP metadata is encapsulated in resource packages that can be announced, distributed or kept for internal use, alowing a given resource to have it's own dependency set and property inheritance. - -# Rulesets - -It is not strict builtin in the protocol but your group can also adopt internal rules regarding what goes at each layer. As an example, a group can adopt a data persistence rule such as data in a layer with a given level of security cannot be moved to a layer with a lower security level, except in cases it is temporarily or permanently declassified. - -# Implementation - -The RSP implementation does not come directly from the protocol. It can be implemented several ways, like keeping tables or wiki pages with detailed information about each layer a given group (or groups) have, can offer or needs. You could even consider to write a script to keep this data updated, although this can be very difficult. One of the best ways to keep the metadata updated is through periodical audits in each layer. - -RSP is meant to be simple enough to be both human and machine readable. So, when considering an implementation, think about those two main types of readability. - -# Applications - -* Ask for resources. -* Resource announcement: - * Offer a resource. - * Ask others to copy a resource. -* Check if a resource exist (ping a website, etc). - -# Metadata examples - -A Linux-VServer instance could hold the following metadata values: - -* Version: 01. -* Date: 20090409. -* Next audit: 20090820. -* Layer type: Linux VServer. -* Layer name: layer.example.org. -* Layer implementation: Debian 5.0. -* Available disk space: 20GB. -* Available memory: 500MB. -* ... - -Another example could be a database: - -* Version: 01. -* Date: 20090409. -* Next audit: 20090820. -* Layer type: SQL. -* Layer name: dbname@layer.example.org. -* Layer implementation: MySQL 5.1. -* ... - -# Version - -This is RSP Version: 0.1. - -# Development - -RSP development and maintenance ins't a hard task: it's just a matter of: - -* Keep a backward-compatible list of metadata. -* Try to fit all needs into the set. -* KISS. - -# Analysis - -See [[analysis|analisys]]. - -# License - -RSP is distributed under the [GNU Affero General Public License](http://www.gnu.org/licenses/agpl-3.0.html): - - Resource Sharing Protocol - RSP - Copyright (C) 2009 RSP Development Team - - This program is free software: you can redistribute it and/or modify - it under the terms of the GNU Affero General Public License as - published by the Free Software Foundation, either version 3 of the - License, or any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU Affero General Public License for more details. - - You should have received a copy of the GNU Affero General Public License - along with this program. If not, see . - ----- - -This wiki is powered by [ikiwiki](http://ikiwiki.info). -- cgit v1.2.3