- Remove epub output as asciidoctor requires unpackaged support.
- Remove html and pdf output as it is not known to be used anyway.
Change-Id: I7089e01ef17dbc40df08b796f48bcd8616936145
Long long time ago (around release 2.8) we started filling
the default HA pingnodes because most of our customers didn't care about them.
Lack of pingnodes was causing problems on PRO/Carrier as HA was not
being able to make correct decisions about the cluster state which causes
split brain and both nodes might end up being active.
The idea back then was to use some IPs which MUST always be reachable:
- gateway
- primary DNS server
- secondary DNS server
NGCP is barely usable (or likely unstable) if some of the IPs above is no reachable.
Sure, those IPs can be redefined in config.yml by the customer IF the customer provides more the 3 IPs.
In the past we didn't have GW and DNS IPs in network.yml,
also NGCP did NOT generate /etc/resolv.conf and /etc/network/interfaces from templates.
Nowadays we have all such information AND generate /etc/resolv.conf from network.yml.
However /etc/ha.d/ha.cf was NOT reconfigured against network.yml but still uses workarounds.
The macro used in /etc/ha.d/ha.cf reads /etc/resolv.conf to fetch DNS addresses.
It causes a list of problems on cloud-based installations (and not only there).
Problem description:
When DHCP is enabled, the server receives IP from DHCP and normally DNS servers
are also included in DHCP packet => Linux/networking saves DNS in /etc/resolv.conf on boot.
Later 'ngcpcfg apply' happens and builds all the files in alphabetical order.
Unfortunately the order here is /etc/ha.d/ha.cf ... /etc/resolv.conf.
So, ngcpcfg builds /etc/ha.d/ha.cf first and inserts there DNS IPs from /etc/resolv.conf->DHCP
and not IPs from network.yml. Some seconds later DNS IPs from network.yml will
be written in /etc/resolv.conf (as we have ngcpcfg template for /etc/resolv.conf since ~mr4.5).
As a result we do change /etc/ha.d/ha.cf twice:
- to switch HA from old DNS IPs/pingnodes to pingnodes from DHCP
- to switch HA back from DHCP DNS IPs/pingnodes to pingnodes from network.yml
It causes two unexpected HA restarts and confuses operators a lot.
We should be safer here and use such sensitive data from one place -> network.yml
The GW/DNS IPs search logic here is a copy of logic from template /etc/resolv.conf:
> For your host find the interface in network.yml which has the gateway defined.
> Use GW/DNS IPs for the interface you detected above.
Change-Id: I055e17e20bfd2bc722388c61db12ff5c156e9ecc
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
We are calling slow Perl command to move files to workaround Docker problem
and losing 25% of performance on every NGCP installation in production.
Let's call slow workaround when it is necessary only (in Docker).
Command: time ngcpcfg build
Original results: real 0m19.976s
Current results: real 0m15.286s
Change-Id: Iac787c0fcdb4182d71b6305ebbba5ea3193e76c8
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
We are performing complex manipulations with list of files to be build
to understand which tt2 file we should use: .tt2/customtt.tt2/tt2.sp1/...
In the same time 90% of our files has only .tt2, so let's check the count here
and use the $file if only one record is available to proceed.
Change-Id: Ib754390563a93a1fbdeb4a4147b066fcb53ed5cc
The previous code had three including loops:
- loop over all folders ${CONFIG_POOL}
- run find to get list of all files
- loop over all files in list
- check if no files requested (build all) then remember file
- loop over all requested files
- check if file was requested then remember file
- process further with all files we remembered above
The new logic is much simpler and faster:
- loop over all folders ${CONFIG_POOL}, remove missing
- run find on all available folders to get list of all files 'filelist_allfiles'
- check IF no files requested (build all)
- THEN just use all files from list 'filelist_allfiles'
- ELSE loop over all requested by user files (normally one/several)
- grep requested file from 'filelist_allfiles'
- process further with all files we remembered above
The two main ideas here:
- just use all files if we build all files, no need to loop one by one
- grep requested files from "all files" instead of searching them in loop
At the end we are 30% faster in case if we build one file only:
> Command: time ngcpcfg build /etc/default/ngcp-roles
> Old code: real 0m1.587s
> New code: real 0m1.060s
Change-Id: I206557b004ff95c0607150a61a9e6e743ab8cd29
for the intermediate-cdr exporter, a similar .conf is
to be generated. intermediate cdr data will be available
in tables with the "int_cdr" prefix.
the macros in get_cdr_export_fields are therefore required
to switch printed table names (ie. "cdr", "cdr_tag_data")
accordingly (ie. "int_cdr", "int_cdr_tag_data").
the existing "type" argv is used as switch param.
Change-Id: I74fc4c91acf285d621b9ecf26a050ccf131139c4
It produces security issues when diff is stored in logs (e.g. upgrade logs)
and may contain passwords or another secrets. The special option '--diff'
is introduced for users who require old behaviour.
Change-Id: Ie4fd1ef2ee7fe1a51e87a99e36b5f71f6ecc8084
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
These files are an intermediate data source, which are being used also
during builds of templates. We cannot make them first stage YAML sources
as they do depend on information coming from the first stage YAML
sources themselves. So we need to special-case them to make sure they
are always built first, so that the other files have up-to-date
information to use when being built.
Change-Id: I6cfd6e80823ddfaf71e2246de5518b9cb6d6a1d2
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
The dpkg-query command already has an interface to fetch the field
value, so there is no need to use --status, grep and then parse the
output.
Change-Id: I13a2f601bde4ca01bfbd7db35f8a1ff11175fba3
An alias for a vlan interface will not have a raw device, stop requiring
it. And an alias for a bond interface might not have miimon, mode or
slaves attributes.
Change-Id: I4b0f547f1c1d02ee826ad97db1a1f44ab91c0e63
The point of an interface alias is to have a different IP, so let's make
that required for any alias, but not for vlan interfaces themselves,
because they might be used for bridging for example.
Change-Id: I7b0fdc0d5cb327c774d6e98ccd7a61c4e6c19b8b
These services files just setup some sysctl settings and should always
be safe to be executed first. In this case we do require them to be
executed first, because many of our services are binding into the shared
IP, which will not be present on the standby node, and would otherwise
fail.
Change-Id: I0df095403461268cdff8517ee5c369355ca9228c
We already know what we have processed and what remains from the
complete list and the new partial list. Use that instead of hard-coding
the directories, which is error-prone as it requires keeping both lists
in sync.
Change-Id: Ia16ac6999beaf89f4c2fb5b74216d0bf17de8414
NGCP uses 'YAML::XS' as only the library to work with YAML files.
Meanwhile pkwalify has a long fallback list:
> @try_order = ('YAML::XS', 'YAML::Syck', 'YAML', 'JSON::XS', 'JSON');
It may hide some issues in validation schema (used by 'ngcpcfg check')
and bypass the testing on Gerrit reviews, but failed to 'ngcpcfg apply'
on the customer's system.
Example:
1) cfg_schema.git had a bug in validation schema committed long time ago
in mr6.1+ , commit b9d69e0b33d316c04d8b70536f1e166fec9a67ac.
The commit passed review and all internal testing:
> https://gerrit.mgm.sipwise.com/#/c/17825/ ->
> https://repoapi.mgm.sipwise.com/job/cfg-schema-ce-validation-docker/849/console.txt
> ...
> + ngcpcfg --validate check
> 2017-12-20 14:34:37: yml configs were validated successfully
The bug was simple, the space was missing in schema:
> "rtcp_logging_facility":{ type: str, required: yes }
The library 'YAML::XS' was not able to load the YAML file.
Meanwhile the library 'YAML' was able to load it and pkwalify happily reported us
"yml configs were validated successfully".
2) Later another developer has noticed the problem with YAML schema here
and fixed it in trunk, commit 4636eadb78e5e91dd6d93378a42a8df2ed84838a.
> - "rtcp_logging_facility":{ type: str, required: yes }
> + "rtcp_logging_facility": { type: str, required: yes }
Unfortunately the fix has been applied in trunk only.
3) Later the third developer committed new code which was valid
for 'YAML::XS' but invalid for 'YAML' library (which is fine, as NGCP uses 'YAML::XS').
Since in trunk pkwalify used 'YAML::XS' the changes passed all the testing:
> commit a79e54fb9fbdf0db61b4dfb9c52e572795e854af
> https://gerrit.mgm.sipwise.com/#/c/28486/ ->
> https://repoapi.mgm.sipwise.com/job/cfg-schema-ce-validation-docker/1987/console.txt
> ...
> 2019-04-05 17:20:08 06828d6f31f5: yml configs were validated successfully
4) Later the third developer backported the commit a79e54fb9fbdf0db
to the previous release mr6.5 (where commit 4636eadb78e was missing).
And nightly upgrade tests has failed on mr6.4->mr6.5 upgrade saying:
> 2019-04-09 04:06:27 sp1: Error: Invalid schema detected for /etc/ngcp-config/config.yml
> Cannot parse </usr/share/ngcp-cfg-schema/validate/config.yml>. Cumulated errors:
> YAML::XS::Load Error: The problem:
> did not find expected key
It happens because pkwalify was not able to load config.yml with any libraries it support.
We have to force pkwalify to use only the library NGCP is using 'YAML::XS'.
This is a commit about it.
Hopefully all the necessary changes have been done by Guillem 2 years ago,
and were uploaded upstream (and even available in default Debian buster):
> https://github.com/eserte/p5-Kwalify/pull/6
Thanks to Guillem Jover for the library fix here and for the help with tracing this issue.
Change-Id: Idbd46b4048a03b5b01a0280a6dcd50406b4222dc
This is necessary when the HA_INT addresses are being changed, the communication
is not possible in that scenario.
Change-Id: I658a4f40e4f5b13d6ac224978999789728d8b915
Change introduced in commit bc1095e596 as part of
the task:
TT#37257 Add option 'ngcpcfg apply --force-all-services' to force all services restart
Change-Id: Iabfd6c78091db98a74a41a0d050f7d090f9443a7
We will gather the actions from within policy-rc.d and then execute all
of them in a single batch.
This will make sure any required restart or reload is performed even if
there has been no template file changes.
Change-Id: I6458936860a86ddb10cd738a8f2770c109d9ed37
The options offload-lro and -tso were required by customers to set up properties
for individual network interfaces, and this tool implements similar options as
helper to set-up network.yml and ultimately /etc/network/interfaces.
Change-Id: Ib6f1c2b6be2c88da10cc8576f83a9f1c72d78d58
Guillem Jover
Alexander Lutay
Rene Krenn
Richard Fuchs
Sipwise Jenkins Builder
Michael Prokop
Andreas Granig
Manuel Montecelo
Marco Capetta