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.

37–48 of 52 labs

  • GeneralPath: SQL and PostgreSQL: from your first query to optimisation

    PostgreSQL: constraints, data types and privileges

    Mama Ngo is back from the village. While she was away, her niece Nadia ran the till for a whole week. "There are sales at zero, a payment method nobody knows, and the rice twice. Couldn't the machine refuse on its own?" In the previous workshop, you learnt to write carefully. But care only protects what you type yourself. The only protection that works for everyone is the database that refuses. You start by finding the damage with the queries you know, then you try to set the rule that would have prevented it, and the database refuses to create it: existing rows already violate it. That refusal becomes your clean-up plan. You clean up without losing anything, after asking Nadia what really happened, because strange data is not necessarily wrong. Then you set the rules the database will enforce on everyone: CHECK, UNIQUE, DEFAULT. You merge the duplicated rice despite the foreign key standing in the way, you choose the type of each piece of information on a delivery note, and you create the deliveries table, with its automatic numbering and its link to the products. Finally, you discover that a new table is closed to everyone, and you grant the right to read it, and only to read it. Everything happens in the terminal, with the database owner's account. At the end, the rules you set and the table you created are checked in the database, and the result counts for your ranking.

    • No reviews yet
    • Intermediate
    • 2 h
    • 750 credits
    • First lab free
  • GeneralPath: SQL and PostgreSQL: from your first query to optimisation

    Advanced SQL: subqueries, WITH (CTEs) and window functions

    The shop finally knows what it pays the wholesaler. Mama Ngo has two questions: "Was September better than August? And what do I really earn on, once the wholesaler is paid?" Neither fits in a simple query. The first compares a month with the previous one, the second combines tables grouped differently. It is SQL's new wall: the question that takes several steps. You learn to write it the way you think it, one named step after another, each checkable on its own. Along the way, three traps that raise no message. A division between integers that shows 0 % instead of 58 %. A NOT IN that returns zero rows because a single empty value lurks in the list. And a direct join between two tables that multiplies the amounts without warning. Each one is triggered on figures you know, so that you see they are wrong instead of believing them. You group by month and by day of the week, you calculate each product's margin with WITH, you classify with CASE, and you discover window functions: lag to compare each month with the previous one, rank to rank without grouping. The challenge: the most profitable product in each aisle. And a surprise in the figures: what fills the till is not what keeps the shop alive.

    • No reviews yet
    • Intermediate
    • 2 h
    • 750 credits
    • First lab free
  • GeneralPath: SQL and PostgreSQL: from your first query to optimisation

    PostgreSQL: speed up a query with EXPLAIN and indexes

    The shop has joined the Nkoldongo traders' cooperative: forty shops, a single database, a million sales. The chairman calls Mama Ngo: "When a loyal customer comes in, the screen takes ages to bring up their history. And on Saturdays, it's worse." No query is wrong: they are slow. And in front of a slow query, the temptation is to try things at random. This workshop does the opposite: before speeding up a query, you read how PostgreSQL runs it. You measure, then you read the plan with EXPLAIN and EXPLAIN ANALYZE: a million rows read to return fourteen, by three processes in parallel. You create the index that changes the plan, and you prove it with the plan itself, learning to look for a single word in it. Then the three cases where an index exists and is useless: a function on the column, a condition that is not selective enough, a search in the middle of a text. You also measure what an index costs on every write, and you drop the one that is not used. Finally, full-text search: searching for words rather than letters, plural or singular, upper case or not, with the index that takes it from more than a second to a few dozen milliseconds. The challenge: the Saturday dashboard, and the two-column index that makes it instant.

    • No reviews yet
    • Intermediate
    • 2 h 15 min
    • 1,000 credits
    • First lab free
  • GeneralPath: SQL and PostgreSQL: from your first query to optimisation

    PostgreSQL: transactions, locks and deadlocks

    Mama Ngo has bought a second till. Last Saturday, there was only one bottle of vegetable oil left: "A lady paid for it at Nadia's till while a gentleman was paying for it at mine. Two receipts, one bottle. Didn't the machine see we were selling the same thing at the same time?" As long as there was only one till, sales went through one after the other. With two, they cross. This workshop opens two terminals, one per till, and replays the Saturday in the exact order in which the two tills act. You first see what one session sees of another's work, before and after COMMIT, then you reproduce the phantom sale: no error, two sales committed, one bottle. You meet your first lock, a terminal that does not give the prompt back because the other till holds the row. Then you write the sale that cannot oversell, by letting the database count, and you see PostgreSQL re-read the row after the wait. You reserve a row before deciding with SELECT FOR UPDATE, you work in a frozen snapshot in REPEATABLE READ until the serialisation error, and you trigger a deadlock that the database breaks by sacrificing one of the two tills. And one last scene: the forgotten transaction that freezes everyone. Finding it and cutting it off is the administrator's job, and it is the challenge that closes the path.

    • No reviews yet
    • Intermediate
    • 2 h 15 min
    • 1,000 credits
    • First lab free
  • GeneralPath: SQL and PostgreSQL: from your first query to optimisation

    PostgreSQL challenge: unblock a session that freezes the till

    Saturday, 10 a.m. The shop is full, and Nadia's till is spinning in the void. It does not crash, it does not display anything: it waits. Ludovic is not answering his phone. Mama Ngo is waiting with a customer, a pack of sardines in her hand. This challenge has no step-by-step guide. It has a mission, rules, and the official PostgreSQL documentation. For the first time you are on the other side of the server: superuser, with a view of every open session, what each one is doing, and what each one is waiting for. It is up to you to trace the blocked till back to the session blocking it, to understand what it holds and since when, then to cut it off, and only it, without restarting the server or stopping the till. You will also have to make sure it does not happen again: configure the server so that a forgotten transaction can no longer block the shop for more than thirty seconds, and leave Ludovic a note so he understands what happened. This is exactly the work of a database administrator: observing, understanding, stepping in without interrupting the service, and relying on the documentation. The natural next step after this path.

    • No reviews yet
    • Intermediate
    • 1 h 30 min
    • 1,000 credits
    • First lab free
  • BeginnerPath: Linux: system administration, LFCS preparation

    Linux: inventory a server (services, ports, logs)

    The contractor who ran the ERP server left three weeks ago, without handing anything over. Nobody knows what runs on it, or what would come back on its own after a power cut. Management is not asking you to fix anything: they want a written inventory, so that the next incident is not handled blind. You start from a shell and nothing else. It is the situation almost every system administrator starts with, and the one no course prepares you for. The guide does not give you the answers: it gives you the questions and the tools, and you search the machine before opening the solution. You will learn to read the file tree to separate what a package installed from what a human put there by hand, to ask systemd which unit a process belongs to, and to put a name on every listening port. Along the way, you will come across what every inherited server hides: business data no standard backup would take, a program nobody watches, and a script that works by hand but would fail as a service. You fix nothing, you document. Your inventory is read on the machine at the end of the lab, and it counts for your ranking. A real server, with its services in production and its logs. The terminal opens in your browser: no SSH key, nothing to install.

    • No reviews yet
    • Beginner
    • 1 h 45 min
    • 500 credits
    • First lab free
  • BeginnerPath: Linux: system administration, LFCS preparation

    Linux: users, groups and permissions

    Two operations staff and an accountant start on Monday. Today everyone logs in with the same admin account, whose password is written on a sticky note. The statutory auditor has set three conditions before signing off the year: named accounts, access to the accounting records limited to the people concerned, and traceability of administrative actions. You have the weekend. Managing rights is what gets handed to a junior administrator first, and what is most often done wrong: a chmod 777 that solves today's problem and opens this year's. You will start with the audit, and it holds a surprise: a former employee has kept full powers. Then you will translate the business need into groups, build a share where every new file stays editable by the whole team (group, setgid, umask), and grant one precise command through sudo instead of root power. The server is in production, and the order of your moves matters as much as the moves themselves: build, prove under each newcomer's identity, and only then close the old accesses. The guide makes you predict the result before every command, because the gap between what you expected and what you see is what makes Unix permissions click. At the end, the machine's state is checked and counts for your ranking. Sandbox ready, terminal in the browser, no key to manage.

    • No reviews yet
    • Beginner
    • 2 h 30 min
    • 750 credits
    • First lab free
  • GeneralPath: Linux: system administration, LFCS preparation

    Linux: patch a vulnerability with apt and dnf (Debian, RHEL)

    A critical vulnerability has just been published in GnuTLS, the encryption library present across your whole estate, and it must be fixed within 24 hours. Except that the ERP vendor wrote to you this morning: their connector is only certified with the version of curl currently installed. Any curl upgrade stops invoicing. So you have to fix the vulnerability without letting curl move, on both halves of the estate, and be able to justify it to the auditor. A uniform estate only exists in training courses. Here you work with both families side by side, a server from the RHEL family and a Debian 12 container stuck at its 2023 version, and you learn to translate every operation from one to the other: dpkg and rpm to know, apt and dnf to change. First trap, the one that trips up most beginners: the package carries neither the command's name nor the same name from one distribution to the other. You will look at what an update would take with it before running it, fix only what is necessary and prove it by the installed version, not by the absence of errors. Then you will freeze curl on both sides, try to force the lock, and document the debt this freeze creates, with its lift date. That last point is the one you will be blamed for if it is missing. At the end, the machine and your sheet are checked, and the result counts for your ranking. Terminal in the browser, nothing to install.

    • No reviews yet
    • Intermediate
    • 2 h 50 min
    • 1,000 credits
    • First lab free
  • GeneralPath: Linux: system administration, LFCS preparation

    Linux: full disk and growing an LVM volume

    3:12 in the morning. The on-call phone rings: not a single invoice is going out, the /srv/factures volume is at 100%. You must restore the service tonight, without rebooting the server, without making /etc/fstab invalid, and without deleting anything that has accounting value. In the morning, management will ask one question only: why was nobody warned before the outage? “Disk full” covers three different failures, and they are not treated the same way. The guide makes you diagnose before you touch: you predict what df and du will answer, and their disagreement leads you to a file deleted the day before but still held open by a service, which still takes up hundreds of megabytes. You give that space back without erasing a single file, then you grow the logical volume and its file system online, without unmounting and without interrupting invoicing. The lab then goes where tutorials stop. Deciding whether swap is a cure or a symptom by reading real memory usage, rather than following a ready-made rule. Then setting up what was really missing: a measurement of how full the disk is, scheduled by a systemd timer, and a CloudWatch alarm with a threshold that leaves time to act during the day. At the end, the machine's state and the alarm are checked, and the result counts for your ranking. A real server, in incident conditions.

    • No reviews yet
    • Intermediate
    • 3 h 15 min
    • 1,500 credits
  • GeneralPath: Linux: system administration, LFCS preparation

    Linux networking: routing and the nftables firewall

    The company switched Internet providers two days ago. Since then, customers can no longer track their containers online, while at the office the portal displays perfectly. The provider answered your ticket within an hour: the problem is not on their side. Management gives you the morning to give customers their portal back, and to answer one question in writing: who was right? You start by narrowing down the outage instead of searching at random: the same test from the office and from the Internet rules out half the suspects. Then a packet capture settles the argument with the provider, with evidence. You then go down layer by layer: the address, the route, the neighbours, and a gateway that has not existed since the router was replaced. You learn to recognise, from the shape of the error alone, a service that is not listening from a firewall that filters, and you catch the firewall in the act in the kernel log. The lab goes where tutorials stop. Understanding why a rule that was wrong from day one worked for years. Opening exactly one port in nftables, without opening administration to the Internet or shutting out the office. Then making every fix permanent, and proving it without rebooting, before writing the incident report that management and the provider will read. The office, the provider's router and a customer on the Internet are simulated on the machine: you can break the route and the firewall without losing your terminal. At the end, the server's state and your report are checked, and the result counts for your ranking.

    • No reviews yet
    • Intermediate
    • 2 h 50 min
    • 1,500 credits
  • AdvancedPath: Linux: system administration, LFCS preparation

    Linux: systemd services, timers and udev rules

    Customs write for the third time: not a single declaration has reached the single window in three days, and containers are stuck at the port. The same morning, the dock supervisor reports that the label printer has printed nothing since the dock workstation was plugged back in. In lab 1, you had put the collection script in the risks column: started at boot by cron, detached by nohup, its output thrown into /dev/null. The risk has materialised. You start with the investigation: the log that stops without a word, the UPS log revealing that only power cuts ever restarted the collection, then the script run by hand that dies before your eyes at the first refusal from the customs window. Before touching anything, you put the configuration under Git. You then hand the collection over to systemd: a unit that restarts it without wearing itself out, under its own account, with bounded memory and a journal where nothing gets lost any more. The nightly summary, which cron forgot on power-cut nights, becomes a timer that catches up on missed runs. That leaves the barcode scanner. The kernel numbers devices in the order they arrive, and the labelling software now listens to the keyboard. You read what the kernel and udev know about a device, meet the modules that drive it, and write the udev rule that names it by what it is, not by its place in the queue. To finish, a colleague "simplifies" the configuration on a Friday evening, and Git tells you in ten seconds what changed. The customs window and the dock hardware are simulated on the machine, and behave like the real ones. At the end, the server's state and your Git history are checked, and the result counts for your ranking.

    • No reviews yet
    • Intermediate
    • 3 h
    • 1,500 credits
  • AdvancedPath: Linux: system administration, LFCS preparation

    Linux: centralise accounts with LDAP, SSSD and PAM

    The statutory auditor is back. In lab 2, you locked the account of ktraore, the dock agent who left months ago. The preliminary report fits in one sentence: ktraore is locked on srv-erp, but active on srv-quai, with administration rights, and the auditor logged in with a password found in the former contractor's notes. The group has had a central directory since last year, which nobody finished connecting. The follow-up visit is on Friday. You start by mapping the estate: the same employee carrying two different numbers from one server to the next, and a local account silently inheriting the directory's groups. You learn to read an LDAP directory, its branches, entries and filters, encrypting the connection and introducing yourself with an account that can only read. Then you disable the former employee in the directory, and discover that a central revocation is worth nothing as long as a local account carries the same name. The lab goes where tutorials stop. Connecting a server with SSSD, NSS and PAM, and understanding why SSSD refuses to start with a file readable by everyone. Migrating local accounts to the directory without any file changing hands, knowing why a chown run on the whole disk would steal their files from a container's accounts. Seeing that a badly chosen order reopens the door you thought was closed. Cutting the directory, seeing who can still get in thanks to the cache, and testing the emergency account before you need it. Finally, writing the departure procedure the auditor will read on Friday. The directory is a real OpenLDAP, and the dock server a container with its own SSSD: you work on a small estate, from a single terminal. At the end, real login attempts check your revocations, as the auditor will, and the result counts for your ranking.

    • No reviews yet
    • Advanced
    • 3 h 15 min
    • 1,500 credits