Linux系统管理实战：文件权限、用户与网络配置

Linux record 05，是我这套学习记录里的第五篇。写记录这件事，最早是因为自己记性不太好，每次在Linux上折腾完一个功能，隔一阵子就忘得一干二净，后来索性养成习惯：遇到问题、查资料、搞定问题、复现一遍，然后按自己的话写下来。这篇的内容正好是“会敲命令”往“会管系统”过渡的那一段，覆盖文件权限、用户管理、系统服务、网络配置、软件安装、Shell脚本，还有一大串我在实际操作里踩过坑又填平的问题。如果你正在学Linux，或者准备运维、嵌入式相关的面试，这篇里的命令和建议可以直接拿去练手。

我的实验环境很普通：一台装了VMware的Windows机器，虚拟机里分别装了Rocky Linux 9和Ubuntu 22.04，一个用来模拟服务器场景，一个用来折腾桌面和日常环境。为什么要搞两个发行版？因为Linux这个生态里，不同发行版之间有共性也有差异，只盯着一个系统容易产生“原来Linux就这么点东西”的错觉，换一个发行版马上就能发现新世界。这篇记录里，大部分命令在主流发行版上都能直接用，少部分涉及网卡配置的地方我会单独说明。

1. 内容整体设计与思路拆解

1.1 为什么学习路线要按“命令→管理→脚本”推进

很多刚接触Linux的朋友最容易掉进一个坑：疯狂背命令。今天记住一个ls -l，明天背一个ps aux，好像命令知道得越多就越厉害。但真到了排查问题或者搭服务的时候，还是不知道从哪下手。

我的看法是，命令只是操作系统的“表面接口”，真正值钱的是对系统机制的理解。文件权限为什么这么设计？用户和组到底在解决什么问题？进程状态是怎么流转的？网络配置为什么有时候改了不生效？这些机制搞明白了，命令不用刻意背，用几次自然就记住了。

所以到第五篇这个节点，我刻意把重心从“单个命令的用法”转移到“用命令解决系统管理问题”。这一篇选择的主题，围绕四个核心方向展开：

• 系统最基础的资源抽象：文件、权限、用户、进程
• 系统与外部通信的关键环节：网络接口与IP配置
• 系统能力扩展的常用手段：软件安装、环境变量、存储挂载
• 系统自动化的起点：Shell脚本与定时任务

这个顺序也是我实际学习时走的路线，先理解单机上的核心机制，再扩展网络和软件层面的能力，最后用脚本把重复操作固化下来。

1.2 发行版选择背后的实际考量

之前有朋友问我，到底选哪个发行版练手比较好。这其实没有标准答案，完全取决于你打算拿Linux干什么。

我自己的选择是Rocky Linux + Ubuntu双开。Rocky Linux是从RHEL（Red Hat Enterprise Linux）分支来的，企业服务器上用它的比例相当高，很多公司生产环境的操作习惯、网卡配置方式、软件包管理都延续这一套。Ubuntu则胜在资料多、桌面友好、软件源更新积极，适合日常使用和嵌入式开发场景。

我建议你也这样做：选定一个“主力”发行版深入学习，同时至少熟悉另一个系的基本操作。因为面试和实际工作中，你很难要求公司“换一个发行版再让我干活”，熟悉不同体系的差异，本身就是竞争力。

1.3 虚拟机是我最推荐的学习环境

我在前几篇记录里反复强调过虚拟机的好处，这里再啰嗦一遍：快照功能太香了。系统改坏了？快照回滚。软件装出依赖冲突？快照回滚。甚至在练习分区、格式化、修改启动项这些危险操作时，虚拟机都是最安全的实验场。

把系统安装好之后，第一步建议先做一次干净快照，起个名字叫“base-clean”。后面所有折腾都基于这个快照开始，出了问题随时回来。我身边不少同事刚开始学Linux的时候都是在虚拟机里练的，等到真正熟练了再考虑物理机安装。

2. 核心细节解析与实操要点

2.1 文件权限：看懂rwx才算是真正入门

Linux最核心的设计哲学就是“一切皆文件”，而文件的安全性，靠的是一套权限模型。很多人觉得权限枯燥，但它恰恰是理解多用户系统的钥匙。

先看一个最常见的权限表示：

-rw-r--r--. 1 root root 1024 Mar 12 10:30 myfile.txt

第一位的-表示这是一个普通文件，如果是d就是目录。后面九个字符分成三组，每组三个，分别对应该文件的所有者（owner）、所属组（group）、其他用户（others）。每组里的r代表读权限，w代表写权限，x代表执行权限。

用门禁卡来类比可能更好理解：所有者就是办卡的人，组就是同一个部门的人，其他用户就是外面的访客。r、w、x分别对应“能不能进会议室看资料”“能不能改资料”“能不能运行资料里的程序”。

实际操作中，我经常用chmod和chown来调整权限和属主：

# 给所有者增加执行权限 chmod u+x myscript.sh # 设置所有者读写执行，组读执行，其他人无权限 chmod 750 myscript.sh # 修改文件属主为john，属组为devteam chown john:devteam myscript.sh

数字权限的算法也很简单：r=4，w=2，x=1，加起来就行。750就是所有者7（4+2+1）、组5（4+1）、其他人0。这套换算我建议肌肉记忆，因为几乎所有服务器环境都会用到。

关于目录的权限，这里有个很多人忽略的坑：目录的r权限只代表能列出目录里的文件名，但能不能进入目录、能不能访问目录里的文件，取决于x权限。如果目录没有x，就算有r，你cd进去也会报Permission denied。我遇到过不止一次，用户说“我明明能ls，怎么进不去”，根因就是目录缺了x。

2.2 用户和组的管理：多用户系统的地基

Linux是一个天然的多用户操作系统，从一开机就是多用户设计的。了解用户管理，不只是会敲几条useradd命令，而是要理解用户信息存在哪、认证信息怎么保护、组有什么用。

用户信息主要存两个文件：/etc/passwd存用户的基本信息，/etc/shadow存加密后的密码和密码策略信息。看看/etc/passwd里一行内容的字段：

john:x:1000:1000:John Doe:/home/john:/bin/bash

依次是：用户名、密码占位符、用户ID（UID）、组ID（GID）、用户描述、家目录、默认Shell。密码字段显示x，说明真正的密码放在shadow文件里，普通用户没有读取权限。

新建用户时我最常用的一组命令是这样的：

# 创建用户，同时创建家目录，指定附加组wheel（sudo组） useradd -m -G wheel john # 设置初始化密码 passwd john # 查看用户信息 id john

-m参数自动建家目录，我建议每次都带上，否则很多用户登录后会找不到自己的目录。-G指定附加组，Rocky Linux里管理员组叫wheel，Ubuntu里叫sudo，这是两系发行版的一个明显差异。

用户组的核心价值在于共享权限。比如开发团队有/data/project目录，想让组内所有成员都能读写，就可以设置目录属组为devteam，再给组赋予读写权限：

groupadd devteam usermod -a -G devteam john usermod -a -G devteam jane chown root:devteam /data/project chmod 770 /data/project

只要用户加入devteam组，再去访问这个目录就有权限，不需要逐个人单独授权。这就是组的“批量授权”思想。

2.3 进程管理：看透系统状态的关键

进程这个概念听起来抽象，其实就是系统里正在运行的程序实例。每一个命令、每一个服务，归根到底都是进程。排查系统卡顿、服务异常，第一步永远是看进程和资源。

我排查问题时的顺序通常是：ps看进程状态，top或htop看资源占用，free看内存，df看磁盘，最后结合日志定位。先看一组基础命令：

# 查看所有进程的完整信息 ps -ef # 按CPU使用率排序查看进程 ps aux --sort=-%cpu | head -20 # 查看某个服务的运行状态 systemctl status sshd # 以实时方式查看系统资源 top

ps输出里有个STAT列，代表进程状态。常见的有：S睡眠状态、R运行状态、T停止状态、Z僵尸状态。如果看到大量Z状态的僵尸进程，通常说明父进程没有正确处理子进程退出，需要留意。

top界面的第一行有个load average，三个数字分别代表过去1分钟、5分钟、15分钟的系统负载。这个值不是越高越坏，要结合CPU核数看：如果负载接近或超过核数，说明系统可能过载了。四核机器负载长期4.0以上，就该看看哪个进程在捣乱。

顺带说一句systemctl，这是现代Linux系统管理服务的核心工具。它的背后是systemd，负责系统和服务的启动、停止、守护。常用操作：

# 启动服务并设置为开机自启 systemctl enable --now httpd # 查看服务是否正常 systemctl status httpd # 重新加载配置文件（改动配置后执行） systemctl daemon-reload

