Иногда pkg при установке/обновлении тянет столько зависимостей или начинает чудить с удалением нужных пакетов. Тогда будем применять следующий приём: скачивать (или собирать на основе порта) нужный пакет, помещать его в наш репозиторий, отключать удалённый, ставить пакет.
Категорія: FreeBSD
IPFilter
map net0 10.10.10.0/24 -> 192.168.0.2/24 round-robin
map net0 10.10.10.0/24 -> 192.168.0.3 round-robin
Iptables
# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 -j SNAT --to 1.2.3.0/24
# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 -j SNAT --to 1.2.3.0-1.2.3.4 --to 1.2.3.6-1.2.3.254
Linux
# strings –a /proc/<pid_of_the_process>/environ
FreeBSD
# procstat -e <pid_of_the_process>
Solaris
# pargs -e <pid_of_the_process>
В комплекте dtrace tool kit есть скрипт opensnoop, который позволяет просматривать открытые файлы в режиме реального времени.
Пример использования.
./opensnoop.d -x -n php UID PID COMM FD PATH 620 8483 php -1 /var/ld/ld.config 620 8483 php -1 /bin//php-cli.ini 620 8483 php -1 /soft/sun_free/php/php-cli.ini 620 8483 php -1 /bin//php.ini ...
Iron Bars SHell, or short ibsh is my first attempt to create a restricted working environment for Linux/Unix. I’m sure that many system administrators wish or have wished for a way to lock some/all users into a safe dungeon, where they can only do harm to their own files. Even more important is the protection against users reading sensitive files, for example the /etc/passwd file, which is accessible for any person with an unrestricted shell. But many system files may be listed here. Users could easily gain information, that could help malicious hackers to compromise the system, the network, the company.
Many attempts have already been made to fix this problem. Menu-based and other interactive shells have been created, but they were not able to completely satisfy worried system administrators. The amount of documents available at various security sites about how to bypass restrictions, how to hack through these shells and gain full access, shows, that ANY experienced Linux user is able to cause big problems.
Ошибка полностью выглядит так:
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’ом:
Ошибка в полном виде:
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 секунд.
