skvidal@xxxxxxxxxxxx (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
