Добавление корневого сертификата локального CA в системный ca-certificates.crt и Java keystore

При попытке подключиться в JXplorer к LDAP серверу с использованием SSL выдало предупреждение о неизвестном сертификате.

Вариант "This Session Only" решает проблему, но является временным. Попытка выбрать вариант "Always" заканчивается ошибкой, поскольку нет прав на запись в системное хранилище (/etc/ssl/certs/java/cacerts).

В Debian установка корневых сертификатов автоматизирована - нужно установить пакет ca-certificates, скопировать нужный сертификат в директорию /usr/local/share/ca-certificates и выполнить команду update-ca-certificates.

# aptitude install ca-certificates
# install -m 0644 /tmp/Corp-CA.crt /usr/local/share/ca-certificates
# update-ca-certificates

При этом содержимое сертификата Corp-CA.crt будет добавлено в бандл /etc/ssl/certs/ca-certificates.crt (используется по-умолчанию приложениями в системе) и при необходимости в дополнительные хранилища, подключенные через хуки /etc/ca-certificates/update.d. Поскольку у меня установлена java, то добавление сертификата в хранилище java произойдет автоматически при выполнении хука /etc/ca-certificates/update.d/jks-keystore.

Если вы хотите добавить сертификат руками, то это можно сделать так:

$ sudo keytool -keystore /etc/ssl/certs/java/cacerts -import -trustcacerts -alias "Corp CA" -file /tmp/Corp-CA.crt

В процессе выполнения спросит пароль от keystore - если вы ничего не меняли, то пароль по-умолчанию "changeit". Теперь проверим, что наш сертификат добавился

keytool -keystore /etc/ssl/certs/java/cacerts -list -alias 'Corp CA'
Corp CA, 29.05.2014, trustedCertEntry, 
Certificate fingerprint (SHA1): 15:2C:D3:50:20:69:43:2D:C7:C1:B7:06:6A:23:38:07:63:F3:EF:22

Теперь jxplorer подключается без лишних вопросов.

Включение планировщика DEADLINE для SSD дисков

По-умолчанию в большинстве дистрибутивов Linux сейчас используется планировщик ввода/вывода CFQ. Он показывает неплохие результаты для смешанной нагрузки, но для SSD дисков есть вариант получше. Для последних оптимальным будет deadline или noop. Раньше я использовал конструкцию вида

echo deadline > /sys/block/sda/queue/scheduler
echo deadline > /sys/block/sdc/queue/scheduler

но сегодня в процессе репетиции восстановления сервера из резервной копии я наткнулся на ошибку при загрузке копии сервера (связана с различием в конфигурации). Чтобы каждый раз не указывать планировщик для нужных дисков я решил доверить это дело UDEV.

Сначала проверим текущие настройки планировщиков

# cat /sys/block/sd*/queue/scheduler
noop anticipatory deadline [cfq]
noop anticipatory deadline [cfq]
noop anticipatory deadline [cfq]
noop anticipatory deadline [cfq]

В данный момент для всех дисков (2 SSD и 2 HDD) установлен планировщик CFQ. Теперь добавим правило UDEV, которое будет изменять планировщик на DEADLINE для всех non-rotational устройств.

# cat > /etc/udev/rules.d/65-ssd-deadline.rules <<_EOF_
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"
_EOF_
# udevadm control --reload-rules
# udevadm trigger --subsystem-match='block'

Снова проверим настройки планировщиков

# cat /sys/block/sd*/queue/scheduler
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
noop anticipatory deadline [cfq]
noop anticipatory deadline [cfq]

В этот раз для двух первых дисков настройки изменились - это как раз SSD диски. Для обычных HDD дисков остался CFQ.

Как программно перезагрузить зависшее USB устройство

Для резервирования интернет соединения я использую 3G модем Huawei E173, подключенный в USB порт маршрутизатора. Соединение через него всегда поднято в режиме горячего резерва (для переключения на модем достаточно сбросить default route с основного соединения). Но есть одна проблема - периодически модем "зависает" и соединение теряется.

