Conflict between entware-ng and Alt-F packages - Can we prioritize the latest version of programs?

[Trillien]

Hi,

I've just upgraded my DNS-320L A1 from RC5 to Release 1.0, and discovered entware-ng. I take the opportunities to install up-to-date packages from entware-ng. I'd like to have the latest version of nfs server available from entware-ng to run NFSv4 protocole with some authentification functionalities (Alt-F packages only provide NFSv3).

I quickly notice some conflicts between both Alt-F and entware-ng versions of same programs.

In fact, due to $PATH variable if a program already exists in /bin or /sbin then the entware version in /opt/sbin is ignored and Alt-F version of the daemon is started.

I think of changing the $PATH variable to prioritize the entware programs, or to add symlinks to /bin.

Have you got a piece of advice for me?

More generally, is my quest of having NFSv4 on Alt-F for a bit of authentification between my machines vain (because it depends on kernel compilation variables) or useless (there isn't any authentification engine working for NFSv4 on Alt-F yet)?

Trillien

[Trillien]

Additional information. I notice the following command in /etc/init.d/S81entware:

export PATH=/opt/bin:/opt/sbin:$PATH

Thus I expect to have $PATH:

/opt/bin:/opt/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/ffp/bin:/ffp/sbin

However my $PATH after reboot is:  

/bin:/sbin:/usr/bin:/usr/sbin:/opt/bin:/opt/sbin:/ffp/bin:/ffp/sbin

[João Cardoso]

On Wednesday, 28 June 2017 22:46:40 UTC+1, Trillien wrote:

Additional information. I notice the following command in /etc/init.d/S81entware:

export PATH=/opt/bin:/opt/sbin:$PATH

That is only set and valid for running entware own init scripts.

If you disable Alt-F NFS from starting at boot and instead enable entware nfs init script you should be OK. Just guessing... no, guessing wrongly, NFS v4 requires kernel support, and that is not provided by, sorry. Perhaps using some entware user-level NFS package? Can't say.

[Trillien]

Hi,

Now you say to disable Alt-F services before running entware-ng, it seems obvious. I investigate further and have some progress.

I disable Alt-F nfs service

sudo rcnfs disable

And make sure entware is enable

sudo rcentware enable

So entware-ng is now in charge to run portmap service. I guess portmap is used by other services than nfs (maybe samba...). So I prefer changing the priority for starting portmap earlier as below:

sudo aufs.sh -n
sudo mv /Alt-F/etc/init.d/S81entware /Alt-F/etc/init.d/S18entware
sudo aufs.sh -r

I had an issue with rc.unslung script. As detailed on hot_aux logs, entware-ng services were started in their inverse order (S77ntpd, S57nfs-kernel-server, S55portmap)

hot_aux: [1;37m Starting ntpd... [m             [1;32m done. [m
Error: portmap not started
[1;37m Starting portmap... [m             [1;32m done. [m

As a consequence, nfs daemon refuses to run at start up as portmap is started after...

In fact rc.unslung script doesn't manage properly the order for starting the services when using restart argument. It stops and immediatly starts the services in the inverse order. I rewrite it and obtain the hot_aux logs below at startup:

hot_aux: [1;37m Checking ntpd...             [1;31m dead. [m
Error: portmap not started
[1;37m Checking portmap...             [1;31m dead. [m
[1;37m Starting portmap... [m             [1;32m done. [m
Starting NFS server
[1;37m Starting ntpd... [m             [1;32m done. [m

It seems rc.unslung script receives the restart argument at startup. However it now tries to first stop all the services, and then starts them in the right order (portmap is now started before nfs).

It seems the server now runs nfsv4:

$ rpcinfo -p
   program vers proto   port
    100000    2   tcp    111
    100000    2   udp    111
    100003    3   udp   2049
    100021    1   udp  54583
    100021    3   udp  54583
    100021    4   udp  54583
    100021    1   tcp  36946
    100021    3   tcp  36946
    100021    4   tcp  36946
    100005    1   udp  40368
    100005    2   udp  40368
    100005    3   udp  40368

I've changed rc.unslung as below:

#!/bin/sh

PREFIX="/opt"

CALLER=$2

PATH=${PREFIX}/sbin:${PREFIX}/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# Start/stop all init scripts in /opt/etc/init.d including symlinks

# starting them in numerical order and

# stopping them in reverse numerical order

is_sourceshell() {

filename=$1

case "$filename" in

S* | *.sh )

return 1

;;

*)

return 0

;;

esac

}

do_action() {

fullfile=$1

action=$2

caller=$3

if test -x "$fullfile"; then

#echo $fullfile $action $caller

filename="${fullfile##*/}"

if is_sourceshell $filename; then

# Source shell script for speed.

trap "" INT QUIT TSTP EXIT

#set $action

#echo "trying $filename" >> /tmp/rc.log

. $fullfile $action $caller

else

# No sh extension, so fork subprocess.

$fullfile $action $caller

fi

fi

}

logger "Started $0${*:+ $*}."

case "$1" in

start)

for fullfile in $(ls ${PREFIX}/etc/init.d/S*) ;do

do_action $fullfile start $CALLER

done

;;

stop)

for fullfile in $(ls -r ${PREFIX}/etc/init.d/S*) ;do

do_action $fullfile stop $CALLER

done

;;

restart)

for fullfile in $(ls -r ${PREFIX}/etc/init.d/S*) ;do

do_action $fullfile stop $CALLER

done

for fullfile in $(ls ${PREFIX}/etc/init.d/S*) ;do

do_action $fullfile start $CALLER

done

;;

reconfigure)

for fullfile in $(ls ${PREFIX}/etc/init.d/S*) ;do

do_action $fullfile reconfigure $CALLER

done

;;

check)

for fullfile in $(ls ${PREFIX}/etc/init.d/S*) ;do

do_action $fullfile check $CALLER

done

;;

status)

for fullfile in $(ls ${PREFIX}/etc/init.d/S*) ;do

do_action $fullfile status $CALLER

done

;;

kill)

for fullfile in $(ls -r ${PREFIX}/etc/init.d/S*) ;do

do_action $fullfile kill $CALLER

done

;;

*)

printf "Usage: $0 

{start|stop|restart|reconfigure|check|kill}\n" >&2

exit 1

;;

esac

By the way, S57nfs-kernel-server from entware-ng doesn't support the check argument generated when I call rcentware status. So I've created an additional entry in the case/esac loop similar to status argument.

I didn't check yet about nfsv4 connectivity and authentification. Next step...

Trillien