s25.linux运维面试题分享

• 一切都是一个文件（包括硬件）。
• 小型，单一用途的程序。
• 连接程序，共同完成复杂的任务（脚本）。
• 避免令人困惑的用户界面。
• 配置数据存储在文本中。

• - 普通文件

• d 目录文件

• b 块设备

• c 字符设备

• l 符号链接文件

• p 管道文件pipe

• s 套接字文件socket

范例：为所有的conf文件加上.bak后缀

范例：去掉所有的bak后缀

Linux是通过link的数量来控制文件删除的，只有当一个文件不存在任何link的时候，这个文件才会被删除。一般来说，每个文件都有2个link计数器:i_count 和i_nlink。

i_count的意义是当前文件使用者（或被调用）的数量,i_nlink 的意义是介质连接的数量（硬链接的数量）；可以理解为i_count是内存引用计数器，i_nlink是磁盘的引用计数器。

当一个文件被某一个进程引用时，对应i_count数就会增加；当创建文件的硬链接的时候，对应i_nlink数就会增加。

对于删除命令rm而言，实际就是减少磁盘引用计数i_nlink。这里就会有一个问题，如果一个文件正在被某个进程调用，而用户却执行rm操作把文件删除了，那么会出现什么结果呢？当用户执行rm操作删除文件后，再执行ls或者其他文件管理命令，无法再找到这个文件了，但是调用这个删除的文件的进程却在继续正常执行，依然能够从文件中正确的读取及写入内容。这又是为什么呢？

这是因为rm操作只是将文件的i_nlink减少了，如果没其它的链接i_nlink就为0了；但由于该文件依然被进程引用，因此，此时文件对应的i_count并不为0，所以即使执行rm操作，但系统并没有真正删除这个文件，当只有i_nlink及i_count都为0的时候，这个文件才会真正被删除。也就是说，还需要解除该进程的对该文件的调用才行。

以上讲的i_nlink及i_count是文件删除的真实条件，但是当文件没有被调用时，执行了rm操作删除文件后是否还可以找回被删的文件呢？

前面说了，rm操作只是将文件的i_nlink减少了，或者说置0了，实际就是将文件名到inode的链接删除了，此时，并没有删除文件的实体即（block数据块），此时，如果及时停止机器工作，数据是可以找回的，如果此时继续写入数据，那么当新数据就可能会被分配到被删除的数据的block数据块，此时，文件就会被真正的回收了，那时就是神仙也没有办法了。

对文件的权限：

对目录的权限：

linux文件权限管理

Linux系统中的每个文件和目录都有访问许可权限，用它来确定谁可以通过何种方式对文件和目录进行访问和操作。

每一文件或目录的访问权限都有三组，每组用三位表示，分别为文件属主的读、写和执行权限；与属主同组的用户的读、写和执行权限；系统中其他用户的读、写和执行权限。

r：文件：读取文件内容；目录：浏览目录

w：文件：修改文件内容；目录：删除、移动目录内文件，但必须同时又x权限

x：文件：执行文件；目录：进入目录

用户可以利用Linux系统提供的chmod命令来重新设定不同的访问权限。也可以利用chown命令来更改某个文件或目录的所有者。

语法：chmod [ugoa…][[±=][perms…]…] file

特殊权限对应的数字

• suid 4000权限字符s(S)，属主位上的x位上设置。
• sgid 2000权限字符s(S)，属组位上的x位上设置。
• 粘滞位1000权限字符t(T)，其他用户位的x位上设置。如何才能使一个目录既可以让任何用户写入文件，又不让用户删除这个目录下他人的文件，sticky就是能起到这个作用。stciky一般只用在目录上，用在文件上起不到什么作用。

如果对应位有x则，字符权限表现为小写，否则表现为大写

linux用户权限管理

在所有Linux系统中，系统都是通过UID来区分用户权限级别的，而UID为0的用户被系统约定为是具有超级权限。我们可以通过/etc/passwd 来查得UID为0的用户是root, root可以超越任何用户和用户组来对文件或目录进行读取、修改或删除。对可执行程序的执行、终止；对硬件设备的添加、创建和移除等；也 可以对文件和目录进行属主和权限进行修改，以适合系统管理的需要。

与超级用户相对的就是普通用户和虚拟（也被称为伪装用户），普通和伪装用户都是受限用户；但为了完成特定的任务，普通用户和伪装用户也是必须的；Linux 是一个多用户、多任务的操作系统，多用户主要体现在用户的角色的多样性，不同的用户所分配的权限也不同；在一般情况下，为了系统安全，对于一般常规级别的应用，不需要root用户来操作完成

当我们以普通权限的用户登录系统时，有些系统配置及系统管理必须通过超级权限用户完成，获取超级权限的过程，就是切换普通用户身份到超级用户身份的过程；这个过程主要是通过su和sudo来解决。

通过su可以在用户之间切换，超级权限用户root向普通或虚拟用户切换不需要密码，而普通用户切换到其它任何用户都需要密码验证；su命令参数如下：

-, -l, --login 登录并改变到所切换的用户环境

-c, --commmand=COMMAND 执行一个命令，然后退出所切换到的用户环境

su不加任何参数默认切换到root用户下，但用户环境变量没有改变；仅仅加-参数，表示默认切换到root用户，并且改变到root用户的环境；

但通过su切换到root后，也有不安全因素；比如系统有10个用户，而且都参与管理。如果这10个用户都涉及到超级权限的运用，做为管理员如果想让其它用户通过su来切换到超级权限的root，必须把root权限密码都告诉这10个用户；如果这10个用户都有root权限，通过root权限可以做任何事， 这在一定程度上就对系统的安全造成了威协；所以su工具在多人参与的系统管理中，并不是最好的选择，su只适用于一两个人参与管理的系统。

对于服务器的管理有多人参与管理时，这时我们就有必要用到sudo，通过sudo，我们能把某些超级权限有针对性的下放，并且不需要普通用户知道root密码，所以sudo相对于权限无限制性的su来说，还是比较安全的。sudo 执行命令的流程是当前用户切换到root（或其它指定切换到的用户），然后以root（或其它指定的切换到的用户）身份执行命令，执行完成后，直接退回到当前用户；而这些的前提是要通过sudo的配置文件/etc/sudoers来进行授权；我们可以用他的专用编辑工具visudo，此工具的好处是在添加规则不太准确时，保存退出时会提示给我们错误信息；配置好后，可以用切换到您授权的用户下，通过sudo -l 来查看哪些命令是可以执行或禁止的。之后可以在授权的命令前加sudo以root用户身份执行。

输出的结果格式为：

bash：父进程会fork一个子进程，shell script在子进程中执行，修改的上下文不会影响当前shell

source:在原进程中执行，不会fork子进程，修改的上下文会影响当前shell

exec:在原进程中执行，但是同时会终止原进程

configure：检查当前编译环境，生成MakeFile

make：根据MakeFile生成相关模块

make install：将模块copy到指定目录

• 1.应用层:我们能接触到的就是应用层了，手机，电脑这些这些设备都属于应用层。
• 2.传输层:就是为应用层提供网络支持的，当设备作为接收⽅时，传输层则要负责把数据包传给应⽤，但是⼀台设备上可能会有很多应⽤在接收或者传输数据，因此需要⽤⼀个编号将应⽤区分开来，这个编号就是端⼝。所以 TCP 和 UDP 协议就是在这一层的
• 3.网络层:是负责传输数据的，最常使用的 ip 协议就在该层，⽹络层负责将数据从⼀个设备传输到另⼀个设备，世界上有很多设备，⽹络层需要有区分设备的编号。我们⼀般⽤ IP 地址给设备进⾏编号
• 4.数据链路层:每⼀台设备的⽹卡都会有⼀个 MAC 地址，它就是⽤来唯⼀标识设备的。路由器计算出了下⼀个⽬的地 IP 地址，再通过 ARP 协议找到该⽬的地的 MAC 地址，这样就知道这个 IP 地址是哪个设备的了。路由器就是通过数据链路层来知道这个 ip 地址是属于哪个设备的，它主要为⽹络层提供链路级别传输的服务。
• 5.物理层:当数据准备要从设备发送到⽹络的时候，需要把数据包转换成电信号，让其可以在物理介质中传输，它主要是为数据链路层提供⼆进制传输的服务。

其实就是在发送方设立一个缓存区间，将已发送但未收到确认的消息缓存起来，假如一个窗口可以发送 5 个 TCP 段，那么发送方就可以连续发送 5 个 TCP 段，然后就会将这 5 个 TCP 段的数据缓存起来，这 5 个 TCP 段是有序的，只要后面的消息收到了 ACK ，那么不管前面的是否有收到 ACK,都代表成功，窗⼝⼤⼩是由接收方决定的。

窗⼝⼤⼩就是指不需要等待应答，还可以发送数据的大小。

• 第一次握手:A 的 TCP 进程创建一个 传输控制块 TCB ，然后向 B 发出连接请求报文段。之后将同步位 SYN 设置为 1，同时选择一个初始序列号 seq=x，这时客户端 A 进入到 SYN-SENT（同步已发送）状态。
• 第二次握手:B 收到连接请求报文段，如果同意建立连接，则向 A 发送确认。在确认报文段中 同步位 SYN=1、确认位 ACK=1、确认号 ack=x+1，同时也为自己选择一个初始序列号 seq=y，这时服务器 B 进入 SYN-RCVID 状态。
• 第三次握手:A 收到 B 的确认以后，再向 B 发出确认。确认报文 ACK=1、确认号ack=y+1。这时A进入到 ESTAB-LISHED 状态。当B接收到A的确认后，也进入 ESTAB-LISHED 状态。连接建立完成

• 1.为了防止已经失效的连接请求报文段突然又传到服务端，因而产生错误

• • 如果客户端连续发送多次 SYN 建⽴连接的报⽂，如果出现了网络拥堵，可能会有旧连接先于新连接到达的情况，就可能会出现连接覆盖，要避免这种情况，最少需要三次握手

• 2.三次握⼿正好避免资源浪费

• • 三次握⼿就已经是理论上建立可靠连接的最小次数了，所以不需要更多的连接

• 3.同步双⽅初始序列号

• • 同步序列号(可以鉴别重复数序，按序接受等)其实并不要三次握手，只要一来一回两次就可以了

• 第一次挥手:A 先发送连接释放报文段，段首部的终止控制位 FIN=1，序号seq=u（等于A前面发送数据的最后一个序号加1）；然后 A 进入 FIN-WAIT-1（终止等待1）状态，等待 B 的确认。

• 第二次挥手:B 收到 A 的连接释放报文段后，立刻发出确认报文段，确认号 ack=u+1，序号 seq=v（等于 B 前面发送数据的最后一个序号加1）；然后 B 进入 CLOSE-WAIT（关闭等待）状态。

• 第三次挥手:A 收到 B 的确认报文段后进入到 FIN-WAIT-2（终止等待2）状态，继续等待 B 发出连接释放报文段；

• • 若 B 已经没有数据要发送，B 就会向 A 发送连接释放报文段，段首部的终止控制位 FIN=1，序号 seq=w（半关闭状态可能又发送了一些数据），确认号 ack=u+1，这时B进入 LAST-ACK（最后确认）状态，等待A的确认。

• 第四次挥手:A收到B的连接释放报文段并发出确认，确认段中 确认位 ACK=1，确认号 ack=w+1，序号 seq=u+1；然后 A 进入到TIME-WAIT（时间等待）状态。当 B 再接收到该确认段后，B 就进入 CLOSED 状态。

• 1.得原来连接的数据包消失

• • 1）如果B没有收到自己的ACK，会超时重传FiN那么A再次接到重传的FIN，会再次发送ACK
  • 2）如果B收到自己的ACK，也不会再发任何消息，
  • 在最后一次挥手后 A 并不知道 B 是否接到自己的 信息

包括 ACK 是以上哪两种情况，A 都需要等待，要取这两种情况等待时间的最大值，以应对最坏的情况发生，这个最坏情况是：去向ACK消息最大存活时间（MSL) + 来向FIN消息的最大存活时间(MSL)。这刚好是2MSL，这个时间，足以使得原来连接的数据包在网络中消失。

• 2.保证 ACK 能被服务端接收到从而正确关闭链接

• • 因为这个 ACK 是有可能丢失的，会导致服务器收不到对 FIN-ACK 确认报文。假设客户端不等待 2MSL ，而是在发送完 ACK 之后直接释放关闭，一但这个 ACK 丢失的话，服务器就无法正常的进入关闭连接状态。

服务端收到第三次握⼿的 ACK 后，内核会把连接从半连接队列移除，然后创建新的完全的连接，并将其添加到全连接队列(accept 队列)，等待进程调⽤ accept 函数时把连接取出来。

这两个队列都是有大小限制的，当超过容量后就会将链接丢弃，或者返回 RST 包。

TCP 发送数据时会根据 TCP 缓冲区的实际情况进行包的划分，一个完整的包可能会被 TCP 拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是 TCP 粘包和拆包问题。

• 1.发送的数据小于 TCP 缓冲区大小，TCP将缓冲区中的数据(数据属于多条业务内容)一次发送出去可能就会发生粘包。
• 2.接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。

发生 TCP 拆包的原因:

• 1.待发送数据大于最大报文长度，TCP 在传输前将进行拆包。
• 2.发送的数据大于 TCP 发送缓冲区剩余空间大小，将会发生拆包。

• 1.发送端给每个数据包添加包首部，首部中包含数据包的长度，这样接收端在接收到数据后，通过该字段就可以知道每个数据包的实际长度了。
• 2.发送端将每个数据包设置固定长度，这样接收端每次从读取固定长度的数据把每个数据包拆分开。
• 3.可以在数据包之间设置边界，如添加特殊符号，接收端可以通过这个特殊符号来拆分包。

如果接收方处理不过来，发送方就会触发重试机制再次发送数据，然而这个是有性能损耗的，为了解决这个问题，TCP 就提出了流量控制，为的就是让发送方知道接受方的处理能力。

也就是说，每次接收方接受到数据后会将剩余可处理数据的大小告诉发送方。

比如接受方滑动窗口可用大小为400字节，发送方发送过来100字节的数据，那么接收方剩余可用滑动窗口大小就为300字节，这是发送方就知道下次返送数据的大小范围了。

但是这里有一个问题，数据会存放在缓冲区，但是这个缓冲区是操作系统控制的，当系统繁忙的时候，会缩减缓冲区减小，可能就会造成丢包的问题。

PING 主要的作用就是测试在两台主机之间能否建立连接，如果 PING 不通就无法建立连接。

它其实就是向目的主机发送多个 ICMP 回送请求报文

• 如果没有响应则无法建立连接
• 如果有响应就可以根据目的主机返回的回送报文的时间和成功响应的次数估算出数据包往返时间及丢包率

1.加载BIOS的硬件信息，获取第一个启动设备

2.读取第一个驱动设备MBR的引导加载程序(grub)的启动信息

3.加载核心操作系统的核心信息，核心开始解压缩，并尝试驱动所有硬件设备

4.核心执行init程序，并获取默认的运行信息

5.init程序执行/etc/rc.d/rc.sysinit文件，重新挂载根文件系统

6.启动核心的外挂模块

7.init执行运行的各个批处理文件(scripts)

8.init执行/etc/rc.d/rc.local

9.执行/bin/login程序，等待用户登录

10.登录之后开始以shell控制主机

1.UEFi或BIOS初始化，运行POST开机自检

2.选择启动设备

3.引导装载程序, centos7是grub2,加载装载程序的配置文件：
/etc/grub.d/
/etc/default/grub
/boot/grub2/grub.cfg

4.加载initramfs驱动模块

5.加载内核选项

6.内核初始化，centos7使用systemd代替init

7.执行initrd.target所有单元，包括挂载/etc/fstab

8.从initramfs根文件系统切换到磁盘根目录

9.systemd执行默认target配置，配置文件/etc/systemd/system/default.target

10.systemd执行sysinit.target初始化系统及basic.target准备操作系统

11.systemd启动multi-user.target下的本机与服务器服务

12.systemd执行multi-user.target下的/etc/rc.d/rc.local

13.Systemd执行multi-user.target下的getty.target及登录服务

14.systemd执行graphical需要的服务

当服务器连接多于最大连接数时dmesg 可以观察到 ：kernel: ip_conntrack: table full, dropping packet错误,并且导致建立TCP连接很慢。

连接过多的解决方法两个：

(1) 加大nf_conntrack_max 值

(2) 降低 nf_conntrack timeout时间

1.造成主从不一致的原因

• 主库binlog格式为Statement（语句型），同步到从库执行后可能造成主从不一致。（把binlog 改成行型）
• 主库执行更改前有执行set sql_log_bin=0，会使主库不记录binlog，从库也无法变更这部分数据。
• 从节点未设置只读，误操作写入数据
• 主库或从库意外宕机，宕机可能会造成binlog或者relaylog文件出现损坏，导致主从不一致主从实例版本不一致，特别是高版本是主，低版本为从的情况下，主数据库上面支持的功能，从数据库上面可能不支持该功能
• MySQL自身bug导致

2.主从不一致修复方法

• 将从库重新实现
  虽然这也是一种解决方法，但是这个方案恢复时间比较慢，而且有时候从库也是承担一部分的查询操作的，不能贸然重建。
• 使用percona-toolkit工具辅助
  PT工具包中包含pt-table-checksum和pt-table-sync两个工具，主要用于检测主从是否一致以及修复数据不一致情况。这种方案优点是修复速度快，不需要停止主从辅助，缺点是需要知识积累，需要时间去学习，去测试，特别是在生产环境，还是要小心使用
  关于使用方法，可以参考下面链接：https://www.cnblogs.com/feiren/p/7777218.html
• 手动重建不一致的表
  在从库发现某几张表与主库数据不一致，而这几张表数据量也比较大，手工比对数据不现实，并且重做整个库也比较慢，这个时候可以只重做这几张表来修复主从不一致这种方案缺点是在执行导入期间需要暂时停止从库复制，不过也是可以接受的

3.如何避免主从不一致

• 主库binlog采用ROW格式
• 主从实例数据库版本保持一致
• 主库做好账号权限把控，不可以执行set sql_log_bin=0
• 从库开启只读，不允许人为写入
• 定期进行主从一致性检验