Re: [CentOS] how to increase DNS reliability?

[Warren Young]

On Jul 25, 2019, at 5:42 PM, Nataraj  wrote:
> 
> On 7/25/19 4:31 PM, Nataraj wrote:
>> It doesn't really help those clients I can not run name servers on,
>> though.
> 
> Another alternative is to look at the multicast dns (mdns) protocol.

That’s for allowing a device to self-advertise its own name, along with other 
things, like available services.  If you have such devices, then configuring 
the other machines on the network to pay attention to such advertisements 
allows them to see the new names and services when they appear.

…And much more importantly, when they *disappear*, since many 
ZeroConf/Bonjour/Avahi/mDNS speaking devices are mobile and aren’t always 
available.

This protocol is one common way for network printers to advertise their 
services, for example.  (The other common way is SMB/CIFS.)

> I'm pretty sure it's inplemented in avahi daemon

Yes, that’s an implementation of mDNS for POSIX type systems.  

> If your client supports
> it then I would think that all you have to do is enable it.

I’m not sure how this is relevant here.  For mDNS to be the solution to the 
OP’s problems, he’d have to also have mDNS multicasts going out advertising 
services, so the Avahi daemon would have something to offer when a compatible 
program comes along looking for services to connect to.

I suppose you could use mDNS in datacenter type environments, but it’s a long 
way away from the protocol’s original intent.

You could imagine a load balancer that paid attention to mDNS advertisements to 
decide who’s available at the moment.  But I don’t know of any such 
implementation.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] how to increase DNS reliability?

[Nataraj]

On 7/26/19 6:52 AM, Giles Coochey wrote:
>
> On 26/07/2019 14:45, Leroy Tennison wrote:
>> This brings up one of the caveats for (at least ISC) DNS, if the
>> master goes down the slaves will take over for a time but eventually
>> will stop serving for the domains of the master if it remains down
>> too long.  If my (sometimes faulty) memory serves me well it is in
>> the three day range (but configurable) which is ample time unless the
>> problem occurs early in a holiday weekend and and the
>> notification/escalation process isn't what it should be (Murphey's
>> Law)...
>
> The value you refer to is the SOA record _expire_ value for a zone, I
> believe is should be set to between 14 and 28 days.
>
> https://en.wikipedia.org/wiki/SOA_record
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos


If you administer the secondary slave servers, there is no reason not to
use a very large number, 30 days or more for the SOA expiration.  Only
reason to use a lower number would be if you don't have control over the
slave servers and don't want to have old zone files that you can't update.

Another alternative, which many people did for years in the early days
when zone transfers were unreliable, is to use a script which replicates
the entire DNS configuration to the secondaries and then run all the
servers as primary masters.  If the script is written cleanly, you can
then edit the zone on any server and rsync it to the other servers. 
Main thing is to prevent multiple people applying updates simultaneously.

Nataraj


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

[CentOS] C7, acpi_als

[mark]

This is an odd one: I've got a user with a system I built recently, who
comes to me to tell me the systems' frozen. I just looked this time,
before I did an init 3/init 5, and you can't click on anything... except
when I click on the uppermost right, and then I see wired, network and it
flashes, over and over. I finally restarted X.

Now, in the logs, I see a bunch of
Jul 26 11:01:51  pkexec[29723]: : Executing command
[USER=root] [TTY=unknown] [CWD=/home/]
[COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 89]

What little I can find sounds as though acpi_als is for a device that's
checking the ambient light... NOT for a real monitor on a workstation.

The other thing is that she says she's got screensaver set for five
minutes, but it seem to come up much sooner, and then we've got this
issue.

There were no clues in journalctl, or /var/log/messages.

Questions:
1. Anyone ever seen something like this?
2. Any reason I shouldn't blacklist acpi_als?

 mark

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

Re: [CentOS] how to increase DNS reliability?

[Giles Coochey]

On 26/07/2019 14:45, Leroy Tennison wrote:

This brings up one of the caveats for (at least ISC) DNS, if the master goes 
down the slaves will take over for a time but eventually will stop serving for 
the domains of the master if it remains down too long.  If my (sometimes 
faulty) memory serves me well it is in the three day range (but configurable) 
which is ample time unless the problem occurs early in a holiday weekend and 
and the notification/escalation process isn't what it should be (Murphey's 
Law)...


The value you refer to is the SOA record _expire_ value for a zone, I 
believe is should be set to between 14 and 28 days.


https://en.wikipedia.org/wiki/SOA_record


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

Re: [CentOS] how to increase DNS reliability?

[Leroy Tennison]

This brings up one of the caveats for (at least ISC) DNS, if the master goes 
down the slaves will take over for a time but eventually will stop serving for 
the domains of the master if it remains down too long.  If my (sometimes 
faulty) memory serves me well it is in the three day range (but configurable) 
which is ample time unless the problem occurs early in a holiday weekend and 
and the notification/escalation process isn't what it should be (Murphey's 
Law)...


From: CentOS  on behalf of Nataraj 

Sent: Thursday, July 25, 2019 6:31:26 PM
To: centos@centos.org 

Harriscomputer

Register now for the dataVoice User Conference,
October 9-11 at the Gaylord Rockies in Denver, CO.
To register click Here


Leroy Tennison
Network Information/Cyber Security Specialist
E: le...@datavoiceint.com


[cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]


2220 Bush Dr
McKinney, Texas
75070
www.datavoiceint.com


This message has been sent on behalf of a company that is part of the Harris 
Operating Group of Constellation Software Inc. These companies are listed 
here.

If you prefer not to be contacted by Harris Operating Group please notify 
us.



This message is intended exclusively for the individual or entity to which it 
is addressed. This communication may contain information that is proprietary, 
privileged or confidential or otherwise legally exempt from disclosure. If you 
are not the named addressee, you are not authorized to read, print, retain, 
copy or disseminate this message or any part of it. If you have received this 
message in error, please notify the sender immediately by e-mail and delete all 
copies of the message.





Subject: [EXTERNAL] Re: [CentOS] how to increase DNS reliability?

On 7/25/19 1:10 PM, hw wrote:
>>
>> Configure all dns servers as primary slaves (plus 1 primary master) for
>> your own domains.  I have never seen problems with resolution of local
>> dns domains when the Internet was down.
>
> It seemed to have to do with the TTL for the local names being too
> short and DNS being designed to generally query root servers rather
> than sticking to their local information.


It has nothing to do with the ttl. The TTL does cause expiration in an
authoritative server.  TTLs only affect  caching servers.  The primary
master gets changed when you edit the local zone database.  The
secondary slave gets updated when the serial number in the SOA record on
the primary master gets bumped.   You must either do that manually or
use a zone database management tool that does it for you.

If a dns server is configured as a primary master or a secondary slave
for a domain, then it is authoritative for that domain and does not
require queries to any other server on your network or on the Internet.
The difference between a primary master and a secondary slave is the
primary master is where you edit the zone records and the secondary
slave replicates the zone database from the primary master.  Even if the
primary master goes down, the secondary slave still has a copy of the
zone files in it's disk files (or other database format that you
configure) and will server them flawlessly.

One way to see if a server is properly configured as authoritative for a
domain is:

nataraj@pygeum:~$ dig mydomain.com. soa @127.0.0.1

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> mydomain.com. soa@127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52104
;; flags: qr *aa* rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 64f402c0c22d57aa2bbb10fc5d3a340d8c19377b924d01c2 (good)
;; QUESTION SECTION:
;mydomain.com.INSOA

;; ANSWER SECTION:
Mydomain.Com.14400INSOAns1.mydomain.com.
postmaster.Mydomain.COM. 2019072505 1200 600 15552000 14400

;; AUTHORITY SECTION:
Mydomain.Com.14400INNSns1.Mydomain.Com.
Mydomain.Com.14400INNSns2.Mydomain.Com.
Mydomain.Com.14400INNSns3.Mydomain.com.

;; ADDITIONAL SECTION:
ns1.mydomain.com.14400INA8.8.8.8

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 25 15:58:21 PDT 2019
;; MSG SIZE  rcvd: 243

The AA flag in the flags section tells you that you have queried a dns
server that is authoritative for the domain that you queried.  If it
doesn't have the AA flag then you have not properly set up the primary
master or secondary slave for that domain.

If your masters and slaves are all configured correctly for a domain
then they will all have the same serial number  in the SOA record (and
same results for any query in that domain).  If they don't then
something is wrong and your zone transfers are not occuring properly.


>
>> Depending on the 

Re: [CentOS] Fastboot and Google pixel 3a

[Nux!]

I've had to use newer than stock/epel packages in the past for various 
phones.

Just get the latest binaries from here:
https://dl.google.com/android/repository/platform-tools-latest-linux.zip

hth

---
Sent from the Delta quadrant using Borg technology!

On 2019-07-26 03:28, H wrote:

Has anyone used fastboot together with the Google Pixel 3a/3a XL
phone? I cannot get it to be recognized and wonder if the version of
fastboot available for Centos 7 may not be recent enough? It does work
with older phones I have so the setup should be correct.

___
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