Data Engineering, Day 2: The Day the Terminal Stopped Feeling Like a Foreign Country

Day one was about learning to walk around the house. Day two was about actually turning the lights on and living in it.

I won't lie — I came into class still tired from yesterday, still slightly proud of myself for typing sudo correctly on the first try. And then day two happened, and it was a lot. Vim modes. A whole database engine. Remote connections. By the end of it my brain felt like a browser with forty tabs open. But it's the good kind of tired — the kind where you can actually feel yourself becoming someone who can do this job, one command at a time.

Here's everything we covered, with the actual commands, because future-me is going to need to come back and re-read this more than once.

1. Logging Into the Server Remotely, Again — But It's Starting to Click

We picked up right where day one left off: SSH-ing into our Ubuntu server.

ssh username@server_ip_address

Yesterday this felt like magic I didn't fully trust. Today it just felt like... opening a door. That's the moment you know something is starting to sink in — when the "wow" wears off and it just becomes muscle memory.

2. Creating Our Own Linux User, Setting a Password, Switching Between Users

Everyone in class created their own personal Linux user account on the server — no more sharing one login.

sudo adduser myusername

Setting or resetting a password for that user:

sudo passwd myusername

And then the part that actually made the concept of "users" feel real — switching between accounts on the same machine:

su - myusername

Typing su - anotheruser and suddenly being that person, with their own home directory and their own permissions, made something click. A server isn't one identity. It's a shared space with clearly separated rooms, and Linux is very serious about who's allowed in which room.

3. Meeting Vim (And Immediately Getting Humbled By It)

If you've never used Vim before, the first thing that happens is panic. You open a file, try to type, nothing happens, and you briefly wonder if you've broken the server. You haven't. You just don't know the modes yet.

Opening a file in Vim:

vim myfile.txt

The Four Modes We Learned

Normal mode — this is where you land the moment Vim opens. You're not typing text here; you're navigating and issuing commands. Pressing letters like h, j, k, l moves the cursor. This is the default, home-base mode.

Insert mode — this is where actual typing happens. You get here by pressing:

i

from Normal mode. Once you're in Insert mode, you type like you would in any normal text editor. You get back to Normal mode by pressing Esc.

Visual mode — for selecting text, the way you'd click-and-drag with a mouse anywhere else. Entered with:

v

From there, moving the cursor highlights text, which you can then delete, copy, or edit as a block.

Command-line mode — this is where the real power lives: saving, quitting, searching, and replacing. Entered by pressing : from Normal mode, which drops a colon prompt at the bottom of the screen.

Saving and Exiting (The Command Everyone Googles at Least Once)

From Normal mode, pressing : and then typing:

:w

saves the file. Typing:

:q

quits Vim. And the one everyone actually needs on day one — save and quit in one motion:

:wq

If you've made a mess and just want out without saving anything:

:q!

That last one saved me today. No shame in it.

4. Basic Linux Navigation Commands, Practiced Until They Felt Boring (In a Good Way)

We drilled the fundamentals again, and repetition is genuinely making them automatic now:

ls          # list what's in the current folder
cd projects # move into the "projects" folder
pwd         # print exactly where you are right now
mkdir data  # create a new folder called "data"
touch notes.txt   # create a new, empty file
cat notes.txt     # print the contents of a file to the screen
whoami      # confirm which user you're currently logged in as
clear       # wipe the terminal screen
sudo apt update    # run a command with administrator privileges
su - anotheruser   # switch to a different user account

Small, unglamorous commands. But every single one of them showed up again later in the day, embedded inside bigger tasks — which is exactly when you realize why the fundamentals matter so much.

5. Installing PostgreSQL and Checking That It's Actually Running

This is where the day shifted from "operating system basics" into genuinely feeling like data engineering.

Installing PostgreSQL on the Ubuntu server:

sudo apt update
sudo apt install postgresql postgresql-contrib

Checking whether the service is actually running:

sudo systemctl status postgresql

Watching that status come back "active (running)" for the first time felt disproportionately exciting for something so small. But it was the first real database engine I've ever installed with my own hands, not a hosted service someone else set up for me.

6. Controlling the PostgreSQL Service with systemctl

We learned the full lifecycle of managing the service, not just turning it on and hoping for the best:

sudo systemctl start postgresql     # start the service
sudo systemctl stop postgresql      # stop the service
sudo systemctl restart postgresql   # restart the service (needed after config changes)
sudo systemctl status postgresql    # check current status

restart became the command I'd use most, since almost every configuration change later in the day required PostgreSQL to reload before it would take effect.

7. Creating a Database, a Database User, and a Password

First, we switched into the built-in postgres system account, which has admin rights inside PostgreSQL itself:

sudo -i -u postgres
psql

From inside the psql prompt, we created a new database:

CREATE DATABASE mydatabase;

Then a new database user, with a password:

CREATE USER myuser WITH ENCRYPTED PASSWORD 'mypassword';

And gave that user full rights over the database we just created:

GRANT ALL PRIVILEGES ON DATABASE mydatabase TO myuser;

There's a genuine sense of ownership that comes from typing CREATE DATABASE and having it just... exist. Something I've queried a hundred times from the outside, and today I built one from the inside.

8. Getting to Know the Configuration Files: postgresql.conf and pg_hba.conf

This is the part that felt the most "real" — the two files that quietly control everything about how PostgreSQL behaves and who's allowed to talk to it.

Opening the main configuration file with Vim:

sudo vim /etc/postgresql/*/main/postgresql.conf

Inside, the key setting we needed was listen_addresses, which controls which network interfaces PostgreSQL accepts connections on. By default it's often locked to localhost, meaning nothing outside the server itself can reach it. We changed it to:

listen_addresses = '*'

Then the client authentication file, which controls who is allowed to connect and how:

sudo vim /etc/postgresql/*/main/pg_hba.conf

Here we added a line allowing remote connections from outside the server, authenticated with a password:

host    all             all             0.0.0.0/0               md5

Editing these two files back to back really underlined the point our instructor kept making: postgresql.conf controls how the server behaves, and pg_hba.conf controls who's allowed through the door. Two very different jobs, two very different files.

9. Restarting PostgreSQL So the Changes Actually Took Effect

None of those edits do anything until the service reloads:

sudo systemctl restart postgresql

This is the step it's easy to forget in the moment — you edit a config file, feel accomplished, and then wonder why nothing changed. Nothing changes until you restart the service.

10. Connecting Remotely with DBeaver and Power BI

This was the payoff for the entire day. After all the SSH, Vim, and config file editing, we opened DBeaver on our own laptops and connected straight into the PostgreSQL database sitting on the remote Ubuntu server — using the database name, username, and password we'd created ourselves earlier:

Host: server_ip_address
Port: 5432
Database: mydatabase
Username: myuser
Password: mypassword

Then we plugged the exact same connection details into Power BI, pulling that same PostgreSQL database in as a live data source.

Seeing our own database — one we built from an empty terminal, line by line — show up as a connectable data source in a tool like Power BI was the moment the whole day clicked into place. It wasn't abstract anymore. It was infrastructure we'd actually built, being used the way real infrastructure gets used.

What I'm Taking Away From Today

Yesterday was about learning to move around a Linux system. Today was about realizing that Linux is just the floor you stand on to build the things that actually matter — like a working database that other tools can plug into.

The instructor's closing note stuck with me: these fundamentals aren't a box to check once and move on from. Vim, navigation commands, PostgreSQL users and databases, pg_hba.conf, postgresql.conf — we're going to be living inside these for the rest of the program.

So tonight's homework to myself is simple: open Vim again, on purpose, just to practice switching modes until :wq stops feeling like a spell I'm reciting from memory and starts feeling like my own handwriting.

See you in the next class.