最近把Linux课程那份"作业1"从头到尾完整做了一遍，从下虚拟机、装系统开始，一路折腾到换源、建用户、配权限、管理进程、写自动化脚本、部署nginx，最后还处理了两个系统故障案例。做完之后最大的感受是：这哪是什么课后作业，分明就是一份浓缩版的上岗培训。从环境安装到日常运维的主干流程，全被这一份作业串起来了。这篇文章就按我实际操作的先后顺序，把整个过程、用到的命令、踩过的坑全部复盘一遍。正准备入门Linux的同学可以直接照着做，已经入行的开发者也可以把它当作查漏补缺的参考，面试前突击一下Linux常用命令和常见问题也够用。

先说结论：Linux学习确实没有捷径，但如果你带着一份具体的作业目标去学，效率会比单纯翻命令手册高出一大截。后面所有内容都是我这次实操的真实记录，每一步都验证过，可以直接抄。

1. 作业任务拆解与环境准备

1.1 拿到作业后，我先把它拆成了六个任务

"linux作业1"这个标题虽然朴素，但里面的子任务一点都不少。作业原要求大概是搭建一套Linux运行环境，完成基础的系统管理操作，包括创建用户和配置权限、查看和管理进程、编写一个Shell脚本、部署nginx服务，再处理一个指定的系统故障案例。

考虑到很多人对"作业"这个词容易轻视，我拆清单时故意把每一条都对应到真实工作场景里。你在公司接手一台新服务器，要做的事情无非就是：装系统、配网络、建账号、调权限、看进程、写脚本、起服务、查日志。这不就是作业里的内容吗？

我把它整理成了下面这张验收表，整个过程都对照着它执行。

计划很简单：先搭好环境，然后按任务顺序推。但实际做下来，环境搭建这一步花的精力远超预期，因为换源、配网卡、装工具这些环节全是坑。后面第5部分我会单独把这些坑集中出来讲。

1.2 虚拟机、镜像选择和WSL的取舍

做这种系统级作业，第一件事就是选环境。我面前有三个候选：VMware Workstation、VirtualBox、WSL2。

WSL2启动快、占用低，平时练命令、写脚本确实非常舒服，但这份作业里有systemd服务管理、nginx部署和进程间通信实验，完整虚拟机的环境更接近生产服务器，折腾起来的真实感完全不一样。而且Windows下WSL安装偶尔会莫名其妙失败，安装向导提前结束、提示升级内核组件或者检查虚拟化，排查起来也费时间。综合考虑，我选了VMware Workstation加完整发行版这条路。

镜像选择上，作业没有限定发行版，我对比了Debian 12、Ubuntu 24.04和Rocky Linux 9。Debian胜在稳定、软件源丰富、入门资料多；Ubuntu社区活跃但和Debian血缘很近，差别不大；Rocky是RHEL系，如果以后想去用CentOS风格命令的企业，这套也值得练。最后我选了Debian 12作为主线，后面所有命令都是Debian系语法，不过90%的内容在Ubuntu和Rocky上同样适用。

有一点值得提醒：装系统时分区选择"使用整个磁盘并配置LVM"会更省心。LVM逻辑卷的好处是后期磁盘不够可以在线扩容，做作业不需要，但工作里早晚会用到。Swap分区给1到2G足够，学习环境不需要追求大页面交换。

1.3 安装完成后的基础配置：换源、更新、装工具

系统装好第一件事永远是换软件源。默认源大多在国外，apt update经常卡到怀疑人生。我直接换了清华的镜像源，Debian 12的sources.list大致长这样。

# /etc/apt/sources.list deb https://mirrors.tuna.tsinghua.edu.cn/debian/ bookworm main contrib non-free non-free-firmware deb https://mirrors.tuna.tsinghua.edu.cn/debian/ bookworm-updates main contrib non-free non-free-firmware deb https://mirrors.tuna.tsinghua.edu.cn/debian-security bookworm-security main contrib non-free non-free-firmware

替换完成后执行apt update，再把系统升一次级，把基础工具一起装上。

sudo apt update sudo apt upgrade -y sudo apt install -y vim gvim net-tools htop tree curl lsof rsync nginx

这里有个细节：换源后如果提示签名失效，别慌，多数情况是缺证书组件，先装ca-certificates和gnupg，再重新update就能解决。新手最容易在这里卡住，以为是源写错了，实际上是证书链问题。

网络配置我放在后面专门讲，因为网卡配置这块我分别踩了Debian和Rocky两边的坑，单独拉出来说会更清楚。装完这一轮基础配置后，环境总算能用了，可以开始真正的系统管理练习。

2. 用户权限与常用命令的实操复盘

2.1 高频命令别死记，按任务场景来

网上搜"linux常用命令大全"能搜出一大堆，但说实话，硬背列表没有意义。我的习惯是把命令按使用场景分类，每类记住几个高频的，先够用，再慢慢扩展。这次作业里真正用到的高频命令，我整理成了这张速查表，你直接照着用就行。

这只是个骨架。比如文件操作用find查大文件，命令是find /var -type f -size +100M，这种配合具体场景的命令才容易记住。今天需要删除一个目录，你自然会想起rm -rf，但光标敲到这个命令上的时候，脑子要同时响起警报：路径确认了吗？有没有备份？误删了能恢复吗？

2.2 新建用户与密码过期提醒

作业B任务要求创建两个新用户，分别加入不同组，并且配置密码过期策略。我执行的过程如下。

# 创建用户并指定家目录和登录shell sudo useradd -m -s /bin/bash stu01 sudo useradd -m -s /bin/bash stu02 # 设置密码 sudo passwd stu01 sudo passwd stu02 # 创建用户组并加入 sudo groupadd devgroup sudo usermod -aG devgroup stu01 sudo id stu01

useradd的-m参数表示创建家目录，-s指定默认shell。如果不加-m，用户没有家目录，登录后连环境变量都怪怪的。这些细节在面试里也常考，比如问你"useradd和adduser的区别"。Debian系的adduser是交互式封装，useradd是底层命令，一个偏向人机交互，一个偏向脚本调用，搞清楚这个很容易加分。

密码过期策略用的是chage命令。我要求密码30天后过期，提前7天提醒，执行后查看效果。

sudo chage -M 30 -W 7 stu01 sudo chage -l stu01

chage -l的输出里能看到最后一次修改密码时间、密码过期时间、两次修改的最小间隔等。实际工作中，很多公司要求服务器密码定期更换，这个命令几乎是必会项。我还顺手在/etc/profile.d/下加了一个提醒脚本，用户登录时如果发现密码快到期限，就输出提示。

#!/bin/bash # /etc/profile.d/passwd-expire-warn.sh days=$(chage -l "$USER" 2>/dev/null | awk -F: '/密码 expires/ {print $2}' | xargs -I{} date -d "{}" +%s 2>/dev/null) current=$(date +%s) ...

这里有个坑：不同系统的locale不一样，chage -l输出的中文或英文字段名不同，用awk按英文"password expires"过滤有时匹配不到。更稳妥的办法是直接解析/etc/shadow文件的第5个字段，那个字段就是密码剩余有效天数。实习的时候我因为这个中文环境问题折腾了半小时，最后干脆改用shadow字段解析，一行awk解决问题。

2.3 sudo权限配置与提权边界的理解

作业里说的"提权"，是指普通用户通过sudo获得临时root权限这种受控操作，别想歪。这里我理清了一个最容易混淆的点：vim /etc/sudoers本身是个绝对危险的操作，因为语法错误会让你所有sudo命令直接罢工。正确方式永远是visudo。visudo在保存时检查语法，发现问题会阻止写入并提示。

我的操作是把stu01加到sudo组，然后验证。

sudo usermod -aG sudo stu01 su - stu01 sudo -l sudo cat /etc/shadow

sudo -l能查看当前用户被授权执行哪些命令。这里还有个容易被忽略的知识点：sudo日志会记录每次提权操作，记录在/var/log/auth.log里。出了安全事故，第一件事就是翻这个日志，查谁在什么时候执行了什么命令。这就是为什么正规做法是让普通用户通过sudo临时提权，而不是直接su切到root乱转，后者在日志审计上等于睁眼瞎。

权限部分我还复习了chmod。权限位用数字表示，r=4、w=2、x=1，目录常见755，普通文件常见644。你要给脚本加执行权限就是chmod +x，要修改属主就是chown user:group file。特殊权限里SUID是比较隐蔽的存在，一个文件如果设置了SUID，普通用户执行它时会临时获得属主权限。面试问到"如何查找系统里的SUID文件"，答案是一条find命令：find / -perm -4000 -type f。这个命令在安全排查里真的会用到，不要只当面试题背。

