Обновил на основном сервере dxdt.blog операционную систему до Debian 12. Обновление, понятно, принесло с собой некоторые минимальные несовместимости (например, в какой-то момент отломился PHP – надеюсь, никто не заметил), но, вроде, сейчас всё работает нормально. Если нет – пишите почтой.

Вчера сайт был несколько часов недоступен, но по другой причине, которая напрямую не связана с обновлением ОС. Вчера проблема возникла с созданием “снапшота” виртуальной машины.

Вообще, я не сторонник “снапшотов”. Я всегда говорю, что “снапшот” – это последнее, на что можно рассчитывать при каких-то сложных работах (восстановление должно происходить не “откатом”, а “перекатом”, говорю я, – но это тема для другой записки; тем более, что я же, – иногда, – шучу в адрес специалистов DevOps, что, мол, “бэкапы – это для трусов”).

Так вот, то, что “снапшот” это последнее, чем следует пользоваться, никак не отменяет того, что сделать “снапшот” не помешает. И есть хорошая практика: перед взятием “снапшота” – остановить саму виртуальную машину. Так я и поступил. Остановил виртуальную машину с веб-сервером dxdt.blog. К сожалению, мне даже не пришла в голову (нездравая) мысль, что “снапшот” всего на несколько десятков гигабайт у хостера может создаваться несколько часов – я к такому не привык, у меня машины “снапшотятся” сильно быстрее. В общем, пока копировался “снапшот” – сервер был недоступен. Но, думаю, это всё не так страшно. Сейчас всё вернул в рабочее состояние.



Комментировать »


Комментировать »

Записка, вышедшая на dxdt (тогда ещё – .ru) почти что ровно пятнадцать лет назад – о том, как важен спутный след и его маскировка: то есть, возмущения в среде, через которую движется некий аппарат, выдают присутствие этого аппарата, и в записке упомянута публикация с описанием того, как специальной конструкцией можно добиться “минимизации” спутного следа. Цитата:

Вот пишут в Physicsworld.com о работе, в которой физики показывают, как с помощью специальной конструкции корпуса судна (там речь о передвижении по поверхности воды) и использования материалов с особыми свойствами можно полностью избавиться от спутного следа, возникающего в результате возмущения среды. Причём, в перспективе, технология работает не только на воде (под водой), но и в воздухе. Основная идея та же, что и в прочих схемах с “невидимостью”: “обтекание” объекта волнами происходит таким образом, что из точек, находящихся на некотором удалении от движущегося объекта, всё выглядит так, как будто никакого объекта и нет.

Занятно, что на Physicsworld.com уже по той ссылке никакой работы нет – там HTTP 404. Но сам сайт при этом продолжает действовать. А публикация сохранилась на Archive.org.



Комментарии (2) »

В продолжение прошлой записки про короткоживущие TLS-сертификаты на dxdt.blog: там было написано, что я перестал отзывать сертификаты для dxdt.blog – так вот, подумав ещё, я всё же добавил отзыв предыдущего сертификата, если успешно выпустился новый. Потому что пока что способ отозвать есть – почему бы его не использовать? Тем более, что это вполне себе обычная ситуация: новый сертификат заменяет старый, для этого даже есть код причины отзыва – Superseded (но см., однако, ниже). Другое дело, что в этих сертификатах для dxdt.blog сейчас одинаковый серверный ключ – это, как бы, переводит основной смысл отзыва в плоскость чистого эксперимента. Но тем не менее.

Let’s Encrypt сейчас предоставляет только один интерфейс для проверки статуса сертификата – списки отозванных сертификатов (CRL-файлы, адреса точек раздачи которых указаны в самом сертификате). От OCSP-респондера давно отказались (и совершенно правильно сделали: OCSP – так себе технология). Собственно, для “сверхкоротких” TLS-сертификатов сейчас вообще допускается отсутствие информации о статусе, то есть, можно и CRL не публиковать. Let’s Encrypt пока что публикуют.

Кстати, немного про устройство раздачи CRL у Let’s Encrypt. Список отозванных сертификатов (или просто “список отзыва”) – это, буквально, удостоверенный подписью список серийных номеров сертификатов, выпущенных данным Удовтоверяющим Центром (УЦ), которые отозваны (иногда – с указанием причины отзыва). Так как сертификатов Let’s Encrypt выпускает много (“много” – это мягко сказано), то можно ожидать, что и списки отозванных сертификатов будут быстро “пухнуть”.

На практике это не всегда так – сертификатов отзывается мало, потому что, вообще говоря, отзыв сертификата – не считается штатным событием. (Но, тем не менее, я таки стал отзывать каждый короткоживущий сертификат, до истечения его срока действия – но то больше в качестве эксперимента.) Всё же, чтобы, видимо, как-то подготовиться к потенциальному “распуханию” списков отзыва, Let’s Encrypt использует некий “шардинг” – CRL для одного УЦ нарезаны на несколько файлов (судя по всему, на 128): например, есть точка раздачи по адресу http://ye1.c.lencr.org/108.crl, а есть и http://ye1.c.lencr.org/18.crl, и 10.crl и т.д., думаю, схема именования ясна. Это всё CRL от УЦ YE1 (как видно и по имени хоста). Конкретный адрес, с разным “фрагментом” CRL, пишется в конкретный оконечный сертификат. Например, сейчас в сертификате на dxdt.blog указана точка http://ye2.c.lencr.org/103.crl.

Отзывать сертификат можно при помощи ACME – там есть специальный интерфейс. ACME вообще предлагает несколько способов отзыва. Понятно, что для отзыва – нужно как-то минимально подтвердить связь отзывающего аккаунта либо с сертификатом, либо с именем в сертификате. Иначе можно будет отзывать чужие сертификаты.

В ACME предусмотрено три основных способа такого “связывания”:
1) через ACME-аккаунт – то есть, запросить отзыв может тот же аккаунт, под которым отзываемый сертификат был получен от УЦ;
2) через секретный ключ от открытого, указанного в сертификате – то есть, любой аккаунт может отозвать сертификат, если запрос подписан секретным ключом от сертификата (это понятный и самый строгий механизм: если секретный ключ от сертификата скомпрометирован, то единственное, где подписи от этого ключа ещё можно доверять, это запрос на отзыв соответствующего сертификата);
3) через подтверждение права управления именем (DCV) – если ACME-аккаунт подтвердил, что управляет именем, указанным в сертификате, то этот аккаунт может отозвать любой сертификат, выпущенный УЦ для подтверждённого имени; тоже логичное решение – сторона, фактически управляющая доменом (или IP-адресом), должна иметь возможность отозвать “прошлые” или “старые” сертификаты.

Заметьте, кстати, что третий метод позволяет отозвать любой сертификат, где единственное подтверждённое имя указано в списке имён (то есть, можно отозвать сертификаты, в которых есть ещё какие-то другие имена/адреса в SAN).

Я сейчас отзываю “замещённые” сертификаты dxdt.blog просто тем же ACME-аккаунтом.



Комментировать »

Вот уже месяц сайт dxdt.blog работает на “короткоживущих” TLS-сертификатах Let’s Encrypt. Эти сертификаты валидны, примерно, шесть с половиной дней (160 часов). Соответственно, новые сертификаты заказывает автомат через API ACME (утилита certbot, в данном случае), с периодичностью один раз в двое суток.

Если новый сертификат удалось получить, то он устанавливается на веб-сервер (другим простым скриптом), если не удалось, то остаётся старый сертификат. Об изменении статуса, о попытках заказа сертификата – робот отправляет мне письмо. Заметьте, кстати, что в ACME нет такого понятия, как “продление сертификата” – нужно просто заказывать новый сертификат, вместо старого. Я несколько раз подобные “старые” сертификаты, после получения нового, даже отзывал (есть специальный статус для причины отзыва: Superseded), но сейчас решил оставлять без отзыва.

То есть, в принципе, всё сделано типовым способом и пока что работает нормально. Продолжаем наблюдать.



Комментарии (3) »

Добавил на страницу с избранными записками ещё пять:

Таким образом, раздел “Избранное” добрался до 2026 года: я туда ссылки выкладываю периодически и, обычно, с заметной задержкой – нужно же накопить записки, чтобы среди них выбирать. Сейчас на странице избранных – ссылки на 338 записок, выходивших в разные годы. Это чуть меньше 10% от записок на сайте. Первая в списке – записка про роллероны, 2006 год, двадцать лет назад: “роллерон – элементарный по устройству и поэтому сверхэффективный активный стабилизатор вращения вокруг продольной оси (по крену)”. Там довольно подробно, с картинками – почитайте, если не видели.



Комментировать »


Комментировать »

Перевёл, в соответствии с современными тенденциями, dxdt.blog на “короткие” TLS-сертификаты Let’s Encrypt, со сроком действия шесть дней (плюс-минус). Но секретный ключ пока оставил специально подобранный. Посмотрим, как оно будет работать.



Комментировать »


Комментарии (2) »

Пару месяцев назад я заменил на dxdt.blog основой домен: вместо .ru стало .blog. Пока что проблема с заменой локальных ссылок остаётся: нужно добраться до доступных в БД сервера гиперссылок, которые указывают на dxdt.ru (по историческим причинам), и заменить их на соответствующие внутри dxdt.blog. (Пока что всё работает потому, что на dxdt.ru есть HTTP-редирект.)

Но есть и проблема другого рода: непонятно, что делать с использованием dxdt.ru в качестве названия данного сайта – я сайт выпускаю двадцать два года, и не просто привык писать “на dxdt.ru”, но обороты с “dxdt.ru” тут используются едва ли не повсеместно, и без всяких ссылок. Например: “Публикации dxdt.ru в 2023 году”. И вот как тут быть – пока не придумал: в том смысле, что писать ли теперь в новых записках “dxdt.blog” или уж просто “dxdt”. (Само название навеяно дифференциалами записи производной: dx/dt, а не дифференциалами в записи интеграла, как иногда думают. Но это не очень помогает.)



Комментировать »

Если вы вдруг регулярно используете форму логина на dxdt.blog, то, пожалуйста, учитывайте, что после нескольких неудачных попыток ввода пароля (выполненных в течение короткого времени) IP-адрес вашего клиента может быть заблокирован на сервере, обычно, на сутки или около того. Блокирование по IP-адресу реализуется до веб-сервера, а это означает, что и на сайт не получится зайти. (Хуже того, если кто-то с вами использует общий внешний IP-адрес, за NAT, то заблокирует всех – избирательности там никакой нет. Но, думаю, поскольку посещаемость реальными пользователями крайне мала – такое совпадение вряд ли возможно: тем не менее, конечно, тоже вариант из серии “навредить коллегам из одной и той же офисной сети”.) Это всё вынужденные меры – к сожалению, опять случился какой-то массовый набег ботов, перебирающих логины десятками в секунду.



Комментировать »