The G.729 is a proprietary voice codec that is used by many (most?) carriers. For this reason this asterisk module is shipped separately from asterisk itself. The ebuild I'm about to submit is non-final, but I submit it anyway in order to get wider testing and feedback. The remaining issue that needs to be sorted out is variant selection (becomes an issue high call concurrency), probably by use of the benchg729 tool. There is a licensing problem with running this tool, which means you can't run the benchmark tool until you've installed a valid license. I've requested from Digium whether they can provide us a version of the tool that is not encumbered by this issue, failing that the alternative suggestion would be to: 1. If benchg729 fails to execute use generic. 2. If benchg729 does pick a variant use that variant. This is probably a good idea anyway, the downside is that it would require a remerge (In the case of 1 I can always add another notice to postinst) under "normal" operation (first merge gets you -generic, second and successive merges get you optimized variant). Also, whilst I'm submitting the ebuild for the matching codec for ast 1.6.2.X simply renaming it the following versions will obtain working ebuilds for asterisk 1.4, 1.6.0 and asterisk 1.6.1 respectively. -1.4.3.1.4 -1.6.0.3.1.4 -1.6.1.3.1.4 I will also upload a Digium license file, which is the LICENSE file contained inside the .tar.gz for the codec itself. Reproducible: Always Steps to Reproduce:
Created attachment 243415 [details] Digium License file (simple rename of LICENSE file inside .tar.gz archive).
Created attachment 243417 [details] asterisk-g729-1.6.2.0.3.1.4.ebuild
Also please confirm package naming, it's simple enough to rename this to codec_g729a instead of asterisk-g729, I went with the latter as this is purely an asterisk add-on and will not function with any other software. Perhaps asterisk-codec_g729a is another option.
Hi, I received the following reply from Digium when I posed the question of whether we can possibly get a version of benchg729 that doesn't require a license to already be installed: Because benchg729 includes a G.729 encoder, it will always require a license. This is stipulated by the G.729 Consortium (the patent holder), so there's not much we can do about this. Perhaps the documentation for installing our G.729 implementation in Gentoo should include a link to the register utility and have instructions for using it, before benchg729 is installed. Let me know if you have any further questions about this. This is about as useful as saying "put a license card inside a box stating that if you opened the box you accept the license terms" imho. My suggestion then remains to attempt running the benchg729 tool, if that makes a positive selection, use that variant. If it doesn't, use generic but also add a message to postinst to this effect. Then also, does it make sense to allow the user some override mechanism for the variant to be used, or possibly replacement for the auto-detection? I know apache has a USE_EXPAND variable that allows the user to select only a single option. I don't like the idea of adding yet more of these variables and further complicating the install of this but I don't really see any other way.
Created attachment 243443 [details] asterisk-g729-1.6.2.0.3.1.4.ebuild Will now (permitting you already have a G.729 license installed) select a flavor of the codec more suited for your machine. If the generic version is installed it will output the additional einfo: * You are using the generic flavor of the codec, in order to install a more appropriate one please install a G.729 license and remerge this package (asterisk-g729). In addition to: * Please note that Digium's register utility has been installed as astregister The last thing which I think needs to (if possible) be sorted out is this QA warning: * QA Notice: The following files contain writable and executable sections * Files with such sections will not work properly (or at all!) on some * architectures/operating systems. A bug should be filed at * http://bugs.gentoo.org/ to make sure the issue is fixed. * For more information, see http://hardened.gentoo.org/gnu-stack.xml * Please include the following list of files in your report: * Note: Bugs should be filed for the respective maintainers * of the package in question and not hardened@g.o. * RWX --- --- usr/sbin/benchg729 * RWX --- --- usr/sbin/asthostid * RWX --- --- usr/sbin/astregister This is in my opinion potentially a problem, albeit I can't run hardened anyway for other reasons.
(In reply to comment #5) > This is in my opinion potentially a problem, albeit I can't run hardened anyway > for other reasons. It will likely necessitate the following on a Hardened Gentoo system: paxctl -m /usr/sbin/asterisk That's certainly the case with the binaries at http://asterisk.hosting.lv. This could be the subject of an ewarn I suppose.
(In reply to comment #6) > (In reply to comment #5) > > This is in my opinion potentially a problem, albeit I can't run hardened anyway > > for other reasons. > > It will likely necessitate the following on a Hardened Gentoo system: > > paxctl -m /usr/sbin/asterisk > > That's certainly the case with the binaries at http://asterisk.hosting.lv. This > could be the subject of an ewarn I suppose. Ok, paxctl isn't installed on all systems, so I think what you're saying is that we need to just issue an ewarn in postinst that should you be using a hardened system you will need to run paxctl -m /usr/sbin/{benchg729,astregister,asthostid} ?
(In reply to comment #7) > Ok, paxctl isn't installed on all systems, so I think what you're saying is > that we need to just issue an ewarn in postinst that should you be using a > hardened system you will need to run paxctl -m > /usr/sbin/{benchg729,astregister,asthostid} ? Actually, that could be done by inheriting pax-utils and invoking "pax-mark m" in the ebuild (there's even a list-paxables() function). Back to the original point, it's plausible that the g729 module would crash asterisk on a hardened system (just as Arkadi Shishlov's does). In this case, regrettably, there is no solution that I'm aware of other than to excempt asterisk from MEMPROTECT. That said, I ought to put Digium's instance to the test as opposed to merely speculating!
(In reply to comment #8) > Back to the original point, it's plausible that the g729 module would crash > asterisk on a hardened system (just as Arkadi Shishlov's does). In this case, > regrettably, there is no solution that I'm aware of other than to excempt > asterisk from MEMPROTECT. That said, I ought to put Digium's instance to the > test as opposed to merely speculating! Will, there is two aspects here: 1. The module itself 2. The three command line utilities Based on the QA warning I'm guessing that a PaX enabled/hardened system won't even bother trying to execute these programs (2). Would you please be so kind as to test (1) for me - I don't have a hardened system at hand to test with. In the meantime I'll look into how that pax-utils eclass functions.
Is it really this simple? --- a/net-misc/asterisk-g729/asterisk-g729-1.6.2.0.3.1.4.ebuild +++ b/net-misc/asterisk-g729/asterisk-g729-1.6.2.0.3.1.4.ebuild @@ -4,7 +4,7 @@ EAPI="2" -inherit versionator +inherit versionator pax-utils DESCRIPTION="G.729 codec and supporting files for asterisk" HOMEPAGE="http://store.digium.com/productview.php?product_code=G729CODEC" @@ -123,6 +123,8 @@ src_install() { dodoc codec_g729a-${MY_PV}-${variant}_${size}/README insinto /usr/lib/asterisk/modules/ doins codec_g729a-${MY_PV}-${variant}_${size}/codec_g729a.so + + pax-mark -m "${D}"/usr/sbin/{astregister,asthostid,benchg729} "${D}"/usr/lib/asterisk/modules/codec_g729a.so } pkg_postinst() { Results in: * Fallback PaX marking -m * /var/tmp/portage/net-misc/asterisk-g729-1.6.2.0.3.1.4/image//usr/sbin/astregister * /var/tmp/portage/net-misc/asterisk-g729-1.6.2.0.3.1.4/image//usr/sbin/asthostid * /var/tmp/portage/net-misc/asterisk-g729-1.6.2.0.3.1.4/image//usr/sbin/benchg729 * /var/tmp/portage/net-misc/asterisk-g729-1.6.2.0.3.1.4/image//usr/lib/asterisk/modules/codec_g729a.so (Obviously I don't have paxctl installed). If the above is in fact correct I'll upload a new ebuild file, just would prefer is someone can first confirm.
Kerin - thanks for confirming use of pax-utils - can you confirm whether this is required for the .so as well please? I'd highly prefer if asterisk can run with that protection switched on...
After the previous reply to my email to digium, I replied with: > Was hoping to install the whole lot as a single package. Second best > option is to default to "generic" if benchg729 fails, thanks, I'll use > the above as a double-merge motivation. Keep in mind that the purpose > of putting this in package management is to install everything the user > needs in a single go (including the register utility) as part of initial > install, and to just allow installing the license (via register utility) > at a later stage. To which they responded with: Our G.729 implementation is useless without a valid license. You could probably execute the register utility as part of the G.729 install process, similar to the way Oracle requires agreement to the Java license when that implementation is installed. You may want to have as part of the install instructions, or even add a disclaimer which the user must acknowledge before G.729 is installed. ... Needless to say I don't like that solution at all as it blocks the merge until user input is obtained. Something I'm: a) not comfortable with due to the fact that I feel that no merge should ever block (I like kicking off merges and going to bed). b) is most likely against portage policy anyway (and if it's not it imho should be). I suspect the current solution is the best we're going to manage within the constraints of portage. Or we need some env var (also something I don't like, we've just ripped some of that kind of junk out of asterisk ebuild the other day) or a USE_EXPAND variable (something against which there is also objections) to pre-empt auto-detection. None of these solutions are ideal IMHO, the USE_EXPAND is probably the least damaging one.
Created attachment 244297 [details] collect-g729-stats As per IRC discussion, we don't like being locked down to having to use the bench tool. So instead we want to try and collect some data that will allow us (me) to collect some timing statistics on different CPUs and flavors. This script will submit this data (as anonymously as I could make it) to one of my servers from where we can process it. I'll make the results publicly available as per the short disclaimer in the script (also displayed when running). Anybody and everybody that is willing to run this on their g729 enabled systems, please do so. I'll probably run it on a quite few systems myself, but the more data we can get, the better. I'll work on actually aggregating the data over the next few days, but it will be available on http://g729.uls.co.za/. The idea is that we'll be able to use the vendor along with the cpu family and model numbers to pick the best codec once we have sufficient data. I'll probably cook up a script (with the help of Tony) that will be able to perform this selection, and issue an ewarn if we don't have correct data. Note that whilst the bench tool already runs 5 tests I still find that it's not really sufficient, I have no clue how digium measures the time (probably subtraction of gettimeofday() values instead of using rusage(2) ... go figure), and the public api for codec_g729.so isn't well-known so I can't rewrite this tool easily either (at least, not legally without some reverse engineering with objdump).
FYI: http://g729.uls.co.za/table/
Tony - what would you require from me in order to merge this?
Created attachment 279807 [details] asterisk-g729-1.8.4.3.1.5.ebuild Updated ebuild to deal with asterisk 1.8. Can also deal with 1.6 with a simple rename.
Created attachment 279907 [details] asterisk-g729-1.8.4.3.1.5.ebuild Tony, Looked through the source again. If (and only if) the guy that installs already has a license the ebuild will currently use benchg729 to check for what that tool considers to be the "best" flavor. This is what we intend to change. The updated ebuild also installs my collect-g729-stats.sh script and prods people to actually run it. Mostly people merging this won't have licenses yet and as such will end up getting the generic variant. Is this acceptable for starters?
Created attachment 285357 [details] new ebuild Port to EAPI4, hide QA notice and added die when necessary
+*asterisk-g729-1.8.4.3.1.5 (02 Sep 2011) + + 02 Sep 2011; Tony Vroon <chainsaw@gentoo.org> + +asterisk-g729-1.8.4.3.1.5.ebuild, +metadata.xml: + Initial commit. Ebuild by Jaco Kroon, subsequently ported to EAPI 4 and + further improved by Agostino "ago" Sarubbo. Closes bug #33277.
