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
|
I define a "/mnt/kd/blocklists/whitelist.netset" for anything important, so a bad IP (intentional or not) in a .netset does not effect production operation. Lonnie > On Oct 13, 2021, at 5:58 PM, Michael Knill <mic...@ip...> wrote: > > Security maybe. Prevent the list from being poisoned? > Its one of the bigger concerns I have with netset and why I have not implemented it yet. > > Regards > Michael Knill > > On 14/10/21, 9:46 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > Interesting, why an API (key) rather than a .netset file updated twice a day or so? > > Their database could be easily incorporated into AstLinux if it were a downloadable .netset file. > > Possibly they are looking at charging to use it, hence the API key? > > Possibly I'm missing something. > > Thanks for sharing Michael. > > Lonnie > > >> On Oct 13, 2021, at 4:23 PM, Michael Knill <mic...@ip...> wrote: >> >> APIBAN looks very interesting. There will be a session on it at Astricon this year as well. >> I assume that banned IP addresses could just be pulled into a netset list? >> >> https://apiban.org/doc.html >> https://www.securevoip.io/48-hours-with-apiban/ >> >> Regards >> >> Michael Knill >> Managing Director >> >> D: +61 2 6189 1360 >> P: +61 2 6140 4656 >> E: mic...@ip... >> W: ipcsolutions.com.au >> >> <image001.png> >> Smarter Business Communications >> >> _______________________________________________ >> 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: Michael K. <li...@mk...> - 2021-10-13 23:04:17
|
Michael, there is also a „whitelist.netset“ where you can whitelist over all netsets. I use the netsets on all my customers (mostly for outbound blocking) together with a whitelist of common addresses and had no issues so far. Though I have SIP only allowed for their VoIP providers. Sent from a mobile device. Michael Keuter > Am 14.10.2021 um 00:58 schrieb Michael Knill <mic...@ip...>: > > Security maybe. Prevent the list from being poisoned? > Its one of the bigger concerns I have with netset and why I have not implemented it yet. > > Regards > Michael Knill > > On 14/10/21, 9:46 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > Interesting, why an API (key) rather than a .netset file updated twice a day or so? > > Their database could be easily incorporated into AstLinux if it were a downloadable .netset file. > > Possibly they are looking at charging to use it, hence the API key? > > Possibly I'm missing something. > > Thanks for sharing Michael. > > Lonnie > > >> On Oct 13, 2021, at 4:23 PM, Michael Knill <mic...@ip...> wrote: >> >> APIBAN looks very interesting. There will be a session on it at Astricon this year as well. >> I assume that banned IP addresses could just be pulled into a netset list? >> >> https://apiban.org/doc.html >> https://www.securevoip.io/48-hours-with-apiban/ >> >> Regards >> >> Michael Knill >> Managing Director >> >> D: +61 2 6189 1360 >> P: +61 2 6140 4656 >> E: mic...@ip... >> W: ipcsolutions.com.au >> >> <image001.png> >> Smarter Business Communications >> >> _______________________________________________ >> 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: Michael K. <mic...@ip...> - 2021-10-13 22:58:14
|
Security maybe. Prevent the list from being poisoned?
Its one of the bigger concerns I have with netset and why I have not implemented it yet.
Regards
Michael Knill
On 14/10/21, 9:46 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Interesting, why an API (key) rather than a .netset file updated twice a day or so?
Their database could be easily incorporated into AstLinux if it were a downloadable .netset file.
Possibly they are looking at charging to use it, hence the API key?
Possibly I'm missing something.
Thanks for sharing Michael.
Lonnie
> On Oct 13, 2021, at 4:23 PM, Michael Knill <mic...@ip...> wrote:
>
> APIBAN looks very interesting. There will be a session on it at Astricon this year as well.
> I assume that banned IP addresses could just be pulled into a netset list?
>
> https://apiban.org/doc.html
> https://www.securevoip.io/48-hours-with-apiban/
>
> Regards
>
> Michael Knill
> Managing Director
>
> D: +61 2 6189 1360
> P: +61 2 6140 4656
> E: mic...@ip...
> W: ipcsolutions.com.au
>
> <image001.png>
> Smarter Business Communications
>
> _______________________________________________
> 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...> - 2021-10-13 22:55:40
|
Yep it needs to go into a netset list aggregated with iprange. Note their client does actually work on Astlinux. Should be pretty easy to do! Regards Michael Knill From: Michael Keuter <li...@mk...> Reply to: AstLinux Developers Mailing List <ast...@li...> Date: Thursday, 14 October 2021 at 9:41 am To: AstLinux Developers Mailing List <ast...@li...> Subject: Re: [Astlinux-devel] Using APIBAN in Astlinux Quite interesting thread about apiban: https://community.freepbx.org/t/integrating-apiban-org-with-freepbx/69422/11 Sent from a mobile device. Michael Keuter Am 13.10.2021 um 23:24 schrieb Michael Knill <mic...@ip...>: APIBAN looks very interesting. There will be a session on it at Astricon this year as well. I assume that banned IP addresses could just be pulled into a netset list? https://apiban.org/doc.html https://www.securevoip.io/48-hours-with-apiban/ Regards Michael Knill Managing Director D: +61 2 6189 1360 P: +61 2 6140 4656 E: mic...@ip...<mailto:mic...@ip...> W: ipcsolutions.com.au<https://ipcsolutions.com.au/> <image001.png> Smarter Business Communications _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Lonnie A. <li...@lo...> - 2021-10-13 22:45:56
|
Interesting, why an API (key) rather than a .netset file updated twice a day or so? Their database could be easily incorporated into AstLinux if it were a downloadable .netset file. Possibly they are looking at charging to use it, hence the API key? Possibly I'm missing something. Thanks for sharing Michael. Lonnie > On Oct 13, 2021, at 4:23 PM, Michael Knill <mic...@ip...> wrote: > > APIBAN looks very interesting. There will be a session on it at Astricon this year as well. > I assume that banned IP addresses could just be pulled into a netset list? > > https://apiban.org/doc.html > https://www.securevoip.io/48-hours-with-apiban/ > > Regards > > Michael Knill > Managing Director > > D: +61 2 6189 1360 > P: +61 2 6140 4656 > E: mic...@ip... > W: ipcsolutions.com.au > > <image001.png> > Smarter Business Communications > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <li...@mk...> - 2021-10-13 22:41:33
|
Quite interesting thread about apiban: https://community.freepbx.org/t/integrating-apiban-org-with-freepbx/69422/11 Sent from a mobile device. Michael Keuter > Am 13.10.2021 um 23:24 schrieb Michael Knill <mic...@ip...>: > > > APIBAN looks very interesting. There will be a session on it at Astricon this year as well. > I assume that banned IP addresses could just be pulled into a netset list? > > https://apiban.org/doc.html > https://www.securevoip.io/48-hours-with-apiban/ > > Regards > > Michael Knill > Managing Director > > D: +61 2 6189 1360 > P: +61 2 6140 4656 > E: mic...@ip... > W: ipcsolutions.com.au > > > <image001.png> > Smarter Business Communications > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2021-10-13 21:24:01
|
APIBAN looks very interesting. There will be a session on it at Astricon this year as well. I assume that banned IP addresses could just be pulled into a netset list? https://apiban.org/doc.html https://www.securevoip.io/48-hours-with-apiban/ Regards Michael Knill Managing Director D: +61 2 6189 1360 P: +61 2 6140 4656 E: mic...@ip...<mailto:mic...@ip...> W: ipcsolutions.com.au<https://ipcsolutions.com.au/> [IPC Solutions] Smarter Business Communications |
|
From: Michael K. <mic...@ip...> - 2021-09-19 20:48:08
|
Hi Lonnie
Yes that is a concern ☹.
We have firewalled it using Vultr. You can also specify IP Address in the initial registration that it only allows requests from.
Although acme-dns is a much better solution, ultimately I just wanted a sacrificial DNS for the ACME Challenge TXT records rather than having my primary DNS API credentials on every system.
My understanding is that if acme-dns was compromised, the most that could be done is that we cant issue certificates any more. I'm sure there is more but certainly the risk and impact is far less than the potential release of primary DNS API credentials.
Regards
Michael Knill
On 19/9/21, 12:19 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
Documenting would be great. This could be universally useful to anyone with a constellation of AstLinux boxes.
Do you run the acme-dns server within your private WireGuard network? or via a public Vultr/Linode VM? If the latter, I would firewall access to the clients as close as possible.
My only concern is the acme-dns Github project [2] has been 2 years since its last release with 70 open issues and 20 PR's waiting. A new acme-dns release with an update of the bundled Go library would be nice since acme-dns is a network server.
Lonnie
> On Sep 18, 2021, at 12:55 AM, Michael Knill <mic...@ip...> wrote:
>
> Hi Devs
>
> We have acme-dns working in our next release. Seems pretty good so far and will be a far more secure and easy to manage option.
> Once I have done some real world testing would you like us to write it up?
>
> Regards
> Michael Knill
>
> On 15/8/21, 1:52 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Hey Michael,
>
> Looking forward to hearing how acme-dns works for you. AstLinux's acme-client (acme.sh) has a plugin for acme-dns, usage: --dns dns_acmedns
>
> The acme-dns author "Joona Hoikkala" wrote an EFF article [1] "Securing the Automation of ACME DNS Challenge Validation"
>
> BTW, I would use the acme-dns Github page [2] for info rather then the nethserver wiki article you referenced.
>
> Lonnie
>
> [1] https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation
>
> [2] https://github.com/joohoi/acme-dns/
>
>
>
>> On Aug 13, 2021, at 10:33 PM, Michael Knill <mic...@ip...> wrote:
>>
>> Actually decided that I will give acme-dns a try: https://wiki.nethserver.org/doku.php?id=userguide:let_s_encrypt_acme-dns
>> Will report how I go.
>>
>> Regards
>> Michael Knill
>>
>> From: Michael Knill <mic...@ip...>
>> Reply to: AstLinux List <ast...@li...>
>> Date: Saturday, 14 August 2021 at 12:29 pm
>> To: AstLinux List <ast...@li...>
>> Subject: [Astlinux-users] Securing DNS API Keys when using ACME
>>
>> Hi Group
>>
>> I'm looking to move away from Wildcard SSL and move back to ACME Lets Encrypt to ensure a unique cert for all our systems. The reason is that we have built our new Mobile Softphone solution which is heavily reliant heavily on TLS for provisioning and SIP.
>>
>> As such, I want to set this up but I am concerned that if one of our systems was compromised (we have quite a few now), this will allow an attacker to do bad stuff to our DNS (currently GoDaddy). I understand that some DNS providers may be able to restrict what you can do with the API but just wondering if anyone has any better ideas?
>>
>> Regards
>>
>> Michael Knill
>> Managing Director
>>
>> D: +61 2 6189 1360
>> P: +61 2 6140 4656
>> E: mic...@ip...
>> W: ipcsolutions.com.au
>>
>> <image001.png>
>> Smarter Business Communications
>>
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
> _______________________________________________
> 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...> - 2021-09-18 14:19:39
|
Hi Michael, Documenting would be great. This could be universally useful to anyone with a constellation of AstLinux boxes. Do you run the acme-dns server within your private WireGuard network? or via a public Vultr/Linode VM? If the latter, I would firewall access to the clients as close as possible. My only concern is the acme-dns Github project [2] has been 2 years since its last release with 70 open issues and 20 PR's waiting. A new acme-dns release with an update of the bundled Go library would be nice since acme-dns is a network server. Lonnie > On Sep 18, 2021, at 12:55 AM, Michael Knill <mic...@ip...> wrote: > > Hi Devs > > We have acme-dns working in our next release. Seems pretty good so far and will be a far more secure and easy to manage option. > Once I have done some real world testing would you like us to write it up? > > Regards > Michael Knill > > On 15/8/21, 1:52 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > Hey Michael, > > Looking forward to hearing how acme-dns works for you. AstLinux's acme-client (acme.sh) has a plugin for acme-dns, usage: --dns dns_acmedns > > The acme-dns author "Joona Hoikkala" wrote an EFF article [1] "Securing the Automation of ACME DNS Challenge Validation" > > BTW, I would use the acme-dns Github page [2] for info rather then the nethserver wiki article you referenced. > > Lonnie > > [1] https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation > > [2] https://github.com/joohoi/acme-dns/ > > > >> On Aug 13, 2021, at 10:33 PM, Michael Knill <mic...@ip...> wrote: >> >> Actually decided that I will give acme-dns a try: https://wiki.nethserver.org/doku.php?id=userguide:let_s_encrypt_acme-dns >> Will report how I go. >> >> Regards >> Michael Knill >> >> From: Michael Knill <mic...@ip...> >> Reply to: AstLinux List <ast...@li...> >> Date: Saturday, 14 August 2021 at 12:29 pm >> To: AstLinux List <ast...@li...> >> Subject: [Astlinux-users] Securing DNS API Keys when using ACME >> >> Hi Group >> >> I'm looking to move away from Wildcard SSL and move back to ACME Lets Encrypt to ensure a unique cert for all our systems. The reason is that we have built our new Mobile Softphone solution which is heavily reliant heavily on TLS for provisioning and SIP. >> >> As such, I want to set this up but I am concerned that if one of our systems was compromised (we have quite a few now), this will allow an attacker to do bad stuff to our DNS (currently GoDaddy). I understand that some DNS providers may be able to restrict what you can do with the API but just wondering if anyone has any better ideas? >> >> Regards >> >> Michael Knill >> Managing Director >> >> D: +61 2 6189 1360 >> P: +61 2 6140 4656 >> E: mic...@ip... >> W: ipcsolutions.com.au >> >> <image001.png> >> Smarter Business Communications >> >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2021-09-18 05:55:28
|
Hi Devs
We have acme-dns working in our next release. Seems pretty good so far and will be a far more secure and easy to manage option.
Once I have done some real world testing would you like us to write it up?
Regards
Michael Knill
On 15/8/21, 1:52 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Hey Michael,
Looking forward to hearing how acme-dns works for you. AstLinux's acme-client (acme.sh) has a plugin for acme-dns, usage: --dns dns_acmedns
The acme-dns author "Joona Hoikkala" wrote an EFF article [1] "Securing the Automation of ACME DNS Challenge Validation"
BTW, I would use the acme-dns Github page [2] for info rather then the nethserver wiki article you referenced.
Lonnie
[1] https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation
[2] https://github.com/joohoi/acme-dns/
> On Aug 13, 2021, at 10:33 PM, Michael Knill <mic...@ip...> wrote:
>
> Actually decided that I will give acme-dns a try: https://wiki.nethserver.org/doku.php?id=userguide:let_s_encrypt_acme-dns
> Will report how I go.
>
> Regards
> Michael Knill
>
> From: Michael Knill <mic...@ip...>
> Reply to: AstLinux List <ast...@li...>
> Date: Saturday, 14 August 2021 at 12:29 pm
> To: AstLinux List <ast...@li...>
> Subject: [Astlinux-users] Securing DNS API Keys when using ACME
>
> Hi Group
>
> I'm looking to move away from Wildcard SSL and move back to ACME Lets Encrypt to ensure a unique cert for all our systems. The reason is that we have built our new Mobile Softphone solution which is heavily reliant heavily on TLS for provisioning and SIP.
>
> As such, I want to set this up but I am concerned that if one of our systems was compromised (we have quite a few now), this will allow an attacker to do bad stuff to our DNS (currently GoDaddy). I understand that some DNS providers may be able to restrict what you can do with the API but just wondering if anyone has any better ideas?
>
> Regards
>
> Michael Knill
> Managing Director
>
> D: +61 2 6189 1360
> P: +61 2 6140 4656
> E: mic...@ip...
> W: ipcsolutions.com.au
>
> <image001.png>
> Smarter Business Communications
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2021-08-14 16:03:32
|
Announcing AstLinux Pre-Release: astlinux-1.4-5218-214c68
Key new features:
-- 2.5G ethernet support for Intel i225 (igc) and Realtek RTL8125 (r8125) NICs
-- '13se' version now uses Asterisk 13.38.3, "Security Fixes Only" version for Asterisk 13
** 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.200 (version bump), security and bug fixes
-- ixgbe, enable the Intel 10-Gigabit Ethernet Network Driver
-- igc, backport from linux-5.4.136, Intel i225 2.5-Gigabit Ethernet Network Driver
-- r8125, version 9.005.06, Realtek RTL8125 2.5-Gigabit Ethernet Network Driver
-- libcurl (curl) version bump to 7.78.0, several security fixes
-- prosody, version bump to 0.11.10, security fix: CVE-2021-37601
-- acme-client, version bump to 2.9.0
-- Monit, version bump to 5.28.1
-- Asterisk 13.38.3 ('13se' version bump)
Latest Asterisk 13.x "Security Fixes Only" version, built --without-pjproject
-- Asterisk 13.38.3 (version bump) and 16.20.0 (version bump)
New Asterisk 16 applications: WaitForCondition, Reload, StoreDTMF
-- 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...> - 2021-07-13 12:40:34
|
Announcing AstLinux Release: 1.4.3 More Info: AstLinux Project https://www.astlinux-project.org/ AstLinux 1.4.3 Highlights: * Asterisk Versions: 13.29.2, 13.38.2, 16.19.0 * Linux Kernel 4.19.196, security and bug fixes * RUNNIX, version bump to runnix-0.6.4 * OpenSSL, version bump to 1.1.1k, security fixes * OpenVPN, version bump to 2.4.11 * WireGuard VPN, module 1.0.20210606 (version bump), tools 1.0.20210424 (version bump) * libcurl (curl) version bump to 7.77.0 * libxml2, version bump to 2.9.12 * LibreTLS, new package, version 3.3.3p1, a port of libtls from LibreSSL to OpenSSL * chrony, version bump to 4.1 * Monit, version bump to 5.28.0 * msmtp, version bump to 1.8.15, switch TLS support to libtls (LibreTLS via OpenSSL) * prosody, major version bump to 0.11.9 * vnStat, version bump to 2.7 * zabbix, version bump to 4.0.31 * phoneprov-tools, add support for `@CID_NUM@` and `@CID_NUM1@` to `@CID_NUM6@` template variables. * Package upgrades providing important security and bug fixes Full ChangeLog: https://raw.githubusercontent.com/astlinux-project/astlinux/1.4.3/docs/ChangeLog.txt All users are encouraged to upgrade, read the ChangeLog for the details. AstLinux Team |
|
From: Lonnie A. <li...@lo...> - 2021-07-02 16:41:34
|
Announcing AstLinux Pre-Release: astlinux-1.4-5177-b91b86
Release Candidate1 pre-1.4.3, please report any issues, ASAP.
** 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.196 (version bump), security and bug fixes. Reverts many @umn.edu unsuitable commits.
-- initrd, check for ASTURW /etc/inittab and copy it forward so the linuxrc's /sbin/init can use it.
Note: AstLinux 1.3.10 through 1.4.2 ignored any user edits to the /etc/inittab file, rather
it always used the default /etc/inittab file (the default is what most users want anyway).
Now edits to the /etc/inittab file are honored again, as they were before AstLinux 1.3.10.
-- RUNNIX, version bump to runnix-0.6.4, with Linux Kernel 4.19.196, e2fsprogs 1.46.2
-- OpenSSL, version bump to 1.1.1k, security fixes: CVE-2021-3449, CVE-2021-3450
-- WireGuard VPN, module 1.0.20210606 (version bump), tools 1.0.20210424 (version bump)
-- OpenVPN, version bump to 2.4.11, security fix: CVE-2020-15078
-- libcurl (curl) version bump to 7.77.0, security fixes: CVE-2021-22876, CVE-2021-22890, CVE-2021-22897,
CVE-2021-22898, CVE-2021-22901
-- libxml2, version bump to 2.9.12, security fix: CVE-2021-3541, plus "an awful lot of serious bug fixes"
-- LibreTLS, new package, version 3.3.3p1, a port of libtls from LibreSSL to OpenSSL
-- chrony, version bump to 4.1
-- Monit, version bump to 5.28.0
-- vnStat, version bump to 2.7
-- prosody, major version bump to 0.11.9
Security fixes: CVE-2021-32917, CVE-2021-32918, CVE-2021-32919, CVE-2021-32920, CVE-2021-32921
-- Asterisk 13.29.2 ('13se' no change)
Older than latest Asterisk 13.x version but more tested, built --without-pjproject
-- Asterisk 13.38.2 (no change) and 16.19.0 (version bump)
-- 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...> - 2021-06-29 12:47:41
|
Hi David, No luck needed :-) Be sure to reboot after your KCMD edits, then "dosfsck -a /dev/sda1" your vfat partition again, and reboot again if anything was repaired. Lonnie > On Jun 29, 2021, at 7:38 AM, David Kerr <da...@ke...> wrote: > > Thanks Lonnie. I have updated my KCMD entries, with luck I won't run into this again. > > Thanks for your help. > > David > > On Mon, Jun 28, 2021 at 11:24 PM Lonnie Abelbeck <li...@lo...> wrote: > David, > > That explains what you are seeing. > > The 'noram' would be in the /oldroot/cdrom/os/*run.conf file(s) KCMD string. > > # grep '^KCMD' /oldroot/cdrom/os/*run.conf > > You need to mount /oldroot/cdrom read-write and remove the 'noram' option from those file(s). > > This 'noram' option had to be manually defined at some point, but every upgrade from then on would copy forward 'noram' if it existed. > > FYI, When 'noram' is set the run image is mounted via a loop device directly from the vfat partition. Normally the run image is copied to a tmpfs device from the vfat partition. > > Interestingly, with 'noram' set, if you did a "revert to previous" and *then a reboot* and then "upgrade with new" after the reboot it would work without messing-up the vfat partition since the loop device's filesystem would not be removed in the upgrade process. > > Lonnie > > > > > > On Jun 28, 2021, at 9:33 PM, David Kerr <da...@ke...> wrote: > > > > Lonnie, > > "noram" is indeed set on my test system, but not on my production. I am not conscious of having set this and I have 2GB ram assigned. But it is possible that when I first installed I had much less and then increased it later. Where is that parameter set? > > > > pbx-test ~ # cat /proc/cmdline > > root=/dev/ram0 rw init=/linuxrc astlinux=genx86_64-vm astimg=astlinux-1.4-bdb746.run astkd=auto asturw=auto astlive noram libata.dma=3 > > pbx-test ~ # > > > > Thanks > > David > > > > On Mon, Jun 28, 2021 at 7:04 PM Lonnie Abelbeck <li...@lo...> wrote: > > David, > > > > > What I am doing is "revert to previous" followed immediately by "upgrade with new" and a reboot. > > > > That is what I always do. > > > > If for some reason "noram" gets added to "cat /proc/cmdline" then that could explain what you are seeing. > > > > But usually "noram" is only for very tight RAM situations. Unless you added it manually. > > > > Lonnie > > > > > > > > > On Jun 28, 2021, at 5:49 PM, David Kerr <da...@ke...> wrote: > > > > > > I don't know what's going on booting into shell... I have the version that requires typing "shell". I just tried again and it failed so I'll need to investigate further. > > > > > > On the dirty disk problem, it occurred again. What I am doing is "revert to previous" followed immediately by "upgrade with new" and a reboot. After doing this three times I get the error. And there are three .REC files on the disk (after fsck repair). All this because, btw, /usr/sbin is no longer in unionfs so I have to make tweaks to file I am editing offline, then make a new image, upgrade, etc. > > > > > > David > > > > > > On Mon, Jun 28, 2021 at 6:36 PM Lonnie Abelbeck <li...@lo...> wrote: > > > Hi David, > > > > > > Great you got things going again. > > > > > > > Worse, it looks like I cannot boot into "shell" from initial boot, whatever I select it just boots the main system. > > > > > > I just tested both a VMware Fusion VM and Proxmox VM and both were able to boot into "shell". Both had the latest runnix-0.6.3, though one had the old syslinux 3.x and the other had the newer syslinux 6.x ... on one I typed "shell" the other I arrowed down to "shell". Both worked for me. > > > > > > Being a VM gives you a lot of repair/recovery options. > > > > > > Lonnie > > > > > > > > > > > > > On Jun 28, 2021, at 3:44 PM, David Kerr <Da...@Ke...> wrote: > > > > > > > > Answering my own question... thanks to the magic of VMware I was able to attach my test vmdk image to another running astlinux VM and inside that run fsck.fat -a /dev/sdb1 (where it was attached) and that cleaned up the "dirty bit". Then I could delete 150MB of "recovered" files and now I am back in business. > > > > > > > > David > > > > > > > > On Mon, Jun 28, 2021 at 4:08 PM David Kerr <da...@ke...> wrote: > > > > One of my test systems has got into a state where I cannot upgrade the firmware anymore... "Not enough free space for new firmware on the RUNNIX partition." I have tried everything I can think of to fix it. I'm having problems unmounting /dev/sda1 (device is busy) so have not been able to run fsck on it. Worse, it looks like I cannot boot into "shell" from initial boot, whatever I select it just boots the main system. > > > > > > > > I may just have to rebuild my test system (not a huge issue, it is afterall just a VM test system), but any suggestions on how to fix this? > > > > > > > > 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 > > _______________________________________________ > > 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...> - 2021-06-29 12:38:45
|
Thanks Lonnie. I have updated my KCMD entries, with luck I won't run into this again. Thanks for your help. David On Mon, Jun 28, 2021 at 11:24 PM Lonnie Abelbeck <li...@lo...> wrote: > David, > > That explains what you are seeing. > > The 'noram' would be in the /oldroot/cdrom/os/*run.conf file(s) KCMD > string. > > # grep '^KCMD' /oldroot/cdrom/os/*run.conf > > You need to mount /oldroot/cdrom read-write and remove the 'noram' option > from those file(s). > > This 'noram' option had to be manually defined at some point, but every > upgrade from then on would copy forward 'noram' if it existed. > > FYI, When 'noram' is set the run image is mounted via a loop device > directly from the vfat partition. Normally the run image is copied to a > tmpfs device from the vfat partition. > > Interestingly, with 'noram' set, if you did a "revert to previous" and > *then a reboot* and then "upgrade with new" after the reboot it would work > without messing-up the vfat partition since the loop device's filesystem > would not be removed in the upgrade process. > > Lonnie > > > > > > On Jun 28, 2021, at 9:33 PM, David Kerr <da...@ke...> wrote: > > > > Lonnie, > > "noram" is indeed set on my test system, but not on my production. I > am not conscious of having set this and I have 2GB ram assigned. But it is > possible that when I first installed I had much less and then increased it > later. Where is that parameter set? > > > > pbx-test ~ # cat /proc/cmdline > > root=/dev/ram0 rw init=/linuxrc astlinux=genx86_64-vm > astimg=astlinux-1.4-bdb746.run astkd=auto asturw=auto astlive noram > libata.dma=3 > > pbx-test ~ # > > > > Thanks > > David > > > > On Mon, Jun 28, 2021 at 7:04 PM Lonnie Abelbeck < > li...@lo...> wrote: > > David, > > > > > What I am doing is "revert to previous" followed immediately by > "upgrade with new" and a reboot. > > > > That is what I always do. > > > > If for some reason "noram" gets added to "cat /proc/cmdline" then that > could explain what you are seeing. > > > > But usually "noram" is only for very tight RAM situations. Unless you > added it manually. > > > > Lonnie > > > > > > > > > On Jun 28, 2021, at 5:49 PM, David Kerr <da...@ke...> wrote: > > > > > > I don't know what's going on booting into shell... I have the version > that requires typing "shell". I just tried again and it failed so I'll > need to investigate further. > > > > > > On the dirty disk problem, it occurred again. What I am doing is > "revert to previous" followed immediately by "upgrade with new" and a > reboot. After doing this three times I get the error. And there are three > .REC files on the disk (after fsck repair). All this because, btw, > /usr/sbin is no longer in unionfs so I have to make tweaks to file I am > editing offline, then make a new image, upgrade, etc. > > > > > > David > > > > > > On Mon, Jun 28, 2021 at 6:36 PM Lonnie Abelbeck < > li...@lo...> wrote: > > > Hi David, > > > > > > Great you got things going again. > > > > > > > Worse, it looks like I cannot boot into "shell" from initial boot, > whatever I select it just boots the main system. > > > > > > I just tested both a VMware Fusion VM and Proxmox VM and both were > able to boot into "shell". Both had the latest runnix-0.6.3, though one > had the old syslinux 3.x and the other had the newer syslinux 6.x ... on > one I typed "shell" the other I arrowed down to "shell". Both worked for > me. > > > > > > Being a VM gives you a lot of repair/recovery options. > > > > > > Lonnie > > > > > > > > > > > > > On Jun 28, 2021, at 3:44 PM, David Kerr <Da...@Ke...> wrote: > > > > > > > > Answering my own question... thanks to the magic of VMware I was > able to attach my test vmdk image to another running astlinux VM and inside > that run fsck.fat -a /dev/sdb1 (where it was attached) and that cleaned up > the "dirty bit". Then I could delete 150MB of "recovered" files and now I > am back in business. > > > > > > > > David > > > > > > > > On Mon, Jun 28, 2021 at 4:08 PM David Kerr <da...@ke...> wrote: > > > > One of my test systems has got into a state where I cannot upgrade > the firmware anymore... "Not enough free space for new firmware on the > RUNNIX partition." I have tried everything I can think of to fix it. I'm > having problems unmounting /dev/sda1 (device is busy) so have not been able > to run fsck on it. Worse, it looks like I cannot boot into "shell" from > initial boot, whatever I select it just boots the main system. > > > > > > > > I may just have to rebuild my test system (not a huge issue, it is > afterall just a VM test system), but any suggestions on how to fix this? > > > > > > > > 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 > > _______________________________________________ > > 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. <li...@mk...> - 2021-06-29 07:58:36
|
I also have "noram" on my test box but not on my router. > Am 29.06.2021 um 04:33 schrieb David Kerr <da...@ke...>: > > Lonnie, > "noram" is indeed set on my test system, but not on my production. I am not conscious of having set this and I have 2GB ram assigned. But it is possible that when I first installed I had much less and then increased it later. Where is that parameter set? > > pbx-test ~ # cat /proc/cmdline > root=/dev/ram0 rw init=/linuxrc astlinux=genx86_64-vm astimg=astlinux-1.4-bdb746.run astkd=auto asturw=auto astlive noram libata.dma=3 > pbx-test ~ # > > Thanks > David > > On Mon, Jun 28, 2021 at 7:04 PM Lonnie Abelbeck <li...@lo...> wrote: > David, > > > What I am doing is "revert to previous" followed immediately by "upgrade with new" and a reboot. > > That is what I always do. > > If for some reason "noram" gets added to "cat /proc/cmdline" then that could explain what you are seeing. > > But usually "noram" is only for very tight RAM situations. Unless you added it manually. > > Lonnie > > > > > On Jun 28, 2021, at 5:49 PM, David Kerr <da...@ke...> wrote: > > > > I don't know what's going on booting into shell... I have the version that requires typing "shell". I just tried again and it failed so I'll need to investigate further. > > > > On the dirty disk problem, it occurred again. What I am doing is "revert to previous" followed immediately by "upgrade with new" and a reboot. After doing this three times I get the error. And there are three .REC files on the disk (after fsck repair). All this because, btw, /usr/sbin is no longer in unionfs so I have to make tweaks to file I am editing offline, then make a new image, upgrade, etc. > > > > David > > > > On Mon, Jun 28, 2021 at 6:36 PM Lonnie Abelbeck <li...@lo...> wrote: > > Hi David, > > > > Great you got things going again. > > > > > Worse, it looks like I cannot boot into "shell" from initial boot, whatever I select it just boots the main system. > > > > I just tested both a VMware Fusion VM and Proxmox VM and both were able to boot into "shell". Both had the latest runnix-0.6.3, though one had the old syslinux 3.x and the other had the newer syslinux 6.x ... on one I typed "shell" the other I arrowed down to "shell". Both worked for me. > > > > Being a VM gives you a lot of repair/recovery options. > > > > Lonnie > > > > > > > > > On Jun 28, 2021, at 3:44 PM, David Kerr <Da...@Ke...> wrote: > > > > > > Answering my own question... thanks to the magic of VMware I was able to attach my test vmdk image to another running astlinux VM and inside that run fsck.fat -a /dev/sdb1 (where it was attached) and that cleaned up the "dirty bit". Then I could delete 150MB of "recovered" files and now I am back in business. > > > > > > David > > > > > > On Mon, Jun 28, 2021 at 4:08 PM David Kerr <da...@ke...> wrote: > > > One of my test systems has got into a state where I cannot upgrade the firmware anymore... "Not enough free space for new firmware on the RUNNIX partition." I have tried everything I can think of to fix it. I'm having problems unmounting /dev/sda1 (device is busy) so have not been able to run fsck on it. Worse, it looks like I cannot boot into "shell" from initial boot, whatever I select it just boots the main system. > > > > > > I may just have to rebuild my test system (not a huge issue, it is afterall just a VM test system), but any suggestions on how to fix this? > > > > > > 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 > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel Michael http://www.mksolutions.info |
|
From: Michael K. <li...@mk...> - 2021-06-29 07:55:46
|
> Am 29.06.2021 um 00:49 schrieb David Kerr <da...@ke...>: > > I don't know what's going on booting into shell... I have the version that requires typing "shell". I just tried again and it failed so I'll need to investigate further. > > On the dirty disk problem, it occurred again. What I am doing is "revert to previous" followed immediately by "upgrade with new" and a reboot. After doing this three times I get the error. And there are three .REC files on the disk (after fsck repair). All this because, btw, /usr/sbin is no longer in unionfs so I have to make tweaks to file I am editing offline, then make a new image, upgrade, etc. > > David Hi David, I have sometimes the same problem with upgrades on my main test box. I cannot say every 3 times, but for for sure one out of ten times. I usally do dosfsck -a /dev/sda and delete the *.rec files afterwards. Since mine is a physical box, I thought my mSATA has a problem. Good to know I am not alone :-). > On Mon, Jun 28, 2021 at 6:36 PM Lonnie Abelbeck <li...@lo...> wrote: > Hi David, > > Great you got things going again. > > > Worse, it looks like I cannot boot into "shell" from initial boot, whatever I select it just boots the main system. > > I just tested both a VMware Fusion VM and Proxmox VM and both were able to boot into "shell". Both had the latest runnix-0.6.3, though one had the old syslinux 3.x and the other had the newer syslinux 6.x ... on one I typed "shell" the other I arrowed down to "shell". Both worked for me. > > Being a VM gives you a lot of repair/recovery options. > > Lonnie > > > > > On Jun 28, 2021, at 3:44 PM, David Kerr <Da...@Ke...> wrote: > > > > Answering my own question... thanks to the magic of VMware I was able to attach my test vmdk image to another running astlinux VM and inside that run fsck.fat -a /dev/sdb1 (where it was attached) and that cleaned up the "dirty bit". Then I could delete 150MB of "recovered" files and now I am back in business. > > > > David > > > > On Mon, Jun 28, 2021 at 4:08 PM David Kerr <da...@ke...> wrote: > > One of my test systems has got into a state where I cannot upgrade the firmware anymore... "Not enough free space for new firmware on the RUNNIX partition." I have tried everything I can think of to fix it. I'm having problems unmounting /dev/sda1 (device is busy) so have not been able to run fsck on it. Worse, it looks like I cannot boot into "shell" from initial boot, whatever I select it just boots the main system. > > > > I may just have to rebuild my test system (not a huge issue, it is afterall just a VM test system), but any suggestions on how to fix this? > > > > Thanks, > > David Michael http://www.mksolutions.info |
|
From: Lonnie A. <li...@lo...> - 2021-06-29 03:24:25
|
David, That explains what you are seeing. The 'noram' would be in the /oldroot/cdrom/os/*run.conf file(s) KCMD string. # grep '^KCMD' /oldroot/cdrom/os/*run.conf You need to mount /oldroot/cdrom read-write and remove the 'noram' option from those file(s). This 'noram' option had to be manually defined at some point, but every upgrade from then on would copy forward 'noram' if it existed. FYI, When 'noram' is set the run image is mounted via a loop device directly from the vfat partition. Normally the run image is copied to a tmpfs device from the vfat partition. Interestingly, with 'noram' set, if you did a "revert to previous" and *then a reboot* and then "upgrade with new" after the reboot it would work without messing-up the vfat partition since the loop device's filesystem would not be removed in the upgrade process. Lonnie > On Jun 28, 2021, at 9:33 PM, David Kerr <da...@ke...> wrote: > > Lonnie, > "noram" is indeed set on my test system, but not on my production. I am not conscious of having set this and I have 2GB ram assigned. But it is possible that when I first installed I had much less and then increased it later. Where is that parameter set? > > pbx-test ~ # cat /proc/cmdline > root=/dev/ram0 rw init=/linuxrc astlinux=genx86_64-vm astimg=astlinux-1.4-bdb746.run astkd=auto asturw=auto astlive noram libata.dma=3 > pbx-test ~ # > > Thanks > David > > On Mon, Jun 28, 2021 at 7:04 PM Lonnie Abelbeck <li...@lo...> wrote: > David, > > > What I am doing is "revert to previous" followed immediately by "upgrade with new" and a reboot. > > That is what I always do. > > If for some reason "noram" gets added to "cat /proc/cmdline" then that could explain what you are seeing. > > But usually "noram" is only for very tight RAM situations. Unless you added it manually. > > Lonnie > > > > > On Jun 28, 2021, at 5:49 PM, David Kerr <da...@ke...> wrote: > > > > I don't know what's going on booting into shell... I have the version that requires typing "shell". I just tried again and it failed so I'll need to investigate further. > > > > On the dirty disk problem, it occurred again. What I am doing is "revert to previous" followed immediately by "upgrade with new" and a reboot. After doing this three times I get the error. And there are three .REC files on the disk (after fsck repair). All this because, btw, /usr/sbin is no longer in unionfs so I have to make tweaks to file I am editing offline, then make a new image, upgrade, etc. > > > > David > > > > On Mon, Jun 28, 2021 at 6:36 PM Lonnie Abelbeck <li...@lo...> wrote: > > Hi David, > > > > Great you got things going again. > > > > > Worse, it looks like I cannot boot into "shell" from initial boot, whatever I select it just boots the main system. > > > > I just tested both a VMware Fusion VM and Proxmox VM and both were able to boot into "shell". Both had the latest runnix-0.6.3, though one had the old syslinux 3.x and the other had the newer syslinux 6.x ... on one I typed "shell" the other I arrowed down to "shell". Both worked for me. > > > > Being a VM gives you a lot of repair/recovery options. > > > > Lonnie > > > > > > > > > On Jun 28, 2021, at 3:44 PM, David Kerr <Da...@Ke...> wrote: > > > > > > Answering my own question... thanks to the magic of VMware I was able to attach my test vmdk image to another running astlinux VM and inside that run fsck.fat -a /dev/sdb1 (where it was attached) and that cleaned up the "dirty bit". Then I could delete 150MB of "recovered" files and now I am back in business. > > > > > > David > > > > > > On Mon, Jun 28, 2021 at 4:08 PM David Kerr <da...@ke...> wrote: > > > One of my test systems has got into a state where I cannot upgrade the firmware anymore... "Not enough free space for new firmware on the RUNNIX partition." I have tried everything I can think of to fix it. I'm having problems unmounting /dev/sda1 (device is busy) so have not been able to run fsck on it. Worse, it looks like I cannot boot into "shell" from initial boot, whatever I select it just boots the main system. > > > > > > I may just have to rebuild my test system (not a huge issue, it is afterall just a VM test system), but any suggestions on how to fix this? > > > > > > 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 > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: David K. <da...@ke...> - 2021-06-29 02:33:55
|
Lonnie, "noram" is indeed set on my test system, but not on my production. I am not conscious of having set this and I have 2GB ram assigned. But it is possible that when I first installed I had much less and then increased it later. Where is that parameter set? pbx-test ~ # cat /proc/cmdline root=/dev/ram0 rw init=/linuxrc astlinux=genx86_64-vm astimg=astlinux-1.4-bdb746.run astkd=auto asturw=auto astlive noram libata.dma=3 pbx-test ~ # Thanks David On Mon, Jun 28, 2021 at 7:04 PM Lonnie Abelbeck <li...@lo...> wrote: > David, > > > What I am doing is "revert to previous" followed immediately by "upgrade > with new" and a reboot. > > That is what I always do. > > If for some reason "noram" gets added to "cat /proc/cmdline" then that > could explain what you are seeing. > > But usually "noram" is only for very tight RAM situations. Unless you > added it manually. > > Lonnie > > > > > On Jun 28, 2021, at 5:49 PM, David Kerr <da...@ke...> wrote: > > > > I don't know what's going on booting into shell... I have the version > that requires typing "shell". I just tried again and it failed so I'll > need to investigate further. > > > > On the dirty disk problem, it occurred again. What I am doing is "revert > to previous" followed immediately by "upgrade with new" and a reboot. After > doing this three times I get the error. And there are three .REC files on > the disk (after fsck repair). All this because, btw, /usr/sbin is no > longer in unionfs so I have to make tweaks to file I am editing offline, > then make a new image, upgrade, etc. > > > > David > > > > On Mon, Jun 28, 2021 at 6:36 PM Lonnie Abelbeck < > li...@lo...> wrote: > > Hi David, > > > > Great you got things going again. > > > > > Worse, it looks like I cannot boot into "shell" from initial boot, > whatever I select it just boots the main system. > > > > I just tested both a VMware Fusion VM and Proxmox VM and both were able > to boot into "shell". Both had the latest runnix-0.6.3, though one had the > old syslinux 3.x and the other had the newer syslinux 6.x ... on one I > typed "shell" the other I arrowed down to "shell". Both worked for me. > > > > Being a VM gives you a lot of repair/recovery options. > > > > Lonnie > > > > > > > > > On Jun 28, 2021, at 3:44 PM, David Kerr <Da...@Ke...> wrote: > > > > > > Answering my own question... thanks to the magic of VMware I was able > to attach my test vmdk image to another running astlinux VM and inside that > run fsck.fat -a /dev/sdb1 (where it was attached) and that cleaned up the > "dirty bit". Then I could delete 150MB of "recovered" files and now I am > back in business. > > > > > > David > > > > > > On Mon, Jun 28, 2021 at 4:08 PM David Kerr <da...@ke...> wrote: > > > One of my test systems has got into a state where I cannot upgrade the > firmware anymore... "Not enough free space for new firmware on the RUNNIX > partition." I have tried everything I can think of to fix it. I'm having > problems unmounting /dev/sda1 (device is busy) so have not been able to run > fsck on it. Worse, it looks like I cannot boot into "shell" from initial > boot, whatever I select it just boots the main system. > > > > > > I may just have to rebuild my test system (not a huge issue, it is > afterall just a VM test system), but any suggestions on how to fix this? > > > > > > 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...> - 2021-06-28 23:03:58
|
David, > What I am doing is "revert to previous" followed immediately by "upgrade with new" and a reboot. That is what I always do. If for some reason "noram" gets added to "cat /proc/cmdline" then that could explain what you are seeing. But usually "noram" is only for very tight RAM situations. Unless you added it manually. Lonnie > On Jun 28, 2021, at 5:49 PM, David Kerr <da...@ke...> wrote: > > I don't know what's going on booting into shell... I have the version that requires typing "shell". I just tried again and it failed so I'll need to investigate further. > > On the dirty disk problem, it occurred again. What I am doing is "revert to previous" followed immediately by "upgrade with new" and a reboot. After doing this three times I get the error. And there are three .REC files on the disk (after fsck repair). All this because, btw, /usr/sbin is no longer in unionfs so I have to make tweaks to file I am editing offline, then make a new image, upgrade, etc. > > David > > On Mon, Jun 28, 2021 at 6:36 PM Lonnie Abelbeck <li...@lo...> wrote: > Hi David, > > Great you got things going again. > > > Worse, it looks like I cannot boot into "shell" from initial boot, whatever I select it just boots the main system. > > I just tested both a VMware Fusion VM and Proxmox VM and both were able to boot into "shell". Both had the latest runnix-0.6.3, though one had the old syslinux 3.x and the other had the newer syslinux 6.x ... on one I typed "shell" the other I arrowed down to "shell". Both worked for me. > > Being a VM gives you a lot of repair/recovery options. > > Lonnie > > > > > On Jun 28, 2021, at 3:44 PM, David Kerr <Da...@Ke...> wrote: > > > > Answering my own question... thanks to the magic of VMware I was able to attach my test vmdk image to another running astlinux VM and inside that run fsck.fat -a /dev/sdb1 (where it was attached) and that cleaned up the "dirty bit". Then I could delete 150MB of "recovered" files and now I am back in business. > > > > David > > > > On Mon, Jun 28, 2021 at 4:08 PM David Kerr <da...@ke...> wrote: > > One of my test systems has got into a state where I cannot upgrade the firmware anymore... "Not enough free space for new firmware on the RUNNIX partition." I have tried everything I can think of to fix it. I'm having problems unmounting /dev/sda1 (device is busy) so have not been able to run fsck on it. Worse, it looks like I cannot boot into "shell" from initial boot, whatever I select it just boots the main system. > > > > I may just have to rebuild my test system (not a huge issue, it is afterall just a VM test system), but any suggestions on how to fix this? > > > > 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...> - 2021-06-28 22:50:13
|
I don't know what's going on booting into shell... I have the version that requires typing "shell". I just tried again and it failed so I'll need to investigate further. On the dirty disk problem, it occurred again. What I am doing is "revert to previous" followed immediately by "upgrade with new" and a reboot. After doing this three times I get the error. And there are three .REC files on the disk (after fsck repair). All this because, btw, /usr/sbin is no longer in unionfs so I have to make tweaks to file I am editing offline, then make a new image, upgrade, etc. David On Mon, Jun 28, 2021 at 6:36 PM Lonnie Abelbeck <li...@lo...> wrote: > Hi David, > > Great you got things going again. > > > Worse, it looks like I cannot boot into "shell" from initial boot, > whatever I select it just boots the main system. > > I just tested both a VMware Fusion VM and Proxmox VM and both were able to > boot into "shell". Both had the latest runnix-0.6.3, though one had the > old syslinux 3.x and the other had the newer syslinux 6.x ... on one I > typed "shell" the other I arrowed down to "shell". Both worked for me. > > Being a VM gives you a lot of repair/recovery options. > > Lonnie > > > > > On Jun 28, 2021, at 3:44 PM, David Kerr <Da...@Ke...> wrote: > > > > Answering my own question... thanks to the magic of VMware I was able to > attach my test vmdk image to another running astlinux VM and inside that > run fsck.fat -a /dev/sdb1 (where it was attached) and that cleaned up the > "dirty bit". Then I could delete 150MB of "recovered" files and now I am > back in business. > > > > David > > > > On Mon, Jun 28, 2021 at 4:08 PM David Kerr <da...@ke...> wrote: > > One of my test systems has got into a state where I cannot upgrade the > firmware anymore... "Not enough free space for new firmware on the RUNNIX > partition." I have tried everything I can think of to fix it. I'm having > problems unmounting /dev/sda1 (device is busy) so have not been able to run > fsck on it. Worse, it looks like I cannot boot into "shell" from initial > boot, whatever I select it just boots the main system. > > > > I may just have to rebuild my test system (not a huge issue, it is > afterall just a VM test system), but any suggestions on how to fix this? > > > > 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...> - 2021-06-28 22:36:32
|
Hi David, Great you got things going again. > Worse, it looks like I cannot boot into "shell" from initial boot, whatever I select it just boots the main system. I just tested both a VMware Fusion VM and Proxmox VM and both were able to boot into "shell". Both had the latest runnix-0.6.3, though one had the old syslinux 3.x and the other had the newer syslinux 6.x ... on one I typed "shell" the other I arrowed down to "shell". Both worked for me. Being a VM gives you a lot of repair/recovery options. Lonnie > On Jun 28, 2021, at 3:44 PM, David Kerr <Da...@Ke...> wrote: > > Answering my own question... thanks to the magic of VMware I was able to attach my test vmdk image to another running astlinux VM and inside that run fsck.fat -a /dev/sdb1 (where it was attached) and that cleaned up the "dirty bit". Then I could delete 150MB of "recovered" files and now I am back in business. > > David > > On Mon, Jun 28, 2021 at 4:08 PM David Kerr <da...@ke...> wrote: > One of my test systems has got into a state where I cannot upgrade the firmware anymore... "Not enough free space for new firmware on the RUNNIX partition." I have tried everything I can think of to fix it. I'm having problems unmounting /dev/sda1 (device is busy) so have not been able to run fsck on it. Worse, it looks like I cannot boot into "shell" from initial boot, whatever I select it just boots the main system. > > I may just have to rebuild my test system (not a huge issue, it is afterall just a VM test system), but any suggestions on how to fix this? > > Thanks, > David > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: David K. <da...@ke...> - 2021-06-28 21:16:46
|
Answering my own question... thanks to the magic of VMware I was able to attach my test vmdk image to another running astlinux VM and inside that run fsck.fat -a /dev/sdb1 (where it was attached) and that cleaned up the "dirty bit". Then I could delete 150MB of "recovered" files and now I am back in business. David On Mon, Jun 28, 2021 at 4:08 PM David Kerr <da...@ke...> wrote: > One of my test systems has got into a state where I cannot upgrade the > firmware anymore... "Not enough free space for new firmware on the RUNNIX > partition." I have tried everything I can think of to fix it. I'm > having problems unmounting /dev/sda1 (device is busy) so have not been able > to run fsck on it. Worse, it looks like I cannot boot into "shell" from > initial boot, whatever I select it just boots the main system. > > I may just have to rebuild my test system (not a huge issue, it is > afterall just a VM test system), but any suggestions on how to fix this? > > Thanks, > David > |
|
From: David K. <da...@ke...> - 2021-06-28 21:14:46
|
One of my test systems has got into a state where I cannot upgrade the firmware anymore... "Not enough free space for new firmware on the RUNNIX partition." I have tried everything I can think of to fix it. I'm having problems unmounting /dev/sda1 (device is busy) so have not been able to run fsck on it. Worse, it looks like I cannot boot into "shell" from initial boot, whatever I select it just boots the main system. I may just have to rebuild my test system (not a huge issue, it is afterall just a VM test system), but any suggestions on how to fix this? Thanks, David |
|
From: Luigi P. <ope...@gm...> - 2021-05-24 13:51:13
|
Hello Lonnie, Yes, as option B I was thinking about AstLinux <> RPi, thank you. :) Regards, Luigi Il 24/05/2021 15:15, Lonnie Abelbeck ha scritto: > >> On May 24, 2021, at 5:07 AM, Luigi Porto <ope...@gm...> wrote: >> >> Dear Astlinux Devs, >> >> I would like to use my mobile phone number as the IN/OUT SIP trunk. >> As previously written I am currently compiling a 1.3.x for my Alix, everything works fine. >> I am very interested, reading this link: https://www.beppo.it/blog/107-minipbx-mobile (https://translate.google.com/translate?sl=it&tl=en&u=https://www. beppo.it/blog/107-minipbx-mobile) >> In astlinux I noticed that there is chan_mobile.conf, but there are no tools for managing the bluetooth, is it possible to integrate all this? >> Or is there some other way to achieve the goal? > Hi Luigi, > > Many years ago (8+ years) we looked into supporting chan_mobile (and bluetooth), and decided not to support it. > > chan_mobile requires Asterisk to be built with "bluetooth" which is complicated, adding bluez-tools, dbus, libglib2 and some audio packages. While technically possibly, definitely not recommended via an AstLinux custom build. Our old bluez-tools package is not the latest version 5. > > Possibly using a Raspberry Pi for the bluetooth, chan_mobile and SIP trunk via ethernet to your AstLinux box. > > Either way, it seems like a lot of work, and a fragile solution to me. > > Lonnie > > > > > > > > _______________________________________________ > 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.
