По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Всем привет! В сегодняшней статье, научим нашу IP-АТС на FreePBX 14 и Asterisk 13 запускаться автоматически, без необходимости подключения к ней и запуска вручную. Итак, вот вы скачали и установили последний доступный дистрибутив FreePBX 14 произвели какие-либо первичные настройки и сделали ребут. После того, как сервер перезагрузился, заходим на web-интерфейс и видим большую, страшную надпись Can Not Connect to Asterisk на красном фоне. Вероятно, сервис не запущен. Открываем консоль и даём команду service asterisk start и надпись исчезает. Всё, IP-АТС готова к работе. Но что же это получается - нам после каждого ребута нужно будет вручную запускать сервис Asterisk? Не очень радужная перспектива, согласитесь. Сейчас мы расскажем как это исправить. Итак, FreePBX, как и очень много других решений, использует в качестве инициализатора других демонов (процесс, который запускается автоматически и работает в фоновом режиме), системный менеджер systemd. Поэтому именно его конфигурацию относительно сервиса FreePBX, мы немножечко поправим. Для этого, создаём файл командой touch /etc/systemd/system/freepbx.service, а затем открываем его любым текстовым редактором и вносим туда следующие записи: Внимание!Приведённый ниже пример применялся в операционной системе CentOS 7, если вы используете Debian 8.1, в поле After= напишите mysql.service вместо mariadb.service [Unit] Description=FreePBX VoIP Server After=mariadb.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/sbin/fwconsole start -q ExecStop=/usr/sbin/fwconsole stop -q [Install] WantedBy=multi-user.target А теперь просто скомандуем, чтобы этот скрипт запускался автоматически. Для этого пишем systemctl enable freepbx.service Всё, теперь наша IP-АТС будет сразу готова к работе после любой перезагрузки!
img
Самые фундаментальные навыки, которые нужно освоить инженеру, работающему с Linux - это перемещение по файловой системе и понимание того, что вас окружает. В этом разделе мы обсудим инструменты, которые позволят вам это сделать. Разберем базовые команды с примерами. pwd Когда вы входите на свой сервер, вы обычно попадаете в домашний каталог своей учетной записи. Домашний каталог - это каталог, предназначенный для хранения файлов и создания каталогов вашим пользователем. Чтобы узнать, где находится ваш домашний каталог по отношению к остальной файловой системе, вы можете использовать команду pwd. Эта команда отображает каталог, в котором мы сейчас находимся: pwd Вы должны получить обратно информацию, которая выглядит следующим образом: /home/demo Домашний каталог назван в честь учетной записи пользователя, поэтому в приведенном выше примере значение будет, если бы вы вошли на сервер с учетной записью под названием demo. Этот каталог находится в каталоге с именем /home, который сам находится в каталоге верхнего уровня, который называется root, но представлен одинарной косой чертой /. ls Теперь, когда вы знаете, как отображать каталог, в котором вы находитесь, мы можем просматривать содержимое каталога. Пока в нашем каталоге ничего нет, поэтому мы перейдем в другой, более насыщенный каталог для изучения. Введите в терминале следующее, чтобы перейти в каталог /usr/share. cd /usr/share После этого используем pwd, чтобы проверить, что мы успешно переехали: /usr/share Теперь, когда мы находимся в новом каталоге, давайте посмотрим, что внутри. Для этого мы введем команду ls: adduser groff pam-configs applications grub perl apport grub-gfxpayload-lists perl5 apps hal pixmaps apt i18n pkgconfig aptitude icons polkit-1 apt-xapian-index info popularity-contest . . . Как видите, в этом каталоге много элементов. Мы можем добавить в команду несколько необязательных флагов, чтобы изменить поведение. Например, чтобы перечислить все содержимое в расширенной форме, мы можем использовать флаг -l (для «длинного» вывода): total 440 drwxr-xr-x 2 root root 4096 Apr 17 2021 adduser drwxr-xr-x 2 root root 4096 Sep 24 19:11 applications drwxr-xr-x 6 root root 4096 Oct 9 18:16 apport drwxr-xr-x 3 root root 4096 Apr 17 2021 apps drwxr-xr-x 2 root root 4096 Oct 9 18:15 apt drwxr-xr-x 2 root root 4096 Apr 17 2021 aptitude drwxr-xr-x 4 root root 4096 Apr 17 2021 apt-xapian-index drwxr-xr-x 2 root root 4096 Apr 17 2021 awk . . . Этот вид дает нам много информации, большая часть которой выглядит довольно необычно. Первый блок описывает тип файла (если в первом столбце стоит d, это каталог, если -, это обычный файл) и разрешения. Каждый последующий столбец, разделенный пробелом, описывает количество жестких ссылок, владельца, владельца группы, размер элемента, время последнего изменения и имя элемента. Вы можете просмотреть эту информацию с помощью флага -l команды ls. Чтобы получить список всех файлов, включая скрытые файлы и каталоги, вы можете добавить флаг -a. Поскольку в каталоге /usr/share нет настоящих скрытых файлов, давайте вернемся в наш домашний каталог и попробуем эту команду. Вернуться в домашний каталог можно набрав cd без аргументов. После этого выполним команду ls -a: . .. .bash_logout .bashrc .profile Как видите, в этом выводе есть три скрытых файла вместе с . и .., которые являются специальными индикаторами. Часто файлы конфигурации хранятся как скрытые файлы, как здесь. Для записей с точками и двойными точками это не совсем каталоги, а встроенные методы обращения к связанным каталогам. Одиночная точка указывает текущий каталог, а двойная точка указывает родительский каталог этого каталога. По умолчанию ls выводит список содержимого текущего каталога. Однако мы можем передать имя любого каталога, содержимое которого мы хотели бы видеть, в конце команды. Например, мы можем просмотреть содержимое каталога с именем /etc, доступного во всех системах Linux, набрав: ls /etc Получим вывод: acpi fstab magic rc.local adduser.conf fstab.d magic.mime rc.local.orig aliases fuse.conf mailcap rcS.d aliases.db gai.conf mailcap.order reportbug.conf alternatives groff mailname resolvconf anacrontab group mail.rc resolv.conf apm group- manpath.config rmt . . . cd Мы уже сделали два перемещения каталога, чтобы продемонстрировать некоторые свойства ls. Давайте подробнее рассмотрим команду здесь. Начните с возврата в каталог /usr/share, набрав следующее: cd /usr/share Это пример изменения каталога путем указания абсолютного пути. В Linux каждый файл и каталог находится в самом верхнем каталоге, который называется «корневым» (root), но обозначается одинарной косой чертой в начале пути /. Абсолютный путь указывает расположение каталога по отношению к этому каталогу верхнего уровня. Это позволяет нам однозначно обращаться к каталогам из любого места файловой системы. Каждый абсолютный путь должен начинаться с косой черты. Альтернативой является использование относительных путей. Относительные пути относятся к каталогам относительно текущего каталога. Для каталогов, близких к текущему каталогу в иерархии, это обычно проще и короче. На любой каталог в текущем каталоге можно ссылаться по имени без косой черты в начале. Мы можем перейти в каталог locale в /usr/share из нашего текущего местоположения, набрав: cd locale Мы также можем переместиться на несколько уровней каталогов с относительными путями, указав часть пути, которая идет после пути к текущему каталогу. Отсюда мы можем перейти в каталог LC_MESSAGES в каталоге en, набрав: cd en/LC_MESSAGES Для возврата к родительскому элементу текущего каталога мы используем специальный индикатор с двумя точками, о котором мы говорили ранее. Например, теперь мы находимся в каталоге /usr/share/locale/en/LC_MESSAGES. Чтобы подняться на один уровень вверх, мы можем ввести: cd .. Это приведет нас в каталог /usr/share/locale/en. Мы можем вернуться в наш предыдущий каталог, набрав: cd - Шорткат, который вы видели ранее, который всегда будет возвращать вас в ваш домашний каталог - это использовать cd без указания каталога: cd
img
У облачного провайдера нам необходимо арендовать пул виртуальных серверов для создания на его основе облачного аналога перечисленной серверной части сети. К организованной облачной виртуальной инфраструктуре будут иметь доступ все отделения организации посредством VPN-туннелей. Все виртуальные машины создаются посредством гипервизора. Аналогичным образом виртуальные машины могут быть созданы и в обычной сети, но также могут использоваться и отдельные физические серверы. Для облачных же услуг технология виртуализации является основополагающей, поэтому в этом разделе подробнее будет рассмотрена технология виртуализации. В данном случае для организации собственных виртуальных серверов мы пользуемся услугами IaaS (чаще всего в списке услуг именуется как "аренда виртуальных серверов" или похожим образом). Но для организации серверов для, например, корпоративной почты или базы данных можно воспользоваться уже готовыми PaaS и SaaS-решениями, которые предлагаются некоторыми облачными провайдерами. При организации облачной инфраструктуры для крупной организации имеет смысл строить частное облако. Даже пусть оно иногда не будет покрывать все потребности организации и периодически придется превращать его в гибридное. Крупным компаниям нужна не столько экономия, столько полный контроль над обрабатываемыми данными - чтобы конфиденциальные данные не вышли за пределы компаний. Для небольших и средних организаций можно создать облачную инфраструктуру на базе публичного облака. Если компания только начинает свою деятельность, нет смысла покупать физические серверы - можно сразу арендовать виртуальные и сэкономить средства, которые можно потратить с большей пользой. Перевод в облако сразу всей инфраструктуры обусловлен еще и взаимосвязями между серверами и скоростью обмена данными между ними. Поэтому следует учитывать взаимосвязь серверов между собой и тот факт, что из любого офиса теперь скорость скачивания файла из того же облачного хранилища будет ограничиваться максимальной скоростью на сетях интернет-провайдера, однако обмен данными в сетях облачного провайдера будет гораздо выше в силу специализированности построенной сети ЦОД. Виртуальные машины Гипервизор - это программное или микропрограммное обеспечение, позволяющее виртуализировать системные ресурсы. Виртуальные машины в гипервизоре логически отделены друг от друга и не привязаны к аппаратному обеспечению, поэтому вирусы и ошибки на одной виртуальной машине никак не влияют на другие на том же гипервизоре и на аппаратную часть сервера, и могут быть легко перемещены с одного сервера на другой. Гипервизор по своей сути аналогичен операционной системе. Существуют 2 типа гипервизоров: гипервизор 1-го типа устанавливается поверх аппаратной части оборудования, 2-й тип устанавливается поверх операционной системы, а также гибридные. В таблице 1 приведены некоторые примеры гипервизоров. Таблица 1 Примеры гипервизоров Гипервизор Тип Требуемые ОС для установки Гостевые ОС KVM 2 Linux, FreeBSD, illumos FreeBSD, Linux, Solaris, Windows, Plan 9 VMware: ESX Server 1 Не требует ОС Windows, Linux, Solaris, FreeBSD, OSx86 (as FreeBSD), virtual appliances, Netware, OS/2, SCO, BeOS, Haiku, Darwin, others: runs arbitrary OS ESXi Server 1 Не требует ОС Fusion 2 macOS Server 2 Windows, Linux Workstation 2 Windows, Linux VMware ESXi (vSphere) 1 No host OS Same as VMware ESX Server Microsoft Hyper-V Hyper-V 2 Windows FreeBSD, Linux (SUSE 10, RHEL 6, CentOS 6) Hyper-V Server 1 Не требует ОС Xen гиб- рид GNU/Liux, Unix-like GNU/Linux, FreeBSD, MiniOS, NetBSD, Solaris, Windows 7/XP/Vista/Server 2008 (requires Intel VT-x (Vanderpool) or AMD-V (Pacifica)-capable CPU), Plan 9 VirtualBox 2 Windows, Linux, macOS, Solaris, FreeBSD, eComStation DOS, Linux, macOS, FreeBSD, Haiku, OS/2, Solaris, Syllable, Windows, and OpenBSD (with Intel VT-x or AMD-V PowerVM ? PowerVM Firmware Linux PowerPC, x86; AIX, IBM i Таким образом при проектировании корпоративной сети с помощью виртуальных серверов, следует заранее определиться с типом виртуальной машины и совместимых с ней операционных систем. Для облачных виртуальных серверов достаточно учитывать совместимые гостевые ОС, обеспечение работоспособности физических серверов и гипервизора берет на себя облачный провайдер. Создание виртуальной машины или виртуальной сети Для переноса элементов корпоративной сети в облако необходимо арендовать у облачного провайдера один или несколько виртуальных серверов, на которых будут развернуты необходимые нам системы. Часто достаточно обойтись моделью предоставления услуги VPS/VDS, описанной в разделе 2, арендовав несколько виртуальных серверов для каждого элемента инфраструктуры. Готовая виртуальная машина (ВМ) на сервере, по сути, будет представлять из себя два файла: файл конфигурации аппаратной части машины и образ диска этой машины, предназначенный для размещения в нем операционной системы. На диске ВМ помимо ОС размещается все программное обеспечение и файлы пользователей. Оба файла, а значит и вся ВМ целиком, могут быть без особых сложностей перенесены или дублированы с одного гипервизора и сервера на другой, что позволяет гибко распределять серверные ресурсы, создавать и восстанавливать резервные копии данных пользователей, а также помогать в процессе миграции на облачную инфраструктуру с уже заранее заготовленными образами систем. Для создания виртуальной машины на сайте почти любого облачного провайдера можно найти параметры конфигурации и "ползунки" для точной настройки вычислительных ресурсов арендуемой виртуальной машины, подобрав все параметры под цели и задачи сервера. Либо же можно воспользоваться "кейсами" - готовыми наборами настроек. А также часто клиентам предлагаются услуги тестирования, платного или бесплатного, арендуемого сервера, чтобы оценить его возможности и соответствие требованиям. Примеры параметров настройки виртуального сервера приведены на рисунке 1. В первом случае идет выбор именно ресурсов сервера, для дальнейшего развертывания на нем "целого парка виртуальных машин". Во втором случае настраивается конкретно виртуальный сервер данный вариант хорошо подойдет. Разворачивание частного облака позволяет создать и настроить необходимое количество виртуальных машин со своими приложениями, но организация и сопровождение такой структуры будет требовать больших затрат по сравнению с выделенным сервером. После создания виртуального сервера на рабочем столе рабочей станции появляется значок подключения к виртуальному серверу. Далее рассмотрим подробнее облачные решения для необходимых нам серверных структур. Терминальный сервер Как уже было упомянуто в разделе 1, терминальный сервер будет представлять собой сервер с заранее установленным на него приложением для удаленной работы с ним посредством "тонкого клиента". Например, такая возможность будет востребована при групповой работе с 1С. В таком случае сервер должен быть связан с сервером базы данных. Это означает, что клиенты подключаются к серверу приложения, а сервер приложения взаимодействует с сервером базы данных. Оба сервера должны находиться в облаке, чтобы между ними была хорошая связь. К терминальному серверу приложений сотрудники могут осуществлять подключение посредством протокола RDP. К приложению (1С, например) может быть организован доступ посредством публикации базы через web-сервер и, соответственно, работой с web-интерфейсом 1С, подключением с помощью "тонкого" или "толстого" клиента 1С или же подключением ко всему серверу терминалов по протоколам удаленного доступа (RDP и другие). Файловый сервер По сути, работа с файловым сервером в облаке ничем не отличается от того, если бы он был в локальной сети. Подключение к файловому серверу обычно осуществляется через протокол FTP (File Transport Protocol) с помощью файлового проводника. Однако следует тщательно взвесить решение о переносе файлового сервера в облако, т.к. объем данных при сообщении с сервером может сильно повлиять на тарифы услуг Интернет. Почтовый сервер В качестве почтового сервера, согласно перечню облачных сервисов, представленному в разделе 2, чаще всего облачные провайдеры используют Microsoft Exchange Server. Он является одним из самых распространенных ПО для корпоративной почты. Подключение к почтовому серверу может осуществляться аналогично другим терминальный приложениям: web, клиенты или удаленный доступ. Также требует доступа к базам данных Виртуальное рабочее место VDI или виртуальное рабочее место позволяет сотрудникам организации использовать рабочую станцию с любой конфигурацией для работы из любого места и в любое время. Для подключения к VDI чаще всего используется специальное клиентское ПО, или же иногда это может осуществляться из браузера. Web-сервер Формально web-приложение также должно быть соединено c сервером базы данных и может быть разбито на 3 части: исполняемый модуль на стороне браузера клиента; исполняемый модуль на стороне сервера; база данных. База данных представляет собой систематизированный набор данных для сетей и пользователей и управляемый посредством системы управления базами данных (СУБД). Пример СУБД MySQL. Сервер печати Следует учесть, что сервер печати однозначно не требует переноса в облако, т.к. выполняет задачу сообщения с офисным оборудованием, таким как принтеры и факсы. Конфигурация сервера Развертывание терминального сервера, а в частности внедрение продуктов 1С одна из самых распространенных задач системны администраторов. И подбор серверной аппаратной конфигурации под данную задачу может служить хорошим примером требований серверных систем к техническим параметрам оборудования. Рассмотрим несколько вариантов организации и аппаратной конфигураций для развертывания 1С сервера с базой данных. Можно предложить 3 варианта: Один сервер с файловой 1С; Один сервер с виртуальными машинами 1С и БД; Два физических сервера: один терминальный 1С, второй с БД. В первом случае будет организован терминальный сервер, на котором будет использоваться файловая версия 1С, таким образом БД будет находиться в файловой системе самого сервера вместе с программой 1С. Для большого количества пользователей разработчик рекомендует использовать систему "клиент-сервер". Организовать терминальный сервер, сервер БД и сервер 1С на одной операционной системе все равно можно, но это будет подвергать сомнению стабильность и информационную безопасность такой системы. Во втором случае как раз-таки и используется такая система, но оба сервера будут виртуальными на одном физическом. Данный вариант и используется в облачной инфраструктуре. Первый сервер будет содержать серверную часть 1С, второй базу данных. В третьем случае будут отдельно использоваться два сервера, а базы данных и программа будут разделены. Для конфигурации общего терминального сервера с двумя виртуальными машинами с расчетом работы примерно на 50 человек должно хватить следующей конфигурации: 10 ядер центрального процессора: по 6-8 терминальных сессий на одно ядро примерно 8 ядер, 1-2 ядра на базу данных, дополнительно еще запас, но для облачных серверов можно в любой момент докупить дополнительную вычислительную мощность; 64 Гб оперативной памяти: операционная система (например, Windows Server) 2 Гб база данных 4-6 Гб сервер 1С 2-4 Гб примерно 700 Мб на каждого пользователя 35 Гб SSD (для быстрых операций) и SAS (для хранения) память данных в условиях облачной инфраструктуры выбор дисковой подсистемы сводится к выбору конкретного типа дисков и их объемов: быстрых твердотельных накопителей (SSD) для быстрых операций чтения/записи и/или более медленных, но вместительных жестких дисков жестких дисков с интерфейсов SAS, подходящих для хранения баз данных. Подключение к облаку Для подключения сотрудников к корпоративному облаку могут применяться комбинации сразу нескольких решений, каждое из которых более детально рассмотрено в таблице 2. Таблица 2 Способы подключения к инфраструктуре в облаке Способ подключения Назначение Требования со стороны сервера Требования со стороны клиента Веб-доступ Доступ к сайту, расположенному на web-сервере через протокол HTTP/HTTPS Наличие выделенного терминального сервера + служба TS Web Access Использование адреса сайта для доступа к ресурсу с помощью браузера RDP Доступ к виртуальным серверам Наличие выделенного терминального сервера Запуск клиента RDP RemoteApp Доступ к терминальным сессиям Наличие конфигурационног о файла со списком программ, имеющим доступ к приложению Запуск сконфигурированного rdp-файла или иконки приложения для подключения к приложению по RDP Remote access VPN Подключение каждого пользователя к серверу через VPN-туннель Наличие сконфигурированного VPN- устройства/сервера. Запуск ярлыка для подключения к VPN-серверу. Продолжение таблицы 2 VPN site-to-site Подключение офиса к серверу через VPN- туннель Наличие двух сконфигурированных VPN-серверов. Пример: VPN-сервер в компании и VPN- сервер в облаке. Отсутствие необходимости создания и запуска ярлыка VPN- подключения. Обращение к ресурсам филиала / центрального офиса / облака напрямую. При обращении к ресурсам VPN- подключение организуется автоматически на уровне серверов. DirectAccess Автоматическая установка связи со всей корпоративной сетью сразу Наличие одного или более серверов DirectAccess в составе домена. Наличие центра сертификации (PKI). Windows - инфраструктура. Только Windows Компьютер клиента должен входить в состав домена. Отсутствие необходимости в создании и запуске ярлыка подключения. VDI Доступ к отдельному виртуальному рабочему месту Развернутая инфраструктура виртуальных рабочих столов VDI Пользователь получает свой собственный виртуальный рабочий стол, к которому можно подключаться с помощью тонкого клиента с любой рабочей станции. Выбор каждого конкретного способа подключения может зависеть от потребностей пользователей, что будет быстрее и удобнее для работы. Облачная инфраструктура корпоративной сети Теперь мы можем составить схему облачной инфраструктуры корпоративной сети. Это будет модифицированная схема из раздела 1. Схема представлена на рисунке:
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59