Building installer with custom base snapshot

[fdizazzo]

Hi all!
I'm trying to create an installer with custom snapshot properties so for firewall and networking, but I'm probably missing something...
So far I've created a new profile in distrib/pom.xml and its folder in distrib/src/main/resources (both duplicated from the generic x86_64) where I've put my snapshot_0.xml.
Everything seems to work fine, the .deb is created, my modified kura.properties is applied except the snapshot_0.xml which seems to be ignored.
I've randomly tried to look at #3592 but can't really find anything missing... where could i start investigating? :)

[mattdibi]

Hello there @fdizazzo,

at the time of the PR you linked we didn't have the customize-installation.sh script. See https://github.com/eclipse/kura/blob/990fc4dc790985389c68a5e9473f92ac65777ee4/kura/distrib/src/main/resources/common/customize-installation.sh#L46

Maybe @marcellorinaldo can help on this matter.

[mattdibi]

making it diffcult to have different installer profiles for the same platform.

🤔 this is a use-case we didn't consider in the past and don't know if we're interested in supporting.

Can you expand a little on what you're trying to achieve and what's the expected outcome? Like: is this something only an "advanced" user is expected to be able to customize? Do we have additional different profiles out-of-the-box for each build?

[fdizazzo]

I'll start with the use case: let's pretend I have the a device with no way to hook up a monitor and keyboard nor any access to a DHCP server 😆 and I know that on all devices eth0 must have a predetermined ip, I'd need an installer able to configure the base kura services out the box.
Once I have to different devices that like the generic-device just fine, but need different base configuration I'd find useful if the build
process creates a couple installer for the same device type but with different configurations.

Like: is this something only an "advanced" user is expected to be able to customize?

Yes, the additional profiles would remain on the codebases of the users that actually need it.

Below the idea with what I think has the least possible impact on how things are working now (not tested, don't look to hard at it), only requiring modifications on customize-installation.sh (that is, only one that would be required to be merged in the main kura repo), leaving the current behaviour unchanged while allowing a user easier customization in its profiles.

KURA_PLATFORM=$( uname -m )
sed -i "s/kura_platform/${KURA_PLATFORM}/g" "/opt/eclipse/kura/framework/kura.properties"

while getopts "b:rn" OPTION; do
    echo "Option ${OPTION} with param ${OPTARG}"
    case $OPTION in
    n)
        NIC=1
        ;;
    r)
        RAM=1
        ;;
    b)
        BOARD=$OPTARG
        ;;
    esac
done

if [ -z ${BOARD} ]
then
    echo "Missing board parameter ${BOARD}"
    if uname -a | grep -q 'raspberry' > /dev/null 2>&1
    then
        BOARD="raspberry"
        echo "Customizing installation for Raspberry PI"
    fi

    if uname -a | grep -q 'up' > /dev/null 2>&1
    then
        if uname -n | grep 'intel' > /dev/null 2>&1
        then
            BOARD="intelup2"
            echo "Customizing installation for Intel UP2"
        fi
    fi

    if uname -a | grep -q 'nvidia' > /dev/null 2>&1
    then
        BOARD="jetson-nano"
        echo "Customizing installation for NVIDIA Jetson Nano"
    fi

    

    if [ -z ${BOARD} ]
    then
        BOARD='generic-device'
        if [ -z ${RAM} ]; then RAM=1; fi
        if [ -z ${NIC} ]; then NIC=1; fi    
    fi
fi
if [ ! -d "/opt/eclipse/kura/user/snapshots/" ]; then
    mkdir /opt/eclipse/kura/user/snapshots/
fi
echo "My reference board is ${BOARD}"

mv "/opt/eclipse/kura/install/jdk.dio.properties-${BOARD}" "/opt/eclipse/kura/framework/jdk.dio.properties"
cat "/opt/eclipse/kura/install/snapshot_0.xml-${BOARD}"
mv "/opt/eclipse/kura/install/snapshot_0.xml-${BOARD}" "/opt/eclipse/kura/user/snapshots/snapshot_0.xml"
mv "/opt/eclipse/kura/install/iptables-${BOARD}" "/opt/eclipse/kura/.data/iptables"
sed -i "s/device_name/${BOARD}/g" "/opt/eclipse/kura/framework/kura.properties"
if python3 -V > /dev/null 2>&1
then
    python3 /opt/eclipse/kura/install/find_net_interfaces.py /opt/eclipse/kura/framework/kura.properties
else
    echo "python3 not found. Could not edit the primary netowrk interface name in /opt/eclipse/kura/framework/kura.properties. Defaulted to eth0."
fi

if [ ${NIC} ]; then
    # replace snapshot_0, iptables.init, and kura.properties with correct interface names
    if python3 -V > /dev/null 2>&1
    then
        python3 /opt/eclipse/kura/install/find_net_interfaces.py /opt/eclipse/kura/user/snapshots/snapshot_0.xml /opt/eclipse/kura/.data/iptables
    else
        echo "python3 not found. snapshot_0.xml, and iptables.init files may have wrong interface names. Default is eth0 and wlan0. Please correct them manually if they mismatch."
    fi
fi

if [ ${RAM} ]; then    
    # dynamic RAM assignment
    RAM_KB=$(grep MemTotal /proc/meminfo | awk '{print $2}')
    RAM_MB=$(expr $RAM_KB / 1024)
    RAM_MB_FOR_KURA=$(expr $RAM_MB / 4)

    if [ "$RAM_MB" -lt 1024 ]; then
        RAM_REPLACEMENT_STRING="-Xms256m -Xmx256m"
    fi

    echo "Setting kura RAM to ${RAM_REPLACEMENT_STRING}"
    start_scripts_to_change=("start_kura.sh" "start_kura_debug.sh" "start_kura_background.sh")

    RAM_REPLACEMENT_STRING="-Xms${RAM_MB_FOR_KURA}m -Xmx${RAM_MB_FOR_KURA}m"
    for installer_name in "${start_scripts_to_change[@]}"; do
        echo "Updating RAM values for $installer_name"
        sed -i "s/-Xms[0-9]*m -Xmx[0-9]*m/$RAM_REPLACEMENT_STRING/g" "/opt/eclipse/kura/bin/$installer_name"
    done
    
fi

having the board, ram, nic parameters added to the kura_install.sh on its customize_installation.sh invocation

Could put together a quick end-to-end example on my repo if needed.

Edit: the example is now slightly more functional

[mattdibi]

I understand 🤔 . @MMaiero @marcellorinaldo thoughts?

[marcellorinaldo]

Hi @fdizazzo,

unfourtunately our distrib code at the moment is not very expandable, and will not be in the next future. To have a custom profile you could proceed as you were describing or have your custom distrib since the one from Kura is not API, so you will be subject to breaking changes and even profiles removal.

The main parts for building your profile are:

• The distrib main pom where you define your custom profiles, like generic-arm32, from which you set properties that "customize" your build, define DEB package properties, and call the ANT script (see point below)
• The ANT script to decide which bundles to include in your kura distrib (you could make you Kura version more lightweight by removing things you do not need) and the scripts that you need for starting Kura

Let me know if you need more help or try joining one of our Kura Dev Meetings to ask directly.

Best, Marcello

[fdizazzo]

Ok, I agree that the QOL gain is not worth the increase in complexity and my solution only covers a subset of what's needed by a user who needs to build its own profile.
Marking @mattdibi's post as answer :)