While maintaining a lot of asterisk installations I've come to conclusion to split up a huge single package into smaller ones, like one package for one application, one package for codecs, one package for basic core functions (really minimalistic). It could be auto-generated from asterisk menuselect (short description for every application/functionality and dependencies). I've almost done the packaging for myself and definitly will use it, but it seems to me that such splitting will be useful for others too. It will simplify the asterisk maintance and help tracking problems, make /etc/asterisk look not so terrifying to a beginner, etc, etc. The minor drawback is a huge list of packages like asterisk-app-voicemail, asterisk-chan-sip, etc, in my aptitude screen, but it could not be avoided yet, and we have an examples for that, like openoffice.
164 164 2483
So I suggest you be more specific about what you want to move to
subpackages. Why would you want app_voicemail.so in a separate package?
What harm is it in this module lying around?
One valid reason would be dependency on external libraries: odbc, pgsql,
netsnmp, radius, sqlite. We have a separate asterisk-h323 .
На Sat, 5 Jan 2008 01:34:59 +0200 Tzafrir Cohen <tzafrir.cohen@xorcom.com> записано: What I've got so far: asterisk-adsi asterisk-ael asterisk-app-alarmreceiver asterisk-app-amd asterisk-app-core - here is included everything related to basic functionality, like: usr/lib/asterisk/modules/app_authenticate.so usr/lib/asterisk/modules/app_cdr.so usr/lib/asterisk/modules/app_chanisavail.so usr/lib/asterisk/modules/app_channelredirect.so usr/lib/asterisk/modules/app_chanspy.so usr/lib/asterisk/modules/app_controlplayback.so usr/lib/asterisk/modules/app_db.so usr/lib/asterisk/modules/app_dial.so usr/lib/asterisk/modules/app_dictate.so usr/lib/asterisk/modules/app_directed_pickup.so usr/lib/asterisk/modules/app_directory.so usr/lib/asterisk/modules/app_disa.so usr/lib/asterisk/modules/app_dumpchan.so usr/lib/asterisk/modules/app_echo.so usr/lib/asterisk/modules/app_exec.so usr/lib/asterisk/modules/app_externalivr.so usr/lib/asterisk/modules/app_flash.so usr/lib/asterisk/modules/app_forkcdr.so usr/lib/asterisk/modules/app_getcpeid.so usr/lib/asterisk/modules/app_ices.so usr/lib/asterisk/modules/app_image.so usr/lib/asterisk/modules/app_lookupblacklist.so usr/lib/asterisk/modules/app_lookupcidname.so usr/lib/asterisk/modules/app_macro.so usr/lib/asterisk/modules/app_milliwatt.so usr/lib/asterisk/modules/app_morsecode.so usr/lib/asterisk/modules/app_mp3.so usr/lib/asterisk/modules/app_nbscat.so usr/lib/asterisk/modules/app_page.so usr/lib/asterisk/modules/app_parkandannounce.so usr/lib/asterisk/modules/app_playback.so usr/lib/asterisk/modules/app_random.so usr/lib/asterisk/modules/app_readfile.so usr/lib/asterisk/modules/app_read.so usr/lib/asterisk/modules/app_realtime.so usr/lib/asterisk/modules/app_record.so usr/lib/asterisk/modules/app_sayunixtime.so usr/lib/asterisk/modules/app_senddtmf.so usr/lib/asterisk/modules/app_sendtext.so usr/lib/asterisk/modules/app_setcallerid.so usr/lib/asterisk/modules/app_setcdruserfield.so usr/lib/asterisk/modules/app_settransfercapability.so usr/lib/asterisk/modules/app_sms.so usr/lib/asterisk/modules/app_softhangup.so usr/lib/asterisk/modules/app_speech_utils.so usr/lib/asterisk/modules/app_stack.so usr/lib/asterisk/modules/app_system.so usr/lib/asterisk/modules/app_talkdetect.so usr/lib/asterisk/modules/app_test.so usr/lib/asterisk/modules/app_transfer.so usr/lib/asterisk/modules/app_url.so usr/lib/asterisk/modules/app_userevent.so usr/lib/asterisk/modules/app_verbose.so usr/lib/asterisk/modules/app_waitforring.so usr/lib/asterisk/modules/app_waitforsilence.so usr/lib/asterisk/modules/app_while.so usr/lib/asterisk/modules/app_pickup2.so asterisk-app-festival asterisk-app-followme asterisk-app-meetme asterisk-app-privacy asterisk-app-queue asterisk-app-voicemail asterisk-cdr-custom asterisk-cdr-manager asterisk-cdr-misc asterisk-cdr-tds asterisk-chan-alsa asterisk-chan-gtalk asterisk-chan-h323 asterisk-chan-iax asterisk-chan-mgcp asterisk-chan-oss asterisk-chan-phone asterisk-chan-sip asterisk-chan-skinny asterisk-chan-zap asterisk-codecs - here goes every codec supported by asterisk-conf-core - here goes basic configuration files, like: etc/asterisk/asterisk.conf etc/asterisk/cdr.conf etc/asterisk/extensions.conf etc/asterisk/features.conf etc/asterisk/indications.conf etc/asterisk/logger.conf etc/asterisk/manager.conf etc/asterisk/modules.conf etc/asterisk/rtp.conf etc/asterisk/say.conf etc/asterisk/udptl.conf etc/asterisk/users.conf asterisk-conf-crap - unused config files (there is no corresponed modules in /usr/lib/asterisk/modules/ by default): etc/asterisk/sla.conf etc/asterisk/vpb.conf etc/asterisk/rpt.conf etc/asterisk/osp.conf etc/asterisk/dnsmgr.conf asterisk-conf-misc asterisk-core - every module needed to make asterisk running asterisk-func-core asterisk-func-enum - special functions with config files asterisk-func-moh asterisk-odbc asterisk-pbx-core asterisk-pbx-dundi asterisk-pgsql asterisk-res-core asterisk-res-jabber asterisk-res-monitor asterisk-res-smdi asterisk-res-snmp asterisk-sounds-main asterisk-web-vmail So, it is way less than 164, only 48 so far. The general idea - every extra functionality goes to it own package, especially modules with it own config files, so I will be able to select via aptitude what exactly my asterisk is intended for. Just for example, I've never used mgcp, dundi, enum, jabber, snmp, smdi, odbc, sqlite, tds, chan_phone, chan_skinny, adsi, alarmreceiver, and definitly will never do. So what is the reason to keep loading unused modules into a production system ? Some of them spin out their own threads, some of them wants me to configure it. And I'd like to keep an asterisk installation lean and mean, with only functionality I've selected - so right now I'm forced to delete unused stuff, after each setup. And yes, here is yet another reason to separate, at least all stuff depended on externals, like pgsql, mysql, etc.
На Sat, 5 Jan 2008 05:32:25 +0500 jamhed <me@jamhed.pp.ru> записано: Even more, will it be better to pre-package modules not included in main asterisk tree as a separate sub-package, making it available without need of compilation ? Modules like app_pickup2, app_steal2, and may be others.
jamhed wrote: <snip> 48 packages is a bloat for no reason; think of all the overhead a package has both on users and on mirrors and think of all the maintainance burden. You can always disable autoload and load only the modules that you want to. You can leave them unconfigured or even remove the configuration files. With the current infrastructure you can even provide a configuration file package to not include these files *at all*. /usr/lib/asterisk/modules is ~5M. It may not be "lean and mean" but it's not exactly the opposite either. That is an actual reason. I've thought about it myself, splitting some modules to different packages to minimize the dependency chain. I'm leaving this open, because it's a valid request -for that last reason- that needs a little bit more though. Don't expect us to split asterisk to 48 packages though, there's no way this is going to happen ever. Thanks, Faidon
So just don't put config files. Why What functionality is "extra"? For me chan_zap is a rather core functionality and app_ices isn't. I can't easily know what functionality will be used. What overhead is there? Memory? Load time? Disk space (all the modules I have right now take less than 4MB)? If you really care, use a modules.conf that loads only the modules you really need.
На Sat, 05 Jan 2008 03:03:05 +0200 Faidon Liambotis <paravoid@debian.org> записано: Ok. May be there should be a configuration dialog with all possible modules, allowing me to check what modules are "active" ? While "passive" are kept in some other place, with their config respectivly. I've tried to remove unused config files, but it seems to me it is not the best solution so far - not every module refuses to load without config, some of them constantly logging an error, and there is no good to see many complaints at asterisk booting. Could we agree that keeping every module and it config in one place, and enablig it to autoload by default is just not the "right thing" ? For example, there are orphaned config files - just because there are too many of them to get it in one sight. It seems to me a better way is, if it is not possible to split-up everything to it own package with current infrastructure, to have: 1. modules with extra dependencies splitted to a separate packages, just like you suggested 2. a configure dialog script allowing to select what modules are "on" and "off", just like apache do. even more, asterisk menuselect allows user to select what application to have installed, but with current packaging scheme this functionality is lost.
На Sat, 5 Jan 2008 03:10:21 +0200 Tzafrir Cohen <tzafrir.cohen@xorcom.com> записано: In other hand, you can easily know what will be not, right ? Yes, but it is not convinient, by default. There is no list of available modules in that file, some modules depends on other, it requires me as user to get an extra knowledge.
Roman Galeyev <me@jamhed.pp.ru> wrote: I totally fail to see how it's going to help with maintenance. Quite the contrary, it's going to complexify the build scripts for no good reason, add a bunch of packages to the control file and their relationships, bloat the Packages file for no good reason, confuse users and risk having version skew between packages. That doesn't buy anything, you've just had a false good idea. JB.
На Sat, 05 Jan 2008 11:10:05 +0100 Julien BLACHE <jblache@debian.org> записано: May be idea is not so false but implementation ;) Think of a modules configuration script, like apache. It will allow to achieve the same thing.
jamhed wrote: Come on, adding single lines to one configuration file asking to "load" (or "noload", in case of autoloading) modules can't be _that_ hard, for anyone -- at least for anyone trying to configure Asterisk. It sure isn't harder than installing a dozen packages just to achieve basic PBX functionality. Again, I'm open to a split that would be done for dependency reasons, just like asterisk-h323 is splitted. Maybe odbc, maybe postgres, not sure yet. Splittting to 50 (or 40, or 30, or...) packages for "maintainance" reasons: over my dead body :-) Just trying to be clear here, there's no point of discussing this further. Regards, Faidon
На Sat, 05 Jan 2008 16:13:21 +0200 Faidon Liambotis <paravoid@debian.org> записано: Ok, I've agreed with everybody that splitting to 50 subpackages is not so good, and the only reason to split is a dependency. But it will be nice to have a dialog-script allowing to select what modules are active, just like "dpkg-reconfigure apache" do. How's about that ?
You'll find a good example of this in the apache2 packages, which have /etc/apache2/mods-available and /etc/apache2/mods-enabled. Some people love it, some people hate it. Ciao, Sheldon.
Sheldon Hearn <sheldonh@clue.co.za> wrote: Diverging from upstream in this area is not an option for obvious reasons. So I suggest you take that up with upstream. Good luck. JB.
Julien BLACHE <jblache@debian.org> writes: I am curious what these obvious reasons are. To the best of my knowledge the (mods|site)-(available|enabled) system that Apache uses is something in Debian that has diverged from upstream. At least insofar as their configuration doesn't use it by default. The ability via the include directive is, of course, part of upstream. Matthew
tag 459244 + wontfix thanks Matthew King wrote: What's the point? Modules are enabled/disabled in modules.conf. Each module has a separate configuration file. How easier can it get? Apache is quite different FWIW. Regards, Faidon
Faidon Liambotis <paravoid@debian.org> writes: To easily, and introducing no/very few errors, enable and disable [un]wanted modules. In this case, Apache is the same. There used to be a list of modules to load in the main configuration file [or in modules.conf depending on how far back you look], this list is now split up into one module per .load file[1]. Where necessary there is a corresponding .conf which *is* different to Asterisk's approach but this difference is negligible[2]. 'a2enmod something && apache2ctl graceful' is far easier than: edit /etc/apache2/modules.conf Find the module you wish to use and uncomment the necessary line. If it's not present, add it ensuring you get the syntax and fs path correct. apache2 -t # Ensure the configuration is not broken apache2ctl graceful Note that not only is the latter, which is identical to the current method employed by Asterisk, 2 [and a half] extra steps, but one is a manual process with which it is possible to make a mistake. Matthew [1] I can't remember how dependant modules are dealt with. Either there's some extra magic in the a2(en|dis)mod scripts or each .load file lists all dependant modules and any resultant duplicates are ignored. [2] That is to say, the .conf equivalent can be in /etc/asterisk while the .loads are in /etc/asterisk/modules-(available|enabled). If the module is not loaded the respective configuration file will simply be ignored. In Apache the many small files are effectively concatenated when the configuration is loaded.
Impression qualité photo Banderole Banderole Éco laminÉe PVC souple 450 gr Impression Éco solvant. <http://www.banderole-eco.com/promo-banderole-de-communication> <http://www.banderole-eco.com/promo-banderole-de-communication> <http://www.banderole-eco.com/promo-banderole-de-communication> <http://www.banderole-eco.com/promo-banderole-de-communication> Applications : Les différents types de banderole personnalisée (ou banderole numérique) qui existent, répondent chacun à un support publicitaire spécifique. Qu'il s'agisse d'un évènement ponctuel, d'une promotion exceptionnelle ou encore d'un anniversaire, la banderole numérique offre un moyen de communication très visuel et économique. <http://www.banderole-eco.com/promo-banderole-de-communication> Si vous ne disposer pas de maquette la creation a 19.90 € (Photo et texte fournis par le client)
Utilisez les MAGNÉTIQUES et démarquez vous de la concurrence Les magnétiques sont prévus pour un montage provisoire sur une surface métallique <http://www.banderole-eco.com/promo-banderole-de-communication> <http://www.banderole-eco.com/promo-banderole-de-communication> Taille 40 * 60 58,00 €* kit 4u Taille 40 * 80 77,00 €* kit 4u Taille 120 * 60 72,00 €* kit 2u Applications : Le magnétique publicitaire est une plaque de caoutchouc de moins de 2 mm d'épaisseur flexible aimanté sur lequel on imprime directement en qualité photographique haute résolution (1080 dpi) la maquette souhaitée avec une encre UV qui résiste au soleil et aux intempéries. Le magnétique publicitaire est un support personnalisable, souple et résistant pour intérieur et extérieur, qui est repositionnable indéfiniment sur tout vos support métallique et ne détériore pas ni ne laisse de marque sur la surface où il est installé. Il faut simplement repositionner le magnétique au moins une fois par semaine afin de nettoyer le support et éviter ainsi l'accumulation d'humidité qui pourrait abimer la superficie qui reçoit le magnétique, surtout en extérieur. <http://www.banderole-eco.com/promo-banderole-de-communication> Si vous ne disposer pas de maquette la creation a 19.9 € (Photo et texte fournis par le client)
Promo Support événementiel Un moyen économique pour présenter vos produits auprès de vos clients Chat en ligne à votre service sur notre site <http://www.banderole-eco.com/promo-de-kakemono-enrouleur> <http://www.banderole-eco.com/promo-de-kakemono-enrouleur> <http://www.banderole-eco.com/promo-de-kakemono-enrouleur> Si vous ne disposer pas de maquette la creation a 19.90 € (Photo et texte fournis par le client) * Embalage et transport non inclus Promotion valable jusqu'au 31 aout Chat en ligne à votre service sur notre site