FreeSWITCH: работа с очередями

2 основных модуля: mod_fifo и mod_callcenter

proxmox: HA, fencing

Fencing is vital for Proxmox to manage a node loss and thus provide effective HA. Fencing is the mechanism used to prevent data incoherences between nodes in a cluster by ensuring that a node reported as "dead" is really down. If it is not, a reboot or power-off signal is sent to force it to go to a safe state and prevent multiple instances of the same virtual machine run concurrently on different nodes.

http://stormbp.blogspot.ru/2012/05/proxmox-ve-2-cluster-with-drbd.html
http://ru-sysadmins.livejournal.com/2222322.html
http://pve.proxmox.com/wiki/Two-Node_High_Availability_Cluster

iptables+bridge

Например, есть сервер с виртуализацией (может быть просто 2 сетевых интерфейса), где сетевые карты виртуалок сидят в бридже с основным интерфейсом, например vmbr0 с eth0 и veth100.0
Если просто вешать правила на хост-ноде, даже при policy DROP хост-нода станет недоступна, но виртуалки будут спокойно ходить через бридж. Это потому, что бридж это L2, и тут нужен ebtables и это будет примерно так
ebtables -A FORWARD -p ip --ip-source 192.168.253.1 --ip-destination 192.168.253.2 -j DROP

Если же нет нужных модулей под ebtables или хочется/нужен iptables, нам в помощь приходит
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
(через sysctl)

А с учётом интерфейса -- нужен physdev

Линки
http://toster.ru/q/29447
http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html
http://www.cyberciti.biz/faq/debian-network-interfaces-bridge-eth0-eth1-eth2/

FreeSWITCH: ставим в centos 6

Что это вообще? Это цифровая АТС, sip-сервер, как asterisk, не такой популярный но в ряде вещей более гибкий. А ещё он более производительный:
Битва титанов FreeSwitch vs. Asterisk — Тест производительности

Установка есть 2 методами: сборка из исходников и подключение репы.

http://wiki.freeswitch.org/wiki/Download_%26_Installation_Guide
Проще и правильнее из пакетов.

src:
http://wiki.freeswitch.org/wiki/Download_%26_Installation_Guide#Source_Options#Source_Options
http://wiki.freeswitch.org/wiki/Linux_Quick_Install_Guide

yum:
rpm -Uvh http://files.freeswitch.org/freeswitch-release-1-0.noarch.rpm

http://wiki.freeswitch.org/wiki/Download_%26_Installation_Guide#YUM_Based_Installation

http://files.freeswitch.org/yum/6/i386/
https://plone.lucidsolutions.co.nz/linux/freeswitch/install-freeswitch-on-a-centos-v6-vm

FreeSWITCH: не запускается

Может быть такое, что сделали service freeswitch restart -- и больше ничего не работает, в логах пусто даже несмотря на то, что включен mod_logfile и mod_syslog. И странно, что нет опции configtest.
Проверить конфиг можно так:

# freeswitch -nf -c -u freeswitch
2014-05-26 19:30:06.166869 [INFO] switch_event.c:649 Activate Eventing Engine.
2014-05-26 19:30:06.177138 [WARNING] switch_event.c:623 Create additional event dispatch thread 0
2014-05-26 19:30:06.199407 [ERR] switch_xml.c:1385 Couldnt open /etc/freeswitch/lang/de/*.xml (No such file or directory)
2014-05-26 19:30:06.204145 [ERR] switch_xml.c:1385 Couldnt open /etc/freeswitch/lang/fr/*.xml (No such file or directory)
2014-05-26 19:30:06.204169 [ERR] switch_xml.c:1385 Couldnt open /etc/freeswitch/lang/ru/*.xml (No such file or directory)
2014-05-26 19:30:06.204187 [ERR] switch_xml.c:1385 Couldnt open /etc/freeswitch/lang/he/*.xml (No such file or directory)
2014-05-26 19:30:06.204203 [ERR] switch_xml.c:1385 Couldnt open /etc/freeswitch/lang/es/es_ES.xml (No such file or directory)
2014-05-26 19:30:06.204224 [ERR] switch_xml.c:1385 Couldnt open /etc/freeswitch/lang/pt/pt_BR.xml (No such file or directory)
Cannot Initialize [[error near line 4424]: unclosed <!--]
#

То, что нет языковых каталогов хоть и ERR, но запуску не мешает, а вот незакрытый комментарий это серьёзно. Настолько, что даже в лог ничего не написать...

А что за странная строка 4424? Ответ искать в /var/log/freeswitch/freeswitch.xml.fsxml - сюда объединяются все конфиги. Править его бесполезно, но найти конкретное место и уже его искать в оригинальных конфигах можно.
Такой бы файлик еще для nginx-а...

Да, если что -- выход ... (три точки)

HP ProCurve и cisco + multicast

У многих управляемых свичей есть весьма неприятный баг: по умолчанию не работает multicast, ибо выключено, поэтому могут не работать всякие proxmox (corosync для работы требует мультикаст). Например, HP 2510-24
ftp://ftp.hp.com/pub/networking/software/2510-AdvTrafficMgmt-Aug2006-59914762.pdf
Проверяем
show ip igmp
show ip igmp config
и видим везде off. Включается на каждый влан отдельно.
vlan 1 ip igmp

cisco:
https://github.com/corosync/corosync/wiki/Corosync-and-Cisco-switches

switch# config t
switch(config)# ip multicast-routing
switch(config)# int vlan1
switch(config-if)# ip pim sparse-dense-mode
switch(config-if)# ^Z
switch# wr

вариант 2
# conf t
# no ip igmp snooping
http://pve.proxmox.com/wiki/Multicast_notes

proxmox: обнуление (удаление) кластера

http://undefinederror.org/how-to-reset-cluster-configuration-in-proxmox-2/

proxmox: Waiting for quorum... Timed-out waiting for cluster

При попытке запустить кластер может быть ошибка (при service cman restart)
Starting cluster:
   Checking if cluster has been disabled at boot... [  OK  ]
   Checking Network Manager... [  OK  ]
   Global setup... [  OK  ]
   Loading kernel modules... [  OK  ]
   Mounting configfs... [  OK  ]
   Starting cman... [  OK  ]
   Waiting for quorum... Timed-out waiting for cluster
[FAILED]

Что может быть не так:

1) проверить /etc/hosts, что адреса и хосты совпадают

2) имя кластера не равно имени одной из нод

3) стоит свич, который фильтрует мультикаст (если свич управляемый и/или их больше 1 -- шанс такого случая большой)

4) проверить, что /etc/cluster/cluster.conf совпадают на нодах

5) фаервол выключен или правильно настроен

6) нет проблем с маршрутизацией

В 3 случае может помочь перевод на юникаст

cluster.conf:
<cman transport="udpu" keyfile="/var/lib/pve-cluster/corosync.authkey">

Но это имеет смысл только когда нод 2-3, так как сильно растет нагрузка на сеть.

Можно также попробовать выставить <quorumd> там же.
Проверить мулькаст-пинги можно через omping, ssmping

Также имеет смысл ознакомиться с
http://pve.proxmox.com/wiki/Multicast_notes

линки

http://188.165.151.221/threads/8140-waiting-for-quorum-cluster-setup-problem

http://forum.proxmox.com/threads/14762-quorum-timeout-adding-node-to-cluster-unicast
http://forum.proxmox.com/threads/7673-making-new-cluster-Waiting-for-quorum-Timed-out-waiting-for-cluster

proxmox + ploop

The plan is to add ploop support when we switch to 3.10 kernel (when openvz team release a 3.10 kernel).

http://comments.gmane.org/gmane.linux.pve.devel/7130

http://forum.proxmox.com/threads/11983-OpenVZ-Ploop-support

What's the difference between utf8_general_ci and utf8_unicode_ci

http://stackoverflow.com/questions/766809/whats-the-difference-between-utf8-general-ci-and-utf8-unicode-ci/766996#766996

There are at least two important differences:

• Accuracy of sorting
  utf8_unicode_ci is based on the Unicode standard for sorting, and sorts accurately in a very wide range of languages.
  utf8_general_ci comes very close to correct Unicode sorting in many common languages, but has a number of inaccuracies in some languages making in unsuitable for correct sorting in those languages.
• Performance
  utf8_general_ci is faster at comparisons and sorting, because it takes a bunch of performance-related shortcuts.
  utf8_unicode_ci uses a much more complex comparison algorithm which aims for correct sorting according in a very wide range of languages. This makes it slower to sort and compare large numbers of fields.

Unicode defines complex sets of rules for how characters should be sorted. These rules need to take into account language-specific conventions; not everybody sorts their characters in what we would call 'alphabetical order'.

• As far as Latin (ie "European") languages go, there is not much difference between the Unicode sorting and the simplified utf8_general_ci sorting in MySQL, but there are still a few differences:
  For examples, the Unicode collation sorts "ß" like "ss", and "Œ" like "OE" as people using those characters would normally want, whereas utf8_general_ci sorts them as single characters (presumably like "s" and "e" respectively).
• In non-latin languages, such as Asian languages or languages with different alphabets, there may be a lot more differences between Unicode sorting and the simplified utf8_general_ci sorting. The suitability of utf8_general_ci will depend heavily on the language used. For some languages, it'll be quite inadequate.

Some Unicode characters are defined as ignorable, which means they shouldn't count toward the sort order and the comparison should move on to the next character instead. utf8_unicode_ci handles these properly.
What should you use?
There is almost never any reason to use utf_general_ci anymore, as we have left behind the point where CPU speed is low enough that the performance difference would be important. Your database will almost certainly be limited by quite other bottlenecks than this nowadays. The difference in performance is only going to be measurable in extremely specialised situations, and if that's you, you'd already know about it. If you're experiencing slow sorting, in almost all cases it'll be an issue with your indexes/query plan. Changing your collation function should not be high on the list of things to troubleshoot.
When I originally wrote this answer (over 4 years ago) I said that if you wanted, you could use utf8_general_ci most of the time, and only use utf8_unicode_ci when sorting was going to be important enough to justify the performance cost. However, the performance cost is no longer really relevant (and it may not have been back then, either). It's more important to sort properly in whichever language your users are using.
One other thing I'll add is that even if you know your application only supports the English language, it may still need to deal with people's names, which can often contain characters used in other languages in which it is just as important to sort correctly. Using the Unicode rules for everything helps add peace of mind that the very smart Unicode people have worked very hard to make sorting work properly.

FreeBSD: "/usr/ports/Mk/bsd.port.mk", line 1767: Malformed conditional (defined(USE_RC_SUBR) && ${USE_RC_SUBR:tu} != "YES")

После 5 мая многие могли в очередной раз столкнуться с багами портов, а именно:
# make
Unknown modifier 't'

"/usr/ports/Mk/bsd.port.mk", line 1767: Malformed conditional (defined(USE_RC_SUBR) && ${USE_RC_SUBR:tu} != "YES")
Unknown modifier 't'

Unknown modifier 't'

Unknown modifier 't'

"/usr/ports/Mk/bsd.sites.mk", line 957: Malformed conditional (!empty(_PERL_CPAN_ID) && ${_PERL_CPAN_FLAG:tl} == "cpan")
Unknown modifier 't'

"/usr/ports/Mk/bsd.port.mk", line 2929: Unclosed conditional/for loop
"/usr/ports/Mk/bsd.port.mk", line 2929: Unexpected end of file in for loop.

"/usr/ports/Mk/bsd.port.mk", line 6708: Unclosed conditional/for loop
"/usr/ports/Mk/bsd.port.mk", line 6708: Unexpected end of file in for loop.

make: fatal errors encountered -- cannot continue

Из какого пакета файл?

http://linsovet.org.ua/package-file-search

И ещё про rpm
Советы по работе с Yum и RPM
Изучаем Linux, 101: Управление пакетами с помощью RPM и YUM

FreeBSD+pkgng:
# pkg which /usr/local/bin/lua52
/usr/local/bin/lua52 was installed by package lua52-5.2.3_2

SFP: подключаем не фирменные SFP к брендированному оборудованию

Если сравнить цены на фирменные и "чужие" SFP -- разница может быть в 10 раз. Например, WDM одномод 3км - у HP цена вопроса около 20 тысяч, SNR - около тысячи, а opticin sfp-wdm3.03 -- вообще 500р.

Иногда достаточно команд (cisco)
service unsupported-transceiver
no errdisable detect cause gbic-invalid

Но иногда нужно шить модули, для этого нужен специальный SFP программатор, типа
http://shop.nag.ru/catalog/00007.Avtomatizatsiya-i-monitoring/13766.Drugoe/08255.Prog-miniUSB
+ прошивки поддерживаемых SFP, чтобы их вшить.

И полезный линк в тему
http://forum.nag.ru/forum/index.php?showtopic=43748

Заметки на полях: Intel vPro совсем не "PRO"

Заметки на полях: Intel vPro совсем не "PRO": Intel vPro aka AMT давно уже не "PRO". Оказывается ушлые интеловцы выпилили поддержку тэгированных вланов на интерфейсах AMT...



Интел уже много лет "энтерпрайз" в худшем смысле, увы. Именно поэтому я уважаю АМД, у них отставание примерно на поколение, но изначально дешевле, плюс даже в бытовом сегменте есть много "серверных" плюшек типа ЕСС (во всяком случае, еще пару лет назад было)