Устойчивость к ошибкам конфигурации

[sinaps]

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

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

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

[~AsmodeuS~]

на все компоненты программы

и это хорошо что он перестаёт работать вы это увидите сразу а не через полгода

[sinaps]

В принципе, при добавлении модулей можно избежать возможности синтаксических ошибок, просто указав каталог в котором лежат используемые (симлинки), и используя всё что там есть. Например abills/modules.enabled. Если при этом у каждого модуля был свой отдельный конфиг, то при любой ошибке в центральном конфиге, включенные и настроенные модули работали бы без перебоев.

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

[~AsmodeuS~]

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

[sinaps]

Не совсем. Пусть примерно так: есть ядро, есть модуль один и есть модуль два. Пусть при настройке модуля два я допускаю ошибку.

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

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

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

[~AsmodeuS~]

идея интересная на первый взгляд так как разрешит разнести модули с отдельными конфигами но в системах где по 15 модулей используется уйдёт куча времени на анализы только 50 заинклежденых файлов конфигов и системы

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


думаю в будущем что то похожее придумаем

[sinaps]

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

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

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

И, если для информирования об ошибке используется отказ веб интерфейса, то может быть имеет смысл добавить туда минимум подробностей? Хотя бы номер строки.