Статью по защите от брутофорса(подбора пароля) с помощью bruteblockerа я уже писал. И вот недавно я настраивал sshit. Это тоже блокировщик брутефорса, он работает по тем же принципам, что и большинство подобных систем. Достоинство sshit заключается в том, что он работает с IPFW, IPFW2 и pf. То есть получается более универсальная система. В моем случае настрока проводилась под IPFW2 и под pf. У клиента несколько серверов с разными файерволами. Как говорится, так исторически сложилось.
Читать далее »

Subversion система контроля версий. На сегодняшний день она практически вытеснила cvs, по крайней мере за последние полгода настраивать cvs мне не приходилось. Subversion так же называют svn. Поскольку последнее время мне все чаще приходится ставить nginx без apache, то и в этом случае svn мы будем ставить без всяких апачей.

cd /usr/ports/devel/subversion
make install clean

Читать далее »

Одним из самых тонких мест серверов являются диски. Для многих апаратных рейд контролеров есть утилиты мониторинга. Есть такая утилита и для GEOM. Относительно недавно она появилась в портах FreeBSD. Она предназначена для проверки состояния компонентов GEOM и в случае отказа или потери каких либо компонент – уведомления сисадмина по электронной почте.
Ставим geomWatch из портов:

cd /usr/ports/sysutils/geomWatch/
make install clean

Читать далее »

Сразу скажу, что установка диверсионная, то есть не из портов. В порту nginx присутствует опция для установки модуля passenger, но я, честно говоря не смог разобраться с ним. Все собралось, все вроде хорошо, но абсолютно не понятно где находится passenger_root и т.п. Порт самого passengera заточен под Apache, в общем не приемлимо. По крайней мере я не сторонник ставить левый софт, просто потому что не люблю держать софт который не будет использоваться, а потом вернувшись через длительный промежуток времени к этому серверу в случае аварии, я буду вспоминать зачем тут стоит апачь и что вообще тут должно крутится. Поэтому, я пошел по пути, установки софта из gems.
Читать далее »

По мере роста мелких площадок(расчитаные на 5-8 клиентов) возникает вопрос, как красиво забекапить конфигурацию так, что бы максимально упростить поиск требуемой конфигурации и восстановления работы свитча максимально быстро. С Эджкорами работать сложно еще и потому, что копирование на tftp у них происходит не так, как во «взрослых» свитчах, а в интерактивном режиме. То есть сначала мы отдаем команду на копирование, потом в появившемся приглашении вводим адрес сервера, а потом уже вводим имя файла. Это все конечно неудобно, но вполне решаемо.
Скрипт бекапа я решил писать на Ruby. У него довольно обширная, хотя и кривоватая стандартная библиотека и туда входит модуль telnet. Кривоватость модуля telnet связана с тем, что он намертво желает авторизоваться только при появлении приглашения Login, а EdgeCore(Так же как и Cisco кстати) выводит приглашение Username:
Читать далее »

Недавно наступил на еще одну неприятность с EdgeCore ES3510, при смене ip адреса на управляющем влане, EdgeCore потерял адрес. Причем потерял напрочь. Управляющий влан не менял, просто на текущем влане сменил ip. При этом из running-config полностью пропал адрес. Пришлось не сохраняя бутать свитч. Адрес появился, и со второго раза удалась смена адреса. Повезло в том, что я перед сохранением проверил running-config. На этот глюк я натыкаюсь примерно пятый раз и первые 2 раза пришлось посылать супортера с ноутбуком к свитчу.
Но вообще эти свитчи отличаются достаточной стойкостью в работе. если его не трогать и не требовать многого, они работают стабильно и надежно. А при операции по смене адресов лучше не выполнять.

Не так давно, один из моих товарищей обновлял сервер под FreeBSD 7.2 до 8-ки.
Система досталась от когото, кто когда то, как то обслуживал эту фирму. Так часто бывает. Пересмотр настроек, перед пересборкой показал, что конфиг ядра немного неадекватен. Конфиг делали из GENERIC, ну в общем как и все делают, но в нем остались целые залежи ненужных устройств.
Товарищ обновил исходники csupом, и дальше, после правки конфига ядра пошел обновляться. Сборка ядра обломилась на попытке собрать в ядре некий драйвер сказевого диска. Пересмотрев конфиг, товарищь не нашел никаких упоминаний о скази устройствах. В прежнем ядре они зачем то были, хотя в сервере скази устройств и близко не было.
Товарищ почистил сборку, make clean в /usr/src, затем опять начал собирать ядро. Сборка опять вылетела на том же месте. Товарищ пересмотрел все настройки и опять почистил сборку. Все повторилось.
В общем так он и воевал с FreeBSD, пока не почистил вручную /usr/obj/, то есть сделал rm -rf /usr/obj/usr. Это убило остатки сборки от 7.2, остатки сборки драйверов структура которых в 8.0 поменялась и сборка 8.0 не могла их корректно почистить.
После ручного удаления, сборка пошла без ошибок.

Все больше офисов в своей работе ориентированны на интернет. Пусть даже офис небольшой, но все равно нужен доступ к электронной почте, к VoIP и т.д. и т.п. Организовать второе подключение к другому провайдеру не сложно, но возникает вопрос, как реализовать работу, так что бы переключение происходило с минимальными действиями со строны админа. Для реализации резервного канала нам понадобится сервер с 3-мя сетевыми картами.
Назначение у этих сетевых карт такое:
fxp0 – первая сетевая карта – к ней подключается офис(является шлюзом для локальной сети) – адрес 192.168.1.1/24
fxp1 – первое подключение – основной внешний канал – адрес 192.168.5.2/30 – шлюз 192.168.5.1
fxp2 – второе подключение – резервный внешний канал – адрес 192.168.6.2/30 – шлюз 192.168.6.1
Читать далее »