По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Часто бывает, что на системе Linux произошла незапланированная или по неизвестным очевидным причинам, перезагрузка. Поиск и устранение первопричины может помочь предотвратить повторение таких проблем и избежать незапланированных простоев. Есть несколько способов выяснить, что вызвало перезагрузку. В этой статье мы обсудим эти способы и способы использования доступных утилит и журналов в системе Linux для устранения таких сценариев. Проверка времени перезагрузки Чтобы посмотреть, когда именно произошла перезагрузка системы можно воспользоваться командами who и last Проверка системных журналов Кроме того, можно сопоставить время перезагрузки, которую требуется диагностировать, с системными сообщениями. Для систем CentOS/RHEL журналы можно найти по адресу /var/log/messages, а для систем Ubuntu/Debian - по адресу /var/log/syslog. Для фильтрации или поиска конкретных данных можно использовать команду tail или любимый текстовый редактор. Как видно из приведенных ниже журналов, такие записи предполагают завершение работы или перезагрузку, инициированную администратором или пользователем root. Эти сообщения могут варьироваться в зависимости от типа ОС и способа запуска перезагрузки или завершения работы, но вы всегда найдете полезную информацию, просматривая системные журналы, хотя этого не всегда может быть достаточно, чтобы определить причину. Ниже приведена одна такая команда, которую можно использовать для фильтрации системных журналов: sudo grep -iv ': starting|kernel: .*: Power Button|watching system buttons|Stopped Cleaning Up|Started Crash recovery kernel' /var/log/messages /var/log/syslog /var/log/apcupsd* | grep -iw 'recover[a-z]*|power[a-z]*|shut[a-z ]*down|rsyslogd|ups' Зафиксированные события не всегда могут быть конкретными. Всегда отслеживайте события, которые дают признаки предупреждений или ошибок, которые могут привести к выключению или сбою системы. Проверка журнала auditd Для систем, использующих auditd – это отличное место для проверки различных событий с помощью инструмента ausearch. Используйте приведенную ниже команду для проверки последних двух записей из журналов аудита. $ sudo ausearch -i -m system_boot,system_shutdown | tail -4 Появится сообщение о двух последних остановках или перезагрузках. Если это сообщает о SYSTEM_SHUTDOWN, за которым следует SYSTEM_BOOT, все должно быть хорошо. Но, если он сообщает две строки SYSTEM_BOOT подряд или только одно сообщение SYSTEM_BOOT, то, скорее всего, система некорректно завершила работу. Вывод при нормальной работе должен быть примерно следующим: $ sudo ausearch -i -m system_boot,system_shutdown | tail -4 ---- type=SYSTEM_SHUTDOWN msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success' ---- type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success' В приведенных ниже выходных данных перечислены два последовательных сообщения SYSTEM_BOOT, которые могут указывать на аварийное завершение работы, хотя результаты нужно скорректировать с данными системного журнала. $ sudo ausearch -i -m system_boot,system_shutdown | tail -4 ---- type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success' ---- type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success' Анализ журнала systemd Чтобы сохранить журнал системных логов на диске, необходимо иметь постоянный системный журнал, иначе логи будут очищаться при перезагрузке. Для этого можно либо внести изменения в /etc/systemd/journald.conf, либо создать каталог самостоятельно с помощью следующих команд: $ sudo mkdir /var/log/journal $ sudo systemd-tmpfiles --create --prefix /var/log/journal 2>/dev/null $ sudo systemctl -s SIGUSR1 kill systemd-journald После этого можно дополнительно перезагрузить систему для ввода нескольких записей перезагрузки в журнал, хотя это и не требуется. Приведенную ниже команда позволяет выводить список записанных событий о загрузке из журнала: $ journalctl --list-boots Вот его выходные данные на моем сервере: Как видно на рисунке, в системе есть несколько событий загрузки. Для дальнейшего анализа причины конкретной перезагрузки используйте: $ journalctl -b {num} –n Здесь {num} будет индексом, заданным в команде journalctl --list-boots в первом столбце. В приведенных выше выходных данных можно просмотреть сообщения, зарегистрированные в журнале, и отследить аномалии, если таковые имеются. Заключение Не всегда можно определить причину перезагрузки Linux с помощью одной команды или из одного файла журнала. Поэтому всегда удобно знать команды и журналы, которые фиксируют события, связанные с системой, и могут сократить время, необходимое для поиска первопричины. Приведенные выше примеры дают вам возможность начать поиск и устранение неисправностей. Используя комбинацию таких инструментов и журналов, вы можете быть уверены в том, что произошло и как перезагрузилась ваша система.
img
SSH туннели один из самых часто используемых методов связи среди системных и сетевых администраторов. В данном руководстве расскажем о такой функции как переброс порта SSH. Это используется для безопасной передачи данных между двумя и более системами. Что такое переброс порта SSH? Коротко, переброс порта SSH даёт возможность создавать туннель между несколькими системами, а затем настроить эти системы так, чтобы трафик они гнали через этот туннель. Именно по такой логике работает VPN или SOCKS Proxy. Есть несколько разных методов переброса: переброс локального порта, переброс удалённого порта или динамический переброс. Для начала дадим пояснение каждому из них. Локальный переброс порта позволяет получать доступ ко внешним ресурсам из локальной сети и работать в удаленной системе, как если бы они находились в одной локальной сети. По такому принципу работает Remote Access VPN. Переброс удаленного порта дает возможность удалённой системе получать доступ к вашей локальной сети. Динамический переброс создает SOCKS прокси сервер. После этого настраиваем приложения так, чтобы они использовали это туннель для передачи данных. Чаще всего такой переброс используется для доступа к ресурсам, который по той или иной причине заблокированы для данной страны. Для чего нужен переброс порта SSH? Допустим у вас есть какое-то приложение, которые передаёт данные в открытом виде или через нешифрованный протокол. Ввиду того, что SSH создает шифрованное соединение, то вы с легкостью можете настроить программу так, чтобы трафик её шёл через этот туннель. Он так же часто используется для доступа к внутренним ресурсам извне. Приблизительно это напоминает Site-to-Site VPN, где нужно указывать какой именно трафик нужно заворачивать в туннель. Сколько сессий можно устанавливать? Теоретически, можно создавать столько сессий, сколько нам захочется. В сети используется 65 535 различных портов, и мы можем перебрасывать любой из этих портов. Но при перебросе порта нужно учитывать, что некоторые из них зарезервированы за конкретными сервисами. Например, HTTP использует 80 порт. Значит, переброс на порт 80 возможен только если нужно переадресовать веб трафик. Порт, который перебрасывается на локальном хосте может не совпадать с портом удаленной системы. Мы легко можем перебросить локальный порт 8080 на порт 80 на удаленной машине. Иными словами, если мы напишем IP адрес нашей машины и порт 8080, то запрос пойдет на 80 порт удалённой системы. Если вам не критично какой порт использовать на своем хосте, лучше выбрать что-то из диапазона 2000-10000, так как все порты ниже 2000 зарезервированы. Переброс локального порта Локальная пересылка представляет собой переброс порта из клиентской системы на сервер. Он позволяет настроить порт в системе таким образом, чтобы все соединения на этот порт проходили через туннель SSH. Для переадресации локального порта используется ключ L. Общий синтаксис команды таков: $ ssh -L local_port:remote_ip:remote_port user@hostname.com $ ssh -L 8080:www.example1.com:80 example2.com Данной командой мы говорим системе, что все запросы на 8080 порт example1.com переадресовывать на example2.com. Это часто используется когда нужно организовать доступ извне на внутренний ресурсы компании. Тестирование работы переадресованного порта Чтобы проверить, работает ли переадресация должным образом можно воспользоваться утилитой netcat. На машине, где была запущена команда переадресации нужно ввести команду netcat в следующем виде: $ nc -v remote_ip port_number Если переадресация работает и трафик проходит, то утилита вернёт "Успех!". В противном случае выдаст ошибку об истечении времени ожидания. Если что-то не работает, нужно убедиться, что подключение к удаленному порту по SSH работает корректно и запросы не блокируются межсетевым экраном. Создание постоянного туннеля (Autossh) Для создания туннеля, который будет активен постоянно используется так называемая утилита Autossh. Единственно требование это необходимость настройки между двумя системами аутентификацию по публичным ключам, чтобы не получать запросы на ввод пароля при каждом обрыве и восстановлении соединения. По умолчанию, Autossh не установлен. Чтобы установить эту утилиту введем команду ниже. $ sudo apt-get install autossh Синтаксис утилиты autossh почти похож на синтаксис ssh: $ autossh -L 80:example1.com:80 example2.com Переброс удалённого порта Переброс порта с удалённой машины используется в тех случаях, если нужно предоставить доступ на свой хост. Допусти у нас установлен веб сервер и нам нужно, чтобы друзья могли пользоваться им. Для этого нужно ввести команду показанную ниже: $ ssh -R 8080:localhost:80 geek@likegeeks.com А общий синтаксис команды выглядит так: $ ssh -R remote_port:local_ip:local_port user@hostname.com Динамическая переадресация портов Динамическая переадресация портов позволит ssh функционировать как прокси-сервер. Вместо переброса трафика на специфический порт, здесь трафик будет идти через на диапазон портов. Если вы когда-нибудь пользовались прокси сервером для посещения заблокированного сайта или просмотра контента, недоступного в вашем регионе, вероятнее всего вы пользовались SOCKS сервером. Динамическая переадресация также обеспечивает некоторую приватность. Она затрудняет логирование и анализ трафика, так как трафик проходит через промежуточный сервер. Для настройки динамической переадресации используется следующая команда: $ ssh -D local_port user@hostname.com Таким образом, если нужно весь трафик идущий на порт 1234 направить на SSH сервер, нужно ввести команду: $ ssh -D 1234 geek@likegeeks.com После установления соединения, мы можем указать в приложениях, например, браузере, пропускать трафик через туннель. Множественная переадресация Иногда приходится перебрасывать несколько внутренних портов на несколько внешних. Допустим у нас на одном и том же сервере крутятся и веб сервер и oracale. В таком случае мы можем указать несколько условий переадресации ставя перед каждым из них ключ L для локальной переадресации и R для внешней. $ ssh -L local_port_1:remote_ip:remote_port_1 -L local_port_2:remote_ip:remote_port2 user@hostname.com $ ssh -L 8080:192.168.1.1:80 -L 4430:192.168.1.1:1521 user@hostname.com $ ssh -R remote_port1:local_ip:local_port1 remote_port2:local_ip:local_port2 user@hostname.com Просмотр списка туннелей Чтобы просмотреть сколько SSH туннелей активны на данный момент можно прибегнуть к помощи команды lsof: $ lsof -i | egrep '<ssh>' Как видим, на нашей системе сейчас активно три подключения. Чтобы вместо имени хоста показать IP адрес к команде нужно добавить ключ n. $ lsof -i -n | egrep '<ssh>' Ограничение переадресации портов По умолчанию, переброс портов SSH активен для всех. Но если нужно ограничить переадресацию портов в целях безопасности, то нужно отредактировать файл sshd_config. $ sudo vi /etc/ssh/sshd_config Здесь есть несколько опций, позволяющих ограничивать создание SSH туннелей. PermitOpen позволяет прописать адреса, для которых можно включить переадресацию портов. Тут можно указать конкретный IP адреса или название хоста: PermitOpen host:port PermitOpen IPv4_addr:port PermitOpen [IPv6_addr]:port AllowTCPForwarding данная опция включает или отключает переадресацию портов для SSH. Так же можно указать какой тип переадресации допускается на этом хосте. AllowTCPForwarding yes #default setting AllowTCPForwarding no #prevent all SSH port forwarding AllowTCPForwarding local #allow only local SSH port forwarding AllowTCPForwarding remote #allow only remote SSH port forwarding Для подробной информации можно вызвать руководство по файлу sshd_config: $ man sshd_config Уменьшение задержки Проблема с переадресацией портов на SSH это возможность увеличения задержки. При работе с текстовой информацией э то не критично. Проблема даёт о себе знать если по сети идёт много трафика, а SSH сервер настрое как SOCKS сервер, то есть на нём настроена динамический переброс портов. Это происходит по той причине, что SSH туннели по сути это TCP туннель поверх TCP. Это не очень эффективный метод передачи данных. Для решения проблемы можно настроить VPN, но если по какой-то причине предпочитаете SSH туннели, то существует программа sshuttle, которая устраняет проблему. На Ubuntu или других дистрибутивах семейства Debian программу можно установить командой $ sudo apt-get install sshuttle Если же программы нет в репозиториях дистрибутива, то можно взять ее с GitHub: $ git clone https://github.com/sshuttle/sshuttle.git $ cd sshuttle $ ./setup.py install Настройка туннеля в sshuttle отличается от SSH. Чтобы завернуть весь трафик в туннель нужно ввести следующую команду: $ sudo sshuttle -r user@remote_ip -x remote_ip 0/0 vv Прервать соединение можно комбинацией клавиш Ctrl+C. Чтобы запустить sshuttle как демон, нужно добавить ключ D. Чтобы убедиться что туннель поднят и в глобальной сети показывается другой IP, в терминале можно ввести команду: $ curl ipinfo.io Или же просто открыть любой другой сайт, который покажет белый IP и местоположение.
img
Что это и зачем? Сегодня сложно представить мир без компьютерных сетей. Технический прогресс позволяет пользователю всего за несколько минут совершить покупки в интернет-магазине с доставкой, заказать такси, забронировать билет на самолет и отель, приобрести билеты в театр и многое другое. Всё это стало возможным благодаря широкому применению компьютерных сетей, их взаимодействию и интегрированию в общую глобальную сеть. Мало кто задумывается, как всё это работает. Средний пользователь, который является конечным потребителем услуг, взаимодействует с сетью через интерфейс пользователя, и просто делает в сети то, что ему нужно. Между тем десятки и сотни тысяч системных инженеров ежеминутно поддерживают инфраструктуру сети на плаву, чтобы всё функционировало без поломок и сбоев. В этом им помогают различные автоматизированные программные решения, которые позволяют одному администратору поддерживать работу сети из сотен устройств. Сегодня мы разбираем одно из таких приложений, призванных сэкономить время системного инженера решение Chef от одноименной группы разработчиков. Непосредственно о Chef Chef это система управления конфигурацией сети. По функциональному назначению она схожа с Puppet или Ansible, однако имеет от них ряд отличий, благодаря которому и пользуется популярностью у некоторых системных инженеров. Разберем, что же в этом решении такого. Сама программа реализована на Ruby, поэтому пользователь должен обладать хотя бы базовыми знаниями по этому языку программирования, а на центральном сервере должно быть установлена соответствующая программная среда. Базовыми понятиями, которые используются в этой программе являются: Ноды (Nodes): Эта любая серверная единица, физическая или виртуальная, которая будет входить в систему обслуживания Chef. Шеф-сервер (Chef-server): Центральный сервер, на котором будет установлена основная управляющая часть программы. Рецепт (Receipt): Собственно, сам файл с конфигурацией, применяемой для настройки поведения сети на различных сетевых узлах. Поваренная книга (Cookbook): Хранилище рецептов то есть всех файлов конфигурации сети. Хранилище поваренных книг (Bookshelf): Директория-хранилище поваренных книг. Рабочая станция администратора (Workstation): Физический ПК, на котором будет развернута система управления Chef. Нож (Knife): Основной инструмент управления программой Chef и ее составляющими из консоли. Помимо этого, программа содержит много компонентов таких как веб-сервер Nginx, сетевой интерфейс сервера Web-UI, хранилище данных PostgreSQL, и другие компоненты. Кроме того, каждая поваренная книга содержит, помимо рецептов, также атрибуты (параметры поведения сети, описанные через рецепты или роли), шаблоны (заготовки файлов конфигурации) и файлы (любые файлы, которые будут распространяться на ноды с помощью рецептов). То есть, структура программы выглядит так: администратор разворачивает серверную часть программы на рабочей станции, то есть создаёт на ней шеф-сервер. Далее пишет рецепты для определения будущего поведения всех нод, объединяет их в поваренную книгу (вместе с нужными атрибутами, файлами программного обеспечения и шаблонами будущих параметров конфигурации), затем помещает книгу в хранилище. Причем, рецептов в поваренной книге может быть несколько на случай различных версий операционных систем и ПО на узлах сети, да и самих поваренных книг также может быть более одной для различных сценариев поведения сети. Ноды через клиентскую часть запрашивают актуальные рецепты у сервера, принимают команды и переконфигурируют параметры узла так, что он исполняет свое назначение в сети наиболее эффективно. Таким образом, система является достаточно гибкой для быстрой перенастройки сети под исполнение тех или иных задач что и является ее основным плюсом. Таким образом, вы получаете ультимативную платформу для управления и автоматизации в вашей сети. Конечно, придется немного поучиться и набраться опыта, зато потом вы сможете экономить кучу вашего времени и избавиться от досадных ошибок.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59