I'm trying to change the user that starts my redis instance? Currently is root.
root 16705 0.0 0.0 133312 1960 ? ssl 11:00 0:02 redis-server
It is definitely not the best thing.
Any help is appreciated!
Thanks.
Related
Installed a redis in ubuntu 16.4 in digitalocean.
I've changed the default redis server 127.0.0.1:6379 into my own ip in digitalocean 178.xxx.xxx.xxx:6379 by editing editing vim /etc/redis/redis.conf
After that I tried redis-cli and redis-cli shutdown all responded this:
Could not connect to Redis at 127.0.0.1:6379: Connection refused
But if ps aux|grep redis
I get:
redis 11734 0.0 0.1 41852 3892 ? Ssl 15:45 0:11 /usr/local/bin/redis-server 178.xxx.xxx.xxx:6379
root 12735 0.0 0.0 12944 948 pts/0 S+ 19:11 0:00 grep --color=auto redis
Is this normal?Or what should I do?
What you should do depends on how you want it to work...
If you want to be able to connect to Redis via any network interface, comment out all the bind directives in your config file by putting a # at the start of the line beginning bind.
If you want to only be able to connect by specifying 178.xxx.xxx.xxx, then put the following in your config file:
bind 178.xxx.xxx.xxx
If you want to use 127.0.0.1 or 178.xxx.xxx.xxx, then put:
bind 178.xxx.xxx.xxx 127.0.0.1
I'm guessing you want this option, but see security note below.
In general though, it is not advisable from a security point of view, to expose your Redis server to the whole Internet - and all the options above do exactly that. You probably want to bind to 127.0.0.1 and set up an ssh tunnel from your 178.xxx.xxx.xxx public address to 127.0.0.1.
Whatever you put in there, restart Redis to make changes take effect.
I use brew to install httpd, I stopped the service using brew services stop httpd then I visit locahost, I still can see apache is running?
You need to give following command: service httpd stop
You must kill the processes. As I can see from your comment you are running httpd as the users www and root:
_www 3356 0.0 0.0 2455088 704 ?? S 9:25AM 0:00.00 /usr/sbin/httpd -D FOREGROUND
root 3355 0.0 0.0 2455344 3588 ?? Ss 9:25AM 0:00.14 /usr/sbin/httpd -D FOREGROUND
private.laptop 3967 0.0 0.0 2444068 816 s004 S+ 9:46AM 0:00.00 grep httpd
The first column represent the user and the second column the process ID or PID.
Try running:
sudo kill -9 3356
sudo kill -9 3355
After each execution verify the services dissapear using ps aux | grep httpd
The last proccess private.laptop isn't related to your problem so no need to kill it.
If your problem isn't solved by this, maybe a daemon is executing your httpd, please refeer to this.
Our EC2 instance has been experiencing very slow connection lately.
After we investigate deeper, we found out that there are few hundred ssh processes running, and they are all trying to connect to the same host (i.e it's almost like ddos attack against that host).
ps aux | grep ssh
root 971 0.0 0.0 61364 3084 ? Ss Dec11 0:00 /usr/sbin/sshd -D
root 7649 0.0 0.0 105628 4228 ? Ss 03:57 0:00 sshd: ubuntu [priv]
ubuntu 7811 0.0 0.0 106404 2740 ? S 03:57 0:00 sshd: ubuntu#pts/0
ubuntu 8616 0.0 0.0 44012 2516 pts/2 S 04:02 0:00 ssh deploy#xxx.xxx.xxx.xxx
ubuntu 8618 0.0 0.0 44012 2512 pts/2 S 04:02 0:00 ssh deploy#xxx.xxx.xxx.xxx
ubuntu 8620 0.0 0.0 44012 2512 pts/2 S 04:02 0:00 ssh deploy#xxx.xxx.xxx.xxx
ubuntu 8622 0.0 0.0 44012 2512 pts/2 S 04:02 0:00 ssh deploy#xxx.xxx.xxx.xxx
ubuntu 8624 0.0 0.0 44012 2516 pts/2 S 04:02 0:00 ssh deploy#xxx.xxx.xxx.xxx
...
Here I logged in as ubuntu. I vaguely remember I executed the command a while ago trying to connect to the host, but ssh outputs many instances of itself and the terminal got frozen, and since then we have been experiencing the slow connection issue.
Anyhow, I tried to kill all of the ssh processes, but they just keep coming back and eventually slow down the whole system connection again.
$ killall -9 ssh
Any idea what went wrong and how can I solve this problem?
Last week I was using RPC and could run my RPC server program just fine. However, today I tried to start it again and I am getting this error:
Cannot register service: RPC: Authentication error; why = Client
credential too weak unable to register (X_PROG, X_VERS, udp)
Can anybody tell me what the cause of this error can be?
rpcinfo gives me this:
program version netid address service owner
100000 4 tcp6 ::.0.111 portmapper superuser
100000 3 tcp6 ::.0.111 portmapper superuser
100000 4 udp6 ::.0.111 portmapper superuser
100000 3 udp6 ::.0.111 portmapper superuser
100000 4 tcp 0.0.0.0.0.111 portmapper superuser
100000 3 tcp 0.0.0.0.0.111 portmapper superuser
100000 2 tcp 0.0.0.0.0.111 portmapper superuser
100000 4 udp 0.0.0.0.0.111 portmapper superuser
100000 3 udp 0.0.0.0.0.111 portmapper superuser
100000 2 udp 0.0.0.0.0.111 portmapper superuser
100000 4 local /run/rpcbind.sock portmapper superuser
100000 3 local /run/rpcbind.sock portmapper superuser
The weird thing is that I haven't even been using this pc the past week.
Are there any services that should be running?
Hope you can help me out.
Grtz Stefan
this error is linked to rpcbind,so you should stop service portmap like this:
sudo -i service portmap stop
then
sudo -i rpcbind -i -w
at end start service portmap:
sudo -i service portmap start
I realize this is an older thread, but Google finds it among the top 3 results and people are still discovering the nfs service error. Even Red Hat's RHN's fix didn't work.
As of December 2013 on a RHEL 6.4 (x64), and patched as of November 2013, the only solution was changing the permissions on the tcp_wrapper config files. Because we had secured the box pretty heavily, we had permissions of 640 on /etc/hosts.allow and /etc/hosts.deny, both owned by root:root. We did try given these files different group ownership nothing corrected the issue when nfs started.
Once we put the perms back to "out-of-the-box" (644) the nfs (rquotad) service started up as expected. Or if we moved the hosts.allow/deny out of the way entirely.
What a pain that was to figure out. The selinux logs may have helped if I had looked sooner.
Now if we had left selinux in enforcing mode this MAY have not been an issue. I still have to test that theory.
Good luck.
Making the change persistent on Ubuntu12.04
(assuming security implications of running rpcbind with -i are irrelevant):
echo 'OPTIONS="-w -i"' | sudo tee /etc/default/rpcbind
sudo service portmap restart
Yet Another Solution: CentOS 7.3 edition
In addition to rpcbind, I also had to allow mountd in /etc/hosts.allow:
rpcbind : ALL : allow
mountd : ALL : allow
This finally allowed me to not only execute rpcinfo, but showmount and mount as well.
None of the solutions presented here so far worked for me on the Debian Squeeze to Wheezy upgrade.
In my case the sole thing I had to do was to replace all occurrences of "portmapper" (or "portmap", no more sure) in /etc/hosts.allow with "rpcbind". That was all. (Otherwise ypbind couldn't connect to rpcbind via localhost.)
This also happens if iptables is used and it is blocking UDP connections for localhost. Ran into this today. Stopped iptables, connections started working.
You will need to figure out the rules that broke it.
I think that it is worth mentioning that if you see errors like:
0-rpc-service: Could not register with portmap
it can be related to hosts.allow and hosts.deny files set and lacking permissions for localhost in the hosts.allow file.
I had this kind of problem with setting NFS with GlusterFS.
In my /etc/hosts.allow file I have added:
ALL: 127.0.0.1 : ALLOW
and problem with registering service with portmap went away and everything is working.
Note: with GlusterFS remember to restart the glusterd service
/etc/init.d/glusterd restart
I was receiving an error like so on rhel7:
ypserv: Cannot register service: RPC: Authentication error; why = Client credential too weak
when starting ypbind. I tried everything including the '-i' to rpcbind above. In the end as XTaran mentioned modifying /etc/hosts. allow adding this line:
rpcbind: 127.0.0.1
worked for me.
FWIW, here's an 'alternative' solution.
Check the /etc/hosts.deny file. It should say something like:
rpcbind mountd nfsd statd lockd rquotad : ALL
Ensure that there is a blank last line in this file.
Check the /etc/hosts.allow file. It should say something like:
rpcbind mountd nfsd statd lockd rquotad: 127.0.0.1 192.168.1.100
Ensure that there is a blank last line in this file.
The "trick" (for me) was the blank final line in the file(s).
I have the same symptoms as Error number 13 - Remote access svn with dav_svn failing. However, the solution to that problem does not work for me.
The error message:
<D:error xmlns:D="DAV:" xmlns:m="http://apache.org/dav/xmlns" xmlns:C="svn:">
<C:error/>
<m:human-readable errcode="13">Could not open the requested SVN filesystem</m:human-readable>
</D:error>
The relevant apache log entry:
(20014)Internal error: Can't open file '/svn/testrepo/format': Permission denied
The subversion conf file:
<Location /svn>
DAV svn
SVNPath /svn/testrepo
</Location>
However, I've further confirmed that user apache can, indeed, open the file /svn/testrepo/format, and can not only open it, but move it, duplicate it, delete it, and overwrite it. (su apache -> do all that stuff.) What can I do next?
=========== FURTHER INFORMATION ===========
In response to crazyjul, here are the results of ps aux | grep apache
apache 14019 0.0 0.2 11248 2112 ? S 16:40 0:00 /usr/sbin/httpd
apache 14020 0.0 0.2 11248 2112 ? S 16:40 0:00 /usr/sbin/httpd
apache 14021 0.0 0.2 11248 2112 ? S 16:40 0:00 /usr/sbin/httpd
apache 14022 0.0 0.2 11248 2112 ? S 16:40 0:00 /usr/sbin/httpd
apache 14023 0.0 0.2 11248 2112 ? S 16:40 0:00 /usr/sbin/httpd
apache 14024 0.0 0.2 11248 2112 ? S 16:40 0:00 /usr/sbin/httpd
apache 14025 0.0 0.2 11248 2112 ? S 16:40 0:00 /usr/sbin/httpd
apache 14026 0.0 0.2 11248 2112 ? S 16:40 0:00 /usr/sbin/httpd
root 14032 0.0 0.0 5412 772 pts/4 R+ 16:41 0:00 grep apache
The results of ps aux | grep www
root 14034 0.0 0.0 5412 772 pts/4 S+ 16:42 0:00 grep www
The results of ls -as on my repo folder:
drwxrwxrwx 7 apache apache 4096 2011-10-07 16:13 .
drwxr-xr-x 7 apache apache 4096 2011-10-07 14:04 ..
-rw-r--r-- 1 apache apache 229 2011-10-07 13:50 README.txt
drwxr-xr-x 2 apache apache 4096 2011-10-07 15:50 conf
drwxr-xr-x 2 apache apache 4096 2011-10-07 13:50 dav
drwxr-sr-x 5 apache apache 4096 2011-10-07 14:25 db
-rwxrwxrwx 1 apache apache 2 2011-10-07 13:50 format
drwxr-xr-x 2 apache apache 4096 2011-10-07 13:50 hooks
drwxr-xr-x 2 apache apache 4096 2011-10-07 13:50 locks
I was researching and I find this.
Problably you have SELinux anabled, is a security system that I don't understad very well how does it work exactly but that's the problem. If you want to know if is on type
[root#localhost ~]# getenforce
If says enforcing, is on
In order to deactivate it type
[root#localhost ~]# chcon -R -t httpd_sys_content_t /var/www/svn/your/path
[root#localhost ~]# chcon -R -t httpd_sys_rw_content_t /var/www/svn/your/path
Do you have selinux enabled? I typically disable it for mod_dav_svn but you can get it working with some configuration.
vince#fedora12 /etc/httpd/conf.d > cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=disabled
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted
Apache generally have another user to access data. Generally it is called www-data. You can check by calling ps auxand search for apache processes
It is an old thread but I hit the same error message. In my case I was using another hard drive mounted as a repository so that I have to give ownership to www-data entire disk. I found this thread and applied than it worked at https://ubuntuforums.org/archive/index.php/t-1233618.html
sudo chown www-data:www-data /media/yourdisk -R