Re: [freebsd] clamav-clamd

[Eugene Grosbein]

05.02.2024 3:49, Eugene Grosbein пишет:
> 04.02.2024 23:47, Taras Heichenko пишет:
> 
>> Включение всяких дебагов показало, что судя по всему очень долго грузятся 
>> сигнатуры. А нельзя ему сказать "ты запустись, а их потом догрузишь"?
> 
> Ему нет смысла работать без сигнатур. Другое дело, что можно заставить его 
> делать это в фоне,
> в /etc/rc.conf:
> 
> clamav_clamd_enable="NO"
> 
> И кладешь в /usr/local/etc/rc.d/ дополнительный скрипт типа такого, который 
> запускает
> стартовый скрипт clamd в фоне:
> 
> #!/bin/sh
> # PROVIDE: start_clamav_clamd
> # REQUIRE: LOGIN
> # BEFORE: mail
> # KEYWORD: shutdown
> 
> case "$1" in
> *start) nohup /usr/local/etc/rc.d/clamav-clamd "$1" >/dev/null 2>&1 & ;;

Тут forcestart вместо "$1"

> esac
> #EOF

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] clamav-clamd

[Eugene Grosbein]

04.02.2024 23:47, Taras Heichenko пишет:

> Включение всяких дебагов показало, что судя по всему очень долго грузятся 
> сигнатуры. А нельзя ему сказать "ты запустись, а их потом догрузишь"?

Ему нет смысла работать без сигнатур. Другое дело, что можно заставить его 
делать это в фоне,
в /etc/rc.conf:

clamav_clamd_enable="NO"

И кладешь в /usr/local/etc/rc.d/ дополнительный скрипт типа такого, который 
запускает
стартовый скрипт clamd в фоне:

#!/bin/sh
# PROVIDE: start_clamav_clamd
# REQUIRE: LOGIN
# BEFORE: mail
# KEYWORD: shutdown

case "$1" in
*start) nohup /usr/local/etc/rc.d/clamav-clamd "$1" >/dev/null 2>&1 & ;;
esac
#EOF

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] clamav-clamd

[Eugene Grosbein]

04.02.2024 4:17, Taras Heichenko пишет:
>Hi all!
> 
> Може хтось підказати.  На сервері  13.2-RELEASE-p9 amd64 запускається 
> clamav-clamd. Запускається дуже довго. Погрався у відладку з скриптом запуску 
> і виявив, що висить він на команді
> 
>  limits -C daemon /usr/local/sbin/clamd
> 
> що, здається помітно гальмує процес завантаження. (Тобто в результаті після 
> ребуту clamd запущений, але займає це помітний час) Є якісь ідеї, на чому 
> воно висить і що з цим можна зробити?
> 

Свопится поди?

Из clamd.conf:

# Enable non-blocking (multi-threaded/concurrent) database reloads.
# This feature will temporarily load a second scanning engine while scanning
# continues using the first engine. Once loaded, the new engine takes over.
# The old engine is removed as soon as all scans using the old engine have
# completed.
# This feature requires more RAM, so this option is provided in case users are
# willing to block scans during reload in exchange for lower RAM requirements.
# Default: yes
ConcurrentDatabaseReload no


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] xscreensaver 6.07

[Eugene Grosbein]

17.10.2023 17:24, Anton Saietskii пишет:
> Вітаю, колеги.
> Якщо раптом є хтось з комітерів, хто ще читає -- подивіться, будь
> ласка, на https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274126
> У поточній версії, 6.06, є неприємний баг з вимкненням DPMS при
> запуску xscreensaver-settings, а x11@ поклали болта і навіть не
> дивляться на PR.

Прокоммитил, добавив USES=desktop-file-utils по подсказке portlint.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] MySQL find broken connection via socket

[Eugene Grosbein]

21.02.2023 22:24, Alexey Krylov пишет:

Просьба отвечать в рассылку.

> *>> Доброго дня всем.
> 
>>> MySQL сыпет в журнал
> 
>>> 2023-02-21T08:10:43.443622Z 767 [Note] Access denied for user 
>>> 'root'@'localhost' (using password: NO)
> 
>>> Это какой то из скриптов потерял свой конфиг. Подключение скорее всего 
>>> через сокет, так как tcpdump не видит трафика tcp-3306
>>> Пожалуйста, помогите советом, как найти процесс, который поломался.
> 
>> Насколько часты сыплется это в журнал? Есть какой-то период более менее 
>> заметный?
> 
> *Периода нет. На хосте свои но разные проекты. Отловить никак не получается 
> какой скрипт дергает базу.
> 
> tcpdump с сокетами не работает :(

Если при этом все проекты работают и нет жалоб пользователей, то может быть это 
какой-то ненужный скрипт :-)

Можно запустить find | grep по всем скриптам, поискать паттерны подключения к 
MySQL,
вряд ли там слишком много языков используется, а у каждого языка нынче один-два 
стандартных паттерна
подключения к базе. Ещё постоянные соединения (persistent connections) иногда 
на языке конфигов
описываются, по ним тоже можно поискать.

Или просто подождать жалоб пользователей.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] MySQL find broken connection via socket

[Eugene Grosbein]

21.02.2023 15:52, Alexey Krylov пишет:
> Доброго дня всем.
> 
> MySQL сыпет в журнал
> 
> 2023-02-21T08:10:43.443622Z 767 [Note] Access denied for user 
> 'root'@'localhost' (using password: NO)
> 
> Это какой то из скриптов потерял свой конфиг. Подключение скорее всего через 
> сокет, так как tcpdump не видит трафика tcp-3306
> Пожалуйста, помогите советом, как найти процесс, который поломался.

Насколько часты сыплется это в журнал? Есть какой-то период более менее 
заметный?


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] AWS Tech Conference

[Eugene Grosbein]

29.06.2022 22:36, Valentin Nechayev пишет:

>>> Напоминаю, что в наше неспокойное время заметная часть того, что
>>> собирается в контейнерах, поступает в виде кода всяких Go и Rust,
>>> которые даже libc обходят, а вместо этого используют свой комплект
>>> сисколлов и врапперов.
>>
>> Напоминаю:
>>
>> osrelease
>>  The string for the jail's kern.osrelease sysctl and uname -r.
>> Они и sysctl kern.osrelease фрёвый дергать не будут.
> 
> Будут.
> 
> [root@verba /usr/ports/lang/go]# objdump -d /usr/local/bin/go | fgrep sysctl 
> | head
> 00431600 :
>   431604:   0f 86 b5 00 00 00   jbe4316bf 
> 
>   43163a:   76 78   jbe4316b4 
> 
>   431666:   e8 b5 43 03 00  callq  465a20 
>   43167d:   7c 29   jl 4316a8 
> 
>   431690:   77 0c   ja 43169e 
> 
>   4316ec:   e9 0f ff ff ff  jmpq   431600 
> 
>   43178f:   e8 6c fe ff ff  callq  431600 
> 
>   4317d4:   e8 47 42 03 00  callq  465a20 
>   4319ac:   e8 6f 40 03 00  callq  465a20 
> ...
> [root@verba /usr/ports/lang/go]# uname -mrs
> FreeBSD 12.3-RELEASE-p5 amd64
> 
> Так что наличие sysctl для авторов своих аналогов libc ни капельки не секрет.

Я говорил вовсе не об sysctl как таковом, а конкретно об фрёвом
sysctl kern.osrelease в контексте обсуждаемых линуксовых Jail.

Не будут.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] AWS Tech Conference

[Eugene Grosbein]

29.06.2022 21:43, Taras Heichenko пишет:

>> Это база для.
> 
> Это хорошая база, она мне нравится. Но базы мало. Только база, это 
> маргинализация.
> А сейчас дальше чем база, очень мало.

А ты CBSD-то смотрел? Чтобы говорить "мало".


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] AWS Tech Conference

[Eugene Grosbein]

29.06.2022 20:31, Valentin Nechayev пишет:

>> ENVIRONMENT
>>  An environment variable composed of the string UNAME_ followed by any
>>  flag to the uname utility (except for -a) will allow the corresponding
>>  data to be set to the contents of the environment variable.
> 
> Осталось понять, какая доля из тех, кто спрашивает эти параметры,
> запускает внешнюю команду :)
> Напоминаю, что в наше неспокойное время заметная часть того, что
> собирается в контейнерах, поступает в виде кода всяких Go и Rust,
> которые даже libc обходят, а вместо этого используют свой комплект
> сисколлов и врапперов.

Напоминаю:

osrelease
 The string for the jail's kern.osrelease sysctl and uname -r.
osreldate
 The number for the jail's kern.osreldate and uname -K.

Они и sysctl kern.osrelease фрёвый дергать не будут. А если будут запускать 
uname,
то /etc/profile или другие способы заполнить environment ничуть не хуже.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] AWS Tech Conference

[Eugene Grosbein]

29.06.2022 19:53, Valentin Nechayev пишет:
>  Wed, Jun 29, 2022 at 16:45:30, eugen wrote about "Re: [freebsd] AWS Tech 
> Conference": 
> 
> 6. идентификация ядра (ответ на uname)
 Сразу нет. Всё-таки jail это клетки над общим ядром.
  osrelease
  The string for the jail's kern.osrelease sysctl and uname -r.
>> Это просто обманка.
> 
> Верно, для того и придумано.
> 
>> И что? Их можно в /etc/profile прописать даже.
> 
> И кто их оттуда читать будет?

Команда uname читает из своего environment.

ENVIRONMENT
 An environment variable composed of the string UNAME_ followed by any
 flag to the uname utility (except for -a) will allow the corresponding
 data to be set to the contents of the environment variable.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] AWS Tech Conference

[Eugene Grosbein]

29.06.2022 16:52, Taras Heichenko пишет:
> 
> 
>> On 29 Jun 2022, at 12:44, Eugene Grosbein  wrote:
>>
>> 29.06.2022 12:53, Taras Heichenko пишет:
>>
>>>>>> Насколько я ничего не понимаю, всего хватает.
>>>>>> В 13.1 допилили LinuxKPI, чтобы запускать современный линуксовый 
>>>>>> userland в jail,
>>>>>> включая Docker. Сам не пробовал.
>>>>>
>>>>> Вот здесь возникает вопрос: а зачем там собственно фря?
>>>>
>>>> Фря может исполнять фрёвый софт параллельно с линуксовым jail.
>>>
>>> Да, конечно. Но это не промышленное решение.
>>
>> А причем тут промышленное решение?
> 
> Это игрушка или инструмент?

Это база для.




___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] AWS Tech Conference

[Eugene Grosbein]

29.06.2022 15:11, Mykola Dzham пишет:

>>> 6. идентификация ядра (ответ на uname)
>>
>> Сразу нет. Всё-таки jail это клетки над общим ядром.
> 
> Эм
> 
> jail(8);
> 
>>  osrelease
>>  The string for the jail's kern.osrelease sysctl and uname -r.
>>
>>  osreldate
>>  The number for the jail's kern.osreldate and uname -K.

И что? Их можно в /etc/profile прописать даже. Это просто обманка.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] AWS Tech Conference

[Eugene Grosbein]

29.06.2022 12:53, Taras Heichenko пишет:

 Насколько я ничего не понимаю, всего хватает.
 В 13.1 допилили LinuxKPI, чтобы запускать современный линуксовый userland 
 в jail,
 включая Docker. Сам не пробовал.
>>>
>>> Вот здесь возникает вопрос: а зачем там собственно фря?
>>
>> Фря может исполнять фрёвый софт параллельно с линуксовым jail.
> 
> Да, конечно. Но это не промышленное решение.

А причем тут промышленное решение? Промышленное решение это совсем отдельная 
тема,
ей больше место в портах или пакетах. Насколько я слышал, такое решение 
предлагает sysutils/cbsd,
или как минимум активно движется в ту сторону. Можно спросить у 
olev...@olevole.ru,
он есть в телеграмм-чате @freebsd_ru




___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] AWS Tech Conference

[Eugene Grosbein]

On 28.06.2022 19:58, Taras Heichenko wrote:

>> Насколько я ничего не понимаю, всего хватает.
>> В 13.1 допилили LinuxKPI, чтобы запускать современный линуксовый userland в 
>> jail,
>> включая Docker. Сам не пробовал.
> 
> Вот здесь возникает вопрос: а зачем там собственно фря?

Фря может исполнять фрёвый софт параллельно с линуксовым jail.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] AWS Tech Conference

[Eugene Grosbein]

On 28.06.2022 18:32, Valentin Nechayev wrote:
> hi,
> 
>  Tue, Jun 28, 2022 at 04:14:26, eugen wrote about "Re: [freebsd] AWS Tech 
> Conference": 
> 
>> Jail это chroot плюс опционально виртуализированный сетевой стек
>> плюс запрет руту из клетки влиять на хост.
> 
> Судя по тому, что можно видеть в комплекте всяких cgroup, в опциях
> clone и так далее, параметров сильно больше:

Придумать можно неограниченное число параметров,
но перечисленное ниже явно не про jail.

> 6. идентификация ядра (ответ на uname)

Сразу нет. Всё-таки jail это клетки над общим ядром.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] anacron daemon vs cron call

[Eugene Grosbein]

On 28.06.2022 19:40, Anton Saietskii wrote:
> Собственно, проверил. Таки да -- anacron запускается, выполняет
> задания и выходит, так что в crontab не помешает. Ещё вижу одно
> преимущество скрипта перед @reboot в crontab -- в скрипте стоит
> resume. Похоже, что он также будет запускаться после выхода из S3
> (поправьте, если ошибаюсь).

Да. В rcorder(8) есть ссылка на acpiconf(8), где этот момент документирован.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] AWS Tech Conference

[Eugene Grosbein]

On 28.06.2022 13:33, Vladimir Sharun wrote:
> Привет,
> 
> Jail это chroot плюс опционально виртуализированный сетевой стек
> плюс запрет руту из клетки влиять на хост. Не виртуальная машина даже 
> близко,
> для этого bhyve.
> 
> 
> Чуть больше:
> 
>   * процессы работают в собственном jailspace назовем его так, которые 
> грохаются вместе с jail

В клетке они работают, понятия jailspace я не видел. Разумеется, убиваются при 
уничтожении клетки,
но убийство группы или групп процессов не уникальная фича для jail :-) Просто 
удобно убивать пачку
возможно неродственных процессов, согласен.

>   * affinity

Process affinity уж точно не уникальная фича клеток, cpuset универсален.

>   * Limit the number of commands from exec.*

Это о чём?

