FRSign in

Your first work experience, before your first job.

Each lab drops you into a real company case. You solve it yourself, on a real server, and you come away with what theory never gives you: confidence.

  • A real business case
  • Ready in minutes, nothing to install
  • A skill to talk through in interviews
Create an account

Your first lab is free.

Labs (52)

Pick your next challenge. Every lab is built by practitioners, from missions they carry out in companies across Africa.

49–52 of 52 labs

  • AdvancedPath: Linux: system administration, LFCS preparation

    Linux: SELinux and rescuing a server that won't boot

    The security audit comes down to two findings. On srv-portail, the server that gives customers the container tracking portal, SELinux has protected nothing since the contractor set it to permissive mode, "because the portal would not start with it". And nobody has ever tested a reboot: since last night's power cut, srv-archives, which keeps the customs declarations, no longer boots. You first read the state of SELinux, the contexts of processes and files, and the audit log, where permissive mode noted every denial without enforcing any. You switch to enforcing to see the portal go down, then rule out the three false fixes that bring the portal back by opening far more than the need: switching SELinux off, the boolean audit2why suggests, and the module audit2allow writes. The real fix comes down to two labels: port 8090 and the portal's folder, with semanage and restorecon. SELinux goes to enforcing mode, now and at boot, with no loss of service. AppArmor, the module on Debian and Ubuntu, is placed alongside. Then the second server: in emergency mode, root locked, no way in. You read its console, find the failing mount, stop the server, check its disk, mount it from the outside as from a rescue instance, fix the typo in its fstab and test it with a test mount. Finally the proof: you find out why the server, although "enabled", did not restart on its own, and you really reboot the machine. A written report closes the audit. The last lab of the path: it covers the last two chapters of LFS207, Linux security modules and system rescue.

    • No reviews yet
    • Advanced
    • 3 h
    • 1,500 credits
  • TutorialPath: PostgreSQL: backup, restore and PITR

    PostgreSQL: automated, encrypted backups to Amazon S3

    The data team of a fintech in Douala keeps its PostgreSQL backups on the application server's disk. A disk failure in July cost two days of transactions: management now demands daily backups, encrypted, stored off the server and verifiable. In this scenario, you take over the infrastructure as it stands: a PostgreSQL payments database that receives a new transaction every two seconds, and an empty S3 bucket. It is up to you to build the complete backup chain: extraction with pg_dump, encryption, upload to S3, rotation of old copies and an alert on failure. The sandbox is ready: PostgreSQL, the AWS CLI and an IAM role restricted to your bucket are already in place, and you open the terminal directly in your browser, with no SSH key. You spend the session on backup logic, not on installing tools. At the end, you deliberately drop a table and prove that your backup gets you back on your feet.

    • 4.0 out of 5, (2 reviews)
    • Intermediate
    • 1 h 40 min
    • 500 credits
    • First lab free
  • AdvancedPath: PostgreSQL: backup, restore and PITR

    PostgreSQL: restore a database after an incident and measure the RTO

    It is 6 a.m., the payments database will not come back up and the CTO asks you one thing only: how long until the service is back. You have the encrypted backups uploaded to S3 the day before and a blank standby server. This scenario follows on from the previous lab's backup chain, but on the side that really matters: the restore. You fetch the archive, decrypt it, bring the database back on the standby server, switch the application traffic back and put a figure on the whole thing, in a time you measure. The sandbox starts with the incident already under way: the main database is corrupted, the backups are in place, the clock is running.

    • No reviews yet
    • Advanced
    • 2 h
    • 1,000 credits
    • First lab free
  • AdvancedPath: PostgreSQL: backup, restore and PITR

    PostgreSQL: point-in-time recovery (PITR) with WAL

    Monday, 2:07 p.m., a migration script goes into production. It was supposed to regularise the weekend's payments; its last query lost its WHERE clause during review. Nobody notices. At 3:30 p.m., the bank reconciliation no longer balances: every transaction has an amount of zero. You restore the 2 a.m. dump, the service comes back, and thirteen hours of payments vanish along with the blunder. The path's first two labs dealt with the time to restore service. This one tackles the other figure, the one nobody had asked for: the amount of data lost. With one backup a day, no restore, however fast, gets below 24 hours of losses: what was not backed up no longer exists. You need to change the mechanism. You set up continuous archiving of the transaction logs to S3, then you prove it on an incident you trigger yourself: you rerun the faulty script on a live database, and bring it back to the second before. A recovery plan that has never been rehearsed is not a plan, it is a hope. The sandbox starts with production running, one transaction every two seconds, the 02:00 dump already on S3, and the WAL archiving still to be built.

    • No reviews yet
    • Advanced
    • 2 h 30 min
    • 1,000 credits
    • First lab free