I have backed up the data from my deployed database successfully using the following commands:
mongodump admin -u user -p password
Is there a shell script to do this automatically with the password hidden(to protect the password even someone get the script)?
You can use crontab to create scheduled task on the server that will run this command for you. in that way only those who have access to the server can get your password.
Here is a link how to do it https://sheharyar.me/blog/regular-mongo-backups-using-cron/
You should implement the solution by Ariel with a read-only user. This limits the damage when someone still manages to obtain the script. It would also be good practice to store the password encrypted and let the scrip that runs the backup decrypt it.
Related
I'm looking for a way to back up a database through a LAN on a mounted drive on a workstation. Basically a Bash script on the workstation or the server to dump a single database into a path on that volume. The volume isn't mounted normally, so I'm not clear as to which box to put the script on, given username/password and mounted volume permissions/availability.
The problem I currently have is permissions on the workstation:
myfile='/volumes/Dragonfly/PG_backups/serverbox_PG_mydomain5myusername_'`date +%Y_%m_%d_%H_%M`'.sql'
pg_dump -h serverbox.local -U adminuser -w dbname > $myfile
Is there a syntax that I can provide for this? Read the docs and there is no provision for a password, which is kind of expected. I also don't want to echo the password and keep it in a shell script. Or is there another way of doing this using rsync after the backups are done locally? Cheers
First, note the pg_dump command you are using includes the -w option, which means pg_dump will not issue a password prompt. This is indeed what you want for unattended backups (i.e. performed by a script). But you just need to make sure you have authentication set up properly. The options here are basically:
Set up a ~/.pgpass file on the host the dump is running from. Based on what you have written, you should keep this file in the home directory of the server this backup job runs on, not stored somewhere on the mounted volume. Based on the info in your example, the line in this file should look like:
serverbox.local:5432:database:adminuser:password
Remember to specify the database name that you are backing up! This was not specified in your example pg_dump command.
Fool with your Postgres server's pg_hba.conf file so that connections from your backup machine as your backup user don't require a password, but use something like trust or ident authentication. Be careful here of course, if you don't fully trust the host your backups are running on (e.g. it's a shared machine), this isn't a good idea.
Set environment variables on the server such as PGPASSWORD that are visible to your backup script. Using a ~/.pgpass file is generally recommended instead for security reasons.
Or is there another way of doing this using rsync after the backups are done locally?
Not sure what you are asking here -- you of course have to specify credentials for pg_dump before the backup can take place, not afterwards. And pg_dump is just one of many backup options, there are other methods that would work if you have SSH/rsync access to the Postgres server, such as file-system level backups. These kinds of backups (aka "physical" level) are complementary to pg_dump ("logical" level), you could use either or both methods depending on your level of paranoia and sophistication.
Got it to work with ~/.pgpass, pg_hba.conf on the server, and a script that included the TERM environment variable (xterm), and a path to pg_dump.
There is no login for the crontab, even as the current admin user. So it's running a bit blind.
I am trying to install postgresql on a server using a bat file. I am using initdb.exe with --pwfile option so that it picks up the password form a text file and continues...
for some reason, even with --pwfile option, it is still prompting me for a password.. Not sure what the problem is.. This is the script I am using:
set DBPATH = something
set DBADMIN = something
set DBDATA = something
RunAs /noprofile /user:%computername%\postgres ""%DBPATH%\initdb.exe" --locale=C --encoding=UTF-8 -U %DBADMIN% --pwfile="D:\Pass.txt" -D "%DBDATA%""
Thanks
If you want to install a software which requires for the installation administrator privileges and the current user account does not have the required privileges, it is possible to use command RunAs to run the installation executable and all processes started by this application with a different user account than the current user account which has the required privileges.
But the user has to enter nevertheless a password - the password for the other user account with the extended privileges to install applications. If it would be possible to run something requiring extended privileges for installing software without requesting entering the password by the user, every bad guy out in the world could very easily install trojaners and other malware (as it is possible on Windows 2000 / XP or since Windows Vista with user account control disabled).
There are systems to deploy and install software on all clients of a company like Group Policy or System Center Configuration Manager.
I'm trying to run the heroku pg:pull command, but I can't seem to get the amazingly cryptic authentication process.
The command I'm running:
> heroku pg:pull app_name::RED localdb
I then get a password prompt, which I can't, for the life of me, figure out. After 2 guesses I get password authentication failed for user "Hanan", and that's it.
I tried Heroku's password, my Windows account password, every password I use, but nothing happens. I checked, and "Hanan" is not a role in Postgresql, so trying to change the password through psql doesn't work. I have no problem logging in to Postgresql through other roles, but it's this 'default' log-in process which I can't seem to crack.
Also, since I'm using windows, I'm not sure how to run commands like sudo -u postgres psql, which I see as a possible solution.
Will appreciate any help regarding this issue, I'm really frustrated by now...
Apparently it's possible to set the environment variables PGUSER and PGPASSWORD, as described here.
However, this won't work on windows in the given syntax. To do this on windows run the following:
SET PGUSER=[pg_username]
SET PGPASSWORD=[pg_password]
after entering these two lines Postgres will log you in with the given authentication info, instead of trying to sign in with the windows username
I've run into this problem a lot when running heroku pg:pull. The issue in my case was that the pg:pull command only works if my local PostgreSQL server has a password set.
To set a password, run psql localdb and execute this SQL:
ALTER USER my_user_name with password 'my_new_password';
(You won't necessarily be required to use this password all the time. Run psql localdb and see whether you're prompted; in my case, I can still log in to psql without the password.)
Now run heroku pg:pull --app my_heroku_app POSTGRESQL_COLOR localdb, and enter your new password (twice) when prompted.
I'm using Windows 10, 64-bit, Powershell and had to use the following commands to properly set the local PostgreSQL environment variables:
C:\> $Env:PGUSER="[pg_username]"
C:\> $Env:PGPASSWORD="[pg_password]"
To verify that these are set properly, list all local environment variables with this:
C:\> Get-ChildItem Env:
After doing this, I was able to run heroku pg:pull without being prompted for a password.
The previous answers did not work for me or were not to my liking so I kept searching. Thanks to the answer provided by Rayz on this post How to add a user to PostgreSQL in Windows? I was able to come up with this one liner for windows powershell.
& { $env:PGUSER="username";$env:PGPASSWORD="password"; heroku pg:push local-db DATABASE_URL --app heroku-app}
You apparently have to pass the variables as a list seperated by semicolons, surrounded by braces which are preceeded by an ampersand. Your funtion (heroku pg:pull/ pg:push/...) has to be a member of the list. As of my current testing it works in powershell with pg:push and the order of items within the braces does not matter.
I was too lazy to find out how to change credentials used by heroku. SET PGUSER and SET PASSWORD did not work for me, what i did was this:
Error said invalid credentials for "janbr" so i have created the user in the local db with a lot of priviledges. I used DBeaver for that with postgres credentials i have set up upon instalation of postgres.
Not a very clean solution though.
Using Windows 10, I tried all of the solutions here without any luck.
What ended up working for me was going into System Properties and editing my Environment Variables there. I added these to my System Variables, restarted my terminal and was able to run after that. One thing to note is that I first tried to add user and password to my User Variables but that didn't work.
PGUSER YourPostgresUser
PGPASSWORD YourPassword
I also ran Get-ChildItem Env: after updating my variables to check that they had been added.
I did not find any reference to user related commands for the jenkins-cli tool.
I need this to automate deployment.
Any comeback?
To use jenkins internal database simply use the following command.
echo 'jenkins.model.Jenkins.instance.securityRealm.createAccount("user1", "password123")' | \
java -jar jenkins-cli.jar -s http://localhost:8080/ groovy =
This will create user=user1 with password=password123
If you have any existing user and have restricted anonymous access to your jenkins, you can specify the username and password with
--username "user_name" and --password "password"
Maybe you don't want to use Jenkins' internal user database at all. There are a host of "Authentication and User Management" plugins.
If you like MySQL, there is a MySQL authenticator (it reads a table of users and passwords), and your "adduser" command could do an insert on that table.
If you like flat files, there is a "Script Security Realm", where you can authenticate with an arbitrary script. Write a file with user and password combos in your favorite format, write an "adduser" script that writes to it, and write an auth script that reads the file and determines whether to authenticate the user.
You can also hook up to an LDAP server, Active Directory, Atlassian Crowd, Unix user accounts (pw_auth), or whatever authentication your application server uses (if it's running off of a Tomcat server, for instance, you can tell Jenkins to let Tomcat authenticate users, and set up Tomcat to do it however you want.
If you specify in more detail what you are trying to do people here may help you better. That said, here are some pointers:
All CLI commands are available via http://[jenkins-server]/cli. What's not found there is not available via CLI. You can specify user name / password via --username and --password (or --password-file) options in CLI commands.
Another option for Jenkins automation is to use Python JenkinsAPI.
You can also use tools like wget and curl to perform certain actions (such as starting a build). There you may use user-specific tokens instead of username/password.
Here's another link that can be helpful.
I stopped my db using db2stop force. The started did a backup restarted and after that
i cannot connect to db from the a client anymore i get:
using the command
db2 connect to "dbname" using "user"
SQL30082N Security processing failed
with reason "42" ("ROOT CAPABILITY
REQUIRED"). SQLSTATE=08001
password and username are correct. When im on the server connecting using command
db2 connect to "dbname"
or
db2 connect to "dbnmae" user "user"
or
db2 connect to "dbname" user db2inst1
works just fine.
I m really confused. Any help is much appreciated
Thanks.
What i tried so far :
db2 get dbm cfg | grep -i auth GSS
Plugin for Local Authorization
(LOCAL_GSSPLUGIN) = Server
Connection Authentication
(SRVCON_AUTH) = NOT_SPECIFIED
Database manager authentication
(AUTHENTICATION) = SERVER Cataloging
allowed without authority
(CATALOG_NOAUTH) = NO Trusted client
authentication
(TRUST_CLNTAUTH) = CLIENT Bypass
federated authentication
(FED_NOAUTH) = NO
switched to client but did not using
db2 update dbm cfg using
authentication client
Update:
Despite the age of this question, it would be wonderful to have a solid answer to this question. Hi locojay, how did you manage? :-)
I'm having the SQL30082N reason code 24 issue in my Windows PC, and today we experienced the same issue in an AIX server.
I googled for a couple hours and didn't find but one happy answer, related to having users with the same name both in the server and the client.
IMO it does not apply to me, as I'm running into a VBox that´s isolated from the domain (no network).
My case: I installed DB2 as user db2admin, no security. Then I granted DBADM to VIRTUALUSR01 and gave this user a password.
db2 connect to TheBase
works fine. But
db2 connect to TheBase user VIRTUALUSR01 using TheRightPassword
returns SQL30082N with reason code 24.
Using client authentication is generally a Bad Idea(TM). That's because you now rely on machines that you may not control for authentication. If I wanted to subvert your system, I could create a new user locally, say, db2inst1 or VIRTUALUSR01 or Administrator, with a password I know, and then, use that to wreak havoc on the database. If, however, no one in your organisation has root/administrator authority over their own machines, client authentication can be made to work. But all it takes is someone plugging in their own personal laptop, and your database could be at risk.
Instead, check the permissions of the files. If you've installed as root, ~db2inst1/sqllib/security/db2c[hk]pw (assuming instance ID of db2inst1) should be setuid root. If not, run db2iupdt against your instance (./db2iupdt db2inst1) which should fix the permissions.
If you've installed without root authority ("non-root install"), which I doubt, since you seem to have had this working, you would need to read the DB2 documentation on non-root installations and their limitations - I don't use non-root installs myself, so I'm not so familiar with them. However, there should be a set-root script that you can use to enable setuid root which, of course, you have to run as root.
I had the same problem and solved with the following way.
Problem occurs because of /etc/shadow file. If the user's password hash is created with SHA then DB2 cannot authenticate or authorize that user. You need MD5 for hashing that user's password.
If you are using Fedora or RedHat Linux, first change hashing method of passwords with:
# authconfig –-passalgo md5 –-update
Then drop and recreate the user:
# userdel userName
# useradd userName
# passwd userName
If you are using AIX or any other linux distros, authconfig won't work. So instead of passwd userName, issue this command:
# usermod --password `openssl passwd desiredPassword`
After that, your password hash belonging to userName will be generated with MD5.
Now grant user privilege to that user:
# su - db2inst1
(db2inst1)$ db2 connect to databaseName
(db2inst1)$ db2 GRANT DBADM with dataaccess with accessctrl on database to user userName
I hope it works for you too.
Thanks to Honza for his solution
Solutions to specific problem causes described previously in
this message are:
1. Run DB2IUPDT <InstName> to update the instance.
2. Ensure that the username created is valid. Review the DB2
General Naming Rules.
3. Ensure that catalog information is correct.