Menu
▾
▴
astlinux-users — AstLinux Users Mailing List
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(91) |
Feb
(111) |
Mar
(226) |
Apr
(65) |
May
(197) |
Jun
(202) |
Jul
(92) |
Aug
(87) |
Sep
(120) |
Oct
(133) |
Nov
(89) |
Dec
(155) |
| 2008 |
Jan
(251) |
Feb
(136) |
Mar
(174) |
Apr
(149) |
May
(56) |
Jun
(32) |
Jul
(36) |
Aug
(171) |
Sep
(245) |
Oct
(244) |
Nov
(218) |
Dec
(272) |
| 2009 |
Jan
(113) |
Feb
(119) |
Mar
(192) |
Apr
(117) |
May
(93) |
Jun
(46) |
Jul
(80) |
Aug
(54) |
Sep
(109) |
Oct
(70) |
Nov
(145) |
Dec
(110) |
| 2010 |
Jan
(137) |
Feb
(87) |
Mar
(45) |
Apr
(157) |
May
(58) |
Jun
(99) |
Jul
(188) |
Aug
(136) |
Sep
(101) |
Oct
(100) |
Nov
(61) |
Dec
(60) |
| 2011 |
Jan
(84) |
Feb
(43) |
Mar
(70) |
Apr
(17) |
May
(69) |
Jun
(28) |
Jul
(43) |
Aug
(21) |
Sep
(151) |
Oct
(120) |
Nov
(84) |
Dec
(101) |
| 2012 |
Jan
(119) |
Feb
(82) |
Mar
(70) |
Apr
(115) |
May
(66) |
Jun
(131) |
Jul
(70) |
Aug
(65) |
Sep
(66) |
Oct
(86) |
Nov
(197) |
Dec
(81) |
| 2013 |
Jan
(65) |
Feb
(48) |
Mar
(32) |
Apr
(68) |
May
(98) |
Jun
(59) |
Jul
(41) |
Aug
(52) |
Sep
(42) |
Oct
(37) |
Nov
(10) |
Dec
(27) |
| 2014 |
Jan
(61) |
Feb
(34) |
Mar
(30) |
Apr
(52) |
May
(45) |
Jun
(40) |
Jul
(28) |
Aug
(9) |
Sep
(39) |
Oct
(69) |
Nov
(55) |
Dec
(19) |
| 2015 |
Jan
(13) |
Feb
(21) |
Mar
(5) |
Apr
(14) |
May
(30) |
Jun
(51) |
Jul
(31) |
Aug
(12) |
Sep
(29) |
Oct
(15) |
Nov
(24) |
Dec
(16) |
| 2016 |
Jan
(62) |
Feb
(76) |
Mar
(30) |
Apr
(43) |
May
(46) |
Jun
(62) |
Jul
(21) |
Aug
(49) |
Sep
(67) |
Oct
(27) |
Nov
(26) |
Dec
(38) |
| 2017 |
Jan
(7) |
Feb
(12) |
Mar
(69) |
Apr
(59) |
May
(54) |
Jun
(40) |
Jul
(76) |
Aug
(82) |
Sep
(92) |
Oct
(51) |
Nov
(32) |
Dec
(30) |
| 2018 |
Jan
(22) |
Feb
(25) |
Mar
(34) |
Apr
(35) |
May
(37) |
Jun
(21) |
Jul
(69) |
Aug
(55) |
Sep
(17) |
Oct
(67) |
Nov
(9) |
Dec
(5) |
| 2019 |
Jan
(19) |
Feb
(12) |
Mar
(15) |
Apr
(19) |
May
|
Jun
(27) |
Jul
(27) |
Aug
(25) |
Sep
(25) |
Oct
(27) |
Nov
(10) |
Dec
(14) |
| 2020 |
Jan
(22) |
Feb
(20) |
Mar
(36) |
Apr
(40) |
May
(52) |
Jun
(35) |
Jul
(21) |
Aug
(32) |
Sep
(71) |
Oct
(27) |
Nov
(11) |
Dec
(16) |
| 2021 |
Jan
(16) |
Feb
(21) |
Mar
(21) |
Apr
(27) |
May
(17) |
Jun
|
Jul
(2) |
Aug
(22) |
Sep
(23) |
Oct
(7) |
Nov
(11) |
Dec
(28) |
| 2022 |
Jan
(23) |
Feb
(18) |
Mar
(9) |
Apr
(15) |
May
(15) |
Jun
(7) |
Jul
(8) |
Aug
(15) |
Sep
(1) |
Oct
|
Nov
(11) |
Dec
(10) |
| 2023 |
Jan
(14) |
Feb
(10) |
Mar
(11) |
Apr
(13) |
May
(2) |
Jun
(30) |
Jul
(1) |
Aug
(15) |
Sep
(13) |
Oct
(3) |
Nov
(25) |
Dec
(5) |
| 2024 |
Jan
(3) |
Feb
(10) |
Mar
(9) |
Apr
|
May
(1) |
Jun
(15) |
Jul
(7) |
Aug
(10) |
Sep
(3) |
Oct
(8) |
Nov
(6) |
Dec
(15) |
| 2025 |
Jan
(3) |
Feb
(1) |
Mar
(7) |
Apr
(5) |
May
(13) |
Jun
(16) |
Jul
(1) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael K. <mic...@ip...> - 2018-03-04 22:36:59
|
Thanks. Yes I think I will need to do a mixture of things, knowing what I have out there.
Regards
Michael Knill
On 5/3/18, 8:54 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
Just for completeness, the Linux kernel exposes some DMI (Destktop Management Information) values in the /sys virtual filesystem.
# grep '.*' /sys/class/dmi/id/[bpc]*
-- APU2 --
/sys/class/dmi/id/bios_date:03/07/2016
/sys/class/dmi/id/bios_vendor:coreboot
/sys/class/dmi/id/bios_version:88a4f96
/sys/class/dmi/id/board_asset_tag:
/sys/class/dmi/id/board_name:apu2
/sys/class/dmi/id/board_serial:123456789
/sys/class/dmi/id/board_vendor:PC Engines
/sys/class/dmi/id/board_version:1.0
/sys/class/dmi/id/chassis_asset_tag:
/sys/class/dmi/id/chassis_serial:
/sys/class/dmi/id/chassis_type:3
/sys/class/dmi/id/chassis_vendor:PC Engines
/sys/class/dmi/id/chassis_version:
/sys/class/dmi/id/product_name:apu2
/sys/class/dmi/id/product_serial:123456789
/sys/class/dmi/id/product_version:1.0
--
And that is one of the more accurately defined boards, many are loaded with "To Be Filled By O.E.M".
As suggested below, some hash of the CPU model and the first 3 bytes of the ethernet MAC address would be a better indicator.
Lonnie
On Mar 1, 2018, at 10:39 AM, Lonnie Abelbeck <li...@lo...> wrote:
> Hi Michael,
>
> There is no direct string containing the vendor/model. By default we don't include the dmidecode command which can retrieve BIOS info, but not always accurate or useful.
>
> A couple ideas ... (example APU2)
>
> # cat /proc/cpuinfo | sed -n -r 's/^model name[[:space:]]*:[[:space:]]*(.+)$/\1/p'
> AMD GX-412TC SOC
> AMD GX-412TC SOC
> AMD GX-412TC SOC
> AMD GX-412TC SOC
>
> You could generate a unique hash string from that ...
>
> # cat /proc/cpuinfo | sed -n -r 's/^model name[[:space:]]*:[[:space:]]*(.+)$/\1/p' | tr -d ' \t' | sha1sum | cut -c 1-8
> 4e908e0f
>
> Of course this is not totally unique, but for the common boards used with AstLinux it would probably be unique. But you would have to map the hash to a human readable string.
>
> You could further refine it using the MAC address of the NIC's
>
> # ip -o link show | sed -n -r 's#^.*link/ether ([0-9a-fA-F:]+).*$#\1#p'
> 00:0d:b9:01:02:24
> 00:0d:b9:01:02:25
> 00:0d:b9:01:02:26
> 00:0d:b9:01:02:25
>
> Get the Vendor of the first MAC ...
>
> # ip -o link show | sed -n -r 's#^.*link/ether ([0-9a-fA-F:]+).*$#\1#p' | xargs mac2vendor
> PC Engines GmbH
>
> You can create a very simple shell script to qualify your vendor/model.
> --
> #!/bin/sh
>
> echo "Network Hardware: $(ip -o link show | sed -n -r 's#^.*link/ether ([0-9a-fA-F:]+).*$#\1#p' | xargs mac2vendor)"
>
> echo "Memory: $(awk '/^MemTotal:/ { print int(($2 + 512) / 1024) }' /proc/meminfo) MB"
>
> case $(cat /proc/cpuinfo | sed -n -r 's/^model name[[:space:]]*:[[:space:]]*(.+)$/\1/p' | tr -d ' \t' | sha1sum | cut -c 1-8) in
> 4e908e0f) echo "PC Engines APU2" ;;
> f24bfcb8) echo "Jetway NF9HG-2930" ;;
> 173fdaba) echo "Soekris net5501" ;;
> *) echo "Model Unknown" ;;
> esac
> --
>
> Output for APU2:
> --
> Network Hardware: PC Engines GmbH
> Memory: 3881 MB
> PC Engines APU2
> --
>
> Lonnie
>
>
>
> On Mar 1, 2018, at 4:49 AM, Michael Knill <mic...@ip...> wrote:
>
>> Ah whoops sorry. Wrong terminology.
>> I meant board vendor/model etc. E.g. is it an APU1, APU2, Jetway ????
>>
>> Regards
>> Michael Knill
>> On 1/3/18, 9:39 pm, "Michael Keuter" <li...@mk...> wrote:
>>
>>
>>> Am 01.03.2018 um 11:25 schrieb Michael Knill <mic...@ip...>:
>>>
>>> Hi Group
>>>
>>> Is there an easy way to find what board type you have installed in an Astlinux box?
>>> Im starting to lose track of what I have installed ☹
>>>
>>> Regards
>>> Michael Knill
>>
>> "cat /proc/cmdline"
>>
>> This is from the file:
>>
>> "/oldroot/cdrom/os/astlinux-xxx.run.conf"
>>
>> you can see in the line KCMD under "astlinux=xxx" the board type.
>>
>> Michael
>>
>> http://www.mksolutions.info
>>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
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....
|
|
From: Michael K. <li...@mk...> - 2018-03-04 22:01:13
|
> Am 04.03.2018 um 22:53 schrieb Lonnie Abelbeck <li...@lo...>:
>
> Hi Michael,
>
> Just for completeness, the Linux kernel exposes some DMI (Destktop Management Information) values in the /sys virtual filesystem.
>
> # grep '.*' /sys/class/dmi/id/[bpc]*
> -- APU2 --
> /sys/class/dmi/id/bios_date:03/07/2016
> /sys/class/dmi/id/bios_vendor:coreboot
> /sys/class/dmi/id/bios_version:88a4f96
> /sys/class/dmi/id/board_asset_tag:
> /sys/class/dmi/id/board_name:apu2
> /sys/class/dmi/id/board_serial:123456789
> /sys/class/dmi/id/board_vendor:PC Engines
> /sys/class/dmi/id/board_version:1.0
> /sys/class/dmi/id/chassis_asset_tag:
> /sys/class/dmi/id/chassis_serial:
> /sys/class/dmi/id/chassis_type:3
> /sys/class/dmi/id/chassis_vendor:PC Engines
> /sys/class/dmi/id/chassis_version:
> /sys/class/dmi/id/product_name:apu2
> /sys/class/dmi/id/product_serial:123456789
> /sys/class/dmi/id/product_version:1.0
> --
>
> And that is one of the more accurately defined boards, many are loaded with "To Be Filled By O.E.M".
Yes I tested it, for the Jetway boards you won't get useful informations this way (also not with "dmidecode") :-(.
> As suggested below, some hash of the CPU model and the first 3 bytes of the ethernet MAC address would be a better indicator.
>
> Lonnie
>
>
> On Mar 1, 2018, at 10:39 AM, Lonnie Abelbeck <li...@lo...> wrote:
>
>> Hi Michael,
>>
>> There is no direct string containing the vendor/model. By default we don't include the dmidecode command which can retrieve BIOS info, but not always accurate or useful.
>>
>> A couple ideas ... (example APU2)
>>
>> # cat /proc/cpuinfo | sed -n -r 's/^model name[[:space:]]*:[[:space:]]*(.+)$/\1/p'
>> AMD GX-412TC SOC
>> AMD GX-412TC SOC
>> AMD GX-412TC SOC
>> AMD GX-412TC SOC
>>
>> You could generate a unique hash string from that ...
>>
>> # cat /proc/cpuinfo | sed -n -r 's/^model name[[:space:]]*:[[:space:]]*(.+)$/\1/p' | tr -d ' \t' | sha1sum | cut -c 1-8
>> 4e908e0f
>>
>> Of course this is not totally unique, but for the common boards used with AstLinux it would probably be unique. But you would have to map the hash to a human readable string.
>>
>> You could further refine it using the MAC address of the NIC's
>>
>> # ip -o link show | sed -n -r 's#^.*link/ether ([0-9a-fA-F:]+).*$#\1#p'
>> 00:0d:b9:01:02:24
>> 00:0d:b9:01:02:25
>> 00:0d:b9:01:02:26
>> 00:0d:b9:01:02:25
>>
>> Get the Vendor of the first MAC ...
>>
>> # ip -o link show | sed -n -r 's#^.*link/ether ([0-9a-fA-F:]+).*$#\1#p' | xargs mac2vendor
>> PC Engines GmbH
>>
>> You can create a very simple shell script to qualify your vendor/model.
>> --
>> #!/bin/sh
>>
>> echo "Network Hardware: $(ip -o link show | sed -n -r 's#^.*link/ether ([0-9a-fA-F:]+).*$#\1#p' | xargs mac2vendor)"
>>
>> echo "Memory: $(awk '/^MemTotal:/ { print int(($2 + 512) / 1024) }' /proc/meminfo) MB"
>>
>> case $(cat /proc/cpuinfo | sed -n -r 's/^model name[[:space:]]*:[[:space:]]*(.+)$/\1/p' | tr -d ' \t' | sha1sum | cut -c 1-8) in
>> 4e908e0f) echo "PC Engines APU2" ;;
>> f24bfcb8) echo "Jetway NF9HG-2930" ;;
>> 173fdaba) echo "Soekris net5501" ;;
>> *) echo "Model Unknown" ;;
>> esac
>> --
>>
>> Output for APU2:
>> --
>> Network Hardware: PC Engines GmbH
>> Memory: 3881 MB
>> PC Engines APU2
>> --
>>
>> Lonnie
>>
>> On Mar 1, 2018, at 4:49 AM, Michael Knill <mic...@ip...> wrote:
>>
>>> Ah whoops sorry. Wrong terminology.
>>> I meant board vendor/model etc. E.g. is it an APU1, APU2, Jetway ????
>>>
>>> Regards
>>> Michael Knill
>>> On 1/3/18, 9:39 pm, "Michael Keuter" <li...@mk...> wrote:
>>>
>>>> Am 01.03.2018 um 11:25 schrieb Michael Knill <mic...@ip...>:
>>>>
>>>> Hi Group
>>>>
>>>> Is there an easy way to find what board type you have installed in an Astlinux box?
>>>> Im starting to lose track of what I have installed ☹
>>>>
>>>> Regards
>>>> Michael Knill
>>>
>>> "cat /proc/cmdline"
>>>
>>> This is from the file:
>>>
>>> "/oldroot/cdrom/os/astlinux-xxx.run.conf"
>>>
>>> you can see in the line KCMD under "astlinux=xxx" the board type.
>>>
>>> Michael
Michael
http://www.mksolutions.info
|
|
From: Lonnie A. <li...@lo...> - 2018-03-04 21:54:04
|
Hi Michael,
Just for completeness, the Linux kernel exposes some DMI (Destktop Management Information) values in the /sys virtual filesystem.
# grep '.*' /sys/class/dmi/id/[bpc]*
-- APU2 --
/sys/class/dmi/id/bios_date:03/07/2016
/sys/class/dmi/id/bios_vendor:coreboot
/sys/class/dmi/id/bios_version:88a4f96
/sys/class/dmi/id/board_asset_tag:
/sys/class/dmi/id/board_name:apu2
/sys/class/dmi/id/board_serial:123456789
/sys/class/dmi/id/board_vendor:PC Engines
/sys/class/dmi/id/board_version:1.0
/sys/class/dmi/id/chassis_asset_tag:
/sys/class/dmi/id/chassis_serial:
/sys/class/dmi/id/chassis_type:3
/sys/class/dmi/id/chassis_vendor:PC Engines
/sys/class/dmi/id/chassis_version:
/sys/class/dmi/id/product_name:apu2
/sys/class/dmi/id/product_serial:123456789
/sys/class/dmi/id/product_version:1.0
--
And that is one of the more accurately defined boards, many are loaded with "To Be Filled By O.E.M".
As suggested below, some hash of the CPU model and the first 3 bytes of the ethernet MAC address would be a better indicator.
Lonnie
On Mar 1, 2018, at 10:39 AM, Lonnie Abelbeck <li...@lo...> wrote:
> Hi Michael,
>
> There is no direct string containing the vendor/model. By default we don't include the dmidecode command which can retrieve BIOS info, but not always accurate or useful.
>
> A couple ideas ... (example APU2)
>
> # cat /proc/cpuinfo | sed -n -r 's/^model name[[:space:]]*:[[:space:]]*(.+)$/\1/p'
> AMD GX-412TC SOC
> AMD GX-412TC SOC
> AMD GX-412TC SOC
> AMD GX-412TC SOC
>
> You could generate a unique hash string from that ...
>
> # cat /proc/cpuinfo | sed -n -r 's/^model name[[:space:]]*:[[:space:]]*(.+)$/\1/p' | tr -d ' \t' | sha1sum | cut -c 1-8
> 4e908e0f
>
> Of course this is not totally unique, but for the common boards used with AstLinux it would probably be unique. But you would have to map the hash to a human readable string.
>
> You could further refine it using the MAC address of the NIC's
>
> # ip -o link show | sed -n -r 's#^.*link/ether ([0-9a-fA-F:]+).*$#\1#p'
> 00:0d:b9:01:02:24
> 00:0d:b9:01:02:25
> 00:0d:b9:01:02:26
> 00:0d:b9:01:02:25
>
> Get the Vendor of the first MAC ...
>
> # ip -o link show | sed -n -r 's#^.*link/ether ([0-9a-fA-F:]+).*$#\1#p' | xargs mac2vendor
> PC Engines GmbH
>
> You can create a very simple shell script to qualify your vendor/model.
> --
> #!/bin/sh
>
> echo "Network Hardware: $(ip -o link show | sed -n -r 's#^.*link/ether ([0-9a-fA-F:]+).*$#\1#p' | xargs mac2vendor)"
>
> echo "Memory: $(awk '/^MemTotal:/ { print int(($2 + 512) / 1024) }' /proc/meminfo) MB"
>
> case $(cat /proc/cpuinfo | sed -n -r 's/^model name[[:space:]]*:[[:space:]]*(.+)$/\1/p' | tr -d ' \t' | sha1sum | cut -c 1-8) in
> 4e908e0f) echo "PC Engines APU2" ;;
> f24bfcb8) echo "Jetway NF9HG-2930" ;;
> 173fdaba) echo "Soekris net5501" ;;
> *) echo "Model Unknown" ;;
> esac
> --
>
> Output for APU2:
> --
> Network Hardware: PC Engines GmbH
> Memory: 3881 MB
> PC Engines APU2
> --
>
> Lonnie
>
>
>
> On Mar 1, 2018, at 4:49 AM, Michael Knill <mic...@ip...> wrote:
>
>> Ah whoops sorry. Wrong terminology.
>> I meant board vendor/model etc. E.g. is it an APU1, APU2, Jetway ????
>>
>> Regards
>> Michael Knill
>> On 1/3/18, 9:39 pm, "Michael Keuter" <li...@mk...> wrote:
>>
>>
>>> Am 01.03.2018 um 11:25 schrieb Michael Knill <mic...@ip...>:
>>>
>>> Hi Group
>>>
>>> Is there an easy way to find what board type you have installed in an Astlinux box?
>>> Im starting to lose track of what I have installed ☹
>>>
>>> Regards
>>> Michael Knill
>>
>> "cat /proc/cmdline"
>>
>> This is from the file:
>>
>> "/oldroot/cdrom/os/astlinux-xxx.run.conf"
>>
>> you can see in the line KCMD under "astlinux=xxx" the board type.
>>
>> Michael
>>
>> http://www.mksolutions.info
>>
|
|
From: Lonnie A. <li...@lo...> - 2018-03-01 16:48:36
|
Announcing Pre-Release Version: astlinux-1.3-3622-e3aee4 The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own. -- Linux Kernel 3.16.54, security and bug fixes. -- zabbix, version bump to 3.0.14, adds TLS encryption support Note: Now requires a Zabbix server with version 3.0 or greater. -- Asterisk 13 version bump to 13.19.2 These pre-release images are for those who would like to take advantage of the AstLinux development before the next official release, as well as providing testing for the project. The "AstLinux Pre-Release ChangeLog" and "Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... AstLinux Project -> Development http://www.astlinux-project.org/dev.html While these images are considered 'stable', the lack of testing will not make these images suitable for critical production systems. If you should come across an issue, please report back here. AstLinux Team |
|
From: Michael K. <li...@mk...> - 2018-03-01 16:47:01
|
> Am 01.03.2018 um 11:49 schrieb Michael Knill <mic...@ip...>: > > Ah whoops sorry. Wrong terminology. > I meant board vendor/model etc. E.g. is it an APU1, APU2, Jetway ???? > > Regards > Michael Knill OK I understand. Best if you should look what you have sold them :-). Seriously, the best you can do is: "cat /proc/cpuinfo" A Jetway NF9HG has 4 CPUs of type: "Intel(R) Celeron(R) CPU N2930 @ 1.83GHz" A APU2 is also quad-core and a APU1 dual-core. In a custom build you could install "dmidecode" which shows much more information. But in case of a NF9HG the string "Jetway" did not appear anywhere. > On 1/3/18, 9:39 pm, "Michael Keuter" <li...@mk...> wrote: > >> Am 01.03.2018 um 11:25 schrieb Michael Knill <mic...@ip...>: >> >> Hi Group >> >> Is there an easy way to find what board type you have installed in an Astlinux box? >> Im starting to lose track of what I have installed ☹ >> >> Regards >> Michael Knill > > "cat /proc/cmdline" > > This is from the file: > > "/oldroot/cdrom/os/astlinux-xxx.run.conf" > > you can see in the line KCMD under "astlinux=xxx" the board type. > > Michael Michael http://www.mksolutions.info |
|
From: Michael K. <li...@mk...> - 2018-03-01 16:45:08
|
> Am 01.03.2018 um 11:49 schrieb Michael Knill <mic...@ip...>: > > Ah whoops sorry. Wrong terminology. > I meant board vendor/model etc. E.g. is it an APU1, APU2, Jetway ???? > > Regards > Michael Knill OK I understand. Best if you should look up what you have sold them :-). Seriously, the best you can do is: "cat /proc/cpuinfo" A Jetway NF9HG has 4 CPUs of type: "Intel(R) Celeron(R) CPU N2930 @ 1.83GHz" A APU2 is also quad-core and a APU1 dual-core. In a custom build you could install "dmidecode" which shows much more information. But in case of a NF9HG the string "Jetway" did not appear anywhere. > On 1/3/18, 9:39 pm, "Michael Keuter" <li...@mk...> wrote: > >> Am 01.03.2018 um 11:25 schrieb Michael Knill <mic...@ip...>: >> >> Hi Group >> >> Is there an easy way to find what board type you have installed in an Astlinux box? >> Im starting to lose track of what I have installed ☹ >> >> Regards >> Michael Knill > > "cat /proc/cmdline" > > This is from the file: > > "/oldroot/cdrom/os/astlinux-xxx.run.conf" > > you can see in the line KCMD under "astlinux=xxx" the board type. > > Michael Michael http://www.mksolutions.info |
|
From: Lonnie A. <li...@lo...> - 2018-03-01 16:39:18
|
Hi Michael,
There is no direct string containing the vendor/model. By default we don't include the dmidecode command which can retrieve BIOS info, but not always accurate or useful.
A couple ideas ... (example APU2)
# cat /proc/cpuinfo | sed -n -r 's/^model name[[:space:]]*:[[:space:]]*(.+)$/\1/p'
AMD GX-412TC SOC
AMD GX-412TC SOC
AMD GX-412TC SOC
AMD GX-412TC SOC
You could generate a unique hash string from that ...
# cat /proc/cpuinfo | sed -n -r 's/^model name[[:space:]]*:[[:space:]]*(.+)$/\1/p' | tr -d ' \t' | sha1sum | cut -c 1-8
4e908e0f
Of course this is not totally unique, but for the common boards used with AstLinux it would probably be unique. But you would have to map the hash to a human readable string.
You could further refine it using the MAC address of the NIC's
# ip -o link show | sed -n -r 's#^.*link/ether ([0-9a-fA-F:]+).*$#\1#p'
00:0d:b9:01:02:24
00:0d:b9:01:02:25
00:0d:b9:01:02:26
00:0d:b9:01:02:25
Get the Vendor of the first MAC ...
# ip -o link show | sed -n -r 's#^.*link/ether ([0-9a-fA-F:]+).*$#\1#p' | xargs mac2vendor
PC Engines GmbH
You can create a very simple shell script to qualify your vendor/model.
--
#!/bin/sh
echo "Network Hardware: $(ip -o link show | sed -n -r 's#^.*link/ether ([0-9a-fA-F:]+).*$#\1#p' | xargs mac2vendor)"
echo "Memory: $(awk '/^MemTotal:/ { print int(($2 + 512) / 1024) }' /proc/meminfo) MB"
case $(cat /proc/cpuinfo | sed -n -r 's/^model name[[:space:]]*:[[:space:]]*(.+)$/\1/p' | tr -d ' \t' | sha1sum | cut -c 1-8) in
4e908e0f) echo "PC Engines APU2" ;;
f24bfcb8) echo "Jetway NF9HG-2930" ;;
173fdaba) echo "Soekris net5501" ;;
*) echo "Model Unknown" ;;
esac
--
Output for APU2:
--
Network Hardware: PC Engines GmbH
Memory: 3881 MB
PC Engines APU2
--
Lonnie
On Mar 1, 2018, at 4:49 AM, Michael Knill <mic...@ip...> wrote:
> Ah whoops sorry. Wrong terminology.
> I meant board vendor/model etc. E.g. is it an APU1, APU2, Jetway ????
>
> Regards
> Michael Knill
> On 1/3/18, 9:39 pm, "Michael Keuter" <li...@mk...> wrote:
>
>
>> Am 01.03.2018 um 11:25 schrieb Michael Knill <mic...@ip...>:
>>
>> Hi Group
>>
>> Is there an easy way to find what board type you have installed in an Astlinux box?
>> Im starting to lose track of what I have installed ☹
>>
>> Regards
>> Michael Knill
>
> "cat /proc/cmdline"
>
> This is from the file:
>
> "/oldroot/cdrom/os/astlinux-xxx.run.conf"
>
> you can see in the line KCMD under "astlinux=xxx" the board type.
>
> Michael
>
> http://www.mksolutions.info
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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....
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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....
|
|
From: Michael K. <mic...@ip...> - 2018-03-01 10:49:30
|
Ah whoops sorry. Wrong terminology.
I meant board vendor/model etc. E.g. is it an APU1, APU2, Jetway ????
Regards
Michael Knill
On 1/3/18, 9:39 pm, "Michael Keuter" <li...@mk...> wrote:
> Am 01.03.2018 um 11:25 schrieb Michael Knill <mic...@ip...>:
>
> Hi Group
>
> Is there an easy way to find what board type you have installed in an Astlinux box?
> Im starting to lose track of what I have installed ☹
>
> Regards
> Michael Knill
"cat /proc/cmdline"
This is from the file:
"/oldroot/cdrom/os/astlinux-xxx.run.conf"
you can see in the line KCMD under "astlinux=xxx" the board type.
Michael
http://www.mksolutions.info
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
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....
|
|
From: Michael K. <li...@mk...> - 2018-03-01 10:39:21
|
> Am 01.03.2018 um 11:25 schrieb Michael Knill <mic...@ip...>: > > Hi Group > > Is there an easy way to find what board type you have installed in an Astlinux box? > Im starting to lose track of what I have installed ☹ > > Regards > Michael Knill "cat /proc/cmdline" This is from the file: "/oldroot/cdrom/os/astlinux-xxx.run.conf" you can see in the line KCMD under "astlinux=xxx" the board type. Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2018-03-01 10:26:09
|
Hi Group Is there an easy way to find what board type you have installed in an Astlinux box? Im starting to lose track of what I have installed ☹ Regards Michael Knill |
|
From: Michael K. <mic...@ip...> - 2018-02-28 05:24:45
|
No sorry Michael. I have the new release out now and I will be progressively rolling it out. By default its not on as most of my sites use an IP Address hostname so its not necessary.
I think its going to be a while before it can prove itself but I will let you know.
It worked fine in the Lab as you can see below so I have no reason to believe that it wont work in production.
Regards
Michael Knill
On 21/2/18, 3:43 am, "Michael Keuter" <li...@mk...> wrote:
> Am 12.02.2018 um 10:46 schrieb Michael Knill <mic...@ip...>:
>
> Hi All
>
> Just though I would give some feedback on my testing. It appears to be all working in the lab:
>
> Script
> --------
> #!/bin/sh -e
> SHOW_TRUNKS="$(asterisk -x 'sip show peers' | grep $1)"
> if [[ $SHOW_TRUNKS != *"Unspecified"* ]] && [[ $SHOW_TRUNKS = *"UNKNOWN"* ]]; then
> echo "Trunk needs a reload"
> exit 1
> else
> echo "Trunk is normal"
> exit 0
> fi
>
> Monit Config
> -----------------
> check program Trunk-Monitor
> path /mnt/kd/scripts/trunk_monitor eict_trunk
> if status = 1 for 3 cycles then exec "/usr/sbin/asterisk -x 'module reload chan_sip.so'"
>
> Output Logs
> -----------------
> After outage with dnsmgr recovering the trunk ip address:
> sip show peers ->
> eict_trunk/0290010593 210.0.113.21 Yes Yes 5060 UNKNOWN
>
> Monit does its thing:
> Feb 12 20:31:16 3999-IBCBuild-CM1 daemon.warn monit[30658]: 'Trunk-Monitor' status failed (1) -- Trunk needs a reload
> Feb 12 20:32:16 3999-IBCBuild-CM1 daemon.warn monit[30658]: 'Trunk-Monitor' status failed (1) -- Trunk needs a reload
> Feb 12 20:33:16 3999-IBCBuild-CM1 daemon.err monit[30658]: 'Trunk-Monitor' status failed (1) -- Trunk needs a reload
> Feb 12 20:33:16 3999-IBCBuild-CM1 daemon.info monit[30658]: 'Trunk-Monitor' exec: '/usr/sbin/asterisk -x module reload chan_sip.so'
> Feb 12 20:33:17 3999-IBCBuild-CM1 local0.notice asterisk[30844]: NOTICE[30883]: chan_sip.c:24586 in handle_response_peerpoke: Peer 'eict_trunk' is now Reachable. (55ms / 5000ms)
> Feb 12 20:33:45 3999-IBCBuild-CM1 mail.info msmtp: host=smtp.ipcsolutions.com.au tls=on auth=on ......
> Feb 12 20:33:45 3999-IBCBuild-CM1 mail.info msmtpqueue: Success: /var/spool/mail/2018-02-12-20.33.16-0.msmtp
> Feb 12 20:35:16 3999-IBCBuild-CM1 daemon.info monit[30658]: 'Trunk-Monitor' status succeeded (0) -- Trunk is normal
> Feb 12 20:35:44 3999-IBCBuild-CM1 mail.info msmtp: host=smtp.ipcsolutions.com.au tls=on auth=on .......
> Feb 12 20:35:44 3999-IBCBuild-CM1 mail.info msmtpqueue: Success: /var/spool/mail/2018-02-12-20.35.16-0.msmtp
>
> sip show peers ->
> eict_trunk/0290010593 210.0.113.21 Yes Yes 5060 OK (55 ms)
>
> I will now need to see how it works in the real world.
> Yay Monit!
>
> Regards
> Michael Knill
Any real world experiences yet?
> From: Michael Knill <mic...@ip...>
> Reply-To: AstLinux List <ast...@li...>
> Date: Friday, 9 February 2018 at 9:30 am
> To: AstLinux List <ast...@li...>
> Subject: Re: [Astlinux-users] Network connectivity and DNS issues
>
> Thanks Michael yes that's my plan ☺
>
> Regards
> Michael Knill
> From: Michael Keuter <li...@mk...>
> Reply-To: AstLinux List <ast...@li...>
> Date: Friday, 9 February 2018 at 8:56 am
> To: AstLinux List <ast...@li...>
> Subject: Re: [Astlinux-users] Network connectivity and DNS issues
>
>
> Am 08.02.2018 um 22:04 schrieb Michael Knill <mic...@ip...>:
>
> Thanks Lonnie
>
> I will give Monit a try and let you know how I go.
> I will only turn on for some sites.
>
> Regards
> Michael Knill
>
> Hi Michael,
>
> in Monit you can run your own programs/scripts and then react on the return/exit value of that program. E.g.
>
> ----
> check program CPU-0_Temp with path "/mnt/kd/bin/monit/sensors_temp.sh 'Core 0'"
> if status > 70 then alert
> ----
>
>
>
> On 9/2/18, 2:49 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Michael,
>
>
>
> So my questions are:
> 1) What frequency of registrations or SIP OPTIONS are actually required to keep the firewall translation is place
>
> Depends on the network hardware in the path and the shortest firewall UDP TTL setting, AstLinux defaults to a 180 second UDP TTL for netfilter.ip_conntrack_udp_timeout_stream states.
>
> By default, in sip.conf, qualifyfreq=60 which sends SIP OPTIONS every 60 seconds. This should work for most situations.
>
> But, it seems in your situation the transient case with network issues can cause problems. Possibly setting qualify to something large like 64000 ms, qualify=64000 would enable the qualify feature but would not normally fail. Possibly mixed with qualifyfreq=30 . Warning, I have never tested or tried this.
>
>
>
>
> 2) Would it be feasible for Monit to check 'sip show peers' that if a trunk peer has a Host IP Address but is a Status of UNKNOWN then do a 'module reload chan_sip.so' and report it?
>
> Personally I don't use Monit, but in theory it may be possible.
>
> Lonnie
>
>
>
> On Feb 8, 2018, at 12:54 AM, Michael Knill <mic...@ip...> wrote:
>
>
>
> Sorry all I am dredging up this thread again. Thanks Lonnie for the info below.
> Although my main provider uses an IP Address based trunk which makes this problem go away, I have some providers that require registration via a DNS name.
> I have now activated dnsmgr which is good in that it will update the IP Address on the peer so it can reregister, HOWEVER the OPTIONS pings will not start up again if down after a reboot.
> I can turn off SIP OPTIONS (qualify=no) and put in a specific firewall rule I suppose but I would still rather have qualify=yes
>
> So my questions are:
> 1) What frequency of registrations or SIP OPTIONS are actually required to keep the firewall translation is place
> 2) Would it be feasible for Monit to check 'sip show peers' that if a trunk peer has a Host IP Address but is a Status of UNKNOWN then do a 'module reload chan_sip.so' and report it?
>
> Thanks all.
>
> Regards
> Michael Knill
>
> On 13/1/18, 6:38 am, "Michael Knill" <mic...@ip...> wrote:
>
> Thanks Lonnie
>
> I have confirmed with my main provider that their IP Address will likely never change to I will be putting the IP Address in sip.conf so I don't even need to set a static host.
> I do like to know the reachability of my trunks so I will keep the OPTIONS pings going.
>
> Thanks so much again for your help.
>
> Regards
> Michael Knill
>
> On 13/1/18, 2:42 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Hi Michael,
>
> The easiest way to always make sure a DNS name resolves is to define static IP addresses in:
>
> Network tab -> Network Services: -> DNS Forwarder & DHCP Server: { Configure DNS Hosts }
>
> There you can statically define DNS host names without requiring any changes to your Asterisk configuration. Of course if your SIP provider makes changes you will have to reconfigure the DNS IP's like a bunny.
>
>
> Another approach, or in tandem, is to not depend on OPTIONS pings (qualify=yes) to keep firewall ports open, instead (qualify=no) use very specific (secure) firewall rules for inbound SIP calls.
>
>
> To be clear, it is not recommended to do either of the above as a general practice, but you do what you have to do.
>
> Lonnie
>
>
> On Jan 11, 2018, at 10:50 PM, Michael Knill <mic...@ip...> wrote:
>
>
>
> Hi Group
>
> I have started a new thread although this is a continuation of my intermittent issues with sip trunks not coming back after a network outage.
> After some testing in the lab I have realised that most of these problems are related to DNS resolution.
>
> Basically I am using sip domain names for all my providers so DNS resolution is necessary. What I have found is that if for some reason DNS resolution is not possible (e.g. network is down), if the system is rebooted or Asterisk loses the resolved address, it no longer sends the OPTIONS pings as it cant find the address obviously.
> Yes that makes sense however the problem arises when the network is restored, Asterisk is completely unaware and therefore makes no attempt in resolving the address.
> I believe this is what is causing my intermittent issues which is easily resolved by doing an Asterisk Reload when network connectivity is restored. I have also enabled the Asterisk dnsmgr which does not fix the problem. I suspect that if it couldn't initially resolve it then it gives up totally.
>
> So what is the fix. Here are some of my options:
> • Don't use DNS but just use the IP Address instead. This will most certainly resolve the issue but is it the best way? Something in the Hosts file maybe?
> • Perform sip monitoring using the SIP Monitor script or Monit. If the SIP URL is resolvable but the status is UNKNOWN then issue a module reload of chan_sip
> • Something else
>
> PS the SIP Monitor does not seem to work for me. It only sends me an email when the system is rebooted.
> Thanks all.
>
> Regards
> Michael Knill
Michael
http://www.mksolutions.info
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
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....
|
|
From: Michael K. <mic...@ip...> - 2018-02-28 05:24:21
|
Hi Group I have noticed quite a few security fixes between 1.3.1 & 1.3.2. I have just done a new release on 1.3.1 but I am feeling that I should go directly to 1.3.2 because of these many fixes. Is there much of a difference? Any major vulnerabilities? Thanks Regards Michael Knill |
|
From: Dan R. <da...@ry...> - 2018-02-27 00:51:51
|
I'm happy to upgrade. Thanks. -------- Original message --------From: Lonnie Abelbeck <li...@lo...> Date: 2/26/18 1:47 PM (GMT-05:00) To: AstLinux Users Mailing List <ast...@li...> Subject: [Astlinux-users] Any Zabbix users ? The AstLinux Team is querying our users, wondering if there are any Zabbix users out there ? Darrick uses Zabbix extensively, but would like to change agent/proxy versions from 2.2 LTS to 3.0 LTS. This change would also require Zabbix 3.0 or higher at the server end. Would switching to Zabbix 3.0 LTS (3.0.14) be a problem for anyone ? The AstLinux Team ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ 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.... |
|
From: Michael K. <mic...@ip...> - 2018-02-26 22:15:45
|
No sorry Michael. I have the new release out now and I will be progressively rolling it out. By default its not on as most of my sites use an IP Address hostname so its not necessary.
I think its going to be a while before it can prove itself but I will let you know.
It worked fine in the Lab as you can see below so I have no reason to believe that it wont work in production.
Regards
Michael Knill
On 21/2/18, 3:43 am, "Michael Keuter" <li...@mk...> wrote:
> Am 12.02.2018 um 10:46 schrieb Michael Knill <mic...@ip...>:
>
> Hi All
>
> Just though I would give some feedback on my testing. It appears to be all working in the lab:
>
> Script
> --------
> #!/bin/sh -e
> SHOW_TRUNKS="$(asterisk -x 'sip show peers' | grep $1)"
> if [[ $SHOW_TRUNKS != *"Unspecified"* ]] && [[ $SHOW_TRUNKS = *"UNKNOWN"* ]]; then
> echo "Trunk needs a reload"
> exit 1
> else
> echo "Trunk is normal"
> exit 0
> fi
>
> Monit Config
> -----------------
> check program Trunk-Monitor
> path /mnt/kd/scripts/trunk_monitor eict_trunk
> if status = 1 for 3 cycles then exec "/usr/sbin/asterisk -x 'module reload chan_sip.so'"
>
> Output Logs
> -----------------
> After outage with dnsmgr recovering the trunk ip address:
> sip show peers ->
> eict_trunk/0290010593 210.0.113.21 Yes Yes 5060 UNKNOWN
>
> Monit does its thing:
> Feb 12 20:31:16 3999-IBCBuild-CM1 daemon.warn monit[30658]: 'Trunk-Monitor' status failed (1) -- Trunk needs a reload
> Feb 12 20:32:16 3999-IBCBuild-CM1 daemon.warn monit[30658]: 'Trunk-Monitor' status failed (1) -- Trunk needs a reload
> Feb 12 20:33:16 3999-IBCBuild-CM1 daemon.err monit[30658]: 'Trunk-Monitor' status failed (1) -- Trunk needs a reload
> Feb 12 20:33:16 3999-IBCBuild-CM1 daemon.info monit[30658]: 'Trunk-Monitor' exec: '/usr/sbin/asterisk -x module reload chan_sip.so'
> Feb 12 20:33:17 3999-IBCBuild-CM1 local0.notice asterisk[30844]: NOTICE[30883]: chan_sip.c:24586 in handle_response_peerpoke: Peer 'eict_trunk' is now Reachable. (55ms / 5000ms)
> Feb 12 20:33:45 3999-IBCBuild-CM1 mail.info msmtp: host=smtp.ipcsolutions.com.au tls=on auth=on ......
> Feb 12 20:33:45 3999-IBCBuild-CM1 mail.info msmtpqueue: Success: /var/spool/mail/2018-02-12-20.33.16-0.msmtp
> Feb 12 20:35:16 3999-IBCBuild-CM1 daemon.info monit[30658]: 'Trunk-Monitor' status succeeded (0) -- Trunk is normal
> Feb 12 20:35:44 3999-IBCBuild-CM1 mail.info msmtp: host=smtp.ipcsolutions.com.au tls=on auth=on .......
> Feb 12 20:35:44 3999-IBCBuild-CM1 mail.info msmtpqueue: Success: /var/spool/mail/2018-02-12-20.35.16-0.msmtp
>
> sip show peers ->
> eict_trunk/0290010593 210.0.113.21 Yes Yes 5060 OK (55 ms)
>
> I will now need to see how it works in the real world.
> Yay Monit!
>
> Regards
> Michael Knill
Any real world experiences yet?
> From: Michael Knill <mic...@ip...>
> Reply-To: AstLinux List <ast...@li...>
> Date: Friday, 9 February 2018 at 9:30 am
> To: AstLinux List <ast...@li...>
> Subject: Re: [Astlinux-users] Network connectivity and DNS issues
>
> Thanks Michael yes that's my plan ☺
>
> Regards
> Michael Knill
> From: Michael Keuter <li...@mk...>
> Reply-To: AstLinux List <ast...@li...>
> Date: Friday, 9 February 2018 at 8:56 am
> To: AstLinux List <ast...@li...>
> Subject: Re: [Astlinux-users] Network connectivity and DNS issues
>
>
> Am 08.02.2018 um 22:04 schrieb Michael Knill <mic...@ip...>:
>
> Thanks Lonnie
>
> I will give Monit a try and let you know how I go.
> I will only turn on for some sites.
>
> Regards
> Michael Knill
>
> Hi Michael,
>
> in Monit you can run your own programs/scripts and then react on the return/exit value of that program. E.g.
>
> ----
> check program CPU-0_Temp with path "/mnt/kd/bin/monit/sensors_temp.sh 'Core 0'"
> if status > 70 then alert
> ----
>
>
>
> On 9/2/18, 2:49 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Michael,
>
>
>
> So my questions are:
> 1) What frequency of registrations or SIP OPTIONS are actually required to keep the firewall translation is place
>
> Depends on the network hardware in the path and the shortest firewall UDP TTL setting, AstLinux defaults to a 180 second UDP TTL for netfilter.ip_conntrack_udp_timeout_stream states.
>
> By default, in sip.conf, qualifyfreq=60 which sends SIP OPTIONS every 60 seconds. This should work for most situations.
>
> But, it seems in your situation the transient case with network issues can cause problems. Possibly setting qualify to something large like 64000 ms, qualify=64000 would enable the qualify feature but would not normally fail. Possibly mixed with qualifyfreq=30 . Warning, I have never tested or tried this.
>
>
>
>
> 2) Would it be feasible for Monit to check 'sip show peers' that if a trunk peer has a Host IP Address but is a Status of UNKNOWN then do a 'module reload chan_sip.so' and report it?
>
> Personally I don't use Monit, but in theory it may be possible.
>
> Lonnie
>
>
>
> On Feb 8, 2018, at 12:54 AM, Michael Knill <mic...@ip...> wrote:
>
>
>
> Sorry all I am dredging up this thread again. Thanks Lonnie for the info below.
> Although my main provider uses an IP Address based trunk which makes this problem go away, I have some providers that require registration via a DNS name.
> I have now activated dnsmgr which is good in that it will update the IP Address on the peer so it can reregister, HOWEVER the OPTIONS pings will not start up again if down after a reboot.
> I can turn off SIP OPTIONS (qualify=no) and put in a specific firewall rule I suppose but I would still rather have qualify=yes
>
> So my questions are:
> 1) What frequency of registrations or SIP OPTIONS are actually required to keep the firewall translation is place
> 2) Would it be feasible for Monit to check 'sip show peers' that if a trunk peer has a Host IP Address but is a Status of UNKNOWN then do a 'module reload chan_sip.so' and report it?
>
> Thanks all.
>
> Regards
> Michael Knill
>
> On 13/1/18, 6:38 am, "Michael Knill" <mic...@ip...> wrote:
>
> Thanks Lonnie
>
> I have confirmed with my main provider that their IP Address will likely never change to I will be putting the IP Address in sip.conf so I don't even need to set a static host.
> I do like to know the reachability of my trunks so I will keep the OPTIONS pings going.
>
> Thanks so much again for your help.
>
> Regards
> Michael Knill
>
> On 13/1/18, 2:42 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Hi Michael,
>
> The easiest way to always make sure a DNS name resolves is to define static IP addresses in:
>
> Network tab -> Network Services: -> DNS Forwarder & DHCP Server: { Configure DNS Hosts }
>
> There you can statically define DNS host names without requiring any changes to your Asterisk configuration. Of course if your SIP provider makes changes you will have to reconfigure the DNS IP's like a bunny.
>
>
> Another approach, or in tandem, is to not depend on OPTIONS pings (qualify=yes) to keep firewall ports open, instead (qualify=no) use very specific (secure) firewall rules for inbound SIP calls.
>
>
> To be clear, it is not recommended to do either of the above as a general practice, but you do what you have to do.
>
> Lonnie
>
>
> On Jan 11, 2018, at 10:50 PM, Michael Knill <mic...@ip...> wrote:
>
>
>
> Hi Group
>
> I have started a new thread although this is a continuation of my intermittent issues with sip trunks not coming back after a network outage.
> After some testing in the lab I have realised that most of these problems are related to DNS resolution.
>
> Basically I am using sip domain names for all my providers so DNS resolution is necessary. What I have found is that if for some reason DNS resolution is not possible (e.g. network is down), if the system is rebooted or Asterisk loses the resolved address, it no longer sends the OPTIONS pings as it cant find the address obviously.
> Yes that makes sense however the problem arises when the network is restored, Asterisk is completely unaware and therefore makes no attempt in resolving the address.
> I believe this is what is causing my intermittent issues which is easily resolved by doing an Asterisk Reload when network connectivity is restored. I have also enabled the Asterisk dnsmgr which does not fix the problem. I suspect that if it couldn't initially resolve it then it gives up totally.
>
> So what is the fix. Here are some of my options:
> • Don't use DNS but just use the IP Address instead. This will most certainly resolve the issue but is it the best way? Something in the Hosts file maybe?
> • Perform sip monitoring using the SIP Monitor script or Monit. If the SIP URL is resolvable but the status is UNKNOWN then issue a module reload of chan_sip
> • Something else
>
> PS the SIP Monitor does not seem to work for me. It only sends me an email when the system is rebooted.
> Thanks all.
>
> Regards
> Michael Knill
Michael
http://www.mksolutions.info
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
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....
|
|
From: Michael K. <mic...@ip...> - 2018-02-26 20:41:41
|
I would like to use it one day but Monit is sufficient for me at the moment.
So all good with me.
Regards
Michael Knill
On 27/2/18, 5:47 am, "Lonnie Abelbeck" <li...@lo...> wrote:
The AstLinux Team is querying our users, wondering if there are any Zabbix users out there ?
Darrick uses Zabbix extensively, but would like to change agent/proxy versions from 2.2 LTS to 3.0 LTS. This change would also require Zabbix 3.0 or higher at the server end.
Would switching to Zabbix 3.0 LTS (3.0.14) be a problem for anyone ?
The AstLinux Team
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
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....
|
|
From: Lonnie A. <li...@lo...> - 2018-02-26 18:47:31
|
The AstLinux Team is querying our users, wondering if there are any Zabbix users out there ? Darrick uses Zabbix extensively, but would like to change agent/proxy versions from 2.2 LTS to 3.0 LTS. This change would also require Zabbix 3.0 or higher at the server end. Would switching to Zabbix 3.0 LTS (3.0.14) be a problem for anyone ? The AstLinux Team |
|
From: Michael K. <mic...@ip...> - 2018-02-23 23:55:29
|
Thanks Lonnie
Regards
Michael Knill
On 24/2/18, 10:25 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
AstLinux ChangeLog ...
https://raw.githubusercontent.com/astlinux-project/astlinux/1.3.2/docs/ChangeLog.txt
There are no "Critical" security fixes in 1.3.2, but many moderate ones. We always encourage users to upgrade to the latest version.
Lonnie
On Feb 20, 2018, at 4:46 PM, Michael Knill <mic...@ip...> wrote:
> Hi Group
>
> I have noticed quite a few security fixes between 1.3.1 & 1.3.2.
> I have just done a new release on 1.3.1 but I am feeling that I should go directly to 1.3.2 because of these many fixes.
>
> Is there much of a difference? Any major vulnerabilities?
>
> Thanks
>
> Regards
> Michael Knill
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> 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....
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
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....
|
|
From: Lonnie A. <li...@lo...> - 2018-02-23 23:23:28
|
Hi Michael, AstLinux ChangeLog ... https://raw.githubusercontent.com/astlinux-project/astlinux/1.3.2/docs/ChangeLog.txt There are no "Critical" security fixes in 1.3.2, but many moderate ones. We always encourage users to upgrade to the latest version. Lonnie On Feb 20, 2018, at 4:46 PM, Michael Knill <mic...@ip...> wrote: > Hi Group > > I have noticed quite a few security fixes between 1.3.1 & 1.3.2. > I have just done a new release on 1.3.1 but I am feeling that I should go directly to 1.3.2 because of these many fixes. > > Is there much of a difference? Any major vulnerabilities? > > Thanks > > Regards > Michael Knill > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ > 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.... |
|
From: Michael K. <mic...@ip...> - 2018-02-23 22:45:29
|
Hi Group I have noticed quite a few security fixes between 1.3.1 & 1.3.2. I have just done a new release on 1.3.1 but I am feeling that I should go directly to 1.3.2 because of these many fixes. Is there much of a difference? Any major vulnerabilities? Thanks Regards Michael Knill |
|
From: Michael K. <mic...@ip...> - 2018-02-23 20:12:16
|
Hi Group Sorry if I have set this twice. I didn't see it in the list. I have noticed quite a few security fixes between 1.3.1 & 1.3.2. I have just done a new release on 1.3.1 but I am feeling that I should go directly to 1.3.2 because of these many fixes. Is there much of a difference? Any major vulnerabilities? Thanks Regards Michael Knill |
|
From: Michael K. <li...@mk...> - 2018-02-20 14:53:02
|
> Am 12.02.2018 um 10:46 schrieb Michael Knill <mic...@ip...>: > > Hi All > > Just though I would give some feedback on my testing. It appears to be all working in the lab: > > Script > -------- > #!/bin/sh -e > SHOW_TRUNKS="$(asterisk -x 'sip show peers' | grep $1)" > if [[ $SHOW_TRUNKS != *"Unspecified"* ]] && [[ $SHOW_TRUNKS = *"UNKNOWN"* ]]; then > echo "Trunk needs a reload" > exit 1 > else > echo "Trunk is normal" > exit 0 > fi > > Monit Config > ----------------- > check program Trunk-Monitor > path /mnt/kd/scripts/trunk_monitor eict_trunk > if status = 1 for 3 cycles then exec "/usr/sbin/asterisk -x 'module reload chan_sip.so'" > > Output Logs > ----------------- > After outage with dnsmgr recovering the trunk ip address: > sip show peers -> > eict_trunk/0290010593 210.0.113.21 Yes Yes 5060 UNKNOWN > > Monit does its thing: > Feb 12 20:31:16 3999-IBCBuild-CM1 daemon.warn monit[30658]: 'Trunk-Monitor' status failed (1) -- Trunk needs a reload > Feb 12 20:32:16 3999-IBCBuild-CM1 daemon.warn monit[30658]: 'Trunk-Monitor' status failed (1) -- Trunk needs a reload > Feb 12 20:33:16 3999-IBCBuild-CM1 daemon.err monit[30658]: 'Trunk-Monitor' status failed (1) -- Trunk needs a reload > Feb 12 20:33:16 3999-IBCBuild-CM1 daemon.info monit[30658]: 'Trunk-Monitor' exec: '/usr/sbin/asterisk -x module reload chan_sip.so' > Feb 12 20:33:17 3999-IBCBuild-CM1 local0.notice asterisk[30844]: NOTICE[30883]: chan_sip.c:24586 in handle_response_peerpoke: Peer 'eict_trunk' is now Reachable. (55ms / 5000ms) > Feb 12 20:33:45 3999-IBCBuild-CM1 mail.info msmtp: host=smtp.ipcsolutions.com.au tls=on auth=on ...... > Feb 12 20:33:45 3999-IBCBuild-CM1 mail.info msmtpqueue: Success: /var/spool/mail/2018-02-12-20.33.16-0.msmtp > Feb 12 20:35:16 3999-IBCBuild-CM1 daemon.info monit[30658]: 'Trunk-Monitor' status succeeded (0) -- Trunk is normal > Feb 12 20:35:44 3999-IBCBuild-CM1 mail.info msmtp: host=smtp.ipcsolutions.com.au tls=on auth=on ....... > Feb 12 20:35:44 3999-IBCBuild-CM1 mail.info msmtpqueue: Success: /var/spool/mail/2018-02-12-20.35.16-0.msmtp > > sip show peers -> > eict_trunk/0290010593 210.0.113.21 Yes Yes 5060 OK (55 ms) > > I will now need to see how it works in the real world. > Yay Monit! > > Regards > Michael Knill Any real world experiences yet? > From: Michael Knill <mic...@ip...> > Reply-To: AstLinux List <ast...@li...> > Date: Friday, 9 February 2018 at 9:30 am > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Network connectivity and DNS issues > > Thanks Michael yes that's my plan ☺ > > Regards > Michael Knill > From: Michael Keuter <li...@mk...> > Reply-To: AstLinux List <ast...@li...> > Date: Friday, 9 February 2018 at 8:56 am > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Network connectivity and DNS issues > > > Am 08.02.2018 um 22:04 schrieb Michael Knill <mic...@ip...>: > > Thanks Lonnie > > I will give Monit a try and let you know how I go. > I will only turn on for some sites. > > Regards > Michael Knill > > Hi Michael, > > in Monit you can run your own programs/scripts and then react on the return/exit value of that program. E.g. > > ---- > check program CPU-0_Temp with path "/mnt/kd/bin/monit/sensors_temp.sh 'Core 0'" > if status > 70 then alert > ---- > > > > On 9/2/18, 2:49 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > Michael, > > > > So my questions are: > 1) What frequency of registrations or SIP OPTIONS are actually required to keep the firewall translation is place > > Depends on the network hardware in the path and the shortest firewall UDP TTL setting, AstLinux defaults to a 180 second UDP TTL for netfilter.ip_conntrack_udp_timeout_stream states. > > By default, in sip.conf, qualifyfreq=60 which sends SIP OPTIONS every 60 seconds. This should work for most situations. > > But, it seems in your situation the transient case with network issues can cause problems. Possibly setting qualify to something large like 64000 ms, qualify=64000 would enable the qualify feature but would not normally fail. Possibly mixed with qualifyfreq=30 . Warning, I have never tested or tried this. > > > > > 2) Would it be feasible for Monit to check 'sip show peers' that if a trunk peer has a Host IP Address but is a Status of UNKNOWN then do a 'module reload chan_sip.so' and report it? > > Personally I don't use Monit, but in theory it may be possible. > > Lonnie > > > > On Feb 8, 2018, at 12:54 AM, Michael Knill <mic...@ip...> wrote: > > > > Sorry all I am dredging up this thread again. Thanks Lonnie for the info below. > Although my main provider uses an IP Address based trunk which makes this problem go away, I have some providers that require registration via a DNS name. > I have now activated dnsmgr which is good in that it will update the IP Address on the peer so it can reregister, HOWEVER the OPTIONS pings will not start up again if down after a reboot. > I can turn off SIP OPTIONS (qualify=no) and put in a specific firewall rule I suppose but I would still rather have qualify=yes > > So my questions are: > 1) What frequency of registrations or SIP OPTIONS are actually required to keep the firewall translation is place > 2) Would it be feasible for Monit to check 'sip show peers' that if a trunk peer has a Host IP Address but is a Status of UNKNOWN then do a 'module reload chan_sip.so' and report it? > > Thanks all. > > Regards > Michael Knill > > On 13/1/18, 6:38 am, "Michael Knill" <mic...@ip...> wrote: > > Thanks Lonnie > > I have confirmed with my main provider that their IP Address will likely never change to I will be putting the IP Address in sip.conf so I don't even need to set a static host. > I do like to know the reachability of my trunks so I will keep the OPTIONS pings going. > > Thanks so much again for your help. > > Regards > Michael Knill > > On 13/1/18, 2:42 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > Hi Michael, > > The easiest way to always make sure a DNS name resolves is to define static IP addresses in: > > Network tab -> Network Services: -> DNS Forwarder & DHCP Server: { Configure DNS Hosts } > > There you can statically define DNS host names without requiring any changes to your Asterisk configuration. Of course if your SIP provider makes changes you will have to reconfigure the DNS IP's like a bunny. > > > Another approach, or in tandem, is to not depend on OPTIONS pings (qualify=yes) to keep firewall ports open, instead (qualify=no) use very specific (secure) firewall rules for inbound SIP calls. > > > To be clear, it is not recommended to do either of the above as a general practice, but you do what you have to do. > > Lonnie > > > On Jan 11, 2018, at 10:50 PM, Michael Knill <mic...@ip...> wrote: > > > > Hi Group > > I have started a new thread although this is a continuation of my intermittent issues with sip trunks not coming back after a network outage. > After some testing in the lab I have realised that most of these problems are related to DNS resolution. > > Basically I am using sip domain names for all my providers so DNS resolution is necessary. What I have found is that if for some reason DNS resolution is not possible (e.g. network is down), if the system is rebooted or Asterisk loses the resolved address, it no longer sends the OPTIONS pings as it cant find the address obviously. > Yes that makes sense however the problem arises when the network is restored, Asterisk is completely unaware and therefore makes no attempt in resolving the address. > I believe this is what is causing my intermittent issues which is easily resolved by doing an Asterisk Reload when network connectivity is restored. I have also enabled the Asterisk dnsmgr which does not fix the problem. I suspect that if it couldn't initially resolve it then it gives up totally. > > So what is the fix. Here are some of my options: > • Don't use DNS but just use the IP Address instead. This will most certainly resolve the issue but is it the best way? Something in the Hosts file maybe? > • Perform sip monitoring using the SIP Monitor script or Monit. If the SIP URL is resolvable but the status is UNKNOWN then issue a module reload of chan_sip > • Something else > > PS the SIP Monitor does not seem to work for me. It only sends me an email when the system is rebooted. > Thanks all. > > Regards > Michael Knill Michael http://www.mksolutions.info |
|
From: Michael K. <li...@mk...> - 2018-02-12 09:55:39
|
> Am 12.02.2018 um 10:46 schrieb Michael Knill <mic...@ip...>: > > Hi All > > Just though I would give some feedback on my testing. It appears to be all working in the lab: > > Script > -------- > #!/bin/sh -e > SHOW_TRUNKS="$(asterisk -x 'sip show peers' | grep $1)" > if [[ $SHOW_TRUNKS != *"Unspecified"* ]] && [[ $SHOW_TRUNKS = *"UNKNOWN"* ]]; then > echo "Trunk needs a reload" > exit 1 > else > echo "Trunk is normal" > exit 0 > fi > > Monit Config > ----------------- > check program Trunk-Monitor > path /mnt/kd/scripts/trunk_monitor eict_trunk > if status = 1 for 3 cycles then exec "/usr/sbin/asterisk -x 'module reload chan_sip.so'" > > Output Logs > ----------------- > After outage with dnsmgr recovering the trunk ip address: > sip show peers -> > eict_trunk/0290010593 210.0.113.21 Yes Yes 5060 UNKNOWN > > Monit does its thing: > Feb 12 20:31:16 3999-IBCBuild-CM1 daemon.warn monit[30658]: 'Trunk-Monitor' status failed (1) -- Trunk needs a reload > Feb 12 20:32:16 3999-IBCBuild-CM1 daemon.warn monit[30658]: 'Trunk-Monitor' status failed (1) -- Trunk needs a reload > Feb 12 20:33:16 3999-IBCBuild-CM1 daemon.err monit[30658]: 'Trunk-Monitor' status failed (1) -- Trunk needs a reload > Feb 12 20:33:16 3999-IBCBuild-CM1 daemon.info monit[30658]: 'Trunk-Monitor' exec: '/usr/sbin/asterisk -x module reload chan_sip.so' > Feb 12 20:33:17 3999-IBCBuild-CM1 local0.notice asterisk[30844]: NOTICE[30883]: chan_sip.c:24586 in handle_response_peerpoke: Peer 'eict_trunk' is now Reachable. (55ms / 5000ms) > Feb 12 20:33:45 3999-IBCBuild-CM1 mail.info msmtp: host=smtp.ipcsolutions.com.au tls=on auth=on ...... > Feb 12 20:33:45 3999-IBCBuild-CM1 mail.info msmtpqueue: Success: /var/spool/mail/2018-02-12-20.33.16-0.msmtp > Feb 12 20:35:16 3999-IBCBuild-CM1 daemon.info monit[30658]: 'Trunk-Monitor' status succeeded (0) -- Trunk is normal > Feb 12 20:35:44 3999-IBCBuild-CM1 mail.info msmtp: host=smtp.ipcsolutions.com.au tls=on auth=on ....... > Feb 12 20:35:44 3999-IBCBuild-CM1 mail.info msmtpqueue: Success: /var/spool/mail/2018-02-12-20.35.16-0.msmtp > > sip show peers -> > eict_trunk/0290010593 210.0.113.21 Yes Yes 5060 OK (55 ms) > > I will now need to see how it works in the real world. > Yay Monit! Hi Michael, in my problem cases I also tried reloading chan_sip and restarting Asterisk, but only a reboot of the system worked for me. So good luck. > Regards > Michael Knill > From: Michael Knill <mic...@ip...> > Reply-To: AstLinux List <ast...@li...> > Date: Friday, 9 February 2018 at 9:30 am > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Network connectivity and DNS issues > > Thanks Michael yes that's my plan ☺ > > Regards > Michael Knill > From: Michael Keuter <li...@mk...> > Reply-To: AstLinux List <ast...@li...> > Date: Friday, 9 February 2018 at 8:56 am > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Network connectivity and DNS issues > > > Am 08.02.2018 um 22:04 schrieb Michael Knill <mic...@ip...>: > > Thanks Lonnie > > I will give Monit a try and let you know how I go. > I will only turn on for some sites. > > Regards > Michael Knill > > Hi Michael, > > in Monit you can run your own programs/scripts and then react on the return/exit value of that program. E.g. > > ---- > check program CPU-0_Temp with path "/mnt/kd/bin/monit/sensors_temp.sh 'Core 0'" > if status > 70 then alert > ---- > > > > On 9/2/18, 2:49 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > Michael, > > > > So my questions are: > 1) What frequency of registrations or SIP OPTIONS are actually required to keep the firewall translation is place > > Depends on the network hardware in the path and the shortest firewall UDP TTL setting, AstLinux defaults to a 180 second UDP TTL for netfilter.ip_conntrack_udp_timeout_stream states. > > By default, in sip.conf, qualifyfreq=60 which sends SIP OPTIONS every 60 seconds. This should work for most situations. > > But, it seems in your situation the transient case with network issues can cause problems. Possibly setting qualify to something large like 64000 ms, qualify=64000 would enable the qualify feature but would not normally fail. Possibly mixed with qualifyfreq=30 . Warning, I have never tested or tried this. > > > > > 2) Would it be feasible for Monit to check 'sip show peers' that if a trunk peer has a Host IP Address but is a Status of UNKNOWN then do a 'module reload chan_sip.so' and report it? > > Personally I don't use Monit, but in theory it may be possible. > > Lonnie > > > > On Feb 8, 2018, at 12:54 AM, Michael Knill <mic...@ip...> wrote: > > > > Sorry all I am dredging up this thread again. Thanks Lonnie for the info below. > Although my main provider uses an IP Address based trunk which makes this problem go away, I have some providers that require registration via a DNS name. > I have now activated dnsmgr which is good in that it will update the IP Address on the peer so it can reregister, HOWEVER the OPTIONS pings will not start up again if down after a reboot. > I can turn off SIP OPTIONS (qualify=no) and put in a specific firewall rule I suppose but I would still rather have qualify=yes > > So my questions are: > 1) What frequency of registrations or SIP OPTIONS are actually required to keep the firewall translation is place > 2) Would it be feasible for Monit to check 'sip show peers' that if a trunk peer has a Host IP Address but is a Status of UNKNOWN then do a 'module reload chan_sip.so' and report it? > > Thanks all. > > Regards > Michael Knill > > On 13/1/18, 6:38 am, "Michael Knill" <mic...@ip...> wrote: > > Thanks Lonnie > > I have confirmed with my main provider that their IP Address will likely never change to I will be putting the IP Address in sip.conf so I don't even need to set a static host. > I do like to know the reachability of my trunks so I will keep the OPTIONS pings going. > > Thanks so much again for your help. > > Regards > Michael Knill > > On 13/1/18, 2:42 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > Hi Michael, > > The easiest way to always make sure a DNS name resolves is to define static IP addresses in: > > Network tab -> Network Services: -> DNS Forwarder & DHCP Server: { Configure DNS Hosts } > > There you can statically define DNS host names without requiring any changes to your Asterisk configuration. Of course if your SIP provider makes changes you will have to reconfigure the DNS IP's like a bunny. > > > Another approach, or in tandem, is to not depend on OPTIONS pings (qualify=yes) to keep firewall ports open, instead (qualify=no) use very specific (secure) firewall rules for inbound SIP calls. > > > To be clear, it is not recommended to do either of the above as a general practice, but you do what you have to do. > > Lonnie > > > On Jan 11, 2018, at 10:50 PM, Michael Knill <mic...@ip...> wrote: > > > > Hi Group > > I have started a new thread although this is a continuation of my intermittent issues with sip trunks not coming back after a network outage. > After some testing in the lab I have realised that most of these problems are related to DNS resolution. > > Basically I am using sip domain names for all my providers so DNS resolution is necessary. What I have found is that if for some reason DNS resolution is not possible (e.g. network is down), if the system is rebooted or Asterisk loses the resolved address, it no longer sends the OPTIONS pings as it cant find the address obviously. > Yes that makes sense however the problem arises when the network is restored, Asterisk is completely unaware and therefore makes no attempt in resolving the address. > I believe this is what is causing my intermittent issues which is easily resolved by doing an Asterisk Reload when network connectivity is restored. I have also enabled the Asterisk dnsmgr which does not fix the problem. I suspect that if it couldn't initially resolve it then it gives up totally. > > So what is the fix. Here are some of my options: > • Don't use DNS but just use the IP Address instead. This will most certainly resolve the issue but is it the best way? Something in the Hosts file maybe? > • Perform sip monitoring using the SIP Monitor script or Monit. If the SIP URL is resolvable but the status is UNKNOWN then issue a module reload of chan_sip > • Something else > > PS the SIP Monitor does not seem to work for me. It only sends me an email when the system is rebooted. > Thanks all. > > Regards > Michael Knill > > Michael > > http://www.mksolutions.info Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2018-02-12 09:46:31
|
Hi All Just though I would give some feedback on my testing. It appears to be all working in the lab: Script -------- #!/bin/sh -e SHOW_TRUNKS="$(asterisk -x 'sip show peers' | grep $1)" if [[ $SHOW_TRUNKS != *"Unspecified"* ]] && [[ $SHOW_TRUNKS = *"UNKNOWN"* ]]; then echo "Trunk needs a reload" exit 1 else echo "Trunk is normal" exit 0 fi Monit Config ----------------- check program Trunk-Monitor path /mnt/kd/scripts/trunk_monitor eict_trunk if status = 1 for 3 cycles then exec "/usr/sbin/asterisk -x 'module reload chan_sip.so'" Output Logs ----------------- After outage with dnsmgr recovering the trunk ip address: sip show peers -> eict_trunk/0290010593 210.0.113.21 Yes Yes 5060 UNKNOWN Monit does its thing: Feb 12 20:31:16 3999-IBCBuild-CM1 daemon.warn monit[30658]: 'Trunk-Monitor' status failed (1) -- Trunk needs a reload Feb 12 20:32:16 3999-IBCBuild-CM1 daemon.warn monit[30658]: 'Trunk-Monitor' status failed (1) -- Trunk needs a reload Feb 12 20:33:16 3999-IBCBuild-CM1 daemon.err monit[30658]: 'Trunk-Monitor' status failed (1) -- Trunk needs a reload Feb 12 20:33:16 3999-IBCBuild-CM1 daemon.info monit[30658]: 'Trunk-Monitor' exec: '/usr/sbin/asterisk -x module reload chan_sip.so' Feb 12 20:33:17 3999-IBCBuild-CM1 local0.notice asterisk[30844]: NOTICE[30883]: chan_sip.c:24586 in handle_response_peerpoke: Peer 'eict_trunk' is now Reachable. (55ms / 5000ms) Feb 12 20:33:45 3999-IBCBuild-CM1 mail.info msmtp: host=smtp.ipcsolutions.com.au tls=on auth=on ...... Feb 12 20:33:45 3999-IBCBuild-CM1 mail.info msmtpqueue: Success: /var/spool/mail/2018-02-12-20.33.16-0.msmtp Feb 12 20:35:16 3999-IBCBuild-CM1 daemon.info monit[30658]: 'Trunk-Monitor' status succeeded (0) -- Trunk is normal Feb 12 20:35:44 3999-IBCBuild-CM1 mail.info msmtp: host=smtp.ipcsolutions.com.au tls=on auth=on ....... Feb 12 20:35:44 3999-IBCBuild-CM1 mail.info msmtpqueue: Success: /var/spool/mail/2018-02-12-20.35.16-0.msmtp sip show peers -> eict_trunk/0290010593 210.0.113.21 Yes Yes 5060 OK (55 ms) I will now need to see how it works in the real world. Yay Monit! Regards Michael Knill From: Michael Knill <mic...@ip...> Reply-To: AstLinux List <ast...@li...> Date: Friday, 9 February 2018 at 9:30 am To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Network connectivity and DNS issues Thanks Michael yes that's my plan ☺ Regards Michael Knill From: Michael Keuter <li...@mk...> Reply-To: AstLinux List <ast...@li...> Date: Friday, 9 February 2018 at 8:56 am To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Network connectivity and DNS issues Am 08.02.2018 um 22:04 schrieb Michael Knill <mic...@ip...<mailto:mic...@ip...>>: Thanks Lonnie I will give Monit a try and let you know how I go. I will only turn on for some sites. Regards Michael Knill Hi Michael, in Monit you can run your own programs/scripts and then react on the return/exit value of that program. E.g. ---- check program CPU-0_Temp with path "/mnt/kd/bin/monit/sensors_temp.sh 'Core 0'" if status > 70 then alert ---- On 9/2/18, 2:49 am, "Lonnie Abelbeck" <li...@lo...<mailto:li...@lo...>> wrote: Michael, So my questions are: 1) What frequency of registrations or SIP OPTIONS are actually required to keep the firewall translation is place Depends on the network hardware in the path and the shortest firewall UDP TTL setting, AstLinux defaults to a 180 second UDP TTL for netfilter.ip_conntrack_udp_timeout_stream states. By default, in sip.conf, qualifyfreq=60 which sends SIP OPTIONS every 60 seconds. This should work for most situations. But, it seems in your situation the transient case with network issues can cause problems. Possibly setting qualify to something large like 64000 ms, qualify=64000 would enable the qualify feature but would not normally fail. Possibly mixed with qualifyfreq=30 . Warning, I have never tested or tried this. 2) Would it be feasible for Monit to check 'sip show peers' that if a trunk peer has a Host IP Address but is a Status of UNKNOWN then do a 'module reload chan_sip.so' and report it? Personally I don't use Monit, but in theory it may be possible. Lonnie On Feb 8, 2018, at 12:54 AM, Michael Knill <mic...@ip...<mailto:mic...@ip...>> wrote: Sorry all I am dredging up this thread again. Thanks Lonnie for the info below. Although my main provider uses an IP Address based trunk which makes this problem go away, I have some providers that require registration via a DNS name. I have now activated dnsmgr which is good in that it will update the IP Address on the peer so it can reregister, HOWEVER the OPTIONS pings will not start up again if down after a reboot. I can turn off SIP OPTIONS (qualify=no) and put in a specific firewall rule I suppose but I would still rather have qualify=yes So my questions are: 1) What frequency of registrations or SIP OPTIONS are actually required to keep the firewall translation is place 2) Would it be feasible for Monit to check 'sip show peers' that if a trunk peer has a Host IP Address but is a Status of UNKNOWN then do a 'module reload chan_sip.so' and report it? Thanks all. Regards Michael Knill On 13/1/18, 6:38 am, "Michael Knill" <mic...@ip...<mailto:mic...@ip...>> wrote: Thanks Lonnie I have confirmed with my main provider that their IP Address will likely never change to I will be putting the IP Address in sip.conf so I don't even need to set a static host. I do like to know the reachability of my trunks so I will keep the OPTIONS pings going. Thanks so much again for your help. Regards Michael Knill On 13/1/18, 2:42 am, "Lonnie Abelbeck" <li...@lo...<mailto:li...@lo...>> wrote: Hi Michael, The easiest way to always make sure a DNS name resolves is to define static IP addresses in: Network tab -> Network Services: -> DNS Forwarder & DHCP Server: { Configure DNS Hosts } There you can statically define DNS host names without requiring any changes to your Asterisk configuration. Of course if your SIP provider makes changes you will have to reconfigure the DNS IP's like a bunny. Another approach, or in tandem, is to not depend on OPTIONS pings (qualify=yes) to keep firewall ports open, instead (qualify=no) use very specific (secure) firewall rules for inbound SIP calls. To be clear, it is not recommended to do either of the above as a general practice, but you do what you have to do. Lonnie On Jan 11, 2018, at 10:50 PM, Michael Knill <mic...@ip...<mailto:mic...@ip...>> wrote: Hi Group I have started a new thread although this is a continuation of my intermittent issues with sip trunks not coming back after a network outage. After some testing in the lab I have realised that most of these problems are related to DNS resolution. Basically I am using sip domain names for all my providers so DNS resolution is necessary. What I have found is that if for some reason DNS resolution is not possible (e.g. network is down), if the system is rebooted or Asterisk loses the resolved address, it no longer sends the OPTIONS pings as it cant find the address obviously. Yes that makes sense however the problem arises when the network is restored, Asterisk is completely unaware and therefore makes no attempt in resolving the address. I believe this is what is causing my intermittent issues which is easily resolved by doing an Asterisk Reload when network connectivity is restored. I have also enabled the Asterisk dnsmgr which does not fix the problem. I suspect that if it couldn't initially resolve it then it gives up totally. So what is the fix. Here are some of my options: • Don't use DNS but just use the IP Address instead. This will most certainly resolve the issue but is it the best way? Something in the Hosts file maybe? • Perform sip monitoring using the SIP Monitor script or Monit. If the SIP URL is resolvable but the status is UNKNOWN then issue a module reload of chan_sip • Something else PS the SIP Monitor does not seem to work for me. It only sends me an email when the system is rebooted. Thanks all. Regards Michael Knill Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2018-02-08 22:29:41
|
Thanks Michael yes that's my plan ☺
Regards
Michael Knill
From: Michael Keuter <li...@mk...>
Reply-To: AstLinux List <ast...@li...>
Date: Friday, 9 February 2018 at 8:56 am
To: AstLinux List <ast...@li...>
Subject: Re: [Astlinux-users] Network connectivity and DNS issues
Am 08.02.2018 um 22:04 schrieb Michael Knill <mic...@ip...<mailto:mic...@ip...>>:
Thanks Lonnie
I will give Monit a try and let you know how I go.
I will only turn on for some sites.
Regards
Michael Knill
Hi Michael,
in Monit you can run your own programs/scripts and then react on the return/exit value of that program. E.g.
----
check program CPU-0_Temp with path "/mnt/kd/bin/monit/sensors_temp.sh 'Core 0'"
if status > 70 then alert
----
On 9/2/18, 2:49 am, "Lonnie Abelbeck" <li...@lo...<mailto:li...@lo...>> wrote:
Michael,
So my questions are:
1) What frequency of registrations or SIP OPTIONS are actually required to keep the firewall translation is place
Depends on the network hardware in the path and the shortest firewall UDP TTL setting, AstLinux defaults to a 180 second UDP TTL for netfilter.ip_conntrack_udp_timeout_stream states.
By default, in sip.conf, qualifyfreq=60 which sends SIP OPTIONS every 60 seconds. This should work for most situations.
But, it seems in your situation the transient case with network issues can cause problems. Possibly setting qualify to something large like 64000 ms, qualify=64000 would enable the qualify feature but would not normally fail. Possibly mixed with qualifyfreq=30 . Warning, I have never tested or tried this.
2) Would it be feasible for Monit to check 'sip show peers' that if a trunk peer has a Host IP Address but is a Status of UNKNOWN then do a 'module reload chan_sip.so' and report it?
Personally I don't use Monit, but in theory it may be possible.
Lonnie
On Feb 8, 2018, at 12:54 AM, Michael Knill <mic...@ip...<mailto:mic...@ip...>> wrote:
Sorry all I am dredging up this thread again. Thanks Lonnie for the info below.
Although my main provider uses an IP Address based trunk which makes this problem go away, I have some providers that require registration via a DNS name.
I have now activated dnsmgr which is good in that it will update the IP Address on the peer so it can reregister, HOWEVER the OPTIONS pings will not start up again if down after a reboot.
I can turn off SIP OPTIONS (qualify=no) and put in a specific firewall rule I suppose but I would still rather have qualify=yes
So my questions are:
1) What frequency of registrations or SIP OPTIONS are actually required to keep the firewall translation is place
2) Would it be feasible for Monit to check 'sip show peers' that if a trunk peer has a Host IP Address but is a Status of UNKNOWN then do a 'module reload chan_sip.so' and report it?
Thanks all.
Regards
Michael Knill
On 13/1/18, 6:38 am, "Michael Knill" <mic...@ip...<mailto:mic...@ip...>> wrote:
Thanks Lonnie
I have confirmed with my main provider that their IP Address will likely never change to I will be putting the IP Address in sip.conf so I don't even need to set a static host.
I do like to know the reachability of my trunks so I will keep the OPTIONS pings going.
Thanks so much again for your help.
Regards
Michael Knill
On 13/1/18, 2:42 am, "Lonnie Abelbeck" <li...@lo...<mailto:li...@lo...>> wrote:
Hi Michael,
The easiest way to always make sure a DNS name resolves is to define static IP addresses in:
Network tab -> Network Services: -> DNS Forwarder & DHCP Server: { Configure DNS Hosts }
There you can statically define DNS host names without requiring any changes to your Asterisk configuration. Of course if your SIP provider makes changes you will have to reconfigure the DNS IP's like a bunny.
Another approach, or in tandem, is to not depend on OPTIONS pings (qualify=yes) to keep firewall ports open, instead (qualify=no) use very specific (secure) firewall rules for inbound SIP calls.
To be clear, it is not recommended to do either of the above as a general practice, but you do what you have to do.
Lonnie
On Jan 11, 2018, at 10:50 PM, Michael Knill <mic...@ip...<mailto:mic...@ip...>> wrote:
Hi Group
I have started a new thread although this is a continuation of my intermittent issues with sip trunks not coming back after a network outage.
After some testing in the lab I have realised that most of these problems are related to DNS resolution.
Basically I am using sip domain names for all my providers so DNS resolution is necessary. What I have found is that if for some reason DNS resolution is not possible (e.g. network is down), if the system is rebooted or Asterisk loses the resolved address, it no longer sends the OPTIONS pings as it cant find the address obviously.
Yes that makes sense however the problem arises when the network is restored, Asterisk is completely unaware and therefore makes no attempt in resolving the address.
I believe this is what is causing my intermittent issues which is easily resolved by doing an Asterisk Reload when network connectivity is restored. I have also enabled the Asterisk dnsmgr which does not fix the problem. I suspect that if it couldn't initially resolve it then it gives up totally.
So what is the fix. Here are some of my options:
• Don't use DNS but just use the IP Address instead. This will most certainly resolve the issue but is it the best way? Something in the Hosts file maybe?
• Perform sip monitoring using the SIP Monitor script or Monit. If the SIP URL is resolvable but the status is UNKNOWN then issue a module reload of chan_sip
• Something else
PS the SIP Monitor does not seem to work for me. It only sends me an email when the system is rebooted.
Thanks all.
Regards
Michael Knill
Michael
http://www.mksolutions.info
|
|
From: Michael K. <li...@mk...> - 2018-02-08 21:55:49
|
>
> Am 08.02.2018 um 22:04 schrieb Michael Knill <mic...@ip... <mailto:mic...@ip...>>:
>
> Thanks Lonnie
>
> I will give Monit a try and let you know how I go.
> I will only turn on for some sites.
>
> Regards
> Michael Knill
Hi Michael,
in Monit you can run your own programs/scripts and then react on the return/exit value of that program. E.g.
----
check program CPU-0_Temp with path "/mnt/kd/bin/monit/sensors_temp.sh 'Core 0'"
if status > 70 then alert
----
> On 9/2/18, 2:49 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Michael,
>
>> So my questions are:
>> 1) What frequency of registrations or SIP OPTIONS are actually required to keep the firewall translation is place
>
> Depends on the network hardware in the path and the shortest firewall UDP TTL setting, AstLinux defaults to a 180 second UDP TTL for netfilter.ip_conntrack_udp_timeout_stream states.
>
> By default, in sip.conf, qualifyfreq=60 which sends SIP OPTIONS every 60 seconds. This should work for most situations.
>
> But, it seems in your situation the transient case with network issues can cause problems. Possibly setting qualify to something large like 64000 ms, qualify=64000 would enable the qualify feature but would not normally fail. Possibly mixed with qualifyfreq=30 . Warning, I have never tested or tried this.
>
>
>> 2) Would it be feasible for Monit to check 'sip show peers' that if a trunk peer has a Host IP Address but is a Status of UNKNOWN then do a 'module reload chan_sip.so' and report it?
>
> Personally I don't use Monit, but in theory it may be possible.
>
> Lonnie
>
>
>
> On Feb 8, 2018, at 12:54 AM, Michael Knill <mic...@ip...> wrote:
>
>> Sorry all I am dredging up this thread again. Thanks Lonnie for the info below.
>> Although my main provider uses an IP Address based trunk which makes this problem go away, I have some providers that require registration via a DNS name.
>> I have now activated dnsmgr which is good in that it will update the IP Address on the peer so it can reregister, HOWEVER the OPTIONS pings will not start up again if down after a reboot.
>> I can turn off SIP OPTIONS (qualify=no) and put in a specific firewall rule I suppose but I would still rather have qualify=yes
>>
>> So my questions are:
>> 1) What frequency of registrations or SIP OPTIONS are actually required to keep the firewall translation is place
>> 2) Would it be feasible for Monit to check 'sip show peers' that if a trunk peer has a Host IP Address but is a Status of UNKNOWN then do a 'module reload chan_sip.so' and report it?
>>
>> Thanks all.
>>
>> Regards
>> Michael Knill
>>
>> On 13/1/18, 6:38 am, "Michael Knill" <mic...@ip...> wrote:
>>
>> Thanks Lonnie
>>
>> I have confirmed with my main provider that their IP Address will likely never change to I will be putting the IP Address in sip.conf so I don't even need to set a static host.
>> I do like to know the reachability of my trunks so I will keep the OPTIONS pings going.
>>
>> Thanks so much again for your help.
>>
>> Regards
>> Michael Knill
>>
>> On 13/1/18, 2:42 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>>
>> Hi Michael,
>>
>> The easiest way to always make sure a DNS name resolves is to define static IP addresses in:
>>
>> Network tab -> Network Services: -> DNS Forwarder & DHCP Server: { Configure DNS Hosts }
>>
>> There you can statically define DNS host names without requiring any changes to your Asterisk configuration. Of course if your SIP provider makes changes you will have to reconfigure the DNS IP's like a bunny.
>>
>>
>> Another approach, or in tandem, is to not depend on OPTIONS pings (qualify=yes) to keep firewall ports open, instead (qualify=no) use very specific (secure) firewall rules for inbound SIP calls.
>>
>>
>> To be clear, it is not recommended to do either of the above as a general practice, but you do what you have to do.
>>
>> Lonnie
>>
>>
>> On Jan 11, 2018, at 10:50 PM, Michael Knill <mic...@ip...> wrote:
>>
>>> Hi Group
>>>
>>> I have started a new thread although this is a continuation of my intermittent issues with sip trunks not coming back after a network outage.
>>> After some testing in the lab I have realised that most of these problems are related to DNS resolution.
>>>
>>> Basically I am using sip domain names for all my providers so DNS resolution is necessary. What I have found is that if for some reason DNS resolution is not possible (e.g. network is down), if the system is rebooted or Asterisk loses the resolved address, it no longer sends the OPTIONS pings as it cant find the address obviously.
>>> Yes that makes sense however the problem arises when the network is restored, Asterisk is completely unaware and therefore makes no attempt in resolving the address.
>>> I believe this is what is causing my intermittent issues which is easily resolved by doing an Asterisk Reload when network connectivity is restored. I have also enabled the Asterisk dnsmgr which does not fix the problem. I suspect that if it couldn't initially resolve it then it gives up totally.
>>>
>>> So what is the fix. Here are some of my options:
>>> • Don't use DNS but just use the IP Address instead. This will most certainly resolve the issue but is it the best way? Something in the Hosts file maybe?
>>> • Perform sip monitoring using the SIP Monitor script or Monit. If the SIP URL is resolvable but the status is UNKNOWN then issue a module reload of chan_sip
>>> • Something else
>>>
>>> PS the SIP Monitor does not seem to work for me. It only sends me an email when the system is rebooted.
>>> Thanks all.
>>>
>>> Regards
>>> Michael Knill
Michael
http://www.mksolutions.info
|
63 messages has been excluded from this view by a project administrator.
