Являясь сетевым администратором, повседневно работаю с BGP. Стоит отметить, что BGP-соединения всегда можно разделить на соединения с апстримами, с клиентами и пиринговые (т.е. паритетные). При настройке паритетных соединений и соединений с клиентами, желательно накладывать prefix-list на принимаемые анонсы. Для автоматизации постройки prefix-list согласно as-set, уже довольно давно пользуюсь утилитой bgpq. Утилита автоматически строит префикс-листы, беря за исходные данные номер автономной системы или as-set. Утилита становится незаменимой довольно быстро.

Для начала, выполним установку утилиты из системы портов:

Подбирая кабель необходимого сечения, обратил внимание, что часть кабелей имеет маркировку AWG без указания сечения кабеля. Поскольку при выборе кабеля отталкиваемся от планируемой мощности нагрузки, подбирая необходимое сечение кабеля, желательно иметь под рукой таблицу перевода и понимать, что  откуда и почему.

Случается, что какой-то процесс время от времени вылетает, что не есть хорошо. И выяснить причину падений не всегда удается. Как вариант - установка мониторинговой системы (Monit, Zabbix, Nagios, etc). Однако не всегда в этом есть смысл, особенно когда это сервер небольшого офиса. В этом случае работу сервиса проще проверять простеньким скриптом, который проверяет, запущен ли процесс, а если нет - дает команду на запуск сервиса.

После очередного обновления софта, обнаружил, что некоторые из скриптов, написанных на Perl, сыпят  в /var/log/httpd-error.log сообщения о ошибках. Пример сообщений:

Понадобилось однажды ресурсы сети А транслировать как локальные ресурсы сети В. Поскольку прямого взаимодействия этих сетей нету, обьединение сетей выполним посредством построения VPN-тунеля, благо что в роли маршрутизаторов обеих сетей выступают сервера под управлением FreeBSD. Поскольку в сети А уже функционировал полноценный VPN-сервер на базе MPD, то не будем изобретать велосипед, а просто настроим подключение с маршрутизатора сети В в качестве VPN-клиента к VPN-серверу, находящегося в сети А.

Логика взаимодействия сетей А и В до построения VPN-тунеля

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

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

1. Останавливаем MySQL-сервер:

По умолчанию Drupal для публикаций типа "Заметка" отображает информацию о публикации по типу "Опубликовано muff в 19:21 28.01.2013". Отключить отображение информации о сообщении можно в настройках тем оформления: Управление -> Конструкция сайта -> Темы оформления -> Настройки -> Глобальные настройки.

Однако довольно часто необходимо, чтобы отображалось время публикации сообщения, а имя пользователя скрыть. Подкоректировать отображение информации о публикации можно "ручками", внеся изменения в файл modules/node/node.module.

Ищем в этом файле следующий блок:

При настройке OSPF на Cisco Catalyst 3550 планировалось редистрибутить статические маршруты и подключенные (connected) сети. Однако, при конфигурировании OSPF-роутера после ввода команды redistribute connected в ответ маршрутизатор выдал предупреждение - Only classful networks will be redistributed.

Настраивал OSPF между Cisco Catalyst 3550 и сервером с установленным пакетом Quagga. При конфигурировании возникла следующая проблема. Маршрутизаторы установили между собой соседство, однако обмен маршрутами не выполнялся -каждый роутер в своей базе данных OSPF имел только собственные маршруты. В логах Cisco Catalyst 3550 можно было обнаружить такие ошибки:

Переносил exim с одного физического сервера на другой... Старый сервер продолжал функционировать. Перенес конфигурационные файлы на новый сервер и проверил работоспособность exim - доставку писем локальным и удаленным пользователям.

После тестирования перенес почту и настройки веб-интерфейса пользователей. После этого отключил старый сервер и запустил новый, подставив IP-адреса старого сервера. Однако где-то я ошибся, поскольку почта перестала доставляться на удаленные сервера, а локальная доставка работала корректно. При этом в логах можно было наблюдать такую ошибку: