info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Не запускается sshd в bullseye на виртуальной машине
44 views
Skip to first unread message
Misha Ramendik
Feb 14, 2024, 2:40:05 PMFeb 14
to
Всем привет!
Мне нужно собрать пакет для bullseye. У меня Федора. Ну, поднял VM с https://cloud.debian.org/images/cloud/bullseye/20240211-1654/debian-11-nocloud-amd64-20240211-1654.qcow2
Но консоль у qemu/virt-manager очень уж неудобная, ни clipboard, ничего. Хочу поднять sshd и работать с VM по ssh.
А не получается!
systemctl status ssh.service показывает кусок лога с ощибкой "ssh.service: Start request repeated too quickly". Полный лог скриншотом тут https://imgur.com/a/ZXFgelf , потому что у консоли virt-manager нет clipboard (из-за чего мне и нужен ssh).
Как это чинить?
--
Yours, Misha Ramendik
Unless explicitly stated, all opinions in my mail are my own and do not reflect the views of any organization
Unless explicitly stated, all opinions in my mail are my own and do not reflect the views of any organization
Anton Gorlov
Feb 14, 2024, 3:40:03 PMFeb 14
to
14.02.2024 23:12, Misha Ramendik пишет:
> Но не пускает. Permission denied (publickey).
>
> Пароль у рута есть, логиниться пытаюсь рутом. /root есть, /root/.ssh
> есть, принадлежат все руту. Что тут нужно сделать чтобы он стал пускать
> по ssh?
>
Вообще ходить рутом плохая идея by design
А так man sshd_config - > PermitRootLogin
> Но не пускает. Permission denied (publickey).
>
> Пароль у рута есть, логиниться пытаюсь рутом. /root есть, /root/.ssh
> есть, принадлежат все руту. Что тут нужно сделать чтобы он стал пускать
> по ssh?
>
Вообще ходить рутом плохая идея by design
А так man sshd_config - > PermitRootLogin
Victor Wagner
Feb 14, 2024, 3:50:04 PMFeb 14
to
В Wed, 14 Feb 2024 23:05:50 +0300
Anton Gorlov <sta...@locum.ru> пишет:
> 14.02.2024 23:12, Misha Ramendik пишет:
>
> > Но не пускает. Permission denied (publickey).
> >
> > Пароль у рута есть, логиниться пытаюсь рутом. /root есть,
> > /root/.ssh есть, принадлежат все руту. Что тут нужно сделать чтобы
> > он стал пускать по ssh?
> >
>
>
> Вообще ходить рутом плохая идея by design
Ну не факт что такая уж плохая идея. Есть случаи, когда без этого не
обойтись. Например чтобы забэкапить rsync-ом на удаленную машину.
(для этого у PermitRootLogin есть значение forced-commands-only)
К сожалению Торвальдс почему-то очень не любит программ, работающих с
дисковыми специальными устройствами помимо файловой системы, поэтому
dump (который именно так и бэкапит, и ему не нужен доступ ко всем
файлам, а только право на чтение специальных файлов в /dev) в linux был
сломан в незапамятные времена и чинить его не собирается.
Впрочем у dump есть свои security implication. Так что может Линус не
так и не прав.
Еще мне тут недавно надо было примонтировать большой раздел на /home на
сервере, расположенном в дата-центре
И соответственно для того, чтобы можно было выполнять административные
действия не занимая /home, я временно подложил authorized_keys в
/root/.ssh. Здесь конечно можно было рискнуть и переименовать старый
/home на лету. Но если бы между сдвигаанием в сторону старого /home и
монтированием нового что-то пошло не так, я бы обычным юзером туда не
зашел. Это как розетку чинить не выключая пробок. Лучше уж временно
разрешить рутом ходить.
--
Victor Wagner <vi...@wagner.pp.ru>
Anton Gorlov <sta...@locum.ru> пишет:
> 14.02.2024 23:12, Misha Ramendik пишет:
>
> > Но не пускает. Permission denied (publickey).
> >
> > Пароль у рута есть, логиниться пытаюсь рутом. /root есть,
> > /root/.ssh есть, принадлежат все руту. Что тут нужно сделать чтобы
> > он стал пускать по ssh?
> >
>
>
> Вообще ходить рутом плохая идея by design
обойтись. Например чтобы забэкапить rsync-ом на удаленную машину.
(для этого у PermitRootLogin есть значение forced-commands-only)
К сожалению Торвальдс почему-то очень не любит программ, работающих с
дисковыми специальными устройствами помимо файловой системы, поэтому
dump (который именно так и бэкапит, и ему не нужен доступ ко всем
файлам, а только право на чтение специальных файлов в /dev) в linux был
сломан в незапамятные времена и чинить его не собирается.
Впрочем у dump есть свои security implication. Так что может Линус не
так и не прав.
Еще мне тут недавно надо было примонтировать большой раздел на /home на
сервере, расположенном в дата-центре
И соответственно для того, чтобы можно было выполнять административные
действия не занимая /home, я временно подложил authorized_keys в
/root/.ssh. Здесь конечно можно было рискнуть и переименовать старый
/home на лету. Но если бы между сдвигаанием в сторону старого /home и
монтированием нового что-то пошло не так, я бы обычным юзером туда не
зашел. Это как розетку чинить не выключая пробок. Лучше уж временно
разрешить рутом ходить.
--
Victor Wagner <vi...@wagner.pp.ru>
Victor Wagner
Feb 14, 2024, 3:50:04 PMFeb 14
to
В Wed, 14 Feb 2024 20:12:04 +0000
Misha Ramendik <m...@ramendik.eu> пишет:
> Это удалось победить. Нагуглилось сделать /usr/bin/ssh-keygen -A и
> сервис взлетел.
публичному ключу и пароль даже не спрашивает, похоже что в
/etc/ssh/sshd_config запрещена PasswordAuthentication или вообще или
для рута.
На первом попавшемся контейнере с bullseye там имеется
закомментировананя строчка
#PermitRootLogin prohibit-password
По-моему закомментированные строчки в дистрибутивном sshd_config
содержат значения опций по умолчанию. А если так, то руту по паролю
нельзя.
Варианта три:
1. Раскоментарить эту строчку и поменять prohibit-password на yes
2. Завести нормального юзера с правом на sudo и забыть про то что можно
ходить рутом.
3. Как-то притащить на виртуальную машину authorized_keys и ходить по
ключу.
--
Victor Wagner <vi...@wagner.pp.ru>
Misha Ramendik <m...@ramendik.eu> пишет:
> Это удалось победить. Нагуглилось сделать /usr/bin/ssh-keygen -A и
> сервис взлетел.
>
> Но не пускает. Permission denied (publickey).
Поскольку оно английским по бэкграунду пишет, что запрещен доступ по
> Но не пускает. Permission denied (publickey).
публичному ключу и пароль даже не спрашивает, похоже что в
/etc/ssh/sshd_config запрещена PasswordAuthentication или вообще или
для рута.
На первом попавшемся контейнере с bullseye там имеется
закомментировананя строчка
#PermitRootLogin prohibit-password
По-моему закомментированные строчки в дистрибутивном sshd_config
содержат значения опций по умолчанию. А если так, то руту по паролю
нельзя.
Варианта три:
1. Раскоментарить эту строчку и поменять prohibit-password на yes
2. Завести нормального юзера с правом на sudo и забыть про то что можно
ходить рутом.
3. Как-то притащить на виртуальную машину authorized_keys и ходить по
ключу.
--
Victor Wagner <vi...@wagner.pp.ru>
Dmitrii Kashin
Feb 15, 2024, 5:50:04 AMFeb 15
to
> On 14 Feb 2024, at 22:33, Misha Ramendik <m...@ramendik.eu> wrote:
>
> Всем привет!
> Мне нужно собрать пакет для bullseye. У меня Федора.
Действительно ли Вы этого хотите?
Если стоит задача собрать пакет, так просто возьмите контейнер с bullseye.
Уж какой-нибудь docker, полагаю, на федоре найдётся.
Maksim Dmitrichenko
Feb 15, 2024, 11:10:04 AMFeb 15
to
Всю дорогу для этого хватало самого обыкновенного chroot. Вроде как для сборки deb-пакетов есть pbuilder - и он доступен в федорином горе.
With best regards
Maksim Dmitrichenko
Maksim Dmitrichenko
Victor Wagner
Feb 15, 2024, 1:20:05 PMFeb 15
to
В Thu, 15 Feb 2024 13:47:48 +0300
Dmitrii Kashin <fre...@gmail.com> пишет:
А протестирвать? Мы, например, на архитектуре x86_64 тестируем постгрес
исключительно в виртуалках. Потому как сетевой сервис, взаимодействует
с инитом и все такое. Тестировать лучше в системе имеющей полноценный
init/systemd и отдельный от хоста сетевой стек. Хотя собирать и правда
в schroot удобнее.
И еще кто сказал что архитектура процессора на хосте и в виртуалке
совпадает?
--
Victor Wagner <vi...@wagner.pp.ru>
Dmitrii Kashin <fre...@gmail.com> пишет:
исключительно в виртуалках. Потому как сетевой сервис, взаимодействует
с инитом и все такое. Тестировать лучше в системе имеющей полноценный
init/systemd и отдельный от хоста сетевой стек. Хотя собирать и правда
в schroot удобнее.
И еще кто сказал что архитектура процессора на хосте и в виртуалке
совпадает?
--
Victor Wagner <vi...@wagner.pp.ru>
Eugene Berdnikov
Feb 15, 2024, 1:50:03 PMFeb 15
to
On Thu, Feb 15, 2024 at 09:17:40PM +0300, Victor Wagner wrote:
> В Thu, 15 Feb 2024 13:47:48 +0300
> Dmitrii Kashin <fre...@gmail.com> пишет:
>
> > > On 14 Feb 2024, at 22:33, Misha Ramendik <m...@ramendik.eu> wrote:
> > >
> > > Всем привет!
> > > Мне нужно собрать пакет для bullseye. У меня Федора.
> > > Ну, поднял VM <...> Хочу поднять sshd и работать с VM по ssh.
> >
> > Действительно ли Вы этого хотите?
> > Если стоит задача собрать пакет, так просто возьмите контейнер с
> > bullseye. Уж какой-нибудь docker, полагаю, на федоре найдётся.
>
> А протестирвать? Мы, например, на архитектуре x86_64 тестируем постгрес
> исключительно в виртуалках. Потому как сетевой сервис, взаимодействует
> с инитом и все такое. Тестировать лучше в системе имеющей полноценный
> init/systemd и отдельный от хоста сетевой стек.
В контейнерах есть и свой init/systemd, и отдельный namespace для сети,
> В Thu, 15 Feb 2024 13:47:48 +0300
> Dmitrii Kashin <fre...@gmail.com> пишет:
>
> > > On 14 Feb 2024, at 22:33, Misha Ramendik <m...@ramendik.eu> wrote:
> > >
> > > Всем привет!
> > > Мне нужно собрать пакет для bullseye. У меня Федора.
> > > Ну, поднял VM <...> Хочу поднять sshd и работать с VM по ssh.
> >
> > Действительно ли Вы этого хотите?
> > Если стоит задача собрать пакет, так просто возьмите контейнер с
> > bullseye. Уж какой-нибудь docker, полагаю, на федоре найдётся.
>
> А протестирвать? Мы, например, на архитектуре x86_64 тестируем постгрес
> исключительно в виртуалках. Потому как сетевой сервис, взаимодействует
> с инитом и все такое. Тестировать лучше в системе имеющей полноценный
> init/systemd и отдельный от хоста сетевой стек.
позволяющий тестировать сетевые приложения. В этом смысле что docker,
что lxc -- пригодные для этого среды, а постгресс в плане сети и инита
ничего странного требовать не должен.
Ситуации, в которых контейнер не даёт делать полноценное тестирование,
встречаются нечасто. Например, с lvm в контейнере есть проблемы.
--
Eugene Berdnikov
Victor Wagner
Feb 15, 2024, 3:00:05 PMFeb 15
to
В Thu, 15 Feb 2024 21:39:42 +0300
Eugene Berdnikov <b...@protva.ru> пишет:
>
> В контейнерах есть и свой init/systemd, и отдельный namespace для
> сети, позволяющий тестировать сетевые приложения. В этом смысле что
> docker, что lxc -- пригодные для этого среды, а постгресс в плане
> сети и инита ничего странного требовать не должен.
В свое время пришллось очень сильно потрахаться в ситуациях когда на
хосте и в контейнере существенно разные версии systemd (или с одной
стороны systemd а с другой sysv init).
Вот как-то я рассказывал-рассказывал людям про то как под ОС МЦСТ
запустить в контейнере относительно свежий альтлинукс, они
послушали-послушали и сказали "нафиг эту МЦСТ, поставим альт на хост"
При том что там и тогда выхода не было. На "Эльбрусах" аппаратная
виртуализация начиная с Эльбрус 12. А то было 8С или 8СВ.
Поэтому только lxc.
> Ситуации, в которых контейнер не даёт делать полноценное
> тестирование, встречаются нечасто. Например, с lvm в контейнере есть
> проблемы.
НУ у нас например есть тесты требующе монтирования специальной тестовой
файловой системы через FUSE. Да. в конце концов удалоьс LXC запинать
чтобы он это делал.
А если у тебя GUI и нужно тестировать с X Window, Wayland и что там еще
нынче бывает?
--
Victor Wagner <vi...@wagner.pp.ru>
Eugene Berdnikov <b...@protva.ru> пишет:
>
> В контейнерах есть и свой init/systemd, и отдельный namespace для
> сети, позволяющий тестировать сетевые приложения. В этом смысле что
> docker, что lxc -- пригодные для этого среды, а постгресс в плане
> сети и инита ничего странного требовать не должен.
хосте и в контейнере существенно разные версии systemd (или с одной
стороны systemd а с другой sysv init).
Вот как-то я рассказывал-рассказывал людям про то как под ОС МЦСТ
запустить в контейнере относительно свежий альтлинукс, они
послушали-послушали и сказали "нафиг эту МЦСТ, поставим альт на хост"
При том что там и тогда выхода не было. На "Эльбрусах" аппаратная
виртуализация начиная с Эльбрус 12. А то было 8С или 8СВ.
Поэтому только lxc.
> Ситуации, в которых контейнер не даёт делать полноценное
> тестирование, встречаются нечасто. Например, с lvm в контейнере есть
> проблемы.
файловой системы через FUSE. Да. в конце концов удалоьс LXC запинать
чтобы он это делал.
А если у тебя GUI и нужно тестировать с X Window, Wayland и что там еще
нынче бывает?
--
Victor Wagner <vi...@wagner.pp.ru>
Eugene Berdnikov
Feb 15, 2024, 3:40:05 PMFeb 15
to
On Thu, Feb 15, 2024 at 10:50:22PM +0300, Victor Wagner wrote:
> В Thu, 15 Feb 2024 21:39:42 +0300
> Eugene Berdnikov <b...@protva.ru> пишет:
>
> > В контейнерах есть и свой init/systemd, и отдельный namespace для
> > сети, позволяющий тестировать сетевые приложения. В этом смысле что
> > docker, что lxc -- пригодные для этого среды, а постгресс в плане
> > сети и инита ничего странного требовать не должен.
>
> В свое время пришллось очень сильно потрахаться в ситуациях когда на
> хосте и в контейнере существенно разные версии systemd (или с одной
> стороны systemd а с другой sysv init).
Это другой вопрос. Речь шла о том, что для тестирования PG в плане
> В Thu, 15 Feb 2024 21:39:42 +0300
> Eugene Berdnikov <b...@protva.ru> пишет:
>
> > В контейнерах есть и свой init/systemd, и отдельный namespace для
> > сети, позволяющий тестировать сетевые приложения. В этом смысле что
> > docker, что lxc -- пригодные для этого среды, а постгресс в плане
> > сети и инита ничего странного требовать не должен.
>
> В свое время пришллось очень сильно потрахаться в ситуациях когда на
> хосте и в контейнере существенно разные версии systemd (или с одной
> стороны systemd а с другой sysv init).
запуска и работы с сетью нет причин требовать полной виртуализации.
> А если у тебя GUI и нужно тестировать с X Window, Wayland и что там еще
> нынче бывает?
проксироваться через unix-сокеты, например, через ssh. Практически же
я неоднократно наблюдал с этим проблемы у Firefox и Libreoffice.
Но я думаю, что там что-то ломали в либах... Времени и желания
разбираться не было, другие приложения работали нормально. Так что
GUI вполне можно отлаживать в контейнерах, если не хотеть экзотики,
вроде прямой работы с видеокартой, аппаратного ускорения и т.п.
--
Eugene Berdnikov
Misha Ramendik
Feb 15, 2024, 7:10:04 PMFeb 15
to
On Thu, 15 Feb 2024 at 10:48, Dmitrii Kashin <fre...@gmail.com> wrote:
Действительно ли Вы этого хотите?
Если стоит задача собрать пакет, так просто возьмите контейнер с bullseye.
Уж какой-нибудь docker, полагаю, на федоре найдётся.
Всё очень просто. С контейнером пришлось бы разбираться, как прикручивать ему persistent storage, чтобы не качать заново все дополнительные пакеты для каждой новой сборки (пока было две, может ещё случиться, всё только для себя - у меня есть VPS на bullseye). И с обменом файлами между контейнером и хостом (собранное желательно куда-то деть). Я имел дело с контейнерами - но не с вот этими вот квестами, а только CI/CD в котором всё совсем просто. Есть кого спросить про контейнеры - но на VM это всё не нужно. Мне своё время жалко, а ресурсы машины на VM - нет.
sshd побеждён не без помощи рассылки, всё уже работает, всё спокойно собирается. pbuilder не побеждён, но оно и не надо, хватает dpkg-checkbuilddeps и debuild.
Victor Wagner
Feb 16, 2024, 12:40:05 AMFeb 16
to
В Thu, 15 Feb 2024 23:33:31 +0300
нужна поддержка на уровне ядра.
А эти системы бывают разные. Ну вот откуда в дебиановском ядре
поддержка астровского parsec.
Ну и про тесты использущие специфическую FUSE-файловую систему я уже
упоминал. Это тоже связано с защитой данных - мы так проверяем что
удаленные данные действительно исчезли с диска.
(а уж как тестируется зачистка удаленных данных из RAM, это вообще
песня)
> > А если у тебя GUI и нужно тестировать с X Window, Wayland и что там
> > еще нынче бывает?
>
> Теоретически X Window, Wayland & Ко должны уметь работать по tcp и
> проксироваться через unix-сокеты, например, через ssh. Практически же
> я неоднократно наблюдал с этим проблемы у Firefox и Libreoffice.
> Но я думаю, что там что-то ломали в либах... Времени и желания
Вот вот. В теории нет различий между теорией и практикой. а на практике
ого-го какие различия.
--
Victor Wagner <vi...@wagner.pp.ru>
Eugene Berdnikov <b...@protva.ru> пишет:
> On Thu, Feb 15, 2024 at 10:50:22PM +0300, Victor Wagner wrote:
> > В Thu, 15 Feb 2024 21:39:42 +0300
> > Eugene Berdnikov <b...@protva.ru> пишет:
> >
> > > В контейнерах есть и свой init/systemd, и отдельный namespace для
> > > сети, позволяющий тестировать сетевые приложения. В этом смысле
> > > что docker, что lxc -- пригодные для этого среды, а постгресс в
> > > плане сети и инита ничего странного требовать не должен.
> >
> > В свое время пришллось очень сильно потрахаться в ситуациях когда на
> > хосте и в контейнере существенно разные версии systemd (или с одной
> > стороны systemd а с другой sysv init).
>
> Это другой вопрос. Речь шла о том, что для тестирования PG в плане
> запуска и работы с сетью нет причин требовать полной виртуализации.
>
Есть причины. Как только речь заходит о системах мандатного доступа,
> On Thu, Feb 15, 2024 at 10:50:22PM +0300, Victor Wagner wrote:
> > В Thu, 15 Feb 2024 21:39:42 +0300
> > Eugene Berdnikov <b...@protva.ru> пишет:
> >
> > > В контейнерах есть и свой init/systemd, и отдельный namespace для
> > > сети, позволяющий тестировать сетевые приложения. В этом смысле
> > > что docker, что lxc -- пригодные для этого среды, а постгресс в
> > > плане сети и инита ничего странного требовать не должен.
> >
> > В свое время пришллось очень сильно потрахаться в ситуациях когда на
> > хосте и в контейнере существенно разные версии systemd (или с одной
> > стороны systemd а с другой sysv init).
>
> Это другой вопрос. Речь шла о том, что для тестирования PG в плане
> запуска и работы с сетью нет причин требовать полной виртуализации.
>
нужна поддержка на уровне ядра.
А эти системы бывают разные. Ну вот откуда в дебиановском ядре
поддержка астровского parsec.
Ну и про тесты использущие специфическую FUSE-файловую систему я уже
упоминал. Это тоже связано с защитой данных - мы так проверяем что
удаленные данные действительно исчезли с диска.
(а уж как тестируется зачистка удаленных данных из RAM, это вообще
песня)
> > А если у тебя GUI и нужно тестировать с X Window, Wayland и что там
> > еще нынче бывает?
>
> Теоретически X Window, Wayland & Ко должны уметь работать по tcp и
> проксироваться через unix-сокеты, например, через ssh. Практически же
> я неоднократно наблюдал с этим проблемы у Firefox и Libreoffice.
> Но я думаю, что там что-то ломали в либах... Времени и желания
ого-го какие различия.
--
Victor Wagner <vi...@wagner.pp.ru>
Eugene Berdnikov
Feb 16, 2024, 1:00:04 AMFeb 16
to
On Fri, Feb 16, 2024 at 08:35:28AM +0300, Victor Wagner wrote:
> В Thu, 15 Feb 2024 23:33:31 +0300
> Eugene Berdnikov <b...@protva.ru> пишет:
>
> В Thu, 15 Feb 2024 23:33:31 +0300
> Eugene Berdnikov <b...@protva.ru> пишет:
>
> > > В свое время пришллось очень сильно потрахаться в ситуациях когда на
> > > хосте и в контейнере существенно разные версии systemd (или с одной
> > > стороны systemd а с другой sysv init).
> >
> > Это другой вопрос. Речь шла о том, что для тестирования PG в плане
> > запуска и работы с сетью нет причин требовать полной виртуализации.
> >
>
> Есть причины. Как только речь заходит о системах мандатного доступа,
> нужна поддержка на уровне ядра.
>
> А эти системы бывают разные. Ну вот откуда в дебиановском ядре
> поддержка астровского parsec.
>
> Ну и про тесты использущие специфическую FUSE-файловую систему я уже
> упоминал. Это тоже связано с защитой данных - мы так проверяем что
> удаленные данные действительно исчезли с диска.
> (а уж как тестируется зачистка удаленных данных из RAM, это вообще
> песня)
Ну и при чём тут инициализация и сеть в постгресе? Не при чём,
> > > хосте и в контейнере существенно разные версии systemd (или с одной
> > > стороны systemd а с другой sysv init).
> >
> > Это другой вопрос. Речь шла о том, что для тестирования PG в плане
> > запуска и работы с сетью нет причин требовать полной виртуализации.
> >
>
> Есть причины. Как только речь заходит о системах мандатного доступа,
> нужна поддержка на уровне ядра.
>
> А эти системы бывают разные. Ну вот откуда в дебиановском ядре
> поддержка астровского parsec.
>
> Ну и про тесты использущие специфическую FUSE-файловую систему я уже
> упоминал. Это тоже связано с защитой данных - мы так проверяем что
> удаленные данные действительно исчезли с диска.
> (а уж как тестируется зачистка удаленных данных из RAM, это вообще
> песня)
поскольку виртуализации требует нечто, к постгресу прямо не относящееся.
Не обманывайте подписчиков рассылки!
> > > А если у тебя GUI и нужно тестировать с X Window, Wayland и что там
> > > еще нынче бывает?
> >
> > Теоретически X Window, Wayland & Ко должны уметь работать по tcp и
> > проксироваться через unix-сокеты, например, через ssh. Практически же
> > я неоднократно наблюдал с этим проблемы у Firefox и Libreoffice.
> > Но я думаю, что там что-то ломали в либах... Времени и желания
>
> Вот вот. В теории нет различий между теорией и практикой. а на практике
> ого-го какие различия.
тестирование гуя в контейнере.
--
Eugene Berdnikov
Eugene Berdnikov
Feb 16, 2024, 3:00:05 AMFeb 16
to
On Fri, Feb 16, 2024 at 12:04:49AM +0000, Misha Ramendik wrote:
> On Thu, 15 Feb 2024 at 10:48, Dmitrii Kashin <fre...@gmail.com> wrote:
>
> > Действительно ли Вы этого хотите?
> > Если стоит задача собрать пакет, так просто возьмите контейнер с
> > bullseye.
> > Уж какой-нибудь docker, полагаю, на федоре найдётся.
>
> Всё очень просто. С контейнером пришлось бы разбираться, как прикручивать
> ему persistent storage, чтобы не качать заново все дополнительные пакеты
> для каждой новой сборки (пока было две, может ещё случиться, всё только
> для себя - у меня есть VPS на bullseye). И с обменом файлами между
> контейнером и хостом (собранное желательно куда-то деть).
Для меня это было одной из главных причин, по которым docker пошёл на.
> On Thu, 15 Feb 2024 at 10:48, Dmitrii Kashin <fre...@gmail.com> wrote:
>
> > Действительно ли Вы этого хотите?
> > Если стоит задача собрать пакет, так просто возьмите контейнер с
> > bullseye.
> > Уж какой-нибудь docker, полагаю, на федоре найдётся.
>
> Всё очень просто. С контейнером пришлось бы разбираться, как прикручивать
> ему persistent storage, чтобы не качать заново все дополнительные пакеты
> для каждой новой сборки (пока было две, может ещё случиться, всё только
> для себя - у меня есть VPS на bullseye). И с обменом файлами между
> контейнером и хостом (собранное желательно куда-то деть).
С lxc всё намного проще и удобней, файлы доступны напрямую в отдельном
каталоге. Правда, с lxc тоже нужно разбираться, хотя бы с созданием
исходного образа, в то время как операции с VM в полностью виртуализованной
среде всем знакомы и привычны.
> Я имел дело с
> контейнерами - но не с вот этими вот квестами, а только CI/CD в котором
> всё совсем просто. Есть кого спросить про контейнеры - но на VM это всё не
> нужно. Мне своё время жалко, а ресурсы машины на VM - нет.
--
Eugene Berdnikov
Dmitrii Kashin
Feb 16, 2024, 3:20:04 AMFeb 16
to
Уж какой-нибудь docker, полагаю, на федоре найдётся.Всю дорогу для этого хватало самого обыкновенного chroot. Вроде как для сборки deb-пакетов есть pbuilder - и он доступен в федорином горе.
Chroot конечно хорошо, но всё одно придётся систему дебутстрапить. Я так раньше делал, и это не особо удобно. С появлением же контейнеров всё стало проще, ибо всё свелось к "docker pull debian:bullseye".
PS: pbuilder, кстати, тоже хороший вариант, тредстартеру на заметку
Dmitrii Kashin
Feb 16, 2024, 3:30:05 AMFeb 16
to
> On 15 Feb 2024, at 21:17, Victor Wagner <vi...@wagner.pp.ru> wrote:
>
> В Thu, 15 Feb 2024 13:47:48 +0300
> Dmitrii Kashin <fre...@gmail.com> пишет:
>
>>> On 14 Feb 2024, at 22:33, Misha Ramendik <m...@ramendik.eu> wrote:
>>>
>>> Всем привет!
>>> Мне нужно собрать пакет для bullseye. У меня Федора.
>>> Ну, поднял VM <...> Хочу поднять sshd и работать с VM по ssh.
>>
>> Действительно ли Вы этого хотите?
>> Если стоит задача собрать пакет, так просто возьмите контейнер с
>> bullseye. Уж какой-нибудь docker, полагаю, на федоре найдётся.
>>
>
> init/systemd и отдельный от хоста сетевой стек.
Довольно мало софта действительно нуждаются в наличии полноценного инита в контейнере.
В 95% случаев для теста хватает контейнера.
>
> И еще кто сказал что архитектура процессора на хосте и в виртуалке
> совпадает?
Dmitrii Kashin
Feb 16, 2024, 4:00:04 AMFeb 16
to
On 16 Feb 2024, at 03:04, Misha Ramendik <m...@ramendik.eu> wrote:С контейнером пришлось бы разбираться, как прикручивать ему persistent storage <...>
Мне своё время жалко, а ресурсы машины на VM - нет.
Сдаётся мне, Вы уже потратили гораздо больше времени, чем заняла бы реализация сборки пакета в контейнере вместе со чтением документации, как контейнеры работают. Впрочем, это Ваше право.
Victor Wagner
Feb 16, 2024, 8:50:04 AMFeb 16
to
В Fri, 16 Feb 2024 16:17:18 +0300
Dmitrii Kashin <fre...@gmail.com> пишет:
> А по существу, что ни выбери -- всё равно надо либо делать базовый
> образ с builddeps, либо каждый раз ждать, пока всё поставится. Докер
> ли, виртуалка ли... Pbuilder даже, и тот имеет архив с базовым
> имиджем. И он тоже потратит время, чтобы туда зависимости доставить.
> Без этого никуда.
И это хорошо и правильно, это гарантирует что все зависимости правильно
прописаны в debian/control. А если собирать пакет в рабочей системе, то
можешь запросто налететь на то, что-то забыл прописать, а пакет молча
собрался потому что у тебя-то — разработчика оно и так стоит.
А потом кто-то пересобрать попробует и у него не соберется.
Вот например такой пример. Собирал я сегодня допустим postgis для
bookworm. Это такая добрая штука, у него каких только зависимостей нет
apt говорит
4 upgraded, 415 newly installed, 0 to remove and 9 not upgraded.
Need to get 657 MB of archives.
(это базовый образ отрефрешить надо там 4 пакета обновились).
Все задание полностью, включая сборку и публикацию заняло 7 минут 24
секунды.
У почти любого другого пакета количество зависимостей будет сильно
меньше. Стоит ли ради этих единиц минут что-то экономить?
Ну конечно у меня оно эти 657Мб качало с локального миррора в той же
стойке.
--
Victor Wagner <vi...@wagner.pp.ru>
Dmitrii Kashin <fre...@gmail.com> пишет:
> А по существу, что ни выбери -- всё равно надо либо делать базовый
> образ с builddeps, либо каждый раз ждать, пока всё поставится. Докер
> ли, виртуалка ли... Pbuilder даже, и тот имеет архив с базовым
> имиджем. И он тоже потратит время, чтобы туда зависимости доставить.
> Без этого никуда.
И это хорошо и правильно, это гарантирует что все зависимости правильно
прописаны в debian/control. А если собирать пакет в рабочей системе, то
можешь запросто налететь на то, что-то забыл прописать, а пакет молча
собрался потому что у тебя-то — разработчика оно и так стоит.
А потом кто-то пересобрать попробует и у него не соберется.
Вот например такой пример. Собирал я сегодня допустим postgis для
bookworm. Это такая добрая штука, у него каких только зависимостей нет
apt говорит
4 upgraded, 415 newly installed, 0 to remove and 9 not upgraded.
Need to get 657 MB of archives.
(это базовый образ отрефрешить надо там 4 пакета обновились).
Все задание полностью, включая сборку и публикацию заняло 7 минут 24
секунды.
У почти любого другого пакета количество зависимостей будет сильно
меньше. Стоит ли ради этих единиц минут что-то экономить?
Ну конечно у меня оно эти 657Мб качало с локального миррора в той же
стойке.
--
Victor Wagner <vi...@wagner.pp.ru>
Dmitrii Kashin
Feb 16, 2024, 9:10:05 AMFeb 16
to
> On 16 Feb 2024, at 16:47, Victor Wagner <vi...@wagner.pp.ru> wrote:
>
> В Fri, 16 Feb 2024 16:17:18 +0300
> Dmitrii Kashin <fre...@gmail.com> пишет:
>
>> А по существу, что ни выбери -- всё равно надо либо делать базовый
>> образ с builddeps, либо каждый раз ждать, пока всё поставится. Докер
>> ли, виртуалка ли... Pbuilder даже, и тот имеет архив с базовым
>> имиджем. И он тоже потратит время, чтобы туда зависимости доставить.
>> Без этого никуда.
>
> И это хорошо и правильно
Если сборки частые -- то есть большая разница, занимает она семь минут или одну (помножаем на число сборок в день, получаем количество сэкономленного времени.
Если собирается что-нибудь явовское -- есть смысл подключать кэширование для зависимостей maven-а (их бывает очень, очень много; так что тезис о том, что крайне редко пакет имеет 657 метров зависимостей -- не вполне верен).
Если у сети ограниченный канал (например в силу юридических причин производство релоцировалось в КЗ, что нынче не редкость) -- тоже.
> Ну конечно у меня оно эти 657Мб качало с локального миррора в той же
> стойке.
Обычная DevOps-практика, в общем, заключается в том, что мы либо готовим базовый имидж на регулярной основе, так что он всегда свежий, к примеру, в течение дня; либо устанавливаем кэширующие сервера/зеркала с тем же умыслом. Обычно этого хватает. Особенно с учётом частоты обновления публичных зеркал дебиана.
Victor Wagner
Feb 16, 2024, 10:10:04 AMFeb 16
to
В Fri, 16 Feb 2024 17:07:11 +0300
Dmitrii Kashin <fre...@gmail.com> пишет:
>
достался работающий софт, после сборки запускают тесты. И тесты эти
работают часы, в лучшем случае десятки минут. Если у тебя тест сьют
занимает два часа, выигрыш шести минут на сборке абсолютно не важен.
А если у тебя тесты не занимают в 10-100 раз больше времени, чем
сборка, значит хреново твой пакет тестами покрыт.
>
> Это кстати тоже в пункт о "положении билд-серверов в сети". Где-то
> есть локальный миррор, где-то нет его.
Я от своих сотрудников всегда требую чтобы прерывание пьяным
экскаваторщиком оптоволоконного кабеля перед входом в датацентр, не
являлось поводом к несрабатыванию сборок и тестов по таймеру.
А то никогда не знаешь, где найдешь где потеряешь. То ли зарубежный
сайт перестанет пускать с российских IP, то ли роскомнадзор xml.org
заблокирует.
> Обычная DevOps-практика, в общем, заключается в том, что мы либо
Мы к счастью не девопсы, мы нормальная софтверная фирма. и производим
продукт который может использоваться не только на наших же серверах.
А к идее девопса (собаки оборотня меняющей пол вместе с ипостасью) я
испытваю глубокое отвращение.
Либо ты (программирующий) пользователь и не зарекайся на большее, либо
таки научись быть нормальным разработчиком и дистрибьютором.
--
Victor Wagner <vi...@wagner.pp.ru>
Dmitrii Kashin <fre...@gmail.com> пишет:
>
> Если сборки частые -- то есть большая разница, занимает она семь
> минут или одну (помножаем на число сборок в день, получаем количество
> сэкономленного времени. Если собирается что-нибудь явовское -- есть
Нет разницы. Потому что нормальные люди, которые хотят чтобы клиентам
> минут или одну (помножаем на число сборок в день, получаем количество
> сэкономленного времени. Если собирается что-нибудь явовское -- есть
достался работающий софт, после сборки запускают тесты. И тесты эти
работают часы, в лучшем случае десятки минут. Если у тебя тест сьют
занимает два часа, выигрыш шести минут на сборке абсолютно не важен.
А если у тебя тесты не занимают в 10-100 раз больше времени, чем
сборка, значит хреново твой пакет тестами покрыт.
>
> Это кстати тоже в пункт о "положении билд-серверов в сети". Где-то
> есть локальный миррор, где-то нет его.
экскаваторщиком оптоволоконного кабеля перед входом в датацентр, не
являлось поводом к несрабатыванию сборок и тестов по таймеру.
А то никогда не знаешь, где найдешь где потеряешь. То ли зарубежный
сайт перестанет пускать с российских IP, то ли роскомнадзор xml.org
заблокирует.
> Обычная DevOps-практика, в общем, заключается в том, что мы либо
продукт который может использоваться не только на наших же серверах.
А к идее девопса (собаки оборотня меняющей пол вместе с ипостасью) я
испытваю глубокое отвращение.
Либо ты (программирующий) пользователь и не зарекайся на большее, либо
таки научись быть нормальным разработчиком и дистрибьютором.
--
Victor Wagner <vi...@wagner.pp.ru>
Eugene Berdnikov
Feb 16, 2024, 10:40:04 AMFeb 16
to
On Fri, Feb 16, 2024 at 06:09:27PM +0300, Victor Wagner wrote:
> В Fri, 16 Feb 2024 17:07:11 +0300
> Dmitrii Kashin <fre...@gmail.com> пишет:
>
> > Если сборки частые -- то есть большая разница, занимает она семь
> > минут или одну (помножаем на число сборок в день, получаем количество
> > сэкономленного времени. Если собирается что-нибудь явовское -- есть
>
> Нет разницы. Потому что нормальные люди, которые хотят чтобы клиентам
> достался работающий софт, после сборки запускают тесты.
Бывает, что тест нагружает дисковую подсистему. И тут разница между
> В Fri, 16 Feb 2024 17:07:11 +0300
> Dmitrii Kashin <fre...@gmail.com> пишет:
>
> > Если сборки частые -- то есть большая разница, занимает она семь
> > минут или одну (помножаем на число сборок в день, получаем количество
> > сэкономленного времени. Если собирается что-нибудь явовское -- есть
>
> Нет разницы. Потому что нормальные люди, которые хотят чтобы клиентам
> достался работающий софт, после сборки запускают тесты.
контейнером и виртуалкой, которая эмулирует диск, становится очень
даже заметной.
Думаю, это должно особенно доставлять тогда, когда нет возможности
запихнуть этот тест в файловую систему в оперативке -- например,
потому что "не лезет", т.к. места на диске нужно слишком много.
--
Eugene Berdnikov
Misha Ramendik
Feb 16, 2024, 11:20:04 AMFeb 16
to
On Fri, 16 Feb 2024 at 15:37, Eugene Berdnikov <b...@protva.ru> wrote:
On Fri, Feb 16, 2024 at 06:09:27PM +0300, Victor Wagner wrote:
Бывает, что тест нагружает дисковую подсистему. И тут разница между
контейнером и виртуалкой, которая эмулирует диск, становится очень
даже заметной.
У меня всё проще, я собирал и тестировал FTP серверы. Включая то как они вкрячиваются в systemd и как они слушают порт 21. Сетапить всё это в контейнере - ну можно наверное разобраться, но зачем, когда в виртуалке всё работает из коробки? Ну, кроме того sshd, которого не было в официальной виртуалке, но я ж его уже починил давно, не без помощи отсюда.
Dmitrii Kashin
Feb 16, 2024, 12:00:04 PMFeb 16
to
> В Fri, 16 Feb 2024 17:07:11 +0300
> Dmitrii Kashin <fre...@gmail.com> пишет:
>
>> Если сборки частые -- то есть большая разница, занимает она семь
>> минут или одну (помножаем на число сборок в день, получаем количество
>> сэкономленного времени. Если собирается что-нибудь явовское -- есть
>
> Нет разницы. Потому что нормальные люди, которые хотят чтобы клиентам
> достался работающий софт, после сборки запускают тесты. И тесты эти
> работают часы, в лучшем случае десятки минут. Если у тебя тест сьют
> занимает два часа, выигрыш шести минут на сборке абсолютно не важен.
> А если у тебя тесты не занимают в 10-100 раз больше времени, чем
> сборка, значит хреново твой пакет тестами покрыт.
Что бы сказал Фредерик Брукс на такое расточительство? =)
> Dmitrii Kashin <fre...@gmail.com> пишет:
>
>> Если сборки частые -- то есть большая разница, занимает она семь
>> минут или одну (помножаем на число сборок в день, получаем количество
>> сэкономленного времени. Если собирается что-нибудь явовское -- есть
>
> Нет разницы. Потому что нормальные люди, которые хотят чтобы клиентам
> достался работающий софт, после сборки запускают тесты. И тесты эти
> работают часы, в лучшем случае десятки минут. Если у тебя тест сьют
> занимает два часа, выигрыш шести минут на сборке абсолютно не важен.
> А если у тебя тесты не занимают в 10-100 раз больше времени, чем
> сборка, значит хреново твой пакет тестами покрыт.
А если серьёзно, Вы почему-то делаете предположение, что у нас нет нормальных тест-сьютов. Но это ошибочно.
Если мы будем полный тест-сьют на каждую сборку запускать, то вы же, разработчики, первые прибежите с претензиями "а что так долго сборку ждать, я никак таску не могу закрыть, а с меня уже требуют".
В общем, обычно в фичбранче прогоняются только юнит-тесты, а полный тест-сьют запускает уже QA перед мерджем.
>> Это кстати тоже в пункт о "положении билд-серверов в сети". Где-то
>> есть локальный миррор, где-то нет его.
>
> Я от своих сотрудников всегда требую чтобы прерывание пьяным
> экскаваторщиком оптоволоконного кабеля перед входом в датацентр, не
> являлось поводом к несрабатыванию сборок и тестов по таймеру.
Бывает, что у бизнеса нет денег на аренду необходимого для этого количества ресурсов.
Бывает, что бизнес не видит в этом необходимости, то есть ему необходимо ощутить боль, чтобы понять, зачем это нужно.
И я как представитель эксплуатации сталкиваюсь с подобным отношением весьма часто.
>> Обычная DevOps-практика, в общем, заключается в том, что мы либо
>
> Мы к счастью не девопсы, мы нормальная софтверная фирма. и производим
> продукт который может использоваться не только на наших же серверах.
Например, почему нет официального решения для построения HA-кластера?
Или почему есть официальная тулза для promote, а для demote -- нету?
Почему basebackup добавляет в файл автоконфигурации (в котором большими буквами написано, что его нельзя редактировать руками) строчку conninfo, а старую не удаляет?
И это только по поверхности. Мелкие нюансы, от которых пользователям Вашего продукта бывает больно, Виктор.
На устранении этих нюансов и очеловечивании Вашего продукта у компании Percona серьёзный востребованный на рынке бизнес построен, между прочим.
> А к идее девопса (собаки оборотня меняющей пол вместе с ипостасью) я
> испытваю глубокое отвращение.
>
> Либо ты (программирующий) пользователь и не зарекайся на большее, либо
> таки научись быть нормальным разработчиком и дистрибьютором.
Dmitrii Kashin
Feb 16, 2024, 1:00:04 PMFeb 16
to
> On 16 Feb 2024, at 18:37, Eugene Berdnikov <b...@protva.ru> wrote:
>
> On Fri, Feb 16, 2024 at 06:09:27PM +0300, Victor Wagner wrote:
>> В Fri, 16 Feb 2024 17:07:11 +0300
>> Dmitrii Kashin <fre...@gmail.com> пишет:
>>
>>> Если сборки частые -- то есть большая разница, занимает она семь
>>> минут или одну (помножаем на число сборок в день, получаем количество
>>> сэкономленного времени. Если собирается что-нибудь явовское -- есть
>>
>> Нет разницы. Потому что нормальные люди, которые хотят чтобы клиентам
>> достался работающий софт, после сборки запускают тесты.
>
> Бывает, что тест нагружает дисковую подсистему. И тут разница между
> контейнером и виртуалкой, которая эмулирует диск, становится очень
> даже заметной.
Комплекты тестов, проверяющие утилизацию реальных ресурсов, обычно выносятся в отдельный тест-сьют и гоняются на специально подготовленных для них хардварных окружениях.
Ну ладно, может не "обычно", а "следует". Так-то обезьян в девопс много (как, впрочем, и в разработке).
Victor Wagner
Feb 17, 2024, 3:10:04 AMFeb 17
to
В Fri, 16 Feb 2024 10:59:25 +0300
Eugene Berdnikov <b...@protva.ru> пишет:
> > И с обменом файлами между контейнером и хостом (собранное
> > желательно куда-то деть).
>
> Для меня это было одной из главных причин, по которым docker пошёл
> на. С lxc всё намного проще и удобней, файлы доступны напрямую в
Докер - слишком overengineered. Ну собственно как и любое решение
набравшее популярность в массах. Меня например в нем больше всего
раздражает его желание по умолчанию использовать гугловские DNS а не
хостовые (откуда гугль знает про миррор в коапроативной сети. куда
контейнеру надо за пакетами ходить) и попытка править хостовый файрволл,
которая приводит к неработоспосбности на той же машине других систем
контейнеризации.
> отдельном каталоге. Правда, с lxc тоже нужно разбираться, хотя бы с
> созданием исходного образа, в то время как операции с VM в полностью
По-моему начиная с 4-й версии в lxc появился темплейт oci, который
позволяет паразитировать на докерном коммьюнити и качать образы для
контейнеров с докерхаба.
Но вот если готового образа контейнера на докерахбе нет, что скорее
правило, чем исключение для всяких отечественных дистрибутивов, то
конечно поставиться родным инсталлятором в виртуалку - проще.
Мы иногда так делаем - ставим виртуалку, потом через qemu-nbd
копируем ее файловую систему и делаем lxc-контейнеры. Хотя они тогда
огромные получаются - с GUI и все такое. Если типичный размер
контейнера созданного debootstrap, dnf или аналогами - полгига, то
типичный контейнер созданный путем копирования виртуалки - полтора-два.
--
Victor Wagner <vi...@wagner.pp.ru>
Eugene Berdnikov <b...@protva.ru> пишет:
> > И с обменом файлами между контейнером и хостом (собранное
> > желательно куда-то деть).
>
> Для меня это было одной из главных причин, по которым docker пошёл
> на. С lxc всё намного проще и удобней, файлы доступны напрямую в
набравшее популярность в массах. Меня например в нем больше всего
раздражает его желание по умолчанию использовать гугловские DNS а не
хостовые (откуда гугль знает про миррор в коапроативной сети. куда
контейнеру надо за пакетами ходить) и попытка править хостовый файрволл,
которая приводит к неработоспосбности на той же машине других систем
контейнеризации.
> отдельном каталоге. Правда, с lxc тоже нужно разбираться, хотя бы с
> созданием исходного образа, в то время как операции с VM в полностью
позволяет паразитировать на докерном коммьюнити и качать образы для
контейнеров с докерхаба.
Но вот если готового образа контейнера на докерахбе нет, что скорее
правило, чем исключение для всяких отечественных дистрибутивов, то
конечно поставиться родным инсталлятором в виртуалку - проще.
Мы иногда так делаем - ставим виртуалку, потом через qemu-nbd
копируем ее файловую систему и делаем lxc-контейнеры. Хотя они тогда
огромные получаются - с GUI и все такое. Если типичный размер
контейнера созданного debootstrap, dnf или аналогами - полгига, то
типичный контейнер созданный путем копирования виртуалки - полтора-два.
--
Victor Wagner <vi...@wagner.pp.ru>
Victor Wagner
Feb 17, 2024, 3:20:05 AMFeb 17
to
В Fri, 16 Feb 2024 19:59:17 +0300
Dmitrii Kashin <fre...@gmail.com> пишет:
> Что бы сказал Фредерик Брукс на такое расточительство? =)
Фредерик Брукс нам еще ответит за украденный 32-бит из архитектуры s390;-)
(почему-то и спарк и power и arm 32-битные, а IBM-овские мейнфреймы -
31 битные)
>
> А если серьёзно, Вы почему-то делаете предположение, что у нас нет
> нормальных тест-сьютов. Но это ошибочно. Если мы будем полный
> тест-сьют на каждую сборку запускать, то вы же, разработчики, первые
> прибежите с претензиями "а что так долго сборку ждать, я никак таску
> не могу закрыть, а с меня уже требуют". В общем, обычно в фичбранче
> прогоняются только юнит-тесты, а полный тест-сьют запускает уже QA
> перед мерджем.
Мы тут не про разработчиков, мы тут про мейнтейнеров пакетов.
Это разные роли, и их должны исполнять разные люди. Во всяком случае в
отношении одного и того же пакета.
Поэтому я, кстати, никогда не пытался стать мейнтейнером своих
программ, которые попали в Debian. Потому что им я разработчик, а не
мейнтейнер.
Как сказал Эрик Раймонд, "Given enough eyeballs all bugs are shallow".
Вот одна пара - это точно не enough. Поэтому вторая пара глаз -
мейнтейнера, который смотрит на код с другой точки зрения, чем
разработчик, необходима.
У разработчика на машине, и даже на общем для команды разработчиков VCS
хосте где запускаются тесты на коммиты во фича-ветки, совершенно не
обязательно иметь чистую среду. Там все -dev пакеты могут быть заранее
поставлены. Но у них там будет от силы пяток разных сред. Именно в силу
необходимости балансирования скорости прогона и широты покрытия.
А вот на этапе пакетирования, где контролируется правильность написания
spec или debian/control - там нужны воспроизводимые билды в
воспроизводимой среде.
И тестовые среды тоже должны быть воспроизводимыми. Раскатываться из
архива образов перед каждым запуском.
И здесь уже будет 30 дистрибутивов для 5 аппаратных архитектур.
Впрочем у нас еще есть между этими двумя стадиями промежуточная, где
максимальная широта охвата, то есть тестируются даже системы которые мы
не поддерживаем и поддерживать не собираемся. Просто потому что баги
которые вылезут на Solaris/Sparc сразу на x86_64 могут не замечаться
годами а просто сажать производительность.
> И работает, кстати, я подтверждаю. Но со стороны эксплуатации к
> Вашему, Виктор, продукту -- на самом деле есть вопросы.
>
> Например, почему нет официального решения для построения HA-кластера?
> Или почему есть официальная тулза для promote, а для demote -- нету?
В нашем продукте - PostgresPro Enterprise и то, и другое уже есть.
https://postgrespro.ru/docs/enterprise/16/biha
А в апстримовском опенсурсном постгресе есть только то, с
необходимость чего согласны все разработчики участвующие в сообществе.
А тут у нас, EnterpriseDB и 2nd Quadrant есть разные мнения. И
проталкивание какой-нибудь разработанной нами фичи иногда занимает годы.
Так было например с covering indexes, которые у нас были еще в 9.5, а в
апстрим были вмержены по-моему в 10. И не потому что мы их зажимали -
на коммитфесте они висели.
В конкретном случае HA-кластера у разных пользователей очень разные
требования и одним "официальным" решением всех не удовлетворишь.
Поэтому и расцветают все цветы.
>
--
Victor Wagner <vi...@wagner.pp.ru>
Dmitrii Kashin <fre...@gmail.com> пишет:
> Что бы сказал Фредерик Брукс на такое расточительство? =)
(почему-то и спарк и power и arm 32-битные, а IBM-овские мейнфреймы -
31 битные)
>
> А если серьёзно, Вы почему-то делаете предположение, что у нас нет
> нормальных тест-сьютов. Но это ошибочно. Если мы будем полный
> тест-сьют на каждую сборку запускать, то вы же, разработчики, первые
> прибежите с претензиями "а что так долго сборку ждать, я никак таску
> не могу закрыть, а с меня уже требуют". В общем, обычно в фичбранче
> прогоняются только юнит-тесты, а полный тест-сьют запускает уже QA
> перед мерджем.
Это разные роли, и их должны исполнять разные люди. Во всяком случае в
отношении одного и того же пакета.
Поэтому я, кстати, никогда не пытался стать мейнтейнером своих
программ, которые попали в Debian. Потому что им я разработчик, а не
мейнтейнер.
Как сказал Эрик Раймонд, "Given enough eyeballs all bugs are shallow".
Вот одна пара - это точно не enough. Поэтому вторая пара глаз -
мейнтейнера, который смотрит на код с другой точки зрения, чем
разработчик, необходима.
У разработчика на машине, и даже на общем для команды разработчиков VCS
хосте где запускаются тесты на коммиты во фича-ветки, совершенно не
обязательно иметь чистую среду. Там все -dev пакеты могут быть заранее
поставлены. Но у них там будет от силы пяток разных сред. Именно в силу
необходимости балансирования скорости прогона и широты покрытия.
А вот на этапе пакетирования, где контролируется правильность написания
spec или debian/control - там нужны воспроизводимые билды в
воспроизводимой среде.
И тестовые среды тоже должны быть воспроизводимыми. Раскатываться из
архива образов перед каждым запуском.
И здесь уже будет 30 дистрибутивов для 5 аппаратных архитектур.
Впрочем у нас еще есть между этими двумя стадиями промежуточная, где
максимальная широта охвата, то есть тестируются даже системы которые мы
не поддерживаем и поддерживать не собираемся. Просто потому что баги
которые вылезут на Solaris/Sparc сразу на x86_64 могут не замечаться
годами а просто сажать производительность.
> И работает, кстати, я подтверждаю. Но со стороны эксплуатации к
> Вашему, Виктор, продукту -- на самом деле есть вопросы.
>
> Например, почему нет официального решения для построения HA-кластера?
> Или почему есть официальная тулза для promote, а для demote -- нету?
https://postgrespro.ru/docs/enterprise/16/biha
А в апстримовском опенсурсном постгресе есть только то, с
необходимость чего согласны все разработчики участвующие в сообществе.
А тут у нас, EnterpriseDB и 2nd Quadrant есть разные мнения. И
проталкивание какой-нибудь разработанной нами фичи иногда занимает годы.
Так было например с covering indexes, которые у нас были еще в 9.5, а в
апстрим были вмержены по-моему в 10. И не потому что мы их зажимали -
на коммитфесте они висели.
В конкретном случае HA-кластера у разных пользователей очень разные
требования и одним "официальным" решением всех не удовлетворишь.
Поэтому и расцветают все цветы.
>
--
Victor Wagner <vi...@wagner.pp.ru>
Dmitrii Kashin
Feb 17, 2024, 7:10:05 AMFeb 17
to
> On 17 Feb 2024, at 11:17, Victor Wagner <vi...@wagner.pp.ru> wrote:
>
> В Fri, 16 Feb 2024 19:59:17 +0300
> Dmitrii Kashin <fre...@gmail.com> пишет:
>
>> Что бы сказал Фредерик Брукс на такое расточительство? =)
>
> Фредерик Брукс нам еще ответит за украденный 32-бит из архитектуры s390;-)
> (почему-то и спарк и power и arm 32-битные, а IBM-овские мейнфреймы -
> 31 битные)
>> А если серьёзно, Вы почему-то делаете предположение, что у нас нет
>> нормальных тест-сьютов. Но это ошибочно. Если мы будем полный
>> тест-сьют на каждую сборку запускать, то вы же, разработчики, первые
>> прибежите с претензиями "а что так долго сборку ждать, я никак таску
>> не могу закрыть, а с меня уже требуют". В общем, обычно в фичбранче
>> прогоняются только юнит-тесты, а полный тест-сьют запускает уже QA
>> перед мерджем.
>
> Мы тут не про разработчиков, мы тут про мейнтейнеров пакетов.
> Это разные роли, и их должны исполнять разные люди.
> Поэтому я, кстати, никогда не пытался стать мейнтейнером своих
> программ, которые попали в Debian. Потому что им я разработчик, а не
> мейнтейнер.
> Как сказал Эрик Раймонд, "Given enough eyeballs all bugs are shallow".
> А в апстримовском опенсурсном постгресе есть только то, с
> необходимость чего согласны все разработчики участвующие в сообществе.
>
> А тут у нас, EnterpriseDB и 2nd Quadrant есть разные мнения.
Короче, подытожу.
Вы говорите в целом правильные вещи, и я рад, что конкретно в Вашей компании есть нормальные люди. К сожалению их количество в мире весьма ограничено, и приходится работать с тем, что есть. Я допускаю, что Вы встречали обезьян, называющих себя DevOps-инженерами, я их тоже встречал. Равно как и встречал немало обезьян, которые называли себя разработчиками. Тем не менее, иногда первое впечатление бывает ошибочным. DevOps -- это хорошая правильная, а главное -- актуальная для сегодняшнего дня методология.
0 new messages