Ходячий генератор энтропии

Товарищ rustedowl у себя в ЖЖ недавно писал про неотключаемую функцию modern standby. А тут приехал ко мне рабочий ноутбук Dell Latitude. Накатил на него Fedora и обнаружил, что там нехило высаживается батарея в режиме suspend. Поначалу грешил на Fedora, но как оказалось, Рафик там неуиноват.

После изысканий выяснилось, что сел на ту же мину что и другие. И да, эта фича у меня не отключается вообще на уровне EFI. То есть прописывать grub опцию mem_sleep_default=deep бесполезно. Всё равно команда cat /sys/power/mem_sleep показывает только поддержку s2idle.

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

Вот так и живу теперь, короче. Заодно подгорело ещё и у меня до кучи.

This is crosspost from https://techquisitor.dreamwidth.org/332617.html

Какое-то время назад, у меня в комментах был человек, утверждавший, что проблемы снабжения хлебом в СССР были временными трудностями, да ещё и на фоне Гражданской войны и нескольких лет после. Почему это не так, не буду пересказывать. Отправлю читать, например, книгу Осокиной «За фасадом сталинского изобилия». Как по тексту книги, так и в конце приводится обширнейшая библиография источников и описей. Рецензию легко найти по тегу «книги».

Но тут другой момент. Часто люди ссылаются на официальную историографию СССР о том, что мол-де в царской России всё было ещё хуже, а большевики исправили ситуацию к лучшему. Причём ссылаются на это как на аксиому.
This is crosspost from https://techquisitor.dreamwidth.org/332407.html

«О чём думаешь, Евгений?» вопрошает меня Фейсбук. А о том, что давно у меня не было рубрики «карма тестировщика».

Дано: Fedora 34 Workstation. Ванильная. Со всеми патчами и апдейтами из штатных репозиториев. Никаких RPM Fusion и иже с ними.

• Уже несколько раз крашился Gnome, причём непонятно из-за чего. Но отчёты в ABRT сгенерились. Надо бы восстановить пароль от багзиллы Fedora и отправить логи туда.


• Постоянно пропадает звук на полсекунды или меньше в Firefox, при подключении внешней звуковой карты. Судя по всему, проблема в PipeWire. Решения пока не нашёл. Если проигрывать со штатной звуковой карты в ноутбуке — всё ОК.


• При обратном включении иконок на работе столе Gnome, иконки постоянно меняют своё местоположение при включении или выключении дока. Причём заметил, что съезжают всегда одинаково. В качестве обходного решения расположил иконки как мне надо при включенном доке и использовать Gnome Shell только с доком. Стыд, да и только.


• Очень редко, но теряются настройки внешних мониторов. Какую-то последовательность пока не уловил. Но случается правда редко и фикс занимает несколько секунд. Переживу. Туда же — меняются местами primary и secondary мониторы.


• Нихера не запоминаются настройки размера окон в Gnome Terminal.


• До сих пор надо в Gnome Terminal надо отключать Menu acceleration, чтобы заработала клавиша F10. Да, я использую Midnight Commander. Порицайте меня.


• Всё так же надо использовать Gnome Tweaks, чтобы добавить кнопки сворачивания, разворачивания и максимизации-минимизации окон.


• По хрен знает какой причине у меня не работали сначала Gnome Extensions. Решение: обнулить профиль пользователя и сбросить профили Firefox/Chrome, затем заново переустановить аддоны для браузеров.


• Если воткнуть док до загрузки ноутбука, то система будет загружаться раза в три медленнее, чем без него.

Может мне и правда в QA идти было надо?

This is crosspost from https://techquisitor.dreamwidth.org/332035.html

Думаю ни для кого не новость, что сертификаты от R3 которым подписаны цепочки от тех же Let's Encrypt протухли ещё 30 сентября. Но те, кто выписывают сертификаты с помощью certbot, обнаружили, что сертификат обновляется, но по-прежнему подсовывается старая цепочка доверия.

Чтобы заставить certbot выдавать сертификаты используя цепочку ISRG X1, надо скормить оному команду certbot renew --preferred-chain "ISRG Root X1". Затем просто перезапустить сервер. В дальнейшем будет сгенерирован конфиг для сертификата, где по умолчанию будет прописано необходимая предпочтительная цепочка доверия.


This is crosspost from https://techquisitor.dreamwidth.org/331789.html

Как-то после обновления с Catalina на BigSur у меня отвалилось два устройства. Точнее как отвалились. Мой внешний ЦАП работал, но очень эпизодически глючил. А вот принтер HP LaserJet 1018 вовсе перестал работать.

К счастью, с ЦАП проблема довольно быстро решилась выпуском обновления драйверов для BigSur, то с принтером оказалась полная засада. Чего только не перепробовал. И переустановка драйверов заново с полной зачисткой всех хвостов, установка драйверов с помощью Pacifist.В итоге уже почти смирился с тем, что придётся менять надёжный как булыжник принтер на что-то иное, как внезапно натыкаюсь на статью, а там вижу интересное:


This is crosspost from https://techquisitor.dreamwidth.org/331624.html

VPN клиент от Cisco, конечно, та ещё притча по языцех. Компания, специализирующаяся на сетевых решениях всё ещё не умеет в клиенты для сетевых, собственно, решений. Даже в Linux с помощью Network Manager это реализовано намного более прямо.

В этот раз обнаружил очередное прекрасное. При установке клиента приезжает до кучи Cisco AnyConnect Socket Filter. Всё бы ничего, он и раньше был, но под OS 11 BigSur с ним всплыла проблема. Socket Filter появляется в Network Preferences. И именно под BigSur он наглухо фильтрует доступ к куче всего, по одному ему известному способу. У меня стало медленно работать вообще всё, что связано с сетью. Браузеры, утилиты вроде ping, вообще всё. В итоге просто грохнул в сетях всё связанное с Socker Filter и позапрещал доступ к Kernel Extension который пытается врубиться при доступе к сети. Внезапно всё заработало так же шустро как раньше. В итоге вопрос — ну нахера так, а?


This is crosspost from https://techquisitor.dreamwidth.org/331399.html

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

Первое, что бросилось в глаза, что IPMI явно стырен у более-менее свежих серверов Huawei, даже окошки консольного ровно те же самые и тормоза точно те же самые. Но дальше меня ждало ещё большее удивление, когда я обнаружил это:


Да-да, в реальности это сервер ASRock со стыренным IPMI Huawei и перелицованный как Aquarius. Вот только сертификатики поменять забыли. Такое вот импортозамещение. Запомните, ASRock иностранная компания и в реестре импортозамещённой продукции быть не должна. А Aquarius это «отечественная разработка». Смотрите, не перепутайте.

This is crosspost from https://techquisitor.dreamwidth.org/331013.html

.. и его проблемы.

Снова решил пописать про работу. На сей раз, проблема возника с RabbitMQ.

Имеется кролик с неработающими очередями. При этом всё поднято, но если заглянуть в логи, то можно увидеть в первую очередь нечто такое:

2021-06-09 10:02:38.030 [error] <0.19004.32> Error on AMQP connection <0.19004.32> (192.168.0.1:42538 -> 192.168.0.3:5672, vhost: 'none', user: 'updater', state: opening), channel 0:
{handshake_error,opening,
{amqp_error,internal_error,
"access to vhost '/' refused for user 'XXX': vhost '/' is down",
'connection.open'}}
2021-06-09 10:02:38.030 [info] <0.19004.32> closing AMQP connection <0.19004.32> (192.168.0.1:42538 -> 192.168.0.3:5672, vhost: 'none', user: 'updat
er')
2021-06-09 10:02:38.031 [info] <0.19001.32> accepting AMQP connection <0.19001.32> (192.168.0.2:14580 -> 192.168.0.3:5672)
2021-06-09 10:02:38.032 [info] <0.19020.32> accepting AMQP connection <0.19020.32> (192.168.0.1:42540 -> 192.168.0.3:5672)
2021-06-09 10:02:38.033 [error] <0.19001.32> Error on AMQP connection <0.19001.32> (192.168.0.2:14580 -> 192.168.0.3:5672, vhost: 'none', user: 'smsc', state: opening), channel 0:
{handshake_error,opening,
{amqp_error,internal_error,
"access to vhost '/' refused for user 'YYY': vhost '/' is down",
'connection.open'}}
2021-06-09 10:02:38.034 [info] <0.19001.32> closing AMQP connection <0.19001.32> (192.168.0.2:14580 -> 192.168.0.3:5672, vhost: 'none', user: 'smsc')
2021-06-09 10:02:38.035 [error] <0.19020.32> Error on AMQP connection <0.19020.32> (192.168.0.1:42540 -> 192.168.0.3:5672, vhost: 'none', user: 'updater', state: opening), channel 0:
{handshake_error,opening,
{amqp_error,internal_error,
"access to vhost '/' refused for user 'XXX': vhost '/' is down",
'connection.open'}}


Если же зайти в админку кролика, то мы видим сообщение вида:

Virtual host / experienced an error on node rabbit@somehost and may be inaccessible

После раскуривания некоторого количества логов, выяснилось, что проблема в Mnesia. По какой-то причине корраптятся сообщения в msg_stores. Если повнимательнее поискать, то можно заметить такое:


CRASH REPORT Process
<0.430.0> with 0 neighbours crashed with reason: no match of right hand value {error,{not_a_dets_file,”/var/lib/rabbitmq/mnesia/rabbit@hostname_1/msg_stores/vhosts/628WB79CIFDYO9LJI6DKMI09L/recovery.d ets”}} in rabbit_recovery_terms:open_table/1 line 197


Дальше останавливаем корлика, затем идём по указанному пути и грохаем целиком /var/lib/rabbitmq/mnesia/rabbit@hostname_1/msg_stores/vhosts/628WB79CIFDYO9LJI6DKMI09L/. После этого запускаем демона заново. Всё должно запуститься без проблем.

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

This is crosspost from https://techquisitor.dreamwidth.org/330773.htm

...а теперь представился случай. Расскажу-ка я про занятный случай связанный Varnish.

Итак, есть энное количество кешей, ранее работавших на Varnish 3. Работало всё хорошо, но третья ветка давно очень устарела и более не поддерживается. Так что мы смигрировали на ветку 6.0.x, которая является LTS релизом. Пришлось правда переписать кастомные модули для него, но это отдельная история.

Всё б ничего, но после апгрейда мы заметили в мониторинге такую вещь, что Varnish стал постоянно перезапускаться. Расследование показало, что умирал порождаемый варнишем процесс.
Хочу заметить, что у нас для кастомных сервисов используется runit. Простой как палка, но своё дело делает (systemd-хейтеры и любители поотлаживать bash — вам сюда!). Так вот в процессе дебага мы отловили такую хрень, что SIGTERM посылает сам runit. Что за ерунда? С третьим варнишем таких проблем не было, исправно работал годами.

Тем не менее, в strace видно следующую картину:

1622625209.201334 --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=4431, si_uid=0} ---
1622625209.202221 --- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=4431, si_uid=0} ---
1622625209.203109 rt_sigreturn({mask=[]}) = 0 <0.065258>
1622625209.333354 write(2, "Error: Manager got SIGTERM\n", 27) = 27 <0.000865>
1622625209.590396 getpid()              = 22267 <0.001420>
1622625209.592812 sendto(7, "<131>Jun  2 09:13:29 varnishd[22"..., 57, MSG_NOSIGNAL, NULL, 0) = 57 <0.000927>
1622625209.718907 write(2, "Debug: Stopping Child\n", 22) = 22 <0.157719>
1622625209.877579 getpid()              = 22267 <0.000890>
1622625209.879363 sendto(7, "<135>Jun  2 09:13:29 varnishd[22"..., 52, MSG_NOSIGNAL, NULL, 0) = 52 <0.000916>

После некоторого времени дебага, обнаружили странную вещь. У нас на машинах крутится два инстанса варниша с разными vcl и настройками. Один runit-сервис так и называется varnish, а второй несколько иначе. И вот второй, что интересно, работает как надо.
Нас взяло любопытство и мы взяли и запихвли во второй инстанс настройки от первого. Что интересно, всё заработало.
Дальше мы в порядке бреда просто переименовали runit varnish в что-то другое и... всё заработало.

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

Так и живём.

This is crosspost from https://techquisitor.dreamwidth.org/330561.html