Мой же случай отличался тем, что надо разместить VPN на этом же сервер, который мы хотим закрывать от внешнего мира. Ну в общем тоже не сказать чтобы сложно. Но у меня был нюанс с тем, что на сервере крутится куча docker-compose стэков, которые случают внешние порты, а эти порты невозможно закрыть через INPUT-цепочку iptables. Пришлось много подебажить, чтобы заставить все работать как надо. Были затронуты только 2 цепочки — INPUT, DOCKER-USER. Итоговые настройки iptables у меня получились такие:

-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21821 -j ACCEPT
-A INPUT -p udp -m udp --dport 21820 -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -p udp -m udp --sport 123 -j ACCEPT
-A INPUT ! -i eth0 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -j DROP

Цепочка DOCKER-USER:

-A DOCKER-USER -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A DOCKER-USER -i eth0 -p udp -m udp --dport 21820 -j ACCEPT
-A DOCKER-USER -i eth0 -p tcp -m tcp --dport 21821 -j ACCEPT
-A DOCKER-USER -i eth0 -p tcp -j DROP
-A DOCKER-USER -i eth0 -p udp -j DROP

eth0 — это внешний интерфейс, торчащий в интернет. Порты 21820, 21821 взяты из настроек подключения к wireguard.

В качестве VPN-сервиса я выбрал wireguard с простой настройкой через web: https://github.com/WeeJeWel/wg-easy

После всех манипуляций, во внешку торчат только 22 и 21820/udp 21821/tcp. Остальные порты, включая веб, доступны только после того как подключишься по VPN.

1. У вас не стоят хидеры для openssl. Решается это просто — поставить пакет openssl-devel для CentOS/RH или libssl-dev для Ubuntu/Debian.
2. Версия вашего системного openssl слишком новая для питона. Тут все немного сложнее. Характеризуется наличием DEPRICATED ошибок в логе python-build. Про решение этой проблемы пойдет речь ниже.

Важное замечание! Перед тем как приступать, удалите пакет с хидерами от вашего openssl (openssl-devel, libssl-dev и т.д.).

Первое что надо сделать, это понять какую версию openssl нужно собрать для компиляции нужного вам питона. Для старых версий питона чаще всего это будет openssl-1.0.1, при условии то в системе у вас стоит минимум openssl-1.1.0. Если вы хотите собрать новую версию питона на старом линуксе, то все будет наоборот.

Итак, мы определились. В моем случае мне нужен openssl-1.0.1. Качаем исходники c https://ftp.openssl.org/source/old/1.0.1/ . Я взял последнюю версию openssl-1.0.1u.tar.gz. Распаковываем исходники и заходим в директорию. Прежде чем компилить, ставим компилятор и сопутствующие библиотеки. Для CentOS 8 это:

# dnf install make gcc zlib-devel bzip2 bzip2-devel readline-devel sqlite sqlite-devel tk-devel libffi-devel tar patch

Конфигурируем сборку:

# ./config --prefix=/opt/openssl-1.0.1 shared

Я буду ставить сборку в /opt/openssl-1.0.1, просто потому что мне так удобнее. Ключ shared явно указывает создавать shared libraries, которые нужны питону.

Собираем и устанавливаем:

# make
.......
# make install

Openssl-1.0.1 собран и установлен. Теперь надо заставить pyenv видеть его. И вот тут я потратил не мало времени, чтобы понять почему не подхватывается новый openssl. А ларчик открывается просто.

При компиляции питона, в скрипте setup.py указаны пути, по которым ищутся заголовочные файлы openssl. Это директории /usr/include, /usr/local/ssl, /usr/contrib/ssl/include/. Дак вот, чтобы pyenv подхватил наш openssl надо создать симлинк от нашего openssl до одной из эти директорий.

# ln -s /opt/openssl-1.0.1/ /usr/local/ssl

Для себя я решил, что это будет путь /usr/local/ssl, т.к. создавать симлинки вручную в /usr/include это костыль.

Но это еще не все. Для того, чтобы при компиляции подхватились нужные нам shared libraries, нужно указать переменную окружения LD_LIBRARY_PATH=/opt/openssl-1.0.1/lib/

Либо добавить эту переменную окружения пользователю в .bash_profile:

# echo 'export LD_LIBRARY_PATH="/opt/openssl-1.0.1/lib/"' >> ~/.bash_profile
# bash

