I am new to CouchDB and have run into an odd issue. I can create a database but can't delete it.
I am setting up a test framework which will create the test version of the DB at the start and delete it at the end of the test run but I don't really want to have the framework SSH to the server as suggested in this answer Delete couchDB databases.
My setup is CentOS 7 (from the released minimal image) running in Virtual Box 4.3. I installed CouchDB from the EPEL repository, the version is reported as 1.6.1. I can manage the DB with Futon to create the database, add and delete documents. Deleting the DB in Futon hangs. Deleting with curl returns 404 not found.
$ curl -X PUT http://dbserver:5984/test
{"ok":true}
$ curl -X DELETE http://dbserver:5984/test
{"error":"not_found","reason":"missing"}
Based on the CouchDB documentation that is the correct URL to delete the DB. I disabled SELinux but that had no effect. No CouchDB security has been enabled, all settings are left at their default.
Why can't I delete the DB?
The problem seems to be a missing SELinux policy.
Running SELinux in Permissive mode, makes the "verify installation" checks work for me. (CentOS 7, couchdb 1.6.1 installed via yum from the EPEL repository).
Looking in /var/audit/audit.log reveals:
type=AVC msg=audit(1422956916.341:371): avc: denied { create } for pid=2188 comm="beam" name=".test_suite_db_design" scontext=system_u:system_r:rabbitmq_beam_t:s0 tcontext=system_u:object_r:couchdb_var_lib_t:s0 tclass=dir
So, SELinux denied the couchdb process to create that directory.
Using the audit2allow tool one may create the missing rules which could be enabled using semodule command:
grep couchdb /var/log/audit/audit.log | audit2allow -M couchdbvarlib
semodule -i couchdbvarlib.pp
See here.
There's already a bug reported against CouchDB in Fedora #1098802
Related
I'm trying to connect to database restored from disk snapshot. I have new VM with ubuntu 18.04. I installed postgres, postgres-client and postgres-contrib from *.deb files. Then I mounted managed disk into machine with database and tried to connect - no success.
Postgres server running good, cluster ok, status ok, pg_isready ok. Until I change the data_directory in postgresql.conf from default to mounted - /snapshot_data_path/. After that my cluster is down and I cannot use psql in postgres (error ~ .s.PGSQL missing. File dissapearing from default directory).
chown -R to /snapshot_data_path - done, looks ok.
I think my database is running manualy when I use :
/usr/lib/postgresql/9.5/bin/postgres -d 3 -D /database/postgresql/9.5/main -c config_file=/etc/postgresql/9.5/main/postgresql.conf with that new path. EDIT: Error, I can connect but no data inside.
I try search over the internet for similar problems - no luck.
Is it possible to take database from 1 VM and connect it with another fresh VM? Or I must use pg_dump to achieve that?
Here the official documentation on this topic: https://www.postgresql.org/docs/9.0/backup-file.html
The database server must be shut down in order to get a usable backup.
Did you shutdown the server while the data snapshot was taken?
In some beta version of Arangodb 3.4 my database crashed while I tried to add a view via arangosh. Because I were not able to start the database anymore, it was not possible to make a backup (database dump).
I just wanted to install the newest Arangodb 3.4.2.1 then, but that failed because my CPU was to old (no SSE 4.2 support). So I bought a new computer, sat up a new linux, copied the databases to /var/lib/arangodb3/databases, started a new installation of Arangodb in which it even asked me, if the current databases should be upraded. I confirmed that.
Unfortunately it hasn't found the databases in that directory, so I have now just acces to the system database.
My question is: Can I recover the databases which are laying in /var/lib/arangodb3/databases somehow?
Do you have a copy of the "var/lib/arangodb3" directory (which includes "databases" as a subfolder) as well? If so, copy the folder to a location on your new machine where Arangodb 3.4.2.1 is installed. You also have to make sure to give the user arangodb access to this folder with the following command:
chown -R arangodb:arangodb /path/to/your/arangodb3RecoveryFolder
Next you can modify the arangod.conf (located at /etc/arangodb3/arangod.conf) to point to your recovery arangodb3 folder.
[database]
directory = /path/to/your/arangodb3RecoveryFolder
Then stop the arangodb3 service with sudo service arangodb3 stop,
run sudo service arangodb3 upgrade to upgrade the database directory and sudo service arangodb3 start to start the service again.
You can check if the service is running by executing sudo service arangodb3 status. In case it is not working, have a look at potential error messages in the log file (/var/log/arangodb3/arangod.log).
I'm using Centos 6.9. I have installed Redis using yum:
sudo yum update
sudo yum install redis
No errors were given during the installation.
I can start Redis using redis-cli. It gives me the prompt as expected:
127.0.0.1:6379>
However whenever I issue commands (e.g. PING or SET foo bar) it's giving the following error message:
(error) MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error.
I've found MISCONF Redis is configured to save RDB snapshots. and gone through it but none of the advice in there works.
The Accepted Answer on the above was to use CONFIG SET to change the directory where Redis was storing data. I tried this in a non-root directory, CONFIG SET dir /home/andy, but it still gives me the same error message.
If I execute BGSAVE it says "Background saving started" but then attempting SET foo bar goes back to giving me the error above.
Other answers have discussed this being a permissions issue. However I don't see how these apply because I've tried starting Redis as both root and my own account (andy) and the same occurs.
I'm not sure if it's the same problem as described on the link or something else.
How can I further diagnose this? I am a PHP developer by trade so this is not my area of expertise, however I am trying to install Redis so I can use it with a PHP application which has it's own interface to Redis.
It seems that the yum installation creates a redis user, and your Redis instance is running by this user. So even if you set dir to /home/andy, this redis user still doesn't have permission to write to andy's home directory.
Use ps aux |grep redis to get the user who's running redis, and config dir to a directory that this user has write permission.
Quick fix for this error is, goto redis-cli and set following
127.0.0.1:6379> config set stop-writes-on-bgsave-error no
Above like just ignore it
I solved the problem by executing following commands:
$ redis-cli
> config set stop-writes-on-bgsave-error no
I've installed GitLab on Google Compute Engine using "Click to Deploy" from the project interface. The deployment is successful after a few minutes. I can SSH into the instance, and muck around with it as expected.
I can also log in to GitLab using the web interface, and add SSH keys to my profile. So far, so good. However, when I attempt to push or pull to a new example repository, I receive this message:
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
I've removed my local SSH config so it doesn't interfere. Do I need to setup an SSH tunnel of some sort? What am I missing?
UPDATE: Wiping out my local ~/.ssh folder, and regenerating an SSH key (which I've added to my profile in GitLab) produces the following error:
Received disconnect from {GITLAB_IP_ADDRESS}: 2: Too many authentication failures for git
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
UPDATE 2: It seems GitLab may already have a solution: run sudo gitlab-ctl reconfigure. See here: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md#git-ssh-access-stops-working-on-selinux-enabled-systems
You need to create an SSH tunnel to communicate with GitLab.
1. Log into your development server as your user, and create a key.
ssh-keygen -t rsa
Follow the steps, and create a passcode (that you can remember) as you'd need this to pull and push code from/to GitLab.
2. Now that you've created your key, we can copy it;
cat id_rsa.pub
Copy the output of that command (including ssh-rsa), and add it to your GitLab profile. (http://my-gitlab-server.com/profile/keys/new).
3. Ensure you have the correct privilege to the project(s)
Ensure you are at role developer at the very least. (Screengrab of roles: http://i.stack.imgur.com/DSSvl.jpg)
4. Now, copy the project link
Go into your project, and find the SSH link in the top right;
5. Now back to your development server
Navigate to your directory where you'd like to work, and run the following;
$ git init
$ git remote add origin <<project_url>>
$ git fetch
Where <<project_url>> is the link we copied in step 4.
You will be prompted your password (this is your ssh key password, not your server password) and to add the host to your known_hosts file. After that, the project will start to download and you can enjoy development.
I did these steps on a CentOS 6.4 machine with Digital Ocean. But they shouldn't differ from using Google CE.
Edit
Quote from Marty Penner answer as per this comment
Solved it! Thanks to #sxleixer and #Alexander Wenzowski for figuring this out.
Apparently, SELinux was interfering with a non-standard location for the .ssh directory. I needed to run the following commands on the Compute Engine instance:
sudo yum -y install policycoreutils-python # Install the `semanage` tool
sudo semanage fcontext -a -t ssh_home_t "/var/opt/gitlab/.ssh/authorized_keys" # Allow the nonstandard ssh_home_t
See the full thread here:
Google Cloud Engine. Permission denied (publickey,gssapi-keyex,gssapi-with-mic)
Solved it! Thanks to #sxleixer and #Alexander Wenzowski for figuring this out.
Apparently, SELinux was interfering with a non-standard location for the .ssh directory. I needed to run the following commands on the Compute Engine instance:
sudo yum -y install policycoreutils-python # Install the `semanage` tool
sudo semanage fcontext -a -t ssh_home_t "/var/opt/gitlab/.ssh/authorized_keys" # Allow the nonstandard ssh_home_t
See the full thread here:
Google Cloud Engine. Permission denied (publickey,gssapi-keyex,gssapi-with-mic)
UPDATE: It seems GitLab may already have a solution: run sudo gitlab-ctl reconfigure. See here: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md#git-ssh-access-stops-working-on-selinux-enabled-systems
In my situation the git user wasn´t set up completely. If you get in your log files messages like "User git not allowed because account is locked" (Under Centos or Redhat it´s /var/log/secure) than you simply need to activate the user via "passwd -d git"
Does anyone know how can I reset the username and password for CouchDB ?
This worked for me:
while couchdb is stopped,
clear the [admin] section in your */etc/couchdb/local.ini
delete the _users.couch database (located in */var/lib/couchdb/)
This will reset the user database to factory defaults (admin party!) and wipe all of couchdb's user accounts. There might be a more subtle way
With Apache CouchDB, admin accounts passwords can be changed by editing a file local.ini in the CouchDB config folder (/etc/couchdb/ on most Linux installs). [1]
Look for the [admin] section, which will list the all admin usernames, along with their hashed passwords:
[admin]
foo = -pbkdf2-0e0e83f911c970565fc988497a657bdc21a005e8,19ecef0bea1caf8d7f08fb791379c686,10
Replace the password hash with a new clear text password:
foo = bar
Now restart CouchDB (sudo restart couchdb on Ubuntu). CouchDB will notice the clear text password on startup and automatically replace it with the hashed version.
What I've done it's quite simple. I found out my old username and password here:
/opt/couchbase/var/lib/couchbase/config/config.dat
After that I went to opt/couchbase/bin/ and run
./couchbase-cli cluster-init -c localhost:8091 -u old_user -p old_password --cluster-init-username=new_user --cluster-init-password=new_password
Done!
Also you can check this: http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase-faq.html
For mac users, base folder is /Library/Application Support/couchdb
One more point to add ...
If you are running Couch DB on Windows, then probably it was installed as a service and to reset it you need to stop service first, within running service other answers do not work.
http://www.7tutorials.com/what-are-windows-services-what-they-do-how-manage-them
Open Control Panel - Administrative Tools - Services and stop Apache Couch DB
for Unix:
http://silviud.blogspot.com/2012/10/couchbase-recover-web-console-password.html
/opt/couchbase/bin/erl \
-noinput -eval \
'case file:read_file("/opt/couchbase/var/lib/couchbase/config/config.dat") of {ok, B} -> io:format("~p~n", [binary_to_term(B)]) end.' \
-run init stop | grep cred
You just need to add the username and password in CouchDB local.ini file. You can add as many administrators as you want.
sudo nano /etc/couchdb/local.ini
and in the end of file, add username and password.
And don't forget to restart the CouchDB server.
sudo service couchdb restart
On Mac OS X, cbreset_password is not in PATH by default, so I've done just:
"/Applications/Couchbase Server.app/Contents/Resources/couchbase-core/bin/cbreset_password" 127.0.0.1:8091
...and re-set the password once confirming yes
You can change couchbase localhost password by using following steps:
1. Install crul(for windows)
2. curl -u Administrator:password http://localhost:8091/controller/changePassword -d password=admin123
ubuntu 20.04 :
apt purge couchdb
apt install couchdb
was the only thing that worked for me.
If using 3.2, CouchDB server administrators and passwords in the last [admins] section that CouchDB finds when loading its ini files:
/opt/couchdb/etc/local.ini or
/opt/couchdb/etc/local.d/10-admins.ini
Don't forget to restart CouchDB:
sudo systemctl restart couchdb (if using ubuntu)
source: https://docs.couchdb.org/en/3.2.0/config/auth.html