Владельцам ядер ниже 4.4 можно не читать.

Собственно есть cgroup и iptables -m cgroup. Почему бы не создать отдельный cgroup и фильтровать локальный трафик для этой группы?

1. Не забываем включить классную фичу

sysctl -w net.ipv4.ip_early_demux=1
# на ядрах 4.10+
sysctl -w net.ipv4.tcp_early_demux=1
sysctl -w net.ipv4.udp_early_demux=1

2. Создаем группу

mkdir /sys/fs/cgroup/net_cls/testgroup2
echo 1234 >/sys/fs/cgroup/net_cls/testgroup2/net_cls.classid

3. создаем тестовые правила

iptables -A INPUT -m cgroup --cgroup 1234 -p icmp
iptables -A INPUT -m cgroup --cgroup 1234 -p udp
iptables -A INPUT -m cgroup --cgroup 1234 -p tcp
iptables -A OUTPUT -m cgroup --cgroup 1234 -p icmp
iptables -A OUTPUT -m cgroup --cgroup 1234 -p udp
iptables -A OUTPUT -m cgroup --cgroup 1234 -p tcp

4. Переносим себя в эту группу

echo $$ >/sys/fs/cgroup/net_cls/testgroup2/tasks

5. Тестируем UDP

dig google.com
iptables -nvxL INPUT; iptables -nvxL OUTPUT

Chain INPUT (policy ACCEPT 2 packets, 255 bytes)
    pkts      bytes target     prot opt in     out     source               destination
       0        0            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            cgroup 1234
       0        0            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            cgroup 1234
       0        0            icmp --  *      *       0.0.0.0/0            0.0.0.0/0            cgroup 1234
Chain OUTPUT (policy ACCEPT 2 packets, 91 bytes)
    pkts      bytes target     prot opt in     out     source               destination
       0        0            icmp --  *      *       0.0.0.0/0            0.0.0.0/0            cgroup 1234
       2       91            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            cgroup 1234
       0        0            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            cgroup 1234

6. Тестируем TCP

iptables -Z
wget -4 -O /dev/zero https://google.com
iptables -nvxL INPUT; iptables -nvxL OUTPUT

Chain INPUT (policy ACCEPT 4 packets, 538 bytes)
    pkts      bytes target     prot opt in     out     source               destination
       4      538            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            cgroup 1234
       0        0            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            cgroup 1234
       0        0            icmp --  *      *       0.0.0.0/0            0.0.0.0/0            cgroup 1234
Chain OUTPUT (policy ACCEPT 6 packets, 451 bytes)
Chain OUTPUT (policy ACCEPT 6 packets, 451 bytes)
    pkts      bytes target     prot opt in     out     source               destination
       0        0            icmp --  *      *       0.0.0.0/0            0.0.0.0/0            cgroup 1234
       0        0            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            cgroup 1234
       6      451            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            cgroup 1234

7. Тестировать остальные протоколы бесполезно, т.к. они не поддерживаются в early_demux

Что имеем в результате? TCP можно контролировать для группы, а с UDP пролный 3.14ц!

Поковыряв ядро становится полностью понятно почему.

Проблема в том, что в UDP можно сделать bind() только на порт, что делает поиск сокета на которые пришли данные в два раза сложнее. __udp4_lib_demux_lookup() делает поиск только по номеру порта и адресу, игнорируя сокеты привязанные только к номеру порта.

Заменив __udp4_lib_demux_lookup() на полноценный поиск udp сокета через __udp4_lib_lookup()

для ядра 4.14.165

diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 731ea78..6143ca5 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2295,8 +2295,8 @@ int udp_v4_early_demux(struct sk_buff *skb)
                                                   uh->source, iph->saddr,
                                                   dif, sdif);
        } else if (skb->pkt_type == PACKET_HOST) {
-               sk = __udp4_lib_demux_lookup(net, uh->dest, iph->daddr,
-                                            uh->source, iph->saddr, dif, sdif);
+               sk = __udp4_lib_lookup(net, iph->saddr, uh->source, iph->daddr, uh->dest,
+                                       dif, 0, &udp_table, NULL);
        }

        if (!sk || !refcount_inc_not_zero(&sk->sk_refcnt))

