astlinux-devel Mailing List for AstLinux

Devs,

Michael and I put together a WiKi entry in the Developer docs:

Developer Documentation -> Tips and Tricks -> Create Custom Web Interface Tabs

http://doc.astlinux.org/devdoc:devdoc-custom-webgui

Lonnie

Interesting topic...

Here in the central US, the common failure modes and possible precautions:

1) Internet Connectivity, 7-90 days MTBF
  - Pay extra for "Business Class" offering priority service to outages.
  - Pay extra for a redundant internet connection. *

2) Electrical Power, 100-300 days MTBF (much lower MTBF at some locations)
  - Large UPS with PoE switches and PoE IP Phones

3) Hardware Damage via Lightning, MTBF varies greatly by location
  - Lightning suppression for analog telco services.
  - Lightning suppression in electrical panel when possible.
  - Use Fiber when practical. *

4) Generic Hardware Failure, typically > 2200 days MTBF
  - Cold spares for critical hardware, net5501, network switch, power supply, etc.
  - Document VLAN's, network topology, firmware configurations

The described precautions above, without *'s, is my current practice.

Lonnie


On Jun 14, 2011, at 7:18 AM, Tom Chadwin wrote:

> Hi all
> 
> I have few failover events. I'm just trying to make the system as
> resilient as possible, partly out of duty, but also because I have
> been backed in selecting an open-source solution for a governmental
> body, and I want to be armed with answers when asked questions about
> resilence.
> 
> I am trying to cater for failure of Astlinux or its host net5501. I am
> also looking to cater for failure of anything between the endpoints
> and Astlinux. By having two net5501s on separate UPSes, on separate
> switches, this seems to fit the bill. Or am I thinking about this in
> the wrong way?
> 
> Thanks
> 
> Tom
> 
> 
> On Fri, Jun 10, 2011 at 5:24 PM, Lonnie Abelbeck
> <li...@lo...> wrote:
>> Tom,
>> 
>> What are your failure causes?  Only/mostly remote network connectivity failures?
>> 
>> Lonnie
>> 
>> On Jun 10, 2011, at 1:56 AM, Tom Chadwin wrote:
>> 
>>> Hello
>>> 
>>> We have redundant Astlinux boxes at our main sites, and rely on the
>>> failover functionality of our endpoints, which does not work well.
>>> Could something like ucarp (www.ucarp.org) be used at the Astlinux end
>>> to handle this failover process at an IP level, and hence
>>> transparently from the endpoints' perspective? If so, that could be a
>>> great feature to have out-of-the-box. HA is certainly strongly touted
>>> with network devices, so why not a PBX?
>>> 
>>> Thanks
>>> 
>>> Tom

Hi all

I have few failover events. I'm just trying to make the system as
resilient as possible, partly out of duty, but also because I have
been backed in selecting an open-source solution for a governmental
body, and I want to be armed with answers when asked questions about
resilence.

I am trying to cater for failure of Astlinux or its host net5501. I am
also looking to cater for failure of anything between the endpoints
and Astlinux. By having two net5501s on separate UPSes, on separate
switches, this seems to fit the bill. Or am I thinking about this in
the wrong way?

Thanks

Tom


On Fri, Jun 10, 2011 at 5:24 PM, Lonnie Abelbeck
<li...@lo...> wrote:
> Tom,
>
> What are your failure causes?  Only/mostly remote network connectivity failures?
>
> Lonnie
>
> On Jun 10, 2011, at 1:56 AM, Tom Chadwin wrote:
>
>> Hello
>>
>> We have redundant Astlinux boxes at our main sites, and rely on the
>> failover functionality of our endpoints, which does not work well.
>> Could something like ucarp (www.ucarp.org) be used at the Astlinux end
>> to handle this failover process at an IP level, and hence
>> transparently from the endpoints' perspective? If so, that could be a
>> great feature to have out-of-the-box. HA is certainly strongly touted
>> with network devices, so why not a PBX?
>>
>> Thanks
>>
>> Tom
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>

>On Jun 11, 2011, at 12:47 PM, Michael Keuter wrote:
>
>>>  Dev Guys,
>>>
>>>  Is there interest in supporting external interface
>>>  monitoring/failover as a init.d service?
>
>...snip...
>
>>>  Would this actually be used?
>>>
>>>  Lonnie
>>
>>  Sounds really good for people who actually have 2 external interfaces
>>  to fail over.
>>
>>  Michael
>
>Well, that is part of the question, is the cost of a second, 
>redundant IP connection something customers will not usually pay 
>for?  At least for the scope of embedded device solutions.
>
>Michael, you mentioned that customers asked you for failover 
>solutions, but even if Astlinux supported it, would the customer say 
>no because of the cost?  Darrick?
>
>Lonnie

Maybe that is differing in different countries.
Here in Germany we have ISDN since 1989 (1TR6) und Euro-ISDN since 
1994, and from a study 33% of all telephone lines in 2006 were ISDN. 
And ISDN is very reliable here.

 From my personal experiences from the past 10 years I had several 
internet connection outages, but only 1 or 2 small ISDN failures, 
that I remember. So, want I want to say is, in my opinion people here 
are rely more on ISDN than on internet/VoIP for business telephony 
(at least in Germany). So they would rather chose to buy an 
additional ISDN line (from a different provider) than a second 
internet connection (especially in small + medium business sector for 
which AstLinux is mainly used).

I don't know how it is in the UK, maybe Tom can share experiences.

Although VoIP is coming more and more, but people are very traditional.

Michael

http://www.mksolutions.info

On Jun 11, 2011, at 12:47 PM, Michael Keuter wrote:

>> Dev Guys,
>> 
>> Is there interest in supporting external interface 
>> monitoring/failover as a init.d service?

...snip...

>> Would this actually be used?
>> 
>> Lonnie
> 
> Sounds really good for people who actually have 2 external interfaces 
> to fail over.
> 
> Michael

Well, that is part of the question, is the cost of a second, redundant IP connection something customers will not usually pay for?  At least for the scope of embedded device solutions.

Michael, you mentioned that customers asked you for failover solutions, but even if Astlinux supported it, would the customer say no because of the cost?  Darrick?

Lonnie

>Dev Guys,
>
>Is there interest in supporting external interface 
>monitoring/failover as a init.d service?
>
>>From at least AstLinux 0.4 to today, the "/usr/sbin/netmon" script 
>>is installed with the following rc.conf variables:
>--
>## Netmon Support
>## Netmon is a daemon that may run to monitor your internet 
>connection.  By default,
>## it will try to ping the default gateway of the system.  If the 
>gateway cannot
>## be reached, netmon will take the action you have defined in your 
>action script.
>## /etc/netmon.script and /mnt/kd/netmon.script - if they are executable.
>## AND attempt to restart the connection, based on the connection type.
>## You can also set the destination address manually, if you wish.
>#NETMON=yes
>#CHKHOST="www.google.com"
>#CHKMETH="ICMP" # ICMP ping
>#CHKMETH="ARP" #arping (remember uses ARP - layer 2)
>--
>I don't think this was ever officially implemented, except via CRON 
>(please correct me if I am wrong).
>
>I'm thinking that we can leverage off our recent 
>"asterisk-sip-monitor" technology, create another background script, 
>and support the following:
>--
>1) Provide optional email alerts for network interruptions on EXTIF 
>and EXT2IF (if defined)
>
>2) Monitor status via ICMP and/or ICMPv6, using NETMON_IPV4_HOSTS 
>and NETMON_IPV6_HOSTS
>
>3) Optionally provide failover using EXT2IF
>   -- Add/Delete 0.0.0.0/1 and 128.0.0.0/1 routes to change IPv4 
>routing, so as not to mess with the default route.
>
>   -- Failover only when *all* NETMON_IPVn_HOSTS fail. Return from 
>failover when *all* succeed.
>
>4) Note external interface IPv4 address changes if dynamic.
>
>5) Support optional "/mnt/kd/bin/netmon.sh" script to be called on 
>network events, passing useful arguments.
>--
>Please add/amend as desired... or say "No Lonnie" bad idea. :-)
>
>Some tips/ideas from our star2star friends, "/usr/sbin/failifd":
>http://astlinux.svn.sourceforge.net/viewvc/astlinux/branches/s2s-newkernel/target/generic/target_skeleton/usr/sbin/failifd
>
>Comments?
>
>Would this actually be used?
>
>Lonnie

Sounds really good for people who actually have 2 external interfaces 
to fail over.

Michael

http://www.mksolutions.info

Dev Guys,

Is there interest in supporting external interface monitoring/failover as a init.d service?

From at least AstLinux 0.4 to today, the "/usr/sbin/netmon" script is installed with the following rc.conf variables:
--
## Netmon Support
## Netmon is a daemon that may run to monitor your internet connection.  By default,
## it will try to ping the default gateway of the system.  If the gateway cannot
## be reached, netmon will take the action you have defined in your action script.
## /etc/netmon.script and /mnt/kd/netmon.script - if they are executable.
## AND attempt to restart the connection, based on the connection type.
## You can also set the destination address manually, if you wish.
#NETMON=yes
#CHKHOST="www.google.com"
#CHKMETH="ICMP" # ICMP ping
#CHKMETH="ARP" #arping (remember uses ARP - layer 2)
--
I don't think this was ever officially implemented, except via CRON (please correct me if I am wrong).

I'm thinking that we can leverage off our recent "asterisk-sip-monitor" technology, create another background script, and support the following:
--
1) Provide optional email alerts for network interruptions on EXTIF and EXT2IF (if defined)

2) Monitor status via ICMP and/or ICMPv6, using NETMON_IPV4_HOSTS and NETMON_IPV6_HOSTS

3) Optionally provide failover using EXT2IF
  -- Add/Delete 0.0.0.0/1 and 128.0.0.0/1 routes to change IPv4 routing, so as not to mess with the default route.

  -- Failover only when *all* NETMON_IPVn_HOSTS fail. Return from failover when *all* succeed.

4) Note external interface IPv4 address changes if dynamic.

5) Support optional "/mnt/kd/bin/netmon.sh" script to be called on network events, passing useful arguments.
--
Please add/amend as desired... or say "No Lonnie" bad idea. :-)

Some tips/ideas from our star2star friends, "/usr/sbin/failifd":
http://astlinux.svn.sourceforge.net/viewvc/astlinux/branches/s2s-newkernel/target/generic/target_skeleton/usr/sbin/failifd

Comments?

Would this actually be used?

Lonnie

Tom,

What are your failure causes?  Only/mostly remote network connectivity failures?

Lonnie

On Jun 10, 2011, at 1:56 AM, Tom Chadwin wrote:

> Hello
> 
> We have redundant Astlinux boxes at our main sites, and rely on the
> failover functionality of our endpoints, which does not work well.
> Could something like ucarp (www.ucarp.org) be used at the Astlinux end
> to handle this failover process at an IP level, and hence
> transparently from the endpoints' perspective? If so, that could be a
> great feature to have out-of-the-box. HA is certainly strongly touted
> with network devices, so why not a PBX?
> 
> Thanks
> 
> Tom

>>Hello
>>
>>We have redundant Astlinux boxes at our main sites, and rely on the
>>failover functionality of our endpoints, which does not work well.
>>Could something like ucarp (www.ucarp.org) be used at the Astlinux end
>>to handle this failover process at an IP level, and hence
>>transparently from the endpoints' perspective? If so, that could be a
>>great feature to have out-of-the-box. HA is certainly strongly touted
>>with network devices, so why not a PBX?
>>
>>Thanks
>>
>>Tom
>
>I also had rquests from customers for a failover solution.
>That would be possible in principle with e.g. an external 
>mediagateway (Berofix, Patton).
>
>There is already an existing package for ucarp in OpenWRT:
>
>https://dev.openwrt.org/browser/packages/net/ucarp/Makefile?rev=20543
>
>It would also fitting for our latest attempts like Safe-Asterisk and 
>SIP-monitoring :-).

Update: I found a buildroot-style makefile for ucarp:

https://eisler.nettworks.org/svn/fli4l/branches/libc-upgrade/src/src/buildroot/package/ucarp/ucarp.mk

Michael

http://www.mksolutions.info

>Hello
>
>We have redundant Astlinux boxes at our main sites, and rely on the
>failover functionality of our endpoints, which does not work well.
>Could something like ucarp (www.ucarp.org) be used at the Astlinux end
>to handle this failover process at an IP level, and hence
>transparently from the endpoints' perspective? If so, that could be a
>great feature to have out-of-the-box. HA is certainly strongly touted
>with network devices, so why not a PBX?
>
>Thanks
>
>Tom

I also had rquests from customers for a failover solution.
That would be possible in principle with e.g. an external 
mediagateway (Berofix, Patton).

There is already an existing package for ucarp in OpenWRT:

https://dev.openwrt.org/browser/packages/net/ucarp/Makefile?rev=20543

It would also fitting for our latest attempts like Safe-Asterisk and 
SIP-monitoring :-).


Michael

http://www.mksolutions.info

Hello

We have redundant Astlinux boxes at our main sites, and rely on the
failover functionality of our endpoints, which does not work well.
Could something like ucarp (www.ucarp.org) be used at the Astlinux end
to handle this failover process at an IP level, and hence
transparently from the endpoints' perspective? If so, that could be a
great feature to have out-of-the-box. HA is certainly strongly touted
with network devices, so why not a PBX?

Thanks

Tom

Morning all

How much work would be involved in i18n of the Astlinux GUI? I could
look at helping out with that if there was an appetite. Graziano's
other question also raises the question of whether modularization
could be achieved. These two developments would lift Astlinux up a
level, professionally, I would say.

Thoughts?

Tom


On Thu, Jun 9, 2011 at 9:48 PM, Lonnie Abelbeck
<li...@lo...> wrote:
> Hi Graziano,
>
> Sorry, but the web interface is not currently written to support multiple languages, only English at this time.
>
> If you want to use the web interface to set astdb values, the Actionlist Tab may be useful, where the "actionlist" family is used and "key" and "value" may be defined.  The Asterisk dialplan can easily utilize these values.
>
> While some users have used existing tabs as a template and created their own tabs, it is not recommended since future updates are not guaranteed to be compatible.
>
> If you have a specific idea for a new Tab that may be of general used to the community, feel free to send it to me.
>
> Lonnie
>
>
> On Jun 9, 2011, at 11:46 AM, Graziano Brioschi wrote:
>
>> Hello list
>>
>> I have some query about astlinux web interface:
>>
>> - Is there a simple way to translate the alternate web interface in
>> other languages (ie:italian...)?
>> - is there a suggested way to add some custom modules (ie. interface to
>> autoprovision for specific endpoint, interface to add/edit specific
>> astdb family databases, etc)?
>>
>> Thanks in advance
>>
>> Graziano
>>
>> --
>>
>> Graziano Brioschi
>>
>> Outland s.a.s.
>> sede operativa:
>> Via A. Don Rocca, 13
>> 20030, Senago (MI)
>> tel: 02 9948 6014
>> mobile: 328 8382622
>> email: gra...@ou...
>> -->  U4E<--
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>