aary

Собрал Heritrix 3 через GitLab CI

aary — Fri, 15 May 2026 04:08:16 +0000

Немало времени на это потратил. И на перенастройку самого Heritrix3. Оказалось, что нельзя пытаться заблокировать скачивание robots.txt, потому что это обязательный ритуал у Heritrix3, он их с каждого сайта качает первыми.

В этот раз HEAD/master (3.14.1+), а не 3.10 как в прошлый. Впрочем, разница незаметна. Теперь контейнеры делаются через Dockerfile + docker-compose.yml

Предыдущая запись была 9 апреля, эта 15 мая. Получается, что больше месяца времени на это потратил.

Попробовал создавать БД при помощи Liquibase 5.0.2

aary — Thu, 9 Apr 2026 20:45:32 +0000

Технический отчёт за сегодня

1. Настройка развёртывания приложения

Устранена ошибка сборки, связанная с несуществующей версией родительского POM Spring Boot.
Настроен Tomcat Manager API для удалённого деплоя WAR-файла через HTTP-запросы.
Решена проблема доступа к Manager API (403), вызванная ограничениями по IP в конфигурации контекста Tomcat.
Создан скрипт предварительной инициализации контейнера для копирования стандартной конфигурации Tomcat и веб-приложения Manager.

2. Подключение к базе данных

Настроена сетевая связанность между Docker-контейнером Tomcat и сервером PostgreSQL на хосте.
Исправлены синтаксические ошибки в конфигурации pg_hba.conf, приводившие к отказу в подключении.
Зафиксирована подсеть Docker в compose.yaml для обеспечения стабильного IP-адреса контейнера и корректной аутентификации в БД.

3. Управление схемой базы данных

Подключена и настроена миграционная система Liquibase.
Созданы файлы миграций для автоматического развёртывания таблиц пользователей и ролей.
Реализована проверка актуальности схемы БД при запуске приложения с перенаправлением на инструкции по обновлению в случае несоответствия.
Добавлено логирование статуса выполнения миграций.

4. Система аутентификации и авторизации

Настроена Spring Security с хранением учётных записей в базе данных PostgreSQL.
Реализована публичная страница регистрации новых пользователей.
Создана административная панель с возможностью просмотра списка пользователей и блокировки/разблокировки учётных записей.
Реализовано автоматическое создание учётной записи администратора при первом запуске либо через веб-форму мастера установки, либо через переменные окружения.

5. Мастер первоначальной настройки

Разработан контроллер, выполняющий проверку готовности окружения (наличие БД, версия СУБД, состояние схемы, наличие администратора).
Создан набор информационных страниц с пошаговыми инструкциями для устранения типовых проблем (отсутствие подключения к БД, необходимость обновления СУБД, запуск миграций и др.).
Обеспечено блокирование доступа к страницам мастера после завершения настройки.

6. Доработка интерфейса и навигации

Скорректированы ссылки в шаблонах для корректной работы с контекстом приложения.
Устранены ошибки в Thymeleaf-выражениях, вызывавшие исключения при отсутствии активного профиля Spring.
Актуализировано содержимое главной страницы в соответствии с предметной областью.

7. Оптимизация и диагностика

Выявлена и решена проблема длительного запуска Tomcat, связанная со сканированием TLD в JAR-файлах.
Добавлены инструкции по точечному отключению сканирования TLD через контекстный XML-файл.
Рассмотрены рекомендации по улучшению аутентификации в PostgreSQL с использованием SSL-сертификатов и по управлению ограничениями доступа для пользователей.

Результаты

Приложение успешно развёртывается и работает в целевой среде.
Обеспечена возможность самостоятельной настройки окружения администратором без ручного вмешательства в конфигурационные файлы.
Реализован базовый функционал управления пользователями и ролями.

Настроил Heritrix 3.10.0 и OpenWayback

aary — Tue, 7 Apr 2026 20:33:21 +0000

Отчёт о настройке системы веб-архивации

1. Цель работы

Настроить полный цикл сбора и последующего воспроизведения веб-контента:

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

2. Используемые компоненты

Краулер – программа для сбора веб-страниц и файлов.
Система воспроизведения архивов – для просмотра сохранённых копий.
Контейнеризация – для изолированного запуска компонентов на выделенном сервере.
Рабочая станция – для подготовки конфигураций и анализа логов.

3. Выполненные этапы

3.1. Развёртывание и начальная настройка

Краулер и система воспроизведения запущены в отдельных контейнерах на серверной машине.
Настроен общий том (директория) для обмена собранными архивными файлами между краулером и системой воспроизведения.
Организована сетевая доступность между компонентами.

3.2. Настройка краулера (базовый режим)

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

3.3. Организация рекурсивного обхода сайта

Изначально краулер скачивал только главную страницу и не переходил по внутренним ссылкам.
Путём корректировки правил обхода («scope») удалось настроить бесконечную глубину перехода по ссылкам внутри целевого сайта.
Достигнуто стабильное скачивание сотен внутренних страниц (количество обработанных URL выросло с единиц до тысяч).

3.4. Ограничение области сканирования

В конфигурацию добавлены правила, запрещающие переход на посторонние домены по обычным гиперссылкам.
Это предотвратило «уход» краулера во внешний интернет и позволило сфокусироваться на целевом сайте.

3.5. Разрешение внешних ресурсов (стили, скрипты, картинки)

Обнаружено, что при ограничении доменов перестали скачиваться необходимые элементы оформления (CSS, JavaScript, изображения), которые физически расположены на других сайтах.
Разработана комбинация правил:
- Список разрешённых доменов для таких ресурсов задан в отдельном файле.
- Включена проверка «родительской страницы» – внешний ресурс скачивается только если на него есть ссылка с уже принятой страницы целевого сайта.
В результате стили и скрипты стали корректно сохраняться в архив, что обеспечивает правильное отображение страниц при воспроизведении.

3.6. Настройка скачивания файлов (книг, документов)

В конфигурацию добавлено правило, принимающее любые ссылки на файлы с типичными расширениями (PDF, EPUB, FB2, DJVU, DOC и др.) независимо от их домена.
Это позволило автоматически собирать все книжные и архивные файлы, на которые есть ссылки со страниц целевого сайта.

3.7. Отладка синтаксиса правил

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

3.8. Проверка целостности данных

Выполнен анализ логов краулера, подтверждающий, что скачиваются как страницы целевого сайта, так и внешние стили, скрипты, а также файлы книг.
Через интерфейс системы воспроизведения подтверждена возможность просмотра сохранённых страниц (со стилями) и доступа к скачанным файлам.

4. Достигнутые результаты

Стабильная работа краулера: система запускается, обрабатывает тысячи URL, не «падает» и не уходит на посторонние сайты.
Полное воспроизведение страниц: архивные копии отображаются с оригинальными стилями и оформлением.
Автоматический сбор внешних файлов: все ссылки на книги, документы и архивы, встречающиеся на целевых страницах, сохраняются в архив.
Гибкая настройка: правила фильтрации легко дополнять новыми типами файлов или разрешёнными доменами.
Прозрачность работы: все действия логируются, что позволяет отслеживать поведение краулера и выявлять возможные проблемы.

5. Замечания и рекомендации

Для обеспечения полноты архива периодически следует проверять, не появились ли на сайте ссылки на новые типы ресурсов (например, аудио, видео), и при необходимости расширять список разрешённых расширений.
При значительном росте объёма архива рекомендуется рассмотреть использование внешнего индексатора (например, CDX-сервера) для ускорения поиска и масштабирования.
В случае изменения структуры внешних ресурсов (смена домена CDN) потребуется обновить список разрешённых доменов.
Все конфигурационные файлы и сценарии запуска целесообразно хранить в системе контроля версий для воспроизводимости.

6. Вывод

В результате проделанной работы создана полностью функционирующая система веб-архивации, которая:

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

Настройки могут быть повторно использованы для любых других сайтов с минимальными правками (замена целевого домена и, при необходимости, списка внешних ресурсов).

Установил/настроил Apache Archiva 2.2.10

aary — Fri, 3 Apr 2026 07:04:08 +0000

✅ Сборка из исходников

Успешно выполнена полная сборка Apache Archiva 2.2.10 из официального Git-репозитория по релизному тегу
Сгенерирован целевой артефакт: archiva-webapp-2.2.10.war
Все 68 модулей проекта прошли компиляцию и тестирование зависимостей без критических сбоев
Настроено стабильное разрешение артефактов через внутренний Maven-репозиторий

✅ Исправление JavaUtils (совместимость с современными JRE)

Выявлена причина падений персистентного слоя: устаревший парсер версий в org.jpox.util.JavaUtils
Переписана логика сравнения версий: устранено затенение переменных, добавлена корректная обработка формата major.minor.patch
Патч применён к библиотеке JPOX 1.1.9, пересобран и опубликован в локальном репозитории
Обеспечена стабильная работа JDO-слоя на актуальных версиях Java (17+)

✅ Настройка mail.jar

Устранены конфликты класслоадеров: почтовая библиотека вынесена в общий classpath сервера приложений
Настроен JNDI-ресурс javax.mail.Session для корректной работы почтовых уведомлений Archiva
Обеспечена совместимость с современными API активации и предотвращён дублирующий класс-лоадинг из WEB-INF

✅ Конфигурация Tomcat 9 и деплой через Manager API

Развёрнут и оптимизирован Tomcat 9 с настройкой пулов соединений и политик безопасности
Сконфигурированы JNDI-ресурсы для подключения к PostgreSQL и инициализации контекста приложения
Освоен удалённый деплой через Tomcat Manager API:
- Настроен безопасный доступ к управляющему REST-интерфейсу
- Реализована автоматическая выгрузка, обновление и откат WAR-артефактов без ручного вмешательства
- Интегрирована проверка статуса развёртывания и логирование операций деплоя
- Процесс полностью автоматизирован и готов к интеграции с CI/CD-конвейерами

