On Mon 29.Feb'16 at 9:05:13 -0800, Gordon Messmer wrote:
> On 02/29/2016 05:33 AM, C. L. Martinez wrote:
> >More info in my ssl_error.log:
> >
> >Mon Feb 29 14:32:06 2016] [info] [client 10.64.118.59] SSL handshake failed:
> >HTTP spoken on HTTPS port; trying to send HTML error page
> >[Mon Feb 2
Am 01.03.2016 um 12:31 schrieb C. L. Martinez :
> On Mon 29.Feb'16 at 9:05:13 -0800, Gordon Messmer wrote:
>> On 02/29/2016 05:33 AM, C. L. Martinez wrote:
>>> More info in my ssl_error.log:
>>>
>>> Mon Feb 29 14:32:06 2016] [info] [client 10.64.118.59] SSL handshake
>>> failed: HTTP spoken on H
On 29/02/16 17:59, Benjamin Smith wrote:
> With the release of the Rasberry Pi 3.x, I think we have a platform I could
> jump on board with. Performance has just been lacking until now!
>
> But I really don't want to jump the "RH ship" - I'd rather stick with an
> environment I am comfortable i
On 02/29/2016 01:00 PM, Jos Vos wrote:
> On Mon, Feb 29, 2016 at 06:26:24PM +, Karanbir Singh wrote:
>
>> join the arm-dev list ( https://lists.centos.org ) CentOS has a great
>> story across the entire ARMv7 and v8 platform, with every major vendor
>> in the ARM 64bit platform working with u
Might be slightly OT as it isn't necessarily a CentOS related issue.
I've been using WD Reds as mdraid components which worked pretty well
for non-IOPS intensive workloads.
However, the latest C7 server I built, ran into problems with them on
on a Intel C236 board (SuperMicro X11SSH) with tons of
On 03/01/2016 09:53 AM, Emmanuel Noobadmin wrote:
Since I'm likely to use Reds again, it is a bit of a concern. So
wondering if I just happen to get an unlucky batch, or is there some
incompatibility between the Reds and the Intel C236 chipset, or
between Red / C236 / Centos 7 combo or the unli
On 3/2/16, Alice Wonder wrote:
> Is it possible to build a vanilla kernel to boot from and test if same
> issue exists?
Unfortunately no, had to get the server out ASAP so already swapped
the Reds with the vendor for HGSTs.
___
CentOS mailing list
CentO
On 02/29/2016 02:07 PM, Warren Young wrote:
so i enacted rngd -r /dev/urandom -o /dev/random
That’s essentially bogus. If /dev/random is blocking due to insufficient
entropy, feeding false entropy in from urandom buys you nothing, other than to
fool /dev/random into thinking it has more ent
Emmanuel Noobadmin wrote:
> Might be slightly OT as it isn't necessarily a CentOS related issue.
>
> I've been using WD Reds as mdraid components which worked pretty well
> for non-IOPS intensive workloads.
>
> However, the latest C7 server I built, ran into problems with them on
> on a Intel C236
On 02/29/2016 05:19 AM, C. L. Martinez wrote:
But I am doing some mistakes because every time I'm receiving a loop error.
...
...
ProxyPass / http://192.168.1.5:5100/
ProxyPassReverse / http://192.168.1.5:5100/
RewriteEngine On
RewriteRule ^/(.*) https://myweb
On Wed, Mar 02, 2016 at 01:53:54AM +0800, Emmanuel Noobadmin wrote:
> Might be slightly OT as it isn't necessarily a CentOS related issue.
>
> I've been using WD Reds as mdraid components which worked pretty well
> for non-IOPS intensive workloads.
>
> However, the latest C7 server I built, ran i
On 3/1/2016 9:53 AM, Emmanuel Noobadmin wrote:
However, the latest C7 server I built, ran into problems with them on
on a Intel C236 board (SuperMicro X11SSH) with tons of "ata bus error
write fpdma queued". Googling on it threw up old suggestions to limit
SATA link speed to 1.5Gbps using libata.
However, the latest C7 server I built, ran into problems with them on
on a Intel C236 board (SuperMicro X11SSH) with tons of "ata bus error
write fpdma queued". Googling on it threw up old suggestions to limit
SATA link speed to 1.5Gbps using libata.force boot options and/or
noncq. Lowering the
I discovered, amidst great initial pain, that most, if not all, of the
problems I had with SATA disks were caused by SATA cables and not by
the disks themselves. Intermittent problems, such as disks randomly
not showing up in RAID groups, were solved when I replaced the cables
with proper one
any chance your SATA cables aren't up to SATA3 (6gbps) performance
levels ?
In my experience, that's the most likely cause.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
greeting.
a short while ago, i may have gone to a site i should not have. maybe.
after visiting, i decided i would check for rpm updates.
when yumex opened to available packages, it showed that;
openssl.x86_64 0:1.0.1e-42.el6_7.4
was available, so i checked it, then clicked install button.
This command output is odd:
yum update --security
...
No packages needed for security; 118 packages available
However, this command says there's an OpenSSL update:
yum update openssl
...
---> Package openssl-libs.x86_64 1:1.0.1e-51.el7_2.2 will be updated
---> Package openssl-libs.x86_64 1:1.0.
On 02/03/16 15:57, Anthony K wrote:
> This command output is odd:
>
> yum update --security
> ...
> No packages needed for security; 118 packages available
...
> Why does yum not consider this CESA a security update?
Cherry-picking updates is not supported by CentOS, this is because each
package
to pass time waiting for reply, went thru kde application launcher.
found this progs have no icon:
cheese
audit logs
media player
note pad
regedit
wineconfig
winefile
winehelp
wine software uninstall
wine wordpad
audio cd extractor
running chkrootkit, shows
Checkin
On 03/01/2016 09:17 PM, Peter wrote:
> On 02/03/16 15:57, Anthony K wrote:
>> This command output is odd:
>>
>> yum update --security
>> ...
>> No packages needed for security; 118 packages available
> ...
>> Why does yum not consider this CESA a security update?
>
> Cherry-picking updates is not
On 03/01/2016 09:41 PM, Johnny Hughes wrote:
> On 03/01/2016 09:17 PM, Peter wrote:
>> On 02/03/16 15:57, Anthony K wrote:
>>> This command output is odd:
>>>
>>> yum update --security
>>> ...
>>> No packages needed for security; 118 packages available
>> ...
>>> Why does yum not consider this CESA
On 3/2/16, John R Pierce wrote:
> any chance your SATA cables aren't up to SATA3 (6gbps) performance levels ?
The cables came with the SuperMicro board so I certainly hope they
haven't started cheapening out on those :D
In any case, the cables shouldn't be the problem because I swapped
other dr
On 3/2/16, m.r...@5-cent.us wrote:
> Sorry, we don't seem to have any Supermicros with that m/b, but with the
> ones we have (all X9* m/bs), as well as our many Dells, old Penguins
> (rebranded Supermicro), and HPs, we've had no trouble at all with them,
> other than the occasional one that dies.
23 matches
Mail list logo
