Багато хто в мережі інтернет пише, що модулі треба вантажити через /boot/loader.conf, але краще так не робити, і ось чому. При ранньому завантаженні (через loader.conf) резервується деякий обʼєм памʼяті, і от, якщо у вас досить великий модуль, наприклад nvidia.ko, то памʼяті може не вистачити і почнуться проблеми із завантаженням.
Це буде коротке нагадування у випадку, коли iostat показує велике навантаження на диски, але через dtrace (rwsnoop, …) ви не бачите, щоб якийсь процес так навантажував диски. Тут варіанти 2: або запущений scrub на цьому пулі або активно використовується swap, який розташований на цих дисках.
Варіанти рішення: зупинити scrub (якщо це він) або перенести swap на інший пул (якщо це можливо).
В Solaris є таке поняття, як contract id (ctid). Перекласти його українською не можна, бо втрачається суть. Так ось, він повʼязує між собою процеси і служби smf.
Розглянемо це на прикладі, щоб краще зрозуміти. У нас є запущені процес, але ми не знаємо, який сервіс їх запускає. Для цього, нам треба дізнатися ctid цих процесів:
$ ps -efc -o ctid,comm,args,pid,user | grep python
1759 python3 python3 /export/home/user01/run_daemon.py --skip-origin 938206 webservd
1759 python3 python3 /export/home/user01/run_daemon.py --skip-origin 201025 webservd
А тепер знайдемо сервіс з ctid 1759:
$ svcs -o CTID,SVC | grep 1759
1759 application/pm2
В даній статті мова йтиме саме про необхідні privileges при запуску сервісів. Для звичайного запуска можна використати ppriv .
Отже, маємо сервіс, який запускається, але в логах скаржиться на permission denied. Зрозуміло, що йому чогось не вистачає, але проблема ускладнюється тим, що це fork від мастер-процесу і він викликається по запиту. Тобто, просто так натравити ppriv не можна.
Дана стаття буде актуальна тим, у кого мережевий інтерфейс з “особливостями”: USB-мережева карта, яка довго ініціалізується, чи отримання адреси через pppoe, чи DHCP сервер дуже повільний. На що це впливає? Припустимо, що у вас є деякі сервіси, які повинні “слухати” ці інтерфейси, які довго піднімаються. За замовчуванням, сервіси піднімаються одразу, не дочекавшись, поки інтерфейс отримає адресу. Як результат, частина сервісів може не піднятися через це. Можна, звичайно, міняти кожен стартовий скрипт, додаючи у секцію REQUIRED відповідну залежність, але ця зміна затреться після чергового оновлення. І навіщо, коли є штатний інструмент для цього?
netwait_enable="YES"
netwait_timeout="10" # Total number of seconds to perform pings.
netwait_ip="1.1.1.1" # Wait for ping response from any IP in this list.
netwait_if="ue0" # Wait for active link on each intf in this list.
netwait_if_timeout="30" # Total number of seconds to monitor link state.
Нагадаю, що таке ToS (Type of Service) – це можливість пріоритезувати певний трафік за рахунок виставлення спеціального байта у заголовку IP пакету. DSCP – деяке розширення (або в деякому сенсі новіша версія ToS), бо має більше різних пріоритетів (64 проти 7 у ToS).
Після одного оновлення один з клієнтів перестав підключатися по ssh до серверу. Враховуючи, що клієнт – це ПЗ закритого типу і з його сторони ми нічого не можемо вдіяти, прийшлося розбиратися зі сторони серверу. Включаємо debug в /etc/ssh/sshd_config:
SyslogFacility AUTH LogLevel DEBUG
і бачимо в логах таке:
Постала задача підключатися через 3G-модем. В даному випадку це Huawei e3372.
Скрипт підключення /opt/scripts/usb_modem.sh:
На одному дуже старому сервері виникла проблема з curl
# curl https://domain.com curl: (60) SSL certificate problem: certificate has expired More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.
Розглянемо лише ту частину яка стосується авторизації у LDAP. Отже в конфіг серверу додаємо таке
username-as-common-name
plugin /usr/lib/openvpn/openvpn-auth-ldap.so /etc/openvpn/auth/ldap.conf
Перший рядок каже, що login такий самий, як у LDAP’і, а другий – підключає відповідний модуль авторизації. А тепер налаштування для модулю авторизації /etc/openvpn/auth/ldap.conf:
