The default /etc/asterisk/asterisk.conf contains:

    astagidir => /usr/share/asterisk/agi-bin

The upstream default is /var/lib/asterisk/agi-bin - this directory can
potentially contain locally created scripts (or binaries) to control
dialplans, and should be under /var so that the administrator is free to
drop executables in there.

[asterisk-app-fax has changed its behaviour to install a script at
/usr/share/asterisk/agi-bin/receive_fax (see #394051) - it should probably
either undo that move, or install a symlink into /var/lib/asterisk/agi-bin.]

agi-bin is modeled after cgi-bin directory of an HTTP daemon, which
resides with Debian under /usr/lib/cgi-bin . It's under /usr as it is
intended for programs and libraries.

If you want to add your own agi script, you can still put it there in
your local system.

You should put stuff under /var if they are to be modified at system
runtime.

The executables should be shipped under /usr/lib or /usr/share in the
Debian packages, I agree.

I think we must disagree here - the FHS would advise administrators to
place their scripts under, say, /usr/local/lib/asterisk/agi-bin.

I do not think site administrators should be modifying anything
under /usr directly - it is possible that it is mounted read-only:
http://www.debian.org/doc/manuals/securing-debian-howto/ch4.en.html#s4.9.2

Since I assume we can only configure one location as the agi-bin
directory, one approach would be for the Debian packages shipping AGI
scripts to install symlinks into /var/lib/asterisk/agi-bin. Then the
system administrator can also put symlinks in there.

This also has the benefit of retaining some compatibility with
upstream's location.

Just as you need to mount it read/write to install extra packages, you
need to mount it read/write to install local scripts. As with cgi-bin -
you can't easily have more than one directory, and it must also be used
for scripts installed by packages.

Upstream is incompatible with FHS. A symlink there might cause
confusion.

Can you give me a simple scenario where this actually helps? I'd hate
complicating things for nothing.

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.)

Moving the directory altogether is potentially more confusing. For some
anecdotal evidence, see:
http://blog.andrew.net.au/2006/10/19#AGI_in_the_wrong_directory

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


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

[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.]

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


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).

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:
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.
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.
Agreed so far.
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.)
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.
That is a stretch and totally incorrect, sorry.
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

There can be site-specific software that is not host-specific, so
third-party Perl modules would still belong in /usr/local.

Well, I agree that it's not clear-cut, so I wanted to have a discussion
before landing an RC bug on you. ;) After all, the asterisk package
isn't installing anything in non-FHS directories itself.

But symlinks in /var/lib would not be unprecedented; I can think, for
example, of the typo3-dummy package (for configuring a web app), which
puts a whole hierarchy of files and symlinks in /var/lib/typo3-dummy.
There must be more.

I seem to recall the policy manual suggests asking the debian-devel
mailing list for advice on complicated FHS issues.

Yes, ideally we would add this support - but would it not involve
changing the format of the config file, and creating even more
incompatibilities with upstream?

At least until upstream change this themselves, I suspect it might be
nicer just to use some symlinks.

Tim Retout wrote:
Exactly; there can be site-specific AGIs that are not host-specific
(been there, done that). If you think about it a bit, there's not much
of a difference.
HylaFAX does something like that. It's ugly as hell :-)
tomcat has a bunch of symlinks and it's not that bad.

I'd prefer it if it was our last option though.
It might. Not sure yet.
I'll try to discuss this with upstream.

Regards,
Faidon