По умолчанию, sshd стартует чуть ли не одним из последних (в том числе после squid’a, samb’ы, spamd и других демонов). Если на каком-то этапе один из таких демонов будет ожидать ввода пользователя, получим нерабочую систему, с невозможностью зайти удалённо. Почему так происходит? Ответ, оставлю цитатой юзера Eugene Grosbein:
Категорія: FreeBSD
Выдержка из документации:
| Синтаксис: | fastcgi_connect_timeout время; |
|---|---|
| Умолчание: | fastcgi_connect_timeout 60s; |
| Контекст: | http, server, location |
Задаёт таймаут для установления соединения с FastCGI-сервером. Необходимо иметь в виду, что этот таймаут обычно не может превышать 75 секунд.
Профилировщики это такие вспомогательные программы, которые позволяют выявить узкие места в самом приложении, то есть копнуть глубже, чем top/iostat/vmstat и понять, что именно (библиотека, функция, …) тормозит
PF
# grep test /etc/pf.conf
test="{ 10.0.0.1 - 10.0.0.100 }"
block in quick on $ext_if from $test
# pfctl -nvf /etc/pf.conf | grep 10.0
test = "{ 10.0.0.1 - 10.0.0.100 }"
block drop in quick on em1 inet from 10.0.0.1 - 10.0.0.100 to any
Но у меня не всегда корректно срабатывало это правило на FreeBSD.
iptables
iptables -A INPUT -p tcp --destination-port 22 -m iprange --src-range 192.168.1.100-192.168.1.200 -j ACCEPT
iptables -t nat -A POSTROUTING -j SNAT --to-source 192.168.1.100-192.168.1.200
В остальных файерволах (ipfilter) данного функционала нет и придётся разбивать диапазон на подсети CIDR.
ipfw
ipfw add allow all from 1.2.3.0/24{128,35-55,89}
Выдержка из мана:
As an example, an address specified as 1.2.3.4/24{128,35-55,89}
or 1.2.3.0/24{128,35-55,89} will match the following IP
addresses:
1.2.3.128, 1.2.3.35 to 1.2.3.55, 1.2.3.89 .
Спасибо нашему читателю, который дополнил статью про ipfw.
Если у кого-то не заработало, вот ссылка на разбивку на подсети
Категорії
Заставляем работать igb/ixgbe с altq
Тестовый стенд: FreeBSD 10.1 Release amd64
При попытки использовать ALTQ на igb интерфейсах получаем следующее:
pfctl: igb0 : driver does not support ALTQ
хотя поддержка ALTQ в ядре есть. Вообще, при планировании использования ALTQ рекомендую обратится к такому “списку поддержки ALTQ”. Он не совсем официальный, но сведён в единую таблицу.
После старта выбираем LiveCD, переключаемся на консоль и устанавливаем ОС в ручном режиме:
Если получаем ошибку
# fetch http://bootstrap.saltstack.org
Certificate verification failed for /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
34380826280:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_clnt.c:1168:
fetch: http://bootstrap.saltstack.org: Authentication error
то избавится от её можно 2-мя способами: быстрым и правильным
По дефолту эта опция стоит в off. То есть, если вы забыли поставить её в on (или поставили уже после того, как заменили все диски), то для применения нужно использовать команду:
# zpool online -e ZPOOL DISK
для каждого диска из пула ZPOOL
При настраивании разного рода сервисов приходится сталкиваться с тем, что на одном интерфейсе, находится несколько алиасов. Всё бы ничего, но возникают вопросы: с каким src address будет уходить пакет?
Если алиасы из разных подсетей, то ответ сразу ясен. А если нет?
Включить пробы dtrace для java, как оказалось, не совсем очевидно. А всё дело в механизме lazy load, который активирует их только тогда, когда явно к ним обратится и только при выполнении таких условий:
1) java должна поддерживать hotspot:
# java -version
java version "1.7.0_60"
Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
Java HotSpot(TM) Server VM (build 24.60-b09, mixed mode)