Конфигурационный файл. Подключаемые файлы Главный конфигурационный файл BIND

Общий формат конфигурационных файлов

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

Общий формат файла конфигурации:

Начало файла ---

[Имя секции 1]

...
ПараметрN = значение1, ..., значениеK

[Имя секции X]
Параметр1 = значение1, ..., значениеK
...

--- конец файла ---

Файлы конфигурации формируются по следующему принципу:

Символы " ; " или " # " в строках конфигурационного файла обозначают начало комментария – весь текст, идущий в строке за этими символами, пропускается модулями Dr.Web для почтовых серверов UNIX при чтении параметров из конфигурационного файла.

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

Каждая секция содержит группу параметров конфигурации, объединенных по смыслу.

В одной строке файла задается значение только одного параметра.

Основной формат задания значения параметра (пробелы, окружающие символ "=", если встречаются, игнорируются):

<Имя параметра> = <Значение>

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

Все имена секций и параметров в файле регистронезависимы.

Порядок следования секций в файле и параметров внутри секций не имеет значения.

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

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

Пример задания параметра, имеющего несколько значений :

1) Перечисление нескольких значений через запятую:

Parameter = Value1, Value2,"Value 3"

2) Задание тех же значений параметра в разных строках конфигурационного файла:

Parameter = Value2
Parameter = Value1
Parameter = "Value 3"

Правила описания параметров, принятые в данном документе

В данном руководстве каждый параметр описывается следующим образом:

[Статус использования в Правилах ] ИмяПараметра = {Тип параметра | Возможные значения}	Описание параметра. {Может ли иметь несколько значений}. {Особые замечания} {Важные замечания}
	Значение по умолчанию : ИмяПараметра = {значение | отсутствует}

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

	Параметр может быть использован в SETTINGS -части Правил обработки писем для временного изменения его значения при обработке конкретного письма, для которого условная часть правила истинна.
	Параметр при использовании в Правилах обработки писем имеет "аддитивную" (накапливающую) семантику, т.е. если для письма истинно несколько Правил, задающих разное значение этого параметра, то в качестве значения параметра выступает объединенный список его значений из сработавших Правил.
	Параметр при использовании в Правилах обработки писем поддерживает клонирование писем, т.е. если у письма несколько получателей, и для разных получателей письма истинны разные Правила, задающие различные значения этого параметра, то письмо будет клонировано (по числу получателей), и к каждой копии письма в качестве значения параметра будет использовано значение из Правила, истинного для этого письма.

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

Описание параметров и секций конфигурационных файлов дано в порядке их следования в файле конфигурации, создаваемом при установке программного комплекса Dr.Web для почтовых серверов UNIX .

Поле Тип параметра может принимать следующие значения:

числовое значение (numerical value) - значение параметра является целым неотрицательным числом.

время (time) - значение параметра задается в единицах измерения времени. Значение состоит из целого числа, после которого может идти буква, определяющая вид единиц измерения времени (s – секунды, m – минуты, h – часы, регистр букв не учитывается). Если в значении параметра буквы нет, то считается, что время задано в секундах.

Примеры : 30s , 15m

размер (size) - значение параметра задается в единицах измерения объема памяти (дисковой или оперативной). Значение состоит из целого числа, после которого может идти буква, определяющая вид единиц измерения объема памяти (b – байты, k – килобайты, m – мегабайты, g – гигабайты, регистр букв не учитывается). Если в значении параметра буквы нет, то считается, что размер задан в байтах.

Примеры : 20b , 15k

права (permissons) - значение параметра задаётся трехзначным числом, обозначающим права доступа к файлам в формате, принятом в UNIX-системах.
Каждое право является комбинацией (суммой) трех базовых прав:

o Право чтения (r) обозначается числом 4;

o Право записи (w) обозначается числом 2;

o Право исполнения (x) обозначается числом 1.

При этом первая цифра числа задает права для владельца файла, вторая – для группы владельцев файла, а третья – для всех остальных, не являющихся ни владельцами, ни членами соответствующей группы.

Примеры : 755 , 644

логический (Ye s /No ) - Логический тип, значения которого представляются строками " Yes " и " No ".

путь к файлу/каталогу (path to file/directory) - строка, задающая расположение файла или каталога в файловой системе. Помните, что в ОС семейства Linux/UNIX имена файлов и каталогов регистрозависимы. Если указано, что значением параметра может быть маска , то в качестве значений параметра можно использовать файловые маски, содержащие следующие специальные символы:

o ? – замещает любой один символ;

o * – замещает любую (в том числе пустую) последовательность символов.

Пример : " ?.e* " – маска, под которую подпадают файлы, имя которых состоит из любого одного символа, а расширение любой длины, и начинается с буквы " e " (x.exe , g.e , f.enable и т.п.).

действие (action) - строка, содержащая наименование действий, совершаемых над объектами, вызвавшими какую-либо реакцию компонентов программного комплекса Dr.Web для почтовых серверов UNIX . В некоторых случаях для параметра можно задать одно основное действие и до трех дополнительных. Тип параметра в этом случае называется список действий (actions list) . Основное действие в этом случае всегда должно быть первым в списке. Для разных параметров набор допустимых действий может различаться, и в этом случае он указывается отдельно для каждого параметра. Общий перечень действий, которые могут использоваться, см. ниже .

адрес (address) - строка, содержащая адрес сокета компонента Dr.Web для почтовых серверов UNIX или внешнего модуля или программы.
Имеет формат ТИП:АДРЕС . Допустимы следующие типы:

o inet - используются TCP-сокеты, АДРЕС имеет формат ПОРТ@ИМЯ_УЗЛА . ИМЯ_УЗЛА может быть как прямым IP-адресом, так и доменным именем узла.

Пример :

Address = inet:3003@localhost

o local - используются локальные UNIX-сокеты, в этом случае адрес является путем к файлу сокета.

Пример:

Address = local:%var_dir/.daemon

o pid - реальный адрес процесса должен быть прочитан из его PID файла. Такой тип адреса доступен лишь в некоторых случаях и при возможности его использования в описании параметра это указывается явно.

текст (text value), строка (string ) - значение параметра задается в виде текстовой строки, текст в строке может быть заключен в кавычки (если в строке есть пробелы, то кавычки обязательны).

настройки пула (pool options) - настройки пула потоков. Имеют специальный формат, описанный в разделе Специальные типы параметров .

Lookup - строки, задающие разделенные запятыми объекты для поиска.

LookupLite - упрощенный Lookup , в котором можно указывать только либо непосредственное значение, либо Lookup типа file .

хранилище (Storage) - объекты для хранения данных. Синтаксис аналогичен Lookup , за исключением использования другого списка префиксов и того, что в Storage нельзя использовать макрос $s .
Подробнее о типах Lookup , LookupLite и Storage см. в разделе Lookup .

настройки TLS/SSL (TLSSettings) - настройки для работы шифрованного соединения с использованием криптографических протоколов TLS и SSL. Имеют специальный формат, описанный в разделе Специальные типы параметров .

список строк (strings list) - набор текстовых значений, разделенных запятыми.

Если значение параметра соответствует шаблону file:/path_to_file (где path_to_file – путь к файлу), то текстовые значения получаются из указанного в параметре файла. Каждое значение в файле должно записываться в отдельной строке. Если при получении информации из файла произошла ошибка, в файл журнала выводится соответствующее диагностическое сообщение и загрузка программы продолжится.

уровень подробности (log level ) - строка, указывающая вывода информации в некоторый журнал или в службу syslog .

возможные значения (value) - параметр имеет тип, не описанный в предыдущих пунктах данного списка. В этом случае перечисляется список разрешенных для него значений.

Поведение модулей при некорректно заданных файлах конфигурации

Если значение какого-либо параметра задано некорректно, Dr.Web для почтовых серверов UNIX выводит сообщение об ошибке и завершает свою работу.

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

Некоторые параметры могут использовать в качестве значений регулярные выражения (для каждого параметра отмечается в его описании). По умолчанию используется синтаксис регулярных выражений Perl . С основами регулярных выражений вы можете ознакомиться, например, в Wikipedia (статья " Регулярные выражения ").

• Recovery Mode

Введение

Как-то находясь в поиске как мне прикрутить конфигурационные ini файлы или json к моему сервачку перебирал варианты, но почему-то они были неудобны или слишком простые, или велосипеды. И хоть я люблю xml конфигурирование, но порою это чрезмерно огромные файлы и неудобно для небольшого количества настроек писать много текста. Раз задал другу вопрос по этой теме, он то мне и подкинул библиотеку. Напоминает она json в смеси с yaml.

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

Настройка и подключение

Библиотека есть во многих репозиториях, поэтому установка простая:
$ sudo aptitude install libconfig8 libconfig8-dev libconfig++ libconfig++-dev

В исходниках С++ подключается одним лишь инклудом:
#include
или
#include
или для С
#include

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

Файл конфига представляет собой следующего вида структуру:
# Example application configuration file version = "1.0"; application: { window: { title = "My Application"; size = { w = 640; h = 480; }; pos = { x = 350; y = 250; }; }; list = (("abc", 123, true), 1.234, (/* an empty list */)); books = ({ title = "Treasure Island"; author = "Robert Louis Stevenson"; price = 29.95; qty = 5; }, { title = "Snow Crash"; author = "Neal Stephenson"; price = 9.99; qty = 8; }); misc: { pi = 3.141592654; bigint = 9223372036854775807L; columns = [ "Last Name", "First Name", "MI" ]; bitmask = 0x1FC3; }; };

Основными видами записей в конфиге являются такие типы:

Элемент (Setting)

Это минимальная значимая часть конфигурационной структуры и имеют вид ключ-значение:
name = value;
или
name: value

Группы (Groups)

Группы могут содержать любое число элементов, но каждый элемент должен содержать уникальный ключ в пределах группы. Записывается в фигурных скобках:
{ settings... }

Массивы (Arrays)

Содержат любое количество элементов, даже ноль, но все элементы состоят лишь из значений и должны иметь один и тот же скалярный тип в пределах массива. Записывает в квадратных скобках:
[ value, value ... ]

Списки (Lists)

Списки содержат ноль или более элементов скалярного типа, массивов, групп или списков. Записывается в круглых скобках:
(value, value ...)

Целочисленые значения (Integers)

Записываются обычным нам десятичным способом (±0-9) или шестнадцатиричном виде (0xA-f). Но целочисленные значения ограничены диапазоном -2147483648..2147483647 (32bit), но если нужны большие диапазоны, то в конце добавляется ’L’.
3578934 897893450934L

Дробные числа с плавающей запятой (floats)

Записывается тоже привычным нам способом
3.1415
Запись с экспонентой стандартная с "e".

Булевые значения (Boolean)

Значения записываются как ’true’ или ’false’ и регистронезависимо (без кавычек, конечно).

Строки (Strings)

Записываются в двойных кавычках как "Обычная длинная строка записанная для примера" .
Следующие варианты в итоге дадут то же значение строки:
"Обычная длинная строка" "записанная для примера"
"Обычная длинная строка" /* комментарий */ " записанная " // комментарий "для примера" .

Комментарии

В конфиге возможны три привычных в С++ вида:

• # однострочный до конца строки
• // тоже однострочный до конца строки
• /*… */ многострочный комментарий включая переносы строк

Внешние подключения (Includes)

Это, в общем, самая вкусная вкусняшка.
# file: quote.cfg quote = "Criticism may not be agreeable, but it is necessary." " It fulfils the same function as pain in the human" " body. It calls attention to an unhealthy state of" " things.\n" "\t--Winston Churchill";
# file: test.cfg info: { name = "Winston Churchill"; @include "quote.cfg" country = "UK"; };

С API

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

Описание использованых функций ниже

