故障现象描述

1. 尝试升级交换机版本（这里应该因为某种原因导致升级失败）。

2. 尝试进入所谓的recover模式 ，也就是FreeBSD的loader，并尝试使用install --format将已有的文件系统重写（也叫格式化安装）。

3. 这时候会得到如下错误：

   1 2	panic: free: guard1 fail @ 0x45c40 from /.amd/svl-engdata1vs1/occamdev/build/freebsd/head/20160518.183540_fbsd-builder_head.327854/src/lib/libstand/dosfs.c:248 --> Press a key on the console to reboot <--

交易过程

此处省略砍价过程…

我：你文档是盲流子文档，有没有官方文档。

K：这就是官方文档。

我：肯定不是，我自己找吧。

十分钟后，我确实遇到同样的错误，再次扯皮。

我：你这包不对吧？

K：肯定对。

我：你有没有别的，img格式的。

K：下载中。

这时基本是确定了包不对，文档也不是解决这个问题的文档，使用Google大法。基本定位是loader模式的状态下，并没有从USB设备引导，由于对BSD不熟悉，但是应该原因类似GRUB引导设备不对差不了多少😂。

我：拿到IMG包。

名词描述

load模式

这个就是FreeBSD内核引导的最后阶段，会检测控制台和磁盘，识别从哪块盘引导。

currdev

选择默认设备。

include

处理脚本文件。依次读取每个文件进入内存，然后将其中的每一行传递。

dd

convert and copy a file。

开搞

• 首先将img.gz包解压，并将其写入到usb设备（win直接解压就好）：

  1	gzip -d xxx.img.gz

• 确定USB是哪个，此处仅写Mac上的方法：

  1 2	diskutil list # 找到你的usb，我这是disk2 diskutil umountDisk /dev/disk2 # 卸载

• 将img镜像写入usb设备(其他刻录软件也可)：

  1	dd if=/path/to/file.img of=/dev/disk2 bs=1m

• 拔掉USB。

• 接到某厂坏了的交换机。

• 插上什么console线。

• 通过COMx连上。

• 执行reboot（主要为了重新识别USB设备）。

• 进入loader模式后。

  1 2	set currdev="disk1s1a" # 设置引导设备为disk1s1a include /boot/loader.rc #　执行/boot/loader.rc脚本文件

结束

等待重写完成，就可以通过默认用户名：root，密码：空，进入系统。

前言

明天要放假了（虽然只有四天），这一年的工作中充斥的琐事（大于60%），那么琐事是什么呢?

琐事就是运维服务中手动性的，重复性的，可以被自动化的，战术性，没有持久价值的工作。

​ ── Google SRE

（当然，也包括主观认为不怎么喜欢做但又不得不做的事😂。

回想去年年底也是许了不少愿，包括但不限于把Golang，Kubernetes学个差不多，监控弄得像个人样，Terraform和Ansible去处理些边缘业务的自动化顺带Gitlab，还有就是去看渴望力量系列，现在看，今年的进度四舍五入约等于0。

今年的工作中，扮演的角色就很有趣，之前我其实只要做好自己管理的系统就好了，其余时间可以自己去找些东西学习，搭建测试，去满足需求就好了，所以琐事的比例很小。今年感觉自己需要参与的工作（不是数量，而是类别）变多了，多数也就是配合作用（也就是无法做主），其实也很舒服，但是嘛，毕竟还需要协调资源（传话）去配合其他老师，免不了与人沟通。就贼难受。

琐事

1. 堡垒机日常工作
2. 疫情+校庆这段期间虚拟机的交付，虽然用了terraform，但是后端状态并没有持久化，很烦。
3. 需求翻译，我很奇怪这个事，但是也有收获，比如我理解运维与开发之间的矛盾是如何产生的，233333。
4. 写毫无意义的日报（工作记录很有意思，但是我这种，意义：0）。
5. 跟一些工程师沟通，跟你们沟通使我变得更菜。

非琐事

1. terraform真香，尝到了甜头。
2. 读《Kubernetes In Action》,K8s大法好，这本书香。
3. 配合大佬。
4. Netbox
5. vSphere Tanzu Cluster
6. 有一丁点安全意识了，知道不关防火墙了。

收获

1. 以后不准备用CentOS了。
2. Kubernetes的理念是真的巧妙。
3. 与人沟通，并非易事。
4. 与人协作，先确认价值观，价值观不符时，做好自己的就好。
5. 找到一个合适的团队很难，不要拿自己的标准衡量别人。

吐槽

有些厂商的工程师，真的差劲。

转换OpenSSH private key为RSA private key

今天下午，想把本机的Private KEY添加到堡垒机，倒是也没仔细看，直接复制粘贴到堡垒机中，低能堡垒机提示说私钥格式无效。

==WTF?==

应该是SSH版本太高了，看了下发现第一行有区别（内容也不同）。

1
2
3
4
5
6
7
8

# OpenSSH_8.1p1
-----BEGIN OPENSSH PRIVATE KEY-----
xxx
-----END OPENSSH PRIVATE KEY-----
# OpenSSH_7.5p1
-----BEGIN RSA PRIVATE KEY-----
xxx
-----END RSA PRIVATE KEY-----

0202年了，SSH版本也要升级到8.0了，先不管了，转换吧，一条命令：

1
2
3
4
5

cp ~/.ssh/id_rsa /tmp/path/to/key
# 就这一条
ssh-keygen -p -N "" -m pem -f /tmp/path/to/key
# 记得保管好呀
rm -f /tmp/path/to/key

复制private key转换后填到堡垒机，删掉，一定保管好private key。

==堡垒机是真的垃圾，谁家都一样。==

以后在家基本告别电脑了，我家一条是真的爱玩电脑hhhh。

TCP与UDP连接

看结果请直接拉到底↓

TCP和UDP协议是两个不同的协议，用于处理IP网络（Internet）中的客户端之间的数据通信。

在传统OSI模型中，TCP和UDP是传输层协议。其中TCP是面向连接的协议，而UDP是无连接协议。

TCP

从理论上讲，传输层协议可以是一个非常简单的，但是不能将TCP协议称为简单协议。为什么要使用与TCP一样复杂的传输层？最重要的原因取决于IP的不可靠性。实际上，TCP下的所有层都不可靠，并且逐跳传递数据报。IP层逐跳传送数据报，并且不能保证传送数据报。这是一个无连接系统。IP只是处理数据报的路由。如果出现问题，IP会立即丢弃该数据包，并在此过程中将错误消息返回给发送方。确定通过网络发送的数据报的状态并在部分已被丢弃的情况下处理信息重发的任务落在TCP上。

大多数用户将TCP和IP视为紧密的对，但是TCP可以并且经常与其他传输协议一起使用。

例如，在文件传输协议（FTP）和简单邮件传输协议（SMTP）中都使用TCP或其中的一部分，它们都不使用IP。

传输控制协议为IP层和上层提供了大量服务。最重要的是，它为上层提供了面向连接的协议，该协议使应用程序可以确保通过网络发送的数据报被完整接收。在此角色下，TCP充当提供可靠通信的消息验证协议。如果数据报已损坏或丢失，则通常由TCP（不是较高层中的应用程序）来处理重传。

TCP管理来自更高层的数据报流，以及来自IP层的传入数据报。它必须确保优先事项和安全得到尊重。TCP必须能够处理其上期望输入数据报的应用程序的终止，以及较低层的故障。TCP还必须维护TCP层内外所有数据流的状态表。将这些服务隔离在一个单独的层中，可以在不考虑流控制或消息可靠性的情况下设计应用程序。没有TCP层，每个应用程序都必须自己实现服务，这是资源的浪费。

TCP位于传输层，位于IP之上，但位于上层及其应用程序之下，如下图所示。TCP仅驻留在实际处理数据报的设备上，以确保数据报已从源计算机传递到目标计算机。它不驻留在仅路由数据报的设备上，因此网关中没有TCP层。这是有道理的，因为在网关上，数据报在分层模型中不需要比IP层更高。

TCP报头结构

