0
点赞
收藏
分享

微信扫一扫

常见的操作系统自动应答安装方法

unadlib 03-11 21:45 阅读 2

前言

大规模商用场景一般不涉及自行部署操作系统的流程,一般都由供应商提供标准的规范化部署满足订单需求,但是自行更换操作系统仍然是必要的操作。绑定硬件销售的设备一般没有部署的流程,出现需要重置系统的过程一般类似手机这种移动终端,采取镜像更新的方式。


Windows

Windows部署过程中的自动应答流程一般是unattended.xml。能够实现自动接受使用条款,磁盘分区,设置系统密钥、用户名密码计算机名、语言地区。如果有需要的话,还可以添加额外的用户,系统自动登录、网络类型。这些都是文件原生能够提供的功能。使用这个文件能够跳过oobe,让系统自动完成初次设定。

文件更新较少,虽然不同的系统无法通用,但是主要格式上大同小异,不同的版本也没有功能差异。从Windows vista/Server 2008到最新的Windows11结构上都是差不多的。没有太多高级的东西,运维重复学习的成本不高,上手非常快。如果本身对Windows理解比较透彻的玩家,初次接除的话一个下午就能玩出花了,后续就没什么更新奇的东西基本上满足常见要求了。至于不常见的搞不定的需求,这也基本上扩展不出来。

正常的unattend文件自动应答方法在国内不怎么常见,更别提以全Windows实现的网络启动然后自动部署安装。更常见的是各种镜像克隆方案。比如已经被放弃了的年久失修的GHOST,也有专业一些的用上了网络版本。这些系统在释放后本身就是已经能正常运行的系统。打包镜像的过程中设定oobe状态或者其他方式,让系统在第一次运行时初始化唯一信息比如计算机名、计算机ID,以及安装驱动,在第一次进入桌面后删除不需要的驱动包,安装软件之类的动作。

如果都是配置及角色相同的计算机,例如学校的电脑,除了用ghost通过网络广播分发,也有比如联想品牌机专属的同传系统。

至于品牌机到手本身就有系统是怎么部署的?都有可能,有可能是unattend部署。厂商也可能会提供自动应答的对当前系列定制调整的光盘或者恢复镜像。也可以会以镜像覆盖方式,正经的厂商的产品都是会有oobe过程的,让最终消费者在第一次开机的时候设置自己的用户名密码以及连接网络。参观过大厂原厂设备厂商为客户部署系统的过程,与我们在机房为服务器安装系统差别并不是很大。

离谱的呢?比如某些电商整机商。为什么电脑到手就是Admin用户直接进入桌面?

网上有一种称为“硬盘拷贝机”的东西。这些整机商要么不懂,要么就是偷懒。首先装好一台,然后随便下一个来路不明的gho版本在这台机器安装完毕,然后关机将硬盘作为母盘直接复制给各种SATA接口的固态,或者M.2接口的固态,甚至不论设备时什么配置都是从同一个母盘复制的。

会发生什么呢?对小白用户来说很好啊,开机就可以用了。但是因为唯一id是完全相同的,曾经有一款风靡全球的游戏,因为系统安装id关联,然后这个商家卖出的电脑全部被关联了,所有用同一个母盘克隆出的系统没有经过oobe都是完全相同的id。可能是一个,也可能是多个玩家作弊吧,游戏厂商封禁了全部同id的系统登录的游戏账号,以及关联了主板网卡的mac地址。其实他们可以先gho覆盖到一个硬盘,然后直接以这个硬盘作为母盘开始克隆,但是第一次开机流程太多,“小白会给差评”。

非常喜闻乐见的是,我就有个朋友买的这样的整机而且懒得重装系统被一起封号。我完全能确定那朋友有能力自己重装安全的原版系统甚至去微软官网购买正版系统,也确定他不会拿他大号开玩笑。


RedHat系

不论是已经停止维护好些年的RH6系,还是最新的版本,也类似Windows,是比较稳定的,都选用kickstart实现自动应答无人值守安装。

Linux有一个地方与Windows稍有不同,语言与地区上,Windows选定了国家就指定了默认键盘之类的信息,而Linux一般再各自的GUI\TUI安装页面上选择了国家能够自动选定特定的键盘、时区之类的信息,但是kickstart文件的编写还是比较自有的。

可以直接指定root用户密码,以及新增的用户,设定网络、防火墙以及常用服务的状态,能进行磁盘分区、选择安装部署的软件,在这个程度上比Windows更为自由。

普通原版Windows镜像的安装过程是将wim文件释放到硬盘,类似解压压缩文件到硬盘的流程。使用unattended.xml能够自动进行的功能与手动部署的流程进行的设定基本上差不多,不考虑磁盘分区的差别,在第一次重启前,不同的计算机在系统盘部署的文件都是相同的。

Windows是镜像解压到硬盘的过程,而Linux一般是安装的过程。kickstart能够决定需要安装的软件,在这个过程中由于是安装,所以不同的平台在第一次重启前就已经有不同的软件包了。Windows在第一次重启后有一个漫长的等待过程,不同的硬件会启用不同的驱动,而Linux在部署过程中,常见的RH系deb系在驱动上可能一视同仁哪怕是虚拟机也会同时安装各种无线网卡的开源驱动,而不同的虚拟化平台会让系统同时安装对应的开源虚拟化监控程序,例如kvm架构会安装qemu-guest-agent。

红帽系统衍生了一大对相关的二进制兼容的系统,在方法上也都是一致的。比如CentOS、rocky Linux、alma以及oracle linux还有国内外云计算厂商贴了自己名字的各种。

不同大版本的系统格式上主要是功能上的差异。后续的版本会有更多的定义选择而老版本没有,系统之间差异不大,红帽官方系统有eula和授权相关的配置项,对其他的系统是不需要的。只要掌握了一个系统的,其他相关的延伸都是大同小异,而同一个大版本可能能够直接通用,例如为CentOS 7 编辑的配置文件,照样能够正常的部署openeuler。

系统部署的过程是安装的过程。格式化,部署软件包的方式释放文件,然后安装引导。如果有需要的话可以指定安装前和安装后自动执行的任务。在比较新的红帽版本上,我们除了可以根据已经记录的MAC地址的方式根据IP返回不同的ks文件,也可以让安装程序在请求ks文件的过程中直接附带上机器的MAC信息。所以可以把玩的项目是相当多的。

通过已经部署完的系统/root目录下当前的安装配置文件作为基础模板修改设定,入门上手也是非常快的,能玩的地方相当多,也可以实现更多复杂的功能。kickstart自动应答文件本身无视后缀名,更别提文件名了,指定的文件能够访问到就行,不管是以卷名查找本地文件,还是网络访问一个php后缀的http路径。如果机器时间准确,无盘或者本地引导的内核比较新,https方式也是可以的。


deb系

deb系首先将Ubuntu先排除在外。大部分的还是preseed.cfg。同RH系,文件名后缀都无所谓。而Ubuntu的自动应答这10年来变化了好几次,不同的大版本都是不同的方法,也用过preseed.cfg的方式。

deb系的自动应答文件preseed.cfg可以参考debian官方的文档得到一个初始的版本。在功能上也相当齐全。虽然每个大版本都有各自的文件,但是官方文档没有详细的列举所有可能的选项。kickstart部署方式如果愿意的话对着红帽的或者其他版本的文档一条条看下来,文档里没有的功能当前版本肯定没有,新的版本多出的功能和砍掉的功能文档都写的非常详细。preseed.cfg可以参考示例文件种注释部分的描述进行修改,可能有的功能没有用,也可能你从其他地方找来的选项插入之后也有作用。

debian本身指定镜像站在这个文件中指定了镜像源的域名以及路径就可以了。而其他的一些系统可能使用debian的安装源,但是具有发行版自身的源,例如基于debian的armbian再延伸的某系统,preseed.cfg能够处理sources.list文件,但是它还有armbian.list默认指向默认源,需要自行额外编写脚本处理。说到这里,红帽系的kickstart指定的安装源不影响部署的yum repo,完全需要自己编写安装后脚本处理。


其他Linux

kickstart preseed方式自动应答部署对应的Linux发行版都是很方便的,如果基本设置齐全,就不需要人工介入。而缺乏或者安装的时候存在异常比如无法找到安装路径就需要人工处理了。kickstart有详细明确的资料,preseed也能找到丰富的案例,总体上还是比较费时间的,而其他一些Linux发行版也有一些独创性的自动部署方式。

例如知名的国产Linux deepin,它使用ini配置文件,相当简单易懂。以install_disk = /dev/nvme0n1 类似的方式很简单的就能够修改计算机名、时区、语言、安装位置、密码及创建用户,需要批量部署的运维可能只需要几十秒就能够将文件修改成自己期望的样子进行分发部署。


树莓派以及各种arm Linux开发板

常见的一些SBC,往往采用TF卡或者emmc引导。一般厂商提供的系统或者三方的例如armbian、dietpi之类的都是将固定的镜像解压释放在整个内存卡。当第一次运行的时候,系统自动运行初次运行脚本,扩展分区到存储器的大小。如果开发板有自带SPI芯片,还可以将引导安装在SPI芯片,从USB或者m.2之类的接口启动系统。以dietpi、raspberry pi os为例,这些系统的镜像写到T卡之后,一般还有个独立的FAT32格式的分区,可以修改里面的txt文件实现在初次运行的时候执行类似的设定,例如直接修改密码,连接指定的WLAN,开启蓝牙,开启热点访问,或者设置静态IP或是将DHCP获得的IP作为静态IP保存。

这些开发板也不是不能网络启动,我也把玩过无盘或者网络部署,一般需要有uboot已经部署在设备本身的SPI或者emmc之类的可启动设备才能继续。如果没有这些,人工通过串口加载网络也是可以的,这就是一些路由器之类的“焊死”了“系统盘”的设备最终“救砖”解决方案。


虚拟化

虚拟化平台在虚拟机的操作系统部署上,可以直接使用特定的镜像运行,类似各种开发板那样。有虚拟化平台部署的虚拟机默认是没有操作系统的,需要指定iso然后类似物理计算机的系统部署流程,而大部分都是指定一个镜像。对于常见的商用虚拟化管理平台,基本上都是系统镜像里面有程序,自动从模拟的光驱取得配置信息进行更新。

虚拟化管理平台与系统的部署有一定关系,但是使用的虚拟化技术本身提供了更有效的接口。kvm虚拟化就可以添加cloud-init专用的驱动器,用于为虚拟机配置IP、计算机名、密码之类的需要修改的信息。也有一些虚拟化管理平台会为虚拟机添加串口。虚拟化平台一般是没有部署操作系统的,镜像在每次运行时启动特定的软件读取特定的位置。cloud-init方案算是一个规范,也不限于kvm虚拟化。在原理上,与各大厂商自行实现的运行软件控制相似,都是读模拟光盘包含的配置。

无需重启修改密码,在页面上正常关闭云服务器,都是内置的服务程序的功劳。如果删除了程序,可能在页面上关机就要等待很久直到超时强制关闭。也有一些云厂商在关机的逻辑上用的是ACPI的方案,即使删除了厂商程序,页面上也是能正常安全关机的。

在云计算领域,物理服务器也有网络引导的。比如有些裸金属服务器系统盘也运行在存储服务器的镜像文件中与云服务器无异,这类系统的部署与云服务器是一样的。


举报

相关推荐

0 条评论