Discuss

discuss@lists.centos.org

5 participants
34752 discussions

CentOS-announce Digest, Vol 162, Issue 3
by centos-announce-request＠centos.org 16 Aug '18

16 Aug '18

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CEBA-2018:2407 CentOS 6 389-ds-base BugFix Update (Johnny Hughes) 2. CEBA-2018:2406 CentOS 6 sos BugFix Update (Johnny Hughes) 3. Release for CentOS Linux 7 (1804) on POWER9 (ppc64le) (James O'Connor) ---------------------------------------------------------------------- Message: 1 Date: Wed, 15 Aug 2018 13:26:03 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEBA-2018:2407 CentOS 6 389-ds-base BugFix Update Message-ID: <20180815132603.GA40006(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2018:2407 Upstream details at : https://access.redhat.com/errata/RHBA-2018:2407 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: ae6efff96d69387264ef7f03b143c1719408036ed4da97436a7e639d0d11de7f 389-ds-base-1.2.11.15-97.el6_10.i686.rpm 562a895d4e0ee963ac0bfc8789e16a85a73a881cfc4305d444780b7dfa97e7a9 389-ds-base-devel-1.2.11.15-97.el6_10.i686.rpm d6d6925bc704747f207d592bcc2fef9acfcde8bf4b0669fc3c1b23599f43dbfa 389-ds-base-libs-1.2.11.15-97.el6_10.i686.rpm x86_64: 226125bf9c549430a6af2638c01fb797e4b2b26a8042725e28ba58e8a4317b3f 389-ds-base-1.2.11.15-97.el6_10.x86_64.rpm 562a895d4e0ee963ac0bfc8789e16a85a73a881cfc4305d444780b7dfa97e7a9 389-ds-base-devel-1.2.11.15-97.el6_10.i686.rpm 79a22fd167036159325d2fc44ba914ede2f12c1c163ee0e4f8f2f74dc0f6041b 389-ds-base-devel-1.2.11.15-97.el6_10.x86_64.rpm d6d6925bc704747f207d592bcc2fef9acfcde8bf4b0669fc3c1b23599f43dbfa 389-ds-base-libs-1.2.11.15-97.el6_10.i686.rpm 5423d51cfba1fa170c6f4c7b36ece4e51bb5ef1a26d5d0e20ec78b513825535f 389-ds-base-libs-1.2.11.15-97.el6_10.x86_64.rpm Source: 2dd39848c8d5b3dbf5efed94355f7a7cd230d7d22d36d3d0680b5dffd75c32ae 389-ds-base-1.2.11.15-97.el6_10.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Message: 2 Date: Wed, 15 Aug 2018 13:26:13 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEBA-2018:2406 CentOS 6 sos BugFix Update Message-ID: <20180815132613.GA40116(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2018:2406 Upstream details at : https://access.redhat.com/errata/RHBA-2018:2406 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 751a8137d6e283f8e83f9df970059a3b1b6691e092cb550dda709ae3b65b6e23 sos-3.2-63.el6.centos.2.noarch.rpm x86_64: 751a8137d6e283f8e83f9df970059a3b1b6691e092cb550dda709ae3b65b6e23 sos-3.2-63.el6.centos.2.noarch.rpm Source: 6c76c3ac69a92aada4b23cdf8a8ce64727efdc60b88baf25e5f787e2be09c3df sos-3.2-63.el6.centos.2.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Message: 3 Date: Wed, 15 Aug 2018 13:26:57 -0500 From: "James O'Connor" <jpoc(a)linux.vnet.ibm.com> To: centos-announce(a)centos.org Subject: [CentOS-announce] Release for CentOS Linux 7 (1804) on POWER9 (ppc64le) Message-ID: <8E062BA8-47A0-4243-B527-4FFCABF6E1D6(a)linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 I am pleased to announce the general availability of CentOS Linux 7 (1804) for POWER9 processors (ppc64le - powerpc 64-bit little endian). This release is derived from Red Hat Enterprise Linux 7.5 ALT. Note this release is 99% equivalent to the existing CentOS 7 Linux 7 (1804) for POWER8 processors (ppc64le - powerpc 64-bit little endian). The key difference being that kernel-4.14.0 is used for POWER9 enablement and kernel-3.10.0 is used for POWER8 enablement. You will find the CentOS 7 (1804) Power9 installation images here: http://mirror.centos.org/altarch/7.5.1804/isos/power9/ sha256sum power9: 753c5b55c9ff681c925ec7d7c5295890284f40ec981f4da35b1f36f1ecbad95a CentOS-7-Power9-Everything-1804.iso 58d9af172656db71947b5db2d0d1f577217bbc1a86eada7ca3ce7bfcf7d7d9b4 CentOS-7-Power9-NetInstall-1804.iso CentOS 7 (1804) Power9 repositories: http://mirror.centos.org/altarch/7.5.1804/os/power9/ http://mirror.centos.org/altarch/7.5.1804/updates/power9/ http://mirror.centos.org/altarch/7.5.1804/extras/power9/ A special thank you to Johnny Hughes and Pablo Greco for their assistance making this release possible. -James O?Connor ------------------------------ Subject: Digest Footer _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org https://lists.centos.org/mailman/listinfo/centos-announce ------------------------------ End of CentOS-announce Digest, Vol 162, Issue 3 ***********************************************

1 0

Old kernel bug back in CentOS 6.10?
by Matthias Bethke 16 Aug '18

16 Aug '18

I updated a few hypervisors and their VMs to CentOS 6.10 on Monday; today I awoke to an alert saying all VMs are down. It looks like a very old bug crept back in. The machine is a ProLiant DL380 G7 with Xeon X5675 and 96 GB, running half a dozen smallish VMs. Hypervisor and all VMs have kernel 2.6.32-754.2.1.el6.x86_64. Around the time the VMs must have gone down, there are quite a few error messages like the following in the system log: Aug 16 03:10:13 hyper-7 kernel: [265397.382552] vmwrite error: reg 6000 value fffffffffffffff7 (err -9) Aug 16 03:10:13 hyper-7 kernel: [265397.421372] Pid: 9375, comm: qemu-kvm Not tainted 2.6.32-754.2.1.el6.x86_64 #1 Aug 16 03:10:13 hyper-7 kernel: [265397.464985] Call Trace: Aug 16 03:10:13 hyper-7 kernel: [265397.481530] [<ffffffffa0532a9c>] ? vmwrite_error+0x2c/0x30 [kvm_intel] Aug 16 03:10:13 hyper-7 kernel: [265397.520737] [<ffffffffa0532ac0>] ? vmcs_writel+0x20/0x30 [kvm_intel] Aug 16 03:10:13 hyper-7 kernel: [265397.560028] [<ffffffffa0535e63>] ? vmx_fpu_activate+0x93/0xc0 [kvm_intel] Aug 16 03:10:14 hyper-7 kernel: [265397.600072] [<ffffffffa04cd1e7>] ? kvm_arch_vcpu_create+0x37/0x50 [kvm] Aug 16 03:10:14 hyper-7 kernel: [265397.638183] [<ffffffffa04c72a1>] ? kvm_vm_ioctl+0x601/0x1050 [kvm] Aug 16 03:10:14 hyper-7 kernel: [265397.674367] [<ffffffff8113f461>] ? free_one_page+0x191/0x440 Aug 16 03:10:14 hyper-7 kernel: [265397.708101] [<ffffffff811b4159>] ? vfs_ioctl+0x29/0xc0 Aug 16 03:10:14 hyper-7 kernel: [265397.739124] [<ffffffff81142d86>] ? __free_pages+0x46/0xa0 Aug 16 03:10:14 hyper-7 kernel: [265397.773193] [<ffffffff811b463a>] ? do_vfs_ioctl+0x3aa/0x590 Aug 16 03:10:14 hyper-7 kernel: [265397.805774] [<ffffffff81142e29>] ? free_pages+0x49/0x50 Aug 16 03:10:14 hyper-7 kernel: [265397.839147] [<ffffffff811b48a1>] ? sys_ioctl+0x81/0xa0 Aug 16 03:10:14 hyper-7 kernel: [265397.870109] [<ffffffff810f1d0e>] ? __audit_syscall_exit+0x25e/0x290 Aug 16 03:10:14 hyper-7 kernel: [265397.909358] [<ffffffff81560351>] ? system_call_fastpath+0x2f/0x34 Curiously, the messages don't seem to indicate anything fatal in and of themselves; there are a two like this a minute after bootup and like a dozen more after about a day, none of which seems to have crashed anything. However, it's the only obvious anomaly I could find around the time and as it's VT-x related, I reckon there's a connection. The stack trace closely resembles this bug that turned up in 2015 and was fixed long ago: https://lkml.org/lkml/2015/7/3/288 Has anyone seen this recently and could confirm or refute any of my guesswork? Cheers, Matthias

1 0

grub2 - add NVME to boot from - how?
by lejeczek 15 Aug '18

15 Aug '18

hi guys, I thought I should ask before I start fiddling and break something - can we tell grub2 to add nvme device as an option to boot from? And if yes then what do tell grub? many thanks, L.

2 2

Re: [CentOS] CentOS Digest, Vol 163, Issue 10
by Ste Films- radio stream 15 Aug '18

15 Aug '18

the thread seams to have dead out or gone from rdadmin login prassword reset to user login on centos I dumped mysql to find the password but can't find it with this comand $mysql dump -u rduser -p Rivendell > resetpass.sql i am useing rduser to run airplay but I can't get into config part of rdadmin which rdadmin controls the paramiter to set the rduser program like rdairplay, rdlogedit, rdlibary...ect rdadmin is used to set default and setting all threwout the rd program.... for radio... On Fri, Aug 10, 2018 at 7:00 AM, <centos-request(a)centos.org> wrote: > Send CentOS mailing list submissions to > centos(a)centos.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.centos.org/mailman/listinfo/centos > or, via email, send a message with subject or body 'help' to > centos-request(a)centos.org > > You can reach the person managing the list at > centos-owner(a)centos.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of CentOS digest..." > > > Today's Topics: > > 1. Re: Can't boot into GUI: Centos 7 "Server with GUI" option > (James Pearson) > 2. bad udp cksum (Laszlo Danielisz) > 3. xfs quota question (mark) > 4. Re: xfs quota question (Valeri Galtsev) > 5. Re: xfs quota question (mark) > 6. Re: xfs quota question (Valeri Galtsev) > 7. Re: bad udp cksum (Simon Matter) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 9 Aug 2018 12:20:26 +0000 > From: James Pearson <james-p(a)moving-picture.com> > To: Jay Hart <jhart(a)kevla.org> > Cc: CentOS mailing list <centos(a)centos.org> > Subject: Re: [CentOS] Can't boot into GUI: Centos 7 "Server with GUI" > option > Message-ID: <a7387fc9-ddcd-f827-cf07-76667a2a0b2e(a)moving-picture.com> > Content-Type: text/plain; charset="utf-8" > > Jay Hart wrote: > > > > A complete step by step would be appreciated. It will avoid further > back-n-forth. > > It's not that difficult - a quick google of 'centos 7 rebuild initramfs' > brings up (e.g.) > https://sites.google.com/site/syscookbook/rhel/rhel-kernel-rebuild > > James Pearson > > > > ------------------------------ > > Message: 2 > Date: Thu, 9 Aug 2018 14:53:17 -0400 > From: Laszlo Danielisz <lacibsd(a)gmail.com> > To: centos(a)centos.org > Subject: [CentOS] bad udp cksum > Message-ID: > <CABPYxKwuSPEeNxdAUu2p4h-oTibH-RJBnxntWbVO2NuBk0-zfA@ > mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi, > > Recently I'm noticing an interesting issue. > My CentOS servers are trying to send logs to a logging server via 514/udp, > however I'm not receiving anything. > > I did the following on CentOS > *tcpdump -vvv -nn udp -i esn160 port 514* > > In another session on the same server: > *nc syslog-server -u 514* > > tcpdump started to show me messages like: > *[bad udp cksum 0x3ce9 -> 0xb0f5!] SYSLOG, length: 172* > > After some research I disabled TCO (ethtool -K ens160 tx off rx off), now > tcpdump shows: > *[udp sum ok] [|syslog]* > And I'm also receiving the logs. Yay! > > I have the same issue on multiple servers with CentOS versions 7.3.1611, > 7.4.1708 & 7.5.1804. I'm having the issue no matter if it is a physical or > virtual server (they also use different hardware and NIC's) > > Of course I could run ethtool every time a server starts but I think there > should be a better solution. Also I enjoy having TCO giving some rest to > the CPUs. > > Did anyone find a solution for this? > > Thanks! > Laszlo > > > ------------------------------ > > Message: 3 > Date: Thu, 9 Aug 2018 15:57:25 -0400 > From: "mark" <m.roth(a)5-cent.us> > To: "CentOS mailing list" <centos(a)centos.org> > Subject: [CentOS] xfs quota question > Message-ID: > <993f74e35fb023b2a49b9053dc3e5a3f.squirrel(a)host290.hostmonster.com > > > Content-Type: text/plain;charset=utf-8 > > Can I go to an existing xfs file system, and apply a soft quota to each > user on it? If I do, can I then run a report, and see who's using how > much, or does it only apply to files created after the quotas are applied? > > mark > > > > ------------------------------ > > Message: 4 > Date: Thu, 9 Aug 2018 15:22:30 -0500 > From: Valeri Galtsev <galtsev(a)kicp.uchicago.edu> > To: centos(a)centos.org > Subject: Re: [CentOS] xfs quota question > Message-ID: <6551c6c1-bbb6-ef43-eb3d-03de0fa58b8c(a)kicp.uchicago.edu> > Content-Type: text/plain; charset=utf-8; format=flowed > > > > On 08/09/18 14:57, mark wrote: > > Can I go to an existing xfs file system, and apply a soft quota to each > > user on it? If I do, can I then run a report, and see who's using how > > much, or does it only apply to files created after the quotas are > applied? > > > > After remounting XFS filesystem with option "usrquota" you can issue the > command similar to: > > xfs_quota -x -c "limit bsoft=8g bhard=10g -d" /home > > This command will enable the limits above for all users (-d flag), > except users who have their limits existing already (usually ones who > preformed fs operations). > > For those who already have some limits set you can still can change > these limits, but with individual command, say in the loop, like: > > for i in `cat user_list`; \ > do xfs_quota -x -c "limit bsoft=8g bhard=10g $i; \ > done > > I hope, this helps. > > Valeri > > > > mark > > > > _______________________________________________ > > CentOS mailing list > > CentOS(a)centos.org > > https://lists.centos.org/mailman/listinfo/centos > > > > -- > ++++++++++++++++++++++++++++++++++++++++ > Valeri Galtsev > Sr System Administrator > Department of Astronomy and Astrophysics > Kavli Institute for Cosmological Physics > University of Chicago > Phone: 773-702-4247 > ++++++++++++++++++++++++++++++++++++++++ > > > ------------------------------ > > Message: 5 > Date: Thu, 9 Aug 2018 17:24:09 -0400 > From: "mark" <m.roth(a)5-cent.us> > To: "CentOS mailing list" <centos(a)centos.org> > Subject: Re: [CentOS] xfs quota question > Message-ID: > <4e5e8e726f2df226bc9d6612a1a572c1.squirrel(a)host290.hostmonster.com > > > Content-Type: text/plain;charset=utf-8 > > Valeri Galtsev wrote: > > On 08/09/18 14:57, mark wrote: > > > >> Can I go to an existing xfs file system, and apply a soft quota to each > >> user on it? If I do, can I then run a report, and see who's using how > >> much, or does it only apply to files created after the quotas are > >> applied? > > > > After remounting XFS filesystem with option "usrquota" you can issue the > > command similar to: > > > > xfs_quota -x -c "limit bsoft=8g bhard=10g -d" /home > > > > This command will enable the limits above for all users (-d flag), > > except users who have their limits existing already (usually ones who > > preformed fs operations). > > > > For those who already have some limits set you can still can change > > these limits, but with individual command, say in the loop, like: > > > > for i in `cat user_list`; \ do xfs_quota -x -c "limit bsoft=8g bhard=10g > > $i; \ > > done > > > > I hope, this helps. > > Will that work if I do a mount -o remount? > > mark > > > > ------------------------------ > > Message: 6 > Date: Thu, 9 Aug 2018 16:57:06 -0500 (CDT) > From: "Valeri Galtsev" <galtsev(a)kicp.uchicago.edu> > To: "CentOS mailing list" <centos(a)centos.org> > Subject: Re: [CentOS] xfs quota question > Message-ID: > <54719.108.68.162.197.1533851826.squirrel(a)cosmo.uchicago.edu> > Content-Type: text/plain;charset=iso-8859-1 > > > On Thu, August 9, 2018 4:24 pm, mark wrote: > > Valeri Galtsev wrote: > >> On 08/09/18 14:57, mark wrote: > >> > >>> Can I go to an existing xfs file system, and apply a soft quota to each > >>> user on it? If I do, can I then run a report, and see who's using how > >>> much, or does it only apply to files created after the quotas are > >>> applied? > >> > >> After remounting XFS filesystem with option "usrquota" you can issue the > >> command similar to: > >> > >> xfs_quota -x -c "limit bsoft=8g bhard=10g -d" /home > >> > >> This command will enable the limits above for all users (-d flag), > >> except users who have their limits existing already (usually ones who > >> preformed fs operations). > >> > >> For those who already have some limits set you can still can change > >> these limits, but with individual command, say in the loop, like: > >> > >> for i in `cat user_list`; \ do xfs_quota -x -c "limit bsoft=8g bhard=10g > >> $i; \ > >> done > >> > >> I hope, this helps. > > > > Will that work if I do a mount -o remount? > > If you are able to execute > > mount -o remount -o usrquota /mountpoint > > then you are OK. Normally, you will not be able to do it if there is even > a single file open on the filesystem, Therefore if it is /home you do have > to kick all users off. Executing any command related to quota will make it > obvious if particular filesystem is mounted with quotas enabled or not. > > Good luck. > > Valeri > > > > > mark > > > > ++++++++++++++++++++++++++++++++++++++++ > Valeri Galtsev > Sr System Administrator > Department of Astronomy and Astrophysics > Kavli Institute for Cosmological Physics > University of Chicago > Phone: 773-702-4247 > ++++++++++++++++++++++++++++++++++++++++ > > > ------------------------------ > > Message: 7 > Date: Fri, 10 Aug 2018 09:34:24 +0200 > From: "Simon Matter" <simon.matter(a)invoca.ch> > To: "CentOS mailing list" <centos(a)centos.org> > Subject: Re: [CentOS] bad udp cksum > Message-ID: > <1c988b38e34d5ddc32177f921f7a6c6b.squirrel(a)webmail.bi.invoca.ch> > Content-Type: text/plain;charset=utf-8 > > > Hi, > > > > Recently I'm noticing an interesting issue. > > My CentOS servers are trying to send logs to a logging server via > 514/udp, > > however I'm not receiving anything. > > > > I did the following on CentOS > > *tcpdump -vvv -nn udp -i esn160 port 514* > > > > In another session on the same server: > > *nc syslog-server -u 514* > > > > tcpdump started to show me messages like: > > *[bad udp cksum 0x3ce9 -> 0xb0f5!] SYSLOG, length: 172* > > > > After some research I disabled TCO (ethtool -K ens160 tx off rx off), now > > tcpdump shows: > > *[udp sum ok] [|syslog]* > > And I'm also receiving the logs. Yay! > > > > I have the same issue on multiple servers with CentOS versions 7.3.1611, > > 7.4.1708 & 7.5.1804. I'm having the issue no matter if it is a physical > or > > virtual server (they also use different hardware and NIC's) > > > > Of course I could run ethtool every time a server starts but I think > there > > should be a better solution. Also I enjoy having TCO giving some rest to > > the CPUs. > > > > Did anyone find a solution for this? > > You can configure the ETHTOOL_OPTS option in the ifcfg files to > automatically assign settings on startup. > > Regards, > Simon > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > CentOS mailing list > CentOS(a)centos.org > https://lists.centos.org/mailman/listinfo/centos > > > ------------------------------ > > End of CentOS Digest, Vol 163, Issue 10 > *************************************** >

1 0

Docker + firewalld
by Todor Petkov 15 Aug '18

15 Aug '18

Hello, I am using Centos7 + Docker CE (docker-ce-18.03.1.ce-1.el7.centos.x86_64), in the following setup 1) On interface br-ee1ac3f6bbaf I have network 172.16.26/24 2) Network from (1) is routed via the IP address of eth0 of the CentOS machine 3) Access to machines in network (1) is direct, without port forwarding I want to be able to reach other machines in other subnet from the IP address of the Docker containers. I ran the following command: firewall-cmd --direct --permanent --add-rule ipv4 nat POSTROUTING 0 -i br+ -o eth0 -s 172.16.26.0/24 -j ACCEPT However, the firewall rules for NAT are: -A POSTROUTING -s 172.16.26.0/24 ! -o br-ee1ac3f6bbaf -j MASQUERADE -A POSTROUTING -j POSTROUTING_direct -A POSTROUTING_direct -s 172.16.26.0/24 -i br+ -o eth0 -j ACCEPT With this, it always goes via MASQUERADE first, without hitting the POSTROUTING_direct chain. Is there a way to add this rule on top of POSTROUTING? Regards,

