| 1 |
On Wed, 2011-03-23 at 12:42 +0100, Alexander Sulfrian wrote: |
| 2 |
> Hi, |
| 3 |
> |
| 4 |
> reading the "Porthole plug-ins & extensions" proposal I got another |
| 5 |
> idea: |
| 6 |
> |
| 7 |
> Maybe you know web based software management solutions from various |
| 8 |
> enterprise Linux distributions (I remember, that at least RedHat |
| 9 |
> have such thing): |
| 10 |
> |
| 11 |
> Based on an python api for portage |
| 12 |
|
| 13 |
Yes, in fact I was the one that started the public_api branch of portage |
| 14 |
which is precisely for this use. It still needs more work to add emerge |
| 15 |
operations, some examples of this can be found in a previous gsoc |
| 16 |
project that resulted in a packagekit portage backend. |
| 17 |
|
| 18 |
> and some way to issue the api calls |
| 19 |
> over network (ssh, xmlrpc, maybe google-protobuf or other), |
| 20 |
|
| 21 |
Python now has the ability (built-in) to to do remote python imports. |
| 22 |
It handles pickling the data transfers in both directions... |
| 23 |
|
| 24 |
> it would be |
| 25 |
> possible to create a web based interface, where you can add clients and |
| 26 |
> install/update packages, view logs, changes portage settings or merge |
| 27 |
> configuration files. |
| 28 |
|
| 29 |
I develop porthole, which is a portage frontend. It already does nearly |
| 30 |
all this already and has imo a very good interface for displaying data, |
| 31 |
modifying settings, etc. for packages. Creating a web interface would |
| 32 |
be in fact more work, but certainly possible. I also believe it would |
| 33 |
take away too much time from the development of the control interface |
| 34 |
and cli development. The more time spent on the primary control |
| 35 |
interface and remote tools needed to perform the tasks, the better. |
| 36 |
|
| 37 |
A new web interface could be a future project. |
| 38 |
|
| 39 |
Have you tried using porthole? or any of the gui frontends available? |
| 40 |
|
| 41 |
Several years ago one of the devs doing some work on porthole created a |
| 42 |
preliminary patch [1] which allowed porthole to connect to remote |
| 43 |
machines. there were many things about that needed a lot more work to |
| 44 |
implement properly, securely. But we never did get back to it. But |
| 45 |
since python now has the built-in ability to do remote imports using |
| 46 |
ssh. That greatly reduces the barrier to actually implement it. |
| 47 |
|
| 48 |
|
| 49 |
> With that it would be easier to manage a large |
| 50 |
> Gentoo-based server farm. |
| 51 |
|
| 52 |
The reason I posted the idea. |
| 53 |
|
| 54 |
> Additionally it would be possibly to create a |
| 55 |
> simple cli to control all registered clients. |
| 56 |
> |
| 57 |
|
| 58 |
Most of the gentoo coding I have been doing this past few years has been |
| 59 |
to make api's for common gentoo tools like gentoolkit's eclean and |
| 60 |
equery. I have also now created an new api for layman. I am big on |
| 61 |
creating a design that allows many ways of using the operational code |
| 62 |
that actually performs the task. Be it cli, gui, etc. |
| 63 |
|
| 64 |
Note that a cli is listed as one of the tasks. |
| 65 |
|
| 66 |
> |
| 67 |
> What do you think? |
| 68 |
> |
| 69 |
> Thanks, |
| 70 |
> Alex |
| 71 |
|
| 72 |
[1] |
| 73 |
http://sourceforge.net/tracker/?func=detail&aid=930246&group_id=96324&atid=614399 |
| 74 |
|
| 75 |
|
| 76 |
-- |
| 77 |
Brian Dolbec <brian.dolbec@×××××.com> |
Archives