Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 35
У меня вопрос. И собственно что вы всем этим хотели сказать?
Просто поделился опытом того, что можно не просто писать программы, но при этом и реализовывать некую концепцию. Хороша она или не очень — судить Вам, а насколько хорошо она реализована в продукте — пользователям системы.
Ваш текст ниочем. Не указано какие дает приемущества PostgreSQL по сравнению с MySQL, ни собственно концепций заложенных в биллинге ни собственно чем они лучше.
Может, текст и не очень складный, но идею Вы уловили правильно: ядро системы — БД PostgreSQL. Написать аналогичный код с использованием MySQL было бы затруднительно. И полностью открытый код, конечно.
Дело в том, что я в свое время на диплом я проектировал конвергентный биллинг, так же на базе PostgreSQL. Кроме этого делал с товарищем биллинг для SOHO code.google.com/p/cakebilling/
Именно поэтому я и говорю что текст собственно не о чем. Ни о архитектуре ничего не написано, ни к чем привело использование хранимых процедур и триггеров ни зачем использовалось наследование. Из вашей статьи понятно ровно одно: — мы ну эта сделали тут биллинг дла на PostgeSQL, а еще у нас там есть PHP JavaScript и HTML!
Именно поэтому я и говорю что текст собственно не о чем. Ни о архитектуре ничего не написано, ни к чем привело использование хранимых процедур и триггеров ни зачем использовалось наследование. Из вашей статьи понятно ровно одно: — мы ну эта сделали тут биллинг дла на PostgeSQL, а еще у нас там есть PHP JavaScript и HTML!
Не хотелось грузить текст техническими подробностями, что, очевидно, привело бы к его плохой читаемости.
Поскольку ВСЕ данные и ВЕСЬ программный код — это БД PostgreSQL, то и архитектура получилась очень простая и прозрачная: Ядро (БД) + источники данных + WEB-интерфейсы + планировщик задач.
Наследование использовалось для секционирования больших архивных таблиц с данными о трафике и начислениях.
Поскольку ВСЕ данные и ВЕСЬ программный код — это БД PostgreSQL, то и архитектура получилась очень простая и прозрачная: Ядро (БД) + источники данных + WEB-интерфейсы + планировщик задач.
Наследование использовалось для секционирования больших архивных таблиц с данными о трафике и начислениях.
Это ресурс, где изучают технические подробности, именно для этого он и предназначен
Не хотелось грузить текст техническими подробностями, что, очевидно, привело бы к его плохой читаемости.
Удаление технических подробностей и описания почему и зачем так сделано как раз привело к плохой читаемости текста. Для рекламного описания ваш пост слишком перегружен техническими деталями, для технического описания ваш пост не содержит необходимых технических деталей.
Поскольку ВСЕ данные и ВЕСЬ программный код — это БД PostgreSQL, то и архитектура получилась очень простая и прозрачная: Ядро (БД) + источники данных + WEB-интерфейсы + планировщик задач.
Это не архитектура. Архитектура включает в себя как минимум ER-диаграмму и описание выбранных решений. Этого тут нет. У вас «у нас есть это и это хорошо» если уж буквально. А чем хорошо почему хорошо не описано. То что вот использование хранимок и триггеров это удобно я верю. Ну а еще?
Удаление технических подробностей и описания почему и зачем так сделано как раз привело к плохой читаемости текста. Для рекламного описания ваш пост слишком перегружен техническими деталями, для технического описания ваш пост не содержит необходимых технических деталей.
Поскольку ВСЕ данные и ВЕСЬ программный код — это БД PostgreSQL, то и архитектура получилась очень простая и прозрачная: Ядро (БД) + источники данных + WEB-интерфейсы + планировщик задач.
Это не архитектура. Архитектура включает в себя как минимум ER-диаграмму и описание выбранных решений. Этого тут нет. У вас «у нас есть это и это хорошо» если уж буквально. А чем хорошо почему хорошо не описано. То что вот использование хранимок и триггеров это удобно я верю. Ну а еще?
Размещение всей бизнес-логики системы, описанной отношениями между сущностями, ограничениями, проверками, правилами, триггерами и функциями, непосредственно в базе данных на наш взгяд имеет следующие преимущества:
1. надёжность — прекомпиляцию, оптимизацию и исполнение кода выполняет СУБД
2. корректность хранимых данных — проверкой правильности пользовательского ввода и поддержкой целостности данных занимается СУБД
3. скорость работы — индексирование данных в таблицах и построение представлений не «вообще», а оптимизированных под выполнение конкретных запросов на чтение, добавление и модификацию данных
4. низкие требования к вычислительным ресурсам — отсутствие массы неоптимизированных запросов к БД из программных модулей, кстати, самих потребляющих системные ресуры при работе
5. простота написания и модификации WEB-интерфейсов — один, как правило примитивный, sql-запрос к базе на страничку
6. удобство поддержки и простота проведения доработок — весь код находится в одном месте, а не «размазан» по отдельным модулям
7. простота установки системы и низкая стоимость владения — сводится, в основном, к инсталляции и поддержке работы сервера PostgreSQL.
В общем-то не супер-оригинальная концепция «биллинг — это БД» была последовательно проведена при разработке и доведена до состояния коммерческого продукта АСР «ASBS», способного успешно конкурировать с имеющимися на этом рынке системами.
1. надёжность — прекомпиляцию, оптимизацию и исполнение кода выполняет СУБД
2. корректность хранимых данных — проверкой правильности пользовательского ввода и поддержкой целостности данных занимается СУБД
3. скорость работы — индексирование данных в таблицах и построение представлений не «вообще», а оптимизированных под выполнение конкретных запросов на чтение, добавление и модификацию данных
4. низкие требования к вычислительным ресурсам — отсутствие массы неоптимизированных запросов к БД из программных модулей, кстати, самих потребляющих системные ресуры при работе
5. простота написания и модификации WEB-интерфейсов — один, как правило примитивный, sql-запрос к базе на страничку
6. удобство поддержки и простота проведения доработок — весь код находится в одном месте, а не «размазан» по отдельным модулям
7. простота установки системы и низкая стоимость владения — сводится, в основном, к инсталляции и поддержке работы сервера PostgreSQL.
В общем-то не супер-оригинальная концепция «биллинг — это БД» была последовательно проведена при разработке и доведена до состояния коммерческого продукта АСР «ASBS», способного успешно конкурировать с имеющимися на этом рынке системами.
Размещение всей бизнес-логики системы, описанной отношениями между сущностями, ограничениями, проверками, правилами, триггерами и функциями, непосредственно в базе данных на наш взгяд имеет следующие преимущества
Все вами перечисленное это свойства СУБД, а не вашей системы. Свойства биллинга это к примеру конвергентность, это когда биллингу без разницы что считать байты, минуты, предоставление доступа к mp3, апельсины. Пока вы про свою систему важного сказали следующее:
1. Использует СУБД PostgreSQL
2. Бизнес-логика работает внутри СУБД
3. Умеет работать с такими источниками данных RADIUS, netflow и sflow
4. Сертифицирована для использования
А теперь сравните то что вы написали и что я написал в 4 строки.
В общем-то не супер-оригинальная концепция «биллинг — это БД» была последовательно проведена при разработке и доведена до состояния коммерческого продукта АСР «ASBS», способного успешно конкурировать с имеющимися на этом рынке системами.
Вот из вашего текста совершенно не понятно чем же она лучше NetAMS или Lanbilling ну разве что кроме использования PostgreSQL в качестве СУБД.
Все вами перечисленное это свойства СУБД, а не вашей системы. Свойства биллинга это к примеру конвергентность, это когда биллингу без разницы что считать байты, минуты, предоставление доступа к mp3, апельсины. Пока вы про свою систему важного сказали следующее:
1. Использует СУБД PostgreSQL
2. Бизнес-логика работает внутри СУБД
3. Умеет работать с такими источниками данных RADIUS, netflow и sflow
4. Сертифицирована для использования
А теперь сравните то что вы написали и что я написал в 4 строки.
В общем-то не супер-оригинальная концепция «биллинг — это БД» была последовательно проведена при разработке и доведена до состояния коммерческого продукта АСР «ASBS», способного успешно конкурировать с имеющимися на этом рынке системами.
Вот из вашего текста совершенно не понятно чем же она лучше NetAMS или Lanbilling ну разве что кроме использования PostgreSQL в качестве СУБД.
1. Когда БД используется как хранилище данных, то действительно — это всё отвлечённые фичи СУБД. Если же принять модель «биллинг = БД», то возможности, предоставляемые СУБД, выходят на передний план. Чем их больше и чем они изощрённее — тем проще создать надёжную и высокопроизводительную биллинговую систему.
2. «Конвергентность» — красивое слово. Правда лукавое, как и всё, что предлагается в качестве панацеи. Иными словами — у любой медали есть обратная сторона. Конечно, здорово, что можно использовать любой источник данных, однако:
— требуется предбиллинг, конвертирующий исходные данные в некий универсальный формат, понятный системе, причём для каждого источника — специфический
— исходные данные часто тоже надо хранить
— команды управления доступам к сервисам, которые биллинг должен выдать на основании загруженных данных (блокировки, шейпирование и т.п.) также специфичны
В предлагаемой системе набор источников данных фиксирован, также как и алгоритмы обработки, хранения и доступа к данным. Действительно, зачем, к примеру, в случае использования протокола RADIUS данные о сессиях преобразовывать для тарификации и хранения в другой формат? Кроме того, используя параметы сессии ею можно (и нужно) управлять (разрывать, менять с помощью CoA атрибуты и т.д.).
Для управления устройствами доступа (блокировки), управления скоростью доступа (шейперы), приёма автоматизированных платежей (электронные платёжные системы, продукты «1С» и т.п.), всевозможными дополнительными услугами система предоствляет простые интерфейсы. Они достаточно универсальны, например, услуга может иметь произвольное количество параметров произвольного формата.
Сравнивать различные модели построения биллинговых систем можно в плане набора потребительских свойств. Для сравнения производительности вероятно нужны стендовые испытания.
2. «Конвергентность» — красивое слово. Правда лукавое, как и всё, что предлагается в качестве панацеи. Иными словами — у любой медали есть обратная сторона. Конечно, здорово, что можно использовать любой источник данных, однако:
— требуется предбиллинг, конвертирующий исходные данные в некий универсальный формат, понятный системе, причём для каждого источника — специфический
— исходные данные часто тоже надо хранить
— команды управления доступам к сервисам, которые биллинг должен выдать на основании загруженных данных (блокировки, шейпирование и т.п.) также специфичны
В предлагаемой системе набор источников данных фиксирован, также как и алгоритмы обработки, хранения и доступа к данным. Действительно, зачем, к примеру, в случае использования протокола RADIUS данные о сессиях преобразовывать для тарификации и хранения в другой формат? Кроме того, используя параметы сессии ею можно (и нужно) управлять (разрывать, менять с помощью CoA атрибуты и т.д.).
Для управления устройствами доступа (блокировки), управления скоростью доступа (шейперы), приёма автоматизированных платежей (электронные платёжные системы, продукты «1С» и т.п.), всевозможными дополнительными услугами система предоствляет простые интерфейсы. Они достаточно универсальны, например, услуга может иметь произвольное количество параметров произвольного формата.
Сравнивать различные модели построения биллинговых систем можно в плане набора потребительских свойств. Для сравнения производительности вероятно нужны стендовые испытания.
Если же принять модель «биллинг = БД», то возможности, предоставляемые СУБД, выходят на передний план.
От этого они фичами СУБД они не перестают быть.
«Конвергентность» — красивое слово. Правда лукавое, как и всё, что предлагается в качестве панацеи. Иными словами — у любой медали есть обратная сторона.
Это необходимость если вы начинаете предоставлять в корне разные услуги.
— требуется предбиллинг, конвертирующий исходные данные в некий универсальный формат, понятный системе, причём для каждого источника — специфический
Такой процессинг требуется всегда. Ни один из виденных мной биллингов не использовал сырые данные напрямую.
— исходные данные часто тоже надо хранить
Вот их лучше хранить отдельно в базе биллинга им делать нечего.
— команды управления доступам к сервисам, которые биллинг должен выдать на основании загруженных данных (блокировки, шейпирование и т.п.) также специфичны
Это совершенно не мешает конвергентности биллинга. Все специфичные части легко выносятся в отдельные модули.
В предлагаемой системе набор источников данных фиксирован, также как и алгоритмы обработки, хранения и доступа к данным. Действительно, зачем, к примеру, в случае использования протокола RADIUS данные о сессиях преобразовывать для тарификации и хранения в другой формат?
И это плохо. У вас уже учтенные услуги должны быть абстрагированы от того как они были получены и что они из себя представляют. Потому что клиента интересует сколько он потребил услуг, а не сколько байт он употребил.
Кроме того, используя параметы сессии ею можно (и нужно) управлять (разрывать, менять с помощью CoA атрибуты и т.д.).
Кто мешает разделять конвергентную часть и специфическую часть для предоставляемых услуг? Правильный ответ никто.
Для управления устройствами доступа (блокировки), управления скоростью доступа (шейперы), приёма автоматизированных платежей (электронные платёжные системы, продукты «1С» и т.п.), всевозможными дополнительными услугами система предоствляет простые интерфейсы. Они достаточно универсальны, например, услуга может иметь произвольное количество параметров произвольного формата.
Фраза услуга может иметь произвольное количество параметров произвольного формата меня уже радует. Зачем это надо и почему это так?
Сравнивать различные модели построения биллинговых систем можно в плане набора потребительских свойств. Для сравнения производительности вероятно нужны стендовые испытания.
Это вообще не понятно к чему тут написано. Поймите у вас нет модели, у вас есть инструментальные средства. Модель все же может присутствовать в рамках предметной области а не вне ее.
От этого они фичами СУБД они не перестают быть.
«Конвергентность» — красивое слово. Правда лукавое, как и всё, что предлагается в качестве панацеи. Иными словами — у любой медали есть обратная сторона.
Это необходимость если вы начинаете предоставлять в корне разные услуги.
— требуется предбиллинг, конвертирующий исходные данные в некий универсальный формат, понятный системе, причём для каждого источника — специфический
Такой процессинг требуется всегда. Ни один из виденных мной биллингов не использовал сырые данные напрямую.
— исходные данные часто тоже надо хранить
Вот их лучше хранить отдельно в базе биллинга им делать нечего.
— команды управления доступам к сервисам, которые биллинг должен выдать на основании загруженных данных (блокировки, шейпирование и т.п.) также специфичны
Это совершенно не мешает конвергентности биллинга. Все специфичные части легко выносятся в отдельные модули.
В предлагаемой системе набор источников данных фиксирован, также как и алгоритмы обработки, хранения и доступа к данным. Действительно, зачем, к примеру, в случае использования протокола RADIUS данные о сессиях преобразовывать для тарификации и хранения в другой формат?
И это плохо. У вас уже учтенные услуги должны быть абстрагированы от того как они были получены и что они из себя представляют. Потому что клиента интересует сколько он потребил услуг, а не сколько байт он употребил.
Кроме того, используя параметы сессии ею можно (и нужно) управлять (разрывать, менять с помощью CoA атрибуты и т.д.).
Кто мешает разделять конвергентную часть и специфическую часть для предоставляемых услуг? Правильный ответ никто.
Для управления устройствами доступа (блокировки), управления скоростью доступа (шейперы), приёма автоматизированных платежей (электронные платёжные системы, продукты «1С» и т.п.), всевозможными дополнительными услугами система предоствляет простые интерфейсы. Они достаточно универсальны, например, услуга может иметь произвольное количество параметров произвольного формата.
Фраза услуга может иметь произвольное количество параметров произвольного формата меня уже радует. Зачем это надо и почему это так?
Сравнивать различные модели построения биллинговых систем можно в плане набора потребительских свойств. Для сравнения производительности вероятно нужны стендовые испытания.
Это вообще не понятно к чему тут написано. Поймите у вас нет модели, у вас есть инструментальные средства. Модель все же может присутствовать в рамках предметной области а не вне ее.
Это необходимость если вы начинаете предоставлять в корне разные услуги.
Это вы про торговлю фруктами (апельсинами) :-))? Мы позиционируемся на рынке ISP.
Выделение «конвергентной» части усложняет структуру системы, тем самым уменьшает её надёжность, скорость работы, увеличивает затраты на оборудование и сопровождение. Выигрыш поставщика услуг при этом, на наш взгляд, эфемерен. Если у него появилось уникальное оборудование (услуга), ему же всё равно придётся обратиться к разработчику за обеспечением программной поддержки.
Нам показалось, что наличие в системе простых интерфейсов к системам управления доступом, скоростью доступа, системам приёма автоматизированных платежей и возможностью тарифицировать самостоятельно создаваемые дополнительные услуги гораздо более актуально для основной массы небольших и средних провайдеров Интернет. При этом все проблемы — все лишь написать (найти в Инете) скрипт управления конкретным имеющимся оборудованием.
Это вы про торговлю фруктами (апельсинами) :-))? Мы позиционируемся на рынке ISP.
Выделение «конвергентной» части усложняет структуру системы, тем самым уменьшает её надёжность, скорость работы, увеличивает затраты на оборудование и сопровождение. Выигрыш поставщика услуг при этом, на наш взгляд, эфемерен. Если у него появилось уникальное оборудование (услуга), ему же всё равно придётся обратиться к разработчику за обеспечением программной поддержки.
Нам показалось, что наличие в системе простых интерфейсов к системам управления доступом, скоростью доступа, системам приёма автоматизированных платежей и возможностью тарифицировать самостоятельно создаваемые дополнительные услуги гораздо более актуально для основной массы небольших и средних провайдеров Интернет. При этом все проблемы — все лишь написать (найти в Инете) скрипт управления конкретным имеющимся оборудованием.
Это вы про торговлю фруктами (апельсинами) :-))? Мы позиционируемся на рынке ISP.
Это я про предоставление услуг интернета и услуг телефонной связи, это в корне разные вещи.
Выделение «конвергентной» части усложняет структуру системы, тем самым уменьшает её надёжность, скорость работы, увеличивает затраты на оборудование и сопровождение.
Зато повышает гибкость и модифицируемость системы под нужды ISP. Насчет надежности и скорости я могу поспорить. Если делать все правильно это сильно не сказывается.
Выигрыш поставщика услуг при этом, на наш взгляд, эфемерен.
Если у него появилось уникальное оборудование (услуга), ему же всё равно придётся обратиться к разработчику за обеспечением программной поддержки.
Далеко не эфемерен. В случае конвергентной системы затраты на внедрение новой услуги ниже. В том числе и со стороны разработчика.
Нам показалось, что наличие в системе простых интерфейсов к системам управления доступом, скоростью доступа, системам приёма автоматизированных платежей и возможностью тарифицировать самостоятельно создаваемые дополнительные услуги гораздо более актуально для основной массы небольших и средних провайдеров Интернет.
Из вашего текста не понятно чем ваши интерфейсы проще чем у других.
Это я про предоставление услуг интернета и услуг телефонной связи, это в корне разные вещи.
Выделение «конвергентной» части усложняет структуру системы, тем самым уменьшает её надёжность, скорость работы, увеличивает затраты на оборудование и сопровождение.
Зато повышает гибкость и модифицируемость системы под нужды ISP. Насчет надежности и скорости я могу поспорить. Если делать все правильно это сильно не сказывается.
Выигрыш поставщика услуг при этом, на наш взгляд, эфемерен.
Если у него появилось уникальное оборудование (услуга), ему же всё равно придётся обратиться к разработчику за обеспечением программной поддержки.
Далеко не эфемерен. В случае конвергентной системы затраты на внедрение новой услуги ниже. В том числе и со стороны разработчика.
Нам показалось, что наличие в системе простых интерфейсов к системам управления доступом, скоростью доступа, системам приёма автоматизированных платежей и возможностью тарифицировать самостоятельно создаваемые дополнительные услуги гораздо более актуально для основной массы небольших и средних провайдеров Интернет.
Из вашего текста не понятно чем ваши интерфейсы проще чем у других.
АСР Pyzzle.ISP pyzzle.ru
тоже полностью открытый исходный код, системе пофигу что считать, хоть мандарины. Написана на python, база по дефолту mysql, но запустить на постгресе тоже не составляет большого труда. 8-)
Вот как все можно описать в двух словах 8-)
тоже полностью открытый исходный код, системе пофигу что считать, хоть мандарины. Написана на python, база по дефолту mysql, но запустить на постгресе тоже не составляет большого труда. 8-)
Вот как все можно описать в двух словах 8-)
Добрый день, Александр! Добрый день %username%!
Увидел упоминание о вашем продукте, не смог пройти мимо. Пробовал работать и участвовал во внедрении этого «биллинга». Могу сказать, не стрит даже читать столько много букв. Вся система по настоящее время работает на пхе скриптах (это на шелл). Все периодические задачи, такие как списание абон платы, смена расчетного периода, блокировка пользователя и т.д. Работает на пхп скриптах, которые с rwx запускаются от рута кроном, в субд на машине с локалью UTF8 бд имеет cp1251. Коллекторы для учета трафика писаны на пехепе. Система ВСЯ состоит из подпорок, очевидно, что программист владеет веб дизайном и не более. Причем если присмотреться внимательнее обнаруживается много лажи. Например жжены могли друг у друга деньги тырить, меняя ip адрес, ну это мелочи. Роли пользователей прописываются не в субд а в скриптах веб интерфейса, тоесть администратор от не администратора отличается скрытыми менюшками в пехепе. Роли правятся инъекциями, я думаю с такой организацией безопасности вы понимаете сами как легко такое сделать, можно банально подсмоореть урл и дальше выполнить тоже самое действие или другое с правами суперпользователя. Ну я уже многое не помню, но если кому будет интересно — пишите в почту, отвечу. Чтобы все понимали — я представитель компании в которой это внедрялось впервые, я тогда работал системным администратором. Есть много деталей о которых писать лениво, так что извиняйте что отвлек, хотел предупредить людей о кидалове и лжи. Да и в плане поддержки внедренной системы все выглядело как целование в жопу разработчика для закрывания им же своих же косяков, и каждый раз латая за собой это выливалось в новый счет на оплату и новую версию системы. Вобщем Александр — не раньте людям мозги, те полтора года ада, которые имел несчастье работать с вами, мы все вспоминаем как страшный сон, как я говорил раньше — надо учиться новому, а ваши навыки 30 летней давности никому не нужны. Локаль в субд старинная тоже плоХо, дыры тоже, хранить пароли плэйнтекстрм в субд вообще плохо. Вобщем я все. Спасибо пожалуйста.
Увидел упоминание о вашем продукте, не смог пройти мимо. Пробовал работать и участвовал во внедрении этого «биллинга». Могу сказать, не стрит даже читать столько много букв. Вся система по настоящее время работает на пхе скриптах (это на шелл). Все периодические задачи, такие как списание абон платы, смена расчетного периода, блокировка пользователя и т.д. Работает на пхп скриптах, которые с rwx запускаются от рута кроном, в субд на машине с локалью UTF8 бд имеет cp1251. Коллекторы для учета трафика писаны на пехепе. Система ВСЯ состоит из подпорок, очевидно, что программист владеет веб дизайном и не более. Причем если присмотреться внимательнее обнаруживается много лажи. Например жжены могли друг у друга деньги тырить, меняя ip адрес, ну это мелочи. Роли пользователей прописываются не в субд а в скриптах веб интерфейса, тоесть администратор от не администратора отличается скрытыми менюшками в пехепе. Роли правятся инъекциями, я думаю с такой организацией безопасности вы понимаете сами как легко такое сделать, можно банально подсмоореть урл и дальше выполнить тоже самое действие или другое с правами суперпользователя. Ну я уже многое не помню, но если кому будет интересно — пишите в почту, отвечу. Чтобы все понимали — я представитель компании в которой это внедрялось впервые, я тогда работал системным администратором. Есть много деталей о которых писать лениво, так что извиняйте что отвлек, хотел предупредить людей о кидалове и лжи. Да и в плане поддержки внедренной системы все выглядело как целование в жопу разработчика для закрывания им же своих же косяков, и каждый раз латая за собой это выливалось в новый счет на оплату и новую версию системы. Вобщем Александр — не раньте людям мозги, те полтора года ада, которые имел несчастье работать с вами, мы все вспоминаем как страшный сон, как я говорил раньше — надо учиться новому, а ваши навыки 30 летней давности никому не нужны. Локаль в субд старинная тоже плоХо, дыры тоже, хранить пароли плэйнтекстрм в субд вообще плохо. Вобщем я все. Спасибо пожалуйста.
Сори за опечатки, автокоррекция на мобильных устройствах стала суровой, не уследил.
Да уж, Максим, отсутствие профессиональных знаний вам всегда сильно мешало (не из-за этого пришлось уволиться из компании провайдера?). Вы так до сих пор и не разобрались, как устроена и работает система. Похоже, даже её краткое описание в этом топике не прочитали.
Очень жаль, что вводите читателей блога в заблуждение. Однако, по порядку (синтаксис автора оставил без изменений):
1. «Вся система по настоящее время работает на пхе скриптах» — вся система работает на PostgreSQL
2. «Все периодические задачи, такие как… Работает на пхп скриптах, которые с rwx запускаются от рута кроном» — подсистема управления построена на планировщике задач pgAgent
3. «в субд на машине с локалью UTF8 бд имеет cp1251» — локаль кластера БД не имеет никакого отношения к системной локали
4. «Коллекторы для учета трафика писаны на пехепе» — система поставляется настроенной для работы с коллектором и агрегатором NetFlow из пакета nfdump
5. «Роли пользователей прописываются не в субд а в скриптах веб интерфейса» — роль системного пользователя — это один из атрибутов справочника пользователей базы данных
6. «Роли правятся инъекциями» — в WEB-интерфейсе администратора предусмотрена защита от sql-инъекций
7. «хранить пароли плэйнтекстрм в субд вообще плохо» — пароли пользователей хранятся в хешированном виде
8. «я представитель компании в которой это внедрялось впервые» — и это тоже неправда
На прочие огульные типа «система ВСЯ состоит из подпорок» и «жжены могли друг у друга деньги тырить» и просто оскорбительные высказывания я, конечно, отвечать не намерен.
Очень жаль, что вводите читателей блога в заблуждение. Однако, по порядку (синтаксис автора оставил без изменений):
1. «Вся система по настоящее время работает на пхе скриптах» — вся система работает на PostgreSQL
2. «Все периодические задачи, такие как… Работает на пхп скриптах, которые с rwx запускаются от рута кроном» — подсистема управления построена на планировщике задач pgAgent
3. «в субд на машине с локалью UTF8 бд имеет cp1251» — локаль кластера БД не имеет никакого отношения к системной локали
4. «Коллекторы для учета трафика писаны на пехепе» — система поставляется настроенной для работы с коллектором и агрегатором NetFlow из пакета nfdump
5. «Роли пользователей прописываются не в субд а в скриптах веб интерфейса» — роль системного пользователя — это один из атрибутов справочника пользователей базы данных
6. «Роли правятся инъекциями» — в WEB-интерфейсе администратора предусмотрена защита от sql-инъекций
7. «хранить пароли плэйнтекстрм в субд вообще плохо» — пароли пользователей хранятся в хешированном виде
8. «я представитель компании в которой это внедрялось впервые» — и это тоже неправда
На прочие огульные типа «система ВСЯ состоит из подпорок» и «жжены могли друг у друга деньги тырить» и просто оскорбительные высказывания я, конечно, отвечать не намерен.
вся система работает на PostgreSQL
Веб-интерфейс тоже? И коллекторы?
локаль кластера БД не имеет никакого отношения к системной локали
Вообще сейчас использовать cp1251 в базе это прошлый век. Особенно при использовании UTF-8 локально на машине. В своем биллинге для SOHO мы сделали это в версии 1.0.1 тогда еще знаете для PostgreSQL autovacuum отдельно был.
система поставляется настроенной для работы с коллектором и агрегатором NetFlow из пакета nfdump
Насколько я вижу коллектор пишет файлы. А дальше как работа с ними производится? У меня к примеру производится агрегация трафика по направлениям прямо с netflow collector дальше уже раз в N минут производится сброс статистики в СУБД.
роль системного пользователя — это один из атрибутов справочника пользователей базы данных
Вы таки скажите атрибут или вы все же права СУБД используете?
и это тоже неправда
А что правда?
По поводу коллекторов, у него с нфдампа пишется в рав. А этот рав разгребается пехепе скриптом по крону, выборка парсится и падает уде в бд, тоесть итоговые вещи дабы не захламлять
Мдяя. Вообще грести СРАЗУ из netflow никакой проблемы не составляет.
Там как то все сложнее, скрипт мониторит и количество файлов, причем как распарсит, Джеками их, на всяк случай. Частенько бывало вся система висела иовэйтами, когда он с файлами работал. Тогда учет трафика все еще был популярен, помнится по этой причине похерилась вся инфа о трафике за несколько дней, файлы копились, а скрипт не успевал. Потом он уде вручную Джеков парсил что бы в бд тарифицировать. Про то что плохо работать с файлами, и что винт самое узкое место, ему не понять, а жаль. Хотя 2года прошло уж, может додумались поправить… Ну тут вообще вся проблема в идеологии, типа постгрес все делает сам, а про остальное и слышать не хотим. Одна фича нормальная и куча костылей. Кстати не понятно как сертификат получали, коллектор же должен быть бинарным. Я конечно понимаю, что лажу совать в биллинг можно на любом этапе, но куда уж проще править файлы на фс и махать перед обиженным абонентом сертификатом. Требования ростеста не учтены явно.
Да, в бд атрибут. У системных юзеров есть атрибут -буковка, если буква v одни права, d другие, конкретной не помню, но чет типа того, плавился сей атрибут инъекцией не сложно. Надеюсь поправят.
Вообще в PostgreSQL есть нефиговая система прав. Учитывая что все функции и логика сделаны в СУБД можно было банально разрулить через кому какие функции доступны.
Да в том то и дело, мы плевались от этого порно целый год, там если по мелочи, сотни косяков будут, я уж все не помню конечно досконально, но я лично не понимаю как это можно сравнивать даже с ланбиллингом и нетапом, они в сравнении просто элегантны. Хотя к ним претензий тоже не мало, но можно и самому допилить, а тут на каждое замечание — ответ куда вам, вы все тупые а я дартаньян. Кстати из приколов: когда при переносе данных из старого утм в это, мы делали выборки для импорта, этот человек заворачивал присланный ему CSV и требовал убрать пробелы в первой строке и выслать обратно ;) такого было много :)
Я написал свое мнение. Выводы о моей компетенции Пусть делают профессионалы. По мастерства о которых вы ответили с цитатами, могу документально подтвердить, у меня цела вся переписка, все ваши скриптах и пр. Но как нормальный человек, грязным бельем торговать не собираюсь. Если кто либо захочет уточнить, я более конкретно отвечу по имэйл, а лучше по телефону. Так что пишите в почту, там договоримся. Я считаю, не к лицу вам в вашем возрасте оправдываться, поэтому будьте уже честны с собой до конца. Вы сами знаете, что беспочвенно обвинять кого либо я не стал бы, и если уж пишу тут, значит имею на то основания. На этом я оканчиваю свое участие в холиварах, дабы не утомляли публику сообщества. Лично я бы перед покупкой продукта обязательно изучил в первую очередь отрицательные мнения, и лично убедился, если как вы говорите, что человек не компетентен или врет, дабы на душе спокойней стало. Спасибо всем за внимание.
max@svoyo.com
max@svoyo.com
У вас радиус напрямую с базой общается? Мы к нему плагин рисовали с нужной логикой, система получилась более прозрачной.
В плагинах для работы системы нет никакой надобности, т.к. ядро общается с RADIUS-сервером без посредников. А именно: все конфигурационные настройки и сведения о сессиях хранятся в БД.
Для FreeRADIUS плагин не нужен. Там SQL-плагин умеет более чем достаточно.
code.google.com/p/cakebilling/wiki/ConfiguringFreeRadius
code.google.com/p/cakebilling/wiki/ConfiguringFreeRadius
Достаточно для чего, простите? У нас для аутентификации по MS-CHAP и OpenVPN используются разные пароли (первый приходится хранить открытым текстом (в смысле, шифрованный, а не хэш, но всё-равно не безопасно), ибо это MS-CHAP), согласно требованиям к функционалу биллинга для части NAS трафик не учитывается вообще, для части не лимитируется только на конкретных тарифах, для части идёт с множителем. Как обработку этой логики без костылей и трёхэтажных конструкций реализовать исключительно на sql-плагине, я себе слабо представляю, да и разбираться не горю желанием — уж лучше вменяемый и предсказуемый код на сишке.
Достаточно для чего, простите?
Для обеспечения AAA.
У нас для аутентификации по MS-CHAP и OpenVPN используются разные пароли (первый приходится хранить открытым текстом (в смысле, шифрованный, а не хэш, но всё-равно не безопасно), ибо это MS-CHAP)
А это собственно тут причем? Разные источники данных? Для первого и второго? Да легко тут плагин вообще не причем, делается штатными средствами FreeRADIUS. Грим это брать отсюда это брать отсюда. Источников можно штамповать сколько требуется.
согласно требованиям к функционалу биллинга для части NAS трафик не учитывается вообще, для части не лимитируется только на конкретных тарифах, для части идёт с множителем. Как обработку этой логики без костылей и трёхэтажных конструкций реализовать исключительно на sql-плагине, я себе слабо представляю
В SQL-плагине реализуется только одна вещь. Вызов хранимой процедуры которая дальше учитывая что там за IP и сколько байтов пришло и сколько байтов в базе лежит может считать поразному. Поверьте мне это существенно гибче и проще чем пересобирать каждый раз C-плагин для RADIUS сервера. Пример реализации можно как раз посмотреть в cakebilling. Там тарификация сделана именно так.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опыт создания концептуальной биллинговой системы для ISP