Speaker 1: Welcome to the deep dive. This is where we take
Speaker 1: those really comprehensive system administration guides, the ones that are
Speaker 1: you know, packed with practical knowledge, and we boil them down.
Speaker 1: We focus on the foundations you really have to.
Speaker 2: Get right exactly, and today we're tackling red hat enterprise
Speaker 2: Linux aid administration.
Speaker 1: Our source material is, well, it's a pretty deep guide
Speaker 1: to mastering RHL.
Speaker 2: Eight right, and our goal here is specific pull out
Speaker 2: that essential day one knowledge, the stuff that really defines
Speaker 2: professional it work using Linux.
Speaker 1: We're going beyond just listing commands. We want the best
Speaker 1: practices for the command line, managing users securely, understanding modern
Speaker 1: system services.
Speaker 2: Yeah, we're aiming for clarity, trying to cut through the
Speaker 2: jargon and give you a solid base. We'll cover navigating
Speaker 2: the system, how permissions actually work, and you know what
Speaker 2: RHL eight does under the hood, because.
Speaker 1: Getting these fundamentals right from the start that's key, isn't.
Speaker 2: It absolutely critical. It's the difference between a system that
Speaker 2: runs smoothly for years and one that just becomes a
Speaker 2: tangled mess later on. Doesn't matter if it's physical, VM cloud,
Speaker 2: these basics save you headaches down the line.
Speaker 1: Okay, let's get into it, starting where every admin spends
Speaker 1: their time, the command line.
Speaker 2: The shell right, Linux is multi user from the ground up,
Speaker 2: and that means understanding the difference between a regular user and.
Speaker 1: Well, the boss for Route account.
Speaker 2: Precisely, your regular user account operates with limited privileges. But
Speaker 2: Root internally known as user ID zero, that's the super user.
Speaker 2: It has total control, absolute power over the system.
Speaker 1: And there's a really simple visual cue for this, right.
Speaker 1: Don't think you have to burn into your brain.
Speaker 2: The command prompt, that's it. If you're a regular user,
Speaker 2: you see a dollar sign a lot, but if you're
Speaker 2: logged in as Root, that prompt changes immediately to the
Speaker 2: hash symbol hashtag.
Speaker 1: That's the warning sign.
Speaker 2: That's the big red flashing light. Seeing that hashtag means
Speaker 2: one typo could wreck your system. So extreme caution is mandatory.
Speaker 2: No ifs ands or butts.
Speaker 1: So if I'm logged in as say myself, a regular user,
Speaker 1: and I need to do something administrative or maybe just
Speaker 1: switch to another user account temporarily, you.
Speaker 2: Use the sum command substitute user. Okay, And here's the kicker.
Speaker 2: If you are already Route, you can use SUN to
Speaker 2: become any other user on the system just by typing
Speaker 2: so username you don't need their password.
Speaker 1: Wow. Okay, that really shows the power of root.
Speaker 2: It absolutely does, and using SO with the DASH is
Speaker 2: important too. It properly initializes the new user's environment, like
Speaker 2: environment variables and paths.
Speaker 1: Right. Speaking of the environment, let's talk about the Linux philosophy.
Speaker 1: Everything is a file, even things like disks or running processes.
Speaker 2: Yeah, that's a core concept. Your hard drives show up
Speaker 2: under DEV, running process info is under PROC. It's all
Speaker 2: represented in the file system.
Speaker 1: And before we run commands, effectively, we need to understand
Speaker 1: environment variables. You mention them, what are they and like,
Speaker 1: how do we see them?
Speaker 2: They're basically name settings that control how your shell and
Speaker 2: other programs behave. Think of them as personalization. The easiest
Speaker 2: way to see one is with the echo command, So
Speaker 2: echoshell will tell you which shell program you're actually using
Speaker 2: maybe Bash maybe.
Speaker 1: And echo path. That one's important.
Speaker 2: Crucial. Path is a list of directories. When you type
Speaker 2: a command, the shell looks through those directories in order
Speaker 2: to find the program. If it's not in your path,
Speaker 2: you have to touch the full location like has been
Speaker 2: some command.
Speaker 1: Got it? So the environment dictates what's easy to run.
Speaker 1: Now navigating this file system which starts at the root directory.
Speaker 1: Any shortcuts for speed?
Speaker 2: Definitely, you absolutely need to know tilled for your home directory,
Speaker 2: right for the current directory you're in, and DOTT for
Speaker 2: the directory one level up the parent directory.
Speaker 1: Standard stuff but essential.
Speaker 2: But the real game changer. Bash autocomplete using the tab key.
Speaker 1: Ah. Yes, this saves so much time.
Speaker 2: It's incredible. Hit tab once and if the command or
Speaker 2: file name you started typing is unique, Bash just fills
Speaker 2: it in for you instantly, and if it's not unique,
Speaker 2: hit tab twice. Bash will then list all the postile
Speaker 2: completions right there for you. Works for commands, file names,
Speaker 2: directory paths. Everything cuts down typos dramatically.
Speaker 1: Don't forget history either, Oh absolutely.
Speaker 2: The history command shows you your previous commands. You can
Speaker 2: easily rerun complex ones about typing them all over again.
Speaker 2: Super useful.
Speaker 1: Okay, so we can find commands run them. Now. What
Speaker 1: about managing the output? That's where IO redirection comes in
Speaker 1: the standard streams.
Speaker 2: Yep, there are three main ones. STDOU standard output that's
Speaker 2: the normal results of a command. Okay, stir R standal
Speaker 2: error that's where error messages go. They're kept separate right,
Speaker 2: that's useful, and STDI and standard input, which is where
Speaker 2: a command can receive data from.
Speaker 1: And we use special symbols to redirect these exactly.
Speaker 2: The greater than symbol S sends stdou to a file
Speaker 2: overwriting anything already there.
Speaker 1: Careful with that one very careful.
Speaker 2: Double greater then ed does the same, but appends the
Speaker 2: output to the end of the file, which is often
Speaker 2: safer and error.
Speaker 1: How do we handle STDR.
Speaker 2: You use two. The two club refers specifically to stur
Speaker 2: so command two air loog dot txt sends only the
Speaker 2: error messages to that file, leaving the normal output stdout
Speaker 2: on your screen or letting you redirect it elsewhere.
Speaker 1: That separation is really powerful for scripting, which brings us
Speaker 1: to the pipe operator, the vertical bar ah the pipe.
Speaker 2: This is where Linux command line power really shines. It
Speaker 2: takes the stdot of the command on its left the
Speaker 2: normal output right and directly connects it or pipes it
Speaker 2: right into the stdo end of the command on.
Speaker 1: Its right, so you can chain commands together.
Speaker 2: Precisely without needing temporary files cluttering things up. You gave
Speaker 2: a great example earlier finding specific files.
Speaker 1: Like counting certain files under source.
Speaker 2: Yeah, you can do. Find a source to list everything.
Speaker 2: Pipe that output into rep keyword to filter for lines
Speaker 2: containing your keyword. Then pipe that output into WCSHL to
Speaker 2: count the lines.
Speaker 1: Find repwcdshel one line no tem files super efficient.
Speaker 2: That's the beauty of it. Small tools chain together incredible.
Speaker 1: Okay, let's move into section two, Security and access management.
Speaker 1: We've talked about the immense power of root that naturally
Speaker 1: leads to needing ways to manage permissions carefully.
Speaker 2: It forces you into that least privileged mindset. You just
Speaker 2: can't run everything as root. The risk is way too.
Speaker 1: High, which brings us to the standard POSX permissions, user group,
Speaker 1: other UGO.
Speaker 2: Right, every file and directory has an owner, user, and
Speaker 2: associated group, and then permissions for others everyone else.
Speaker 1: We usually see these as RWX read, write, execute, but
Speaker 1: the system often uses numbers octal notation. Quick reminder on.
Speaker 2: That ezpz read is four, write is to execute is
Speaker 2: one at them up yep sox is four plus two
Speaker 2: plus one annual seven artipsx is four plus zero plus
Speaker 2: one E plus five r is just four. So a
Speaker 2: common permission like rwxrxrx is.
Speaker 1: Seven for the user r wx five for the group
Speaker 1: RFX and five for others RX. So seven fifty five
Speaker 1: you got it. Seven. Now there are some special permissions too.
Speaker 1: What's one administrators really need to understand, especially regarding shared directories.
Speaker 2: Ah, you're probably thinking of the sticky bit.
Speaker 1: That's the one represented by a t right.
Speaker 2: You often see it on world writable directories like TAMP.
Speaker 2: When the sticky bit is set on a directory, it
Speaker 2: changes the rules slightly. How So, even if everyone has
Speaker 2: right permission in the directory, a user can only delete
Speaker 2: or rename files that they themselves own inside that directory,
Speaker 2: or the owner of the directory can of course.
Speaker 1: So it stops users from messing with each other's files
Speaker 1: in a shared space like TIAM.
Speaker 2: Exactly prevents accidental or malicious deletion of files you didn't create.
Speaker 1: Okay, So to maintain that least privilege idea, we don't
Speaker 1: want users logging in as root all the time or
Speaker 1: even using sue constantly.
Speaker 2: That's where pseudo comes in precisely. Pseudo superrouser do it
Speaker 2: lets a permitted user run a specific command as another user,
Speaker 2: usually as root.
Speaker 1: And the key difference from just using.
Speaker 2: Sue auditability pseudologs who ran what can when and as
Speaker 2: whom it's all about accountability. Using SUE to become root
Speaker 2: gives you a rootshell, and then it's harder to track
Speaker 2: exactly which commands we're run with elevated privileges.
Speaker 1: And by default, who gets to use pseudo?
Speaker 2: By default in RHL, root can use it naturally and
Speaker 2: any members of the administrative wheel group. So managing membership
Speaker 2: of the wheel group is a key security control point.
Speaker 1: It makes sense now managing the users themselves over time
Speaker 1: life cycle management. How do we enforce things like password changes?
Speaker 2: RHL provides the change command for that change age. Okay,
Speaker 2: you use it to set password aging policies for users.
Speaker 2: Key options are dash M for the maximum number of
Speaker 2: days a pathword.
Speaker 1: Is valid before they must change it right.
Speaker 2: H i S sets how many days the account can
Speaker 2: be inactive after password expiry before it gets locked automatically.
Speaker 1: Enforcing these really helps maintain security hygiene definitely.
Speaker 2: It protects against stale accounts and forces regular password updates.
Speaker 1: And what if you need to lock an account immediately,
Speaker 1: say someone leaves the company?
Speaker 2: Quickest way is user mod dash L username.
Speaker 1: The ash L is for a lock and what does
Speaker 1: that actually do under the hood? Is there something visible yep.
Speaker 2: If you were to look in the accept shadow file
Speaker 2: where the encrypted password hashes are stored, locking the account
Speaker 2: inserts an exclamation mark ah right at the beginning of
Speaker 2: the password hash.
Speaker 1: Field AH, so it invalidates.
Speaker 2: The hash exactly, makes it impossible to authenticate with that
Speaker 2: password until an admin unlocks it using user mod dushu.
Speaker 2: It's instant and effective.
Speaker 1: Okay, fascinating. Let's move into section three the more modern
Speaker 1: system operations in RHL eight. Let's talk systemed. It replaced
Speaker 1: the older in its systems. Why was that necessary? What
Speaker 1: problem did it solve?
Speaker 2: The big one was boot time. Older systems like cisvin
Speaker 2: it booted sequentially. Service A had to fully start and
Speaker 2: report success before service B could even begin loading, creating bottlenecks,
Speaker 2: huge bottlenecks, especially on systems with many services. It led
Speaker 2: to really long boot times. System, which runs as PID one,
Speaker 2: the very first process started by the kernel, tackles this
Speaker 2: using parallel processing.
Speaker 1: It manages things through units.
Speaker 2: That's the core concept. Everything system manages is a unit.
Speaker 2: There are service units for demons, socket units for network sockets,
Speaker 2: target units, which are like groups of other units similar
Speaker 2: to run levels. Timer units.
Speaker 1: Timer units what are those? For?
Speaker 2: System? Timers are essentially the modern integrated way to run
Speaker 2: jobs periodically. They replace the traditional Kron demon for many tasks.
Speaker 1: Uh, like cron jobs, but managed by systems. Yeah. Any
Speaker 1: common examples.
Speaker 2: A good one is f strem dot timer on systems
Speaker 2: with SSDs. This timer usually runs weekly to trigger the
Speaker 2: strum command, which tells the SSD controller which blocks are
Speaker 2: no longer in use, helping maintain performance. It's managed entirely.
Speaker 1: By systems, so more robust than Kron.
Speaker 2: Perhaps generally Yes, better logging, integration, dependency management, that kind
Speaker 2: of thing.
Speaker 1: Okay, let's pivot slightly. Time synchronization. Why is having accurate
Speaker 1: time so critical on network systems?
Speaker 2: Oh, it's non negotiable. Think about logs. If your server's
Speaker 2: clocks are out of sync, correlating events across machines to
Speaker 2: troubleshoot an issue becomes a nightmare maybe impossible, And many
Speaker 2: security protocols like cerberos rely heavily on tightly synchronized time.
Speaker 2: If clocks drift too far apart, authentication just fails. Financial
Speaker 2: transactions databases, accurate time is fundamental.
Speaker 1: And our HL eight uses crony for this.
Speaker 2: Yes, Crony is the default NTP Network Time Protocol client
Speaker 2: and server.
Speaker 1: Now, there's something interesting about how CRONY handles time adjustments,
Speaker 1: isn't there. It doesn't just jump the clock.
Speaker 2: That's a key insight. Yeah, Crony is designed to be
Speaker 2: very application friendly. After it gets an initial sink, if
Speaker 2: it detects the system clock is drifting, it generally avoids
Speaker 2: making a sudden, large jump or stepping the clock.
Speaker 1: What does it do instead?
Speaker 2: It slightly adjusts the rate at which the system clock runs,
Speaker 2: making it run a tiny bit faster or slower until
Speaker 2: it smoothly convert with the reference time source.
Speaker 1: So it maintains a continuous flow of time from the
Speaker 1: OS and application.
Speaker 2: Perspective, exactly, it prevents those sudden time shifts that could
Speaker 2: confuse applications that rely on steady time progression, like databases
Speaker 2: or real time monitoring systems. It prioritizes continuity.
Speaker 1: Very clever. Okay, last bit in this section basic resource checks.
Speaker 1: What are the go to commands?
Speaker 2: For a quick look? Free gives you memory and swap
Speaker 2: usage and df disc free shows you disk space usage
Speaker 2: per file system usually DFH for human readable sizes.
Speaker 1: Simple but essential. Now what happens when the system runs
Speaker 1: at a RAM.
Speaker 2: There's something called the O and killer ah, yes, the
Speaker 2: out of memory killer. When the kernel detects its critically
Speaker 2: low on memory, the OM killer activates. Its job is
Speaker 2: to pick one or more processes and terminate them to
Speaker 2: free up memory and hopefully save the system from crashing entirely.
Speaker 1: But it can pick the wrong process, right, I've heard
Speaker 1: horror stories.
Speaker 2: It absolutely can. The OM killer uses heuristics, but it
Speaker 2: might kill your critical dayatabase to save a less important
Speaker 2: web server worker, for example. It prioritizes freeing memory and
Speaker 2: not necessarily preserving the most important service.
Speaker 1: So why would an admin sometimes choose to make the
Speaker 1: system crash instead using panic.
Speaker 2: It sounds counterintuitive, but in some high availability scenarios, a
Speaker 2: controlled crash is better than unpredictable behavior. Setting paticonum tells
Speaker 2: the kernel, if you run out of memory, just panic
Speaker 2: and crash the whole system immediately.
Speaker 1: Why is that better?
Speaker 2: Because a crash often generates a core dump, a snapshot
Speaker 2: of the system's memory state at the time of failure.
Speaker 2: This gives you detailed forensic data to analyze why it
Speaker 2: ran out of memory. Letting the OME killer randomly killed
Speaker 2: processes can lead to a cascade of failures that's much
Speaker 2: harder to diagnose after the fact. It's about getting reliable
Speaker 2: data from the failure.
Speaker 1: Okay, that makes sense in critical environments. Let's move to
Speaker 1: our last section, Section four. Hardening and newer technologies. Standard
Speaker 1: file permissions ugorics are called discretionary access control or DAC.
Speaker 1: What is selenic?
Speaker 2: Adding on top of that, Selenic Security Enhanced Linux provides
Speaker 2: mandatory Access control MAC. It's an additional layer of security enforcement,
Speaker 2: managed by policy, not just by the file owner.
Speaker 1: How does it work? Conceptually?
Speaker 2: It works by confining processes. Each process runs in a
Speaker 2: specific security context or domain, like HTTDT for the Apache webserver.
Speaker 2: SELNX policy then dictates exactly what resources, files, ports, other
Speaker 2: processes a process in that context is allowed to interact
Speaker 2: with regardless of the standard Linux permissions.
Speaker 1: So even if a file is world readable, SELENICX might
Speaker 1: stop the webserver from reading it if the policy doesn't
Speaker 1: allow it.
Speaker 2: Precisely, it enforces the principle of least privilege at a
Speaker 2: much deeper level based on system wide policy.
Speaker 1: Now, SELinux has a reputation, let's say, for causing headaches
Speaker 1: during troubleshooting, the temptation is just to turn it off.
Speaker 1: Why is that usually a terrible.
Speaker 2: Idea because you're essentially disabling a massive part of the
Speaker 2: system's defense. Most Selenix problems aren't bugs in silinicx itself.
Speaker 2: They're usually caused by files having the wrong security context label, like.
Speaker 1: If you moved web content into placing.
Speaker 2: Correctly exactly, or installed software in a non standard location.
Speaker 2: The fix isn't set in forth zero disabling it. The
Speaker 2: fix is usually to restore the correct file context using
Speaker 2: restore con or maybe tweak a specific policy rule using
Speaker 2: sale Linux booleians sets you bul or the semanaged tool.
Speaker 2: Disabling it leaves you far more vulnerable. If a service
Speaker 2: is compromised, learn.
Speaker 1: To troubleshoot it, don't just disable it. Yeah, got it? Okay?
Speaker 1: Remote access SSH secure shell It replaced older insecure things
Speaker 1: like Telnet and FTP.
Speaker 2: Right absolutely. SSH is the standard for secure remote log
Speaker 2: in and file transfer.
Speaker 1: And while passwords work, what's the better, more secure and
Speaker 1: automation friendly way to authenticate?
Speaker 2: Key based authentication? Public key cryptography.
Speaker 1: How does that work?
Speaker 2: Briefly, you generate a pair of keys, a private key,
Speaker 2: which you keep secret and secure on your client machine
Speaker 2: and a public key which you copy to the server,
Speaker 2: usually into the dotsch authorized keys file in your home directory.
Speaker 1: There and the server uses the public key to verify
Speaker 1: you have the private key without the private key ever,
Speaker 1: leaving your.
Speaker 2: Machine correct no passwords flying over the network. Much more secure.
Speaker 2: But there's the catch with permissions es.
Speaker 1: SSH is picky, very picky.
Speaker 2: Your eight ish directory on the server must have strict
Speaker 2: permissions usually seven hundred only owner access, and the authorized
Speaker 2: keys file itself should be readable only by you, like
Speaker 2: six hundred. If permissions are too open, SSH will refuse
Speaker 2: to use the keys as a security measure.
Speaker 1: Good tip. Finally, let's touch on containers. They give you
Speaker 1: process isolation kind of like VMS, but lighter weight. RHL
Speaker 1: eight focuses on tools like Podman, build a SCOPEO. What's
Speaker 1: the main security angle here, especially with Podman.
Speaker 2: The big push with Podman is rootless containers. This is
Speaker 2: a significant security improvement over say, the traditional Docker model,
Speaker 2: which relied on a root privileged demon So.
Speaker 1: Podman can run containers without needing root pleges itself.
Speaker 2: Yes, you can run containers entirely as a regular unprivileged user.
Speaker 2: This means if a process inside the container somehow escapes
Speaker 2: or gets compromised, the attacker is contained as that regular
Speaker 2: user on the host system, not as route. It dramatically
Speaker 2: shrinks the attack surface.
Speaker 1: That's a huge win. So podman runs them. What about
Speaker 1: BUILDA and SCOPEO.
Speaker 2: BUILDA is specifically designed for building container images, often using
Speaker 2: definition files called container files, similar to Docker files. It's
Speaker 2: focused just on the build process, okay. And SCOPEO is
Speaker 2: a utility for working with container images on remote registries.
Speaker 2: You can use it to inspect images, copy them between registries,
Speaker 2: delete them all without needing to pull the entire image
Speaker 2: down locally or run a full container engine. It's about
Speaker 2: image management.
Speaker 1: So podman build a SCOPEO plus red Hat's Universal Base
Speaker 1: image UBI. That's the RAHL stack for containers.
Speaker 2: That's the modern secure stack.
Speaker 1: Yes wow, okay, We've covered a lot of ground there,
Speaker 1: from the absolute basics of the shell and user identity,
Speaker 1: through permissions, pseudo, the whole system of architecture, timekeeping, resource monitoring,
Speaker 1: and then into advanced hardening with selnux, SSH keys and
Speaker 1: secure contenter tooling.
Speaker 2: It really shows how these foundational pieces build on each other.
Speaker 2: Understanding the shell enable scripting. Understanding permissions enables Pseudo and SELinux.
Speaker 2: Understanding systems helps you manage the services running inside containers.
Speaker 2: It's all connected.
Speaker 1: The journey from just using Linux to really administering it
Speaker 1: effectively hinges on grasping these fundamentals. How it boots, manages resources,
Speaker 1: enforces security.
Speaker 2: Absolutely. That core understanding is what lets you solve complex
Speaker 2: problems later.
Speaker 1: So before we wrap up, let's leave you with that
Speaker 1: final provocative thought, the ultimate break glass in case of
Speaker 1: emergency knowledge, what happens if you completely lose the root password?
Speaker 1: How do you recover access without reinstalling everything?
Speaker 2: Ah, the ultimate test of system understanding. The sources point
Speaker 2: to intervening very early in the boot process, within the
Speaker 2: grub boot loader.
Speaker 1: Menu, before Linux even really starts exactly.
Speaker 2: You edit the kernel's boot parameters before it loads. You
Speaker 2: add the parameter dot break to the end of the kernel.
Speaker 1: Line word dot break. What does that do?
Speaker 2: It tells the system to pause the boot process very
Speaker 2: early on, before it mounts the main root file system ReadWrite,
Speaker 2: and before it loads security policies like selenux. It drops
Speaker 2: you into a minimal emergency shell, and from there, from
Speaker 2: that minimal shell, the actual root file system is usually
Speaker 2: mounted read only under sysroute. You need to remind it
Speaker 2: read write mount rosis route. Then you use croute cisroute
Speaker 2: to change your root directory into the real system's root.
Speaker 1: So now you're effectively operating inside your main system, but
Speaker 1: without the usual security constraints.
Speaker 2: Active yet correct, and then you can simply run the
Speaker 2: password command to set a new password for the root user.
Speaker 2: Once done, you exit the creut, exit the emergency shell,
Speaker 2: and let the boot process continue normally.
Speaker 1: That's well, that's some serious power. Knowing how to interrupt
Speaker 1: the system right at its birth.
Speaker 2: It's the ultimate demonstration mastering the fundamentals. Now go try
Speaker 2: it out on a test system, but be aware this
Speaker 2: specific trick gets a lot more complicated if your root
Speaker 2: file system is encrypted. That adds another layer entirely good point.
Speaker 1: A final thought to explore. Thanks for joining us on
Speaker 1: this deep dive.