Re: Не запускается sshd в bullseye на виртуальной машине

[Dmitrii Kashin]

> On 17 Feb 2024, at 11:17, Victor Wagner  wrote:
> 
> В Fri, 16 Feb 2024 19:59:17 +0300
> Dmitrii Kashin  пишет:
> 
>> Что бы сказал Фредерик Брукс на такое расточительство? =)
> 
> Фредерик Брукс нам еще ответит за украденный 32-бит из архитектуры s390;-)
> (почему-то и спарк и power и arm 32-битные, а IBM-овские мейнфреймы -
> 31 битные)

Каков подлец! =)

>> А если серьёзно, Вы почему-то делаете предположение, что у нас нет
>> нормальных тест-сьютов. Но это ошибочно. Если мы будем полный
>> тест-сьют на каждую сборку запускать, то вы же, разработчики, первые
>> прибежите с претензиями "а что так долго сборку ждать, я никак таску
>> не могу закрыть, а с меня уже требуют". В общем, обычно в фичбранче
>> прогоняются только юнит-тесты, а полный тест-сьют запускает уже QA
>> перед мерджем.
> 
> Мы тут не про разработчиков, мы тут про мейнтейнеров пакетов. 
> Это разные роли, и их должны исполнять разные люди.

Ну вообще-то мы говорили про DevOps. И нет, DevOps-инженер не является ни 
разработчиком, ни мейнтейнером. Это всё другие люди. А является он по 
определению медиатором между разработкой и эксплуатацией.

> Поэтому я, кстати, никогда не пытался стать мейнтейнером своих
> программ, которые попали в Debian. Потому что им я разработчик, а не
> мейнтейнер. 

Может и зря. Не смотря на то, что всё в Postgresql заточено под то, чтобы 
конфиги хранились в датадире (о чём явно сказано в документации), его 
мейнтейнеры в Debian утащили их из датадира в /etc, не иначе как для 
соответствия своей FHS, и теперь конкретно дебиановскими инсталляциями 
пользоваться не особо удобно.

> Как сказал Эрик Раймонд, "Given enough eyeballs all bugs are shallow".

Не думаю, что это работает. Когда Реймонд это писал, университеты ещё давали 
фундаментальное образование в области CS, а сейчас же они массово клепают 
прикладников. С тех пор количество проектов выросло по экспоненте, а количество 
глаз, способных что-то высмотреть -- осталось плюс-минус тем же. И в этом, 
кстати, кроется причина появления методологии DevOps как таковой.

> А в апстримовском опенсурсном постгресе есть только то, с
> необходимость чего согласны все разработчики участвующие в сообществе.
> 
> А тут у нас, EnterpriseDB и 2nd Quadrant есть разные мнения.

Я могу это понять, Виктор. Однако если никак не получается даже по утилите для 
demote договориться -- значит кто-то не особо заинтересован в этом.

Короче, подытожу.

Вы говорите в целом правильные вещи, и я рад, что конкретно в Вашей компании 
есть нормальные люди. К сожалению их количество в мире весьма ограничено, и 
приходится работать с тем, что есть. Я допускаю, что Вы встречали обезьян, 
называющих себя DevOps-инженерами, я их тоже встречал. Равно как и встречал 
немало обезьян, которые называли себя разработчиками. Тем не менее, иногда 
первое впечатление бывает ошибочным. DevOps -- это хорошая правильная, а 
главное -- актуальная для сегодняшнего дня методология.

Re: Не запускается sshd в bullseye на виртуальной машине

[Victor Wagner]

В Fri, 16 Feb 2024 19:59:17 +0300
Dmitrii Kashin  пишет:


> Что бы сказал Фредерик Брукс на такое расточительство? =)

Фредерик Брукс нам еще ответит за украденный 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 

Re: Не запускается sshd в bullseye на виртуальной машине

[Victor Wagner]

В Fri, 16 Feb 2024 10:59:25 +0300
Eugene Berdnikov  пишет:


> > И с обменом файлами между контейнером и хостом (собранное
> > желательно куда-то деть).  
> 
>  Для меня это было одной из главных причин, по которым docker пошёл
> на. С lxc всё намного проще и удобней, файлы доступны напрямую в

Докер - слишком overengineered. Ну собственно как и любое решение
набравшее популярность в массах. Меня например в нем больше всего
раздражает его желание по умолчанию использовать гугловские DNS а не
хостовые (откуда гугль знает про миррор в коапроативной сети. куда
контейнеру надо за пакетами ходить) и попытка править хостовый файрволл,
которая приводит к неработоспосбности на той же машине других систем
контейнеризации.

