Fedora koji构建系统详细教程之一 -- 部署

经过一段时间对Fedora koji的学习和部署，我做出了一些总结和疑难问题的解决方案，在koji系统部署的过程中会踩很多坑，需要我们一步步去解决。这篇文章会提供部署koji的每一个步骤，并且尽可能详细地把这么做的理由给讲出来，部署好koji系统并且使用koji构建出rpm包。Fedora koji在部署和使用过程中遇到的概念是比较多的，我会理论结合实践，这样会让你看得更加清楚。本文尽可能会写得通俗易懂，因为现有资料确实很难啃，大多都是提供一种思路，对于初学者而言最好是手把手教，给出可以复制的代码、可复刻的模板，用比较快的速度尽可能完成一个简单koji系统的部署。这篇文章主要是以构建RISC-V的rpm包为主。在这一整个的过程中，基本上是不需要自己去写代码，只要做一个configer,根据实际情况在模板的基础上对配置文件进行调节和修改就好，不需要进行大的改动。这篇文章写得比较啰嗦，你可能看了大半天才有一点点成果，不过你可以反复看几遍，基本上就永远不需要再看本文了（确信）。真是希望把我的研究一股脑全写出来，只是这可能得慢慢来。

我把一些关于koji系统的资料放在这里，本文的理论部分都来自于这些资料：

这是第二篇文章的地址

本文会从上述信息中总结出来，并且给出一条初学者容易理解并上手的koji学习路径，你跟着我一步一步做就好。本文中的脚本代码来自于上述文档以及来自iscas的大佬。当你已经学习一定的koji知识的时候最好把中文文档和英文文档给看掉，这样才能融会贯通。（中文文档里目前来说可能是有些地方是有误的，我会提交一个pr去尝试修复它）。在中文文档里的每一篇开头都会有一幅图，不过初学者看了可能会困惑，等到实际成熟我再来解释它们。

上面这幅图就是Fedora的koji页面，也就是后面会提到的kojiweb,这里面就展示了rpm包构建的一些信息。

在我写这篇文章的时候，Fedora koji系统正在构建flatpak的kde runtime.

除了Fedora官方之外，iscas也部署了自己的koji构建系统（Build System Info | ISCAS openkoji system），就是上面的这幅图，这二者的界面略有差异。

不过大家也不用太羡慕，很快我们就可以在自己的机器上部署koji，就能够看到类似的界面了。

本系列文章对koji的研究主要围绕着Fedora koji和openkoji这两个已经部署koji的系统。但实际上还有很多发行版也是自建了koji，大家有兴趣可以自己去了解一下，甚至是加入发行版对应包管理的maintainer也都是可以的，只是这不是本篇文章的重点。

Rocky linux koji

CentOS Stream koji

一、koji简介

大家可能对koji这个词很陌生，我简单讲讲它的含义，激发一下读者的阅读兴趣。

koji的中文意思是"麹"，又称为“曲”，你理解成酒曲就好了，用来酿酒、酿醋的一种菌。koji似乎与日本文化比较有缘，后面还会提到它。

在这里koji指的是Fedora koji，是Fedora以及众多rpm系Linux发行版（比如CentOS、rhel、RockyLinux）的包构建和管理系统。koji提供一个集中式的rpm软件包管构建环境，允许开发者和维护者在受控的环境中构建和测试软件包，并将软件包发布到公共或者内部仓库中。是Fedora等操作系统的核心部件之一。除了koji之外，其实还有obs这些也是分布式的高级构建系统，不过这个我研究的就比较少了。

koji的发展历史与Fedora project紧密相连，Koji 的开发始于 2005 年左右，最初由 Red Hat 工程师 Mike McLean 开发。Koji 的名字源于日语中的“酿酒”，与它管理和“酿造”软件包的功能相契合。

在 2003 年，Fedora 项目由 Red Hat 创建，作为一个开源社区驱动的操作系统。随着 Fedora 项目的发展，社区需要一个强大且灵活的构建系统来管理其软件包的构建和发布流程。Koji 应运而生，作为继承于 Brew（Red Hat 内部使用的构建系统）的工具，用于更好地支持开源项目的需求。

Koji 旨在解决多个平台和架构的 RPM 包构建问题，并提供构建任务的全面管理功能。它支持分布式构建、多架构构建、任务调度、访问控制等功能，满足了 Fedora 项目日益增长的需求。

总之就是Fedora项目组高瞻远瞩，在比较早以前就开始着手构建系统的研究，这对于一个发行版而言非常重要。

Fedora koji中的几个重要部件

1、koji-hub

它是所有 Koji 操作的核心，是一个运行于 Apache 的 mod_wsgi 模块下XML-RPC 服务。koji-hub 仅 以被动方式 接受 XML-RPC 请求，依赖编译守护模块(kojid)和其他模块来发起交互。koji-hub是唯一能直接访问数据库的模块，而且是对文件系统有写权限的两个模块之一(另外一个是koji)。

2、kojid

编译守护模块，运行在每一个执行编译任务的机器上。其主要是负责对编译请求进行轮询并作相应处理。Koji除了编译外也支持其他任务，如创建安装镜像(Image)。kojid同样也可以完成这样的任务。

kojid使用mock来编译。它为每次编译任务创建一个干净的编译环境（buildroot）。kojid是python实现的，通过 XML-RPC 与 koji-hub 通信。

3、koji-web

它是一套运行在 mod_wsgi 下的脚本，使用 Cheetah 模板引擎为 Koji 提供一个 Web 接口。koji-web 不仅可显示许多信息，还可提供一些特定操作，如取消编译任务。

4、koji

它是一个用 python 实现的命令行程序，提供了许多操作Koji的方法（hooks）。它能让用户查询许多信息，也能执行许多操作，如发起编译任务。部署好之后，我们大多数时间都是在和这个命令打交道。

5、kojira

它是一个守护程序，可保证编译环境（build root）使用的仓库数据的不断更新，你可以把它看成是“仓库管理员”。

6、mock

它是一个虚拟环境管理器，构建系统使用mock来创建一个干净的构建环境，然后在这个干净的环境进行构建，具有类似chroot的功能。

上述信息是我从文档里摘录来的，大家看了可能会比较困惑，最好是亲眼见证，这样才会比较清晰，我会在后面一个一个讲述和演示它们的作用。除了这几个组件之外，koji作为一个rpm包的管理系统，它具有关于Linux发行版包如何发行的重要概念，这几个概念更难理解了，你得跟着我做一遍，然后还得多实践一下。

二、koji初体验

Fedora koji最好在一台Fedora设备上部署，这样不会出现缺包的问题，你可以在一台Fedora物理机上面部署，不过由于我现在使用Gentoo了，在Gentoo部署koji不太合适，所以就开一台Fedora虚拟机来跑。无论是物理机还是虚拟机，我都推荐你使用带有图形界面的Fedora，因为你需要在本机上查看kojiweb。

如果你使用Linux，那么你至少需要qemu-system-x86_64和virt-manager(或者gnome-box).这样才能比较方便地管理虚拟机和得到比较好的桌面体验。如果你用的是Windows,那么vmware,virtualbox,Qemu等都能够使用，看你喜欢哪个了；如果你使用的是MacOS,那么就自己解决虚拟机问题吧，我没有用过Apple的设备。

虽然本文是在虚拟机里做这个koji部署实验，不过我也会在最后附上Fedora实体机运行的效果，并且你在本地搭建好koji之后完全可以把它放置到服务器上，这样就可以实现类似Fedora官网的效果了。而且koji并不是只能为Fedora构建rpm包，还可以为openEuler等进行构建。

1、安装Fedora虚拟机

我推荐你使用Fedora xfce桌面，因为xfce占用空间很小，可以跑在一些嵌入式设备上，我们拿来做实验不需要太花里胡哨的界面。GNOME和KDE占用资源太多，其他桌面又太简单了，就选xfce吧。选择并下载ISO文件，然后创建一个虚拟机（我在下面以virt-manager为例）。

注意：你最好给虚拟机多一些内存和硬盘，因为构建系统是比较吃性能的，而且我们要在Fedora虚拟机里面再开一个Fedora RISC-V虚拟机（虚拟机嵌套），这对于资源的占用是比较大的，所以我建议你内存最好大于等于8GB,硬盘80GB左右，多分配一些也没事。（因为qcow2格式是动态的虚拟磁盘格式，它不像raw那样直接占用空间，而是你越需要空间它才会增大实际存储空间）

创建好虚拟机后会进入启动盘界面，然后正常安装Fedora就好。我当前kde桌面使用的是wayland,所以观感可能有点差，会出现莫名其妙的横竖线。

安装期间不需要对koji进行什么操作，我们先进入系统再说。

系统安装好之后：

xfce桌面自带一个firefox浏览器，这一点非常重要，我们自己部署的kojiweb应当使用firefox浏览器打开而不是其他浏览器。因为我们在访问kojihub的时候是必须携带证书的，否则就没有访问权限，无法访问。目前来说只有firefox才允许通过证书登陆，而chrome是不行的。

安装好的系统可以先更新一下rpm包然后我们会在下一章节进行openssl签发证书工作。

sudo rpm --rebuilddb
sudo dnf update
sudo dnf install zsh make cmake git python3-pip

安装界面创建的那个用户（april_zhao）默认在wheel组，所以你可以直接用sudo.

由于后期要写的命令比较多，如果你容易忘记的话你可以对当前的shell进行优化然后用ssh连接，这样可以方便你复制粘贴命令。

美化Shellhttps://blog.csdn.net/qq_61653333/article/details/139780093?spm=1001.2014.3001.5501

2、安装必要的软件包

sudo dnf install postgresql-server mod_ssl httpd koji-hub koji-web koji-utils

大家从安装的软件包里可以看出很多信息来：

koji构建系统使用postgresql这个数据库进行后台管理，也就是构建的情况和用户信息使用postgresql数据库来记录.postgresql是现在一个比较火的数据库，它也是sql,语法和mysql等sql系列的数据库一样；
kojihub的部署与SSL认证有关，但不是必须使用SSL；
kojihub使用Apache服务器跑（httpd就是apache的主程序）,不用nginx反向代理.

在安装上述包的同时会跟着多个依赖，这样一安装你就可以使用koji这个命令了。

3、初体验

我们先不要急着部署kojihub,而是先看看koji这个命令本身的一些用法。

你可以先执行一下koji help来查看koji的一些子命令，我们以后要和它们打交道并且必须理解它们的含义。

我在这里划几个关键词，它们表示一类操作。比如channel通道操作，有add,remove,edit增删改查一套，其他操作也是这样，允许增删改查。

然后最有趣的命令就是

koji hello
koji moshimoshi

这会让你当前的客户端（执行该命令的用户）去访问服务器端，相当于ping命令，去检查是否能联通，当然你现在肯定提示Error,因为它默认指向Fedora的kojihub,只有Fedora项目组的包管理maintainer才有权限访问，普通用户是连不上的，不过这并不影响你去读取Fedora官方提供的一些信息，就使用koji命令去获取，我会在后面讲到。moshimoshi在日语里相当于接电话的开场白“喂”，如果能够ping通的话，则会返回日语。有时候也会返回中文，是不是很有趣。

它使用post请求去访问kojihub后端。不用担心，等下一章做完了你就可以通过koji hello了。我们在这个阶段有更加重要的事情要做，因为koji默认是指向Fedora官方的kojihub的，所以你要趁还没有部署自己的kojihub的时候把一些信息给带出来。

虽然说我们没有权限去修改Fedora官方的kojihub的后端数据，因为我们不是kojiadmin,但是我们是可以从后端读取Fedora的包信息到前端的。相当于我们可以获取那些“只读”的信息。

1、获取Fedora40的src包列表

koji list-tagged --latest --rpms --arch src f40 > f40_src_list.txt
cat f40_src_list.txt | sed "s/-[^-]*-[^-]*.src$//g" > f40_pkg_list.txt

我这里以Fedora40做一个例子，这是在获取Fedora40的package列表文件。

2、获取软件分组信息

1) koji编译系统特定的分组信息

koji show-groups --comps f40-build > comps_f40_koji.xml

这个文件的作用包括：

定义软件包组：文件中定义了多个软件包组（group），每个组都有一个唯一的ID（如 appliance-build、build 等）。每个组包含了一系列的软件包，这些软件包可以按组进行安装。
描述软件包组：每个软件包组还包含了描述（description）、是否默认安装（default）、是否对用户可见（uservisible）等属性信息。这些属性有助于管理安装过程中的选项。
软件包列表：每个组的 <packagelist> 中列出了属于该组的软件包，每个包的类型（如“mandatory”表示必需安装）也被指定。这些包通常用于特定用途，比如构建工具、系统核心工具等。
用于安装工具或构建系统：这个文件通常会被系统安装程序（如Anaconda）或构建工具（如Koji）使用，来确定在某个软件组中应该安装哪些软件包，以及如何处理这些软件包。

这个文件是为了帮助自动化软件包的选择和安装，使得系统能够根据不同的需求（如构建、开发、媒体制作等）安装合适的工具和依赖包。

2) fedora功能分组信息

git clone https://pagure.io/fedora-comps.git
pip install click xmltodict
sudo dnf install intltool
cd fedora-comps
make all

把这几个文件做好之后留着备用就好，我们现在还用不到它们，等到kojihub部署完成之后可以通过koji命令使用这些文件。

三、部署kojihub和kojiweb

在部署kojihub的过程中，大部分操作都是先进行openssl签名执行多个脚本，这可能会导致初学者最摸不着头脑。说好的研究koji,结果大部分教程开头就是一堆openssl签名的命令。其实这么做的目的也比较好理解：就是当你以管理员身份访问某重要网站的时候，肯定会对你的身份进行验证，以确保你就是本人或确保你的权限是符合你的操作的，大多数网站都是使用账号/密码这种方式，比如你登陆QQ的时候就是这样；但是kojiweb为了安全起见，决定不采用这种简单粗暴的方式，而是仅允许kerberos和openssl这两种方式对你的身份进行验证。大家无需担心，实际上使用openssl是非常方便的，并不是想象中的那么麻烦。我在这里选择了openssl的方法，因为这种方法在网络上资料比较多，可以把脚本拿来用；而kerberos的话如果能探究出来那自然是好的，不过初学者最好是先从简单的开始，尽快得到一些成果。

1、SSL验证

这里以用户april_zhao为例，就是安装系统的时候创建的用户。我们创建一个目录/etc/pki/koji作为存放签名和证书的“大本营”，所有的签名都在这里有备份，请大家务必记住这个目录。实际上目录不是必须在这里，你可以自己修改配置文件，使其指向别的目录，但是初学者就放在这里就好了。因为/etc/pki/这个目录本身就是用来存放一些key信息，比如你在安装rpm包的时候的gpg key也是在该目录里，所以把koji的openssl签名放在这里面完全符合规范。

sudo mkdir /etc/pki/koji
cd /etc/pki/koji
vim openssl.conf

1、创建CA相关文件

在/etc/pki/koji/目录下创建我们的第一个文件openssl.conf，并填入以下内容：

WORK                    = /etc/pki/koji
RANDFILE                = .rand
CANAME                    = koji

[ca]
default_ca              = ca_default
[ca_default]
dir                     = ${ENV::WORK}
certs                   = $dir/certs
crl_dir                 = $dir/crl
database                = $dir/index.txt
new_certs_dir           = $dir/newcerts
certificate             = $dir/${ENV::CANAME}_ca_cert.crt
private_key             = $dir/private/${ENV::CANAME}_ca_cert.key
serial                  = $dir/serial
crl                     = $dir/crl.pem
x509_extensions         = usr_cert
name_opt                = ca_default
cert_opt                = ca_default
default_days            = 3650
default_crl_days        = 30
default_md              = sha256
preserve                = no
policy                  = policy_match

[policy_match]
countryName             = match
stateOrProvinceName     = match
localityName            = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[req]
default_bits            = 2048
default_keyfile         = ${ENV::WORK}/private/${ENV::CANAME}_ca_cert.key
default_md              = sha256
distinguished_name      = req_distinguished_name
x509_extensions         = v3_ca 
# The extensions to add to the self signed cert
string_mask             = MASK:0x2002

[req_distinguished_name]

[usr_cert]
basicConstraints                = CA:FALSE
nsComment                       = "OpenSSL Generated Certificate"
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid,issuer:always

[v3_ca]
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid:always,issuer:always
basicConstraints                = CA:true

这里面的内容其实并不是太重要，大家会用就好，不要去纠结里面具体的配置，不会影响使用的。openssl.conf里面的[req_distinguished_name]这个标签里没有内容，这没有关系。虽然有的教程里这里是有东西的，不过我还是推荐你什么都不要写进去，否则会影响后面脚本的执行。不过这个配置文件里面定义的文件和目录大家都可以关注一下，因为后面在签发证书的时候都会用到。里面的细节还是比较多了。

sudo touch index.txt
sudo vim pw.txt

pw.txt里存放一个你自己设置的密码，也不太重要，随便写一个就好（比如往里面写123456）。

index.txt 中会记录所有签发证书的相关信息

sudo vim serial

这是下一次签发组件证书的序号，你往里面填写01就好；在后面，你每为一名用户签发一次，该文件里的序号就+1.一会儿可以对比一下看看。

sudo mkdir {certs,confs,private}

新建三个目录。

2、创建CA证书

sudo vim createca.sh
sudo chmod +x createca.sh

WORK_DIR=/etc/pki/koji

EXPIRE_DAYS=3650
SSL_CONF_TEMPLATE=openssl.conf
caname=koji
CA_CERT_PRI_KEY=${WORK_DIR}/private/${caname}_ca_cert.key
CA_CERT_CRT=${WORK_DIR}/${caname}_ca_cert.crt
PASSPHRASE_FILE=pw.txt


## for your own instance, please change them
SERVER_NAME=koji.april.com
COMMON_NAME=${SERVER_NAME}
EMAIL_ADDR=april@${SERVER_NAME}
ORG_UNIT=Koji
SSL_CONF_SUBJ_COM='/C=CN/ST=Guangdong/L=Shenzhen/O=april'
SSL_CONF_SUBJ="${SSL_CONF_SUBJ_COM}/OU=${ORG_UNIT}/CN=${COMMON_NAME}/emailAddress=${EMAIL_ADDR}"


sudo openssl genrsa -out ${CA_CERT_PRI_KEY} 2048
sudo openssl req -verbose -new -x509 -passout file:${PASSPHRASE_FILE} \
        -days ${EXPIRE_DAYS} \
        -config ${SSL_CONF_TEMPLATE} \
        -subj ${SSL_CONF_SUBJ} \
        -out ${CA_CERT_CRT}

上述脚本是整个签名过程中非常重要的一步，不过你只需要执行一次就好，以后都不用执行了。Apache服务器就是根据这个文件去验证当前用户是否有权限去访问kojihub后端。假如你又执行了一次，那么你所有SSL都需要重新签名。所以千万不要不小心又执行一次，那么koji_ca_cert.crt会被覆盖掉的，由它产生的验证证书就全部无效了！

有两点需要注意一下：

脚本里出现了多个april,特别是SERVER_NAME这个参数，它直接影响了你将来使用哪一个url去访问kojihub后端，所以你在这里可以把koji.april.com看作是域名。这里面的april和月份没有关系，单纯是我的名字叫april，这里你可以随便写。比如说你可以改成自己的名字koji.zhangsan.com。你甚至可以改成koji.fedoraproject.org（确信），反正kojihub现在是跑在本地，你只需要做一个域名映射到本地的IP地址就好（这个后面会说）。
执行脚本后会产生一个重要文件 -- koji_ca_cert.crt 请记住这个文件，我们每给一名用户签一次名就需要使用到这个文件。
我建议你第一次执行完这个脚本生成koji_ca_cert.crt文件之后，就取消这个脚本的执行权限，以防止自己不小心把原来的证书给覆盖掉，不过你最好备份koji_ca_cert.crt（或者保护它避免被误删）

sudo chmod -x createca.sh
sudo chattr +i koji_ca_cert.crt

CA 证书是用来签发其他 SSL 证书的密钥/证书对。在对 Koji 各组件进行配置时，客户端和服务端程序要用到的 CA 证书都来自这一步骤生成的 CA 证书。CA 证书放在 /etc/pki/koji 目录下，其他各组件的证书则放在 /etc/pki/koji/certs 目录下。

3、签发模块证书

sudo mkdir newcerts
sudo vim cert-issue.sh
sudo chmod +x cert-issue.sh

#!/bin/bash
WORK_DIR=/etc/pki/koji

EXPIRE_DAYS=3650
PASSPHRASE_FILE=pw.txt
SSL_CONF_TEMPLATE=openssl.conf
# if you change your certificate authority name to something else you will
# need to change the caname value to reflect the change.
caname=koji
CA_CERT_PRI_KEY=${WORK_DIR}/private/${caname}_ca_cert.key
CA_CERT_CRT=${WORK_DIR}/${caname}_ca_cert.crt


# __HOST_NAME is equal to parameter one or the first argument when you actually
# run the script
ORG_UNIT=Koji
SERVER_NAME=koji.april.com

if [ "${2}x" != "x" ]
then
        __ORG_UNIT=${2}
        __EMAIL_ADDR=${2}@${SERVER_NAME}
        __HOST_NAME=${2}
else
        __ORG_UNIT=${ORG_UNIT}
        __EMAIL_ADDR=${1}@${SERVER_NAME}
        __HOST_NAME=${1}
fi

__PRI_KEY=${WORK_DIR}/private/${__HOST_NAME}.key
__CSR_FILE=${WORK_DIR}/certs/${__HOST_NAME}.csr
__CRT_FILE=${WORK_DIR}/certs/${__HOST_NAME}.crt
__PEM_FILE=${WORK_DIR}/${__HOST_NAME}.pem

__COMMON_NAME=${1}
SSL_CONF_SUBJ_COM='/C=CN/ST=Guangdong/L=Shenzhen/O=april'
__SSL_CONF_SUBJ="${SSL_CONF_SUBJ_COM}/OU=${__ORG_UNIT}/CN=${__COMMON_NAME}/emailAddress=${__EMAIL_ADDR}"


sudo openssl genrsa \
    -out ${__PRI_KEY} 2048 \
&& \
sudo openssl req -new -nodes -passin file:${PASSPHRASE_FILE} \
    -config ${SSL_CONF_TEMPLATE} \
    -subj ${__SSL_CONF_SUBJ} \
    -key ${__PRI_KEY} \
    -out ${__CSR_FILE} \
&& \
sudo openssl ca -batch -passin file:${PASSPHRASE_FILE} \
    -config ${SSL_CONF_TEMPLATE} \
    -out ${__CRT_FILE} \
    -infiles ${__CSR_FILE} \
&& \
sudo cat ${__CRT_FILE} ${__PRI_KEY}  | sudo tee ${__PEM_FILE} > /dev/null

这个脚本会因为你的执行时输入参数数量不同而有不同的结果。同样地，相同的变量名的值需要和前面的脚本里的变量名的值一样。不过实际上你需要关注的就是出现“april”的那些地方，改成你想要的就好。同时这里面有一个参数叫emailAddress也不需要填写你的真实email信息，只要能用就好，不要考虑太多。

sudo ./cert-issue.sh koji.april.com kojihub
sudo ./cert-issue.sh koji.april.com kojiweb
sudo ./cert-issue.sh kojiadmin
sudo ./cert-issue.sh kojira

如果是用户的话，仅需要输入一个参数的就好，比如kojiadmin。这个用户就是我们将来的“管理员”用户，我们可以使用kojiadmin给kojihub提交build task,然后kojihub会自动分配这个任务给注册好的builder（构建机）。

如图所示，当执行一次之后，就会产生名称.pem这个文件（这里就是kojihub.pem）请记住这个文件，然后serial文件里面的字符也会变成02,代表下一个创建的证书的编号是02,同时会创建一个serial.old文件，这里的内容是上一个serial文件的一个备份（里面的内容为01）.

上面的命令都执行之后/etc/pki/koji/就热闹起来了，出现了多个.pem文件。

我们在这里就把kojiadmin这个重要的“角色”，交给安装系统是创建的april_zhao，你也可以交给你自己的那个用户，当然交给root也可以，就是一般来说都是以普通用户的身份登陆系统的，进入系统后才使用firefox访问kojiweb.

我们需要在用户的家目录里创建一个.koji目录来存放配置文件和证书文件。这一点非常重要，因为只有这一步操作正确才能够访问到kojihub。这个我们以后再说，得把Apache服务器打开之后再来对比配置.koji目录前后的效果。

2、设置数据库

1、准备数据库

sudo postgresql-setup initdb
sudo systemctl enable --now postgresql.service

我们先初始化postgresql数据库然后打开服务。

2、创建数据库用户,为koji建立数据库环境

sudo useradd koji

#建立 koji 数据库用户
[tekkamanninja@Samantha ~]$ sudo -iu postgres
[postgres@Samantha ~]$ createuser --no-superuser --no-createrole --no-createdb koji
#建立 koji 数据库
[postgres@Samantha ~]$ createdb -O koji koji
#为 koji 数据库用户设置密码
[postgres@Samantha ~]$ psql -c "alter user koji with encrypted password '123456';"
ALTER ROLE
[postgres@Samantha ~]$ exit
logout

3、配置数据库服务

sudo vim /var/lib/pgsql/data/pg_hba.conf

打开这个配置文件，然后拉到最下面，把它原本写的那些配置给注释掉，然后填入以下配置：

#TYPE   DATABASE    USER    CIDR-ADDRESS      METHOD
host    koji        koji    127.0.0.1/32      trust
host    koji        koji     ::1/128          trust
#如果要使用 UNIX socket 和数据库通信（这种方式下，Koji组件的配置文件中 DBHost 选项不能进行设置），可以使用这样的配置：
local   koji        apache                    trust
local   koji        koji                      trust

sudo vim /var/lib/pgsql/data/postgresql.conf

打开这个数据库的配置文件

这一行表明监听哪些IP地址，你可以把前面的#给删除掉，默认监听localhost本地，不过你还可以改成*

表明监听任意网络接口.

在这个配置文件里还有很多参数是可以自己设置和修改的，你可以去学习一下postgresql数据库以及查看koji的中文文档。

4、重启数据库并导入数据库模板

sudo systemctl restart postgresql
sudo -iu koji
psql koji koji < /usr/share/koji/schema.sql

koji@fedora:~$ psql
psql (16.3)
输入 "help" 来获取帮助信息.

koji=> insert into users (name, status, usertype)
koji->  values ('kojiadmin', 0, 0);
INSERT 0 1
koji=> insert into user_perms (user_id, perm_id, creator_id)
koji-> values (1, 1, 1);
INSERT 0 1
koji=> select * from users;
 id |   name    | password | status | usertype 
----+-----------+----------+--------+----------
  1 | kojiadmin |          |      0 |        0
(1 行记录)

koji=> quit

Koji 管理用户(kojiadmin)需要手动通过 sql 语句添加到数据库中。当管理用户添加成功之后，其他的用户操作（增加、删除用户，修改用户权限等）可以通过 koji 命令完成。 (来自中文文档) 意思就是一旦把kojiadmin给添加进去之后，以后添加用户就不需要用sql语句去修改数据表里的信息了，直接使用koji命令就会自动改动数据表里的信息。（koji是一个相对比较全能的工具）

我们这里还有一点必须要注意一点，就是说这个postgresql数据库不知道什么原因，在并发度比较高或者开启时间较长的情况下会导致出错，所以我们必须启动一个定时刷新器，隔一段时间就要重启一下数据库；并且如果你使用期间遇到了database outage的时候那么你就需要重新启动postgresql数据库服务了。

sudo systemctl enable --now koji-sweep-db.timer

如果你要重新初始化数据库，那么在执行initdb之前需要

sudo rm -rf /var/lib/pgsql/data

把这个目录给删除

3、配置Apache服务器

这一步是比较容易出错的，而且你必须注意格式和写法，如果你的配置文件语法有误，那么Apache服务器是打不开的（再次强调这里的httpd服务就是Apache服务器）。

1)修改http基本设置

sudo vim /etc/httpd/conf.d/kojihub.conf

把这个文件拉到最底下，然后把我选框里的代码给取消注释，然后保存并退出。这里注意一下uncomment那一行不要取消注释，因为那一行就是单纯的注释、它不是配置。

2)修改koji-hub配置文件

sudo vim /etc/koji-hub/hub.conf

做出如下修改，你可以根据实际需要，改成你的那个样子。

3)修改ssl配置

sudo vim /etc/httpd/conf.d/ssl.conf

SSLCertificateFile /etc/pki/koji/certs/kojihub.crt
SSLCertificateKeyFile /etc/pki/koji/private/kojihub.key
SSLCertificateChainFile /etc/pki/koji/koji_ca_cert.crt
SSLCACertificateFile /etc/pki/koji/koji_ca_cert.crt

我们需要对这几个File配置指向的文件进行修改，这里我们再一次使用到了koji_ca_cert.crt.如果前面有注释的话，还要把注释给取消掉。

并且你需要把这两个参数给解除注释，否则的话可能会出现SSL版本不一致导致无法访问到kojihub.

4)创建目录/mnt/koji

