I have installed Minio server on a Centos 7.9 and I am trying to run it as a service.
I used this guide and the minio.service file it provided to install Minio as a service: https://www.centosblog.com/install-configure-minio-object-storage-server-centos-linux/
Now when I try to enable the service I receive the following error. Could someone please kindly help?
[root#danesh bin]# systemctl enable minio.service
** (pkttyagent:38702): WARNING **: 22:50:16.320: Unable to register authentication agent: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Cannot determine user of subject
Error registering authentication agent: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Cannot determine user of subject (polkit-error-quark, 0)
Starting the service:
[root#danesh bin]# systemctl start minio.service
** (pkttyagent:43010): WARNING **: 23:06:46.143: Unable to register authentication agent: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Cannot determine user of subject
Error registering authentication agent: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Cannot determine user of subject (polkit-error-quark, 0)
Job for minio.service failed because a configured resource limit was exceeded. See "systemctl status minio.service" and "journalctl -xe" for details.
It turned out to be because of "Secure processes" in Centos. It supposedly hides all Linux processes not owned by the user.
I had CWP control panel so I went to "Secure processes" section of the panel and temporarily disabled it. After enabling the service you can re-enable it.
You have to set permissive mode to SELINUX. Open the following file in the command line:
sudo vi /etc/selinux/config
Then change the following value:
SELINUX=permissive
And finally, reboot the OS:
sudo reboot
After you enable minio.service, don't forget to set enforcing to SELINUX again.
Related
I am trying to configure mod_evasive in my CENTOS7 server (VPS) to prevent DDOS attacks.
I followed the steps mentioned in the following tutorial. (this link) Although I am not using IPTABLES, I am using firewalld instead.
In mod_evasive, the directive to execute a shell command when an IP is blacklisted is DOSSystemCommand. But when an IP is blocked, the script I want to run which will submit the IP address to firewalld to block, is blocked by SeLinux. According to what I understood after looking at the audit.log is, SeLinux does not allow apache user to run a command as sudo. Even though this is allowed via the sudoers file.
(mod_evasive is working properly, I verified this my running the test script provided by mod_evasive. I also get the email when an IP is blocked)
Following are the specifics;
mod_evasive.conf file (only the DOSSystemCommand directive shown below)
DOSSystemCommand "sudo /var/www/mod_evasive/ban_ip_mod_evasive.sh"
I have also tried the below variation (with different users too, Ex. root user)
DOSSystemCommand "sudo -u apache '/var/www/mod_evasive/ban_ip_mod_evasive.sh %s'"
Sudoers file (only the part I have modified for this purpose [allow apache to run as sudo)
apache ALL=(ALL) NOPASSWD:ALL
Defaults:apache !requiretty
I have allowed apache to run as any user for all scripts, just for testing purposes. Initially I had restricted the command as follows
apache ALL=NOPASSWD: /usr/local/bin/myscripts/ban_ip.sh
Defaults:apache !requiretty
My ban_ip.sh file
#!/bin/sh
# IP that will be blocked, as detected by mod_evasive
IP=$1
sudo firewall-cmd --add-rich-rule 'rule family="ipv4" source address="`$IP" service name="https" reject'
I have verified that the configuration is working by running the following
sudo -u apache '/usr/local/bin/myscripts/ban_ip.sh 111.111.111.111'
The above command successfully adds the rule to firewalld.
This entire setup works when I disable SeLinux.
After I enable SeLinux the following errors appear in the audit.log
type=AVC msg=audit(1593067671.808:1363): avc: denied { setuid } for pid=3332 comm="sudo" capability=7 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:system_r:httpd_sys_script_t:s0 tclass=capability permissive=0
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
type=AVC msg=audit(1593067671.808:1364): avc: denied { setgid } for pid=3332 comm="sudo" capability=6 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:system_r:httpd_sys_script_t:s0 tclass=capability permissive=0
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
The following flags are set in SeLinux
httpd_mod_auth_pam
httpd_setrlimit
I am not sure why SeLinux blocks this, therefore I am skeptical to create a custom policy to allow this behavior as audit2allow suggests.
audit2allow output
#============= httpd_sys_script_t ==============
allow httpd_sys_script_t self:capability { setgid setuid };
#============= httpd_t ==============
allow httpd_t systemd_logind_t:dbus send_msg;
I feel mod_evasive would not help in stopping a DDOS if we can not block the IP rather than merely sending a 403 forbidden response to the attacker. This will still consumer the server resources.
How can I solve this and what other alternatives I can implement to mitigate DDOS and enhance my VPS protection?
thanks for your help
I am no more able to do sudo su - to get root authentication. I am logged in as test user. I mapped test from unconfined_u to SElinux user staff_u. I restarted the vm machine on google cloud. I can login to vm as test user, but if I do sudo su -, I get following error:
su: avc.c:74: avc_context_to_sid_raw: Assertion `avc_running' failed.
Aborted
It seems to be a known bug of CentOS and Redhat:
0011249: su: avc.c:74: avc_context_to_sid_raw: Assertion `avc_running'
failed.
Description Whenever I execute a su - command after switching
into the sysadm_r, I get this fault. The system is in enforcing mode
when I get this error. When in permissive mode, this does trigger the
error. Attempted to address the problem with audit2allow to see if
that could temporarily resolved the problem while I looked for a
permanent solution but that did not work either
There are the 2 referencies:
Centos bug
RedHat Bug
Following the tutorial and tool setup as outlined here;
https://hyperledger.github.io/composer/installing/development-tools.html
On the very last step, I executed the script to download and install local Fabric runtime:
cd ~/fabric-tools
./downloadFabric.sh
The resulting log in the console contained this error at the very end:
# Pull and tag the latest Hyperledger Fabric base image.
docker pull hyperledger/fabric-peer:$ARCH-1.0.4
Warning: failed to get default registry endpoint from daemon (Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.35/info: dial unix /var/run/docker.sock: connect: permission denied). Using system default: https://index.docker.io/v1/
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.35/images/create?fromImage=hyperledger%2Ffabric-peer&tag=x86_64-1.0.4: dial unix /var/run/docker.sock: connect: permission denied
What should I do about this warning?
So your issue is a Docker issue - not a Hyperledger Composer issue FYI. I think this may help you https://techoverflow.net/2017/03/01/solving-docker-permission-denied-while-trying-to-connect-to-the-docker-daemon-socket/
Possibly a docker install issue - didn't install correctly? See here https://superuser.com/questions/835696/how-solve-permission-problems-for-docker-in-ubuntu where it talks about being in the docker group. Or else you can find an answer on Google.
I think this answer might be the reason behind it. The shell keeps your session stored. SO, in order to get the updates working, you have to close the shell and restart it again. That's why it worked after the restart.
Please correct me if I'm wrong!
I am trying to integrate flocker with docker, for that I found plugin flocker-docker-plugin. I installed it by using the commands on my flocker agents.-
$ yum install -y clusterhq-flocker-docker-plugin
$ systemctl enable flocker-docker-plugin
$ systemctl restart flocker-docker-plugin
It shows flocker-docker-plugin is running. However after few seconds when I checked status by using $ systemctl status flocker-docker-plugin, I got error saying
flocker-docker-plugin.service: main process exited, code=killed, status=11/SEGV
Based on the information you have given there could be multiple reasons for this error:
Check if you can reach the flocker control service and more so if your node-agents can reach the control-service.
Check if the flocker-dataset-agent and the flocker-container-agent are running on your nodes.
Check if you have provided certificates for the flocker-docker-plugin as mentioned on their site (https://docs.clusterhq.com/en/latest/docker-integration/generate-api-plugin.html).
While installing flocker i also got the same error as we have just installed the docker plugin and by default it does't start's up.
First use the command systemctl start flocker-docker-plugin and then check the running status of flocker using systemctl status flocker-docker-plugin
Make sure the control service and dataset agent are running correctly first, you can find logs by looking in /var/log/flocker/, journalctl -u flocker-dataset-agent or running flocker-diagnostics.
Read through any error in these logs such as communication with control service issues, certificates issues, agent.yml config issues etc, or feel free to post them for more help.
You can also find flocker-docker-plugin logs the same way to see specific errors that may be occurring.
Here is more information about how to debug flocker.
I am starting with a clean install of Fedora 15 on a VirtualBox VM and trying to install Zend Server CE. To install, I adding the Zend repo to yum and ran:
sudo yum install zend-server-ce-php-5.3
The installation itself seemed to go very well. I opened the browser at http://localhost:10081/ZendServer as directed. After clicking through the license page and entering an administative password I get the error:
Failed to access Web server. Please make sure that the Web server is running and listening to the correct port
The Applications, Rules Management and Administration tabs function properly but the Monitor and Server Setup tabs both display the above error. It is a fact that the web server is not running, but when I try to rectify that I get another error:
$ sudo service httpd start
[sudo] Password for XXXXX:
Starting httpd (via systemctl): Job failed. See system logs and 'systemctl status' for details.
[FAILED]
For what it's worth (not much, I'm guessing) here are the details the message refers to:
$ sudo tail /var/log/messages
....
Jan 17 17:24:18 M5 systemd[1]: httpd.service: control process exited, code=exited status=1
Jan 17 17:24:18 M5 systemd[1]: Unit httpd.service entered failed state.
$ systemctl status httpd.service
httpd.service - LSB: start and stop Apache HTTP Server
Loaded: loaded (/etc/rc.d/init.d/httpd)
Active: failed since Tue, 17 Jan 2012 17:24:18 -0500; 3min 44s ago
Process: 19500 ExecStart=/etc/rc.d/init.d/httpd start (code=exited, status=1/FAILURE)
CGroup: name=systemd:/system/httpd.service
The diagnostics don't seem very helpful. I've tried various things, such as installing and starting httpd before installing Zend Server CE, reinstalling httpd (no good: unistalling it caused Zend to uninstall too). The httpd config isn't causing the problem as the following output demonstrates:
$ /usr/sbin/apachectl configtest
Syntax OK
Is this a know problem? What's my next move? Do I start putting debug statements in the control script to see what's failing? I can do that, but I'm hoping someone out there has dealt with this problem and can give me a quick solution.
I was able to get better information on the cause of the problem by invoking the apachectl script directly rather than using the service:
$ sudo /usr/sbin/apachectl start
httpd: Syntax error on line 220 of /etc/httpd/conf/httpd.conf: Syntax error on line 6 of /etc/httpd/conf.d/zendserver_php.conf: Cannot load /usr/local/zend/lib/apache2/libphp5.so into server: /usr/local/zend/lib/apache2/libphp5.so: cannot enable executable stack as shared object requires: Permission denied
The syntax check on httpd.conf didn't catch this because it's not really a syntax error and it's not in httpd.conf either, but in the included zendserver_php.conf. A quick search shows that this error is the result of libphp5.so violating one of the constraints that SELinux enforces. SELinux is enabled by default in Fedora 15.
I don't like to reduce security, but that the only way I've seen this issue addressed. So I disabled SELinux temporarily with the command
$ sudo setenforce 0
I also edited /etc/selinux/config and changed SELINUX=enforced to SELINUX=disabled so SELinux would stay disabled on reboot. Now my web server starts without a hitch:
[mike#M5 ~]$ sudo service httpd start
Starting httpd (via systemctl): [ OK ]
I would like to think someone in the Zend development community is working on this shared library issue. Reducing security is not an acceptable work-around in a lot of cases. If anybody has a better solution, I'd still like to know it.