[Неофициальные] пакеты Fedora (и EL)

[Неофициальные] пакеты Fedora (и EL), UniFi Network

hobbes1069

Guest

11.12.2017 20:06:00

Теперь, когда unifi находится в репозиториях RPM Fusion Non-Free, установка стала ещё проще. К сожалению, MongoDB был удалён из Fedora (и RHEL) из-за смены лицензии на проприетарную, но они предоставляют пакет, совместимый с EL. Инструкции по установке были позаимствованы с благодарностью @justabr0. Для CentOS 7 вместо dnf используйте yum, понятно.

Шаги 1-5 (подготовка):
sudo su
dnf update -y
dnf install epel-release
dnf install --nogpgcheck https://download1.rpmfusion.org/nonfree/el/rpmfusion-nonfree-release-8.noarch.rpm
dnf config-manager --enable PowerTools

Шаги 6-7 (подготовка MongoDB):
vi /etc/yum.repos.d/mongodb-org-4.2.repo
Вставьте в новый файл следующее и сохраните:
[mongodb-org-4.2]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/4.2/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-4.2.asc

Шаг 8 (установка MongoDB):
dnf install -y mongodb-org

Шаги 9-11 (установка и настройка UniFi):
dnf install unifi
systemctl enable --now unifi.service

Шаги 12-13 (настройка файрвола):
firewall-cmd --permanent --add-service=unifi
firewall-cmd --reload

Шаг 14 (перезагрузка – НЕ ОБЯЗАТЕЛЬНО, по желанию пользователя):
shutdown -r now

Контроллер UniFi теперь должен быть доступен по адресу: https://<hostname>:8443/ и/или https://<IP>:8443/

hobbes1069

Guest

26.06.2022 03:48:00

Что касается требования пакета unifi из RPM Fusion, жесткой зависимости от mongo у него нет, предполагается, что он у вас уже установлен. Проблема с поддержкой el7 описана выше — в общем, glibc там слишком старая. Единственный возможный обходной путь — это использовать docker-контейнер, если кто-нибудь его сделает. Спасибо, Ричард.

jcnt

Guest

26.06.2022 02:48:00

Возвращаясь к этой теме, заметил, что в epel7 убрали mongodb-server из пакета, и теперь при обновлениях возникают конфликты. Кто-нибудь знает, какую версию mongodb с официального сайта лучше использовать?

К тому же, в версии 5.9.29 по-прежнему mongodb-server числится как зависимость, а официальный пакет mongodb предоставляет:

$ rpm -q --provides mongodb-org-server
mongo-10gen-server
mongodb-org-server = 5.0.9-1.el7
mongodb-org-server(x86-64) = 5.0.9-1.el7

Может, стоит обновить 5.9.29, чтобы это учесть?

hobbes1069

Guest

07.07.2020 21:56:00

Скорее всего, версия LTS вам подойдёт (хотя я ещё не проверял это). Но обойти тот факт, что они ориентируются на более новую версию glibc, чем в EL 7, хорошего способа нет. Если хотите использовать последнюю версию, попробуйте найти какой-нибудь контейнер (docker или что-то похожее). В упаковке это никак не обойти. Спасибо, Richard.

jcnt

Guest

07.07.2020 21:53:00

Я до сих пор работаю на версии 5.5.20 и mongodb 3.2 на EL7. Жалоб нет, но меня беспокоит, что обновления прошивки для устройств вроде коммутаторов и точек доступа, по всей видимости, идут вместе с контроллером. Я подключил новый контроллер от Ubiquiti для теста, восстановил конфигурацию из своего бэкапа, и он сразу предложил обновить прошивку на всех подключённых устройствах Ubiquiti. Я решил не обновлять, чтобы избежать конфликтов с моей текущей 5.5.20. Вопрос: достаточно ли просто обновить rpm до 5.9.29, или нужно также апгрейдить mongodb?

hobbes1069

Guest

15.02.2019 02:38:00

