... кто-то еще пользуется openssl enc для прятания порнушки, то имейте в виду, что где-то в районе openssl 1.1.0 там сменили умолчальный message digest, в результате чего зашифрованное старым не читается новым. Короч, openssl -md md5, да...

Главное, в мануале об этом так вскользь, а то вдруг кто-то прочитает, и его инфаркт не тяпнет. Пойти накатить грамм триста корвалола от нервов штоли...
Это которая про именование. Ну и как нетрудно видеть, не до всех эта простая истина доходит. Не дошла она и до авторов systemd, и они именуют вещи как бог на душу положит. Например, вот кто, не заглядывая в man systemd.path сможет сказать, чем отличается условие PathChanged от PathModified? Вот то-то же.

Не будьте такими как авторы systemd.
Bcache, который я поставил примерно 6 недель назад, успешно отсох и перестал кэшировать. Похоже, что причиной тому не проблемы с SSD, а какие-то его внутренние процессы — сейчас оно ругается в dmesg о том, что btree corrupted и кэш не подключает. На самом деле случилось это не сейчас, а еще две недели назад, и я ничего бы не заметил, если бы не легкие подтормаживания, ну и привычка иногда мониторить состояние всего свеженастроенного. В итоге оно просто переключилось в passthrough режим и продолжило работать как ни в чём не бывало. Потерь данных нет. В логах от 3/11 есть такая запись:

Mar 11 22:29:48 debian kernel: [198437.484482] corrupted btree at bucket 107995, block 446, 504 keys
Mar 11 22:29:48 debian kernel: [198437.484483] , disabling caching
Mar 11 22:29:54 debian kernel: [198443.041803] bcache: cached_dev_detach_finish() Caching disabled for sda
Mar 11 22:29:54 debian kernel: [198443.045608] bcache: cache_set_free() Cache set f73f7a39-fc4c-45dc-acef-7c250128e1ab unregistered


За полным отсутсвием воспроизводимости проблемы и отсутствием диагностических инструментов для bcache (даже fsck нет), писать в какое-либо спортлото считаю бессмысленным. Пересоздал кэш, посмотрим что дальше будет.
В linux-4.9 сломали rtlwifi (да, детка, это testing). Сломали по-дурацки: чего-то там рефакторили и теперь вместо rtlwifi/rtl8192cf.bin грузится rtlwifi/rtl8192cfU.bin, все живет секунд 15, а потом wifi ложится. Спасибо, что хоть так, а то подобные фокусы могут и окирпичить адаптер в теории.

Официальный фикс: http://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/commit/?id=53f769b4a76c06f7c4b7f74f8bdd028b28af6423

В дебиане (backports) можно поставить linux-image-4.9.0-0.bpo.2-amd64 (само оно почему-то не подцепилось). Более универсальный фикс — просто переименовать файлы firmware.

UPD Чудесаааа.... поставил bpo.2 и вернул firmware взад, но не перезагружался. После suspend-resume оно предсказуемо загрузило *cfU.bin (т.е. не работающее на этом адаптере), но все пока работает. Похоже, ему достаточно один раз проинициализироваться с нормальным fw.
TL;DR bcache работает и он рулез.

Меж тем, завел в хозяйстве SSD кэш для диска (несколько лет собирался аж). Ниже впечатления кратко.

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

Итак, герои дня:

1. Flashcache. Исторически первая реализация, написанная людьми из facebook. Похоже, сдох. Последний условно-содержательный коммит от сентября 2015, да и репозиторий в github/facebookarchive/flashcache как бы намекает. В дебиане есть, но на ядре 4.8 уже не собирается, а версия 3.1.3 из /testing роняет ядро в бесконечный oops. На ядре 3.16/stable впрочем работает. По итогам отправился в мусорку.

2. EnhanceIO. Форк flashcache, заброшен также осенью 2015. В дебиане нет, даже не стал пытаться заводить.

3. bcache. Выглядит самым вменяемым из всех, плюс наличие его в mainline дает некоторую надежду. Есть поддержка в дебиане. По итогам на нём и остановился. Имеет маленький недостаток: требуется полное переразбиение дисков, поскольку хочет записать на разделы свой суперблок.

4. dm-cache. Еще одна mainline-реализация, вроде бы рабочая, но в моем случае она отпала по причине того, что получался слишком замороченный io-стэк (lvm over lvm).

Сам bcache устанавливается достаточно прямолинейно. Инструкция из archwiki вполне подойдет: размечаем разделы, говорим make-bcache на backing device и на кэш, аттачим одно к другому. Очень понравилось то, что режимы можно переключать на ходу, а также работать без кэша, отцеплять его на ходу, итд. Как обычно, LVM позволяет не прерывать рабочий процесс на всякую ерунду вроде форматирования дисков, но, разумеется, понадобится еще один диск размером не менее чем основной, чтобы было куда сохранить данные (lvconvert -m1/-m0, vgreduce и далее в таком духе). На этом в принципе все.

Маленький нюанс. Вроде бы в некоторых версиях bcache себя не очень хорошо ведет с sleep/hibernate, и для компенсации этого может потребоваться маленький скрипт. В более новых ядрах все должно быть хорошо, но могут загрузить и старое, да и на проверку времени пока нет.

За неделю полет нормальный, потерь данных нет. Скорость тоже стала очень ок.
Оракл такой оракл!

In order to prevent undue risks to our customers, Oracle will not provide additional information about the specifics of vulnerabilities beyond what is provided in the Critical Patch Update (or Security Alert) advisory and pre-release note, the pre-installation notes, the readme files, and FAQs.

Что в переводе означает "хер вам, код мы обещали, а сопровождение — как получится".

Дебиановские мейнтейнеры прикинули сколько будет ручной работы по бэкпортированию фиксов в стабильные ветки, и немедленно решили перестать это делать (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794466), в результате чего:

  1. Ветки 5.x скорее всего не будет в stretch (из testing уже вынесли, а в вики официально рекомендуется ставить бинарники с virtualbox.org)
  2. В бэкпортах лежит 5.1.8, которая с новым бэкпортовым ядром 4.9 не запускается.
  3. В sid лежит 5.1.14, но её надо еще ухитриться собрать, не переезжая на sid целиком. Ну или сидеть на 4.3/stable


С учетом остальных приколов и феерической расстановки приоритетов пора и правда подумать о переезде на KVM.

upgrade

Jul. 29th, 2016 04:36 pm
mate-volume-control-applet → pasystray
NAME
       memfrob - frobnicate (encrypt) a memory area

SYNOPSIS
       #define _GNU_SOURCE             /* See feature_test_macros(7) */
       #include <string.h>

       void *memfrob(void *s, size_t n);

DESCRIPTION
       The memfrob() function encrypts the first n bytes of the memory
       area s by exclusive-ORing each character with  the  number  42.
       The  effect can be reversed by using memfrob() on the encrypted
       memory area.

       Note that this function is not a proper encryption  routine  as
       the  XOR  constant  is  fixed,  and is suitable only for hiding
       strings.
clickme

Коллега по прошлой работе запилил свой аналог buildroot и openembedded. На перле с башем. Хвастается вот.

В числе достоинств — поддержка дешевых китайских процов типа allwinner и ingenic. Впрочем, OMAP, i.MX6 и x86/64 тоже есть.
Debian 8 + backports, pulseaudio 7, bluez 5.23, mate и штатный blueman в нем.

Имеем вот это: https://bugs.freedesktop.org/show_bug.cgi?id=92102

Ключевой момент такой, что нужно каждому бойцу в цепочке еще раз доходчиво объяснить его обязанности, а именно:
bluetoothctl# connect 00:42:42:42:42:42 — на уже подсоединенной карте, Карл!
после этого a2dp становится available, и можно сделать
pactl set-card-profile ## a2dp_sink

Оказываеццо, ОКАЗЫВАЕЦЦО, кто-то еще должен делать их работу:


Apparently the a2dp profile doesn't initially get connected. It's not PulseAudio's job to connect the profiles, but something is connecting the hsp profile, so I wonder why a2dp doesn't get connected at the same time...



Парой версий раньше, разумеется, все работало.

PS. Пора уже тег заводить для поттерингосрани.
MATE заебал своими квирками
https://github.com/mate-desktop/mate-settings-daemon/blob/master/plugins/media-keys/msd-media-keys-manager.c#L979

Mate-settings-daemon, Карл! Обрабатывает нажатия клавиш, Карл!

case CALCULATOR_KEY:
                if ((cmd = g_find_program_in_path ("galculator"))) {
                        execute (manager, "galculator", FALSE, FALSE);
                } else if ((cmd = g_find_program_in_path ("mate-calc"))) {
                        execute (manager, "mate-calc", FALSE, FALSE);
                } else {
                        execute (manager, "gcalctool", FALSE, FALSE);
                }

                g_free (cmd);
                break;


Куда-то надо медленно ползти с этого...
Открыл для себя game-data-packager

TIL...

Aug. 22nd, 2015 03:50 am
... что systemd не понимает кучу опций в crypttab, в частности keyscript. Что, если вам не повезет, может привести к полной незагружабельности машины. А если повезет — будете просто вводить пароли N раз, сколько есть дисков в crypttab'е.

Поттеринг все ж мудак полный — взять, выкинуть работающую вещь, заменив своими полупереваренными выделениями, и выдавать это за неизбежное наступление светлого будущего. Проблема, между прочим, известна года так с 2011; сама первопричина проблемы смущенно ковыряет носочком пол и мямлит что-то вроде "... ну пока хорошего патча никто не прислал...".

PS. Как это обходить написано здесь.
В wheezy-backports залили обновленный libreoffice, собранный с libc >= 2.19 (как в testing). Тьху. Кажется, и впрямь пора закапывать.

UPD. Починили, но осадочек остался.
Тут кто-то из френдов какое-то время назад жаловался (по-моему это был [livejournal.com profile] nicka_startcev), что переезд на новый HDD отнимает заметный кусок жизни, полкилометра нервов, комп при этом занят и всякое такое.

Неправда.

Вот я сейчас это пишу, а машина без моего участия осваивает новый терабайтник. Потребовалась одна перезагрузка (поменять винт на новый), далее старый винт подключен к usb-адаптеру, с коего машина нормально поднялась и загрузила обычное рабочее окружение, ну и далее pvcreate / vgextend / pvmove... Даунтайм — минут двадцать, в моем случае еще прослойкой сидит cryptsetup, которым я пользуюсь раз в два года и напрочь не помню ключи — пришлось лезть в мануал.

А всего-то один раз при установке потребовалось глубоко вдохнуть и принять волевое решение ставить всё на LVM.

UPD. Спустя два часа pvmove отработал, говорим vgreduce на старый диск, отцепляем его и убираем в коробку, а на новом производим lvextend и resize2fs. На этом совсем все.
Как предложено тут:
function frng()
{
        openssl enc -aes-256-ctr \
                    -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" \
                    -nosalt < /dev/zero 
}


Скорость заметно выше чем /dev/urandom
$ frng | dd count=2M of=/dev/null
2097152+0 records in
2097152+0 records out
error writing output file
1073741824 bytes (1.1 GB) copied, 4.94361 s, 217 MB/s

$ </dev/urandom dd count=2M of=/dev/null
2097152+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB) copied, 87.8828 s, 12.2 MB/s


У владельцев процессоров с AES-NI будет еще быстрее.
705451

Проблема существует как минимум с 3.2.2, и ни одна падла не обнаружила, что функция вместо осмысленного значения возвращает 0. Тестов на это тоже нет. TDD, my ass...
Патч таки вмержили. Почти четыре месяца, бггг.
Qt5 из wheezy backports собран криво, и требует QT_XKB_CONFIG_ROOT=/usr/share/X11/xkb в env.

Profile

ex0_planet

July 2017

S M T W T F S
      1
2345678
9101112131415
1617 1819202122
23242526272829
3031     

Syndicate

RSS Atom

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 23rd, 2017 06:29 pm
Powered by Dreamwidth Studios