similar to: mysql client ssl connection failure

https://bugzilla.mindrot.org/show_bug.cgi?id=845 Devin Reade <gdr at gno.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gdr at gno.org --- Comment #12 from Devin Reade <gdr at gno.org> 2011-05-03 14:08:48 EST --- [More details for

In article <55D2174F.70509 at centos.org>, Johnny Hughes <johnny at centos.org> wrote: > On 08/17/2015 11:19 AM, Johnny Hughes wrote: > > On 08/17/2015 10:57 AM, Tony Mountifield wrote: > >> I recently applied updates to a CentOS 5 box running MySQL. I've discovered > >> that the new version of openssl, 0.9.8e-36.0.1.el5_11, breaks MySQL SSL > >>

On 08/17/2015 11:19 AM, Johnny Hughes wrote: > On 08/17/2015 10:57 AM, Tony Mountifield wrote: >> I recently applied updates to a CentOS 5 box running MySQL. I've discovered >> that the new version of openssl, 0.9.8e-36.0.1.el5_11, breaks MySQL SSL >> connections. >> >> If I rename /lib/libssl.so.0.9.8e and replace it with the old version of >> that file

Now don't go bugging people asking when CentOS 6.7 will be out. "When it's ready." In upgrading from RHEL 6.6 to 6.7, I did find that I had to disable my 3rd party repos (elrepo and epel) in order to avoid yum erroring out. Plus I did the usual "yum clean all". (I don't use the PackageKit GUI as it's been unable to complete for quite a few months without

In article <55D20981.7030902 at centos.org>, Johnny Hughes <johnny at centos.org> wrote: > On 08/17/2015 10:57 AM, Tony Mountifield wrote: > > I recently applied updates to a CentOS 5 box running MySQL. I've discovered > > that the new version of openssl, 0.9.8e-36.0.1.el5_11, breaks MySQL SSL > > connections. > > > > If I rename

Am 10.11.2015 um 22:36 schrieb Devin Reade <gdr at gno.org>: > > bat is a native GUI, so UNIX only. we use bat GUI on windows ... -- LF

On 08/17/2015 10:57 AM, Tony Mountifield wrote: > I recently applied updates to a CentOS 5 box running MySQL. I've discovered > that the new version of openssl, 0.9.8e-36.0.1.el5_11, breaks MySQL SSL > connections. > > If I rename /lib/libssl.so.0.9.8e and replace it with the old version of > that file from openssl-0.9.8e-27.el5_10.1 (not sure if that is the next >

On Nov 18, 2015, at 9:49 PM, Devin Reade <gdr at gno.org> wrote: > > The one thing I would point out regarding the above link is that despite > conventional UNIX wisdom, *don't* put /usr on a separate filesystem > in CentOS 7. <sarcasm>Thank you RedHat</sarcasm> > > Flames to /dev/null. Sorry, you don?t get to throw that grenade and then run away. The

--On Thursday, July 23, 2015 11:40:21 PM -0700 Akemi Yagi <amyagi at gmail.com> wrote: > On Thu, Jul 23, 2015 at 8:02 PM, Devin Reade <gdr at gno.org> wrote: > >> In upgrading from RHEL 6.6 to 6.7, I did find that I had to disable >> my 3rd party repos (elrepo and epel) in order to avoid yum erroring >> out. > > Can you elaborate on this? What yum

I've got a fresh CentOS 7 test machine, fully patched. The command: shutdown -h now surprisingly does not halt the machine. Instead it reboots it. WTF? I found the following Debian discussion which seems to be the same issue: <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766338> However, removing kexec-tools in this case did not solve the problem. Nor does

I recently applied updates to a CentOS 5 box running MySQL. I've discovered that the new version of openssl, 0.9.8e-36.0.1.el5_11, breaks MySQL SSL connections. If I rename /lib/libssl.so.0.9.8e and replace it with the old version of that file from openssl-0.9.8e-27.el5_10.1 (not sure if that is the next oldest, but it was handy), then SSL connection to MySQL works again. I then performed

--On Monday, May 11, 2015 02:26:17 PM -0700 John R Pierce <pierce at hogranch.com> wrote: > never met a unix that didn't come with Perl already installed, or as a > base option SunOS-4 :) Didn't have emacs, either, nor an ANSI-C compiler. And the OS came on QIC-150 tape (ie: 150 MB total capacity). Not that that defeats the argument ... Devin

Have you considered any alternatives? I'm thinking of IPSec to create a secured network encapsulation channel(s) "above" the TCP connection(s). This would provide encryption with control over cipher(s), and cert validation on both sides (if you used cert auth, not PSK). -- K On Thu, Apr 18, 2019, at 12:15 PM, TG Servers via dovecot wrote: > Ok then it seems again a MariaDB

It's time to purchase hardware again, and I'm going through the usual "of that which is on the market, what will CentOS run without leaving new hardware collecting dust for a year"? I'm looking at a number of commodity-grade machines (ie: desktop grade will suffice) with reasonably fast CPUs and able to use at least 8GB each (preferably 32GB). These will be deployed as

What does your /etc/idmapd.conf look like on the server side? I fought with this quite a bit a while ago, but my use case was a bit different, and I was working with CentOS 5 and 6. Still, the kicker for me was updating the [Translation] section of /etc/idmapd.conf. Mine looks like this: [Translation] Method = nsswitch GSS-Methods = nsswitch,static You said you're not using Kerberos or

On Thu, Jul 23, 2015 at 8:02 PM, Devin Reade <gdr at gno.org> wrote: > In upgrading from RHEL 6.6 to 6.7, I did find that I had to disable > my 3rd party repos (elrepo and epel) in order to avoid yum erroring > out. Can you elaborate on this? What yum error(s) did you see? I updated a RHEL 6.6 system with ELRepo enabled (but no EPEL packages) to RHEL 6.7 using 'yum update'

On Nov 19, 2015, at 3:49 PM, Devin Reade <gdr at gno.org> wrote: > > size of the disk was never the original motivation for > keeping / separate, at least within my memory Prior to SysV, the location of user home directories was not standardized, and AT&T recommended that you put them in /usr.[1] Also, in the PDP days, you had things like the RL and RK series drives, which

I have a CentOS 6 machine that was initially installed as CentOS 6.4 in May of 2013. It's /boot filesystem is 200M which, IIRC, was the default /boot size at the time. The most recent kernel update (2.6.32-573.18.1.el6) fails because of lack of space in /boot. The workaround is edit /etc/yum.conf, reduce installonly_limit from 5 to something lower (I used 3), remove the oldest kernel via

On Wed, Apr 29, 2015 at 10:36 AM, Devin Reade <gdr at gno.org> wrote: > Have you looked at the client-side NFS cache? Perhaps the C6 cache > is either disabled, has fewer resources, or is invalidating faster? > (I don't think that would explain the C5 starvation, though, unless > it's a secondary effect from retransmits, etc.) Do you know where the NFS cache settings