curl localhost:5984/_users/org.couchdb.user:tyler
{"error":"not_found","reason":"missing"}
I am logged into futon as tyler, so i know that user exists.
Anyone know what i'm doing wrong?
This will happen if you create a server admin via the local.ini configuration file. No _users document is created in that case, but you can still log in via futon.
Related
We are going to change cassandra setting from authenticator: AllowAllAuthentication to authenticator: PasswordAuthenticator
to enable role-based authentication. There will be two roles:
admin which is a superuser
read-only which is only allowed to read.
I would like to provide backward compatibility for users of the cassandra cluster. More specifically,
many users use
shell script that uses cqlsh
python cassandra package
php cassandra package
to only read data from cassandra. Currently they don't specify any username or password. Therefore
I would like to make read-only role some sort of a "default" role, i.e. if no username and password provided,
then the role is automatically set to read-only so the users can read data and thus clients don't need to change their code.
Is there a way to do this? I'm currently having trouble in the following two parts:
the default user is cassandra if there is no role / user specified in cqlsh. I did not find a way to set default user / role.
and for the default user cassandra, I still have to set a password for it.
Any suggestions would be appreciated! Thanks in advance.
I come from an oracle background, were I've done "sqlplus "/as sysdba"" for years. I like it because the O/S authenticates me. Now, there is something similar in Cassandra, but it isn't secure. Basically in your home directory there is a subdirectory called ".cassandra" (hidden). In that directory there is a file (if there isn't, create one) called "cqlshrc" (so ~/.cassandra/cqlshrc). That file you can add authentication information that will allow someone to log in by simply typing "cqlsh" without anything else (unless you're doing remote where you need "host" and "port"). The cqlshrc file has, among other things an authentication section that looks like this:
[authentication]
username = <your_user_name>
password = <your_password>
So you could simply put your desired username and password in that file and you're essentially able to connect without supplying your username and password (You could also run "cqlsh -u your_user_name" and it will find your password in your cqlshrc file as well).
You can see a few obvious issues here:
1) The password is in clear text
2) If you change the password you need to change the password in the cqlshrc file
I do not recommend you use the "cassandra" user for ANYTHING. In fact, I'd drop it. The reason is because the cassandra user does everything with CL=quorum. We found this out when investigating huge I/O requests coming from OpsCenter and our backup tool (as you can see, we use DSE). They were all using cassandra and pounding on the node(s) that had the cassandra authentication information. It's baked into the code apparently to have CL=quorum - kinda dumb. Anyway, the above is one way to have users log in with a specific user and not provide credentials making it pretty easy to switch.
Hope that helps
-Jim
I am new to couchDB world after installing its latest version I am getting login window. I don't know what is default username and password.
Thanks in advance!
To verify if you already have and admin user configured you should check the local.ini config file in CouchDB.
In macOS for default package it should be located here:
~/Library/Preferences/couchdb2-local.ini
Edit the local.ini and check if there is an [admins] section on it. Add an admin user or replace the existing password
[admins]
admin=<your-new-pass>
Restart couchdb, the pass will be hashed in the file and you can log in with the new admin user.
I'm using a Linux server from AWS and have been encountering the issue of Server refused our key and I couldn't login to the server anymore (The key and the login accounts ec2-user are correct as I've been connecting for days already).
After some investigation I found out the the issue occurs when I change the permission on the account's folder. In this case, the /home/ec2-user/, by default it has --- on group, by running the command chmod g-rwx /home/ec2-user/ to allow access for the ec2-user (I have nginx user added to ec2-user which needs the access).
Once the above is applied, if I try to connect, I always get the Server refused our key message, tried restarting the server, creating new servers, same scenario. I only managed to figure it out by keeping one PuTTY connection open, changing the permissions, trying another session, shows the error, I set the permissions back to what they were, connects successfully.
I'm very newbie still to Linux, so can someone enlighten me if possible on what might be causing this issue or whether it's something on AWS?
Note: I'm referring to connecting with the .pem file which was converted properly to the right .ppk file, I've been connected for a while and working on the server, so the credentials are not the issue.
Thanks.
Avoid change permissions to the ec2-user.
Homedir permissions require that you clear understand what you are doing before change it.
If you require a nginx user to use it own space, try to create at /opt or where it has by default /var/www.
You shot yourself in the foot.
The more specific explanation for what happened is related to the permissions on ~/.ssh/authorized_keys.
This is a list of the public ssh keys whose matching private key can be used to log in as you.
Make this file writable by anyone other than yourself, and the implications are obvious: anyone who can write to this file can add an arbitrary public key to the list, thereby allowing them to log in as you.
The secure shell daemon, sshd sees this misconfiguration, and calls foul -- if the file of authorized keys is compromised by being writable by anyone other than you, then its contents are inherently unsafe, and it therefore is ignored... and since that's the mechanism by which your key was trusted to allow you to log in... you no longer can.
This is by design, standard *nix behavior, and unrelated to AWS.
Recursively changing permissions is unwise unless you absolutely know what you're doing.
I am installing phpMyAdmin on a CentOs server and I have installed it successfully, from what I can tell. I can at least travel to the index page where it asks for my username and password. When I try to log in with any combination of default usernames and passwords, I receive this error #2003 Cannot log in to the MySQL server.
I followed this guide (http://www.krizna.com/centos/how-install-phpmyadmin-centos-6/) to help me install phpMyAdmin. From researching this, I am under the impression that after you log in with the default username:root and password:null, you will be able to change the username and password. I tried changing the config.inc.php value AllowNoPassword to TRUE, but that also didn't seem to help. How do I set a username and password so I can successfully log into phpMyAdmin?
I figured out the issue. Only some of the required software was installed on the server when I was assigned to the project. After installing mysql-server, I was able to change the root password for mysql. I changed the config file for phpmyadmin to receive the log in data through html not cookies or config. Everything works great now, I hope this helps at least one other individual.
Im trying to configure Xampp as I have done before and everything use to work.
Now, I am a bit concerned because even though I have set a password for my PhpMyadmin(exactly as I have done in the past), the system doesn't ask me to log in at anytime. What has changed?
Before I had to log in with username "root" and password and now it doesn't ask for it?
With phpMyAdmin, there are different means of authenticating ("auth_types"). These are generally set in the configuration file, config.inc.php, using a line like $cfg['Servers'][$i]['auth_type'] = 'cookie';.
Using cookie or http prompt the user for username and password when connecting; config means it's hardcoded in to the configuration file and you're automatically connected. The default in the official phpMyAdmin distribution is cookie, however it sounds like XAMPP makes it config. You should be able to change that simply by editing the config.inc.php file and changing (or adding) the line mentioned above..