> отдельном каталоге. Правда, с lxc тоже нужно разбираться, хотя бы с
> созданием исходного образа, в то время как операции с VM в полностью

По-моему начиная с 4-й версии в lxc появился темплейт oci, который
позволяет паразитировать на докерном коммьюнити и качать образы для
контейнеров с докерхаба.

Но вот если готового образа контейнера на докерахбе нет, что скорее
правило, чем исключение для всяких отечественных дистрибутивов, то 
конечно поставиться родным инсталлятором в виртуалку - проще.

Мы иногда так делаем - ставим виртуалку, потом через qemu-nbd
копируем ее файловую систему и делаем lxc-контейнеры. Хотя они тогда
огромные получаются - с GUI и все такое. Если типичный размер
контейнера созданного debootstrap, dnf или аналогами - полгига, то
типичный контейнер созданный путем копирования виртуалки - полтора-два.





-- 
   Victor Wagner 

Re: Не запускается sshd в bullseye на виртуальной машине

[Dmitrii Kashin]

> On 16 Feb 2024, at 18:37, Eugene Berdnikov  wrote:
> 
> On Fri, Feb 16, 2024 at 06:09:27PM +0300, Victor Wagner wrote:
>> В Fri, 16 Feb 2024 17:07:11 +0300
>> Dmitrii Kashin  пишет:
>> 
>>> Если сборки частые -- то есть большая разница, занимает она семь
>>> минут или одну (помножаем на число сборок в день, получаем количество
>>> сэкономленного времени. Если собирается что-нибудь явовское -- есть
>> 
>> Нет разницы. Потому что нормальные люди, которые хотят чтобы клиентам
>> достался работающий софт, после сборки запускают тесты.
> 
> Бывает, что тест нагружает дисковую подсистему. И тут разница между
> контейнером и виртуалкой, которая эмулирует диск, становится очень
> даже заметной.

Да это вообще ни к контейнерам, ни к виртуализации не относится. Это вопрос 
организации тестовой среды.
Комплекты тестов, проверяющие утилизацию реальных ресурсов, обычно выносятся в 
отдельный тест-сьют и гоняются на специально подготовленных для них хардварных 
окружениях.
Ну ладно, может не "обычно", а "следует". Так-то обезьян в девопс много (как, 
впрочем, и в разработке).

Re: Не запускается sshd в bullseye на виртуальной машине

[Dmitrii Kashin]

> On 16 Feb 2024, at 18:09, Victor Wagner  wrote:
> 
> В Fri, 16 Feb 2024 17:07:11 +0300
> Dmitrii Kashin  пишет:
> 
>> Если сборки частые -- то есть большая разница, занимает она семь
>> минут или одну (помножаем на число сборок в день, получаем количество
>> сэкономленного времени. Если собирается что-нибудь явовское -- есть
> 
> Нет разницы. Потому что нормальные люди, которые хотят чтобы клиентам
> достался работающий софт, после сборки запускают тесты. И тесты эти
> работают часы, в лучшем случае десятки минут. Если у тебя тест сьют
> занимает два часа, выигрыш шести минут на сборке абсолютно не важен.

> А если у тебя тесты не занимают в 10-100 раз больше времени, чем
> сборка, значит хреново твой пакет тестами покрыт.

Что бы сказал Фредерик Брукс на такое расточительство? =)

А если серьёзно, Вы почему-то делаете предположение, что у нас нет нормальных 
тест-сьютов. Но это ошибочно. 
Если мы будем полный тест-сьют на каждую сборку запускать, то вы же, 
разработчики, первые прибежите с претензиями "а что так долго сборку ждать, я 
никак таску не могу закрыть, а с меня уже требуют".
В общем, обычно в фичбранче прогоняются только юнит-тесты, а полный тест-сьют 
запускает уже QA перед мерджем.

>> Это кстати тоже в пункт о "положении билд-серверов в сети". Где-то
>> есть локальный миррор, где-то нет его.
> 
> Я от своих сотрудников всегда требую чтобы прерывание пьяным
> экскаваторщиком оптоволоконного кабеля перед входом в датацентр, не
> являлось поводом к несрабатыванию сборок и тестов по таймеру.

Ну вот Вы -- молодец. Но ситуации бывают разные.
Бывает, что у бизнеса нет денег на аренду необходимого для этого количества 
ресурсов.
Бывает, что бизнес не видит в этом необходимости, то есть ему необходимо 
ощутить боль, чтобы понять, зачем это нужно.
И я как представитель эксплуатации сталкиваюсь с подобным отношением весьма 
часто.

>> Обычная DevOps-практика, в общем, заключается в том, что мы либо
> 
> Мы к счастью не девопсы, мы нормальная софтверная фирма. и производим
> продукт который может использоваться не только на наших же серверах.

И работает, кстати, я подтверждаю. Но со стороны эксплуатации к Вашему, Виктор, 
продукту -- на самом деле есть вопросы.

Например, почему нет официального решения для построения HA-кластера?
Или почему есть официальная тулза для promote, а для demote -- нету?
Почему basebackup добавляет в файл автоконфигурации (в котором большими буквами 
написано, что его нельзя редактировать руками) строчку conninfo, а старую не 
удаляет?

И это только по поверхности. Мелкие нюансы, от которых пользователям Вашего 
продукта бывает больно, Виктор.
На устранении этих нюансов и очеловечивании Вашего продукта у компании Percona 
серьёзный востребованный на рынке бизнес построен, между прочим.

> А к идее девопса (собаки оборотня меняющей пол вместе с ипостасью) я
> испытваю глубокое отвращение.
> 
> Либо ты (программирующий) пользователь и не зарекайся на большее, либо
> таки научись быть нормальным разработчиком и дистрибьютором.


Эк Вас колбасит. Что ж, я как раз собираюсь пересечься с Маслюком, ну вот у 
меня и будет повод его спросить, почему он так плохо работает, что я читаю 
здесь такие отзывы. =)