TCP段作为Internet数据报发送。Internet协议报头包含几个信息字段，包括源和目标主机地址。TCP头跟随Internet头，提供特定于TCP协议的信息。这种划分允许存在TCP以外的主机级别协议。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Data |           |U|A|P|R|S|F|                               |
| Offset| Reserved  |R|C|S|S|Y|I|            Window             |
|       |           |G|K|H|T|N|N|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |         Urgent Pointer        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             data                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         TCP Header Format

       				请注意，一个刻度表示一位位置。

TCP通讯

在将TCP用于任何实际有用的目的（即发送数据）之前，必须在希望通信的两个设备之间建立连接。此过程通常称为连接建立，涉及交换消息，该消息将两个设备从其初始连接状态（CLOSED）转换为正常操作状态（ESTABLISHED）。

连接建立功能

建立连接过程实际上会完成几件事，因为它创建了适合于数据交换的连接：

联系和通信： 客户端和服务器相互联系，并通过相互发送消息建立通信。在这一点之前，服务器通常甚至不知道它将与之对话的客户端，因此它在连接建立期间就发现了这一点。

序列号同步： 每个设备都让对方知道其首次传输要使用的初始序列号。

参数交换： 控制TCP连接操作的某些参数由两个设备交换。

用于建立连接的控制消息：SYN和ACK

TCP使用控制消息来管理联系和通信过程。但是，没有任何特殊的TCP控制消息类型。所有TCP消息均使用相同的段格式。TCP报头中的一组控制标志指示段是用于控制目的还是仅用于承载数据。使用控制消息时，以下标志会更改。

SYN： 该位指示该段正在用于初始化连接。参考上面提到的序列号同步，SYN表示同步。

ACK： 此位指示发送网段的设备正在传送对其已接收消息（例如SYN）的确认。

正常连接建立：“三次握手”

为了建立连接，每个设备必须发送一个SYN并从另一个设备接收一个ACK。因此，从概念上讲，需要在设备之间传递四个控制消息。但是，当一个人可以同时通信时，在单独的消息中发送SYN和ACK效率很低。因此，在连接建立中的正常事件序列中，通过设置两个相关位（有时称为SYN + ACK的消息）来一起发送SYN之一和ACK之一。这总共产生了三个消息，因此，连接过程称为三次握手。

关键： 在TCP客户端和服务器之间建立连接的正常过程包括三个步骤：

• 客户端发送SYN消息

• 服务器发送结合了客户端SYN的ACK并包含服务器SYN的消息

• 然后客户端发送针对服务器的SYN的ACK。这称为TCP三次握手。

连接在其生存周期内会经历一系列状态，这包括：

UDP

UDP是一种无连接且不可靠的传输协议，这两个端口用于标识源计算机和目标计算机内的端点。当不需要可靠的传送时，使用用户数据报协议代替TCP。但是，从不使用UDP发送重要数据，例如网页，数据库信息等。流媒体（例如视频，音频等）使用UDP，因为它提供速度。

为什么UDP比TCP快？

UDP比TCP快的原因是因为没有任何形式的流控制。UDP不会进行错误检查，错误纠正或确认。UDP只与速度有关。因此，当Internet上发送的数据受到冲突的影响时，就会出现错误。

UDP数据包称为8字节标头的用户数据报。用户数据报的格式如图3所示。在用户数据报中，前8个字节包含头信息，其余字节包含数据。

UDP数据报

UDP的特征

UDP的特征如下。

• 端到端。UDP可以识别计算机上运行的特定进程。

• 不可靠的无连接传送

UDP使用无连接通信设置。在这种情况下，UDP无需在发送数据之前建立连接。通信仅由数据段本身组成

• 尽力而为

• 无应答，无顺序，无流量控制

• 可能会丢失，重复，延迟，乱序或失去连接

• 快速，低开销

1. 适用于可靠的本地网络
2. RTP（实时传输协议）

在通讯中使用端口

