Rpmyum;磁盘储存与文件系统;网络基础
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Rpmyum;磁盘储存与文件系统;网络基础相关的知识,希望对你有一定的参考价值。
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报文。
局域网:基于广播机制,全域网:基于点对点,
以上是关于Rpmyum;磁盘储存与文件系统;网络基础的主要内容,如果未能解决你的问题,请参考以下文章