#include #include #include /* Данный пример читает конфигурационный файл "example.cfg" и выводит его составляющие */ int main(int argc, char **argv) { /* используются свои типы. */ config_t cfg; config_setting_t *setting; const char *str; config_init(&cfg); /* обязательная инициализация */ /* Читаем файл. Если ошибка, то завершаем работу */ if(! config_read_file(&cfg, "example.cfg")) { fprintf(stderr, "%s:%d - %s\n", config_error_file(&cfg), config_error_line(&cfg), config_error_text(&cfg)); config_destroy(&cfg); return(EXIT_FAILURE); } /* Поиск некого значения "name". */ if(config_lookup_string(&cfg, "name", &str)) printf("Store name: %s\n\n", str); else fprintf(stderr, "No "name" setting in configuration file.\n"); /* Вывод списка книжек с полок. */ setting = config_lookup(&cfg, "inventory.books"); if(setting != NULL) { int count = config_setting_length(setting); int i; printf("%-30s %-30s %-6s %s\n", "TITLE", "AUTHOR", "PRICE", "QTY"); for(i = 0; i < count; ++i) { config_setting_t *book = config_setting_get_elem(setting, i); /* Выводим только те записи, если они имеют все нужные поля. */ const char *title, *author; double price; int qty; if(!(config_setting_lookup_string(book, "title", &title) && config_setting_lookup_string(book, "author", &author) && config_setting_lookup_float(book, "price", &price) && config_setting_lookup_int(book, "qty", &qty))) continue; printf("%-30s %-30s $%6.2f %3d\n", title, author, price, qty); } putchar("\n"); } /* Вывод всех фильмов с полки. */ setting = config_lookup(&cfg, "inventory.movies"); if(setting != NULL) { unsigned int count = config_setting_length(setting); unsigned int i; printf("%-30s %-10s %-6s %s\n", "TITLE", "MEDIA", "PRICE", "QTY"); for(i = 0; i < count; ++i) { config_setting_t *movie = config_setting_get_elem(setting, i); /* Вывод только тех медиа, у которых заполнены все поля. */ const char *title, *media; double price; int qty; if(!(config_setting_lookup_string(movie, "title", &title) && config_setting_lookup_string(movie, "media", &media) && config_setting_lookup_float(movie, "price", &price) && config_setting_lookup_int(movie, "qty", &qty))) continue; printf("%-30s %-10s $%6.2f %3d\n", title, media, price, qty); } putchar("\n"); } config_destroy(&cfg); /* Освободить память обязательно, если это не конец программы */ return(EXIT_SUCCESS); }

Небольшое описание функционала

Полное описание в документации .

config_t - тип файла конфигурации (это ещё не запись). Грубо говоря, основной контейнер.
config_setting_t - объект элемента конфигурации. В примере используется указатель, возвращаемый контейнером на искомый элемент.
int config_read_file (config_t * config, const char * filename) - функция читает конфигурационный файл filename в память и заполняет объект типа config_t . Можно не читать из файла, а сразу «скормить» строку в config_read_string() или отдать дескриптор файла в config_read()
int config_lookup_string (const config_t * config, const char * path, const char ** value) - ищет и возвращает значение в виде указателя на строку value , по заданному пути path внутри конфига config .
config_setting_t * config_lookup (const config_t * config, const char * path) - ищет запись внутри конфига по заданному внутреннему пути и возвращает её.
config_setting_t * config_setting_get_elem (const config_setting_t * setting, unsigned int index) - используется для массивов, списков чтобы возвращать из него элементы с таким-то номером по порядку
int config_setting_lookup_string (const config_setting_t * setting, const char * name, const char ** value) -
возвращает значение value дочернего элемента name относительно заданной записи setting
Когда же надо получить значение в конкретно заданной записи, то используются функции типа
int config_setting_get_int (const config_setting_t * setting)

C++ API

Тот же пример, но на С++. Полная документация на сайте

#include #include #include #include using namespace std; using namespace libconfig; // Пример, читающий конфигурационный файл "example.cfg" и выводит его записи int main(int argc, char **argv) { Config cfg; // Прочитать файл. Или выйти с ошибкой // Класс в С++ не возвращает ошибку, а кидает исключение try { cfg.readFile("example.cfg"); } catch(const FileIOException &fioex) { std::cerr << "I/O error while reading file." << std::endl; return(EXIT_FAILURE); } catch(const ParseException &pex) { std::cerr << "Parse error at " << pex.getFile() << ":" << pex.getLine() << " - " << pex.getError() << std::endl; return(EXIT_FAILURE); } // Получить некое название. try { string name = cfg.lookup("name"); cout << "Store name: " << name << endl << endl; } catch(const SettingNotFoundException &nfex) { cerr << "No "name" setting in configuration file." << endl; } const Setting& root = cfg.getRoot(); // Найти все книжки на полке. try { const Setting &books = root["inventory"]["books"]; int count = books.getLength(); cout << setw(30) << left << "TITLE" << " " << setw(30) << left << "AUTHOR" << " " << setw(6) << left << "PRICE" << " " << "QTY" << endl; for(int i = 0; i < count; ++i) { const Setting &book = books[i]; // Находим только те записи, что имеют все заполненные поля. string title, author; double price; int qty; if(!(book.lookupValue("title", title) && book.lookupValue("author", author) && book.lookupValue("price", price) && book.lookupValue("qty", qty))) continue; cout << setw(30) << left << title << " " << setw(30) << left << author << " " << "$" << setw(6) << right << price << " " << qty << endl; } cout << endl; } catch(const SettingNotFoundException &nfex) { // Ignore. } // Вывод всех фильмов с полки. try { const Setting &movies = root["inventory"]["movies"]; int count = movies.getLength(); cout << setw(30) << left << "TITLE" << " " << setw(10) << left << "MEDIA" << " " << setw(6) << left << "PRICE" << " " << "QTY" << endl; for(int i = 0; i < count; ++i) { const Setting &movie = movies[i]; // Вывод только тех, что содержат все поля. string title, media; double price; int qty; if(!(movie.lookupValue("title", title) && movie.lookupValue("media", media) && movie.lookupValue("price", price) && movie.lookupValue("qty", qty))) continue; cout << setw(30) << left << title << " " << setw(10) << left << media << " " << "$" << setw(6) << right << price << " " << qty << endl; } cout << endl; } catch(const SettingNotFoundException &nfex) { // Ignore. } return(EXIT_SUCCESS); }
Тут тот же принцип, что и в функциональном стиле, только перед получением данных из конфига необходимо получать корневой элемент cfg.getRoot(); и уже потом от него обращаться к остальным элементам. Так же надо быть внимательным к тому, что практически на все ошибки кидаются исключения