>   * Следующие sysctl'ки дают приблизительный обзор ограничений:
> 
> 
> security.bsd.see_jail_proc: 1
> security.jail.mount_tmpfs_allowed: 0
> security.jail.mount_zfs_allowed: 0
> security.jail.mount_procfs_allowed: 0
> security.jail.mount_devfs_allowed: 0
> security.jail.param.sysvshm.: 0
> security.jail.param.sysvsem.: 0
> security.jail.param.sysvmsg.: 0
> security.jail.param.allow.mount.tmpfs: 0
> security.jail.param.allow.mount.zfs: 0
> security.jail.param.allow.mount.procfs: 0
> security.jail.param.allow.mount.devfs: 0
> security.jail.param.allow.mount.: 0
> security.jail.param.allow.suser: 0
> security.jail.param.allow.unprivileged_proc_debug: 0
> security.jail.param.allow.read_msgbuf: 0
> security.jail.param.allow.reserved_ports: 0
> security.jail.param.allow.mlock: 0
> security.jail.param.allow.socket_af: 0
> security.jail.param.allow.quotas: 0
> security.jail.param.allow.chflags: 0
> security.jail.param.allow.raw_sockets: 0
> security.jail.param.allow.sysvipc: 0
> security.jail.param.allow.set_hostname: 0
> security.jail.param.ip6.saddrsel: 0
> security.jail.param.ip6.: 0
> security.jail.param.ip4.saddrsel: 0
> security.jail.param.ip4.: 0
> security.jail.param.cpuset.id: 0
> security.jail.param.host.hostid: 0
> security.jail.param.host.hostuuid: 64
> security.jail.param.host.domainname: 256
> security.jail.param.host.hostname: 256
> security.jail.param.host.: 0
> security.jail.param.children.max: 0
> security.jail.param.children.cur: 0
> security.jail.param.dying: 0
> security.jail.param.vnet: 0
> security.jail.param.persist: 0
> security.jail.param.devfs_ruleset: 0
> security.jail.param.enforce_statfs: 0
> security.jail.param.osrelease: 32
> security.jail.param.osreldate: 0
> security.jail.param.securelevel: 0
> security.jail.param.path: 1024
> security.jail.param.name: 256
> security.jail.param.parent: 0
> security.jail.param.jid: 0
> security.jail.devfs_ruleset: 0
> security.jail.enforce_statfs: 2
> security.jail.mount_allowed: 0
> security.jail.chflags_allowed: 0
> security.jail.allow_raw_sockets: 0
> security.jail.sysvipc_allowed: 0
> security.jail.socket_unixiproute_only: 1
> security.jail.set_hostname_allowed: 1
> security.jail.jail_max_af_ips: 255
> security.jail.vnet: 0

Это уже пошла детализация того же, о чем я упомянул, про ограничение влияния на 
хост (и на соседнией jail тоже).
Плюс ещё Mandatory Access Control (MAC) тоже может влиять на клетки.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] TCP vs UDP в контексте туннеля.

[Eugene Grosbein]

On 28.06.2022 09:23, Nick Kostirya via freebsd wrote:
> On Tue, 28 Jun 2022 03:03:35 +0700
> Eugene Grosbein  wrote:
> 
>> On 27.06.2022 10:11, Nick Kostirya via freebsd wrote:
>>> On Mon, 27 Jun 2022 01:36:39 +0700
>>> Eugene Grosbein  wrote:
>>>   
>>>> 25.06.2022 13:47, Nick Kostirya via freebsd пишет:  
>>>>> Привет.
>>>>>
>>>>> В туннель заворачивается на сервере X (192.168.10.1) вот так
>>>>>
>>>>> ${fwcmd} nat 2 config if vmx0 same_ports reset redirect_port udp 
>>>>> 192.168.10.111:8080 8080 redirect_port tcp 192.168.10.111:8080 8080
>>>>>
>>>>>
>>>>> На сервере Y (192.168.10.111) запросы tcpdump показывает приходят на 
>>>>> 192.168.10.111, но вот ответы...
>>>>>
>>>>> UDP ответ идет с 192.168.0.111 (вне туннеля) по внешнему интерфейсу rl0
>>>>> а
>>>>> TCP ответ идет с 192.168.10.111 (адрес туннеля), но тоже по внешнему 
>>>>> интерфейсу rl0
>>>>>
>>>>>
>>>>> Почему так? 
>>>>>
>>>>>
>>>>> Для UDP заворачиваю в туннель вот так
>>>>> ${fwcmd} add fwd 192.168.10.1 all from me 8080 to any out via rl0
>>>>>
>>>>> И все работает. Сервер видит ответ X и пересылает дальше.
>>>>>
>>>>> А вот с TCP forward не работает.
>>>>
>>>> Нужен полный вывод ipfw show без каких-либо редактирований, разве что 
>>>> можешь заменить публичные адреса.  
>>>
>>> На W.W.W.W делаю запрос, который X.X.X.X перенаправляет в тeннель 
>>> 192.168.10.1 -> 192.168.10.111
>>> # echo hello | nc -w 1 X.X.X.X 8080
>>>
>>>
>>>
>>> Ответ на дальнем конце туннеля (192.168.10.111), где стоит TCP сервер
>>>
>>>
>>> # tcpdump -A -i rl0 'port 8080'  
>>
>> Я просил вывод ipfw show, а не tcpdump.
> 
> 
> Прошу прошение.
> 
> UDP 
> 
> Начало туннеля.
> 
> # ipfw show
> 001001  34 nat 1 ip from any to me 8080 in via vmx0
> 002002  62 nat 1 ip from any 8080 to any
> 65000   563352 allow ip from any to any
> 65535 8928 1279978 deny ip from any to any
> 
> 
> 
> ${fwcmd} nat 1 config if vmx0 same_ports reset redirect_port udp 
> 192.168.10.111:8080 8080 redirect_port tcp 192.168.10.111:8080 8080
> ${fwcmd} add nat 1 ip from any to me 8080 in via vmx0
> ${fwcmd} add nat 1 ip from any 8080 to any
> 
> 
> 
> Сервер в конце туннеля
> 
> # ipfw show
> 00100   0 0 fwd 192.168.10.1 ip from 192.168.10.111 8080 to any via rl0
> 00200   131 fwd 192.168.10.1 ip from me 8080 to any out via rl0
> 65000 120 11064 allow ip from any to any
> 65535 122 10052 allow ip from any to any
> 
> 
> ${fwcmd} add fwd 192.168.10.1 all from 192.168.10.111 8080 to any via rl0
> ${fwcmd} add fwd 192.168.10.1 all from me 8080 to any out via rl0
> 
> 
> 
> TCP
> 
> Начало туннеля.
> 
> # ipfw show
> 001001  60 nat 1 ip from any to me 8080 in via vmx0

Лучше писать in recv vmx0 (хотя функционально это одно и то же).

> 002000   0 nat 1 ip from any 8080 to any

А вот тут большая ошибка: транслировать исходящие пакеты надо,
только если они уходят обратно в тот же интерфейс, то есть пропущено out xmit 
vmx0 в конце правила, добавь.

> 65000  1047636 allow ip from any to any
> 65535 8928 1279978 deny ip from any to any
> 
> Сервер в конце туннеля
> 
> # ipfw show
> 00100   4   240 fwd 192.168.10.1 ip from 192.168.10.111 8080 to any via rl0
> 00200   0 0 fwd 192.168.10.1 ip from me 8080 to any out via rl0
> 65000  63  4599 allow ip from any to any
> 65535 122 10052 allow ip from any to any

Если тебе надо безусловно направлять ответные пакеты через 192.168.10.1, то 
правило нужно только одно
и чем оно будет короче, тем лучше:

ipfw add 100 fwd 192.168.10.1 ip from any 8080 to any out

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

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] AWS Tech Conference

[Eugene Grosbein]

On 27.06.2022 15:36, Valentin Nechayev wrote:
> hi,
> 
>  Mon, Jun 27, 2022 at 11:18:53, vladimir.sharun wrote about "Re: [freebsd] 
> AWS Tech Conference": 
> 
> Вообще хотелось бы увидеть актуальную сводку "чего именно сейчас в
> FreeBSD не хватает, чтобы запустить Docker" (ну или его полноценный
> аналог).

Насколько я ничего не понимаю, всего хватает.
В 13.1 допилили LinuxKPI, чтобы запускать современный линуксовый userland в 
jail,
включая Docker. Сам не пробовал.

> Если оно есть, можно её рекламировать в плане, например, "у нас то
> же самое, но линуксовый вирус не сработает". Если нет - то понимать,
> чего именно не хватает.
> Я уровня изоляции в jail уже не понимаю совсем, что именно там есть,
> чего нет.

Jail это chroot плюс опционально виртуализированный сетевой стек
плюс запрет руту из клетки влиять на хост. Не виртуальная машина даже близко,
для этого bhyve.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] TCP vs UDP в контексте туннеля.

[Eugene Grosbein]

On 27.06.2022 10:11, Nick Kostirya via freebsd wrote:
> On Mon, 27 Jun 2022 01:36:39 +0700
> Eugene Grosbein  wrote:
> 
>> 25.06.2022 13:47, Nick Kostirya via freebsd пишет:
>>> Привет.
>>>
>>> В туннель заворачивается на сервере X (192.168.10.1) вот так
>>>
>>> ${fwcmd} nat 2 config if vmx0 same_ports reset redirect_port udp 
>>> 192.168.10.111:8080 8080 redirect_port tcp 192.168.10.111:8080 8080
>>>
>>>
>>> На сервере Y (192.168.10.111) запросы tcpdump показывает приходят на 
>>> 192.168.10.111, но вот ответы...
>>>
>>> UDP ответ идет с 192.168.0.111 (вне туннеля) по внешнему интерфейсу rl0
>>> а
>>> TCP ответ идет с 192.168.10.111 (адрес туннеля), но тоже по внешнему 
>>> интерфейсу rl0
>>>
>>>
>>> Почему так? 
>>>
>>>
>>> Для UDP заворачиваю в туннель вот так
>>> ${fwcmd} add fwd 192.168.10.1 all from me 8080 to any out via rl0
>>>
>>> И все работает. Сервер видит ответ X и пересылает дальше.
>>>
>>> А вот с TCP forward не работает.  
>>
>> Нужен полный вывод ipfw show без каких-либо редактирований, разве что можешь 
>> заменить публичные адреса.
> 
> На W.W.W.W делаю запрос, который X.X.X.X перенаправляет в тeннель 
> 192.168.10.1 -> 192.168.10.111
> # echo hello | nc -w 1 X.X.X.X 8080
> 
> 
> 
> Ответ на дальнем конце туннеля (192.168.10.111), где стоит TCP сервер
> 
> 
> # tcpdump -A -i rl0 'port 8080'

Я просил вывод ipfw show, а не tcpdump.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] TCP vs UDP в контексте туннеля.

[Eugene Grosbein]

25.06.2022 13:47, Nick Kostirya via freebsd пишет:
> Привет.
> 
> В туннель заворачивается на сервере X (192.168.10.1) вот так
> 
> ${fwcmd} nat 2 config if vmx0 same_ports reset redirect_port udp 
> 192.168.10.111:8080 8080 redirect_port tcp 192.168.10.111:8080 8080
> 
> 
> На сервере Y (192.168.10.111) запросы tcpdump показывает приходят на 
> 192.168.10.111, но вот ответы...
> 
> UDP ответ идет с 192.168.0.111 (вне туннеля) по внешнему интерфейсу rl0
> а
> TCP ответ идет с 192.168.10.111 (адрес туннеля), но тоже по внешнему 
> интерфейсу rl0
> 
> 
> Почему так? 
> 
> 
> Для UDP заворачиваю в туннель вот так
> ${fwcmd} add fwd 192.168.10.1 all from me 8080 to any out via rl0
> 
> И все работает. Сервер видит ответ X и пересылает дальше.
> 
> А вот с TCP forward не работает.

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



___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] Есть ли особенности проброса порта в туннель?

[Eugene Grosbein]

24.06.2022 17:16, Nick Kostirya via freebsd пишет:
> On Fri, 24 Jun 2022 14:30:01 +0700
> Eugene Grosbein  wrote:
> 
>>> На сервере Y с IP 192.168.12.111 в туннеле (13.1-RELEASE)
>>> Вижу только входящий пакет и все.
>>> # tcpdump -n -i ipsec0 -a 'port 8080 or port 80'
>>> 06:07:03.106586 IP X.X.X.X.62673 > 192.168.12.111.80: Flags [S], seq 
>>> 1358968744, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 
>>> 3568935363 ecr 0], length 0  
>>
>> Разница в том, что в первом случае адрес источника был X.X.X.X, а во втором 
>> 192.168.12.1.
>> Либо входящий пакет был убит файрволом на приёмной стороне, либо ответ не 
>> находит роута в туннель
>> и уходит в другой интерфейс или вообще никуда.
> 
> В ipfw разрешено для tcp все.
> 
> Таблица роутинга вот такая:
> 
> DestinationGatewayFlags Netif Expire
> defaultX.X.X.XUGS rl0
> 127.0.0.1  link#2 UH  lo0
> 192.168.0.0/24 link#1 U   rl0
> 192.168.0.111  link#1 UHS lo0
> 192.168.12.1   link#5 UH   ipsec0
> 192.168.12.111 link#5 UHS lo0
> 
> 
> Получается ответы, на запроси от X.X.X.X, хоть и пришли через тунель, уходят 
> на X.X.X.X, а не в тунель 192.168.12.1.
> 
> Но их почему-то не видно tcpdump -i rl0 'port 8080 or port 80'.

Тогда они не уходят в этот интерфейс. Вероятно, они не уходят никуда, потому 
что убиваются
уже после расшифровки в ядре.

> А почему на сервере Y в tcpdump видны запросы
> 
> 12:50:08.219710 IP X.X.X.X.41173 > 192.168.12.111.http: Flags [S], seq 
> 3645315935, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 
> 1553419922 ecr 0], length 0
> 
> Но в ipfw нет?

Вероятно, до прохода по ipfw после расшифровки пакеты не доходят.
Нужен вывод netstat -sp ipsec и netstat -sp esp

> И что означает ip в nat config ?
> Описание "Define an ip address to use for aliasing." на понятно.

Вместо if можно использовать ip.
Если использовать if, то ipfw nat берет с указанного интерфейса два параметра:
IP в качестве aliasing address (то есть, "внешнего) и MTU для PMTUD,
для отправки ICMP need-frag при необходимости.

Если же вместо if указать ip, то он будет его использовать, но ICMP need-frag 
отправлять не будет.

Что касается исходной проблемы: пора в деталях описывать, каким образом 
устанавливается IPSec-туннель:
используется ли IKE-агент? Используется ли NAT-T? Что в выводе упомянутых выше 
команд
netstat -sp ipsec и netstat -sp esp и какие счетчики растут, когда проблема 
воспроизводится повторно?

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] Есть ли особенности проброса порта в туннель?

[Eugene Grosbein]

25.06.2022 13:54, Valentin Nechayev пишет:
> hi,
> 
>  Fri, Jun 24, 2022 at 14:30:01, eugen wrote about "Re: [freebsd] Есть ли 
> особенности проброса порта в туннель?": 
> 
>> Только размер пакета: часто на туннеле меньше MTU и если у пакета выставлен 
>> DF-бит
>> и пакет больше next-hop MTU, он не пролезет.
> 
> А needfrag оно вернёт назад в этом случае?

Вернет.

 

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] Есть ли особенности проброса порта в туннель?

[Eugene Grosbein]

24.06.2022 10:35, Nick Kostirya via freebsd пишет:
> Привет.
> 
> У меня вопрос: есть ли особенности проброса порта в туннель?

Только размер пакета: часто на туннеле меньше MTU и если у пакета выставлен 
DF-бит
и пакет больше next-hop MTU, он не пролезет. Ещё FreeBSD пока не умеет роутить
комбинированные LRO пакеты в IPSec, если суммарный размер "чанка" больше MTU 
IPSec-туннеля,
но это не твой случай. Если же всё пролазит, то проблем не должно быть
при условии следования документации.

> У сервера X (12.3-RELEASE-p5)
> 
> ${fwcmd} nat 1 config if vmx0 redirect_port tcp 192.168.12.111:80 8080
> ${fwcmd} add nat 1 ip from any to any 8080
> (упростил уже до такого)
> 
> Делаю для проверки
> echo hello | nc X.X.X.X 8080
> 
> На сервере Y с IP 192.168.12.111 в туннеле (13.1-RELEASE)
> Вижу только входящий пакет и все.
> # tcpdump -n -i ipsec0 -a 'port 8080 or port 80'
> 06:07:03.106586 IP X.X.X.X.62673 > 192.168.12.111.80: Flags [S], seq 
> 1358968744, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 
> 3568935363 ecr 0], length 0

Ты увидел успешно расшированный пакет на приёмной стороне,
а это значит, что к серверу X вопросов никаких быть не может,
он всё правильно отфорвардил и даже не налажал с шифрованием.

> Когда на сервере X делаю запрос напрямую по туннелю без redirect_port
> 
> echo hello | nc 192.168.12.111 80
> 
> То на сервере Y вижу сразу и ответ
> 
> # tcpdump -n -i ipsec0 -a 'port 8080 or port 80'
> 06:28:41.232011 IP 192.168.12.1.49774 > 192.168.12.111.80: Flags [S], seq 
> 1477405936, win 65535, options [mss 1360,nop,wscale 6,sackOK,TS val 878248554 
> ecr 0], length 0
> 06:28:41.232045 IP 192.168.12.111.80 > 192.168.12.1.49774: Flags [S.], seq 
> 3253001398, ack 1477405937, win 65535, options [mss 1360,nop,wscale 
> 6,sackOK,TS val 2263718684 ecr 878248554], length 0
> 
> Может что-то есть такое, что я не знаю?
> 
> И там и там net.inet.ip.forwarding=1

Разница в том, что в первом случае адрес источника был X.X.X.X, а во втором 
192.168.12.1.
Либо входящий пакет был убит файрволом на приёмной стороне, либо ответ не 
находит роута в туннель
и уходит в другой интерфейс или вообще никуда.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] Туннель с клиентом за натом

[Eugene Grosbein]

22.06.2022 12:49, Nick Kostirya via freebsd пишет:
> On Wed, 22 Jun 2022 10:38:36 +0700
> Eugene Grosbein  wrote:
> 
>> 22.06.2022 9:34, Nick Kostirya via freebsd пишет:
>>> Привет.
>>>
>>> Вопрос про туннель с клиентом за натом.
>>>
>>>
>>> Сервер: X.X.X.X 192.168.12.1  (FreeBSD 12.3)
>>> NAT:Y.Y.Y.Y   192.168.0.1
>>> Слиент:   192.168.0.5   192.168.12.5  (FreeBSD 12.3)
>>>
>>>
>>> На сервере (X.X.X.X):
>>>
>>> ifconfig gif0 create
>>> ifconfig gif0 inet tunnel X.X.X.X Y.Y.Y.Y
>>> ifconfig gif0 inet 192.168.12.1/24 192.168.12.5
>>>
>>>
>>> На клиенте (192.168.0.5):
>>>
>>> ifconfig gif0 create
>>> ifconfig gif0 inet tunnel 192.168.0.5 X.X.X.X
>>> ifconfig gif0 inet 192.168.12.5/24 192.168.12.1
>>>
>>>
>>> TCP - работает, а вот UDP и ICMP дают дубликати.
>>>
>>> При этом tcpdump показывает, что UDP уже на gif0 интерфейсе сервера, а ICMP 
>>> echo дает дубликати ответа, видные tcpdump на клиенте, если пинговать с 
>>> клиента и наоборот.
>>>
>>> Аналогичная картина наблюдается для ipsec.
>>>
>>> Как это объяснить и исправить?
>>>
>>> Спасибо.  
>>
>> не надо художественно излагать показания tcpdump. Их надо показывать.
>> И ещё очень важно, что за роутер делает NAT. Потому что не любой NAT 
>> отроутит инкапсуляцию gif/IPIP,
>> а если она дополнительно обёрнута ещё во что-то типа UDP (как это делает 
>> IPSec NAT-T),
>> то это надо тоже явным образом описывать.
>>
>> Потому что как сейчас описано - ничо не понятно.
> 
> 
> 
> UDP
> 
> 
> На клиенте
> # echo hello | nc -u 192.168.12.1 
> 
> # tcpdump -i gif0
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on gif0, link-type NULL (BSD loopback), capture size 262144 bytes
> 08:42:41.200475 IP 192.168.12.5.14623 > 192.168.12.1.: UDP, length 6
> 
> 
> На сервере получаю
> # nc -u -l 
> hello
> hello
> 
> 
> # tcpdump -i gif0
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on gif0, link-type NULL (BSD loopback), capture size 262144 bytes
> 07:42:40.938382 IP 192.168.12.5.14623 > 192.168.12.1.: UDP, length 6
> 07:42:40.939678 IP 192.168.12.5.14623 > 192.168.12.1.: UDP, length 6
> 
> 
> ---
> 
> Ping
> 
> 
> На клиенте.
> 
> 
> # ping -c 3 192.168.12.1
> PING 192.168.12.1 (192.168.12.1): 56 data bytes
> 64 bytes from 192.168.12.1: icmp_seq=0 ttl=64 time=112.012 ms
> 64 bytes from 192.168.12.1: icmp_seq=0 ttl=64 time=113.694 ms (DUP!)
> 64 bytes from 192.168.12.1: icmp_seq=1 ttl=64 time=112.483 ms
> 64 bytes from 192.168.12.1: icmp_seq=1 ttl=64 time=113.131 ms (DUP!)
> 64 bytes from 192.168.12.1: icmp_seq=2 ttl=64 time=114.567 ms
> 
> --- 192.168.12.1 ping statistics ---
> 3 packets transmitted, 3 packets received, +2 duplicates, 0.0% packet loss
> round-trip min/avg/max/stddev = 112.012/113.177/114.567/0.899 ms
> 
> 
> #  tcpdump -i gif0
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on gif0, link-type NULL (BSD loopback), capture size 262144 bytes
> 08:22:30.774131 IP 192.168.12.5 > 192.168.12.1: ICMP echo request, id 39435, 
> seq 0, length 64
> 08:22:30.886033 IP 192.168.12.1 > 192.168.12.5: ICMP echo reply, id 39435, 
> seq 0, length 64
> 08:22:30.887670 IP 192.168.12.1 > 192.168.12.5: ICMP echo reply, id 39435, 
> seq 0, length 64
> 08:22:31.798535 IP 192.168.12.5 > 192.168.12.1: ICMP echo request, id 39435, 
> seq 1, length 64
> 08:22:31.910871 IP 192.168.12.1 > 192.168.12.5: ICMP echo reply, id 39435, 
> seq 1, length 64
> 08:22:31.911573 IP 192.168.12.1 > 192.168.12.5: ICMP echo reply, id 39435, 
> seq 1, length 64
> 08:22:32.807997 IP 192.168.12.5 > 192.168.12.1: ICMP echo request, id 39435, 
> seq 2, length 64
> 08:22:32.922373 IP 192.168.12.1 > 192.168.12.5: ICMP echo reply, id 39435, 
> seq 2, length 64
> 08:22:32.923572 IP 192.168.12.1 > 192.168.12.5: ICMP echo reply, id 39435, 
> seq 2, length 64
> 
> 
> На сервере
> 
> # tcpdump -i gif0
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on gif0, link-type NULL (BSD loopback), capture size 262144 bytes
> 07:22:30.566485 IP 192.168.12.5 > 192.168.12.1: ICMP echo request, id 39435, 
> seq 0, length 64
> 07:22:30.566501 IP 192.168.12.1 > 192.168.12.5: ICMP echo reply, id 39435, 
> seq 0, length 64
> 0

Re: [freebsd] Туннель с клиентом за натом

[Eugene Grosbein]

22.06.2022 9:34, Nick Kostirya via freebsd пишет:
> Привет.
> 
> Вопрос про туннель с клиентом за натом.
> 
> 
> Сервер: X.X.X.X 192.168.12.1  (FreeBSD 12.3)
> NAT:Y.Y.Y.Y   192.168.0.1
> Слиент:   192.168.0.5   192.168.12.5  (FreeBSD 12.3)
> 
> 
> На сервере (X.X.X.X):
> 
> ifconfig gif0 create
> ifconfig gif0 inet tunnel X.X.X.X Y.Y.Y.Y
> ifconfig gif0 inet 192.168.12.1/24 192.168.12.5
> 
> 
> На клиенте (192.168.0.5):
> 
> ifconfig gif0 create
> ifconfig gif0 inet tunnel 192.168.0.5 X.X.X.X
> ifconfig gif0 inet 192.168.12.5/24 192.168.12.1
> 
> 
> TCP - работает, а вот UDP и ICMP дают дубликати.
> 
> При этом tcpdump показывает, что UDP уже на gif0 интерфейсе сервера, а ICMP 
> echo дает дубликати ответа, видные tcpdump на клиенте, если пинговать с 
> клиента и наоборот.
> 
> Аналогичная картина наблюдается для ipsec.
> 
> Как это объяснить и исправить?
> 
> Спасибо.

не надо художественно излагать показания tcpdump. Их надо показывать.
И ещё очень важно, что за роутер делает NAT. Потому что не любой NAT отроутит 
инкапсуляцию gif/IPIP,
а если она дополнительно обёрнута ещё во что-то типа UDP (как это делает IPSec 
NAT-T),
то это надо тоже явным образом описывать.

Потому что как сейчас описано - ничо не понятно.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] zfs

[Eugene Grosbein]

14.06.2022 19:50, forumforeign пишет:
> 13.06.2022 21:44, Eugene Grosbein пише:
>> Не надо было так делать. Есть гораздо более простой и быстрый путь:
>> добавить второй диск в существующий пул командой zpool attach poolname 
>> old_device new_device
>>
>> Это делает пул зеркалом. Надо дождаться окончания зеркалирования данных,
>> проверяя прогресс командой zpool status. Затем можно удалить старый диск из 
>> пула
>> командой zpool detach.
>>  
> 
> Вот тут я бы советовал делать не detach, в zpool split: у вас будет 2 
> одинаковых пула, но с разными названиями. Дальше на всякий случай поставить 
> загрузчик на второй пул и можно уже орудовать пулами отдельно, не зависимо 
> друг от друга.

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


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] zfs import

[Eugene Grosbein]

14.06.2022 17:32, Nick Kostirya via freebsd wrote:

> On Tue, 14 Jun 2022 01:44:22 +0700
> Eugene Grosbein  wrote:
> 
>> 13.06.2022 22:57, Nick Kostirya via freebsd пишет:
>>> On Mon, 13 Jun 2022 18:39:41 +0300
>>> Владимир Друзенко via freebsd  wrote:  
>>>> Nick Kostirya via freebsd писал(а) 2022-06-13 17:52:  
>>>>>
>>>>> Вопрос про zfs. FreeBSD 13.1
>>>>> Есть диск с zfs (созданный bsdinstall).
>>>>> Затем добавили еще диск с целью перенести на нее систему, а второй
>>>>> оставить для разных больших файлов.
>>>>> Загрузился с флешки и bsdinstall создал на весь диск zfs и установил.
>>>>> В биосе сказал грузиться с нового диско, но FreeBSD все равно
>>>>> грузиться со старого диска.  
>>
>> Не надо было так делать. Есть гораздо более простой и быстрый путь:
>> добавить второй диск в существующий пул командой zpool attach poolname 
>> old_device new_device

[skip]

>> У пулов кроме имени есть уникальные ID, импортировать пул с тем же именем 
>> можно вручную по ID.
>> man zpool-import.
> 
> Импортировать по ID получилось, если загрузиться с install флешки.
> А при загрузке с диска один пулл, наверное, ложиться поверх второго.
> Когда их назвал разными именами, то при загрузке импортировался только пулл с 
> диска, с которого шла загрузка.
> Почему, если имена совпадаю, загрузчик лезет в другой диск - не понятно.

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

> Далее возник вопрос, как добраться до данных второго диска.

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


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] zfs

[Eugene Grosbein]

13.06.2022 22:57, Nick Kostirya via freebsd пишет:
> On Mon, 13 Jun 2022 18:39:41 +0300
> Владимир Друзенко via freebsd  wrote:
>> Nick Kostirya via freebsd писал(а) 2022-06-13 17:52:
>>>
>>> Вопрос про zfs. FreeBSD 13.1
>>> Есть диск с zfs (созданный bsdinstall).
>>> Затем добавили еще диск с целью перенести на нее систему, а второй
>>> оставить для разных больших файлов.
>>> Загрузился с флешки и bsdinstall создал на весь диск zfs и установил.
>>> В биосе сказал грузиться с нового диско, но FreeBSD все равно
>>> грузиться со старого диска.

Не надо было так делать. Есть гораздо более простой и быстрый путь:
добавить второй диск в существующий пул командой zpool attach poolname 
old_device new_device

Это делает пул зеркалом. Надо дождаться окончания зеркалирования данных,
проверяя прогресс командой zpool status. Затем можно удалить старый диск из пула
командой zpool detach.

Предварительно почитать man zpool-attach и man zpool-detach.
Важно не спутать с командой zpool add, которая тоже добавляет диск в пул,
но делает из пула не зеркало, а аналог gconcat, когда объём пула становится
суммарным объёмом двух дисков, данные распределяются по всему объёму и такой
пул уже невозможно разобрать потом, только через спасение данных и уничтожение 
пула целиком.

>>> Что еще нужно подкрутить?  
>>
>> Название рутового пула случайно не одинаковое?
> 
> Ой, оба из под bsdinstall, значит одинаковые. А как выкрутиться в этой 
> ситуации?
> 
> Читаю про ZFS: все про зеркала рассказывают...
> А как же поступают в такой ситуации: вставил диск с другой компьютера что-бы 
> данные скопировать?

У пулов кроме имени есть уникальные ID, импортировать пул с тем же именем можно 
вручную по ID.
man zpool-import.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] pkg

[Eugene Grosbein]

11.06.2022 19:19, Taras Heichenko пишет:
> Спасибо за подробный ответ. Фактически если какой-то пакет не может быть 
> собран локально,
> то приходится использовать  пекеджи, а не порты. (Ну это конечно если не 
> собрать на другой машине
> пекедж под эту архитектуру и зависимости, что тоже может оказаться весьма 
> сексуальным занятием.)

Когда то давно могло оказаться. Сейчас уже нет, это всё рутинно и скучно:
ставишь ports-mgmt/poudriere, говоришь ему список пакетов и под какую 
архитектуру собирать
и он тебе создаёт локальный репозиторий с готовыми пакетами, из которого можно 
сразу ставить.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] pkg (was: Ржавый)

[Eugene Grosbein]

11.06.2022 16:42, Taras Heichenko пишет:
> 
> 
>> On 10 Jun 2022, at 15:32, Anton Saietskii  wrote:
>>
>> Мда, "нетекущий" ржавый жрёт памяти на порядки больше, чем безб-жно текущий 
>> С...
> 
> Сорри, за дурацкий вопрос – давно не пользовался pkg для установки чего-либо. 
> А может
> кто-то объяснить, а почему команда
> 
> pkg install rust
> предлагает удалить вот такой список пакетов (вопрос собственно не в том, 
> почему список именно
> такой, а в том, зачем это все удалять, чтобы поставить rust из пекеджа)?
>   avahi-app: 0.8
>   cairo: 1.17.4,3
>   cups: 2.3.3op2
>   dbus-glib: 0.112
>   ghostscript9-agpl-base: 9.55.0
>   glib: 2.70.4_5,2
>   gnupg: 2.3.3_3
>   gnutls: 3.7.4
>   gobject-introspection: 1.70.0,1
>   gpgme: 1.17.1
>   graphviz: 2.50.0
>   harfbuzz: 4.0.0
>   mutt: 2.2.3
>   p11-kit: 0.24.1
>   pango: 1.50.4
>   portupgrade: 2.4.16,2
>   py38-cffi: 1.15.0
>   py38-cryptography: 3.3.2
>   py38-openssl: 20.0.1
>   py38-recommonmark: 0.5.0_2
>   py38-requests: 2.25.1
>   py38-sphinx: 4.3.1,1
>   py38-urllib3: 1.26.8,1
>   ruby: 2.7.6,1
>   ruby27-bdb: 0.6.6_8
>   ruby27-gems: 3.3.7_1
>   rubygem-psych: 4.0.3
>   rubygem-rdoc: 6.4.0
>   rubygem-stringio: 3.0.1
>   tex-basic-engines: 20210325
>   tex-web2c: 20210325

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

Например, в пакете rust прописана зависимость от *конкретной* версии пакета 
curl.
Если у вас curl установлен любой другой версии, pkg попытается удалить curl
и установить пакет curl именно той версии, которая прописана в зависимости
устанавливаемого пакета rust. А так как от curl нынче зависит много всего,
то pkg будет вынужден удалить и всё, что зависит от curl, а так же всё,
что зависит от тех пакетов и так далее, и заменить их на версии из того же 
репозитория,
откуда ставятся rust и curl.

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

Например, установленный пакет даёт /usr/local/lib/libcurl.so.4
а в целевом пакете бинарники слинкованы с другой версией либы и просто не 
запустятся.
Опять же можно в крайнем случае использовать libmap.conf(5) и заставить их таки 
запуститься,
но это чревато разнообразными глюками и даже сегфолтами.





___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] Ржавый

[Eugene Grosbein]

10.06.2022 18:50, Taras Heichenko пишет:
> Hi!
> Есть виртуальная машинка с
> FreeBSD 12.3-RELEASE r371126 GENERIC  amd64
> На ней не собирается rust. Всякие make clean, обновления портов и прочие 
> стучания по 
> колесам и хлопанья багажником не помогают. История заканчивается одинаково
> 
> error: build failed
> command did not execute successfully: 
> "/usr/ports/lang/rust/work/bootstrap/bin/cargo" "build" "--target" 
> "x86_64-unknown-freebsd" "-Zbinary-dep-depinfo" "-j" "2" "-v" "-v" 
> "--release" "--frozen" "--features" "llvm max_level_info" "--manifest-path" 
> "/usr/ports/lang/rust/work/rustc-1.61.0-src/compiler/rustc/Cargo.toml" 
> "--message-format" "json-render-diagnostics"
> expected success, got: exit status: 101
> Traceback (most recent call last):
>   File "x.py", line 27, in 
> bootstrap.main()
>   File 
> "/usr/ports/lang/rust/work/rustc-1.61.0-src/src/bootstrap/bootstrap.py", line 
> 1324, in main
> bootstrap(help_triggered)
>   File 
> "/usr/ports/lang/rust/work/rustc-1.61.0-src/src/bootstrap/bootstrap.py", line 
> 1310, in bootstrap
> run(args, env=env, verbose=build.verbose, is_bootstrap=True)
>   File 
> "/usr/ports/lang/rust/work/rustc-1.61.0-src/src/bootstrap/bootstrap.py", line 
> 185, in run
> raise RuntimeError(err)
> RuntimeError: failed to run: 
> /usr/ports/lang/rust/work/_build/bootstrap/debug/bootstrap dist --jobs=2
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/ports/lang/rust
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/lang/rust
> 
> При том, что на другой машине (не виртуальной а физической, и с i386 
> архитектурой) собрался без проблем.
> Есть какие-то идеи, что с этим можно сделать?

Памяти много? Нет ничего подозрительного в dmesg?
Оно у тебя ругается на ошибку запуска 
/usr/ports/lang/rust/work/_build/bootstrap/debug/bootstrap
который генерируется в процессе сборки порта и являет собой огромный бинарник.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

On Sun, Jan 23, 2022 at 01:53:30PM +0200, Anton Saietskii wrote:

> > Не исключён баг в BIOS, так как биосописатели тестируют свой код,
> > я уверен, только на Windows разных версий и паре-тройке линуксов может
> > быть.
> > Не представляю, как это дебажить тогда. Можно попробовать вместо этого
> > в boot2 и его конфиг /boot.config добавить новый флаг для отключения
> > zfs_probing, либо в сам loader. Сделать workaround для такого железа
> > и случая, когда искать ZFS на removable drives не нужно.
> >
> А зачем так сложно? WITHOUT_LOADER_ZFS же.

Для установки системы на такое железо не должно требоваться пересборок,
весь код должен быть в загрузчике из коробки и активироваться флагами.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

On Sun, Jan 23, 2022 at 01:33:21AM +, sp...@itl.ua wrote:

> 21 января 2022 г., 9:24, "Eugene Grosbein"  написал:
> > 
> > Загрузчик от 11.2 работает.
> 
> Вместо одного bd_int13probe() поставила цикл из сотни вызовов, и 11.2 тоже 
> свалилася.
> Просто без zfs probing этот int 13h вызываеся всего 2-3 раза, так что 
> вероятность крэша очень мала.
> А при zfs probing - десятки, поэтому всплыло именно на нем.
> 
> BTW, bd_int13probe() не использует никакую память.

Не исключён баг в BIOS, так как биосописатели тестируют свой код,
я уверен, только на Windows разных версий и паре-тройке линуксов может быть.
Не представляю, как это дебажить тогда. Можно попробовать вместо этого
в boot2 и его конфиг /boot.config добавить новый флаг для отключения
zfs_probing, либо в сам loader. Сделать workaround для такого железа
и случая, когда искать ZFS на removable drives не нужно.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

On Sat, Jan 22, 2022 at 05:48:17PM +, sp...@itl.ua wrote:
> 21 января 2022 г., 9:24, "Eugene Grosbein"  написал:
> > 
> > Загрузчик от 11.2 работает.
> 
> Заглянула в него printf'ом - оказывается он не вызывает zfs probing.
> А именно на этом этапе и падает у меня загрузчик от 12.3.
> 
> Возможно, сам по себе zfs probing ни при чем, просто во время него
> много раз вызывается процедура чтения флешки, и одна из них крешится.

Тут полно вариантов. zfs_probing может адресовать больше памяти,
чем отмаплено, или там утечка, или ещё что. Всё это больше похоже
на некорректную работу с памятью.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

On 22.01.2022 02:40, Paul Tatarenko wrote:

> On 21.01.2022 9:24, Eugene Grosbein wrote:
>> 21.01.2022 3:40, Paul Tatarenko пишет:
>>
>>> А могут быть просто аппаратные проблемы с конкретной машиной (BIOS-ом)? 
>>> Микросхема битая или память? Или я пропустил проверку на таком же железе?
>> Загрузчик от 11.2 работает.
>>
>> У меня тоже был случаей с арендованным в Hetzner сервером Dell,
>> когда в первый раз ставил тогда актуальную 11.1, не использовал инсталлятор 
>> для разбиения диска,
>> а вышел в shell и разбивал всё сам при помощи gpart, сам ставил все 
>> загрузчики,
>> создавал пул ZFS, скачивал на него дистрибутивные .txz и распаковывал их.
>> И все эти команды запротоколировал.
>>
>> Через несколько лет понадобилось на такое же железо под те же цели поставить 
>> второй раз там же в Hetzner,
>> но уже 12.1 и оно, конечно, всё установилось, но не загружалось - висло. Так 
>> как мне было надо быстро,
>> то я просто снова загрузился с инсталляционного образа, скачал старые 
>> загрузчики от 11.1 и они
>> прекрасно грузили 12.1 - так и оставил, потому что экспериментировать на 
>> сервере клиента возможности не было.
>> А раз нет возможности проверять фиксы на железе, то и репортить не стал 
>> тогда.
> 
> "Такое же железо" тоже може оказаться "разным". Версии прошивок были те же?

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

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

21.01.2022 3:40, Paul Tatarenko пишет:

> А могут быть просто аппаратные проблемы с конкретной машиной (BIOS-ом)? 
> Микросхема битая или память? Или я пропустил проверку на таком же железе?

Загрузчик от 11.2 работает.

У меня тоже был случаей с арендованным в Hetzner сервером Dell,
когда в первый раз ставил тогда актуальную 11.1, не использовал инсталлятор для 
разбиения диска,
а вышел в shell и разбивал всё сам при помощи gpart, сам ставил все загрузчики,
создавал пул ZFS, скачивал на него дистрибутивные .txz и распаковывал их.
И все эти команды запротоколировал.

Через несколько лет понадобилось на такое же железо под те же цели поставить 
второй раз там же в Hetzner,
но уже 12.1 и оно, конечно, всё установилось, но не загружалось - висло. Так 
как мне было надо быстро,
то я просто снова загрузился с инсталляционного образа, скачал старые 
загрузчики от 11.1 и они
прекрасно грузили 12.1 - так и оставил, потому что экспериментировать на 
сервере клиента возможности не было.
А раз нет возможности проверять фиксы на железе, то и репортить не стал тогда.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

21.01.2022 0:04, sp...@itl.ua wrote:

>>> Выходит, крешится биосовский interrupt handler?
>>
>> Это ничему не противоречит. Если loader от 11.2 вызывает BIOS так, что BIOS 
>> отрабатывает чисто,
>> а более свежий loader вызывает BIOS так, что внутри BIOS всё ломается,
>> то нужно заточить наш loader, чтобы он был совместим с такими BIOS-ами.
> 
> Разумеется, workarounds никто не отменял. Но хотечется понимать, на чьей 
> стороне проблема.
> По идее должен же interrupt handler быть устойчивым к любому набору аргументов
> (значениям регистров, стека/etc) и возвращаться хотя бы с ошибкой? Или нет?

Не совсем. Некоторые вызовы BIOS работают только в real mode, некоторые только 
в protected mode,
некоторые в обоих. У нас loader переключает процессор в protected mode,
то есть когда память адресуется как виртуальная и мапится в физическую.
Из-за мапинга тоже вполне может быть креш.

Это если не говорить об тупо багах в коде BIOS. А баги есть везде.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

20.01.2022 22:11, sp...@itl.ua пишет:
> 3 января 2022 г., 4:44, "Eugene Grosbein"  написал:
> 
>>
>> Это всё надо писать в PR комментарием.
> 
> 
> Раскопки привели к тому, что креш происходит внутри bd_edd_io(), в котором
> нечему крешиться кроме v86int(), в котором вроде бы нечему крешиться кроме
> int $INT_V86
> 
> Выходит, крешится биосовский interrupt handler?

Это ничему не противоречит. Если loader от 11.2 вызывает BIOS так, что BIOS 
отрабатывает чисто,
а более свежий loader вызывает BIOS так, что внутри BIOS всё ломается,
то нужно заточить наш loader, чтобы он был совместим с такими BIOS-ами.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

03.01.2022 16:14, sp...@itl.ua пишет:
> 3 января 2022 г., 3:45, "Eugene Grosbein"  написал:
> 
>> 02.01.2022 20:14, sp...@itl.ua пишет:
>>
>>> Я не знаю, как надо было сделать, но точно не так.
>>> Ради того, чтобы вернуть доступ к полмегабайту (неумно отобранный ранее),
>>> смапим повторно 16G, из которых будут доступны только эти полмегабайта,
>>> и сдвинем 8G второй планки по адресному пространству, увеличив бардак еще 
>>> больше.
>>> Вот в этом месте KISS не только вышел из чата, но и застрелился.
>>
>> Сегменты ещё и пересекаться могут, и несортированным списокм отдаваться.
> 
> Это какой-то трэш...
> И наверняка это еще не все сюрпризы, так как я пока не нашла объяснение тому 
> факту,
> что на моей машинке "куча" выпадает на один из "выкушенных" сегментов, судя по
> выводу команд biosmem и smap в loader'е. Или это был не "вышушенный" сегмент,
> а наоборот биос предлагает его использовать? Фиг разберешься в этом 
> творении...

Ну я же кидал ссылку, могу продублировать:
https://wiki.osdev.org/Detecting_Memory_(x86)#Detecting_Upper_Memory

Там описано пять типов сегментов:
Type 1: Usable (normal) RAM
Type 2: Reserved - unusable
Type 3: ACPI reclaimable memory
Type 4: ACPI NVS memory
Type 5: Area containing bad memory 

Эти типы BIOS возвращает, а loader анализирует.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

03.01.2022 5:46, sp...@itl.ua пишет:

> И еще одна.
> Как я уже говорила, с HDD система грузится и в AHCI.
> Уточнение: она грузится в AHCI только если не вставлена флешка.
> Если флешка вставлена, и выбран режим AHCI, загрузка с диска
> точно так же крешится, как и загрузка с флешки.
> 
> Это все верно при установленной опции "USB legacy support".
> Если ее убрать, система с диска грузится в AHCI и со вставленной флешкой.
> Но флешка тогда не появляется ни в биосовском boot menu, ни в фревом.
> 
> Выходит, крэш происходит на этапе:
> 
> BIOS drive D: is disk1
> 
> Т.е. когда сочетаются три условия:
> 1) вставлена флешка
> 2) режим AHCI
> 3) loader видит флешку (как drive D)

Это всё надо писать в PR комментарием.



___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

02.01.2022 20:14, sp...@itl.ua пишет:

> Я не знаю, как надо было сделать, но точно не так.
> Ради того, чтобы вернуть доступ к полмегабайту (неумно отобранный ранее),
> смапим повторно 16G, из которых будут доступны только эти полмегабайта,
> и сдвинем 8G второй планки по адресному пространству, увеличив бардак еще 
> больше. 
> Вот в этом месте KISS не только вышел из чата, но и застрелился.

Сегменты ещё и пересекаться могут, и несортированным списокм отдаваться.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

01.01.2022 21:04, sp...@itl.ua пишет:

> Разобралась, но это же кошмар...
> Принцип KISS вышел из чата.

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


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

01.01.2022 0:28, sp...@itl.ua пишет:
> 31 декабря 2021 г., 18:49, "Eugene Grosbein"  написал:
> 
>> 31.12.2021 23:00, sp...@itl.ua пишет:
>>
>>> 31 декабря 2021 г., 17:53, "Anton Saietskii" >> >> 
>>> написал:
>>>
>>> *без сарказма* Я вот не помню -- а кто-то обещал, что там будет видна вся 
>>> память?
>>>
>>> Мне - нет :)
>>> Но на другом ноутбуке в этом месте показывается около 2G (столько и есть)
>>>
>>> А что тогда значит это второе число? (631kB/523264kB)
>>
>> Когда загрузчик определяет, сколько памяти ему можно использовать
>> под свою работу (в частности, для malloc), он использует сервис BIOS для 
>> этого:
>>
>> https://wiki.osdev.org/Detecting_Memory_(x86)#Detecting_Upper_Memory
>>
>> Так как BIOS резервирует часть адресного пространства для различных 
>> устройств,
>> то оставшаяся доступная память может быть разбита на "сегменты" разного 
>> размера.
>>
>> Для упрощения кода загрузчик ищет непрерывный сегмент подходящего размера.
>> Обычно это сегмент, который начинается со второго мегабайта, то есть с начала
>> Extended memory в терминах MS-DOS.
>>
>> Второе число это размер найденного сегмента, в котором будет располагатся,
>> в частности, "куча" загрузчика (heap/malloc).
> 
> Аг, вот оно что.
> А в dmesg.boot сообщения между real memory и available memory - это этот же 
> список
> доступных сегментов?

В основе наверняка да, но в dmesg.boot идут сообщения от ядра, а не загрузчика
и теоретически возможны некоторые расхождения, потому что BIOS может показывать
сегменты разных типов, не только доступных для использования непосредственно,
так что загрузчик/ядро могут не одинаково к ним относиться.

> Интересно, почему мой биос подробил память аж на 6 кусков (в вашем примере 
> всего 3).

Потому что железо другое.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

31.12.2021 23:00, sp...@itl.ua пишет:
> 
> 
> 31 декабря 2021 г., 17:53, "Anton Saietskii"  >
>  написал:
> 
> *без сарказма* Я вот не помню -- а кто-то обещал, что там будет видна вся 
> память?
> 
> 
> Мне - нет :)
> Но на другом ноутбуке в этом месте показывается около 2G (столько и есть)
> 
> А что тогда значит это второе число? (631kB/523264kB)

Когда загрузчик определяет, сколько памяти ему можно использовать
под свою работу (в частности, для malloc), он использует сервис BIOS для этого:

https://wiki.osdev.org/Detecting_Memory_(x86)#Detecting_Upper_Memory

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

Для упрощения кода загрузчик ищет непрерывный сегмент подходящего размера.
Обычно это сегмент, который начинается со второго мегабайта, то есть с начала
Extended memory в терминах MS-DOS.

Второе число это размер найденного сегмента, в котором будет располагатся,
в частности, "куча" загрузчика (heap/malloc).


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

31.12.2021 23:03, sp...@itl.ua пишет:
> 31 декабря 2021 г., 17:48, "Eugene Grosbein"  написал:
> 
>> 29.12.2021 23:17, sp...@itl.ua пишет:
>>
>>>> Первым делом завести PR в багзилле и туда все эти данные (все попытки с 
>>>> разными настройками),
>>>> включая инфу о работе 11.2
>>>
>>> Две новости.
>>> 1) Движения по PR нет (договорились с Toomas Soome, что он пришлет тестовый 
>>> код, а я проверю его, и
>>> он пропал).
>>
>> Надо напоминать, у человека может быть много других дел. Напомнить через 
>> неделю-две не считается
>> невежливым.
> 
> Может, он рассчитывал, что появятся еще наступившие на этот баг и отпишутся...
> Anyway, написала вчера, сообщив открытие, что креша нет при режиме IDE.

Надо ещё добавить, что при загрузке с HDD креша нет и при AHCI.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

29.12.2021 23:17, sp...@itl.ua пишет:

>> Первым делом завести PR в багзилле и туда все эти данные (все попытки с 
>> разными настройками),
>> включая инфу о работе 11.2
> 
> Две новости.
> 1) Движения по PR нет (договорились с Toomas Soome, что он пришлет тестовый 
> код, а я проверю его, и он пропал).

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


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

31.12.2021 18:06, sp...@itl.ua пишет:

> CPU: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz (2594.16-MHz 686-class CPU)
> 
> real memory  = 4294967296 (4096 MB)
> Physical memory chunk(s):
> 0x1000 - 0x0009cfff, 638976 bytes (156 pages)
> 0x0010 - 0x007f, 7340032 bytes (1792 pages)
> 0x0242a000 - 0x1fff, 498950144 bytes (121814 pages)
> 0x2020 - 0x40003fff, 534790144 bytes (130564 pages)
> 0x40005000 - 0xb5754fff, 1970601984 bytes (481104 pages)
> 0xb9c7f000 - 0xb9f59fff, 2994176 bytes (731 pages)
> avail memory = 3005071360 (2865 MB)

Как-то многовато BIOS откушал от четырех гигабайт, больше гига.

Интегрированное видео? Если да, то попробуйте уменьшить до минимума память для 
него в BIOS SETUP
и перепроверьте, поможет это инсталлятору или нет в режиме AHCI.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

31.12.2021 18:06, sp...@itl.ua пишет:

>> Нужна информация о вашем CPU и материнке и такая же выдача из dmesg.boot.
> 
> CPU: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz (2594.16-MHz 686-class CPU)
> 
> real memory  = 4294967296 (4096 MB)
> Physical memory chunk(s):
> 0x1000 - 0x0009cfff, 638976 bytes (156 pages)
> 0x0010 - 0x007f, 7340032 bytes (1792 pages)
> 0x0242a000 - 0x1fff, 498950144 bytes (121814 pages)
> 0x2020 - 0x40003fff, 534790144 bytes (130564 pages)
> 0x40005000 - 0xb5754fff, 1970601984 bytes (481104 pages)
> 0xb9c7f000 - 0xb9f59fff, 2994176 bytes (731 pages)
> avail memory = 3005071360 (2865 MB)
> 
> В dmesg.boot сообщения о памяти вроде норм, смутило то, которое выдает loader
> сразу после сообщения о дисках:
> 
> BIOS drive C: is disk0
> BIOS drive D: is disk1
> BIOS 631kB/523264kB available memory
> 
> Какое инфо нужно о материнке?

Производитель и модель. Ещё не помешает выдача kenv | fgrep smbios.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] printf в clang

[Eugene Grosbein]

31.12.2021 16:48, Valentin Nechayev пишет:
> hi,
> 
>  Fri, Dec 31, 2021 at 15:51:50, eugen wrote about "Re: [freebsd] printf в 
> clang": 
> 
>>> Подскажите, а это тянет на баг, или никто ничего в таком случае не обещал?
>>
>> Никто не обещал. Если хочется писать переносимо и с гарантией работы, проще 
>> всего делать так:
>>
>> printf("%jd %ju\n", (intmax_t)longvalue, (intmax_t)unsignedlong);
> 
> В  есть макры типа PRId64.
> https://pubs.opengroup.org/onlinepubs/009696899/basedefs/inttypes.h.html
> Для типов точной размерности можно их использовать.
> [u]intmax_t, конечно, тоже сработает... в принципе printf и так
> дорогой, это ничего существенно не добавит к его цене.

Я пробовал и так, и так. Через %jd гораздо удобнее в тех случаях, когда цена 
принта неважна.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] printf в clang

[Eugene Grosbein]

31.12.2021 15:51, Eugene Grosbein пишет:
> 31.12.2021 4:15, sp...@itl.ua пишет:
>>
>>
>> Приветствую сообщество.
>>
>> Подскажите, а это тянет на баг, или никто ничего в таком случае не обещал?
> 
> Никто не обещал. Если хочется писать переносимо и с гарантией работы, проще 
> всего делать так:
> 
> printf("%jd %ju\n", (intmax_t)longvalue, (intmax_t)unsignedlong);

Пардон, очепятка, надо так:

printf("%jd %ju\n", (intmax_t)longvalue, (uintmax_t)unsignedlong);

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

30.12.2021 20:27, sp...@itl.ua пишет:
> 30 декабря 2021 г., 12:48, "Eugene Grosbein"  написал:
> 
>> 30.12.2021 17:06, sp...@itl.ua пишет:
>>
>>> Пытаюсь вычислить, почему у меня происходит крэш при установленном в биосе 
>>> AHCI.
>>
>> Это баг во фрёвом загрузчике.
> 
> Да, просто пытаюсь локализовать его...
> Крешится в момент опроса биоса/контроллера о режиме, в момент (некорректного) 
> обращения
> к контроллеру, или сбоит выбор драйвера, или еще что-то..

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

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

Я бы попробовал положить в /boot11/ загрузчик от 11.2, раз там всё работало
и попытаться загрузить ядро от 13-й версии старым загрузчиком, запуская сам 
старый загрузчик
из boot2 (если используется MBR) вручную нажатием кнопки "прямой слеш" (/)
и вводом полного пути /boot11/loader, как это документировано в man boot,
если это ещё не сломали:

 After the boot blocks have been loaded, you should see a prompt similar
 to the following:

 >> FreeBSD/x86 BOOT
 Default: 0:ad(0,a)/boot/loader
 boot:

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

30.12.2021 17:06, sp...@itl.ua пишет:

> Пытаюсь вычислить, почему у меня происходит крэш при установленном в биосе 
> AHCI.

Это баг во фрёвом загрузчике.

> Спрошу еще так: сам биос как обращается к диску? зависимо от установки 
> IDE/AHCI
> или нет? Т.е. у него две процедуры под разные режимы или одна?

Это несущественно для обсуждаемой проблемы. А вообще, зависит от диска.

> И так: как система узнает предпочтение контроллера диска?
> читая установку биоса или опрашивая сам контроллер?

В современных системах ACPI BIOS/UEFI - активная часть системы.
ACPI BIOS снабжает операционную систему большим массивом данных об оборудовании,
а операционная система может вызывать код в ACPI BIOS.

> Может ли система скомандовать контроллеру перейти в другой режим, отличный от 
> установки в биосе?

Это всё путь в никуда. Если очень коротко, то нет.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] странности с сетью при переходе на 13-ую версию

[Eugene Grosbein]

02.12.2021 17:34, Nike пишет:
> Было похожее когда сеть была настроена по dhcp. Службы стартовали раньше, чем 
> поднималась сеть.
> А еще похожее было, когда сетевуха была usb'шной.

Кстати да, хорошая мысль.

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



___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] странности с сетью при переходе на 13-ую версию

[Eugene Grosbein]

02.12.2021 18:46, Taras Heichenko пишет:
> Hi!
> 
>> On 2 Dec 2021, at 12:19, Eugene Grosbein  wrote:
>>
>>>>
>>>> Все попытки законнектиться telnet'ом выполнялись
>>>> только применительно к ip-адресам интерфейсов.
>>>> А вообще на машине bind крутится.
>>>
>>> Не настаиваю на своей версии. :) Но прошу не забывать, даже когда вы 
>>> обращаетесь по IP
>>> к интерфейсу, машинка, к которой вы обращаетесь, пытается выполнить 
>>> backresolv на IP,
>>> с которого вы приходите.
>>
>> Приложение, выполняющее бекресолв по IP клиента, должно сначала узнать этот 
>> IP,
>> обычно это происходит уже после того, как подключение установлено.
> 
> По тому описанию, которое было дано, выглядит именно так. Подключение 
> установлено, это еще не удалось подключиться,
> это куда-то постучали. И вот то, куда постучали, и начинает выяснять "кто 
> стучится дверь моя". И если выяснить не получается,
> то со стороны телнета так и будет выглядеть – не могу подключиться. Ярослав 
> ведь не писал, что он там смотрел на tcpdump – 
> конкретики, что происходит, нет. А просто со стороны телнета – ну да, не 
> удалось подключиться.

В случае с TCP сетевые стеки клиента и сервера выполняют трехступенчатый 
handshake (SYN, SYN+ACK, ACK)
и приложение, которое слушает серверный сокет TCP только после этого узнаёт, 
что пришел новый клиент и
в это время уже может начать бекресолв или что там оно желает, но в это же 
время на клиенте
будет "connection established", то есть успешное подключение независимо от 
того, занимается
там дальше сервер бекресолвингом или нет.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] странности с сетью при переходе на 13-ую версию

[Eugene Grosbein]

02.12.2021 16:31, Taras Heichenko пишет:
> Hi!
> 
>> On 2 Dec 2021, at 01:44, Yaroslav Shvets  wrote:
>>
>> Hello.
>>
>> On Thu, 2 Dec 2021, 01:31, you wrote:
>>
>>>
>>> Нет. Дело не в резолвинге.
>>> И не в правилах ipfw.
>>> Одно из первых правил разрешает все via lo
>>
>> Все попытки законнектиться telnet'ом выполнялись
>> только применительно к ip-адресам интерфейсов.
>> А вообще на машине bind крутится.
> 
> Не настаиваю на своей версии. :) Но прошу не забывать, даже когда вы 
> обращаетесь по IP
> к интерфейсу, машинка, к которой вы обращаетесь, пытается выполнить 
> backresolv на IP,
> с которого вы приходите.

Приложение, выполняющее бекресолв по IP клиента, должно сначала узнать этот IP,
обычно это происходит уже после того, как подключение установлено.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] странности с сетью при переходе на 13-ую версию

[Eugene Grosbein]

02.12.2021 6:41, Yaroslav Shvets пишет:

>>> FreeBSD 12.2-releng
>>> Почтовый сервер: sendmail, dovecot
>>> Все работало без приключений. ipfw довольно сложный.
>>>
>>> При переходе на 13.0-releng, а потом на 13-stable наблюдается странное
>>> поведение:

[skip]

> Посмотрю. Сервер постоянно используется.
> Времени на эксперименты особо нет.

Не стоит ставить dot-zero (13.0) на рабочие серверы.
Рекомендую откат на stable/12 хотя бы до выпуска 13.1

На тестовые машины ставить можно.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] странности с сетью при переходе на 13-ую версию

[Eugene Grosbein]

02.12.2021 2:01, Yaroslav Shvets пишет:
> Hello All.
> 
> FreeBSD 12.2-releng
> Почтовый сервер: sendmail, dovecot
> Все работало без приключений. ipfw довольно сложный.
> 
> При переходе на 13.0-releng, а потом на 13-stable наблюдается странное
> поведение:
> 
> При перезагрузке сервера успешно стартуют и sendmail, и dovecot.
> `netstat -an` показывают, что нужные порты успешно слушаются.
> При этом, подключится telnet'ом то получается, то не получается.
> То получается на localhost, но не получается на другие сетевые интерфейсы.
> То можно подключиться к одному порту, но не получается к другому,
> то после перезагрузки к другому уже нельзя, а к ранее неработавшему -
> уже можно. Такое чувство, что после перезагрузки слушающие
> порты работают/не работают в рэндомном порядке.
> 
> Рестарт сервисов уже после загрузки, как правило лечит.
> И оба сервиса начинают нормально работать.
> Вобщем, какая-то магия.
> Sendmail - штатный,
> dovecot-2.3.17_1
> 
> (ssh при этом работает нормально)
> 
> На <= 12.2-releng до этого много лет на тех же конфигах
> все работало без странностей: если порт слушается и фаервол не
> препятствует - то подключиться можно.
> 
> Кто-нибудь знает, что и где могло поломаться?

Что угодно могло поломаться. Что значит "не получается" - connection refused? 
таймаут?
Что показывает tcpdump -npi lo0 ?

"Рестарт сервисов лечит" - это включает в себя загрузку правил ipfw по новой?
Если да, то уходит ли проблема, если вместо рестарта временно сделать
sysctl net.inet.ip.fw.enable=0 ?

В багзилле делал поиск по похожим проблемам для 13.0-RELEASE или 13.0-STABLE?



___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] PPPoE и PPTP, GRE, IPSEC

[Eugene Grosbein]

11.11.2021 14:25, Yaroslav Shvets пишет:
> Hello All.
> 
> Провайдер предоставляет интернет через pppoe.
> Данный сервер должен также выступать как множественным
> pptp-клиентом, так и pptp-сервером (mpd5).
> Предполагается также подключение по IPSEC.
> Не исключены в будущем другие туннели.
> Конфигурация давно отлажена и успешно работает
> через классический сетевой интерфейс.
> 
> Будет ли это все нормально работать через PPPoE?
> Есть ли смысл связываться или стоит выбрать
> классическое подключение к провайдеру?

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

С другой стороны, с практической точки зрения КРАЙНЕ желательно иметь MTU=1500
на интерфейсе подключения к публичному интернету, так как это избавит от 
большого числа проблем.

Иметь MTU=1500 на PPPoE теоретически возможно, а практически это зависит от 
провайдера.
Так что классическое статическое подключение с MTU=1500 гораздо более 
беспроблемно на практике
и нужно всеми силами стараться получить именно его.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] Обновление с 11.4 на 12.2, как лучше?

[Eugene Grosbein]

21.10.2021 17:31, Владимир Друзенко via freebsd пишет:
> 21.10.2021 05:28, Eugene Grosbein пишет:
>> 21.10.2021 4:25, Eugene V. Boontseff via freebsd пишет:
>>> Hello, All!
>>>
>>> Мне нужно обновить 11.4-STABLE.
>>> Можно ли ее обновлять freebsd-update?
>> Нет, freebsd-update не обновляет STABLE. Нужно через gitup stable, 
>> buildworld etc.
>>
>>> Или из src? Если второе, то на релиз или можно на stable?
>> Можно и на релиз, и на 12-STABLE.
> Есть схожий вопрос: можно ли бинарно обновить собранный из исходников релиз 
> 12.2-p4 до 12.2-p10, до 12.3 (когда выйдет), до 13.0?

the FreeBSD Security Team only builds updates for
releases shipped in binary form by the FreeBSD Release Engineering Team

(c) man freebsd-update

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

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] Обновление с 11.4 на 12.2, как лучше?

[Eugene Grosbein]

21.10.2021 4:25, Eugene V. Boontseff via freebsd пишет:
> Hello, All!
> 
> Мне нужно обновить 11.4-STABLE.
> Можно ли ее обновлять freebsd-update?

Нет, freebsd-update не обновляет STABLE. Нужно через gitup stable, buildworld 
etc.

> Или из src? Если второе, то на релиз или можно на stable?

Можно и на релиз, и на 12-STABLE.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] Postfix in test mode

[Eugene Grosbein]

22.09.2021 21:15, Sergey V. Dyatko пишет:

>> Postfix in test mode Здравствуйте.
>>
>> Как сконфигурировать тестовый postfix-сервер для принятия почты с таким
>> алгоритмом:
>>
>> 1) есть 2 MX записи с разными приоритетами
>> comp-mir.ua.86400   IN   MX  15  mail.comp-mir.ua.
>> comp-mir.ua.86400   IN   MX  30  mailtest.comp-mir.ua.
>>
>> 2) Любой сервер X подключается к mailtest.comp-mir.ua и передает письмо.
>>  mailtest.comp-mir.ua принимает письмо, но передает ошибку
>>  Сервер Х передает письмо на mail.comp-mir.ua.
>>  mail.comp-mir.ua. принимает письмо и возвращает "200 OK"
>>
>> Конфигурации двух серверов почти одинаковые. Подскажите, какая настройка
>> заставит принять почту но ответить ошибкой?
>>
> 
> мне казалось, что "любой сервер Х" должен подключаться к mail.comp-mir.ua в
> первую очередь. и только при недоступности идти в mailtest. разве нет?

Спамеры любят долбиться в низкоприоритетные MX :-) но они долбятся вообще везде.

А ответ на первоначальный вопрос зависит от того, что в итоге хочется получить:
потерю почты? тогда надо отвечать ошибкой 5xx;
перепосылку позже на другой MX? тогда надо отвечать ошибкой 4xx и ставить 
приоритет такого сервера выше, а не ниже (цифру меньше).


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] unbound и отстающие часы

[Eugene Grosbein]

21.09.2021 11:53, Valentin Nechayev пишет:
> hi,
> 
>  Tue, Sep 21, 2021 at 04:34:16, eugen wrote about "Re: [freebsd] unbound и 
> отстающие часы": 
> 
>>> и как же часы выставить без работающего DNS?
>>
>> В случае ntpd добавить в конфиг несколько команд server с IP-адресами
>> в дополнение к команде pool.
> 
> В случае корней DNS гарантируется, что IP списка хинтов валидны много
> лет после момента актуализации списка.
> Кто даст такую же гарантию для NTP?

Практика. Отресолвь вот этот список, с 2009 года из него пропало только два 
сервера (было на 2 больше):

server Time2.Stupi.SE   iburst maxpoll 9
server ntp1.sp.se   iburst maxpoll 9
server ntp1.mmo.netnod.se   iburst maxpoll 9
server ntp1.ptb.de  iburst maxpoll 9
server ntp1.ien.it  iburst maxpoll 9
server ntp1.sth.netnod.se   iburst maxpoll 9
server ntp1.vniiftri.ru iburst maxpoll 9
server ntp2.vniiftri.ru iburst maxpoll 9
server ntp3.vniiftri.ru iburst maxpoll 9

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

Не уверен, что понял эту фразу: ты пишешь себе ненадёжные перловые 
трехстрочники?
Вот тебе надежный шелловский:

getip() { host "$1" | awk '/has address/ {print $NF}'; }
{
  getip ntp1.vniiftri.ru
  getip ntp2.vniiftri.ru
  ...
} | xargs -n 1 ipfw -q table 5 add

Вместо ipfw можно поставить /usr/bin/printf 'server %s iburst maxpoll 9\n' или 
что хочешь.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] unbound и отстающие часы

[Eugene Grosbein]

21.09.2021 4:17, Slawa Olhovchenkov пишет:

> и как же часы выставить без работающего DNS?

В случае ntpd добавить в конфиг несколько команд server с IP-адресами
в дополнение к команде pool.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] unbound и отстающие часы

[Eugene Grosbein]

21.09.2021 2:05, Valentin Nechayev пишет:
> hi,
> 
>  Thu, Sep 02, 2021 at 18:15:20, eugen wrote about "Re: [freebsd] unbound и 
> отстающие часы": 
> 
>> Да, при условиях:
>>
>> 1) VBoxManage setextradata "VM name" 
>> "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" 0
>> 2) установлены VBox Guest Additions:
>> https://docs.freebsd.org/en/books/handbook/virtualization/#virtualization-guest-virtualbox
> 
> Это сработало, спасибо. Но это таки лечение не основной проблемы, мне
> кажется.

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

Если ты начнешь убеждать авторов DNS-серверов в том, что так писать софт нельзя,
услышишь много интересного в свой адрес.

>> Что касается глюка local_unbound, то скорее всего это эффект от DNSSEC,
>> вероятно поможет добавить val-permissive-mode: yes
>> в unbound.conf
>>
>> То есть, отключить проверку подписей. Это несложно потестировать.
> 
> При разнице до 12 часов?
> Ну если так, то конфиг для первичного старта с часами желательно чтобы
> как раз содержал такое отключение, а после успешной синхронизации -
> уже без него...

Про DNSSEC это всего лишь предположение, сначала надо потестировать.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] unbound и отстающие часы

[Eugene Grosbein]

03.09.2021 1:44, Valentin Nechayev wrote:

> Оказалось, что кто-то из этих скриптов сумел вписать запись в
> master.passwd и passwd, но не регенерировал соответствующие dbʼшки.
> (Полечил вручную через vipw с записью.)

Если эта система ранее была обновлена при помощи freebsd-update,
то это известный баг в freebsd-update, после её работы pkg обламывается с 
добавлением юзеров
из-за рассинхрона master.passwd и [s]pwd.db

https://www.freebsd.org/security/advisories/FreeBSD-EN-21:08.freebsd-update.asc

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] unbound и отстающие часы

[Eugene Grosbein]

02.09.2021 18:05, Valentin Nechayev пишет:
> Обнаружил эффект: FreeBSD под Virtualbox (12.2, в описанных
> областях все параметры штатные). Хостовая машина периодически в
> спячке, при этом локальное время в виртуалке останавливается.
> Когда просыпается, виртуалке надо восстановить время. Но даже
> какое-нибудь "ntpdate -bs pool.ntp.org" не работает: local_unbound
> отвечает SERVFAIL на всё. Как только зарезолвил хосты для часов в
> другом месте и засинхронизировал вручную по IP, unbound стал нормально
> отвечать.
> 
> Есть ли штатный метод лечения такой проблемы? Происходит ли она
> при загрузке, если локальные часы тяжело сбиты?

Да, при условиях:

1) VBoxManage setextradata "VM name" 
"VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" 0
2) установлены VBox Guest Additions:
https://docs.freebsd.org/en/books/handbook/virtualization/#virtualization-guest-virtualbox

Что касается глюка local_unbound, то скорее всего это эффект от DNSSEC,
вероятно поможет добавить val-permissive-mode: yes
в unbound.conf

То есть, отключить проверку подписей. Это несложно потестировать.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] Беда с KOI8-R в xfce4-terminal.

[Eugene Grosbein]

04.08.2021 9:07, Victor Sudakov wrote:

>> Это вопрос к самому эмулятору терминала.
>> Либо он должен перекодировать выдачу в кодировку твоего шрифта,
>> либо не перекодировать, но менять шрифт на другой с нужной кодировкой.
> 
> Это всё похоже на советы Кэпа,

Это указание векторов, в каких направлениях копать.

> Ну а отчего бы оно могло перестать работать?

Разработчики и пользователи перестали тестировать перекодирование.
Неиспользуемые инструменты ржавеют.

> А где эта перекодировка лежит? В смысле, эмуляторы терминалов и
> конкретно сабж что используют для перекодировки, системный libiconv или
> что-то гномское например?

Не знаю, у меня везде только KOI8-R.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] Беда с KOI8-R в xfce4-terminal.

[Eugene Grosbein]

02.08.2021 10:59, Victor Sudakov пишет:
> Коллеги,
> 
> После очередного обновления портов (?) на 12.2-RELEASE возникла странная
> проблема с xfce4-terminal. У меня локале вообще-то ru_RU.UTF-8, но
> остались несколько удалённых хостов с KOI8-R. Я раньше на них ходил,
> просто переключая кодировку в xfce4-terminal на Cyrillic -> KOI8-R 
> 
> А сейчас какую кодировку ни выбери в меню терминала, похоже что терминал 
> остаётся в
> UTF-8. 
> 
> Когда точно это случилось, определить не могу, т.к. хожу на эти хосты
> достаточно редко, но вот вдруг сюрприз.

А причем тут FreeBSD вообще? Это вопрос к самому эмулятору терминала.
Либо он должен перекодировать выдачу в кодировку твоего шрифта,
либо не перекодировать, но менять шрифт на другой с нужной кодировкой.

Так что либо у тебя больше не работают (не поддерживаются эмулятором)
шрифты с KOI8-R, например, битмапового формата pcf/bdf, или векторного OpenType,
или TTF, какие там у тебя есть; либо поломали перекодировку из KOI8-R в UTF-8.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] cmake

[Eugene Grosbein]

20.07.2021 22:00, Taras Heichenko пишет:
>  Hi all!
> А кто-нибудь недавно собирал cmake под фрей? Это у меня какой косяк вылез, 
> или я не одинок?
> 
> Traceback (most recent call last):
>   File "/usr/local/bin/sphinx-build", line 6, in 
> from pkg_resources import load_entry_point
> ModuleNotFoundError: No module named 'pkg_resources'
> --- Utilities/Sphinx/doc_format_man ---
> *** [Utilities/Sphinx/doc_format_man] Error code 1
> 
> дальше еще пачка сообщений от make, где именно он stopped, после чего

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

Если же у вас, например, стоит python 3.7.x и это не прописано в /etc/make.conf,
а оно тянет сборку 3.8, то имеет смысл прописать в make.conf что-то типа такого:

DEFAULT_VERSIONS= perl5=5.32 python=3.7 python3=3.7

Не помню, что из python/python3 надо, но оба прописать не вредно.
И тогда оно не будет тянуть каждую новую версию питона, пока 3.7 не дропнут 
совсем.



___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] сигнал для процесса

[Eugene Grosbein]

01.07.2021 2:32, Eugene Grosbein пишет:

> В FreeBSD можно посмотреть состояние блокировок сигналов запущенного процесса:
> 
> # ps -wo pid,sigmask,sigignore,command -p 53667
>   PID BLOCKED  IGNORED COMMAND
> 53667   0 18788002 /usr/local/sbin/squid -f 
> /usr/local/etc/squid/squid.conf
> 
> В данном случае у squid нет заблокированных сигналов и есть игнорируемые.

Можно также посмотреть подробности:

# procstat -i 53667 | fgrep -v -- ---
  PID COMM SIG FLAGS
53667 squidINT  -I-
53667 squidURG  -I-
53667 squidCHLD -I-
53667 squidTTIN -I-
53667 squidTTOU -I-
53667 squidIO   -I-
53667 squidWINCH-I-
53667 squidINFO -I-
53667 squidUSR1 --C
53667 squid32   --C

Тут мы видим те сигналы, для которых включено игнорирование (флаг I в наборе 
флагов)
и два последних обрабатываются особо (флаг C от catch).

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

У squid такого нет, но вот пример для VBoxHeadless:

# procstat -j 2212 | fgrep -v -- -- | head
  PIDTID COMM SIG FLAGS
 2212 100930 VBoxHeadless ALRM -B
 2212 100934 VBoxHeadless ALRM -B
 2212 100935 VBoxHeadless ALRM -B
 2212 100936 VBoxHeadless ALRM -B
 2212 100937 VBoxHeadless ALRM -B
 2212 100939 VBoxHeadless ALRM -B
 2212 100941 VBoxHeadless ALRM -B
 2212 100944 VBoxHeadless ALRM -B
 2212 100963 VBoxHeadless ALRM -B

Это всё документировано в man procstat.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] сигнал для процесса

[Eugene Grosbein]

30.06.2021 12:23, Yaroslav Shvets пишет:
> Hello.
> 
> В /usr/local/etc/rc.d есть скрипт, который запускает некий процесс.
> При получении сигнала SIGHUP и скрипт, и процесс отдельно умеют
> этот сигнал обрабатывать.
> Т.е. выполняют отвественную за это логику.
> 
> Если запуск скрипта, а соотвественно и последующий запуск процесса произошел
> во время загрузки системы, то и скрипт, и процесс на SIGHUP не реагируют.
> Т.е. процессы в памяти присутствуют, но на kill -HUP  не реагируют.
> Если скрипт в /usr/local/etc/rc.d запускается из шелла, то и скрипт,
> и процесс вполне реагируют на приходящие сигналы.
> 
> Как мне кажется, дело не в другом окружении.
> Что я упустил?

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

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

Например, такой баг есть в squid, я его им зарепортил в 2016-м с простым 
исправлением, но без какой-либо реакции вообще.
https://bugs.squid-cache.org/show_bug.cgi?id=4494
https://bugs.squid-cache.org/attachment.cgi?id=3337

В FreeBSD можно посмотреть состояние блокировок сигналов запущенного процесса:

# ps -wo pid,sigmask,sigignore,command -p 53667
  PID BLOCKED  IGNORED COMMAND
53667   0 18788002 /usr/local/sbin/squid -f /usr/local/etc/squid/squid.conf

В данном случае у squid нет заблокированных сигналов и есть игнорируемые.

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

И если не секрет, что за процесс?

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] releng-13 не проходит installworld

[Eugene Grosbein]

15.06.2021 16:41, Yaroslav Shvets пишет:
> Hello All.
> 
> Успешно обновился из исходников с releng-12.2 до releng-13.
> При пересборке releng-13 из releng-13 не инсталится мир:

Такие вопросы лучше всего задавать в список рассылки sta...@freebsd.org.
Или можно сразу PR оформлять в багзилле и в нём CC: ставить sta...@freebsd.org.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] socket

[Eugene Grosbein]

21.04.2021 23:39, Nick Kostirya via freebsd пишет:
> Привет.
> 
> Вопрос по сокетам.
> 
> Забыл открыть сокет в неблокирующем режиме.
> После select записывалось столько данных, сколько влезало, и операция записи 
> не блокировалась. 
> 
> А вот при запуске под Линуксом обнаружил эту ошибку, так как там запись 
> блокируется.
> 
> Это такая особенность FreeBSD или всех BSD?
> А как под Солярисом?

И то, и другое - допустимое поведение системы.

Из man send:

 If no messages space is available at the socket to hold the message to be
 transmitted, then send() normally blocks.

Из man setsockopt:

 SO_SNDLOWAT is an option to set the minimum count for output operations.
 Most output operations process all of the data supplied by the call,
 delivering data to the protocol for transmission and blocking as
 necessary for flow control.  Nonblocking output operations will process
 as much data as permitted subject to flow control without blocking, but
 will process no data if flow control does not allow the smaller of the
 low water mark value or the entire request to be processed.  A select(2)
 operation testing the ability to write to a socket will return true only
 if the low water mark amount could be processed.  The default value for
 SO_SNDLOWAT is set to a convenient size for network efficiency, often
 1024.

На FreeBSD давно есть автомасштабирование буфера сокета, принимающего данные
для отправки ядром без синхронизации приложения. Дефолтный размер значения
sysctl net.inet.tcp.sendspace=32K для приложений,
которые сами не меняет дефолты при помощи setsockopt, автоувеличение включено
порциями по net.inet.tcp.sendbuf_inc=8K вплоть до 8M.

Условия автоувеличения буфера описаны в sys/netinet/tcp_output.c
в комментариях функции tcp_sndbuf_autoscale() (FreeBSD 12+) или tcp_output 
(FreeBSD 11 и ранее).

А в FreeBSD 12 и новее ещё есть sysctl net.inet.tcp.sendbuf_auto_lowat 
(выключено по дефолту),
при включенном процедура автоувеличения буфера принимает во внимание 
пользовательское
значение SO_SNDLOWAT: https://reviews.freebsd.org/D11016

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

20.04.2021 0:25, sp...@itl.ua пишет:
> 19 квітня 2021 р., 20:04, "Eugene Grosbein"  написав:
> 
>>
>> Да баг это, баг. Если загрузчик уже выдал часть своих строчек, а потом 
>> внезапно всё по новой пошло,
>> то это был креш, который закончился CPU reset.
>>
>> 13.0 мало отличается от девелоперской версии (dot zero release), так что 
>> дебажить это
>> дальше можно, если на то есть желание или если, к примеру, 12.2-RELEASE 
>> ведёт себя так же.
>>
>> Иначе лучше вернуться на 12.2-RELEASE.
> 
> 12.2 - та же картина.
> 
> Желание дебажить есть (если хватит мозгов), тем более что а куда деваться.
> Подскажете направление?

Первым делом завести PR в багзилле и туда все эти данные (все попытки с разными 
настройками),
включая инфу о работе 11.2


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

19.04.2021 23:33, sp...@itl.ua пишет:
> 19 квітня 2021 р., 19:12, "Anton Saietskii"  >
>  написав:
> 
> Я бы за 2 дня уже переставил оперативу в кошерный слот и проверил...
> 
> 
> Было страшно :)
> Спасибо за мотивацию, переставила.
> 
> На загрузку не повлияло. Значит, дело не в слоте. Может, в способе доступа к 
> памяти?
> В этом EliteBook в биосе какая-то параноидальная секьюрити, может, биосу 
> что-то не нравится?

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

13.0 мало отличается от девелоперской версии (dot zero release), так что 
дебажить это
дальше можно, если на то есть желание или если, к примеру, 12.2-RELEASE ведёт 
себя так же.

Иначе лучше вернуться на 12.2-RELEASE.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] 13.0 memstick не грузится

[Eugene Grosbein]

18.04.2021 2:41, sp...@itl.ua пишет:
> Приветствую сообщество.
> 
> 13.0 memstick не хочет грузиться на HP EliteBook 2570p.
> Эта же флешка с этим же имеджем успешно грузится на другом ноуте.
> Эта же флешка с 11.2 memstick успешно грузится на первом ноуте.
> В boot menu флешка есть, начинается загрузка с нее, на экране
> на мгновенье появляются строки:
> 
> Consoles: internal video/keyboard
> BIOS Drive C: disk0
> BIOS Drive D: disk1
> 
> Потом темный экран и опять boot menu.
> 
> На втором ноуте при загрузке за этими строками следует такая:
> 
> BIOS 639kB/2087744kB available memory
> 
> Аналогичная - при загрузке с 11.2 memstick на первом ноуте.
> 
> Может ли это быть связано с тем, что на первом ноуте память стоит
> во втором слоте, а первый пустой? Как всё-таки загрузиться с флешки?

Если set kern.vty=sc не помогает и также вместо этого не помогает set 
hw.vga.textmode=1,
то есть третий вариант вместо этих двух попробовать:

set hw.vga.acpi_ignore_no_vga=1

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] dts

[Eugene Grosbein]

15.04.2021 0:12, Slawa Olhovchenkov пишет:

>>> Как? Разве git позволяет скачать часть?
>>
>> git даже позволяет скачивать без истории, shallow clones:
>>
>> git clone --depth 1 $url
>>
>> Итог занимает сильно меньше места.
> 
> может тебе еще известен и способ обновить только один порт в дереве?

Скажем так, потребности в этой колбасе у меня ещё не было, так что не гугулил в 
эту сторону.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] dts

[Eugene Grosbein]

14.04.2021 21:19, Nick Kostirya via freebsd пишет:

> Как? Разве git позволяет скачать часть?

git даже позволяет скачивать без истории, shallow clones:

git clone --depth 1 $url

Итог занимает сильно меньше места.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] netgraph

[Eugene Grosbein]

On 05.04.2021 10:31, Nick Kostirya wrote:

>>> Привет. 
>>>
>>> У меня наивный вопрос про netgraph.
>>>
>>> Я правильно понял, что при помощи ng_socket можно соединить два компьютера 
>>> в одну сеть через, например, UART проводами или при помощи радио?
>>> Для этого лишь достаточно написать демона, который будет просто 
>>> перекладывать байты из socket в UART сразу или передавать радиочипу?  
>>
>> Не этой нодой.
>>
>> ng_socket это "переходник" между BSD-сокетами стека TCP/IP и внутренностями 
>> NETGRAPH и не более того.
>> То есть, если у нас есть некая абстрактная нода или сеть нод внутри NETGRAPH 
>> и их надо кормить
>> данными, приходящими из TCP/IP (или в обратную сторону, или в обе), для 
>> этого можно использовать ng_socket.
> 
> А в случае UART можно использовать ng_tty(4)?

Не вижу, каким образом.

> Общение с железкой осуществляется через gpio и uart. Сначала она 
> настраивается через uart, потом при помощи gpio переключается в режим, когда 
> через uart (/dev/cuaU* или /dev/ttyU*) идут только данные, которые прямо без 
> обработки можно заворачивать в TCP/IP.
> Получится, после настрой железки, при помощи ng_tty создать netgraph ноду и 
> ее при помощи ng_ksocket соединить ее к стеку TCP/IP?

Если драйвером является uart(4), который вовсе не заточен отдавать принимаемые 
данные в NETGRAPH, то нет.
uart(4) рассчитан на работу с пользовательскими процессами через файл 
устройства в /dev,
то есть системными вызовами read/write (ещё ioctl). Это существенный момент - 
данные из UART можно получить
только через файл устройства, то есть ориентация на обработку данных 
пользовательскими процессами,
а не в ядре, на что заточен NETGRAPH.

Можно, конечно, использовать ng_device для создания ещё одного девайса типа 
/dev/ngd0
и запустить пару процессов cat < /dev/cuau0 > /dev/ngd0 и второй cat в обратную 
сторону,
а затем соединить ng_device с ng_ksocket, но это как-то некузяво. Для тестовой 
схемы, может быть, сойдет,
но для работы такое вряд ли годится.

Если цель это получить данные именно из UART на другой машине, то конкрето эта 
задача,
разумеется, давным давно решена и много раз. В /usr/ports/comms хватает разного 
софта для этого:
comserv, remserial. Или, если вместо этого хочется "экспортировать" локальный 
/dev/cuau0 так,
чтобы удаленный хост мог подключиться по TCP и получить поток данных,
там же serialoverip, sredird, tits, и тот же comserv, который умеет и так.

Я когда-то давно с успехом пользовался каким-то из подобных пакетов под FreeBSD 
8,
но ставил не сам и уже не помню, каким именно. У меня была система FreeBSD с 
обычной
мультипортовкой и разные коммутаторы, циски и прочее, подключенные к портам,
стандартный консольный сервер. Он позволял подключаться к разным TCP-портам
стандартным telnet-ом и попадать на соответствующие порты UART.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] netgraph

[Eugene Grosbein]

02.04.2021 14:43, Nick Kostirya via freebsd пишет:
> Привет. 
> 
> У меня наивный вопрос про netgraph.
> 
> Я правильно понял, что при помощи ng_socket можно соединить два компьютера в 
> одну сеть через, например, UART проводами или при помощи радио?
> Для этого лишь достаточно написать демона, который будет просто перекладывать 
> байты из socket в UART сразу или передавать радиочипу?

Не этой нодой.

ng_socket это "переходник" между BSD-сокетами стека TCP/IP и внутренностями 
NETGRAPH и не более того.
То есть, если у нас есть некая абстрактная нода или сеть нод внутри NETGRAPH и 
их надо кормить
данными, приходящими из TCP/IP (или в обратную сторону, или в обе), для этого 
можно использовать ng_socket.

Для передачи данных (соединения в сеть) через UART штатный драйвер uart(4) уже 
создаёт файлы устройств
в /dev, плюс драйвер этот реализует абстракцию termios(4) line discipline и уже 
написаны демоны,
которые перекладывают байты в девайс и обратно: ppp, mpd5 и раньше ещё был 
slattach, но протокол SLIP
для работы поверх UART выпилили давно из FreeBSD (во время FreeBSD 4 он ещё 
работал).

Если вам интересно использование именно NETGRAPH через некое железо, то плясать 
надо от драйвера
этого железа, в какой форме драйвер принимает данные для отправки или выдаёт 
принятые от железа данные?

Если вы сами пишете такой драйвер - вполне возможно реализовать новую ноду 
NETGRAPH,
которая с одной стороны будет частью драйвера, общающейся с железом "напрямую",
а с другой стороны посредством нетграфовых хуков может быть соединена с 
ng_iface или ng_eiface
или ng_device.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] hyper-v + freebsd 12.2

[Eugene Grosbein]

10.03.2021 18:56, Pavel Gaidai пишет:
> Всем привет!
> 
> Такая проблема, на сервере установлена windows server 2012 R2 Standard 64 
> bit, настроен Hyper-V, в Hyper-V крутится виртуалка с freebsd 11.2.
> После обновления freebsd до 12.2 generic ядро перестало монтировать корневую 
> fs, со старым ядром все работает:
> 
> Trying to mount root from ufs:/dev/da0p2 [rw]...
> mountroot: waiting for device /dev/da0p2 ...
> Mounting from ufs:/dev/da0p2 failed with error 19.
> 
> Подскажите как решить эту проблему?

Оно потом вываливается в запрос mountroot>
В нём нужно спросить список доступных к монтированию устройств командой "знак 
вопроса", ввести ?

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


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] [mail] [postfix] отправка писем серверу получателя, используя ssl

[Eugene Grosbein]

09.03.2021 17:24, Anton Saietskii пишет:

> Такие вещи надо писать в рассылку, а не приватно :-)
> 
> Вся эта боль из-за отсутствия reply-to, что уже неоднократно обсуждалось.

Так надо пользоваться кнопочкой "Ответить всем" или "Ответить в рассылку".

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] [mail] [postfix] отправка писем серверу получателя, используя ssl

[Eugene Grosbein]

09.03.2021 17:11, Alexey Krylov пишет:
> Здравствуйте, Eugene.
> 
> *> 09.03.2021 16:04, Alexey Krylov пишет:
>>> Всем доброго дня.
>>> Пожалуйста, подскажите, как настроить postfix, чтобы он отправлял письма по 
>>> дефолту используя ssl(port 465)
>>> И, если ssl не поддерживается сервером получателя отправлял письма plain 
>>> (port 25)
> 
>> Пардон, вчитался в вопрос получше :-)
>> 25-й порт вовсе не означает передачу почты без SSL, современные MTA
>> сразу после начала сессии по 25-му порту умеют сказать STARTTLS
>> и дальше всё идёт обёрнутое в TLS по этому порту.
> 
> 
> *Спасибо. Всё теперь понял... как гуглу вопрос задать.
> 
> 
> Решение оказалось простым:
> Добавить в main.cf
> smtp_tls_security_level = may
> 
> и в master.cf для smtp
> -o smtpd_tls_security_level=may

Такие вещи надо писать в рассылку, а не приватно :-)


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] [mail] [postfix] отправка писем серверу получателя, используя ssl

[Eugene Grosbein]

09.03.2021 16:04, Alexey Krylov пишет:
> Всем доброго дня.
> 
> Пожалуйста, подскажите, как настроить postfix, чтобы он отправлял письма по 
> дефолту используя ssl(port 465)
> И, если ssl не поддерживается сервером получателя отправлял письма plain 
> (port 25)

Пардон, вчитался в вопрос получше :-)
25-й порт вовсе не означает передачу почты без SSL, современные MTA
сразу после начала сессии по 25-му порту умеют сказать STARTTLS
и дальше всё идёт обёрнутое в TLS по этому порту.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] [mail] [postfix] отправка писем серверу получателя, используя ssl

[Eugene Grosbein]

09.03.2021 16:04, Alexey Krylov пишет:
> Всем доброго дня.
> 
> Пожалуйста, подскажите, как настроить postfix, чтобы он отправлял письма по 
> дефолту используя ssl(port 465)
> И, если ssl не поддерживается сервером получателя отправлял письма plain 
> (port 25)
> 
> Может кто сталкивался...
> 
> ssl в роде настроил и клиент отправляет почту используя ssl(post 465) но 
> дальше сервер устанавливает
> соединение на 25 порт сервера получателя... Или так нельзя?
> 
> Спасибо за помощь

К сожалению, не могу ответить по сути (не пробовал так делать и не использую 
postfix),
но хочу уточнить: порт 465 "положено" использовать клиентским приложениям
(MUA, Mail User Agent) для подключения к MSA (Mail Submission Agent, компонент 
почтового сервера),
а порт 25 "положено" использовать почтовому серверу (его компоненту MTA, Mail 
Transfer Agent)
для подключений к другим MTA.

Чтобы найти адекватное решение задачи, неплохо бы сначала почетче сформулировать
саму задачу, для чего это нужно? Замаскировать postfix под клиентский MUA?


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] FreeBSD 12 out of swap space при пустом свопе

[Eugene Grosbein]

02.03.2021 10:43, Dmytro Lavryk пишет:
> Всем здоровья!
> Время от времени выскакивает такое:
> Feb 16 10:48:40 005 kernel: pid 76229 (mysqld), jid 0, uid 88, was killed: 
> out of swap space
> Mar  1 21:11:55 005 kernel: pid 3785 (icecast), jid 0, uid 80, was killed: 
> out of swap space
> 
> При этом свопа много и он ВЕСЬ пустой. Вообще не вижу чтобы его кто-то 
> когда-то использовал. Больше ничего "подозрительного" в логах нет.
> 
> Честно говоря, вообще плохо понимаю, как такое может быть.
> 
> Куда смотреть?

swapinfo -h


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] FreeBSD 12.2 reply-to перестал работать

[Eugene Grosbein]

29.01.2021 15:14, skeletor пишет:
> Всем привет.
> После обновления с 12.1 на 12.2 перестал работать reply-to (есть 2 провайдера 
> и ответы уходят через тот интерфейс, откуда пришли, а не через route map) в 
> файерволе pf. Причём на обоих машинах сразу с разным набором правил. Как 
> видно из tcpdump'a они просто уходят согласно route map и никак не реагируют 
> на правила reply-to / route-to.
> 
> Писал в freebsd...@freebsd.org, но пока нет ответа. Вдруг тут кто-то 
> столкнулся с похожим знает в чём проблема и знает как решить :) . Или может 
> стоит оформить bug report?
> 
> Если надо - могу привести правила, но маловероятно, что дело в них, так как 
> это случилось сразу на 2-х машинах (заметил не сразу, ибо резервными каналами 
> пользуемся очень редко)
> 
> PS. Сейчас сделал через костыли в виде static route, но это неудобно и не 
> всегда применимо.

Надо делать баг-репорт и потом дублировать в freebsd-net@ (гораздо гуще 
населён) со ссылкой на PR.
Я сам pf не использовал никогда, не подскажу (использую ipfw fwd для этого же).


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] ZFS - занимаемое пространство

[Eugene Grosbein]

21.01.2021 18:15, Mikhail Golub пишет:
> все дело в recordsize.

> # diskinfo -v da1
> da1
> 512 # sectorsize

> 
> # zdb -C | egrep 'ashift| name'
> name: 'tank'
> ashift: 9
> name: 'www'
> ashift: 12

Да, recordsize 2KB при ashift 12 (4KB) очевидно, плохая идея.
Можно попробовать сделать recordsize 4KB, проблема должна уйти.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] ZFS - занимаемое пространство

[Eugene Grosbein]

21.01.2021 15:47, Mikhail Golub пишет:
> Доброго времени суток.
> 
> Поясните, пожалуста, не могу понять.
> 
> Имеется FreeBSD 12.1 на виртуалке.
> Пул ZFS с одним диском.
> На пуле файловая система.
> Задан параметр refquota 2 Гб.
> На этой файловой системе лежит каталог сайта (данные 7z):
> 1220 folders, 7395 files, 460629747 bytes (440 MiB)

1220+7395=8615 пользовательских объектов на файловой системе,
460629747/8615 = 53468 байт на объект в среднем.

949M/439M = 2.16, то есть каждый объект в действительности
занимает на fs вдвое больше места, чем его длина в среднем...

Вопрос: что показывает diskinfo -v для "диска" в этой виртуалке?
И ещё zdb -C | egrep 'ashift| name'


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] ZFS - занимаемое пространство

[Eugene Grosbein]

21.01.2021 15:47, Mikhail Golub пишет:
> Доброго времени суток.
> 
> Поясните, пожалуста, не могу понять.
> 
> Имеется FreeBSD 12.1 на виртуалке.
> Пул ZFS с одним диском.
> На пуле файловая система.
> Задан параметр refquota 2 Гб.
> На этой файловой системе лежит каталог сайта (данные 7z):
> 1220 folders, 7395 files, 460629747 bytes (440 MiB)
> 
> И 7z и mc сообщают одинаковый размер.
> 
> А du и df - другой размер занимаемого пространства.
> # df -h /www/sites/netapp-event
> FilesystemSizeUsed   Avail Capacity  Mounted on
> www/sites/netapp-event2,0G949M1,1G46% /www/sites/netapp-event
> 
> # du -d 0 -h /www/sites/netapp-event
> 953M/www/sites/netapp-event
> 
> NAMEPROPERTY VALUE  SOURCE
> www/sites/netapp-event  quotanone   local
> www/sites/netapp-event  refquota 2G local
> www/sites/netapp-event  compression  offdefault
> www/sites/netapp-event  usedbydataset949M   -
> www/sites/netapp-event  usedbysnapshots  317M   -
> www/sites/netapp-event  dedupoffdefault

Это данные от ядра, от самой ZFS.

> recordsize был 2 Кб. Сегодня поменял на дефолтный 128 Кб.

Смена recordsize влияет на вновь записываемые блоки данных, но не влияет на 
ранее записанные.

> Из-за чего разница в результатах используемого дискового пространства?

df также показывает данные от ядра. du считает сам, причём du может показывать 
сильно разные данные
при использовании ключа -A и без него.

mc и 7z считают сами и, очевидно, считают неправильно. А почему - вопрос к ним.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] Удаленные порты

[Eugene Grosbein]

09.01.2021 10:56, Vladislav V. Prodan пишет:
> А можно как-то поспособствовать появлению порта emulators/qemu-guest-agent ?
> 
> Автор, вроде допилил порт - https://github.com/aborche/qemu-guest-agent

Наличие подробной документации это очень хорошо.

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

Желательно в FreeBSD Bugzilla сделать PR и прикрепить туда порт,
оформленный в соответствии с Porters Handbook. Если порт 
протестирован/поддерживает
только FreeBSD 12+, в Handbook указано, как это оформить в Makefile порта.

Порт сабмитнуть может не только автор, а вообще кто угодно.
Если PR уже есть - пришлите сюда или мне ссылку на него.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] Удаленные порты

[Eugene Grosbein]

01.01.2021 15:43, Nick Kostirya пишет:
> On Fri, 1 Jan 2021 12:48:43 +0700
> Eugene Grosbein  wrote:
> 
> 
>>
>> Я восстановил все три порта.
> 
> Огромное спасибо!
> 
> А вот есть еще удаленный порт из-за: Uses obsolete glib12
> 
> https://www.freshports.org/x11/xdialog
> 
> Там достаточно поменять 
> 
> USE_GNOME= gtk12
> 
> на
> 
> USE_GNOME= gtk20
> 
> и добавить
> 
> CONFIGURE_ARGS= --with-gtk2

Готово.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] Удаленные порты

[Eugene Grosbein]

30.12.2020 22:37, Nick Kostirya пишет:
> On Wed, 30 Dec 2020 14:00:28 +0700
> Eugene Grosbein  wrote:
> 
> 
>> Если дистфайлы небольшие и лицензия позволяет, возможно, я могу положить к 
>> себе.
>> О каких портах идёт речь?
> 
> 
> 
> GNU2 Suguru Yamaguchi
> https://www.freshports.org/sysutils/xbattbar
> http://mirror.its.dal.ca/freebsd/distfiles/xbattbar_1.4.2.tar.gz
> 
> GNU2
> https://www.freshports.org/sysutils/wmcube/
> http://mirror.its.dal.ca/freebsd/distfiles/wmcube-0.98.tar.gz
> 
> https://www.freshports.org/sysutils/wmbsdbatt/
> http://mirror.its.dal.ca/freebsd/distfiles/wmbsdbatt-0.1.tar.gz
> 
> Все три под GNUv2. Позволяет GNUv2 лицензия сделать это?

Лицензия называется GPLv2 (GNU Public License version 2) и она разрешает 
распространение софта.
Для этой лицензии абсолютно неважен источник неизменённого дистфайла.

И для FreeBSD он тоже неважен, если дистфайл публично доступен и не на серверах 
самого проекта.
Взаимное зеркалирование вполне подходит.

Я восстановил все три порта.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] Удаленные порты

[Eugene Grosbein]

30.12.2020 12:40, Nick Kostirya пишет:
> Привет. Это опять я. Вопрос про удаленные порты.
> 
> Обнаружил, что некоторые маленький программки, к которым привык, были удалены 
> из портов. Удалены, потому, что сайты с distfiles перестали существовать.
> 
> Такое удаление происходит автоматически?

Нет. Это делают некоторые комиттеры вручную.

> Нашел их исходники, проверил.
> 
> Как вы думаете, куда лучше выложить архивы, прежде чем писать в ports@
> Может есть специальное место?

Теоретически есть - у каждого портового комиттера есть возможность положить 
дистфайлы
в собственной каталог на серверах FreeBSD и прописать источник дистфайла как 
LOCAL/...,
примеров достаточно в дереве.

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

> Подумал о github c tar в виде релизов. Но это ведь не мои программы...

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

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] Вопрос по ForwardX11

[Eugene Grosbein]

24.11.2020 11:01, Nick Kostirya пишет:
> Привет.
> 
> У меня вопрос по ForwardX11.
> 
> Есть локальный компьютер с X.org и второй, назовем его "сервер".
> На локальном установлены более старые программы.
> 
> Запускаю на сервере более новый gvim и вижу, что если на локальном нет 
> запушеного gvim, то передо мной открывается окно нового gvim c сервера. Но 
> если есть запущенный локально старый gvim, то при запуске на сервере получаю 
> новое окно со старым gvim.
> 
> С броузером ситуация аналогичная. Даже более интересная.
> Когда локально не запущен броузер, с сервера запускается более новый, но он 
> каким то образом имеет часть с информации с локального компьютера. 
> 
> Получается, что ForwardX11 это не только проброс картинки, а что-то еще.
> 
> Но если на локальном компьютере gvim собран c GTK2, а на сервере - с GTK3, то 
> такого эффекта нет.
> 
> Локально X запускаю так
> startx -- -listen tcp
> и указываю
> xhost +...
> 
> На сервере только устанавливаю env DISPLAY
> 
> Может как-то можно сделать, чтобы был только проброс картинки?

Этот поведение не X-сервера, а самих приложений. Не сталкивался с gvim,
но Firefox при старте ищет в X-сервере свою сессию, и если находит,
то активирует ранее запущенный процесс, а сам завершается.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] mismatched checksums

[Eugene Grosbein]

13.06.2020 3:01, Taras Heichenko пишет:
> 
> 
>> On 12 Jun 2020, at 16:59, Eugene Grosbein  wrote:
>>
>> 12.06.2020 12:05, Valentin Nechayev пишет:
>>
>>> Fri, Jun 12, 2020 at 10:27:46, eugen wrote about "Re: [freebsd] mismatched 
>>> checksums": 
>>>
>>>> Слово __pycache__ намекает на то, что там лежит некий "кеш", то есть 
>>>> изменяемые файлы,
>>>> проверить это можно через ls -l для сравнения даты создания/модификации 
>>>> этого файла
>>>> с датой создания других файлов того же пакета вне кеша.
>>>>
>>>> Суть контрольных сумм - обнаружить взлом, подмену файлов, поэтому 
>>>> изменяемым файлам не место
>>>> в списке защищаемых котрольной суммой, такие кеши согласно принятой на фре 
>>>> иерархии
>>>> должны жить внутри /var/db.
>>>
>>> Дело в том, что этот кэш должен быть идентичным для комбинации
>>> конкретного исходного файла и версии Питона.
>>
>> Дата модификации на 11 секунд позднее других файлов пакета намекает на такой 
>> сценарий:
>> порт или пакет установлены по зависимости, затем 11 секунд на 
>> загрузку/установку пакета
>> или сборку зависящего порта порта, при которой вызывается код из 
>> свежепоставленного
>> pycparser, который перегенерирует файл в кеше, при этом файл таки меняется,
>> раз уж контрольная сумма поменялась.
> 
> George L. Yermulnik в самом начале обсуждения давал ссылку на описание и 
> обсуждение бага, где
> достаточно внятно объяснено, откуда он лезет и как его можно полечить.
> 
> There is no problem with pkg check -q -s py36-pycparser immediately after 
> installation.
> But after python -c 'import pycparser', problems arise.
> 
> But python -c 'import pycparser' only updates it once.
> Perhaps we only need to run python -c 'import pycparser' once before 
> recording the checksum.
> 
> обсуждение датировано ноябрем-декабрем прошлого года.

Ну, это почти то же самое другими словами. Проблема в том, что "run" чего-нибудь
может быть проблематично в условиях кросс-компиляции, когда целевая платформа,
к примеру, ARM или MIPS, а мы собираем образ на amd64.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] mismatched checksums

[Eugene Grosbein]

12.06.2020 23:52, Maxim Sobolev пишет:

> По поводу предложения "игнорировать контрольную сумму" я бы поаккуратнее с 
> этим. Этот PYC/PYO код между прочим исполняется на вашем тазике и миллионах 
> других тазиков. А вдруг как враг пролезет и поменяет какой-нибудь безобидный 
> модуль который юзается ну скажем certbot на что-то свое, админ никогда этого 
> не заметит и не оценит.

Потому и сказал, что этот вариант мне не нравится.

Интересно, что будет, если при первоначальной установке делать таким файлам 
chflags uchg,
запрещать изменять его независимо от прав доступа без снятия флага. Для 
эксперимента.

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] mismatched checksums

[Eugene Grosbein]

12.06.2020 12:05, Valentin Nechayev пишет:

>  Fri, Jun 12, 2020 at 10:27:46, eugen wrote about "Re: [freebsd] mismatched 
> checksums": 
> 
>> Слово __pycache__ намекает на то, что там лежит некий "кеш", то есть 
>> изменяемые файлы,
>> проверить это можно через ls -l для сравнения даты создания/модификации 
>> этого файла
>> с датой создания других файлов того же пакета вне кеша.
>>
>> Суть контрольных сумм - обнаружить взлом, подмену файлов, поэтому изменяемым 
>> файлам не место
>> в списке защищаемых котрольной суммой, такие кеши согласно принятой на фре 
>> иерархии
>> должны жить внутри /var/db.
> 
> Дело в том, что этот кэш должен быть идентичным для комбинации
> конкретного исходного файла и версии Питона.

Дата модификации на 11 секунд позднее других файлов пакета намекает на такой 
сценарий:
порт или пакет установлены по зависимости, затем 11 секунд на 
загрузку/установку пакета
или сборку зависящего порта порта, при которой вызывается код из 
свежепоставленного
pycparser, который перегенерирует файл в кеше, при этом файл таки меняется,
раз уж контрольная сумма поменялась.

> Поэтому его и можно учитывать в пакете.

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

___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] mismatched checksums

[Eugene Grosbein]

11.06.2020 21:47, Taras Heichenko пишет:
> Hi!
> 
> Последнее время фря регулярно по ночам ругается
> 
> Checking for packages with mismatched checksums:
> py37-pycparser-2.20: 
> /usr/local/lib/python3.7/site-packages/pycparser/__pycache__/c_ast.cpython-37.pyc
> 
> Я так понимаю, что это просто некая неаккуратность. Но грызет меня червячок 
> совершенства. Подскажите,
> куда пнуть, чтобы это поправили? Или может это только у меня такое вылазит – 
> тогда что я делаю не так?

Слово __pycache__ намекает на то, что там лежит некий "кеш", то есть изменяемые 
файлы,
проверить это можно через ls -l для сравнения даты создания/модификации этого 
файла
с датой создания других файлов того же пакета вне кеша.

Суть контрольных сумм - обнаружить взлом, подмену файлов, поэтому изменяемым 
файлам не место
в списке защищаемых котрольной суммой, такие кеши согласно принятой на фре 
иерархии
должны жить внутри /var/db. К сожалению, это не всегда согласуется с дефолтной 
раскладкой
каталогов порта и лень маинтейнера (или его незнание об этом моменте) приводит
к таким вот коллизиям: все устанавиваемые пакетом/портом файлы должны быть 
перечислены
в pkg-plist и контрольные суммы для всех файлов из pkg-plist создаются и 
проверяются
автоматически. Если пакет ставит "предсозданный" кеш, а потом его обновляет,
вылазит эта хрень.

По хорошему надо пинать маинтейнеров инфраструктуры python.mk, группу 
port...@freebsd.org,
потому что это вряд ли проблема отдельного питоновского модуля, это 
инфраструктурная проблема.


___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd