日々编译，日々编译，烦たま死，この天天让我编译の世界早晚爆破する，この

今天的节目内容是编译Android-x86，文档给的还是比较全的，主要解决某些不存在的代码的问题。

apt update
apt -y install git gcc curl make repo libxml2-utils flex m4
apt -y install openjdk-8-jdk lib32stdc++6 libelf-dev mtools
apt -y install libssl-dev python-enum34 python-mako syslinux-utils 
apt -y install pkg-config gettext bzip2 unzip bc kmod dosfstools genisoimage

export REPO_URL='https://mirrors.tuna.tsinghua.edu.cn/git/git-repo'

cd
mkdir android-x86
cd android-x86
repo init -u git://git.osdn.net/gitroot/android-x86/manifest -b q-x86
#出现各种报错就换 mirrors.tuna.tsinghua.edu.cn/git/AOSP
find . -type f -name '*.xml' -print0 | xargs -0 sed -i -e 's#android.googlesource.com#mirrors.ustc.edu.cn/aosp#g'
sed -i -e 's#git://git.osdn.net#https://scm.osdn.net#g' .repo/manifests.git/config
find . -type f -name '*.xml' -print0 | xargs -0 sed -i -e 's#clone-depth=".*?"##g'
repo sync --no-tags --no-clone-bundle

# 你们aosp真的不考虑跟着升级一下编译器吗
cd prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.11-4.6
git fetch aosp 2078a6bf9e5479104cfe2cbf54e9602672bd89f7
git checkout 2078a6bf9e5479104cfe2cbf54e9602672bd89f7
cd ../../../../..

source build/envsetup.sh
lunch android_x86_64-userdebug
m -j16 iso_img

编译中会遇到两个问题，一个是依赖项目的-Werror，按照编译器提示加一个[[fallthrough]];然后继续编译就行；第二个参照https://stackoverflow.com/questions/67557000/depmod-is-not-allowed-to-be-used ，修改build/soong/ui/build/paths/config.go，添加"depmod": Allowed,即可。解决这两个问题后应该就能正常完成镜像的生成了。

libvirt是红帽家写的一套虚拟化软件管理工具。

现在市面上有着大量的虚拟化软件，大至ESXi、Proxmox，小如LXC、QEMU，但这些工具提供了各自不同的接口，出现混用的情况将会十分麻烦。俗话说的好，没有什么是计算机工程无法解决的，如果有，那就加一个抽象层。而libvirt则提供了一个统一的接口，允许以相同的格式在不同底层平台上创建对应的虚拟实例，而这也可以说是红帽家OpenStack允许在混合云环境上搭建虚拟化平台的技术支柱之一。

既然libvirt叫做库而不是工具，那么意味着其使用方法更多地是在代码中调用，而非作为一套命令行工具由人工手动操作。然而咱作为普通用户，没有数据中心那个经济实力，一套OpenStack开下来很有可能一半内存就没了（单机内存占用8G起步），因而只能试着用用底层工具来自行创建和使用虚拟机了。

接下来将使用同样是libvirt包提供的virsh及其衍生工具virt-install来创建虚拟机。

首先是安装软件包：

sudo dnf install -y qemu-kvm libvirt virt-install

如果机器配置了图形界面的话，可以安装virt-viewer包，执行virt-install时可以直接给出窗口展示虚拟机的图形界面。由于我这里服务器没配图形界面，后面就都是用的vnc了。

由于virt-install和qemu的命令风格非常相似，因而可以参考我之前介绍qemu的文章，这里直接贴命令行了：

virt-install \
--virt-type=kvm \
--name win10 \
--ram 8192 \
--vcpus=4 \
--os-variant=win10 \
--boot cdrom \
--disk <Windows_ISOFILE>,device=cdrom,bus=sata,readonly=on \
--disk <VirtIO_ISOFILE>,device=cdrom,bus=sata,readonly=on \
--graphics vnc \
--disk path=<PATH_TO_STORE_IMAGE>,size=100,bus=virtio,format=qcow2

