The correct fix is to update your SSL certificates.
sudo yum upgrade ca-certificates --disablerepo=epel
You need to disable the epel repo so that this command will succeed. After you update your certificates you can use yum normally as EPEL will work again.
I came across this error after updating my PHP installation to 5.5.14, on RedHat EL v6. I had installed PHP via the Yum package manager, and then needed to re-install some of the PHP extensions I was using. In searching for tips on how to solve this issue, I came across this question, and now that I have discovered a working solution I wanted to share my ...
init: logstash main process (2546) killed by KILL signal
Actually your process does stop here.
init: logstash main process ended, respawning
A new logstash process is started by init to replace it.
That is also shows which control process is responsible for restarting logstash: init. (On RHEL 6 and CentOS that is Upstart) Your process most likely gets ...
You can edit the file /etc/ld.so.conf and add your path /usr/local/lib to it
or create a new file in /etc/ld.so.conf.d/ like /etc/ld.so.conf.d/usrlocal.conf
and put only the following line in it
Then run ldconfig -v as root, and you're done.
You probably need to load the IPMI kernel modules:
You can add these to /etc/modules to have them loaded automatically (just list the module names):
you can use ldconfig, it recreates the symlink:
# rm /lib/libc.so.6
rm: remove symbolic link `/lib/libc.so.6'? y
# ls -l /lib/libc*
ls: error while loading shared libraries: libc.so.6: cannot open shared object file:
# ls -l /lib/libc*
lrwxrwxrwx. 1 root root 12 May 11 07:59 /lib/libc.so.6 -> libc-2.12.so
just tested it, as you ...
Use the Match config parameter in /etc/ssh/sshd_config:
# general config
# the following overrides the general config when conditions are met.
Match Address 192.168.0.*
See man sshd_config
From what I understand, this error is generated from the priorities plugin as noted by Pawel.
In 2009, the maintainer of yum mentioned that he hoped people would not use priorities. To disable the priorities plugin, edit /etc/yum/pluginconf.d/priorities.conf and set enabled = 0. After this change, next time you run yum update, you should not get any ...
When the gpg --gen-key command hangs like this, log in to another shell and perform the following command:
dd if=/dev/sda of=/dev/zero
(This command basically reads from your hard drive and discards the output, because writing to /dev/zero will do nothing.)
After a few seconds / minutes, the key generation command should complete.
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.
Processor advancements, clock speed and IPC calculations can make it almost impossible to try to reasonably compare decade old CPUs to modern ones. Not only are the instructions per cycle going to vary, but newer processors have instruction sets dedicated to complex calculations (Intel has added AES-NI as an example), clock speed is no longer a reasonable ...
I found a very, very, very helpful upstart script for people that are having problems in the future. Put this into /etc/init/
start on ( starting JOB!=debug \
or started JOB!=debug \
or stopping JOB!=debug \
or stopped JOB!=debug )
echo -n "$UPSTART_JOB/$UPSTART_INSTANCE ($0):$$:`date`:"
echo "Job $...
Here is a couple of shell scripts that will install and configure openldap on a server and install and configure sssd for user authentication against the LDAP-server.
One that installs the LDAP-server with groups, users etc.
# Install LDAP-server
I don't want to sound terrible by emphasizing something that should be obvious here, but you're comparing a high-end server processor from 2014 to a high-end server processor from 2007.
I don't think this requires much more explanation.
There's a reason an HP ProLiant DL580 G5 is available so inexpensively today. They were large, slow and lack many ...
Cron is not a shell - it does not parse commands in the same way that a shell does. As such, your variable is assigned as if it was static text.
There are three solutions I know of to this problem:
Use a shell script to generate your command, include whatever variables and logic you want - and call that shell script from cron.
* * * * * /path/to/...
I just have faced this problem on ubuntu when i called for PECL command. The only thing that helped me is to install php-xml package. First check if you have the XML module already installed with
If you don't find it then you have to
sudo apt-get install php-pear
it will automatically install php-xml package. or you can just install xml like this ...
You need to enable access to your server on port 80 as it is currently being blocked by iptables.
sudo /sbin/iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT
This will insert the rule into your iptables configuration at the start. Once you have done this and tested that it works then you should save the configuration so that it it is used next time the ...
Run strace ls /var/www/ and see what it hangs on. It's certainly hung on I/O -- that's what the D state in your ps output means (and since kill doesn't help, it's one of the uninterruptible I/O syscalls). Most hangs involve an NFS server that's gone to god, but based on your df that isn't the case here. A quick check of dmesg for anything related to ...
postfix/smtpd - This is typically the SMTP daemon process for handling incoming mail and routing to the appropriate internal location.
postfix/smtp - This is typically the SMTP daemon process for delivering mail out to the world.
If you're seeing alot of postfix/smtp log entries, these would be all of the SMTP connections sending spam out to other nodes.
Set LD_PRELOAD to preload the relevant library. I tried it out with libpthread and it seems to work:
root@spirit:~# mv /lib/x86_64-linux-gnu/libpthread.so.0 /lib/x86_64-linux-gnu/libpthread.so.0-bak
chattr: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory
The simple answer is "set the date manually", which you need to do, but to prevent this occurring again, there is more that you should do.
Ensure that the system timezone configuration is in a sane state.
Unless there is a very strong reason not to do so (such as software compatibility issues), server clocks should always run on UTC time.
If you decide ...
Put them in /etc/sysconfig/network-scripts/ifcfg-eth0, with a 2 or 3 etc. after them, such as:
Unfortunately this seems to be undocumented (or I can't find it right now; it looks like Red Hat rearranged their web site yet again).
sln serves exactly that purpose: to fix symbolic links when you can't use regular ln because you broke an essential symlink. To quote its man page:
The sln program creates symbolic links. Unlike the ln(1) program, it
is statically linked. This means that if for some reason the dynamic
linker is not working, sln can be used ...