WEBVTT

1
00:00:00.080 --> 00:00:04.240
<v Speaker 1>Okay, so I want you to picture this scenario. Imagine

2
00:00:04.240 --> 00:00:07.000
<v Speaker 1>you're sitting at a small, totally unfamiliar desk.

3
00:00:07.240 --> 00:00:09.359
<v Speaker 2>Sounds a little ominous already, right.

4
00:00:09.199 --> 00:00:12.400
<v Speaker 1>It gets worse. In front of you is a single monitor,

5
00:00:12.560 --> 00:00:17.359
<v Speaker 1>a keyboard, and a live, completely broken operating system. Oh wow, Yeah,

6
00:00:17.440 --> 00:00:19.600
<v Speaker 1>the clock on the wall is ticking down. You have

7
00:00:19.679 --> 00:00:24.600
<v Speaker 1>exactly two and a half hours to diagnose the problems,

8
00:00:24.839 --> 00:00:28.000
<v Speaker 1>fix the system, and configure this really complex series of

9
00:00:28.000 --> 00:00:31.079
<v Speaker 1>IT scenarios. Oh and here's the kicker. Let me guess

10
00:00:31.320 --> 00:00:33.520
<v Speaker 1>you have absolutely zero access to the Internet.

11
00:00:33.640 --> 00:00:35.799
<v Speaker 3>Yeah, that's the real nightmare for most people exactly.

12
00:00:35.920 --> 00:00:37.560
<v Speaker 1>I mean, you can't reach for a search engine, you

13
00:00:37.600 --> 00:00:39.840
<v Speaker 1>can't load up a forum, you can't even bring in

14
00:00:39.840 --> 00:00:43.039
<v Speaker 1>a piece of scratch paper. It is this incredibly intense,

15
00:00:43.119 --> 00:00:47.399
<v Speaker 1>highly isolated environment. And for systems engineers, this isn't some

16
00:00:47.600 --> 00:00:52.079
<v Speaker 1>hypothetical stress dream. It's the very real setting of a

17
00:00:52.119 --> 00:00:53.679
<v Speaker 1>red hat certification exam.

18
00:00:53.759 --> 00:00:54.280
<v Speaker 3>It really is.

19
00:00:54.320 --> 00:00:56.200
<v Speaker 2>I mean, it's the ultimate proving ground for an IT

20
00:00:56.439 --> 00:00:59.520
<v Speaker 2>professional and for you listening. You know, whether you are

21
00:00:59.600 --> 00:01:02.479
<v Speaker 2>active prepping to run this gauntlet yourself, or you simply

22
00:01:02.560 --> 00:01:07.439
<v Speaker 2>want to understand the rigorous architecture that keeps our digital

23
00:01:07.439 --> 00:01:11.560
<v Speaker 2>infrastructure from basically collapsing in on itself. Well, this deep

24
00:01:11.640 --> 00:01:12.439
<v Speaker 2>dive is for you.

25
00:01:12.719 --> 00:01:13.680
<v Speaker 3>We are going to strut.

26
00:01:13.480 --> 00:01:15.840
<v Speaker 2>Away the abstractions and just look at the raw mechanics

27
00:01:15.879 --> 00:01:16.799
<v Speaker 2>of modern computing.

28
00:01:16.879 --> 00:01:21.079
<v Speaker 1>Absolutely, and our map for this journey today is osgar

29
00:01:21.120 --> 00:01:25.519
<v Speaker 1>Gory's massive twenty fifteen text. It's the Red Hat Enterprise

30
00:01:25.640 --> 00:01:30.439
<v Speaker 1>Linux seven Training and Exam Preparation Guide, truly massive book, huge,

31
00:01:30.799 --> 00:01:33.640
<v Speaker 1>and our mission here is to basically tear into this

32
00:01:33.719 --> 00:01:37.840
<v Speaker 1>twenty five chapter blueprint of it infrastructure. We really want

33
00:01:37.879 --> 00:01:40.599
<v Speaker 1>to extract what it actually reveals about the hidden architecture

34
00:01:40.599 --> 00:01:43.480
<v Speaker 1>of RHL seven. But more importantly, we want to look

35
00:01:43.480 --> 00:01:47.159
<v Speaker 1>at the specific mindset that's required to master systems administration

36
00:01:47.680 --> 00:01:49.599
<v Speaker 1>at a bare metal level.

37
00:01:49.359 --> 00:01:51.200
<v Speaker 2>Because it really does come down to that mindset. I mean,

38
00:01:51.200 --> 00:01:53.439
<v Speaker 2>before we even look at the technical commands or the

39
00:01:53.480 --> 00:01:57.239
<v Speaker 2>file systems or the demons, we have to understand the

40
00:01:57.280 --> 00:02:01.359
<v Speaker 2>crucible where this knowledge is tested. Straints of the environment

41
00:02:01.439 --> 00:02:03.640
<v Speaker 2>dictate exactly how the learning has to happen.

42
00:02:04.120 --> 00:02:06.799
<v Speaker 1>Right, So let's unpack this because the exam environment itself

43
00:02:06.879 --> 00:02:10.439
<v Speaker 1>is notoriously severe. Oh yeah, The book prepares candidates for

44
00:02:10.560 --> 00:02:15.759
<v Speaker 1>two specific performance based exams. First, you've got the RHCSA.

45
00:02:15.879 --> 00:02:19.000
<v Speaker 1>That's the Red Hat Certified System Administrator Exam or the

46
00:02:19.000 --> 00:02:21.400
<v Speaker 1>EX two hundred, right, the two hundred, and that one

47
00:02:21.439 --> 00:02:23.840
<v Speaker 1>is the two and a half hour sprint. Then there's

48
00:02:23.879 --> 00:02:27.159
<v Speaker 1>the RHCE, the Red Hat Certified Engineer Exam. That's the

49
00:02:27.199 --> 00:02:30.439
<v Speaker 1>EX three hundred, which is this grueling four.

50
00:02:30.199 --> 00:02:31.960
<v Speaker 3>Hour marathon, just a marathon.

51
00:02:32.120 --> 00:02:35.039
<v Speaker 1>And both of these are taken on live environments running

52
00:02:35.199 --> 00:02:39.000
<v Speaker 1>RHL seven. And like I mentioned before, the crucial constraint

53
00:02:39.000 --> 00:02:44.039
<v Speaker 1>here is the total isolation. No Internet, no electronic devices,

54
00:02:44.039 --> 00:02:48.039
<v Speaker 1>no printed materials. You only have access to standard offline

55
00:02:48.080 --> 00:02:51.719
<v Speaker 1>Linux documentation, which is rough right, You're relying entirely on

56
00:02:51.759 --> 00:02:53.919
<v Speaker 1>the man pages and info commands. You pay your four

57
00:02:53.960 --> 00:02:56.319
<v Speaker 1>hundred dollars, you show up usually on a Friday, I think,

58
00:02:56.360 --> 00:02:59.199
<v Speaker 1>and you are just locked in with the machine.

59
00:02:58.840 --> 00:02:59.960
<v Speaker 3>Just you and the command line.

60
00:03:00.080 --> 00:03:02.240
<v Speaker 1>But okay, I have to challenge this premise right out

61
00:03:02.280 --> 00:03:04.879
<v Speaker 1>of the gate. I mean, is testing engineers in a

62
00:03:04.919 --> 00:03:09.039
<v Speaker 1>complete vacuum actually validating a modern sissedmen because in the

63
00:03:09.080 --> 00:03:13.639
<v Speaker 1>real world, literally everybody relies on vendor documentation, search engines,

64
00:03:13.719 --> 00:03:16.400
<v Speaker 1>community forums. I mean, an engineer who doesn't look things

65
00:03:16.479 --> 00:03:18.280
<v Speaker 1>up is usually a dangerous engineer.

66
00:03:18.560 --> 00:03:19.240
<v Speaker 3>You're not wrong.

67
00:03:19.759 --> 00:03:23.719
<v Speaker 2>What's fascinating here, though, is the underlying philosophy of that constraint. Yeah,

68
00:03:23.879 --> 00:03:28.639
<v Speaker 2>you're completely right that in a normal Tuesday afternoon deployment scenario,

69
00:03:29.280 --> 00:03:31.759
<v Speaker 2>an engineer is going to look up the specific syntax

70
00:03:32.319 --> 00:03:35.560
<v Speaker 2>for a really complex OX string, of course, or they'll

71
00:03:35.639 --> 00:03:37.639
<v Speaker 2>verify a flag and it can fig file.

72
00:03:38.319 --> 00:03:38.879
<v Speaker 3>But the ex.

73
00:03:38.879 --> 00:03:41.439
<v Speaker 2>Two hundred and ex. Three hundred. They aren't testing for

74
00:03:41.520 --> 00:03:45.280
<v Speaker 2>normal Tuesday afternoons. Oh okay, they are testing for a

75
00:03:45.360 --> 00:03:48.080
<v Speaker 2>catastrophic failure at three point zero am.

76
00:03:47.919 --> 00:03:49.639
<v Speaker 1>When everything is on fire.

77
00:03:49.520 --> 00:03:53.120
<v Speaker 2>Exactly when your core DNS server goes down or your

78
00:03:53.159 --> 00:03:57.120
<v Speaker 2>external gateway is misconfigured and the network itself is totally unreachable.

79
00:03:57.439 --> 00:03:59.800
<v Speaker 2>You don't have the luxury of querying a forum.

80
00:03:59.520 --> 00:04:01.400
<v Speaker 1>Because you can even get online to ask the question.

81
00:04:01.800 --> 00:04:05.039
<v Speaker 2>Right, the baseline foundational knowledge of how the system operates.

82
00:04:05.039 --> 00:04:08.120
<v Speaker 2>It has to be instinctual. The lack of Internet forces

83
00:04:08.199 --> 00:04:11.960
<v Speaker 2>true comprehension over just rote memorization.

84
00:04:11.520 --> 00:04:12.400
<v Speaker 1>So you can't fake it.

85
00:04:12.560 --> 00:04:14.639
<v Speaker 2>You really can't. You can't just copy and paste a

86
00:04:14.680 --> 00:04:17.879
<v Speaker 2>Bash script from the web. You have to fundamentally understand

87
00:04:17.879 --> 00:04:20.879
<v Speaker 2>the architecture of the os SO you can navigate it

88
00:04:20.959 --> 00:04:25.839
<v Speaker 2>using only its internal documentation. In fact, Gory explicitly warns

89
00:04:25.879 --> 00:04:27.360
<v Speaker 2>readers in his preface about this.

90
00:04:27.399 --> 00:04:28.000
<v Speaker 1>What does he say?

91
00:04:28.120 --> 00:04:30.959
<v Speaker 2>He says that his book is not an official replacement

92
00:04:31.079 --> 00:04:34.639
<v Speaker 2>for red Hat courses, but it's a rigorous tool designed

93
00:04:34.720 --> 00:04:38.839
<v Speaker 2>specifically to guarantee that you have built this baseline instinct.

94
00:04:39.240 --> 00:04:43.199
<v Speaker 1>That reliance on internal documentation is exactly why Gory's book

95
00:04:43.240 --> 00:04:45.759
<v Speaker 1>isn't just like a cheat sheet.

96
00:04:46.040 --> 00:04:46.639
<v Speaker 3>No, not at all.

97
00:04:46.680 --> 00:04:49.240
<v Speaker 1>It's a complete restructuring of how you approach a system.

98
00:04:49.279 --> 00:04:52.160
<v Speaker 1>And he actually breaks this down into four pillars. First

99
00:04:52.319 --> 00:04:58.000
<v Speaker 1>is grasping concepts, second is mastering implementation procedures, Third is

100
00:04:58.240 --> 00:05:02.360
<v Speaker 1>learning the commands can figure files and demons, and fourth

101
00:05:02.519 --> 00:05:04.480
<v Speaker 1>is troubleshooting and resolving problems.

102
00:05:04.480 --> 00:05:04.959
<v Speaker 3>A big one.

103
00:05:04.959 --> 00:05:06.759
<v Speaker 1>But looking at that list, I mean, I have to ask,

104
00:05:06.920 --> 00:05:09.519
<v Speaker 1>isn't that just a generic learning model for literally any

105
00:05:09.600 --> 00:05:13.399
<v Speaker 1>technical subject. Read the theory, do the practice, memorize the vocabulary,

106
00:05:13.759 --> 00:05:15.759
<v Speaker 1>and fix the errors on the surface.

107
00:05:16.040 --> 00:05:18.839
<v Speaker 2>Yeah, it definitely looks like standard pedagogy. Ah, but the

108
00:05:18.879 --> 00:05:24.399
<v Speaker 2>application here is hyper specific to Linux administration. Let's look

109
00:05:24.399 --> 00:05:30.079
<v Speaker 2>at that fourth pillar, troubleshooting. Okay, in RHL troubleshooting isn't

110
00:05:30.120 --> 00:05:31.360
<v Speaker 2>just turning it off and on again.

111
00:05:31.439 --> 00:05:33.120
<v Speaker 1>This is my usual strategy to be hot.

112
00:05:33.160 --> 00:05:36.120
<v Speaker 2>Right for most of us, but here it requires a

113
00:05:36.160 --> 00:05:40.040
<v Speaker 2>really deep, interconnected understanding of the exact execution path of

114
00:05:40.079 --> 00:05:44.560
<v Speaker 2>a service. If an implementation procedure fails, Gory demands that

115
00:05:44.600 --> 00:05:46.680
<v Speaker 2>his readers don't just retry the command.

116
00:05:47.079 --> 00:05:50.680
<v Speaker 1>Oh so, no blindly hitting the upbarrow and entering it

117
00:05:50.720 --> 00:05:51.439
<v Speaker 1>again exactly.

118
00:05:51.480 --> 00:05:52.319
<v Speaker 3>They have to trace it.

119
00:05:52.480 --> 00:05:54.560
<v Speaker 2>They have to know which specific log file in the

120
00:05:54.639 --> 00:05:57.959
<v Speaker 2>varlog directory to check which demon was handling their request

121
00:05:58.399 --> 00:06:01.560
<v Speaker 2>and whether, say, a syntax air or an environment variable

122
00:06:01.680 --> 00:06:04.800
<v Speaker 2>cause the failure. Wow, He's training the reader to parse

123
00:06:04.839 --> 00:06:08.240
<v Speaker 2>system feedback natively. And he backs all this up with

124
00:06:08.319 --> 00:06:11.680
<v Speaker 2>serious authority. I mean, Gory is a UNHS and Linux consultant.

125
00:06:12.120 --> 00:06:15.800
<v Speaker 2>He holds the PMP, the HPCSA, the RHSE himself, so.

126
00:06:15.759 --> 00:06:17.560
<v Speaker 1>He knows what he's talking about very much so.

127
00:06:17.639 --> 00:06:20.800
<v Speaker 2>And he insists on a physical, tactile lab environment to

128
00:06:20.879 --> 00:06:22.480
<v Speaker 2>actually make these four pillars stick.

129
00:06:22.680 --> 00:06:22.839
<v Speaker 1>Right.

130
00:06:23.000 --> 00:06:23.360
<v Speaker 3>Yeah.

131
00:06:23.399 --> 00:06:26.079
<v Speaker 1>He lays out the hardware requirements for a home lab

132
00:06:26.079 --> 00:06:28.160
<v Speaker 1>in the book. He says you need a sixty four

133
00:06:28.199 --> 00:06:31.800
<v Speaker 1>bit machine, at least a dual core processor and built

134
00:06:31.839 --> 00:06:34.120
<v Speaker 1>in hardware virtualization support.

135
00:06:33.839 --> 00:06:35.279
<v Speaker 3>Pretty standard stuff nowadays.

136
00:06:35.399 --> 00:06:38.360
<v Speaker 1>Yeah, but what really stands out is the software workaround

137
00:06:38.360 --> 00:06:41.680
<v Speaker 1>he provides for the reader. Because you know, if you

138
00:06:41.720 --> 00:06:45.800
<v Speaker 1>don't want to buy a commercial RHL seven subscription.

