Modify underlying Linux with sdef


#1

Hiya,

Is there any way to modify files on the underlying yocto image from within a sdef package?

I need to modify or replace the firewall rules file /etc/iptables.rules (on a FX30 - it’s in a different file on the standard WP build) when I install my sdef bundle into the existing legato install.

Currently, I run a script to do the mods as well as installing the sdef bundle. But it would be nice (and the client has asked for it) to be able to do this in one step - then I can force the install/update from AirVantage

ciao, Dave


#2

That sounds dangerous. If you do that and (for example) the system is rolled back your iptables.rules will not be rolled back.

Instead, I think it would be better to write an app that installs your new firewall rules on start & removes them on stop of the app.


#3

Hiya,

Point taken. There’s no guarantee that a roll-back sdef will put things back the way they were without reloading the entire OS image.

But, writing another ‘app’ to manage the firewall rules has a few issues that also need to be managed:

  1. another app to be maintained (probably only a shell script so not so bad)
  2. there may be a sequence/dependency issue here. Because there is no way (that I am aware of) to say that one app depends on another app completing without failure in either a adef or sdef file, there is no easy way to sequence the startup of apps. For example, if a ‘comms’ app depends on the ‘firewall’ app having been run and completed successfully, there’s no way to do this without wrapping another layer of app scripting inside the adef file.

Thanks for your thoughts.

ciao, Dave


#4

I think you might be misunderstand my concern about rollback: If Legato reboots too many times while under probation, it will try to roll back to the previously installed system (see Controlling the Probation Period at http://legato.io/legato-docs/latest/c_updateCtrl.html). But this rollback process will miss anything you touch outside the Legato directory.

If you have this kind of dependency you could include the firewall rules inside the “comms” app directly.


#5

Hiya,

I understand the rollback process when an app continually faults and reboots the platform - I’ve had it happen a number of times during development. It’s a pain during development but an excellent reliability tool for a device in the field.

But including the firewall rules in the comms app still has the same problem of sequencing - I want to make sure the firewall rules are run (and complete successfully) before the main body of the comms app runs.

I can see two ways of doing this:

  1. write a script that manages the firewall rules, then starts the comms app at the end. This has the disadvantage that the legato app management of the comms app is sort of bypassed as the script will always completes and legato probably can’t catch if the comms app faults for some reason.
  2. call the underlying linux ‘iptables’ program (or maybe another script) from within the comms source using a system() call.

Your thoughts?

ciao, Dave


#6

What about option 1b: write a wrapper script that manages the firewall rules and starts the comms app in the middle. Once the comms app exits (for whatever reason), reset the firewall rules then exit the script with the same exit code as the comms app. Legato app management should work as long as the script doesn’t exit until after the comms app does (i.e. the script should start the comms app in the foreground).

Number 2 may work, but I’d be worried (again) about runing into problems on upgrade/downgrade scenarios as it’s hard to cleanup the rules afterwards.

Depending on your app & the rules you need it may be OK to start the firewall & app simultaneously, and the app just won’t communicate until the firewall rules are set. From the sounds of it this won’t work in your particular circumstance, but I thought I’d include it for completeness.