Нельзя просто так взять и разобраться в лицензировании продуктов Microsoft

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

Q2 - If I have guests that come into my office an temporarily use a Windows DHCP server to grab an IP address to access the Internet, do they need CALs?

A2 - Yes, they are using a Windows Server service and would need a CAL.

Вот теперь PayPal точно пришел в Беларусь

Новость порадовала. За несколько минут создал новую учетку в paypal и привязал к ней банковскую карту. Надеюсь лавочку не прикроют в скором времени.

В гугле забанен!

Меня в очередной раз забанили в гугле. Раньше хотя бы давали возможность ввести капчу, но сегодня и этого нету.

P.S. Такое часто бывает в сети провайдера АтлантТелеком по выходным и связано с множеством людей, которые сидят за NAT с одного IP. Перейти на Yandex или DuckDuckGo что ли...

Добавление корневого сертификата локального 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 по сети.