А?

Вне зависимости от содержания и полезности.

Возможно ли это сделать на живой системе? Т.е. zfs смонтировано и используется, параллельно переносясь на другой zpool, и после переноса продолжая на нём работать без перебоев и более не завися от старого, т.е. его можно destroy итд.

В очередной (третий-четвёртый за несколько последних лет) раз затерев по неаккуратности файл с кодом (cp не в ту сторону), на который был потрачен предыдущий час или больше, и который ещё не был закоммичен, решил что искать его с помощью dd и grep - занятие утомительное. Слышал тут про binwalk, но, посмотрев описание, то ли не осилил найти способ её для этой цели использовать, то ли она и правда для другого.

Написал свою прогу в итоге: исходник.

Компилировать: gcc -o rawsearch rawsearch.c

Синтаксис: ./rawsearch if=/dev/sda8 str=some_string_from_file

Прога найдёт на диске все текстовые блоки (внимание: если файл фрагментирован то он будет не одним блоком а несколькими, прога их сцеплять не будет), что содержат эту строку и создаст пачку файлов с названиями found-NNN (NNN - байт где начинается) с этими текстами. Границы текстовых блоков определяются так:

static int is_binchar(char c) { return (c==127 || c>=0 && c<=6 || c>=14 && c!=27 && c<=31); }

(это символы которые по мнению проги в текстовых файлах не встречаются).

Возможно кому-то будет полезно.

Исходник максимально простой (всего 300 строк и 12кб), можно легко патчить под какие-то потребности по месту.

Перенёс систему tar-ом, и как я и подозревал getcap /usr/bin/ping выдаёт пустую строчку, а на старом диске cap_net_raw=ep. Переделывать не хочу, думаю как-то найти/угадать список таких файлов и вручную починить, либо они сами после обновлений соответствующих пакетов со временем все исправятся а вручную фиксить только по мере обнаружения проблем. Что в этом плане может пойти не так и что кроме capabilities могло не скопироваться? Сам никакие экзотические свойства файлов не использую, то есть вопрос только про файлы из дефолтных дебиановских пакетов.

Кстати вроде в прошлый раз много лет назад я так же переносил debian 7 и даже не заметил ничего.

Перемещено hobbit из general

В нескольких местах в инете прочитал что у этой модели проблемы с линуксом. В том числе на лоре: Ubuntu server 20.04.2 + Samsung 870 EVO 1TB

Но то всё старые заметки, и тема 2021 года. Это ещё актуально или уже всё починили и будет работать из коробки?

Я вижу что автор там подкрутил в sysfs длину ncq очереди и вроде у него после этого заработало, но это ж костыль и плохо сказывается на производительности.

Сразу скажу: это как-то реализовано в крупных DE, но я не знаю как и знать не хочу - так что просьба туда не смотреть. Вопрос о том, как должно быть правильно (вне зависимости от того как уже где-то сделано). Возможно, тема не для desktop а для dev, не знаю.

Так вот, простая ситуация - гуи-прога зависла и юзер хочет её завершить. Или не зависла даже, но юзер всё равно хочет её завершить именно аварийным способом. При этом считаем что механизм запуска этой проги тоже у нас в руках, а так же мы можем в умеренных рамках патчить X-server и ядро (хотя лучше без ядра). Но требовать что-то от самой проги свыше дефолтного X11 протокола нельзя (т.е. оно должно работать со всем существующим софтом без патчей).

Проблема разделяется на две: 1) сопоставить окно и pid, 2) найти все побочные pid-ы проги (у неё могут быть подпроцессы) которые тоже надо убить.

Что касается первого, то варианта вижу два:

1. при открывании коннекта к иксам с помощью ядра узнавать кто вызвал connect() на той стороне и запоминать (в линуксе это getsockopt(SO_PEERCRED));

2. запускать каждое приложение с отдельным $DISPLAY либо Xauthority, запоминать запущеный pid и где-то хранить таблицу соответствия.

У обоих вариантов есть минус: открыть коннект может один процесс а потом так или иначе отдать сокет другому, иногда совсем другому. В случае первого варианта будет ещё чуть сложнее распознать мультипроцесс приложения. Во втором - схема слишком муторная.

Теперь о втором, варианты такие:

1. запоминать только один pid и с ним и работать

2. считать единым приложением то у чего одинаковый pgid (и обеспечить и его отделение при лаунче)

3. считать единым приложением то у чего одинаковый sid (и обеспечить и его отделение при лаунче)

4. про лаунче засовывать новый процесс в контейнер и определять по контейнеру

Минусы очевидные: первый вариант не учитывает подпроцессы (а надо?), последний - наоборот испортит возможность запустить демон (демона убьют вместе с контейнером), ну а 2-3 плохи тем что их два без чёткой разницы, и есть опасения что их некоторые могут использовать не по назначению.

Чего по-моему делать точно не нужно:

1. искать список с помощью дерева процессов по pid+ppid (стоит кому-то в середине заверщиться как вся ветка его потомков прячется в ppid=1)

2. трассировать всех, ловить fork() и запоминать то же дерево но без потерь (слишком накладно и вызовет конфликты с отладчиками).

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

Что думаете по поводу всех поднятых вопросов?

Найдём и откатим все вредоносные коммиты от агентов вайланда и будем нормально фиксить все проблемы которые выяснятся с иксами у лоровцев. После чего у вайландоагитаторов исчезнут даже те никчемные аргументы что есть у них сейчас. Что думаете?

(исходники от 102.15.1 но думаю в 115 всё так же)

Собственно начинаем с C++

Файл gfx/webrender_bindings/RenderThreadOGL.cpp функция RendererOGL::UpateAndRender() - в середине есть вызов

  if (!wr_renderer_render(mRenderer, size.width, size.height, bufferAge, aOutStats, &dirtyRects)) {

mRenderer - это поле в классе RendererOGL, определено так:

  wr::Renderer* mRenderer;

wr это namespace в котором много всего разного есть.

Функция wr_renderer_render находится в файле gfx/webrender_bindings/src/bindings.rs

pub extern "C" fn wr_renderer_render(
    renderer: &mut Renderer,
    width: i32,
    height: i32,
    buffer_age: usize,
    out_stats: &mut RendererStats,
    out_dirty_rects: &mut ThinVec<DeviceIntRect>,
) -> bool {
    match renderer.render(DeviceIntSize::new(width, height), buffer_age) {
        Ok(results) => {
            *out_stats = results.stats;
            out_dirty_rects.extend(results.dirty_rects);
            true
        },
        Err(errors) => {
            for e in errors {
                warn!(" Failed to render: {:?}", e);
                let msg = CString::new(format!("wr_renderer_render: {:?}", e)).unwrap();
                unsafe {
                    gfx_critical_note(msg.as_ptr());
                }
            }
            false
        },
    }
}

Как я понимаю match это аналог switch и она вызывает метод render из той штуки которую ей дали первым аргументом. Касательно типа этого аргумента (напомню, это поле wr::Renderer* mRenderer из класса RendererOGL) в С++ файлах нашлось только упоминание struct Renderer; (без тела) в файле gfx/webrender_bindings/RendererScreenshotGrabber.h. Я думаю, эта «структура» - opaque для c++-кода и используется только из rust-а (может, не прав). В файле gfx/wr/webrender/src/renderer/mod.rs нашлось некое pub struct Renderer url но не вижу там указания на namespace wr:: и не вижу в ней метода render, который вроде бы вызывается из вышеприведённой wr_renderer_render.

Ещё есть struct/class Renderer упоминается тут:

third_party/rust/codespan-reporting/src/term/renderer.rs:pub struct Renderer<'writer, 'config> {
third_party/rust/profiling/examples/puffin/renderer.rs:pub struct Renderer {
third_party/libwebrtc/video/end_to_end_tests/call_operation_tests.cc:  class Renderer : public rtc::VideoSinkInterface<VideoFrame> {
third_party/libwebrtc/video/end_to_end_tests/call_operation_tests.cc:  class Renderer : public rtc::VideoSinkInterface<VideoFrame> {
third_party/libwebrtc/modules/audio_device/include/test_audio_device.h:  class Renderer {

но мне кажется это что-то другое вообще.

Где я напутал?

Что это за бред? Фф при компиляции создаёт директорию obj-x86_64-pc-linux-gnux32/ и компилирует всё в неё (вроде). Откуда вообще такое название могло взяться? Файл a.out, который я там внутри нашёл - вроде бы нормальный 32-битный i686 или как там его назвать. Но gnux32 это же другое должно быть.

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

Проблема, кажется, старая, потому что ещё во времена примерно фф 30 я помню скачал фф с мозиллы чтоб получить версию новее (в дебиане было что-то сильно устаревшее) и тоже заметил разительную разницу в фпс - тогда я это связал с тем что с старом фф просто джаваскрипты хуже работали, но видимо дело было не в этом а в чём-то другом.

Собственно фпс сравнивал в игре https://orteil.dashnet.org/cookieclicker/ - в мозилловском пакете там всё плавно и хорошо, в дебановском дёрганая картинка уже на стадии загрузки (когда крутятся шарики посередине экрана, эту стадию можно искуcственно удлинить если залагать себе инет - зафайрволить что-нить нужное ему в DROP).

А вы что-нить такое замечали? С чем это связано?

Оба фф запускал в новом чистом профиле (одном и том же).

Из заметной разницы (кроме фпс) - в мозилловском пакете нет звука т.к. он только пульсу ищет которой нет.

------------------

Профайлер deb: https://ibb.co/jHqYXxB

Профайлер moz: https://ibb.co/5c4mt5X

Видно что рендер запускается где-то раз в 300мс и грузит проц больше чем рендер в mozilla-пакете. А само 300мс берется из того что сама вкладка этим 300мс перед эти тоже грузит проц, а в moz-пакете гораздо меньше.

Зелёное в Render это в основном RenderThread::UpdateAndRender (во вкладке Marker Table эти пики называются «Composite #1»)

Синее в работе вкладки это «CanvasRenderingContext2D.drawImage»

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

upd: кажется не связано, ввёл в консоли CanvasRenderingContext2D.prototype.clip = function() { }; и ничего не поменялось в плане скорости

Ввёл CanvasRenderingContext2D.prototype.drawImage = function() {};, после этого затраты на эту функцию в проце вкладки исчезли (как и соответствующие картинки на странице), а вот процесс render всё так же продолжает лагать и тратит по 100мс на одну итерацию (даже увеличилось - до этого тратила около 95мс). В мозилловском пакете же 10-20мс.

------------------

Компактный пример для воспроизведения проблемы: firefox-esr с mozilla.org и из debian - разный fps (комментарий)

Как оказалось, js ни при чём, в примере его вообще нет. Но проблема как-то побочно задевает js тоже (а конкретно функцию CanvasRenderingContext2D.prototype.drawImage - она начинает в этих условиях работать в разы медленнее). В приведённом же примере js нет и лаги видны только в RenderThread::UpdateAndRender (это внутренняя функция в исходниках фф как я понял).

--------------------

Сравнение about:buildconfig firefox-esr с mozilla.org и из debian - разный fps (комментарий)

--------------------

Обновление: firefox-esr с mozilla.org и из debian - разный fps (комментарий)

Я дал вполне норм совет как решить проблему, а ты его (хорошо хоть автор темы уже успел прочесть) удалил как флуд. Заодно зачем-то удалил ответ самого автора темы о том, как он успешно решил свою проблему.

Опубликована 83-я версия кэширующего и антиспамного прокси-сервера для персонального использования c гибкими настройками.

Основные функции (всё настраивается):

1. фильтрация нежелательного контента (белые/чёрные списки на урлы, запрет кук);
2. принудительное и бессрочное кеширование полученных данных (в основном удобно для картинок и скриптов);
3. исправление содержимого веб-страниц на лету (правкой исходника на Си, есть пример для замены содержания страниц-клонов stackoverflow ссылкой на оригинал);
4. чёрные/белые списки сертификатов и certificate pinning по списку;
5. подмена айпи-адреса/домена/пути/протокола http-запроса по конфигу (такой расширенный вариант /etc/hosts);
6. http/https-сниффер.

Прекрасно подходит для просмотра сайтов через медленный интернет или с медленного устройства (благодаря п.1 и 2, ради которых изначально всё и затевалось), но вообще полезно в любом случае.

Прокси-сервер в целях безопасности и упрощения логики работы разделён на три части: TLS-сервер (терминирующий браузерные подключения), центральный модуль прокси и клиент, терминирующий исходящие подключения.

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

Пример списка блокировки:

deny    nosub   all     share.yandex.ru browser-updater.yandex.net
deny    nosub   all     a.ria.ru # ?
deny    nosub   spec    vk.com
                query   /share.php
deny    nosub   spec    yastatic.net
                query   /pcode/adfox/loader.js
                query   /share2/share.js
deny    nosub   spec    www.youtube.com
                query   /subscribe_widget
deny    nosub   spec    pano.img.ria.ru
                query   /adriver/flashplagin/movie.swf
deny    nosub   spec    a.ria.ru
                query   /ping
deny    nosub   spec    n-ssl.ria.ru
                query   /polling
deny    nosub   spec    apis.google.com
                query   /js/plusone.js
deny    nosub   spec    yandex.ru
                pref    /clck/safeclick/
                pref    /clck/click/
                pref    /clck/jclck/
deny    all     spec
                query   /tnc    # index.ru proxied counter
                exact   /tnc.js # index.ru proxied counter
                query   /pixel.gif # some spammers use this

Пример списка роутинга:

https://my.local.site
        set proxy none
        set target http://127.0.0.1:1234/localsite
        set http_host new.host:1234
.intel.com
        resolve off
        set proxy socks5://127.0.0.1:3333

В случае обновления с версии более старой чем 78 следует сконвертировать кеш: зайти в рабочую директорию прокси-сервера от юзера (uid/gid) прокси-сервера и выполнить fproxy-cacheconv-78 (по умолчанию эта программа не компилируется).

Изменения с прошлой опублированной версии (80):

1. fproxy-dashboard теперь имеет опцию для показа размеров контента в байтах а не кбайтах;
2. поддержка багнутых серверов, игнорирующих заголовок «Connection: close»;
3. поддержка багнутых серверов, отдающих некорректный заголовок «Content-Encoding: identity»;
4. отправка TLS-опции ALPN;
5. улучшение работы TLS-терминатора внешней стороны (клиента): он теперь поддерживает не только TLS, но и обычные соединения, поддерживает работу в виде независимого демона с приёмом запросов от основного прокси по сети, а также может пробрасывать свои исходящие соединения через другое прокси, таким образом позволяя гибко разделять задачи между узлами в условиях плохого интернет-соединения и/или необходимости организовать «выход» трафика где-то на удалённом сервере разной степени доверенности; так же новая версия более удобна для использования вручную из командной строки в качестве консольного TLS-клиента с поддержкой проксирования;
6. упрощена сборка, теперь есть Makefile вместо шелл-скриптов
7. организованы предсобранные .deb-пакеты в репозитории (для версий Debian 8-12)
8. изменения файла конфигурации, обратно-несовместимые
9. новый конфиг для управления роутингом запросов, объединивший ранее бывшие отдельными конфиги resolv и включения проброса исходящих соединений на удалённый сервер, а так же получивший ряд новых опций: теперь можно для каждого url-а (протокол, домен, порт, путь) выбирать через какой клиент, какое прокси он будет отправлен, через чей днс-сервер будет проводиться определение его айпи-адреса (включая опциональное делегирование этой задачи внешнему прокси-серверу http или socks5), либо прописать адрес вручную, а так же заменить протокол, порт или префикс пути url-а
10. добавлена поддержка SAN-сертификатов для ip-адресов и в клиенте и в сервере (браузеры с некоторых пор перестали принимать ip-адреса в CommonName)

В планах на будущее:

1. поддержка CGI/FastCGI/.so хуков для mitm-обработки полученного от сайтов контента
2. менеджер профилей и конфигураций прокси
3. интерактивное управление проверкой сертификатов удалёных сайтов и списками блокировок

>>> Подробности

Время от времени хотелось чтоб был некий дамп схемы использования физических накопителей разными файловыми системами, чтобы не лазить отдельно по camcontrol devlist, gmirror/gmultipath/gpart, спискам монтирования и иногда sysctl. И чтобы этот дамп был пригоден для обычного diff между «было» и «теперь». Написал в итоге такую прогу, может кому пригодится или кто даст совет как поудобнее сделать её вывод чтобы было нагляднее кто за что отвечает. (только не так как geom -t который дублирует на каждого члена mirror/multipath всю вышележащую топологию)

исходник

Компилировать с -lgeom -lfcl

update 2023-12-05

как скомпилировать с нуля с черновой поддержкой zfs:

cd /tmp/
fetch https://dev.m1089.ru/fcl/files/fcl-20231205.tar.gz
tar xf fcl-20231205.tar.gz
cd fcl-20231205/DEV/src
./build.sh fcl
fetch https://dev.m1089.ru/freebsd-misc/files/storage-summary/storage-summary.c
cc storage-summary.c -DWITH_LIBZFS -DLIBZFS_HACK -I../include -L../lib -lgeom -lfcl -lzfs -lnvpair -o storage-summary

Обновил freebsd 12.3 -> 12.4, стал ставить порты, а у диалогов с опциями поехала псевдографика, по виду похоже что оно начало её в юникоде рисовать а консоль с однобайтной кодировкой. Как исправить?

LANG= и LANG=C не помогают.

Запуск со старым ядром от 12.3 не помогает.

----------

Всё, разобрался, они из-за GPL-фобии заменили утилиту для этих диалогов, только она не в 12.3 или 12.4 а в дереве портов прописана.

https://alfonsosiciliano.gitlab.io/posts/2021-11-20-portconfig.html

Дописал в make.conf

DIALOG4PORTS=/usr/local/bin/dialog4ports

и всё починилось.

-------------

Мда https://cgit.freebsd.org/ports/commit/Mk/Scripts/dialog4ports.sh?id=9fee35128...

из-за виндузятников с putty испортили нормальное определение наличия юникода. Дело не в утилите, с ней всё норм, просто старая utf-8 вообще не поддерживала, а этой фейковое описание локали подсовывают из скрипта.

Сразу скажу что задача можно считать учебная и ответ на неё многих может показаться банальным, но мне интересно как бы вы её решили.

Условие очень простое: выражение is_contained(h0, hlen, q0, qlen) должно возвращать 1, если диапазон под вопросом (question - q), начинающийся включительно с q0 и занимающий всего qlen индексов, полностью содержится в диапазоне (have - то что имеется), начинающимся включительно с h0 и имеющим длину в hlen индексов, и должно возвращать 0 во всех других случаях. Оба диапазона относятся к индексам некоего массива или смещениям байт в файле, при том что файл целиком влез в аллоцированный блок памяти процесса в виде того же массива.

Вопрос: написать синтаксически корректную (допустим C89) реализацию функции is_contained(), такую чтобы всегда отдавала правильный результат, при этом не содержала лишнего кода и не требовала линковки с чем-то ещё, включая libc, для работы (но содержимым C89-стандартных (только их) .h файлов пользоваться можно, если оно не приводит к импорту символов извне).

Условие именно такое как я написал, никакие уточнения не предполагаются. Если считаете что условие где-то двусмысленное - дополняйте его как хотите (не противореча исходным утверждениям).

Когда речь идёт об организации надёжного хранения данных на диске, возникает проблема: надо как-то узнавать о том, что данные на диск не смогли записаться, и принимать по этому поводу какие-то меры.
Есть, конечно, и другая проблема: даже если данные на самом деле записались, они всё равно могут позже потеряться из-за аппаратного сбоя. Но это другая тема и тут мы не будем её рассматривать.

( читать дальше... )

Хочу поделиться. В течение некоторого количества часов с диска с XFS файловой системой снималась копия методом dd if=/dev/sdX of=/dev/sdY на работающем сервере с нагрузкой (т.е. в этом время там перезаписывались какие-то файлы итд). Затем sdY был использован как загрузочный диск для другой системы. Итоги: первый запуск выбросил в recovery shell из-за того что в fstab было прописано лишнее которого на второй системе нет, закомментировал и заодно исправил конфиг сети которая очевидно тоже другая, ребут - завис на надписи i/o error при чтении systemd-readahead. Ещё один ребут - зависло где-то ещё раньше без внятной диагностики. Ещё один ребут и прописал init=/bin/sh в grub-е. Оказалось что mount отказывается монтировать раздел из-за каких-то ошибок, запустил xfs_repair -L, который выдал кучу надписей но в итоге завершился успехом. Заодно на всякий случай удалил файл .readahead из корня. Итог - система грузится и работает, и даже данные вроде на месте.

Тему создал, вспомнив как тут у кого-то xfs неисправимо накрылось просто из-за аварийного ребута (питание что ли или что-то похожее) и ему там сказали что оно не подходит для таких условий работы.

Но я всё равно буду предпочитать ext4 на своих установках.

На всякий случай уточню: всё сделано исключительно для тестов и в прод пущено не будет.

У всех?

С плохого инета иногда не доходят ответы на post отправки сообщения. В итоге, после повторного нажатия кнопки, их получаются два, и из-за того же плохого инета может не получиться увидеть этот итог и вовремя удалить дубль. Почему бы не пропускать добавление коммента, если он 100% совпадает с последним добавленным этим юзером в эту тему? Даже ошибку никакую не писать, просто раз коммент уже есть - пропускать этот инсерт а всё остальное как обычно.

Почему авторы всяких libc могут объявлять функции типа vprintf в stdio.h не инклюдя побочно stdarg.h (вдруг юзеру не нужно), а все остальные не могут? Ну, я конечно посмотрел как там сделано и там вместо va_list внутренний __синоним к нему, но это же не то что некроссплатформенно, а даже при переходе на другое libc может сломаться (у libc-шных хедеров такой проблемы понятное дело нет). И даже нормального способа выяснить инклюдил ли юзер stdarg тоже нет (можно было бы эти функции вырещать препроцессором если знать что stdarg не заинклюден - всё равно без него их вызвать не получится ведь va_list).

Что вы об этом думаете?

UPDATE Поскольку замечено систематическое непонимание сути темы, попробую ещё раз написать другими словами. Есть такая функция

int vprintf(char const *fmt, va_list arg);

Перемещено leave из talks