или указать при сборке pyenv:

# LD_LIBRARY_PATH="/opt/openssl-1.0.1/lib/" pyenv  install 3.5.2

Готово, Питон собирается и использует нужный нам openssl.

Один маленький нюанс. Пользователь от которого будет работать ваше приложение с этой версией питона должен так же иметь переменную окружения LD_LIBRARY_PATH=/opt/openssl-1.0.1/lib/

Как уже было указано выше, можно добавть в .bash_profile, можно добавить в systemd service файл вашего демона Environment=’LD_LIBRARY_PATH=/opt/openssl-1.0.1/lib/’, есть и другие варианты. Это уже надо смотреть исходя из того как вы собрались запускать приложение на питоне.

На Fedora\CentOS ставим пакет alsa-tools

# dnf install alsa-tools

Запускаем hdajackretask. Выбираем IDT 92HD91BXX

Нажимаем “Show unconnected pins” и выбираем

• Выставляем 0x0d (Internal Speaker, фронтальные динамики) в «Internal speaker».
• Выставляем 0x10 (“Not connected”, сабвуфер) в «Internal speaker (LFE)»

Нажимаем «Install boot override» и перезагружаемся.

Оригинал тут

Exception in thread "main" org.dbmaintain.util.DbMaintainException: Following irregular script updates were detected:
.... Тут перечислены скрипт(ы) .....
Because of this, dbmaintain can't perform the update. To solve this problem, you can do one of the following:
  1: Revert the irregular updates and use regular script updates instead
  2: Enable the fromScratch option so that the database is recreated from scratch (all data will be lost)
  3: Perform the updates manually on the database and invoke the markDatabaseAsUpToDate operation (error prone)

Причина в том, что скрипт миграции уже содержится в таблице проведенных миграций и его контрольная сумма не совпадает с тем, что лежит на диске. Т.е. файл был изменен.

Решение. Смотрим в конфиге dbmaintain название таблицы куда пишутся все проведенные миграции в параметре dbMaintainer.executedScriptsTableName. Допустим это таблица migrations. Заходим в базу приложения, находим эту таблицу и ищем нужную нам запись

db=# select * from migrations where file_name like '%название_файла_из_ошибки%';

Видим запись, берем поле checksum и удаляем эту запись.

db=# delete from migrations where checksum='794fe145f2ad4f254e8ae187fd0ef1d5';

Далее как обычно проводим миграции

$ ./dbmaintain.sh updateDatabase -config MyConfig.properties

В моем случае эта миграция вообще была бесполезной. Поэтому перед тем как запустить обновление я зафейкал миграцию

./dbmaintain.sh markErrorScriptPerformed scripts/incremental/4/002_@some_script.sql -config MyConfig.properties

PKIX path validation failed: java.security.cert.CertPathValidatorException: timestamp check failed
java.security.cert.CertificateExpiredException: NotAfter: Sat May 30 16:48:38 2020

После напряженных поисков проблема решилась путем, не требующим вмешательства в код Java-чекера. Собственно исходников у нас от него и нет.

Дак вот. Проблема решилась следующими шагами:

1. На сайте https://whatsmychaincert.com/ была сгенерирована другая цепочка сертификатов. На выходе мы получили сертификат своего сайта + корневой сертификат COMODO CA RSA.

2. Полученную цепочку (файл сертификата) подсовываем вместо нашей старой цепочки (файла сертификата), где был злополучный AddTrust CA. В nginx это директива ssl_certificate.

3. Далее, т.к. у нас Java-прога старая, написана на седьмой версии, нам нужно вручную добавить COMODO CA RSA в хранилище доверенных сертификатов. Для этого конвертируем pem сертфикат COMODO CA RSA в der формат, что его мог понять keytool:

# openssl x509 -in ./comodoca.pem -inform pem -out comodoca.der -outform der
# cat ./comodoca.pem #Дам содержимое сертификата, на всякий случай
-----BEGIN CERTIFICATE-----
MIIGDjCCA/agAwIBAgIQNoJef7WkgZN+9tFza7k8pjANBgkqhkiG9w0BAQwFADCB
hTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNV
BAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTQwMjEy
MDAwMDAwWhcNMjkwMjExMjM1OTU5WjCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgT
EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxPDA6BgNVBAMTM0NPTU9ETyBSU0EgT3JnYW5pemF0
aW9uIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBDQTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBALkU2YXyQURX/zBEHtw8RKMXuG4B+KNfwqkhHc5Z9Ozz
iKkJMjyxi2OkPic284/5OGYuB5dBj0um3cNfnnM858ogDU98MgXPwS5IZUqF0B9W
MW2O5cYy1Bu8n32W/JjXT/j0WFb440W+kRiC5Iq+r81SN1GHTx6Xweg6rvn/RuRl
Pz/DR4MvzLhCXi1+91porl1LwKY1IfWGo8hJi5hjYA3JIUjCkjBlRrKGNQRCJX6t
p05LEkAAeohoXG+fo6R4ESGuPQsOvkUUI8/rddf2oPG8RWxevKEy7PNYeEIoCzoB
dvDFoJ7BaXDej0umed/ydrbjDxN8GDuxUWxqIDnOnmkCAwEAAaOCAWUwggFhMB8G
A1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSa8yvaz61P
ti+7KkhIKhK3G0LBJDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIB
ADAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwGwYDVR0gBBQwEjAGBgRV
HSAAMAgGBmeBDAECAjBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9k
b2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggr
BgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29t
L0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz
cC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAGmKNmiaHjtlC+B8z6ar
cTuvYaQ/5GQBSRDTHY/i1e1n055bl71CHgf50Ltt9zKVWiIpYvgMnFlWJzagIhIR
+kf0UclZeylKpUg1fMWXZuAnJTsVejJ1SpH7pmue4lP6DYwT+yO4CxIsru3bHUeQ
1dCTaXaROBU01xjqfrxrWN4qOZADRARKVtho5fV8aX6efVRL0NiGq2dmE1deiSoX
rS2uvUAOZu2K/1S0wQHLqeBHuhFhj62uI0gqxiV5iRxBBJXAEepXK9a0l/qx6RVi
7Epxd/3zoZza9msAKcUy5/pO6rMqpxiXHFinQjZf7BTP+HsO993MiBWamlzI8SDH
0YZyoRebrrr+bKgy0QB2SXP3PyeHPLbJLfqqkJDJCgmfyWkfBxmpv966+AuIgkQW
EH8HwIAiX3+8MN66zQd5ZFbY//NPnDC7bh5RS+bNvRfExb/IP46xH4pGtwZDb2It
z1GdRcqK6ROLwMeRvlu2+jdKif7wndoTJiIsBpA+ixOYoBnW3dpKSH89D4mdJHJL
DntE/9Q2toN2I1iLFGy4XfdhbTl27d0SPWuHiJeRvsBGAh52HN22r1xP9QDWnE2p
4J6ijvyxFnlcIdNFgZoMOWxtKNcl0rcRkND23m9e9Pqki2Z3ci+bkEAsUhJg+f+1
cC6JmnkJiYEt7Fx4b4GH8fxV
-----END CERTIFICATE-----

4. Добавляем DER-сертификат в Java keystore

# keytool -importcert -alias comodocarsa -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass пароль -file comodoca.der

По дефолту пароль changeit

После чего перезапускаем Java-приложение и проверяем что оно стало успешно чекать файлы, больше не придираясь к сертификату. Тем самым мы отвязали наш сайт от цепочки с протухшим AddTrust.

На всякий случай уточню, что содержимое ./comodoca.pem я взял из файла, который мне выдал сайт https://whatsmychaincert.com/. В файле 2 сертификата в PEM формате. Первый — это сертификат нашего сайта, а второй это COMODO CA RSA. Я просто взял второй и скопировал его в отдельный файл.

sed -n '/14\/May\/2020:10:00/,/14\/May\/2020:15:00/p' /var/log/nginx/access_ssl.log > ~/access_ssl_from_10_to_15.log

В итоге мы получим файл ~/access_ssl_from_10_to_15.log с логами nginx c 10:00 утра до 15:00 дня.

Возможно в дальнейшем будут дополнять эту страничку

# Список особых адресов
geo $managed_ips {
    default 0;
    10.0.1.5/32 1;
    10.0.2.3/32 1;
    10.0.3.0/24 2;
} 

# Определяем куда пойдут особые адреса 
map $managed_ips $fcgi_to {
    default    "unix:/var/run/php5-fpm.sock"; # php 5
    1          "127.0.0.1:9000"; # php 7.1
    2          "10.5.5.10:9000"; # php 7.4 
}

Далее в нужном location направляем пользовователей к соответствующему бэкэнду.

location / {
    ...
    fastcgi_pass $fcgi_to; 
    ...
}

Вместо fastcgi_pass может быть proxy_pass, в зависимости от того что нам нужно сделать.

По работе попробовали настроить эту связку без использования nginx на нодах, т.е. запросы с балансировщика идут напрямую в php-fpm, тем самым сэкономив чуточку ресурсов.
В моем случае производится балансировка сайта на moodle и конфиг представленный ниже будет для его работы.

nginx на балансировщике:

upstream backend {
    server  10.1.2.3:9000;
    server  10.1.2.4:9000;
}


server {
    access_log /var/log/nginx/access_log;
    error_log /var/log/nginx/error_log;

    listen 443 ssl;
    server_name test-site.ru;
    
    ssl_certificate     /etc/nginx/ssl/test-site.ru.crt;
    ssl_certificate_key /etc/nginx/ssl/test-site.ru.key;

    location ~ /\. {
        deny all;
    }

    location / {
        if (-f /etc/nginx/tmp/maintenance.flag) {
            return 503;
        }

        index index.php;
        try_files $uri @moodle;
    }

    location @moodle {
        root /var/www/moodle/;
        fastcgi_split_path_info  ^(.+\.php)(.*)$;
        fastcgi_index            index.php;
        fastcgi_pass             backend;
        include         /etc/nginx/mime.types;
        include         fastcgi_params;
        fastcgi_param   PATH_INFO       $fastcgi_path_info;
        fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_buffer_size 128k;
        fastcgi_buffers 256 4k;
        fastcgi_busy_buffers_size 256k;
        fastcgi_temp_file_write_size 256k;
    }
}

Из конфига убрал какие-то специфические вещи. Просто общий вид. Сократить его можно засунув содержимое @moodle в location /. Но я решил оставить в таком виде.

php-fpm при этом настраивается почти стандартно, меняются только несколько опций в пуле:

listen = 10.1.2.3:9000 ; случаем на интерфейсе, доступном для балансировщика
listen.allowed_clients = 10.1.2.1 ; разрешаем коннектиться только балансеру
php_value[session.save_path] = "tcp://10.1.2.2:6379" ; храним php сессии в redis (нужно для корректной работы балансировки round robin + в настройках moodle надо внести изменения)

Остальные опции по вкусу.

Проблема вроде ясная и очевидным решением было бы переименовать файлы с длинными именами. Но файлов этих сотни, возможно тысячи. Есть множество мест на сайте, которые ссылаются на эти файлы. Править ссылки вообще не вариант, как и сделать редиректы для файлов. Как уже сказал, таких файлов сотни и возможно тысячи.

Поэтому пришлось придумывать как это победить.
Проблема заключается в кодировке. При монтировании виндовой шары, где файлы названы на русском языке — дефолтная кодировка это utf-8, каждый русский символ которой занимает 2 байта. Ограничение наложенное на длинну имени файла в linux — 256 байт. При этом это завязанно не столько на ФС, сколько на уровне абстракции VFS. Именно в нем этот лимит закреплен жестко. Исходя из того, что кирилистический символ занимает 2 байта в utf-8, максимальная длинна имени файла ограничена 128 символами.

Решение:

1) Монтируем виндовую шару с указанием однобайтовой кирилистической кодировки cp1251 (она же виндовая windows-1251, стандартная виндовая кодировка):
//win-server/files /mnt/files cifs user,ro,credentials=/root/.smbcredentials,vers=2.1,echo_interval=10,iocharset=cp1251 0 0

2) Заставляем nginx (именно он у нас используется) обращаться к файлам на cp1251 кодировке, а не на стандартном utf-8:
Для это используем замечательный модуль от наших азиатских друзей: nginx-module-url.
Пересобираем и устанавливаем nginx c опцией —add-module=/path/to/nginx-module-url, как указана на сайте.

3) Добавляем в нужный нам location перекодировку utf-8 запросов в cp1251:

location /files {
    url_encoding_convert               on;
    url_encoding_convert_from          utf-8;
    url_encoding_convert_to            windows-1251;

    expires max;
    root /mnt/;
....
}

Всё! Проблема с длинными виндовыми именами в файлах решена! nginx прекрасно читает и передает на скачивание такие файлы.

openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/ssl/private/selfsigned.key -out /etc/ssl/certs/selfsigned.crt