Re: Continuing discussion on Handling persistent files (/etc/group)during BMC updates

[Ed Tanous <ed.tanous@intel.com>]

On 8/9/19 12:33 AM, Alexander A. Filippov wrote:
> On Fri, Aug 09, 2019 at 12:19:32PM +0530, Raviteja Bailapudi wrote:
>> Hi all,
>>
>> We are looking for thoughts and perspectives on the way the persistent files
>> are managed across BMC code updates.
>>
>> The problem is regarding the code update where, as a part of code update we
>> don't touch any of the persistent files like /etc/group or /etc/passwor
>>
>> what if the new BMC image has an application which requires some changes to
>> be present in these persistent files ?
>>
>> For Example:
>> Let's say the BMC image which is used for code update has a new
>> feature(ex:avahi) and it requires avahi user and
>> the group to be present in the /etc/passwd and /etc/group to even kick start
>> it's daemon.

One way that I've seen work quite well in other production firmwares is
to treat it like you would a database schema, and simply generate the
"new" files via patching the existing file in a script that executes on
first new firmware startup.  In general, when you're messing with these
files, you're either appending a new line, which would be done with a
script like:
if grep -Fxqv "avahi:x:41:" /etc/group
then
cat "avahi:x:41:" >> /etc/group
fi

or you're modifying an existing line, which would be done with a sed
replace.

In the above, we're checking to see if the file has been changed
appropriately before actually appending the line, to make sure that the
update only gets applied once.  I've seen other cases where it makes
more sense to simply leave a separate marker file, with an arbitrary
revision number so that the BMC knows which updates it needs to apply.
It really all depends on what you're attempting to add and whether or
not it could conflict.

If you're careful about how you craft the matching regexes, and keep the
scripts around forever, you can generally transition files like that
from one firmware update to another without any ill effects.

The only case where it doesn't work is in the downgrade case, which gets
really tricky really fast, and why most vendors give a "your mileage may
vary" warning on downgrades, and recommend defaulting the configuration
after a downgrade.