Under systemd we need to issue "daemon-reload" after applying
templates, to avoid spurious warnings when adding/changing/removing
systemd unit files.
Change-Id: Ifd474bec25b94ee9cb1c247b1390103a29c7b7b3
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 option is essential if we're testing from within the git
repository and aren't standing on active 'master' branch.
Change-Id: I75b62d071116313317c69ad496e4425d6e98ad5a
At the moment we provide no output for the end users, which
confuses them for the checks with and without the validation.
We should clearly report to users what has been checked.
Change-Id: Icc61744637345a1dc51fe8d8dd9bd3fd7f86824d
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
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
/var/log/ngcp/ngcpcfg.log might not contain error messages from
ngcpcfg's sync-db script. This might be confusing when comparing
output from the command line with the logged actions from
ngcpcfg.log. As sync-db doesn't log all error messages to stderr
anyway and we ignore exit code of the sync-db script as well (on
purpose) let's just redirect stderr and stdout to the same file
descriptor and then provide output to the console as well as
syslog's ngcpcfg tag.
Output before this change:
| root@sp1:~# ngcpcfg commit "before"
| 2016-10-25 22:12:20: Executing sync-db:
| DBI connect('database=provisioning;host=localhost;port=3306','sipwise',...) failed: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at /usr/share/ngcp-ngcpcfg/helper//sync-db line 70.
| Error: Could not connect to database 'provisioning' at 'localhost:3306' as 'sipwise': Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
| 2016-10-25 22:12:20: OK: nothing to commit.
| 2016-10-25 22:12:20: Synchronizing MySQL grants/credentials
| Can't connect to MySQL database 'mysql': Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at /usr/sbin/ngcp-sync-grants line 66.
| root@sp1:~# tail -f /var/log/ngcp/ngcpcfg.log
| [...]
| Oct 25 22:12:20 sp1 (notice) ngcpcfg: Executing sync-db:
| Oct 25 22:12:20 sp1 (notice) ngcpcfg: OK: nothing to commit.
| Oct 25 22:12:20 sp1 (notice) ngcpcfg: Checking state of /etc files
| Oct 25 22:12:20 sp1 (notice) ngcpcfg: OK: nothing to commit.
| Oct 25 22:12:20 sp1 (notice) ngcpcfg: Synchronizing MySQL grants/credentials
Output after this change gets applied:
| root@sp1:~# ngcpcfg commit "after"
| 2016-10-25 22:12:59: Executing sync-db:
| DBI connect('database=provisioning;host=localhost;port=3306','sipwise',...) failed: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at /usr/share/ngcp-ngcpcfg/helper//sync-db line 70.
| Error: Could not connect to database 'provisioning' at 'localhost:3306' as 'sipwise': Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
| 2016-10-25 22:12:59: OK: nothing to commit.
| 2016-10-25 22:12:59: Synchronizing MySQL grants/credentials
| Can't connect to MySQL database 'mysql': Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at /usr/sbin/ngcp-sync-grants line 66.
| root@sp1:~# tail -f /var/log/ngcp/ngcpcfg.log
| [...]
| Oct 25 22:12:59 sp1 (notice) ngcpcfg: Executing sync-db:
| Oct 25 22:12:59 sp1 (notice) ngcpcfg: DBI connect('database=provisioning;host=localhost;port=3306','sipwise',...) failed: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at /usr/share/ngcp-ngcpcfg/helper//sync-db line 70.
| Oct 25 22:12:59 sp1 (notice) ngcpcfg: Error: Could not connect to database 'provisioning' at 'localhost:3306' as 'sipwise': Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
| Oct 25 22:12:59 sp1 (notice) ngcpcfg: OK: nothing to commit.
| Oct 25 22:12:59 sp1 (notice) ngcpcfg: Checking state of /etc files
| Oct 25 22:12:59 sp1 (notice) ngcpcfg: OK: nothing to commit.
| Oct 25 22:12:59 sp1 (notice) ngcpcfg: Synchronizing MySQL grants/credentials
Change-Id: Iabb0c0ab24e212b79b0dfa85947cb274a161cc00
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
- ngcp-sync-grants is responsible for ngcp mysql
grants sync from a template
- it is executed by the 'commit' trigger before ngcp-sync-constants
Change-Id: I082256e57b1394a3f056ad1ca56a5443bfb5a745
Mainly nobody validate the schema in trunk right now
as it requires manual changes for ngcpcfg.cfg.
Also having force validation will allow us to add
validation in ngcp-upgrade and Jenkins nightly builds.
Change-Id: Ia48a778ecf7dae30b26bdff0c5dd5b9000c9d089
Verify that the user is operating on branch master,
otherwise the result might be unexpected.
If branch master is checked out:
| root@spce:/etc/ngcp-config# ngcpcfg check
| root@spce:/etc/ngcp-config# ngcpcfg status
| [...]
| 2016-02-23 05:48:32: Checking currently active branch:
| 2016-02-23 05:48:32: OK: branch master active
If a branch other than 'master' is checked out:
| root@spce:/etc/ngcp-config# ngcpcfg check
| 2016-02-23 05:47:42: Error: branch 'mika' in '/etc/ngcp-config' active - please switch to branch 'master' before continuing.
| root@spce:/etc/ngcp-config# echo $?
| 1
| root@spce:/etc/ngcp-config# ngcpcfg status
| [...]
| 2016-02-23 05:47:47: Checking currently active branch:
| 2016-02-23 05:47:47: ACTION_NEEDED: branch 'mika' active - please switch to branch 'master'
| [...]
Change-Id: I5df92075905cafa3b714211581c8cfe749df04ba
The commit action already takes care of invoking etckeeper, so there's
no need to call it from the apply action. In addition calling it after
record_commit_id is either pointless or buggy.
Change-Id: I8ccd40f962c24f99b2ae26655c083bb976e47ce9
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
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
Provide "apply" action as separate script.
We don't care about changes related to etckeeper, but just
about outstanding commits in /etc/ngcp-config.
Change-Id: I47411f00a5085d65cacf9e24fc8a468258d57c31
This allows us to abort in 'ngcpcfg status' whenever there are
outstanding changes to pull/push from the shared storage. Using
the --no-action-failure option allows the user to continue anyway.
Change-Id: I4062d5bb627bb553b98705bb122575651b035849
`which $function` doesn't work as intended, commit
dc984aa2e7 in ngcpcfg-ha.git broke the HA features
in 'ngcpcfg status' therefore.
Change-Id: I2bb9ed9b3276e63fc6d127559df32ae229a43b33
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
- added quiet option to disable loading output at tt2-daemon
- detect arrays and output values joined by space
Change-Id: I0b7694a366a284ca2b24ea2df55cb285b598e66d
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
Otherwise users notice error during upgrade mr3.7->mr3.8:
> ngcpcfg commit 'snapshot during /usr/share/ngcp-upgrade-mr3.8/upgrade-2.8-to-mr3.8 - Mon Apr 13 10:29:24 CEST 2015'
> YAML Error: Couldn't open /etc/ngcp-rtpengine-daemon/interfaces.yml for input:\nNo such file or directory
> Code: YAML_LOAD_ERR_FILE_INPUT
> at /usr/share/perl5/YAML.pm line 71
> OK
> Synchronizing data from /etc/ngcp-config/constants.yml
Change-Id: I2e4b8780d2ada64854186da93b03b8817eac99bf
A random order of service restarts might not work because
a service might depend on specific monit resource(s).
Therefore restart monit before any other service(s).
Change-Id: If6eae434014f00a76fdd66aac8c82dfd69b86f1b
Manuel Montecelo
Michael Prokop
Guillem Jover
Alexander Lutay
Kirill Solomko
Victor Seva
Richard Fuchs