My First Linux Server

I have been running Ubuntu on my laptop for a while now, but that is a desktop distribution. It has a graphical interface, a nice file manager, and it holds your hand through most things. A real server is a completely different animal.

A professor in my department let me set up Red Hat Enterprise Linux on an old machine in the college lab. RHEL 5.2 came out a couple of months ago, and the college has a site license. This machine was just sitting in a corner collecting dust, so when I asked if I could use it, he said yes without much hesitation.

That was two weeks ago. I have learned more in those two weeks than in an entire semester of classes.

The Installation

Installing RHEL is not like installing Ubuntu. There is no friendly wizard that does everything for you. The installer asks questions that I had to look up on the spot. What filesystem type? What partition layout? Which package groups? Minimal install or full?

I went with a minimal install because everything I read online said that is the right way to set up a server. Only install what you need. Less software means fewer things that can go wrong, fewer security vulnerabilities, fewer updates to manage.

The machine booted into a black screen with a blinking cursor. No desktop. No icons. No mouse pointer. Just a login prompt. I typed in my username and password and got a command line.

This was it. This was the whole thing. Everything from here on out would be done by typing commands.

Learning Bash

I already knew some basic Linux commands from using Ubuntu. ls to list files, cd to change directories, cp to copy, rm to delete. But administering a server requires a completely different level of command line knowledge.

I learned about services and how to start and stop them. I learned about configuration files in /etc and how almost everything in Linux is configured by editing text files. I learned about file permissions, and why they matter so much on a server. I learned about cron jobs for scheduling tasks. I learned about logs in /var/log and how to read them to figure out what went wrong.

The text editor situation was an experience of its own. The server had vi installed, and vi is not intuitive. At all. The first time I opened it, I could not figure out how to type anything. Then I could not figure out how to quit. I literally had to open another terminal and look up "how to exit vi." I am not ashamed to admit this because I later found out that this is one of the most common searches related to vi. Apparently everyone goes through this.

I have been forcing myself to use vi because everyone says that once you learn it, it becomes incredibly fast and efficient. I am not at the "fast and efficient" stage yet. I am at the "accidentally deleting lines and having to undo" stage. But I am getting better.

Networking

The most exciting part has been networking. I configured the server to have a static IP address on the college network. I set up SSH so I could connect to it remotely from my laptop. The first time I SSHed into the server from across the hostel, I felt like a hacker in a movie.

I installed Apache and got a basic web page running. Then I opened a browser on my laptop, typed in the server's IP address, and saw the page. My page, running on my server, accessible over the network. It is a simple HTML page that just says "Hello from Lokesh's server" but I was unreasonably proud of it.

I also learned about firewalls. RHEL comes with iptables, and configuring firewall rules is both critical and terrifying. One wrong rule and you can lock yourself out of your own server. I know this because I did exactly that. I had to physically walk to the lab and log in at the console to fix it.

What I Broke

Let me list everything I broke during these two weeks because I think it is important to be honest about the learning process:

Locked myself out with a bad iptables rule (twice)
Accidentally deleted a system configuration file and had to reinstall a package to get it back
Set wrong permissions on /etc/shadow and could not log in until I booted into single user mode
Filled up the disk by not setting up log rotation and letting Apache access logs grow unchecked
Crashed the machine by trying to compile a program that consumed all available memory

Every single one of these was a learning experience. Every single one taught me something I will never forget because I had to spend hours figuring out how to fix it.

Why This Matters

I understand now why companies pay good money for Linux administrators. This is hard. There are a thousand things that can go wrong, and when they go wrong, there is no helpful error dialog with a "Fix it for me" button. You have to understand the system deeply enough to diagnose and fix problems yourself.

But there is something incredibly satisfying about it. When you type a command and something works, you know exactly why it works. There is no magic, no hidden layers of abstraction. You can trace every action through the system if you want to. The logs tell you what happened. The configuration files tell you what should happen. The man pages tell you how everything works.

I want to keep learning this. I want to understand networking deeply, learn about DNS and DHCP and all the protocols that make the internet work. I want to learn shell scripting so I can automate the repetitive tasks. I want to set up more services, maybe a mail server or a database server.

This old machine in the corner of the lab is the best learning tool I have ever had. Better than any textbook, better than any lecture. There is no substitute for getting your hands dirty and breaking things and fixing them.

I am going to keep breaking things. That seems to be how you learn.