I have installed postgressql 8.4-91 version in my Linux OS.
On going to the directory where its installed I am able to locate psql in the directory.
I am having 2 issues.
on typing ./psql ,it asks for a password and doesn't accept any password.
On typibf psql i am getting " command not found"
The second one is easy. Most secure Linux system don't include . (the current directory) in the path (i.e., $PATH).
This avoids the attack vector of providing an ls script in your directory that will run if someone is foolish enough to have . before the real location of ls in their path.
If you really want to be able to run it without the dot, the safest option is to set up an alias like:
alias pg='./psql'
and then use pg to run it. I would advise against putting . in your $PATH variable, at least on a shared machine. If you're the only one able to muck about on your machine, then you could probably do it safely.
The first you can probably get around by editing the pg_hba.conf file to get rid of authentication, using alter user (or add user) to set up a password then turn authentication back on.
Or you could just run without authentication in your development environment, as so many of us do :-)
Related
I want to copy the content of a shared folder to local folder.
Issue is I want to use a specific user to acsses the shared folder, meaning i want to provide username and password for the copy method to use.
When doing like so, i get an permission error because the copy uses my user.
import shutil
source = "C:\\Users\\asafs\\Documents\\Test\\test.txt"
target = "C:\\Temp"
shutil.copy(source, target)
The reason your program tries to use your user permissions is because you started it. You would have to start the process as another user.
On Linux
su -s /bin/bash -u <user> -c <command>
On Windows
runas /noprofile /user:<user> <command>
Neither require a password due to the /bin/bash and /noprofile switches, but on windows there is a way to change that without directly disabling the process at least. Neither are anything to do with python because python simply cannot do what you ask of it here, and any libraries that do it are likely to use a similar solution to what I have written here.
This is because when you start your python program you are starting python as your own user, so it can only do things you can do. You have to start it as a different user to make it do things as that user.
Hope that helps.
I have repackaged a Bash RPM to include automatic logging to syslog. I am trying to work out a way to set this up so that it is used ONLY when a user or service account runs a command as root. The option I'm looking at is installing this version of Bash to an alternate location, and then pointing root to use that version as it's default shell.
Can someone go through the process of installing this RPM to an alternate path and associating the root account to it as the default shell? I have been having difficulty finding a way to do this when searching online.
Since you are repackaging the RPM, it is probably best to change the destination path directly in the RPM.
As for the default shell, run chsh -s /path/to/your/bash root to change it.
Be aware that this solution may not work for all purposes though. For example, running a script that starts with #!/bin/bash will still execute it with /bin/bash instead of your default login shell.
I have installed Hadoop on an Ubuntu machine. I set up passphraseless ssh. I can use the command "ssh localhost" and it gives me information without needing to enter a password. However when I go to Hadoop and type "sudo bin/start-all.sh" it asks me for my password (because I used sudo which is fine), but after I enter that, it will do a couple things and then ask me for the root password which I believe it's not suppose to do. I've searched for a couple days now and I only end up with answers for when "ssh localhost" doesn't work. I haven't found anything for my problem. Any help is very much appreciated.
UPDATE:
It seems that I need sudo passphraseless ssh which is not the same as just passphraseless ssh. However, I am still unable to find out how to make this happen.
I just came back to check and realized I didn't post the solution I found. When installing Hadoop and generating keys, avoid using SUDO where ever it is not absolutely necessary. If you use SUDO, it will attempt to use the root keys which are not the same as the ones generated not using SUDO. Hadoop will automatically use the current user's keys and they won't work, so it prompts for a password.
When I stop using
**sudo** ./start-dfs.sh
And used:
./start-dfs.sh
I solved the shh communication problem with the namenode
I've got an SVN instance installed on a free EC2 AWS server. In short: I'm using LAMP.
Using what I read in this article and encountered the "you need a TTY" error as mentioned in the comments. I followed the second resource and it cleared the error message, but doesn't seem to be executing the script. When I manually run the script, however, it works.
Any clue what I'm missing?
When I followed the second resource to fix the TTY error I changed the contents of my /svn/repository/hooks/post-commit script from:
#!/bin/bash
sudo /usr/local/bin/svn-post-commit-update-mysite 1>&2
to:
#!/bin/bash
su –session-command=”/usr/local/bin/svn-post-commit-update-mysite 1>&2″ dynamic &
First possible issue:
You cannot rely on the value of the $PATH variable inside the hook. This means you need to specify complete paths for all executables.
In particular, "su" is a program located in "/bin/sh" in most distributions. To be sure, type
type su
Next possible issue:
Is your subversion server being run as root? su will try to ask for password if run by other users, and will fail if it's not being run interactively - even if the user is in the sudoers file!
If you are using Apache+DAV, this means the apache service must be run as root for this to work (instead of www-data), which is a serious security problem.
You probably don't need to use su or sudo at all if all of the files are owned by the same user (www-data, for instance). You can change the ownership of the site files with something like
sudo chown -R www-data:www-data /var/www/<my-project>
And then remove the sudo and su from both the hook and the svn-post-commit-update-mysite file.
My best guess would be that something in your script depends on the PATH environment variable. Subversion runs hooks in an empty environment for security reasons. So you need to either setup the environment in your shell script or use absolute paths.
You might want to read the Subversion book entry on implementing hook scripts. The particular issue I mentioned is explained in the information block.
I want to run a script on remote server using SSH.
I have write all the code which runs properly using system command.
To run my code on remote server I need some packages which I need to install on remote server.
To do so I need login into remote terminal as a ROOT user. When I try to do using Ruby script so I get something like following
[not_root_user#remote_server]$ su
Password:
I need some command using which I can able to login into the remote server something like following
[not_root_user#remote_server]$ su -p ******
[root#remote_server]#
Is there any linux command which accepts the password in it?
So you want your script to act as root?
It's not really recommended, but you can use expect: http://en.wikipedia.org/wiki/Expect
The wiki there has a walkthrough for a basic automated telnet session that you could adapt to your needs.
However, you're going to have your root password in plain text, which could be a security issue. If you go that route, I'd definitely obliterate all copies of that script from the universe once this package is installed.
But if you're allowing direct root logins, you've already got a bit of a security problem. Sudo works out-of-the-box on every modern linux distro I've used, I'd stick with that, if possible.
Another option which is equally tasteless would be to set up root-to-root login without a password via ssh.
Sudo would be my first option to getting around this. Although not the best option.
You can also use Key authentication with SSH, and if password authentication is turned off there is no need to enter a password.