接收到数据之后，计算机必须具有某种处理机制。考虑到用户已打开三个应用程序，例如Web浏览器，telnet会话和FTP会话。这三个应用程序都正在通过网络移动数据。因此，应该有某种机制来确定操作系统将哪些流量绑定到哪个应用程序。要处理这种情况，请使用网络端口。可用端口的范围是0到65535。其中0到1023是众所周知的端口 ，1023到49151是注册端口，49152到65535是动态端口。

使用UDP协议的常见端口：

UDP通信

在UDP连接中，客户端根据他们开始连接的程序设置唯一的源端口号。UDP不限于一对一交互。可以使用广播或多播寻址提供一对多交互。与单台服务器通信的许多客户端可以提供多对一交互。多对多交互只是这些技术的扩展。

TCP vs UDP

如何测试一个端口是否通信

telnet和一些奇奇怪怪的工具我就不说了，如果您认为某些网站上的工具好用，请Alt + F4。

如果是个人电脑，没所谓，用些小工具可以，但是Server的话可不能因为测试就随便装某些奇怪的东西。

在Windows上测试端口

telnet

不是本文关注内容

Test-NetConnection

这是PowerShell提供的能力，支持ping,TCP，traceroute

• ping测试：

  1	Test-NetConnection -ComputerName www.hit.edu.cn -InformationLevel Detailed

• 路由测试(管理员权限运行)：

  1	Test-NetConnection -ComputerName www.hit.edu.cn -DiagnoseRouting -InformationLevel Detailed

• TCP端口连通性测试：

  1	Test-NetConnection -ComputerName www.hit.edu.cn -Port 80 -InformationLevel Detailed

• Trace测试：

  1	Test-NetConnection -ComputerName www.hit.edu.cn -TraceRoute

InformationLevel Detailed参数可选。

在Linux/Unix上测试端口

telnet仍不不关注

netcat

需要使用包管理（apt/yum等）安装nc（netcat）：

1

yum -y install nc

比如咱们测试192.168.1.1的TCP22端口：

1

nc -vz 192.168.1.1 22

如果可以连通，会在标准输出回显successded。

nmap

nmap其实是一个网络扫描工具，但是也可以使用，首先也是安装nmap包,省略步骤，然后咱们继续测试22，

1

nmap -sT -v -p 22 192.168.1.1

具体参数需要养成查阅man手册的好习惯。

UDP端口测试

这才是写这个文档的目的，这个问题困扰很多人，如果有人问你如何测试一个UDP端口是否可达？其实这个问题就是个错误(虽然某些方式可以验证是否可达)，先说为什么，再说怎么做。

其实没有所谓的开放UDP端口，大多数人惯于思考的意义上（这是在回答，确认，我以接受连接，这一类意思）。UDP是无会话的，因此，所谓Port（读取：OS中IP协议栈中的UDP协议）将永远不会自行响应，也就是所谓的三次握手完成后，所响应的成功。（后面会说各种工具对于UDP端口的测试是如何实现的）

