Am 08.01.2015 um 03:54 schrieb Tim Dunphy:
Hey guys,
Got a quick question and I hope this is an easy one!
In my /etc/logrotate.conf file I have the following entry:
# rotate all of the apache logs -- we'll rotate them here
/var/log/mysqld.log {
weekly
size 50M
create 06
On 01/07/2015 01:06 PM, Always Learning wrote:
On Tue, 2015-01-06 at 16:07 -0700, Warren Young wrote:
"There is nothing new to be discovered in physics now. All that
remains is more and more precise measurement.”
— William Thomson, Lord Kelvin, 1900
Now means the current
Check for selinux denials for logrotate.
Chris
On Jan 7, 2015 8:09 PM, "Mateusz Guz" wrote:
> Have u tried removing the 'weekly' directive?
> You might consider replacing size with maxsize (details below)
>
> maxsize size
> Log files are rotated when they grow bigger than size bytes even before
Have u tried removing the 'weekly' directive?
You might consider replacing size with maxsize (details below)
maxsize size
Log files are rotated when they grow bigger than size bytes even before the
additionally specified time interval (daily, weekly, monthly, or yearly). The
related size option
Hey guys,
Got a quick question and I hope this is an easy one!
In my /etc/logrotate.conf file I have the following entry:
# rotate all of the apache logs -- we'll rotate them here
/var/log/mysqld.log {
weekly
size 50M
create 0644 mysql mysql
rotate 1
}
And from that I woul
On 01/08/2015 12:16 PM, Chuck Campbell wrote:
> Peter,
> thank you, I was guessing this is what might be needed, and I appreciate the
> heads up on what to expect when I do the update.
>
> The resolution I achieved is a bit more convoluted, but it consists of the
> following, and remains consisten
On 01/07/2015 3:04 AM, Liam O'Toole wrote:
>> Maybe you missed the big announcement:
>> http://lists.centos.org/pipermail/centos-announce/2014-January/020100.html
Thanks for this Liam!
It gave me a lot of context I was missing.
On 01/07/2015 4:25 AM, Jim Perrin wrote:
> Nope. We're still air-gapp
On 1/7/2015 4:01 PM, Peter wrote:
> On 01/08/2015 05:39 AM, Chuck Campbell wrote:
>> I tried this using yum install dovecot22, but I get a lot of these:
>> file xxx from install of dovecot22-1:2.2.15-1.gf.el6.x86_64 conflicts with
>> file
>> from package dovecot-1:2.0.9-8.el6_6.4.x86_64
>>
>> I tr
On 01/08/2015 05:39 AM, Chuck Campbell wrote:
> I tried this using yum install dovecot22, but I get a lot of these:
> file xxx from install of dovecot22-1:2.2.15-1.gf.el6.x86_64 conflicts with
> file
> from package dovecot-1:2.0.9-8.el6_6.4.x86_64
>
> I tried yum update dovecot22, but I get:
> Pa
> On Jan 7, 2015, at 12:08 PM, John R Pierce wrote:
>
> On 1/7/2015 11:30 AM, Gary Greene wrote:
>> During the reboot, most card’s drivers on init, will invalidate the cache on
>> the card to ensure dirty pages of data don’t get flushed to disk, to prevent
>> scribbling junk data to the platter
On Wed, Jan 7, 2015 at 3:30 PM, John R Pierce wrote:
>>
>> Right... but only cost 133% (about) more than consumer drives, as opposed
>> to the 300% that the "server/enterprise" grade drives' cost.
>
>
> well, those $$$ drives are likely SAS rather than SATA, and that has other
> advantages... 10k
On 1/7/2015 12:50 PM, m.r...@5-cent.us wrote:
Right... but only cost 133% (about) more than consumer drives, as opposed
to the 300% that the "server/enterprise" grade drives' cost.
well, those $$$ drives are likely SAS rather than SATA, and that has
other advantages... 10k or 15k RPM gives yo
On 1/7/2015 12:15 PM, m.r...@5-cent.us wrote:
Actually, the WD Reds and similar are just fine.
those are specifically sold for use in small NAS (raid) environments, so
yeah, they are configured 'correctly'.
--
john r pierce 37N 122W
somewhere on the mid
On 1/7/2015 11:30 AM, Gary Greene wrote:
During the reboot, most card’s drivers on init, will invalidate the cache on
the card to ensure dirty pages of data don’t get flushed to disk, to prevent
scribbling junk data to the platters. From what I recall, this is true of both
the megaraid and ada
On Wed, Jan 7, 2015 at 1:37 PM, Gary Greene wrote:
>>
> Problem is, Gordon, the layer I’m talking about is _below_ the logical layer
> that filesystems live at, in the block layer, at the mercy of drivers, and
> firmware that the kernel has zero control over. While in a perfect world, the
> con
> On Jan 6, 2015, at 9:23 PM, Gordon Messmer wrote:
>
> On 01/06/2015 04:37 PM, Gary Greene wrote:
>> This has been discussed to death on various lists, including the
>> LKML...
>>
>> Almost every controller and drive out there now lies about what is
>> and isn’t flushed to disk, making it nigh
> On Jan 6, 2015, at 5:50 PM, Les Mikesell wrote:
>
> On Tue, Jan 6, 2015 at 6:37 PM, Gary Greene
> wrote:
>>
>>
>> Almost every controller and drive out there now lies about what is and isn’t
>> flushed to disk, making it nigh on impossible for the Kernel to reliably
>> know 100% of the ti
On 1/7/2015 10:52 AM, Johnny Hughes wrote:
> On 01/07/2015 10:39 AM, Chuck Campbell wrote:
>> On 1/7/2015 9:46 AM, Chuck Campbell wrote:
>>> On 1/7/2015 12:06 AM, Alexander Dalloz wrote:
Am 06.01.2015 um 23:55 schrieb Chuck Campbell:
> I'm running centos 6.6 with the default 2.0.9-xxx dove
On Wed, January 7, 2015 10:54 am, Les Mikesell wrote:
> On Wed, Jan 7, 2015 at 10:43 AM, Valeri Galtsev
> wrote:
>>>
>>> Not junk - these are mostly IBM 3550/3650 boxes - pretty much top of
>>> the line in their day (before the M2/3/4 versions), They have
>>> Adaptec raid contollers,
>>
>> I nev
On Wed, Jan 7, 2015 at 10:15 AM, wrote:
>>>
>> Yes - the unattended fsck fails. Personally, I'd prefer for the
>> default run to use '-y' in the first place. It's not like I'm more
>> likely than fsck to know how to fix it and it is very inconvenient on
>> remote machines. The recent case wa
On Wed, Jan 7, 2015 at 10:43 AM, Valeri Galtsev
wrote:
>>
>> Not junk - these are mostly IBM 3550/3650 boxes - pretty much top of
>> the line in their day (before the M2/3/4 versions), They have
>> Adaptec raid contollers,
>
> I never had Adaptec in _my_ list of good RAID hardware... But certainl
On 01/07/2015 10:39 AM, Chuck Campbell wrote:
> On 1/7/2015 9:46 AM, Chuck Campbell wrote:
>> On 1/7/2015 12:06 AM, Alexander Dalloz wrote:
>>> Am 06.01.2015 um 23:55 schrieb Chuck Campbell:
I'm running centos 6.6 with the default 2.0.9-xxx dovecot.
I run sa-learn against my spam_to_
On Wed, January 7, 2015 10:33 am, Les Mikesell wrote:
> On Wed, Jan 7, 2015 at 9:52 AM, Gordon Messmer
> wrote:
>>
>> Every regular file's directory entry on your system is a hard link.
>> There's
>> nothing particular about links (files) that make a filesystem fragile.
>
> Agreed, although when
On 1/7/2015 9:46 AM, Chuck Campbell wrote:
> On 1/7/2015 12:06 AM, Alexander Dalloz wrote:
>> Am 06.01.2015 um 23:55 schrieb Chuck Campbell:
>>> I'm running centos 6.6 with the default 2.0.9-xxx dovecot.
>>>
>>> I run sa-learn against my spam_to_learn folder, then I wan to move those
>>> emails
>>
On Wed, Jan 7, 2015 at 9:52 AM, Gordon Messmer wrote:
>
> Every regular file's directory entry on your system is a hard link. There's
> nothing particular about links (files) that make a filesystem fragile.
Agreed, although when there are millions, the fsck fixing it is somewhat slow.
>> It is m
On 01/07/2015 08:53 AM, Les Mikesell wrote:
On Wed, Jan 7, 2015 at 12:10 AM, Keith Keller
wrote:
On 2015-01-07, Gordon Messmer wrote:
Of course, the other possibility is simply that you've formatted your
own filesystems, and they have a maximum mount count or a check
interval.
If Les is havi
On 01/07/2015 05:53 AM, Les Mikesell wrote:
Yes - the unattended fsck fails.
In that case, there should be logs indicating the cause of the error
when it was detected by the kernel. There's probably something wrong
with your controller or other hardware.
Personally, I'd prefer for the
de
On 1/7/2015 12:06 AM, Alexander Dalloz wrote:
> Am 06.01.2015 um 23:55 schrieb Chuck Campbell:
>> I'm running centos 6.6 with the default 2.0.9-xxx dovecot.
>>
>> I run sa-learn against my spam_to_learn folder, then I wan to move those
>> emails
>> to a learned_spam folder.
>> when I do a doveadm
On Tue, Jan 06, 2015 at 08:45:29PM -0600, John R. Dennison wrote:
> It's not relevant in _any_ sense. CentOS is nothing more than (at it's
> core) a rebuild of RHEL. This type of nonsense should be directed to
> Red Hat in a Red Hat venue. It's nothing but off-topic noise here as
> CentOS will n
On Wed, 2015-01-07 at 08:31 -0500, Darr247 wrote:
> On 07 January 2015 @01:37 zulu, Always Learning wrote:
> > You seem to forget. Computers were invented to perform repetitive tasks.
>
> Or maybe, some of us just seem to remember it differently.
> In my opinion, robots/automatons were invented
On Wed, Jan 7, 2015 at 7:31 AM, Darr247 wrote:
> On 07 January 2015 @01:37 zulu, Always Learning wrote:
>>
>> You seem to forget. Computers were invented to perform repetitive tasks.
>
>
> Or maybe, some of us just seem to remember it differently.
> In my opinion, robots/automatons were invented t
I sent this last night but it didn't show up in the archives. Trying
again without the attachment. Are messages with attachments blocked
on this list?
On Tue, Jan 6, 2015 at 11:50 PM, Darby Vicker wrote:
> Thanks a ton for the suggestions and info everyone.
>
>> Two things I think you should co
John R. Dennison писал 2015-01-07 04:49:
Quick question, if I may? What does this have to do with CentOS?
I for one read this thread with interest. Let it be.
And IMHO the topics are relevant for anybody professionally involved
with computers.
___
On Wed, Jan 7, 2015 at 12:10 AM, Keith Keller
wrote:
> On 2015-01-07, Gordon Messmer wrote:
>>
>> Of course, the other possibility is simply that you've formatted your
>> own filesystems, and they have a maximum mount count or a check
>> interval.
>
> If Les is having to run fsck manually, as he
On 07 January 2015 @01:37 zulu, Always Learning wrote:
You seem to forget. Computers were invented to perform repetitive tasks.
Or maybe, some of us just seem to remember it differently.
In my opinion, robots/automatons were invented to perform repetitive
tasks; computers were invented to perf
Hi,
I am trying to implement the *password must change at next logon* in CentOS
6.5 client using sssd 1.11.6 where Samba 4.1.10 is my backend server.
Here are the list of things which I have done,
1. I have setup the CentOS to do the Domain login using sssd service. I can
able to login into the
36 matches
Mail list logo