Aide de jeu pour Les Bâtisseurs Antiquité

Laisser un commentaire

J'ai eu la joie de recevoir pour mon anniversaire le jeu de société Les Bâtisseurs Antiquité, un super jeu au format très compact. Tellement compact que l'éditeur, Bombyx pour ne pas le citer, n'a pas fourni d'aide de jeu ! C'est un peu étonnant de nos jours surtout qu'il restait de la place dans la boîte et que l'impression de 4 cartes supplémentaires n'aurait sans doute pas fait exploser le prix du jeu (13,50 € chez Philibert).

Du coup j'ai confectionné une petite aide de jeu qui reprend le format (11cm x 11cm), la charte graphique et le code couleur de la notice.

Mise en place d’une Autorité de Certification SSH

Laisser un commentaire

0. Préambule

0.1. Présentation

Nous allons permettre à un utilisateur (user) d'utiliser un client SSH pour se connecter à un serveur SSH (host) puis de s'authentifier grâce à une paire de clé.

Ces opérations (connexion puis authentification) seront validées par une chaine de certification.

Dans cette documentation, l'utilisateur test@srvbackup01.info.lan va se connecter en tant que transfert@srvapache01.info.lan grâce à sa paire de clés RSA.

0.2. Pré-requis

Nous avons besoin de 3 ordinateurs :

  • srvauth01.info.lan = Autorité de Certification SSH
  • srvapache01.info.lan = Serveur SSH
  • srvbackup01.info.lan = Client SSH

Nous avons besoin que la résolution DNS soit fonctionnelle sur tous les ordinateurs.

Nous avons besoin d'au minimum 5 utilisateurs :

  • root@srvauth01.info.lan = administrateur de la machine
  • root@srvapache01.info.lan = administrateur de la machine
  • test@srvapache01.info.lan = utilisateur de test
  • root@srvbackup01.info.lan = administrateur de la machine
  • test@srvbackup01.info.lan = utilisateur de test

1. Création de l'Autorité de Certification (AC)

Nous allons créer une chaine de certification pour les hosts (serveurs) et une chaine de certification pour les users (utilisateurs).

1.1. Préparation de l'espace de travail de l'autorité de certification

Nous ouvrons une session root@srvauth01.info.lan

Nous créons un dossier ssh_ca dans le dossier home de l'utilisateur root (/root) 

mkdir /root/ssh_ca/

1.2. Génération des paires de clés

Nous allons générer une paire de clés pour la chaine de certification des hosts (serveurs) et une paire de clés pour la chaine de certification des users (utilisateurs) .

1.2.1. Chaine HOSTS

Nous générons une paire de clés RSA 2048 bits : 

ssh-keygen -t rsa -b 2048 -f /root/ssh_ca/ssh_ca_hosts_rsa_key -C "AC HOSTS"

Une clé privée (format standard) est générée dans le fichier ssh_ca_hosts_rsa_key
Une clé publique (format SSH) est générée dans le fichier ssh_ca_hosts_rsa_key.pub

1.2.2. Chaine USERS

Nous générons une paire de clés RSA 2048 bits : 

ssh-keygen -t rsa -b 2048 -f /root/ssh_ca/ssh_ca_users_rsa_key -C "AC USERS"

Une clé privée (format standard) est générée dans le fichier ssh_ca_users_rsa_key
Une clé publique (format SSH) est générée dans le fichier ssh_ca_users_rsa_key.pub

1.3. Création des certificats "racine"

Nous allons auto-signer des certificats "racine" avec les clés générées précédemment

1.3.1. Chaine HOSTS

Génération d'un certificat depuis la clé publique de l'AC HOSTS : 

ssh-keygen -s /root/ssh_ca/ssh_ca_hosts_rsa_key -I ca_hosts -h -n srvauth01.info.lan -V +52w /root/ssh_ca/ssh_ca_hosts_rsa_key.pub

Un certificat SSH est généré dans le fichier ssh_ca_hosts_rsa_key-cert.pub

1.3.2. Chaine USERS

Génération d'un certificat depuis la clé publique de l'AC USERS : 

ssh-keygen -s /root/ssh_ca/ssh_ca_users_rsa_key -I ca_users -h -n srvauth01.info.lan -V +52w /root/ssh_ca/ssh_ca_users_rsa_key.pub

Un certificat SSH est généré dasn le fichier ssh_ca_users_rsa_key-cert.pub

2. Configuration des hosts (serveurs SSH)

Nous allons générer un certificat SSH par host puis nous allons lui indiquer comment vérifier les hosts et les users.

2.1. Installation des chaines de certification

2.1.1. Génération du certificat d'hote

Nous ouvrons une session root@srvauth01.info.lan

Nous allons préparer les fichiers nécessaires à la configuration de srvapache01.info.lan

Création d'un dossier de travail : 

mkdir /root/ssh_ca/srvapache01.info.lan/

Récupération de la clé publique : 

scp root@srvapache01.info.lan:/etc/ssh/ssh_host_rsa_key.pub /root/ssh_ca/srvapache01.info.lan/

Création du certificat : 

ssh-keygen -s /root/ssh_ca/ssh_ca_hosts_rsa_key -I host_srvapache01 -h -n srvapache01.info.lan -V +52w /root/ssh_ca/srvapache01.info.lan/ssh_host_rsa_key.pub

2.1.2. Installation du certificat d'hote et de la clé publique de vérification des utilisateurs

Nous ouvrons une session root@srvauth01.info.lan

Copie du certificat sur l'hôte : 

scp /root/ssh_ca/srvapache01.info.lan/ssh_host_rsa_key-cert.pub root@srvapache01.info.lan:/etc/ssh/

Copie de la clé publique de l'AC USERS sur l'hôte : 

scp /root/ssh_ca/ssh_ca_users_rsa_key.pub root@srvapache01.info.lan:/etc/ssh/

2.2. Configuration des serveurs SSH (SSHD)

Nous ouvrons une session root sur srvapache01.info.lan et sur srvbackup01.info.lan

Modification de la configuration de SSHD : 

vi /etc/ssh/sshd_config

Nous devons indiquer au serveur SSH où trouver son certificat : 

HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Nous devons indiquer au serveur SSH où trouver la clé publique permettant de vérifier les certificats des utilisateurs : 

TrustedUserCAKeys /etc/ssh/ssh_ca_users_rsa_key.pub

Redémarrage du service : 

service ssh restart

3. Configuration de la partie "client"

3.1. Génération du certificat utilisateur depuis l'AC

Nous allons préparer les fichiers nécessaires à l'authentification de test@srvbackup01.info.lan

Nous ouvrons une session root@srvauth01.info.lan

Création d'un dossier de travail : 

mkdir -p /root/ssh_ca/srvbackup01.info.lan/test/

Récupération de la clé publique : 

scp test@srvbackup01.info.lan:/home/test/.ssh/id_rsa.pub /root/ssh_ca/srvbackup01.info.lan/test/

Création du certificat : 

ssh-keygen -s /root/ssh_ca/ssh_ca_users_rsa_key -I test_user -n test -V +52w /root/ssh_ca/srvbackup01.info.lan/test/id_rsa.pub

Copie du certificat dans le profil de l'utilisateur : 

scp /root/ssh_ca/srvbackup01.info.lan/test/id_rsa-cert.pub test@srvbackup01.info.lan:/home/test/.ssh/

