aary 

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

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

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

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

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-сертификатов и по управлению ограничениями доступа для пользователей.

Результаты

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

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

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 из официального 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

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

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

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 — портативная, с возможностью миграции.

• Поиск: контекстный, с приоритетом доверенного круга, группировкой по источникам, опциональными шлюзами наружу.

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