vop
-
Всього повідомлень
1 339 -
Приєднався
-
Останній візит
-
Дней в лидерах
35
Тип контенту
Профили
Форум
Календарь
Сообщения додав vop
-
-
Предлагаю решение для автоматизации приёма платежей. Мой способ не претендует на идеал
но для сети до 100-150 человек подойдёт То, что ты называешь решением, обычно называется "платежным агрегатором". По сути, это набор программных средств, которые позволяют организовать прием платежей разными способами. Обычно, агрегаторы являются либо частью основного ПО, либо поставляются в виде независимого ПО, либо пишутся самостоятельно. Из отдельных агрегаторов мне в голову приходит только продукт Чекркашина (это если не считать мой, но я его не раздаю). Реально, их, видимо, больше.
К чему я это все, а, ну да. Будешь писать свой - делай сразу его в виде независимого агрегатора с четким API. Это позводит тебе в будушем, если будешь переходить на другой биллинг или добавишь новых услуг, использовать то же ПО.
-
С этим-то, как раз, вопросов и нет. Вещи весьма известные и ожидаемые от указанных персонажей. Тем более, что в данном случае фрегат получается не злодеем, а жертвой
Но вот кто наехал на интраком - пока не понятно.
-
...
Интраком - это показательные выступления чтоб отвести внимание от себя. Всеравно на тополе больше уходить некуда, так что народ тихонько посидел без инета пару дней, ничего не случилось.
...
Мне это видится немного по другому. Руководство двух сетей - форта и фрегата (в лице интракома) что-то не порешали там, где им надо было порешать. В результате власти сделали совершенно стандартный наезд под названием "маски шоу". Ну бывает. Так вот кое-кто из форта решил под шумок попинать конкурента, свалив на него все. Наверно, надеялись, что мало кто знает, что интраком уже фрегатовская сеть. А фрегат взял и написал это на своем сайте. Вот и все. Поэтому и пахнет это фигово.
Извините, но вредить своему сосбтвенному бизнесу "для отвода глаз" - по крайней мере тупо. Да и рассказы, что уходить некуда, сказка для маленьких детей. Зайдите в офис лайнкома, и поинтересуйтесь, сколько людей к ним приходят из интракома.
-
Может купить эти сети на корню хотят? И валят их руководство... Главное что бы до стрельбы и разборок с братвой не дошло.
Интраком уже давно куплен Фрегатом, т.е. по факту, они и являются Фрегатом.
Не знаю, что значит "конкуренция по фрегатовски", но этот фортовский топик выглядит очень уж с "душком".
-
возможно Фрегат воспользовался случаем.
Но нефакт.
Интраком - сеть Фрегата
Так-что вопрос остается открытым - кто наехал на интраком, и кто наехал на форт. -
Заказали через прокуратуру.
А кто, тогда, заказал Intrakom? Ребята попали под аналогичную раздачу. Причем, Inrakom принадлежит фрегату.
http://fregat.dp.ua/about/partners
Что-то хило как-то выглядит эта версия про Фрегат.
-
Много букв - все не читал, но что бросилось в глаза:
Примечание к этому скрипту. Все удаления сделаны в одном цикле, тк. если делать в разных циклах, то происходит зацикливание и скрипт просто висит в памяти, не дорабатывая до конца. Методом научного тыка, а также проб и ошибок я выяснил структуру скрипта, к.будет работать корректно.Делать в одном цикле = делать вообще без цикла. Надо проверять код завершения каждой команды удаления, а не только последней.
-
Сам файл шифруется по паролю пользователя.
При запуске StgKassa пользователь вводит свой пароль по этому же паролю происходит
дешифрация файла авторизация и в расшифрованной структуре проверяется введенный пароль.
Если он совпадает открывается основное окно для работы.
Вот в этом месте не совсем понятна логика работы. Если пароль не правильный, то данные не смогут быть дешифрованы, т.е. и вроде проверять нечего... Зачем же тогда проверять пароль еще раз? Я слабо представляю ситуаию, что структура данных будет расскрыта, а пароль не сопадет...
-
iptables -t filter -A FORWARD -p icmp -j ACCEPT
Ура... Я, как клиент такой сети, ставлю icmp-tunnel
-
if [ -f /var/stargazer/users/$login/Onconnect ]
if [ -x /var/stargazer/users/$login/Onconnect ]
-
Идея была написать скрипт, который будет прописан в кронтабе и уведомлять пользователей сообщением через консольный конфигуратор, когда на счету осталось меньше 2-х (например) денег. Аля предупредительная смс мобильных операторов.
Когда-то ообсуждали разделение функционала между компонентами, и пришли к выводу, что все сообщения-предупреждения (т.е. сторожевые фенкции) - это исключительно внутренний функционал авторизатора. Клиент сам должен иметь возможность устаналвливать разные критерии, лимит денег, лимит трафика и т.д. И нефиг для этого грузить сервер.
-
Ну так переходите на mysql_store и баги испарятся...
Почему-то у меня такая уверенность, что если не можем с примитивными файлами работать, что при переходе на sql багов увеличится в разы... А надежнолсть рухнет ниже порога функциональности.
-1
Я не слежу за этой фишкой особо, но проблему с потерей коннекта к базе уже порешали?
-
Ну так переходите на mysql_store и баги испарятся...
Почему-то у меня такая уверенность, что если не можем с примитивными файлами работать, что при переходе на sql багов увеличится в разы... А надежнолсть рухнет ниже порога функциональности.
-
Надо резать входящий от юзеров трафик.
-
Значит файл мы не закрываем. Дык открыть для записи открыли- что-то туда записали, а скинуть буффер на диск не скинули !!! Подправьте меня если я не прав
Вообще, в приличном обществе так bak-файл не создают. BAK-файл - это _предыдущий_ файл без каких-либо изменений, меняется только имя (что гарантирует его целостность), и создаваться он может (если это не файльшивый bak) только командочкой rename("stat", "stat.bak");
Далее, bak-файл создается только в тех случаях, когда запись новых данных в файл подразумевает возможность ошибки. Например, это редактор текста, в котором файл редактируется человеком, который может ошибиться - в этом случае необходим возврат к предыдущей версии файла. Вот в этом случае и создается BAK-файл. К тому же, в таких случаях, ситуация отсутсвия основного файла мкжду двумя переименованиями не критично (а в старгейзере наоборот, критично). Если файл пишется программно автоматически, то никакого возврата потребоваться не может. Поэтому в этом месте мало того, что он фиктивный (создается искуственно, а не является предыдущим файлом), так он еще и не нужен. В результате работа старгейзера неоправданно утежеляется и усложняется.
А деструктор должен вызываться автоматически при уходе из функции, где определен класс (может я не прав - я не программист
)Так-что рецепт простой. Фиктивный BAK убрать нафик. Процедуру записи модернизировать.
-
К сожалению опять пустые слова. Если вы заглядывали в модуль (file_store.cpp) и узрели ошибку, что мешает вам поделиться идей её искоренения с авторами ? Пожалуйста, выскажите более конструктивные предложения по реализации записи файлов, чем в уже который раз высказывание про то что "ошибка где-то есть, но где и в чем искать как-то не с руки да и отлаживать сей продукт мне нету времени". Любая конструктивная критика будет воспринята и воспринимается от других, правда другие люди хоть и критикуют, однако утруждают найти время для того чтобы прислать логи/показать конкретно места кода, где по их мнению возникает ошибка. От вас же, кроме опусов о том что неправильно пишутся файлы, к сожалению конкретных предложений не поступает, а жаль.
Приводил я много раз свой вариант гарантированной и надежной записи данных, в результате чего Борис стал спорить со стандартами POSIX
Еще раз привести? Мне не жалко. Ибо процедура очень примитивна и проста. Привожу вариант надежного сохранения данных. И так, если мы хотим обновить данные в каком-либо файле, делаем, как раз-два-три:
1) Создаем временный файл, с раширением, например, stat.tmp%d, куда запихиваем, например, (int)getpid() в качестве уникального номера в системе.
2) Записываем все данные в этот файл. Закрываем файл (!!!) - все, файл целый и невредимый - и только тут его может спасти журнал в случае внезапного ребута!!!
3) Для обновления основного файла делаем rename("stat.tmp123", "stat") - POSIX гарантирует, что в любой момент времени обязан существовать либо старый, либо новый файл. Т.е. отсутствовать он не может ни при каких условиях, кроме случаев физического повреждения носителя. Т.е. файл есть всегда - целый и не нулевой.
ВСЕ!!!
Теперь при выпадении старгейзера, либо при его килянии НИКОГДА данные из файла stat не потеряются. При внезапном ребуте файл никогда не обнулится.
Для написания процедуры гарантированного сохранения данных в старгейзере надо делать больше изменений.
Так-что не надо про "опусы" и "пустые слова". Я уже задолбался каждый раз рассказывать...
-
Ладно уже, спасал переход на журналируемую ФС и не раз. Особенно на FreeBSD где по дефолту иногда ставилась не журналируемая ФС.
Журнал ведется для того, что бы сохранить структуру файловой системы, и все. Не будет он спасать файл, открытый на запись (т.е. файл нулевой длины, он же файл, который не содержит информации). Не надо плодить очередные мифы про журнал.
Борис предлагал вам прислать патч - не хотите, не шлите, но тогда не надо в каждой теме писать "свое" мнение, ибо я тоже могу сказать что на заборе написано.Я очень благодарен Борису за оказанную мне честь прислать ему патч. Но я не собираюсь специально ставить старгейзер, править код, отлаживать и проверять, и отсылать ему патч, ибо я не являюсь пользователем старгейзера. Скачать исхолники и заглянуть в файл file_store.cpp мне не сложно - 5-10 минут в виде отдыха не жалко. Но исправлять явную и элементарную ошибку мне некогда (да и желания нет никакого). Патчить "от балды" без проверки и отладки - не в моих правилах. В конце концов, это Борин продукт имеет дырищу в сохранении данных. Я посоветовал элементарный и общеиспользуемый алгоритм по сохранению этих данных. Пока Борис предпочитает спорить... Ну пусть спорит (а в этом время его продукт теряет данные!).
Я не собираюсь писать "свое" мнение об общей идее старгейзера, об неудачно выбранной структуре данных (ну пытается Борис много лет натянуть клиента на коллектор трафика - ну может это многим нравится), о выборе математической модели биллинга (в результате чего деньги считаются примерно, приблизительно, с погрешностью до 15% в месяц - да кому оно надо правильно считать-то?).
Но вот о элементарной ошибке работы с файлами я буду писать до тех пор, пока эта ошибка будет болтаться в продукте, и пока автору продукта до лампочки эта ошибка. Может кто-то очередной бедолага подумает лишний раз, стоит ли ставить продукт, который элементарно теряет данные, в следствие чего он принципиально не пригоден для эксплуатации.
-
".bak-файлы, .bak-файлы!"
Они должны быть вне зависимости от того дописал сервер файл или нет. Если stg падает - он не удаляет их за собой.
Так, как сделаны бак-файлы сейчас (по сути являясь фиктивными бак-файлами), не спасет ситуацию. Да и по сути, бак-файлы, создаваемые рядом, обычно нужны совсем для других целей (для возможности отката к предыдущей версии данных - back up, а не для их спасения).
Еще раз повторю - причина проблемы в том, что Борис открывает файл с данными на запись. Это делать ни в коем случае нельзя. Ни при каких условиях. В этом причина всех проблем. Но пока Борис предпочитает "незамечать" этого.
-
Журналируемая ФС, УПС на сервер, перевод хранилища на БД, выкинуть сервер, улететь на луну (рекомендуется, если все прошлые методы не помогли).
Никогда журналирующая ФС не будет спасать открытый на запись файл. Никогда в жизни. Журнал ведется не для этого. Снова и снова вопрос в криво написанной процедуре записи данных в файл.
-
Биллинги, в которые зашиты платформо-зависимые компоненты (например, коллектор трафика, контроль доступа), потребуют заметной переделки.
-
Ок, пришли патч.
На всякий случай - разумеетя, я не буду ставить stg, править код, отлаживать, что бы тебе прислать патч. Причина дыры понятна и известна. Просто зафиксируем, что ты совершенно не хочешь ее исправлять - странная позиция автора продукта.
Поэтому у меня преджложение тем, кто занимается правкой stg - я попробую рассказать, что и как надо переделать, что бы сделать сохранение данных хотя бы надежным. А вы уж делайте патчи и т.п.
-
Может быть в окончательном релизе вообще выбросить файловый стораж - раз решений не найдено и остановится на СУБД. Ведь тема будет всплывать постоянно ))
У меня вопрос - почему в миллионе программ используется найденое (и придуманое) десяткм лет назад решение, а у СТГ оно, вдруг, не найдено? Почему вместо того, что бы воспользоваться широко известным приемом при записи в файл, делаются какие-то подпорки и затычки? Я не уверен, что при таком подходе, переход на базы спасет ситуацию.
У Бориса вообще странная реакция. Я вообще, как бы человек не заинтересованный, но мне уже самому настолько надоело читать постоянные жалобы в форуме годами, что можно подумать, что это основная цель форума. Я не поленился, скачал старгейзер, потратил времени, полазил по сырцам, нашел причину проблемы и просто подсказал простое решение этой КРИТИЧЕСКОЙ проблемы. Вполне конструктивный подход. И что? Просто тема закрываем? Разве я похож на врага?
Если надо, я могу открыть отдельную тему и четко, по пунктам описать проблему, ее причины и способ решения. И не надо меня называть флудером, плиз.
-
Для файлового хранилища давно реализован автобекап.
Уже сколько раз говорилось - исчезновение данных в файлах - это криво написанная работа с файлами. Я более того скажу, что при такой небрежной работе с файлами никакое журналирование не поможет, ибо журнальчику просто восстанавливать нечего. Не надо оправдывать небрежность отсутствием транзакий и журналов. Надо просто выполнить элементарное правило работы с файлами, которое выполняют все программы, включая и vi, и mc, и вообще любая программа, которая изменяет информацию в файле. Ибо не забываем, что и СУБД работают поверх файловой базы (ну, за исключением оракла под соляркой).
Хотя, со скриптом автобакапа можно делать вид, что этой проблемы нет. Но возникает новый вопрос - каких еще проблем нет в продукте из замалчиваемых? А то получается, что выросло поколение людей, которым вдолбили в голову, что хранить данные в файлах нельзя...
P.S. Интересно, эта тема тоже будет закрыта?
-
И всего навсего предлагаю общими усилиями дорабатывать то что есть.
Эту проблему уже не доработать. Тут надо обязательно менять систему учета клиентов на многоуровневую. Что бы работало правило "Один клиент - много услуг". И делать это надо начинать, как можно скорее. Иначе куча проблем будет просто расти. Целый ряд проблем просто не будет возникать, если разделить систему учета клиентов и систему учета услуг.
но для сети до 100-150 человек подойдёт 
Stargazer и электронные кошельки
в Модулі для Stargazer
Опубліковано:
Уууу... Какой топик поднялся.
А так - есть, как минимум, 5 разных способов принимать деньги через WebMoney. При этом, есть один соверенно автоматический вариант, который не требует персонального сертификата. Хотя, я не вижу большой проблемы его получить.