1.如何编译打包OpenSSH 9.4并实现批量升级
2.运维基础（10）linux被删数据恢复方法
3.Django实现crontab远程任务管理系统
4.ansible 使用密码登录
5.如何使用Ansible 2的API做python开发
6.自动化运维初级村Paramiko vs Netmiko

如何编译打包OpenSSH 9.4并实现批量升级

       对于如何编译打包OpenSSH 9.4并实现批量升级，码解以下详细操作指南将会提供完整步骤。码解推荐关注公众号后台回复“ssh”，码解以获取相关源码文件。码解

       操作步骤如下：

       首先，码解了解OpenSSH 9.4版本的码解网站办公源码重要更新以及官方发布的相关说明。官网链接请参考openssh.com/releasenote...。码解

       openssh.com/releasenote...链接

       步骤1: 定制编译脚本

        使用开源脚本进行自动化编译，码解以简化OpenSSH源码的码解构建过程。

        Github链接请参考github.com/boypt/openss...。码解请注意，码解对于编译过程中的码解依赖安装，建议使用虚拟机环境以避免与系统环境冲突。码解

        从pullsrc.sh脚本中，码解添加--no-check-certificate参数至wget命令，码解以解决源代码下载时的证书问题。同时，针对CentOS7环境，对el7目录下的SPECS/openssh.spec文件进行修改以确保编译中包含ssh-copy-id命令。

       步骤2: 准备编译环境

        确保所有开发工具和环境（如GCC、make等）已经安装在虚拟机中。对于没有网络的服务器，可以通过外部链接提供源码包并传入download目录。

        使用编译脚本进行自动化编译和打包过程，并检查编译是否成功，以及rpm包是否完整。

       步骤3: 批量升级服务器SSH版本

        利用Ansible自动化工具在多台服务器上执行脚本，以实现批量升级。kernel 串口源码

        第一步，在执行脚本前，确保Ansible服务已安装在用以执行脚本的服务器上。

        解压脚本文件，查看核心文件。脚本会包含一个playbook用于批量管理与配置服务器。

       自定义待升级服务器信息，例如，可以将一组服务器的IP、用户名及密码列表分类存储至不同主机组，适用于相同的登录凭证或用于区分不同登录凭证的多组服务器。

        执行自定义脚本，启动升级过程。随后，通过SSH服务验证OpenSSH是否已成功升级到9.4版本，并检查与服务器的登录是否正常。

       为了提供具体代码和操作流程的指导，建议参考这些链接提供的资源，并确保在执行操作前了解和遵循各自的安全策略与最佳实践，包括权限管理、依赖安装与配置等方面的细节。

运维基础（）linux被删数据恢复方法

       源代码托管网站sourceforge.net提供了一个名为extundelete的工具，用于Linux系统中被删除数据的恢复。extundelete具有多种参数和动作，帮助用户在不同场景下恢复丢失的数据。

       在使用extundelete之前，首先需要安装必要的仿砍柴 源码软件包。通过命令行操作，依次执行#cd /usr/local/src，#yum install gcc-c++，#yum install e2fsprogs-devel e2fsprogs，#wget zy-res.oss-cn-hangzhou.aliyuncs.com，#tar -jxvpf extundelete-0.2.4.tar.bz2，#cd extundelete-0.2.4，#./configure ; make ; make install。这一步确保了extundelete的安装和配置。

       在数据恢复阶段，首先需要确认文件系统挂载情况。以sdb1和sdb2作为示例，分别在mnt1和mnt2目录下存放了文件1.file和2.file。通过#cd /mnt1，执行#rm -rvf 1.file删除文件，然后#cd /#umount /mnt1确保磁盘挂载安全解除，避免数据丢失。执行#extundelete /dev/sdb1 --inode 2命令恢复特定inode编号的文件，确保恢复过程正确无误。

       对于目录恢复，使用#extundelete /dev/sdb1 --restore-directory tmp命令，其中tmp是被删除目录的路径。通过恢复目录结构，用户可以迅速恢复丢失的数据组织。

       extundelete的强大之处在于，它无需依赖特定的文件格式进行恢复。其工作流程包括：首先通过文件系统的4418 android源码inode信息（根目录inode通常为2）获取文件系统的文件信息，包括已存在和已删除文件的详细信息，如文件名和inode；然后利用inode信息结合日志查询文件所在的block位置，包括直接块、间接块等信息；最后，通过dd命令备份这些信息，完成数据恢复。

       为了确保数据恢复的安全性，建议使用umount命令解除磁盘挂载。未解除挂载直接运行恢复命令可能导致数据丢失风险。在恢复操作后，通过#ls /mnt1/1.file命令验证文件恢复成功。

       欢迎关注微信公众号厦门微思网络，获取更多专业IT认证培训信息，包括思科、华为、红帽、ORACLE、VMware、CISP、PMP等课程。通过往期回顾，了解运维基础系列内容，包括Nginx、实用工具篇、备份篇、流量监控工具篇、Ansible、smarty cms源码CI / CD、Ansible Tower、shell脚本以及Linux性能调优三大系统。

Django实现crontab远程任务管理系统

       在之前的文章中，我们已经探讨了如何使用 django-crontab 和 apscheduler 在Django应用内部管理定时任务，这些模块主要用于处理应用自身的任务调度。

       然而，本文将转向一个不同的场景，类似于Java的xxl-job，我们构建了一个系统，能够通过Ansible API，远程管理不同Java项目中Task的定时任务。这个系统是ansible cron模块的可视化界面，允许你便捷地在Django后台添加、修改和删除Linux主机上的crontab任务。

       核心技术实现涉及创建一个crontab模型，并将其集成到Django Admin中。每当模型发生变化时，会触发post_save信号，进而通过celery执行Task。这个Task调用ansible-runner的playbook接口，将crontab命令发送到指定主机。

       模型设计和celery task的ansible-playbook执行是关键部分。在编写Task函数时，我们注意到增加了一个未实际使用的update_time参数，以确保每次更新都会生成新的Task实例。同时，使用mark_safe函数处理crontab命令中的特殊字符，render_to_string用于根据模型数据动态生成playbook模板，os.environ设置ansible的环境变量。

       配置celery和信号处理，包括celery任务注册、异步任务日志独立存放以及信号机制的理解，都构成了技术栈的一部分。同时，我们还讨论了logging配置，以及在Django Admin后台记录操作的问题，特别是关于用户身份识别的挑战。

       源代码已发布在gitee上，dj_cronjobs[6]，并提供了详细的Readme.md指南供读者参考。如果你觉得这个系统有用，请通过我的个人公众号（搜索全栈运维 或者 DailyJobOps）获取更多信息，也可以直接在公众号中找到Django获取当前登录用户的方法[5]。

       相关链接如下：

       [6] dj_cronjobs: gitee.com/colin/dja...

ansible 使用密码登录

        安装ansible

        1.安装sshpass

        apt :

        源码：

        创建一个hosts文件，添加用户密码,认证ssh连接

        2.错误汇总：

        ansible -i hosts test -m ping

        3.原因和解决办法：

        ssh第一次连接的时候一般会提示输入yes 进行确认为将key字符串加入到 ~/.ssh/known_hosts 文件中。而本机的~/.ssh/known_hosts文件中并有fingerprint key串

        解决方法：在ansible.cfg文件中更改下面的参数：

        执行shell 命令

如何使用Ansible 2的API做python开发

       Ansible 和 SaltStack 都提供了 Python 直接调用的API, 这方便了 Pythoner 对这些软件进行二次开发和整合, 此功能着实方便了不少, 比起 Python 代码中调用 shell 也略显专业!

       ç„¶è€Œ Ansible 在2.0版本后重构了大部分的代码逻辑, 启用了2.0版本之前的 Runner 和 Playbook ç±», 使得广大同学之前的代码运行错误. 择日不如撞日, 今天中午对照 官方的文档 , 结合源代码, 对2.0版本之后的 Python API 做了下探究

       Adhoc

       adhoc 其实就是执行 Ansible 模块, 通过 adhoc 我们可以方便快捷的完成一些临时的运维操作.

       2.0 之前的调用

       import ansible.runner

       import json

       runner = ansible.runner.Runner(

        module_name='ping', # 模块名

        module_args='', # 模块参数

        pattern='all', # 目标机器的pattern

        forks=

        )

       datastructure = runner.run()

       data = json.dumps(datastructure,indent=4)

       å½“然这里会去加载默认的 inventory

       å¦‚果不想使用 inventory 文件或者想使用动态的 inventory, 则可以使用 host_list 参数代替

       import ansible.runner

       import json

       runner = ansible.runner.Runner(

        host_list=["..0.1"], # 这里如果明确指定主机需要传递一个列表, 或者指定动态inventory脚本

        module_name='ping', # 模块名

        module_args='', # 模块参数

        extra_vars={ "ansible_ssh_user":"root","ansible_ssh_pass":"xx"},

        forks=

        )

       datastructure = runner.run()

       data = json.dumps(datastructure,indent=4)

       2.0 之后的调用

       import json

       from ansible.parsing.dataloader import DataLoader

       from ansible.vars import VariableManager

       from ansible.inventory import Inventory

       from ansible.playbook.play import Play

       from ansible.executor.task_queue_manager import TaskQueueManager

       from ansible.executor.playbook_executor import PlaybookExecutor

       loader = DataLoader() # 用来加载解析yaml文件或JSON内容,并且支持vault的解密

       variable_manager = VariableManager() # 管理变量的类,包括主机,组,扩展等变量,之前版本是在 inventory 中的

       inventory = Inventory(loader=loader, variable_manager=variable_manager)

       variable_manager.set_inventory(inventory) # 根据 inventory 加载对应变量

       class Options(object):

        '''

        这是一个公共的类,因为ad-hoc和playbook都需要一个options参数

        并且所需要拥有不同的属性,但是大部分属性都可以返回None或False

        因此用这样的一个类来省去初始化大一堆的空值的属性

        '''

        def __init__(self):

        self.connection = "local"

        self.forks = 1

        self.check = False

        def __getattr__(self, name):

        return None

       options = Options()

       def run_adhoc():

        variable_manager.extra_vars={ "ansible_ssh_user":"root" , "ansible_ssh_pass":"xxx"} # 增加外部变量

        # 构建pb, 这里很有意思, 新版本运行ad-hoc或playbook都需要构建这样的pb, 只是最后调用play的类不一样

        # :param name: 任务名,类似playbook中tasks中的name

        # :param hosts: playbook中的hosts

        # :param tasks: playbook中的tasks, 其实这就是playbook的语法, 因为tasks的值是个列表,因此可以写入多个task

        play_source = { "name":"Ansible Ad-Hoc","hosts":"..0.1","gather_facts":"no","tasks":[{ "action":{ "module":"shell","args":"w"}}]}

        play = Play().load(play_source, variable_manager=variable_manager, loader=loader)

        tqm = None

        try:

        tqm = TaskQueueManager(

        inventory=inventory,

        variable_manager=variable_manager,

        loader=loader,

        options=options,

        passwords=None,

        stdout_callback='minimal',

        run_tree=False,

        )

        result = tqm.run(play)

        print result

        finally:

        if tqm is not None:

        tqm.cleanup()

       if __name__ == '__main__':

        run_adhoc()

       Playbook

       playbook 则类似于 SaltStack 中的 state

       2.0 之前的调用

       from ansible import callbacks

       from ansible import utils

       from ansible.playbook import PlayBook

       stats = callbacks.AggregateStats()

       callback = callbacks.PlaybookCallbacks()

       runner_callbacks = callbacks.PlaybookRunnerCallbacks(stats)

       pb = ansible.playbook.PlayBook(

        playbook="tasks.yml",

        stats=stats,

        callbacks=playbook_cb,

        runner_callbacks=runner_cb,

        check=True

       )

       pb.run()

       2.0 之后的调用

       import json

       from ansible.parsing.dataloader import DataLoader

       from ansible.vars import VariableManager

       from ansible.inventory import Inventory

       from ansible.playbook.play import Play

       from ansible.executor.task_queue_manager import TaskQueueManager

       from ansible.executor.playbook_executor import PlaybookExecutor

       loader = DataLoader() # 用来加载解析yaml文件或JSON内容,并且支持vault的解密

       variable_manager = VariableManager() # 管理变量的类,包括主机,组,扩展等变量,之前版本是在 inventory 中的

       inventory = Inventory(loader=loader, variable_manager=variable_manager)

       variable_manager.set_inventory(inventory) # 根据 inventory 加载对应变量

       class Options(object):

        '''

        这是一个公共的类,因为ad-hoc和playbook都需要一个options参数

        并且所需要拥有不同的属性,但是大部分属性都可以返回None或False

        因此用这样的一个类来省去初始化大一堆的空值的属性

        '''

        def __init__(self):

        self.connection = "local"

        self.forks = 1

        self.check = False

        def __getattr__(self, name):

        return None

       options = Options()

       def run_playbook():

        playbooks=['task.yaml'] # 这里是一个列表, 因此可以运行多个playbook

        variable_manager.extra_vars={ "ansible_ssh_user":"root" , "ansible_ssh_pass":"xxx"} # 增加外部变量

        pb = PlaybookExecutor(playbooks=playbooks, inventory=inventory, variable_manager=variable_manager, loader=loader, options=options, passwords=None)

        result = pb.run()

        print result

       if __name__ == '__main__':

        run_playbook()