sudo mkdir -p /mnt/koji/{packages,repos,repos-dist,scratch,work}
sudo chown -R apache:apache   /mnt/koji/*
sudo systemctl enable --now httpd

我们在前面koji-hub配置文件里的一个参数KojiDIr里写了一个目录/mnt/koji，这就是我们将来的第二个“大本营”，我们必须设置这个目录可以被Apache服务访问。设置好了之后你就可以打开Apache服务，并设置为开机自启动。但是你第一次打开不一定成功，如果报错了，那么就去查看它的日志，Apache服务的日志是写的比较详细的，问题具体出现在哪一个配置文件的哪一行都会告诉你的，你顺藤摸瓜去看看那一行是不是哪里写错了就好。

我在这里给你举个例子好了：

journalctl -xeu httpd.service

如图所示，我去查看Apache服务的日志，结果显示该目录里有语法错误，然后还写明了错误原因：我这里是这个koji_ca_cert.crt文件的位置给写错了，然后我打开这个文件再改成正确的，这样就可以打开服务了。以后Apache服务出现任何问题都这样这样去解决。

4、部署kojiweb

1) 修改/etc/kojiweb/web.conf

SiteName = koji
KojiHubURL = http://koji.april.com/kojihub
KojiFilesURL = http://koji.april.com/kojifiles

# SSL authentication options
# 其中 WebCert 对应的文件必须同时包含公钥和私钥信息，也就是pem文件
WebCert = /etc/pki/koji/kojiweb.pem
KojiHubCA = /etc/pki/koji/koji_ca_cert.crt
# This must be CHANGED to random value and uncommented before deployment
# Secret = CHANGE_ME
Secret = april

2) 修改/etc/httpd/conf.d/kojiweb.conf

# uncomment this to enable authentication via SSL client certificates
<Location /koji/login>
    SSLVerifyClient require
    SSLVerifyDepth  10
    SSLOptions +StdEnvVars
</Location>

取消注释上述内容。

这里需要注意一下，由于我们现在使用的是SSL签名，所以你取消注释都是取消带有ssl的那一段，kerberos那一段你不要取消注释。

为了能够在本地访问koji.april.com，我们需要做一个url到IP地址的映射：

sudo vim /etc/hosts

127.0.0.1 koji.april.com
192.168.122.59 koji.april.com

这其实相当于是DNS，只不过这个DNS仅限于本地计算机使用，你需要把localhost映射到这里，并且把你的实际IP地址也做一个映射。

/etc/hosts：本地静态主机名解析文件。系统在解析域名时，首先会查看 /etc/hosts 文件。如果在这个文件中找到了对应的域名与IP地址的映射关系，系统就直接使用这个映射，而不再查询DNS服务器。

/etc/resolv.conf：配置DNS服务器的文件。这个文件告诉系统在需要进行域名解析时，应该联系哪些DNS服务器来获取IP地址。当系统在 /etc/hosts 中找不到某个域名的解析时，才会根据 /etc/resolv.conf 中指定的DNS服务器进行查询。

IP地址可以这样查看。

5、导入浏览器证书

我们先为浏览器生成访问证书，当携带该证书的浏览器访问你的kojiweb网页（我这里是koji.april.com）的时候，就可以成功访问了。比如你不导入这个证书，那么实际上你作为kojiadmin还是没有访问kojiweb的权限。我们在这里需要使用PKCS12证书来进行浏览器的身份验证。

PKCS12文件使用密码保护，可以安全地存储在文件中，便于在不同系统之间传输个人证书和密钥。它广泛应用于SSL/TLS配置中，用于身份验证和加密数据传输。

cd /etc/pki/koji
sudo vim PKCS12.sh

往里面填入以下内容：

WORK_DIR=/etc/pki/koji
# if you change your certificate authority name to something else you will
# need to change the caname value to reflect the change.
caname=koji
CA_CERT_CRT=${WORK_DIR}/${caname}_ca_cert.crt


__USER_NAME=${1}
__PRI_KEY=${WORK_DIR}/private/${__USER_NAME}.key
__CRT_FILE=${WORK_DIR}/certs/${__USER_NAME}.crt
__P12_FILE=${WORK_DIR}/certs/${__USER_NAME}_browser_cert.p12


sudo openssl pkcs12 -export \
    -inkey ${__PRI_KEY} \
    -in ${__CRT_FILE} \
    -CAfile ${CA_CERT_CRT} \
    -out ${__P12_FILE}

sudo chmod +x PKCS12.sh
sudo ./PKCS12.sh kojiadmin

执行时会询问你是否要设置一个密码，这个密码和前面的pw.txt不是同一个东西。而是在你的浏览器引入这个证书的时候会询问你密码，如果你什么都不填（即不设置密码），那么在引入证书的时候保持空白就行，如果设置了密码就写你设置的密码。

执行脚本后会在/etc/pki/koji/certs/ 里生成一个带有browser（浏览器）字样的证书文件，你可以先在这里把它设置成777的权限，一来这样会变成绿色标记比较显眼，二来你在firefox引入证书的时候就不会出现无法访问该文件的问题。你需要在firefox里引入这个证书文件，然后你就可以通过浏览器访问kojiweb了。接着往下看

我们首先打开firefox,并在搜索栏里写入 about:config 我们要做一个配置

在config页面的搜索框里搜索

security.tls.enable_post_handshake_auth

原本的是选择了false,现在点击右侧的转换按钮使其变成true.

然后我们点击设置 -> 隐私与安全 -> 查看证书

点击您的证书 -> 导入

选择其他位置，并从根目录开始一路查找到/etc/pki/koji/kojiadmin_browser_cert.p12这个文件，双击进行导入操作

然后就会进入这个界面，如果你之前写了密码，就把密码写上去；如果你之前和我一样填的是空，那就直接点击登陆就好，不用写东西进去；如果你忘记了密码，那你就回去重新执行PKCS12.sh这个脚本。

点击确定后成功导入。

至此你就可以在浏览器输入koji.april.com/koji，进入的页面就是所谓的kojiweb.我们可以通过这个kojiweb界面去和kojihub这个后端进行交互。

当你第一次使用firefox访问的时候会出现这个现象，你点击高级 -> 接受风险并继续，这样就能进去了。

sudo systemctl restart httpd postgresql.service

我们在正式访问之前重启一下Apache服务器和数据库，以避免配置文件没有更新，确保这两个服务都是能够正常运行的。

如果你比较莽撞地去访问，可能会得到上图所示的结果，selinux会阻止httpd访问80号端口，我们还需要进行一系列的设置。

当然，你也可以直接关掉SELinux,这样最简单粗暴，不过更妥善的解决办法是允许Apache访问postgresql数据库。

sudo setsebool -P httpd_can_network_connect_db=1 allow_httpd_anon_write=1 httpd_can_network_connect=1
sudo chcon -R -t public_content_rw_t /mnt/koji/*

不过既然提到了防护问题，我们得开放一下防火墙，避免影响我们访问：

sudo firewall-cmd --add-service=https --permanent && sudo firewall-cmd --add-service=http --permanent
sudo firewall-cmd --add-port=443/tcp --permanent && sudo firewall-cmd --add-port=80/tcp --permanent
sudo systemctl restart firewalld

如果这么做了还是被拦截，那么就考虑一下关闭SELinux和firewalld防火墙守护进程。

然后重启httpd ，并再一次访问koji.april.com

这下就可以正常访问了

但是点击login后出了问题

sudo vim /etc/koji-hub/hub.conf

## the client username is the common name of the subject of their client certificate
DNUsernameComponent = CN
## separate multiple DNs with |
ProxyDNs = emailAddress=kojiweb@koji.april.com,CN=koji.april.com,OU=kojiweb,O=april,L=Shenzhen,ST=Guangdong,C=CN

把这两行前面的注释都取消掉，然后把ProxyDNs改成它提示你的那一句，也就是我用红色框框标记出来的那里，复制粘贴到这里面进去然后重启Apache服务器。

sudo systemctl restart httpd

重启后再次访问：

从现在开始你就正式以管理员身份去访问了。

大家可以看见在网页标签的左上角有一个“麴”字，这就是koji的一个标志吧算是。然后你可以对比一下前面Fedora koji的和iscas部署的koji的图，你会发现其实前端不太一样。Fedora官方和iscas的kojiweb前端是美化过的，比较好看，因为前端的话自己去改相对比较容易。虽然我们现在的界面也许简陋了一点，不过我们现在主要学习这个思维，界面什么的就将就一下吧。

你默认部署好的koji的前端是它自带的，就叫kojiweb,大家有兴趣的可以点开kojiweb目录，所有的html,css,js以及static资源都在这里面。整个koji项目包括前端、后端、数据库以及插件，都集成在它的源码里，你可以通过修改源码的方式改变它的样貌或作用。

6、通过命令行和kojiweb查看kojihub信息

其实我们到目前为止已经能够看到kojiweb了，你通过firefox浏览器访问koji.aprilc.om/koji展示出来的这个界面就是kojiweb,作为kojiadmin,你可以通过这个界面进行比较方便地进行一些操作。不过真正核心的一些任务实际上还是得由koji这个命令来完成。

你现在在命令行敲koji hello实际上还是会报错，因为此时你还没有携带证书，所以我们现在就是要把之前在证书“大本营”里生成的那一堆证书给用起来。

cd
mkdir .koji
cd .koji
cp /etc/koji.conf config

实际上那个报错信息里已经有提示了，我们就是要把证书和config文件放置到~/.koji/这个目录下面，/etc/koji.conf是一个模板文件，你依照这个模板去做一个配置。

~/.koji/config

[koji]

;configuration for koji cli tool

;url of XMLRPC server
;server = http://hub.example.com/kojihub
server = https://koji.april.com/kojihub

;url of web interface
;weburl = http://www.example.com/koji
weburl = https://koji.april.com/koji

;url of package download site
;pkgurl = http://www.example.com/packages
topurl = https://koji.april.com/kojifiles

;path to the koji top directory
topdir = /mnt/koji

;configuration for Kerberos authentication

;the principal to auth as for automated clients
;principal = client@EXAMPLE.COM

;the keytab to auth as for automated clients
;keytab = /etc/krb5.keytab

; fedora uses kerberos auth
authtype = ssl

;configuration for SSL authentication

;client certificate
cert = ~/.koji/client.crt

;certificate of the CA that issued the HTTP server certificate
serverca = ~/.koji/serverca.crt


;plugin paths, separated by ':' as the same as the shell's PATH
;koji_cli_plugins module and ~/.koji/plugins are always loaded in advance,
;and then be overridden by this option
;plugin_paths = ~/.koji/plugins

;[not_implemented_yet]
;enabled plugins for CLI, runroot and save_failed_tree are available
;plugins =
; runroot plugin is enabled by default in fedora
plugins = runroot

;timeout of XMLRPC requests by seconds, default: 60 * 60 * 12 = 43200
;timeout = 43200

;timeout of GSSAPI/SSL authentication by seconds, default: 60
;auth_timeout = 60

;enforcing CLI authentication even for anonymous calls
;force_auth = False

; use the fast upload feature of koji by default
use_fast_upload = yes

cp /etc/pki/koji/koji_ca_cert.crt serverca.crt
cp /etc/pki/koji/kojiadmin.pem client.crt
sudo chown april_zhao:april_zhao ~/.koji/*

我们把一个配置文件和两个证书给放置好，并把owner设置为用户自己。

然后见证奇迹的时刻就到了：

到目前为止应该说都是挺顺利的，我几遍走下来遇到的错误也都给解决了，但是后面出现的问题会更多更复杂还没有文档可以看。大家要做好随时查看源码的准备。

四、配置并启用kojira

kojira是koji的仓库管理守护进程，它负责对数据库进行增删改查，就是说很多操作都是kojira自动帮你完成，而不需要说你自己来做。

1、添加kojira用户并进行配置

koji add-user kojira
#kojira 用户需要拥有 repo 权限
koji grant-permission repo kojira

我们使用koji命令添加kojira用户,现在添加一个用户已经不需要直接对数据库进行操作了。至于repo权限是一个什么样的权限，这个会在后面的时候讲到。

可以来验证一下是否添加成功：

sudo -iu koji

如图所示，确实已经添加了kojira这个用户了。

sudo vim /etc/kojira/kojira.conf

然后对这个配置文件进行修改

;在 /etc/kojira/kojira.conf 中添加 koji-hub 的 url 地址：
server=http://koji.april.com/kojihub
;使用 SSL 证书验证
cert = /etc/pki/koji/kojira.pem
serverca = /etc/pki/koji/koji_ca_cert.crt

配置好之后打开守护进程就好

sudo systemctl enable --now kojira

五、配置kojibuilder和hosts

如图所示，上图中的kojibuilder1,kojibuilder2,kojibuilder3就是hosts。上图是我举例子用的另一个系统，我拿来做一个演示，大家不用关注这几个kojibuilder是哪里来的。

每一个host就对应一个builder构建机；
Arches代表了这个hosts构建包的架构；
Channels代表了他们的权限，默认具有default权限；
Enabled代表是否启用，你可以把它关掉，不使用它
Ready代表这个builder是否已经准备好了（你也可以认为是这个builder机器上的kojid是否正常运行）；
Load表示当前负载，为0表示当前builder一个任务都没有接；
Cap（capacity）代表总负载，就是说这个builder最多能够接几个任务，当Load和Cap的值相等的时候意味着这个builder已经满负载了（非常忙碌）；
Last Update就是说这个builder最后上线时间。

在构建一个包的时候，不同的任务，它的负载Load是不同的。

rebuildSRM是1,相当于会占用100%的CPU.在Linux中有n个逻辑核心（或者说Hart）那么它的总CPU就是100% * n.

buildArch的负载是1.5

buildNotification的负载是1.0

rebuildSRPM的负载是1.0

new-repo的负载是0.1

create-repo的负载是1.0

还有一些小任务的负载是比较低的，当同时运行多个Task的时候会出现非整的数。

我现在就把这一套关于hosts的操作方法说明一下：

我们在默认情况下，Hosts里面是什么都没有的，需要自己去添加和修改信息。我们也可以通过koji命令去查看这些信息。

➜  ~ koji list-hosts
No hosts found.
➜  ~

现在是空的。

1、添加host

koji add-host kojibuilder1 x86_64

# koji add-host 名称 架构

通过这条命令我们去添加第一个host，名称为kojibuilder1，架构为x86_64，我们把它设置为本机，也就是kojihub运行的那台机器，也就是你开的虚拟机。执行后观察现象

刷新一下网页，这时候就有信息了，由于我们还没有打开kojid,所以这里的Ready显示未开启。在默认情况下，Cap是设置为2.0，可以自己调节。

2、修改host负载

koji edit-host --capacity=4  kojibuilder1

# koji edit-host --capacity=n 名称

现在kojibuilder1有更高的Cap了，在高性能设备上可以调高一点，低性能就调低一点。

不过更快更方便的方法是直接点击kojibuiler1

这样通过图形界面去修改会更加方便，最后你只需要点击Save按钮保存即可。同时注意一下这里的Channels的选择，这个就是该host的权限，只有具备了某一个权限才能完成一种任务。

kojiweb的按钮你可以都去点一下，因为你现在是kojiadmin，作为管理员这里面的按钮没有什么你是不能点的。比如这里如果你点击disable，那么这个host就会被关掉、不使用。

再点一下还会打开来。

3、打开kojid使准备好

现在我们要在本机上打开kojid守护进程，来作为kojibuilder1这个host对应的机器。

sudo yum install koji-builder

kojid守护进程就在这个软件包里。

cd /etc/pki/koji
sudo ./cert-issue.sh kojibuilder1
sudo cp kojibuilder1.pem /etc/kojid/client.crt
sudo cp koji_ca_cert.crt /etc/kojid/serverca.crt

大家还记得我前面说过“每多一个需要访问kojihub的用户就需要执行该脚本”吧，为了让我们的kojibuilder1允许访问kojihub,所以我们要用这个脚本生成一个SSL证书，并把这个证书放置到/etc/kojid/目录下。

sudo cp /etc/pki/koji/koji_ca_cert.crt /etc/pki/ca-trust/source/anchors/serverca.crt
sudo update-ca-trust

让builder信任koji hub的自建CA

sudo vim /etc/kojid/kojid.conf

参考下面我写的配置文件：

[kojid]
; The number of seconds to sleep between tasks
; sleeptime=15

; The maximum number of jobs that kojid will handle at a time
maxjobs=10

; Time after successfully finished task's buildroot is deleted (2 minutes in seconds)
; Some logs and directories are left in place until buildroot_final_cleanup_delay
; buildroot_basic_cleanup_delay=120


; Time after successfully finished task's buildroot is deleted completely (1 day in seconds)
; buildroot_final_cleanup_delay=86400

; The minimum amount of free space (in MBs) required for each build root
minspace=4096

; The directory root where work data can be found from the koji hub
; topdir=/mnt/koji

; The directory root for temporary storage
workdir=/tmp/koji

; The temporary directory in buildroot
; chroot_tmpdir = /chroot_tmpdir

; The directory root for mock
; mockdir=/var/lib/mock

; The user to run as when doing builds
; mockuser=kojibuilder

; The vendor to use in rpm headers
; vendor=Koji

; The packager to use in rpm headers
; packager=Koji

; The distribution to use in rpm headers
; distribution=Koji

; The _host string to use in mock
; mockhost=koji-linux-gnu

; Timeout for build duration (24 hours)
rpmbuild_timeout=86400

; Install timeout(seconds) for image build
; Default value is 0, which means using the number in /etc/oz/oz.cfg,
; supported since oz-0.16.0
; oz_install_timeout=7200

; The URL for the xmlrpc server
server=http://koji.april.com/kojihub

; The URL for the file access
topurl=http://koji.april.com/kojifiles

; use createrepo_c rather than createrepo
; use_createrepo_c=True

; for faster repo regeneration reuse last repodata for given repo
; createrepo_update=True

; for createrepo tasks believe that rpms were not changed and
; we don't even need to stat them again. Turn off if some rewrites are expected.
; createrepo_skip_stat=True

; same as createrepo_skip_stat but for distrepo tasks. Here is the expectation
; different as distrepo can be run with different signing keys. So, tasks can refer
; to different binary versions of rpms. Turn on if you're sure that the task will
; be always run in same way. Not recommended
; distrepo_skip_stat=False

; copy old repodata if there is no apparent change
; copy_old_repodata = False

; A space-separated list of tuples from which kojid is allowed to checkout.
; The format of those tuples is:
;
;     host:repository[:use_common[:source_cmd]]
;
; Incorrectly-formatted tuples will be ignored.
;
; If use_common is not present, kojid will attempt to checkout a common/
; directory from the repository.  If use_common is set to no, off, false, or 0,
; it will not attempt to checkout a common/ directory.
;
; source_cmd is a shell command (args separated with commas instead of spaces)
; to run before building the srpm. It is generally used to retrieve source
; files from a remote location.  If no source_cmd is specified, "make sources"
; is run by default.
allowed_scms=scm.example.com:/cvs/example git.example.org:/example svn.example.org:/users/*:no

; If use the option allowed_scms above for allowing / denying SCM, default: true
; allowed_scms_use_config = true

; If use hub policy build_from_scm for allowing / denying SCM, default: false
; notice that if both options are enabled, both assertions will be applied, and user_common and
; source_cmd will be overridden by the policy's result.
; allowed_scms_use_policy = false

; A directory to bind mount into Source RPM creation so that some
; credentials can be supplied when required to fetch sources, e.g.
; when the place the sources are fetched from requires all accesses to
; be authenticated in order to satisfy auditing requirements.
;
; The directory specified here will turn up in the SRPMfromSCM chroot
; as /credentials. It is up to whatever implements "make_source_cmd"
; to make appropriate use of any credentials supplied.
;
; Be aware that this means "make_source_cmd" has access to these
; credentials and could steal them; any credentials supplied
; should be easily disabled, and not used for other purposes.
; scm_credentials_dir = /etc/kojid/scmcredentials

; The mail host to use for sending email notifications
smtphost=koji.april.com

; SMTP user and pass (uncomment and fill in if your smtp server requires authentication)
;smtp_user=user@example.com
;smtp_pass=CHANGEME

; The From address used when sending email notifications
from_addr=april <april@qq.com>

;configuration for Kerberos authentication

;the format of the principal used by the build hosts
;%s will be replaced by the FQDN of the host
;host_principal_format = compile/%s@EXAMPLE.COM

;location of the keytab
;keytab = /etc/kojid/kojid.keytab

;configuration for SSL authentication

;client certificate
cert = /etc/kojid/client.crt

;certificate of the CA that issued the HTTP server certificate
serverca = /etc/kojid/serverca.crt

;if set to True, failing subtask will not automatically cancel other siblings
;build_arch_can_fail = False

;if set to True, tag extra 'mock.bootstrap_image' can be used
;mock_bootstrap_image = False

;image build with raw-xz type will use following xz options
;xz_options=-z6T0

;if set to True additional logs with timestamps will get created and uploaded
;to hub. It could be useful for debugging purposes, but creates twice as many
;log files
;log_timestamps = False

;enabled plugins, base koji installation has access to runroot and save_failed_tree
;none of these is enabled by default
;plugin = 

;path where builder plugins are located, there could be multiple paths delimited by :
;pluginpath = /usr/lib/koji-builder-plugins

;allow passing noverifyssl option to anaconda for image builds
;allow_noverifyssl = False

;allow password in SCM url
;allow_password_in_scm_url = False

准备就绪后就可以打开kojid

sudo systemctl enable --now kojid

于是

现在kojibuilder1已经可以干活了！

这个/etc/kojid/kojid.conf是非常重要的配置文件，可以说在builder机器上会发生的一切行为都由这个配置文件作为依据，也就是说它不仅仅是指明ssl证书的位置（虽然到目前为止它也就这个作用了）。在构建用的机器上，我们不需要做更多的环境配置，比如说搭建干净的构建环境、在环境里安装构建依赖包、构建完成后删除环境，以上的这些任务都由kojid守护进程来完成。不需要用户或者说运维人员天天守着ssh盯着看。

实际上这些配置文件在源码里都有模板，kojibuilder软件包在安装的时候也会放到/etc/kojid.conf里面去。大家可以在koji的源代码里找到所有组件。

六、小结

我现在打算是把整个这一过程分成两篇文章来写，因为到目前为止该blog已经三万字了，我再写下去会导致不方便查看。所以下一篇文章我会讲述如何构建rpm包，如何部署RISC-V的builder从而构建出risc-v架构的rpm包，其实其他架构也是同样的操作。大家就稍稍期待一下吧。

你照着本篇文章做完之后就能部署好kojihub和kojiweb，并且可以使用koji命令和后端进行数据的交互。你看完之后可能还会觉得有些迷糊，我们这里需要做一个总结，把这一个部署的过程给简单描述一下。

这是中文文档里的一幅图，我就依据这幅图，把这一个过程给描述出来给大家看看。

我们整个koji服务的核心就是kojihub,你可以认为这就是一个后端，所有的部分都必须通过kojihub进行联系和交互，是所有数据和任务的中转站。我们个人使用firefox浏览器，访问的是kojiweb也就是前端。kojihub同时与postgresql数据库进行交互，从数据库里取出数据或者把数据放回数据库。这样就是一套经典的C/S架构（Client/Server）。

kojihub同时还可以和kojid进行交互，kojid这是也是一个守护进程，它是跑在builder机器上面。kojid和kojihub进行交互，把kojihub里已经提交的任务拿来执行，并且是负载均衡的，由kojihub自动分配，这里的任务不一定指的是rpm包的构建任务，还有其他的repo重建等任务，都需要由builder来执行。并且builder不一定在kojihub运行的机器上，它可以是一台虚拟机，也可以是一块高性能开发板（只不过这个需要远程连接），但是道理是大同小异的。相当于koji命令是生产者，而kojid是消费者，这类似于操作系统里面的“生产者与消费者模型”，一个负责提交任务，一个负责解决任务。这么做好处是分工明确，提高效率。

同时在koji构建系统里还有一个repo的重要部分，这个会在下一篇文章里多次出现。

这篇文章到这里就结束了，到目前为止，我们已经搭建和部署好了kojihub,并可以通过多种方式去访问后端，查找和修改数据库里的数据。在下一篇文章里，我会去构建第一个rpm包，真正地发挥koji的作用。

实体机运行效果如下：