In the past helper/build_config generated new tmp file for every call
and we called it for hundred+ times. Let's generate it once and pass
to helper/build_config to be reused every time.
Command: time ngcpcfg apply "test"
Old code: real 0m17.194s
New code: real 0m15.477s
Change-Id: Ic1c35ccb5c5f92ddee6328502194a5301123bd9d
We do abort building on the first broken file due to 'set -e' above.
Having $RC variable here which collects exit code is very confusing.
Change-Id: I415bc77d8becf317c1be6b5ac493be2583479e00
About 50% of previous helper/build_config execution was loading 'functions/main'
and we were performing it again and again for every tt2 files we build
and we have more then hundred files in ngcpcfg.
In fact we need two env variables and logging functions.
Let's extract them into the separate function file and load them only.
Command: time ngcpcfg build
Original results: real 0m27.766s
Current results: real 0m19.976s
Change-Id: I6896ac437b1548888db7702de92b0ec79ed9d03f
Otherwise:
> warning: Brace expansions and globs are literal in assignments. Quote it or use an array. [SC2125]
Change-Id: I5a209cc1b50cea37e13aef40dfbd86c6178b53dc
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
This is necessary when the HA_INT addresses are being changed, the communication
is not possible in that scenario.
Change-Id: I658a4f40e4f5b13d6ac224978999789728d8b915
'git status' output has been changed in 2.9 which causes some troubles for us
(we didn't change all the places, we missed ngcpcfg-ha.git repo,
better to use common code in all the places).
Change-Id: Ie664af89ee6d6b31fb3011e763107c41bf4cf00f
If the file /etc/hosts gets handled by templates, as ongoing changes
attempt to do, there's a problem because /etc/hosts gets truncated to
create a new file when it's needed to generate itself, to resolve the
"localhost" string as hostname, so the generation fails and /etc/hosts
gets empty at that point, affecting the system until restored.
The simplest way to break that cycle is to switch to Unix sockets.
Change-Id: I1e33ead6a134625346b9cf1beb09a7bdbfdfc8d2
The new function will simplify initial customtt->patchtt
migration for end users. Some code was merged to be generic.
Also more tests were add here.
Change-Id: I7719f45275018818b2db82f6deee5b7428670a29
The 'ngcpcfg' received support for 'patchtt' files, like
> /etc/ngcp-config/templates/etc/foo/bar.patchtt.tt2
Those 'patchtt' are going to be applied on default 'tt2 template' file:
> /etc/ngcp-config/templates/etc/foo/bar.tt2
and produce 'customtt' on 'ngcpcfg patch':
> /etc/ngcp-config/templates/etc/foo/bar.customtt.tt2
Further 'customtt' will be used to overwrite 'tt2 templates'
on 'ngcpcfg build' or 'ngcpcfg apply'.
NOTE: 'ngcpcfg patch' is executed automatically on every 'ngcpcfg build'.
It should allows to update ngcp-templates easily and support
local modifications without the pain (until the patches can be applied).
Change-Id: Ice4369386313c5d33e4d498346345eade6f3d0d7
This option is essential if we're testing from within the git
repository and aren't standing on active 'master' branch.
Change-Id: I75b62d071116313317c69ad496e4425d6e98ad5a
When installing Debian/stretch we fail at this stage:
| ngcpcfg --no-db-sync commit
On first glance it looks like a mariadb issue, though actually
it's the git status check inside ngcpcfg that's failing. The
reason is that starting with git v2.9.3 there's a different
output in its "status" output:
| commit 2a0e6cdedab306eccbd297c051035c13d0266343
| Author: Lars Vogel <lars.vogel@gmail.com>
| Date: Thu Jun 9 20:19:30 2016 +0200
|
| Use "working tree" instead of "working directory" for git status
|
| Working directory can be easily confused with the current directory.
| In one of my patches I already updated the usage of working directory
| with working tree for the man page but I noticed that git status also
| uses this incorrect term.
|
| Signed-off-by: Lars Vogel <Lars.Vogel@vogella.com>
| Signed-off-by: Junio C Hamano <gitster@pobox.com>
In Debian/stretch we've 2.11.0-2 and are affected by this change.
Adjust the `git status` checks accordingly to support git in all
its versions.
NOTE: we should consider switching to `git status --porcelain`
(see git commit fc5af3bbb2 for
some history about it) once we've the testsuite in place.
Change-Id: If4223a35083d279e746dce5a80bcb86b52f64025
Make the relationship internal, instead of external. So that anything
that might end up calling the build script will always do the right
thing and we will not forget to perform required actions.
Change-Id: Iafc3bc7230c59750de7ec8bf825005011b48f403
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
We will use first free port instead which will be stored into
/var/run/ngcpcfg.port file while tt2-daemon is up and running.
Change-Id: I1a918f865d87863eef7d34be8abd1032282220b8
When runnning 'ngcpcfg build' (which is also executed when
running 'ngcpcfg apply') we waste quite some time with loading
the same YAML configuration files and merging them again and
again.
In a 'ngcpcfg build' run we don't have to re-load and merge those
configuration files again and again (since they won't modify
during a single run), instead just load+merge them *once* and
re-use the result on all the following execution steps in the
same run.
Original:
| # time ngcpcfg apply >/dev/null
| ngcpcfg apply > /dev/null 149.01s user 9.49s system 96% cpu 2:43.57 total
Reworked optimized runs:
| # time ngcpcfg apply >/dev/null
| ngcpcfg apply > /dev/null 81.25s user 8.62s system 95% cpu 1:34.17 total
For debugging purposes you can execute 'ngcpcfg build' under
NO_REUSE=1 to not use this feature, executing it under 'DEBUG=1'
won't remove the so called reuse file which stores the merged
configuration data.
Thanks: Alexander Lutay for the initial patch and idea
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
Alexander Lutay
Richard Fuchs
Manuel Montecelo
Guillem Jover
Michael Prokop