От экспертов «1С‑Рарус»: Подготовка к практической части экзамена «1С:Эксплуататор крупных информационных систем»

Введение

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

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

А зачем нам нужна подсистема Фреш? Давайте посмотрим условия экзамена.

Что будут от вас требовать

Компания 1С открыто говорит что нужно знать для успешной сдачи экзамена.
1c.ru/rus/partners/training/uc1/course.jsp?id=540

Экзамен однодневный.

1. В первой части нужно выполнить практическую задачу, которая звучит так:

   

   В контуре, построенном по технологии 1cFresh, смоделированы отказы тех или иных узлов. Необходимо восстановить работоспособность всей системы.

   Вот здесь мы и встречаем подсистему «Фреш». И как видите, бессмысленно идти на экзамен без знания Фреша. На всё это дается 1.5 астрономических часа. Для успешной сдачи практической части необходимо выявить каждый недоступный узел (компонент), разобраться в причинах недоступности, внести необходимые исправления и восстановить доступность узла.

   Очевидно, что для выполнения этого задания, необходимо обладать практическими навыками расследования и устранения ошибок.

2. Во второй части экзамена выполняется проверка теоретических знаний. Дается 2 основных вопроса, обычно на общее понимание какой-то темы. Экзаменатор во время ответа задает дополнительные вопросы, чтобы понять, насколько хорошо человек разбирается в данной теме.

Про теорию мы говорить не будем. Данная статья касается только практической части.

Что такое облачная подсистема «Фреш»

Подсистема «Фреш» — это информационная система управления, которая работает как правило в облаке.

Имеется много определений того, какие именно задачи решает подсистема «Фреш». Для краткости мы выбрали несколько основных её функций.

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

Подсистема «Фреш» облегчает эксплуатацию, беря на себя следующие функции:

• Централизованное обновление опубликованных в сервисе прикладных решений.
• Автоматический обмен данными между опубликованными в сервисе прикладными решениями.
• Автоматическое резервное копирование данных.
• Единая аутентификация пользователей во всех приложениях и компонентах сервиса.
• Оповещение пользователей сервиса о предстоящих работах и других событиях в сервисе.
• Средства централизованного хранения информации о ресурсах сервиса.
• Использование тарифов и автоматический контроль тарифных ограничений.

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

На данном изображении мы видим упрощенную схему, которая показывает только общую суть подсистемы «Фреш». На схеме обозначены узлы, которые присутствуют в подсистеме «Фреш»:

• менеджер сервиса,
• менеджер доступности,
• сайт сервиса,
• агент сервиса,
• шлюз приложений,
• форум сервиса.

Также мы видим, что информационные базы разделяются на цветные слои. Это и есть те самые области разделения данных, где каждая область хранит в себе данные одного клиента.

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

С чего начинается стенд для подготовки к практической части экзамена

В основу данной статьи заложена идея, что мы можем сделать тестовый стенд, на котором будем отрабатывать приемы поиска неприятностей, которые могут встретиться на экзамене. Это позволит увереннее себя чувствовать на экзамене и не терять время на простых вещах. А времени на экзамене не так уж и много — 90 минут.

Также этот стенд можно будет потом передать коллегам по наследству, дабы помочь им повысить квалификацию. Во всяком случае, пока компания 1С не изменит формат экзамена.

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

За основу стенда мы берем облачную подсистему «Фреш», созданную по демонстрационному примеру с сайта ИТС (its.1c.ru/db/freshex1/content/983/hdoc).

Для этого рекомендуется развернуть отдельную виртуальную машину. На ней будет проще делать копии состояния всей системы. И если что-то пошло не так при установке очередного узла, можно будет легко восстановить копию и попробовать установить узел ещё раз.

На виртуальной машине установить чистую операционную систему и далее развернуть подсистему «Фреш» по указанному примеру. Чтобы лучше разобраться, из каких узлов состоит подсистема и как эти узлы взаимодействуют, делать это должен тот, кто готовится сдавать экзамен. В таком случае, человек, хочет он того или нет, углубит (или закрепит) свои знания по операционной системе, по настройкам и взаимосвязям узлов подсистемы «Фреш».

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

Какие узлы могут быть поломаны? Исходя из описания практической части на странице экзамена считаем, что поломан может быть любой узел. Надо заметить, что здесь у людей могут возникнуть проблемы — не хватает фантазии, как же поломать эти узлы. Так вот, все узлы мы сегодня ломать не будем. Ведь наша задача — показать способы, как это можно сделать. Так сказать придать творческого вдохновения в массы.

Какие неприятности бывают

И давайте разбираться, что значит — в подсистеме «Фреш» смоделирован отказ узла? Что значит отказ в работе узла?

Мы выделили три возможных класса.

1. Служба не запускается.
2. Служба запускается неполноценно (запускаются не все её компоненты).
3. Служба запускается без ошибок, но функционирует неправильно — не взаимодействует с другими узлами подсистемы «Фреш».

Способы вызвать отказ узла

Вызвать отказ в работе узла можно различными способами. Вот эти способы:

• Воздействие на настройки операционной системы.
• Воздействие на конфигурацию узла.
• Воздействие на конфигурацию сторонней службы.
• Воздействие на доступ к узлу.

Эмулируем сбои и недоступность информационной системы

Начнем изменять наш стенд с установки некорректных настроек в операционной системе.

Файл hosts. Воздействие на настройки операционной системы

Файл hosts — это текстовый файл в операционной системе, который выполняет функцию локальной службы DNS. Проще говоря, это как бы адресная книга вашего компьютера, которую он проверяет в самую первую очередь, прежде чем обращаться к серверам DNS. Основная задача файла hosts — статическое сопоставление доменных имен с IP-адресами. Администратор системы всегда должен помнить про этот файл и уметь работать с ним.

Так как все настройки по взаимодействию между узлами подсистемы «Фреш» построены на доменных именах, то некорректные данные в файле hosts будут негативно сказываться на работе всей подсистемы.

В данном примере мы закомментировали сопоставление имени нашего сервера (hostname) с его IP-адресом, таким образом удалив трансляцию имени в IP-адрес, оставив только стандартные строки с localhost. И как говорилось выше, т. к. взаимодействие между узлами происходит по имени сервера, то таким образом мы нарушили это взаимодействие.

Сайт перестал отвечать, а при подключении тонким клиентом к любой информационной базе получаем ошибку соединения. Да и в целом, без правильных настроек файла hosts, подсистема «Фреш» просто не будет функционировать.

Межсетевой экран Iptables. Воздействие на настройки операционной системы

Iptables — это стандартная система межсетевого экрана (firewall) для Linux, встроенная в операционную систему. Основная задача Iptables — обеспечение сетевой безопасности. И блокировка сетевых портов операционной системы является её важным средством.

Для нас же такая возможность является «удобным» способом вызвать проблемы сетевого взаимодействия.

Эксплуататор информационной системы должен понимать принципы архитектуры Iptables — таблицы и цепочки, знать команды и уметь их использовать. В данной статье мы не будем глубоко погружаться в эту тему. При желании можно легко найти информацию в интернете.

Для примера, давайте просто заблокируем сетевой порт какого-либо узла подсистемы Фреш. Например, web-сервера Apache.

Если забыли, на каких портах слушает Apache, можно посмотреть в конфигурационный файл, но можно выполнить команду ss или аналогичную ей команду netstat. Которая отображает состояние сетевых соединений. Данным способом всегда можно узнать, какая служба слушает на каких сетевых портах:

Мы видим, что Apache слушает на портах 8888, 8889, 8890. Для блокировки мы выбрали порт 8888. Выполним команду:

Данной командой мы добавили правило для входящих соединений на порт 8888 по протоколу TCP и указали, чтобы данные соединения блокировались.

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

