I am trying to shutdown my redis-server from a redis-cli. Whenever I issue a command from a client I receive the error "(error) NOAUTH Authentication required." I have tried the commands "SHUTDOWN" and "SHUTDOWN NOSAVE".
I have also tried "redis-server stop" from another terminal window but received the error "# Fatal error, can't open config file 'stop'"
How can I shut down this server?
(I am on OSX).
Your Redis server is configured with a password apparently. Therefore, when using redis-cli, you'll need to issue the AUTH password command before any other command or else you'll be getting that error message (replace password with your server's password).
Alternatively, you can invoke redis-cli with the -a switch followed by your password for the same result.
To find the password of your server, open the Redis configuration file (by default /etc/redis/6379.conf) and look for the line starting with requirepass - whatever value is next to it, is the password.
1. redis-cli
2. auth yourpassword
3. shutdown
4. sudo service redis_6379 start
You have to manually edit the start/stop-service script:
sudo vi /etc/init.d/redis_6379
Find the following line:
$CLIEXEC -p $REDISPORT shutdown
And replace it with the following 'changeit' is where your password goes:
$CLIEXEC -p $REDISPORT -a changeit shutdown
Now you should be able to start and stop the service without any problems.
On Amazon EC2 instance I could restart local Redis like this:
sudo /etc/init.d/redis restart
P.S. If you are using Redis Authentication you have to pass -a <pass> parameter.
Related
I have a redis database on a remote docker host, and I'd like to access it through a single ssh script command via plink.
The script is simple (redis-script.sh):
#!/bin/bash
echo "Enter Redis Password."
read -s pass
docker exec -it my-redis-container redis-cli -a $pass
Which works fine when I do a standard ssh connection via putty then run the script after login. I am able to enter the password and connect to the db:
Enter Redis Password.
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379>
The problem is when I use plink, my plink command line:
plink.exe -t container-host /containers/redis-script.sh
I get this:
Enter Redis Password.
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
[6n
One issue is the mangled characters, but the biggest issue is that I can no longer type in any commands at this point. I am able to interact when it asks for the password, but once it gets into redis-cli, I cannot type anything.
Perhaps it's the docker exec command which is messing up the interactivity?
Any help is appreciated.
I have created a PowerShell script for changing password for Windows services.
Using sc.exe in code for the same.
When I execute the script it changed password in few servers but failed for others.
Next, I executed the command directly on the servers to check. The command is not returning anything.
On servers where it was successful, it will return a success message or some error if the password in not changed or if command not proper.
Also, same command is used with same values in all servers. Following is the command:
sc.exe config "$Service" obj= "$UserName" password= "$Password"
I am on a server and running a script file that has following code.
ssh username#servername
sudo su - root
cd /abc/xyz
mkdir asdfg
I am able to ssh... but then the next command is not working.. the script is not sudo-ing. any idea?
Edit: Able to create a mech id and then do the things.. though still looking for the answer to above question :|
First of all your command will "stuck" on the first line because it will go into an interactive mode. The ssh command will require a password to be provided by a user (unless there is an sshkey being used) . And if the ssh is logged into the remote server then it will wait for user commands from standard input.
Secondly the lines following the ssh command will be executed only when the first process has exited. This is why your script is not "sudoing" - it's waiting for the ssh to end.
So if your point is to run a command on a remote server then put the command as a parameter into the same line as ssh connection. In your case:
ssh user#server sudo su - root
But this will not be of satisfaction for you. I suggest you create a script of what you want to execute on the remote server and then execute the script.
ssh user#server scriptName
The sudo thing here is very tricky because again your script might get stuck in the interactive mode waiting for a password to be inserted so I suggest you think again on the basis of the script.
mb47!
You want to run the script on the remote computer, correct?
On the remote machine, create a file containing the commands you would like to execute.
Then, on the other machine, run ssh user#machine /path/to/script/you/created/earlier
I hope this helps!
ALinuxLover
Shrewsoft [1] provides a command line interface for setting up the vpn tunnel automatically without any user intervention, such as by using the following command
ikec -u username -p password -r configuration -a
IS there any way to detect if the connect attempt was successful such as by reading live logs and how can we terminate the vpn tunnel after some time using the command line. Any help will be appreciable.
By looking at the terminal output from ikec -u username -p password -r configuration -a, you can tell if the connection was successful; if the output has a line ii : tunnel enabled, that means the connection was successful and should work. If you get a message such as >> : detached from key daemon or failed to connect to key daemon, it means there was a problem with the connection (https://askubuntu.com/a/793336/705434 suggests running sudo /usr/sbin/iked for a solution to this particular error). To exit the ikec command, just type q into the terminal.
EDIT: it looks like this page (https://gist.github.com/fschabmeyer/22b759994cf852df7e9b) has a shell script that can handle the detection, you should be able to add a case to exit the command automatically after a certain amount of time.
I am getting a error while accessing the firefox using X11Forwarding.
[root#station2 ~]# firefox
KiTTY X11 proxy: wrong authorisation protocol attemptedKiTTY X11 proxy: wrong authorisation protocol attemptedError: cannot open display: localhost:10.0
setup the following values: /etc/ssh/sshd_config
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
** Installed the package**
#yum install xorg-x11-xauth
#yum -y install xauth
[root#station2 .ssh]# echo $DISPLAY
localhost:10.0
#mkxauth -c
adding key for station2.example.com to /root/.Xauthority ... done
export XAUTHORITY=$HOME/.Xauthority
This fix worked for me
There is a hard, if not even impossible, to find (by search engine) scenario that may may cause that error message.
Preliminary note: The topic of this answer is not to discuss if it is a safety
risc or recommondable at all to use a graphical desktop as root on an remote, display-less, webserver.
Scenario:
A remote internet connected Linux server S has assigned the domain
name example.com to it's public IP4-address 192.0.2.1.
The /etc/hostname file on S contains the single line example.
The /etc/hosts
file on S contains the line 127.0.0.1 localhost example.com example.
The (remote) ssh access to S is by (sshd-) configuration (on S) forbidden
for root by the line DenyUsers root in /etc/ssh/sshd_config, but
allowed for a dummy user user1. From a client computer C a ssh
connection, using the ssh parameter -X or -Y, is established to S
as user user1.
Then, in a remote terminal on S owned by user1,
if any X11 related command is tried to be executed as root, may it be by
su, then trying to start the X11 desktop environment
or, as in the concrete case executing a script containing
#!/bin/bash
su --preserve-environment -c "xfce4-session &" root
the error message
X11 connection rejected because of wrong authentication.
is output and the start of any X11 related program fails.
The DISPLAY variable of root's environment contains
example.com:10.0
then.
One solution to the problem is, in this special case, to modify the line
127.0.0.1 localhost example.com example
in /etc/hosts to
127.0.0.1 localhost
Solution: run the application with the same user you are SSHing.
I have also encounter such errors while using X11.
The source of my problem was that i used SSH with my own username (which was not root).
Then, once logged in i tired running stuff with X11 while doing "su" or doing "sudo",
the problem with that is that the SSH session is configured with your own username - e.g: Raj, but then you switch to user root which is not part of the X11 session.
So what you should do is simply try to run the application (firefox in your case) with the same user you started the X11 session.
Hope this helps.
Talel.
I ran into this running gvim over ssh -t -Y and the solution that worked for me was:
xauth add $(xauth -f ~<logon_user>/.Xauthority list | tail -1) ; export NO_AT_BRIDGE=1 # gvim X11 fix for remote GUI failure after su
I do not know where I stumbled on this answer so I cannot give credit to the author.