По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Роутеры MikroTik имеют множество полезных функций для траблшутинга проблем. Одной из таких утилит является возможность создания supout.rif файла.
Supout.rif - это файл, который содержит всю конфигурацию вашего роутера, а также логи и другую полезную информацию об устройстве. Возможность создания данного файла задумывалась командой MikroTik как быстрый способ информации получения всей необходимой информации о роутере в рамках работ по оказанию технической поддержки. Дабы не нагружать пользователя просьбами выгружать сначала конфигурацию, потом снимать логи, а просто попросить выгрузить Support.rif и начать исследовать проблему.
При этом, пользователь может не переживать за то, что его пароли из утекут на третью сторону, так как все пароли в файле supout.rif шифруются.
Итак, чтобы создать данный файл через WinBox, нужно просто нажать на кнопку Make Supout.rif, затем Start и дождаться пока завершится процесс генерации.
Теперь, чтобы скачать его, просто открываем Files, ищем support.rif, нажимаем на него правой кнопкой и выбираем Download.
Чтобы сгенерировать этот файл из командной строки, вводим в Terminal:
/system sup-output name=supout.rif. Далее можно скачать его по FTP или отправить на другой хост.
Но текстовым редактором данный файл мы открыть не сможем. Для того, чтобы его прочитать в команде MikroTik придумали инструмент Supout.rif viewer. Чтобы им воспользоваться, необходимо зарегистрироваться на сайте MikroTik.com, залогиниться в свой аккаунт, перейти в раздел Support и найти там Supout.rif viewer.
Далее нужно просто загрузить сгенерированный файл в открывшейся форме. После этого перед вами откроется список из 46 пунктов, нажав на которые вы сможете посмотреть соответствующую информацию.
Правила firewall, настройки маршрутизации, лог устройства, в общем все что здесь есть - все это есть. Например, в разделе export содержится вся текущая конфигурация.
Очень удобный инструмент, который пригодится любому, кто администрирует роутеры MikroTik.
Привет, друг! Мы подготовили удобную инструкцию по установке и настройке SFTP-сервера Linux.
Что такое SFTP?
SFTP - это безопасный протокол передачи файлов - «Secure SHell» File Transfer Protocol. То есть это версия FTP, которая для безопасности поверх использует SSH. FTP делает то же самое, но без шифрования, поэтому использовать SFTP предпочтительнее.
Установка SFTP-сервера на Linux
Чтобы выполнить эти шаги, вам нужно иметь права sudo. SFTP прост в установке, но сначала необходимо установить OpenSSH со стороны сервера и SSH-пакет со стороны клиента.
Чтобы установить OpenSSH на сервер, используйте следующую команду:
sudo apt install openssh-server [Ubuntu/Debian]
sudo yum –y install openssh-server openssh-clients [CentOS/RHEL]
Вам также понадобится SSH на компьютере, с которого вы хотите получать доступ к серверу SFTP.
sudo apt install ssh [Ubuntu/Debian]
Теперь все готово для настройки SFTP.
Этап 1: Создание групп, пользователей, каталогов
Для безопасного использования SFTP, лучше всего создать группы и пользователей, которые будут использовать только эту службу.
Создадим группу с названием sftpg, при помощи комыды groupadd:
sudo groupadd sftpg
Далее создадим пользователя seenisftp, и добавим его в группу.
sudo useradd -g sftpg seenisftp
sudo passwd seenisftp
В команде useradd параметр -g указывает группе, какого пользователя нужно добавить.
Предположим, что вы хотите использовать каталог /data/ в качестве корневого для sftp, а /data/USERNAME - для каждого пользователя. Поэтому, когда пользователи входят через sftp, они должны будут оказаться в каталоге /data/USERNAME. Также создадим ограничение при котором пользователи смогут читать файлы из этого каталога, но загружать их смогут только в каталог uploads.
Cоздадим каталоги и изменим их доступ:
sudo mkdir -p /data/seenisftp/upload
sudo chown -R root.sftpg /data/seenisftp
sudo chown -R seenisftp.sftpg /data/seenisftp/upload
Важно: убедитесь, что владелец /data/USERNAME и есть root, это обязательно для изменения корневого каталога в SFTP
Этап 2: Настройка sshd_config
Далее нужно настроить сервер так, чтобы когда пользователь, из группы sftpg, входил в систему, он попадал в sftp вместо обычной оболочки, в которую попадает через ssh. Добавьте следующий фрагмент кода в файл /etc/ssh/sshd_config:
Match Group sftpg
ChrootDirectory /data/%u
ForceCommand internal-sftp
ChrootDirectory позволяет создать необходимый каталог в качестве корневого узла (/ каталог) в дереве каталогов. Вошедший в систему пользователь не сможет увидеть ничего выше этого каталога и это не даст ему получить доступ к файлам других пользователей. %u - это escape код для заполнения его текущим именем пользователяm, во время входа в систему.
Этап 3: Перезагрузите службу
Чтобы выполнить внесенные в sshd_config изменения, перезапустите службу:
sudo systemctl restart sshd
Доступ к SFTP через командную строку Linux
Заходите в SFTP также как в SSH:
sftp seenisftp@merionet.ru
Примеры команд SFTP
Синтаксис команд SFTP:
COMMAND [SOURCE] [DESTINATION]
Параметрами могут быть либо локальные, либо удаленные системные пути.
GET - загрузка содержимого с удаленного сервера в локальную систему.
GET poster.img ~/Pictures
PUT - загрузка содержимого из локальной системы в удалённую.
PUT ~/Pictures/picture2.jpg uploads/
RM – предназначен для удаления файлов в удалённой системе.
RM uploads/picture3.jpg
В прошлой статье мы рассмотрели, как создавать в амазоне инстансы с помощью Terraform. В данной статье мы рассмотрим, как изменять то, что мы создали в облаке.
Из прошлой статьи у нас есть работающий сервер в амазоне, теперь нам необходимо изменить его параметры.
Допустим мы решили, что нам одного сервера недостаточно и нам понадобился еще один сервер. Мы можем внести изменение. Вместо count 1, подставим значение 2.
Сохраняем изменение в файле. Пробуем запустить, команду которая покажет, что у нас произойдет - terraform plan.
Мы видим, что в результате наших действий, будет добавлен еще один сервер. Запускаем на выполнение terraform apply. Не забываем, что необходимо подтвердить наше действие напечатав yes.
Мы можем увидеть, что в результате наших действий изменилось количество бегущих серверов. Теперь их 2 штуки.
Следующий шаг. Давайте попробуем изменить, размер сервера. У нас был t2.micro, возьмем немного побольше сервер t3.micro и уберем один лишний сервер изменив параметр count c 2 на 1.
Вводим команду terraform plan и видим, что один сервер будет уничтожен, а второй будет изменен.
Ну и стандартное уже terraform apply с подтверждением своих действий. Перейдем в консоль амазон и посмотрим, что происходит.
Амазон, в соответствии с произведёнными изменениями меняет размер виртуального сервера и уничтожает лишний. Теперь, можно посмотреть в официальной документации resource aws_instance, те параметры, которые можно изменять таким нехитрым образом в амазон с помощью Terraform.
Давайте добавим так, чтобы обозначить, например, сервер. На старице в официальной документации, было показано, что внутрь ресурса надо добавить.
tags = {
Name = "Vasya"
}
И отправляем изменения в амазон terraform apply. На выходе мы получим.
Сервер с именем Vasya. По факту мы не сделали ничего нового, просто изменили пустые параметры, грубо говоря просто подписали, добавили tags. Tags имеет смысл добавлять к каждому развертываемому серверу, потому что в крупных проектах, когда серверов более 100, а то и пол тысячи, будет очень легко запутаться и в параметрах и в запущенных серверах. В этом случае tag или по-другому метки, нас выручат очень хорошо.
Обратите внимание, когда мы вносим, какое-либо изменение в код, то при выводе результата команды terraform plan, на против планируемых изменений мы видим знак + зеленый если добавляется что-то или знак - красный если мы, что-то убираем.
Еще не мало важный фактор. Нельзя вносить изменения в сервера, в ручном режиме через консоль, которые мы обслуживаем с помощью Terraform. Все, изменения, которые вы внесете в ручном режиме, будут удалены при синхронизации, потому что данных параметров нет в коде.
Следовательно, исходя из этого принципа, удалять ресурсы тоже необходимо через код. Делается это достаточно просто, просто необходимо удалить ресурс из кода или поставить параметр count = 0 внутри ресурса.
В нашем примере я изменил параметр count = 0. И можно видеть, что Terraform сообщил нам о том, что сервер будет уничтожен в облаке.
И действительно, если мы посмотрим в консоль, то мы увидим, что все сервера в облаке находятся в состоянии terminated, в течении полутора минут.
Это означает, что данные сервера выключены и готовятся к удалению. Если у нас несколько серверов предназначен для удаления, то Terraform будет производить выключение и последующее удаление данных серверов параллельно.