Re: Пользователь www-data в nginx.conf
А на убунте как работало? И как именно пользователи наполняют сайт? nginx должен работать от www-data, не нужно это менять. Если файлы не секретные, то можно дать всем права на их чтение, и www-data сможет их читать. Настроить права для создаваемых файлов можно через `umask`. Другое решение это сделать спец группу, добавить туда всех пользователей, и www-data, и дать права на чтение этой группе. Пользователям можно назначить эту группу основной, тогда файлы будут сразу создаваться с этой группой в качестве владельца, либо пользователи сами могут менять группу с помощью chgrp. Наконец, можно заморочиться с ACL. https://manpages.debian.org/testing/acl/acl.5.en.html
Re: Postfix/Exim Relay с проверкой по шаблону
Есть https://www.postfix.org/BUILTIN_FILTER_README.html Нужно настроить https://www.postfix.org/header_checks.5.html (в конце есть примеры) Демон cleanup (см диаграмму https://paulgorman.org/technical/postfix-architecture-diagram.svg) пропускает все сообщения через header_checks(5), и при совпадении регулярки может делать разные действия.
Re: События с линком Wireguard
> > > Я тебе один страшный секрет открою - весь магический KeepAlive кривотика - > это пакет с 0-byte payload. Которые успешно режут некоторые виды > корпоративных фаирволов. Всё гораздо хуже: " A GRE Keepalive is a "host to router" GRE packet encapsulated inside a "router to host" GRE packet. The idea being the host (in this case Linux) receives the packet, sees the packet is actually a GRE packet for the router, and sends it back out. The router receives this packet and knows the remote end is still responding. The Linux FIB code is such that if it receives traffic where the source is a local unicast address, the traffic is considered invalid. " Так что режет его сам линукс, когда видит пакет со своим адресом в качестве source. Можно включить "accept_local", но это дыра, и потому используют пинг.
Re: События с линком Wireguard
> > > А поскольку wireguard это переусложнённый ipip туннель, то выбор тут > небольшой - наскриптовать ping/wg show или уже промышленно так, завести > bird2 с bgp и анонсить себе маршруты с удалённой стороны. > > У микротов есть похожая проблема с GRE: определить смерть GRE невозможно, потому они переодически шлют нестандартный KeepAlive, который Линукс не умеет, и народ решает пингом в кроне: микрот видит траффик, и тоннель не кладет:) У циски есть BFD для быстрого детекта упавших линков. https://en.wikipedia.org/wiki/Bidirectional_Forwarding_Detection Под Линукс есть его реализация тут: https://frrouting.org/ Возможно, это поможет. Но я не пробовал.
Re: DevFS и прочие
> > > Но это же делает набор правил уже *после* того, как устройство было > выставлено драйвером. > Или я что-то неправильно понимаю? > Не совсем imho: В devfs файлы устройств появлялись от вызова драйвером devfs_register. devfsd мог по ним сделать символические ссылки, но сами файлы он не трогал. В случае же udev, драйвер создает специальную структуру (она видна в /sys), и посылает uevent (через NETLINK), и udev уже создает нужную запись. Кмк, дело было так: До 2.4 все устройства создавались mkdev и драйвер привязывался к major номеру. Ненужные файлы забивали /dev, путали пользователя, имели проблемы с безопасностью (решение о пермишенах принимал автор скрипта MAKEDEV) а еще и major номера начали кончаться (их было-то всего 255). В 2.4 проблему решили devfs, позволив драйверу самому создавать устройство через devfs_register. Подробнее погуглите главу "The Device Filesystem" второго (не третьего!) издания Linux Driver Development. Стало лучше: в dev не стало несуществующих устройств и драйвер смог выбирать пермишены на файл. Однако осталась проблемы, наример пользователь всё еще не мог выбирать как назвать устройство оперируя его идентификатором. У каждой шины (PCI, USB) у устройства есть уникальные ID, и хотелось бы привязывать имена к ним. Кроме того, все существующие имена приходилось хранить в памяти ядра (невыгружаемой). Появилось желание вынести это в userspace. Всё это привело к вот такому (там много жалоб на devfs): http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf В 2.6 сделали sys, куда драйверы стали репортовать свои устройства, затем посылать uevent, который забирал udev, и на основе рулов создавал нужное устройство, а еще он по D-Bus мог сообщить об этом вашему DE, чтобы тот нарисовал красивый попап. Почитать можно тут: https://linux-kernel-labs.github.io/refs/heads/master/labs/device_model.html#sysfs Часть людей была против, вот тут их переубеждают: https://lwn.net/Articles/65197/ Затем udev смерджили с systemd:) Но тут оказалось, что udev не нравится емебдщикам и не подходит для всяких rescue mode, потому что требует нехилый userspace udev. Тогда был создан devtmpfs (тут подробно написано) https://lwn.net/Articles/330985/ Он просто брал имена (те, что драйверы репортуют в sys)и создавал для них устройства. Файловая система была создана на основе tmpfs, так что она была намного проще, и позволяла udevу работать поверх нее Естественно, все тут же сказали "мы опять изобрели devfs!" https://lwn.net/Articles/331818/ Но утверждается, что: * devtmpfs проще (сделана на основе tmpfs) * совместима с udev Видимо это и есть ответ на ваш вопрос:)
Re: DevFS и прочие
Добрый день, > > Затем разработчики Linux добавили в ядро поддержку devfs (не той, > которая используется сейчас). С ней возникли проблемы. Например, > пользовательские скрипты при загрузке должны были ожидать заполнения > иерархии и как-то синхронизироваться, необходимость явных вызовов изо > всех драйверов и т.д. Проблемы решались с переменным успехом, но система > не прижилась. > Тут наверное стоило бы рассказать, что в Devfs файл устройства создавал драйвер, пользователь на это никак не влиял. Кажется, нельзя было например попросить систему всегда давать определенное имя сетевой карте с определенным мак-адресом (сейчас через udev это легко делается) > > Современный Linux монтирует в /dev файловую систему DevTmpFS, которая > сразу отображает все перечисленные ядром устройства, и поддерживающий > различные правила и события демон udev, при необходимости, > обеспечивающий её динамическую конфигурацию из пространства пользователя. > Фишка udev еще в том, что пользователь настраивает правила, имея возможность давать устройствам имена, запускать скрипты при их появлении, запрещать какие-то устройства итд.
Re: Проблема с работой разрешения
У этого процессора встроенный GPU "UHD graphics", кажется он должен поддерживаться (но я могу ошибаться). Если проблема в XOrg, то можно утилитой randr попробовать поменять разрешение https://xorg-team.pages.debian.net/xorg/howto/use-xrandr.html Если проблема во framebuffer (в консоли) то наверное начать надо с утилиты fbset: https://manpages.debian.org/testing/fbset/fbset.1.en.html и дальше попробовать передать нужные параметры ядру. Лучше напишите вопрос на обычный debian userlist, на английском, там куда больше людей. On Wed, Jun 22, 2022 at 11:12 AM Вячеслав Мостовой wrote: > Здравствуйте. > Я инженер компании Opt-Line. > Столкнулись с проблемой при использовании debian. > На моноблоке возникла проблема с разрешением. Всегда выбирается 800 на > 600, а другие разрешения поддерживаются некорректно.( Растягиваются за > пределы экрана) > Как удалось выяснить проблема в процессоре N5095 который не > поддерживается в debian. > Можно ли ожидать появления данной поддержки и когда? > Есть ли какое то другое решение данной проблемы? > > >
