Welcome to the deep dive today. We're really cutting through the noise to get right to the core of Linux.
Yeah, the foundations exactly.
Think of this as your essential guide, you know, understanding what makes a Linux system tick, right from power on to keeping your data safe. We're pulling insights from Steven Surring's LPIC one practice test, kind of a shortcut to those aha moments, but you know, without getting totally overwhelmed.
And that's key, isn't it, Because whether you're just curious or you actually manage Linux systems day to day, these concepts are well, they're fundamental to so much tech out there, ensuring i mean, twenty years in the field engineering Sissigmin Architecture author, Linux World editor. He's packaged up that.
Real world knowledge, but practical stuff.
Absolutely. Our mission here is to demystify Linux admin, give you a clear, solid understanding of how it all fits together, more than just definitions.
Okay, let's dive in. Then the machine's off, cold, silent. What's that very first spart? How does it even begin to wake up and become you know, Linux?
It's a really precise sequence, actually, almost like choreography. It starts way down low, with the BIOS or more commonly now UEFI firmware.
Right, the basic hardware stuff exactly.
That's the very first code that runs. It does its initial checks, then it hands control.
Over to the bootloader like GRUB.
Yeah, GRB legacy or GRB two are the most common examples. The bootloader's job is basically to find the operating system kernel and get it ready to launch.
Okay, so the bootloader finds the kernel, the heart of the OS. What's next? Does a kernel just take over?
It does, but there's another clever step. First, the kernel starts loading, but then it often relies on something called the intotramps in initial RAM file system. Yeah, it's a it's quite ingenious. It's a tiny temporary root filesystem loaded into memory, okay, because it contains just the essential drivers like for your discontroller needed to mount the actual root filesystem from your hard drive or ssd ah.
So it's like a temporary toolkit to access the main storage.
Exactly. It lets Linux boot on tons of different hardware before it can even fully see the main disc Super flexible.
That makes sense. Okay, kernels loaded, we've used the innatrams to find the real file system. How does it get ready for us? You know, start services, let us log.
In, right, that's the system initialization phase. The kernel. Once it's up, hands off control to the very first userspace process. Traditionally this was CISSV in it the old way, the older classic way. Most modern distries now use systems both fundamentally do the same thing though. Start all the necessary background services, mount file systems, listened in, et cetera. Get the network going, and bring the system up to a usable state.
Yeah, that first process, that's PID one.
That's the one process, ID one, whether it's sissv in it or systemed, it's the ancestor of pretty much everything else running on the system. A critical process.
Got it. So these in its systems bring things up? Can you tell Linux how to come up? Like different modes? Sometimes I just need a command line for fixing things.
Absolutely. That's where run levels in cissp in it or boot targets in systems come in. They define different operational states.
Like safe mode and Windows sort of.
Kind of analogous. Yeah, you have single user mode that's often run level one or rescue dot target. It's minimal, usually no networking, just a rootshell, perfect for maintenance. Okay, then you've got your typical states like a multi user command line environment run level three or multi user dot target or the full multi user graphical desktop run level five or graphical dot target.
And if things go wrong during boot where I want to change the default state, what tools do I use?
Good question? For diagnosing boot issues, DMEs is invaluable. It shows you the kernel's messages right from startup. You can see hardware detection, driver loading errors.
Okay.
On system systems general, pizerl is your main log viewing tool. It's incredibly powerful for seeing what happened during boot, checking service status everything.
Right, systems journal YEP, and to.
Manage services and targe gets use system tail like system taitl. Set default graphical dot target makes it boot to the desktop by default.
And rebooting is it just pulling the plug?
Haha? Please don't. The class command is in its six or with systemed system tel to reboot is the standard way graceful shut down and restart and.
A quick troubleshooting tip from the source. Ah yes.
If a hard disk isn't even showing up in Linux like DMAs doesn't see it, the first place to check is often the system bios or UF five setup. Linux can't see hardware. The firmware doesn't recognize first.
Makes sense, starts the lowest level. Okay, so the system's alive. But how does Linux organize everything? It feels very structured compared to say, Windows drive letters.
It is, and that structure is key. It's largely governed by the Filesystem Hierarchy Standard, the FHS FAHS. Yeah, it's a standard that defines where specific types of files and directories should live. It provides consistency across different Linux distributions.
So it's at or always means configuration.
Files more or less exactly. That predictability is a huge advantage for anyone managing Linux systems. You know where to look for things.
So walk us through some of the big ones. The really critical directories defined by the FAHS.
Heay top level is bull the root file system. Everything absolutely, everything stems.
From there, the single slash YEP.
Then boot is crucial. It holds the kernel itself. The any tramps we talked about, bootloader can figs like grub dot cfg. You don't want to mess that up, definitely. Not et cetera is where system wide configuration files live, things like etcetera, STAB, for filesystem mounts at tetcresolve dot com for DNS network settings, service can figs it's the control center.
Got it can figs and ACCA.
Home is where user directories are typically created, so you'd have homilis home Bob containing their personal.
File and stuff that changes a lot, like logs.
That goes in VAR for variable data. Varlog is the standard place for system logs. You also find things like mailspools and varspool temporary files used by services, database files sometimes okay var.
For variable stuff. What about US? I see that everywhere?
S tor often pronounced user, though historically it's good for Unix system resources. Holds most user installed applications and shared libraries, documentation, etc. It's usually one of the largest directories.
And USB drives. Where do they pop up?
The FHS designates media as the standard mount point for removable media. Some systems might also use run media or other locations, but media is the traditional FAHS spot.
This structure feels really logical. Now thinking about the actual discs, How does Linux lay them out? Partitions and such?
Yeah, good disc layout is important. You typically partition your drive to create separate filesystems for different parts of.
The hierarchy, like a separate partition for home.
Exactly or for VAR or t pay. It helps with organizations security and performance. If VAR fills up with logs, it won't crash the whole system by filling the root file systems Smart end swap space AH swap space essential. It's disc space that Linux uses as virtual memory when your physical ram gets full. It's slower than obviously, but it prevents the system from crashing due to lack of memory. Usually it's on its own partition okay.
And for booting with UEFI you.
Need an EFI system Partition or ESP is usually formatted as FA thirty two, surprisingly not a native Linux file system. That's where the bootloader lives.
For UAFI systems, FAT thirty two. Interesting and partitioning schemes MBR versus GPT.
Right MBR Masterboot Record is the older style. It has limitations, most notably a two terabyte limit on perkission size. GPT Goid Partition Table is the modern standard. Supports much larger disks and more partitions. You'll use GPT on almost any modern system.
Good to know, especially with big drives now okay, shifting gears slightly hard links versus symbolic links. This trips people up, it can.
Yeah, they're both ways to refer to files, but they work differently. A hard link is essentially another name for the exact same file data another name.
Yeah.
Imagine if files data has an ID number on the disc an eNode number. A hard link is just another directory entry pointing to that same inode.
So deleting one hard link doesn't delete the file.
Not if other hard links to that inode still exist. The data only gets removed when the last link pointing to it is gone. And crucially, hard links must be on the same filesystem because inode numbers are filesystems specific.
Okay, So what's a symbolic link.
Then, symbolic link or simlink or soft link. It's more like a pointer or a shortcut. It's a small file that simply contains the path to another file or directory.
Huh, like a window shortcut.
Exactly like that. It has its own inode number. It just points somewhere else. This means sim links can cross filesystems, but if you delete the original file, the sim link becomes broken. It points to.
Nothing, and you create those with ln ns.
Yep LNS target link name very useful.
Okay, and tools for managing disk space.
DF shows DISC free space on mounted filesystems. D estimates DISC usage for files and directories. Very handy for finding what's eating up space, DPN.
Do got it? And creating filesystems.
Use MKFS commands like nkfs dot e st four to create an XT four filesystem, or mk swap to prepare a partition for swap space.
And making sure they mount automatically.
That's etc. F STAB. That file lists all the file systems the system should mount at boot time, where to mount them, and with what options critical canfig file?
All right, we understand the layout. Now how do we actually talk to the machine? The command line right?
Absolutely, the command line interface or a CLI is where the real power lies in Linux administration. It's not just an afterthought, it's central.
So the basics moving around listing files.
Your bread and butter. Dot LS to list files, CD to change directory, MV to move a rename, CP to copy, RM to remove. You'll use these constantly. PWGAWD prince your present working directory tells you where you are, and history is amazing shows you your previous commands. Let's you reuse them easily. Huge time saver.
Yeah, history is great, but the real magic happens when you chain commands, doesn't it. Pipes and redirects.
Oh absolutely, that's where the CLI really shines. Streams, pipes and redirects let you build complex workflows from simple tools.
Okay, break down redirects first.
The symbol right redirection controls where output goes. By default, commands send output to your screen, st doo et and errors to your screen too. Std err redirects stdu to a file. Overwriting it appends stdog to a file and errors. You can redirect sddoo using two for example, command to error dot log. A common trick is command output dot log two on one, which sends both stdou and st r to the same file.
Okay, two in one for combined output. Now, pipes, the vertical.
Of art pipes are incredibly powerful. They takes the standard output of the command on its left and feeds it directly as standard input to the command on its right. It lets you chain commands together.
Can you give that example from the source again? The password file one?
Sure. Let's say you want a sorted list of just the user names from etcter password. You could do cat et cetera. Password a SF print one.
Dollars, Sort okay, walk me through.
It, kat, etc. Password displays the file content stdo ut right. That output is piped into oc ocdash xcdof tells OC to use a colon as the field separator. Print one dollar tells OC to print only the first field the username from each line.
Okay, so now we have just user names exactly.
And that list of user names ox stdout is piped into the sort command, which sorts them alphabetically. The final sordid list appears on your screen.
Wow, simple commands, complex result. That's cool.
It really is. That composibility is a core Linux philosophy. Oh and T is useful too. It reads from standard input and writes to both standard output and one or more files like a T junction for data streams.
Handy for seeing output while also logging in. Okay, command line basics covered. What about installing software? It's different on different Linux types, right, it is.
That's a major distinction. You generally have two main families or ecosystems for package management. Family one Debian based systems think Debian, Oupa to Mint. They use dot deb package files. The low level tool is dpkg gpeg, but you usually interact with higher level tools like app get or the newer often preferred app. They handle dependencies automatically fetching packages from repositories defined and at capsources dot list.
You're right apped update first.
Usually Yeah, app update or act get update refreshes the list of available packages from the repositories before you install or upgrade anything.
Okay, Debianfamily, dot, DPKG, app dot deb files at caapsources dot list.
What's the other big one, the red Hat based systems. It's RedHat Enterprise Linux, r h e L, Fedora, Sentos, sec Linux uses it to They use dot rpm package files. The low level tool is RPM. The higher level tools are typically YUM older or its successor, d n F, s U s C and opencus use zipper like APPED. These handle dependencies and use repositories configured in places like at CHAM dot COF or files in at CM dot, rebos, dot.
D SO, yum in package or DNF info.
Package exactly to get information about a package before installing it. Understanding which system you're on, Debian based or red Hat based is crucial for managing software effectively.
Makes sense and other useful command line tools for finding things or searching. Oh, yeah.
Find is incredibly powerful for locating files based on name, type, size, modification, time, permissions, anything you can think of. And REP is essential for searching inside text files for specific patterns using regular expressions.
Find and GP got them.
Yeah.
Okay. Let's shift to system administration and crucially security.
Very important topics. Let's start with user and group management. Linux is multi user from the ground up. Commands like user rat right, user red, user mod, modify, user BETL delete, same for groups, group head, group mod group doll managing who can access the system and what they.
Can do, and the key files here it's set our pass group.
Yes, it's setter pass roots stores basic user info username, user id, UID, group id GID, home directory path default show. Well it's readable by.
Everyone, but not the passwords.
Critically no, the encrypted passwords are an et ceter shadow. This file is only readable by the root user. That's a fundamental security features shadow passwords.
Oh okay, shadow for passwords.
What else, ETCETERA group defines the groups and their members, and it setuskool is neat. It's a skeleton directory. When you create a new user with USAD, the files in its siscle are copied into their new home directory, providing default canfigs or files.
Like default that bashshack maybe.
Exactly insures consistency. And if you want to check password policies like explanation dates, the change command change h L username shows password, aging info, last change, expiry date, et cetera very.
Useful, good one. What about automating task running backups every night?
That's where scheduling comes in. The classic tool is krawn. It runs commands or scripts on a schedule a minute, hour, day of month, month, day.
Of week, defined in crontab files yep.
Each user can have their own cron tab and there are system wide chron jobs defined in et cetera cantab or files within et ceter used for log rotation, backup system checks all sorts of things.
And if I just want to run something once.
That's the job for AT. You can say at now plus one hour and then type the commands you want or run in an hour. Simple but effective for one off.
Delayed tasks and the system's way.
System timer units. They're the modern approach, more flexible than kron, integrated with system services offer finer control. They're becoming the standard way to schedule tasks on systems systems.
Okay, let's talk host security. What are the absolute must knows?
Well, we mentioned shadow passwords, keep et cetera, shadow secure, that's number one. Number two, use pseudo. Don't log in as route directly unless absolutely necessary. Pseudo lets authorized users run specific commands as route or another user temporarily.
And editing the pseudo rules.
Always use vesudo, Never edit et cetera, seriers directly with the text editor. Pisudo locks the file and performs syntax checking before saving. This prevents you from making a mistake that locks you out of Pseudo entirely. Tip the pseudo absolutely critical another useful security measure, especially during maintenance. Touch its knowledge in this knowlogy Yeah, if that file exists, only root can log in. It displays the contents of the file to users trying to log in non route.
It's a simple way to keep users off while you're doing major work. Just remember to remove it when you're done. Good temporary lockout and generally minimize your attack surface. Turn off any network services you don't absolutely need. Every listening service is a potential entry point.
Solid advice. How about securing data and communications?
Encryption SSH secure shell that's the standard for secure remote logins, command execution, and file transfers like cit AP or.
SFTP uses key pairs right.
Yes, public private key pairs. You generate them with shurch keysen. Put your public key in the dotch authorized keys file on the server, keep your private key safe, and you get secure often passwordless.
Access and graphical apps remotely.
SSH can do x eleven forwarding on a graphical program on a remote server, but have its window displayed securely on your local desktop.
Very handy, cool and for encrypting files themselves.
Et IPG or GPG. It's the standard tool for encrypting, decrypting, signing, and verifying files and messages using public key cryptography. Essential for data confidentiality and integrity.
GPG Yeah, got it? Any other useful DMin security tools.
To end attention wallets, you send a quick message to the terminals of all logged in users. Good for broadcasting systems, shut down warnings, okay, and end map. It's a powerful network scanner used to discover hosts on a network, see which ports are open, identify services running. It's essential for security auditing, understanding what's exposed.
Network mapping makes sense. Wow, we've covered a lot of ground. We really have from the boot process, the file system, structure of the command line, power package management, user admin security. Oh, it's a pretty comprehensive.
Look under the hood, it is, and like you said, drawing from that LPIC one material gives a really solid press pactical foundation. But you know, this deep dive, it's really just scratching the surface. Linux is vast, but hopefully this gives you a much better framework for understanding how these core pieces work together. The key is to keep exploring, keep asking questions.
Definitely, and as you do, maybe consider this, how do those fundamental Linux principles like modularity, you know, six v in it versus system or using separate partitions. How does that and the reliance on plaintext canfig files we saw on etc and the FHS contribute to its incredible longevity and adaptability.
Right from tiny embedded systems to massive cloud exactly.
So, what other sort of hidden design ideas might be shaping the tech you use every day and how can understanding them empower you? Something to think about