Unable to copy running-config to non-existing startup-config

[rical]

Current Behavior

No user can copy running to startup if startup doesn't exist or the full path name is given (copy running /cfg/startup-config.cfg)

root@ix-00-00-00:/> copy running-config startup-config 
Error: setting group owner wheel (10) on /cfg/startup-config.cfg: No such file or directory

No startup-config.cfg is created here ^

root@ix-00-00-00:~$ ls /cfg/startup-config.cfg 
ls: /cfg/startup-config.cfg: No such file or directory

Expected Behavior

root@ix-00-00-00:/> remove startup-config.cfg
Remove /cfg/startup-config.cfg, are you sure (y/N)? y
root@ix-00-00-00:/> copy running-config startup-config 

Steps To Reproduce

root@ix-00-00-00:/> remove startup-config.cfg
Remove /cfg/startup-config.cfg, are you sure (y/N)? y

root@ix-00-00-00:/> copy running-config startup-config 
Error: setting group owner wheel (10) on /cfg/startup-config.cfg: No such file or directory

Additional information

This problem manifests itself by throwing this chown error but the main problem is that no start-config is created. The command copy running startup takes a different code path than copy running /cfg/startup-config.cfg.

[troglobit]

I think the root cause is that following should be && instead of || -- so that we can enter the first if() statement to reach systemf("sysrepocfg -d %s -X%s -f json", srcds->sysrepocfg, fn);, but I don't understand how this could work if the file exists ... 🤔

infix/src/bin/copy.c

Lines 241 to 244 in dd788f5

	if (!srcds->path || !dstds->path)
	goto err; /* done, not an error */
	/* allow copy factory startup */

[rical]

I had a quick look.

startup-config is the only infix_config with a path, that causes the error printout from the permission code. But I'm not sure this is purely a problem with the copy code. If the file exists it's updated properly but I don't see any explicit writes to it in the copy code? Is it sysrepo who updates the backing file (/cfg/startup-config.cfg)?

EDIT: To clarify, the copy running /cfg/startup-config.cfg works as it takes a totally different code path as /cfg/startup-config.cfg is treated as a file and not a data store.

[jovatn]

CCB: Future

[troglobit]

Found the root cause for this now. Turns out the copy command does "nothing" when we save running to startup, instead it's a trigger in confd:core.c that runs -- but only if there have been any changes to the startup datastore.

Took me a while, but I'm now recalling that one of the reasons for this weird design is that we have users that script Infix using sysrepocfg, who expect sysrepocfg -d startup -C running to persist across boots.

[troglobit]

The trigger in confd, core_startup_save(), runs for each change registered. E.g., for nine changes in running config, we will call sysrepocfg -X/cfg/startup-config.cfg -d startup -f json nine times. Less than ideal, obviously.

So if /cfg/startup-config.cfg is removed manually, running-config is updated, followed by another copy running-config startup-config from the CLI, the file will be created, but with the wrong permissions.

[troglobit]

There are multiple ways forward here, a radical one is to remove the tools sysrepocfg and sysrepoctl -- do we really need them if we ensure the CLI and our own command line tools link with libsysrepo and use the C API instead?

Another, perhaps less invasive which would allow us to drop core_startup_save() is to patch sysrepo to support an alternative (single) backend-store file for startup, /cfg/startup-config.cfg.

Personally I vote for the section option, either way a decision needs to be made before the copy command can be simplified/refactored.

[troglobit]

After discussions during today's CCB we agreed we need something fundamental to fix this issue, and @wkz suggested instead patch sysrepo to add a post-hook with a datastore argument. That way we could at the same time remove our own num_changes hack in confd:core.c