При обычной установке практически любого дистрибутива Linux отсутствуют средства сборки приложений. Не положен современному линуксу компилятор. В принципе оно и понятно, есть менеджеры пакетов, есть собранные пакеты, ими и довольствуйтесь. А в прочем, никто не удивляется тому что на биржах удаленной работы, тема собрать что то под Linux, ведь мантейнеры заботятся о безопасности дистрибутива, а заказчика это мало беспокоит, ему нужны определенные функции. В общем, таким образом мы оправдали себя перед самим собой, подвели так сказать идеологическую базу оправданий и можем устанавливать компиляторы и другие средства сборки.
В CentOS:

yum install gcc gcc-c++

В Debian дистрибутивах надо сделать:

apt-get install build-essential

Теперь ваш линукс стал настоящим полигоном для экспериментов.

Оговорюсь сразу, статья относится к сборке под Linux, во FreeBSD, достаточно в диалоге настройки порта ткнуть галочку напротив iILBC и все.
Но Asterisk приходится чаще всего собирать под Linux и если при

make menuselect

Выбрать поддержку iLBC(в разделе Codec Translators), то получим такую ошибку при выполнении команды make:
Читать далее »

SAMS – веб интерфейс управления Squid. Он позволяет управлять доступом к прокси серверу с помощью редиректора. SAMS позволяет использовать как собственный редиректор так и сторонние Rejik и SquidGuard.
Эта система управления Squidом, состоит из 4-х основных компонет:
1. Вебинтерфейс который вносит изменения в базу
2. Демон который выполняет команды на перезапуск/реконфигурирование Squid
3. Редиректор, который управляет доступом к Squid(работой через него), фильтрацией урлов и тд и тп
4. Программа работы с логами сквида(sams), она занимается учетом трафика.

Программа обрабатывающая логи, должна переодически запускаться демоном samsdaemon, но у меня этого почему то не происходило. Поэтому я стал запускать его через крон, раз в минуту.
Читать далее »

Сегодня консультировал человека по восстановлению FreeBSD, после того, как он запустил fsck, примерно через 20 минут последовал звонок о том, что fsck повис при проверке диска и он не знает что делать. А на самом деле fsck проверял большой раздел storage, размер которого 2 террабайта, а что бы увидето что fsck на самом делел работает достаточно было нажать комбинацию клавиш Ctrl-T. При нажатии на эту комбинацию клавишь в консоли fsck, то он напишет отчет о своей работе, выглядит этот отчет примерно так:

load: 0.10  cmd: fsck_ufs 14817 [physrd] 0.13u 0.18s 1% 1440k
/dev/ad2s1d: phase 1: cyl group 2 of 28 (7%)

и если нажать еще раз то:

load: 0.19  cmd: fsck_ufs 14821 [physrd] 0.20u 0.09s 2% 1588k
/dev/ad2s1d: phase 1: cyl group 4 of 28 (14%)

Недавно возникла такая проблема, при работе мртг на графиках, превышении 124 мегабит в секунду, следует провал. То есть график в тех местах где трафик превышает 124 мегабита, рисует нолевой трафик. Поискав по инету, я обнаружил, что проблема заключается в том, что переполняется 32 битный счетчик.
А решение этой проблемы простое, вместо того, что бы снимать данные с интерфейса, раз в 5 минут, достаточно делать это раз в минуту. Счетчик переполнятся не будет, MRTG будет замечательно строить графики.

LinkSys WRT54GL – активно используется в сети. Я его в основном использую как бридж между Wireless сетью и обычной(на витой паре), а недавно помогал настраивать товарищу этот девайс и он у него уперто не работал как мост между сетями, только как роутер.
Я долго не мог понять в чем дело, тем более что товарищ кидал мне ссылки на форумы, где для режима бриджа используют какие то непонятные прошивки. Но когда я к нему приехал – я понял в чем дело, он шнурок подключения к сети устанавливал в гнездо Internet, а не в обычное. Это сработал стереотип – отсюда будет подаваться Internet – значит надо вставлять в гнездо интернет. Как только переключили шнур, все заработало как надо.

Exim сообщения которые он не смог отправить и уже не будет пытаться отправлять, помечает как frozen. На почтовых системах с активным почтовым трафиком таких сообщений может скопится очень много. Со временем(в зависимости от настроек) exim эти сообщения уничтожает, на скорость обработки сообщений в очереди они не влияют, так как пометка frozen исключает их из обработки.
Но зато они часто очень мешают анализировать очередь.
Что бы избавится от всех frozen сообщений в очереди можно воспользоваться такой комбинацией команд:

exiqgrep -zi | xargs exim -Mrm

и все, будут уничтожены все frozen сообщения.
Остается только напомнить, что перед удалением стоит все таки проверить, вдруг некоторые из сообщений заморозились в результате сбоя и на самом деле являются полезными.
Инициировать отправку всех сообщений из очереди (не завсимо от того frozen они или нет) можно командой:

exim -qqff

Недавно очень помогла утилита unix2tcp.
Убирали с одного из серверов MySQL, базы перенесли, все хорошо, все красиво заработало, но как выяснилось в части проектов, хостясщихся на этом сервере настройки в MySQL зарыты в исходных текстах и искать их долго, а перенести надо максимально быстро.
Поэтому из портов был установлен unix2tcp:

cd /usr/ports/net/unix2tcp/
make install clean

А использовать эту програмку очень просто, к примеру сервер MySQL находится на адресе 192.168.254.5 порт 3306, локальный unix сокет должен быть /tmp.mysql.sock, соответственно запускать его надо так:

unix2tcp /tmp/mysql.sock 192.168.254.5 3306

Собственно и все. Я не привожу стартовый скрипт для этого решения, просто потому, что никто не рассматривает это решение как долгосрочное. Но у нас оно проработало почти неделю и нареканий не вызвало.
Только помните, что теперь нужно на удаленном сервере все равно в MySQL задать нужные права на базы от IP адреса сервера с которого вы будете соединяться.