madf

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

А это тот-же самый sgconf, только без разбора XML. А, я его попутал с xmlrpc видимо. Правильный вопрос: конфигурирование через xmlrpc тоже подвержено этой проблеме? Именно этой - нет. Но у него есть другая проблема: он иногда возвращает пустой ответ. Точнее проблема не в самом плагине а в используемой сторонней библиотеке libxmlrpc-c.

А это тот-же самый sgconf, только без разбора XML.

Сто лет уже теме. Пока работает один конфигуратор — второй отдыхает. Выход — увеличивать количество плагинов конфигуратора (при этом разнося их по разным портам). Или же списывать деньги последовательно.

E7, EA... Действительно, есть такое. Надо будет как-то проверить, у меня есть подозрение что для CompactFlash оно отрабатывает не всегда...

Я не специалист по ATA/SCSI/SATA, но на сколько я знаю, в этих протоколах нет подобной команды. На девайс приходит только read/write. fflush который из POSIX всего лишь сбрасывает содержимое буферов юзерспейса. Из ядра данные на устройство вполне могут и не поступить. Для этого надо вызывать fsync/fdatasync или "бомбить по площадям" с помощью sync. Эти команды отправят данные на устройство, но все еще не гарантируют их запись. Они еще могут болтаться в кеше самого устройства, для чего используют батарейки в контроллерах и эти сомнительные конденсаторы.

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

Ну да. Еще и с учетом 30/31 и високосных годов.

В логах Stargazer'а что-то интересное есть? Типа "Subscriber fee charge".

И почему я не сомневался?

Если указать FeeChargeType = yes то Stargazer даже не запустится Давайте лучше посмотрим на логи и конкретных абонентов. База у вас в чем?

Какое значение у FeeChargeType? такого параметра, у меня, в stargazer.conf вообще не установленно. Тогда скорее всего у вас ситуация в которой абонка не снимается. Например юзер "заморожен" или у него величина ежедневной абонплаты менее 10^-3.

Когда умирает железный RAID то прочитать что-то с массива можно только при наличии такого-же RAID-контроллера. Так что он хорош когда имеется брендовое решение, и производитель готов заменить комплектующие по первому запросу. Во всех остальных случаях софтовый RAID гибче и надежнее. А по поводу кондера - он конечно спасет в ситуации когда данные остались в кеше устройства. Но есть еще кеш ОС и кеш приложения. Да и файловые системы при всей своей транзакционности (которую часто ограничивают при использовании SSD) все еще нужно корректно размонтировать при отключении. Так что кондер кондером, а UPS важнее. все важно. и упс, и энергонезависимый кэш в рейд-контроллере, и энергонезависимый кэш в дисках (или отсутствие кэша там вообще). Что касается кэшей ОС и приложений. То да, они потеряются. Для каких-то приложений это может быть критично, для каких-то нет. Если речь идет о БД, например. То она данные из кэша на диск может оочень долго не сбрасывать. Но рядом она пишет транзакционный лог. По принципу "дисковая подсистема сказала, что запись прошла успешно, только после этого подтвердили успешность транзакции". И в случае креша все не долетевшие из кэша БД данные будут донакатываться из такого лога. (ну Капитан Очевдность вобщем-то, но). Когда дисковая подсистема сказала что запись прошла - это еще ничего не значит. И лог транзакций живет как и все файлы поверх файловой системы. При наличии правильно настроенного UPS наличие или отсутствие батарейки в железном RAID'е или конденсатора на винте никак не сказывается на надежности. Конденсатор скорее всего добавили чтобы уменьшить количество потерь данных у домашних пользователей. А какие мины вы имеет в виду?

Это шутка что-ли такая? У вас на УПСе батарейки никогда не выходит из строя, никогда не заканчивается и дизель за упс-ом стартует в 101% случаев, никакой Вася походя рубильником не щелкнет, кабелек питания в сервере не дернет? Супер. Я на это все не рассчитываю. Поэтому кроме двух независимых бесперебойных входа по питанию в сервер, внутри сервера стараюсь делать так. чтобы тоже лажи было поменьше Может еще про падающие метеориты вспомним? Когда я говорю "правильно настроенный UPS" я имею в виду правильно настроенный UPS. С мониторингом. Дизель и Вася - они за UPS'ом, так что всегда есть время разобраться или штатно погасить сервер. Выдергивание кабеля питания из сервера стоящего в стойке... Ну разве что при разгильдяйстве. А тут ничто не поможет.

Когда умирает железный RAID то прочитать что-то с массива можно только при наличии такого-же RAID-контроллера. Так что он хорош когда имеется брендовое решение, и производитель готов заменить комплектующие по первому запросу. Во всех остальных случаях софтовый RAID гибче и надежнее. А по поводу кондера - он конечно спасет в ситуации когда данные остались в кеше устройства. Но есть еще кеш ОС и кеш приложения. Да и файловые системы при всей своей транзакционности (которую часто ограничивают при использовании SSD) все еще нужно корректно размонтировать при отключении. Так что кондер кондером, а UPS важнее.

Вообще-то у нас диски всегда были с кэшем и всегда что-то недослито при пропадании питания, бд уж как-нибудь и без ваших догадок справится и останется консистентной, даже такая говняная, как Innodb в mysql. И брать пару дисков по цене целого сервера каждый, чтобы кэш дослился - какая-то полная неадекватность. Там еще столько всего может случиться, что кэши не досольються, вы даже не представляете. мне нравится ваш оптимизм. но на своих продакшенах я его не разделяю и другим не советую. а так каждый на своих серверах может делать что угодно, даже бекапы не держать ... Вы на боевых серверах надеетесь на конденсаторы в винтах? У меня для вас плохие новости! Софтовый RAID плюс правильно настроенный UPS решает все проблемы. Конденсаторы не решают ничего.

Какое значение у FeeChargeType?

Профиль -> Черная магия -> Детальная статистика А еще обратил внимание на такие записи в rules: ALL 217.12.80.0 DIR3 ALL 217.12.81.0 DIR3 ALL 217.12.82.0 DIR3 ALL 217.12.83.0 DIR3 ALL 217.12.84.0 DIR3 ALL 217.12.85.0 DIR3 ALL 217.12.86.0 DIR3 Что-то это подозрительно наличие таких записей в rules, но точно вам скажет о подозрительности madf... Вот кстати да. По дефолту он, вроде, /32 поставит.

Так вроде ж не в степях

Значит вы намудрили в rules или забыл после этого отдать stargazer'у команду перечитать этот файл. Может покажете что вы там написали? Да, пожалуйста,в прикрепленных.Это стояло на прошлой час назад на прошлой система,как я уже написал выше,сейчас снес и поставил всё заного,префиксами ещё не занялся. По файлу вроде все ок. Можно включить детальную статистику и посомтреть какой трафик прилетает и как классифицируется.

Ярлык находиться в панели управления в разделе "Справочники" и выглядит он вот так: Неужели вы думаете,что я не в состоянии найти ярлык "Классы трафика"!!??Охренеть можно,выводы битон у вас.Я говорил про отдельный модуль,подключаемый из /etc/stargazer/conf-... Такого не существует. Значит вы намудрили в rules или забыл после этого отдать stargazer'у команду перечитать этот файл. Может покажете что вы там написали?

А Stargazer перезапустили? Вот так: # killall stargazer # stargazer Зачем учите плохому? Чтоб перечитать rules не надо ничего перезапускать. Достаточно сделать killall -1 stargazer

В файле rules как раз и описываются сети принадлежащие заданному направлению. Что значит "направление нужному пользователю присвоил" я не понял. Что значит "чтобы тариф действовал только на нужное направление"? Сейчас можно только открывать всем все или использовать авторизатор и открывать только те которые пользователь выберет.

Здесь вроде бы не обсуждается,какой из раидов лучше) Просто совет на будущее.

Программный RAID и правильно настроенный UPS в 100 раз лучше и в 100 раз надежнее любого аппаратного решения.