步骤一：修改 snmp 的配置文件
# vim /etc/snmp/snmpd.conf将以下内容：
......
group gpublic v1 upublic
group gpublic v2c upublic
......修改为：
......
# group gpublic v1 upublic
# group gpublic v2c upublic
......步骤二：让修改的内容生效
# systemctl restart snmpd[内容] Linux 用户登陆的超时时间的设置
内容一：临时设置用户登陆的超时时间
# TMOUT=900或者：
# export TMOUT=0（
补充：
1) 这里以设置超过 900 秒用户就会超时为例
2) 如果 TMOUT=0 则用户永不会超时
）
内容二：永久设置用户登陆的超时时间
2.1 通过 /etc/profile 文件实现
2.1.1 修改 /etc/profile 文件
# vim /etc/profile添加以下内容：
......
TMOUT=900（
补充：
1) 这里以设置超过 900 秒用户就会超时为例
2) 如果 TMOUT=0 则用户永不会超时
3) 补充 /etc/bashrc 文件会比 /etc/profile 文件更有优先级
）
2.1.2 使刚刚的设置生效
# source /etc/profile2.2 通过 /etc/bashrc 文件实现
2.2.1 修改 /etc/bashrc 文件
# vim /etc/bashrc添加以下内容：
......
TMOUT=900（
补充：
1) 这里以设置超过 900 秒用户就会超时为例
2) 如果 TMOUT=0 则用户永不会超时
3) 补充 /etc/bashrc 文件会比 /etc/profile 文件更有优先级
）
2.2.2 使刚刚的设置生效
# source /etc/bashrc内容三：显示现在用户登陆的超时时间
# echo $TMOUT补充：
当通过以上设置造成用户登陆超时时，系统会输出以下内容：
# timed out waiting for input: auto-logout[步骤] Linux 周期性计划任务 cron 的设置
步骤目录：
步骤一：进入周期任务计划的文件
1.1 案例一：直接进入周期任务计划的文件
1.2 案例二：以某一个用户的身份进入周期任务计划的文件
步骤二：设置周期任务计划
2.1 设置周期任务计划的格式
2.2 设置周期任务计划的案例
2.2.1 案例一
2.2.2 案例二
2.2.3 案例三
步骤三：显示已设置的周期任务计划
3.1 案例一：显示本用户已设置的周期任务计划
3.2 案例二：以某一个用户的身份进入周期任务计划的文件
补充：# crontab -e 命令所编辑的文件所在位置
具体的操作步骤：
步骤一：进入周期任务计划的文件
1.1 案例一：直接进入周期任务计划的文件
# crontab -e1.2 案例二：以某一个用户的身份进入周期任务计划的文件
# crontab -u root -e（补充：这里以使用 root 用户的身份进入周期任务计划的文件为例）
步骤二：设置周期任务计划
2.1 设置周期任务计划的格式
<what minute> <what hour> <day of the month> <what month> <day of the week> <command>（
补充：
1) 当以上内容是 1 个星号 “*” 时，代表任意时刻都会执行
2) 当在某一个时刻执行时，可以直接写入对应的数字，例如：0，代表在 0 时执行
3) 当同时在多个时刻执行时，可以直接写入多个对应的数字，例如：0,15,30，代表在 0 时、15 时、30 时都会执行
4) 当每隔一段时间就执行时，可以在星号 “*” 后面添加斜杠和间隔的数字，例如：*/5，代表每隔 5 就会执行 1 次
5) 当是执行 /sbin 下的命令时，需要使用命令的全路径
6) 有些特殊符号不会在此地起作用，例如：$(<command>)
）
2.2 设置周期任务计划的案例
2.2.1 案例一
0 1 * * * curl eternalcenter.com（补充：此案例会在每天 1 点 0 时访问一次 eternalcenter.com）
2.2.2 案例二
*/5 * * * * curl eternalcenter.com（补充：此案例会每过 5 分钟访问一次 eternalcenter.com）
2.2.3 案例三
0 0 1,5,10,15 /sbin/reboot（补充：此案例会在每个月的 1 号 5 号 10 号 15 号的 0 点 0 分重启系统）
步骤三：显示已设置的周期任务计划
3.1 案例一：显示本用户已设置的周期任务计划
# crontab -l3.2 案例二：以某 1 个用户的身份进入周期任务计划的文件
# crontab -u root -l（补充：这里以显示 root 用户已设置的周期任务计划为例）
补充：# crontab -e 命令所编辑的文件所在位置
# crontab -e 设置的结果 /var/spool/cron/crontabs 目录中
[步骤] Linux Kdump 的开启 （用于收集内核崩溃时的信息）
步骤一：允许 Kdump 使用内存
1.1 方法一：在 /etc/default/grub 文件里修改 crashkernel 参数
1.1.1 在 /etc/default/grub 文件里修改 crashkernel 参数
# vim /etc/default/grub在这一行里：
.....
GRUB_CMDLINE_LINUX_DEFAULT="......"
.....确保有：
.....
GRUB_CMDLINE_LINUX="crashkernel=auto......"
.....并确保此文件其他地方没有和 crashkernel= 相关的参数
（补充：这里的 auto 代表系统会根据内存大小自动设置一个值，也可以指定一个值，例如：crashkernel=crashkernel=128M,high、crashkernel=crashkernel=256M,high 等等，但是建议设置成 crashkernel=crashkernel=512M,high）
1.1.2 让刚刚修改的内核参数生效
# grub2-mkconfig -o /boot/grub2/grub.cfg# reboot1.2 方法二：通过 yast 工具修改 crashkernel 参数
1.2.1 通过 yast 工具修改 crashkernel 参数
# yast kdump之后将 –Start-Up 中的 Kdump Low Memory [MiB] (72 – 3069) 修改为 256，将 –Start-Up 中的 Kdump High Memory [MiB] (0 – 7168) 修改为 512，之后再选择 [ OK ]
（补充：当 Kdump Low Memory 设置为 256，Kdump High Memory 设置为 512 时更易触发 Kdump）
（注意：方法二只有 openSUSE & SUSE 可以使用）
1.2 让刚刚修改的内核参数生效
# reboot步骤二：修改 Kdump 的配置信息
2.1 修改 Kdump 的配置文件
# vim /etc/kdump.conf将以下内容：
......
path /var/crash
core_collector makedumpfile -l --message-level 1 -d 31
......修改为：
......
path /var/crash
core_collector makedumpfile -c -l --message-level 1 -d 31
default reboot
......（
补充：
1) path /var/crash
2) -c 参数会对搜集的内核崩溃时的信息进行压缩
3) default reboot 参数会让 KDUMP 收集完内核崩溃时的信息后重启
）
2.2 让刚刚修改的 Kdump 配置文件生效
# systemctl enable --now kdump.service步骤三：测试 Kdump
3.1 造成系统内核崩溃
# echo 1 > /proc/sys/kernel/sysrq ; echo c > /proc/sysrq-trigger（注意：此时系统会自动崩溃并重启）
3.2 显示 Kdump 生成内核崩溃信息
# ls /var/crash/<date>/vmcore（补充：这里的内核崩溃信息存放目录 /var/crash/，是刚刚在 /etc/kdump.conf 文件里指定的）
[步骤] CentOS Linux & RHEL 系统的优化 （通过 tuned 实现）
步骤一：系统环境要求
服务器系统要配置好可用的软件源
步骤二：安装 tuned 系统优化软件
# yum -y install tuned步骤三：显示 tuned 推荐的优化模式
# tuned-adm recommend
virtual-guest步骤四：切换至 tuned 推荐的优化模式
# tuned-adm profile virtual-guest步骤五：显示当前的优化模式
# tuned-adm active
Current active profile: virtual-guest补充：取消 tuned 系统优化的方法
# tuned-adm off