Re: systemd

[Sergey B Kirpichev]

On Fri, Nov 13, 2015 at 11:54:25PM +0300, Dmitry E. Oboukhov wrote:
> >> что сказать, да - голосовал в голосованиях, да спорил в IRC.
> >> да в рассылке поддержал тех кто сказал что "когда в Debian нельзя
> >> будет жить без systemd, я уйду из Debian", но этого всего недостаточно
> >> разумеется.
> 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6661
> > весь вклад русскоязычных DD в дискуссию ctte.  Самое время
> > премудрым пескарям удивляться итогам голосования.
> 
> в голосовании я не имел права принимать участие, но я в него таки
> отправил свой голос.

Там шло обсуждение, я о нем.

> но у нас увы всего восемь DD в России

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

Re: systemd

[Victor Wagner]

В Sun, 15 Nov 2015 16:45:08 +0300
Иван Лох  пишет:

> On Sun, Nov 15, 2015 at 04:17:28PM +0300, Sergey B Kirpichev wrote:
> > 
> > Выглядит дело так, как будто народ все менее спешит обновлять
> > десктоп с каждым новым релизом Debian.  Видимо этот процесс
> > становится все более болезненным.  Хотя железки поддерживаются
> > ощутимо лучше, казалось бы...
> 
> Это чисто социальный феномен. Не знаю кому как, но мне раньше
> миграции давались сложней. Тот же переход на glibc чего стоил.
> Там вообще невозможно было понять зачем это нужно. Вообще,

Там как раз было понятно зачем, хотя за давностью лет подробностей не
помню. Тем более что для меня этот переход совпал с переходом с RH на
Debian.

> критика, хейтинг разный были и раньше, но то что происходит
> с systemd IMHO групповая истерия просто.
> То сколь неудобно и мутно debian перешел на multiarch

А Debian перешел на multiarch? По мне в Debian как не было multiarch,
так и нет. Единственная задача, которую этот multiarch решает - это
запуск skype на 64-битной системе.

А так ни запуска на 32-битной системе отдельных 64-битных программ, ни
нормальной кросс-сборки пакетов что-то не видно. 

Вот скажем, попробовал я поставить на 32-битный jessie 64-битные qemu,
inn, hugin, docker.io. Получилось только с qemu. Все остальные
почему-то начинают ругаться что пакет с архитектурой _all их
зависимости не удовлетворяет. Или make хотят обязательно совпадающей
архитектуры.

А в Solaris это еще в прошлом веке умели.

 
> (я кстати, не говорю, что знаю пути проще) никого не волнует
> только потому что в интернетиках истерики нет.

Говорят, в ArchLinux сделали сильно лучше. Во всяком случае там есть
работающая процедура кроссгрейда с 32 на 64.

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

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

-- 
   Victor Wagner 

Re: systemd

[Иван Лох]

On Sun, Nov 15, 2015 at 05:30:14PM +0300, Victor Wagner wrote:
> > То сколь неудобно и мутно debian перешел на multiarch
> 
> А Debian перешел на multiarch? По мне в Debian как не было multiarch,
> так и нет. Единственная задача, которую этот multiarch решает - это
> запуск skype на 64-битной системе.
> 
> А так ни запуска на 32-битной системе отдельных 64-битных программ, ни
> нормальной кросс-сборки пакетов что-то не видно. 
> Вот скажем, попробовал я поставить на 32-битный jessie 64-битные qemu,
> inn, hugin, docker.io. Получилось только с qemu. Все остальные

Отдельные 64-битные программы не из дистрибутива можно запускать. 
После обработки напильником. С недавних пор ядро из amd64 можно
ставит на i386 дебиан. Хотя тоже с косяками. Но я то о том, что реально
система про штатном обновлении (unstable, конечно) ломалась до
необходимости использовать busybox-static
С systemd проблемы все-таки меньшего масштаба
> 

Re: systemd

[Иван Лох]

On Sun, Nov 15, 2015 at 04:17:28PM +0300, Sergey B Kirpichev wrote:
> 
> Выглядит дело так, как будто народ все менее спешит обновлять
> десктоп с каждым новым релизом Debian.  Видимо этот процесс
> становится все более болезненным.  Хотя железки поддерживаются
> ощутимо лучше, казалось бы...

Это чисто социальный феномен. Не знаю кому как, но мне раньше
миграции давались сложней. Тот же переход на glibc чего стоил.
Там вообще невозможно было понять зачем это нужно. Вообще,
критика, хейтинг разный были и раньше, но то что происходит
с systemd IMHO групповая истерия просто.
То сколь неудобно и мутно debian перешел на multiarch
(я кстати, не говорю, что знаю пути проще) никого не волнует
только потому что в интернетиках истерики нет.

Re: systemd

[Sergey B Kirpichev]

On Sat, Nov 14, 2015 at 10:31:11PM +0300, Pavel Volkov wrote:
> On среда, 11 ноября 2015 г. 14:34:40 MSK, sergio wrote:
> >Всем привет.
> >
> >Внезапно я поставил себе дебиан на десктоп и решил посмотреть есть ли
> >жизнь на systemd.
> >
> 
> Я в шоке, думал время прошло, страсти поутихли,  до сих пор холивары на 160
> сообщений.

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

Re: systemd

[Artem Chuprina]

Alexey Shrub -> Debian Russian Mailing List  @ Sat, 14 Nov 2015 09:02:15 +0300:

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

 AS> Да, может и знать, только не нарушая DRY, т.е. он должен читать конфиг 
демона
 AS> и оттуда брать информацию о том что и где чистить и при это гадить в 
системные
 AS> и в логи демона что о делает. Только в таком варианте это будет 
относительно
 AS> нормально.

Или писать в конфиг демона.  Вернее (и это часто делают), в параметры
командной строки.

 AS> По данному примеру - раз systemd уже взялся подчищать за процессом (судя по
 AS> приведёным ранее его опциям), то значит ему этим и заниматься, если он 
где-то
 AS> не дорабатывает, то делаем временный костыль и пишем багрепорт.

Ну, тут, пожалуй, да, соглашусь.  Если функциональность есть в
запускалке, ее и использовать.

 AS> Вобщем мне кажется по вопросу шел скрипты vs конфиги мы зашли в тупик, моё
 AS> чувство архитектуры говорит мне что если можно использовать конфиг вместо
 AS> языка программирования то так и надо делать, это защита от ошибок и дыр в
 AS> безопасности. Но видимо каждый останется при своём мнении.

А вот тут я бы предложил глянуть чуть шире.

Язык конфига - это тоже язык программирования.  Только это декларативный
DSL.  Впрочем, если глянуть шире, то все языки программирования - DSL,
только для D разной ширины.  Конкретно sh - DSL для взаимодействия
словами между пользователем и операционной системой, предназначенный для
двух целей - интерактивного взаимодействия и автоматизации выработанного
в оном интерактивном взаимодействии (бизнес-)процесса.

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

На самом деле, насколько я понимаю, в целях иллюстрации кривизны мощного
DSL надо приводить вообще не systemd, а exim.  Из того, что я в жизни
видел, кривее только язык досовско-виндовых батников (от .bat до .cmd),
и то в сравнении с sh.

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

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

С systemd, насколько я понимаю, ситуация все же получше, но осложняется
тем, что его DSL поначалу имел недостаточную выразительную силу, и все
еще идет ее наращивание.  С соответствующим усложнением языка.

Может быть, конфигам systemd и можно было бы доверить систему
инициализации более, чем скриптам SysV init.  Если бы можно было
доверить жизнеспособность системы самому systemd...

Re: systemd

[Artem Chuprina]

Egorov N.V. -> Alexey Shrub  @ Sat, 14 Nov 2015 12:31:29 +0300:

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

 EN> А у вас есть гарантия что вам отвечает ваша-же программа, или что
 EN> программа той-же версии что ваша? Если нет, то валидация всех полей,
 EN> особенно на переполнение, преобразование во внутренне представление и
 EN> так далее. 

 EN> Та же самба торпеду в протокол много раз получала, причем с исполнение
 EN> произвольного кода - ну что-то не провалидировали.

 EN> С текстом устроить такую подлость гораздо сложнее...

Ой, да ладно...  SQL injection, Javascript injection, XSS...

Проблема валидации недоверенных данных для текста стоит в тот же полный
рост.

Re: Устаревшие автосоздаваемые пользователи и группы

[Alexander Galanin]

On Sat, 14 Nov 2015 20:14:18 +0300 (MSK)
yuri.nefe...@gmail.com wrote:

> > 1. Как определить принадлежность пользователя/группы к пакету. Не всё
> >   перечислено в документации к base-passwd и не всё удаётся угадать по
> >   имени.
>   Некоторые советы содержатся тут (раздел 12.1.12)
>   https://www.debian.org/doc/manuals/securing-debian-howto/ch12.en.html

Я брал этот список из /usr/share/doc/base-passwd/users-and-groups.txt.gz,
там то же самое.

-- 
Alexander Galanin

Re: Устаревшие автосоздаваемые пользователи и группы

[Artem Chuprina]

yuri.nefe...@gmail.com -> debian-russian@lists.debian.org  @ Sun, 15 Nov 2015 
20:38:58 +0300 (MSK):

  Если при помощи «-fstab ext4» вы хотели записать условие на только
  корень, без других подмонтированных в него разделов, то это можно
  более корректно сформулировать как «-xdev».
 
 >>>Нет, это я что бы find по сетевой файловой системе (afs) не лазил.
 >>>А в локальных смонтированных пускай ищет. Вообще, да,
 >>>правильнее было бы сначала сетевые fs остановить.
 >>
 >> Я пошел сверился с руководством — и выходит, что это вовсе не прокатит.
 >>
 >> ‘-fstab’ в отличие от ‘-xdev’ (она же ‘-mount’) — это не опция (как
 >> ‘-maxdepth’), а условие (как ‘-name’), что должно значить, что find все
 >> равно пройдется по не-экст-4 файловым системах, переберет на них каждый
 >> файл, но все отвергнет, кто бы ни был владельцем.
 >>
 >> Нет?
 >>
 y>   Не fstab a fstype.

 y>   Похоже, что, да вы правы, это тест, ну и если подумать, иначе быть
 y>   и не может.  То-то оно у меня тормозило жутко.

 y>   А как бы тогда корректно исключить все сетевые фс?

С -prune скомпоновать.  Тогда, по идее, оно наткнется на точку
монтирования сетевой fs, увидит там нужный fstype, и вглубь не полезет.

Другое дело, что выражение логики у find несколько неинтуитивно.

Re: systemd

[Stanislav Vlasov]

13 ноября 2015 г., 20:10 пользователь Andrey Melnikoff
 написал:
>> > > Проблема не надуманая, проблема из-за реализации PCI device
>> > > enumeration которая приводила к тому, что при следующей загрузке
>> > > сетевые карты могли быть обнаружены в другом порядке.  Что могло
>> > > привести к недоступности машины с двумя сетевыми картами после
>> > > перезагрузки.
>> > надуманная. BIOS сам по себе не меняется, рядом будет админ который
>> Причем здесь биос? Просто в результате перезагрузки по отключению
>> питания что-то измениться могло.
> Не увиливай от ответа. Каким образом могла измениться енумерация сама по
> себе после падения по питанию?

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

-- 
Stanislav

Re: Устаревшие автосоздаваемые пользователи и группы

[yuri . nefedov]

On Sun, 15 Nov 2015, Dmitry Alexandrov wrote:


On 14/11/15 23:13, yuri.nefe...@gmail.com wrote:

On Sat, 14 Nov 2015, Dmitry Alexandrov wrote:

Если при помощи «-fstab ext4» вы хотели записать условие на только
корень, без других подмонтированных в него разделов, то это можно
более корректно сформулировать как «-xdev».


   Нет, это я что бы find по сетевой файловой системе (afs) не лазил.
   А в локальных смонтированных пускай ищет. Вообще, да,
   правильнее было бы сначала сетевые fs остановить.


Я пошел сверился с руководством — и выходит, что это вовсе не прокатит.

‘-fstab’ в отличие от ‘-xdev’ (она же ‘-mount’) — это не опция (как 
‘-maxdepth’), а условие (как ‘-name’), что должно значить, что find все равно 
пройдется по не-экст-4 файловым системах, переберет на них каждый файл, но 
все отвергнет, кто бы ни был владельцем.


Нет?


  Не fstab a fstype.

  Похоже, что, да вы правы, это тест, ну и если подумать, иначе быть
  и не может.  То-то оно у меня тормозило жутко.

  А как бы тогда корректно исключить все сетевые фс?
  Можно конечно -mount и перечислить все локальные точки монтировки,
  но это не очень красиво получается. Хотя,.. эффективно.
  Попробовал, теперь за секунды отрабатывает.
  Спасибо.
Ю.

Re: systemd

[Victor Wagner]

В Sun, 15 Nov 2015 18:01:13 +0300
Иван Лох  пишет:

> On Sun, Nov 15, 2015 at 05:30:14PM +0300, Victor Wagner wrote:
> > > То сколь неудобно и мутно debian перешел на multiarch
> > 
> > А Debian перешел на multiarch? По мне в Debian как не было
> > multiarch, так и нет. Единственная задача, которую этот multiarch
> > решает - это запуск skype на 64-битной системе.
> > 
> > А так ни запуска на 32-битной системе отдельных 64-битных программ,
> > ни нормальной кросс-сборки пакетов что-то не видно. 
> > Вот скажем, попробовал я поставить на 32-битный jessie 64-битные
> > qemu, inn, hugin, docker.io. Получилось только с qemu. Все остальные
> 
> Отдельные 64-битные программы не из дистрибутива можно запускать. 
> После обработки напильником. С недавних пор ядро из amd64 можно
> ставит на i386 дебиан. Хотя тоже с косяками. Но я то о том, что

Ядро от amd64 можно было еще то ли  в lenny, то ли в sarge ставить. 
У меня стояло пять лет назад. И "отдельная программа не из
дистрибутива" - VMWare server вполне под ним работала, позволяя для
того же соляриса создавать 64-битные виртуальные машины.

Это было задолго до всякого multiarch.

По-моему. то что заявлялось как multiarch это именно возможность
пакетным менеджером работать одновременно с пакетами нескольких
архитектур. И эта задача до сих пор не решена, в то время как
альтернативные решения частных задач (dpkg-cross, например) уже
похерили.

> реально система про штатном обновлении (unstable, конечно) ломалась до
> необходимости использовать busybox-static

unstable имеет право ломаться при штатном обновлении.

> С systemd проблемы все-таки меньшего масштаба

Большего. с появлением systemd стало невозможным из stable  (тогда
wheezy) использовать lxc-контейнеры с testing. Это, кстати, по-моему до
сих пор в вики написано - если хотите иметь в контейнере систему с
systemd, снаружи от контейнера тоже должен быть systemd. Или еще
какие-то компоненты не старее чем. 

То есть иметь стабильную систему, а внутри нее в песочнице пробовать
нововведения не получается.


-- 
   Victor Wagner