PF
В портах есть утилита sysutils/pftop
IPF
Штатная утилита из комплекта (ipfstat -t)
Категорія: Linux
Выдержка из документации:
| Синтаксис: | 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.
Если у кого-то не заработало, вот ссылка на разбивку на подсети
Категорії
Бесплатные online хранилища
google drive
$ sudo add-apt-repository ppa:thefanclub/grive-tools
$ sudo apt-get update
$ sudo apt-get install grive grive-tools
Категорії
Наследование acl в ext4
И так, предположим, что ACL вы собственно настроили. Но наследование не работает. Здесь кроется 2 момента: наследование прав со стороны ФС и наследование прав со стороны ACL.
Для решения первого вопроса, нужно перемонтировать ФС с параметром bsdgroups:
# mount -o remount,bsdgroups /opt
Так же не забудьте внести правки в /etc/fstab:
/dev/sda7 ext4 errors=remount-ro,acl,bsdgroups 0 1
При настраивании разного рода сервисов приходится сталкиваться с тем, что на одном интерфейсе, находится несколько алиасов. Всё бы ничего, но возникают вопросы: с каким src address будет уходить пакет?
Если алиасы из разных подсетей, то ответ сразу ясен. А если нет?
Я обновлялся с 12.10 до 14.04.
Что бы нормально обновить и без ругани, сначала нужно удалить все i386 пакеты (лучше сохранить их список куда-то в файл, что бы потом заново проинсталлить). Удаляем такой командой:
# for i in `dpkg -l | grep i386 | grep -v amd64 | awk '{print $2}'`; do dpkg -P $i; done
Причём это нужно будет делать не 1 раз, так как будут зависимости и не всё удалится с первого раза. Мне пришлось запустить команду раз 6.
Для отслеживания изменений в реальном времени будем использовать встроенные механизмы каждой ОС, где это возможно.
Linux
FreeBSD/OpenBSD
Solaris
Разное
А вот и ПО, которое построено на базе вышеперечисленных механизмов, которое позволяет синхронизировать контент в реальном времени:
Речь идёт о пулах в десятки терабайт, которые заполнены данными. Команды zpool/zfs destroy даже не мощном сервере будет выполняться часами, если не днями.
Оказывается, выход есть.
# zpool export -f data_pool
# zpool create -f data_new raidz2 c5t0d0 ...
То есть экспортируем пул (на всякий случай принудительно), а потом принудительно создаём на тех же дисках новый пул.