The code assumes both SRC and DST is passed, here we ensure this
early.
Prior to this patch:
root@host:~$ copy foo
Segmentation fault (core dumped)
Signed-off-by: Richard Alpe <richard@bit42.se>
Prior to this patch the errno value was overwritten by getgrgid()
making the printouts invalid:
Error: setting group owner wheel (10) on /cfg/startup-config.cfg:
Success
Signed-off-by: Richard Alpe <richard@bit42.se>
Avoid a theoretical race between getting the number of groups a user
belongs to and actually processing them. We should not need to check
the return value of getgrouplist() as we know the number of groups fit
inside the buffer.
Signed-off-by: Richard Alpe <richard@bit42.se>
As per earlier decsision, the .cfg suffix is no longer implied when a
user copy to a regular file, so we should allow tab completion in the
copy command to show foo.cfg, otherwise the copy command will fail.
Skip /cfg/startup-config.cfg since it's treated as a special case and
added to the list by the infix_datastore() plugin function.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
When copying a file to a directory, the file should be accessible (read
+ write) by all members of the group that are allowed write access.
E.g., an 'admin' level user creating a new file /cfg/foo.cfg should
result in the file being owned by $LOGNAME:wheel with 0660 perms,
because /cfg is root:wheel.
Writing to already existing file, e.g., created by 'root' at first boot,
say /cfg/startup-config.cfg should be possible by all members of the
'wheel' group. In this case thef file already exists as root:wheel and
any user trying to chgrp it will fail, this is fine.
Fixes#977
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
For future readers, the user paramenter to the copy() function is
actually the remote user in any curl command.
Also, realign columns in infix_config[].
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
{topdoc} is needed for asciidoctor to find the image during test
report generation.
This is the same functional change as 02d8288863 but with the
generation script actually updated. This was forgotten in the last
commit.
Signed-off-by: Richard Alpe <richard@bit42.se>
Turns out the root cause for the odd log message in #896 was that the
system did not properly call `resolvconf -u` when starting in failure
mode.
This patch simplifies the code by moving all `resolvconf -u` calls to
the same Finit task. Ensuring it is first launched when confd has
successfully consumed any configuration at boot, and then every time
a static DNS server is added. (The udhcpc client script already call
`resolvconf -u` when dynamic DNS servers are learned.)
Fixes#896
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The following log message does not stem from an error in setting up the
chroot, but from the internal communication with the chroot. This patch
adds the crucial missing file name in the log message.
avahi-daemon[3590]: chroot.c: open() failed: No such file or directory
So that when the user sees this message, e.g., with "/etc/resolv.conf"
as the arg. to open(), they can be certain; "ah, no a biggie, we have
not created that file yet!"
Issue #896
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Either indent by four spaces or use backticks. Depending on the output
generator they may apply different styling though.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Mattias Walström