1 0

USB disk IO
by Jerry Geis 15 Aug '18

15 Aug '18

Hello - frequently I turn on my external USB 3.0 disk and back. While my machine is copying and backing up my desktop becomes very sluggish. Is there a way to change that ? I am using CentOS 7.5 x86 with a very nice processor extra cores available and plenty of memory. There is no reason the "other" cores cannot keep the desktop going. Thanks, Jerry

2 2

CentOS-announce Digest, Vol 162, Issue 2
by centos-announce-request＠centos.org 15 Aug '18

15 Aug '18

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CESA-2018:2390 Important CentOS 6 kernel Security Update (Johnny Hughes) 2. CESA-2018:2384 Important CentOS 7 kernel Security Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Wed, 15 Aug 2018 01:59:55 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2018:2390 Important CentOS 6 kernel Security Update Message-ID: <20180815015955.GA24393(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2018:2390 Important Upstream details at : https://access.redhat.com/errata/RHSA-2018:2390 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 106a77192bd5329bcc3f7e388192dd6f180b0ab95f4680064d75f3c51d959702 kernel-2.6.32-754.3.5.el6.i686.rpm 62f7a798b08f065e936aa1f3d56a5c7fb4e9e41931a9d85f100f475517f7b017 kernel-abi-whitelists-2.6.32-754.3.5.el6.noarch.rpm 6e5987cd17220deecfa9e669c0be2ffcf42730dd99574c8e3a660e7f1ec7a6d5 kernel-debug-2.6.32-754.3.5.el6.i686.rpm bcab4f5115d1f298efc4894f2d38ebeffd75ae4ee6292146550bbbefdda6f036 kernel-debug-devel-2.6.32-754.3.5.el6.i686.rpm fda995f13c04b4f71fe7ecfb720266a0dade787c4f48b943581c6e75fcae5ef1 kernel-devel-2.6.32-754.3.5.el6.i686.rpm 83fbe21432b4cebf049ba18423bedb34f3f52ba72dd59c5609246d1a393cdb7f kernel-doc-2.6.32-754.3.5.el6.noarch.rpm 22a3605c9893c09958d7d691feec8819680b5117389fab7be28d52bc8f2f108d kernel-firmware-2.6.32-754.3.5.el6.noarch.rpm 17f99387f14bea201de0ef0fc9a117201a26595f9f1bde392504579c9ed71493 kernel-headers-2.6.32-754.3.5.el6.i686.rpm bad0c18a9fcebb72f6a08aac18787222e1c3b10f49ca8eea1a015029c4761515 perf-2.6.32-754.3.5.el6.i686.rpm fa8c69dafcb9bb4a209f8f2fae92a208389b3183a5a473608ef7d765601ec82a python-perf-2.6.32-754.3.5.el6.i686.rpm x86_64: a315d9824eba61490ec384774421d84baf2e853d12e031aaf9ea26f6459e4307 kernel-2.6.32-754.3.5.el6.x86_64.rpm 62f7a798b08f065e936aa1f3d56a5c7fb4e9e41931a9d85f100f475517f7b017 kernel-abi-whitelists-2.6.32-754.3.5.el6.noarch.rpm 67e08721326f15f1b4e9f2a062a45ef612c0d8a784d9f1e3e03f5bb677b56d34 kernel-debug-2.6.32-754.3.5.el6.x86_64.rpm bcab4f5115d1f298efc4894f2d38ebeffd75ae4ee6292146550bbbefdda6f036 kernel-debug-devel-2.6.32-754.3.5.el6.i686.rpm cc9f24337e23be4eeb20a1a87aa69dc91f9a765be4430c58e20ff31b782c75ba kernel-debug-devel-2.6.32-754.3.5.el6.x86_64.rpm 0c16e8f698561ed21e832431b402150f94fe0a0437c5c43a12b70c15306ebcf2 kernel-devel-2.6.32-754.3.5.el6.x86_64.rpm 83fbe21432b4cebf049ba18423bedb34f3f52ba72dd59c5609246d1a393cdb7f kernel-doc-2.6.32-754.3.5.el6.noarch.rpm 22a3605c9893c09958d7d691feec8819680b5117389fab7be28d52bc8f2f108d kernel-firmware-2.6.32-754.3.5.el6.noarch.rpm 0cd344a1d45d5d38e0b00cd2a966c4c6c5c436a830af589edc69ff43da620833 kernel-headers-2.6.32-754.3.5.el6.x86_64.rpm 8f0d34fb64a264cc1d345d3f929f4e0915b4eafab6516de5f32b2e11f4426e27 perf-2.6.32-754.3.5.el6.x86_64.rpm bb421ac56e0ebc227b240dcdccd0a724da33c07fc92d8106b7e4e71c52cb3918 python-perf-2.6.32-754.3.5.el6.x86_64.rpm Source: 4da720dc6cd3913aa9b54abb9d398295b74d5cfb64ea4c93f3eac61ac1070c08 kernel-2.6.32-754.3.5.el6.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Message: 2 Date: Wed, 15 Aug 2018 03:59:04 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2018:2384 Important CentOS 7 kernel Security Update Message-ID: <20180815035904.GA31375(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2018:2384 Important Upstream details at : https://access.redhat.com/errata/RHSA-2018:2384 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 4c81a12f0c1bab43e45a688035081b68bc17d4ccaf219ad92b8a8a7856282106 kernel-3.10.0-862.11.6.el7.x86_64.rpm 85b7bd8c17bea34630282c70fdcbadb1daafcb112b0a1396770753f90d220c29 kernel-abi-whitelists-3.10.0-862.11.6.el7.noarch.rpm 406fb8d4fe1a048955208a96288505e3c8c0d0d58252650c21f113532fc5b62b kernel-debug-3.10.0-862.11.6.el7.x86_64.rpm cc676de2fa76153f340ceb98d1f709314b404fb19c09f312266b53272f46f127 kernel-debug-devel-3.10.0-862.11.6.el7.x86_64.rpm f28bacde434bc5801b423172e75c932654d153d05bde710306b56323e5ba6b36 kernel-devel-3.10.0-862.11.6.el7.x86_64.rpm 7c45bf82de48d08ad52586c38980366e51e71ff84cb9661452df41484e44598f kernel-doc-3.10.0-862.11.6.el7.noarch.rpm 6c041e73dfa61237e70ecc9f7c201581175a26a88bc2cdcbb2337e19e386d905 kernel-headers-3.10.0-862.11.6.el7.x86_64.rpm e899bc77622146b49a47d58a04dffb8b22215fc8219f1dd8a5fb60dfdbaf9782 kernel-tools-3.10.0-862.11.6.el7.x86_64.rpm 69acbd5ba958c6f367edd0e484822134a325c7d1a97c6af7954d53c80fdb6457 kernel-tools-libs-3.10.0-862.11.6.el7.x86_64.rpm d619c0a7d84568240e05b30e45a207fdc7f8acd7a93643f7d66128c0cf9943e6 kernel-tools-libs-devel-3.10.0-862.11.6.el7.x86_64.rpm 203da784ce254e22df2a78021c5cc97f3a5948432d4d04c49ec44bf1d630ff1a perf-3.10.0-862.11.6.el7.x86_64.rpm 94abbe3057a41b29f89163e5bd838b8c11015182a91f9c58647418d18808282c python-perf-3.10.0-862.11.6.el7.x86_64.rpm Source: aabaa81106744323a084655078fcb93498357768315f53020135688ec03cd21f kernel-3.10.0-862.11.6.el7.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Subject: Digest Footer _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org https://lists.centos.org/mailman/listinfo/centos-announce ------------------------------ End of CentOS-announce Digest, Vol 162, Issue 2 ***********************************************

1 0

Sending mail from CentOS7 VM to FX ApeosPort-IV C4475 problem
by マスターズ　イアン 15 Aug '18

15 Aug '18

Hi Folks I'm a long term Linux user but have never used CUPS until this week. I'm trying to print from a CentOS7 VM to a Fuji Xerox ApeosPort-IV C4475 printer which requires a user name to be specified but no password. CUPS reports jobs are complete but nothing appears at the printer. This is what I've tried: 1. I downloaded the linux printer driver from the Fuji Xerox website and installed it and its accompanying printer utility. 2. I've followed various guides for setting up the printer in CUPS as an LPR connection as that is what my Windows machine uses. 3. I used the print utility (fxlputil) to specify my user name as I have to with Windows. However I have a sneaky feeling that nothing is arriving at the printer (whose admin info I don't have access to). I know the connection is OK: /usr/lib/cups/backend/snmp 172.16.58.222 gives: network socket://172.16.58.222 "Unknown" "FUJI XEROX ApeosPort-IV C4475 v 34. 52. 0 Multifunction System" "MANUFACTURER:FUJI XEROX;MODEL:ApeosPort-IV C4475" "" But lpinfo -l -v gives alot of "make-and-model = Unknown" messages. What can I can try to get more information or to get this working? Sorry if my information is vague. As I said, I'm only just starting to dip my feet in the pond of CUPS and it hasn't been very successful so far. Thanks in advance for any assistance. Ian

1 0

Proxy rendering of 4K
by Phil Evans 14 Aug '18

14 Aug '18

Hi everyone. I have used cinelerra for several years and love the application, so thanks to all for the hard work. I recently started to edit 4K footage from a Canon 1DX Mk 2. This is obviously very slow even with a six core processor. So I am required to use proxy files to speed things up. This worked with fedora 28. However I have changed to Centos 7.5 and now have an issue, the proxy files when dropped into the viewer are very small only taking up a small part of the window. I cannot find a way to resize these to fill the viewer window. This did not happen on fedora 28. I set the >settins >format to the resolution of the original video, then the >settings >Proxy settings to use scaler, 1/3rd size, FFMPEG Mp4 and auto proxy/scale media loads. I then import the video and drag the newly created proxy file into the viewer where it sits at a third size in the centre of the viewer window. Any suggestions welcome. Cinelerra 5.1 built jul 31st 2018 06:59:29 Regards Phil Evans

1 0

TLS 1.3 and openSSL 1.1.1 support
by Robert Moskowitz 14 Aug '18

14 Aug '18

TLS 1.3 RFC has 'shipped': RFC 8446. Don't yet know all that will have to be updated to support it, but I am working on openSSL 1.1.1 beta which is available in the Fedora 29 beta. The openSSL team is looking at one more beta release (I had challenges with ED25519 certs, I will soon have an Internet Draft out on them). So general heads up. TLS 1.3 is claimed to be the cat's meow for security (I see it as a kitchen sink). There will be questions asking for when it will be available (wait until they start thinking about creating EDDSA pkis). Yet another thing for our hard working Centos team.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss