• В защиту swap'а [в Linux]: распространенные заблуждения
    0

    Если у вас конкретный демон с таким поведением и systemd — посмотрите на опцию OOMScoreAdjust.

  • В защиту swap'а [в Linux]: распространенные заблуждения
    +2

    Когда-то описывал полезную в этих случаях комбинацию Alt-SysRq-F — принудительно запустить OOM-killer один раз. По умолчанию она (и многие другие сочетания с SysRq) запрещены по соображениях безопасности (по каким именно — нужно читать где-нибудь в первоисточнике), а вообще есть даже сочетание для того, чтобы уронить ядро в kernel panic. :) Это не в качестве замены свопу, а в дополнение (при наличии свопа иногда весьма полезное).

  • В защиту swap'а [в Linux]: распространенные заблуждения
    0

    На всякий случай, вот документация. Там много всяких интересных штук, а вот про влияние на безопасность (локальный пользователь прибил lock screen и т.д.) нужно читать где-нибудь в другом месте. Кстати, при работе по ssh до magic sysrq key можно достучаться через /proc/sysrq-trigger, если права позволяют.

  • Авторизация клиентов в nginx посредством SSL сертификатов
    +1

    Вот пошаговый мануал: по факту нужно не 14 файлов, а меньше: ключевая пара удостоверяющего центра, ключевая пара сервера, ключевая пара клиента и конфиг Nginx. 7 :-)


    1. Создание сертификатов УЦ


      openssl genrsa -out ca.key 2048
      openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

    2. Создание сертификата сервера


      1. Конфигурационный файл server.cnf, пример:


        [req]
        prompt = no
        distinguished_name = dn
        req_extensions = ext
        
        [dn]
        CN = Сервер с аутентификацией клиентов
        emailAddress = my.email@example.com
        O = Private person
        OU = Alter ego dept
        L = Korolyov
        C = RU
        
        [ext]
        subjectAltName = DNS:example.com,DNS:*.example.com,IP:127.0.0.1

        В subjectAltName должны быть указаны все используемые DNS-имена и IP-адреса.


      2. Создание запроса на сертификат


        openssl req -new -utf8 -nameopt multiline,utf8 -config server.cnf -newkey rsa:2048 -keyout server.key -nodes -out server.csr

      3. Создание сертификата


        openssl x509 -req -days 3650 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt -extfile server.cnf -extensions ext

      4. Настройка Nginx, пример (фрагмент)


        http {
          ssl_certificate         /path/to/server.crt;
          ssl_certificate_key     /path/to/server.key;
          ssl_client_certificate  /path/to/ca.crt;
          ssl_verify_client       on;
        
          server {
            listen       8443 ssl default_server;
            listen       [::]:8443 ssl default_server;
          }
        }


    3. Создание сертификата клиента


      openssl req -new -utf8 -nameopt multiline,utf8 -newkey rsa:2048 -nodes -keyout client.key -out client.csr
      openssl x509 -req -days 3650 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out client.crt

    4. Проверка


      Следующая команда должна отрабатывать без ошибок:


      curl -v --cacert path/to/ca.crt --cert path/to/client.crt --key path/to/client.key https://127.0.0.1:8443/

      Следующая команда должна возвращать ошибку «не предоставлен сертификат клиента»:


      curl -v --cacert path/to/ca.crt https://192.168.194.97:8443/

    5. Добавление сертификата ЦА в RHEL (от имени root, где path/to/ca.crt — путь к файлу корневого сертификата)


      cp path/to/ca.crt /etc/pki/ca-trust/source/anchors/
      update-ca-trust


    Последний пункт нужен, чтобы можно было не указывать явно сертификат ЦА в командах (в том же cURL).