По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Предыдущая статья из цикла про соответствие пакетов в IP ACL.
Обратные маски, такие как значения dotted-decimal number (DDN), фактически представляют собой 32-разрядное двоичное число. Как 32-разрядное число, маска WC фактически направляет логику маршрутизатора бит за битом. Короче говоря, бит маски WC (wildcard), равный 0, означает, что сравнение должно выполняться как обычно, но двоичный 1 означает, что бит является подстановочным знаком и может быть проигнорирован при сравнении чисел.
Кстати, наш калькулятор подсетей показывает и сам считает WC (wildcard) маску.
Вы можете игнорировать двоичную маску WC. Почему? Что ж, обычно мы хотим сопоставить диапазон адресов, которые можно легко идентифицировать по номеру подсети и маске, будь то реальная подсеть или сводный маршрут, который группирует подсети вместе. Если вы можете указать диапазон адресов с помощью номера подсети и маски, вы можете найти числа для использования в вашем ACL с помощью простой десятичной математики, как описано далее.
Если вы действительно хотите знать логику двоичной маски, возьмите два номера DDN, которые ACL будет сравнивать (один из команды access-list, а другой из заголовка пакета), и преобразуйте оба в двоичный код. Затем также преобразуйте маску WC в двоичную. Сравните первые два двоичных числа бит за битом, но также игнорируйте любые биты, для которых маска WC случайно перечисляет двоичный 1, потому что это говорит вам игнорировать бит. Если все биты, которые вы проверили, равны, это совпадение!
Нахождения правильной обратной маски, соответствующей подсети
Во многих случаях ACL должен соответствовать всем хостам в определенной подсети. Чтобы соответствовать подсети с помощью ACL, вы можете использовать следующие сочетания:
Используйте номер подсети в качестве исходного значения в команде access-list.
Используйте обратную маску, полученную путем вычитания маски подсети из 255.255.255.255.
Например, для подсети 172.16.8.0 255.255.252.0 используйте номер подсети (172.16.8.0) в качестве параметра адреса, а затем выполните следующие вычисления, чтобы найти обратную маску:
Продолжая этот пример, завершенная команда для той же подсети будет следующей:
access-list 1 permit 172.16.8.0 0.0.3.255
Соответствие любому/всем адресам
В некоторых случаях вам может понадобиться одна команда ACL для сопоставления всех без исключения пакетов, которые достигают этой точки в ACL. Во-первых, вы должны знать (простой) способ сопоставить все пакеты с помощью ключевого слова any. Что еще более важно, вам нужно подумать о том, когда сопоставить все без исключения пакеты.
Во-первых, чтобы сопоставить все пакеты с помощью команды ACL, просто используйте ключевое слово any для адреса. Например, чтобы разрешить все пакеты:
access-list 1 permit any
Итак, когда и где вы должны использовать такую команду? Помните, что все ACL Cisco IP заканчиваются неявным отрицанием любой концепции в конце каждого ACL. То есть, если маршрутизатор сравнивает пакет с ACL, и пакет не соответствует ни одному из настроенных операторов, маршрутизатор отбрасывает пакет. Хотите переопределить это поведение по умолчанию? Настроить permit any в конце ACL.
Вы также можете явно настроить команду для запрета всего трафика (например, access-list 1 deny any) в конце ACL. Почему, когда та же самая логика уже находится в конце ACL? Что ж, ACL показывает счетчики списка для количества пакетов, соответствующих каждой команде в ACL, но нет счетчика для этого не явного запрета любой концепции в конце ACL. Итак, если вы хотите видеть счетчики количества пакетов, совпадающих с логикой deny any в конце ACL, настройте явное deny any.
Внедрение стандартных IP ACL
В этой лекции уже представлены все этапы настройки по частям. Далее суммируются все эти части в единую конфигурацию. Эта конфигурация основана на команде access-list, общий синтаксис которой повторяется здесь для справки:
access-list access-list-number {deny | permit} source [source-wildcard]
Этап 1. Спланируйте локацию (маршрутизатор и интерфейс) и направление (внутрь или наружу) на этом интерфейсе:
Стандартные списки ACL должны быть размещены рядом с местом назначения пакетов, чтобы они случайно не отбрасывали пакеты, которые не следует отбрасывать.
Поскольку стандартные списки ACL могут соответствовать только исходному IP-адресу пакета, идентифицируйте исходные IP-адреса пакетов по мере их прохождения в направлении, которое проверяет ACL.
Этап 2. Настройте одну или несколько команд глобальной конфигурации списка доступа для создания ACL, учитывая следующее:
Список просматривается последовательно с использованием логики первого совпадения.
Действие по умолчанию, если пакет не соответствует ни одной из команд списка доступа, - отклонить (отбросить) пакет.
Этап 3. Включите ACL на выбранном интерфейсе маршрутизатора в правильном направлении, используя подкоманду ip access-group number {in | out}.
Далее рассмотрим несколько примеров.
Стандартный нумерованный список ACL, пример 1
В первом примере показана конфигурация для тех же требований, что и на рисунках 4 и 5. Итак, требования для этого ACL следующие:
Включите входящий ACL на интерфейсе R2 S0/0/1.
Разрешить пакеты, приходящие от хоста A.
Запретить пакеты, приходящие от других хостов в подсети хоста A.
Разрешить пакеты, приходящие с любого другого адреса в сети класса A 10.0.0.0.
В исходном примере ничего не говорится о том, что делать по умолчанию, поэтому просто запретите весь другой трафик.
В примере 1 показана завершенная правильная конфигурация, начиная с процесса настройки, за которым следует вывод команды show running-config.
R2# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)# access-list 1 permit 10.1.1.1
R2(config)# access-list 1 deny 10.1.1.0 0.0.0.255
R2(config)# access-list 1 permit 10.0.0.0 0.255.255.255
R2(config)# interface S0/0/1
R2(config-if)# ip access-group 1 in
R2(config-if)# ^Z
R2# show running-config
! Lines omitted for brevity
access-list 1 permit 10.1.1.1
access-list 1 deny 10.1.1.0 0.0.0.255
access-list 1 permit 10.0.0.0 0.255.255.255
Во-первых, обратите внимание на процесс настройки в верхней части примера. Обратите внимание, что команда access-list не изменяет командную строку из приглашения режима глобальной конфигурации, поскольку команда access-list является командой глобальной конфигурации. Затем сравните это с выводом команды show running-config: детали идентичны по сравнению с командами, которые были добавлены в режиме конфигурации. Наконец, не забудьте указать ip access-group 1 в команде под интерфейсом R2 S0/0/1, который включает логику ACL (как локацию, так и направление).
В примере 2 перечислены некоторые выходные данные маршрутизатора R2, которые показывают информацию об этом ACL. Команда show ip access-lists выводит подробную информацию только о списках ACL IPv4, а команда show access-lists перечисляет сведения о списках ACL IPv4, а также о любых других типах ACL, настроенных в настоящее время, например, списки ACL IPv6.
Вывод этих команд показывает два примечания. В первой строке вывода в этом случае указывается тип (стандарт) и номер. Если существовало более одного ACL, вы бы увидели несколько разделов вывода, по одной на каждый ACL, каждая со строкой заголовка, подобной этой. Затем эти команды перечисляют счетчики пакетов для количества пакетов, которые маршрутизатор сопоставил с каждой командой. Например, на данный момент 107 пакетов соответствуют первой строке в ACL.
Наконец, в конце примера перечислены выходные данные команды show ip interface. Эта команда перечисляет, среди многих других элементов, номер или имя любого IP ACL, включенного на интерфейсе для подкоманды интерфейса ip access-group.
Стандартный нумерованный список ACL, пример 2
Для второго примера используйте рисунок 8 и представьте, что ваш начальник в спешке дает вам некоторые требования в холле. Сначала он говорит вам, что хочет фильтровать пакеты, идущие от серверов справа к клиентам слева. Затем он говорит, что хочет, чтобы вы разрешили доступ для хостов A, B и других хостов в той же подсети к серверу S1, но запретили доступ к этому серверу хостам в подсети хоста C. Затем он сообщает вам, что, кроме того, хостам в подсети хоста A следует отказать в доступе к серверу S2, но хостам в подсети хоста C должен быть разрешен доступ к серверу S2 - и все это путем фильтрации пакетов, идущих только справа налево. Затем он говорит вам поместить входящий ACL на интерфейс F0/0 R2.
Если вы просмотрите все запросы начальника, требования могут быть сокращены до следующего:
Включите входящий ACL на интерфейсе F0/0 R2.
Разрешить пакеты от сервера S1, идущие к хостам в подсети A.
Запретить пакетам с сервера S1 идти к хостам в подсети C.
Разрешить пакетам с сервера S2 идти к хостам в подсети C.
Запретить пакетам с сервера S2 идти к хостам в подсети A.
Не было комментариев о том, что делать по умолчанию; используйте подразумеваемое отклонение всего по умолчанию.
Как оказалось, вы не можете сделать все, что просил ваш начальник, с помощью стандартного ACL. Например, рассмотрим очевидную команду для требования номер 2: access-list 2 permit 10.2.2.1. Это разрешает весь трафик с исходным IP-адресом 10.2.2.1 (сервер S1). Следующее требование просит вас фильтровать (отклонять) пакеты, полученные с того же IP-адреса! Даже если вы добавите другую команду, которая проверяет исходный IP-адрес 10.2.2.1, маршрутизатор никогда не доберется до него, потому что маршрутизаторы используют логику первого совпадения при поиске в ACL. Вы не можете проверить и IP-адрес назначения, и исходный IP-адрес, потому что стандартные ACL не могут проверить IP-адрес назначения.
Чтобы решить эту проблему, вам следует переосмыслить проблему и изменить правила. В реальной жизни вы, вероятно, вместо этого использовали бы расширенный ACL, который позволяет вам проверять как исходный, так и целевой IP-адрес.
Представьте себе, что ваш начальник позволяет вам изменять требования, чтобы попрактиковаться в другом стандартном ACL. Во-первых, вы будете использовать два исходящих ACL, оба на маршрутизаторе R1. Каждый ACL разрешает пересылку трафика с одного сервера в эту подключенную локальную сеть со следующими измененными требованиями:
Используя исходящий ACL на интерфейсе F0 / 0 маршрутизатора R1, разрешите пакеты с сервера S1 и запретите все остальные пакеты.
Используя исходящий ACL на интерфейсе F0 / 1 маршрутизатора R1, разрешите пакеты с сервера S2 и запретите все остальные пакеты.
Пример 3 показывает конфигурацию, которая удовлетворяет этим требованиям.
access-list 2 remark This ACL permits server S1 traffic to host A's subnet
access-list 2 permit 10.2.2.1
!
access-list 3 remark This ACL permits server S2 traffic to host C's subnet
access-list 3 permit 10.2.2.2
!
interface F0/0
ip access-group 2 out
!
interface F0/1
ip access-group 3 out
Как показано в примере, решение с номером ACL 2 разрешает весь трафик с сервера S1, при этом эта логика включена для пакетов, выходящих из интерфейса F0/0 маршрутизатора R1. Весь другой трафик будет отброшен из-за подразумеваемого запрета all в конце ACL. Кроме того, ACL 3 разрешает трафик от сервера S2, которому затем разрешается выходить из интерфейса F0/1 маршрутизатора R1. Также обратите внимание, что решение показывает использование параметра примечания списка доступа, который позволяет оставить текстовую документацию, которая остается в ACL.
Когда маршрутизаторы применяют ACL для фильтрации пакетов в исходящем направлении, как показано в Примере 2, маршрутизатор проверяет пакеты, которые он направляет, по списку ACL. Однако маршрутизатор не фильтрует пакеты, которые сам маршрутизатор создает с помощью исходящего ACL. Примеры таких пакетов включают сообщения протокола маршрутизации и пакеты, отправленные командами ping и traceroute на этом маршрутизаторе.
Советы по устранению неполадок и проверке
Устранение неполадок в списках ACL IPv4 требует внимания к деталям. В частности, вы должны быть готовы посмотреть адрес и обратную маску и с уверенностью предсказать адреса, соответствующие этим двум комбинированным параметрам.
Во-первых, вы можете определить, соответствует ли маршрутизатор пакетам или нет, с помощью пары инструментов. Пример 2 уже показал, что IOS хранит статистику о пакетах, соответствующих каждой строке ACL. Вдобавок, если вы добавите ключевое слово log в конец команды access-list, IOS затем выдает сообщения журнала со случайной статистикой совпадений с этой конкретной строкой ACL. И статистика, и сообщения журнала могут помочь решить, какая строка в ACL соответствует пакету.
Например, в примере 4 показана обновленная версия ACL 2 из примера 3, на этот раз с добавленным ключевым словом log. Внизу примера затем показано типичное сообщение журнала, в котором показано результирующее совпадение на основе пакета с исходным IP-адресом 10.2.2.1 (в соответствии с ACL) с адресом назначения 10.1.1.1.
R1# show running-config
! lines removed for brevity
access-list 2 remark This ACL permits server S1 traffic to host A's subnet
access-list 2 permit 10.2.2.1 log
!
interface F0/0
ip access-group 2 out
R1#
Feb 4 18:30:24.082: %SEC-6-IPACCESSLOGNP: list 2 permitted 0 10.2.2.1 -> 10.1.1.1, 1
Packet
Когда вы впервые устраняете неисправности на ACL, прежде чем вдаваться в подробности логики сопоставления, подумайте, как об интерфейсе, на котором включен ACL, так и о направлении потока пакетов. Иногда логика сопоставления идеальна, но ACL был включен на неправильном интерфейсе или в неправильном направлении, чтобы соответствовать пакетам, настроенным для ACL.
Например, на рисунке 9 повторяется тот же ACL, показанный ранее на рисунке 7. Первая строка этого ACL соответствует конкретному адресу хоста 10.1.1.1. Если этот ACL существует на маршрутизаторе R2, размещение этого ACL в качестве входящего ACL на интерфейсе S0/0/1 R2 может работать, потому что пакеты, отправленные хостом 10.1.1.1 - в левой части рисунка - могут входить в интерфейс S0/0/1 маршрутизатора R2. Однако, если R2 включает ACL 1 на своем интерфейсе F0/0 для входящих пакетов, ACL никогда не будет соответствовать пакету с исходным IP-адресом 10.1.1.1, потому что пакеты, отправленные хостом 10.1.1.1, никогда не войдут в этот интерфейс. Пакеты, отправленные 10.1.1.1, будут выходить из интерфейса R2 F0/0, но никогда не попадут в него только из-за топологии сети.
Нормализация базы данных (БД) - это метод проектирования реляционных БД, который помогает правильно структурировать таблицы данных. Процесс направлен на создание системы с четким представлением информации и взаимосвязей, без избыточности и потери данных.
В данной статье рассказывается, что такое нормализация базы данных, и объясняются принципы ее работы на практическом примере.
Что такое нормализация базы данных?
Нормализация базы данных - это метод создания таблиц БД со столбцами и ключами путем разделения (или декомпозиции) таблицы большего размера на небольшие логические единицы. В данном методе учитываются требования, предъявляемые к среде БД.
Нормализация - это итеративный процесс. Как правило, нормализация БД выполняется через серию тестов. Каждый последующий шаг разбивает таблицу на более легкую в управлении информацию, чем повышается общая логичность системы и простота работы с ней.
Зачем нужна нормализация базы данных?
Нормализация позволяет разработчику БД оптимально распределять атрибуты по таблицам. Данная методика избавляет от:
атрибутов с несколькими значениями;
задвоения или повторяющихся атрибутов;
атрибутов, не поддающихся классификации;
атрибутов с избыточной информацией;
атрибутов, созданных из других признаков.
Необязательно выполнять полную нормализацию БД. Однако она гарантирует полноценно функционирующую информационную среду. Этот метод:
позволяет создать структуру базы данных, подходящую для общих запросов;
сводит к минимуму избыточность данных, что повышает эффективность использования памяти на сервере БД;
гарантирует максимальную целостность данных, устраняя аномалий вставки, обновления и удаления.
Нормализация базы данных преобразует общую целостность данных в удобную для пользователя среду.
Избыточность баз данных и аномалии
Когда вы вносите изменения в таблицу избыточностью, вам придется корректировать все повторяющиеся экземпляры данных и связанные с ними объекты. Если этого не сделать, то таблица станет несогласованной, и при внесении изменений возникнут аномалии.
Так выглядит таблица без нормализации:
Для таблицы характерна избыточность данных, а при изменении этих данных возникают 3 аномалии:
Аномалия вставки. При добавлении нового «Сотрудника» (employee) в «Отдел» (sector) Finance, обязательно указывается его «Руководитель» (manager). Иначе вы не сможете вставить данные в таблицу.
Аномалия обновления. Когда сотрудник переходит в другой отдел, поле «Руководитель» содержит ошибочные данные. К примеру, Джейкоб (Jacob) перешел в отдел Finance, но его руководителем по-прежнему показывается Адам (Adam).
Аномалия удаления. Если Джошуа (Joshua) решит уволиться из компании, то при удалении строки с его записью потеряется информация о том, что отдел Finance вообще существует.
Для устранения подобных аномалий используется нормализация базы данных.
Основные понятия в нормализации базы данных
Простейшие понятия, используемые в нормализации базы данных:
ключи - атрибуты столбцов, которые однозначно (уникально) определяют запись в БД;
функциональные зависимости - ограничения между двумя взаимосвязанными атрибутами;
нормальные формы - этапы для достижения определенного качества БД.
Нормальные формы базы данных
Нормализация базы данных выполняется с помощью набора правил. Такие правила называются нормальными формами. Основная цель данных правил - помочь разработчику БД в достижении нужного качества реляционной базы.
Все уровни нормализации считаются кумулятивными, или накопительными. Прежде чем перейти к следующему этапу, выполняются все требования к текущей форме.
Стадии нормализации:
Стадия
Аномалии избыточности
Ненормализованная (нулевая) форма (UNF)
Это состояние перед любой нормализацией. В таблице присутствуют избыточные и сложные значения
Первая нормальная форма (1NF)
Разбиваются повторяющиеся и сложные значения; все экземпляры становятся атомарными
Вторая нормальная форма (2NF)
Частичные зависимости разделяются на новые таблицы. Все строки функционально зависимы от первичного ключа
Третья нормальная форма (3NF)
Транзитивные зависимости разбиваются на новые таблицы. Не ключевые атрибуты зависят от первичного ключа
Нормальная форма Бойса-Кода (BCNF)
Транзитивные и частичные функциональные зависимости для всех потенциальных ключей разбиваются на новые таблицы
Четвертая нормальная форма (4NF)
Удаляются многозначные зависимости
Пятая нормальная форма (5NF)
Удаляются JOIN-зависимости (зависимости соединения)
База данных считается нормализованной после достижения третьей нормальной формы. Дальнейшие этапы нормализации усложняю структуру БД и могут нарушить функционал системы.
Что такое Ключ?
Ключ БД (key) - это атрибут или группа признаков, которые однозначно описывают сущность в таблице. В нормализации используются следующие типы ключей:
суперключ (Super Key) - набор признаков, которые уникально определяют каждую запись в таблице;
потенциальный ключ (Candidate Key) - выбирается из набора суперключей с минимальным количеством полей;
первичный ключ (Primary Key) - самый подходящий кандидат из набора потенциальных ключей; служит первичным ключом таблицы;
внешний ключ (Foreign Key) - первичный ключ другой таблицы;
составной ключ (Composite Key) - уникальный ключ, образованный двумя и более атрибутами, каждый из которых по отдельности не является ключом.
Поскольку таблицы разделяются на несколько более простых единиц, именно ключи определяют точку ссылки для объекта БД.
Например, в следующей структуре базы данных:
Примерами суперключей являются:
employeeID;
(employeeID, name);
email
Все суперключи служат уникальным идентификатором каждой строки. К примеру, имя сотрудника и его возраст не считаются уникальными идентификаторами, поскольку несколько людей могут быть тезками и одногодками.
Потенциальные ключи выбираются из набора суперключей с минимальным количеством полей. В нашем примере это:
employeeID;
email
Оба параметра содержат минимальное количество полей, поэтому они хорошо подходят на роль потенциальных ключей. Самый логичный выбор для первичного ключа - поле employeeID, поскольку почта сотрудника может измениться. На такой первичный ключ легко ссылаться в другой таблице, для которой он будет считаться внешним ключом.
Функциональные зависимости базы данных
Функциональная зависимость БД отражает взаимосвязь между двумя атрибутами таблицы. Функциональные зависимости бывают следующих типов:
тривиальная функциональная зависимость - зависимость между атрибутом и группой признаков; исходный элемент является частью группы;
нетривиальная функциональная зависимость - зависимость между атрибутом и группой признаков; признак не является частью группы;
транзитивная зависимость - функциональная зависимость между тремя атрибутами: второй атрибут зависит от первого, а третий - от второго. Благодаря транзитивности, третий атрибут зависит от первого;
многозначная зависимость - зависимость, в которой несколько значений зависят от одного атрибута.
Функциональные зависимости - это важный этап в нормализации БД. В долгосрочной перспективе такие зависимости помогают оценить общее качество базы данных.
Примеры нормализации базы данных. Как нормализовать базу данных?
Общие этапы в нормализации базы данных подходят для всех таблиц. Конкретные методы разделения таблицы, а также вариант прохождения или не прохождения через третью нормальную форму (3NF) зависят от примеров использования.
Пример ненормализованной базы данных
В одном столбце ненормализованной таблицы содержится несколько значений. В худшем случае в ней присутствует избыточная информация.
Например:
Добавление, обновление и удаление данных - все это сложные задачи. Выполнение любых изменений текущих данных сопряжено с высоким риском потери информации.
Шаг 1: Первая нормальная форма (1NF)
Для преобразования таблицы в первую нормальную форму значения полей должны быть атомарными. Все сложные сущности таблицы разделяются на новые строки или столбцы.
Чтобы не потерять информацию, для каждого сотрудника дублируются значения столбцов managerID, managerName и area.
Доработанная таблица соответствует первой нормальной форме.
Шаг 2: Вторая нормальная форма (2NF)
Во второй нормальной форме каждая строка таблицы должна зависеть от первичного ключа.
Чтобы таблица соответствовала критериям этой формы, ее необходимо разделить на 2 части:
Manager (managerID, managerName, area)
Employee (employeeID, employeeName, managerID, sectorID, sectorName)
Итоговая таблица во второй нормальной форме представляет собой 2 таблицы без частичных зависимостей.
Шаг 3: третья нормальная форма (3NF)
Третья нормальная форма разделяет любые транзитивные функциональные зависимости. В нашем примере транзитивная зависимость есть у таблицы Employee; она разбивается на 2 новых таблицы:
Employee (employeeID, employeeName, managerID, sectorID)
Sector (sectorID, sectorName)
Теперь таблица соответствует третьей нормальной форме с тремя взаимосвязями. Конечная структура выглядит так:
Теперь база данных считается нормализованной. Дальнейшая нормализация зависит от ваших конкретных целей.
Заключение
В статье рассказывалось, как с помощью нормализации БД можно сократить избыточность информации. В долгосрочной перспективе нормализация БД позволяет свести к минимуму потерю данных и улучшить их общую структуру.
Если же вы хотите повысить производительность доступа к данным, то воспользуйтесь денормализацией БД.
А если вы испытываете трудности с нормализацией базы данных, то рассмотрите возможность перехода на другой тип БД.
CentOS Web Panel (CWP) поможет легко установить стек LAMP или LEMP. Это бесплатное решение и работает на CentOS.
Если вы ищете место для размещения CMS вроде WordPress, Joomla и т.д., или PHP-приложения, где вам нужен веб-сервер, база данных, электронные письма, мониторинг и безопасность, то у вас есть два варианта.
Вы приобретаете виртуальную машину у одног из публичных облачных провайдеров и устанавливаете каждое программное обеспечение вручную. Это может занять много времени, и вам нужны навыки системного администрирования.
Или же выбираете способ попроще - вы получаете облачную виртуальную машину и устанавливаете CWP. Затем вы устанавливаете необходимое программное обеспечение через графический интерфейс пользователя. Это займет гораздо меньше времени, чем делать это вручную.
CWP позволяет установить более 50 программ/компонентов, самые популярные из которых указаны ниже.
Веб-стек - Apache, Nginx, Varnish
Стек приложений - PHP-FPM, MySQL, PostgreSQL, phpMyAdmin
Безопасность - сертификаты TLS, брандмауэр CSF, Mod Security с правилами OWASP
DNS и электронная почта - DNS-сервер, почтовые ящики, AntiSpam, Postfix
Мониторинг - метрики сервера, такие как CPU, файловая система, память
Диспетчер файлов
Crontab
В целом она выглядит многообещающим для размещения приложений на основе PHP. Давайте установим CWP и посмотрим, как он выглядит.
Установка CWP на CentOS
Следующая демонстрация выполняется на виртуальной машине Kamatera.
Войдите на сервер CentOS 7.x с учетной записью root-а или учетной записью с привилегией sudo
Выполните следующую команду для обновления YUM и установки CWP
yum -y install wget
yum -y update
wget http://centos-webpanel.com/cwp-el7-latest
sh cwp-el7-latest
Установка займет несколько минут. После окончания вы должны получить соответствующее уведомление.
#############################
# CWP Installed #
#############################
Go to CentOS WebPanel Admin GUI at http://SERVER_IP:2030/
http://167.71.1x1.xx:2030
SSL: https://167.71.1x1.xx:2031
Для вступления изменений в силу потребуется перезагрузка, которую можно выполнить командой:
shutdown -r now
К веб-панели CWP можно подключиться по 2030 (HTTP) и 2031 (HTTPS) портам. При первом входе в качестве имени пользователя можно использовать root и его пароль, и после входа в систему вы должны увидеть что-то подобное.
Интерфейс выглядит аккуратным и чистым. В левой части навигации можно найти все параметры, необходимые для установки, настройки и управления программным обеспечением и сервером.