Да, это дополнительные накладные расходы, но мы дважды это подтвердили через net.ipv4.ip_early_demux=1 и net.ipv4.udp_early_demux=1

Но теперь мы получаем в п.5

Chain INPUT (policy ACCEPT 2 packets, 255 bytes)
    pkts      bytes target     prot opt in     out     source               destination
       0        0            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            cgroup 1234
       1      226            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            cgroup 1234
       0        0            icmp --  *      *       0.0.0.0/0            0.0.0.0/0            cgroup 1234
Chain OUTPUT (policy ACCEPT 2 packets, 91 bytes)
    pkts      bytes target     prot opt in     out     source               destination
       0        0            icmp --  *      *       0.0.0.0/0            0.0.0.0/0            cgroup 1234
       2       91            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            cgroup 1234
       0        0            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            cgroup 1234

Но это патч ядра, который не все могут осилить.

Есть возможность получить аналогичный результат при помощи модуля ядра. ( https://github.com/vel21ripn/ipt_sk_helper )

Чтоб оно заработало нужно сделать sysctl -w net.ipv4.ip_early_demux=2

Работа проверялать на 4.4.209 и 4.14.165. Собирается даже на 5.4.х

Если кто может попробовать собрать его и протестировать - напишите что получилось.

PS Если починить эту фичу в официальном ядре, то станет доступной фильтраци входящего трафика по UID/GID.

Всем привет! Есть такой ноут https://market.yandex.ru/product--noutbuk-hp-pavilion-15-bc404ur-intel-core-i5-8300h-2300-mhz-15-6-1920x1080-8gb-1000gb-hdd-dvd-net-nvidia-geforce-gtx-1050-wi-fi-bluetooth-dos/278968196

Есть проблема. В нем установленная галимая TN матрица. Попробовал погуглить IPS матрицы для него, но чет не нашел. Подскажите пожалуйста как вообще понять есть ли под него IPS матрицы и какая подойдет для него? Я так понимаю у каждого ноутбука свой «разъем/порт» для матрицы. Подскажите пожалуйста как выбирать матрицы для ноутбука. Буду очень благодарен за прямые ссылки на магазины с нужной матрицей

Старая задачка. Нашел максимально точную формулировку, попрошу придерживаться её.

У нас есть три сундука, в каждом из которых лежит по две монетки.

В первом — две золотых. Во втором — две серебрянных. В третьем — одна золотая и одна серебрянная.

Мы выбираем сундук случайным образом и вслепую вытаскиваем оттуда монетку. Она оказывается золотой. Какова вероятность того, что следующая вытащенная из того же сундука монетка — тоже золотая?

Просьба, объяснить свое решение, если у вас ответ НЕ 1/2.

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

PS. Добавьте тег «тервер», плиз.

В продолжение этого треда
Импортозамещаемся

Были куплены, помимо основательного запаса обозреваемого там, NRK-518, NRK-373, 255-ZERO, 250 активный, и их припой (ПОС-61 с флюсом hr-500-lk).

518-ый теперь будет основным флюсом для всего вообще. Не кипит, не воняет, работает прекрасно. Реально лучший флюс, хоть под smd, хоть под bga. Сначала, пока не привык, хотел всё же консистенцию погуще, как у эрсы - флюс-крем. Достаточно иголочку потоньше, по итогу. И так даже лучше наносится. 255-ый тоже очень хороший, хотя в основном лично мне нужно поактивнее. Но у него нулевая проводимость, абсолютно. Найдёт своих потребителей в СВЧ электронике или аудио. А ещё пахнет лимоном лимоненом, как fluxplus, только послаще, как сироп из аптеки.

Вот 373-ий мне не зашёл. Несмотря на то что он должен быть, в принципе, похож, на 518, только менее активным, он не то что кипит, а пенится, как эпилептик сука. Может мне такой неудачный экземпляр попался, но всё же.


Припой. Естественно что пос61/63 и так был лучшим, но мне всегда не нравилась канифоль внутри, много говен после неё. Тут эта проблема решена. Felder также отправляется на полку.

В общем, ребятам из Rusflux ещё есть над чем работать, но промежуточные результаты уже очень радуют. Китайское говно окончательно выкинуто в мусорное ведро, остатки брендовых расходников пока остаются, но сиротливо ютятся на верхней полке.

Это уже взвешенное мнение после месяца использования исключительно отечественных паяльных материалов. Иншаллах.

Вообще видел тут один севачёк в сетке, пингуется нормально но вот проскнить его не получается, на попытку скана nmap, причём в режиме стэлса, говорит что хост в дауне, при этом нормально пингуется. Как такое возможно и как добиться такого же?

Заранее спасибо!!!

Привет, лор!

Прочитав работу «Techniques and Countermeasures of TCP-IP OS Fingerprinting on Linux Systems» и мануал Block and Slow Nmap with Firewalls, решил, что нужно разработать шаблон iptables для защиты своих vps-ок. Цель – по возможности скрыть пассивные отпечатки OS, а также фильтрация нежелательных подключений. Работа таблиц тестировалась в том числе и на реликтовом 2.6 ядре.

#!/bin/bash

# 1
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
ip6tables -P INPUT DROP
ip6tables -P OUTPUT ACCEPT
ip6tables -P FORWARD ACCEPT

# 2
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -N NMAP
iptables -N SSH

# 3
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

# 4
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT ! -i lo -s 127.0.0.0/8 -j DROP
iptables -A INPUT -m state --state UNTRACKED,INVALID -j DROP
iptables -t nat -A POSTROUTING -s XX.XX.XX.XX/24 -j SNAT --to-source XX.XX.XX.XX --persistent
iptables -A INPUT -i tun+ ! -s XX.XX.XX.XX/32 -p tcp --dport XXXXX -j REJECT --reject-with tcp-reset
iptables -A INPUT -i tun+ -j ACCEPT

# 5
iptables -A INPUT -p udp --dport XXXXX ! --sport 0 -m state --state NEW ! -f -m u32 --u32 "0>>22&0x3C@5&0xFF=0x38 && 0>>22&0x3C@34=0x3F3" -j ACCEPT

# 6
iptables -A INPUT -m recent --update --seconds 604800 --reap --name nmap -j DROP

# 7
iptables -A INPUT -p tcp -m multiport --dports XXXXX,XXXXX -m tcpmss --mss YYYY -m state --state NEW -j SSH
iptables -A SSH -m recent --update --seconds 604800 --reap --name ssh
iptables -A SSH -m recent --set --name ssh
iptables -A SSH -m limit --limit 1/minute --limit-burst 1 -j ACCEPT
iptables -A SSH -j DROP

# 8
iptables -A INPUT -p icmp --icmp-type 8 -m length --length XXXX -m limit --limit 1/second --limit-burst 1 -j ACCEPT
iptables -A INPUT -p icmp -m limit --limit 1/second --limit-burst 1 -j REJECT --reject-with icmp-host-unreachable

# 9
iptables -A INPUT -p tcp --sport 0 -j NMAP
iptables -A INPUT -p udp --sport 0 -j NMAP
iptables -A INPUT -m state --state NEW -f -j NMAP
iptables -A INPUT -p tcp -m osf --genre NMAP -j NMAP
iptables -A INPUT -p udp -m length --length 20:28 -j NMAP
iptables -A INPUT -p tcp ! --tcp-flags ALL SYN -m state --state NEW -j NMAP
iptables -A INPUT -p tcp --tcp-flags SYN SYN -m state ! --state NEW -j NMAP
iptables -A NMAP -m recent --set --name nmap -j DROP

# 10
iptables -t mangle -A OUTPUT -p tcp -j ECN --ecn-tcp-remove
iptables -t mangle -A OUTPUT -p tcp -j DSCP --set-dscp-class XX
iptables -t mangle -A OUTPUT -p tcp --syn -j TCPMSS --set-mss XXXX
iptables -t mangle -A OUTPUT -p tcp -j TTL --ttl-set 128
iptables -t mangle -A OUTPUT -p udp -j TTL --ttl-set 32
iptables -t mangle -A OUTPUT -p icmp -j TTL --ttl-set 128

# 11
# XXXXX service
iptables -A INPUT -p tcp --dport XXXXX -m state --state NEW -j ACCEPT
iptables -A INPUT -p udp --dport XXXXX -m state --state NEW -j ACCEPT

exit 0

• #1 Настройка политик по умолчанию. ipv6 обычно отключена, но ip6tables -P INPUT DROP оставляю на случай, если забуду v6 выключить.

• #2 Очистка таблиц перед настройкой правил.

• #3 Подтверждённые соединения больше не фильтруются. Без RELATED всё замечательно работает.

• #4 Внутренний трафик должен приходить только с устройства lo. -j SNAT для vpn. ! -s XX.XX.XX.XX/32 на некоторые порты доступ закрыт в том числе друзьям внутри виртуальной сети. Остальной трафик внутри vpn -i tun+ принимается без фильтраций.

• #5 Мне нужен стабильный доступ к vpn даже тогда, когда мой ip-шник занесён в список блокировки (во время тестов такое случается частенько). Есть подключение по vpn – доступ к ssh гарантирован. Так как этот порт не прикрыт чёрным списком, ему назначены дополнительные проверки: первый пакет не должен быть сегментирован, например. Модуль u32 – это нечто! Оооочень доступный мануал от Bill Stearn здесь. Меня напрягало, что OpenVPN отвечает на обе доступные пробы nmap -sV. Благо, первый openvpn udp пакет обладает уникальными для каждой конфигурации признаками в зависимости от сгенерированнного Diffie–Hellman ключа. 0>>22&0x3C@5&0xFF=0x38 матчится байт-маркер OpenVPN, 0>>22&0x3C@34=0x3F3 – бред, чтобы не копировали: здесь правило будет у всех разное, можно только его оставить. Ищется просто с помощью tcpdump, wireshark и т. д. В результате vps-ка больше не отвечает ни на какие пробы запущенной на порту службы.

• #6 Чёрный список со сроком жизни каждой записи в одну неделю.

• #7 К сожалению, первый пакет tcp соединения (ssh) невозможно фильтровать модулем u32 – пакет обычно пустой, а провайдер режет бит TOS. Поэтому придумал помечать SYN пакеты выставлением --mss (принимает значения до 1460 включительно). Выбрал нестандартное значение и voilà: для обычного сканера порт выглядит всегда закрытым, и не нужно городить «port-knocking» и прочие «f2b». Доступ к ssh разрешён только по сертификату + подключаюсь всегда только с одной машины. Разумеется, у клиента прописано правило -t mangle -A POSTROUTING -d XX.XX.XX.XX -p tcp --syn -m multiport --dports XXXXX,XXXXX -j TCPMSS --set-mss YYYY. Это резервное правило, потому что всегда подключаюсь к ssh по vpn. -m limit --limit 1/minute нужен для замедления атак на случай, если злоумышленник подберёт значение mss. Таблица -m recent --set --name ssh не участвует в блокировках, но мне нужна, чтобы я начал вовремя паниковать (время от времени просматриваю логи блокировок).

• #8 icmp отвечает только если матчится --length XXXX. Во всех остальных случаях не drop, а --reject-with icmp-host-unreachable – никого нет дома! На мой взгляд это эффективнее.

• #9 Детектор tcp и udp сканеров. Ответ на пакет с запрещённого 0-го порта – пассивный признак OS. Сканирование пустыми udp пакетами – верный признак nmap. Первый пакет tcp соединения должен быть помечен SYN флагом, и только так! Он не должен быть сегментирован. Всё остальное от лукавого!
  Меня не интересует блокировка случайных сканеров: каждый день они стучатся тысячами на 22 и т. п. порты. Постучатся разок, да и уходят. А вот nmap-щики отличаются настырностью, как о том свидетельствуют логи. Скан-товарищи появляются нечасто: 1 в день максимум, но таких лучше выявлять и отправлять в ж… на одну неделю.

• #10 Затирание пассивных признаков OS. Цепочка -A OUTPUT транзитный трафик не изменяет, только ответы и соединения самого сервера. Бит TOS (он же ECN + DSCP) менять нужно 100%, он в дефолте выдаёт linux. «–set-mss XXXX» выставляю любой, который матчится скриптами nmap (благо исходники на гитхабе можно просмотреть и подобрать подходящее значение). По моему наблюдению удачными значениями являются 1000, 1400 и 1460. «–ttl-set 128» чаще бывает на M$. В итоге nmap после сканирования с пристрастием уверенно рапортует, что 98% на устройстве работает OS M$ 2000 server, а зная операционку, уже понятно какие надо применять эксплойты ;)

• #11 Прописаны открытые порты для моих сервисов. Там их куча, оставил образец.

Изучил все расширения iptables. Больше ничего полезного для себя не нашёл. Если есть ещё интересные способы прикрытия файервола на iptables – прошу поделиться опытом. Может быть какие-то неочевидные ошибки допустил – прошу поправить. Буду рад, если мой опыт кому-нибудь пригодится.
От атак «я-у-мамы-кул-хацкеров» такие правила должны защитить. В случае с профессионалами, наверно, это не защита, но таким до моих vps-ок нет никакого дела :)

Будет ли разница, если я скомпилирую 3 библиотеки с lto отдельно; и если скомпилирую их вместе? Что делать, если нет возможности объединить два проэкта? Как заставить lto продолжить оптимизацию в совокупности со всеми слинкованными библиотеками (которые также были скомпилированны с lto, но автономно)? А то я сильно удивился, когда скомпилил основной проект с LTO и производительность не изменилась ни на грамм. А там куча зависимостей, к которым я не применил LTO, и я не знаю, как применить его ко всем библиотекам сразу.

Большинство зависимостей можно статически связать с моей программой, но некоторые нельзя. В каком случае можно сделать общий LTO, если его вообще можно сделать, и как?

Можно ли то же самое провернуть с PGO? (Тоже почти не заметил разницы из-за этого, она была 1%, где-то в лучшую где-то в худшую сторону).

Столкнулся с такой проблемой при использовании динамической либы в Си. Допустим в библиотеке используется функция

uint16_t crc16_ccitt (const void *p, size_t size);

она используется исключительно внутри библиотеки в не объявлена в экспортируемых заголовочных файлах.

Если вдруг в приложении, где будет использоваться эта библиотека, есть функция с таким же именем, то из библиотеки вызывается именно эта пользовательская реализация… конкретно это я заметил исключительно потому, что у пользователя эта функция была объявлена как

uint16_t crc16_ccitt (size_t size, const void *p);

то есть параметры были поменяны местами и когда библиотека пыталась ее вызвать, приложение падало в segmentation fault.

Есть ли какой-то способ избежать таких эффектов и изолировать функции библиотеки от пользовательских функций с таким же именем, возможно, некоторая опция gcc?

Если нет, то как такую проблему решают в крупных проектах?

Библиотека собирается с такими опциями:

-fPIC -c -std=c11 -fplan9-extensions -Wall -Wno-unused-parameter -Wno-unused-variable -Wno-unused-function -Wno-format-zero-length

Дано: имеем наушники с микрофоном, подключенные через bluetooth к компьютеру. Наушники используются как собственно наушники для прослушивания музыки (профиль A2DP) и для голосовых VoIP-звонков (профиль HSP/HFP). Переключение профилей производится вручную в программе pavucontrol.

Проблема: при использовании профиля HSP/HFP (именно в таком виде оно представлено в выпадающем списке pavucontrol) качество звука плохое, слушать музыку непривычно и неприятно. Даже при голосовых звонках чувствуется разница качества звука по сравнению с проводной гарнитурой.

Можно ли достичь высокого качества звука при совершении голосовых звонков с помощью беспроводной гарнитуры?

Нужно временно смонтировать все файлы и папки внутри определённых папок /usr/local в /usr, с «заменой», но на время. При чём, при монтировании, те файлы, которые в /usr не были замещены, должны остаться. Простыми словами, приоритет local должен быть выше чем приоритет usr, но программы должны думать, что это всё лежит в /usr. Симлинки не подходят, сразу говорю, они заменяют всё без отмены. Монтирование обыкновенное тоже не подходит, оно стирает те файлы которые не были заменены, т.к их нет в local. Я просто установил musl libc, а он из local не может получить доступ к некоторым заголовкам и многому другому. Устанавливать его напрямую в /usr мне не удобно, т.к нужно будет вернуть обратно для некоторых сборок, а там уже всё окажется испорченным.

День добрый. Подскажите, пытаюсь настроить оповещение zabbix в телеграмм, и не получается настроить проксирование, роскомнадзор заблокировал все напрочь.

проверяю, работает ли прокси:

curl -IL --socks5-hostname "user:pass@p.serv.ru:443" https://api.telegram.org 

Получаю ошибку: OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to api.telegram.org:443

*   Trying 144.76.234.220...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55e28fb6ddc0)
* SOCKS5 communication to api.telegram.org:443
* SOCKS5 request granted.
* Connected to p.sb30.ru (144.76.234.220) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to api.telegram.org:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to api.telegram.org:443

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

Как curl указать этот тип проксирования? Как вообще отправлять в телеграм из zabbix в России из под роскомнадзора?

Состоялся релиз Coreboot 4.11 - свободной замены проприетарным прошивкам UEFI/BIOS, используемой для начальной инициализации железа перед передачей управления дополнению «payload», например SeaBIOS или GRUB2. Coreboot очень минималистичен, к тому же он предоставляет широкие возможности встраивания различных дополнений вроде утилиты вывода подробной системной информации coreinfo и тетриса tint, а также дискетных ОС: Kolibri, FreeDOS, MichalOS, Memtest, Snowdrop, FloppyBird и др.

В новой версии:

• Почищен и унифицирован код многих платформ

• Значительно улучшена поддержка чипсетов Mediatek 8173 и AMD Picasso 17h (Ryzen), а также RISC-V

• Расширена поддержка vboot (свободного аналога проприетарному SecureBoot) — изначально он был только на хромбуках, но теперь появился и на другом железе

• Добавлены 25 новых плат:

  AMD Padmelon, ASUS P5QL-EM, Emulation QEMU-AARCH64, Google Akemi / Arcada CML / Damu / Dood / Drallion / Dratini / Jacuzzi / Juniper / Kakadu / Kappa / Puff / Sarien CML / Treeya / Trogdor, Lenovo R60, Lenovo T410, Lenovo Thinkpad T440P, Lenovo X301, Razer Blade-Stealth KBL, Siemens MC-APL6, Supermicro X11SSH-TF / X11SSM-F.

• Удалена поддержка единственной поддерживаемой платы MIPS (Google Urara) и архитектуры MIPS вообще, а также платы AMD Torpedo и кода AMD AGESA 12h

• Улучшена нативная инициализация Intel-овских видеокарт в библиотеке libgfxinit

• Исправлен спящий режим на некоторых AMD-шных платах, включая Lenovo G505S

В ближайшее после релиза время планируется удаление многих плат, не поддерживающих «relocatable ramstage», «C bootblock» и платформ использующих «Cache as RAM» без стадии postcar. Это ставит под, угрозу множество важных плат на базе AMD, в том числе сервер ASUS KGPE-D16 — самый мощный поддерживаемый coreboot-ом сервер, к тому же способный работать без блобов (libreboot). О серьёзности намерений свидетельствует ряд свежих изменений на review.coreboot.org, в особенности https://review.coreboot.org/c/coreboot/+/36961

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

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

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

https://habr.com/ru/post/476414/

Поговорим о флюсах. Я уже очень долгое время использую немецкий Ersa FMKANC32, и полностью им доволен, однако он неожиданно, как приход зимы, закончился, новый я не заказал, а брать официально - я не миллиардер. Так что были куплены в ближайшем лабазе тоже именитый американский Fluxplus 612 и расово отечественный Rusflux HR-500-LK. Также в сравнении будет участвовать китайский Kingbo RMA-218.

Активность
Самый активный китаец. Американец менее, наш ещё менее. То есть для облуживания ржавых гвоздей не подойдёт. Однако это не вазелин, и его активности более чем достаточно для пайки SMD и BGA, то есть на слабоокисленных контактах.

Проводимость
Мегаомметра у меня нет, потому такие тесты не делал. Однако они есть на ютубе, и русфлюкс даже в неактивированном состоянии укладывается в ГОСТ (100 МОм). Китаец же и после активации имеет весьма высокую проводимость, особенно это будет заметно на линиях данных. Паял как-то мультиконтроллер им, курсор тачпада офигевал. Для пайки BGA использовать его нельзя категорически, только полная отмывка. Американец тут нареканий не вызывает, но его тоже желательно отмывать.

Кипучесть
Почти не кипит, даже в больших количествах. Китай, кстати, тоже не особо кипучий, а вот от флюксплюса может и микруху сдвинуть.

Отмывка
Наш - несомненный лидер, отмывается одним движением кисти. Флюксплюс заметно хуже, китайский говнилин надо греть что бы отмыть.

Запах
Российский вообще почти не пахнет. Америка пахнет химическим ароматизатором лимона. Мне этот запах, кстати, нравится (я токсикоман), но окружающие не в восторге. Эрса воняет химией и тухлыми носками, а кингбо как 30 эрс одновременно.

В остальных сравнениях эрса не упоминалась, поскольку примерно аналогична efd fluxplus, только менее активна.

Я сегодня отреболлил и припаял на HR-500-LK интеловский комбинированный процессор, снял и поставил на родных бессвинцовых шарах амдшный север rs880, поменял мультиконтроллер. То есть, по сути, самые сложные задачи, провода паять и канифолью можно. Впечатления отличные. С учётом того что rusflux дешевле fluxplus в 4 раза, а эрсы, если смотреть официальный ценник, в 16 (иначе в 5), а качество одинаковое по сути, то не вижу смысла платить больше. Хватит кормить Америку!

Дешевле всех, конечно, Китай. Он, можно сказать, бесплатный. Банка 100 г. стоит 370 рублей, а с каким-то купоном я её взял за 100. Для проводов и разъемов пойдёт. Для чего-то серьёзного - нет.

Закажу завтра остальной ассортимент отечественного производителя. Особенно интересен NRK-518-A, он более активен, чем обозреваемый, и работает до 350 градусов, под паяльник самое то. А этот всё же больше для бесконтактной пайки.

привет всем. На sway не могу нативно запустить хромиум и иже с ним, всегда используется xwayland. Те если сделать GDK_BACKEND=wayland базирующиеся на хромиуме браузера не запускаются вообще с ошибкой display not found. Не то чтобы я страдал без хромовых, но просто интересно сравнить производительность тк фокс сейчас летает а хромиум заметно подтормаживает. изменять gdk_backend желания нет, вероятно куча софта будет пробовать стартовать по иксами. Вопрос к людям с дм на вяленом но на разных дистрах: когда запускается хром у всех стартует xwayland? Может у кого есть решение проблемы, потому как все что я испробовал не помогло вообще. Это советы типа WAYLAND_DISPLAY=wayland-0 или EGL_DEFAULT_DISPLAY=wayland-0.

Новая возможность пока имеет статус «экспериментальная». Она позволяет использовать для аутентификации очень дешевые аппаратные ключи, подключаемые через USB, Bluetooth и NFC. Например YubiKey Security Key или Thetis FIDO U2F Security Key with Bluetooth стоят около 100 евро.

Руководство по включению данной аутентификации по ссылке.

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

Готовлюсь к плавному переезду на freebsd, как раз выходу 12.1, потискал в виртуалке - все круто и довольно понятно. Единственное, что не могу проверить в виртуалке и поиграть с настройками - это видеокарты и драйвера к ним. Поэтому хотелось бы получить мнения\советы\бест практисы по следующим моим умозаключениям.

Переехал, пишу из горящего ноутбука. Немного отредактировал тему: сначала все по интелу, включая xorg (все работает), потом нвидиа (пока не трогал)

Итак, есть ноут Intel® Core™ i7-4500U + GeForce GT 750M.

1. Для начала нужно узнать как определились видеокарты в системе:

pciconf -lv

pci0:0:0 - intel
pci0:1:0 - nvidia

2. Начнем с установки драйвера интел:

• опытным путем было вымучано, что простой установки иксов через:

  pkg install xorg

  не хватает, и нужны еще драйвера от интела:

  pkg install xf86-video-intel

• используя чудесный гайд: https://forums.freebsd.org/threads/how-to-use-the-old-or-the-new-i915kms-driv..., можно понять, что i7-4500U это 4-ое поколение и нужен драйвер i915kms.ko, который уже поставляется в базовой системе. Для его загрузки нужно только прописать его в rc.conf:

  kld_list="i915kms"
  

• если у вас процессор более новый - 5ххх и выше, то будет чуть больше шагов: по ссылке выше все описано.
• далее пользователя, который будет заходить в иксы и пользовать интел нужно добавить в группу видево для 3Д ускорения (user=user) и ребут:

  pw group video -m user
  reboot
  

• проверка того, что драйвер от интела загрузился:

  kldstat | grep 915
  

• ура, на этом этапе установлены драйвера от интела и они загружаются при старте ОС.

3. Нвидиа пока не трогал.

4. Настройка xorg.

• далее нужно указать xorg, что для определенной видеокарты нужно юзать определенный драйвер, для это нужно создать следующий файл:

  /usr/local/etc/X11/xorg.conf.d/driver.conf
  

  с содержимым (данные зависят от вывода первого пункта):

  Section "Device"
  	Identifier "Card0"
  	Driver     "intel"
  	BusID    "PCI:0:0:0"
  EndSection
  

• далее можно сразу попробовать стартануть иксы:

  startx
  

  если все заработает и стартанет без ошибок - значит драйвер i915kms корректно подгрузился в xorg
• на этом этапе уже можно выбирать себе DE и далее смотреть другие гайды, если есть проблемы, то смотреть в лог:

  /var/log/Xorg.0.log
  

5. Из приятного: изображение в иксах не мерцает, как это было в ubuntu, fedora, manjaro и rhel (причем мерцало как и на интеле, так и на нвидиа(как на открытом так и на закрытом драйвере))

как бы научить Хы делать альт-шифт на переключение раскладки И не «переключая» раскладки например с включенным английским набирать русские буквы нажав какой-нибудь мод4

P.S. Если кому надо (альт-шифт и капслок) setxkbmap -layout us,ru -option grp:alt_shift_toggle,caps_switch

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

Хотелось бы уточнить собранную инфу и опробованную опытом

Если я правильно понял в ZFS может быть:

Pool с файловыми системами
ZIL (Intent Log) - транзакционный лог, обычно расположен в пуле
SLOG - транзакционный лог, вынесенный из пула на отдельное устройство
ARC - кэш чтения в RAM
L2ARC - дополнительный кэш чтения на отдельном устройстве типа быстрого SSD или RAMdrive?

ZFS всегда пишет последовательно и в Pool и в ZIL, верно?
но если одновременно туда и туда, то может получиться random write, поэтому чтобы убрать лишнее ерзанье головок ZIL перемещают из Pool в отдельный SLOG верно?

Какой размер блока, записываемый ZFS на устройства? равный record size?
какая у винтов пропускная способность на последовательные МЕЛКИЕ блоки, например 4К, 128К ?

В ZFS вообще не бывает random write данных? может быть только метаданных? Метаданные нельзя хранить на отдельном от данных устройстве (mirror dev1 dev2 ...)? Поэтому размещение ZIL на SSD SLOG почти не дает видимого прироста?

Т.е. применить SSD в ZFS для повышения производительности записи random write (I)OPs почти невозможно?

При использовании части SSD под пул, имеет ли смысл часть этих SSD отдавать под SLOG или L2ARC? Или они насыщены операциями в пуле и будут только тормозить работу других пулов, находясь в SLOG и L2ARC этих других пулов?

Может ли SSD повысить скорость чтения, если его добавить в кэш чтения L2ARC?

Вообще для ZFS наверно лучше добавлять только устройство целиком под определенную функцию (SLOG, L2ARC, и т.п.)?