Дано: фронт nginx как реверс прокси
один из бэков срмка nginx+bitrix
после перезда на ssl + letsencrypt
серты генерирую на фронте далее новые серты заливаются на бэк с релоадом.
но в один прекрасный момент появилась ошибка,
2021-Nov-09 19:14:36 Работа с сокетами (check_socket): Fail
Connection to ssl://192.168.10.65:443 Fail
Socket error [0]:
удивительно зайдя на сервак по внутреннему адресу серт был от фронта, значит не в нем дело.
Давненько ничего не писал, все нет времени.
Очередная интересная задачка т.к. есть задача по перезду с платных решений оракла или ibm на OpenSource коллеги со смежных подразделений обратились за помощь в настройки связи weblogic+posgresql, и как часто это бывает инструкций нет.
Закинул либу в .../${DOMAIN_NAME}/lib/postgresql-42.2.20.jar но либа не появилась.
Было много разных дебагов проверка environ пида java серверов, проверка ps -ef |grep java - к сожалению нигде нет данных, что либа подтянулась.
Решил открыть статейку полезностей по линуксу которые часто применяю в работе - пополняется.
1) Если необходимо, что бы процессы висели к сессиях и к ним есть потребность вернуться, для этого запускаем screen и дальше работаем как в обычном терминале
для запуска из под определенного пользователя неоходимо ввести комманду для удобства описываем имя сессии которе не учавствует в дальейшем подключени например:
screen -S pb_basebackup
после запуска открывается сессия проверить можно
Есть некоторые системы типа siebel которые плодят большое кол. файликов более 10млн на каталог, так вот удаление старых не нужных лог файлов или темпов, через rm не даст никакого результата система выругается матом и скажет, что такого делать не буду, но есть вариант загнать все это в цикл
for f in ./*.log; do rm "$f"; done
Многие кто сопровождают weblogic, сталкивались с ситуацией когда, нужно пропатчить weblogic, а там версия 10.3.6, а это значит, что weblogic в версии 10.3.6 патчится только через bsu и это адище т.к. обычно это сперва чекин-удаление конфликтных-чекин-установка и это еще лайтовый вариант на каждый шаг, в среднем где то от 15-30 минут.
Как оказалось есть решение, на помощь нам приходит смартапдейты от производителя:
первым заливаем p12426828_1035_Generic после сверху p31136426_1036_Generic
Работает на SunOS,RH,Win;
1) скопируем и установим куратор на какую нибудь мастерноду cd /distro/ yum install elasticsearch-curator-5.6.0-1.x86_64.rpm
2) создадим каталог mkdir /etc/curator
3) создадим config.yml для подключения к elastic
Настраиваем авторизацию через LDAP
1) Конфигурируем securityconfig/config.yml для авторизации через LDAP
1.1) Правим конфигу на всех серверах OD(OpenDistro)
mcedit /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/config.yml
1) определяемся с ролью сервера для нас это ALLinOne без warm, с двумя репликами, важно определиться до того как пойдет поток потому, что прийдется сперва сделать шаблон с названиями и настройкой сколько будет реплик и шард.
Кучу шард под один небольшой сервис делать нет смысла, но и один большой тоже, важно придерживаться правила один шард около 30Гб.
Через утилиту разработчика
---проверяем что память зарезервирована---
GET _nodes?filter_path=**.mlockall
---просмотр состояния кластера * отмечен ведущий мастер
GET _cat/nodes
GET _cluster/health
---просмотр по загруженности нод---
GET _cat/allocation
GET _cluster/stats?filter_path=**.nodes
---ClusterState просмотр статуса кластера---
GET _cluster/state?pretty
GET _cluster/stats?human&pretty
---ClusterHealth просмотр состояния кластера---
GET _cluster/health?pretty
Установка Логстеша на отдельную машину
1) mkdir /distro
2) yum install java-1.8.0-openjdk-devel
3) копируем logstash на сервер в /distro
4) yum install logstash-oss-6.7.1.rpm
5) systemctl enable logstash.service
6) logstash.yml node.name: ls-tkli-middle0009 pipeline.workers: 4 #по кол. cpu (cat /proc/cpuinfo path.data: /var/lib/logstash path.logs: /var/log/logstash
7) создаем и конфигурируем например nginx.conf под требования в /etc/logstash/conf.d
8) service logstash start && systemctl enable logstash