Выдержка из документации:
| Синтаксис: | fastcgi_connect_timeout время; |
|---|---|
| Умолчание: | fastcgi_connect_timeout 60s; |
| Контекст: | http, server, location |
Задаёт таймаут для установления соединения с FastCGI-сервером. Необходимо иметь в виду, что этот таймаут обычно не может превышать 75 секунд.
Профилировщики это такие вспомогательные программы, которые позволяют выявить узкие места в самом приложении, то есть копнуть глубже, чем top/iostat/vmstat и понять, что именно (библиотека, функция, …) тормозит
# 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 -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 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.
Если у кого-то не заработало, вот ссылка на разбивку на подсети
$ sudo add-apt-repository ppa:thefanclub/grive-tools
$ sudo apt-get update
$ sudo apt-get install grive grive-tools
И так, предположим, что 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.
Для отслеживания изменений в реальном времени будем использовать встроенные механизмы каждой ОС, где это возможно.
Разное
А вот и ПО, которое построено на базе вышеперечисленных механизмов, которое позволяет синхронизировать контент в реальном времени:
Для отслеживания изменения конфигурационных файлов, можно использовать разного рода инструменты. Можно использовать inotify, но оно не всегда удобно.
Это называется Linux audit trails. Как это настроить и использовать – описано здесь
К сожалению, нормального аналога нет, но зато энтузиасты написали что-то похоже. Так же рекомендую прочесть другую заметку
Схема работы следующая:
клиент —– (external ip=1.1.1.1) SRV (openvpn ip=10.8.0.1) —- [openvpn tunnel] —– (openvpn ip=10.8.0.6) Asterisk (NO external IP)
То есть, клиент в настройках SIP-аккаунта телефона указывает ip=1.1.1.1 и совершает звонки через сервер астериска, у которого вообще нет внешнего IP (“спрятан” в офисе)
Разделим задачу на несколько.