astlinux-devel — The AstLinux development environment, compilation, etc

Re: [Astlinux-devel] Can't Add Bind to New Dev Build

[Josh A. <jm...@ho...>]

Hi Lonnie,

My goal here is to be able to do NAPTR lookups since much of my VOIP stuff uses ENUM. Of course I can SSH to another box or use an online dig but I'm lazy so I like to have the ability to do NAPTR lookups wherever I find myself logged in.

You mentioned 'host' and I never checked to see whether it was capable of doing NAPTR lookups. It turns out that it can. So, rather than use dig or even unbound-host, I think I will just use host on my Astlinux machines when I find myself in need of a NAPTR lookup. No extra software needed!

Thanks again for your feedback. I never knew about unbound so it's good to know that it exists. I also wasn't aware of the LXC container functionality in Astlinux - that could be useful at some point! I've been using Astlinux for perhaps 8 years at this point and I am happy that it still seems to be going strong.

Josh

________________________________
From: Lonnie Abelbeck <li...@lo...>
Sent: Sunday, February 20, 2022 11:21 AM
To: AstLinux Developers Mailing List <ast...@li...>
Subject: Re: [Astlinux-devel] Can't Add Bind to New Dev Build



> On Feb 20, 2022, at 9:54 AM, Lonnie Abelbeck <li...@lo...> wrote:
>
>
>> On Feb 20, 2022, at 9:06 AM, Josh Alberts <jm...@ho...> wrote:
>>
>> Hello Astlinux Team,
>>
>> I tried to make a fresh development built last night and I am unable to include 'bind libs and dig tool'. After adding it in 'make menuconfig' this is the error that I get when running the build script:
>>
>> ...
>
>> It's not imperative for me to have bind but I like to have it in my dev builds so I can use dig. Would you guys please consider bumping the version of bind to something that will build with Astlinux?
>>
>> Thanks!
>
> Hi Josh,
>
> AstLinux has never included "bind" in the image, the package has originated with an early Buildroot.
>
> Years ago we looked at adding "dig", but it added a lot to the disk image size ... which 5MB of .xz compressed source might imply.
>
> Instead the "unbound" package installs unbound-host (with a symlink for "host"), while not "dig" it provides a lot of functionality.  Much better than Busybox's nslookup.
>
> Lonnie

Josh, another thought...

In cases where it might be handy to have diagnostic tools (like "dig") you can install a Debian LXC container within AstLinux.

LXC container in AstLinux
https://doc.astlinux-project.org/userdoc:guest_lxc_container

The LXC container is not part of the AstLinux image, but uses /mnt/kd/lxc/ for storage, and must be kept updated separately.


Lonnie





_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel

Re: [Astlinux-devel] Can't Add Bind to New Dev Build

[Lonnie A. <li...@lo...>]

> On Feb 20, 2022, at 9:54 AM, Lonnie Abelbeck <li...@lo...> wrote:
> 
> 
>> On Feb 20, 2022, at 9:06 AM, Josh Alberts <jm...@ho...> wrote:
>> 
>> Hello Astlinux Team,
>> 
>> I tried to make a fresh development built last night and I am unable to include 'bind libs and dig tool'. After adding it in 'make menuconfig' this is the error that I get when running the build script:
>> 
>> ...
> 
>> It's not imperative for me to have bind but I like to have it in my dev builds so I can use dig. Would you guys please consider bumping the version of bind to something that will build with Astlinux?
>> 
>> Thanks!
> 
> Hi Josh,
> 
> AstLinux has never included "bind" in the image, the package has originated with an early Buildroot.
> 
> Years ago we looked at adding "dig", but it added a lot to the disk image size ... which 5MB of .xz compressed source might imply.
> 
> Instead the "unbound" package installs unbound-host (with a symlink for "host"), while not "dig" it provides a lot of functionality.  Much better than Busybox's nslookup.
> 
> Lonnie

Josh, another thought...

In cases where it might be handy to have diagnostic tools (like "dig") you can install a Debian LXC container within AstLinux.

LXC container in AstLinux
https://doc.astlinux-project.org/userdoc:guest_lxc_container

The LXC container is not part of the AstLinux image, but uses /mnt/kd/lxc/ for storage, and must be kept updated separately.


Lonnie

Re: [Astlinux-devel] Can't Add Bind to New Dev Build

[Lonnie A. <li...@lo...>]

> On Feb 20, 2022, at 9:06 AM, Josh Alberts <jm...@ho...> wrote:
> 
> Hello Astlinux Team,
> 
> I tried to make a fresh development built last night and I am unable to include 'bind libs and dig tool'. After adding it in 'make menuconfig' this is the error that I get when running the build script:
> 
> ...

> It's not imperative for me to have bind but I like to have it in my dev builds so I can use dig. Would you guys please consider bumping the version of bind to something that will build with Astlinux?
> 
> Thanks!

Hi Josh,

AstLinux has never included "bind" in the image, the package has originated with an early Buildroot.

Years ago we looked at adding "dig", but it added a lot to the disk image size ... which 5MB of .xz compressed source might imply.

Instead the "unbound" package installs unbound-host (with a symlink for "host"), while not "dig" it provides a lot of functionality.  Much better than Busybox's nslookup.

Lonnie

[Astlinux-devel] Can't Add Bind to New Dev Build

[Josh A. <jm...@ho...>]

Hello Astlinux Team,

I tried to make a fresh development built last night and I am unable to include 'bind libs and dig tool'. After adding it in 'make menuconfig' this is the error that I get when running the build script:

checking for OpenSSL library... using OpenSSL from /home/jalberts/astlinux/trunk/output/host/usr/x86_64-unknown-linux-gnu/sysroot/usr/lib and /home/jalberts/astlinux/trunk/output/host/usr/x86_64-unknown-linux-gnu/sysroot/usr/include
checking whether linking with OpenSSL works... assuming it does work on target platform
checking whether linking with OpenSSL requires -ldl... unknown
configure: error: OpenSSL has unsupported dynamic loading
make: *** [package/Makefile.package.in:282: /home/jalberts/astlinux/trunk/output/build/bind-9.10.3-P4/.stamp_configured] Error 1

It seems to me that bind 9-10.3-P4 is incompatible with the newest version of OpenSSL that Astlinux uses. I tried going into bind.mk and changing the variable 'BIND_VERSION' to the newest ESL version of bind, but that didn't work because they seem to have changed the file extensions to .tar.xz, and the build script goes out to the ISC FTP site looking for a .tar.gz file. I didn't see a way to change that.

It's not imperative for me to have bind but I like to have it in my dev builds so I can use dig. Would you guys please consider bumping the version of bind to something that will build with Astlinux?

Thanks!

[Astlinux-devel] AstLinux Pre-Release: astlinux-1.4-5380-6e3fb2

[Lonnie A. <li...@lo...>]

Announcing AstLinux Pre-Release: astlinux-1.4-5380-6e3fb2

Key new features:

-- Asterisk 18.x is now supported, along with Asterisk 16.x and Asterisk 13.x built --without-pjproject

-- Previous ast13-firmware-1.x is no longer being updated, ast13-firmware-1.x users should either switch to ast16-firmware-1.x (recommended)
	or use ast13se-firmware-1.x if chan_pjsip is not used in your dialplan.


** 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.230 (version bump), security and bug fixes

-- OpenSSL, version bump to 1.1.1m, security fixes: none

-- WireGuard VPN, module 1.0.20211208 (version bump), tools 1.0.20210914 (no change)

-- strongSwan, version 5.5.3, security fix: CVE-2021-45079

-- expat, version bump to 2.4.4, security fixes: many, many

-- libcurl (curl) version bump to 7.81.0

-- LibreTLS, version bump to 3.4.2

-- Monit, version bump to 5.31.0

-- msmtp, version bump to 1.8.19, 'msmtpd' security fix

-- nano, version 2.7.5, fix issue where not saving a file could still copy the file to /mnt/asturw/

-- tarsnap, version bump to 1.0.40, "Trust No One" encrypted backups using the Tarsnap Backup service.

-- zabbix, version bump to 4.0.38

-- Network tab, Non-ACME Self-Signed HTTPS Certificate, use 2048 key length.

-- Asterisk 13.38.3 ('13se' no change)
	Last Asterisk 13.x "Legacy" version, built --without-pjproject

-- Asterisk 16.21.1 (no change) and 18.10.0 (new version)
	Note: Asterisk 16.23.0 has issues with high call usage, reverting to 16.21.1

-- Complete Pre-Release ChangeLog:
https://astlinux-project.org/beta/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

[Astlinux-devel] New AstLinux Project cloud infrastructure

[Lonnie A. <li...@lo...>]

Greetings,

A simple note to let our users know about a new back-end cloud infrastructure for the AstLinux Project.

This change should be seamless, and unnoticed for the majority of you.

The AstLinux Project cloud infrastructure, including the documentation wiki, release images, release ISOs, domain DNS, as well as development files are all now hosted via Linode [1].

As such, some of you may download official release images to your own private repository.  Previously a person could use HTTPS with "s3.amazonaws.com/mirror.astlinux-project/..." to access release images and ISOs, for the future use HTTPS with "astlinux-project.org/mirror/...".  Note, if you use 'curl' include the '-L' option to follow the redirect.

Lastly, as special thanks goes out to Darrick Hartman for hosting the documentation wiki in his Colo and paying for AWS S3 costs for many years.  Darrick has long been involved with AstLinux (since 2006) and assisted with this transition ... Thanks!


AstLinux Team

[1] https://www.linode.com/

Re: [Astlinux-devel] Duplicate INT and EXT interfaces

[Michael K. <mic...@ip...>]

I'm still thinking the best option would be to restore the original config prior to the error but I'm not going to die in a ditch over it. 1st time it has happened in many years and I didn't lose access.

So was the firewall completely open after the reboot? This was actually my biggest concern!

Regards
Michael Knill

On 30/1/22, 4:13 am, "Michael Keuter" <li...@mk...> wrote:



    > Am 29.01.2022 um 17:43 schrieb Lonnie Abelbeck <li...@lo...>:
    > 
    >> On Jan 29, 2022, at 9:11 AM, Michael Keuter <li...@mk...> wrote:
    >> 
    >>> Am 29.01.2022 um 15:08 schrieb Lonnie Abelbeck <li...@lo...>:
    >>> 
    >>> Hi Michael,
    >>> 
    >>>> I learned something today. Having the same interface configured on EXT and INT breaks stuff. I realise that the Network Tab pops an error if this is the case but it still writes it in gui.network.conf. So if you click away from the tab and forget about it then when you reboot the system it will be broken.
    >>> 
    >>> Yes, I recall writing that code (more than 10 years ago).
    >>> 
    >>> During saveNETWORKsettings(...) the checkNETWORKsettings() function could arguably be called at the beginning, resulting in any changes to be lost for these errors:
    >>> --
    >>> } elseif ($result == 100) {
    >>> 	putHtml('<p style="color: red;">Error in Network Configuration, an Interface is used more than once.</p>');
    >>> } elseif ($result == 101) {
    >>> 	putHtml('<p style="color: red;">Error in Network Configuration, DMZ requires a LAN to also be defined.</p>');
    >>> } elseif ($result == 102) {
    >>> 	putHtml('<p style="color: red;">Warning! Firewall is enabled, but not configured, click "Firewall Configuration" and save.</p>');
    >>> } elseif ($result == 103) {
    >>> 	putHtml('<p style="color: red;">Error in Network Configuration, Invalid Timezone setting.</p>');
    >>> --
    >>> I recall testing this, and quickly decided to move checkNETWORKsettings() to the end of saveNETWORKsettings(...) so the changes (albeit with an error) are saved, with a descriptive error in "red" of what to fix (often a simple fix).
    >>> 
    >>> During typical usage, a lot of tedious data is entered in the Network tab, and it is all too easy to mis-select an interface.  Having to start over could raise a person's blood pressure.
    >>> 
    >>> Not to be flippant, but if a person drives through a "Bridge Out" sign on the road ... it usually doesn't end well. :-)
    >>> 
    >>> Lonnie
    >>> 
    > 
    >> Just an idea: Is it possible to NOT show a "used" NIC in the dropdown menu of the other interfaces (even if not rebooted yet)?
    >> 
    >> Let's we have 4 NICs, "External interface" is "eth0", then "1st LAN Interface" would show only "eth1,eth2,eth3".
    >> 
    >> Michael
    > 
    > Say you want to swap the "External interface" eth0 with the "1st LAN Interface" eth1, resulting in EXT:eth1 and LAN:eth0 ... all interfaces need to available to swap interfaces around.  During the selecting process there could be interfaces used multiple times.  Our PHP POST web interface offers a static state of menus between requests.

    Hmm, at least all Internal Interfaces, the DMZ and the Failover-Interface could be set to "None" during a possible swapping phase as a workaround.
    Only the External interface has to be set to an existing NIC.

    > I suppose there could be some javascript real-time warning ... and could be annoying.
    > 
    > Lonnie

    Michael

    http://www.mksolutions.info





    _______________________________________________
    Astlinux-devel mailing list
    Ast...@li...
    https://lists.sourceforge.net/lists/listinfo/astlinux-devel

Re: [Astlinux-devel] Duplicate INT and EXT interfaces

[Michael K. <li...@mk...>]

> Am 29.01.2022 um 17:43 schrieb Lonnie Abelbeck <li...@lo...>:
> 
>> On Jan 29, 2022, at 9:11 AM, Michael Keuter <li...@mk...> wrote:
>> 
>>> Am 29.01.2022 um 15:08 schrieb Lonnie Abelbeck <li...@lo...>:
>>> 
>>> Hi Michael,
>>> 
>>>> I learned something today. Having the same interface configured on EXT and INT breaks stuff. I realise that the Network Tab pops an error if this is the case but it still writes it in gui.network.conf. So if you click away from the tab and forget about it then when you reboot the system it will be broken.
>>> 
>>> Yes, I recall writing that code (more than 10 years ago).
>>> 
>>> During saveNETWORKsettings(...) the checkNETWORKsettings() function could arguably be called at the beginning, resulting in any changes to be lost for these errors:
>>> --
>>> } elseif ($result == 100) {
>>> 	putHtml('<p style="color: red;">Error in Network Configuration, an Interface is used more than once.</p>');
>>> } elseif ($result == 101) {
>>> 	putHtml('<p style="color: red;">Error in Network Configuration, DMZ requires a LAN to also be defined.</p>');
>>> } elseif ($result == 102) {
>>> 	putHtml('<p style="color: red;">Warning! Firewall is enabled, but not configured, click "Firewall Configuration" and save.</p>');
>>> } elseif ($result == 103) {
>>> 	putHtml('<p style="color: red;">Error in Network Configuration, Invalid Timezone setting.</p>');
>>> --
>>> I recall testing this, and quickly decided to move checkNETWORKsettings() to the end of saveNETWORKsettings(...) so the changes (albeit with an error) are saved, with a descriptive error in "red" of what to fix (often a simple fix).
>>> 
>>> During typical usage, a lot of tedious data is entered in the Network tab, and it is all too easy to mis-select an interface.  Having to start over could raise a person's blood pressure.
>>> 
>>> Not to be flippant, but if a person drives through a "Bridge Out" sign on the road ... it usually doesn't end well. :-)
>>> 
>>> Lonnie
>>> 
> 
>> Just an idea: Is it possible to NOT show a "used" NIC in the dropdown menu of the other interfaces (even if not rebooted yet)?
>> 
>> Let's we have 4 NICs, "External interface" is "eth0", then "1st LAN Interface" would show only "eth1,eth2,eth3".
>> 
>> Michael
> 
> Say you want to swap the "External interface" eth0 with the "1st LAN Interface" eth1, resulting in EXT:eth1 and LAN:eth0 ... all interfaces need to available to swap interfaces around.  During the selecting process there could be interfaces used multiple times.  Our PHP POST web interface offers a static state of menus between requests.

Hmm, at least all Internal Interfaces, the DMZ and the Failover-Interface could be set to "None" during a possible swapping phase as a workaround.
Only the External interface has to be set to an existing NIC.

> I suppose there could be some javascript real-time warning ... and could be annoying.
> 
> Lonnie

Michael

http://www.mksolutions.info

Re: [Astlinux-devel] Duplicate INT and EXT interfaces

[Lonnie A. <li...@lo...>]

> On Jan 29, 2022, at 9:11 AM, Michael Keuter <li...@mk...> wrote:
> 
> 
> 
>> Am 29.01.2022 um 15:08 schrieb Lonnie Abelbeck <li...@lo...>:
>> 
>> Hi Michael,
>> 
>>> I learned something today. Having the same interface configured on EXT and INT breaks stuff. I realise that the Network Tab pops an error if this is the case but it still writes it in gui.network.conf. So if you click away from the tab and forget about it then when you reboot the system it will be broken.
>> 
>> Yes, I recall writing that code (more than 10 years ago).
>> 
>> During saveNETWORKsettings(...) the checkNETWORKsettings() function could arguably be called at the beginning, resulting in any changes to be lost for these errors:
>> --
>> } elseif ($result == 100) {
>> 	putHtml('<p style="color: red;">Error in Network Configuration, an Interface is used more than once.</p>');
>> } elseif ($result == 101) {
>> 	putHtml('<p style="color: red;">Error in Network Configuration, DMZ requires a LAN to also be defined.</p>');
>> } elseif ($result == 102) {
>> 	putHtml('<p style="color: red;">Warning! Firewall is enabled, but not configured, click "Firewall Configuration" and save.</p>');
>> } elseif ($result == 103) {
>> 	putHtml('<p style="color: red;">Error in Network Configuration, Invalid Timezone setting.</p>');
>> --
>> I recall testing this, and quickly decided to move checkNETWORKsettings() to the end of saveNETWORKsettings(...) so the changes (albeit with an error) are saved, with a descriptive error in "red" of what to fix (often a simple fix).
>> 
>> During typical usage, a lot of tedious data is entered in the Network tab, and it is all too easy to mis-select an interface.  Having to start over could raise a person's blood pressure.
>> 
>> Not to be flippant, but if a person drives through a "Bridge Out" sign on the road ... it usually doesn't end well. :-)
>> 
>> Lonnie
>> 

> Just an idea: Is it possible to NOT show a "used" NIC in the dropdown menu of the other interfaces (even if not rebooted yet)?
> 
> Let's we have 4 NICs, "External interface" is "eth0", then "1st LAN Interface" would show only "eth1,eth2,eth3".
> 
> Michael

Say you want to swap the "External interface" eth0 with the "1st LAN Interface" eth1, resulting in EXT:eth1 and LAN:eth0 ... all interfaces need to available to swap interfaces around.  During the selecting process there could be interfaces used multiple times.  Our PHP POST web interface offers a static state of menus between requests.

I suppose there could be some javascript real-time warning ... and could be annoying.


Lonnie

Re: [Astlinux-devel] Duplicate INT and EXT interfaces

[Michael K. <li...@mk...>]

> Am 29.01.2022 um 15:08 schrieb Lonnie Abelbeck <li...@lo...>:
> 
> Hi Michael,
> 
>> I learned something today. Having the same interface configured on EXT and INT breaks stuff. I realise that the Network Tab pops an error if this is the case but it still writes it in gui.network.conf. So if you click away from the tab and forget about it then when you reboot the system it will be broken.
> 
> Yes, I recall writing that code (more than 10 years ago).
> 
> During saveNETWORKsettings(...) the checkNETWORKsettings() function could arguably be called at the beginning, resulting in any changes to be lost for these errors:
> --
> } elseif ($result == 100) {
> 	putHtml('<p style="color: red;">Error in Network Configuration, an Interface is used more than once.</p>');
> } elseif ($result == 101) {
> 	putHtml('<p style="color: red;">Error in Network Configuration, DMZ requires a LAN to also be defined.</p>');
> } elseif ($result == 102) {
> 	putHtml('<p style="color: red;">Warning! Firewall is enabled, but not configured, click "Firewall Configuration" and save.</p>');
> } elseif ($result == 103) {
> 	putHtml('<p style="color: red;">Error in Network Configuration, Invalid Timezone setting.</p>');
> --
> I recall testing this, and quickly decided to move checkNETWORKsettings() to the end of saveNETWORKsettings(...) so the changes (albeit with an error) are saved, with a descriptive error in "red" of what to fix (often a simple fix).
> 
> During typical usage, a lot of tedious data is entered in the Network tab, and it is all too easy to mis-select an interface.  Having to start over could raise a person's blood pressure.
> 
> Not to be flippant, but if a person drives through a "Bridge Out" sign on the road ... it usually doesn't end well. :-)
> 
> Lonnie
> 
> 
> 
>> On Jan 28, 2022, at 5:09 PM, Michael Knill <mic...@ip...> wrote:
>> 
>> Hi Devs
>> 
>> I learned something today. Having the same interface configured on EXT and INT breaks stuff. I realise that the Network Tab pops an error if this is the case but it still writes it in gui.network.conf. So if you click away from the tab and forget about it then when you reboot the system it will be broken.
>> It all started when I was trying to write a firewall rule and it kept popping a firewall error even though it was fine. So I rebooted the system and then it was quite broken. Luckily I could still get into the system and after doing ‘arno-iptables-firewall force-reload’ I found the error. I'm concerned though that it was without a firewall after the reboot:
>> 
>> # arno-iptables-firewall status
>> Arno's Iptables Firewall Script v2.0.2-05-astlinux
>> -------------------------------------------------------------------------------
>> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
>>    pkts      bytes target     prot opt in     out     source               destination
>> 
>> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>>    pkts      bytes target     prot opt in     out     source               destination
>> 
>> Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
>>    pkts      bytes target     prot opt in     out     source               destination
>> Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
>>    pkts      bytes target     prot opt in     out     source               destination
>> 
>> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
>>    pkts      bytes target     prot opt in     out     source               destination
>> 
>> Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
>>    pkts      bytes target     prot opt in     out     source               destination
>> 
>> Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
>>    pkts      bytes target     prot opt in     out     source               destination
>> 
>> Is this the case?
>> 
>> Wondering if it is worth saving the previous network config on each save and after popping an error, the previous network config is reinstated and you are notified of this in the error message.
>> 
>> Regards
>> 
>> Michael Knill
>> Managing Director

Just an idea: Is it possible to NOT show a "used" NIC in the dropdown menu of the other interfaces (even if not rebooted yet)?

Let's we have 4 NICs, "External interface" is "eth0", then "1st LAN Interface" would show only "eth1,eth2,eth3".

Michael

http://www.mksolutions.info

Re: [Astlinux-devel] Duplicate INT and EXT interfaces

[Lonnie A. <li...@lo...>]

Hi Michael,

> I learned something today. Having the same interface configured on EXT and INT breaks stuff. I realise that the Network Tab pops an error if this is the case but it still writes it in gui.network.conf. So if you click away from the tab and forget about it then when you reboot the system it will be broken.

Yes, I recall writing that code (more than 10 years ago).

During saveNETWORKsettings(...) the checkNETWORKsettings() function could arguably be called at the beginning, resulting in any changes to be lost for these errors:
--
} elseif ($result == 100) {
	putHtml('<p style="color: red;">Error in Network Configuration, an Interface is used more than once.</p>');
} elseif ($result == 101) {
	putHtml('<p style="color: red;">Error in Network Configuration, DMZ requires a LAN to also be defined.</p>');
} elseif ($result == 102) {
	putHtml('<p style="color: red;">Warning! Firewall is enabled, but not configured, click "Firewall Configuration" and save.</p>');
} elseif ($result == 103) {
	putHtml('<p style="color: red;">Error in Network Configuration, Invalid Timezone setting.</p>');
--
I recall testing this, and quickly decided to move checkNETWORKsettings() to the end of saveNETWORKsettings(...) so the changes (albeit with an error) are saved, with a descriptive error in "red" of what to fix (often a simple fix).

During typical usage, a lot of tedious data is entered in the Network tab, and it is all too easy to mis-select an interface.  Having to start over could raise a person's blood pressure.

Not to be flippant, but if a person drives through a "Bridge Out" sign on the road ... it usually doesn't end well. :-)

Lonnie



> On Jan 28, 2022, at 5:09 PM, Michael Knill <mic...@ip...> wrote:
> 
> Hi Devs
>  
> I learned something today. Having the same interface configured on EXT and INT breaks stuff. I realise that the Network Tab pops an error if this is the case but it still writes it in gui.network.conf. So if you click away from the tab and forget about it then when you reboot the system it will be broken.
> It all started when I was trying to write a firewall rule and it kept popping a firewall error even though it was fine. So I rebooted the system and then it was quite broken. Luckily I could still get into the system and after doing ‘arno-iptables-firewall force-reload’ I found the error. I'm concerned though that it was without a firewall after the reboot:
>  
> # arno-iptables-firewall status
> Arno's Iptables Firewall Script v2.0.2-05-astlinux
> -------------------------------------------------------------------------------
> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
>     pkts      bytes target     prot opt in     out     source               destination
>  
> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>     pkts      bytes target     prot opt in     out     source               destination
>  
> Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
>     pkts      bytes target     prot opt in     out     source               destination
> Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
>     pkts      bytes target     prot opt in     out     source               destination
>  
> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
>     pkts      bytes target     prot opt in     out     source               destination
>  
> Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
>     pkts      bytes target     prot opt in     out     source               destination
>  
> Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
>     pkts      bytes target     prot opt in     out     source               destination
>  
> Is this the case?
>  
> Wondering if it is worth saving the previous network config on each save and after popping an error, the previous network config is reinstated and you are notified of this in the error message.
>  
> 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] Duplicate INT and EXT interfaces

[Michael K. <mic...@ip...>]

Hi Devs

I learned something today. Having the same interface configured on EXT and INT breaks stuff. I realise that the Network Tab pops an error if this is the case but it still writes it in gui.network.conf. So if you click away from the tab and forget about it then when you reboot the system it will be broken.
It all started when I was trying to write a firewall rule and it kept popping a firewall error even though it was fine. So I rebooted the system and then it was quite broken. Luckily I could still get into the system and after doing ‘arno-iptables-firewall force-reload’ I found the error. I'm concerned though that it was without a firewall after the reboot:

# arno-iptables-firewall status
Arno's Iptables Firewall Script v2.0.2-05-astlinux
-------------------------------------------------------------------------------
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Is this the case?

Wondering if it is worth saving the previous network config on each save and after popping an error, the previous network config is reinstated and you are notified of this in the error message.

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/>

 [Icon  Description automatically generated]
Smarter Business Communications

[Astlinux-devel] AstLinux Pre-Release: astlinux-1.4-5333-94c1eb

[Lonnie A. <li...@lo...>]

Announcing AstLinux Pre-Release: astlinux-1.4-5333-94c1eb

Key new features:

-- Asterisk 18.x is now supported, along with Asterisk 16.x and Asterisk 13.x built --without-pjproject

-- Previous ast13-firmware-1.x is no longer being updated, ast13-firmware-1.x users should either switch to ast16-firmware-1.x (recommended)
	or use ast13se-firmware-1.x if chan_pjsip is not used in your dialplan.


** 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.224 (version bump), security and bug fixes

-- OpenSSL, version bump to 1.1.1m, security fixes: none

-- WireGuard VPN, module 1.0.20211208 (version bump), tools 1.0.20210914 (no change)

-- libcurl (curl) version bump to 7.81.0

-- LibreTLS, version bump to 3.4.2

-- msmtp, version bump to 1.8.19, 'msmtpd' security fix

-- nano, version 2.7.5, fix issue where not saving a file could still copy the file to /mnt/asturw/

-- Network tab, Non-ACME Self-Signed HTTPS Certificate, use 2048 key length.

-- Asterisk 13.38.3 ('13se' no change)
	Last Asterisk 13.x "Legacy" version, built --without-pjproject

-- Asterisk 16.23.0 (version bump) and 18.9.0 (new version)

-- 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

Re: [Astlinux-devel] Vultr Astlinux Build process

[Michael K. <li...@mk...>]

I made a new note relecting this at the top of the Vultr Wiki page.

https://doc.astlinux.org/userdoc:hosted_guest_vm_vultr

> Am 22.12.2021 um 20:42 schrieb Michael Knill <mic...@ip...>:
> 
> Great thanks Lonnie. That explains it.
>  
> Regards
> Michael Knill
>  
> From: Lonnie Abelbeck <li...@lo...>
> Reply to: AstLinux Developers Mailing List <ast...@li...>
> Date: Thursday, 23 December 2021 at 3:29 am
> To: AstLinux Developers Mailing List <ast...@li...>
> Subject: Re: [Astlinux-devel] Vultr Astlinux Build process
>  
> Hi Michael,
>  
> Ahhh, OK I now understand ...
>  
> Long story short, deploying a fresh new Vultr instance now requires a Linux kernel 4.x or later Custom ISO, the virtio_blk driver is no longer recognized with a Linux 3.16.x kernel using Vultr's latest VM.
>  
> So, testing with AstLinux 1.3.10 the ISO installer appears but when trying to install a "No suitable disk found." message is displayed.  This is because the /dev/vda virtio_blk mount is not available.
>  
> Bottom line, a Linux 3.16.x kernel is no longer compatible with a fresh new Vultr instance.  Which corresponds to AstLinux 1.3.10 and earlier. In other words if a person created a fresh new Vultr instance using AstLinux 1.4.4 and then did a "upgrade-run-image upgrade ..." to an AstLinux 1.3.10 image, that image will not boot.
>  
> Next you might ask, if a old Vultr instance that was created with a Linux 3.16.x kernel will it still work ... I tried and the answer is yes:
>  
> <Screen Shot 2021-12-22 at 9.59.39 AM.png>
>  
> So my personal older test Vultr instance VM will still work with an AstLinux 1.3.4 or later run image.
>  
> Not sure if this is bug on Vultr's part, but it is highly recommended to use AstLinux 1.4.4 with a fresh new Vultr instance anyway.
>  
> Lonnie

Michael

http://www.mksolutions.info

Re: [Astlinux-devel] Vultr Astlinux Build process

[Michael K. <mic...@ip...>]

Great thanks Lonnie. That explains it.

Regards
Michael Knill

From: Lonnie Abelbeck <li...@lo...>
Reply to: AstLinux Developers Mailing List <ast...@li...>
Date: Thursday, 23 December 2021 at 3:29 am
To: AstLinux Developers Mailing List <ast...@li...>
Subject: Re: [Astlinux-devel] Vultr Astlinux Build process

Hi Michael,

Ahhh, OK I now understand ...

Long story short, deploying a fresh new Vultr instance now requires a Linux kernel 4.x or later Custom ISO, the virtio_blk driver is no longer recognized with a Linux 3.16.x kernel using Vultr's latest VM.

So, testing with AstLinux 1.3.10 the ISO installer appears but when trying to install a "No suitable disk found." message is displayed.  This is because the /dev/vda virtio_blk mount is not available.

Bottom line, a Linux 3.16.x kernel is no longer compatible with a fresh new Vultr instance.  Which corresponds to AstLinux 1.3.10 and earlier. In other words if a person created a fresh new Vultr instance using AstLinux 1.4.4 and then did a "upgrade-run-image upgrade ..." to an AstLinux 1.3.10 image, that image will not boot.

Next you might ask, if a old Vultr instance that was created with a Linux 3.16.x kernel will it still work ... I tried and the answer is yes:

[cid:295...@pr...]

So my personal older test Vultr instance VM will still work with an AstLinux 1.3.4 or later run image.

Not sure if this is bug on Vultr's part, but it is highly recommended to use AstLinux 1.4.4 with a fresh new Vultr instance anyway.

Lonnie




On Dec 21, 2021, at 11:39 PM, Michael Knill <mic...@ip...<mailto:mic...@ip...>> wrote:

Nope certainly does not work using 1.3.10. No suitable disk found!
Works ok in 1.4.4 however.

Regards
Michael Knill

On 21/12/21, 10:55 am, "Michael Knill" <mic...@ip...<mailto:mic...@ip...>> wrote:

   Hmm sorry if I have caused you unnecessary hassle. I will test it out again and report back.

   Regards
   Michael Knill

   On 21/12/21, 2:43 am, "Lonnie Abelbeck" <li...@lo...<mailto:li...@lo...>> wrote:

       Hi Michael,

       I created a few new test instances on Vultr using AstLinux 1.4.4 [1]

       Quick answer, this all worked as expected per the docs, I even created a couple Sydney AU location instances.

       Though a couple minor changes since the "Vultr KVM" docs [2] were created:

       1) "Cloud Compute" is no longer the default, "High Frequency" (for $6 vs. $5/month) is now the default.

       2) Sometimes when viewing the console with "Cloud Compute" I saw "ISO medium not found" or some such, but closing the console and viewing the console again the "AstLinux Installer" is shown and works as expected.  Possibly waiting an additional 30 seconds is needed.

       3) When using the new "High Frequency" instance, viewing the console always showed the "AstLinux Installer" without any hiccups.

       Otherwise, Vultr seemed to work very nicely.

       Lonnie

       [1] https://s3.amazonaws.com/mirror.astlinux-project/downloads/iso/astlinux-1.4.4-genx86_64-vm.iso

       [2] https://doc.astlinux-project.org/userdoc:hosted_guest_vm_vultr





On Dec 19, 2021, at 11:06 PM, Michael Knill <mic...@ip...<mailto:mic...@ip...>> wrote:

Hi Devs

Unfortunately the build page is now incorrect as they have changed things in Vultr. Using this process it cant find a disk.
You need to allocate an OS rather than Custom ISO and then add the ISO afterwards and reboot.
Would you like us to edit it?

Regards

Michael Knill
Managing Director



       _______________________________________________
       Astlinux-devel mailing list
       Ast...@li...<mailto:Ast...@li...>
       https://lists.sourceforge.net/lists/listinfo/astlinux-devel


   _______________________________________________
   Astlinux-devel mailing list
   Ast...@li...<mailto:Ast...@li...>
   https://lists.sourceforge.net/lists/listinfo/astlinux-devel


_______________________________________________
Astlinux-devel mailing list
Ast...@li...<mailto:Ast...@li...>
https://lists.sourceforge.net/lists/listinfo/astlinux-devel

Re: [Astlinux-devel] Vultr Astlinux Build process

[Lonnie A. <li...@lo...>]

Hi Michael,

Ahhh, OK I now understand ...

Long story short, deploying a fresh new Vultr instance now requires a Linux kernel 4.x or later Custom ISO, the virtio_blk driver is no longer recognized with a Linux 3.16.x kernel using Vultr's latest VM.

So, testing with AstLinux 1.3.10 the ISO installer appears but when trying to install a "No suitable disk found." message is displayed.  This is because the /dev/vda virtio_blk mount is not available.

Bottom line, a Linux 3.16.x kernel is no longer compatible with a fresh new Vultr instance.  Which corresponds to AstLinux 1.3.10 and earlier. In other words if a person created a fresh new Vultr instance using AstLinux 1.4.4 and then did a "upgrade-run-image upgrade ..." to an AstLinux 1.3.10 image, that image will not boot.

Next you might ask, if a old Vultr instance that was created with a Linux 3.16.x kernel will it still work ... I tried and the answer is yes:



So my personal older test Vultr instance VM will still work with an AstLinux 1.3.4 or later run image.

Not sure if this is bug on Vultr's part, but it is highly recommended to use AstLinux 1.4.4 with a fresh new Vultr instance anyway.

Lonnie



> On Dec 21, 2021, at 11:39 PM, Michael Knill <mic...@ip... <mailto:mic...@ip...>> wrote:
> 
> Nope certainly does not work using 1.3.10. No suitable disk found!
> Works ok in 1.4.4 however.
> 
> Regards
> Michael Knill
> 
> On 21/12/21, 10:55 am, "Michael Knill" <mic...@ip... <mailto:mic...@ip...>> wrote:
> 
>    Hmm sorry if I have caused you unnecessary hassle. I will test it out again and report back.
> 
>    Regards
>    Michael Knill
> 
>    On 21/12/21, 2:43 am, "Lonnie Abelbeck" <li...@lo... <mailto:li...@lo...>> wrote:
> 
>        Hi Michael,
> 
>        I created a few new test instances on Vultr using AstLinux 1.4.4 [1]
> 
>        Quick answer, this all worked as expected per the docs, I even created a couple Sydney AU location instances.
> 
>        Though a couple minor changes since the "Vultr KVM" docs [2] were created:
> 
>        1) "Cloud Compute" is no longer the default, "High Frequency" (for $6 vs. $5/month) is now the default.
> 
>        2) Sometimes when viewing the console with "Cloud Compute" I saw "ISO medium not found" or some such, but closing the console and viewing the console again the "AstLinux Installer" is shown and works as expected.  Possibly waiting an additional 30 seconds is needed.
> 
>        3) When using the new "High Frequency" instance, viewing the console always showed the "AstLinux Installer" without any hiccups.
> 
>        Otherwise, Vultr seemed to work very nicely.
> 
>        Lonnie
> 
>        [1] https://s3.amazonaws.com/mirror.astlinux-project/downloads/iso/astlinux-1.4.4-genx86_64-vm.iso <https://s3.amazonaws.com/mirror.astlinux-project/downloads/iso/astlinux-1.4.4-genx86_64-vm.iso>
> 
>        [2] https://doc.astlinux-project.org/userdoc:hosted_guest_vm_vultr <https://doc.astlinux-project.org/userdoc:hosted_guest_vm_vultr>
> 
> 
> 
> 
>> On Dec 19, 2021, at 11:06 PM, Michael Knill <mic...@ip... <mailto:mic...@ip...>> wrote:
>> 
>> Hi Devs
>> 
>> Unfortunately the build page is now incorrect as they have changed things in Vultr. Using this process it cant find a disk.
>> You need to allocate an OS rather than Custom ISO and then add the ISO afterwards and reboot.
>> Would you like us to edit it?
>> 
>> Regards
>> 
>> Michael Knill
>> Managing Director
> 
> 
> 
>        _______________________________________________
>        Astlinux-devel mailing list
>        Ast...@li... <mailto:Ast...@li...>
>        https://lists.sourceforge.net/lists/listinfo/astlinux-devel <https://lists.sourceforge.net/lists/listinfo/astlinux-devel>
> 
> 
>    _______________________________________________
>    Astlinux-devel mailing list
>    Ast...@li... <mailto:Ast...@li...>
>    https://lists.sourceforge.net/lists/listinfo/astlinux-devel <https://lists.sourceforge.net/lists/listinfo/astlinux-devel>
> 
> 
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li... <mailto:Ast...@li...>
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel

Re: [Astlinux-devel] Vultr Astlinux Build process

[Michael K. <mic...@ip...>]

Nope certainly does not work using 1.3.10. No suitable disk found!
Works ok in 1.4.4 however.

Regards
Michael Knill

On 21/12/21, 10:55 am, "Michael Knill" <mic...@ip...> wrote:

    Hmm sorry if I have caused you unnecessary hassle. I will test it out again and report back.

    Regards
    Michael Knill

    On 21/12/21, 2:43 am, "Lonnie Abelbeck" <li...@lo...> wrote:

        Hi Michael,

        I created a few new test instances on Vultr using AstLinux 1.4.4 [1]

        Quick answer, this all worked as expected per the docs, I even created a couple Sydney AU location instances.

        Though a couple minor changes since the "Vultr KVM" docs [2] were created:

        1) "Cloud Compute" is no longer the default, "High Frequency" (for $6 vs. $5/month) is now the default.

        2) Sometimes when viewing the console with "Cloud Compute" I saw "ISO medium not found" or some such, but closing the console and viewing the console again the "AstLinux Installer" is shown and works as expected.  Possibly waiting an additional 30 seconds is needed.

        3) When using the new "High Frequency" instance, viewing the console always showed the "AstLinux Installer" without any hiccups.

        Otherwise, Vultr seemed to work very nicely.

        Lonnie

        [1] https://s3.amazonaws.com/mirror.astlinux-project/downloads/iso/astlinux-1.4.4-genx86_64-vm.iso

        [2] https://doc.astlinux-project.org/userdoc:hosted_guest_vm_vultr




        > On Dec 19, 2021, at 11:06 PM, Michael Knill <mic...@ip...> wrote:
        > 
        > Hi Devs
        >  
        > Unfortunately the build page is now incorrect as they have changed things in Vultr. Using this process it cant find a disk.
        > You need to allocate an OS rather than Custom ISO and then add the ISO afterwards and reboot.
        > Would you like us to edit it?
        >  
        > Regards
        >  
        > Michael Knill
        > Managing Director



        _______________________________________________
        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

Re: [Astlinux-devel] Vultr Astlinux Build process

[Michael K. <mic...@ip...>]

Hmm sorry if I have caused you unnecessary hassle. I will test it out again and report back.

Regards
Michael Knill

On 21/12/21, 2:43 am, "Lonnie Abelbeck" <li...@lo...> wrote:

    Hi Michael,

    I created a few new test instances on Vultr using AstLinux 1.4.4 [1]

    Quick answer, this all worked as expected per the docs, I even created a couple Sydney AU location instances.

    Though a couple minor changes since the "Vultr KVM" docs [2] were created:

    1) "Cloud Compute" is no longer the default, "High Frequency" (for $6 vs. $5/month) is now the default.

    2) Sometimes when viewing the console with "Cloud Compute" I saw "ISO medium not found" or some such, but closing the console and viewing the console again the "AstLinux Installer" is shown and works as expected.  Possibly waiting an additional 30 seconds is needed.

    3) When using the new "High Frequency" instance, viewing the console always showed the "AstLinux Installer" without any hiccups.

    Otherwise, Vultr seemed to work very nicely.

    Lonnie

    [1] https://s3.amazonaws.com/mirror.astlinux-project/downloads/iso/astlinux-1.4.4-genx86_64-vm.iso

    [2] https://doc.astlinux-project.org/userdoc:hosted_guest_vm_vultr




    > On Dec 19, 2021, at 11:06 PM, Michael Knill <mic...@ip...> wrote:
    > 
    > Hi Devs
    >  
    > Unfortunately the build page is now incorrect as they have changed things in Vultr. Using this process it cant find a disk.
    > You need to allocate an OS rather than Custom ISO and then add the ISO afterwards and reboot.
    > Would you like us to edit it?
    >  
    > Regards
    >  
    > Michael Knill
    > Managing Director



    _______________________________________________
    Astlinux-devel mailing list
    Ast...@li...
    https://lists.sourceforge.net/lists/listinfo/astlinux-devel

Re: [Astlinux-devel] Vultr Astlinux Build process

[Lonnie A. <li...@lo...>]

Hi Michael,

I created a few new test instances on Vultr using AstLinux 1.4.4 [1]

Quick answer, this all worked as expected per the docs, I even created a couple Sydney AU location instances.

Though a couple minor changes since the "Vultr KVM" docs [2] were created:

1) "Cloud Compute" is no longer the default, "High Frequency" (for $6 vs. $5/month) is now the default.

2) Sometimes when viewing the console with "Cloud Compute" I saw "ISO medium not found" or some such, but closing the console and viewing the console again the "AstLinux Installer" is shown and works as expected.  Possibly waiting an additional 30 seconds is needed.

3) When using the new "High Frequency" instance, viewing the console always showed the "AstLinux Installer" without any hiccups.

Otherwise, Vultr seemed to work very nicely.

Lonnie

[1] https://s3.amazonaws.com/mirror.astlinux-project/downloads/iso/astlinux-1.4.4-genx86_64-vm.iso

[2] https://doc.astlinux-project.org/userdoc:hosted_guest_vm_vultr




> On Dec 19, 2021, at 11:06 PM, Michael Knill <mic...@ip...> wrote:
> 
> Hi Devs
>  
> Unfortunately the build page is now incorrect as they have changed things in Vultr. Using this process it cant find a disk.
> You need to allocate an OS rather than Custom ISO and then add the ISO afterwards and reboot.
> Would you like us to edit it?
>  
> Regards
>  
> Michael Knill
> Managing Director

Re: [Astlinux-devel] Vultr Astlinux Build process

[Michael K. <mic...@ip...>]

Yes it looks the same but it does not work as it cant find the drive.
Works if you set to FreeBSD (or likely anything else) and then attach Custom ISO and reboot when provisioned.

Regards
Michael Knill

From: Michael Keuter <li...@mk...>
Reply to: AstLinux Developers Mailing List <ast...@li...>
Date: Monday, 20 December 2021 at 8:47 pm
To: AstLinux Developers Mailing List <ast...@li...>
Subject: Re: [Astlinux-devel] Vultr Astlinux Build process




Am 20.12.2021 um 06:06 schrieb Michael Knill <mic...@ip...<mailto:mic...@ip...>>:

Hi Devs

Unfortunately the build page is now incorrect as they have changed things in Vultr. Using this process it cant find a disk.
You need to allocate an OS rather than Custom ISO and then add the ISO afterwards and reboot.
Would you like us to edit it?

Regards

Michael Knill
Managing Director

Hi Michael,

I looked up Vultr, and to me it looks like before (but I haven't created a new instance):

[cid:793...@pr...]
Michael

http://www.mksolutions.info

Re: [Astlinux-devel] Vultr Astlinux Build process

[Michael K. <li...@mk...>]

> Am 20.12.2021 um 06:06 schrieb Michael Knill <mic...@ip...>:
> 
> Hi Devs
>  
> Unfortunately the build page is now incorrect as they have changed things in Vultr. Using this process it cant find a disk.
> You need to allocate an OS rather than Custom ISO and then add the ISO afterwards and reboot.
> Would you like us to edit it?
>  
> Regards
>  
> Michael Knill
> Managing Director

Hi Michael,

I looked up Vultr, and to me it looks like before (but I haven't created a new instance):



Michael

http://www.mksolutions.info

[Astlinux-devel] Vultr Astlinux Build process

[Michael K. <mic...@ip...>]

Hi Devs

Unfortunately the build page is now incorrect as they have changed things in Vultr. Using this process it cant find a disk.
You need to allocate an OS rather than Custom ISO and then add the ISO afterwards and reboot.
Would you like us to edit it?

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

Re: [Astlinux-devel] Duplicated files in ASTURW

[Ramesh GK <ram...@ho...>]

Hi Lonnie,

Seems like our emails collided. I just did a test with the patch on 2.7.5 and it worked. glad that you have figured that out so fast.

Thanks
Ramesh GK

________________________________
From: Lonnie Abelbeck <li...@lo...>
Sent: Monday, December 13, 2021 4:47 PM
To: AstLinux Developers Mailing List <ast...@li...>
Subject: Re: [Astlinux-devel] Duplicated files in ASTURW

I found the problem in our (older) version of nano, fixed with:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fastlinux-project%2Fastlinux%2Fcommit%2F40613be0cce1d3d33a7a9a37b3f9ba1d3486aa78&amp;data=04%7C01%7C%7C44ba008229e64146b42408d9be823987%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637750288784797243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=4gggzgvAF849hIbU%2FYk%2BzrHTlErihliEHSqICNPdIZs%3D&amp;reserved=0

This fix was included with nano-4.3.

The problem occurred when a file was opened, the file writability check actually *wrote* to the file, now simply permission bits are checked.

Tested and seems to fix the problem Ramesh noted.

Lonnie



> On Dec 13, 2021, at 9:12 AM, Lonnie Abelbeck <li...@lo...> wrote:
>
> Hi Ramesh,
>
> I don't use nano myself ('vi' commands are involuntary to me), though I have replicated your findings.
> Even if you make a text change in nano and ^X ...
> --
> Save modified buffer?  (Answering "No" will DISCARD changes.) N
> --
> nano will *still* write out the original file!
>
> I would be open to a patch to nano (2.7.5) to fix this awful behavior.
>
>
> There is a -v (--view) option to nano (View mode (read-only)) which solves the problem.
>
> pbx4 ~ # nano -v /etc/shells
>
> Possibly create a bash alias "view"
>
> pbx4 ~ # alias view='nano -v'
>
> would support nano read-only mode
>
> pbx4 ~ # view /etc/shells
>
>
> BTW Ramesh, I seem to recall you appreciate "classic" software, the 'ne' editor is much better than nano (IMHO) and 'ne' originated for the Amiga, a Copyright going back to 1992 in the source.  30 years of good stuff, and still maintained.  Included by default in AstLinux.
>
> ne, the nice editor
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fne.di.unimi.it%2F&amp;data=04%7C01%7C%7C44ba008229e64146b42408d9be823987%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637750288784797243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=BllptMOpFoLOavkfticumm0PrPmbo7t2KlAMwR2uUts%3D&amp;reserved=0
>
>
> Lonnie
>
>
>
>> On Dec 13, 2021, at 7:57 AM, Ramesh GK <ram...@ho...> wrote:
>>
>> Hi Lonnie,
>>
>> Thanks for checking. you are correct. If i open the file in /mnt/asturo/etc/shells then no corresponding file is getting created in /mnt/asturw but if I open the file /etc/shells then a corresponding file is getting created in /mnt/asturw as it is an overlay of /mnt/asturo for /etc.
>>
>> i tried to do the same tests that you have done below and figured out the issue. Looks like the issue is occuring because of nano. I use nano for file review or editing mostly. whenever I open the file in nano and close it without making any modifications, it is still trying to save the file i guess. that was the reason a corresponding entry is getting created in /mnt/asturw.
>>
>> Thanks
>> Ramesh GK
>> From: Lonnie Abelbeck <li...@lo...>
>> Sent: Sunday, December 12, 2021 6:30 PM
>> To: AstLinux Developers Mailing List <ast...@li...>
>> Subject: Re: [Astlinux-devel] Duplicated files in ASTURW
>>
>> Hi Ramesh,
>>
>>>> When I startup the firmware image and open any file in /mnt/asturo (/etc or /stat) that does not have a link to /tmp, it creates a duplicate file in /mnt/asturw.
>>
>>
>> I'm not sure what "open any file" means ... if you open a file on /mnt/asturo read-only then no file should be written to /mnt/asturw.
>>
>> On the other hand, if you open a file on /mnt/asturo and change the contents, timestamp or write to it, then a corresponding change to /mnt/asturw will occur.
>>
>> For example:
>>
>> pbx4 ~ # ls -l /etc/shells
>> -rw-r--r--    1 root     root            38 Apr  6  2020 /etc/shells
>> pbx4 ~ # ls -l /mnt/asturo/etc/shells
>> -rw-r--r--    1 root     root            38 Apr  6  2020 /mnt/asturo/etc/shells
>> pbx4 ~ # ls -l /mnt/asturw/etc/shells
>> ls: /mnt/asturw/etc/shells: No such file or directory
>>
>> Then "cat /etc/shells"
>>
>> pbx4 ~ # cat /etc/shells
>>
>> pbx4 ~ # ls -l /mnt/asturw/etc/shells
>> ls: /mnt/asturw/etc/shells: No such file or directory
>>
>> Note it is not copied to /mnt/asturw
>>
>> Also, use an editor and quit without writing ...
>>
>> pbx4 ~ # vi /etc/shells
>> Enter-> :q
>>
>> pbx4 ~ # ne /etc/shells
>> Enter-> <ESC>q or CTL-q
>>
>> pbx4 ~ # ls -l /mnt/asturw/etc/shells
>> ls: /mnt/asturw/etc/shells: No such file or directory
>>
>> So in summary, try to understand why the /mnt/asturo files are getting written to when you don't want them to.
>>
>> Lonnie
>>
>>
>>> On Dec 12, 2021, at 3:13 PM, Ramesh GK <ram...@ho...> wrote:
>>>
>>> Hi,
>>>
>>> A while back I reached out of using AstLinux as a Home Gateway Appliance. I am working on the same and observed a weird issue. I migrated the entire build system to buildroot-2017.02.11 and the packages merged between (buildroot and AstLinux) and fixed all (mostly) issues. Happy to share the code base but it is still in beta with a working firmware image as I have not tested the Asterisk components.
>>>
>>> When I startup the firmware image and open any file in /mnt/asturo (/etc or /stat) that does not have a link to /tmp, it creates a duplicate file in /mnt/asturw. This should not pose a problem if both files are same however when the firmware image is updated. the file in /mnt/asturo is newer than the file in /mnt/asturw which became stale as it was kept back with the assumption that the file contents have changed but it was in fact the file attributes that got changed.
>>>
>>> I could not able to find a cleaner approach and thought of checking if there is any clean way of making sure that the files do not become stale. for now I put in a temporary fix that seem to be working which checks on startup and shutdown if the files between /mnt/asturo and /mnt/asturw are same and if yes then remove the files from /mnt/asturw so they do not become stale.
>>>
>>> /etc/init.d/misc
>>> cleanup_asturw() {
>>> local dir1=/mnt/asturo
>>> local dir2=/mnt/asturw
>>>
>>> for newfile in $(find $dir2 -type f); do
>>>   if [ -e "${newfile/${dir2}/${dir1}}" ]; then
>>>        file=${newfile/${dir2}/${dir1}}
>>>        if cmp -s "$file" "$newfile" ; then
>>> #          echo "Cleaning up -> $newfile"
>>>           rm -f $newfile
>>>        fi
>>>   fi
>>> done
>>> }
>>>
>>> mhtgw ~ # stat /etc/common_functions.sh
>>>  File: /etc/common_functions.sh
>>>  Size: 4038       Blocks: 8          IO Block: 1024   regular file
>>> Device: 12h/18d Inode: 34824       Links: 1
>>> Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
>>> Access: 2021-12-12 04:51:16.000000000
>>> Modify: 2021-12-12 04:51:16.000000000
>>> Change: 2021-12-12 20:52:40.000000000
>>>
>>> mhtgw ~ # stat /mnt/asturo/etc/common_functions.sh
>>>  File: /mnt/asturo/etc/common_functions.sh
>>>  Size: 4038       Blocks: 8          IO Block: 4096   regular file
>>> Device: ch/12d Inode: 3360        Links: 1
>>> Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
>>> Access: 2021-12-12 04:51:16.000000000
>>> Modify: 2021-12-12 04:51:16.000000000
>>> Change: 2021-12-12 20:47:12.000000000
>>>
>>> mhtgw ~ # stat /mnt/asturw/etc/common_functions.sh
>>>  File: /mnt/asturw/etc/common_functions.sh
>>>  Size: 4038       Blocks: 8          IO Block: 1024   regular file
>>> Device: 802h/2050d Inode: 34824       Links: 1
>>> Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
>>> Access: 2021-12-12 04:51:16.000000000
>>> Modify: 2021-12-12 04:51:16.000000000
>>> Change: 2021-12-12 20:52:40.000000000
>>>
>>> Any thoughts or ideas are greatly appreciated
>>>
>>> Thanks
>>> Ramesh GK
>>>
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fastlinux-devel&amp;data=04%7C01%7C%7C44ba008229e64146b42408d9be823987%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637750288784797243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=wSZehQcNqKIerC4lLPox91FzaxESzIjlgghmIDS7eqs%3D&amp;reserved=0
>>
>>
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fastlinux-devel&amp;data=04%7C01%7C%7C44ba008229e64146b42408d9be823987%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637750288784797243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=wSZehQcNqKIerC4lLPox91FzaxESzIjlgghmIDS7eqs%3D&amp;reserved=0
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fastlinux-devel&amp;data=04%7C01%7C%7C44ba008229e64146b42408d9be823987%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637750288784797243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=wSZehQcNqKIerC4lLPox91FzaxESzIjlgghmIDS7eqs%3D&amp;reserved=0
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fastlinux-devel&amp;data=04%7C01%7C%7C44ba008229e64146b42408d9be823987%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637750288784797243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=wSZehQcNqKIerC4lLPox91FzaxESzIjlgghmIDS7eqs%3D&amp;reserved=0
>



_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fastlinux-devel&amp;data=04%7C01%7C%7C44ba008229e64146b42408d9be823987%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637750288784797243%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=wSZehQcNqKIerC4lLPox91FzaxESzIjlgghmIDS7eqs%3D&amp;reserved=0

Re: [Astlinux-devel] Duplicated files in ASTURW

[Ramesh GK <ram...@ho...>]

Thanks Lonnie,

I tested the issue with the latest 5.9 and previous version 2.9.8 where there are significant changes for save functionality (2.9.x) and both do not have this issue. there is significant code bloat between 2.7.5 and 2.8.0. I might not be in a position to create a patch. for now i bumped to the latest version of nano and moved on as the difference in size is only 50k.

l gave ne a try earlier and the top menu did not go well for me as it is not my user interface preference for a text editor despite the functionality. I use debian mostly and got used to nano coming from vi world.

Thanks
Ramesh GK
________________________________
From: Lonnie Abelbeck <li...@lo...>
Sent: Monday, December 13, 2021 10:12 AM
To: AstLinux Developers Mailing List <ast...@li...>
Subject: Re: [Astlinux-devel] Duplicated files in ASTURW

Hi Ramesh,

I don't use nano myself ('vi' commands are involuntary to me), though I have replicated your findings.
Even if you make a text change in nano and ^X ...
--
Save modified buffer?  (Answering "No" will DISCARD changes.) N
--
nano will *still* write out the original file!

I would be open to a patch to nano (2.7.5) to fix this awful behavior.


There is a -v (--view) option to nano (View mode (read-only)) which solves the problem.

pbx4 ~ # nano -v /etc/shells

Possibly create a bash alias "view"

pbx4 ~ # alias view='nano -v'

would support nano read-only mode

pbx4 ~ # view /etc/shells


BTW Ramesh, I seem to recall you appreciate "classic" software, the 'ne' editor is much better than nano (IMHO) and 'ne' originated for the Amiga, a Copyright going back to 1992 in the source.  30 years of good stuff, and still maintained.  Included by default in AstLinux.

ne, the nice editor
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fne.di.unimi.it%2F&amp;data=04%7C01%7C%7C1a85e2ca0766408f73b608d9be4b146a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637750051941294120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=9sZo0cvoP0rDyym7GjTrVGlGfgsfbFnIeajKxZnhmPo%3D&amp;reserved=0


Lonnie



> On Dec 13, 2021, at 7:57 AM, Ramesh GK <ram...@ho...> wrote:
>
> Hi Lonnie,
>
> Thanks for checking. you are correct. If i open the file in /mnt/asturo/etc/shells then no corresponding file is getting created in /mnt/asturw but if I open the file /etc/shells then a corresponding file is getting created in /mnt/asturw as it is an overlay of /mnt/asturo for /etc.
>
> i tried to do the same tests that you have done below and figured out the issue. Looks like the issue is occuring because of nano. I use nano for file review or editing mostly. whenever I open the file in nano and close it without making any modifications, it is still trying to save the file i guess. that was the reason a corresponding entry is getting created in /mnt/asturw.
>
> Thanks
> Ramesh GK
> From: Lonnie Abelbeck <li...@lo...>
> Sent: Sunday, December 12, 2021 6:30 PM
> To: AstLinux Developers Mailing List <ast...@li...>
> Subject: Re: [Astlinux-devel] Duplicated files in ASTURW
>
> Hi Ramesh,
>
> >> When I startup the firmware image and open any file in /mnt/asturo (/etc or /stat) that does not have a link to /tmp, it creates a duplicate file in /mnt/asturw.
>
>
> I'm not sure what "open any file" means ... if you open a file on /mnt/asturo read-only then no file should be written to /mnt/asturw.
>
> On the other hand, if you open a file on /mnt/asturo and change the contents, timestamp or write to it, then a corresponding change to /mnt/asturw will occur.
>
> For example:
>
> pbx4 ~ # ls -l /etc/shells
> -rw-r--r--    1 root     root            38 Apr  6  2020 /etc/shells
> pbx4 ~ # ls -l /mnt/asturo/etc/shells
> -rw-r--r--    1 root     root            38 Apr  6  2020 /mnt/asturo/etc/shells
> pbx4 ~ # ls -l /mnt/asturw/etc/shells
> ls: /mnt/asturw/etc/shells: No such file or directory
>
> Then "cat /etc/shells"
>
> pbx4 ~ # cat /etc/shells
>
> pbx4 ~ # ls -l /mnt/asturw/etc/shells
> ls: /mnt/asturw/etc/shells: No such file or directory
>
> Note it is not copied to /mnt/asturw
>
> Also, use an editor and quit without writing ...
>
> pbx4 ~ # vi /etc/shells
> Enter-> :q
>
> pbx4 ~ # ne /etc/shells
> Enter-> <ESC>q or CTL-q
>
> pbx4 ~ # ls -l /mnt/asturw/etc/shells
> ls: /mnt/asturw/etc/shells: No such file or directory
>
> So in summary, try to understand why the /mnt/asturo files are getting written to when you don't want them to.
>
> Lonnie
>
>
> > On Dec 12, 2021, at 3:13 PM, Ramesh GK <ram...@ho...> wrote:
> >
> > Hi,
> >
> > A while back I reached out of using AstLinux as a Home Gateway Appliance. I am working on the same and observed a weird issue. I migrated the entire build system to buildroot-2017.02.11 and the packages merged between (buildroot and AstLinux) and fixed all (mostly) issues. Happy to share the code base but it is still in beta with a working firmware image as I have not tested the Asterisk components.
> >
> > When I startup the firmware image and open any file in /mnt/asturo (/etc or /stat) that does not have a link to /tmp, it creates a duplicate file in /mnt/asturw. This should not pose a problem if both files are same however when the firmware image is updated. the file in /mnt/asturo is newer than the file in /mnt/asturw which became stale as it was kept back with the assumption that the file contents have changed but it was in fact the file attributes that got changed.
> >
> > I could not able to find a cleaner approach and thought of checking if there is any clean way of making sure that the files do not become stale. for now I put in a temporary fix that seem to be working which checks on startup and shutdown if the files between /mnt/asturo and /mnt/asturw are same and if yes then remove the files from /mnt/asturw so they do not become stale.
> >
> > /etc/init.d/misc
> > cleanup_asturw() {
> >  local dir1=/mnt/asturo
> >  local dir2=/mnt/asturw
> >
> >  for newfile in $(find $dir2 -type f); do
> >    if [ -e "${newfile/${dir2}/${dir1}}" ]; then
> >         file=${newfile/${dir2}/${dir1}}
> >         if cmp -s "$file" "$newfile" ; then
> > #          echo "Cleaning up -> $newfile"
> >            rm -f $newfile
> >         fi
> >    fi
> >  done
> > }
> >
> > mhtgw ~ # stat /etc/common_functions.sh
> >   File: /etc/common_functions.sh
> >   Size: 4038       Blocks: 8          IO Block: 1024   regular file
> > Device: 12h/18d Inode: 34824       Links: 1
> > Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
> > Access: 2021-12-12 04:51:16.000000000
> > Modify: 2021-12-12 04:51:16.000000000
> > Change: 2021-12-12 20:52:40.000000000
> >
> > mhtgw ~ # stat /mnt/asturo/etc/common_functions.sh
> >   File: /mnt/asturo/etc/common_functions.sh
> >   Size: 4038       Blocks: 8          IO Block: 4096   regular file
> > Device: ch/12d Inode: 3360        Links: 1
> > Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
> > Access: 2021-12-12 04:51:16.000000000
> > Modify: 2021-12-12 04:51:16.000000000
> > Change: 2021-12-12 20:47:12.000000000
> >
> > mhtgw ~ # stat /mnt/asturw/etc/common_functions.sh
> >   File: /mnt/asturw/etc/common_functions.sh
> >   Size: 4038       Blocks: 8          IO Block: 1024   regular file
> > Device: 802h/2050d Inode: 34824       Links: 1
> > Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
> > Access: 2021-12-12 04:51:16.000000000
> > Modify: 2021-12-12 04:51:16.000000000
> > Change: 2021-12-12 20:52:40.000000000
> >
> > Any thoughts or ideas are greatly appreciated
> >
> > Thanks
> > Ramesh GK
> >
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fastlinux-devel&amp;data=04%7C01%7C%7C1a85e2ca0766408f73b608d9be4b146a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637750051941294120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=5ztPNAh6LFM3xocmfXaUjyrz3Zs%2FgVYaY6djCvZV7D0%3D&amp;reserved=0
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fastlinux-devel&amp;data=04%7C01%7C%7C1a85e2ca0766408f73b608d9be4b146a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637750051941294120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=5ztPNAh6LFM3xocmfXaUjyrz3Zs%2FgVYaY6djCvZV7D0%3D&amp;reserved=0
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fastlinux-devel&amp;data=04%7C01%7C%7C1a85e2ca0766408f73b608d9be4b146a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637750051941294120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=5ztPNAh6LFM3xocmfXaUjyrz3Zs%2FgVYaY6djCvZV7D0%3D&amp;reserved=0



_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fastlinux-devel&amp;data=04%7C01%7C%7C1a85e2ca0766408f73b608d9be4b146a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637750051941294120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=5ztPNAh6LFM3xocmfXaUjyrz3Zs%2FgVYaY6djCvZV7D0%3D&amp;reserved=0

Re: [Astlinux-devel] Duplicated files in ASTURW

[Lonnie A. <li...@lo...>]

I found the problem in our (older) version of nano, fixed with:
https://github.com/astlinux-project/astlinux/commit/40613be0cce1d3d33a7a9a37b3f9ba1d3486aa78

This fix was included with nano-4.3.

The problem occurred when a file was opened, the file writability check actually *wrote* to the file, now simply permission bits are checked.

Tested and seems to fix the problem Ramesh noted.

Lonnie



> On Dec 13, 2021, at 9:12 AM, Lonnie Abelbeck <li...@lo...> wrote:
> 
> Hi Ramesh,
> 
> I don't use nano myself ('vi' commands are involuntary to me), though I have replicated your findings.
> Even if you make a text change in nano and ^X ...
> --
> Save modified buffer?  (Answering "No" will DISCARD changes.) N
> --
> nano will *still* write out the original file!
> 
> I would be open to a patch to nano (2.7.5) to fix this awful behavior.
> 
> 
> There is a -v (--view) option to nano (View mode (read-only)) which solves the problem.
> 
> pbx4 ~ # nano -v /etc/shells 
> 
> Possibly create a bash alias "view"
> 
> pbx4 ~ # alias view='nano -v'
> 
> would support nano read-only mode
> 
> pbx4 ~ # view /etc/shells 
> 
> 
> BTW Ramesh, I seem to recall you appreciate "classic" software, the 'ne' editor is much better than nano (IMHO) and 'ne' originated for the Amiga, a Copyright going back to 1992 in the source.  30 years of good stuff, and still maintained.  Included by default in AstLinux.
> 
> ne, the nice editor
> https://ne.di.unimi.it/
> 
> 
> Lonnie
> 
> 
> 
>> On Dec 13, 2021, at 7:57 AM, Ramesh GK <ram...@ho...> wrote:
>> 
>> Hi Lonnie,
>> 
>> Thanks for checking. you are correct. If i open the file in /mnt/asturo/etc/shells then no corresponding file is getting created in /mnt/asturw but if I open the file /etc/shells then a corresponding file is getting created in /mnt/asturw as it is an overlay of /mnt/asturo for /etc.
>> 
>> i tried to do the same tests that you have done below and figured out the issue. Looks like the issue is occuring because of nano. I use nano for file review or editing mostly. whenever I open the file in nano and close it without making any modifications, it is still trying to save the file i guess. that was the reason a corresponding entry is getting created in /mnt/asturw.
>> 
>> Thanks
>> Ramesh GK
>> From: Lonnie Abelbeck <li...@lo...>
>> Sent: Sunday, December 12, 2021 6:30 PM
>> To: AstLinux Developers Mailing List <ast...@li...>
>> Subject: Re: [Astlinux-devel] Duplicated files in ASTURW
>> 
>> Hi Ramesh,
>> 
>>>> When I startup the firmware image and open any file in /mnt/asturo (/etc or /stat) that does not have a link to /tmp, it creates a duplicate file in /mnt/asturw.
>> 
>> 
>> I'm not sure what "open any file" means ... if you open a file on /mnt/asturo read-only then no file should be written to /mnt/asturw.
>> 
>> On the other hand, if you open a file on /mnt/asturo and change the contents, timestamp or write to it, then a corresponding change to /mnt/asturw will occur.
>> 
>> For example:
>> 
>> pbx4 ~ # ls -l /etc/shells 
>> -rw-r--r--    1 root     root            38 Apr  6  2020 /etc/shells
>> pbx4 ~ # ls -l /mnt/asturo/etc/shells 
>> -rw-r--r--    1 root     root            38 Apr  6  2020 /mnt/asturo/etc/shells
>> pbx4 ~ # ls -l /mnt/asturw/etc/shells 
>> ls: /mnt/asturw/etc/shells: No such file or directory
>> 
>> Then "cat /etc/shells"
>> 
>> pbx4 ~ # cat /etc/shells
>> 
>> pbx4 ~ # ls -l /mnt/asturw/etc/shells 
>> ls: /mnt/asturw/etc/shells: No such file or directory
>> 
>> Note it is not copied to /mnt/asturw
>> 
>> Also, use an editor and quit without writing ...
>> 
>> pbx4 ~ # vi /etc/shells
>> Enter-> :q
>> 
>> pbx4 ~ # ne /etc/shells 
>> Enter-> <ESC>q or CTL-q
>> 
>> pbx4 ~ # ls -l /mnt/asturw/etc/shells 
>> ls: /mnt/asturw/etc/shells: No such file or directory
>> 
>> So in summary, try to understand why the /mnt/asturo files are getting written to when you don't want them to.
>> 
>> Lonnie
>> 
>> 
>>> On Dec 12, 2021, at 3:13 PM, Ramesh GK <ram...@ho...> wrote:
>>> 
>>> Hi,
>>> 
>>> A while back I reached out of using AstLinux as a Home Gateway Appliance. I am working on the same and observed a weird issue. I migrated the entire build system to buildroot-2017.02.11 and the packages merged between (buildroot and AstLinux) and fixed all (mostly) issues. Happy to share the code base but it is still in beta with a working firmware image as I have not tested the Asterisk components.
>>> 
>>> When I startup the firmware image and open any file in /mnt/asturo (/etc or /stat) that does not have a link to /tmp, it creates a duplicate file in /mnt/asturw. This should not pose a problem if both files are same however when the firmware image is updated. the file in /mnt/asturo is newer than the file in /mnt/asturw which became stale as it was kept back with the assumption that the file contents have changed but it was in fact the file attributes that got changed.
>>> 
>>> I could not able to find a cleaner approach and thought of checking if there is any clean way of making sure that the files do not become stale. for now I put in a temporary fix that seem to be working which checks on startup and shutdown if the files between /mnt/asturo and /mnt/asturw are same and if yes then remove the files from /mnt/asturw so they do not become stale.
>>> 
>>> /etc/init.d/misc
>>> cleanup_asturw() {
>>> local dir1=/mnt/asturo
>>> local dir2=/mnt/asturw
>>> 
>>> for newfile in $(find $dir2 -type f); do
>>>   if [ -e "${newfile/${dir2}/${dir1}}" ]; then
>>>        file=${newfile/${dir2}/${dir1}}
>>>        if cmp -s "$file" "$newfile" ; then
>>> #          echo "Cleaning up -> $newfile"
>>>           rm -f $newfile
>>>        fi
>>>   fi
>>> done
>>> }
>>> 
>>> mhtgw ~ # stat /etc/common_functions.sh
>>>  File: /etc/common_functions.sh
>>>  Size: 4038       Blocks: 8          IO Block: 1024   regular file
>>> Device: 12h/18d Inode: 34824       Links: 1
>>> Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
>>> Access: 2021-12-12 04:51:16.000000000
>>> Modify: 2021-12-12 04:51:16.000000000
>>> Change: 2021-12-12 20:52:40.000000000
>>> 
>>> mhtgw ~ # stat /mnt/asturo/etc/common_functions.sh
>>>  File: /mnt/asturo/etc/common_functions.sh
>>>  Size: 4038       Blocks: 8          IO Block: 4096   regular file
>>> Device: ch/12d Inode: 3360        Links: 1
>>> Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
>>> Access: 2021-12-12 04:51:16.000000000
>>> Modify: 2021-12-12 04:51:16.000000000
>>> Change: 2021-12-12 20:47:12.000000000
>>> 
>>> mhtgw ~ # stat /mnt/asturw/etc/common_functions.sh
>>>  File: /mnt/asturw/etc/common_functions.sh
>>>  Size: 4038       Blocks: 8          IO Block: 1024   regular file
>>> Device: 802h/2050d Inode: 34824       Links: 1
>>> Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
>>> Access: 2021-12-12 04:51:16.000000000
>>> Modify: 2021-12-12 04:51:16.000000000
>>> Change: 2021-12-12 20:52:40.000000000
>>> 
>>> Any thoughts or ideas are greatly appreciated
>>> 
>>> Thanks
>>> Ramesh GK
>>> 
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fastlinux-devel&amp;data=04%7C01%7C%7C9db4a4d4f17a4f87777a08d9bdc77ac1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637749486727083129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=7Q4hXhcdxsh8KAFWU3ff9vnN1EzLSu2O%2F8VEYQztaWs%3D&amp;reserved=0
>> 
>> 
>> 
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fastlinux-devel&amp;data=04%7C01%7C%7C9db4a4d4f17a4f87777a08d9bdc77ac1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637749486727083129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=7Q4hXhcdxsh8KAFWU3ff9vnN1EzLSu2O%2F8VEYQztaWs%3D&amp;reserved=0
>> _______________________________________________
>> 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
>