UDP端口有两种状态：监听与未监听。其实也就是某些进程是否打开套接字。后一种（未打开套接字）情况比较容易检测，因为系统使用`code=3（端口不可达）ICMP Destination Unrechable进行响应。但是，许多防火墙会丢弃这种数据包，因此如果没有得到任何回应，就不能确切知道端口是否处于这种状态。（ICMP也是无会话的，并不会重传），这句话是什么意思呢，就是ICMP Destination Unrechable代表的端口不可达数据包很有可能在途中某个地方被丢弃或丢失。

处于监听状态的UDP端口也可能根本不响应（正在监听它的进程只是接收数据包，并不传输任何内容），或者将某些内容发送回去。也就是说，如果什么也拿不回来，永远无法确定此端口的状态是什么。

有些啰嗦，说的是啥意思呢，就是不通不代表不通，也没有会话控制，无需重传。

那么测试的办法又是什么呢，像nc，nmap这些工具是如何判断UDP端口是否可达呢?

咱们试验一下：

实验用到的工具： nc、tcpdump/wireshark、nmap。

首先，模拟一个监听的UDP端口，并使用tcpdump或wireshark抓包，另一个客户端请求这个端口。

• 服务端使用netcat监听udp端口6666：

  1	nc -ul 6666 # 监听udp6666端口

• 服务端抓包：

  1	tcpdump -i enp0s31f6 udp port 6666 -X

• 防火墙先不开通udp6666：

现在客户端可以使用nc或nmap测试端口了：

1

nc -uv SERVER_IP 6666

Connection to 192.168.1.182 6777 port [udp/*] succeeded!

这时可以键入字符，看server端是否接受到对应输入的字符；

抓包同时查看，

具体不贴图了，多个电脑倒来倒去麻烦，其实目的就是看下

测试结果

其实UDP端口测试，如无外接因素影响的话，nc nmap都可以简单的检测，不过，如果主机防火墙或链路中存在防火墙，这就不确定了。所以下次，如果有人问你如何测试UDP端口，请送上一枚斜眼币。

基于UDP的可靠传输协议

TCP/IP协议栈中，TCP和UDP属于传输层，负责实现数据的传输。其中TCP是面向连接的和基于单个字节流的、保证顺序的可靠传输协议，UDP是无连接的、不可靠的、面向报文的协议。

在实际应用中，TCP由于简单可靠，被大部分应用层协议使用，特别是HTTP，所以占据了互联网流量的主要部分。由于TCP的广泛应用，并且是实现在操作系统中，在参数和算法调整上比较受限，难以进行一些激进的改进和定制。另外TCP的NAT穿越比较困难，一些P2P应用也只能使用UDP，所以就有了各种各样的可靠UDP协议。

可靠UDP协议

UDT(UDP-based Data Transfer Protocol)

UDT的主要目的是支持高速广域网上的海量数据传输，所以除了在UDP之上实现类似TCP的协议和算法之外，UDT还对TCP的拥塞算法做了一些细节上的调整，包括Negative-ACK(NAK)、ACK to ACK(ACK2)、基于对数的动态AIMD等。不过UDT的重传效率较低，无效报文，实际效果并不理想。

KCP

KCP是一个很简单的ARQ的实现，包括选择重传和快重传等机制，对上层提供一个可靠的字节流。应用层可以使用多流复用的框架来实现对多个流的支持。另外，KCP增加了可配置启用的加密和FEC选项，FEC用的是Reed-Solomon纠删码，例如可以配置发送10%的冗余数据，来减少丢包时需要的重传，从而降低数据传输的延时。

QUIC

QUIC是Google实现的一种可靠UDP传输协议，并且已经被选择作为HTTP/3的基础。它的特点有：

• 内建安全性，集成TLS
• 连接建立过程和TLS协商过程合并，减少往返请求次数，提高连接速度
• 集成多种拥塞算法，包括最新的BBR
• 多流支持，每个流有独立的拥塞控制，避免单个流中的丢包阻塞其它所有流（Head-of-line Blocking问题），更好的支持类似HTTP/2中的乱序请求
• 连接迁移：QUIC可以通过连接ID来唯一标识一个连接，当用户在有线、无线、移动网络之间切换时，可以保持上层连接的有效性，不需要再进行重连。

另外，早期的QUIC还使用了一种基于异或的FEC算法，不过在新版本中已经去掉。

uTP

uTP是BitTorrent中新增加的一种UDP传输协议，主要特点是使用了LEDBAT（Low Extra Delay Background Transport）拥塞算法。这种算法基于延时来检测网络拥塞，可以更早的探测到拥塞和更早的以及更大幅度的进行避让，从而避免影响用户上网操作的进行，保持后台下载跟前台操作的和平共处。

FASP(Aspera)

FASP是Aspera公司（已被IBM收购）的私有UDP解决方案，提供加密的可靠传输，拥塞算法估计是类似BBR，直接使用RTT和带宽来作为调节速度的参考。但FASP主要用于高速的文件传输，所以不需要保证报文的顺序，避免乱序重组时占用的内存开销，而且也避免了因为内存有限而丢弃的部分乱序报文，从而减少不必要的重传，提高传输速度。也就是说，完全避免了Head-of-line Blocking问题。

SCTP（Stream Control Transmission Protocol，流控制传输协议）

准确的说，SCTP不是一种可靠UDP协议，而是一种跟TCP/UDP平级的传输层协议，是IETF在2000年指定的标准协议。目前Linux和部分UNIX已经集成，Windows和Mac需要使用第三方包来实现。SCTP最初主要用于电信系统，此外，WebRTC中的DataChannel也用到这个协议。它的特点有：

• 跟TCP一样面向连接，提供可靠传输
• 跟UDP一样面向消息
• 多流支持
• 每个流可以配置成接受有序或无序的消息
• Multi-Homing：可以配置多个地址，利用多条网络传输通道
• 更好的安全性：要求四次握手，避免TCP的SYN Flooding攻击

标签页和Windows

tmux对控制台而言，桌面对GUI应用而言，这是本文维度内的世界。在tmux中，可以：

• 在终端内部执行多任务，运行多个应用程序。
• 在同一窗口中有多个命令行（窗格）。
• 工作区（会话）中有多个窗口（窗口）。
• 在多个工作区之间切换，例如虚拟桌面。

思考TMUX

基于文本的窗口管理器

tmux对我们的工作流程和vim一样重要，它对于会话和窗口的管理，能更高效的工作。

会话管理

创建一个名为session_name的新tmux会话：

1

tmux new -s session_name

将现有tmux会话附加到名为session_name的tmux会话：

1

tmux attach -t session_name

切换到名为session_name的现有会话：

1

tmux switch -t session_name

列出现有tmux会话：

1

tmux list-sessions

分离当前连接的会话：

1

tmux detach

快捷键是：control + b ，然后键入d

本文不含性能测试等，实在懒得整理文字排版，不太会写开箱，会慢慢学习！！！

由于几乎没有任何移动办公的需求，这是我第二次买笔记本，第一个还是我上学的时候花2000买的二手HP电磁炉。

为什么买它

之前办公一直是用一台ThinkPad X260，单位没有台式机，也没接显示器，一直装着Ubuntu，直到手贱Upgrade了一个非LTS版本（18.10），彻底GG以后，才意识到需要一台笔记本了。

本来是很排斥苹果的产品的（主要是看不惯果粉无脑吹，比如2019下半年美帝良心想的LEGION Y9000X，果粉根本不敢承认别家比他们水果强。逃，

想买败家之眼的GX 701，可是待机时间感人，

后来认怂想买个MAC Mini或者NUC8 i5，但也不能拿着去会议室看方案吧。

最后听了大佬一句劝，说买个最起码能用四年，直接下单了，

基础架构即代码意味着编写代码来配置，管理和部署IT基础架构，这种概念以下几项关键原则：

• 可再生性：基础环境中的任意元素可以再现，复制。
• 一致性：无论何时，创建在环境各个元素的配置是完全相同的。
• 快速反馈：能够频繁、简单地进行变更。
• 可见性：所有对环境的变更都更易读、可接受版本控制的管理。

通过IaC，可以将基础设施中的元素和配置标准化、自动化，将基础设施作为软件开发流程中的一个功能，一段代码，实现基础设施的pipeline，从而最终实现CI/CD，NetOps以及DevOps。

本文主要描述配置的声明以及下发示例，通过Ansible和Terraform两种IaC工具，通过Netconf over SSH协议对正在运行JunOS的网络设备进行配置的下发，后期会慢慢记录Pipeline的实现（还没弄）。

基础环境信息

描述本次基础环境信息：

本教程可帮助您在系统上安装Java 8或更新Java。在从Linux命令行下载Java之前，请仔细阅读说明。

有关CentOS6的制作我大概思路已经做过一篇文章，本来是希望读者根据这篇来尝试其他release的模板，再加上之前的文章可能对小白有点不友好，我以为SWAP和磁盘分区的问题大家是可以解决的，加上最近同事有这方面的需要，就再次整理一篇。

还是希望大家不是简单的Ctrl + C。

这次的需求呢，是这样：

1. 网卡配置
2. IP地址分发
3. 强制修改密码（有点简陋）
4. 磁盘分区问题

涉及到什么？