Notes and observations on PiaF 64 bit Bronze install

[jroper]

Dear Tom and Ward

I've been asked to redo my script to install PiaF on an existing CentOS installation, and have picked up on some oddities while installing 1.7.5.5.3

Samba Issues

During the install - yum stage one install, we get some samba errors as noted in the install log:-

Error: samba3x-swat conflicts with samba-swat
Error: samba3x conflicts with samba
Error: samba3x-client conflicts with samba
Error: samba3x conflicts with samba-common
Error: samba3x-doc conflicts with samba
Error: samba3x-common conflicts with samba-client
Error: samba3x-common conflicts with samba
Error: samba3x-winbind conflicts with samba-common
Error: samba3x conflicts with samba-client
Error: samba3x-client conflicts with samba-client
Error: samba3x-common conflicts with samba-common
 You could try using --skip-broken to work around the problem
 You could try running: package-cleanup --problems
                        package-cleanup --dupes
                        rpm -Va --nofiles --nodigest

This may mean that your intended action of yum stage one may not work.

Packages and dependency issues on the ISO


In order to check out the problem with Samba, I checked to ensure that all the packages were in order on the ISO with all dependencies satisfied, so I downloaded both the 64 bit and 32 bit, and checked them with rpm --test --dbpath

The 32 bit version threw these errors, which suggest that either you have packages on there which do not need to be there, or dependencies that should be there that are not.

error: Failed dependencies:
        poppler-utils is needed by cups-1.3.7-18.el5_5.7.i386
        perl(Digest::SHA) is needed by perl-Net-DNS-0.66-1.el5.rf.i386
        samba-common = 0:3.0.33-3.29.el5_5 is needed by samba-3.0.33-3.29.el5_5.i386
        libsmbclient is needed by samba3x-common-3.3.8-0.52.el5_5.i386
        libtalloc >= 1.2.0-52.el5_5 is needed by samba3x-common-3.3.8-0.52.el5_5.i386
        libtalloc.so.1 is needed by samba3x-common-3.3.8-0.52.el5_5.i386
        libtdb >= 1.1.2-52.el5_5 is needed by samba3x-common-3.3.8-0.52.el5_5.i386
        libtdb.so.1 is needed by samba3x-common-3.3.8-0.52.el5_5.i386
        libwbclient.so.0 is needed by samba3x-common-3.3.8-0.52.el5_5.i386
        samba3x-winbind = 0:3.3.8-0.52.el5_5 is needed by samba3x-common-3.3.8-0.52.el5_5.i386
        samba conflicts with samba3x-common-3.3.8-0.52.el5_5.i386
        perl(Crypt::PasswdMD5) is needed by syslinux-3.86-1.el5.rf.i386
        xorg-x11-drv-qxl is needed by xorg-x11-drivers-7.1-4.2.el5.i386

You will note that Samba is one of the failed dependencies.

The 64 bit is a little more verbose than that, so I have not included it here.

I'm afraid I don't know which Samba versions you need or want on the system, so I'm afraid I cannot make a recommendation here. However, there is a methodology to ensure that you only have the packages you need on the ISO, and the dependencies are fulfilled.

Roll the perfect ISO


The way to cure this issue when you are rolling up the ISO, and deciding which packages are going to go on, is simply to build a golden image of exactly what you need in terms of packages, do it for both the 64 bit and the 32 bit. When you are happy that you have the perfect PIAF system, with only the packages you need, and everything works as it should, install yum-utils and run the command:-

yum list installed > yumlist.txt

This will give you a list of all the installed packages in the text file, yumlist.txt, which you can then turn into a line like:-

yumdownloader --destdir=/root/createISO/cd1/pbx/ lots of packages blah blah

This will go and get only the packages that you need that are going to go on the ISO. When you come to roll up the ISO, there should be no errors and no missing dependencies, and you will only have on the ISO exactly what is going to be installed, with no packages that are not used, so it will be as small as it possibly can be.

Inspect my "Create Updated ISO" for more tips on how this works.

RPMForge ?


I also noticed during the install that the rpmforge repository was installed, however it was left enabled - is that wise? Some of the packages in there can be a little bleeding edge.

I would say that it would be better that any packages and updates should come first from the centos repository, and only from rpm-forge when there is no alternative.

If you disable the repository, and then when you need a package from it, you can simply use the line:-

yum --enablerepo=rpmforge install blah blah

So that say running "update source" does not bring down all the scary hairy bleeding edge stuff.

Installing FreePBX modules from the command line


I also notice that there was a fairly large file brought down called freepbx16base.tgz, which appeared to contain and install a number of FreePBX modules.

Of course, you can do it this way, but you do have to keep this file updated, and re-create it at intervals, and I am sure you have a script for it, but it is one more thing to maintain and generate.

But it is pretty simple to do in the install script using FreePBX's tools designed for this purpose, and will work across many versions of FreePBX without ever having to be touched again.

/var/lib/asterisk/bin/module_admin download asterisk-cli
/var/lib/asterisk/bin/module_admin download asteriskinfo 
/var/lib/asterisk/bin/module_admin download backup 
/var/lib/asterisk/bin/module_admin download fw_ari
/var/lib/asterisk/bin/module_admin download fw_fop
/var/lib/asterisk/bin/module_admin download iaxsettings 
/var/lib/asterisk/bin/module_admin download javassh 
/var/lib/asterisk/bin/module_admin download languages 
/var/lib/asterisk/bin/module_admin download logfiles 
/var/lib/asterisk/bin/module_admin download phpinfo 
/var/lib/asterisk/bin/module_admin download sipsettings 
/var/lib/asterisk/bin/module_admin download weakpasswords 
/var/lib/asterisk/bin/module_admin download fw_langpacks
/var/lib/asterisk/bin/module_admin install asterisk-cli
/var/lib/asterisk/bin/module_admin install asteriskinfo 
/var/lib/asterisk/bin/module_admin install backup 
/var/lib/asterisk/bin/module_admin install fw_ari
/var/lib/asterisk/bin/module_admin install fw_fop
/var/lib/asterisk/bin/module_admin install iaxsettings 
/var/lib/asterisk/bin/module_admin install javassh 
/var/lib/asterisk/bin/module_admin install languages 
/var/lib/asterisk/bin/module_admin install logfiles 
/var/lib/asterisk/bin/module_admin install phpinfo 
/var/lib/asterisk/bin/module_admin install sipsettings 
/var/lib/asterisk/bin/module_admin install weakpasswords 
/var/lib/asterisk/bin/module_admin install fw_langpacks

/var/lib/asterisk/bin/module_admin reload

The above commands will bring down the current up to date modules as listed for the version of FreePBX that is installed from the FreePBX repository. Simply add or remove what is required.

The last line does a reload.

This approach saves your bandwidth as well.

Yours

Joe

 

[dswartz]

Joe speaking of repos, a comment I made some time back that was not replied to: my understanding is that CentOS best practices is if you have any non-standard repos, you should install yum-priorities and set those repos to be lower priority.

 

[jroper]

Hi

Yes, I would agree that this would be a sound and alternative approach, however, we tend to use rpmforge and others for stuff that simply is not available on the centos repositories, so often it is simply necessary to grab one package, and not go near it again, so I would favour the "Only access it if you absoutely need to" approach.

Joe

 

[wardmundy]

Thanks, Joe. You've made some very good points, and we're always looking for ways to build a better mousetrap.

The only one that gives me pause is the FreePBX utility which looks neat but is totally undocumented. I'm assuming you learned about it when your former company paid FreePBX to do a custom build for your distribution. In fact, the only documentation seems to be in a trouble ticket. So... the question arises whether we'd really want to depend upon it to get things properly loaded and activated now and in the future.

 

[jroper]

Hi

I can't remember where I learned about it - not that it is relevant, I just had a problem to solve, and this does the job.

typing

/var/lib/asterisk/bin/module_admin --help

As you might with any other program, help, gives you all the documentation you need.

root@pbx:~ $ /var/lib/asterisk/bin/module_admin --help

USAGE:
  /var/lib/asterisk/bin/module_admin [params] <operation> <module> [parameters.. ]
