date:20170420

On 04/20/2017 06:17 PM, Warren Young wrote:

On Apr 20, 2017, at 3:39 PM, Robert Moskowitz wrote:

On 04/20/2017 05:16 PM, Warren Young wrote:

On Apr 20, 2017, at 3:00 PM, Robert Moskowitz wrote:

So I have learned that Postfix should delay until Chronyd has moved the system
time from 0 to current.

I think it’s more the case that CentOS is written with the assumption that
you’re running it on a host with a battery-backed RTC

It is the Centos7 for arm SOCs. RPi is one of the worst (in my opinion) of
these.

So you picked an alternative that cites “server stability” when explaining why
they’re redirecting you to a Kim Dotcom service to get info about the product?
No, no, no. No thank you. No.

http://dl.cubieboard.org/model/CubieBoard5/CB5%20Resource%20changed%20download%20%20server.txt

That looks like a “Don’t stick your hand in this hole.” sign to me.

If you want a US built SoC, go with the Wandboard by Freescale. Oh,
wait, NXP bought Freescale, that makes it a UK company.

There are lots of affordable armv7 boards from lots of sources. You
want one that has a good uboot development and does not need a custom
kernel like RPi does.

Apache?

Just speculating here, but my sense is that Apache doesn’t care about dates and
times until it gets an HTTP request, in order to handle Expires headers and
such correctly. And, HTTP being stateless, even if an HTTP request comes in so
early that it gives the wrong answer, it should get back on track once the
system clock is fixed.

On the Apache list, I was just told

"There are some parts of the HTTP conversation which could be affected by
having the wrong time, but HTTPD itself doesn't care.
For example, if you are using cookies, caching, those could be affected by the
time change (even more specifically, for PHP sessions, when the clock changes,
the PHP session cleanup handler might think a session is very old and remove
it).”

That pretty much just backs up and amplifies my speculation: strange things
will happen in the window where the clock is wrong, but operations will get on
track quickly without restarting the web server once the clock changes out from
under it.

It is possible that some particular web apps won’t cope nicely, such as because
they keep server time info on the client and then make later stateful
comparisons, but that isn’t about Apache or PHP.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS-virt] Xen C6 kernel 4.9.13 and testing 4.9.15 only reboots.

2017-04-20 Thread Anderson, Dave

Good news/bad news testing the new kernel on CentOS7 with my now notoriously 
finicky machines:

Good news: 4.9.23-26.el7 (grabbed today via yum update) isn't any worse than 
4.9.13-22 was on my xen hosts (as far as I can tell so far at least)

Bad news: It isn't any better than 4.9.13 was for me either, if I don't set 
vcpu limit in the grub/xen config, it still panics like so:

[6.716016] CPU: Physical Processor ID: 0
[6.720199] CPU: Processor Core ID: 0
[6.724046] mce: CPU supports 2 MCE banks
[6.728239] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 8
[6.733884] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0
[6.740770] Freeing SMP alternatives memory: 32K (821a8000 - 
821b)
[6.750638] ftrace: allocating 34344 entries in 135 pages
[6.771888] smpboot: Max logical packages: 1
[6.776363] VPMU disabled by hypervisor.
[6.780479] Performance Events: SandyBridge events, PMU not available due to 
virtualization, using software events only.
[6.792237] NMI watchdog: disabled (cpu0): hardware events not enabled
[6.798943] NMI watchdog: Shutting down hard lockup detector on all cpus
[6.805949] installing Xen timer for CPU 1
[6.810659] installing Xen timer for CPU 2
[6.815317] installing Xen timer for CPU 3
[6.819947] installing Xen timer for CPU 4
[6.824618] installing Xen timer for CPU 5
[6.829282] installing Xen timer for CPU 6
[6.833935] installing Xen timer for CPU 7
[6.838565] installing Xen timer for CPU 8
[6.843110] smpboot: Package 1 of CPU 8 exceeds BIOS package data 1.
[6.849475] [ cut here ]
[6.854091] kernel BUG at arch/x86/kernel/cpu/common.c:997!
[6.855864] random: fast init done
[6.863070] invalid opcode:  [#1] SMP
[6.867088] Modules linked in:
[6.870168] CPU: 8 PID: 0 Comm: swapper/8 Not tainted 4.9.23-26.el7.x86_64 #1
[6.877298] Hardware name: Supermicro X9DRT/X9DRT, BIOS 3.2a 08/04/2015
[6.883920] task: 880058a6a5c0 task.stack: c900400c
[6.889840] RIP: e030:[]  [] 
identify_secondary_cpu+0x57/0x80
[6.898756] RSP: e02b:c900400c3f08  EFLAGS: 00010086
[6.904069] RAX: ffe4 RBX: 88005d80a020 RCX: 81e5ffc8
[6.911201] RDX: 0001 RSI: 0005 RDI: 0005
[6.918335] RBP: c900400c3f18 R08: 00ce R09: 
[6.925466] R10: 0005 R11: 0006 R12: 0008
[6.932599] R13:  R14:  R15: 
[6.939735] FS:  () GS:88005d80() 
knlGS:
[6.947819] CS:  e033 DS: 002b ES: 002b CR0: 80050033
[6.953565] CR2:  CR3: 01e07000 CR4: 00042660
[6.960696] Stack:
[6.962731]  0008  c900400c3f28 
8104ebce
[6.970205]  c900400c3f40 81029855  
c900400c3f50
[6.977691]  810298d0   

[6.985164] Call Trace:
[6.987626]  [] smp_store_cpu_info+0x3e/0x40
[6.993480]  [] cpu_bringup+0x35/0x90
[6.998700]  [] cpu_bringup_and_idle+0x20/0x40
[7.004706] Code: 44 89 e7 ff 50 68 0f b7 93 d2 00 00 00 39 d0 75 1c 0f b7 
bb da 00 00 00 44 89 e6 e8 e4 02 01 00 85 c0 75 07 5b 41 5c 5d c3 0f 0b <0f> 0b 
0f b7 8b d4 00 00 00 89 c2 44 89 e6 48 c7 c7 90 d3 ca 81 
[7.024976] RIP  [] identify_secondary_cpu+0x57/0x80
[7.031528]  RSP 
[7.035032] ---[ end trace f2a8d75941398d9f ]---
[7.039658] Kernel panic - not syncing: Attempted to kill the idle task!

So...other than my work around...that still works...not sure what else I can 
provide in the way of feedback/testing. But if you want anything else gathered, 
let me know.

Thanks,
-Dave

--
Dave Anderson


> On Apr 19, 2017, at 10:33 AM, Johnny Hughes  wrote:
> 
> On 04/19/2017 12:18 PM, PJ Welsh wrote:
>> 
>> On Wed, Apr 19, 2017 at 5:40 AM, Johnny Hughes > > wrote:
>> 
>>On 04/18/2017 12:39 PM, PJ Welsh wrote:
>>> Here is something interesting... I went through the BIOS options and
>>> found that one R710 that *is* functioning only differed in that "Logical
>>> Processor"/Hyperthreading was *enabled* while the one that is *not*
>>> functioning had HT *disabled*. Enabled Logical Processor and the system
>>> starts without issue! I've rebooted 3 times now without issue.
>>> Dell R710 BIOS version 6.4.0
>>> 2x Intel(R) Xeon(R) CPU L5639  @ 2.13GHz
>>> 4.9.20-26.el7.x86_64 #1 SMP Tue Apr 4 11:19:26 CDT 2017 x86_64 x86_64
>>> x86_64 GNU/Linux
>>> 
>> 
>>Outstanding .. I have now released a 4.9.23-26.el6 and .el7 to the
>>system as normal updates.  It should be available later today.
>> 
>>
>> 
>> 
>> I've verified with a second Dell R710 that disabling
>> Hyperthreading/Logical Processor causes the

[CentOS-announce] CESA-2017:1108 Moderate CentOS 7 java-1.8.0-openjdk Security Update


CentOS Errata and Security Advisory 2017:1108 Moderate

Upstream details at : https://rhn.redhat.com/errata/RHSA-2017-1108.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

x86_64:
80f97a5168f5932d27c58307e818fff0d988324cc1ec96256023901efc29e57c  
java-1.8.0-openjdk-1.8.0.131-2.b11.el7_3.i686.rpm
7da72b8c1e26b0ce5d6e1005f1548f0edb8fa8d8c7b1f3c14e4aefb37085  
java-1.8.0-openjdk-1.8.0.131-2.b11.el7_3.x86_64.rpm
ce71df28e9ddc9e2ef20d3b650a6fcb5f7fd85f78b6f1dbd165b124b53a47468  
java-1.8.0-openjdk-accessibility-1.8.0.131-2.b11.el7_3.x86_64.rpm
4d0182588cf632344b640212c7d6af7cd6eec7e9054e4abe29413985319077c8  
java-1.8.0-openjdk-accessibility-debug-1.8.0.131-2.b11.el7_3.x86_64.rpm
468258b25230325f4fefc65cf2cc0ce9981afdc0813353f4ac708fb3a0f6f993  
java-1.8.0-openjdk-debug-1.8.0.131-2.b11.el7_3.i686.rpm
100f04812cfacc3074751a4abe5e3fb7116447c00ed5ac627b274fc07dc22862  
java-1.8.0-openjdk-debug-1.8.0.131-2.b11.el7_3.x86_64.rpm
b15f42135eea22c01a5108a51651785db9c2a6027e15b30df7336ce8195ae52d  
java-1.8.0-openjdk-demo-1.8.0.131-2.b11.el7_3.x86_64.rpm
730b3081be2ab04afd4d749b201ca99baa77f41c06c09afbeb23351bb4d6  
java-1.8.0-openjdk-demo-debug-1.8.0.131-2.b11.el7_3.x86_64.rpm
cc8d180344fa874cbea51e5cd79d80220c5b9ba2a34ebc5807000298e18ecbd3  
java-1.8.0-openjdk-devel-1.8.0.131-2.b11.el7_3.i686.rpm
b7ae364e5b7634782da6695433ff505b9d8c7fcbfa971591d3bbaca464ff39a9  
java-1.8.0-openjdk-devel-1.8.0.131-2.b11.el7_3.x86_64.rpm
63f3e239c453cf668521dacbc94bbc67001b10864c57a0bd83305630299dd3c5  
java-1.8.0-openjdk-devel-debug-1.8.0.131-2.b11.el7_3.i686.rpm
b4a5f6a1c91c695beecc2096e8c212a5e5fb8ed2698b64eae5ec7793525c1f0c  
java-1.8.0-openjdk-devel-debug-1.8.0.131-2.b11.el7_3.x86_64.rpm
1dfb5b727a67525c934304ebbee7a08745693734d523f8d71e95b3d99c2a748d  
java-1.8.0-openjdk-headless-1.8.0.131-2.b11.el7_3.i686.rpm
a7e0b5f42dc24e0e240a543c692b9a402cd3e187c246371435f5e67ea58fe5ae  
java-1.8.0-openjdk-headless-1.8.0.131-2.b11.el7_3.x86_64.rpm
e7b5333038c1c9c0fe6d095f7b90f53f45960b73717eb083043962e5bf7a306a  
java-1.8.0-openjdk-headless-debug-1.8.0.131-2.b11.el7_3.i686.rpm
723f5060b6d63f64ebd1b0161dae4b1cd834ae7b7b4c4837b9565e3753ca189f  
java-1.8.0-openjdk-headless-debug-1.8.0.131-2.b11.el7_3.x86_64.rpm
0804c823721fedc0b9852b6d9603ae233d3a678174a4d897a490b7a2e2ceaf83  
java-1.8.0-openjdk-javadoc-1.8.0.131-2.b11.el7_3.noarch.rpm
4b6d9e2df4cd9bfc39d2d0fd27bf7ed722c111e9d031c0f29ab8019fd7610ccc  
java-1.8.0-openjdk-javadoc-debug-1.8.0.131-2.b11.el7_3.noarch.rpm
65fbfe6c7733aeec5c5b8edce9121f081a14a33ac65af9660e5ce9cfe49be84d  
java-1.8.0-openjdk-javadoc-zip-1.8.0.131-2.b11.el7_3.noarch.rpm
3bf4903901e52a6303dc72e1bcfc8e33b50c8a1c66ac2769228aec0784132388  
java-1.8.0-openjdk-javadoc-zip-debug-1.8.0.131-2.b11.el7_3.noarch.rpm
5d1f88e3b95d9f4a2403f9544045baf92cff53e2123e0d92bf4dd2141e157537  
java-1.8.0-openjdk-src-1.8.0.131-2.b11.el7_3.x86_64.rpm
141f62c2952d839b2b0e24f7789c73d4bdfa7b9bbd23634d9054baf1e8c10fbb  
java-1.8.0-openjdk-src-debug-1.8.0.131-2.b11.el7_3.x86_64.rpm

Source:
eaac4898178a36c4003be40b7c98c38a7572baa31b52aab5f5e90845202039b4  
java-1.8.0-openjdk-1.8.0.131-2.b11.el7_3.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS

___
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce

[CentOS-announce] CESA-2017:1106 Critical CentOS 7 firefox Security Update


CentOS Errata and Security Advisory 2017:1106 Critical

Upstream details at : https://rhn.redhat.com/errata/RHSA-2017-1106.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

x86_64:
db9f358d231c95b7443d58e8a92b90d5bf9f24cd5f2641c3262271cb13aa4ecb  
firefox-52.1.0-2.el7.centos.i686.rpm
6f191762164e4cf5b54b7a0b4026d78c69e0073abf331840572accd09341a78c  
firefox-52.1.0-2.el7.centos.x86_64.rpm

Source:
90270668303aceb8ffec03143491fee0c4e5fb5245655a37f11188560878b434  
firefox-52.1.0-2.el7.centos.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS

___
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce

[CentOS-announce] CESA-2017:1100 Critical CentOS 7 nss Security Update


CentOS Errata and Security Advisory 2017:1100 Critical

Upstream details at : https://rhn.redhat.com/errata/RHSA-2017-1100.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

x86_64:
7c0e9cbeacb07e7d2868f2f364527ff71816cdfef0dc18474e05db16e57e25e7  
nss-3.28.4-1.0.el7_3.i686.rpm
86968563fe276b36b88f07fa11f06c3366a9a96b20c4b2691338748f649f3d4d  
nss-3.28.4-1.0.el7_3.x86_64.rpm
f065aa53f66548495a2130e280fc14dc8b8f8a076bd7bade3425adac88f77d36  
nss-devel-3.28.4-1.0.el7_3.i686.rpm
caea2c9dc2ca247bb9042124d7d6a60ce4f02d71af28a5e069d60525f80b6740  
nss-devel-3.28.4-1.0.el7_3.x86_64.rpm
385f200523e2720d9f250fd3149a471f1f02f5cc55dfae5ac50090a89eab499b  
nss-pkcs11-devel-3.28.4-1.0.el7_3.i686.rpm
ed301c352dabeb127f12decacc3d6639372357dc7673de463ea590773bae3ff6  
nss-pkcs11-devel-3.28.4-1.0.el7_3.x86_64.rpm
7c82dbe83f51d6505d368d68535fd34da2da0efc52c3115612011ef791c5bbc6  
nss-sysinit-3.28.4-1.0.el7_3.x86_64.rpm
fe1d1425aaebb108851540d27337613f169db30ddbdccb336b79d4dc0197eea0  
nss-tools-3.28.4-1.0.el7_3.x86_64.rpm

Source:
8031fd77de059ce3786fb98712737a9e9e83a8e4e29e8071050ce90ae4a1cb53  
nss-3.28.4-1.0.el7_3.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS

___
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce

[CentOS-announce] CESA-2017:1100 Critical CentOS 7 nss-util Security Update


CentOS Errata and Security Advisory 2017:1100 Critical

Upstream details at : https://rhn.redhat.com/errata/RHSA-2017-1100.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

x86_64:
847b8da43f05a5f24b81b01efbc991e70c5d2c9c659f6bd9feb420bbfe59ba5e  
nss-util-3.28.4-1.0.el7_3.i686.rpm
f23201ad7af7e0d5105bbde62ea32c2a10b62cfd1cdce92fe904306bdfb4ae43  
nss-util-3.28.4-1.0.el7_3.x86_64.rpm
78199e2871b2b385458ff852b1609f7c46f71a2a7133ee885f153a3ffc5fc715  
nss-util-devel-3.28.4-1.0.el7_3.i686.rpm
c26d927e1604c5fc1ab7b5499e96e83d356eee25e3d560e96d60c612891bffa1  
nss-util-devel-3.28.4-1.0.el7_3.x86_64.rpm

Source:
df5fc54dc4fa11167312e53541dc2334c45398132b61f879f1dc2a27cd55f436  
nss-util-3.28.4-1.0.el7_3.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS

___
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce

[CentOS-announce] CESA-2017:1109 Moderate CentOS 6 java-1.8.0-openjdk Security Update


CentOS Errata and Security Advisory 2017:1109 Moderate

Upstream details at : https://rhn.redhat.com/errata/RHSA-2017-1109.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
9224c888761f388ca9a3664dc0b1fb0dcc3904e7462fba3a482d1ecc6ee77285  
java-1.8.0-openjdk-1.8.0.131-0.b11.el6_9.i686.rpm
5d0ca0b600d8fe739ac51de1f09882abbc66493cf8e3aff50f0fc8e6717efd78  
java-1.8.0-openjdk-debug-1.8.0.131-0.b11.el6_9.i686.rpm
e2fe48b3835fb57826354c3266a3ab70236edbbb9b352e0abed5bc4732414f32  
java-1.8.0-openjdk-demo-1.8.0.131-0.b11.el6_9.i686.rpm
26f7cb4cd650f0caae18cfcf6945d1aa8fc3bbb35031158f6b0e69d4b233db50  
java-1.8.0-openjdk-demo-debug-1.8.0.131-0.b11.el6_9.i686.rpm
a21257bb46833259d5368a8824d052732889359195a298cebd46302991e8f5b9  
java-1.8.0-openjdk-devel-1.8.0.131-0.b11.el6_9.i686.rpm
548d135b874f032c96707ee87c9625f572c88768f8c76b4f7eb09830da802cb2  
java-1.8.0-openjdk-devel-debug-1.8.0.131-0.b11.el6_9.i686.rpm
fd096a0b691c2a5404eb1cffd7948d9a67c4eb22d5cf5524bc74ecc35251f63b  
java-1.8.0-openjdk-headless-1.8.0.131-0.b11.el6_9.i686.rpm
4a75f1a3ce60d1a5a8005e89718dbdf77237bcea549bea9c54c0b72b8ed9ef61  
java-1.8.0-openjdk-headless-debug-1.8.0.131-0.b11.el6_9.i686.rpm
4cd56647098db901ef2159069b5aabb8abc78e03e76ade03d2aaaf8f1b3026ae  
java-1.8.0-openjdk-javadoc-1.8.0.131-0.b11.el6_9.noarch.rpm
e27d648018256c24242169e0daf40570c51f2ff159d459e9b5faebfd4f31067f  
java-1.8.0-openjdk-javadoc-debug-1.8.0.131-0.b11.el6_9.noarch.rpm
eb4c6af473dc4144f158ca93b573581922dbdc78f11d5fb7ad91d13bb332653a  
java-1.8.0-openjdk-src-1.8.0.131-0.b11.el6_9.i686.rpm
e31cf76f7bb1463ff56dc41b50da9d8507269c060241b267a4b72a30dd0f1b28  
java-1.8.0-openjdk-src-debug-1.8.0.131-0.b11.el6_9.i686.rpm

x86_64:
60467c3d0eb329d8015666908ff1f69bb3fe4cf7b366ffd05fd746cadb91d95d  
java-1.8.0-openjdk-1.8.0.131-0.b11.el6_9.x86_64.rpm
407ad1c6c24fe83a6cf64b9db8913c75aaf4d09ca22c9c24e328a941f085b883  
java-1.8.0-openjdk-debug-1.8.0.131-0.b11.el6_9.x86_64.rpm
8369296dfd96ce334763ba5c8ffd509e7643f5d2605b769ff36f09a5a21ab1a0  
java-1.8.0-openjdk-demo-1.8.0.131-0.b11.el6_9.x86_64.rpm
610ad62174d70e2eb79b7b70696ea4f53c093215769c78999dbccb15f774b6db  
java-1.8.0-openjdk-demo-debug-1.8.0.131-0.b11.el6_9.x86_64.rpm
7f296719610ee8b1abd3fcc7dc9f5f62420a2ed721c816ce853322670ba37bde  
java-1.8.0-openjdk-devel-1.8.0.131-0.b11.el6_9.x86_64.rpm
1b213bfaee59e5313dbbd12045eb6a06c4ea7bc2ec85080c67964635e8f59b83  
java-1.8.0-openjdk-devel-debug-1.8.0.131-0.b11.el6_9.x86_64.rpm
4ce2d2b8112ed815ecbfd996c3bf50feb811f1d7ce0ff7037f64755fd6d3ff31  
java-1.8.0-openjdk-headless-1.8.0.131-0.b11.el6_9.x86_64.rpm
71e150cb4271c56d20bbed3f889dca93e47352a5d7c9ce88188ea1b45ba93daf  
java-1.8.0-openjdk-headless-debug-1.8.0.131-0.b11.el6_9.x86_64.rpm
4cd56647098db901ef2159069b5aabb8abc78e03e76ade03d2aaaf8f1b3026ae  
java-1.8.0-openjdk-javadoc-1.8.0.131-0.b11.el6_9.noarch.rpm
e27d648018256c24242169e0daf40570c51f2ff159d459e9b5faebfd4f31067f  
java-1.8.0-openjdk-javadoc-debug-1.8.0.131-0.b11.el6_9.noarch.rpm
738543c7d856135299d617c17085a8c53a31302ed6e49ca788549fd2aeb15c18  
java-1.8.0-openjdk-src-1.8.0.131-0.b11.el6_9.x86_64.rpm
2285a49c613009229265ee4e566a23fb6426c21b17390baa5a30adcf15e2068e  
java-1.8.0-openjdk-src-debug-1.8.0.131-0.b11.el6_9.x86_64.rpm

Source:
6c902637907443fe1ac219a230978d42296894dafa8b4fd8cc3b5df6324e00bd  
java-1.8.0-openjdk-1.8.0.131-0.b11.el6_9.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS

___
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce

[CentOS-announce] CESA-2017:1104 Critical CentOS 6 firefox Security Update


CentOS Errata and Security Advisory 2017:1104 Critical

Upstream details at : https://rhn.redhat.com/errata/RHSA-2017-1104.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
da7e0a3b2f6cc4703c95b34c6cc75b2815e4ae5035bef6ef56d052c625cc3eaa  
firefox-52.1.0-2.el6.centos.i686.rpm

x86_64:
da7e0a3b2f6cc4703c95b34c6cc75b2815e4ae5035bef6ef56d052c625cc3eaa  
firefox-52.1.0-2.el6.centos.i686.rpm
c5d308fb577cb57882c9478a0b7d1c85bbd63ca411399ee4cb3d8bc0af960973  
firefox-52.1.0-2.el6.centos.x86_64.rpm

Source:
583ca21ee5e6610c077d0671fba0bd4bb0f1117e1115faf4468b8fb44c7f5049  
firefox-52.1.0-2.el6.centos.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS

___
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce

[CentOS-announce] CESA-2017:1105 Important CentOS 6 bind Security Update


CentOS Errata and Security Advisory 2017:1105 Important

Upstream details at : https://rhn.redhat.com/errata/RHSA-2017-1105.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
266ff64660c075b7bfb17bbf4d4c356ff3ccdd119f35a129ae133cc44a69ea6c  
bind-9.8.2-0.62.rc1.el6_9.1.i686.rpm
888eb9b8a3cb22ebc9b0a3f4b6506921b87ee43a15e6fda781341330151dc3cb  
bind-chroot-9.8.2-0.62.rc1.el6_9.1.i686.rpm
d8858c4a806579f9054d7a037fb073089f67e4785878fc56970ce7380e9bb898  
bind-devel-9.8.2-0.62.rc1.el6_9.1.i686.rpm
b38c21b53129c69466455a59c955ffafcf8bbae05ffb32b96f9a7ff0e11ff666  
bind-libs-9.8.2-0.62.rc1.el6_9.1.i686.rpm
14fef0f86fa4b1dc16744c455212f0898ce499469ff78ad3be09fed7d83e6b9b  
bind-sdb-9.8.2-0.62.rc1.el6_9.1.i686.rpm
fc6060564bf23ed602d04029964e92e6c9eaec7bdfc3699fb8fb70f83e3301bf  
bind-utils-9.8.2-0.62.rc1.el6_9.1.i686.rpm

x86_64:
71e75001dd78f3d3289a8fa1dee4b0732b91367f016ff7a4ed18d7ffe57d76ee  
bind-9.8.2-0.62.rc1.el6_9.1.x86_64.rpm
4e91a4f03ed4e735bac48da9baddc23b1d02c4c090cf450f7eb4a6f807d38d13  
bind-chroot-9.8.2-0.62.rc1.el6_9.1.x86_64.rpm
d8858c4a806579f9054d7a037fb073089f67e4785878fc56970ce7380e9bb898  
bind-devel-9.8.2-0.62.rc1.el6_9.1.i686.rpm
bb151b30485f3ada32fce9f174aa9062109ad18e548f8c3d2dc56ae3cc87183c  
bind-devel-9.8.2-0.62.rc1.el6_9.1.x86_64.rpm
b38c21b53129c69466455a59c955ffafcf8bbae05ffb32b96f9a7ff0e11ff666  
bind-libs-9.8.2-0.62.rc1.el6_9.1.i686.rpm
d83ffedf34e95f4cf8b5bf1c663e1a5b558f0216ac72f961caaf68464eacd66b  
bind-libs-9.8.2-0.62.rc1.el6_9.1.x86_64.rpm
9427eeecce239e8fa449d6a10a1859e53d283c9322751db9aa63aad04578f234  
bind-sdb-9.8.2-0.62.rc1.el6_9.1.x86_64.rpm
72d554da0c64568336b159232f3e408a45716c32aa41c4c7c8b4fed0a26fe40e  
bind-utils-9.8.2-0.62.rc1.el6_9.1.x86_64.rpm

Source:
111d7cd4e4965321ccee94526fe79629709da816ca6ee47832c44807320883b9  
bind-9.8.2-0.62.rc1.el6_9.1.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS

___
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce

[CentOS-announce] CESA-2017:1100 Critical CentOS 6 nss Security Update


CentOS Errata and Security Advisory 2017:1100 Critical

Upstream details at : https://rhn.redhat.com/errata/RHSA-2017-1100.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
5821f235b991ffcd273006c24ca9d3e1daf4b6e3228ce7dcb97c24de5b21de41  
nss-3.28.4-1.el6_9.i686.rpm
9688f7b58816ab0192210a2ef4c138139083abcdb842ee4f5f8e89847649d610  
nss-devel-3.28.4-1.el6_9.i686.rpm
67bbf48d70115e4596bba46853e35e41510e04f76916e676821e953f4abe41b3  
nss-pkcs11-devel-3.28.4-1.el6_9.i686.rpm
c6e3ea1c22bfc39fd3d8872bf890acfd444b8e27342243c9310477a39e5a1b6b  
nss-sysinit-3.28.4-1.el6_9.i686.rpm
8e9dc735e1af62d3e6dac0c5997735e19c2e864d78d4a0050d55cf263edfe928  
nss-tools-3.28.4-1.el6_9.i686.rpm

x86_64:
5821f235b991ffcd273006c24ca9d3e1daf4b6e3228ce7dcb97c24de5b21de41  
nss-3.28.4-1.el6_9.i686.rpm
a82f4e54a89d9b8923fe457130bf4e7aefc0b9d506716eb1ead0db9fa2b8714a  
nss-3.28.4-1.el6_9.x86_64.rpm
9688f7b58816ab0192210a2ef4c138139083abcdb842ee4f5f8e89847649d610  
nss-devel-3.28.4-1.el6_9.i686.rpm
9d9721cdbb202bd30503872b8a2e80f94cd63a38aba666449fe27dda4cc616dd  
nss-devel-3.28.4-1.el6_9.x86_64.rpm
67bbf48d70115e4596bba46853e35e41510e04f76916e676821e953f4abe41b3  
nss-pkcs11-devel-3.28.4-1.el6_9.i686.rpm
f8a915c0d9066123ac1371f559dee7acd48f506ff69e976af11952b623b35201  
nss-pkcs11-devel-3.28.4-1.el6_9.x86_64.rpm
d3d0d749646b8a0d1a198ac9dc15cfe39b0c9103055fe2d10f5db4971a6bb866  
nss-sysinit-3.28.4-1.el6_9.x86_64.rpm
6e7a942c903ded2beadf2744a0f6ddacfd1b92e482396209358b2c4b2d691af9  
nss-tools-3.28.4-1.el6_9.x86_64.rpm

Source:
f3d57fbec19b0a79e88bedf659868d173f34a651a42313ddc600b0ce420aef47  
nss-3.28.4-1.el6_9.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS

___
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce

[CentOS-announce] CESA-2017:1100 Critical CentOS 6 nss-util Security Update


CentOS Errata and Security Advisory 2017:1100 Critical

Upstream details at : https://rhn.redhat.com/errata/RHSA-2017-1100.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
09d5ded637588ded6406eafe69a19b13d981a8bf945ada12894da1a0d21d376f  
nss-util-3.28.4-1.el6_9.i686.rpm
fcc501f2c221dab92c66ba05ee5ad80ad5894984a5423d7db58020165cc0b45b  
nss-util-devel-3.28.4-1.el6_9.i686.rpm

x86_64:
09d5ded637588ded6406eafe69a19b13d981a8bf945ada12894da1a0d21d376f  
nss-util-3.28.4-1.el6_9.i686.rpm
62d946e014cfbfb7cc657a58295a8f27b11043f2136edf91126b3ff467400c85  
nss-util-3.28.4-1.el6_9.x86_64.rpm
fcc501f2c221dab92c66ba05ee5ad80ad5894984a5423d7db58020165cc0b45b  
nss-util-devel-3.28.4-1.el6_9.i686.rpm
515fd89043687a0cf6f40271d36ebfb34d27bd8304d8027e70b168d110fb81d5  
nss-util-devel-3.28.4-1.el6_9.x86_64.rpm

Source:
0667ca1376b6eca9ae5b4b0c5745d5ae9801227458afe5c43fab9422908f8763  
nss-util-3.28.4-1.el6_9.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS

___
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce

Re: [CentOS] What besides Postfix should not start until system time set?

On 04/20/2017 06:17 PM, Warren Young wrote:

On Apr 20, 2017, at 3:39 PM, Robert Moskowitz wrote:

On 04/20/2017 05:16 PM, Warren Young wrote:

On Apr 20, 2017, at 3:00 PM, Robert Moskowitz wrote:

So I have learned that Postfix should delay until Chronyd has moved the system
time from 0 to current.

I think it’s more the case that CentOS is written with the assumption that
you’re running it on a host with a battery-backed RTC

It is the Centos7 for arm SOCs. RPi is one of the worst (in my opinion) of
these.

So you picked an alternative that cites “server stability” when explaining why
they’re redirecting you to a Kim Dotcom service to get info about the product?
No, no, no. No thank you. No.

http://dl.cubieboard.org/model/CubieBoard5/CB5%20Resource%20changed%20download%20%20server.txt

That looks like a “Don’t stick your hand in this hole.” sign to me.

I got mine from a US supplier:

http://www.iotllc.com

Fedora-arm and Centos-arm developers use the Cubietruck. FWW.

Apache?

On the Apache list, I was just told

To delay httpd is no biggie. To delay bind is a no-no. To delay
Postfix, apparently, is important.

There seems to be a way with the chronyd -s option to use the timestamp
on the driftfile. I need to look more into that.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] What besides Postfix should not start until system time set?

On Apr 20, 2017, at 3:39 PM, Robert Moskowitz  wrote:
> 
> On 04/20/2017 05:16 PM, Warren Young wrote:
>> On Apr 20, 2017, at 3:00 PM, Robert Moskowitz  wrote:
>>> So I have learned that Postfix should delay until Chronyd has moved the 
>>> system time from 0 to current.
>> I think it’s more the case that CentOS is written with the assumption that 
>> you’re running it on a host with a battery-backed RTC
> 
> It is the Centos7 for arm SOCs.  RPi is one of the worst (in my opinion) of 
> these.

So you picked an alternative that cites “server stability” when explaining why 
they’re redirecting you to a Kim Dotcom service to get info about the product?  
No, no, no.  No thank you.  No.

http://dl.cubieboard.org/model/CubieBoard5/CB5%20Resource%20changed%20download%20%20server.txt

That looks like a “Don’t stick your hand in this hole.” sign to me.

>>> Apache?
>> Just speculating here, but my sense is that Apache doesn’t care about dates 
>> and times until it gets an HTTP request, in order to handle Expires headers 
>> and such correctly. And, HTTP being stateless, even if an HTTP request comes 
>> in so early that it gives the wrong answer, it should get back on track once 
>> the system clock is fixed.
> 
> On the Apache list, I was just told
> 
> "There are some parts of the HTTP conversation which could be affected by 
> having the wrong time, but HTTPD itself doesn't care.
> For example, if you are using cookies, caching, those could be affected by 
> the time change (even more specifically, for PHP sessions, when the clock 
> changes, the PHP session cleanup handler might think a session is very old 
> and remove it).”

That pretty much just backs up and amplifies my speculation: strange things 
will happen in the window where the clock is wrong, but operations will get on 
track quickly without restarting the web server once the clock changes out from 
under it.

It is possible that some particular web apps won’t cope nicely, such as because 
they keep server time info on the client and then make later stateful 
comparisons, but that isn’t about Apache or PHP.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

On Apr 20, 2017, at 7:33 AM, James B. Byrne  wrote:
> 
> When a vendor ... fundamentally changes the way the administration
> of an operating system is presented

I’ve gotten the sense from this other part of the thread that the answer to my 
question, “What are you moving to?” is FreeBSD.

If you think FreeBSD system administration hasn’t changed over the past 10 
years, you must not have been using it that long.  What makes you think it 
won’t change again in the next 10 years, possibly in very large breaking ways?

> vanishingly few firms in my
> experience (i.e.NONE) have ever had operational programming staff
> write or even modify a device driver.

My company is very small.  I’ve modified device drivers to make them work 
properly on Linux, purely in a “scratch my own itch” kind of way.

I assure, you, many larger organizations also do this or something similar.  
Netflix is famous for using FreeBSD on their streaming servers and for tuning 
the FreeBSD kernel heavily for that purpose.

> A business is in existence to
> make money for its owners not dick around with esoteric computer
> theory and practice.

I’m not glorifying change for its own sake.  I’m just saying it happens, and 
however inessential it may be to your business’ operations is really not 
on-point.  The fact is that it happens everywhere in this industry, so your 
only choice is in which bag of changes you want to deal with, not whether you 
get a bag of changes.

> The idea that one has to rebuild from scratch entire host systems and
> then laboriously port over data and customised portions to a new host
> simply to upgrade the underlying OS is absolutely ludicrous.

I find that most hardware is ready to fall over by the time the CentOS that was 
installed on it drops out of support anyway.

That is to say, I think the right way to use CentOS is to install one major 
version on the hardware when it’s built, and then ride it for the 7-10 years 
until that OS version drops out of support.  (7 being the worst case, when you 
install a new system jst before the next major OS version comes out.)

Then there’s all the change that is outside the OS proper.  For example, 
there’s all the current changes in the way encryption is handled, which would 
require operational changes anyway.  You can’t keep running BIND 4 on your 
public-facing DNS servers, for example, even if all the security problems were 
somehow fixed without changing any user interface.

Ditto mail, HTTP, and many other critical services, since old versions often 
don’t even speak today’s required protocols.  (TLS 1.1 minimum, DMARC, DKIM, 
SPF, etc.)

FreeBSD, this supposed bastion of stability, now actively discourages you from 
using BIND in the first place, for example.  Now they want you to migrate to 
NSD + Unbound.  Oh noes, more change!

> Consider
> the tremendous labour costs regularly incurred in accomplishing what
> amounts to maintaining the status quo.

If you only wanted the status quo ante, why upgrade at all?

Obvious answer: because you actually do want *some* change.

> We just upgraded a FreeBSD host from 10.3 to 11.0 in situ without
> problem

Lucky you.  I’ve had such upgrades take a system out for a day, working around 
all the breakages.

Upgrading FreeBSD is historically one of the most painful things about it.  
It’s getting better, but only by changing how everything about packaging was 
done.  Holy ChangeLogs, Batman!

Don’t get the wrong idea that I don’t like FreeBSD, by the way.  I know these 
things about it because I use it regularly.  This is one of those “bags of 
changes” I referred to above.  Sometimes I want the Linux bag, and sometimes I 
want the FreeBSD bag, and I know going into the decision that each bag implies 
a future bag of changes I’ll have to deal with.

> It was the OS running the metal for multiple BHyve virtual machines

Ah, more change.  Bhyve only goes back to FreeBSD 10, so if you were using 
FreeBSD prior to that, you’d have had to either drag forward whatever VM 
manager you were using or migrate to bhyve.

> given we use ZFS in FreeBSD, and that we snapshot regularly, getting
> back to 10.3 would have been, and still could be, nearly
> instantaneous.

That’s a great reason to pick FreeBSD.  Just don’t fool yourself that by 
switching that you’ve somehow gotten off the upgrade treadmill.  You’ve only 
switched bags.

> Systemd is not the problem.  It
> is a symptom of a deeper malaise, indifference.

systemd offers benefits to certain classes of end users which could not have 
been achieved without *some* kind of change.

We can argue about how well systemd did its job — I share many of the negative 
opinions about it — but I think you’ll have a very tough time convincing me 
that we could have gotten all the benefits without changing the user interface.

Again it comes back to the bag of features: if you didn’t want any of the 
features systemd brought, then you may be right to abandon

Re: [CentOS] What besides Postfix should not start until system time set?




On 04/20/2017 05:16 PM, Warren Young wrote:

On Apr 20, 2017, at 3:00 PM, Robert Moskowitz  wrote:

So I have learned that Postfix should delay until Chronyd has moved the system 
time from 0 to current.

I think it’s more the case that CentOS is written with the assumption that 
you’re running it on a host with a battery-backed RTC, so that system time 
isn’t wildly off at boot time.  This includes VMs, since the VM host should 
pass its RTC through to the VM.

What are you running CentOS on that doesn’t have this property?


It is the Centos7 for arm SOCs.  RPi is one of the worst (in my opinion) 
of these.  See:


http://medon.htt-consult.com/arm.html



The only such system I can think of which will also run CentOS is the Raspberry 
Pi 3. They dropped the battery-backed RTC in the name of cost savings and that 
most Pi boards are network-connected, so they can get Internet time soon after 
boot.  But yeah, there is a small window...


What other services need to be delayed?

I can only speculate.  But take the above as a warning: lots of other software 
may assume sane system time at startup.  Short of a massive code audit or your 
present “canvass the audience” approach, I don’t know how you find out which 
ones.


Apache?

Just speculating here, but my sense is that Apache doesn’t care about dates and 
times until it gets an HTTP request, in order to handle Expires headers and 
such correctly. And, HTTP being stateless, even if an HTTP request comes in so 
early that it gives the wrong answer, it should get back on track once the 
system clock is fixed.


On the Apache list, I was just told

"There are some parts of the HTTP conversation which could be affected 
by having the wrong time, but HTTPD itself doesn't care.
For example, if you are using cookies, caching, those could be affected 
by the time change (even more specifically, for PHP sessions, when the 
clock changes, the PHP session cleanup handler might think a session is 
very old and remove it)."






Bind?

Similar to Apache, due to cache expiration rules.  Since “now” minus time_t(0) 
is $bignum, that means as soon as the system clock is fixed, it will expire all 
the info it learned in the time the clock was wrong, and any info it gave out 
with start time equal to 0 + epsilon will expire immediately in clients’ DNS 
caches.

Since so much other software depends on having a local DNS server early in 
their startup, I would definitely not delay BIND startup on any machine where 
the local DNS configuration points to localhost.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Chrome version 28 for CentOS 6 or last official version that worked on C6

2017-04-20 Thread Leon Fauster

> Am 20.04.2017 um 22:42 schrieb Jerry Geis :
> 
> Anyone know where I can download version 28 of chrome for C6?
> 
> I know there are "other" ways to get the latest... and install on C6...
> I know version 28 is old and unsupported and all that...
> 
> But that is what I need.
> 
> I think it was the last official build that worked on C6 "as is".
> 
> Thanks for your help.
> 


https://people.centos.org/hughesjr/chromium/6/x86_64/RPMS/


--
LF


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] What besides Postfix should not start until system time set?

On Apr 20, 2017, at 3:00 PM, Robert Moskowitz  wrote:
> 
> So I have learned that Postfix should delay until Chronyd has moved the 
> system time from 0 to current.

I think it’s more the case that CentOS is written with the assumption that 
you’re running it on a host with a battery-backed RTC, so that system time 
isn’t wildly off at boot time.  This includes VMs, since the VM host should 
pass its RTC through to the VM.

What are you running CentOS on that doesn’t have this property?

The only such system I can think of which will also run CentOS is the Raspberry 
Pi 3. They dropped the battery-backed RTC in the name of cost savings and that 
most Pi boards are network-connected, so they can get Internet time soon after 
boot.  But yeah, there is a small window...

> What other services need to be delayed?

I can only speculate.  But take the above as a warning: lots of other software 
may assume sane system time at startup.  Short of a massive code audit or your 
present “canvass the audience” approach, I don’t know how you find out which 
ones.

> Apache?

Just speculating here, but my sense is that Apache doesn’t care about dates and 
times until it gets an HTTP request, in order to handle Expires headers and 
such correctly. And, HTTP being stateless, even if an HTTP request comes in so 
early that it gives the wrong answer, it should get back on track once the 
system clock is fixed.

> Bind?

Similar to Apache, due to cache expiration rules.  Since “now” minus time_t(0) 
is $bignum, that means as soon as the system clock is fixed, it will expire all 
the info it learned in the time the clock was wrong, and any info it gave out 
with start time equal to 0 + epsilon will expire immediately in clients’ DNS 
caches.

Since so much other software depends on having a local DNS server early in 
their startup, I would definitely not delay BIND startup on any machine where 
the local DNS configuration points to localhost.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] What besides Postfix should not start until system time set?

2017-04-20 Thread Alice Wonder


On 04/20/2017 02:00 PM, Robert Moskowitz wrote:

So I have learned that Postfix should delay until Chronyd has moved the
system time from 0 to current.

What other services need to be delayed?


Apache?
Bind?

Of course if this is a nameserver, Chronyd will probably not be able to
resolve the NTP server addresses until Bind is running!

thanks


I use unbound on all my servers listening only on the localhost, not 
sure if it needs the current time to be accurate when it starts or not 
but it never seems to be an issue.


I'm of the opinion every server should have locally provided DNSSEC 
enforcing DNS services simply because it takes away a potential attack 
vector to have local DNS queries stay local.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] What besides Postfix should not start until system time set?

So I have learned that Postfix should delay until Chronyd has moved the 
system time from 0 to current.


What other services need to be delayed?


Apache?
Bind?

Of course if this is a nameserver, Chronyd will probably not be able to 
resolve the NTP server addresses until Bind is running!


thanks

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Chrome version 28 for CentOS 6 or last official version that worked on C6

2017-04-20 Thread Jerry Geis

Anyone know where I can download version 28 of chrome for C6?

I know there are "other" ways to get the latest... and install on C6...
I know version 28 is old and unsupported and all that...

But that is what I need.

I think it was the last official build that worked on C6 "as is".

Thanks for your help.

jerry
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

On Apr 19, 2017, at 2:22 PM, Chris Murphy  wrote:
> 
> On Wed, Apr 19, 2017 at 5:21 AM, James B. Byrne  wrote:
>> 
>> On Mon, April 17, 2017 17:13, Warren Young wrote:
>> 
>>> Also, Iâ€™ll remind the list that one of the *prior* times the systemd
>>> topic came up, I was the one reminding people that most of our jobs
>>> summarize as â€œCope with change.â€
>> 
>> At some point 'coping with change' is discovered to consume a
>> disproportionate amount of resources for the benefits obtained…Linux
>> does not meet our business needs.
> 
> Apple has had massively disruptive changes on OS X and iOS. Windows
> has had a fairly disruptive set of changes in Windows 10.

…And FreeBSD finally just got through the whole binary-package-everything 
phase, meaning installation and upgrade practices have changed almost entirely 
in the past few years.  And before that, there was “move everything to ZFS,” 
which totally changed file system management, the boot system, backups, at-rest 
data encryption, file sharing services, and more.

The other BSDs haven’t had as much change, but that’s both bad and good.

Solaris has had mighty shakeups in the past 10 so years, much before the Oracle 
buyout and much more after.

So what is Harte & Lyne Limited moving *to*?

> the Linux community appears to have a
> change-for-change-sake fetish.

Are you seriously saying that none of the change in the Linux world in the past 
10 years has had any practical benefit?

The only such charge that immediately comes to mind for me is this move in the 
past 5 years or so to “flat” user interfaces, led by the mobile world but 
infecting desktop OSes as well…but not Linux.  If Linux were doing change for 
change’s sake, wouldn’t Linux have flattened its UIs like Google, Apple, and 
Microsoft have?

I wonder if what you’d actually prefer is magical levels of foresight, so that 
we could have made all the change required 30, 40 years ago, and now just be 
riding on top of perfect stability?

Or is is that you think the *ix world already had perfection and lost it?  What 
was the perfect OS, what version, and does it still run your apps today?  Will 
it still run them 10 years from now?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Solved - Re: startup process that rebuilds aliases.db?


Got what I needed from the chronyd list

On 04/20/2017 10:00 AM, Robert Moskowitz wrote:
My Centos7 system does not have a battery for the clock (like most 
armv7 SOCs), thus I rely on that at some point in boot time, chronyd 
sets the time.  If a file is updated prior to chronyd accomplishing 
its task (or network connectivity is down), the file ends up with a 
timestamp of "Dec 31  1969".


I notice that occasionally, after a reboot, /etc/aliases.db reverts to 
this time, and I have to run newaliases to fix it.  I suppose I could 
run touch as well.


What process could be rebuilding aliases.db?  Postfix list says it 
isn't them.


How, after chronyd, can I insure the date on aliases.db is not back to 0?

Yes, this is just a warning message in maillog, but annoying.


"The recommended way to delay start of a service until the clock is
synchronized is to add "After=time-sync.target" to its unit file and
enable the chrony-wait service. It uses the chronyc waitsync command
to delay the time-sync target."


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

2017-04-20 Thread Jonathan Billings

On Thu, Apr 20, 2017 at 09:33:30AM -0400, James B. Byrne wrote:
> Red Hat, again in my sole opinion, increasingly appears to me to be
> emulating another company notorious for shuffling the user interface
> to little evident purpose other than profit.  That is good business
> for them.  It is not good for us.

>From my perspective as a Red Hat customer who supports hundreds of
RHEL7 Workstation systems, Red Hat really doesn't seem to care or test
their Workstation product.  Their support doesn't seem to have much
training when it comes to problems with the GUI.  Since GNOME itself
moves along at a much faster pace than RHEL, I always end up looking
for archives of documentation, and trawling through GNOME's bugzilla.

Red Hat makes its business on the Server side.  They don't really care
about graphical user interfaces apart from the installer.

-- 
Jonathan Billings 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

2017-04-20 Thread Pete Biggs


> 
> Think about what that would take in terms of man hours to accomplish
> moving from EL6 to 7.  And moving from 5 to 6 was not much better. 
> This is just too expensive to repeat every three years.

So why do it? There is absolutely nothing wrong with sticking with EL6
for a long time, certainly for the lifetime of the hardware - EL5 has
only just gone EoL, and if you pay RH you can still have it on support.
 Just because EL7 exists, it doesn't mean that you have to upgrade to
it. I've only just started to seriously roll out CentOS7, and then
mostly only on new machines.

P.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS-virt] lvm cache + qemu-kvm stops working after about 20GB of writes

2017-04-20 Thread Sandro Bonazzola

On Thu, Apr 20, 2017 at 12:32 PM, Richard Landsman - Rimote <
rich...@rimote.nl> wrote:

> Hello everyone,
>
> Anybody had the chance to test out this setup and reproduce the problem? I
> assumed it would be something that's used often these days and a solution
> would benefit a lot of users. If can be of any assistance please contact
> me.
>
I haven't seen any additional report of this happening, can you please try
to reproduce with the new qemu-kvm-ev-2.6.0-28.el7_3.9.1 currently in
testing?

> --
> Met vriendelijke groet,
>
> Richard Landsmanhttp://rimote.nl
>
> T: +31 (0)50 - 763 04 07
> (ma-vr 9:00 tot 18:00)
>
> 24/7 bij storingen:
> +31 (0)6 - 4388 7949
> @RimoteSaS (Twitter Serviceberichten/security updates)
>
>
>

-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA 

TRIED. TESTED. TRUSTED. 
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] qemu-kvm-ev-2.6.0-28.el7_3.9.1 now available for testing

2017-04-20 Thread Sandro Bonazzola

Hi,
just pushed to testing a new build of qemu-kvm-ev, here's the ChangeLog:

* Thu Apr 20 2017 Sandro Bonazzola  -
ev-2.6.0-28.el7_3.9.1
- Removing RH branding from package name

* Fri Mar 24 2017 Miroslav Rezanina  -
rhev-2.6.0-28.el7_3.9
- kvm-block-gluster-memory-usage-use-one-glfs-instance-per.patch
[bz#1413044]
- kvm-gluster-Fix-use-after-free-in-glfs_clear_preopened.patch [bz#1413044]
- kvm-fix-cirrus_vga-fix-OOB-read-case-qemu-Segmentation-f.patch
[bz#1430061]
- kvm-cirrus-vnc-zap-bitblit-support-from-console-code.patch [bz#1430061]
- kvm-cirrus-add-option-to-disable-blitter.patch [bz#1430061]
- kvm-cirrus-fix-cirrus_invalidate_region.patch [bz#1430061]
- kvm-cirrus-stop-passing-around-dst-pointers-in-the-blitt.patch
[bz#1430061]
- kvm-cirrus-stop-passing-around-src-pointers-in-the-blitt.patch
[bz#1430061]
- kvm-cirrus-fix-off-by-one-in-cirrus_bitblt_rop_bkwd_tran.patch
[bz#1430061]
- kvm-file-posix-Consider-max_segments-for-BlockLimits.max.patch
[bz#1431149]
- kvm-file-posix-clean-up-max_segments-buffer-termination.patch [bz#1431149]
- kvm-file-posix-Don-t-leak-fd-in-hdev_get_max_segments.patch [bz#1431149]
- Resolves: bz#1413044
  (block-gluster: use one glfs instance per volume)
- Resolves: bz#1430061
  (CVE-2016-9603 qemu-kvm-rhev: Qemu: cirrus: heap buffer overflow via vnc
connection [rhel-7.3.z])
- Resolves: bz#1431149
  (VMs pause when writing to Virtio-SCSI direct lun with scsi passthrough
enabled via an Emulex HBA)

* Tue Mar 21 2017 Miroslav Rezanina  -
rhev-2.6.0-28.el7_3.8
- kvm-target-i386-present-virtual-L3-cache-info-for-vcpus.patch [bz#1430802]
- Resolves: bz#1430802
  (Enhance qemu to present virtual L3 cache info for vcpus)

* Wed Mar 15 2017 Miroslav Rezanina  -
rhev-2.6.0-28.el7_3.7
- kvm-block-check-full-backing-filename-when-searching-pro.patch
[bz#1425125]
- kvm-qemu-iotests-Don-t-create-fifos-pidfiles-with-protoc.patch
[bz#1425125]
- kvm-qemu-iotest-test-to-lookup-protocol-based-image-with.patch
[bz#1425125]
- kvm-target-i386-Don-t-use-cpu-migratable-when-filtering-.patch
[bz#1413897]
- Resolves: bz#1413897
  (cpu flag nonstop_tsc is not present in guest with host-passthrough and
feature policy require invtsc)
- Resolves: bz#1425125
  (qemu fails to recognize gluster URIs in backing chain for block-commit
operation)

In order to test it:

# yum install centos-release-qemu-ev
# yum-config-manager --enable centos-qemu-ev-test
# yum install qemu-kvm-ev

Or just yum update if you already have qemu-kvm-ev installed and test
repository enabled.

If you test it, please provide feedback.
I'm going to release it on April 26th if no negative feedback is provided.

-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA 

TRIED. TESTED. TRUSTED. 
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS] Firefox for CentOS

2017-04-20 Thread wwp

Hello James,


On Thu, 20 Apr 2017 14:06:59 + James Pearson  
wrote:

> wwp wrote:
> >>>
> >>> They obviously felt more comfortable instead released the older one on
> >>> EL6 this cycle, but I suspect that the newer 52.x ESR version will be
> >>> released during the next cycle.
> >>>
> >>>  
> >> Indeed, the latest RHEL 6 update for firefox is the 52.1.0 ESR release:
> >>
> >> This update upgrades Firefox to version 52.1.0 ESR.  
> >
> > Sorry for jumping into this topic from nowhere.. does this mean that we
> > could get a Firefox v52 running on a CentOS 6?  
> 
> Yes, not 'could' but 'will' ...

Hah. Good news!


Regards,

-- 
wwp


pgp_4LqrLQ22H.pgp
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Firefox for CentOS

2017-04-20 Thread James Pearson

wwp wrote:
>>>
>>> They obviously felt more comfortable instead released the older one on
>>> EL6 this cycle, but I suspect that the newer 52.x ESR version will be
>>> released during the next cycle.
>>>
>>>
>> Indeed, the latest RHEL 6 update for firefox is the 52.1.0 ESR release:
>>
>> This update upgrades Firefox to version 52.1.0 ESR.
>
> Sorry for jumping into this topic from nowhere.. does this mean that we
> could get a Firefox v52 running on a CentOS 6?

Yes, not 'could' but 'will' ...

James Pearson

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS-virt] qemu-kvm-ev ppc64le release builds

2017-04-20 Thread Sandro Bonazzola

On Thu, Apr 20, 2017 at 1:03 AM, Lance Albertson  wrote:

> Hi,
>
> We're using qemu-kvm-ev on ppc64le and I've noticed that it's included in
> the extras repo for ppc64le but in the qemu-kvm-ev repo for x86_64. I also
> noticed the version in ppc64le is lagging behind x86. I see that ppc64le is
> being built for this, however isn't tagged for virt7-kvm-common-release and
> thus showing up under /virt/kvm-common on the mirrors.
>
> Is there any particular reason why this is happening? If possible, I can
> certainly provide some testing to get this moving along.
>

There are still issues in the publishing chain for alternative arches from
SIGs.
https://bugs.centos.org/view.php?id=11457 is tracking it.
Karanbir, any chance we can move on on this topic?



>
> Thank you!
>
> [1] http://cbs.centos.org/koji/packageinfo?packageID=539
>
> --
> Lance Albertson
> Director
> Oregon State University | Open Source Lab
>
> ___
> CentOS-virt mailing list
> CentOS-virt@centos.org
> https://lists.centos.org/mailman/listinfo/centos-virt
>
>


-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA 

TRIED. TESTED. TRUSTED. 
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS] startup process that rebuilds aliases.db?