Beyonwiz Australia

Hi,

Another one I'd leave off is the DLNA server, or at least disabled by default.

dRdoS7

dRdoS7 wrote: Another one I'd leave off is the DLNA server, or at least disabled by default.

+1 for disabling it by default, especially since the enable/disable setting is one that cannot be backed up.

I'd say it would not be a good idea to remove entirely since it is a useful feature for some users and is very much a core feature for media sharing.

dRdoS7 wrote:Hi,

Another one I'd leave off is the DLNA server, or at least disabled by default.

dRdoS7

We had a discussion about this some time ago, everyone was unanimous that it should be disabled by default. WizHQ responded to a PM from me to him requesting it be disabled stating that he would discuss it with PeterU but unfortunately it seemed to go no where.

Glen

It's not gone nowhere. At this stage it remains enabled because there are many users out there that will expect their Beyonwiz to be found by DLNA enabled devices.

It would be useful to be able to preserve the enabled/disabled state of the network services items (Samba/NFS/DLNA/DYN-DNS) in the settings backup. I haven't been able to work out how that can be done within the current settings backup system, because disabling these services removes a symbolic link from /etc/rc2.d, and the non-existence of a file can't be represented in a tar archive (which is what the settings backup is).

prl wrote:It would be useful to be able to preserve the enabled/disabled state of the network services items (Samba/NFS/DLNA/DYN-DNS) in the settings backup. I haven't been able to work out how that can be done within the current settings backup system, because disabling these services removes a symbolic link from /etc/rc2.d, and the non-existence of a file can't be represented in a tar archive (which is what the settings backup is).

I was thinking about that problem, since you had pointed out in the past that it was not straightforward, and I figured it was tied up in the init scripts.
Could we just have another init script that runs on boot (or even at shutdown), and checks what the state of those services is supposed to be and enables/disables them as required.

I figure, the user would restore their settings, be prompted to reboot, then the new script would run and sort out the other services, and things would then be back to the way the user wanted it.

I'm not entirely across what other hazards that might introduce though.

MrQuade wrote:...
I was thinking about that problem, since you had pointed out in the past that it was not straightforward, and I figured it was tied up in the init scripts.
Could we just have another init script that runs on boot (or even at shutdown), and checks what the state of those services is supposed to be and enables/disables them as required.
...

That would probably be possible, but it's a bit ugly. It would be modifing the set of scripts that run at startup/shutdown as the scripts are run. I think that a kill script that runs after step 20 (the step where the network services are started/stopped) and forces the enable/disable of the services in /etc/init.d would work.

I'm also not sure how well putting non-standard init scripts into the firmware sits with the system build scripts.

Don't go there. These packages use standard system V init scripts that come from upstream. I don't want to hack the base distro to deviate.

peteru wrote:Don't go there. These packages use standard system V init scripts that come from upstream. I don't want to hack the base distro to deviate.

I rather suspected that changing the /etc/init.d scripts would get in the way.

prl wrote:

peteru wrote:Don't go there. These packages use standard system V init scripts that come from upstream. I don't want to hack the base distro to deviate.

I rather suspected that changing the /etc/init.d scripts would get in the way.

Fair enough.

How about a change to the backup and restore scripts to check and set the runlevel of the various services rather than simply taking a backup of the settings files?