Error while installing custom App.

[Ajay K]

I am trying to install a custom app locally on the conduit flash under /var/config/app directory and I have also set the “SDCard” to false so that it installs the application on the local flash. However I get the following error below. Can you let me know why I would get this error and how I could fix this?

admin@mtcdt:/var/volatile# app-manager --command local --appfile lorauplinkpacketmgr.tar.gz --appname $app_name --apptype CUSTOM
Locally installing [“LoraUplinkPacketMgr”]
AppCommand::executeLocalInstall: failed to parse manifest data for appId UNKNOWN
Command local failed with:
    appId      UNKNOWN
    appName    “LoraUplinkPacketMgr”
    appVersion UNKNOWN
    appType    CUSTOM
    appStoreIP www.devicehq.com
    configids  {"ids":[]}

Thanks,
Ajay

[Jeff Hatch]

Ajay,

Could you post the contents of your manifest file?

Jeff

[Ajay K]

Hi Jeff,

Here is the contents of the manifest.json. Is it because the false set for the SDCard is not enclosed in double quotes?

{
    “AppName” : “LoraUplinkPacketMgr”,
    “AppVersion : “1.0”,
    “AppDescription” : “Manages LORA Uplink Packets”,
    “AppVersionNotes” : “instaling on flash”,
    “SDCard” : false
}

Thanks,
Ajay

[Ajay K]

Also in the Start scripts for the custom app, is it okay to use the node-angel like the node-red start up script?

for ex:

$START_STOP_DAEMON --start \
             --background \
             --pidfile "$PID_FILE" \
              --make-pidfile \
               --chdir "$RUN_DIR" \
               --startas /sbin/node-angel \
               -- /bin/bash -c "exec $DAEMON -- $DAEMON_ARGS >& $APP_LOGDIR/$NAME.log"

or can the same thing be achieved from the daemon command below.

$START_STOP_DAEMON --start \
                      --background \
                      --pidfile "$PID_FILE" \
                      --make-pidfile \
                      --chdir "$RUN_DIR" \
                      --startas "$DAEMON" \
                      -- "$DAEMON_ARGS >& $APP_LOGDIR/$NAME.log"

Thanks,
Ajay

[Jeff Hatch]

Ajay,

In your manifest file you are missing a ‘”‘ at the end of the AppVersion key. That is why the version is UNKOWN in the error statement.

As for the use of the angel process, if you use the node-angel (which is a link to the angel binary, see code) you will need to be careful because a “/etc/init.d/node-red killstop will also kill your app. See do_killstop() in /etc/init.d/node-red.

admin@mtcdt:/etc/rc5.d# ls -l /sbin/node-angel                                                            
lrwxrwxrwx    1 admin    root            11 Apr 24 15:28 /sbin/node-angel -> /sbin/angel

On install (in the Install script) your app could install it’s own link to angel, and that could be used by your Start script to start your app under an angel process. That would restart your app if it died.

Jeff

[Ajay K]

Thanks Jeff for pointing that out. So I am guessing using the node-angel is risky. Since I need my custom app running even if node-red is shutdown. Also as far as piping the o/p logs to a file, I did as you suggested in an earlier thread, is this the correct way to handle it?

$START_STOP_DAEMON --start \
                      --background \
                      --pidfile "$PID_FILE" \
                      --make-pidfile \
                      --chdir "$RUN_DIR" \
                      --startas "$DAEMON" \
                      -- "$DAEMON_ARGS >& $APP_LOGDIR/$NAME.log"

Thanks,
Ajay

[Jeff Hatch]

Ajay K,

For the angel process, I think you will be fine using angel if you create your own link to /sbin/angel for management of your app process. That way none of the built-in functionality on the Conduit will kill it if it has a unique name. What I was referring to is the possibility that using angel through the link “node-angel” could match the node-angel process name and get killed unexpectedly due to Conduit’s built-in functionality managing the Node-RED process.

So, you should be ok using angel as long as your angel instances is running through a unique link.

As for the logs, I think that should work though I would put the “>& APP_LOGDIR/$NAME.log” in the DAEMON_ARGS since it will be an argument for the daemon to redirect output to the log file.

Jeff

[Ajay K]

Is there anything else I need to pass to the app-manager command line to clearly indicate this needs to be installed on the flash, other than using the “local” command? Currently even with the SDCard key set to false in the manifest.json, the App-manager still installs it on the SD card on my conduit

Thanks,
Ajay

[Jeff Hatch]

Ajay,

Are you running the Conduit 1.4.1 firmware? That is the only version that supports installing and running in flash. Anything before that will always try to install it on the SD Card and ignore the SDCard key.

Jeff

[Ajay K]

Hi Jeff,

Yes I did upgrade my firmware to 1.4.1 firmware as soon it was released. I double checked the firmware version again and it is 1.4.1. The command that was executed as mentioned below and like the link suggests I have set the SDCard key to false in the manifest.json.

app-manager --command local --appfile LoraUplinkPacketManager.tar.gz --appname "LoraUplinkPacketManager" --apptype CUSTOM

Thanks,
Ajay

[Ajay K]

Since the scripts don’t seem to be honoring the SDCard settings in the manifest.json, so I removed the SD card from the conduit and ran the script and this time I get a “Permission Denied” error and is as shown below.

Locally installing [LoraUplinkPktManager]
sh: /var/config/app/LoraUplinkPktManager/Install: Permission denied
AppCommand::runInstall: failed to execute Install script: /var/config/app/LoraUplinkPktManager/Install install

AppCommand::executeLocalInstall: Install failed in /var/config/app/LoraUplinkPktManager/
Command local failed with:
appId UNKNOWN
appName LoraUplinkPktManager
appVersion UNKNOWN
appType CUSTOM
appStoreIP http://www.devicehq.com
configids {“ids”:[]}

However the folder structure seems to have been created under /var/config/app, but the overall application fails to be installed.

Thanks,
Ajay

[Ajay K]

Hi Jeff,

I had the permission issue resolved, however I think the app-manager or some other script should handle the step that I did it to get it to work.

So I had to run chmod +x Install and chmod +x Start commands on the Install and Start scripts so they have execute permissions and then generate the tar files. After which the Install went thru’ fine.

Also I wasn’t initially couldn’t pipe the console.log outputs of my custom application to a log file using the “–startas /usr/bin/node”, however using the angel process as a part of my start scripts allowed me to do pipe the console o/p successfully to a custom log file.

As you suggested I created a soft link to the angel application under /sbin and gave it a unique name and that shouldn’t clash with node-angel. However I am wondering how we would deal with a firmware upgrade and creating a soft link and installing the custom app?

Also is there a way I can get a custom app launch before the lora-wan server/service is up and running?

Thanks for all your help and inputs.

Thanks,
Ajay

[Jeff Hatch]

Ajay,

I disagree that it should be the install code’s responsibility to chmod things correctly. Future devices will have much more “locked down” permissions for the different processes on the Conduit. At this time the app-manager code does not chown or chmod anything, and keeping it that way so we can make it least privileged will not only simplify things, but also make them more secure.

“However I am wondering how we would deal with a firmware upgrade and creating a soft link and installing the custom app?”

You’re in luck on this one. As long as your app Install script creates the link. The Install script for each custom app gets re-run every time there is a firmware upgrade.

“Also is there a way I can get a custom app launch before the lora-wan server/service is up and running?”

You can create your own init script that starts your app and have the Install script install it. You can install it using the rc.update utility at whatever level you want. Make sure to have your Start script essentially be a no-op so that the only instance that is running is the one started by your init script.

Jeff

[Ajay K]

Thanks Jeff for your response.

1)However if you look at it the files are compressed into the tar.gz file and the app-manager copies over to the /var/app folder and runs the install and start scripts, so if it is able to do all that not sure why giving it permissions to execute is making it less secure, unless the install and start scripts are a suspect. Having said that I will update my scripts to do just that.

2) Regarding the firmware upgrade, I never thought of that of creating the soft links via the install, that will solve the issue, I will do that. So I am guessing the App-Manager during a firmware upgrade looks for the tar.gz file under the /var/app/<app-name> folder or is there an upgrade dir where the <app-name>tar.gz file needs to be present?

3) Lastly instead of creating a brand new init script, is it possible to run the rc.update utility in the postInstall step and still change the priority? Also while it boots I was hoping the custom app starts before the lora wan server and when the conduit is being rebooted the custom app is terminated after the lora wan server is shut down. I should be able to do all that with the rc.update utility right?

All this I am doing just to compensate for the scenario where we end up loosing packets that were ack-ed by the lora wan server for an uplinked packet, but node-red already was either shutdown or not yet up and running when the conduit boots up.

Thanks,
Ajay

[Jeff Hatch]

Ajay,

1) While trying to not sound too pedantic (though I think security requires it), giving the app-manager permission to exec on a file and to chown the same file are two separate capabilities that can be controlled with Linux capabilites (see man capabilities). The capabilities/privileges of a process can be restricted through these settings.

2) The app-manager simply runs the Install script which will install anything in the provisioning directory. If you are un-tarring a file in the Install script it will perform that operation. However, the app-manager doesn’t untar the entire application tar file over again. The /var/config/app and the /media/card/ directory (with SD Card present) will persist through the firmware upgrade.

3) You should be able to use the postinstall step to do that. I think in the case you have described you will need two init scripts. One with just a start() to start the app before the LoRa WAN server with an empty stop() that does nothing, and a second script that will be run after the LoRa WAN script that has the stop() defined to stop the app that has an empty start().

I understand that this is a lot of work to prevent loss of packets. Welcome to the world of M2M with it’s many mirco-architectures.

Jeff

[Ajay K]

3) You should be able to use the postinstall step to do that. I think in the case you have described you will need two init scripts. One with just a start() to start the app before the LoRa WAN server with an empty stop() that does nothing, and a second script that will be run after the LoRa WAN script that has the stop() defined to stop the app that has an empty start().

Based on the comments above. Instead of creating two brand new scripts, do you see any issues in updating the start priority of customapp script in the init.d folder, as the kill is being done in the correct order, lorawan server first and then the custom app.

if you don’t see any issues, Should I update the priority of the customapp script during the install of my custom app. Since there is only one custom app and I would like it to start before the Lorawan service is up and running?

Again yesterday while testing this we lost a packet just because the custom app launched 20 seconds after the lorawan service.

Thanks,
Ajay

[Jeff Hatch]

Ajay,

Do you want to change the start order in a target run level?

ie. “update-rc.d customapp stop 31 5”

If that is the case just remember that your custom app will need to be responsible for this on it’s install since this change would get blown away by a firmware update.

Jeff

[Ajay K]

Hi Jeff,

For the stop levels i.e. 0, 1 and 6 the priority of the custom app is at 1 on my conduit, so its going to be run/shutdown after the lora-network-service and mosquitto has already been shut down.

For the Start level i.e. 2, 3, 4, 5, the Lora-network-service is running at a priority of 80 and the mosquitto is at 75 and the customapp on my conduit is at 95. So I would like to run the customapp between the priority levels of the mosquitto and lora-network-server, say 77. so I would end up running the command as you have mentioned above and as shown below.

update-rc.d customapp defaults 77 1

So once the firmware upgrade has completed I am guessing it will begin any customapp installs. In the post install step, i will remove the customapp init.d settings using the “update-rd.d -f customapp remove” command and install the customapp init.d settings with the changed priority level as shown above. Do you see any issues with this approach or any obvious concerns?

I did make those changes on my conduit to test it out, and this time the custom app starts 20 seconds ahead of the lora-network-server” service and at least i can be assured no loss of packets, because of service startup delays.

Thanks,
Ajay.

[Jeff Hatch]

Ajay,

Other than making sure to re-install on firmware upgrade that we already discussed, I don’t see any issues with what you are doing.

Jeff

[Ajay K]

Thanks Jeff for confirming. Yup will ensure on re-install of firmware the customapp priority levels are set correctly.

Thanks,
Ajay

[Author]

Posts