Gigaset C610A IP

Вобщем настал момент, когда я решил объединить в одном девайсе стандартную проводную телефонию от МГТС и IP телефонию.

Раньше проводной телефон был отдельно (DECT Philips с парой трубок) и IP телефония от МТТ через шлюз Planet (со вторым noname DECT телефоном).
Выбирал недорогой IP телефон с возможностью подключения аналоговой проводной линии. Выбирал между Panasonic и Gigaset. В итоге выбрал Gigaset. Основной причиной была возможность подключения простых DECT трубок, у Панаса подключаются только специализированные трубки.
Вчерась привезли девайс, распаковал, включил. Настройка (включая обновление прошивки) заняла минут 10. Трубку от Phillips подключил сразу. К сожалению подключил только одну трубку, на второй ребенок раздавил экран и я не смог банально выбрать меню ввода кода базы :).

Что хотелось бы получить в итоге.

  1. Все исходящие на 495, 499, 812 и межгород делать через МТТ.
  2. Исходящие на мобилы и спец службы (112, 01, 02, 03), через МГТС. (Номер МГТС приходится оставлять, потому как многочисленная родня и знакомые жены и тестя знают только его. В перспективе перейду на самый дешевый повременной план.)
  3. Все входящие отображать на всех трубках, подключенных к девайсу.

На какие неприятности наткнулся:

  1. Если на простом DECT при поднятии трубки сразу выдается сигнал линии МГТС и ты можешь набирать номер «на слух» (это особенно важно при наборе через «8, пауза, код, номер телефона»). То тут все наоборот, сначала набираешь номер, потом телефон немного думает, подключает линию и начинает набирать номер. Поэтому приходится при наборе номера после 8-ки явно ставить символ паузы (R или P, зависит от производителя телефона). А зная качество связи МГТС, телефон после 8-ки может не дождаться ответа станции и продолжить набирать номер 🙁
  2. Настройка плана звонков в Gigaset-е убогая до безобразия. Рассчитана только на IP телефонию. Простой пример, хочу все звонки на код 916 МТС завернуть на телефон от МГТС. Т.е. все телефоны, номер которых начинается на 8P916 или 8R916, пускать на соответствующую линию. Ага, бананас! Gigaset не понимает символы паузы в номере! Вау! Т.е. если я хочу отловить номера мобилы я должен писать 8916, но см. пункт 1. Без паузы на МГТС не набрать такой номер! Обалденная засада! Слава Богу, на родной гигасетовской трубке можно выбрать линию, через которую придется делать звонок, но вот с другой трубой это сделать не получится. Поэтому пришлось жестко привязать все звонки с Филипса на МГТС :(, абидно.
  3. Сервисные службы, предоставляемые порталом Gigaset либо не работают, ли бо все через опу. Да и для отображения почты и прочая, производитель забыл поставить русские шрифты в трубку 🙂 или кодировки не понимает 🙂 Так что отключил я всю эту фигню. Тем более, что на не родных трубках это по определению не работает.
  4. WEB морда торомозиииит :). Но это не критично, потому как настраиваешь один раз, и забываешь про ее существование.

В итоге план звонков выглядит печально:
Трубка Philips жестко привязана к МГТС.
На гигасете установлен выбор линии при наборе номера.

01 -> МГТС
02 -> МГТС
03 -> МГТС
112 -> МГТС
8495 -> МТТ
8499 -> МТТ
8812 -> МТТ
Жене сказано, что все звонки по межгороду только через трубу Гигасет 🙂 (а шо? тоже план звоков, ага 🙂

Единственно радует, что если номер из плана звонков, то срабатывает линия, указанная в плане. Т.е при наборе на филипсе номера 8495ххххххх набор будет через МТТ. А вот если набирать 8P495ххххххх — соединение пойдет через МГТС.

Теперь вот сижу и думаю, как я это все объясню своей жене?! Чувствую придется таки докупать вторую трубу от гигасета 🙂

очистка истории сообщений в openfire

Предупреждаю сразу — сам еще не попробовал, надо дождаться выходных, когда люди спать будут 🙂

Вобщем всем хорош модуль Monitoring в openfire, но есть один боооольшой недостаток, нет возможности в WEB интерфейсе почистить историю сообщений. Тупо хранит все.
У друзей возникла задача, оставлять только свежие сообщения. Т.е. удалять все, что древнее одного месяца.
Полазив по базе openfire обнаружил табличку:

mysql> describe ofMessageArchive;
+—————-+—————+——+——+———+—-—+

| Field          | Type         | Null | Key | Default | Extra |
+—————-+—————+——+——+———+—-—+
| conversationID | bigint(20)   | NO   | MUL | NULL    |       |
| fromJID        | varchar(255) | NO   |     | NULL    |       |
| toJID          | varchar(255) | NO   |     | NULL    |       |
| sentDate       | bigint(20)   | NO   |     | NULL    |       |
| body           | text         | YES  |     | NULL    |       |
+—————-+—————+——+——+———+—-—+

Как видно из таблицы, все будет крутиться вокруг sentDate.
В результате появилась вот такая вот командочка:

delete from ofMessageArchive where sentDate/1000 < unix_timestamp(now())-2629743

По идее должно почистить табличку.
Погуглив по имени таблицы, нашел вот это: http://community.igniterealtime.org/docs/DOC-2199
В выходные проверю.

SIP

Товарищи / други, подскажите — какой SIP оператор сейчас актуален для звонков за кордон (Украину) и по Москве? По старинке пользуюсь sipnet.ru, может есть более лучшие предложения на рынке?

Еще мысли

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

cyrus-imap ipurge

После какого-то обновления (честно говоря не уследил какого), cyrus-imap перестал нормально отрабатывать скрипты в разделе EVENTS.

Например, у пользователей чистятся папки с карантином. Раньше работало вот так:
purgespam cmd=»ipurge -f -d 5 user.*.quarantine» at=0100
Но теперь программа стала «выборочно» очищать папки, некоторые просто игнорирует.

Есть подозрение, что изменили таймаут, по которому прекращается выполнение ipurge.
Пока не разобрался в причине, пришлось выкручиваться вот таким смешным образом:

purgespam cmd=»ipurge -f -d 5 user.a*.quarantine» at=0100
purgespam cmd=»ipurge -f -d 5 user.b*.quarantine» at=0110

и так далее, по всему алфавиту 🙂

Несколько админов в openldap, или каждому своя ветка

Как при большом количестве контейнеров в openldap разрешить конкретным пользователям работать с конкретными контейнерами?

Исходные данные:
корень зла: dc=test,dc=com
организация раз: o=org1,dc=test,dc=com
организация два: o=org2,dc=test,dc=com

Необходимо пользователю uid=admin1,o=org1,dc=test,dc=com дать возможность управлять (добавлять, удалять, редактировать) записи в org1. Пользователю uid=admin2,o=org2,dc=test,dc=com, аналогичные права на org1 и org2.

Мы не будем жестко прописывать в acl пользователей. Каждый раз менять sldap.conf или динамический cn=config при изменении администратора контейнера не очень удобно. Для разгарничения доступа будем использовать objectclass: groupOfNames. По сути своей — это группа, которую, в отличии от posixGroup, openldap умеет использовать в acl.

Создадим две группы: cn=admins1,dc=test,dc=com и cn=admins2,dc=test,dc=com. В первую будем добавлять пользователей, которые будут рулить org1, во вторую, пользователей управляющих org2. Обратите внимание на то, что эти группы в иерархии находятся на одном уровне с org1 и org2, это сделано для того, чтобы добавлять/удалять пользователей в эти группы мог только суперадмин.

Создать группы можно при помощи ldif файла, пример которого показан ниже. Или при помощи любого клиента ldap, например phpLDAPadmin
dn: cn=admins1,dc=test,dc=com
cn: admins1
member: uid=admin1,o=org1,dc=test,dc=com
member: uid=admin2,o=org2,dc=test,dc=com
objectclass: groupOfNames
objectclass: top

dn: cn=admins2,dc=test,dc=com
cn: admins2
member: uid=admin2,o=org2,dc=test,dc=com
objectclass: groupOfNames
objectclass: top

Теперь займемся sldap.conf. За основу был взят файл из пакета в OpenSuSE. От оригинала остались только первые два правила.

access to attrs=userPassword,userPKCS12
        by self write
        by * auth
access to attrs=shadowLastChange
        by self write
        by * read
#=====================================
access to dn.subtree=»o=org1,dc=test,dc=com»
        by self write
        by group.exact=»cn=admins1,dc=test,dc=com» write
        by anonymous auth
        by * read
#======================================
access to dn.subtree=»o=org2,dc=test,dc=com»
        by self write
        by group.exact=»cn=admins2,dc=test,dc=com» write
        by anonymous auth
        by * read
#=======================================
access to dn.base=»dc=test,dc=com»
        by * read
access to dn.one=»dc=test,dc=com»
        by * read
access to dn.base=»»
        by * read
access to dn.base=»cn=Subschema»
        by * read
access to *
        by * none

Рассмотрим подробнее этот файл. Как я уже говорил, первые два правила отсались от оригинала.
Правило доступа к контейнеру o=org1,dc=test,dc=com

access to dn.subtree=»o=org1,dc=test,dc=com»
        by self write
        by group.exact=»cn=admins1,dc=test,dc=com» write
        by anonymous auth
        by * read
  • dn.subtree — доступ ко всем объектам контейнера, включая все дочерние контейнеры.
  • by self write — любой пользователь должен иметь возможность изменять свои данные.
  • by group.exact=»cn=admins1,dc=test,dc=com» write — а вот собственно и группа админов, членам которой можно изменять все.
  • by anonymous auth — открываем возможность аутентификации пользователям.
  • by * read — тут вопрос спорный — выдавать информацию о записях или нет всем остальным? В принципе я бы поставил none, или более подробно расписал какие атрибуты можно или нельзя читать. В конце концов, что разрешать остальным — решать вам 🙂

Аналогично описан доступ ко второму контейнеру.

access to dn.base=»dc=test,dc=com»
        by * read
access to dn.one=»dc=test,dc=com»
        by * read
access to dn.base=»»
        by * read
Эти правила добавил для того, чтобы программы типа phpLDAPadmin могли отображать информацию о корневых контейнерах.

access to dn.base=»cn=Subschema»
        by * read
Это запись для удобства. В phpLDAPadmin можно смотреть схемы, описания атрибутов, при условии, что ldap сервер такую информацию отдаёт.

access to *
        by * none

Традиционное правило по умолчанию.

Вот пожалуй и все. В результате, если поменялся администратор контейнера не надо рестартовать сервер (в случае статической конфигурации) или возится с ldif файлами (в случае динамической конфигурации). В любом клиенте ldap заходим суперадмином и меняем членов групп admins1 и admins2.

phpLDAPadmin не работает шаблон PosixGroup

Решил обновить свои познания в openLDAP. В процессе подготовки столкнулся с небольшой проблемкой в phpLDAPadmin: если ставить по умолчанию openldap, в phpLDAPadmin перестаёт работать шаблон по созданию PosixGroup.
При первом входе в phpLDAPadmin выводятся предупреждения типа таких:
Posix Group: cn removed from template as it is not defined by an ObjectClass
И в дальнейшем шаблон добавления группы не работает 🙁

Лечится это просто, в sldap.conf необходимо заменить схему rfc2307bis.schema на nis.schema. Перезапустить ldap сервер. В интерфейсе phpLDAPadmin-на очистить кеш (там есть соответствующая ссылочка). После этого шаблон создания группы будет доступен.