По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Итак, у нас загрузилось ядро операционной системы. Далее отрабатывают системы инициализации операционной системы. Три варианта: SysV, systemd, Upstart. Init в стиле SysV Init в стиле SysV данная процедура инициализации, самая старая она более классический Unix вариант инициализации операционной системы. Для того, чтобы понять, как происходит инициализация необходимо понять, что такое режимы загрузки (они же runlevel), разобраться как между ними переключатся, рассмотреть работу со службами. Обычно есть 7 уровней выполнения по умолчанию: Выключение Однопользовательский режим (чаще всего используется для отладки и настройки операционной системы) DebianUbuntu по умолчанию RedHatSuse по умолчанию текстовый режим. WildCard (программируемый режим, можно сюда поставить любой) RedHatSuse GUI (Graphical User Interface) Перезагрузка. Но существуют операционные системы, где 10 уровней по умолчанию. Конечно речь идет о самых распространенных ядрах и сборках *nix образных операционных системах. Для дальнейших пояснений, как работает инициализация в стиле sysV нам необходим операционная система CentOS 5.4 или ниже, потому что в более новых операционных системах данный процесс давно уже заменен. Отроем файл настроек текстовым редактором vi или любым другим удобным для вас. Мы можем увидеть содержание файла. Те самые уровни о которых шла речь выше. Плюс прописан уровень используемые при загрузке по умолчанию. Строчка id:3:initdefault: Мы данный параметр можем отредактировать и например сказать, чтобы операционная система загружалась по умолчанию в Single Mode например. Если мы посмотрим далее файл, мы можем увидеть настройку, которая описывает действия нажатия клавиш Ctrl+alt-delete. А также наглядно прописано, что запуск определенного уровня - это запуск определённого скрипта. Все скрипты запускаются из папки /etc/rc.d/ Все дальнейшие варианты инициализации растут, вот из этого варианта. И этой процедуры инициализации. Перейдем в директорию, где лежат все скрипты инициализации и выполняются данные скрипты при старте системы. В данной папке куча скриптов, которые запускают определенные службы, например, ssh запускает демона ssh для подключения клиентом по 22 порту. Т.е здесь куча служб и запускаются они этими скриптами. Если мы например хотим остановить какую нибудь службу то набираем ./rsync stop , ну и соответственно ./rsync start для запуска данной службы. Аналогично мы можем управлять через команду service, например: service rsync restart . Поднимемся на уровень выше cd .. Найдем все файлы, которые начинаются с rc. Для этого набираем: ls -l | grep rc. В результате мы увидим несколько скриптов. Посмотрим rc3.d . А для этого перейдем в эту директорию. В ней можно увидеть кучу скриптов. В вариации Ubuntu современной и затем в вариации CentOS 5.4 Те скрипты, которые начинаются с буквы K, эти скрипты при старте убивают сервис, те скрипты, которые имеют первой букву S запускают сервис. Ну и соответственно порядковый номер исполнения скрипта в очереди. Для каждого runlevel свой набор скриптов. Основные команды Init управление инициализацией с помощью нее можно перемещаться между runlevel. Telinit управление процессом init , в старых дистрибутива использовалась именно эта команда. Wall вывод сообщения пользователям системы Halt - выключение компьютера Reboot перезагрузка компьютера Shutdown - запланированное выключение Service service_name start|stop|reload|restart Для того, чтобы перемещаться по уровням загрузки, нам необходимо понять на каком уровне мы находимся сейчас. Набираем runlevel . Соответственно, если мы хотим переключится telinit 1 отрабатывают скипты мы попадаем в однопользовательский режим 1. Для того, чтобы послать сообщение все пользователям на данной машине необходимо набрать с соблюдением регистра wall "Abrakadabra". У всех пользователей появится данное сообщение на экране. Для выключения сейчас компьютера можно использовать shutdown h now. Init в стиле Systemd Init в стиле Systemd более современная система инициализации операционной системы Linux. Необходимым элементом работы системы systemd , являются Unit. Unit- это модуль которыми оперирует systemd: .service службы .mount точки монтирования .device устройства .socket сокеты Если при работе в консоли мы не указывает расширение юнита, то в принципе system может догадаться в каком случае, что используется. В операционной системе существуют 2 папки в которых хранятся Unit: /usr/lib/systemd директория с Units по умолчанию, в которой создаются units при установке какого либо программного обеспечения. /etc/systemd директория с управляемыми Units. Тут лежат те Unit которыми может управлять админ, добавлять , редактировать. Посмотрим, что находится в данных директориях переходим в /usr/lib/system Нам интересны 2 директории system и user. Содержимое папки system выглядит вот так. В данной директории лежат все необходимые Units для системы в директории user для пользователя. Картинка будет примерно аналогичная. Директория /etc/systemd. Тут точно также есть две папки system и user, а также конфигурационные фалы. Данные конфигурационные файлы и отвечают за настройку systemd. Это те файлы которые пришли на замену /etc/inittab, предыдущей версии инициализации операционной системы. Файлы юнитов в директориях system и user мы можем редактировать для каких-то своих целей и даже писать targets. Далее мы можем посмотреть запущенные Units. Для этого мы можем выполнить systemctl команду, она отвечает за все действия с systemd. Для примера команда systemctl list-units нам выведет все запущенные Units, сокеты ,устройства ,точки монтирования. Можно посмотреть юниты, которые не стартанули systemd failed. А также мы можем управлять юнитами systemctl status|start|stop|restart crond. Так же Systemd работает с Target (целями). Есть target которые работают так же как runlevel в классической процедуре инициализации, они не пронумерованы в отличии от runlevel у них есть конкретные имена. В табличке можно посмотреть какие target соотносятся с какими runlevel. Их этих target может быть несколько, потому что target бывают не только загрузочные. Данная система использования target обратно совместимая с системой инициализации. Для переключения мы можем использовать команду telinit. Сами по себе target есть некая группировка юнитов, последовательность вызова юнитов. Это может быть target последовательного вызова нескольких служб и ниже стоящий target. Текущий уровень мы можем посмотреть командой runlevel. По умолчанию это будет 3. Далее мы можем написать systemctl list-units --type=target И можно увидеть, что находимся на 3-м уровне также т.к target соответствует. Так же мы можем переключатся между runlevel командой telinit. Например, для перехода в однопользовательский режим telinit 1. А так же мы можем использовать через синтаксис systemctl isolate reboot.target. Для того чтобы поставить какой-то загрузочный target по умолчанию, необходимо отредактировать загрузчик, вставить параметры ядра, которые будут запускаться. Или сделать проще командой systemctl set-default f multi-user.target (использование например 3 runlevel по умолчанию). Одной из особенностей system является интересная система журналирования journald. Демон журналов. Эта система уникальна тем, что собирает информацию из разных источников событий и привязывает их к конкретным юнитам и сервисам. Благодаря этому мы можем всю диагностическую информацию просматривать в одном месте. Соответственно находить неисправности и их устранять. Работает следующим образом: Journalctl f - показывает события по мере их возникновения. Journalctl n 10 вывод последних 10 событий Инициализация Init в стиле Инициализация Init в стиле upstart это система инициализации, в том стиле которая задумывалась для Ubuntu, и заменила процедуру инициализации, которая пришла из Unix стандартную init процедуру. Процедура инициализации upstart контролирует инициализацию демонов и служб в течении загрузки системы и их остановку если у нас система выключается или нужно переключится в другой режим. Основное отличие от классической процедуры инициализации в том, что задачи и службы останавливаются по событиям и сами события могут генерироваться задачами и службами, могут приняты быть от любого процесса системы. Могут быть службы перезапущены в автоматическом режиме если они вдруг были завершены в аварийном режиме. Еще одно отличие в том, что у данного режима инициализации есть задачи (tasks). Основными понятиями являются службы и задачи. Основное отличие службы от задачи в том, что служба перезапускается если была аварийно завершена, а задача нет. Процесс инициализации системы по upstart берет конфигурацию из файлов каталога /etc/init каталог файлов-заданий (jobs). Каждый файл отвечает за запуск каждого задания или службы и должен заканчиваться с расширением .conf . Уровни инициализации остались те же самые. Определение и переключение между уровнями выполняются теми же командами, описанными выше. Изменился файл, в котором мы описываем runlevel запуска по умолчанию. И для управления upstart используется утилита initctl. Как мы видим в каталоге /etc/init находятся конфигурационные файлы Jobs. Каждый отвечает за запуск отдельной службы. Смотрим файл конфигурации простейшего файрвола операционной системы cat ufw.conf Как мы видим ufw стартует при условии, описанном start on, выключается на определенных runlevel. Файл конфигурации с runlevel по умолчанию находится в файле cat /etc/init/rc-sysinit.conf Управляются службы простыми командами status ufw start ufw stop ufw. В данной статье мы рассмотрели различные вариации инициализации. Думаю, информация будет очень полезной.
img
Git – это популярная система контроля версий. Благодаря Git разработчики могут сотрудничать и без проблем работать над проектами совместно. Git позволяет отслеживать изменения, которые вы вносите в проект с течением времени. Помимо этого, он позволяет вернуться к предыдущей версии, если вы вдруг решили не вносить изменение. Git работает по следующему принципу: вы размещаете файлы в проекте с помощью команды git add, а затем фиксируете (коммитите) их с помощью команды git commit. При совместной работе над проектами могут возникнуть ситуации, когда вы не захотите, чтобы какие-то файлы или части проекта были видны всем участникам команды. Иными словами, вы не захотите включать и фиксировать эти файлы в основной версии проекта. Вот почему вы можете не захотеть использовать разделитель (точку) с командой git add, так как в этом случае каждый отдельный файл будет размещен в текущем каталоге Git. Когда вы используете команду git commit, то каждый отдельный файл фиксируется – это также добавляет файлы, которые не нужно. Вы можете, наоборот, захотеть, чтобы Git игнорировал определенные файлы, но для такой цели не существует команды git ignore. Итак, как же сделать так, чтобы Git игнорировал и не отслеживал определенные файлы? С помощью файла .gitignore. В этой статье вы узнаете, что такое файл .gitignore, как его создать и как использовать для игнорирования некоторых файлов и папок. Также вы узнаете, как можно заставить Git игнорировать уже закоммиченый файл. Что такое файл .gitignore? Для чего он нужен? Каждый из файлов в любом текущем рабочем репозитории Git относится к одному из трех типов: Отслеживаемые – это все файлы и каталоги, о которых знает Git. Это файлы и каталоги, которые были недавно размещены (добавлены с помощью git add) и зафиксированы (закоммичены с помощью git commit) в главном репозитории. Неотслеживаемые – это новые файлы и каталоги, которые созданы в рабочем каталоге, но еще не размещены (или добавлены с помощью команды git add). Игнорируемые – это все файлы и каталоги, которые полностью исключаются и игнорируются, и никто о них в репозитории Git не знает. По сути, это способ сообщить Git о том, какие неотслеживаемые файлы так и должны остаться неотслеживаемыми и не должны фиксироваться. Все файлы, которые должны быть проигнорированы, сохраняются в файле .gitignore. Файл .gitignore – это обычный текстовый файл, который содержит список всех указанных файлов и папок проекта, которые Git должен игнорировать и не отслеживать. Внутри файла .gitignore вы можете указать Git игнорировать только один файл или одну папку, указав имя или шаблон этого конкретного файла или папки. Используя такой же подход, вы можете указать Git игнорировать несколько файлов или папок. Как создать файл .gitignore Обычно файл .gitignore помещается в корневой каталог репозитория. Корневой каталог также известен как родительский или текущий рабочий каталог. Корневая папка содержит все файлы и другие папки, из которых состоит проект. Тем не менее, вы можете поместить этот файл в любую папку в репозитории. Если на то пошло, но у вас может быть несколько файлов .gitignore. Для того, чтобы создать файл .gitignore в Unix-подобной системе, такой как macOS или Linux, с помощью командной строки, откройте приложение терминала (например, в macOS это Terminal.app). Затем для того, чтобы создать файл .gitignore для вашего каталога, перейдите в корневую папку, которая содержит проект, и при помощи команды cd введите следующую команду: touch .gitignore Файлы, перед именем которых стоит точка ., по умолчанию скрыты. Скрытые файлы нельзя просмотреть, используя только команду ls. для того, чтобы иметь возможность просмотреть все файлы, включая скрытые, используйте флаг -a с командой ls следующим образом: ls –a Что добавлять в файл .gitignore В файл .gitignore должны быть добавлены файлы любого типа, которые не нужно фиксировать. Вы можете не хотеть их фиксировать из соображений безопасности или потому, что они нужны только вам и не нужны другим разработчикам, работающим над тем же проектом, что и вы. Вот некоторые файлы, которые могут быть включены: Файлы операционной системы. Каждая операционная система, будь то macOS, Windows или Linux, создает системные скрытые файлы, которые не нужны другим разработчикам, так как их система создает такие же файлы. Например, в macOS Finder создает файл .DS_Store, который содержит пользовательские настройки внешнего вида и отображения папок, такие как размер и положение иконок. Файлы конфигурации, создаваемые такими приложениями, как редакторы кода и IDE (Integrated Development Environment – интегрированная среда разработки). Эти файлы настроены под вас, ваши конфигурации и ваши настройки, например папка .idea. Файлы, которые автоматически генерируются языком программирования или средой разработки, которую вы используете для своего проекта, и в процессе компиляции специфичных для кода файлов, такие как файлы .o. Папки, созданные диспетчерами пакетов, например, папка npm node_modules. Это папка, которая используется для сохранения и отслеживания зависимостей для каждого пакета, который вы устанавливаете локально. Файлы, которые содержат конфиденциальные данные и личную информацию. Примерами таких файлов могут послужить файлы с вашими учетными данными (имя пользователя и пароль) и файлы с переменными среды, такие как файлы .env (файлы .env содержат ключи API, которые должны оставаться защищенными и закрытыми). Файлы среды выполнения, такие как файлы .log. Они предоставляют информацию об использовании операционной системы и ошибках, а также историю событий, произошедших в рамках ОС. Как игнорировать файл или папку в Git Если вы хотите игнорировать только один конкретный файл, то вам необходимо указать полный путь к файлу из корневой папки проекта. Например, если вы хотите игнорировать файл text.txt, который расположен в корневом каталоге, то вы должны сделать следующее: /text.txt А если вы хотите игнорировать файл text.txt, который расположен в папке test корневого каталоге, вы должны сделать следующее: /test/text.txt Вы можете это записать иначе: test/text.txt Если вы хотите игнорировать все файлы с определенным именем, то вам нужно написать точное имя файла. Например, если вы хотите игнорировать любые файлы text.txt, то вы должны добавить в .gitignore следующее: text.txt В таком случае вам не нужно указывать полный путь к конкретному файлу. Этот шаблон будет игнорировать все файлы с таким именем, расположенные в любой папке проекта. Для того, чтобы игнорировать весь каталог со всем его содержимым, вам нужно указать имя каталога со слешем в конце: test/ Эта команда позволит игнорировать любой каталог (включая другие файлы и другие подкаталоги внутри каталога) с именем test, расположенный в любой папке вашего проекта. Стоит отметить, что если вы напишете просто имя каталога без слеша, то этот шаблон будет соответствовать как любым файлам, так и любым каталогам с таким именем: # соответствует любым файлам и каталогам с именем test test Что делать, если вы хотите игнорировать любые файлы и каталоги, которые начинаются с определенного слова? Допустим, вы хотите игнорировать все файлы и каталоги, имя которых начинается с img. Для этого вам необходимо указать имя, а затем селектор подстановочного символа *: img* Эта команда позволит игнорировать все файлы и каталоги, имя которых начинается с img. Но что делать, если вы хотите игнорировать любые файлы и каталоги, которые заканчиваются определенным набором символов? Если вы хотите игнорировать все файлы с определенным расширением, то вам необходимо будет использовать селектор подстановочного знака *, за которым последует расширение файла. Например, если вы хотите игнорировать все файлы разметки, которые заканчиваются расширением .md, то вы должны в файл .gitignore добавить следующее: *.md Этот шаблон будет соответствовать любому файлу с расширением .md, расположенному в любой папке проекта. Мы разобрали, как игнорировать все файлы, которые оканчиваются одинаково. Но что делать, если вы хотите сделать исключение для одного из этих файлов? Допустим, вы добавили в свой файл .gitignore следующее: .md Этот шаблон позволит игнорировать все файлы, оканчивающиеся на .md, но вы, например, не хотите, чтобы Git игнорировал файл README.md. Для этого вам нужно будет воспользоваться шаблоном с отрицанием (с восклицательным знаком), чтобы исключить файл, который в противном случае был бы проигнорирован, как и все остальные: # игнорирует все файлы .md .md # не игнорирует файл README.md !README.md Учитывая эти два шаблона в файле .gitignore, все файлы, оканчивающиеся на .md будут игнорироваться, кроме файла README.md. Стоит отметить, что данный шаблон не будет работать, если вы игнорируете весь каталог. Допустим, что вы игнорируете все каталоги test: test/ И допустим, внутри папки test у вас есть файл example.md, который вы не хотите игнорировать. В этом случае вы не сможете сделать исключение для файла внутри игнорируемого каталога следующим образом: # игнорировать все каталоги с именем test test/ # попытка отрицания файла внутри игнорируемого каталога не сработает !test/example.md Как игнорировать ранее закоммиченый файл Лучше всего создать файл .gitignore со всеми файлами и различными шаблонами файлов, которые вы хотите игнорировать, при создании нового репозитория, до его коммита. Git может игнорировать только неотслеживаемые файлы, которые еще не были зафиксированы в репозитории. Что же делать, если вы уже закоммитили файл, но хотели бы, чтобы он все-таки не был закоммичен? Допустим, что вы случайно закоммитили файл .env, в котором хранятся переменные среды. Для начала вам необходимо обновить файл .gitignore, чтобы включить файл .env: # добавить файл .env в .gitignore echo ".env" >> .gitignore Теперь, вам нужно указать Git не отслеживать этот файл, удалив его из перечня: git rm --cached .env Команда git rm вместе с параметром --cached удаляет файл из репозитория, но не фактический файл. Это значит, что файл остается в вашей локальной системе и в вашем рабочем каталоге в качестве файла, который игнорируется. Команда git status покажет, что файла в репозитории больше нет, в ввод команды ls покажет, что файл существует в вашей локальной файловой системе. Если вы хотите удалить файл из репозитория и вашей локальной системы, то не используйте параметр --cached. Затем добавьте .gitignore в область подготовленных файлов с помощью команды git add: git add .gitignore И наконец, закоммитте файл .gitignore с помощью команды git commit: git commit -m "update ignored files" Заключение Вот и все – теперь вы знаете, как игнорировать файлы и папки в Git.
img
Session Border Controller (контроллер граничных сессий) - сетевое устройство, которое может обеспечить безопасность VoIP, а так же соединять несовместимые (разнородные) сигнальные протоколы и медиа потоки, поступающие от различных устройств. SBC – устройства используются в корпоративных сетях и сетях провайдеров услуг и, как правило, развертываются на границе сети (точка входа провайдера в корпоративный контур). В основном, несмотря на способность устройств поддерживать H.323, SCCP и прочие, фокус работы SBC сделан на обеспечении безопасности SIP – протокола, а так же сопряжении различных версий SIP. Основная идея SBC защищает от атак сеть телефонии и соответствующие сервера, выполняя роль B2BUA (back-to-back user agent), схожую по типу работы с SIP прокси – сервером. Контроллер терминирует каждую сессию (завершает), а затем заново ее инициирует, выступая в роли агентского сервера UAS (User Agent Server) и агентским клиентом UAC (User Agent Client), работая с каждым из «плеч» вызова по отдельности. На базе собственных мощностей SBC реализует списки контроля доступа ACL, ограничение DDOS атак, а так же анализ пакетов на предмет искажения информации с целью нанести ущерб. Анализируя SIP, SBC анализирует заголовки и поле полезной нагрузки. Особенно это актуально в SDP – сообщениях, к которым может применяться множество правил модификации. Помимо сигнальной информации, SBC обрабатывает RTP потоки, тем самым, обеспечивает не только шифрование медиа, но и выполняет функции транскодинга (преобразования потока из одного кодека в другой) в случаях, когда две стороны SIP – коммуникации не могут согласовать параметры передачи данных в сообщениях SDP. Кстати, на SBC обычно реализуют так называемый SIP forking, который позволяет дублировать сессию на третье устройство, например, такое как система записи телефонных разговоров. В современных версиях SBC, сигнальная информация и потоки изолированы друг от друга (с точки зрения обработки устройством) – это обеспечивает высокие параметры масштабирования. Давайте рассмотрим на примеры схемы ниже принцип работы SBC:
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59