我建议你把服务管理统一用systemctl，不要再去手动执行/etc/init.d/xxx start这种老式命令了，虽然兼容，但容易被systemd的管理逻辑干扰。

2.4 网络配置：从网卡文件到连通性排查

虚拟机里最常遇到的一类问题就是“网络不通”。这类问题其实有一套固定的排查路径，顺着路径走，大多数都能解决。

在Rocky Linux这类RHEL系发行版上，网卡配置现在主要由NetworkManager管理，配置文件在/etc/NetworkManager/system-connections/目录下。老一点的系统可能还会看到/etc/sysconfig/network-scripts/ifcfg-xxx文件，两种可能都会遇到。

我个人习惯优先使用nmcli这个命令行工具来配置网络，因为它比直接改文件更直观，而且能自动化生成配置。比如把ens160网卡改成静态IP：

# 查看网卡和连接状态 nmcli device status # 修改连接配置，使用静态IP nmcli connection modify ens160 \ ipv4.addresses 192.168.1.100/24 \ ipv4.gateway 192.168.1.1 \ ipv4.dns 114.114.114.114 \ ipv4.method manual # 使配置生效 nmcli connection up ens160

这里有个容易踩坑的地方：连接名和网卡名有时候不是同一个。用nmcli connection show看到的“NAME”才是连接名，改配置要针对连接名而不是网卡名。我一开始就老在这上面栽跟头，改了老半天网卡名，提示找不到连接。

改完配置之后，验证连通性的顺序也很重要：

# 1. 看IP是否配置成功 ip addr show ens160 # 2. 看网关通不通 ip route # 3. 先ping网关，再ping外网 ping -c 4 192.168.1.1 ping -c 4 8.8.8.8

如果网关能ping通、外网ping不通，大概率是DNS或者出口路由的问题。很多新手一上来就直接ping外网，ping不通就慌了，其实分步排查更快。

3. 实操过程与核心环节实现

3.1 新建用户并授予sudo权限的完整过程

这个需求非常常见，相当于“给新同事开一个系统账号并给他管理授权”。我以前遇到过不少次，因为少带了参数导致用户登录不了或者权限不对，所以现在都按固定流程来做。

假设我要创建一个叫devops的用户，把它加入管理员组，并设置好登录环境：

# 创建用户并创建家目录 useradd -m devops # 设置初始密码，会提示输入两次 passwd devops # 用id确认用户信息 id devops # 加入sudo/wheel组 usermod -a -G wheel devops # 验证sudo权限配置是否正确 su - devops sudo whoami

如果执行sudo whoami返回root，说明sudo权限配置成功。这里需要注意几个细节：

• useradd如果不带-m，某些系统配置下不会创建/home/devops目录，用户登录后会出现在根目录，容易造成各种奇怪问题。
• usermod -a -G里的-a千万别漏。如果不加-a，用户会被从原来所属的附加组里移除，改成只有wheel一个附加组。
• 有些发行版的sudo配置默认启用了一个叫secure_path的机制，导致你自己设置的变量在sudo执行时被重置。如果遇到“sudo提示命令找不到，但直接执行却正常”的情况，基本就是这个原因。

我还遇到过一种情况：用户能正常登录，但执行sudo时提示“user is not in the sudoers file”。明明我已经把他加入wheel组了，为什么还不行？后来发现，那个系统的sudo配置里，%wheel这一行被注释掉了。检查/etc/sudoers文件，确保有下列行：

%wheel ALL=(ALL) ALL

修改sudoers文件要用visudo命令，不要直接vim编辑，因为visudo会做语法检查，避免改坏后sudo完全无法使用。

3.2 使用nmcli配置静态IP并验证连通性

我在虚拟机里做静态IP配置的频率很高，因为DHCP分配的IP每次变化之后，之前连好的SSH会话就断了，非常打断思路。干脆固定一个IP。

先把当前网卡和连接情况摸清楚：

nmcli device status nmcli connection show

假设设备名是ens160，连接名也是ens160（如果不是，后面命令里的连接名要改）。然后执行修改：

nmcli connection modify ens160 \ ipv4.addresses 192.168.10.50/24 \ ipv4.gateway 192.168.10.1 \ ipv4.dns "192.168.10.1 223.5.5.5" \ ipv4.method manual nmcli connection up ens160

配置完成后，用前面说过的步骤验证。这里有个经验：如果改动不生效，先看ip addr的输出，确认IP是否真的变了；如果没有变化，执行nmcli connection reload再nmcli connection up ens160一次，有时候NetworkManager的状态没有刷新，需要人为触发一次。

我还建议顺手把主机名改一下，方便辨识：

hostnamectl set-hostname node1.lab.local

主机名这种东西，看起来不起眼，但在多台虚拟机同时跑的时候，能帮你省去大量“我这是在操作哪台机器”的困惑。

3.3 编写一个系统信息收集脚本并加入定时任务

脚本能力是Linux学习中非常关键的一环。它能把你平时手动敲的命令固化下来，一气呵成地收集系统状态。这项技能在排查问题和日常巡检里非常实用。

我写了一个简单的系统信息收集脚本，逻辑很直白，就是逐项输出基本信息，追加到日志文件：

vim /usr/local/bin/sys_info.sh

脚本内容如下：

#!/bin/bash # 系统信息收集脚本 # 输出时间、系统版本、负载、内存、磁盘使用情况 # 每次执行追加到 /var/log/sys_info.log LOG_FILE="/var/log/sys_info.log" { echo "==================== $(date '+%F %T') ====================" echo "--- 系统信息 ---" uname -a cat /etc/os-release | grep -E "^(NAME|VERSION)=" echo "--- 负载情况 ---" uptime echo "--- 内存使用 ---" free -h echo "--- 磁盘使用 ---" df -h | grep -E "^(Filesystem|/dev/)" echo "" } >> "$LOG_FILE" echo "信息已追加到 $LOG_FILE"

给脚本加上执行权限：

chmod +x /usr/local/bin/sys_info.sh

先手动运行一次确认输出正常：

/usr/local/bin/sys_info.sh

然后加入定时任务，让系统每天自动执行一次：

crontab -e

在打开的文件里加一行：

0 2 * * * /usr/local/bin/sys_info.sh

这代表每天凌晨2点执行一次脚本。定时任务配置好之后，建议用下面的命令确认任务确实被写入：

crontab -l

写脚本时我读了几个小经验，值得分享：

• 脚本头部务必写#!/bin/bash，否则系统可能用错误的解释器执行。
• 涉及路径的变量用大写命名，一眼能看出是常量，比如LOG_FILE。
• 在脚本里不要只做一件事，可以像上面这样把多个相关命令组合在一起，方便之后扩展。
• 如果脚本涉及的业务逻辑较复杂，在关键位置加set -x可以输出调试执行过程，排查完再关掉。

3.4 安装JDK并配置环境变量的两种方式

对应很多人搜过的“linux配置jdk1.8”，我把两种安装方式都记录一下。第一种是用系统包管理器安装，简单省心；第二种是使用官方tar包解压安装，适合需要定制版本和路径的场景。

方式一：用包管理器安装

Rocky Linux上：

dnf install -y java-1.8.0-openjdk java-1.8.0-openjdk-devel

Ubuntu上：

apt update apt install -y openjdk-8-jdk

安装完成后，验证版本：

java -version

这种方式会自动配置好环境变量，对新手最友好。

方式二：使用tar包安装

先去官网下载JDK压缩包，放到/opt目录后解压：

cd /opt tar -zxvf jdk-8u202-linux-x64.tar.gz

然后配置环境变量，编辑/etc/profile或用户级别的~/.bashrc：

export JAVA_HOME=/opt/jdk1.8.0_202 export PATH=$JAVA_HOME/bin:$PATH

修改完后让配置生效：

source /etc/profile

如果系统里已经安装过其他版本的OpenJDK，可能会发生java -version仍然指向旧版本的情况。这时候可以检查which java的路径，确认为/opt/jdk1.8.0_202/bin/java。如果不对，可能需要在PATH设置上调整顺序，让自定义路径排在前面。

3.5 挂载磁盘与NAS存储并写入fstab

存储挂载是服务器环境里非常频繁的操作。这一节把两种场景讲清楚：挂载一块新磁盘、挂载NAS网络存储。

先讲新磁盘，假设新磁盘设备名是/dev/sdb1，要挂载到/data目录：

# 创建挂载点 mkdir -p /data # 查看磁盘是否被系统识别 lsblk # 格式化磁盘为ext4（注意：会清空磁盘数据） mkfs.ext4 /dev/sdb1 # 临时挂载 mount /dev/sdb1 /data # 查看挂载结果 df -h /data

要让重启后仍然自动挂载，需要写入/etc/fstab。这一步非常关键，也稍微有点风险。正确做法是先编辑fstab，然后在挂载前先用mount -a做一次测试：

echo "/dev/sdb1 /data ext4 defaults 0 0" >> /etc/fstab mount -a

如果mount -a之后没有报错并且df -h能看到，说明配置无误。如果在写入fstab后执行mount -a报错，一定要先修正，然后再重启。因为fstab出错会导致系统启动时挂载失败，甚至卡在维护模式。

网络存储挂载也很常见，尤其是NFS（Network File System）。远程服务器192.168.10.10导出了/nfs_share目录，客户端挂载方式如下：

# 安装nfs客户端 dnf install -y nfs-utils # 查看远端可用的nfs共享 showmount -e 192.168.10.10 # 挂载到本地/mnt/nas mount -t nfs 192.168.10.10:/nfs_share /mnt/nas # 写入fstab实现开机自动挂载 echo "192.168.10.10:/nfs_share /mnt/nas nfs defaults,_netdev 0 0" >> /etc/fstab

NFS挂载的_netdev参数很实用，它告诉系统“等到网络就绪后再挂载”，避免开机时因为网络未启动导致挂载失败。没有这个参数，NFS挂载在网络环境不稳定的机器上经常翻车。

4. 常见问题与排查技巧实录

4.1 虚拟机安装Linux蓝屏怎么办

“虚拟机安装linux蓝屏”这个词能被大量搜索，说明这个问题太普遍了。蓝屏通常出现在安装过程中，尤其是在启动安装界面的那一刻。

我排查的思路是这样的，按概率从高到低：

• 虚拟化引擎没开：在VMware的虚拟机设置里，勾选“虚拟化Intel VT-x/EPT或AMD-V/RVI”选项。这个开关没开，某些新版本内核的发行版确实会蓝屏。
• 镜像文件损坏或不完整：下载系统镜像后，最好校验一下SHA256校验值，避免下载过程中数据出错。
• 内存分配过少：安装桌面版Linux时，建议至少分配2GB内存，低于这个值安装程序可能在启动图形界面时崩溃。
• 选了错误的系统类型：创建虚拟机时选择“Linux”和对应的版本，比如RHEL 9 64位，选择错误也有可能导致兼容性问题。

另外，如果在Windows虚拟机里装Linux时出现蓝屏，可以先尝试修改虚拟机显示模式，把“加速3D图形”取消勾选再试一次。

4.2 网卡没有IP或重启后IP丢失

这个问题有两种典型表现：一是刚装完系统就没有IP，二是配置好静态IP后重启又变回去了。

没有IP的排查：

# 1. 确认网卡是否存在 ip link # 2. 确认NetworkManager是否运行 systemctl status NetworkManager # 3. 查看连接配置 nmcli connection show

如果NetworkManager没运行，先启动：

systemctl enable --now NetworkManager

如果是“重启IP丢失”，多数是因为网络连接没有设置为自动连接：

nmcli connection modify ens160 connection.autoconnect yes nmcli connection up ens160

这里有个细节：修改配置后一定要nmcli connection up一次，让新的autoconnect配置生效。如果只是改完就重启，某些环境下配置可能没有被正确保存。

4.3 输入法无法切换中英文

在Linux桌面上最影响日常使用的就是输入法。我在Ubuntu上遇到过装了输入法框架但无法切出中文面板的情况，原因通常是环境变量没设置好。

以使用fcitx5为例，确保以下环境变量存在：

export GTK_IM_MODULE=fcitx export QT_IM_MODULE=fcitx export XMODIFIERS=@im=fcitx

这些变量一般写入~/.xprofile或~/.pam_environment里，设置完成后需要注销重新登录，光source文件往往不彻底。

另外确认输入法框架是否启动：

fcitx5 -d

如果命令提示找不到，说明输入法主程序没装完整。Ubuntu上执行：

sudo apt install fcitx5 fcitx5-chinese-addons sudo im-config -n fcitx5

4.4 用户密码过期提醒与强制修改

服务器上启用密码过期策略很常见，但带来的问题是用户登录时不断被提醒修改密码，甚至直接无法登录。这也是“Linux密码过期提醒通知”背后大家常遇到的实际场景。

查看用户的密码过期信息：

chage -l devops

相关字段含义：

• 密码最后修改时间
• 密码最短使用期限
• 密码最长使用期限
• 密码过期警告天数

如果需要强制用户下次登录时必须改密码：

chage -d 0 devops

把密码最后修改日期设为0，用户会收到过期提示，并在本次登录时强制修改密码。如果希望某天之后密码不过期：

chage -M 99999 devops

这个就是设置密码最长有效期，“99999”表示无限期。

我还遇到过一个案例：某用户说登录时提醒“密码过期，请更改”，但改密码后又提示“密码太短”。这是因为系统有密码复杂度策略，要么按规则设置更强的密码，要么调整策略模板里的配置参数。RHEL系通常由libpwquality的配置文件控制，路径在/etc/security/pwquality.conf。

4.5 修改进程名称的几种方式

“linux 修改进程名称”这个需求，我在后台服务和脚本场景里都用过。进程名之所以有时需要改，是为了方便后台进程监控时能一眼认出对应的任务。

如果是启动一个脚本，可以用exec -a指定argv[0]：

exec -a my_custom_name /usr/bin/python3 /opt/scripts/daemon.py

这种方式改的是进程显示名，在很多场景下够用。

如果是systemd服务，可以在service文件里指定进程启动参数，例如：

[Service] ExecStart=/usr/bin/python3 /opt/scripts/daemon.py

它本身不改进程名，但可以通过systemctl status直接看到服务名。如果一定要修改进程名，更常见的做法是直接在程序内部用prctl接口设置，或者对Python来说可以setproctitle库。

从运维角度看，我其实建议优先用systemd服务来管理后台任务，而不是自己后台执行。因为systemd可以管理日志、自动重启、资源限制，这些能力是裸脚本进程不具备的。

4.6 sudo执行报错的典型原因

sudu报错基本集中在这么几类：

• user is not in the sudoers file：用户没有被授权。把用户加入wheel或sudo组就行了。
• sudo: command not found：在secure_path里找不到命令，但当前用户shell里能直接执行。这说明命令路径不在sudo的安全路径里，要么调整secure_path，要么执行时写明绝对路径。
• sorry, you must have a tty to run sudo：这是Linux里禁用了普通用户无终端执行sudo，常见于自动化脚本里执行sudo命令时报错。可以在/etc/sudoers里注释掉Defaults requiretty一行来关闭这个限制，但一般情况下不建议在生产环境这么做，因为它会降低安全性。

排查sudo问题时，有一个高价值的技巧：打开sudo日志。RHEL系默认记录在/var/log/secure，先查日志再猜原因会高效很多：

grep sudo /var/log/secure | tail -20

5. 常用命令速查与自我测试清单

这一节不是罗列所有命令，而是把这一篇里反复出现、后续也会高频使用的命令做一个精炼汇总，可以当作自查清单使用。能不看笔记写出每一个场景对应的命令，说明基本功就到位了。

除了命令本身，我还整理了几个自测问题，能想明白这些问题，比单纯背命令有价值得多：

• 为什么目录权限需要x才能进入？
• 为什么/etc/passwd对所有用户可读，但/etc/shadow不行？
• ps aux输出的CPU和内存使用率，分别代表进程启动以来还是实时状态？
• 静态IP配置后，重启为什么会被重置？有哪些可能的原因？
• chmod 777的问题在哪里？生产环境为什么强烈不建议使用？

如果这些问题让你有“模模糊糊”的感觉，建议回到前面对应的小节再读一遍。能自己讲清楚，才算真正掌握。

6. 写在记录之后的一点感受

写这篇记录时，我又重新走了一遍从用户创建到网络配置再到脚本运行的流程，意外发现自己的操作方式比前几篇记录时顺畅了不少。这就是记录带来的复利效应：每次重写都是对知识的二次整理，抬头看自己走过的路，才知道进步在哪里。

如果你看完这篇觉得内容密度有点大，没关系，正常。Linux本来就不是一天啃下来的东西。我的建议是：搭一台虚拟机，按这篇的顺序，把用户创建、静态IP、系统脚本、磁盘挂载四个任务各做一遍，不需要做到完美，哪怕只把其中一个任务跑通，就已经比单纯“看教程”有效十倍。

下一篇记录我大概率会往服务部署方向走，比如用Linux跑一个小型Web服务，或者用脚本定时备份。这类内容在实际工作中使用频率高，也更能把之前零零散散的命令串起来。到时候再继续更新。这一篇就到这儿，接下来该练手的练手，该查缺补漏的查缺补漏。