Lab server setup - Ubuntu 12.4

With a recent change of machines in the lab, I thought that I should update the backup server according to reflect the new machines. However, upon inspection the backup server OS hard drive had died long ago; but then what do you expect when you use 8 year old battered PCs as a server.

This wasn’t too much of a problem as the machine’s RAID array was otherwise fine, it just hadn’t been mounted in some time. And the lab machines all have their files safely on them still. So I thought I’d take the opportunity to bring new life to the server and update it. Something that had been on the list of things-to-do for a long time and I just hadn’t got there.

Server installation

I got a USB stick with the latest version of Ubuntu 12.4 LTS x64 and installed it onto the backup server on a fresh, new WD green drive. I used the standard desktop version and not the dedicated server or minimal install as frankly I cant be bothered with setting everything up from the command line and getting all the libraries, drivers, network connections, etc to work when the live disk just works.

After the fresh install I ran the usual

1
sudo apt-get update && sudo apt-get upgrade

And waited for it to pull the updates from the Ubuntu servers. Followed by:

1
sudo apt-get install synaptic

This just downloads the Synaptic package manager, which oddly isn’t included by default anymore by Ubuntu.

1
sudo apt-get install nfs-kernel-server nfs-client

All of the lab machines I’ve configured to use NFS shares to allow manipulation of files between them

RAID array configuration

Finally, I installed mdadm (md (multiple device) administrator) which allows for the mounting and control of hard drives into RAID arrays without expensive hardware controllers

1
sudo apt-get install mdadm

Annoyingly, the mdadm install requires the package sendmail, which is used for email notifications if a RAID array dies, however the sendmail installer is useless. It takes over the terminal window and needs you to set up some configuration settings but will not allow you a cursor. To solve this press “Tab” and suddenly the cursor selects the OK box and you can continue.

With mdadm installed I could now mount the RAID array, using a similar method to that described before, initially using Ubuntu’s Disk Utility program to gather which hard drives were allocated to which hardware address. My drives were located at /dev/sdb and /dev/sdc. So I could mount them using:

1
sudo mdadm --create /dev/md0 --level=1 --force --raid-devices=2 /dev/sdb /dev/sdc

Which created a single mdadm device (md0)

  • in a RAID 1 (--level=1)
  • from 2 disks (--raid-devices=2).

Now the device had been created it was mounted to a folder (having to specify the drives file system (ext4)

1
sudo mount -t ext4 /dev/md0 /media/raid

NFS mounting

As previously mentioned all the machines in the lab allow NFS sharing between them. So for each machine it was as easy as creating a new directory for each machine

1
mkdir /media/[machine to be added]

And then mounting the machine (make sure to configure firewalls appropriately)

1
mount [IP or DNS entry to machine]:/home /media/[machine to be added]

So something like

1
mount epr-PC1.department.uni.edu:/home /media/PC1

Running

1
df -h

Should now show that you have a NFS drive attached.

This is all very well and good, but all that we’ve done is mount the drive this time, but for a server in the event of power outage and reboot we want the drives to be automatically mounted. To do this we need to edit /etc/fstab and add a new line for each drive

1
2
3
[...]

epr-PC1.department.uni.edu:/home /media/raid/PC1   nfs   rw,sync,hard,intr   0   0

You can use different mount options if you like (look up man nfs), for example a backup server doesn’t really need write permissions.

Remote desktop

In Ubuntu’s menu select, Desktop Sharing, and select Allow others to view your desktop and Allow other users to control your desktop

Backup script

For the backing up scripts, see the next article


This page previously appeared on morganbye.net[^1][^2][^3]

[^1:] http://morganbye.net/lab-server-setup-ubuntu-12-4 [^2:] http://morganbye.net/2012/08/lab-server-setup-ubuntu-12-4) [^3:] http://morganbye.net/uncategorized/2012/08/lab-server-setup-ubuntu-12-4/

How do you define successful engineering leadership?

The Philosophy

Many view technical leadership as being the “smartest architect in the room.” I see it as the opposite. My job is to build a room where I don’t have to be the smartest person because the systems, culture, and communication are so robust that the team can out-innovate me.

The Strategy

  • Alignment: Does every engineer understand how their sprint task impacts the company’s bottom line?
  • Velocity vs. Stability: We aren’t just “shipping fast”; we are building a predictable, repeatable engine that doesn’t collapse under its own weight at the next order of magnitude.
  • The Human Growth Curve: Success is when the engineering team’s capability evolves faster than the product’s complexity. If the team feels stagnant, the tech stack will soon follow.

What is your approach to scaling technical organizations?

The Philosophy

Scaling isn’t just “hiring more people” - that’s often how you slow down. Scaling is about moving from Individual Heroics to Organizational Systems.

The Strategy

  • The 3-Continent Perspective: Having managed global teams, I focus on “High-Signal Communication.” As you grow, the cost of a meeting triples. I implement “Asynchronous-First” cultures that protect deep-work time while ensuring no one is blocked by a timezone.

  • Modular Autonomy: I advocate for breaking down monolithic teams into autonomous units with clear ownership. This reduces the “communication tax” and allows us to scale the headcount without scaling the bureaucracy.

  • Automation as Infrastructure: At petabyte scale, manual intervention is a failure. I treat the developer experience (CI/CD, observability, self-service infra) as a first-class product to keep the “path to production” frictionless.

How do you balance high-growth velocity with technical stability?

The Philosophy

Technical debt isn’t a “bad thing” to be avoided; it’s a set of historical decisions that no longer serve you. Like any loan, leverage can accelerate growth when investments payoff. But if velocity and returns are slowing you need a payment plan before the interest kills you.

The Strategy

  • The ROI Filter: I don’t refactor for the sake of “clean code.” I don’t refactor a micro-service with no users. I refactor when the pain on that debt - measured in bugs, downtime, or developer frustration - starts to exceed the cost of the fix.

  • Zero-Downtime Culture: Especially at scale, stability is a feature. I implement “Guardrail Engineering” where the system is designed to fail gracefully, ensuring that a Series B growth spike becomes a success story rather than a post-mortem.

  • The 70/20/10 Rule: I typically aim to dedicate 70% of resources to new features, 20% to infrastructure/debt, and 10% to R&D. This ensures we never stop innovating, but we never stop fortifying either.