说到踩坑，权限这里我犯过两个低级错误。一次是手滑执行了chmod -R 777 /usr/bin，结果系统里一堆命令权限错乱，登录都开始出现异常。另一次是删除目录忘了加引号，路径里有个空格结果直接拆成了两个参数。从那以后，凡是rm -rf前面我都要加个echo先打印一遍，确认路径完全正确才动手。这个习惯救过我很多次。

3. 进程管理、服务部署与日志排查

3.1 顺着作业任务看进程、发信号、改进程名

进程这块作业要求能查看进程、能按信号结束进程，还考察了进程间通信。这些点串起来其实就是你做运维排障时最常用的那套操作。

查看进程，我常用ps aux和top搭配。ps aux能看所有进程的快照，top能看到实时的CPU和内存占用。如果机器卡到连top都开不了，多半是内存或磁盘有问题，先free -h和df -h走一轮。load average是面试里必问的指标，它有三个数字，分别代表1分钟、5分钟、15分钟的平均负载。误区是很多人以为load高就是CPU满，其实它表示的是处于可运行和不可中断状态的进程数，磁盘IO卡住也能拉高load。

给进程发信号，kill是最直接的。kill -l能看到全部信号列表，常用的是TERM（15，正常终止）、KILL（9，强制结束）、HUP（1，重载配置）、USR1/USR2（自定义业务信号）。作业里要求用kill结束一个指定进程，我的完整脚本是：

# 先找到进程PID pidof sleep # 优雅终止 kill -15 12345 # 确认是否消失 ps aux | grep 12345 # 万一没死，才用强制 kill -9 12345

实际操作里优先用-15，给进程一个处理收尾工作的机会。动辄-9容易留下半截状态的临时文件或脏数据。只有确认进程卡死无响应，才轮到-9上场。

改进程名这个技能看起来冷门，实际排查时很有用。脚本里启动的后台任务一堆sleep和bash，进程列表里全是重复名字，根本分不清谁是谁。作业里我用了三种方式实现改名：

第一种，启动时指定标题。bash和python都支持，比如python3 -c之后用setproctitle库，可以在进程运行中修改名字。

# python3改进程名示例 import setproctitle setproctitle.setproctitle("my-daemon-worker")

第二种，通过exec -a参数。在bash里执行exec -a customname python3 script.py，这样进程显示名就是customname，这对脚本方式启动的场景尤其好用。

第三种，systemd部署。在Unit文件里设置ExecStart的启动命令，service name本身就会显示在进程列表里。比如nginx.service里的进程就叫nginx，看起来清清楚楚。

进程间通信这块，管道是最直观的。命令里那根竖线其实就是IPC，比如ps aux | grep nginx，左边进程输出直接流进右边进程。信号是另一种IPC方式，一个进程可以用kill给另一个进程发信号。作业里我写了一个极简的生产者消费者演示，生产者每秒写入管道，消费者从管道读取，整个过程不经过磁盘，这就是管道通信的工作方式。

提示：排查"进程存在但端口不监听"这类问题，先用ss -tlnp看端口，再用lsof -i:8080看占用进程，两个命令配合能解决90%的端口问题。

3.2 systemd Unit文件与nginx部署

现代Linux发行版基本都用systemd管理服务，开机自启、崩溃重启、日志统一都由它负责。作业E任务要求部署nginx并配置自启，我顺手写了个自定义服务的Unit文件，理解了这个文件的语法，nginx自启就是顺带的事。

先看nginx部署。Debian系下安装太简单了：

sudo apt install nginx -y sudo systemctl enable --now nginx sudo systemctl status nginx curl http://127.0.0.1

如果curl能返回一大段HTML，默认页面就起来了。这一步里有一个很容易忽略的坑：改完配置一定要执行systemctl reload nginx而不是restart。reload等于告诉nginx平滑重载配置，不会中断现有连接；restart是全部推倒重来，在线上环境会造成连接闪断。作业里没要求，但面试问到nginx重载和重启的区别，这就是标准答案。

我后来自己写了一个Unit文件，内容是启动一个简单的Python HTTP服务。

# /etc/systemd/system/myweb.service [Unit] Description=My Simple HTTP Server After=network.target [Service] ExecStart=/usr/bin/python3 -m http.server 8080 Restart=on-failure User=www-data Group=www-data [Install] WantedBy=multi-user.target

这个文件的语法逻辑很清晰。After表示这个服务在网络就绪之后再启动；Restart=on-failure表示进程异常退出时自动拉起，这是生产环境服务高可用的基础；User和Group指定服务以什么身份运行，原则是最小化权限，绝不轻易用root跑业务服务。写完后执行systemctl daemon-reload，再start、enable，一个自启服务就建好了。

现在回过头看nginx的systemd配置文件，它内部做的事情和我这个myweb.service一模一样，只是多了更多参数。理解了Unit文件语法，你对系统服务的掌控力会上一个台阶。

3.3 日志分析与系统故障案例实录

作业F要求排查系统故障，这部分最能体现"运维基本功"。日志是排障的第一现场，journald统一收集系统日志后，常用的操作是：

# 查看nginx服务的实时日志 journalctl -u nginx -f # 只看本次开机后的错误级日志 journalctl -b -p err # 按时间范围捞日志 journalctl --since "1 hour ago"

传统日志文件在/var/log下，系统日志看syslog，登录日志看auth.log，内核日志看dmesg。我这次处理的两个案例都非常典型。

案例一：磁盘满导致服务拒绝写入。现象是nginx突然返回500，系统日志里出现"No space left on device"。我先执行df -h，发现/dev/mapper根分区使用率100%，然后用du -sh /var/log/*按目录找大文件，结果发现一个访问日志文件涨到了80G。定位到是上一次日志轮转配置没启用，导致日志无限增长。解决方式是清理日志并配置logrotate，让系统按天轮转并保留7天历史。

案例二：inode耗尽。这个案例很隐蔽，df -h显示磁盘还有空间，但df -i显示inode使用率100%。什么叫inode？简单类比，磁盘空间像一栋楼的房间总面积，inode就是门牌号。门牌号满了，哪怕楼里还有很多空房间，你也住不进去。无法创建新文件、新目录就是这个原因。最后定位到/var/spool/postfix/maildrop下堆了几十万个小文件，全是未送达的邮件碎片，清空之后一切恢复正常。

服务起不来的通用排查顺序也总结一下：先systemctl status看服务状态，再journalctl -u 服务名看日志，日志不够就tail -f业务日志文件，最后检查配置文件的目录权限、属主属组是否正确。这套顺序能解决九成问题。很多人一上来就改配置，结果方向都是错的，排查效率极低。

4. 自动化和面试高频点：让作业带点"求职"视角

4.1 从零写一个能用的Shell脚本

作业D任务是写一个Shell脚本并用crontab定时执行。我把需求定得很实际：每天凌晨清理/var/log下超过7天的.log文件，同时把清理结果追加到操作日志里，方便回溯。脚本我写成了下面这样。

#!/bin/bash # /usr/local/bin/clean_old_logs.sh LOG_DIR="/var/log" DAYS=7 CLEAN_LOG="/var/log/clean_script.log" # 先判断目录是否存在 if [ ! -d "$LOG_DIR" ]; then echo "$(date +'%F %T') [ERROR] 目录 $LOG_DIR 不存在" >> "$CLEAN_LOG" exit 1 fi # 找出并删除超过7天的日志文件 count=$(find "$LOG_DIR" -name "*.log" -mtime +$DAYS | wc -l) find "$LOG_DIR" -name "*.log" -mtime +$DAYS -delete echo "$(date +'%F %T') [INFO] 清理完成，共删除 $count 个文件" >> "$CLEAN_LOG"

这个脚本有几个讲究。count变量先统计要删除的文件数量，再把删除结果打印到日志，保证每一步都有迹可查。find配合-delete，比find加管道再xargs rm更安全，因为xargs参数过长或者管道处理中文件名带空格都会出问题，-delete是find内建操作，效率和正确性都更好。

脚本写完别忘了chmod +x，然后配置crontab定时任务。

crontab -e # 添加一行，每天凌晨2点执行 0 2 * * * /usr/local/bin/clean_old_logs.sh

crontab格式五个字段依次是分、时、日、月、周。0 2 * * *就表示每天2点0分。实践里有个坑：crontab环境变量非常精简，脚本里最好使用绝对路径，命令也要写全路径，否则经常出现"手动执行没问题、定时执行没反应"的情况。另一个坑是crontab里执行的结果默认会发邮件到本机root邮箱，邮箱文件堆积多了，又变成一个磁盘故障源。所以脚本里最好自己重定向日志，crontab行尾可以加>/dev/null 2>&1来屏蔽默认邮件。

4.2 面试题高频考点，顺手整理了一份答案

做完作业后发现，很多任务对应的知识点其实就是面试里常考的点。我直接把作业里的内容映射成了一份面试题清单，每一问都能在实操中找到答案。

面试官考"linux常用命令"时，很少让你背列表，而是给你一个场景问"线上CPU飙升你怎么排查"。完整的思路是：top定位高CPU进程，ps aux查看进程详情，top -Hp看线程级消耗，strace跟踪系统调用，最后分析是不是代码死循环。这套流程我在作业里虽然没有完全跑完，但排查原理是一模一样的，建议你提前练一遍。

4.3 嵌入式Linux和国产化方向的一点延伸

做完这份作业，其实还能向两个方向延伸。一是嵌入式Linux方向。嵌入式开发不能只懂单片机，很多时候需要在板子上跑完整Linux内核、写驱动、调设备树，作业里学的用户管理、进程查看、systemd、脚本编译，到板子上照样通用。区别只是交叉编译和内核裁剪，但系统管理的基础是完全相同的。

二是国产操作系统方向。现在很多企业做信创适配，数据库、中间件、应用都要部署在基于Linux内核的发行版上。说到linux国产这个词，不用觉得陌生，它的命令体系和常见操作跟这次作业里学的没有本质区别，多数只是包管理器、文件路径有细微差异。学好标准Linux，再上手国产系统基本是无缝切换。

这两个方向都不是作业硬性要求，但却是我自己做完后觉得最有价值的延伸。作业只是起点，后面的路还长。

5. 实操过程记录与问题排查速查

5.1 完整操作时间线：从镜像下载到作业收尾

为了让读者有整体体感，我把这次作业的时间线列在下面，中间每个环节我都做了标记。

整个过程差不多8小时，中途还穿插了一些网络配置和工具装的反复操作。第一次做可能会觉得慢，但我建议别急着压缩时间，因为中间卡壳排查的过程才是真正涨经验的地方。面试官问"你遇到过哪些故障、怎么排查的"，答案全都藏在这些卡壳时刻里。

5.2 高频问题速查表：我踩过的坑，你直接避开

这里把这次作业和平时学员提问中出现频率最高的问题汇总成表，每个问题都附排查思路。

这些问题的共同点就是：看起来吓人，实际上都是基础配置或权限问题。排查的时候最忌讳乱猜，一定要沿着日志和状态一步步走。把这张表收藏起来，能少走很多弯路。

5.3 作业验收清单与复盘建议

按老师的要求，我把作业验收做成了一份自检清单。每一项都实际跑通过，现在直接共享出来。

# 1. 系统基础 cat /etc/os-release ping -c 3 mirrors.tuna.tsinghua.edu.cn # 2. 用户权限 id stu01 sudo -l -U stu01 chage -l stu01 # 3. 进程管理 ps aux | grep nginx ss -tlnp | grep :80 # 4. 脚本自动化 /usr/local/bin/clean_old_logs.sh crontab -l # 5. 服务部署 systemctl status nginx curl -I http://127.0.0.1 # 6. 故障排查 df -h df -i journalctl -p err -b

一份作业做完，回头看这些命令，其实已经覆盖了Linux系统管理的半壁江山。如果还有余力，我的建议是继续做三件事：第一，再人为制造两个故障案例，比如塞满/tmp、故意改坏sudoers，然后练习恢复，这种破坏性练习最能建立信心；第二，认真读一遍man命令，挑一个不熟的命令看完整帮助文档；第三，把awk和sed各找20道练习题做一遍，这两个工具在日志分析和文本处理里是真正的生产力。

我个人在这份作业里最深的体会是，别把"作业"两个字看轻了。你什么时候能在虚拟机里把系统装坏再修好，把服务跑起来再弄挂再救回来，Linux的基础就真正扎实了。我踩过不少坑，也查了很多资料，最后发现最有用的学习方式还是亲手把环境搭起来，把命令敲进去，把日志翻出来看。下次如果再布置linux作业2，我想我会更期待，因为知道基础打牢之后，能玩的东西会越来越多。