Menu
▾
▴
astlinux-devel — The AstLinux development environment, compilation, etc
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
(41) |
Apr
(35) |
May
(18) |
Jun
(5) |
Jul
(4) |
Aug
(37) |
Sep
(9) |
Oct
(20) |
Nov
(50) |
Dec
(217) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(212) |
Feb
(76) |
Mar
(113) |
Apr
(88) |
May
(130) |
Jun
(54) |
Jul
(208) |
Aug
(223) |
Sep
(112) |
Oct
(63) |
Nov
(131) |
Dec
(103) |
| 2010 |
Jan
(247) |
Feb
(130) |
Mar
(43) |
Apr
(92) |
May
(40) |
Jun
(43) |
Jul
(43) |
Aug
(80) |
Sep
(44) |
Oct
(74) |
Nov
(21) |
Dec
(46) |
| 2011 |
Jan
(36) |
Feb
(11) |
Mar
(21) |
Apr
(33) |
May
(4) |
Jun
(12) |
Jul
(5) |
Aug
(20) |
Sep
|
Oct
(64) |
Nov
(26) |
Dec
(71) |
| 2012 |
Jan
(13) |
Feb
(24) |
Mar
(11) |
Apr
(2) |
May
(10) |
Jun
(5) |
Jul
(13) |
Aug
(7) |
Sep
(26) |
Oct
(22) |
Nov
(17) |
Dec
(16) |
| 2013 |
Jan
(6) |
Feb
(6) |
Mar
(6) |
Apr
(8) |
May
(20) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(18) |
Oct
(3) |
Nov
(14) |
Dec
(33) |
| 2014 |
Jan
(26) |
Feb
(6) |
Mar
(69) |
Apr
(10) |
May
|
Jun
(8) |
Jul
(18) |
Aug
(22) |
Sep
(19) |
Oct
(17) |
Nov
|
Dec
(4) |
| 2015 |
Jan
(14) |
Feb
(18) |
Mar
|
Apr
|
May
(26) |
Jun
(8) |
Jul
(9) |
Aug
(10) |
Sep
(15) |
Oct
(2) |
Nov
(30) |
Dec
(33) |
| 2016 |
Jan
(1) |
Feb
(24) |
Mar
(19) |
Apr
(1) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(20) |
Oct
(5) |
Nov
(14) |
Dec
(4) |
| 2017 |
Jan
(15) |
Feb
(35) |
Mar
(10) |
Apr
(9) |
May
(14) |
Jun
(33) |
Jul
(1) |
Aug
(27) |
Sep
(7) |
Oct
|
Nov
(10) |
Dec
(15) |
| 2018 |
Jan
(29) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
|
Jul
(1) |
Aug
(8) |
Sep
(11) |
Oct
(22) |
Nov
(9) |
Dec
(13) |
| 2019 |
Jan
(1) |
Feb
(7) |
Mar
(3) |
Apr
(21) |
May
(34) |
Jun
(36) |
Jul
(18) |
Aug
(17) |
Sep
(19) |
Oct
(8) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(8) |
Apr
(29) |
May
(50) |
Jun
(8) |
Jul
(2) |
Aug
(10) |
Sep
(1) |
Oct
(7) |
Nov
(9) |
Dec
(19) |
| 2021 |
Jan
(2) |
Feb
(9) |
Mar
(6) |
Apr
(21) |
May
(13) |
Jun
(11) |
Jul
(2) |
Aug
(1) |
Sep
(3) |
Oct
(26) |
Nov
(2) |
Dec
(16) |
| 2022 |
Jan
(8) |
Feb
(7) |
Mar
(1) |
Apr
(13) |
May
(1) |
Jun
(4) |
Jul
(4) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
(2) |
Feb
(3) |
Mar
(16) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(4) |
Aug
(13) |
Sep
(8) |
Oct
(6) |
Nov
(4) |
Dec
|
| 2024 |
Jan
(3) |
Feb
(3) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(5) |
Aug
|
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
| 2025 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
(11) |
May
(1) |
Jun
(9) |
Jul
(18) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Lonnie A. <li...@lo...> - 2020-11-28 13:56:51
|
Announcing AstLinux Pre-Release: astlinux-1.4-4914-e9aab1
** The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.
-- Linux Kernel 4.19.160 (version bump), security and bug fixes
-- WireGuard VPN, module 1.0.20201112 (version bump), tools 1.0.20200827 (no change)
-- libcurl (curl) version bump to 7.73.0
-- chrony, version bump to 4.0
-- miniupnpd, version 2.1, add Debian security fixes: CVE-2019-12107, CVE-2019-12108
CVE-2019-12109, CVE-2019-12110, CVE-2019-12111
-- sngrep, version bump to 1.4.8
-- Monit, version bump to 5.27.1
-- zabbix, version bump to 4.0.26
-- Asterisk 13.29.2 ('13se' no change)
Older than latest Asterisk 13.x version but more tested, built --without-pjproject
-- Asterisk 13.38.0 (version bump) and 16.15.0 (version bump)
-- DAHDI, dahdi-linux 3.1.0 (no change) and dahdi-tools 3.1.0 (no change)
-- pjsip 2.10 (no change)
-- Add support for directory /var/spool/asterisk/outgoing_tmp for call file staging.
-- Add support for persistent /mnt/kd/call-file/ directory for certain tmpfs spool directories.
If the directory /mnt/kd/call-file/ exists, the following symlinks will automatically occur:
== /var/spool/asterisk/outgoing -> /mnt/kd/call-file/outgoing
== /var/spool/asterisk/outgoing_tmp -> /mnt/kd/call-file/outgoing_tmp
== /var/spool/asterisk/outgoing_done -> /mnt/kd/call-file/outgoing_done
-- Complete Pre-Release ChangeLog:
https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt
The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...
AstLinux Project -> Development
https://www.astlinux-project.org/dev.html
AstLinux Team
|
|
From: Michael K. <li...@mk...> - 2020-11-28 11:17:36
|
> Am 27.11.2020 um 22:46 schrieb Michael Knill <mic...@ip...>: > > Hi Devs > > Hoping that I can get some advice from you in determining my development efforts moving forward. > As driven by Covid, I have an increased number of customers that want mobile softphones and I have lost at least one customer and likely more because I have not been able to provide this functionality. > > I am looking to use Bria which I believe is the gold standard and I sort of have push notification working on it. The problem is that Push Notification work best with multiple registration which is not supported with chan_sip. > > So I have two options I believe: > • Migrate to PJSIP > • Add Kamailio to Astlinux to sip in front of Asterisk > > Now 1) will certainly be the easiest however 2) is something that I would love to do as its going to be more secure with external connecting clients. > > Any comments would be greatly appreciated? > > Regards > Michael Knill Hi Michael, I have similar thoughts and would be interested in a more universal solution as well. I have one big customer, where I use WireGuard plus mostly Linphone without Push Notifications. And the customer is quite happy with it, although they are not using it excessively. I created a (combined) template for an IP-phone plus a softphone under the same extension, same CLID, but with different SIP account names (with chan_sip). I generated the dialplan (in the template as well) so that both phones ring parallel. Most depends how the mobile OS handles priority for the SIP client on the phone and the the sleep functions. For Push Notifications I found this: https://www.zoiper.com/en/tutorials/push-notifications https://github.com/balusreekanth/ios-asterisk-push BTW: For simple notifications (only for my own phone) I use Pushover (works also via email) or prepaid SMS via Voipbuster. https://pushover.net https://www.voipbuster.com/sms_rates Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2020-11-27 21:46:30
|
Hi Devs Hoping that I can get some advice from you in determining my development efforts moving forward. As driven by Covid, I have an increased number of customers that want mobile softphones and I have lost at least one customer and likely more because I have not been able to provide this functionality. I am looking to use Bria which I believe is the gold standard and I sort of have push notification working on it. The problem is that Push Notification work best with multiple registration which is not supported with chan_sip. So I have two options I believe: 1. Migrate to PJSIP 2. Add Kamailio to Astlinux to sip in front of Asterisk Now 1) will certainly be the easiest however 2) is something that I would love to do as its going to be more secure with external connecting clients. Any comments would be greatly appreciated? Regards Michael Knill |
|
From: Michael K. <mic...@ip...> - 2020-10-24 23:27:56
|
Thanks that works. I will do that!
Regards
Michael Knill
On 25/10/20, 10:13 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Good point ... how about
if ls -l /usr/lib/asterisk/modules/*pjsip.so >/dev/null 2>&1; then
echo "pjsip installed"
else
echo "pjsip not installed"
fi
Lonnie
> On Oct 24, 2020, at 5:57 PM, Michael Knill <mic...@ip...> wrote:
>
> Thanks Lonnie.
>
> Unfortunately I turn off PJSIP in modules.conf already so this method does not help me find whether its an SE version or not.
> For example:
> |||||
> | A | Release: astlinux-1.3.7.1 - Asterisk 13.29.2
> | s | Host Name: 3037-QGPSC-CM1.private.ipcaccess.net
> | t | Last Boot: 2020-10-24 15:35
> | L | Linux: 3.16.74-astlinux x86_64
> | i | CPU: Intel Xeon E5-2670 v2 (2x) @ 2500 MHz
> | n | RAM: 2011 MB
> | u | Board Type: genx86_64
> | x | Hardware: VMware Guest VM
> |||||
> 3037-QGPSC-CM1 kd # asterisk -rnx "pjsip show version"
> No such command 'pjsip show version' (type 'core show help pjsip show version' for other possible commands)
> 3037-QGPSC-CM1 kd #
>
> Regards
> Michael Knill
>
> On 25/10/20, 9:43 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
>
>
>> On Oct 24, 2020, at 4:56 PM, Michael Knill <mic...@ip...> wrote:
>>
>> Hi Devs
>>
>> Just wondering with the astlinux-release file whether it can show if its an SE version or not e.g. ‘astlinux-1.4.0SE’.
>> What uses this file? Would it break anything?
>>
>> Regards
>> Michael Knill
>
> The SE version is only related to the Asterisk version and how it was built.
>
> The /etc/astlinux-release file relates the base system.
>
> If you need to programmatically know if pjsip is supported, one method is:
>
> (SE version, w/o pjsip)
> # asterisk -rnx "pjsip show version"
> No such command 'pjsip show version' (type 'core show help pjsip show' for other possible commands)
>
> (non-SE version, with pjsip)
> # asterisk -rnx "pjsip show version"
> PJPROJECT version currently running against: 2.10
>
>
> I would not mess with the /etc/astlinux-release file.
>
> Lonnie
>
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2020-10-24 23:13:41
|
Good point ... how about if ls -l /usr/lib/asterisk/modules/*pjsip.so >/dev/null 2>&1; then echo "pjsip installed" else echo "pjsip not installed" fi Lonnie > On Oct 24, 2020, at 5:57 PM, Michael Knill <mic...@ip...> wrote: > > Thanks Lonnie. > > Unfortunately I turn off PJSIP in modules.conf already so this method does not help me find whether its an SE version or not. > For example: > ||||| > | A | Release: astlinux-1.3.7.1 - Asterisk 13.29.2 > | s | Host Name: 3037-QGPSC-CM1.private.ipcaccess.net > | t | Last Boot: 2020-10-24 15:35 > | L | Linux: 3.16.74-astlinux x86_64 > | i | CPU: Intel Xeon E5-2670 v2 (2x) @ 2500 MHz > | n | RAM: 2011 MB > | u | Board Type: genx86_64 > | x | Hardware: VMware Guest VM > ||||| > 3037-QGPSC-CM1 kd # asterisk -rnx "pjsip show version" > No such command 'pjsip show version' (type 'core show help pjsip show version' for other possible commands) > 3037-QGPSC-CM1 kd # > > Regards > Michael Knill > > On 25/10/20, 9:43 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > > >> On Oct 24, 2020, at 4:56 PM, Michael Knill <mic...@ip...> wrote: >> >> Hi Devs >> >> Just wondering with the astlinux-release file whether it can show if its an SE version or not e.g. ‘astlinux-1.4.0SE’. >> What uses this file? Would it break anything? >> >> Regards >> Michael Knill > > The SE version is only related to the Asterisk version and how it was built. > > The /etc/astlinux-release file relates the base system. > > If you need to programmatically know if pjsip is supported, one method is: > > (SE version, w/o pjsip) > # asterisk -rnx "pjsip show version" > No such command 'pjsip show version' (type 'core show help pjsip show' for other possible commands) > > (non-SE version, with pjsip) > # asterisk -rnx "pjsip show version" > PJPROJECT version currently running against: 2.10 > > > I would not mess with the /etc/astlinux-release file. > > Lonnie > > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2020-10-24 23:02:08
|
Option 2 may be to just look at the system_firmware_repository_url in webgui-prefs.txt. Not completely accurate as it can be changed but better than nothing.
Regards
Michael Knill
On 25/10/20, 9:57 am, "Michael Knill" <mic...@ip...> wrote:
Thanks Lonnie.
Unfortunately I turn off PJSIP in modules.conf already so this method does not help me find whether its an SE version or not.
For example:
|||||
| A | Release: astlinux-1.3.7.1 - Asterisk 13.29.2
| s | Host Name: 3037-QGPSC-CM1.private.ipcaccess.net
| t | Last Boot: 2020-10-24 15:35
| L | Linux: 3.16.74-astlinux x86_64
| i | CPU: Intel Xeon E5-2670 v2 (2x) @ 2500 MHz
| n | RAM: 2011 MB
| u | Board Type: genx86_64
| x | Hardware: VMware Guest VM
|||||
3037-QGPSC-CM1 kd # asterisk -rnx "pjsip show version"
No such command 'pjsip show version' (type 'core show help pjsip show version' for other possible commands)
3037-QGPSC-CM1 kd #
Regards
Michael Knill
On 25/10/20, 9:43 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> On Oct 24, 2020, at 4:56 PM, Michael Knill <mic...@ip...> wrote:
>
> Hi Devs
>
> Just wondering with the astlinux-release file whether it can show if its an SE version or not e.g. ‘astlinux-1.4.0SE’.
> What uses this file? Would it break anything?
>
> Regards
> Michael Knill
The SE version is only related to the Asterisk version and how it was built.
The /etc/astlinux-release file relates the base system.
If you need to programmatically know if pjsip is supported, one method is:
(SE version, w/o pjsip)
# asterisk -rnx "pjsip show version"
No such command 'pjsip show version' (type 'core show help pjsip show' for other possible commands)
(non-SE version, with pjsip)
# asterisk -rnx "pjsip show version"
PJPROJECT version currently running against: 2.10
I would not mess with the /etc/astlinux-release file.
Lonnie
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Michael K. <mic...@ip...> - 2020-10-24 22:57:50
|
Thanks Lonnie. Unfortunately I turn off PJSIP in modules.conf already so this method does not help me find whether its an SE version or not. For example: ||||| | A | Release: astlinux-1.3.7.1 - Asterisk 13.29.2 | s | Host Name: 3037-QGPSC-CM1.private.ipcaccess.net | t | Last Boot: 2020-10-24 15:35 | L | Linux: 3.16.74-astlinux x86_64 | i | CPU: Intel Xeon E5-2670 v2 (2x) @ 2500 MHz | n | RAM: 2011 MB | u | Board Type: genx86_64 | x | Hardware: VMware Guest VM ||||| 3037-QGPSC-CM1 kd # asterisk -rnx "pjsip show version" No such command 'pjsip show version' (type 'core show help pjsip show version' for other possible commands) 3037-QGPSC-CM1 kd # Regards Michael Knill On 25/10/20, 9:43 am, "Lonnie Abelbeck" <li...@lo...> wrote: > On Oct 24, 2020, at 4:56 PM, Michael Knill <mic...@ip...> wrote: > > Hi Devs > > Just wondering with the astlinux-release file whether it can show if its an SE version or not e.g. ‘astlinux-1.4.0SE’. > What uses this file? Would it break anything? > > Regards > Michael Knill The SE version is only related to the Asterisk version and how it was built. The /etc/astlinux-release file relates the base system. If you need to programmatically know if pjsip is supported, one method is: (SE version, w/o pjsip) # asterisk -rnx "pjsip show version" No such command 'pjsip show version' (type 'core show help pjsip show' for other possible commands) (non-SE version, with pjsip) # asterisk -rnx "pjsip show version" PJPROJECT version currently running against: 2.10 I would not mess with the /etc/astlinux-release file. Lonnie _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Lonnie A. <li...@lo...> - 2020-10-24 22:43:35
|
> On Oct 24, 2020, at 4:56 PM, Michael Knill <mic...@ip...> wrote: > > Hi Devs > > Just wondering with the astlinux-release file whether it can show if its an SE version or not e.g. ‘astlinux-1.4.0SE’. > What uses this file? Would it break anything? > > Regards > Michael Knill The SE version is only related to the Asterisk version and how it was built. The /etc/astlinux-release file relates the base system. If you need to programmatically know if pjsip is supported, one method is: (SE version, w/o pjsip) # asterisk -rnx "pjsip show version" No such command 'pjsip show version' (type 'core show help pjsip show' for other possible commands) (non-SE version, with pjsip) # asterisk -rnx "pjsip show version" PJPROJECT version currently running against: 2.10 I would not mess with the /etc/astlinux-release file. Lonnie |
|
From: Michael K. <mic...@ip...> - 2020-10-24 21:57:05
|
Hi Devs Just wondering with the astlinux-release file whether it can show if its an SE version or not e.g. ‘astlinux-1.4.0SE’. What uses this file? Would it break anything? Regards Michael Knill |
|
From: Lonnie A. <li...@lo...> - 2020-10-06 14:56:55
|
Announcing AstLinux Release: 1.4.0 More Info: AstLinux Project https://www.astlinux-project.org/ AstLinux 1.4.0 Highlights: * Asterisk Versions: 13.29.2, 13.36.0, 16.13.0 * Linux Kernel 4.19.146, major bump from 3.16.x series * RUNNIX, version bump to runnix-0.6.2, with Linux Kernel 4.19.146, e2fsprogs 1.45.6, util-linux 2.33.2 * WireGuard VPN, version bump, module 1.0.20200908, tools 1.0.20200827 * iproute2 (ip, tc, bridge, etc.) version bump to 4.20.0 * iptables, version bump to 1.8.4 * Fossil, version bump to 2.10.2, security fixes * acme-client, version 2.8.7, add email notify support * dnsmasq, version bump to 2.82, performance improvements and bug fixes * util-linux, version bump to 2.33.2, add 'nsenter' command * zabbix, version bump to 4.0.24 * Asterisk '13se' (stable edition) version 13.29.2 is older than latest Asterisk 13.x version but more tested, built --without-pjproject * pjsip, version bump to 2.10 * DAHDI, version bump to dahdi-linux 3.1.0 and dahdi-tools 3.1.0, required to support the new kernel Previous DAHDI_HFCS and RHINO drivers are no longer supported Add patch to return DAHDI support for (wctdm24xxp) TDM800P/AEX800 and TDM410P/AEX410 PCI cards Add patch to return DAHDI support for (wctdm) TDM400P PCI cards Add patch to return DAHDI support for (wcfxo) X100P PCI cards * Package upgrades providing important security and bug fixes Full ChangeLog: https://raw.githubusercontent.com/astlinux-project/astlinux/1.4.0/docs/ChangeLog.txt All users are encouraged to upgrade. Previous Asterisk 11.x users are encouraged to switch to the new Asterisk '13se' (stable edition). Some configuration changes will be needed, though minimal. AstLinux Team |
|
From: Lonnie A. <li...@lo...> - 2020-09-27 15:07:06
|
Release Candidate1 pre-1.4.0, please report any issues, ASAP.
The next AstLinux version will be 1.4.0, most notably switching to the Linux kernel 4.19.x LTS series.
** IMPORTANT NOTICE
-- DAHDI is now version 3.1.0 to support the new kernel, as such previous DAHDI_HFCS and RHINO drivers are no longer supported.
** The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.
-- Linux Kernel 4.19.146 (major version bump from 3.16.x)
-- WireGuard VPN, module 1.0.20200908 (version bump), tools 1.0.20200827 (version bump)
-- iproute2 (ip, tc, bridge, etc.) version bump to 4.20.0
-- iptables, version bump to 1.8.4
-- Fossil, version bump to 2.10.2, security fixes
-- acme-client, version 2.8.7, add email notify support
-- dnsmasq, version bump to 2.82, performance improvements and bug fixes
-- util-linux, version bump to 2.33.2, add 'nsenter' command
-- zabbix, version bump to 4.0.24
-- Asterisk 13.29.2 ('13se' no change)
Older than latest Asterisk 13.x version but more tested, built --without-pjproject
-- Asterisk 13.36.0 (version bump) and 16.13.0 (version bump)
-- DAHDI, dahdi-linux 3.1.0 (version bump) and dahdi-tools 3.1.0 (version bump)
Note: Add patch to return support for (wctdm24xxp) TDM800P/AEX800 and TDM410P/AEX410 PCI cards.
Note: Add patch to return support for (wctdm) TDM400P PCI cards.
Note: Add patch to return support for (wcfxo) X100P PCI cards.
-- pjsip 2.10 (version bump)
-- Complete Pre-Release ChangeLog:
https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt
Updated Documentation Topics:
-- ACME (Let's Encrypt) Certificates
https://doc.astlinux-project.org/userdoc:tt_acme_certificates
The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...
AstLinux Project -> Development
https://www.astlinux-project.org/dev.html
AstLinux Team
|
|
From: Lonnie A. <li...@lo...> - 2020-08-28 15:44:57
|
Announcing Pre-Release Version: astlinux-1.4-4801-574be0 The next AstLinux version will be 1.4.0, most notably switching to the Linux kernel 4.19.x LTS series. Much testing needs to be done, if you have a non-standard box (HP Thin Client, unique China box, etc.) we would encourage you to test. Be certain you have console access, using the CLI to upgrade to the pre-release version. Possibly type "dmesg -H" to view the logs and note anything weird, particularly Broadcom or Realtek NIC related. Revert back to your previous image with "upgrade-run-image revert" and "kernel-reboot" CLI commands. While we do not suggest this specific pre-release is production ready, some of the developers are using it in production. ** IMPORTANT NOTICE -- DAHDI is now version 3.1.0 to support the new kernel, as such previous DAHDI_HFCS and RHINO drivers are no longer supported. ** The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own. -- Linux Kernel 4.19.140 (major version bump) -- WireGuard VPN, module 1.0.20200729 (version bump), tools 1.0.20200820 (version bump) -- iproute2 (ip, tc, bridge, etc.) version bump to 4.20.0 -- iptables, version bump to 1.8.4 -- DAHDI, dahdi-linux 3.1.0 (version bump) and dahdi-tools 3.1.0 (version bump) -- Fossil, version bump to 2.10.2, security fixes -- Complete Pre-Release ChangeLog: https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... AstLinux Project -> Development https://www.astlinux-project.org/dev.html AstLinux Team |
|
From: Lonnie A. <li...@lo...> - 2020-08-08 20:08:03
|
Hi David, > Source Port (#'s) Destination Port Protocol Packets Bytes TTL > 192.168.17.104 54135 17.57.144.52 5223 TCP 10097 6326476 7199:42 > 192.168.17.201 58114 17.57.144.7 5223 TCP 4603 2941050 4:59 The 7199:42 (large) TTL indicates an active TCP connection. When traffic occurs it is reset back to 7200.00 (5 days). The 4:59 TTL is most likely a closed TCP connection counting down to 0 when the state expires. Lonnie > On Aug 8, 2020, at 2:28 PM, David Kerr <da...@ke...> wrote: > > Thanks lonnie. I'm sure I will have more questions once I dig into the proc/net/fn_conntrack file. In the meantime how should I interpret these two lines... > > Source Port (#'s) Destination Port Protocol Packets Bytes TTL > 192.168.17.104 54135 17.57.144.52 5223 TCP 10097 6326476 7199:42 > 192.168.17.201 58114 17.57.144.7 5223 TCP 4603 2941050 4:59 > > The local devices are Apple devices, the destination IPs are owned by Apple and port 5223 is for their push notification service. Both are next to each other in the sorted (by bytes) table, but both have very different TTL. So what if anything can I tell from the difference? > > Thanks > David > > On Sat, Aug 8, 2020 at 3:05 PM Lonnie Abelbeck <li...@lo...> wrote: > Hi David, > > The data under "Firewall States:" originates from /proc/net/nf_conntrack > > The TTL is the Time-To-Live of the conntrack state. > > I have found the current format quite useful over the years. > > BTW, the Prefs tab has a couple of filters: > > _x_ Show Firewall States > Hide SRC Ports: > Hide DST Ports: > > Any defined Source (SRC) or Destination (DST) ports > will not be displayed. Multiple ports are separated with a space character. > > Lonnie > > > > > On Aug 8, 2020, at 1:51 PM, David Kerr <da...@ke...> wrote: > > > > I've been paying more attention to the firewall states on the status page to try and track down heavy internet users (though thankfully Comcast is back now -- but power is not). > > > > A lot of the information reported is not very useful. For example, a lot of bonjour traffic over port 5353 to 224.0.0.251 / ff02::fb currently occupying 6 of the top 11 entries. And then there is lots of traffic within my internal networks. > > > > Also, what is the TTL column, is it something to do when last traffic was seen? Started? Can we age off old data... about 2/3rd of my entries are showing 7199:xx in the TTL column and I am not sure how to interpret that. > > > > All I really care about is recent traffic leaving and arriving across the external interface(s). Other than manually filtering, is there a way we could make the status page's firewall states more helpful? > > > > Thanks, > > David > > _______________________________________________ > > Astlinux-devel mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: David K. <da...@ke...> - 2020-08-08 19:35:43
|
Thanks lonnie. I'm sure I will have more questions once I dig into the proc/net/fn_conntrack file. In the meantime how should I interpret these two lines... Source Port (#'s) Destination Port Protocol Packets Bytes TTL 192.168.17.104 54135 17.57.144.52 5223 TCP 10097 6326476 7199:42 192.168.17.201 58114 17.57.144.7 5223 TCP 4603 2941050 4:59 The local devices are Apple devices, the destination IPs are owned by Apple and port 5223 is for their push notification service. Both are next to each other in the sorted (by bytes) table, but both have very different TTL. So what if anything can I tell from the difference? Thanks David On Sat, Aug 8, 2020 at 3:05 PM Lonnie Abelbeck <li...@lo...> wrote: > Hi David, > > The data under "Firewall States:" originates from /proc/net/nf_conntrack > > The TTL is the Time-To-Live of the conntrack state. > > I have found the current format quite useful over the years. > > BTW, the Prefs tab has a couple of filters: > > _x_ Show Firewall States > Hide SRC Ports: > Hide DST Ports: > > Any defined Source (SRC) or Destination (DST) ports > will not be displayed. Multiple ports are separated with a space > character. > > Lonnie > > > > > On Aug 8, 2020, at 1:51 PM, David Kerr <da...@ke...> wrote: > > > > I've been paying more attention to the firewall states on the status > page to try and track down heavy internet users (though thankfully Comcast > is back now -- but power is not). > > > > A lot of the information reported is not very useful. For example, a > lot of bonjour traffic over port 5353 to 224.0.0.251 / ff02::fb currently > occupying 6 of the top 11 entries. And then there is lots of traffic > within my internal networks. > > > > Also, what is the TTL column, is it something to do when last traffic > was seen? Started? Can we age off old data... about 2/3rd of my entries > are showing 7199:xx in the TTL column and I am not sure how to interpret > that. > > > > All I really care about is recent traffic leaving and arriving across > the external interface(s). Other than manually filtering, is there a way > we could make the status page's firewall states more helpful? > > > > Thanks, > > David > > _______________________________________________ > > Astlinux-devel mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > |
|
From: Lonnie A. <li...@lo...> - 2020-08-08 19:05:38
|
Hi David, The data under "Firewall States:" originates from /proc/net/nf_conntrack The TTL is the Time-To-Live of the conntrack state. I have found the current format quite useful over the years. BTW, the Prefs tab has a couple of filters: _x_ Show Firewall States Hide SRC Ports: Hide DST Ports: Any defined Source (SRC) or Destination (DST) ports will not be displayed. Multiple ports are separated with a space character. Lonnie > On Aug 8, 2020, at 1:51 PM, David Kerr <da...@ke...> wrote: > > I've been paying more attention to the firewall states on the status page to try and track down heavy internet users (though thankfully Comcast is back now -- but power is not). > > A lot of the information reported is not very useful. For example, a lot of bonjour traffic over port 5353 to 224.0.0.251 / ff02::fb currently occupying 6 of the top 11 entries. And then there is lots of traffic within my internal networks. > > Also, what is the TTL column, is it something to do when last traffic was seen? Started? Can we age off old data... about 2/3rd of my entries are showing 7199:xx in the TTL column and I am not sure how to interpret that. > > All I really care about is recent traffic leaving and arriving across the external interface(s). Other than manually filtering, is there a way we could make the status page's firewall states more helpful? > > Thanks, > David > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: David K. <da...@ke...> - 2020-08-08 18:51:58
|
I've been paying more attention to the firewall states on the status page to try and track down heavy internet users (though thankfully Comcast is back now -- but power is not). A lot of the information reported is not very useful. For example, a lot of bonjour traffic over port 5353 to 224.0.0.251 / ff02::fb currently occupying 6 of the top 11 entries. And then there is lots of traffic within my internal networks. Also, what is the TTL column, is it something to do when last traffic was seen? Started? Can we age off old data... about 2/3rd of my entries are showing 7199:xx in the TTL column and I am not sure how to interpret that. All I really care about is recent traffic leaving and arriving across the external interface(s). Other than manually filtering, is there a way we could make the status page's firewall states more helpful? Thanks, David |
|
From: David K. <da...@ke...> - 2020-08-06 21:38:07
|
Lonnie, No, I had @MASTER_PASS@ properly in my file. The problem was that I did not stop first before doing the init... so files were generated in etc, but the daemons were not told to reload them. I still think that should be fixed... if the daemons are running and init updates the files, then they should be told to reload. David On Thu, Aug 6, 2020 at 4:29 PM Lonnie Abelbeck <li...@lo...> wrote: > Hi David, > > My thought was to temporarily add "admin" permissions, hence edit > /etc/ups/upsd.users and "restart". Not something I wanted to have stick > around in /mnt/kd/ups/ . > > But looking at /etc/init.d/ups, editing /mnt/kd/ups/upsd.users and "stop", > "init" should work just fine as well. Look at what gets autogenerated when > /mnt/kd/ups/upsd.users is not defined, and start with that ... but you must > replace the master password in /mnt/kd/ups/upsd.users with the @MASTER_PASS@ > token which is randomly generated and shared across the files. > > -- /mnt/kd/ups/upsd.users snippet -- > [master] > password = @MASTER_PASS@ > upsmon master > -- > > I suspect that was your original problem. (ERR ACCESS-DENIED) > > Lonnie > > > > > On Aug 6, 2020, at 2:23 PM, David Kerr <Da...@Ke...> wrote: > > > > Lonnie, > > I see that you were editing the file /etc/ups/upsd.users. I was > editing the file /mnt/kd/ups/upsd.users (because that is what the > instructions said to do as the one in /etc is generated from that). So my > edits would persist across reboots, yours would not (at least I don't think > so... have not tried... unionfs comes into play too). My expectation was > that having edited the file in /mnt/kd/ups and doing a service ups init, > that would have caused the new file to get picked up. But it was not. > > > > I had looked at the etc/init.d scriipt and observed that I needed to do > an init to pick up the changes in mnt/kd. I did not realize I also had to > do a restart, that was not expected. So I stand by my original statement > that doing an init should not just rebuild the /etc files, it should also > make sure that they are read. > > > > Regards, > > David > > > > On Wed, Aug 5, 2020 at 10:24 PM Lonnie Abelbeck < > li...@lo...> wrote: > > Hi David, > > > > Years ago I wanted to disable the beeper on a Tripp-Lite UPS, below are > the steps I used. Possibly it might help you. Step 1 was key. > > > > > > 1) Edit /etc/ups/upsd.users and add the lines: > > -- > > [admin] > > password = pass > > instcmds = all > > -- > > > > 2) Apply the change without rebuilding the config files. > > -- > > service ups restart > > -- > > > > 3) List what commands are available > > -- > > upscmd -l ups > > -- > > > > 4) In this case "beeper.disable" was the desired command > > -- > > upscmd -u admin -p pass ups beeper.disable > > -- > > > > 5) Display UPS responses > > -- > > upsc ups > > -- > > > > 6) Restart "ups" rebuilding the config files. > > -- > > service ups stop > > service ups init > > -- > > > > > > Lonnie > > > > > > > On Aug 5, 2020, at 8:18 PM, David Kerr <Da...@Ke...> wrote: > > > > > > As I prepare to enjoy multiple days without power or internet I have > been trying to reconfigure my UPS as it is sending LOWBATT far too early. > I tried to use upsrw command to set values into the UPS but kept getting... > > > > > > Unexpected response from upsd: ERR ACCESS-DENIED > > > > > > Even after editing upsd.user file. After which I would do a > > > service ups init > > > Well it turns out that is not good enough. It regenerates all the > config files but it does not reload the new config files. It has to be > followed by a > > > service ups restart > > > > > > Or... the init script could do a stop before the init? > > > Or... the init script could send a reload to upsd? > > > > > > Thanks > > > David > > > > > > _______________________________________________ > > > Astlinux-devel mailing list > > > Ast...@li... > > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > > > > > _______________________________________________ > > Astlinux-devel mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > _______________________________________________ > > Astlinux-devel mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > |
|
From: Lonnie A. <li...@lo...> - 2020-08-06 20:29:48
|
Hi David, My thought was to temporarily add "admin" permissions, hence edit /etc/ups/upsd.users and "restart". Not something I wanted to have stick around in /mnt/kd/ups/ . But looking at /etc/init.d/ups, editing /mnt/kd/ups/upsd.users and "stop", "init" should work just fine as well. Look at what gets autogenerated when /mnt/kd/ups/upsd.users is not defined, and start with that ... but you must replace the master password in /mnt/kd/ups/upsd.users with the @MASTER_PASS@ token which is randomly generated and shared across the files. -- /mnt/kd/ups/upsd.users snippet -- [master] password = @MASTER_PASS@ upsmon master -- I suspect that was your original problem. (ERR ACCESS-DENIED) Lonnie > On Aug 6, 2020, at 2:23 PM, David Kerr <Da...@Ke...> wrote: > > Lonnie, > I see that you were editing the file /etc/ups/upsd.users. I was editing the file /mnt/kd/ups/upsd.users (because that is what the instructions said to do as the one in /etc is generated from that). So my edits would persist across reboots, yours would not (at least I don't think so... have not tried... unionfs comes into play too). My expectation was that having edited the file in /mnt/kd/ups and doing a service ups init, that would have caused the new file to get picked up. But it was not. > > I had looked at the etc/init.d scriipt and observed that I needed to do an init to pick up the changes in mnt/kd. I did not realize I also had to do a restart, that was not expected. So I stand by my original statement that doing an init should not just rebuild the /etc files, it should also make sure that they are read. > > Regards, > David > > On Wed, Aug 5, 2020 at 10:24 PM Lonnie Abelbeck <li...@lo...> wrote: > Hi David, > > Years ago I wanted to disable the beeper on a Tripp-Lite UPS, below are the steps I used. Possibly it might help you. Step 1 was key. > > > 1) Edit /etc/ups/upsd.users and add the lines: > -- > [admin] > password = pass > instcmds = all > -- > > 2) Apply the change without rebuilding the config files. > -- > service ups restart > -- > > 3) List what commands are available > -- > upscmd -l ups > -- > > 4) In this case "beeper.disable" was the desired command > -- > upscmd -u admin -p pass ups beeper.disable > -- > > 5) Display UPS responses > -- > upsc ups > -- > > 6) Restart "ups" rebuilding the config files. > -- > service ups stop > service ups init > -- > > > Lonnie > > > > On Aug 5, 2020, at 8:18 PM, David Kerr <Da...@Ke...> wrote: > > > > As I prepare to enjoy multiple days without power or internet I have been trying to reconfigure my UPS as it is sending LOWBATT far too early. I tried to use upsrw command to set values into the UPS but kept getting... > > > > Unexpected response from upsd: ERR ACCESS-DENIED > > > > Even after editing upsd.user file. After which I would do a > > service ups init > > Well it turns out that is not good enough. It regenerates all the config files but it does not reload the new config files. It has to be followed by a > > service ups restart > > > > Or... the init script could do a stop before the init? > > Or... the init script could send a reload to upsd? > > > > Thanks > > David > > > > _______________________________________________ > > Astlinux-devel mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: David K. <da...@ke...> - 2020-08-06 19:48:30
|
Lonnie, I see that you were editing the file /etc/ups/upsd.users. I was editing the file /mnt/kd/ups/upsd.users (because that is what the instructions said to do as the one in /etc is generated from that). So my edits would persist across reboots, yours would not (at least I don't think so... have not tried... unionfs comes into play too). My expectation was that having edited the file in /mnt/kd/ups and doing a service ups init, that would have caused the new file to get picked up. But it was not. I had looked at the etc/init.d scriipt and observed that I needed to do an init to pick up the changes in mnt/kd. I did not realize I also had to do a restart, that was not expected. So I stand by my original statement that doing an init should not just rebuild the /etc files, it should also make sure that they are read. Regards, David On Wed, Aug 5, 2020 at 10:24 PM Lonnie Abelbeck <li...@lo...> wrote: > Hi David, > > Years ago I wanted to disable the beeper on a Tripp-Lite UPS, below are > the steps I used. Possibly it might help you. Step 1 was key. > > > 1) Edit /etc/ups/upsd.users and add the lines: > -- > [admin] > password = pass > instcmds = all > -- > > 2) Apply the change without rebuilding the config files. > -- > service ups restart > -- > > 3) List what commands are available > -- > upscmd -l ups > -- > > 4) In this case "beeper.disable" was the desired command > -- > upscmd -u admin -p pass ups beeper.disable > -- > > 5) Display UPS responses > -- > upsc ups > -- > > 6) Restart "ups" rebuilding the config files. > -- > service ups stop > service ups init > -- > > > Lonnie > > > > On Aug 5, 2020, at 8:18 PM, David Kerr <Da...@Ke...> wrote: > > > > As I prepare to enjoy multiple days without power or internet I have > been trying to reconfigure my UPS as it is sending LOWBATT far too early. > I tried to use upsrw command to set values into the UPS but kept getting... > > > > Unexpected response from upsd: ERR ACCESS-DENIED > > > > Even after editing upsd.user file. After which I would do a > > service ups init > > Well it turns out that is not good enough. It regenerates all the > config files but it does not reload the new config files. It has to be > followed by a > > service ups restart > > > > Or... the init script could do a stop before the init? > > Or... the init script could send a reload to upsd? > > > > Thanks > > David > > > > _______________________________________________ > > Astlinux-devel mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > |
|
From: Lonnie A. <li...@lo...> - 2020-08-06 02:24:53
|
Hi David, Years ago I wanted to disable the beeper on a Tripp-Lite UPS, below are the steps I used. Possibly it might help you. Step 1 was key. 1) Edit /etc/ups/upsd.users and add the lines: -- [admin] password = pass instcmds = all -- 2) Apply the change without rebuilding the config files. -- service ups restart -- 3) List what commands are available -- upscmd -l ups -- 4) In this case "beeper.disable" was the desired command -- upscmd -u admin -p pass ups beeper.disable -- 5) Display UPS responses -- upsc ups -- 6) Restart "ups" rebuilding the config files. -- service ups stop service ups init -- Lonnie > On Aug 5, 2020, at 8:18 PM, David Kerr <Da...@Ke...> wrote: > > As I prepare to enjoy multiple days without power or internet I have been trying to reconfigure my UPS as it is sending LOWBATT far too early. I tried to use upsrw command to set values into the UPS but kept getting... > > Unexpected response from upsd: ERR ACCESS-DENIED > > Even after editing upsd.user file. After which I would do a > service ups init > Well it turns out that is not good enough. It regenerates all the config files but it does not reload the new config files. It has to be followed by a > service ups restart > > Or... the init script could do a stop before the init? > Or... the init script could send a reload to upsd? > > Thanks > David > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: David K. <da...@ke...> - 2020-08-06 01:44:15
|
As I prepare to enjoy multiple days without power or internet I have been trying to reconfigure my UPS as it is sending LOWBATT far too early. I tried to use upsrw command to set values into the UPS but kept getting... Unexpected response from upsd: ERR ACCESS-DENIED Even after editing upsd.user file. After which I would do a service ups init Well it turns out that is not good enough. It regenerates all the config files but it does not reload the new config files. It has to be followed by a service ups restart Or... the init script could do a stop before the init? Or... the init script could send a reload to upsd? Thanks David |
|
From: Lonnie A. <li...@lo...> - 2020-07-26 19:04:25
|
Announcing AstLinux Release: 1.3.10 More Info: AstLinux Project https://www.astlinux-project.org/ AstLinux 1.3.10 Highlights: * Asterisk Versions: 13.29.2, 13.34.0, 16.11.1 * Upgrade to Linux Kernel 3.16.85, including the new x86_64 RUNNIX bootloader, security and bug fixes Kernel config: Add NAMESPACES and CGROUPS for Linux Containers * New toolchain: glibc 2.27, binutils 2.29.1, gcc 6.5.0, using crosstool-ng-1.24.0 * unionfs, move from old kernel unionfs to FUSE unionfs version 2.1 To better secure the filesystem, now only '/etc' and '/stat' will be read-write over the read-only base firmware image. * lxc, new package, add support for guest Linux Containers. For example, run Pi-hole or the UniFi Controller. * OpenSSL, version bump to 1.1.1g * WireGuard VPN, version bump, module 1.0.20200712, tools 1.0.20200513 * OpenVPN, version bump to 2.4.9 * udev, now use eudev version 3.2.9 * zabbix, major version bump to 4.0.20, LTS series * initial-setup, remove 'combined' partition format option, always use 'format separate' * Asterisk '13se' (stable edition) version 13.29.2 is older than latest Asterisk 13.x version but more tested, built --without-pjproject * Package upgrades providing important security and bug fixes Full ChangeLog: https://raw.githubusercontent.com/astlinux-project/astlinux/1.3.10/docs/ChangeLog.txt All users are encouraged to upgrade. Previous Asterisk 11.x users are encouraged to switch to the new Asterisk '13se' (stable edition). Some configuration changes will be needed, though minimal. AstLinux Team |
|
From: Lonnie A. <li...@lo...> - 2020-07-10 15:49:29
|
Release Candidate1 pre-1.3.10, please report any issues, ASAP. Many under-the-hood updates: New toolchain: glibc 2.27, binutils 2.29.1, gcc 6.5.0, using crosstool-ng-1.24.0 udev, now use eudev version 3.2.9 kmod, version 27, new package which replaces module-init-tools ** IMPORTANT NOTICE -- AstLinux now only supports 64-bit, x86_64 architectures. -- Current supported board types are: "genx86_64", "genx86_64-serial" and "genx86_64-vm" ** 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.85 (version bump), security and bug fixes Kernel config: Add NAMESPACES and CGROUPS for Linux Containers -- lxc, new package, add support for guest Linux Containers. Running Pi-hole for example. New rc.conf variables: LXC_BRIDGE0, LXC_STOP_TIMEOUT More info: https://doc.astlinux-project.org/userdoc:guest_lxc_container_main -- unionfs, move from old kernel unionfs to FUSE unionfs version 2.1 To better secure the filesystem, now only '/etc' and '/stat' will be read-write over the read-only base firmware image. Previously '/' (everything) was overlaid. Additionally, mount ASTURW as /mnt/asturw instead of /oldroot/mnt/asturw . -- New rc.conf variable ASTERISK_RW_MODULES_DIR, give directory /usr/lib/asterisk/modules/ read/write permissions, "yes" or "no", defaults to "no". Example: If you had a codec_g729a.so module installed, you must define: ASTERISK_RW_MODULES_DIR="yes" Note: With AstLinux 1.3.8 and older this was implied to be "yes". -- Asterisk 13.29.2 ('13se' version bump) Older than latest Asterisk 13.x version but more tested, built --without-pjproject -- Asterisk 13.34.0 (version bump) and 16.11.1 (version bump) -- OpenSSL, version bump to 1.1.1g, security fix: CVE-2020-1967 -- WireGuard VPN, module 1.0.20200623 (version bump), tools 1.0.20200513 (version bump) -- OpenVPN, version bump to 2.4.9, security fix: CVE-2020-11810 -- zabbix, major version bump to 4.0.20, next LTS series -- Complete Pre-Release ChangeLog: https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt New Documentation Topics: -- AstLinux Hosted Linux Containers https://doc.astlinux-project.org/userdoc:guest_lxc_container_main -- Firewall Overview https://doc.astlinux-project.org/userdoc:tt_firewall_overview Updated Documentation Topics: -- DNS-TLS Proxy Server https://doc.astlinux-project.org/userdoc:tt_dns_tls_proxy The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... AstLinux Project -> Development https://www.astlinux-project.org/dev.html AstLinux Team |
|
From: Michael K. <mic...@ip...> - 2020-06-13 22:39:22
|
I think this is going to be my Astlinux LTS Release.
Looking forward to it __
Regards
Michael Knill
On 13/6/20, 11:41 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Announcing Pre-Release Version: astlinux-1.3-4711-4a99b3
Many under-the-hood updates:
New toolchain: glibc 2.27, binutils 2.29.1, gcc 6.5.0, using crosstool-ng-1.24.0
udev, now use eudev version 3.2.9
kmod, version 27, new package which replaces module-init-tools
** IMPORTANT NOTICE
-- AstLinux now only supports 64-bit, x86_64 architectures.
-- Current supported board types are: "genx86_64", "genx86_64-serial" and "genx86_64-vm"
** 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.84 (version bump), security and bug fixes
Kernel config: Add NAMESPACES and CGROUPS for Linux Containers
-- lxc, new package, add support for guest Linux Containers. Running Pi-hole for example.
New rc.conf variables: LXC_BRIDGE0, LXC_STOP_TIMEOUT
More info: https://doc.astlinux-project.org/userdoc:guest_lxc_container_main
-- unionfs, move from old kernel unionfs to FUSE unionfs version 2.1
To better secure the filesystem, now only '/etc' and '/stat' will be read-write
over the read-only base firmware image. Previously '/' (everything) was overlaid.
Additionally, mount ASTURW as /mnt/asturw instead of /oldroot/mnt/asturw .
-- New rc.conf variable ASTERISK_RW_MODULES_DIR, give directory /usr/lib/asterisk/modules/
read/write permissions, "yes" or "no", defaults to "no".
Example: If you had a codec_g729a.so module installed, you must define: ASTERISK_RW_MODULES_DIR="yes"
Note: With AstLinux 1.3.8 and older this was implied to be "yes".
-- Asterisk 13.29.2 ('13se' version bump)
Older than latest Asterisk 13.x version but more tested, built --without-pjproject
-- Asterisk 13.34.0 (version bump) and 16.11.0 (version bump)
-- OpenSSL, version bump to 1.1.1g, security fix: CVE-2020-1967
-- WireGuard VPN, module 1.0.20200611 (version bump), tools 1.0.20200513 (version bump)
-- OpenVPN, version bump to 2.4.9, security fix: CVE-2020-11810
-- zabbix, major version bump to 4.0.20, next LTS series
-- Complete Pre-Release ChangeLog:
https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt
New Documentation Topics:
-- AstLinux Hosted Linux Containers
https://doc.astlinux-project.org/userdoc:guest_lxc_container_main
-- Firewall Overview
https://doc.astlinux-project.org/userdoc:tt_firewall_overview
Updated Documentation Topics:
-- DNS-TLS Proxy Server
https://doc.astlinux-project.org/userdoc:tt_dns_tls_proxy
The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...
AstLinux Project -> Development
https://www.astlinux-project.org/dev.html
AstLinux Team
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2020-06-13 13:41:38
|
Announcing Pre-Release Version: astlinux-1.3-4711-4a99b3 Many under-the-hood updates: New toolchain: glibc 2.27, binutils 2.29.1, gcc 6.5.0, using crosstool-ng-1.24.0 udev, now use eudev version 3.2.9 kmod, version 27, new package which replaces module-init-tools ** IMPORTANT NOTICE -- AstLinux now only supports 64-bit, x86_64 architectures. -- Current supported board types are: "genx86_64", "genx86_64-serial" and "genx86_64-vm" ** 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.84 (version bump), security and bug fixes Kernel config: Add NAMESPACES and CGROUPS for Linux Containers -- lxc, new package, add support for guest Linux Containers. Running Pi-hole for example. New rc.conf variables: LXC_BRIDGE0, LXC_STOP_TIMEOUT More info: https://doc.astlinux-project.org/userdoc:guest_lxc_container_main -- unionfs, move from old kernel unionfs to FUSE unionfs version 2.1 To better secure the filesystem, now only '/etc' and '/stat' will be read-write over the read-only base firmware image. Previously '/' (everything) was overlaid. Additionally, mount ASTURW as /mnt/asturw instead of /oldroot/mnt/asturw . -- New rc.conf variable ASTERISK_RW_MODULES_DIR, give directory /usr/lib/asterisk/modules/ read/write permissions, "yes" or "no", defaults to "no". Example: If you had a codec_g729a.so module installed, you must define: ASTERISK_RW_MODULES_DIR="yes" Note: With AstLinux 1.3.8 and older this was implied to be "yes". -- Asterisk 13.29.2 ('13se' version bump) Older than latest Asterisk 13.x version but more tested, built --without-pjproject -- Asterisk 13.34.0 (version bump) and 16.11.0 (version bump) -- OpenSSL, version bump to 1.1.1g, security fix: CVE-2020-1967 -- WireGuard VPN, module 1.0.20200611 (version bump), tools 1.0.20200513 (version bump) -- OpenVPN, version bump to 2.4.9, security fix: CVE-2020-11810 -- zabbix, major version bump to 4.0.20, next LTS series -- Complete Pre-Release ChangeLog: https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt New Documentation Topics: -- AstLinux Hosted Linux Containers https://doc.astlinux-project.org/userdoc:guest_lxc_container_main -- Firewall Overview https://doc.astlinux-project.org/userdoc:tt_firewall_overview Updated Documentation Topics: -- DNS-TLS Proxy Server https://doc.astlinux-project.org/userdoc:tt_dns_tls_proxy The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... AstLinux Project -> Development https://www.astlinux-project.org/dev.html AstLinux Team |
28 messages has been excluded from this view by a project administrator.
