from:"Artem Chuprina"

Damir Hakimov -> Debian Russian Mailing List  @ Tue, 18 Dec 2018 22:59:57 +0400:

 >> >  > Получается проблема курицы и яйца. Чтобы набрать энтропию, системе
 >> >  > требуется начать работать - обрабатывать какие-то сетевые запросы,
 >> >  > шуршать диском и т.д.
 >>
 >  Чисто для расширения кругозора вопрос: на сетевом интерфейсе свет
 > клином сошелся? Почему не задействовать микрофон, АЦП подключенный к
 > нагреваемому резистору, пятна на солнце для этой самой энтропии?

В рассматриваемых случаях обычно ни микрофона, ни АЦП нет, а пятна на
солнце есть, но вот данных о них опять же нет.

Все-таки беседа в основном о серверах, причем часто о виртуальных.

Может быть, ядерный ДСЧ и умеет задействовать микрофон, если он вдруг
найдется. Конструкцию из АЦП с резистором — вряд ли, потому как те
полтора землекопа, которые ее соберут, нехай сами дописывают этот кусок
кода и оценивают собранную энтропию.

Re: linux /dev/random initialization CVE-2018-1108

Vladimir Zhbanov -> debian-russian@lists.debian.org  @ Tue, 18 Dec 2018 
23:25:46 +0300:

 >> >  Чисто для расширения кругозора вопрос: на сетевом интерфейсе свет
 >> > клином сошелся? Почему не задействовать микрофон, АЦП подключенный к
 >> > нагреваемому резистору, пятна на солнце для этой самой энтропии?
 >> 
 >>  Нажатие клавиш (например, Shift-а с автоповтором) позволяет быстро
 >>  проскочить место, где системный демон завис на getrandom().
 >>  Так что по крайней мере драйвер клавиатуры задействован.
 >>  
 >>  Но у серверов кроме сети существенных источников шума обычно нет.

 > Отслеживаемые напряжения питания материнской платы и процессора,
 > которых обычно несколько, по-любому плавают. Плавает и
 > температура, но гораздо медленнее, что, впрочем, тоже можно
 > использовать. Про какие-то процессоры читал, что там специально
 > улучшали качество и скорость отслеживания напряжений, по ходу даже
 > датчики и АЦП в том же корпусе были, чтобы энтропию собирать.

Плохо там со случайностью без специальных мер. Для мониторинга
высокоточное измерение не нужно, а при невысокой точности энтропии там
кот наплакал.

А если речь про виртуалку, так и вообще никак. Кто ж ей даст реальные
данные о напряжении на плате?

Re: linux /dev/random initialization CVE-2018-1108

Victor Wagner -> Artem Chuprina  @ Tue, 18 Dec 2018 12:52:11 +0300:

 >> Как интересно... Хотя, если по уму, то urandom'у бы тоже сначала
 >> набрать энтропию, и только потом уже раскручивать псевдорандомизацию.
 >> А прикапывать ее между перезагрузками чревато тем же боком. Так-то
 >> считается, что urandom — псевдослучайный, но с криптографическим
 >> качеством. А значит, должен иметь в виду криптографическую модель
 >> угроз.

 > Получается проблема курицы и яйца. Чтобы набрать энтропию, системе
 > требуется начать работать - обрабатывать какие-то сетевые запросы,
 > шуршать диском и т.д.

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

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

А сетевую активность без проблем со случайностью можно сделать,
например, так: взять совсем уже псевдослучайное число, например,
8.8.8.8, пингануть его, таймингом ответа зарядить обычный дешевый PRNG,
который не криптографического качества, а дальше в параллель попинговать
его следующие значения, периодически подмешивая тайминги ответов. С
этого ядро наберет уже вполне вменяемую энтропию.

Re: linux /dev/random initialization CVE-2018-1108

Eugene Berdnikov -> debian-russian@lists.debian.org  @ Mon, 17 Dec 2018 
23:22:51 +0300:

 > On Mon, Dec 17, 2018 at 10:05:55PM +0300, Artem Chuprina wrote:
 >> Eugene Berdnikov -> debian-russian@lists.debian.org @ Mon, 17 Dec 2018
 >> 18:48> > Пришлось уже позаменять syslog-ng на rsyslog, потому что первый
 >> вызывает
 >>  >  getrandom() ДО того, как свалить в бэкграунд (правда, к нему и другие
 >>  >  претензии были). Хорошо что sshd так не делает, иначе на серверах
 >>  >  пришлось бы его под inetd переводить.
 >> 
 >> Вот интересно, а зачем syslog-ng понадобилась настоящая энтропия? Чему
 >> ему urandom не угодил?

 >  Насколько я разбираюсь в медицине, он как раз urandom и читает.
 >  Вот что написано в мане random(7):

 >*  The  Linux-specific  getrandom(2) system call, available since Linux
 >   3.17.  This system call provides access either to the same source as
 >   /dev/urandom (called the urandom source in this page) or to the same
 >   source as /dev/random (called the random source in this page).   The
 >   default  is  the  urandom  source;  the random source is selected by
 >   specifying the GRND_RANDOM flag to the  system  call.   (The  geten‐
 >   tropy(3) function provides a slightly more portable interface on top
 >   of getrandom(2).)

 >  А вот что делает syslog-ng, фрагмент трассы, который я отправил в BT:
 > 
 > 1501 22:44:00 
 > getrandom("\x74\x78\x56\x35\x28\xad\x52\xd2\xcb\x51\xb1\x30\xc7\x67\x14\x26\x01\xa4\x2d\xa0\x30\x1d\xad\x09\x9e\xe3\x2c\x4e\x07\x55\x0d\x29",
 >  32, 0) = 32 <322.583360>

 >  Got with "strace -Tt", means reading of 32 random bytes tooks 322 seconds.
 > 
 >  Флаги здесь, как видно, нулевые, в то время как GRND_NONBLOCK = 1,
 >  GRND_RANDOM = 2. Так что именно urandom он и читает, и блокируется
 >  на нём на 5 минут.

Как интересно... Хотя, если по уму, то urandom'у бы тоже сначала набрать
энтропию, и только потом уже раскручивать псевдорандомизацию. А
прикапывать ее между перезагрузками чревато тем же боком. Так-то
считается, что urandom — псевдослучайный, но с криптографическим
качеством. А значит, должен иметь в виду криптографическую модель угроз.

 >>  >  Зато появился новый квест: писать программы так, чтобы они рандомные
 >>  >  битики получали асинхронно, в отдельном треде. Рядом с резолвером.
 >> 
 >> Опять-таки, если им нужна настоящая энтропия, то им ее все равно
 >> дожидаться.

 >  Да, это правильно, но теперь нужно понимать, что этом сисколе можно крепко
 >  зависнуть, а это может быть критично. Для syslog-ng квест выглядит так:
 >  автор должен был догадаться, что сначала нужно создать сокет в /dev/log
 >  и сказать ему listen(), иначе некоторые сервисы (например, sshd) не захотят
 >  запускаться и процесс загрузки встанет. Так что просто сделать костыль,
 >  принудительно отправив syslog-ng в бэкграуд -- не получится. Я пробовал,
 >  на SysV-init. Возможно, с systemd результат будет иной, но проблема
 >  имеется, для других утилит она может проявляться иначе.

Да, одна проблема раскрыла наличие другой. Ну что ж, бывает...

Re: linux /dev/random initialization CVE-2018-1108

Eugene Berdnikov -> debian-russian@lists.debian.org  @ Mon, 17 Dec 2018 
18:48:51 +0300:

 >>  >>  > Почему нельзя сохранить entropy pool при выключении и восстановить 
 >> при
 >>  >>  > включении, как происходить с urandom seed?
 >>  >> 
 >>  >> Потому что небезопасно.
 >> 
 >>  >  Может ли кто-нибудь изложить модель угроз?
 >> 
 >> replay в случае восстановления диска с бэкапа/снапшота или размножения
 >> образов диска.

 >  Угу, а те кому работать, а не заниматься размножением в рабочее время,
 >  и кому нужно в случае чего быстро ребутнуться, те сосут лапу из-за
 >  измышлений теоретиков. И ладно бы теоретики предусмотрели ручку, чтобы
 >  отключить их фантазии нахрен, или хотя бы сделали параметр "время жизни
 >  энтропийного пула" с отметками времени, mac-адресами сетевушек и т.п...
 >  
 >  Пришлось уже позаменять syslog-ng на rsyslog, потому что первый вызывает
 >  getrandom() ДО того, как свалить в бэкграунд (правда, к нему и другие
 >  претензии были). Хорошо что sshd так не делает, иначе на серверах
 >  пришлось бы его под inetd переводить.

Вот интересно, а зачем syslog-ng понадобилась настоящая энтропия? Чему
ему urandom не угодил?

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

Опять-таки, если им нужна настоящая энтропия, то им ее все равно
дожидаться. Пул и закончиться может. А если сгодится urandom, то фиг ли
они настоящую просят?

Re: linux /dev/random initialization CVE-2018-1108

Eugene Berdnikov -> debian-russian@lists.debian.org  @ Mon, 17 Dec 2018 
19:04:40 +0300:

 >> > Ну и плюс, если речь о виртуалках у хостера, дополнительные риски с
 >> > доступом злоумышленника к образу диска (по сравнению с доступом к
 >> > памяти).
 >> 
 >> Если виртуалка у хостера, то он уже и так имеет полный доступ ко всем
 >> закрытым ключам хранящимся на диске (ssh) и ещё одни приватные данные
 >> никаких рисков не добавят.

 >  Вообще, у хостера есть доступ к памяти виртуалки... Так что прятать
 >  что-то от хостера глупо. :)

Не от хостера, а от соседей по хостингу.

 >  Но зачем на хостинге приватные ключи ssh? Они должны быть на рабочей
 >  станции админа, а на хостинг следует пробрасывать лишь ssh-agent.
 >  Да и то не всегда, а лишь на доверенные хостинги.

Ключи сервера, например, еще как нужны.

Re: linux /dev/random initialization CVE-2018-1108

Eugene Berdnikov -> debian-russian@lists.debian.org  @ Mon, 17 Dec 2018 
16:34:58 +0300:

 >>  > Почему нельзя сохранить entropy pool при выключении и восстановить при
 >>  > включении, как происходить с urandom seed?
 >> 
 >> Потому что небезопасно.

 >  Может ли кто-нибудь изложить модель угроз?

replay в случае восстановления диска с бэкапа/снапшота или размножения
образов диска.

Во втором случае получится не столько replay как таковой, сколько
одинаковые seed'ы у нескольких инстансов. И пока настоящая энтропия не
набежала, выхлоп из них будет очень сильно скоррелирован, на самом
старте, возможно, даже идентичен.

Ну и плюс, если речь о виртуалках у хостера, дополнительные риски с
доступом злоумышленника к образу диска (по сравнению с доступом к
памяти). Или к освобожденным блокам хранилища после затирания этого
seed'а на виртуальном диске. Память-то под это дело наверняка лочится, и
в своп данные RNG не попадают.

Re: linux /dev/random initialization CVE-2018-1108

sergio -> debian-russian  @ Mon, 17 Dec 2018 15:09:11 +0300:

 > Я правильно понял, что безопасных способов решения проблемы нет?
 > (Ну кроме как купить надёжный TRNG.)

Да. RNG - это в принципе самая большая проблема криптографии.

 > Почему нельзя сохранить entropy pool при выключении и восстановить при
 > включении, как происходить с urandom seed?

Потому что небезопасно.

Re: drweb и wifi

2018-11-23 Пенетрантность Artem Chuprina

Александр Завгородний -> Artem Chuprina  @ Fri, 23 Nov 2018 15:58:10 +0300:

 > а я не юзер)

 >> Описанные тобой действия помогают обратному. Если юзер будет под них
 >> прогибаться, то нафига им разрабатывать-то? Тяп, ляп, и в продакшн. Вот
 >> если юзер будет их нагибать, тогда другое дело...
 > что вы хотите этим сказать?

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

А если не хотят работать - деньгивзад, и пусть сосут лапу.

Re: drweb и wifi

2018-11-23 Пенетрантность Artem Chuprina

1 -> debian-russian@lists.debian.org  @ Fri, 23 Nov 2018 15:24:26 +0300:

 > допустим, я хочу немного помочь DrWeb в разработке отечественного ПО)

