Что содержится в файле etc services
Операционные системы UNIX хранят так называемый файл служб в / etc / services. Он хранит информацию о многочисленных услугах, которые клиентские приложения могут использовать на компьютере. Внутри файла указано имя службы, номер порта и используемый протокол, а также любые применимые псевдонимы.
Номера портов сопоставляются с определенными службами, подобно тому, как файл hosts на компьютерах Windows сопоставляет имя хоста IP-адресу. Однако файл служб операционной системы UNIX не включает в себя IP-адреса, но вместо этого информация, например, является ли служба TCP или UDP и какие общие имена она может выполнять.
Простой текстовый редактор можно использовать для редактирования файла / etc / services, такого как Vim или Kate.
Пример файла служб UNIX
В UNIX ключевая роль файла конфигурации / etc / services заключается в том, что программы могут выполнять вызов сокетов getportbyname () в своем коде, чтобы понять, какой порт они должны использовать. Например, демона электронной почты POP3 будет делать getportbyname (POP3), чтобы получить номер 110, на котором работает POP3.
Идея состоит в том, что если все демоны POP3 используют getportbyname (), то независимо от того, какой вы запускаете POP3, вы всегда можете перенастроить свой номер порта, отредактировав / etc / services.
Замечания: Недостаточно использовать файл служб, чтобы выяснить, какие номера портов означают. Если вы хотите узнать, какие программы используют порты, вы должны использовать программу lsof для определения того, какие порты связаны с этими процессами. Если запуск lsof не подходит, вы должны исследовать порты в более общей ссылке.
Все файлы служб следуют одному и тому же синтаксису:
имя порта / протокол псевдонимы комментарии
Однако псевдоним и комментарий для каждой записи базы данных не нужны, как вы можете видеть в этом примере файл служб:
Исправление файла hosts.
ВНИМАНИЕ! В папке etc кроме файла hosts находятся другие файлы, которые предназначены для настройки сети. Это networks, protocol, services,hosts, lmhosts.sam. НЕ УДАЛЯЙТЕ эту папку совсем!.
- утилиты Microsoft Fix it — перейдите на сайт к его создателям и проделайте это двумя щелчками мыши.
- утилиты AVZ — очень подробно об этом написано здесь.
- при проверке компьютера с помощью бесплатной утилиты CureIt — скачать бесплатно Dr Web CureIt.
- исправление вручную.
При исправлении файла hosts вы должны знать о том, что здесь есть подводные камни. Вирусописатели используют нехитрые, но вполне эффективные уловки, чтобы подсунуть нам фиктивный файл hosts. Поэтому, если вы не можете открыть сайт и собираетесь проверить файл hosts, будьте предельно внимательны.
Использование hosts в своих целях.
Способ 1 — ускорить доступ к сайту с помощью hosts.
Браузер, обнаружив эти строки, не будет обращаться к DNS-серверу, а значит, процесс загрузки данного сайта будет проходить быстрее.
Как узнать IP сайта?
Способ 2 — запретить доступ к сайту.
Можно заблокировать нежелательные сайты, назначив против их имени либо локальный IP 127.0.0.1. либо IP какого-то другого сайта.
Например, по журналу вы видите, что ребенок часами играет в танчики. Строки в hosts файле вида:
Как видите, мы можем сделать то же самое что и вирусы, но уже с пользой.
Можно заблокировать наиболее зловредные баннерообменные сети и прочие рассадники рекламного мусора. Например строка вида:
Но не увлекайтесь этим особо — большие (от нескольких десятков кБ) файлы hosts требуют заметного времени на их просмотр, что подтормаживает работу. Но сильно экономить строки тоже не надо — файлы до 10 кБ ничего не тормозят даже на старых машинах, а 10 кБ — это многие сотни строк.
3.1. Традиционные файлы конфигурации
Как правило, если у приложения всего один файл конфигурации, его можно найти так: /home/(username)/.(app_name) . Но если конфигурационных файлов больше, то они хранятся в папке /home/(username)/.(app_name) .
Наглядный пример такого приложения — редактор vim .
Любая утилита GNU в качестве сервера
Ранее мы затронули пока ещё только один стандартный «строительный блок» из числа множества типовых сетевых средств UNIX (запуск сервера из-под xinetd ). А что, если попытаться построить 3-х уровневую клиент-серверную систему (это сейчас так модно…) используя в качестве транспортного механизма нижнего уровня любую консольную утилиту UNIX? Тот же telnet , консольные клиенты PostgreSQL – psql , или MySQL - mysql и т. д.? Для этого придётся только отобрать стандартные ввод ( SYSIN ) и вывод ( SYSOUT ) у такой консольной утилиты, и отдать их обрамляющему тонкому клиенту, используемому xinetd в качестве сервера. Это уже будет посложнее, но … «игра стоит свеч»! Создадим такой класс (здесь просто проще и компактнее излагать это в терминологии C++), это может быть что-то типа (файл chld.cc ):
Далее, мы сделаем вызывающую программу (сервер) parent (и использующую показанный класс chld ), которую будем вызывать, например, такой командой:
- т. е., мы хотим из этой программы вызывать нашего (а значит и произвольного) консольного агента с произвольным набором параметров его вызова, получая имя такого агента в качестве параметра. Два слова об избыточности: далее показаны два варианта использования перехваченных файловых дескрипторов ввода-вывода, конечно, в реальной жизни вам достаточно одного механизма, того, который вам больше нравится. Собрать нравящийся нам вариант мы можем такой командой сборки:
Итак, код программы сервера (файл parent.cc ):
Если в приводимых текстах и есть некоторая громоздкость, то она связана с необходимостью своевременного воссоздания перевода строки ( '\n' ), который потребуется для последующей операции чтения из потока … Автономно (без xinetd , для которого всё это готовится) убедиться, что всё это нормально функционирует можно так:
Дописываем строку в /etc/services :
И добавляем соответствующий новый файл parent в каталог /etc/xinetd.d :
Наконец, объясняем xinetd , что ему следует перечитать обновлённые нами конфигурации:
Теперь всё готово для того, чтобы проверить слаженность нашей серверной конструкции:
Обратим внимание на то обстоятельство, что и SYSIN и SYSOUT в коде любого такого сервера, и их использование в контексте xinetd — это всё символьно ориентированные потоки, или даже, если быть точнее, строчно ориентированные — если учесть умалчиваемые свойства потока cin или операций API чтения с консоли строки до завершающего '\n' . Тем не менее, как это может не показаться странным, к стандартным дескрипторам потоков при таком использовании может применяться всё множество специфических функций IP-сокетов, в виде: getpeerbyname( 0, . ), getsockopt( 1, . ), setsockopt( 1, . ), send( 1, . ), reqv( 0, . ), sendto( 1, . ), reqvfrom( 0, . ) . в общем — весь джентльменский набор API применимых к сокетам.
Простейший ретранслятор
Давайте напишем такую простую (проще уже не бывает) программу (исходный файл mycopy.cc , исполнимый - mycopy ):
Что это? Это - полнофункциональный TCP/IP сетевой эхо-сервер! Не верите? Для того, чтобы заставить его функционировать в этом качестве делаем следующие шаги (многие из них потребуют прав root ):
- В файл (в конец файла) /etc/services дописываем (мы решили в качестве порта использовать 50000 из числа «эфемерных» портов):
- Конфигурационный файл суперсервера /etc/xinetd.conf (всё дальнейшее рассмотрение будет ориентировано на xinetd , как более современное решение) отсылает нас в каталог /etc/xinetd.d . Это достаточно обычная практика в конфигурировании нынешнего Linux: все потенциально входящие в /etc/xinetd.conf текстовые секции (то, что было представлено строками в /etc/inetd.conf ) теперь представлены отдельными файлами в этом каталоге /etc/xinetd.d , которые обрабатываются последовательно, имя конкретного файла не играет роли, но может влиять на порядок обработки. Для наших целей достаточно создать в /etc/xinetd.d новый файл (имя его особого значения не имеет):
Особое значение здесь имеет поле server : значение может быть произвольное, но должно в точности соответствовать пути, куда мы поместим наш откомпилированный код сервера, обсуждавшийся выше.
Всё! Теперь мы готовы к испытанию созданного нами ретранслирующего сервера:
В абсолютных «плюсах» таких решения – предельная простота отладки для относительно несложных приложений (а большинство реальных серверов часто и не требует большей сложности): все комбинации запрос-ответ могут быть обкатаны в режиме простейшей текстовой консоли, после чего уже готовое изделие переносится под управление xinetd .
Часто в качестве первого возражения высказывается следующее: «… фи, а я люблю многопоточные сервера» (я, кстати, тоже их люблю). Но вариациями параметров конфигурации (строка wait ) можно научить xinetd запускать новый экземпляр сервера по запросу от нового клиента ( wait=no , по умолчанию: wait=yes ). Только это не многопоточный сервер, как его называют, а . как бы это лучше назвать по-русски? — многопроцессный: для каждого нового подсоединяющегося клиента порождается новая копия процесса сервера. Но, заметьте, что классические UNIX-сервера, построенные через fork() - они в точности такие же многопроцессные (собственно, это и было генеральным направлением построения серверов на протяжении почти 30 лет, до широкого распространения к концу 90-х годов API pthread_* и техники потоков).
Что такое файл hosts
Начнем с того у каждого сайта есть текстовое название и соответствующий уникальный цифровой код. Обычно в адресной строке мы пишем текстовый адрес сайта, поскольку так нам удобнее. Как только мы ввели название сайта, тут же специальный DNS-сервер преобразует это название в цифровой код – IP-адрес.
Файл hosts предназначен для ускорения доступа к сайту в обход DNS-сервера. То есть, если мы сами пропишем здесь пару IP-адрес и имя сайта, то обращения к DNS- серверу не будет.
Теперь вы понимаете, что если прописать эту пару неверно, то и переход будет не туда, куда вы ожидали или вообще никуда.
Вот эту особенность и используют вредоносные программы, дописывая в hosts неверные пары — IP адрес и имя сайта.
Что такое CSS: что такое каскадные таблицы стилей?
Прежде чем вы сможете использовать каскадные таблицы стилей, вам нужно понять, что они собой представляют и как они используются в современном дизайне и разработке сайтов.
В заключение.
После того, как вы удачно исправили свой hosts, обязательно проверьте компьютер на наличие вирусов и измените пароли от почтового ящика.
не хрена не понимаю ,надоть с самых начал )!
Большое спасибо.Очень интересная статья,обязательно буду посещать Ваш сайт,тогда возможно перестану бояться Компьютера.
Эта запись сделана утилитой CureIT, после сканирования вашего компа. Вредной она не является. Но вообще-то редактировать файл хост, я думаю, не должна ни одна утилита, я имею ввиду прописывать там что-то.. Я просто удаляю добавленные строки и все.
Прекрасный, просто замечательный сайт, удачи.
Татьяна, спасибо за подробную и полезную информацию! Очень понравился Ваш сайт! Успехов!
Папка etc распложена по следующему пути: «Пуск» — «Компьютер» — «Локальный диск С» — «Windows» — «System32» — «drivers» — «etc».
В папке ect находятся следующие стандартные файлы операционной системы hosts, lmhosts.sam, networks, protocol, services.
Если вы задаетесь вопросом, как выглядит папка etc, то вот вам изображение ее содержимого.
Мощность ОС Linux кроется в возможности гибко настраивать систему под наши потребности. Большинство дистрибутивов содержат продвинутые пользовательские интерфейсы для конфигурации системы, однако, по сути, они лишь редактируют текстовые файлы в различных системных папках. Понимая, как работают конфигурационные файлы, мы можем отказаться от этих интерфейсов и повысить свой уровень владения Linux.
Из этого руководства вы узнаете, где файлы конфигурации расположены и каковы их функции. Благодаря стандарту иерархии файловой системы (Filesystem Hierarchy Standard) папки и файлы, которые мы рассмотрим, сохраняют своё расположение даже в разных дистрибутивах.
Прим. переводчика:
Прежде чем двигаться дальше, следует разобраться, как устроена файловая система согласно стандарту FHS.
Все файлы и каталоги располагаются в корневой директории «/» . Даже если эти данные находятся на различных носителях, какие-то из этих каталогов присутствуют, а какие-то могут отсутствовать. В качестве примера можно привести каталоги, связанные с подсистемой X Window, когда каталогов может и не быть, если графическая подсистема не установлена. Однако, большинство каталогов присутствует на всех UNIX-подобных операционных системах и используется аналогичным образом.
Раздел | Корневая директория, содержащая всю файловую иерархию |
---|---|
/bin/ | Утилиты, которые доступны всем пользователям, такие как cat, ls, cp и др. |
/boot/ | Загрузочные файлы (файлы загрузчика, ядро, initrd, System.map). Как правило, выносится на отдельный раздел. |
/dev/ | Файлы устройств. Файлы в данном каталоге обычно создаются драйверами (например, /dev/null, /dev/zero, /dev/sda1). |
/etc/ | Основной каталог конфигурационных файлов системы. |
/home/ | Домашние директории с пользовательскими данными. Могут быть на отдельном разделе либо монтироваться по nfs. |
/lib/ | Основные библиотеки, необходимые для работы программ из /bin/ и /sbin/. |
/media/ | Точки монтирования для сменных носителей, таких как CD-ROM, DVD-ROM, флеш-карты. |
/mnt/ | Используется для монтирования временных файловых систем. |
/opt/ | Дополнительное программное обеспечение. Сюда обычно устанавливаются различные компиляторы и пользовательское ПО, которое не требует соответствия FSHS |
/proc/ | Виртуальная файловая система, представляющая состояние ядра операционной системы и запущенных процессов в виде файлов. |
/root/ | Домашняя директория пользователя root. |
/sbin/ | Основные системные программы для администрирования и настройки системы (например, init, iptables, ifconfig). |
/srv/ | Данные, специфичные для окружения системы. |
/tmp/ | Временные файлы. |
/usr / | Вторичная иерархия для данных пользователя, содержит большинство пользовательских приложений и утилит. |
/usr/bin/ | Дополнительные программы для всех пользователей, не являющиеся необходимыми в однопользовательском режиме. При различных решениях может монтироваться отдельно. |
/usr/include/ | Стандартные заголовочные файлы. |
/usr/lib/ | Библиотеки для программ, находящихся в /usr/bin/ и /usr/sbin/. |
/usr/sbin/ | Дополнительные системные программы (такие как демоны различных сетевых сервисов). |
/usr/share/ | Архитектурно-независимые общие данные. |
/usr/src/ | Исходные коды ядра. |
/usr/local/ | Третичная иерархия для данных, специфичных для данного хоста. Обычно содержит такие поддиректории, как bin/, lib/, share/. |
/var/ | Изменяемые файлы, такие как файлы регистрации (log-файлы), временные почтовые файлы, файлы спулеров. |
/var/lock/ | Лок-файлы, указывающие на занятость некоторого ресурса. |
/var/log/ | Различные log-файлы. |
/var/mail/ | Почтовые ящики пользователей. |
/var/run/ | Информация о запущенных программах (в основном о демонах). |
/var/spool/ | Задачи, ожидающие обработки (например, очереди печати, непрочитанные или неотправленные письма). |
/var/tmp/ | Временные файлы, которые должны быть сохранены между перезагрузками. |
Более детально можно почитать, например,тут.
Всё про папку etc
Найти где находится папка etc просто, жмите «Пуск» — «Компьютер» — «Локальный диск С» — «Windows» — «System32» — «drivers» — «etc».
Какие файлы в папке etc
Если у вас пропала папка etc то можете скачать папку etc Windows 7 и для Windows 8.
После некоторого затишья вновь пошла волна вопросов на тему «Не открывается страница..», «не могу войти на сайт…». Правило здесь одно – начать проверку с файла hosts.
2.3. /etc/default/
Исторически конфигурационные файлы в папке /etc/default/ содержали настройки сервисов/программ-демонов для их использования с системами инициализации, например upstart. Однако с появлением systemd эта папка стала использоваться в основном для настроек приложений пользовательского пространства.
Система не перезаписывает файлы в папке /etc/default/ . А значит, как только мы настроили там поведение приложений, оно не изменится при обновлении системы.
Что такое Google Fiber? И что такое Webpass?
Google Fiber - интернет-провайдер, специализирующийся на высокоскоростных интернет-соединениях. Он принадлежит Alphabet, материнской компании Google.
Когда Вы запускаете локальную вычислительную сеть, Ваша цель обеспечить пользователям среду, которая делает сеть простой. Важной частью этого является синхронизация данных типа учетных записей пользователей между всеми машинами. Мы видели, что для поиска имени хоста существует мощный и сложный сервис DNS. Для других задач нет такого специализированного сервиса. Кроме того, если Вы управляете маленькой LAN без выхода в Internet, устанавливать DNS иногда не оправдано.
Поэтому фирма Sun разработала Network Information System (NIS). NIS обеспечивает универсальные средства доступа к базе данных, которая может использоваться, например, чтобы распределять информацию, содержащуюся в файлах passwd и groups на все компьютеры в Вашей сети. Точно так же Вы можете использовать NIS, чтобы распределить информацию о hostname из файла /etc/hosts на все машины в сети.
NIS основан на RPC, включает сервер, клиентскую библиотеку и несколько административных инструментальных средств. Первоначально NIS был назван желтыми страницами или YP (Yellow Pages), это название все еще используется, чтобы обратиться к нему. К сожалению, это имя является маркой компании British Telecom, которая требовала, чтобы Sun отказалась от его использования. Тем не менее, YP остался префиксом в именах команд, относящихся к NIS таких, как ypserv и ypbind.
Сегодня NIS доступен фактически для всех Unix, и имеются свободные реализации. BSD Net-2 был основан на публичной версии, выпущенной Sun. Код клиентской библиотеки из этого релиза долго присутствовал в Linux libc , а административные программы были перенесены в Linux Swen ThЭmmler. Сервер NIS в публичной версии отсутствовал.
Peter Eriksson разработал новую версию под именем NYS. Она поддерживает как NIS, так и Sun NIS+. NYS не только обеспечивает набор инструментальных средств NIS и сервер, но также добавляет целый набор новых библиотечных функций, которые должны компилироваться в libc , если Вы желаете использовать этот пакет. Это включает новую схему конфигурации преобразования имен, которая заменяет текущую схему, использующую host.conf .
GNU libc, известная как libc6 , в сообществе Linux, включает модифицированную версию традиционной поддержки NIS, разработанную Thorsten Kukuk. Она поддерживает все библиотечные функции NYS и также использует расширенную схему конфигурации NYS. Вам все еще нужны инструментальные средства и сервер, но использование GNU libc избавляет от проблем с библиотеками.
Эта глава в основном рассматривает поддержку NIS в GNU libc . Для двух других пакетов приведенные здесь инструкции тоже могут пригодиться. Подробнее о вопросе можно узнать в NIS-HOWTO, кроме того на английском языке есть книга Managing NFS and NIS (автор Hal Stern, издательство O'Reilly).
NIS хранит информацию базы данных в файлах карт (maps), которые содержат пары ключ=значение. Примером такой пары является имя пользователя и зашифрованная форма его пароля для входа в систему. Карты хранятся на центральном главном компьютере, управляющем сервером NIS, откуда клиенты могут брать информацию через различные обращения RPC. Часто карты хранятся в DBM-файлах. DBM это простая библиотека управления базами данных, которая использует методы хеширования, чтобы ускорить операции поиска. Имеется свободная реализация DBM из проекта GNU, названная gdbm, которая является частью большинства дистрибутивов Linux.
Карты обычно генерируются из текстовых файлов типа /etc/hosts или /etc/passwd . Для некоторых файлов будет создано несколько карт, по одной для каждого типа ключа поиска. Например, Вы можете искать в файле hosts имя машины или ее IP-адрес. Соответственно, из этого файла будут получены две NIS-карты hosts.byname и hosts.byaddr . Таблица 13-1 перечисляет наиболее распространенные карты и файлы, из которых они сгенерированы.
Таблица 13-1. Стандартные карты NIS и соответствующие им файлы
Соответствие IP-адресов именам машин
Соответствие IP-адресов именам сетей
Пароли пользователей и их логины
Идентификаторы групп (Group ID) и имена групп в системе
Номера сервисов Sun RPC и их имена
Номера протоколов и их имена
Почтовые псевдонимы с именами
Вы можете найти поддержку иных файлов и карт в других NIS пакетах. Они обычно содержат информацию для прикладных программ, не обсуждаемых в этой книге, типа карты bootparams , которая используется сервером Sun bootparamd.
Для некоторых карт обычно используют прозвища (nicknames), которые короче и, следовательно, их проще напечатать. Обратите внимание, что эти прозвища понятны только ypcat и ypmatch, двум инструментальным средствам для проверки Вашей конфигурации NIS. Чтобы получить полный список прозвищ, понятных этим инструментальным средствам, выполните следующую команду:
Сервер NIS традиционно назван ypserv. Для средней сети один сервер обычно достаточен, большие сети могут выполнить несколько серверов на различных машинах и в разных сегментах сети, чтобы уменьшить загрузку на серверы и маршрутизаторы. Эти серверы должны быть синхронизированы объявлением одного из них главным (master server), а остальных подчиненными (slave servers). Карты создаются только на главном. Оттуда они распределяются на все подчиненные.
До сих пор мы очень неопределенно говорили относительно "сети". Имеется в виду особый термин в NIS: все хосты, разделяющие часть системных настроек по NIS: так называемый домен NIS (NIS domain). К сожалению, домены NIS не имеют абсолютно ничего общего с доменами, с которыми мы столкнулись в DNS. Во избежание неоднозначности мы будем всегда определять, какой тип домена имеется в виду.
NIS-домены имеют административную функцию. Они обычно невидимы для пользователей, за исключением совместного использования паролей всеми машинами в домене. Следовательно, имя, данное NIS-домену, нужно только администраторам. Обычно любое имя несет определенную смысловую нагрузку в сети. Например, администратор Virtual Brewery может создать два домена NIS: один для Brewery, второй для сети Winery, с именами brewery и winery соответственно. Можно и просто использовать имя DNS-домена и для NIS.
Чтобы устанавливать и отображать имя домена NIS Вашей машины, используйте команду domainname. Когда она вызывается без параметров, отображает текущее имя. Чтобы задать имя домена, надо задать его в качестве параметра. Введите от имени администратора:
NIS-домены определяют, к какому серверу NIS сделает запрос прикладная программа. Например, программа login на хосте в сети Winery должна опрашивать только NIS-сервер Winery (или одни из них, если там есть несколько) для получения информации о пароле пользователя, в то время как прикладная программа на машине в сети Brewery должна обращаться к серверу Brewery.
Возникает вопрос: а как клиент найдет, к какому серверу обращаться? Самое простое решение сводится к файлу конфигурации с указанием в нем имени нужной машины. Такой подход пригоден в сетях с одним сервером, но если несколько, клиент не сможет динамически запрашивать разные серверы (понятно, из одного домена) в зависимости от их доступности. Следовательно, реализации NIS полагаются на специальный daemon по имени ypbind, чтобы обнаружить подходящий сервер NIS в своем домене. Перед выполнением любого NIS-запроса, прикладная программа сначала выясняет у ypbind, какой сервер использовать.
ypbind исследует серверы, посылая широковещательные запросы в локальную IP-сеть. Первый ответивший сервер считается самым быстрым и используется во всех последующих запросах NIS. После того, как пройдет некоторый интервал, или если сервер становится недоступным, ypbind снова проводит поиск активных серверов.
Динамическое связывание полезно только, когда сеть обеспечивает больше, чем один сервер NIS. Динамическое связывание также представляет проблему защиты: ypbind просто верит, кто бы не отвечал. Так что если вместо сервера NIS ответит хакер, его ответ будет воспринят без тени недоверия. Само собой разумеется, это становится особенно ненадежным, если Вы управляете базами данных паролей по NIS. Чтобы принимать меры против этого, Linux ypbind обеспечивает два способа работы: либо обычный опрос локальной сети в поисках сервера NIS, либо указание имен машин с серверами NIS в своем файле настроек.
Ремейк 3.08 от 27.04.2012г. статьи, опубликованной в 2002 году.
2.4. Важные глобальные файлы конфигурации
Вот несколько наиболее полезных глобальных файлов конфигурации:
2.2. /etc/opt/
Папка /etc/opt/ должна содержать глобальные файлы конфигурации приложений, установленных в /opt/ . Однако в Linux это требование не является обязательным. В результате бывает, что папка /opt/ полна установленных пользователем программ, а /etc/opt/ остаётся пустой.
Особенности правки файла hosts в Windows 8.
В Windows 8, в отличие от предыдущих версий, изменен порядок редактирования файла hosts. Разработчики уделили этому вопросу гораздо больше внимания. И связано это с более жесткими требованиями к безопасности системы и защите столь важного файла от посягательств из вне.
Эту защиту осуществляет встроенный антивирус Windows Defender — при внесении любых изменений в файл hosts, Windows 8 автоматически удалит их, защитив систему от атак злоумышленников. Но для более опытных и уверенных в себе пользователей существует один способ обхода данной защиты.
- Открываем окно самого защитника. Для этого перейдите на стартовый экран и вызовите боковую панель Charms Bar. Если вы успели принарядить свою систему и установили windows 8 темы такие, что система изменилась до неузнаваемости, то воспользуйтесь сочетанием клавиши WindowsWin+C
- Зайдите в поиск и введите запрос «Defender».
- Кликаем на показанной строке. Откроется окно, в котором нужно перейти на вкладку «Параметры», выбрать «Исключенные файлы и расположения» и нажать кнопку «Обзор».
- Находим путь к файлу C:WindowsSystem32Driversetchosts и нажимаем ОК.
- Теперь, чтобы внести этот файл в исключения защиты, нужно нажать кнопку «Добавить» и «Сохранить изменения».
Теперь можно приступать к редактированию самого файла. Однако, имейте в виду, что изменить файл можно только от имени администратора. Для этого включаем поиск приложений — Win+C -> Иконка Поиска -> вводим запрос «Блокнот«.
Запускаем Блокнот и в появившемся снизу меню выбираем иконку с заголовком «Запуск от имени Администратора».
Откроется привычный блокнот и можно изменять файл hosts как обычно.
2. Глобальные файлы конфигурации
Глобальные файлы конфигурации определяют поведение системы в целом .
Как правило, они располагаются в корневом разделе диска ( / ), а доступ к ним требует прав суперпользователя.
Справедливости ради, стоит заметить, что согласно стандарту FHS конфигурационные файлы не хранятся в корневой директории, она пустая и содержит в себе только папки.
3.3. Важные файлы пользовательской конфигурации
Среди наиболее часто используемых файлов пользовательской конфигурации следует перечислить:
- $HOME/.xinitrc — в нём содержатся указания о запуске менеджера окон при работе с командой startx;
- $HOME/.vimrc — конфигурация vim;
- $HOME/.bashrc — скрипт, который выполняет командная оболочка bash , когда пользователь запускает командную оболочку без регистрации;
- $XDG_CONFIG_HOME/nvim/init.vim — конфигурация редактора neovim;
- $HOME/.editor — задаёт редактор по умолчанию для данного пользователя;
- $HOME/.gitconfig — в файле указывается имя по умолчанию и адрес электронной почты для указания в коммитах Git;
- $HOME/.profile — командная оболочка с регистрацией выполняет команды из скрипта .profile при запуске;
- $HOME/.ssh/config — конфигурация ssh для конкретного пользователя.
Какой файл hosts вы правите?
Если вы проверяете свой hosts и либо не находите его совсем, либо считаете его правильным, проведите дополнительный анализ. Вам потребуется дополнительное умение, чуть больше чем обычное владение блокнотом. Но — ничего сложного.
Уловка 1 — перенаправление в реестре
Если вы не можете войти на сайт, а ваш файл hosts верный или вы не находите hosts в папке С:windowssystem32driversetc, значит вирус подменил расположение файла в ключе реестра.
Чтобы избавиться от вируса, выполните следующие действия:
1. Пуск — Выполнить — regedit.exe.
2. В окне редактора реестра найдите ветку —
HKLMSYSTEMCurrentControlSetServicesTcpipParameters
3. Во вкладке Parameters в правой части окна появится меню с именем файла, его типом и значением. Проверьте значение параметра DataBasePath. Должно быть %SystemRoot%System32driversetc . Если это не так, то кликаем правой кнопкой мыши на этой строке, выбираем Изменить, и вводим правильное значение.
Даже если hosts у вас там, где нужно, но операционная система использует тот файл, путь к которому указан параметром DataBasePath.
Уловка 2 — вставка пустых строк.
Чтобы обнаружить лишние строчки в файле hosts было сложнее, они записываются в самый конец файла после большого количества пустых строк.
С первого взгляда такой файл выглядит нормально и при беглом взгляде мы можем ничего не заметить, однако надо всегда обращать внимание на ползунок полосы прокрутки в Блокноте:
Если ползунок присутствует, то его надо опустить вниз, чтобы посмотреть содержимое файла полностью. Зачастую это оказывается полезным, т.к. внизу файла мы можем найти неприятные сюрпризы:
Уловка 3 — скрытие файла.
Файлу hosts присваивается атрибут Скрытый, и он становится не виден — нету файла hosts. А поскольку по умолчанию скрытые файлы и папки не отображаются в проводнике, то пользователь может не найти этот файл, а значит не может и отредактировать его.
Если у вас нету файла hosts, значит нам надо сделать его видимым. Для этого в Windows XP делаем следующее: Пуск – Панель управления – Свойства папки – вкладка Вид – установить признак Показывать скрытые файлы и папки – нажать Ok (в Windows 7 все то же, но вместо Свойства папки пункт называется Параметры папок).
Уловка 4 — подложный файл с похожим названием.
Создается ложный файл без расширения, но имеющий схожее название, например файл host. А настоящий файл hosts при этом делают скрытым.
В этом случае мы опять редактируем ложный файл, а настоящий остается без изменений. Такой файл (host) можно тоже смело удалять!
Уловка 5 — изменение расширения.
Уловка 6 — невозможно отредактировать файл hosts.
И еще одна вещь, на которую слишком торопливые часто не обращают внимание.
Уловка 7 — настройка прокси.
Не буду сильно заморачиваться на прокси, просто проверьте настройки своего браузера.
Opera: Общие настройки (Ctrl+F12) — Расширенные — Сеть — кнопка Прокси
Firefox: Настройки->Дополнительно->вкладка Сеть — Настроить
По умолчанию там стоит галочка «использовать системные настройки прокси», переключите на “Без прокси”, попробуйте сохранить настройки и перезапустить браузер.
Если стоит ручная настройка и прописан адрес прокси сервера, при этом вы его не устанавливали: сохраните адрес, удалите его, переведите в режим «без прокси».
Открываем наш редактор реестра (используйте сочетание клавиш Win+R), нажимаем CTRL+F (поиск) и вставляем сохраненный адрес, затем — найти далее… Все ключи с данным адресом нужно будет изменить, а именно удалить присвоенное им значение нашего адреса.
Перезагружаем Windows и проверяем.
Что такое файловая система и что такое разные типы?
Файловая система - это способ организации информации на запоминающем устройстве, таком как жесткий диск компьютера. Общие файловые системы включают NTFS, FAT и т. Д.
3.2. Конфигурационные файлы, соответствующие стандарту XDG
По стандарту XDG все файлы пользовательской конфигурации хранятся в папке $XDG_CONFIG_HOME (обычно в /home/(username)/.config ).
Внутри $XDG_CONFIG_HOME каждое приложение создаёт свои подпапки для конфигурационных файлов.
Базовой спецификации каталогов XDG теперь придерживаются редактор NeoVim и многие активно развивающиеся приложения. Для пользователей стандарт тоже удобен: одной резервной копии папки $XDG_CONFIG_HOME достаточно, чтобы сохранить все настройки.
3. Пользовательская конфигурация
Файлы пользовательской конфигурации определяют поведение системы только для задающего настройки пользователя .
Эти файлы, как правило, расположены в домашней папке пользователя и не требуют прав суперпользователя для редактирования.
Следует иметь в виду, что пользовательские настройки всегда имеют более высокий приоритет, чем глобальные. Иными словами, приложение всегда будет придерживаться пользовательских настроек, если таковые есть .
В части пользовательских настроек приложения соответствуют одному из двух стандартов.
История вопроса
Первоначально (в октябре 2002г.) эта публикация была отработана в операционной системе QNX (версия 6.1) и подготовлена в для публикации в журнале «СТА» [1], позже она вошла в книгу [2]. За прошедшие 10 лет ко мне неоднократно обращались с вопросами и за советом. Оказалось, что и операционная система утратила свою актуальность, и многие публикации того времени выглядят не интересными, а вопрос упрощения серверного программирования использованием inetd или xinetd не утратил актуальности. Но, когда возникла возможность заново опубликовать эту статью относительно Linux, оказалось, что в Linux достаточно многие вещи нужно поменять (хоть и по мелочам). Из-за этого предлагается не прежняя версия текста, а новая, переписанная «по мотивам», поэтому и названная «ремейк». Ещё более поменялись примеры иллюстрирующих кодов. Я беру за основу переписывания исходный текст, поэтому он может выглядеть, местами, достаточно несуразно. Но исходной установкой было: осовременить существующий текст.
xinetd — кто он такой?
Поводом для появления этих коротких заметок с сознательно провокационным названием явилось намерение напомнить о том, что иногда для того, чтобы описать в программе нечто, по существу своему являющееся достаточно сложным, могут существовать способы выразить эти же вещи намного проще. И о том, что прежде, чем «барабанить» программный код, разумно потерять некоторое время на размышления о наиболее коротких путях достижения цели. А уж как результат такого подхода: краткость, простота, и, что гораздо ценнее – надёжность, отсутствие ошибок и устойчивость программ в период эксплуатации и сопровождения.
А именно – мы поговорим об некоторых способах создания прикладных TCP/IP серверов, крайне редко, к сожалению, используемых в прикладном программировании, которые почти не требуют написания программного кода. С чего начинает программист, когда перед ним ставится задача написания TCP/IP сервера, особенно если это клиент-серверное TCP/IP приложение для него – хронологически первое в его биографии? C судорожной проработки техники написания IP коммуникаций, сравнения механизмов BSD socket с механизмами TLI SRV4 и т. д. Далее: многие часы бдения над инициализацией socket , установлением соединения … и отладка, отладка, отладка. С учётом того обстоятельства, что отладка сетевых приложений на порядок сложнее локальных, даже при самом смелом использовании таких механизмов как BPF (Berkley Packet Filter) и сетевых сниферов, таких как tcpdump или wireshark . Не случайно, один из самых известных программистских анекдотов объясняет фразу «программировать TCP/IP» как , в более понятной форма, «писать музыку для борделя».
И это при том, что очень часто речь идёт о достаточно тривиальных и типовых случаях, когда сервер должен выполнять нечто, не намного превышающее по сложности ретрансляцию входных запросов (возможно, с минимальными изменениями в них), или отрабатывать однозначные последовательности «запрос-ответ», как в случаях с SQL сервером. Во многом, кроме того, сложившаяся «ручная» практика написания сетевых серверов наследуется разработчиком из практики программирования в Windows - все мы, в силу определённых исторических обстоятельств, выросли из Windows.
Но практически в каждом UNIX, а всё последующее изложение я буду вести относительно только UNIX-подобных систем, существует возможность широкого использования арсенала уже имеющихся под рукой утилит, в частности, начнём мы с суперсервера (super server) inetd . Демон inetd очень широко используется в системных сервисах UNIX, но, как-то так сложилось, что в целевых пользовательских программах его практически не используют. Но в последние годы на смену inetd пришёл xinetd — вот его мы и будем эксплуатировать в наших изысканиях.
Вспоминаем: что делает суперсервер inetd или xinetd ? Во-первых, прослушивает сервисы (как TCP, так и UDP, но нас, для однозначности и простоты, будет интересовать далее, в основном, сервисы TCP), которые прописаны файле /etc/inetd.conf (собственно, прослушивает суперсервер, естественно, не сервисы, а порты, однозначно приписанные этим сервисам в файле /etc/services ). Порты TCP/UDP подразделяются на «хорошо известные» порты (номера 0 - 1023), «динамические» (из диапазона 1024 - 49151), и «эфемерные» (49152 - 65535). Для прикладных пользовательских приложений предлагается выбирать номер порта именно из числа «эфемерных» (использование портов из числа «хорошо известных» вообще потребует от вас прав root , что достаточно рискованно для экспериментов). При появлении трафика на отслеживаемых портах (запрос со стороны клиента) – inetd/xinetd запускает эти сервисы (соответствующую этому сервису программу сервера). Эта логика суперсерверов в достаточной мере общеизвестна.
Во-вторых, при запуске программы сервера inetd/xinetd ассоциирует (дублирует, перенапраяляет) его потоки SYSIN/SYSOUT (и SYSERR , но это представляется нужным крайне редко) в/из открытый им же ( inetd/xinetd ) IP сокет (см. «во-первых»). Это гораздо менее известная его особенность.
Кроме того, inetd/xinetd обслуживает некоторые сетевые службы (сервисы) самостоятельно (internal services), например: chargen, datime и др. Эти возможности не будут нас интересовать, но могут быть также гибко задействованы в прикладных целях.
Наконец, inetd/xinetd поддерживает механизмы RPC, TCPMUX и многое другое - для чего используется несколько изменённая форма конфигурационной записи суперсервера, … но «это совсем другая история», которая нас в текущем изложении интересовать не будет совершенно.
2.1. /etc/
Большинство глобальных файлов конфигурации хранится в папке /etc .
Папка /etc/ больше походит на файловую систему с множеством подпапок, в которых размещены соответствующие конфигурационные файлы.
Ниже приведён список наиболее полезных подпапок:
В порядке итогов.
Глядя на возможности, предоставляемые xinetd , которые далеко не все раскрыты по различным вариантам их использования, иногда задумаешься (я, по крайней мере) — а так ли часто реально существует необходимость писать в каждом случае развёрнутый сервер с детализированным использованием сокетов? Кстати, насколько мне помнится, большинство традиционных UNIX-серверов для таких протоколов как: telnet, ftp, rlogon, rsh … выполнены именно технике использования суперсерверов. Программисты-разработчики часто не любят использовать суперсервер в своих проектах. Но это связано с тем, что программисты обычно чувствуют себя гораздо менее уверенными в сфере администрирования сетевой системы, чем в вопросах написания программного кода. Но это нисколько не есть аргумент против ориентации на суперсервера!
И последнее (это имеет отношение не столько к технике программирования, сколько к технологии создания комплексного программного продукта): описанная техника может быть легко использована, начиная с самых ранних фаз согласования с заказчиком прикладных протоколов системы, на уровне действующих прототипов. На этом этапе обычно нет ясности с деталями целевых протоколов, и именно с подобными инструментами они могут быть в деталях отработаны раньше написания итоговых, сложных и изощрённых сетевых компонент комплекса, не вызывая необходимости их последующей корректировки, или существенной переработки.
[2]. Д.Алексеев, А.Волков, Е.Горошко, М.Горчак, Р.Жавнис, Д.Сошин, О.Цилюрик, А.Чиликин, «Практика работы с QNX», М.: «КомБук», 2004, 432 стр., ISBN 5-94740-009-X.
Etc папка это папка в которой находятся следующие текстовые файлы hosts, lmhosts.sam, networks, protocol, services это стандартное содержание папки etc для Windows XP и Windows 7.
4. Заключение
В этой статье мы рассмотрели два типа конфигурационных файлов, которые используются в Linux, и узнали, где их найти.
Кроме того, заглянули в наиболее распространённые папки для хранения конфигурационных файлов и выяснили, как более старые и новые приложения работают с пользовательскими настройками.
Поскольку ОС Linux не налагает ограничений на эти конфигурационные файлы, их синтаксис может быть самым разным. Но если взять на себя труд и хоть немного в них разобраться, знание конфигурационных файлов освобождает от ограничений пользовательских интерфейсов, предназначенных для новичков.
Читайте также: