По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В этой статье мы рассмотрим некоторые протоколы, такие как NTP, syslog и SNMP. Все они используются для мониторинга "работоспособности" вашей сети. При правильной настройке они могут быть очень полезны...если они не работают, может быть действительно трудно выяснить, когда в сети произошло определенное событие и что его вызвало. Syslog и SNMP используются для мониторинга сети, NTP используется для обеспечения того, чтобы наша регистрационная информация имела правильное время и дату. Мы начнем с NTP - это не очень сложный протокол, но есть несколько вещей, которые могут пойти не так: Фильтрация трафика NTP: списки доступа могут блокировать трафик NTP. Проблемы аутентификации NTP: NTP поддерживает аутентификацию, клиент и сервер должны использовать одинаковые настройки. Слишком большое временное смещение: если временное смещение между клиентом и сервером слишком велико, для синхронизации потребуется очень много времени. Stratum level слишком высокий: Stratum level составляет от 1 (лучший) до 15 (худший). Stratum level 16 считается непригодным. Фильтр источника NTP-сервера: NTP-серверы можно настроить так, чтобы разрешать только клиентам с определенных IP-адресов. Давайте разберем эти вопросы. Мы будем использовать два маршрутизатора для этого: Урок 1 R1 будет нашим NTP-клиентом, а R2 будет NTP-сервером. Есть две полезные команды, с которых мы должны начать: Команды говорят нам, что R1 имеет адрес 192.168.12.2, настроенный как сервер NTP, и в настоящее время он не синхронизирован. Давайте проверим, получает ли R1 пакеты NTP, это лучше всего сделать с помощью отладки: Эта отладка говорит нам, что R1 отправляет NTP-пакеты, но мы ничего не получаем от NTP-сервера. Убедитесь, что NTP-сервер разрешен для прохождения: R1 использует UDP-порт 123, убедитесь, что он не заблокирован: R1(config)#interface FastEthernet 0/0 R1(config-if)#no ip access-group NO_TIME in После удаления списка доступа, NTP сможет использовать пакеты NTP с сервера: Вот конечный результат: Часы теперь синхронизированы. Другая проблема, которую вы можете обнаружить с помощью debugging NTP, - это несоответствие аутентификации: R1(config)#ntp server 192.168.12.2 key 1 R1(config)#ntp authentication-key 1 md5 MY_KEY Мы настроим R1 так, чтобы он принимал только NTP-пакеты от NTP-сервера, которые аутентифицированы с определенным ключом. Сервер NTP, однако, не использует никакой формы аутентификации. Мы можем найти эту ошибку с помощью следующей отладки: Это расскажет нам о: Убедитесь, что ваши настройки аутентификации NTP совпадают с обеих сторон. Когда разница во времени / дате между сервером NTP и клиентом велика, синхронизация займет много времени. Прямо сейчас часы выглядят так: Установка часов на NTP-клиенте на что-то близкое к NTP-серверу значительно ускорит процесс синхронизации: R1#clock set 18:00:00 30 January 2015 Через несколько минут часы на клиенте NTP должны быть синхронизированы. Еще одна проблема с NTP заключается в том, что stratum level ограничен, мы можем использовать значения от 1 (лучший) до 15 (худший). Если у сервера NTP есть stratum level 15, то клиент NTP не сможет синхронизировать, так как 16 считается недостижимым. Отладка пакетов NTP на клиенте покажет это: R1 никогда не сможет синхронизировать себя, поскольку NTP-сервер объявляет себя как stratum -уровень 15. Вы можете исправить это, установив более низкое значение stratum - уровня NTP на своем NTP-сервере: R2(config)#ntp master 2 Мы изменяем его на значение 2 уровня. Это позволяет R1 синхронизировать себя: И последнее, но не менее важное: NTP-серверы могут быть настроены так, чтобы разрешать NTP-клиентам только с определенных IP-адресов: Например, мы настрою его, чтобы разрешить только IP-адрес 1.1.1.1: R2(config)#ntp access-group serve 1 R2(config)#access-list 1 permit 1.1.1.1 R2(config)#ip route 1.1.1.1 255.255.255.255 192.168.12.1 В этом случае нам нужно убедиться, что NTP-клиент получает свои NTP-пакеты с правильного IP-адреса: R1(config)#interface loopback 0 R1(config-if)#ip address 1.1.1.1 255.255.255.255 R1(config)#ntp source loopback0 Команда NTP source скажет R1 использовать IP-адрес 1.1.1.1 из своего loopback интерфейса в качестве источника своих пакетов NTP. Это самые распространенные ошибки NTP. Урок 2 Давайте продолжим, посмотрев на syslog. Наиболее распространенная проблема с системным журналом - это отсутствие информации о регистрации. По умолчанию ведение журнала включено только для консоли, а не для внешних серверов системного журнала. Есть одна команда, которую вы можете использовать для проверки ее конфигурации: Это говорит нам, что системный журнал включен для консоли вплоть до уровня отладки. Если вы не видите всего на консоли, то кто-то, возможно, изменил уровень ведения журнала на более низкое значение. Вот варианты: Уровень отладки - самое высокое значение (7), поэтому он покажет все сообщения системного журнала. Если вы не видите все сообщения, убедитесь, что они установлены на уровне отладки для консоли. По умолчанию информация системного журнала не отправляется на внешний сервер. Вы должны это настроить самостоятельно: R1(config)#logging host 192.168.12.2 Это приведет к отправке регистрационной информации для всех уровней серьезности на внешний сервер по адресу 192.168.12.2. Убедитесь, что этот трафик не заблокирован, syslog использует UDP-порт 514. Другая распространенная ошибка - сообщения системного журнала не отображаются в сеансах telnet или SSH. Вы можете включить это с помощью команды terminal monitor. Урок 3 Следующий протокол, который мы обсудим, - это SNMP версии 2c и 3. Перед тем, как погрузиться в конфигурацию SNMP, убедитесь, что ваш NMS (сервер сетевого управления) может связаться с вашим устройством (агент SNMP). SNMP использует UDP-порт 161 для сообщений и UDP-порт 162 для прерываний и информирования. Убедитесь, что этот трафик разрешен. Когда дело доходит до SNMPv2c, есть несколько общих проблем: Неправильная community-string: community-string похожа на пароль, который используется для того, чтобы NMS могла читать или записывать данные на сетевое устройство. Если он не совпадает, SNMP не будет работать. Ошибки списка доступа: списки доступа могут определять, какой NMS разрешено использовать community-string. Убедитесь, что вы используете правильный IP-адрес. Перемешивание индексов: при добавлении новых интерфейсов к сетевому устройству номера интерфейсов могут больше не совпадать. Ловушки не отправлены: если вы хотите отправить SNMP-ловушки (или сообщения), то вам нужно будет настроить это, это не делается автоматически. Вот соответствующие команды SNMPv2c, которые вы должны проверить в случае, если SNMP не работает: R1(config)#snmp-server community MY_COMMUNITY ro 1 R1(config)#access-list 1 permit host 192.168.1.1 Выше мы настроили сообщество под названием MY_COMMUNITY с доступом только для чтения. Мы используем access-list 1, чтобы определить, какому устройству разрешено использовать это сообщество. Убедитесь, что в списке доступа указаны правильные операторы разрешений. Следующая команда гарантирует, что индекс интерфейса остается прежним: R1(config)#snmp-server ifindex persist И если вы хотите отправлять SNMP-ловушки, настройте его следующим образом: R1(config)#snmp-server enable traps eigrp R1(config)#snmp-server host 192.168.1.1 traps version 2c MY_COMMUNITY Это активирует ловушки SNMP для EIGRP и будет отправлено в NMS на IP-адрес 192.168.1.1 с использованием сообщества "MY_COMMUNITY". Если вы не укажете, какие ловушки вы хотите, он включит все ловушки. SNMPv3 сильно отличается от версии 2, в безопасность и аутентификацию внесено много изменений. При поиске и устранении неисправностей SNMPv3 необходимо учитывать несколько моментов, связанных с SNMPv3: Вложенность: с помощью SNMPv3 мы создаем пользователей, которые вложены в группы. Группы вложены в представления, которые предоставляют доступ к определенным MIBs на сетевом устройстве. Убедитесь, что ваш пользователь находится в правильной группе и что представление имеет правильные разрешения на просмотр. Уровень безопасности: SNMPv3 поддерживает разные уровни безопасности, они должны совпадать на сетевом устройстве и NMS: noAuthNoPriv authNoPriv authPriv Параметры безопасности: SNMPv3 предлагает несколько алгоритмов хеширования и шифрования. Убедитесь, что вы настроили одинаковые алгоритмы на сетевом устройстве и NMS. Конфигурация представлений: в представлении мы настраиваем объекты, к которым NMS разрешен доступ, убедитесь, что вы настроили правильные объекты. Ниже приеден пример конфигурации того, что мы обсуждали: Router(config)#snmp-server user MY_USER MY_GROUP v3 auth md5 MY_PASSWORD priv aes 128 MY_PASSWORD Сначала мы настраиваем пользователя с именем MY_USER, который принадлежит группе с именем MY_GROUP. Мы используем версию 3 SNMP. Для аутентификации этого пользователя мы используем MD5 и пароль "MY_PASSWORD". Для шифрования мы используем 128-битный AES и тот же пароль. Убедитесь, что на сетевом устройстве и NMS все одинаково ... Теперь мы настраиваем группу: Router(config)#snmp-server group MY_GROUP v3 priv read MY_VIEW access 1 Router(config)#access-list 1 permit host 192.168.1.1 Группа называется MY_GROUP, и мы используем уровень безопасности authPriv. Мы также присоединяем группу к представлению под названием MY_VIEW. Мы также используем список доступа, только NMS, использующая IP-адрес 192.168.1.1, может использовать эту группу. Давайте настроим view: Router(config)#snmp-server view MY_VIEW system included Router(config)#snmp-server view MY_VIEW cisco included Это представление позволяет NMS получать доступ только к объектам в системной группе MIB-II и ко всем объектам в корпоративной MIB Cisco. Убедитесь, что вы добавили все объекты, к которым вам нужен доступ. Информация о пользователе не отображается в конфигурации, если вы хотите увидеть пользователей, вам нужно использовать другую команду: Эта команда показывает нам нашу учетную запись пользователя, ее алгоритмы аутентификации и шифрования и сообщает, к какой группе она принадлежит.
img
Дорогой друг! Ранее мы рассказывали про новинки FreePBX 14. Новые и интересные фичи безусловно не будут лишними. Ну что же, приступим теперь к обновлению FreePBX 13 версии до 14? Pre-work Рекомендуем перед началом работ сделать полный бэкап/снэпшот сервера, на котором будут производиться работы; Как и у любого пользователя FreePBX, у вас в Dashboard графической оболочки появилось следующее уведомление: Заманчивое название модуля. Переходим в консоль (подключаемся пол SSH) вашего сервера и даем простую команду: fwconsole ma downloadinstall versionupgrade Модуль будет установлен: Теперь возвращаемся в FreePBX. В правом верхнем углу нажимаем Apply Config. Далее, прыгаем по пути Admin → 13 to 14 Upgrade Tool и вот что мы увидим: Нажимаем на кнопку Check the requirements! и смотрим: система говорит, что у нас установлен FreePBX Distro и нам необходимо воспользоваться специальным скриптом для апгрейда. Что же, приступим к обновлению вручную. Обновление через CLI Перед началом работ есть определенные требования, такие как: Сервер с 64 - битной архитектурой; Как минимум 10 Гб свободного места; Стабильное интернет соединение; Если вы используете 32 – битную архитектуру, то проще всего воспользоваться FreePBX Conversion tool, сделав бэкап на 32 – битной системе, а восстановить его в системе 64 – бит с FreePBX 14. При попытке установки на 32 – битной системе процесс предупредит вас об этом: Устанавливаем нужный RPM: yum -y install http://package1.sangoma.net/distro-upgrade-1707-16.sng7.noarch.rpm После успешной установки RPM даем следующую команду: distro-upgrade И переходим в интерактивный режим: [root@freepbx ~]# distro-upgrade ?????????????????????????????????????????????? ? ? ? Sangoma 6 to 7 Upgrade Tool ? ? ? ? Distro Upgrade - Version 1707-2.sng7 ? ? Build Date: 2017-06-21 ? ? ? ?????????????????????????????????????????????? Checking prerequsites... Checking bitsize of machine [ ? ] - x86_64 Checking available disk space [ ? ] - 13G Available All prerequsites passed! Are you ready to upgrade your machine to SNG7? This process requires two reboots, and will download approximately 200mb of files before starting. There will be no interruption to service until this machine is rebooted. Download files required for upgrade [Yn]? Указываем y: Download files required for upgrade [Yn]? y ######### Starting setup upgrade on Tue Aug 22 17:39:08 MSK 2017 ######### ######### Creating upgrade repofile ######### ######### Installing needed packages ######### ######### Running preupgrade ######### ######### Running upgrade-tool ######### ######### Downloading sangoma-release rpm ######### ######### Updating packages.list ######### ######### Verified sangoma-release in package.list ######### ######### Reboot to finish this stage of the upgrade ######### ######### Finished setup upgrade on Tue Aug 22 17:44:12 MSK 2017 ######### Preparations complete! Please reboot your machine when convenient. This machine will install all the new and upgraded packages, and then reboot for a second time automatically. After the second reboot, it will then continue the upgrade process automatically. When the upgrade is complete, you will be presented with a standard login prompt. Важно! Данный процесс можно проводить в рабочее время параллельно с обслуживанием вызовов. Даунтайм подразумевается только далее, после перезагрузки. Перезагружаем сервер командой reboot. При загрузке, у вас будет автоматически выбрана опция System Upgrade, как показано ниже. Если нет, то выберите эту опцию вручную стрелками на клавиатуре: После этого начнется процесс обновления. Длительность этого процесса напрямую коррелирует с производительностью вашего сервера. После обновление компоненты Core OS произойдет вторая перезагрузка, в рамках которой произойдет обновление всех модулей FreePBX, после чего апгрейд будет завершен. По окончанию, вы увидите стандартный баннер FreePBX 14: Выполняем проверку версии. Даем команду в консоль: ls -l /usr/src | grep freepbx Если все ОК, то вывод будет вот такой:
img
Файл CSV (Comma Separated Values - значения, разделенные запятыми) использует запятые для разделения различных значений в файле. Файл CSV является стандартным форматом при переносе таблицы в другую систему или ее импорте в другое приложение базы данных. Это подробное руководство покажет вам, как экспортировать базу данных MySQL в файл CSV и импортировать файл CSV обратно в базу данных MySQL. Экспорт MySQL в CSV Нам понадобится: Доступ к командной строке или окну терминала Учетная запись пользователя с привилегиями root или sudo Учетная запись пользователя MySQL с правами root Предварительно настроенная учетная запись phpMyAdmin (необязательно) Экспорт MySQL в CSV с phpMyAdmin Инструмент phpMyAdmin предоставляет бесплатный графический интерфейс для управления базами данных MySQL. Вы можете использовать его для экспорта любой из отслеживаемых баз данных в файл CSV. Войдите в phpMyAdmin. Затем нажмите кнопку Databases (Базы данных) в верхней части баннера. В списке баз данных щелкните ссылку на базу данных, которую вы хотите экспортировать. В этом примере мы выбрали базу данных user. На следующем экране отображается список таблиц в этой базе данных. Установите флажки для таблиц, которые вы хотите экспортировать. Нажмите кнопку Export на баннере внизу. Оставьте метод экспорта установленным как есть. Используйте раскрывающееся меню Format, чтобы выбрать CSV, затем нажмите Go. Диалоговое окно предлагает указать место, где вы хотите сохранить файл CSV. Экспорт из MySQL в CSV с помощью командной строки Вы можете выполнить экспорт без излишеств через CLI, выбрав все данные в таблице и указав место, куда их нужно сохранить. Начните с открытия оболочки MySQL, затем переключитесь на базу данных, которую вы хотите экспортировать. Введите следующую команду: SELECT * FROM myTable INTO OUTFILE ' mpmyExportFile.csv' FIELDS ENCLOSED BY '"' TERMINATED BY ';' ESCAPED BY '"' LINES TERMINATED BY ' '; Замените myTable реальным именем таблицы из вашей базы данных. Вы можете заменить mpmyExportFile.csv любым другим именем файла или местоположением. Не забудьте сохранить имя файла .csv в конце. Примечание. В этом примере используется местоположение файла Linux. Если вы работаете в Windows, вы можете использовать c:/folder/file.csv для вашего местоположения файла. Дополнительные параметры для экспорта из MySQL Чтобы указать отдельные наборы данных для экспорта из таблицы: SELECT column1, column2, column3, column4 FROM myTable WHERE column2 = 'value'; Замените column1 (и остальные) фактическими именами столбцов, которые вы хотите экспортировать. Обязательно используйте команду FROM, чтобы указать таблицу, из которой вы экспортируете. Оператор WHERE является необязательным и позволяет экспортировать только те строки, которые содержат определенное значение. Замените значение фактическим значением, которое вы хотите экспортировать. Например: SELECT order_date, order_number, order_status FROM current_orders WHERE order_status='pending';
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59