По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
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
В сегодняшней статье поговорим об одном очень полезном инструменте Asterisk, который называется Call Flow. Данный инструмент позволяет управлять отправкой вызовов на основании положения переключателя. Переключатель может находиться в режиме Normal и Override. По сути, данный функционал является чем-то наподобие тумблера. Когда он в положении “включено”, входящие звонки будут отправляться по одному назначению, когда “выключено”, по другому. Например, в рабочие часы, необходимо настроить отправку входящих звонков на специальную ринг-группу, а в нерабочие – на IVR. С такой задачей поможет справиться модуль Time Conditions. Но если компания не имеет чётко определенного рабочего времени, то данный модуль уже не поможет, поскольку он переключает режим обработки вызовов автоматически в определенно заданное время. /p> С помощью Call Flow переключить “тумблер” можно в любое время и нужный режим обработки вызовов сохранится до тех пор, пока не будет изменен вручную. Для переключения режимов в Call Flow предусмотрены специальные коды (feature code). Существует 100 кодов (0-99), каждый из которых может включать определенный режим обработки вызовов. Чтобы использовать Call Flow нужно ввести специальный индекс ( 0-99) и дополнить его специальным кодом -28. Например, если индекс– 1, то feature code, включающий Call Flow будет *281. Call Flow Control Рассмотрим модуль Call Flow Control на примере FreePBX 13. Для того, чтобы открыть панель управления модулем, переходим по следующему пути Applications -> Call Flow. По умолчанию, никаких записей нет. Жмём кнопку Add и перед нами открывается панель добавления нового переключателя. Рассмотрим основные параметры, которые нужно настроить: Call Flow Toggle Feature Code Index – Индекс переключателя. Как было сказано ранее, каждый feature code модуля Call Flow начинается с *28. Индекс это последняя часть кода, который может иметь значения от 0 до 99. Если вы выбрали 1 в качестве индекса, то код будет *281, если 78, то *2878 и так далее. Description – Описание помогает быстро идентифицировать нужный переключатель среди остальных в списке. Current Mode – Текущий режим. Выбор начального состояния переключателя Normal (Green/BLF off) или Override (Red/BLF on). Позднее эти кнопки (в дополнение к feature code’у) можно использовать для изменения режима. Normal (Green/BLF off) - Эта настройка говорит о том, что звонки отправляются по стандартному назначению. Если на телефоне есть BLF, запрограммированный под данный feature code, то в данном состоянии лампочка будет гореть зеленым или не гореть вообще. Override (Red/BLF on) – Эта настройка, говорит о том, что звонки отправляются по другому (нестандартному) назначению. Если на телефоне есть BLF запрограммированный под данный feature code, то в данном состоянии лампочка будет гореть красным. Recording for Normal Mode – Позволяет настроить запись, которая будет проигрываться при переключении в нормальный режим. По умолчанию, сначала будет гудок (beep), а затем объявление о том, что feature code деактивирован. Вы можете записать собственное объявление при помощи модуля System Recordings Optional Password – Опционально можно настроить специальный пароль для использования данного feature code’а. Пользователь, желающий воспользоваться кодом, должен будет сначала ввести пароль на своём телефоне. Normal Flow Destination – Назначение, куда должны отправляться входящие звонки, когда переключатель находится в режиме Normal (Green/BLF off). Это может быть любое назначение на PBX, как то внутренний номер, IVR, ринг группа и т.д. Override Flow – Это назначение, куда должны отправляться вызову, когда переключатель находится в режиме Override (Red/BLF on). Это может быть любое назначение на PBX, как то внутренний номер, IVR, ринг группа и т.д. На примере ниже мы создали переключатель, который в нормальном режиме отправляет все звонки на IVR, а когда включен – на Announcement, который уведомит абонентов о том, что компания не работает. Для использования данного feature code’а, необходимо ввести на телефоне *2852
img
Партнер данного материала Telegram-канал Админим с Буквой Тема статьи небольшая, но информация данная необходима для понимания ограничений на дисках в операционной системе Linux. В данной статье рассмотрим: Установка квоты Редактирование квоты Просмотр отчетов по квотам Квоты – это ограничения, налагаемые системным администратором на использование дискового пространства в операционных системах. Они позволяют гибко управлять ограниченным ресурсом для сервера свободным местом на жестком диске. Квоты можно устанавливать, как на отдельных пользователей, так и на группы пользователей. Для конфигурации и управления квотами используются следующие команды: quotaon – включение квоты quotaoff – выключение квоты edquota – редактирование квоты repquota - отчет по квотам У Windows Server, конечно намного богаче инструментарий по работе с квотами. Для этого выделена целый File Server Resource Manager, но в данной статье мы посмотрим, как это работает в Linux системах на примере Ubuntu Server. У меня есть смонтированый раздел /dev/sdc1 в папку /mnt/hard. Для того, чтобы работать с квотами, необходимо поставить пакет apt-get install quota. Для того, чтобы использовать квоты, нам необходимо добавить монтирование данного раздела в файл /etc/fstab. Добавляем следующую строчку: /dev/sdc1 /mnt/hard auto rw,user,auto,usrquota,grpquota 0 0 Где, раздел, куда монтируем, автоопределение файловой системы, раздел для записи, разрешаем монтирование пользователям, раздел будет монтироваться автоматически при старте системы и включаем пользовательскую квоту и групповую. Строка будет выглядеть как на картинке. Сохраняем и перезагружаем. Для начала выключаем все квоты, если они когда-нибудь ставились, для чистоты настройки quotaoff /mnt/hard. Следующая команда quotacheck – которая создаст квоту для пользователей и групп, у нее большой функционал, но мы ее используем именно в таком ключе. Квоту мы можем создать только полностью на примонтированный раздел – это связанно с файловой системой ext4. Существуют и другие файловые системы, в которых мы можем ставить квоты на папки и работать более гибко, например xfs. quotacheck –cug /mnt/hard. В данном случае мы квоту ставим полностью на раздел, который смонтирован в /mnt/hard. И как видим команда создала 2 файла aquota.group и aquota.user. Это файлы с настройками квот. Это двоичные файлы и при попытке их посмотреть, например, cat aquota.user мы увидим, нечто не читаемое. Для редактирования данных фалов настройки текстовый редактор не подойдет, и мы будем использовать отдельную команду edquota – u siadmin. Т.е команда -u указывает , что мы редактируем для пользователя и далее указывается непосредственно пользователь. Вот так выглядит редактирование. Мы видим, что здесь есть blocks – число 1К блоки, soft – мягкая квота, это квота, которую пользователь может превысить, но не более чем на неделю, hard – жесткая квота, это квота которую пользователь не сможет превысить вообще. Получается так, если пользователь siadmin поставит soft 10 и hard 30, и запишу файлик в 15КБ, то неделю моя квота терпит, а через неделю система скажет, что квота превышена и будет требовать очистки. Если создать сразу файл 40 КБ, то квота скажет, что нету места на жестком диске. Так же можно поставить квоту на inodes, т.е на уникальные идентификаторы файлов, каждому файлу присваивается уникальный идентификатор, следовательно, пользователь не может превысить их количество по квоте. Когда мы выполняем команду edquota, то для открытия открывается редактор, установленный по умолчанию. В данном случае редактор nano. Как было уже написано мягкая квота устанавливается на неделю и после чего начинает блокировать, если мы не уменьшили размер файлов или не уменьшили их количество, смотря какая квота была выставлена. Мы можем данный параметр изменить, выполнив sudo edquota –t. Думаю, открытый файл на редактирование, тут все интуитивно понятно. Меняем и сохраняем. Мы в файле /etc/fstab указали, что файловая система монтируется с применением квот, потом командой quotacheck создали квоты, а затем указали ограничения edquota. Но до сих пор квоты не включены, квоты не работают! Для того, чтобы квоты заработали используется команда sudo quotaon /mnt/hard. И как только мы эту команду дали, файлы созданные aquota.group и aquota.user будут отредактированы и квоты заработают. Чтобы посмотреть, как работают квоты, создадим файл текстовый. Но т.к монтировался раздел из под root, то необходимо сменить владельца папки /mnt/hard/. Это можно сделать командой chown siadmin:root /mnt/hard. И теперь спокойно можно создать файл touch test.txt. Теперь добавим в файл информацию несколько слов. edquota – u siadmin выполняем и видим, что число блоков изменилось. Добавим еще информации, еще раз поменяется количество блоков. Создадим еще один файл – изменится число inodes. Далее простым копирование увеличиваем количество файлов, пока не сработает квота. Соответственно мы одновременно можем использовать квоты и по размеру, и по inodes. Очень важный момент. Поднимаемся в корневую папку /. Команда sudo repqouta /mnt/hard покажет отчет по квотам. Есть еще интересная команда - man warnquota. Команда отправляет e-mail при превышении квоты. Но для этого необходимо настроить почтовый smtp сервер, который будет отправлять почту.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59