Menu
▾
▴
astlinux-users — AstLinux Users Mailing List
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(91) |
Feb
(111) |
Mar
(226) |
Apr
(65) |
May
(197) |
Jun
(202) |
Jul
(92) |
Aug
(87) |
Sep
(120) |
Oct
(133) |
Nov
(89) |
Dec
(155) |
| 2008 |
Jan
(251) |
Feb
(136) |
Mar
(174) |
Apr
(149) |
May
(56) |
Jun
(32) |
Jul
(36) |
Aug
(171) |
Sep
(245) |
Oct
(244) |
Nov
(218) |
Dec
(272) |
| 2009 |
Jan
(113) |
Feb
(119) |
Mar
(192) |
Apr
(117) |
May
(93) |
Jun
(46) |
Jul
(80) |
Aug
(54) |
Sep
(109) |
Oct
(70) |
Nov
(145) |
Dec
(110) |
| 2010 |
Jan
(137) |
Feb
(87) |
Mar
(45) |
Apr
(157) |
May
(58) |
Jun
(99) |
Jul
(188) |
Aug
(136) |
Sep
(101) |
Oct
(100) |
Nov
(61) |
Dec
(60) |
| 2011 |
Jan
(84) |
Feb
(43) |
Mar
(70) |
Apr
(17) |
May
(69) |
Jun
(28) |
Jul
(43) |
Aug
(21) |
Sep
(151) |
Oct
(120) |
Nov
(84) |
Dec
(101) |
| 2012 |
Jan
(119) |
Feb
(82) |
Mar
(70) |
Apr
(115) |
May
(66) |
Jun
(131) |
Jul
(70) |
Aug
(65) |
Sep
(66) |
Oct
(86) |
Nov
(197) |
Dec
(81) |
| 2013 |
Jan
(65) |
Feb
(48) |
Mar
(32) |
Apr
(68) |
May
(98) |
Jun
(59) |
Jul
(41) |
Aug
(52) |
Sep
(42) |
Oct
(37) |
Nov
(10) |
Dec
(27) |
| 2014 |
Jan
(61) |
Feb
(34) |
Mar
(30) |
Apr
(52) |
May
(45) |
Jun
(40) |
Jul
(28) |
Aug
(9) |
Sep
(39) |
Oct
(69) |
Nov
(55) |
Dec
(19) |
| 2015 |
Jan
(13) |
Feb
(21) |
Mar
(5) |
Apr
(14) |
May
(30) |
Jun
(51) |
Jul
(31) |
Aug
(12) |
Sep
(29) |
Oct
(15) |
Nov
(24) |
Dec
(16) |
| 2016 |
Jan
(62) |
Feb
(76) |
Mar
(30) |
Apr
(43) |
May
(46) |
Jun
(62) |
Jul
(21) |
Aug
(49) |
Sep
(67) |
Oct
(27) |
Nov
(26) |
Dec
(38) |
| 2017 |
Jan
(7) |
Feb
(12) |
Mar
(69) |
Apr
(59) |
May
(54) |
Jun
(40) |
Jul
(76) |
Aug
(82) |
Sep
(92) |
Oct
(51) |
Nov
(32) |
Dec
(30) |
| 2018 |
Jan
(22) |
Feb
(25) |
Mar
(34) |
Apr
(35) |
May
(37) |
Jun
(21) |
Jul
(69) |
Aug
(55) |
Sep
(17) |
Oct
(67) |
Nov
(9) |
Dec
(5) |
| 2019 |
Jan
(19) |
Feb
(12) |
Mar
(15) |
Apr
(19) |
May
|
Jun
(27) |
Jul
(27) |
Aug
(25) |
Sep
(25) |
Oct
(27) |
Nov
(10) |
Dec
(14) |
| 2020 |
Jan
(22) |
Feb
(20) |
Mar
(36) |
Apr
(40) |
May
(52) |
Jun
(35) |
Jul
(21) |
Aug
(32) |
Sep
(71) |
Oct
(27) |
Nov
(11) |
Dec
(16) |
| 2021 |
Jan
(16) |
Feb
(21) |
Mar
(21) |
Apr
(27) |
May
(17) |
Jun
|
Jul
(2) |
Aug
(22) |
Sep
(23) |
Oct
(7) |
Nov
(11) |
Dec
(28) |
| 2022 |
Jan
(23) |
Feb
(18) |
Mar
(9) |
Apr
(15) |
May
(15) |
Jun
(7) |
Jul
(8) |
Aug
(15) |
Sep
(1) |
Oct
|
Nov
(11) |
Dec
(10) |
| 2023 |
Jan
(14) |
Feb
(10) |
Mar
(11) |
Apr
(13) |
May
(2) |
Jun
(30) |
Jul
(1) |
Aug
(15) |
Sep
(13) |
Oct
(3) |
Nov
(25) |
Dec
(5) |
| 2024 |
Jan
(3) |
Feb
(10) |
Mar
(9) |
Apr
|
May
(1) |
Jun
(15) |
Jul
(7) |
Aug
(10) |
Sep
(3) |
Oct
(8) |
Nov
(6) |
Dec
(15) |
| 2025 |
Jan
(3) |
Feb
(1) |
Mar
(7) |
Apr
(5) |
May
(13) |
Jun
(16) |
Jul
(1) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael K. <mic...@ip...> - 2020-04-27 23:11:45
|
Hi Patrick
If its just a host, I think its best to turn off the firewall altogether on the Network Tab and then add your route to rc.elocal.
Regards
Michael Knill
On 28/4/20, 8:53 am, "Patrick Warichet" <pat...@gm...> wrote:
Hello,
I had to migrate my Astlinux appliance from being my
router/firewall/SIP/etc. and hooked it up to a new router/firewall
that I have to test. I like to keep using Astlinux for several
services (DNScrypt, DHCP, SIP, etc.) that are not available on the
firewall but I am facing 2 issues.
I do not want to use the EXTIF anymore (since the system is only a
host and connected to my local LAN) and just use the INTIF, but even
disconnected the EXTIF (eth0 in my case) is used for the default route
even when I configure "ip route add to 0.0.0.0/0 via 192.168.1.1 dev
eth1" in rc.elocal.
Another issue, how to change the default gw parameter from dnsmasq ?
I added "dhcp-option=lan,option:router,192.168.1.1" in dnsmasq.static
but it keeps on using the local IP address of the eth1 interface in
the lease it sends out (confirmed by looking at dnsmasq.conf).
Thank you for your help
/Patrick
_______________________________________________
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: Patrick W. <pat...@gm...> - 2020-04-27 22:53:13
|
Hello, I had to migrate my Astlinux appliance from being my router/firewall/SIP/etc. and hooked it up to a new router/firewall that I have to test. I like to keep using Astlinux for several services (DNScrypt, DHCP, SIP, etc.) that are not available on the firewall but I am facing 2 issues. I do not want to use the EXTIF anymore (since the system is only a host and connected to my local LAN) and just use the INTIF, but even disconnected the EXTIF (eth0 in my case) is used for the default route even when I configure "ip route add to 0.0.0.0/0 via 192.168.1.1 dev eth1" in rc.elocal. Another issue, how to change the default gw parameter from dnsmasq ? I added "dhcp-option=lan,option:router,192.168.1.1" in dnsmasq.static but it keeps on using the local IP address of the eth1 interface in the lease it sends out (confirmed by looking at dnsmasq.conf). Thank you for your help /Patrick |
|
From: Michael K. <mic...@ip...> - 2020-04-22 11:23:59
|
Looks like this problem was bad power. I was told by the local IT Guy that there are regular brownouts so I installed a UPS. No more problems since doing so.
Seems like APU's don't like low voltage scenarios.
Thanks for your help.
Regards
Michael Knill
On 13/4/20, 1:05 pm, "Michael Knill" <mic...@ip...> wrote:
Yes could be but very unusual. I have never had this problem with any other APU.
Maybe I will look for a good surge suppressor.
Regards
Michael Knill
On 13/4/20, 12:47 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Interesting, maybe bad power (spikes, noise, etc.)
Test with a UPS attached or good surge suppresser.
Lonnie
> On Apr 12, 2020, at 9:17 PM, Michael Knill <mic...@ip...> wrote:
>
> Hi Lonnie
>
> I have replaced the hardware already and it did EXACTLY the same thing ☹
>
> Regards
> Michael Knill
>
> On 13/4/20, 12:15 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>
>
>
>> On Apr 12, 2020, at 7:03 PM, Michael Knill <mic...@ip...> wrote:
>>
>> May not have anything to do with Astlinux but I have a site which completely locks up e.g. cannot even communicate using serial port.
>> On reboot its fine but there is nothing in the logs but the bootup messages.
>> So far I have replaced the hardware with new storage as well and power supply and it is still doing it.
>>
>> It is currently running Astlinux 1.3.7.1 which has been running fine on another APU2 but its only been 8 days.
>>
>> Any ideas what I can do next?
>>
>> Regards
>> Michael Knill
>
> Sounds like an APU2 hardware issue.
>
> Maybe Pascal will give you a replacement.
>
> Lonnie
>
>
>
>
> _______________________________________________
> 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-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: Michael K. <mic...@ip...> - 2020-04-22 11:14:14
|
Hmm for some reason there is a lot less in /proc/net than my other systems.
I cant really see why there is a difference.
Regards
Michael Knill
On 22/4/20, 7:48 pm, "Michael Keuter" <li...@mk...> wrote:
> Am 22.04.2020 um 11:43 schrieb Michael Knill <mic...@ip...>:
>
> Even though I don't use SNMP, I thought I would add the default configuration from the doco just in case I wanted it one day.
> A couple of my systems are now complaining as follows:
> Apr 22 16:32:38 1280-IPCPROD-GW1 daemon.err snmpd[7707]: ipaddress_linux: could not open /proc/net/if_inet6: No such file or directory
> Apr 22 16:32:41 1280-IPCPROD-GW1 daemon.err snmpd[7707]: ipaddress_linux: could not open /proc/net/if_inet6: No such file or directory
> Apr 22 16:32:44 1280-IPCPROD-GW1 daemon.err snmpd[7707]: ipaddress_linux: could not open /proc/net/if_inet6: No such file or directory
>
> Any idea what it could be? Note these systems were built new whereas other systems which are working fine were upgraded!
> I'm thinking of just turning it off.
>
> Regards
> Michael Knill
Hi Michael,
does "/proc/net/if_inet6" exist on this system?
On my systems it does exist.
Michael
http://www.mksolutions.info
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Michael K. <li...@mk...> - 2020-04-22 09:48:32
|
> Am 22.04.2020 um 11:43 schrieb Michael Knill <mic...@ip...>: > > Even though I don't use SNMP, I thought I would add the default configuration from the doco just in case I wanted it one day. > A couple of my systems are now complaining as follows: > Apr 22 16:32:38 1280-IPCPROD-GW1 daemon.err snmpd[7707]: ipaddress_linux: could not open /proc/net/if_inet6: No such file or directory > Apr 22 16:32:41 1280-IPCPROD-GW1 daemon.err snmpd[7707]: ipaddress_linux: could not open /proc/net/if_inet6: No such file or directory > Apr 22 16:32:44 1280-IPCPROD-GW1 daemon.err snmpd[7707]: ipaddress_linux: could not open /proc/net/if_inet6: No such file or directory > > Any idea what it could be? Note these systems were built new whereas other systems which are working fine were upgraded! > I'm thinking of just turning it off. > > Regards > Michael Knill Hi Michael, does "/proc/net/if_inet6" exist on this system? On my systems it does exist. Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2020-04-22 09:43:38
|
Even though I don't use SNMP, I thought I would add the default configuration from the doco just in case I wanted it one day. A couple of my systems are now complaining as follows: Apr 22 16:32:38 1280-IPCPROD-GW1 daemon.err snmpd[7707]: ipaddress_linux: could not open /proc/net/if_inet6: No such file or directory Apr 22 16:32:41 1280-IPCPROD-GW1 daemon.err snmpd[7707]: ipaddress_linux: could not open /proc/net/if_inet6: No such file or directory Apr 22 16:32:44 1280-IPCPROD-GW1 daemon.err snmpd[7707]: ipaddress_linux: could not open /proc/net/if_inet6: No such file or directory Any idea what it could be? Note these systems were built new whereas other systems which are working fine were upgraded! I'm thinking of just turning it off. Regards Michael Knill |
|
From: Michael K. <mic...@ip...> - 2020-04-18 23:54:02
|
Thanks Lonnie
Regards
Michael Knill
On 18/4/20, 11:23 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
BTW, the config I quoted was not complete, the rest:
=====================
...
# When this plugin's status is called, if the default external IPv4 address
# has changed, the NAT_LOOPBACK_DNAT and NAT_LOOPBACK_SNAT chains will be
# updated with the new address. Set NAT_LOOPBACK_UPDATE_ON_STATUS to "0"
# to disable this automatic update on status.
#
# Example:
# $ arno-iptables-firewall status-plugins nat-loopback
#
# Defaults to update on status if not set to "0"
# ------------------------------------------------------------------------------
NAT_LOOPBACK_UPDATE_ON_STATUS=1
=====================
which is important to point out, since the external IPv4 address is needed in the iptables rules for this to work, as such if you have a dynamic address you need to call:
--
arno-iptables-firewall status-plugins nat-loopback
--
whenever the external address changes.
If you have a static external IPv4 address, you are golden by default.
Lonnie
> On Apr 17, 2020, at 4:41 PM, Michael Knill <mic...@ip...> wrote:
>
> Well there you go. Why haven’t I seen this before!
> Can you see any reason why I wouldn't turn this on by default for all my sites?
>
> Thanks so much.
>
> Regards
> Michael Knill
>
> On 18/4/20, 7:30 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
>
>
>> On Apr 17, 2020, at 4:22 PM, Michael Knill <mic...@ip...> wrote:
>>
>> Hi Group
>>
>> I should know this but is it possible for Astlinux to do hairpin NAT e.g. they can do http://<external IP>:<external port> connecting to an internal host both internally and externally?
>> If not then I assume the only way is to use DNS and resolve to the internal host address when internal.
>>
>> Thanks
>
> The "nat-loopback" plugin should do what you want.
>
> =====================
> # ------------------------------------------------------------------------------
> # -= Arno's iptables firewall - NAT Loopback plugin =-
> # ------------------------------------------------------------------------------
>
> # To actually enable this plugin make ENABLED=1:
> # ------------------------------------------------------------------------------
> ENABLED=0
>
> # NAT Loopback for local nets using existing NAT_FORWARD_TCP and NAT_FORWARD_UDP
> # rules.
> # Note: The default external IPv4 address is obtained from the first
> # interface defined in the EXT_IF variable.
> #
> # Limit local nets by defining NAT_LOOPBACK_NET, a space separated list.
> # Defaults to NAT_INTERNAL_NET if not defined.
> #
> # Example:
> # NAT_LOOPBACK_NET="192.168.1.0/24"
> # (IPv4 Only)
> # ------------------------------------------------------------------------------
> NAT_LOOPBACK_NET=""
>
> # When local servers are in another LAN they are unreachable (by default) unless
> # FORWARD rules are created. When NAT_LOOPBACK_FORWARD is set to "1" the
> # FORWARD rules to the servers are created for all subnets in NAT_LOOPBACK_NET.
> #
> # Defaults to no added forwards if not set to "1"
> # ------------------------------------------------------------------------------
> NAT_LOOPBACK_FORWARD=0
> =====================
>
> Lonnie
>
>
>
>
>
> _______________________________________________
> 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-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...> - 2020-04-18 13:23:12
|
Hi Michael, BTW, the config I quoted was not complete, the rest: ===================== ... # When this plugin's status is called, if the default external IPv4 address # has changed, the NAT_LOOPBACK_DNAT and NAT_LOOPBACK_SNAT chains will be # updated with the new address. Set NAT_LOOPBACK_UPDATE_ON_STATUS to "0" # to disable this automatic update on status. # # Example: # $ arno-iptables-firewall status-plugins nat-loopback # # Defaults to update on status if not set to "0" # ------------------------------------------------------------------------------ NAT_LOOPBACK_UPDATE_ON_STATUS=1 ===================== which is important to point out, since the external IPv4 address is needed in the iptables rules for this to work, as such if you have a dynamic address you need to call: -- arno-iptables-firewall status-plugins nat-loopback -- whenever the external address changes. If you have a static external IPv4 address, you are golden by default. Lonnie > On Apr 17, 2020, at 4:41 PM, Michael Knill <mic...@ip...> wrote: > > Well there you go. Why haven’t I seen this before! > Can you see any reason why I wouldn't turn this on by default for all my sites? > > Thanks so much. > > Regards > Michael Knill > > On 18/4/20, 7:30 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > > >> On Apr 17, 2020, at 4:22 PM, Michael Knill <mic...@ip...> wrote: >> >> Hi Group >> >> I should know this but is it possible for Astlinux to do hairpin NAT e.g. they can do http://<external IP>:<external port> connecting to an internal host both internally and externally? >> If not then I assume the only way is to use DNS and resolve to the internal host address when internal. >> >> Thanks > > The "nat-loopback" plugin should do what you want. > > ===================== > # ------------------------------------------------------------------------------ > # -= Arno's iptables firewall - NAT Loopback plugin =- > # ------------------------------------------------------------------------------ > > # To actually enable this plugin make ENABLED=1: > # ------------------------------------------------------------------------------ > ENABLED=0 > > # NAT Loopback for local nets using existing NAT_FORWARD_TCP and NAT_FORWARD_UDP > # rules. > # Note: The default external IPv4 address is obtained from the first > # interface defined in the EXT_IF variable. > # > # Limit local nets by defining NAT_LOOPBACK_NET, a space separated list. > # Defaults to NAT_INTERNAL_NET if not defined. > # > # Example: > # NAT_LOOPBACK_NET="192.168.1.0/24" > # (IPv4 Only) > # ------------------------------------------------------------------------------ > NAT_LOOPBACK_NET="" > > # When local servers are in another LAN they are unreachable (by default) unless > # FORWARD rules are created. When NAT_LOOPBACK_FORWARD is set to "1" the > # FORWARD rules to the servers are created for all subnets in NAT_LOOPBACK_NET. > # > # Defaults to no added forwards if not set to "1" > # ------------------------------------------------------------------------------ > NAT_LOOPBACK_FORWARD=0 > ===================== > > Lonnie > > > > > > _______________________________________________ > 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...> - 2020-04-17 21:47:39
|
As with opening any firewall paths, if you don't need it, don't turn it on. Lonnie > On Apr 17, 2020, at 4:41 PM, Michael Knill <mic...@ip...> wrote: > > Well there you go. Why haven’t I seen this before! > Can you see any reason why I wouldn't turn this on by default for all my sites? > > Thanks so much. > > Regards > Michael Knill > > On 18/4/20, 7:30 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > > >> On Apr 17, 2020, at 4:22 PM, Michael Knill <mic...@ip...> wrote: >> >> Hi Group >> >> I should know this but is it possible for Astlinux to do hairpin NAT e.g. they can do http://<external IP>:<external port> connecting to an internal host both internally and externally? >> If not then I assume the only way is to use DNS and resolve to the internal host address when internal. >> >> Thanks > > The "nat-loopback" plugin should do what you want. > > ===================== > # ------------------------------------------------------------------------------ > # -= Arno's iptables firewall - NAT Loopback plugin =- > # ------------------------------------------------------------------------------ > > # To actually enable this plugin make ENABLED=1: > # ------------------------------------------------------------------------------ > ENABLED=0 > > # NAT Loopback for local nets using existing NAT_FORWARD_TCP and NAT_FORWARD_UDP > # rules. > # Note: The default external IPv4 address is obtained from the first > # interface defined in the EXT_IF variable. > # > # Limit local nets by defining NAT_LOOPBACK_NET, a space separated list. > # Defaults to NAT_INTERNAL_NET if not defined. > # > # Example: > # NAT_LOOPBACK_NET="192.168.1.0/24" > # (IPv4 Only) > # ------------------------------------------------------------------------------ > NAT_LOOPBACK_NET="" > > # When local servers are in another LAN they are unreachable (by default) unless > # FORWARD rules are created. When NAT_LOOPBACK_FORWARD is set to "1" the > # FORWARD rules to the servers are created for all subnets in NAT_LOOPBACK_NET. > # > # Defaults to no added forwards if not set to "1" > # ------------------------------------------------------------------------------ > NAT_LOOPBACK_FORWARD=0 > ===================== > > Lonnie > > > > > > _______________________________________________ > 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: Michael K. <mic...@ip...> - 2020-04-17 21:41:28
|
Well there you go. Why haven’t I seen this before!
Can you see any reason why I wouldn't turn this on by default for all my sites?
Thanks so much.
Regards
Michael Knill
On 18/4/20, 7:30 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> On Apr 17, 2020, at 4:22 PM, Michael Knill <mic...@ip...> wrote:
>
> Hi Group
>
> I should know this but is it possible for Astlinux to do hairpin NAT e.g. they can do http://<external IP>:<external port> connecting to an internal host both internally and externally?
> If not then I assume the only way is to use DNS and resolve to the internal host address when internal.
>
> Thanks
The "nat-loopback" plugin should do what you want.
=====================
# ------------------------------------------------------------------------------
# -= Arno's iptables firewall - NAT Loopback plugin =-
# ------------------------------------------------------------------------------
# To actually enable this plugin make ENABLED=1:
# ------------------------------------------------------------------------------
ENABLED=0
# NAT Loopback for local nets using existing NAT_FORWARD_TCP and NAT_FORWARD_UDP
# rules.
# Note: The default external IPv4 address is obtained from the first
# interface defined in the EXT_IF variable.
#
# Limit local nets by defining NAT_LOOPBACK_NET, a space separated list.
# Defaults to NAT_INTERNAL_NET if not defined.
#
# Example:
# NAT_LOOPBACK_NET="192.168.1.0/24"
# (IPv4 Only)
# ------------------------------------------------------------------------------
NAT_LOOPBACK_NET=""
# When local servers are in another LAN they are unreachable (by default) unless
# FORWARD rules are created. When NAT_LOOPBACK_FORWARD is set to "1" the
# FORWARD rules to the servers are created for all subnets in NAT_LOOPBACK_NET.
#
# Defaults to no added forwards if not set to "1"
# ------------------------------------------------------------------------------
NAT_LOOPBACK_FORWARD=0
=====================
Lonnie
_______________________________________________
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...> - 2020-04-17 21:29:45
|
> On Apr 17, 2020, at 4:22 PM, Michael Knill <mic...@ip...> wrote: > > Hi Group > > I should know this but is it possible for Astlinux to do hairpin NAT e.g. they can do http://<external IP>:<external port> connecting to an internal host both internally and externally? > If not then I assume the only way is to use DNS and resolve to the internal host address when internal. > > Thanks The "nat-loopback" plugin should do what you want. ===================== # ------------------------------------------------------------------------------ # -= Arno's iptables firewall - NAT Loopback plugin =- # ------------------------------------------------------------------------------ # To actually enable this plugin make ENABLED=1: # ------------------------------------------------------------------------------ ENABLED=0 # NAT Loopback for local nets using existing NAT_FORWARD_TCP and NAT_FORWARD_UDP # rules. # Note: The default external IPv4 address is obtained from the first # interface defined in the EXT_IF variable. # # Limit local nets by defining NAT_LOOPBACK_NET, a space separated list. # Defaults to NAT_INTERNAL_NET if not defined. # # Example: # NAT_LOOPBACK_NET="192.168.1.0/24" # (IPv4 Only) # ------------------------------------------------------------------------------ NAT_LOOPBACK_NET="" # When local servers are in another LAN they are unreachable (by default) unless # FORWARD rules are created. When NAT_LOOPBACK_FORWARD is set to "1" the # FORWARD rules to the servers are created for all subnets in NAT_LOOPBACK_NET. # # Defaults to no added forwards if not set to "1" # ------------------------------------------------------------------------------ NAT_LOOPBACK_FORWARD=0 ===================== Lonnie |
|
From: Michael K. <mic...@ip...> - 2020-04-17 21:22:34
|
Hi Group I should know this but is it possible for Astlinux to do hairpin NAT e.g. they can do http://<external IP>:<external port> connecting to an internal host both internally and externally? If not then I assume the only way is to use DNS and resolve to the internal host address when internal. Thanks Regards Michael Knill |
|
From: Michael K. <mic...@ip...> - 2020-04-13 03:05:14
|
Yes could be but very unusual. I have never had this problem with any other APU.
Maybe I will look for a good surge suppressor.
Regards
Michael Knill
On 13/4/20, 12:47 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Interesting, maybe bad power (spikes, noise, etc.)
Test with a UPS attached or good surge suppresser.
Lonnie
> On Apr 12, 2020, at 9:17 PM, Michael Knill <mic...@ip...> wrote:
>
> Hi Lonnie
>
> I have replaced the hardware already and it did EXACTLY the same thing ☹
>
> Regards
> Michael Knill
>
> On 13/4/20, 12:15 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>
>
>
>> On Apr 12, 2020, at 7:03 PM, Michael Knill <mic...@ip...> wrote:
>>
>> May not have anything to do with Astlinux but I have a site which completely locks up e.g. cannot even communicate using serial port.
>> On reboot its fine but there is nothing in the logs but the bootup messages.
>> So far I have replaced the hardware with new storage as well and power supply and it is still doing it.
>>
>> It is currently running Astlinux 1.3.7.1 which has been running fine on another APU2 but its only been 8 days.
>>
>> Any ideas what I can do next?
>>
>> Regards
>> Michael Knill
>
> Sounds like an APU2 hardware issue.
>
> Maybe Pascal will give you a replacement.
>
> Lonnie
>
>
>
>
> _______________________________________________
> 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-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...> - 2020-04-13 02:46:58
|
Interesting, maybe bad power (spikes, noise, etc.) Test with a UPS attached or good surge suppresser. Lonnie > On Apr 12, 2020, at 9:17 PM, Michael Knill <mic...@ip...> wrote: > > Hi Lonnie > > I have replaced the hardware already and it did EXACTLY the same thing ☹ > > Regards > Michael Knill > > On 13/4/20, 12:15 pm, "Lonnie Abelbeck" <li...@lo...> wrote: > > > >> On Apr 12, 2020, at 7:03 PM, Michael Knill <mic...@ip...> wrote: >> >> May not have anything to do with Astlinux but I have a site which completely locks up e.g. cannot even communicate using serial port. >> On reboot its fine but there is nothing in the logs but the bootup messages. >> So far I have replaced the hardware with new storage as well and power supply and it is still doing it. >> >> It is currently running Astlinux 1.3.7.1 which has been running fine on another APU2 but its only been 8 days. >> >> Any ideas what I can do next? >> >> Regards >> Michael Knill > > Sounds like an APU2 hardware issue. > > Maybe Pascal will give you a replacement. > > Lonnie > > > > > _______________________________________________ > 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: Michael K. <mic...@ip...> - 2020-04-13 02:17:31
|
Hi Lonnie
I have replaced the hardware already and it did EXACTLY the same thing ☹
Regards
Michael Knill
On 13/4/20, 12:15 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
> On Apr 12, 2020, at 7:03 PM, Michael Knill <mic...@ip...> wrote:
>
> May not have anything to do with Astlinux but I have a site which completely locks up e.g. cannot even communicate using serial port.
> On reboot its fine but there is nothing in the logs but the bootup messages.
> So far I have replaced the hardware with new storage as well and power supply and it is still doing it.
>
> It is currently running Astlinux 1.3.7.1 which has been running fine on another APU2 but its only been 8 days.
>
> Any ideas what I can do next?
>
> Regards
> Michael Knill
Sounds like an APU2 hardware issue.
Maybe Pascal will give you a replacement.
Lonnie
_______________________________________________
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...> - 2020-04-13 02:14:35
|
> On Apr 12, 2020, at 7:03 PM, Michael Knill <mic...@ip...> wrote: > > May not have anything to do with Astlinux but I have a site which completely locks up e.g. cannot even communicate using serial port. > On reboot its fine but there is nothing in the logs but the bootup messages. > So far I have replaced the hardware with new storage as well and power supply and it is still doing it. > > It is currently running Astlinux 1.3.7.1 which has been running fine on another APU2 but its only been 8 days. > > Any ideas what I can do next? > > Regards > Michael Knill Sounds like an APU2 hardware issue. Maybe Pascal will give you a replacement. Lonnie |
|
From: Michael K. <mic...@ip...> - 2020-04-13 00:04:02
|
May not have anything to do with Astlinux but I have a site which completely locks up e.g. cannot even communicate using serial port. On reboot its fine but there is nothing in the logs but the bootup messages. So far I have replaced the hardware with new storage as well and power supply and it is still doing it. It is currently running Astlinux 1.3.7.1 which has been running fine on another APU2 but its only been 8 days. Any ideas what I can do next? Regards Michael Knill |
|
From: David K. <da...@ke...> - 2020-04-09 20:55:49
|
Thanks lonnie, I will have to find some time to do further investigating. Kind of tough now-a-days with stay at home order as there is almost never a time I can fiddle without upsetting someone. I only have the IPv4 address setup, so I'll try adding the IPv6 as well. David On Wed, Apr 8, 2020 at 8:48 PM Lonnie Abelbeck <li...@lo...> wrote: > David, another thing, I use both IPv4 and IP6 in my Cloudflare DNS-TLS > config ... > -- > 2606:4700:4700::1111~cloudflare-dns.com > 1.1.1.1~cloudflare-dns.com > -- > > That should add some resilience to upstream network routing issues. > > Lonnie > > > > > On Apr 8, 2020, at 7:39 PM, Lonnie Abelbeck <li...@lo...> > wrote: > > > > Hi David, > > > > Just so happened I had a very short outage here as well, just long > enough for failover to kick in. > > > > No problem with DNS-TLS DNS. > > > > Possibly your outage had some issue with upstream routes as well. > > > > Lonnie > > > > > > > >> On Apr 8, 2020, at 2:52 PM, Lonnie Abelbeck <li...@lo...> > wrote: > >> > >> Hi David, > >> > >> That should work as expected. > >> > >> The DNS-TLS (stubby) should timeout and retry after a short period of > time. > >> > >> I vaguely recall testing this, and it did take a little while for DNS > to work again, but it worked, IIRC. > >> > >> Lonnie > >> > >> > >>> On Apr 8, 2020, at 1:46 PM, David Kerr <Da...@Ke...> wrote: > >>> > >>> Yesterday Comcast/Xfinity went down for a few minutes and my Astlinux > did a failover to my cellular link. However it looks like my DNS did not > survive the failover... name resolution did not work after the primary link > was restored (and possibly was not working when on the secondary during > failover, but as I'm not so sure about that). I have DNS-TLS configured > with 1.1.1.1. > >>> > >>> Any ideas? Is DNS-TLS expected to survive a change in interface/IP > address? I tried a restart of DNS-TLS after the primary link was restored > but that did not seem to work... so I rebooted Astlinux (too many people in > the house now-a-days for me to spend any time troubleshooting on everyone's > primary internet connection!). > >>> > >>> Thoughts? > >>> David > >>> > >>> > >>> _______________________________________________ > >>> 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-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...> - 2020-04-09 00:48:53
|
David, another thing, I use both IPv4 and IP6 in my Cloudflare DNS-TLS config ... -- 2606:4700:4700::1111~cloudflare-dns.com 1.1.1.1~cloudflare-dns.com -- That should add some resilience to upstream network routing issues. Lonnie > On Apr 8, 2020, at 7:39 PM, Lonnie Abelbeck <li...@lo...> wrote: > > Hi David, > > Just so happened I had a very short outage here as well, just long enough for failover to kick in. > > No problem with DNS-TLS DNS. > > Possibly your outage had some issue with upstream routes as well. > > Lonnie > > > >> On Apr 8, 2020, at 2:52 PM, Lonnie Abelbeck <li...@lo...> wrote: >> >> Hi David, >> >> That should work as expected. >> >> The DNS-TLS (stubby) should timeout and retry after a short period of time. >> >> I vaguely recall testing this, and it did take a little while for DNS to work again, but it worked, IIRC. >> >> Lonnie >> >> >>> On Apr 8, 2020, at 1:46 PM, David Kerr <Da...@Ke...> wrote: >>> >>> Yesterday Comcast/Xfinity went down for a few minutes and my Astlinux did a failover to my cellular link. However it looks like my DNS did not survive the failover... name resolution did not work after the primary link was restored (and possibly was not working when on the secondary during failover, but as I'm not so sure about that). I have DNS-TLS configured with 1.1.1.1. >>> >>> Any ideas? Is DNS-TLS expected to survive a change in interface/IP address? I tried a restart of DNS-TLS after the primary link was restored but that did not seem to work... so I rebooted Astlinux (too many people in the house now-a-days for me to spend any time troubleshooting on everyone's primary internet connection!). >>> >>> Thoughts? >>> David >>> >>> >>> _______________________________________________ >>> 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-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...> - 2020-04-09 00:39:42
|
Hi David, Just so happened I had a very short outage here as well, just long enough for failover to kick in. No problem with DNS-TLS DNS. Possibly your outage had some issue with upstream routes as well. Lonnie > On Apr 8, 2020, at 2:52 PM, Lonnie Abelbeck <li...@lo...> wrote: > > Hi David, > > That should work as expected. > > The DNS-TLS (stubby) should timeout and retry after a short period of time. > > I vaguely recall testing this, and it did take a little while for DNS to work again, but it worked, IIRC. > > Lonnie > > >> On Apr 8, 2020, at 1:46 PM, David Kerr <Da...@Ke...> wrote: >> >> Yesterday Comcast/Xfinity went down for a few minutes and my Astlinux did a failover to my cellular link. However it looks like my DNS did not survive the failover... name resolution did not work after the primary link was restored (and possibly was not working when on the secondary during failover, but as I'm not so sure about that). I have DNS-TLS configured with 1.1.1.1. >> >> Any ideas? Is DNS-TLS expected to survive a change in interface/IP address? I tried a restart of DNS-TLS after the primary link was restored but that did not seem to work... so I rebooted Astlinux (too many people in the house now-a-days for me to spend any time troubleshooting on everyone's primary internet connection!). >> >> Thoughts? >> David >> >> >> _______________________________________________ >> 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...> - 2020-04-08 19:52:16
|
Hi David, That should work as expected. The DNS-TLS (stubby) should timeout and retry after a short period of time. I vaguely recall testing this, and it did take a little while for DNS to work again, but it worked, IIRC. Lonnie > On Apr 8, 2020, at 1:46 PM, David Kerr <Da...@Ke...> wrote: > > Yesterday Comcast/Xfinity went down for a few minutes and my Astlinux did a failover to my cellular link. However it looks like my DNS did not survive the failover... name resolution did not work after the primary link was restored (and possibly was not working when on the secondary during failover, but as I'm not so sure about that). I have DNS-TLS configured with 1.1.1.1. > > Any ideas? Is DNS-TLS expected to survive a change in interface/IP address? I tried a restart of DNS-TLS after the primary link was restored but that did not seem to work... so I rebooted Astlinux (too many people in the house now-a-days for me to spend any time troubleshooting on everyone's primary internet connection!). > > Thoughts? > David > > > _______________________________________________ > 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: David K. <da...@ke...> - 2020-04-08 18:46:38
|
Yesterday Comcast/Xfinity went down for a few minutes and my Astlinux did a failover to my cellular link. However it looks like my DNS did not survive the failover... name resolution did not work after the primary link was restored (and possibly was not working when on the secondary during failover, but as I'm not so sure about that). I have DNS-TLS configured with 1.1.1.1. Any ideas? Is DNS-TLS expected to survive a change in interface/IP address? I tried a restart of DNS-TLS after the primary link was restored but that did not seem to work... so I rebooted Astlinux (too many people in the house now-a-days for me to spend any time troubleshooting on everyone's primary internet connection!). Thoughts? David |
|
From: Michael K. <mic...@ip...> - 2020-04-08 03:14:40
|
Doh! Sorry for that.
And I just realised our custom status page for this version is incorrect.
My bad totally ☹
Thanks for your help.
Regards
Michael Knill
On 8/4/20, 1:09 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Michael,
Your .sha1 file for genx88_64 (video) is incorrect
$ curl -sSfL http://download.ipcsolutions.com.au/13se/genx86_64/astlinux-1.3.7.1.tar.gz | shasum
cfde4639295579c540240498ee0fc979bbd53858 -
$ curl -sSfL http://download.ipcsolutions.com.au/13se/genx86_64/astlinux-1.3.7.1.tar.gz.sha1
bfa72ef0057b204996eda91bfaded4b132655047 astlinux-1.3.7.1.tar.gz
But for your genx88_64-serial (serial) it is OK
$ curl -sSfL http://download.ipcsolutions.com.au/13se/genx86_64-serial/astlinux-1.3.7.1.tar.gz | shasum
e985d6f2755b122908d969e4b681a67106ada348 -
$ curl -sSfL http://download.ipcsolutions.com.au/13se/genx86_64-serial/astlinux-1.3.7.1.tar.gz.sha1
e985d6f2755b122908d969e4b681a67106ada348 astlinux-1.3.7.1.tar.gz
So the Qotom has a genx88_64 (video) image.
Lonnie
> On Apr 7, 2020, at 9:03 PM, Michael Knill <mic...@ip...> wrote:
>
> Hi Guys. I'm having this problem again Grrr.
> I have a Qotom that has been built with a board type of genx86_64-serial. Could this be what is breaking it?
>
> I tried to upgrade to VGA:
> 3066-Detlevs-CM1 kd # upgrade-run-image upgrade http://download.ipcsolutions.com.au/13se 64
> Firmware verification failed.
>
> Then just normal:
> 3066-Detlevs-CM1 kd # upgrade-run-image upgrade http://download.ipcsolutions.com.au/13se
> Firmware verification failed.
>
> I haven’t tried the official repository yet as its on 1.3.8 and I don't want to go there yet.
>
> Any ideas why I'm getting this and what I can do about it?
>
> Regards
> Michael Knill
>
> From: Michael Knill <mic...@ip...>
> Reply to: AstLinux List <ast...@li...>
> Date: Monday, 20 January 2020 at 5:43 am
> To: AstLinux List <ast...@li...>
> Subject: Re: [Astlinux-users] Getting 'Firmware verification failed' on some boxes when I try to upgrade
>
> Thanks Lonnie. Private repo it is.
> Hmm good idea Michael. I think I will do that. Thanks.
>
> Regards
> Michael Knill
>
> From: Michael Keuter <li...@mk...>
> Reply to: AstLinux List <ast...@li...>
> Date: Monday, 20 January 2020 at 3:48 am
> To: AstLinux List <ast...@li...>
> Subject: Re: [Astlinux-users] Getting 'Firmware verification failed' on some boxes when I try to upgrade
>
>
>
>
>
>> Am 19.01.2020 um 07:56 schrieb Michael Knill <mic...@ip...>:
>>
>> Maybe one day!
>>
>> So any chance you would consider putting previous releases into their own subdirectory?
>> E.g. current release is http://mirror.astlinux-project.org/ast13se-firmware-1.x/<board type> or specific version is http://mirror.astlinux-project.org/ast13se-firmware-1.x/<board type>/<version>
>
> If you would do it the other way round for your own repo:
>
> .../version/board-type/
>
> then you could include the version number in your "Repository URL" in the Prefs and it would work as before.
> You would need a "board-type" folder structure for every release in that case.
>
>
>
>> I wouldn't bother with my own repository if that was the case!
>>
>> Regards
>> Michael Knill
>>
>> On 19/1/20, 9:48 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>>
>> Hi Michael,
>>
>>
>>
>>> I have been using a Private Repository ...
>>
>>
>>
>>> I just copy in the upgrade files from the official Astlinux Repository.
>>
>> Ahh, OK ... simple enough.
>>
>> I was thinking you were somehow adding your "special sauce" to the official images to create custom images, which I did not know how you could do that without building images yourself.
>>
>> Lonnie
>>
>>
>>
>>
>>
>>> On Jan 18, 2020, at 4:40 PM, Michael Knill <mic...@ip...> wrote:
>>>
>>> Thanks guys
>>>
>>> I was not aware of that doco to convert to a vm board type. Excellent I will do this and then it should all work.
>>>
>>> Lonnie I have been using a Private Repository for years now and have never had a problem. The main reason for using it was purely to determine the 'Current' release for my systems and the ability to upgrade(or downgrade) to any version I want by appending the version directory to the repository URL. I just copy in the upgrade files from the official Astlinux Repository.
>>> I would be happy to use the Astlinux repository if I could do the above.
>>>
>>> Regards
>>> Michael Knill
>>>
>>> On 19/1/20, 1:36 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>>>
>>>
>>>
>>>
>>>
>>>> On Jan 18, 2020, at 6:06 AM, Michael Keuter <li...@mk...> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Am 18.01.2020 um 01:15 schrieb Michael Knill <mic...@ip...>:
>>>>>
>>>>> Hi group
>>>>>
>>>>> Strangely it appears that with all my genx86_64 systems, on multiple astlinux versions, I am unable to perform an upgrade from my private repository as it comes up with ‘Firmware verification failed’. genx86_vm and genx86_64-serial upgrades work fine.
>>>>>
>>>>> I have tried upgrading to both 1.3.6 and 1.3.7.1 and it does the same thing. I have downloaded it multiple times into the repository so I don't believe the sha1 file is corrupted.
>>>>> It does work however when I point the repository to http://mirror.astlinux-project.org/ast13se-firmware-1.x so this indicates that there must be something wrong with my repository and I cant for the life of me work out what.
>>>>>
>>>>> So my questions are:
>>>>> • Any ideas what this could be and what to try to fix it?
>>>>> • How do I show the board type for a system (before it was shown on login)?
>>>>> • Is there a way I can upgrade to a specific version using the Astlinux repository?
>>>>> • How can I move to a different board type e.g. all my genx86_64 systems are on vm’s so they really should be a genx86_vm board type?
>>>>>
>>>>> Sorry for the lots of questions. Thanks all.
>>>>>
>>>>> Regards
>>>>> Michael Knill
>>>>
>>>> Hi Michael,
>>>>
>>>> short answers to 3. + 4.:
>>>>
>>>> 3. it depends on the "ver" file in the repo folder which contains the (latest) version. E.g. "astlinux-1.3.7.1".
>>>>
>>>> 4. You can switch on the commandline between genx86_64 and genx86_64-vm (but not between serial and vga):
>>>>
>>>> https://doc.astlinux.org/devdoc:devdoc_switch_genx86_64_and_vm
>>>>
>>>>
>>>> Michael
>>>
>>> +1 and for completeness I'll add this link:
>>>
>>> Create a Private Repository
>>> https://doc.astlinux-project.org/devdoc:devdoc_create_repository
>>>
>>> Michael (Knill), you mentioned you are not building your own images (yet), so that begs the question ... how are you generating custom images for your private repository ?
>>>
>>> Lonnie
>
> Michael
>
> http://www.mksolutions.info
>
>
>
>
>
> _______________________________________________
> 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...> - 2020-04-08 03:08:13
|
Michael, Your .sha1 file for genx88_64 (video) is incorrect $ curl -sSfL http://download.ipcsolutions.com.au/13se/genx86_64/astlinux-1.3.7.1.tar.gz | shasum cfde4639295579c540240498ee0fc979bbd53858 - $ curl -sSfL http://download.ipcsolutions.com.au/13se/genx86_64/astlinux-1.3.7.1.tar.gz.sha1 bfa72ef0057b204996eda91bfaded4b132655047 astlinux-1.3.7.1.tar.gz But for your genx88_64-serial (serial) it is OK $ curl -sSfL http://download.ipcsolutions.com.au/13se/genx86_64-serial/astlinux-1.3.7.1.tar.gz | shasum e985d6f2755b122908d969e4b681a67106ada348 - $ curl -sSfL http://download.ipcsolutions.com.au/13se/genx86_64-serial/astlinux-1.3.7.1.tar.gz.sha1 e985d6f2755b122908d969e4b681a67106ada348 astlinux-1.3.7.1.tar.gz So the Qotom has a genx88_64 (video) image. Lonnie > On Apr 7, 2020, at 9:03 PM, Michael Knill <mic...@ip...> wrote: > > Hi Guys. I'm having this problem again Grrr. > I have a Qotom that has been built with a board type of genx86_64-serial. Could this be what is breaking it? > > I tried to upgrade to VGA: > 3066-Detlevs-CM1 kd # upgrade-run-image upgrade http://download.ipcsolutions.com.au/13se 64 > Firmware verification failed. > > Then just normal: > 3066-Detlevs-CM1 kd # upgrade-run-image upgrade http://download.ipcsolutions.com.au/13se > Firmware verification failed. > > I haven’t tried the official repository yet as its on 1.3.8 and I don't want to go there yet. > > Any ideas why I'm getting this and what I can do about it? > > Regards > Michael Knill > > From: Michael Knill <mic...@ip...> > Reply to: AstLinux List <ast...@li...> > Date: Monday, 20 January 2020 at 5:43 am > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Getting 'Firmware verification failed' on some boxes when I try to upgrade > > Thanks Lonnie. Private repo it is. > Hmm good idea Michael. I think I will do that. Thanks. > > Regards > Michael Knill > > From: Michael Keuter <li...@mk...> > Reply to: AstLinux List <ast...@li...> > Date: Monday, 20 January 2020 at 3:48 am > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Getting 'Firmware verification failed' on some boxes when I try to upgrade > > > > > >> Am 19.01.2020 um 07:56 schrieb Michael Knill <mic...@ip...>: >> >> Maybe one day! >> >> So any chance you would consider putting previous releases into their own subdirectory? >> E.g. current release is http://mirror.astlinux-project.org/ast13se-firmware-1.x/<board type> or specific version is http://mirror.astlinux-project.org/ast13se-firmware-1.x/<board type>/<version> > > If you would do it the other way round for your own repo: > > .../version/board-type/ > > then you could include the version number in your "Repository URL" in the Prefs and it would work as before. > You would need a "board-type" folder structure for every release in that case. > > > >> I wouldn't bother with my own repository if that was the case! >> >> Regards >> Michael Knill >> >> On 19/1/20, 9:48 am, "Lonnie Abelbeck" <li...@lo...> wrote: >> >> Hi Michael, >> >> >> >>> I have been using a Private Repository ... >> >> >> >>> I just copy in the upgrade files from the official Astlinux Repository. >> >> Ahh, OK ... simple enough. >> >> I was thinking you were somehow adding your "special sauce" to the official images to create custom images, which I did not know how you could do that without building images yourself. >> >> Lonnie >> >> >> >> >> >>> On Jan 18, 2020, at 4:40 PM, Michael Knill <mic...@ip...> wrote: >>> >>> Thanks guys >>> >>> I was not aware of that doco to convert to a vm board type. Excellent I will do this and then it should all work. >>> >>> Lonnie I have been using a Private Repository for years now and have never had a problem. The main reason for using it was purely to determine the 'Current' release for my systems and the ability to upgrade(or downgrade) to any version I want by appending the version directory to the repository URL. I just copy in the upgrade files from the official Astlinux Repository. >>> I would be happy to use the Astlinux repository if I could do the above. >>> >>> Regards >>> Michael Knill >>> >>> On 19/1/20, 1:36 am, "Lonnie Abelbeck" <li...@lo...> wrote: >>> >>> >>> >>> >>> >>>> On Jan 18, 2020, at 6:06 AM, Michael Keuter <li...@mk...> wrote: >>>> >>>> >>>> >>>> >>>> >>>>> Am 18.01.2020 um 01:15 schrieb Michael Knill <mic...@ip...>: >>>>> >>>>> Hi group >>>>> >>>>> Strangely it appears that with all my genx86_64 systems, on multiple astlinux versions, I am unable to perform an upgrade from my private repository as it comes up with ‘Firmware verification failed’. genx86_vm and genx86_64-serial upgrades work fine. >>>>> >>>>> I have tried upgrading to both 1.3.6 and 1.3.7.1 and it does the same thing. I have downloaded it multiple times into the repository so I don't believe the sha1 file is corrupted. >>>>> It does work however when I point the repository to http://mirror.astlinux-project.org/ast13se-firmware-1.x so this indicates that there must be something wrong with my repository and I cant for the life of me work out what. >>>>> >>>>> So my questions are: >>>>> • Any ideas what this could be and what to try to fix it? >>>>> • How do I show the board type for a system (before it was shown on login)? >>>>> • Is there a way I can upgrade to a specific version using the Astlinux repository? >>>>> • How can I move to a different board type e.g. all my genx86_64 systems are on vm’s so they really should be a genx86_vm board type? >>>>> >>>>> Sorry for the lots of questions. Thanks all. >>>>> >>>>> Regards >>>>> Michael Knill >>>> >>>> Hi Michael, >>>> >>>> short answers to 3. + 4.: >>>> >>>> 3. it depends on the "ver" file in the repo folder which contains the (latest) version. E.g. "astlinux-1.3.7.1". >>>> >>>> 4. You can switch on the commandline between genx86_64 and genx86_64-vm (but not between serial and vga): >>>> >>>> https://doc.astlinux.org/devdoc:devdoc_switch_genx86_64_and_vm >>>> >>>> >>>> Michael >>> >>> +1 and for completeness I'll add this link: >>> >>> Create a Private Repository >>> https://doc.astlinux-project.org/devdoc:devdoc_create_repository >>> >>> Michael (Knill), you mentioned you are not building your own images (yet), so that begs the question ... how are you generating custom images for your private repository ? >>> >>> Lonnie > > Michael > > http://www.mksolutions.info > > > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2020-04-08 02:03:58
|
Hi Guys. I'm having this problem again Grrr. I have a Qotom that has been built with a board type of genx86_64-serial. Could this be what is breaking it? I tried to upgrade to VGA: 3066-Detlevs-CM1 kd # upgrade-run-image upgrade http://download.ipcsolutions.com.au/13se 64 Firmware verification failed. Then just normal: 3066-Detlevs-CM1 kd # upgrade-run-image upgrade http://download.ipcsolutions.com.au/13se Firmware verification failed. I haven’t tried the official repository yet as its on 1.3.8 and I don't want to go there yet. Any ideas why I'm getting this and what I can do about it? Regards Michael Knill From: Michael Knill <mic...@ip...> Reply to: AstLinux List <ast...@li...> Date: Monday, 20 January 2020 at 5:43 am To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Getting 'Firmware verification failed' on some boxes when I try to upgrade Thanks Lonnie. Private repo it is. Hmm good idea Michael. I think I will do that. Thanks. Regards Michael Knill From: Michael Keuter <li...@mk...> Reply to: AstLinux List <ast...@li...> Date: Monday, 20 January 2020 at 3:48 am To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Getting 'Firmware verification failed' on some boxes when I try to upgrade Am 19.01.2020 um 07:56 schrieb Michael Knill <mic...@ip...<mailto:mic...@ip...>>: Maybe one day! So any chance you would consider putting previous releases into their own subdirectory? E.g. current release is http://mirror.astlinux-project.org/ast13se-firmware-1.x/<board type> or specific version is http://mirror.astlinux-project.org/ast13se-firmware-1.x/<board type>/<version> If you would do it the other way round for your own repo: .../version/board-type/ then you could include the version number in your "Repository URL" in the Prefs and it would work as before. You would need a "board-type" folder structure for every release in that case. I wouldn't bother with my own repository if that was the case! Regards Michael Knill On 19/1/20, 9:48 am, "Lonnie Abelbeck" <li...@lo...<mailto:li...@lo...>> wrote: Hi Michael, I have been using a Private Repository ... I just copy in the upgrade files from the official Astlinux Repository. Ahh, OK ... simple enough. I was thinking you were somehow adding your "special sauce" to the official images to create custom images, which I did not know how you could do that without building images yourself. Lonnie On Jan 18, 2020, at 4:40 PM, Michael Knill <mic...@ip...<mailto:mic...@ip...>> wrote: Thanks guys I was not aware of that doco to convert to a vm board type. Excellent I will do this and then it should all work. Lonnie I have been using a Private Repository for years now and have never had a problem. The main reason for using it was purely to determine the 'Current' release for my systems and the ability to upgrade(or downgrade) to any version I want by appending the version directory to the repository URL. I just copy in the upgrade files from the official Astlinux Repository. I would be happy to use the Astlinux repository if I could do the above. Regards Michael Knill On 19/1/20, 1:36 am, "Lonnie Abelbeck" <li...@lo...<mailto:li...@lo...>> wrote: On Jan 18, 2020, at 6:06 AM, Michael Keuter <li...@mk...<mailto:li...@mk...>> wrote: Am 18.01.2020 um 01:15 schrieb Michael Knill <mic...@ip...<mailto:mic...@ip...>>: Hi group Strangely it appears that with all my genx86_64 systems, on multiple astlinux versions, I am unable to perform an upgrade from my private repository as it comes up with ‘Firmware verification failed’. genx86_vm and genx86_64-serial upgrades work fine. I have tried upgrading to both 1.3.6 and 1.3.7.1 and it does the same thing. I have downloaded it multiple times into the repository so I don't believe the sha1 file is corrupted. It does work however when I point the repository to http://mirror.astlinux-project.org/ast13se-firmware-1.x so this indicates that there must be something wrong with my repository and I cant for the life of me work out what. So my questions are: • Any ideas what this could be and what to try to fix it? • How do I show the board type for a system (before it was shown on login)? • Is there a way I can upgrade to a specific version using the Astlinux repository? • How can I move to a different board type e.g. all my genx86_64 systems are on vm’s so they really should be a genx86_vm board type? Sorry for the lots of questions. Thanks all. Regards Michael Knill Hi Michael, short answers to 3. + 4.: 3. it depends on the "ver" file in the repo folder which contains the (latest) version. E.g. "astlinux-1.3.7.1". 4. You can switch on the commandline between genx86_64 and genx86_64-vm (but not between serial and vga): https://doc.astlinux.org/devdoc:devdoc_switch_genx86_64_and_vm Michael +1 and for completeness I'll add this link: Create a Private Repository https://doc.astlinux-project.org/devdoc:devdoc_create_repository Michael (Knill), you mentioned you are not building your own images (yet), so that begs the question ... how are you generating custom images for your private repository ? Lonnie Michael http://www.mksolutions.info |
63 messages has been excluded from this view by a project administrator.
