操作系统

Linux系统LVM逻辑卷创建过程以及自动化脚本

最近在上海新建机房的时候,给了我2台M2机型服务器,在做初始化的时候发现有一堆磁盘: 其中挂载的只有 /dev/sda,其他都在那闲着。运管那边告诉我这个机型不能做raid。而根据我这边的业务需求,我并不能一次用到这么多分区,所以必须使用LVM合并使用。 关于LVM的创建,目前网络上一堆详细教程,用起来也非常简单,这里就只贴一下我的过程。 ①、用fdisk给每一个磁盘创建一个8e分区: 这样就完成了一块磁盘,接着我们依次将其他 sdc到sdl的磁盘也操作一把。 ②、全部完成后,使用 pvcreate 将所有分区转化成物理卷,即添加LVM属性信息并划分PE存储单元: 创建完PV之后,就可以使用 pvdisplay 或 pvs 查看详细信息了,篇幅有限,这里我就不贴了。 ③、下面我们需要创建一个VG,然后PV都加入到这个卷组当中,卷名可自定义,比如 vg: 同样,在创建好VG以后,我们也可以使用 vgdisplay 或者 vgs 命来来查看VG的信息(略) ④、接着,使用 lvcreate 命令基于VG创建逻辑卷,vg 和 lvm 我们自定义的名称: 同样我们可以使用 lvdisplay 或者 lvs 命令来查看创建好的逻辑卷的信息(略) ⑤、格式化创建的逻辑卷: ⑥、挂载分区: 这样,我们就完成了LVM的手工创建过程了,我还有一台M2要弄,而且听运管说以后会继续交付这类机型,我可不想这么苦逼的操作了,光那个创建8e格式分区就已经很坑了。 所以,就将上面的操作串成脚本,一键完成: 哦了,就写这么多,以备后用。
阅读全文
操作系统

Linux系统 df 命令显示异常、分区丢失问题解决

本文记录2种因 /etc/mtab 文件异常导致 df 命令显示异常、分区丢失问题的解决过程,以备后用。 一、根目录丢失 前些日子,同事在RTX群里问大家,有台服务器执行 df -h 看不到根目录,该如何解决? 于是我帮忙解决了一把,看了下 /etc/fstab 内容,根目录挂载信息是正常的: 接着,看了下 /etc/mtab 文件内容,发现根目录缺失: 执行 grep -v rootfs /proc/mounts 命令进行修复: 可以看到,根目录已经出现了,再执行 df -h 就正常了: 二、df命令报错 帮同事解决问题后,不巧自己负责的服务器也出现类似问题,执行 df 命令报如下错误: df: cannot read table of mounted file systems: No such file or directory 想着应该可以上述问题原因一样,所以直接执行修复命令,发现报错: 看来是空间不足,找了下发现是 maildrop 目录把根目录撑爆了: 直接清空,在执行 grep -v rootfs /proc/mounts >/etc/mtab 命令进行修复: 已经正常了,maildrop 爆满的问题一般是 crontab 未屏蔽错误造成的,于是顺手将crontab 里面的条目都带上了 2>&1 屏蔽了,下次应该不会出现因为目录爆满导致 mtab 异常的情况了。 三、区别与联系 继续记录一下/etc/fstab和/etc/mtab的区别和联系。 /etc/fstab 文件记录了服务器上硬盘分区信息,启动 Linux 的时候,检查分区的 fsck 命令和挂载分区的 mount 命令都需要 fstab 中的信息,来检查和挂载分区。 /etc/mtab 文件记载的是现在系统已经装载的文件系统,包括操作系统建立的虚拟文件等,每当 mount 挂载分区、umount 卸载分区,都会动态更新 mtab,mtab总是保持着当前系统中已挂载的分区信息,fdisk、df 这类程序,必须要读取 mtab 文件,才能获得当前系统中的分区挂载情况。 当然我们自己还可以通过读取/proc/mount也可以来获取当前挂载信息(即使用文章中用到的修复命令 grep -v rootfs /proc/mounts)。 当 /etc/mtab 因为磁盘满或文件系统异常,导致该文件内缺失常或直接为空,就会出现上文记录的问题了。
阅读全文
脚本编程

巧用echo命令解决Samba批量添加用户难题

最近实在太忙,没时间研究和折腾,所以也没有什么可以分享到博客的。果然,个人博客坚持原创太不不容易了。张戈博客上线2年多,从1天多更,到一天1更、一周一更,直到现在2星期可能有一更的节奏。。。 好了,废话不说了。翻了翻在工作上的印象笔记,发现还是有一些存货可以分享的。 挺久之前,组内新申请了一批开发测试机,需要部署环境。除了一些常见的软件要安装之外,还有一个我之前很少用到的Samba。 Samba的专业解释我就不贴了,百度百科啥的都有。说白了就是Samba安装到Linux服务器上之后,就可以将服务器上的目录映射到Windows、MAC等个人电脑上,类似于Windows的文件共享,使用相当方便,因此,Samba成了组内开发同事的刚需软件。。。(其实对于使用云服务器的站长,Samba可比FTP好用多了,直接本地开发编辑。。。这个后面有空再介绍吧) 这批开发测试机大部分都是基于Centos的Tlinux系统,所以使用yum install -y samba 就能安装了。安装后发现需要在每台服务器上都配置组内30多个成员的samba账号,手工单个的加太苦逼了,于是写了一个Samba批量添加用户的脚本了。 使用也非常简单,将如上代码保存为 addsmbuser.sh,然后将需要添加的用户名一行一个保存到一个文本文件,比如userlist,然后执行 sh addsmbuser.sh userlist 就能批量添加这些用户了,初始密码和用户名一致。 当然,直接执行 sh addsmbuser.sh  + 用户名 还能添加单个用户。 由于smbpasswd正常使用是需要交互进行的,也就是输入用户名,再输入密码,这种批量交互的活完全可以使用expect脚本来完成。但是本文比较巧妙的利用了echo -e 可以输出回车符(\n)的特性,非常轻巧的完成了任务。 暂时就写这么多,后面有时间再整理下坑爹的SuSE下如何编译安装Samba,以及Samba的简单使用。
阅读全文
操作系统

分享一次Linux任务计划crontab不执行的问题排查过程

朋友弄了一个小项目,要我帮忙做下Linux系统运维,上线一段时间后,发现项目偶尔会挂掉导致服务不可用。开发朋友一时之间也没空去研究项目奔溃的根因,只好由我这个运维先写一个项目进程自拉起脚本,通过Linux任务计划每分钟检查一下进程是否存在来避免项目挂了没人管的情况。 自拉起脚本很简单,随便写几行就搞定了: 然后丢到 crontab,1分钟执行一次: 本以为万事大吉了,结果还是坑了,进程再一次挂了,尼玛什么鬼? 一、检查日志 根据经验,先看一下crontab的日志: tail /var/log/messages 没发现相关日志,看来不是打印到了这,于是查看了下crontab的默认日志位置: tail /var/log/cron 很明显,任务计划确实在正常执行着,看来问题在脚本上了。 二、检查脚本 ①、直接执行 检查脚本第一步,直接按照crontab里面的命令行,执行脚本: 结果进程正常拉起了! 直接执行成功,而放到crontab就失败,经验告诉我肯定的脚本环境变量有问题了! ②、环境变量 于是在脚本里面载入环境变量: 然后手工把进程杀死,等待自拉起,结果... 还是不行! ③、系统邮件 经验告诉我,crontab执行失败,如果没有屏蔽错误的话,会产生一个系统邮件, 位置在 /var/spool/mail/root 所以,我把crontab里面的 2>&1 这个屏蔽错误先取消掉,等待几分钟查看邮件。 cat /var/spool/mail/root 发现有如下报错: 居然是脚本里面的sudo执行失败了,找不到这个文件。看来单纯的载入 profile 不一定靠谱啊! ③、修复脚本 知道问题所在,解决就简单了,粗暴点,直接写入sudo的绝对路径 /usr/bin/sudo 继续测试自拉起,结果... 还是不行!R了G了!! 三、最终解决 继续查看了下系统邮件,发现如下信息: 很明显,提示了sudo必须需要tty才能执行,解决很简单,取消这个限制即可! 编辑 /etc/sudoers ,找到 Defaults    requiretty, 然后注释掉这行: 最后使用 :x! 或 :wq! 强制保存即可。 结果观察还是报了相同的错误!原来改完这个sudo并不会影响已经运行的crontab,所以需要重启crontab服务刷新下设置: 这下终于可以了! 四、分析总结 Linux系统里面计划任务,crontab 没有如期执行这是运维工作中比较常见的一种故障了,根据经验,大家可以从如下角度分析解决: ①、检查crontab服务是否正常 这个一般通过查看日志来检查,也就是前文提到的 /var/log/cron 或 /var/log/messages,如果里面没有发现执行记录,那么可以重启下这个服务:service crond restart ②、检查脚本的执行权限 一般来说,在crontab中建议使用 sh 或 bash 来执行shell脚本,避免因脚本文件的执行权限丢失导致任务失败。当然,最直接检查就是人工直接复制crontab -l 里面的命令行测试结果。 ③、检查脚本需要用到的变量 和上文一样,通常来说从crontab里面执行的脚本和人工执行的环境变量是不一样的,所以对于一些系统变量,建议写绝对路径,或使用witch动态获取,比如  sudo_bin=$(which sudo) 就能拿到 sudo在当前系统的绝对路径了。 ④、放大招:查看日志 其实,最直接最有效的就是查看执行日志了,结合crontab执行记录,以及crontab执行出错后的系统邮件,一般都能彻底找到失败的原因了!当然,要记住在crontab中如果屏蔽了错误信息,就不会发邮件了。 这又让我想起了如果crontab未屏蔽日志,可能会导致硬盘 inode 爆满 ==> 历史文章传送门 ,感兴趣的童鞋也可以谷歌一下 /var/spool/clientmqueue/ 这个关键词了解下。 好了,本文分享到此,希望对你有所帮助!
阅读全文
操作系统

