вторник, 19 ноября 2019 г.

Apt не хочет качать по https

А вот тут был интересный кейс. Сервер со свежеобновленным Debian 10.2 не хочет качать индексные файлы из репозитория по протоколу https:
Err https://download.docker.com/linux/debian buster Release
  Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.  Could not handshake: Error in the certificate verification. [IP: 205.251.219.17 443]
W: https://download.docker.com/linux/debian/dists/buster/InRelease: No system certificates available. Try installing ca-certificates.
W: https://download.docker.com/linux/debian/dists/buster/Release: No system certificates available. Try installing ca-certificates.
E: The repository 'https://download.docker.com/linux/debian buster Release' does not have a Release file.
E: Failed to download some files
W: Failed to fetch https://download.docker.com/linux/debian/dists/buster/Release: Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.  Could not handshake: Error in the certificate verification. [IP: 205.251.219.17 443]
E: Some index files failed to download. They have been ignored, or old ones used instead.
Проверил ссылку из браузера -- всё ок, на той стороне сертификат валидный.
Значит дело в нашем сервере. Оно и понятно, на других серверах этот же репозиторий работает нормально.

Но ни curl, ни wget не ругается на сертификат, как и openssl s_client.

Более того, подключил еще один проверенный репозиторий по https, на него валятся такие же ошибки.

За пару часов в гугле ничего не нашел. У всех с такой ошибкой какие-то проблемы с корневыми сертификатами и им предлагают произвести стандартные танцы с бубнами вокруг пакета ca-certificates. У меня же с сертификатами всё хорошо, состав и количество совпадают с "рабочими" серверами. Но именно apt не хочет работать по https.
Дело оказалось в правах на каталог /etc/ssl/certs. Кто-то ошибочно выставил на него режим 700, поэтому curl и wget, запущенные от root добрались до корневых сертификатов, а apt из-под непривилегированного пользователя не смог.

А значит решением будет:

# chmod 755 /etc/ssl/certs/

среда, 30 октября 2019 г.

Консольная утилита для управления WordPress

У нас есть сервер, на котором крутятся сайты на WordPress для других отделов. Они их как-то сами наполняют и админят, но, конечно же, обновлять и не думают.
Nginx, PHP, Mysql я им обновлю, а как быть с самими сайтами?

Можно было бы добавить себя в админы каждого сайта, но не всё так просто. На каких-то сайтах локальная аутентификация, на других LDAP, на третьих что-то ещё.

Объединяет их то, что они лежат на одном сервере. Обновить их оказалось довольно просто (имея рутовые права на сервере).

Нужна утилита wp-cli. К сожалению, её нет в официальных репах Debian'а, но эту утилиту можно скачать с её официального сайта (это один файл на php) и положить в любой каталог из переменной path. Если мы хотим, чтобы утилита могла обновлять сама себя, её надо положить в каталог, правами на запись в который должен обладать пользователь www-data (или под кем вы там запускаете web-сервер). Ну тут смотрите сами, снижаем безопасность в угоду удобству, как обычно.

Утилите надо создать каталог с правами на запись, куда она сможет скачивать обновления Вордпресса и плагинов. Он должен лежать в домашнем каталоге пользователя web-сервера, у меня это /var/www и назвать .wp-cli.

Далее, утилиту надо запускать от имени web-сервера, это www-data в Debian по умолчанию.

Например так:

От рута:
# sudo -u www-data bash
Переходим в каталог с первым сайтом:
$ cd /var/www/site1
$ wp core check-update
$ wp core update
$ wp core updatedb
$ wp plugin update --all
Переходим в следующий и повторяем, пока не кончатся сайты. Ну а дальше скрипты для автоматизации, ansible и т.д., но вы это и без меня знаете.

среда, 27 февраля 2019 г.

Создать пользователя в DJANGO через SQL

Понадобилось попасть в админку сайта на django, имя рутовый доступ к серверу. База сайта лежала в локальном sqlite. Генерируем себе пароль с помощью утилиты djpass:
$ ./djpass ololo
Hash: pbkdf2_sha256$120000$nwEK2MXzMCj7$u3ZGMBCbdGC72pNJkh8dZ79pcYbmlGNQCrDXvvG8WuA=
Эту утилиту я поставил в мусорную тестовую виртуальную машину на Debian, дабы не засорять свой комп, а уж тем более сервер, всяким непотребством. Ставится через программу cargo, которая есть в стандартных репах Debian:
# apt install cargo
$ cargo install djpass
Если что, утилита оказывается в каталоге ~/.carbo/bin С хешем наперевес идём в базу. В моём случае, как я уже сказал, это sqlite:
# sqlite3 /path/to/db/file

sqlite> INSERT INTO "auth_user" VALUES(3,"pbkdf2_sha256$120000$nwEK2MXzMCj7$u3ZGMBCbdGC72pNJkh8dZ79pcYbmlGNQCrDXvvG8WuA=
","",1,"megaadmin","","",1,1,"2019-02-27 11:32:20","");
Готово. Далее у меня была внутреняя ошибка 500, но при включенном дебаге выяснил, что просто права к базе были некорректными, nginx не мог до неё добраться.