Файл CONFIG известен как файл конфигурации; используется для настройки параметров и основных настроек для нескольких компьютерных программ. Некоторые программы читают свои файлы конфигурации только при запуске. Другие периодически проверяют файлы конфигурации на наличие изменений.
КОНФИГУРАЦИЯ Формат файла
Формат файла CONFIG используется для серверных процессов, программных приложений и настроек операционной системы. Программист может написать код, чтобы заставить программное обеспечение читать файлы конфигурации снова и снова через определенный период времени и применять изменения к текущему процессу. Для sysntax файла CONFIG не существует четких стандартов или строгих соглашений. Например, файл Microsoft Web.config относится к формату файла CONFIG, который состоит из наборов тегов на основе XML; можно редактировать с помощью Microsoft Visual Studio или любого другого текстового редактора.
Примеры конфигурационных файлов:
Поскольку файлы конфигурации не создаются в соответствии с какими-либо правилами, стандартами или соглашениями, эти файлы могут быть написаны с использованием разных форматов. Файл .config может быть основан на XML, JSON или любом другом формате. Ниже приведены примеры файлов конфигурации для известных операционных систем и программ:
У 9 из 10 сайтов внезапно обнаружил Атрибуты конфигурационных файлов 700 вместо 444.
Файлы конфигурации в Linux
Каждая программа Linux представляет собой исполняемый файл, содержащий список кодов операций, которые ЦП выполняет для выполнения типичных операций. Работа почти каждой программы может быть настроена в соответствии с вашими требованиями путем изменения ее конфигурационных файлов. Несколько файлов конфигурации в системе Linux находятся в каталоге /etc. Файлы конфигурации можно разделить на следующие категории:
| Доступ к файлам | /etc/host.conf | Сообщает серверу сетевого домена, как искать имена хостов. |
| Загрузка и вход/выход из системы | /etc/rc.d/rc.local | Неофициально. Может вызываться из rc, rc.sysinit или /etc/inittab. |
| Файловая система | /etc/mtools.conf | Конфигурация для всех операций (mkdir, копирование, форматирование и т. д.) в файловой системе типа DOS. |
| Системное администрирование | /etc/shells | Содержит список возможных «оболочек», доступных системе. |
| Сеть | /etc/gated.conf | Конфигурация для gated. Используется только демоном gated. |
| Системные команды | /etc/logrotate.conf | Конфигурация динамического компоновщика. |
| Демоны | /etc/httpd.conf | Файл конфигурации для Apache, веб-сервера. Обычно этот файл находится не в каталоге /etc. |
| Пользовательские программы | /etc/lynx.cfg | Настройки прокси |
Пример файла AWS CONFIG
Часто используемые параметры конфигурации и учетные данные можно сохранить в файлах CONFIG, которые поддерживаются интерфейсом командной строки AWS. Файл CONFIG должен быть текстовым файлом в следующем формате:
Ошибка вот блиц Конфигурационный Файл — Решение Проблемы !
[default] region = us-west-2 output = json [profile dev-user] region = us-east-1 output = text [profile developers] role_arn = arn:aws:iam::123456789012:role/developers source_profile = dev-user region = us-west-2 output = json
Пример файла SSH CONFIG
Файл конфигурации OpenSSH на стороне клиента называется CONFIG и хранится в каталоге .ssh. Файл SSH CONFIG имеет следующую структуру:
Host hostname1 SSH_OPTION value SSH_OPTION value Host hostname2 SSH_OPTION value Host * SSH_OPTION value
Пример файла конфигурации Python
Файл конфигурации Python может выглядеть так:
#!/usr/bin/env python import preprocessing mysql = < «host»: «localhost», «user»: «root», «passwd»: «my secret password», «db»: «write-math», >preprocessing_queue = [ preprocessing.scale_and_center, preprocessing.dot_reduction, preprocessing.connect_lines, ] use_anonymous = True
использованная литература
- Понимание файлов конфигурации Linux
- Настройки файла конфигурации и учетных данных
- Файлы конфигурации в Python
See Also
- ABC — файл байт-кода ActionScript
- ANE — собственное расширение Adobe AIR
- APA — Архив проекта разработки RSView
- FODT — плоский XML-документ OpenDocument
- MAN — Руководство Unix
Источник: docs.fileformat.com
Файлы конфигурации приложений
Файл конфигурации приложения — это XML-файл, используемый для управления привязкой сборки. Он может перенаправлять приложение с одной версии параллельной сборки в другую версию той же сборки. Это называется конфигурацией для каждого приложения. Файл конфигурации приложения применяется только к определенному манифесту приложения и зависимым сборкам.
Для изолированных компонентов, скомпилированных с помощью встроенного манифеста ISOLATIONAWARE_MANIFEST_RESOURCE_ID, требуется отдельный файл конфигурации приложения. Манифестам, управляемым с помощью CreateActCtx, требуется отдельный файл конфигурации приложения.
Перенаправление, указанное в файле конфигурации приложения, может переопределить версии сборки, указанные в манифестах приложения и файлах конфигурации издателя. Например, если файл конфигурации издателя указывает, что все ссылки на сборку будут перенаправлены с версии 1.0.0.0 на 1.1.0.0, файл конфигурации приложения можно использовать для перенаправления конкретного приложения на использование версии 1.0.0.0. Файл конфигурации приложения применяется только к указанному манифесту приложения и зависимым сборкам.
Файлы конфигурации приложения содержат элементы и атрибуты, показанные в следующей таблице.
| Конфигурация | Да |
| windows | Да |
| publisherPolicy | Да |
| Применить | Да |
| Среда выполнения | Нет |
| assemblyBinding | Да |
| Зондирования | Нет |
| privatePath | Да |
| Зависимостей | Нет |
| dependentAssembly | Да |
| assemblyIdentity | Да |
| type | Да |
| name | Да |
| language | Нет |
| processorArchitecture | Да |
| version | Да |
| Publickeytoken | Нет |
| bindingRedirect | Да |
| oldVersion | Да |
| newVersion | Да |
Расположение файла
Файлы конфигурации приложения должны быть установлены в том же расположении, что и манифест приложения.
Синтаксис имени файла
Имя файла конфигурации приложения — это имя исполняемого файла приложения, за которым следует .config.
Например, файл конфигурации приложения, ссылающийся на Example.exe или Example.dll, будет использовать синтаксис имени файла, показанный в следующем примере. Вы можете опустить поле идентификатора ресурса> , если устанавливается файл конфигурации как отдельный файл или если идентификатор ресурса равен 1.
example.exe.идентификатор> ресурса.config
example.dll.идентификатор> ресурса.config
Элементы
Имена элементов и атрибутов чувствительны к регистру. Значения элементов и атрибутов не учитывают регистр, за исключением значения атрибута типа.
настройка
Элемент контейнера для элементов windows и среды выполнения файла конфигурации приложения. Обязательный.
Windows
Включает части файла конфигурации приложения, которые применяются к перенаправлению сборок Win32.
Автор приложения не должен включать файл конфигурации с подэлементом Windows в составе приложения. Это может быть разрешено, если единственной целью файла конфигурации является включение функций privatePath элемента пробы . Элемент probing недоступен в системах более ранних версий, чем Windows Server 2008 R2 и Windows 7.
publisherPolicy
Указывает, следует ли применять политику издателя.
Этот элемент содержит атрибуты, показанные в следующей таблице.
| Применить | Значение «да» применяет политику издателя. Это параметр по умолчанию. Значение «нет» не применяет политику издателя. |
среда выполнения
Включает части файла конфигурации приложения, которые применяются к перенаправлению сборок .NET.
assemblyBinding
Включает сведения о перенаправлении для приложения и сборки, затронутой этим файлом конфигурации приложения. Первым подэлементом assemblyBinding должно быть свойство assemblyIdentity , которое идентифицирует приложение.
Начиная с Windows Server 2008 R2 и Windows 7 элемент assemblyBinding может включать в себя подэлемент проверки .
Зондирования
Необязательный вложенный элемент элемента assemblyBinding , который расширяет поиск сборок на дополнительные каталоги. Дополнительные каталоги не обязательно должны быть подкаталогами каталога сборки.
Этот элемент недоступен в системах, предшествующих Windows Server 2008 R2 и Windows 7, и может использоваться только в элементе Windows .
Этот элемент содержит атрибуты, показанные в следующей таблице.
| privatePath | Указывает относительные пути к подкаталогам базового каталога приложения, который может содержать сборки. Можно указать не более девяти путей к подкаталогу. Разделите путь к каждому подкаталогу точкой с запятой. |
Можно использовать специальный описатель с двойными точками в пути, чтобы обозначить родительский каталог текущего каталога. С помощью двойных точек можно указать не более двух уровней над текущим каталогом. Не используйте тройные точки. Например, приложение, использующее следующий проверочный элемент, проверяет наличие дополнительных каталогов для сборки.
dependency
Элемент контейнера по крайней мере для одного dependentAssembly. Каждый dependAssembly может находиться в пределах ровно одной зависимости. Этот элемент не содержит атрибуты. Необязательный элемент.
dependentAssembly
Первый вложенный элемент должен быть элементом assemblyIdentity , который определяет параллельную сборку, перенаправленную файлом конфигурации приложения. У объекта dependentAssembly нет атрибутов.
assemblyIdentity
В качестве первого подэлемента элемента assemblyBindingassemblyIdentity описывает и однозначно идентифицирует приложение. Файл конфигурации приложения перенаправляет привязку этого приложения в параллельные сборки. Например, следующая assemblyIdentity указывает, что файл конфигурации приложения влияет на привязку приложения mysampleApp к параллельным сборкам. Перенаправляемые сборки будут определены в dependentAssembly.
В качестве первого подэлемента элемента dependentAssemblyassemblyIdentity описывает параллельную сборку, от которой зависит приложение. Файл конфигурации приложения перенастраивает удостоверение этой необходимой сборки. Например, следующие assemblyIdentity и bindingRedirect перенастраивает зависимость от Microsoft.Windows.SampleAssembly с версии 2.0.0.0 на версию 2.1.0.0.
Обратите внимание, что каждая assemblyIdentity , включенная в dependentAssembly , должна точно соответствовать assemblyIdentity в манифесте сборки.
Элемент assemblyIdentity имеет следующие атрибуты. У него нет подэлементов.
| type | Значение должно быть win32 (в нижнем регистре). Обязательный. |
| name | Атрибут name определяет приложение, на которое влияет файл конфигурации приложения или перенаправляемая сборка. Используйте следующий формат для имени: Organization.Division.Name. Обязательный. Например: Microsoft.Windows.MysampleApp или Microsoft.Windows.MysampleAsm. |
| language | Определяет язык. Необязательный элемент. Для assemblyIdentity , ссылающегося на сборку, если сборка зависит от языка, укажите код языка DHTML. Если сборка используется по всему миру (нейтралитет языка), задайте значение «*». |
| processorArchitecture | Указывает процессор, на котором выполняется приложение. |
| version | Указывает версию приложения или сборки. Используйте синтаксис версии из четырех частей: mmmm.nnnn.чикo.pppp. Обязательный. |
| Publickeytoken | Для assemblyIdentity , ссылающегося на сборку, это шестнадцатеричная строка из 16 символов, представляющая последние 8 байт хэша SHA-1 открытого ключа, под которым подписывается сборка. Открытый ключ, используемый для подписи каталога, должен иметь значение 2048 бит или больше. Требуется для всех общих параллельных сборок. |
bindingRedirect
Элемент bindingRedirect содержит сведения о перенаправлении для привязки сборки. Каждый bindingRedirect должен быть включен только в один dependentAssembly. Синтаксис новой и старой версий из четырех частей должен указывать одну и ту же основную и дополнительную версии.
Этот элемент содержит атрибуты, показанные в следующей таблице.
| oldVersion | Указывает версию сборки, для которой выполняется переопределение и перенаправление. Используйте синтаксис версии из четырех частей nnnnn.nnnnn.nnnnn.nnnnn. Укажите диапазон версий с помощью дефиса без пробелов. Например, 2.14.3.0 или 2.14.3.0 2.16.0.0. Обязательный. |
| newVersion | Указывает версию заменяемой сборки. Используйте синтаксис версии из четырех частей nnnnn.nnnnn.nnnnn.nnnnn. |
Комментарии
Файлы конфигурации приложения не указываются.
Источник: learn.microsoft.com
Хозяйке на заметку: разбираемся с конфигурационными файлами Linux
Понимая, как работают конфигурационные файлы, вы можете существенно повысить уровень владения Linux. В статье рассказываем, как конфигурационные файлы управляют пользовательскими разрешениями, системными приложениями, демонами и другими административными задачами в многопользовательской среде.
Введение в конфигурационные файлы
Само ядро можно назвать «программой». Зачем ядру конфигурационные файлы? Ему нужно знать список пользователей и групп в системе, управлять правами доступа к файлам (определять, может ли файл открываться конкретным пользователем в соответствии с разрешениями UNIX_USERS).
Такие файлы считываются не программами, а функцией, предоставляемой системной библиотекой и используемой ядром. Предположим, программа, которой требуется зашифрованный пароль пользователя, не должна открывать файл /etc/passwd. Вместо этого следует вызвать функцию системной библиотеки getpw(). Этот тип функции также известен как системный вызов. Через системную библиотеку ядро открывает файл /etc/passwd и затем ищет пароль запрошенного пользователя.
Большинство конфигурационных файлов Linux находятся в каталоге /etc, если не указано иное. В зависимости от сферы применения и служб, на которые они влияют, конфигурационные файлы делят на несколько категорий, о которых и пойдёт речь дальше.
Доступ к файлам
/etc/host.conf
Сообщает серверу сетевого домена, как искать имена хостов. Сначала идёт /etc/hosts, затем имя сервера. Файл можно изменить через netconf.
/etc/hosts
Содержит список известных хостов в локальной сети. Может использоваться, если IP-адрес системы не генерируется динамически.
/etc/hosts.allow
Справочная страница, аналогичная hosts_access.
/etc/hosts.deny
Справочная страница, аналогичная hosts_access.
Загрузка и вход/выход из системы
/etc/issue
Разберём на примере утилиты wget. В /etc/ есть файл /etc/wgetrc. В домашнем каталоге есть файл с именем .wgetrc, который описывает настроенную конфигурацию (которая будет загружена только тогда, когда пользователь выполнит команду wget). Другие пользователи также могут иметь файл .wgetrc в своем домашнем каталоге (/home/other).
Этот файл будет прочитан, только тогда, когда пользователь запустит команду wget. Иными словами, файл /etc/wgetrc предоставляет значения «по умолчанию» для wget, а файл /home/xxx/.wgetrc перечисляет «настройки» для определенного пользователя.
Важно понимать, что это «общее правило», и оно не обязательно верно для всех случаев. Например, у программы pine нет файлов в /etc/, только пользовательская конфигурация в домашнем каталоге пользователя в файле с именем .pinerc. Другие программы могут иметь только файл конфигурации по умолчанию в /etc/ и могут не позволять пользователям «настраивать» их.
Коротко о главном
В этой статье мы разобрали конфигурационные файлы, которые управляют пользовательскими разрешениями, системными приложениями, демонами и др. А также рассмотрели особенности процесса изменения конфигурационных файлов.
Источник: habr.com