#386 closed улучшение (не будем делать)
Контроль целостности конфигурации.
| Reported by: | san | Owned by: | alx |
|---|---|---|---|
| Priority: | низкий | Milestone: | 1 очередь |
| Component: | sw | Keywords: | |
| Cc: | andrei |
Description
Не давно у меня произошёл такой случай: я отправил пользователю файл конфига, а у него он применился не правильно, таблица коммутации оказалась "пустой". В последствии выяснилось, что где-то в ходе передачи файла он был изменён, а точнее внутрь настроек <mapper> и <gctable> были добавлены переносы строк(вероятно файл был пересохранён каким-то редактором).
Такой конфиг блок съел через веб-морду, не ругался, но повреждённый маппер применить не смог.
Предлагаю к настройкам <mapper> и <gctable> добавить поля <mapper_crc> и <gctable_crc>, содержащие контрольную сумму данных. Если у загружаемого через веб морду файла одна из контрольных сумм не совпадёт с вычисленным значением, веб-интерфейс ообщит пользователю об этом.
Change History (10)
comment:1 by , 5 years ago
| Resolution: | → не будем делать |
|---|---|
| Status: | new → closed |
follow-up: 3 comment:2 by , 5 years ago
... config.xml:640: 'mapper' invalid data size...
Ага, значит всё-таки какой-то контроль целостности этих полей есть.
почему только эти два элемента
Они самые нечеловекочитаемые, и вручную их мало кто возьмётся поправить.
Но и сделать некую "контрольную сумму" для всего конфига не кажется мне плохой идеей.
диагностики вполне достаточно
С тем что диагностики достаточно я согласен.
Но я бы хотел сразу проинформировать пользователя что что-то пошло не так.
comment:3 by , 5 years ago
Replying to san:
... config.xml:640: 'mapper' invalid data size...
Ага, значит всё-таки какой-то контроль целостности этих полей есть.
Это не контроль целостности, а контроль валидности. Если ты изменишь значение этого поля, и оно при этом останется валидным, значение будет применено (записано в табилцу коммутации).
почему только эти два элемента
Они самые нечеловекочитаемые, и вручную их мало кто возьмётся поправить.
В случае, упоминаемом в описании тикета, никто ничего вручную не правил. Там говорится об искажении файла в процессе передачи. А программе, исказившей файл, я думаю, все равно, насколько человекочитаемым является элемент, содержимое которого она исказила. :)
Но и сделать некую "контрольную сумму" для всего конфига не кажется мне плохой идеей.
Мне это кажется плохой идеей. Каждый раз при загрузке конфиг-файла надо будет загружать еще и второй файл, содержащий контрольную сумму первого. Слишком большие неудобства это доставит пользователю при слишком незначительном повышении надежности.
Но я бы хотел сразу проинформировать пользователя что что-то пошло не так.
Так оно сразу и информирует - как только обнаруживается, что значение элемента не может быть применено, немедленно выводится сообщение в лог.
follow-up: 5 comment:4 by , 5 years ago
надо будет загружать еще и второй файл
Я думаю, что можно некое подобие контрольной суммы засунуть прямо в файл конфига.
немедленно выводится сообщение в лог
Ага, а пользователь, работая с блоком через браузер, ещё параллельно обновляет лог постоянно, чтобы видеть что всё хорошо...
Как средство диагностики это хорошо, но гороздо удобней было бы не доходить до диагностики почему плохой конфиг не работает, а ещё на этапе загрузки файла в блок подсказать пользователю что файл плохой.
comment:5 by , 5 years ago
Replying to san:
надо будет загружать еще и второй файл
Я думаю, что можно некое подобие контрольной суммы засунуть прямо в файл конфига.
В таком случае (если, например, добавить CRC в конец файла), файл перестанет быть валидным документом XML (из-за "мусора" в конце файла).
немедленно выводится сообщение в лог
Ага, а пользователь, работая с блоком через браузер, ещё параллельно обновляет лог постоянно, чтобы видеть что всё хорошо...
Бесспорно. Только я бы сказал, не обновляет (лог обновляется сам, точнее, его обновляют программы, выводящие в него сообщения), а просматривает.
follow-up: 7 comment:6 by , 5 years ago
добавить CRC в конец файла
Зачем же в конец, можно и в виде элемента XML добавить, например CRC содержимого всех элементов и их имён.
не обновляет
Я имел в виду "обновляет отображение лога у себя на экране".
comment:7 by , 5 years ago
Replying to san:
добавить CRC в конец файла
Зачем же в конец, можно и в виде элемента XML добавить, например CRC содержимого всех элементов и их имён.
Тогда получится замкнутый круг: добавление в документ элемента, содержащего контрольную сумму документа, изменит контрольную сумму документа, и документ станет иметь неверную (не совпадающую с помещенным в документ значением) контрольную сумму.
follow-up: 9 comment:8 by , 5 years ago
Тогда получится замкнутый круг
- элемент с контрольной суммой должен быть один (назовём его X)
- при сохранении контрольной суммы считаем crc всех элементов кроме X, а в X записываем вычисленное значение
- при проверке так-же считаем crc всех элементов кроме X, и сравниваем со значением из X
comment:9 by , 5 years ago
Replying to san:
- при проверке так-же считаем crc всех элементов кроме X, и сравниваем со значением из X
То есть получается, что чтобы проверить контрольную сумму конфиг-файла, необходимо реализовать парсер, который будет разбирать текст на элементы только чтобы не учитывать при вычислении элемент X. Огромная работа ради крайне маловероятного (я бы сказал, гипотетического, ибо известен один такой случай за 10 лет существования аппаратуры, и кто знает, случится ли еще что-либо подобное) события...
comment:10 by , 5 years ago
Ну это только я так сходу предложил, если подумать, наверное, более эффективный метод можно придумать.
Мне не нравится это предложение.
Во-первых, чтобы сообщить что-либо в веб-интерфейс, надо чтобы веб-интерфейс, как минимум, был и прислал соответствующий запрос серверу (то есть пользователь запустил веб-браузер, и браузер выполнил некий запрос). Что не обязательно выполняется (на момент чтения и применения конфиг-файла запущенного браузера с открытым веб-интерфейсом блока может просто не быть).
Во-вторых, я только что провел эксперимент: в котором воспроизвел описанную ситуацию (добавил переводы строки в содержимое элемента <mapper/>). В результате при применении конфиг-файла получил в логе сообщение об ошибке: "
... config.xml:640: 'mapper' invalid data size...".В-третьих, почему только эти два элемента, а не все? Только что посмотрел конифг своего блока. В нем около 1000 элементов, из них один <mapper/> и один <gctable/>, что составляет 0.2%. А если что-то будет добавлено к содержимому элемента <port/> или <channel/>?
Подводя итог: я считаю, что на данный момент существующей диагностики вполне достаточно. Выводимая в лог запись вполне ясно дает понять, что содержимое элемента <mapper/> некорректно и не может быть применено.