Re: Не запускается sshd в bullseye на виртуальной машине

[Misha Ramendik]

On Fri, 16 Feb 2024 at 15:37, Eugene Berdnikov  wrote:

> On Fri, Feb 16, 2024 at 06:09:27PM +0300, Victor Wagner wrote:
>  Бывает, что тест нагружает дисковую подсистему. И тут разница между
>  контейнером и виртуалкой, которая эмулирует диск, становится очень
>  даже заметной.
>
>
>
У меня всё проще, я собирал и тестировал FTP серверы. Включая то как они
вкрячиваются в systemd и как они слушают порт 21. Сетапить всё это в
контейнере - ну можно наверное разобраться, но зачем, когда в виртуалке всё
работает из коробки? Ну, кроме того sshd, которого не было в официальной
виртуалке, но я ж его уже починил давно, не без помощи отсюда.

Re: Не запускается sshd в bullseye на виртуальной машине

[Eugene Berdnikov]

On Fri, Feb 16, 2024 at 06:09:27PM +0300, Victor Wagner wrote:
> В Fri, 16 Feb 2024 17:07:11 +0300
> Dmitrii Kashin  пишет:
> 
> > Если сборки частые -- то есть большая разница, занимает она семь
> > минут или одну (помножаем на число сборок в день, получаем количество
> > сэкономленного времени. Если собирается что-нибудь явовское -- есть
> 
> Нет разницы. Потому что нормальные люди, которые хотят чтобы клиентам
> достался работающий софт, после сборки запускают тесты.

 Бывает, что тест нагружает дисковую подсистему. И тут разница между
 контейнером и виртуалкой, которая эмулирует диск, становится очень
 даже заметной.

 Думаю, это должно особенно доставлять тогда, когда нет возможности
 запихнуть этот тест в файловую систему в оперативке -- например,
 потому что "не лезет", т.к. места на диске нужно слишком много.
-- 
 Eugene Berdnikov

Re: Не запускается sshd в bullseye на виртуальной машине

[Victor Wagner]

В Fri, 16 Feb 2024 17:07:11 +0300
Dmitrii Kashin  пишет:

> 
> Если сборки частые -- то есть большая разница, занимает она семь
> минут или одну (помножаем на число сборок в день, получаем количество
> сэкономленного времени. Если собирается что-нибудь явовское -- есть

Нет разницы. Потому что нормальные люди, которые хотят чтобы клиентам
достался работающий софт, после сборки запускают тесты. И тесты эти
работают часы, в лучшем случае десятки минут. Если у тебя тест сьют
занимает два часа, выигрыш шести минут на сборке абсолютно не важен.

А если у тебя тесты не занимают в 10-100 раз больше времени, чем
сборка, значит хреново твой пакет тестами покрыт.

> 
> Это кстати тоже в пункт о "положении билд-серверов в сети". Где-то
> есть локальный миррор, где-то нет его.

Я от своих сотрудников всегда требую чтобы прерывание пьяным
экскаваторщиком оптоволоконного кабеля перед входом в датацентр, не
являлось поводом к несрабатыванию сборок и тестов по таймеру.

А то никогда не знаешь, где найдешь где потеряешь. То ли зарубежный
сайт перестанет пускать с российских IP, то  ли роскомнадзор xml.org
заблокирует.

> Обычная DevOps-практика, в общем, заключается в том, что мы либо

Мы к счастью не девопсы, мы нормальная софтверная фирма. и производим
продукт который может использоваться не только на наших же серверах.

А к идее девопса (собаки оборотня меняющей пол вместе с ипостасью) я
испытваю глубокое отвращение.

Либо ты (программирующий) пользователь и не зарекайся на большее, либо
таки научись быть нормальным разработчиком и дистрибьютором.















-- 
   Victor Wagner 

Re: Не запускается sshd в bullseye на виртуальной машине

[Dmitrii Kashin]

> On 16 Feb 2024, at 16:47, Victor Wagner  wrote:
> 
> В Fri, 16 Feb 2024 16:17:18 +0300
> Dmitrii Kashin  пишет:
> 
>> А по существу, что ни выбери -- всё равно надо либо делать базовый
>> образ с builddeps, либо каждый раз ждать, пока всё поставится. Докер
>> ли, виртуалка ли... Pbuilder даже, и тот имеет архив с базовым
>> имиджем. И он тоже потратит время, чтобы туда зависимости доставить.
>> Без этого никуда.
> 
> И это хорошо и правильно

Ну да. Тем не менее всё зависит от вводных. От частоты сборок, от способностей 
кэширования, от положения билд-серверов в сети, от частоты обновления 
зависимостей.

Если сборки частые -- то есть большая разница, занимает она семь минут или одну 
(помножаем на число сборок в день, получаем количество сэкономленного времени.
Если собирается что-нибудь явовское -- есть смысл подключать кэширование для 
зависимостей maven-а (их бывает очень, очень много; так что тезис о том, что 
крайне редко пакет имеет 657 метров зависимостей -- не вполне верен).
Если у сети ограниченный канал (например в силу юридических причин производство 
релоцировалось в КЗ, что нынче не редкость) -- тоже.

> Ну конечно у меня оно эти 657Мб качало с локального миррора в той же
> стойке.

Это кстати тоже в пункт о "положении билд-серверов в сети". Где-то есть 
локальный миррор, где-то нет его.

Обычная DevOps-практика, в общем, заключается в том, что мы либо готовим 
базовый имидж на регулярной основе, так что он всегда свежий, к примеру, в 
течение дня; либо устанавливаем кэширующие сервера/зеркала с тем же умыслом. 
Обычно этого хватает. Особенно с учётом частоты обновления публичных зеркал 
дебиана.

Re: Не запускается sshd в bullseye на виртуальной машине

[Victor Wagner]

В Fri, 16 Feb 2024 16:17:18 +0300
Dmitrii Kashin  пишет:


> А по существу, что ни выбери -- всё равно надо либо делать базовый
> образ с 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 

Re: Не запускается sshd в bullseye на виртуальной машине

[Dmitrii Kashin]

> On 16 Feb 2024, at 12:06, Maksim Dmitrichenko  wrote:
> 
> пт, 16 февр. 2024 г. в 12:14, Dmitrii Kashin  >:
>> 
 Уж какой-нибудь docker, полагаю, на федоре найдётся.
>>> 
>>> Всю дорогу для этого хватало самого обыкновенного chroot. Вроде как для 
>>> сборки deb-пакетов есть pbuilder - и он доступен в федорином горе. 
>> 
>> 
>> Chroot конечно хорошо, но всё одно придётся систему дебутстрапить.
> 
> Но pbuilder - это как раз и есть обёртка над chroot'ом, где это всё 
> автоматизировано.

Это понятно. Но pbuilder это специализированный инструмент чисто для deb-а, и 
ему надо учиться отдельно, причём в дополнение к dh и прочим. А docker человек 
сможет использовать в том числе для сборки под другие системы тоже, и не только 
для сборки.

>> Я так раньше делал, и это не особо удобно. С появлением же контейнеров всё 
>> стало проще, ибо всё свелось к "docker pull debian:bullseye".
> 
> Э не, батенька. Это потом надо запустить контейнер с этим базовым имиджем, 
> поставить туда все build-dependencies пакета, который тебе нужно собрать, или 
> написать Dockerfile поверх этой базы и так далее.

Ну перво-наперво правильно, чёрт возьми. Я тут батька, и это не обсуждается. =)

А по существу, что ни выбери -- всё равно надо либо делать базовый образ с 
builddeps, либо каждый раз ждать, пока всё поставится. Докер ли, виртуалка 
ли... Pbuilder даже, и тот имеет архив с базовым имиджем. И он тоже потратит 
время, чтобы туда зависимости доставить. Без этого никуда.

>> PS: pbuilder, кстати, тоже хороший вариант, тредстартеру на заметку
> 
> Читаю тут тред, и народ не может даже осилить ключ -v у команды docker run 
> (чтобы сделать общую папку с хостом). Сползаем в какое-то либо дедовское 
> недовольство всем новым, либо в милениальное "слишком сложно, мне надо 
> быстрее".

Да ладно, Максим. Вы уже столько лет в нашей сфере, пора бы перестать 
удивляться очевидным вещам. =)

Re: Не запускается sshd в bullseye на виртуальной машине

[Maksim Dmitrichenko]

пт, 16 февр. 2024 г. в 12:14, Dmitrii Kashin :

>
> Уж какой-нибудь docker, полагаю, на федоре найдётся.
>>
>
> Всю дорогу для этого хватало самого обыкновенного chroot. Вроде как для
> сборки deb-пакетов есть pbuilder - и он доступен в федорином горе.
>
>
> Chroot конечно хорошо, но всё одно придётся систему дебутстрапить.
>

Но pbuilder - это как раз и есть обёртка над chroot'ом, где это всё
автоматизировано.


> Я так раньше делал, и это не особо удобно. С появлением же контейнеров всё
> стало проще, ибо всё свелось к "docker pull debian:bullseye".
>

Э не, батенька. Это потом надо запустить контейнер с этим базовым имиджем,
поставить туда все build-dependencies пакета, который тебе нужно собрать,
или написать Dockerfile поверх этой базы и так далее.

Хотя я очень люблю докеры, но в данном случае он лишний. Докер нужен для
изоляции, а для сборки пакета из исходников нужен
бинарно-совместимый userland.


> PS: pbuilder, кстати, тоже хороший вариант, тредстартеру на заметку
>

Читаю тут тред, и народ не может даже осилить ключ -v у команды docker run
(чтобы сделать общую папку с хостом). Сползаем в какое-то либо дедовское
недовольство всем новым, либо в милениальное "слишком сложно, мне надо
быстрее".

-- 
With best regards
  Maksim Dmitrichenko

Re: Не запускается sshd в bullseye на виртуальной машине

[Dmitrii Kashin]

> On 16 Feb 2024, at 03:04, Misha Ramendik  wrote:
>> 
> С контейнером пришлось бы разбираться, как прикручивать ему persistent 
> storage <...>
> Мне своё время жалко, а ресурсы машины на VM - нет.

Сдаётся мне, Вы уже потратили гораздо больше времени, чем заняла бы реализация 
сборки пакета в контейнере вместе со чтением документации, как контейнеры 
работают. Впрочем, это Ваше право.

Re: Не запускается sshd в bullseye на виртуальной машине

[Dmitrii Kashin]

> On 15 Feb 2024, at 21:17, Victor Wagner  wrote:
> 
> В Thu, 15 Feb 2024 13:47:48 +0300
> Dmitrii Kashin  пишет:
> 
>>> On 14 Feb 2024, at 22:33, Misha Ramendik  wrote:
>>> 
>>> Всем привет!
>>> Мне нужно собрать пакет для bullseye. У меня Федора.
>>> Ну, поднял VM <...> Хочу поднять sshd и работать с VM по ssh.  
>> 
>> Действительно ли Вы этого хотите?
>> Если стоит задача собрать пакет, так просто возьмите контейнер с
>> bullseye. Уж какой-нибудь docker, полагаю, на федоре найдётся.
>> 
> 
> А протестирвать? <...> Тестировать лучше в системе имеющей полноценный
> init/systemd и отдельный от хоста сетевой стек.

Довольно мало софта действительно нуждаются в наличии полноценного инита в 
контейнере.
В 95% случаев для теста хватает контейнера.

> 
> И еще кто сказал что архитектура процессора на хосте и в виртуалке
> совпадает?

А не нужно. Докер поддерживает мульти-платформенные сборки.

Re: Не запускается sshd в bullseye на виртуальной машине

[Dmitrii Kashin]

>> Уж какой-нибудь docker, полагаю, на федоре найдётся.
> 
> Всю дорогу для этого хватало самого обыкновенного chroot. Вроде как для 
> сборки deb-пакетов есть pbuilder - и он доступен в федорином горе. 


Chroot конечно хорошо, но всё одно придётся систему дебутстрапить. Я так раньше 
делал, и это не особо удобно. С появлением же контейнеров всё стало проще, ибо 
всё свелось к "docker pull debian:bullseye".

PS: pbuilder, кстати, тоже хороший вариант, тредстартеру на заметку

Re: Не запускается sshd в bullseye на виртуальной машине

[Eugene Berdnikov]

On Fri, Feb 16, 2024 at 12:04:49AM +, Misha Ramendik wrote:
>On Thu, 15 Feb 2024 at 10:48, Dmitrii Kashin  wrote:
> 
>> Действительно ли Вы этого хотите?
>> Если стоит задача собрать пакет, так просто возьмите контейнер с
>> bullseye.
>> Уж какой-нибудь docker, полагаю, на федоре найдётся.
> 
>Всё очень просто. С контейнером пришлось бы разбираться, как прикручивать
>ему persistent storage, чтобы не качать заново все дополнительные пакеты
>для каждой новой сборки (пока было две, может ещё случиться, всё только
>для себя - у меня есть VPS на bullseye). И с обменом файлами между
>контейнером и хостом (собранное желательно куда-то деть).

 Для меня это было одной из главных причин, по которым docker пошёл на.
 С lxc всё намного проще и удобней, файлы доступны напрямую в отдельном
 каталоге. Правда, с lxc тоже нужно разбираться, хотя бы с созданием
 исходного образа, в то время как операции с VM в полностью виртуализованной
 среде всем знакомы и привычны.

>Я имел дело с
>контейнерами - но не с вот этими вот квестами, а только CI/CD в котором
>всё совсем просто. Есть кого спросить про контейнеры - но на VM это всё не
>нужно. Мне своё время жалко, а ресурсы машины на VM - нет.

 Правильно.
-- 
 Eugene Berdnikov

Re: Не запускается sshd в bullseye на виртуальной машине

[Eugene Berdnikov]

On Fri, Feb 16, 2024 at 08:35:28AM +0300, Victor Wagner wrote:
> В Thu, 15 Feb 2024 23:33:31 +0300
> Eugene Berdnikov  пишет:
> 
> > > В свое время пришллось очень сильно потрахаться в ситуациях когда на
> > > хосте и в контейнере существенно разные версии systemd (или с одной
> > > стороны systemd  а с другой sysv init).   
> > 
> >  Это другой вопрос. Речь шла о том, что для тестирования PG в плане
> >  запуска и работы с сетью нет причин требовать полной виртуализации.
> >
> 
> Есть причины. Как только речь заходит о системах мандатного доступа,
> нужна поддержка на уровне ядра.
> 
> А эти системы бывают разные. Ну вот откуда в дебиановском ядре
> поддержка астровского parsec.
> 
> Ну и про тесты использущие специфическую FUSE-файловую систему я уже
> упоминал. Это тоже связано с защитой данных - мы так проверяем что
> удаленные данные действительно исчезли с диска.
> (а уж как тестируется зачистка удаленных данных из RAM, это вообще
> песня)

 Ну и при чём тут инициализация и сеть в постгресе? Не при чём,
 поскольку виртуализации требует нечто, к постгресу прямо не относящееся.
 Не обманывайте подписчиков рассылки!

> > > А если у тебя GUI и нужно тестировать с X Window, Wayland и что там
> > > еще нынче бывает?  
> > 
> >  Теоретически X Window, Wayland & Ко должны уметь работать по tcp и
> >  проксироваться через unix-сокеты, например, через ssh. Практически же
> >  я неоднократно наблюдал с этим проблемы у Firefox и Libreoffice.
> >  Но я думаю, что там что-то ломали в либах... Времени и желания
> 
> Вот вот. В теории нет различий между теорией и практикой. а на практике
> ого-го какие различия.

 На практике нужно вычёсывать подобные баги, после чего можно продолжать
 тестирование гуя в контейнере.
-- 
 Eugene Berdnikov

Re: Не запускается sshd в bullseye на виртуальной машине

[Victor Wagner]

В Thu, 15 Feb 2024 23:33:31 +0300
Eugene Berdnikov  пишет:

> On Thu, Feb 15, 2024 at 10:50:22PM +0300, Victor Wagner wrote:
> > В Thu, 15 Feb 2024 21:39:42 +0300
> > Eugene Berdnikov  пишет:
> >   
> > >  В контейнерах есть и свой 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 

Re: Не запускается sshd в bullseye на виртуальной машине

[Misha Ramendik]

On Thu, 15 Feb 2024 at 10:48, Dmitrii Kashin  wrote:


> Действительно ли Вы этого хотите?
> Если стоит задача собрать пакет, так просто возьмите контейнер с bullseye.
> Уж какой-нибудь docker, полагаю, на федоре найдётся.
>
> Всё очень просто. С контейнером пришлось бы разбираться, как прикручивать
ему persistent storage, чтобы не качать заново все дополнительные пакеты
для каждой новой сборки (пока было две, может ещё случиться, всё только для
себя - у меня есть VPS на bullseye). И с обменом файлами между контейнером
и хостом (собранное желательно куда-то деть). Я имел дело с контейнерами -
но не с вот этими вот квестами, а только CI/CD в котором всё совсем просто.
Есть кого спросить про контейнеры - но на VM это всё не нужно. Мне своё
время жалко, а ресурсы машины на VM - нет.

sshd побеждён не без помощи рассылки, всё уже работает, всё спокойно
собирается. pbuilder не побеждён, но оно и не надо, хватает
dpkg-checkbuilddeps и debuild.

Re: Не запускается sshd в bullseye на виртуальной машине

[Eugene Berdnikov]

On Thu, Feb 15, 2024 at 10:50:22PM +0300, Victor Wagner wrote:
> В Thu, 15 Feb 2024 21:39:42 +0300
> Eugene Berdnikov  пишет:
> 
> >  В контейнерах есть и свой init/systemd, и отдельный namespace для
> > сети, позволяющий тестировать сетевые приложения. В этом смысле что
> > docker, что lxc -- пригодные для этого среды, а постгресс в плане
> > сети и инита ничего странного требовать не должен.
> 
> В свое время пришллось очень сильно потрахаться в ситуациях когда на
> хосте и в контейнере существенно разные версии systemd (или с одной
> стороны systemd  а с другой sysv init). 

 Это другой вопрос. Речь шла о том, что для тестирования PG в плане
 запуска и работы с сетью нет причин требовать полной виртуализации.

> А если у тебя GUI и нужно тестировать с X Window, Wayland и что там еще
> нынче бывает?

 Теоретически X Window, Wayland & Ко должны уметь работать по tcp и
 проксироваться через unix-сокеты, например, через ssh. Практически же
 я неоднократно наблюдал с этим проблемы у Firefox и Libreoffice.
 Но я думаю, что там что-то ломали в либах... Времени и желания
 разбираться не было, другие приложения работали нормально. Так что
 GUI вполне можно отлаживать в контейнерах, если не хотеть экзотики,
 вроде прямой работы с видеокартой, аппаратного ускорения и т.п.
-- 
 Eugene Berdnikov

Re: Не запускается sshd в bullseye на виртуальной машине

[Victor Wagner]

В Thu, 15 Feb 2024 21:39:42 +0300
Eugene Berdnikov  пишет:


> 
>  В контейнерах есть и свой init/systemd, и отдельный namespace для
> сети, позволяющий тестировать сетевые приложения. В этом смысле что
> docker, что lxc -- пригодные для этого среды, а постгресс в плане
> сети и инита ничего странного требовать не должен.

В свое время пришллось очень сильно потрахаться в ситуациях когда на
хосте и в контейнере существенно разные версии systemd (или с одной
стороны systemd  а с другой sysv init). 

Вот как-то я рассказывал-рассказывал людям про то как под ОС МЦСТ
запустить в контейнере относительно свежий альтлинукс, они
послушали-послушали и сказали "нафиг эту МЦСТ, поставим альт на хост"

При том что там и тогда выхода не было. На "Эльбрусах" аппаратная
виртуализация начиная с Эльбрус 12. А то было 8С или 8СВ.
Поэтому только lxc. 

>  Ситуации, в которых контейнер не даёт делать полноценное
> тестирование, встречаются нечасто. Например, с lvm в контейнере есть
> проблемы.

НУ у нас например есть тесты требующе монтирования специальной тестовой
файловой системы через FUSE. Да. в конце концов удалоьс LXC запинать
чтобы он это делал.

А если у тебя GUI и нужно тестировать с X Window, Wayland и что там еще
нынче бывает?


-- 
   Victor Wagner 

Re: Не запускается sshd в bullseye на виртуальной машине

[Eugene Berdnikov]

On Thu, Feb 15, 2024 at 09:17:40PM +0300, Victor Wagner wrote:
> В Thu, 15 Feb 2024 13:47:48 +0300
> Dmitrii Kashin  пишет:
> 
> > > On 14 Feb 2024, at 22:33, Misha Ramendik  wrote:
> > > 
> > > Всем привет!
> > > Мне нужно собрать пакет для bullseye. У меня Федора.
> > > Ну, поднял VM <...> Хочу поднять sshd и работать с VM по ssh.  
> > 
> > Действительно ли Вы этого хотите?
> > Если стоит задача собрать пакет, так просто возьмите контейнер с
> > bullseye. Уж какой-нибудь docker, полагаю, на федоре найдётся.
> 
> А протестирвать? Мы, например, на архитектуре x86_64 тестируем постгрес
> исключительно в виртуалках. Потому как сетевой сервис, взаимодействует
> с инитом и все такое. Тестировать лучше в системе имеющей полноценный
> init/systemd и отдельный от хоста сетевой стек.

 В контейнерах есть и свой init/systemd, и отдельный namespace для сети,
 позволяющий тестировать сетевые приложения. В этом смысле что docker,
 что lxc -- пригодные для этого среды, а постгресс в плане сети и инита
 ничего странного требовать не должен.

 Ситуации, в которых контейнер не даёт делать полноценное тестирование,
 встречаются нечасто. Например, с lvm в контейнере есть проблемы.
-- 
 Eugene Berdnikov

Re: Не запускается sshd в bullseye на виртуальной машине

[Victor Wagner]

В Thu, 15 Feb 2024 13:47:48 +0300
Dmitrii Kashin  пишет:

> > On 14 Feb 2024, at 22:33, Misha Ramendik  wrote:
> > 
> > Всем привет!
> > Мне нужно собрать пакет для bullseye. У меня Федора.
> > Ну, поднял VM <...> Хочу поднять sshd и работать с VM по ssh.  
> 
> Действительно ли Вы этого хотите?
> Если стоит задача собрать пакет, так просто возьмите контейнер с
> bullseye. Уж какой-нибудь docker, полагаю, на федоре найдётся.
> 

А протестирвать? Мы, например, на архитектуре x86_64 тестируем постгрес
исключительно в виртуалках. Потому как сетевой сервис, взаимодействует
с инитом и все такое. Тестировать лучше в системе имеющей полноценный
init/systemd и отдельный от хоста сетевой стек. Хотя собирать и правда
в schroot удобнее.

И еще кто сказал что архитектура процессора на хосте и в виртуалке
совпадает?

-- 
   Victor Wagner 

Re: Не запускается sshd в bullseye на виртуальной машине

[Maksim Dmitrichenko]

чт, 15 февр. 2024 г. в 14:48, Dmitrii Kashin :

>
> > On 14 Feb 2024, at 22:33, Misha Ramendik  wrote:
> >
> > Всем привет!
> > Мне нужно собрать пакет для bullseye. У меня Федора.
> > Ну, поднял VM <...> Хочу поднять sshd и работать с VM по ssh.
>
> Действительно ли Вы этого хотите?
> Если стоит задача собрать пакет, так просто возьмите контейнер с bullseye.
> Уж какой-нибудь docker, полагаю, на федоре найдётся.
>

Всю дорогу для этого хватало самого обыкновенного chroot. Вроде как для
сборки deb-пакетов есть pbuilder - и он доступен в федорином горе.


-- 
With best regards
  Maksim Dmitrichenko

Re: Не запускается sshd в bullseye на виртуальной машине

[Dmitrii Kashin]

> On 14 Feb 2024, at 22:33, Misha Ramendik  wrote:
> 
> Всем привет!
> Мне нужно собрать пакет для bullseye. У меня Федора.
> Ну, поднял VM <...> Хочу поднять sshd и работать с VM по ssh.

Действительно ли Вы этого хотите?
Если стоит задача собрать пакет, так просто возьмите контейнер с bullseye.
Уж какой-нибудь docker, полагаю, на федоре найдётся.

Re: Не запускается sshd в bullseye на виртуальной машине

[Victor Wagner]

В Wed, 14 Feb 2024 23:05:50 +0300
Anton Gorlov  пишет:

> 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 

Re: Не запускается sshd в bullseye на виртуальной машине

[Victor Wagner]

В Wed, 14 Feb 2024 20:12:04 +
Misha Ramendik  пишет:

> Это удалось победить. Нагуглилось сделать /usr/bin/ssh-keygen -A и
> сервис взлетел.
> 
> Но не пускает. 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 

Re: Не запускается sshd в bullseye на виртуальной машине

[Anton Gorlov]

14.02.2024 23:12, Misha Ramendik пишет:


Но не пускает. Permission denied (publickey).

Пароль у рута есть, логиниться пытаюсь рутом. /root есть, /root/.ssh 
есть, принадлежат все руту. Что тут нужно сделать чтобы он стал пускать 
по ssh?





Вообще ходить рутом плохая идея by design

А так man sshd_config - > PermitRootLogin

Re: Не запускается sshd в bullseye на виртуальной машине

[Misha Ramendik]

Это удалось победить. Нагуглилось сделать /usr/bin/ssh-keygen -A и сервис
взлетел.

Но не пускает. Permission denied (publickey).

Пароль у рута есть, логиниться пытаюсь рутом. /root есть, /root/.ssh есть,
принадлежат все руту. Что тут нужно сделать чтобы он стал пускать по ssh?

On Wed, 14 Feb 2024 at 19:33, Misha Ramendik  wrote:

> Всем привет!
>
> Мне нужно собрать пакет для 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
>