✅ Настройка сборочного и клиентского окружения

Подготовлена стандартизированная среда разработки: JDK, Maven, Git, системные зависимости
Настроен защищённый канал передачи артефактов между сборочным узлом и сервером приложений
Документирован полный цикл поставки: от клонирования кода до рабочего экземпляра в production-подобной среде
Обеспечена полная воспроизводимость процесса на любых совместимых хостах

📋 Итоговые артефакты и готовность

Сборка:
  - Исходный код: официальный релизный тег 2.2.10
  - Патч JPOX: применён, собран и зафиксирован в артефакторее
  - WAR-файл: archiva-webapp-2.2.10.war (готов к публикации)

Инфраструктура:
  - Сервер приложений: Tomcat 9 с настроенными JNDI-ресурсами
  - СУБД: PostgreSQL с выделенной схемой и пользователем для Archiva
  - Деплой: автоматизирован через Tomcat Manager REST API

🎯 Готовность к следующему этапу

Работает автоматический деплой актуальной сборки через Manager API
Настроен веб-интерфейс, аутентификации и управления репозиториями
Протестирована интеграция с внешними хранилищами и системами сборки
Настройкы политики хранения, резервного копирования и мониторинга

Поставил TightBlog

aary — Sat, 28 Mar 2026 04:40:31 +0000

1. Технические достижения

Запуск TightBlog 4.2.0 на Java 25, PostgreSQL с SSL, исправлены проблемы:
- Десериализация пароля: @JsonProperty перенесены на сеттеры в UserCredentials.java.
- Схема БД: password_hash в weblogger_user снят NOT NULL (двухэтапное сохранение: INSERT с NULL → UPDATE с хешем). Также исправлены date_updated и publish_time в weblog_entry.
- Фиды (Atom): исправлен шаблон entries-atom.html:37 (замена updateTime на dateUpdated).
- Добавлен заголовок Content-Disposition: inline для отображения в браузере.
Роутинг работает: /aary/feed перенаправляется на /tb-ui/rendering/feed/aary через RequestMappingFilter.
Feedbro (расширение Firefox) успешно читает локальный фид, решая проблему внешней валидации.

2. Понимание архитектуры TightBlog

Таблица user_weblog_role была переименована из roller_permission в 2015 году, семантика изменена с «права» на «роль». Это наследие Roller, но TightBlog упростил модель.
Миграции БД перешли от Velocity-генерации к прямым SQL-файлам (Flyway). Это снизило универсальность (только PostgreSQL), но повысило прозрачность и управляемость.
В TightBlog несколько блогов на пользователя поддерживаются, хотя в UI Roller эта функция могла отсутствовать.

3. Ключевые концепции, выработанные в диалоге

Плоские категории vs теги: категории — рубрикация, теги — кросс-тематический поиск. В TightBlog категории не иерархичны.
Фиды: Atom 1.0 + JSON Feed + ActivityPub (последние — для гибкости). Обнаружение фидов через <link rel="alternate">.
Мультиязычность в фидах возможна через отдельные фиды по языкам или через атрибут xml:lang.
Поиск: без ИИ — использовать обратный индекс, ранжирование по доверенному кругу (организации, подписки), группировку по источникам, уточняющие вопросы.
Приватность и обнаружение: нужен баланс между «кругами доверия» и шлюзами наружу. Организация как единица доверия может сертифицировать ключи, управлять доступом, модерацией.
Теги как сообщества: теги становятся точками входа, имеют свои фиды, модерацию, могут быть scoped по организациям.

4. Уроки из истории

«Мой Круг» показал, что неявные круги друзей сложны в UX и не обеспечивают рост. Ваша модель «Планет» с явным членством и уставом может быть понятнее.
Провалы XMPP, Matrix, RetroShare связаны с тем, что они решали технические задачи, забывая о массовом пользователе: сложный старт, отсутствие обнаружения, привязка к серверу, метаданные открыты.
Успешные системы (Email, DNS) работают потому, что владельцы идентичностей заинтересованы поддерживать свои записи.

5. Предложения для будущего движка

Прогрессивная децентрализация: начать с централизованного приложения, затем добавить свой домен, федерацию, P2P.
Организация как КА (центр сертификации): выдаёт сертификаты участникам, публикует каталог, управляет модерацией.
Теги как службы: каждый тег может иметь правила модерации, фид, уровень доступа (публичный/только для участников).
Идентичность: did:web:org:user — портативная, с возможностью миграции.
Поиск: контекстный, с приоритетом доверенного круга, группировкой по источникам, опциональными шлюзами наружу.

Место для публикации текстов

aary — Thu, 19 Mar 2026 16:20:49 +0000

Здесь я буду писать свои мысли. Пока, наверное, на тему создания "схемы технологических работ". Можно подписаться (если есть чем читать подписки).