Rpm、yum；磁盘储存与文件系统；网络基础

rpm包命名方式：
name-VERSION-release.arch.rpm
例：bash-4.2.46-19.el7.x86_64.rpm
包之间：可能存在依赖关系，甚至循环依赖
解决依赖包管理工具：
yum：rpm包管理器的前端工具
dnf: Fedora 18+ rpm包管理器前端管理工具
配置文件：/etc/ld.so.conf, /etc/ld.so.conf.d/*.conf 放库的调用文件
缓存文件：/etc/ld.so.cache
Rpm包安装
[install-options]
--test: 测试安装，但不真正执行安装，即dry run模式
--nodeps：忽略依赖关系
--replacepkgs | replacefiles
--nosignature: 不检查来源合法性
--nodigest：不检查包完整性
--noscripts：不执行程序包脚本
%pre: 安装前脚本 --nopre
%post: : 安装后脚本 --nopost
%preun: 卸载前脚本 --nopreun
%postun: 卸载后脚本 --nopostun
Rpm包升级
upgrade：安装有旧版程序包，则“升级”
若是不存在旧版程序包，则“安装”
freshen：安装有旧版程序包，则“升级”
若是不存在旧版程序包，则不执行升级操做
rpm -Uvh PACKAGE_FILE ...
rpm -Fvh PACKAGE_FILE ...
--oldpackage：降级
--force: 强制安装
Rpm包查询
-a: 全部包 -f: 查看指定的文件由哪一个程序包安装生成
-p rpmfile：针对还没有安装的程序包文件作查询操做
-c: 查询程序的配置文件 -d: 查询程序的文档
-i: information -l: 查看指定的程序包安装后生成的全部文件
--scripts：程序包自带的脚本 -e：卸载 包名
-R: 查询指定的程序包所依赖的CAPABILITY
数据库重建：
/var/lib/rpm
rpm {--initdb|--rebuilddb}
initdb: 初始化
若是事先不存在数据库，则新建之
不然，不执行任何操做
rebuilddb：重建已安装的包头的数据库索引目录
yum
Yum repository: yum repo，存储了众多rpm包，以及包的相关的元数据
文件（放置于特定目录repodata下） repodata/ 此目录在哪一个文件夹下，仓库的路径就在哪里
文件服务器：http:// https:// ftp:// file://
Yum配置文件
仓库指向的定义：
[repositoryID]
name=Some name for this repository
baseurl=url://path/to/repository/
enabled={1|0}
gpgcheck={1|0} 设置为0 表示不检查
gpgkey=URL
yum命令的用法：
yum [options] [command] [package ...]
显示仓库列表：
yum repolist [all|enabled|disabled]
安装程序包：
yum install package1 [package2] [...]
yum reinstall package1 [package2] [...] (从新安装)
升级程序包： yum update [package1] [package2] [...]
yum downgrade package1 [package2] [...] (降级)
检查可用升级： yum check-update
卸载程序包： yum remove | erase package1 [package2] [...]
清理本地缓存：
清除/var/cache/yum/$basearch/$releasever缓存
yum clean [ packages | metadata | expire-cache | rpmdb | plugins | all ]
构建缓存：yum makecache
系统光盘yum仓库
系统安装光盘做为本地yum仓库：
(1) 挂载光盘至某目录，例如/mnt/cdrom
mount /dev/cdrom /mnt/cdrom
(2) 建立配置文件
[CentOS7]
name=
baseurl=
gpgcheck=
enabled=
两种分区方式：MBR，GPT fdisk 建立MBR分区
• gdisk 建立GPT分区 • parted 高级分区操做
从新设置内存中的内核分区表版本 • partprobe
gdisk /dev/sdb 类fdisk 的GPT分区工具
fdisk -l [-u] [device...] 查看分区
fdisk /dev/sdb 管理分区
子命令： p 分区列表 t 更改分区类型
n 建立新分区 d 删除分区 v 校验分区 u 转换单位
w 保存并退出 q 不保存并退出
建立文件系统
mkfs命令： (1) mkfs.FS_TYPE /dev/DEVICE
ext4 xfs btrfs vfat
(2)mkfs -t FS_TYPE /dev/DEVICE -L 'LABEL' 设定卷标
建立ext文件系统mke2fs：ext系列文件系统专用管理工具-t {ext2|ext3|ext4} 指定文件系统类型-b {1024|2048|4096} 指定块大小-L ‘LABEL’ 设置卷标-j 至关于 -t ext3 mkfs.ext3 = mkfs -t ext3 = mke2fs -j = mke2fs -t ex
findfs ：查找分区
挂载mount
挂载:将额外文件系统与根文件系统某现存的目录创建起关联关系，进而使得此
目录作为其它文件访问入口的行为
卸载:为解除此关联关系的过程
把设备关联挂载点：mount Point
mount
卸载时：可以使用设备，也可使用挂载点
umount 设备名|挂载点
挂载点下原有文件在挂载完成后会被临时隐藏
挂载点目录通常为空
卸载命令
查看挂载状况
findmnt MOUNT_POINT|device
查看正在访问指定文件系统的进程
lsof MOUNT_POINT
fuser -v MOUNT_POINT
终止全部在正访问指定的文件系统的进程
fuser -km MOUNT_POINT
卸载
umount DEVICE
umount MOUNT_POINT
使用光盘： 建立ISO文件
cp /dev/cdrom /root/centos.iso
mkisofs -r -o /root/etc.iso /etc
刻录光盘
wodim –v –eject centos.iso
手动挂载• mount /dev/sdb1 /m
挂载工具：dd命令：convert and copy a file
用法：
dd if=/PATH/FROM/SRC of=/PATH/TO/DEST bs=# count=#
if=file 从所命名文件读取而不是从标准输入
of=file 写到所命名的文件而不是到标准输出
ibs=size 一次读size个byte
obs=size 一次写size个byte
bs=size block size, 指定块大小（既是是ibs也是obs)
cbs=size 一次转化size个byte
skip=blocks 从开头忽略blocks个ibs大小的块
seek=blocks 从开头忽略blocks个obs大小的块
count=n 复制n个bs
备份MBR
dd if=/dev/sda of=/tmp/mbr.bak bs=512 count=1
破坏MBR中的bootloader
dd if=/dev/zero of=/dev/sda bs=64 count=1 seek=446
有一个大与2K的二进制文件fileA。如今想从第64个字节位置开始读取，须要读取的大小是128Byts。又有fileB, 想把上面读取到的128Bytes写到第32个字节开始的位置，替换128Bytes，实现以下
dd if=fileA of=fileB bs=1 count=128 skip=63 seek=31 conv=notrunc
备份：
dd if=/dev/sdx of=/dev/sdy
将本地的/dev/sdx整盘备份到/dev/sdy
dd if=/dev/sdx of=/path/to/image
将/dev/sdx全盘数据备份到指定路径的image文件
dd if=/dev/sdx | gzip >/path/to/image.gz
备份/dev/sdx全盘数据，并利用gzip压缩，保存到指定路径
恢复：
dd if=/path/to/image of=/dev/sdx
将备份文件恢复到指定盘
gzip -dc /path/to/image.gz | dd of=/dev/sdx
将拷贝内存资料到硬盘
dd if=/dev/mem of=/root/mem.bin bs=1024
将内存里的数据拷贝到root目录下的mem.bin文件
从光盘拷贝iso镜像 dd if=/dev/cdrom of=/root/cd.iso
拷贝光盘数据到root文件夹下，并保存为cd.iso文件压缩的备份文件恢复到指定盘
为现有逻辑卷建立快照
lvcreate -l 64 -s -n data-snapshot -p r /dev/vg0/data
挂载快照
mkdir -p /mnt/snap
mount -o ro /dev/vg0/data-snapshot /mnt/snap
恢复快照
umount /dev/vg0/data-snapshot
umount /dev/vg0/data
lvconvert --merge /dev/vg0/data-snapshot
删除快照
umount /mnt/databackup
lvremove /dev/vg0/databackup
建立逻辑卷示例
建立物理卷
pvcreate /dev/sda3
为卷组分配物理卷
vgcreate vg0 /dev/sda3
从卷组建立逻辑卷
lvcreate -L 256M -n data vg0
mkfs.xfs -j /dev/vg0/data
 挂载
mount /dev/vg0/data /mnt/data
网络基础部分
网络：一些网络设备，利用各类媒介连接起来，按照通信规则，造成的通信的集合。
路由器:(rooter）
交换机：swith
单工：单向 单双工：轮流双向 全双工：同时双向
TCP/IP 堆栈（来源于以太网） OSI参考模型
（传输控制协议/因特网互联协议：是集合，不是2个协议）
应用层 message 应用层 http协议工做在此
传输层 段 传输层 UDP TCP工做在此
Internet层 包 网络层 路由器在此 选择路径 IP地址是逻辑地址 做用在此
数据链路层 帧 数据链路层 以太网卡在物理地址
物理层 位 物理层 Hub在此
单播：一个电脑发一个数据，目标地址是一个主机，目标地址就是单播地址
广播：目标地址是全部主机，出现48个1，广播地址出现于目标地址，广播越多，性能越差
多播：目标地址是部分主机
冲突域：一个设备向外发数据，另外一个也在发，两个相遇就冲突，连接的主机多冲突域多，性能越差
TIME_WAIT:最纠结的状态来了。从状态图上能够看出，有三个状态能够转化成它：
a:由FIN_WAIT_2进入此状态：在双方不一样时发起FIN的状况下，主动关闭的一方在完成自身发起的关闭请求后，接收到被动关闭一方的FIN后进入的状态。
b:由CLOSING状态进入:双方同时发起关闭，都作了发起FIN的请求，同时接收到了FIN并作了ACK的状况下，有CLOSING状态进入。
c:由FIN_WAIT_1状态进入：同时接收到FIN(对方发起)，ACK(自己发起的FIN回应)，与b的区别在于自己发起的FIN回应的ACK先于对方的FIN请求到达，而b是FIN先到达。这种状况几率最小。
关闭的4次链接最难理解的状态是TIME_WAIT，存在TIME_WAIT的2个理由：
1.可靠地实现TCP全双工链接的终止。
2.容许老的重复分节在网络中消逝。
问题：TCP创建链接时，为何是 三次握手呢？
client发出的第一个链接请求报文段并无丢失，而是在某个网络结点长时间的滞留了，以至延误到链接释放之后的某个时间才到达server。原本这是一个早已失效的报文段。但server收到此失效的链接请求报文段后，就误认为是client再次发出的一个新的链接请求。因而就向client发出确认报文段，赞成创建链接。假设不采用“三次握手”，那么只要server发出确认，新的链接就创建了。因为如今client并无发出创建链接的请求，所以不会理睬server的确认，也不会向server发送数据。但server却觉得新的运输链接已经创建，并一直等待client发来数据。这样，server的不少资源就白白浪费掉了。采用“三次握手”的办法能够防止上述现象发生。例如刚才那种状况，client不会向server的确认发出确认。server因为收不到确认，就知道client并无要求创建链接。”在google上搜到的网友的解释：
这个问题的本质是, 信道不可靠, 可是通讯双发须要就某个问题达成一致. 而要解决这个问题, 不管你在消息中包含什么信息, 三次通讯是理论上的最小值. 因此三次握手不是TCP自己的要求, 而是为了知足"在不可靠信道上可靠地传输信息"这一需求所致使的. 请注意这里的本质需求,信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就不要紧了. 所以,若是信道是可靠的, 即不管何时发出消息, 对方必定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就能够了.”
为何创建链接协议是三次握手，而关闭链接倒是四次握手呢？
这是由于服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它能够把ACK和SYN（ACK起应答做用，而SYN起同步做用）放在一个报文里来发送。但关闭链接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你全部的数据都所有发送给对方了，因此你可能未必会立刻会关闭SOCKET,也即你可能还须要发送一些数据给对方以后，再发送FIN报文给对方来表示你赞成如今能够关闭链接了，因此它这里的ACK报文和FIN报文多数状况下都是分开发送的。
为何TIME_WAIT状态还须要等2MSL后才能返回到CLOSED状态？
这是由于：虽然双方都赞成关闭链接了，并且握手的4个报文也都协调和发送完毕，按理能够直接回到CLOSED状态（就比如从SYN_SEND状态到 ESTABLISH状态那样）；可是由于咱们必需要假想网络是不可靠的，你没法保证你最后发送的ACK报文会必定被对方收到，所以对方处于 LAST_ACK状态下的SOCKET可能会由于超时未收到ACK报文，而重发FIN报文，因此这个TIME_WAIT状态的做用就是用来重发可能丢失的 ACK报文。
局域网：基于广播机制，全域网：基于点对点，