«systemctl set-property user-1009.slice CPUQuota = 50%» - Не удалось задать свойства единиц для user-1009.slice: Unit user-1009.slice не загружен
К сожалению, это действительно сложно; rpm не предназначен для движения в обратном направлении. Если вы хотите попробовать, я думаю, это должно сработать:
sudo dnf --releasever=23 --allowerasing downgrade fedora-release
sudo dnf distro-sync
Обратите внимание, что это опасно - - разрешить удаление вариант определенно позволяет вам выстрелить себе в ногу и выполнить дистрибутив -sync может не работать.
Вместо этого я мог бы подумать о том, чтобы просто остаться на Rawhide в течение цикла Fedora 23. Мы (отказ от ответственности - я работаю над Fedora!) Иногда вызывают некоторые проблемы там, но если вы следите за блогами, такими как Кевин Фенци This Week in Rawhide , вы обычно можете знать, когда они могут произойти, и будьте осторожны с обновления.
Специалистам по DNS давно известно, что если вам нужна отказоустойчивость службы DNS в любой сети, вы не оставляете это решение на усмотрение клиента.
Это слишком важное решение — оставить на усмотрение распознавателя реализацию клиентов.
Хотя теоретически клиенты должны возвращаться ко 2-му DNS в случае сбоя 1-го, часто этого не происходит по нескольким причинам. За годы своей карьеры я видел огромные сбои в полных сетях, когда люди реализовывали вещи, рассчитывая на то, что распознаватель клиентской операционной системы достаточно умен.
Обычно вы делаете то же, что и корневые серверы имен, то есть создаете DNS-кластеры для получения виртуальных IP-адресов ваших DNS-серверов. Чаще всего для этого используется технология DNS anycast. Вы также можете попробовать более простые архитектуры, такие как использование keepdalived.
Однако, что бы вы ни делали, я подчеркиваю, что не оставляйте это решение на усмотрение клиента.
см. Anycast IPv4 с Linux и Quagga
The traditional safeguard is to establish multiple DNS servers for a given site. Each DNS client on the network is configured with each of those servers' IP addresses. The chances of all of those servers failing in a catastrophic way are fairly small, so you have a margin of safety.
On the other hand, many stub resolvers will take only two DNS servers, making it nearly impossible to have any meaningful geographical dispersion in your DNS topology. DNS stub resolvers generally use the first of two configured DNS servers exclusively. Consequently, you end up with one server taking the entire query load and one idling, waiting for a failure. Not optimal, but hey, that's the price of redundancy...right? It doesn't have to be.
DNS redundancy and failover is a classic use case for anycast. Anycast is the concept of taking one IP address and sharing it between multiple servers, each unaware of the others. The DNS root nameservers make extensive use of anycast.
ПС. В прошлом я внедрил Anycast DNS с iBGP и OSPF у двух интернет-провайдеров и в одном университете, что значительно улучшило доступность службы DNS во время безотказной работы.