It's the background of my question: I'm running a Devstack(stable Juno release) on a Ubuntu 14.10 machine with Neutron enabled. When I spawn a VM, ssh to it and try to curl the metadata service(curl http://169.254.169.254), it returns a 500 error. The problem here is, that the configurations in /etc/neutron/metadata_agent.ini are set wrong. They look like this:
[DEFAULT]
...
auth_url = http://<my_ip_adress>:35357
...
admin_tenant_name = %SERVICE_TENANT_NAME%
admin_user = %SERVICE_USER%
admin_password = %SERVICE_PASSWORD%
After I have changed them to
[DEFAULT]
...
auth_url = http://<my_ip_adress>:35357/v2.0
...
admin_tenant_name = admin
admin_user = admin
admin_password = <admin_pwd>
everything works fine.
My question is now: how can I define these settings in my local.conf so I don't have to do it manually every time I unstack/stack the Devstack installation? Or is it a bug in the Devstack installation script?
You can change configurations in /etc/neutron/metadata_agent.ini by setting in local.conf:
[[post-config|$Q_META_CONF_FILE]]
[DEFAULT]
...
auth_url = http://<my_ip_adress>:35357/v2.0
...
admin_tenant_name = admin
admin_user = admin
admin_password = <admin_pwd>
Related
I have a raspberry pi with gitlab-runner installed (linux version) and a git repository on gitlab.com (not self hosted).
At the beginning of pipeline, gitlab-runner on raspberry try to fetch the .git repo but I get :
Could not resolve host: gitlab.com
I tried :
ping gitlab.com is ok on the raspberry
Add extra_host = ['localhost:my.ip.ad.ress] --> No changes
Add netword_mode = "gitlab_default" like this, And get :
This error :
Error response from daemon: network gitlab_default not found (exec.go:57:1s)
I am in the simplest configuration with repo on gitlab.com and a gitlab-runner on raspberry. How can I deal with it ?
Here is the config.toml :
concurrent = 1
check_interval = 0
[session_server]
session_timeout = 1800
[[runners]]
name = "gitlab runner on raspberryPi"
url = "https://gitlab.com/"
token = "XXXX"
executor = "docker"
[runners.custom_build_dir]
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
[runners.cache.azure]
[runners.docker]
tls_verify = false
image = "node:latest"
privileged = false
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/cache"]
shm_size = 0
I had same issue , my gitlab-runner was running on my local. I restarted my docker
systemctl restart docker
and error went away.
Not being able to resolve the host name can have multiple root-causes:
IP forwarding disabled?
Routing might be disabled on your system. Check if IP forwarding is enabled (== 1).
cat /proc/sys/net/ipv4/ip_forward
1
If it's disabled, it will return 0, please enable it by editing a sysctl file. For example edit and add: /etc/sysctl.d/99-sysctl.conf:
net.ipv4.conf.all.forwarding = 1
net.ipv4.ip_forward = 1
Apply the setting without rebooting: sudo sysctl --system
Important Note: Even if the system is reporting that IP forwarding is currently enabled, you might want to set to explicitly and correctly in your sysctl configs. Since Docker will run sysctl -w net.ipv4.ip_forward=1 when the Daemon starts-up. But that is not a persistent setting, and might cause very random issues!! Like you have.
DNS missing / invalid?
You can try if setting a DNS server to 8.8.8.8 might fix the problem:
[runners.docker]
dns = ["8.8.8.8"]
Add extra_host?
You can also try to add an extra host, which might be mainly relevant within a local network (so not with gitlab.com domain).
[runners.docker]
extra_hosts = ["gitlab.yourdomain.com:192.168.xxx.xxx"]
Using host network
I really do not advise this, but you could configure the Docker container to run with network_mode as "host". Again, only do this for debugging reasons:
[runners.docker]
network_mode = "host"
I'm currently trying to configure our WSO2 API Manager 3.2 to use our SSL certificate.
I followed the documentation "Creating a New Keystore" and "Configuring Keystores in API Manager".
I have updated the deployment.toml file:
[server]<br>
hostname = "myserver001.internal.net"
....
[keystore.tls]
file_name = "myKeystore.jks"
type = "JKS"
password = "secretpassword"
alias = "myserver001.internal.net"
key_password = "secretpassword"
[keystore.primary]
file_name = "wso2carbon.jks"
type = "JKS"
password = "wso2carbon"
alias = "wso2carbon"
key_password = "wso2carbon"
The servername is set to myserver001.
The domain name myserver001.internal.net is set in the host file.
After restarting the WSO2 APIM server an exception message is thrown:
SSLException: hostname in certificate didn't match:
<localhost> != <myserver001.internal.net> OR <myserver001.internal.net>
Does anyone knows what I have to change additionally, to come around this error or where I can find additional documentation?
Any help is appreciated
Looks this is due to the missing service_url of TM/Event hub config. So can you add/update the following config?
[apim.throttling]
...
service_url = "https://myserver001.internal.net:9443/services/"
I was in the exact same situation :
Migration from v2.6.0 to v3.2.0
Valid certificate
SSLException: hostname in certificate didn't match
I tried a lot of things, but after a lot of researches, I'd say that there is two possibilities :
It's a bug
It's a documentation problem, and we have to edit more things to make our certificate work
I believe that you changed the Dhttpclient.hostnameVerifier to another value than "AllowAll". See the doc about hostname verification.
It's just a workaround and it's probably not that secure, but you'll have to put back the default value for Dhttpclient.hostnameVerifier to avoid this error :
service wso2am-3.2.0 stop
nano /usr/lib/wso2/wso2am/3.2.0/bin/wso2server.sh
-Dhttpclient.hostnameVerifier=AllowAll \
service wso2am-3.2.0 start
I have install Keystone following the guide for Ubuntu14.04
When i try to create a service entity:
openstack service create --type identity \
--description "Openstack Identity" keystone
I obtain:
INFO: urllib3.connectionpool Starting new HTTP connection (1): controller
ERROR: cliff.app Internal Server Error (HTTP 500)
I am sure that i have connection to "controller",and mysql is configured to accept connections from any host.
My configuration file of keystone is:
[DEFAULT] admin_token =ADMIN
admin_port=35357
public_port=5000
[database]
connection = mysql://keystone:keystone#controller/keystone
[memcache]
servers = localhost:11211
[token]
provider = keystone.token.providers.uuid.Provider
driver =keystone.token.persistence.backends.memcache.Token
[revoke]
driver = keystone.contrib.revoke.backends.sql.Revoke
[DEFAULT]
verbose = True
And Apache is configured as shown in the guide.
Where am i failing?
I dont' know if you found and answer already but I also had this problem.
The reason was quite simple really, one of the instructions on the guide didn't work for me. This is the one:
# apt-get install ubuntu-cloud-keyring
# echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu" \
"trusty-updates/kilo main" > /etc/apt/sources.list.d/cloudarchive-kilo.list
So I was not using the kilo packages but older ones (urllib3 being one of them). How to fix this? Just create this file manually:
nano /etc/apt/sources.list.d/cloudarchive-kilo.list
And just write this inside:
deb http://ubuntu-cloud.archive.canonical.com/ubuntu trusty-updates/kilo main
Finish it with this command, to make the update:
# apt-get update && apt-get dist-upgrade
You should have a lot of new updates now.
There you go, hope it helps, it fixed the problem for me at least.
Bruno
I'm trying to deploy Openstack Icehouse on Ubuntu Server 14.04 by following the official document. But after Keystone\Nova\Neutron\Glance were deployed, when I tried to launch a CirrOS instance by
nova boot -nic ... -image ... -flavor ...
, it failed.
The log in Nova client shows that:
The Neutron client(Yes, it's neutron. I guess there are interactions between them in booting) tried to connect with Neutron server to create a port on tenant's network.
But Neutron client set up the token-getting request using {username:neutron, password:REDACTED} to Keystone server and used that token to request for creating port to Neutron server.
Finally, the Neutron Server decided that that's an authentication problem.
I'm sure that I requested to create instance using tenant 'demo''s info($OS_TENANT_NAME, $OS_USERNAME, $OS_PASSWORD, $OS_AUTH_URL were properly set with 'demo''s value) by
source demoopenrc.sh
with demo's credential in that file.
Is that something wrong in the Neutron client's configuration or booting process? I paste a part of the neutron.conf here:
the Keystone setting
[keystone_authtoken]
auth_uri = http://controller:5000
auth_host = controller
auth_port = 35357
auth_protocol = http
admin_tenant_name = service
admin_user = neutron
admin_password = neutronpass
signing_dir = $state_path/keystone-signing
Since the Neutron client used 'neutron' user's credential for token getting, is there something wrong in this part?
The problem has been solved after nearly a month. For anyone still interested in this problem, please visit here
I've tried almost everything in the past couple of days to get keystone running to no avail.
The setup is all on the same host, the virtualization and openstack and keystone are all on the same host, so I've tried setting up keystone with 127.0.0.1 and localhost and the IP of the host with no luck
[DEFAULT] log_file = /var/log/keystone/keystone.log
admin_token = ***
bind_host = 192.168.33.11
public_port = 5000
admin_port = 35357
compute_port = 8774
# === Logging Options ===
# Print debugging output verbose = True
# Print more verbose output
# (includes plaintext request logging, potentially including passwords)
# debug = False
# Name of log file to output to. If not set, logging will go to stdout. log_file = keystone.log
# The directory to keep log files in (will be prepended to --logfile) log_dir = /var/log/keystone
# Use syslog for logging.
# use_syslog = False
# syslog facility to receive log lines
# syslog_log_facility = LOG_USER
# If this option is specified, the logging configuration file specified is
# used and overrides any other logging options specified. Please see the
# Python logging module documentation for details on logging configuration
# files. log_config = logging.conf
# A logging.Formatter log message format string which may use any of the
# available logging.LogRecord attributes.
# log_format = %(asctime)s %(levelname)8s [%(name)s] %(message)s
# Format string for %(asctime)s in log records.
# log_date_format = %Y-%m-%d %H:%M:%S
# onready allows you to send a notification when the process is ready to serve
# For example, to have it notify using systemd, one could set shell command:
# onready = systemd-notify --ready
# or a module with notify() method:
# onready = keystone.common.systemd
[sql] connection = mysql://keystone:***#localhost/keystone
# idle_timeout = 200
[identity] driver = keystone.identity.backends.sql.Identity
[catalog] template_file = /etc/keystone/default_catalog.templates driver = keystone.catalog.backends.sql.Catalog
# dynamic, sql-based backend (supports API/CLI-based management commands)
# driver = keystone.catalog.backends.sql.Catalog
# static, file-based backend (does *NOT* support any management commands)
# driver = keystone.catalog.backends.templated.TemplatedCatalog
# template_file = default_catalog.templates
[token] driver = keystone.token.backends.sql.Token
# driver = keystone.token.backends.kvs.Token
# Amount of time a token should remain valid (in seconds)
# expiration = 86400
I've enabled logging in the logging.conf file and set the level to DEBUG and INFO, however nothing in log files.
[root#* keystone]# service openstack-keystone restart
Stopping keystone: [FAILED]
Starting keystone: [ OK ]
[root#* keystone]# service openstack-keystone restart
Stopping keystone: [FAILED]
Starting keystone: [ OK ]
[root#* keystone]# ps aux | grep keystone
root 25580 0.0 0.0 103236 880 pts/1 S+ 09:41 0:00 grep keystone
[root#* keystone]#
Any ideas will be greatly appreciated.Thank you
As I mentioned in the comment, I've never seen a config file with the section headings on the same line as config option:
[DEFAULT] log_file = /var/log/keystone/keystone.log
I've also seen it like this instead:
[DEFAULT]
log_file = /var/log/keystone/keystone.log
However, I have no idea if this is related to your issue.
To enable debug-level logging, make sure you set the following in /etc/keystone/logging.conf:
[logger_root]
level=DEBUG
Then try running keystone manually instead of as a service:
$ sudo -u keystone bash
$ HOME=/var/lib/keystone keystone-all --debug
Hopefully you'll see a relevant error message on standard out.
(I believe it will still send the logging to /var/log/keystone/keystone.log, not sure how to actually get it to log to standard out when running manually like this).
Add a valid token for admin_token. It should not be "*".
Check the below line:
[sql] connection = mysql://keystone:*#localhost/keystone
It should be something like:
connection = mysql://keystone:keystone#localhost/keystone
Refer to this url for an example keystone.conf file
http://docs.openstack.org/trunk/openstack-compute/install/yum/content/keystone-conf-file.html
I ran into this issue as well. I am running on Ubuntu 12.04LTS. What i found was the the service start command in /etc/init/keystone.conf is using start-stop-daemon to run the service. It was written for a newer version than the one on my box. The --chdir variable is not accepted as an input. once i removed that line keystone started right up.
Try running:
start-stop-daemon --start --chuid keystone --name keystone --exec /usr/bin/keystone-all
/etc/init/keystone.conf after
description "Keystone API server"
author "Soren Hansen <soren#linux2go.dk>"
start on runlevel [2345]
stop on runlevel [!2345]
respawn
exec start-stop-daemon --start --chuid keystone \
--name keystone \
--exec /usr/bin/keystone-all
Check if your IP-adress is equal to HOST_IP=... in localrc
This might be due to keystone not getting started properly and therefore port 35357 is not in listening mode.
This seems to be anomalous behavior of service keystone.
I am mentioning steps which have worked on my system for havana installtion on Ubuntu 12.04 Kernel version 3.2.0-67-generic. After a day of headache around this issue. Try these steps, preferably in the same order.
1) Remove keystone package:-
apt-get remove keystone
2) Reboot your system
reboot
3) After reboot again INSTALL KEYSTONE.
apt-get install keystone
4) Check status of keystone service
service keystone status
It will show start/running
5) Now do the necessary changes you want to do in /etc/keystone/keystone.conf
after making changes in conf file DO NOT RESTART KEYSTONE SERVICE
Use stop and start command to make an effect of restart but don't restart.
service keystone stop
service keystone start
For further help, pasting a dump of my CLI :-
http://pastebin.com/sduuFCL7
There are multiple problems with the icehouse documentations and install. packstack is broken so the only way to get started is to manually follow the upstream docs for your distro. keystone is very important to set up first correctly before moving on, because other services rely on it.
the paste-file /usr/share/keystone/keystone-dist-paste.ini should be copied to /etc/ to be accessible to the config scripts like this:
cp /usr/share/keystone/keystone-dist-paste.ini /etc/keystone/
chown keystone:keystone /etc/keystone/*
make sure to update keystone.conf with the new config_file value
documentation is wrong about the mysql connection, it should go to [sql] and not [database] so:
openstack-config --set /etc/keystone/keystone.conf sql connection mysql://keystone:PASSWD#controller/keystone
the name controller should be resolved to whatever mysql is bound to, I will add it to /etc/hosts like this if [mysqld]/bind-address in /etc/my.cnf is 10.1.1.100:
10.1.1.100 controller
make sure to uncomment log_file in keystone.conf to get what is happening.
I was facing similar issue.I followed below mentioned steps and openstack-keystone service got started.
Edit the /etc/keystone/keystone.conf file and complete the following actions:
In the [DEFAULT] section
[DEFAULT]
admin_token = ADMIN_TOKEN
In the [database] section
[database]
connection = mysql://keystone:KEYSTONE_DBPASS#controller/keystone
In the [token] section, configure the UUID token provider and SQL driver
[token]
provider = keystone.token.providers.uuid.Provider
driver = keystone.token.persistence.backends.sql.Token
In the [revoke] section
[revoke]
driver = keystone.contrib.revoke.backends.sql.Revoke
After making above changes populate the Identity service database using command
su -s /bin/sh -c "keystone-manage db_sync" keystone
Start the openstack-keystone service using below command
systemctl start openstack-keystone