Re: [CentOS] bcachefs-tools

2019-07-25 Thread Mike
On Thu, Jul 25, 2019 at 10:45 AM Nux!  wrote:
>
> You could try to get this slightly old rpm, save you the build troubles
> (untested):
> http://ftp5.gwdg.de/pub/opensuse/repositories/home:/garloff:/storage/RHEL_7/x86_64/

Thanks I may go back to this repo if I can't get it done with more
current packages.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] Fastboot and Google pixel 3a

2019-07-25 Thread H
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


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread Nataraj
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.  I
have no experience with it, so I can't say very much, but I know it
exists.  I'm pretty sure it's inplemented in avahi daemon, so it may
just be an issue of enabling it on the client.  If your client supports
it then I would think that all you have to do is enable it.

Nataraj

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


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread Nataraj
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.            IN    SOA

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

;; AUTHORITY SECTION:
Mydomain.Com.        14400    IN    NS    ns1.Mydomain.Com.
Mydomain.Com.        14400    IN    NS    ns2.Mydomain.Com.
Mydomain.Com.        14400    IN    NS    ns3.Mydomain.com.

;; ADDITIONAL SECTION:
ns1.mydomain.com.        14400    IN    A    8.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 size of your network, you can run a caching server on
>> each host (configured as a primary slave for your own domains) and  then
>> configure that local server to use forwarders.  When you use multiple
>> forwarders the local server does not have to wait for timeouts before
>> querying another server.  Then you just run 2 or more servers to use for
>> forwarding.  Use forward-only to force all local servers to use only
>> forwarding (for security and caching reasons).  Much simpler than using
>> keepalived.
>
> Hm.  I thought about something like that, but without the separation
> into local slaves using forwarders and the forwarders.  I will
> probably do that; it seems like the most reasonable solution, and I
> should have at least one forwarder anyway so as not to leak
> information to the internet-only VLANs.  It would be an improvement in
> several ways and give better reliability.


The local server can have forward-only either on or off.  If off, It
will go out directly to the Internet if it does not receive a response
from a forwarder.  Using forward only and putting your forwarders on a
seperate network away from your inside network means if there is a
security hole in the nameserver, your inside hosts are less likely to be
compromised.    You could also configure your ISP's or google or other
public recursive name servers as forwarders if you don't want to run
your own.


>
> It doesn't really help those clients I can not run name servers on,
> though.
>
> > In recent years I *have not had any* problems with bind9 or
>> powerdns crashing.
>>
>> As far as using the ISC server vs powerdns, you may want to check on
>> peoples recent experiences.  There was a time when many thought powerdns
>> had much better performance and fewer security issues.  For various
>> reasons  I've seen some people including myself, switch back to ISC
>> bind9.  I switched about 1.5 years ago because I 

Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread Giles Coochey


On 25/07/2019 22:17, Giles Coochey wrote:


Separate DNS servers must be on a different subnet according to 
RFC2182 (https://tools.ietf.org/html/rfc2182):


Secondary servers must be placed at both topologically and
   geographically dispersed locations on the Internet, to minimise the
   likelihood of a single failure disabling all of them.

I know that UPSs are physical, and subnets are logical, but the 
reasoning behind the requirement is due to having to be on a different 
infrastructure.


__


Shock horror, replying to my own post, but in cloud cluster 
environments, you might consider anti-affinity rules to prevent multiple 
name servers going down at the same time due to a cluster node failure 
(i.e. rules to ensure that hypervisors keep different name servers on 
different hosts).


I know it doesn't help OP, who was looking for cluster based solutions, 
but the same applies if using load balancing virtual appliances, hosting 
IPs as name servers.



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


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread Giles Coochey



On 25/07/2019 20:39, John Pierce wrote:

On Thu, Jul 25, 2019 at 10:32 AM hw  wrote:


I can't help it when the primary name server goes down because the UPS
fails
the self test and tells the server it has 2 minutes or so left in wich case
the server figures it needs to shut down.  I wanted better UPSs ...


critical infrastructure servers should have redudant PSUs, on seperate UPSs.


Separate DNS servers must be on a different subnet according to RFC2182 
(https://tools.ietf.org/html/rfc2182):


Secondary servers must be placed at both topologically and
   geographically dispersed locations on the Internet, to minimise the
   likelihood of a single failure disabling all of them.

I know that UPSs are physical, and subnets are logical, but the 
reasoning behind the requirement is due to having to be on a different 
infrastructure.


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


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread hw

On 7/25/19 7:10 PM, Nataraj wrote:

[...]

I meant to say:

Configure all dns servers as secondary/slaves (one should be the primary 
master) for your own domains.  Thos means that all of your servers are 
authoritative for your own domains, so they cannot fail on local dns lookups 
due to Internet problems.


Ah!?

When I had it happen a couple years ago and wondered why even local 
names couldn't be resolved (which didn't make sense to me because the 
server would always know about them from the zone files), I was told 
that nothing could be done about it because DNS is designed to do 
lookups no matter what.


However, that was a server acting as both a local master and as a 
forwarder.  If what you say is true, I would now understand this much 
better --- and I'd need to change my setup.

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


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread Paul Heinlein

On Thu, 25 Jul 2019, hw wrote:


 On Linux systems, you can set the timeout in /etc/resolv.conf, e.g.,

#  I think the default nameserver timeout is 5; use rotate
#  option if you prefer round-robin queries rather than
#  always using the first-listed first
 nameserver 10.11.12.13 timeout:2 rotate
 nameserver 10.11.12.14 timeout:2 rotate

 I'll admit that I'm not sure if those options are configurable on
 Mac and/or Windows workstations.


It was those showing problems.

Only 5 seconds isn't long enough that I would expect any problems. 
What do I need to put into the ifcf files or tell nmcli to set these 
options?


If you're using dhclient to manage addresses, then you can add the 
RES_OPTIONS variable to /etc/sysconfig/network:


# /etc/sysconfig/network
RES_OPTIONS="timeout:2 rotate"

Or, with even less patience:

RES_OPTIONS="timeout:1 retries:1 rotate"


Grep for RES_OPTIONS in /sbin/dhclient-script for the gory details.

--
Paul Heinlein
heinl...@madboa.com
45°38' N, 122°6' W
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread hw

On 7/25/19 9:39 PM, John Pierce wrote:

On Thu, Jul 25, 2019 at 10:32 AM hw  wrote:


I can't help it when the primary name server goes down because the UPS
fails
the self test and tells the server it has 2 minutes or so left in wich case
the server figures it needs to shut down.  I wanted better UPSs ...



critical infrastructure servers should have redudant PSUs, on seperate UPSs.


right, with hot swappable batteries ...


my last rack builds, I had 2 Eaton PowerWare 7KVA 4U UPS's in the bottom of
each rack.  one fed the left side PDUs, the other fed the right side PDUs,
and each server had redundant PSU's, one plugged into each PDU.

those Eaton UPS's had hotswappable batteries, too.


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


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread hw

On 7/25/19 9:11 PM, mark wrote:

hw wrote:

On 7/25/19 4:07 PM, Giles Coochey wrote:



Sounds like you're performing maintenance on your servers


(a) too often
(b) during office / peak hours



I can't help it when the primary name server goes down because the UPS
fails the self test and tells the server it has 2 minutes or so left in
wich case the server figures it needs to shut down.  I wanted better UPSs
...


Change that. Are you using apcupsd? You can set the config from
SHUTDOWN=/sbin/shutdown to /bin/false. Then, the next time you see the
UPS, change the battery. If it's just started to complain, it's not dead
yet!

Works for me with all of our mostly APC SmartUPS 3000 rackmounts.


I don't remember which UPS it was, either the crappy one for which a 
replacement battery was already waiting to be put in, or the normal one 
that already had a new battery in it which is either broken or doesn't 
get charged ...


That's how I rather have not everything go dark even when Murphy comes 
along.  I have generally deprecated all non-rackmount UPSs, and being 
able to change batteries without outage has become a requirement.

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


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread hw

On 7/25/19 7:58 PM, Paul Heinlein wrote:

On Thu, 25 Jul 2019, hw wrote:


On 7/25/19 3:28 PM, Leroy Tennison wrote:

If you don't want multiple DNS server entries on the client


I'm ok with them, only the problem is that the clients take their 
timeouts

when a server is unreachable, and users panic.


On Linux systems, you can set the timeout in /etc/resolv.conf, e.g.,

# I think the default nameserver timeout is 5; use rotate
# option if you prefer round-robin queries rather than
# always using the first-listed first
nameserver 10.11.12.13 timeout:2 rotate
nameserver 10.11.12.14 timeout:2 rotate

I'll admit that I'm not sure if those options are configurable on Mac
and/or Windows workstations.



It was those showing problems.

Only 5 seconds isn't long enough that I would expect any problems.  What 
do I need to put into the ifcf files or tell nmcli to set these options?

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


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread mark
John Pierce wrote:
> On Thu, Jul 25, 2019 at 10:32 AM hw  wrote:
>
>> I can't help it when the primary name server goes down because the UPS
>> fails the self test and tells the server it has 2 minutes or so left in
>> wich case the server figures it needs to shut down.  I wanted better
>> UPSs ...
>>
> critical infrastructure servers should have redudant PSUs, on seperate
> UPSs.
>
> my last rack builds, I had 2 Eaton PowerWare 7KVA 4U UPS's in the bottom
> of each rack.  one fed the left side PDUs, the other fed the right side
> PDUs, and each server had redundant PSU's, one plugged into each PDU.
> those Eaton UPS's had hotswappable batteries, too.

*shrug* All UPSes have hot-swappable. Mine beep while you disconnect the
batteries, pull out the sled, replace all 8, shove it back in, and
reconnect, and it shuts up.

For those that haven't done it, though, DO NOT BELIEVE WHAT ANYONE SAYS,
DO NOT USE *ANYTHING* BUT HR (high rate) batteries in a UPS (maybe in a
home one, but...). APC, for example, simply stays red, and insists that
you still need to change them. *Good* battery vendors know this.

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


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread hw

On 7/25/19 5:14 PM, Nataraj wrote:

On 7/25/19 6:48 AM, rai...@ultra-secure.de wrote:

Am 2019-07-25 15:41, schrieb hw:

On 7/25/19 2:53 PM, rai...@ultra-secure.de wrote:

Am 2019-07-25 14:51, schrieb hw:

Hi,

how can DNS reliability, as experienced by clients on the LAN who are
sending queries, be increased?

Would I have to set up some sort of cluster consisting of several
servers all providing DNS services which is reachable under a single
IP address known to the clients?

Just setting up several name servers and making them known to the
clients
for the clients to automatically switch isn't a good solution because
the clients take their timeouts and users lacking even the most basic
knowledge inevitably panic when the first name server does not answer
queries.


Run a local cache (unbound) and enter all your local resolvers as
upstreams.


That can fail just as well --- or be even worse when the clients
can't switch
over anymore.  I have that and am avoiding to use it for some clients
because
it takes a while for the cache to get updated when I make changes.

However, if that cache fails, chances are that the internet
connection is also
down in which case it can be troublesome to even get local host names
resolved.
When that happens, trouble is to be expected.



Anything else is - IMHO - much more work, much more complicated and
much more likely to fail, in a more spectacular way.
Especially all those keepalive "solutions".

I have found that I need to restart unbound if all upstreams had failed. 



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.



Depending on the size of your network, you can run a caching server on
each host (configured as a primary slave for your own domains) and  then
configure that local server to use forwarders.  When you use multiple
forwarders the local server does not have to wait for timeouts before
querying another server.  Then you just run 2 or more servers to use for
forwarding.  Use forward-only to force all local servers to use only
forwarding (for security and caching reasons).  Much simpler than using
keepalived.


Hm.  I thought about something like that, but without the separation 
into local slaves using forwarders and the forwarders.  I will probably 
do that; it seems like the most reasonable solution, and I should have 
at least one forwarder anyway so as not to leak information to the 
internet-only VLANs.  It would be an improvement in several ways and 
give better reliability.


It doesn't really help those clients I can not run name servers on, though.

> In recent years I *have not had any* problems with bind9 or

powerdns crashing.

As far as using the ISC server vs powerdns, you may want to check on
peoples recent experiences.  There was a time when many thought powerdns
had much better performance and fewer security issues.  For various
reasons  I've seen some people including myself, switch back to ISC
bind9.  I switched about 1.5 years ago because I was getting better
performance from bind9.  You may want to check out other peoples
experience before switching to powerdns.


Bind has been around for ages, and I've never had any issues with it for 
the last 25 years or so.  Just set it up and let it do its thing, and it 
does.


If there were performance problems, I imagine they would be more likely 
due to insufficient internet bandwidth.  Perhaps it would take all the 
DNS queries that come up during a week or even a month to arrive within 
a second before any performance considerations become relevant ...

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


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread John Pierce
On Thu, Jul 25, 2019 at 10:32 AM hw  wrote:

> I can't help it when the primary name server goes down because the UPS
> fails
> the self test and tells the server it has 2 minutes or so left in wich case
> the server figures it needs to shut down.  I wanted better UPSs ...
>

critical infrastructure servers should have redudant PSUs, on seperate UPSs.

my last rack builds, I had 2 Eaton PowerWare 7KVA 4U UPS's in the bottom of
each rack.  one fed the left side PDUs, the other fed the right side PDUs,
and each server had redundant PSU's, one plugged into each PDU.

those Eaton UPS's had hotswappable batteries, too.


-- 
-john r pierce
  recycling used bits in santa cruz
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread mark
hw wrote:
> On 7/25/19 4:07 PM, Giles Coochey wrote:

>> Sounds like you're performing maintenance on your servers
>>
>>
>> (a) too often
>> (b) during office / peak hours
>>
>
> I can't help it when the primary name server goes down because the UPS
> fails the self test and tells the server it has 2 minutes or so left in
> wich case the server figures it needs to shut down.  I wanted better UPSs
> ...

Change that. Are you using apcupsd? You can set the config from
SHUTDOWN=/sbin/shutdown to /bin/false. Then, the next time you see the
UPS, change the battery. If it's just started to complain, it's not dead
yet!

Works for me with all of our mostly APC SmartUPS 3000 rackmounts.

   mark

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


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread Leon Fauster via CentOS


> Am 25.07.2019 um 19:58 schrieb Paul Heinlein :
> 
> On Thu, 25 Jul 2019, hw wrote:
> 
>> On 7/25/19 3:28 PM, Leroy Tennison wrote:
>>> If you don't want multiple DNS server entries on the client
>> 
>> I'm ok with them, only the problem is that the clients take their timeouts
>> when a server is unreachable, and users panic.
> 
> On Linux systems, you can set the timeout in /etc/resolv.conf, e.g.,
> 
> # I think the default nameserver timeout is 5; use rotate
> # option if you prefer round-robin queries rather than
> # always using the first-listed first
> nameserver 10.11.12.13 timeout:2 rotate
> nameserver 10.11.12.14 timeout:2 rotate

IMO such entries are done via "options" ... 

yum install man-pages ; man resolv.conf

--
LF

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


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread John Pierce
On Thu, Jul 25, 2019 at 11:00 AM Paul Heinlein  wrote:

> On Thu, 25 Jul 2019, hw wrote:
>
> > On 7/25/19 3:28 PM, Leroy Tennison wrote:
> >> If you don't want multiple DNS server entries on the client
> >
> > I'm ok with them, only the problem is that the clients take their
> timeouts
> > when a server is unreachable, and users panic.
>
> On Linux systems, you can set the timeout in /etc/resolv.conf, e.g.,...
>


Windows will 'rotate' the list of NS servers if the top one times out, so
next time it will use the first alternate and if that times out, it
will start using the next alternate, etc.


-- 
-john r pierce
  recycling used bits in santa cruz
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread Paul Heinlein

On Thu, 25 Jul 2019, hw wrote:


On 7/25/19 3:28 PM, Leroy Tennison wrote:

If you don't want multiple DNS server entries on the client


I'm ok with them, only the problem is that the clients take their timeouts
when a server is unreachable, and users panic.


On Linux systems, you can set the timeout in /etc/resolv.conf, e.g.,

# I think the default nameserver timeout is 5; use rotate
# option if you prefer round-robin queries rather than
# always using the first-listed first
nameserver 10.11.12.13 timeout:2 rotate
nameserver 10.11.12.14 timeout:2 rotate

I'll admit that I'm not sure if those options are configurable on Mac
and/or Windows workstations.

--
Paul Heinlein
heinl...@madboa.com
45°38' N, 122°6' W
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread hw
On 7/25/19 4:07 PM, Giles Coochey wrote:
> 
> On 25/07/2019 13:51, hw wrote:
>> Hi,
>>
>> how can DNS reliability, as experienced by clients on the LAN who are
>> sending queries, be increased?
>>
>> Would I have to set up some sort of cluster consisting of several
>> servers all providing DNS services which is reachable under a single
>> IP address known to the clients?
>>
>> Just setting up several name servers and making them known to the clients
>> for the clients to automatically switch isn't a good solution because
>> the clients take their timeouts and users lacking even the most basic
>> knowledge inevitably panic when the first name server does not answer
>> queries.
> 
> Sounds like you're performing maintenance on your servers
> 
> (a) too often
> (b) during office / peak hours

I can't help it when the primary name server goes down because the UPS fails
the self test and tells the server it has 2 minutes or so left in wich case
the server figures it needs to shut down.  I wanted better UPSs ...

> You could load balance multiple servers (using lots of available 
> load-balancing technologies) to allow you to perform maintenance at certain 
> times, but it has its own issues.

Load balancing or clustering?  At least clustering seems not entirely
trivial to do.

> I've recently been looking at PowerDNS, which separates the recursor and the 
> authoritative server into two distinct packages. I'm just running the 
> authoritative server as a master, and keeping my old bind/named servers as 
> recursors / slaves.

This can be done with bind, how does it require something called PowerDNS?

> It's a home
> office network, but I only have issues when I'm tinkering, and if I were to 
> be doing this kind of work in a larger commercial environment, then I would 
> not be doing DNS server maintenance while others were relying on them.

The maintenance didn't cause any problems.  You can edit the configuration
just fine and restart the server when done ... :)

