пїЅпїЅпїЅпїЅпїЅпїЅ - пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ24
Слишком длинный поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Linux Jargon Buster: что такое менеджер пакетов в Linux? Как это работает?
То, что позволяет отличать дистрибутивы Linux друг от друга, – это механизм управления пакетами. В этой части серии статей Linux Jargon Buster вы узнаете об организации пакетов и менеджерах пакетов в Linux. Вы узнаете, что такое пакеты, что такое менеджеры пакетов, как они работают и какие виды менеджеров пакетов существуют.
Что такое менеджер пакетов в Linux?
Простыми словами, менеджер пакетов – это инструмент, который дает пользователям возможность устанавливать, удалять, обновлять, настраивать и управлять программными пакетами в операционной системе. Менеджер пакетов может представлять собой приложение с графическим интерфейсом, такое как Software Center, или инструмент командной строки, такой как apt-get или pacman.
Вы часто будете встречать термин «пакет» в руководствах или статьях на It’s FOSS. И чтобы понять, что такое менеджер пакетов, вам нужно иметь представление о том, что такое пакет.
Что такое пакет?
Пакет, как правило, имеет отношение к приложению, но это может быть приложение с графическим интерфейсом, инструмент командной строки или библиотека программных модулей (которая нужна для других программ). Пакет – это, можно сказать, архивный файл, который содержит двоичный исполняемый файл, файл конфигурации и иногда информацию о зависимостях.
Раньше программное обеспечение устанавливалось из исходного кода. Вы бы обратились к файлу (обычно он назывался readme) и посмотрели, какие программные компоненты требуются и где расположены двоичные файлы. Конфигурационный скрипт или make-файл обычно находятся там же. Вам придется компилировать программное обеспечение или собирать его вручную, а также обрабатывать все зависимости (некоторое программное обеспечение требует, чтобы было установлено другое программное обеспечение) самостоятельно.
Для того, чтобы решить эту проблему, дистрибутивы Linux создали свой собственный формат организации пакетов, чтобы конечные пользователи получали уже готовые к использованию двоичные файлы (то есть предварительно скомпилированное программное обеспечение) с некоторыми метаданными (номер версии, описание) и зависимостями, и с помощью этих файлов уже могли установить программное обеспечение.
Это как выбор между «испечь торт» или «купить торт».
Примерно в середине 90-х годов Debian создал формат организации пакетов .deb или DEB, а Red Hat Linux создал систему организации пакетов .rpm или RPM (сокращение от Red Hat Package Manager). Компиляция исходной кода все еще имеет место быть, но теперь это необязательно.
Для того, чтобы взаимодействовать с системами организации пакетов, вам нужен менеджер пакетов.
Как работает менеджер пакетов?
Учитывайте, что менеджер пакетов – это общая концепция, и она не является уникальной для Linux. Вы можете найти менеджер пакетов для самых разных программных обеспечений или языков программирования. Есть менеджер пакетов PIP, который был создан исключительно для пакетов Python. Даже редактор Atom имеет свой собственный менеджер пакетов.
Так как основной фокус внимания в этой статье направлен на Linux? то и рассматривать все я буду с точки зрения Linux. Однако большую часть всего, что здесь будет, можно применить и к менеджерам пакетов в целом.
Я нарисовал эту схему, чтобы вам было проще понять, как работает менеджер пакетов.
Практически все дистрибутивы Linux имеют программные репозитории, которые, как правило, представляют собой набор программных пакетов. Да, может быть больше одного репозитория, и они содержат различные программные пакеты.
В репозиториях также есть файлы метаданных, которые содержат информацию о пакетах, такую как имя пакета, номер версии, описание пакета, имя репозитория и т.д. Это то, что вы можете увидеть, если введете команду apt show в Ubuntu/Debian.
Сначала менеджер пакетов взаимодействует в метаданными. Он создает локальный кэш метаданных в вашей системе. Когда вы запускаете команду обновления менеджера пакетов (например, apt update), он обновляет этот локальный кэш, обращаясь к метаданным из репозитория.
Когда вы запускаете команду установки менеджера пакетов (например, apt install package_name), он обращается к этому кэшу. Если он находит там информацию о пакете, то он подключается к соответствующему репозиторию через Интернет и перед тем, как установить пакет в вашей системе, загружает его.
У пакета могут быть зависимости. Это значит, что, возможно нужно будет установить еще какие-то пакеты. Менеджер пакетов внимательно следит за этим и устанавливает зависимости автоматически вместе с основным пакетом.
Менеджер пакетов в Linux, обрабатывающий зависимости
Аналогично с удалением пакетов, менеджер пакетов либо информирует вас о том, что в вашей системе есть неиспользуемые пакеты, которые можно удалить, либо удаляет их автоматически.
Кроме очевидных задач, которые связаны с установкой и удалением, менеджер пакетов можно использовать для настройки и управления пакетами в соответствии с вашими потребностями. Например, вы можете запретить обновление версии пакета из обычных системных обновлений. И это не все, на что способен ваш менеджер пакетов.
Разные виды менеджеров пакетов
Менеджеры пакетов отличаются системами организации пакетов, но при этом одна и та же система может иметь более одного менеджера пакетов.
Например, в RPM есть менеджеры пакетов Yum и DNF. А для DEB - менеджеры пакетов на основе командной строки apt-get и aptitude.
Менеджер пакетов Synaptic
Менеджеры пакетов не всегда бывают основаны на командной строке. Есть и инструменты управления пакетами с графическим интерфейсом, такие как Synaptic. Также менеджером пакетов является программный центр вашего дистрибутива, даже если за всем этим работает apt-get или DNF.
Заключение
Я не буду раскрывать все подробности этой темы, потому здесь можно продолжать бесконечно. Но в таком случае мы отклонимся от цели статьи – дать базовое представление о менеджере пакетов в Linux.
И я пока не касался такие новых универсальных форматов организации упаковки, как Snap и Flatpak.
Когда базы данных Oracle не работают, целесообразно проверить подключения к ним.
Периодически приходится проверять, работает ли база данных Oracle. Иногда процесс, запущенный на одном сервере, извлекает данные из базы данных на другом сервере, и, если процесс завершается неудачей, тестирование соединения с базой данных является хорошей отправной точкой для определения того, что пошло не так.
Проверка локальной базы данных
Если база данных находится в локальной системе, сперва проверяем состояние процесса и должны увидеть результат, подобный показанному на скриншоте ниже.
Эти выходные данные говорят нам, что процессы Oracle запущены, включая tnslsnr, часто называемый «прослушивателем» и критически важный для подключения к локальной базе данных. Также можно проверить вывод команды netstat, чтобы увидеть, порт, который «опрашивает» Oracle и использует по умолчанию. Это порт, который должен был открыть «прослушиватель».
Использование tnsping
Другая, потенциально более полезная команда - это tnsping, которая использует информацию из файла БД Oracle tnsnames.ora для проверки возможности подключения. Если, например, набрать команду tnsping ORCL, команда будет искать базу данных с именем службы ORCL, отправит запрос типа ping на настроенный порт и сообщит об ответе. Успешный ответ от tnsping будет выглядеть примерно так:
Обратите внимание на ответ «ОК» в последней строке. Также получен отчет о том, сколько времени потребовалось на ответ. Одиннадцать секунд - быстрый ответ. Если проверялась удаленная система, то потребовалось бы в десять или более раз больше времени, чтобы получить ответ.
Если Oracle прослушивает порт, отличный от 1521, команда tnsping все равно будет работать, предполагая, что файл tnsnames.ora содержит правильную информацию. Запись tnsnames.ora для одной базы данных будет выглядеть примерно так:
Обратите внимание, как имя службы (ORCL), которое использовалось в примере команды tnsping, и порт, на который отвечает «прослушиватель» Oracle (1521), настроены в этом дескрипторе базы данных.
Использование sqlplus
Другая команда, которую любят использовать администраторы БД для проверки связи с базой данных Oracle - это sqlplus. С помощью sqlplus (установленного вместе с Oracle) можно проверить, отвечает ли Oracle, а также и запустить несколько команд sqlplus, чтобы убедиться, что таблицы или их содержимое соответствуют тому, что мы ожидаем увидеть. Команда sqlplus имеет следующую форму для подключения к базе данных Oracle:
sqlplus username/password@SID
SID в этом описании может быть SID или SERVICE_NAME, взаимозаменяемыми в некоторых версиях Oracle. Например, можно ввести:
% sqlplus admin/f0xtrawt@ORCL
Эта команда определяет имя пользователя, пароль и SERVICE_NAME/SID в одной команде. После подключения можно ввести пару команд sql, чтобы убедиться, что база данных работает правильно. Можно подсчитать количество пользовательских таблиц с помощью такой команды:
SQL> select count(*) from user_tables;
COUNT(*)
----------
45
Создание скрипта
Поскольку я не так часто пытаюсь устранить неполадки в базах данных Oracle, я предпочитаю сохранять команды для подключения к конкретной базе данных в виде простого скрипта. Я мог бы назвать скрипт для подключения к локальной базе данных connect2local и аналогичный сценарий для подключения к базе данных на удаленном сервере connect2rem или connect2mars (если удаленная система была названа mars).
Чтобы облегчить мне использование БД Oracle, я сохраню переменные, которые хочу использовать, в профиле и буду использовать их по мере необходимости:
Мною написанный скрипт будет выглядеть так:
Когда я набираю connect2local, я ожидаю увидеть в ответ OK и возможность остаться в приглашении SQL>, из которого я могу выдавать запросы или набрать quit для выхода. Быстрые тесты, позволяющие определить, реагирует ли база данных Oracle, имеют большое значение для устранения проблем с подключением.
Устройства третьего уровня модели OSI обеспечивают так называемую трансляцию сетевых адресов, или Network Address Translation (NAT). Устройства третьего уровня, как правило, маршрутизаторы, фаерволы или коммутаторы с функциями L3, преобразуют внутренние IP-адреса во внешние, которые маршрутизируются в сети интернет. В рамках преобразования IP-адреса, фаервол сохраняет внутренний адрес себе в память, затем подменяет его на адрес внешнего интерфейса, либо меняет его на один из адресов внешнего диапазона (пула), и совершает отправку измененного IP-пакета.
Трансляция портов
В современных корпоративных сетях, фаерволы выполняют функцию, которая называется Port Address Translation (PAT). Эта технология позволяет множеству внутренних IP – адресов использовать один и тот же внешний адрес. Данная технология реализуется на четвертом уровне модели OSI. Схема работы PAT показана ниже:
На схеме, компьютеры (рабочие станции) находятся в защищенном участке сети за «фаерволом». Этот участок обозначен как внутренняя сеть, где действует адресация 192.168.0.0 с маской подсети 255.255.255.0. Как было сказано в начале главы, Cisco Adaptive Security Appliances (ASA) выполняет функции по трансляции портов для устройств внутренней сети. Трансляция выполняется для «хостов» подсети 192.168.0.X в во внешний IP-адрес Cisco ASA – 208.104.33.225. В данном примере, компьютер А отправляет TCP пакет с портом назначения 80, получателем которого является WEB – сервер, расположенный во внешнем сегменте сети на компьютере Б. ASA подменяет оригинальный запрос с IP-адреса 192.168.0.44 на свой собственный (208.104.33.225). Параллельно, случайно выбирается номер порта, отличного от исходного (в данном примере порт 1024 заменен на 1188). Только после этого, пакеты отправляются на WEB – сервер к адресу назначения 208.104.33.241.
Система обнаружения и предотвращения вторжений
Система обнаружения вторжений Intrusion Detection System (IDS), это устройства, которые предназначены для обнаружения атак на корпоративную сеть и поддержания ИТ безопасности в целом. Системы обнаружения позволяют отслеживать распределенные DDoS атаки, «черви» и «трояны».
Как показано выше, злоумышленник отправляет «зараженный» пакет на WEB – сервера компании с целью, например, вывести из строя сайт компании. Система обнаружения вторжения (IDS) отслеживает данный пакет, и отправляет сигнал тревоги на систему мониторинга. Недостатком данного механизма является то, что он лишь уведомляет о наличии угрозы, но не предотвращает ее. В данном случае, отправленный злоумышленником пакет дойдет до получателя.
Система предотвращения вторжений, или Intrusion Prevention System (IPS) , способна не только обнаружить «зараженный» пакет, но и уничтожить его. Схема работы IPS показана на рисунке ниже:
Как видно из рисунка, система IPS предотвращает попадание «зараженного» пакета в сегмент корпоративной сети. IPS/IDS системы определяют «зараженный» трафик по следующим критериям:
Проверка на базе подписи;
Общая политика безопасности;
Проверка на базе нелинейности поведения;
Проверка на основании репутации.
О критериях определения "плохого" трафика мы расскажем в следующих статьях.