Painter

К сожалению, мне не известна история этого файла. Что интересно, размер файла такой же как и у утилиты на http://ftp.lissi.ru/Utils/P12FromGOSTCSP/ Итоговые сертификаты и закрытый ключ всегда можно проверить после сохранения, нет ли там лишних записей и запускать в виртуальной машине без интернета. Или можно купить программу за 2990 (каждый год). Которая меняет несколько байт и сохраняет купленный вами сертификат и закрытый ключ на диск. Кстати вопрос, а можно сразу купить в PEM формате на обычной флешке (или скачать из личного кабинета)? Был у кого-нибудь такой опыт?

Такая ошибка возникает при сохранении сертификата с GOST R... в файл .pfx с помощью стандартного диалога сохранения в Windows. Насколько я понял, для того, чтобы gost engine для openssl мог прочесть этот файл, pfx файл должен быть в определенном формате. Вот тут человек пытается получить содержимое без дополнительных программ: https://vgimly.blogspot.com/2019/03/2.html Работающая с GOST R 34.10-2012 версия P12FromGostCSP (не требует файла лицензии): https://www105.zippyshare.com/v/0cZxZR8r/file.html Взято отсюда: https://ru.stackoverflow.com/questions/910436/pfx-файл-Подпись-документа Так же прикрепил к этому сообщению P12FromGostCSP.exe

Я модифицировал исходный код DHCDROP (довольно просто если есть минимальные знания в C + гугл) чтобы он писал сообщения в syslog, а дальше уже любым удобным способом парсим syslog и делаем что хотим.

Мы тестировали новый роутер с помощью еще одного компьютера. На боевом сервере записали дамп реального трафика с помощью tcpreplay, например 1 минуту. Потом переписали в дампе мак и ip адреса на тестовые с помощью tcprewrite. Потом пуляли этот дамп с тестового компьютера в несколько потоков на тестовый роутер, проводили изменения в конфигурации, смотрели графики, снова проводили изменения т.д. Таким образом можно найти конфигурацию с которой нагрузка при текущем трафике минимальна (лучше распарраллеливается и т.д.). Естественно тестовый компьютер должен быть мощным + хорошая сетевушка.

Тоже понадобилось логиниться на DIR-100 с помощью Net::Telnet. В моем случае проблема была в том, что DIR-100 просит клиента сообщить тип терминала, а Net::Telnet отказывает в этом RCVD DO TERMINAL TYPE SENT WONT TERMINAL TYPE RCVD WILL ECHO SENT DO ECHO RCVD WILL SUPPRESS GO AHEAD SENT DO SUPPRESS GO AHEAD Дальше я нагуглил эту тему - Managing TERM TYPE Option Requests with Net::Telnet и смог подключиться к DIR-100 use Net::Telnet; use Net::Telnet::Options; my %options = ( 'TTYPE' => { 'DO' => sub {} }, 'ECHO' => { 'DO' => sub {} }, 'SUPPRESS-GO-AHEAD' => { 'DO' => sub {} }, ); my $nto = Net::Telnet::Options->new(%options); my $t = new Net::Telnet( Timeout => '4' ); $t->telnetmode(0); $t->open('10.10.10.10'); my $data; recv($t, $data, 1024, 0); $nto->answerTelnetOpts($t, $data); $nto->sendOpt($t, 'SB', 24, 'IS', 'xterm'); recv($t, $data, 1024, 0); $nto->answerTelnetOpts($t, $data); recv($t, $data, 1024, 0); $nto->answerTelnetOpts($t, $data); $t->telnetmode(1); my $content; while (my $line = $t->getline() ) { print $line; } ... ******************************************************************** D-Link DIR-100 Ver 2.01_sw Fri Oct 02 11:01:04 2009 ******************************************************************** ...

Для сильно различающихся по значению величин можно поставить свойство "Logarithmic Scaling (--logarithmic)" в Graph Template. Тогда скачки до 100500 пунктов не повлияют на отображение обычных значений

Если у вас всего 4 интерфейса на 3 хоста, то без разницы как подключать. Проще когда все хосты и хранилище будут в одной подсети. Или я не так понял вопрос. Best practice: каждый хост надо подключать 2мя концами к хранилищу через различные интерфейсы, различные пачкорды и различные коммутаторы. Сетевые карты и SFP модули должны быть различных моделей. Само хранилище так же желательно зарезервировать, так же как и диски и raid контроллеры в нем самом. А на хостах включить multipath. Не забыть разместить хранилища в различных зданиях :)

посмотрите "ethtool --statistics eth0". А задержки в пингах нормальные?

Поидее он должен написать в логи, почему не может создать новый файл. Судя по коду, там все просто (я смотрел в файле server/db.c, функция new_lease_file ()). Можно отследить системные вызовы с помощью strace в момент ротации, может там будет что-то интересное. Или это какая-то особенность работы в failover режиме. Запустите где-нибудь 2 тестовых сервера и подождите время ротации. У меня была проблема, не писались изменения в файл с какого-то момента. Была проблема с хендлом открытого файла, я это обнаружил с помощью lsof | grep leases. Но тут что-то другое.

Временно запускайте freeradius в отладочном режиме c ключом -X из консоли, а не в режиме демона. Будет что-то типа " service freeradius stop", а потом "freeradius -X"

Добавить строчки в файл /etc/iproute2/rt_tables, чтобы задать читаемые имена таблицам маршрутизации ... # Custom Tables 10 UPLINK_1_DEFAULT_GATEWAY 20 UPLINK_2_DEFAULT_GATEWAY ... # Input interface ip addr add 192.168.1.1/30 dev eth0 ip link set eth0 up # Uplink 1 interface ip addr add 10.10.10.1/30 dev eth1 ip link set eth1 up # Uplink 2 interface ip addr add 10.10.20.1/30 dev eth2 ip link set eth2 up ip rule add from 172.27.18.0/24 iif eth0 lookup UPLINK_1_DEFAULT_GATEWAY ip route add default via 10.10.10.2 table UPLINK_1_DEFAULT_GATEWAY ip rule add from 172.27.19.0/24 iif eth0 lookup UPLINK_2_DEFAULT_GATEWAY ip route add default via 10.10.20.2 table UPLINK_2_DEFAULT_GATEWAY Пакеты с адресами источников 172.27.18.0/24 и 172.27.19.0/24 будут уходить в соответсвующий основной шлюз у аплинков "iif eth0" можно опустить, это проверка на входящий интерфейс

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

Это проблема с tickless ядрами. Munin считывает загрузку из файла '/proc/stat'. Значения в этом файле в jiffies. В не Tickless ядрах значения в этом файле постоянно обновляются и соответсвенно процессор находится в каком-то определенном состоянии (или что-то делает или idle). А в tickless ядрах этот файл иногда не обновляется. Из-за этого суммарная загрузка всех ядер на графиках munin не доходит до (100% x количество процессоров. idle на графиках тоже читается из файла, а не вычисляется как 100-загрузка cpu). Если вы запустите dstat, то сумма usr+sys+idl+wai+hiq+siq тоже не будет равна 100. Так же можно поизменять значения в конфиге ядра в "CPU/Task time and stats accounting" - "Cputime accounting", там есть на выбор "Simple tick based cputime accounting", "Full dynticks CPU time accounting" и "Fine granularity task level IRQ time accounting". Но это увеличит нагрузку в какой-то степени. Еще можно переписать плагин для munin.

Это вы ещё их ТВ-продукт не пользовали :) ( ненавижу нетап много больше 10 лет ) Год назад к счастью соскочили с интернет биллига UTM5 на abills, но еще остался ТВ-биллинг... Это адская боль, злейшему врагу не посоветуешь. Он даже деньги не может правильно списывать и еще несколько десятков багов, которые не фиксятся годами, а когда фиксят, то добавляют еще 3 новых. Рекомендую забить на имеющуюся лицензию, потерять деньги и воспользоваться каким-нибудь другим биллингом (с модулем телефонии UTM5 я не работал).

Судя по статистике локов, большая часть из них это шейпер. Но как это влияет на tx_restart_queue, я не знаю (а может все наоборот). Предположение: шейпер загружает CPU, CPU не успевает генерировать прерывания, сетевушка не успевает забирать пакеты из буфера, буфер переполняется, счетчик увеличивается. А если отключить шейпер, убрать qdisc с интерфейса, _ticket_spinlock так же на первом месте? увеличиваются ли tx_restart_queue? А еще какие-то счетчики увеличиваются вместе с tx_restart_queue? Я бы еще попробовал обновить ядро и модуль ixgbe Наврятли можно как-то решить проблему с локами в htb, только использовать другие дисциплины (mqprio, multiq), которые лучше параллелятся на несколько CPU и очередей сетевой карты. Но там вылазиет еще куча проблем.

Просмотрел по-быстрому код, по-умолчанию для опроса сокетов используется select и ограничение на 1024 сокета (FD_SETSIZE), также среди вариантов есть kqueue и epoll с поддержкой 4096 дескрипторов. Наверное будет достаточно переконфигурировать с --enable-epoll

Enable collection of statistics: # echo 1 >/proc/sys/kernel/lock_stat View the top contending locks: # grep : /proc/lock_stat | head

Это один из механизмов синхронизации доступа нескольких потоков к какой-то структуре данных. Спинлок ограничивает доступ к этим данным, пока с ними работает другой поток. А "spin", потому что ожидающий освобождения блокировки поток, "крутится" в бесконечном цикле. Spinlock Spinlock. Linux Documentation 82576eb-gigabit-ethernet-controller-datashee - стр. 50, секция 1.4.9 - LEDs Interface. Может можно как-то этим управлять. А в dmesg было сообщение типа?: Sep 17 22:34:19 hostname kernel: [1343117.109123] Clocksource tsc unstable (delta = 299966045123 ns) Sep 17 22:34:19 hostname kernel: [1343117.114812] Switching to clocksource hpet Потому что TSC счетчик он встроен в процессор, не знаю, почему он может быть не доступен. CONFIG_X86_TSC=y ? В общем это уже другая проблема.

kayot vitalyb Про скорость работы с интерфейсами - [RFC][PATCH] iproute: Faster ip link add, set and delete Возможно в более новой версии iproute2 исправили что-то и с ip route show при наличии 100500 влан интерфейсов.

Статистика по локам покажет чем занимается spin_lock. Я вам отвечал на этот вопрос в теме про HTB шейпер TC HTB упирается в 2Гбит/c (хотя там был raw_spin_lock, а не __ticket_spin_lock) P.S. про второй bras TSС работает заметно быстрее. Попробуйте заменить. (у меня включение hpet увеличивало загрузку CPU на шейпере в 2 раза)

Я думал это только у меня так (может закешировалось что), каждый день захожу и вижу сообщение от 21 декабря :)

Не перестаю узнавать что-то новое из этой темы :) Спасибо. Я оптимизировал iptables, изучал flame graph системный вызовов (уже тогда обратил внимание на intel_idle, но не придал этому значения), собранных с помощью perf, пересобирал десятки раз ядро, настраивал параметры napi, оптимизировал шейпер... а после этого сообщения запустил утилиту i7z и узнал, что у меня на бордерах и насах процессоры уходят в сон :). Даже в голову не приходило проверить частоту процессора, после настроек в биосе. Не думаю, что отключение энергосбережения сильно поможет, но все равно - слона то я и не заметил. Линукс негодяй, оказывается ему пофиг на настройки в биосе (тоже везде стоит "static max performance").

не, не падало... не помню, сколько по времени занимал бекап и какого размера была таблица. Еще была такая же проблема с памятью фрирадиуса во время использования биллинга Abills, там в функции выделения рандомного ip адреса, ставится лок на таблицу, а после выделения адреса снимается. А у нас стоял пул из 65535 адресов и эта функция долго отрабатывала если одновременно сотня пользователей пытается подключиться (например во время фейла pppoe-сервера или в начале месяца). фрирадиус умирал за пару минут с 12 гигами памяти :) Возможно это особенность работы фрирадиус+rlm_perl. В итоге мы нашли узкое место и уменьшили пул адресов с 65535 до 4096. Но искали это место долго. Тоже был костыль - monit перезапускал freeradius при превышении определенного лимита занятой памяти. Еще попробуйте увеличить таймаут на радиус-клиенте, может он мало ждет и шлет повторный запрос. Я в mysql слабо разбираюсь... c ключом --single-transaction таблицы не лочатся, а изменения пишутся в какое-то другое место, пока бекап не закончится. Если у вас продолжаются проблемы с фрирадиусом, то где-то проблема с производительностью. Включите в нем логов побольше. Может база данных начинает тормозить из-за ввода/вывода во время бекапа.

Тоже сталкивался с такими проблемами. Потом сравнили время падений с кроном, оказалось падает во время бекапов. Перевели базу в innodb и добавили ключ "--single-transaction" к mysqldump. А потом вообще настроили репликацию базы данных и делаем бекап с другого сервера.

Посмотрите с помощью tcpdump или wireshark отправляются ли пакеты из интерфейса. Может не хватает каких-нибудь прав, если от рута запустить Dude тоже не работает?