воскресенье, 24 марта 2019 г.

Проблема с XFCE

Столкнулся на одном из компьютеров со странной проблемой - не удаётся выключить компьютер через меню XFCE:

В открывшемся диалоговом окне выбираем "Выключить":

Кнопка нажимается успешно, но вот дальше ничего не происходит.

Последующие попытки повторить те же действия приводят к ошибке. После нажатия пункта "Выйти" в меню XFCE появляется сообщение об ошибке:

Процитирую надпись с картинки: "Получена ошибка при попытке завершения сеанса. Менеджер сеансов ожидает завершение работы системы. Пожалуйста подождите". Не буду сейчас придираться к грамотности сообщения (Ошибка не получена, а произошла. Ожидает чего? Завершения. "Пожалуйста, подождите").

На всякий случай, приведу также сообщения на английском языке: "Received error while trying to log out. Session manager must be in idle state when requesting a shutdown"

Сколько ни искал в интернете решения проблемы, ничего годного найти не смог. В итоге помогло... Чтение журналов! В домашнем каталоге пользователя есть журнал .xsession-error, в котором моё внимание привлекли две подозрительные строчки:
/etc/xdg/xfce4/xinitrc: 85: /etc/xdg/xfce4/xinitrc: xrdb: not found

** (xfce4-session:4149): CRITICAL **: polkit_unix_process_set_property: assertion 'val != -1' failed
sh: 1: /usr/bin/iceauth: not found
Я поискал, в каких пакетах находятся недостающие файлы xrdb и iceauth:
$ apt-file search xrdb | grep /xrdb$
bash-completion: /usr/share/bash-completion/completions/xrdb
x11-xserver-utils: /usr/bin/xrdb
$ apt-file search iceauth | grep /iceauth$
x11-xserver-utils: /usr/bin/iceauth
Как видно из результатов поиска, оба файла находятся в пакете x11-xserver-utils. Установим недостающий пакет:
# apt-get install x11-xserver-utils
Принудительно перезапустим дисплейный менеджер:
# systemctl restart lightdm
Пробуем выключить компьютер снова - теперь всё получается!

воскресенье, 17 марта 2019 г.

Получение SSL-сертификата от удостоверяющего центра Let's Encrypt в Debian Stretch

В черновиках скопилось некоторое количество готовых статей, которые хотелось ещё чем-то дополнить, из-за чего они и не были опубликованы своевременно. Например, эта статья была написана аж в октябре 2017 года. О некоторых статьях я уже не помню, чем ещё я хотел их дополнить. Про другие помню, но сейчас их доведение до задуманного вида не является для меня приоритетной задачей. Думаю, что лучше опубликовать всё как есть, а дополнять можно уже впоследствии отдельными статьями.

В последние годы администраторы и пользователи интернет всё чаще обращают внимание на безопасность. Увлечение защищёнными версиями протоколов приняло настолько повальный характер, что некоторые начали перегибать палку и требовать наличия сертификатов даже там, где они вроде бы и не нужны. Например, когда я обновлял операционную систему Debian с Jessie на Stretch, то система управления источниками бесперебойного питания NUT стала требовать использования SSL-сертификатов, хотя этот сервис вовсе не публичный и доступен только на локальном петлевом интерфейсе. Многие системные администраторы совсем не против того, чтобы увеличить безопасность своих систем. Одна беда - сертификаты иногда стоят несоразмерно дорого для сервиса, которым пользуются несколько человек. До этого я пользовался бесплатными сертификатами, которые предоставлял удостоверяющий центр StartCom. Однако этот удостоверяющий центр сменил владельцев, которые теперь находятся в Китае.
Не исключаю предвзятости по отношению к этому удостоверяющему центру. Вполне возможно, что он и раньше был не безопасен, но это замалчивали, т.к. владельцы были израильскими, а у США и Израиля довольно доверительные отношения. Теперь же, когда сервис сменил владельца, его безопасностью начали интересоваться особо внимательно. Так или иначе, даже если с сервисом всё в порядке - ему не доверяют компании, разрабатывающие два самых влиятельных браузера, поэтому пользоваться такими сертификатами особого смысла нет, т.к. по качеству они мало чем отличаются от самозаверенных.

В последнее время на слуху новый удостоверяющий центр Let's Encrypt, который был создан как ответ на постоянные проблемы с безопасностью сервисов и высокую цену на сертификаты удостоверяющих центров. Первые новости о его публичной доступности появились ещё в конце 2015 года, до скандалов с StartCom:
[03.12.2015] Некоммерческий удостоверяющий центр Let's Encrypt начал выдачу сертификатов всем желающим.
Начал писать статью о настройке Jabber-сервера Prosody и в процессе написания раздела о настройке SSL решил попробовать новый удостоверяющий центр. Описал процесс получения сертификата, но потом решил, что описание этой процедуры имеет самостоятельную ценность и решил вынести в отдельную статью, которую вы сейчас и читаете.

Получение сертификатов

У сервиса Let's Encrypt нет веб-интерфейса, как у других удостоверяющих центров. Для создания сертификата используется протокол ACME. Протокол этот реализован в боте CertBot, пакет с которым имеется в репозитории Debian Stretch. Установим бота:
# apt-get install certbot
После установки бота, запустим его от имени пользователя root:
# certbot certonly --manual
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel):vladimir@stupin.su

-------------------------------------------------------------------------------
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf. You must agree
in order to register with the ACME server at
https://acme-v01.api.letsencrypt.org/directory
-------------------------------------------------------------------------------
(A)gree/(C)ancel: A
Здесь нас просят ознакомиться с лицензионным соглашением, которое размещается по ссылке https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf С вас как минимум требуется, чтобы вы получали сертификаты только для тех доменов, которыми владеете, а также требуется отзывать сертификаты, если у вас имеются подозрения о взломе ваших серверов или сертификатов. Нажимаем кнопку A, чтобы принять соглашение.
Please enter in your domain name(s) (comma and/or space separated)  (Enter 'c'
to cancel):stupin.su
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for stupin.su

-------------------------------------------------------------------------------
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?
-------------------------------------------------------------------------------
(Y)es/(N)o: Y
Здесь вас предупреждают, что IP-адрес, с которого будет отправлен запрос на получение сертификата, будет сохранён в общедоступный журнал. Если вы запускаете бота не на своём сервере, то подтвердите, что получили на это разрешение владельца. Нажимаем кнопку Y, чтобы подтвердить отправку запроса на получение сертификата.
-------------------------------------------------------------------------------
Make sure your web server displays the following content at
http://stupin.su/.well-known/acme-challenge/VQaUp_Q225nyu_beedJzbDhRHmLt8y7W4dSBrZ4YIt4 before continuing:

VQaUp_Q225nyu_beedJzbDhRHmLt8y7W4dSBrZ4YIt4.AxZB-wyvXtEUAxRRJN5bDGyEo5uDO7aVvEgrJ7PVgoo

If you don't have HTTP server configured, you can run the following
command on the target server (as root):

mkdir -p /tmp/certbot/public_html/.well-known/acme-challenge
cd /tmp/certbot/public_html
printf "%s" VQaUp_Q225nyu_beedJzbDhRHmLt8y7W4dSBrZ4YIt4.AxZB-wyvXtEUAxRRJN5bDGyEo5uDO7aVvEgrJ7PVgoo > .well-known/acme-challenge/VQaUp_Q225nyu_beedJzbDhRHmLt8y7W4dSBrZ4YIt4
# run only once per server:
$(command -v python2 || command -v python2.7 || command -v python2.6) -c \
"import BaseHTTPServer, SimpleHTTPServer; \
s = BaseHTTPServer.HTTPServer(('', 80), SimpleHTTPServer.SimpleHTTPRequestHandler); \
s.serve_forever()" 
-------------------------------------------------------------------------------
Press Enter to Continue
Чтобы подтвердить владение доменом, нас просят разместить по адресу http://stupin.su/.well-known/acme-challenge/VQaUp_Q225nyu_beedJzbDhRHmLt8y7W4dSBrZ4YIt4 следующее содержимое:
VQaUp_Q225nyu_beedJzbDhRHmLt8y7W4dSBrZ4YIt4.AxZB-wyvXtEUAxRRJN5bDGyEo5uDO7aVvEgrJ7PVgoo
Перейдём в корневой каталог документов веб-сервера, создадим необходимые для подтверждения каталоги:
# cd /var/www/
# mkdir -p .well-known/acme-challenge
# cd .well-known/acme-challenge/
Теперь воспользуемся текстовым редактором, создав файл с именем VQaUp_Q225nyu_beedJzbDhRHmLt8y7W4dSBrZ4YIt4 и добавим в него указанное выше содержимое. Теперь нажимаем Enter, чтобы удостоверяющий центр проверил наличие файла и тем самым убедился во владении доменом.
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0000_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0000_csr-certbot.pem

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/stupin.su/fullchain.pem. Your cert will
   expire on 2017-11-04. To obtain a new or tweaked version of this
   certificate in the future, simply run certbot again. To
   non-interactively renew *all* of your certificates, run "certbot
   renew"
 - If you lose your account credentials, you can recover through
   e-mails sent to vladimir@stupin.su.
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le
Готовый сертификат лежит в файле /etc/letsencrypt/live/stupin.su/fullchain.pem и годен до 4 ноября. Если учётная запись будет утрачена, её можно будет восстановить через указанный вами ящик электронной почты. Если понадобится обновить все сертификаты, сделать это можно при помощи одной команды:
# certbot renew
Удалим более не нужные файлы, которые использовались для подтверждения владения доменом:
# cd /var/www/
# rm -R .well-known
Если нужно будет получить ещё один сертификат, это можно сделать точно таким же образом. Единственное отличие будет заключаться в том, что второй раз у вас не будут спрашивать адрес электронной почты.