Заключение

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

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

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

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

Типы Конфигурационных файлов

Сетевое устройство Cisco содержит два конфигурационных файла:

Рабочий конфигурационный файл - используется во время текущей работы устройства

Конфигурационный файл запуска - используется в качестве резервной конфигурации и загружается при запуске устройства

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

Конфигурационный файл запуска

Конфигурационный файл запуска (конфигурация запуска) используется во время системного запуска, чтобы сконфигурировать устройство. Конфигурационный файл запуска или файл конфигурации запуска хранится в энергонезависимой памяти RAM (NVRAM) . Так как NVRAM является энергонезависимой, когда устройство Cisco выключается, файл остается. Файлы конфигурации запуска загружаются в RAM каждый раз при запуске или перезагрузке маршрутизатора. Как только конфигурационный файл загружается в RAM, он считается рабочей конфигурацией .

Рабочая Конфигурация

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

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

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

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

Конфигурационный файл - файл, в котором описываются:
- структура программной системы; и/или
- вспомогательные параметры, определяющие ее конкретную настройку.
Обычно конфигурационный файл реализуется в виде текстового файла, который интерпретируется программной системой.

• - Камень судьбы...

  Энциклопедия мифологии

• - поименованная совокупность байтов, записанная на жёстком или гибком магнитном диске, в которой хранится отдельный элемент овой системы, напр. документ Word или рисунок...

  Энциклопедия техники

• - совокупность однотипных по структуре и способу использования порций информации, размещаемая на носителях данных внешней памяти ЭВМ и рассматриваемая в процессе передачи и обработки как единое целое...

  Большой энциклопедический политехнический словарь

• - Собрание/комплекс взаимосвязанной информации в компьютере, хранящейся в его накопителе как единое целое. Файл может содержать программу, которая может быть скопирована в оперативную память и исполнена...

  Словарь бизнес терминов

• - совокупность связанных записей, рассматриваемая как единое целое...

  Большой бухгалтерский словарь

• - совокупность упорядоченных и взаимосвязанных порций информации, имеющая описание для идентификации отд. порции...

  Естествознание. Энциклопедический словарь

• - Файл, содержащий системную информацию о работе сервера и информацию о действиях пользователей: - дату и время визита пользователя; - IP-адрес компьютера пользователя; - наименование браузера пользователя...

  Словарь бизнес терминов

• - файл, содержащий системную информацию о работе сервера и информацию о действиях пользователей: - дату и время визита пользователя; - IP-адрес компьютера пользователя; - наименование браузера пользователя...

  Финансовый словарь

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

  Финансовый словарь

• - совокупность связанных записей, рассматриваемая как единое целое. Например одна строка кадровой анкеты рассматривается как элемент, вся анкета – как запись, полный набор таких записей – как файл...

  Большой экономический словарь

• - совокупность упорядоченных и взаимосвязанных порций информации из однородных элементов, имеющая описание для идентификации отдельных порций...

  Современная энциклопедия

• - ; мн. фа/йлы, Р....

  Орфографический словарь русского языка

• - КОНФИГУРА́-ИЯ, -и, ж. . Внешнее очертание, а также взаимное расположение предметов или их частей. К. изделия...

  Толковый словарь Ожегова

• - -а, муж. . В ЭВМ: поименованная область данных. Имя файла. Хранение файла. Текстовые файлы. | прил. файловый, -ая, -ое. Файловые системы...

  Толковый словарь Ожегова

• - файл I м. Специально организованная структура данных во внешней памяти компьютера, имеющая свое наименование; область его памяти, содержащая какие-либо данные и программы...

  Толковый словарь Ефремовой

• - конфигураци"...

  Русский орфографический словарь

"Конфигурационный файл" в книгах

Приложение 2. Конфигурационный файл клиента Tor.

автора Стручков Юрий

Приложение 2. Конфигурационный файл клиента Tor. Конфигурационный файл torrc находится в папке Application DataVidalia Программа Tor при загрузке считывает конфигурационный файл и устанавливает рабочие параметры в соответствии со значениями команд в

Приложение 3. Конфигурационный файл фильтрующего прокси Polipo

Из книги Установка и настройка Tor автора Стручков Юрий

Приложение 3. Конфигурационный файл фильтрующего прокси Polipo Здесь приводится простейший вариант конфигурационного файла polipo.conf (только незакомментированные команды). ### Basic configurationproxyaddress = "127.0.0.1"proxyport = 8118allowedclients = 127.0.0.1allowedports = 1-65535proxyName = "localhost" cacheIsShared = falsesocksParentProxy =

Файл

Из книги Windows Vista автора Вавилов Сергей

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

Файл

Из книги Linux Mint и его Cinnamon. Очерки применителя автора Федорчук Алексей Викторович

Файл Пункты меню Файл сгруппированы в несколько блоков:Первый из них посвящен созданию новых файлов. Пункт Создать предполагает открытие в окне редактирования пустого документа. Пункт Создать из шаблона предоставляет на выбор с десяток вариантов, позволяющих создать

REG-файл

Из книги Реестр Windows 7 автора Климов Александр Петрович

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

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

автора Смит Родерик В.

Конфигурационный файл Samba Для настройки Samba используется файл smb.conf. В большинстве дистрибутивных пакетов Linux он помещается в один из следующих каталогов: /etc, /etc/samba или /etc/samba.d. Подобно многим другим конфигурационным файлам Linux, в smb.conf для обозначения комментариев в начало

Главный конфигурационный файл BIND

Из книги Сетевые средства Linux автора Смит Родерик В.

Главный конфигурационный файл BIND Основные опции BIND задаются в главном конфигурационном файле с именем named.conf. Этот файл обычно располагается в каталоге /etc. В некоторых дистрибутивных пакетах Linux файл с опциями, установленными по умолчанию, в каталоге /etc отсутствует. В

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

Из книги Сетевые средства Linux автора Смит Родерик В.

Конфигурационный файл Postfix Особенности выполнения Postfix определяются содержимым конфигурационного файла main.cf, который обычно располагается в каталоге /etc/postfix. Большинство записей в этом файле представлены в следующем формате:опция = значениеНекоторые записи main.cf

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

Из книги Linux-сервер своими руками автора

20.2. Конфигурационный файл XF86Config Как и любая другая программа, система X Window имеет свой конфигурационный файл. Согласно традиции, конфигурационные файлы хранятся в каталоге /etc. Главный конфигурационный файл называется XF86Config и находится в каталоге /etc/X11. В этом файле

9.3.1. Конфигурационный файл /etc/syslog.conf

автора Колисниченко Денис Николаевич

9.3.1. Конфигурационный файл /etc/syslog.conf Это простой текстовый файл, каждая непустая и незакомментированная (знак комментария - #) строка которого имеет следующий формат:<селектор>[;<селектор>...] <действие>Селектор представляет собой правило отбора сообщений, а

18.5. Расширенные настройки SQUID. Конфигурационный файл squid.conf

Из книги Linux: Полное руководство автора Колисниченко Денис Николаевич

18.5. Расширенные настройки SQUID. Конфигурационный файл squid.conf 18.5.1. Параметры сети В файле squid.conf могут быть заданы следующие параметры сети:? http_port - порт для запросов клиентов. С этого порта прокси-сервер будет ожидать и обрабатывать запросы клиентов. Значение по умолчанию

3.1.4. Конфигурационный файл /etc/yum.conf

автора Колисниченко Денис Николаевич

3.1.4. Конфигурационный файл /etc/yum.conf Сейчас мы поговорим об основном конфигурационном файле /etc/yum.conf. Для его редактирования вам нужны права пользователя root, поэтому, чтобы открыть данный файл для редактирования, нам придется ввести в терминале следующую команду:su -с "gedit

4.1.2.1. Основной конфигурационный файл

Из книги Fedora 8 Руководство пользователя автора Колисниченко Денис Николаевич

4.1.2.1. Основной конфигурационный файл Основной конфигурационный файл /etc/X11/xorg.conf состоит из следующих секций. Files - пути к файлам, которые используются графической подсистемой, обычно тут указываются пути к шрифтам. Данная секция может отсутствовать, если используются

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

Из книги Fedora 8 Руководство пользователя автора Колисниченко Денис Николаевич

7.3.2. Конфигурационный файл GRUB Конфигурационный файл GRUB называется /boot/grub/grub.conf. В ранних версиях этот файл назывался menu.lst, а теперь menu.lst - это ссылка на файл grub.conf, хотя в некоторых дистрибутивах, например, в Ubuntu, данный файл до сих пор называется menu.lst. Впрочем, к Fedora это

32.2 Конфигурационный файл /etc/fstab

Из книги Руководство по переходу на Ubuntu 10.04 LTS «Lucid Lynx» автора Неворотин Вадим

32.2 Конфигурационный файл /etc/fstab А теперь собственно к практике. Осталось только рассказать, как же устроен файл /etc/fstab и что в него надо писать. Начну с того, что этот файл является системным, поэтому для его редактирования нужны права root. Если вы забыли, как редактировать

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

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

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

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

Methody@localhost:~ $ cat .vimrc so $VIMRUNTIME/vimrc_example.vim " Some mappings map:wall!^M map! ^O:wall!^M " Tune up set shiftwidth=2 tabstop=8 history=200 viminfo="50 set showmode showmatch showcmd ruler modeline set autoindent ignorecase smartcase set nohlsearch noincsearch set dir=/var/tmp set wildmode=list:longest,full set wildmenu " Colouring syntax on colorscheme desert Пример 12.2. Настройки редактора vim

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

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

Methody@localhost:~ $ cat .i18n LANG=ru_RU.KOI8-R LANGUAGE=ru_RU.KOI8-R SYSFONTACM=koi8-r SYSFONT=UniCyr_8x16 DICTIONARY=russian MPAGE="-CKOI8-R" export DICTIONARY MPAGE Пример 12.3. Файл настройки языковых особенностей

Однако хранить настройки специфической программы (не нужные всем остальным) в окружении – не самое удачное решение: синтаксис, задающий переменную окружения , слишком прост (имя_переменной=значение ), а самих переменных становится слишком много, поэтому при просмотре трудно выделить, какая из них к какой группе настроек относится. Если пытаться упаковать все настройки в значение одной переменной, это значение окажется трудночитаемым, и все преимущество текстового формата сойдет на нет. Например, стандартный конфигурационный файл утилиты 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 , например, секционируется по адресату (провайдеру) плюс отдельная секция "по умолчанию". Сами секции отделяются друг от друга заголовками, заключенными в квадратные скобки:

Root@localhost:~> cat .wvdialrc Modem = /dev/modem Baud = 115200 Init1 = ATZ Init2 = ATQ0 L0 M4 V1 E1 S0=0 &C1 &D2 +FCLASS=0 Auto DNS = on Modem Type = Analog Modem Phone = 0123456 Username = fireman Password = Fire!Fire! TOnline = true Phone = 0246813 Username = cop-120 Password = gimmethegun Force Address=10.0.0.120 Пример 12.4. Секционированный конфигурационный файл

Утилита 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 , оформлен в самодокументированном стиле:

Methody@localhost:~ $ cat /etc/man.conf . . . # NOCACHE keeps man from creating cache pages ("cat pages") # (generally one enables/disable cat page creation by # creating/deleting the directory they would live in – man # never does mkdir) # # NOCACHE # The command "man -a xyzzy" will show all man pages for xyzzy. # When CMP is defined man will try to avoid showing the same # text twice. (But compressed pages compare unequal.) # CMP /usr/bin/cmp -s . . . Пример 12.5. Самодокументированный конфигурационный файл

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

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

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