Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 22
Годно. А жизнь нереальняа боль :D
перечитал еще раз, но таки не понял почему erlang.mk а не rebar?
rebar старый, большой, медленный и известный как мне, так и всем остальным. Ну и синтаксис конфика у него неудобный.
И если все равно нужно делать Makefile, зачем плодить конфигурационные сущности?
И если все равно нужно делать Makefile, зачем плодить конфигурационные сущности?
Спасибо.
Годно, но только вот насчёт дебиана ты неправ.
Flussonic собирается в дебиановские и rpm пакеты прям из под макоси одним единственным скриптом без всякой боли.
Flussonic собирается в дебиановские и rpm пакеты прям из под макоси одним единственным скриптом без всякой боли.
Дебиан — это не только устанавливающуюся дебку собрать, а еще и подписать ее и залить в репозиторий.
Кроме этого в epm я не нашел работы с changelog, адекватности которого хочется админам.
Но вообще хороша штука, да. Спасибо, что напомнил.
Кроме этого в epm я не нашел работы с changelog, адекватности которого хочется админам.
Но вообще хороша штука, да. Спасибо, что напомнил.
> подписать
поясни, пожалуйста. Я имплементил цифроподпись для rpm, но не для дебиана. Если надо, можно сделать и для дебки.
> залить в репозиторий
Я рассчитывал на простой репо, когда на сервере делаешь dpkg-scanpackages
> в epm я не нашел работы с changelog
Данил, да я тебе хоть коммит-права в репозиторий дам =) У меня ведется Changelog в умеренно примитивном виде, но опять же: это можно доделать, если будут либо пулл-реквесты, либо вменяемое описание проблемы. Я не знаю, что за проблема с changelog, потому что не знаю куда смотреть.
В отличие от проклятого rpm, у дебиана крайне простой и очень, очень правильный формат пакета. А rpm — гори огнём каждый человек, кто его хоть куда-то пропихивает. Это лютый ад. Проще распарсить виндовый реестр, чем работать с rpm!
поясни, пожалуйста. Я имплементил цифроподпись для rpm, но не для дебиана. Если надо, можно сделать и для дебки.
> залить в репозиторий
Я рассчитывал на простой репо, когда на сервере делаешь dpkg-scanpackages
> в epm я не нашел работы с changelog
Данил, да я тебе хоть коммит-права в репозиторий дам =) У меня ведется Changelog в умеренно примитивном виде, но опять же: это можно доделать, если будут либо пулл-реквесты, либо вменяемое описание проблемы. Я не знаю, что за проблема с changelog, потому что не знаю куда смотреть.
В отличие от проклятого rpm, у дебиана крайне простой и очень, очень правильный формат пакета. А rpm — гори огнём каждый человек, кто его хоть куда-то пропихивает. Это лютый ад. Проще распарсить виндовый реестр, чем работать с rpm!
Каноничная жизнь дебиан-пакета после правки исходников выглядит примерно так:
* Собрать сорцы в кучу
* Собрать дебку с бинарями
* Подписать сорцы (файл .dsc)
* Подписать бинарные дебки, сорцы и подпись сорцов (файл .changes)
* Залить результаты работы четырех предыдущих пунктов в репозиторий, настроенный в .dupload.conf
Epm сейчас справляется только со вторым пунктом, потому не годится в случае больших репозиториев (официальных или корпоративных).
Для того, чтобы дорабатывать его до совместимости со всем, что нужно, нужно потратить немало времени на исследования (в нерабочее время, естественно). Может, доберусь как-нибудь.
Я не собираюсь спорить с тем, что rpm внутри устроен как фантазии прыщавого школьника, недавно узнавшего про маршаллинг, Я говорил об инструментах, предлагаемых авторами дистрибутива. И тут rpmbuild оказывается проще в использовании, чем debuild.
* Собрать сорцы в кучу
* Собрать дебку с бинарями
* Подписать сорцы (файл .dsc)
* Подписать бинарные дебки, сорцы и подпись сорцов (файл .changes)
* Залить результаты работы четырех предыдущих пунктов в репозиторий, настроенный в .dupload.conf
Epm сейчас справляется только со вторым пунктом, потому не годится в случае больших репозиториев (официальных или корпоративных).
Для того, чтобы дорабатывать его до совместимости со всем, что нужно, нужно потратить немало времени на исследования (в нерабочее время, естественно). Может, доберусь как-нибудь.
Я не собираюсь спорить с тем, что rpm внутри устроен как фантазии прыщавого школьника, недавно узнавшего про маршаллинг, Я говорил об инструментах, предлагаемых авторами дистрибутива. И тут rpmbuild оказывается проще в использовании, чем debuild.
говорить про каноничную жизнь дебиан-пакета надо не со мной. Я ни за какие деньги этим идиотизмом заниматься бы не стал, для этого можно нанять людей, которые будут таким бессмысленным образом прожигать время.
Но конечная цель — получить deb-ку, которая может лечь в репо. Если админ не фанатичный пурист, то ты можешь здорово себе сэкономить время. А если админы фанатики, то да — беда. Тебе не повезло.
Но конечная цель — получить deb-ку, которая может лечь в репо. Если админ не фанатичный пурист, то ты можешь здорово себе сэкономить время. А если админы фанатики, то да — беда. Тебе не повезло.
Хотя я слабо понимаю, как альтернативный сборщик дебок может являться аргументом против «сборка пакетов под него сделана мутантами и для мутантов».
Еще боль: ошибка в, кажется, posinstall-скрипте ставит пакетный менеджер в состояние, из которого его можно вытащить только клещами, вонзившись в распакованный скрипт где-то в /var/lib/
И еще: у дебиана есть развитая система хелперов, которые раскрываются при сборке пакетов. Очень глюкавое, но иногда нужное поделие.
И еще: ни в дебиане, ни в редхате, кажется, до сих пор нет возможности декларативно сказать «этому пакету нужен такой юзер в такой группе». Приходится писать костыли из useradd, etc.
Еще боль: ошибка в, кажется, posinstall-скрипте ставит пакетный менеджер в состояние, из которого его можно вытащить только клещами, вонзившись в распакованный скрипт где-то в /var/lib/
И еще: у дебиана есть развитая система хелперов, которые раскрываются при сборке пакетов. Очень глюкавое, но иногда нужное поделие.
И еще: ни в дебиане, ни в редхате, кажется, до сих пор нет возможности декларативно сказать «этому пакету нужен такой юзер в такой группе». Приходится писать костыли из useradd, etc.
> как альтернативный сборщик дебок может являться аргументом против «сборка пакетов под него сделана мутантами и для мутантов».
Дебиановский путь сборки пакетов сделан мутантами для мутантов. Но ты можешь не пробивать лбом метровой толщины железобетонный забор, а зайти сбоку.
> Еще боль: ошибка в, кажется, posinstall-скрипте ставит пакетный менеджер в состояние
Да. Причем ответ на это как правило: переставьте систему.
> И еще: ни в дебиане, ни в редхате, кажется, до сих пор нет возможности декларативно сказать
на этих словах можно было бы поставить точку. Большинство нужных вещей копируются из скрипта в скрипт, хотя должны предоставляться базовым линуксом.
Дебиановский путь сборки пакетов сделан мутантами для мутантов. Но ты можешь не пробивать лбом метровой толщины железобетонный забор, а зайти сбоку.
> Еще боль: ошибка в, кажется, posinstall-скрипте ставит пакетный менеджер в состояние
Да. Причем ответ на это как правило: переставьте систему.
> И еще: ни в дебиане, ни в редхате, кажется, до сих пор нет возможности декларативно сказать
на этих словах можно было бы поставить точку. Большинство нужных вещей копируются из скрипта в скрипт, хотя должны предоставляться базовым линуксом.
Объясните для тех кто в танке чем REST отличается от RPC?
Representational state transfer (REST) is a way to create, read, update or delete information on a server using simple HTTP calls. It is an alternative to more complex mechanisms like SOAP, CORBA and RPC. A REST call is simply an HTTP request to the server.
Условно:
в RPC вы постите какой-то JSON/XML в один единственный HTTP endpoint, таким образом вы не пользуетесь всеми фичами HTTP для передачи бизнес-запросов
в REST вы пользуетесь разными урлами и разными Verb-ами для разных задач. Получение ресурса — GET уникальный урл, удаление ресурса DELETE уникальный урл.
Опять же авторизация: в RPC она как правило инкапсулирована внутрь сообщений, а в REST она идет на уровне HTTP.
Но есть пара но. SOAP валидируется и генерируется из валидируемого WSDL. Rest надо полностью писать ручками.
в RPC вы постите какой-то JSON/XML в один единственный HTTP endpoint, таким образом вы не пользуетесь всеми фичами HTTP для передачи бизнес-запросов
в REST вы пользуетесь разными урлами и разными Verb-ами для разных задач. Получение ресурса — GET уникальный урл, удаление ресурса DELETE уникальный урл.
Опять же авторизация: в RPC она как правило инкапсулирована внутрь сообщений, а в REST она идет на уровне HTTP.
Но есть пара но. SOAP валидируется и генерируется из валидируемого WSDL. Rest надо полностью писать ручками.
Тема правильного конфига не раскрыта.
Родной эрланговский конфиг файл совершенно нечеловеческий, отдавать админам его нельзя.
Можно конечно при старте приложения прочитать и распарсить конфиг файл в произвольном формате — хоть yaml, хоть init. Но возникает вопрос что делать, если в конфиге какие то проблемы. Изнутри релиза вывести что либо на stdout/stderr невозможно. Можно было бы записать ошибку в лог, но для этого лог уже должен быть правильно сконфигурирован.
Родной эрланговский конфиг файл совершенно нечеловеческий, отдавать админам его нельзя.
Можно конечно при старте приложения прочитать и распарсить конфиг файл в произвольном формате — хоть yaml, хоть init. Но возникает вопрос что делать, если в конфиге какие то проблемы. Изнутри релиза вывести что либо на stdout/stderr невозможно. Можно было бы записать ошибку в лог, но для этого лог уже должен быть правильно сконфигурирован.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кластерный сервис на Эрланге: от идеи до deb-пакета