Дополнительно я бы посоветовал сменить права доступа к приватному ключу сертификата. Лучше чтобы к нему имел доступ только пользователь root или тот пользователь, от имени которого будет работать использующая его программа. Отобрать права у прочих пользователей ко всем приватным ключам можно следующим образом:
# chmod o= /etc/letsencrypt/archive/*/privkey*.pem

Обновление сертификатов

Для беспроблемного дальнейшего обновления сертификатов добавим в файл /etc/letsencrypt/cli.ini следующие настройки:
manual-auth-hook /etc/letsencrypt/authenticator.sh
manual-cleanup-hook /etc/letsencrypt/cleanup.sh
manual-public-ip-logging-ok yes
Эти настройки указывают скрипты, при помощи которых в каталоге веб-сервера сначала размещаются файлы для проверки владения доменом, а затем, после проверки, удаляются из этого каталога. Третья настройка даёт согласие зарегистрировать IP-адрес вашего сервера в журнале удостоверяющего центра, где отмечается информация обо всех выданных сертификатах. В будущем имеется вероятность, что этот журнал станет общественно-доступным и в него можно будет заглянуть, чтобы узнать подробности о выданном кому-либо сертификате.

Первый скрипт /etc/letsencrypt/authenticator.sh содержит внутри себя следующие команды:
#!/bin/sh

mkdir -p /var/www/.well-known/acme-challenge
echo $CERTBOT_VALIDATION > /var/www/.well-known/acme-challenge/$CERTBOT_TOKEN
Второй скрипт /etc/letsencrypt/cleanup.sh содержит внутри себя следующие команды:
#!/bin/sh

rm -f /var/www/.well-known/acme-challenge/$CERTBOT_TOKEN
rmdir /var/www/.well-known/acme-challenge
rmdir /var/www/.well-known
Теперь для обновления сертификатов можно будет воспользоваться одной командой:
# certboot renew
Стоит однако учитывать, что эти скрипты размещают файлы для проверки всегда в одном и том же месте, вне зависимости от домена. Веб-сервер должен выдавать содержимое каталога /var/www/.well-known/acme-challenge/ при обращении по адресу домена к любому документу по ссылке http://<домен>/.well-known/acme-challenge/<имя_файла>

воскресенье, 23 сентября 2018 г.

Сборка RAID-массива на контроллере LSI MegaSAS в Linux

В прошлом я уже писал ряд заметок про RAID-контроллеры семейства LSI MegaSAS - Intel RS2WC040 и Intel RSBL040, которые используются у меня на работе:
Иногда приходится менять диски, подключенные к аппаратным RAID-контроллерам. Замену диска при помощи mfiutil во FreeBSD я уже описывал, а аналогичная задача в Linux решается при помощи утилиты megacli, которая доступна в стороннем репозитории. Процедура замены дисков у меня до автоматизма не доведена, т.к. менять их приходится не часто. Поэтому я завёл для себя страницу в wiki, в которой делал заметки, чтобы не пришлось вспоминать команды и последовательность действий в следующий раз. Несколько раз я исправлял ошибки в заметке и даже дополнил её описанием решения проблемы с добавлением диска, который ранее уже состоял в другом RAID-массиве. Наконец, заметка дозрела до состояния, пригодного к публикации.

Установка утилиты

Установить утилиту megacli в Debian можно из неофициального репозитория HwRAID. Например, чтобы подключить репозиторий в Debian Stretch, нужно добавить в файл /etc/apt/sources.list такую строчку:
deb http://hwraid.le-vert.net/debian stretch main
Установим в систему GPG-ключ для проверки подлинности репозитория при помощи команды:
# wget -O - https://hwraid.le-vert.net/debian/hwraid.le-vert.net.gpg.key | apt-key add -
Теперь можно обновить список пакетов, доступных для установки из репозиториев:
# apt-get update
И установить утилиту mecacli для управления RAID-контроллером:
# apt-get install megacli

Просмотр информации о RAID-контроллере

Чтобы просмотреть модель, серийный номер, настройки RAID-контроллера:
# megacli -AdpAllInfo -aAll

Диагностика

Смотрим список и состояние RAID-массивов в поле Sate:
# megacli -LdInfo -Lall -aALL
Если там Degraded, значит массив развалился. Смотрим, есть ли строчки Firmware state с состоянием Failed:
# megacli -PdList -a0
Если есть, можно посмотреть состояние диск по SMART. Для этого в выводе команды смотрим идентификаторы дисков в поле Device Id. Дальше указывая эти идентификаторы можно увидеть состояние SMART каждого из дисков и определить его серийный номер:
# smartctl -a -d megaraid,4 /dev/sda
# smartctl -a -d megaraid,5 /dev/sda
# smartctl -a -d megaraid,7 /dev/sda
# smartctl -a -d megaraid,6 /dev/sda

Диск исправен - запуск перестроения массива

Если диск исправен, можно попробовать перестроить массив. Для этого находим значения полей Enclosure Device ID и Slot Number у неисправного диска и выполняем для него команду запуска перестроения массива. В примере ниже используются значения 252 и 3:
# megacli -PdRbld -Start -PhysDrv[252:3] -a0
Наблюдать за состоянием перестроения массива можно при помощи команды:
# megacli -PdRbld -ShowProg -PhysDrv [252:3] -a0

Диск неисправен - замена диска

Если диск неисправен, его нужно заменить. Помечаем его как отключенный:
# megacli -PdOffline -PhysDrv [252:3] -a0
Затем - как отсутствующий в массиве:
# megacli -PdMarkMissing -PhysDrv [252:3] -a0
И теперь - как подготовленный к удалению из системы:
# megacli -PdPrpRmv -PhysDrv [252:3] -a0
Неисправный диск можно подсветить светодиодом:
# megacli -PdLocate -start -PhysDrv [252:3] -a0
Если индикация не заработала, можно попробовать починить её при помощи следующей команды:
# megacli -AdpSetProp \{UseDiskActivityforLocate -1\} -aALL
Заменяем диск (в случае SAS это можно сделать на горячую, если по светодиодным индикаторам видно, какой из дисков неактивен).

Когда новый диск вставлен, убираем подсветку светодиодом:
# megacli -PdLocate -stop -PhysDrv [252:3] -a0
После замены диска смотрим, каких дисков не хватает в RAID-массиве:
# megacli -PdGetMissing -a0
                                     
    Adapter 0 - Missing Physical drives

    No.   Array   Row   Size Expected
    0     1       1     428199 MB

Exit Code: 0x00
Вставляем новый диск в пустующее место в массиве:
# megacli -PdReplaceMissing -PhysDrv [252:3] -array1 -row1 -a0
Если диск не вставляется и выводится ошибка следующего вида:
Adapter: 0: Failed to replace Missing PD at Array 1, Row 1.

FW error description: 
 The specified device is in a state that doesn't support the requested command.  

Exit Code: 0x32
То можно проверить текущее состояние прошивки диска:
# megacli -PdInfo -PhysDrv [252:3] -a0
Если в строке Firmware state отображается состояние JBOD, то исправить это состояние можно следующим образом:
# megacli -PdMakeGood -PhysDrv[252:3] -Force -a0
Если же в строке Firmware state отображается состояние Unconfigured(good), Spun Up, но в строке Foreign State отображается состояние Foreign, то надо просканировать наличие дисков, переставленных из других RAID-контроллеров и снять у таких дисков отметку о других контроллерах:
# megacli -CfgForeign -Scan -aALL
# megacli -CfgForeign -Сlear -aALL
Включаем новый диск в работу массива:
# megacli -PdRbld -Start -PhysDrv [252:3] -a0
Посмотреть продвижение процесса перестроения можно так:
# megacli -PdRbld -ShowProg -PhysDrv [252:3] -a0

Подробнее: