Привет, По мотивам рекомендаций использовать Ubuntu вместо CentOS. Поставил Ubuntu Server 17.10. Почитал, поконфигурил. В общем все понятно и красиво. Но есть один вопрос. Как <правильно> ставить свежий софт? Два вопроса: 1. В случае с nginx в его собственном репозитории есть нужная версия, но некоторые модули смотрят на другую более старую версию. Как быть? 2. В случае с redis - вообще нужно собрать из исходников свежую версию. Как это сделать с установкой на конкретной системе - ясно. А как собрать package, который можно поставить на другом сервере через apt-get? Поделитель, пожалуйста, опытом. Вот, на примере nginx и redis. NGINX:
apt-search show nginx Package: nginx Architecture: all Version: 1.12.1-0ubuntu2
А если хочется mainline? Например так:
wget --quiet -O - http://nginx.org/keys/nginx_signing.key | sudo apt-key add - echo "deb http://nginx.org/packages/mainline/ubuntu/ $(lsb_release -cs) nginx" >> /etc/apt/sources.list.d/nginx.list echo "deb-src http://nginx.org/packages/mainline/ubuntu/ $(lsb_release -cs) nginx" >> /etc/apt/sources.list.d/nginx.list apt-get update apt-search show nginx Package: nginx Version: 1.13.9-1~artful Architecture: amd64
Уже лучше. Но, хочется еще module headers-more.
add-apt-repository ppa:nginx/development apt-get update apt-cache show libnginx-mod-http-headers-more-filter Package: libnginx-mod-http-headers-more-filter Architecture: amd64 Version: 1.13.6-0+artful0
И вот тут облом. Модуль собран под 1.13.6, а последняя версия 1.13.9. Понятно дело, при попытке установки получаем: The following packages have unmet dependencies: libnginx-mod-http-headers-more-filter : Depends: nginx-common (= 1.13.6-0+artful0) but it is not going to be installed E: Unable to correct problems, you have held broken packages. Что в таком случае правильно делать? Поскольку разница между 1.13.6 и 1.13.9 для модуля врядли критична - задавить ошибки? Или собирать из исходников? REDIS:
apt-cache show redis-server Package: redis-server Architecture: amd64 Version: 4:4.0.1-7
В текущая версия 4.0.8. Понятно, что можно скачать исходники, дальше ./configure ./make ./make install Но, а можно как-то сделать стандартный package для Ubuntu и потом поставить его обычным apt-get? С уважением, Александр
Hello! On Fri, 23 Feb 2018 at 16:56:18 (+0200), Alex Cherevko wrote:
add-apt-repository ppa:nginx/development apt-get update apt-cache show libnginx-mod-http-headers-more-filter Package: libnginx-mod-http-headers-more-filter Architecture: amd64 Version: 1.13.6-0+artful0
И вот тут облом. Модуль собран под 1.13.6, а последняя версия 1.13.9. Понятно дело, при попытке установки получаем:
The following packages have unmet dependencies: libnginx-mod-http-headers-more-filter : Depends: nginx-common (= 1.13.6-0+artful0) but it is not going to be installed E: Unable to correct problems, you have held broken packages.
Что в таком случае правильно делать? Поскольку разница между 1.13.6 и 1.13.9 для модуля врядли критична - задавить ошибки? Или собирать из исходников?
Возьмите и nginx из этого ppa.
REDIS:
apt-cache show redis-server Package: redis-server Architecture: amd64 Version: 4:4.0.1-7
В текущая версия 4.0.8.
Гляньте в ppa:chris-lea/redis-server
Понятно, что можно скачать исходники, дальше ./configure ./make ./make install
Но, а можно как-то сделать стандартный package для Ubuntu и потом поставить его обычным apt-get?
Можно взять deb с нужной версией отсюда (dpkg -i package-name.deb): http://ftp.lt.debian.org/debian/pool/main/r/redis/ Ну, или заморочиться созданием своего deb. В сети полно howto. -- George L. Yermulnik [YZ-RIPE]
Привет! Смотрю вот, Alex Cherevko пишет как-то (Пятница, 23 Февраль, 16:56):
apt-cache show redis-server Package: redis-server Architecture: amd64 Version: 4:4.0.1-7
В текущая версия 4.0.8. Понятно, что можно скачать исходники, дальше ./configure ./make ./make install
Но, а можно как-то сделать стандартный package для Ubuntu и потом поставить его обычным apt-get?
1) Для сборки пакетов надо поставить пакет devscripts. 2) Нужный пакет подготавливается путём распаковки двух архивов: а) package_X.Y.Z_orig.tar.gz б) package_X.Y.Z-N.debian.tar.xz внутрь распакованного (а) 3) Зайти в подготовленные исходники и набрать команду debuild. Файл package_X.Y.Z_orig.tar.gz должен оставаться в каталоге .. перед запуском команды. 4) После успешного завершения в каталоге .. будет готовый к установке при помощи apt файл пакета package-X.Y.Z-N.deb. Достаточно часто обновление до новой версии можно сделать лишь подменой package_X.Y.Z_orig.tar.gz на package_X.Y.W_orig.tar.gz (с распаковкой, конечно) и редактированием первой строчки в файле debian/changelog, но не всегда, иногда приходится ещё усилия приложить. Удачи! Андрей.
Hi
Как «правильно» ставить свежий софт?
В контейнерах. https://en.wikipedia.org/wiki/Linux_containers
Поставил Ubuntu Server 17.10.
Плохой выбор.
Срок жизни LTS версии - 5 лет, обычной - 8-9 мес.
https://en.wikipedia.org/wiki/Ubuntu_(operating_system)#Releases
--
Best regards,
Mykola
2018-02-23 16:56 GMT+02:00 Alex Cherevko
Привет,
По мотивам рекомендаций использовать Ubuntu вместо CentOS.
Поставил Ubuntu Server 17.10. Почитал, поконфигурил. В общем все понятно и красиво.
Но есть один вопрос.
Как «правильно» ставить свежий софт?
Два вопроса:
1. В случае с nginx в его собственном репозитории есть нужная версия, но некоторые модули смотрят на другую более старую версию. Как быть?
2. В случае с redis – вообще нужно собрать из исходников свежую версию. Как это сделать с установкой на конкретной системе – ясно.
А как собрать package, который можно поставить на другом сервере через apt -get?
Поделитель, пожалуйста, опытом.
Вот, на примере nginx и redis.
NGINX:
apt-search show nginx
Package: nginx
Architecture: all
Version: 1.12.1-0ubuntu2
А если хочется mainline?
Например так:
wget --quiet -O - http://nginx.org/keys/nginx_signing.key | sudo apt-key add -
echo "deb http://nginx.org/packages/mainline/ubuntu/ $(lsb_release -cs) nginx" >> /etc/apt/sources.list.d/nginx.list
echo "deb-src http://nginx.org/packages/mainline/ubuntu/ $(lsb_release - cs) nginx" >> /etc/apt/sources.list.d/nginx.list
apt-get update
apt-search show nginx
Package: nginx
Version: 1.13.9-1~artful
Architecture: amd64
Уже лучше. Но, хочется еще module headers-more.
add-apt-repository ppa:nginx/development
apt-get update
apt-cache show libnginx-mod-http-headers-more-filter
Package: libnginx-mod-http-headers-more-filter
Architecture: amd64
Version: 1.13.6-0+artful0
И вот тут облом. Модуль собран под 1.13.6, а последняя версия 1.13.9.
Понятно дело, при попытке установки получаем:
The following packages have unmet dependencies:
libnginx-mod-http-headers-more-filter : Depends: nginx-common (= 1.13.6-0+artful0) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
Что в таком случае правильно делать? Поскольку разница между 1.13.6 и 1.13.9 для модуля врядли критична – задавить ошибки?
Или собирать из исходников?
REDIS:
apt-cache show redis-server
Package: redis-server
Architecture: amd64
Version: 4:4.0.1-7
В текущая версия 4.0.8.
Понятно, что можно скачать исходники, дальше
./configure
./make
./make install
Но, а можно как-то сделать стандартный package для Ubuntu и потом поставить его обычным apt-get?
С уважением,
Александр
_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
Думаю уже сказали и до меня, но добавлю. У меня по убунте и версиям софтин есть 2 варианта тактики, смотря чего нужно, а чего достаточно. 1. Версии софта в штатной репе убунту как правило *достаточно* свежие. Соответственно тактика номер раз - юзать что предложено, и не заморачиваться. 2. Если свежесть версии имеет значение. Тогда находим у производителя софтинки его собственньій third-party Ubuntu PPA (в большинстве случаев он есть), и добавляем его в систему штатньіми средствами. После чего то, что доступно из добавленного таким образом PPA, "перекрьівает" своими (более свежими) пакетами те, что предлагаются в родной репе. Ну а чего нету в добавленной репе, будет браться из родной. Рисков минимум, и если что-то пошло не так, откатиться можно в любую минуту легко. Тактикой номер 3 "самому собирать из исходников" я не пользуюсь вообще, т.к. хлопотно, затратно и в среднем рискованно.
Hi All,
2018-02-23 21:05 GMT-08:00 Stesin
Думаю уже сказали и до меня, но добавлю. У меня по убунте и версиям софтин есть 2 варианта тактики, смотря чего нужно, а чего достаточно.
1. Версии софта в штатной репе убунту как правило *достаточно* свежие. Соответственно тактика номер раз - юзать что предложено, и не заморачиваться.
+1 - обычно майнтейнер пакета более-менее в курсе как самого пакета, так и интеграции его с инфраструктурой дистрибутива
2. Если свежесть версии имеет значение. Тогда находим у производителя софтинки его собственньій third-party Ubuntu PPA (в большинстве случаев он есть), и добавляем его в систему штатньіми средствами.
После чего то, что доступно из добавленного таким образом PPA, "перекрьівает" своими (более свежими) пакетами те, что предлагаются в родной репе. Ну а чего нету в добавленной репе, будет браться из родной. Рисков минимум, и если что-то пошло не так, откатиться можно в любую минуту легко.
Оно то да, но есть нюансы. Если оверлейная репа одна, то обычно проблем не возникает - разве что в дистре внезапно выкатят слишком уж свежее, но apt позволяет заморозить некоторые пакеты. А вот с двумя и более уже возможны нюансы с тем, что каждый из оверлеев может гарантировать совместимость с базовой, но не между собой. Пример: * есть базовая репа с пакетами P1 и P2, причем P2 зависит от P1 * есть оверлейная репа A с более свежим пакетом P1+ (совместим с базовой репой) * есть оверлейная репа B с более свежим пакетом P2 + (тоже совместим с базовой репой) Вот только при одновременном подключении A и B мы получим конфликт, потому как P2 требует более старую версию пакета P1, чем предоставляемый из репы A.
Тактикой номер 3 "самому собирать из исходников" я не пользуюсь вообще, т.к. хлопотно, затратно и в среднем рискованно.
Можно, если собирать в виде deb пакетов и укладывать в приватную apt репу.
_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
On Feb 24, 2018 09:24, "Michael Bochkaryov"
Оно то да, но есть нюансы.
... В точности так. Впрочем, лично я как-то давно уже не попадал на такое. Лентяй патамушта ;) Тактикой номер 3 "самому собирать из исходников" я не пользуюсь вообще,
т.к. хлопотно, затратно и в среднем рискованно.
Можно, если собирать в виде deb пакетов и укладывать в приватную apt репу. На любителя. To whom how. Я, повторюсь, лентяй. :) Еще есть вариант, применимьій дозированно и с оглядкой на рекомендации собаководов. Кое-что иногда рекомендуют (в редких случаях) скачать .deb с более актуальной версией из оф. репьі предрелизного Debian и поставить. Пару раз так делал. В порядке исключения.
До речі, 18.04 вже на підході. В дверях майже. -- /doka, on the run
On Feb 24, 2018, at 15:05, Stesin
wrote: On Feb 24, 2018 09:24, "Michael Bochkaryov"
wrote: Оно то да, но есть нюансы. ... В точности так. Впрочем, лично я как-то давно уже не попадал на такое. Лентяй патамушта ;)
Тактикой номер 3 "самому собирать из исходников" я не пользуюсь вообще, т.к. хлопотно, затратно и в среднем рискованно.
Можно, если собирать в виде deb пакетов и укладывать в приватную apt репу.
На любителя. To whom how. Я, повторюсь, лентяй. :)
Еще есть вариант, применимьій дозированно и с оглядкой на рекомендации собаководов. Кое-что иногда рекомендуют (в редких случаях) скачать .deb с более актуальной версией из оф. репьі предрелизного Debian и поставить. Пару раз так делал. В порядке исключения.
_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
Власне, з 17.10 на 18.04 десь у червні перейти, як бліх виведуть, і можна
ще років 5 на ній і працювати. Про що власне і йшлося ще як Олег свій Xen
ставив.
On Feb 24, 2018 15:21, "Volodymyr Litovka"
Привіт усім.
Ну, так. Ото як поставив (XenServer 7.2 + 5 віртуальних машин, з яких одна
Univention Corporate Server на базі Debian, а інші - Ubuntu 17.10) - так і
забув. Працює, як годинник, їсти не просить (звісно, навантаження, можна
сказати, незначне).
Вчасно треба було (дякую Миколі Уляницькому) лише не провтикати і
відмовитися від апгрейду на version 7.3 (яка порівняно із 7.2 виглядає
явною диверсією).
24 лютого 2018 р. о 18:05 Stesin
Власне, з 17.10 на 18.04 десь у червні перейти, як бліх виведуть, і можна ще років 5 на ній і працювати. Про що власне і йшлося ще як Олег свій Xen ставив.
On Feb 24, 2018 15:21, "Volodymyr Litovka"
wrote: До речі, 18.04 вже на підході. В дверях майже.
_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
-- Regards, /oleh hrynchuk http://zmejgorynych.blogspot.com
он другой
policy поменялась
On Feb 26, 2018 18:07, "Alex Cherevko"
Вчасно треба було (дякую Миколі Уляницькому) лише не провтикати і відмовитися від апгрейду на version 7.3 (яка порівняно із 7.2 виглядає явною диверсією).
А что плохого в XenServer 7.3? А то я, как раз, пока не применял пока update на 7.3, но думал...
_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
нет dynamic memory control, ограничено до 3 количество серверов в
кластере (но если создать кластер на версии 7.2 и заапгрейдить до 7.3,
то прокатит) и кучка других ограничений. Загоняют на платную версию.
26 лютого 2018 р. о 18:06 Alex Cherevko
Вчасно треба було (дякую Миколі Уляницькому) лише не провтикати і відмовитися від апгрейду на version 7.3 (яка порівняно із 7.2 виглядає явною диверсією).
А что плохого в XenServer 7.3? А то я, как раз, пока не применял пока update на 7.3, но думал...
_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
-- Pavlo Narozhnyy +380 95 276 31 46 https://www.techniqtrading.com/
Загоняют на платную версию XenServer очень активно, отключая возможность поставить апдейты на более ранние версии бесплатных релизов. Если хочешь получать апдейты и иметь вовремя пропатченную систему, нужно быть на current release (сечас это 7.3), который будет выходить раз в 3 месяца. Остаться на 7.2 без ущерба для безопасности скорее всего не получится. On 02/26/18 18:37, Pavlo Narozhnyy wrote:
нет dynamic memory control, ограничено до 3 количество серверов в кластере (но если создать кластер на версии 7.2 и заапгрейдить до 7.3, то прокатит) и кучка других ограничений. Загоняют на платную версию.
26 лютого 2018 р. о 18:06 Alex Cherevko
написав: Вчасно треба було (дякую Миколі Уляницькому) лише не провтикати і відмовитися від апгрейду на version 7.3 (яка порівняно із 7.2 виглядає явною диверсією). А что плохого в XenServer 7.3? А то я, как раз, пока не применял пока update на 7.3, но думал...
_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
On Feb 26, 2018 19:12, "Andrey Lakhno"
On Mon, Feb 26, 2018 at 06:37:47PM +0200, Pavlo Narozhnyy wrote:
нет dynamic memory control, ограничено до 3 количество серверов в "нет" или "отключили управлялку" ?
кластере (но если создать кластер на версии 7.2 и заапгрейдить до 7.3, то прокатит) и кучка других ограничений. Загоняют на платную версию.
Ну кусочек работы - ставить 7.2, настраивать, апгрейдить, жить... -- Best regards, Paul Arakelyan.
On Feb 24, 2018 5:05 AM, "Stesin"
т.к. хлопотно, затратно и в среднем рискованно.
Можно, если собирать в виде deb пакетов и укладывать в приватную apt репу. На любителя. To whom how. Я, повторюсь, лентяй. :) Скорее зависит от того, потребуется ли воспроизводить в будущем регулярно. Для домашнего применения таки overkill. Для промышленного применения таки стоит и делается просто. Еще есть вариант, применимьій дозированно и с оглядкой на рекомендации собаководов. Кое-что иногда рекомендуют (в редких случаях) скачать .deb с более актуальной версией из оф. репьі предрелизного Debian и поставить. Пару раз так делал. В порядке исключения. Лучше тогда взять исходники этого deb и пересобрать, чтобы не ловить косяки с зависимостями. Впрочем, см. первую часть ответа :)
0. Никогда не ставить _не LTS_ в продакшен.
2018-02-24 7:05 GMT+02:00 Stesin
Думаю уже сказали и до меня, но добавлю. У меня по убунте и версиям софтин есть 2 варианта тактики, смотря чего нужно, а чего достаточно.
1. Версии софта в штатной репе убунту как правило *достаточно* свежие. Соответственно тактика номер раз - юзать что предложено, и не заморачиваться.
2. Если свежесть версии имеет значение. Тогда находим у производителя софтинки его собственньій third-party Ubuntu PPA (в большинстве случаев он есть), и добавляем его в систему штатньіми средствами.
После чего то, что доступно из добавленного таким образом PPA, "перекрьівает" своими (более свежими) пакетами те, что предлагаются в родной репе. Ну а чего нету в добавленной репе, будет браться из родной. Рисков минимум, и если что-то пошло не так, откатиться можно в любую минуту легко.
Тактикой номер 3 "самому собирать из исходников" я не пользуюсь вообще, т.к. хлопотно, затратно и в среднем рискованно.
_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
-- wbr, Alex
On Feb 25, 2018 09:55, "Alexey Belinsky"
Кстати, еще стоит посмотреть в сторону вынесения сервисов в контейнеры. Как
минимум, позволит обновлять базовую систему и приложения независимо друг от
друга.
On Feb 25, 2018 9:35 AM, "Stesin"
On Feb 25, 2018 09:55, "Alexey Belinsky"
wrote: 0. Никогда не ставить _не LTS_ в продакшен.
...что очевидно и ежу.
Но если у тебя продакшен по плану начнется через полгода, а свежий LTS будет через 4 месяца, то разумнее поставить на дев/тест пред-LTS и обновиться, чем ставить заведомо древний уходящий LTS в фазе его заката. Я так думаю.
_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
On Sun, Feb 25, 2018 at 07:34:53PM +0200, Stesin wrote:
On Feb 25, 2018 09:55, "Alexey Belinsky"
wrote: 0. Никогда не ставить _не LTS_ в продакшен.
...что очевидно и ежу.
Но если у тебя продакшен по плану начнется через полгода, а свежий LTS будет через 4 месяца, то разумнее поставить на дев/тест пред-LTS и обновиться, чем ставить заведомо древний уходящий LTS в фазе его заката. Я так думаю.
Однохренственно - "дурень думкою ...", 17.хх - не совсем "пред-LTS" и вопросы понадобится решать аналогичные. Так что единственная причина - "нужные версии пакетов есть в 17.10". -- Best regards, Paul Arakelyan.
participants (12)
-
Alex Cherevko
-
Alexey Belinsky
-
Andrey Lakhno
-
Andriy Grytsenko
-
George L. Yermulnik
-
Michael Bochkaryov
-
Mykola Ulianytskyi
-
Oleh Hrynchuk
-
Paul Arakelyan
-
Pavlo Narozhnyy
-
Stesin
-
Volodymyr Litovka