Эскорт-услуги в Москве от Queens Palace

Архив рубрики ‘ Без рубрики

Защищаем Proftpd посредством SSL

Proftpd является одним из наиболее популярных FTP сереврров в UNIX-мире. Протокол передачи FTP очень удобен для работы с файлами на сервере, хотя некоторые датацентры не рекомендуют использовать его из соображений безопасности. Тем не менее выходом из положения может стать включение шифрования. Посмотрим как это сделать на примере свежей версии ProFTPD Version 1.3.5.
Достаточно просто собрать proftpd из портов или поставить пакет, поскольку модуль TLS вкомпилирован в сервер по умолчанию (начиная с версии 1.3.4). Далее создадим ключи:

#mkdir -p /usr/local/etc/proftpd/ssl
#openssl req -new -x509 -days 1800 -nodes -out /usr/local/etc/proftpd/ssl/proftpd.cert.pem -keyout /usr/local/etc/proftpd/ssl/proftpd.key.pem

В диалоге вводим код страны, адрес и email.

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

LoadModule mod_tls.c

TLSEngine on
TLSLog /var/log/proftpd/tls.log
TLSProtocol SSLv23
TLSOptions NoCertRequest AllowClientRenegotiations NoSessionReuseRequired
TLSRSACertificateFile /usr/local/etc/proftpd/ssl/proftpd.cert.pem
TLSRSACertificateKeyFile /usr/local/etc/proftpd/ssl/proftpd.key.pem
TLSVerifyClient off
TLSRequired on

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

Этот хитрый gmirror

Интересной особенностью немецко-фашистского датацентра HETZNER является добровольно-принудительное навязывание использования на выделенных серверах бюджетного класса под управлением нашей настоящей системы — софтовой реализации зеркального RAID — gmirror. Поскольку качество жестких дисков оставляет желать лучшего, зачастую ставят на новый сервер диски в ошибками SMART, то и на рабочих серверах ошибки SMART не новость.

SMART Error Log Version: 1
ATA Error Count: 3
    CR = Command Register [HEX]
    FR = Features Register [HEX]
    SC = Sector Count Register [HEX]
    SN = Sector Number Register [HEX]
    CL = Cylinder Low Register [HEX]
    CH = Cylinder High Register [HEX]
    DH = Device/Head Register [HEX]
    DC = Device Command Register [HEX]
    ER = Error register [HEX]
    ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 3 occurred at disk power-on lifetime: 1576 hours (65 days + 16 hours)
  When the command that caused the error occurred, the device was active or idle.

Такая картина — суровая реальность. Естественно, что софтовый RAID в таком режиме не живет. Статус выглядит как-то так:

# gmirror status
      Name    Status  Components
mirror/gm0  DEGRADED  ad6 (ACTIVE)

Чтобы не искать каждый раз 2 команды для восстановления массива решение на сторонних сайтах, делаю себе пометку в этом блоге.

# gmirror forget gm0
# gmirror insert gm0 ad4

Сначала приказываем системе «забыть» про массив. Далее добавляем «потерянного бойца» в ряды, так сказать РККА.
Сбор массива — дело не одной минуты, сервер будет мучаться примерно сутки для дисков размером 2 ТБайта. Еще бы, ведь он просто копирует диски.

# gmirror status
      Name    Status  Components
mirror/gm0  DEGRADED  ad6 (ACTIVE)
                      ad4 (SYNCHRONIZING, 0%)

Disks   ad4   ad6
KB/t    127   119
tps     652   723
MB/s  80.79 84.02
%busy    22    96

Полка 3 ошибки, молча собираем массив. Вот будет 30, тогда можно создать тикет в саппорт.

В ряде случаев пр работе с FreeBSD необходимы исходники системы, но далеко не всегда они поставлены при установке. С помощью cvsup достаточно проблематично получить исходники, версия которых гарантированно совпадает с версией установленной системы. Допускать различные версии системы и исходников крайне нежелательно, поскольку приложения, собранные из новых исходников будут потенциальной причина паник ядра в самый неожиданный момент. Если вы помните с какого диска ставили систему,  то исходники можно легко поставить. Несколько усложнит задачу отсутствие консольного доступа к серверу, да и, собственно говоря, отсутствие в ней CD-привода, что чаще всего и наблюдается на практике.

Итак. Качаем с официального сайта образ установочного диска:

# fetch ftp://ftp.freebsd.ru/pub/FreeBSD/ISO-IMAGES-i386/8.0/8.0-RELEASE-i386-disc1.iso
8.0-RELEASE-i386-disc1.iso                    100% of  625 MB   36 kBps 00m00s

Создаем на основе скачанного файла блочное устройство md0:

# mdconfig -a -f ./8.0-RELEASE-i386-disc1.iso
md0

Монтируем устройство:

# mount_cd9660 /dev/md0 /mnt

Копируем директорию с исходниками в свою домашнюю директорию:

# cp -Rf /mnt/8.0-RELEASE/src /usr/home/myuser

Отмонтируем образ диска и уничтожаем блочное устройство:

# umount /mnt
# mdconfig -d -u md0

Далее исправляем файл install.sh, содержание которого должно быть таким:

#!/bin/sh

dists="base bin cddl contrib crypto etc games gnu include krb5 lib libexec release rescue sbin secure share sys tools ubin usbin"

echo "Extracting sources into /usr/src..."
for i in $dists; do
echo "  Extracting source component: $i"
cat s${i}.?? | tar --unlink -xpzf - -C /usr/src
done
echo "Done extracting sources."
exit 0

Запускаем сценарий install.sh

