We move some of the OpenPGP support into this file, which we will extend
once we switch to use the OpenPGP Stateless OpenPGP support.
Change-Id: I56acd993cb394dd8bc12a8da3cf4c78088adb61b
We can simply feed the encrypted or unencrypted tarfile both when
decrypting and encrypting it, so that we do not have to leave one
around with the additional disk space, and danger of it not getting
removed.
Change-Id: If8c9fba36fd14c58cccacc789a0e4f8e474aac3f
Rename gpg to pgp or OpenPGP and remove crypted from filenames.
The standard is called OpenPGP, GnuPG (or GPG, gpg) is one of many
implementations (although depending on the context the prevalent one)
so we use that when referring to the specification.
For the encrypted tarball we remove the «-crypted» term which is an
odd wording use for encryted content and it is unnecessary and confusing
when using layered containers (as when the tarball is decrypted the
name becomes invalid); and make it use «.pgp» instead of «.gpg» as
extension, while trying the old filename on decryption for backwards
compatibility.
Change-Id: If5e0349ff0c3d8e3b47ced361e9e77d7d4d2defc
These functions were previously in the main functions file, which we
could not use as it depends on configuration files we do not have
available while decrypting these same configurations. But these got
split up for performance reasons into its own functions file. We can
thus now switch to use that instead of having to keep the same functions
in sync in multiple places.
Change-Id: I3860d747e575146d4ffc1a6fc8160d7aa16925ed
We are prepending an extra / to the pathnames passed to tar, and
calling tar from a directory other than the root directory while
not telling it to use absolute names so it complains about these
two things with the following messages:
,---
tar: Removing leading `/' from member names
tar: Removing leading `/' from hard link targets
tar: Removing leading `//' from member names
tar: Removing leading `//' from hard link targets
`---
which is something the user cannot do much about, and it's rather
annoying.
Change-Id: I9e9c853f26363e451b8883d3c74c5508ba3049dc
Fixing issues reported by new shellcheck v0.9.0:
1) SC2317 (info): Command appears to be unreachable. Check usage (or ignore if invoked indirectly).
https://www.shellcheck.net/wiki/SC2317
(new feature as of shellcheck v0.9.0)
2) SC2086 (info): Double quote to prevent globbing and word splitting.
https://www.shellcheck.net/wiki/SC2086
(behavior change with shellcheck v0.9.0)
Change-Id: I73d50157f72b772c381cf1bff497079133bc6d09
We are using console_output() from within log_info(), which is invoking
`console_output "$*\n"`, so we need to expand the escape sequences
(without interpreting other format specifiers), which is exactly what
"%b" provides in bash.
This is a fixup for previous commit 0dda93ad97
Change-Id: I16f354eb35e13568331e5107aff0d1c80dafb822
shellcheck v0.7.1 complains about a bunch of issues:
SC1083: This { is literal. Check expression (missing ;/\n?) or quote it.
SC1083: This } is literal. Check expression (missing ;/\n?) or quote it.
SC1090: Can't follow non-constant source. Use a directive to specify location.
SC2034: foo appears unused. Verify it or export it.
SC2059: Don't use variables in the printf format string. Use printf '..%s..' "$foo".
SC2128: Expanding an array without an index only gives the first element.
SC2148: Tips depend on target shell and yours is unknown. Add a shebang or a 'shell' directive.
SC2155: Declare and assign separately to avoid masking return values.
SC2162: read without -r will mangle backslashes.
SC2164: Use 'cd ... || exit' or 'cd ... || return' in case cd fails.
SC2181: Check exit code directly with e.g. 'if mycmd;', not indirectly with $?.
SC2207: Prefer mapfile or read -a to split command output (or quote to avoid splitting).
SC2237: Use [ -z .. ] instead of ! [ -n .. ].
We're still bound to support shellcheck v0.3.4 and sadly this version
fails hard when using the modern "shellcheck source=" directives to
address SC1090 and SC1091. It's failing like:
| not ok 1 source/functions/init:8:28: note: The mentioned parser error was in this then clause. [SC1009]
| not ok 2 source/functions/init:10:3: error: Couldn't parse this shellcheck annotation. [SC1073]
| not ok 3 source/functions/init:10:16: error: Unexpected "s". Fix any mentioned problems and try again. [SC1072]
So until we can get rid of supporting this ancient shellcheck version,
instead of using:
| # shellcheck source=etc/ngcp-config/ngcpcfg.cfg
| # shellcheck source=functions/init
| # shellcheck source=functions/logs
| # shellcheck source=functions/main
we need to place disable=SC1090 and disable=SC1091 accordingly.
Change-Id: I14da87a00102609bffdb60e932045180c6d13d5e
We need to use some folder on glusterfs to ensure it is reachable.
/mnt/glusterfs/mgmt-share is good enough here as /mnt/glusterfs/shared_config
is no longer available.
Change-Id: I9f604db9604af41405cfd7b088abb332a463fe4d
Git doesn't track file permissions (except for the executable
flag). For sensitive data (like the 'ssl' directory and file
'constants.yml' with passwords included) we've to prevent
non-root users from accessing those files.
hooks/pre-commit is inspired and based on the implementation
as present in etckeeper (and luckily we're license compatible)
and takes care of storing the file permissions inside file
/etc/ngcp-config/.ngcpcfg_perms.
The restore-permissions helper script takes care of restoring the
permissions after cloning the ngcpcfg repository via ngcpcfg
itself (being actions decrypt, pull (PRO-only) + initialise
(PRO-only)). It can be executed manually as well via
`usr/share/ngcp-ngcpcfg/helper/restore-permissions /etc/ngcp-config/`
(or wherever the according ngcpcfg repository is placed at).
Regarding the commit integration: git(1) itself doesn't track
file permissions, so we can't detect changes to file permissions
using git itself. Our new pre-commit hook records file
permissions via the .ngcpcfg_perms file. Now by just invoking it
during 'ngcpcfg commit' time we can ensure that even if there
have been any file permission changes in the working directory
the file .ngcpcfg_perms is then up2date and committed.
JFTR: The solution via the git pre-commit hook ensures that no
matter whether you're using 'ngcpcfg commit …' or 'git commit …'
you always get the file permissions handled via .ngcpcfg_perms.
Now if you want to change file permissions in a clean working
directory and commit *without* using 'ngcpcfg commit' but
directly via git itself then you've to use 'git commit
--allow-empty ...' and thanks to the pre-commit hook the file
.ngcpcfg_perms will still be up2date.
Change-Id: I84d608585c626b52112ff649893e232e441c59d8
The file should be accessible only to user root.
Also don't leave the unencrypted file /etc/ngcp-config-crypted.tgz around.
Change-Id: I82f7f36d8561d8d5e82435edb70e11170fa6c082
Guillem Jover
Michael Prokop
Alexander Lutay
Victor Seva