Окей, так что у меня мало что получилось с версией 5.10.x... Во-первых, она не устанавливается на CentOS 7 из-за версии glibc, с которой связывается... На моей Fedora 29 я получил вот такую ошибку, которую так и не смог исправить:
Feb 10 08:47:24 systemd[1]: Started Ubiquiti UniFi server.
Feb 10 08:47:24 java[9203]: Feb 10, 2019 8:47:24 AM org.apache.commons.httpclient.HttpMethodDirector executeWithRetry
Feb 10 08:47:24 java[9203]: INFO: I/O exception (java.net.ConnectException) caught when processing request: Connection refused (Connection refused)
Feb 10 08:47:24 java[9203]: Feb 10, 2019 8:47:24 AM org.apache.commons.httpclient.HttpMethodDirector executeWithRetry
Feb 10 08:47:24 java[9203]: INFO: Retrying request
Feb 10 08:47:24 java[9203]: Feb 10, 2019 8:47:24 AM org.apache.commons.httpclient.HttpMethodDirector executeWithRetry
Feb 10 08:47:24 java[9203]: INFO: I/O exception (java.net.ConnectException) caught when processing request: Connection refused (Connection refused)
Feb 10 08:47:24 java[9203]: Feb 10, 2019 8:47:24 AM org.apache.commons.httpclient.HttpMethodDirector executeWithRetry
Feb 10 08:47:24 java[9203]: INFO: Retrying request
Feb 10 08:47:24 java[9203]: Feb 10, 2019 8:47:24 AM org.apache.commons.httpclient.HttpMethodDirector executeWithRetry
Feb 10 08:47:24 java[9203]: INFO: I/O exception (java.net.ConnectException) caught when processing request: Connection refused (Connection refused)
Feb 10 08:47:24 java[9203]: Feb 10, 2019 8:47:24 AM org.apache.commons.httpclient.HttpMethodDirector executeWithRetry
Feb 10 08:47:24 java[9203]: INFO: Retrying request
Feb 10 08:48:30 systemd[1]: Stopping Ubiquiti UniFi server...
Так что вот вам парочка *ТЕСТОВЫХ* пакетов. Могут быть драконы, которые едят младенцев, так что ОБЯЗАТЕЛЬНО сделайте резервную копию.
https://www.dropbox.com/s/1cx1ywm665vkxmq/unifi-5.10.17-1.fc29.x86_64.rpm
https://www.dropbox.com/s/jcytu1nlgqwaexa/unifi-data-5.10.17-1.fc29.noarch.rpm
В общем, они должны работать с текущими релизами Fedora.
Спасибо,
Richard

hobbes1069

Guest

07.02.2019 19:27:00

Две большие новости!!!
1. unifi-lts теперь доступен в RPM Fusion non-free для тех, кто поддерживает Gen 1 UAP.
2. unifi 5.10.x использует библиотеки, связанные с libstc++ 3.4.20, которая недоступна для CentOS 7 — там поддерживается максимум версия 3.4.19...
Сейчас у меня нет решения этой проблемы, так что 5.10.x для EL 7 я предоставить не смогу.
Спасибо, Richard

hobbes1069

Guest

08.08.2018 16:23:00

Да, я подписан, чтобы получать обновления о релизах. На работе сейчас мало времени, чтобы заняться упаковкой, и обычно я сначала тестирую на своём CentOS 7, чтобы заметить явные проблемы, прежде чем запускать сборки на RPM Fusion. Спасибо, Ричард.

svde Guest	#9 08.08.2018 14:07:00 К вашему сведению: https://community.ui.com/releases/fe7a9921-5a78-4d22-954f-bda1f099c2fb

hobbes1069

Guest

#10

29.07.2018 11:35:00

Мне специально разрешили упаковывать только стабильные релизы. Я не загружаю пакеты ни в testing, ни в stable. Если вы пользуетесь пакетами из RPM Fusion, вам действительно стоит подписаться на их рассылку для пользователей и задавать такие вопросы там. Спасибо, Ричард.

svde

Guest

#11

29.07.2018 10:07:00

4. Или просто следите за релизами UBNT. Когда они выпускают «stable candidate» (например: https://community.ui.com/releases/e26ccd78-03bd-4aa1-a18b-398a343405a0), тогда упаковывайте это и кладите в rpmfusion non-free testing. В момент выхода «stable» (например: https://community.ui.com/releases/8bf9da67-7a53-4bde-a100-ae9283d03d8) — упаковывайте в rpmfusion non-free testing и через 24 часа перемещайте в rpmfusion non-free stable.

За блогом UBNT легко следить через RSS.

Смысл в том, чтобы предоставлять стабильные версии UBNT только в rpmfusion non-free stable, при этом давая тем, кто не боится пользоваться rpmfusion non-free testing, возможность не только тестировать сам rpm-пакет (spec-файл и systemd-магии), но и проверять stable candidate от UBNT, а потом возвращать обратную связь UBNT.

Да, это немного больше работы, но, думаю, это добавляет больше пользы и одновременно проясняет, чего ожидать по срокам продвижения пакетов из rpmfusion non-free testing в stable.

Guest

#12

26.07.2018 00:14:00

svde: Я не совсем понимаю, в чем у тебя проблема? Думаю, тебе просто нужно выбрать одно из следующих решений:
1. Включи testing-репозиторий, если хочешь получать пакеты сразу после их создания — без ожидания, пока кто-то нажмёт кнопку. И, пожалуйста, постарайся помочь нам с тестированием.
2. Если хочешь, чтобы обновления из testing быстрее попадали в stable автоматически — не стесняйся присоединиться к rpmfusion-community и помочь сделать что-то более автоматизированное (и, возможно, побыстрее), как это сделали в сообществе Fedora. Хорошее место для старта — это список rpmfusion-developers.
3. Сделай свою собственную упаковку и не распространяй плохую карму в этой теме.

svde

Guest

#13

25.07.2018 21:25:00

DNF обновился сегодня утром: unifi x86_64 5.8.24-1.fc28 rpmfusion-nonfree-updates. Посмотрим, сколько времени в следующий раз займет у вас нажатие кнопки, чтобы перевести всё из тестовой версии в стабильную. Ты упомянул, что rpmfusion — сообщество поменьше, чем у Fedora.

Вопросы: Сколько человек вообще пользуются тестовым репозиторием rpmfusion non-free? Сколько из них используют пакет unifi? Сколько из них на самом деле отправит сообщение, что последняя версия в тестовой работает нормально и её можно переводить в стабильную? (Ответ: никто?)

Пакету нужна широкая проверка, чтобы выявить проблемы. Хотя это и сложный софт, настоящие сложности, с которыми я столкнулся, связаны не с упаковкой rpm, а с тем, что старые версии mongodb несколько раз обновлялись, а потом mongodb отказывалась загружать базу данных. Ты тоже собираешься решать такие проблемы своей упаковочной магией?

> Всё бесплатное стоит ровно столько, сколько за это платишь 😀

Да, спасибо, напомнил. Это доказывает, что, может, лучше самому всё сделать, чем ждать, пока кто-то (кто вдруг забыл?) нажмёт нужную кнопку.

hobbes1069

Guest

#14

25.07.2018 20:45:00

Пакеты обычно находятся в тестировании около недели после того, как я их собираю. В Fedora есть система на основе karma, которая позволяет пакету раньше попасть в стабильную версию, но, к сожалению, у RPM Fusion гораздо более скромная инфраструктура и меньше участников, поэтому у нас такой механизмы нет. Перемещение пакетов (как в тестирование после сборки, так и в стабильную ветку позже) происходит вручную. Всё бесплатное стоит ровно столько, сколько вы за это платите 😀 Спасибо, Richard

mcavalieri

Guest

#15

25.07.2018 13:37:00

Пожалуйста, не забывайте, что он оказывает вам услугу, поддерживая этот пакет в репозитории. Я предполагаю, что делает это сам, при том что у него есть работа и другие дела. Если это значит, что вам или мне придётся немного подождать, вместо того чтобы поддерживать свою собственную версию, — пусть так и будет. Если хотите обновления гораздо быстрее, то, кажется, есть два варианта:
1) Помочь. Протестировать обновления в ветке testing и выложить результаты.
2) Собрать свою версию на основе его или чужой работы. В сообществе несколько человек поддерживают RPM-версию UniFi.

svde

Guest

#16

25.07.2018 12:14:00

Каждое обновление (с 0.8.23 до 0.8.24) должно недельками висеть в тестировании, прежде чем его перенесут в релизный репозиторий? Потому что вы переделываете «FHS-совместимый способ», в упаковке unifi, где я уже делаю кучу «фокусов» — настройка systemd-сервиса и всё такое? Всё это уже сделано, и, на мой взгляд, совсем не повод держать пакет в тестировании так долго. Понимаю, если он висит пару часов или, максимум, день, но не гораздо дольше. Кто вообще решает, когда пакет переходит из теста в релиз? Это автоматический процесс (например, с фиксированным сроком в 4 недели) в репозитории rpmfusion, или кто-то вручную нажимает кнопку?

hobbes1069

Guest

#17

25.07.2018 11:32:00

Это инструмент контроля качества... В упаковке апстрим-проекта много чего учитывается, что не входит в сам апстрим-релиз. Например, нужно убедиться, что всё устанавливается в соответствии с FHS — именно для этого я делаю кучу «магии» при упаковке unifi. Настройка systemd-сервиса и так далее. Мы, паковщики, не идеальны и можем ошибаться, поэтому логично дать более смелым пользователям протестировать новые пакеты (если они хотят), прежде чем всем автоматически придёт обновление в рамках обычного системного апдейта. Если хотите самые свежие версии — можно либо постоянно включить тестовый репозиторий, либо на базе моего пакета собрать свой собственный. Спасибо, Richard.

svde Guest	#18 24.07.2018 21:19:00 Я ценю проделанную работу... Но действительно ли этот процесс добавляет какую-то пользу? Я подумываю взять src.rpm и разместить его на openSUSE Build Service. Так обновлять будет быстрее и меньше бюрократии.

mcavalieri Guest	#19 24.07.2018 19:01:00 Достаточно. Ценю проделанную работу и обновление. Спасибо.

hobbes1069 Guest	#20 24.07.2018 18:54:00 Все пакеты проходят процесс, в ходе которого их собирают и некоторое время тестируют, прежде чем отправить в стабильное репозиторий. Это никак не связано с upstream, а касается только внутреннего процесса пакетов и процесса релиза, а не релиза upstream. Если это объяснение вам не подходит, могу попытаться изложить по-другому. К тому же всё в Fedora, особенно в RPM Fusion, делают волонтёры, так что даже если Ubiquity выпустил новую версию сегодня, ничего не происходит автоматически. Мне нужно найти время, чтобы заняться упаковкой, и это не входит в мой основной доходный проект. 😀 Спасибо, Richard

Читают тему (гостей: 1)