Configuration - CardinPatson/SysAdmin GitHub Wiki

Conventions et bonnes pratiques pour le repository

  • La langue employée dans ce repository ainsi que les commentaires dans les codes sources est le français.
  • Les conventions d'usage pour lier les mots sont :
    • snake_case et camelCase : variables et fonctions
    • kebab-case : fichiers pouvant se retrouver dans les URLs (ex: petite-patate.html)
    • PascalCase : classes PHP
    • SCREAMING_SNAKE : constantes
  • Les notes de modifications et améliorations sont :
    • TODO : point restant à développer
    • FIXME : point nécessitant une modification ou une amélioration
  • Les sources consultées dans le cadre des recherches nécessaires à la réalisation des différents services sont regroupées sous le titre "Sources" à la fin de chaque page correspondante.
  • Les commits sont réalisés avec, comme message, une description du changement.
  • Le wiki est divisé en plusieurs sections représentant un service avec ses propres pages :
    • Analyse
    • Configuration
    • Documentation
    • Sécurisation
  • L'arborescence des fichiers dans le repository est représentée ci-dessous :
WoodyToy
├─ README.md
└─ SysAdmin
   ├─ Docs
   │  ├─ admin-II-Cdc-projet.pdf
   │  ├─ admin-II-enoncé-projet.pdf
   │  ├─ infrastructure_woody.png
   │  ├─ resume.txt
   │  ├─ workflow_dev.drawio
   │  └─ workflow_dev.png
   ├─ Mail
   │  ├─ addusername
   │  ├─ db
   │  │  ├─ db.sql
   │  │  └─ users.sql
   │  ├─ dkim-dmarc
   │  │  ├─ KeyTable
   │  │  ├─ opendkim.conf
   │  │  ├─ SigningTable
   │  │  └─ TrustedHosts
   │  ├─ docker-compose.yml
   │  ├─ Dockerfile
   │  ├─ dovecot
   │  │  ├─ conf.d
   │  │  │  ├─ 10-auth.conf
   │  │  │  ├─ 10-logging.conf
   │  │  │  ├─ 10-mail.conf
   │  │  │  ├─ 10-master.conf
   │  │  │  ├─ 10-ssl.conf
   │  │  │  └─ auth-sql.conf.ext
   │  │  ├─ dovecot-sql.conf.ext
   │  │  └─ dovecot.conf
   │  ├─ postfix
   │  │  ├─ main.cf
   │  │  ├─ master.cf
   │  │  ├─ virtual-domains.cf
   │  │  ├─ virtual-email2email.cf
   │  │  ├─ virtual-forwardings.cf
   │  │  └─ virtual-users.cf
   │  └─ spamassassin
   │     ├─ local.cf
   │     └─ spamassassin
   ├─ README.md
   ├─ schema.drawio
   ├─ schema.png
   ├─ Services_internes
   │  ├─ docker-compose.yml
   │  ├─ intranet
   │  │  ├─ Dockerfile
   │  │  ├─ index.php
   │  │  └─ intranet.conf
   │  ├─ range.txt
   │  ├─ resolver
   │  │  ├─ Dockerfile
   │  │  └─ named.conf
   │  ├─ samba
   │  │  ├─ shares.conf
   │  │  └─ smb.conf
   │  └─ SOA_interne
   │     ├─ db.intranet.woody
   │     ├─ Dockerfile
   │     ├─ named.conf
   │     └─ zone_reverse
   ├─ SOA_externe
   │  ├─ db.m1-3.ephec-ti.be
   │  ├─ docker-compose.yml
   │  ├─ Dockerfile
   │  └─ named.conf
   ├─ ssh.txt
   ├─ VoiP
   └─ Web
      ├─ b2b
      │  └─ index.php
      ├─ docker
      │  ├─ certbot
      │  │  └─ certbot.txt
      │  ├─ mysql
      │  │  └─ schema.sql
      │  ├─ nginx
      │  │  └─ default.conf
      │  └─ php
      │     ├─ Dockerfile
      │     └─ www.conf
      ├─ docker-compose.yml
      ├─ docker-compose.yml and dovecot
      └─ www
         └─ index.html

Workflow de développement

Après analyse du service, nous développons le DockerFile qui servira de base. Une fois le DockerFile opérationnel, on passe à la configuration du service. La configuration se base sur le cahier des charges et l'analyse qu'on en a retirée.

Quand les conditions de configuration semblent correctes, on peut se pencher sur la documentation et la sécurisation du service. Comme les configurations ne sont pas toujours terminées en temps et en heure, il arrive que ces 2 points soient démarrés avant mais autant que possible en concertation avec les autres membres du groupe.

Quand la documentation et la sécurisation semblent terminées, on contrôle si le service est opérationnel et que les conditions précitées sont toujours respectées sinon on procède à des ajustements.

Si toutes les conditions sont satisfaites et que le service est opérationnel, alors on soumet le service pour sa validation.

Workflow

Etat d'avancement et de fonctionnement du prototype

Service DNS :

  • Analyse : Ok
  • Configuration : Ok
  • Documentation : Ok
  • Sécurisation : Ok

Service Web :

  • Analyse : Ok
  • Configuration : Ok
  • Documentation : Ok
  • Sécurisation : Ok

Service Réseau Interne :

  • Analyse : Ok
  • Configuration : En cours
  • Documentation : Ok
  • Sécurisation : En cours

Service Mail :

  • Analyse : Ok
  • Configuration : Ok
  • Documentation : Ok
  • Sécurisation : En cours

Service VoiP :

  • Analyse : Ok
  • Configuration : En cours
  • Documentation : En cours
  • Sécurisation : Ok

Prototype :

  • Analyse : En cours
  • Configuration : En cours
  • Documentation : Ok
  • Sécurisation : Ok

Organisation du travail

Description du mode de fonctionnement

Nous avons décidé d'une réunion hebdomadaire minimum à planifier selon les disponibilités de chacun. Il n'a pas toujours été évident de régler ça compte tenu de tous les travaux parallèles mais en fin de compte, la nuit compte aussi.

Le projet a démarré avec la rédaction des Ressources Records du service DNS. Une fois ça mis en place, nous en avons fait l'analyse, la configuration la documentation et la sécurisation dans la foulée.

Ensuite, les vps ont été inaccessibles pendant un temps plus ou moins long selon le vps et donc nous sommes tous partis dans des directions différentes afin de compléter un maximum les différents points qui ne requerraient pas leur utilisation. Nous avons perdu pas mal de temps entre les nombreuses questions au sujet du cahier des charges et des différentes solutions à y apporter et les vps au point mort donc, nous n'avons pas vraiment eu le temps de nous pencher sur les compétences avancées. A une semaine de la fin des cours, la priorité est de terminer nos compétences de base.

Bilan 1 au 15/03

Le DNS est fonctionnel et les différentes tâches ont été partagées. La réunion hebdomadaire nous permet de partager nos questions au sujet des zones d'ombre du cahier des charges.

Bilan 2 au 03/04

Presque tout le service DNS a été validé. Les vps sont out depuis 1 semaine donc on décide de compléter tout ce qui est complétable en attendant le retour des vps.

Bilan 3 au 17/04

Les vps sont à nouveau opérationnels depuis 2 jours donc on essaie de se lancer les configurations. Il est difficile de distinguer ce qui est attendu par rapport au cahier des charges et donc, on perd du temps à discuter de la solution à adopter pour les services internes. Le service Mail est terminé et le service Web en passe de l'être aussi.

Bilan 4 au 01/05

On entame la VoiP, tous les autres services sont terminés à part la configuration des Services Internes mais le doute sur la solution adoptée, à savoir le gestionnaire de fichiers Samba, est enfin levé.