> For much of the back end infrastructure I use IP addresses rather than DNS 
> names in their configuration, just to take DNS issues out of the equation 
> completely.

I think this is a very bad idea because it causes lots of work and is likely to
cause issues.  What if you, for example, migrate remote logging to another 
server?
All the time, you have to document every place where you put an IP address; you
have to keep the documentation always up to date and then change the address at
every place when you make a change.  Forget one place, and things break.

But when you use names instead of addresses, like 'log.example.com', you only
need to make a single change at a single place such as you alter the address
in your name server config.

DNS can be difficult to get right, though it's not all that difficult, and
once it's working, there aren't really any issues other than that a server can
become unreachable.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread hw
On 7/25/19 4:49 PM, Nux! wrote:
> I'm about to do an overhaul of the DNS service at work and my plan is to use 
> powerdns recursor + dnsdist + keepalived.

I've more or less done the overhaul, only some sort of failover thing
is missing ...  I'll check those out, thanks!
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread hw
On 7/25/19 3:28 PM, Leroy Tennison wrote:
> If you don't want multiple DNS server entries on the client

I'm ok with them, only the problem is that the clients take their timeouts
when a server is unreachable, and users panic.

> then a master and (possibly multiple) slave server configuration can be set 
> up (I'm assuming ISC DNS - their solution to redundancy/failover is master 
> and slave servers, this may be the way it is with all DNS).

Yes, bind9, and I've set up a master and a slave.  The router uses them to
forward requests to on behalf of those clients that use the router as a name
server while other clients know master and slave but not the router as name
servers.

There was a failure a while ago (IIRC because of a UPS causing a server to
shut down when the battery failed the self test), and things didn't quite work
anymore with the master server being unreachable.

This is how I have a problem with the clients knowing multiple servers: The
very setup is intended to keep things working during an outage and yet it
doesn't help.

>  keepalived can be used for fail over and will present a single IP address 
> (which the clients would use) shared among the servers.  haproxy or 
> alternatives might be another fail over option.

Thanks, I'll look into that!  I've been searching for "dns proxy" and no useful
results came up ...

> Each technology has its own learning curve (and doing this will require at 
> least two) and caveats.  In particular systemd doesn't appear to play well 
> with technologies creating IP addresses it doesn't manage.  The version of 
> keepalived we're using also has its own nasty quirk as well where it comes up 
> assuming it is master until discovered otherwise, this is true even if it is 
> configured as backup.  In most cases this is probably either a non-issue (no 
> scripts being used) or a minor annoyance.  But if you're using scripts trigger
>  ed by keepalived which make significant (and possibly conflicting) changes 
> to the environment then you'll need to embed "intelligence" in them to wait 
> until final state is reached or test state before acting or some other option.

I consider myself warned :)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread Nataraj
On 7/25/19 8:14 AM, Nataraj wrote:
> On 7/25/19 6:48 AM, rai...@ultra-secure.de wrote:
>> Am 2019-07-25 15:41, schrieb hw:
>>> On 7/25/19 2:53 PM, rai...@ultra-secure.de wrote:
 Am 2019-07-25 14:51, schrieb hw:
> Hi,
>
> how can DNS reliability, as experienced by clients on the LAN who are
> sending queries, be increased?
>
> Would I have to set up some sort of cluster consisting of several
> servers all providing DNS services which is reachable under a single
> IP address known to the clients?
>
> Just setting up several name servers and making them known to the
> clients
> for the clients to automatically switch isn't a good solution because
> the clients take their timeouts and users lacking even the most basic
> knowledge inevitably panic when the first name server does not answer
> queries.
 Run a local cache (unbound) and enter all your local resolvers as
 upstreams.
>>> That can fail just as well --- or be even worse when the clients
>>> can't switch
>>> over anymore.  I have that and am avoiding to use it for some clients
>>> because
>>> it takes a while for the cache to get updated when I make changes.
>>>
>>> However, if that cache fails, chances are that the internet
>>> connection is also
>>> down in which case it can be troublesome to even get local host names
>>> resolved.
>>> When that happens, trouble is to be expected.
>>
>> Anything else is - IMHO - much more work, much more complicated and
>> much more likely to fail, in a more spectacular way.
>> Especially all those keepalive "solutions".
>>
>> I have found that I need to restart unbound if all upstreams had failed. 
>
> 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.

I meant to say:

Configure all dns servers as secondary/slaves (one should be the primary 
master) for your own domains.  Thos means that all of your servers are 
authoritative for your own domains, so they cannot fail on local dns lookups 
due to Internet problems.

>
> Depending on the size of your network, you can run a caching server on
> each host (configured as a primary slave for your own domains) and  then
> configure that local server to use forwarders.  When you use multiple
> forwarders the local server does not have to wait for timeouts before
> querying another server.  Then you just run 2 or more servers to use for
> forwarding.  Use forward-only to force all local servers to use only
> forwarding (for security and caching reasons).  Much simpler than using
> keepalived.  In recent years I *have not had any* problems with bind9 or
> powerdns crashing.
>
> As far as using the ISC server vs powerdns, you may want to check on
> peoples recent experiences.  There was a time when many thought powerdns
> had much better performance and fewer security issues.  For various
> reasons  I've seen some people including myself, switch back to ISC
> bind9.  I switched about 1.5 years ago because I was getting better
> performance from bind9.  You may want to check out other peoples
> experience before switching to powerdns.
>
>
> Nataraj
>
>
> ___
> 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] how to increase DNS reliability?

2019-07-25 Thread Nataraj
On 7/25/19 6:48 AM, rai...@ultra-secure.de wrote:
> Am 2019-07-25 15:41, schrieb hw:
>> On 7/25/19 2:53 PM, rai...@ultra-secure.de wrote:
>>> Am 2019-07-25 14:51, schrieb hw:
 Hi,

 how can DNS reliability, as experienced by clients on the LAN who are
 sending queries, be increased?

 Would I have to set up some sort of cluster consisting of several
 servers all providing DNS services which is reachable under a single
 IP address known to the clients?

 Just setting up several name servers and making them known to the
 clients
 for the clients to automatically switch isn't a good solution because
 the clients take their timeouts and users lacking even the most basic
 knowledge inevitably panic when the first name server does not answer
 queries.
>>>
>>> Run a local cache (unbound) and enter all your local resolvers as
>>> upstreams.
>>
>> That can fail just as well --- or be even worse when the clients
>> can't switch
>> over anymore.  I have that and am avoiding to use it for some clients
>> because
>> it takes a while for the cache to get updated when I make changes.
>>
>> However, if that cache fails, chances are that the internet
>> connection is also
>> down in which case it can be troublesome to even get local host names
>> resolved.
>> When that happens, trouble is to be expected.
>
>
> Anything else is - IMHO - much more work, much more complicated and
> much more likely to fail, in a more spectacular way.
> Especially all those keepalive "solutions".
>
> I have found that I need to restart unbound if all upstreams had failed. 


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.

Depending on the size of your network, you can run a caching server on
each host (configured as a primary slave for your own domains) and  then
configure that local server to use forwarders.  When you use multiple
forwarders the local server does not have to wait for timeouts before
querying another server.  Then you just run 2 or more servers to use for
forwarding.  Use forward-only to force all local servers to use only
forwarding (for security and caching reasons).  Much simpler than using
keepalived.  In recent years I *have not had any* problems with bind9 or
powerdns crashing.

As far as using the ISC server vs powerdns, you may want to check on
peoples recent experiences.  There was a time when many thought powerdns
had much better performance and fewer security issues.  For various
reasons  I've seen some people including myself, switch back to ISC
bind9.  I switched about 1.5 years ago because I was getting better
performance from bind9.  You may want to check out other peoples
experience before switching to powerdns.


Nataraj


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


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread Nux!
I'm about to do an overhaul of the DNS service at work and my plan is to 
use powerdns recursor + dnsdist + keepalived.



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

On 2019-07-25 14:28, Leroy Tennison wrote:

If you don't want multiple DNS server entries on the client then a
master and (possibly multiple) slave server configuration can be set
up (I'm assuming ISC DNS - their solution to redundancy/failover is
master and slave servers, this may be the way it is with all DNS).
keepalived can be used for fail over and will present a single IP
address (which the clients would use) shared among the servers.
haproxy or alternatives might be another fail over option.  Each
technology has its own learning curve (and doing this will require at
least two) and caveats.  In particular systemd doesn't appear to play
well with technologies creating IP addresses it doesn't manage.  The
version of keepalived we're using also has its own nasty quirk as well
where it comes up assuming it is master until discovered otherwise,
this is true even if it is configured as backup.  In most cases this
is probably either a non-issue (no scripts being used) or a minor
annoyance.  But if you're using scripts trigger
 ed by keepalived which make significant (and possibly conflicting)
changes to the environment then you'll need to embed "intelligence" in
them to wait until final state is reached or test state before acting
or some other option.


From: CentOS  on behalf of hw 
Sent: Thursday, July 25, 2019 7:51:39 AM
To: centos@centos.org 
Subject: [EXTERNAL] [CentOS] how to increase DNS reliability?


Hi,

how can DNS reliability, as experienced by clients on the LAN who are
sending queries, be increased?

Would I have to set up some sort of cluster consisting of several
servers all providing DNS services which is reachable under a single
IP address known to the clients?

Just setting up several name servers and making them known to the 
clients

for the clients to automatically switch isn't a good solution because
the clients take their timeouts and users lacking even the most basic
knowledge inevitably panic when the first name server does not answer
queries.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

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.




___
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] bcachefs-tools

2019-07-25 Thread Nux!
You could try to get this slightly old rpm, save you the build troubles 
(untested):

http://ftp5.gwdg.de/pub/opensuse/repositories/home:/garloff:/storage/RHEL_7/x86_64/

Bare in mind there is no support in the stock kernel for bcachefs 
(afaik), you  might have better luck with the elrepo kernel-ml.


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

On 2019-07-25 14:45, Mike wrote:

Hello,

I want to test bachefs file system on CentOS 7.
~$  cat /etc/system-release
CentOS Linux release 7.6.1810 (Core)

I'm following the bcachefs howto:  https://bcachefs.org/Howto/.

Having  a problem trying to complete make && make install of the 
bcache-tools.

After going through all the dependencies and insuring they are
installed on Cent 7, I get the following output on make && make
install:

Package blkid was not found in the pkg-config search path.
Perhaps you should add the directory containing `blkid.pc'
to the PKG_CONFIG_PATH environment variable
No package 'blkid' found
Package uuid was not found in the pkg-config search path.
Perhaps you should add the directory containing `uuid.pc'
to the PKG_CONFIG_PATH environment variable
No package 'uuid' found
Package libsodium was not found in the pkg-config search path.
Perhaps you should add the directory containing `libsodium.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libsodium' found
Package libzstd was not found in the pkg-config search path.
Perhaps you should add the directory containing `libzstd.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libzstd' found
Makefile:42: *** pkg-config error, command: pkg-config --cflags "blkid
uuid liburcu libsodium zlib liblz4 libzstd".  Stop.

The packages are installed but I'm not certain how to satisfy
pkg-config and place them in the correct path.

The pkg-config man page states -
ENVIRONMENT VARIABLES
   PKG_CONFIG_PATH
A colon-separated (on Windows, semicolon-separated) list of
directories to search for .pc files.   The  default  directory  will
always  be searched  after  searching the path; the default is
libdir/pkgconfig:datadir/pkgconfig where libdir is the libdir for
pkg-config and datadir is the datadir for pkg-config when it was
installed.

On my installation, the current path seems to be:
~$ pkg-config --variable pc_path pkg-config
/usr/lib64/pkgconfig:/usr/share/pkgconfig

~$ echo $PKG_CONFIG_PATH
<>

Using locate, I do not find any of these files, so how do I properly
add the packages to the path --
`blkid.pc'
`uuid.pc'
`libsodium.pc'
`libzstd.pc'

Thanks for reading and I appreciate any guidance.

Best,

Mike
___
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] how to increase DNS reliability?

2019-07-25 Thread hw
On 7/25/19 3:48 PM, rai...@ultra-secure.de wrote:
> Am 2019-07-25 15:41, schrieb hw:
>> On 7/25/19 2:53 PM, rai...@ultra-secure.de wrote:
>>> Am 2019-07-25 14:51, schrieb hw:
 Hi,

 how can DNS reliability, as experienced by clients on the LAN who are
 sending queries, be increased?

 Would I have to set up some sort of cluster consisting of several
 servers all providing DNS services which is reachable under a single
 IP address known to the clients?

 Just setting up several name servers and making them known to the clients
 for the clients to automatically switch isn't a good solution because
 the clients take their timeouts and users lacking even the most basic
 knowledge inevitably panic when the first name server does not answer
 queries.
>>>
>>> Run a local cache (unbound) and enter all your local resolvers as upstreams.
>>
>> That can fail just as well --- or be even worse when the clients can't switch
>> over anymore.  I have that and am avoiding to use it for some clients because
>> it takes a while for the cache to get updated when I make changes.
>>
>> However, if that cache fails, chances are that the internet connection is 
>> also
>> down in which case it can be troublesome to even get local host names 
>> resolved.
>> When that happens, trouble is to be expected.
> 
> 
> Anything else is - IMHO - much more work, much more complicated

That's what I was thinking.  Perhaps it is better to live with a main server and
one or two slaves so the clients can keep their alternatives.

But still ...  There's got to be a better way ...

> and much more likely to fail, in a more spectacular way.
> Especially all those keepalive "solutions".

You mean like probing if the DNS server is still responsive and somehow 
switching
over when it's not?  I never tried, though it is evident that more complicated
things may tend to be less reliable.

Yet it reminds me that I could actually check the name servers and dispatch a 
message
when one fails as I'm already doing for a couple other things.  That would 
suffice
and doesn't introduce more possibilites of failure to name resolution.

> I have found that I need to restart unbound if all upstreams had failed.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread Giles Coochey



On 25/07/2019 13:51, hw wrote:

Hi,

how can DNS reliability, as experienced by clients on the LAN who are
sending queries, be increased?

Would I have to set up some sort of cluster consisting of several
servers all providing DNS services which is reachable under a single
IP address known to the clients?

Just setting up several name servers and making them known to the clients
for the clients to automatically switch isn't a good solution because
the clients take their timeouts and users lacking even the most basic
knowledge inevitably panic when the first name server does not answer
queries.


Sounds like you're performing maintenance on your servers

(a) too often
(b) during office / peak hours

You could load balance multiple servers (using lots of available 
load-balancing technologies) to allow you to perform maintenance at 
certain times, but it has its own issues.


I've recently been looking at PowerDNS, which separates the recursor and 
the authoritative server into two distinct packages. I'm just running 
the authoritative server as a master, and keeping my old bind/named 
servers as recursors / slaves. It's a home office network, but I only 
have issues when I'm tinkering, and if I were to be doing this kind of 
work in a larger commercial environment, then I would not be doing DNS 
server maintenance while others were relying on them.


For much of the back end infrastructure I use IP addresses rather than 
DNS names in their configuration, just to take DNS issues out of the 
equation completely.


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


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread rainer

Am 2019-07-25 15:41, schrieb hw:

On 7/25/19 2:53 PM, rai...@ultra-secure.de wrote:

Am 2019-07-25 14:51, schrieb hw:

Hi,

how can DNS reliability, as experienced by clients on the LAN who are
sending queries, be increased?

Would I have to set up some sort of cluster consisting of several
servers all providing DNS services which is reachable under a single
IP address known to the clients?

Just setting up several name servers and making them known to the 
clients

for the clients to automatically switch isn't a good solution because
the clients take their timeouts and users lacking even the most basic
knowledge inevitably panic when the first name server does not answer
queries.


Run a local cache (unbound) and enter all your local resolvers as 
upstreams.


That can fail just as well --- or be even worse when the clients can't 
switch
over anymore.  I have that and am avoiding to use it for some clients 
because

it takes a while for the cache to get updated when I make changes.

However, if that cache fails, chances are that the internet connection 
is also
down in which case it can be troublesome to even get local host names 
resolved.

When that happens, trouble is to be expected.



Anything else is - IMHO - much more work, much more complicated and much 
more likely to fail, in a more spectacular way.

Especially all those keepalive "solutions".

I have found that I need to restart unbound if all upstreams had failed.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] bcachefs-tools

2019-07-25 Thread Mike
Hello,

I want to test bachefs file system on CentOS 7.
~$  cat /etc/system-release
CentOS Linux release 7.6.1810 (Core)

I'm following the bcachefs howto:  https://bcachefs.org/Howto/.

Having  a problem trying to complete make && make install of the bcache-tools.
After going through all the dependencies and insuring they are
installed on Cent 7, I get the following output on make && make
install:

Package blkid was not found in the pkg-config search path.
Perhaps you should add the directory containing `blkid.pc'
to the PKG_CONFIG_PATH environment variable
No package 'blkid' found
Package uuid was not found in the pkg-config search path.
Perhaps you should add the directory containing `uuid.pc'
to the PKG_CONFIG_PATH environment variable
No package 'uuid' found
Package libsodium was not found in the pkg-config search path.
Perhaps you should add the directory containing `libsodium.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libsodium' found
Package libzstd was not found in the pkg-config search path.
Perhaps you should add the directory containing `libzstd.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libzstd' found
Makefile:42: *** pkg-config error, command: pkg-config --cflags "blkid
uuid liburcu libsodium zlib liblz4 libzstd".  Stop.

The packages are installed but I'm not certain how to satisfy
pkg-config and place them in the correct path.

The pkg-config man page states -
ENVIRONMENT VARIABLES
   PKG_CONFIG_PATH
A colon-separated (on Windows, semicolon-separated) list of
directories to search for .pc files.   The  default  directory  will
always  be searched  after  searching the path; the default is
libdir/pkgconfig:datadir/pkgconfig where libdir is the libdir for
pkg-config and datadir is the datadir for pkg-config when it was
installed.

On my installation, the current path seems to be:
~$ pkg-config --variable pc_path pkg-config
/usr/lib64/pkgconfig:/usr/share/pkgconfig

~$ echo $PKG_CONFIG_PATH
<>

Using locate, I do not find any of these files, so how do I properly
add the packages to the path --
`blkid.pc'
`uuid.pc'
`libsodium.pc'
`libzstd.pc'

Thanks for reading and I appreciate any guidance.

Best,

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


Re: [CentOS] how to increase DNS reliability?

2019-07-25 Thread hw
On 7/25/19 2:53 PM, rai...@ultra-secure.de wrote:
> Am 2019-07-25 14:51, schrieb hw:
>> Hi,
>>
>> how can DNS reliability, as experienced by clients on the LAN who are
>> sending queries, be increased?
>>
>> Would I have to set up some sort of cluster consisting of several
>> servers all providing DNS services which is reachable under a single
>> IP address known to the clients?
>>
>> Just setting up several name servers and making them known to the clients
>> for the clients to automatically switch isn't a good solution because
>> the clients take their timeouts and users lacking even the most basic
>> knowledge inevitably panic when the first name server does not answer
>> queries.
> 
> Run a local cache (unbound) and enter all your local resolvers as upstreams.

That can fail just as well --- or be even worse when the clients can't switch
over anymore.  I have that and am avoiding to use it for some clients because
it takes a while for the cache to get updated when I make changes.

However, if that cache fails, chances are that the internet connection is also
down in which case it can be troublesome to even get local host names resolved.
When that happens, trouble is to be expected.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] how to increase DNS reliability?

2019-07-25 Thread Leroy Tennison
If you don't want multiple DNS server entries on the client then a master and 
(possibly multiple) slave server configuration can be set up (I'm assuming ISC 
DNS - their solution to redundancy/failover is master and slave servers, this 
may be the way it is with all DNS).  keepalived can be used for fail over and 
will present a single IP address (which the clients would use) shared among the 
servers.  haproxy or alternatives might be another fail over option.  Each 
technology has its own learning curve (and doing this will require at least 
two) and caveats.  In particular systemd doesn't appear to play well with 
technologies creating IP addresses it doesn't manage.  The version of 
keepalived we're using also has its own nasty quirk as well where it comes up 
assuming it is master until discovered otherwise, this is true even if it is 
configured as backup.  In most cases this is probably either a non-issue (no 
scripts being used) or a minor annoyance.  But if you're using scripts trigger
 ed by keepalived which make significant (and possibly conflicting) changes to 
the environment then you'll need to embed "intelligence" in them to wait until 
final state is reached or test state before acting or some other option.


From: CentOS  on behalf of hw 
Sent: Thursday, July 25, 2019 7:51:39 AM
To: centos@centos.org 
Subject: [EXTERNAL] [CentOS] how to increase DNS reliability?


Hi,

how can DNS reliability, as experienced by clients on the LAN who are
sending queries, be increased?

Would I have to set up some sort of cluster consisting of several
servers all providing DNS services which is reachable under a single
IP address known to the clients?

Just setting up several name servers and making them known to the clients
for the clients to automatically switch isn't a good solution because
the clients take their timeouts and users lacking even the most basic
knowledge inevitably panic when the first name server does not answer
queries.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

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.




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


Re: [CentOS] CentOS 8 partiitioning for reliability

2019-07-25 Thread hw
On 7/19/19 11:57 PM, Kenneth Porter wrote:
> I was just given a Dell R720xd with 160 GB memory and 12x 900 GB drives that 
> I plan to deploy as my home mail/file/backup server to replace an aging 
> Supermicro server running CentOS 7. Yeah, it's gross overkill for that and I 
> expect to tuck most of the
> drives away for spares.
> 
> How should I RAID and partition this beast for maximum reliability?

If it can do JBOD, you may want to put FreeBSD on it and use ZFS.

In any case, get two 147GB disks to install the system on and use some
RAID mirror setup to create two logical volumes.  That separates system
from data and leaves you two spares for when a disk fails.

You may want to take out some of the memory and check power consumption
since more memory might consume more power, and you don't need that much.


You probably want to avoid using the strange file system they invented
for 8 because it seems to be a mess made from LVM and xfs, while its RAID
capabilites weren't mentioned in the article I read about it.  Like LVM
sucks badly in that it is extremely inflexible: For example, try to make
a snapshot to a different volume group when the one the volume you want to
make a snapshot of is full ...

Also, how do you limit the size of file systems with the new file system?
The article said each file system can grow to the full size of the pool,
and that is something I certainly wouldn't want because it could crash the
server when one FS chokes another.

> 
> My current C7 system is using 1 TB of 2 TB capacity on the root partition (4x 
> 1 TB drives in RAID 10). /boot is 300MB/50GB. Memory and swap is 8GB each.
> 
> 
> ___
> 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] how to increase DNS reliability?

2019-07-25 Thread rainer

Am 2019-07-25 14:51, schrieb hw:

Hi,

how can DNS reliability, as experienced by clients on the LAN who are
sending queries, be increased?

Would I have to set up some sort of cluster consisting of several
servers all providing DNS services which is reachable under a single
IP address known to the clients?

Just setting up several name servers and making them known to the 
clients

for the clients to automatically switch isn't a good solution because
the clients take their timeouts and users lacking even the most basic
knowledge inevitably panic when the first name server does not answer
queries.


Run a local cache (unbound) and enter all your local resolvers as 
upstreams.


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


[CentOS] how to increase DNS reliability?

2019-07-25 Thread hw


Hi,

how can DNS reliability, as experienced by clients on the LAN who are
sending queries, be increased?

Would I have to set up some sort of cluster consisting of several
servers all providing DNS services which is reachable under a single
IP address known to the clients?

Just setting up several name servers and making them known to the clients
for the clients to automatically switch isn't a good solution because
the clients take their timeouts and users lacking even the most basic
knowledge inevitably panic when the first name server does not answer
queries.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] CentOS-announce Digest, Vol 173, Issue 8

2019-07-25 Thread centos-announce-request
Send CentOS-announce mailing list submissions to
centos-annou...@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-requ...@centos.org

You can reach the person managing the list at
centos-announce-ow...@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-2019:1811 Moderate CentOS 6  java-1.8.0-openjdk Security
  Update (Johnny Hughes)
   2. CESA-2019:1840 Moderate CentOS 6  java-1.7.0-openjdk Security
  Update (Johnny Hughes)
   3. CESA-2019:1810 Moderate CentOS 7 java-11-openjdk  Security
  Update (Johnny Hughes)
   4. CESA-2019:1839 Moderate CentOS 7  java-1.7.0-openjdk Security
  Update (Johnny Hughes)
   5. CESA-2019:1815 Moderate CentOS 7  java-1.8.0-openjdk Security
  Update (Johnny Hughes)


--

Message: 1
Date: Wed, 24 Jul 2019 20:18:47 +
From: Johnny Hughes 
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2019:1811 Moderate CentOS 6
java-1.8.0-openjdk Security Update
Message-ID: <20190724201847.ga19...@bstore1.rdu2.centos.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Security Advisory 2019:1811 Moderate

Upstream details at : https://access.redhat.com/errata/RHSA-2019:1811

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

i386:
054cbcfb7d5d72d191b2ffa3cf35d9fe618dca5c6c594b6433b01885741f  
java-1.8.0-openjdk-1.8.0.222.b10-0.el6_10.i686.rpm
9072f3f3659dcee32d4f710cdbdb0610143ae52c798dccaa9dac152031b2236a  
java-1.8.0-openjdk-debug-1.8.0.222.b10-0.el6_10.i686.rpm
0e88fd7e0d2e591fc7bf9326e8a2b4f93ccc5bc27c8406e865e0134101c0e0f0  
java-1.8.0-openjdk-demo-1.8.0.222.b10-0.el6_10.i686.rpm
f95e0cafe50e0eca6523fbd602f2326383d14d1e4ba7b871394f75fcecb42656  
java-1.8.0-openjdk-demo-debug-1.8.0.222.b10-0.el6_10.i686.rpm
e12cf888912d746c03a82e4d37f19e8da6a8669734f8543d4970cf31e5bd197a  
java-1.8.0-openjdk-devel-1.8.0.222.b10-0.el6_10.i686.rpm
e3d8b764aa8d8f7c0e9b179fb8cc6f7cafcd76ccfa1aeaca835ba1c142108ac0  
java-1.8.0-openjdk-devel-debug-1.8.0.222.b10-0.el6_10.i686.rpm
917b0903c7e94858fe3cbb22477dc02ceffae4b3b86f340f6d84d30c2d637fea  
java-1.8.0-openjdk-headless-1.8.0.222.b10-0.el6_10.i686.rpm
a8e26c6020413fc9d4652538d7791b61d23598444103695630005cefadf91cbb  
java-1.8.0-openjdk-headless-debug-1.8.0.222.b10-0.el6_10.i686.rpm
497d0ba27a779d61dd40c398259c8d0b98a549080b00d1f1f98bac8a80c23854  
java-1.8.0-openjdk-javadoc-1.8.0.222.b10-0.el6_10.noarch.rpm
2f5bbab8f73ea0b3c897c163f5b7bd563713cb1f9d212a4f0ccf8be2a9316298  
java-1.8.0-openjdk-javadoc-debug-1.8.0.222.b10-0.el6_10.noarch.rpm
54bed9db6f36151156c73ed70582501562a9e0d9ac119d5b6959fc4851ee0c3e  
java-1.8.0-openjdk-src-1.8.0.222.b10-0.el6_10.i686.rpm
bd75788a97d65fae0aa1fd8bc3d22dcb39892c44c08795371f2f010eb4094a15  
java-1.8.0-openjdk-src-debug-1.8.0.222.b10-0.el6_10.i686.rpm

x86_64:
aec643bd2c801723bb3b73acf53567eec3754d06400855983dfba0349db7bf66  
java-1.8.0-openjdk-1.8.0.222.b10-0.el6_10.x86_64.rpm
1f63f7fd2a690b8f5de477c2cbd71f11c0e32c7be454ca138b11234938e26f97  
java-1.8.0-openjdk-debug-1.8.0.222.b10-0.el6_10.x86_64.rpm
8a9a64c99cbc83757786018a9c612d29a5d36787064bc39b42be8af127314604  
java-1.8.0-openjdk-demo-1.8.0.222.b10-0.el6_10.x86_64.rpm
6a8cc90f55b8dffee9500d79d998fc30e6d997db8e4905a0563d0ebe2d2289da  
java-1.8.0-openjdk-demo-debug-1.8.0.222.b10-0.el6_10.x86_64.rpm
2893a5a4e5bbc4622811e8158f4d35fe73e3ab2d2874e8a94f7bbb9371f7  
java-1.8.0-openjdk-devel-1.8.0.222.b10-0.el6_10.x86_64.rpm
f77d40de4e89f807262fc799a148efdbaf0067c0596b2741cba532fd5a7fd9d5  
java-1.8.0-openjdk-devel-debug-1.8.0.222.b10-0.el6_10.x86_64.rpm
080dd95cdf28eceb1139c8ce396029046e69b584ac1a6a6cf8a8e0c2ea074dea  
java-1.8.0-openjdk-headless-1.8.0.222.b10-0.el6_10.x86_64.rpm
3fafbfb4022d20148ec0b843b89ca63d3f0ab3bc0fd1d61197db68793379bec0  
java-1.8.0-openjdk-headless-debug-1.8.0.222.b10-0.el6_10.x86_64.rpm
497d0ba27a779d61dd40c398259c8d0b98a549080b00d1f1f98bac8a80c23854  
java-1.8.0-openjdk-javadoc-1.8.0.222.b10-0.el6_10.noarch.rpm
2f5bbab8f73ea0b3c897c163f5b7bd563713cb1f9d212a4f0ccf8be2a9316298  
java-1.8.0-openjdk-javadoc-debug-1.8.0.222.b10-0.el6_10.noarch.rpm
19eadc98e77fccc5597436ef17c7b5523d530e23f2b2acba49e19397ee14341c  
java-1.8.0-openjdk-src-1.8.0.222.b10-0.el6_10.x86_64.rpm
448ce2a17fc55c1c2e92c8f298165c5970ce66818d8a12c43b2adad3681f1aba  
java-1.8.0-openjdk-src-debug-1.8.0.222.b10-0.el6_10.x86_64.rpm

Source:
9cc327553bbaa5c9684c4e4478fbdd178fecd35981a4fd267aca60acac8a3847  
java-1.8.0-openjdk-1.8.0.222.b10-0.el6_10.src.rpm



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




Re: [CentOS] Failed to start crond

2019-07-25 Thread Alexander Dalloz

Am 2019-07-25 11:12, schrieb Tarik Belaam:

Hi,

A couple of days ago, cron service stopped been running on my Centos 6.
When I try to start with "service crond start" I get this error :
"Starting /usr/sbin/crond: [-] Error 0x7a911401 in attaching to
process!"

Any ideas?

Thanks



You do not share much info about your system and what you already did so 
far to debug the situation.


Is only the function of crond affected?

What does running "rpm -Vv cronie" tell you?

Alexander

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


[CentOS] Failed to start crond

2019-07-25 Thread Tarik Belaam
Hi,

A couple of days ago, cron service stopped been running on my Centos 6.
When I try to start with "service crond start" I get this error :
"Starting /usr/sbin/crond: [-] Error 0x7a911401 in attaching to
process!"

Any ideas?

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