Этот демон может использоваться на сервере приложений или на сервере базы данных для выполнения системных команд с помощью вызовов rest API.

Здравствуйте, я Асель. Сегодня я собираюсь показать вам, как создать rest API для выполнения системных команд на вашем сервере. Этот метод используют известные компании. Представьте, что вы переместили свою базу данных на другой сервер, отличный от вашего внутреннего сервера, и хотите получить контроль над своим сервером базы данных из своего внутреннего API. Для этого нам нужно создать демона на сервере базы данных.

* примечание - я пишу это как контактный адрес. Если вы собираетесь продакшен, вам следует серьезно подумать о проблемах безопасности (используя https и т. Д.).

Шаг 1 - Сбор зависимостей

Начнем с добавления пары зависимостей в наш проект.

Сначала я дам краткое введение об этих зависимостях, а также после того, как мы их используем. Actix - это фреймворк, который мы будем использовать для нашего API для отдыха. serde используется для сериализации и десериализации. simple_logger и log используются для ведения журнала, а последний pam используется для аутентификации пользователя.

Шаг 2 - Запустите простой сервер

Как сказано в документации, я буду следовать этим строкам кода.

Если все в порядке, вы увидите тот же журнал, что и мой.

Это очень-очень простая реализация, но я думаю, что ее достаточно для основы использования actix.

├── Cargo.lock
├── Cargo.toml
├── LICENSE
├── README.md
└── src
 ├── executor
 │ ├── execute.rs
 │ └── validate_password.rs
 └── main.rs
└──target

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

Шаг 3 - Создание функции для проверки пользователя

В основном я буду использовать для этого ящик с памятью. Используя этот метод, API вызывающего абонента может проверить, имеет ли пользователь доступ к серверу или нет.

Шаг 4 - Создание функции для выполнения команд.

Эта функция получит запрос JSON с именем пользователя и паролем для пользователя и вернет логический результат.

Оба этих метода будут использовать корневой путь как serv..

Шаг 5 - Создайте основную функцию

Теперь все основные функции реализованы. Теперь нам нужно связать файл с сервером.

Простое объяснение того, что я здесь сделал.

Это из документации.

Метод run() возвращает экземпляр типа Server. Для управления http-сервером могут использоваться методы типа сервера.

pause() - Приостановить прием входящих подключений

resume() - Возобновить прием входящих подключений

stop() - Остановить обработку входящего соединения, остановить всех воркеров и выйти

Из-за файлового дерева мы должны использовать исполнитель мода следующим образом. В противном случае мы не сможем использовать созданные нами методы.

mod executor {    
     pub mod validate_password; 
     pub mod execute;
}

Я создал по две службы для каждой функции. Таким образом, каждый будет доступен под 127.0.0.1:8088/serv/.

Здесь определены 10 рабочих потоков, поэтому выполнение некоторых системных команд может занять значительное время. После создания рабочих процессов каждый из них получает отдельный экземпляр приложения для обработки запросов, поэтому время ожидания отсутствует.

Actix может ждать запросов на поддерживающем соединении. Keep_alive поведение соединения определяется настройками сервера. из документации -

  • 75, Some(75), KeepAlive::Timeout(75) - включить 75 секунд для сохранения активности таймера.
  • None или KeepAlive::Disabled - отключить keep alive.
  • KeepAlive::Tcp(75) - используйте SO_KEEPALIVE параметры сокета.

Наконец, запустить приложение → cargo run.

Заключение

Этот API создан для управления API вашего сервера. Таким образом, для выполнения команд Linux не требуется ssh.

Надеюсь, эта статья поможет вам в работе с Rust и Actix. Спасибо.
Ура!
Вот учебник по Rust-Rocket Rest API, написанный мной ...



Как создать REST API в Rust - пошаговое руководство
Создайте свой API на самом популярном языке за последние четыре года на Stack Overflow medium.com