vop

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

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

А кто, тогда, заказал 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-файл. К тому же, в таких

Приводил я много раз свой вариант гарантированной и надежной записи данных, в результате чего Борис стал спорить со стандартами POSIX Еще раз привести? Мне не жалко. Ибо процедура очень примитивна и проста. Привожу вариант надежного сохранения данных. И так, если мы хотим обновить данные в каком-либо файле, делаем, как раз-два-три: 1) Создаем временный файл, с раширением, например, stat.tmp%d, куда запихиваем, например, (int)getpid() в качестве уникального номера в системе. 2) Записываем все данные в этот файл. Закрываем файл (!!!) - все, файл целый и невредимый - и только тут его

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

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

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

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

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

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

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

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

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

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

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

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