The date is already tracked as part of the commit metadata, and we use
the current day which will always match the author date for the commit,
so no information is lost.
This makes the commit message more clear and removes redundant and
distracting information from it.
For «ngcpcfg log» we include the date from the commit metadata explicitly
in the output, which will be duplicated for old entries but gets it from
where it belongs for new ones. (Even though the date is also printed in
relative terms on the front of the line.) We now get this output for old
and new entries:
* b3767f6 (10 hours ago) new [2024-02-02 14:28:11 +0100] (HEAD -> master)
* dc0a310 (3 days ago) old [2024-01-30 23:10:32.674452749+01:00] [2024-01-30 23:10:32 +0100]
Change-Id: I4eb4faed433db52e6755bc7782ec34545741d452
We are prepending an extra / to the pathnames passed to tar, and
calling tar from a directory other than the root directory while
not telling it to use absolute names so it complains about these
two things with the following messages:
,---
tar: Removing leading `/' from member names
tar: Removing leading `/' from hard link targets
tar: Removing leading `//' from member names
tar: Removing leading `//' from hard link targets
`---
which is something the user cannot do much about, and it's rather
annoying.
Change-Id: I9e9c853f26363e451b8883d3c74c5508ba3049dc
* sync_extra_sockets() renamed into sync_lb_and_extra_sockets()
* extra_sockets_sync() renamed into lb_and_extra_sockets_sync()
* $config now also contains merged $NETWORK_CONFIG (network.yml)
* lb_and_extra_sockets_sync does the following and then calls
generic_enum_sync() to provide with the gathered data:
* all shared ips from interfaces that
- host have 'lb' role
- host status 'online'
- interface has type '^sip_'
are added into the outbound sockets list of protos (udp, tcp, tls)
as: 'host:interface:proto' = 'proto:shared_ip:port'
(port is taken from config.kamailio.lb.port in case of ('udp', 'tcp')
and config.kamailio.tls.port in case of 'tls'
)
- if an interface has multiple shared IPs,
the key becomes 'host:interface:shared_ip:proto'
- $config->{kamailio}{lb}{extra_sockets} keys are merged
with the gathered config
* generic_enum_sync() - processes hash keys are now sorted
to have consistent output/processing
Change-Id: I218f1ae584e2dc9dfeb3a51c43d9f3fc950e829b
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
For multi-site support we need to pass all the possible files to load,
and these might be different between sites, so we need to check for
their existence from within tt2-process, instead of from the outside as
that would restrict them to only the current site.
Change-Id: I0965506832aa2f0a1ba67b19511c509bec60922e
The script got supported added for the maintenance file, but missed a
spot where the actual selection is performed.
Fixes: commit 948f940975
Change-Id: I9d092fd99a821f6f8ce72b0f7b8c05e5ab1c25e6
We need to pass the host lists to the check remote code, and we should
not be passing any host lists to the check shared storage code, as that
takes an action instead.
Change-Id: I7292cf56f110df81f5a3b83da911742bae2af1b2
Fixing issues reported by new shellcheck v0.9.0:
1) SC2317 (info): Command appears to be unreachable. Check usage (or ignore if invoked indirectly).
https://www.shellcheck.net/wiki/SC2317
(new feature as of shellcheck v0.9.0)
2) SC2086 (info): Double quote to prevent globbing and word splitting.
https://www.shellcheck.net/wiki/SC2086
(behavior change with shellcheck v0.9.0)
Change-Id: I73d50157f72b772c381cf1bff497079133bc6d09
These commands are db-specific, and the constants one involves the
database credentials, so give both better names to make it clear these
are not general purpose commands.
Preserve backwards compatibility symlinks for external callers, or
user muscle memory, which this gets migrated away.
Change-Id: I3baae364e786ebbdc9e386dfc4f8c0bf54333cd1
Move perl code which actually modifies yml file to separate helper as
there is no sense to recreate it every call of 'ngcpcfg del'.
Change-Id: Iab9e023318cf9798bdb10d89b08dc2afe125c495
In ngcp-initial-configuration there are a lot of multiple sequential calls
of 'ngcpcfg set' which consume significant amount of time.
So add support for setting multiple options to do it at once.
Change-Id: I8cacdbec78ecefc4681048a0fb085b4cb705d83e
Move perl code which actually modifies yml file to separate helper as
there is no sense to recreate it every call of 'ngcpcfg set'.
Change-Id: I08b10186b1aa127d4a2b81ef36b234dfdd46fc8e
If the maintenance mode is enabled, then we shouldn't suggest to
run ngcpcfg build/apply, as this might cause unexpected side effects.
Instead report that the maintenance mode is enabled and we're skipping
checks.
Change-Id: I2ca43142a3caeac2c00514b1353568f4c438fbed
Introduce a list of checks related to connections:
* check that we don't have instance names duplicates
* prove an existence of a preferred for instnace host
* an instance to which instance gets connected exists
* a host to which instance gets connected exists
* interface via which instance gets connected is defined
Change-Id: I24f43b0fb24e308f571a88f30a72a9b6dd04b94d
We add support for YAML schemas, and hook it into the check command to
validate the sites.yml file.
Change-Id: Ic6ed43e36361d395b485230af4ec3cf7e77758bb
we can define what is the expected origin via
/etc/ngcp-ngcpcfg/ngcpcfg.d/mgmnode.cfg for instance
Change-Id: Ied83502ddc022a1c7bb948f43bee7ccc10efcd88
This off-loads the check to the ngcp-site script, and prints any error
message from it if the script fails.
Only run the check if ngcp-site is present, so that we avoid a
hard-dependency on system-tools.
Change-Id: I640f85383d424980d81a207dee7d586a88422862
This is the symlink pointing to the current site for this site, which
cannot be committed to git, or we'd get constant conflicts when multiple
sites commit their own.
Change-Id: I054afc15bb3a52d0ca2357db5ea4a152cfff035b
This special handling was from a time when we did not have any other
generic suffix support to override based on hostname, nodename, role,
etc. It also depends on the now obsolete systems.cfg file which is
redundant and already covered by the information contained in
network.yml.
Our tt2-process tool already handles these suffixes, so there is no
point in special-casing them from within the build script. This way we
simplify our templating and overriding mechanism, and reduce duplication
of information.
Change-Id: Iabf597dbaddf755a7f85504975afc8666a58d272
We want to be able to track down any left-behind tmp files,
so ensure we're creating them with according file names.
Change-Id: I1aa0ccdb8834e8aef919f1f028028c1bb14cbd01
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
We should validate all configuration files by concatenating them, so
that any local addition or override gets schema validated, otherwise
these modifications will pass without notice, until it is probably too
late.
Change-Id: I9c7774eefdeadddb399dd68668779dffcd173696
This new action concatenates the various configuration files and outputs
the result as YAML. This is useful because they have a determined
ordering, and include optional host specific files that might not be
obvious how to merge.
This will also be the foundation for verifying all the current host
settings against the cfg-schema.
Change-Id: I72a61193f74caf3b2f7a58a47eefad2ed46c973a
Otherwise 'ngcpcfg apply' silently aborted on stage 'build'
and error message is not visible due to long/parallel output.
Change-Id: I34b2c14fecad33526d89939e62d85dbafab31535
* We were missing the scenario when only the build files for an instance
had changes. The service for that instance was not restarted
Change-Id: I85ba86bc57c7fc8b6df1ac2ef1144c2d3952a4da
The prevalent convention in the project is to use «-» instead of «_» to
split words in options. Switch the options to that, and keep backwards
compatibility option alias that emits a deprecation warning while people
transition to the new names. The alias will be removed on the next LTS.
Change-Id: I8bb7f26f8a766f7ea76ba2d9e49b793e5cb8d11e
Instead of having to identify the parent process name (ngcpcfg vs.
ngcp-config) inside subprocesses (like "status"), let's provide the
invocation name through the main ngcpcfg binary via variable
NGCPCFG_NAME.
Thanks to Guillem Jover for the suggestion.
Change-Id: Iafbac535bedb9cc9dc73f3d95861a5bc735cc739
will provide a new instance_info variable with the all the content
defined at network.yml for the instance
removed intance_name since instance_info.name has the same value
Change-Id: I349d0b430b59280bc383d46d5ba6a61f5d1f9046
When invoking `ngcp-config status`, we reported "ngcpcfg":
| [sipwise-lab-trunk] sipwise@sp1:~$ sudo ngcpcfg status
| 2021-12-09 17:30:08 sp1: Checking state of ngcpcfg:
| 2021-12-09 17:30:08 sp1: OK: has been initialised already
| [...]
While what we should report instead is "ngcpcfg-config", like:
| [sipwise-lab-trunk] sipwise@sp1:~$ sudo ngcp-config status
| 2021-12-09 17:31:31 sp1: Checking state of ngcp-config:
| 2021-12-09 17:31:31 sp1: OK: has been initialised already
| [...]
Change-Id: If8fc8076fdf1d214baea3c7388ab208947d66a05
The previous error message was really confusing:
> root@spce:~# ngcpcfg get /asdf
> 2021-12-06 18:48:12 sp1: Error: Cannot process template '/tmp/tmp.RBRJg02PEz':
>
> file error - parse error - input file handle line 1: unexpected token (/asdf)
> [% /asdf %]
> 2021-12-06 18:48:12 sp1: Error: Generating /tmp/tmp.NKfB8BtJXv based on /tmp/tmp.RBRJg02PEz: FAILED
It happens due to the way ngcpcfg using TT2 template which
is trying to include the file it the string looks like a PATH.
The new error message is more user friendly
(and generates proper/non-zero exit code):
> root@spce:~# ngcpcfg get /asdf
> 2021-12-07 12:42:50 spce: Error: cannot process request for '/asdf'!
> root@spce:~# echo $?
> 1
> root@spce:~#
Change-Id: Ifaf56dec07adf8600bd9d7cf2e733769d6d82a4f
* expects values from CONFIG_POOL
* append OUTPUT_DIRECTORY just when changing directory
added at 83003649e3
Change-Id: I9c22bff70b58d4cfb49c3dab45330bccb898011e
Switch all code to use a loop to parse options so that these can parse
multiple options (currently some scripts would simply parse one or
another but not several), and to make them easier to extend.
Change-Id: I5e902f2d7d8db78e66e48db1237924fa7d8fdda1
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
shellcheck v0.8 has new check, known as SC2295 ("Warn about "${x#$y}"
treating $y as a pattern when not quoted").
Fixes:
| In scripts/build line 117:
| build_file="${build_file%%.${host}}"
| ^-----^ SC2295 (info): Expansions inside ${..} need to be quoted separately, otherwise they match as patterns.
| In scripts/encrypt line 24:
| x=${file##${NGCPCTL_MAIN}/templates/} # drop leading /etc/ngcp-config
| ^-------------^ SC2295 (info): Expansions inside ${..} need to be quoted separately, otherwise they match as patterns.
... as reported by our Github actions at
https://github.com/sipwise/ngcpcfg
Change-Id: I3371388ecf445905cca0bc4681276151aceb43ae
We need to flush the queues unconditionally regardless on whether we
have executed .services files, otherwise the enqueued services during
package upgrades might be left unattended for long periods of time in
case no .services files got triggered due to modified configuration
files.
We flush all queues in case some enqueued service was left behind in the
default queue.
Change-Id: Iea8ab11fcb7e580cb8e160b8674e2dff3c9c85a0
We need to make sure the permissions for any config file are set
correctly, otherwise on the next build action these will be updated,
which might cause spurious commits just for these updates, that can
end up generating rebase conflicts.
Change-Id: I7c0f4cf13593da0d696ba25097b202e0b7a33674
Instead of checking for the user, group and mode configuration knobs in
various scripts (currently «build» and «set»), just make sure the
variables have sane defaults when loading the «ngcpcfg.cfg» file.
This also makes it possible to simplify the chown/chgrp calls into
single chown calls.
Change-Id: I1fcc06a7d311e4ebc4a96cc84ffae333be243c53
When we are creating a new file with set, for a known config.yml
variation, we need to apply the correct owner/group and mode or the next
build will modify them and that will change spurious commits that have
no relation to the action being taken at the time.
Change-Id: I93017cdcdcf22fa1c5ef8e103d215aa7bc110b9a
introduced at commit eff9d4ae07
> ngcp-service: info: Action restart skipped, service kamailio-proxy is not for this role
> 2021-08-17 14:59:18 lb01a: Synchronizing current with expected services state
> /usr/share/ngcp-ngcpcfg/scripts//apply: line 56: $1: unbound variable
Change-Id: I75a551327ecb42b7ff6a14a5206b85fb35e5f608
Guillem Jover
Kirill Solomko
Mykola Malkov
Michael Prokop
dzenichev
ngcp-config
Alexander Lutay