【centos使用系列】玩转centos7之程序安装与启动(rpm、yum、systemd)

提示

进行下面的操作前,最好修改下dns(查找速度):

vim /etc/resolv.conf

升级curl、nss:
yum update nss curl

程序安装包技术rpm

rpm包与源码包的对比

rpm help命令

本机已安装的包

程序安装关键技术yum

repo概念

repo文件是Fedora中yum源(软件仓库)的配置文件,通常一个repo文件定义了一个或者多个软件仓库的细节内容。
例如我们将从哪里下载需要安装或者升级的软件包,repo文件中的设置内容将被yum读取和应用!
更多的源介绍,可以参考: https://jxdw.github.io/2017/08/05/centos7-repo-introduce/

yum介绍

yum(Yellow dog Updater, Modified)是一个在Fedora和RedHat以及SUSE中的Shell前端软件包管理器。
基于RPM包管理,能够从指定的服务器自动下载RPM包并且安装,可以自动处理依赖性关系,并且一次安装所有依赖的软体包,无须繁琐地一次次下载、安装。
yum提供了查找、安装、删除某一个、一组甚至全部软件包的命令,而且命令简洁而又好记。
YUM的工作原理并不复杂,每一个 RPM软件的头(header)里面都会纪录该软件的依赖关系,那么如果可以将该头的内容纪录下来并且进行分析,可以知道每个软件在安装之前需要额外安装 哪些基础软件。
也就是说,在服务器上面先以分析工具将所有的RPM档案进行分析,然后将该分析纪录下来,只要在进行安装或升级时先查询该纪录的文件,就可以知道所有相关联的软件。

yum配置文件解析

cat /etc/yum.conf
[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=5
bugtracker_url=http://bugs.centos.org/set_project.php?project_id=23&ref=http://bugs.centos.org/bug_report_page.php?category=yum
distroverpkg=centos-release

各个文件存放在/etc/yum.repos.d目录下。

更换yum源

一直有一个现实的问题:在国内下载某些国外的软件会很慢。所以,一般会选择aliyun或者163的源仓库。
更换步骤:

备份原来的yum源

cp /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak 

设置aliyun的yum源

wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo 

添加EPEL源

EPEL (http://fedoraproject.org/wiki/EPEL) 是由 Fedora 社区打造,为 RHEL 及衍生发行版如 CentOS、Scientific Linux 等提供高质量软件包的项目。
装上 EPEL后,可以像在 Fedora 上一样,可以通过 yum install package-name,安装更多软件。

wget -P /etc/yum.repos.d/ http://mirrors.aliyun.com/repo/epel-7.repo 

清理缓存并生成新的缓存

yum clean all  
yum makecache

其他的源

暂时不需要更新内核,所以,就不用装elrepo源。
自此,结束。

yum其他命令

输入man yum可以看到参考手册:

程序启动关键技术systemd

systemd的历史

Systemd目的是要取代Unix时代以来一直在使用的init系统,兼容SysV和LSB的启动脚本,而且够在进程启动过程中更有效地引导加载服务。
Systemd的很多概念来源于苹果Mac OS操作系统上的launchd,不过launchd专用于苹果系统,因此长期未能获得应有的广泛关注。Systemd借鉴了很多launchd的思想。
Systemd是Linux系统中最新的初始化系统(init),它主要的设计目标是克服SysV init 固有的缺点,提高系统的启动速度。
systemd和ubuntu的upstart 是竞争对手,预计会取代 UpStart,然而在Ubuntu 15.04采用systemd作为默认引导程序,debian8也开始使用systemd。足以看出systemd的流行度。

systemd的特点

CentOS 7使用systemd替换了SysV。下面是一些特别要注意的和之前主要版本的RHEL不再兼容的部分。
1.systemd对运行级别支持有限
为了保存兼容,systemd提供一定数量的target单元,可以直接和运行级别对应,也可以被早期的分布式的运行级别命令支持。不是所有的target都可以被映射到运行级别,在这种情况下,使用runlevel命令有可能会返回一个为N的不知道的运行级别,所以推荐尽量避免在RHEL7中使用runlevel命令。

2.systemd不支持像init脚本那样的个性化命令。
除了一些标准命令参数例如:start、stop、status,SysV init脚本可以根据需要支持想要的任何参数,通过参数提供附加的功能,因为SysV init的服务器脚本实际上就是shell脚本,命令参数实际上就是shell子函数。举个例子,RHEL6的iptables服务脚本可以执行panic命令行参数,这个参数可以让系统立即进入紧急模式,丢弃所有的进入和发出的数据包。但是类似这样的命令行参数在systemd中是不支持的,systemd只支持在配置文件中指定命令行参数。

3.systemd不支持和没有从systemd启动的服务通讯
当systemd启动服务的时候,他保存进程的主ID以便于追踪,systemctl工具使用进程PID查询和管理服务。相反的,如果用户从命令行启动特定的服务,systemctl命令是没有办法判断这个服务的状态是启动还是运行的。

4.systemd可以只停止运行的服务
在RHEL6及之前的版本,当关闭系统的程序启动之后,RHEL6的系统会执行/etc/rc0.d/下所有服务脚本的关闭操作,不管服务是处于运行或者根本没有运行的状态。而systemd可以做到只关闭在运行的服务,这样可以大大节省关机的时间。

5.不能从标准输出设备读到系统服务信息。
systemd启动服务的时候,将标准输出信息定向到/dev/null,以免打扰用户。

6.systemd不继承任何上下文环境。
systemd不继承任何上下文环境,如用户或者会话的HOME或者PATH的环境变量。每个服务得到的是干净的上下文环境。

7.SysV init脚本依赖性。
当systemd启动SysV init脚本,systemd在运行的时候,从LinuxStandardBase(LSB)Linux标准库头文件读取服务的依赖信息并继承。

8.超时机制。
为了防止系统被卡住,所有的服务有5分钟的超时机制。

systemd的架构和优缺点

Systemd 的优点是功能强大,使用方便,缺点是体系庞大,非常复杂。
事实上,现在还有很多人反对使用 Systemd,理由就是它过于复杂,与操作系统的其他部分强耦合,违反”keep simple, keep stupid”的Unix 哲学。
下图是systemd的架构图(图片来自网络):

systemd的概念模型

单元的概念

在RHEL7之前,服务管理是分布式的被SysV init或UpStart通过/etc/rc.d/init.d下的脚本管理。这些脚本是经典的Bash脚本,允许管理员控制服务的状态。在RHEL7中,这些脚本被服务单元文件替换。
系统初始化需要做的事情非常多。需要启动后台服务,比如启动 SSHD 服务;需要做配置工作,比如挂载文件系统。这个过程中的每一步都被 systemd 抽象为一个配置单元,即 unit。Systemd可以管理所有系统资源。不同的资源统称为 Unit(单位)。可以认为一个服务是一个配置单元;一个挂载点是一个配置单元;一个交换分区的配置是一个配置单元;等等。systemd 将配置单元归纳为以下一些不同的类型。然而,systemd 正在快速发展,新功能不断增加。所以配置单元类型可能在不久的将来继续增加。systemd中有许多单元类型,服务单元文件的扩展名是.service,同脚本的功能相似。例如有查看、启动、停止、重启、启用或者禁止服务的参数。
下面说明下,systemd单元文件放置位置:
/run/systemd/system #单元运行时创建,这个目录优先于按照目录
/etc/systemd/system #系统管理员创建和管理的单元目录,优先级最高
/usr/lib/systemd/system/system #默认单元文件安装目录
有了对systemd的基本认识后,下面就开始来介绍相关的操作命令。但是注意一点,systemd并不是一个命令,而是一组命令,涉及到系统管理的方方面面。

systemd命令

1.查看当前系统的所有Unit

systemctl list-units #列出正在运行的Unit
systemctl list-units --all #列出所有Unit,包括没有找到配置文件的或者启动失败的
systemctl list-units --all --state=inactive #列出所有没有运行的Unit
systemctl list-units --failed #列出所有加载失败的Unit
systemctl list-units --type=service #列出所有正在运行的、类型为service的Unit

2.unit.service管理命令

systemctl start name.service #启动一个服务
systemctl stop name.service #关闭一个服务
systemctl restart name.service #重启一个服务
systemctl reload name.service #重载一个服务
systemctl try-restart name.service #仅当服务运行的时候,重启服务
systemctl kill name.service # 杀死一个服务的所有子进程
systemctl daemon-reload #重载所有修改过的配置文件
systemctl enable name.service #允许服务开机启动
systemclt disable name.service #禁止服务开机启动
systemctl list-dependencies nginx.service #命令列出一个Unit的所有依赖
systemctl show httpd.service #显示某个Unit的所有底层参数
systemctl show -p CPUShares httpd.service #显示某个Unit的指定属性的值
systemctl set-property httpd.service CPUShares=500 # 设置某个Unit的指定属性

3.电源管理命令(systemctl)

systemctl reboot         #重启机器
systemctl poweroff #关机
systemctl suspend #待机
systemctl hibernate #休眠
systemctl hybrid-sleep #混合休眠模式(同时休眠到硬盘并待机)

4.系统引导性能分析命令(systemd-analyze)

5.systemd的日志服务
systemd 自带日志服务 journald,该日志服务的设计初衷是克服现有的 syslog 服务的缺点。比如:syslog不安全,消息的内容无法验证。每一个本地进程都可以声称自己是 Apache PID 4711,而 syslog 也就相信并保存到磁盘上。数据没有严格的格式,非常随意。自动化的日志分析器需要分析人类语言字符串来识别消息。一方面此类分析困难低效;此外日志格式的变化会导致分析代码需要更新甚至重写。
Systemd Journal 用二进制格式保存所有日志信息,用户使用 journalctl 命令来查看日志信息。无需自己编写复杂脆弱的字符串分析处理程序。

journalctl #查看所有日志(默认情况下 ,只保存本次启动的日志)
journalctl -k #查看内核日志(不显示应用日志)
journalctl -b #查看系统本次启动的日志
journalctl -b -0
journalctl -b -1 # 查看上一次启动的日志(需更改设置)
journalctl --since="2012-10-30 18:17:16" # 查看指定时间的日志
journalctl --since "20 min ago" # 查看指定时间的日志
journalctl --since yesterday # 查看指定时间的日志
journalctl --since "2015-01-10" --until "2015-01-11 03:00" # 查看指定时间的日志
journalctl --since 09:00 --until "1 hour ago" # 查看指定时间的日志
journalctl -n # 显示尾部的最新10行日志
journalctl -n 20 # 显示尾部指定行数的日志
journalctl -f # 实时滚动显示最新日志
journalctl /usr/lib/systemd/systemd # 查看指定服务的日志
journalctl _PID=1 # 查看指定进程的日志
journalctl /usr/bin/bash # 查看某个路径的脚本的日志
journalctl _UID=33 --since today # 查看指定用户的日志
journalctl -u nginx.service # 查看某个 Unit 的日志
journalctl -u nginx.service --since today
journalctl -u nginx.service -f # 实时滚动显示某个 Unit 的最新日志
journalctl -u nginx.service -u php-fpm.service --since today # 合并显示多个 Unit 的日志
journalctl -p err -b # 查看指定优先级(及其以上级别)的日志,共有8级-0: emerg、1: alert、2: crit、3: err、4: warning、5: notice、6: info、7: debug
journalctl --no-pager # 日志默认分页输出,--no-pager 改为正常的标准输出
journalctl -b -u nginx.service -o json # 以JSON格式(单行)输出
journalctl -b -u nginx.serviceqq -o json-pretty # 以JSON格式(多行)输出,可读性更好
journalctl --disk-usage # 显示日志占据的硬盘空间
journalctl --vacuum-size=1G # 指定日志文件占据的最大空间
journalctl --vacuum-time=1years # 指定日志文件保存多久

例子(mysqld为例)

# systemd service file for MySQL forking server

[Unit]
Description=MySQL Server
Documentation=man:mysqld(8)
Documentation=http://dev.mysql.com/doc/refman/en/using-systemd.html
After=network.target
After=syslog.target

[Install]
WantedBy=multi-user.target
[Service]
User=mysql
Group=mysql
Type=forking
PIDFile=/data/mysql/run/mysqld.pid
# Disable service start and stop timeout logic of systemd for mysqld service.
TimeoutSec=0
# Execute pre and post scripts as root
PermissionsStartOnly=true
# Needed to create system tables
#ExecStartPre=/home/bin/mysqld_pre_systemd
# Start main service
ExecStart=/data/mysql/bin/mysqld --daemonize --pid-file=/data/mysql/run/mysqld.pid $MYSQLD_OPTS
# Use this to switch malloc implementation
EnvironmentFile=-/etc/sysconfig/mysq
# Sets open_files_limit
LimitNOFILE = 65535
Restart=on-failure
RestartPreventExitStatus=1
PrivateTmp=false