接下来是通过vnc远程连接虚拟机图形界面的流程。由于偷懒，这里选择不用安装客户端的novnc：

dnf install -y novnc

默认的vnc端口是5900，我们需要配置novnc连接到该端口，然后再从新端口提供novnc解析后的vnc客户端服务：

novnc_proxy --vnc localhost:5900 --listen 8443

这里选择了8443端口提供novnc服务，在浏览器中输入ip-端口组合即可通过浏览器访问虚拟机的vnc界面了。不过我这挺怪的，novnc的某些资源加载的时候会随机报404，只有反复刷新，等所有资源都被缓存好之后才能正常使用= =

有些人就是喜欢折腾

最近又心血来潮，打算把两年前的坑填上，整了两天，算是把部署OpenStack的坑踩得差不多了。部署方法和之前一样，还是采用的kolla-ansible，主要是neutron_external_interface的文档还是写的比较模糊，加上OpenVirtualSwitch一起，折腾了不少时间。

总结起来，这次折腾的主要结论是，能用，但没必要。由于OpenStack本来就是工业级的设计，开发者原本就是基于企业环境控制网络和外网分离的假设做的实现，因而把两个网络合并势必会受到操作系统等外部组件的设计阻碍，这次的坑基本上都是来自这方面。

首先一开始是打算虚拟一个接口给外网，然后用系统做流量转发给物理网口，但是因为技艺不精，一直失败，只好作罢。后来看到OpenStack的开发文档中提到，由于开发者电脑不一定像工业级服务器一样有两个网口，因而还是允许使用单网口机器部署的。只不过由于ovs要独占外网网口，对外网的访问要从原本的物理网口转移到虚拟网口，导致网络配置丢失，因而必须要使用非远程的方法进行配置（BMC除外）。

大致配置流程如下（假设网卡为eth0）：

1. 按照正常流程配置OpenStack安装，并将network_interface和neutron_external_interface都设置为eth0；
   安装到一半的时候，由于kolla-ansible配置了ovs，导致原有网络配置失效，无法访问外网，表现为某些docker pull失败，说无法连接到quay.io。
2. 此时可以发现eth0被连接到了ovs-system，但是用ovs-vsctl查看，发现eth0又被分配给了br-ex。用nmcli手动进行网络地址的配置：

   nmcli connection modify br-ex connection.autoconnect yes
   nmcli connection modify br-ex ipv4.addresses xxx.xxx.xxx.xxx
   nmcli connection modify br-ex ipv4.gateway xxx.xxx.xxx.xxx
   nmcli connection modify br-ex ipv4.method manual
   nmcli connection modify br-ex ipv4.dns xxx.xxx.xxx.xxx

   其中xxx.xxx.xxx.xxx设置为网卡正常访问外网时的配置即可。需要注意这几条命令的顺序最好不要修改，因为nmcli会做参数检查，如果没设置好某些参数是设置不了另一些的。

3. 执行nmcli device set br-ex managed yes，将br-ex的网络配置交给nmcli执行，此时可以用ping检查网络是否配置完成；
4. 修改kolla-ansible的globals.yml，将network_interface配置为br-ex，因为此时eth0已经无法正常用于访问网络；
5. 重新执行kolla-ansible的deploy指令，等待部署完成即可。

由于nmtui似乎没法快捷方便地管理ovs的网卡配置，因而每次重启后需要手动将br-ex设置为managed模式，才能由NetworkManager进行配置，即手动执行第三步。

接下来如果有新坑的话，就是在Linux上配个子网，然后让OpenStack用本地虚拟子网作为外网了

最近在配服务器端的VSCode，该软件很贴心地提供了以当前用户身份启动服务端的功能，可以有效防止有意无意修改到本应处于隔离范围外的文件。

由于最近洁癖有点严重，想知道这功能是不是在包管理器脚本里硬写出来的，以及添加新用户时他还能否提供相同的便捷性，就简单刨了一下，发现它的service文件名有些特殊，叫做code-server@.service，与他提示用户可以创建的code-server@$USER.service只差一个$USER。