3.2. Configuration du client SSH (déclaration de l'AC HOSTS)

Nous allons indiquer au client SSH comment vérifier le certificat du serveur SSH. Pour cela nous allons designer la clé publique de l'AC HOSTS comme @cert-authority de *.info.lan.

Il suffit d'ajouter la ligne suivante dans le fichier known_hosts de l'utilisateur (~/.ssh/known_hosts) ou de l'ordinateur (/etc/ssh/ssh_known_hosts) : 

@cert-authority *.info.lan <clé publique SSH de l'AC HOSTS>

3.2.1. Génération d'un fichier known_hosts de référence

Nous ouvrons une session root@srvauth01.info.lan 

printf "@cert-authority *.info.lan $(cat /root/ssh_ca/ssh_ca_hosts_rsa_key.pub)" > /root/ssh_ca/known_hosts

3.2.2. Ajout de l'AC HOSTS pour un utilisateur

Nous ouvrons une session root@srvauth01.info.lan

Remplacement du fichier known_hosts de l'utilisateur test@srvbackup01.info.lan 

scp /root/ssh_ca/known_hosts test@srvbackup01.info.lan:/home/test/.ssh/

3.2.3. Ajout de l'AC HOSTS pour un ordinateur

Nous ouvrons une session root@srvauth01.info.lan

Remplacement du fichier ssh_known_hosts de srvbackup01.info.lan 

scp /root/ssh_ca/known_hosts root@srvbackup01.info.lan:/etc/ssh/ssh_known_hosts

Nous pouvons changer l'emplacement de ce fichier en modifiant la directive GlobalKnownHostsFile du fichier /etc/ssh/ssh_config : 

GlobalKnownHostsFile /etc/ssh/known_hosts

 

Apache HTTPD : SSO dans un réseau d’entreprise Windows

Laisser un commentaire

1. Technologies utilisables pour le SSO

Services d'authentification :

Fournisseurs d'identité :

  • Le contrôleur de domaine Active Directory (Active Directory Domain Services)

Fournisseur d'autorisation :

  • Le contrôleur de domaine Active Directory (Active Directory Federation Services)

Mécanisme de négociation :

Méthodes / protocoles d'authentification :

Fournisseurs de sécurité :

2. Fonctions disponibles pour Apache HTTPD

Le serveur peut procéder à l'identification du client web en utilisant un module tiers.

Version 2.2.X Windows :

  • mod_auth_ntlm (NTLM sur HTTP)
  • mod_auth_sspi (SSPI + NTLMSSP)

Version 2.4.X Windows

  • mod_auth_sspi (SSPI + NTLMSSP)

Version 2.2.X Linux :

  • mod_auth_ntlm_winbind (NLTM sur HTTP)
  • mod_auth_kerb (GSSAPI + Kerberos)

Version 2.4.X Linux :

  • mod_auth_ntlm_winbind (NLTM sur HTTP)
  • mod_auth_kerb (GSSAPI + Kerberos)

 

3. Exemples

Cas 0 : NTLM sur HTTP

 

Cas 1 : SSPI + NTLMSSP

 

Cas 2 : GSSAPI + Kerberos

 

 

Passer de Debian 7 à 8

Le but est de passer de Debian 7.X (wheezy) à Debian 8.X (Jessie).

Mettre à jour votre version actuelle :
apt-get update && apt-get upgrade

Remplacer le nom de version dans les listes de sources de APT :
sed -i 's/wheezy/jessie/g' /etc/apt/sources.list

Ne pas oublier de modifier les listes de sources des produits tiers (MariaDB, etc) :
sed -i 's/wheezy/jessie/g' /etc/apt/sources.list.d/mariadb.list

Téléchargement et installation de la nouvelle version :
apt-get update && apt-get upgrade && apt-get dist-upgrade -y

Redémarrage :
reboot

C'est fini !

[En route vers les Indes] Règles alternatives

Dernière mise à jour le 31/08/2015

Ces règles alternatives ont été conçues pour le jeu En Route vers les Indes édité par IELLO en 2014 (voir le site officiel).

Introduction

Le but de ces règles alternatives est d'améliorer le jeu tout en simplifiant les règles et sans ajouter de nouveau matériel.

Liste des modifications :

  • Ajout du jeu à 2 joueurs
  • Modification du jeu à 3 joueurs
  • Simplification de l'installation
  • Amélioration de la rejouabilité

Je m'efforcerai d'utiliser les termes utilisés dans la règle officielle.

Partie 0 : Présentation

  • 0.1. Lexique

Partie A : Installation

  • A.1. Détermination de l’ordre du tour
  • A.2. Distribution du matériel des joueurs
  • A.3. Sélection des cartes Ville Côtière
  • A.4. Mise en place de la zone commune
  • A.5. Placement des marqueurs et des disques
  • A.6. Attribution des richesses de départ
  • A.7. Limitation des ressources (à moins de 4 joueurs)

Partie B : Comment jouer

  • B.1. Tour de jeu
  • B.2. Activation des marqueurs
  • B.3. Déplacement des navires
  • B.4. Vente des marchandises
  • B.5. Construction d'un bâtiment
  • B.6. Acquisition d'une technologie
  • B.7. Accélération des navires
  • B.8. Actions gratuites
  • B.9. Conditions de fin de partie

[En route vers les Indes] Règles alternatives – Partie B : Comment jouer

B. Comment jouer

B.1. Tour de jeu

IDENTIQUE A LA REGLE OFFICIELLE

B.2. Activation des marqueurs

IDENTIQUE A LA REGLE OFFICIELLE

B.3. Déplacement des navires

B.3.1. Déplacer les marqueurs

IDENTIQUE A LA REGLE OFFICIELLE

B.3.2. Découvrir une nouvelle Ville côtière

IDENTIQUE A LA REGLE OFFICIELLE

A moins de 4 joueurs : Après avoir révélé la carte Ville Côtière, le joueur Lanterne Rouge place un marqueur Joueur Neutre sur cette carte.

B.3.3. Convertir ses navires en marchandises

IDENTIQUE A LA REGLE OFFICIELLE

B.4. Vente des marchandises

IDENTIQUE A LA REGLE OFFICIELLE

B.5. Construction d’un bâtiment

IDENTIQUE A LA REGLE OFFICIELLE

B.6. Acquisition d’une technologie

IDENTIQUE A LA REGLE OFFICIELLE

B.7. Accélération des navires

IDENTIQUE A LA REGLE OFFICIELLE

B.8. Actions gratuites

IDENTIQUE A LA REGLE OFFICIELLE

B.9. Conditions de fin de partie

IDENTIQUE A LA REGLE OFFICIELLE

[En route vers les Indes] Règles alternatives – Partie A : Installation

A. Installation

A.1. Détermination de l’ordre du tour

Le joueur ayant navigué pour la dernière fois est désigné Premier Joueur.

Le tour de jeu commencera par le Premier Joueur puis continuera dans le sens horaire.

A.2. Distribution du matériel des joueurs

Dans l’ordre du tour de jeu, chaque joueur prend :

  • 1 carte Domaine
  • 1 carte Histoire
  • 1 carte Aide de jeu
  • Tous les marqueurs et les disques de la couleur de son choix

Replacez ensuite le matériel inutilisé dans la boite de jeu.

A.3. Sélection des cartes Ville Côtière

Mélangez les douze cartes Ville Côtière.

Tirer un nombre de cartes dépendant du nombre de joueurs :

  • à 2 joueurs : 6 cartes
  • à 3 joueurs : 9 cartes
  • à 4 joueurs : 12 cartes

Replacez les cartes non utilisées dans la boite de jeu (tout en les conservant faces cachées).

A.4. Mise en place de la zone commune

Placez les éléments suivant de façon à ce que tous les joueurs puissent les lire facilement :

  • Les 3 cartes Technologies
  • Les cartes Ville Côtière en formant une ligne horizontale pour tracer la route vers les Indes
  • La carte Lisbonne à la gauche de la route vers les Indes

Révélez les 3 cartes les plus proches de la carte Lisbonne.

A.5. Placement des marqueurs et des disques

Chaque joueur place :

  • 2 marqueurs sur la carte Lisbonne
  • Tous les autres marqueurs dans la réserve
  • 1 disque sur la case 1 de la zone vitesse du navire de sa carte Domaine
  • Tous les autres disques sur la case TECHNOLOGIE de sa carte Domaine

A.6. Attribution des richesses de départ

Dans l’ordre du tour, chaque joueur obtient les richesses suivantes :

  • à 2 joueurs : 2 richesses, 3 richesses
  • à 3 joueurs : 2 richesses, 2 richesses, 3 richesses
  • à 4 joueurs : 2 richesses, 2 richesses, 3 richesses, 4 richesses

A.7. Limitation des ressources (à moins de 4 joueurs)

Le Premier Joueur choisit une couleur non-utilisée, cette couleur sera celle du Joueur Neutre.

Dans l’ordre inverse du tour (du dernier au premier), les joueurs vont placer :

  • 1 marqueur Joueur Neutre sur une carte Ville Côtière vide
  • 1 disque Joueur Neutre sur une carte Technologies vide

Continuez le processus jusqu’à ce que chaque carte Ville Côtière et Technologies possède une marqueur ou un disque Joueur Neutre.

[En route vers les Indes] Règles alternatives – Partie 0 : Présentation

Partie 0 : Présentation

0.1. Lexique

Lanterne Rouge : le joueur ayant le moins de Point de Victoire. En cas d’égalité de Point de Victoire, le joueur ayant le moins de richesse. En cas d’égalité de richesse, le joueur ayant la moins bonne position dans l’ordre du tour.

Placer un marqueur : positionner un marqueur sur une zone autorisée.

[Batailles de Westeros] Règles optionnelles officielles

Dernière mise à jour le 17/07/2015.

Voici les règles additionnelles officielles FFG en VO suivies de ma traduction/interprétation :

Coordinated Attack

Multiple units may melee attack the same unit simultaneously. When this occurs, one unit is declared the lead unit while all others are supporting units. Supporting units give up their normal attack to add their attack dice minus one to the lead unit’s attack. All attack dice are rolled together. All units activate normally.

Only the lead unit (and its commander if it is a commander unit) can use its keyword abilities.

Valor results are only scored as hits if both the lead and supporting units can hit on valor. For example, if a player attacks an enemy cavalry unit and is supported by infantry units, the attack would not score hits on valor.

If flanking units and non-flanking units take part in a coordinated attack, do not reroll for the flanking unit.

If all units taking part in the attack are flanking units, rerolls occur as normal.

It is possible for a supporting unit to be unable to contribute any dice to a coordinated attack. For example, when playing with the “Reduced Strength Units” optional rule, a green rank unit at reduced strength contributes 0 dice as a supporting unit in a coordinated attack.

Attaque Coordonnée

L’attaque coordonnée permet à plusieurs unités de mener simultanément une attaque de mêlée contre une seule et même cible.

Séquence de combat :
1. Déclarer les unités attaquantes participant à l’attaque coordonnée. Désigner une unité qui va mener l’attaque, elle sera appelée ATTAQUANT. Les autres unités attaquantes seront appelées SOUTIENS.
2. Déclarer l’unité qui sera la cible de l’attaque coordonnée, elle sera appelée CIBLE.
3. Vérifier la portée. Toutes les unités attaquantes doivent être adjacentes à la CIBLE et doivent exécuter une attaque de mêlée.
4. Placer le pion d’engagement (si nécessaire) entre l’ATTAQUANT et la CIBLE.
5. Déterminer les caractéristiques de l’attaque (débordement, etc). Si toutes les unités attaquantes sont en capacité de déborder la CIBLE, une attaque par débordement peut être menée.
6. Déterminer les dés d’attaque. Calculer pour chaque SOUTIEN le bonus de dés d’attaque donné à l’ATTAQUANT. Ce bonus est égal au nombre de dés d’attaque du SOUTIEN moins un dé.
7. Lancer les dés d’attaque de l’ATTAQUANT.
8. Résoudre l’attaque. Compter les touches en ne retenant que celles étant un succès pour toutes les unités attaquantes.
9. Pivoter la bannière des attaquants.

Any Card To Order Only 1 Unit
A player may discard any Leadership card to order a single unit. A command token must still be placed on a commander and the ordered unit must be in that commander’s ZOC.

Utiliser n’importe quelle carte pour commander une seule unité
Un joueur peut jouer n’importe quelle carte de commandement pour commander une seule unité. Les propriétés de cette carte sont ignorées.

Reduced Strength Units
A unit that has lost at least half its strength is considered a reduced strength unit.
Reduced strength units roll one less die during combat rolls.
Reduced strength units can retreat a maximum of two hexes. If forced to retreat beyond two hexes, the reduced strength unit takes hits as normal.

Unité affaiblie
Une unité qui a perdu la moitié ou plus de sa force devient une unité affaiblie. Une unité affaiblie lance une dé d’attaque de moins durant les attaques. Une unité affaiblie n’a le droit de se replier que de 2 cases au maximum.

Withdrawals
After all ordered enemy units have moved, a player may choose to voluntarily withdraw any friendly units adjacent to an enemy unit ordered this turn. This happens before any new engagement tokens are placed on the game board. Withdrawing units must be active and adjacent to an enemy unit ordered this turn. The owner of the withdrawing unit must then decrease his morale by one point if the withdrawing unit is of a rank lower than the highest-ranked adjacent enemy unit, by two points if these ranks are equal, and by three points if the withdrawing unit is a higher rank than the highest-ranked adjacent enemy unit. To withdraw, move the withdrawing unit into one of the two hexes toward its owner’s board edge. This unit becomes inactive. If the withdrawing unit was engaged with another unit, the enemy unit may perform a parting blow as normal.
Multiple units may withdraw during a turn.

Replis
Après la phase de mouvement du joueur actif, un joueur inactif peut provoquer le repli de certaines de ses unités.

Séquence de repli :
1. Déclarer les unités en repli. Ces unités doivent être activables et doivent être adjacentes aux unités ennemies s’étant déplacées durant ce tour.
2. Déplacer les unités en repli d’une case vers leur camp (bord du plateau associé à leur camp).
3. Pivoter les bannières des unités en repli.
4. Ajuster l’échelle de moral. Pour chaque unité se repliant, le joueur reçoit un malus de moral de 1 point si l’unité en repli est de rang inférieur à l’unité ennemie, de 2 points si l’unité en repli est de rang égal à l’unité ennemie ou de 3 points si l’unité en repli est de rang supérieur à l’unité ennemie.

Liste des modifications :

Version 1.0 (14/07/2015)
Première traduction et interprétation des règles additionnelles officielles FFG en VO (FAQ 1.3.2)

Version 1.1 (17/07/2015)
Général : refonte des textes afin d’employer les termes utilisés dans la règle officielle en VF editée par EDGE.
Attaque coordonnée : réorganisation de l’action pour se rapprocher de la « Séquence de combat » de la règle officielle.
Replis : réorganisation de l’action dans une « Séquence de repli ».