Hot answers tagged centos6
As you can see from the output, the release version has changed from 6.6 to 6.7: centos-release.x86_64 6-7.el6.centos.12.3 base So this is perfectly normal. http://wiki.centos.org/Manuals/ReleaseNotes/CentOS6.7
The key thing to pick up is centos-release.x86_64, which is being upgraded to 6-7.el6.centos.12.3. You haven't said which subversion of CentOS you're on, but assuming you're up to patch, you're on 6.6 - this is the new 6.7 release hitting the mirrors. Those of us using the cr (continuous release) repository saw many of these packages arrive late last week. ...
You're using the syntax for an entry in /etc/crontab which has the user ID in the 6th column, but if you use crontab -e, you're editing the entry in /var/spool/crontab, which does not have this column since they are already separated per user. In other words, this is what you would put in /etc/crontab: 0 1 * * * root /sbin/shutdown -r now And this is ...
You can look into /var/log/secure to get login times. If there was only one user at the time, it's a strong indication he was the culprit (but not necessary a proof). If there where more users logged in, you can't identify the offending IP this way. With users sharing a username, even the auditing subsystem won't help you much, I guess. Having shared ...
It seems like this could be a routing issue. Since the VMs inside KVM can route independently of the host, the issue is not going to be your physical network connectivity, but rather your logical network connectivity. Check your default gateway and static routes, make sure those are configured properly. If your host cannot find a route back to the devices ...
This very much looks like a DNS configuration problem inside the VM. Start from looking at /etc/resolv.conf contents. My guess is that adding/removing interfaces may change routing table and this way influence name resolving. What happens when you change nameservers order? A result from host -v google.com. could help you find the correctly working nameserver ...
SOLVED: Stupid mistake, I were trying to load a key in .ppk format by specifying it in preferences, the solution, use Pageant and set as "Try autologin" in preferences instead.
when you do ps aux | grep cron you are running two commands - ps aux and grep cron. ps aux lists all processes currently running, and grep cron matches any lines which contain "cron" in them. Obviously the crond process matches the word cron, but so does the grep cron process you just ran. It's matching itself recursively.
Your system gets stuck in boot because the system service in boot order after atd is broken or has a very long timeout value configured. First of all you should activate system message during boot to identify which service is the problem. To do that you should follow the instructions given in this server fault question. Once you finished that your system ...
As a root user, you can append the JAVA_HOME value in /etc/profile export JAVA_HOME=/opt/jdkpath PATH=$PATH:$HOME/bin:/opt/jdkpath/bin Change /opt/jdkpath to the correct path of your jdk installation. Once you do that you can logout & login back & execute the service command
You can try implementing sudosh - http://sourceforge.net/projects/sudosh/ It acts like a VCR, you can see the commands the people ran and who exactly ran it. Hope this helps.
The problem is that your firewall is not stateful, and it only allowed traffic to pass in one direction. There is nothing here to allow return traffic. So, while a client request is passed through, the response from the server doesn't match any rules and is dropped. Write instead normal stateful rules. For example: -A FORWARD -m conntrack --ctstate ...
I solved, in my case, using noperm option in fstab entry
You should install a version of the fwknopd package which is built for CentOS 6, rather than Fedora 21. Sadly, it doesn't appear that the Cipherdyne site provides up-to-date binary RPMs for anything else, so you're stuck with downloading the SRPMs and building them yourself.
For the next foolio....The actual path to the nagios.cmd is /var/spool/nagios. Once I set the right path in the NSCA.cfg file, everything started working. Remember, that nsca puts in a file nsca.dump which has all the data. nsca.dump needs to consumed by nagios.cmd.
A new release of CentOS just came out a few days ago. It's not surprising that there's a sudden influx of new packages.
Only top voted, non community-wiki answers of a minimum length are eligible