Sipwise recommends to set password for MariaDB user 'root'.
It brakes ngcp-reset-db which drops database, upload/create the
new one and cannot connect MariaDB using user 'root' to
initialize all DB passwords using ngcp-sync-constants.
ngcp-sync-constants has to use user 'root' to initialize
DB user 'sipwise' from constants.yml.
We have to request user to provide password for DB user 'root' as
it is NOT stored on NGCP platform anywhere.
P.S. also performed 'wrap-and-sort -sat' here.
Change-Id: I15467ef37d6765e972c8c482a2dbe86eececd0ca
It was a widely popular question from users.
As the common sense pushes them to use 'get' when they use 'set/del'.
Let's follow the common logic here.
We still support old 'ngcpcfg values' syntax.
Change-Id: I40a210b7c13d21a4bff4b6988535c39091f53280
After checking with Kirill, it looks like we do not need any longer
"special handling for user sipwise as it is not in constants.yml".
ngcp-installer fully operates with sipwise_extra.cnf which is filled
from constants.yml, tested as PPA, CE/PRO were installed properly.
The following commands also work well:
> root@spce:~# ngcp-sync-constants -v
> --> nodename => sp1
> --> connected to localhost:3306 using '/etc/mysql/sipwise_extra.cnf'
> --> nothing to update
> root@sp1:~#
> root@spce:~# ngcp-sync-constants -v -r
> --> nodename => spce
> --> connected to localhost:3306 using user 'root'
> --> nothing to update
> root@spce:~#
Also reset DB passwords works in both ways:
- using user 'root':
> ngcp-sync-constants -v -i
> ngcp-sync-constants -v -r
- using user sipwise:
> ngcp-sync-constants -v -i
> ngcpcfg build /etc/mysql/sipwise_extra.cnf
> ngcp-sync-constants -v -r
ngcpcfg build there is necessary to update defaults-extra-file with
newly generated password in constants.yml (credentials->mysql->system->p).
Change-Id: Ib9be8723233ec385256d05576ecfbab613a8c1ce
There is no need to read the text file and search for password inside,
we have properly formatted credentials file /etc/mysql/sipwise_extra.cnf
which is fully supported by MySQL/MariaDB client library and Perl DBI.
Also we have plans to remove /etc/mysql/sipwise.cnf to prevent it usage
(to prevent password leakage through Linux process list).
Change-Id: I62006ae01d9097642a3dae063781a621f5050842
We need to call action and care about SUMMARY_ONLY without calling ngcpcfg.
main_action will be used in push-parallel to call pull/build/apply actions
directly without calling ngcpcfg. Also 'ngcpcfg push' can be migrated on new
approach '--remote' (recommended by Guillem Jover, BTW, Tnx!) from the current
approach of executing commands through ngcp-ssh on remote host.
Change-Id: I927b8055a040f49d6cfb462a200ad4d4b2d660ff
Sometimes (e.g. on 'push-parallel') we need to call ngcpcfg on
remote host and generating summary only output about the results.
It simplifies complex 'push-parallel' codebase which is critical
for huge Carrier installation.
P.S. we cannot print summary message all the time to console output,
as a lot of code depends on the ngcpcfg output, e.g.:
> root@web01a:~# ngcp-ppa gerrit_alutay_63758_push_parallel_2
> ERROR: There are uncommitted changes in config files:
> 2019-10-02 11:59:38 web01a: Successfully executed 'diff' on 'web01a'
> ERROR: Please commit them or discard
> root@web01a:~#
Instead, let's be backward compatible with printing on console,
but always print this message to log file (as we sometimes need to know
ngcpcfg exit code and it was impossible to find it in log file previously.)
Change-Id: I9aad0912796500cddb23d1f3eaa428b0b39152d0
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
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
Create a new function to set a key conditionally on its value being
defined. And rename the set_yml_config and its arguments to make it
clearer what it is doing.
Change-Id: Idefd89314b5ff76ed0f386135b3791a3309db34c
These commands do not perfom dangerous git calls,
at the same time we slowed them down a lot which
causes very slow nightly testing.
Previously:
> root@web01a:/tmp# time ngcpcfg values eventexport.transfer.password
> ...
> real 0m5.505s
With the new changes:
> root@web01a:/tmp# time ngcpcfg values eventexport.transfer.password
> ...
> real 0m0.127s
Change-Id: I937b4522eb8dbe4f91ada57c978ed4183e7e23fd
Current problem: CE system doesn't pass ngcpcfg
validation if interface name is 'ens0', installation
is aborted on the final 'ngcpcfg apply'.
There were a lot of code changes here and the original logic
if fallback validation has been lost.
The situation here is very unpleasant as all Jenkins tests
reported no issues for us, as interface name is 'eth0' there.
We have enabled validation be default in mr6.5, in the same
time the validation schema we have is not yet perfect, but
we must focus on 'trust' to validation functionality we
introduced otherwise it will not be used by users.
There is not point to have fallback in validation at this stage.
As it can be triggered for random physical and logical interfaces
in the system. Keep in mind mr6.5 generates /etc/network/interfaces
from network.yml, so all interfaces must be described in network.yml.
Change-Id: I1d90c64941bfb7eb8afad51c64c19f72b4ec65d9
ngcpcfg initialise setup git hooks, we should not try to
check/use hooks before they are configured.
Change-Id: Ie74c08fe53f8c8464ee057094637deb03be1d31c
We need to initialize ngcpcfg without HA repo,
to solve chicken-eggs problem about git hooks handking.
Also it will be useful to build glusterfs configs
from tt2 templates and yml configuration.
Then start glusterfs and store HA repo on glusterfs.
In this case ngcp-installer will be able to call:
> ngcpcfg initialise --without_shared
> ngcpcfg set ...
> ngcpcfg build ...
> ngcpcfg init-shared
> ngcpcfg apply "Applying everything together"
In the past it was not so critical problem until we started
taking care about the files permissions which are coming from
ngcp-template-* packages and transferred to POSIX perms via ngcpcfg.
One of the problems there is 'git clone' (which is a part of
HA setup initialisation). It resets file perms if they are not
yet stored into file '.ngcpcfg_perms'.
Change-Id: I3cdc93f309f0b899e626779afb1e71f64b2cb953
- Remove a spurious trailing ';'.
- Make the hook directory reaction conditional on whether we are running
from within a testsuite, to restore its otherwise fatal treatment.
Change-Id: I3f8a5364d7b2f0ac82bfdc132b94641603225f85
Fixes: commit 505d6566d8
Unfortunately git doesn't track POSIX file permissions,
which cause perms drop on some git commands like 'git stash/pull/reset', etc.
We must be sure 'restore-permissions' always executed at the end of 'ngcpcfg'.
Also we must be sure we update .ngcpcfg_perms whenever we start 'ngcpcfg',
otherwise we might loose not-yet committed changes in .ngcpcfg_perms.
Example during the upgrade mr7.0->mr7.1:
1) JFYI, ngcpcfg mr7.1+ copies perms from source tt2 file to the destination config
2) on mr7.0->mr7.1, ngcp-upgrade installs new package ngcp-templates-pro package
with new perms on tt2 files (which are not committed by apt as /etc/ngcp-config
is not covered by 'etckeeper', it is by design).
3) later ngcp-upgrade executes 'ngcpcfg build' to build some config.
4) on PRO/Carrier 'ngcpcfg build' executes 'ngcpcfg pull' first to
ensure there is no outstanding changes on shared git repo
(has been done on Ops request in MT#15803).
5) 'ngcpcfg pull' does 'git stash/pop' before pulling which effectively
reset new perms which came from package in step 1 (as git doesn't track
perms on files, by design).
Summary/fix:
whenever we stash something we should ensure perms are stored as well,
which means we need to generate new .ngcpcfg_perms and store it in stash
together with all the rest local changes.
Change-Id: I5292d4433a39ff2751874d63083f093f19b9cfe2
This will make it possible for child processes to check whether they are
being executed from ngcpcfg, for example to avoid recursion.
Change-Id: I8f51dd7872c458b8c3214be4bc9a4ab133b3e441
In some conditional branches we make the ip key optional, but never
change netmask to match. Which can end up being required when it
should not, such as on a vlan interface.
Change-Id: I9767434901abb2c0f07c10f8b8800987c2e363c5
We should not just check whether these keys are defined, but whether
they contain actual IPs too.
Fixes: commit 80f70d88b2
Change-Id: I122de32629164cc46537ab0800612c8654f1ba14
If we are using DHCP we do not need either an IPv4 nor an IPv6. If we
have an IPv6 we do not need an IPv4. If we have a netmask, a shared
IP, an advertised IP, we should have the matching IP setting.
Change-Id: I13f190086a0540495b0314e58ca301aae6db0453
Otherwise ngcp-installer failed to install PRO/Carrier as
we build the file /etc/ngcp_mgmt_node the very first time on the first MGMT node:
> +08:22:48 cfg_build_templates
> +08:22:48 cfg_build_configs /etc/ngcp_mgmt_node
> +08:22:48 build_configs=($1)
> +08:22:48 declare -a build_configs
> +08:22:48 log_info 'Generating default configuration files /etc/ngcp_mgmt_node'
> +08:22:48 tee -a /tmp/ngcp-installer.log
> +08:22:48 echo 'Generating default configuration files /etc/ngcp_mgmt_node'
> Generating default configuration files /etc/ngcp_mgmt_node
> +08:22:48 ngcpcfg build /etc/ngcp_mgmt_node
> cat: /etc/ngcp_mgmt_node: No such file or directory
> +08:22:48 log_die 'Error running '\''ngcpcfg build'\'''
Checking the file availability is not enough here, the next error is:
> (sp1)root@sp1:/# ngcpcfg build
> /usr/share/ngcp-ngcpcfg/scripts//check: line 83: NGCP_IS_MGMT: unbound variable
> (sp1)root@sp1:/# cat /etc/default/ngcp-roles
> NGCP_TYPE="sppro"
> (sp1)root@sp1:/#
It happens because /etc/default/ngcp-roles is a fake one at this stage.
Handling NGCP_IS_MGMT properly is also not enough:
> (sp1)root@sp1:/# ngcpcfg build
> 2018-07-16 16:49:32: Error: Remote origin of ngcpcfg is '/mnt/glusterfs/ngcpcfg-share', expected: 'sp:/mnt/glusterfs/ngcpcfg-share'.
> 2018-07-16 16:49:32: Error: NOTE: execute `cd /etc/ngcp-config ; git remote set-url origin 'sp:/mnt/glusterfs/ngcpcfg-share'` to adjust setting.
> 2018-07-16 16:49:32: Error: NOTE: perform `ngcpcfg clean --all` to recreate local master branch from remote.
> (sp1)root@sp1:/#
Which happens because the peer is not yet configured at the moment (first node installation).
Introducing new internal option '--no-check-origin' to skip the test into installer.
Change-Id: I0265c65f45972e92ca92320871a7ef29f8904fec
We should be exhaustive here, and any unknown pattern should be caught
and reported, as we might miss information about peers and the cluster
layout otherwise.
Change-Id: I56a9a2b5b6c6f776c0c64fc2f8e01f5f76bb8e10
Previously it had the following behavior:
Select all records with 'Host LIKE' filtering so if requested host was '%'
this select returned all the record for this user.
Then user was delete with 'DELETE ... Host LIKE' statement so if
requested host was '%' it deleted all the records.
With using 'DROP USER' statement the same behavior can be achieved with
the same selecting but drop user not with requested host but with actual
one from select statement.
Change-Id: I72f1dd1962e139939be700794e0eb025fe1615b2
There are a lot of flushing privileges so in order not to flood the
console move it to debug level.
Change-Id: I98e3247881393d7892799cc23c2a4e5dc865185a
Replace unsafe 'DELETE FROM mysql.user' with recommended 'DROP USER'
statement to avoid problems with DROP/CREATE USER due to missing
'FLUSH PRIVILEGES' like:
Error: Cannot create grant temp user: Operation CREATE USER failed
for 'ngcp-sync-db'@'localhost' at /usr/sbin/ngcp-sync-grants line 322.
Execute 'FLUSH PRIVILEGES' before creating and after dropping of temp user
'ngcp-sync-db'.
Change-Id: I49c29b6c39353d4a47f086851a915af1469ebcdd
Script init-mgmt is installed on PRO installation so change
description to the proper one - script is usable only on Carrier
installation.
Change-Id: I7a7904183e30c4146267d73fbfc1075b2b066d08
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
- eth* interfaces should have a hwaddr.
- anything other than bond*, eth* should have type.
- anything other than bond*, eth* and idrac* should have ip/netmask.
Change-Id: I8c0b4f5eddaaab0c658a5281448735a985ee08f1
* users with special chars, like debian-sys-maint
require revoke/grant to be escaped as 'user'@'host'
* [default.user.host] "parent" is printed in the log if
without debug but only when there is something to change
Change-Id: I63065b5df37eea9136c6e61d15c329b978ba62dd
Alexander Lutay
Richard Fuchs
Guillem Jover
Michael Prokop
Manuel Montecelo
Mykola Malkov
Kirill Solomko