# ./install.sh
Extracting sources into /usr/src...
Extracting source component: base
Extracting source component: bin
Extracting source component: cddl
cddl/contrib/opensolaris/cmd/zpool/zpool.8: (Empty error message)
tar: Error delayed from previous errors.
Extracting source component: contrib
Extracting source component: crypto
Extracting source component: etc
Extracting source component: games
Extracting source component: gnu
Extracting source component: include
Extracting source component: krb5
Extracting source component: lib
Extracting source component: libexec
Extracting source component: release
Extracting source component: rescue
Extracting source component: sbin
Extracting source component: secure
Extracting source component: share
Extracting source component: sys
Extracting source component: tools
Extracting source component: ubin
Extracting source component: usbin
Done extracting sources.

Имеет место ошибка при извлечении одного файла, но это не критично. В директории /usr/src получаем исходный код системы.

Bsdlabel + newfs

Создать метки в слайсе с использованием sysinstall при подключении к нового диска настоящее мучение. Процентов 90 гарантии, что ничего не получится. Неужели стоит нервничать, упорствовать и тыкаться в утилиту получая непонятные сообщения об ошибках. Нет кончено. Это не Microsoft Windows, есть полноценные команды для описанной задачи.

Итак, с помощью sysinstall (или без таковой) создаем на диске слайс, например /dev/ad16s1 (в новых платах, на которых достаточно много портов SATA можно встретить и /dev/ad31s1). Предположим нужно создать одну метку размером 50 Гбайт и отформатировать в UFS2 c SoftUpdate. Нет проблем. Только не забудьте изменить редактор по умолчанию, иначе придется столкнутся с мерзким vi, который я терпеть не могу. Если работаете в оболочке csh изменить редактор нужно так: Читать полностью »

Проверка жесткого диска в FreeBSD

Иногда у приверженцев настоящей системы к сожалению может возникнуть проблемы с железом. например есть подозрение, что жесткий диск потихоньку «сыпется». Это очень неприятная ситуация, поскольку FreeBSD может зависать, перегружаться (не всегда успешно) и выделывать прочие чудеса. На разделах с Soft Update возможна потеря информации, а при достижении некоторого уровня «зоофилии» может испортится весь раздел так, что никакие fsck уже не помогут. Проверить состояния вашего «питомца» в ранней стадии «заболевания» можно с помощью порта dd_rescue.

# /usr/ports /sysutils/dd_rescue
# make install clean

Строка запуска программы для проверки раздела /dev/ad4s1e выглядит так:

# dd_rescue -v -l error.log -o bad.log /dev/ad4s1e /dev/null

Файл error.log содержит отчет о секторах с ошибками, а в файл  bad.log записываются обнаруженные bad-блоки.

Результат тестирования имеет вид:

dd_rescue: (info): about to transfer 0.0 kBytes from /dev/ad4s1e to /dev/null
dd_rescue: (info): blocksizes: soft 65536, hard 512
dd_rescue: (info): starting positions: 0.0k, out 0.0k
dd_rescue: (info): Logfile: error.log, Maxerr: 0
dd_rescue: (info): Reverse: no , Trunc: no , interactive: no
dd_rescue: (info): abort on Write errs: no , spArse write: err
dd_rescue: (info): ipos:   1637376.0k, opos:   1637376.0k, xferd:   1637376.0k
dd_rescue: (info): ipos: 488386496.0k, opos: 488386496.0k, xferd: 488386496.0k
errs:      0, errxfer:         0.0k, succxfer: 488386496.0k
+curr.rate:    25647kB/s, avg.rate:    25844kB/s, avg.load:  1.7%
dd_rescue: (info): problems at ipos 488386496.0k: Unknown error: 0
fall back to smaller blocksize


dd_rescue: (info): /dev/ufsid/4cbcb79a6f0f961dd (488386560.0k): EOF
Summary /dev/ad4s1e -> /dev/null:
dd_rescue: (info): ipos: 488386560.0k, opos: 488386560.0k, xferd: 488386560.0k
errs:      0, errxfer:         0.0k, succxfer: 488386560.0k

+curr.rate:   128118kB/s, avg.rate:    25844kB/s, avg.load:  1.7%

Весь вывод записывается в файл error.log. Время проверки диска размером 500 Гбайт — приблизительно 6 часов. Проверка показала отсутствие bad-блоков и блоков с ошибками. с чем меня и поздравьте. Проверять можно и примонтированный раздел — нужен только доступ для чтения.

IPFW — элементарный роутер с шейпером и NAT

К чему сводится в большинстве случаев функционал роутера на FreeBSD? Это ограничение скорости хостам и трансляция (маскарадинг адресов). Рассмотрим реализацию для небольшой сети, например на 29 хостов (192.168.0.0/0), каждому из них необходимо ограничить скорость, скажем по 256Кбит/с. Самая простая реализация представляет собой последовательную обработку:

  • ограничение скорости (с помощью dummynet) на внутреннем интерфейсе (192.168.0.254/24 em0)
  • трансляция адресов на внешнем интерфейсе (109.86.41.14/24 re0).

Первую задачу наиболее просто решить тупым набором правил с pipe

/sbin/ipfw -q pipe 1001 config bw 16Kbits/s
/sbin/ipfw -q pipe 1002 config bw 16Kbits/s
/sbin/ipfw -q add 1001 pipe 1001 ip from any to 192.168.0.1 out xmit em0
/sbin/ipfw -q add 1002 pipe 1002 ip from 192.168.0.1 to any recv em0

и т.д. для всех необходимых адресов.

Трансляцию адресов реализуем средствами ipfw nat. Для всего блока:

/sbin/ipfw -q nat 101 config ip 109.86.41.14
/sbin/ipfw -q add 2001 nat 101 ip from any to 109.86.41.14 recv re0
/sbin/ipfw -q add 2002 nat 101 ip from 192.168.0.0/24 to any out xmit re0

Это простейший элементарный пример для начинающих.