|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Zahar Kiselev 2:5030/382.1 26 Jun 2002 22:39:52
To : Victor Wagner
Subject : Re: Время + почта
--------------------------------------------------------------------------------
Jun 26 21:33 02, Victor Wagner wrote to Zahar Kiselev:
ZK>> Мой приятель, после чтения большого количества
ZK>> документации, утверждал, что если в биосе стоит местное
ZK>> время, то неправильно работают какие-то из функций xntpd.
VW> Верится с трудом. xntpd то какое дело он с ядреным временем
VW> работает а не с биосным.
Хорошо, уточняю: проблема была в том, что xntpd всегда должен "держаться" за
своего коллегу - то есть за того, кого считает эталоном. А если канал не
идеален, то при пропаданиях свзяи его начинает "колбасить":) Чтобы этого не
случалось - нужен хотябы один всегда доступный эталон. Если рядом такого нет, то
проблема может быть решена прописыванием в качестве эталона собственных часов с
указанием большого числа stratum, чтобы это использовалось только когда ничего
больше не доступно. Это сильно помогает переживать падения канала. Так вот в
связи с какими-то ограничениями xntpd ему нельзя было "указать на самого себя"
если в машине часы установлены не по UTC. То есть если мы не прописываем "ссылку
на себя" - то часы ставить по местному времени можно. Воевал с этим мой приятель
долго, ему, как и мне, совершенно не хотелось устанавливать часы по UTC. Однако
на трех машинах пришлось это сделать.
Все вышестказанное относится к системе и софту, собранному на основе
Дебиана 1.2 и ядру 2.0.38. Четвертый год не можем рискнуть сломать вобщем-то
хорошо работающую конструкцию из нескольких машин чтобы заменить систему на
более новую. Вобщем-то основная и пока не решенная проблема - traffic shaper в
ядре 2.4. Даже маскарадинг у меня получилось настроить(на экспериментальной
машине), а вот шейпер ну никак не сделать. Ситуация усложняется тем, что
несколько сеток, трафик на которые должен быть ограничен, имеют маскарадные
адреса и нужно все их повесить на один интерфейс, так как иначе в машине не
хватит слотов под карточки. Собственно - нехватка слотов и является той
причиной, по которой мы задумались об апгрейде системы. В ядре 2.4 можно
назначить одному интерфейсу несколько адресов, причем для этого даже алиасы не
обязательны.
Проблема в том, что тот вариант traffic shaper, который есть в 2.0.38 хотя и
может существовать в 2.4, но он не умеет "прицепляться" к алиасам, он только
весь интерфейс ограничивать может. А то, что сделали в 2.4 новое и что
управляется через команду tc - не имеет достаточно толковых описаний. Во всяком
случае чтение advanced routing howto не помогло за три дня экспериментов
получить работающую нужным образом конфигурация. Или не ограничивает совсем, или
ограничивает, но возникает взаимовлияние между разными сетями - то есть
ограничение в одной частично зависит от ограничения в другой, причем поведение
всей этой конструкции не поддается предсказанию.
Дело в том, что howto - это именно сборник готовых рецептов, и нужного рецепта
там нет.
Если это письмо сейчас читает кто-нибудь, у кого получилось сделать независимое
ограничение трафика на основе анализа ip-адреса, а не имени интерфейса - буду
премного благодарен за совет как мне тоже такое настроить.
VW> Вот с переходом на летнее/зимнее
VW> время - точно проблемы будут, если не GMT.
Только если машина выключается. Hа постоянно работающей машине достаточно после
момента переходя времени выполнить по крону команду записи нового значения в
cmos-часы, так как ядро свое время в процессе работы переводит
_правильно_(вернее - как в локали прописано, а она часто неправильная
встречается, но это понятное дело поправимо).
ZK>> Правда было это два года назад, может что-нибудь и
ZK>> поменялось. Вообще говоря, какое время стоит в биосе
ZK>> какого-нибудь сервера, который последний раз перезагружали
ZK>> несколько месяцев назад - довольно безразлично. А вот если
ZK>> машина включается не особо регулярно и из-за этого нередко
ZK>> "забывает" время (или просто системная плата с такой
ZK>> особенностью) - то каждый раз при переустановке часов
ZK>> высчитывать сколько же там сейчас в Гринвиче - несколько
ZK>> напрягает.
VW> А нафига? При загрузке системы должно взлетать ntpdate и тащить
VW> время с ближайшего ntp-сервера.
Hетрудно догадаться, что редко включаемые машины, а также машины с глюкавыми
системными платами - обычно находятся где-нибудь "далеко" от интернета(дома
например). Согласись - звонить провайдеру только для того, чтобы корректно
загрузить домашнюю машину - все-таки лень.
VW> У меня всю жизнь так было, даже на диалапе. Все равно при старте у
VW> машины есть куча дел в сети - MX смартхоста закешировать к примеру.
По-моему если нет нормального канала, то лучше всего сделать машину максимально
работоспособной в автономном варианте. Потому как не известно - будет ли в
данный момент связь с провайдером или нет.
Zahar(@spbdept.rbc.ru)
--- Msged/LNX 6.1.0
* Origin: undefined location (2:5030/382.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
