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

时间：2019-01-06 21:57:26 阅读：225 评论：0 收藏：0 [点我收藏+]

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报文。
局域网：基于广播机制，全域网：基于点对点，

标签：并保存 dir 卷标自带 nop x86 base 服务端消息

原文地址：http://blog.51cto.com/14128387/2339449

踩

(0)

评论一句话评论（0）

分享档案

更多>

2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)

周排行