Nasqueron Agora - User contributions [en]

Operations grimoire

2017-01-15T08:09:20Z

2001:470:1F13:D91:818A:558B:64C0:D7B7: /* Appendices */ alphabetic order ; + /External services

Welcome to the Nasqueron operations grimoire (NOG).

== Infrastructure ==
* [[/Docker engine]]

== Services ==
=== Identity management ===
* [[/Login]] (Auth Grove)

=== Collaborative tools ===
* [[/Dæghrefn]] (eggdrop)
* [[/DevCentral]] (Phabricator)
* [[/Etherpad]]
* [[/Mumble]]

=== CI/CD ===
* [[/Broker]]
* [[/Jenkins]]
* [[/Notifications center]]
* [[/Vault]]

== Other web sites ==
* [[/Sites on Eglide]]
* [[/Sites on Ysul]]
== Services configuration ==
''This section contains general information not related to a specific service.''
* [[/SSL certificates]] (Let's encrypt / letsencrypt)

== Checklists ==
=== Docker ===
* [[/Restart a Docker engine]]
* [[/Dwellers to DevCentral]]
* [[/Git operations in production containers]]

=== Salt ===
* [[/Deploy with Salt]]
* [[/Create and revoke user accounts on Salt servers]]

== Appendices ==
* [[/Contacts]]
* [[/Evaluated products]]
* [[/External services]]
* [[/Policies]]

[[Category:Reference]]

Operations grimoire

2017-01-15T07:16:47Z

2001:470:1F13:D91:818A:558B:64C0:D7B7: /* Appendices */ +/Evaluated products

Welcome to the Nasqueron operations grimoire (NOG).

== Infrastructure ==
* [[/Docker engine]]

== Services ==
=== Identity management ===
* [[/Login]] (Auth Grove)

=== Collaborative tools ===
* [[/Dæghrefn]] (eggdrop)
* [[/DevCentral]] (Phabricator)
* [[/Etherpad]]
* [[/Mumble]]

=== CI/CD ===
* [[/Broker]]
* [[/Jenkins]]
* [[/Notifications center]]
* [[/Vault]]

== Other web sites ==
* [[/Sites on Eglide]]
* [[/Sites on Ysul]]
== Services configuration ==
''This section contains general information not related to a specific service.''
* [[/SSL certificates]] (Let's encrypt / letsencrypt)

== Checklists ==
=== Docker ===
* [[/Restart a Docker engine]]
* [[/Dwellers to DevCentral]]
* [[/Git operations in production containers]]

=== Salt ===
* [[/Deploy with Salt]]
* [[/Create and revoke user accounts on Salt servers]]

== Appendices ==
* [[/Policies]]
* [[/Contacts]]
* [[/Evaluated products]]

[[Category:Reference]]

Ysul

2016-12-24T12:50:19Z

2001:470:1F13:D91:1961:6B57:682:8423: /* Services */

'''Ysul''' is an FreeBSD 10 server instance installed on [[Stormshear]].

== Basic information ==
* '''IP:'''
** 212.83.187.132
** DN42 still to configure
** 2001:470:1f13:9e1:0:c0ff:ee:1 (Hurricane Electric)
** 177.27.26.33 (Drake)
* '''Hostname:''' ysul.nasqueron.org
* '''Homepage:''' http://ysul.nasqueron.org/
* '''Configuration:'''Should have access to 3.5 GB RAM and 4 core, burstable on request to 8 cores/+-6 Gb (to be negotiated according [[Dwellers]] use). Currently 2.5 GB / 1 core.
* '''OS:''' FreeBSD 10
* '''ISP:''' [http://www.online.net Online] (FR)
* '''Network:''' Illiad (FR)
* '''Status:''' Installing.
* '''Policy:''' Access for any Nasqueron or Wolfplex project, access for general public seeking a development purpose shell account or a staging environment.
* '''Started:''' 2014-07-06

== Services ==
* SSH (*:22)
* Nginx (*:80), see [[Operations grimoire/Sites on Ysul]]
* Mumble (*:64738)

=== Ports table ===

The table doesn't include dgram and streams (e.g. socket files).

If you start a new service or want to make reservations for a port or a port range for occasional services (e.g. a range of ports for DCC transfers on a IRC bot or client), indicate them here.

If you wish to check the table is accurate, <code>sockstat | grep "*:"</code> could be helpful.

{| class="wikitable"
! '''Service'''
! '''Application'''
! '''Port'''
! '''Listening to'''
! '''Notes'''
|-
|SSH||sshd||22||world||
|-
|DNS||unbound||53||localhost||A distinct world DNS server will be soon installed (through djbdns?)
|-
|rowspan=1|Web
|rowspan=1|nginx
||80||world||Currently IPv4 only
|-
|Identd||oidentd||113||world||
|-
|Logging||syslogd||514||world||
|-
|MySQL||mysqld||3306||world||MariaDB 5.5
|-
|rowspan=2|Mumble
|rowspan=2|murmurd
|64738||world||
|-
|6502||localhost||ZeroC Ice socket
|}

== Decentralized networks peers ==
{| class="wikitable"
!rowspan=2|Interface
!rowspan=2|Peer name
!colspan=2|Pipeline network
!colspan=3|Decentralized network
!rowspan=2|Remote contact
!rowspan=2|Notes
|-
! Local IP
! Remote IP
! Network
! Local IP
! Remote IP
|-
|gre0||Ubald||212.83.187.33||213.189.173.103||[[Drake]]||172.27.26.33||172.27.26.30||Dereckson||Remote IP is dynamic
|-
|gre1||Dwellers||212.83.187.33||212.129.32.223||[[Drake]]||172.27.26.33||172.27.26.49||Dereckson
|-
|}

[[Category:Ysul]]

How to contribute code

2016-11-12T02:40:11Z

2001:470:1F13:D91:80E6:B029:8213:E8A1: /* Accept a revision */

This guide explains how to contribute code to a Nasqueron project.

We use Phabricator for tasks and code reviews, our instance is called DevCentral and is accessible at {{PhabricatorInstance}}.

In a nutshell, to submit a change, you need to clone the relevant repository, create a new branch, commit and send this commit to our code review server. Pull requests on GitHub could be fine for trivial hit and run patches, but if you add a new feature, use our code review server.

== Clone the repository ==
On DevCentral, go to [{{PhabricatorInstance}}/diffusion/ Diffusion]. Each repository will offer you a clone command.

For example, it could be:
git clone ssh://git@github.com/nasqueron/someproject

Internal projects are directly hosted on DevCentral. In this case, you need to [{{PhabricatorInstance}}/settings/panel/ssh/ add your SSH key to the settings].

If the repository is on GitHub but not on DevCentral, please request it to be added. For that, create a task on DevCentral and add DevCentral as project You can use the priority Unbreak now! if you already have a change to review, high if you plan to do it in the next 12 hours, normal for 24 hours, low for one week.

== Code something ==
<div style="display: table; margin: 1em; padding: 0.5em 1.5em; border: 4px solid #aaa; background-color: #f9f9f9;">
'''Never work in Git master branch''', when you are submitting new code.

Always create a new branch for each change, code feature or bug fix.

The master branch is only to merge changes, not to work.

Trust us, you want to code and have fun, not to spend an evening to fix your Git repositories merging infinite conflicts.

'''Remember: One new change, one new branch.'''
</div>

To fix a bug, or code a new feature, three operations are needed:
# code it
# commit it
# review it

=== Code it ===

Before to start to code, create a new branch:

git checkout -b feature/something-awesome

If you fix a bug, use the number of the bug on DevCentral:

git checkout -b bug/T434

Then code something, test it, reread it.

=== Commit it ===

When you're ready, you can commit it.

Your commit message should use the following format:

* a title, as short as possible, with 43 max characters recommended, 55 characters as soft limit, 72 as hard limit
* some paragraphs, but wrap lines < 72 characters. You can extend at 80 (soft limit) or 100 (hard limit) if really needed.

The title should be at imperative, not followed by a final dot.

The paragraphs should focus to explain why this change is needed.

See http://chris.beams.io/posts/git-commit/ for more best practices.

=== Review it ===
arc diff

This will send your change on DevCentral, and allow the review process to start.

When you use `arc diff`, Arcanist will try to guess what change you want to offer. If you've committed in a branch, it will guess correctly you want to submit the diff between master and this branch (your commit).

You'll find more information about this on [https://secure.phabricator.com/book/phabricator/article/arcanist_diff/ the Phabricator documentation].

Once reviewed, your change will be live in the master repository. Cheers!

=== Edit a change ===

To edit the change, amend the relevant commit.

git checkout <the relevant branch>
[change something]
git add <the files modified>
git commit --amend
arc diff

If arc complain, try:

arc diff --update <differential id without D prefix>

You can also use the web interface: Differential allows you to submit a patch to amend your change.

In this case, you edit the files, run `git diff` and copy/paste the result on Phabricator.

=== You can now go on to code ===

Meanwhile review, you can go to another branch and go on to work.

If this change is independent, your new branch must start at master, not at your previous branch:

git checkout master
git checkout -b feature/another-awesome-change

But when your change depends of the previous one, you create a new branch from the last:
git checkout -b feature/the-next-change

Then again, code, commit, and send to review with arc diff.

== Review code ==

=== Where are reviews and what can I do there? ===

Reviews are accessible at [{{PhabricatorInstance}}/differential Differential].

In the bottom of a revision page, you'll find a action menu to accept a revision or request changes.

You can also comment inline, clicking on line numbers.

Everyone can offer comment.

=== Accept a revision ===
<div style="display: table; margin: 1em; padding: 0.5em 1.5em; border: 4px solid #aaa; background-color: #f9f9f9;">
'''Don't self review''', ie don't accept your own revisions.

Consider to '''land accepted revisions immediately'''.
</div>

Note: for Salt, that works slightly differently: a test deployment is required before landing, and self review is allowed when a member of the team is alone, and the matter trivial or urgent.

==== What does that mean? ====

An accepted revision is a revision ready to be integrated into the code base (the goal of the CI process), and so to be sent to production environment.

Some projects trigger automatically a new deployment step after a commit has been integrated, for example the Docker images are all configured to rebuild a new image from the latest tag. Websites like https://docker.nasqueron.org/ or https://assets.nasqueron.org/ are also automatically updated.

By accepting a revision, you express your confidence it's ready and sounds safe to deploy.

Does your project have special guidelines for code review?
* If so, follow them.
* If not, any member considering themself a member of the project can accept any revision from another project member.

Next step is to land the accepted revision. This currently requires <code>arc land</code>, but we're working to allow to land from the web UI.

==== Merge the revision to master ====
In Phabricator language, that's called ''land the revision''.

# Use a clean and up-to-date master: <code>git fetch && git checkout master && git reset --hard origin/master</code>
# Get the patch: <code>arc patch D300</code>
# Merge the patch to master: <code>arc land</code>

The differential UI gives the next step in the header.

==== After the merge ====

Stay reachable and watch the post commit actions (e.g. does the Docker image has been successfully built on Docker Hub?). Be ready to use <code>git revert</code> to revert the change if something is wrong.

=== When can I self review? ===

Self review is frowned upon, but in two cases it could be needed:
* when there is an emergency, for example to fix a security issue, when no one in duty can be found;
* when you're alone on your project, and can't find someone to review.

=== How to revert a change? ===

A change revert is a commit:
* you can automatically create by <code>git revert <commit-ish></code>
* you craft manually, like any other change

Then, you follow the exact same instructions you would for a regular change: send to the code review, review it, land it.

The revision should be accepted by:
* the original commit author if present at deployment time
* someone you work with to solve currently the issue if the author isn't there
* yourself if you're alone

The review should contain a comment about what is broken in the reverted commit, excepted if there is already such information in Audit or Differential.

== Useful links ==
* http://www.unixwiz.net/techtips/ssh-agent-forwarding.html

[[Category:Reference]]

How to contribute code

2016-11-12T02:39:27Z

2001:470:1F13:D91:80E6:B029:8213:E8A1: /* Accept a revision */

This guide explains how to contribute code to a Nasqueron project.

We use Phabricator for tasks and code reviews, our instance is called DevCentral and is accessible at {{PhabricatorInstance}}.

In a nutshell, to submit a change, you need to clone the relevant repository, create a new branch, commit and send this commit to our code review server. Pull requests on GitHub could be fine for trivial hit and run patches, but if you add a new feature, use our code review server.

== Clone the repository ==
On DevCentral, go to [{{PhabricatorInstance}}/diffusion/ Diffusion]. Each repository will offer you a clone command.

For example, it could be:
git clone ssh://git@github.com/nasqueron/someproject

Internal projects are directly hosted on DevCentral. In this case, you need to [{{PhabricatorInstance}}/settings/panel/ssh/ add your SSH key to the settings].

If the repository is on GitHub but not on DevCentral, please request it to be added. For that, create a task on DevCentral and add DevCentral as project You can use the priority Unbreak now! if you already have a change to review, high if you plan to do it in the next 12 hours, normal for 24 hours, low for one week.

== Code something ==
<div style="display: table; margin: 1em; padding: 0.5em 1.5em; border: 4px solid #aaa; background-color: #f9f9f9;">
'''Never work in Git master branch''', when you are submitting new code.

Always create a new branch for each change, code feature or bug fix.

The master branch is only to merge changes, not to work.

Trust us, you want to code and have fun, not to spend an evening to fix your Git repositories merging infinite conflicts.

'''Remember: One new change, one new branch.'''
</div>

To fix a bug, or code a new feature, three operations are needed:
# code it
# commit it
# review it

=== Code it ===

Before to start to code, create a new branch:

git checkout -b feature/something-awesome

If you fix a bug, use the number of the bug on DevCentral:

git checkout -b bug/T434

Then code something, test it, reread it.

=== Commit it ===

When you're ready, you can commit it.

Your commit message should use the following format:

* a title, as short as possible, with 43 max characters recommended, 55 characters as soft limit, 72 as hard limit
* some paragraphs, but wrap lines < 72 characters. You can extend at 80 (soft limit) or 100 (hard limit) if really needed.

The title should be at imperative, not followed by a final dot.

The paragraphs should focus to explain why this change is needed.

See http://chris.beams.io/posts/git-commit/ for more best practices.

=== Review it ===
arc diff

This will send your change on DevCentral, and allow the review process to start.

When you use `arc diff`, Arcanist will try to guess what change you want to offer. If you've committed in a branch, it will guess correctly you want to submit the diff between master and this branch (your commit).

You'll find more information about this on [https://secure.phabricator.com/book/phabricator/article/arcanist_diff/ the Phabricator documentation].

Once reviewed, your change will be live in the master repository. Cheers!

=== Edit a change ===

To edit the change, amend the relevant commit.

git checkout <the relevant branch>
[change something]
git add <the files modified>
git commit --amend
arc diff

If arc complain, try:

arc diff --update <differential id without D prefix>

You can also use the web interface: Differential allows you to submit a patch to amend your change.

In this case, you edit the files, run `git diff` and copy/paste the result on Phabricator.

=== You can now go on to code ===

Meanwhile review, you can go to another branch and go on to work.

If this change is independent, your new branch must start at master, not at your previous branch:

git checkout master
git checkout -b feature/another-awesome-change

But when your change depends of the previous one, you create a new branch from the last:
git checkout -b feature/the-next-change

Then again, code, commit, and send to review with arc diff.

== Review code ==

=== Where are reviews and what can I do there? ===

Reviews are accessible at [{{PhabricatorInstance}}/differential Differential].

In the bottom of a revision page, you'll find a action menu to accept a revision or request changes.

You can also comment inline, clicking on line numbers.

Everyone can offer comment.

=== Accept a revision ===
<div style="display: table; margin: 1em; padding: 0.5em 1.5em; border: 4px solid #aaa; background-color: #f9f9f9;">
'''Don't self review''', ie don't accept your own revisions.

Consider to '''land accepted revisions immediately'''.
</div>

Note: the operations repository work slightly differently: a tesqt deployment is required before landing, self review allowed when a member of the team is alone, and the matter trivial or urgent.

==== What does that mean? ====

An accepted revision is a revision ready to be integrated into the code base (the goal of the CI process), and so to be sent to production environment.

Some projects trigger automatically a new deployment step after a commit has been integrated, for example the Docker images are all configured to rebuild a new image from the latest tag. Websites like https://docker.nasqueron.org/ or https://assets.nasqueron.org/ are also automatically updated.

By accepting a revision, you express your confidence it's ready and sounds safe to deploy.

Does your project have special guidelines for code review?
* If so, follow them.
* If not, any member considering themself a member of the project can accept any revision from another project member.

Next step is to land the accepted revision. This currently requires <code>arc land</code>, but we're working to allow to land from the web UI.

==== Merge the revision to master ====
In Phabricator language, that's called ''land the revision''.

# Use a clean and up-to-date master: <code>git fetch && git checkout master && git reset --hard origin/master</code>
# Get the patch: <code>arc patch D300</code>
# Merge the patch to master: <code>arc land</code>

The differential UI gives the next step in the header.

==== After the merge ====

Stay reachable and watch the post commit actions (e.g. does the Docker image has been successfully built on Docker Hub?). Be ready to use <code>git revert</code> to revert the change if something is wrong.

=== When can I self review? ===

Self review is frowned upon, but in two cases it could be needed:
* when there is an emergency, for example to fix a security issue, when no one in duty can be found;
* when you're alone on your project, and can't find someone to review.

=== How to revert a change? ===

A change revert is a commit:
* you can automatically create by <code>git revert <commit-ish></code>
* you craft manually, like any other change

Then, you follow the exact same instructions you would for a regular change: send to the code review, review it, land it.

The revision should be accepted by:
* the original commit author if present at deployment time
* someone you work with to solve currently the issue if the author isn't there
* yourself if you're alone

The review should contain a comment about what is broken in the reverted commit, excepted if there is already such information in Audit or Differential.

== Useful links ==
* http://www.unixwiz.net/techtips/ssh-agent-forwarding.html

[[Category:Reference]]

Operations grimoire/Deploy with Salt

2016-11-07T20:24:39Z

2001:470:1F13:D91:3113:262:4553:BBAF: /* Salt commands */

== Where to work? ==
* We deploy from Ysul using:
** /opt/nasqueron-operations as our local copy of rOPS, authoritative for Salt
** /opt/staging for web application content
* You need to belong to the <code>salt</code> group to be able to control Salt
* You need to belong to the <code>deploy</code> group to be able to update /opt/staging (salt is a member of deploy)
* You want this alias: <code>alias salt sudo -u salt salt</code> (tcsh syntax)
* Check salt-master is run, if not <code>service salt-master start</code>

== Deployment workflow ==
=== Apply a new Salt state ===
# On your laptop, prepare and upload a change to Differential against rOPS repository
# Get the change on Ysul: <code>arc patch D607</code>
# Ask Salt to apply the change
# Log on #nasqueron-operations something like <code>[Eglide] New user account: amj (D607)</code>
# Once working, you can merge it to master
=== Deploy a web site ===
# Commit as needed
# Go to /opt/staging relevant subdirectory and fetch code
# Ask Salt to apply the matching state (if in doubt, a full run is <code>salt '*' state.highstate</code>)

== Salt commands ==
To apply one state or a directory:

<code>salt eglide state.apply roles/shellserver/users</code>

To apply all:

<code>salt eglide state.highstate</code>

Replace <code>eglide</code> by the server name, or <code>*</code> to target all machines.

When you've a new state, ensure it's called from <code>top.sls<code> file, as the repository root.

How to contribute code

2016-10-15T16:07:45Z

2001:470:1F13:D91:D11B:848D:2A93:2B8F: /* Edit a change */

This guide explains how to contribute code to a Nasqueron project.

We use Phabricator for tasks and code reviews, our instance is called DevCentral and is accessible at {{PhabricatorInstance}}.

In a nutshell, to submit a change, you need to clone the relevant repository, create a new branch, commit and send this commit to our code review server. Pull requests on GitHub could be fine for trivial hit and run patches, but if you add a new feature, use our code review server.

== Clone the repository ==
On DevCentral, go to [{{PhabricatorInstance}}/diffusion/ Diffusion]. Each repository will offer you a clone command.

For example, it could be:
git clone ssh://git@github.com/nasqueron/someproject

Internal projects are directly hosted on DevCentral. In this case, you need to [{{PhabricatorInstance}}/settings/panel/ssh/ add your SSH key to the settings].

If the repository is on GitHub but not on DevCentral, please request it to be added. For that, create a task on DevCentral and add DevCentral as project You can use the priority Unbreak now! if you already have a change to review, high if you plan to do it in the next 12 hours, normal for 24 hours, low for one week.

== Code something ==
<div style="display: table; margin: 1em; padding: 0.5em 1.5em; border: 4px solid #aaa; background-color: #f9f9f9;">
'''Never work in Git master branch''', when you are submitting new code.

Always create a new branch for each change, code feature or bug fix.

The master branch is only to merge changes, not to work.

Trust us, you want to code and have fun, not to spend an evening to fix your Git repositories merging infinite conflicts.

'''Remember: One new change, one new branch.'''
</div>

To fix a bug, or code a new feature, three operations are needed:
# code it
# commit it
# review it

=== Code it ===

Before to start to code, create a new branch:

git checkout -b feature/something-awesome

If you fix a bug, use the number of the bug on DevCentral:

git checkout -b bug/T434

Then code something, test it, reread it.

=== Commit it ===

When you're ready, you can commit it.

Your commit message should use the following format:

* a title, as short as possible, with 43 max characters recommended, 55 characters as soft limit, 72 as hard limit
* some paragraphs, but wrap lines < 72 characters. You can extend at 80 (soft limit) or 100 (hard limit) if really needed.

The title should be at imperative, not followed by a final dot.

The paragraphs should focus to explain why this change is needed.

See http://chris.beams.io/posts/git-commit/ for more best practices.

=== Review it ===
arc diff

This will send your change on DevCentral, and allow the review process to start.

When you use `arc diff`, Arcanist will try to guess what change you want to offer. If you've committed in a branch, it will guess correctly you want to submit the diff between master and this branch (your commit).

You'll find more information about this on [https://secure.phabricator.com/book/phabricator/article/arcanist_diff/ the Phabricator documentation].

Once reviewed, your change will be live in the master repository. Cheers!

=== Edit a change ===

To edit the change, amend the relevant commit.

git checkout <the relevant branch>
[change something]
git add <the files modified>
git commit --amend
arc diff

If arc complain, try:

arc diff --update <differential id without D prefix>

You can also use the web interface: Differential allows you to submit a patch to amend your change.

In this case, you edit the files, run `git diff` and copy/paste the result on Phabricator.

=== You can now go on to code ===

Meanwhile review, you can go to another branch and go on to work.

If this change is independent, your new branch must start at master, not at your previous branch:

git checkout master
git checkout -b feature/another-awesome-change

But when your change depends of the previous one, you create a new branch from the last:
git checkout -b feature/the-next-change

Then again, code, commit, and send to review with arc diff.

== Review code ==

=== Where are reviews and what can I do there? ===

Reviews are accessible at [{{PhabricatorInstance}}/differential Differential].

In the bottom of a revision page, you'll find a action menu to accept a revision or request changes.

You can also comment inline, clicking on line numbers.

Everyone can offer comment.

=== Accept a revision ===
<div style="display: table; margin: 1em; padding: 0.5em 1.5em; border: 4px solid #aaa; background-color: #f9f9f9;">
'''Don't self review''', ie don't accept your own revisions.

Consider to '''land accepted revisions immediately'''.
</div>

==== What does that mean? ====

An accepted revision is a revision ready to be integrated into the code base (the goal of the CI process), and so to be sent to production environment.

Some projects trigger automatically a new deployment step after a commit has been integrated, for example the Docker images are all configured to rebuild a new image from the latest tag. Websites like https://docker.nasqueron.org/ or https://assets.nasqueron.org/ are also automatically updated.

By accepting a revision, you express your confidence it's ready and sounds safe to deploy.

Does your project have special guidelines for code review?
* If so, follow them.
* If not, any member considering themself a member of the project can accept any revision from another project member.

Next step is to land the accepted revision. This currently requires <code>arc land</code>, but we're working to allow to land from the web UI.

==== Merge the revision to master ====
In Phabricator language, that's called ''land the revision''.

# Use a clean and up-to-date master: <code>git fetch && git checkout master && git reset --hard origin/master</code>
# Get the patch: <code>arc patch D300</code>
# Merge the patch to master: <code>arc land</code>

The differential UI gives the next step in the header.

==== After the merge ====

Stay reachable and watch the post commit actions (e.g. does the Docker image has been successfully built on Docker Hub?). Be ready to use <code>git revert</code> to revert the change if something is wrong.

=== When can I self review? ===

Self review is frowned upon, but in two cases it could be needed:
* when there is an emergency, for example to fix a security issue, when no one in duty can be found;
* when you're alone on your project, and can't find someone to review.

=== How to revert a change? ===

A change revert is a commit:
* you can automatically create by <code>git revert <commit-ish></code>
* you craft manually, like any other change

Then, you follow the exact same instructions you would for a regular change: send to the code review, review it, land it.

The revision should be accepted by:
* the original commit author if present at deployment time
* someone you work with to solve currently the issue if the author isn't there
* yourself if you're alone

The review should contain a comment about what is broken in the reverted commit, excepted if there is already such information in Audit or Differential.

== Useful links ==
* http://www.unixwiz.net/techtips/ssh-agent-forwarding.html

[[Category:Reference]]

PuTTY with SSH key tutorial

2016-10-08T18:17:15Z

2001:470:1F13:D91:5542:B7B7:D9B5:6E65:

This tutorial shows how to generate a new SSH key, then configure a PuTTY session to use it.

== What's this? ==

To login to the server, instead of a password, you use a key.

This key is divided in two parts:
* the public key, you give freely (you can publish it on your webpage for example) where you need to have an access
* the private key, you keep very safely and privately for you and only you

The public key is more like a login, the privave key more like a password.

== Generate a new SSH key ==
PuTTY ships a software to generate a key, PuTTYGen. You can download it on http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html.

'''Step 1.''' Run it, and you've this screen. Click on the generate button.

[[File:PuTTY_Key_Generator_2.png]]

'''Step 2.''' Move the mouse to generate some randomness. That will be used to generate a random key, a key we can't guess.

[[File:PuTTY_Key_Generator.png]]

'''Step 3.''' Copy/paste the content of first textarea (ssh-rsa ...): this is your public key.

Save safely where you want the key ("Save private key").

If you set a password, the key will be encrypted, and a password asked each time you use the key.

[[File:PuTTY_Key_Generator_3.png]]

== Configure a PuTTY session to log in with a SSH key ==

[[File:Session_Panel_on_PuTTY.png]]

[[File:Data_Panel_on_PuTTY.png]]

[[File:Authentication_Panel_on_PuTTY.png]]

[[File:Session_Panel_on_PuTTY_2.png]]

[[File:Session_Panel_on_PuTTY_3.png]]

PuTTY with SSH key tutorial

2016-10-08T17:51:59Z

2001:470:1F13:D91:5542:B7B7:D9B5:6E65:

This tutorial shows how to generate a new SSH key, then configure a PuTTY session to use it.

== Generate a new SSH key ==
[[File:PuTTY_Key_Generator_2.png]]

[[File:PuTTY_Key_Generator.png]]

[[File:PuTTY_Key_Generator_3.png]]

== Configure a PuTTY session to log in with a SSH key ==

[[File:Session_Panel_on_PuTTY.png]]

[[File:Data_Panel_on_PuTTY.png]]

[[File:Authentication_Panel_on_PuTTY.png]]

[[File:Session_Panel_on_PuTTY_2.png]]

[[File:Session_Panel_on_PuTTY_3.png]]

Operations grimoire/Deploy with Salt

2016-09-12T05:03:05Z

2001:470:1F13:D91:E8A0:AB13:681B:5C9F: /* Deployment workflow */

== Where to work? ==
* We deploy from Ysul using:
** /opt/nasqueron-operations as our local copy of rOPS, authoritative for Salt
** /opt/staging for web application content
* You need to belong to the <code>salt</code> group to be able to control Salt
* You need to belong to the <code>deploy</code> group to be able to update /opt/staging (salt is a member of deploy)
* You want this alias: <code>alias salt sudo -u salt salt</code> (tcsh syntax)
* Check salt-master is run, if not <code>service salt-master start</code>

== Deployment workflow ==
=== Apply a new Salt state ===
# On your laptop, prepare and upload a change to Differential against rOPS repository
# Get the change on Ysul: <code>arc patch D607</code>
# Ask Salt to apply the change
# Log on #nasqueron-operations something like <code>[Eglide] New user account: amj (D607)</code>
# Once working, you can merge it to master
=== Deploy a web site ===
# Commit as needed
# Go to /opt/staging relevant subdirectory and fetch code
# Ask Salt to apply the matching state (if in doubt, a full run is <code>salt '*' state.highstate</code>)

== Salt commands ==
To apply one state or a directory:

<code>salt eglide state.apply roles/shellserver/users</code>

To apply all:

<code>salt eglide state.highstate</code>

Replace <code>eglide<code> by the server name, or <code>*</code> to target all machines.

When you've a new state, ensure it's called from <code>top.sls<code> file, as the repository root.

Operations grimoire/Deploy with Salt

2016-09-12T05:00:27Z

2001:470:1F13:D91:E8A0:AB13:681B:5C9F: /* Deployment workflow */

== Where to work? ==
* We deploy from Ysul using:
** /opt/nasqueron-operations as our local copy of rOPS, authoritative for Salt
** /opt/staging for web application content
* You need to belong to the <code>salt</code> group to be able to control Salt
* You need to belong to the <code>deploy</code> group to be able to update /opt/staging (salt is a member of deploy)
* You want this alias: <code>alias salt sudo -u salt salt</code> (tcsh syntax)
* Check salt-master is run, if not <code>service salt-master start</code>

== Deployment workflow ==
# On your laptop, prepare and upload a change to Differential against rOPS repository
# Get the change on Ysul: <code>arc patch D607</code>
# Ask Salt to apply the change
# Log on #nasqueron-operations something like <code>[Eglide] New user account: amj (D607)</code>
# Once working, you can merge it to master

== Salt commands ==
To apply one state or a directory:

<code>salt eglide state.apply roles/shellserver/users</code>

To apply all:

<code>salt eglide state.highstate</code>

Replace <code>eglide<code> by the server name, or <code>*</code> to target all machines.

When you've a new state, ensure it's called from <code>top.sls<code> file, as the repository root.

Operations grimoire/Deploy with Salt

2016-09-12T05:00:09Z

2001:470:1F13:D91:E8A0:AB13:681B:5C9F: /* Where to work? */

== Where to work? ==
* We deploy from Ysul using:
** /opt/nasqueron-operations as our local copy of rOPS, authoritative for Salt
** /opt/staging for web application content
* You need to belong to the <code>salt</code> group to be able to control Salt
* You need to belong to the <code>deploy</code> group to be able to update /opt/staging (salt is a member of deploy)
* You want this alias: <code>alias salt sudo -u salt salt</code> (tcsh syntax)
* Check salt-master is run, if not <code>service salt-master start</code>

== Deployment workflow ==
# On your laptop, prepare and upload a change to Differential against rOPS repository
# Get the change on Ysul: <code>arc patch D607</code>
# Ask Salt to apply the change
# Log on #nasqueron-operations something like <code>[Eglide] New user account: amj (D607)</code>
# Once working, you can merge it to master

== Salt commands ==
To apply one state or a directory:

<code>salt eglide state.apply roles/shellserver/users</code>

To apply all:

<code>salt eglide state.highstate</code>

Replace <code>eglide<code> by the server name, or <code>*</code> to target all machines.

When you've a new state, ensure it's called from <code>top.sls<code> file, as the repository root.

Operations grimoire/Deploy with Salt

2016-09-12T04:59:29Z

2001:470:1F13:D91:E8A0:AB13:681B:5C9F: /* Where to work? */

== Where to work? ==
* We deploy from Ysul using:
** /opt/nasqueron-operations as our local copy of rOPS, authoritative for Salt
** /opt/stating for web application content
* You need to belong to the <code>salt</code> group
* You want this alias: <code>alias salt sudo -u salt salt</code> (tcsh syntax)
* Check salt-master is run, if not <code>service salt-master start</code>

== Deployment workflow ==
# On your laptop, prepare and upload a change to Differential against rOPS repository
# Get the change on Ysul: <code>arc patch D607</code>
# Ask Salt to apply the change
# Log on #nasqueron-operations something like <code>[Eglide] New user account: amj (D607)</code>
# Once working, you can merge it to master

== Salt commands ==
To apply one state or a directory:

<code>salt eglide state.apply roles/shellserver/users</code>

To apply all:

<code>salt eglide state.highstate</code>

Replace <code>eglide<code> by the server name, or <code>*</code> to target all machines.

When you've a new state, ensure it's called from <code>top.sls<code> file, as the repository root.

Operations grimoire/Sites on Ysul

2016-09-12T04:57:51Z

2001:470:1F13:D91:E8A0:AB13:681B:5C9F: Created page with "Sites on Ysul are deployed to /var/wwwroot. Four processes are known: * through custom deployment script (e.g. Zed, Nasqueron Tools) * through Git (e.g. www.espace-win.org ar..."

Sites on Ysul are deployed to /var/wwwroot.

Four processes are known:
* through custom deployment script (e.g. Zed, Nasqueron Tools)
* through Git (e.g. www.espace-win.org archive)
* through Jenkins task (e.g. dæghrefn.nasqueron.org)
* without any deployment workflow

To deploy a Jenkins-powered site, just commit to master and the deploy job will run automatically.

For other sites, reach Dereckson for guidance and support.

Operations grimoire/Sites on Eglide

2016-09-12T04:53:43Z

2001:470:1F13:D91:E8A0:AB13:681B:5C9F: Created page with "Sites on Eglide are fully managed through Salt configuration. == www.eglide.org == # On the Salt master, go to /opt/staging/wwwroot/eglide.org # Pull new code through <code>g..."

Sites on Eglide are fully managed through Salt configuration.

== www.eglide.org ==
# On the Salt master, go to /opt/staging/wwwroot/eglide.org
# Pull new code through <code>git fetch && git log HEAD..origin/master</code> and if changes are as expected <code>git rebase master</code>.
# Run <code>salt eglide state.apply roles/shellserver/eglide-website</code>

Operations grimoire

2016-09-12T04:51:07Z

2001:470:1F13:D91:E8A0:AB13:681B:5C9F: /* Services configuration */

Welcome to the Nasqueron operations grimoire (NOG).

== Infrastructure ==
* [[/Docker engine]]

== Services ==
=== Identity management ===
* [[/Login]] (Auth Grove)

=== Collaborative tools ===
* [[/Dæghrefn]] (eggdrop)
* [[/DevCentral]] (Phabricator)
* [[/Etherpad]]

=== CI/CD ===
* [[/Broker]]
* [[/Jenkins]]
* [[/Notifications center]]
* [[/Vault]]

== Other web sites ==
* [[/Sites on Eglide]]
* [[/Sites on Ysul]]
== Services configuration ==
''This section contains general information not related to a specific service.''
* [[/SSL certificates]] (Let's encrypt / letsencrypt)

== Checklists ==
=== Docker ===
* [[/Restart a Docker engine]]
* [[/Dwellers to DevCentral]]
* [[/Git operations in production containers]]

=== Salt ===
* [[/Deploy with Salt]]
* [[/Create and revoke user accounts on Salt servers]]

== Appendices ==
* [[/Policies]]
* [[/Contacts]]

[[Category:Reference]]

Poem

2016-09-05T21:20:28Z

2001:470:1F13:D91:985C:4F3C:AB66:5056:

<div style="-moz-column-width: 20em;">I was born in a water moon. Some people, especially its inhabitants, called it a planet, but as it was only a little over two hundred kilometres in diameter, 'moon' seems the more accurate term. The moon was made entirely of water, by which I mean it was a globe that not only had no land, but no rock either, a sphere with no solid core at all, just liquid water, all the way down to the very centre of the globe.

If it had been much bigger the moon would have had a core of ice, for water, though supposedly incompressible, is not entirely so, and will change under extremes of pressure to become ice. (If you are used to living on a planet where ice floats on the surface of water, this seems odd and even wrong, but nevertheless it is the case.) The moon was not quite of a size for an ice core to form, and therefore one could, if one was sufficiently hardy, and adequately proof against the water pressure, make one's way down, through the increasing weight of water above, to the very centre of the moon.

Where a strange thing happened.

For here, at the very centre of this watery globe, there seemed to be no gravity. There was colossal pressure, certainly, pressing in from every side, but one was in effect weightless (on the outside of a planet, moon or other body, watery or not, one is always being pulled towards its centre; once at its centre one is being pulled equally in all directions), and indeed the pressure around one was, for the same reason, not quite as great as one might have expected it to be, given the mass of water that the moon was made up from.

This was, of course,—

''Iain M. Banks''
</div>

== Divide by site ==

;Paragraph 1
* ''I was born in a water moon'' -> free
* ''Some people, especially its inhabitants, called it a planet'' -> [[Planet|planet.]]
* ''But as it was only a little over two hundred kilometres in diameter, 'moon' seems the more accurate term.'' -> free
* ''The moon was made entirely of water'' -> free
* ''by which I mean it was a globe that not only had no land, but no rock either'' -> free
* ''a sphere with no solid core at all'' -> databases
* ''just liquid water, all the way down to the very centre of the globe.'' -> blog

;Paragraph 2
* ''If it had been much bigger the moon would have had a core of ice'' -> devcentral
* ''for water, though supposedly incompressible, is not entirely so'' -> tools
* ''and will change under extremes of pressure to become ice.'' -> free (for a crytography tool?)
* ''If you are used to living on a planet'' -> free
* ''where ice floats on the surface of water'' -> forum
* ''this seems odd and even wrong, but nevertheless it is the case.'' -> server log
* ''The moon was not quite of a size for an ice core to form'' -> free
* ''and therefore one could, if one was sufficiently hardy, and adequately proof against the water pressure, make one's way down'' -> docker
* ''through the increasing weight of water above'' -> free
* ''to the very centre of the moon.'' -> free

[[Category:Nasqueron documentation]]

Operations grimoire/Etherpad

2016-08-25T00:45:16Z

2001:470:1F13:D91:6589:819A:61D0:B540: /* Upgrade code */

== Shared between Nasqueron and Wolfplex ==
The same Etherpad installation is served at two domains:
* https://pad.wolfplex.be/
* https://pad.nasqueron.org/

== Upgrade code ==

The easiest way is to spin a new container.

You can also upgrade code in the live container, updating Git code then restarting Node:

<source lang="console">
$ docker exec -it etherpad bash
$ git pull
…
Updating 2e81b39..45266f9
…
$ logout
$ docker restart etherpad
$ docker logs etherpad
…
[2016-08-25 00:40:24.711] [INFO] console - Your Etherpad version is 1.6.0 (45266f9)
</source>

Check the two versions match.

Note most recent code lives in the develop branch, not the master one.

== Launch container ==
<code>run-pad</code>

Source script available at https://devcentral.nasqueron.org/P210.

== Maintenance scripts ==

There are scripts to delete a pad or to repair a corrupted pad.

There are documented at https://github.com/ether/etherpad-lite/wiki/Getting-to-know-the-tools-in-bin

== Past known issues ==
=== Instability ===
When a copy/paste was done, server could crash.

This has been fixed by switching database to utf8mb4_bin:

<source lang="mysql">
ALTER DATABASE `etherpad` CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
ALTER TABLE `etherpad.store` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
</source>

=== Missing plugins ===
The installation requires two plugins, provided as npm packages:
* ep_ether-o-meter
* ep_author_neat

We now install them in <code>run-pad</code>:

<source lang="bash">
PLUGINS="ep_ether-o-meter ep_author_neat"

for plugin in $PLUGINS; do
docker exec $INSTANCE npm install $plugin
done
</source>

=== API key issue ===
http://www.wolfplex.be/pad/ could be empty. When that occurs, the API key on this site diverges from ours.

They store their API on Ysul at <code>/var/wwwroot/wolfplex.be/.dat/secrets-api.json</code>.

Normally, this is now handled by the following line from run-pad script:
<code>docker cp /data/etherpad/APIKEY.txt $INSTANCE:opt/etherpad-lite/APIKEY.txt</code>

{{Configuration as code}}
{{Vault secrets migration}}

Operations grimoire/Etherpad

2016-08-25T00:43:54Z

2001:470:1F13:D91:6589:819A:61D0:B540: /* Upgrade code */

== Shared between Nasqueron and Wolfplex ==
The same Etherpad installation is served at two domains:
* https://pad.wolfplex.be/
* https://pad.nasqueron.org/

== Upgrade code ==
<source lang="console">
$ docker exec -it etherpad bash
$ git pull
…
Updating 2e81b39..45266f9
…
$ logout
$ docker restart etherpad
$ docker logs etherpad
…
[2016-08-25 00:40:24.711] [INFO] console - Your Etherpad version is 1.6.0 (45266f9)
</source>

Check the two versions match.

== Launch container ==
<code>run-pad</code>

Source script available at https://devcentral.nasqueron.org/P210.

== Maintenance scripts ==

There are scripts to delete a pad or to repair a corrupted pad.

There are documented at https://github.com/ether/etherpad-lite/wiki/Getting-to-know-the-tools-in-bin

== Past known issues ==
=== Instability ===
When a copy/paste was done, server could crash.

This has been fixed by switching database to utf8mb4_bin:

<source lang="mysql">
ALTER DATABASE `etherpad` CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
ALTER TABLE `etherpad.store` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
</source>

=== Missing plugins ===
The installation requires two plugins, provided as npm packages:
* ep_ether-o-meter
* ep_author_neat

We now install them in <code>run-pad</code>:

<source lang="bash">
PLUGINS="ep_ether-o-meter ep_author_neat"

for plugin in $PLUGINS; do
docker exec $INSTANCE npm install $plugin
done
</source>

=== API key issue ===
http://www.wolfplex.be/pad/ could be empty. When that occurs, the API key on this site diverges from ours.

They store their API on Ysul at <code>/var/wwwroot/wolfplex.be/.dat/secrets-api.json</code>.

Normally, this is now handled by the following line from run-pad script:
<code>docker cp /data/etherpad/APIKEY.txt $INSTANCE:opt/etherpad-lite/APIKEY.txt</code>

{{Configuration as code}}
{{Vault secrets migration}}

Operations grimoire/Etherpad

2016-08-25T00:43:14Z

2001:470:1F13:D91:6589:819A:61D0:B540: /* Launch container */

== Shared between Nasqueron and Wolfplex ==
The same Etherpad installation is served at two domains:
* https://pad.wolfplex.be/
* https://pad.nasqueron.org/

== Upgrade code ==
<source lang="console">
$ docker exec -it etherpad bash
$ git pull
…
Updating 2e81b39..45266f9
…
$ logout
$ docker restart etherpad
$ docker logs etherpad
…
00:42:24 <+Dereckson> [2016-08-25 00:40:24.711] [INFO] console - Your Etherpad version is 1.6.0 (45266f9)
</source>

Check the two versions match.

== Launch container ==
<code>run-pad</code>

Source script available at https://devcentral.nasqueron.org/P210.

== Maintenance scripts ==

There are scripts to delete a pad or to repair a corrupted pad.

There are documented at https://github.com/ether/etherpad-lite/wiki/Getting-to-know-the-tools-in-bin

== Past known issues ==
=== Instability ===
When a copy/paste was done, server could crash.

This has been fixed by switching database to utf8mb4_bin:

<source lang="mysql">
ALTER DATABASE `etherpad` CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
ALTER TABLE `etherpad.store` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
</source>

=== Missing plugins ===
The installation requires two plugins, provided as npm packages:
* ep_ether-o-meter
* ep_author_neat

We now install them in <code>run-pad</code>:

<source lang="bash">
PLUGINS="ep_ether-o-meter ep_author_neat"

for plugin in $PLUGINS; do
docker exec $INSTANCE npm install $plugin
done
</source>

=== API key issue ===
http://www.wolfplex.be/pad/ could be empty. When that occurs, the API key on this site diverges from ours.

They store their API on Ysul at <code>/var/wwwroot/wolfplex.be/.dat/secrets-api.json</code>.

Normally, this is now handled by the following line from run-pad script:
<code>docker cp /data/etherpad/APIKEY.txt $INSTANCE:opt/etherpad-lite/APIKEY.txt</code>

{{Configuration as code}}
{{Vault secrets migration}}

Operations grimoire/Notifications center

2016-08-24T01:03:56Z

2001:470:1F13:D91:F980:7449:6E00:B7F8: /* Upgrade a live container */

The notifications centers is an HTTP to HTTP and HTTP to AMQP gateway for our CI infrastructure.

It allows to receive events from GitHub, Docker Hub and Phabricator, and send them to a RabbitMQ broker (white-rabbit) or Phabricator.

== Requirements ==
* [[Operations grimoire/Docker engine|Docker engine]]
* [[Operations grimoire/RabbitMQ|RabbitMQ broker]]

== Run it ==
=== Start a new container ===
<code>run-notifications</code>

=== Upgrade a live container ===
# Enter notifications container as app user : <code>docker exec -it --user=app notifications bash</code>
# Check we're on the master branch and the history is clean
# Update code rebasing the production branch against origin/master
# If composer has been touched, <code>composer update</code> (could be faster to docker pull, stop this container and start a new container)
# If entered as root, fix ownership with <code>chown -R app:app /var/wwwroot/default</code>
# Restart PHP FPM with <code>sv restart php-fpm</code>
# Run <code>php optimize</code> to refresh compiled class
# Restart again PHP FPM with <code>sv restart php-fpm</code>

For longer upgrade, you can put the application in maintenance mode with <code>php artisan down</code>.

If preferences are updated (in the code or by us), update the cache: <code>php artisan config:cache && sv restart php-fpm</code> is needed.

=== How to rebase against master? ===

# update master to match origin/master
# rebase production against master

<syntaxhighlight lang="console">
$ git fetch
$ git checkout master
$ git rebase origin/master
$ git checkout production
$ git rebase master
</syntaxhighlight>

If there is a merge conflict:

# Edit the conflict files
# <code>git add <edited files></code>
# <code>git rebase --continue</code>

== Configure it ==
=== Add a new GitHub organization ===
# Generate a random string to be used as a secret token shared between GitHub and the notifications center
# On Dwellers, add credentials to /data/notifications/storage/app/credentials.json
# On GitHub, go to organization settings, then Webhooks, e.g. https://github.com/organizations/acme/settings/hooks
# Add webhook:
## URL should be https://notifications.nasqueron.org/gate/GitHub/Acme where Acme is the ucfirst name of the organization account
## Your secret token go to secret field
## Switch from push events to "Send me everything".
## Let default settings: active, SSL verification, application/json
# Run the CLI client to receive notifications (`notifications` on Ysul, require to be in the `notifications` group, editable through /etc/group)
# GitHub will then fire immediately a ping, check in recent deliveries it's 200
# Fix and redeliver it if not
# Check in the CLI you've got a correct reply, e.g. [16:36:13] <Eglide/orgz> « Anything added dilutes everything else. » — GitHub Webhooks ping zen aphorism.

For payload delivery code returned by notifications.nasqueron.org, a 500 means probably a JSON syntax error in credentials.json, a 403 tokens don't match, note the center doesn't verify token if an empty string is left in the config (or you made a typo to the property).

== Links ==
# [https://devcentral.nasqueron.org/diffusion/NOTIF/ Source code]
# [https://devcentral.nasqueron.org/tag/notifications_center/ DevCentral board]

{{Configuration as Code}}
{{Vault secrets migration}}

Operations grimoire/Notifications center

2016-08-24T01:00:33Z

2001:470:1F13:D91:F980:7449:6E00:B7F8: /* Upgrade a live container */

The notifications centers is an HTTP to HTTP and HTTP to AMQP gateway for our CI infrastructure.

It allows to receive events from GitHub, Docker Hub and Phabricator, and send them to a RabbitMQ broker (white-rabbit) or Phabricator.

== Requirements ==
* [[Operations grimoire/Docker engine|Docker engine]]
* [[Operations grimoire/RabbitMQ|RabbitMQ broker]]

== Run it ==
=== Start a new container ===
<code>run-notifications</code>

=== Upgrade a live container ===
# Enter notifications container as app user : <code>docker exec -it --user=app notifications bash</code>
# Check we're on the master branch and the history is clean
# Update code rebasing the production branch against origin/master
# If composer has been touched, <code>composer update</code> (could be faster to docker pull, stop this container and start a new container)
# If entered as root, fix ownership with <code>chown -R app:app /var/wwwroot/default</code>
# Restart PHP FPM with <code>sv restart php-fpm</code>
# Run <code>php optimize</code> to refresh compiled class
# Restart again PHP FPM with <code>sv restart php-fpm</code>

For longer upgrade, you can put the application in maintenance mode with <code>php artisan down</code>.

If preferences are updated (in the code or by us), <code>php artisan config:clear</code> is needed.

=== How to rebase against master? ===

# update master to match origin/master
# rebase production against master

<syntaxhighlight lang="console">
$ git fetch
$ git checkout master
$ git rebase origin/master
$ git checkout production
$ git rebase master
</syntaxhighlight>

If there is a merge conflict:

# Edit the conflict files
# <code>git add <edited files></code>
# <code>git rebase --continue</code>

== Configure it ==
=== Add a new GitHub organization ===
# Generate a random string to be used as a secret token shared between GitHub and the notifications center
# On Dwellers, add credentials to /data/notifications/storage/app/credentials.json
# On GitHub, go to organization settings, then Webhooks, e.g. https://github.com/organizations/acme/settings/hooks
# Add webhook:
## URL should be https://notifications.nasqueron.org/gate/GitHub/Acme where Acme is the ucfirst name of the organization account
## Your secret token go to secret field
## Switch from push events to "Send me everything".
## Let default settings: active, SSL verification, application/json
# Run the CLI client to receive notifications (`notifications` on Ysul, require to be in the `notifications` group, editable through /etc/group)
# GitHub will then fire immediately a ping, check in recent deliveries it's 200
# Fix and redeliver it if not
# Check in the CLI you've got a correct reply, e.g. [16:36:13] <Eglide/orgz> « Anything added dilutes everything else. » — GitHub Webhooks ping zen aphorism.

For payload delivery code returned by notifications.nasqueron.org, a 500 means probably a JSON syntax error in credentials.json, a 403 tokens don't match, note the center doesn't verify token if an empty string is left in the config (or you made a typo to the property).

== Links ==
# [https://devcentral.nasqueron.org/diffusion/NOTIF/ Source code]
# [https://devcentral.nasqueron.org/tag/notifications_center/ DevCentral board]

{{Configuration as Code}}
{{Vault secrets migration}}

Operations grimoire/Notifications center

2016-08-23T19:53:30Z

2001:470:1F13:D91:F980:7449:6E00:B7F8: /* Upgrade a live container */

The notifications centers is an HTTP to HTTP and HTTP to AMQP gateway for our CI infrastructure.

It allows to receive events from GitHub, Docker Hub and Phabricator, and send them to a RabbitMQ broker (white-rabbit) or Phabricator.

== Requirements ==
* [[Operations grimoire/Docker engine|Docker engine]]
* [[Operations grimoire/RabbitMQ|RabbitMQ broker]]

== Run it ==
=== Start a new container ===
<code>run-notifications</code>

=== Upgrade a live container ===
# Enter notifications container as app user : <code>docker exec -it --user=app notifications bash</code>
# Check we're on the master branch and the history is clean
# Update code rebasing the production branch against origin/master
# If composer has been touched, <code>composer update</code> (could be faster to docker pull, stop this container and start a new container)
# If entered as root, fix ownership with <code>chown -R app:app /var/wwwroot/default</code>
# Restart PHP FPM with <code>sv restart php-fpm</code>
# Run <code>php optimize</code> to refresh compiled class
# Restart again PHP FPM with <code>sv restart php-fpm</code>

For longer upgrade, you can put the application in maintenance mode with <code>php artisan down</code>.

=== How to rebase against master? ===

# update master to match origin/master
# rebase production against master

<syntaxhighlight lang="console">
$ git fetch
$ git checkout master
$ git rebase origin/master
$ git checkout production
$ git rebase master
</syntaxhighlight>

If there is a merge conflict:

# Edit the conflict files
# <code>git add <edited files></code>
# <code>git rebase --continue</code>

== Configure it ==
=== Add a new GitHub organization ===
# Generate a random string to be used as a secret token shared between GitHub and the notifications center
# On Dwellers, add credentials to /data/notifications/storage/app/credentials.json
# On GitHub, go to organization settings, then Webhooks, e.g. https://github.com/organizations/acme/settings/hooks
# Add webhook:
## URL should be https://notifications.nasqueron.org/gate/GitHub/Acme where Acme is the ucfirst name of the organization account
## Your secret token go to secret field
## Switch from push events to "Send me everything".
## Let default settings: active, SSL verification, application/json
# Run the CLI client to receive notifications (`notifications` on Ysul, require to be in the `notifications` group, editable through /etc/group)
# GitHub will then fire immediately a ping, check in recent deliveries it's 200
# Fix and redeliver it if not
# Check in the CLI you've got a correct reply, e.g. [16:36:13] <Eglide/orgz> « Anything added dilutes everything else. » — GitHub Webhooks ping zen aphorism.

For payload delivery code returned by notifications.nasqueron.org, a 500 means probably a JSON syntax error in credentials.json, a 403 tokens don't match, note the center doesn't verify token if an empty string is left in the config (or you made a typo to the property).

== Links ==
# [https://devcentral.nasqueron.org/diffusion/NOTIF/ Source code]
# [https://devcentral.nasqueron.org/tag/notifications_center/ DevCentral board]

{{Configuration as Code}}
{{Vault secrets migration}}

Operations grimoire

2016-07-24T14:08:05Z

2001:470:1F13:D91:B4A6:641E:A23:C344: New section for SSL certificates

Welcome to the Nasqueron operations grimoire (NOG).

== Infrastructure ==
* [[/Docker engine]]

== Services ==
=== Identity management ===
* [[/Login]] (Auth Grove)

=== CI/CD ===
* [[/Broker]]
* [[/DevCentral]] (Phabricator)
* [[/Jenkins]]
* [[/Notifications center]]
* [[/Vault]]

== Services configuration ==
''This section contains general information not related to a specific service.''
* [[/SSL certificates]] (Let's encrypt / letsencrypt)

== Checklists ==
* [[/Restart a Docker engine]]

== Appendices ==
* [[/Policies]]
* [[/Contacts]]

[[Category:Reference]]

NOG

2016-07-22T11:32:44Z

2001:470:1F13:D91:8DAB:104C:2FD3:B875: Redirected page to Operations grimoire

#REDIRECT [[Operations grimoire]]

IRC

2015-12-21T21:22:28Z

2001:470:1F13:D91:BC7C:A61F:5017:4900: /* Wearg groups */ #nasqueron-ops→ #nasqueron-ops-logs

== List of channels ==

; In the primary Nasqueron space

Note : Freenode doesn't currently allow (well... since 2010 actually) new group registration, so we currently can't assign nasqueron/ cloaks etc.

* #nasqueron-ops - discussions about operations, infrastructure, any action performed on a server must be logged on this channel
* #nasqueron-pentacle - testing and operational control of the bots (Dæghrefn, Wearg, etc.), not really used for other beings than bots

; By project

* #tasacora - cartography project [[Tasacora]]

; Other channels were Nasqueron stuff are discussed

* #wolfplex - currently also given as support channel in a lot of documentation
* #fauve
* #wikipedia-fr - rare, but some discussions about Dæghrefn or tools.nasqueron.org occurs

== Wearg groups ==

Some channels want notifications about new commits, tasks, etc.

* #nasqueron-ops-logs - nasqueron.ops.* and nasqueron.docker.*
* #tasacora - nasqueron.tasacora.*

== Create a new channel ==

=== Where to list it? ===
* on this page
* a task should be filled on DevCentral against Dæghrefn project to notify the new channel, so we can configure the bot to manage ChanServ access there too

=== ChanServ configuration ===

REGISTER #nasqueron-quux
SET #nasqueron-quux MLOCK
TEMPLATE #nasqueron-quux botadmin +*
TEMPLATE #nasqueron-quux botop -*+vVoOti
TEMPLATE #nasqueron-quux member -*+vVoti
ACCESS #nasqueron-quux ADD Daeghrefn botadmin

=== Channel log ===

Normally, a channel is not publicly logged. But in some cases, it's interesting to enable this feature on purely technical channels.

If the channel is logged, you must do both of these:

* document it in the topic
* add an autojoin message, for example through ChanServ: SET #nasqueron-quux ENTRYMSG "This channel is publicly logged."

We consider the publication of logs to the DevCentral chatlog application to qualify as "publicly logged", regardless of the project-as-ACLs or the space where the log is.

IRC

2015-12-16T14:04:42Z

2001:470:1F13:D91:C89B:92BA:BAB6:2930: ChanServ configuration, notes about channel log

== List of channels ==

; In the primary Nasqueron space

Note : Freenode doesn't currently allow (well... since 2010 actually) new group registration, so we currently can't assign nasqueron/ cloaks etc.

* #nasqueron-ops - discussions about operations, infrastructure, any action performed on a server must be logged on this channel
* #nasqueron-pentacle - testing and operational control of the bots (Dæghrefn, Wearg, etc.), not really used for other beings than bots

; By project

* #tasacora - cartography project [[Tasacora]]

; Other channels were Nasqueron stuff are discussed

* #wolfplex - currently also given as support channel in a lot of documentation
* #fauve
* #wikipedia-fr - rare, but some discussions about Dæghrefn or tools.nasqueron.org occurs

== Wearg groups ==

Some channels want notifications about new commits, tasks, etc.

* #nasqueron-ops - nasqueron.ops.* and nasqueron.docker.*
* #tasacora - nasqueron.tasacora.*

== Create a new channel ==

=== Where to list it? ===
* on this page
* a task should be filled on DevCentral against Dæghrefn project to notify the new channel, so we can configure the bot to manage ChanServ access there too

=== ChanServ configuration ===

REGISTER #nasqueron-quux
SET #nasqueron-quux MLOCK
TEMPLATE #nasqueron-quux botadmin +*
TEMPLATE #nasqueron-quux botop -*+vVoOti
TEMPLATE #nasqueron-quux member -*+vVoti
ACCESS #nasqueron-quux ADD Daeghrefn botadmin

=== Channel log ===

Normally, a channel is not publicly logged. But in some cases, it's interesting to enable this feature on purely technical channels.

If the channel is logged, you must do both of these:

* document it in the topic
* add an autojoin message, for example through ChanServ: SET #nasqueron-quux ENTRYMSG "This channel is publicly logged."

We consider the publication of logs to the DevCentral chatlog application to qualify as "publicly logged", regardless of the project-as-ACLs or the space where the log is.

User:Dereckson/Notes 2015-08-11

2015-08-11T17:38:46Z

2001:470:1F13:D91:1D60:A6E9:DF4C:61D3:

== Définition formelle de la récursivité ==

''Source:'' rama

La récursion se compose de deux choses :

# une façon de passer de l'étape N à l'étape N+1 (en fonction de l'étapge N, voire d'autres étapes antérieures)
# un ancrage (i.e. la première occurrence)

la démonstration par récurrence se résume ainsi à "je prouve que si $PROPERTY est vraie pour x_(n), elle est vrai pour n_(n+1), ET j'exhibe un cas x_0 pour lequel c'est vrai ; c'est donc vrai pour tout x_n avec n entre 0 et l'infini".

== Approche intuitive de la récursivité ==

La récursivité est une fonction qui s'appelle elle-même.

Si tu as un Android, l'application AirDroid permet de prendre une photo, en l'afficher la caméra sur l'écran. Photographie l'écran qui affiche la photographie et tu obtiendras quelque chose comme ceci :

[[File:Recursivity intuitive.jpg]]

== Copier un tableau en C++ ==

http://nadeausoftware.com/articles/2012/05/c_c_tip_how_copy_memory_quickly#Method1Loopwitharrayindexes

== Exercices ==

Refaire la factorielle, findmin

Calculer par récursivité la somme des nombres d'un tableau

<code>
int* findsum (int[] numbers, int size)

e.g. findsum([1, 4, 7, 26], 4)
</code>

Déterminer si un chaîne de caractères est ou non un palindrome.

<code>
bool isPalindrome (char[] word, int len);

e.g. isPalindrome ("kayak", 5) -> true
</code>

User:Dereckson/Notes 2015-08-11

2015-08-11T17:17:35Z

2001:470:1F13:D91:1D60:A6E9:DF4C:61D3: /* Exercices */

== Définition formelle de la récursivité ==

''Source:'' rama

La récursion se compose de deux choses :

# une façon de passer de l'étape N à l'étape N+1 (en fonction de l'étapge N, voire d'autres étapes antérieures)
# un ancrage (i.e. la première occurrence)

la démonstration par récurrence se résume ainsi à "je prouve que si $PROPERTY est vraie pour x_(n), elle est vrai pour n_(n+1), ET j'exhibe un cas x_0 pour lequel c'est vrai ; c'est donc vrai pour tout x_n avec n entre 0 et l'infini".

== Copier un tableau en C++ ==

http://nadeausoftware.com/articles/2012/05/c_c_tip_how_copy_memory_quickly#Method1Loopwitharrayindexes

== Exercices ==

Refaire la factorielle, findmin

Calculer par récursivité la somme des nombres d'un tableau

<code>
int* findsum (int[] numbers, int size)

e.g. findsum([1, 4, 7, 26], 4)
</code>

Déterminer si un chaîne de caractères est ou non un palindrome.

<code>
bool isPalindrome (char[] word, int len);

e.g. isPalindrome ("kayak", 5) -> true
</code>

User:Dereckson/Notes 2015-08-11

2015-08-11T17:17:21Z

2001:470:1F13:D91:1D60:A6E9:DF4C:61D3:

== Définition formelle de la récursivité ==

''Source:'' rama

La récursion se compose de deux choses :

# une façon de passer de l'étape N à l'étape N+1 (en fonction de l'étapge N, voire d'autres étapes antérieures)
# un ancrage (i.e. la première occurrence)

la démonstration par récurrence se résume ainsi à "je prouve que si $PROPERTY est vraie pour x_(n), elle est vrai pour n_(n+1), ET j'exhibe un cas x_0 pour lequel c'est vrai ; c'est donc vrai pour tout x_n avec n entre 0 et l'infini".

== Copier un tableau en C++ ==

http://nadeausoftware.com/articles/2012/05/c_c_tip_how_copy_memory_quickly#Method1Loopwitharrayindexes

== Exercices ==

Refaire la factorielle, findmin

Calculer par récursivité la somme des nombres d'un tableau

<code>
int* findsum (int[] numbers, int size)

e.g. findsum([1, 4, 7, 26], 4)
</code>

Déterminer si un chaîne de caractères est ou non un palindrome.

bool isPalindrome (char[] word, int len);

e.g. isPalindrome ("kayak", 5) -> true

User:Dereckson/Notes 2015-08-11

2015-08-11T17:01:18Z

2001:470:1F13:D91:1D60:A6E9:DF4C:61D3: Created page with "== Définition formelle de la récursivité == ''Source:'' rama La récursion se compose de deux choses : # une façon de passer de l'étape N à l'étape N+1 (en fonction..."

Dwellers

2014-11-03T15:40:13Z

2001:470:1F13:D91:0:0:0:4: /* Shipyard */ Provides a shipyard instance to manage Dwellers (and potentially other Docker installation) at http://dwellers.nasqueron.org:30080

'''Dwellers''' is an VMWare EXSi instance installed on [[Stormshear]].

The goal of this server is to provide a Docker / OpenShift / Geard CentOS PaaS service.

== Basic information ==
* '''IPs:'''
** 212.129.32.223
** 2001:470:1f13:ce7:ca5:cade:fab:1e
* '''Hostname:''' dwellers.nasqueron.org
* '''Homepage:''' http://dwellers.nasqueron.org/
* '''Configuration:'''Access to 3.5 GB RAM and 4 core, burstable on request to 8 cores/+-6 Gb (to be negotiated according [[Ysul]] use)
* '''OS:''' CentOS 7
* '''ISP:''' [http://www.online.net Online] (FR)
* '''Network:''' Illiad (FR)
* '''Status:''' Installing.
* '''Policy:''' Access for any Nasqueron or Wolfplex project
* '''Started:''' 2014-07-13

== Services ==
* SSH (*:22)
* Docker
* OpenShift

== Containers ==
=== Ports table ===
Ø indicates an unmapped port. In such cases, it's accessible logging in Dwellers, and connecting locally to the current mutable container IP variable and the immutable specified port.

{| class="wikitable"
! '''Container name'''
! '''Container image'''
! '''Prefix'''
! '''Service'''
! '''Internal port'''
! '''External port'''
|-
| Dwellers Shipyard
| shipyard/shipyard
| 30
| Apache||80||30080
|-
|rowspan=3| phabricator.nasqueron.org
|rowspan=3| yesnault/docker-phabricator:latest
|rowspan=3| 31
| SSH||22||Ø
|-
| Apache||80||31080
|-
| MySQL||3306||Ø
|-
|rowspan=3| forum.nasqueron.org
|rowspan=3| provided by the project Discuss docker image
|rowspan=3| 32
| SSH||22||Ø
|-
| Apache||80||32080
|-
|colspan=3|Others services like redis are still to document
|-
|rowspan=2| bugzilla.espace-win.org
|rowspan=2| dklawren/docker-bugzilla
|rowspan=2| 33
| SSH||22||Ø
|-
| Apache||80||33080
|-

|}

=== phabricator.nasqueron.org ===
'''Port prefix:''' 31

Provides a Phabricator instance for Nasqueron projects at [http://phabricator.nasqueron.org http://phabricator.nasqueron.org].

To run a new container:
docker run -p 31080:80 nasqueron-phabricator

=== Shipyard ===
'''Port prefix:''' 30

Provides a shipyard instance to manage Dwellers (and potentially other Docker installation) at http://dwellers.nasqueron.org:30080

To run RethinkDB for the storage and launch shipyard:
docker run -it -d --name shipyard-rethinkdb-data --entrypoint /bin/bash shipyard/rethinkdb -l
docker run -it -P -d --name shipyard-rethinkdb --volumes-from shipyard-rethinkdb-data shipyard/rethinkdb
docker run -it -p 30080:8080 -d --name shipyard --link shipyard-rethinkdb:rethinkdb shipyard/shipyard

To control shipyard instance, launch the CLI (also in a container):
docker run -it shipyard/shipyard-cli

Documentation is at http://shipyard-project.com/docs/usage/cli/

== Troubleshoot ==
=== How to point a domain here? ===
For your domains:
* subdomain.domain.tld A 212.129.32.223
* subdomain.domain.tld AAAA 2001:470:1f13:ce7:ca5:cade:fab:1e

To request a DNS update for domains using extensively the Nasqueron servers infrastructure:
* subdomain.nasqueron.org CNAME www3.nasqueron.org
* subdomain.espace-win.org CNAME www2.espace-win.org

=== How to access by SSH to an instance? ===
See the ports table to check if a port is assigned. We don't assign port if there is no reason general public got access to the VM by SSH. We assign port each time a stable address is needed (for example to talk with a Git server)

If the port is mapped:

ssh -p <port> username@dwellers.nasqueron.org

If the port is unmapped, you can from Dwellers:

docker ps
docker inspect <instance id> #gets the local IP
ssh <IP 172.*>

=== No network at boot time ===
Access the machine on the hypervisor, then:

;Check the interface is up:
ip addr
ifup ens192 # to bring it up

;If you've reset the configuration and need to add again the IP:
ip addr 212.129.32.223/32 dev ens192

;Routing is probably the issue:
ip route add 62.210.76.1 dev ens192
ip route add default via 62.210.76.1

;Same for the case we can ping/ssh (slowly) from [[Ysul]] but not from the world:
ip route change 62.210.76.1 dev ens192
ip route change default via 62.210.76.1

;Reconfigure the IPv6 tunnel
ip tunnel del he-ipv6
ip tunnel add he-ipv6 mode sit remote 216.66.84.42 local 212.129.32.223 ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f12:ce7::2/64 dev he-ipv6
ip addr add 2001:470:1f13:ce7:ca5:cade:fab:1e/64 dev he-ipv6
ip route change ::/0 dev he-ipv6

=== A port on the host doesn't reply (but does in Docker) ===
You can reset the iptables configuration. A script has been provided for that.

# systemctl stop docker
# [[reset-iptables]]
# systemctl start docker

[[Category:Dwellers]]

Dwellers

2014-11-03T15:39:03Z

2001:470:1F13:D91:0:0:0:4: /* Containers */

'''Dwellers''' is an VMWare EXSi instance installed on [[Stormshear]].

The goal of this server is to provide a Docker / OpenShift / Geard CentOS PaaS service.

== Basic information ==
* '''IPs:'''
** 212.129.32.223
** 2001:470:1f13:ce7:ca5:cade:fab:1e
* '''Hostname:''' dwellers.nasqueron.org
* '''Homepage:''' http://dwellers.nasqueron.org/
* '''Configuration:'''Access to 3.5 GB RAM and 4 core, burstable on request to 8 cores/+-6 Gb (to be negotiated according [[Ysul]] use)
* '''OS:''' CentOS 7
* '''ISP:''' [http://www.online.net Online] (FR)
* '''Network:''' Illiad (FR)
* '''Status:''' Installing.
* '''Policy:''' Access for any Nasqueron or Wolfplex project
* '''Started:''' 2014-07-13

== Services ==
* SSH (*:22)
* Docker
* OpenShift

== Containers ==
=== Ports table ===
Ø indicates an unmapped port. In such cases, it's accessible logging in Dwellers, and connecting locally to the current mutable container IP variable and the immutable specified port.

{| class="wikitable"
! '''Container name'''
! '''Container image'''
! '''Prefix'''
! '''Service'''
! '''Internal port'''
! '''External port'''
|-
| Dwellers Shipyard
| shipyard/shipyard
| 30
| Apache||80||30080
|-
|rowspan=3| phabricator.nasqueron.org
|rowspan=3| yesnault/docker-phabricator:latest
|rowspan=3| 31
| SSH||22||Ø
|-
| Apache||80||31080
|-
| MySQL||3306||Ø
|-
|rowspan=3| forum.nasqueron.org
|rowspan=3| provided by the project Discuss docker image
|rowspan=3| 32
| SSH||22||Ø
|-
| Apache||80||32080
|-
|colspan=3|Others services like redis are still to document
|-
|rowspan=2| bugzilla.espace-win.org
|rowspan=2| dklawren/docker-bugzilla
|rowspan=2| 33
| SSH||22||Ø
|-
| Apache||80||33080
|-

|}

=== phabricator.nasqueron.org ===
'''Port prefix:''' 31

Provides a Phabricator instance for Nasqueron projects at [http://phabricator.nasqueron.org http://phabricator.nasqueron.org].

To run a new container:
docker run -p 31080:80 nasqueron-phabricator

=== Shipyard ===
'''Port prefix:''' 30

Run RethinkDB for the storage and launch shipyard:
docker run -it -d --name shipyard-rethinkdb-data --entrypoint /bin/bash shipyard/rethinkdb -l
docker run -it -P -d --name shipyard-rethinkdb --volumes-from shipyard-rethinkdb-data shipyard/rethinkdb
docker run -it -p 30080:8080 -d --name shipyard --link shipyard-rethinkdb:rethinkdb shipyard/shipyard

To control shipyard instance, launch the CLI (also in a container):
docker run -it shipyard/shipyard-cli

Documentation is at http://shipyard-project.com/docs/usage/cli/

== Troubleshoot ==
=== How to point a domain here? ===
For your domains:
* subdomain.domain.tld A 212.129.32.223
* subdomain.domain.tld AAAA 2001:470:1f13:ce7:ca5:cade:fab:1e

To request a DNS update for domains using extensively the Nasqueron servers infrastructure:
* subdomain.nasqueron.org CNAME www3.nasqueron.org
* subdomain.espace-win.org CNAME www2.espace-win.org

=== How to access by SSH to an instance? ===
See the ports table to check if a port is assigned. We don't assign port if there is no reason general public got access to the VM by SSH. We assign port each time a stable address is needed (for example to talk with a Git server)

If the port is mapped:

ssh -p <port> username@dwellers.nasqueron.org

If the port is unmapped, you can from Dwellers:

docker ps
docker inspect <instance id> #gets the local IP
ssh <IP 172.*>

=== No network at boot time ===
Access the machine on the hypervisor, then:

;Check the interface is up:
ip addr
ifup ens192 # to bring it up

;If you've reset the configuration and need to add again the IP:
ip addr 212.129.32.223/32 dev ens192

;Routing is probably the issue:
ip route add 62.210.76.1 dev ens192
ip route add default via 62.210.76.1

;Same for the case we can ping/ssh (slowly) from [[Ysul]] but not from the world:
ip route change 62.210.76.1 dev ens192
ip route change default via 62.210.76.1

;Reconfigure the IPv6 tunnel
ip tunnel del he-ipv6
ip tunnel add he-ipv6 mode sit remote 216.66.84.42 local 212.129.32.223 ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f12:ce7::2/64 dev he-ipv6
ip addr add 2001:470:1f13:ce7:ca5:cade:fab:1e/64 dev he-ipv6
ip route change ::/0 dev he-ipv6

=== A port on the host doesn't reply (but does in Docker) ===
You can reset the iptables configuration. A script has been provided for that.

# systemctl stop docker
# [[reset-iptables]]
# systemctl start docker

[[Category:Dwellers]]