Вы можете выбрать другой порт Apache и посмотреть на поведение системы. Или указать порт другого узла подсистемы «Фреш» на ваше усмотрение.

Будьте осторожны с изменением настроек Iptables. Некорректные настройки могут привести к потере доступа к серверу. Если не уверены, то самый простой способ — создать копию виртуальной машины перед изменением настроек Iptables.

Теперь приступим к поломке конкретных узлов подсистемы Фреш.

Сервер PostgreSQL. Воздействие на сторонние службы

Так как узлы в подсистеме «Фреш» — это сетевые службы, первый и самый очевидный способ — вызвать конфликт сетевых портов. Здесь есть много пространства для воображения. Например, можно настроить какой-то из узлов подсистемы «Фреш» на рабочий порт другого узла. Тогда первая служба захватит порт, остальные службы, настроенные на этот порт не смогут запуститься.

В данном примере мы взяли конфигурационный файл web-сервера Apache и добавили настройку, чтобы web-сервер занял порт 5432, на который у нас настроена служба кластера PostgreSQL.

При запуске системы web-сервер захватил порт и в следствие этого мы получили ошибку при запуске службы кластера PostgreSQL:

Кстати, это универсальный способ, который подходит для вывода из строя любого узла подсистемы «Фреш».

Сервер PostgreSQL. Воздействие на конфигурацию узла

У кластера PostgreSQL имеется файл конфигурации postgresql.conf, в нем хранятся настройки, которые считываются при запуске службы кластера. В этом файле можно установить недопустимое значение для какого-то параметра.

В данном случае мы изменили значение параметра максимальное количество подключений — max_connections, установив значение за пределами диапазона допустимых значений 1-262143.

И в результате мы снова получили ошибку при запуске службы кластера PostgreSQL.

Сервер PostgreSQL. Воздействие на доступ к узлу

Так же, сервер PostgreSQL использует в своей работе файл pg_hba.conf. В данном файле хранятся настройки, с помощью которых мы управляем аутентификацией клиентов. А по сути определяем, какие пользователи, с каких адресов и к каким базам данных имеют доступ и какую аутентификацию они должны пройти для того, чтобы получить этот доступ.

Сменив настройку в данном файле можно нарушить взаимодействие с PostgreSQL.

Например, строка:

Означает, что сетевые соединения ко всем базам под пользователем postgres, по протоколу IPv4 с адресов 127.0.*.* (за маску отвечает значение 16), должны использовать метод md5, т. е. проходить аутентификацию с паролем.

В данном примере в методе аутентификации мы использовали значение reject, при котором аутентификация просто отклоняется. Этим самым мы по сути запретили все такие подключения.

Ну и т. к. наш сервер «1С:Предприятие» установлен на том же сервере, что и PostgreSQL, а значит имеет локальный IP-адрес 127.0.0.1 и подключение информационных баз 1С к СУБД происходит под пользователем postgres, то такие подключения перестанут работать.

Здесь мы видим параметры информационной базы Менеджер сервиса. Данная информационная база является одним из важнейших узлов подсистемы «Фреш». Пользователь сервера БД — postgres. Это значит, что данная информационная база не будет работать при таких настройках.

Причем перестанет работать и сайт подсистемы «Фреш», т. к. он активно обращается к данным менеджера сервиса.

На данном изображении видим, что служба кластера PostgreSQL активна и как-будто проблем нет. Но подключиться к сайту мы не можем:

Видите, как всё взаимосвязано? Проблема в настройках PostgreSQL может повлиять на доступность сайта. Поэтому очень важно четко понимать, как узлы взаимодействуют друг с другом.

Сервер «1С:Предприятие». Изменение прав доступа пользователей системы

Можно установить запрет на чтение файлов или каталогов, запрет на выполнение исполняемых файлов.

Давайте запретим чтение файлов из каталога, в котором находятся файлы платформы «1С:Предприятие» /opt/1cv8/x86_64/8.3.25.1445/.

Сперва надо понять, какому пользователю будем ограничивать права:

Такой командой мы можем посмотреть свойства запущенных процессов системы. Процессов много, поэтому, командой grep накладываем отбор по процессу ragent.

Видим, что данный процесс запускается под пользователем usr1cv8. Воспользуемся командой groups, чтоб посмотреть, в какие группы входит пользователь:

Пользователь usr1cv8 входит только в группу grp1cv8. Запомним эту информацию.

Теперь нам надо понять, какие права доступа установлены на каталог. Для этого используем команду ls с параметрами -ld:

Видим, что владельцем является пользователь root, группа владельцев тоже root , а мы уже выяснили, что работает с этими файлами пользователь usr1cv8, который не является владельцем и не входит в группу root. Получается, при таких правах наш пользователь попадает в категорию «другие пользователи», для которых установлены права r-x, т. е. разрешено чтение и исполнение. Давайте для этой категории изменим права:

Для изменения прав мы использовали команду chmod с параметром o-x. Данной командой для группы «другие пользователи» мы запретили вход в каталог, а значит и запретили доступ к файлам каталога.

Теперь перезапускаем службу сервера «1С:Предприятие».

И в результате видим ошибку при запуске службы.

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

Сервер «1С:Предприятие». Воздействие на сторонние службы

Так же можно занять порт любой другой сетевой службой, имеющейся в операционной системе или специально для этого установить дополнительную службу.

Данный пример напоминает первый способ, которым мы ломали PostgreSQL, отличие в том, что здесь участвует служба, которая нам не нужна для функционирования подсистемы «Фреш». И этот способ тоже является универсальным.

Давайте займем порт менеджера кластера «1С:Предприятие» 1541 службой MySQL. Но можно подобрать любую другую службу для этого.

Сначала установим MySQL в систему командой:

После установки MySQL найдем файл конфигурации mysqld.cnf и изменим порт, настроив его на порт менеджера кластера «1С:Предприятие» (1541).

Разумеется, придется постараться сделать так, чтоб такая вот «вредная» служба запускалась первая и занимала нужный нам порт. Для этого в service-файл, который отвечает за запуск службы MySQL, в секцию [Unit] добавим параметр Before, который влияет на очередность запуска служб и установим в его значение имя нашей службы сервера «1С:Предприятие».

Теперь MySQL занял порт менеджера кластера и мы видим такую картину, что служба сервера «1С:Предприятие» вроде бы активна, но запустились не все службы необходимые для полноценной работы.

Обратим внимание, что в данном списке имеется процесс менеджера кластера rmngr. Такова специфика кластера «1С:Предприятие». Данный процесс хоть и запущен, но свой порт занять не может и как сетевая служба не функционирует. Такой процесс через какое-то время будет перезапущен и опять не сможет занять порт. И так будет постоянно, пока порт не освободится.

Давайте посмотрим на процессы сервера «1С:Предприятие», когда он запущен без ошибок и сравним с предыдущим состоянием.

В данном случае важнее, что у нас не запустился рабочий процесс кластера rphost. Без него кластер «1С:Предприятие» является неработоспособным.

Так же в консоли администрирования серверов 1С:Предприятия можем увидеть ошибку, что кластер недоступен:

Сервер «1С:Предприятие». Воздействие на конфигурацию рабочего сервера

Можно установить некорректные или запрещающие значения параметров в настройках кластера.

В консоли администрирования серверов 1С:Предприятия изменим параметр «Критический объем памяти процессов». Действие его такое:

Понятно, что ничего хорошего от такого поведения ждать не приходится.

В данном примере мы установили данное значение порядка 1 ГБ, что явно недостаточно для нормальной работы, заставляя рабочий процесс регулярно перегружаться. Значение придется подбирать опытным путем, т. к. оно будет индивидуальным для каждого отдельного стенда.

В результате этого на сайте Фреша нам удалось зайти в личный кабинет. Лимита памяти для этого ещё хватило, но вот запустить приложение из него уже не получилось:

Мы получили ошибку, что не найден доступный рабочий процесс. При запуске приложения объем памяти рабочего процесса превысил установленное ограничение, рабочий процесс был остановлен и пока загружался новый, наш сеанс выдал ошибку: Не найден доступный рабочий процесс.

Сервер «1С:Предприятие». Воздействие на конфигурацию информационной базы

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

При попытке зайти в приложение получаем ошибку:

Сайт подсистемы «Фреш». Воздействие на конфигурацию. Нарушение сетевого взаимодействия

Что такое сайт в подсистеме «Фреш»? По сути, это мини web-сервер, информация для которого хранится в базе данных нашего кластера PostgreSQL. Очевидно, что такой узел можно вывести из строя, сменив порт или нарушив взаимодействие с базой данных.

Давайте вспомним, как запрос от пользователя доходит до сайта Фреш. Первым запрос принимает фронтенд web-сервер, которым у нас является сервер Nginx и в зависимости от вида запроса направляет его на разные службы нашей подсистемы Фреш. Вот так выглядят настройки перенаправления запросов на службу сайта. Перенаправление выполняется на порт 8180:

При таких настройках, наш сайт должен принимать запросы на порте 8180. Давайте изменим данный порт и нарушим взаимодействие между фронтенд web-сервером и сайтом:

В данном примере, мы взяли конфигурационный файл службы сайта application.properties, в котором хранятся настройки, использующиеся при старте службы и в параметре server.port изменили стандартное значение 8180 на 8182. При такой настройке сайт будет работать, но принимать запросы будет на другом порте:

В результате служба стартовала, но при попытке зайти на сайт получаем страницу недоступности, т.к. сервер Nginx направил запрос на другой порт:

Данный способ является универсальным. Таким образом можно нарушить взаимодействие с любым узлом подсистемы «Фреш».

Сайт подсистемы «Фреш». Воздействие на конфигурацию. Нарушение доступа к данным (способ 1)

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

За это отвечают параметры: spring.datasource.url, spring.datasource.username, spring.datasource.password.

После изменения этих настроек мы два раза подряд запросили состояние службы Сайта и получили разный результат. Т. к. служба сайта при запуске не может подключиться к базе данных и постоянно перезапускается.

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

Сайт подсистемы «Фреш». Воздействие на конфигурацию. Нарушение доступа к данным (способ 2)

Подобного результата можно добиться, изменив настройки как бы с другой стороны. Не в конфигурационном файле, а в базе данных.

Для этого будем использовать консольную утилиту для работы с PostgreSQL — PSQL, поставляемую вместе с СУБД.

Подключившись к кластеру баз данных, с помощью запроса мы установили новый пароль для нужной нам роли site, под которой служба сайта подключается к СУБД.

Так же можно вообще установить для роли site запрет на подключение к кластеру.

И в обоих случаях мы в результате получаем постоянный перезапуск службы.

Все способы, которые указаны для сайта, можно применить и для службы Форум, т. к. эти две службы технически очень похожи.

Шлюз приложений. Воздействие на конфигурацию

Шлюз приложений — ещё один узел в подсистеме «Фреш». Данная служба отвечает за перенаправление запросов к публикациям приложений. С данной службой проще настраивать нашу подсистему «Фреш» при добавлении в неё новых единиц масштабирования, которые называются Ноды. Добавление Нод в подсистему «Фреш» предназначено для повышения отказоустойчивости и распределения нагрузки.

Например, два абонента сервиса «Фреш» имеют похожий внешний адрес приложения, который отличается только номером области:

https://1cfresh.example/a/sbm/16/... и https://1cfresh.example/a/sbm/17/...

Но при этом сами публикации приложений для областей 16 и 17 могут быть размещены на разных web-серверах, информационные базы для этих областей могут находиться в разных кластерах сервера «1С:Предприятие», данные могут находиться в разных базах данных и все эти сервисы могут находиться на разных машинах. Перенаправлением на разные публикации и занимается шлюз приложений. Таким образом, шлюз приложений выступает как единая точка входа, упрощая управление доступом распределенной системы «Фреш».

Использование шлюза приложений имеет смысл, когда развернуто несколько Нод или внутри одной Ноды настроено несколько кластеров «1С:Предприятие». Включается данная возможность в менеджере сервиса:

Для примера мы взяли файл настроек шлюза приложений application.properties и изменили в нем значение параметра app.id.depth.

Данный параметр указывает, где хранится номер области приложения в полученном адресе. Например, если у абонента адрес имеет такой вид:

https://1cfresh.example/a/sbm/16/..

То число 16 — номер области, является третьим в глубине вложения нашего адреса (отсчет ведется после имени сервера 1cfresh.example). И корректно установить значение параметра app.id.depth=3.

Изменив значение данного параметра, мы нарушили логику работы шлюза приложений и при подключении к приложению получили ответ, что приложение не найдено:

Публикация прикладного решения. Воздействие на конфигурацию

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

Публикация прикладного решения выполняется на web-сервере Apache и состоит из двух частей.

В основе публикации лежит директива Directory, размещаемая в конфигурационном файле сервера. Она определяет, как Apache должен взаимодействовать с содержимым конкретной папки. И в простейшем случае выглядит так:

Вторая часть — файл описания публикации, который содержит в себе инструкции по взаимодействию между информационной базой и клиентом. Такие как: настройки аутентификации и авторизации, настройки публикации web-сервисов и http-сервисов, параметры сервиса OpenID и т. п. Физически файл расположен в папке документов web-сервера и по умолчанию имеет имя default.vrd. Примерный вид файла такой:

Все вместе это работает так. Web-сервер получает запрос к документам в определенной папке и проверяет, существует ли директива Directory, соответствующая пути к запрашиваемой папке. Если директива найдена, сервер применяет все указанные в ней правила обработки и на основе полученных инструкций предоставляет доступ к файлам, включая файл описания публикации.

Давайте нарушим взаимодействие в данной схеме. Например, изменим путь к каталогу у директивы Directory. Тогда, при обращении к документам публикации, web-сервер не найдет нужную директиву и не сможет понять назначение файла default.vrd.

В данном примере мы выбрали публикацию прикладного решения с именем sbm и изменили путь к каталогу:

И в результате мы не смогли подключиться к информационной базе из личного кабинета:

OpenID аутентификация. Воздействие на конфигурацию

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

Как пример — сервисы Яндекс. Авторизовавшись один раз мы получаем доступ сразу ко многим сервисам Яндекс — почта, карты, диск, документы, календарь и т. п.

Так выглядит нормальное поведение в подсистеме «Фреш»:

OpenID аутентификация является неотъемлемой частью полноценной работы подсистемы Фреш. Нарушение в работе OpenID аутентификации тоже является отказом в работе узла.

В файле описания публикации прикладного решения default.vrd есть секция openid, в которой прописан путь к провайдеру аутентификации. По сути, это путь к другой публикации, которая отвечает за OpenID аутентификацию.

В данном случае мы изменили путь к OpenID публикации. Но можно и просто удалить данную секцию:

В результате при входе в приложение OpenID аутентификации не сработает и будет выведено окно запроса логина и пароля:

Послесловие

В заключение стоит сказать, что:

• Сам сертификат «1С:Эксплуататор» не про «Фреш», хотя знание Фреша обязательно для успешного прохождения экзамена. Подсистема «Фреш» на экзамене являет собой пример сложной информационной системы. Чаще всего вам придется эксплуатировать не подсистему «Фреш», а стандартные кластеры «1С:Предприятие». Но знания, полученные при подготовке к экзамену, безусловно пригодятся в будущем.
• Важно не столько знать всевозможные ошибки в компонентах системы, но понимать как диагностировать неисправности. Ведь часто решение многих проблем лежит на виду, однако надо знать, куда посмотреть и это очень не просто.

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

Спасибо за внимание и удачи на экзаменах!