自动化运维初级村Paramiko vs Netmiko

       秉承着“最小化上手范围”的原则，相信大家经过新手村二十多个章节的学习，都已经对Python有了初步的了解，基础的学习必然是略显枯燥无聊的，但希望大家可以在“新手村”系列视频和文章的指导下有自己阅读程序，分析需求，编写程序，调试程序的基本技能。

       以上也是进入初级村的最低门槛，如果还没有具备上述能力的朋友，衷心的希望你可以返回新手村进行学习，切勿囫囵吞枣，盲目求快。

       初级村包含的内容：Paramiko和Netmiko，两者的使用方式及优劣；Python正则解析，将通过SSH收集回来的各种信息进行正则解析；番外：Text-FSM解析；Python SNMP，如何使用Python调用SNMP采集指令，并讲解OID使用方式；NetConf，如何通过NetConf对网络设备进行操作；Crontab并回调CMDB，如何设置定时执行SSH任务进行定期巡检，并更新回写CMDB；番外：Python Scheduler；Flask Web框架，将SSH和NetConf与Web框架相结合，通过API方式或前端调用其执行。

       在自动化运维领域里面，单从服务器运维的角度来讲，由于可以提前对服务器做系统的定制安装，所以一些大厂会选择在装机时植入特定的Agent，以此实现远程控制服务器的目的。不过对于大部分的公司，服务器运维或者网络设备运维都仍然依靠远程SSH这一方法，所以我们使用Python作为自动化运维的编程语言的话，就非常需要一个第三方包来实现这一功能，而Paramiko和Netmiko可以说是扛把子的角色。相信看这个教程的朋友肯定都听过这两个工具包，但可能并不是所有的人都了解这两个包之间的关系。除此之外，网上五花八门的对于用哪个更好的争论也难以分辨。那么这个章节就先给大家介绍一下这两个包的来龙去脉，以及我个人在工作中对两个包都深度使用过之后的体验。

       OpenSSH，介绍第三方库之前有必要先科普一下关于SSH的知识。我们经常谈论的SSH是一个传输层协议，相比Telnet来说可以与远端设备建立更安全的连接通道，对传输的内容进行加解密处理，所以基于安全考虑，企业中几乎所有的对远程设备的连接都要求使用SSH连接。

       SSH协议有两种不兼容的版本：SSHv1和SSHv2。那么设备想要支持SSH协议，就需要在设备上安装一个与之相匹配的服务端/客户端的应用程序，而OpenSSH就是目前使用最为广泛的SSH协议的开源实现。

       对于较老的SSHv1，由于存在加密算法的专利问题和数据完整性的缺陷，OpenSSH已经删除了对其的支持。所以目前OpenSSH主要支持SSHv2。

       OpenSSH套件包含以下工具：

       整体的结构图如下所示：

       Paramiko/Netmiko简介：Paramiko遵循SSH2协议，支持以加密和认证的方式，进行远程服务器的连接；模块本身使用Python语言编写和开发，只有像crypto这样的核心函数才会用到C语言。

       Paramiko目前是Python中应用最广的SSH模块，大家耳熟能详的Ansible， Netmiko，Nornir，NAPALM其实都是用到了Paramiko来做SSH的实现，所以也可以从中看出，其实Paramiko的角色其实是Python语言里实现SSH功能的底层工具包。

       那么既然是底层工具包就必然为了具备完备的通用性而损失了易用性，而Paramiko过于底层的方法调用也是被网友最为诟病的原因。

       但我们已经提到，Python想要实现SSH远程连接，就逃不开Paramiko，那么我们就非常有必要了解一下Paramiko的基本实现原理和主要的组成类。

       源码核心架构图：Paramiko中几个大的概念和相互之间的关系基本就是如上图所示了（一些身份认证类和其他杂类并没有包含其中，在学习初期也没有深究这些的必要）。

       总体来说Paramiko的源码核心架构并不复杂，但对于使用该包的编程人员来说，暴露了太多底层细节。因为其最High-Level的类就是一个SSHClient对象，而一个SSHClient对象又必须通过创建Channel来完成数据的收发。

       所以说Paramiko其实就是一个实现了SSH功能的底层工具包，它可以连接任何兼容SSHv2的设备，包括：服务器，网络设备，打印机，甚至是监控摄像头，并且它最核心的功能就是：建立SSH连接 -> 发数据 -> 收数据。

       Netmiko：但看本系列的教程的朋友应该大多数都是具备网络运维背景的朋友，想实现一些网络运维中的自动化能力，那么平时所要面对的就都是网络设备，我这里推荐大家使用Netmiko。

       我们可以通过一个流程图来表示一下除了Paramiko本身的底层能力外，还需要哪些步骤才能完成一次与网络设备的交互。

       交互流程图：从上述的流程图中可以看出，除了Paramiko支持的底层SSH连接与数据发送接收功能之外，我们想要与网络设备进行交互还需要诸多地方需要处理，而Netmiko正好可以提供以上这些功能，这也是我们为什么选择用Netmiko的原因。

       其实网上有很多文章都有对Paramiko和Netmiko的对比，但大多数的解释都不够准确，并且还有很多直接通过代码来演示区别的，更是让一些编程基础不太好的朋友十分头疼，所以我希望大家可以通过这一章节，非常清晰的知道，两者之间的区别究竟有哪些。

       这一章节并没有提到关于使用Paramiko或者Netmiko来进行连接设备的代码，但对Paramiko的源码核心架构做了介绍，这也是大家后续使用Netmiko必须要掌握的基础知识，并且对于Netmiko基于Paramiko的改进也通过流程图展示给大家，对后续的深入理解及二次开发会非常有帮助。