Bug#462270: asterisk: agi-bin directory is intended for local scripts, and should be under /var

[Faidon Liambotis]

First of all, let's all agree that this is not a clear cut case.

We definitely have a bug here, aside from this discussion, and this is 
that we don't ship the agi-bin directory even though we referenced this.
Sadly, Andew Pollock didn't report this as a bug when he found it.

Tim Retout wrote:
> With web servers such as Apache, it is generally possible for the
> administrator to configure other cgi-bin directories at different
> locations. Administrators do not have to put their custom CGI scripts
> in /usr/lib/cgi-bin.
> 
> Asterisk can have only one agi-bin directory, so I do not think this is
> comparable. (Hardcoding the full path in extensions.conf is not really
> the same.)
This is the whole point of this discussion.

We're trying to find a single path that will fulfill different needs 
(shipping AGIs from packages AND provide a way to install site-local AGIs).
It is an upstream bug that has hit us many times before -- we had to do 
a symlink workaround recently for the location of the sounds.

>>> This also has the benefit of retaining some compatibility with
>>> upstream's location.
>> Upstream is incompatible with FHS. A symlink there might cause
>> confusion.
I have to agree with Tzafrir here on both points:
a) upstream is known for not caring less about the FHS
b) afaict, we are going to need symlinks for each and every package or 
provide scripts that do that. Not really a solution.

> I am mostly thinking about administrators writing custom AGI scripts,
> and wanting to have them included in the agi-bin directory. They could
> have different scripts on each host.
> 
> If they put their custom scripts into /usr/share/asterisk/agi-bin, then
> the scripts may be overwritten by system upgrades; there is no guarantee
> that a Debian package might not accidentally choose the same name as one
> of the local scripts. See footnote [27] of FHS 2.3:
> http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1450
Agreed so far.

> Requiring administrators to add their own host-specific scripts
> under /usr also goes against the FHS (and therefore Debian Policy); the
> intention of the /usr hierarchy is that it is "shareable, read-only
> data" that is not host-specific - it could potentially be shared between
> different machines:
> http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
Well, I don't exactly agree to the "host-specific scripts".
If we go down this road, then the whole /usr/local should go away
(think of perl, python etc.)

> [Technically, site admins should perhaps be using somewhere under /srv
> for host-specific scripts, not /usr/local:
> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
> ...but it looks like it would be unwise for packages to install anything
> there themselves.]
Not only we cannot put stuff in /srv (not even subdirectories, unlike 
/usr/local) but we cannot even make assumptions that something may 
reside there.

> I believe symlinks in /var/lib/asterisk/agi-bin can be considered state
> information of the system (i.e. the set of currently available AGI
> scripts on this host) and fits the FHS criteria:
> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION
That is a stretch and totally incorrect, sorry.

> So, I hope this isn't just making things more complicated for nothing -
> it could be interpreted as a violation of a "must" directive in Debian
> Policy (section 9.1.1).
That may be a legitimate bug but it's hardly a policy violation.
I presume you agree, since you didn't file it as "serious", even though 
you are aware of our procedures.

All in all, I believe that we may have to support multiple directories 
(i.e. also supporting /usr/local) and the only way I can see for doing 
that is by modifying asterisk's source.

I'll have a look and try to produce a not very crude hack to do that.

I will also try to move this discussion with upstream -- may be we can 
agree on a proper solution.

Thanks,
Faidon