- 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
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
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
We have a hard dependency on netcat-openbsd, see:
| commit 26ba0340b6
| Author: Alexander Lutay <alutay@sipwise.com>
| Date: Mon Jun 4 13:22:27 2018 +0200
|
| TT#37401 Fix 50ecc1544: depends on netcat-openbsd since we use 'nc -U' (not available in 'netcat-traditional')
But our docker image still uses netcat-traditional.
Make sure to have netcat-openbsd available, while at
it also adjust Build-Depends accordingly.
Change-Id: I1d3cfd9b4b56047fa51c3ef1d77060122f4d2568
This makes it possible to depend on this new package while not having to
pull the huge amount of dependencies.
Change-Id: I2df3d072ecca0751d4d05d30f5b5c1ac0ec4ed25
This file should be installed only for the ngcp-ngcpcfg package, as
that's the one making sure etckeeper is installed, and we only need
one doing the setup, not all the rdepends too.
Change-Id: Ib20111ada44964a3bdfda4c50a84971cf9678eb9
The perl Template::Toolkit is very rich, but its "function" support is a
bit poor. The ways to do it are either via MACRO directives, or by
simulating them with one function per file and then using PROCESS on
these. The problem is that this is very clunky, does not support
nesting, as we'd need different "argument" names for each "function",
and it's quite cumbersome to use, need to assign aguments passed
beforehand, and then assign back a designated return value from another
variable. This is also one of the reasons some of the functions are not
encapsulated, and have been inlined in various loops, because it was not
possible to cleanly PROCESS them from those call sites.
Instead we should use its native support for perl objects and perl
subroutines, which exposes these as proper methods of a designated
variable, and have none of the above mentioned problems. So we'll switch
from constructs such as:
argv.arg-a = variable;
argv.arg-b = 'value';
PROCESS 'path-to-library-dir/function'
result = out
into:
result = ngcp.function(variable, 'value');
In addition this might actually be faster, as it does not require
processing additional files, and it's all just native perl code.
This will be exposed within the NGCP templates as the ngcp object, and
new member functions will start replacing our old and clunky native
Template PROCESS-style library.
Change-Id: Id2f0d181c695a9dd074646881b7d9de3478570af
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
* sync_db_timezones use 'mysql_tzinfo_to_sql'
to load timezone info from /usr/share/zoneinfo into
MariaDB.
* tzdata package version is checked and the timezone data
sync is skipped if the version in ngcp.tzinfo_version
is already up to date.
Change-Id: I92c87fb52fea20df0366c93c2e3568c25833b9bb
We should not list a virtual package first, because we do not know what
will end up being installed. Select a modern implementation of netcat
and place it first.
Change-Id: I9d5a54fee12e4b53f07127f886d92f6253de1409
Stop inferring from the metapackage presence and instead use the
variable general.ngcp_type from the constants.yml file which should now
always be present.
Change-Id: I68e97f6894094fe6a1589fa73b048b061eae4a7b
The latter does not support YAML 1.1, nor many parts of the
specification. Use the more compliant implementation, in addition to try
to converge to a single one, so that we do not get serialization delta
surprises.
Change-Id: Ie51f1c79859d40ef0877fc0ab75f86ee72e14ea4
This script will validate the network.yml based on a schema constructed
from information only available from the network.yml file itself. This
way we can do the strictest validation, which we could not do before.
Change-Id: I32714e678e901e58d70e4253bcc61a147494c225
This module is more compliant and it is faster than the pure perl
implementation. The latter is also deprecated in favor of the former
(see man YAML for more details).
Change-Id: I3fccca4ab57ad7c316b6cf58a81bc4baa1bdabe1
The old testsuite wasn't updated for way too long and since
ngcpcfg receives more and more features we need a decent test
coverage. pytest seems to provide the right level of
abstraction, excellent fixtures and junit-xml reporting as
needed.
Inspired by Vincent Bernat's
https://github.com/vincentbernat/lldpd/tree/master/tests/integration
Thanks Victor Seva <vseva@sipwise.com>, Vincent Bernat <vincent@bernat.im>, Christian Hofstaedtler <christian@hofstaedtler.name> and Lukas Prokop <admin@lukas-prokop.at> for feedback, inspiration and help
Change-Id: Iffed87e8cc540169bed89c00967a03e80859179e
This reverts commit 8a6053a104.
We can't run autopkgtest runs inside *-binaries jobs yet
since they don't support PPAs which we depend on.
So until we've a working solution for this let's revert this.
Change-Id: I99035ca33049ca6f9c698fd78c9064504cf2409b
Make sure ngcpcfg binary is available and installed
appropriately for execution.
Provide placeholder files for the configuration files
that are needed for ngcpcfg execution.
This serves as a starting point for further system tests
during Debian package build time.
Change-Id: I70dca5e4bed6a896f31c3a3eb909da17e496fc92
It is hard to clean ngcpcfg framework for users with
limited git knowledge, lets introduce action 'clean'.
It should allows users easily reset to 'previous safe state'
in the case 'if something went wrong'.
Also remove old and unreliable error handling hint from manuals,
as we have switched to fast-forward rebase long time ago.
Change-Id: I961e681d55cac15ba8d772b9345c668218313bf4
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
Guillem Jover
Alexander Lutay
Sipwise Jenkins Builder
Richard Fuchs
Michael Prokop
Kirill Solomko