суббота, 31 мая 2014 г.

Добавление корневого сертификата локального 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 подключается без лишних вопросов.

вторник, 20 мая 2014 г.

Включение планировщика 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.