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 -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
# strings –a /proc/<pid_of_the_process>/environ
# procstat -e <pid_of_the_process>
# pargs -e <pid_of_the_process>
pkg CVE
Начиная с SRU 11.2.5.X.X доступен поиск по базе CVE. Подробнее можно прочесть здесь. Так же можно проверить, исправлен ли нужный баг:
$ pkg search -f ':set:com.oracle.service.bugid:7146824' INDEX ACTION VALUE PACKAGE com.oracle.service.bugid set 7146824 pkg:/library/security/openssl@1.0.0.7-0.175.0.5.0.3.0
В комплекте 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 ...
В рассылке нашёл исходники автора Youzhong Yang. Привожу как есть, используйте на свой страх и риск.
Не используйте ни tshark, ни tcpdump на Solaris, тем более на SPARC системах. Иначе получите полное подвисание сервера. Даже в официальной документации сказано:
System Might Hang When Running the tshark Command on an Interface With Network Traffic (7202371)
The system might hang when you run the tshark command on an interface with network traffic.Workaround: Use the snoop command instead of tshark or wireshark command.
Выдержка из документации:
| Синтаксис: | fastcgi_connect_timeout время; |
|---|---|
| Умолчание: | fastcgi_connect_timeout 60s; |
| Контекст: | http, server, location |
Задаёт таймаут для установления соединения с FastCGI-сервером. Необходимо иметь в виду, что этот таймаут обычно не может превышать 75 секунд.
Профилировщики это такие вспомогательные программы, которые позволяют выявить узкие места в самом приложении, то есть копнуть глубже, чем top/iostat/vmstat и понять, что именно (библиотека, функция, …) тормозит
Некоторое время назад fmadm начал заваливать сообщениями типа
External sensors indicate that a fan is no longer operating correctly.
Сообщение важное, но ребутать сервер, что бы посмотреть, что там с куллерами нельзя, так как сервер в продакшине. Такие сообщения валятся по пару раз в день и уже спустя неделю – надоели. Было принято решение (не совсем корректное, но по другому нельзя) – отключить уведомление.
