Could not find a version that satisfies the requirement pbr!=2.1.0,>=2.0.0 (from tempest==16.0.1.dev178) - openstack

I just followed the openstack rally quick start guide to create a tempest verifier with Rally v0.9.1 in an Openstack Ocata/stable deployment. The command failed:
(rally-15.1.2) root#infra1-utility-container-f31faeb0:~/.rally/verification# rally verify create-verifier --type tempest --name tempest-verifier
2017-05-21 07:53:13.410 11422 INFO rally.api [-] Creating verifier 'tempest-verifier'.
2017-05-21 07:53:13.528 11422 INFO rally.verification.manager [-] Cloning verifier repo from https://git.openstack.org/openstack/tempest.
2017-05-21 07:53:37.174 11422 INFO rally.verification.manager [-] Creating virtual environment. It may take a few minutes.
2017-05-21 07:53:42.323 11422 ERROR rally.verification.utils [-] Failed cmd: '['pip', 'install', '-e', './']'
2017-05-21 07:53:42.324 11422 ERROR rally.verification.utils [-] Error output: 'Obtaining file:///root/.rally/verification/verifier-091a49ab-1241-40a3-bc9b-531d7f091e37/repo
Collecting pbr!=2.1.0,>=2.0.0 (from tempest==16.0.1.dev178)
Could not find a version that satisfies the requirement pbr!=2.1.0,>=2.0.0 (from tempest==16.0.1.dev178) (from versions: 1.10.0)
No matching distribution found for pbr!=2.1.0,>=2.0.0 (from tempest==16.0.1.dev178)
'
Command failed, please check log for more info
As the current version of pbr is 2.0.0, I'm not sure why pbr installation failed.
(rally-15.1.2) root#infra1-utility-container-f31faeb0:~/.rally/verification# pip freeze|grep pbr
pbr==2.0.0
The question is how to adjust the requirement checking for pbr? or is it possible to choose an older version of tempest?
Thanks.

It solved.
After uploading the two missing python packages: os_testr-0.8.2-py2-none-any.whl and testrepository-0.0.19.tar.gz into local repo, which is a lxc container had been created by openstack-ansible, the Tempest plugin was finally installed.

Related

Error when checking the service status In Nebula Graph

Install NebulaGraph
sudo rpm -ivh nebula-graph-3.3.0.el7.x86_64.rpm
Start NebulaGraph
sudo /usr/local/nebula/scripts/nebula.service start all
[INFO] Starting nebula-metad...
[INFO] Done
[INFO] Starting nebula-graphd...
[INFO] Done
[INFO] Starting nebula-storaged...
[INFO] Done
Run the following command to check the service status of NebulaGraph.
sudo /usr/local/nebula/scripts/nebula.service status all
The returned result is the following one, there is a problem in nebula-graphd. How do I deal with this issue?
[INFO] nebula-metad(33fd35e): Running as 29020, Listening on 9559
[INFO] nebula-graphd(33fd35e): Running as 29095, Listening on 9669
[WARN] nebula-storaged after v3.0.0 will not start service until it is added to cluster.
[WARN] See Manage Storage hosts:ADD HOSTS in https://docs.nebula-graph.io/
[INFO] nebula-storaged(33fd35e): Running as 29147, Listening on 9779
Best to my knowledge, starting from NebulaGraph 3.0.0, the Meta service cannot directly read or write data in the Storage service that you add in the configuration file. The configuration file only registers the Storage service to the Meta service.
You must run the ADD HOSTS command to enable the Meta to read and write data in the Storage service.

brew install mariadb fails as system can not chown for auth_pam_tool

brew
brew install not work. this is the log.
% brew install mariadb
==> Downloading https://homebrew.bintray.com/bottles/mariadb-10.4.13.mojave.bottle.tar.gz
Already downloaded: /Users/shingo/Library/Caches/Homebrew/downloads/d56104142081a8230646ac3f245adf2414e515cd5f2aeeb0637614e9966e882c--mariadb-10.4.13.mojave.bottle.tar.gz
==> Pouring mariadb-10.4.13.mojave.bottle.tar.gz
==> /usr/local/Cellar/mariadb/10.4.13/bin/mysql_install_db --verbose --user=shingo --basedir=/usr/local/Cellar/mariadb/10.4.13 --datadir=/usr/local/var/mysql --tmpdir=/tmp
Last 15 lines from /Users/shingo/Library/Logs/Homebrew/mariadb/post_install.01.mysql_install_db:
shell> /usr/local/Cellar/mariadb/10.4.13/bin/mysql -u root mysql
mysql> show tables;
Try 'mysqld --help' if you have problems with paths. Using
--general-log gives you a log in /usr/local/var/mysql that may be helpful.
The latest information about mysql_install_db is available at
https://mariadb.com/kb/en/installing-system-tables-mysql_install_db
You can find the latest source at https://downloads.mariadb.org and
the maria-discuss email list at https://launchpad.net/~maria-discuss
Please check all of the above before submitting a bug report
at http://mariadb.org/jira
Warning: The post-install step did not complete successfully
You can try again using `brew postinstall mariadb`
==> Caveats
A "/etc/my.cnf" from another install may interfere with a Homebrew-built
server starting up correctly.
MySQL is configured to only allow connections from localhost by default
To start mariadb:
brew services start mariadb
Or, if you don't want/need a background service you can just run:
mysql.server start
==> Summary
🍺 /usr/local/Cellar/mariadb/10.4.13: 744 files, 169.9MB
I have tried to execute mysql_install_db
I have tried to execute mysql_install_db without brew. this is the log.
The brew displays only the last 15 lines, so I can't help it.
% /usr/local/Cellar/mariadb/10.4.13/bin/mysql_install_db --verbose --user=shingo --basedir=/usr/local/Cellar/mariadb/10.4.13 --datadir=/usr/local/var/mysql --tmpdir=/tmp
chown: /usr/local/Cellar/mariadb/10.4.13/lib/plugin/auth_pam_tool_dir/auth_pam_tool: Operation not permitted
Couldn't set an owner to '/usr/local/Cellar/mariadb/10.4.13/lib/plugin/auth_pam_tool_dir/auth_pam_tool'.
It must be root, the PAM authentication plugin doesn't work otherwise..
Installing MariaDB/MySQL system tables in '/usr/local/var/mysql' ...
2020-05-29 22:13:03 0 [Note] /usr/local/Cellar/mariadb/10.4.13/bin/mysqld (mysqld 10.4.13-MariaDB) starting as process 45440 ...
2020-05-29 22:13:03 0 [ERROR] /usr/local/Cellar/mariadb/10.4.13/bin/mysqld: option '--innodb-large-prefix' requires an argument
2020-05-29 22:13:03 0 [ERROR] Parsing options for plugin 'InnoDB' failed.
2020-05-29 22:13:03 0 [ERROR] /usr/local/Cellar/mariadb/10.4.13/bin/mysqld: unknown variable 'mysqlx-bind-address=127.0.0.1'
2020-05-29 22:13:03 0 [ERROR] Aborting
Installation of system tables failed! Examine the logs in
/usr/local/var/mysql for more information.
The problem could be conflicting information in an external
my.cnf files. You can ignore these by doing:
shell> /usr/local/Cellar/mariadb/10.4.13/bin/mysql_install_db --defaults-file=~/.my.cnf
You can also try to start the mysqld daemon with:
shell> /usr/local/Cellar/mariadb/10.4.13/bin/mysqld --skip-grant-tables --general-log &
and use the command line tool /usr/local/Cellar/mariadb/10.4.13/bin/mysql
to connect to the mysql database and look at the grant tables:
shell> /usr/local/Cellar/mariadb/10.4.13/bin/mysql -u root mysql
mysql> show tables;
Try 'mysqld --help' if you have problems with paths. Using
--general-log gives you a log in /usr/local/var/mysql that may be helpful.
The latest information about mysql_install_db is available at
https://mariadb.com/kb/en/installing-system-tables-mysql_install_db
You can find the latest source at https://downloads.mariadb.org and
the maria-discuss email list at https://launchpad.net/~maria-discuss
Please check all of the above before submitting a bug report
at http://mariadb.org/jira
I noticed that the system can not chown for auth_pam_tool because Operation not permitted.
auth_pam_tool permission
this is my permission the directory.
% ls -l /usr/local/Cellar/mariadb/10.4.13/lib/plugin/auth_pam_tool_dir/auth_pam_tool
-r-xr-xr-x 1 shingo staff 13608 5 10 04:28 /usr/local/Cellar/mariadb/10.4.13/lib/plugin/auth_pam_tool_dir/auth_pam_tool
How to fix Operation not permitted?
Or is there any other reason why it cannot be installed?
Self resolved.
Anyway I gave it try start
Even though the installation was not successful, anyway I gave it try % mysql.server start.
A error log file was created.
A error log file was created by starting mysql server.
the error log shows:
2020-05-30 8:47:10 0 [Warning] InnoDB: innodb_open_files 300 should not be greater than the open_files_limit 256
2020-05-30 8:47:10 0 [ERROR] /usr/local/Cellar/mariadb/10.4.13/bin/mysqld: unknown variable 'mysqlx-bind-address=127.0.0.1'
2020-05-30 8:47:10 0 [ERROR] Aborting
An unknown value in the mysqlx-bind-address seems to be causing the error.
How to fix unknown variable
I found
the same error question. This question discussed a my.conf file.
~/.my.conf did not exist on my mac
/etc/my.conf did not exist on my mac
this question teach me the my.conf location.
Finally I found my.conf in /usr/local/etc/my.cnf.Certainly the settings for mysqlx-bind-address were written in my.conf.
So rm /usr/local/etc/my.cnf, then brew reinstall SUCCESS!.
The permission was irrelevant at all.
this work for me:
rm /opt/homebrew/etc/my.cnf

OpenVAS: OSPD scanner can't be used as scanner in new task

After understanding how to add an ospd scanner, verify it etc ...
I though I could finally use it but got an error through UI to add it to a task.
In my case, I run OpenVAS 9 on a debian 9 and I'm trying to include a w3af scanner but I got the same issue with every OSP scanner I add.
my pip freeze :
ospd==1.2.0
ospd-debsecan==1.2b1
ospd-nmap==1.0b1
ospd-w3af==1.0.0
Note that here is an example of w3af but the issue is the same for debsecan scanner and nmap scanner.
my openvas-check-setup :
Step 1: Checking OpenVAS Scanner ...
OK: OpenVAS Scanner is present in version 5.1.1.
OK: redis-server is present in version v=3.2.6.
OK: scanner (kb_location setting) is configured properly using the redis-server socket: /tmp/redis.sock
OK: redis-server is running and listening on socket: /tmp/redis.sock.
OK: redis-server configuration is OK and redis-server is running.
OK: NVT collection in /usr/local/var/lib/openvas/plugins contains 47727 NVTs.
WARNING: Signature checking of NVTs is not enabled in OpenVAS Scanner.
SUGGEST: Enable signature checking (see http://www.openvas.org/trusted-nvts.html).
OK: The NVT cache in /usr/local/var/cache/openvas contains 47727 files for 47727 NVTs.
Step 2: Checking OpenVAS Manager ...
OK: OpenVAS Manager is present in version 7.0.2.
OK: OpenVAS Manager database found in /usr/local/var/lib/openvas/mgr/tasks.db.
OK: Access rights for the OpenVAS Manager database are correct.
OK: sqlite3 found, extended checks of the OpenVAS Manager installation enabled.
OK: OpenVAS Manager database is at revision 184.
OK: OpenVAS Manager expects database at revision 184.
OK: Database schema is up to date.
OK: OpenVAS Manager database contains information about 47727 NVTs.
OK: At least one user exists.
OK: OpenVAS SCAP database found in /usr/local/var/lib/openvas/scap-data/scap.db.
OK: OpenVAS CERT database found in /usr/local/var/lib/openvas/cert-data/cert.db.
OK: xsltproc found.
Step 3: Checking user configuration ...
WARNING: Your password policy is empty.
SUGGEST: Edit the /usr/local/etc/openvas/pwpolicy.conf file to set a password policy.
Step 4: Checking Greenbone Security Assistant (GSA) ...
OK: Greenbone Security Assistant is present in version 7.0.2.
OK: Your OpenVAS certificate infrastructure passed validation.
Step 5: Checking OpenVAS CLI ...
OK: OpenVAS CLI version 1.4.5.
Step 6: Checking Greenbone Security Desktop (GSD) ...
SKIP: Skipping check for Greenbone Security Desktop.
Step 7: Checking if OpenVAS services are up and running ...
OK: netstat found, extended checks of the OpenVAS services enabled.
OK: OpenVAS Scanner is running and listening on a Unix domain socket.
OK: OpenVAS Manager is running and listening on a Unix domain socket.
OK: Greenbone Security Assistant is listening on port 443, which is the default port.
Step 8: Checking nmap installation ...
WARNING: Your version of nmap is not fully supported: 7.40
SUGGEST: You should install nmap 5.51 if you plan to use the nmap NSE NVTs.
Step 10: Checking presence of optional tools ...
OK: pdflatex found.
WARNING: PDF generation failed, most likely due to missing LaTeX packages. The PDF report format will not work.
SUGGEST: Install required LaTeX packages.
OK: ssh-keygen found, LSC credential generation for GNU/Linux targets is likely to work.
OK: rpm found, LSC credential package generation for RPM based targets is likely to work.
OK: alien found, LSC credential package generation for DEB based targets is likely to work.
OK: nsis found, LSC credential package generation for Microsoft Windows targets is likely to work.
To create the scanner in openvas, I use:
openvasmd --create-scanner="w3af" --scanner-host=127.0.0.1 --scanner-port=1235 --scanner-type="OSP" \
--scanner-ca-pub=/usr/local/var/lib/openvas/CA/cacert.pem \
--scanner-key-pub=/usr/local/var/lib/openvas/CA/clientcert.pem \
--scanner-key-priv=/usr/local/var/lib/openvas/private/CA/clientkey.pem
To run ospd-w3af scanner, I use:
~# ospd-w3af -b 127.0.0.1 -p 1235 -k \
/usr/local/var/lib/openvas/private/CA/clientkey.pem -c \
/usr/local/var/lib/openvas/CA/clientcert.pem --ca-file \
/usr/local/var/lib/openvas/CA/cacert.pem -L DEBUG
When I verify the scanner with openvasmd --verify-scanner xxxxx I got
Scanner version: 2018.8.22.
note: in the logs of the scanner I got this for every verify I do, I don't know if it's related or no and I didn't find a way to fix this:
2018-10-15 14:27:47,413 ospd.ospd: DEBUG: New connection from 127.0.0.1:60078
2018-10-15 14:27:49,430 ospd.ospd: DEBUG: Error: ('The read operation timed out',)
2018-10-15 14:27:49,433 ospd.ospd: DEBUG: 127.0.0.1:60078: Connection closed
So, my verification made, I want to create a task that uses this scanner but I can't save it due to error "Given scanner_type was invalid" :
https://i.stack.imgur.com/fvIJd.png
I got 0 connection to the chosen scanner at this moment and I can't find anything in the logs (maybe I can't search). I suspect the gsad UI being responsible for this but I can't find it.
I don't know what to do and if someone more expert than me (not very hard) could help that'd be great :)
Thanks in advance.
I solved this issue by creating a scan configuration for the ospd scanner (I though it didn't need one since it import them)
I faced another issue concerning ospd-w3af configuration, I couldn't create one because it needs ospd 1.0.0 installed, I modified the dependencies few days ago and it doesn't work with ospd 1.2.0
Now I'm facing the issue where the scans doesn't start properly. It stops at 1%
Getting openvas 9 running on new install of Ubuntu 18 was a pain. once i got past all my errors by creating files and ln -s for redis-server socks connections my tasks crapped out at 1%. My fix was install sudo apt install libopenvas-dev after that scans work and check-setup worked. Check-setup report no scanner but openvassd was running and openvasmd --verify-scanner (uuid) showed the scanner.

ICp 2.1.0.1: Installation failed with error TASK [master: Waiting for MariaDB service to start]

I am installing ICp 2.1.0.1 and I received an error at the TASK
[master: Waiting for MariaDB service to start] msg: The MariaDB
component failed to start.
After this msg the installation completed with failed status.
We are installing ICp with 3 Masters, 3 Proxies and 2 Workers. We have 1 IP for VIP master and 1 for VIP proxy.
I tried to install multiple times and all installations got the same error.
For prior issues with that error, the correct db admin password was not used. So check the db user and password to resolve issue.
Would you validate whether each master host was able to access port 3306 on the other hosts?
If you run with .. install -vv | tee -a install-log.txt, do you get additional details as well?
The error was solved by following the steps below.
Check whether kubelet is running:
Log in to your master node.
Run the following command to check kubelet status:
systemctl status kubelet
If kubelet is not running, run the following command to get the logs:
journalctl -u kubelet &> kubelet.log
We found the error in the kubelet.log log:
Error: failed to run Kubelet: Running with swap on is not supported, please disable swap! or set --fail-swap-on flag to false.
We found this troubleshoot in this link, and the solution at the ICP issue 4651.
https://www.ibm.com/support/knowledgecenter/en/SSBS6K_2.1.0/troubleshoot/etcd_fails.html
https://github.ibm.com/IBMPrivateCloud/roadmap/issues/4651

chef recipe unable install nginx on RHEL 7.3

I am trying use the package manager in chef and installing nginx server but every time i ran the cook book on my client it is just saying that
Recipe: nginx::default
* yum_package[nginx] action install[2017-03-11T06:16:01-05:00] INFO: Processing yum_package[nginx] action install (nginx::default line 11)
* No candidate version available for nginx
================================================================================
Error executing action `install` on resource 'yum_package[nginx]'
================================================================================
Chef::Exceptions::Package
-------------------------
No candidate version available for nginx
Resource Declaration:
---------------------
# In /var/chef/cache/cookbooks/nginx/recipes/default.rb
11: package "nginx" do
12: action :install
13: end
14:
Compiled Resource:
------------------
# Declared in /var/chef/cache/cookbooks/nginx/recipes/default.rb:11:in `from_file'
yum_package("nginx") do
package_name "nginx"
action [:install]
retries 0
retry_delay 2
default_guard_interpreter :default
declared_type :package
cookbook_name "nginx"
recipe_name "default"
flush_cache {:before=>false, :after=>false}
end
Platform:
---------
x86_64-linux
[2017-03-11T06:16:29-05:00] INFO: Running queued delayed notifications before re-raising exception
Running handlers:
[2017-03-11T06:16:29-05:00] ERROR: Running exception handlers
Running handlers complete
[2017-03-11T06:16:29-05:00] ERROR: Exception handlers complete
Chef Client failed. 1 resources updated in 05 minutes 44 seconds
And even i tried to install epel-release packages but denied with similar errors.
Any idea how we could install nginx with CHEF recipe.
I tried also using yum_package but had no luck in installing
yum_package "nginx" do
action :install
end
Thanks
This means there is no package named nginx in your repositories. If you log into the machine you want to provision (With kitchen login, for example), you can try to search package nginx.
The best way to install it if it is not in your repositories is either adding nginx´s official repo with a chef repository resource (Like yum_repository for Centos) or downloading the tarball with Chef resource remote_file.
If you choose the last option, be sure to generate a sha256 of the tarball you download and add it to the remote_file resource, so among other things you prevent Chef from downloading every run the file.
-Edit-
As Szymon says, you can also use the Nginx cookbook for this and don't write any special recipe.
As discussed here, you can use official NGINX chef cookbook or just install epel-release before installing NGINX:
if platform_family?('rhel')
package 'epel-release'
end
if platform_family?('debian')
apt_update 'update'
end
package 'nginx'

Resources