Описанные тобой действия помогают обратному. Если юзер будет под них
прогибаться, то нафига им разрабатывать-то? Тяп, ляп, и в продакшн. Вот
если юзер будет их нагибать, тогда другое дело...

  Можно этот https://github.com/kumina/fakemac или любой другой.
 
 >>> я пока повременил со сторонней программой, я попытался сделать так, как
 >>> мне показалось немного проще:
 >> Потом из техподдержки тебя попросят вкрутить анальный зонд еще немного
 >> глубже, т.к. им не удобно, а из-за того, что сигнал стал проходить хуже -
 >> ходите зондом вперед и под углом 45% от горизонта. Мы заботимся о вас (С).
 >>
 >> И это заметь - за твои-же деньги.
 >>

Re: $MAIL & ssh

2018-11-18 Пенетрантность Artem Chuprina

sergio -> debian-russian@lists.debian.org  @ Sun, 18 Nov 2018 03:28:38 +0300:

 >> как то плохо грепал, если login.defs с его MAIL_DIR пропустил...

 > А при чём тут MAIL_DIR?

grep должен был его найти, а ты пишешь "ничего".

 > Он используется pam_mail'ом, который, ещё раз, закомментиорван во
 > всех pam.d/*. Но что бы не рисковать, я и MAIL_DIR убрал --- но
 > ничего не изменилось.

... и кто-то взял вкомпилированное умолчание, за отсутствием других
вариантов...

Re: LXC vs Docker и форматы контейнеров

2018-11-14 Пенетрантность Artem Chuprina

Andrey Jr. Melnikov -> debian-russian@lists.debian.org  @ Wed, 14 Nov 2018 
20:05:06 +0300:

 >> Почту, календарь, контакты,
 >> в меньшей степени "быстрая" связь (видео, голос, мессенджер),
 > Хангаутс-то? Так себе видео/голос/месенджер. Оно же в дуплекс голосом еще не
 > научилось. 

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

Я же не про то, что надо. Я про то, что пипл хавает.

Re: LXC vs Docker и форматы контейнеров

2018-11-11 Пенетрантность Artem Chuprina

Andrey Jr. Melnikov -> debian-russian@lists.debian.org  @ Sun, 11 Nov 2018 
16:12:42 +0300:

 >> Т.е. в основном оно используется для того что обычный современный юзер
 >> отдает Гуглю, а я не хочу.
 > А что там можно отдать гуглю - почту и календари? 

Почту, календарь, контакты, в меньшей степени "быстрая" связь (видео,
голос, мессенджер), "документы", кстати. В смысле, docs, sheets, и кто
там у него presentation умеет. Если нужна совместная работа с кем-то
еще.

Re: btrfs?

2018-11-10 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Sat, 10 Nov 2018 16:29:16 +0300:

 >>   >> При этом поддержка ext4 в линуксе не в пример лучше :) Включая,
 >>   >> например, тот момент, что дистрибутивный пакет умеет цеплять ZFS только
 >>   >> если инитом работает systemd, а systemd инитом весьма хреново
 >>   >> работает.
 >>
 >>   > Ну как-бы он сейчас меинстрим, хоть как-то да работает.
 >>
 >> Угу. При каждой загрузке сервера приходится потом логиниться, вручную
 >> домонтировать том ZFS, передергивать самбу и nfsd (они раздают в том
 >> числе эту директорию, и не умеют отследить, что туда что-то
 >> подмонтировали), и поднимать не запустившийся по столь же неизвестным
 >> причинам rsyncd.
 >>
 >> Подозреваю, что проблема в том, что отслеживать зависимости при загрузке
 >> systemd на самом деле не умеет, а "как повезет". Т.е. подозреваю, что
 >> проблема в этом, потому что про "как повезет" есть уверенность.
 >>

 > Вообще, как бы неприятен systemd не был, но он всё-таки предназначен для
 > отслеживания зависимостей и управления ими множеством способов.
 > Так что, есть подозрение, что тут не в его сторону надо смотреть, а на
 > описание сервиса.
 > Возможно, что именно там зависимости прописаны криво.

С виду — прямо.

 >>   >> Описанная проблема с нецеплянием одного из томов — не
 >>   >> единственная проблема с systemd на этой машине. Это я уж молчу про 
 >> танцы
 >>   >> с рутом на ZFS. Я их один раз станцевал, но результат мне не шибко
 >>   >> нравится.
 >>
 >>   > Рут на ZFS, вполне устраивает, grub на ZFS загружает ядро с ZFS тома.
 >>
 >> Загружает. Устанавливать систему в эту позу (например, если придется
 >> поднимать с бэкапа) неудобно. Много ручных танцев.

 > Ну, кажется, для бэкапа, вы же сами мне рекомендовали сохранять образ
 > полностью. В этом случае, проблем нет.

Иногда бывает, что бэкапный винт меньше рабочего, и бэкап приходится
делать выборочным. Было бы куда сохранить полный...

И второй момент. При восстановлении на железо, от которого не было
фирмвари, образ винта может не взлететь. В этой ситуации надо уметь
подмонтировать его с rescue-флешки. Для ZFS надо вместо rescue брать
live и доставлять в нее zfs-dkms.

Оно бы окупалось, если бы какие-то функции ZFS, которых нету у ext4,
прижились. А так — нет.

Re: btrfs?

2018-11-08 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Thu, 8 Nov 2018 23:07:09 +0300:

 >>   > Пользуюсь ZFS на Debian Linux с 17 года в NAS, пока всё ok. Две системы
 >>   > подобной сложности вряд ли нужны. Одна в продакшне, другая между альфа 
 >> и бета
 >>   > версиями уже долго, потому если требуется подобный функционал, ясно что
 >>   > выбирать.
 >>
 >> Ну вот у меня, например, при загрузке системы упорно не монтируется один
 >> из томов ZFS. Если залогиниться после загрузки и сказать zfs mount -a,
 >> то молча монтируется. Отличается от остальных тем, что там попрошено
 >> case insensitive имена файлов (это exchange, в первую очередь для винды)
 >> и задействованы ACL.
 >> Как следует разобраться с проблемой руки не доходят, ибо сервер на шкафу
 >> и монитор к нему цеплять неудобно.
 >>

 > А монитор-то зачем, если залогиниться возможно без примонтированного тома?

Чтобы разобраться, что происходит в момент загрузки.

 > Кстати, точка монтирования пустая?

Пустая.

 >> Офф-бэнд дефрагментацию блочного уровня ZFS, в отличие от btrfs, не
 >> умеет.

 > Да, есть такое, предлагают делать через zfs send, но велик ли уровень
 > фрагментации для большинства задач?

Тьфу. Дедупликацию.

 >> При этом поддержка ext4 в линуксе не в пример лучше :) Включая,
 >> например, тот момент, что дистрибутивный пакет умеет цеплять ZFS только
 >> если инитом работает systemd, а systemd инитом весьма хреново
 >> работает.

 > Ну как-бы он сейчас меинстрим, хоть как-то да работает.

Угу. При каждой загрузке сервера приходится потом логиниться, вручную
домонтировать том ZFS, передергивать самбу и nfsd (они раздают в том
числе эту директорию, и не умеют отследить, что туда что-то
подмонтировали), и поднимать не запустившийся по столь же неизвестным
причинам rsyncd.

Подозреваю, что проблема в том, что отслеживать зависимости при загрузке
systemd на самом деле не умеет, а "как повезет". Т.е. подозреваю, что
проблема в этом, потому что про "как повезет" есть уверенность.

 >> Описанная проблема с нецеплянием одного из томов — не
 >> единственная проблема с systemd на этой машине. Это я уж молчу про танцы
 >> с рутом на ZFS. Я их один раз станцевал, но результат мне не шибко
 >> нравится.

 > Рут на ZFS, вполне устраивает, grub на ZFS загружает ядро с ZFS тома.

Загружает. Устанавливать систему в эту позу (например, если придется
поднимать с бэкапа) неудобно. Много ручных танцев.

Re: btrfs?

2018-11-03 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Sat, 3 Nov 2018 16:10:09 +0300:

 > Пользуюсь ZFS на Debian Linux с 17 года в NAS, пока всё ok. Две системы
 > подобной сложности вряд ли нужны. Одна в продакшне, другая между альфа и бета
 > версиями уже долго, потому если требуется подобный функционал, ясно что
 > выбирать.

Ну вот у меня, например, при загрузке системы упорно не монтируется один
из томов ZFS. Если залогиниться после загрузки и сказать zfs mount -a,
то молча монтируется. Отличается от остальных тем, что там попрошено
case insensitive имена файлов (это exchange, в первую очередь для винды)
и задействованы ACL.

Как следует разобраться с проблемой руки не доходят, ибо сервер на шкафу
и монитор к нему цеплять неудобно.

Офф-бэнд дефрагментацию блочного уровня ZFS, в отличие от btrfs, не
умеет. Под ин-бэнд требования к железу невменяемые. А прочие плюшки ZFS
по сравнению с той же ext4 как-то применить не удается — машинка
слабенькая, без ECC, диск один, так что чексуммы все равно лучше держать
внешние, и проверять после скидывания на бэкапный винт.

При этом поддержка ext4 в линуксе не в пример лучше :) Включая,
например, тот момент, что дистрибутивный пакет умеет цеплять ZFS только
если инитом работает systemd, а systemd инитом весьма хреново
работает. Описанная проблема с нецеплянием одного из томов — не
единственная проблема с systemd на этой машине. Это я уж молчу про танцы
с рутом на ZFS. Я их один раз станцевал, но результат мне не шибко
нравится.

Re: btrfs?

2018-11-02 Пенетрантность Artem Chuprina

Угу, осознал. Всем спасибо, переформатировал в ext4 и ограничусь
перелинковкой средствами jdupes. Из положительного: в процессе чтения
про дедупликацию у btrfs выяснил, что существуют готовые инструменты для
такой перелинковки (не зависящие от btrfs), не надо писать :)

 >> Граждане, а как у нас нынче с надежностью btrfs? А другими тараканами?

 > Пару лет назад оно вело себя странно. Данные вроде не терял из-за нее,
 > но периодически приходилось делать rebalance. Сейчас живу с ней (ядро
 > 4.18) и вроде всё устраивает. Кроме того, она активно используется в
 > качестве backend для sbuild очень много у кого.


 > [gq@dwarf:~/ya/sdc]$ mount | grep btrfs
 > /dev/mapper/dwarf-root on / type btrfs 
 > (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
 > /dev/mapper/dwarf-chroot on /srv/chroot type btrfs
 > (rw,relatime,compress=zlib:3,ssd,space_cache,subvolid=5,subvol=/)
 > /dev/mapper/dwarf-home on /home type btrfs 
 > (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
 > /dev/mapper/dwarf-tmp on /mnt type btrfs 
 > (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)

 >> Или ну его пока нафиг, и пожить на старой доброй ext4? Задача - ФС под
 >> домашний файловый/бэкапный сервер. 8 TB. Его собственное содержимое
 >> бэкапится, увы, пока нерегулярно. Рейд тоже пока увы. Во-первых,
 >> нетбабла (диск такого объема не три копейки стоит), а во-вторых, в той
 >> машинке быстрый SATA-выход один.
 > Под надежный сторадж я использую ext4. Он же надёжный =)

 >> А вот косой взгляд на инструменты out-of-band deduplication для btrfs
 >> как раз вызывает интерес к оной файловой системе. Поскольку там немало
 >> бэкапов, и порой файлы в них переезжают, эта функциональность
 >> представляется нелишней. Расслабиться на тему "ну и что, что сотню
 >> гигабайт переложили и потрогали, к завтрему перелинкуется" было бы
 >> приятно.

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

btrfs?

2018-11-01 Пенетрантность Artem Chuprina

Хмутро.

Граждане, а как у нас нынче с надежностью btrfs? А другими тараканами?

А то я в одном месте читаю, что типа мейтейнер ext4 полагает ее
временной мерой, и уже пора переходить на btrfs, а в дебиановской вики
перечислено такое количество тараканов...

Изрядная часть из них - из разряда "тут играть, тут не играть, тут рыбу
заворачивали". Типа, эта функция есть, но чревата потерей данных, так
что лучше не использовать. Компрессию лучше не использовать. dpkg (если
делать рут на btrfs) страшно тормозит, и чинить это никто не будет.

И все это касается в том числе и свежих ядер, в смысле, более свежих,
чем в stable.

Или ну его пока нафиг, и пожить на старой доброй ext4? Задача - ФС под
домашний файловый/бэкапный сервер. 8 TB. Его собственное содержимое
бэкапится, увы, пока нерегулярно. Рейд тоже пока увы. Во-первых,
нетбабла (диск такого объема не три копейки стоит), а во-вторых, в той
машинке быстрый SATA-выход один.

Снапшоты, которыми имелось в виду пользоваться при экспериментах с zfs,
не прижились, самопальные скрипты вокруг rsync на задаче бэкапов дают
лучшую управляемость. Еще хотелось разнесения задач по подтомам, благо
zfs (и btrfs) динамически распределяют под них место, но что-то тоже
практического применения не сложилось.

А вот косой взгляд на инструменты out-of-band deduplication для btrfs
как раз вызывает интерес к оной файловой системе. Поскольку там немало
бэкапов, и порой файлы в них переезжают, эта функциональность
представляется нелишней. Расслабиться на тему "ну и что, что сотню
гигабайт переложили и потрогали, к завтрему перелинкуется" было бы
приятно.

Re: grep_проблемы_с поиском русского_при определённых условиях

2018-10-15 Пенетрантность Artem Chuprina

Galina Anikina -> debian-russian@lists.debian.org  @ Mon, 15 Oct 2018 12:20:49 
+0300:

 >> Копать в сторону "в какой локали запущены терминал и bash". Скорее
 >> всего, дело в терминале. Если среда графическая, то ее скрипты
 >> запуска
 >> bashrc не читают. По вполне понятной причине - это файл конфигурации
 >> интерактивного шелла, а скрипт запуска никаким боком не
 >> интерактивный, и
 >> вообще, кстати, совершенно не обязательно интерпретируется башем.
 >> 

 > Да запущен гарфический Xserver и уже в нём запускаю терминал xfce, но у
 > меня (вручную отключено зрафическое окно входа и поэтому я вхожу по
 > учётной записи сразу в терминал и только потом ручками иду через startx
 > - давнишняя привычка и её трудно искоренить). Поэтому сразу у меня
 > должна активизироваться локаль, прописанная в bashrc. Но если при
 > запуске Xserver-а он считывает информацию, игнорируя bashrc, то да
 > возможны проблемы. Надо почитать откуда XServer считывает настройки.

Или если этим переменным забыли сказать export, и потому они не
передаются в запущенные процессы.

 >> Можно попробовать вписать в ~/.profile
 >> 
 >> LANG=ru_RU.UTF-8
 >> export LANG
 >> 
 >> (не одной строкой, а двумя, потому что, строго говоря, никто не
 >> обещал,
 >> что читать его будет продвинутый шелл, а так гарантированно
 >> sh-совместимо). А из bashrc как раз убрать, чтобы маскировки проблем
 >> не
 >> происходило.
 >> 
 >> Если не поможет, разбираться, где environment устанавливается у
 >> используемой граф. среды. Но в .profile все равно пусть будет, для
 >> захода по ssh и в текстовом варианте.
 >> 

 > Спасибо и про профиль почитаю.
 > Пока с помощью подсказки из другой ветки рассылки - 
 > debian-l10n-russ...@lists.debian.org частично решила этот вопрос
 > методом ввода в терминале LANG=en_US.UTF-8 или LANG=ru_RU.UTF-8 и далее
 > через env проверить, вступили ли в силу изменения, и потом запуск
 > какой-то программы - так нормально работает - программа даёт интерфейс,
 > который ты ей закажешь - английский или русский, и все сообщения
 > (хвостики в консоле-терминале будут выходить на определённом языке).
 > То есть можно не корректировать bashrc, а просто откорректировать файл
 > /etc/locale.gen, раскоментировав там два языка - русский и английский,
 > и потом # dpkg-reconfigure locales будут сформированы две локали в
 > системе, из них ты и сможешь выбирать.
 > Спасибо за ответ. Чуть позже я попробую и по вашему предложению
 > настроить ("кашу маслом не испортишь").

/etc/locale.gen отвечает только за генерацию локалей. А у процесса
одновременно может быть только одна. Но у каждого своя, да.

Re: grep_проблемы_с поиском русского_при определённых условиях

2018-10-13 Пенетрантность Artem Chuprina

Galina Anikina -> debian-russian  @ Sun, 14 Oct 2018 08:09:37 +0300:

 > 3) И в таком варианте почти всё работало нормально, но вот с grep
 > возникли проблемки...
 > Если через консоль простым пользователем пытаешься задать поиск 
 > grep -R "online" Документы/ 
 > вводишь "Док" и клавишей TAB пытаешься дополнить слово - обычно так и
 > работало ранее. А в условиях, описанных выше, появляется абракадабра -
 > курсор перескакивает, русские буквы не показываются. При попытке ввести
 > всё же вслепую русскую фразу и нажать Enter - выдаёт чепуху.
 > Та же ситуация, если бы я написала не "online", а слово на русском
 > языке.

Начнем с того, что это проблемы не с grep, а с эмулятором терминала или
с shell. Первое вероятнее. До grep в этот момент дело еще не доходит.

Проверить можно просто: запустить из этого шелла

LANG=ru_RU.UTF-8 терминал

(терминалов много, я не знаю, какой у Вас) и повторить в нем.

 > Вообщем в конце вернулась глобально к LANG=ru_RU.UTF-8.
 > Но проблема то не решена
 > Может кто подскажет - где копать.

Копать в сторону "в какой локали запущены терминал и bash". Скорее
всего, дело в терминале. Если среда графическая, то ее скрипты запуска
bashrc не читают. По вполне понятной причине - это файл конфигурации
интерактивного шелла, а скрипт запуска никаким боком не интерактивный, и
вообще, кстати, совершенно не обязательно интерпретируется башем.

Можно попробовать вписать в ~/.profile

LANG=ru_RU.UTF-8
export LANG

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

Если не поможет, разбираться, где environment устанавливается у
используемой граф. среды. Но в .profile все равно пусть будет, для
захода по ssh и в текстовом варианте.

Re: Мне расстраиваться, или ничего страшного?

2018-10-13 Пенетрантность Artem Chuprina

fuf -> debian-russian@lists.debian.org  @ Sat, 13 Oct 2018 19:44:53 +:

 > сыт по горло, теперь от Дебиана- ни на шаг! Приобрёл USB-modem (HUAWEI
 > E8372 LTE Wingle), но на коробке прочитал:
 > Требования к ОС ПК
 > -Win7, Win8, Win8.1 (без поддержки Windows RT)
 > -Mac OS ..
 > -АО ПК должно соответствовать требованиям установленой версии ОС
 > -Стандартный USB-интерфейс.
 > Мне расстраиваться, или ничего страшного?
 > Спасибо всем зараннее.

Ну как... Или будет работать, или нет. Одно из двух.

Re: Доступ к медиатеке

2018-10-06 Пенетрантность Artem Chuprina

D. H. -> debian-russian@lists.debian.org  @ Sat, 6 Oct 2018 06:18:14 -0500:

 > On 06/10/18 05:53 AM, Victor Wagner wrote:
 >> 3. От очередной драчки роскомнадзора с Дуровым при которой ваше облако
 >> может случайно попасть под раздачу, оказавшись в одном /16 блоке с
 >> телеграмовской прокси.

 > Вот это я пошел гуглить. Что-то пропустил похоже.

Угу. Пару месяцев назад, подыскивая для машинки на DigitalOcean адрес,
не заблокированный Роскомнадзором, я перебрал пять их датацентров. С
трудом нашел.

Re: systemd symlink vs file в dev-X1.device.requires

2018-09-11 Пенетрантность Artem Chuprina

sergio -> debian-russian@lists.debian.org  @ Tue, 11 Sep 2018 01:45:58 +0300:


 > Есть пустой /etc/systemd/system/dev-X1.device.requires

 > В чём разница между

 > # ln -s /lib/systemd/system/X@.service
 > /etc/systemd/system/dev-X1.device.requires

 > и

 > # cp /lib/systemd/system/X@.service 
 > /etc/systemd/system/dev-X1.device.requires

 > ?

Оба неправильные, насколько я понимаю... Но я могу неправильно понимать.

В смысле, systemd - это не init.d, в его конфигурации симлинки
развешиваются только в директории вида *.wants/. А линковать
непосредственно в /etc/systemd/system/ ничего не следует, он там этого
не ожидает.

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

Re: .application Name

2018-06-24 Пенетрантность Artem Chuprina

sergio -> debian-russian@lists.debian.org  @ Sun, 24 Jun 2018 02:35:55 +0300:

 > Так вот я в курсе, что за приложения у меня стоят, зачем я их ставил,
 > и что они делают, и не надо мне в меню ещё и описания.

Ну, это ты такой весь продвинутый. А я зачастую и не знаю про некоторые
приложения, что они у меня вообще стоят, не говоря уж о том, зачем
нужны. Это при том, что у меня Apt::Install-Recommends false.

И вообще, если ты такой продвинутый, то зачем тебе меню-то? Словами,
чай, разговаривать удобнее, чем мышкой...

Я вот, опять же, и не знаю, что у него там в .desktop написано - мне
просто не нужно его читать, и ни одной из программ, которые я запускаю,
это тоже не нужно. (Ну, может, кто само и читает, но на взаимодействие
со мной это не влияет никак.)

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

 >> Ну напишите мэйнтейнеру, пускай пофиксит, приведет к норме.

 > Так вот я и прошу ссылку на "норму".

Re: .application Name

2018-06-24 Пенетрантность Artem Chuprina

sergio -> debian-russian@lists.debian.org  @ Sun, 24 Jun 2018 00:15:37 +0300:

 >> А в чём проблема-то? Name нужен только для пользователя.

 > А из чего вы сделали вывод, что я сказал, что Name нужен не только для
 > пользователя?

 > Проблема в том, что все приложения как приложения, а Chromium Web Browser!

Это чтобы скрыть, что на самом деле он еще и Chromium Spy, и вышивать умеет :)

Re: debian/control Provides

2018-06-22 Пенетрантность Artem Chuprina

Andrey Nikitin -> debian-russian@lists.debian.org  @ Thu, 21 Jun 2018 15:56:55 
+0300:

 >> Боюсь, что из программных комплексов, написанных в ОО-стиле, такие
 >> занозы не вытаскиваются.

 > Вот взять, например, виртуальный "mail-transport-agent", или "time-daemon".
 > Я очень надеялся что `apt-cache rdepends mail-transport-agent` вернёт кучку 
 > пакетов,
 > которым нужен mta, всё равно какой, лишь бы был хоть один.
 > Это казалось мне логичным.
 > Но нет, пусто, никому не нужен виртуальный mail-transport-agent.
 > Тогда на зачем вся эта городьба с Provides? Чёт не понимаю.

Это, боюсь, вопрос к реализации rdepends. Потому что apt-cache depends
bsd-mailx показывает все, что надо. При установке пакетов достаточно depends.

Re: debian/control Provides

2018-06-22 Пенетрантность Artem Chuprina

D. H. -> debian-russian@lists.debian.org  @ Thu, 21 Jun 2018 08:27:07 -0500:

 >> Боюсь, что из программных комплексов, написанных в ОО-стиле, такие
 >> занозы не вытаскиваются.

 > Прошу прощения, не люблю догадываться, предпочитаю уточнять все
 > возможные неточности во избежании глупых недопониманий. Что имелось в
 > виду под "ОО-стиле"?

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

Re: debian/control Provides

2018-06-21 Пенетрантность Artem Chuprina

Andrey Nikitin -> debian-russian@lists.debian.org  @ Thu, 21 Jun 2018 15:10:54 
+0300:

 > Есть пакеты "foo-bar" и "foo-baz", каждый их которых:
 >Provides: foo
 >Conflicts: foo
 >Replaces: foo

 > И есть другой пакет: "foo-deps" у которого:
 >Depends: foo

 > Всё бы ничего, но при смене "foo-bar" на "foo-baz" (или наоборот),
 > apt выводит предупреждение "dependency problems":

 > dpkg: foo-deps: dependency problems, but removing anyway as you requested:
 >  foo-deps depends on avreg-site; however:
 >   Package foo is not installed.
 >   Package foo-bar which provides foo is to be removed.
 >   Package foo-baz which provides foo is not installed.

 > Делает всё как надо, меняет foo-bar на foo-baz не удаляя foo-deps.
 > Но предупреждение как заноза в ж..е, может кто поможет вытащить? :)

Боюсь, что из программных комплексов, написанных в ОО-стиле, такие
занозы не вытаскиваются.

Оно запускает dpkg не с ключом "я тебе эту зависимость потом
удовлетворю" (у него такого нет), а с ключом "удаляй, но не трогай
зависящих". А тот в такой ситуации вполне резонно громко вопит.

Re: env DISPLAY

2018-06-01 Пенетрантность Artem Chuprina

Andrey Nikitin -> debian-russian@lists.debian.org  @ Fri, 1 Jun 2018 11:04:27 
+0300:

 >> Вообще говоря, конкретная X-овая программа совершенно не обязана
 >> коннектиться к тому (или только к тому) дисплею, на которую указывает
 >> переменная DISPLAY.

 > У меня более простая задача.

 > Раньше, для запуска gui-приложений из

 >   а) ssh сеансов,
 >   б) скриптов, в которых нужно запускать gui через sudo;

 > достаточно было просто указать/передать DISPLAY=:0.0

 > А теперь, для того чтобы подключится к локальному дисплею
 > нужно дополнительно настраивать (keep env DISPLAY) sudo, ssh, pam(?).

sudo, пожалуй, стоит. И раньше стоило. А ssh - нет. Это с вероятностью
больше 1/2 будет гвоздь не от той стенки. Существует модель, при которой
имеет смысл передать ему DISPLAY от того процесса, который его
запускает, но надо хорошо понимать, что делаешь. А у вас с этим явная
проблема. pam точно не надо.

Re: env DISPLAY

2018-06-01 Пенетрантность Artem Chuprina

Andrey Nikitin -> debian-russian@lists.debian.org  @ Fri, 1 Jun 2018 10:37:40 
+0300:

 >> Нет. Один из них — X сервер обслуживающий gdm, а другой
 >> пользовательский.

 > О, точно, но DISPLAY у него такой же

 > $ sudo -u Debian-gdm sh -c 'echo $DISPLAY'
 > :1

Нет.

Переменные среды - свойство процесса, а не пользователя.

Re: комп с блютозом в деревне, где есть мобильная связь

2018-05-24 Пенетрантность Artem Chuprina

fuf -> debian-russian@lists.debian.org  @ Thu, 24 May 2018 14:02:32 +:

 > Ещё побеспокою.
 > Цитаты я сам в новое чистое сообщение вклеиваю из ваших постов с
 > debian-russian@lists.debian.org.
 > Телефон у меня примитивный NOKIA, я думаю никакой поддержки там нет. Значит
 > нужен новый?

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

Re: комп с блютозом в деревне, где есть мобильная связь

2018-05-24 Пенетрантность Artem Chuprina

fuf -> debian-russian@lists.debian.org  @ Thu, 24 May 2018 09:08:38 +:

 > Извините, вчера был краток, т.к. засыпал.
 > Дело в следующем: оплачивал мобильник в МТС, и предложили перейти с опт.
 > кабеля на сотовую связь, цена такая-же -500р. Я к этому решительному
 > предложению не готов, но вспомнил о деревне, лете и задумался о сот. связи
 > как о дополнении к кабелю. Эл-во там есть, вся детвора ходит уткнувшись в
 > смартфоны (мне это не подходит- экран мал и нет клав.), телевизоры
 > показывают плохо (30км от телевышки), у всех спут. тарелки, зимой живут в
 > двух домах.
 >  Блютузом и вай-фаем не пользовался., представление об этом смутное, но,
 > конечно, теперь почитаю.
 >  Хотелось бы прикинуть цену необходимого доп. железа и последовательность
 > действий.
 > Спасибо.

При наличии умения пользоваться дебианом и работоспособного в нем
блютуса в дебиане (такое бывает не всегда, иногда встроенные контроллеры
линуксом не поддерживаются) цена доп. железа 0. Но телефон во время
работы в инете должен быть рядом с ноутом.

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

Re: комп с блютозом в деревне, где есть мобильная связь

2018-05-24 Пенетрантность Artem Chuprina

Victor Wagner -> debian-russian@lists.debian.org  @ Thu, 24 May 2018 09:27:10 
+0300:

 >> Я пользуюсь мобильным роутером
 >> http://otzovik.com/reviews/3g_wifi_router_huawei_e5330/
 >> Не уверен, что это лучшее устройство этого типа.
 >> Для меня важно, что роутер умеет подключаться через мобильную связь а
 >> также раздавать имеющуюся WiFi-сеть уже от своего имени.

 > Мобильный роутер стоит денег. И в него нужна отдельная симка, которая
 > тоже стоит денег и требует абонентской платы (фиксирвоанной или за
 > траффик это уже не очень важно).

 > А здесь человек явно пытается слепить беспроводную сеть из того, что
 > было.

 > Не уверен, что результат его обрадует, но интересный опыт - получит.

И в общем, да, практика показывает, что в деревне блютуса более чем
достаточно.

samba: упорный бит x для группы

2018-04-20 Пенетрантность Artem Chuprina

Хмутро.

Эксперты по самбе есть? Наткнулся на следующую граблю.

Самба. Нижележащая директория, она exchange, имеет ACL

zsh% getfacl .
# file: .
# owner: root
# group: root
user::rwx
user:winguest:rwx
group::r-x
group:staff:rwx
mask::rwx
other::r-x
default:user::rwx
default:user:winguest:rwx
default:group::r-x
default:group:staff:rwx
default:mask::rwx
default:other::r-x

Т.е. есть юзер и группа, которым явно разрешено всё. Локально и по NFS
все работает ожидаемым образом.

zsh% touch locally
zsh% getfacl locally 
# file: locally
# owner: ran
# group: ran
user::rw-
user:winguest:rwx   #effective:rw-
group::r-x  #effective:r--
group:staff:rwx #effective:rw-
mask::rw-
other::r--

(с другой машины)
zsh% touch /bag/exchange/over-nfs
zsh% getfacl over-nfs 
# file: over-nfs
# owner: ran
# group: ran
user::rw-
user:winguest:rwx   #effective:rw-
group::r-x  #effective:r--
group:staff:rwx #effective:rw-
mask::rw-
other::r--

и ожидаемо в выводе ls бит x не стоит.

(с той же другой машины)
zsh% touch over-samba
zsh% ls -l over-samba 
-rw-rw-r-- 1 ran ran 0 апр 20 20:02 over-samba
zsh% smbclient -N //bag/exchange   
Anonymous login successful
Domain=[GREENWOOD] OS=[Windows 6.1] Server=[Samba 4.5.12-Debian]
smb: \> put over-samba 
putting file over-samba as \over-samba (0,0 kb/s) (average 0,0 kb/s)

И вот тут внезапно

zsh% getfacl over-samba 
# file: over-samba
# owner: winguest
# group: nogroup
user::rw-
user:winguest:rwx
group::rw-
group:staff:rwx
mask::rwx
other::rw-

Т.е. эффективного срезания бита x нет, и 
zsh% ls -l over-samba 
-rw-rwxrw-+ 1 winguest nogroup 0 Apr 20 20:04 over-samba*

причем почему-то показывают бит x у группы, а вовсе не у владельца,
который как раз winguest.

Что у меня настроено неправильно? Конфигурация шары

[exchange]
   comment = Home network exchange
   path = /exchange
   wide links = yes
   browseable = yes
   writable = yes
   guest ok = yes
   guest only = yes
   create mask = 0666
   directory mask = 0777

Документация на всякие танцы вокруг ACL в man smb.conf, как водится у
самбы, мутна. Явно никаких ручек на эту тему я не прописывал. unix
extensions = no, и с винды поведение то же самое.

Re: LDAP

2018-04-20 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Fri, 20 Apr 2018 08:44:25 +0300:

 > Так это, господа гуру криптографии и распределения ключей, FAQ-то
 > пользоваться или неактуально?
 > easy-rsa уже отменяется, я так понял?
 > Свой CA во вменяемом виде сейчас хрен поднимешь?

Нет, не отменяется. Для твоих целей того, что есть, скорее всего, хватит.

Re: LDAP

2018-04-19 Пенетрантность Artem Chuprina

Victor Wagner -> debian-russian@lists.debian.org  @ Thu, 19 Apr 2018 10:08:47 
+0300:

 >>  > учетом современных реалий. Чтобы и X509v3 умело, и эллиптические
 >>  > кривые понимало, причем не только в виде ECDSA.  
 >> 
 >>  > А Шаплова заставим новый Certificates HOWTO написать.  
 >> 
 >> Палка о двух концах. В easy_rsa ключевое слово - easy. Мы сумеем
 >> добавить туда новые возможности, не потеряв в простоте применения для
 >> простых случаев?

 > Ну, не попробуем - не узнаем. В общем-то challenge в том и состоит,
 > чтобы простые вещи были простыми, а сложные - возможными.

Ну ок, мысль эту следует попробовать. Я посмотрю на оные скрипты глазами.

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

 > По-моему, ты немножко не прав, и в JAVA cryptoapi которому андроид
 > более-менее следует, все это поддерживается. 

 > Оно  в сим-картах и то поддерживается. (JavaCard 3.0, если не
 > ошибаюсь).

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

Я тут на днях попытался в VX ConnectBot втянуть секретные
ssh-ключи. Нишмагла. В смысле, шмагла только RSA.

Re: LDAP

2018-04-18 Пенетрантность Artem Chuprina

Victor Wagner -> debian-russian@lists.debian.org  @ Thu, 19 Apr 2018 07:03:06 
+0300:

 >>  > Собственный CA имеет смысл, вроде.
 >>  > Вопрос только в том, насколько сложно (LDAP тоже казался простым,
 >>  > но свои особенности у каждого сервиса сожрали уйму времени)?  
 >> 
 >> В свое время в сети гуглился документ SSL Certificates Howto. Там было
 >> довольно грамотно расписано.

 > Устарело оно лет на двадцать. Осталось на уровне X509v1.
 >  
 >> Сейчас в дистрибутиве есть пакет easy-rsa, им любит OpenVPN
 >> пользоваться.  Это сделанный по тому рецепту комплект скриптов для
 >> своего CA.

 > Вот у нас тоже им пользовались. Коропоративная локалка, примерно 30
 > пользователей. VPN, LDAP, десяток-другой внутренних веб-сервисов.

 > Возникла необходимость поднять парочку Name-based https-хостов на одной
 > машина и ап.. А где SubjectAlternativeName? А не умеет его easy_rsa.
 > Вообще никаких extension не умеет.
 >  
 >> Чтобы им адекватно пользоваться, крайне желательно уже иметь понимание
 >> устройства PKI по схеме X509 (в PGP, например, схема другая). В
 >> упомянутом Howto изложение, помнится, было.

 > Ага было. На уровне  RFC 2459, принятого в прошлом веке.
 > А сейчас немножко даже 3280 уже неактуально. Надо пользоваться 5280 и
 > то с оглядкой на 6818.

 > Может это, тряхнем стариной, да и напишем ремейк easy_rsa, но с учетом
 > современных реалий. Чтобы и X509v3 умело, и эллиптические кривые
 > понимало, причем не только в виде ECDSA.

 > А Шаплова заставим новый Certificates HOWTO написать.

Палка о двух концах. В easy_rsa ключевое слово - easy. Мы сумеем
добавить туда новые возможности, не потеряв в простоте применения для
простых случаев?

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

Re: SAS hotswap и баг

2018-04-18 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Wed, 18 Apr 2018 23:05:20 +0300:

 >> echo "- - -" >/sys/class/scsi_host/host/scan
 >> 
 >> не уверен, насколько набор команд актуален современным ядрам, давно с 
 >> дисками не возился.
 >> 
 > Попробовать могу, но разве хотсвоп не предполагает, что руками делать
 > ничего не надо?

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

Re: LDAP

2018-04-18 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Wed, 18 Apr 2018 22:46:27 +0300:

 > Собственный CA имеет смысл, вроде.
 > Вопрос только в том, насколько сложно (LDAP тоже казался простым, но
 > свои особенности у каждого сервиса сожрали уйму времени)?

В свое время в сети гуглился документ SSL Certificates Howto. Там было
довольно грамотно расписано.

Сейчас в дистрибутиве есть пакет easy-rsa, им любит OpenVPN
пользоваться.  Это сделанный по тому рецепту комплект скриптов для
своего CA.

Чтобы им адекватно пользоваться, крайне желательно уже иметь понимание
устройства PKI по схеме X509 (в PGP, например, схема другая). В
упомянутом Howto изложение, помнится, было.

Re: LDAP

2018-04-16 Пенетрантность Artem Chuprina

 >>  >> Вот тут добавлю, Let's Encrypt можно получить для динамического адреса
 >>  >> используя сервис аля dyndns.
 >>  >> 
 >>  > Вот хотелось поподробнее про Let's Encrypt.
 >>  > Эта идея сначала была, но загнулась, и теперь мои сертификаты
 >>  > самоподписанные.
 >>  > Я так понял, этот сервис подписывает сертификат, созданный на внешнее
 >>  > доменное имя?
 >> 
 >> Да. 
 >> 
 >> Причем по этому имени должен быть доступен веб-сервер, и уметь отдать
 >> сгенерированный по ходу операции подписи файл со случайным именем,
 >> подписанный соответствующим ключом. 

 > Он умеет и без веб-сервера. Поднимая свой собственный на время подписи.
 > После подписания или пере выпуска сервер ему не нужен. Это есть в
 > документации.

Окей, по этому имени на время выписывания сертификата должен быть
доступен веб-сервер.

Re: LDAP

2018-04-16 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Mon, 16 Apr 2018 00:33:40 +0300:

 >>> Да, аутентификация по сертификату есть, если вы купите у своего
 >>> провайдера белый IP-адрес, то вам не нужны самоподписанные сертификаты,
 >>> можно использовать Let's Encrypt и разместить RADIUS-сервер на VPS. 
 >> 
 >> Вот тут добавлю, Let's Encrypt можно получить для динамического адреса
 >> используя сервис аля dyndns.
 >> 
 > Вот хотелось поподробнее про Let's Encrypt.
 > Эта идея сначала была, но загнулась, и теперь мои сертификаты
 > самоподписанные.
 > Я так понял, этот сервис подписывает сертификат, созданный на внешнее
 > доменное имя?

Да. 

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

Для локалки так себе решение. Возможно, свой CA (не самоподписанные
сертификаты, а плюс лишние два часа времени однократно, и таже
процедура, но со своим корневым сертификатом) будет умнее. Но
преимущество Let's Encrypt (на данный момент политических игр в области
PKI) в том, что про подписанные им сертификаты не надо ничего вручную
объяснять каждому клиенту. А про свой CA надо.

Re: Внешнее хранилище для виды

2018-04-13 Пенетрантность Artem Chuprina

Lev Arzhanov -> debian-russian@lists.debian.org  @ Fri, 13 Apr 2018 14:36:12 
+0500:

 > Почти оффтопик.

 > Есть нужда часть дискового пространства машины с Debian отдать в винду
 > по сети. Рассматриваю два варианта: NFS и iSCSI. Не подскажете, какой
 > из них будет предпочтительнее?

samba :)

Re: SAS hotswap и баг

2018-04-08 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Sun, 8 Apr 2018 16:55:12 +0300:

 >>  > Вытащил диск, вставил на место, но в /dev его не увидел.
 >>  > Зато увидел вот это в dmesg:
 >> 
 >> Это там, где ZFS поверх LUKS?  Есть шанс, что ты получил ответ на свой
 >> вопрос, что же ты сделал неправильно.
 >> 
 > Вряд ли тут что-то неправильно.
 > Да и шанса такого нет.
 > scsi_device_dev_release_usercontext явно знать не может о каком-то LUKS.

Ну, насчет шанса нет я бы не был так уверен. Нынче в ядре у нас что ни
блоковое устройство, то SCSI, даже если оно чисто программное.

Хотя, если в /dev нет самого диска, то в общем, да, говорить о проблеме
в районе LUKS не следует. Если проблема там, то нижележащий диск должен
быть на месте.

 >>  > [69497.081559] sd 0:0:5:0: [sdf] Synchronize Cache(10) failed: Result:
 >>  > hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
 >>  > [69916.705257] Buffer I/O error on dev dm-8, logical block 0, async page 
 >> read
 >>  > [69930.896113] list_del corruption, 986c0632b010->next is 
 >> LIST_POISON1 (dead0100)
 >>  > [69930.896226] [ cut here ]
 >>  > [69930.896227] kernel BUG at 
 >> /build/linux-3RM5ap/linux-4.14.13/lib/list_debug.c:47!
 >>  > [69930.896329] invalid opcode:  [#1] SMP PTI
 >>  > [69930.896416] Modules linked in: xt_nat veth ipt_MASQUERADE
 >>  > nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo
 >>  > iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype
 >>  > xt_conntrack nf_nat nf_conntrack br_netfilter bridge stp llc bonding 
 >> xt_tcpudp
 >>  > cpufreq_conservative cpufreq_userspace cpufreq_powersave iptable_filter
 >>  > intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel iTCO_wdt
 >>  > iTCO_vendor_support kvm irqbypass ttm drm_kms_helper intel_cstate 
 >> intel_uncore
 >>  > pcspkr intel_rapl_perf serio_raw drm evdev mei_me mei sg lpc_ich mfd_core
 >>  > shpchp ie31200_edac button nuvoton_cir ipmi_si battery ipmi_devintf 
 >> rc_core
 >>  > ipmi_msghandler tpm_crb video acpi_pad nct6775 hwmon_vid jc42 coretemp
 >>  > ip_tables x_tables autofs4 zfs(PO) zunicode(PO) zavl(PO) icp(PO) 
 >> zcommon(PO)
 >>  > znvpair(PO)
 >>  > [69930.896925]  spl(O) btrfs zstd_decompress zstd_compress xxhash
 >>  > algif_skcipher af_alg dm_crypt dm_mod raid10 raid456 async_raid6_recov
 >>  > async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c 
 >> crc32c_generic
 >>  > raid1 raid0 multipath linear md_mod sd_mod hid_generic usbhid hid
 >>  > crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc
 >>  > aesni_intel aes_x86_64 crypto_simd ahci glue_helper xhci_pci cryptd 
 >> libahci
 >>  > mpt3sas igb xhci_hcd raid_class i2c_algo_bit libata scsi_transport_sas 
 >> dca
 >>  > i2c_i801 ptp pps_core usbcore scsi_mod usb_common fan thermal
 >>  > [69930.897315] CPU: 7 PID: 15570 Comm: kworker/u16:2 Tainted: P O
 >>  > 4.14.0-0.bpo.3-amd64 #1 Debian 4.14.13-1~bpo9+1
 >>  > [69930.897462] Hardware name: To Be Filled By O.E.M. To Be Filled By
 >>  > O.E.M./E3C224D4I-14S, BIOS P3.20 05/29/2015
 >>  > [69930.897612] Workqueue: fw_event_mpt2sas0 _firmware_event_work 
 >> [mpt3sas]
 >>  > [69930.897732] task: 986a138af040 task.stack: bbcfca9a8000
 >>  > [69930.897846] RIP: 0010:__list_del_entry_valid+0x4e/0x90
 >>  > [69930.897958] RSP: 0018:bbcfca9abb48 EFLAGS: 00010086
 >>  > [69930.898070] RAX: 004e RBX: 0246 RCX: 
 >> 
 >>  > [69930.898185] RDX:  RSI: 986c1fdd66f8 RDI: 
 >> 986c1fdd66f8
 >>  > [69930.898298] RBP: 986c0632b738 R08:  R09: 
 >> 0fdf
 >>  > [69930.898413] R10: 017d R11: 99b88e6d R12: 
 >> 986c0636b180
 >>  > [69930.898527] R13: 986c05f22000 R14: 986c0632b000 R15: 
 >> 986c0d078010
 >>  > [69930.898641] FS:  () GS:986c1fdc() 
 >> knlGS:
 >>  > [69930.898779] CS:  0010 DS:  ES:  CR0: 80050033
 >>  > [69930.898892] CR2: 7fbe5e9f4ab4 CR3: 00019b40a005 CR4: 
 >> 001606e0
 >>  > [69930.899008] Call Trace:
 >>  > [69930.899121]  scsi_device_dev_release_usercontext+0x55/0x260 [scsi_mod]
 >>  > [69930.899242]  execute_in_process_context+0x5e/0x70
 >>  > [69930.899358]  device_release+0x2d/0x80
 >>  > [69930.899467]  kobject_put+0xa5/0x1a0
 >>  > [69930.899580]  scsi_remove_target+0x171/0x1b0 [scsi_mod]
 >>  > [69930.899699]  sas_rphy_remove+0x55/0x60 [scsi_transport_sas]
 >>  > [69930.899814]  sas_port_delete+0x2a/0x160 [scsi_transport_sas]
 >>  > [69930.899931]  mpt3sas_transport_port_remove+0x1bc/0x220 [mpt3sas]
 >>  > [69930.900053]  _scsih_remove_device+0x21d/0x330 [mpt3sas]
 >>  > [69930.900171]  ? _scsih_sas_host_refresh+0x118/0x180 [mpt3sas]
 >>  > [69930.900290]  _scsih_device_remove_by_handle.part.30+0x78/0xc0 
 >> [mpt3sas]
 >>  > [69930.900407]  _firmware_event_work+0x15c7/0x1d80 [mpt3sas]
 >>  > [69930.900519]  ? update_curr+0xf0/0x1a0

Re: SAS hotswap и баг

2018-04-08 Пенетрантность Artem Chuprina

Артём Н. -> debian-russian@lists.debian.org  @ Sun, 8 Apr 2018 11:37:14 +0300:

 > Вытащил диск, вставил на место, но в /dev его не увидел.
 > Зато увидел вот это в dmesg:

Это там, где ZFS поверх LUKS?  Есть шанс, что ты получил ответ на свой
вопрос, что же ты сделал неправильно.

 > [69497.081559] sd 0:0:5:0: [sdf] Synchronize Cache(10) failed: Result:
 > hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
 > [69916.705257] Buffer I/O error on dev dm-8, logical block 0, async page read
 > [69930.896113] list_del corruption, 986c0632b010->next is LIST_POISON1 
 > (dead0100)
 > [69930.896226] [ cut here ]
 > [69930.896227] kernel BUG at 
 > /build/linux-3RM5ap/linux-4.14.13/lib/list_debug.c:47!
 > [69930.896329] invalid opcode:  [#1] SMP PTI
 > [69930.896416] Modules linked in: xt_nat veth ipt_MASQUERADE
 > nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo
 > iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype
 > xt_conntrack nf_nat nf_conntrack br_netfilter bridge stp llc bonding 
 > xt_tcpudp
 > cpufreq_conservative cpufreq_userspace cpufreq_powersave iptable_filter
 > intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel iTCO_wdt
 > iTCO_vendor_support kvm irqbypass ttm drm_kms_helper intel_cstate 
 > intel_uncore
 > pcspkr intel_rapl_perf serio_raw drm evdev mei_me mei sg lpc_ich mfd_core
 > shpchp ie31200_edac button nuvoton_cir ipmi_si battery ipmi_devintf rc_core
 > ipmi_msghandler tpm_crb video acpi_pad nct6775 hwmon_vid jc42 coretemp
 > ip_tables x_tables autofs4 zfs(PO) zunicode(PO) zavl(PO) icp(PO) zcommon(PO)
 > znvpair(PO)
 > [69930.896925]  spl(O) btrfs zstd_decompress zstd_compress xxhash
 > algif_skcipher af_alg dm_crypt dm_mod raid10 raid456 async_raid6_recov
 > async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c 
 > crc32c_generic
 > raid1 raid0 multipath linear md_mod sd_mod hid_generic usbhid hid
 > crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc
 > aesni_intel aes_x86_64 crypto_simd ahci glue_helper xhci_pci cryptd libahci
 > mpt3sas igb xhci_hcd raid_class i2c_algo_bit libata scsi_transport_sas dca
 > i2c_i801 ptp pps_core usbcore scsi_mod usb_common fan thermal
 > [69930.897315] CPU: 7 PID: 15570 Comm: kworker/u16:2 Tainted: P O
 > 4.14.0-0.bpo.3-amd64 #1 Debian 4.14.13-1~bpo9+1
 > [69930.897462] Hardware name: To Be Filled By O.E.M. To Be Filled By
 > O.E.M./E3C224D4I-14S, BIOS P3.20 05/29/2015
 > [69930.897612] Workqueue: fw_event_mpt2sas0 _firmware_event_work [mpt3sas]
 > [69930.897732] task: 986a138af040 task.stack: bbcfca9a8000
 > [69930.897846] RIP: 0010:__list_del_entry_valid+0x4e/0x90
 > [69930.897958] RSP: 0018:bbcfca9abb48 EFLAGS: 00010086
 > [69930.898070] RAX: 004e RBX: 0246 RCX: 
 > 
 > [69930.898185] RDX:  RSI: 986c1fdd66f8 RDI: 
 > 986c1fdd66f8
 > [69930.898298] RBP: 986c0632b738 R08:  R09: 
 > 0fdf
 > [69930.898413] R10: 017d R11: 99b88e6d R12: 
 > 986c0636b180
 > [69930.898527] R13: 986c05f22000 R14: 986c0632b000 R15: 
 > 986c0d078010
 > [69930.898641] FS:  () GS:986c1fdc() 
 > knlGS:
 > [69930.898779] CS:  0010 DS:  ES:  CR0: 80050033
 > [69930.898892] CR2: 7fbe5e9f4ab4 CR3: 00019b40a005 CR4: 
 > 001606e0
 > [69930.899008] Call Trace:
 > [69930.899121]  scsi_device_dev_release_usercontext+0x55/0x260 [scsi_mod]
 > [69930.899242]  execute_in_process_context+0x5e/0x70
 > [69930.899358]  device_release+0x2d/0x80
 > [69930.899467]  kobject_put+0xa5/0x1a0
 > [69930.899580]  scsi_remove_target+0x171/0x1b0 [scsi_mod]
 > [69930.899699]  sas_rphy_remove+0x55/0x60 [scsi_transport_sas]
 > [69930.899814]  sas_port_delete+0x2a/0x160 [scsi_transport_sas]
 > [69930.899931]  mpt3sas_transport_port_remove+0x1bc/0x220 [mpt3sas]
 > [69930.900053]  _scsih_remove_device+0x21d/0x330 [mpt3sas]
 > [69930.900171]  ? _scsih_sas_host_refresh+0x118/0x180 [mpt3sas]
 > [69930.900290]  _scsih_device_remove_by_handle.part.30+0x78/0xc0 [mpt3sas]
 > [69930.900407]  _firmware_event_work+0x15c7/0x1d80 [mpt3sas]
 > [69930.900519]  ? update_curr+0xf0/0x1a0
 > [69930.900627]  ? pick_next_task_fair+0x156/0x570
 > [69930.900737]  ? __switch_to+0xa8/0x450
 > [69930.900844]  process_one_work+0x181/0x370
 > [69930.900953]  worker_thread+0x4d/0x3c0
 > [69930.901061]  kthread+0xfc/0x130
 > [69930.901168]  ? process_one_work+0x370/0x370
 > [69930.901278]  ? kthread_create_on_node+0x70/0x70
 > [69930.901388]  ret_from_fork+0x1f/0x30
 > [69930.901494] Code: 74 2b 48 8b 12 48 39 d7 75 34 48 8b 50 08 48 39 d7 75 3c
 > b8 01 00 00 00 c3 48 89 fe 48 89 c2 48 c7 c7 60 9e 44 99 e8 7d 21 d5 ff <0f>
 > 0b 48 89 fe 48 c7 c7 98 9e 44 99 e8 6c 21 d5 ff 0f 0b 48 89
 > [69930.901702] RIP: __list_del_entry_valid+0x4e/0x90 RSP: bbcfca9abb48
 > [69930.901816] ---[ end trace b1b41653fc7fb543 ]---

Re: Системы управления сервером?

2018-04-08 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Sun, 8 Apr 2018 11:55:37 +0300:

 >> Ну, еще регулярно лезут подобные баги в криптопротоколах, но там вот как
 >> раз сотни, а то и тысячи ревью, а толку? Потом лет через 10-15 таки
 >> находится тысяча первый ревьюер, который таки замечает багу и делает
 >> эксплойт.
 >> 
 > Может быть из-за ревью он находится через 10-15 лет, а не каждый год на
 > их протяжении?

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

А баги в реализации обычно ловят тесты.

 >> А обычно бага либо легко правится, либо быстро замечается. В идеале и
 >> то, и другое. Совсем в идеале ее ловит юнит-тест еще в процессе
 >> реализации фичи, но так бывает не всегда :)
 >> 
 > Угу, 50% времени на тесты в TDD, которые также могут баги содержать, о
 > чём как-то давно вы сами и писали.

Если считать только время реализации, отдельно от размышлений об
архитектуре, то больше 50%. На глазок, примерно 70. Оно, правда, часто
окупается.

 >>  >>  >>  >> Практика показывает, что читать код _до_ попадания в 
 >> репозиторий - не
 >>  >>  >>  >> очень хорошая идея. Благо репозиторий позволяет, если что, 
 >> откатить.
 >>  >>  >>  >> 
 >>  >>  >>  > Но сборки уже будут собраны и отправлены на тестирование, так не 
 >> лучше
 >>  >>  >>  > ли - не допустить?
 >>  >>  >>  > Какая практика?
 >>  >>  >>  > В чём нехорошесть данной идеи?
 >>  >>  >> 
 >>  >>  >> Тормозной путь. Между моментом изменения кода и моментом, когда код
 >>  >>  >> будет изменен, проходит время.
 >>  >>  > Как минус, так и плюс.
 >>  >> 
 >>  >> В течение этого времени в системе присутствуют и старые, и новые баги.
 >>  >> Где плюс?
 >>  >> 
 >>  > Нет, присутствуют только старые баги, которые уже известны, проверены и
 >>  > одеты в пиджак, так что стали напоминать фичи.
 >> 
 >> В коде они уже есть. В репозиторий еще не попали, а в коде уже есть. И
 >> поверх них уже идет работа.
 >> 
 > Да не идёт поверх них работы, пока их нет в репозитории, иначе процесс
 > неверно построен.

То есть в верно построенном процессе эти два дня никто ничего не делает
ни в чем, завязанном на это место кода? Верно построен процесс, что и
говорить...

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

А это по коду фикса очень трудно понять. Нужен контекст гораздо большего
объема. Тут как раз набор автоматизированных тестов работает не в пример
лучше - в нем этот контекст зафиксирован.

 >>  > А тут новые баги, которые успеют сломать тестирование, например, в
 >>  > результате чего могут не пройти другие тесты и т.п..
 >>  > На ревью есть шанс хоть что-то отсеять (да, я в курсе про юнит-тесты,
 >>  > однако есть факты на практике).
 >> 
 >> На практике тесты для того и существуют, чтобы баги их ломали. Один фиг,
 >> если тест сломался, то багу надо чинить. Если бага сломала сразу много
 >> тестов, починка приоритетна, и все дела.
 >> 
 > Ладно, умолчу про тех, кто "чинит" тесты в таком случае.
 > Такие тоже бывали.
 > Но очень редко тестовое покрытие полное.

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

 >>  >>  > Да, с прерываниями. Но сложно постоянно концентрироваться на ревью и
 >>  >>  > ждать ответов автора (который в этом время уже над другим работает), 
 >> к
 >>  >>  > тому же, ревьюверов бывает несколько.
 >>  >> 
 >>  >> Я про прерывания не процесса ревью, а про прерывания процесса своей
 >>  >> работы необходимостью ревью.  Для ревью надо загрузить в голову контекст
 >>  >> той задачи, к которой относится просматриваемый код.  Он там неизбежно
 >>  >> заменит контекст своей задачи.  После ревью придется снова грузить свой.
 >>  >> Это время, и в случае сложной задачи весьма изрядное.  От 15 минут до
 >>  >> часа каждая перегрузка, а их тут две.
 >>  > Ну час - это явный перебор.
 >> 
 >> Это значит, у тебя все задачи простые.
 >> 
 > Не сказал бы. Ревью компактные относительно. И, естественно, что я не
 > вникаю в весь код: только в изменения.

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

 >>  > А отрыв на 15 минут - не критично: вы же не соревновательным
 >>  > программированием занимаетесь, надеюсь?
 >> 
 >> Каждая перезагрузка. Каждое ревью. Плюс столько же потом вернуться в 
 >> контекст.
 >> 
 > Есть вечер, утро и обед, если не критично.

В обед надо обедать. И мозгом тоже. Иначе очень быстро огребешь гастрит.

 >>  > Иногда вообще полезно от задачи оторваться, бывает.
 >> 
 >> В моем опыте оторваться от задачи полезно, а вот заменять в голове ее
 >> контекст контекстом другой задачи как раз

Re: Системы управления сервером?

2018-03-31 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Sat, 31 Mar 2018 14:18:00 +0300:

 >>  >>  >>  >> За коммитами джуниоров просто присматривают вручную. Недолго, 
 >> человек
 >>  >>  >>  >> либо обучается, либо идет искать работу в другом месте.
 >>  >>  >>  >> 
 >>  >>  >>  > Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, 
 >> код
 >>  >>  >>  > сложный, хотелось бы видеть, что уйдёт в репозиторий.
 >>  >>  >> 
 >>  >>  >> В одной из контор у нас были любители почитать код, уходящий в
 >>  >>  >> репозиторий. Ну, репозиторий был настроен так, чтобы рассылать 
 >> коммиты
 >>  >>  >> желающим. По почте. Тем же способом присматривали за джуниорами.
 >>  >>  >> 
 >>  >>  > Примерно так и есть, но почта заменяется ccollab (или, в общем 
 >> случае,
 >>  >>  > любым web интерфейсом), и код не проходит в репозиторий без 
 >> одобрения.
 >>  >> 
 >>  >> Тут важный момент - не веб или почта "код не проходит в репозиторий без
 >>  >> одобрения". У нас проходил. Мой point в том, что проблем от этого не
 >>  >> происходит.
 >>  >> 
 >>  > Возможно. Надо подумать над этим. Раньше я даже не предполагал такой
 >>  > практики.
 >> 
 >> Собственно, системы управления версиями придуманы ровно для этой
 >> ситуации.  Чтобы заменить трехслойную бюрократию ревью, которая работает
 >> месяц, но тоже пропускает баги, возможностью найти и откатить изменение,
 >> если оно оказалось неудачным.
 >> 
 >> А чтобы неудачное изменение не долетело до заказчика, существует
 >> релизный цикл.  И ревью его необходимости не отменяет.
 >> 
 > Есть минусы, есть плюсы: не так легко откатить сломавшую правку из
 > репозитория, на которую уже понакоммитили и заложили функционал.

Бывает и такое. Но мне в жизни всего однажды встретилась грабля, которую
очень не сразу удалось обнаружить, не брали никакие разумные тесты, и
трудоемко было потом починить. Так и не починили, кстати. Причем по
крайней мере два первых ревью (два разных человека, входивших в разное
время в проект, внимательно читали этот код) она тоже успешно
проскочила.

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

А обычно бага либо легко правится, либо быстро замечается. В идеале и
то, и другое. Совсем в идеале ее ловит юнит-тест еще в процессе
реализации фичи, но так бывает не всегда :)

 >>  >>  >> Практика показывает, что читать код _до_ попадания в репозиторий - 
 >> не
 >>  >>  >> очень хорошая идея. Благо репозиторий позволяет, если что, откатить.
 >>  >>  >> 
 >>  >>  > Но сборки уже будут собраны и отправлены на тестирование, так не 
 >> лучше
 >>  >>  > ли - не допустить?
 >>  >>  > Какая практика?
 >>  >>  > В чём нехорошесть данной идеи?
 >>  >> 
 >>  >> Тормозной путь. Между моментом изменения кода и моментом, когда код
 >>  >> будет изменен, проходит время.
 >>  > Как минус, так и плюс.
 >> 
 >> В течение этого времени в системе присутствуют и старые, и новые баги.
 >> Где плюс?
 >> 
 > Нет, присутствуют только старые баги, которые уже известны, проверены и
 > одеты в пиджак, так что стали напоминать фичи.

В коде они уже есть. В репозиторий еще не попали, а в коде уже есть. И
поверх них уже идет работа.

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

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

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

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

Это значит, у тебя все задачи простые.

 > А отрыв на 15 минут - не критично: вы же не соревновательным
 > программированием занимаетесь, надеюсь?

Каждая перезагрузка. Каждое ревью. Плюс столько же потом вернуться в контекст.

 > Иногда вообще полезно от задачи оторваться, бывает.

В моем опыте оторваться от задачи полезно, а вот заменять

Re: Автоотключение монитора подключённого по HDMI

Andrey Tataranovich -> debian-russian  @ Thu, 29 Mar 2018 16:39:07 +0300:

 >> в /etc/pm/sleep.d скрипт положите.
 >>
 >> что-то вроде
 >>
 >>
 >> case $1)
 >>   suspend|hibernate)
 >> DISPLAY=:0 xrandr --output HDMI1 --off
 >>   ;;
 >> esac
 >>

 > Вот только на системах с systemd это не работает. У systemd собственный
 > обработчик для событий suspend/hibernate и хуки pm-utils не вызываются.

А у своего хуков нет?

Re: Почтовый клиент

D. H. -> debian-russian@lists.debian.org  @ Thu, 29 Mar 2018 08:26:49 -0500:

 >>  > Ага, тут связка с smarthost. Этого дела нету. Интересно можно ли в
 >>  > принципе заставить MTA общаться с другими MTA по томуже 587
 >> 
 >> С любыми - нет. Это submission port, там будут ожидать аутентификации.

 > Тогда буду менять провайдера и не устраивать плясок с бубном вокруг
 > смартхостов и vpn.

 > Хотя можно попробовать на него надавить. За статический адрес плачу, что
 > за ерунда с обрезанием портов блин.

Или так. Я вот недавно по своим пробегался, почитал условия. У них
(обоих) если внешний IP, то резьбы по портам нет.

Re: Почтовый клиент

D. H. -> debian-russian@lists.debian.org  @ Thu, 29 Mar 2018 08:04:37 -0500:

 >> silver (ноутбук):
 >> 
 >> /etc/exim4/update-exim4.conf.conf:
 >> ..
 >> dc_smarthost='nest::587'
 >> ..
 >> 
 >> /etc/exim4/passwd.client:
 >> nest:mailsilver:тутПароль
 > 

 > Ага, тут связка с smarthost. Этого дела нету. Интересно можно ли в
 > принципе заставить MTA общаться с другими MTA по томуже 587

С любыми - нет. Это submission port, там будут ожидать аутентификации.

Re: Почтовый клиент

D. H. -> debian-russian@lists.debian.org  @ Thu, 29 Mar 2018 07:30:20 -0500:

 >> соответственно, входящую почту приходилось пробрасывать через VPN с
 >> виртуалки на хостинге. (VPN тут в принципе не обязательна, достаточно
 >> настроить транспорт через smtps по нестандартному порту, но если она
 >> все равно есть, через нее - проще).

 > А вот тут можно чуть подробнее в случае exim? С ходу как-то не нашлось у
 > меня ответа на этот вопрос. Сейчас тоже через vpn пускаю, но если есть
 > возможность от него отказаться

silver (ноутбук):

/etc/exim4/update-exim4.conf.conf:
...
dc_smarthost='nest::587'
...

/etc/exim4/passwd.client:
nest:mailsilver:тутПароль

Ну, 587 - он стандартный, но у меня его провайдер не перекрывает, только 25.

nest (VPS):
там по ряду причин конфиг полностью самописный, зато экзимовский, а не 
дебиановский. Из релевантного:

daemon_smtp_ports = 25 : 465 : 587
tls_on_connect_ports = 465
(на 587, соответственно, STARTTLS)

acl_check_mail:
warn hosts = : @[]
 control = submission
warn authenticated = *
 control = submission/sender_retain
 set acl_c_relay = true
 set acl_c_skip_sa = true
 set acl_c_skip_greylist = true
 set acl_c_skip_spamtrap = true
(переменные используются в соответствующих местах, но идея понятна)

acl_check_rcpt:
# если мы это письмо релеим - проверяем получателя и принимаем
deny condition = $acl_c_relay
 !verify = recipient/defer_ok
accept condition = $acl_c_relay
(это вот существенное место, именно тут решается, что делать с
аутентифицироваными клиентами)

begin authenticators

dovecot_login:
driver = dovecot
public_name = LOGIN
server_advertise_condition = ${if eq{$tls_cipher}{}{no}{yes}}
server_socket = /var/run/dovecot/auth-client
server_set_id = $auth1

dovecot_plain:
driver = dovecot
public_name = PLAIN
server_advertise_condition = ${if eq{$tls_cipher}{}{no}{yes}}
server_socket = /var/run/dovecot/auth-client
server_set_id = $auth1

(у меня dovecot IMAP-сервером, заодно об него и аутентифицируем; а он,
соответственно, уже об PAM)

Re: Почтовый клиент

Евгений Кабанов -> Debian-russian  @ Thu, 29 Mar 2018 12:04:44 +0300:

 >> Ходить по imap это правильно. Почта должна лежать в  одном месте, и
 >> это место должно быть доступно по imap.

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

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

Если канал слабый (читай: слишком высокое время отклика), то
offlineimap. Предварительно, перед выездом из дома,
засинхронизированный, чтобы не пришлось качать лишнего. Запустил его, и
пошел мыться. Пока мылся, он накопившуюся почту скачал. У меня он
работает поверх ssh. Он умеет на этом конце тоже IMAP и Maildir. Скажу
сразу, не умеет отследить, что письмо было перемещено из одного фолдера
в другой. Умеет НЕ синхронизировать обратно, но у меня синхронизирует.

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

Re: Системы управления сервером?

2018-03-28 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Tue, 27 Mar 2018 23:35:21 +0300:

 >>  >>  >> В идеале пишутся тесты. Часть заранее, часть по мере наступания на
 >>  >>  >> грабли :) Код на Haskell и Scala даже и не тестируется 
 >> автомагически,
 >>  >>  >> настолько мало там багов, что написание тестов не окупается.
 >>  >>  >> 
 >>  >>  > Ну это две параллельные задачи. Часто тесты нельзя написать.
 >>  >> 
 >>  >> Если тесты нельзя написать, то код негодный. Другое дело, что на
 >>  >> написание тестов не всегда хватает ресурса.
 >>  >> 
 >>  > Ну почему сразу "код"? А взаимодействие с аппаратурой? Моки каждый раз
 >>  > делать?
 >> 
 >> Не каждый. Для unit-тестирования да, а для acceptance подключать
 >> аппаратуру, ага.
 >> 
 > А она бажная. Как факт. Потому что тоже разрабатывается.

Именно поэтому для acceptance, или, точнее, для integration, ее надо подключать.

 >>  >> Если более тысячи программистов отвечают за одно место в коде, код
 >>  >> работать не будет. В больших конторах за каждое место в коде отвечает
 >>  >> очень небольшое количество людей, а протоколы взаимодействия между кодом
 >>  >> разных отделов компактны.
 >>  >> 
 >>  >>  >> За коммитами джуниоров просто присматривают вручную. Недолго, 
 >> человек
 >>  >>  >> либо обучается, либо идет искать работу в другом месте.
 >>  >>  >> 
 >>  >>  > Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, код
 >>  >>  > сложный, хотелось бы видеть, что уйдёт в репозиторий.
 >>  >> 
 >>  >> В одной из контор у нас были любители почитать код, уходящий в
 >>  >> репозиторий. Ну, репозиторий был настроен так, чтобы рассылать коммиты
 >>  >> желающим. По почте. Тем же способом присматривали за джуниорами.
 >>  >> 
 >>  > Примерно так и есть, но почта заменяется ccollab (или, в общем случае,
 >>  > любым web интерфейсом), и код не проходит в репозиторий без одобрения.
 >> 
 >> Тут важный момент - не веб или почта "код не проходит в репозиторий без
 >> одобрения". У нас проходил. Мой point в том, что проблем от этого не
 >> происходит.
 >> 
 > Возможно. Надо подумать над этим. Раньше я даже не предполагал такой
 > практики.

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

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

 >>  >> Практика показывает, что читать код _до_ попадания в репозиторий - не
 >>  >> очень хорошая идея. Благо репозиторий позволяет, если что, откатить.
 >>  >> 
 >>  > Но сборки уже будут собраны и отправлены на тестирование, так не лучше
 >>  > ли - не допустить?
 >>  > Какая практика?
 >>  > В чём нехорошесть данной идеи?
 >> 
 >> Тормозной путь. Между моментом изменения кода и моментом, когда код
 >> будет изменен, проходит время.
 > Как минус, так и плюс.

В течение этого времени в системе присутствуют и старые, и новые баги.
Где плюс?

 >> Либо это очень большое время, либо
 >> ревьюер работает с частыми прерываниями. Если у него содержательная
 >> работа не обезьянья, то частые прерывания очень сильно снижают его
 >> продуктивность. Так и так изрядно падает КПД.
 >>
 > Ну, допустим, пара дней на ревью - это большое время?

Офигительно.  За это время я успею еще много чего сделать, и оно будет
пересекаться по коду с теми изменениями, и если изменение не примут как
есть, то попытка что-то там подкрутить приведет к конфликтам с точки
зрения VCS.  А разбор конфликта - одно из самых багопродуцирующих
действий.  И результатом его оказывается патч, разбираться в котором -
уже два полных рабочих дня, а не просто задержка на пару дней.

 > Да, с прерываниями. Но сложно постоянно концентрироваться на ревью и
 > ждать ответов автора (который в этом время уже над другим работает), к
 > тому же, ревьюверов бывает несколько.

Я про прерывания не процесса ревью, а про прерывания процесса своей
работы необходимостью ревью.  Для ревью надо загрузить в голову контекст
той задачи, к которой относится просматриваемый код.  Он там неизбежно
заменит контекст своей задачи.  После ревью придется снова грузить свой.
Это время, и в случае сложной задачи весьма изрядное.  От 15 минут до
часа каждая перегрузка, а их тут две.

 >>  >> Это вот понятное употребление ревью. Очень громоздкое, но цена ошибки
 >>  >> там такова, что оно окупается.
 >>  >> 
 >>  > В случае того, что есть сейчас, коммиты тоже обосновываются: к ним
 >>  > привязана задача, после чего проверяются (перед репозиторием).
 >> 
 >> А "в случае того, что есть сейчас" непонятно, окупается ли этот
 >> тормозной путь.
 >> 
 > Продукт окупается.
 > "Тормозной путь", скорее всего, да.
 > Не от хорошей жизни, а из-за некоторых разработчиков и сжатых сроков.

Вот тут уже сомнения.  Если сжатые сроки, то потеря в среднем получаса
на каждое ревью...  Это какие же должны быть разработчики, чтобы оно
окупалось?

 >>  >>  >>

Re: Системы управления сервером?

2018-03-27 Пенетрантность Artem Chuprina

artiom -> debian-russian@lists.debian.org  @ Mon, 26 Mar 2018 20:53:38 +0300:

 >>  >> В идеале пишутся тесты. Часть заранее, часть по мере наступания на
 >>  >> грабли :) Код на Haskell и Scala даже и не тестируется автомагически,
 >>  >> настолько мало там багов, что написание тестов не окупается.
 >>  >> 
 >>  > Ну это две параллельные задачи. Часто тесты нельзя написать.
 >> 
 >> Если тесты нельзя написать, то код негодный. Другое дело, что на
 >> написание тестов не всегда хватает ресурса.
 >> 
 > Ну почему сразу "код"? А взаимодействие с аппаратурой? Моки каждый раз
 > делать?

Не каждый. Для unit-тестирования да, а для acceptance подключать
аппаратуру, ага.

 > А работа при загрузке ОС?

И это тоже надо тестировать. Ну да, придется контейнер тюнить.

 >>  > Плюс, на ревью проверяется читабельность кода и его логическая
 >>  > корректность (и тесты, и код возможно написать некорректно).  Плюс, в
 >>  > два раза больше работы.  В общем, одно другое не заменяет.
 >> 
 >> Я не утверждал, что тестирование заменяет ревью. Я утверждал, что в
 >> процессах, которые применяются там, где я работал, ревью отсутствует.
 >> 
 > Понял вас. Хотя, всё-равно не могу представить. У меня опыт поменьше, но
 > всё-таки, в трёх достаточно известных конторах, где я работал, ревью
 > имеется, причём через WEB GUI.

Известная контора - еще далеко не гарантия качества результата :)

 >> Если более тысячи программистов отвечают за одно место в коде, код
 >> работать не будет. В больших конторах за каждое место в коде отвечает
 >> очень небольшое количество людей, а протоколы взаимодействия между кодом
 >> разных отделов компактны.
 >> 
 >>  >> За коммитами джуниоров просто присматривают вручную. Недолго, человек
 >>  >> либо обучается, либо идет искать работу в другом месте.
 >>  >> 
 >>  > Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, код
 >>  > сложный, хотелось бы видеть, что уйдёт в репозиторий.
 >> 
 >> В одной из контор у нас были любители почитать код, уходящий в
 >> репозиторий. Ну, репозиторий был настроен так, чтобы рассылать коммиты
 >> желающим. По почте. Тем же способом присматривали за джуниорами.
 >> 
 > Примерно так и есть, но почта заменяется ccollab (или, в общем случае,
 > любым web интерфейсом), и код не проходит в репозиторий без одобрения.

Тут важный момент - не веб или почта "код не проходит в репозиторий без
одобрения". У нас проходил. Мой point в том, что проблем от этого не
происходит.

 >> Практика показывает, что читать код _до_ попадания в репозиторий - не
 >> очень хорошая идея. Благо репозиторий позволяет, если что, откатить.
 >> 
 > Но сборки уже будут собраны и отправлены на тестирование, так не лучше
 > ли - не допустить?
 > Какая практика?
 > В чём нехорошесть данной идеи?

Тормозной путь. Между моментом изменения кода и моментом, когда код
будет изменен, проходит время. Либо это очень большое время, либо
ревьюер работает с частыми прерываниями. Если у него содержательная
работа не обезьянья, то частые прерывания очень сильно снижают его
продуктивность. Так и так изрядно падает КПД.

 >> Это вот понятное употребление ревью. Очень громоздкое, но цена ошибки
 >> там такова, что оно окупается.
 >> 
 > В случае того, что есть сейчас, коммиты тоже обосновываются: к ним
 > привязана задача, после чего проверяются (перед репозиторием).

А "в случае того, что есть сейчас" непонятно, окупается ли этот
тормозной путь.

 >>  >>  >> В общем, даже модель pull request не использовали, не говоря уже о 
 >> code
 >>  >>  >> review. А вот работу в паре как раз использовали.
 >>  >>  >> 
 >>  >>  > А подробнее? Это из области "экстремального программирования"?
 >>  >> 
 >>  >> Да. Просто садятся двое. Один за клавиатурой, он код пишет. Второй
 >>  >> рядом, он смотрит, что пишет первый. Его задача - взгляд уровнем
 >>  >> абстракции выше, чем у писателя. Чтобы прямо по ходу иметь возможность
 >>  >> сказать "ты решаешь не ту задачу" или "ты сейчас подложил вот сюда вот
 >>  >> такие грабли".
 >>  >> 
 >>  >> Результаты различного качества, в зависимости в основном от дисциплины
 >>  >> написания тестов. Но так, чтобы было неработоспособно - нет. Чаще
 >>  >> вылетает аппаратура, чем вылезают не дающие работать баги.
 >>  >> 
 >>  > Только читал об этом, не думал, что в РФ используется.
 >> 
 >> Это парадигма, ей чихать на государственные границы.
 >> 
 > Границы не при чём, имеет значение "менталитет", в общем и, в частности:
 > культура разработки и стоимость такого подхода.

Менталитет программиста тоже интернационален. С менталитетом "кодера по
обезьяньей работе" хуже, но extreme programming - технология для
программистов.

 >>  > В любом случае, если я такое (чисто теоретически) предложу менеджеру,
 >>  > он только у виска покрутит. Это же получается, что каждый программист
 >>  > работает, условно половину времени, а половину сидит "и что-то там
 >>  > смотрит".

 >> А если тебе не результат а имитацию бурной деятельности для менеджера,
 >> то да, подход ровно обратный.
 > В конкретном

Re: Системы управления сервером?

2018-03-25 Пенетрантность Artem Chuprina

Alexander Gerasiov -> debian-russian@lists.debian.org  @ Sun, 25 Mar 2018 
19:16:36 +0300:

 >>  > Артем, при работе с джунами очень удобно ткнуть мышой в место в
 >>  > коде/диффе и написать, что тут не так и как поправить. Особенно,
 >>  > когда таких мест десяток. Без этого приходится либо сажать рядом и
 >>  > показывать, либо в ядерном стиле, когда дифф в почте комментируется
 >>  > инлайн.
 >>  > Так что не надо топить вебинтерфейсы, у них иногда действительно
 >>  > есть плюсы.  
 >> 
 >> Эффективнее всего - именно сажать рядом и показывать.
 > Но для этого хорошо бы предварительно откомментировать, иначе сам потом
 > сходу не вспомишь, когда будешь объяснять, все замечания - это раз, и
 > джуниор не вспомнит все замечания, когда будет их править - два.

Ну, да, полезно. Нет, не в браузере - как текстовый редактор он очень неудобен.

Re: Системы управления сервером?

artiom -> debian-russian@lists.debian.org  @ Sat, 24 Mar 2018 16:46:36 +0300:

 >>> Впечатлился статьёй.
 >>> Айн: https://habrahabr.ru/post/328048/
 >>> Цвайн:
 >>> https://forum.level1techs.com/t/how-to-create-a-nas-using-zfs-and-proxmox-with-pictures/117375
 >>>
 >>> Помимо Proxmox, есть такая штука, как Cockpit:
 >>> http://cockpit-project.org
 >>>
 >>> О нём я ничего не знаю.
 >>> Собственно, Proxmox я тоже не использовал.
 >>>
 >>> Основные задачи:
 >>>
 >>> - Отделение сервисов путём контейнеризации (docker+lxc, возможно будет
 >>> использован kvm в редких случаях).
 >> Используем Proxmox.
 >> 
 > Вот ещё насчёт Proxmox: возможно ли его поставить в Docker контейнер и
 > стоит ли это делать?

А потом все это запустить на VirtualBox, запущенном под VmWare?

Re: Системы управления сервером?

artiom -> debian-russian@lists.debian.org  @ Sat, 24 Mar 2018 16:59:02 +0300:

 >>  >> Больше 15 лет работаю с кодом в коллективах. Ни разу не использовали
 >>  >> никаких гитлабов и вообще никаких уеб-интерфейсов. Никаких сложностей, и
 >>  >> код работает.
 >>  >> 
 >>  > 1. Сейчас, где я работаю, используется TFS, прости Господи. Под Linux.
 >>  > Ревью проводится через CodeCollaborator. Это наследие такое. Гит тоже
 >>  > есть, но пока не везде.
 >>  > 2. Объективно лучше, чем ccollab, интерфейсы gitlab и bitbucket. Для
 >>  > всех без исключений. Даже те, кто больше всех матерился из-за перехода
 >>  > на git, в разных конторах, в итоге признавали, что "эти web-интерфейсы
 >>  > удобнее".
 >> 
 >>  > Не опровергаю ваш опыт, но узнать было бы интересно: как так?
 >>  > Т.е.:
 >> 
 >>  > - Первый вопрос: это код на Haskell, не C/C++ + Python + Lua + Bash + 
 >> etc.?
 >> 
 >> C, C++, Smalltalk, Haskell, Scala, tcl.
 >> 
 >>  > - Как проводится процесс контроля и устранения недостатков?
 >> 
 >> В идеале пишутся тесты. Часть заранее, часть по мере наступания на
 >> грабли :) Код на Haskell и Scala даже и не тестируется автомагически,
 >> настолько мало там багов, что написание тестов не окупается.
 >> 
 > Ну это две параллельные задачи. Часто тесты нельзя написать.

Если тесты нельзя написать, то код негодный. Другое дело, что на
написание тестов не всегда хватает ресурса.

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

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

 >>  > - Если несколько ревьюверов, как они просматривают код и вносят 
 >> замечания?
 >> 
 >> Их нет. Ревьюеров, в смысле. В одной из предыдущих контор был мем "кто
 >> первый встал, того и грабли". В смысле, багу исправляет тот, кто на нее
 >> наступил (или взялся за багрепорт). Это обеспечивает коллективное
 >> владение кодом. В отличие от code review, которое все-таки нет. При
 >> необходимости {git,svn,cvs} annotate и зовем автора проблемного
 >> места. Но это нужно очень не всегда.
 >> 
 > Но если в конторе более тысячи программистов, а за код отвечают разные
 > отделы, причём часть людей, его написавших, уже давно не работает, будет
 > ли такая схема эффективна (это не к моему случаю, а в общем)?

А в общем задача неразрешима. Это еще Гёдель доказал :) Решается всегда
в конкретном.

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

 >> За коммитами джуниоров просто присматривают вручную. Недолго, человек
 >> либо обучается, либо идет искать работу в другом месте.
 >> 
 > Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, код
 > сложный, хотелось бы видеть, что уйдёт в репозиторий.

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

Практика показывает, что читать код _до_ попадания в репозиторий - не
очень хорошая идея. Благо репозиторий позволяет, если что, откатить.

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

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

 >>  >> В общем, даже модель pull request не использовали, не говоря уже о code
 >>  >> review. А вот работу в паре как раз использовали.
 >>  >> 
 >>  > А подробнее? Это из области "экстремального программирования"?
 >> 
 >> Да. Просто садятся двое. Один за клавиатурой, он код пишет. Второй
 >> рядом, он смотрит, что пишет первый. Его задача - взгляд уровнем
 >> абстракции выше, чем у писателя. Чтобы прямо по ходу иметь возможность
 >> сказать "ты решаешь не ту задачу" или "ты сейчас подложил вот сюда вот
 >> такие грабли".
 >> 
 >> Результаты различного качества, в зависимости в основном от дисциплины
 >> написания тестов. Но так, чтобы было неработоспособно - нет. Чаще
 >> вылетает аппаратура, чем вылезают не дающие работать баги.
 >> 
 > Только читал об этом, не думал, что в РФ используется.

Это парадигма, ей чихать на государственные границы.

 > В любом случае, если я такое (чисто теоретически) предложу менеджеру,
 > он только у виска покрутит. Это же получается, что каждый программист
 > работает, условно половину времени, а половину сидит "и что-то там
 > смотрит".

А если тебе не результат а имитацию бурной деятельности для менеджера,
то да, подход

Re: Системы управления сервером?

artiom -> debian-russian@lists.debian.org  @ Sat, 24 Mar 2018 17:00:47 +0300:

 >> Artem Chuprina <r...@lasgalen.net> wrote:
 >> 
 >> Артем, при работе с джунами очень удобно ткнуть мышой в место в

...

 >> Так что не надо топить вебинтерфейсы, у них иногда действительно есть плюсы.
 >> 
 > В каком смысле? Что я "топлю"? Я так и делаю обычно (комментирую
 > строчки, либо показываю, что не так), а сейчас ищу для себя подходящий
 > интерфейс.

Ты просто читаешь не все буквы. Иногда зря. Имя в письме прочел, а
фамилию в квоте - нет.

Re: Системы управления сервером?

Alexander Gerasiov -> debian-russian@lists.debian.org  @ Sat, 24 Mar 2018 
14:45:18 +0300:

 >>  >> В зависимости от сценария разработки - пуш на приватную ветку или
 >>  >> в свой репозиторий и дальше пулл-реквест, где мейнтейнер смотрит
 >>  >> дифф, оставляет комментарии (но не к строчкам кода/диффа, а
 >>  >> только к реквесту в целом) и аксептит или реджектит.
 >>  >> 
 >>  >>   
 >>  > Ладно, хотя бы реквесты есть.
 >>  > Но если больше 10 файлов в мердже, не особенно представляю, как с
 >>  > этим работать.
 >>  > Сам я работал с гитовыми репозиториями через gitlab и с bitbucket
 >>  > (ну да, если считать, что гогс повторяет интерфейс гитхаб, то и с
 >>  > ним, только с ревью), и без комментариев к строчкам, как-то
 >>  > коллективно работать с кодом было бы весьма сложно.  
 >> 
 >> Больше 15 лет работаю с кодом в коллективах. Ни разу не использовали
 >> никаких гитлабов и вообще никаких уеб-интерфейсов. Никаких
 >> сложностей, и код работает.
 >> 
 >> В общем, даже модель pull request не использовали, не говоря уже о
 >> code review. А вот работу в паре как раз использовали.

 > Артем, при работе с джунами очень удобно ткнуть мышой в место в
 > коде/диффе и написать, что тут не так и как поправить. Особенно, когда
 > таких мест десяток. Без этого приходится либо сажать рядом и
 > показывать, либо в ядерном стиле, когда дифф в почте комментируется
 > инлайн.
 > Так что не надо топить вебинтерфейсы, у них иногда действительно есть плюсы.

Эффективнее всего - именно сажать рядом и показывать.

А если говорить о переписке, то логичнее поправить, закоммитить, и
прокомментировать _свой_ коммит.

Re: Системы управления сервером?