SkyOS →

Часть I. Требования к системе, сертификаты

Выбор сборочной системы

Хорошим решением представляется использование части системы инфраструктуры Fedora. Как наиболее простой в настройке и эксплуатации. Компоненты Koji могут работать на отдельных ресурсах, если все ресурсы способны обмениваться данными. В этом цикле статей будет рассказано, как настроить работу всех служб на одном сервере, однако все службы могут находиться на разных ресурсах.

Замечание о пространстве файловой системы

Koji будет использовать много дискового пространства в основном каталоге KojiDir (как установлено в файле kojihub.conf - по умолчанию /mnt/koji ). Однако, так как koji использует mock на бэкэнде для фактического создания корней сборки и выполнения сборок в этих корнях сборки, пользователей может удивить, что работающий сервер koji будет занимать большие объемы дискового пространства в /var/lib/mock и /var/cache/mock . Пользователи должны либо спланировать для этого дисковое пространство и файловую систему, либо запланировать изменение каталога фиктивной сборки по умолчанию в файле kojid.conf. Если вы измените местоположение, убедитесь, что новые каталоги принадлежат группе «mock» и имеют разрешение 02755.

Выбор аутентификации Koji

Коджи в первую очередь поддерживает аутентификацию Kerberos и SSL-сертификатов. Для базового доступа к командной строке koji возможны простые комбинации user/pass. Однако kojiweb не поддерживает обычную аутентификацию и как только для kojiweb будет включена аутентификация Kerberos или SSL-сертификат, простой метод user/pass перестанет работать полностью. Аутентификация же Kerberos требует соответствующей инфраструктуры. По этой причине я рекомендуем вообще пропустить простой метод user/pass и Kerberos, а правильно настроить аутентификацию по SSL-сертификатам с самого начала.

Для аутентификации SSL

Сертификаты SSL для сервера xmlrpc, для различных компонентов koji и один для пользователя-администратора должны быть настроены (пользователю уже не нужно знать, как создавать цепочки сертификатов, мы включим инструкции для этого ниже).

Создайте каталог /etc/pki/koji скопируйте и вставьте файл ssl.cnf, указанный здесь, и сохраните его в новом каталоге. Этот файл конфигурации используется вместе с командой openssl для генерации SSL-сертификатов для различных компонентов koji.

ssl.cnf HOME = . RANDFILE = .rand [ca] default_ca = ca_default [ca_default] dir = . certs = $dir/certs crl_dir = $dir/crl database = $dir/index.txt new_certs_dir = $dir/newcerts certificate = $dir/%s_ca_cert.pem private_key = $dir/private/%s_ca_key.pem 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 organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional [req] default_bits = 2048 default_keyfile = privkey.pem default_md = sha256 distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca # The extensions to add to the self signed cert string_mask = MASK:0x2002 [req_distinguished_name] countryName = Country Name (2 letter code) countryName_default = RU countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = Russia localityName = Locality Name (eg, city) localityName_default = Lisky 0.organizationName = Organization Name (eg, company) 0.organizationName_default = Samopal Inc organizationalUnitName = Organizational Unit Name (eg, section) commonName = Common Name (eg, your name or your server\'s hostname) commonName_max = 64 emailAddress = Email Address emailAddress_max = 64 [req_attributes] challengePassword = A challenge password challengePassword_min = 4 challengePassword_max = 20 unstructuredName = An optional company 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

Хотя это и не требуется, рекомендуется изменить значения по умолчанию в разделе [req_distinguished_name] конфигурации, чтобы они соответствовали информации для вашего собственного сервера. Это позволит вам принять большинство значений по умолчанию при создании сертификатов. Другие разделы могут быть оставлены без изменений.

Создание CA

CA является центром сертификации. Это пара ключ / сертификат, используемая для подписи всех других запросов на сертификат. При настройке различных компонентов koji и клиентский CA, и серверный CA будут копией CA, сгенерированной здесь. Сертификат CA будет помещен в каталог /etc/pki/koji а сертификаты для других компонентов будут помещены в каталог /etc/pki/koji/certs . index.txt файл index.txt является базой данных сгенерированных сертификатов и может использоваться для просмотра информации для любого из сертификатов, просто просматривая содержимое index.txt.

cd /etc/pki/koji/ mkdir {certs,private,confs} touch index.txt echo 01 > serial openssl genrsa -out private/skyos_ca_cert.key 4096 openssl req -config ssl.cnf -new -x509 -days 3650 -key private/skyos_ca_cert.key \ -out skyos_ca_cert.crt -extensions v3_ca

Последняя команда, приведенная выше, попросит вас подтвердить ряд пунктов о генерируемом вами сертификате. Предположительно, вы уже отредактировали значения по умолчанию для страны, штата / провинции, организации в ssl.cnf и вам нужно было всего лишь нажать Enter. Для самого СА(ЦС) эти поля не имеют жестких требований. Одним из предложений для этого сертификата является использование полного доменного имени сервера.Или как в нашем случае SkyOS CA

Создание сертификатов для компонентов koji и сертификата администратора.

Каждому компоненту коджи необходим собственный сертификат для его идентификации. Два из сертификатов (kojihub и kojiweb) используются в качестве сертификатов на стороне сервера, которые аутентифицируют сервер для клиента. По этой причине если вы хотите, чтобы общее имя в обоих этих сертификатах было одинаковое и чтобы клиенты не жаловались на общее имя и сервер вы можете установить OU для этих двух сертификатов как kojihub и kojiweb для целей идентификации.

Для других сертификатов (kojira, kojid, начальной учетной записи администратора и всех пользовательских сертификатов) сертификат используется для аутентификации клиента на сервере. Общее имя для этих сертификатов должно быть установлено на имя входа для этого конкретного компонента. Например, общее имя для сертификата kojira должно быть установлено на kojira, чтобы оно совпадало с именем пользователя. Причина этого заключается в том, что общее имя сертификата будет сопоставлено с соответствующим именем пользователя в базе данных koji. Если в базе данных нет имени пользователя, которое соответствует CN сертификата, клиент не будет аутентифицирован, и доступ будет запрещен.

Когда вы позже используете koji add-host для добавления машины сборки в базу данных koji, она создает учетную запись пользователя для этого хоста, даже если учетная запись пользователя не отображается в списке пользователей. Созданная учетная запись пользователя должна соответствовать общему имени сертификата, который этот компонент использует для аутентификации на сервере. При создании сертификата kojiweb вам нужно будет точно помнить, какие значения вы вводите для каждого поля, так как вам придется их вносить в файл /etc/koji-hub/hub.conf в качестве записи ProxyDN.

Когда вам нужно создать несколько сертификатов, может быть удобно создать цикл или сценарий, как описано ниже, и запустить сценарий для создания сертификатов. Вы можете просто настроить количество kojibuild-еров и имя учетной записи администратора по своему усмотрению. Для большей части этого руководства учетная запись администратора называется kojiadm.

#!/bin/bash # if you change your certificate authority name to something else you will # need to change the caname value to reflect the change. caname=skyos # user is equal to parameter one or the first argument when you actually # run the script user=$1 openssl genrsa -out private/${user}.key 2048 cat ssl.cnf | sed 's/insert_hostname/'${user}'/'> ssl2.cnf openssl req -config ssl2.cnf -new -nodes -out certs/${user}.csr -key private/${user}.key openssl ca -config ssl2.cnf -keyfile private/${caname}_ca_cert.key -cert ${caname}_ca_cert.crt \ -out certs/${user}.crt -outdir certs -infiles certs/${user}.csr cat certs/${user}.crt private/${user}.key > ${user}.pem mv ssl2.cnf confs/${user}-ssl.cnf

Создание сертификата пользователя PKCS12 (для веб-браузера)

Это требуется только для пользовательских сертификатов. В дополнении к скрипту выше.

openssl pkcs12 -export -inkey private/${user}.key -in certs/${user}.crt \ -CAfile ${caname}_ca_cert.crt -out certs/${user}_browser_cert.p12

При создании сертификатов для пользователя ${user}_browser_cert.p12 файлы ${user}.pem , ${caname}_ca_cert.crt и ${user}_browser_cert.p12 которые были сгенерированы выше. Файл $ {user} .pem обычно устанавливается как ~/.fedora.cert , ~/.fedora.cert ${caname}_ca_cert.crt устанавливается как ~/.fedora-upload-ca.cert и ~/.fedora-server-ca.cert , и пользователь будет импортировать ${user}_brower_cert.p12 в свой веб-браузер в качестве личного сертификата.