#include <hallo.h> * Ron [Mon, May 01 2006, 01:25:36PM]: > > In a nutshell, if you set: > > example_sources_line="run screaming to the help desk"
Aaah, I see, you just wanted to configure the help messages sent to user. Somehow I assumed that you wish deeper changes... > and visit the usage page of the cacher, the basic inconsistency > that first grabbed me should be quite evident when trying to > follow its instructions. > > More-practical examples are below, but more mixed up with My Idea > of how it might be improved... it's hardcoding ftp.au.d.o as the > 'before' example which is the basic bug that got me scratching, > the musing on what to replace it with you are free to pick and > choose from... Yes, it is not perfect. I should have named it debian.example.org a while ago, but the mirror URI looks more authentic with a real servers. Which OTOH presumes that users have enough phantasy to convert their sources.list. > On Sun, Apr 30, 2006 at 10:01:07PM +0200, Eduard Bloch wrote: > > #include <hallo.h> > > > > Sorry, I cannot follow. Please say what exactly you mean, my idea of > > "ideal" may differ from yours. > > Ok, if I set, for example: > > example_sources_line=deb http://<b>mycache.mydomain:8080/</b>http.us.debian.org/debian unstable main contrib non-free I have another idea: - make the contents static HTML files - put the files into /etc/errors, a default page and maybe specific from different visitors - when looking for the error page contents, first look at the domain name of the visitor (eg. a.b.example.org), try to find the appropriate error page for him (lookin for a.b.example.org.html, b.example.org.html, example.org.html and default.html) I think this should give the local admin enough control to specify desired user actions. > With the intention that us.d.o should be the preferred mirror, > perhaps even insisting on that via: allowed_locations=http.us.d.o > > Then the usage instructions shown at http://mycache.mydomain:8080/ > become: > > ... like this: > > deb http://ftp.au.debian.org/debian unstable ... > > becomes > > deb http://mycache.mydomain:8080/http.us.d.o/debian ... > > > Which is not really consistent with the rest of the text above it, > which indicates you just need to prepend the cache location. > > I see a couple of ways this might prove misleading (if (l)users are > pointed to that page as a reference by local admin): If ftp.au.d.o > is_a_permitted mirror, but not_the_preferred one, people may be led > to stop using it by following the example literally. Conversely if > the example given is the only_allowed_mirror, that is not clearly > indicated either. Most people will figure it out without too many > tries, or calls to a help desk, but it seems that it shouldn't be > too hard to clarify this one way or another and avoid all that. > > > > > It might be best (or at least easiest) to compose this from a > > > pair of 'cache_server' and 'example_server' settings or similar... > > > > Specifying what? Concrete use case please. > > I originally though of something like (wrt the example above): > > cache_server=mycache.mydomain:8080 > example_server=http.us.d.o/debian unstable ... > > Which could be used to easily compose both 'before' and 'after' > examples shown (instead of hard coding ftp.au.d.o), with only the > addition of the cache_server to the appropriate place in the url. > > I wonder, as an extension to that, if this should not permit > a list of examples, and a way to indicate if they are the only > servers permitted, or only examples you might commonly use: > > eg. > # Any sort of list mechanism, this one simply whitespace separated. > example_server=a.o b.o c.o > > Usage: edit ... like this: > > deb http://a.o > deb http://b.o > deb http://c.o > > becomes > > deb http://cache/a.o I see what you mean, but I think adding additional processing for all the possible examples (apt-cacher can be used in many different ways) adds additional code complexity which should not be in the server itself. For your case above, one single custom HTML file written once by the admin is enough. There could be even different help pages, see above. For any other case there is simply not enough information to create meaningful messages matching the exact use case. > I do realise that I could probably add any html I like to the > example_sources_line, with any explanation or examples I like, > on as many lines as I like, but that doesn't seem like the best > answer, and the documentation didn't lead me to believe that > was the expected style of use... Uhm, no. I already hate this example_sources_line cludge, it should have been done differently. IMO it will go away with the next major version. Thanks for reporting that. Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