PARAMETERS:
  -f  Force operation (skips dependency and status checks)
      WARNING: Use at your own risk, modules have dependencies for a reason!
OPERATIONS:
  checkdepends <module>
      Check if module meets all dependencies
  delete <module>
      Disable, uninstall, and delete the specified module
  deleteall
      Disable, uninstall, and delete ALL MODULES
      WARNING: Use at your own risk, this will remove ALL MODULES from your system!
  disable <module>
      Disable the specified module
  download <module>
      Download the module from the website
      If -f is used, downloads even if there is already a copy.
  enable <module>
      Enable the specified module
  info <module>
      Get information about a given module
  i18n <module>
      print out i18n required text for the given module
  install <module>
      Install the module (must exist in the modules directory)
  installall
      Installs all module that exist in the repository
  list
      List all local modules and their current status
  listonline
      List all local and repository modules and their current status
  reload
      Reload the configuration (same as pressing the reload bar)
  reversedepends <module>
      Show all modules that depend on this one
  showupgrades
      Show a list of upgradable modules
  showannounce
      Shows any annoucements that maybe displayed at freepbx.org for this version
  uninstall <module>
      Disable and uninstall the specified module
  upgrade <module>
      Equivalent to running download and install
  upgradeall
      Downloads and upgrades all modules with pending updates
  --help, -h, -?           Show this help
root@pbx:~ $

You can see that there are a number of utilities here for an Aggregation Creator which could come in useful.

It's probably not documented on a web page, because there are not that many of us around that build FreePBX ISO's and you'd hope that we know what we are doing, and secondly, there probably isn't anything in the bug-tracker, because for me, it just works!

Joe

 

[wardmundy]

It's probably not documented on a web page, because there are not that many of us around that build FreePBX ISO's and you'd hope that we know what we are doing...

The concern wasn't that the hidden app didn't have a good help file. The concern was that the FreePBX Dev Team has not mentioned this on either their web site, or in their documentation, or in their developer courses EVER. And, yes, we like to think "we know what we are doing." But we could always improve if people that write code would take 5 minutes to document what they've done... assuming the Dev Team ever wanted anyone outside their own little group to know about it. The help file kinda makes the point. They didn't have any trouble spending the time to document it for themselves.

When we started with Asterisk, we found much the same attitude. Almost nothing was documented. As we now have learned from observing many open source projects, this turns out to be the dirty little secret that many open source developers use to earn their living. They give away their software, but you have to hire one of them to get it working because the documentation is either non-existent or has huge missing pieces. It's kinda like your grandma giving you her cookie recipe and "forgetting" to tell you about adding the sugar. Little wonder that her cookies always tasted better. I'm not picking on anyone. This is just my personal observation of how much of the open source world seems to operate.

Call it what you will, but it's really just another form of crippleware. That's obviously not my view of how open source projects ought to operate. And we've done and are doing our best to try to change it... at least in the Asterisk community.

 

[p_lindheimer]

Ward,

a bit of a cynic aren't we? I think there may be a much simpler reason, though granted not nearly as dramatic and would definitely not make the tabloids. I don't know of any environments where developers, as a general rule, do documentation without being forced to. (And often that is a good thing because many developers are not necessarily the best writers though there are plenty of exceptions).

Commercial software projects usually hire technical writers to do their documentation. In the open source world, we typically install CMS (Content Management Systems) and wikis - both of which FreePBX has. The open source world tends to expect that some percent of the hundreds of thousands of users, and the hundreds of projects that use their software will contribute, and documentation is one of those ways. All of the FreePBX documentation is done this way, there is very little that is written by the developers.

The concern was that the FreePBX Dev Team has not mentioned this on either their web site, or in their documentation, or in their developer courses EVER.

I seem to recall you were cordially invited to OTTS where it was brought up in various sections like trouble shooting white screen scenarios with Module Admin GUI and disabling/uninstalling modules that are blocked from doing such in the GUI. That's a couple areas, it may be mentioned others.

It's there, along with a handful of other tools that are little used and probably not known by too many people. I guess it comes down to simple math. Most OS projects have many more consumers then contributors back to the project. When you multiply a small number (the number of people who would ever use the CLI module_admin) with a very small percentage, it approaches zero. Thus apparently, none of that very small population of the CLI version of module_admin have ever bothered to write up a page of add to an existing page on the site. (Though I've brought it up on numerous occasions on the forum when there had been issues that it helped resolve).

And, yes, we like to think "we know what we are doing." But we could always improve if people that write code would take 5 minutes to document what they've done... assuming the Dev Team ever wanted anyone outside their own little group to know about it. The help file kinda makes the point. They didn't have any trouble spending the time to document it for themselves.

I guess you really don't know developers now do you. Developers would never write a "--help" option for themselves, that's what code is for… The help was written in a way that is fairly consistent with most linux/unix based CLI commands, some of which have "man" pages and others which don't.

When we started with Asterisk, we found much the same attitude. Almost nothing was documented. As we now have learned from observing many open source projects, this turns out to be the dirty little secret that many open source developers use to earn their living. They give away their software, but you have to hire one of them to get it working because the documentation is either non-existent or has huge missing pieces. This is just my personal observation of how much of the open source world seems to operate.

And that's a pretty cynical view on the world. I'm sure there are projects out there that work that way, but such a comment in light of this thread and your other comments sure seems to imply something about FreePBX. See comment below...

Call it what you will, but it's really just another form of crippleware. That's obviously not my view of how open source projects ought to operate. And we've done and are doing our best to try to change it... at least in the Asterisk community.

You've got proper permissions on FreePBX.org to add to the FreePBX documentation, and were you to run into a snag with the permissions, you know how to reach me. So if you are doing your best, and you obviously feel strongly about this topic, then go spend the 2 minutes (remembering that the development has already "spent 5 minutes" and copy and paste the help that has already been done onto the Module Admin book page as the alternate methods and options of the CLI version of managing modules.

Ward … I really expect more from you, I'm sorry to see you in such a mood today.

 

[p_lindheimer]

I suspect it was probably when you came to the OTTS training, or maybe from one of the forum posts I have mentioned it in in the past. And obviously, the help was adequate to see how to use it glad it helped.

 

[blanchae]

Documentation is always a headache - doesn't matter if it is open source or not. Once the project is completed, there usually isn't enough time before moving on to "putting out the next fire".

My contribution has been to document PiaF on my website. Unfortunately, it is already obsolete in sections. I thought that I was on the bleeding edge using FreePBX 2.5, Asterisk 1.6 plus Dahdi and now find that I'm behind already.

I'm spending my free time updating the labs and documentation for my students for Jan 2011 - I've been working on this since April 2010. And when it is done, it will be time to update again.

I definitely would like better documentation on creating FreePBX modules. I went looking in the summer and found broken links and obsolete examples. Left very frustrated. Unfortunately, creating documentation normally doesn't pay the bills. That's the bind that we are in.

 

[tm1000]

The best way to learn about anything FreePBX wise is to just contact Mr. lindheimer. and I'm completely serious about that.

I knew about the module admin CLI that Joe speaks of from talking directly to Mr. lindheimer over the phone.

Eh, I suppose it's not the best way to get information but the documentation is horrible on the FreePBX website, and I'm not blaming anyone for that because my own documentation for endpoint manager is completely horrible and lacking, I'm just saying I see the problems and I can relate.

All developers I know hate to write long documentation. They would rather program because it's much more fun.

It would be great if someone could go along and clean up all FreePBX articles.

 

[jmullinix]

Huh????

Call it what you will, but it's really just another form of crippleware. That's obviously not my view of how open source projects ought to operate. And we've done and are doing our best to try to change it... at least in the Asterisk community.

Ward, I am sorry but people who live in glass houses should not through stones.

You, Tom and initially Joe have built one of the world leaders of PBX software. You have rolled it into an ISO simple enough that "even a caveman can do it." (For our non-North American friends, there is an insurance commercial that uses this phrase.) You have every right to be proud of your accomplishments.

I find it curious that you will call Joe's efforts contributing to crippleware when you own installers are closed source. When the project started and another (green) company was using your scripts without credit, I could understand the reasoning behind encrypting your installers. That was years ago and that company has moved far enough ahead that this can no longer be an issue. Their distribution is now rpm based and, to use your installers, would require a total rewrite.

If you are a true believer in open-source software, open your installer scripts to the community, put up a wiki and some sort of CMS system and let the community help you maintain this project. You would be amazed at where PIAF would go if you did this.

Ed Macri and I wrote the first version of the Endpoint manager. Tony Schiffer turned it into a FreePBX module. Ed and I were happy with what we had so we stopped developing it. Andrew Nagy took it over and has turned it into something wonderful. I submitted suggestions to the project yesterday to better program Aastra 6755i phones. If you opened your installers, you would have this type of assistance also.

You have a great community here with a lot of talent. Only good would come from opening the installers to the community. One of the side benefits would be freeing up some of Tom's time.

Give serious thought to this and in the meantime, stop throwing stones; you might break a window.

 

[wardmundy]

Glad You Brought It Up...

John,

I've been churning out shareware, freeware, and open source software for more than 25 years. And I must say it's always a little disappointing when folks complain about (only) getting free software.

Just for the record, I didn't suggest anything about Joe's efforts. In fact, we really appreciate everything Joe has done over the years as well as his suggestions that began this thread. Second, compiled freeware installers are a far cry from hiding open source apps. Which would you rather have? One provides total, uncrippled functionality to every user while the other gives users absolutely nothing. Except for the price tag, our installers are no different than those for Fax for Asterisk and Skype for Asterisk. Where our installers load open source apps, you always get the source code for the app either on your local disk or in our source repo. Haven't heard any complaints about Digium's commercial distribution model even though both of those products supplanted free alternatives. And I do mean supplanted. Try getting rxfax to work with Asterisk 1.8 and FreePBX 2.8 if you don't believe it.

There are dozens of threads on these forums that will show anyone how to roll their own installer with our stuff for almost any platform if anyone wishes to do so. We ungrudgingly provide enormous amounts of code and bandwidth and forum support to make generic Asterisk installs work in virtual environments as well as with other flavors of Linux.

We always have and always will welcome contributors with open arms. The number of gurus on these forums is a testament to that. Still it's each individual's free choice how to license and distribute their software. We don't think it's appropriate to brow beat us or anyone else into a particular licensing scheme especially when Asterisk itself is distributed subject to a dual license.

Finally, one reason the green app may appear to be dying on the vine might very well be because they have no one to borrow code from any more.

 

[p_lindheimer]

ward,

I don't know about Asterisk 1.8 and rxfax, but FreePBX 2.8 supports rxfax/spandsp fine. If you have run into a bug with it then file a bug report and it will be promptly looked at. The additions to faxing in FreePBX that came a few releases ago were aimed at improving the overall ease of use of faxing within FreePBX and adding the support for fax-for-asterisk (NOT replacing anything).

As far as what asterisk 1.8 has done wrt to faxing, I wouldn't know as I have not played with it yet. However, 1.8 is on 1.8.0 if I'm not mistaken. Don't forget that Asterisk typically takes at least half a dozen minor releases and often a dozen or more before it begins to 'stabilize' when a new major release comes out. And 1.8 was quite a change form my understanding so...

 

[wardmundy]

Bug report already filed, and Asterisk ticket also is open. In addition, rxfax won't compile for Asterisk 1.8. Of course, the answer we'd get back on rxfax is that it is a "foreign" app for which the Asterisk developers are not responsible... even when their code changes broke it.

 

[p_lindheimer]

Things change which does sometimes break outside apps. Has anyone looked to see why it doesn't compile and what may be involved to get it to work in 1.8. It is Open Source, that's one of the advantages and often an expectation.

In FreePBX, we usually jump through hoops to avoid breaking APIs and other things that may be used by outside projects and modules not in our control. However, every now and then, something comes along that can't be helped and it's going to be up to the original developers or others who jump in to help to move them forward.

However, on the fax front, I'm wondering if there are better alternatives in 1.8 given these comments that are in their Changelog:

* A technology independent fax frontend (res_fax) has been added to Asterisk.
* A spandsp based fax backend (res_fax_spandsp) has been added.
* The app_fax module has been deprecated in favor of the res_fax module and the new res_fax_spandsp backend.

If there is anything that we need to do on the FreePBX side to accommodate these changes then who ever experiments with it and figures it out should file a ticket and let us know and we can see what we can do. I get the impression from those comments that spandsp may now work with SendFAX/ReceiveFAX or something like that???

 

[wardmundy]

I get the impression from those comments that spandsp may now work with SendFAX/ReceiveFAX or something like that???

That was the theory. Unfortunately, nothing works in Asterisk 1.8.0 as best I can determine. YMMV!

 

[TheShniz]

If you are a true believer in open-source software, open your installer scripts to the community, put up a wiki and some sort of CMS system and let the community help you maintain this project. You would be amazed at where PIAF would go if you did this.

+1

( Hit nail on head )

 

[blanchae]

If you are a true believer in open-source software, open your installer scripts to the community, put up a wiki and some sort of CMS system and let the community help you maintain this project. You would be amazed at where PIAF would go if you did this.

I think that there is a balance that is needed to prevent PiaF from being forked. Which introduces a complete new set of problems.

Sometimes opening up things can be detrimental. Providing some restricted structure can be a good thing. Compare Apple and the IBM PC world. While Apple is much more restrictive about their operating system, they have minimal problems compared to the Windows world.

Personally, I see the problems in administrating, that are now occuring with having the gold, silver and bronze versions of PiaF, not to mention having VM versions and Proxmox also. Throw in somebody who decides to fork PiaF because now they have the source for the scripts and the problems will multiply on the forums.

Having said that then restrict opening up the source to invited contributors with restrictions on what they can and can't do - perhaps similar to how Linus controls the Linux kernel development?

 

[wardmundy]

I don't think we'd have any objection to getting some more help with the builds although I can't speak for Tom. There are probably close to a dozen threads on the forum that already document how to do this on your own if anyone has a burning urge. See my next post. But you've hit the support nail on the head. Because we have more or less implicitly supported builds on other platforms and in VMs, we are constantly bombarded with emails that go something like this...

My machine blew up while attempting to download xyz.tar.gz. Is your site down?

And the answer is that, yes, one of our sites may be down from time to time, but we have mirrors that are supported in our installs that apparently aren't in those that others have rolled themselves.

And then there's the matter of bandwidth. We're happy supporting the occasional home-rolled downloader. Not sure we are equipped, financially or otherwise, to become a mini-SourceForge. So we're, of course, open to ideas on how that would work, too.

Finally, I've just got to ask. What exactly is it that you think you're getting with the source that you don't already have? Your system works today. It loads Linux, Asterisk, and FreePBX with all the source to do with as you please. Once we open it up where everyone and their brother "improves" things and leaves out pieces that many of us now assume are in place, who is going to support the mess?

 

[wardmundy]

If you are a true believer in open-source software, open your installer scripts to the community, put up a wiki and some sort of CMS system and let the community help you maintain this project. You would be amazed at where PIAF would go if you did this.

+1

( Hit nail on head )

Here you go: the complete list of do-it-yourself threads with accompanying scripts and tips. Please grab any or all of them and strike out on your own (again) with our blessings. But let's quit pretending all of this stuff isn't readily available.

• http://pbxinaflash.com/community/threads/remote-piaf-dedicated-server-install.7026/
• http://pbxinaflash.com/community/th...y-to-install-piaf-in-remote-data-center.2957/
• http://pbxinaflash.com/community/threads/why-no-remote-install-script.4286/
• http://pbxinaflash.com/community/th...osoft-virtual-server-2005-r2-sp1-part-1.4390/
• http://pbxinaflash.com/community/threads/openvz-remote-installation.156/
• http://pbxinaflash.com/community/th...l-piaf-in-remote-data-center.2957/#post-17423
• http://pbxinaflash.com/community/threads/piaf-1-4-remote-installation-help.3787/
• http://pbxinaflash.com/community/threads/64-bit-piaf-vz-template.6833/
• 
  
  There's been one fork, and I believe some of you actually participated in getting it going. Feel free to try again. Rome was not built in a day. :rockonb:

[youtube]Ew7gBQcM65M[/youtube]