Опыт установки 5.3 на боевом сервере
1) В урфа появилась функция "rpcf_remove_house". А в админке не появилась кнопка удалить дом.
2) Еще с прошлый версий тянется "масло маслянное". Когда пользователя привязываем к коммутатору и порту, при этом коммутатор выбираем из списка файрволов, и при этом назначении правил файрволов в списке передающих параметров можем передать коммутатор (т.е. файрволл). Сделайте поле "Порт" текстовым, чтобы туда можно было бы записать 192.168.1.1:39 (ипадрес:порт) сразу миллион проблем решите у пользователей.
2) Еще с прошлый версий тянется "масло маслянное". Когда пользователя привязываем к коммутатору и порту, при этом коммутатор выбираем из списка файрволов, и при этом назначении правил файрволов в списке передающих параметров можем передать коммутатор (т.е. файрволл). Сделайте поле "Порт" текстовым, чтобы туда можно было бы записать 192.168.1.1:39 (ипадрес:порт) сразу миллион проблем решите у пользователей.
Честно говоря необходимость привязки пользователя к фаерволу и порту не могу обосновать в той реализации как сейчас, так как у одного пользователя может быть несколько лицевых счетов, при этом не факт что устройства указанные в IP группах могут быть подключены к одному коммутатору.serjk писал(а):2) Тогда проще добавить строковое поле "Порт" в свойства IP-группы
Создание несколько тысяч фаерволов тоже выглядит проблематично. Фактически вы в списке брандмауеров объединили два класса устройств, одни пользуются для управления оборудованием, а вторые являются тем самым оборудованием.
Как минимум было бы лучше просто задать указание remote_switch_id как строковый параметр принимающий любой IP адрес и сохраняющий его в таблице, но выше я пояснил что это не есть правильное решение.
Поэтому лучше добавить в свойства IP группы дополнительные поля "Коммутатор" и "Порт", а из "Других" вообще убрать данный функционал.
Еще нюанс по телефонии, сейчас пулы номеров приходится хранить на листочке, было бы неплохо иметь возможность завести списки телефонных номеров в биллинг. С указанием у каждого номера:
Категории (можно применить для вычисления стоимость выделения номера, в случае золотых)
Даты добавления пользователю (если активен)
Пользователь (если активен)
Дата последнего пользования (для того чтобы такие номера выдавать повторно в последнюю очередь)
Категории (можно применить для вычисления стоимость выделения номера, в случае золотых)
Даты добавления пользователю (если активен)
Пользователь (если активен)
Дата последнего пользования (для того чтобы такие номера выдавать повторно в последнюю очередь)
раз уж подняли тему коммутаторов и портов, добавлю свои 5 копеек.
Нынешняя схема указания коммутатора и порта реально никуда не годится. При наличии более 1500 коммутаторов листать список - забодаешься.
1.На данный момент выходим из ситуации следующим образом:
1.1. В доп.полях есть поле, в котором указывается имя-свича_вилан_порт,порт,порт - это поле парсится внутренними процедурами dhcp-сервера, который работает с dhcp option82 и лазит в базу биллинга, чтобы выяснить какие адреса отдавать по dhcp. Использовать это поле тоже не удобно, т.к. возникают проблемы с индексами и приходится городить доп.проверки, а было бы проще, если бы можно было создать уникальный индекс для такого поля.
1.2. В базе есть отдельная таблица, в которой хранится соответствие opt82 agentid(мак коммутатора) его полному имени в dns(актуальное состояние поддерживается автоматически системой мониторинга коммутаторов), эта таблица используется при парсинге доп.поля, т.к. писать ip-адреса коммутаторов - муторно и они могут меняться время от времени, хотя и имена тоже могут меняться, но с именами проще работать.
1.3. один пользователь может быть включен только в один коммутатор, но может использовать несколько портов в нем(указываются через запятую), если надо включить пользователя в другой коммутатор или по другому адресу, то заводится новая учетная запись, с разными лицевыми счетами на подной учетке не связываемся, т.к. когда-то давно возникали проблемы с тарифами и обсчетом, если у одной учетки было несколько лицевых счетов, да и к тому же доп.параметры указываются только для учетной записи, а не лицевого счета.
2. В связи со всем вышеописанным, было бы здорово, если бы в настройках биллинга можно было хранить:
2.1 opt82 agent remote id коммутатора - char(12)(1cbdb9562b00), либо целиком - char(16) (00061cbdb9562b00)
2.2 имя коммутатора, для идентификации, мы используем короткие имена, т.е. без домена - varchar(9)
2.3 опционально ip-адрес, но при использовании dns в нем нет смысла вообще, его в INT(11) Unsigned, чтоб стандартные inet_aton/ntoa работали, а не тот изврат, что используется сейчас.
2.4. заметки по коммутатору.
3. В то же в ремя в настройках учетной записи:
3.1. opt82 circuit id клиента - (0004001e001a), либо сразу разобрать на vlanid и порт и хранить их отдельно в разных полях - vlanid int(4), port int(3). Все равно всем этим будет пользоваться сторонний софт, выполнящий работу dhcp-сервера, преобразования можно делать и в нем, главное, чтобы в базе это хранилось оптимально и через админку можно было подправить в дружественном человеку виде.
3.2. имя свича, из глобальных настроек, желательно с возможностью быстрой фильтрации при наборе имени. Адресным справочником не пользуемся из-за неудобства работы с ним, поэтому привязывать свич к дому из справочник - нет смысла
Хранить свич, вилан и порт в настройках ip-группы нет смысла, т.к. как только тариф снимается - все данные уходят, а информация о свиче и порте может еще пригодится.
А вот еще что хотелось бы - так это оптимизацию работы с радиус-атрибутами, нынешняя схема не позволяет на полную использовать возможности Ericsson(Redback) BRAS'ов, которым можно передавать несколько однотипным атрибутов с разным индексом и значением, например:
1.
vendor: 2352
attr: 81:1
value: Policy-name1
2.
vendor: 2352
attr: 81:2
value: Policy-name2
Добавить бы еще поле для индекса, который бы добавлялся к атрибуту при передаче.
Все вышесказанное IMHO, у нас и так все работает своими силами, но было бы удобнее, если бы эта часть была реализована в биллинге.
Нынешняя схема указания коммутатора и порта реально никуда не годится. При наличии более 1500 коммутаторов листать список - забодаешься.
1.На данный момент выходим из ситуации следующим образом:
1.1. В доп.полях есть поле, в котором указывается имя-свича_вилан_порт,порт,порт - это поле парсится внутренними процедурами dhcp-сервера, который работает с dhcp option82 и лазит в базу биллинга, чтобы выяснить какие адреса отдавать по dhcp. Использовать это поле тоже не удобно, т.к. возникают проблемы с индексами и приходится городить доп.проверки, а было бы проще, если бы можно было создать уникальный индекс для такого поля.
1.2. В базе есть отдельная таблица, в которой хранится соответствие opt82 agentid(мак коммутатора) его полному имени в dns(актуальное состояние поддерживается автоматически системой мониторинга коммутаторов), эта таблица используется при парсинге доп.поля, т.к. писать ip-адреса коммутаторов - муторно и они могут меняться время от времени, хотя и имена тоже могут меняться, но с именами проще работать.
1.3. один пользователь может быть включен только в один коммутатор, но может использовать несколько портов в нем(указываются через запятую), если надо включить пользователя в другой коммутатор или по другому адресу, то заводится новая учетная запись, с разными лицевыми счетами на подной учетке не связываемся, т.к. когда-то давно возникали проблемы с тарифами и обсчетом, если у одной учетки было несколько лицевых счетов, да и к тому же доп.параметры указываются только для учетной записи, а не лицевого счета.
2. В связи со всем вышеописанным, было бы здорово, если бы в настройках биллинга можно было хранить:
2.1 opt82 agent remote id коммутатора - char(12)(1cbdb9562b00), либо целиком - char(16) (00061cbdb9562b00)
2.2 имя коммутатора, для идентификации, мы используем короткие имена, т.е. без домена - varchar(9)
2.3 опционально ip-адрес, но при использовании dns в нем нет смысла вообще, его в INT(11) Unsigned, чтоб стандартные inet_aton/ntoa работали, а не тот изврат, что используется сейчас.
2.4. заметки по коммутатору.
3. В то же в ремя в настройках учетной записи:
3.1. opt82 circuit id клиента - (0004001e001a), либо сразу разобрать на vlanid и порт и хранить их отдельно в разных полях - vlanid int(4), port int(3). Все равно всем этим будет пользоваться сторонний софт, выполнящий работу dhcp-сервера, преобразования можно делать и в нем, главное, чтобы в базе это хранилось оптимально и через админку можно было подправить в дружественном человеку виде.
3.2. имя свича, из глобальных настроек, желательно с возможностью быстрой фильтрации при наборе имени. Адресным справочником не пользуемся из-за неудобства работы с ним, поэтому привязывать свич к дому из справочник - нет смысла
Хранить свич, вилан и порт в настройках ip-группы нет смысла, т.к. как только тариф снимается - все данные уходят, а информация о свиче и порте может еще пригодится.
А вот еще что хотелось бы - так это оптимизацию работы с радиус-атрибутами, нынешняя схема не позволяет на полную использовать возможности Ericsson(Redback) BRAS'ов, которым можно передавать несколько однотипным атрибутов с разным индексом и значением, например:
1.
vendor: 2352
attr: 81:1
value: Policy-name1
2.
vendor: 2352
attr: 81:2
value: Policy-name2
Добавить бы еще поле для индекса, который бы добавлялся к атрибуту при передаче.
Все вышесказанное IMHO, у нас и так все работает своими силами, но было бы удобнее, если бы эта часть была реализована в биллинге.
Коммутатор/порт надо выносить в ip-группу.
Еще не плохо бы добавить поле External_id по типа как у лицевого счета к ip-группе и сервисной связке. и добавить комментарий для ЛС/Service link/IP group.
Еще не плохо было б что пользователи сами могли подключать услуги. Я конечно понимаю, что реализовывать некую универсальную логику этого достаточно муторно, но было б не плохо
Еще не плохо было б сделать типы технических параметров изменяемыми. Т.е. не web/email как сейчас, а чтоб можно было б их создавать, удалять.
Эх, мечты.....)
Еще не плохо бы добавить поле External_id по типа как у лицевого счета к ip-группе и сервисной связке. и добавить комментарий для ЛС/Service link/IP group.
Еще не плохо было б что пользователи сами могли подключать услуги. Я конечно понимаю, что реализовывать некую универсальную логику этого достаточно муторно, но было б не плохо
Еще не плохо было б сделать типы технических параметров изменяемыми. Т.е. не web/email как сейчас, а чтоб можно было б их создавать, удалять.
Эх, мечты.....)
Добавлю свои пять копеек.
Раньше установить пакет на Debian 6.0.X (amd 64) можно было так
появилась multiarch делаем так
Раньше установить пакет на Debian 6.0.X (amd 64) можно было так
- 1) apt-get install libxslt1.1
2) apt-get install ia32-libs
3) dpkg-reconfigure locales
en_US.UTF-8... done
ru_RU.UTF-8... done
4) dpkg -i --force-architecture utm 5.X.X
появилась multiarch делаем так
Код: Выделить всё
root@test:/# uname -a
Linux test 3.9-0.bpo.1-amd64 #1 SMP Debian 3.9.6-1~bpo70+1 x86_64 GNU/Linux
root@test:/# cat /etc/debian_version
7.1- 1) dpkg --add-architecture i386
2) apt-get install libxslt1.1:i386
3) apt-get install libc6:i386
4) apt-get install ia32-libs-i386:i386
5) Качаем (http://packages.debian.org/squeeze/i386 ... 8/download) libssl0.9.8_0.9.8o-4squeeze14_i386.deb и ставим его dpkg -i libssl0.9.8_0.9.8o-4squeeze14_i386.deb
6) dpkg -i utm5-3.001.deb
7) Проверяем ldd /netup/utm5/bin/utm5_core
linux-gate.so.1 => (0xf771e000)
libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xf75b9000)
libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xf756d000)
librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xf7563000)
libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xf754a000)
libgssapi_krb5.so.2 => /usr/lib/i386-linux-gnu/libgssapi_krb5.so.2 (0xf750c000)
libldap_r-2.4.so.2 => /usr/lib/i386-linux-gnu/libldap_r-2.4.so.2 (0xf74ba000)
libkrb5.so.3 => /usr/lib/i386-linux-gnu/libkrb5.so.3 (0xf73e8000)
libcrypt.so.1 => /lib/i386-linux-gnu/i686/cmov/libcrypt.so.1 (0xf73b5000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf72c9000)
libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xf72a3000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7286000)
libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xf7123000)
libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xf711e000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf7105000)
libcom_err.so.2 => /lib/i386-linux-gnu/libcom_err.so.2 (0xf7100000)
/lib/ld-linux.so.2 (0xf771f000)
libk5crypto.so.3 => /usr/lib/i386-linux-gnu/libk5crypto.so.3 (0xf70d6000)
libkrb5support.so.0 => /usr/lib/i386-linux-gnu/libkrb5support.so.0 (0xf70cd000)
libkeyutils.so.1 => /lib/i386-linux-gnu/libkeyutils.so.1 (0xf70c7000)
libresolv.so.2 => /lib/i386-linux-gnu/i686/cmov/libresolv.so.2 (0xf70b3000)
liblber-2.4.so.2 => /usr/lib/i386-linux-gnu/liblber-2.4.so.2 (0xf70a4000)
libsasl2.so.2 => /usr/lib/i386-linux-gnu/libsasl2.so.2 (0xf7088000)
libgnutls.so.26 => /usr/lib/i386-linux-gnu/libgnutls.so.26 (0xf6fbf000)
libgcrypt.so.11 => /lib/i386-linux-gnu/libgcrypt.so.11 (0xf6f39000)
libtasn1.so.3 => /usr/lib/i386-linux-gnu/libtasn1.so.3 (0xf6f27000)
libp11-kit.so.0 => /usr/lib/i386-linux-gnu/libp11-kit.so.0 (0xf6f15000)
libgpg-error.so.0 => /lib/i386-linux-gnu/libgpg-error.so.0 (0xf6f11000)
/netup/utm5/bin/utm5_core -v
NetUP UTM billing system core. Compile date: Jul 16 2013 17:13:47
Version:5.3-001-rc4-debian_squeeze Rev #rc4
Copyright (c) 2001-2013 NetUP Inc. www.netup.ru
Последний раз редактировалось ZeM Ср июл 17, 2013 15:21, всего редактировалось 1 раз.