> -----Original Message----- > From: Martin Meredith [mailto:[email protected]] > Sent: Monday, February 06, 2012 11:17 AM > To: [email protected] > Subject: Re: [Pound Mailing List] Pound 2.7 > > On 06/02/12 16:00, Robert Segall wrote: > >> Clustering via multiple includes of the same file is clever. I'd > >> suggest a note in the man page about that, since I think it's a > >> common thing. > >> > >> Re: include_dir - if you sort the files alphabetically, then order > is > >> defined. > > ...and at a later date you add one file by accident to that directory > > and nothing works any longer. Besides, think of the next sysadmin, > who > > will need to work with your installation. > I'd say that if they add a file and break it - then surely it's their > fault?? > > > > I would also question the use case for it: do you really need > hundreds > > of files included? If it is just a handful it is not so difficult to > > include them explicitly. > Same could be said for apache. It allows us to 1) develop a similar > system like a2ensite a2enmod et al, and 2) means if we want to add, > say, a new listener, we only have to add a file, not edit multiple > files. > Therefore, reducing the possibility that we break something. (typoing > the filename for example) >
I would expect any system admin using a recent Linux distribution would be familiar with conf.d style directories. Every new distribution I install has *more* packages using this syntax, not less. Apache, init.d, apt (sources and preferences), logrotate, rsyslog, the list goes on and on. By all means, pound should be able to tell you the filename and the line where the parser goes awry. However, 0 files, 1 file, or 10 files, or a hundred files in a directory... doesn't matter. The point is the flexibility of using files for chunks of reusable configuration blocks and allowing the user to set their own convention. I can think of 3-4 different conventions that would be useful. Indeed, the one I use would be something like: /etc/pound/mainbackends.d/ (one file per backend) Which I can then include within several service definitions. If I want to disable a backend, rename the file from .conf to .disabled. The filename is clearly marked with the backend name. Simple, clear, easy to understand and use. And if for whatever reason that backend has multiple ports in different services (like mine do), having several folders is not a problem... merely use find or glob matching to rename the correct set of files. Given a NAT environment, one might have several listeners with global service definitions... but the port 80's should only have redirect services, so maybe global services aren't appropriate. No problem, drop your global service files into a directory, includedir them within your 443 listeners.. On your 80 listeners, include another directory with a file for your redirects. Simple, elegant. And then if you need a non-redirect service, it's merely add the file and all the 80 listeners get it. While I see the use case is more about having files that contain entire blocks (i.e. Listener, Service, Backend)... they don't have to. Sure, someone could put a file with invalid syntax in the folder. If they have access to the config. And to write the config. And restart pound. But if they do, they're an admin. So really, as Martin says... that's on them. With any great power comes great responsibility! It's up to the admin to define their convention. They'd have the power and flexibility to take to whatever makes most sense in their environment. Joe
