Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 1257 сообщений
Cообщения с меткой

администрирование - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Заметки о Cisco Catalyst: настройка VLAN, сброс пароля, перепрошивка операционной системы IOS

Суббота, 15 Апреля 2017 г. 21:38 (ссылка)

Пошаговое руководство по выполнению наиболее типовых задач, связанных с обслуживанием коммутаторов Cisco Catalyst 2950. А именно: настройка VLAN, сброс пароля, переустановка повреждённой операционной системы Cisco IOS. Подробно рассмотрен вопрос подключения, в том числе через com-порт.







Данная статья является продолжением Основы TCP/IP для будущих дилетантов, где я рассказывал о теоретических основах построения ЛВС. Как и прошлая статья, эта — рассчитана на новичков в области.



Подключение к коммутатору



Для того, что бы выполнить какую либо настройку коммутатора, к нему надо подключиться с персонального компьютера или ноут-бука. Есть два вида подключения — через com порт или через web интерфейс.



Подключение через com порт



Для подключения через com порт вам понадобится «консольный провод». Это, как правило, голубой плоский провод. Он должен идти в комплекте с коммутатором. Один конец провода подсоединяется к com порту вашего ПК (у ноутбуков, как правило, нет com порта; конечно, если вы не носите с собой док-станцию). Этот конец называется DB-9. Другой конец вставляете в место для подключения к коммутатору через консоль. Где именно оно находится — сказать невозможно, это зависит от конкретной модели. Но, как правило, оно подписано соответствующим образом, и находится на задней панели коммутатора. Место для подключения консоли выглядит так же, как обычный 10mb/100mb порт на коммутаторе. Коннектор (т.е. наконечник) на другом конце консольного провода, как и коннектор для витой пары, называется RJ-45. Таким образом, читая документацию, вы можете увидеть такое определение: RJ-45 — to DB-9. Так иногда обозначают консольный провод. Подключение этого провода недолжно вызвать у вас каких либо затруднений, т.к. запутаться или вставить провод не туда практически невозможно.



Далее вам надо запустить терминал. Нажмите Пуск->Выполнить и напишите hypertrm (ОС Windows). В появившимся окне напишите любое имя соединения и нажмите Enter. Далее нажмите на кнопку «стандартные настройки» и выберите com порт, к которому подключили консольный провод. При этом коммутатор должен быть выключен. Если вы его не выключили, сделайте это сейчас. Затем нажмите кнопку ОК. И после чего включите питание коммутатора. Через несколько секунд вам на консоль начнёт выводиться информация о ходе загрузки операционной системы коммутатора. Но можно (а иногда и нужно) включить коммутатор без загрузки операционной системы, а войти в bootloader и загрузить систему вручную. Подробнее об этом читайте в пункте Установка ОС IOS. Теперь вам придётся немного подождать пока операционная система распакуется, flash память инициализируется и система загрузится. Затем на консоль выведется приглашение, после чего надо подождать ещё секунд 10 (зависит от модели коммутатора). И после всего этого вы наконец получаете консоль управления, в которой можете набирать команды, тем самым осуществляя настройку коммутатора. Функциональность коммутатора очень большая, и чем младше модель тем больше функциональность. Объяснение всех функций выходит за рамки этого файла помощи. Здесь вы можете научится использовать одну из самых главных функций коммутатора — настройка VLAN-ов. Подробнее читайте пункты VLAN-ы, теория и VLAN-ы, практика.



Возможно, процесс подключения может показаться вам долгим и неудобным, но на практике он занимает не более двух минут вместе с подсоединением консольного провода. После того, как вы выполните все выше написанные действия, первая команда, которую надо ввести коммутатору — enable. Эта команда дает вам права администратора коммутатора, и вам становится доступен полный набор команд, которыми надо производить настройку. Но, после набора команды enable коммутатор может спросить у вас пароль. Если вы не знаете пароль и вам не у кого его спросить, то пароль надо сбросить. В дальнейшем, так же как и пароль, можно сбросить и все настройки, если они были неудачными. Об этом вы можете подробнее прочитать в пункте Восстановление забытого пароля. Если настройки уже сброшены, то коммутатор, после загрузки ОС, задаст вам несколько вопросов, касающихся основных настроек. Если у вас не возникает сложности с чтением технической литературы на английском языке, то это не должно составить для вас проблему. Но замечу, что на второй вопрос, про managment надо ответить no.



Если же операционная система не загрузилась, вероятно, вам придётся её переустановить. Подробнее об этом читайте в пункте Установка ОС IOS. Но учтите, что не загрузиться без явных на то причин она не могла. Если вы не уверены в том, что делаете, то не стоит выполнять указания из пункта по установке ОС IOS. Всё таки лучше обратиться к специалисту, хотя бы для того, что бы выявить причину, по которой не загружается ОС. Такой случай можно считать экстренным. В переустановке ОС на коммутатор нет ничего сложного, но, повторюсь, что без явной на то причины ОС не могла выйти из стоя. Так же предупрежу вас, что существуют такие ситуации, после которых коммутатор невозможно починить в «домашних» условиях, и его придётся вести в сервис, внеся кругленькую сумму за ремонт. Если вы не уверены в том, что делаете, вы можете случайно ввести коммутатор в такое состояние.



Подключение через web интерфейс



Если коммутатор уже включён, вы можете подсоединиться к нему через web интерфейс. Для этого вам надо подключить ваш ПК или ноутбук к порту коммутатора обычной витой парой (пачкордом). Хотя это не всегда возможно, в зависимости от модели коммутатора, от его местонахождения и от имеющихся на нём настроек (web интерфейс может быть запрещён/отключён). Для подключения по web интерфейсу вам необходимо знать ip адрес коммутатора (точнее ip адрес, при обращении на который коммутатор выдаёт web интерфейс), и порт, на который надо подключиться.



Если вы этого не знаете, то вам надо загрузить коммутатор через com порт, как описано выше, удалить/переименовать файл конфигурации, если он есть, и пройти первичную настройку коммутатора, в ходе которой вам будет задан вопрос об ip адресе, заходя на который обычным броурезом с вашего ПК, вы получите web интерфейс коммутатора.



После того, как вы зайдёте на web интерфейс коммутатора, вы можете управлять им двумя способами. Первый: нажимать соответствующие кнопки, предоставляемые интерфейсом. Второй: обычным набором команд, вызвав через web интерфейс Telnet консоль.



Замечу, что некоторые версии операционной системы коммутатора работают не со всеми броузерами. Так же вам может потребоваться java2 sdk (jdk) определённой версии.



VLAN-ы, практика



Предполагается, что у вас уже есть доступ к веб интерфейсу или консоли телнета коммутатора. Настройка через графическую консоль осуществляется по разному, в зависимости от версии операционной системы. Но принцип всегда один и тот же. Здесь будет показан частный случай настройки VLAN через веб-интерфейс операционной системы IOS 12.1.



Настройка VLAN через веб-интерфейс



Внимание! При установке порта, через который вы управляете коммутатором, в не интерфейсный vlan (по умолчанию это vlan 1), соединение с коммутатором будет прервано. После входа на веб-интерфейс, нажмите на Smartports в меню интерфейса. Затем выберите порты, которые будут использоваться в работе и нажмите кнопку Customize, как показано на рисунке:





Затем напишите номер VLAN-а, которому должен принадлежать порт, и нажмите кнопку «done». Если такого VLAN-а не существует, он автоматически создастся, не задавая каких либо вопросов. К примеру, вы можете поставить порты 1, 2 и 3 в VLAN номер 1, а порты 18 и 20 в VLAN номер 37. Установите нужным портам нужный вам VLAN как показано на рисунке:





Затем нажмите кнопку «submit» (внизу страницы) для вступления изменений в силу.



