WEBVTT

1
00:00:00.160 --> 00:00:02.560
<v Speaker 1>Welcome to the deep dive, where we take your sources

2
00:00:02.600 --> 00:00:06.080
<v Speaker 1>and extract the most important nuggets of knowledge. Today, we're

3
00:00:06.080 --> 00:00:08.960
<v Speaker 1>diving deep into a component of modern Linux that uh,

4
00:00:09.080 --> 00:00:11.000
<v Speaker 1>definitely sparks some strong opinions.

5
00:00:11.480 --> 00:00:12.560
<v Speaker 2>Yeah, it certainly does.

6
00:00:12.720 --> 00:00:15.759
<v Speaker 1>Our mission is to demystify it all drawing insights from

7
00:00:16.120 --> 00:00:19.399
<v Speaker 1>System for Linux cysadmins. All you need to know about

8
00:00:19.399 --> 00:00:22.440
<v Speaker 1>the System Suite for Linux users by David Both.

9
00:00:22.600 --> 00:00:25.320
<v Speaker 2>That's right for anyone interacting with Linux. I mean, whether

10
00:00:25.320 --> 00:00:29.399
<v Speaker 2>you're a seasoned, sissedmin juggling servers, or just you know,

11
00:00:29.960 --> 00:00:33.479
<v Speaker 2>really curious about what makes your machine tick. Understanding system

12
00:00:33.600 --> 00:00:34.799
<v Speaker 2>isn't just about knowing a.

13
00:00:34.719 --> 00:00:37.000
<v Speaker 1>Tool now, it's more fundamental exactly.

14
00:00:37.079 --> 00:00:40.920
<v Speaker 2>It's like getting a shortcut to truly understanding your system's heartbeat.

15
00:00:41.479 --> 00:00:44.359
<v Speaker 2>So our goal is to uncover what system is, what

16
00:00:44.399 --> 00:00:47.840
<v Speaker 2>it does, and crucially, how it impacts everything from system

17
00:00:47.880 --> 00:00:51.439
<v Speaker 2>startup to managing your most critical services right.

18
00:00:51.280 --> 00:00:54.479
<v Speaker 1>And equipping you with practical insights for efficient system management

19
00:00:54.520 --> 00:00:56.880
<v Speaker 1>along the way. So settle in. We think we've got

20
00:00:56.880 --> 00:01:00.439
<v Speaker 1>some aha moments coming your way as we unpack this

21
00:01:00.560 --> 00:01:05.280
<v Speaker 1>foundational piece of Linux. Okay, let's unpack this then, many

22
00:01:05.319 --> 00:01:08.239
<v Speaker 1>people here SYSTEMED and immediately think of, well, a lot

23
00:01:08.239 --> 00:01:11.519
<v Speaker 1>of strong opinions, sometimes even heated debates online.

24
00:01:11.599 --> 00:01:12.480
<v Speaker 2>Right, Oh definitely.

25
00:01:12.680 --> 00:01:14.719
<v Speaker 1>But if we strip away the controversy for a moment,

26
00:01:14.840 --> 00:01:16.680
<v Speaker 1>what is it at its absolute core?

27
00:01:17.439 --> 00:01:20.680
<v Speaker 2>Well, at its heart, systemed is truly the mother of

28
00:01:20.719 --> 00:01:24.640
<v Speaker 2>all processes in modern Linux. It's the very first process

29
00:01:24.680 --> 00:01:28.359
<v Speaker 2>started by the kernel famously assigned process ID or.

30
00:01:28.319 --> 00:01:30.239
<v Speaker 1>PID one, pid one, okay.

31
00:01:30.319 --> 00:01:34.079
<v Speaker 2>And from that precise moment it's responsible for starting, managing,

32
00:01:34.120 --> 00:01:36.799
<v Speaker 2>and ultimately stopping all of their processes on your system.

33
00:01:37.120 --> 00:01:39.480
<v Speaker 2>You can really think of it as the central.

34
00:01:39.239 --> 00:01:41.719
<v Speaker 1>Orchestrator, the conductor maybe, yeah.

35
00:01:41.640 --> 00:01:44.040
<v Speaker 2>One, pulling all the strings, making sure everything runs in harmony.

36
00:01:44.079 --> 00:01:46.200
<v Speaker 1>And our source material does a great job of clarifying

37
00:01:46.200 --> 00:01:49.239
<v Speaker 1>something fundamental here, doesn't it. It separates the entire system

38
00:01:49.239 --> 00:01:53.239
<v Speaker 1>boot in three distinct parts. That seems crucial for understanding

39
00:01:53.319 --> 00:01:55.159
<v Speaker 1>systems domain exactly.

40
00:01:55.319 --> 00:01:58.319
<v Speaker 2>This is a really important clarification, especially when you're troubleshooting.

41
00:01:58.760 --> 00:02:02.120
<v Speaker 2>So there's the hardware boot, right, That's where your systems

42
00:02:02.200 --> 00:02:07.159
<v Speaker 2>UEFI or bios initializes all your physical components, memory, CPU drives,

43
00:02:07.200 --> 00:02:09.280
<v Speaker 2>that sort of thing. Got it. Then comes the Linux

44
00:02:09.280 --> 00:02:13.159
<v Speaker 2>boot that's where GRUB two typically loads the kernel and

45
00:02:13.240 --> 00:02:15.960
<v Speaker 2>critically systemed itself into memory. Okay, and then there's the

46
00:02:16.000 --> 00:02:21.240
<v Speaker 2>Linux startup. That's the phase where system truly takes over control,

47
00:02:21.479 --> 00:02:24.960
<v Speaker 2>bringing up all the services, mounting file systems, and basically

48
00:02:25.000 --> 00:02:26.719
<v Speaker 2>preparing your host for productive work.

49
00:02:27.240 --> 00:02:29.840
<v Speaker 1>Ah. So our deep dive is really focusing on that

50
00:02:29.919 --> 00:02:34.000
<v Speaker 1>critical Linux startup phase, the part system completely manages.

51
00:02:34.159 --> 00:02:34.719
<v Speaker 2>That's the one.

52
00:02:34.800 --> 00:02:37.960
<v Speaker 1>Now, the shift from the old Venerable system via Knit

53
00:02:38.039 --> 00:02:41.319
<v Speaker 1>system to Systems wasn't exactly quiet. A lot of changes

54
00:02:41.319 --> 00:02:44.759
<v Speaker 1>there beyond just it's newer. What were the truly compelling

55
00:02:44.879 --> 00:02:48.840
<v Speaker 1>problems system solved? What made this huge fundamental change almost

56
00:02:48.840 --> 00:02:50.520
<v Speaker 1>inevitable for most distributions.

57
00:02:50.800 --> 00:02:52.840
<v Speaker 2>That's a great question, and it gets right to the

58
00:02:52.840 --> 00:02:56.560
<v Speaker 2>core of why this happened. The key advantages, well, they

59
00:02:56.599 --> 00:03:01.120
<v Speaker 2>really boil down to significantly more comprehensive status information and

60
00:03:02.039 --> 00:03:05.400
<v Speaker 2>much needed standardization. How so well, with system V if

61
00:03:05.439 --> 00:03:08.520
<v Speaker 2>you ran say service DHGPD status, you might just get

62
00:03:08.520 --> 00:03:12.159
<v Speaker 2>a vague running or stopped, not very helpful if something's.

63
00:03:11.840 --> 00:03:13.280
<v Speaker 1>Wrong, right, pretty basic.

64
00:03:13.560 --> 00:03:16.759
<v Speaker 3>But with Systems system.

65
00:03:16.120 --> 00:03:19.919
<v Speaker 2>Title status DHGPD, you get this wealth of detailed information.

66
00:03:20.639 --> 00:03:23.960
<v Speaker 2>It's current state, recent log entries pulled right in what

67
00:03:24.000 --> 00:03:25.520
<v Speaker 2>it depends on it's C group.

68
00:03:25.800 --> 00:03:28.280
<v Speaker 1>It's much richer, ah, so you can see what's actually

69
00:03:28.319 --> 00:03:29.400
<v Speaker 1>going on exactly.

70
00:03:29.439 --> 00:03:33.479
<v Speaker 2>It empowers administrators to understand and troubleshoot much much faster.

71
00:03:34.039 --> 00:03:37.919
<v Speaker 2>Plus the standardization across distributions that was huge. Configuration file

72
00:03:38.039 --> 00:03:40.479
<v Speaker 2>service management commands, they became far more.

73
00:03:40.400 --> 00:03:44.199
<v Speaker 1>Consistent, so less context switching between say Fedora and Debian.

74
00:03:44.280 --> 00:03:46.960
<v Speaker 2>Precisely, it makes a systeman's job much easier. You don't

75
00:03:46.960 --> 00:03:49.439
<v Speaker 2>have to relearn core system management stuff just because you

76
00:03:49.479 --> 00:03:50.280
<v Speaker 2>switch distros.

77
00:03:50.599 --> 00:03:54.800
<v Speaker 1>Now about those strong opinions. We mentioned the book Touches

78
00:03:54.840 --> 00:03:58.919
<v Speaker 1>on the Controversy around Systems, and it even cites Linus Torvalds,

79
00:03:59.120 --> 00:04:02.000
<v Speaker 1>the creator of the Linux kernel. What was his real

80
00:04:02.039 --> 00:04:03.639
<v Speaker 1>take on it? Because I think that gets.

81
00:04:03.439 --> 00:04:06.159
<v Speaker 3>Twisted sometimes it does, and what's fascinating here?

82
00:04:06.159 --> 00:04:08.560
<v Speaker 2>According to that twenty fourteen z ten At article our

83
00:04:08.639 --> 00:04:12.759
<v Speaker 2>source Sites, Linus actually stated he had no particularly strong

84
00:04:12.800 --> 00:04:14.439
<v Speaker 2>opinions on system itself.

85
00:04:14.719 --> 00:04:15.919
<v Speaker 1>Really yeah, okay.

86
00:04:16.319 --> 00:04:19.759
<v Speaker 2>His expressed issues were specifically aimed at some core developers being,

87
00:04:20.120 --> 00:04:24.439
<v Speaker 2>in his words, too cavalier about bugs and compatibility. He

88
00:04:24.480 --> 00:04:28.120
<v Speaker 2>also mentioned a dislike for binary logs as a design detail,

89
00:04:28.240 --> 00:04:30.920
<v Speaker 2>but he explicitly stated these were not big issues for

90
00:04:31.000 --> 00:04:34.759
<v Speaker 2>him personally, which really emphasizes that the core of the debate,

91
00:04:35.000 --> 00:04:38.279
<v Speaker 2>at least from his perspective, was more about specific technical

92
00:04:38.319 --> 00:04:42.040
<v Speaker 2>implementation details and maybe developer interactions, not a fundamental rejection

93
00:04:42.399 --> 00:04:43.199
<v Speaker 2>of systems role.

94
00:04:43.519 --> 00:04:46.920
<v Speaker 1>So more technical disagreements than a philosophical war against the

95
00:04:46.920 --> 00:04:47.639
<v Speaker 1>concept itself.

96
00:04:47.680 --> 00:04:49.600
<v Speaker 2>Pretty much. Yeah, it frames it as a technical.

97
00:04:49.360 --> 00:04:52.120
<v Speaker 1>Discussion that does reframe it, and the book even references

98
00:04:52.199 --> 00:04:55.920
<v Speaker 1>Leonard Poetering's twenty thirteen blog post aiming to debunk myths.

99
00:04:56.399 --> 00:05:00.439
<v Speaker 1>It really paints system does this comprehensive suite managing way

100
00:05:00.480 --> 00:05:02.360
<v Speaker 1>more than just an in its system traditionally?

101
00:05:02.360 --> 00:05:04.079
<v Speaker 2>Did it truly is? I mean, if you look at

102
00:05:04.079 --> 00:05:08.160
<v Speaker 2>the big picture, system manages almost everything in that critical

103
00:05:08.240 --> 00:05:11.879
<v Speaker 2>layer between the kernel and your user applications, like what

104
00:05:12.000 --> 00:05:18.120
<v Speaker 2>specifically hardware detection, process management, filesystem mounts, network configuration, log

105
00:05:18.160 --> 00:05:22.199
<v Speaker 2>collection via the journal, system timesink, security settings, The list

106
00:05:22.240 --> 00:05:22.600
<v Speaker 2>goes on.

107
00:05:22.800 --> 00:05:23.240
<v Speaker 3>Wow.

108
00:05:23.279 --> 00:05:25.079
<v Speaker 2>Now, our source is careful to point out it's not

109
00:05:25.160 --> 00:05:30.160
<v Speaker 2>everything everything. It leaves core genie utilities and graphical interfaces

110
00:05:30.160 --> 00:05:33.560
<v Speaker 2>to other projects, but it definitely covers a huge amount

111
00:05:33.600 --> 00:05:34.680
<v Speaker 2>of ground in that middle.

112
00:05:34.480 --> 00:05:38.920
<v Speaker 1>Layer, acting as a single standardized tool for deep system management.

113
00:05:39.040 --> 00:05:42.000
<v Speaker 2>Exactly, a big shift from the older, more fragmented ways.

114
00:05:42.319 --> 00:05:45.279
<v Speaker 1>Okay, so one system takes over during that Linux startup phase.

115
00:05:45.279 --> 00:05:47.879
<v Speaker 1>It's clearly doing a lot. How exactly does it get

116
00:05:47.920 --> 00:05:50.240
<v Speaker 1>your Linux system fully ready for you to log in

117
00:05:50.279 --> 00:05:51.079
<v Speaker 1>and start working?

118
00:05:51.240 --> 00:05:56.720
<v Speaker 3>What's the mechanism It orchestrates this pretty complex sequence of events,

119
00:05:57.279 --> 00:06:00.720
<v Speaker 3>primarily by managing services based on dependencies and bringing the

120
00:06:00.759 --> 00:06:02.160
<v Speaker 3>system up to certain targets.

121
00:06:02.319 --> 00:06:05.279
<v Speaker 1>Targets like run levels in system V sort of.

122
00:06:05.360 --> 00:06:08.439
<v Speaker 2>Yeah, they're similar in concept, but much more flexible. Think

123
00:06:08.439 --> 00:06:12.000
<v Speaker 2>of them as system states. For instance, graphical dot target

124
00:06:12.120 --> 00:06:15.240
<v Speaker 2>usually means a full graphical desktop environment is running.

125
00:06:15.360 --> 00:06:17.279
<v Speaker 1>Then multi user dot target that.

126
00:06:17.279 --> 00:06:20.040
<v Speaker 2>Typically means a console interface is ready, you know, for

127
00:06:20.120 --> 00:06:25.240
<v Speaker 2>server environments or non graphical logins systems. Sophisticated role here

128
00:06:25.399 --> 00:06:28.160
<v Speaker 2>is ensuring all the necessary dependencies for a given target,

129
00:06:28.839 --> 00:06:32.000
<v Speaker 2>all the services, mounts, et cetera, are loaded and running

130
00:06:32.319 --> 00:06:34.079
<v Speaker 2>before that target is considered reached.

131
00:06:34.160 --> 00:06:36.800
<v Speaker 1>And it does this in parallel, right, which speeds things up.

132
00:06:36.920 --> 00:06:40.600
<v Speaker 2>Yes, exactly. It parallelizes the service startup wherever possible, which

133
00:06:40.639 --> 00:06:43.600
<v Speaker 2>is one reason modern Linux systems tend to boot much

134
00:06:43.639 --> 00:06:45.040
<v Speaker 2>faster than older ones.

135
00:06:44.879 --> 00:06:47.439
<v Speaker 1>And the book gives us a fantastic practical tip for

136
00:06:47.519 --> 00:06:51.000
<v Speaker 1>actually seeing this complex dance unfold. Many of us just

137
00:06:51.040 --> 00:06:54.040
<v Speaker 1>see the pretty animated splash screen during boot. But there's

138
00:06:54.079 --> 00:06:55.879
<v Speaker 1>a way to peak behind that curtain, isn't there?

139
00:06:56.160 --> 00:06:59.079
<v Speaker 2>Yes, And it's an incredibly useful trick for any sised

140
00:06:59.160 --> 00:07:02.240
<v Speaker 2>men or even just a curious user. If you want

141
00:07:02.240 --> 00:07:05.600
<v Speaker 2>to see all the verbose boot messages, the kernel messages,

142
00:07:05.680 --> 00:07:09.160
<v Speaker 2>the system service startup messages, the raw stuff, the raw stuff. Yeah,

143
00:07:09.360 --> 00:07:12.480
<v Speaker 2>you can edit the et cetera default grub file. Look

144
00:07:12.519 --> 00:07:17.199
<v Speaker 2>for the line starting jerobcmd line lene wex okay, and

145
00:07:17.319 --> 00:07:20.399
<v Speaker 2>you just need to remove the parameters RHGB that stands

146
00:07:20.439 --> 00:07:24.240
<v Speaker 2>for red hat graphical boot and quiet. Then regenerate your

147
00:07:24.279 --> 00:07:26.199
<v Speaker 2>grubcinfig and reboot, and.

148
00:07:26.160 --> 00:07:27.959
<v Speaker 1>Then you see everything scrolling by.

149
00:07:28.160 --> 00:07:31.800
<v Speaker 2>You see everything. It's invaluable especially for troubleshooting boot problems.

150
00:07:31.839 --> 00:07:34.519
<v Speaker 2>You can see exactly where things hang or what failed

151
00:07:34.560 --> 00:07:34.920
<v Speaker 2>to start.

152
00:07:35.120 --> 00:07:37.720
<v Speaker 1>That's great for watching it happen live, but on modern

153
00:07:37.759 --> 00:07:40.759
<v Speaker 1>systems that stuff flies by super fast. If you need

154
00:07:40.800 --> 00:07:43.279
<v Speaker 1>to diagnose a problem from a previous boot, how can

155
00:07:43.319 --> 00:07:46.160
<v Speaker 1>you analyze what happened during startup at your own pace?

156
00:07:46.439 --> 00:07:50.360
<v Speaker 2>Ah? Right, that's where two critical tools come in. First,

157
00:07:50.399 --> 00:07:53.680
<v Speaker 2>there's the daymed's command that shows you kernel ring buffer

158
00:07:53.720 --> 00:07:57.040
<v Speaker 2>messages from the current boot. It's good for immediate insights

159
00:07:57.079 --> 00:07:59.759
<v Speaker 2>into hardware detection and initial kernel stuff.

160
00:07:59.439 --> 00:08:02.439
<v Speaker 1>Like the system first words for this session kind.

161
00:08:02.199 --> 00:08:06.240
<v Speaker 2>Of yeah, But for the full picture, persistent detailed information

162
00:08:06.480 --> 00:08:10.480
<v Speaker 2>from all system components, including system service messages and even

163
00:08:10.519 --> 00:08:13.079
<v Speaker 2>from pass boots, you absolutely turn to journal label. The

164
00:08:13.120 --> 00:08:16.279
<v Speaker 2>system journal exactly captures everything in a time sequenced order.

165
00:08:16.480 --> 00:08:19.079
<v Speaker 2>It's indexed and unless you review it all later with

166
00:08:19.240 --> 00:08:20.759
<v Speaker 2>really powerful filtering.

167
00:08:21.120 --> 00:08:24.360
<v Speaker 1>Speaking of foundational things needed to even boot, our source

168
00:08:24.399 --> 00:08:28.959
<v Speaker 1>brings up MBR versus GPT partitioning. This might seem like

169
00:08:28.959 --> 00:08:31.800
<v Speaker 1>a dry disc management detail, but why is this distinction

170
00:08:32.039 --> 00:08:34.039
<v Speaker 1>actually important for cissegminds today?

171
00:08:34.200 --> 00:08:37.720
<v Speaker 2>What's about understanding the foundations of your storage. Think of

172
00:08:37.759 --> 00:08:40.919
<v Speaker 2>it this way. MBR Master Boot Record. It's the older standard.

173
00:08:41.320 --> 00:08:44.759
<v Speaker 2>It was designed for a world where two terabytes seemed massive,

174
00:08:44.879 --> 00:08:47.440
<v Speaker 2>and its limits are It's limited to about two point

175
00:08:47.440 --> 00:08:50.879
<v Speaker 2>two terabyte disks and only four primary partitions, which is

176
00:08:51.320 --> 00:08:55.480
<v Speaker 2>pretty restrictive now definitely, and GPT GPT or guid Partition

177
00:08:55.600 --> 00:08:59.480
<v Speaker 2>Table is the modern standards. It supports vastly larger discs

178
00:08:59.600 --> 00:09:01.679
<v Speaker 2>to nine point four to four zetabytes, which is just

179
00:09:02.039 --> 00:09:04.679
<v Speaker 2>mind bogglingly huge and way more partitions.

180
00:09:04.759 --> 00:09:06.879
<v Speaker 1>Okay, size is one thing, anything else.

181
00:09:07.200 --> 00:09:10.759
<v Speaker 2>It's not just about size though. GPT also has built

182
00:09:10.799 --> 00:09:15.000
<v Speaker 2>in redundancy for the partition table itself, making it more resilient.

183
00:09:15.679 --> 00:09:18.919
<v Speaker 2>It's really about future proofing and reliability, even if you're

184
00:09:18.960 --> 00:09:22.799
<v Speaker 2>not managing petabyte rays today. It defines the possibilities.

185
00:09:22.879 --> 00:09:26.480
<v Speaker 1>Right, So systems up discs are partitioned, how do we

186
00:09:26.519 --> 00:09:29.279
<v Speaker 1>manage what's actually running? You mentioned system tatle what's happening

187
00:09:29.320 --> 00:09:31.759
<v Speaker 1>under the hood when we use that to start, stop,

188
00:09:31.879 --> 00:09:33.039
<v Speaker 1>or enable services.

189
00:09:33.360 --> 00:09:37.240
<v Speaker 2>System tatl is absolutely your main interface for talking to systems,

190
00:09:37.600 --> 00:09:40.840
<v Speaker 2>and what's really need is how systems organizes everything into units.

191
00:09:40.960 --> 00:09:41.240
<v Speaker 1>Units.

192
00:09:41.320 --> 00:09:44.759
<v Speaker 2>Yeah, these aren't some abstract idea. They're actual plaintext files

193
00:09:44.840 --> 00:09:47.639
<v Speaker 2>usually handing in dot service, dot mount, dot time, or

194
00:09:47.639 --> 00:09:50.519
<v Speaker 2>et cetera. They use a simple Dinine style format to

195
00:09:50.559 --> 00:09:52.360
<v Speaker 2>define how that resource behaves.

196
00:09:52.080 --> 00:09:54.600
<v Speaker 1>So they're readable, configurable, exactly.

197
00:09:54.279 --> 00:09:56.679
<v Speaker 2>Very transparent. Use system table to interact with these units.

198
00:09:56.720 --> 00:09:59.720
<v Speaker 2>List active ones, check the status of a specific service

199
00:10:00.039 --> 00:10:03.440
<v Speaker 2>system tail status strupt or start it, stop it, and

200
00:10:03.480 --> 00:10:06.000
<v Speaker 2>able to start automatically at boot. Yeah, it all revolves

201
00:10:06.000 --> 00:10:07.519
<v Speaker 2>around managing these unit files.

202
00:10:07.639 --> 00:10:11.720
<v Speaker 1>Okay, let's get practical running customs scripts that startup is

203
00:10:12.320 --> 00:10:14.919
<v Speaker 1>like Cisenman one oh one. Say I have a simple

204
00:10:14.919 --> 00:10:18.440
<v Speaker 1>script hello dot s in US lowcalbin. How would I

205
00:10:18.519 --> 00:10:20.759
<v Speaker 1>set that up to run once at boot using a

206
00:10:20.759 --> 00:10:23.240
<v Speaker 1>one shot service? What are the key steps?

207
00:10:23.320 --> 00:10:26.320
<v Speaker 2>That's a super common need. Yeah, a perfect use case

208
00:10:26.360 --> 00:10:28.919
<v Speaker 2>for a one shot service. You'd create a unit file,

209
00:10:29.159 --> 00:10:32.120
<v Speaker 2>maybe call it hello dot service probably in SS systems.

210
00:10:32.519 --> 00:10:34.000
<v Speaker 1>Inside that file you'd have a.

211
00:10:33.919 --> 00:10:36.279
<v Speaker 2>Few sections, you know, would have something like description my

212
00:10:36.360 --> 00:10:39.679
<v Speaker 2>hello shell script. Then the service section is key. You'd

213
00:10:39.679 --> 00:10:43.360
<v Speaker 2>put type one shot and crucially exc start uclocalbin hello

214
00:10:43.399 --> 00:10:45.240
<v Speaker 2>dot sh to tell it what command to run.

215
00:10:45.399 --> 00:10:45.919
<v Speaker 1>Makes sense.

216
00:10:46.120 --> 00:10:49.200
<v Speaker 2>I'd also strongly recommend adding standard output journal plus console

217
00:10:49.240 --> 00:10:51.879
<v Speaker 2>in the service section. That make sure any output from

218
00:10:51.919 --> 00:10:54.240
<v Speaker 2>your script gets captured in the system journal, which is

219
00:10:54.279 --> 00:10:57.519
<v Speaker 2>great for debugging. Good tip, and you need an install section,

220
00:10:57.639 --> 00:11:00.840
<v Speaker 2>usually with wanted by multi user dot com target. This

221
00:11:00.960 --> 00:11:03.759
<v Speaker 2>tell system when the service should be enabled, typically when

222
00:11:03.759 --> 00:11:05.799
<v Speaker 2>the system reaches a usable multi user state.

223
00:11:05.919 --> 00:11:07.799
<v Speaker 1>Okay, file created, now, what right?

224
00:11:07.960 --> 00:11:13.279
<v Speaker 2>Two crucial steps after creating or changing any unit file. First,

225
00:11:13.600 --> 00:11:17.279
<v Speaker 2>you have to run system tiled demon reload that tail

226
00:11:17.360 --> 00:11:20.320
<v Speaker 2>system to reread its configuration, including your new file.

227
00:11:20.399 --> 00:11:22.039
<v Speaker 1>Don't forget that one, definitely.

228
00:11:21.720 --> 00:11:24.639
<v Speaker 2>Don't forget that one. Then to actually activate it now

229
00:11:24.679 --> 00:11:27.159
<v Speaker 2>and make it run on future boots, you'd run system

230
00:11:27.200 --> 00:11:31.279
<v Speaker 2>teag'll enable now Hello dot service. They all starts it immediately.

231
00:11:31.399 --> 00:11:35.559
<v Speaker 1>Perfect, But what if that custom script, maybe it configures

232
00:11:35.600 --> 00:11:38.440
<v Speaker 1>a webserver or something, absolutely needs the network to be

233
00:11:38.559 --> 00:11:41.879
<v Speaker 1>fully up and running before it starts. I've definitely seen

234
00:11:41.879 --> 00:11:44.120
<v Speaker 1>scripts fail because they try to bind to an IP

235
00:11:44.240 --> 00:11:47.240
<v Speaker 1>address that wasn't quite ready yet. Just using wanted by

236
00:11:47.399 --> 00:11:49.360
<v Speaker 1>multi user dot target isn't enough, is it?

237
00:11:49.440 --> 00:11:49.600
<v Speaker 3>Oh?

238
00:11:49.600 --> 00:11:52.159
<v Speaker 2>Absolutely not. That's a really crucial point, And honestly it's

239
00:11:52.159 --> 00:11:54.679
<v Speaker 2>a very common trap for system and starting out with systems.

240
00:11:54.840 --> 00:11:55.080
<v Speaker 1>Yeah.

241
00:11:55.200 --> 00:11:58.159
<v Speaker 2>Yeah, simply having wanted by graphical dot target or multi

242
00:11:58.240 --> 00:12:02.039
<v Speaker 2>user dot target doesn't guarantee full network readiness. Those targets

243
00:12:02.039 --> 00:12:05.080
<v Speaker 2>can be considered reached even while network interfaces are still

