Section 5 (#9)

* initial toc

* fixed index for readthedocs

* added mkdocs for forcing the toc structure

* fixed indentation

* fixed node operation error in mkdocs compilation

* restructured the repository

* fixed linter issues

* fixing few linting issues and applying comments

* include section 1

* add content for section-2

* content for section 4

* content for section 5

* Fixes based on PR Feedback

* Fixes for travis

* Fixes for travis

* Fixes for travis

* Intro to 5

* Fixes based on pull request feedback

docs/4.operation/8.backlog.md

@@ -0,0 +1,41 @@
+## Backlog
+
+The backlog management web site is a tool implemented with the purpose
+to provide easy understanding of the activity recorded on the trackers.
+Access to FIWARE Backlog Management Web Site at
+[*http://backlog.fiware.org*](http://backlog.fiware.org)
+
+![FIWARE Backlog tool.](image12.png)
+
+At FIWARE we are looking to be sensitive to several sources demanding
+both reactive and proactive working modes. Therefore, the Backlog
+Management web site has been arranged accordingly.
+
+![FIWARE Backlog, urgent desk management](image13.png)
+
+Important thing in the Backlog tool is the Urgent Desk and Help Desk
+option in the menu. The Urgent Desk is an important tool since it allows
+to create common awareness on issues with time-sensitive fields such as
+issues’ deadlines, priorities and status. To meet this objective, it
+collects all items in the trackers with relevant deadlines, priorities
+and status to display them in the desk. Additionally, the Help Desk is
+also a key tool in supporting the end users. It is implemented by adding
+email lists connected to JIRA. The Backlog Web Site also helps by
+providing meaningful views for the different channels and actors.
+
+![FIWARE Backlog, Help-Desk evolution.](image14.png)
+
+Last but not least, each channel has its corresponding view in the
+tracker and backlog web site. Two key channels from the technical point
+of view are:
+
+-   fiware-lab-help help desk view of the channel devoted to incoming
+    issues to be solved in FIWARE Lab.
+
+-   fiware-tech-help help desk view of the channel devoted to incoming
+    issues to be solved in Generic Enabler Implementations.
+
+Both channels are analysed every day by the L1 HELP-Desk support team in
+order to assign correctly the tickets that we receive to the owners and
+resolve it in time in order to complete the requirements of the FIWARE
+Lab node SLA levels.

docs/5.management/1.introduction.md

@@ -0,0 +1,8 @@
+# Management operations on a FIWARE Lab node
+
+In this section, we include the different management operations that
+are needed in order to work with the FIWARE Lab node. These operations
+include the management of new FIWARE Lab accounts, the procedure to
+create base images taking into account the security recommendations and
+the management of the Help Desk tickets associated to the different FIWARE
+Lab nodes.

docs/5.management/2.account.md

@@ -0,0 +1,214 @@
+# Management operations on a FIWARE Lab node
+
+In this section, we include the different management operations that
+are needed in order to work with the FIWARE Lab node. These operations
+include the management of new FIWARE Lab accounts, the procedure to
+create base images taking into account the security recommendations and
+the management of the Help Desk tickets associated to the different FIWARE
+Lab nodes.
+
+## Account Management
+
+This section contains the different actions to manage a user account.
+The most important issue relating to customer accounts is the process to
+upgrade from a FIWARE Trial Account to a FIWARE Community Account, what
+are their available resources, how can they apply and what every FIWARE Lab node
+administrator have to do to proceed with it.
+
+### Request for Community Account Upgrade
+
+To request an account upgrade, FIWARE Lab users need to request it through the
+filling in of an Upgrade Account form available in the
+[FIWARE Lab cloud portal](https://cloud.lab.fiware.org).
+
+-   *Who can apply?*
+
+    Individuals and Companies willing to develop innovative applications
+    based on FIWARE, and to disclose the usage of FIWARE they will make.
+
+-   *How much does it cost*?
+
+    It's free! We are enacting this requirement to ensure that start-ups
+    and SMEs willing to develop applications and demonstrators using
+    FIWARE have the access to the proper resources.
+
+-   *How long do I retain the Community Status*?
+
+    The typical duration for the community status is 9 months. We believe
+    this is enough to allow teams the development of a complete solution based
+    on FIWARE. If it is needed, accounts can be extended. Send a request to
+    [fiware-lab-help@lists.fiware.org](mailto:fiware-lab-help@lists.fiware.org)
+    in order to request an extension of your account with the justification of
+    this extension.
+
+-   *How can I request a Community Account upgrade?*
+
+    Users can apply through the [FIWARE Lab cloud page](https://cloud.lab.fiware.org/)
+    clicking on the “Request Community Account” button.
+
+-   *How long should it take to complete the procedure?*
+
+    The support team is available 9 am to 5 pm during working days. Except
+    for complex request where negotiation of resources is required, a
+    request should be fulfilled in 1 working day.
+
+### Quotas and Flavours
+
+#### What is a Flavour and what are the available flavours?
+
+Flavours represents the size of virtual machines. FIWARE Lab flavours
+are based on OpenStack flavours. Available flavours in the FIWARE Lab
+are listed in this table.
+
+| **ID** | **Flavour** | **Memory** | **Disk** | **Virtual CPUs** |
+| --- | --- | --- | --- | --- |
+| 1 | m1.tiny | 512 | 1 | 1 |
+| 2 | m1.small | 2048 | 20 | 1 |
+| 3 | m1.medium | 4096 | 40 | 2 |
+| 4 | m1.large | 8192 | 80 | 4 |
+
+Keep in mind that it is only a recommendation to optimize the physical
+resources available in a node. Each of the FIWARE Lab administrators is
+free to create new flavours or change resources assigned to users but in
+that case, they could break the homogeneity between different FIWARE Lab
+nodes and could be difficult (if not impossible in some cases) to make a
+migration from one node to another.
+
+#### What are the default quotas?
+
+By default, each user has assigned a minimum number of resources that
+can be used in the development of its solution. This quota is comprised
+of the following values:
+
+| **VM Instances** | **vCPUs** | **Hard Disk** | **Memory** | **Public IPs** |    **Routers** | **Networks** |
+| --- | --- | --- | --- | --- | --- | --- |
+| 2 | 2 | 40 Gb | 4096 Mb | 1 | 0 | 0 |
+
+#### What are the default maximum quotas?
+
+If the project required more resources, the users have the possibility
+to explain it and the default quotas can be extended to a maximum
+default quotas that is comprised of the following values:
+
+| **VM Instances** | **vCPUs** | **Hard Disk** | **Memory** | **Public IPs** |    **Routers** | **Networks** |
+| --- | --- | --- | --- | --- | --- | --- |
+| 5  | 10 | 100 Gb | 10240 Mb | 1 | 1 | 1 |
+
+Keep in mind that in order that users can obtain more resources, it is
+mandatory that they provide the corresponding justification why they
+need more resources. Exceptionally, if users need more resources, after
+a clear justification the FIWARE Lab nodes can provide extra resources
+to cover them.
+
+### Resource assignment and account upgrade by FIWARE Lab administrators
+
+This section describes how FIWARE Lab Node operators should process
+incoming requests. The process is simple and depicted below.
+
+![Account upgrade workflow](image15.png)
+
+The FIWARE Lab administrators start processing the account
+upgrade when they receive the corresponding ticket. Each
+comment will be notified to the end-user that will be able
+to provide you further information in this way. For resource
+assignment/negotiation the guide in Section [Quotas and Flavours](#Quotas_and_Flavours)
+will be considered.
+
+If your FIWARE Lab node is not able to complete the assignment,
+we suggest that FIWARE Lab administrators makes a negotiation
+with other FIWARE Lab nodes in order to transfer the request and
+assign the resources in any other FIWARE Lab node. Of course,
+you should inform users about this migration assignment to confirm
+that it is ok for them.
+
+#### How to assign resources to a new community user
+
+To manage user information, you have to use the Horizon-based Cloud
+Portal interface at
+[*https://cloud.lab.fiware.org*](https://cloud.lab.fiware.org). In this
+web site, you can to click on the button *Request Community Account* and
+you will see a google form requesting the information required to set up
+a community account. Once the user has filled in all the information and
+submitted it, the process will start with the creation of the
+corresponding Jira ticket. The next steps that every FIWARE Lab administrator
+has to follow are the following:
+
+1.  Start progressing the ticket as soon as you receive it.
+
+2.  Check the requested resources and comment to inform the user about
+decision on resources, or additional information you need.
+
+3.  If the user is not created you have to create it.
+
+4.  If the user has not been granted access to any of the projects to
+create cloud resources, you have to create it and assign the user as a member
+of the project.
+
+5.  Assign the role *Community* in the domain *default* to the user. The
+user can have several roles for different projects (owner, member,
+...), however, it is a Community or a Trial user for the
+whole domain.
+
+6.  Include in the metadata of the user (*description* field) the date
+in which the user has been upgraded to Community (with the format
+`"community_started_at": "YYYY-MM-DD"`) and the duration of this community
+account expressed in days (with the format `"community_duration": "DD"`).
+
+7.  Assign the desired quotas in your FIWARE Lab node to the user.
+
+8.  Assign the endpoint group of your FIWARE Lab node to the user’s project.
+
+9.  If you need to contact the user you can use the email address
+included in the user detail.
+
+10. Progress to “done” when completed.
+
+11. Alternatively, if any impediment arises, move to impeded, and inform
+the user by commenting the ticket.
+
+### Procedure to create new FIWARE Lab user account
+
+The process to create a new FIWARE Lab user account, includes a
+procedure to check that the email introduced is a valid email. During
+this process, FIWARE requests several information to the user to be filled in a
+google form. This information includes:
+
+-   User name to be kept in the database.
+
+-   User email to communicate any issue directly to the user.
+
+-   Preferred FIWARE Lab node to be used.
+
+-   Acceptance of the FIWARE Lab Terms & Conditions.
+
+![FIWARE Lab user creation form](image16.png)
+
+All these data are mandatory to be fulfilled. This form activates a
+specific procedure to manage the creation of the FIWARE Lab user
+account.
+
+![FIWARE Lab user creation workflow](image17.png)
+
+Once that the user submits this information an email will automatically
+be sent to the user using the email provided. This email includes in the
+subject (Betreff in German in the following picture) the confirmation
+code to be submitted. The user must reply to this email in order to
+confirm that the email is correct.
+
+![FIWARE Lab user creation, confirmation email template.](image18.png)
+
+During this procedure, the reception of the confirmation email is mandatory in
+order to create the new user account.
+to create a new user. This confirmation is obtained through the response
+of this received email leaving intact the email's subject. The received response
+email, with the subject intact, is enough to validate the user's email and
+activate the JIRA ticket creation with the corresponding FIWARE Lab
+node administrator in order to create the corresponding user account.
+After the creation, the FIWARE Lab node administrator informs the users
+that the new account has been created and the recommendation to change
+the password by themselves.
+
+The information of the user created (and eventually deleted) will be
+kept under Data Protection control for statistical purposes and
+evaluation of the creation and deletion of user accounts in the FIWARE
+Lab ecosystem.

docs/5.management/3.base-image.md

@@ -0,0 +1,53 @@
+## Base-images Management
+
+The creation of base images is a very important operation mainly due the
+security updates and configuration of them. For this purpose, we download the
+official images of the different operating systems supported in the FIWARE Lab.
+There are the three options that we can manage:
+
+-   CentOS 6 and 7,
+
+-   Ubuntu 14.04, 16.04, and 18.04 (LTS releases), and
+
+-   Debian 7 and 8.
+
+However, we modify these images in order to make the default image a little more
+secure by doing some operations on them. For this purpose, we follow the
+recommendations of the Centre for Internet Security
+([*CIS*](https://www.cisecurity.org/)).
+CIS is a forward-thinking, non-profit entity that harnesses the power of a
+global IT community to safeguard private and public organizations against cyber
+threats. CIS Benchmarks is the global standard and recognized best
+practices for securing IT systems and data against the most pervasive
+attacks. It provides a very exhaustive guideline, continuously refined
+and verified, to configure Operating System in a secure way. The
+recommendations, that we adopt in the configuration of the virtual
+machines, are the following:
+
+-   We remove the default password for the default user. Additionally,
+    the only valid method to login on the operating system is through
+    public-private key.
+
+-   Root user is disabled to be used to access to the Instance
+    through SSH.
+
+-   We remove the less secure ciphers from the list of available valid ciphers
+    and the less secure key exchange methods.
+
+-   We add a warning banner explaining that an authorization is needed
+    to access them.
+
+-   We add some IPTables rules to ensure that by default, only some
+    ports (ssh, http and https can be used).
+
+-   By default, we enable only automatic security updates.
+
+-   The administrative access to the operating system is allowed only using a
+    specific user with both password and public-private key. Every FIWARE Lab
+    node has assigned the corresponding administrator who contact us to provide
+    details about this public-private key access.
+
+All the FIWARE GEs, that are deployed using these base images,
+inherit these security configuration options. Sometimes, under the
+requirements of the FIWARE GEs owners, we need to modify IPTables rules
+in order to allow the use of some other ports.

docs/index.md

@@ -32,3 +32,6 @@ and connect it to the FIWARE Lab.
     - [Rancher](4.operation/5.rancher.md)
     - [Mastermind](4.operation/6.mastermind.md)
     - [JIRA](4.operation/7.jira.md)
+1. [Management operations on a FIWARE Lab node](5.management/1.introduction.md)
+    - [Account](5.management/2.account.md)
+    - [Base Image](5.management/3.base-image.md)

mkdocs.yml

@@ -34,6 +34,10 @@ pages:
       - 'Rancher': '4.operation/5.rancher.md'
       - 'Mastermind': '4.operation/6.mastermind.md'
       - 'JIRA': '4.operation/7.jira.md'
+    - 'Management operations on a FIWARE Lab node':
+      - 'Introduction': '5.management/1.introduction.md'
+      - 'Account': '5.management/2.account.md'
+      - 'Base Image': '5.management/3.base-image.md'
 
 markdown_extensions: [toc,fenced_code]
 extra_css: ["https://fiware.org/style/fiware_readthedocs.css"]