Learning Python: A Journey Through Version 2.3.4

January 26, 2004

In the early days of 2004, I was knee-deep in a project that required me to automate some critical tasks using Python. The tech world was abuzz with open-source stacks and web development frameworks like LAMP (Linux, Apache, MySQL, PHP), but at work, we were still feeling our way around the new kid on the block: Python.

I had been tasked with creating a script that would periodically check the status of several servers and log any issues. This was no small feat in the days before robust logging tools like Splunk or ELK stacks existed. Back then, it was all about finding the right balance between reliability and simplicity.

The Setup

Our infrastructure was built on Xen hypervisors running Ubuntu 4.10 (Hoary Hedgehog). We were using Apache for our web servers, MySQL as our database back-end, and a mix of Perl scripts and shell scripts to handle various tasks. The plan was to integrate Python into this existing ecosystem.

The Challenges

One of the biggest challenges I faced was deciding which version of Python to use. At that time, we were still running Python 2.3 on our servers, but the latest stable release was 2.4. Many of the scripts and tools I had at my disposal required Python 2.3.x, so a major upgrade wasn’t trivial.

I spent several days reading through the changelogs and API documentation for Python 2.4, trying to identify any breaking changes that might affect our existing infrastructure. This was no small task, as many of the Python scripts I had were scattered across different directories and written by various developers over time.

The Script

After weeks of planning, I decided to start with a simple script to check server uptime. Here’s how it looked:

import os
import subprocess
from datetime import datetime

def check_server_status(server_ip):
    response = os.system("ping -c 1 " + server_ip)
    if response == 0:
        return True
    else:
        return False

def log_message(message):
    timestamp = datetime.now().strftime("%Y-%m-%d %H:%M:%S")
    with open("/var/log/server_health.log", "a") as f:
        f.write(f"{timestamp} - {message}\n")

servers_to_check = ["192.168.0.10", "192.168.0.11", "192.168.0.12"]

for server in servers_to_check:
    if check_server_status(server):
        log_message(f"Server {server} is up and running.")
    else:
        log_message(f"Warning: Server {server} is down.")

print("Server health checks completed at", datetime.now().strftime("%Y-%m-%d %H:%M:%S"))

The Debugging

Running the script on my local machine was a breeze, but when I tried to deploy it to production servers, issues started popping up. One of our servers was returning non-zero exit codes for ping, which meant that even though the server pinged successfully, Python wasn’t interpreting it as such.

After much head-scratching and print statements, I realized that we had some custom networking scripts that were modifying the behavior of the os.system command. Once I fixed those dependencies, everything worked smoothly.

The Outcome

The script ran reliably for a few weeks without any issues. It not only helped us keep an eye on our server health but also served as a good learning experience in Python scripting. Over time, we started using this script as the basis for more complex monitoring tools and eventually moved to newer versions of Python.

Reflections

Debugging and maintaining these scripts was challenging, especially when dealing with older versions of tools and languages. But it taught me the value of clear documentation and robust testing in development. As we continue to evolve our infrastructure, I know that the lessons from this project will help us better integrate new technologies while still respecting our existing legacy systems.

Python 2.3.4 might seem quaint today, but those days were full of learning and growing as a developer. Looking back, it was a crucial step in my journey toward mastering Python and becoming more efficient with automation tools.

---