Меню

Что такое конфигурационный файл и как его найти



Где находятся конфигурационные файлы самых популярных CMS

У многих пользователей возникает вопрос, при настройке CMS, ГДЕ НАХОДИТСЯ ФАЙЛ С НАСТРОЙКАМИ для подключения к базе данных? Самая большая проблема заключается в том, что у всех движков (CMS) конфигурационный файл находится в разных местах, поэтому если пользователь не знаком близко с CMS, которая у него установлена или которую он переносит в другое место и хочет настроить подключение к БД то могут возникнуть проблемы с поиском конфигурационного файла для настройки подключения к БД.

Итак давайте рассмотрим самые популярные CMS и то где у них расположены конфигурационные файлы.

Конфигурационный файл WordPress

Файл с настройками для подключения к БД у wordpress находится в корне (в папке с движком) и называется: wp-config.php

Конфигурационный файл Joomla

Файл с настройками для подключения к базе данных Joomla находится в папке с Joomla

Имя конфигурационного файла: configuration.php

Конфигурационный файл DLE

Файл с настройками для CMS DLE находится по адресу: engine/data/dbconfig.php

Имя файла как вы уже поняли: dbconfig.php

Конфигурационный файл Drupal

Файл находится по адресу: sites/default/settings.php

Файл называется: settings.php

Конфигурационный файл phpBB

Файл находится в той же папке что и сама CMS и называется: config.php

Конфигурационный файл vBulletin

Файл размещен по адресу: includes/config.php и называется config.php

Конфигурационный файл vBulletin

Файл размещен по адресу: ./ conf_global.php и называется conf_global.php

Конфигурационный файл Magento

Файл находится по адресу: app/etc/local.xml и файл называется local.xml

Конфигурационный файл CS-Cart

Файл размещен в директории сайта и называется: config.local.php

Конфигурационный файл MODx

Файл с настройками для подключения к БД находится по адресу: /manager/includes/config.inc.php

Конфигурационный файл Typo3

Файл с настройками для подключения к БД у CMS Typo3 находится в папке typo3conf и называется localconf.php

Конфигурационный файл NetCat

Сам файл находится в папке netcat, которая находится в корне CMS и называется vars.inc.php

Конфигурационный файл Image CMS

Файл находится по адресу: /application/config/config.php

Файл как вы видите называется: config.php

Конфигурационный файл Bitrix

Файл находится в папке: /bitrix/php_interface/dbconn.php

Имя файла: dbconn.php

Конфигурационный файл WebAsyst

Файл находится по адресу: kernel/wbs.xml и dblist/КЛЮЧ_БАЗЫ_ДАННЫХ.xml

Первый файл называется: wbs.xml

Второй файл называется: КЛЮЧ_БАЗЫ_ДАННЫХ.xml

Источник статьи: http://novall.net/manual/gde-naxodyatsya-konfiguracionnye-fajly-samyx-populyarnyx-cms.html

Конфигурационные файлы

Конфигурационный файл

Задание профиля с помощью командной строки – метод далеко не всегда удобный. Даже при работе с самой командной строкой используется окружение для сохранения настроек, чтобы не задавать их всякий раз и для всякой команды. Что уж говорить о сложных системных службах, свойства которых должны сохраняться не от сеанса к сеансу, а постоянно (в том числе при перезагрузке системы). Вывод прост: профиль необходимо держать в файле, вроде того, что создается по команде «сохранить настройки».

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

Конфигурационный файл. Текстовый файл, содержащий настройки какой-нибудь части системы (утилиты, демона и т. п.). Как правило, считывается ею при запуске. Типичный для Linux способ организации профиля .

Одним словом, если есть конфигурационный файл , то должны быть и средства редактирования этого файла. Учитывая, что в Linux реализована высокоразвитая система хранения и переработки (как ручной, так и автоматической) данных в текстовом виде, изобретать какой-то новый формат – все равно что изобретать велосипед. Тем более, что именно текст, разделенный на строки и слова, лучше всего подходит тогда, когда есть четкое деление профиля на объекты управления и их свойства (например, настройки какого-нибудь демона и значения этих настроек). Вдобавок, именно со структурированными текстами отменно управляются текстовые редакторы Linux: Vi, Emacs и др:

Вот как выглядит конфигурационный файл для Vim , написанный Мефодием на основе файла, взятого у Гуревича. Легко заметить, что файл состоит из команд режима командной строки Vi с комментариями (в отличие от большинства утилит Linux, в Vi комментарии начинаются на «»»). Символы » ^O » и » ^M » – это именно соответствующие управляющие символы (вставленные в текстовый файл с помощью » ^V «, см. лекцию 9). Такой конфигурационный файл легко понимать и изменять.

Как уже было замечено, набор переменных окружения составляет особенный профиль , к которому чувствительны все запускаемые программы – в этом его достоинство. Задаются переменные окружения обычно в командном сценарии, который тоже можно рассматривать как конфигурационный файл ). Например, во многих дистрибутивах используется конфигурационный файл .i18n для настройки языковых особенностей клавиатуры, языка вывода сообщений и т. п. 2 Обозначение «i18n» происходит от слова » internationalization «, в котором 20 букв, т. е. «i», «n» и 18 букв между ними. :

Однако хранить настройки специфической программы (не нужные всем остальным) в окружении – не самое удачное решение: синтаксис, задающий переменную окружения , слишком прост ( имя_переменной=значение ), а самих переменных становится слишком много, поэтому при просмотре трудно выделить, какая из них к какой группе настроек относится. Если пытаться упаковать все настройки в значение одной переменной, это значение окажется трудночитаемым, и все преимущество текстового формата сойдет на нет. Например, стандартный конфигурационный файл утилиты ls (точнее, только ее цветовых предпочтений) – /etc/DIR_COLORS (его можно подменить личным файлом

/.dir_colors ) занимает около ста строк вместе с комментариями. Команда ls использует не этот файл, а создаваемую утилитой dircolors переменную LS_COLORS , значение которой – 600-символьная строка без всяких комментариев.

Если профиль слишком велик, держать его в одном конфигурационном файле – значит, доставлять пользователю сомнительное удовольствие разбирать этот файл целиком даже при необходимости внести минимальное изменение. Методов борьбы с неудобочитаемостью несколько. В частности, уже известный по лекции 10 механизм » .d «: файл разделяется на несколько независимых друг от друга файлов так, что редактировать приходится только один из файлов, а программа во время самонастройки считывает все.

Другой способ опирается на то, что изменения, которые пользователь вносит в профиль , как правило, существенно меньше объема всего профиля . Поэтому может быть выгодно хранить все настройки по умолчанию в каком-нибудь файле, менять который вообще не надо, а файл пользовательских настроек использовать как бы «поверх», изменяя профиль в соответствии с ними после того, как выставлен профиль по умолчанию. Дополнительное преимущество такого способа – в том, что пользователь всегда может подглядеть в «большой» файл, чтобы узнать, как оформляется та или иная настройка. Например, утилита updfstab, которая изменяет содержимое /etc/fstab при появлении или удалении съемного дискового носителя (например, лазерного диска), считывает данные из конфигурационного файла /etc/updfstab.conf . Сам этот файл состоит из единственной строки: include /etc/updfstab.conf.default , что приводит к чтению файла с настройками по умолчанию, где задан способ работы со многими съемными устройствами системы. Если администратору нужно как-то изменить поведение updfstab в отношении определенного устройства, он копирует соответствующую группу настроек из updfstab.conf.default в updfstab.conf после строчки include.. . и исправляет их. То, что эти группы настроек читаются дважды, не играет особой роли: чтение коротких файлов выполняется быстро.

Наконец, третий способ сделать конфигурационный файл удобочитаемым — секционирование профиля , когда все настройки разбиваются на группы, каждой группе дается собственное имя, и синтаксис конфигурационного файла проектируется так, чтобы границы групп хорошо различались при просмотре. В сущности, этот способ – предок схемы » .d «, где группе соответствует отдельный файл, однако нередки ситуации, когда разбивать на файлы неудобно (например, если группы не полностью независимы, поэтому может понадобиться редактировать их сразу несколько). Конфигурационный файл утилиты дозвона wvdial , например, секционируется по адресату (провайдеру) плюс отдельная секция «по умолчанию». Сами секции отделяются друг от друга заголовками, заключенными в квадратные скобки:

Утилита wvdial обладает высокоразвитым искусственным интеллектом: она самостоятельно догадывается, какой именно тип идентификации используется на сервере. Например, «с той стороны» может оказаться терминал Linux, которому требуется сначала ввести обыкновенное входное имя и пароль, затем надо получить командную строку, запустить на сервере сетевой демон pppd , и только после этого запустить pppd на собственной машине. Другой вариант: pppd на сервере уже запущен, а настройки «Username» и «Password» означают идентификационную информацию протокола CHAP , используемого pppd . Обо всем этом и о многом другом wvdial способна догадаться,так же как wvdialconf умел определять, какое же из устройств является модемом.

Однако на любой искусственный интеллект найдется непостижимая ему жизненная ситуация. На одном из серверов (секция «Dialer hotspace») тоже стоит программа с зачатками искусственного интеллекта, которая тоже пытается определить, каким способом хочет идентифицироваться позвонивший. Оттого эти два кудесника, созвонившись, все ждут, пока кто-нибудь не проявит себя. Помогает настройка TOnline , которая заставляет wvdial немедленно задействовать протокол ppp , на что сервер, подумавши «ах, ppp!», с облегчением запускает pppd . Остается вопрос: почему эта полезная настройка никак не отражена в документации (ее нашел в исходных текстах программы Гуревич)? Не потому ли, что пара wvdialconf-wvdial не по-Linux-овски стремится все делать за пользователя, а стало быть, пользовательская документация для разработчиков этой программы – не главное?

Идею чтения настроек по умолчанию можно развить. Оказывается, бывает удобно, когда описание настройки помещено не в руководство, а непосредственно в конфигурационный файл в виде комментариев. Тогда при изменении этой настройки пользователь сразу видит, что она собой представляет, при этом отпадает необходимость сначала находить строчку в файле, а потом искать ее же в руководстве. Такой распространенный способ оформления называется самодокументированием профиля . Например, файл /etc/man.conf , управляющий работой команды man , оформлен в самодокументированном стиле:

Мефодий, может быть, и не понял бы сразу, зачем команде man использовать утилиту cmp, однако в поясняющем комментарии написано: когда нужно показать несколько руководств разом, они предварительно сравниваются, и показываются только несовпадающие.

Если пойти еще дальше, то можно создать несколько различных файлов с примерами настроек, чтобы пользователь мог взять один из них и довести до нужного ему состояния. Именно такую – демонстрационную – настройку Мефодий и включил в качестве настройки по умолчанию в свой .vimrc (в первой строке). Кстати, на самом деле профиль Vim весьма сложен, но большинство его настроек по умолчанию находятся в различных файлах дерева каталогов /usr/share/ vim – эдакая «схема .d/.d «, где файлы профиля , соответствующие подгруппам настроек, лежат в подкаталогах, соответствующих группам. Включение определенного настроечного файла может происходить неявно: например, строчка colorscheme desert из .vimrc приводит к чтению /usr/share/ vim /colors/desert. vim .

Конфигурационные файлы могут иметь довольно замысловатый синтаксис, если соответствуют сложным структурам данных (таковы, например, настройка irc-клиента irssi ) или содержать в себе дополнительные средства самодокументирования (например, файл настройки текстового www-броузера lynx не просто хорошо документирован, но и размечен теми же средствами, какие используются в самом броузере для представления HTML).

Источник статьи: http://intuit.ru/studies/courses/37/37/lecture/1102?page=2


Adblock
detector