8.4.9 Lab: Configure Logging On Linux: Exact Answer & Steps

Ever tried to hunt down why a service suddenly stopped, only to stare at an empty /var/log directory?
You’re not alone. In real terms, in a lot of labs—especially the 8. 4.9 “Configure Logging on Linux” exercise—students spend more time Googling “where does syslog write?” than actually fixing the problem.

The short version is: if you don’t tell Linux where to put its messages, you’ll be chasing ghosts. Below is everything you need to know to ace that lab, keep your logs tidy, and actually use the data when something goes sideways.

What Is Logging on Linux

Linux logging is the system’s way of whispering (or shouting) everything that happens: kernel boots, daemons start, users log in, files get accessed. In practice, those whispers end up as plain‑text files under /var/log, but the magic happens behind the scenes with a daemon called rsyslog (or sometimes systemd‑journald on newer distros).

Think of rsyslog as the post office. Applications drop “letters” (log messages) into a mailbox, rsyslog reads the envelope, decides where to deliver it, and then stamps it into the right file. You can also tell it to forward messages to a remote server, filter out noise, or change the format entirely Simple as that..

The Core Pieces

• syslog facility – a tag that groups similar services (e.g., auth, cron, daemon).
• syslog severity – how urgent the message is (debug, info, warning, err, crit).
• rsyslog.conf – the rulebook that maps facility + severity to a destination.
• journalctl – the command‑line viewer for systemd’s binary journal (if you’re on a system that uses it).

If you’ve ever edited /etc/rsyslog.d/, you’ve already been playing with the same tools the 8.confor dropped a file into/etc/rsyslog.4.9 lab expects you to master.

Why It Matters / Why People Care

When you’re troubleshooting a flaky web server, the first place you look is the log. No log, no clue, and you end up restarting services blindfolded.

In a production environment, logs are the raw material for compliance audits, security forensics, and capacity planning. Miss a single line about a failed SSH login and you could be blind to a brute‑force attack Nothing fancy..

And here’s the thing most newbies miss: logging isn’t just “turn it on”. The 8.4.In practice, over‑logging fills disks; under‑logging leaves you clueless. Even so, it’s about making the right data visible, searchable, and retained for the right amount of time. 9 lab forces you to strike that balance But it adds up..

How It Works (or How to Do It)

Below is a step‑by‑step walk‑through that covers the typical lab requirements: installing rsyslog, configuring local files, rotating logs, and sending a copy to a remote host.

1. Install and Verify rsyslog

# Debian/Ubuntu
sudo apt-get update && sudo apt-get install -y rsyslog

# RHEL/CentOS/Fedora
sudo yum install -y rsyslog

After installation, make sure the daemon is running:

systemctl status rsyslog

You should see “active (running)”. If it’s disabled, enable it:

sudo systemctl enable --now rsyslog

2. Understand the Default Configuration

Open the main config file:

sudo less /etc/rsyslog.conf

You’ll notice three sections:

1. Modules – load input/output plugins (imuxsock, imjournal, etc.).
2. Global directives – things like $RepeatedMsgReduction that control behavior.
3. Rules – the heart of the matter, e.g.:

*.info;mail.none;authpriv.none;cron.none                /var/log/messages
authpriv.*                                              /var/log/secure
mail.*                                                  -/var/log/maillog

The asterisk (*) means “all facilities”. Now, after the semicolon you can exclude specific ones (mail. On top of that, none). The path at the end tells rsyslog where to write Small thing, real impact..

3. Create a Custom Rule File

Best practice (and what the lab expects) is to drop a new file into /etc/rsyslog.d/. Let’s call it `10-custom.

sudo tee /etc/rsyslog.d/10-custom.conf > /dev/null <<'EOF'
# Log all cron activity to its own file
cron.*                          /var/log/cron.log

# Separate authentication logs
auth,authpriv.*                 /var/log/auth.log

# Capture kernel messages at warning level or higher
kern.warn                       /var/log/kern.warn.log
EOF

A few notes:

• No spaces before the destination path, otherwise rsyslog will ignore the line.
• Prefixing the file with a low number (10-) ensures it’s loaded early, before any catch‑all rules that might otherwise swallow the messages.

4. Test the New Rules

Restart rsyslog so it picks up the new file:

sudo systemctl restart rsyslog

Now generate a test message:

logger -p auth.info "Test auth log entry"
logger -p cron.notice "Test cron log entry"
logger -p kern.err "Kernel error test"

Check the files:

tail /var/log/auth.log
tail /var/log/cron.log
tail /var/log/kern.warn.log

If you see your messages, you’ve nailed the basic configuration.

5. Set Up Log Rotation

Linux doesn’t keep logs forever; logrotate handles that. The default package already ships a config for most standard logs, but you’ll want a custom rule for the files you just created.

Create /etc/logrotate.d/custom:

sudo tee /etc/logrotate.d/custom > /dev/null <<'EOF'
/var/log/cron.log /var/log/auth.log /var/log/kern.warn.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
    create 0640 syslog adm
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}
EOF

Explanation in plain English: keep four weeks of logs, compress old ones, and tell rsyslog to reopen its file handles after rotation (the postrotate script does that) No workaround needed..

Run a manual rotation to be sure:

sudo logrotate -f /etc/logrotate.conf

6. Forward Logs to a Remote Syslog Server

Many labs ask you to ship logs to a central host for aggregation. Add this line to a new file, say `/etc/rsyslog.d/30-remote.

*.* @192.0.2.10:514

• @ = UDP (use @@ for TCP).
• Replace 192.0.2.10 with your remote server’s IP.

Restart rsyslog again, then verify with tcpdump or by checking the remote server’s /var/log/syslog. If you see the lab’s test messages arriving, you’re golden It's one of those things that adds up..

7. Using systemd‑journalctl (Optional)

If your distro uses systemd-journald (most modern ones do), logs are also stored in a binary journal under /run/log/journal (volatile) or /var/log/journal (persistent). You can view them with:

journalctl -u rsyslog
journalctl -p err

To make the journal persistent, create the directory and restart:

sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald

The lab may not require this, but it’s good to know the two systems can coexist.

Common Mistakes / What Most People Get Wrong

1. Editing the wrong file – The default rsyslog.conf is still read, but any mistake there can override your custom rules. Always add new rules in /etc/rsyslog.d/ unless you have a reason to edit the main file.

2. Forgetting the dash before a log path – A leading - tells rsyslog to use asynchronous writes (faster, less safe on power loss). If you accidentally put a space before the dash, rsyslog treats it as part of the filename and silently drops the rule.

3. Not reloading after changes – systemctl restart rsyslog is required. Some people think service rsyslog reload works, but on newer systems it only reloads the configuration if the daemon supports it, and rsyslog prefers a full restart.

4. Mismatched facility/severity syntax – Using authpriv.* is fine, but authpriv.*.* will break the parser. Stick to facility.severity or the wildcard *.

5. Logrotate not notified – If you forget the postrotate script, rsyslog will keep writing to the old (now renamed) file, causing duplicate entries and huge disk usage.

6. Remote logging over UDP without firewall rules – UDP is connectionless; if the firewall blocks port 514, your packets vanish. Double‑check iptables or firewalld Which is the point..

Practical Tips / What Actually Works

• Keep it simple – One rule per file is easier to audit. If you need many destinations, consider using a template ($Template) instead of copy‑pasting lines.

• Use timestamps – Add $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat at the top of your config if you need the classic “MMM DD HH:MM:SS” format. It makes grepping far easier.

• Separate noisy services – Applications that spew debug info (e.g., cron on a busy server) should have their own log file with a higher severity threshold (cron.warn) Not complicated — just consistent..

• Compress early – Adding compress to logrotate saves space, but remember that compressed logs are not readable by tail. Use zcat or zless when you need to peek.

• Test with logger – The logger command is your best friend. It lets you fake any facility/severity without needing to restart services.

• Monitor disk usage – Set up a simple alert with df -h /var/log in a cron job. Nothing is more frustrating than a full root partition because logs weren’t rotated.

• Document your changes – Add a comment at the top of each custom config file: who added it, why, and the date. Future you (or a teammate) will thank you when the lab turns into a production environment.

FAQ

Q: Do I need both rsyslog and systemd‑journald?
A: Not necessarily. Most distros run both; journald captures everything first, then forwards to rsyslog if configured. You can disable journald forwarding by setting ForwardToSyslog=no in /etc/systemd/journald.conf, but keep it on for redundancy That alone is useful..

Q: How can I view only kernel warnings in real time?
A: journalctl -k -p warning -f or tail -f /var/log/kern.warn.log if you’ve set up a separate file That alone is useful..

Q: My remote syslog server isn’t receiving anything. What’s the first thing to check?
A: Verify network connectivity (ping/nc -vz <IP> 514), then confirm the firewall allows UDP/TCP 514. Finally, look at /var/log/syslog on the client for “error sending” messages Nothing fancy..

Q: Can I limit log size without using logrotate?
A: Yes, rsyslog has a built‑in omfile option FileSize that stops writing once a file reaches a threshold, but logrotate is more flexible and widely used.

Q: Is it safe to use UDP for remote logging?
A: UDP is faster but unreliable—packets can be dropped. For critical security logs, use TCP (@@remote:514) or even TLS (@@@remote:6514) if your server supports it And it works..

Logs are the lifeblood of any Linux system. Once you’ve got the 8.4.9 lab down—custom rules, proper rotation, and remote forwarding—you’ll find yourself spending far less time guessing and a lot more time actually fixing problems.

So next time a service misbehaves, open the right log file, read the line, and let the data tell you what’s wrong. Happy logging!