Устранение неполадок в DC CMS
В этой статье вы узнаете, какие проблемы могут возникнуть при работе с DC CMS и как их решить:
- проблемы с поиском
- проблемы с публикацией
- проблемы с CMS Deployer
- проблемы с SSH Key
- проблемы с SSL Handshake
Проблемы с поиском 
Как работает поиск
DC CMS использует ElasticSearch в качестве вспомогательной поисковой системы. CMS Deployer индексирует содержимое и обновляет ElasticSearch с учетом последних изменений. CMS Engine использует ElasticSearch для выполнения поисковых запросов.
Процесс индексирования
1. Авторы создают или обновляют контент в CMS Studio.
2. CMS Studio публикует контент.
3. CMS Deployer отслеживает изменения в конкретном целевом объекте (который представляет собой комбинацию сайта/окружения). Затем:
- На этапе обновления предпросмотра CMS Deployer проводит проверку изменений в песочнице (sandbox). Он сравнивает файлы между последним коммитом Git, обработанным им, и последним коммитом в песочнице (sandbox). Если есть какие-то изменения, CMS Deployer разрешает их.
- При публикации CMS Studio перемещает эти разрешенные изменения в опубликованное состояние. Когда необходимо доставить эти изменения, CMS Deployer извлекает их из опубликованного состояния.
4. Процессор цели в CMS Deployer отправляет запрос на поиск с использованием XML или контента для индексации.
Процесс запроса
1. Конечный пользователь отправляет запрос в CMS Engine.
2. Компоненты CMS Engine отправляют запрос на поиск, где к запросу будут добавлены фильтры, после чего он будет выполнен.
Места, где могут возникнуть проблемы с поисковым индексом
- Коммуникация между CMS Studio и CMS Deployer
- CMS Studio будет уведомлять CMS Deployer при изменении контента
- Убедитесь, что CMS Deployer активно извлекает изменения
- Если CMS Deployer не получает обновления, проверьте сетевое соединение и порты
- Коммуникация между DC CMS Deployer и ElasticSearch
- CMS Deployer имеет цель с процессором поиска
- Убедитесь, что процессор правильно настроен на соответствующие HOST и PORT для ElasticSearch
- Коммуникация между DC CMS Engine и ElasticSearch
- CMS Engine настроен на взаимодействие с ElasticSearch
- Убедитесь, что конфигурация CMS Engine включает точные параметры HOST и PORT для беспрепятственного взаимодействия с ElasticSearch
Проверка логов
Чтобы выяснить, какая из возможных ошибок, описанных в предыдущем разделе, произошла, вам следует просмотреть следующие файлы логов для каждого из компонентов:
| Компонент | Файл логов |
|---|---|
| CMS Studio | CMS/logs/tomcat/catalina.out |
| CMS Deployer | CMS/logs/deployer/deployer.outCMS/logs/deployer/deployer-general.logCMS/logs/deployer/{target}-{env}.log |
| CMS Engine | CMS/logs/tomcat/catalina.out |
Настройка портов деплоера и поиска
Настройка CMS Deployer и Search port происходит с помощью переменных окружения:
export DEPLOYER_PORT=${DEPLOYER_PORT:="9191"}
export SEARCH_HOST=${SEARCH_HOST:="localhost"}
export SEARCH_PORT=${SEARCH_PORT:="9201"}
Проблемы с публикацией
Если публикация завершена неудачно, вот несколько вещей, которые могут помочь отследить причину проблемы с публикацией.
Проверка очереди публикации
Чтобы посмотреть очередь публикации материалов в CMS Studio:
1. Нажмите на Инструменты сайта.
2. Перейдите в Публикация и проскролльте вниз до блока Очередь публикации.
Дополнительные сведения о публикации контента можно найти здесь.
Проблемы при перемещении проектов по диску
При переносе проектов в рамках диска существует риск сбоя при публикации. Это связано с тем, что связь или ссылка между опубликованным (published) репозиторием и репозиторием песочницы (sandbox) может стать недействительной после перемещения. Для решения этой проблемы необходимо обновить ссылку между опубликованным (published) репозиторием и репозиторием песочницы (sandbox). Это гарантирует восстановление связи, обеспечивает успешную публикацию и предотвращает возможные сбои в ходе рабочего процесса проекта.
Как правило, конфигурацию для published репозитория можно найти в файле path_to_published_repo/published/.git/config, а ссылка на sandbox может выглядеть следующим образом:
[remote "origin"]
url = ../sandbox
fetch = +refs/heads/*:refs/remotes/origin/*
Иногда конфигурация выглядит так:
[remote "origin"]
url = /my/absolute/path/to/cms_install/cms-auth-env/bin/../data/repos/sites/mysite/sandbox
fetch = +refs/heads/*:refs/remotes/origin/*
Чтобы вручную устранить проблему с конфигурацией, установите значение url как относительный путь между опубликованным репозиторием (published) и репозиторием песочницы (sandbox) (по умолчанию ../sandbox), либо укажите его как абсолютный путь к репозиторию песочницы (sandbox).
Проблемы с CMS Deployer
Неизвестный ключ хоста
При настройке целевого Deployer-а для подключения к удаленному хосту через SSH вы можете столкнуться со следующей ошибкой:
com.jcraft.jsch.JSchException: UnknownHostKey: SERVER_NAME. RSA key fingerprint is 50:db:75:ba:11:2f:43:c9:ab:14:40:6d:7f:a1:ee:e3
Обычно это указывает на то, что ключ хоста SSH, сохраненный в файле known_hosts для удаленного сервера, имеет формат ECDSA, а не RSA, который требуется деплоером. Чтобы устранить эту проблему, выполните следующие шаги:
-
Удалите файл ~/.ssh/known_hosts для пользователя, использующего CMS Deployer.
-
Восстановите соединение с удаленным сервером, используя следующую команду для добавления ключа RSA:
ssh -o HostKeyAlgorithms=ssh-rsa SERVER_NAME.
Ошибки Git
Если папка published в установке авторской системы сталкивается с повреждением или проблемами, связанными с Git, которые требуют ручного вмешательства, и CMS Deployer в системе Delivery продолжает извлекать данные из этой скомпрометированной папки, существует высокая вероятность того, что репозиторий delivery может столкнуться с ошибками при извлечении/слиянии. Если такие ошибки появляются в журнале логов, после исправления опубликованного репозитория authoring вы можете выполнить git reset --hard в репозитории delivery. Это действие сбрасывает репозиторий до последнего успешного коммита, заставляя CMS Deployer извлекать изменения заново из репозитория authoring. Кроме того, можно сброситься до конкретного коммита, используя git reset --hard <commit-hash>.
Другая проблема, с которой вы можете столкнуться, - это ошибки во время выполнения GitDiffProcessor CMS Deployer-ом. Эти ошибки указывают на сбой при расчете изменений между последним обработанным коммитом и последним извлеченным коммитом. Чтобы устранить это, перейдите в папку data/deployer/processed-commits и найдите файл .commit, соответствующий сайту. Если вы знаете хэш последнего правильно обработанного коммита, обновите значение в файле. CMS Deployer затем автоматически обработает изменения с этого коммита до последнего. В случае, если хэш неизвестен, вы можете удалить файл, заставив CMS Deployer повторно обрабатывать с начального коммита. Однако будьте осторожны, так как это обычно приводит к повторной обработке и переиндексации всех файлов.
Истечение времени ожидания соединения
Если CMS Deployer не может клонировать удаленный репозиторий и в логах появляется ошибка, подобная приведенной ниже:
org.eclipse.jgit.errors.TransportException: ssh://jdoe@authoring-server/path/to/repo: Connection timed out (Connection timed out)
at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:159)
at org.eclipse.jgit.transport.SshTransport.getSession(SshTransport.java:137)
at org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.<init>(TransportGitSsh.java:274)
at org.eclipse.jgit.transport.TransportGitSsh.openFetch(TransportGitSsh.java:169)
at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1236)
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:213)
... 15 common frames omitted
попробуйте выполнить ручное клонирование с использованием командной строки: git clone ssh://jdoe@authoring-server/path/to/repo
Если ручное клонирование успешно, высока вероятность наличия прокси между серверами. На данный момент CMS Deployer не обладает возможностью устанавливать соединения через прокси, но в будущем обновлении может появиться поддержка этой функции.
Проблемы с SSH Key
Неизвестный хост SSH
При настройке целевого объекта CMS Deployer-а для подключения к удаленному хосту через SSH вы можете столкнуться со следующей ошибкой:
Caused by: org.apache.sshd.common.SshException: Server key did not validate
Обычно это означает, что сервер отсутствует в файле known_host. Чтобы исправить это, выполните следующее:
ssh-keyscan {server url} >> cms-authoring/data/ssh/known_hosts
Чтобы проверить настройку SSH, выполните следующее:
ssh -F cms-authoring/data/ssh/config -o UserKnownHostsFile=cms-authoring/data/ssh/known_hosts -T {server url}
Удаленный репозиторий не найден: ошибка USERAUTH
Вот ещё одна ошибка, с которой вы можете столкнуться в логах при создании сайта с ссылкой на удаленный репозиторий, используя SSH-ключи:
org.apache.sshd.common.SshException: USERAUTH fail
Это может указывать на то, что была установлена фраза-пароль для SSH-ключей. В настоящее время DC CMS не поддерживает использование фразы-пароля с SSH-ключами. Для устранения этой проблемы удалите фразу-пароль, связанную с SSH-ключом.
Есть несколько способов удаления фразы-пароля из SSH-ключа:
- Удалите ваш текущий ключ и сгенерируйте новый ключ без фразы-пароля.
ИЛИ
- Выполните следующую команду:
$ ssh-keygen -p
Эта команда попросит вас ввести расположение файла ключа (по умолчанию CMS_HOME/data/ssh), старую фразу-пароль и новую фразу-пароль (оставьте поле пустым для отсутствия фразы-пароля).
Проблемы с SSL Handshake
Начиная с версии JVM 11.0.11, поддержка TLS версии 1.1 и более ранних версий по умолчанию отключена, как указано в примечаниях к выпуску JDK 11 в разделе security-libs/javax.net.ssl.
Если вы столкнетесь со следующей ошибкой в вашем приложении:
Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
at sun.security.ssl.HandshakeContext.<init>(HandshakeContext.java:171) ~[?:1.8.0_292]
at sun.security.ssl.ClientHandshakeContext.<init>(ClientHandshakeContext.java:98) ~[?:1.8.0_292]
at sun.security.ssl.TransportContext.kickstart(TransportContext.java:220) ~[?:1.8.0_292]
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:428) ~[?:1.8.0_292]
at com.mysql.cj.protocol.ExportControlled.performTlsHandshake(ExportControlled.java:317) ~[mysql-connector-java-8.0.23.jar:8.0.23]
at com.mysql.cj.protocol.StandardSocketFactory.performTlsHandshake(StandardSocketFactory.java:188) ~[mysql-connector-java-8.0.23.jar:8.0.23]
at com.mysql.cj.protocol.a.NativeSocketConnection.performTlsHandshake(NativeSocketConnection.java:97) ~[mysql-connector-java-8.0.23.jar:8.0.23]
at com.mysql.cj.protocol.a.NativeProtocol.negotiateSSLConnection(NativeProtocol.java:333) ~[mysql-connector-java-8.0.23.jar:8.0.23]
at com.mysql.cj.protocol.a.NativeAuthenticationProvider.connect(NativeAuthenticationProvider.java:167) ~[mysql-connector-java-8.0.23.jar:8.0.23]
at com.mysql.cj.protocol.a.NativeProtocol.connect(NativeProtocol.java:1350) ~[mysql-connector-java-8.0.23.jar:8.0.23]
at com.mysql.cj.NativeSession.connect(NativeSession.java:157) ~[mysql-connector-java-8.0.23.jar:8.0.23]
at com.mysql.cj.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:953) ~[mysql-connector-java-8.0.23.jar:8.0.23]
at com.mysql.cj.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:823) ~[mysql-connector-java-8.0.23.jar:8.0.23]
... 173 more
это указывает на то, что ваше приложение устанавливает соединение с версией, предшествующей TLSv1.2.
Обратитесь к документации библиотеки, ответственной за соединение, чтобы определить, есть ли метод обеспечить использование TLSv1.2 или более высокой версии (например, при использовании драйвера JDBC для MySQL вы можете задать это, добавив параметр enabledTLSProtocols=TLSv1.2 к строке подключения).
Если необходимо использовать TLSv1 или TLSv1.1, вы можете включить эти отключенные версии, удалив "TLSv1" и/или "TLSv1.1" из свойства безопасности jdk.tls.disabledAlgorithms в файле конфигурации java.security.
Рассмотрим пример повторного включения TLSv1 и TLSv1.1:
1. Найдите файл java.security в JDK_INSTALL_HOME/conf/security и перейдите к свойству jdk.tls.disabledAlgorithms:
jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
include jdk.disabled.namedCurves
2. Чтобы снова включить TLSv1 и TLSv1.1, просто удалите их из свойства jdk.tls.disabledAlgorithms, как показано в примере ниже:
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, \
DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
include jdk.disabled.namedCurves