Re: [CentOS] Updated krb5 rpm package altered existing krb5.conf - No go
On Mon, 18 Jun 2018, G?tz Reinicke wrote: Am 15.06.2018 um 01:04 schrieb Gordon Messmer : On 06/14/2018 09:30 AM, m...@tdiehl.org wrote: On Thu, 14 Jun 2018, Richard Grainger wrote: I looked at the spec file in the source RPM for the krb5-libs package and it it has the correct %config(noreplace) directive next to that file in the %files section, so this is mysterious. I too can confirm this behavior. # rpm -qa krb\* --triggers triggerun scriptlet (using /bin/sh) -- krb5-libs < 1.15.1-13 if ! grep -q 'includedir /etc/krb5.conf.d' /etc/krb5.conf ; then sed -i '1i # Other applications require this directory to perform krb5 configuration.\nincludedir /etc/krb5.conf.d/\n' /etc/krb5.conf fi Looks like that's the culprit. Good to know, but writing a rpmnew or rpmsave file would be nice to check against the life used file. Agreed! IMO this is a packaging bug. Triggers do not drop rpmsave files. I suspect the chances of getting Red Hat to fix it are slim to none. Fixing it would most likely break other things for them. The samba people are aware of that problem regarding the include line and are working on a patch ? the support at SerNet told me. I agree they are aware of it but I suspect it is a low priority thing given they have known about this since 2016-12-29. I do think it would be relatively easy for SerNet to patch around in their paid for rpms. alas I do not have the budget for them. :-( The bug is available at https://bugzilla.samba.org/show_bug.cgi?id=12488 Regards, -- Tom m...@tdiehl.org ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] gnome-shell killing KDE
I'm running KDE on C7, so why would I have a gnome-shell process spending rather a lot of its time in D mode? -- Michael henne...@web.cs.ndsu.nodak.edu "Sorry but your password must contain an uppercase letter, a number, a haiku, a gang sign, a heiroglyph, and the blood of a virgin." -- someeecards ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Kernel Support
On 06/16/2018 02:15 PM, Stephen John Smoogen via CentOS wrote: > On 15 June 2018 at 21:07, Keith Keller via CentOS wrote: >> On 2018-06-16, Johnny Hughes via CentOS wrote: >>> >>> You agreed to an EULA that says you will not distribute things that you >>> get from that paid subscription. You can do it, and be in violation of >>> the terms of your subscription. >> >> Is this enforceable with the GPLv2? IIRC someone who distributes GPLv2 >> source code is not permitted to restrict other people's ability to >> redistribute. It could be an interesting legal test (that I don't think >> CentOS should test :) ) >> > > This gets asked every couple of months for the last 18+ years. This > has been the model that pretty much every enterprise company from > Cygnus before Red Hat merged with it, to SuSE and Red Hat enforce > their contracts. RMS has probably answered it so many times that he > has an autoresponder on it.. so I would say ask him and see what he > says. > > The general way it has been said is that this does not equal what the > law sees as an additional restriction on the code. The restriction is > on the support contract you have with Red Ha which is not promised in > the GPL as being a right you have. The only licenses which do provide > that amount and more requirements are code which are covered under the > AGPL. Right .. they aren't saying you can not distribute .. they are saying if you chose to distribute to non customers .. you can't subscribe. That is not the same thing. Given that they only do that for extended support items only, and that they open source everything they buy from other companies, and allow for 10 years of building for CentOS. It seems to be they are very much more open than most, I don't see why its a problem to pay them for the very extended support .. since that is very much harder to maintain than even the normal backporting and releasng of security updates that they do (and provide to all, NOT just customers). That is, of course, a personal opinion. signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Passwords in plain text
> Date: Monday, June 18, 2018 07:57:56 -0500 > From: Valeri Galtsev >> I agree with you .. unfortunately, gmail does not. They have >> enabled it for gmail users .. so if someone from yahoo xends a >> mail from a yahoo address, it gets rejected by gmail accounts. >> The list setting wrt dmarc doesn't matter .. it is totally gmail >> enabling it. >> >> What our settings do is NOT send the From (as the original >> sender), if the sender is on a domain where dmarc is enabled, so >> that gmail does not reject it. >> >> If it is rejected by gmail .. it causes (eventually) .. not he >> sender's, but the recipient's account on gmail to be disabled by >> the mailing list as non-existent. > > I'm surprised no one arrived at conclusion: don't use gmail then. > > Valeri > >> [OT] My (non-gmail) mail hosting provider also enforces the DMARC settings that others put in place, so this isn't (just) a gmail issue. Most people in the field find the p=reject setting that yahoo is using to be less than optimal, and come to the conclusion that the best course of action it to avoid sending mail (specifically to mailing lists) from such providers. All places like my provider and gmail are doing is enforcing the standard. That others have selected poorly considered settings is the fault of the site making those selections, not the site doing the enforcing of the standard. [the DMARC notifications are, in my view, a very serious privacy leak, so it should be avoided, but that's a whole separate off-topic discussion.] - Richard ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Passwords in plain text
On Mon, June 18, 2018 7:10 am, Johnny Hughes wrote: > On 06/17/2018 11:13 AM, Alice Wonder via CentOS wrote: >> On 06/17/2018 09:11 AM, Alice Wonder via CentOS wrote: >>> On 06/17/2018 08:52 AM, Michael Hennebry via CentOS wrote: I'm petty sure I messed up attributions, so am deleting them. >> I believe this is a DMARC issue. Yahoo, among other places, has set >> their dmarc records to p=reject: >> So, if your mail hosting provider enforces dmarc,(gmail does) and >> you >> get mail from a list that doesn't rewrite the headers, and people >> from places like yahoo post to the list, you'll likely get some form >> of warning about being being kicked off the mailing list every now >> and then. The frequency depends on how often people from p=reject >> places post, and what the settings are for bounce handling of the >> mailing list in question. > This is indeed what happened. An email from yahoo.com.uk caused > gmail > to reject all the mails sent by that user because of the yahoo DMARC > settings. Say it isn't so: *An* e-mail, just *one* from yahoo.com.uk caused every gmail user to have his account disabled. I'd heard of the DMARC thing with mailing lists before, but had not known it enabled single e-mails of mass destruction. >>> >>> I run dmarc on my mail server but only in report mode, it doesn't >>> reject. >>> >>> I did it as a test (for years) and am fully convinced that dmarc is >>> worthless for real world protection. >>> >>> Numerous mail lists out there are configured in such a way that dmarc >>> gets triggered and that just isn't going to change. >>> >>> It's a neat idea but it's not backwards compatible with the way SMTP >>> already works. >>> >>> I can not recommend its use. I do recommend mail server software update >>> if possible to be compatible but I just can not recommend mail servers >>> enforce dmarc. >>> >>> DKIM is a good thing, but dmarc breaks things too badly. >>> >>> Even DKIM though is of limited usefulness - it seems the spammer >>> blacklists don't really care. Even with proper DKIM signature on a >>> domain with correct reverse DNS set up for years, they will still add >>> you to the spam blacklist if any other host on your subnet is >>> identified >>> as a spammer. >>> >>> So even the blacklists don't really utilize this anti-spam anti-spoof >>> technology, which makes it kind of worthless. >>> >>> Using DKIM as one of several factors in spamassassin though is possibly >>> helpful, though most spammers these days have a validating DKIM sig. >>> >>> ___ >> >> >> Let me put it this way - in the several years of running dmarc is report >> only mode, over 99% of reported violations are false positives from mail >> lists. >> >> That high of a false positive rate tells me it is broken technology. Fully agree. > > I agree with you .. unfortunately, gmail does not. They have enabled it > for gmail users .. so if someone from yahoo xends a mail from a yahoo > address, it gets rejected by gmail accounts. The list setting wrt dmarc > doesn't matter .. it is totally gmail enabling it. > > What our settings do is NOT send the From (as the original sender), if > the sender is on a domain where dmarc is enabled, so that gmail does not > reject it. > > If it is rejected by gmail .. it causes (eventually) .. not he sender's, > but the recipient's account on gmail to be disabled by the mailing list > as non-existent. I'm surprised no one arrived at conclusion: don't use gmail then. Valeri > > What the change that Brian and I tried to make, and Fabian finally fixed > :D (thanks Fabian), is to fix that only from doamins that enable dmarc > (ie, yahoo.* ) so that domains who turn on dmarc as enforcing (ie gmail) > do not cause rejects of those emails. > > > ___ > CentOS mailing list > CentOS@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 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Passwords in plain text
On 06/17/2018 11:13 AM, Alice Wonder via CentOS wrote: > On 06/17/2018 09:11 AM, Alice Wonder via CentOS wrote: >> On 06/17/2018 08:52 AM, Michael Hennebry via CentOS wrote: >>> I'm petty sure I messed up attributions, so am deleting them. >>> > I believe this is a DMARC issue. Yahoo, among other places, has set > their dmarc records to p=reject: >>> > So, if your mail hosting provider enforces dmarc,(gmail does) and you > get mail from a list that doesn't rewrite the headers, and people > from places like yahoo post to the list, you'll likely get some form > of warning about being being kicked off the mailing list every now > and then. The frequency depends on how often people from p=reject > places post, and what the settings are for bounce handling of the > mailing list in question. >>> This is indeed what happened. An email from yahoo.com.uk caused gmail to reject all the mails sent by that user because of the yahoo DMARC settings. >>> >>> Say it isn't so: *An* e-mail, just *one* from yahoo.com.uk >>> caused every gmail user to have his account disabled. >>> >>> I'd heard of the DMARC thing with mailing lists before, >>> but had not known it enabled single e-mails of mass destruction. >> >> I run dmarc on my mail server but only in report mode, it doesn't reject. >> >> I did it as a test (for years) and am fully convinced that dmarc is >> worthless for real world protection. >> >> Numerous mail lists out there are configured in such a way that dmarc >> gets triggered and that just isn't going to change. >> >> It's a neat idea but it's not backwards compatible with the way SMTP >> already works. >> >> I can not recommend its use. I do recommend mail server software update >> if possible to be compatible but I just can not recommend mail servers >> enforce dmarc. >> >> DKIM is a good thing, but dmarc breaks things too badly. >> >> Even DKIM though is of limited usefulness - it seems the spammer >> blacklists don't really care. Even with proper DKIM signature on a >> domain with correct reverse DNS set up for years, they will still add >> you to the spam blacklist if any other host on your subnet is identified >> as a spammer. >> >> So even the blacklists don't really utilize this anti-spam anti-spoof >> technology, which makes it kind of worthless. >> >> Using DKIM as one of several factors in spamassassin though is possibly >> helpful, though most spammers these days have a validating DKIM sig. >> >> ___ > > > Let me put it this way - in the several years of running dmarc is report > only mode, over 99% of reported violations are false positives from mail > lists. > > That high of a false positive rate tells me it is broken technology. I agree with you .. unfortunately, gmail does not. They have enabled it for gmail users .. so if someone from yahoo xends a mail from a yahoo address, it gets rejected by gmail accounts. The list setting wrt dmarc doesn't matter .. it is totally gmail enabling it. What our settings do is NOT send the From (as the original sender), if the sender is on a domain where dmarc is enabled, so that gmail does not reject it. If it is rejected by gmail .. it causes (eventually) .. not he sender's, but the recipient's account on gmail to be disabled by the mailing list as non-existent. What the change that Brian and I tried to make, and Fabian finally fixed :D (thanks Fabian), is to fix that only from doamins that enable dmarc (ie, yahoo.* ) so that domains who turn on dmarc as enforcing (ie gmail) do not cause rejects of those emails. signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Updated krb5 rpm package altered existing krb5.conf - No go
> Am 15.06.2018 um 01:04 schrieb Gordon Messmer : > > On 06/14/2018 09:30 AM, m...@tdiehl.org wrote: >> On Thu, 14 Jun 2018, Richard Grainger wrote: >> >>> I looked at the spec file in the source RPM for the krb5-libs package >>> and it it has the correct %config(noreplace) directive next to that >>> file in the %files section, so this is mysterious. >> >> I too can confirm this behavior. > > # rpm -qa krb\* --triggers > triggerun scriptlet (using /bin/sh) -- krb5-libs < 1.15.1-13 > if ! grep -q 'includedir /etc/krb5.conf.d' /etc/krb5.conf ; then > sed -i '1i # Other applications require this directory to perform krb5 > configuration.\nincludedir /etc/krb5.conf.d/\n' /etc/krb5.conf > fi > > > Looks like that's the culprit. Good to know, but writing a rpmnew or rpmsave file would be nice to check against the life used file. The samba people are aware of that problem regarding the include line and are working on a patch … the support at SerNet told me. Regards . Götz ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
