Re: [freebsd] dma(8) mail forwarding

[Valentin Nechayev]

 Wed, Jun 29, 2022 at 16:55:32, vsasjason wrote about "[freebsd] dma(8) mail 
forwarding": 

> Jun 29 12:33:45 freebsdvm dma[961a.7b883c0c050][56265]: remote
> delivery to smtp.google.com [64.233.165.26] failed after final DATA:
> 550-5.7.1 [x.x.x.x] Messages missing a valid address in From: header,
> or^M 550 5.7.1 having no From: header, are not accepted.
> s5-20020a2e81c500b0025a97d857besi6415ljg.150 - gsmtp
> 
> Чего же мне такого интересного в последнем скрипте не хватает, что
> даже MASQUERADE не помогает? Я неправильно воспринимаю ошибку gsmtp?

А эту dma нельзя попросить записать её общение в plaintext?

А если связать с пробным MTA и без SSL?


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

Re: [freebsd] AWS Tech Conference

[Valentin Nechayev]

 Wed, Jun 29, 2022 at 21:34:49, eugen wrote about "Re: [freebsd] AWS Tech 
Conference": 


> > Напоминаю, что в наше неспокойное время заметная часть того, что
> > собирается в контейнерах, поступает в виде кода всяких 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 ни капельки не секрет.

> А если будут запускать uname,
> то /etc/profile или другие способы заполнить environment ничуть не хуже.

Может таки проверишь в следующий раз до постинга? ;)


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

[freebsd] (no subject)

[Valentin Nechayev]

 Wed, Jun 29, 2022 at 16:05:06, vsasjason wrote about "Re: [freebsd] AWS Tech 
Conference": 

> Вот в том числе этим и плохи спамеры -- наброс ссылки и начался флейм
> на 3 дня. Что, вероятно, повлияло на внимание к другим тредам в
> рассылке, которые точно по теме. :-)

А я только "за". Другие треды не денутся, кто знает - тот ответит. А
тут и так слишком мелкий поток.


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

Re: [freebsd] AWS Tech Conference

[Valentin Nechayev]

 Wed, Jun 29, 2022 at 20:03:08, eugen wrote about "Re: [freebsd] AWS Tech 
Conference": 

> >> И что? Их можно в /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.

Осталось понять, какая доля из тех, кто спрашивает эти параметры,
запускает внешнюю команду :)
Напоминаю, что в наше неспокойное время заметная часть того, что
собирается в контейнерах, поступает в виде кода всяких Go и Rust,
которые даже libc обходят, а вместо этого используют свой комплект
сисколлов и врапперов.


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

Re: [freebsd] AWS Tech Conference

[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 прописать даже.

И кто их оттуда читать будет?


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

Re: [freebsd] AWS Tech Conference

[Valentin Nechayev]

hi,

 Wed, Jun 29, 2022 at 12:38:29, i wrote about "Re: [freebsd] AWS Tech 
Conference": 

> >> Причём много этого всего есть задолго до того, как оно появилось в linux.
> > 
> > Ой я бы не спешил с подобными историческими выводами:)
> 
> Всё началось где-то в 2006-м году, когда Google надоело поддерживать 
> внутреннее глубоко кастомное ядро, и они опубликовали свои разработки для 
> Borg, которые теперь известны как cgroups.
> До этого все в линукс мире верили “фигня эти ваши jail-ы, будущее за 
> виртаулизацией”.

В моей проекции линуксового мира каждый второй, кто задолбался тому,
что как хостеру ему приходится сочетать требования десятка разных
пользователей с индивидуальными настройками PHP, радовался любой
возможности загнать каждого пользователя в свой chroot, а потом
сделать ему какой-то шейпинг ресурсов, чтобы озверелые скрипты не
сжирали всё что могли, а также чтобы он держал персональный mysql и
опять же не морочил голову "вы другим слишком много даёте".
И тут пришли некие ребята со своим VZ (Virtuozzo) и сказали - а у нас
всё из коробки и в шоколаде... и это было уже кто мог платить - в
2000 (помню, как в Зеноне хвастались, что они это умеют и у них нет
"через месяц мигрируем на 4.1.2, кто не переписал код, тот сам
виноват"). В Киеве было несколько пиратских Virtuozzo на хостингах. А
в 2005 сделали уже OpenVZ - меньше, но достаточно для мелких. И это
только одна из таких разработок, хотя самая выдающаяся. То, что ты
вспоминаешь про 2006, это именно что гугл решил опубликовать для всех.
И район 2008-2012 это вечные мучения "делать на OpenVZ или на LXC?",
которые закончились только с появлением Docker.

(Давно хочу написать едкую статью типа "Чем хуже, тем лучше, или PHP
как крёстный отец Docker";))

> Но это не принципиально для вопроса.

Как раз принципиально. Именно путь: веб-хостинг (~90% на PHP) =>
контейнеры (начиная с chroot) -> усиленная контейнеризация - привёл к
тому, что все BSD были выкошены с этого, самого бурного и активного,
рынка. Как BSD выехали на новом рынке за счёт того, что у них сеть
работала лучше конкурентов и не требовала лицензий и прочих извратов -
так на следующем новом рынке они и потеряли первенство, отстав реально
на десятилетие.


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

Re: [freebsd] AWS Tech Conference

[Valentin Nechayev]

hi,

 Wed, Jun 29, 2022 at 10:05:47, i wrote about "Re: [freebsd] AWS Tech 
Conference": 

> > 2. своё пространство pidʼов
> 
> Похоже что нету, но на самом деле не очень то и надо - вообще то pid-ы 
> изнутри docker контейнеров тоже прекрасно видны на host системе.

Во-первых, видны, но под своими номерами. В контейнере иерархия
строится от pid=1, дальше последовательно 2, 3 и так далее, а у хоста
они видны иначе. Вот я заглянул execʼом в контейнер:

/ # ps ax
PID   USER TIME  COMMAND
1 root  0:00 sleep 3600
   10 root  0:00 /bin/sh
   15 root  0:00 ps ax

А вот я смотрю на то же самое из хост-системы:

4037136 ?Sl 0:00 /usr/bin/containerd-shim-runc-v2 -namespace moby -i
d cc8eb0bd81e855e58132d5db46ae35a534bf746abeb6fd4d8e20459ae683b47a -address /var
/run/docker/containerd/containerd.sock
4037157 ?Ss 0:00  \_ sleep 3600
4042116 pts/0Ss+0:00  \_ /bin/sh

Во-вторых, эта видимость односторонняя (ещё бы).

(Вот что плохо, что соответствие pidʼов хоста и контейнера надо искать кривыми
путями. Видимо, обычно мало кому нужно.)

> > 3. шейперы разных шедулеров (CPU, IO, память) и пространства учёта
> 
> Есть через rctl, который умеет дружить с jail: 
> https://docs.freebsd.org/doc/9.2-RELEASE/usr/share/doc/freebsd/handbook/security-resourcelimits.html

Жестковато и неиерархично, но для начала сойдёт.

> Частично есть: cpuset.id в jail(8). Но на самом деле не так часто 
> используется в K8s.

Где как... мы сейчас в контейнерах привязываемся через DPDK к сетевым
интерфейсам, там это критично.

> Повторюсь: большинство необходимых компонент есть, а чего нету, то можно 
> доделать и/или не так уже и критично на самом деле.

Я вообще-то не утверждал, что его нет :)
я говорил, что для полноценного контейнера нужно много больше, чем те 2-3
пункта, что привёл Евгений.
Это сейчас мы уже перешли к конкретным пунктам, есть или нет, и как именно.

> Причём много этого всего есть задолго до того, как оно появилось в linux.

Ой я бы не спешил с подобными историческими выводами:)

> Только никто не будет это всё ручками лепить докучи. Надо чтобы всё это было
слеплено в стандартизированный СRI. И вот этого нету.

Да, похоже на то.


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

Re: [freebsd] AWS Tech Conference

[Valentin Nechayev]

hi,

 Tue, Jun 28, 2022 at 04:14:26, eugen wrote about "Re: [freebsd] AWS Tech 
Conference": 

> Jail это chroot плюс опционально виртуализированный сетевой стек
> плюс запрет руту из клетки влиять на хост.

Судя по тому, что можно видеть в комплекте всяких cgroup, в опциях
clone и так далее, параметров сильно больше:
1. chroot (уже сказано)
2. своё пространство pidʼов
3. шейперы разных шедулеров (CPU, IO, память) и пространства учёта
4. ограничения на набор допустимых устройств (тех что в /dev)
5. сетевой стек (инстанс, интерфейсы)
6. идентификация ядра (ответ на uname)
7. отдельное пространство IPC (если не сделано через FS)
8. CPU affinity (ограничение сверху и возможно маппинг)
9. таки да, запрет "влиять на хост", и это может быть сложно (что
можно монтировать, а что нет)
И это я наверняка мог ещё что-то потерять (если заглянуть в
/proc/cgroup в podʼе под k8s, видны hugetlb и какой-то freezer).

В принципе повторить всё это не проблема, но конкретный механизм...

> Не виртуальная машина даже близко,
> для этого bhyve.

Кэп:)

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

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


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

Re: [freebsd] AWS Tech Conference

[Valentin Nechayev]

hi,

 Mon, Jun 27, 2022 at 11:18:53, vladimir.sharun wrote about "Re: [freebsd] AWS 
Tech Conference": 

Вообще хотелось бы увидеть актуальную сводку "чего именно сейчас в
FreeBSD не хватает, чтобы запустить Docker" (ну или его полноценный
аналог).
Если оно есть, можно её рекламировать в плане, например, "у нас то
же самое, но линуксовый вирус не сработает". Если нет - то понимать,
чего именно не хватает.
Я уровня изоляции в jail уже не понимаю совсем, что именно там есть,
чего нет.
На следующем этапе Kubernetes (причём с плагинами типа Multus CNI). А
то с одной стороны хороший уровень сетевых возможностей, а с другой -
фиг их кто применит.

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

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

> Там весьма полезные концепты, которых у FreeBSD natively нет. Но
> есть повод задуматься.

Вот кто бы это 20 лет назад начал полноценно делать...


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

Re: [freebsd] AWS Tech Conference

[Valentin Nechayev]

hi,

 Mon, Jun 27, 2022 at 09:39:26, vsasjason wrote about "Re: [freebsd] AWS Tech 
Conference": 

> А фактически это просто спам от кого-то с 0 писем и 0 участия в жизни
> сообщества.

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


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

Re: [freebsd] AWS Tech Conference

[Valentin Nechayev]

hi,

 Mon, Jun 27, 2022 at 09:12:33, vladimir.sharun wrote about "Re: [freebsd] AWS 
Tech Conference": 

> Начнешь работу искать, сразу поймешь какое это имеет отношение к -.

"Захочешь есть - сразу поймёшь, какое отношение имеет реклама пончиков
к -"

Давайте не утрировать до такой степени.


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

Re: [freebsd] AWS Tech Conference

[Valentin Nechayev]

hi,

 Sun, Jun 26, 2022 at 23:40:23, freebsd wrote about "Re: [freebsd] AWS Tech 
Conference": 

> > 30 червня AWS User Group Ukraine організовує AWS Tech Conference
> > #StandWithUkraine для міжнародного AWS ком’юніті! Долучайтесь
> > безкоштовно: https://bit.ly/3nif2Cp
> Это имеет какое-то отношение к FreeBSD или хотя бы к OpenSource?

Ну FreeBSD можно запускать под AWS => отношение есть, хоть и
косвенное. Хотя хотелось бы, конечно, доклад в духе "мы на ней
используем Kubernetes и через AWS и напрямую, и это кое в чём лучше,
чем на Linux" :)


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

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

[Valentin Nechayev]

hi,

 Fri, Jun 24, 2022 at 14:30:01, eugen wrote about "Re: [freebsd] Есть ли 
особенности проброса порта в туннель?": 

> Только размер пакета: часто на туннеле меньше MTU и если у пакета выставлен 
> DF-бит
> и пакет больше next-hop MTU, он не пролезет.

А needfrag оно вернёт назад в этом случае?


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

Re: [freebsd] Ржавый

[Valentin Nechayev]

hi,

 Fri, Jun 10, 2022 at 15:32:34, vsasjason wrote about "Re: [freebsd] Ржавый": 

> Мда, "нетекущий" ржавый жрёт памяти на порядки больше, чем безб-жно текущий
> С...

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


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

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

[Valentin Nechayev]

hi,

 Sun, Jan 02, 2022 at 13:14:20, spell wrote about "Re: [freebsd] 13.0 memstick 
не грузится": 

> Разумеется, легаси и прочее "640K хватит на все" приходится тащить,
> куда деваться. Я больше про то, что, похоже, каждый новый трюк с картой
> памяти делали как последний, не "на вырост",

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

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

Ну во-первых это только один из вариантов, и сейчас так обычно _не_
делают (например, потому, что надо ограничить доступ к SMM памяти...
но это ещё один костыль). Мапят кусок отдельно, да, но доступ дают
только к этому небольшому участку. В любом случае, не стараются
контроллеру задать много работы, он просто не успеет.

А во-вторых - а зачем вообще тут непрерывность памяти?

1) Когда работает загрузчик (типа GRUB или фрёвый /boot/loader), ему
нужно распаковать всё ядро в связную область, ну и ещё пару мег на
данные старта с офигенным запасом - дальше ядро подхватит это и само
полетит. То есть считаем современному ядру достаточно ну даже 30MB (с
запасом в километр) одним связным куском, чтобы дальше разобраться
самому.
В принципе он и тут мог бы покрошить мелкими кусочками, но это
заморочнее потом восстанавливаться.

2) Когда инициализируется система управления виртуальной памятью в
ядре, ей нужен (на x86) небольшой "идемпотентно" отображённый кусок в
десяток килобайт (обычно в нижнем 1MB) для переключений, а дальше она
способна проитерировать все выделенные области и подготовить их для
нарезания по страницам (4KB, если не large/huge). Даже если бы было,
что идёт "полосатая" схема - 4KB есть, 4KB нет, 4KB есть, 4KB нет... -
она бы справилась.

И учтите, что может оказаться, что полная непрерывность адресов памяти
вообще невозможна даже если б не было выкусывания легаси-блоков. В
случае одного физического процессора, да, можно начинать мапить с
более толстых модулей памяти, тогда будет непрерывность. А представим
себе серверную материнку с 2 физическими процессорами и памятью -
сейчас в этом случае половина слотов памяти будет подключена к
контроллеру первого процессора, половина - второго. И вот ставим мы
48GB (32+16) на первый процессор (в слоты под его контроллером) и 40GB
(32+8) на второй. Имеем право, а больше не нашлось. Контроллеры памяти
могут просто не суметь поставить их так, чтобы получилась непрерывная
область.

Потому, ничего этого и не требуют.


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

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

[Valentin Nechayev]

hi,

 Fri, Dec 31, 2021 at 17:28:29, spell wrote about "Re: [freebsd] 13.0 memstick 
не грузится": 

> Аг, вот оно что.
> А в dmesg.boot сообщения между real memory и available memory - это этот же 
> список
> доступных сегментов?

Да.

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

Модели разные. Объём памяти разный. Модули памяти разного состава...

Если подробно, то картина выглядит так. В x86 сохраняется
совместимость с
1) 16-битным режимом и границей доступной памяти в 1MB;
2) 32-битным режимом и границей доступной памяти в 4GB.

Первое приводит к тому, что адреса 0xA-0xF (кусок между
первыми 640kB и границей 1MB) розданы исторически, ещё от первых IBM
PC, под видеопамять старых режимов и под BIOS (реально под RAM, в
которую скопирована часть BIOS). Кроме того, несколько первых и
последних килобайт занято под данные BIOS (включая ACPI).

Второе аналогично выглядит так, что часть адресов ниже границы 4GB
занято под спец. роли: например, local APIC ядра процессора - от
0xFEE0_ до 0xFEE0_0FFF. Менять это тоже не хотят.
Некоторые устройства могут так же требовать себе области памяти в
32-битной адресации (ниже 4GB), это можно определить прочитав их PCI
конфигурацию.

Теперь... представим себе 8GB RAM одним модулем. Если бы можно было
разместить его связным куском, он был бы от 0 до 0x1__. Но
описанные требования приводят к тому, что
1) должен быть максимум в интервале от 0 до 0x9 (те самые 640kB),
с потерей на данные BIOS, которые должны быть доступны и в реальном
режиме;
2) должен быть разумный объём (а для 32-битных систем - максимум) от
0x10_ до, например, 0xDFFF_ (например - может быть больше или
меньше);
3) всё остальное должно быть представлено выше границы 4GB и максимум
от того, что осталось от выделения под видеопамять, shadow BIOS и всё
такое (терять больше условно 1MB тут нежелательно, обидятся).
4) устройство должно быть как можно проще с точки зрения контроллера
памяти (никаких сложений-вычитаний адресов, только изменение отдельных
битов).

И вот надо сделать чтобы вывалившиеся 512MB ниже 4GB были всё-таки
доступны выше. Один из вариантов: сделать чтобы участок 8GB-16GB
контроллером памяти мапился в тот же модуль, а через карту памяти BIOS
запретить софту доступ к нему. Тогда получится карта вида:
1) 0x1000-0x9EFFF (4kB в начале и в конце BIOS откусил под данные);
2) 0x10_-0xDFFF_ (регулярный доступ, откушено 512MB на адреса
устройств);
3) 0x1__-0x1__ (регулярный доступ к остатку модуля);
4) 0x2_E000_-0x2__ (512MB которые не доступны в первых
4GB, доступны здесь).
При этом в контроллере памяти включена логика вида: участки
0-0x1__ и 0x2__-0x3__ одинаково отображены на
один и тот же модуль (но у первого выкушены приоритетно 2 диапазона
под I/O), и если просто сканировать их - получится вроде бы 16GB, но
BIOS знает, что реально второй идентичен первому, и разрешает из него
только тот кусок в 512MB, который "обошли" в первом 8GB.

А на другой машине вдруг окажется, что, например, установлены модуль
на 8GB и модуль на 16GB, причём BIOS решил замапить с нуля тот, что
16GB. Тогда он замапит этот 16GB дважды, из второго отображения
разрешит те же 512MB, а 8GB модуль замапит с адреса 0x8__
(32GB) и уже только один раз.

И с каждой новой версией северного моста (последние 10-12 лет
интегрирован в процессор) эта логика может чуть меняться. Ну и ревизии
BIOS могут её менять.

Гуглить можно по аббревиатурам типа TOLUD, TOUUD, документам типа "10th
Generation Intel Core Processor Families datasheet" и т.п. - там это
всё расписано подробнее.

И таки с Новым годом всех :))


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

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

[Valentin Nechayev]

hi,

 Fri, Dec 31, 2021 at 15:41:58, spell wrote about "Re: [freebsd] 13.0 memstick 
не грузится": 

> В биосе нет никаких настроек по поводу графики. Да, интегрированное (ноутбук).
> Так много откусило, потому что я затупила и поставила 32-разрядную, в которой 
> всего доступно 3.5G.

Вообще считается, что 64-битная ОС становится эффективна при памяти
где-то от 1.5GB.
Обоснование: если ядро может дважды замапить всю оперативную память на
виртуальное адресное пространство (первый раз для своего доступа и
второй - для исполняемого процесса) и ещё и поместить пространства
устройств ввода-вывода, то не требуется частого переключения страниц
на разные копирования; а как превышается этот размер - начинается
много тупой возни по созданию буферов для промежуточного копирования
через них.

> Но все равно это не объясняет, почему в самом начале находится всего 
> полгигабайта...

Таки похоже, что этот показатель можно игнорировать.
Его происхождение - см. $src/stand/i386/libi386/biosmem.c, переменная
bios_extmem, и комментарий /* look for the first segment in 'extended'
memory */. Extended memory вычитывается из отчёта e820, если доступен.
То, что разрывы в видимой памяти - это уже особенности политики
построения в x86.


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

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

[Valentin Nechayev]

hi,

 Fri, Dec 31, 2021 at 11:06:59, spell wrote about "Re: [freebsd] 13.0 memstick 
не грузится": 

> > на 4GB памяти:
> > 
> > real memory = 6442450944 (6144 MB)

Ой вот это точно не на 4GB :)

> 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)

Ну тогда получается, что оно отдаёт какой-то один из непрерывных
кусков. Тогда в этом самом по себе проблемы нет...


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

Re: [freebsd] printf в clang

[Valentin Nechayev]

hi,

 Fri, Dec 31, 2021 at 08:20:44, spell wrote about "Re: [freebsd] printf в 
clang": 

> > Именно что если в 32 битах, то всё логично, потому что:
> > 1. При передаче в переменном наборе аргументов (как printf) происходит
> > расширение всех целочисленных типов, которые у́же int, к int, а более
> > широкие не меняются.
> > 2. Соглашение о вызове предусматривает передачу всех аргументов на
> > стеке. Соответственно в позиции начала переменной области аргументов
> > укладывается: 03 00 00 00 02 00 00 00 (bv) 6f 00 00 00 (cid).
> > 3. printf согласно формату %ld извлекает long, который в этом режиме
> > 32 бита (равен int). Извлекается 03 00 00 00 (значение 3).
> > Второй %ld извлекает 02 00 00 00 (значение 2).
> 
> Так и предположила.
> Собственно, вопрос - это считается за баг, или "сам виноват"?

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

> Варнинг, конечно, это хорошо, но и обработка ситуации тоже важна.
> Вот например такой код:
> 
> printf("%ld %ld\n", bv, cid, cid);
> 
> выдаст варнинг насчет лишнего аргумента, но значение cid не выведет,
> хотя в стеке аргументов место для этого второго cid есть.

Да, потому что не сказано его печатать. А если будет, наоборот, лишний
%ld без параметра - выведется что-то со стека (условно, мусор).

В C++ это фиксили в основных средствах (iostreams, boost::format...) -
там есть контроль типов и параметры ввода-вывода устанавливаются во
время компиляции. В C такое как-то не завезли.


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

Re: [freebsd] printf в clang

[Valentin Nechayev]

hi,

 Thu, Dec 30, 2021 at 21:15:36, spell wrote about "[freebsd] printf в clang": 

> int64_t bv;
> long cid;
> bv = ( (int64_t) 1 << 33) + 3;
> cid = 111;
> printf("%ld %ldn", bv, cid);

Тут наверно должно было быть \n в конце форматной строки.

> clang резонно выдает варнинг о несоответствии типа первого аргумента (%ld 
> вместо правильного %lld).

Компиляция в 32 битах, я так понимаю? Потому что в 64 проблем не
видно.

> А вот вывод этой программы менее ожидаем:
> 
> 3 2
> 
> Первое число ожидаемо - младшие 4 байта от bv.
> А второе, вместо значения cid - старшие 4 байта от bv.
> 
> clang version 10.0.1.

Именно что если в 32 битах, то всё логично, потому что:
1. При передаче в переменном наборе аргументов (как printf) происходит
расширение всех целочисленных типов, которые у́же int, к int, а более
широкие не меняются.
2. Соглашение о вызове предусматривает передачу всех аргументов на
стеке. Соответственно в позиции начала переменной области аргументов
укладывается: 03 00 00 00 02 00 00 00 (bv) 6f 00 00 00 (cid).
3. printf согласно формату %ld извлекает long, который в этом режиме
32 бита (равен int). Извлекается 03 00 00 00 (значение 3).
Второй %ld извлекает 02 00 00 00 (значение 2).

В 64 битах проблемы не будет, потому что:

1. Первые 6 аргументов передаются в регистрах, включая переменные
аргументы (! - из-за этого va_arg c компанией заметно усложняется).
Форматная строка будет в rdi, bv - в rsi, cld - в rdx.
2. long и long long одинаково имеют 64 бита ширины и передаются
соответственно в полную ширину регистра.

Хорошо, что оно ворнинги пишет :))


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

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

[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?
Есть готовое средство автоматизации правки этого списка в конфиге?
(Не надо рассказывать про перловые трёхстрочники, я сам себе напишу
тут что угодно, вопрос про готовое и надёжное.)


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

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

[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

Это сработало, спасибо. Но это таки лечение не основной проблемы, мне
кажется.

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

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


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

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

[Valentin Nechayev]

hi,

 Fri, Sep 03, 2021 at 04:35:32, eugen wrote about "Re: [freebsd] unbound и 
отстающие часы": 

> > Оказалось, что кто-то из этих скриптов сумел вписать запись в
> > 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

Видимо, эффект оказался отложенным (на этот момент было 12.2-p7).


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

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

[Valentin Nechayev]

hi,

 Thu, Sep 02, 2021 at 14:09:36, vsasjason wrote about "Re: [freebsd] unbound и 
отстающие часы": 

> > Обнаружил эффект: FreeBSD под Virtualbox (12.2, в описанных
> > областях все параметры штатные). Хостовая машина периодически в
> > спячке, при этом локальное время в виртуалке останавливается.
> > Когда просыпается, виртуалке надо восстановить время.
> 
> И это -- работа guest additions. Там и нужно чинить...

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


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

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

[Valentin Nechayev]

hi,

 Thu, Sep 02, 2021 at 14:09:19, freebsd wrote about "Re: [freebsd] unbound и 
отстающие часы": 

> Можно глупый вопрос: а emulators/virtualbox-ose-additions установлен
> и запущены в госте?

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

# pkg install virtualbox-ose-additions
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 2 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
dbus: 1.12.20_5
virtualbox-ose-additions: 6.1.22

Number of packages to be installed: 2

The process will require 9 MiB more space.

Proceed with this action? [y/N]: y
[1/2] Installing dbus-1.12.20_5...
===> Creating groups.
Using existing group 'messagebus'.
===> Creating users
Creating user 'messagebus' with uid '556'.
pw: user 'messagebus' disappeared during update
pkg: PRE-INSTALL script failed

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

Спасибо, понаблюдаю. Но основным вопросом таки остаётся странность
работы unbound по умолчанию.


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

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

[Valentin Nechayev]

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

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


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

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

[Valentin Nechayev]

hi,

 Wed, Aug 04, 2021 at 19:28:11, vas wrote about "Re: [freebsd] Беда с KOI8-R в  
xfce4-terminal.": 

> Вот не знаю, как Фидо (Golded) перевести в UTF-8.

Golded я запускаю с прочей фидой под screen, у которого штатно есть
перекодировщик для koi8-r.
Но базовой кодировкой давно utf-8.

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

Проблема в том, что уже очень давно фактически не работает. Масса
проблем самых разных и странных, но начали слишком анноить.
Я терпел koi8 в системе до, кажется, 2015. Затем плюнул и перевёл всё
на utf-8.


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

Re: [freebsd] socket

[Valentin Nechayev]

hi,

 Wed, Apr 21, 2021 at 19:39:14, freebsd wrote about "[freebsd] socket": 

> Забыл открыть сокет в неблокирующем режиме.
> После select записывалось столько данных, сколько влезало, и операция записи 
> не блокировалась. 
> 
> А вот при запуске под Линуксом обнаружил эту ошибку, так как там запись 
> блокируется.
> 
> Это такая особенность FreeBSD или всех BSD?

Вообще-то все send() должны блокироваться, если не могут за раз
отправить все данные в ядерный буфер, и если nonblocking не выставлено
(включая MSG_DONTWAIT в опциях sendto/sendmsg).

Может, под FreeBSD этот буфер оказался больше?


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

Re: [freebsd] hyper-v + freebsd 12.2

[Valentin Nechayev]

hi,

 Wed, Mar 10, 2021 at 13:56:42, smeegulists wrote about "[freebsd] hyper-v + 
freebsd 12.2": 

> Такая проблема, на сервере установлена 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.

Перед этим ядро выводит достаточно подробный лог обо всех найденных
устройствах, посмотрите туда, что же оно нашло. Могут быть странные
варианты - da1, ada1, вообще что-то другое...

> Подскажите как решить эту проблему?
> 
> ЗЫ: В /boot/loader.conf есть строка hw.ata.disk_enable=1

Если там действительно da0, то оно не поможет - ata даёт ad или ada
устройства, но не da.


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

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

[Valentin Nechayev]

 Thu, Jan 21, 2021 at 10:47:47, gmn wrote about "[freebsd] ZFS - занимаемое 
пространство": 

> На этой файловой системе лежит каталог сайта (данные 7z):
> 1220 folders, 7395 files, 460629747 bytes (440 MiB)
> И 7z и mc сообщают одинаковый размер.
> А du и df - другой размер занимаемого пространства.

Я так понимаю, 7z и mc сообщают сумму видимых байт. du по
умолчанию округляет до блоков, как он их понимает (размер блока
берёт из данных FS). Про df на ZFS ничего не скажу...

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

Возможно, от этого разница только увеличится.


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

Re: [freebsd] boot

[Valentin Nechayev]

hi,

 Tue, Dec 29, 2020 at 05:28:37, nikolay.kostirya wrote about "[freebsd] boot":

> На домашнем компьютере у меня установлена с давних времен Windows 7 и FreeBSD.
> Загрузка сделана на основе NTLDR, который использует boot1 как простую копию 
> /boot/boot1 в виде C:\bootbsd.bin.
>
> Вопрос. Как boot1 находит boot2?
>
> На ноутбуке у меня установлен boot0 при помощи boot0cfg, и две FreeBSD.
> Предполагаю, boot1 ищет boot2 на том же разделе, где сам установлен?
>
> Но как boot1 тогда находит boot2, когда запускается из под NTLDR?

1. Читается таблица MBR (только 4 первичных раздела) с указанного диска
(его хэндл для BIOS вызовов, обычно 0x80).
2. В таблице ищется первый раздел с id 0xA5 и установленным признаком
"загрузочный" (flags & 0x80).
3. Если в пункте 2 ничего не найдено, ищется первый раздел с id
0xA5, уже не смотря на флаги.
4. С начала раздела грузится 8KB и передаётся управление на начало
boot2 в загруженном.

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

Дальше эта машина работает так: у неё уже есть readonly драйвер UFS.
Она ищет /boot.config на предмет, надо ли заменить текущее устройство
(пока что в понятиях BIOS) и /boot/loader на что-то другое. Если нет,
то ищет его на текущем устройстве. Если не нашло, грузит /boot/kernel,
но уже грузит криво, пригодно только к ремонтным работам.
/boot/loader уже умеет исполнять Forth, и на скриптах написано всё
прочее включая меню с демоном с вилкой.

> Если я поставлю еще одну FreeBSD и захочу использовать NTLDR, то как boot1 
> найдет нужный boot2.

Никак, он найдёт первый.
Но через флаг активного раздела можно переключать, откуда он будет
брать boot2 (и, что может быть важнее, /boot.config, а уже из этого
файла можно задать, откуда будет браться /boot/loader или что-то
вместо него).

> Или bsdlabel и gpart не просто копируют /boot/boot1 в нужную область диска, 
> но и прописывают информацию об boot2? И мне нужно будет для NTLDR 
> использовать не оригинальный /boot/boot1, а при помощи dd скопировать boot1 с 
> раздела второй FreeBSD?

Нет, на этом уровне такого не делается.

> Второй вопрос про FreeBSD, установленную на второй диск.
> В /usr/share/doc/faq/disks.html#NT-BOOTLOADER говориться, что нужно при 
> помощи boot0cfg подготовить boot0. А как?
>
> Просто указать boot0, что он загружен со второго диска?
>
> boot0cfg -B -d 0x81 -o setdrv,noupdate -s 1
>
> Или так не сработает, и нужно делать обычный boot0 с загрузкой MBR второго 
> диска?
>
> boot0cfg -B -o setdrv,noupdate -s 5

А откуда вообще пойдёт его грузить? По указанию в BIOS?

Если BIOS сразу загрузит со второго диска, то AFAIK эти пляски уже
не нужны, boot0 сразу узнает хэндл диска.
Всё это "-s 5" нужно, если BIOS пошёл грузить первый диск и хочется
через boot0 перекинуть загрузку на второй.

> Третий вопрос.
> Кстати, если 3 диска и везде стоит boot0, то по F5 они будет грузиться по 
> кругу?
> 1 -> 2 -> 3 -> 1 -> 2
> Или как?

После последнего оно идёт на флоповод, а не первый HDD.

=== cut ===
/*
 * If it was illegal or we cycled through them, go back to drive 0.
 */
xorb %al,%al# Drive 0
=== end cut ===

> Четвертый вопрос.
> На ноутбуке у меня 4 раздела: первые 2 с FreeBSD, третий - зашифрованный 
> home, четвертый большой.
> Использую два первых раздела для поочередного обновления. Например, работаю 
> за 11.2, вышла 12.1 - не трогаю 11, а вместо 10 ставлю 12. Если все 
> нормально, что использую ее, иначе продолжаю 11.
>
> Вопрос: на будущем новом ноутбуке стоит ли переходить на GPT или для такого 
> использования нет преимуществ перед MBR? Стоит ли также использовать на ноуте 
> ZFS? С ней не сталкивался подробно, так как не админ, а обычный юзер. :-)

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

Про ZFS пусть расскажут те, кто её плотно мучал, но я помню, что она
хотела много оперативки, а на лаптопах с этим сложнее.


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

Re: [freebsd] mismatched checksums

[Valentin Nechayev]

 Fri, Jun 12, 2020 at 10:27:46, eugen wrote about "Re: [freebsd] mismatched 
checksums": 

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

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

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

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

Может и модуля. Я вот сейчас борюсь с тем, что CFFI пересоздаёт в
некоторых случаях целевой soʼшник (причём в нескольких процессах
параллельно, и они начинают драться за линковку - реальный сюр).


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

Re: [freebsd] Не все письма из рассылки доходят до подписчиков.

[Valentin Nechayev]

hi,

 Wed, Jun 03, 2020 at 12:05:13, tasic wrote about "Re: [freebsd] Не все письма 
из рассылки доходят до подписчиков.": 

> А нельзя попробовать все перестроить с нуля? Ведь по миру народ пользуется 
> mailman'ом, и похоже
> без таких проблем. Т.е. переустановить mailman пересобрать ему базу подписки 
> (или это невозможно?).

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


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

Re: [freebsd] Не все письма из рассылки доходят до подписчиков.

[Valentin Nechayev]

hi,

 Wed, Jun 03, 2020 at 10:50:46, eugene wrote about "[freebsd] Не все письма из 
рассылки доходят до подписчиков.": 

> Здравствуйте, коллеги, а также администраторы рассылки!
> Обнаружил, что не все письма из рассылки до меня доходят.
> Недавно я писал сюда с темой "ipsec freebsd <-> mikrotik: пропадает
> соединение. "
> 
> В рассылке вижу своё первоначальное письмо и последний ответ
> Александра Дружинина.
> Хотя дважды мне отвечал Евгений Гросбейн, и я в свою очередь ответил
> на оба его сообщения (в рассылку).
> Но эти сообщения в рассылке до меня не дошли. В архиве есть.
> Сообщения Евгения я получил только потому что он дублировал их на мой адрес.

Хм, мне это всё сильно не нравится, потому что даже в плоском архиве последнее
письмо за 18 мая :(
mailman недиагностируем без глубоких плясок в потрохах. Похоже, надо менять.
Сейчас убрал reject_unlisted_recipient у postfix как пробную меру, но
если не поможет, значит, проблема глубже.


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

Re: [freebsd] Ламерский вопрос

[Valentin Nechayev]

hi,

 Thu, Mar 26, 2020 at 18:14:53, tasic wrote about "[freebsd] Ламерский вопрос": 

> Каталоги, названные с использованием кириллических символов показываются 
> правильно.
> Но я не могу их набрать в командой строке. При попытке набрать что-нибудь 
> кириллицей, выскакивают
> 
> :\262\320\321\321\320\320\320
> 
> Вообще нажатия клавиш передаются на удаленную машину правильно. В vim текст 
> кириллицей набирается
> без проблем. Т.е. впечатление, что bash'у нужно что-то сказать, чтобы он в 
> командной строке воспринимал
> этот ввод правильно. Но что?

Проверь ~/.inputrc и /etc/inputrc.
Подозрительные настройки будут со словом meta.
https://tiswww.case.edu/php/chet/readline/readline.html

Если не то, надо на локали проверить, что её установка работает перед
запуском bash. Проще всего запустить ещё один под ним и проверить,
работает ли на нём. Но это может быть важно только для очень старой
системы.


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

[freebsd] ** квотинг - Re: FreeBSD 12.1 + Mellanox MT27710

[Valentin Nechayev]

hi,

 Mon, Mar 23, 2020 at 22:11:55, vvd wrote about "Re: [freebsd] FreeBSD 12.1 + 
Mellanox MT27710": 

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


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

[freebsd] ** доставка

[Valentin Nechayev]

hi,
пока все играют в тишину (ждут вердикта по доставке?):
переключил на обязательный VERP на каждое письмо; есть заметные шансы, что
это решит проблему. Кто ждёт отмашки - вот она тут :)
Детальный отчёт - по накоплению данных.

Архивы на вебе: http://mailman.uafug.org.ua/pipermail/freebsd/
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

[freebsd] TEST

[Valentin Nechayev]

Не надо отвечать, проверю по логам.

 Thu, Feb 06, 2020 at 11:48:23, netch wrote about "** проблемы с доставкой": 

> в последнее время обнаружилось, что mailman не доставляет письма части
> подписчиков (непонятно какой) без внятных на то причин (не видно
> ограничений в конфигурации). Пока разбираюсь, можете проверить, есть
> ли для вас пропуски, по архивам, кто видит явную недоставку - прошу
> написать лично.
> Архивы лежат на: http://mailman.uafug.org.ua/pipermail/freebsd/


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

[freebsd] ** проблемы с доставкой

[Valentin Nechayev]

hi,
в последнее время обнаружилось, что mailman не доставляет письма части
подписчиков (непонятно какой) без внятных на то причин (не видно
ограничений в конфигурации). Пока разбираюсь, можете проверить, есть
ли для вас пропуски, по архивам, кто видит явную недоставку - прошу
написать лично.
Архивы лежат на: http://mailman.uafug.org.ua/pipermail/freebsd/
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd

Re: [freebsd] syslog и управление журналами

[Valentin Nechayev]

hi,

 Sun, Jun 09, 2019 at 17:26:35, upholder wrote about "[freebsd] syslog и 
управление журналами": 

> Есть пачка системных логов в каталоге /var/log/
> Есть logrotate для которого я не могу решить следующие задачи
> Обработка файлов по дефолту (т.е просто файлов подпадающих под *.log)

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

Как говорят в наших краях, "такое ТЗ это чистое ХЗ".
Но если сформулируете задачу чётко хотя бы для себя, это будет
половина решения.


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

Re: [freebsd] Which fib has running process

[Valentin Nechayev]

hi,

 Tue, Jan 22, 2019 at 09:38:11, krylov wrote about "[freebsd] Which fib has 
running process": 

Прошу не использовать html там, где достаточно text/plain.

FIB процесса можно узнать, например, так: ps -p 32265 -o fib.

От чего зависит, получится ли в данном FIB приконнектиться к
астериску, скорее зависит от того, коннект идёт через inet-сокеты или
unix-сокеты. Скорее всего, во втором случае именно второе и сработало. 
Но через ps проверять таки проще.


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

Re: [freebsd] DNS problem

[Valentin Nechayev]

 Tue, Jan 15, 2019 at 12:17:35, oleg wrote about "Re: [freebsd] DNS problem": 

>  Не видать glue records у 
> 
> namebrightdns.com.  172800  IN  NS  nbd1.namebrightdns.com.
> namebrightdns.com.  172800  IN  NS  nbd2.namebrightdns.com.
> 
>  Можно догадаться что это регистратор regery.net
> 
> Вряд ли что-то кардинально поможет.

glue records как раз есть.
А вот дальше интересно.
Бо̀льшая часть IP nbd[12].namebrightdns.com. не отвечает.
Но IP'шники для ns1, ns2 отдаются с gtld-servers.net, который ведёт и
com, и net, в additional section.
Дальше зависит от логики намеда, а она в этом аспекте как раз в районе
9.9, 9.10 заметно менялась. А именно, восприятие "попутно" переданных
записей из additional section было сильно ужесточено, и многие ранее
работавшие подходы перестали работать.
В частности, тут получается, что новая версия named те IP для
ns[12].namebrightdns.com, которые gtld-servers.net отдают в additional
при запросе для ns[123].regery.net, проигнорирует по новому
подходу - named пойдёт дальше искать и заново оттрейсит эти NS'ы по
авторитетной цепочке. И вот тут он и натыкается на то, что nbd[12] в
основном не отвечают, не позволяя получить авторитетный ответ даже для
собственных IP.
А те старые, которые всё из additional принимали на веру, пройдут
спокойно по цепочке, получат IP для ns[123].regery.net и в них найдут
финальную цель.

Что там с unbound, надо смотреть - раз тормозит, он тоже пытается
найти финально авторитетный ответ, но, может, он параллельно запускает
поиск.


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

Re: [freebsd] DNS problem

[Valentin Nechayev]

 Tue, Jan 15, 2019 at 11:23:04, gmn wrote about "[freebsd] DNS problem": 

> Проблема "околоBSD-шная" ...
> Прошу помощи знающих админов. Заранее спасибо.
> 
> Есть такой домен - ua.energy
> bind никак не может получить для него MX-записи (любые записи).

У меня SERVFAIL'ится на 9.9.4 на центоси.
Значит, BSD не очень при чём.
Я бы лог включил, да давно забыл, как это делается. :)

> Да, я вижу с доменом не все хорошо,

А видно, в чём именно? А то я пока явных диверсий не увидел.

> ua.energy.  86400   IN  NS  ns1.regery.net.
> ua.energy.  86400   IN  NS  ns2.regery.net.
> ua.energy.  86400   IN  NS  ns3.regery.net.
> couldn't get address for 'ns1.regery.net': not found
> couldn't get address for 'ns2.regery.net': not found
> couldn't get address for 'ns3.regery.net': not found
> dig: couldn't get address for 'ns1.regery.net': no more

У меня эти по отдельности резолвятся (подумав секунды 2).

Согласно BIND ARM есть опция resolver-query-timeout в options.
Поднял навскидку до 30, стало резолвить ua.energy MX.
Если у вас резолвер для клиентов, стоит таки подумать поднять её...


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

Re: [freebsd] exit utility

[Valentin Nechayev]

hi,

 Fri, Feb 09, 2018 at 10:10:15, spell wrote about "Re: [freebsd] exit utility": 

> Ммм.. Попробую перефразировать свою задачу:
> Требуется преобразовать строку в exitcode (0 или >0).
> 
> Можно, конечно, так:
> 
> [ $somestr = '0' ] && true || false
> 
> Но, по-моему, так было бы проще:
> 
> setstatus $somestr

[ "$somestr" = '0' ]

и оно же

test "$somestr" = '0'

всё, оно уже сделало всё, что нужно. Всё это "&& true || false" всего
лишь воспроизводят уже сделанную проверку, один в один.

Или вы упростили пример, или действительно просто наворачиваете
лишнее.

> Другими словами, в скрипте выполнять одно из двух действий в зависимости
> от содержания строки, но используя для ветвления не test а exitcode.
> Впрочем, я уже почти готова согласиться, что перемудрила..

См. выше.


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

Re: [freebsd] exit utility

[Valentin Nechayev]

hi,

 Fri, Feb 09, 2018 at 08:16:53, spell wrote about "Re: [freebsd] exit utility": 

> > $ set_status() { return $1; }
> > $ set_status 26
> > $ echo $?
> > 26
> 
> Спасибо, оно!
> (затупила подумать в эту сторону)
> (хотя всё-таки это дополнительная громоздкость, и для полноты счастья
> хотелось бы готового (даже не утилиту, а builtin, устанавливающий экситкод
> (переменную $?), наподобие builtin true/false))

Его не предусматривают, мне кажется, потому, что $? неустойчива - она
модифицируется каждой следующей командой. Поэтому, если кому-то этот
статус нужен дольше, чем на проверку одним выстрелом, он копируется в
другую, явно названную переменную, которая хранит результат уже
постоянно. А этой переменной уже можно присвоить нужное значение
напрямую, без подобных хитростей. Даже если после этого пользовать
конструкции && ||, это делается достаточно легко в стиле

test $saved_status = 0 && ветка1 || ветка2

Поэтому мне изначально вся проблема кажется надуманной, или попыткой
решения в условиях "категорически запретили приводить стиль к
нормальному". Или же какие-то ситуации в духе "100500 веток case,
из которых 99% просто передают статус последней команды в теле ветки,
но для 1% его надо выставить вручную" (а почему тогда не true/false,
они же тоже встроены?) - тоже редкий и странный вариант.
Но в первом ответе я не хотел акцентироваться на этом. Достаточно
того, что функции и return встроены в любой современный шелл и стоят
реально копейки.


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

Re: [freebsd] exit utility

[Valentin Nechayev]

hi,

 Fri, Feb 09, 2018 at 08:02:31, eugen wrote about "Re: [freebsd] exit utility": 

> > $ set_status() { return $1; }
> > $ set_status 26
> > $ echo $?
> > 26
> 
> +1
> 
> Только я бы обозвал функцию fail для похожести на true/false:

И тогда fail без аргументов будет создавать код возврата 0? Это жуткое
нарушение POLA, примерно как если бы утилита "yes" выдавала поток слов
"no".
Тут ни fail, ни success не подходят. set_status всё-таки прямое и
нейтральное.


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

Re: [freebsd] exit utility

[Valentin Nechayev]

 Thu, Feb 08, 2018 at 21:48:25, spell wrote about "[freebsd] exit utility": 

> В процессе скриптописания возникла надобность в утилите, подобной
> true/false, только с заданным значением кода выхода (пока обошлась
> вызовом "sh -c 'exit 123'").
> Если такая есть, просто ткните в неё, плиз.
> Если нету, скажите что это блажь, и суровые шелл-программисты вызывают
> целый шелл ради экситкода и не заморачиваются.

Метод 1 (кажется, самый эффективный)

$ set_status() { return $1; }
$ set_status 26
$ echo $?
26

Метод 2 (с fork, но без exec - всё равно дешевле, чем sh -c)

$ X=26
$ (exit $X)
$ echo $?
26


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

Re: [freebsd] FreeBSD wc -m

[Valentin Nechayev]

hi,

 Wed, Dec 27, 2017 at 16:29:36, skeletor wrote about "Re: [freebsd] FreeBSD wc 
-m": 

> >Если строку "test" поместить в файл (без перевода строки), то все ок:
> ># cat 1.txt | wc -m
> >    4
> >
> 
> Он есть:
> 
> $ echo -n test | wc -m
>4

Лучше даже так показать:

$ echo test | hd
  74 65 73 74 0a|test.|
0005


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

Re: [freebsd] ports management

[Valentin Nechayev]

 Sat, Dec 09, 2017 at 16:23:56, yz wrote about "Re: [freebsd] ports 
management": 

> От llvm обычно ничего не зависит. Его можно смело удалить.

От llvm (4.0) с некоторых пор зависят, парадоксально, иксы, через mesa-dri
или что-то подобное :) потому что генерируют код на ходу.
А с тех пор, как в него включён clang, начинает присутствовать и clang
(не тот, что в базовой системе).


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

Re: [freebsd] test и пустые строки

[Valentin Nechayev]

hi,

 Tue, Nov 21, 2017 at 14:55:11, spell wrote about "Re: [freebsd] test и пустые 
строки": 

> > Да, тут понятие null string требует расшифровки или замены на более
> > понятное, типа empty string.
> 
> Empty string не годится потому что в таком случае не отражает реальное
> положение вещей. Синтаксис же допускает как non-zero-length string и
> zero-lengh string так и отсутствие оной.

Эти случаи можно рассмотреть отдельно, получится понятнее.

> > Я в таких случаях _никогда_ не надеюсь на постулаты типа "эта команда
> > никогда не выдаст более одного слова";
> 
> Даже если эта команда - "echo 1"? ;)

Да.

> Моя команда точно не выводит более одного слова :)
> 
> > если где-то записано `x` вместо
> > "`x`", это следует считать прямой командой шеллу перепарсить вывод, а
> > такие команды не надо использовать, если нет на то прямого указания.
> 
> Не поняла, почему "перепарсить"?

Потому что он обязан это сделать. Принять строку, разделить IFSʼами
(field splitting) и набрать аргументов, сколько получилось после
разделения. А если в кавычках, то это правило выключается.

> > Ну и если "всё очевидно", то что мешает упростить работу шеллу в
> > случае test?
> 
> В смысле?

В смысле, что если "$x" вместо $x, не будет запускаться field
splitting, независимо от того, там одно реальное поле или нет.

> > > Да-да..
> > > Если бы мне дали всё исправить, я бы начала с того, что 0 - это true,
> > > а 1 - false. (начиная с машинной логики, а не только в шеллах)
> > 
> > Вот тут не согласен. В шелле такая логика потому, что успешных
> > завершений один код, а неуспешных - много. Но именно поэтому она
> > обратная.
> 
> Имхо, в шелле как раз нормальная логика. Успех - он и в Африке успех,
> для него достаточно одного кода. А поводов для файлура может быть
> множество, и когда каждый код выхода означает определённый reason -
> это просто счастье и благодать. И естественно отдать 0, как единственный
> в своём роде, успеху, а остальные ненули - ошибкам.
> И очень легко делать проверку: if (true), условно говоря.
> 
> А вот в Сишечке необходимость выворачивать наизнанку смысл
> кода возврата:
> 
> if (!somefunc()) printf("success")
> 
> меня расстраивает... Это при том, что логика кодов возврата
> та же (0 - success, >0 - failure).
> 
> Да и вообще! 0 - true и 1 - false логично хотя бы потому, что
> 0 - это чёт, а 1 - нечет. Само по себе понятие "нечет" (а хоть бы даже и
> odd) несёт в себе отрицательный смысл, и его логичней привязать к false.
> Щетаю, что из "0 - false" растут многие сложности, созданные на ровном
> месте и совершенно ненужные.