兜兜转转发现这是systemd的一种特殊用法，叫服务模板，而且填充在@后面的可以不仅仅是用户名，可以是任何声明需要的变量类型。由于本人目前还用不到，就暂时先码在这里，贴一个文档链接：https://www.freedesktop.org/software/systemd/man/systemd.service.html#Service%20Templates

好耶，是红帽系的openEuler

dnf groupinstall -y "Development Tools"

# 下载源代码
git clone https://github.com/ceph/ceph
cd ceph
git checkout quincy-release
git submodule update --init --recursive

# 编译前准备
# openEuler 22.03的源里没有这两个python包，需要改为手动下载
sed -i -E 's/(.*asyncssh$)/#\1/gm' ceph.spec.in
sed -i -E 's/(.*natsort$)/#\1/gm' ceph.spec.in

# 官方还没有加openEuler的选项，但大概率是兼容的
sed -i -e 's/centos|fedora/centos|openEuler|fedora/g' install-deps.sh

./install-deps.sh

# 装完依赖之后再装dnf里没有的两个包
pip3 install asyncssh natsort

dnf install -y xmlsec1 doxygen ninja-build python3-sphinx
dnf install -y libibverbs-devel openldap-devel lz4-devel expat-devel lttng-ust-devel libbabeltrace-devel libatomic librabbitmq-devel librdkafka-devel java-1.8.0-openjdk-devel

# cmake配置
./do_cmake.sh -DCMAKE_BUILD_TYPE=RelWithDebInfo

# 开始编译
ninja

打RPM包的过程有点曲折，openEuler的维护者不知道在干些什么，去维护ceph.spec而不是ceph.spec.in，搞得我不知道版本更新的时候到底该对着谁的spec改了。。

这里就不理openEuler自己公布的spec文件了，用点取巧的方法，伪装成CentOS试试。

# 制作RPM源码包
./make_srpm.sh

# 展开RPM源码包用于安装
# 注意默认是解压到家目录下的，所以在ceph目录下执行完可能发现没任何变化，回家目录检查下肯定有rpmbuild文件夹了
rpm -i ceph-17.2.5-0.g98318ae89f1.src.rpm

# 安装编译依赖
dnf builddep -y --define 'rhel 7' --spec ~/rpmbuild/SPECS/ceph.spec

# 华子的像素级抄袭功底还是在的，包管理器名字都给你改喽
# 说实话还整个大小写混用让人挺不舒服的。。
sed -i -e 's/^BuildRequires:  redhat-rpm-config$/BuildRequires:  (redhat-rpm-config or openEuler-rpm-config)/gm' ~/rpmbuild/SPECS/ceph.spec
sed -i -E 'N;s/(^%if 0%\{\?rhel} == 8$)(\n%py_byte_compile.*)/\1 || 0%{?openEuler}\2/gm' ~/rpmbuild/SPECS/ceph.spec

# RPM编译
# openEuler上的cmake可执行文件是python脚本，然而很怪，一用rpmbuild，python就会掉PYTHONPATH，找不到cmake
# 伪装成rhel7，走centos的编译流程，但是又绕过软件包版本限制
PYTHONPATH=/usr/local/lib64/python3.9/site-packages rpmbuild -ba ~/rpmbuild/SPECS/ceph.spec --define 'rhel 7'

将编译的ceph RPM包作为repo提供给其他机器使用，参考：https://blog.csdn.net/DeamonXiao/article/details/120879577

dnf install -y createrepo
cd ~/rpmbuild/RPMS
createrepo .

然后另外单独起个后台进程，直接用http提供服务；这里用7000端口，根据需要可以自己调。

python3 -m http.server 7000

至此，一个repo就建立好了。

然后配置服务器使用这个源：

cat << EOF > /etc/yum.repos.d/Ceph-dev.repo
[ceph-dev]
name=Ceph Dev
baseurl=http://<ip-address>:7000/
enabled=1
gpgcheck=0
EOF

# 更新缓存，测试源是否添加成功
dnf makecache