vop

Ну вот, нам его будет сильно не хватать? Ну раз нету, значит можно поглумиться над продуктом немного? Я какое-то время не наблюдал за продуктом, посему задам пару актуальных вопросов: 1. Арифметику перевели уже на целчисленное исчисление, или все так же флоатами мутим? 2. Сделали накопительную систему расчета денег за предоставленные услуги, или так и продолжается "снятие" маленькими кусочками? Вопрос про добровольное убиваение старгейзером своих файлов пропускаем. Раз уж добавили еще одно звено нестабильности - sql Ну и классический вопрос - не пора ли исправить изначальную логическую ловушку: т.е. разнести разные задачи в разные программные структуры - I meant учет клиентов и денег отдельно, считание байтов и дергание фаервола - отдельно?

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

Уууу... Какой топик поднялся. А так - есть, как минимум, 5 разных способов принимать деньги через WebMoney. При этом, есть один соверенно автоматический вариант, который не требует персонального сертификата. Хотя, я не вижу большой проблемы его получить.

То, что ты называешь решением, обычно называется "платежным агрегатором". По сути, это набор программных средств, которые позволяют организовать прием платежей разными способами. Обычно, агрегаторы являются либо частью основного ПО, либо поставляются в виде независимого ПО, либо пишутся самостоятельно. Из отдельных агрегаторов мне в голову приходит только продукт Чекркашина (это если не считать мой, но я его не раздаю). Реально, их, видимо, больше. К чему я это все, а, ну да. Будешь писать свой - делай сразу его в виде независимого агрегатора с четким API. Это позводит тебе в будушем, если будешь переходить на другой биллинг или добавишь новых услуг, использовать то же ПО.

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

Мне это видится немного по другому. Руководство двух сетей - форта и фрегата (в лице интракома) что-то не порешали там, где им надо было порешать. В результате власти сделали совершенно стандартный наезд под названием "маски шоу". Ну бывает. Так вот кое-кто из форта решил под шумок попинать конкурента, свалив на него все. Наверно, надеялись, что мало кто знает, что интраком уже фрегатовская сеть. А фрегат взял и написал это на своем сайте. Вот и все. Поэтому и пахнет это фигово. Извините, но вредить своему сосбтвенному бизнесу "для отвода глаз" - по крайней мере тупо. Да и рассказы, что уходить некуда, сказка для маленьких детей. Зайдите в офис лайнкома, и поинтересуйтесь, сколько людей к ним приходят из интракома.

Интраком уже давно куплен Фрегатом, т.е. по факту, они и являются Фрегатом. Не знаю, что значит "конкуренция по фрегатовски", но этот фортовский топик выглядит очень уж с "душком".

Интраком - сеть Фрегата Так-что вопрос остается открытым - кто наехал на интраком, и кто наехал на форт.

А кто, тогда, заказал Intrakom? Ребята попали под аналогичную раздачу. Причем, Inrakom принадлежит фрегату. http://fregat.dp.ua/about/partners Что-то хило как-то выглядит эта версия про Фрегат.

Много букв - все не читал, но что бросилось в глаза: Делать в одном цикле = делать вообще без цикла. Надо проверять код завершения каждой команды удаления, а не только последней.

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

Ура... Я, как клиент такой сети, ставлю icmp-tunnel

if [ -x /var/stargazer/users/$login/Onconnect ]

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

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

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

Надо резать входящий от юзеров трафик.

Вообще, в приличном обществе так bak-файл не создают. BAK-файл - это _предыдущий_ файл без каких-либо изменений, меняется только имя (что гарантирует его целостность), и создаваться он может (если это не файльшивый bak) только командочкой rename("stat", "stat.bak"); Далее, bak-файл создается только в тех случаях, когда запись новых данных в файл подразумевает возможность ошибки. Например, это редактор текста, в котором файл редактируется человеком, который может ошибиться - в этом случае необходим возврат к предыдущей версии файла. Вот в этом случае и создается BAK-файл. К тому же, в таких случаях, ситуация отсутсвия основного файла мкжду двумя переименованиями не критично (а в старгейзере наоборот, критично). Если файл пишется программно автоматически, то никакого возврата потребоваться не может. Поэтому в этом месте мало того, что он фиктивный (создается искуственно, а не является предыдущим файлом), так он еще и не нужен. В результате работа старгейзера неоправданно утежеляется и усложняется. А деструктор должен вызываться автоматически при уходе из функции, где определен класс (может я не прав - я не программист ) Так-что рецепт простой. Фиктивный BAK убрать нафик. Процедуру записи модернизировать.

Приводил я много раз свой вариант гарантированной и надежной записи данных, в результате чего Борис стал спорить со стандартами POSIX Еще раз привести? Мне не жалко. Ибо процедура очень примитивна и проста. Привожу вариант надежного сохранения данных. И так, если мы хотим обновить данные в каком-либо файле, делаем, как раз-два-три: 1) Создаем временный файл, с раширением, например, stat.tmp%d, куда запихиваем, например, (int)getpid() в качестве уникального номера в системе. 2) Записываем все данные в этот файл. Закрываем файл (!!!) - все, файл целый и невредимый - и только тут его может спасти журнал в случае внезапного ребута!!! 3) Для обновления основного файла делаем rename("stat.tmp123", "stat") - POSIX гарантирует, что в любой момент времени обязан существовать либо старый, либо новый файл. Т.е. отсутствовать он не может ни при каких условиях, кроме случаев физического повреждения носителя. Т.е. файл есть всегда - целый и не нулевой. ВСЕ!!! Теперь при выпадении старгейзера, либо при его килянии НИКОГДА данные из файла stat не потеряются. При внезапном ребуте файл никогда не обнулится. Для написания процедуры гарантированного сохранения данных в старгейзере надо делать больше изменений. Так-что не надо про "опусы" и "пустые слова". Я уже задолбался каждый раз рассказывать...

Журнал ведется для того, что бы сохранить структуру файловой системы, и все. Не будет он спасать файл, открытый на запись (т.е. файл нулевой длины, он же файл, который не содержит информации). Не надо плодить очередные мифы про журнал. Я очень благодарен Борису за оказанную мне честь прислать ему патч. Но я не собираюсь специально ставить старгейзер, править код, отлаживать и проверять, и отсылать ему патч, ибо я не являюсь пользователем старгейзера. Скачать исхолники и заглянуть в файл file_store.cpp мне не сложно - 5-10 минут в виде отдыха не жалко. Но исправлять явную и элементарную ошибку мне некогда (да и желания нет никакого). Патчить "от балды" без проверки и отладки - не в моих правилах. В конце концов, это Борин продукт имеет дырищу в сохранении данных. Я посоветовал элементарный и общеиспользуемый алгоритм по сохранению этих данных. Пока Борис предпочитает спорить... Ну пусть спорит (а в этом время его продукт теряет данные!). Я не собираюсь писать "свое" мнение об общей идее старгейзера, об неудачно выбранной структуре данных (ну пытается Борис много лет натянуть клиента на коллектор трафика - ну может это многим нравится), о выборе математической модели биллинга (в результате чего деньги считаются примерно, приблизительно, с погрешностью до 15% в месяц - да кому оно надо правильно считать-то?). Но вот о элементарной ошибке работы с файлами я буду писать до тех пор, пока эта ошибка будет болтаться в продукте, и пока автору продукта до лампочки эта ошибка. Может кто-то очередной бедолага подумает лишний раз, стоит ли ставить продукт, который элементарно теряет данные, в следствие чего он принципиально не пригоден для эксплуатации.

Так, как сделаны бак-файлы сейчас (по сути являясь фиктивными бак-файлами), не спасет ситуацию. Да и по сути, бак-файлы, создаваемые рядом, обычно нужны совсем для других целей (для возможности отката к предыдущей версии данных - back up, а не для их спасения). Еще раз повторю - причина проблемы в том, что Борис открывает файл с данными на запись. Это делать ни в коем случае нельзя. Ни при каких условиях. В этом причина всех проблем. Но пока Борис предпочитает "незамечать" этого.

Никогда журналирующая ФС не будет спасать открытый на запись файл. Никогда в жизни. Журнал ведется не для этого. Снова и снова вопрос в криво написанной процедуре записи данных в файл.

Биллинги, в которые зашиты платформо-зависимые компоненты (например, коллектор трафика, контроль доступа), потребуют заметной переделки.

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

У меня вопрос - почему в миллионе программ используется найденое (и придуманое) десяткм лет назад решение, а у СТГ оно, вдруг, не найдено? Почему вместо того, что бы воспользоваться широко известным приемом при записи в файл, делаются какие-то подпорки и затычки? Я не уверен, что при таком подходе, переход на базы спасет ситуацию. У Бориса вообще странная реакция. Я вообще, как бы человек не заинтересованный, но мне уже самому настолько надоело читать постоянные жалобы в форуме годами, что можно подумать, что это основная цель форума. Я не поленился, скачал старгейзер, потратил времени, полазил по сырцам, нашел причину проблемы и просто подсказал простое решение этой КРИТИЧЕСКОЙ проблемы. Вполне конструктивный подход. И что? Просто тема закрываем? Разве я похож на врага? Если надо, я могу открыть отдельную тему и четко, по пунктам описать проблему, ее причины и способ решения. И не надо меня называть флудером, плиз.