Re: [PATCH] base-files: sysupgrade: include uci-defaults script disabling services

2024-02-15 Thread Rafał Miłecki 

On 15.02.2024 18:46, Paul D wrote:

On 2024-02-15 15:42, Rafał Miłecki wrote:

On 14.02.2024 21:50, Paul D wrote:

Would services not do better to be tracked within uci and its config files in 
/etc/config?


Well, it's a part of a mess we have in our init/config code. It was only
last week that Jo was discussing it with Ansuel. In short we have:
1. Packages with no UCI config option for enabling/disabling
2. Packages with "enable"
3. Packages with "enabled"
4. Packages with "disable"
5. Packages with "disabled"

I'm pretty sure most users are used to enabling/disabling services
using UCI config option but not all of them have such possibility. That
is the case my change is meant to deal with.

An alternative would be to make sure every package uses "enabled" (or
"disabled") UCI option. Should we do that?



Is 'on' or 'off' in the config perhaps simpler? I think it avoids the 
linguistic differences of past participle vs present simple. (Sometimes this 
distinction is important to have.)

Otherwise 'en/disabled' is a good paradigm to encourage in configs.


Do you mean "on" and "off" as option values? How would you call such option? "enabled"? 
:P Something like "status" would be misleading again.

Or if you mean "on" and "off" as option names then what value should we assign?
uci set foo.config.on=1
?

No, I don't think "on" / "off" is a good option at all.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] base-files: sysupgrade: include uci-defaults script disabling services

2024-02-15 Thread Paul D 

On 2024-02-15 15:42, Rafał Miłecki wrote:

On 14.02.2024 21:50, Paul D wrote:
Would services not do better to be tracked within uci and its config 
files in /etc/config?


Well, it's a part of a mess we have in our init/config code. It was only
last week that Jo was discussing it with Ansuel. In short we have:
1. Packages with no UCI config option for enabling/disabling
2. Packages with "enable"
3. Packages with "enabled"
4. Packages with "disable"
5. Packages with "disabled"

I'm pretty sure most users are used to enabling/disabling services
using UCI config option but not all of them have such possibility. That
is the case my change is meant to deal with.

An alternative would be to make sure every package uses "enabled" (or
"disabled") UCI option. Should we do that?



Is 'on' or 'off' in the config perhaps simpler? I think it avoids the 
linguistic differences of past participle vs present simple. (Sometimes 
this distinction is important to have.)


Otherwise 'en/disabled' is a good paradigm to encourage in configs.



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: some github runner failers

2024-02-15 Thread Paul D 

I recommend avoiding Docker (hub) entirely if possible.

GHCR has been great in my experience. Integrates nicely with GH actions.




On 2024-02-15 13:37, Paul Spooren wrote:




On Feb 15, 2024, at 00:12, Paul D  wrote:

https://github.com/openwrt/packages/actions/runs/7908507874/job/21587828762?pr=23415

for various platforms

errors:


#4 [internal] load metadata for 
docker.io/openwrt/rootfs:i386_pentium-mmx-openwrt-23.05
#4 ERROR: no match for platform in manifest 
sha256:7a53f3d962d2ecbd00ee1f5b12794be788ca9312c1f2bc51d4ff36376a2b362d: not 
found
--

[internal] load metadata for 
docker.io/openwrt/rootfs:i386_pentium-mmx-openwrt-23.05:

--
Dockerfile:2

   1 | ARG ARCH=x86-64
   2 | >>> FROM openwrt/rootfs:$ARCH
   3 |
   4 | ADD entrypoint.sh /entrypoint.sh

ERROR: failed to solve: openwrt/rootfs:i386_pentium-mmx-openwrt-23.05: no match 
for platform in manifest 
sha256:7a53f3d962d2ecbd00ee1f5b12794be788ca9312c1f2bc51d4ff36376a2b362d: not 
found
Error: Process completed with exit code 1.


Maybe bad timing where a container is updated in the middle of a pull? I’ve seen some 
hiccups for Docker hub recently so we may want to switch to ghcr.io 
 since we’re using their runners anyway?



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: procd error messages

2024-02-15 Thread e9hack 
Hi,

'sh: missing ]' was my fault. I forgot a '&&' in a hot-plug-script:
[ $DEBUG -gt 0 ] logger -t ...

Regards,
Hartmut

Am Mi., 14. Feb. 2024 um 22:29 Uhr schrieb Paul D :
>
> On 2024-02-13 00:23, Hartmut Birr wrote:
> > Hi,
> >
> > I let /etc/init.d/network log some more things by changing:
> >
> > --- network.rom 2024-02-12 20:46:51.0 +0100
> > +++ network 2024-02-12 23:18:07.0 +0100
> > @@ -16,8 +16,10 @@ start_service() {
> >  init_switch
> >
> >  procd_open_instance
> > -   procd_set_param command /sbin/netifd
> > +   procd_set_param command /sbin/netifd -l 5 -d 15
> >  procd_set_param respawn
> > +   procd_set_param stdout 1
> > +   procd_set_param stderr 1
> >  procd_set_param watch network.interface
> >  [ -e /proc/sys/kernel/core_pattern ] && {
> >  procd_set_param limits core="unlimited"
> >
> > It reports some errors by using logread -e netifd:
> >
> > Mon Feb 12 23:30:27 2024 daemon.err netifd[29247]: device_claim(694):
> > Claim Network device pppoe-wan, new active count: 2
> > Mon Feb 12 23:30:27 2024 daemon.err netifd[29247]:
> > proto_shell_handler(231): run setup for interface 'wan_6'
> > Mon Feb 12 23:30:27 2024 daemon.err netifd[29247]:
> > __device_add_user(1037): Add user for device 'pppoe-wan', refcount=2
> > Mon Feb 12 23:30:27 2024 daemon.debug pppd[24514]: Script
> > /lib/netifd/ppp6-up finished (pid 24752), status = 0x0
> > Mon Feb 12 23:30:45 2024 daemon.err netifd[29247]: sh: missing ]
> > Mon Feb 12 23:30:45 2024 daemon.err netifd[29247]: device_claim(694):
> > Claim Network alias pppoe-wan, new active count: 2
> > Mon Feb 12 23:30:45 2024 daemon.err netifd[29247]:
> > interface_add_dns_server(1435): Add IPv6 DNS server: 2003:180:2:::
> > Mon Feb 12 23:30:45 2024 daemon.err netifd[29247]:
> > interface_add_dns_server(1435): Add IPv6 DNS server: 2003:180:2:::
> > Mon Feb 12 23:30:45 2024 daemon.err netifd[29247]:
> > interface_queue_event(124): Queue hotplug handler for interface 'wan_6',
> > event 'ifup'
> > Mon Feb 12 23:30:45 2024 daemon.notice netifd: Interface 'wan_6' is now up
> > Mon Feb 12 23:30:50 2024 daemon.err netifd[29247]: task_complete(109):
> > Complete hotplug handler for interface 'wan'
> > Mon Feb 12 23:30:50 2024 daemon.err netifd[29247]: call_hotplug(100):
> > Call hotplug handler for interface 'wan', event 'ifupdate' (pppoe-wan)
>
> Call exits netifd.
>
> Does it go to ppp.sh?
>
> It could be that some ' -a ' condition is breaking down...?
>
> [ blah -a blah2 ]
>
> ?
>
> https://git.openwrt.org/?p=project/netifd.git;a=blob;f=examples/proto/ppp.sh;hb=f01345ec13b9b27ffd314d8689fb2d3f9c81a47d
>
>
> https://git.openwrt.org/?p=project/netifd.git;a=blob;f=scripts/netifd-proto.sh;h=87d337df07e9aa94b80ea53d050eadde791739d9;hb=refs/heads/master
>
>
>
>
> > Mon Feb 12 23:31:05 2024 daemon.err netifd[29247]: sh: missing ]
> > Mon Feb 12 23:31:07 2024 daemon.err netifd[29247]: sh: out of range
> > Mon Feb 12 23:31:07 2024 daemon.err netifd[29247]: task_complete(109):
> > Complete hotplug handler for interface 'wan'
> > Mon Feb 12 23:31:07 2024 daemon.err netifd[29247]: call_hotplug(100):
> > Call hotplug handler for interface 'wan_6', event 'ifup' (pppoe-wan)
> > Mon Feb 12 23:31:07 2024 daemon.err netifd[29247]: /sbin/uci: Invalid
> > argument
> > Mon Feb 12 23:31:16 2024 daemon.err netifd[29247]: sh: missing ]
> >
> > Is it possible to let print netifd more informations related to errors
> > from executed commands like:
> >
> > Mon Feb 12 23:31:05 2024 daemon.err netifd[29247]: sh: missing ]
> > Mon Feb 12 23:31:07 2024 daemon.err netifd[29247]: sh: out of range
> > Mon Feb 12 23:31:07 2024 daemon.err netifd[29247]: /sbin/uci: Invalid
> > argument
> >
> > I'm not able to identify the executed scripts.
> >
> > Regards,
> > Hartmut
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] base-files: sysupgrade: include uci-defaults script disabling services

2024-02-15 Thread Eric via openwrt-devel 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Thursday, February 15th, 2024 at 06:42, Rafał Miłecki  
wrote:
> I'm pretty sure most users are used to enabling/disabling services
> using UCI config option but not all of them have such possibility. That
> is the case my change is meant to deal with.

Well, there was some user discussion on the forum a couple months back and
I've always felt 'service X enable/disable' was the right way to do things.
https://forum.openwrt.org/t/bug-service-status-is-not-saved-after-sysupgrade/179045

> An alternative would be to make sure every package uses "enabled" (or
> "disabled") UCI option. Should we do that?

I recently reworked the snort3 package and added "enabled" to its config.
I felt then (and still do) that this is sort of a "hack around a bug",
and would rather see it addressed as part of sysupgrade's backup/restore
process.

I'm a definite +1 on your current patch for sysupgrade, it looks like 
an elegant, unintrusive and robust means for dealing with service state.

Eric

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] base-files: sysupgrade: include uci-defaults script disabling services

2024-02-15 Thread Rafał Miłecki 

On 14.02.2024 21:50, Paul D wrote:

Would services not do better to be tracked within uci and its config files in 
/etc/config?


Well, it's a part of a mess we have in our init/config code. It was only
last week that Jo was discussing it with Ansuel. In short we have:
1. Packages with no UCI config option for enabling/disabling
2. Packages with "enable"
3. Packages with "enabled"
4. Packages with "disable"
5. Packages with "disabled"

I'm pretty sure most users are used to enabling/disabling services
using UCI config option but not all of them have such possibility. That
is the case my change is meant to deal with.

An alternative would be to make sure every package uses "enabled" (or
"disabled") UCI option. Should we do that?



Or do changes to those files there risk triggering other procd actions to the 
services they dictate?


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: some github runner failers

2024-02-15 Thread Paul Spooren 


> On Feb 15, 2024, at 00:12, Paul D  wrote:
> 
> https://github.com/openwrt/packages/actions/runs/7908507874/job/21587828762?pr=23415
> 
> for various platforms
> 
> errors:
> 
> 
> #4 [internal] load metadata for 
> docker.io/openwrt/rootfs:i386_pentium-mmx-openwrt-23.05
> #4 ERROR: no match for platform in manifest 
> sha256:7a53f3d962d2ecbd00ee1f5b12794be788ca9312c1f2bc51d4ff36376a2b362d: not 
> found
> --
> > [internal] load metadata for 
> > docker.io/openwrt/rootfs:i386_pentium-mmx-openwrt-23.05:
> --
> Dockerfile:2
> 
>   1 | ARG ARCH=x86-64
>   2 | >>> FROM openwrt/rootfs:$ARCH
>   3 |
>   4 | ADD entrypoint.sh /entrypoint.sh
> 
> ERROR: failed to solve: openwrt/rootfs:i386_pentium-mmx-openwrt-23.05: no 
> match for platform in manifest 
> sha256:7a53f3d962d2ecbd00ee1f5b12794be788ca9312c1f2bc51d4ff36376a2b362d: not 
> found
> Error: Process completed with exit code 1.

Maybe bad timing where a container is updated in the middle of a pull? I’ve 
seen some hiccups for Docker hub recently so we may want to switch to ghcr.io 
 since we’re using their runners anyway?

signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel