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