解决Linux修改密码报PAM authentication failed错误

最近接到一个运维开发任务,需要开发一个帐号管理系统,对手头三千多台Linux服务器的root帐号进行批量系统的管理,实现定期修改root为随机密码并加密存储,并向运维管理WEB前台提供密码查询解密接口等功能。 刚开始,我基于php+ssh2_exec开发了一套雏形。基本功能都实现了,结果老大说这里的运维就我稍微会点php,后面可不好维护。本来也被我说服了,因为写都写好了,难道要重构? 后面线上测试发现,公司有部分系系统接入了ldap鉴权,php的ssh2_exec就无法工作了,返回登陆失败的错误。 不得已,最后苦逼的用python将这个系统重构了一遍,并实现了多线程模式,因为不太会python的cgi框架,就用php搭的api接口,到此为止,基本全部搞定了。 在线上测试了几天后,发现总是有一台服务器要卡半天,登陆校验日志倒是成功的,但总是卡在修改密码那一步。 于是,print一下过程,发现chpasswd改密码这一步报错了!导致expect卡住了。 看了下错误信息是: chpasswd: PAM authentication failed 实际登陆这台机器,执行chpasswd,发现也是报这个错误。 试着执行passwd,也报错了: passwd: pam_start() failed, error 26 搜了半天,也看了半天的洋文案例,都没找到一个贴切的解决办法。最终,我看到有一篇类似的案例,他是通过检查 /var/log/secure 日志文件找到的错误。 于是,我也试着碰碰运气,发现还真有记录! 在 /var/log/secure 中,发现我在执行chpasswd命令是会提示找不到/etc/pam.conf文件。于是到其他系统上去看有没有这个文件,发现也没有的。 最终,我无奈之下,对比了2个系统的/etc目录,让我发现了猫腻!不知道哪个无聊的人把这个系统的/etc/pam.d给重命名为pam.d_bak了!!我去你XXX,浪费我半天时间。 直接 mv pam.d_bak pam.d,然后就能够执行 echo 'root:newpassword'|chpasswd 来修改密码了。 这种奇葩的原因并不多见,所以出了问题不一定能在搜索引擎得到答案。 不过,我写这篇文章的时候,特意把pam.d再一次重命名,chpasswd还是报一样的错,但是passwd报错却变成了: passwd: Permission denied 罗里吧嗦说了半天,主要分享一下这个奇葩的案例和解决过程。当搜索引擎都找不到的时候,那么恭喜你成为了第一个吃螃蟹的人,有了造福互联网的机会,赶紧解决问题再分享吧。。。 目前我开发的帐号管理系统运行良好,后续有时间再整理分享一下,也许有人需要,敬请期待!
阅读全文
WEB应用

PHP7.0正式版编译安装升级及WordPress问题解决分享

盼望以久的PHP 7.0正式版,终于在今天发布了! 官方给出的新特性如下: PHP 7.0.0 comes with new version of the Zend Engine with features such as (incomplete list): Improved performance: PHP 7 is up to twice as fast as PHP 5.6 Consistent 64-bit support Many fatal errors are now Exceptions Removal of old and unsupported SAPIs and extensions The null coalescing operator (??) Combined comparison Operator (<=>) Return Type Declarations Scalar Type Declarations Anonymous Classes 至于新特性是什么,百度一下都有大牛给出很详细的解释,不过我也看不太懂,但是我看懂了一条: Improved performance: PHP 7 is up to twice as fast as PHP 5.6 PHP7的性能将是PHP5.6的2倍! 好了,其他就不用看了,单这一条就已经有升级的动力了吧! 之前就用过RC版本,性能确实提高了很多,但是在PHP7.0环境中,Begin主题存在不少问题,由于不是正式版,我也就懒得花时间去解决了。 今天官方发布了正式版,于是利用下班时间给博客编译安装了PHP7.0,且一并解决了Begin主题依然存在的不兼容问题,下面简单的分享下。 一、编译安装 以下安装步骤是在已有PHP5的环境下进行的,不保证能够顺利完成,仅供参考。 ①、下载PHP 这是PHP官方的PHP7.0正式版的国内CDN下载地址,可以放心下载。 ②、解压编译 基本大家伙都已经安装了PHP的5.6或更老的版本,所以我们可以编译安装到一个新的路径。 上面的编译安装激活了opcache缓存,如果不需要可以去掉 --enable-opcache,个人推荐使用。 ③、设置参数 Ps:以上参数等代码从lnmp一键安装包中提取。 ④、版本替换 php 7 已经安装到了 /usr/local/php7,为了让2个版本暂时都存在,方便过渡,这里我们使用软链接搞定 哦了,做完以上步骤,要是没报错基本就已经搞定了,执行一下php...
阅读全文