Re: Используете ли вы антивирус и фаервол?
On Sun, Apr 07, 2024 at 10:16:00PM +0300, Andrey Jr. Melnikov wrote: > ssh скорости не добавляет. между доверенными сетями проще rsync через родной > протокол использовать. Ага, на каждом хосте юнит-файлы нарисовать, конфиги с секциями, файлики для авторизации... вместо того, чтобы просто указать rsync-у хост назначения, чтобы он сам запустил ssh, авторизовался через него, сам создал серверный процесс rsync, и чтобы всё это само удалилось и освободило память после передачи данных. Да уж, проще некуда... :) > а в sid быстро-быстро liblzma обновился до версии 5.6.1+really5.4.5-1. > Маинтайнеры в debian нонче в двух супер-позициях - "тянем всё самое новое" и > "плевать мы хотели на обновления". В данном случае ликвидация дыры безопасности была намного важнее новизны. -- Eugene Berdnikov
Re: Используете ли вы антивирус и фаервол?
On Fri, Apr 05, 2024 at 12:39:41AM +0300, Dmitrii Kashin wrote: > Victor Wagner writes: > > > В Thu, 4 Apr 2024 15:48:27 +0200 > > Konstantin Matyukhin пишет: > > > >> Подозреваю, что не любит GMail quoted-printable кодировку в письмах :) > > > > А я вообще грешил на SPF + DMARC. Думал что-то не то там прописал, что > > гугль мои письма в подозрительные записал. Причем не те, которые > > прямые, прямые ходят, а именно через списки рассылки. > > % dig -t txt _dmarc.wagner.pp.ru +short > "v=DMARC1; p=reject; aspf=s; rua=mailto:postmas...@wagner.pp.ru; > > У Вас, Виктор, стоит p=reject. Какие тут вопросы? > Вам либо нужно выставить p=none, либо добавить в spf все рассылки. У Витуса письма без DKIM-а, а для lists.debian.org SPF не прописана. Кто считает, что в таком случае письма должны отвергаться по DMARC, ткните в конкретный пункт RFC7489, pls. -- Eugene Berdnikov
Re: Bounce и спам
On Mon, Mar 18, 2024 at 02:05:59PM +0300, Jan Krapivin wrote: >Пришло такое письмо. К сожалению, я ничего не понял, но не из-за плохого >английского. В чём тут проблема? Кто-то, пожалуйста, может простыми >словами сказать о чём речь? > >Никаких спам-фильтров у меня не стоит. Почта на Гугле. Заметил разве что, >что какие-то письма из рассылок Дебиана ушли в спам (только некоторые, не >все). И было такое, что в архиве письмо видел, а у себя на почте - нет. Причина в том, что Гугла есть спамовый классификатор, а его алгоритмы, скажем так, не идеальны. Простыми словами объяснить, в чём проблема этого достаточно сложного механизма -- вряд ли получится, но суть в том, что там получается "коллективная ответственность", когда наличие спаммера в одном почтовом домене портит жизнь не только другим пользователям этого домена, но и тем, кто в этом домене почты не имеет. Например, тем, у кого ящик на gmail-е и есть подписка на рассылку debian-users, куда прилетают письма из проблемного домена. К сожалению, народные верования в крутизну и непогрешимость Гугла это наивность. На практике всё не так радужно, а пожаловаться и исправить что-то в подобных случаях, я думаю, непросто. > >Спасибо > >"Dear subscriber, > >We've encountered some problems while sending listmail to your >emailaddress [1]daydreamer199...@gmail.com. > >In the last seven days we've seen bounces for the following list: >* debian-user > 1 bounce out of 178 mails in 7 days (0%, kick-score is 80%) > ([2]https://lists.debian.org/bounces/BClZeahHWgRdxNSHG485bg) > >(The link above points to a copy of the latest bounce >and will be valid for seven days.) > >If the bounce-rate passes the kick-score, our bounce-detection will >forcibly >remove your subscription. > >Bounces happen from time to time when spam slips through our filters but >are >rejected by your mail provider. If you are your own mail provider and use >'Before-Queue Content filtering', you should whitelist >[3]bendel.debian.org from >Content filtering. > >However: You can safely ignore this message (and you will not be >unsubscribed >:-) ) if your bounce rate remains low. > >For more information see [4]https://wiki.debian.org/Teams/ListMaster/FAQ > >You are welcome to contact [5]listmas...@lists.debian.org if you think >this >message was sent in error. > > Sincerely, >The Listmaster Team >-- >[6]http://lists.debian.org; > > References > >Visible links >1. mailto:daydreamer199...@gmail.com >2. https://lists.debian.org/bounces/BClZeahHWgRdxNSHG485bg >3. http://bendel.debian.org/ >4. https://wiki.debian.org/Teams/ListMaster/FAQ >5. mailto:listmas...@lists.debian.org >6. http://lists.debian.org/ -- Eugene Berdnikov
Re: Обрывы звука на Debian 12 Gnome
On Mon, Mar 11, 2024 at 01:32:35PM +0300, Jan Krapivin wrote: >вс, 10 мар. 2024 г. в 19:12, Иван Лох <[1]l...@1917.com>: >> >> Попробуйте посмотреть (и записать) трафик используя wireshark, в момент >> когда у вас пропадает/появляется звук > >Я установил Wireshark но почему-то не вижу там bluetooth соединения. Посмотрите пакет bluez-hcidump. -- Eugene Berdnikov
Re: Засыпание ноутбука после закрытия крышки
On Sun, Feb 18, 2024 at 06:46:42PM +0400, Maksim Dmitrichenko wrote: >вс, 18 февр. 2024 г. в 09:29, Max Nikulin : >> Можно попробовать найти input устройство >> journalctl -b --grep '\blid\b' >> и послушать, идут ли оттуда события, когда крышка >> открывается-закрывается > >Идут. Lid opened/Lid closed. Проблема в том, что это происходит достаточно >редко, и довольно трудно задетектить. Ты закрыл крышку, никакие огоньки не >горят. Как понять - ушел он в слип или нет? Понимаешь это только спустя >время, когда открыл крышку, а ноут либо сел вообще, либо там осталось >всего ничего. Это надо спецом садиться и воспроизводить. Пинговать с >другой тачки, ловить момент, когда пинги например идут, а крышка закрыта >(но не факт, что вайфай при этом остаётся) В окошке с шеллом набрать "while date ; do sleep 1 ; done", после закрытия и открытия крышки по отметкам времени будет видно, засыпал ноут или нет. Можно добавить по вкусу отображение разных регистров, относящихся к pm. -- Eugene Berdnikov
Re: Не запускается sshd в bullseye на виртуальной машине
On Fri, Feb 16, 2024 at 06:09:27PM +0300, Victor Wagner wrote: > В Fri, 16 Feb 2024 17:07:11 +0300 > Dmitrii Kashin пишет: > > > Если сборки частые -- то есть большая разница, занимает она семь > > минут или одну (помножаем на число сборок в день, получаем количество > > сэкономленного времени. Если собирается что-нибудь явовское -- есть > > Нет разницы. Потому что нормальные люди, которые хотят чтобы клиентам > достался работающий софт, после сборки запускают тесты. Бывает, что тест нагружает дисковую подсистему. И тут разница между контейнером и виртуалкой, которая эмулирует диск, становится очень даже заметной. Думаю, это должно особенно доставлять тогда, когда нет возможности запихнуть этот тест в файловую систему в оперативке -- например, потому что "не лезет", т.к. места на диске нужно слишком много. -- Eugene Berdnikov
Re: Не запускается sshd в bullseye на виртуальной машине
On Fri, Feb 16, 2024 at 12:04:49AM +, Misha Ramendik wrote: >On Thu, 15 Feb 2024 at 10:48, Dmitrii Kashin wrote: > >> Действительно ли Вы этого хотите? >> Если стоит задача собрать пакет, так просто возьмите контейнер с >> bullseye. >> Уж какой-нибудь docker, полагаю, на федоре найдётся. > >Всё очень просто. С контейнером пришлось бы разбираться, как прикручивать >ему persistent storage, чтобы не качать заново все дополнительные пакеты >для каждой новой сборки (пока было две, может ещё случиться, всё только >для себя - у меня есть VPS на bullseye). И с обменом файлами между >контейнером и хостом (собранное желательно куда-то деть). Для меня это было одной из главных причин, по которым docker пошёл на. С lxc всё намного проще и удобней, файлы доступны напрямую в отдельном каталоге. Правда, с lxc тоже нужно разбираться, хотя бы с созданием исходного образа, в то время как операции с VM в полностью виртуализованной среде всем знакомы и привычны. >Я имел дело с >контейнерами - но не с вот этими вот квестами, а только CI/CD в котором >всё совсем просто. Есть кого спросить про контейнеры - но на VM это всё не >нужно. Мне своё время жалко, а ресурсы машины на VM - нет. Правильно. -- Eugene Berdnikov
Re: Не запускается sshd в bullseye на виртуальной машине
On Fri, Feb 16, 2024 at 08:35:28AM +0300, Victor Wagner wrote: > В Thu, 15 Feb 2024 23:33:31 +0300 > Eugene Berdnikov пишет: > > > > В свое время пришллось очень сильно потрахаться в ситуациях когда на > > > хосте и в контейнере существенно разные версии systemd (или с одной > > > стороны systemd а с другой sysv init). > > > > Это другой вопрос. Речь шла о том, что для тестирования PG в плане > > запуска и работы с сетью нет причин требовать полной виртуализации. > > > > Есть причины. Как только речь заходит о системах мандатного доступа, > нужна поддержка на уровне ядра. > > А эти системы бывают разные. Ну вот откуда в дебиановском ядре > поддержка астровского parsec. > > Ну и про тесты использущие специфическую FUSE-файловую систему я уже > упоминал. Это тоже связано с защитой данных - мы так проверяем что > удаленные данные действительно исчезли с диска. > (а уж как тестируется зачистка удаленных данных из RAM, это вообще > песня) Ну и при чём тут инициализация и сеть в постгресе? Не при чём, поскольку виртуализации требует нечто, к постгресу прямо не относящееся. Не обманывайте подписчиков рассылки! > > > А если у тебя GUI и нужно тестировать с X Window, Wayland и что там > > > еще нынче бывает? > > > > Теоретически X Window, Wayland & Ко должны уметь работать по tcp и > > проксироваться через unix-сокеты, например, через ssh. Практически же > > я неоднократно наблюдал с этим проблемы у Firefox и Libreoffice. > > Но я думаю, что там что-то ломали в либах... Времени и желания > > Вот вот. В теории нет различий между теорией и практикой. а на практике > ого-го какие различия. На практике нужно вычёсывать подобные баги, после чего можно продолжать тестирование гуя в контейнере. -- Eugene Berdnikov
Re: Не запускается sshd в bullseye на виртуальной машине
On Thu, Feb 15, 2024 at 10:50:22PM +0300, Victor Wagner wrote: > В Thu, 15 Feb 2024 21:39:42 +0300 > Eugene Berdnikov пишет: > > > В контейнерах есть и свой init/systemd, и отдельный namespace для > > сети, позволяющий тестировать сетевые приложения. В этом смысле что > > docker, что lxc -- пригодные для этого среды, а постгресс в плане > > сети и инита ничего странного требовать не должен. > > В свое время пришллось очень сильно потрахаться в ситуациях когда на > хосте и в контейнере существенно разные версии systemd (или с одной > стороны systemd а с другой sysv init). Это другой вопрос. Речь шла о том, что для тестирования PG в плане запуска и работы с сетью нет причин требовать полной виртуализации. > А если у тебя GUI и нужно тестировать с X Window, Wayland и что там еще > нынче бывает? Теоретически X Window, Wayland & Ко должны уметь работать по tcp и проксироваться через unix-сокеты, например, через ssh. Практически же я неоднократно наблюдал с этим проблемы у Firefox и Libreoffice. Но я думаю, что там что-то ломали в либах... Времени и желания разбираться не было, другие приложения работали нормально. Так что GUI вполне можно отлаживать в контейнерах, если не хотеть экзотики, вроде прямой работы с видеокартой, аппаратного ускорения и т.п. -- Eugene Berdnikov
Re: Не запускается sshd в bullseye на виртуальной машине
On Thu, Feb 15, 2024 at 09:17:40PM +0300, Victor Wagner wrote: > В Thu, 15 Feb 2024 13:47:48 +0300 > Dmitrii Kashin пишет: > > > > On 14 Feb 2024, at 22:33, Misha Ramendik wrote: > > > > > > Всем привет! > > > Мне нужно собрать пакет для bullseye. У меня Федора. > > > Ну, поднял VM <...> Хочу поднять sshd и работать с VM по ssh. > > > > Действительно ли Вы этого хотите? > > Если стоит задача собрать пакет, так просто возьмите контейнер с > > bullseye. Уж какой-нибудь docker, полагаю, на федоре найдётся. > > А протестирвать? Мы, например, на архитектуре x86_64 тестируем постгрес > исключительно в виртуалках. Потому как сетевой сервис, взаимодействует > с инитом и все такое. Тестировать лучше в системе имеющей полноценный > init/systemd и отдельный от хоста сетевой стек. В контейнерах есть и свой init/systemd, и отдельный namespace для сети, позволяющий тестировать сетевые приложения. В этом смысле что docker, что lxc -- пригодные для этого среды, а постгресс в плане сети и инита ничего странного требовать не должен. Ситуации, в которых контейнер не даёт делать полноценное тестирование, встречаются нечасто. Например, с lvm в контейнере есть проблемы. -- Eugene Berdnikov
Re: [S] Re: devuan
On Fri, Sep 29, 2023 at 09:57:29PM +0400, Maksim Dmitrichenko wrote: >Очередь есть только у RT-сигналов. > >> В манах эта модель поведения называется "BSD semantics". >> Модель без накопления называется "SysV semantics". >> Можно выбрать алгоритм для конкретного сигнала. > >ЕМНИП, это касается другого - когда система считает, что сигнал обработан >и можно вызывать хендлер опять. Перечитал ещё раз man и да, признаю свою ошибку. Согласен. -- Eugene Berdnikov
Re: devuan
On Fri, Sep 29, 2023 at 12:44:46PM +0400, Maksim Dmitrichenko wrote: > Сигналы не накапливаются в очередь. Мне казалось, что вполне себе накапливаются, при SA_RESTART. В манах эта модель поведения называется "BSD semantics". Модель без накопления называется "SysV semantics". Можно выбрать алгоритм для конкретного сигнала. А для совершенно отмороженных экстремалов, желающих получать сигналы даже в сигхэндлере, есть SA_NODEFER, рекомендую. :) -- Eugene Berdnikov
Re: devuan
On Fri, Sep 29, 2023 at 12:53:28PM +0400, Maksim Dmitrichenko wrote: >пт, 29 сент. 2023 г. в 12:37, Eugene Berdnikov <[1]b...@protva.ru>: > >> Потому как любое >> действие, затрагивающее libc, грозит разносом стэка, и вообще во время >> обработки сигнала сплошь минные поля. А когда из сигхэндлера вернулся, >> нужно как-то мониторить тот факт, что тебе пришёл сигнал, т.е. рядом >> с poll/select будет ещё вычитывание той переменной, с флагом. > >Это тоже не совсем так. Во-первых, man 7 signal-safety содержит список >async signal safe функций, которые можно дергать из обработчика сигнала. Ну так наличие схемы раскладки мин не отменяет сам факт наличия минного поля, а также риска подорваться на нём. Прозевать мину тут легче лёгкого. >Во-вторых, трюк с глобальным флагом - он так себе, обычно либо в пайп >писали из обработчика сигнала, который ждали на том самом select'е (и Запись в пайп это сисколл, а потому очень долго и неэффективно. Повторю: сигналы хороши там, где нужна быстрая реакция, в самые горячих точках кода. Если это не нужно, то poll/select намного проще. Тут мы расходимся во взглядах с А.Мельниковым. -- Eugene Berdnikov
Re: devuan
On Thu, Sep 28, 2023 at 11:30:47PM +0300, Andrey Jr. Melnikov wrote: > Max Nikulin wrote: > > Послать-то сигнал может и просто, а вот правильно поймать уже некоторое > > искусство. Чинить обработчики сигналов - трудоемкий процесс. За это я > > сигналы не люблю. > Вот и не надо перекладывать свои "люблю-нелюблю" на всех. Сигналы - > хорошее, правильное асинхронное средство донести до процесса необходимую > информацию. Информация там очень скудна, по сути исчерпывается списком сигналов (с некоторыми вольностями в трактовке, включая USR1/USR2). > > С сокетами проще. Если есть утилита и библиотека, которые могут слать > > нужные сообщения, и процесс их может правильно обработать, то это лучше, > > чем сигналы. Мне такой вариант нравится больше. > Проще? Создать сокет, открыть сокет, крутить select() в цикле, обрабатывать > ошибки, прочитать сокет (если прочитается), закрыть сокет.. и это все вместо > одного signal handler? Ой, не надо сказки про "один signal handler"... Он один, когда нужно застрелицца. Да и то если твоя прога ничего полезного не делает, так что может просто не обрабатывать этот сигнал. А во всех нетривиальных случаях хэндлер может лишь поставить флаг в переменной, описанной как sig_atomic_c (static volatile ...) и вернуться через sigreturn(). Потому как любое действие, затрагивающее libc, грозит разносом стэка, и вообще во время обработки сигнала сплошь минные поля. А когда из сигхэндлера вернулся, нужно как-то мониторить тот факт, что тебе пришёл сигнал, т.е. рядом с poll/select будет ещё вычитывание той переменной, с флагом. Когда же она вычитана и мы знаем, что сигнал получен, встанет отдельный квест, как эту переменную безопасно вычистить, чтобы не потерять повторный сигнал, который может придти именно в момент очистки. Такое вполне может быть, если это не SIGTERM, который обычно одиночный и повторение которого ничего не меняет. По сравнению с этим добавление в poll/select одного сокета, на котором принимаются команды управления, это просто детская задачка. Сигналы хороши тем, что на вычитывание своего флага не нужен дорогущий сискол. Поэтому мониторингом сигналов можно нашпиговать самые горячие участки кода. Но и цена грамотного программирования здесь очень высока. Особенно если программа многопоточная. -- Eugene Berdnikov
Re: devuan
On Thu, Sep 28, 2023 at 11:52:49PM +0300, Andrey Jr. Melnikov wrote:
> > и он перед экзитом выполняет такой код:
>
> > [pid 848] --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1428154,
> > si_uid=0} ---
> > [pid 848] gettid()= 848
> > [pid 848] getpid()= 848
> > ...
> > [pid 848] kill(848, SIGTTOU) = 0
> > [pid 848] --- SIGTTOU {si_signo=SIGTTOU, si_code=SI_USER, si_pid=848,
> > si_uid=0} ---
> > [pid 848] sigreturn({mask=[]})= 0
> > [pid 848] send(1, "<46>Sep 28 16:37:26 rsyslogd: [origin
> > software=\"rsyslogd\" swVersion=\"8.2308.0\" x-pid=\"848\"
> > x-info=\"https://www.rsyslog.com\;] exiting on signal 15.", 146,
> > MSG_NOSIGNAL) = -1 ECONNREFUSED (В соединении отказано)
> > [pid 848] close(1)= 0
> > [pid 848] socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 1
> > [pid 848] connect(1, {sa_family=AF_UNIX, sun_path="/dev/log"}, 110) = -1
> > ENOENT (Нет такого файла или каталога)
> > [pid 848] close(1)= 0
>
> Это стандартный кусок записи внутреннего сообщения в лог.
Чаааво? Какой лог? На fd=1 висит сокет, а не файл, и потому там send(2).
> Ничего интересного
> тут нет. Самое интересное - почему сдох слушатель, но этого в трейсе у тебя
> нет.
Трейс там длинный, и чудесами типа вызова exit(2) из дочернего треда,
и где там должен быть слушатель вообще непонятно (ведь коннектился он
к этому сокету не тогда, когда я запустил strace, а несколькими часами
раньше).
> > Возможно, этот сокет с fd=1 используется для взаимодействия со своими же
> Это явно результат вызова openlog() где-то внутри syslog().
Я догадываюсь, но syslogd, вызывающий openlog(), это форменная шиза...
Ты не считаешь, что автора такого изделия нужно везти в психушку? :)
--
Eugene Berdnikov
Re: devuan
On Thu, Sep 28, 2023 at 05:32:35PM +0700, Max Nikulin wrote:
> On 26/09/2023 21:43, Eugene Berdnikov wrote:
> > On Tue, Sep 12, 2023 at 10:55:46PM +0300, Eugene Berdnikov wrote:
> > Но не тут-то было: сегодня 4 раза подряд rsyslogd не запустился... :)
> > На том же хосте, где 2 недели назад проверялся orphan-sysvinit-scripts.
>
> А в консоль он что-нибудь пишет, когда не может запуститься?
Нет.
> Останавливается перед этим нормально?
Ммм... не знаю. Он при остановке что-то странное делает.
У него при работе открыт некий сокет на fd=1,
lr-x-- 1 root root 64 сен 28 16:30 0 -> /dev/urandom
lrwx-- 1 root root 64 сен 28 16:30 1 -> 'socket:[34753352]'
...
и он перед экзитом выполняет такой код:
[pid 848] --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1428154,
si_uid=0} ---
[pid 848] gettid()= 848
[pid 848] getpid()= 848
...
[pid 848] kill(848, SIGTTOU) = 0
[pid 848] --- SIGTTOU {si_signo=SIGTTOU, si_code=SI_USER, si_pid=848,
si_uid=0} ---
[pid 848] sigreturn({mask=[]})= 0
[pid 848] send(1, "<46>Sep 28 16:37:26 rsyslogd: [origin
software=\"rsyslogd\" swVersion=\"8.2308.0\" x-pid=\"848\"
x-info=\"https://www.rsyslog.com\;] exiting on signal 15.", 146, MSG_NOSIGNAL)
= -1 ECONNREFUSED (В соединении отказано)
[pid 848] close(1)= 0
[pid 848] socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 1
[pid 848] connect(1, {sa_family=AF_UNIX, sun_path="/dev/log"}, 110) = -1
ENOENT (Нет такого файла или каталога)
[pid 848] close(1)= 0
Возможно, этот сокет с fd=1 используется для взаимодействия со своими же
тредами, но поскольку на send() возвращается ECONNREFUSED, то скорее всего
тред-писатель уже не слушает, и потому в логе сообщения об экзите нет.
Зачем далее открывается ещё один сокет, и делается попытка соединиться
с /dev/log (это самим-то rsyslogd, да ещё по получении SIGTERM!),
я не понимаю. И, честно говоря, совершенно не горю желанием разбираться,
поскольку, повторюсь, страшно подумать, что там внутри...
Хотя может я просто чайник и не способен понять логику из трейса.
Например, зачем самому себе посылать SIGTTOU, причём внутри обработчика
сигнала (поскольку далее идёт sigreturn()).
> > > В чём была проблема -- мне тогда
> > > докопаться не удалось (уже не помню, почему, кажется, под strace эта
> > > зараза всегда успешно работала, а без strace процесс исчезал, не
> > > оставляя
> > > ни корки, ни других следов).
>
> Либо не крэш, либо не может запись core файла подавлена. Как минимум 2 места
> есть: rlimits и sysctl kernel.core*, описано в core(5).
# sysctl -a | fgrep kernel.core
kernel.core_pattern = core
kernel.core_pipe_limit = 0
kernel.core_uses_pid = 0
# ulimit -c
unlimited
# limit coredumpsize
coredumpsizeunlimited
Перезапускаем (/etc/init.d/rsyslog restart) и ура, с первого раза поймали.
# ps -C rsyslogd fww
PID TTY STAT TIME COMMAND
#
# ls -al core
ls: невозможно получить доступ к 'core': Нет такого файла или каталога
# find / -mount -name core
#
А пока я всё это копипастил сюда, запускаемый по крону монитор отловил
факт отсутствия процесса и запустил его:
# ps -C rsyslogd fww
PID TTY STAT TIME COMMAND
1053061 ?Ssl0:00 /usr/sbin/rsyslogd
Кстати, с тех пор как я писал сюда об "успешных" экспериментах по запуску
rsyslogd, тот опять обновился, и нынче его версия 8.2308.0-1, для i386.
--
Eugene Berdnikov
Re: devuan
On Tue, Sep 12, 2023 at 10:55:46PM +0300, Eugene Berdnikov wrote: > On Sun, Sep 10, 2023 at 11:02:39PM +0700, Max Nikulin wrote: [...] > > > Мои попытки сделать в скрипте цикл и на каждой итерации проверять, > > > запустился rsyslogd или нет, не привели к успеху даже в варианте > > > "5 итераций и ожидание 3 секунды после перезапуска" -- всё равно бывали > > > случаи, когда процесс не запускался. Автоподъём по крону эту проблему > > > решает, но нужно понимать, что иногда система живёт без сислога. > > > > А оригинальный init скрипт с этой задачей не справлялся что-ли? Какие-то > > сложности с сетевыми сокетами или что-то другое? > > Вытащил скрипт из свежего orphan-sysvinit-scripts, о котором я не знал. > Там скрипт совсем свеженький, датирован 3 сентября 2023. При сравнении > с моим собственным скриптом (последняя правка от 30-янв-2022) нашлось > лишь одно отличие: у меня start-stop-daemon вызывается с опцией -oknodo, > в остальном скрипты по сути совпадают. И выяснилось, что сейчас оба > успешно перезапускают rsyslogd... :) Но не тут-то было: сегодня 4 раза подряд rsyslogd не запустился... :) На том же хосте, где 2 недели назад проверялся orphan-sysvinit-scripts. > В чём была проблема -- мне тогда > докопаться не удалось (уже не помню, почему, кажется, под strace эта > зараза всегда успешно работала, а без strace процесс исчезал, не оставляя > ни корки, ни других следов). Возможно, багу пофиксили, поскольку ryslog > с тех пор обновлялся, в том числе совсем недавно: > > 2023-08-19 21:42:26 upgrade rsyslog:i386 8.2306.0-2 8.2308.0-1 > -- > Eugene Berdnikov -- Eugene Berdnikov
Re: devuan
On Tue, Sep 19, 2023 at 10:02:00AM +0300, Andrey Jr. Melnikov wrote: > Max Nikulin wrote: > > контейнер выделяется по pidns. У меня, конечно systemd, но pidns же lxc > > вроде создает, так что это влиять не должно. > > Нет, не проблема. Проблема написать баг-репорт и донести его нужность до > маинтайнеров, у которых теперь есть на всё одна отмазка "sysvinit устарел, > под systemd всё работает (C)". Писать лучше патч, с ним багрепорт имеет намного больше шансов на успех. Хотя и это не всегда помогает... -- Eugene Berdnikov
Re: devuan
On Fri, Sep 15, 2023 at 05:03:50PM +0300, Andrey Jr. Melnikov wrote: > Eugene Berdnikov wrote: > > внутри контейнера. Вот у меня контейнеры с дебианами примерно от 2008 года > > (с апдейтами, да), с такими строчками в inittab'e: > > > # What to do when the power fails/returns. > > pf::powerwait:/etc/init.d/powerfail start > > pn::powerfailnow:/etc/init.d/powerfail now > > po::powerokwait:/etc/init.d/powerfail stop > > > причём никаких /etc/init.d/power* нет, а системы нормально гасятся и > > поднимаются. Под systemd. > Так systemd плевать хотел на /etc/initttab. Он им не пользуется. В верхней строчке написано: "дебианы от 2008 года". Ясное дело, там SysV, в контейнере, а не снаружи. Ты бы хоть читал то, на что отвечаешь... > И на SIGPWR тоже, т.к. у Поттеринга на него алергия: Согласен с Поттерингом: да, все варианты проблем с электропитанием в один лишь SIGPWR запихнуть невозможно, потому и сакрального смысла в нём нет. Трахаться с ним или сразу закопать -- решать Поттерингу: он свои силы тратит на движение прогресса, а мы пользуемся результатом. -- Eugene Berdnikov
Re: devuan
On Fri, Sep 15, 2023 at 10:11:34AM +0300, Andrey Jr. Melnikov wrote: > Eugene Berdnikov wrote: > > и в итоге сделал для себя вывод, что проще поставить на хост systemd > > чем 100 раз отжиматься... Под systemd оно сразу и shutdown/reboot нормально > > отрабатывало, и вложенные контейнеры запускало, и ещё чего-то там делало, > > что под SysV лечилось лишь напильником. > Хахаха... Ты нашёл замшелую граблю обильно присыпанную пылью веков. Всё дело > в том, что lxc использует SIGPWR для останова контенйнеров, а в inittab'e от > SysV-init прописано обработчик "pf::powerwait:/etc/init.d/powerfail start" Если такая грабля существовала, это не то, с чем сталкивался я... Насчёт SIGPWR не знаю, скорее всего он используется, но конечный результат зависит и от процесса, управляющего контейнером, и от поведения init'а внутри контейнера. Вот у меня контейнеры с дебианами примерно от 2008 года (с апдейтами, да), с такими строчками в inittab'e: # What to do when the power fails/returns. pf::powerwait:/etc/init.d/powerfail start pn::powerfailnow:/etc/init.d/powerfail now po::powerokwait:/etc/init.d/powerfail stop причём никаких /etc/init.d/power* нет, а системы нормально гасятся и поднимаются. Под systemd. Когда я игрался с подобными контейнерами под SysV, там было примерно такое: по lxc-stop контейнер шустро сворачивается, а потом lxc-stop висит 2-3 минуты, ожидая какого-то ответа из сокета, и выдаёт невразумительное сообщение об ошибке. При этом в контейнере ничего не ломается. И много подобных неудобств и граблей было, всех уже не вспомнить... Если сегодня под SysV инфраструктура lxc нормально живёт, это замечательно, но мне надо было вчера, и для этих задач я для себя выбрал systemd. -- Eugene Berdnikov
Re: devuan
On Thu, Sep 14, 2023 at 02:26:07PM +0300, Andrey Jr. Melnikov wrote: > Eugene Berdnikov wrote: > > У меня везде, где есть контейнеры, стоит система инициализации systemd. > > Потому что lxc, например, под SysV-init не жилец (да, я знаю, что можно > > запускать контейнеры lxc под sysv, но это будет не работа, а бесконечный > > бег по граблям). > У меня везде стоит SysV-init где контейнеры. И ничего - граблей не наблюдаю. > И даже контейненры с systemd внутри - тоже работают, хотя раньше это изделие > не могло там стартануть нормально. Ну так 1. я про то, что было раньше, несколько лет назад, 2. контейнеры они разные бывают. Несколько лет назад я пытался завести lxc-шные, начитался разных wiki на тему "как заставить это работать под SysV", и в итоге сделал для себя вывод, что проще поставить на хост systemd чем 100 раз отжиматься... Под systemd оно сразу и shutdown/reboot нормально отрабатывало, и вложенные контейнеры запускало, и ещё чего-то там делало, что под SysV лечилось лишь напильником. Тенденция такова, что как только отстал от мейстрима, так проблемы растут, отнимая всё больше времени и сил... Вон, формально для i686 до сих пор собирают mplayer и chrome. Однако на тех процах, которые были во времена мейнстрима i686, как правило, не было SSSE3, которые эти изделия хотят. И ведь можно было бы обойтись, просто работать медленнее, но нет, кодерам неинтересна поддержка "убогих" процов, им проще тупо вернуть статус-код. Ну а если у меня современный проц, зачем мне гонять на нём 32-битную базовую систему? Я 64 заведу, а всякие ископаемые конфигурации, которые слишком дорого переделывать, загоню в 32-битные виртуалки/контейнеры. И так оно везде, к сожалению. В том числе в виртуализации, всех видов. > Вопрос не во вложенности, а имеено в том, что на физическом хосте > start-stop-daemon путается в запущенном. Следи за руками: Да это понятно. Я про то, что в контейнере start-stop-daemon не путается, если там других (вложенных) контейнеров нет. Потому как в контейнере ему лишь свои и дочерние процессы видны. Поэтому под systemd контейнер с инициализаций SysV нормально живёт. -- Eugene Berdnikov
Re: devuan
On Thu, Sep 14, 2023 at 12:21:03PM +0300, Andrey Jr. Melnikov wrote: > А у тебя случаем контейнеров на машинке не крутится? А то смотри, > start-stop-daemon у нас тупенький, он про отдельные неймспесы ничего не > знает. Поэтому, когда у тебя запущенно несколько экземпляров чего либо в > различных контейнерах - start-stop-daemon на host-машине ведет себя весма > оригинально - то сигнал не в тот процесс пришлёт, то узрит живущий демон в > контенйнере и откажется запускать его-же на хосте. Из-за этого, приходтся > весь пакадж с dpkg пересобирать. Хотя, надо наверное сделать отдельный и > через dpkg-divert подсовывать нужный start-stop-daemon. У меня везде, где есть контейнеры, стоит система инициализации systemd. Потому что lxc, например, под SysV-init не жилец (да, я знаю, что можно запускать контейнеры lxc под sysv, но это будет не работа, а бесконечный бег по граблям). Но я писал про сислоги в контексте физических машин и контейнеров без вложенности, где start-stop-daemon ошибиться не может. -- Eugene Berdnikov
Re: devuan
On Sun, Sep 10, 2023 at 11:02:39PM +0700, Max Nikulin wrote: > Andrey Jr. Melnikov уже написал, что скрипт положили, но в пакет > orphan-sysvinit-scripts. Правда туда положили и > /usr/lib/rsyslog/rsyslog-rotate. [...] > > Но там не написано, что выполнить задачу скрипта /etc/init.d/rsyslog > > не очень просто, потому что rsyslogd при рестарте запускается через раз. > > Мои попытки сделать в скрипте цикл и на каждой итерации проверять, > > запустился rsyslogd или нет, не привели к успеху даже в варианте > > "5 итераций и ожидание 3 секунды после перезапуска" -- всё равно бывали > > случаи, когда процесс не запускался. Автоподъём по крону эту проблему > > решает, но нужно понимать, что иногда система живёт без сислога. > > А оригинальный init скрипт с этой задачей не справлялся что-ли? Какие-то > сложности с сетевыми сокетами или что-то другое? Вытащил скрипт из свежего orphan-sysvinit-scripts, о котором я не знал. Там скрипт совсем свеженький, датирован 3 сентября 2023. При сравнении с моим собственным скриптом (последняя правка от 30-янв-2022) нашлось лишь одно отличие: у меня start-stop-daemon вызывается с опцией -oknodo, в остальном скрипты по сути совпадают. И выяснилось, что сейчас оба успешно перезапускают rsyslogd... :) В чём была проблема -- мне тогда докопаться не удалось (уже не помню, почему, кажется, под strace эта зараза всегда успешно работала, а без strace процесс исчезал, не оставляя ни корки, ни других следов). Возможно, багу пофиксили, поскольку ryslog с тех пор обновлялся, в том числе совсем недавно: 2023-08-19 21:42:26 upgrade rsyslog:i386 8.2306.0-2 8.2308.0-1 -- Eugene Berdnikov
Re: devuan
On Tue, Sep 12, 2023 at 05:40:36PM +0700, Andrey Lu wrote: > 07.09.2023 15:09, Eugene Berdnikov пишет: [...] > > что называется, понесло... А раньше syslog-ng иногда подвисал из-за > > какой-то баги. При этом он переставал принимать пакеты, и подвисала > > практически вся система, ибо в юниксах код syslog(3) традиционно > > блокирующийся, и в линуксе GNU libc, там так же. Я даже собрал все > > материалы для багрепорта, но времени оформить его не хватило, пришлось [...] > Можно поподробнее про syslog-ng ? используем syslog-ng на большом количестве > серверов со стретча до булзая, в разных позах - никаких проблем не замечали Нашёл файлики от июля 2019, созданные когда я готовил багрепорт. В них видно, что syslog-ng стопорится на операции записи send(32, "<39>Jul 20 07:49:29 syslog-ng: DIGEST-MD5 common mech free", 58, MSG_NOSIGNAL a lsof в этот замечательный момент показывает COMMAND PID TID TASKCMD USER FD TYPE DEVICE SIZE/OFF NODE NAME syslog-ng 18274root 32u unix 0xc94137a7 0t05922798 type=DGRAM Т.е. syslog-ng пытается писать в сокет, клонированный accept()ом от /dev/log. Но с обратной стороны никто не собирается читать, там сидит чукча-писатель с syslog(3). А поскольку send() с MSG_NOSIGNAL, и, ясный пень, без таймера, то наступает капец. Ни по ssh зайти на эту машину, ни с консоли, поскольку и sshd, и getty->login вызывают синхронный syslog(3), на котором точно так же виснут. Бага проявлялась редко, но на физических хостах она отличалась особой неприятностью. И неуловимостью. А в контейнере поймалась на ура. Возможно, это уже починили, всё-таки 4 года прошло. -- Eugene Berdnikov
Re: devuan
On Sat, Sep 09, 2023 at 09:41:36AM +0700, Max Nikulin wrote: > А по поводу rsyslog-rotate, можно проверить, что патч > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031399#24 накладывается и > корректно работает, а потом вежливо, [...] Этот патч требует /etc/init.d/rsyslog, что, собственно, в комментарии к нему и написано. А скрипт этот в дистрибутив не положили. Но там не написано, что выполнить задачу скрипта /etc/init.d/rsyslog не очень просто, потому что rsyslogd при рестарте запускается через раз. Мои попытки сделать в скрипте цикл и на каждой итерации проверять, запустился rsyslogd или нет, не привели к успеху даже в варианте "5 итераций и ожидание 3 секунды после перезапуска" -- всё равно бывали случаи, когда процесс не запускался. Автоподъём по крону эту проблему решает, но нужно понимать, что иногда система живёт без сислога. -- Eugene Berdnikov
Re: devuan
On Thu, Sep 07, 2023 at 01:38:27AM +0300, sergio wrote: > В букворме сломана поддержка rsyslog в sysv: > > 1. удалён /etc/init.d/rsyslog > 2. /usr/lib/rsyslog/rsyslog-rotate обрезан else про invoke-rc.d: > > if [ -d /run/systemd/system ]; then > systemctl kill -s HUP rsyslog.service > else > invoke-rc.d rsyslog rotate > /dev/null > fi > > Воспринимается это как целенаправленное вредительство и унижение > пользователей sysV. Можно, конечно, и то и то через /etc исправить (на > rsyslog-rotate ссылается /etc/logrotate.d/rsyslog), то есть update оно > переживать будет. А можно и по сторонам посмотреть. Есть у кого чего сказать > про devuan? Не знаю про devuan, скажу про debian, ибо он эхотаг (привет фидошникам). Rsyslog переломан в нескольких местах. При рестарте он запускается 50/50 (как те фашистские гранаты из культового боевика "Брат-2"). Почему так -- не знаю, и копать не хочется: судя по тому, что авторы rsyslog'а изобрели в плане синтаксиса конфигов, в головах у них венигрет... Страшно подумать, какой ужас там в коде, потому и лезть туда не хочется. Systemd его стартует лишь потому, что расчитан на запуск даже таких калек, которые сами с первой попытки подняться не могут. Что там в голове у мантейнеров -- неведомо. Maybe это юные наруралисты, которые SysV-init не видели и не догадываются, что его тоже нужно включить в пакет... А может они в курсе, какое дерьмо мантейнят и просто забили на SysV-init, поскольку заставить это нормально работать не удаётся. Во всяком случае, мне не удалось. Пришлось делать крон-скрипт, который проверяет наличие процесса rsyslogd и при отсутствии пытается запустить. Так оно хоть как-то живёт на старых системах с SysV-init. Единственная известная мне альтернатива rsyslog-у, умеющая делить логи по шаблонам/регуляркам, это syslog-ng. К сожалению, сейчас его автора, что называется, понесло... А раньше syslog-ng иногда подвисал из-за какой-то баги. При этом он переставал принимать пакеты, и подвисала практически вся система, ибо в юниксах код syslog(3) традиционно блокирующийся, и в линуксе GNU libc, там так же. Я даже собрал все материалы для багрепорта, но времени оформить его не хватило, пришлось просто оставить syslog-ng. Альтернатива в виде rsyslog'а хоть с костылями и через пень-колоду, но всё-таки работает и не убивает всю систему. -- Eugene Berdnikov
Re: PPPoE hijacking
On Sat, May 27, 2023 at 09:35:23AM +0300, Maksim Dmitrichenko wrote: >Если посмотреть инструкцию на роутер, то там нет настройки режима >авторизации в PPPoE. Значит он будет цепляться любой. Роутер - довольная >убогая железка с 2 мегабайтами флэша и VxWorks в качестве ОС. Если роутер навязывается при подключении провайдером, то там может быть провайдером же похаченная прошивка, где оставлен один-единственный механизм авторизации. Но может быть и подобная глупость, конечно. -- Eugene Berdnikov
Re: Linux 1 #1 SMP PREEMPT_DYNAMIC Sat Apr 15 12:29:04 MSK 2023 x86_64 GNU/Linux
On Mon, Apr 17, 2023 at 01:25:31PM +0300, Ruslan Langer wrote: >Добрый день! Подскажите, после обновления ядра до версии 6.2.11 при >выводе: > >➜ ~ uname -a > >Linux 1 #1 SMP PREEMPT_DYNAMIC Sat Apr 15 12:29:04 MSK 2023 x86_64 >GNU/Linux Покажите выдачу strace -e uname uname -a which uname ls -ald /bin dpkg -S /bin/uname -- Eugene Berdnikov
Re: PPPoE hijacking
On Thu, Apr 13, 2023 at 08:23:18AM +0300, Victor Wagner wrote: > Если оба события достаточно маловероятны, то может случиться так что > ручное вмешательтсово будет требоваться не раз в сутки, а раз в неделю. Для топикстартера даже первое событие слишком вероятно. А вероятности тут не перемножаются (для пуассоновских потоков алгебра другая). -- Eugene Berdnikov
Re: PPPoE hijacking
On Wed, Apr 12, 2023 at 08:57:54PM +0400, Maksim Dmitrichenko wrote: >ср, 12 апр. 2023 г. в 20:26, Eugene Berdnikov <[1]b...@protva.ru>: > > Непонятно, хочется наделать таких "решений" с перехватом сессий PPPoE > для > всех пользователей целого дома? Если нет, то нахрена это городить когда > есть простое и надёжное решение через туннелирование квартирного > трафика? > Чай завернуть default route в туннель несложно. > >Причем тут весь дом? Как будут решать эту проблему пользователи всего >дома, меня вообще мало колебет. Использовать провайдерский роутер в >качестве "туннеля" в PPPoE я не очень хочу, так как он вообще имеет ещё >ряд дурацких особенностей, главная из которых в том, что он ещё и >подвисает периодически. То есть оно, грубо говоря, не надёжное. А перехват сессии это "надёжное решение"? Не смешите. Вы перехватываете сессию, которую начал "провайдерский роутер", незаменимый по той причине что пароль от PPPoE неизвестен, а крякнуть прошивку нет скилов. Затем "провайдерский роутер" подвисает, а провайдер в очередной раз обрывает соединение (по тыщеодной причине, например, просто из желания ограничить время жизни пользовательских сессий 24 часами). Вот и приплыли, что дальше предлагается делать? -- Eugene Berdnikov
Re: PPPoE hijacking
Привет. On Wed, Apr 12, 2023 at 08:07:09PM +0400, Maksim Dmitrichenko wrote: >Имеется многоквартирный дом, в котором единственный монопольный интернет >провайдер (не в РФ), который ставит в каждую квартиру свой роутер. На >роутере настроен PPPoE, однако доступа в админку нет и провайдер его не >даёт, реквизиты PPPoE не даёт, и узнать их через админку соответственно >нельзя. > >Проблема в следующем: похоже, что сетевой концентратор (судя по MAC - >Mikrotik) не держит нагрузку, то ли ещё что-то - но постоянно вылезают >сбросы при установке новых TCP-соединений. Видимо таблица NAT >переполняется, или ещё что-то. Но если установить, например, wireguard >туннель, то через него всё стабильно работает. Провайдер отказывается >вменяемо реагировать на проблему. Соседи тоже жалуются на такие же >симптомы, поэтому проблему с роутером провайдера исключаю. > >Так как PPPoE сессии не шифрованные, то теоретически можно сделать MITM, >предоставив роутеру провайдера возможность авторизоваться в сети, а дальше >работать со своего роутера через VPN, как бы захватив эту сессию. Да, >криво, да нужно держать оригинальный роутер включенным и он займет один >порт, но другого выхода я не вижу. Если кто-то знает альтернативное >айтишное решение (то есть НЕ сменить провайдера/квартиру/страну), тоже >приветствуется. Непонятно, хочется наделать таких "решений" с перехватом сессий PPPoE для всех пользователей целого дома? Если нет, то нахрена это городить когда есть простое и надёжное решение через туннелирование квартирного трафика? Чай завернуть default route в туннель несложно. -- Eugene Berdnikov
Re: Нужен прокси, но хитрый
On Fri, Mar 24, 2023 at 09:07:00PM +0400, Maksim Dmitrichenko wrote: >чт, 23 мар. 2023 г. в 17:56, Eugene Berdnikov : > > Сквид умеет задавать src_ip исходящих соединений, по заданным в конфиге > критериям. В эти критерии могут входить параметры соединения, > выбираемые > на стороне клиента, конкретно dst_ip и dst_port. Как вместо одного > исходящего от сквида src_ip сделать пул адресов -- задача на дом. > >Я в курсе, как работает сквид. Но мне не нужна конфигурация, когда для >выбранного host:port соединение будет выходить всегда с одной и той же >группы адресов. Задача как раз в том, что первое соединение установить с >одной группы, второе - со второй, а третье - мы вообще не указываем >желаемую группу, и прокся, например, сама решает каким-нить >round-robin'ом, какой src_ip выбрать. Поднимать несколько сквидов - по >одному на каждую группу: тоже так себе вариант Kлиент может для первого соединения использовать одну комбинацию проксевого ip:port, для следующего -- другую, а если хочет предоставить выбор группы проксе, то третью. Вы лишь хотите, чтобы этот выбор был реализован не в параметрах соединения на 4-м уровне модели OSI, а в заголовках запроса, т.е. на более высоком уровне. Не знаю, чем может быть так ограничен выбор (может быть в вашей местности настоящих буйных мало:)), но если хотите именно такой прокси, предложить готовый не могу. -- Eugene Berdnikov
Re: Нужен прокси, но хитрый
On Thu, Mar 23, 2023 at 06:15:12PM +0300, Andrey Jr. Melnikov wrote: > > Сквид умеет задавать src_ip исходящих соединений, по заданным в конфиге > > критериям. В эти критерии могут входить параметры соединения, выбираемые > > на стороне клиента, конкретно dst_ip и dst_port. Как вместо одного > > исходящего от сквида src_ip сделать пул адресов -- задача на дом. > И почему на том-же nginx это будет сделать проще и гибчче - тоже на дом, как > бонусная. Nginx это реверсный прокси, он не умеет CONNECT, который товарищу очень хочется, да ещё со своими кастомными хедерами. Хотя исходная постановка задачи допускает разные толкования и предположения, что там хочется... -- Eugene Berdnikov
Re: Нужен прокси, но хитрый
On Thu, Mar 23, 2023 at 04:20:16PM +0400, Maksim Dmitrichenko wrote: >чт, 23 мар. 2023 г. в 14:01, Eugene Berdnikov <[1]b...@protva.ru>: > Ну, это всё незамысловато строгается через squid+iproute+iptables... > Даёте группе свой выходной src_ip, и через ip rule его на нужный шлюз. > >Таким образом нельзя программно-протокольным образом выбрать группу >адресов, через которую отправится предстоящее соединение. Если я правильно >понял предлагаемую схему. Что значит "программно-протокольным образом"? Сквид умеет задавать src_ip исходящих соединений, по заданным в конфиге критериям. В эти критерии могут входить параметры соединения, выбираемые на стороне клиента, конкретно dst_ip и dst_port. Как вместо одного исходящего от сквида src_ip сделать пул адресов -- задача на дом. -- Eugene Berdnikov
Re: Нужен прокси, но хитрый
On Thu, Mar 23, 2023 at 01:26:04PM +0400, Maksim Dmitrichenko wrote: >Хочется поиметь такой HTTP Proxy сервер, который: >а) будет балансировать соединения из внутренней сети в Интернет по >определенному набору внешних айпишников (к каждому из которых на хосте >прокси имеется, например, VPN-соединение, то есть айпишники не на >интерфейсах хоста, где запущен прокси, а до них ещё один хоп). >б) умеет группировать айпишники по группам (с помощью конфигурации), а >клиент имеет возможность выбрать группу (например в заголовке к методу >CONNECT). Ну, это всё незамысловато строгается через squid+iproute+iptables... Даёте группе свой выходной src_ip, и через ip rule его на нужный шлюз. Вот только установка своих заголовков может быть лишь в палате для буйных, где каждый себе своего клиента строчит и свои заголовки в запрос вставить может. А простые юзеры могут лишь в настройках браузера порт или ip-адрес прокси выбрать (по порту и ip сквид разрулить трафик может). >в) умеет гарантировать, что для отдельного взятого клиента очередной >CONNECT поедет через такой айпи, через который данный клиент ещё не >законнекчен или выдаст ошибку (типа 429). Идентификацию клиента можно >делать авторизацией или каким-то уникальным значением, которое передается, >например, опять же в одном из заголовков к методу CONNECT. Боюсь, для столь удивительной задачи ничего готового не найти. Тем более что статус 4xx по превышению числа коннекций это точно не для людей, даже из палаты для буйных. :) -- Eugene Berdnikov
Re: xfonts-bolkhov-*
On Tue, Feb 14, 2023 at 06:45:07PM -0500, Tim Sattarov wrote: > Ну и как бы в трэкинге[1] показывает почему[2] > > 1) https://tracker.debian.org/pkg/xfonts-bolkhov > 2) > https://tracker.debian.org/news/1290230/xfonts-bolkhov-removed-from-testing/ Спасибо всем ответившим. Про tracker.debian.org не знал, теперь понятно. -- Eugene Berdnikov
xfonts-bolkhov-*
Добрый вечер. Кто-нибудь может пояснить, отчего в testing (bookworm) болховитяновских шрифтов нет, хотя в stable (bullseye) они присутствуют? Например, xfonts-bolkhov-isocyr-75dpi: https://packages.debian.org/search?suite=bullseye=xfonts-bolkhov-isocyr-75dpi https://packages.debian.org/search?suite=bookworm=xfonts-bolkhov-isocyr-75dpi По всем пакетам xfonts-bolkhov-* ситуация такая. В unstable (sid) фонты опять появляются. -- Eugene Berdnikov
Re: Как правильно подписывать пропиетарный драйвер nvidia для secureboot?
On Fri, Feb 03, 2023 at 09:07:59AM +0300, Victor Wagner wrote: > В Thu, 2 Feb 2023 20:35:05 +0300 > Eugene Berdnikov пишет: > > К слову, лучшее средство от ордера на обыск -- бэкап, тщательно > > спрятанный вне дома, плюс запасной комплект вычислительной техники к > > нему, плюс заначка для того, чтобы сразу после обыска докупить ещё > > один запасной комплект. > > Это, кстати, многие не понимают. Что всегда надо рассматривать две > угрозы > 1. Что ваши данные попадут не в те руки > 2. Что ваши руки не дотянутся до ваших данных в тот момент, когда вам > эти данные будут нужны. > > Предложенный тобой способ защищает от второй угрозы. А пользователи > всяких FDE надеются, что применение этих средств защитит их от первой В слове FDE буква E как раз защищает, а вот FD, как верно было замечено, скорее бесит нападающих и толкает их на применение радикальных средств... Всё ценное должно быть зашифровано, включая бэкап, но шифровать всё подряд это глупость, IMHO. -- Eugene Berdnikov
Re: Как правильно подписывать пропиетарный драйвер nvidia для secureboot?
On Thu, Feb 02, 2023 at 06:40:40PM +0300, Victor Wagner wrote: > Поскольку в мою модель угроз входит появление в доме вежливого офицера > ФСБ с ордером на обыск или встреча с не менее вежливым таможенником при > пересечении границы, меры, рассчитанные на противодействие этим > угрозам, спасают и от излишне любопытного нашедшего ноутбук. Второй раз читаю тут про таможенника, и ума не приложу, какое может быть дело таможне до содержимого диска... Биты и байты вроде никакими пошлинами не облагаются, а у таможенника нет ни времени, ни средств изучать их: другие пассажиры в очереди нервничают и матерятся. К слову, лучшее средство от ордера на обыск -- бэкап, тщательно спрятанный вне дома, плюс запасной комплект вычислительной техники к нему, плюс заначка для того, чтобы сразу после обыска докупить ещё один запасной комплект. -- Eugene Berdnikov
Re: ifupdown: dhcp & static ip
On Wed, Jan 11, 2023 at 01:20:14PM +0400, Maksim Dmitrichenko wrote: >ср, 11 янв. 2023 г. в 04:48, sergio <[1]ser...@outerface.net>: > > И если его таки сносит dhclient, то ручной режим точно ничем не поможет. > >Ковырялся с чем-то подобным. Не помню уже в чём там дело было, но помню, >что прибег к написанию простой утилитки, которая вешалась на NETLINK >сокеты и мониторила всё происходящее с сетевым хозяйством. Не знаю запилил >ли кто что-нить подобное с тех пор, но по быстрому нашел только статью на >хабре https://habr.com/ru/post/121254/ ip monitor help Запилено хрен знает сколько лет как. -- Eugene Berdnikov
Re: ifupdown: dhcp & static ip
On Wed, Jan 11, 2023 at 04:46:02AM +0400, sergio wrote: > On 10/01/2023 18:24, Eugene Berdnikov wrote: > > > Правильно "inet manual" и в up/down скриптах установку/снятие статического > > адреса и запуск dhcp-клиента. > > Чёт я не очень в это верю. Во-первых, если я не ошибаюсь, так было сделано > раньше, и адрес всё равно слетал. Во-вторых, слетает он не понятно при каких > обстоятельствах, чем "ручное" конфигурирование поможет? Интырфейс на хосте > никто не дёргает, хост не ребутается, адрес слетает довольно редко. Верующий? Тогда на всё воля божья, а пути господни, эх, неисповедимы... Tолько еретики читают логи и пытаются докопаться до сути вещей. -- Eugene Berdnikov
Re: ifupdown: dhcp & static ip
On Tue, Jan 10, 2023 at 05:26:17PM +0400, sergio wrote: > > Хочу dhcp адрес и статический, на одном и том же интырфейсе. > > Вот так работает, но изредка статический адрес слетает (наверное dhclient > сносит). Так делать не правильно? А как правильно? > > % cat /etc/network/interfaces.d/eno2 > > auto eno2 > > iface eno2 inet dhcp > > iface eno2 inet static > address 1.1.1.1/32 Правильно "inet manual" и в up/down скриптах установку/снятие статического адреса и запуск dhcp-клиента. -- Eugene Berdnikov
Re: Слетел драйвер Radeon, без причины
On Sat, Aug 27, 2022 at 07:08:19PM +0500, Евгений Золотов wrote: > Решение случайно нашлось... > > В /etc/modprobe.d/ обнаружился файлик blacklist-amdgpu.conf следующего > содержания: > blacklist amdgpu > > Просто этот файл удалил и видяха заработала нормально. Аллах знает, > как он тут оказался... Правоверным Аллах дал такие суры: dpkg -S blacklist-amdgpu.conf fgrep -r blacklist-amdgpu.conf /var/lib/dpkg fgrep amdgpu /var/log/dpkg.log Ну и можно посмотреть содержимое пакетов xserver-xorg-video-amdgpu и libdrm-amdgpu1, которые находятся по слову "amdgpu". -- Eugene Berdnikov
Re: События с линком Wireguard
On Tue, Aug 09, 2022 at 12:53:53PM +0300, Maksim Dmitrichenko wrote: >К вопросу об OSPF, BGP и иже с ними. Допустим мы решили задачу >конфигурации и получения базы маршрутов. Если это девайс уровня домашнего >роутера с OpenWRT, он потянет такую большую таблицу маршрутизации? Вопрос насколько большую. Если база под рукой, посчитайте число префиксов. Насколько я помню, у full view сейчас префиксов где-то 800 тысяч, так что рунет с его 3% от населения Земли скорее всего < 40 тысяч маршрутов требует. Это 5-10 мег памяти, у современного домашнего роутера столько найдётся. По cpu нужно смотреть, но думаю что в линуксе просмотр таблиц маршрутизации хорошо оптимизирован и узким местом будет не процессор, а шина. -- Eugene Berdnikov
Re: События с линком Wireguard
On Tue, Aug 09, 2022 at 10:44:42AM +0300, Maksim Dmitrichenko wrote: >вт, 9 авг. 2022 г. в 08:46, Eugene Berdnikov <[1]b...@protva.ru>: > решать > задачу не в плоскости ip, а в плоскости прокси и доменных имён, то > завернуть > домены ru/su/рф/рус и ещё пяток через российский parent очень просто. > >Не приходит в голову сходу как можно заворачивать трафик по DNS, тем паче, Речь шла о том, чтобы юзеров выпускать в мир через прокси. A на прокси, как вариант, прописать проксирование российских доменов через российский parent-прокси, доступный через туннель. Для сквида это директивы вида "dstdomain .ru .su ..." и "cache_peer_access ...", ну и prefer_direct и never_direct по вкусу. Для сквида есть ещё вариант пометить обращения к целевым доменам через tcp_outgoing_address / tcp_outgoing_mark / tcp_outgoing_tos, и далее через ip rules отправлять их в туннель. Но не уверен, что это можно сделать по имени домена -- у сквида есть ограничения на тип acl-ей для таких директив. >Коллега, а как вы думаете - без списка российских сетей модуль geoip как >трудится? Никак. Список очевидно есть. В пожатом виде это 70Кб в некотором >бинарном виде. Можно, конечно, написать тул, который перегоняет это в вид, >понятный OSPF'у. Но тут надо понять, что проще - писать тул или писать >демона, который будет следить за keepalive-статистикой wireguard и дёргать >нужные хуки. Ага, за время пока мы тут дискутируем, можно было пару раз пинговалку написать. А поскольку риалтайм тут не нужен, то всякие bgp и ospf здесь перебор, десяток строчек на шелле решат задачу. -- Eugene Berdnikov
Re: События с линком Wireguard
On Tue, Aug 09, 2022 at 03:16:04AM +0300, Maksim Dmitrichenko wrote:
>Задача: в некоторой сети за рубежом необходимо сделать так, что трафик на
>российские IP заворачивается в туннель, который выныривает на сервере
>внутри России, и чтобы всё это не зависело от настроек хостов в этой сети.
>Для чего? Для того, чтобы не страдал user experience в отношении
>российских сервисов анально отгородившихся от остального мира - это как
>многие государственные сервисы, так и коммерческие (например, Авито).
>Почему не заворачивать весь трафик? Out of scope. Так надо сделать.
>
>Сейчас задача решается следующим способом: между роутером в этой сети и
[ ... неважно]
>
>Проблема: если туннель ложится (причины не обсуждаем сейчас), то
>отваливается весь рунет.
А зачем заворачивать в туннель ВЕСЬ рунет? Заворачивайте то, что нужно
завернуть ("отгородившиеся" сервисы), тогда если туннель отваливается,
то менять правила на ротутере будет незачем. К отвалившимся хостам ведь
напрямую ходить не следует, разве не так?
Вопрос, конечно, как составить список "отгородившихся"... Но если решать
задачу не в плоскости ip, а в плоскости прокси и доменных имён, то завернуть
домены ru/su/рф/рус и ещё пяток через российский parent очень просто.
>То есть, понятно, что можно анонсировать со стороны российского сервера в
>туннель маршруты на весь рунет, но как это сделать с т.з. конфигурации - я
>хз.
Технически это рабочая схема, правда, где взять список российских сетей,
я не знаю.
--
Eugene Berdnikov
Re: События с линком Wireguard
On Sun, Aug 07, 2022 at 11:01:16PM +0300, Andrey Jr. Melnikov wrote: > Eugene Berdnikov wrote: > > > Спецификация GRE не регламентирует поведение инкапсулятора, который > > может мониторить состояние туннеля, либо нет, по своему усмотрению. > > Так что вендоры вольны реализовать над GRE любые модели поведения: > > как голый GRE (stateless), так и l2tp (например) со своими таймерами. > Да оно вообще ничего не регламентирует. Как и прохождение через кривые > провайдерские NAT'ы и прочие перелести современных инетрнетов. В 1994 году об этих современных реалиях можно было лишь гадать... Многие сетевики, насколько я помню, считали что мир пойдёт в сторону технологий source routing, в том же RFC1701 для GRE есть целая пачка заготовок на этот счёт. Но к концу 90х явно стал побеждать привычный нам NAT. Однако явторы GRE не были совсем уж тупы, они также ввели поле "key", которое дало потом возможность делать трекинг коннекций на шлюзе и выходить за NAT. Благодаря этому полю GRE до сих пор полужив. > > Но задача, которая обсуждается здесь, более высокого уровня: что делать, > > если машрут через туннель недоступен. Сам инкапсулятор этого не знает. > > И даже если он мониторит состояния линка и может передать его на уровень > > дивайса (link up/down) или на 3-й уровнь (icmp-unreach и т.п.), варианты > > вида "переключить маршрут" выходят за рамки p2p-туннеля. Для этого нужен > > BGP/OSPF/etc, а GRE тут просто низший уровень, который задачу не решает. > В оригинале автор сомневался, что решение "скриптик с wg show" это не > профессионально и всё такое, а дальше - понеслось. В общем, он правильно сомневается: bgpd или ospfd отслеживают события "link up/down" гораздо надёжнее, чем самопальные скрипты. Хотя бы потому, что между двумя poll-ами вида "wg show" можно пропустить события link down-up, скрипт этого не заметит, а вот ядро маршрутик-то через могнувший дивайс аккуратно удалит. С push-ами через netlink таких пропусков не будет. У quagga с этим всё вроде нормально, про bird не скажу, но думаю что у него аналогично. -- Eugene Berdnikov
Re: События с линком Wireguard
On Sun, Aug 07, 2022 at 05:57:03PM +0300, Andrey Jr. Melnikov wrote: > IL Ka wrote: > > У микротов есть похожая проблема с GRE: определить смерть GRE невозможно, > Не у микротов, а опять-же у "флагмана промышленности" - cisco. Ибо это её > инженегры накостыляли GRE со всеми его проблемами. GRE это протокол, который с точки зрения payload'a является программным аналогом 2-го уровня модели OSI, то есть это уровень изернетовских фреймов. Если посмотреть на номера пейлоадов в исходном RFC1701 (1994 год), там значения совпадают с изернетовскими номерами. А 2-му уровню нет дела до доступности получателя. Его задача -- упаковать пришедший пакет и отправить дальше. Примерно так, наверное, рассуждали авторы GRE. Спецификация GRE не регламентирует поведение инкапсулятора, который может мониторить состояние туннеля, либо нет, по своему усмотрению. Так что вендоры вольны реализовать над GRE любые модели поведения: как голый GRE (stateless), так и l2tp (например) со своими таймерами. Но задача, которая обсуждается здесь, более высокого уровня: что делать, если машрут через туннель недоступен. Сам инкапсулятор этого не знает. И даже если он мониторит состояния линка и может передать его на уровень дивайса (link up/down) или на 3-й уровнь (icmp-unreach и т.п.), варианты вида "переключить маршрут" выходят за рамки p2p-туннеля. Для этого нужен BGP/OSPF/etc, а GRE тут просто низший уровень, который задачу не решает. -- Eugene Berdnikov
Re: Что-то странное произошло с сетью
On Sun, Nov 21, 2021 at 02:45:35PM +0400, Алексей Витальевич Коротков wrote: > На компьютерах у меня в /etc/resolv.conf стоит > nameserver 192.168.1.1 > > А на Кинетике (который 192.168.1.1) серверы DNS такие > 77.88.8.8 > 77.88.8.1 > 77.88.8.88 > 77.88.8.2 > 77.88.8.7 > 77.88.8.3 > 8.8.8.8 > 192.168.8.1 > (именно в таком порядке). > > 192.168.8.1 это адрес модема. В такой толпе серверов неудивительно распостранение глюков и багов, особенно во время пандемии... :) Без дампа трафика гадать тут можно бесконечно, подозревая и косяки Кинетика (в котором может быть зашит dnsmasq прошлого века), и модем, а в качестве безумной фантастики ещё iproute2 и версию ядра. -- Eugene Berdnikov
Re: Что-то странное произошло с сетью
On Sat, Nov 20, 2021 at 11:05:50PM +0400, Алексей Витальевич Коротков wrote: > После убирания отключения IPv6 старые проблемы ушли, но есть новые. > getmail получает почту со второго раза, в перый раз он выдаёт > > operation error (error resolving name pop.gmail.com during connect > ([Errno -2] Name or service not known)) Это явно проблема с DNS. Скорее всего запросы где-то дублируются на разные серверы, и первым отвечает поломанный сервер, возвращая NxDomain (имя не найдено). При повторном запросе тот сервер почему-то не отвечает, и клиенту удаётся дождаться правильного ответа от другого сервера. Почему так может происходить -- есть варианты, не вижу смысла их вдаваться в их обсуждение. Проще и быстрее посмотреть дамп трафика, как было здесь предложено, хотя бы на проблемном хосте. Только я не знаю, где взять dumpcap... а tcpdump в Дебиане точно есть. Запускать его под рутом, примерно так: tcpdump -nlUv -i any -s0 port domain -- Eugene Berdnikov
Re: Что-то странное произошло с сетью
On Sat, Nov 20, 2021 at 01:39:38PM +0400, Алексей Витальевич Коротков wrote:
> Вложил ping.txt от команды
> LANG=en_US.UTF-8 ping -c 1 192.168.1.1 > ping.txt 2>&1
Вот это
capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0
capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0, permitted=0,
+inheritable=0}) = 0
capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0
capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0, permitted=0,
+inheritable=0}) = 0
prctl(PR_SET_KEEPCAPS, 1) = 0
getuid()= 1000
setuid(1000)= 0
prctl(PR_SET_KEEPCAPS, 0) = 0
getuid()= 1000
...
socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP) = -1 EACCES (Permission denied)
socket(AF_INET, SOCK_RAW, IPPROTO_ICMP) = -1 EPERM (Operation not permitted)
совершенно закономерно: видно, что "strace ping ..." запускается не от
рута, а под uid/gid=1000/1000), а в таком случае при запуске под strace
на применяются capabilities, соответственно capget не выдаёт, а capset
не ставят нужную CAP_NET_RAW, в результате не удаётся создать raw socket,
необходимый для пинга -- последний вызов socket() выдаёт EPERM.
Насколько я понимаю, ping без strace исправно работает под этим uid/gid,
хоть и ругается на ipv6.
Интересно, давно ли перезагружался компьютер. :)
И поскольку говорилось о наличии рядом другого компьютера с рабочей
системой, предлагаю сравнить diff-ом выдачу "sysctl -a" с этих компов.
Разумеется, отсекая всё что не относится к сети.
--
Eugene Berdnikov
Re: exim4 - anacron, не работают aliases
On Mon, Oct 04, 2021 at 07:29:41PM +0300, Pavel Gaidai wrote: >У меня стоит rewrite: >*@* s...@domain.kiev.ua Ffrs >все письма возвращаются s...@domain.kiev.ua, а нужно что бы уходили на >s...@ukr.net 1. Здесь нет ответа на заданные вопросы. 2. Этот мусор в конфиге вряд ли имеет отношение к проблеме. >пн, 4 окт. 2021 г. в 19:00, Eugene Berdnikov : > > On Mon, Oct 04, 2021 at 05:42:19PM +0300, Pavel Gaidai wrote: > > Всем привет! > > Anacron шлет письма root-у и прописанные в aliases настройки не > работают. > > Если отсылать письма обычно через mailx aliases работает. > > А в чём отличие "работает" от "не работает", куда письма-то уходят? > И что по этому поводу написано в логе, чем рутовые адреса отличаются? > -- -- Eugene Berdnikov
Re: exim4 - anacron, не работают aliases
On Mon, Oct 04, 2021 at 05:42:19PM +0300, Pavel Gaidai wrote: >Всем привет! >Anacron шлет письма root-у и прописанные в aliases настройки не работают. >Если отсылать письма обычно через mailx aliases работает. А в чём отличие "работает" от "не работает", куда письма-то уходят? И что по этому поводу написано в логе, чем рутовые адреса отличаются? -- Eugene Berdnikov
Re: Ядро 5.14 и драйвер Nvidia
On Fri, Oct 01, 2021 at 12:35:15AM +0300, Andrey Jr. Melnikov wrote: > PS: А как-же ты живешь, на нутбуке то с отключенным hibernate? От розетки до > розетки? А нет розетки - всё, прощай всё запущеное вместе с питанием? Если ненадолго, то в принципе есть suspend, но я бы не смог спать спокойно даже в саспенде если карта nvidia да ещё и драйвер проприетарный. :) -- Eugene Berdnikov
Re: Ядро 5.14 и драйвер Nvidia
On Thu, Sep 30, 2021 at 08:36:40AM +0300, Victor Wagner wrote: > В Thu, 30 Sep 2021 00:36:08 +0300 > "Andrey Jr. Melnikov" пишет: > > > https://wiki.debian.org/SecureBoot, генерировать machine owner key, > > > инсталлировать его в UEFI, и подписывать модули. > > А просто выключить всю эту DRM'щину от M$ нельзя? > > Я б лучше еще "замкнутую программную среду" включил, чтобы подписи > требовали не только ядерные модули, но и юзерспейс-программы и > подгружаемые в них .so. Ноутбук у меня для того, чтобы им пользоваться, > а не для того, чтобы ядро хакать. Поэтому лишний уровень защиты от > модификации кода используемых программ скорее полезен. В этом разделе https://wiki.debian.org/SecureBoot#Secure_Boot_limitations среди утрачиваемых от всей этой паранойи фишек упоминается * Hibernation and resume from hibernation. Это правда? Вам действительно очень нужен такой ноутбук? -- Eugene Berdnikov
Re: не стартуют Иксы
On Sun, Jun 27, 2021 at 04:35:53PM +0300, user user wrote: >далее запустил X -configure и скопировал конфиг xorg.conf в /etc/X11/ >(лог вылета иксов в файле - 2_Xorg.0.log) >ошибка - Number of created screens does not match number of detected >devices. Предлагаю добавить "-logverbose n" к опциям Xorg и поднять n выше тройки. >после запустил nvidia-xconfig >(лог вылета иксов в файле - 3_Xorg.0.log) Конфиг, сделанный nvidia-xconfig, неадекватен тем, что для обеих карт указан драйвер nvidia, тогда как одна из них intel. В остальном этот конфиг вроде повторяет первый. Можно попробовать сначала запустить иксы на одной из карт, а потом уж собирать конфиг для двух. -- Eugene Berdnikov
Re: Диску скоро капут?
On Thu, Jun 17, 2021 at 12:18:58AM +0300, artiom wrote: > Провёл fsck, на диске бэды. > В процессе работы fsck вываливаются ATA ошибки, которые не фиксируются в > логе. > > Капут ли диску? Чтобы сказать, капут ли диску, нужно смотреть состояние диска, а не файловой системы на нём. Потому что ошибки уровня ATA и разрушение fs могут произойти и при рабочем диске, например, при капуте контроллера на материнке и даже окислении контактов на шлейфе. Поэтому в идеале желательно вынуть диск, вставить его в проверенную машину, посмотреть smart (особенно reallocated sectors count) и погонять badblocks. -- Eugene Berdnikov
Re: непривелигерованный контейнер lxc в бустер
On Tue, Feb 09, 2021 at 07:11:19PM +0100, Sergey Spiridonov wrote: > $ lxc-create -n cname -t debian -- -r buster > lxc-create: cname: conf.c: chown_mapped_root: 3250 lxc-usernsexec failed: > Permission denied - Failed to open tt > lxc-create: cname: tools/lxc_create.c: main: 327 Failed to create container > cname А у юзера, выполняющего lxc-create, есть возможность писать в /var/lib/lxc? -- Eugene Berdnikov
Re: 1C предприятие на Debian или Debian based
On Tue, Jan 26, 2021 at 06:10:53PM +0300, Andrey Jr. Melnikov wrote: > Eugene Berdnikov wrote: > > On Mon, Jan 25, 2021 at 05:04:51PM +0300, Andrey Jr. Melnikov wrote: > > > редхат. И под дебиан пакажди по виду получаются сборкой в rpm а потом > > > alien'ом. Так что, про замечательное качество этого мы умолчим. > > > Из факта такой сборки не следует, что оно не работает. У меня сервер над > > постгрессом проработал года два как часики. Но дебиан нужен stable, ага. > > У соседей над Ораклом вполне исправно жужжал, там был центос, AFAIK. > Во-во, клон редхата. Я сказал что оно работало как часики. И мне пофигу как оно было упаковано и на чём запущено. > > Подозреваю, что клиенту 1С без fcntl() никак, поэтому из попсовых файловых > > серверов кандидатом является лишь Samba. Можно протрассировать клиент > > и посмотреть, какие сисколы он выполняет. > Какой нахрен fcntl() и самба? Даже я в курсе - запускать v8 в такой позе > НЕЛЬЗЯ. Ну и я нечто подобное слышал, да. Приходили самые френчайзинги от 1С, им задавался вопрос "пачаму?". Они в ответ несли таа-акую пургу, что даже верховный пресс-секретарь тихо икал бы в сторонке на золотом горшке... Теперь я мечтаю от кого-нибудь услышать ответ на этот вопрос, только по существу -- чем самба как сетевая fs не подходит для 1с? > Даже под винду давно уже виртуалка с v8 на sdd + rdesktop к ней. Други > варианты - череваты и глюковаты (С). Вот интересно было бы узнать конкретные причины таких рекомендаций. Если они вообще кому-то известны. -- Eugene Berdnikov
Re: 1C предприятие на Debian или Debian based
On Mon, Jan 25, 2021 at 05:04:51PM +0300, Andrey Jr. Melnikov wrote: > Maksim Dmitrichenko wrote: > > Почему в списке рассылке Debian? Потому что я рассматриваю Debian в > > качестве использования на рабочих местах и потому что указанный продукт > > распространяется в виде deb-пакетов, и, наверное, ими кто-то пользуется, и > > очень возможно, что читает рассылку. > Если нечто завернуто в газетку - это повод обращаться в редакцию газеты или > сразу на бумаго-целлюлозный комбинат? Здесь ни разу не редакция: мейнтейнеров дебиана в этой рассылке человек пять максимум. И разрабов почти нет. Тут в основном "юзеры" газетки Деб. > Последний раз, когда я видел 1с v8 сервер в виде ящика с линуксом - там был > редхат. И под дебиан пакажди по виду получаются сборкой в rpm а потом > alien'ом. Так что, про замечательное качество этого мы умолчим. Из факта такой сборки не следует, что оно не работает. У меня сервер над постгрессом проработал года два как часики. Но дебиан нужен stable, ага. У соседей над Ораклом вполне исправно жужжал, там был центос, AFAIK. Но это всё не имеет отношения к первоначальному вопросу. Товарищ просто хотел опыт эксплуатации нативного клиента под линукс. И насчёт шаровой fs он спрашивал -- насколько я понимаю, там всё упирается в тип блокировок. Подозреваю, что клиенту 1С без fcntl() никак, поэтому из попсовых файловых серверов кандидатом является лишь Samba. Можно протрассировать клиент и посмотреть, какие сисколы он выполняет. -- Eugene Berdnikov
Re: 1C предприятие на Debian или Debian based
On Sun, Jan 24, 2021 at 08:38:08PM +0300, Maksim Dmitrichenko wrote: >Наверняка кому-то из вас приходилось запускать 1С в линукс? Интересует >вариант бессерверного применения, то есть БД хранится в файле. А под линукс уже появился файловый клиент? Раньше был только браузерный, в виде чудовищного js-апплета. Он к серверу цеплялся, ясное дело. > Речь о >микропредприятии из двух человек, поэтому сервер тут overkill на данной >стадии из-за больших капвложений. Может того, паре бухов вознестись в облака? Подписка на 1С не оверкил? -- Eugene Berdnikov
Re: SMART errors
On Fri, Oct 30, 2020 at 01:50:41AM +0300, Andrey Jr. Melnikov wrote: > artiom wrote: > > [-- text/plain, encoding 8bit, charset: utf-8, 62 lines --] > > > Да, с температурой плохо, но 46 - это нормально. > Это НЕ нормально. Нормально - это 26, ну 36 при постоянном обращении. А 46 - > это уже ж*па. Да ладно, 46 это не очень хорошо и нужно подумать о вентиляции, однако вполне рабочая температура. Вообще, от модели зависит, есть сковородки и есть нормальные по тепловыделению диски. -- Eugene Berdnikov
Re: Что-то с памятью иксов сталось
On Mon, Aug 24, 2020 at 02:34:46AM +0300, Alex Kicelew wrote: > Медленное и печальное опускание всех клиентов с наблюдением за памятью > перед перезапуском иксов тоже ничего не дал. При полном отсутствии > клиентов, кроме window manager-а -- те же 1.5г (после его рестарта без > рестарта иксов -- тоже). После перезапуска иксов -- 89М. > > Учитывая, что я не знал раньше о существовании xrestop -- может быть, > есть еще что-нибудь, о чем я не знаю, и что могло бы помочь локализовать > проблему? Посмотрите хотя бы куда течёт: попробуйте периодически сбрасывать содержимое /proc//maps и сравнивать diff-ом. Я бы ещё напустил strace на x-сервер, чтобы посмотреть, нет ли каких-нибудь "неучтённых" клиентов, которые постоянно коннектятся и запросы какие-то шлют, но при этом память под окна не берут и потому в верхушку xrestop не попадают. Всё это, конечно, лучше делать заходя с другого компа или с консоли, а не в той же иксовой сессии. -- Eugene Berdnikov
Re: Почтовый клиент и gmail
On Thu, Apr 23, 2020 at 12:09:16PM +0100, Stanislav Maslovski wrote: [...] > Что интересно, за всю долгую мою жизнь на mutt+procmail+fetchmail (да > еще и с почтовыми ящиками в формате mbox) почта ни разу не гробилась. Среди тех mbox были ящики под 50 гиг, которые интересуют топикстартера? :) -- Eugene Berdnikov
Re: Discourse
On Mon, Apr 13, 2020 at 05:26:58PM +0300, sergio wrote: > On 13/04/2020 17:05, Eugene Berdnikov wrote: > > > Почтового интерфейса как бы не существует. Почта это транспорт. > > https://www.debian.org/Bugs/server-control > https://www.debian.org/Bugs/server-request > > А что это тогда такое, кроме как не интерфейс? Это CLI для рептилоидов с Энцелада, обитаемого спутника Сатурна. Им по месяцу ждать, пока кляуза до bugs.debian.org долетит, поэтому они пользуются таким вот cli над галактической e-почтой... :) А сама почта это не интерфейс, это транспорт. По почте можно и текст, и дампы дисков пересылать, где никаких команд вообще нет. -- Eugene Berdnikov
Re: Discourse
On Mon, Apr 13, 2020 at 03:49:32PM +0300, sergio wrote: > > PS: лучше бы bugs.debain.org на что-нибудь приличное смигрировали. > > Ооо, то есть вы признаёте, что почтовый интерфейс --- кал (: Почтового интерфейса как бы не существует. Почта это транспорт. А возможности складывать сообщения от разных отправителей в одно место, или раскладывать по разным местам -- во всяких там мессенджерах пока представлены убого или вообще отсутствуют. Такой функционал есть в почтовых клиентах, это реально удобно и реально экономит время. Особенно удобно когда в адресатах много контор типа RIPE, которые присылают мейл раз-два в год. К слову, bugs.debain.org это не то место, где нужно что-то быстро обсуждать. Там чем глубже копаешь, тем быстрее результат. -- Eugene Berdnikov
Re: выравнивание раздела: кому верить, fdisk или parted?
On Sat, Dec 07, 2019 at 03:12:57PM +0300, Victor Wagner wrote: > В Sat, 7 Dec 2019 12:40:23 +0300 > Eugene Berdnikov пишет: > > > > > > By default, Linux follows an optimistic memory allocation > > > > strategy. This means that when malloc() returns non-NULL there is > > > > no guarantee that the memory really is available. In case it > > > > turns out that the system is out of memory, one or more processes > > > > will be killed by the OOM killer. > > > > Мне что-то подсказывает, что выставление лимитов на память для > > процесса и лимитов на количество процессов позволяют свести оптимизм > > к величине, соответствующей объёму физической памяти. > > может проще сказать > > sysctl vm.overcommit_memory=1 В плане убиения оверкоммита да, проще. Но один лишь глобальный лимит позволяет одному раздувшемуся процессу съесть весь ресурс компьютера, не оставив ничего другим процессам. Это типичная аварийная ситуация. В плане гранулярности лучше лимиты на процессы и/или cgroups. Ну и для полноты картины полезно знать, что есть "vm.swappiness". Про него можно сообщить авторам дурацких идей по удалению свопа. -- Eugene Berdnikov
Re: выравнивание раздела: кому верить, fdisk или parted?
On Fri, Dec 06, 2019 at 10:25:04PM +0300, Alexander Galanin wrote: > 06.12.2019 22:03, Eugene Berdnikov пишет: > >> Не всегда сегфолт лучше, чем замедление работы :) > > > > Ну... иногда бывает лучше. :) Потому что даёт право вынуть из ножен > > мечик и помахать по кривым рукам разрабов, которые не проверяют код > > возврата из malloc(). > > Проверяй-не проверяй, всё равно гарантий нет: > > > By default, Linux follows an optimistic memory allocation strategy. This > > means > > that when malloc() returns non-NULL there is no guarantee that the memory > > really is available. In case it turns out that the system is out of memory, > > one or more processes will be killed by the OOM killer. Мне что-то подсказывает, что выставление лимитов на память для процесса и лимитов на количество процессов позволяют свести оптимизм к величине, соответствующей объёму физической памяти. -- Eugene Berdnikov
Re: выравнивание раздела: кому верить, fdisk или parted?
On Fri, Dec 06, 2019 at 05:19:20PM +0300, Artem Chuprina wrote: > yuri.nefe...@gmail.com -> debian-russian@lists.debian.org @ Fri, 6 Dec 2019 > 12:01:42 +0300 (MSK): > > >>> Лучше не напрягать мозг и не делать ни отступов ни таблиц разделов. > >> > >> Своп тоже не делать, чтобы мозг не перегрелся? :) > >> -- > >> Eugene Berdnikov > >> > > Опасно так шутить. > > Вот в планах по оптимизации кластера для обработки данных > > стоит - удалить своп. > > (Кусочек из презентации в приложении.) > > Не всегда сегфолт лучше, чем замедление работы :) Ну... иногда бывает лучше. :) Потому что даёт право вынуть из ножен мечик и помахать по кривым рукам разрабов, которые не проверяют код возврата из malloc(). Правда, если прога чужая и без техподдержки, то поймать автора и применить серп к его яйцам будет проблематично... В принципе, отсутствие свопа -- это не повод для сегфолта. В теории. На практике же выход за пределы RAM приводит к отказам на выделение памяти, а для абсолютного большинства программ это столь же фатально, как сегфолт. Наличие свопа позволяет эту (аварийную по сути) ситуацию перевести в разряд "неэффективной работы". Отказываться от свопа как средства избежать катастрофы -- это глупость примерно того же плана, как предложение удалить спасательные шлюпки с палубы Титаника, потому что идти в океане на вёслах неэффективно. -- Eugene Berdnikov
Re: выравнивание раздела: кому верить, fdisk или parted?
On Fri, Dec 06, 2019 at 08:08:50AM +0300, sergio wrote: > On 06/12/2019 07:16, Sergey Spiridonov wrote: > > > Какой отступ лучше брать? > > Лучше не напрягать мозг и не делать ни отступов ни таблиц разделов. Своп тоже не делать, чтобы мозг не перегрелся? :) -- Eugene Berdnikov
Re: Thinstation 5.6 зависание rdesktop
On Tue, Nov 19, 2019 at 01:31:32PM +0300, Andrey N. Prokofiev wrote: > Небольшой offtop. У меня в сети используются тонкие клиенты HP с > загрузкой образа thinstation. > > Клиенты через rdesktop работают с rdp сервером windows server 2012. > > На одной точке имеется нестабильный канал (mikrotik c 4G модемом). > При кратковременной потере связи rdesktop замирает на последнем > кадре и ничего не происходит, двигается только курсор мыши. Курсор мыши у thinstation, скорее всего, двигается локальным Х-сервером, точно так же, как у обычного линукса. Именно такое поведение и должно наблюдаться при потере связи. > Как я понимаю это "фича" rdesktop. Решаемо ли это как-то? Может есть > у кого опыт по данной проблеме. Заранее спасибо! Офтопик простить можно, но вот приходить с вопросами по сетевой проблеме без дампов трафика с обеих сторон -- это неспортивно. :) -- Eugene Berdnikov
Re: mail dups
On Tue, Nov 05, 2019 at 09:01:06AM +0300, sergio wrote: > Eugene Berdnikov -> EB, sergio -> s > > EB> Ну так выбросьте те копии, которые пришли напрямую, но согласно > EB> заголовкам были направлены ещё и в рассылку. > > s> Странно, мне казалось я видел в этом было противоречие. > > Вспомнил, есть один момент: перед тем как выбросить те копии, необходимо > пройтись по настройкам всех подписок и отключить "Avoid duplicate copies > of messages". Всегда об этом помнить и проверять при новых подписках. Необходимости в этом нет, т.к. проверить наличие такой копии и удалить её можно независимо от того, включено в подписке дублирование или нет. Для проверки достаточно содержимого заголовков To: и Cc:, можно ещё List-Id: посмотреть для надёжности. > Интересно, а если не выбрасывать их а отвечать > "541 already subscribed, dup rejected" > меня побьют? Тому, кто хотел чем-то помочь ответом, несомненно, будет очень полезно получить сообщение, что его адресат -- инвалид умственного труда, который не умеет настроить себе почтовый ящик и свои проблемы перекладывает на других. Несомненно, это поможет вовремя свернуть с ним переписку. -- Eugene Berdnikov
Re: ipv6 use_tempaddr
On Sat, Oct 05, 2019 at 02:29:00PM +, Коротаев Руслан wrote: > /etc/network/interfaces: > > iface dhcp inet dhcp > pre-up /bin/ip link set $IFACE up > post-down /bin/ip link set $IFACE down И зачем здесь скрипты, дублирующие функционал ifupdown? Причём дублирующие неправильно. То, что написано в pre-up, приводит к тому, что скрипты в /etc/network/if-pre-up.d/ выполняются когда интерфейс находится в состоянии "up", а они должны выполняться в состоянии "down", потому каталог и имеет такое название. А то, что написано в post-down вообще бессмысленно, так как выполняется уже ПОСЛЕ того, как интерфейс перешёл в состояние "down". То есть это пустое действие, no-op. -- Eugene Berdnikov
Re: Firefox неправильно восстанавливает запомненную при выходе позицию
On Wed, Oct 02, 2019 at 11:15:24AM +0300, Andrey Jr. Melnikov wrote:
> Victor Wagner wrote:
> > On Tue, 1 Oct 2019 12:48:42 +0300
> > "Andrey Jr. Melnikov" wrote:
>
> > > Victor Wagner wrote:
> > > > On Tue, 1 Oct 2019 11:11:48 +0300
> > > > "Andrey Jr. Melnikov" wrote:
> > >
> > >
> > > > > Дак а кто автору злобный буратино, что он не пользует конструкцию
> > > > >
> > > > > _pacman=$(command -v pacman)
> > > > > if [ -n "${_pacman}" -a ]; ...
> > >
> > > > Ну зачем так сложно?
> > > Затем, что потом сразу можно вызвать ${_pacman} -- ${file} без
> > > повторного поиска по дискам в $PATH - а где там тот pacman лежало.
> > >
> > > > Ведь command -v возвращает ненулевой код если команда не найдена.
> > > > Я ведь с самого начала про то и пишу, что НЕ ИСПОЛЬЗУЙТЕ КОМАНДУ
> > > > test, для того чтобы проверить условие, уже проверенное другое
> > > > командой.
> > >
> > > О, расскажи как мне, как в
> > > if /usr/bin/неведомафигня ; then
> > > обработать вот это:
> > > /usr/bin/неведомафигня: cannot execute binary file: Exec format error
> > А нам оно в данном случае надо?
> Надо. Т.к. я знаю, что /usr/bin/неведомафигня должна сделать или exit(0) или
> exit(1). А в противном случае - надо громко обругаться и упасть прямо тут,
> а не считать, что у нас был вариант exit(1).
Ошибка "exec format error" это ошибка времени выполнения, и она ничем
не лучше и не хуже других аналогичных ошибок (не оказалось либы на месте,
занят сегмент shm, забайнден сокет на нужном порту и т.п.), независимо
от того, возникают они на этапе работы загрузчика или после передачи
управления в программу. Если их хочется все до одной ловить -- пишите
свою запускалку, свой супервизор, или даже целую систему виртуализации.
> > Бывают такие ошибки которые НЕ НАДО обрабатывать. Ежели юзер сумел
> > загнать свою систему в такое состояние, он сам себе злобный Билл Гейтс.
> Да? и флешки не глючат? и с дисков читается всё всегда и так-как-записали?
> пришибло OOM'ом/SIGSEGV или ещё какой невозможной в этой вселенной вещью?
Это не ошибки конфигурации, поэтому обрабатывать их должен не шелл.
Шелл он для того, чтобы утилиту запустить. Возможно, задав предварительно
разные ulimit'ы и переменные окружения. И на этом его функционал
целесообразно ограничить, здесь я с Витусом полностью согласен.
--
Eugene Berdnikov
Re: Firefox неправильно восстанавливает запомненную при выходе позицию
On Mon, Sep 30, 2019 at 11:03:55PM +0200, Artem Chuprina wrote: > > > On 29 September 2019 9:50:02 pm GMT+02:00, "Andrey Jr. Melnikov" > wrote: > >> При этом что в шелле есть логические операции, что в командной строке > >> test есть логические операции и они РАЗНЫЕ. > >Витус, как так ЛОГИЧЕСКИЕ операции могут быть разными? AND и OR - они и в > >африке AND и OR. > > Я, конечно, зануда, но должен заметить, что они у нас ни хрена не > логические. Они вычислительные, Булева алгебра, как и любая другая алгебра, допускает множество различных представлений. В том числе над полем вычетов по модулю 2 (как в C++), и над полем натуральных чисел (как у шеллов: 0=true, остальное false). > и их результат сильно зависит от порядка записи операндов. А это к булевой алгебре отношения не имеет: статус-коды складываются по определённым правилам независимо от того, как они были получены. И да, в Африке эти правила такие же как у нас. -- Eugene Berdnikov
Re: О тонкостях синтаксиса Баша (was: Firefox неправильно восстанавливает запомненную при выходе позицию)
On Sun, Sep 29, 2019 at 08:19:53PM +0300, Dmitry Alexandrov wrote:
> Eugene Berdnikov wrote:
> > On Sun, Sep 29, 2019 at 01:18:01AM +0300, Dmitry Alexandrov wrote:
> >> Eugene Berdnikov wrote:
> >>> Синтаксически символ [ не является alphanumeric, поэтому он является не
> >>> нормальным именем команды, а нелепым исключением.
> >>
> >> Почему? Тут вам не Винда, из запретных для файловых имен символов —
> >> кажется, только нулевой.
> >
> > Потому что символ [ ещё является одним из спецсимволов для file globbing,
>
> Таки нет, сверьтесь с (info "(bash) Pattern Matching"). Особым значением
> наделено то, что внутри _пары_ квадратных скобок внутри одного слова. Так
> что никакого исключения тут предусматривать не надо.
И юзер всё это должен держать в голове? А также то, что [ может быть именем
файла, который баш был бы готов запустить (если бы не одноимённый builtin),
а вот с { и ( это уже не так. Лёгкий вынос мозга... Гораздо легче было бы
считать, что [] {} () это строго парные синтаксические разделители.
Тем более что команда [ ну очень хочет получить последним аргументом ].
Не надо убеждать меня в том, что алгоритм обработки параметров в баше
непротиворечив. Я говорю о том, что контринтуитивен для тех, кто вырос
в нашей сложившейся среде и культуре программирования.
--
Eugene Berdnikov
Re: Firefox неправильно восстанавливает запомненную при выходе позицию
On Sun, Sep 29, 2019 at 07:11:30PM +0300, Victor Wagner wrote: > В Sun, 29 Sep 2019 12:36:12 +0300 > Eugene Berdnikov пишет: > > > On Sun, Sep 29, 2019 at 12:31:13PM +0300, Victor Wagner wrote: > > > Я уж не говорю про остерхутовскую концепцию safe comartments, > > > которая была создана более 20 лет назад и которая намного лучше и > > > совершеннее того, что предлагают современные решения для исполнения > > > недоверенного кода, включая мобильные ОС. > > > > Подробнее об этом можно? > > Вообще Остерхут в прошлом году издал книжку "Phylosophy of Software > Design" > > Но вообще я имел в виду вот эту статью с Usenix 1998 года: > > https://www.usenix.org/legacy/publications/library/proceedings/usenix98/full_papers/levy/levy.pdf Пробежался по нескольким первым страницам -- не заметил ничего принципиально нового. Системные вызовы заменяются прослойками со встроенными фильтрами для контроля доступа, приложения выполняются защищёнными интерпретаторами, типа процессов ОС или контейнеров. Что тут принципиально отличное от современных подходов? -- Eugene Berdnikov
Re: Firefox неправильно восстанавливает запомненную при выходе позицию
On Sun, Sep 29, 2019 at 12:31:13PM +0300, Victor Wagner wrote: > Я уж не говорю про остерхутовскую концепцию safe comartments, которая > была создана более 20 лет назад и которая намного лучше и совершеннее > того, что предлагают современные решения для исполнения недоверенного > кода, включая мобильные ОС. Подробнее об этом можно? -- Eugene Berdnikov
Re: Firefox неправильно восстанавливает запомненную при выходе позицию
On Sun, Sep 29, 2019 at 01:18:01AM +0300, Dmitry Alexandrov wrote: > Eugene Berdnikov wrote: > > On Sat, Sep 28, 2019 at 11:24:18PM +0300, Victor Wagner wrote: > >> buitin, не builtin синтаксически это все равно команда с параметрами. > > > > Синтаксически символ [ не является alphanumeric, поэтому он является не > > нормальным именем команды, а нелепым исключением. > > Почему? Тут вам не Винда, из запретных для файловых имен символов — кажется, > только нулевой. Потому что символ [ ещё является одним из спецсимволов для file globbing, и если написать, например, [a-z] то сначала Баш попытается раскрыть это выражение, подобрав из текущего каталога файлы "a", "b" ... "z", и только если это не удастся, пойдёт искать файл "[a-z]" по каталогам в PATH. Да, в случае одиночного [ глоббинг не случится, потому что такой шаблон синтаксически неправилен, но вместо того, чтобы выдать сообщение об ошибке в шаблоне, классический борновский шелл пойдёт искать бинарий по PATH. Всё это контринтиутивно. Обычный человек, выросший в нашей современной культуре программирования, склонен воспринимать [ ... ] как часть синтаксиса, а не думать постоянно о тонкостях трактовки параметров со множеством неочевидных "волчьих ям" (piffalls). Короче, Bourne shell это тяжкий груз наследственности. > > Перечитал это раз пять, но ниасилил, увы... :) > > Имеется в виду Bash Pitfall № 9 по Вулиджу [0]. > > [0] https://mywiki.wooledge.org/BashPitfalls#if_.5Bgrep_foo_myfile.5D Спасибо. Да, читается как медицинская карта тяжелобольного. -- Eugene Berdnikov
Re: Firefox неправильно восстанавливает запомненную при выходе позицию
On Sat, Sep 28, 2019 at 11:24:18PM +0300, Victor Wagner wrote: > В Sat, 28 Sep 2019 13:41:09 +0300 > "Andrey Jr. Melnikov" пишет: > > > Victor Wagner wrote: > > > On Thu, 26 Sep 2019 16:14:50 +0300 (MSK) > > > yuri.nefe...@gmail.com wrote: > > > > [...] > > > > > Тут мы не на grep экономим, а на test. В смысле на команде > > > "квадратая скобка". После найденного мной бага #931822 мне очень > > > хочется у тех, кто не понимает что такое команда квадратная скобка, > > > в чем ее отличие от > > Нет давно такой комманды (в понимании современных shell'ов). Уже > > давно везде что '[', что 'test' - builtin. > > buitin, не builtin синтаксически это все равно команда с параметрами. Синтаксически символ [ не является alphanumeric, поэтому он является не нормальным именем команды, а нелепым исключением. Причём эта "команда" должна обязательно иметь "последний параметр" ], йопс. > Проблема в том что люди не понимают, что условием в шелловских условных > конструкциях является не какое-то там выражениеп, а именно > последовательность шелловских команд, формирующая некий код завершения. Перечитал это раз пять, но ниасилил, увы... :) -- Eugene Berdnikov
Re: Соотнесение процесса и поля QoS
On Mon, Sep 23, 2019 at 02:09:57PM +0100, Stanislav Maslovski wrote: > On Mon, Sep 23, 2019 at 10:53:56AM +0300, Eugene Berdnikov wrote: > > Есть ещё sudo. Да, бутерброд выходит, но ничего самому писать на Си > > не нужно, только скрестить правильно базовые программы. Unix-way. > > ИМХО, благодаря наличию компилятора в штатной системе, да ещё с полным > комплектом системной документации, написание своих утилит под свои же > потребности - это тоже true Unix-way ;-) Скорее махоDOSизм. :) В системе есть ещё штатный ассемблер, кстати. -- Eugene Berdnikov
Re: Соотнесение процесса и поля QoS
On Sun, Sep 22, 2019 at 04:11:55PM +0100, Stanislav Maslovski wrote: > On Sun, Sep 22, 2019 at 01:47:13PM +0300, Eugene Berdnikov wrote: > > В пакете util-linux есть setpriv(1). > > Это полезная утилита, но она требует прав рута для своей работы. А мне > нужно ограничить доступ для приложения, которое запускается обычным > пользователем. Кстати, и автору оригинального поста тоже. > > Можно, конечно, поставить setgid на бинарник setpriv-а (или на копию) на > нужную группу, но это уже выйдет как из (предварительно заглушённой) > пушки по воробьям стрелять. Есть ещё sudo. Да, бутерброд выходит, но ничего самому писать на Си не нужно, только скрестить правильно базовые программы. Unix-way. -- Eugene Berdnikov
Re: Соотнесение процесса и поля QoS
On Sat, Sep 21, 2019 at 10:37:15PM +0100, Stanislav Maslovski wrote: > On Sun, Sep 15, 2019 at 12:12:10PM +0300, Pavel Volkov wrote: > > Я налуркал, что в iptables есть таблица owner, где можно матчить по UID, > > GID, PID. > > Я использую nftables, там есть матчинг по UID, GID. > > Может быть при запуске этих процессов как-то менять им GID? > > У меня для аналогичного эффекта (ограничение доступа к сети для некой > проприетарщины) много лет используется вот такой простенький setgid > wrapper в комбинации c owner GID match в OUTPUT chain: > ... В пакете util-linux есть setpriv(1). -- Eugene Berdnikov
Re: Debian stable и браузеры
On Sat, Aug 24, 2019 at 04:43:43AM +0100, Mikhail Ramendik wrote: > Я ушёл с Дебиана в 2016 году и сюда не писал, но сейчас одной подруге > надо бы водрузтить систему и я смотрю что бы ей такое поставить, чтобы > долго можно было спокойно жить. И напрашивается buster. > > Но тут такое дело - она веб-девелопментом занимается. Ей надо > проверять на апдейченных браузерах. Либо "долго и спокойно", либо апдейты. Если хочется долго и апдейты, то нужно разводить загон с контейнерами, в каждом свою версию браузера. Но про "спокойно" придётся забыть. -- Eugene Berdnikov
Re: Сокрытие факта связи
On Tue, Aug 13, 2019 at 06:44:06PM +0300, Иван Лох wrote: > Допустим вы рассылаете шифротекст по большому количеству адресов. > Следователь полагает, что это Mein Kampf, возбуждается, получает > санкцию приходит к Вам толпа ребят с шлемах ломает Вашу дверь и т. д. > Преступление не завершено, но это как бы не важно. Есть же > статья 30 УК РФ. Сажать можно и за приготовление к совершению. Стороне обвинения придётся убедить суд, что имело место приготовления к преступлению. Когда у кого-то находят гранаты, запалы и прочие боеприпасы, то утверждение о приготовлении будет звучать убедительно. Когда же находят какие-то файлы, и обвиняемый заявляет, что там личная переписка и он имеет конституционное право не показывать её посторонним, обвинению сложнее. Хотя для басманных судов всё это полная фигня. -- Eugene Berdnikov
Re: Сокрытие факта связи (was: Проиграна ли борьба за вычислительную свободу?)
On Tue, Aug 13, 2019 at 02:44:23PM +0300, Иван Лох wrote: > On Tue, Aug 13, 2019 at 01:17:51PM +0300, Dmitry Alexandrov wrote: > > > > А от этого спасает прием, успешно работающий на передовой уже сотню > > лет, — _широковещание_. Не надо устанавливать никакого канала между > > корреспондентами, надо условленным образом сделать сообщение доступным > > для неограниченного круга лиц. И чем большее количество людей его > > получит, тем лучше. > > Проблема в том, что многие типы сообщений адресованные _неограниченному > кругу лиц_ могут по действующему законодательству трактоваться как уголовное > преступление, даже если тоже сообщение адресованное _определенному кругу > лиц_ > совершенно легально. Доступное неограниченному кругу лиц и адресованное неограниченному кругу лиц это разные вещи. Зашифровали адрес с контентом (публичным ключом получателя, например) и вуаля: доступно всем, но кому адресовано никто кроме получателя не знает. Законодательно же можно запретить что угодно, и читать законы как угодно, мол, "все звери равны, но некоторые более равны чем другие", отчего право на тайну переписки вроде как формально будет, а пользоваться им будет запрещено. :) Но вся эта правовая софистика к техническим аспектам отношения не имеет. -- Eugene Berdnikov
Re: Проиграна ли борьба за вычислительную свободу?
On Sat, Aug 10, 2019 at 09:26:54AM +0300, Victor Wagner wrote: > > > Не может фирма не зависеть от государства. > > > > Может, просто она должна зависеть от другого государства. Ex: > > Телеграмм. > > Вы правда считаете что другое государство более заинтересовано в вашем > благополучии, чем это? Другое государство в данном случае более заинтересовано в сборе налогов с фирмы в его юрисдикции, нежели в подкармливании российских оборотней в погонах, принимающих в России удобные для своего "бизнеса" законы. > Вот посмотрите на жителей Крыма которым взяли и обрезали доступ ко всем > ресурсам в юрисдикции США, от платежных систем до гитхаба. Просто > для того, чтобы наказать то государство, которое теперь с этого Крыма > собирает налоги. Государство этим не накажешь, для него это как слону дробина. :) Санкции они для раскачки ситуации в Крыму, чтобы устроить там майданы и революции. Но жители Крыма нынче своими глазами видят, сколько вкладывается средств в инфраструктуру, как строятся днём и ночью автодороги (да-да, даже ночью, кто не верит может сам слетать и посмотреть), и понимают, что 30 лет их налоги просто куда-то выкачивались, и лишь сейчас ситуация хоть как-то нормализуется. -- Eugene Berdnikov
Re: Проиграна ли борьба за вычислительную свободу?
On Fri, Aug 09, 2019 at 08:13:14PM +0300, artiom wrote: > > > 09.08.2019 11:14, Eugene Berdnikov пишет: > > On Fri, Aug 09, 2019 at 12:43:21AM +0300, artiom wrote: > > > > On Thu, Aug 08, 2019 at 09:47:48AM +0300, artiom wrote: > > > > > > Как ГБ может заставить чужой браузер > > > > > > ПолярнаяЛиса отдать в JS тот фингерпринт, который должен быть у > > > > > > интересного юзеру сайта, а не тот, который в подсунутом > > > > > > чекистами > > > > > > сертификате? > > > > > > > > > > Изначальная посылка была в том, что государство может заставить > > > > > браузер установить их корневой сертификат. > > > > > Не пользователя. > > > > > > > >Наоборот. Государство может что-то заставлять делать своих граждан. > > > >А те, кто пишет браузеры, на этот казахстан кладут, им > > > > законодательные > > > >инициативы в какой-то крошечной дырке мира совершенно неинтересны. > > > > > > > > > > Конечно. Но если это большая дырка, в которой живёт большинство > > > разработчиков браузера, и зарегистрирована компания, разговор другой. > > > Но мой главный посыл не в этом: ни в том, ни в другом случае нельзя решить > > > проблему технически, потому что её причины лежат в другой плоскости. > > > > Можно, и вообще многие нетехнические проблемы вполне себе можно решать > > техническими методами. Для этого и существуют замки, заборы, шифрование... > > Ваш замок вместе с забором вышибет ОМОН, а против шифрования применят > ректальный криптоанализ, если ваша неприкосновенность для этого не > обеспечена законом. Да уж, оочень сильный ответ на вопрос в самой верхней цитате, о том как ГБ заставит чужой браузер отдать в JS не тот фингерпринт, который ГБ нужен. Оказывается... вышибанием дверей и ректальным криптоанализом! Надо полагать, применительно к разработчикам браузеров и сотен тысяч сайтов по всему миру. Вот так просто вылетит из крошечной задницы мира суровый казахский спецназ и покажет всем несогласным на планете кузькину мать... Жуть. :)) > Евгений, вы действительно не понимаете, что против доморощенных "технических > методов", государство выставит десять технических и пять законов, причём за > ваш счёт? Вам действительно платят за троллинг в рассылке и попытки убедить технарей, что они бессильны против государства с его "слугами народа", принимающими один за другим неработающие законы-страшилки? Ну-ну, это забавно. :) -- Eugene Berdnikov
Re: Проиграна ли борьба за вычислительную свободу?
On Fri, Aug 09, 2019 at 10:29:13PM +0300, Victor Wagner wrote: > > > Задача создания защищенного от господслушивания мессенджера > > > действительно имеет техническое решение, но этим решением не может > > > быть коммерческая фирма с централизованными серверами и привязкой к > > > сотовому номеру. > > > > Ну почему же? От госпрослушивания -- очень даже может, если эта фирма > > не зависит от государства. Централизация серверов и привязка к номеру > > Не может фирма не зависеть от государства. Может, просто она должна зависеть от другого государства. Ex: Телеграмм. > > никак не мешают защите канала передачи данных. Не путать с защитой > > данных на конечных узлах, это другая задача. > > Защита канала данных не спасает от анализа метаинформации. Информация > о том, что абонент с номером таким-то передал сттолько-то байт абоненту > с номером таким-то и в ответ получил столько-то байт - все равно > останется в логах сервера и будет доступна государству.ю Да пожалуйста! Законопослушного человека мало волнует то, что государство знает, с кем он разговаривал. Это для преступников выявление связей смерти подобно. И обычным людям хочется защиты их личной жизни вообще и переписки в частности, бандитам же наплевать что переписка читается, они шифруются и применяют эзопов язык. Поэтому прослушка выгодна оборотням в погонах, чтобы доить бизнес, но плохо помогает против криминала. Если бы власти действительно хотели бы бороться с криминалом, они бы занимались выявлением связей. А то, что происходит у нас, это по сути такой бизнес силовиков под прикрытием лозунгов о "борьбе с терроризмом". -- Eugene Berdnikov
Re: Проиграна ли борьба за вычислительную свободу?
On Fri, Aug 09, 2019 at 11:45:55AM +0300, Victor Wagner wrote: > Вся эта героическая борьба роскомнадзора с телеграмом выглядит как > "борьба нанайских мальчиков". Выглядит как госкомпозор. Думаю, все понимают, что это выливается в дискредитацию власти, но то ли кому-то это выгодно, то ли действительно наверху среди прикормленных и послушных оставили одних лишь дебилов. > Задача создания защищенного от господслушивания мессенджера > действительно имеет техническое решение, но этим решением не может > быть коммерческая фирма с централизованными серверами и привязкой к > сотовому номеру. Ну почему же? От госпрослушивания -- очень даже может, если эта фирма не зависит от государства. Централизация серверов и привязка к номеру никак не мешают защите канала передачи данных. Не путать с защитой данных на конечных узлах, это другая задача. > Tox может, jami может, даже XMPP-based сеть в какой-то степени может. > Но не telegram и не signal. Вы о чём-то своём поёте, Виктор. Может быть, о наличии единой точки управления у Телеграмма, или наличия персональных данных в одном центре, или контроля над программным кодом и протоколами передачи данных. Можно дискутировать о том, хорошо это или плохо. Да, наличие единого центра контроля имеет и плюсы, и минусы. В случае Телеграмма плюс в том, что он аккумулирует ресурсы на разработку и продвижение сервиса, на создание которого у рядового обывателя нет времени и сил. А вот понимание того, что госпрослушка в 99.99% случаев будет кормить разных оборотней в погонах, и лишь в 0.01% помогать ловить шпионов и террористов, это понимание у обывателя вполне себе присутствует. -- Eugene Berdnikov
Re: Проиграна ли борьба за вычислительную свободу?
On Fri, Aug 09, 2019 at 12:43:21AM +0300, artiom wrote: > > On Thu, Aug 08, 2019 at 09:47:48AM +0300, artiom wrote: > > > >Как ГБ может заставить чужой браузер > > > >ПолярнаяЛиса отдать в JS тот фингерпринт, который должен быть у > > > >интересного юзеру сайта, а не тот, который в подсунутом чекистами > > > >сертификате? > > > > > > Изначальная посылка была в том, что государство может заставить > > > браузер установить их корневой сертификат. > > > Не пользователя. > > > > Наоборот. Государство может что-то заставлять делать своих граждан. > > А те, кто пишет браузеры, на этот казахстан кладут, им законодательные > > инициативы в какой-то крошечной дырке мира совершенно неинтересны. > > > > Конечно. Но если это большая дырка, в которой живёт большинство > разработчиков браузера, и зарегистрирована компания, разговор другой. > Но мой главный посыл не в этом: ни в том, ни в другом случае нельзя решить > проблему технически, потому что её причины лежат в другой плоскости. Можно, и вообще многие нетехнические проблемы вполне себе можно решать техническими методами. Для этого и существуют замки, заборы, шифрование... А последний яркий пример в IT это то как мессенджер Телеграмм вполне себе техническими методами избавил нас от гэбешников, которые хотят легимитизировать своё желание залезать в чью-то личную переписку. И государство ничего сделать не может, только поливает Пашу Дурова и Телеграмм грязью, мол, наркодилеры им пользуются, поэтому он плохой. Точно так же на казахов можно найти действенные технические методы. Вы же на аргументы технического плана всё время повторяете, как мантру, что вопрос решить технически невозможно... Не умеете -- не решайте. :) Только если хотите убедить в чём-то нас, то отвечайте техническими аргументами, иначе это смотрится как попытки промывать нам мозги. -- Eugene Berdnikov
Re: Sudo
On Thu, Aug 08, 2019 at 06:26:04PM +0300, Dmitry Alexandrov wrote: > "S.Kholodny" wrote: > > Как настроить команду так, чтобы весь код скрипта проходил через обычного > > пользователя, и только sudo - от рута? > > Вы хотите вызывать sudo(8) в своей программе? Так не делается, делается > наоброт: программа запускается со всеми ей необходимыми правами, а затем они > прозрачно для запускающего _сбрасываются_ до минимально нужных. Часто бывает нужно в скрипте какие-то действия выполнять под обычным пользователем, а какие-то под рутом, причём всё это, что важно, чередуется. Если же права один раз сбросить, вернуть их обратно уже крайне сложно. Вызовы sudo в таком случае -- самое правильное решение. При таком подходе скрипт может писать любой юзер, не думающий о безопасности, а ограничения (через правила sudo) накладываются на отдельные критичные операции. И что важно, формализует эти ограничения сисадмин, который обычно лучше юзера разбирается в вопросах безопасности. -- Eugene Berdnikov
Re: Проиграна ли борьба за вычислительную свободу?
On Thu, Aug 08, 2019 at 09:47:48AM +0300, artiom wrote: > > Как ГБ может заставить чужой браузер > > ПолярнаяЛиса отдать в JS тот фингерпринт, который должен быть у > > интересного юзеру сайта, а не тот, который в подсунутом чекистами > > сертификате? > > Изначальная посылка была в том, что государство может заставить > браузер установить их корневой сертификат. > Не пользователя. Наоборот. Государство может что-то заставлять делать своих граждан. А те, кто пишет браузеры, на этот казахстан кладут, им законодательные инициативы в какой-то крошечной дырке мира совершенно неинтересны. P.S. Не надо в письмо включать полную копию предыдущего, здесь это считается моветоном. -- Eugene Berdnikov
Re: Проиграна ли борьба за вычислительную свободу?
On Tue, Aug 06, 2019 at 10:17:37AM +0300, artiom wrote: > > Вы не поняли. Если бы в JS была возможность получить атрибуты сертификата, > > то владелец сайта мог бы запрограммировать дополнительные проверки на то, > > что браузер получил именно тот сертификат, который принадлежит его сайту. > >> Теоретически любую такую проверку можно обойти, но практически > государству > > легче будет поломать ключи всех корневых сертификатов брутфорсом, нежели > > бороться с тысячами "вражеских" сайтов, постоянно меняющих код. :) > > > > Да всё я понял. > Не будет государство ничего ломать. > Когда есть рычаг давления, позволяющий внедрить чужой сертификат, > можно обязать браузер возвращать JS коду владельца поля его > сертификата, даже если он подписан "вражеским" и есть госмитм. > Вариантов, как сделать подобное, - множество. > Эта проблема не решается технически. О, как интересно. Расскажите подробнее. Вот браузер ПолярнаяЛиса, который юзер себе поставил с плеймаркета, вот сертификат от ГБ, который ему пришлось поставить, чтобы выйти в интернет (без него чекисты не выпускают), вот код на JS, который читает поля сертификата и проверяет, скажем, фингерпринт. Как ГБ может заставить чужой браузер ПолярнаяЛиса отдать в JS тот фингерпринт, который должен быть у интересного юзеру сайта, а не тот, который в подсунутом чекистами сертификате? > >>>Я пока не вижу иного выхода для > >>> владельца сайта, кроме как выдавать пользователям клиентские > >>> сертификаты и требовать их для доступа к ценным данным. > >> > >>Так уже есть токены. > > > > Токен это хранилище ключа, а клиента в модели x509 удостоверяет сертификат. > > Независимо от того, как клиент хранит свой ключ, в файле или в тукене. > > > > Когда вам отдают токен, вы можете быть уверены, что там ключ именно > того, кто его передаёт (считаем, что механизмы передачи надёжны). Свой ключ ещё надёжнее, потому как не передаётся удостоверяющему центру. А токен, переданный третьей стороной, может быть этой же стороной слит в ГБ по требованию госорганов. Им это намного легче сделать, чем добыть ключ, который никогда не покидал хозяина. -- Eugene Berdnikov
Re: Проиграна ли борьба за вычислительную свободу?
On Sun, Aug 04, 2019 at 09:41:20PM +0300, artiom wrote: > > Интересно это прежде всего как неожиданный поворот для модели > > безопасности, основанной на 509х сертификатах. > > Поскольку API всех популярных браузеров на сегодняшний день > > не позволяют получить в javascript'e информацию о сертификате, > > то владельцу сайта непросто защитить всех своих посетителей от > > опасности местечкового MitM. > > Это естественная проблема всякого централизованного доверительного центра. > И никакая "информация в JS" эту проблему не решит. > Если браузеры выполнят требования о добавлении сертификата, значит имеется > рычаг давления, позволяющий сделать что-угодно, в том числе не возвращать > информацию о "левом" корневом сертификате в JS вызове. Вы не поняли. Если бы в JS была возможность получить атрибуты сертификата, то владелец сайта мог бы запрограммировать дополнительные проверки на то, что браузер получил именно тот сертификат, который принадлежит его сайту. Теоретически любую такую проверку можно обойти, но практически государству легче будет поломать ключи всех корневых сертификатов брутфорсом, нежели бороться с тысячами "вражеских" сайтов, постоянно меняющих код. :) > > Я пока не вижу иного выхода для > > владельца сайта, кроме как выдавать пользователям клиентские > > сертификаты и требовать их для доступа к ценным данным. > > Так уже есть токены. Токен это хранилище ключа, а клиента в модели x509 удостоверяет сертификат. Независимо от того, как клиент хранит свой ключ, в файле или в тукене. > > Кто-нибудь знает более простое решение? > > Ну так известный же вам и всем остальным факт: всякая система основывается > на доверии, и не имея доверенного канала (хотя бы защищённого от MitM) > невозможно гарантированно надёжно обменяться ключами. Нет, всё гораздо сложнее. Есть, например, известный факт, что любое сколь угодно длинное число может быть разложено на простые множители. Вот только времена всех известных алгоритмов для решения этой задачи так быстро растут с длиной числа, что на этом основан метод шифрования RSA. Так что один лишь факт разложимости числа на практике оказывается недостаточен, есть ещё другие факторы, и они ЗНАЧИМЫ. Точно так же наличие MitM недостаточно, чтобы читать любую переписку, оно даёт такую возможность лишь для цензоров на сферических конях в вакууме, то есть в том случае, если другие значимые факторы считать не существующими. :) -- Eugene Berdnikov
Re: Проиграна ли борьба за вычислительную свободу?
On Sat, Aug 03, 2019 at 05:27:07PM +0300, artiom wrote: > > На этом фоне Казахстан со своим государственным MitM смотрится примерно > > так же как его бомбардировочная авиация на фоне американской. > > > > А что там снова властные дегенераты требуют? > Я упустил опять. Требуют поставить в каждый браузер свой корневой сертификат. Чтобы иметь возмость генерить на лету и подписывать его ключом сертификаты для любых сайтов. Включая банковские, да. Всё это исключительно для безопасности юзеров, разумеется. :) Интересно это прежде всего как неожиданный поворот для модели безопасности, основанной на 509х сертификатах. Поскольку API всех популярных браузеров на сегодняшний день не позволяют получить в javascript'e информацию о сертификате, то владельцу сайта непросто защитить всех своих посетителей от опасности местечкового MitM. Я пока не вижу иного выхода для владельца сайта, кроме как выдавать пользователям клиентские сертификаты и требовать их для доступа к ценным данным. Кто-нибудь знает более простое решение? -- Eugene Berdnikov
Re: SD card reader
On Sat, Jul 27, 2019 at 11:19:01PM +0300, Boris wrote: > Вопрос такой. Имеется ноут hp, buster и слот для sd-карт в ноуте. Слот не > работает и не могу понять, дело в аппаратной части, или программной? ... > То же с lshw в разделе usb - ничего явно не указывает на слот. Искал mmc, > blkmmc, sd, card. Может надо на что ещё внимание обратить? Посмотрите в биосе, виден ли чип. Бывает, устройства отключаются или неожиданные параметры для них устанавливаются: всякие hotplug-дивайсы особенно чувствительны к статическому электричеству, плохим контактам и прочему электрическому шуму. -- Eugene Berdnikov
Re: systemd-networkd
On Thu, Jul 25, 2019 at 01:00:18PM +0300, Victor Wagner wrote: > On Thu, 25 Jul 2019 11:58:01 +0300 > Eugene Berdnikov wrote: > > > > доступа к которым с этим китайцем придется судиться. > > > в) оно все нихрена не документировано. > > > > Железка и драйвера нас не интересуют. А вот базовая платформа общая. > > Как не интересует? Нас интересует изменить поведение железки так, чтобы > она делала то, что надо нам. Свобода N1 по Столлману. Прежде всего нас интересовал вопрос, кто победил в "войне за свободу ПО", и было утверждение, что война якобы проиграна. Меня именно это задело, и я утверждаю, что наличие свободной базовой платформы означает, что "война" вовсе не проиграна. Те самые производители железок помогают победить в ней проприетарщину, даже если закрывают код своих драйверов. Потому что платформа общая, а драйверы это частности. > Кстати, в огромном количестве случаев "чтобы она работала как нам надо" > будет "поправить дурацкий глюк в драйвере WiFi" или что-то подобное, > так что без драйверов никак. Даже при наличии исходника драйвера чаще всего без документации на чип править нечего. Причём более чем в половине случаев, я уверен, приходится выправлять поведение чипа, отличного от ожидаемого (в том числе отличное от того, что на самом деле хотели запечь в кремнии создатели). Так что одних лишь исходников может не хватить для получения результата. При этом "дурацкий глюк" лучше править тому, кто драйвер писал и в теме. Но для этого больше нужна не открытость кода (хотя лучше, если код открыт), а нормально выстроенная служба техподдержки. Если она есть и работает, то потребителю проще и быстрее обновить прошивку, чем самому колупаться с компилятором. Последнее для редких мазохистов. > Поэтому об отсутствии подготовки и образования речь не идет. > > Речь идет о том, что гигантские проекты должны быть структурированы > так. чтобы можно было сесть и за полчаса разобраться где что править. > При условии что ты умеешь читать на том языке, на котором оно написано. Да это тоже маниловщина. Открывашь, скажем, кусок, относящийся к изернету в более-менее структурированной линуксовой сети, а там -- бац! Kакие-то skb, локи, rcu и хрен знает что внутри привычного, вроде бы, языка Си... Выдыхашь, снимаешь с полки книжку по теории поля, чтобы понять, что там за хиггса такого на БАКе поймали, о котором трындят по ящику. А там, блин, вакуум, лагранжиан, группы, пропагаторы... Хотя их всех просто складывают да умножают, интегралы какие-то берут. Вроде бы всё в школе учили. :) В обоих случаях нужна ориентация в предметной области, одного образования общего плана оказывается мало. > Вопрос в том, что Столлман в свое время осознавал образовательную > ценность текстов программ. Поттеринги и де Иказы - нет. Они пишут > не для того, чтобы их тексты читали, а чтобы это работало как > магический артефакт, который может модифицировать только его создатель. Да им просто не до документации... Это плохо, но не нужно искать здесь сознательное вредительство. Настоящее вредительство это "документация" от Майкрософт, у которого, наверное, есть целый штат сотрудников, задачей которых является так переделать технический текст, чтобы читающий (даже если у него 20-летний стаж в предметной области) почувствовал себя полным идиотом. -- Eugene Berdnikov
Re: systemd-networkd
On Thu, Jul 25, 2019 at 10:25:46AM +0300, Victor Wagner wrote: > On Thu, 25 Jul 2019 09:47:34 +0300 > Eugene Berdnikov wrote: > > > On Thu, Jul 25, 2019 at 12:54:43AM +0300, Victor Wagner wrote: > > > Здесь все не так. И война за свободу ПО, которую начал Столлман в > > > середине 80-х - проиграна. > > > > Выиграна. Какую коробочку с WiFi или 4G ни возьми с полки, везде > > внутри линукс, а из лога, если он показывается, торчат busybox, > > dnsmasq и прочие ужасы... :) И каждый новый китаец, пришедший на > > рынок со своей новой коробочкой, пихает в неё тот же линукс. Потому > > Проиграна. Попробуйте в этом busybox-е что-нибудь изменить. > Выяснится что > а) не так-то просто выяснить как и чем это вообще можно собрать Нужна некоторая квалификация. Абыдна, да? :) > б) оно требует патчей и проприетарных драйверов, за получение доступа к > которым с этим китайцем придется судиться. > в) оно все нихрена не документировано. Железка и драйвера нас не интересуют. А вот базовая платформа общая. О ней и речь. И о том, что китаец без этой платформы свои железки продать уже не может, т.к. конкуренты вокруг с линуксами и экономически давят. > Более того, формально opensource продукты, такие как мозилла тоже > в общем-то нарушают свободу N1. Потому что дизайн там такой запутанный > что на выяснение того как там что устроено и "change it so it does > computing as you wish" уйдут годы. А за эти годы оно будет три раза > переделано. Поэтому если ты не имеешь возможности тратить на работу над > конкретным продуктом значительную часть своего времени, ты не сможешь > "change it so it does your computing as you wish." Вам Столман не объяснил, в чём разница между свободным и бесплатным? Жаль. Если нет времени разбираться в продукте, заплатите тому, кто сядет и разберётся. Продукт можете ему дать, вместе с зарплатой. Вас никто в этом не ограничит, и будет свободный выбор между "плестись в остающих на 3 года" или "опередить всех", "сделать свой форк" и т.д. А думать, что "свобода" это когда можно без подготовки и образования сесть и сходу поправить что-то в коде гигантского проекта, вроде ядра линукса, так это глупо. Никто ж не удивляется тому, что средняя кухарка не может просто так сесть и посчитать распределение радиационных потерь нейтронов в стенке реактора: ей нужно хотя бы квантовую механику изучить. Хотя книжек по физике на полке и в инете целый ряд, все свободно доступны. А если ещё возмущаться тем, что книжки "слишком сложно написаны", так это просто инфантилизм чистой воды. :) -- Eugene Berdnikov
Re: systemd-networkd
On Thu, Jul 25, 2019 at 12:54:43AM +0300, Victor Wagner wrote: > Здесь все не так. И война за свободу ПО, которую начал Столлман в > середине 80-х - проиграна. Выиграна. Какую коробочку с WiFi или 4G ни возьми с полки, везде внутри линукс, а из лога, если он показывается, торчат busybox, dnsmasq и прочие ужасы... :) И каждый новый китаец, пришедший на рынок со своей новой коробочкой, пихает в неё тот же линукс. Потому что иначе ему на массовый рынок сегодня не выползти. Только не надо говорить, что, мол, настоящие пацаны будут покупать дорогие брендовые железки со своим вылизанным ядром внутри. Мы это уже проходили на примере Digital, Sun, HP и прочих динозавров... Будете делать ставки на Cisco, господа? :) > Но я же говорю - битва за свободу ПО проиграна. Замена Free Software > на Open Source, которая казалась в конце 90-х замечательным тактическим > ходом, позволяющим привлечь на сторону свободы ресурсы копораций, > оказалась троянским конем. Она дала возмодность примазаться де Иказам и > Поттерингам и постепенно захватить всю экосистему. Экосистема живёт и развивается, это главный результат. А кто там "примазался" -- несущественные детали. Нужно смотреть выше, глобально. Поттеринг, между прочим, уже перекачивает в эту экосистему ресурсы IBM. -- Eugene Berdnikov
