It's strange, but i've searched around for this source of configuration but couldnt find it out.
Im currently using opensuse 11.3 with postgresql 9.
Every postgresql command line that i issue will ask the current user password, like psql, createdb, dropdb, and i have to enter the password of the current user (which is postgres) to make it work.
Doing dropdb xxx && createdb xxx will ask the password twice.
Please show me the light !
Thank you :-)
EDIT
Actually im already running as a postgres user (a user in my linux), so i can psql without supplying the database password, but i still have to supply the password for the system user postgres.
So if the database has a user of dbuser, and im running psql as the postgres (linux user), a password for the linux user (postgres) will be asked, not the dbuser password.
You can create a ~/.pgpass file (%APPDATA%\postgresql\pgpass.conf on Windows) with a line in the following format:
hostname:port:database:username:password
See the documentation for details.
If you're on opensuse you should be able to create a .pgpass file by running:
echo "hostname:port:database:username:password" > ~/.pgpass
chmod 0600 ~/.pgpass
With all of the correct information of course.
if you have a .pgpass file setup to allow a certain user access to a certain database (let's call it "myprojectdb"), recall that creatdb and dropdb aren't really acting on "myprojectdb" despite the fact that you may be asking them to create and drop that db.
You'll most likely want to add postgres' internal tables to your pgpass permissions (postgres / templates). Also don't forget to add the --no-password option on both createdb and dropdb to ignore interactive prompts (note this will only work if the user specified with the -U option can modify the internal postgres tables)
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
How can I reset the admin password in Datastax Opscenter? Will disabling and reenabling authentication in /etc/opscenter/opscenterd.conf do the trick? Will I lose any other data in the process?
I'm not aware of an official way to simply reset the admin password in OpsCenter. However, I do know of a "hacky" way to do it, if you're up for that (and if you have physical or ssh access to the server).
OpsCenter's user authentication is maintained in a SQLite database file named passwd.db, located in the root of your OpsCenter directory. The file is created once you enable user authentication in OpsCenter. Using sqlite3, you can open and manage this file:
$ sqlite3 passwd.db
SQLite version 3.8.5 2014-08-15 22:37:57
Enter ".help" for usage hints.
sqlite> PRAGMA table_info(users);
0|id|INTEGER|0||1
1|username|TEXT|0||0
2|password|TEXT|0||0
3|groupid|INTEGER|0||0
sqlite> SELECT * FROM users;
1|admin|8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918|1
Looking above, you can see the row for the "admin" user of a brand new install of OpsCenter 5.2.1 is the hash of:
8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918
If you update the password field on the users table to that value, it should reset it back to the original:
UPDATE users
SET password='8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918'
WHERE username='admin';
I don't know if the passwords on different versions of OpsCenter use the same hash or not, but this should work if you're using OpsCenter 5.2.1. Otherwise, if you have a user in there that you do know the password to, you can (look up and) set the admin password to that hash, and then at least you'll know the password and be able to log in.
Turns out this was fairly simple. All I needed to do was stop OpsCenter, rename (or remove) passwd.db, and restart OpsCenter again. The daemon automatically creates a new password db file and sets the admin password to 'admin'.
I'm trying to edit some files on a remote server with Vim. I've managed this on other servers without trouble in the past, but in this case when I type:
$ vim ftp://username#xxxxxx.com/
I'm prompted for a password, I type it in and I see this:
Name (notixvalet.com:george): User cannot log in.
Please login with USER and PASS.
Please login with USER and PASS.
Please login with USER and PASS.
ftp: Login failed
'george' is my username on my local machine (Mac OS X 10.8.) Vim seems to be ignoring the username I give it and trying to log on as 'george', no matter what I do. To test this I created a new account on my MacBook with the same username as the username on the server I'm trying to log in as, then from that account I can log in fine. This is obviously a VERY hacky solution - how can I connect using the right username from my regular account?
(Incidentally, the username and password I'm using are 100% definitely right - I can use them to connect to the server through an FTP client such as FileZilla.)
The plugin you are using to edit the remote files is netrw, as noted by Ingo in the comments. You can read the plugin help file through :h netrw. In special:
NETRC *netrw-netrc*
The <.netrc> file, typically located in your home directory, contains lines
therein which map a hostname (machine name) to the user id and password you
prefer to use with it.
The typical syntax for lines in a <.netrc> file is given as shown below.
Ftp under Unix usually supports <.netrc>; ftp under Windows usually doesn't.
>
machine {full machine name} login {user-id} password "{password}"
default login {user-id} password "{password}"
Your ftp client must handle the use of <.netrc> on its own, but if the
<.netrc> file exists, an ftp transfer will not ask for the user-id or
password.
Note:
Since this file contains passwords, make very sure nobody else can
read this file! Most programs will refuse to use a .netrc that is
readable for others. Don't forget that the system administrator can
still read the file! Ie. for Linux/Unix: chmod 600 .netrc
Is there any chance that you forgot to copy the ~/.netrc file from the other servers where you can connect without problems? Or it has incorrect permissions, as mentioned on the last paragraph?
I'm use an Debian based OS here on my work an i've configured the service for test routines of ERP app...
This service (Tomcat+Java service) it's consumed via HTTP on intranet correctly...but the test leader sometimes need chance the database used by service application and uses SSH to access my machine to change database on config file and restart the service...eventually this person change some service or O.S. config throwing problems to me (on my O.S and others things..).
What i want know is if can i change my password only for SSH service (doesn't change to my KDE/Gnome session), just because the company's policy requires everyone to have a default password on stations...
Remebering that i'm a manager of config, maintenance and others jobs of service to test team...and change database solicitations can made to me.
A simple example:
KDE login if user 'carlos' and password '123456'
SSH login if user 'carlos' and password '4nyJokeHere'
That it's possible ?
Thanks in advance.
Possible? Maybe. You'd probably have to fiddle with pam.d to get SSH authenticating via a different mechanism to KDE etc.
Coming from a different angle, I may be missing something, can you not create a second user for the SSH process, keeping your main user for KDE etc cleanly separate?
I'd really strongly recommend trying to "split" a user into multiple purposes/security groups with differing passwords for each!
You can use authorized_keys to restrict the SSH commands available, and/or sudo...
Update: Some expansion on the subject as requested by the OP
You can limit commands available via SSH by using ~/.ssh/authorised_keys file - see O'Reilly for a good explanation.
I'm was solved this case applying a single rule here. On SSH service i'm was locked access of my user 'carlos --> sudoers' and enable access only for a user called 'padrao' (padrao translated to english is 'default').
This user 'padrao' doesn't have sudoers permissions. If i needed access with SSH my machine i'm do:
ssh padrao#my.intranet.machine
password: ***
$ su carlos
password: ***
This is not the best way to solve, but solved my problem here.
Thanks.
I've a debian system, when a user try to login, a pam module exec a bash script as root.
I need this script to know who is trying to login.
But the user isn't already connected so basic command as users/w/who ... doesn't work here.
So is there a possibility to retrieve the username of a user trying to get logged ?
Thank you.
Cyrbil
You can also use /etc/profile or /etc/bashrc to grab the user logging in, I typically have a small script that gets executed via /etc/bashrc that gives me details about the user (who it is, connecting from what IP address etc).