Настройка VLAN через консоль




  • Войдите в привилегированный режим командой enable.

  • Войдите в базу данных vlan-ов: vlan database.

  • Командой ? вы можете посмотреть, какие команды можно делать в базе данных vlan-ов.

  • Командой vlan 200 вы создадите и активизируете новый vlan. 200 — это номер vlan-а. Здесь может быть любая цифра от 1 до 1005.

  • show покажет вам имеющиеся vlan-ы и информацию о них.

  • Команда no делает обратное действие команды, идущей после неё. Например, no vlan 200 удалит vlan с идентификационным номером 200.

  • Теперь пишем команду exit и выходим и базы данных vlan-ов. Теперь нам надо добавить нужный нам порт в нужный нам vlan.

  • Для этого войдите в режим конфигурации, командой configure. На вопрос, что конфигурировать, ответьте terminal.

  • Затем выберите нужный вам порт командой interface FastEthernet 0/17, где 17 — это номер порта.

  • Вы попадаете в режим конфигурации порта. Так же, что бы посмотреть свои возможности, наберите команду ?.

  • Для пролистывания вывода на строку нажимайте любую кнопку, на экран — пробел, прервать вывод списка информации на монитор — Ctrl + z или Ctrl + c.

  • Затем командой switchport access vlan 200 устанавливаем порт в нужный нам vlan. 200 — номер vlan-а.

  • После выхода из режима конфигурации, командой show vlan просмотрите результат проделанных действий.



Теперь можете подключить в соответствующие порты персональные компьютеры, и командой ping убедится, что они находятся поштучно в разных сетях, так, как вы настроили vlan.



Восстановление забытого пароля



Если вы не знаете пароль к коммутатору, то его нужно сбросить. Для этого выполните следующие действия:



Подключитесь к коммутатору через консоль. Как это сделать — подробно описано в пункте Подключение к коммутатору. Но на этот раз подключаться надо немного по-другому. Нам надо зайти в bootloader. Для этого, перед включением питания коммутатора, нажмите и удерживайте кнопку «mode» (кнопка на передней панели, слева, обычно подписана). Включайте питание удерживая это кнопку, и держите её до тех пор, пока вы не увидите на консоли приглашение bootloader-а. Это должно произойти через несколько секунд после включения питания.



От сюда вы можете управлять файлами во флеш памяти коммутатора. Но перед этим её надо инициализировать. Для этого наберите команду flash_init. После этого вы можете просматривать, копировать, удалять файлы и каталоги из памяти. Команды для этого почти такие же, как в операционной системе MS-DOC. Для того, что бы просмотреть содержимое флэш памяти, наберите команду dir flash: Замечу, что если в MS_DOC вы бы набирали «C:» или «D:», то тут надо набирать «flash:», т.е. знак "\" не нужен. После набора этой команды, вы должны увидеть примерно следующее:



Directory of flash:/
3 drwx 10176 Mar 01 2001 00:04:34 html
6 -rwx 2343 Mar 01 2001 03:18:16 config.text
171 -rwx 1667997 Mar 01 2001 00:02:39 c2950-i6q412-mz.121-9.EA1.bin
7 -rwx 3060 Mar 01 2001 00:14:20 vlan.dat
172 -rwx 100 Mar 01 2001 00:02:54 env_vars

7741440 bytes total (3884509 bytes free)


Здесь, html — это каталог, в котором находится web интерфейс. config.text — фийл, в котором хранятся все настройки коммутатора, в том числе и пароль. c2950-i6q412-mz.121-9.EA1.bin — операционная система коммутатора. Зависит от серии коммутатора. vlan.dat — здесь хранятся настройки vlan-ов. env_vars — файл с переменными окружения. Однажды, вам может понадобиться этот файл при установке операционной системы на отформатированную флэш-память коммутатора. Об этом читайте подробнее в пункте Установка ОС IOS.



Далее, переименуйте конфигурационный файл, если он вам понадобится в будущем, или, если настройки коммутатора не нужны, просто удалите его. Для переименования, команда, соответственно, такая: rename flash:config.text flash:config.text.old. Для удаления delete flash:config.text. Далее загружаем операционную систему либо выключением и повторным включением питания, либо командой reset либо командой boot. Последнее предпочтительнее.



После загрузки, операционная система задаст вам вопрос: «Continue with the configuration dialog? [yes/no]:». Если файл конфигурации вам не нужен, и на предыдущем шаге вы его удалили, то ответьте Y. И на этом можно закончить чтение этого пункта, поскольку в процессе предварительной настройки, коммутатор спросит вас, какой пароль установить. Если файл конфигурации содержит множество настроек, которые стабильно работали на производстве, и на предыдущем шаге вы его переименовали, ответьте N.



Далее, войдите в привилегированный режим командой enable. Пароль коммутатор спрашивать не будет. Затем переименуйте файл конфигурации обратно, командой rename flash:config.text.old flash:config.text. Теперь примените настройки из этого файла к текущей настройке коммутатора и установите новый пароль:



switch# copy flash:config.text system:running-config
Source filename [config.text]?
Destination filename [running-config]?

switch# config terminal
switch(config)# enable secret
switch(config)# enable password
switch(config)# exit
switch#

switch# copy running-config startup-config


Это всё. Теперь, при входе на коммутатор и вводе команды enable, правильным паролем будет являться тот, который вы ввели в место "" на предыдущем шаге.



Установка ОС IOS



Коммутаторы серии Cisco Catalyst и многие другие коммутаторы работают под управлением операционной системы IOS. Эта ОС представляет из себя один файл, размером 1,5 — 4,0 мегабайта, в зависимости от версии коммутатора. Каждая версия IOS предназначена лишь для одной серии коммутаторов. Серия коммутаторов может состоять из множества коммутаторов. Ниже изображено несколько коммутаторов серии Catalyst 2950:









Операционная система IOS для коммутаторов серии Cat2950 будет работать на всех изображённых коммутаторах. Но, хотя, в данной серии, есть исключение — это LRE (Long Reach Ethernet) коммутатор. Для него нужна другая версия IOS. Имена файлов операционных систем выглядят примерно так: c2950lre-i6k2l2q4-mz.121-22.EA7.bin. Это как раз IOS для последнего из изображённых коммутаторов. Как можно заметить, после цифр «2950» идут буквы «lre». Операционная система распространяется в виде бинарного файла и, в большинстве случаев, в виде *.tar архива. В архиве лежит этот же бинарный файл, а так же каталог html, в котором находится web интерфейс коммутатора. Операционная система должна прилагаться к коммутатору. Но если прилагаемый диск с ОС утерян, или вы хотите обновить ОС, то вам придётся её скачать. Скачать IOS для любого оборудования фирмы Cisco можно с их официального сайта (cisco.com), предварительно оплатив и составив договор с ними на сервисное обслуживание.



Установку IOS можно производить тремя способами: скопировать файл операционной системы через xmodem или через TFTP сервер. Третий способ — через web интерфейс. Но эта возможность не всегда имеется, и реализуется она каждый раз по разному, в зависимости от версии IOS. Поэтому рассмотрим только первые два способа.



Xmodem



Установку по протоколу xmodem надо осуществлять только в том случае, когда на коммутаторе операционная система либо стёрта либо повреждена. Время копирования IOS размером в 3 мегабайта во флэш память коммутатора — примерно один час. Для переустановки IOS по протоколу Xmodem вам надо подключиться к коммутатору через консоль, как описано в пункте Подключение к коммутатору и войти в bootloader, как описано в пункте Восстановление забытого пароля.



Далее, надо инициализировать флеш память командой flash_init. Затем просмотрите, что имеется в данный момент в памяти коммутатора: dir flash:. В конце списка файлов, находящихся в памяти, пишется размер памяти и имеющееся свободное пространство. Убедитесь, что вам хватит места, что бы закачать IOS. Если места нет — удалите *.tar и *.bin файлы командой delete flash:file_name.tar(bin). Так же можно отформатировать память командой format flash:.



После того, как пространство расчищено, можно приступать к копированию. Наберите команду copy xmodem: flash:file_name.bin и немедленно(!) отправьте нужный файл через терминал. Нажмите в меню терминала Передача->Отправить файл. В появившемся окне выберите xmodem, как показано на рисунке, и файл, который вы хотите передать:





Замечу, что если вы закачаете операционную систему в виде *.tar архива — это ни к чему не приведёт. Поскольку у bootloader-а отсутствуют функции разархивации.



После окончания копирования, перезагрузите коммутатор. Возможно, если вы форматировали флеш память, вам придётся создать файл env_vars, в котором нужно написать mac адрес вашего коммутатора. Для этого, внимательно просмотрите информацию, которую выдаёт bootloader при загрузке и найдите в ней mac адрес. Затем командой set MAC_ADDR xx:xx:xx:xx:xx:xx введите mac адрес в список переменных окружения, и затем наберите команду set_param. Флеш память при этом должна быть инициализирована. После этих действий должен создастся файл env_vars, что вы можете проверить командой dir flash:. Web интерфейс можно закачать только в виде *.tar архива, поскольку в каталоге html содержится огромное количество файлов. Это лучше сделать через TFTP, т.к. он в сотни раз быстрее.



TFTP



Установить IOS через TFTP можно только в том случае, если коммутатор в текущий момент находится в рабочем состоянии (т.е. IOS загружен), и вы находитесь в привилегированном режиме (команда enable). Для копирования файлов при помощи TFTP вам понадобится программа TFTPServer. Вы можете скачать её из интернета. Она занимает менее полутора мегабайт. Установите эту программу на свой компьютер и запустите. Не забудьте дать соответствующие указания вашему брендмаузеру, или отключите его на время копирования файлов. Скопируйте файлы, которые хотите передать, в каталог к TFTP серверу, или в любой другой каталог, предварительно указав это программе, как показано на картинке:





Вероятно, вам захочется использовать TFTP только для того, что бы закачать web интерфейс операционной системы. В таком случае в вашем *.tar арвите должен быть только каталог html. Саму ОС нужно удалить из архива. Что бы сделать это под windows, установите программу total commander. Это файловый менеджер, который поддерживает формат *.tar архива, т.е. позволяет просматривать архив, удалять/добавлять файлы и каталоги и многое другое.



Коммутатор должен быть включен, IOS загружен, Telnet консоль запущена. Наберите в консоли copy tftp: flash:, и ответьте на несколько вопросов, которые задаст вам коммутатор. После чего начнётся закачка. И, если в архиве находится только web интерфейс, он закачается примерно за 10-15 секунд. После чего вам надо разархивировать web интерфейс. Для этого наберите команду archive tar /xtract 1.tar flash:, где 1.tar — это закачавшийся архив.



Переустановка операционной системы IOS на коммутатор завершена.
Original source: habrahabr.ru.

https://habrahabr.ru/post/326584/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как на самом деле работает DNS?

Среда, 05 Апреля 2017 г. 14:37 (ссылка)

Проводя собеседования, постоянно сталкиваюсь с тем что соискатели знают о DNS только то что он превращает имена доменов (например google.com) в IP адреса (173.194.32.165). А как это происходит, мало кто может объяснить. Даже те кто может, допускают массу неточностей.



В этой заметке я не буду рассказывать о ресурсных записях, сосредоточимся на процессе — как из DNS выгребаем IP адрес для домена.




  1. Когда вводим адрес сайта в браузер, например habrahabr.ru, он пытается выяснить IP адрес домена, используя системный вызов getaddrinfo, gethostbyname или подобный.




  2. Сначала смотрим в файле hosts соответствие домена IP адресу. Это исторический момент, еще с тех пор когда не было DNS — соответствия доменов IP адресам закачивались с централизованного сервера. Удобно при переносе сайта на другой хостинг в файле hosts указать новый IP для домена и протестировать работу сайта на новой площадке. Файл hosts это НЕ часть DNS. Если DNS это человек, то файл hosts это хвост.




  3. Если в фале hosts соответствий нет, направляется рекурсивный запрос DNS серверу, еще такой сервер часто называют резолвер (resolver). DNS серверы всегда указываются при настройке сети. Вот у этих серверов мы и спрашиваем - какой IP адрес у домена habrahabr.ru? Отправляя рекурсивный запрос, мы говорим DNS-серверу что ждем от него IP адрес, либо ошибку.




  4. Если DNS-сервер ни чего не знает об этом домене, он спрашивает у root-серверов интернета - дайте мне информацию о зоне .ru! Стоп. Стоп. Что еще за root-серверы интернета?



    $ nslookup -q=ns .
    Server: 8.8.8.8
    Address: 8.8.8.8#53

    Non-authoritative answer:
    . nameserver = a.root-servers.net.
    . nameserver = b.root-servers.net.
    . nameserver = c.root-servers.net.
    . nameserver = d.root-servers.net.
    . nameserver = e.root-servers.net.
    . nameserver = f.root-servers.net.
    . nameserver = g.root-servers.net.
    . nameserver = h.root-servers.net.
    . nameserver = i.root-servers.net.
    . nameserver = j.root-servers.net.
    . nameserver = k.root-servers.net.
    . nameserver = l.root-servers.net.
    . nameserver = m.root-servers.net.


    Эти рутовые серверы и их IP хранятся в специальном кеше, который ставится вместе с установкой, например, bind. Секция zone "." в файле named.conf, можно проверить у себя.




  5. Каждый root-сервер хранит информацию обо всех Top Level Domains (TLD), таких как .ru, .com и тд. Рутовый сервер ответил, что информацию о доменах в зоне .ru можно спросить у TLD DNS серверов, т.е. у серверов, которые обслуживают эту зону:



    $ nslookup -q=ns ru. a.root-servers.net.
    Server: a.root-servers.net.
    Address: 198.41.0.4#53

    Authoritative answers can be found from:
    ru nameserver = a.dns.ripn.net.
    ru nameserver = e.dns.ripn.net.
    ru nameserver = f.dns.ripn.net.
    ru nameserver = d.dns.ripn.net.
    ru nameserver = b.dns.ripn.net.
    a.dns.ripn.net internet address = 193.232.128.6
    a.dns.ripn.net has AAAA address 2001:678:17::193:232:128:6
    e.dns.ripn.net internet address = 193.232.142.17
    e.dns.ripn.net has AAAA address 2001:678:15::193:232:142:17
    f.dns.ripn.net internet address = 193.232.156.17
    f.dns.ripn.net has AAAA address 2001:678:14::193:232:156:17
    d.dns.ripn.net internet address = 194.190.124.17
    d.dns.ripn.net has AAAA address 2001:678:18::194:190:124:17
    b.dns.ripn.net internet address = 194.85.252.62
    b.dns.ripn.net has AAAA address 2001:678:16::194:85:252:62



  6. Каждый из TLD DNS знает где дальше искать информацию о домене второго уровня, в нашем случае habrahabr.ru. Серверы имен для домена настраиваются у регистратора домена, собственно, это позволяет делегировать домен, т.е. передавать управление зоной серверам имен. TLD DNS возвращает серверы имен для нашего домена, которые уже знают IP:



    $ nslookup -q=ns habrahabr.ru. a.dns.ripn.net.
    Server: a.dns.ripn.net.
    Address: 193.232.128.6#53

    Authoritative answers can be found from:
    HABRAHABR.RU nameserver = ns3.habradns.net.
    HABRAHABR.RU nameserver = ns1.habradns.net.
    HABRAHABR.RU nameserver = ns2.habradns.net.



  7. Так были найдены серверы имен для домена, которые вернут IP адрес. IP возвращается резолвером. Теперь браузер может установить соединение.



    $ nslookup -q=a habrahabr.ru. ns1.habradns.net.
    Server: ns1.habradns.net.
    Address: 88.198.175.104#53

    Name: habrahabr.ru
    Address: 178.248.237.68



Спасибо за внимание!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/325742/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Zabbix Moscow Meetup в офисе Badoo 15 апреля

Вторник, 04 Апреля 2017 г. 16:16 (ссылка)

enter image description here



Привет! Объявляем регистрацию на митап открытой. Мы в очередной раз принимаем в нашем офисе сообщество Zabbix. Ниже – описание выступлений. Начало мероприятия в 12:00.



Программа



11:00 – Начало регистрации (приходите, чтобы успеть выпить кофе и занять лучшие места)



12:00 – 12:45 – Алексей Владышев, Zabbix

12:45 – 13:00 – Вопросы

13:05 – 13:50 – Илья Аблеев, Badoo

13:50 – 14:05 – Вопросы



14:10 – 14:45 – Перерыв на обед и экскурсии в офис Badoo



14:50 – 15:35 – Александр Зобнин, Grafana Labs

15:35 – 15:50 – Вопросы

15:55 – 16:30 – Андрей Денисов

16:30 – 16:45 – Вопросы



16:45 – 17:15 – Свободное общение



Спикеры и темы выступлений



Алексей Владышев, Zabbix



enter image description here



Тема: Zabbix: над чем мы работаем?



Я поделюсь своими мыслями о направлении развития Zabbix. Расскажу о том, что уже удалось реализовать для версии 3.4, что осталось сделать и когда это будет готово.




  • Узнаете о том, будет ли в 3.4 NoSQL бэкенд. А если будет, то какой?

  • Узнаете, как управлять пользователями и их правами доступа, не прикасаясь к Zabbix.

  • Как одним-двумя кликами мышки управлять периодичностью сбора миллионов метрик?



И многое другое, нам есть о чём поговорить. И, конечно же, я постараюсь ответить на все вопросы участников митапа. Приходите, будет много интересной информации. Скучать не придётся!



Илья Аблеев, Badoo



enter image description here



Тема: Zabbix в Badoo: реагируем быстро и качественно



В условиях большой инфраструктуры и немалого количества критичных компонентов, время реакции на инцидент должно быть как можно меньше. В докладе я расскажу, какие инструменты помогают увеличить скорость реакции и уведомить о проблеме качественнее.




  1. Инфраструктура / специфика компании и отдела эксплуатации

  2. Для чего нам нужен Zabbix

  3. Флоу работы отдела мониторинга

  4. С помощью чего повышаем скорость / качество работы

    4.1. Триггеры в консоли

    4.2. Уведомления на десктопе

    4.3. Zabbix в Telegram



Александр Зобнин, Grafana Labs



enter image description here



Тема: Как перестать бороться с графиками и начать жить



Я расскажу вам про интеграцию Zabbix и Grafana, чтобы вы могли улучшить возможности визуализации данных мониторинга с помощью Grafana.




  1. Зачем нужны графики?

  2. Как нарисовать 100 графиков за 10 секунд? (Query Editor, Regex, Templating)

  3. И что потом с этим делать? ( Max Data Points, Functions, Performance)

  4. События – это тоже Time Series (Annotations)

  5. Seek & Destroy (Alerting в Grafana)

  6. Бонус: Heatmap



Ссылки на проект: 1 и 2.



Андрей Денисов, IT-специалист в телекоммуникационной компании



enter image description here



Тема: В ожидании мониторинга баз данных



Вероятно, многие пробовали использовать решение Zabbix для мониторинга баз данных. Из моего доклада вы узнаете о нашем опыте его применения, и к чему мы в итоге пришли.




  1. Штатный Zabbix-мониторинг баз данных: особенности реализации/настройки в промышленных масштабах

  2. Преимущества/недостатки решения мониторинга баз данных от Zabbix SIA

  3. Преимущества/недостатки существующих расширений Zabbix для мониторинга баз данных

  4. Подробнее о расширении DBforBix v2.3 beta: конфигурирование, возможности

  5. Доработка DBforBix: сохраняем преимущества и устраняем недостатки штатного мониторинга баз данных Zabbix

  6. Варианты развития идеи



Регистрироваться на митап – здесь: ссылка.

(пишите ваши фамилии и имена кириллицей, пожалуйста).



Адрес: Москва, Цветной бульвар, 2, БЦ «Легенда Цветного», подъезд А. Метро: Трубная/Цветной бульвар. Захватите с собой какой-нибудь удостоверящий личность документ.


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/325652/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Настройка репликации во FreeIPA 4.4 с domain level 1

Понедельник, 03 Апреля 2017 г. 18:26 (ссылка)

image



У нас в компании для организации и управления доступами для Linux-серверов

используется такой сервис как FreeIPA. FreeIPA — это вполне полноценная замена AD для Linux-систем от RHEL. В новой версии появились уровни доменов и был переработан процесс настройки репликации. Так как инструкций вменяемого вида в рунете найти не удалось, я решил написать собственную.



Для начала нам понадобится два сервера с CentOS 7.



ipamaster.org.lan  	ip 192.168.10.23
ipareplica0.org.lan ip 192.168.10.123


На каждом сервере вносим в /etc/hosts адреса мастера и реплики.



192.168.10.23	ipamaster.org.lan
192.168.10.213 ipareplica0.org.lan


Дальше на мастере устанавливаем необходимые пакеты. В нашем случае мы используем сервера FreeIPA как DNS-сервера. Поэтому устанавливем и пакет DNS-сервера:



yum -y install ipa-server bind bind-dyndb-ldap ipa-server-dns


После установки пакетов необходимо установить сам сервер FreeIPA. Для автоматизации установки ipa-server-install поддерживает множество ключей, которые позволяют в автоматическом режиме ответить на все вопросы инсталлятора. Мы же в данный момент пройдёмся руками по каждому полю с описанием. Так же ничего не мешает выполнить ipa-server-install -h и составить нужный набор ключей.



Итак установка сервера:



ipa-server-install --setup-dns --mkhomedir


Ключ --setup-dns говорит о том, что мы будем использовать DNS-сервер; ключ --mkhomedir нужен, чтобы на клиентах для каждого пользователя автоматически создавалась home директория.



Далее отвечаем на вопросы.



1. Имя хоста должно быть прописано в хост и резолвится. Оставляем как есть.



Server host name [ipamaster.org.lan]:


2. Доменное имя тоже оставляем как есть.



Please confirm the domain name [org.lan]:


3. Realm name тоже без изменений.



Please provide a realm name [org.lan]:


4. Пароль для менеджмента лдап-директорий нужен сложный. И не потерять.



Directory Manager password: q1w2e3r4t5y6
Password (confirm): q1w2e3r4t5y6


5. Пароль администратора самого сервиса.



IPA admin password: 1234567890


6. Указываем dns forwarders, к примеру, на гугловые сервера. Чтобы закончить указывать форвардеры, достаточно в пустой строке нажать ENTER.



Do you want to configure DNS forwarders? [yes]:
Do you want to configure these servers as DNS forwarders? [yes]:
All DNS servers from /etc/resolv.conf were added. You can enter additional addresses now:
Enter an IP address for a DNS forwarder, or press Enter to skip: 8.8.8.8
DNS forwarder 8.8.8.8 added. You may add another.
Enter an IP address for a DNS forwarder, or press Enter to skip: 8.8.4.4
DNS forwarder 8.8.4.4 added. You may add another.
Enter an IP address for a DNS forwarder, or press Enter to skip:
Checking DNS forwarders, please wait…


7. Разрешаем реверс зону.



Do you want to search for missing reverse zones? [yes]:
Do you want to create reverse zone for IP 192.168.10.23 [yes]:
Please specify the reverse zone name [10.168.192.in-addr.arpa.]:
Using reverse zone(s) 10.168.192.in-addr.arpa.


8. Дальше нам выводят данные для проверки. Проверяем, продолжаем.



The IPA Master Server will be configured with:
Hostname: ipamaster.org.lan
IP address(es): 192.168.10.23
Domain name: org.lan
Realm name: ORG.LAN

BIND DNS server will be configured to serve IPA domain with:
Forwarders: 8.8.8.8, 8.8.4.4
Forward policy: only
Reverse zone(s): 10.168.192.in-addr.arpa.
Continue to configure the system with these values? [no]: yes


Начинается довольно долгий процесс установки. Одна из самых долгих частей это генерация сертификатов, так что можно сходить попить чаю.



В финале установки нам покажут какие порты используются. Настраиваем фаерволл, чтобы он принимал соединения на этих портах. В нашем случае тестовое окружение и все друг другу доверяют.



1. You must make sure these network ports are open:
TCP Ports:
* 80, 443: HTTP/HTTPS
* 389, 636: LDAP/LDAPS
* 88, 464: kerberos
* 53: bind
UDP Ports:
* 88, 464: kerberos
* 53: bind
* 123: ntp


Можем зайти в веб-интерфейс, проверить работу.



image



Убедились, что всё работает. Теперь переходим к повышению уровня домена. Нам необходимо пройти по вкладкам IPA SERVERS -> Topology. Где нас сразу предупреждают, что СА-серверов должно быть больше одного.



image



Отвечаем ОК. И проверяем уровень домена на вкладке Domain Level. Если это свежая установка, он по умолчанию будет 1.



ВНИМАНИЕ! Если вы это делаете на проде, то повышение уровня домена без предварительной подготовки может всё сломать. Делайте это только в том случае, когда понимаете зачем и как.



После этих операций переходим к настройки реплики. И вот тут начинаются отличия от старых механизмов. Если раньше нужно было генерировать ключи, переносить на реплику и делать множество телодвижений, то теперь всё значительно проще.



Итак проверяем что реплика берёт днсы с мастера.



cat  /etc/resolv.conf
search org.lan
nameserver 192.168.10.23


Теперь устанавливаем ipa-client.



yum -y install ipa-client ipa-server-dns


После этого устанавливаем и настраиваем клиента. Тут такая же история как с сервером — есть куча ключей для автоматизации, поэтому выполняем.



/usr/sbin/ipa-client-install -d --mkhomedir --domain=org.lan --server=ipamaster.org.lan --realm=ORG.LAN --principal=admin --password=1234567890  --enable-dns-updates -U


После этого хост должен появиться в веб-интерфейсе.



image

Дальше переходим к настройке репликации. Выполняем.



Ipa-replica-install


У нас попросят пароль админа. Вводим, жмем ENTER.



WARNING: conflicting time&date synchronization service 'chronyd' will be disabled in favor of ntpd

Password for admin@ORG.LAN:


Далее дожидаемся установки и настройки репликации. После завершения можно зайти на ipareplica0.org.lan там в IPA SERVERS -> Topology -> Topology Graph мы увидим, что реплика появилась и реплицируется только доменная часть.



image



Но мы также помним про назойливое упоминание, что СА-сервер один и что нам нужен резервный днс. Переходим к настройке днс-сервера на реплике.



Ipa-dns-install


И по аналогии с мастером разрешаем форвардеров. Если вдруг наша реплика находится в другом регионе, можно указать другие форвардеры.



После этого переходим к установке СА сервера.



Ipa-ca-install


Тут у нас спросят наш Directory Manager password. Вы ведь его ещё не потеряли?



Directory Manager (existing master) password: q1w2e3r4t5y6


Это займет довольно много времени, поэтому ждём. После завершения идём на любой веб-интерфейс и проверяем топологию. Пропало назойливое сообщение о том, что СА в единственном экземпляре. И появилась новая связь в графике топологий.



image



Как видим, теперь всё относительно отказоустойчиво. Масштабирование в новой версии стало гораздо более простым и понятным.



Теперь пару слов о том, что стоит не забывать мониторить. Мы мониторим запущенные процессы, открытые порты и самое главное мониторим срок действия корневого СА-сертификата. Потому как в случае, если он прострочится, может возникнуть куча ручной волокиты которая никому не нужна.



Ну и ссылки на официальную документацию:



www.freeipa.org/page/V4_Designs

www.freeipa.org/page/V4_Proposals
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/325546/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Хороший триггер, плохой триггер: как мы мониторим сотни серверов по всему миру

Вторник, 28 Марта 2017 г. 16:02 (ссылка)

image



Необходимость мониторинга должна быть очевидна практически для любой компании, однако я не раз сталкивался с примерами, когда к такому выводу ребята приходили только после падения продакшна. Причем нередко команда узнавала об этом уже постфактум — от своего генерального директора, которому на недоступность проекта пожаловались его друзья, решившие вдруг взглянуть на стартап. И вот он в гневе звонит членам команды с вопросом даже не «почему все упало», а почему он об этом знает, а они — нет. И тут им в голову приходит мысль, а почему бы не настроить мониторинг? Казалось бы, что может быть проще…



Нам, например, круглосуточно требуется мониторить более 46 000 метрик на более чем 500 серверах в 6 дата-центрах и 4 странах, а DAU игры War Robots стабильно переваливает за 1 500 000 человек.



Но правильный, настоящий мониторинг пишется кровью системного администратора и разработчика. Каждый кейс, каждый факап и даже внутренние процессы, включая количества тонера в картридже принтера, должны быть описаны сценарием мониторинга. Я решил немного рассказать о том, с чем мы столкнулись при организации этого процесса, а также как выстроили работу сисадминов, снизив количество дежурств и улучшив их качество. При этом упор будет сделан на подходе к мониторингу, тогда как настройка той или иной системы легко гуглится и без посторонней помощи.



Для начала несколько кейсов из прошлого. Помню был случай, когда какой-то Java-процесс по API отдавал 200 и пустое тело. Процесс висел, порт был открыт и соединения телнетом принимал. Но при этом любой http-запрос от внутренних сервисов к API тоже отдавал 200 и пустое тело. И казалось бы — сервис есть, порт отвечает, а данных не отдаёт. Поэтому мы теперь везде, где возможно, проверяем особый URL, который не нагружает сервис, но привязан к его работе и в случае, если всё хорошо, отдаёт 200, а в теле — результат работы. Ошибкой в нашем случае будет либо ответ, отличный от 200, либо любое несоответствие ожидаемому формату.



В другой раз проблема была со связанностью нод в кластере, когда одна нода могла не видеть кого-то из кластера, а все остальные считали, что всё в порядке. Разработчики базы данных тогда объяснили у себя это багом. Но нам от этого легче не стало и результатом приобретенного опыта стало добавление новых мониторинг-метрик. С каждого узла кластера мы стали собирать данные о количестве узлов в состоянии DOWN. И в случае, если это значение больше 0, — на конкретном хосте выполняется скрипт, который в отдельную метрику записывает адрес хоста, с которым пропала связанность.



Также после определенной ситуации мы стали мониторить DNS-резолвы с сервера на сервер. Это был случай, когда в игре возникли проблемы, но мониторинг сработал только на следствие. Чтобы разобраться в причинах, пришлось немного покопаться. Как выяснилось в итоге, часть хостов начали неправильно разрешать некоторые наши DNS-имена. Поэтому сейчас у нас есть специальный механизм, который проверяет разрешение имен. В случае проблемы срабатывает триггер и затем все критически важные имена заносятся в hosts-файл. Это позволяет получить минимальный даун тайм и возможность спокойно разобраться в причинах проблемы.



Инструменты





Чем именно мониторить — вопрос важный и очень хороший. Когда-то у нас замечательно справлялись несколько Nagios-серверов на стеке thruk + nconf + munin. Но когда сервера начали добавляться по 50 штук в месяц, а сервисы по 300 в неделю — нагиосы и мунины перестали справляться с нагрузкой и отвечать нашим представлениям об автоматизации.



В итоге, как бы не было больно, нам пришлось переезжать на Zabbix. И дело тут не только в разности подходов Zabbix и Nagios, но и в огромном количестве кастомных метрик, которые нам пришлось переписывать. А также в отсутствии возможности проверить самые критические части в боевых условиях на Заббиксе, ведь мы не стали бы вызывать их искусственно.



Зато переезд дал нам единый интерфейс конфигурации и управления, API для регистрации серверов и присвоения им в автоматическом режиме темплейта, графики из коробки, более продвинутую систему Zabbix Proxy и, если нам совсем уж чего-то не хватало — можно было использовать Zabbix Sender.



В идеале новый сервер должен автоматически регистрироваться в системе мониторинга и на него, исходя из его hostname, присваиваться соответствующий шаблон (пример «хорошего» хостнейма: web1.ios.ru.prod.example.com). Добавление пачки серверов тоже не должно быть головной болью.



В нашем случае существует полная корреляция между всеми группами хостов во всех системах инфраструктуры. Мы добавляем сервера специально написанной ролью Ansible, которая вызовом API Zabbix добавляет хост в заббикс. Потом присваивает ему хост-группу и темплейт согласно его группе во FreeIPA и Ansiblе. Однако вопросы автоматизации — тема отдельной большой статьи.



Помимо заббикса у нас также трудится амазоновский CloudWatch, остатки нагиоса и еще пара вещей.



Как аккумулировать все уведомления в одном месте, чтобы не бегать по пяти разным статус страницам? Для нас откровением стал PagerDuty — в нем мы настроили график дежурств и эскалационные политики. Для отправки данных в PD мы использовали стандартные модули для Zabbix и CloudWatch, а также написали свои модули для отправки необходимых нам данных, остатков нагиоса и нескольких специфических мест. Очень порадовал их API — он целиком покрывает все стандартные требования.



Также неплохо себя показала Grafana, дополнительно прикрученная к стандартным заббиксовым графикам.



image



Хороший триггер, плохой триггер





Отдельно хочется отметить, что не стоит увлекаться и слать уведомления по каждому существующему триггеру, если вы не хотите постоянно просыпаться из-за «ложных» срабатываний. В исключительных случаях, если вы знаете, что сервис может выдавать одну ошибку в час и это для вас является нормой, то можно агрегировать ошибки за дельту времени. Таким образом можно минимизировать ложные срабатывания системы мониторинга, отсылая уведомление о проблеме, например, только в случае возникновения трех и более ошибок в течение 15 минут.



Тем не менее ничего не должно ускользнуть от всевидящего ока мониторинга.



Мониторить требуется и показатели софта, и процессы взаимодействия между сервисами — например, коннект к базе данных не с сервера базы данных, а с сервера приложения, который непосредственно этим коннектом пользуется.



Если у вас есть хардварный рейд — ставьте CLI-утилиты и добавляйте в мониторинг состояние вашего RAID-массива. Если вы знаете критическое (для пользователя) время загрузки страницы и ее размер — мониторьте и это. Если у вас свой внутренний протокол — требуйте от разработчиков дать вам Status Page (и всегда требуйте разъяснений за каждую метрику, лучше — с описанием в wiki проекта) или предоставить инструментарий для самостоятельных тестов закрытого протокола внутренней разработки.



Плохая, непонятная метрика: All systems state — OK.

Хорошая метрика: Server to server query time — OK (under 2 sec).



Также хочется вспомнить про типы уведомлений info, warn и crit. Вы можете описать все, что хотите, триггером info — будете получать по этой метрике статистику, видеть график и, возможно, в какой-то момент поймете, что вам требуется добавить на эту метрику трешхолд на warn и crit. Или сможете определить в ретроспективе, когда у вас начали расти показатели по этой метрике. Но значения warn и crit должны быть для вас очень прозрачны и понятны. По сути, каждое их ложное срабатывание — это потеря 15 минут времени.



Как не доводить проблему до абсурда





Важно понимать так же не только, по каким критериям мы шлем нотификации, но и кому. Это могут быть разные линии тех поддержки или разработчики и админы. В некоторых особо критичных случаях можно даже генеральному директору прислать уведомление, но, конечно же, не стоит до этого доводить.



Раньше у нас дежурили по два админа каждые две ночи. В результате четыре человека стабильно не высыпались, а качество как работы, так и дежурств постепенно падало. Грамотное построение эскалационной политики позволило не только улучшить качество работы, но и снизить количество дежурств и сверхурочных часов дежурных сисадминов.



Сейчас каждый админ дежурит сутки через трое. В целом эскалационная политика в нашем случае выглядит следующим образом:




  1. при срабатывании триггера дежурному админу отправляются оповещения: на почту и через PagerDuty — в Slack, смской, push-уведомлением и звоноком от робота;

  2. в случае отсутствия реакции через 30 минут проблема эскалируется на всю команду всеми доступными способами нотификации;

  3. если вся команда не отвечает в течение 20 минут — эскалация происходит на начальника отдела;

  4. если и он подзабил на звонок от системы — через 10 минут звоним техническому директору.



Справедливости ради стоит отметить, что дальше второго шага у нас ни разу не доходило.



image



При этом у нас всего 2 серверных админа, а 2 хелпдеска достаточно квалифицированы, чтобы решить простейшие проблемы, которые могут возникать с серверной инфраструктурой — например, рестартануть/ребутнуть сервер или выполнить трейсы и составить тикет в дата-центр.



Мониторинг на опережение





Пару слов о превентивной настройке мониторинга ключевых нововведений.



Еще до релиза каждой новой фичи, разработчики подготавливают и передают нашему отделу документацию по критическим метрикам, требующим внимания со стороны мониторинга. На основании этих данных настраиваются информационные метрики для определения дальнейших боевых (продакшн) метрик.



Документация в обязательном порядке содержит в себе, что означает каждая метрика, как она влияет на соседние параметры и порядок действий в случае нотификации по пороговому значению. Например, перед введением клановых сервисов была добавлена метрика процента фейлов при запросах к ним.

Уроки географии



К вопросу географического расположения сервера мониторинга требуется подходить очень осознанно. Яркий пример того, как делать НЕ надо (но многие продолжают совершать эту ошибку), — располагать сервер мониторинга в том же дата-центре, где и сервера, которые он будет отслеживать. В этом случае, если в даун уходит весь дц, вы снова узнаете об этом только от своего генерального директора.



Ещё одна распространённая ошибка: размещать мониторинг в той же стране что и сервера, если основной доход приносят пользователи другой страны. При таком сценарии мониторинг, располагающийся, например, в Берлине, будет показывать, что в Германии все хорошо, в то время как пользователи из США будут испытывать сетевые задержки в случае просадки производительности международных коммуникаций тех сетей, что у вас используются. Но вы об этом опять же ничего не узнаете и на стендапе с утра на вопрос, почему вчера на графиках просели платежи и все ли было хорошо с серверами, будете уныло разводить руками.



