Start a systemd Service on the First Connection (TCP Socket Edition)
Configure systemd to keep a TCP port open at all times while starting the backing service process only when the first connection arrives.
Focused hands-on problems designed to help you hone your DevOps or Server Side skills. Some challenges are more educational, while others are based on real-world scenarios. The platform provides hints and feedback for each challenge, including automated solution checks.
Configure systemd to keep a TCP port open at all times while starting the backing service process only when the first connection arrives.
Configure systemd to keep a Unix domain socket open at all times while starting the backing service process only when the first connection arrives.
Make a single echo server listen on either a TCP socket or a Unix domain socket, selected by its command-line argument. The challenge illustrates that the same stream-socket workflow works with two address families (AF_INET and AF_UNIX).
Write a TCP client to hold a back-and-forth conversation with a "chat" server: send a line, read the reply, send another line - repeat until the session is over. A hands-on lesson in designing an application protocol on top of a byte-oriented TCP stream.
Write your first TCP client for a push-only telemetry server that starts sending sensor readings as soon as you connect. Likely the easiest way to get started with TCP socket programming.
The Hello World of network programming: implement a tiny TCP echo server in the language of your choice.
Sometimes an image needs to be removed from a registry - because it was pushed by mistake, contains sensitive data, or simply should no longer be available. Practice purging a container image properly: remove the tag, trace it to the manifest and blobs behind it, and make sure the image can no longer be pulled - even by digest.
Practice discovering what has been published to a remote container repository by listing its tags using crane, regctl, or a direct call to the registry HTTP API.
Set up your own OCI-compatible container registry with username/password authentication and HTTPS - the kind of protection you'd expect before using a registry in production.
Stand up a self-hosted container registry so you can push and pull images without relying on a third-party registry. Useful for tests, internal services, air-gapped environments, or just for poking at the OCI Distribution API.