将pebuilder变成dibuilder.sh,将di tools集入boot层(4):打包pve debs,利用pve代替pd打造你的bearmetal多os系统并集入boot

本文关键字:sed 部分替换,debootstrap多源处理,merge multiple deb source into 1

在《将pebuilder变成dibuilder.sh,将di tools集入boot层(2):发明minstack live os》中,我们讲到了针对单个deb repo路径进行debootstrap打包差异化部分,产生宏deb的的操作,在那文中,其本质是“利用dpkg -e加后配置脚本代替apt,使apt动态配置包变成静态包+后配置脚本”,为了这种极致化目的,我们甚至用ar代替dpkg -e,甚至都不用到dpkg -i,这一切都是为了让deb包的处理变得足够portable:

这里有二个处理,1,借助工具,从网上的debian源出发,在本地建立一个部分源,2,借助dibuilder.sh,将这些源重新remastering形成新发行版。
这些处理最终遗留了二个大问题,1,我们的操作是针对单个deb repo进行的,而现实(apt)的情况是,一个系统往往是针对多个仓库(/etc/apt/sources.list/sources.d)条目进行的update/install,debootstrape只允许你指定一个,2,我们没有解决依赖问题。(3,也许还要算上3,我们的后配置脚本是排除了control/preinstall脚本的,这个应该无法避免,除非我们保留源差异化deb包,而且这种包并不能dpkg -i安装,因为它不能像升级包一样去掩盖(类似mount -o)同位置下的文件,会提示之前的包已经将文件放到那个位置了。)4,上文中,我们采用netiso作为基包测试debootstrap,但实际上我们应该用tdl-initramfs作为基包。而不是一个iso。不过,使用iso的结果也是正确的。但我们是以tdl-initramfs作为基础remastering发行的,所以最好用后者。

废话不多说。下面讲述整理一个pve-initramfs所需的debs,得到其基础包的过程(至于后配置和解决依赖的部分,以后有机会再强化吧),开始!

1,得到pve debs

上文求得xorg基础包用的是debootstrape,debootstrap要求一个单一的mirror url,而我们现在面临多源多库的情形:

我们把single suite/codename/release->compent->arch的路径叫做一个源,这就是debootstrape最后那个参数指定的mirror url,形如:

Suite: oldoldstable
Version: 8.11
Codename: jessie    我们把它称为源
Date: Sat, 06 Jul 2019 09:36:16 UTC
Architectures: amd64 armel armhf i386
Components: main contrib non-free    我们把它称为库

一般,一个debian镜像点会维护三个连续的版本,一个是oldoldstable,一个是oldstable,一个是stable,由于debian进化到了10,那个oldoldstable就是jessie8,jessie只是oldoldstable的链接。
而一个正常的debian版,不光是http://mirrors.xxx.com/debian/ jessie main这里的内容,还有http://mirrors.xxx.com/debian-security/ jessie/updates main这里的内容,比如,按aliyun它的镜像添加教程,应该是这二条:

deb http://mirrors.aliyun.com/debian/ jessie main
deb http://mirrors.aliyun.com/debian-security/ jessie/updates main

(代表一个源库的就是源release中指定的各个库的packages/packages.gz/packages.bz2文件,你/etc/apt/sources.list写好源库配置,sudo apt-get update后,packages中的软件条目会写入/var/lib/apt/lists,下面实践一下,
首先将上面二条源库配置写入。然后:
sudo rm -rf /var/lib/apt/lists/*
sudo rm -rf /var/lib/apt/lists/partial/*
上面命令为了解决可能出现的waitting headers,也是为了清空上次的安装信息源库数据库。
再sudo apt-get update;sudo apt list | wc -l,在一个纯粹的debian netinstall iso安装出的系统中,会得出42000多条软件包记录,包括系统已安装,待安装等,即使/var/lib/apt/lists没任何内容,sudo apt list也是能显示已安装的包的[installed,local])

而我们要的效果是,在这个netinstall iso中安装出的本地虚拟机系统中,我们需要维护一个由mirrors.aliyun.com产生的本地子源,以使得我们能利用/etc/apt/sources.list中单条deb http://10.211.55.2:8000/downloads/mirrors/debian jessie main main-security-updates pve-no-subscription,就足以能支持安装完sudo apt install --no-install-recommends proxmox-ve(main-security-updates实际上就是release文件中把debian-security/ jessie/updates main作为debian的子库整合进来之后的效果,而proxmox-ve,是http://download.proxmox.com/debian/pve/dists/jessie/整合进来的子库效果)。

这个操作的背后逻辑是:http://10.211.55.2:8000/downloads/mirrors/debian jessie main main-security-updates pve-no-subscription,这三个源main main-security-updates pve-no-subscription整合进来之后,对应的packages是要保证其正确性的,否则apt-update之后,它不会提示你安装,而仅会提示你说“deps unmet,依赖未达到”,意思就是说你提供的源是不健全的是坏的,而在配合以前的dibuilder.sh脚本中,为了能使文件名中包含+,~的deb包名能做在onedrive中被hosting,我们修改和定制了release文件和packages/paackages.gz文件,由于这些文件的修改当初仅预设作为配合dibuilder.sh中简单的remastering,所以并没有太多考虑(比如它所在的源其实不支持apt-get,也不好用于debootstrape),里面经过修过的文件当然不能放在/etc/apt/sources.list中用(自然会导致deps unmet),而我们现在想使之正确用于debootstrape和apt-get,放在sources.list中使用(支持sudo apt install --no-install-recommends proxmox-ve)。

所以我们要重新提供正确的packages版本,直接从http://mirrors.aliyun.com/debian/dists/jessie/main/binary-amd64/Packages.gz https://mirrors.aliyun.com/debian-security/dists/jessie/updates/main/binary-amd64/Packages.gz http://download.proxmox.com/debian/pve/dists/jessie/pve-no-subscription/binary-amd64/Packages.gz下载截止目前最新的pakcages再经过如下处理即可(暂时不需要一开始就涉及到下载debs):

我们一步一步来:

(我们之前在dibuilder.sh是严格按官方路径存放debs的,现在我们统一将debs放到dists下下级的目录中:这样更合理,因为我们是求得一个定制源的子库------ 基于此,我们来修改获得packages)

cat Packages | sed -e 's/Filename: .*//Filename: /g' > NewPackages (首先把路径去掉)

然后把三个packages中的路径都修改为各自的dists/jessie/main/binary-amd64/deb/下,dists/jessie/main-security-updates/binary-amd64/deb/下,和dists/jessie/pve-no-subscription/binary-amd64/deb/下,这个/deb/的上级也可以放各自dists的vmlinuz,cdl-initramfs,tdi-initramfs,grub files等等,------ 将索引逻辑仅保留在packages中单独编辑,deb文件全部无层次,这样维护方便。由于我们的发行版是部分拉取总库形成的,这样文件夹中不会有大量文件其实也合理。dibuilder.sh对应下载数组/下载/解压逻辑处要改一下

然后,cat Packages | sed 's/(Filename: .)+(..deb)/\1-\2/' | sed 's/(Filename: .)+(..deb)/\1-\2/' | sed 's/(Filename: .)~(..deb)/\1-\2/' > NewPackages (第一次替换+号后,还有少许+号残留,最后一次替换~,你其实可以在上面输出为NewPackages前 | grep "Filename: " 查看验证结果)

然后在本地wc -c Packages,md5sum,sha1sum,sha256sum Packages,用得出的结果修改Releases

这样packages就修改完成了,用deb http://10.211.55.2:8000/downloads/mirrors/debian jessie main main-security-updates pve-no-subscription写的sources.list在sudo apt install --no-install-recommends proxmox-ve时能出现正确的提示而不是deps unmet了。

然后是得到main-security-updates与pve-no-subscription的debs,main的我们在前面已经通过debootstrape得到过了。把源库配置恢复为aliyun.com的二条,pve的用deb http://download.proxmox.com/debian/pve jessie pve-no-subscription

sudo rm -rf /var/cache/apt/archives/*
sudo apt install -y --download-only --force-yes --no-install-recommends proxmox-ve > 2.txt (由于这是多源结构不可能用debootstrap之类的工具,这条拿掉2.txt,会提示2个升级,161个新装,共163个包要下载到/var/cache/apt/archives中去)

提取debs:

(main的新加部分90个)mkdir main-deb;cat 2.txt |  grep http://10.211.55.2:8000 | awk '{print $4,$6,$5}'| sed -e 's/ /_/g' | sed -e 's/:/%3a/g' |while read line; do sudo cp -f /var/cache/apt/archives/$line.deb main-deb; done
(security的部分35个)mkdir sec-deb;cat 2.txt |  grep http://mirrors.aliyun.com/debian-security ....
(pve的部分38个)mkdir pve-deb;cat 2.txt |  grep http://download.proxmox.com/debian ....

实际测试用deb http://10.211.55.2:8000/downloads/mirrors/debian jessie main main-security-updates pve-no-subscription安装sudo apt install --no-install-recommends proxmox-ve。

首先是修改/etc/hosts,只需要修改或加入一条,本地公网IP 对应主机名,之后hostname --ip-adress能得到那个公网IP就行了,这步是必要的,否则会在安装配置处出错。提示E: Sub-process /usr/bin/dpkg returned an error code (1),网上安装pve的教程的其它部分可以忽略。

重新启动,pve 在 grub advanced 4.4.134-1,也是默认的第一条,但是点开用advance原来的3.0.16也可以,所以我们完全可以从90m的pve-deb结果中排除二个大deb,得到约20m的pve结果。

2,得到pve的意义:代替虚拟boot作暂代方案。用pve/lxc代替openfaas/container

第一部分实际上就是利用pve实质上就是一些debian包的本质来完成的:

Proxmox VE ships as a set of Debian packages, so you can install it on top of a standard Debian installation. After configuring the repositories Section 3.1, you need to run: apt-get update apt-get install proxmox-ve,及https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Stretch这样的教程。

这个好处较exsi这种从内核开始封闭生产的系统大了去了:它可以用于作为我的暂代方案。

其实这个想法很久了,最初是为了实现parallels boot+oslevelvm app level vm in 1+guestos=all in the boot,后来它发展我的整个方案:一个企图将统一语言统一平台统一开发组成的最小开发栈实现做入boot的方案,这种子系统,虚拟机,app容器合一的架构特性保证了虚拟到各os的app共享同样级别的virutal appliance基础(甚至硬件统一)
在实践中,想用virtual boot firmware+libos做,发现难度较高,业界对此方案的支持处在早期,故现在转为基于linux普通方式做。在《一个统一的parallel bootloader efi设想:免PE,同时引导多个系统》和《一种虚拟boot作通用bootloader及一种通用qemu os的设想》开始一直是这种思路的尝试。在群晖等bearmetal上折腾过,甚至想买个裸金属云服务器折腾。
故目前的实现仅是采用某些方案的一个暂代,仅介绍在云主机上安装pve和各种常见和专用qemu的unix系云OS

更多考虑:

pve更像是一个debian dists。而不是一个deb bundle。当然它也可以做成xorg的宏deb包。不过这不是我的方向,make tdl-initrd-pve才是。所以只要在仓库中维护可remastering to dists的包就好了,不要宏包化加静态加后配置(这个仅适合cdi集成,其实这个是为了cdi考虑的,并不一开始考虑用在xorg包宏化上面),
为什么不使用Qubes os。。因为它是基于xen过时的。而pve同时有OS级虚拟(kvm)和OS内APP虚拟(lxc)
而且lxc container template完全可以用packer或debootstrap生成。免去用docker-cli这样的东西生成。甚至可以将minstackos装在云端,生成sket脚手架镜像用。
为什么选择4而不是更高版?
虽然Support for Proxmox VE 4.4 ends on June 30, 2018,但我们为了与以前兼容还是用jessie pve
另,pve 4的刚好没有lvm。thin lvm有个好听的名字叫精简置备,比qcow2这种更有优势,但local storage更适合调试和初级使用。


无论如何,我们安装了pve,就实现了用云主机支持快照的方式使用本地osle,在不支持再虚拟化的云主机上,lxc式的容器更容易instant commit,甚至未来我们将其单盘化装在mbp的分区中,裸金属方向使用mbp搭建pve云(附带解决mbp下无线网卡不可用,开机亮度过高这些debian在mbp上的安装使用问题)。

上一篇:FreeRTOS与uCOS II的比较


下一篇:UCOS-Ⅲ:信号量