Разбираясь с RAID-контроллерами 3ware, обнаружил еще одну утилиту - 3DM, которая реализует возможности утилиты tw_cli через web-интерфейс.

Утилита 3DM присутствует в портах. Выполним установку:

По завершению установки, порт вывел короткое руководство по настройке:

Когда-то уже делал перепост статьи о том, как пересобрать развалившийся массив на RAID-контроллерах 3ware.

Пересетапил сервер, на котором есть данный контроллер и решил сразу же установить утилиту для мониторинга работы контроллера. Однако при установке утилиты возникли проблемы с установкой. 

Идем в порты и пытаемся выполнить установку утилиты tw_cli:

Не тут то было... Архив утилиты (версия 10.2.1_9.5.4) не нашелся на серверах: 

На днях обратился знакомый с просьбой о помощи. Часть ресурсов его сети стала недоступна.

После диагностики обнаружил, что проблема заключается в отсутсвии "защиты от дурака" в настройках BGP. В сети знакомого используются сети из блока 192.168.0.0/16 с маской /24, а провайдер по BGP начал анонсировать эти же сети с маской /26. Соответственно, таблица маршрутизации перестроилась и трафик, вместо того, чтобы "бежать" к ресурсам локальной сети, направлялся к провайдеру. Как говорится, "офигел молча", но нужно что-то решать.

Возмущаться и разбираться с сапортом провайдера - дело долгое. Поэтому решаем вопрос на стороне сети знакомого.

Попытался установить FreeBSD 10 на жесткий диск, который перед этим был одним из дисков зеркала, организованного с помощью аппаратного RAID-контроллера. Во время установки, при разметке дисков, получил такую ошибку:

+------Error--------+
| Operation not     |
| permitted. geom   |
| 'ada0'            |
+-------------------+

Ошибка связана с разметкой диска, которая осталась после работы в зеркале (зеркало не разбиралось, просто демонтировались диски).

Одним из способов решения даной проблемы - воспользоваться штатной утилитой dd. Для этого необходимо прервать установку и перейти в режим "Live CD".

Один из посетителей блога задал вопрос о возможности отправки файла на e-mail, используя штатную утилиту mail. Однако штатная утилита mail не умеет работать с аттачами, так уж исторически сложилось...

Не будем расстраиваться преждевременно и попытаемся найти выход из сложившейся ситуации.

Скорее всего, отправка будет использоваться в shell-скриптах, поэтому варианты использования скриптов на php, perl, и т.д. - не рассматриваем.

Один из простых и действенных вариантов - использование конвертора uuencode с дальнейшим перенаправлением результата в утилиту mail:

На одном из серверов после перехода на использование pkgng как-то отловил такую ошибку:

Решил это дело просто так не оставлять... Согласно информации на wiki.freebsd.org, в этом случае необходимо выполнить следующие шаги.

Так уж случилось, что на одном из серверов порт net-snmp никак не хотел собираться, ругаясь на ошибки компиляции. Тратить время, разбираться и устранять причину не очень хотелось, поэтому решил воспользоваться возможностями штатного агента SNMP - bsnmpd.

bsnmpd (сокращено от Begemot SNMPD) - это минимальный агент SNMP, предусматривающий возможность расширения с помощью внешних модулей.

Файл конфигурации - /etc/snmpd.config, который довольно хорошо прокомментирован. После правки "под себя", получился следующий конфиг (комментарии удалены):

"Ковыряясь" с DD-WRT, от использования DD-WRT в качестве PPTP-клиента отказался в связи с непонятными рендомными обрывами связи. Решил потестировать, как поведет себя маршрутизатор в роли PPTP-сервера.

Настройка DD-WRT - на скриншоте:

Понадобилось как-то обьеденить локальные сети двух небольших офисов. При этом, необходимо было, чтобы каждая сеть использовала свой канал в сеть интернет, а вот трафик для локальных сетей шел через VPN-тунель между офисами. Это возможно, если IP-адресация офисов отличается. В моем случае IP-адресация в офисе №1 была 192.168.0.0/24, а в офисе №2 - 192.168.1.0/24.

В офисе №1 в роли маршрутизатора был сервер с установленной FreeBSD и настроенным по этой статье PPTP VPN-сервером на базе MPD5. К тому же, в этой точке был статический маршрутизируемый IP-адрес. В офисе №2 в качестве маршрутизатора был задействован TP-LINK TL-WR741ND.  Соответственно, решил отталкиваться от существующей аппаратной части, чтобы минимизировать финансовые затраты.

Понадобилось как-то организовать защищенный обмен сообщениями между пользователями небольшого офиса и работающими удаленно сотрудниками. В качестве Jabber-сервера на этот раз решено использовать ejabberd (статья по настройке Jabber-сервера Openfire).

Стоит отметить тот факт, что ejabberd является лидером среди Jabber-серверов. Его используют Facebook, Vkontakte, Yandex, Google, etc.

Ключевыми особеностями ejabberd являются: