Леннарт Поттеринг (Lennart Poettering) сообщил (https://plus.google.com/115547683951727699051/posts/g1E6AxVKtyc) о добавлении в код Journal, в рамках которого развивается подсистема systemd, призванная заменить собой службу syslog и другие сопутствующие сервисы журналирования событий, поддержки механизма цепочной верификации записей FSS (Forward Secure Sealing). Указанная техника позволяет гарантировать неизменность логов и не позволяет злоумышленникам в случае успешной атаки на систему подменить записи в логе (лог можно удалить целиком, но нельзя незаметно изменить или удалить отдельные записи).Суть FSS сводится к использованию методов криптографии по открытым ключам в сочетании с формированием по цепочке проверочных хэшей для всех записей лога. Для начальной записи лога будет генерироваться пара из закрытого и открытого ключей, после формирования первой цифровой подписи закрытый ключ будет удалён, а для всех последующих записей в журнале будут генерироваться хэши, по цепочке охватывающие хэши предыдущих записей. Используя первичный проверочный ключ, который предлагается сохранить после создания лога на внешнем носителе, можно проверить неизменность всего лога.
Обычно для защиты логов от подмены записей в результате взлома используют средства журналирования на внешние syslog-серверы, но такой способ требует привлечения дополнительных ресурсов и усложнения конфигурации. FSS позволяет гарантировать целостность локально сохранённых логов, но требует периодического сохранения сгенерированных проверочных ключей на внешние системы или носители, после каждой ротации лога. Иначе, злоумышленник может перестроить лог и подменить проверочный ключ. Для упрощения операции сохранения проверочных ключей их предлагается выводить на терминал при входе в систему, дав возможность администратору легко сфотографировать новый ключ телефоном. Поддержку FSS планируется включить в состав дистрибутива Fedora 18.
URL: https://plus.google.com/115547683951727699051/posts/g1E6AxVKtyc
Новость: https://www.opennet.ru/opennews/art.shtml?num=34630
Ну и кто теперь скажет, что сисВ-иниты лучше?
sysVinit лучше хотя бы тем, что не занимается тем, чем не должен заниматься. Например логами и управлением пользовательской сессией.
sysVinit хуже хотя бы тем, что не занимался тем, чем должен был заниматься.
Именно поэтому его сейчас выметают поганой метлой из всех вменяемых дистрибутивов.
> sysVinit хуже хотя бы тем, что не занимался тем, чем должен был
> заниматься.
> Именно поэтому его сейчас выметают поганой метлой из всех вменяемых дистрибутивов.Чем же, просвятите?
Видимо не отсылал сообщения о загрузке в твиттер.
lol =D
Анонсирован новый системный сервис lold, созданный для того чтобы разгрузить администратора от выполнения рутиных операций по добавлению смайликов в сообщения на форумы. Сервис будет вести внутренний реестр сайтов, посещаемых администратором, с последующей тренировкой нейронной сети для выявления характерных паттернов поведения, для последующего их воспроизведения. Уже подсчитано, что внедрение сервиса в основные дистрибутивы позволит сэкономить до 2-х часов ежедневно.
ты только что подарил кому-то идею крутого стартапа.
> ты только что подарил кому-то идею крутого стартапа.Да не жалко. Пусть приходит, я ему ещё мешок идей высыплю.
> Да не жалко. Пусть приходит, я ему ещё мешок идей высыплю.«сума, сума, дай мне ума!» (ц)
>> Да не жалко. Пусть приходит, я ему ещё мешок идей высыплю.
> «сума, сума, дай мне ума!» (ц)Идеи - от лукавого, а лень - русская ))) И кто кого перетерпит?
> Анонсирован новый системный сервис lold, созданный для того чтобы разгрузить администратора от выполнения рутиных операций по добавлению смайликов в сообщения на форумы...Для управления реестром используемых смаликов, включая контроль над правильностью и правомерностью применения тех или иных форм, будет использоваться специально разработанный пакет SmileKit.
Если ты единоличный хозяин - журналируй (пусть даже бардак) , а не сваливай ответственость на "хитрых" потомков.
> Чем же, просвятите?А за просвЯщением - обращайтесь к священникам.
А за просвЕщением - к электрикам. Учите родной язык, мать вашу.
Любите родину, мать вашу.
> Учите родной язык, мать вашу.Да, там еще рассказывают про проверочные слова. И святость не имеет прямого отношения к приобретению знаний. А вот то что "ученье - свет" как бы давно известно.
> Именно поэтому его сейчас выметают поганой метлой из всех вменяемых дистрибутивов.Переход на systemd - первый и единственный критерий вменяемости?
Стоило бы посомневаться во "вменяемости" собственных оценок, а то у вас даже RHEL во "вменяемые" не попал :D
> Переход на systemd - первый и единственный критерий вменяемости?Ну почему. Переход арча на systemd, например, был вполне предсказуем, исходя из вменяемости арча.
Как сейчас предсказуем аналогичный переход для генты.> Стоило бы посомневаться во "вменяемости" собственных оценок, а то у вас даже
> RHEL во "вменяемые" не попал :DRHEL6 появился раньше systemd, и его там быть не могло. А RHEL7 уже будет на systemd.
Не знаю как насчёт арча (я бы его вменяемым не назвал, но это вкусовщина, конечно), но в генте, насколько мне известно, планов по переходу на systemd нет.
В USE флагах:
systemd Install SystemD init script instead of OpenRC
"Переход" - это когда он в stage3 будет по умолчанию. А то о чём Вы - лишь возможность его завести вместо штатного OpenRC.
Гента тем и хороша,что руки не выкручивает. Хочешь - ставь, возможность дадут и для бОльших извратов. Но вот планов по миграции нет.
> Гента тем и хороша,что руки не выкручивает. Хочешь - ставь, возможность дадут и для бОльших извратов.С OpenRC таки выкрутили.
> Но вот планов по миграции нет.
Есть.
> Гента тем и хороша,что руки не выкручивает. Хочешь - ставь, возможность дадут
> и для бОльших извратов. Но вот планов по миграции нет.$ which ifconfig
/bin/ifconfig$ which ip
/bin/ip$ which netstat
/bin/netstatи еще примеров налить могу. причем, аргументация для таких перемещений весьма сомнительна. systemd, как USE-флаг имеет место, только используется далеко не во всех пакетах, в следствие чего в системе появляется куча systemd-related хлама, который явно для openrc нужен аж никак. добавим сюда напрочь поломаный /usr на отдельном разделе из коробки, продиктованый отсутствием желания поддерживать патчсэт, собирающий standalone udev в человеческом виде и медленное сползание в yet another fedora, только source-based, это ли не выкручивание рук? ну что тут скажешь, гентушники уже не те к моему великому сожалению. деб еще держится, да слака. остальные упорно упорно оборачивают в пакеты чужие костыли, не желая заниматься разработкой своих инструментов. тоже мне mainstream нашли в виде шапки.. такое ощущение, что разработкой софта под Linux занимаются полные виндузятники, тянущие за собой свои костыли, дабы избавить нас от неоспоримых преимуществ Unix(-like) систем. зачем modprobe -l? используйте find, это логичней и нормальней! зачем вам pam? впихните в систему consolekit с dbus! и ведь только для того, чтобы давно ставший монстроуозным udev смог вам нарисовать acl. вам не нужен /sbin, separated /usr и /var/run и отсутствие костыля в виде initrd/initramfs, вам нужен /run и /var/lib/run (странно, как еще /tmp сохранился). ну а конкретно в контексте самой новости, запасаемся попкорном и наблюдаем парсинг и мониторинг многотонных логов.
> $ which ifconfig
> /bin/ifconfig
> $ which ip
> /bin/ip
> $ which netstat
> /bin/netstatВы наверное Gentoo с федоркой попутали:
# which ifconfig
/sbin/ifconfig
# which ip
/sbin/ip
# which netstat
/sbin/netstat
# uname -r
2.6.32-hardened-r110
>[оверквотинг удален]
>> /bin/netstat
> Вы наверное Gentoo с федоркой попутали:
> # which ifconfig
> /sbin/ifconfig
> # which ip
> /sbin/ip
> # which netstat
> /sbin/netstat
> # uname -r
> 2.6.32-hardened-r110увы, не перепутал, а очень хотелось бы, чтобы все это оказалось страшным сном и исчезло после пробуждения.
$ qlist -I -v net-tools
sys-apps/net-tools-1.60_p20120127084908$ qlist -I -v iproute2
sys-apps/iproute2-3.5.1http://sourceforge.net/mailarchive/message.php?msg_id=28485418
https://bugs.gentoo.org/show_bug.cgi?id=330115
quse -D systemd
local:systemd:app-emulation/qemu-guest-agent: Install SystemD init script instead of OpenRCага
> В USE флагах:
> systemd Install SystemD init script instead of OpenRCНу-ну. Это как "systemd включен в Debian". Ага, а еще 100500 других "альтернатив" sysvinit точно также.
> в генте, насколько мне известно, планов по переходу на systemd нет.А насколько _мне_ известно - есть. Мейнтейнеры OpenRC остались в меньшинстве, большинство ведущих разработчиков выступает за переход.
>> в генте, насколько мне известно, планов по переходу на systemd нет.
> А насколько _мне_ известно - есть. Мейнтейнеры OpenRC остались в меньшинстве, большинство
> ведущих разработчиков выступает за переход.Пруф будет? Или опять лужи загазовываете?
О_о ссылки на обсуждение в рассылке, неужели зря отписался?
>> Переход на systemd - первый и единственный критерий вменяемости?
> Ну почему. Переход арча на systemd, например, был вполне предсказуем, исходя из
> вменяемости арча.Или невменяемости (если оную считать критерием перехода на). Заметьте, переход "предсказуем" в любом случае.
> RHEL6 появился раньше systemd
Ну да, из машины времени :D
> А RHEL7 уже будет на systemd.
Ну вот когда *будет* и когда у оного *будут* пользователи... А пока, увы.
> Или невменяемости (если оную считать критерием перехода на). Заметьте, переход "предсказуем" в любом случае.Невменяемость дистрибутива GNU/Linux можно определить по желанию сломать поддержку компонентов GNU/Linux (например, systemd, который фактически является внешней зависимостью Linux kernel).
> Ну да, из машины времени :D
Не знаете, как что было - не выеживайтесь.
> Ну вот когда *будет* и когда у оного *будут* пользователи...
И то, и другое - вполне предсказуемо. Если, разумеется, конец света не наступит раньше следующей весны.
>компонентов GNU/Linux (например, systemd, который фактически является внешней зависимостью Linux kernel).Не в этой реальности пока (не говорите разработчикам в лицо - запинают). Рассказать в каком файлике написано о "внешних зависимостях"?
>> Ну да, из машины времени :D
> Не знаете, как что было - не выеживайтесь.Я просто обратил внимание на даты релизов. Вас носом ткнуть, что далеко не один релиз systemd вышел *до* RHEL6?
Насколько это чудо было готово к включению в RHEL6 - это, конечно, уже другой вопрос. Тот же вопрос справедлив и сейчас, кстати.
>> Ну вот когда *будет* и когда у оного *будут* пользователи...
> И то, и другое - вполне предсказуемо.И то, и другое - еще бабушка надвое сказала. Если вы думаете, что все релизы редхат были одинаково удачны и популярны - подумайте еще. Это серверное ПО, срок поддержки - не маленький, и нужды мигрировать на ваши грабли - нету.
> Я просто обратил внимание на даты релизов.Здесь Вы немного не правы. RHEL6 основан на 12/13 федоре. http://fedoraproject.org/wiki/RHEL#History , systemd появился только в 15.
> И то, и другое - еще бабушка надвое сказала.
В RHEL6 systemd не включат. В роадмапе RHEL7 он есть http://rhsummit.files.wordpress.com/2012/03/burke_rhel_roadm...
>> Я просто обратил внимание на даты релизов.
> Здесь Вы немного не правы. RHEL6 основан на 12/13 федоре.Так 12 или 13? Таки все-равно - раньше 13 федоры. Даже раньше ее заморозки.
> systemd появился только в 15.
systemd "появился" задолго до его включения в 15 федору.
> В RHEL6 systemd не включат.
Никто подобного "счастья" и не ждет.
> В роадмапе RHEL7 он есть
Да, на это мне и указали. Вот только включат или нет - непонятно.
>>> Я просто обратил внимание на даты релизов.
>> Здесь Вы немного не правы. RHEL6 основан на 12/13 федоре.
> Так 12 или 13?Я дал ссылку. Mix of Fedora 12 Fedora 13 and several modifications
> Таки все-равно - раньше 13 федоры.
> Даже раньше ее заморозки.Не понял. Заморозки чего?
>> systemd появился только в 15.
> systemd "появился" задолго до его включения в 15 федору.Естественно, софт пишется до включения его в дистрибутив.
>> В RHEL6 systemd не включат.
> Никто подобного "счастья" и не ждет.РедХат (так же как дебиан и т.д.) не меняют софт в уже выпущенном дистрибутиве.
>> В роадмапе RHEL7 он есть
> Да, на это мне и указали. Вот только включат или нет
> - непонятно.У Вас есть _факты_ когда РедХат не соблюдал свой роадмап?
>> Таки все-равно - раньше 13 федоры.
>> Даже раньше ее заморозки.
> Не понял. Заморозки чего?Федоры 13, кэп.
>>> systemd появился только в 15.
>> systemd "появился" задолго до его включения в 15 федору.
> Естественно, софт пишется до включения его в дистрибутив.Ну вот. Я и показал предыдущему оратору, что "написан" софт был задолго релиза RHEL6 (и даже федоры 13).
>>> В RHEL6 systemd не включат.
>> Никто подобного "счастья" и не ждет.
> РедХат (так же как дебиан и т.д.) не меняют софт в уже
> выпущенном дистрибутиве.Спасибо, конечно, что просветили - но почему вы так уверены что я был не вкурсе? systemd пока не включен ни в один серьезный дистрибутив (RHEL, его клоны или Debian).
>>> В роадмапе RHEL7 он есть
>> Да, на это мне и указали. Вот только включат или нет
>> - непонятно.
> У Вас есть _факты_ когда РедХат не соблюдал свой роадмап?Просто посмотрите на том же opennet кучу новостей "мы снова перенесли релиз федоры". Вам мало, или будете делать вид что оная к RH никакого отношения не имеет?
> Федоры 13, кэп.И какое отношение 13 федора имеет к systemd (который включили только в 15)?
>>>> systemd появился только в 15.
>>> systemd "появился" задолго до его включения в 15 федору.
>> Естественно, софт пишется до включения его в дистрибутив.
> Ну вот. Я и показал предыдущему оратору, что "написан" софт
> был задолго релиза RHEL6 (и даже федоры 13).Непонятно, почему Вы считаете, что только что написанный софт должен быть включен в дистрибутив. Федора иногда так делает, но есть разница между включением сырого ДЕ (KDE4, GNOME3), которому всегда есть альтернатива и системой инициализации, от которой зависит все.
>>>> В RHEL6 systemd не включат.
>>> Никто подобного "счастья" и не ждет.
>> РедХат (так же как дебиан и т.д.) не меняют софт в уже
>> выпущенном дистрибутиве.
> Спасибо, конечно, что просветили - но почему вы так уверены что я
> был не вкурсе? systemd пока не включен ни в один
> серьезный дистрибутив (RHEL, его клоны или Debian).Т.е. Вы считаете федору, Mageia, мандриву, openSUSE и т.д. несерьезными дистрами?
>>>> В роадмапе RHEL7 он есть
>>> Да, на это мне и указали. Вот только включат или нет
>>> - непонятно.
>> У Вас есть _факты_ когда РедХат не соблюдал свой роадмап?
> Просто посмотрите на том же opennet кучу новостей "мы снова перенесли релиз
> федоры". Вам мало, или будете делать вид что оная к
> RH никакого отношения не имеет?Федора к РедХату имеет такое же отношение как openSUSE к SLED и т.д. Т.е. одно дело тестовый дистр и совсем другое энтерпрайз, за который они получают деньги.
На счет перенесения сроков: это вполне нормально, для Дебиана это обычная практика.
>> Федоры 13, кэп.
> И какое отношение 13 федора имеет к systemd (который включили только в 15)?Ну подумайте немного. Может помочь вдумчивое прочтение сообщений, на которые вы "отвечаете".
> Непонятно, почему Вы считаете, что только что написанный софт должен быть включен в дистрибутив.
А почему бы и нет? Если он хорошо спроектирован и написан. А важный компонент системы должен быть таковым.
И для справки: я не считаю что кто-то кому-то чего-то должен. Речь шла совсем о другом.
> Т.е. Вы считаете федору, Mageia, мандриву, openSUSE и т.д. несерьезными дистрами?
Грубо говоря, да. Федора - откровенно для альфа-тестеров. Да и доля их суммарно <10% в соответствующих областях, например на веб-серверах.
> Федора к РедХату имеет такое же отношение как openSUSE к SLED и
> т.д. Т.е. одно дело тестовый дистр и совсем другое энтерпрайз, за
> который они получают деньги.Тестовый или нет - это результат работы одной и той же компании, зачастую буквально одних и тех же людей.
> На счет перенесения сроков: это вполне нормально, для Дебиана это обычная практика.
Ну там побольше чем "перенесение сроков". Ровно то, что вы просили: изменение планов включения того или иного софта в релиз и т.п. Никто не спорит, что это в принципе "нормально".
> А почему бы и нет? Если он хорошо спроектирован и написан. А важный компонент системы должен быть таковым.Не важно насколько хорошо спроектирована и написана система инициализации (если мы говорим о systemd). От нее зависит куча софта, в который необходимо внести изменения.
Тем более в случае федоры, где переходили с upstart на systemd, которые между собой не совместимы.
> Грубо говоря, да. Федора - откровенно для альфа-тестеров. Да и доля их суммарно <10% в соответствующих областях, например на веб-серверах.У Вас есть статистика? Напрашивается некоторое сравнение с долей линукса на десктопах. По чему бы и нет, если Вы ограничиваетесь веб-серверами, хотя я привел список "десктопных" дисторв?
> Тестовый или нет - это результат работы одной и той же компании, зачастую буквально одних и тех же людей.Цели релизов несколько разные ;) Отсюда и разные требования.
> Ну там побольше чем "перенесение сроков". Ровно то, что вы просили: изменение планов включения того или иного софта в релиз и т.п. Никто не спорит, что это в принципе "нормально".Что именно не включили в 13 федору? Если Вы о systemd, то его не включили в 14, отложив до 15. https://www.opennet.ru/opennews/art.shtml?num=28503 .
>> А почему бы и нет? Если он хорошо спроектирован и написан. А важный компонент системы должен быть таковым.
> Не важно насколько хорошо спроектирована и написана система инициализации (если мы говорим
> о systemd). От нее зависит куча софта, в который необходимо внести изменения.Если действительно "хорошо спроектирована" - не надо. Есть такое понятие - "обратная совместимость". Для системного софта - жизненно важное.
> У Вас есть статистика?
Конечно.
> По чему бы и нет, если Вы ограничиваетесь веб-серверами, хотя я
> привел список "десктопных" дисторв?Кому на серверах интересны "десктопные" "дисторы"?
>> Тестовый или нет - это результат работы одной и той же компании, зачастую буквально одних и тех же людей.
> Цели релизов несколько разные ;) Отсюда и разные требования.Цели разные, но люди и компания - одни и те же. Почему в релизах RH планы должны сбываться неприменно - мне не очевидно. А искать персонально для вас контрпримеры - лень.
> Что именно не включили в 13 федору?
Без понятия. Читайте новости, смотрите. Так, навскидку, я помню что переход на btrfs откладывался (пару раз?).
> Если действительно "хорошо спроектирована" - не надо. Есть такое понятие -
> "обратная совместимость". Для системного софта - жизненно важное.Совместимости между инит-скриптами разных дистров никогда не было. РедХат пытается это исправить. Естественно с некоторыми издержками.
> Кому на серверах интересны "десктопные" "дисторы"?
Честно говоря не понял, когда разговор зашел о серверах.
> Цели разные, но люди и компания - одни и те же.
> Почему в релизах RH планы должны сбываться неприменно - мне не
> очевидно. А искать персонально для вас контрпримеры - лень.О том, что будет включено в энтерпрайзные дистры РедХат (и не только он) сообщают заранее, чтобы сторонние разработчики могли адаптировать свой софт. Изменение этих планов вызывает некоторые проблемы. С федорой такой проблемы нет.
>> Что именно не включили в 13 федору?
> Без понятия. Читайте новости, смотрите.Т.е. Вы в течении нескольких постов упоминали 13 федору и не знаете, что в ней изменилось? Забавно. И Вам не кажется, что:
> Ну там побольше чем "перенесение сроков". Ровно то, что вы просили: изменение планов включения того или иного софта в релиз и т.п. Никто не спорит, что это в принципе "нормально".несколько этому противоречит?
> Так, навскидку, я помню что
> переход на btrfs откладывался (пару раз?).И причем тут btrfs?
> Совместимости между инит-скриптами разных дистров никогда не было. РедХат пытается это
> исправить. Естественно с некоторыми издержками.Да б-г с ним, с world domination - исправили бы хоть в своей деревне.
>> Кому на серверах интересны "десктопные" "дисторы"?
> Честно говоря не понял, когда разговор зашел о серверах.Тогда, когда разговор зашел о каком-то серьезном применении linux.
> О том, что будет включено в энтерпрайзные дистры РедХат (и не только
> он) сообщают заранее, чтобы сторонние разработчики могли адаптировать свой софт.Что вы предлагаете "адаптировать" и каким образом? Даже без конкретных версий ПО.
Под пресс-релиз ничего "адаптировать" нельзя. Для адаптации существует техническая документация, альфа-бета релизы и т.п.
Но повторяю, никакой фантастики не будет, если включат. NIH во весь рост. Как собака на сене - вот и посмотрим к чему приведет это метание и как понравится клиентам.
> Т.е. Вы в течении нескольких постов упоминали 13 федору и не знаете,
> что в ней изменилось? Забавно.Что забавного? Вы просили привести примеры изменения планов в RH - я указал вам где искать. Почему вы прицепились к конкретному релизу, если я его не упоминал в данном контексте?
>> Так, навскидку, я помню что
>> переход на btrfs откладывался (пару раз?).
>
> И причем тут btrfs?Изменение планов. Вы просили - я привел пример. Комикс нарисовать, вы читать не умеете?
> Да б-г с ним, с world domination - исправили бы хоть в
> своей деревне.Согласен.
> Тогда, когда разговор зашел о каком-то серьезном применении linux.
Согласен.
> Но повторяю, никакой фантастики не будет, если включат. NIH во весь
> рост. Как собака на сене - вот и посмотрим к
> чему приведет это метание и как понравится клиентам.У нас разное мнение о перспективах (не)включения systemd в RHEL.
В принципе согласен. До беты рано утверждать что то определенное.> Что забавного? Вы просили привести примеры изменения планов в RH -
> я указал вам где искать. Почему вы прицепились к конкретному
> релизу, если я его не упоминал в данном контексте?Возможно, я Вас не так понял.
>>> Федоры 13, кэп.
>> И какое отношение 13 федора имеет к systemd (который включили только в 15)?
> Ну подумайте немного. Может помочь вдумчивое прочтение сообщений, на которые вы
> "отвечаете".
>> Непонятно, почему Вы считаете, что только что написанный софт должен быть включен в дистрибутив.
> А почему бы и нет? Если он хорошо спроектирован и написан.
> А важный компонент системы должен быть таковым.этот "вдумчиво" написанный важный компонент системы:
1) спроектирован хреново:
- не может быть одного лекарства от ВСЕГО! козырь nix систем - модульность => гибкая настройка под любые нужды. щас видим рождения зверя который, который жрет что хочет и срет, где хочет (ура - мы на пути к винде - идеалу десктопа)2) настолько важный, что (повторяюсь) срет, где хочет
3) я конечно понимаю Вашу позицию, что надо просто СРАТЬ, чтобы проект получил оценку "важный компонент системы" (ключевое слово ВАЖНЫЙ. е-мое, как мы до сих пор без этого жили - странно даже). он еще к тому же и "вдумчиво написан"!!
PS
regedit там еще не на подходе? судя по теме - скоро будет.
> 3) я конечно понимаю Вашу позицию, что надо просто СРАТЬВы абсолютно не поняли чужую позицию, так что прекратите делать "это самое".
Научитесь читать, вьюнош. А "каменты" писать будете потом.
для генты перехода не будет, но разрабы опенрц думают о совместимости с юнитами и о добавлении в опенрц фич системд, но скорость будет минимальна как минимум до стабилизации системд.
"Деньги портят Всех" Позволю Ц.
"А чем должен заниматься создатель"? Давать простор и следить за греховностью. Но Строго! Чтобы на суде, адвокат не ссылался на скомпрометированый лог ))))
> sysVinit лучше хотя бы тем, что не занимается тем, чем не должен
> заниматься. Например логами и управлением пользовательской сессией.Иксовой сессией, разумеется.
> sysVinit лучше хотя бы тем, что не занимается тем, чем не должен заниматься. Например логами и управлением пользовательской сессией.Все правильно. sysVinit не занимается потому что не должен, systemd занимается тем, что должен.
>Все правильно. sysVinit не занимается потому что не должен, systemd занимается тем, что >должен."Придет уничтожитель" (Ц) из охотников на приведений. А постеру - " и к Вам придут, но это будете не Вы..."
> sysVinit лучше хотя бы тем, что не занимается тем, чем не должен
> заниматься. Например логами и управлением пользовательской сессией.Вы подменяете понятия. Системный менеджер /usr/bin/systemd, являющийся заменой sysvinit, не занимается ни логами, ни сеансами. Для этого есть демон лога systemd-journald и менеджер сеансов systemd-logind.
>> sysVinit лучше хотя бы тем, что не занимается тем, чем не должен
>> заниматься. Например логами и управлением пользовательской сессией.
> Вы подменяете понятия. Системный менеджер /usr/bin/systemd, являющийся заменой sysvinit,
> не занимается ни логами, ни сеансами. Для этого есть демон лога
> systemd-journald и менеджер сеансов systemd-logind.Угумс, которые не могут использоваться отдельно от systemd. Весело. Мне, как человеку, никогда не трогавшем systemd, интересно, они все в одном процессе выполняются или нет?
s'/нет?/хотя бы нет?/'
> Мне, как человеку, никогда не трогавшем systemdТогда почему вы так любите рассуждать об архитектуре systemd, если ничего о ней не знаете?,
> интересно, они все в одном процессе выполняются или нет?
Нет.
> они все в одном процессе выполняются или нет?systemd-logind, systemd-journald, systemd-udevd - обычные службы, которые запускаются и управляются точно так же, как и остальные сервисы.
>Для этого есть демон лога systemd-journald и менеджер сеансов systemd-logind.Ага, прибитый гвозядми к systemd.
> Ага, прибитый гвозядми к systemd.Какая разница, все равно вменяемых аналогов нет =)
А когда нечем заменить - нет смысла делать компонент заменяемым.Опять же, логи и управление сеансами нужны на любой системе.
А когда незачем отключать - нет смысла делать компонент отключаемым.
Стоп-стоп, ты путаешь причину со следствием. Разве тот же логгинг нельзя выкинуть к чертям? Это он зависит от systemd, а не systemd от него.
> Стоп-стоп, ты путаешь причину со следствием. Разве тот же логгинг нельзя выкинуть
> к чертям?Ну попробуйте выкинуть вызов syslog() из libc.
> Ну попробуйте выкинуть вызов syslog() из libc.Я не говорю выкинуть вызов сислога. На место логгера, исполняющего этот вызов, вполне ведь можно влепить заглушку, которая будет делать одно большое нихрена. Я не проверял, но теоретически такая заглушка должна автоматически активироваться если нет демона, отвечающего за логгирование… или просто все запросы будут уходить в /dev/null, что аналогично.
> Я не говорю выкинуть вызов сислога. На место логгера, исполняющего этот вызов,
> вполне ведь можно влепить заглушку, которая будет делать одно большое нихрена.Ну патчьте libc, если вам так нравится.
А на системах с journal можно просто поставить нулевой лимит хранения логов, после чего сам journald превращается в такую заглушку.
> Ну патчьте libc, если вам так нравится.Зачем? Попробуйте на тестовой системе остановить или вообще не запускать syslog, может вас удивит, но ничего страшного не произойдет.
>> Ну патчьте libc, если вам так нравится.
> Зачем? Попробуйте на тестовой системе остановить или вообще не запускать syslog, может
> вас удивит, но ничего страшного не произойдет.а тем временем логи таки будут писаться, но не все да.
Интересно чем они будут писаться? Системд головного мозга? Всё в куче и в бинарном виде, что без декодировщика не разобрался даже владелец?
> Системд головного мозга? Всё в куче и в бинарном виде, что без декодировщика не разобрался даже владелец?Filesystem головного мозга. Именно так организована почти любая файловая система.
> Filesystem головного мозга.Интересно, что за фаловая система у вас в мозгу? :)
Речь идёт о том, что в принципе ни что не мешает journald выкинуть вовсе. Systemd от этого не пострадает и будет работать, и патчить libc для этого совершенно не нужно. Просто логи строчить будет некому. То не моя идиотская идея о патчинге libc была и не нужно мне её приписывать.
Если вернуться на несколько комментариев выше, то можно увидеть довольно странное предположение о том, что systemd как-то зависит от journald и без него жить не может, с которым я и не согласился. А это только journald себя без systemd дурно чувствует, а не наоборот.
Кстати - а чем именно (и зачем) он завязан на systemd? Кто-то знает, там осмысленные мотивы есть?
На сколько я понял он умеет общаться только с systemd. Теоретически ни что не мешает научить его общаться с чем-то ещё или научить это что-то ещё (upstart, например?) общаться с ним.
То есть банально не захотели совместимость снизу вверх реализовать? Забавно. Впору патч писать...
> То есть банально не захотели совместимость снизу вверх реализовать? Забавно. Впору патч
> писать...на самом деле просто основная фича этого журнала более ранний запуск чем возможно для сислога.. и возможно это только потому что системд позволяет запустить журнал раньше. потому для остальных систем инициализации большой пользы от журнала нет.( особенно если там пивыкли к сислогу) ЗЫ вот когда все анонсированные фичи журнала запилят будет интересно посмотреть на желающих журнал без одной из фич.
> То есть банально не захотели совместимость снизу вверх реализовать? Забавно.А смысл реализовывать совместимость с тем, чего нет? upstart и openrc не умеют сокет-активацию.
С тем же успехом можно попытаться портировать chmod на MS-DOS и обидеться на разработчиков chmod, что они не захотели обеспечить совместимость.
> Впору патч писать...
Ага, для upstart. Только его не примут - разработка уже прекращена, принимаются только багфиксы.
> Systemd от этого не пострадаетсистемд потеряет вывод 10 последних сообщений в лог при вызове systemctl servicename.service (или как там правильней?)
> только journald себя без systemd дурно чувствует, а не наоборот.журналд написан чтобы по запросу системктл сервиснейм.сервис нам выдавало последне 10 сообщений сервиса в лог. если вам нужны фичи журнала вне системд вы можете это сделать, разработчикам системд это не нужно.
>> только journald себя без systemd дурно чувствует, а не наоборот.
> журналд написан чтобы по запросу системктл сервиснейм.сервис нам выдавало последне 10 сообщений
> сервиса в лог. если вам нужны фичи журнала вне системд вы
> можете это сделать, разработчикам системд это не нужно.А нам пока что не нужен системд.
И да. По моей практике наиболее часто нужно последние 20-40 строк лога, но никак не 10...
> А нам пока что не нужен системд.Это ваши проблемы.
> И да. По моей практике наиболее часто нужно последние 20-40 строк лога,
> но никак не 10...Есть такая штука - параметры программы. Например systemctl -n40. Но чтобы узнать о них, нужно RTFM, а такие, как вы, никогда ничего не читают, только осуждают.
>> А нам пока что не нужен системд.
> Это ваши проблемы.я бы сказал иначе. вам нравится? используйте на здоровье. только нечего сей велосипед и сопутствующие костыли насильно впаривать всем.
я бы сказал иначе. не нравится? запили свой проект, форк, etc. а не ной, как девчёнка!
> я бы сказал иначе. не нравится? запили свой проект, форк, etc. а
> не ной, как девчёнка!раньше говорили, не нравится - не юзай. согласно вашей логике, теперь это должно звучать как не нравится - форкай. естесственно, зачем при слушиваться к мнениям? хотите - жрите кактус, но не трогайте альтернативы. хотите - берите да форкайте, форкайте кернел, форкайте юзерспейс, форкайте дистрибутивы и поддерживайте их в одиночку. класс! занимайтесь кодингом и отловом чужих граблей вместо работы, выполнения прямых обязанностей и досуга. больше форков и разных на всякий ленивый выпендреж. libav, в частности, тому прекрасный пример. а мне хватает работы мейнтейнером помимо основного рода занятий, да своих собственных проектов.
> я бы сказал иначе. вам нравится? используйте на здоровье. только нечего сей
> велосипед и сопутствующие костыли насильно впаривать всем.Так разработчики дистров насильно их не впихивают. Это их дистры и их решения. Не нравится политика партии - валите нафиг. Дистров то дохрена.
Есть более простой вариант - просто выгнать всё в текст и передать через пайп (пока ещё его не доломали) нужному скрипту. Зато это будет работать везде, а не только в линухе.
> Стоп-стоп, ты путаешь причину со следствием. Разве тот же логгинг нельзя выкинуть
> к чертям? Это он зависит от systemd, а не systemd от
> него.ога или просто не дать возможности писать в логфайл, тогда лог будет жить в памяти до первого ребута... отключать насовсем смысла ваще нет. хотя и это можно сделать.
Иксовые сеансы нужны отнюдь не любой системе.
> Иксовые сеансы нужны отнюдь не любой системе.systemd без разницы, иксовый сеанс или нет.
>Какая разница, все равно вменяемых аналогов нет =)Прибитых гвоздями к systemd конечно нет. А так хоть **** жуй.
>>Какая разница, все равно вменяемых аналогов нет =)
> Прибитых гвоздями к systemd конечно нет. А так хоть **** жуй.и кто из них стартует также рано как журнал?
>и кто из них стартует также рано как журнал?Ядро же.
>>и кто из них стартует также рано как журнал?
> Ядро же.технически принято, но может ктонибудь ещё?
> Прибитых гвоздями к systemd конечно нет. А так хоть **** жуй.Жопой жуй - какашек типа rsyslog или syslog-ng. А _вменяемых_ альтернатив - нет.
> Жопой жуй - какашек типа rsyslog или syslog-ng.Этими "какашками" пользуются сурьезные дяди, они умеют делать на порядки больше чем journald. И отказываться от использования их ради этой поделки для localhost - пока не намеряны.
> А _вменяемых_ альтернатив - нет.
Вменяемых альтернатив невменяемому ПО - нет, по определению.
>они умеют делать на порядки больше чем journaldОчень интересно. Умеют ли они, например, искать по устройству? Или грепаем до посинения, попутно думая, какие случаи регексп пропустит?
> Какая разница, все равно вменяемых аналогов нет =)Как же ж мы жили-то, ужасъ.
> А когда нечем заменить - нет смысла делать компонент заменяемым.
Неверная посылка и неверный вывод => double fault.
Заменяемые компоненты -- это именно то, на чём *nix жив до сих пор. Сильно рекомендую (только не останавливайтесь на заголовке, если уж будете читать):
http://lwn.net/Articles/411845/
http://lwn.net/Articles/412131/
http://lwn.net/Articles/414618/
http://lwn.net/Articles/416494/> Опять же, логи и управление сеансами нужны на любой системе.
Нет. Хотя бы потому, что не у каждой системы вообще консоль локальная в наличии и куда писать логи.
> А когда незачем отключать - нет смысла делать компонент отключаемым.
Вот у таких "архитехтуров" и получаются уродцы с родовыми травмами из, казалось бы, неплохого в теории материала...
> Как же ж мы жили-то, ужасъ.Прогресс - это движение от плохой жизни к хорошей.
В свое время жили в пещерах и охотились с дубиной - и ведь выжили.>> А когда нечем заменить - нет смысла делать компонент заменяемым.
> Неверная посылка и неверный вывод => double fault.И в чем же они неверны?
> Заменяемые компоненты -- это именно то, на чём *nix жив до сих пор.
А вот Инго Молнар, например, считает иначе - наличие множества альтернатив для юзерспейсных компонентов сдерживает развитие ядра и ОС в целом.
Вообще, разработчики Linux все больше склоняются к идее Core OS - набора базовых системных компонентов (включая systemd), для которого будет гарантироваться совместимость с ядром. А альтернативы пусть сами о совместимости заботятся и мозг разработчикам ядра не сношают.> Нет. Хотя бы потому, что не у каждой системы вообще консоль
> локальная в наличии и куда писать логи.Ага, и по ssh на них не зайти, и dmesg не пишется =)
>> А когда незачем отключать - нет смысла делать компонент отключаемым.
> Вот у таких "архитехтуров" и получаются уродцы с родовыми травмами из, казалось
> бы, неплохого в теории материала...Да, идея запускать службы через скрипты 30 лет назад казалась неплохой...
>> Как же ж мы жили-то, ужасъ.
> Прогресс - это движение от плохой жизни к хорошей.
> В свое время жили в пещерах и охотились с дубиной - и
> ведь выжили.
> А вот Инго Молнар, например, считает иначе - наличие множества альтернатив для
> юзерспейсных компонентов сдерживает развитие ядра и ОС в целом.
> Вообще, разработчики Linux все больше склоняются к идее Core OS - набора
> базовых системных компонентов (включая systemd), для которого будет гарантироваться совместимость
> с ядром. А альтернативы пусть сами о совместимости заботятся и мозг
> разработчикам ядра не сношают.вам в винду.
> Да, идея запускать службы через скрипты 30 лет назад казалась неплохой...
ага, а юниты прям сильно лучше
ну ты прям сравнил ебилд с install.sh
> ну ты прям сравнил ебилд с install.shя бы сравнил иначе: это больше похоже на втюхивание чугунной статуи чапаева, когда мне нужна золотая статуя русалки =)
>> ну ты прям сравнил ебилд с install.sh
> я бы сравнил иначе: это больше похоже на втюхивание чугунной статуи чапаева,
> когда мне нужна золотая статуя русалки =)шурх шурх вам таки дают и ту статую и ту статую сислог по прежнему работает.
>>> ну ты прям сравнил ебилд с install.sh
>> я бы сравнил иначе: это больше похоже на втюхивание чугунной статуи чапаева,
>> когда мне нужна золотая статуя русалки =)
> шурх шурх вам таки дают и ту статую и ту статую сислог
> по прежнему работает.все бы вам бы ровер с двигателем от горбатого запорожца, да микроскопом гвозди забивать... вот тогда и скажете какие кому статуи дают. и да, сислог _пока_что_работает_
>>> А когда нечем заменить - нет смысла делать компонент заменяемым.
>> Неверная посылка и неверный вывод => double fault.
> И в чем же они неверны?"Нечем заменить" и "нет смысла делать заменяемым" -- ошибки.
1) хоть тот же rsyslog, который поливаете почём зря, разобрали бы малость;
2) даже если допущения ради согласиться с посылкой, то отсутствие возможности замены понижает вероятность (повышает трудоёмкость) создания этой самой замены в дальнейшем.Это One Microsoft Way, а не unix way. А за некрософт веем -- вон туда, в редмонд.
>> Заменяемые компоненты -- это именно то, на чём *nix жив до сих пор.
> А вот Инго Молнар, например, считает иначе - наличие множества альтернатив для
> юзерспейсных компонентов сдерживает развитие ядра и ОС в целом.Есть разумный баланс, не кидаться же в крайности.
> Вообще, разработчики Linux все больше склоняются к идее Core OS
Насчёт "склоняются" -- AFAIK преувеличение, скорее "бродит на уровне идеи".
>> Нет. Хотя бы потому, что не у каждой системы вообще консоль
>> локальная в наличии и куда писать логи.
> Ага, и по ssh на них не зайтиВ том числе. И IP тоже может не быть.
> и dmesg не пишется =)
Вы бы хоть поинтересовались тем кольцевым ядерным буфером, куда он пишется, прежде чем логи обсуждать и сислогды хаять, а?.. :(
И на ядерный модуль emlog посмотрите, раз уж такое дело.
> Да, идея запускать службы через скрипты 30 лет назад казалась неплохой...
Она и сейчас на удивление неплоха.
>> Вообще, разработчики Linux все больше склоняются к идее Core OS
> Насчёт "склоняются" -- AFAIK преувеличение, скорее "бродит на уровне идеи".Причем многие от подобных идеи плюются и говорят нехорошие слова. И найти их "лехше" (тот же Линус). А вот положительное отношение к systemd - субъективно, у куда меньшего количества разработчиков (мне Инго приходит на ум, пожалуй - усе).
>> Да, идея запускать службы через скрипты 30 лет назад казалась неплохой...
> Она и сейчас на удивление неплоха.И через 30 лет будет неплоха. Скрипты - это unix. "Одноразовые" утилиты на C, которые имеют смысл только в конкретном месте одного toolchain'а - это балаган.
>>Для этого есть демон лога systemd-journald и менеджер сеансов systemd-logind.
> Ага, прибитый гвозядми к systemd.можете взять и отвязать, но почемуто во время анонса все сказали нафиг оно нам не надо, а лёньке писать поддержку вне системд тоже не интересно, если никому не надо то тогда зачем?
>>>Для этого есть демон лога systemd-journald и менеджер сеансов systemd-logind.
>> Ага, прибитый гвозядми к systemd.
> можете взять и отвязатьЕщё можно форкнуть, или заново переписать. Только сути претензий к systemd-logind это не меняет.
>>>>Для этого есть демон лога systemd-journald и менеджер сеансов systemd-logind.
>>> Ага, прибитый гвозядми к systemd.
>> можете взять и отвязать
> Ещё можно форкнуть, или заново переписать. Только сути претензий к systemd-logind это
> не меняет.пфф тогда может стоит изложить эти претензии, конкретно к логинд и конкретно про невозможность использовать его в ну например опенрц
> Ещё можно форкнуть, или заново переписать. Только сути претензий к systemd-logind это не меняет.Разумеется. Потому что ваши претензии к logind (и многим другим компонентам Linux) не связаны с объективными факторами, а являются следствием ваших эмоционально мотивированных предпочтений (ноофобия, "эффект гусенка").
> можете взять и отвязать, но почемуто во время анонса все сказали нафиг
> оно нам не надоэто потому, что нормальные люди смотрят на системд с недоумением. а админам локалхоста, конечно, не надо.
>> можете взять и отвязать, но почемуто во время анонса все сказали нафиг
>> оно нам не надо
> это потому, что нормальные люди смотрят на системд с недоумением. а админам
> локалхоста, конечно, не надо.более точная информация говорит что нормальные люди поделились на тех кто не слышал про системд тех кто начал его пилить ибо заинтересовался нужными ему фичами и тех кто ждёт резульитатов чтобы решить позже. у нормального человека недоумение возникает только когда он не может понять как с виду нормальный человек не понимает или почему он делает вид что не понимает.
>> можете взять и отвязать, но почемуто во время анонса все сказали нафиг
>> оно нам не надо
> это потому, что нормальные люди смотрят на системд с недоумением. а админам
> локалхоста, конечно, не надо.Админам не локал хоста оно собственно тоже не. Они логи смотрят слишком часто, что бы им нужен был дополнительный гемор и сложности с их просмотром.
> Админам не локал хоста оно собственно тоже не. Они логи смотрят слишком
> часто, что бы им нужен был дополнительный гемор и сложности с
> их просмотром.Вот поэтому все больше дистров и переходят на systemd.
Одна из причин - нежелание устраивать шаманские пляски с грепом по десятку файлов.
> Одна из причин - нежелание устраивать шаманские пляски с грепом по десятку файлов.eventlog ваш выбор. идите в винду. там и бинарные файлы, и отличный греп бинарный, и шараваре прог для "ещё более лучшего грепа" вагон.
> eventlog ваш выбор. идите в винду. там и бинарные файлы, и отличный
> греп бинарный, и шараваре прог для "ещё более лучшего грепа" вагон.В UNIX бинарные логи использовались еще когда винды на свете не было.
Даже во FreeBSD они появились раньше, чем в Linux.
И чЁ? Плюсов вообще никаких не видно. А вот проблем вагон. Железки такие как циска как не отдавала в мегабинарном формате, так и не будет отдавать. Сислог там. Мне вот интересно а что проги уже все переписали на быстрый бинарный вывод логов и т.д.? Или они будут текст выплёвывать а франкинштейн от поттеринга будет переводить в бинарный вид. А захочешь посмотреть что там надо будет обратно в текст выгонять. Никакой лишней работы, ага.
ну почитал бы хоть..журнал добавляет метаинфу сообщения остаются текстовыми( впрочем разрабатываются рекомендации для создания культуры ведения логов) всё это сжимается и структурируется.
Ну сейчас расскажи раз они точь-в-точь такие же текстовые (кстати плоттеринг уже утвердил стандарт логов и менять не будет?) почему в сислог всё это не плюнуть.
> Ну сейчас расскажи раз они точь-в-точь такие же текстовые (кстати плоттеринг уже
> утвердил стандарт логов и менять не будет?) почему в сислог всё
> это не плюнуть.окститесь журнал ещё даже не рекомендовано использовать как обычный лог. там полторы заявленные фичи прикручены пока что.. такчто живите на сислоге( хотя мне больше нравится металог) ещё года два и не думайте про журнал.
>>> можете взять и отвязать, но почемуто во время анонса все сказали нафиг
>>> оно нам не надо
>> это потому, что нормальные люди смотрят на системд с недоумением. а админам
>> локалхоста, конечно, не надо.
> Админам не локал хоста оно собственно тоже не. Они логи смотрят слишком
> часто, что бы им нужен был дополнительный гемор и сложности с
> их просмотром.у тех у кого уже есть наработанные годами шишки для удобного анализа логов рекомендованы к прохождению курсов реабилитации.
ЗЫ но неужели вас так плохо учили что вы не устойчивы к смене окружений?
> у тех у кого уже есть наработанные годами шишки для удобного анализа
> логов рекомендованы к прохождению курсов реабилитации.А теперь расскажите это пользователям (да и разработчикам) splunk. :]
>> у тех у кого уже есть наработанные годами шишки для удобного анализа
>> логов рекомендованы к прохождению курсов реабилитации.
> А теперь расскажите это пользователям (да и разработчикам) splunk. :]я тут глянул в вики, кажется этих ребят можно назначить на ответственные должности в реабилитационных центрах.
Если у админа или пользователя возникает потребность к смене окружения каждые полгода, то самое время посетить психиатра.
так системд этим не занимается этим занимается журнал.
Я.Кстати, они там для криптографии не openssl используют часом?
> Кстати, они там для криптографии не openssl используют часом?Нет, libgcrypt.
> Кстати, они там для криптографии не openssl используют часом?У тебя этот вопрос возник из-за того, что ты часто встречал слова «OpenSSL» и «криптография» рядом? Поинтересуйся уже что такое SSL, например.
Нет. Из за того что часто встречаю слова "openssl" и "уязвимость" рядом.
Ну ок, пусть «уязвимость», а не «криптография».
А теперь может таки пойдёшь и прочтёшь что такое SSL?
Может хоть тогда поймёшь какую глупость сморозил…
А то понимаешь, он звучал примерно как «А они масло на хлеб случайно не трубопроводом намазывают?»
А может ты перестанешь выпендриваться и сам почитаешь man crypto?
> А может ты перестанешь выпендриваться и сам почитаешь man crypto?Ну так и спрашивал бы libgcrypt, libgcrypto или что-то ещё. А то OpenSSL это ведь реализация протоколов SSL и TLS. Хотя ок, я слишком придирчивый. В конце-концов криптографическая либа там главная часть.
Ты не слишком придирчивый, ты просто не разбираешься в вопросе и решил блеснуть своим "интеллектом", а в результате сам сел в лужу.
http://tldp.org/LDP/LG/issue87/vinayak.html
Учитывая, что OpenSSL таки содержит вагон реализаций криптографических клгоритмов и любовь Поттеринга к комбайнам - могли засунуть OpenSSL запросто, да ещё и использовать по прямому назначению, тыкаясь куда-нибдуь в сеть
>> А может ты перестанешь выпендриваться и сам почитаешь man crypto?
> Ну так и спрашивал бы libgcrypt, libgcrypto или что-то ещё. А то
> OpenSSL это ведь реализация протоколов SSL и TLS. Хотя ок, я
> слишком придирчивый. В конце-концов криптографическая либа там главная часть.Вообще openssl это криптографический комбайн могущий и ассиметричную, и симметричную криптографии. И дайджесты и ещё кучу всякого. И применение этого для SSL-TLS, это частный случай, мной, к примеру, используемый куда реже, чем расчёт дайджестов или генерация ключей предназначенных вовсе не для TLS.
> Вообще openssl это криптографический комбайн могущий и ассиметричную, и симметричную криптографии.А не объявить ли заодно джихад и опенсслю? Ведь ненужный комбайн же, не юниксвейно.
#include <openssl/hmac.h>
- не?
А Вам, уважаемый, не помешало бы поинтересоваться возможностями этой библиотеки.
$ openssl -
openssl:Error: '-' is an invalid command.<…>
Message Digest commands (see the `dgst' command for more details)
md4 md5 mdc2 rmd160
sha sha1Cipher commands (see the `enc' command for more details)
aes-128-cbc aes-128-ecb aes-192-cbc aes-192-ecb
aes-256-cbc aes-256-ecb base64 bf
bf-cbc bf-cfb bf-ecb bf-ofb
camellia-128-cbc camellia-128-ecb camellia-192-cbc camellia-192-ecb
camellia-256-cbc camellia-256-ecb cast cast-cbc
cast5-cbc cast5-cfb cast5-ecb cast5-ofb
des des-cbc des-cfb des-ecb
des-ede des-ede-cbc des-ede-cfb des-ede-ofb
des-ede3 des-ede3-cbc des-ede3-cfb des-ede3-ofb
des-ofb des3 desx idea
idea-cbc idea-cfb idea-ecb idea-ofb
rc2 rc2-40-cbc rc2-64-cbc rc2-cbc
rc2-cfb rc2-ecb rc2-ofb rc4
rc4-40 rc5 rc5-cbc rc5-cfb
rc5-ecb rc5-ofb seed seed-cbc
seed-cfb seed-ecb seed-ofb zlib
$man openssl
…
OpenSSL is a cryptography toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) network protocols and related cryptography standards required by them.The openssl program is a command line tool for using the various cryptography functions of OpenSSL's crypto library from the shell.
…В ситуации когда можно слинковаться с либой ни кто в здравом уме не будет использовать шелл-тулзу для вызова всех этих функций, а либа именуется не openssl. А так я просто излишне придирчивый. Забей.
> В ситуации когда можно слинковаться с либой ни кто в здравом уме
> не будет использовать шелл-тулзу для вызова всех этих функций, а либа
> именуется не openssl.Фейспалм. man crypto ->
crypto - OpenSSL cryptographic library
> Фейспалмвот именно.
> Ну и кто теперь скажет, что сисВ-иниты лучше?Демагоги из лагерей Шindoшs и freebsd, у которых каждый шаг развитии линукса вызывает потоки зависти и ненависти.
Ага-ага, шаг в пропасть – тоже путь к переменам?
К значительный.
*В значительным.
> *В значительным.третья попытка будет?
Нед.
>> *В значительным.
> третья попытка будет?зачем? это ведь правильный вариант.
> Ага-ага, шаг в пропасть – тоже путь к переменам?Да-да, всякое развитие - это тупиковый путь. Надо срочно свернуть все окололинуксовые разработки, иначе линукс рухнет в пропасть и наступит Страшный Суд, истинно говорю вам.
Он уже наступил несколько лет назад. Сейчас катится по наклонной. Все софтины начали превращаться в комбайны всё-в-одном. Нафига ещё одна винда?
> Он уже наступил несколько лет назад. Сейчас катится по наклонной. Все софтины
> начали превращаться в комбайны всё-в-одном. Нафига ещё одна винда?с выходом восьмёрки место завакантилось
> Ну и кто теперь скажет, что сисВ-иниты лучше?если по теме, то:
- кто скажет, что будет с logrotate, etc?
- кто скажет, что будет с веб-мордами по анализу логов?
- кто скажет, что влезя в жопу без мыла и заменив все, что в бошку по пьяному бреду втемяшется это чудовище не станет закрытым и платным?простой вопрос: regedit надобность или неизбежность? все в одном флаконе, удобно для пользователя итд... где-то я уже такое слышал.
> Ну и кто теперь скажет, что сисВ-иниты лучше?тут о SysV речь уже не идет ИМХО. Оно и так не во всех дистрибах было. Речь совсем о другом:
пытаются навязать стандарт, который одним дубом разработан (не -не разработан - его новые гениальные мысли вижу еще посещают до сих пор) и фактически закрыт.PS
все возвращается на круги своя. похоже скоро снова будет только win и fido.
> но требует периодического сохранения сгенерированных проверочных ключей на внешние системы или носители, после каждой ротации лога. Иначе, злоумышленник может перестроить лог и подменить проверочный ключ. Для упрощения операции сохранения проверочных ключей их предлагается выводить на терминал при входе в системуЧто за бред? Ключи генерируются и выводятся по команде journalctl --setup-keys, и это никак не привязано к ротации логов и входу в систему.
Вот бы подобное в каком-нибудь syslog-ng =) Ну или на крайний отдельным демоном..
Хотя да, syslog-ng remote рулит.
> Вот бы подобное в каком-нибудь syslog-ng =)При использовании текстовых логов, реализация такой фичи даст огромный оверхед по скорости и занимаемому месту.
>> Вот бы подобное в каком-нибудь syslog-ng =)
> При использовании текстовых логов, реализация такой фичи даст огромный оверхед по скорости
> и занимаемому месту.С этого места поподробнее.
> С этого места поподробнее.Попробуйте реализовать, поймете. Мы - пробовали.
А в чём проблема? Подписи держим отдельно, в любом нравящемся виде - хоть текст, хоть бинарь. Даже оффсеты не нужны - всё равно только с "головы" можно проверить. Хоть убей - не вижу никаких сложностей.
> А в чём проблема? Подписи держим отдельно, в любом нравящемся виде -
> хоть текст, хоть бинарь. Даже оффсеты не нужны - всё равно
> только с "головы" можно проверить. Хоть убей - не вижу никаких
> сложностей.1. Нужно, чтобы каждая новая строчка была подписана новым секретным ключём.
2. При этом новый ключ должен создаваться из старого.
3. При этом, старый ключ не должен восстанавливаться из нового ну совсем никак.
4. А после генерации нового ключа, старый должен навсегда вытираться из памяти компьютера.Аналогично и с открытыми ключами. Я так понимаю, в этом вся проблема.
> 1. Нужно, чтобы каждая новая строчка была подписана новым секретным ключём.Зачем новый секретный ключ? Хэш же.
> А в чём проблема? Подписи держим отдельно, в любом нравящемся виде -
> хоть текст, хоть бинарь. Даже оффсеты не нужны - всё равно
> только с "головы" можно проверить. Хоть убей - не вижу никаких
> сложностей.Какие подписи Вы держите отдельно? "Пришли с утра и расписались?"
>> А в чём проблема? Подписи держим отдельно, в любом нравящемся виде -
>> хоть текст, хоть бинарь. Даже оффсеты не нужны - всё равно
>> только с "головы" можно проверить. Хоть убей - не вижу никаких
>> сложностей.
> Какие подписи Вы держите отдельно? "Пришли с утра и расписались?"спрятать нужно только подпись сгенерированную первой. он же вам написал как цепочка подписей легко получаемых только в одну сторону позволяет не хранить все подписи а только первую и текущую, соответственно пока первая в безопасностии остальные можно вообще за логинд не выпускать.
>>> А в чём проблема? Подписи держим отдельно, в любом нравящемся виде -
>>> хоть текст, хоть бинарь. Даже оффсеты не нужны - всё равно
>>> только с "головы" можно проверить. Хоть убей - не вижу никаких
>>> сложностей.
>> Какие подписи Вы держите отдельно? "Пришли с утра и расписались?"
> спрятать нужно только подпись сгенерированную первой. он же вам написал как цепочка
> подписей легко получаемых только в одну сторону позволяет не хранить все
> подписи а только первую и текущую, соответственно пока первая в безопасностии
> остальные можно вообще за логинд не выпускать.Тю! Единственная точка отказа, не?
>> С этого места поподробнее.
> Мы - пробовали.Пруф или не было. А то вдруг руки не оттуда у вас растут.
man mkfifo
man bash
man gpg
man dd (опционально)
и попробуйте ещё раз
> man mkfifo
> man bash
> man gpg
> man dd (опционально)
> и попробуйте ещё раз"Я там уже был..."
а мы пробывали - получилось не плохо.
каждая строчка свой hash и xor с предудущим хэшем - файлик с хэшами отдельно.
получается очень даже не плохо.
> пробывалипосле этого смешно читать, что там «получилось». «пробывальщеги».
> а мы пробывали - получилось не плохо.
> каждая строчка свой hash и xor с предудущим хэшем - файлик с
> хэшами отдельно.
> получается очень даже не плохо.Только вот автор rsyslog в свое время объяснил, почему такую схему легко ломануть (он думал, что она будет использоваться в journal - явно недооценил конкурента).
и почему же?
А что сложного-то? Кроном забрасывать лог в алгоритм шифрования, результат в хеш, хеш - в тот же лог. Реализуется за минут 5 при знании всего, что нужно, и минут 30 с гуглением.
> А что сложного-то? Кроном забрасывать лог в алгоритм шифрования, результат в хеш,
> хеш - в тот же лог. Реализуется за минут 5 при
> знании всего, что нужно, и минут 30 с гуглением.Рисовали на бумаге, да забыли про овраги, а по ним ходить.
Попробуйте сделать, увидите, что не все так гладко, как вам кажется.
> Рисовали на бумаге, да забыли про овраги, а по ним ходить.
> Попробуйте сделать, увидите, что не все так гладко, как вам кажется.Ну так и нарисуйте нам овраги. Ан окажется - другие умнеее вас и подскажут как их обойти?
начинай подсказывать https://admin.fedoraproject.org/pkgdb/acls/bugs/systemd
> начинай подсказывать https://admin.fedoraproject.org/pkgdb/acls/bugs/systemdЧто, если Леннард клепает сотый бажный велосипед - и все так обязаны?
> начинай подсказывать https://admin.fedoraproject.org/pkgdb/acls/bugs/systemdну зачем так больно бить по самолюбию любителей портеринга.
Ну ничего федору и с этим набором багов резинут - RedHat нужны тестеры!
Я не очень понимаю, предлагается ежесуточно вручную фотографировать консоль сервера на телефон? И это, дескать, проще, чем автоматически отсылать лог на удалённую машину?
> Я не очень понимаю, предлагается ежесуточно вручную фотографировать консоль сервера на
> телефон? И это, дескать, проще, чем автоматически отсылать лог на удалённую
> машину?Нет, достаточно одного раза. Про привязку к ротации - это измышления новостеписателя.
> Нет, достаточно одного раза. Про привязку к ротации - это измышления новостеписателя.It works by generating a key pair of "sealing key" and "verification key". The former stays on the machine whose logs are to be protected and is automatically changed in regular intervals (and the previous one securely deleted), the latter should be written down on a piece of paper or stored on your phone or some other secure location (that means: not on the machine whose logs are to be protected). With the verification key at hand you can verify the journals on the machine and be sure that -- if the verification is successful -- log history until the point where the machine was cracked has not been altered a posteriori.
Читая Poetteringа мы видим, что поскольку sealing key и verification key идут парами, то непосредственно при стирании sealing key нужно сохранять соответствующий verification key. Иначе злоумышленник может точно также сварганить нужное кол-во пар sealing key и verification key, подделать логи и всё. То есть, у вас всегда должна быть последняя версия нескомпрометированного verification key.
То есть, таки надо фотографировать монитор сервера на телефон каждый день.
>...нужно сохранять соответствующий verification key...
>...
>То есть, таки надо фотографировать монитор сервера на телефон каждый день.Осталось понять почему каждый день, а не каждый год или не каждые 37.5 секунд. Не объясните?
> Осталось понять почему каждый день, а не каждый год или не каждые
> 37.5 секунд. Не объясните?Вообще, желательно после каждой записи в лог. И с такой же частотой создавать пары ключей. Но чаще, чем раньше раз в день, себя не заставишь. :-)
Вообще, verification key, который не откопирован в гарантированно безопасное хранилище, абсолютно бесполезен - его можно подменить в паре с sealing key.
В общем, я совершенно не понимаю, каким образом можно выдать злоумышленнику компьютер со всей необходимой информацией так, чтобы он не мог подделать лог. И при этом можно было за разумное время этот лог проверить (Возможна такая ситуация, что секретный ключ для каждой новой записи генерируется из предыдущего, при этом предыдущий забывается без возможности восстановления. Но тогда, казалось бы, проверка этого лога займёт вечность.).
>То есть, у вас всегда должна быть последняя версия нескомпрометированного verification key.
> То есть, таки надо фотографировать монитор сервера на телефон каждый день.а может просто не стоит компрометировать ключ каждый день? моя пара ключей для подписи уже 5 лет не скомпрометирована и врядли будет.
>>То есть, у вас всегда должна быть последняя версия нескомпрометированного verification key.
>> То есть, таки надо фотографировать монитор сервера на телефон каждый день.
> а может просто не стоит компрометировать ключ каждый день? моя пара ключей
> для подписи уже 5 лет не скомпрометирована и врядли будет.почитайте что такое "нагрузка на ключ".
> а может просто не стоит компрометировать ключ каждый день? моя пара ключей
> для подписи уже 5 лет не скомпрометирована и врядли будет.Я не совсем понимаю происходящее, т.к. статьи про методу нет (см. оригинальный пост Поттеринга). Но, очевидно, что после взлома у злоумышленника в руках появляется секретный ключ, которым подписываются логи.
>> а может просто не стоит компрометировать ключ каждый день? моя пара ключей
>> для подписи уже 5 лет не скомпрометирована и врядли будет.
> Я не совсем понимаю происходящее, т.к. статьи про методу нет (см. оригинальный
> пост Поттеринга). Но, очевидно, что после взлома у злоумышленника в руках
> появляется секретный ключ, которым подписываются логи.получить доступ к логам и к хранилищу ключей несколько очень разные уровни взлома.
> получить доступ к логам и к хранилищу ключей несколько очень разные уровни
> взлома.К логам на запись - т.е. это и в том, и в том случае root доступ.
вот тут не уверен, но мне пока такие потребности не грозят такчто реализацию безопасности я прорабатываю теоретически, могу чего-то не учитывать, но помоему всётаки разные у меня например при попытке ручного доступа к ключам нужно пароль вводить.. думается если понадобится автоматический доступ будет несложно разрешить туда доступ только мной лично подписанным сервисам.
> Читая Poetteringа мы видим, что поскольку sealing key и verification key идут
> парами, то непосредственно при стирании sealing key нужно сохранять соответствующий verification
> key. Иначе злоумышленник может точно также сварганить нужное кол-во пар sealing
> key и verification key, подделать логи и всё. То есть, у
> вас всегда должна быть последняя версия нескомпрометированного verification key.
> То есть, таки надо фотографировать монитор сервера на телефон каждый день.Вы довольно плохо читаете по-английски. Новый sealing key генерируется на основе предыдущего каждые 15 минут. При этом, для проверки всей цепочки sealing keys достаточно одного verification key, созданного одновременно с первым sealing.
Думаю, настолько эпичную глупость они не могли сотворить
> Думаю, настолько эпичную глупость они не могли сотворитьС одной стороны, да. С другой стороны, не понадобится ли хранить вообще все логи с момента генерации пары sealed key/verification key, чтобы проверить их нескомпрометированность? Это тоже, в некотором смысле, убивает идею.
Впрочем, поскольку основополагающая статья ещё не опубликована, узнать это невозможно.
>> Думаю, настолько эпичную глупость они не могли сотворить
> С одной стороны, да. С другой стороны, не понадобится ли хранить вообще
> все логи с момента генерации пары sealed key/verification key, чтобы проверить
> их нескомпрометированность? Это тоже, в некотором смысле, убивает идею.Для проверки нужны все логи после получения verification key. Хочешь удалить старые логи - новая пара sealed / verification key и поехали дальше.
> Для проверки нужны все логи после получения verification key. Хочешь удалить старые
> логи — новая пара sealed / verification key и поехали дальше.ой, как чудно. log rotation особенно чуден: забыл сфотографировать экран — капец.
> Я не очень понимаю, предлагается ежесуточно вручную фотографировать консоль сервера на
> телефон? И это, дескать, проще, чем автоматически отсылать лог на удалённую
> машину?шурх шурх, почему я не читая новсть таки понимаю что и как сделали? неужели потому что яитал ещё анонс фичи?
> шурх шурх, почему я не читая новсть таки понимаю что и как
> сделали?Это у вас иллюзия: "FSS is based on "Forward Secure Pseudo Random Generators" by Bertram Poettering at the Royal Holloway/University of London, who is a cryptography postdoc and researches these kind of things. (He also happens to be my brother...) A paper about FSPRG will be published shortly."
Последняя фраза "A paper about FSPRG will be published shortly." переводится как "Статья о FSPRG вскоре будет опубликована".
> неужели потому что яитал ещё анонс фичи?
Нет, это потому, что вы не читали оригинал.
> Нет, это потому, что вы не читали оригинал.так яж и говорю новость не читал что ту что ту читал только прошлый анонс тогдашние планы и нынешний заголовок.
ещё и портеринг от криптографии…
> ещё и портеринг от криптографии…Ну мне сама по себе идея засовывания теории, которая будет изложена в статье, которую опубликуют потом, в эксплуатируемый миллионами код, крайне не нравится. Если я не ошибаюсь, эта статья ещё рецензию-то не прошла.
ну так не зря ж они братья. семейное, видать.
> ну так не зря ж они братья. семейное, видать."Торопыжка был голодный,
Проглотил утюг холодный." :-)
С удовольствием воспользуюсь, но только лет через пять, когда технология будет обкатаны и все крупные баги выловлены.
Через 5 лет в /usr/bin ничего кроме systemd не останется, который тоже сдохнет под собственным весом.
Казалось бы, всего лишь нужно определить области ответственности системных процессов (запуск/инициализация, логгирование, управление сервисами), проработать качественные интерфейсы этих процессов, дать им хорошую, современную шину для взаимодействия и спокойно развивать по отдельности эти демоны. Классическая модульная архитектура. Но нет, полно ещё заряда в умельцах вхерачить все свои мечты в один бинарник.
> Через 5 лет в /usr/bin ничего кроме systemd не останется, который тоже
> сдохнет под собственным весом.
> Казалось бы, всего лишь нужно определить области ответственности системных процессов (запуск/инициализация,
> логгирование, управление сервисами), проработать качественные интерфейсы этих процессов,
> дать им хорошую, современную шину для взаимодействия и спокойно развивать по
> отдельности эти демоны. Классическая модульная архитектура. Но нет, полно ещё заряда
> в умельцах вхерачить все свои мечты в один бинарник.NIH-синдром заразен...
> Казалось бы, всего лишь нужно определить области ответственности системных процессов (запуск/инициализация,
> логгирование, управление сервисами), проработать качественные интерфейсы этих процессов,
> дать им хорошую, современную шину для взаимодействия и спокойно развивать по
> отдельности эти демоны. Классическая модульная архитектура.Именно так systemd и построен.
>Именно так systemd и построен.Хочу отдельный systemd-logind. Не подскажешь, как его отдельно запустить?
Запилить протокол, по которому они общаются с systemd, в upstart, например? Будет работать с upstart тогда.
> Запилить протокол, по которому они общаются с systemd, в upstart, например? Будет
> работать с upstart тогда.Вот все типы "протоколов" systemd:
/proc marking
C Drop-in
C Library
C Library or Drop-in
CLI
D-Bus
Environment
Environment, flag files
Environment, Mounts
File format
File hierarchy change
Socket+Files
Subprocess
System Mode
Treaty
udev PropertyBender, you're a mess...
> Хочу отдельный systemd-logind. Не подскажешь, как его отдельно запустить?Создать инит-систему, поддерживающую API logind. Или добавить это API в одну из существующих.
> Именно так systemd и построен.Тогда, наверное, эту систему логгирования можно будет соединить с upstart?
Модульность внутри бинарника - это хорошо с точки зрения поддержки и развития приложения. Но с точки зрения надсистемы (ОС, дистрибутив) это ничего не меняет. Один пухлый бинарник, который по частям нельзя использовать.Как пример - смотреть архитектуру Android с их Intent/Activity. Вот где модульность в идеальном виде.
> Казалось бы, всего лишь нужно определить области ответственности системных процессов (запуск/инициализация,
> логгирование, управление сервисами), проработать качественные интерфейсы этих процессов,
> дать им хорошую, современную шину для взаимодействия и спокойно развивать по
> отдельности эти демоны. Классическая модульная архитектура.Вы абсолютно точно описали архитектуру systemd. Мистер Поттеринг, это вы?
Хотите сказать, что любую ненужную часть можно выкинуть и остальное будет работать? И что можно влёгкую заменить любой компонент на самописный? И интерфейсы, конечно, документированы и гарантирована их неизменность?
мой любимый пример - есть сервис. Пользовательский. Ни к каким init, вообще говоря, отноешния не имеющий. Сейчас чтобы его гонять используется start-stop-daemon, который отлично разбирается с пидами и вообще удобен. Он, понятное дело, из дебиановского пакета инита. Есть в systemd что-то аналогичное?
Crazy, этот вопрос мучает не только Вас. Но ответа на него Вы, полагаю, не дождетесь.Апологеты системд за спорами о скорости и прозрачности загрузки напрочь забывают про такое понятие как "запас живучести" системного демона. А между тем, этот запас у любого демона под управлением системд изрядно уменьшается, просто потому, что системд (по определению!) уменьшает автономность любого демона, пытаясь контролировать его более плотно чем обычный скрипт-обвязка. В сущности, дела обстоят так, что любой фейл в либах системд легко может похоронить весь карточный домик системных процессов. На десктопе - это не страшно, но вот если сервер?
А что взамен предлагает системд? Про высокую скорость я уже... Безопасность от взлома? Ну так песочница системных вызовов весьма сомнительный довесок к безопасности, имхо. Что еще?
прозрачность процесса загрузки? Это вообще можно читать как "низкий порог вхождения в понимание процесса старта промышленной ОС". Что-то еще?Блин, и все же отлично понимают, что идеальный демон - это статический бинарник, ни на что не завязанный и запускаемый (лучше всего) скриптом. Все остальное - от лукавого.
Но именно этот вариант и не устраивает любителей быстрой загрузки. И я их даже где-то понимаю: на десктопе ждать пока каждый автономный модуль стртанет - совсем не торт. Вот поэтому они и будут трындеть о чем угодно, только не о запасе живучести оси и о тех вопросах, что Вы поднимаете.
автономность демонов не безопасна бай дезигнъи контроля от пользователя не получает.
впрочем посмотрим как системд будет с изоморфами поступать...
Есть. systemd неважно, что запускать.
http://www.freedesktop.org/wiki/Software/systemd/InterfacePo...
Хм, ну есть надежда, что жить можно будет, когда каждый компонент обрастёт ещё парой-тройкой реализаций, будут пройдены основный грабли и придёт понимание что там надо выкинуть сразу, что хитро настраивать и т.д. В общем, года через три можно будет глянуть ещё раз.
> конечно, документированы и гарантирована их неизменность?Пока что гарантивана их разнородность и сложность:
/proc marking
C Drop-in
C Library
C Library or Drop-in
CLI
D-Bus
Environment
Environment, flag files
Environment, Mounts
File format
File hierarchy change
Socket+Files
Subprocess
System Mode
Treaty
udev Property
> Хотите сказать, что любую ненужную часть можно выкинуть и остальное будет работать?
> И что можно влёгкую заменить любой компонент на самописный? И интерфейсы,
> конечно, документированы и гарантирована их неизменность?окститесь ещё даже не все анонсированные изначально фичи реализованы, а у нас тут блидинг эдж хватит лезть в неоконченную работу, если этого не понимаете.
> хватит лезть в неоконченную работуБр-р, так добрая половина претензий как раз к тому, что сырую реализацию стопки в общем неплохих идей раньше времени пытаются вывалить на головы _всем_, причём без исключения.
Там ещё года на два работы до состояния "рекомендованный способ загрузки любого generic linux distro" даже леннартовскими темпами, IMHO. И работа с сообществом в кооперативном стиле, а не флеймогенерирующем, только бы помогла.
>> хватит лезть в неоконченную работу
> Бр-р, так добрая половина претензий как раз к тому, что сырую реализацию
> стопки в общем неплохих идей раньше времени пытаются вывалить на головы
> _всем_, причём без исключения.
> Там ещё года на два работы до состояния "рекомендованный способ загрузки любого
> generic linux distro" даже леннартовскими темпами, IMHO. И работа с
> сообществом в кооперативном стиле, а не флеймогенерирующем, только бы помогла.плюсуемо! просто сообщество линукс из сообщества разработчиков за последние 10 лет превратилась в сообщество пользователей и проходивших мимо.. впрочем свойство людей игнорировать очевидное уже записао как основное, такчто будет не лишним почаще напоминать об этом.
ЗЫ я за обязательный дисклэймер о экспериментальном статусе разработки в каждой новости.
Хрен отвечающий вот так на баги https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=... вам накодирует, дааа.
«We do not support display managers whose primary VT is not VT1. That is by design.»ой, как чудесно. всё, после этого на системды можно поставить крест и отнести её на помойку.
Чтобы ещё чудесней стало http://bugzilla-attachments.gnome.org/attachment.cgi?id=220506
> Чтобы ещё чудесней стало http://bugzilla-attachments.gnome.org/attachment.cgi?id=220506молодцы, чо. после этого я полностью уверен в отсутствии мозга у портерофанов.
> Через 5 лет в /usr/bin ничего кроме systemd не останется, который тоже
> сдохнет под собственным весом.
> Казалось бы, всего лишь нужно определить области ответственности системных процессов (запуск/инициализация,
> логгирование, управление сервисами), проработать качественные интерфейсы этих процессов,
> дать им хорошую, современную шину для взаимодействия и спокойно развивать по
> отдельности эти демоны.шурх шурх.. ребята из редхат при разработке системд именно так и делают.
Они так вроде бы делают - а потом оказываются, что процессы друг от друга слишком многого ждут и имеют кучу предположений об окружении, в котором запущены.
> Они так вроде бы делают - а потом оказываются, что процессы друг
> от друга слишком многого ждут и имеют кучу предположений об окружении,
> в котором запущены.да у вас людей с этим вообще проблема приходишь в магазин а там все пиджаки на 2 руки рассчитаны. что за фигня? я ведь завтра могу эволюционировать и получить 3 руки почему пиджакошители об этом не думают?
>> Они так вроде бы делают - а потом оказываются, что процессы друг
>> от друга слишком многого ждут и имеют кучу предположений об окружении,
>> в котором запущены.
> да у вас людей с этим вообще проблема приходишь в магазин а
> там все пиджаки на 2 руки рассчитаны. что за фигня? я
> ведь завтра могу эволюционировать и получить 3 руки почему пиджакошители об
> этом не думают?Всё немного проще. У меня 52 размер и мне не нравится, что системд пытается натянуть на меня 48, потому что Поттеринг считает, что этот размер лучше и дургих не надо...
> Всё немного проще. У меня 52 размер и мне не нравится, что
> системд пытается натянуть на меня 48, потому что Поттеринг считает, что
> этот размер лучше и дургих не надо...блин а такая былабы шутка еслиб системд не прыгнул на нумерацию удава...
типа поддержку 52 размера обещали к 52 версии системд...
но впрочем стоит подождать пока потттеринг достроит свой дом о 51 этажа и начнёт класть крышу прежде чем говорить что он не хочет строить 52 этаж.
> да у вас людей с этим вообще проблема приходишь в магазин а
> там все пиджаки на 2 руки рассчитаны. что за фигня?systemd расчитан на управление пиджаками?
>> да у вас людей с этим вообще проблема приходишь в магазин а
>> там все пиджаки на 2 руки рассчитаны. что за фигня?
> systemd расчитан на управление пиджаками?нет но пиджаками удобно ловить людей 3.0
> Через 5 лет в /usr/bin ничего кроме systemd не останетсяА-аа, я понял, им не дают покоя лавры busybox! ;-)
>>Обычно для защиты логов от подмены записей в результате взлома используют средства журналирования на внешние syslog-серверы, но такой способ требует привлечения дополнительных ресурсов и усложнения конфигурации. FSS позволяет гарантировать целостность локально сохранённых логов, но требует периодического сохранения сгенерированных проверочных ключей на внешние системы или носителиЕсли внешние сервера все равно нужны, уж лучше на них отсылать логи чем ключи. Иначе злоумышленник просто удалит локальный лог и вы останетесь с ключами, но без логов.
> Если внешние сервера все равно нужны, уж лучше на них отсылать логи
> чем ключи. Иначе злоумышленник просто удалит локальный лог и вы останетесь
> с ключами, но без логов.Идея в том, что внешний сервер как раз не нyжен. Админу достаточно сфоткать QR-код на мобилку.
> сфоткать QR-код на мобилку.Оправдаем блондинок, фотающих на мобилку монитор? =)
*(сарказм, но с долей правды)
> Оправдаем блондинок, фотающих на мобилку монитор? =)Теперь это будут делать бородатые дядьки в свитерах =)
Жеесть =)
А у меня нет фотоаппарата в телефоне, у меня в телефоне есть только телефон. Видимо, мне придется прикладывать к монитору сканер? Или лучше класть монитор в ксерокс? Никак не пойму - посоветуйте.
> А у меня нет фотоаппарата в телефоне, у меня в телефоне есть
> только телефон. Видимо, мне придется прикладывать к монитору сканер? Или лучше
> класть монитор в ксерокс? Никак не пойму - посоветуйте.толсто же ну есть телефон сфотал нет по старинке скопировал файлы ключеё, ну чо вы как в детсаде то?
> Идея в том, что внешний сервер как раз не нyжен.Эта "идея" полностью глупая.
Убедиться, что система скомпрометирована - это, конечно, хорошо. Но одного этого мало. Вот почему польза от этой "технологии" - почти нулевая и самого обычного сервера логов она никак не заменит.
> Админу достаточно сфоткать QR-код на мобилку.
Ага. И потом любоваться этим QR-кодом. А действия злоумышленника по удаленным логам - восстанавливать телепатически.
>> Идея в том, что внешний сервер как раз не нyжен.
> Эта "идея" полностью глупая.
> Убедиться, что система скомпрометирована - это, конечно, хорошо. Но одного этого
> мало. Вот почему польза от этой "технологии" - почти нулевая
> и самого обычного сервера логов она никак не заменит.
>> Админу достаточно сфоткать QR-код на мобилку.
> Ага. И потом любоваться этим QR-кодом. А действия злоумышленника по
> удаленным логам - восстанавливать телепатически.удаление логов обычно не так страшно как их подмена, в случае когда сохранность логов необходима да их надо записывать в недоступное для удаления место энивэй.
> удаление логов обычно не так страшно как их подмена, в случае когда
> сохранность логов необходима да их надо записывать в недоступное для удаления
> место энивэй.Ну вот и нахрена тогда козе боян?
ну в случае с журналд он может писать на диск уже криптованные логи и ихже слать на
логсервер, что снижает достаточно низкий, но не нулевой шанс перехвата и подмены логов
в процессе отправки на сервер до нуля, хотя козе виолончелистке боян по прежнему
н.е н.у.ж.е.н..
мне правда жаль!
> ну в случае с журналд он может писать на диск уже криптованные
> логи и ихже слать на логсервер, что снижает достаточно низкий, но не нулевой шанс перехватаА можно сперва почитать про стандарты и давно существующие решения сей проблемы. Только и всего.
И никакой "криптованной" бинарной лабуды где она нафиг не нужна.
> А можно сперва почитать про стандарты и давно существующие решения сей проблемы.
> Только и всего.
> И никакой "криптованной" бинарной лабуды где она нафиг не нужна.ох еслиб это было целью написания журнала его никто бы не писал.. а причина появления шифрования как оказалось проста раз другой поттеринг её придумал и её можно сдесь реализовать, то почему бы и нет?
> почему бы и нет?Потому что не нужно. Все что нужно - безопасно доставить логи с минимальными задержками на другой хост. Решениям, умеющим это хорошо - сто лет в обед.
>> почему бы и нет?
> Потому что не нужно. Все что нужно - безопасно доставить логи
> с минимальными задержками на другой хост. Решениям, умеющим это хорошо
> - сто лет в обед.давай ты сам придумаешь параноидальный вариант когда логи будут подменены в удачный момент?
> давай ты сам придумаешь параноидальный вариант когда логи будут подменены в удачный
> момент?Блестяще. "Придумайте за меня проблему для вашего решения". Неа, тренируйся, чадо - мозг использовать самостоятельно.
уже который раз игнорируется вопрос со сторонним оборудованием. циско, жунипер, ембедед линух будет плевать сислог. и журналд тут совершенно не поможет как не паранойничай.
>> Все что нужно - безопасно доставить логи с минимальными задержками на другой хост.
> [...] параноидальный вариант когда логи будут подменены в удачный момент?С сетевой доставкой более вероятным представляется record & replay, а не именно подмена по дороге или замена на лог-сервере при надлежащей его организации.
> С сетевой доставкой более вероятным представляется record & replay, а не именно
> подмена по дороге или замена на лог-сервере при надлежащей его организации.Как бы нам не заметить, что кусок логов от 12 Nov 2009 пришел к нам, например, еще раз 11 Sep 2012 :)
TIMESTAMP - часть RFC для syslog протокола и любой его модификации/расширения.
>[оверквотинг удален]
>> Эта "идея" полностью глупая.
>> Убедиться, что система скомпрометирована - это, конечно, хорошо. Но одного этого
>> мало. Вот почему польза от этой "технологии" - почти нулевая
>> и самого обычного сервера логов она никак не заменит.
>>> Админу достаточно сфоткать QR-код на мобилку.
>> Ага. И потом любоваться этим QR-кодом. А действия злоумышленника по
>> удаленным логам - восстанавливать телепатически.
> удаление логов обычно не так страшно как их подмена, в случае когда
> сохранность логов необходима да их надо записывать в недоступное для удаления
> место энивэй.Поскольку кроме логов определить что было сделано с системой не позволяет ничто, то сохранность логов для сервера - это импириатив. А для десктопа, ваша супер пупер крипто цепочка нафиг ненужна.
IMHO, там где стоит вопрос о защите целостности логов настолько чтобы заморачиваться с сохранением ключа на внешний носитель - отдельный сервер имеет куда больший смысл. например в случае отказа аппаратуры там можно будет понять что и как умирало. Причём в случае чего - до того, как будет разобрана каша из умерших винтов.
> Идея в том, что внешний сервер как раз не нyжен. Админу достаточно сфоткать QR-код на мобилку.Как же я хочу посмотреть на это дело. Так и представляю очередь таких дебилов-админов к этому локалхосту. И каждый фоткает - кто на айфон, кто на самсунг, кто на ноклу. Нет ну особо продвинутые додумаются сфоткать на один смарт, а потом всем друзьям расшарить через гугл+ - это же так удобно. Это кстати хорошая идея для плотерринга - пусть приблуду для гуглплея напишет.
> Если внешние сервера все равно нужны, уж лучше на них отсылать логи
> чем ключи. Иначе злоумышленник просто удалит локальный лог и вы останетесь
> с ключами, но без логов.а ещё лучше когда у тебя есть и ключи(в мобильнике админа как нам например предлагают) и логи на внешнем сервере.
Он начинает мне напоминать LeechCraft.
> Он начинает мне напоминать LeechCraft.В LeechCraft добавят wayland. А в systemd ядро. А потом оба проекта объявят о слиянии кода.
>> Он начинает мне напоминать LeechCraft.
> В LeechCraft добавят wayland. А в systemd ядро. А потом оба проекта
> объявят о слиянии кода.После чего сколлапсируют в черную дыру, видимо...
>>> Он начинает мне напоминать LeechCraft.
>> В LeechCraft добавят wayland. А в systemd ядро. А потом оба проекта
>> объявят о слиянии кода.
> После чего сколлапсируют в черную дыру, видимо...занято! в чёрной дыре штаб квартира нашего клуба.
Ну и крон заодно туда встроить, а то наплодили тут демонов. Да и почтовик. А то куда будет крон отсылать свои сообщения? Ну и sshd, конечно, такой критический сервис должен быть частью системы, а не прикручиваться сбоку проволокой.
Да вот создаётся впечатление, что туда товарищи и бегут. лучше им идеи не подавать, пожалуй :-) А то придётся ж LFS шаманить для получения нормальной удобной системы.
Cron давно уже в systemd свой
> Ну и крон заодно туда встроить, а то наплодили тут демонов. Да
> и почтовик. А то куда будет крон отсылать свои сообщения? Ну
> и sshd, конечно, такой критический сервис должен быть частью системы, а
> не прикручиваться сбоку проволокой.функционал крона уже есть, позволяет пускать сервисы по событиям в том числе временным.
Он таки сделал логи бинарными?
Они и были уже бинарными. Сейчас анонс о другой фиче - защита от изменяемости.
Насколько я помню, он их бинарными хотел сделать как раз для того, чтобы реализовать эту защиту от изменений. Больше ни для чего бинарные логи не нужны...
> Он таки сделал логи бинарными?до момента распечатки на принтере все логи бинарные.
на бумаге тоже
> на бумаге тожену если у тебя есть идеально монохромный принтер( с точки зрения физики такой не возможен) то да, шутку оценил, но увы тут полно неадекватов.
Вы так говорите, будто это что-то плохое.
Плохое. Во-первых, для просмотра бинарных логов нужна дополнительная библиотека/утилита, которая сама по себе может быть источником ошибок и уязвимостей. А во-вторых, если, допустим, упадёт файловая система, то повреждённый - даже частично! - зашифрованный бинарный лог можно смело выбрасывать на помойку, тогда как из повреждённого текстового лога можно извлечь хоть какую-то информацию.
> Плохое. Во-первых, для просмотра бинарных логов нужна дополнительная библиотека/утилита,
> которая сама по себе может быть источником ошибок и уязвимостей. А
> во-вторых, если, допустим, упадёт файловая система, то повреждённый - даже частично!
> - зашифрованный бинарный лог можно смело выбрасывать на помойку, тогда как
> из повреждённого текстового лога можно извлечь хоть какую-то информацию.я уже говорил про это но для просмотра plain\text тоже нужна библиотека и программа. а если посмотреть на реальную практику где логи собираются в папочки и жмутся гзипом, их устойчивость к случайным повреждениям зависит от количества добавляемой информации для восстановления.
> я уже говорил про это но для просмотра plain\text тоже нужна библиотека
> и программа. а если посмотреть на реальную практику где логи собираются
> в папочки и жмутся гзипом, их устойчивость к случайным повреждениям зависит
> от количества добавляемой информации для восстановления.и если вы вдруг не догадались эту информацию можно добавлять в "бинарный" лог ещё на этапе записи файла.
> я уже говорил про это но для просмотра plain\text тоже нужна библиотека
> и программа.Да, только этих программ понаделаны тысячи. А для просмотра бинарного лога, скорее всего, будет сделана одна, работающая только под GNOME3. ;-)
> Да, только этих программ понаделаны тысячи. А для просмотра бинарного лога, скорее
> всего, будет сделана одна, работающая только под GNOME3. ;-)на 100% известно что рекомендовано будет пользоваться именно поттеринговской либой. но работать она будет навсех никсах.
> на 100% известно что рекомендовано будет пользоваться именно поттеринговской либой. но
> работать она будет навсех никсах.:-) Это смешно - UNIXов вагон и большая тележка. У всех разные компиляторы. Поэтому она даже банально не соберётся на половине.
>> на 100% известно что рекомендовано будет пользоваться именно поттеринговской либой. но
>> работать она будет навсех никсах.
> :-) Это смешно - UNIXов вагон и большая тележка. У всех разные
> компиляторы. Поэтому она даже банально не соберётся на половине.ну хорошо кроме тех где намерено сделают нерабочим.
> ну хорошо кроме тех где намерено сделают нерабочим.????????????? Это вы о чём?
>> ну хорошо кроме тех где намерено сделают нерабочим.
> ????????????? Это вы о чём?Это он о том, что он тролль.
>>> ну хорошо кроме тех где намерено сделают нерабочим.
>> ????????????? Это вы о чём?
> Это он о том, что он тролль.ну есть немного, но мы таки с вами на разных языках говорим для серьёзного разговора.
> для просмотра plain\text тоже нужна библиотека и программа.Эти программы входят в любой *nix уже лет сорок как. (местами это довод не знающих про rpm2cpio.sh дебианщиков в пользу .deb, ага)
> а если посмотреть на реальную практику где логи собираются в папочки и жмутся гзипом
...то жмутся _архивные_ логи, а не рабочие.
>> для просмотра plain\text тоже нужна библиотека и программа.
> Эти программы входят в любой *nix уже лет сорок как. (местами это
> довод не знающих про rpm2cpio.sh дебианщиков в пользу .deb, ага)в моём случае это пример того что рассовая ненависть ко всему бинарному необоснована, до тех пор пока есть способы читать этот бинарник с достаточной скоростью.
>> а если посмотреть на реальную практику где логи собираются в папочки и жмутся гзипом
> ...то жмутся _архивные_ логи, а не рабочие.насяколько я понял из анонса системд тоже дописывает сжатые архивные блоки.
для чтения файловой системы на котором находится файл с логами тоже нужен драйвер, вас не пугает что файловая система это тоже бинарный формат?
Не пугает, т.к. я не занимаюсь чтением "файловой системы" :)
когда у вас логи будут бинарными, вы их тоже читать не будете. Так спокойнее?
Потому что гладиолус. Вы все аргументы исчерпали? :)
> Потому что гладиолус. Вы все аргументы исчерпали? :)ну тут остаётся только вызвать вам психоаналитика.. впрочем всегда есть санитары с разупорином.
И откуда вы такие никнеймы себе подбираете..
</dev/urandom tr -dc 'a-zA-Z0-9' | head -c 8
Хех, бинарные логи. А представьте как это будет замедлять систему на этапах зашифровывания/расшифровывания лога. А избыточность веса.Поттеринг снова шагнул далеко вперед!
> Хех, бинарные логи. А представьте как это будет замедлять систему на этапах
> зашифровывания/расшифровывания лога. А избыточность веса.
> Поттеринг снова шагнул далеко вперед!вообщето там оч низкий оверхэд который окупает ту метаинформацию которую мы при этом получаем.
>> Хех, бинарные логи. А представьте как это будет замедлять систему на этапах
>> зашифровывания/расшифровывания лога. А избыточность веса.
>> Поттеринг снова шагнул далеко вперед!
> вообщето там оч низкий оверхэд который окупает ту метаинформацию которую мы при
> этом получаем.При ассиметрике то??? ... Аа!!! Оно ещё будет расчитанно на наличие в системе криптопроцессора, или, как минимум, на GPU c CUDA или OpenCL.
>>> Хех, бинарные логи. А представьте как это будет замедлять систему на этапах
>>> зашифровывания/расшифровывания лога. А избыточность веса.
>>> Поттеринг снова шагнул далеко вперед!
>> вообщето там оч низкий оверхэд который окупает ту метаинформацию которую мы при
>> этом получаем.
> При ассиметрике то??? ... Аа!!! Оно ещё будет расчитанно на наличие в
> системе криптопроцессора, или, как минимум, на GPU c CUDA или OpenCL.ну ладно расшифрование таки да, но зато теперь будет смысл брать топовые процы от интела.
>>>> Хех, бинарные логи. А представьте как это будет замедлять систему на этапах
>>>> зашифровывания/расшифровывания лога. А избыточность веса.
>>>> Поттеринг снова шагнул далеко вперед!
>>> вообщето там оч низкий оверхэд который окупает ту метаинформацию которую мы при
>>> этом получаем.
>> При ассиметрике то??? ... Аа!!! Оно ещё будет расчитанно на наличие в
>> системе криптопроцессора, или, как минимум, на GPU c CUDA или OpenCL.
> ну ладно расшифрование таки да, но зато теперь будет смысл брать топовые
> процы от интела.хотя стоп зачем? мыж ключ раз в 15 минут генерим и только в одну сторону и только для подписи.. хотя шифрование тож былобы не лишним.
Первый раз вижу qr код в консоле. Интересная идея и вполне читаемо
Да, одна из немногих разумных идей - при условии, что это не единственный путь, конечно.
> Да, одна из немногих разумных идей - при условии, что это
> не единственный путь, конечно.плохая идея - QR библиотеки имеют плохую лицензию + в QR плохо ложатся бинарные данные + имеются ограничения на их максимальный размер (2 или 4 килобайта, чего впритык хватает)
лучше всегда и везде использовать православный DataMatrix
> Первый раз вижу qr код в консоле. Интересная идея и вполне читаемохм в целом идея не нова gpg генераторы ключей давно рисуют подобные картинки, вопрос 15 строк кода сделать из этого qr код
Сделай. Тебе все будут благодарны.
> Сделай. Тебе все будут благодарны.окей когда буду учить яваскрипт сделаю.
> вопрос 15 строк кода сделать из этого qr кодВы в 15 строк умудряетесь втиснуть генерацию нехилого кода коррекции ошибок, брейнфакерского размещения битов по полям и прочая? :)
длина строк-то не уточняется. в принципе, и всё ядро можно в одну строку уместить, если постараться.
> Для упрощения операции сохранения проверочных ключей их предлагается выводить на терминал, дав возможность администратору легко сфотографировать новый ключ телефоном.АТОМНО! ржали всем офисом. больше всех ржал сисадмин.
Да ладно, сейчас смартфон чуть ли не у каждой собаки. А если таки не на что - они ж обычный файлик тоже создают, полагаю. Ну какие реальные минусы, кроме непривычности? а плюсы есть - работает даже если сеть не поднята, хорошо заметен ключ - легко вспонить, что его скопировать надо, на смартфоне он может выжить с хорошей вероятностью. А что это не для серьёзного применения (а потому аргументы о пакетной установке неприменимы) - и так понятно, там один хрен удаленное логирование нужно.
> Ну какие реальные минусы, кроме непривычности?хочу увидеть автоматизированый бэкап этой фотографии. а также узнать, что делать, если смартфон потеряли или в самый нужный момент села батарейка/разбился экран/смартфон взорвался.
я ж говорю: админы локалхоста об этом не задумываются. поэтому нежно любят системд и портеринга: последний мыслит примерно как админ локалхоста, отсюда у них любовь и взаимопонимание.
Кстати, теперь можно будет требовать с начальства окромя служебных флешек, еще и навороченные смарты. :)
>> Ну какие реальные минусы, кроме непривычности?
> хочу увидеть автоматизированый бэкап этой фотографии. а также узнать, что делать, если
> смартфон потеряли или в самый нужный момент села батарейка/разбился экран/смартфон взорвался.
> я ж говорю: админы локалхоста об этом не задумываются. поэтому нежно любят
> системд и портеринга: последний мыслит примерно как админ локалхоста, отсюда у
> них любовь и взаимопонимание.шурх шурх, а кто-то ещё не бэкапит важную информацию со смартфона в надёжных местах?
какой-то идиот хранит *важную информацию* на смарте? а, ну да, админы локалхоста же…
> какой-то идиот хранит *важную информацию* на смарте? а, ну да, админы локалхоста
> же…не хранить важную информацию которой пользуется смартфон на смарте не то что глупо а очевидно невозможно. у информации есть разные степени важности которые можно свести к: лучше утратить чем рассекретить и лучше рассекретить чем утратить.
> не хранить важную информацию которой пользуется смартфон...Речь шла о сохранении ключей, вообще-то. Ну и какого хрена этими ключами будет пользоваться смартфон? И для каких целей? В гугл/эппл/... автоматически отправлять или именно сам с ними чего-то будет делать?
>> не хранить важную информацию которой пользуется смартфон...
> Речь шла о сохранении ключей, вообще-то. Ну и какого хрена этими ключами
> будет пользоваться смартфон? И для каких целей? В гугл/эппл/... автоматически отправлять
> или именно сам с ними чего-то будет делать?в случае с ключами он будет получать ключь из qr кода и сохранять в криптохранилище( считаю логичным иметь такое на смарте)и забэкаплен в шифрованом виде на какойнить дропбокс\сахарок
просто была нападка на несовместимость важных данных и смартфона, привёл обратный пример.
> ключьвопросов больше нет.
> вопросов больше нет.А я думал что словечки типа "дропбокс" надежно диагностируют хомячка. Готового жрать любой кактус.
> А я думал что словечки типа «дропбокс» надежно диагностируют хомячка.да ладно, дропбокс определённо лучше файлопомоек «скачать бесплатно без смс на большой скорости». для того, кто скачивает, натурально.
а я считаю что вы просто закостенелые ребята без фантазии которые не умеют делать иначе чем научились и мешают другим. надеюсь что и с большим возрастом я так и не стану консервативным.
не станешь, не переживай. и твой локалхост у тебя никто не отберёт.
> не станешь, не переживай. и твой локалхост у тебя никто не отберёт.у меня его нет. я работаю в другой сфере.
> у меня его нет. я работаю в другой сфере.то есть, ты даже локалхост не админишь. но Мнение Имеешь. молодец, Илитарный Иксперт.
> надеюсь что и с большим возрастом я так и не стану консервативным.Только если мозги не включатся: "Кто в молодости не был революционером – у того нет сердца. Кто в старости не стал консерватором – у того нет мозгов."
Не льстите себе. Старость - это когда мозги уже заржавели и способность к (пере)обучению утрачена. После чего все новые знания воспринимаются в штыки.
> Старость - это когда мозги уже заржавелиСудя по комментам: поттерофилы старые четырнадцатилетние пердуны - мозги заржавели до начала эксплуатации.
Та я ж не спорю, что это не для больших систем. А для локалхоста - таки удобно, чего ж нет.
> Та я ж не спорю, что это не для больших систем. А
> для локалхоста - таки удобно, чего ж нет.Ушел за экзорцистом...
> хочу увидеть автоматизированый бэкап этой фотографии.Хочешь я такое покажу? Rsync на телефоне - и нет проблем, линукс еще и не так изогнуться позволяет. Просто попинываем телефон изредка "ответным" rsync-ом. Как появился в сети - так и забэкапался туда откуда пинали (у меня это роутер с присоединенным винчом). Вполне себе автоматически.
> а также узнать, что делать, если смартфон потеряли или в самый нужный момент села
> батарейка/разбился экран/смартфон взорвался.Могу предложить сценарии ужастиков и покруче: прилетел метеорит! Хотя это недостаточно круто. Вот метеоритный дождь раздолбавший все ДЦ с бэкапами - уже нормальненько. Еше можно вторжение инопланетян рассмотреть. Ну или например электричество в розетке кончится.
> я ж говорю: админы локалхоста об этом не задумываются. поэтому нежно любят
> системд и портеринга: последний мыслит примерно как админ локалхоста, отсюда у
> них любовь и взаимопонимание.Да ладно тебе, это лишь еще +1 метод передачи ключей. Достаточно удобный, кстати - надо отдать чуваку должное за то что не зашорен стереотипами и нашел баловству и более полезное прменение чем рекламный спам. Хоть оно и совсем не главное в системе логгинга и инициализации :)
>> хочу увидеть автоматизированый бэкап этой фотографии.
> Хочешь я такое покажу?да. у меня вот няшный китайский CAXIO. Настоящее Китайское Качество, все дела. ну, нравится он мне. совершенно нестандартная прошивка, ещё и без всякой жабы. покажи. нет, «купи себе ведроид» не катит, про смену аппарата речи не было.
>> я ж говорю: админы локалхоста об этом не задумываются. поэтому нежно любят
>> системд и портеринга: последний мыслит примерно как админ локалхоста, отсюда у
>> них любовь и взаимопонимание.
> Да ладно тебе, это лишь еще +1 метод передачи ключей.вот так из буханки хлеба можно сделать троллейбус. но зачем? (ц)
> кстати — надо отдать чуваку должное за то что не зашорен
> стереотипами и нашел баловству и более полезное прменение чем рекламный спам.а ещё можно кодировать в циферки и пропискивать DTMF-ом. по-моему, даже круче. записал на диктофон и рад.
> Да ладно, сейчас смартфон чуть ли не у каждой собаки.У всех есть ручка и бумажка. Смартфоны, кстати, частенько тырят.
>> Да ладно, сейчас смартфон чуть ли не у каждой собаки.
> У всех есть ручка и бумажка. Смартфоны, кстати, частенько тырят.Смартами частенько мусорят в кабаках, йоптиль! Кой хрен тырят-то...
PS. Дарю идею - смарт, имплантированный в башку админа. Если только апстена пробежит, правда.... )
> У всех есть ручка и бумажка.У меня нету. А зачем они мне? Бумажку потерять еще проще чем смарт, кстати.
>> У всех есть ручка и бумажка.
> У меня нету. А зачем они мне? Бумажку потерять еще проще чем
> смарт, кстати.зато ее в клочки порвать не жалко и съесть можно, в отличии от смарт )
Админ пусть продожает спать!... А мыши пусть ржут!... Это гламурно, Это тренд! Надеюсь у админа все в наличии? )))
Да-а, довод достойный системного программиста.
Давно так не смеялся.
Видно задание сделать фотографию ключа системщик воспринял буквально.
тэг -- история успеха :)
> тэг -- история успеха :)[генератор QR кодов][скачать бесплатно][Linux][Поттеринг][systemd]
Учитесь как надо :)
А есть такой генератор QR-кодов в консоли в виде отдельного приложения?
qrencode
>плюсы есть - работает даже если сеть не поднятаА если еще и комп выключен - работает вообще идеально!
ЗЫж И как мы раньше-то мыкались, горемычныя, как сеть в даун - так усё, логи кончились. Пока не пришел Леня и светом своим лучезарным нас, грешных, не озарил...
Не тупи. Речь шла о том, что как только эта ерунда поднялась, можно сразу ключ себе скинуть. Остроумно, как по мне.
>>Для упрощения операции сохранения проверочных ключей их предлагается выводить на терминал, дав возможность администратору легко сфотографировать новый ключ телефоном.<<Так и представил себе степенного, в костюме с галстуком, администратора RedHat Linux, фотографирующего своим мощным смартфоном HTC секретный ключ с экрана консоли в серверной. Внушает.
> Так и представил себе степенного, в костюме с галстуком, администратора RedHat Linux,
> фотографирующего своим мощным смартфоном HTC секретный ключ с экрана консоли в
> серверной. Внушает.О да, и моники к серверам можно будет выбивать.:)
>> Так и представил себе степенного, в костюме с галстуком, администратора RedHat Linux,
>> фотографирующего своим мощным смартфоном HTC секретный ключ с экрана консоли в
>> серверной. Внушает.
> О да, и моники к серверам можно будет выбивать.:)зачем сразу по ссш со смартфона а потом бац и скриншот. нью фажные админы оч любят админить сервы из дома со своих андроид смартов.
> нью фажные админы оч любят админить сервы из дома со своих андроид смартов.это да, хорошо. пролюбил смарт — добро пожаловать на сервера. люблю таких няшечек.
>> нью фажные админы оч любят админить сервы из дома со своих андроид смартов.
> это да, хорошо. пролюбил смарт — добро пожаловать на сервера. люблю таких
> няшечек.хм ну обычно смартфон без знания пароля бесполезен, но описаных тобой няшек я бы тоже любл.
> хм ну обычно смартфон без знания пароля бесполезендостали модуль памяти, засунули в читалку, забрали вкусняшки, радуемся. зачем тут пароль — не ясно.
>> хм ну обычно смартфон без знания пароля бесполезен
> достали модуль памяти, засунули в читалку, забрали вкусняшки, радуемся. зачем тут пароль
> — не ясно.О_о на сервер ты как без пароля попадёшь? алсо у тебя что в смарте нет шифрования диска?
> алсо у тебя что в смарте нет шифрования диска?судя по каментам нет не только шифрования диска, но и самого смартфона.
> О_о на сервер ты как без пароля попадёшь?именно так, как и попадаю на свои сервера. пойди, почитай про авторизацию по ключу. хотя тебе, как админу локалхоста, может быть удивительно: «зачем такие сложности? ведь пароль 'barsik' запомнить несложно!»
> хм ну обычно смартфон без знания пароля бесполезен, но описаных тобой няшек
> я бы тоже любл.Пароль "для защиты аппарата" там обычно весьма декоративный и снимается за несколько минут. Ну, кроме случая когда истинный маньяк-линуксоид воткнул нечто типа трукрипта или LUKS - с таковыми халявы не дождешься разумеется :)
> Ну, кроме случая когда истинный маньяк-линуксоид воткнул нечто типа трукрипта
> или LUKS — с таковыми халявы не дождешься разумеется :)это немного другой контингент уже. но их обычно три с половиной инвалида на тысячи.
>> Так и представил себе степенного, в костюме с галстуком, администратора RedHat Linux,
>> фотографирующего своим мощным смартфоном HTC секретный ключ с экрана консоли в
>> серверной. Внушает.
> О да, и моники к серверам можно будет выбивать.:)ip kvm вам хватит ;-)
>>>Для упрощения операции сохранения проверочных ключей их предлагается выводить на терминал, дав возможность администратору легко сфотографировать новый ключ телефоном.<<
> Так и представил себе степенного, в костюме с галстуком, администратора RedHat Linux,
> фотографирующего своим мощным смартфоном HTC секретный ключ с экрана консоли в
> серверной. Внушает.секретность такого ключа сомнительна его утечка сама по себе не критична, а играя на том уровне когда этим можно воспользоваться.. есть пути проще.
Это публичный ключ. Секретный вообще удаляется сразу после создания им одной подписи.
> Так и представил себе степенного, в костюме с галстуком, администратора RedHat Linuxs/RHL/RHEL/ ! :)
Это ещё что, теперь представьте окучивание оным стопки блейд-шасси... напряжённый взгляд, продуманная схема именования снимков, невероятная ответственность за происходящее.
>> Так и представил себе степенного, в костюме с галстуком, администратора RedHat Linux
> s/RHL/RHEL/ ! :)
> Это ещё что, теперь представьте окучивание оным стопки блейд-шасси... напряжённый взгляд,
> продуманная схема именования снимков, невероятная ответственность за происходящее.Самому-то еще не смешно, не? А датацентр на 5к серверов - представил? :D:D:D
> Самому-то еще не смешно, не? А датацентр на 5к серверов - представил?Что там представлять, разворачивал софт на кластере в 5k лезвий.
> :D:D:D
Иной народ из Афгана до сих пор курит в горсточку -- чтоб не выдавать местоположение головы ночью за пару километров. Но Вы же пишете не для обсуждения, вот и не дошло до сих пор, что "опусы" оперативно удаляются. Так что спасибо за сигнатурку. <прицеливаясь>
> Иной народ из Афгана до сих пор курит в горсточку -- чтоб
> не выдавать местоположение головы ночью за пару километров.А дронам пофиг - у них ИК камеры обычно есть. Да и приборы ночного видения давно перестали быть экзотикой. Так что кури, не кури...
Не понял третий абзац. Прочитал оригинал, опять не понял. Ткните, плиз, где у меня неадекватное восприятие реальности?То есть сбросить логи на соседний сервер - это нипадецки сложная конфигурация. Гораздо проще генерить ключи и опять сбрасывать их на соседний сервер...
Или сидеть и щёлкать сгенерированную хрень на мониторе...
Наверно ещё проще и надёжнее просто выводить лог на экран и снимать кино вэбкамерой. И отснятые шедевры снова хранить на соседнем сервере...
> Наверно ещё проще и надёжнее просто выводить лог на экран и снимать кино вэбкамерой. И отснятые шедевры снова хранить на соседнем сервере...Нет конечно. Каждый кадр на видео надо тоже сделать с хешами и прочими салями. А то вдруг проклятый умышленник и видео подменит? А к видео свой кур код. И пусть админы обкурятся этими кур-кодами.
>> Наверно ещё проще и надёжнее просто выводить лог на экран и снимать кино вэбкамерой. И отснятые шедевры снова хранить на соседнем сервере...
> Нет конечно. Каждый кадр на видео надо тоже сделать с хешами и
> прочими салями. А то вдруг проклятый умышленник и видео подменит? А
> к видео свой кур код. И пусть админы обкурятся этими кур-кодами.в куркод даже гифосмайл запихнуть тяжело а ты видео
> в куркод даже гифосмайл запихнуть тяжело а ты видеоя верю в леннарта.
> Нет конечно. Каждый кадр на видео надо тоже сделать с хешамиО, а это идея: QR код с хешом - как лого вывешенное в кадр видео. А если там (magnet) ссылку зашить - видео будет всем окружающим рассказывать где его скачать :)
Там написана ложь. Нужно записать или распознать ключ один раз.
Потом с помощью него всегда можно проверить свои логи.
> Не понял третий абзац. Прочитал оригинал, опять не понял. Ткните, плиз, где
> у меня неадекватное восприятие реальности?
> То есть сбросить логи на соседний сервер - это нипадецки сложная конфигурация.
> Гораздо проще генерить ключи и опять сбрасывать их на соседний сервер...
> Или сидеть и щёлкать сгенерированную хрень на мониторе...
> Наверно ещё проще и надёжнее просто выводить лог на экран и снимать
> кино вэбкамерой. И отснятые шедевры снова хранить на соседнем сервере...речь о том что раньше это был единственный путь, а теперь у тебя есть ещё один слой защиты логов. речь не о том что проще а о том что надёжнее.
Оно для локалхоста, судя по всему. Нет там соседней машины, некуда там логи сбрасывать, и настраивать всё это некому. А смартфон - с вероятностью у хозяина есть, и инструкции для проверки можно сделать вполне "чайниковые".
http://upload.wikimedia.org/wikipedia/commons/6/60/Lennart_P...
На биллгейтса похож.
> На биллгейтса похож.хз кто такой биллгейц, но этот похож на человека, фотающего QR код сислога.
Просто оставлю это здесь, для любителей системд:
http://www.linux.org.ru/forum/talks/8127329#comment-8127509
и далее
Отличная вещь !!! Особенно штрих-код в консоле !!! Интересно, а фотоаппараты для его фиксации где можно будет получить, Лёня будет высылать?
П.С.: Поздно фотку из 1.191 заметил . Так у Лёни оказывается Сanon - чур мой будет !
> Отличная вещь !!! Особенно штрих-код в консоле !!! Интересно, а фотоаппараты для
> его фиксации где можно будет получить, Лёня будет высылать?Фотоаппаратом является любой современный смарт с камерой. Он же и декодирует содержимое. Кстати у QR кода на редкость брейнфакерская логика формирования оного :)
QR код в консоли. Лол, феерический п-ц!..
Вот, ещё один довод в пользу systemd. Люблю я эту систему инициализации.
Странное совпадение? Пару месяцев назад вывод QR в качестве логов был реализован в haiku
> Странное совпадение? Пару месяцев назад вывод QR в качестве логов был реализован
> в haikuждём синих куркодов смерти.
> ждём синих куркодов смерти.Не, с их некромансией это будет как максимум синий штрихкод с кодом ошибки :)
К любителям fedora/systemd есть прикладной вопрос насчёт telinit u:
https://bugzilla.altlinux.org/show_bug.cgi?id=27666#c9
> К любителям fedora/systemd есть прикладной вопрос насчёт telinit u:
> https://bugzilla.altlinux.org/show_bug.cgi?id=27666#c9интересно, ответит кто-нибудь?
впрочем, я подозреваю, что «это не надо». как поддержка разных VT.