On 09/21/2011 11:43 AM, Thomas Goirand wrote:
On 09/21/2011 12:49 PM, Daniel Kauffman wrote:
... for serving Adobe socket policy files.
What's that? How do you make them?
Adobe Flash Player (since version 9.0.124.0) will not open a socket
connection to a server unless the server first authorizes the connection
via an Adobe socket policy. This module serves these policies. (Adobe
uses a non-standard protocol for serving these policies, hence the
existence of this module.)
Adobe socket policies are configured using XML. A selection of
pre-configured socket policies are available in:
/usr/share/libapache2-mod-socket-policy-server/socket-policy/
And more information about socket policies in particular, and cross
domain policies in general, is available from the Adobe Cross Domain
Policy File Specification:
https://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
Other useful links discussing Adobe socket policies:
https://www.adobe.com/devnet/flashplayer/articles/socket_policy_files.html
https://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html
The package is ready for sponsorship and can be downloaded from:
http://socketpolicyserver.com
The updated package is ready for download.
1/ The package is a native package, which isn't required for an Apache
module IMO. Please read about it in the Debian policy manual.
There is no upstream, so it seemed appropriate to create a native
package... is that incorrect? I didn't see a reference to quilt in the
Debian Policy Manual and the Debian New Maintainers' Guide section 2.9
seems to suggest that a native package is ok where there is no upstream.
The native format seems a little simpler. But if I'm missing something,
and the quilt format is preferable, I can switch to that.
2/ The package has apache2-threaded-dev as Build-Depends, any reason
why it wouldn't work with apache2-prefork-dev also? Also, having a
binary package with "apache2 | apache2-mpm" seems strange to me.
I agree, both of those seemed a little odd to me as well. I had
referenced the instructions on:
http://wiki.debian.org/Apache/PackagingModules
And it seems that building against the threaded headers results in a
module that works with both threaded and non-threaded versions of
apache2. In my case, I built the module against apache2-threaded-dev and
have no issues running the module with either apache2-mpm-worker or
apache2-mpm-prefork.
The binary dependency on "apache2 | apache2-mpm" was from those same
instructions. Some apache2 modules use this construct, and some don't.
All four of the apache2-mpm-* packages provide both names. I'm not sure
what the reasoning is behind this, though it is interesting that apache2
is a package and apache2-mpm is a virtual package. Perhaps this is some
sort of historical artifact?
3/ It'd be nice to use the DEP5 format for debian/copyright. Please see
http://dep.debian.net/deps/dep5/. It's still a candidate, so it's not a
requirement though.
Updated, no problem.
4/ Your Standards-Version: isn't up-to-date. Did you build the package
in SID and ran lintian there?
Reviewed checklist and updated Standards-Version. Re-built using
pbuilder sid and checked using lintian from backports. No issues.
I: libapache2-mod-socket-policy-server:
extended-description-is-probably-too-short
You don't need the last dot at the end, but you do need a longer
extended description. Lintian complains with less than 2 lines,
but I think at least 10 lines sounds reasonable. By reading what
you wrote, I still don't understand what your package is doing. :)
The description is now longer. Hopefully, it is also more descriptive. :-)
5/ Your debian/README explains how to use apt-get, that we can
edit the config file of the module, and how to restart apache. I
don't think you should do that, it's not helpful, but there might
be other things you want to document (like what to put in the
socket policy file for example?).
I updated the README to be a duplicate of the (new) description from the
control file (including links describing the socket policy file format),
plus a description of the configuration directives and a description of
how to test that the module is configured as expected. Anything else
come to mind that might be helpful here?
6/ Your package configures a VirtualHost in a /etc/apache2/conf.d
file, don't you think it would be nicer in /etc/apache2/sites-available?
If not, please explain here why.
True, VirtualHost doesn't really belong there. Not sure how I missed
that. However, instead of moving the configuration, I removed the
VirtualHost declaration, so that the default configuration is now a
global configuration. None of the apache2 modules in the repository
touch /etc/apache2/sites-available -- IMO the sites-available directory
is more appropriate for something like a web application.
I hope the above helps,
It does, thank you.
Thanks for your will to contribute to Debian,
Thomas
Thanks, I'm glad to be able to contribute to the community.
--
Daniel Kauffman
Lead Developer
Rock Solid Solutions, LLC
877.239.9195 toll-free
208.699.9699 mobile
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e7ae47f.7050...@rocksolidsolutions.org
