Как обновить прошивку (firmware) Grandstream HT-503
Итак,
1) на ПК под управлением OC Windows идем на сайт разработчиков HT-503 и скачиваем архив с прошивкой
2) распаковываем архив в папку, которая будет корнем на TFTP-сервере
3) скачиваем последнюю версию TFTP-сервера нужной архитектуры отсюда и устанавливаем
4) запускаем Tftpd64 (или Tftpd32 – если вы ставили 32-битную версию), нажимаем Browse и выбираем папку с файлами прошивки затем нажимаем Show Dir – для проверки, в списке Server Interface выбираем нужный (тот, который смотрит в вашу локальную сеть или в VPN – короче, тот, где находится сам HT-503).
5) идем на веб-морду настройки HT-503 и во вкладке Advanced Settings и меняем метод обновления и адрес сервера обновления на тот, который мы толькоч то настроили, также проверяем, включено ли автоматическое обновление:
Затем, чтобы думу не думать долго, если пойдет что-то не так, настраиваем внизу вкладки логирование на удаленный rsyslog:
6) перезагружаем HT-503 желательно нажав скрепкой на кнопку рестарта, которая расположена в задней части корпуса в отверстии а не выдернув шнур питания. Только не держите долго нажатой эту кнопку – после 5-7 секунд произойдет сброс к заводским настройкам.
Если всё сделано правильно, то сразу после включения HT-503 найдет файлы на TFTP-сервере и будет обновляться, при этом индикаторы на корпусе будут мигать периодически и веб-морда некоторое время будет не доступна.
Всё. Надеюсь, кому-то поможет моё описание.
Как разделить образ .cue на треки .flac в Linux
На примере Debian 7 делаем следующее.
Устанавливаем вначале необходимые пакеты:
aptitude install shntool cuetools
Далее переходим в папку с .cue и разбиваем:
shntool split -f *.cue -o flac *.flac
На выходе получим файлы с именами split-track##.flac. И можем дальше собирать наш аудио-диск.
Удобочитаемая панель предпросмотра в Roundcube Webmail
Решить проблему сию поможет плугин Threecol Layout, доступный по ссылке:
https://github.com/tofi86/Roundcube-Plugin-Threecol-Layout
Но он работает только с версиями Roundcube 0.9.x, я же ставил версию из пакетов Debian Wheezy, а там только 0.8. Пришлось скачать архив с сайта разработчиков Roundcube и установить заново (я решил устанавливать всё в папку /var/www/roundcubemail – у вас путь может быть иной). Благо, старую БД он подхватил отлично и настройки в main.inc.php мало отличаются.
Скачиваем его на сервер, распаковываем в папку с плугинами, например: /var/www/roundcubemail/plugins
Редактируем конфигурационный файл:
nano /var/www/roundcubemail/config/main.inc.php
Находим там строчки и добавляем в список после array наш плагин (и другие, которые хотите использовать):
// ———————————-
// PLUGINS
// ———————————-
// List of active plugins (in plugins/ directory)
$rcmail_config[‘plugins’] = array(‘threecol’, ‘thunderbird_labels’, ‘markasjunk2’);
Также вниз (или куда угодно) дописываем:
//threecol
$rcmail_config[‘previewpane_layout’] = ‘right’;
Перезапускаем веб-сервер и радуемся нормальному превью:
service apache2 restart
Удаление старых файлов одной командой в Linux
Например, для файлов старше 5 дней:
find /path/to/files* -mtime +5 -exec rm {} ;
Для файлов, измененных в пределах 24…48 часов:
find /path/to/files* -mtime 1 -exec rm {} ;
Это версия для Debian, на RHEL надо писать чуть по-другому:
find /path/to/files* -mtime +0 -exec rm {} ;
Создать файлы для тестирования можно командой (например, дата 2 апреля):
Nokia 5230 самопроизвольно выключается
Контакты на батарее иногда отходят (обычно после долгой эксплуатации).
В общем, вытаскиваем батарею и понимаем, что на ней есть зажимы для 3 штырьков, какие находятся на корпусе телефона. Это видно на фото.
Берем иглу или ножик с тонким кончиком и немного отгибаем зажимы так, чтобы они сильнее прижимались к штырькам на телефоне.
Усё, собираем, пользуемся.
Борьба со спамом средствами Postfix
Входные данные:
- сервер под управлением ОС Debian 7,
- Postfix 2.9.x,
- домен: example.com,
- внешний IP – 222.222.222.222,
- внутренняя сеть – 192.168.1.0/24, 192.168.2.0/24.
Считаю, что постфикс у вас уже настроен в плане авторизации, почтовых ящиков и прочего хозяйства.
Основной файл, где настраивается фильтрация спама, это main.cf
Для начала укажем адреса доверенных сетей с префиксами через “,” – для этих сетей большинство проверок работать не будут дабы не использовать лишние ресурсы:
mynetworks = 127.0.0.0/8, 192.168.1.0/24, 192.168.2.0/24
Далее следуют проверки HELO, т. к. многие спаммеры или пропускают команду SMTP HELO или посылают заведомо неверные данные.
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,
permit_sasl_authenticated,
check_helo_access hash:/etc/postfix/helo_access,
reject_non_fqdn_hostname,
reject_invalid_hostname,
permit
- разрешить доверенным сетям,
- разрешить авторизованным по sasl (если вы используете sasl)
- проверка хеш-таблицы, которая собержит черный/белый список HELO, в который вы вправе добавить заведомо доверенные или нежелательные домены/адреса, например:
some_other_spam.com REJECT SPAM!
234.234.234.234 REJECT Some spam IP
222.222.222.222 REJECT Fake!
- далее происходит фильтрация заведомо неправильных доменов вроде “MAILSERVER” или “HOST@192.168!aol.com”
- если с HELO письма всё хорошо, то оно проходит в следующую цепочку фильтрации
Также можно добавить перед permit опцию reject_unknown_hostname, но использование ее спорно – она фильтрует письма от доменов, которые не могут быть отрезольвены с помощью DNS. С одной стороны хорошо, а с другой – многие валидные системы имеют проблемы с DNS и их письма будут тоже отклонены.
smtpd_sender_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_sender_access regexp:/etc/postfix/sender_access,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
permit
- вначале как и раньше – разрешаем “нашим” доступ
- проверяем, как и в предыдущем случае, хеш-таблицу с белым/черным списком и “отфутболиваем” отправителей из неправильных и неизвестных доменов
- пропускаем тех, у кого всё Ок с отправителем
smtpd_recipient_restrictions =
reject_unauth_pipelining,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
check_recipient_access regexp:/etc/postfix/recipient_access,
check_policy_service inet:127.0.0.1:10023,
check_policy_service unix:private/policy-spf,
permit
- многие спаммеры посылают письма как можно быстрее сериями команд, не дожидаясь ответа – для фильтрации такого спама первая проверка
- далее мы фильтруем неправильные и неизвестные домены
- разрешаем “нашим”
- опция reject_unauth_destination возможно самая важная – без нее наш сервер станет т.н. open relay
- далее следует проверка по хешу блеклиста получателей – полезно добавлять туда даже локальных пользователей, если на их аккаунты сыпятся т. н. баунсы. Пример записи:
something@example.com REJECT This is not real account.
- далее идет прове
рка через внешний сервис т.н. грейлистинга – в данном случае – Postgrey. - а также проверка Sender Policy Framework (SPF) – он них ниже.
- ну и, конечно же, пропуск далее валидных писем
smtpd_client_restrictions =
permit_mynetworks,
reject_rbl_client bl.spamcop.net,
reject_rbl_client cbl.abuseat.org,
permit
Здесь мы проверяем адреса отправителя в помощью сервисов черных списков. Дескредитированные IP-адреса, от которых идет спам, заносятся в эти списки. Перед использованием в своем конфиге нужно проверить, работают ли сервисы – иначе будет большая задержка приходящих писем.
Для использования Spamassassin и Amavis необходимо так же добавить строчку:
content_filter = amavis:[127.0.0.1]:10024
Но настройка этих демонов – это тема для отдельной статьи.
Теперь поподробнее о SPF и Greylisting
SPF позволяет владельцу домена указать в TXT-записи, соответствующей имени домена, специальным образом сформированную строку, указывающую список серверов, имеющих право отправлять email-сообщения с обратными адресами в этом домене.
Агенты передачи почты, получающие почтовые сообщения, могут запрашивать SPF-информацию с помощью простого DNS-запроса, верифицируя таким образом сервер отправителя.
Пример SPF-данных в TXT-записи DNS:
v= определяет используемую версию SPF. Далее следует перечисление механизмов верификации: в данном случае «a» разрешает прием писем от узла, IP-адрес которого совпадает с IP-адресом в A-записи для example.org; «mx» разрешает прием писем, если отправляющий узел указан в одной из MX-записей для example.org. Строка завершается «-all» — указанием того, что сообщения, не прошедшие верификацию с использованием перечисленных механизмов, следует отвергать. Также может использоваться «~all» – в этом случае письмо, не прошедшее верификацию, не должно быть отклонено, но может быть изучено более тщательно (SoftFail).
Этой записи вполне может и не быть, но всё же.
Greylisting — способ автоматической блокировки спама, основанный на том, что «поведение» программного обеспечения, предназначенного для рассылки спама, отличается от поведения обычных серверов электронной почты. Еслипочтовый сервер получателя отказывается принять письмо и сообщает о «временной ошибке», сервер отправителя обязан позже повторить попытку. Спамерское программное обеспечение в таких случаях, обычно, не пытается этого делать.
check_policy_service inet:127.0.0.1:10023, check_policy_service unix:private/policy-spf,
в цепочку smtpd_recipient_restrictions (НО после reject_unauth_destination). Также необходимо добавить в этот файл (лучше в конец) опцию:
policy-spf_time_limit = 3600s
Перезапускаем службы и смотрим в логи, как работает наша обновка.
Создать SPF-запись для своего домена можно с помощью мастера здесь:
http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/default.aspx
Полезные ссылки:
http://www.postfix.org/postconf.5.html
http://www.freesoftwaremagazine.com/articles/focus_spam_postfix
https://help.ubuntu.com/community/Postfix/SPF
Asterisk и NAT
Есть несколько сценариев работы * с НАТом в зависимости от того, находится сервер и/или клиенты за НАТом. НО. В каждом конкретном случае приходится “шаманить”, т. к. стандартные рецепты не всегда помогают.
У меня был самый тяжелый случай – и сервер Asterisk и клиенты находятся за НАТами… разными НАТами.
Вариантов тут может быть два:
– настроить всю кухню так, что телефоны будут подклучаться к * через свой НАТ, интернет и НАТ сети с * (т. е. путь будет такой: телефон –> НАТ –> интернет –> НАТ –> астериск);
– установить второй сервер * внутри сети, где телефоны и связать 2 сервера * IAX транком – именно IAX, т. к. он более приспособлен для работы через НАТ (путь будет: телефон –> астериск2 –> IAX-транк –> астериск1).
Но, т. .к. настоящие герои всегда идут в обход (с), я решил делать вариант номер 1.
Итакс, начнемс.
1) Конфигурирование сервера с *
SIP телефоны были аппаратными, потому никаких особо вычурных конфигураций в sip.conf придумывать не надо было.
Обязательно надо добавлять опцию qualify = yes, чтобы поддерживать открытым порты на роутерах и чтобы сам * знал, что атм происходит с пиром (иначе возможна ситуация, когда звонки вроде идут, но не доходят или нет звука).
Вот пример конфига для телефонов Cisco SPA XXX:
[general]
…
pedantic = no
nat = no
…
[authentication]
deny = 0.0.0.0/0.0.0.0
permit = X.X.X.0/255.255.255.255
permit = Y.Y.Y.0/255.255.255.0
[c395]
disallow = all
allow = all
qualify = yes
type = friend
host=dynamic
call-limit=3
busylevel=1
rtpkeepalive = 15
nat=route
fromdomain=example.com
context=something
deny=0.0.0.0/0.0.0.0
permit=X.X.X.0/255.255.255.0
permit=Y.Y.Y.0/255.255.255.0
secret=*****
mailbox=395@default
3) Конфигурирование фаерволла, за которым спрятан *
Тут уже несколько интересней. Зависит от фаерволла. Если есть настройки типа SIP Passthrough, то включаем, так же делаем порт-форвардинг SIP порта на сервер с * (UDP 5060 по-умолч, но лучше поменять).
Если таких настроек нет или они не дают результата, то – по матчасти – нужно открыть порты для SIP (UDP 5060 по умолч), а также для голосового траффика RTP (по умолч – UDP 10000-20000, изменяется в rtp.conf) и дописать в sip.conf:
[general]
…
externip = X.X.X.X
localnet = Y.Y.Y.0/24
port = [ext_port]
…
4) Конфигурирование телефонов.
Конфигурирование, конечно же различается от телефона к телефону, но в общем – нужно включать поддержку NAT на тех телефонах, которые спрятаны за NAT. Если таковая поддержка есть в опциях, конечно.
Для Cisco SPA необходимо зайти на веб-морду для конфигурации (http://x.x.x.x/admin/advanced) затем в секции Line включить NAT как на рисунке:
а также, адрес прокси-сервера (т. е. адрес нашего *) указывать с учетом внешнего порта, какой форвардиться на * (х.х.х.х:ext_port).
Проверить всё это дело можно (после перезапуска астериска желательно всего, а не только модуля sip) набрав в командной строке Asterisk’а (asterisk -r):
asterisk*CLI> sip show peers
Name/username Host Dyn Nat ACL Port Status
***
c395/c395 x.x.x.x D N A 24513 OK (134 ms)
***
Т. е., команда выдает список пиров для протокола SIP и их состояние: Имя, IP-адрес (внешний, если пир за NAT), диманический он или статический в настройках sip.conf, далее используется пиром NAT или нет, контроль доступа есть/нет, порт пира (в случае с NAT – какой роутер форвардит для телефона) и собсно статус и время задержки.
Если телефоны за NAT не работают и в лог Asterisk’a сыплет записи вроде такой:
NOTICE[19903] chan_sip.c: Correct auth, but based on stale nonce received from ‘”с395″ <sip:с395@X.X.X.X>;tag=…………………’
То скорее всего поможет назначение телефону другого внутреннего IP – в таблице маршрутизации роутеров остаются “хвосты”.
Полезные ссылки:
1) http://www.asteriskguru.com/tutorials/sip_nat_oneway_or_no_audio_asterisk.html
2) http://www.voip-info.org/wiki/view/Asterisk+SIP+NAT+solutions
Монтирование разделов Windows в Linux без root или sudo
Создаем папки, куда будем монтировать. Например в хомяке пользователя, с правами ему.
mkdir /home/user/C
mkdir /home/user/D
chown user:user /home/user/C
chown user:user/home/user/D
Далее дописываем в файл:
nano /etc/fstab
/dev/sda2 /home/user/C ntfs-3g defaults 0 0
/dev/sda5 /home/user/D ntfs-3g defaults 0 0
Google Chrome исчезает из меню в Debian
Решение простое – скопируем ярлыки в нужное место:
cp /opt/google/chrome/google-chrome.desktop /usr/share/applications/