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: Michael K. <li...@mk...> - 2020-05-23 17:26:21
|
> Am 23.05.2020 um 19:08 schrieb Lonnie Abelbeck <li...@lo...>: > > > >> On May 23, 2020, at 11:15 AM, David Kerr <da...@ke...> wrote: >> >> Is it possible to expand the disk partition that Astlinux uses? For example I am running a test system in ESXi and expanded the disk from 16GB to 32GB. I can see that the "physical" disk is expanded in Astlinux using fdisk... but is there a non-destructive way to expand /dev/sda2 to use that full space? >> >> pbx-test / # fdisk -l >> Disk /dev/sda: 32 GiB, 34359738368 bytes, 67108864 sectors >> Units: sectors of 1 * 512 = 512 bytes >> Sector size (logical/physical): 512 bytes / 512 bytes >> I/O size (minimum/optimal): 512 bytes / 512 bytes >> Disklabel type: dos >> Disk identifier: 0xdd48f40c >> >> Device Boot Start End Sectors Size Id Type >> /dev/sda1 * 2048 524159 522112 255M 6 FAT16 >> /dev/sda2 524288 33554431 33030144 15.8G 83 Linux >> pbx-test / # >> >> Thanks >> David > > Interesting question. > > Looking at this: > https://geekpeek.net/resize-filesystem-fdisk-resize2fs/ > > This would require access via the RUNNIX shell, which has fdisk, e2fsck, but we don't include resize2fs. > > Kind of a unique scenario for only VM's, but I understand why you want this. > > Just thinking out loud ... could you create a new VM disk and install AstLinux from scratch via the ISO installer, then shutdown, attach the old VM drive along with the new VM drive and boot into the RUNNIX shell, mount common partitions and "cp -a ..." the files from the small partition to the large partition. > > For extra credit, could you use this technique to take a unionfs /mnt/kd and convert it to a sda3 /mnt/kd ? > > We could look at enabling resize2fs for RUNNIX builds if this is useful, regardless it is kind of scary deleting the partition you have data on. > > Lonnie Since it is a VM, I would create a backup first, and then try GParted: https://gparted.org/download.php Michael http://www.mksolutions.info |
|
From: Lonnie A. <li...@lo...> - 2020-05-23 17:08:19
|
> On May 23, 2020, at 11:15 AM, David Kerr <da...@ke...> wrote: > > Is it possible to expand the disk partition that Astlinux uses? For example I am running a test system in ESXi and expanded the disk from 16GB to 32GB. I can see that the "physical" disk is expanded in Astlinux using fdisk... but is there a non-destructive way to expand /dev/sda2 to use that full space? > > pbx-test / # fdisk -l > Disk /dev/sda: 32 GiB, 34359738368 bytes, 67108864 sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disklabel type: dos > Disk identifier: 0xdd48f40c > > Device Boot Start End Sectors Size Id Type > /dev/sda1 * 2048 524159 522112 255M 6 FAT16 > /dev/sda2 524288 33554431 33030144 15.8G 83 Linux > pbx-test / # > > Thanks > David Interesting question. Looking at this: https://geekpeek.net/resize-filesystem-fdisk-resize2fs/ This would require access via the RUNNIX shell, which has fdisk, e2fsck, but we don't include resize2fs. Kind of a unique scenario for only VM's, but I understand why you want this. Just thinking out loud ... could you create a new VM disk and install AstLinux from scratch via the ISO installer, then shutdown, attach the old VM drive along with the new VM drive and boot into the RUNNIX shell, mount common partitions and "cp -a ..." the files from the small partition to the large partition. For extra credit, could you use this technique to take a unionfs /mnt/kd and convert it to a sda3 /mnt/kd ? We could look at enabling resize2fs for RUNNIX builds if this is useful, regardless it is kind of scary deleting the partition you have data on. Lonnie |
|
From: David K. <da...@ke...> - 2020-05-23 16:15:59
|
Is it possible to expand the disk partition that Astlinux uses? For example I am running a test system in ESXi and expanded the disk from 16GB to 32GB. I can see that the "physical" disk is expanded in Astlinux using fdisk... but is there a non-destructive way to expand /dev/sda2 to use that full space? pbx-test / # fdisk -l *Disk /dev/sda: 32 GiB, 34359738368 bytes, 67108864 sectors* Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xdd48f40c Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 524159 522112 255M 6 FAT16 /dev/sda2 524288 33554431 33030144 15.8G 83 Linux pbx-test / # Thanks David |
|
From: Lonnie A. <li...@lo...> - 2020-05-23 14:57:20
|
Announcing Pre-Release Version: astlinux-1.3-4671-9b2ac4 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.83 (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 -- 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.33.0 (version bump) and 16.10.0 (version bump) -- OpenSSL, version bump to 1.1.1g, security fix: CVE-2020-1967 -- WireGuard VPN, module 1.0.20200520 (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: -- LXC container in AstLinux https://doc.astlinux-project.org/userdoc:guest_lxc_container -- Firewall Overview https://doc.astlinux-project.org/userdoc:tt_firewall_overview 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-05-21 20:03:17
|
Great thanks Lonnie
Regards
Michael Knill
On 22/5/20, 12:02 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> On May 21, 2020, at 5:47 AM, Michael Keuter <li...@mk...> wrote:
>
>
>
>> Am 21.05.2020 um 02:21 schrieb Michael Knill <mic...@ip...>:
>>
>> Thanks Lonnie
>>
>> I certainly want to go down the path of pushing SE to at least 13.29. Nice there is no pjsip.
>
> It think that would be a good idea bumping SE to 13.29.2 + security updates.
Done.
https://github.com/astlinux-project/astlinux/commit/e0c18e3aa67fd56ede6860bbe416ebc1d85efca0
Note: all previous security updates are included in 13.29.2 .
Will be available to test in the next pre-release snapshot.
Lonnie
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Michael K. <li...@mk...> - 2020-05-21 16:15:50
|
> Am 21.05.2020 um 16:02 schrieb Lonnie Abelbeck <li...@lo...>: > > > >> On May 21, 2020, at 5:47 AM, Michael Keuter <li...@mk...> wrote: >> >> >> >>> Am 21.05.2020 um 02:21 schrieb Michael Knill <mic...@ip...>: >>> >>> Thanks Lonnie >>> >>> I certainly want to go down the path of pushing SE to at least 13.29. Nice there is no pjsip. >> >> It think that would be a good idea bumping SE to 13.29.2 + security updates. > > Done. > > https://github.com/astlinux-project/astlinux/commit/e0c18e3aa67fd56ede6860bbe416ebc1d85efca0 > > Note: all previous security updates are included in 13.29.2 . > > Will be available to test in the next pre-release snapshot. > > Lonnie It would be a good time for a new dev-release now :-). Michael http://www.mksolutions.info |
|
From: Lonnie A. <li...@lo...> - 2020-05-21 14:02:23
|
> On May 21, 2020, at 5:47 AM, Michael Keuter <li...@mk...> wrote: > > > >> Am 21.05.2020 um 02:21 schrieb Michael Knill <mic...@ip...>: >> >> Thanks Lonnie >> >> I certainly want to go down the path of pushing SE to at least 13.29. Nice there is no pjsip. > > It think that would be a good idea bumping SE to 13.29.2 + security updates. Done. https://github.com/astlinux-project/astlinux/commit/e0c18e3aa67fd56ede6860bbe416ebc1d85efca0 Note: all previous security updates are included in 13.29.2 . Will be available to test in the next pre-release snapshot. Lonnie |
|
From: Michael K. <li...@mk...> - 2020-05-21 10:47:39
|
> Am 21.05.2020 um 02:21 schrieb Michael Knill <mic...@ip...>: > > Thanks Lonnie > > I certainly want to go down the path of pushing SE to at least 13.29. Nice there is no pjsip. It think that would be a good idea bumping SE to 13.29.2 + secutity updates. > I'm wondering though about the point considering that its only Security fixes at the end of October which is probably something I would like to keep in the release? > > What do you think? > > Regards > Michael Knill > > On 20/5/20, 10:39 pm, "Lonnie Abelbeck" <li...@lo...> wrote: > > >> On May 20, 2020, at 4:41 AM, Michael Knill <mic...@ip...> wrote: >> >> Is there an easy way to tell what commit is in what release? >> >> Regards >> Michael Knill > > The github mirror of Asterisk shows which tags are included. > > Looking back from here (13.29.2): > https://github.com/asterisk/asterisk/commits/13.29/apps/app_queue.c > > to Sept 2018 where 13.23.1 is based, I see three app_queue.c "fix crash" commits. > > app_queue: Revert broken queue channel reference patch > https://github.com/asterisk/asterisk/commit/91630834f784061ced7f01e55d8d6929d1350c8b#diff-a1ab912bb1327820884f2c5951760c74 > > app_queue: Handle empty 'interface' in queue member config > https://github.com/asterisk/asterisk/commit/cb6a97665671400b92e1c2da5944d59773521176#diff-a1ab912bb1327820884f2c5951760c74 > > app_queue: fix ring_entry to access nativeformats with a channel lock > https://github.com/asterisk/asterisk/commit/92d18898137036a44064f73b1e73312c835ab989#diff-a1ab912bb1327820884f2c5951760c74 > > We could add these to 13se, or possibly this is a good time to bump 13se to 13.29.2 provided that was a generally stable Asterisk release. > > Lonnie Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2020-05-21 01:33:10
|
Ah cool I didn't realise that sorry Lonnie.
Sounds like a great idea then. I do like the SE concept.
Regards
Michael Knill
On 21/5/20, 11:29 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Michael,
We always add applicable security fixes to the 13se version.
Lonnie
> On May 20, 2020, at 7:21 PM, Michael Knill <mic...@ip...> wrote:
>
> Thanks Lonnie
>
> I certainly want to go down the path of pushing SE to at least 13.29. Nice there is no pjsip.
> I'm wondering though about the point considering that its only Security fixes at the end of October which is probably something I would like to keep in the release?
>
> What do you think?
>
> Regards
> Michael Knill
>
> On 20/5/20, 10:39 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>
>
>
>> On May 20, 2020, at 4:41 AM, Michael Knill <mic...@ip...> wrote:
>>
>> Is there an easy way to tell what commit is in what release?
>>
>> Regards
>> Michael Knill
>
> The github mirror of Asterisk shows which tags are included.
>
> Looking back from here (13.29.2):
> https://github.com/asterisk/asterisk/commits/13.29/apps/app_queue.c
>
> to Sept 2018 where 13.23.1 is based, I see three app_queue.c "fix crash" commits.
>
> app_queue: Revert broken queue channel reference patch
> https://github.com/asterisk/asterisk/commit/91630834f784061ced7f01e55d8d6929d1350c8b#diff-a1ab912bb1327820884f2c5951760c74
>
> app_queue: Handle empty 'interface' in queue member config
> https://github.com/asterisk/asterisk/commit/cb6a97665671400b92e1c2da5944d59773521176#diff-a1ab912bb1327820884f2c5951760c74
>
> app_queue: fix ring_entry to access nativeformats with a channel lock
> https://github.com/asterisk/asterisk/commit/92d18898137036a44064f73b1e73312c835ab989#diff-a1ab912bb1327820884f2c5951760c74
>
> We could add these to 13se, or possibly this is a good time to bump 13se to 13.29.2 provided that was a generally stable Asterisk release.
>
> 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-05-21 01:29:47
|
Michael, We always add applicable security fixes to the 13se version. Lonnie > On May 20, 2020, at 7:21 PM, Michael Knill <mic...@ip...> wrote: > > Thanks Lonnie > > I certainly want to go down the path of pushing SE to at least 13.29. Nice there is no pjsip. > I'm wondering though about the point considering that its only Security fixes at the end of October which is probably something I would like to keep in the release? > > What do you think? > > Regards > Michael Knill > > On 20/5/20, 10:39 pm, "Lonnie Abelbeck" <li...@lo...> wrote: > > > >> On May 20, 2020, at 4:41 AM, Michael Knill <mic...@ip...> wrote: >> >> Is there an easy way to tell what commit is in what release? >> >> Regards >> Michael Knill > > The github mirror of Asterisk shows which tags are included. > > Looking back from here (13.29.2): > https://github.com/asterisk/asterisk/commits/13.29/apps/app_queue.c > > to Sept 2018 where 13.23.1 is based, I see three app_queue.c "fix crash" commits. > > app_queue: Revert broken queue channel reference patch > https://github.com/asterisk/asterisk/commit/91630834f784061ced7f01e55d8d6929d1350c8b#diff-a1ab912bb1327820884f2c5951760c74 > > app_queue: Handle empty 'interface' in queue member config > https://github.com/asterisk/asterisk/commit/cb6a97665671400b92e1c2da5944d59773521176#diff-a1ab912bb1327820884f2c5951760c74 > > app_queue: fix ring_entry to access nativeformats with a channel lock > https://github.com/asterisk/asterisk/commit/92d18898137036a44064f73b1e73312c835ab989#diff-a1ab912bb1327820884f2c5951760c74 > > We could add these to 13se, or possibly this is a good time to bump 13se to 13.29.2 provided that was a generally stable Asterisk release. > > 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-05-21 00:21:38
|
Thanks Lonnie
I certainly want to go down the path of pushing SE to at least 13.29. Nice there is no pjsip.
I'm wondering though about the point considering that its only Security fixes at the end of October which is probably something I would like to keep in the release?
What do you think?
Regards
Michael Knill
On 20/5/20, 10:39 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
> On May 20, 2020, at 4:41 AM, Michael Knill <mic...@ip...> wrote:
>
> Is there an easy way to tell what commit is in what release?
>
> Regards
> Michael Knill
The github mirror of Asterisk shows which tags are included.
Looking back from here (13.29.2):
https://github.com/asterisk/asterisk/commits/13.29/apps/app_queue.c
to Sept 2018 where 13.23.1 is based, I see three app_queue.c "fix crash" commits.
app_queue: Revert broken queue channel reference patch
https://github.com/asterisk/asterisk/commit/91630834f784061ced7f01e55d8d6929d1350c8b#diff-a1ab912bb1327820884f2c5951760c74
app_queue: Handle empty 'interface' in queue member config
https://github.com/asterisk/asterisk/commit/cb6a97665671400b92e1c2da5944d59773521176#diff-a1ab912bb1327820884f2c5951760c74
app_queue: fix ring_entry to access nativeformats with a channel lock
https://github.com/asterisk/asterisk/commit/92d18898137036a44064f73b1e73312c835ab989#diff-a1ab912bb1327820884f2c5951760c74
We could add these to 13se, or possibly this is a good time to bump 13se to 13.29.2 provided that was a generally stable Asterisk release.
Lonnie
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: David K. <da...@ke...> - 2020-05-20 18:13:28
|
Ramesh, I think you will find that there are several people on this list that use AstLinux in SMB settings... making their living selling and supporting services with AstLinux at the core. On each of your points AstLinux has a way to address. - Routing and Firewall is built in. Uses Arno iptables firewall. - DNS... we use dnsmasq - DHCP... dnsmasq is our dhcp server. IPv4 only. - We recommend an external cellular modem like NetGear LB1121. Astlinux has WAN failover that will work with that. - Current development builds include LXC containers. With that you could add a full mail server (I installed Postfix the other day). - You could do a custom build of AstLinux to include python. But with LXC I think you're better off putting that, and Java, into a container. Regards, David On Wed, May 20, 2020 at 1:15 PM Ramesh GK <ram...@ho...> wrote: > Hi, > > I have been an avid follower of your project since last 1.5yrs and at one > point used it to fit my needs as a Home Gateway Appliance however I was > looking to make it extensible by bringing in other components to make it as > a full blown suite which can also be used by SMBs too. > > - routing & firewall - shorewall (optional) > - dns - bind > - dhcp - isc dhcp server > - mail server - exim4 & dovecot > - in-built cellular services using modem manager & network manager for > sending alerts/notifications when primary network goes down > - java/python for developing additional/extending the existing > functionality. For example support for openhab or homeassistant home > automation > > Please let know if this is of your interest. > > Thanks > Ramesh GK > *Strive not to be a success but rather to be of value - Albert Einstein* > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > |
|
From: Lonnie A. <li...@lo...> - 2020-05-20 18:12:21
|
> On May 20, 2020, at 1:04 PM, Michael Keuter <li...@mk...> wrote: > > > >> Am 20.05.2020 um 19:14 schrieb Ramesh GK <ram...@ho...>: >> >> Hi, >> >> I have been an avid follower of your project since last 1.5yrs and at one point used it to fit my needs as a Home Gateway Appliance however I was looking to make it extensible by bringing in other components to make it as a full blown suite which can also be used by SMBs too. >> >> - routing & firewall - shorewall (optional) >> - dns - bind >> - dhcp - isc dhcp server >> - mail server - exim4 & dovecot >> - in-built cellular services using modem manager & network manager for sending alerts/notifications when primary network goes down >> - java/python for developing additional/extending the existing functionality. For example support for openhab or homeassistant home automation >> >> Please let know if this is of your interest. >> >> Thanks >> Ramesh GK >> Strive not to be a success but rather to be of value - Albert Einstein > > Hi Ramesh, > > please read the first paragraph about the AstLinux Principles: > > https://www.astlinux-project.org/about.html > > Michael Exactly. Keeping a minimal code footprint has many advantages. But, for special cases, we will be supporting guest Linux Containers in the next release of AstLinux. Lonnie |
|
From: Michael K. <li...@mk...> - 2020-05-20 18:04:15
|
> Am 20.05.2020 um 19:14 schrieb Ramesh GK <ram...@ho...>: > > Hi, > > I have been an avid follower of your project since last 1.5yrs and at one point used it to fit my needs as a Home Gateway Appliance however I was looking to make it extensible by bringing in other components to make it as a full blown suite which can also be used by SMBs too. > > - routing & firewall - shorewall (optional) > - dns - bind > - dhcp - isc dhcp server > - mail server - exim4 & dovecot > - in-built cellular services using modem manager & network manager for sending alerts/notifications when primary network goes down > - java/python for developing additional/extending the existing functionality. For example support for openhab or homeassistant home automation > > Please let know if this is of your interest. > > Thanks > Ramesh GK > Strive not to be a success but rather to be of value - Albert Einstein Hi Ramesh, please read the first paragraph about the AstLinux Principles: https://www.astlinux-project.org/about.html Michael http://www.mksolutions.info |
|
From: Ramesh GK <ram...@ho...> - 2020-05-20 17:15:09
|
Hi, I have been an avid follower of your project since last 1.5yrs and at one point used it to fit my needs as a Home Gateway Appliance however I was looking to make it extensible by bringing in other components to make it as a full blown suite which can also be used by SMBs too. - routing & firewall - shorewall (optional) - dns - bind - dhcp - isc dhcp server - mail server - exim4 & dovecot - in-built cellular services using modem manager & network manager for sending alerts/notifications when primary network goes down - java/python for developing additional/extending the existing functionality. For example support for openhab or homeassistant home automation Please let know if this is of your interest. Thanks Ramesh GK Strive not to be a success but rather to be of value - Albert Einstein |
|
From: Lonnie A. <li...@lo...> - 2020-05-20 12:39:44
|
> On May 20, 2020, at 4:41 AM, Michael Knill <mic...@ip...> wrote: > > Is there an easy way to tell what commit is in what release? > > Regards > Michael Knill The github mirror of Asterisk shows which tags are included. Looking back from here (13.29.2): https://github.com/asterisk/asterisk/commits/13.29/apps/app_queue.c to Sept 2018 where 13.23.1 is based, I see three app_queue.c "fix crash" commits. app_queue: Revert broken queue channel reference patch https://github.com/asterisk/asterisk/commit/91630834f784061ced7f01e55d8d6929d1350c8b#diff-a1ab912bb1327820884f2c5951760c74 app_queue: Handle empty 'interface' in queue member config https://github.com/asterisk/asterisk/commit/cb6a97665671400b92e1c2da5944d59773521176#diff-a1ab912bb1327820884f2c5951760c74 app_queue: fix ring_entry to access nativeformats with a channel lock https://github.com/asterisk/asterisk/commit/92d18898137036a44064f73b1e73312c835ab989#diff-a1ab912bb1327820884f2c5951760c74 We could add these to 13se, or possibly this is a good time to bump 13se to 13.29.2 provided that was a generally stable Asterisk release. Lonnie |
|
From: Michael K. <li...@mk...> - 2020-05-20 12:21:48
|
> Am 20.05.2020 um 12:03 schrieb Michael Knill <mic...@ip... <mailto:mic...@ip...>>: > > Well I guess that's true but due to the apparent maturity of Asterisk 13, it begs the question why I wouldn't use the latest version for everything. > I thought the point of an SE version is a baseline, known stable working version that is not potentially broken with new features added. > Considering that Asterisk 13 will be Security Fix Only on 24 October 2020, does an SE version even make sense for version 13? Would it be something better added to version 16? I personally use 16 in my office. And yes, there was also a 16cert version released lately. > I'm thinking of moving everything off SE now. Does this seem reasonable? As I said I use SE only for AstLinux routers only (where Asterisk is disabled) or when I need only very basic stuff (or testing something), otherwise 13. > Regards > Michael Knill > > On 20/5/20, 7:41 pm, "Michael Keuter" <li...@mk...> wrote: > > > >> Am 20.05.2020 um 11:33 schrieb Michael Keuter <li...@mk...>: >> >> >> >>> Am 20.05.2020 um 11:25 schrieb Michael Knill <mic...@ip...>: >>> >>> At one of my large customer sites, when I implemented an IVR which uses Local channels to forward to a queue, I got regular seg faults on app_queue.so crashing Asterisk. This was a previous problem and I was hoping the SE version would fix it but it didn't. >>> When I upgraded from Asterisk 13.23.1 (SE) to Asterisk 13.29.2, the problem is now gone. >>> >>> Not sure how we should handle this? Ideally it would be good to find where this problem was fixed and make that the SE version but not sure how we pick an SE version. >>> >>> Regards >>> Michael Knill >> >> Hi Michael, >> >> I would start here: >> >> http://git.asterisk.org/gitweb/?p=asterisk/asterisk.git;a=history;f=apps/app_queue.c;h=53ae2ba1c59ffc1fbadc2e1d197624856fc9ae24;hb=1863c35fc3f888d726e54e8674ec78a7cd099e34 >> >> This is the history of "app_queue.c" backwards from 13.29.2. > > There were lots of changes compared to 13.21-cert6: > > http://git.asterisk.org/gitweb/?p=asterisk/asterisk.git;a=history;f=apps/app_queue.c;h=f783ac94deedd7f10fff365c3b7dde2afdf85833;hb=a8b7b407f9a3f1c12d0aa03761cd32b550d6a140 > > Why don't you use the latest Asterisk 13 version? > In the cert version there were no updates for more than half a year: > http://git.asterisk.org/gitweb/?p=asterisk/asterisk.git;a=shortlog;h=refs/heads/certified/13.21 > > I use the cert version only when I only need basic stuff or on routers etc. > app_queue is definitely no basic stuff, but quite complex. > > Michael Michael http://www.mksolutions.info |
|
From: Michael K. <li...@mk...> - 2020-05-20 12:21:17
|
> Am 20.05.2020 um 11:41 schrieb Michael Knill <mic...@ip... <mailto:mic...@ip...>>: > > Is there an easy way to tell what commit is in what release? > > Regards > Michael Knill Yes, do what I did and compare each release with each other one. > On 20/5/20, 7:33 pm, "Michael Keuter" <li...@mk...> wrote: > > > >> Am 20.05.2020 um 11:25 schrieb Michael Knill <mic...@ip...>: >> >> At one of my large customer sites, when I implemented an IVR which uses Local channels to forward to a queue, I got regular seg faults on app_queue.so crashing Asterisk. This was a previous problem and I was hoping the SE version would fix it but it didn't. >> When I upgraded from Asterisk 13.23.1 (SE) to Asterisk 13.29.2, the problem is now gone. >> >> Not sure how we should handle this? Ideally it would be good to find where this problem was fixed and make that the SE version but not sure how we pick an SE version. >> >> Regards >> Michael Knill > > Hi Michael, > > I would start here: > > http://git.asterisk.org/gitweb/?p=asterisk/asterisk.git;a=history;f=apps/app_queue.c;h=53ae2ba1c59ffc1fbadc2e1d197624856fc9ae24;hb=1863c35fc3f888d726e54e8674ec78a7cd099e34 > > This is the history of "app_queue.c" backwards from 13.29.2. > > Michael Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2020-05-20 10:03:32
|
Well I guess that's true but due to the apparent maturity of Asterisk 13, it begs the question why I wouldn't use the latest version for everything.
I thought the point of an SE version is a baseline, known stable working version that is not potentially broken with new features added.
Considering that Asterisk 13 will be Security Fix Only on 24 October 2020, does an SE version even make sense for version 13? Would it be something better added to version 16?
I'm thinking of moving everything off SE now. Does this seem reasonable?
Regards
Michael Knill
On 20/5/20, 7:41 pm, "Michael Keuter" <li...@mk...> wrote:
> Am 20.05.2020 um 11:33 schrieb Michael Keuter <li...@mk...>:
>
>
>
>> Am 20.05.2020 um 11:25 schrieb Michael Knill <mic...@ip...>:
>>
>> At one of my large customer sites, when I implemented an IVR which uses Local channels to forward to a queue, I got regular seg faults on app_queue.so crashing Asterisk. This was a previous problem and I was hoping the SE version would fix it but it didn't.
>> When I upgraded from Asterisk 13.23.1 (SE) to Asterisk 13.29.2, the problem is now gone.
>>
>> Not sure how we should handle this? Ideally it would be good to find where this problem was fixed and make that the SE version but not sure how we pick an SE version.
>>
>> Regards
>> Michael Knill
>
> Hi Michael,
>
> I would start here:
>
> http://git.asterisk.org/gitweb/?p=asterisk/asterisk.git;a=history;f=apps/app_queue.c;h=53ae2ba1c59ffc1fbadc2e1d197624856fc9ae24;hb=1863c35fc3f888d726e54e8674ec78a7cd099e34
>
> This is the history of "app_queue.c" backwards from 13.29.2.
There were lots of changes compared to 13.21-cert6:
http://git.asterisk.org/gitweb/?p=asterisk/asterisk.git;a=history;f=apps/app_queue.c;h=f783ac94deedd7f10fff365c3b7dde2afdf85833;hb=a8b7b407f9a3f1c12d0aa03761cd32b550d6a140
Why don't you use the latest Asterisk 13 version?
In the cert version there were no updates for more than half a year:
http://git.asterisk.org/gitweb/?p=asterisk/asterisk.git;a=shortlog;h=refs/heads/certified/13.21
I use the cert version only when I only need basic stuff or on routers etc.
app_queue is definitely no basic stuff, but quite complex.
Michael
http://www.mksolutions.info
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Michael K. <mic...@ip...> - 2020-05-20 09:41:14
|
Is there an easy way to tell what commit is in what release?
Regards
Michael Knill
On 20/5/20, 7:33 pm, "Michael Keuter" <li...@mk...> wrote:
> Am 20.05.2020 um 11:25 schrieb Michael Knill <mic...@ip...>:
>
> At one of my large customer sites, when I implemented an IVR which uses Local channels to forward to a queue, I got regular seg faults on app_queue.so crashing Asterisk. This was a previous problem and I was hoping the SE version would fix it but it didn't.
> When I upgraded from Asterisk 13.23.1 (SE) to Asterisk 13.29.2, the problem is now gone.
>
> Not sure how we should handle this? Ideally it would be good to find where this problem was fixed and make that the SE version but not sure how we pick an SE version.
>
> Regards
> Michael Knill
Hi Michael,
I would start here:
http://git.asterisk.org/gitweb/?p=asterisk/asterisk.git;a=history;f=apps/app_queue.c;h=53ae2ba1c59ffc1fbadc2e1d197624856fc9ae24;hb=1863c35fc3f888d726e54e8674ec78a7cd099e34
This is the history of "app_queue.c" backwards from 13.29.2.
Michael
http://www.mksolutions.info
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Michael K. <li...@mk...> - 2020-05-20 09:40:55
|
> Am 20.05.2020 um 11:33 schrieb Michael Keuter <li...@mk...>: > > > >> Am 20.05.2020 um 11:25 schrieb Michael Knill <mic...@ip...>: >> >> At one of my large customer sites, when I implemented an IVR which uses Local channels to forward to a queue, I got regular seg faults on app_queue.so crashing Asterisk. This was a previous problem and I was hoping the SE version would fix it but it didn't. >> When I upgraded from Asterisk 13.23.1 (SE) to Asterisk 13.29.2, the problem is now gone. >> >> Not sure how we should handle this? Ideally it would be good to find where this problem was fixed and make that the SE version but not sure how we pick an SE version. >> >> Regards >> Michael Knill > > Hi Michael, > > I would start here: > > http://git.asterisk.org/gitweb/?p=asterisk/asterisk.git;a=history;f=apps/app_queue.c;h=53ae2ba1c59ffc1fbadc2e1d197624856fc9ae24;hb=1863c35fc3f888d726e54e8674ec78a7cd099e34 > > This is the history of "app_queue.c" backwards from 13.29.2. There were lots of changes compared to 13.21-cert6: http://git.asterisk.org/gitweb/?p=asterisk/asterisk.git;a=history;f=apps/app_queue.c;h=f783ac94deedd7f10fff365c3b7dde2afdf85833;hb=a8b7b407f9a3f1c12d0aa03761cd32b550d6a140 Why don't you use the latest Asterisk 13 version? In the cert version there were no updates for more than half a year: http://git.asterisk.org/gitweb/?p=asterisk/asterisk.git;a=shortlog;h=refs/heads/certified/13.21 I use the cert version only when I only need basic stuff or on routers etc. app_queue is definitely no basic stuff, but quite complex. Michael http://www.mksolutions.info |
|
From: Michael K. <li...@mk...> - 2020-05-20 09:33:39
|
> Am 20.05.2020 um 11:25 schrieb Michael Knill <mic...@ip...>: > > At one of my large customer sites, when I implemented an IVR which uses Local channels to forward to a queue, I got regular seg faults on app_queue.so crashing Asterisk. This was a previous problem and I was hoping the SE version would fix it but it didn't. > When I upgraded from Asterisk 13.23.1 (SE) to Asterisk 13.29.2, the problem is now gone. > > Not sure how we should handle this? Ideally it would be good to find where this problem was fixed and make that the SE version but not sure how we pick an SE version. > > Regards > Michael Knill Hi Michael, I would start here: http://git.asterisk.org/gitweb/?p=asterisk/asterisk.git;a=history;f=apps/app_queue.c;h=53ae2ba1c59ffc1fbadc2e1d197624856fc9ae24;hb=1863c35fc3f888d726e54e8674ec78a7cd099e34 This is the history of "app_queue.c" backwards from 13.29.2. Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2020-05-20 09:26:06
|
At one of my large customer sites, when I implemented an IVR which uses Local channels to forward to a queue, I got regular seg faults on app_queue.so crashing Asterisk. This was a previous problem and I was hoping the SE version would fix it but it didn't. When I upgraded from Asterisk 13.23.1 (SE) to Asterisk 13.29.2, the problem is now gone. Not sure how we should handle this? Ideally it would be good to find where this problem was fixed and make that the SE version but not sure how we pick an SE version. Regards Michael Knill |
|
From: Lonnie A. <li...@lo...> - 2020-05-03 13:30:20
|
Announcing Pre-Release Version: astlinux-1.3-4637-eff0be
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.83 (version bump), security and bug fixes
-- 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.23.1 ('13se' version)
Older than latest Asterisk 13.x version but more tested, built --without-pjproject
-- Asterisk 13.33.0 (version bump) and 16.10.0 (version bump)
-- OpenSSL, version bump to 1.1.1g, security fix: CVE-2020-1967
-- WireGuard VPN, module 1.0.20200429 (version bump), tools 1.0.20200319 (no change)
-- OpenVPN, version bump to 2.4.9, security fix: CVE-2020-11810
-- 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. <mic...@ip...> - 2020-05-01 23:34:46
|
Thanks Lonnie
Regards
Michael Knill
On 2/5/20, 9:32 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> On May 1, 2020, at 6:13 PM, Michael Knill <mic...@ip...> wrote:
>
> Thanks Lonnie for all your work.
> I did a random check of my systems and all good as far as no additional binaries added. I do have one site that has binaries added for QueueMetrics but this is in /mnt/kd/bin which I assume will still be fine.
Yes, /mnt/kd/bin is perfectly fine.
> I have a few APU1's out there which are certainly slower than APU2's. Are they going to be impacted significantly do you think?
Last I checked (a few years ago) the APU1 was faster than an APU2 for single core, the APU2 wins for multicore.
APU1 -> Performance: 59.1 secs. (Single-core test, lower is better)
APU2 -> Performance: 66.6 secs. (Single-core test, lower is better)
Test# time ( echo "scale=3456; 4*a(1)" | bc -l )
I would expect the APU1 to be just fine, no noticeable change.
Also keep in mind this FUSE unionfs change does not effect pure CPU driven code, only when the filesystem accesses the '/etc' or '/stat' paths.
Lonnie
> Regards
> Michael Knill
>
> On 2/5/20, 4:27 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Hi Dev minded folks,
>
> We have completed a significant transition from a kernel based unionfs filesystem to a FUSE (in-kernel + userland) unionfs filesystem.
>
> A key goal, any change needs to be backward compatible with pre-existing ASTURW partitions.
>
> With that, there are a few changes. All good changes, we hope. :-)
>
> The old kernel unionfs (via a kernel patch) has not been supported for years, we stretched it's usefulness to the linux kernel 3.16.x, but it is an anchor keeping us from moving to newer kernel versions.
>
> We considered a shiny new anchor :-), Aufs, which is also implemented via a kernel patch, more featured/bloated than the previous kernel unionfs and it has targeted support for only select kernel versions.
>
> Given the decision for AstLinux to only support 64-bit, x86_64 boards going forward, we wondered how the FUSE unionfs would perform.
>
> We gave FUSE unionfs a try on one of the lowest powered x86_64 boards, the PC Engines APU2 ...
>
>
> Previously the full root '/' read-only mount was overlaid with the writable ASTURW partition to yield a read/write filesystem ... unionfs.
>
> While FUSE unionfs worked fine as a replacement for a '/' unionfs overlay, the filesystem speed suffered on the APU2, for example reloading the firewall took 3x the time. BTW, the FUSE unionfs is slower since it adds a lot of userland <-> kernel context switches.
>
> So then we thought, we really only need (mostly) the '/etc' and '/stat' directories to be overlaid to be made writable, which allowed moving the unionfs mount from the initrd into the /etc/rc startup script. That change returned the APU2 reload firewall performance to nearly it's previous time ... now the '/usr', '/lib', paths are very-slightly faster than before since there is no kernel unionfs overhead, but any '/etc' access is somewhat slower. Overall, no significant filesystem performance difference.
>
> So, FUSE unionfs for select directories is the new solution for Astlinux 1.3.10 and onward. No more kernel limiting anchors.
>
> This also better secures the filesystem, no accidental (or malicious) changing of '/usr', '/lib', binaries and scripts.
>
> The devil is in the details ...
>
> Some users may have partitioned their AstLinux installation by selecting "Combined Unionfs and /mnt/kd/ partition", so that is automatically supported when there is no separate ASTKD partition for '/mnt/kd'.
>
> Note: New installations now only support "Create separate Unionfs and /mnt/kd/ partitions", which has been the better choice.
>
> Some users may have installed binary blobs like codec_g729a.so to the Asterisk /usr/lib/asterisk/modules/ directory. The new default for this directory is to be read-only, but if the user adds ASTERISK_RW_MODULES_DIR="yes" to their user.conf this directory will be overlaid by the ASTURW partition, as it was before. This also creates an easy way to disable incompatible binary blobs from keeping Asterisk from starting.
>
>
> Finally, some homework for those reading this (yes you!). To make sure we did not overlook anything, issue this command:
> --
> show-union all | grep -v -e /asturw/etc -e /asturw/stat -e lost.found -e /asturw/mnt/kd
> --
>
> You might see
> --
> /oldroot/mnt/asturw
> /oldroot/mnt/asturw/.rnd
> /oldroot/mnt/asturw/.asterisk_history
> --
> which can be safely ignored.
>
> If you see some '/usr', '/lib', files that may seem important to you, let us know.
>
>
> The AstLinux Team
>
>
>
>
> _______________________________________________
> 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
|
28 messages has been excluded from this view by a project administrator.