Честно - это надо обдумать. Беру таймаут.

> 
> > И не везде она такая (вон в Windows положительные коды -
> > успех, отрицательные - ошибка, и в обоих множествах 2 миллиарда
> > возможностей).
> 
> Зашибись решение. Стоит только не проследить за типом данных
> (signed/unsigned и длиной в байтах) как вуаля - лёгким движением руки
> отрицательное превращается в положительное.

Ну а в юниксах очень похоже.
Я не смотрел, какой интерфейс сисколлов в 64-битных FreeBSD, но в
Linux это так - значения от (со знаком) -4096...-1 это ошибки
(-errno), а остальные - положительные (например, дескрипторы файлов).
Ну а "не проследить" за такими вещами в C это настолько глобальная
ошибка, что вряд ли уже можно с ней мириться...


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

Re: [freebsd] test и пустые строки

[Valentin Nechayev]

hi,

 Tue, Nov 21, 2017 at 11:40:47, spell wrote about "Re: [freebsd] test и пустые 
строки": 

> Валентин, моё почтение за Ваше объяснение :)
> Даже жалко скипать, но, наверное, надо.

То не то чтобы объяснение, скорее оправдание :)
С моей точки зрения, шелл вообще в принципе нелогичный зверь. Два
самых известных варианта, как его замкнуть до адекватного состояния,
зовутся Perl и Tcl.

> Согласна, но почему бы об этом не упомянуть в мане? Сэкономило бы много
> времени не только мне. А лучше переписать usage syntax.
> Вот эта строка:
> 
>  stringTrue if string is not the null string.
> 
> и работающая конструкция "[ ]" дают надежду на то, что аргументы могут
> быть null'ами (это если не задумываться о реализации и наследии).
> Поскольку в околошелльных кругах нет устоявшихся понятий
> "null string", "zero string", "initialized variable" (нет же?), то
> описание типа такого, кмк, было бы более прозрачным:
> 
>  [string]  True if string is specified and it's length is not zero.

Да, тут понятие null string требует расшифровки или замены на более
понятное, типа empty string.

> > А теперь о случаях типа один аргумент, который проверяет на непустоту.
> > Тут одновременно и наследие (в смысле legacy), и простой сокращённый
> > случай - но это уже фактически та простота, которая не то хуже
> > воровства, не то "просто" требует очень внимательного отношения к
> > себе.
> 
> Эта "простота" мне вчера оказалась полезной :)
> Кмк,
> 
> [ `somelongcommandline` ] && dosomething || doother
> 
> выглядит получше чем
> 
> [ -n "`somelongcommandline`" ] && dosomething || doother

Мнэээ... вообще-то это уже диверсия. Например:

$ a() { echo 1 -eq 3; }
$ [ `a` ] && echo yes || echo no
no
$ a() { echo 1 -ne 3; }
$ [ `a` ] && echo yes || echo no
yes
$ a() { echo 1 2 3; }
$ [ `a` ] && echo yes || echo no
bash: [: 2: binary operator expected
no

то есть отсутствием закавычивания Вы уже пришли к тому, что
`somecommand` может выдавать несколько разделённых пробелом слов,
которые будут рассматриваться отдельно.
Это крайне хрупко и может быстро привести к настоящим дырам в
безопасности.
Я в таких случаях _никогда_ не надеюсь на постулаты типа "эта команда
никогда не выдаст более одного слова"; если где-то записано `x` вместо
"`x`", это следует считать прямой командой шеллу перепарсить вывод, а
такие команды не надо использовать, если нет на то прямого указания.

> > Как и вообще многое в шелле и вокруг. Test тут далеко не
> > единственный пример. Возьмём grep. Мы можем десятки раз писать что-то
> > типа "grep vasya /var/log/auth.log", но если шаблон приходит снаружи,
> > мы обязаны написать:
> > 
> > grep -e "$pattern" "$file"
> > 
> > причём важны и -e - указать, что тут шаблон, и кавычки - чтобы шелл
> > сохранил это одним аргументом, независимо от количества параметров в
> > нём.
> 
> С grep всё очевидно и согласно процедурам word expansion и quote removal.

Это про кавычки, а я также про -e для шаблона, который может
начинаться с '-'.
Ну и если "всё очевидно", то что мешает упростить работу шеллу в
случае test?

> > В случае test имеем несколько наслоений интерфейса - да, таки это
> > legacy. Первый, самый ранний, это тот самый одноаргументный вариант и
> > прочее связанное с ним.
> 
> А что ещё связано с одноаргументным вариантом?

С самым ранним, а не с одноаргументным. В первую очередь это та же
логика "ищем операцию согласно количеству аргументов", которая не
расширяема на более сложные случаи.

> С $(( )) связана отдельная боль...
> За вот это:
> 
> $ echo $(( 010 ))
> 8
> 
> повбывавбы...
> 
> Ну что мешало добавить буковку "o" аналогично "x" в хексе?:

+100. Самое ужасное, что это переносят и в новейшие языки (например, Go).

> Да-да..
> Если бы мне дали всё исправить, я бы начала с того, что 0 - это true,
> а 1 - false. (начиная с машинной логики, а не только в шеллах)

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


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

Re: [freebsd] test и пустые строки

[Valentin Nechayev]

hi,

 Tue, Nov 21, 2017 at 07:56:44, netch wrote about "Re: [freebsd] test и пустые 
строки": 

> (Если бы мне дали это всё исправить, я бы сделал вариант с только
> префиксной записью всех вариантов (например, `= arg1 arg2' вместо `arg1
> = arg2'), начальную опцию для него, и загнал бы это кувалдой в стандарт.

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


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

Re: [freebsd] test и пустые строки

[Valentin Nechayev]

hi,

 Tue, Nov 21, 2017 at 01:34:30, spell wrote about "Re: [freebsd] test и пустые 
строки": 

> > Я бы перефразировал: всплыло некорректное использование команды test.
> 
> О, это всё объясняет :) Спасибо.
> Только ни разу не очевидно, что null string в случае "[ $str ]" допустим,
> а в случае "[ -n $str ]" - нет. И тем более что оно молча fallback-ает в
> treating an option as a regular string. 

А какой собственно у неё выход?
Вот запускается test. Неважно, в каком виде - как test или как [ (во
втором случае оно просто финальный ] не считает параметром). У неё на
входе argc с количеством параметров и argv с их строками. И теперь
надо неким святым духом опознать, что и как было задано на входе, что
автор скрипта подразумевал как параметр, а что как операция?
Когда видим какую-нибудь -n, это опция самой test, опция вызванного
скрипта, которую этот test проверяет, прочтённая из файла строка, имя
файла или что-то иное? Отличить их так нельзя, в отличие от
"полноценного" языка программирования, где чётко видно, где одно, а
где другое. И при этом неважно, у нас какого стиля язык. Например, для
C++

if (a != b && s1 != "!=" && s2 == "&&") { puts("ой всё"); }

или для LISP (неважно, какой диалект)

(if (and (= a b ) (not (streq (s1 "!=")) (streq s2 "&&"))) (puts "ой всё"))

синтаксис даёт их различать так, что спутать невозможно. А для test
такого нет. Уж такой интерфейс достался, извините.

Поэтому, для test есть формы гарантированно надёжного использования
проверок, которые не страдают от того, что где-то какое-нибудь "="
оказалось операцией самого test, а где-то - аргументом для этой
операции. Если у него два аргумента и первый равен "-n", это проверка
на непустоту. Если три аргумента и средний равен "=", это проверка на
текстовое равенство. Если три аргумента и средний равен "lt", это
проверка на числовое "меньше". И ещё несколько аналогичных операций.
Собственно, это всё, что гарантируется стандартом без побочных
эффектов (см. ниже - можете полный набор сами прочитать).

А теперь о случаях типа один аргумент, который проверяет на непустоту.
Тут одновременно и наследие (в смысле legacy), и простой сокращённый
случай - но это уже фактически та простота, которая не то хуже
воровства, не то "просто" требует очень внимательного отношения к
себе. Как и вообще многое в шелле и вокруг. Test тут далеко не
единственный пример. Возьмём grep. Мы можем десятки раз писать что-то
типа "grep vasya /var/log/auth.log", но если шаблон приходит снаружи,
мы обязаны написать:

grep -e "$pattern" "$file"

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

В случае test имеем несколько наслоений интерфейса - да, таки это
legacy. Первый, самый ранний, это тот самый одноаргументный вариант и
прочее связанное с ним. Когда осознали возможность конфликта с
опциями, добавили гарантированный вариант. Но из-за принципиальной
проблемы на уровне передачи аргументов оказалось, что есть
относительно немного надёжных форм. В частности, если не применяется
XSI расширение со скобками, то гарантия даётся на корректный парсинг
только одной проверки; если нужно две и больше - это делается на
уровне вызывающего шелла, а не самой test. Например, вы не можете
написать

if [ "$a" = 1 -a "$b" = 2 ]; then

надо писать вместо этого

if [ "$a" = 1 ] && [ "$b" = 2 ]; then

Зато при этом не надо ставить префиксы аргументам.

А вот если допустить проверку с объединителями стиля XSI (-a, -o,
скобки), можно писать несколько условий. Но тут начинается новая
проблема: а что, если одним из параметров придёт -a, -o, числовая
операция типа -eq, или скобка?
Вот тут уже для строковых операций можно исключить это проверками
вида:

if [ "x$a" = x1 -a "x$b" = x2 ]; then

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

Стандарт можете почитать сами тут:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html

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

(Если бы мне дали это всё исправить, я бы сделал вариант с только
префиксной записью всех вариантов (например, `= arg1 arg2' вместо `arg1
= arg2'), начальную опцию для него, и загнал бы это кувалдой в стандарт.
Примеры такого подхода есть - printf в стандарте вместо проблемного
echo. Проблемы неоднозначного парсинга были бы решены с гарантией и с
возможностью расширения на любые операции. Но сейчас имеем то, что
имеем.)


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

Re: [freebsd] измененные руками конфиги

[Valentin Nechayev]

hi,

 Sat, Nov 18, 2017 at 17:35:37, adobrovolskii wrote about "Re: [freebsd] 
измененные руками конфиги": 

> mergemaster -iFUP
> 
> *** Creating the temporary root environment in /var/tmp/temproot
>  *** /var/tmp/temproot ready for use
>  *** Creating and populating directory structure in /var/tmp/temproot
> 
> mtree: unknown user `auditdistd'
> mtree: failed at line 21 of the specification

`mergemaster -p' делалось на этой версии?


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

Re: [freebsd] измененные руками конфиги

[Valentin Nechayev]

hi,

 Sat, Nov 18, 2017 at 16:55:20, adobrovolskii wrote about "Re: [freebsd] 
измененные руками конфиги": 

> Что-то не идет каменный цветок. Возможно это все ещё проблемы из-за
> незаконченной когдато установки новой версии системы.
> How should I deal with this? [Use the existing /var/tmp/temproot]
> 
>*** Leaving /var/tmp/temproot intact

При малейших сомнениях в содержимом этого temproot - сносить!
Сохранять только если точно свежее от этой же версии и был ценный
результат мержа.


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

Re: [freebsd] Спасите-помогите и уши агрессора

[Valentin Nechayev]

hi,

 Wed, Sep 27, 2017 at 19:43:57, mstyslav wrote about "Re: [freebsd] 
Спасите-помогите и уши агрессора": 

пару слов как от фактического модератора, --

> имхо, т.к. группа все же _UA_FUG, то следует что-то решить с подписчиками и 
> прочими клиентами из-за поребрика... война все же идет!

Рекомендую решать это каждому персонально. Потому что действительно
непубличные данные не стоит вываливать даже в якобы ограниченное от
врагов публичное место - такое ограничение никогда не бывает
надёжным, если не построено на default deny any - а просто технические
обсуждения ничего не выиграют от закрытия.

> сорри за оффтоп!

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

> > Вы сначала копните что это за организация, откройте связанные сайты, а 
> > потом почитайте 111УК Украины.
> > 
> > 
> > Там столько интересного за 5 минут вылезло, лет на 10 за решеткой.

Тогда отправь plz по назначению :) я не уверен, что ответственные
структуры настолько успели восстановиться, что читают и этот ресурс.


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

Re: [freebsd] need py3 packages...

[Valentin Nechayev]

hi,

 Sat, Aug 05, 2017 at 22:30:09, marshall wrote about "Re: [freebsd] need py3 
packages...": 

> Можно попробовать описать опции сборки в /etc/make.conf создав отдельную 
> секцию для конкретного пакета:
> 
> .if ${.CURDIR} == ${PORTSDIR}/portsforsome/portname

1. Я предпочитаю другой стиль - например, так

.if ${.CURDIR:N*/ports/databases/mysql*} == ""

2. Это не поможет, если нужно иметь пакет одного и того же порта под
разные версии Питона.


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

Re: [freebsd] need py3 packages...

[Valentin Nechayev]

 Sun, Aug 06, 2017 at 00:30:14, eugen wrote about "Re: [freebsd] need py3 
packages...": 

> $ fgrep -A 6 user: /usr/ports/Mk/Uses/python.mk
> # Variables, which can be set by a user:
> #
> # PYTHON_VERSION- The chosen Python interpreter including the version,
> # e.g. python2.7, python3.3, etc. This allows the user
> # to override the currently chosen default version and
> # to install the port for a specific Python version.
> # It must not be set by a port.
> 
> То есть, пишешь PYTHON_VERSION=python3.5 в /etc/make.conf и получаешь 
> py35-scipy-0.19.0_2

Ага, похоже, работает.

Писать в make.conf это не совсем уместно (например, если мне нужны
впараллель py27-scipy и py35-scipy?), тут придётся дорабатывать как-то
ещё.
Но на вычитанное глазами проставление вручную работает, спасибо.

Грепать по user как-то не было привычки - тоже надо записать в методы
поиска...


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

Re: [freebsd] опции ядра

[Valentin Nechayev]

 Mon, Jun 19, 2017 at 20:31:07, eugen wrote about "Re: [freebsd] опции ядра": 

> > Случайно грохнул конфиг, с которым собирал кернел.
> 
> Вот как раз после этого приходит понимание того,
> что не надо держать конфиг ядра внутри /usr/src,
> туда надо класть симлинк куда-нибудь в $HOME/kernconf/MYKERNEL.

У меня этот штатный /usr/src/sys/${arch}/conf и общий conf находятся
под cvsbackupʼом, заодно это даёт показательные диффы при апгрейде
исходников.


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

Re: [freebsd] ZFS, TMPFS, pagedaemon/uma и подземный стук

[Valentin Nechayev]

hi,

 Sat, May 06, 2017 at 23:06:30, slw wrote about "Re: [freebsd] ZFS, TMPFS, 
pagedaemon/uma и подземный стук": 

> > Подозреваю, что это письмо ты второй копией тоже не получишь :)
> > Mailman слишком умничает в некоторых вопросах. В частности, подписчику
> > по умолчанию ставится флаг nodupes (можешь зайти через веб снять его),
> > при этом письмо не посылается, если такой получатель уже замечен в
> > h_To или h_Cc.
> > Причём штатных средств рулить это групповым образом от админа - нет
> 
> Default options for new members joining this list.
> (Details for new_member_options)

Это для новопришедших, а не уже заимпорченного. Видел, но поздно. :)
OK, снял галочку на новопоступающих. Ждём обратных жалоб типа "дупы в
эхе!"

> > (в отличие от плоского списка подписчиков), надо unpickleʼить
> > состояние рассылки и менять вручную.
> Membership List
> 
> not metoo -- Does the member want to avoid copies of their own
> postings? 

Это через веб. Предлагаешь 200+ подписчиков каждому менять галочки? :)
Но вообще-то not metoo не установлена (у большинства), в отличие от
nodupes.

> > Поскольку подписчик может таки себе это сам строить, я сильно не
> > заморачивался.
> вот уж блин спасибо.

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


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

Re: [freebsd] ZFS, TMPFS, pagedaemon/uma и подземный стук

[Valentin Nechayev]

hi,

 Sat, May 06, 2017 at 20:13:10, slw wrote about "Re: [freebsd] ZFS, TMPFS, 
pagedaemon/uma и подземный стук": 

> 2netch: а какого я не получил это письмо через рассылку?
> только копию в личную почту?

Подозреваю, что это письмо ты второй копией тоже не получишь :)
Mailman слишком умничает в некоторых вопросах. В частности, подписчику
по умолчанию ставится флаг nodupes (можешь зайти через веб снять его),
при этом письмо не посылается, если такой получатель уже замечен в
h_To или h_Cc.
Причём штатных средств рулить это групповым образом от админа - нет
(в отличие от плоского списка подписчиков), надо unpickleʼить
состояние рассылки и менять вручную.
Поскольку подписчик может таки себе это сам строить, я сильно не
заморачивался.


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

Re: [freebsd] [freebsd-beer] вау это просто огромная

[Valentin Nechayev]

hi,

 Thu, Mar 30, 2017 at 23:17:14, yz wrote about "Re: [freebsd] [freebsd-beer] 
вау это просто огромная": 

> Опять Нетч что-то тестит...? =)

Нет, это уже прорвался спам. И не поленился же кто-то подписаться...

> > Привет!
> 
> > Просто взгляните на это удивительные вещи, они являются удивительными! Вы
> > определенно будете любить их, здесь, взгляните подробнее


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

Re: [freebsd] ** Подписка и DMARC

[Valentin Nechayev]

hi,

Письмо попало в рассмотрение на модерацию, я его нашёл случайно.
Вы пишете с неподписанного адреса, или это было на то время, когда я
массово снимал флаг stopped-because-bounce (или как он там зовётся)?

 Thu, Mar 09, 2017 at 15:19:54, c.kworr wrote about "Re: [freebsd] ** Подписка 
и DMARC": 

> Как бы на будущее хотелось бы прояснить политику распространения
> списка рассылки. Не то чтобы я здесь часто бываю или много пишу, но
> попытаюсь просуммировать имеющиеся вопросы, возможно ещё кого-то это
> интересует.
> 
> 1. В данный момент рассылка не доступна на GMANE. Мне такой способ
> получения рассылки кажется более удобным, поскольку я могу
> тягать/смотреть только то что меня интересует и, соответственно, мне
> не нужно будет высылать всю эту почту. То есть если мой домен не
> желает получать почту вот в таком виде, почему я не могу поставить
> доставку на холд и смотреть на рассылку через GMANE? Формально это
> решит проблему без реконфигурации, смены адресов и так далее.

Этот вопрос не ставился в принципе. Видимо, имеет смысл такое сделать.

> 2. Текущая версия Mailman немного устарела, начиная с версии 2.1.18
> уже есть необходмый функционал для манглинга/враппинга. Возможно
> обновление Mailman могло бы предупредить такие кардинальные
> действия?

Не было необходимости заменять дистрибутивную версию (CentOS7) на
более новую. Хотя некоторые локальные патчи я туда вынужден был
докатить.

> Ну вот у меня например так сложилось что и другая почта тоже скоро
> получит DMARC. Ну вот шагает DMARC по планете, что с ним сделаешь.
> Мне он нравится тем, что в отличии от байеса, rbl и прочего он явно
> детерминирован и не подразумевает возможности недоставки необходимой
> почты в случае выполнения всех требований.
> 
> PS: Если я не ошибаюсь это касается и доменов с strict spf тоже, так
> как они явно запрещают доставку почту от этого домена с посторонних
> адресов. Правда не помню насколько буквально гугл исполняет такие
> политики.

Похоже, разница в том, что SPF проверяет конверт, а DMARC - заголовок.
С SPF проблемы не было. А с DMARC будут проблемы у любых списков
рассылок, которые не переписывают заголовок.


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

Re: [freebsd] Повторный запуск скрипта в cron

[Valentin Nechayev]

 Thu, Jan 26, 2017 at 20:57:08, yuri.kurenkov wrote about "Re: [freebsd] 
Повторный запуск скрипта в cron": 

> >Да кто ж спорит, что работает. До первого случая, когда снесли процесс ;)
> >
> >А вот с регулярным запуском из крона так сложнее - это надо уже сам
> >крон снести.
> >
> 
> 
> Да кто же спорит о том, что можно снести что-то. Да хоть патч
> Бармина накатить!.. ;) Я не настаиваю на гениальности сего решения.
> Я говорю о множественности этих решений без применения софта из
> портов. А оптимальность каждого решения зависит от условия
> конкретной задачи.
> 
> И если нужна одинаковая переодичность запуска, то тут крон. А если
> нужен определённый интервал между стоп и старт, то тут sleep в while
> или моё решение.

Так в том-то и дело, что не "или", а "и". Берём Ваш вариант и пишем в
крон:

* * * * * lockf -s -t10 <путь к локфайлу> while :; do <работа>; sleep 900; done
(времена старта и таймауты подкручиваются по вкусу)

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

> Да Ленин вариант с использованием ttys защитит от
> "процесс снесли".

Да. Но: только для рута; есть шанс снести при апгрейде.


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

Re: [freebsd] Повторный запуск скрипта в cron

[Valentin Nechayev]

 Thu, Jan 26, 2017 at 12:35:24, yuri.kurenkov wrote about "Re: [freebsd] 
Повторный запуск скрипта в cron": 

> >>Есть вариантиспользовать lock(1) для защиты от параллельных запусков, а 
> >>можно
> >>иначе. В crontab(5) для запуска скрипта используешь @reboot, а в самом 
> >>скрипте
> >>с помощью at(1) запускаешь самого себя с нужным тебе интервалом.
> >
> >OMG! %-\
> >
> 
> У меня была задача запускать скрипт через 15 минут после его
> завершения. Для меня это оказалось решением. Уже более 11 лет
> работает "костыль" и нет ему сносу... Кто-там нынче админит - не
> знаю, но "костыль" работает.

Да кто ж спорит, что работает. До первого случая, когда снесли процесс ;)

А вот с регулярным запуском из крона так сложнее - это надо уже сам
крон снести.


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

Re: [freebsd] Повторный запуск скрипта в cron

[Valentin Nechayev]

 Wed, Jan 25, 2017 at 20:56:24, marshall wrote about "Re: [freebsd] Повторный 
запуск скрипта в cron": 

> Можно реализовать через файл блокировки (в примере ниже переменная LOCK). Т. 
> е. при запуске скрипта создается файл, который не удаляется если задание не 
> завершено (например первый бакап длится больше заданного интервала вркмкни).

lockf тем и хороша, что залипания у неё нет. Если процесс умер,
ядерный flock снимается сам. Ну и для крона крайне вкусен таймаут
(если запускаешь раз в минуту - как раз ставь таймаут в минуту).

Для работы с FS, где flock() невозможен (старые NFS и т.п.) - есть
готовая тулза shlock (изначально - из комплекта cnews). Она не может
обеспечить идеальность, но пытается проверять все реально
отрабатываемые случаи.


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

Re: [freebsd] Посоветуйте git сервер

[Valentin Nechayev]

hi,

 Sun, Jan 22, 2017 at 16:39:41, admin wrote about "[freebsd] Посоветуйте git 
сервер": 

> Разработчикам нужно сервер контроля версий для множества мелких
> репозитариев с гибкими настройками прав доступа.

А почему freebsd@? Должен на ней ставиться?

> Они выбрали варианты:
> 
>1. git
>2. Mercurial
>3. subversion
> 
> 
> Я склоняюсь к git.
> Смотрю Gitosis и Gitolite, но их похоже забросили.
> Что посоветуете?

На текущей и предыдущей работе - gitlab. Настройки доступа к репо есть
по группам и отдельным пользователям. Авторизация по ssh или через
веб, веб неплохой. Система pull requestʼов.
Есть community версия, расширяемая до платной.

Ещё на предыдущей был Gerrit. Настройки доступа есть, стиль не помню.
Существенное преимущество - в предварительном ревью всего кода, от
человека и автоматическом (подключался Jenkins).
Недостаток - совершенно кошмарный стиль управления расширениями этого
ревью (через Prolog с нечеловеческой логикой).


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

[freebsd] Re: Обновление p5-* портов

[Valentin Nechayev]

 Fri, Dec 02, 2016 at 11:33:59, admin wrote about "[freebsd] Re: [freebsd] Re: 
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] 
Re: [freebsd] Обновление p5-* портов": 

> Мне клиент платит не за своевременные обновления, а за разовые, раз в
> несколько лет.

Независимо от прочей дискуссии - система, обновляемая раз в несколько
лет, фатально дырява почти всё время работы.


-netch-

[freebsd] ** Об обращениях и взаимном уважении (было: Re: от 10.3 на 11.0)

[Valentin Nechayev]

hi all,

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

1. Является безусловным фактом то, что сама атмосфера общения в
подобных рассылках, на форумах, в эхообластях и аналогичных местах
способствует неформальному общению коллег, которое переходит на "ты".
По этой причине, сам по себе факт обращения на "ты" не может быть
_априорным_ признаком неуважения.

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

В данном конфликте частично неправы оба участника:
* Anton Sayetsky - 1) переход на "ты" в ответ на систематическое "Вы";
  2) последующий грубый отказ соблюдать общепринятые правила;
  3) неконструктивные замечания и вообще неконструктивный тон во всём
  треде.
* Alexander Sheiko - чрезмерно резкий, провокационный выпад про "брудершафт"

но со стороны Anton Sayetsky значительно больше отклонений от
желаемого подхода.

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

 Wed, Oct 26, 2016 at 02:00:59, vsasjason wrote about "[freebsd] Re: [freebsd] 
Re: [freebsd] от 10.3 на 11.0": 

> >> Мои деньги к твоему заказчику никакого отношения не имеют
> >
> > Молодой человек, я с Вами на брудершафт не пил...
> Это интернет, детка. (с)
> Кроме того, "Вы" с заглавной используется исключительно в официальной
> переписке, каковой данная рассылка не является. Здесь вообще все
> равны, так что даже и со строчной "вы" - неправильно.
> Ну а брудершафт, кстати, с представителями собственного пола я не пью,
> так что придётся уж терпеть и переносить моё обращение таким, какое
> оно есть и без того. Как минимум до тех пор, пока netch@ не выступит с
> официальным заявлением о запрещении использования обращения "ты" в
> рассылке.

Выступаю. С официальным заявлением.
По отношению к одному конкретному собеседнику, см. выше - в
обязательном порядке. К остальным - соответственно формам, которые они
используют.

> > Имеет ровно в той же степени, как и Ваше поучение "сменить железо на
> > современное". Вы, почему-то посчитали его уместным.
> Вовсе нет. Повторюсь: выражения, подобные "сборка из сырцов -
> медленно/медленнее" - ложь, если высказаны без учёта дополнительных
> данных. А от тебя лишь было утверждение, что бинарный апдейт - 15
> минут, а компилять (из контекста) значительно дольше. Но оказалось,
> что скомпилять можно значительно быстрее 15 минут. Вот если бы ты
> написал: "на железе, которое я обслуживаю, сборка медленнее, чем
> бинарное обновление" - вопросов бы не было.
> 
> И на будущее: срач, выяснение отношений и трамвайное
> правдоискательство в данной рассылке не приветствуется проводить, ибо
> для этого личка есть. Так что если хочешь продолжить дискуссию по
> поводу того, как кто должен обращаться и какие советы давать - туда [в
> личку] и пиши далее.

В ответ на одну строку собеседника Вы привели сразу 5.
И реплика Шейко:

>> Любой каприз за Ваши деньги вместо железа заказчика.

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

Прошу учесть всё сказанное при дальнейшем участии.


-netch-

Re: [freebsd] /dev/ada*p* или /dev/diskid/DISK-${id}p*?

[Valentin Nechayev]

hi,

 Tue, Oct 25, 2016 at 00:14:47, citrin wrote about "Re: [freebsd] /dev/ada*p* 
или /dev/diskid/DISK-${id}p*?": 

> On 10/23/16 12:34, Valentin Nechayev wrote:
> > а от чего зависит, при буте будут видны имена первого или второго типа?
> > При переходе на 10.3 вдруг активировались diskid'ы, пришлось менять fstab.
> > Сегодня на новом ядре вдруг вернулись ada* варианты, опять менять fstab.
> >
> > И, главное, оба одновременно - почему-то не сделали...
> 
> Как уже было сказано - до монтированая (или включения диска в gmirror и 
> т. п.) должны быть видны оба варианта одновременно.

Как уже было рассказано, именно этого и не было. Был виден только один
вариант.

Вместе с безумными артефактами типа /dev/ada0s1ce меня это приводит к
однозначному выводу - что что-то там во всём этом механизме нарушено
(и не мной, я так не умею извращать;))

> Если в fstab все ФС были прописаны как /dev/adaN* то должно работать в 
> таком виде и в 10.3 и в других версиях.
> 
> Смонтировать часть разделов диска через diskid? а другую часть разделов 
> этого же диска через /dev/adaN* возможно не получится.

Это „возможно“ очень „радует“.

> Чтобы было понятно что происходит рекомендую добавить в loader.conf
> kern.geom.label.debug=1

Ну на следующие подёрги так и сделаю.


-netch-

Re: [freebsd] /dev/ada*p* или /dev/diskid/DISK-${id}p*?

[Valentin Nechayev]

 Mon, Oct 24, 2016 at 16:16:48, eugen wrote about "Re: [freebsd] /dev/ada*p* 
или /dev/diskid/DISK-${id}p*?": 

> >>> У меня нет над ними ничего вообще. Это просто два диска.
> >> А причем тогда fstab?
> > При том, что присутствует или /dev/ada1p1, или
> > /dev/diskid/DISK-S1E2D7FYp1, но не одновременно.
> > И если в fstab записан один, а GEOM выставила другой - загрузка
> > ломается.
> Погоди-погоди, или над дисками (над GEOM DISK) "нет ничего вообще",
> включая GEOM_PART_*, или есть разделы. Одно из двух.

Разделы не над дисками, а в них. Давай таки более привычными понятиями :)
И я имел в виду то, что ничего сам над ними не строил, никаких
зеркал и т.п.

> Не забываем про GEOM DISK, именно он вынимает серийный номер из диска
> и засовывает его в атрибут GEOM::ident, откуда GEOM LABEL его берет
> для генерации diskid:
> 
> # geom disk status | grep ada[12]
> ada1 N/A  N/A
> ada2 N/A  N/A
> # geom disk list ada2 | grep ident
>ident: WD-WCAWFA251128

Вот не поверишь - мне пофиг, кто его извлекает.
(А не пофиг то, что мы имеем слабопрозрачный механизм с громоздкой
собственной логикой, которая нетривиальна и контринтуитивна (одно
только соотношение понятий provider и consumer, которое прямо
противоречит POLA), и который, как мы видим, начал жить собственной
жизнью. При этом всём он не обеспечивает тривиальную функциональность,
которая по состоянию на сейчас должна быть базовой и безусловно
доступной - я имею в виду _одновременное_ представление объектов как
по иерархии подключения, так и по уникальным идентификаторам.
Но это, конечно, уже из области сакрального плача.)

> >> Если "просто два диска" без разметки, понимаемой
> >> GEOM_PART_*, то никакой GEOM и не занимает диски и не мешает созданию 
> >> diskid,
> >> тогда это штатное поведение системы. Если после этого нечто вроде ZFS
> >> откроет diskid, то ada* пропадут. Так и задумано.
> > 
> > В данном случае я вообще привёл id _свопа_. Никакой ZFS тут не
> > участвует.
> 
> Неважно, своп тоже открывается ядром при выполнении swapon, та же хрень.

Если механизм "открыли по diskid - пропало по иерархии подключения"
работает, как ты описал, то он сработал не на этом уровне, а на уровне
всего диска. При этом появились /dev/ada1p${X} и пропали
/dev/diskid/DISK-${ID}p${X} _все одновременно_. Или, наоборот, с
точностью до обмена местами. На идентичном конфиге, идентичной кроме
patchlevel версии системы, и идентичных опциях загрузки.

Вот теперь, если ты понимаешь этот механизм изнутри, попробуй
предположить, где же оно такое происходит.

> > Но такое же происходит и с двумя соседними UFS разделами,
> > причём со всеми одновременно - у ada1 или появляются p1, p2..., 
> > или у serialʼа диска появляются подзаписи p1, p2... в diskid.
> 
> Появляется всё, просто diskid пропадает в момент монтирования.
> Или пропадает ada* при открытии diskid. Или ada* не появляется,
> потому что кто-то собрал ядро вообще без GEOM_PART_*

Ещё раз: состав опций GEOM не менялся между вариантами. Кроме того, он
в точности совпадает с GENERIC. "Кто-то" в состоянии проконтролировать
эти детали и начинает уже открытым текстом удивляться, почему второй
"кто-то" этому не верит.

> > А, значит, по сравнению с тем, что ты говоришь - кто-то таки мешает
> > созданию diskids, причём для всего диска.
> 
> Я же показал, что diskid не видно просто потому, что соответствующие
> объекты заняты геомами PART_*

