Как стать автором
Обновить

Комментарии 23

Хорошая статья, однако, у меня есть пару идей, как можно было бы сделать её ещё лучше.

На мой взгляд, первые пункты про запись образа диска и установку CentOS можно было бы и опустить. Думаю, что человек, поставивший себе задачу поднять свой репозиторий, самостоятельно сможет справиться с установкой системы.

Инструкция в виде готового рецепта неплоха, но всегда лучше, когда для каждого действия объяснена причина, последствия, а также случаи, когда можно этим действием пренебречь.

Также, для улучшения восприятия, в примерах хотелось бы видеть большую сфокусированность именно на процессе сборки, а не на особенностях конфигурации tmux'а. Но это уже так, придирки.
Отвечу тут Вам и товарищу ниже с подобным комментарием.

Мне не хотелось отдельную статью делать про установку CentOS, в то же время хотелось показать, как стоит подходить к вопросу проверки целостности и достоверности дистрибутива, как его скачать в консоли в виде torrent, как закатать образ из той же консоли на флешку или диск и что все это можно сделать просто и доступными вещами. Так же в статье есть места с настройками SSH и межсетевого экрана, которые с одной стороны можно было опустить, но с другой тема с уклоном в безопасность и организацию надежного сервиса была бы не полной, по этому я принял решение описать весь путь от начала до конца, что позволит в будущем просто ссылаться на данную статью.

Объяснений причин для каждого действия действительно не хватает, но объем статьи в таком случае увеличился бы в разы, я старался пояснять некоторые моменты, которые казались мне не очевидными.

Про tmux — стоит отметить конфигурационный файл для него — это единственный полный, с комментариями файл конфигурации в интернете, чтобы его собрать и описать я перерыл все маны, исходный код проекта и попутно указал на некоторые оплошности на GitHub. Так что можно сказать — «моя прелесть». Ну и писать отдельную статью о конфигурации tmux посчитал мелко, для хабра.
Статья очень фундаментальная, спасибо большое!

Но соглашусь с xomachine, что это в чем-то и проблема — например, по запросу «habr настройка tmux» на не гуглится, хотя должна бы. Аналогично с «правильной» установкой дистрибутива. Просто те, кому это интересно, а сборка rpm пакетов не очень, не прочтут ее (хотя хотели бы).

В общем, труд колоссален, спасибо большое! Но если все же сможете разбить ее на 3 части — будет еще лучше.

Спасибо, огромный труд!


Одно непонятно: если человек не умеет поставить centos 7, то репозиторий ему точно незачем поднимать, а если умеет, некоторые моменты избыточны. Но труд объемный, побольше бы такого!

Спасибо за статью. Часто делаю бекпорты для своего дистрибутива и вечно проблемы с подписью пакетов. Не давно для CentOS пересобирал пакет с недостающим патчем, пришлось гуглить не много. Спасибо. Добавил в закладки.
Экспортируем GPG ключи для проверки исходников:
gpg --recv-keys 8EF8686D
gpg --recv-keys F7E48EDB

А что это за magic numbers? Откуда они берутся?

«magic numbers» — часть отпечатка ключа, идентификатор открытого ключа (GPG key ID). В примере в статье был вывод команды:
gpg --fingerprint chelaxe@gmail.com
    pub   2048R/E6D53D4D 2014-05-07
          Key fingerprint = EE2A FF9A 2BE3 318E 9346  A675 8440 3961 E6D5 3D4D
    uid                  ChelAxe (D.F.H.) <chelaxe@gmail.com>


тут E6D53D4D и есть GPG key ID — однозначно определяет мой открытый ключ. Посмотреть его можно в самой подписи к файлу или однозначно получив от авторов ПО, например в статье в начале мы скачивали ключ CentOS для проверки подлинности файла с контрольными суммами:

wget http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-7
gpg --quiet --with-fingerprint RPM-GPG-KEY-CentOS-7
    pub  4096R/F4A80EB5 2014-06-23 CentOS-7 Key (CentOS 7 Official Signing Key) <security@centos.org>
          Key fingerprint = 6341 AB27 53D7 8A78 A7C2  7BB1 24C6 A8A7 F4A8 0EB5


тут GPG key ID — F4A80EB5

Спасибо! Теперь понял.

Кстати, гораздо точнее воспроизводить сборочное окружение помогает утилита mock — обертка над rpmbuild, которая создает chroot при сборке.
mock действительно удобная вещь, когда ты постоянно и много собираешь пакетов, но если объем не большой, то достаточно будет:
сборку производить на отдельном виртуальном хосте, активно используя технологию snapshot'ов


Да вот статейка по mock, с которой можно начать.
mock пользоваться проще, чем виртуальной машиной. Да что уж там, mock'ом собирать даже проще, чем rpmbuild'ом. И с зависимостями не накосячишь. Я уж не говорю про сборку для разных версий дистрибутивов и даже где-то как-то для разных архитектур.
Кому как. Сколько пользовался rpmbuild'ом не заметил неудобств в его использовании, да и не проблема работать в виртуальной среде. Все упирается лишь в количестве сборок, чем их больше и есть необходимость под разные дистрибутивы и архитектуры, тем больше есть нужда в подобных инструментах. В моем случае штатных средств хватает вполне.

sudo chcon -R -t httpd_sys_content_t ~/rpmbuild/REPO/.htaccess


Контекст слетит после ребута. Для постоянного действия Semanage fcontext -a -t httpd_sys_content_t "~/rpmbuild/REPO/.htaccess" затем restorecon -Rv ~/rpmbuild/REPO/.htaccess. и во втором случае аналогично

Выше посмотрите там есть:
sudo semanage fcontext -a -t public_content_t '/var/www/repo(/.*)?'
sudo restorecon -Rv '/var/www/repo'


Ниже действительно не указал `restorecon`, но это подразумевалось. Вообще .htaccess лучше не использовать, о чем я и писал в статье.
Давно не проверял, но раньше createrepo не умел автоматически генерировать подпись для метаданных. Вероятно вам стоит добавить (после каждого вызова createrepo):
gpg --detach-sign --armor ~/rpmbuild/REPO/repodata/repomd.xml
Сообразил что у вас в chelaxe.repo также отсутствует repo_gpgcheck=1. Оно вам не нужно или есть другая причина?
Есть
gpgcheck=1

Про «генерировать подпись для метаданных» я как-то упустил. Спасибо. Изучу этот момент и внесу в статью.
repo_gpgcheck = 1

относится так же к проверке подписи у метаданных. Я понял о чем Вы, проверю этот момент и допишу.
Чем делать rich-rule, проще было добавить новую зону, добавить туда сеть и сервис ssh
Кому как удобнее и проще. Мне кажется так нагляднее и понятно.
Вот certbot вместо acme.sh как-то странно выглядит. Ничего личного, но гибче же!
Спасибо. Обязательно ознакомлюсь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории