We check whether we have both a sites.yml and a sites/ directory.
If so, and multi-sites support is enabled, then we proceed to load
all the multi-sites configurations, by placing each of them under
«sites.<site-name>.<config>». Adding a «sites.current» link to the
current site, and filling the root tree config with the current site
as well for backwards compatibility.
Change-Id: Ia810f57e8e976eef6a7582bddda46c1701456ed6
This variable has been deprecated for a long time (since mr10.5), and it
is not used anywhere in our entire NGCP code base.
Change-Id: Ic142a347fcef0405f8cf8304728b076af3369e0d
We currently only fix up owner and permissions for known local files,
including the stock config.yml and any variant affecting the current
host (which include role selectors, pair or host specific files).
The problem is that when pushing these to the remotes where the files
are local there, then their permissions will be fixed up, and that will
happen independently for different files on different nodes. Which
results in git conflicts when trying to merge back these files.
Instead add a new variable that contains the glob for all such
customized files which we will fix up in the current node.
Change-Id: Ib2a7317a92733ad5b4d2fa8106759b00049edb68
The configuration files specific to the ngcpcfg tool should not be
mixed with the site specific configuration, as that's rather confusing,
more so when the actual ngcpcfg configuration contains references to the
location of the ngcp-config dir itself, which makes it self-referential.
Change-Id: I93f59e2ce3441c2c315956f68e22e4b2e9c839ac
This makes it clear this is not an ngcpcfg tool specific file but one
more in line with the cfg-schema and friends. It also gives it a proper
extension to make it clear it is a YAML file.
Change-Id: I6f19945a3ffc0e1406024b60e401688d7d3c68cc
The HA_NODE, HA_FILE and HA_CONFIG variables and nomenclature are
deprecated in favor of the NGCP_NODENAME, NODE_FILE and NODE_CONFIG.
Switch the old uses to the new ones. Unify PAIRNAME to NGCP_PAIRNAME.
Leave the old HA_ variables for backwards compatibility
Change-Id: I11f09f1620c2e456f10fc17229b61ec5a35a732b
> # Backward compatibility config for upgrade mr3.4*->mr3.5*
> # it can be removed when the next LTS is released:
Change-Id: Ie93fc45965251dc3384a3b624339d45ad144683f
we need to produce different output for each instance defined
from the same source
* helper/instances-info, produces the needed output to feed
helper/tt2-process with the proper arguments to build
instances files. We inject ``instance_name`` with the
proper value to templates and INSTANCE_NAME to hooks
environment
* ${NGCPCTL_MAIN}/ngcpcfg.instances is where we define the
supported instance templates and where the output path is
* helper/tt2-process, add -r --replace <path:path> option
in order to allow generation of different output from
the same source
Change-Id: I067266b5226485ea0d6c3bc3436275c5553a8177
To get uniform and unexpected behavior we should use the exact same
precedence used with the tt2 files.
Fixes: commit 354e7578c5
Change-Id: I86281f3bd236687baec58b3a2e29cf80550176da
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
This makes it possible to use more specific config.yml files either for
a pair of nodes, for settings that will always affect both, or for the
HA names, for settings that might affect all A or B nodes.
This matches the support in the template files.
We need to move sourcing the ha_features and carrier_features before
sourcing init, as now the ngcpcfg.cfg file can use these variables if
set.
Change-Id: Ic6b32acceb8f020f48c3afa09d9e84252b3531e7
This reverts commit 55c5c6df89.
We need to inject scripts that requires ngcpcfg services files to be
executed, which does not work because those are only honored for /etc
pathnames.
Instead we will just create a symlink back to /etc where we will
install all the needed scripts.
Change-Id: I66b61dea93ed320117bbdf019a4c0a4b2582042f
The monit-services OCF Resource Agent for pacemaker needs to be
installed there.
Ideally we would not need this, but as this is the only location
allowed by pacemaker, let's add it, even if we might at some point
end up not using it, as we can just not install any templates in those
directories.
Change-Id: Ib14b68388f018b45bc4d7cf6895ca17d0fc802a3
according to security framework spec
5.5.4 Allow r/w access /etc/ngcp-config/config.yml for users in security
domain ngcp-admin This file contains operational configuration data of
the NGCP system. Reading and editing it is part of day-to-day
operations. As such it has to be read- and writable by users in security
domain ngcp-admin. It is also readable by users of any other security
domain. This file is also read by many NGCP processes.
The current default setup of the NGCP does not implement permissions as
required by tightened user security. Required permission settings have
to be applied manually issuing command:
chgrp ngcp-admin /etc/ngcp-config/config.yml
Security domain: ngcp-admin User ownership: root Group ownership:
ngcp-admin File permissions: 664
IMPACT: Configuration data can be edited by all users in group
ngcp-admin, the sipwise user, and user root. If for some reason (e.g.
after upgrade) the proposed settings are reverted to default settings,
this does not pose a security risk. However, write access to
configuration data in this file will be denied to named users.
5.5.5 Allow r/w access to /etc/ngcp-config/network.yml for users in
security domain ngcp-admin This file contains information about the
network configuration of the NGCP cluster. This information should not
frequently change. Nevertheless, this file and its content is meant for
the operator and as such is read- and writable by users in security
domain ngcp-admin. It is also readable by users of any other security
domain. This file is also read by many NGCP processes.
The current default setup of the NGCP does not implement permissions as
required by tightened user security. Required permission settings have
to be applied manually issuing command:
chgrp ngcp-admin /etc/ngcp-config/network.yml
Security domain: ngcp-admin User ownership: root Group ownership:
ngcp-admin File permissions: 664
IMPACT: Configuration data can be edited by all users in group
ngcp-admin, the sipwise user, and user root. If for some reason (e.g.
after upgrade) the proposed settings are reverted to default settings,
this does not pose a security risk. However, write access to
configuration data in this file will be denied to named users.
5.5.6 Restrict access to /etc/ngcp-config/constants.yml to users in
security domain root This file contains values set during the
initialization of the NGCP system. It contains passwords used by
different NGCP functions to connect to other secured subsystems (e.g. DB
or lawful intercept). As such the file has a high security impact and is
read- and writeable to users of security domain root only.
The current default setup of the NGCP does not implement permissions as
required by tightened user security. Required permission settings have
to be applied manually issuing command:
chmod 600 /etc/ngcp-config/constants.yml
Security domain: root User ownership: root Group ownership: root File
permissions: 600
IMPACT: Data in this configuration file are usually entered once during
commissioning of the platform. Only users root or sipwise can edit or
read this file. The customer’s named users have no access to this data.
If for some reason (e.g. after upgrade) the proposed settings are
reverted to default settings, this poses a security risk as credentials
used internally may be leaked to unprivileged users.
Change-Id: I49a2994a227b9c296966c805c9370ae3b067de12
Corrupted YML schema is the popular way for time spending on debug
mystery behaviour on NGCP. We have validation schema since mr4.5
and it coverts all YML files nowadays. Let's enable it by default,
since in field testing shows good results.
In case of the inconsistent schema, apply is still possible with
ngcpcfg option '--no-validate':
> root@sp1:~# ngcpcfg --no-validate apply 'some changes with inconsistent schema'
> 2018-08-29 13:12:27: Error: Invalid schema detected for /etc/ngcp-config/config.yml
> /etc/ngcp-config/config.yml#0: INVALID
> - [/apps] Expected required key 'malicious_call'
>
> DANGEROUS ZONE: invalid configs detected, continue anyway due to option '--no-validate'
> Checking state of local storage:
> ...
Change-Id: Ifa51c9e0c2fd396696f73760d89eadcbe9763456
As soon as we merge 2e74d71 to ngcpcfg.git we cannot install PRO/Carrier:
> /usr/share/ngcp-ngcpcfg/functions/ha_features: line 54: cd: /etc /var: No such file or directory
Change-Id: I124adc4e42d3c87d0f4fbf19b076986d757cff39
In a previous implementation using timestamps we ran into timing
problems on slower systems. So instead lets record the git commit
ID of the latest ngcpcfg commit and check whether we have a match
between this commit and an according ngcpcfg build.
If the "ngcpcfg build" was executed without an "ngcpcfg commit"
before then we mark it as dirty since we don't have an according
git commit available for testing against. Since that's a common
workflow we don't report it as a real problem though, instead we
inform the user using:
| OK: nothing to build (latest build newer than latest commit)
As we commit AFTER the build in the apply action we can use a
workaround for this situation, so build and commit state match
with each other in that case then.
Change-Id: I48e32db6f42b53fe97a0b88805e7ddbee8576133
This reverts commit db373d3927.
Conflicts:
etc/ngcp-config/ngcpcfg.cfg
Until we've a working solution for this let's revert
the broken change so we avoid this being a release
stopper.
Change-Id: If03d9b3913de23c698b430d583dc7babfcc4ff04
There are some times when a configuration, service or system upgrade
requires a reboot to take effect. When a component requires a reboot,
it will record this fact in the file system through the file
«/var/run/reboot-required», and «ngcpcfg status» will notify the user
that a reboot has been requested.
We use the «/var/run/reboot-required» because it is already being used
in the unattended-upgrades package on Debian/Ubuntu which does something
similar.
Change-Id: I43997bfb83892f67bd57bb55ad3ec0a41a5e088d
If the latest git commit has a newer timestamp than
our latest "build" action then a "build" (or apply)
run is required, inform the user about it.
Change-Id: I83e2ff47ba54da733d368d78b6616d13d31a66d4
Disabled by default as we need a time to check it carefuly.
Also we need to solve the "tilda" problem reported upstream:
https://github.com/eserte/p5-Kwalify/issues/1
Change-Id: Ia2c3d48f0ac6fc6ac9899d44f4291544373806d9
Otherwise we faced the error during upgrading the second node (sp2):
> Script started on Fri 29 Aug 2014 10:34:23 AM CEST
> Not prompting user for approval because environment variable FORCE_UPGRADE is present.
> /usr/share/ngcp-upgrade-trunk/upgrade-stable-to-trunk - start on Fri Aug 29 10:34:23 CEST 2014
> Looks like you are running Debian 7 already.
> Checking for (possibly) outstanding ngcpcfg changes
> /usr/share/ngcp-ngcpcfg/functions//main: line 78: TEMPLATE_POOL: unbound variable
The node sp1 has been upgraded succesfully but new config ngcpcfg.cfg has been
delievered to sp2 and old ngcpcfg framework failed to start with new config.
Those workaround can be reverted as soon as next LTS release is released.
Change-Id: Idb1f4ca05e88e7a30054ace0c0b47dc0eadf1b7a
Files in configuration directory EXTRA_CONFIG_DIR (being
/etc/ngcp-config/config.d/ by default) with the suffix yml (so
e.g. a file named pbx.yml can be shipped by an external Debian
package) are additionally taken into consideration as main
configuration files.
Those extra configuration file(s) have higher precedence than
the other yml configuration files (config.yml, network.yml,...),
*except* for constants.yml which has the power to override all
settings, including the ones from files inside EXTRA_CONFIG_DIR.
Closes: sipwise-#3059
Guillem Jover
Mykola Malkov
ngcp-config
Michael Prokop
Richard Fuchs
Alexander Lutay