244
00:12:05.080 --> 00:12:07.320
<v Speaker 2>coming up or getting IP addresses via.

245
00:12:07.360 --> 00:12:11.000
<v Speaker 1>DHCP, So your script runs too early exactly.

246
00:12:10.679 --> 00:12:13.559
<v Speaker 2>To make sure your service waits for a truly operational network,

247
00:12:13.799 --> 00:12:17.879
<v Speaker 2>meaning interfaces are up. IP addresses are assigned. Maybe even

248
00:12:17.919 --> 00:12:21.399
<v Speaker 2>default rights are said. You need to explicitly add two

249
00:12:21.519 --> 00:12:23.519
<v Speaker 2>lines to the unit section of your service file.

250
00:12:23.600 --> 00:12:24.399
<v Speaker 1>Okay, what are they?

251
00:12:24.480 --> 00:12:27.360
<v Speaker 2>You need after network dash online dot target and also

252
00:12:27.440 --> 00:12:30.720
<v Speaker 2>wants network dash online dot target. The networkdash online dot

253
00:12:30.720 --> 00:12:33.679
<v Speaker 2>target is specifically designed to signal that the network is

254
00:12:33.759 --> 00:12:35.039
<v Speaker 2>really truly ready for action.

255
00:12:35.279 --> 00:12:35.679
<v Speaker 3>Ah.

256
00:12:35.720 --> 00:12:38.440
<v Speaker 1>Okay, So after makes the weight and wants pulls it

257
00:12:38.480 --> 00:12:38.840
<v Speaker 1>in as.

258
00:12:38.720 --> 00:12:42.480
<v Speaker 2>A dependency basically yes, after it defines the ordering once

259
00:12:42.559 --> 00:12:46.440
<v Speaker 2>creates a dependency link. Using both is the robust way

260
00:12:46.480 --> 00:12:50.399
<v Speaker 2>to prevent those frustrating startup failures caused by network timing issues.

261
00:12:50.559 --> 00:12:53.039
<v Speaker 1>Now, when something inevitably does go wrong. You mentioned the

262
00:12:53.039 --> 00:12:55.600
<v Speaker 1>system journal. It really sounds like the go to place

263
00:12:55.639 --> 00:12:59.080
<v Speaker 1>for diagnosing almost any system issue, a single source.

264
00:12:58.840 --> 00:13:01.399
<v Speaker 2>Of truth it really aims to Yeah, the system journal

265
00:13:01.440 --> 00:13:04.399
<v Speaker 2>demon is incredibly powerful. Think of it as a universal

266
00:13:04.440 --> 00:13:06.279
<v Speaker 2>log collector built right into the core.

267
00:13:06.080 --> 00:13:08.159
<v Speaker 1>System universal How what does it collect?

268
00:13:08.519 --> 00:13:12.000
<v Speaker 2>It gathers pretty much all the logging data kernel messages

269
00:13:12.200 --> 00:13:16.720
<v Speaker 2>like from dimez, traditional cislog output from applications, the standard

270
00:13:16.720 --> 00:13:20.200
<v Speaker 2>output and standard error streams from services managed by systems,

271
00:13:20.480 --> 00:13:23.679
<v Speaker 2>audit records for security. You name it, wow, and it

272
00:13:23.879 --> 00:13:27.799
<v Speaker 2>aggregates all of this into a single structured time sequenced

273
00:13:28.080 --> 00:13:32.600
<v Speaker 2>index journal. The time sequencing is key. You could see

274
00:13:32.600 --> 00:13:35.360
<v Speaker 2>exactly what happened across totally different parts of the system

275
00:13:35.600 --> 00:13:37.080
<v Speaker 2>at a specific moment in time.

276
00:13:37.279 --> 00:13:41.960
<v Speaker 1>That sounds incredibly powerful for troubleshooting tricky intermittent problem.

277
00:13:42.080 --> 00:13:45.519
<v Speaker 2>It really is, especially for issues where multiple components might

278
00:13:45.559 --> 00:13:47.279
<v Speaker 2>be interacting in unexpected ways.

279
00:13:47.440 --> 00:13:49.480
<v Speaker 1>But with all that data pouring in, it must feel

280
00:13:49.480 --> 00:13:52.159
<v Speaker 1>like drinking from a fire hose Sometimes. What are your

281
00:13:52.200 --> 00:13:54.639
<v Speaker 1>go to journal? Podital tricks for cutting through the noise

282
00:13:54.679 --> 00:13:57.840
<v Speaker 1>and finding that specific error message or event when you're

283
00:13:57.840 --> 00:13:59.480
<v Speaker 1>trying to diagnose a problem quickly?

284
00:13:59.639 --> 00:14:02.320
<v Speaker 2>Right the string journal bityles filtering is essential. It's your

285
00:14:02.320 --> 00:14:04.559
<v Speaker 2>best friend here. You can narrow things down in lots

286
00:14:04.600 --> 00:14:06.879
<v Speaker 2>of ways. Okay, so, you can look at specific boot

287
00:14:06.919 --> 00:14:10.960
<v Speaker 2>instances with AMEB like masho B zero for the current boot,

288
00:14:11.279 --> 00:14:14.480
<v Speaker 2>magic bvers one for the previous one. That's super useful.

289
00:14:14.679 --> 00:14:16.519
<v Speaker 1>Okay, filter by boot, well.

290
00:14:16.399 --> 00:14:19.679
<v Speaker 2>You can filter by a specific unit with au so.

291
00:14:20.000 --> 00:14:24.000
<v Speaker 2>Journal at lu SSHD dot service shows only messages from

292
00:14:24.039 --> 00:14:28.879
<v Speaker 2>the sshdmon very handy. Nice time ranges absolutely since and

293
00:14:29.000 --> 00:14:31.600
<v Speaker 2>until your friend's there, you can use relative times like

294
00:14:31.720 --> 00:14:34.960
<v Speaker 2>since one hour ago or specific timestaps.

295
00:14:35.000 --> 00:14:36.879
<v Speaker 1>And you mentioned syslog facilities earlier.

296
00:14:37.000 --> 00:14:39.200
<v Speaker 2>Yeah, if you're used to traditional cyslog, you can still

297
00:14:39.240 --> 00:14:43.120
<v Speaker 2>filter by facility like journal atal facility mail to see

298
00:14:43.159 --> 00:14:46.720
<v Speaker 2>only mail related logs. It gives you incredible precisions.

299
00:14:46.320 --> 00:14:48.519
<v Speaker 1>So you can really zero in exactly.

300
00:14:48.720 --> 00:14:51.440
<v Speaker 2>The book even walks through a great example troubleshooting in

301
00:14:51.480 --> 00:14:55.159
<v Speaker 2>apatche HTTP service that fails because it started before the

302
00:14:55.200 --> 00:14:58.799
<v Speaker 2>network was ready. It shows precisely how journal Achiel helps

303
00:14:58.799 --> 00:15:01.200
<v Speaker 2>you find the error, see the timing issue, and then

304
00:15:01.200 --> 00:15:04.320
<v Speaker 2>realize you need that network dash online dot target fix

305
00:15:04.320 --> 00:15:05.080
<v Speaker 2>we just talked about.

306
00:15:05.120 --> 00:15:07.679
<v Speaker 1>Okay, let's broaden our view a bit beyond just starting

307
00:15:07.679 --> 00:15:11.720
<v Speaker 1>services and collecting logs. Systems influence extends further. Let's talk

308
00:15:11.720 --> 00:15:14.799
<v Speaker 1>about system time. Why is keeping accurate time such a

309
00:15:14.799 --> 00:15:17.679
<v Speaker 1>critical thing for a Linux server and how does system

310
00:15:17.720 --> 00:15:18.399
<v Speaker 1>to help.

311
00:15:18.480 --> 00:15:22.360
<v Speaker 2>Accurate time is? Well, it's fundamental for so many things.

312
00:15:22.399 --> 00:15:25.960
<v Speaker 2>You need it for security protocols like cerberos or TLS

313
00:15:26.000 --> 00:15:31.159
<v Speaker 2>certificates for ensuring log time stamps are actually meaningful for forensics.

314
00:15:30.879 --> 00:15:33.240
<v Speaker 1>Right, correlating events across systems.

315
00:15:33.000 --> 00:15:38.360
<v Speaker 2>Exactly, proper authentication in distributed networks scheduling tasks correctly. It

316
00:15:38.480 --> 00:15:40.480
<v Speaker 2>just has to be right. Our source points at the

317
00:15:40.519 --> 00:15:44.000
<v Speaker 2>Timesync relies on protocols like MTP Network.

318
00:15:43.679 --> 00:15:45.399
<v Speaker 3>Time Protocol and systems role.

319
00:15:45.320 --> 00:15:49.679
<v Speaker 2>System provide streamline tools. There's system D time sync, which

320
00:15:49.720 --> 00:15:52.159
<v Speaker 2>is a simple client for syncing time over the network.

321
00:15:52.600 --> 00:15:55.519
<v Speaker 2>And there's a unified command time detectable which lets you

322
00:15:55.600 --> 00:15:58.840
<v Speaker 2>manage the system clock, check the hardware clock, the RTC,

323
00:15:59.120 --> 00:16:01.600
<v Speaker 2>set the time zone, and see the sink status all

324
00:16:01.639 --> 00:16:02.240
<v Speaker 2>in one place.

325
00:16:02.600 --> 00:16:04.840
<v Speaker 1>So a cleaner interface for time management.

326
00:16:05.080 --> 00:16:08.000
<v Speaker 2>Yeah. It aims to make basic time synchronization and management

327
00:16:08.240 --> 00:16:09.519
<v Speaker 2>much simpler and more consistent.

328
00:16:09.639 --> 00:16:14.200
<v Speaker 1>And security another huge piece. Now. Firewalled isn't technically part

329
00:16:14.200 --> 00:16:17.360
<v Speaker 1>of the system's suite, right, but it's very commonly used

330
00:16:17.360 --> 00:16:17.639
<v Speaker 1>with it.

331
00:16:17.879 --> 00:16:21.000
<v Speaker 2>That's correct. It's not officially core systemed, but it's adopted

332
00:16:21.000 --> 00:16:24.919
<v Speaker 2>systems Command Structure, system devis style commands, and it's the

333
00:16:25.000 --> 00:16:30.879
<v Speaker 2>default firewall on many major system based distros like Fedora, RHL, Sentos.

334
00:16:30.960 --> 00:16:33.399
<v Speaker 1>What's its core philosophy? I hear about these zones.

335
00:16:33.799 --> 00:16:37.480
<v Speaker 2>The core idea is dynamic management based on trust levels.

336
00:16:37.919 --> 00:16:40.559
<v Speaker 2>The zones are key. They're pre defined sets of rules

337
00:16:40.559 --> 00:16:43.799
<v Speaker 2>for different network environments. You might have a public zone

338
00:16:43.799 --> 00:16:47.000
<v Speaker 2>for untrusted networks like coffee shop Wi Fi, a home

339
00:16:47.120 --> 00:16:50.159
<v Speaker 2>or trusted zone for your private network, maybe a DMZ

340
00:16:50.360 --> 00:16:52.519
<v Speaker 2>zone for servers that need to be exposed like.

341
00:16:52.480 --> 00:16:54.879
<v Speaker 1>Different security postures exactly, And.

342
00:16:54.879 --> 00:16:58.279
<v Speaker 2>The best practice, as our source emphasizes, is usually to

343
00:16:58.320 --> 00:17:01.240
<v Speaker 2>start with a zone that blocks almost everything by default,

344
00:17:01.279 --> 00:17:04.920
<v Speaker 2>like public, and then explicitly open only the specific ports

345
00:17:04.920 --> 00:17:08.519
<v Speaker 2>and services you absolutely need. Allow each TTP, allow SSH,

346
00:17:08.599 --> 00:17:09.240
<v Speaker 2>that kind of thing.

347
00:17:09.359 --> 00:17:11.119
<v Speaker 1>Least privilege for your network ports.

348
00:17:11.279 --> 00:17:14.599
<v Speaker 2>Precisely, it drastically reduces your potential attack surface.

349
00:17:14.680 --> 00:17:18.000
<v Speaker 1>So opening port eighty for a web server is straightforward.

350
00:17:18.279 --> 00:17:21.599
<v Speaker 1>But what about more dynamic situations like maybe you need

351
00:17:21.599 --> 00:17:23.839
<v Speaker 1>to open a port just for a quick test, or

352
00:17:23.880 --> 00:17:26.599
<v Speaker 1>you want to automatically block ips that are trying to

353
00:17:26.640 --> 00:17:28.559
<v Speaker 1>brute force your SSH log in.

354
00:17:28.759 --> 00:17:33.839
<v Speaker 2>Firewalled handles temporary rules quite elegantly. The firewall cmd command

355
00:17:34.160 --> 00:17:36.960
<v Speaker 2>lets you add services or ports with a timeout option,

356
00:17:37.200 --> 00:17:39.440
<v Speaker 2>so you can open something for say five minutes, and

357
00:17:39.440 --> 00:17:43.000
<v Speaker 2>the rule automatically disappears afterwards. Super useful for quick tests.

358
00:17:43.079 --> 00:17:45.359
<v Speaker 1>Oh that's handy, and the boot force attacks.

359
00:17:45.440 --> 00:17:48.759
<v Speaker 2>For that kind of adaptive security, you typically integrate firewalled

360
00:17:48.799 --> 00:17:50.759
<v Speaker 2>with a tool like failed to ban, fail to ban

361
00:17:50.920 --> 00:17:55.079
<v Speaker 2>monitors log files for patterns like repeated failed log in attempts.

362
00:17:54.640 --> 00:17:56.240
<v Speaker 1>And then tells the firewall, and then.

363
00:17:56.160 --> 00:17:59.119
<v Speaker 2>It dynamically tells firewalled or iptables. If you use that

364
00:17:59.400 --> 00:18:02.039
<v Speaker 2>to add a rule blocking the offending IP address for

365
00:18:02.079 --> 00:18:05.079
<v Speaker 2>a configurable period, it's a great way to automatically fend

366
00:18:05.119 --> 00:18:07.680
<v Speaker 2>off those noisy brute force attempts without you having to

367
00:18:07.720 --> 00:18:08.920
<v Speaker 2>constantly watch logs.

368
00:18:09.240 --> 00:18:12.279
<v Speaker 1>One last area of the book delves into is resource

369
00:18:12.359 --> 00:18:16.599
<v Speaker 1>management using SE groups. These seem increasingly important, especially with

370
00:18:16.640 --> 00:18:20.400
<v Speaker 1>containers everywhere. Now, what exactly are sick groups and why

371
00:18:20.400 --> 00:18:21.559
<v Speaker 1>are they such a big deal?

372
00:18:22.240 --> 00:18:25.039
<v Speaker 2>Groups or control groups are actually a Linux kernel feature,

373
00:18:25.440 --> 00:18:28.160
<v Speaker 2>but Systems makes heavy use of them and provides tools

374
00:18:28.160 --> 00:18:30.839
<v Speaker 2>to manage them. They allow you to allocate and crucially

375
00:18:31.119 --> 00:18:36.559
<v Speaker 2>limit system resources CPU time, memory usage, disc IO bandwidth

376
00:18:36.640 --> 00:18:38.599
<v Speaker 2>to groups of processes.

377
00:18:38.119 --> 00:18:40.799
<v Speaker 1>So you can stop one runaway process from killing the

378
00:18:40.799 --> 00:18:41.400
<v Speaker 1>whole server.

379
00:18:41.599 --> 00:18:45.039
<v Speaker 2>That's a primary use case. Before C groups were well integrated,

380
00:18:45.279 --> 00:18:48.240
<v Speaker 2>you could easily have one rogue application consume all the

381
00:18:48.359 --> 00:18:52.160
<v Speaker 2>CPU or memory, impacting everything else. Ce groups that you

382
00:18:52.160 --> 00:18:54.640
<v Speaker 2>set limits ensuring fair resource allocation.

383
00:18:54.799 --> 00:18:56.119
<v Speaker 1>How do you see these groups?

384
00:18:56.319 --> 00:18:59.720
<v Speaker 2>System provides tools like system dcgls to view the control

385
00:18:59.759 --> 00:19:02.319
<v Speaker 2>group hierarchy, or you can use system t wall with

386
00:19:02.400 --> 00:19:05.759
<v Speaker 2>options like ECC slice all to see the slices, which

387
00:19:05.799 --> 00:19:07.960
<v Speaker 2>are system's way of managing groups of units within c

388
00:19:08.119 --> 00:19:08.759
<v Speaker 2>groups and.

389
00:19:08.759 --> 00:19:09.519
<v Speaker 1>The container link.

390
00:19:09.680 --> 00:19:14.279
<v Speaker 2>The fit groups are absolutely fundamental technology for container platforms

391
00:19:14.279 --> 00:19:17.200
<v Speaker 2>like Docker and Kubernetes. There would allow containers to have

392
00:19:17.240 --> 00:19:21.559
<v Speaker 2>defined resource limits, making them predictable and preventing noisy neighbor problems.

393
00:19:21.599 --> 00:19:24.400
<v Speaker 2>So yeah, they're more relevant than ever for cisadmins today.

394
00:19:24.640 --> 00:19:29.440
<v Speaker 1>Okay, one final really crucial area. Our source highlights system's

395
00:19:29.519 --> 00:19:33.599
<v Speaker 1>influence on name services. How does your Linux box typically

396
00:19:33.680 --> 00:19:37.279
<v Speaker 1>figure out the IP address for SA www dot example

397
00:19:37.319 --> 00:19:41.359
<v Speaker 1>dot net and how has system d resolved changed that picture?

398
00:19:41.640 --> 00:19:45.319
<v Speaker 2>Right? Name resolution. Historically, you'd rely on your local ECHOS

399
00:19:45.400 --> 00:19:48.279
<v Speaker 2>file for quick lookups of local machines, and then at

400
00:19:48.359 --> 00:19:51.039
<v Speaker 2>krezol dot com would list DNS servers to query for

401
00:19:51.079 --> 00:19:55.039
<v Speaker 2>everything else. Pretty straightforward, But now in many modern Linux distributions,

402
00:19:55.079 --> 00:19:58.160
<v Speaker 2>system resolved often steps in as the central resolver service.

403
00:19:58.359 --> 00:20:01.759
<v Speaker 2>It manages DNS queries, can catch results, and sometimes uses

404
00:20:01.799 --> 00:20:05.680
<v Speaker 2>things like multicast DNS DNS for discovering services on your

405
00:20:05.720 --> 00:20:08.440
<v Speaker 2>local network without needing a dedicated DNS server.

406
00:20:08.400 --> 00:20:10.920
<v Speaker 1>So it tries to integrate and manage name resolution more

407
00:20:11.000 --> 00:20:12.359
<v Speaker 1>centrally exactly.

408
00:20:12.480 --> 00:20:16.279
<v Speaker 2>The goal is often simplification and unification, providing a standard

409
00:20:16.279 --> 00:20:19.039
<v Speaker 2>way to handle different name resolution protocols.

410
00:20:19.119 --> 00:20:22.759
<v Speaker 1>But our source describes a situation where this integrated approach

411
00:20:22.880 --> 00:20:27.640
<v Speaker 1>actually caused problems systems resolved, leading to slow web page loading,

412
00:20:27.960 --> 00:20:30.480
<v Speaker 1>timed out DNS queries. What was going on there?

413
00:20:30.680 --> 00:20:33.640
<v Speaker 2>Yeah, this is a really insightful troubleshooting example. In the book,

414
00:20:33.920 --> 00:20:37.440
<v Speaker 2>it highlights that sometimes these integrated systems can have unexpected

415
00:20:37.480 --> 00:20:40.240
<v Speaker 2>side effects. In that case, system resolves seem to be

416
00:20:40.240 --> 00:20:44.319
<v Speaker 2>introducing delays or bottlenecks, especially for websites that require resolving

417
00:20:44.319 --> 00:20:45.480
<v Speaker 2>many different host names.

418
00:20:45.559 --> 00:20:48.079
<v Speaker 1>And how does a cresolve dot com fit in when

419
00:20:48.119 --> 00:20:49.400
<v Speaker 1>system resolved is active?

420
00:20:49.759 --> 00:20:53.400
<v Speaker 2>That's key three. Solve dot coms isn't a static file anymore.

421
00:20:53.599 --> 00:20:56.559
<v Speaker 2>It's frequently a symbolic link pointing to a file managed

422
00:20:56.559 --> 00:21:00.440
<v Speaker 2>by system resolved, something like run system resolves, dubdash resolve

423
00:21:00.480 --> 00:21:03.680
<v Speaker 2>dot cof and that stub file typically just lists nameserver

424
00:21:03.880 --> 00:21:06.799
<v Speaker 2>one twenty seven point zero point five three pointing all

425
00:21:06.880 --> 00:21:09.279
<v Speaker 2>DNS queries to the local system resolved demon.

426
00:21:09.519 --> 00:21:12.799
<v Speaker 1>Ah, So if that local demon gets slower stuck, then.

427
00:21:12.640 --> 00:21:15.000
<v Speaker 2>All your DNS lookups can get slow or stuck. It

428
00:21:15.039 --> 00:21:17.519
<v Speaker 2>becomes a potential single point of failure or bottleneck for

429
00:21:17.599 --> 00:21:18.240
<v Speaker 2>name resolution.

430
00:21:18.640 --> 00:21:22.240
<v Speaker 1>So the modern integrated approach hit a snag in that scenario,

431
00:21:22.559 --> 00:21:26.279
<v Speaker 1>and the workaround described in the SORES involved basically bypassing

432
00:21:26.319 --> 00:21:29.240
<v Speaker 1>system resolved and going back to a more traditional setup.

433
00:21:29.880 --> 00:21:32.680
<v Speaker 1>What's the deeper lesson there for sissidmans working in this

434
00:21:32.799 --> 00:21:33.839
<v Speaker 1>heavily system.

435
00:21:33.519 --> 00:21:36.200
<v Speaker 2>To fight a world Yes, exactly. The solution in that

436
00:21:36.240 --> 00:21:39.720
<v Speaker 2>specific case involved removing the simlink for at creezol dot

437
00:21:39.720 --> 00:21:43.119
<v Speaker 2>com and also telling another tool off select to stop

438
00:21:43.160 --> 00:21:45.759
<v Speaker 2>managing exits in s switch dot cof n s.

439
00:21:45.640 --> 00:21:49.839
<v Speaker 1>Switch dot com that controls how lookups happen right hosts users.

440
00:21:49.559 --> 00:21:52.640
<v Speaker 2>Precisely dn't switch dot com dictates the order and sources

441
00:21:52.640 --> 00:21:56.079
<v Speaker 2>for various lookups. By taking control back from system resolved

442
00:21:56.079 --> 00:21:58.839
<v Speaker 2>and off select, it allowed either network manager to create

443
00:21:58.839 --> 00:22:01.880
<v Speaker 2>a traditional resolve dot com file putting directly to external

444
00:22:01.960 --> 00:22:05.759
<v Speaker 2>DNS servers, or allow the syssidmin to manually edit nswitch

445
00:22:05.799 --> 00:22:09.519
<v Speaker 2>dot com to prioritize the traditional nssdn's.

446
00:22:08.799 --> 00:22:11.359
<v Speaker 1>Mechanism so forcing it to use the old way for

447
00:22:11.440 --> 00:22:12.720
<v Speaker 1>DNS lookups.

448
00:22:12.440 --> 00:22:15.279
<v Speaker 2>Essentially yes, and the lesson I think is crucial. While

449
00:22:15.319 --> 00:22:19.759
<v Speaker 2>system brings powerful unification and standardization, sometimes its integrated components

450
00:22:19.759 --> 00:22:22.799
<v Speaker 2>can introduce unexpected issues or bottlenecks and specific.

451
00:22:22.480 --> 00:22:25.240
<v Speaker 1>Environments, so you still need to know the layers underneath.

452
00:22:25.279 --> 00:22:29.519
<v Speaker 2>Absolutely. It highlights that even with systems, understanding the underlying mechanisms,

453
00:22:29.599 --> 00:22:33.519
<v Speaker 2>how DNS resolution really works, how n switch operates, and

454
00:22:33.559 --> 00:22:36.119
<v Speaker 2>knowing when to peel back the layers and potentially revert

455
00:22:36.160 --> 00:22:39.759
<v Speaker 2>to more traditional, battle tested methods is still an essential

456
00:22:39.799 --> 00:22:44.319
<v Speaker 2>SISSEDMINS skill. It's about pragmatic problem solving, not just blindly

457
00:22:44.359 --> 00:22:45.279
<v Speaker 2>following the default.

458
00:22:45.400 --> 00:22:49.279
<v Speaker 1>Wow. Okay, that was a truly comprehensive deep dive into

459
00:22:49.359 --> 00:22:53.200
<v Speaker 1>system from its absolutely pivotal role as PAD one, the

460
00:22:53.240 --> 00:22:57.720
<v Speaker 1>initial process orchestrator, all the way through managing services, collecting logs,

461
00:22:57.720 --> 00:23:01.799
<v Speaker 1>synchronizing time, helping secure the network, work with firewalled, allocating

462
00:23:01.839 --> 00:23:05.759
<v Speaker 1>resources with sick groups, and even deeply influencing name resolution.

463
00:23:06.400 --> 00:23:09.559
<v Speaker 1>Its clear system is embedded in almost every aspect of

464
00:23:09.599 --> 00:23:10.799
<v Speaker 1>a modern Linux system.

465
00:23:10.920 --> 00:23:14.599
<v Speaker 2>It really is, and hopefully it's clearer now that understanding

466
00:23:14.640 --> 00:23:18.559
<v Speaker 2>these components, knowing your way around system tail leveraging journalectal

467
00:23:18.559 --> 00:23:23.000
<v Speaker 2>for diagnostics, understanding fireworlled zones, appreciating sick groups. It truly

468
00:23:23.039 --> 00:23:26.240
<v Speaker 2>empowers you, gives you the ability to manage and troubleshoot

469
00:23:26.240 --> 00:23:29.319
<v Speaker 2>your Linux environments with much greater confidence and precision.

470
00:23:29.640 --> 00:23:33.440
<v Speaker 1>Yeah, this journey through David Bolt's insights really helps demystify

471
00:23:33.480 --> 00:23:36.200
<v Speaker 1>the system, doesn't it turning what can sometimes feel like

472
00:23:36.240 --> 00:23:40.319
<v Speaker 1>a complex black box into a much clearer operational picture. Definitely,

473
00:23:40.519 --> 00:23:44.039
<v Speaker 1>And it really underscores the continuous evolution of Linux. It

474
00:23:44.119 --> 00:23:46.920
<v Speaker 1>shows the power of standardization when it works well, but

475
00:23:47.000 --> 00:23:50.519
<v Speaker 1>also the absolute necessity of understanding those underlying layers when

476
00:23:50.559 --> 00:23:53.920
<v Speaker 1>things don't go as planned. So thinking about that evolution

477
00:23:54.240 --> 00:23:58.799
<v Speaker 1>for you, our listener, Given system's incredibly extensive reach and

478
00:23:58.880 --> 00:24:03.079
<v Speaker 1>the ongoing drive for standardization and Linux, what aspect of

479
00:24:03.079 --> 00:24:05.799
<v Speaker 1>system management do you think might be the next to

480
00:24:05.839 --> 00:24:09.559
<v Speaker 1>be fundamentally rethought or standardized? What could be the system

481
00:24:09.640 --> 00:24:12.359
<v Speaker 1>moment for another core Linux component down the road?

482
00:24:12.640 --> 00:24:14.880
<v Speaker 2>Hmmm, that's a great question to ponder.

483
00:24:14.680 --> 00:24:17.799
<v Speaker 1>It is. We encourage you to keep exploring, keep experimenting

484
00:24:17.799 --> 00:24:20.400
<v Speaker 1>with your systems, and of course keep sharing your discoveries.

485
00:24:20.519 --> 00:24:21.960
<v Speaker 1>Thanks for joining us on the deep dive