Hot answers tagged

2

You are mixing CentOS 6 packages (.el6) with CentOS 7 packages (.el7), which is invalid. They differ a lot. You installed mysql56-community-release-el7.* instead of mysql56-community-release-el6*, where from you get that. Remove this wrong package source: yum remove "mysql56-community-release-el7.*" Install the correct one (as you installed the above ...


2

sudo wants your password in your case user cooltoo's password, not the root password. Update You don't need to be root every time you want to run some specific administrative tasks. Thanks to sudo, you can run some or every command as root. Once sudo is installed (package name: sudo), you can configure it by running visudo as root. Basically, it runs ...


2

Does /temp really exist (didn't you mean /tmp)? If it doesn't then your script tries to cd to /temp, fails, and then all the commands run in the starting directory. The last two commands are particularly dangerous because you cd to /, then cd to /temp (which may not exist) and then rm everything (which could well be the root filesystem). You should ...


2

In addition to the other answers, iptables -v -L lists the counts of packets and bytes that traverse a given rule, so you can see how much traffic you're dropping, and I wouldn't be too hard to write a tool that parses and reports that info.


1

You need to explicitly log the packets, using the LOG target. You'd add a rule in your chains with the same criteria as the DROP rule for the abusive IP, but using -j LOG instead of -j DROP. In addition you can specify the log prefix using --log-prefix, and a log level using --log-level. It's also common to specify rate limits to avoid flooding the logs... ...


1

You'll need to set up a logging chain for your dropped packets. There is a good tutorial on doing that at http://www.thegeekstuff.com/2012/08/iptables-log-packets/ which boils down to adding something similar to the following to your current ruleset: iptables -N LOGGING iptables -A INPUT -j LOGGING iptables -A LOGGING -m limit --limit 2/min -j LOG ...


1

Did you use yum to uninstall it? I would check for any startup/upstart/init.d scripts that might be lingering around. As a last resort, if there are no startup scripts, you can try moving it to the /tmp/ directory: sudo mv `which sosreport` /tmp/


1

In my opinion you should never ever disable the root user entirely. If you do not want to be able to login as root using ssh you should set the directive PermitRootLogin no in /etc/ssh/sshd_config. For other applications there are mostly equivalent settings which can be made.


1

Start another Linux VM, and mount that disk to repair the problem. In addition, to avoid the password entered in single user mode, change as follows /lib/systemd/system/rescue.service. --- /lib/systemd/system/rescue.service.orig 2015-11-20 13:49:03.000000000 +0900 +++ /lib/systemd/system/rescue.service 2016-04-11 15:58:31.002000000 +0900 @@ -18,11 ...


1

It looks to me like a cron job creating temporary working directories and then failing to clean up after itself properly. To verify that, examine any local (i.e. not part of a system package) scripts called from root's crontab, as well as /etc/crontab and /etc/cron*/* - especially any that run every 5 minutes My initial guess was that it would be a cron ...


1

sslsniff hasn't been updated since the end of 2011. Author seems to ignore issues and pull requests. You have a few options: look through forks on GitHub to see if anyone is keeping it all up to date; try and find libboost 1.35 for Centos (or maybe even compile it yourself) and build against that; depending on your needs, mitmproxy might fit your usecase. ...



Only top voted, non community-wiki answers of a minimum length are eligible