I tried to access Horizon as recommended here, through the IP 10.20.20.1 and admin user, and received the following runtime error:
Request Method: | POST
-- | --
http://10.20.20.1/auth/login/
2.0.13
RuntimeError
Unable to create a new session key. It is likely that the cache is unavailable.
/snap/microstack/196/lib/python3.6/site-packages/django/contrib/sessions/backends/cache.py in create, line 51
/snap/microstack/196/bin/uwsgi
3.6.9
['.', '', '/snap/microstack/196/usr/lib/python36.zip', '/snap/microstack/196/usr/lib/python3.6',
'/snap/microstack/196/usr/lib/python3.6/lib-dynload', '/snap/microstack/196/usr/lib/python3/dist-packages',
'/snap/microstack/196/lib/python3.6/site-packages', '/snap/microstack/196/lib/python3.6/site-packages/openstack_dashboard']
Mon, 17 Aug 2020 12:42:48 +0000
The expected result would be a successful login.
Check on which address Memcached is running. With the command:
systemctl status memcached
And set that IP address in the local_settings.py mine it's located in /etc/openstack-dashboard/local_settings.py
CACHES = {
'default': {
'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
'LOCATION': '192.168.122.2:11211',
},
}
I faced the same issue. For me, adding -l 10.20.20.1 (below -l 127.0.0.1) in /etc/memcached.conf and restarting memcached with systemctl restart memcached seemed to do the trick.
Related
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
Novice Artifactory user here so please bear with.
Trying to use curl on linux to deploy a file in a repo and failing. trying this running on the same server that's serving artifactory.
% --> curl -u my_idsid -X PUT
"http://localhost:8081/artifactory/test_repo/test_artifact_linux_01" -T
test_aftifact_linux_01
Enter host password for user 'my_idsid':<I entered the pw die my_user here>
HTTP/1.1 100 Continue
HTTP/1.1 403 Forbidden
Server: Artifactory/5.4.6
X-Artifactory-Id: 3444ab9991d26041:29864758:15e2f4940fa:-8000
Content-Type: application/json;charset=ISO-8859-1
Content-Length: 65
Date: Tue, 05 Sep 2017 21:00:20 GMT
Connection: close
{
"errors" : [ {
"status" : 403,
"message" : ""
} ]
}
I was able to put (deploy) a file (an artifact) in this same repo from windows with the drag-drop method for that same user. So I'm thinking that this confirms several things...
1) the repo exists
2) the permissions to allow that user write access is ok
3) the server is up and running ok
And the pw is OK, because when I intentionally enter something wrong, it comes up with a 401 instead.
I looked in artifactory.log and it has this for my attempt...
2017-09-05 17:15:00,332 [http-nio-8081-exec-7] [WARN ]
(o.a.w.s.RequestUtils:155) - Request /test_repo/test_artifact_linux_01
should be a repo request and does not match any repo key
Does not match a repo key ?
I'm using the example here...
https://www.jfrog.com/confluence/display/RTF/Artifactory+REST+API#ArtifactoryRESTAPI-Example-DeployinganArtifact
and plugging in the repo name right after "artifactory" (replacing "my_repository") in the path.
I have a strong suspicion that I'm goofing up the path name, but I don't know what's wrong. How does one determine the proper path to use ?
Thanks in advance for any help.
UPDATE:
My bad. The repo was actually named "test-repo", not "test_repo".
Worked fine once I made that change.
Sorry for the false alarm.
I try to install https://github.com/roots/bedrock-ansible to get a bedrock deployment (http://roots.io/wordpress-stack/) running.
When I run "vagrant up", after some time I get the error:
TASK: [capistrano-setup | Setup deploy group] *********************************
skipping: [default]
TASK: [capistrano-setup | Setup deploy user] **********************************
skipping: [default]
TASK: [capistrano-setup | Adding public key to server] ************************
fatal: [default] => could not locate file in lookup: ~/.ssh/id_rsa.pub
FATAL: all hosts have already failed -- aborting
PLAY RECAP ********************************************************************
to retry, use: --limit #/Users/johannes/site.retry
default : ok=46 changed=16 unreachable=1 failed=0
Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.
I do not have a clou how i can fix this. Do you have an idea?
It seems the role is trying to find your local public key. It should be in the location in the error message '~/.ssh/id_rsa.pub', but it's not. So either you don't have one, or you keep it in another location.
If you're not familiar with generating SSH keys you probably don't have one. I personally like the GitHub help page for this: https://help.github.com/articles/generating-ssh-keys/
(you only have to perform steps 1 and 2).
If you do have SSH keys, but in a different location, the capistrano-install role in bedrock uses some variables:
deploy_user: deploy
deploy_keys:
- "~/.ssh/id_rsa.pub"
So you can set (multiple) public key files in the deploy_keys list and they will be added to the deploy_user's authorized keys.
All this is needed because Capistrano will use the deploy user to connect to the remote server later. http://blakesmith.me/2010/02/08/understanding-public-key-private-key-concepts.html
I installed openldap 2.4.35 from source tarball with berkeleydb 5.0.32.NC on CentSO 6.4 x86_64.
After running a few days , the ldap server shutdown unexpectedly. And here is the last log:
ber_get_next
TLS trace: SSL3 alert read:warning:close notify
52b7b798 ber_get_next on fd 13 failed errno=0 (Success)
52b7b798 conn=1023 op=70 do_unbind
52b7b798 connection_close: conn=1023 sd=13
TLS trace: SSL3 alert write:warning:close notify
52b7cbba daemon: shutdown requested and initiated.
52b7cbba slapd shutdown: waiting for 0 operations/tasks to finish
52b7cbba slapd shutdown: initiated
52b7cbba ====> bdb_cache_release_all
52b7cbba slapd destroy: freeing system resources.
52b7cbba slapd stopped.
The configuration file (slapd.conf):
include /home/ucportal/local/openldap/etc/openldap/schema/core.schema
include /home/ucportal/local/openldap/etc/openldap/schema/corba.schema
include /home/ucportal/local/openldap/etc/openldap/schema/cosine.schema
include /home/ucportal/local/openldap/etc/openldap/schema/duaconf.schema
include /home/ucportal/local/openldap/etc/openldap/schema/dyngroup.schema
include /home/ucportal/local/openldap/etc/openldap/schema/inetorgperson.schema
include /home/ucportal/local/openldap/etc/openldap/schema/java.schema
include /home/ucportal/local/openldap/etc/openldap/schema/misc.schema
include /home/ucportal/local/openldap/etc/openldap/schema/nis.schema
include /home/ucportal/local/openldap/etc/openldap/schema/openldap.schema
include /home/ucportal/local/openldap/etc/openldap/schema/ppolicy.schema
include /home/ucportal/local/openldap/etc/openldap/schema/collective.schema
include /home/ucportal/local/openldap/etc/openldap/schema/uc.schema
pidfile /home/ucportal/local/openldap/var/run/slapd.pid
argsfile /home/ucportal/local/openldap/var/run/slapd.args
loglevel 1
logfile /home/ucportal/openldap/var/log/slapd.log
database bdb
suffix "dc=ucweb,dc=com"
rootdn "cn=admin,dc=ucweb,dc=com"
rootpw 123456
directory /home/ucportal/local/openldap/var/openldap-data
index objectClass eq
index entryUUID,entryCSN eq
TLSCACertificateFile /home/ucportal/openldap/etc/openldap/cacerts/ca.crt
TLSCertificateFile /home/ucportal/openldap/etc/openldap/ldap-server.crt
TLSCertificateKeyFile /home/ucportal/openldap/etc/openldap/ldap-key.pem
Attention : I installed and run openldap with non-root user
I used this command to start ldap daemon process: slapd -f ~/openldap/etc/openldap/slapd.conf -d 1 -h 'ldaps://0.0.0.0:6361'
Any suggestions?
This is a very common issue with Open-LDAP servers, firstly I'll recommend you to migrate this question to serverfault. This will be a good practice to always run your daemons with root priviledges.
Based on my so far research I'd like to share these links with you, I hope they may help you to fix your problems.
http://www.clearfoundation.com/component/option,com_kunena/Itemid,232/catid,10/func,view/id,19945/
http://www.openldap.org/lists/openldap-software/200502/msg00268.html
Configure OpenLDAP
https://serverfault.com/questions/138286/configuring-openldap-and-ssl
http://www.openldap.org/doc/admin24/slapdconf2.html
I have devstack installed on a ubuntu 12.04 and I could get logged into Dashboard , Now I changed the IP of my ubuntu machine. After changing the IP, I couldn't log into Dashboard anymore
I gets the following error message. I can see my old IP in the error message.
ConnectionError at /auth/login/
HTTPConnectionPool(host='OLD_IP_ADDRESS', port=35357): Max retries exceeded with url: /v2.0/tokens (Caused by <class 'socket.error'>: [Errno 113] No route to host)
Request Method: POST
Request URL: http://NEW_IP_ADDRESS/auth/login/
Django Version: 1.4.5
Exception Type: ConnectionError
Exception Value:
HTTPConnectionPool(host='OLD_IP_ADDRESS', port=35357): Max retries exceeded with url: /v2.0/tokens (Caused by <class 'socket.error'>: [Errno 113] No route to host)
Exception Location: /usr/local/lib/python2.7/dist-packages/requests/adapters.py in send, line 246
Python Executable: /usr/bin/python
Python Version: 2.7.3
Python Path:
['/opt/stack/horizon/openstack_dashboard/wsgi/../..',
'/opt/stack/python-keystoneclient',
'/usr/local/lib/python2.7/dist-packages',
'/opt/stack/python-glanceclient/setuptools_git-1.0b1-py2.7.egg',
'/opt/stack/python-glanceclient',
'/opt/stack/python-cinderclient',
Is there a documented procedure available to change the IP address manually ?
My New IP doesn't have connection to internet so I wouldn't be able to redeploy devstack
Thanks guys for your answers..
I missed to update my answer, I fixed that issue in an easy way.
Solution is first run unstack.sh and then run stack.sh once more. It will do the necessary fix. Since I haven't made much progress with Devstack after installation it makes me more confident to run stack.sh
For the second time when you run stack.sh its not needed to connect to internet, So my issue is fixed.
Feel free to share your thoughts on this.
You will need to change the IP address hard-coded in OpenStack configuration files generated by devstack. They are stored in /etc/ and elsewhere.
http://xmodulo.com/2013/04/how-to-change-ip-address-after-openstack-installation-via-devstack.html
Here's a few steps I've taken to get back online.
backup the answers file...
cp packstack-answers-20130417.txt packstack-answers.txt-SAVE
replace ip addresses...
sed -i '/s/10\.10\.248\.11/10\.32\.70\.10/g' packstack-answers-20130417.txt
Delete the cinder loopback devices, installer fails if it exists
losetup -d /dev/loop0
List what's left mounted via the loop.
losetup -a
rm /var/lib/cinder/cinder-volumes
Now rerun the deploy scripts
packstack --answer-file=packstack-answers-20130417.txt
Fix up other IP addressing concerns with nova-manage in the CLI.
Should work from here.