Если говорить более конкретно, то у нас имеется центральный сервер, к которому подключаются отдельные прокси, находящиеся в конкретном регионе. Каждый прокси собирает данные и отправляет их центральному серверу. Мониторинг важных и географически зависимых сервисов осуществляется либо кастомными юзерпараметрами с каждого заинтересованного хоста, либо с каждого прокси-сервера. Это и даёт нам чёткое понимание географических проблем.



Мониторинг мониторинга и не только





Но не следует ограничиваться мониторингом исключительно внешних вещей. Мониторинг внутренних процессов так же важен. Независимо от того, говорим ли мы о количестве тонера в картридже принтера или о количестве зарегистрированных (билд) агентов в вашей системе CI/CD. Каждый допущенный факап внутренней инфраструктуры ведет к парализации работы того или иного отдела.



Мониторить также полезно количество Wi-Fi клиентов, подключенных к точке доступа, загруженность основного и резервного каналов офисного интернета. Например, у нас более 300 Wi-Fi устройств, одновременно подключенных в корпоративную сеть и генерирующих трафик. И без мониторинга было бы очень тяжело заранее ставить дополнительные точки доступа там, где это необходимо.



Мониторинг Wi-Fi точек, в частности, однажды помог нам решить проблему с тестированием игры. Отдел QA стал жаловаться на высокий пинг в игре и именно мониторинг позволил выяснить, что большинство тестировщиков, по определенным причинам, подключались к одной и той же точке Wi-Fi, в то время как остальные точки оставались свободными.



Тестовые и стейджинговые сервера должны быть покрыты мониторингом не в меньшей степени чем продакшн. Наши разработчики всегда сверяют графики мониторинга до и после релиза новых фич, различных маркетинговых компаний и их эффекта на общую нагрузку системы.



Ну и конечно же не будем забывать про мониторинг мониторинга. В случае падения сервера мониторинга не исключены форс-мажорные ситуации, о которых вы не знаете, потому что сервер мониторинга недоступен. В нашем случае есть специально написанный сервис, который независимо от основного заббикса проверят состояние и доступность заббикс-серверов и заббикс-прокси.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/325040/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Немного о приватности реальных Git-репозиториев

Вторник, 22 Марта 2017 г. 01:23 (ссылка)

https://habrahabr.ru/post/324530/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Немного о приватности реальных Git-репозиториев

Вторник, 22 Марта 2017 г. 01:23 (ссылка)

https://habrahabr.ru/post/324530/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Простой, надёжный и удобный мониторинг серверов на Linux

Пятница, 17 Марта 2017 г. 13:03 (ссылка)

Если вы администрируете сервера на Linux, наверняка, вы находитесь в состоянии постоянного поиска простых, надежных и удобных инструментов для решения самых разных задач. Одна из них — наблюдение за состоянием машин. И, хотя инструментов для мониторинга предостаточно, найти то, что войдёт в повседневный набор программ, обычно не так уж и просто. Именно поэтому сегодня я хочу рассказать об одной из таких находок, об утилите, которой пользуюсь каждый день.







Программа, о которой пойдёт речь, называется Nigel’s Monitor, или просто nmon. Она, используя простой интерфейс ncurses, умеет выводить, в реальном времени, сведения о различных показателях, характеризующих состояние сервера. Среди них — данные по процессору и памяти, информация о сетевых ресурсах, о дисковых накопителях, о файловой системе и NFS, о процессах. Набор отображаемых показателей можно настраивать. Nmon имеет текстовый интерфейс, поэтому, для работы с ним достаточно подключиться к серверу по SSH.



Предлагаю установить nmon и поговорить о том, как им пользоваться.



Установка



Утилиту nmon можно установить из стандартных репозиториев дистрибутивов серверных ОС. То есть, вы вряд ли столкнётесь с какими-то сложностями. Если ваша система использует apt (это — Debian, Ubuntu, и другие), надо выполнить в терминале такие команды:



sudo apt-get update
sudo apt-get install nmon


Для дистрибутивов, использующих dnf (среди них — Red Hat, Fedora, CentOS), установка будет выглядеть так:



dnf install epel-release
dnf install nmon


Как видите, всё просто. Переходим к работе с nmon.



Работа с nmon



Итак, nmon установлен, теперь можно его запустить, выполнив команду nmon. В окне утилиты, показанном на рисунке ниже, надо указать, какие именно сведения вас интересуют, включая и отключая соответствующие информационные разделы.





Главное окно nmon содержит подсказки по включению и отключению различных разделов сведений о системе



Скажем, вас интересуют дисковые накопители. Если нажать клавишу d на клавиатуре, nmon выведет данные обо всех подключённых к серверу дисках.





Средство мониторинга nmon выводит данные о дисках



Далее, добавим информационные разделы со сведениями о сети и памяти, нажав клавиши n и m. В итоге, набор данные о системе будет дополнен интересующими нас показателями.





Добавление в окно мониторинга сведений о сетевой подсистеме и памяти



Выключить отображение тех или иных разделов можно с помощью тех же клавиш, которые использовались для их вывода на экран. Кроме того, nmon поддерживает возможность менять скорость обновления данных. Делается это с помощью клавиш «-» и «+» на клавиатуре. Первая, соответственно, уменьшает скорость обновления показателей, вторая — увеличивает.



Для того, чтобы выйти из nmon, нажмите клавишу q, это возвратит вас к обычному приглашению bash.



Сбор данных с помощью nmon



Инструмент включает в себя возможность захвата данных и сохранения их в файл. Это может оказаться очень кстати, если нужно проанализировать данные о состоянии системы на некоем отрезке времени.



Предположим, требуется 30 «снимков» состояния системы, делать которые надо каждые 60 секунд. Организовать подобное можно, воспользовавшись такой командой:



nmon -f -s 60 -c 30


Здесь ключ -f указывает на то, что данные надо писать в файл, ключ -s задаёт промежутки времени, в секундах, между «снимками», а ключ -c говорит программе о том, что нам надо 30 наборов показателей.



Через полчаса после выполнения вышеописанной команды в текущей рабочей директории окажется интересующий нас файл с расширением .nmon.



Проанализировать этот файл можно, например, с помощью утилиты nmonchart, которая создаст из него веб-страницу, содержащую симпатичные графики.





Анализ данных, собранных nmon, с помощью nmonchart



Планирование сбора данных



Если необходимо организовать регулярный сбор данных о показателях работы сервера, например, для выявления периодически возникающих неполадок, можно воспользоваться заданиями cron. Делается это так. Сначала создадим bash-скрипт, скажем, с именем nmon.sh, с таким вот содержимым:



#! /bin/sh
nmon -f -s 60 -c 30


Файл надо сохранить и дать ему разрешение на исполнение с помощью команды chmod u+x nmon.sh. Теперь откроем файл crontab для редактирования командой crontab -e и введём следующее:



30 11 * * * ~/nmon.sh


После сохранения изменений, задание cron будет выполняться ежедневно, в 11:30 утра. Вы, конечно, подставите сюда то время, которое вам нужно, получив в своё распоряжение удобный инструмент для выявления причин неполадок серверов.



Итоги: действительно просто и по-настоящему полезно



Уверен, вам нелегко будет найти более простое и удобное решение для мониторинга Linux-серверов, подходящее для наблюдения за системами в реальном времени и для сбора данных, которые планируется проанализировать позже.



Пожалуй, nmon — это, так сказать, мастхэв для каждого системного администратора.



Уважаемые читатели! А какими утилитами для администрирования Linux вы пользуетесь постоянно и можете порекомендовать их другим?
Original source: habrahabr.ru.

https://habrahabr.ru/post/324194/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Превращаем Ubuntu Server в контроллер домена с помощью samba-tool

Вторник, 14 Марта 2017 г. 11:16 (ссылка)

Как быть, если и контроллер домена нужен, и сэкономить хочется? Сегодня мы представим вашему вниманию один из ответов на этот вопрос. Речь пойдёт о пакете Samba, об Ubuntu Server, и о том, как всё это быстро и правильно настроить.



С помощью Samba можно превратить сервер, работающий под управлением ОС семейства Linux, в контроллер домена (Domain Controller, DC) Active Directory. Тот DC, который мы собираемся поднять, сможет работать как контроллер домена Windows NT4. Он подойдёт для централизованного хранения данных учётных записей пользователей и компьютеров.



Надо отметить, что мы не будем говорить о задаче создания основного контроллера домена (Primary Domain Controller, PDC) Active Directory, хотя связка Ubuntu Server/Samba, рассмотренная здесь (с добавлением OpenLDAP) вполне может играть и такую роль.



Итак, наша цель — быстро и экономично обзавестись AD DC. В этом нам поможет интерактивный инструмент samba-tool, который предназначен для автоматизированной подготовки сервера к работе, а именно, он позволяет сформировать файл настроек /etc/smb.conf.



Начнём с установки необходимого ПО.



Установка



Первый шаг — установка на сервер пакетов Samba и Winbind. Сделать это можно с помощью следующей команды:



sudo apt install samba libpam-winbind


Время установки невелико, даже с учётом того, что системе может понадобиться загрузить некоторые зависимости.



После установки можно приступать к настройкам.



Подготовка к настройке



Перед запуском samba-tool нужно проверить файл /etc/hosts, а именно — верны ли записанные в нём полное доменное имя и IP-адрес контроллера домена. Там можно найти что-то вроде этого:



127.0.0.1 localhost.localdomain 
IP_ADDRESS_OF_SERVER localhost
IP_ADDRESS_OF_SERVER SAMBADOM.EXAMPLE.NET
SAMBADOM


Здесь IP_ADDRESS_OF_SERVER — это реальный адрес сервера Samba. Проверьте, чтобы файл содержал актуальные данные.



Далее нужно задать имя узла для сервера. Как можно судить по приведённому выше фрагменту файла /etc/hosts, в нашем случае имя узла — SAMBADOM. Для того, чтобы его настроить, откройте файл /etc/hostname и соответствующим образом его измените. Далее — перезагрузите сервер.



После того, как сервер перезагрузится, нужно удалить существующий файл smb.conf, а так же — любые файлы баз данных Samba (это .tdb и .ldb-файлы). Для того, чтобы найти директории, содержащие эти файлы, выполните следующие команды:



mbd -b | grep "CONFIGFILE"
smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR"


На рисунке ниже показаны результаты исполнения этих команд, которыми можно будет воспользоваться для того, чтобы удалить ненужные файлы. Если же подобные файлы в системе не существуют — можно сразу двигаться дальше.





Поиск файлов, которые надо удалить



Использование samba-tool



Теперь пришло время воспользоваться samba-tool. Мы запустим это средство в интерактивном режиме, выполнив следующую команду:



sudo samba-tool domain provision --use-rfc2307 --interactive


Выполнив команду с ключом --use-rfc2307, мы включаем расширения NIS. Samba-tool предложит настроить следующие параметры:




  • Realm. Это полное DNS-имя домена, которое настроено в файле hosts. Например: SAMBADOM.EXAMPLE.NET.

  • Domain. Доменное имя NetBIOS сервера Samba. Обратите внимание на то, что здесь рекомендуется использовать первую часть доменного имени DNS. Например, SAMBADOM.

  • Server Role. Этот параметр предназначен для указания типа серверной роли. По умолчанию здесь установлено значение dc, оно нас устроит.

  • DNS backend. Этот параметр позволяет настроить DNS-сервер. Здесь так же оставляем параметр по умолчанию — SAMBA_INTERNAL.


  • DNS forwarder IP address. Данный параметр позволяет указать IP-адрес DNS-сервера, на который будут перенаправлены запросы, которые не может разрешить сервер Samba. Если перенаправление DNS-запросов вам не нужно — ничего не вводите в ответ на данный вопрос. Подробнее об этом можно почитать здесь.

  • Administrator password. Тут надо указать пароль администратора домена.



После того, как система получит ответы на интересующие её вопросы, samba-tool настроит Samba как контроллер домена. Можете просмотреть файл /etc/samba/smb.conf и, если нужно, внести в него изменения.



Прежде чем продолжать, позаботьтесь о регистрации пользователей в Samba. Этот шаг очень важен — иначе пользователям не удастся пройти аутентификацию. Делается это следующими командами:



ssmbpasswd -a USERNAME
smbpasswd -e USERNAME


Здесь USERNAME — имя существующего пользователя, которого надо добавить к Samba. Указать пароль нужно будет лишь после ввода первой команды. Вторая активирует пользователя.



Настройка DNS-сервера



Нам надо, чтобы в качестве DNS-сервера на контроллере домена использовался он сам. Для того, чтобы это сделать, отредактируем файл /etc/network/interfaces, приведя его к такому виду:



auto INTERFACE_NAME
iface INTERFACE_NAME inet static
address IP_ADDRESS_FOR_SERVER
netmask NETMASK
gateway GATEWAY
dns-nameservers IP_ADDRESS_FOR_SERVER


Тут же имеются настройки использования сетевым интерфейсом статического IP-адреса. Обратите внимание на то, что всё, набранное ЗАГЛАВНЫМИ буквами, надо настроить в соответствии с параметрами вашей системы.



После выполнения настроек перезапустите сетевые сервисы такой командой:



sudo service networking restart


Кроме того, следует отредактировать файл /etc/resolv.conf, внеся изменения, согласующиеся с теми, о которых было сказано выше. А именно, тут нас интересует следующая строка:



nameserver IP_ADDRESS_FOR_SERVER


Здесь, вместо IP_ADDRESS_FOR_SERVER, нужно ввести тот же адрес, который был записан в параметр dns-nameservers выше.



Настройка Kerberos



У Kerberos имеется собственный стандартный конфигурационный файл, который нужно заменить файлом krb5.conf, сгенерированным в ходе подготовки Samba к работе. Для того, чтобы это сделать, выполните следующие команды:



sudo mv /etc/krb5.conf /etc/krb5.conf.orig
sudo ln -sf /var/lib/samba/private/krb5.conf /etc/krb5.conf


Обратите внимание на то, что вы можете столкнуться с отсутствием в системе файла /etc/krb5.conf. Если это действительно так, достаточно будет выполнить только вторую из вышеприведённых команд.



Тестируем и подключаемся



Самое сложное позади. Теперь всё готово к тому, чтобы протестировать только что созданный контроллер домена на Samba и подключиться к нему. Быстро проверить, всё ли работает, можно с помощью такой команды:



smbclient -L localhost -U%


После ввода пароля пользователя Samba, вы должны увидеть сообщение об успешном подключении.





Успешное подключение



Как видите, при проверке smbclient выведены сведения о netlogon и sysvol как об общих ресурсах. Они созданы по умолчанию и должны существовать на контроллере домена. Кроме того, в /var/lib/samba/sysvol/REALM/scripts следует поместить любые скрипты входа в систему, которые понадобятся клиентам. Здесь REALM соответствует тому параметру REALM, который был задан в ходе работы с командой samba-tool.



Итоги



Теперь контроллер домена готов принимать подключения. Однако, может оказаться так, что вам придётся отредактировать файл /etc/samba/smb.conf, внести в него данные, отражающие ваши требования к серверу. Этот файл, сгенерированный samba-tool, весьма лаконичен, хотя и является хорошей отправной точкой для тонкой настройки вашего AD DC, построенного на базе Samba и Ubuntu Server.



Уважаемые читатели! А какие варианты взаимодействия экосистем Linux и Windows кажутся вам наиболее интересными и полезными?
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/323860/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<администрирование - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda