Hi Maxime,

On Tue, May 10, 2016 at 12:07:15AM +0200, Maxime de Roucy wrote:
> > > I'm not sure to like this feature in its current implementation.
> > > I fear it will also create some new issues depending on how people
> > > will use it.
> 
> Indeed it should be use with care.
> But for me it's as dangerous as the '--' option as '--' had clearly
> been implemented to be used with bash globling.
> However with '--' the sysadmin can filter himself the files list ; it
> can't with my patch.

That's exactly the point.

(...)
> > > Other use cases I immediately see :
> > > - some configurations provide the crt files in the same directory,
> > > which will break things
> > > - some others will store map files in the same directory also
> > > - what about configurations with a README or similar in the
> > > directory ? or swap files because someone else is editing a file at
> > > the same time ?
> 
> The last point is a very good one I think, swap files can easily be
> forgotten.
> The previous ones are more controversial for me as with my patch the
> directory itself become a configuration "file". If sysadmin put "trash"
> in it, it's the same as if he put "trash" in a configuration file??? it's
> not haproxy's fault if it fail.
>
> However, I agree that we should implement some safeguards.

User error can be addressed with good documentation, and stupidity with a
baseball bat. But we need to protect the user against issues he's not aware
of (swap files, backup files, core files if the editor dies, etc).

> > I think that before going further we should start by trying to
> > define what we want to see and what we don't want.
> >  Maybe a solution could be to at least impose a file name extension
> > (eg: .cfg), and I'm not sure it's enough. For example what should we
> > do with symlinks, some will prefer to follow them, others not to.
> > Most likely we should skip all dot files, etc.
> > I think the discussion should go on before we go further with the
> > code.
> 
> OK.
> 
> For me we should add a filter on file name ; keeping only ending with
> ".cfg" and not starting with ".".

I do think that it could be sufficient but I have not thought about it
for a long time, so I could be missing some cases.

> I vote for following symlinks, as the implementation currently does.
> It means less work for me :-) ??? Joking aside, I don't see any point
> against it and sysadmins will assume it does except if it's explicitly
> said in the docs (docs which I should complet regarding this point).

Yes I think you're right. Also it matches the output of "grep" when admins
search for something (eg: a domain name). And it allows to share some
elements between multiple directories if needed (eg: defaults sections).

Regards,
Willy


Reply via email to