|
| +1 |
|
> > Для десктопа не подходит из-за отсутствия systemd
> Чего это? Это некий "системный менеджер". Почитал бегло описание: содержит в одном проекте упрощённые реализации множества стандартных утилит, написанные (и пишущиеся в данный момент) с нуля двумя людьми под влиянием того, как аналогичные задачи решаются в windows и macos. По сути, похоже на бизибокс, только если там есть определённая цель - embedded и среды с ограниченным объёмом ресурсов, то здесь - проект пишется для души, не преследуя никакой конкретной цели. Утилиты реализованы особым образом, и, чтобы они работали, требуются изменения в базовых принципах работы современных юниксов. В результате ребятам пришлось реализовать свой инит, свой способ работы с логами, свой менеджер сеансов, свой способ монтирования разделов (временно с целью поддержки софта, аналоги которого ещё не реализованы в рамках systemd, традиционный fstab генерируется автоматически), даже отдельный демон для работы с /etc/localtime. Подробностей, к сожалению, не знаю, так как прочитал описание лишь бегло, но, судя по всему, многие задачи, типично решаемые в никсах запуском утилиты или установкой переменной окружения, здесь решаются просто отдельным демоном. То есть традиционное никсовое "всё есть файл" тут пытаются заменить на "всё есть демон". Проект является "домашним проектом" двоих вышеупомянутых, поэтому если им требуется какая-то возможность, то они просто берут и реализовывают её, а если что-то становится им ненужным, то могут удалить. Кроме того, поддерживается только работа в Линукс, причём достаточно свежих версий, и требует, чтобы ядро было собрано с некоторыми экзотическими опциями (как минимум, cgroups). РедХэт седьмую центось (и рхел вроде тоже) реализовала на базе этого "системного менеджера". Лидеру технического комитета Дебиана тоже так понравился этот systemd, что он устроил несколько голосований по вопросу внедрения его в дебиан и переделки всего на работу именно с ним вместо традиционных аналогов. Однако после трёх голосований желающих переходить на systemd всё ещё было не слишком много, так что решение мигрировать Дебиан на systemd ему пришлось принимать самостоятельно. Части голосовавших это не понравилось, и они создали ветку Дебиана в классическом исполнении - devuan. |
вторник, 20 ноября 2018 г.
среда, 19 сентября 2018 г.
ntpdate при невозможности синхронизировать время с сервером NTP весьма неинформативно об этом рапортует, что на самом деле не только снижает потенциальный интерес к утилите, но и фактически мешает работать. Утилита при стандартном запуске вида
ntpdate 10.20.30.40
не даст отличить ситуации "нет доступа к сетевому узлу 10.20.30.40" от ситуации "на хосте 10.20.30.40 не запущен NTP сервер" не говоря уже об новой для меня ситуации "NTP сервер запущен, но его stratum/leap - это параметры [не]достоверности времени сервера - слишком велики.
Для более подробного разбора полётов -ожидаемого на самом деле поведения - необходимо запускать nptdate с ключом -d.
Вчера на gentoo настраивал NTP сервер без доступа к внешним источникам. В генте 3 варианта NTP серверов, это
Мне был привычен традиционный ntp от www.ntp.org но решил попробовать openntpd.
Дать шанс. Указал адрес прослушивания, вроде бы что-то поднялось, попробовал синхронизироваться, не получилось - забил. Думаю, надо использовать старых друзей.
И как выяснилось, привычный ntpd тоже не отдаст время с ожидаемой точностью для ntpdate.
Запустил
<client>#ntpdate192.168.0.1
получил ожидаемое
20 Sep 05:54:30 ntpdate[1890]: no server suitable for synchronization found
далее с ключом -d
<client># ntpdate -d 192.168.0.1 ...
20 Sep 05:57:03 ntpdate[5580]: ntpdate 4.2.6p5@1.2349-o Mon Nov 14 18:25:09 UTC 2016 (1)
Looking for host 192.168.0.1 and service ntp
host found : 192.168.0.1
transmit(192.168.0.1)
receive(192.168.0.1)
...
receive(192.168.0.1)
192.168.0.1: Server dropped: strata too high
server 192.168.0.1, port 123
stratum 16, precision -24, leap 11, trust 000
...
20 Sep 05:57:09 ntpdate[5580]: no server suitable for synchronization found
Решил немного покопать, может получится быстро исправить ситуацию - не получилось быстро найти требуемые опции.
в ntpd/ntp_proto.c задал при отправке stratum = 2;
немногое изменилось:
<client># ntpdate -d 192.168.0.1
20 Sep 05:59:26 ntpdate[8858]: ntpdate 4.2.6p5@1.2349-o Mon Nov 14 18:25:09 UTC 2016 (1)
Looking for host 192.168.0.1 and service ntp
host found : 192.168.0.1
transmit(192.168.0.1)leap 11
...
...
192.168.0.1: Server dropped: Leap not in sync
server 192.168.0.1, port 123
stratum 2, precision -24, leap 11, trust 000
решил, что это уже перебор. Надо дать шанс chrony, перед дальнейшей ломкой кода.
<server>#emerge chrony
<server>#cat /etc/chrony/chrony.conf
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
clientloglimit 100000000
local stratum 10
leapsectz right/UTC
allow 192.168.0.100
bindaddress 192.168.0.1
<server>#/etc/init.d/chronyd start
на клиентской тачке
<client># ntpdate -d 192.168.0.1
...
...
server 192.168.0.1, port 123
stratum 10, precision -25, leap 00, trust 000
refid [192.168.0.1], delay 0.02576, dispersion 0.00182
...
20 Sep 06:05:10 ntpdate[16530]: adjust time server 192.168.0.1 offset 0.434906 sec
отлично
ntpdate 10.20.30.40
не даст отличить ситуации "нет доступа к сетевому узлу 10.20.30.40" от ситуации "на хосте 10.20.30.40 не запущен NTP сервер" не говоря уже об новой для меня ситуации "NTP сервер запущен, но его stratum/leap - это параметры [не]достоверности времени сервера - слишком велики.
Для более подробного разбора полётов -ожидаемого на самом деле поведения - необходимо запускать nptdate с ключом -d.
Вчера на gentoo настраивал NTP сервер без доступа к внешним источникам. В генте 3 варианта NTP серверов, это
- net-misc/openntpd
- net-misc/ntp
- net-misc/chrony
Мне был привычен традиционный ntp от www.ntp.org но решил попробовать openntpd.
Дать шанс. Указал адрес прослушивания, вроде бы что-то поднялось, попробовал синхронизироваться, не получилось - забил. Думаю, надо использовать старых друзей.
И как выяснилось, привычный ntpd тоже не отдаст время с ожидаемой точностью для ntpdate.
Запустил
<client>#ntpdate192.168.0.1
получил ожидаемое
20 Sep 05:54:30 ntpdate[1890]: no server suitable for synchronization found
далее с ключом -d
<client># ntpdate -d 192.168.0.1 ...
20 Sep 05:57:03 ntpdate[5580]: ntpdate 4.2.6p5@1.2349-o Mon Nov 14 18:25:09 UTC 2016 (1)
Looking for host 192.168.0.1 and service ntp
host found : 192.168.0.1
transmit(192.168.0.1)
receive(192.168.0.1)
...
receive(192.168.0.1)
192.168.0.1: Server dropped: strata too high
server 192.168.0.1, port 123
stratum 16, precision -24, leap 11, trust 000
...
20 Sep 05:57:09 ntpdate[5580]: no server suitable for synchronization found
Решил немного покопать, может получится быстро исправить ситуацию - не получилось быстро найти требуемые опции.
В сердцах
подправил в сорцах
немногое изменилось:
<client># ntpdate -d 192.168.0.1
20 Sep 05:59:26 ntpdate[8858]: ntpdate 4.2.6p5@1.2349-o Mon Nov 14 18:25:09 UTC 2016 (1)
Looking for host 192.168.0.1 and service ntp
host found : 192.168.0.1
transmit(192.168.0.1)leap 11
...
...
192.168.0.1: Server dropped: Leap not in sync
server 192.168.0.1, port 123
stratum 2, precision -24, leap 11, trust 000
решил, что это уже перебор. Надо дать шанс chrony, перед дальнейшей ломкой кода.
<server>#emerge chrony
<server>#cat /etc/chrony/chrony.conf
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
clientloglimit 100000000
local stratum 10
leapsectz right/UTC
allow 192.168.0.100
bindaddress 192.168.0.1
<server>#/etc/init.d/chronyd start
на клиентской тачке
<client># ntpdate -d 192.168.0.1
...
...
server 192.168.0.1, port 123
stratum 10, precision -25, leap 00, trust 000
refid [192.168.0.1], delay 0.02576, dispersion 0.00182
...
20 Sep 06:05:10 ntpdate[16530]: adjust time server 192.168.0.1 offset 0.434906 sec
отлично
воскресенье, 26 августа 2018 г.
пятница, 8 июня 2018 г.
среда, 16 мая 2018 г.
Openssl и многопоточка.
Всё меняется, растёт, развивается - в OpenSSL более не требуется настраивать набор локов при использовании в многопоточном приложении!
Было забавно.
Заходит глава саппорта, фанат альтернативного решения, развиваемого в той же конторе, и говорит так по отечески, с легкой болью общения с непрофессионалами, окончившими учебные заведения с главным зданием слишком маленькой высоты - "там Серёга с багом в опенссл столкнулся, вы тоже на это напоретесь, идите и посмотрите. Вот идите." Мы всегда рады расти. Ведь у нас невысокие здания в наших университетах. Во всех, кроме одного, где и готовят Специалистов. Не комплексуем, но почему-то терпим это отеческое псевдокомпетентное. Ну может действительно чему-то научили ребят, в отличие от нас, кто знает?
Ну и захожу к соседям, и там мне "Вован, тут такая тема, надо ссл_аццепт локом обрамлять, при использовании в нескольких потоках" и я так сходу - "man threads не помог?" и мне "что-что?" и уже как-то сразу ясно стало, почему мы не столкнулись с этим, а вот альтернатива, так скажем, влетела, при всём своём несомненном опыте. Сколько таких моментов было, и всё мы скромно терпели, и зря. Надо было драться с напыщенными саппортерами. Вообще такие случаи отличный маркер нездорового отношения, должен был аларм завыть у менеджмента, это кристально ясно через десяток лет. Ну что было, то стало.
Всё меняется, растёт, развивается - в OpenSSL более не требуется настраивать набор локов при использовании в многопоточном приложении!
УРА!!!
Натыкался на это, примерно лет 10 назад.Было забавно.
Заходит глава саппорта, фанат альтернативного решения, развиваемого в той же конторе, и говорит так по отечески, с легкой болью общения с непрофессионалами, окончившими учебные заведения с главным зданием слишком маленькой высоты - "там Серёга с багом в опенссл столкнулся, вы тоже на это напоретесь, идите и посмотрите. Вот идите." Мы всегда рады расти. Ведь у нас невысокие здания в наших университетах. Во всех, кроме одного, где и готовят Специалистов. Не комплексуем, но почему-то терпим это отеческое псевдокомпетентное. Ну может действительно чему-то научили ребят, в отличие от нас, кто знает?
Ну и захожу к соседям, и там мне "Вован, тут такая тема, надо ссл_аццепт локом обрамлять, при использовании в нескольких потоках" и я так сходу - "man threads не помог?" и мне "что-что?" и уже как-то сразу ясно стало, почему мы не столкнулись с этим, а вот альтернатива, так скажем, влетела, при всём своём несомненном опыте. Сколько таких моментов было, и всё мы скромно терпели, и зря. Надо было драться с напыщенными саппортерами. Вообще такие случаи отличный маркер нездорового отношения, должен был аларм завыть у менеджмента, это кристально ясно через десяток лет. Ну что было, то стало.
Подписаться на:
Сообщения (Atom)