Ошибка полностью выглядит так:
sed: /usr/local/lib/libffi.la: No such file or directory
libtool: link: `/usr/local/lib/libffi.la' is not a valid libtool archive
Такого рода ошибки лечатся следующим workarond’ом:
Категорія: FreeBSD
Ошибка в полном виде:
pkg: sqlite error while executing DROP INDEX deps_unique;CREATE UNIQUE INDEX deps_unique ON deps(name, version, package_id); in file pkgdb.c:2262: UNIQUE constraint failed: deps.name, deps.version, deps.package_id
Означает, что где-то в базе есть дублирующие строки, причём не полностью 1 в 1, а совпадают 3 поля: name, version, package_id. Придётся править базу пакетов. Что бы понять, какие именно, выполним такую команду (на всякий случай сделайте резервную копию файла базы/var/db/pkg/local.sqlite)
По умолчанию, sshd стартует чуть ли не одним из последних (в том числе после squid’a, samb’ы, spamd и других демонов). Если на каком-то этапе один из таких демонов будет ожидать ввода пользователя, получим нерабочую систему, с невозможностью зайти удалённо. Почему так происходит? Ответ, оставлю цитатой юзера Eugene Grosbein:
Выдержка из документации:
| Синтаксис: | 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-мя способами: быстрым и правильным
