So today is my first official day of getting back into IT. It’s been a busy one, but I’ve made good progress!
After several years working in mental health, getting back into the technical side of things feels like a big shift. I’ve still got experience to draw on from my earlier IT consulting and software-development work, but there’s plenty to refresh. Today was about giving that return some structure—and getting something real working.
First, a study plan I can actually follow
Before touching the server, I spent the first part of the day putting together a weekly study guide. I wanted a clear route through the material, with practical exercises, useful references and checkpoints to help me decide when I’m ready for an exam.
The result is a 78-week plan, running from November 2026 into May 2028. It includes 74 normal study weeks and four lighter holiday weeks, with roughly seven hours of study in the earlier phases and around nine in the more demanding Microsoft, cloud and DevOps blocks. There’s room to adjust the timetable as I find out where my strengths and gaps really are.
The certifications and exams I’m working towards are:
- LPI Linux Essentials — exam 010-200, covering the Linux and open-source foundations I want to make sure I understand properly.
- LPIC-1 — exams 101-500 and 102-500, moving further into Linux installation, administration, networking and security. LPI publishes the objectives for both exams.
- Microsoft Certified: Azure Fundamentals — AZ-900, building a foundation in cloud concepts and Azure services.
- Microsoft 365 Certified: Endpoint Administrator Associate — MD-102, focused on deploying, managing and securing modern endpoints.
- Microsoft Certified: Azure Administrator Associate — AZ-104, covering the practical administration of Azure infrastructure.
- Microsoft Certified: DevOps Engineer Expert — AZ-400, the longer-term goal, building on the Azure Administrator credential and further practical work with source control, automation and delivery pipelines.
That’s six credentials across seven exams. There’s also a practical container and automation block in the guide to support the later DevOps work. The exam dates are targets: I’ll use the readiness checks to decide when to book, and recheck the current exam versions and requirements along the way.
Building the Linux environment
With the guide ready, I moved on to the VPS—a virtual private server that would host this blog, its email service and the traffic reports. I had ChatGPT helping with planning, scripts and troubleshooting throughout the day, while I ran the administration through PuTTY and fed back the results. Working in stages made it much easier to see what had passed and where something needed another look.
1. Start with the server and secure access
The server is hosted with BinaryLane and runs Debian 13 “trixie”. I used PuTTY and PuTTYgen from my Windows PC to create an SSH key and connect to the server.
I set up a separate administrator account with sudo access, tested key-based login, and then hardened OpenSSH. That included disabling direct root login and password-based SSH authentication. I kept the existing session available while testing a fresh connection, so I could verify that the new settings actually worked before relying on them.
One of the early satisfying moments was trying a direct root login and having the server refuse it. A small test, but useful evidence that the change had taken effect!
2. Separate the provider, DNS and server settings
There were several different places to configure, each with its own job. BinaryLane manages the VPS, its external firewall and reverse-DNS settings. Crazy Domains manages the domain’s DNS records. Inside Debian, nftables controls the host firewall, while the individual services have their own configuration.
The website and mail hostnames needed address records pointing to the server. Email also needed an MX record to identify the receiving mail host, plus the relevant authentication records. The provider’s PTR record supplies the reverse-DNS name; that’s configured separately from the domain’s normal DNS records.
I matched the host firewall to the services I wanted reachable from outside. SSH remains available from changing client addresses using key authentication, while the database and internal mail-filtering services stay local. A DNS record gives a service a name; the firewall and service configuration still have to let the connection reach something that is listening.
3. Get WordPress working privately first
The web stack uses Nginx, PHP 8.4 with PHP-FPM, MariaDB and WordPress. I also installed WP-CLI, verifying its downloaded executable before using it to prepare WordPress.
I created a dedicated database and database account, generated the WordPress configuration and salts, and set ownership and permissions so the maintenance account could manage the application without making all the site files writable by the web server.
Initially, the site was only available on the server’s loopback interface. A PuTTY SSH tunnel let me open it in my local browser while it was still private. That uncovered a missing Nginx site configuration along the way: the tunnel could connect to SSH, but there was no web listener ready at its destination. Getting the listener configured brought up the WordPress installer.
4. Jump ahead to email when the website needed it
This was the first point where the order in the guide needed to change. I wanted to use my new domain email address for WordPress, so it made sense to get that mailbox working before finishing the website installation.
I moved ahead to the mail-server section and configured Postfix for SMTP, Dovecot 2.4 for mailbox access and authentication, and Rspamd for spam filtering and DKIM signing, using Redis as its data store for statistics, caching and rate limiting. Using documentation that matched Dovecot’s installed version was important, given the configuration changes in the 2.4 series.
There was more DNS work here too: SPF to identify the sending server, DKIM to sign outgoing messages, and DMARC to publish the domain’s authentication policy. I checked forward and reverse DNS, configured encrypted IMAP and authenticated SMTP submission, and tested sending and replying through two separate external accounts.
Seeing messages arrive and replies make it back was a good milestone. The mailbox was ready, and I could return to the WordPress setup using the address I actually wanted.
5. Publish the website over HTTPS
I used Certbot to obtain Let’s Encrypt certificates: one for the website names and a separate one for the mail hostname. With HTTPS configured and WordPress installed, I could log in to the dashboard over the public domain.
I then connected Jetpack and the WordPress connection to ChatGPT, testing it with an unpublished draft. That connection also helped with the site’s layout and content.
Jetpack initially hit an Nginx FastCGI response-header buffer limit. The error log gave us the useful clue, and adjusting the buffer settings cleared the connection problem. It was a reminder to check what the server actually reports when a browser error is vague.
The site itself now has a straightforward introduction alongside the latest journal posts, with clear publication dates. I wanted it to feel personal and give people an easy way to follow the weekly progress.
6. Add traffic reporting and test log rotation
For server-side traffic reporting, I installed GoAccess. Nginx records the original requested page paths and available referrers, with query strings removed before they are written to the dedicated access log. GoAccess builds a static dashboard every 15 minutes, and the report is protected by a separate password.
I also configured daily log rotation, retaining the current log plus up to fourteen daily archives. The report rebuild reads both current and rotated files, including compressed archives.
This produced one of the more useful troubleshooting lessons of the day. The first logging check needed to allow for Nginx’s workers changing over after a reload. Later, after rotating the log, the problem was permissions: Nginx’s workers couldn’t traverse the directory to reopen the new file. A narrowly scoped directory-access permission fixed that.
I followed up with a request from my Windows PC and verified that its public client IP, the requested page and a test referrer reached the report. That gave me evidence from outside the VPS as well as the local checks.
7. Make the services maintainable
With the website and mail working, I tested certificate-renewal simulations for both certificates, ran the existing deployment hook, and checked the certificates actually presented by HTTPS, SMTP and IMAP. Nginx, Postfix and Dovecot all had successful reloads recorded.
I configured Debian’s unattended-upgrades for daily security updates, automatic restarts of affected services and immediate reboots when an update requires one. I’m comfortable with that policy for this learning server, and checked that the main services are enabled to start at boot.
The final checks also caught a firewall-service detail. The rules were already loaded, but the nftables service was inactive. The saved configuration used a global flush that would have removed the separate mail-ban table managed by Fail2Ban. I changed the loader to replace only the main firewall table, preserving the mail-ban table, and tested a fresh SSH connection with automatic rollback available.
The final verification passed: the firewall, website, mail services and automation timers were healthy, with no failed services reported. There were no eligible security updates waiting, and the running kernel matched the installed kernel, so a reboot wasn’t needed.
How long did it all take?
I started working on the guide at around 11:00 am and had it ready by about 4:15 pm—roughly five hours and fifteen minutes of planning, checking and refining.
The server work ran from around 4:15 pm to 8:12 pm: three hours and fifty-seven minutes. That puts the whole day at approximately nine hours and twelve minutes.
The guide had allowed roughly 41 focused hours for its full initial server-setup block. Today’s working Linux environment came together in just under four hours of server work, helped considerably by having the study guide ready and using AI-assisted scripts. I’ll keep revisiting the configuration during the study weeks so I can explain it, troubleshoot it and repeat the work with increasing confidence.
Next stop: the Windows environment
I’ve got everything working where I want it, so my Linux learning environment is now ready. The next step is to build the separate Windows environment so I can continue towards my Microsoft certification alongside the Linux certifications.
It’s been quite a long day, and it feels good to have both a plan and a working place to begin. I think I’ve earned a well-deserved rest!
–Owen.