vop

Уже сколько раз говорилось - исчезновение данных в файлах - это криво написанная работа с файлами. Я более того скажу, что при такой небрежной работе с файлами никакое журналирование не поможет, ибо журнальчику просто восстанавливать нечего. Не надо оправдывать небрежность отсутствием транзакий и журналов. Надо просто выполнить элементарное правило работы с файлами, которое выполняют все программы, включая и vi, и mc, и вообще любая программа, которая изменяет информацию в файле. Ибо не забываем, что и СУБД работают поверх файловой базы (ну, за исключением оракла под соляркой). Хотя, со скриптом автобакапа можно делать вид, что этой проблемы нет. Но возникает новый вопрос - каких еще проблем нет в продукте из замалчиваемых? А то получается, что выросло поколение людей, которым вдолбили в голову, что хранить данные в файлах нельзя... P.S. Интересно, эта тема тоже будет закрыта?

Эту проблему уже не доработать. Тут надо обязательно менять систему учета клиентов на многоуровневую. Что бы работало правило "Один клиент - много услуг". И делать это надо начинать, как можно скорее. Иначе куча проблем будет просто расти. Целый ряд проблем просто не будет возникать, если разделить систему учета клиентов и систему учета услуг.

Как бы не вышло так, что лет через 5 будет то же самое - все те же проблемы с хранением и пропаданием данных, все та же "приблизительная" математика при подсчете точных величин, все те же проблемы с одноуровневостью структуры данных, и еще целой кучей элементарных ошибок... Вот мне надо же будет тогда тоже написать "Говорил же я Борису 5 лет назад..."

Такая фишка может называться "система динамического квотирования".

Такого рода проблемы вылезают и будут вылезать постоянно в силу одноуровневости учета клиентов и услуг. Я об этом говорил Борису 5 лет назад. Система одноуровневая, поэтому и учет идет по принципу - у одного клиента может быть только единственная услуга. А уже вторые IP, емейлов сколько надо и т.д. - просто не влезает.

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

Честно говоря, я не готов продолжать дальше, ибо обсуждаем уже не вариант алгоритма, который позволит данным не пропадать, а начинаем спорить с POSIX... Я пасс... POSIX требует, что бы эта функция была атомарная. Ее реализация под линуксом и фрей является атомарной. The rename function is specified in the stdio.h library header file in C and the cstdio header in C++. It is specified in ANSI C. In POSIX, rename will fail (with EXDEV) if the old and new names are on different mounted file systems. On Linux, if a call to rename succeeds it is [b]guaranteed to have been atomic[/b] from the point of view of the current host. Причем чуть ранее я привел тебе цитату из документа, озаглавленного селдующим образом: The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition Copyright © 2001-2004 The IEEE and The Open Group, All Rights reserved. А как утверждают источники... POSIX (IPA: /ˈpɒsɪks/) or "Portable Operating System Interface"[1] is the collective name of a family of related standards specified by the IEEE to define the application programming interface (API) for software compatible with variants of the Unix operating system. Originally, the name stood for IEEE Std 1003.1-1988, which as the name suggests, was released in 1988. Т.е. я тебе привел цитату из оригинального требования POSIX, а вовсе не свое мнение или предположение. Так-что я немного потерялся, о чем дальше говорить?

С рождения у тебя на каждую величину были отдельные файлики - ip, cash, pswd, на каждый счетчик и т.д. И для каждого счетчика тоже были отдельные файлы. Вот так и получалось, что при инициализации каждого клиента, старгейзер читал по 15 файлов. Вот из моего старого конвертора. loadd - это типа трафик по Днепру Тут не все файлы, а только те, которые нужны были для сбора статистики на верхний уровень. #define BILLI_FILE_IP BILLI_HOME_DIR"/%s/ip" #define BILLI_FILE_LOADI BILLI_HOME_DIR"/%s/loadi" #define BILLI_FILE_LOADD BILLI_HOME_DIR"/%s/loadd" #define BILLI_FILE_LOADE BILLI_HOME_DIR"/%s/loade" #define BILLI_FILE_PLAN BILLI_HOME_DIR"/%s/plan" #define BILLI_FILE_CASH BILLI_HOME_DIR"/%s/currcash" #define BILLI_FILE_PSWD BILLI_HOME_DIR"/%s/pswd"

Вот этого делать нельзя!!! Нельзя переписывать файл по живому. Вообще, нельзя открывать ни один рабочий файл на запись. Хоть кто-нибудь читал, что я там накарябал? Новый файл создается отдельно. На момент выполнения rename уже никто никуда не переписывается и не двигается. Одной операцией запмисывается указатель на новый массив данных.

Возможно, тебе сказать трудно. Я Борису об этом 5 лет назад говорил. Тогда еще не было файлов stat в базе старгейзера. Но опасность исчезновения данных уже были заложены заранее не совсем разумной работой с данными. В общем, на этом и закончим. При чем тут mv - не знаю.

If the rename() function fails for any reason other than [EIO], any file named by new shall be unaffected. Перевожу на русский толковый - что бы ни случилось (кроме физической поломки винта), любой из двух файлов (старый или новый) должен остаться на новом месте, причем, остаться целкой. Так-что нет никакого момента "когда старый удален" и так далее. Это ГАРАНТИЯ функции rename() по стандарту POSIX, который требует атомарной реализации этой функции Она не уменьшает вероятность пропажи файла, а ИСКЛЮЧАЕТ вообще их пропажу. Ой, сомневаюсь, что тебе поможет журналируемая fs. Мало того, что не поставят все любители старгейзера себе журнальную fs, так с ней тоже работать надо уметь правильно :)

Если не ошибаюсь, это было где-то в 2002 году. Я тогда много своих соображений тебе высказывал. В том числе и по переводу авторизатора с tcp протокола на udp, или, например, из критичных на мой взгляд вопросов - переход на целочисленную арифметику и накопительный подсчет данных. В общем, много тогда говорили - возможно что и забылось уже. Давай лучше к данному вопросу, который мучает умы уже много времени. Правила гарантированного сохранения данных при работе с файлами очень простые. Есть несколько разных вариантов. Это конечно правильно ты мыслишь с разными bak-файлами, но не совсем правильно (с моей точки зрения, как минимум). Вот смотри в чем проблема - в определенных случаях возникает ситуация, когда сервер прекращает работу в тот момент, когда файл stat имеет нулевую длинну. Т.е. если кильнуть сервер, нажать резет и т.д. - то возникают такие неприятности, что какой(-ие)-нибудь файлы stat на этот момент имеют длинну 0. Что надо добиться? Надо добиться, что бы файл stat никогда не был нулевой длинны. Никогда, ни секундочку, как говорится, ни единый "машинный такт". Для этого есть очень простые правила, которыми пользуются программеры разного софта. Будь то cron при перезаписи таблицы, будь то rsync или vi, или практически любые другие программы, работающие с данными. Вот они в моем изложении: 1. Никогда, ни при каких условиях, ни в каких случаях не открывать файл с данными на запись. Тем более, не держать их открытыми на запись. На запись можно открывать только некритичные данные - те же логи, например (не путать критичные и важные данные). 2. Для обновления файла с данными используется единственная функция, которая (как говорят в умных книжках) имеет гарантию неисчезающего существования файла - т.е. система обязаны выполнить функцию "за один системный цикл" без прерывания и т.д. (о, как умничаю ) Я говорю о функции rename(); Т.е. исходя из этих двух правил мы имеем очень простой алгоритм изменения данных в файле. 1. Создаем временный файл (текстовые редакторы, обычно, созадют файлы с раширением .bak). Мы можем делать какой-нибудь tmp, с номером pid, например. Основной файл с данными цел. 2. Записываем во временный файл обновленные данные, при этом считаем, сколько записали байт. Получаем копию нашего будушего файла с данными. Основной файла цел. 3. Закрываем файл и проверяем его размер, сравнивая с количеством записанных байт (что бы не наткнуться, например, на диск-квоту, которая не всегда кричит, что место закончилось). Основной файл цел. 4. Если все нормально - и файл есть, и размер нормальный - просто делаем rename из временного в основной. При этом, новый файл заменыет старый, и нет не единого момента, когда файл с данными отсутствует, или обнулен. Прошу прощения, если много слов написал. Но у меня такое впечатление, что я когда-то тут или на наге об этом уже писал, и даже кусок кода для примера приводил. Ну да ладно, мне не жалко. Потому-как потеря данных в программе - это вообще никуда не годится, и это дело надо исправлять, как можно скорее. P.S. И не говорите, что поменяв файловую базу на базу SQL можно избавиться от этой проблемы. С SQL можно так наворотить, что проблема с файлом stat покажется вообще детской

Так кто должен написать? Разве не Борис? Или просто надо обсудить алгоритм и принципы гарантированной записи данных в файл. Я могу предложить один из вариантов, который я рассказывал Борису лет 5 назад. Какая проблема-то?

Либо, наконец, написать нормальную работу с файлами без всех этих подпорок Ну не сложно же ведь!

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

Какого именно клиент-банка?

А какое именно мнение интересует? Ибо "да" и "нет" к мнению сложно отнести. P.S. Держим, а как же?

root в юниксоподобных системах определяется не словесным идентификатором (root), а номером uid`а = 0.

Там можно не только по маскам задавать цейпер, но и маркировать пакеты по разным критериям. Смотри опцию --mark iptables

Пример такого скрипта (именно, пример): https://topola.unity.net/filef/rc/taweb-0.05.29-rc5.tar.gz Надо зарегистрироваться. Регистрация бесплатная и без подтверждения. После этого определяешься с источником, что именно хочешь показывать, определяешься со страничками, которые надо тянуть, возможно, апдейтишь скрипт, и ставишь его на локальный сервер. Юзер логинистся к локальной странице - а скрипт к удаленному серверу. Еще один вариант - с помощью команды wget деклаешь локальное зеркало выбранной страницы.

Поставь проксирующий скрипт на какой-нибудь гисметео.

Очень сильно все навалено в кучу, нет четкой струкутризации. Вот над этим надо бы поработать. P.S. Ну и забано, что заказывать переход на новый тариф можно только один раз в месяц...

Как?

Как не бывает хорошего ресторана без шеф-повара, так и не бывает хорошего провайдера без админа...

Во первых, кроме Кривого Рога есть еще Кременчуг с единой системой оплаты коммунальных услуг. Больше нет ни одного города с единой системой - в остальных городах люди оплачивают квитанции пачками по отдельности без всяких единых предприятий, выстаивая многочасовые очереди в сберкассах. Поэтому Ваш совет не совсем подходит. С другой стороны оплата абонентской платы ничем не отличается от оплаты других затрат (например, трафик, время), поэтому выделять как-то ее нет особого смысла, особенно, если в сети есть эти другие затраты клиентов. Поэтому кратко приведу примерный список возможных вариантов оплаты услуг: "Ручные" способы: 1. Касса в оффисе, сбор налика по квартирам. 2. Банковский перевод. Недостатки очевидны - необходимость следить как за оплатами, так и за работой в ручном режиме. Автоматические способы: 1. Скретч-карты (предоплаченные карты). Все сводится к ассинхронно-независимому выпуску карточек в домашне-кухонных или промышленных условиях. 2. Оплата через электронные валюты (Webmoney, Ukrmoney и т.д.). Покупка ваучеров этих систем у диллеров, в банкоматах, ларьках и т.д. 3. Оплата при помощи банковских (кредитных) карт прямо на сайте через интернет-эквайринг. 4. Оплата через платежные терминалы (разные ОСМП, ibox и так далее). 5. Покупка опять-таки карт пополнения счета через все указанные выше способы (на сайте, в терминале и т.д.). Сюда же можно добавить покупку ваучеров/кодов пополнения через SMS (как срочный вариант для клиента с большой комиссией). В любом случае, накладные расходы могут достигать до 5%, что и стоит заранее закладывать в стоимость услуги. При всех автоматических способах оплаты администрация сети может вообще никак не участвовать в процессе. Т.е. клиент оплачивает услуги (ПО расчетной системы должно понимать нужные методы оплаты). В случае исчерпания баланса, биллинг его может автоматически отключать. Пополнил счет - подключил. P.S. У меня мобилка - контракт с абонентской платой. Однако, ничто не мешает мне пополнять счет не разделяя абонку и оплату времени.