139
00:06:45.519 --> 00:06:47.800
<v Speaker 3>Just to practice, which can be pricey.

140
00:06:47.879 --> 00:06:52.759
<v Speaker 1>Exactly, Gory points you straight to CentOS or Scientific Linux.

141
00:06:53.279 --> 00:06:57.319
<v Speaker 1>They are one hundred percent compatible, free, non commercial versions

142
00:06:57.319 --> 00:06:59.920
<v Speaker 1>that are built from the exact same source code. He

143
00:07:00.160 --> 00:07:03.199
<v Speaker 1>totally removes the financial barrier to actually putting your hands

144
00:07:03.199 --> 00:07:03.839
<v Speaker 1>on the keyboard.

145
00:07:04.000 --> 00:07:05.759
<v Speaker 2>And putting your hands on the keyboard is the only

146
00:07:05.759 --> 00:07:07.480
<v Speaker 2>way you're going to build that instinct we were talking

147
00:07:07.519 --> 00:07:10.240
<v Speaker 2>about earlier. You actually have to intentionally break your own

148
00:07:10.319 --> 00:07:13.240
<v Speaker 2>lab environment and then use those offline man pages to

149
00:07:13.279 --> 00:07:14.120
<v Speaker 2>dig yourself out.

150
00:07:14.600 --> 00:07:16.439
<v Speaker 1>So what does this all mean for the learner? When

151
00:07:16.480 --> 00:07:18.800
<v Speaker 1>I look at these four pillars within the context of

152
00:07:18.839 --> 00:07:21.959
<v Speaker 1>an RHL environment, it actually looks less like an IT

153
00:07:22.399 --> 00:07:25.920
<v Speaker 1>manual to me and more like a language acquisition framework.

154
00:07:26.160 --> 00:07:27.480
<v Speaker 3>Oh, that's an interesting way to put it.

155
00:07:27.560 --> 00:07:30.600
<v Speaker 1>Yeah, think about it. Grasping the concepts is like learning

156
00:07:30.600 --> 00:07:35.399
<v Speaker 1>the underlying grammar rules, mastering the implementation and commands. That's

157
00:07:35.439 --> 00:07:39.600
<v Speaker 1>building your raw vocabulary, right. But troubleshooting that fourth pillar

158
00:07:40.199 --> 00:07:43.519
<v Speaker 1>that's the ability to understand a subtle joke in a

159
00:07:43.560 --> 00:07:44.360
<v Speaker 1>foreign language.

160
00:07:44.399 --> 00:07:45.920
<v Speaker 3>That is a great analogy, right.

161
00:07:46.040 --> 00:07:51.079
<v Speaker 1>It requires context, culture, unexpected connections. That is what actually

162
00:07:51.120 --> 00:07:52.639
<v Speaker 1>proves fluency.

163
00:07:53.079 --> 00:07:57.519
<v Speaker 2>The language analogy works perfectly, really because to troubleshoot effectively,

164
00:07:57.800 --> 00:08:00.319
<v Speaker 2>you have to understand how different components of this system

165
00:08:00.439 --> 00:08:04.240
<v Speaker 2>are conversing with each other. A failure in one service

166
00:08:04.480 --> 00:08:06.639
<v Speaker 2>is you know, it's often just a symptom of a

167
00:08:06.680 --> 00:08:09.199
<v Speaker 2>miscommunication much deeper in the stack.

168
00:08:09.360 --> 00:08:11.199
<v Speaker 1>Yeah, and here's where it gets really interesting.

169
00:08:11.240 --> 00:08:11.480
<v Speaker 3>Though.

170
00:08:11.680 --> 00:08:15.240
<v Speaker 1>We've established this rigorous learning philosophy and the physical lab

171
00:08:15.319 --> 00:08:17.800
<v Speaker 1>set up, but when we dive into the actual anatomy

172
00:08:17.839 --> 00:08:20.800
<v Speaker 1>of the syllabus, the structure of the text itself tells

173
00:08:20.839 --> 00:08:22.959
<v Speaker 1>a story about the evolution of an engineer.

174
00:08:23.120 --> 00:08:23.720
<v Speaker 3>It really does.

175
00:08:23.879 --> 00:08:26.519
<v Speaker 1>The book is split right down the middle. Chapters one

176
00:08:26.560 --> 00:08:30.399
<v Speaker 1>through thirteen covered the RHCSA syllabus, which is managing a

177
00:08:30.439 --> 00:08:34.240
<v Speaker 1>single system. Then chapters fourteen through twenty five cover the

178
00:08:34.399 --> 00:08:38.279
<v Speaker 1>RHCE syllabus, which is managing two or more networked systems.

179
00:08:38.759 --> 00:08:41.919
<v Speaker 1>So to borrow another metaphor here, if the RHCSA is

180
00:08:41.919 --> 00:08:45.840
<v Speaker 1>about building a single watertight submarine, the RHCE is about

181
00:08:45.840 --> 00:08:49.879
<v Speaker 1>coordinating an entire fleet of those submarines to communicate securely

182
00:08:49.960 --> 00:08:51.159
<v Speaker 1>in hostile waters.

183
00:08:51.320 --> 00:08:54.399
<v Speaker 2>That is exactly the progression, because I mean you cannot

184
00:08:54.399 --> 00:08:56.759
<v Speaker 2>coordinate the fleet if the individual holes are.

185
00:08:56.679 --> 00:09:00.440
<v Speaker 1>Leaking, exactly. And the scope of building that's a single

186
00:09:00.600 --> 00:09:03.879
<v Speaker 1>watertight hull in the RHCSA is just massive.

187
00:09:03.919 --> 00:09:04.600
<v Speaker 3>Oh, it's huge.

188
00:09:04.600 --> 00:09:08.879
<v Speaker 1>You're dealing with local storage management using MBR and GPT partitioning.

189
00:09:09.200 --> 00:09:13.120
<v Speaker 1>You're setting up Logical Volume Manager or LVM. You're managing

190
00:09:13.159 --> 00:09:16.720
<v Speaker 1>swap spaces totally crucial. Yeah, and you are locking down

191
00:09:16.759 --> 00:09:21.360
<v Speaker 1>the system with firewalled and configuring security enhanced cylinics, managing

192
00:09:21.360 --> 00:09:24.519
<v Speaker 1>its specific contexts and booleans. And you're doing all of

193
00:09:24.519 --> 00:09:27.919
<v Speaker 1>this while mastering tools like five GP and TAR.

194
00:09:27.960 --> 00:09:29.279
<v Speaker 3>Right the absolute basics.

195
00:09:29.399 --> 00:09:32.600
<v Speaker 1>But then you hit the RC section and the scope

196
00:09:32.679 --> 00:09:36.879
<v Speaker 1>just expands exponentially. You're diving into shell scripting. You're configuring

197
00:09:36.919 --> 00:09:41.600
<v Speaker 1>IPv six routing interface, bonding teaming, you are hosting web

198
00:09:41.639 --> 00:09:46.039
<v Speaker 1>services with apatche, setting up NFS and Samba, yes, routing

199
00:09:46.080 --> 00:09:49.080
<v Speaker 1>mail via postfix, handling B and D for DNS, and

200
00:09:49.159 --> 00:09:53.600
<v Speaker 1>managing Maria dB databases. It is a staggering amount of material.

201
00:09:53.679 --> 00:09:54.879
<v Speaker 3>It's a lot for one person.

202
00:09:55.120 --> 00:09:57.919
<v Speaker 1>So I have to ask, does a modern IT engineer

203
00:09:58.000 --> 00:10:00.639
<v Speaker 1>really need to know how to execute all of this manually?

204
00:10:01.200 --> 00:10:03.759
<v Speaker 1>I mean, we're in an arrow where infrastructure as code

205
00:10:03.799 --> 00:10:08.080
<v Speaker 1>and cloud provisioning exist. Why are we manually partitioning raw

206
00:10:08.159 --> 00:10:12.320
<v Speaker 1>hard drives with parted and then manually configuring Apache virtual hosts.

207
00:10:12.639 --> 00:10:14.879
<v Speaker 2>Well, if we connect this to the bigger picture, the

208
00:10:14.960 --> 00:10:18.679
<v Speaker 2>reason manual mastery is still required is because abstractions eventually leak.

209
00:10:18.840 --> 00:10:19.799
<v Speaker 1>Okay, what do you mean by that.

210
00:10:19.879 --> 00:10:22.399
<v Speaker 2>Let's look at the mechanics of why these two halves

211
00:10:22.440 --> 00:10:24.279
<v Speaker 2>of the book the single system in the network are

212
00:10:24.320 --> 00:10:27.559
<v Speaker 2>so deeply intertwined. Take your patchy web server example from

213
00:10:27.600 --> 00:10:31.360
<v Speaker 2>the RHC section. Say you deploy a web application and

214
00:10:31.399 --> 00:10:36.080
<v Speaker 2>the browser throws a forbidden error. A novice somebody who

215
00:10:36.120 --> 00:10:38.879
<v Speaker 2>only understands the top layer of the network service, they

216
00:10:38.960 --> 00:10:42.559
<v Speaker 2>might spend three hours staring at the httpd dot.

217
00:10:42.399 --> 00:10:44.399
<v Speaker 1>Com file, just pulling their hair out.

218
00:10:44.320 --> 00:10:48.720
<v Speaker 2>Exactly verifying the document route, checking the directory permissions, and

219
00:10:48.799 --> 00:10:51.279
<v Speaker 2>just being completely baffled because the standard Linux read and

220
00:10:51.279 --> 00:10:53.200
<v Speaker 2>write permissions look perfectly fine.

221
00:10:53.240 --> 00:10:55.960
<v Speaker 1>That the expert knows to look deeper into the hull

222
00:10:56.000 --> 00:10:56.720
<v Speaker 1>of the submarine.

223
00:10:56.879 --> 00:11:01.960
<v Speaker 2>Precisely, the expert who mastered. The RHSA material knows that

224
00:11:02.159 --> 00:11:06.360
<v Speaker 2>RHL seven implements SELinux and SYLINICX. Doesn't care about your

225
00:11:06.399 --> 00:11:10.240
<v Speaker 2>standard read rate permission. It uses mandatory access control. It

226
00:11:10.320 --> 00:11:13.679
<v Speaker 2>tags every single process in every file with a specific

227
00:11:13.679 --> 00:11:16.600
<v Speaker 2>security context. So if the Apache demon which has an

228
00:11:16.720 --> 00:11:20.039
<v Speaker 2>HTGTT context, tries to serve a file from a directory

229
00:11:20.039 --> 00:11:23.120
<v Speaker 2>that will say moved manually and still carries an admin

230
00:11:23.159 --> 00:11:24.399
<v Speaker 2>homic context.

231
00:11:24.000 --> 00:11:24.879
<v Speaker 1>This system stops it.

232
00:11:25.120 --> 00:11:27.440
<v Speaker 2>The kernel will block the read operation right at the

233
00:11:27.440 --> 00:11:30.759
<v Speaker 2>system call level, and this block is completely invisible to

234
00:11:30.759 --> 00:11:33.759
<v Speaker 2>the Apache configuration file. Oh yeah, so if you don't

235
00:11:33.840 --> 00:11:36.639
<v Speaker 2>know how to use samager or restore con to fix

236
00:11:36.720 --> 00:11:41.639
<v Speaker 2>that context, which are skills taught in the RHCSA, your

237
00:11:41.679 --> 00:11:44.720
<v Speaker 2>web server will never function and you will have absolutely

238
00:11:44.799 --> 00:11:45.759
<v Speaker 2>no idea why.

239
00:11:45.879 --> 00:11:49.559
<v Speaker 1>That highlights the dependency perfectly. The network service is completely

240
00:11:49.600 --> 00:11:51.399
<v Speaker 1>reliant on the local security policy.

241
00:11:51.519 --> 00:11:52.039
<v Speaker 3>Absolutely.

242
00:11:52.120 --> 00:11:55.240
<v Speaker 2>Let's take another example from the syllabus LVM the Logical

243
00:11:55.360 --> 00:12:00.120
<v Speaker 2>volume manager. Okay, the RHCSA requires you to understand and

244
00:12:00.279 --> 00:12:03.519
<v Speaker 2>how to take raw physical discs, group them into a

245
00:12:03.600 --> 00:12:07.759
<v Speaker 2>volume group, and carve out logical volumes. But why does

246
00:12:07.799 --> 00:12:11.039
<v Speaker 2>an RHSE managing let's say a MERYIDB database need to

247
00:12:11.080 --> 00:12:13.559
<v Speaker 2>know this because they're just dealing with the data, right, right,

248
00:12:13.600 --> 00:12:16.200
<v Speaker 2>But if that database suddenly halts and refuses to write

249
00:12:16.200 --> 00:12:19.399
<v Speaker 2>new records, the database logs might just show a really

250
00:12:19.480 --> 00:12:23.240
<v Speaker 2>generic right failure. Okay, but if the engineer understands LVM,

251
00:12:23.519 --> 00:12:26.519
<v Speaker 2>they know check the physical volume extents, they might realize

252
00:12:26.519 --> 00:12:29.240
<v Speaker 2>that the logical volume was set up using thin provisioning.

253
00:12:29.480 --> 00:12:31.039
<v Speaker 1>Remind me what sin provisioning is.

254
00:12:31.279 --> 00:12:34.159
<v Speaker 2>It basically means it was allocated more space virtually than

255
00:12:34.399 --> 00:12:38.120
<v Speaker 2>actually exists physically. So the underlying physical disc just hit

256
00:12:38.159 --> 00:12:39.440
<v Speaker 2>a one under capacity.

257
00:12:39.679 --> 00:12:42.840
<v Speaker 1>Oh I see, So the database software is actually functioning perfectly,

258
00:12:43.200 --> 00:12:45.919
<v Speaker 1>but the physical storage floor just literally dropped out from

259
00:12:46.000 --> 00:12:46.360
<v Speaker 1>under it.

260
00:12:46.639 --> 00:12:47.159
<v Speaker 3>Exactly.

261
00:12:47.600 --> 00:12:51.200
<v Speaker 2>You cannot troubleshoot the fleet's communication if you don't know

262
00:12:51.240 --> 00:12:53.360
<v Speaker 2>how the plumbing in the individual submarine works.

263
00:12:53.559 --> 00:12:54.639
<v Speaker 1>That makes total sense.

264
00:12:54.799 --> 00:12:58.120
<v Speaker 2>The network services in the rhse rely entirely on the

265
00:12:58.159 --> 00:13:02.600
<v Speaker 2>local storage mechanism's permission and security contexts that are established

266
00:13:02.639 --> 00:13:04.399
<v Speaker 2>in THECSA.

267
00:13:03.840 --> 00:13:08.000
<v Speaker 1>Which brings us to this really fascinating irony in Gory's curriculum.

268
00:13:08.159 --> 00:13:09.279
<v Speaker 3>Oh yeah, we've.

269
00:13:09.120 --> 00:13:12.840
<v Speaker 1>Just talked about all these highly abstracted concepts, right, thinly

270
00:13:12.879 --> 00:13:18.200
<v Speaker 1>provisioned logical volumes, IPB six routing mandatory access controls. But

271
00:13:18.279 --> 00:13:21.399
<v Speaker 1>when you trace this massive text back to its very

272
00:13:21.440 --> 00:13:25.679
<v Speaker 1>first technical chapter, it begins in the most grounded, tactile

273
00:13:25.720 --> 00:13:26.559
<v Speaker 1>way imaginable.

274
00:13:26.799 --> 00:13:28.080
<v Speaker 3>Oh, I know where you're going with this.

275
00:13:28.360 --> 00:13:32.480
<v Speaker 1>Chapter One is literally titled installing RHL seven on physical

276
00:13:32.480 --> 00:13:34.440
<v Speaker 1>computer using local DVD.

277
00:13:34.639 --> 00:13:37.200
<v Speaker 2>You really cannot get more bare metal than a local

278
00:13:37.279 --> 00:13:38.039
<v Speaker 2>optical drive.

279
00:13:38.480 --> 00:13:42.799
<v Speaker 1>No, it is incredibly physical for an operating system that

280
00:13:43.200 --> 00:13:46.519
<v Speaker 1>acts as the invisible backbone of the cloud. I mean,

281
00:13:46.559 --> 00:13:49.519
<v Speaker 1>the chapter walks you step by step through navigating the

282
00:13:49.559 --> 00:13:52.759
<v Speaker 1>physical boot menu. It forces you to manually configure the

283
00:13:52.840 --> 00:13:57.120
<v Speaker 1>day and time, manually partition the installation destination, and set

284
00:13:57.120 --> 00:13:58.519
<v Speaker 1>the literal root password.

285
00:13:58.679 --> 00:14:00.360
<v Speaker 3>Yeah, it starts from absolutely zero.

286
00:14:00.559 --> 00:14:03.639
<v Speaker 1>It even delineates between red Hat Enterprise Linux for desktop

287
00:14:03.799 --> 00:14:07.879
<v Speaker 1>and ROHL for server. But I think the most critical

288
00:14:07.919 --> 00:14:10.480
<v Speaker 1>part of this chapter is the breakdown of the Linux

289
00:14:10.480 --> 00:14:13.799
<v Speaker 1>boot process phases. Oh, definitely gory walks the reader through

290
00:14:13.840 --> 00:14:18.080
<v Speaker 1>the exact handover, starting at the hardware firmware, passing control

291
00:14:18.159 --> 00:14:20.879
<v Speaker 1>to the grub bootloader, which then loads the kernel and

292
00:14:20.919 --> 00:14:23.679
<v Speaker 1>the intertrams into memory, and finally handing off to the

293
00:14:23.720 --> 00:14:26.320
<v Speaker 1>initialization phase managed by systems.

294
00:14:25.960 --> 00:14:29.240
<v Speaker 2>And he forces the student to trace that specific sequence

295
00:14:29.320 --> 00:14:32.440
<v Speaker 2>for a very good reason, because the boot process is

296
00:14:32.480 --> 00:14:35.679
<v Speaker 2>the ultimate intersection of hardware and software. We throw the

297
00:14:35.720 --> 00:14:38.759
<v Speaker 2>word cloud around so casually that it kind of obscures reality.

298
00:14:38.960 --> 00:14:41.639
<v Speaker 2>The cloud is just heavily abstracted physical hardware sitting in

299
00:14:41.679 --> 00:14:43.080
<v Speaker 2>a massive, air conditioned.

300
00:14:42.720 --> 00:14:44.720
<v Speaker 1>Warehouse somewhere someone else's computer.

301
00:14:44.919 --> 00:14:45.399
<v Speaker 3>Exactly.

302
00:14:45.679 --> 00:14:48.399
<v Speaker 2>By making the students start with a local DVD and

303
00:14:48.480 --> 00:14:51.799
<v Speaker 2>trace the boot sequence from the BIOS or UAFI all

304
00:14:51.799 --> 00:14:54.639
<v Speaker 2>the way up to the system targets, he basically ensures

305
00:14:54.639 --> 00:14:57.600
<v Speaker 2>they understand the mechanical reality beneath the hypervisor.

306
00:14:57.799 --> 00:15:01.200
<v Speaker 1>But why is knowing that specific boothand over, you know,

307
00:15:01.200 --> 00:15:04.399
<v Speaker 1>from Grub to the kernel to system pack. Why is

308
00:15:04.440 --> 00:15:06.720
<v Speaker 1>that so vital for someone who might just be deploying

309
00:15:06.759 --> 00:15:07.840
<v Speaker 1>virtual machines all day.

310
00:15:08.200 --> 00:15:11.159
<v Speaker 2>Because when a virtual machine fails to boot due to

311
00:15:11.919 --> 00:15:17.240
<v Speaker 2>say a corrupted master boot record or a misconfigured Grub payload,

312
00:15:17.559 --> 00:15:20.720
<v Speaker 2>the hypervisor can't help you. Oh yeah, the abstraction layer

313
00:15:20.759 --> 00:15:21.519
<v Speaker 2>is totally useless.

314
00:15:21.519 --> 00:15:22.600
<v Speaker 3>At that point, the.

315
00:15:22.559 --> 00:15:25.519
<v Speaker 2>Engineer actually has to mount a rescue ISO CREUD into

316
00:15:25.519 --> 00:15:28.679
<v Speaker 2>the broken file system and manually rebuild the grub dot

317
00:15:28.720 --> 00:15:32.840
<v Speaker 2>cfg file or reinstall the bootloader manually manually if you

318
00:15:32.840 --> 00:15:35.000
<v Speaker 2>don't know the mechanical sequence of how the OS pulls

319
00:15:35.039 --> 00:15:38.519
<v Speaker 2>itself up by its bootstraps, a corrupted bootloader basically means

320
00:15:38.559 --> 00:15:41.759
<v Speaker 2>the complete loss of the server. Gory's Chapter one ensures

321
00:15:41.759 --> 00:15:43.639
<v Speaker 2>the engineer never loses sight of the bear metal.

322
00:15:43.799 --> 00:15:46.600
<v Speaker 1>It's the ultimate grounding exercise. I mean, you can't build

323
00:15:46.720 --> 00:15:50.120
<v Speaker 1>resilient cloud architecture if you don't understand how the concrete

324
00:15:50.120 --> 00:15:54.440
<v Speaker 1>foundation actually cures exactly. Looking back at our deep dive today,

325
00:15:54.519 --> 00:15:57.519
<v Speaker 1>it has been a really rigorous journey through the mechanics

326
00:15:57.519 --> 00:15:58.279
<v Speaker 1>of administration.

327
00:15:58.519 --> 00:16:00.279
<v Speaker 3>A lot of groundcovered.

328
00:15:59.759 --> 00:16:03.279
<v Speaker 1>Still guarded in the intense Internet free isolation of the ex.

329
00:16:03.279 --> 00:16:06.720
<v Speaker 1>Two hundred and ex three hundred exams. Really understanding why

330
00:16:06.799 --> 00:16:10.080
<v Speaker 1>instinct has to replace search engines during a crisis. We

331
00:16:10.200 --> 00:16:13.679
<v Speaker 1>explored osgar Gory's four Pillars of mastery and that really

332
00:16:13.759 --> 00:16:18.360
<v Speaker 1>clever CentOS lab workaround. We broke down the vital dependency

333
00:16:18.399 --> 00:16:22.759
<v Speaker 1>between the ricsa's single system architecture, things like LVM and

334
00:16:22.840 --> 00:16:26.879
<v Speaker 1>Celinux and the ricees complex network services, and finally we

335
00:16:26.960 --> 00:16:29.200
<v Speaker 1>traced all of that high level theory back to the

336
00:16:29.360 --> 00:16:33.039
<v Speaker 1>very physical reality of a DVD installation and the grub

337
00:16:33.080 --> 00:16:33.799
<v Speaker 1>boot sequence.

338
00:16:33.879 --> 00:16:37.519
<v Speaker 2>That's a really demanding curriculum, but it completely demystifies the

339
00:16:37.559 --> 00:16:41.679
<v Speaker 2>invisible infrastructure that routes every email, hosts, every database, and

340
00:16:41.720 --> 00:16:43.639
<v Speaker 2>secures every transaction we rely on.

341
00:16:43.919 --> 00:16:46.720
<v Speaker 1>It really does so for you listening. The next time

342
00:16:46.759 --> 00:16:50.679
<v Speaker 1>you seamlessly stream a video or access a secure web portal,

343
00:16:51.279 --> 00:16:53.919
<v Speaker 1>take a second to picture the vast hidden matrix of

344
00:16:53.960 --> 00:17:00.000
<v Speaker 1>firewalled rules, sylinic security contexts, and apatche virtual hosts executing

345
00:17:00.120 --> 00:17:02.639
<v Speaker 1>literally millions of instructions in the background.

346
00:17:02.679 --> 00:17:03.679
<v Speaker 3>It's pretty mind boggling.

347
00:17:03.759 --> 00:17:06.440
<v Speaker 1>And more importantly, picture the highly trained engineers who can

348
00:17:06.519 --> 00:17:10.440
<v Speaker 1>navigate that matrix, relying purely on their internal training and

349
00:17:10.480 --> 00:17:11.519
<v Speaker 1>a few man pages.

350
00:17:11.799 --> 00:17:12.000
<v Speaker 3>You know.

351
00:17:12.400 --> 00:17:15.000
<v Speaker 2>This raises an important question, though, and it's a thought I.

352
00:17:14.920 --> 00:17:16.000
<v Speaker 3>Want to leave you with today.

353
00:17:16.079 --> 00:17:16.720
<v Speaker 1>Oh what's that?

354
00:17:16.960 --> 00:17:20.039
<v Speaker 2>Throughout Gory's text, we see the foundation being laid for

355
00:17:20.079 --> 00:17:24.759
<v Speaker 2>our modern infrastructure, mentions of virtualization, virtual machine managers like

356
00:17:24.880 --> 00:17:29.279
<v Speaker 2>vert manager and thin provisioning. As our computing environment becomes

357
00:17:29.319 --> 00:17:33.880
<v Speaker 2>increasingly hyper virtualized, we're moving into an era where engineers

358
00:17:33.920 --> 00:17:38.039
<v Speaker 2>deploy infrastructure as code, spinning up hundreds of abstracted nodes in.

359
00:17:38.000 --> 00:17:39.640
<v Speaker 3>Milliseconds, which is amazing.

360
00:17:39.759 --> 00:17:42.799
<v Speaker 2>But in this environment, will the tactile mechanics of a

361
00:17:42.799 --> 00:17:47.759
<v Speaker 2>local DVD installation or manual grub recovery or bare metal

362
00:17:47.799 --> 00:17:51.480
<v Speaker 2>physical volume management eventually degrade into ancient arts.

363
00:17:51.720 --> 00:17:52.960
<v Speaker 1>Wow, that's a scary thought.

364
00:17:53.279 --> 00:17:56.880
<v Speaker 2>If the next generation of systems administrators becomes completely detached

365
00:17:56.880 --> 00:17:59.720
<v Speaker 2>from the physical reality of the machines they command, what

366
00:18:00.000 --> 00:18:04.680
<v Speaker 2>happens to our infrastructure When the underlying abstraction layer catastrophically fails.

367
00:18:05.119 --> 00:18:08.039
<v Speaker 2>The host notes go dark and there's no one left

368
00:18:08.079 --> 00:18:10.279
<v Speaker 2>who remembers how to rebuild the foundation from the bare

369
00:18:10.319 --> 00:18:10.880
<v Speaker 2>metal up