LINUX.ORG.RU

Удалённая компиляция с помощью RPC

 ,


0

1

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

С RPC раньше не сталкивался. Изучив кое-какие основы, сделал с помощью rpcgen небольшое приложение, которое отправляет серверу простые сообщения с вариантом аутентификации AUTH_SYS; сервер соответственно получает сообщения и сопутствующую информацию о клиенте (uid, hostname, gid...). Клиент и сервер на виртуальных машинах (ubuntu 12.04).

Для достижения цели мне думается дальше расширять это приложение, но сейчас возникло два вопроса: 1) как в коде сервера запустить компилятор (g++) с другим uid? 2) как корректно обработать результаты труда компилятора? Как оповестить пользователя и об ошибках и о предупреждениях и исполняемые/объектные файлы ему обратно отослать?

Ответ на: комментарий от its_not_my_name

А интересует конкретно Sun RPC, или RPC в широком смысле? Я полагаю, что Sun RPC сейчас не самая трендовая технология :)

annulen ★★★★★ ()

посылаешь серверу аддресс гит репозитория и говоришь, чтобы тот сделал клон, мэйк и отослал тебе исполняемый файл назад :)

invy ★★★★★ ()
Ответ на: комментарий от annulen

А интересует конкретно Sun RPC, или RPC в широком смысле? Я полагаю, что Sun RPC сейчас не самая трендовая технология :)

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

Но, увы, приходится работать именно с ней.

its_not_my_name ()
Ответ на: комментарий от invy

посылаешь серверу аддресс гит репозитория и говоришь, чтобы тот сделал клон, мэйк и отослал тебе исполняемый файл назад :)

Мне было бы интересно это реализовать, но, к сожалению, есть ТЗ по которому надо передавать серверу от клиента .cpp файлик и обратно получать результаты работы g++.

its_not_my_name ()

1) как в коде сервера запустить компилятор (g++) с другим uid?

через su -c или sudo, например

2) как корректно обработать результаты труда компилятора?

Записать stderr компилятора. Если код выхода 0, отправляем клиенту вывод stderr + выходной файл. Если не 0, оправляем stderr + флаг ошибки вместо выходного файла.

Если в sun rpc нет возможности запихать несколько «полей» в один ответ, придется придумать свой формат сериализации для объединения stderr и файла, например, записать заголовк с длиной обоих частей и их смещениями в начало ответа

annulen ★★★★★ ()

1) через shell?

su -l ...; g++ ... > logfile

2) кинуть в ответ logfile. Если это свой велосипед, то файл через сокет передается просто - сначала пихается длина файла (скажем 8 байт), затем сам файл. Если велосипед чужой - см. какие там поддерживаются протоколы.

AIv ★★★★★ ()

У тебя RPC сапомальный?

В любом случае настоятельно рекомендую ознакомиться с protocol buffers чтобы знать как на самом деле нужно строить протокол обмена. Если не ошибаюсь, оно даже умеет в RPC из коробки. Вот здесь можно посмотреть: https://developers.google.com/protocol-buffers/docs/proto

Если же ты пишешь с нуля на сокетах итп то тогда суть вопроса совершенно не понятна. Спрашивай что-то более конктретное, типа «как мне запустить команду из c++» или «какой сделать формат сообщения и как его парсить».

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

оно даже умеет в RPC из коробки.

оно умеет интерфейсы для вызовов из коробки. транспорта нет, как и, собссно, протокола.

anonymous ()

о клиенте (uid, hostname, gid...).

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

anonymous ()
Ответ на: комментарий от anonymous

Раньше была такая особенность у NFS - она все по uid определяла, так что если на другой машине с твоим uid другой юзер, то было упс... щас как не знаю.

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

AIv ★★★★★ ()
Ответ на: комментарий от anonymous

транспорта нет, как и, собссно, протокола.

На счёт транспорта я погорячился (впрочем, есть готовые решения), а вот простейший протокол оно умеет задавать:

service SearchService {
  rpc Search (SearchRequest) returns (SearchResponse);
}
true_admin ★★★★★ ()
Ответ на: комментарий от AIv

она все по uid определяла

Можно либо руками мапинг задать, либо, на сколько помню, поднимать демона который это сам сделает.

true_admin ★★★★★ ()
Ответ на: комментарий от AIv

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

Т.е.? Вот я форкнусь, вызовом execve() подниму компилятор, и в атрибутах процесса будет красоваться мой uid, так ведь? А мне надо не мой, а клиентский :) Вы сначала предожили шелл, скорее всего я им и воспользуюсь: мне видится это менее затратным.

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

Ну вот у меня задачка учебного плана, так что я может организую какой-нибудь список вида «хост:уид - уид_на_сервере» (соответственно зарегистрирую новых юзеров на серверной стороне). Получится так, что по прилетевшим значениям, сервер будет в коде выполнять сопоставление с существующими у него в системе uid и плясать дальше.

its_not_my_name ()
Ответ на: комментарий от its_not_my_name

Вот я форкнусь, вызовом execve() подниму компилятор, и в атрибутах процесса будет красоваться мой uid, так ведь? А мне надо не мой, а клиентский :)

А какая разница какой у него uid? Обычно в таких случаях сервер крутится под выделенным специально для него юзером.

AIv ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.