ENSe connecter

Votre première expérience professionnelle, avant votre premier emploi.

Chaque lab vous plonge dans un vrai cas d'entreprise. Vous le résolvez vous-même, et vous gagnez ce que la théorie ne donne pas : la confiance.

Créer un compte

Votre premier atelier est offert.

Labs (52)

Choisissez votre prochain défi. Chaque lab est conçu par des experts, à partir de missions qu'ils mènent en entreprise.

49–52 sur 52 labs

  • AvancéParcours : Linux : administration système, préparation au LFCS

    Linux : SELinux et dépannage d'un serveur qui ne démarre plus

    L'audit de sécurité tient en deux constats. Sur srv-portail, le serveur qui sert aux clients le portail de suivi des conteneurs, SELinux ne protège plus rien depuis que le prestataire l'a mis en mode permissif, « parce que le portail ne démarrait pas avec ». Et personne n'a jamais testé un redémarrage : depuis la coupure de courant de cette nuit, srv-archives, qui garde les déclarations en douane, ne démarre plus. Vous lisez d'abord l'état de SELinux, les contextes des processus et des fichiers, et le journal d'audit, où le mode permissif a noté chaque refus sans en appliquer aucun. Vous passez en mode contraint pour voir le portail tomber, puis vous écartez les trois fausses corrections qui font repartir le portail en ouvrant bien plus que le besoin : couper SELinux, le booléen que propose audit2why, et le module qu'écrit audit2allow. La vraie correction tient en deux étiquettes : le port 8090 et le dossier du portail, par semanage et restorecon. SELinux passe en mode contraint, maintenant et au démarrage, sans perte de service. AppArmor, le module de Debian et d'Ubuntu, est situé en regard. Puis le second serveur : en mode d'urgence, root verrouillé, impossible d'y entrer. Vous lisez sa console, trouvez le montage qui échoue, arrêtez le serveur, vérifiez son disque, le montez depuis l'extérieur comme depuis une instance de secours, corrigez la faute de frappe de son fstab et la testez par un montage d'essai. Enfin la preuve : vous découvrez pourquoi le serveur, pourtant « activé », ne redémarrait pas seul, et vous redémarrez la machine pour de vrai. Un compte rendu écrit clôt l'audit. Dernier lab du parcours : il couvre les deux derniers chapitres de LFS207, les modules de sécurité Linux et le secours d'un système.

    • Aucun avis
    • Avancé
    • 3 h
    • 1 500 crédits
  • TutorielParcours : PostgreSQL : sauvegarde, restauration et PITR

    PostgreSQL : sauvegardes automatiques et chiffrées vers Amazon S3

    L'équipe data d'une fintech de Douala conserve ses sauvegardes PostgreSQL sur le disque du serveur applicatif. Une panne disque en juillet a coûté deux jours de transactions : la direction exige désormais des sauvegardes quotidiennes, chiffrées, stockées hors du serveur et vérifiables. Dans ce scénario, vous reprenez l'infrastructure là où elle en est : une base PostgreSQL de paiements qui reçoit une nouvelle transaction toutes les deux secondes, et un bucket S3 vide. À vous de construire la chaîne de sauvegarde complète — extraction avec pg_dump, chiffrement, dépôt sur S3, rotation des anciennes copies et alerte en cas d'échec. La sandbox est prête : PostgreSQL, l'AWS CLI et un rôle IAM limité à votre bucket sont déjà en place, et vous ouvrez le terminal directement dans votre navigateur, sans clé SSH. Vous passez la séance sur la logique de sauvegarde, pas sur l'installation des outils. À la fin, vous supprimez volontairement une table et prouvez que votre sauvegarde permet de repartir.

    • 4,0 sur 5, (2 avis)
    • Intermédiaire
    • 1 h 40 min
    • 500 crédits
    • 1er atelier offert
  • AvancéParcours : PostgreSQL : sauvegarde, restauration et PITR

    PostgreSQL : restaurer une base après incident et mesurer le RTO

    Il est 6 h du matin, la base de paiements ne redémarre plus et le directeur technique vous demande une seule chose : dans combien de temps le service est rétabli. Vous disposez des sauvegardes chiffrées déposées sur S3 la veille et d'un serveur de secours vierge. Ce scénario enchaîne sur la chaîne de sauvegarde du lab précédent, mais du côté qui compte vraiment : la restauration. Vous récupérez l'archive, la déchiffrez, remontez la base sur le serveur de secours, rebasculez le trafic applicatif et chiffrez le tout en un temps que vous mesurez. La sandbox démarre avec l'incident déjà survenu : la base principale est corrompue, les sauvegardes sont en place, le chronomètre tourne.

    • Aucun avis
    • Avancé
    • 2 h
    • 1 000 crédits
    • 1er atelier offert
  • AvancéParcours : PostgreSQL : sauvegarde, restauration et PITR

    PostgreSQL : restauration à la minute près (PITR) avec les WAL

    Lundi 14 h 07, un script de migration passe en production. Il devait régulariser les paiements du week-end ; sa dernière requête a perdu sa clause WHERE à la relecture. Personne ne le voit. À 15 h 30, le rapprochement bancaire ne tombe plus : toutes les transactions portent un montant à zéro. Vous restaurez le dump de 2 h du matin, le service repart, et treize heures d'encaissements disparaissent avec la bêtise. Les deux premiers labs du parcours ont réglé le temps de remise en service. Celui-ci s'attaque à l'autre chiffre, celui que personne n'avait demandé : la quantité de données perdues. Avec une sauvegarde par jour, aucune restauration, aussi rapide soit-elle, ne descend sous 24 heures de pertes — ce qui n'a pas été sauvegardé n'existe plus. Il faut changer de mécanisme. Vous mettez en place l'archivage continu des journaux de transactions vers S3, puis vous le prouvez sur un incident que vous déclenchez vous-même : vous relancez le script fautif sur une base vivante, et vous la ramenez à la seconde d'avant. Un plan de reprise qu'on n'a jamais répété n'est pas un plan, c'est un espoir. La sandbox démarre avec la production en marche — une transaction toutes les deux secondes — le dump de 02 h 00 déjà sur S3, et l'archivage des WAL à construire.

    • Aucun avis
    • Avancé
    • 2 h 30 min
    • 1 000 crédits
    • 1er atelier offert