tobuild file

[Enrico Scholz]

skvidal at phy.duke.edu (seth vidal) writes:

>> >> plague seems to try to connect directly with the buildserver. This will
>> >> not work in most corporate or complex environments:
>> >
>> > I'd wager the vast majority of plague users are going to be coming at it
>> > from a corporate environment. This is a hobbyist distribution, remember?
>> 
>> This should not stop us from doing things right from the beginning.
>> *Enforcing* usage of a half-baked plague-client (and ignoring the
>> current 'make build') is the wrong way.
>
> I take issue that doing things the way you've suggested is 'right'.
> Programming for the corner case is not 'right' nor sane. You program
> for the common case

Proxy support is a common case which should be implemented in all
network aware applications. Well-known ports should be used for all
public services.


> I take more issue that there is anything half-baked about plague or
> plague-client. Just b/c it doesn't support an infrastructure that
> doesn't allow arbitrary outbound connections doesn't mean it is
> half-baked. 

Every HTTP based application without proxy support is half-baked.


> oh and the current 'make build' way relies on me uploading them,
> manually, from time to time using plague. So 'ignoring the whole make
> build' is entirely the point. make build will become make plague
> sometime soon.

Hopefully, plague will be finished then...


>> Why not tunnel it over an exiting https server?  E.g. over
>> https://bugzilla.redhat.com/plague; this should be doable with Apache
>> httpd's ProxyPass directive.
>
> b/c I doubt seriously red hat is going to allow that sort of misc cruft
> to live on their bugzilla server(s).

It should be only four additional statements in httpd.conf; e.g.

| SSLProxyEngine          on
| ProxyVia                on
| ProxyPass               /plague/        https://the-buildhost/
| ProxyPassReverse        /people/        https://the-buildhost/


> Now, we can do something with this from another machine but I'm still
> wondering why we're inventing layers of indirection for an extremely
> isolated case.

Because network applications resp. public services should be as firewall
friendly as possible. XML-RPC is HTTP based and allows this without much
effort. So why stop at the current state just because you think that it
is enough for the most users?



Enrico