Гипотеза не проходит. Картина с конкретным присутствием только одного из
вариантов видна в полном составе уже на момент загрузки в single user
до подключения любых объектов со второго диска. Корень находится на
ada0, своп не активирован, ZFS не активирован, клиентов (в нормальном
смысле) ни на что на ada1 ещё нет. По-твоему, при этом должны были
быть видны оба набора объектов в /dev/, так?

> >> Упомянутый loader tunnable запрещает создание diskid полностью.
> >> Скорее всего, тебе надо его выставить в ноль и расслабиться.
> > 
> > Я, наоборот, предпочёл бы видеть, как будто он всегда в 1, а лучше в 2
> > (чтобы присутствовали оба варианта). :)
> 
> Оба одновременно при открытых провайдерах на фре не бывает afaik.

При открытых, гм, "провайдерах". Вот я и говорю - похоже, что или
"провайдер" GPT хватает диск раньше, создавая /dev/ada1p${X}, или
label делает это раньше, создавая свои id.
Ты же описываешь в своём примере параллельность работы label к
остальным. Это при том, что у меня

kern.features.geom_label: 1
kern.geom.label.disk_ident.enable: 1
kern.geom.label.gptid.enable: 1
kern.geom.label.gpt.enable: 1

А вот что интересно, кстати. Если посмотреть сейчас чуть по другому
пути:

$ ls -l /dev/gptid
total 0
crw-r-  1 root  operator  0x71 Oct 23 19:04 
2ab4dce7-497b-11e3-aa6e-902b34773338

этот uuid виден у ada1p3. Который занят внутри ZFS. Это не к тому, что
он виновник такого переключения - ZFS загружается уже из rc-скриптов,
то есть позже появления эффекта. Почему подключение к ZFS не убирает
его из видимости?

Я отмонтировал ada1p4, картина изменилась:

# ls -l /dev/gptid

Re: [freebsd] /dev/ada*p* или /dev/diskid/DISK-${id}p*?

[Valentin Nechayev]

 Sun, Oct 23, 2016 at 23:59:29, eugen wrote about "Re: [freebsd] /dev/ada*p* 
или /dev/diskid/DISK-${id}p*?": 

> >> Что значит "активировались" и зачем менять fstab?
> >
> > В системе два диска, первый под DOS разбиением, второй под GPT.
> > На первом были /dev/ada0s{1,2,3...}
> > На втором до перехода были /dev/ada1p{1,2,3...}
> > а после вдруг появились /dev/diskid/DISK-p{1,2,3...}, а
> > /dev/ada1p{1,2,3...} пропали.
> 
> Это ты что-то накосячил с конфигом ядра. В норме такого не бывает.

1. На GENERIC тоже видны только одни из.
2. Что такое "норма" по-твоему? Прошу показать вывод ls -l
/dev/diskid/ и ls -ld /dev/ad* с машины, где, по-твоему, "норма".
3. Мой конфиг отличается от GENERIC очень малым - в основном, урезано
огромное количество левых устройств. Самая большая диверсия там -
IPFIREWALL_DEFAULT_TO_ACCEPT. Секция GEOMʼов не трогалась _совсем_.
Сборка тоже стандартными способами. Поэтому твои наезды сомнительны.


-netch-

Re: [freebsd] /dev/ada*p* или /dev/diskid/DISK-${id}p*?

[Valentin Nechayev]

hi,

 Sun, Oct 23, 2016 at 23:42:51, eugen wrote about "Re: [freebsd] /dev/ada*p* 
или /dev/diskid/DISK-${id}p*?": 

> > а от чего зависит, при буте будут видны имена первого или второго типа?
> 
> Возможно, от kern.geom.label.disk_ident.enable

Сейчас равен 1. /dev/diskid отсутствует.

> Но не вместо ada*, а в дополнение к.

В том и дело, что получается вместо. Есть в /dev или одни, или другие.

> > При переходе на 10.3 вдруг активировались diskid'ы, пришлось менять fstab.
> 
> При переходе с которой версии?

С 10.2.

> Что значит "активировались" и зачем менять fstab?

В системе два диска, первый под DOS разбиением, второй под GPT.
На первом были /dev/ada0s{1,2,3...}
На втором до перехода были /dev/ada1p{1,2,3...}
а после вдруг появились /dev/diskid/DISK-p{1,2,3...}, а
/dev/ada1p{1,2,3...} пропали.

> Сохранился ли лог загрузки (в kernel.log или console.log, all.log),
> в котором нет ada*?

Увы, всё проэкспайрилось.


-netch-

[freebsd] i3-Haswell+10.3+RDRAND: грабли и паника

[Valentin Nechayev]

hi,

перешёл на новое железо (i3-4170 + AsRock B85M Pro4), фряха 10.3.
При загрузке - получил panic быстро пролетающий (ни одной подробности
схватить не успевал).
Нашёл старое ядро от 10.2, загрузился до single. Собранный там же
GENERIC начал точно так же дёргаться. Покурив гугл, собрал
GENERIC+DDB, увидел панику сразу после "random: unlocking device".
Пересобрал с random, но без rdrand_rng - взлетело нормально. Ooook...
попытался загрузиться снова с GENERIC+DDB, чтобы сфоткать панику - не
хочет паниковать...

Дёргать машину ещё раз не хочу, но такое впечатление, что в 10.2 или
ранних 10.3 криво собирали использование rdrand, но вылезло оно только
там, где он появился. (Это ядро от 10.3 было собрано, похоже, ещё в
процессе перехода от 10.2, потом не clean'илось на новые патчи.)
При том, что в 10.2 такая же rdrang_rng, и без проблем.
Гугление ничего внятного про такое не рассказывает (есть рассказ про
10ку "мы напрямую не отдадим RDRAND в /dev/random, мы его всё равно
прогоним через Yarrow", но это совсем не то.)

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

[freebsd] /dev/ada*p* или /dev/diskid/DISK-${id}p*?

[Valentin Nechayev]

hi,

а от чего зависит, при буте будут видны имена первого или второго типа?
При переходе на 10.3 вдруг активировались diskid'ы, пришлось менять fstab.
Сегодня на новом ядре вдруг вернулись ada* варианты, опять менять fstab.

И, главное, оба одновременно - почему-то не сделали...

Такое впечатление, что на момент компиляции вписывается фаза Луны.
Хорошо, что не при буте, но всё равно непонятно...

[freebsd] раскладка свопа по процессам

[Valentin Nechayev]

hi,

есть ли какой-то более-менее готовый способ узнать по процессам,
сколько места в свопе занял каждый из них?

(Выполнять пересчёты по vm maps как-то слишком путано и ненадёжно.
Swapped out в ps это не то - это когда процесс целиком ушёл с концами
в своп, а частичные случаи не будут покрыты. Счётчики тоже не
интересны.)

Re: [freebsd] g_dev_taste: make_dev_p() failed

[Valentin Nechayev]

 Tue, Mar 01, 2016 at 13:30:35, eugen wrote about "Re: [freebsd] g_dev_taste: 
make_dev_p() failed": 

> >> g_dev_taste: make_dev_p() failed (gp->name=vol/i320SSD80Gdisk2rootfs, 
> >> error=17)
> Такие же сообщения об ошибках получаются, если сделать kldload geom_vol_ffs,
> если в ядре уже есть GEOM_LABEL (или загружен geom_label.ko),
> который реализует в том числе и функции старого geom_vol_ffs.
> Нет ли в /boot/loader.conf подгрузки чего попало модулями?

У меня есть такие сообщения, но в loader.conf грузятся только
сетевухи.
Куча разных GEOM в конфиге ядра (наверно, их пытаются ещё раз
динамически подгрузить?)


-netch-

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

hi,

 Fri, Oct 16, 2015 at 20:58:47, eugen wrote about "Re: [freebsd] sendmail + 
roundcube": 

> Зависит от определения стандартной конфигурации.
> С дефолтным конфигом и под атакой - да, есть проблемы,

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

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

Нет.


-netch-

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

 Fri, Oct 16, 2015 at 21:30:33, eugen wrote about "Re: [freebsd] sendmail + 
roundcube": 

> >>> Но реально даже плюсанутые localparts используют только нердомамонты.
> 
> Просто потому что тупо не знают о возможностях MTA, схемах адресации
> и вообще читать документацию немодно.
> 
> Откуда им знать, что в sendmail, для того чтобы, скажем, прикрутить
> IM-рассылку к уведомлениям из JIRA в дополнение к почтовым уведомлениям,
> есть готовая схема адресации вида username+79876543...@domain.org?

"Готовая схема", говорите?

> При которой полное уведомление доставляется по адресу usern...@domain.org,
> а заголовок письма уходит по SMS или через какой-нибудь Instant messaging,
> и что для этого достаточно прописать три строчки в .mc, указав путь к команде
> отправки SMS или IM и шаблон для её аргументов и затем рулить просто записями
> в virtusertable, выбирая, которые домены/субдомены/отдельные ящики 
> обрабатывать
> по такой схеме.

Вы что-то не то курили, коллега.

Во-первых, там в принципе нет никакого автомата типа "полное письмо -
в основной ящик, заголовок - на SMS". Есть форвард, в котором лучшее,
что можно сделать - это сделать отдельный ~/.forward+P2 для адреса
вида user+P2, и передать это в procmail.
Не делается даже укладки этого суффикса в окружение, в отличие,
например, от exim.
То есть "схема" требует полного заката солнца вручную в виде форварда
на свой код.
(Напоминаю, что расщепление адресатов возможно только при алиасе или
форварде. Лукап по virtusertable на это неспособен.)

Во-вторых, в самом интересном варианте - локального форварда - схема
работает относительно недавно, когда в ForwardPath сделали добавку в
виде поиска с +$h. В те времена, когда это было максимально нужно,
этой добавки не было, и надо было руками (.mc, etc.) менять ForwardPath
на вариант с ним.

Если скрыть основную часть реализации под водой, да, можно сказать про
"готовую схему". Слегка так утрировав.

> А ведь всё это документировано в Sendmail Installation and Operation Guide,
> что идёт в дистрибутиве.

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


-netch-

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

 Thu, Oct 15, 2015 at 23:31:21, oleg wrote about "Re: [freebsd] sendmail + 
roundcube": 

> > После освоения и многолетней работы с Exim, возвращаться к sendmail нет
> > никакого желания,   кроме  самых простых случаев. Ибо с Exim все, чуть
> > более, чем простые вещи, делаются намного удобней и гибче, прямо из
> > коробки.
> 
>  Надеюсь Exim из коробки может переписать envelope from на основании значений 
> переменных окружения. Будете хостить веб сервисы для 2+ виртуальных доменов - 
> появится задача.

Пафос я оценил. return_path в транспорте пробовал?

> > Например,
> > мой ответ автору вопроса вернулся в виде отлупа из-за юзания им сервиса
> > senderbase.org и отлупа  почты   по  этому  одному  критерию.  Хотя мой
> > релей по всем нормальным критериям - чистый. Так же само идёт  отлуп при
> > попытке написания на postmaster. Думаю - Вы меня поняли...
> 
>  Рекомендую задуматься о причинах отлупа - там приведена вся необходимая 
> информация для администратора почты. Если эта информация недостаточна для 
> понимания проблемы - причина не в этой информации.
>  И еще -  раз уж Вы решили вынести это вынести на публичное обсуждение без 
> моего согласия - дальнейшая дискуссия на эту тему будет негативно  
> свидетельствовать о Вас.

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


-netch-

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

hi,

 Fri, Oct 16, 2015 at 13:50:34, eugen wrote about "Re: [freebsd] sendmail + 
roundcube": 

> >> Неправда. Так может говорить только тот, кто не читал документацию
> >> на используемый софт, но с exim или postfix ситуация такая же:
> >> неудобно тому, кто доку не читает,
> > 
> > Евгений, я надеюсь, мой авторитет по sendmail (на основании K+1 года
> > его использования в продакшене и десятков патчей на разные темы) ты
> > опровергать не будешь?
> 
> Почему нет? Отсылка к авторитету - плохой аргумент.

Это аргумент к тому, что я и читал документацию (включая то, что в ней
сказано сквозь слова;)), и что на практике набил множество шишек с
ним. И этого достаточно для опровержения твоего "так может говорить
только тот, кто не читал документацию". Я её читал, я использовал его
на практике, и я говорю, что sendmail сложен и неудобен.

> "накидать опций по руководству и вызвать make" полностью покрывает
> как задачу из топика, так и абсолютное большинство остальных почтовых задач,
> о highload речь не идёт, дешевые VPS не используют под highload.

Последний аргумент некорректен как минимум по двум причинам:
1. Мы не знаем уровень нагрузки на реальный хост от соседей. Она на
типичном дешёвом хостинге может быть непредсказуемой и временами очень
высокой.
2. Проявление лавинного эффекта самозаклина очереди зависит не от
нагрузки как таковой, а от её отношения к доступным ресурсам.
VPS может обладать крайне низкими ресурсами, особенно "дешёвый" VPS,
вполне может оказаться, что тарифному плану соответствует что-то
уровня P150 в среднем и P2/300 в относительно свободные часы,
а то и ещё что-то послабее (но этого достаточно, чтобы отображать
страничку типа "я, моя собака и мой прайс", генерируемую модной CMS на
PHP). В этом случае достаточно пары сотен писем, чтобы вызвать такой
заклин; а его самоподдерживаемость лишает простого пользователя, не
знакомого с этими хитростями, возможности решить это собственными
силами без потери данных.
Качественная реализация может быть тормозной, но она не имеет права
быть неуправляемой и допускать лавинные нарастания нагрузки по
внутренним причинам.
 
"Абсолютное большинство остальных почтовых задач" сейчас скорее
решаются методами, которые в принципе не предусматривают собственного
почтового домена и MTA, который его держит.

> Кому из администраторов почтовых систем на VPS требуется автоматизированное
> тестирование кода MTA? Или даже шире, кому вообще из администраторов почтовых
> систем требуется автоматизированное тестирование кода MTA?
> Это задача для совсем другого уровния контор.

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

> Даже знать от существовании REFAL или о его названии не требуется
> для решения типовых задач вроде топика.

С кем ты сейчас разговаривал? Я не говорил, что надо про него знать.
Ты начинаешь избивать воображаемого противника.

> Это всё о highload, который совершенно отдельная тема.

С каких это пор уровень потока в 10K писем в сутки стал highload?
(это примерно то, на чём нам начали проявляться подобные эффекты)


-netch-

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

 Fri, Oct 16, 2015 at 02:35:11, eugen wrote about "Re: [freebsd] sendmail + 
roundcube": 

> >> Можно подумать, sendmail негибок в конфигурировании или много жрет :-)
> > sendmail очень неудобен и сложен в настройке, особенно если требуется 
> > гибкость, 
> Неправда. Так может говорить только тот, кто не читал документацию
> на используемый софт, но с exim или postfix ситуация такая же:
> неудобно тому, кто доку не читает,

Евгений, я надеюсь, мой авторитет по sendmail (на основании K+1 года
его использования в продакшене и десятков патчей на разные темы) ты
опровергать не будешь? Так вот - я категорически подтверждаю слова
cirtin@: sendmail неудобен и сложен - по крайней мере для всего, что
выходит за рамки простой стратегии "накидать опций по ману в
${hostname}.mc и вызвать make", и эта сложность далеко выходит за
пределы того, что определяется "естественными" факторами сложности
тематики. По пунктам:

1. Основным средством конфигурации является "язык переписывания" на
основе идей REFAL. Это само по себе не было бы настолько тяжёлой
проблемой, если бы этот язык не пытались впихнуть вообще всюду,
включая места, где такое не нужно или неудобно.
В частности, тот же язык используется после уже давно состоявшейся
канонизации форм адресов для проверки релеинга. Я понимаю, что авторам
было лениво вводить ещё сущностей, и они тупо отдали тему на откуп
сообществу - мол, напишите нам реализацию, а мы её включим.

2. Но даже для работы с адресами этот код, за редкими исключениями,
не нужен. Да, есть всякие чрезмерно грамматичные адреса RFC822 (луч
пламенного привета IETF), но практически формата localpart@domain
хватает для 99.% случаев. На переходники с uucp/etc. можно
поставить и специальную обработку. При старте Exim, Philip Hazel
намеренно отрёкся от этого всего, и был прав - "в интернете" такое не
нужно.

Ещё хороший альтернативный подход показывает zmailer (кто-то ещё
помнит такое? Один киевский провайдер применял его лет 15 аж до своего
поглощения).

3. Код чудовищно архаичен и не подвергался редизайну верхнего уровня
и/или рефакторингу как минимум последние 30 лет. Для софта это просто
безумный срок.
Кто будет возражать - прошу вначале прочитать и понять логику таких
замечательных функций, как getrequests(), sendall(), dropenvelope(),
описать её словами. Продолжить содержимым файла queue.c, разобрать
тёмные моменты логики.
При изучении конкурентов не потребуется делать аналогичный выворот
мозга.

4. Код в текущем состоянии фатально непригоден для автоматизированного
тестирования. Я понимаю, что многие апологеты и классические авторы
open source, воспитанные в лучшем случае на идеях середины 60-х годов
и, может, немного слышавшие про ценность структурного
программирования, никогда про него не слышали или не понимают
ценности, и что это требует усилий больше, чем "just for fun"; но
почему-то:) у конкурентов это обеспечено лучше.
Присутствующие тесты покрывают только часть вспомогательных библиотек
и то в лучшем случае 1/10 от нужного.
Для сравнения, postfix написан предельно модульно (хоть и некоторые
идеи Венемы требуют бутылки водки для вкуривания в них) и при этом всё
равно в разы легче sendmail. Exim в основе цельно написанный, но он
всё равно проще в подходах.

5. Настройка по умолчанию несопровождаема кроме установки вида
"получать daily run output в локальный ящик". Начать с дефолта
LogLevel=9, который не пишет завершения заданий (и от этого нельзя
вести анализ доставки по логу). Далее, логика управления нагрузкой по
RefuseLA и QueueLA придумана для каких-то других систем, но не
современных юниксов (возможно, она для старого SunOS?) В наших
условиях (в первую очередь FreeBSD) она выливалась в самозаклин под
большой очередью, когда собственно чтение очереди уже даёт нагрузку
заметно выше уровня QueueLA. Там, где большие потоки, приходилось
ставить два демона - принимающий без ограничения по форкам, но с
QueueLA=1, и разгребающий с QueueLA=дофига, но жёстким ограничением по
количеству потомков и ненулевым MaxQueueAge - и только в таком виде
удавалось получить устойчивую конфигурацию. Об этом я писал где только
можно и жаловался авторам, но ответа не было - в лучшем случае "вы же
придумали, как это правильно делать, вот и радуйтесь себе в тряпочку".

Это только малая часть того, что стоит ругать - но не хочу сейчас
тратить много времени.

Причины этого всего мне видятся в следующем факторе: sendmail, по
сути, продукт коммерческий, и был таким изначально, а то, что мы
получаем в доступном виде это урезанная версия "для ширнармасс". Любая
непонятка, с точки зрения авторов, должна вылиться в приход к ним в
гости с пачкой денег на тему "сделайте мне хорошо", и тогда они
вытащат все свои наработки от правильного стартового сетапа до всех
форм секретных патчей типа "100500 параметров статистики в mysql".
В связи с этим вспоминается следующее эссе на тему целевых ниш софта и
зависящих от этого решений по дизайну:

http://web.archive.org/web/20120403172742/http://vydrov.com/index.php/archives/38

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

hi,

 Fri, Oct 16, 2015 at 14:34:29, eugen wrote about "Re: [freebsd] sendmail + 
roundcube": 

> > Это аргумент к тому, что я и читал документацию (включая то, что в ней
> > сказано сквозь слова;)), и что на практике набил множество шишек с
> > ним. И этого достаточно для опровержения твоего "так может говорить
> > только тот, кто не читал документацию". Я её читал, я использовал его
> > на практике, и я говорю, что sendmail сложен и неудобен.
> 
> Сложен и неудобен для каких задач? Для большинства задач он не сложен
> и не неудобен.

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

> Лавинный эффект следствие использования дефолтов, да.
> Решается чтением документации и использованием соответствующих
> стандартных настроек, код читать не требуется.

Нет. Решается 1) попаданием в халепу (как правило, неожиданно и
невовремя), 2) гуглением проблемы и 3) исправлением по уже готовым
рецептам от того, кто таки читал сырцы (как я). Просто так, чтобы
читая документацию, найти и осознать проблему, требуется особый крайне
редкий стиль мышления, владельцы которого обычно становятся QA
seniors, а не админами.

> Ok, аргументы касательно REFAL вычеркиваем.

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

> > С каких это пор уровень потока в 10K писем в сутки стал highload?
> > (это примерно то, на чём нам начали проявляться подобные эффекты)
> 
> На 10K в сутки указанные эффекты могут проявляться на Pentium-120,
> если в конфигурации sendmail даже confHOST_STATUS_DIRECTORY не включена.
> А если включена и вообще sendmail работает не с тупыми дефолтами,
> а с опциями, настроенными под задачу - на Pentium-120 он справляется, 
> проверено.

Ну да, после того, как разнести демоны приёма и раздачи из очереди -
он может работать практически независимо от производительности машины
(до тех пор, пока не начинаются эффекты вроде таймаутов TCP коннекта).
Но до этого он способен убить практически любую конфигурацию (ну
ладно, Xeon + дофига RAM + SSD + etc. выживут, скорее всего, в любом
реальном случае, или заткнутся на чём-то другом).

Это как с пресловутым 12309 - автор реформ, которые его изначально
породили, работал на машине с 2GB RAM, когда средняя машина вокруг
имела 16-64MB, и на все жалобы отвечал "It works for me".


-netch-

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

hi,

 Fri, Oct 16, 2015 at 13:13:43, slw wrote about "Re: [freebsd] sendmail + 
roundcube": 

> Раз пошла такая пьянка -- режь последний огурец.
[...]

> да, в sendmail REFAL. но в остальных нет ничего. т.е. можно только
> выбрать набор каких-то фиксированых проверок и их порядок. если надо
> что-то нестандартное -- патчи сырцы!

В postfix фиксированный набор. В exim значительно гибче набор и штатно
говорят "вам недостаточно => perl в зубы и вперёд". Через него
действительно можно сделать что угодно.

Перед уходом из LN я сделал тестовую установку на exim, которая
работала через перловый хук с таблицами, рассчитанными на sendmail.
Скорость установки была ровно такая же до погрешности измерения, как и
у прямой реализации на sendmail, несмотря на то, что выгибание под
формат чужих таблиц привело к куче тяжёлого перлового кода.
Я не успел сделать нормальный переход к более подходящему виду, но
тесты показывали, что было бы 2-3-кратное ускорение при той же
результирующей функциональности. Рядом в ukr.net Шарун строил реальный
хайлоад (раз уж Гросбейн любит это слово;)) на мощности порядка сотен
писем в секунду среднего потока и подскоками до десятков тысяч, там он
глубоко оптимизировал затраты, но мог выгнуться под практически любую
задачу. Так что с "патчи сырцы" я тут никак не соглашусь.

> сейчас найти рецепты для sendmail кажется несколько сложнее.

Неудивительно - чуть менее чем все, кто тогда ещё мог писать на этом
чудо-языке, сказали "дапашливы" и перешли к более интеллектуальным
занятиям;))

Ещё сурово помог спам - когда купить какой-нибудь Ironport таки
дешевле, чем самому держать штат дорогих админов на управлении
фильтрами.

> да, я в курсе, что postfix писался для того что бы управлять рассылками на 
> пень-100.
> только те, кому такое (смасштабированное) нужно сейчас -- об этом спрашивать 
> не будут.

Ну вот где-то потому у меня сейчас postfix только на раздаче рассылок,
включая данную :)

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

Это отдельный флейм :)

> > Кто будет возражать - прошу вначале прочитать и понять логику таких
> > замечательных функций, как getrequests(), sendall(), dropenvelope(),
> > описать её словами. Продолжить содержимым файла queue.c, разобрать
> > тёмные моменты логики.
> 
> я разбирался, ничего, жив остался.

Ты такой же мамонт, как и я :) рекомендовать такое широкому кругу я не
могу. Жалко птичек.

> > 5. Настройка по умолчанию несопровождаема кроме установки вида
> > "получать daily run output в локальный ящик". Начать с дефолта
> > LogLevel=9, который не пишет завершения заданий (и от этого нельзя
> > вести анализ доставки по логу).
> 
> Шо?
> 
> Oct 16 13:50:35 inter sm-mta[96000]: t9G9oP4x095819: to=leader-...@yandex.ru, 
> delay=00:00:04, xdelay=00:00:01, mailer=esmtp, pri=203421, 
> relay=mx.yandex.ru. [213.180.204.89], dsn=2.0.0, stat=Sent (Ok: queued on 
> mxfront3j.mail.yandex.net as 1444989035-eeXLwLnCXA-oYK8vqd7)
> 
> лог -- по дефолту.

Я про сообщения вида

Oct 16 13:30:32 segfault sm-mta[53431]: tAGAUVgE053430: done; delay=00:00:01, 
ntries=1

они появляются только с 11-го уровня, хотя для понимания происходящего
они важнее раскрытия алиасов (10-й уровень).

> В общем, моя кочка зрения:
> 
> postfix -- нафиг
> в простых случая и exim и sendmail справятся
> если думать лень и хочется готовых рецептов и менять *точно* ничего никогда 
> не будет (как и усложнять) -- наверное exim проще
> если светит в перспективе усложнение (вообще-то оно почти всегда светит) -- 
> лучше потратить время на sendmail.

Лучше таки exim :) или вообще что-то за пределами этой тройки.

> REFAL конечно требует несколько выворачивать мозг, но это, вообще-то полезно.

По нынешним временам лучше бы lua или elisp привинтили.
Хотя я когда-то perl map к нему строил (патч тривиальный, можно
актуализировать).


-netch-

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

 Fri, Oct 16, 2015 at 14:53:09, adsh wrote about "Re: [freebsd] sendmail + 
roundcube": 

> Разница есть. Валентин выше аккуратно всё расписал. Но я понимаю, почему
> многие уже из немолодого поколения за sendmail держатся. Для того, чтобы с
> ним разобраться и использовать в сложных конфигурациях в своё время нужно
> было потратить множество сил и времени. И этим людям становится немного
> обидно, что всё это сейчас делается проще и гибче. По человечески это всё
> можно понять.

Где-то так. В тяжёлом случае это превращается в тот самый
"профессионализм" по Выдрову.

> Главное, чтобы продолжая сидеть на sendmail они не делали
> всякого рода детских ошибок в логике работе своих почтовых систем.
> 
> Как раз здесь и уместна цитата:
> 
> > ...Научить настороженно относиться к опыту бывалых людей, потому
> > что жизнь меняется необычайно быстро...
> 
> ...и появляются новые MTA ;-).

Важнее тут не то, что появляются новые MTA - они как раз, пока следуют
той же концепции "мы держим свои домены и общаемся по SMTP", все MTA
друг на друга похожи в основных концепциях. А вот если выйти за это
прокрустово ложе - начинается реальный мир, в котором хаоса больше,
чем порядка, потому что
1) Выдают вместо домена только один ящик - и начинаются
герценовски-тяжёлые раздумья о том, "что делать", когда надо один ящик
распихать на большую организацию - на входе, и отправлять те же daily
run outputs в мир, имея формально один обратный адрес на всё - на
выходе;
2) IMAP как хранилище с шареным доступом задавливает собой концепцию
собственно почты, и появляются те, кто за много лет ни разу не принял
и не отправил ни одного письма, но у них типа "почта";
3) Появляются общалки через новые транспорты типа ICQ и XMPP, и доля
общения через email сокращается с ~90% до жалких единиц процентов;
4) Засилье спама вынуждает всех мигрировать на что-то вроде Google
Apps, потому что иначе с фильтрацией не справляются;
5) Все уходят в социалки, и теперь надо о работе на сервере
предупреждать в ВК, потому что почты уже у сотрудников нет...

для меня лично email как что-то существенное, на работу с чем и на
развитие чего следует тратить собственные душевные силы, кончилось
где-то между этапами 3 и 4.

Может, именно это не даёт застаиваться людям в болоте, но, наоборот,
застаиваются, не развиваясь, сами технологии - и в итоге тот же
sendmail, по выражению Судакова, становится "не говно, а ценный
компост", ходячий музей старых технологий и подходов :)

А ведь для 95% линуксово-фрибздишных тазиков вместо sendmail'ов
достаточно было бы комбинации логин+пароль+сервер для условного gmail,
чтобы отправлять кроновые отчёты на него, не заботясь о всяких
FEATURE(masquerade_envelope).


-netch-

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

 Fri, Oct 16, 2015 at 15:29:48, slw wrote about "Re: [freebsd] sendmail + 
roundcube": 

> > А ведь для 95% линуксово-фрибздишных тазиков вместо sendmail'ов
> > достаточно было бы комбинации логин+пароль+сервер для условного gmail,
> > чтобы отправлять кроновые отчёты на него, не заботясь о всяких
> > FEATURE(masquerade_envelope).
> 
> да пихали бы сразу в какое гноилище, кто их эти отчеты вообще читает?
> настроили фильтрацию в папку и никогда не смотрят.

Я читаю. Сюрприз:)
Хотя бы чтобы знать, когда дырявые пакеты апгрейдить.
А ещё там многие проблемы видны до перехода в фаталити.


-netch-

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

hi,

 Fri, Oct 16, 2015 at 13:48:23, slw wrote about "Re: [freebsd] sendmail + 
roundcube": 

> > В postfix фиксированный набор. В exim значительно гибче набор и штатно
> > говорят "вам недостаточно => perl в зубы и вперёд". Через него
> > действительно можно сделать что угодно.
> а) по дефолту он без перла.

Только что проверил на портах 2-дневной давности - дефолт таки с
перлом.

> > Ну вот где-то потому у меня сейчас postfix только на раздаче рассылок,
> > включая данную :)
> 
> за настройку которой "фе" высказывалось уже наверное десятком
> участников, но это к постфиксу не относится, как и сама рассылка не
> является аргументом.

Если про reply-to, то я не хочу новый цикл:)
Если про свойства самого majordomo, то они, кажется, мешают только
мне.

> > > > Кто будет возражать - прошу вначале прочитать и понять логику таких
> > > > замечательных функций, как getrequests(), sendall(), dropenvelope(),
> > > > описать её словами. Продолжить содержимым файла queue.c, разобрать
> > > > тёмные моменты логики.
> > > 
> > > я разбирался, ничего, жив остался.
> > 
> > Ты такой же мамонт, как и я :) рекомендовать такое широкому кругу я не
> > могу. Жалко птичек.
> 
> c 1995 года и не требовалось.

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

> > Oct 16 13:30:32 segfault sm-mta[53431]: tAGAUVgE053430: done; 
> > delay=00:00:01, ntries=1
> > 
> > они появляются только с 11-го уровня, хотя для понимания происходящего
> > они важнее раскрытия алиасов (10-й уровень).
> 
> зачем? (не испытывал нужды)

Собственно для логгинга конца обработки письма.

> > 
> > Лучше таки exim :) или вообще что-то за пределами этой тройки.
> 
> qmail. ога.

qmail с человеческим лицом зовётся словом postfix.
Мне из qmail только системы алиасов жалко - аналога не дали.
Но реально даже плюсанутые localparts используют только нердомамонты.

> > По нынешним временам лучше бы lua или elisp привинтили.
> > Хотя я когда-то perl map к нему строил (патч тривиальный, можно
> > актуализировать).
> 
> по нынешним временам в тренде хаскель.
> ну или скала.
> а, нода!

Ну, можно и так. V8 с его тщательно вылизанным JIT местами бьёт даже C.
А недостатки JS на таких мелких кусках кода могут не успеть
проявиться.


-netch-

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

hi,

 Fri, Oct 16, 2015 at 17:53:25, eugen wrote about "Re: [freebsd] sendmail + 
roundcube": 

> Не вижу противоречия. В стандартные конфигурации и опции sendmail
> вкладывается огромное количество разных задач и для них он не сложен
> и не неудобен. А для специфических задач и sendmail, и postfix, и exim
> надо настраивать.

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

> > Нет. Решается 1) попаданием в халепу (как правило, неожиданно и
> > невовремя), 2) гуглением проблемы и 3) исправлением по уже готовым
> > рецептам от того, кто таки читал сырцы (как я). Просто так, чтобы
> > читая документацию, найти и осознать проблему, требуется особый крайне
> > редкий стиль мышления, владельцы которого обычно становятся QA
> > seniors, а не админами.
> 
> Это с любым софтом так.

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

> И слово "нет" тут лишнее, так как руководства
> есть и сорцы читать таки не требуется.

Нет.(tm)
Там нет нужного.


-netch-

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

hi,

 Fri, Oct 16, 2015 at 15:47:46, slw wrote about "Re: [freebsd] sendmail + 
roundcube": 

> > Если про reply-to, то я не хочу новый цикл:)
> 
> только ты за него, остальным он мешает.

Ну я как-то ставил. Или тут, или в uanog, не помню.
Пришлось быстро снять эту спиральку, пошли тонны жалоб типа "я не могу
ответить человеку напрямую". Оказалось, что проблемы от вылетевших в
список всяких ДСП сведений и интимных тайн, которых полны даже
разговоры между участниками технических рассылок - эти проблемы ой как
лупят по людям.
Потому что нажать reply и не посмотреть на то, что получилось в h_To -
это встречается чуть более чем всегда. А виноват, естественно, админ
списка.
Нет уж, пусть лучше ты, Шейко и ещё десяток человек будете ворчать на
дублирование писем, но я буду спокойно спать ночью, не ожидая, что ко
мне придут страшные мстятели :)

> и нет, я не считаю что
> а) список -- это личное мыло отправлямое списку адресатов
> б) письмо в список является большой ценностью, не подлежащей изменению

Я тоже не считаю, но вопрос не в этом, а в том, что выше.

> > Если про свойства самого majordomo, то они, кажется, мешают только
> > мне.
> 
> не только. архива-то нет, к примеру.
> а к mm доступный с веба архив идет бесплатным довеском.

У меня давно стоит готовый к применению Mailman.
Проблема в том, что я сдался искать вариант, как без переписки пары
злобных модулей заимпортить в его базу уже существующий архив.
Я-то ему подам на вход что угодно - mailbox, maildir, каждое письмо
отдельным вызовом - пофиг, но там генерация страницы веб-архива
нормально не отделяется.
Это было года 3 назад. С тех пор не пробовал, извините уж.

> > Собственно для логгинга конца обработки письма.
> в отрезанном было же тоже самое, не?

?

> > qmail с человеческим лицом зовётся словом postfix.
> > Мне из qmail только системы алиасов жалко - аналога не дали.
> > Но реально даже плюсанутые localparts используют только нердомамонты.
> qmail вообще неработающее говно -- он по mxам вообще научился ходить?

Ну я бы не на это бил, а на лицензию.
Но если всё равно локально собирать, то он патчился до правильного
состояния.

> > А недостатки JS на таких мелких кусках кода могут не успеть
> > проявиться.
> 
> да ладно, язык-то та еще какашка.
> http://stackoverflow.com/questions/359494/does-it-matter-which-equals-operator-vs-i-use-in-javascript-comparisons

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


-netch-

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

 Fri, Oct 16, 2015 at 15:13:27, slw wrote about "Re: [freebsd] sendmail + 
roundcube": 

> > > ...Научить настороженно относиться к опыту бывалых людей, потому
> > > что жизнь меняется необычайно быстро...
> > 
> > ...и появляются новые MTA ;-).
> 
> школота, считающая, что она познала дао, недоступное динозаврам -- это
> прикольно!
> exim -- это примерно 1998 год
> postfix -- тоже 1998 год.
> очень новые, ога.

sendmail - 1979 (вместе с delivermail)
zmailer - 1988
smail - ? (но не раньше 1990)
qmail - 1995

да, новые. Заметь, после них массового развития темы MTA уже не было.
Даже CGP ровесник этих двух с точностью до пятилетки.
То есть сидеть на первом поколении до сих пор реально.

> новый -- это dma, но еще недавно у него была целая пачка дестких
> болячек.

Без слушания на порту - не в счёт.


-netch-

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

 Sat, Oct 17, 2015 at 01:05:23, eugen wrote about "Re: [freebsd] sendmail + 
roundcube": 

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

Никакой "лёгкой нагрузки" НЕ СУЩЕСТВУЕТ. Это слова, которые
использовать НЕЛЬЗЯ. На любую "лёгкую нагрузку" найдётся недостаток
ресурсов.
Система или устойчива, не позволяя себя завести в тупик, или
неустойчива. Всё остальное - трёп в пользу бедных.

> Я именно на Pentium-120 обслуживал нагруженный релей во время оно
> и многотысячные очереди разгребать приходилось, да. Они возникали
> только при флуде, а пока флуда нет - очередь жила нормальной жизнью
> и всё доставлялось во время даже без тонких настроек.

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


-netch-

** Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

hi,

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

 Thu, Oct 15, 2015 at 23:33:49, slw wrote about "Re: [freebsd] sendmail + 
roundcube": 

> Date: Thu, 15 Oct 2015 23:33:49 +0300
> From: Slawa Olhovchenkov 
> To: freebsd@uafug.org.ua
> Subject: Re: [freebsd] sendmail + roundcube
> 
> On Thu, Oct 15, 2015 at 11:02:45PM +0300, Sergey V. Dyatko wrote:
> 
> > On Fri, 16 Oct 2015 02:35:22 +0700
> > Eugene Grosbein  wrote: 
> > 
> > > On 16.10.2015 02:30, Anton Yuzhaninov wrote:
> > > > On 10/15/15 22:20, Eugene Grosbein wrote:
> > > >> Можно подумать, sendmail негибок в конфигурировании или много жрет :-)
> > > > 
> > > > sendmail очень неудобен и сложен в настройке, особенно если требуется
> > > > гибкость, 
> > > 
> > > Неправда. Так может говорить только тот, кто не читал документацию
> > > на используемый софт, но с exim или postfix ситуация такая же:
> > > неудобно тому, кто доку не читает,
> > > 
> > 
> > Евгений, Ваш корректно настроенный сендмейл (?) послал 3 письма, зачем-то.
> 
> гм. мне кажется неспособность отличить дупликаты, посланные MTA от
> сгенерированных MUA уже достаточно говорит о ценности остальных
> суждений автора в отношении MTA, MUA, их возможностей и их настройке.


-netch-

** Re: [freebsd] ntpdate стартует раньше, чем bind

[Valentin Nechayev]

 Tue, Sep 01, 2015 at 20:29:13, vector-ua wrote about "Re[2]: [freebsd] ntpdate 
стартует раньше, чем bind": 

> пропишите в конфиге 
> ntpdate_enable="YES" ntpdate_hosts="62.149.0.30 31.28.161.71 212.115.229.130 
> 62.149.2.62 62.149.2.2" 

Как модератор рассылки, я ЗАПРЕЩАЮ всем следовать этому совету. Как
минимум часть упомянутых адресов принадлежат ресурсам, которые никогда
не выставлялись как часть публичной системы раздачи времени по NTP.
В тяжёлом варианте на подобные рецепты есть даже статьи уголовного
кодекса, но даже без них, подобное поведение является тяжелейшим
нарушением сетевого этикета.
Здесь было подробнее: http://netch80.livejournal.com/21781.html

Vladyslav Kolesnyk и всем прочим, это первое и последнее
предупреждение. Следующий такой же совет приведёт к бессрочному бану
по всем подчинённым мне IT ресурсам, включая рассылки uafug.
А на следующий раз рекомендую включать голову и не давать инициативы
неуправляемым рукам.

Ответ в рассылку на это письмо запрещён и приведёт к аналогичным
ограничениям доступа.


-netch-

Re: [freebsd] Ошибка при сборке мира

[Valentin Nechayev]

 Wed, Sep 02, 2015 at 00:13:26, eugen wrote about "Re: [freebsd] Ошибка при 
сборке мира": 

> > find /usr/obj/ -mindepth 1 -delete
> > chflags -R 0 /usr/obj/
> > find /usr/obj/ -mindepth 1 -delete
> >
> > Первый проход сотрёт 99.999% безфлаговых, но пожалуется пару десятков
> > раз на файлы с флагом. Очистка флагов и добивка разберётся только с
> > оставшимися.
> >
> > (Слэш в конце /usr/obj/ принципиален, если этот obj - симлинк, что
> > нередко.)
> 
> А почему не сделать проще?
> rm -rf /usr/obj/*
> chflags -R 0 /usr/obj
> rm -rf /usr/obj/*

Это ничем не "проще", столько же команд, такие же по сути (для случая
типичного /usr/obj без посторонних вмешательств).


-netch-

Re: [freebsd] ntpdate стартует раньше, чем bind

[Valentin Nechayev]

 Mon, Aug 31, 2015 at 02:31:46, adsh wrote about "[freebsd] Re: [freebsd] 
ntpdate стартует раньше, чем bind": 

> Давайте  вернёмся  к тому, с чего начали. У автора темы не
> резолвились сервера точного  времени  из-за  того, что резолвер
> стартовал позже программы установки точного времени.

Да.

> Ему  было  предложено штатное рекомендуемое решение - использовать
> ntpd в режиме корректировки  времени  в любом диапазоне. Поскольку
> ntpd устанавливает время не мгновенно,  а  делает  несколько
> попыток, это решает проблему.

Уже нет. "Решает проблему" оно только в сферической сети в вакууме.
Начнём с того, что ntpd не умеет повторять запрос резолвинга. Точнее,
умеет для peer'ов всех видов, если есть на это опция сборки, не
включенная во FreeBSD. Это значит, что если резолвинг откажет из-за
торможения следующего старта или из-за того, что придёт немедленный
отказ (вполне возможно с некоторыми резолверами), то ntpd вообще не
получит никаких IP. Ещё хуже с именами в restrict, там повторов
вообще не настроишь, и асинхронный резолвинг явно выключен (понятно
почему, но ждущему старта от этого не легче).

(Это уж я не вспоминаю в прямой укор, что у всех DNS записей есть TTL
и вообще-то резолвинг надо повторять через некоторое время. Случаи,
когда IP резолвился из *.pool.ntp.org и "залипал" в ntpd годами,
описаны.)

> Потом уже началось притягивание за уши,
[...]
> Если Вы отбросите всю эту мнительность, то увидите,  что  текущее
> рекомендуемое  разработчиками  решение было дано в самом первом
> ответе.
[...]

Я вижу, что Вы чрезмерно подвержены влиянию официальных авторитетов.
"Рекомендумое разработчиками" для Вас - безусловная истина, а всё
прочее - "притягивание за уши". В то время как практически изучившие
проблему знают, что команда профессора Миллза сильна только в
математике, а как программисты они слабы и на ровном месте пропускают
очевидное (как я слышал, там бо́льшая часть программирования делается
студентами на курсовые).

>  Автор  пока  не  возражал  и не приводил дополнительных условий
> задачи.

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

> Потом  начались  утверждение  оппонентов  о  том, что очерёдность
> запуска ntpd в сравнении с ntpdate имеет какое-то существенное
> значение, хотя очевидно, что это нет так, ибо он синхронизирует
> время не сразу, а через несколько минут.

Мне очевидно, что очерёдность запуска продолжает иметь значение,
потому что:

1. Уже упомянутые выши проблемы с резолвингом. Вы самонадеянно
предположили, что в "синхронизирует время" включается и надёжный
резолвинг сторон. Это не так.

2. Вы принципиально игнорируете проблему сервисов, которым важно
точное внешнее время с самого начала, а не когда-то заметно потом.
Таких сервисов полно, начиная с СУБД.
(Впрочем, в этом игнорировании вы объединяетесь с разработчиками
FreeBSD. Те не делают виртуальное свойство стартового скрипта "время
синхронизировано". Но для того, чтобы это сделать, нужно построить
что-то, не к обеду будь сказано, systemd-образное, что при написании в
стиле автора оного просто убьёт систему. Сделать это когда-нибудь -
нужно, но так, чтобы было диагностируемо и управляемо легко и в любой
момент.)

> Разработчик  считал,  что  программа  ntpdate  было  нужна  лишь для
> того, чтобы привести  начальное  время  в  диапазоны  обслуживаемые
> ntpd.

Повторюсь - "разработчик считал" оказалось резко противоположно тому,
что хочет комьюнити, у которого для большинства установок есть
достаточно надёжные средства синхронизироваться до уровня, когда не
нужно делать time step (что важнее, чем попасть в какие-то
определённые неизвестно почему и как "диапазоны обслуживаемые ntpd").
Пусть это будет включать в себя настроенный левой пяткой на другой
машине ntpd, с точностью до секунды-двух, но оно есть, и достаточно
для старта.

В то же время альтернатива в виде sntp с его "кто первый, тот и в
тапках, даже если у него стратум равен ULONG_MAX" оказалась уже за
пределами разумного.

> Вот, собственно, и весь расклад.

И ещё раз: если хотите обсуждать по сути, отучайтесь циклиться на
авторитетах и давить ими в дискуссии. Не знаю, из каких корней растёт
у Вас такая манера, но успеха тут она не получит.


-netch-

Re: [freebsd] ntpdate стартует раньше, чем bind

[Valentin Nechayev]

 Mon, Aug 31, 2015 at 01:22:32, adsh wrote about "[freebsd] Re: [freebsd] 
ntpdate стартует раньше, чем bind": 

> При  чём  здесь вообще рассылка? Вы шлёте мне напрямую письмо через
> свой релей.  Ваше  нежелание соблюдать элементарные правила хорошего
> тона не имеет никакого отношения к сервису рассылки вообще.

Прошу уйти с этим из рассылки в какие-то средства личной коммунизации.


-netch-

Re: [freebsd] ntpdate стартует раньше, чем bind

[Valentin Nechayev]

 Sun, Aug 30, 2015 at 23:18:03, adsh wrote about [freebsd] Re: [freebsd] 
ntpdate стартует раньше, чем bind: 

 Так  рекомендовалось  раньше. Даже больше для того, чтобы мог
 работать ntpd, ибо он  отказывался  подкручивать время, если оно
 отличалось больше чем на некоторую небольшую  величину.  Сейчас
 явно  написано,  что  эта  программа  устарела, её функциональность
 включена  в  ntpd  и  она будет скоро выпилена из системы.

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

Сидение авторов ntp.org в башне из слоновой кости уже привело к
появлению пачки альтернативных реализаций.

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

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


-netch-

Re: [freebsd] Ошибка при сборке мира

[Valentin Nechayev]

 Fri, Aug 21, 2015 at 00:13:34, Lena wrote about Re: [freebsd] Ошибка при 
сборке мира: 

  cd /usr/src
  make clean
  rm -r /usr/obj
 
 У меня в старой шпаргалке
 
 cd /usr/obj
 chflags -R noschg *
 rn -rf *

На этом chflags можно сдохнуть в ожидании. Лучше всего так:

find /usr/obj/ -mindepth 1 -delete
chflags -R 0 /usr/obj/
find /usr/obj/ -mindepth 1 -delete

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

(Слэш в конце /usr/obj/ принципиален, если этот obj - симлинк, что
нередко.)


-netch-

[freebsd] Re: ntpdate стартует раньше, чем bind

[Valentin Nechayev]

 Sun, Aug 30, 2015 at 19:46:57, i wrote about [freebsd] Re: [freebsd] Re: 
[freebsd] ntpdate стартует раньше, чем bind: 

 А rc скрипты править не надо: там уже должно быть всё правильно.
 Нужно просто посмотреть в существующий скрипт и разобраться почему оно не 
 работает так, как оно задумано. как должно.
 Подозреваю что у вопрошающего вместо портового startup скрипта для named 
 лежит что-то своё.

Увы. Вот на сервере данной рассылки:

$ rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | egrep 'named|ntpdate'
/usr/local/etc/rc.d/named
/etc/rc.d/ntpdate

но:

$ rcorder /etc/rc.d/* /usr/local/etc/rc.d/* /site/etc/rc.d/* | egrep 
'named|ntpdate'
/etc/rc.d/ntpdate
/usr/local/etc/rc.d/named

bind99 из портов, скрипт не патчился.

Очевидно, упорядочения между этими двумя пунктами нет, поэтому
топологическая сортировка ставит их в порядке, зависящем от погоды на
Марсе и группы крови девушки релиз-инженера.

Чего я слегка не понимаю - почему не ввели виртуальную характеристику
resolver, чтобы скрипт, который из них включён (unbound, named или
любой другой резолвер) включался бы в упорядочение по ней. Но это уже
общая проблема стартовой системы - rcorder не имеет понятия, какой
скрипт включается своими настройками, а какой - нет, и прогоняет их
всех. Если бы systemd писался по-человечески, его следовало бы тут
проанализировать на пригодность.


-netch-

Re: [freebsd] ntpdate стартует раньше, чем bind

[Valentin Nechayev]

 Mon, Aug 31, 2015 at 03:42:07, adsh wrote about [freebsd] Re: [freebsd] 
ntpdate стартует раньше, чем bind: 

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

 Немного мыслей по поводу практичности. ntpdate ждёт от сервера DNS
 или NTP ответ в  теч.  4-5  секунд (проверил лично), потом
 отваливается. ОС до момента запуска ntpdate грузится очень быстро -
 до начала всего тяжёлого. Теперь представим себе ситуацию  загрузки
 всего оборудования некой организации после подачи пропавшего
 питания.  Управляемые  свичи / модемы / пограничные роутеры, всякие
 IPoE / PPPoE тоже  не сразу грузятся. Ну Вы поняли, к чему я клоню.
 Так сказать - оборотная и неожиданная сторона хотелки.

Tools, not policy. Не навязывайте людям насильственную точную
синхронизацию там, где им это не нужно, а важнее быстрый подъём.


-netch-