Как правило достаточно перезапустить pppd, но вчера модем перестал реагировать совсем. В логе появились сообщения, которые относятся к проблемам скорее аппаратным.

xhci_hcd 0000:02:00.0: WARN Event TRB for slot 1 ep 4 with no TDs queued?
xhci_hcd 0000:02:00.0: WARN Event TRB for slot 1 ep 4 with no TDs queued?
xhci_hcd 0000:02:00.0: WARN Event TRB for slot 1 ep 4 with no TDs queued?
xhci_hcd 0000:02:00.0: ERROR Transfer event TRB DMA ptr not part of current TD
xhci_hcd 0000:02:00.0: ERROR Transfer event TRB DMA ptr not part of current TD
xhci_hcd 0000:02:00.0: ERROR Transfer event TRB DMA ptr not part of current TD

Перезапуск pppd ничего не дал, похоже модем не отвечает ни на одну команду.

Apr 24 10:02:11 inet chat[6761]: abort on (\nBUSY\r)
Apr 24 10:02:11 inet chat[6761]: abort on (\nERROR\r)
Apr 24 10:02:11 inet chat[6761]: abort on (\nNO ANSWER\r)
Apr 24 10:02:11 inet chat[6761]: abort on (\nNO CARRIER\r)
Apr 24 10:02:11 inet chat[6761]: abort on (\nNO DIALTONE\r)
Apr 24 10:02:11 inet chat[6761]: abort on (\nRINGING\r\n\r\nRINGING\r)
Apr 24 10:02:11 inet chat[6761]: send (^MAT^M)
Apr 24 10:02:11 inet chat[6761]: timeout set to 12 seconds
Apr 24 10:02:11 inet chat[6761]: expect (OK)
Apr 24 10:02:23 inet chat[6761]: alarm
Apr 24 10:02:23 inet chat[6761]: Failed

Попытки переинициализировать модем программно не увенчались успехом, поскольку его устройство (/dev/ttyUSB0) не отвечает на AT команды. Остается только отключить и снова включить модем в порт. Но сначала решил попробовать метод, на который наткнулся недавно в интернете.

Для сброса нужной шины USB нам потребуется скомпилировать бинарник. Чтобы не компилировать его каждый раз снова и пользоваться им на практически любой машине я буду компилировать его статически.

$ wget https://gist.githubusercontent.com/x2q/5124616/raw -O usbreset.c
$ gcc -Wall -static -o usbreset usbreset.c
$ sudo install -o root -g root -m 0755 usbreset /usr/local/sbin
$ lsusb | grep Huawei
Bus 001 Device 002: ID 12d1:1001 Huawei Technologies Co., Ltd. E169/E620/E800 HSDPA Modem
$ sudo usbreset /dev/bus/usb/001/002
Error in ioctl: No such device

Несмотря на ошибку в логе появились записи, свидетельствующие о "перезагрузке" модема.

$ dmesg | tail
usb 1-6: New USB device strings: Mfr=3, Product=2, SerialNumber=0
usb 1-6: Product: HUAWEI Mobile
usb 1-6: Manufacturer: HUAWEI Technology
usb 1-6: configuration #1 chosen from 1 choice
option 1-6:1.0: GSM modem (1-port) converter detected
usb 1-6: GSM modem (1-port) converter now attached to ttyUSB0
option 1-6:1.1: GSM modem (1-port) converter detected
usb 1-6: GSM modem (1-port) converter now attached to ttyUSB1
option 1-6:1.2: GSM modem (1-port) converter detected
usb 1-6: GSM modem (1-port) converter now attached to ttyUSB2

Попробуем подключиться к нему и выполнить несколько AT команд.

$ screen /dev/ttyUSB0 115200
ATZ
OK
ATI
Manufacturer: huawei
Model: E173
Revision: 11.126.16.00.715
IMEI: 861976004215827
+GCAP: +CGSM,+DS,+ES

OK

Модем ожил и теперь можно включать соединение.

Будьте внимательны при обновлении vzctl до версии 4.7

Если вы используете OpenVZ и решили обновить сервер, то не пропустите важное сообщение при обновлении vzctl до версии 4.7.

============================================================================
Due to conntrack impact on venet performance, conntrack need to be disabled
on the host system (it will still work for containers).

Adding the following option to /etc/modprobe.d/openvz.conf:

      options nf_conntrack ip_conntrack_disable_ve0=1

This change will take effect only after the next reboot.

NOTE: IF YOU NEED conntrack functionality, edit /etc/modprobe.d/openvz.conf NOW,
changing =1 to =0. DO NOT REMOVE the line, or it will be re-added!
============================================================================

Начиная с этой версии по-умолчанию отключается conntrack в VE0 (на hardware node). Если ваш файервол полагается на conntrack, то вы рискуете закрыть всем (и себе тоже) доступ на Hardware Node по сети.

Пакеты Midnight Commander для Ubuntu Trusty Tahr

На днях вышла Ubuntu Trusty Tahr (13.04). Сегодня я добавил поддержку этой версии в мой сборщик пакетов для проекта Midnight Commander. На данный момент доступны последние версии stable и nightly.

Как подключить репозитарий указано тут.

Отключение запроса PIN для SIM карты через AT команды

Если вы не отключили защиту SIM через PIN код перед установкой карты в модем, то не стоит расстраиваться, вытаскивать ее и ставить в телефон. Защиту можно отключить используя AT команды модема. В примере PIN код равен "1111", а управляющий порт модема /dev/ttyUSB0. Если у вас другие значения, то замените на свои.

$ screen /dev/ttyUSB0 115200
ATZ
OK
AT+CPIN?
+CPIN: SIM PIN
AT+CPIN="1111"
OK
AT+CLCK="SC",0,"1111"
OK

139905006626448:error:0906D064:PEM routines:PEM_read_bio:bad base64 decode:pem_lib.c:818:

В процессе устранения CVE-2014-0160 дошел до обновления всех сертификатов на серверах. Поскольку уязвимость создает вероятность получения секретного ключа, то нужно сгенерировать сертификат заново.

$ openssl genrsa -out /etc/ssl/private/example.com.key 2048
$ chmod 0400 /etc/ssl/private/example.com.key
$ openssl req -new -out /etc/ssl/certs/example.com.csr -key /etc/ssl/private/example.com.key

Полученный файл example.com.csr нужно подписать у удостоверяющего центра. Мы пользуемся Thawte через посредника и в ответ на повторный выпуск сертификата пришел zip архив

$ unzip -l reissue.zip
Archive:  reissue.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
     1744  2014-04-09 09:56   ServerCertificate.cer
     4815  2014-04-09 09:56   PKCS7.p7b
     1642  2014-04-09 09:56   CACertificate-1.cer
     1540  2014-04-09 09:56   CACertificate-2.cer
---------                     -------
     9741                     4 files

Файлы с расширением CER это сертификат в формате PEM. Перед установкой нового сертификата в веб-сервер проверяю его информацию

$ mkdir ssl-tmp
$ cd ssl-tmp
$ unzip ../reissue.zip
$ openssl x509 -in ServerCertificate.cer -text -noout
unable to load certificate
139905006626448:error:0906D064:PEM routines:PEM_read_bio:bad base64 decode:pem_lib.c:818:

Облом. OpenSSL отказывается читать сертификат, ссылаясь на неверное base64 кодирование. Открываю сертификат в текстовом редакторе и смотрю его глазами. В теле base64 есть пробелы! А ведь пробелов быть не должно... Попробовал сравнить содержимое с предыдущим сертификатом и нашел, что возможно по ошибке "+" заменился на " ". В качестве проверки делаю замену всех пробелов на "+" между строками "-----BEGIN CERTIFICATE-----" и "-----END CERTIFICATE-----".

После замены снова проверяю сертификат

$ openssl x509 -in ServerCertificate.cer -text -noout

В этот раз проверка прошла успешно, повторяю действия для CACertificate-1.cer и CACertificate-2.cer. И проверяю их аналогично. В конце останется только установить новый сертификат на сервере.