Making Elastix More Modular

Discussion in 'General' started by GameGamer, Sep 18, 2008.

  1. GameGamer

    Joined:
    Jun 7, 2007
    Messages:
    13
    Likes Received:
    0
    For those of you who visit the Elastix IRC Channel, you are probably well aware of my view on Elastix and how we need to make it more modular. So here is my proposal for PaloSanto as well as the community.

    As it is right now, Elastix bills itself as Custom Made Telephony and an All in One Solution. While I have no problem with that, I think we need to move forward and take Elastix to a whole new level, a level that many other Distributions continue to ignore. We need to make Elastix the one Distribution that makes itself, whatever the end user or customer needs, not one that has a bunch of crap the customer will never use.

    So how do you propose to encompass this?

    Right now, Elastix installs the following tabs: System, PBX, Fax, Email, IM, Reports, Extras, and Agenda with multiple options under each of them.

    So why not just start off with a base install of System, PBX, Fax, and Reports and then from there we can go to elastix.org and download the modules we need, such as Email, IM, Agenda. When we try to upgrade our system, Elastix looks at just the modules that are installed and updates them accordingly.

    This will keep Elastix geared towards the beginning user as well as the more advanced users that want to dedicate a machine to a certain task such as only being a phone system.

    Whats the Downside?
    Keeping older systems up to date. Right now we use "yum update" to update our systems from the shell, but if we make these changes, that will not work to upgrade to our new Modular Elastix. But thats ok, because Elastix has great Backup and Restore utility thats done a great job since it's implementation. So the older systems would need to Backup, Re-image, Install Required Modules, and Restore. So you figure maybe an hour of downtime even if that in a production environment, if you don't just swap out the old systems with a new system already restored and configured.

    But look at the advantages that a more modular version of Elastix offers the community.

    Feel free to post your ideas, suggestions, and questions regarding a more modular Elastix, or visit the Elastix IRC Channel and spark a discussion with me (GameGamer43 on IRC).
     
  2. rafael

    Joined:
    May 14, 2007
    Messages:
    1,454
    Likes Received:
    1
    I like the idea to have an optimal light installation that can grow in very dynamically ways depending on the modules we install. If I have 200 extensions on a server I don't to have email server going in the same server, but if I have 10 extensions and 10 mails it might okay. Start with something and grow depending on your needs.

    What I don't really agree is with not using yum. I think the module admin should install rpms and it should be a frontend of yum. there is less or no downtime with yum update while backing up reinstalling would give us down time of 20 to several hours depending on the user expirience.

    Saludos,

    Rafael
     
  3. GameGamer

    Joined:
    Jun 7, 2007
    Messages:
    13
    Likes Received:
    0
    Regarding yum, I agree with your take on the idea. The only thing I see here is by doing an upgrade on older installs and updating the rpms, we need to allow people an easy and efficient way of uninstalling certain rpms (or modules as they'd be referred to at that time).
     
  4. mihpel

    Joined:
    May 8, 2007
    Messages:
    87
    Likes Received:
    0
    Making Elastix modular will dramatically increase it's usefulness and attractiveness but will demand much more dev hours put on it.

    I have to agree that modules should be packed as rpm's whether a frontend is available or not.

    Another approach would be to keep everything as is and have the ability to activate/deactivate "modules" and web gui "components".
     
  5. rafael

    Joined:
    May 14, 2007
    Messages:
    1,454
    Likes Received:
    1
    A button on the front end that do a "yum remove package|module" would solve that. I believe is better using rpms that our own package form as they are some how more standard. Even do I am a big fan of Debian and debs.

    Saludos,

    Rafael
     
  6. mihpel

    Joined:
    May 8, 2007
    Messages:
    87
    Likes Received:
    0
    Removing a package|module should immediately affect the web gui while preserving the option to reinstall removed packages|modules in the future restoring package and web gui.
     
  7. GameGamer

    Joined:
    Jun 7, 2007
    Messages:
    13
    Likes Received:
    0
    Thinking about this more indepth and taking all the above comments into consideration, we could do this without increasing dev time. Since the current system is relying on rpms, making the changes on the Web Interface shouldn't be hard. Then we could even do a Module Repository that house all the modules available for a base Elastix install, so for exisiting users they choose to remove whats installed with an upgrade they get through yum (putting the "yum remove package|module" button on the interface), whereas new users do a base install (System, PBX, Fax, and Reports) then choose modules from the Module Repository that the base install does not install by default.
     
  8. mihpel

    Joined:
    May 8, 2007
    Messages:
    87
    Likes Received:
    0
    +1

    FreePBX style setup! Bare base setup with loads of extras.

    The only con i can think of is traffic on elastix repo.
     
  9. techieg

    Joined:
    Oct 8, 2007
    Messages:
    81
    Likes Received:
    0
    To restate what I had posted on another thread;

    Its about time Elastix started looking into a fully integrated system;

    Dovecot - IMAP server so users can access emails outside of Elastix (http://www.dovecot.org/). Sinceerly, nobody needs to host email on a phone server due to the amount of system resources email servers consume, so having an email server in Elastix is totally unnecessary bloatware and needs to be removed. The same goes for CRM software. These are applications that need to be hosted outside of a phone system but tied together over IP for seamless access.

    Dojotoolkit - Open Source DHTML toolkit written in JavaScript. It builds on several contributed code bases (nWidgets, Burstlib, f(m)), which is why it sometimes referred to as a "unified" toolkit (http://dojotoolkit.org/).

    Jabberd2 - XMPP/Jabber server library so admin and users can seamless UI (http://jabberd2.xiaoka.com/) as opposed to Openfire within Elastix (this is not pretty anymore as there are advancements out there now).

    Quagga - a routing software suite, providing implementations of OSPFv2, OSPFv3, RIP v1 and v2, RIPng and BGP-4 (http://www.quagga.net/about.php).

    SLA - we all know too well what this is and need it soon.

    Webfax - We all know what this also is and need to see it soon. In my opinion, this will be better done by completely skinning the Avantfax backend code and embedding it behind an Elastix UI for seamlessness.

    Elaborate endpoint provisioning system for various brands/models.

    Hardware manager UI.

    Replace FreePBX UI with seamless Elastix UI.

    Cisco Discovery Protocol (CDP) and Multicast DNS (mDNS)- used to discover compatible IP phones (such as Polycom, Cisco, Linksys, Aastra, etc) and put them on the default voice VLAN or one set by admin for DHCP to assign a different subnet IP address.

    Opensource telephony software is getting more and more competitive so advancement is much needed to say the least. The need to make Elastix more modular is one thing, the need to advance Elastix with services that are more integrated than FreePBX and Openfire sitting in their own cubbies and fax that is not feasible to implement is another (take a good look at http://voiceroute.org/ (see demo here; http://demo.voiceroute.net/druid/login.php , login/password are admin/admin), these guys are taking no prisoners. They have come to overtake the open source PBX arena, so until all other guys like Trixbox, Elastix, FreePBX, AsteiskNOW, etc step up their games these guys have got the open source UCS arena locked down. They have SLA, Webfax, hardware configurator/manager, full (multibrand/model) endpoint provisioner UI, etc working and are porting it over from their commercial version to the open source version soon according to; http://forums.voiceroute.org/showthread ... hlight=sla . However, they have taken the same stand as I have not to integrate email server and CRM into any of their systems but rather those be external services due to the resources those features use up as they compete with the main phone functionality for system resources which can then cause bad phone system performance.

    Competition is good for the community.
     
  10. GameGamer

    Joined:
    Jun 7, 2007
    Messages:
    13
    Likes Received:
    0
    techieg, I think your missing the point a little here as most of your requests aren't necessarily something that everyone wants or would need. For instance the people that are just using Elastix as a phone and fax server don't need an IMAP server or Jabber. However if we go the module approach, then this is something that can be put into a module for your respected task.

    As for your comment on Druid, I also disagree with you here. Druid is another option, as Elastix is. Each has there own market and while you praise Druid for the things they have done, I'll agree somethings are great. But to say that they have the OpenSource UCS market on lock down is false. If we look at why they opensourced Druid, it's because they did not get enough interest in the initial commercial offering. Druid started off as a commercial product and even with the opensource release, is still maintained as such from what I've seen. I think there is some good that has come out of Druid but like every distribution, to each his/her own.
     
  11. techieg

    Joined:
    Oct 8, 2007
    Messages:
    81
    Likes Received:
    0
    I'm quite sure we all know the history behind DruidOSE being originally solely a commercial offering. My aim here is to foster competition (perhaps I should have said Druid developers have come into the open source arena by storm) because I am indeed a fan of all open source telephony. Having said that, I have earlier made requests for many of the features I mentioned here way back when Trixbox was the in thing. And just as Elastix impressed me from when I was mainly into Trixbox so has Druid impressed me now (this is not to say Druid is perfect because there are some areas I would rather have differently), although we embrace and offer all to clients at; http://www.opentelefony.com/. Coming from a network/systems admin experience such things that Druid brings to the table are what we look for. For instance, I would rather host email on exchange server and have an IMAP server on Elastix to access the email just like Outlook Web Access (OWA) or any web-based email service and I would rather set outbound SMTP settings in Elastix UI to deliver email via exchange. I am not sure you understand the amount of RAM and HDD space email alone requires; an example for you is a client of 15 users that we have 4GB RAM installed on their file server, email alone constantly takes up about 2GB RAM (50%) not to talk of how much HDD space it needs which equals less HDD space for user voicemail and other telephony functions. Adding CRM on top of that on the same system only hogs more RAM and HDD with customer data and database processes, etc when core telephony, voicemail, etc need the same system resources. Just to add, I also found that memory leaks do not occur in Druid as I have observed, the exact opposite happens in Elastix where RAM rises to 90% usage within an hour of uptime even though there is not a single call in progress. This may be a result of too much unnecessary services in there. That is why when put to actual use, there is usually a system crash eventually.

    Also keep in mind that my suggestions will essentially make Elastix a leaner, meaner software. Take for example removing a full blown Openfire and replacing it with Jabberd2 which simply provides embedded XMPP/Jabber server which also includes LDAP support. For every distribution; to each his/her own but when the community and critics/reviewers compare them all side by side that does not work. You will obviously see more check marks for feature availability on one distribution or the other than the other, which goes a long way in determining a lot for each distribution. What the ideal comparison result should be is for the leading distribution to edge the other one by just one feature check mark or two...this will be competition.

    Needless to say, all mentioned projects are all open source, I assume features can be ported from one distribution to another and everyone will be happier I guess.
     
  12. GameGamer

    Joined:
    Jun 7, 2007
    Messages:
    13
    Likes Received:
    0
    techieg: I understand what your saying but with regards to some of your requests, you'll see that if we make Elastix more modular and use the modules, all of your above features can come as a module for users to choose and decide if it fits their business model, or particular install.

    For instance, if you want an IMAP server on the box, maybe it will be part of the Email Module, or maybe you choose to develop a seperate module just for an IMAP server, as you don't want all the other email offerings. Regardless we are both making the distrubtion leaner while allowing the community the opportunity to make modules that fit their need.

    I'll also note that I completely agree that Openfire may not be the best choice for instant messaging anymore. However if we again choose this modular approach, and install the IM module (which we can choose to use Jabber and not Openfire in), then we will get jabber and a decent Web Base UI for Administration purposes. Also contributing to the fact of a leaner distro and ultimately better distro for all users.
     
  13. techieg

    Joined:
    Oct 8, 2007
    Messages:
    81
    Likes Received:
    0
    A couple of features I must say majority if not all of us will agree on is the need for LDAP support and Single-Sign-On for every feature available to admin and users, these are some other things Druid does seamlessly.
     
  14. GameGamer

    Joined:
    Jun 7, 2007
    Messages:
    13
    Likes Received:
    0
    Come on guys, I know techieg, rafael, and I can't be the only ones who see how this could benefit the community. So let's continue to do what we've been doing all along and let your voices be heard so that we embark on a path to make Elastix the best distribution possible.
     
  15. bmacias

    Joined:
    Sep 27, 2007
    Messages:
    205
    Likes Received:
    0
    Hello community:

    hmmm...

    I like the idea. B)
     
  16. RB2

    RB2

    Joined:
    Oct 11, 2008
    Messages:
    2
    Likes Received:
    0
    I whole-heartedly agree.

    Smaller organizations would benefit from being able to start out with just the PBX and easily install modules (IM, Email, etc.) that are tightly integrated with their phone system as needed. Larger organizations already have infrastructure in place (application servers, mail servers, db servers), but may like tighter integration.

    Off the cuff brainstorming, the notion of adapters isn't a bad idea either. For example, a user installs the the Openfire IM module and the adapter gets installed and is pre-configured to point at the local instance. If the user just installs the adapter (or later on changes its settings), they can configure it to point at a different instance. This would also allow organizations to easily install an application and if it fits their need or becomes wildly popular, migrate it to a platform that is much more scalable.

    Just my 2 cents.
     
  17. berniem

    Joined:
    Oct 14, 2008
    Messages:
    1
    Likes Received:
    0
    As far as modularity goes, I'd suggest considering a slightly larger view: rather than "starting with PBX and maybe FAX and maybe _____", how about assume only that the install will include the OS and Elastix?

    To whatever extent synergy exists between the various components of Elastix, perhaps that synergy can be kept even though the modules happen to live on different boxes. Why? Well:

    *) The whole is greater than the sum of the parts. If the Elastix PBX and the Elastix Mail server communicate, there should be more value that can be added to the whole package.

    *) Unified management. If the "command interface" for the Elastix components are not difficult to remote, then the shop that has an Elastix PBX and an Elastix Mail server and an Email Fax server, need have only one management console. That's a BIG win. (This is the same concept as having unified user management - it's just the next level up.)

    *) To make it easier for that SOHO installation to grow up slowly. For the SOHO installation which has had its PBX & FAX & Email & IM & etc all running on the same box, wouldn't it be nice if they could pull off, say, the email server and still have the same old familiar interface they're used to?
     
  18. techieg

    Joined:
    Oct 8, 2007
    Messages:
    81
    Likes Received:
    0
    In my opinion and I'm sure other IT administrators/system engineers are on board, email servers do not belong on a PBX. A lot of people do not understand how much system resources email servers alone use up on server hardware. If users badly need an email server, they can easily get hardware and setup Zimbra Open Source Email Server; http://www.zimbra.com/products/zimbra_l ... erver.html (it's developed by Yahoo to give Microsoft Exchange a run for the money so you know it has good financial and developer backing). See user interface demos here; http://www.zimbra.com/products/demos.html . It does not get any easier or more sensible than that...OMG, why is it so hard for people including Elastix team to understand this and keep email server out of a PBX if they actually want to be taken seriously?
     
  19. RB2

    RB2

    Joined:
    Oct 11, 2008
    Messages:
    2
    Likes Received:
    0
    berniem,

    I agree, I believe you're saying the same thing as I was (wrt to my "adapters" brain dump).


    techieg,

    I agree with you 99%. An email server is an exceptionally bad idea. As for IM and CRM software, it would make sense for a small company of 10 or 20 people to use it as a unified communications platform. But, those services need to have the ability to be migrated to a remote box if/when the company grows and still be able to retain that unified communications solution.

    If it were modularized, the default install could be a lean efficient PBX with no frills.

    And I think a Zimbra adapter would be awesome. :)
     
  20. techieg

    Joined:
    Oct 8, 2007
    Messages:
    81
    Likes Received:
    0
    RB2, I get your point but I also think a small business should be able to get basic PC hardware and setup Zimbra open source which they obviously get for free to do their emails especially with 1TB HDD 7200RPM 32MB Cache is about $100 now. They can easily set up endless storage for their emails without impacting the PBX at all. A Zimbra adapter or Zimlet as they may be called to easily tie a separate Zimbra server to Elastix can be developed. From my understanding, this will be a small application which will could actually be all that needs to be developed as the email server tie in module.

    Better or even best yet, is for Elastix to just have an integrated IMAP interface (module or not) to access ANY external email server seamlessly, be it Exchange, Zimbra, Oracle, etc. Example IMAP servera are Dovecot - http://www.dovecot.org/ and RoundCube - http://www.roundcube.net/ to access emails hosted on external email servers such as those earlier listed, other PBXes have long been smart about it amongst other things such as LDAP, Ajax UI, etc that is why they are taken seriously and continue to garner tons of enterprise clientelle. They can also have an SMTP GUI to set outbound email delivery parameters through the external SMTP/email server as well....much straight forward and less time trying to maintain an integrated email server which limits Elastix adoption anyway.
     

Share This Page