Перейти к содержимому


mDNS/DNS-SD is inherently incompatible with unicast DNS zones .local. We strongly recommend not to use Avahi or nss-mdns in such a network setup. N.B.: nss-mdns is not typically bundled with Avahi and requires a separate download and install.

Background: The Zeroconf protocols Avahi implements are known as mDNS and DNS-SD. mDNS (short for Multicast DNS) is based on traditional (unicast) DNS, but the two systems do not interact. mDNS is used to manage a special cooperative zone .local where all local mDNS servers can freely register host names or services. Before mDNS was introduced the domain .local was sometimes used in non-public (unicast) DNS servers to assign names in LANs. Unfortunately some networks still use this domain that way. If Avahi and nss-mdns is installed properly a machine does not contact a unicast DNS server when resolving names from the .local domain, thus the unicast DNS domain .local becomes unreachable.

If you come across a network where .local is a unicast DNS domain, please contact the local administrator and ask him to move his DNS zone to a different domain. If this is not possible, we recommend not to use Avahi in such a network at all.


If you really want to use Avahi with .local as unicast domain, you might want to try the following. YMMV. Don't come running to us if something doesn't work as expected. It's your own fault!

The recommended nss-mdns configuration line for /etc/nsswitch.conf is

This makes nss-mdns authoritative for .local.

If this is changed as follows, unicast DNS will be tried before mDNS for .local, essentially "merging" the unicast and the multicast domain .local, with unicast taking precedence.

Please note that this line will "unbreak" the name service switch (NSS, aka gethostbyname()) only. Avahi itself will still not resolve any hosts from a unicast domain .local. i.e. this change will make some things work, but not all.

Please remember, that we do no recommend using nss-mdns in this way. Why? Firstly, because the conflict resolution protocol of mDNS becomes ineffective. Secondly, because due to the "merging" of theses zones, DNS RRs might point to wrong other RRs. Thirdly, this can become a security issue, because information about the mDNS domain .local which is intended to be link-local might leak into the Internet. Fourthly, when you mistype host names from .local the long mDNS timeout will always occur. Fifthly it creates more traffic than necessary. And finally it is really ugly.

Better workaround

If you want to use avahi in this environment, instead of asking the administrator to move the .local zone (for example, this is the default for a Small Business Server environment on Windows) then simply modify your /etc/avahi/avahi-daemon.conf with the following entry:

Avahi will simply use the domain .alocal to do its magic.


If you are a distributor, please follow the following recommendations when packaging Avahi/nss-mdns:

We recommend to run a special script at bootup and whenever the DNS configuration changes (i.e. from the DHCP hook script), which checks if there is a zone .local on the newly configured DNS server. If there is, please make sure to shut down Avahi and to disable nss-mdns. (Disabling nss-mdns explicitly is not necessary if it wasn't compiled with the mDNS mini stack, i.e. is not compiled with --enable-legacy). Use the bind9 host tool to check for such a zone:

Besides writing a warning about this to syslog, a notification bubble on the screen might also be advisable.


Since I keep finding posts that tell you to restart nscd to flush its caches, I'll tell you how to really do it.

The nscd caches are saved to disk, On my Fedora system, they are located in /var/db/nscd:
[[email protected] ~]# ls /var/db/nscd/
group hosts netgroup passwd services

When you stop nscd, these files will just stay there, so restarting really doesn't flush your nscd caches.
What you need to do is use the --invalidate option, e.g.:
nscd --invalidate=hosts


Нужно скачать и сконвертировать музыку с миксклауда, чтобы слушать её в магнитоле.

При помощи http://clouddownload.co.uk, или аналогичного сервиса - получаем ссылку на аудиофайл (можно хоть в браузерной консоли девелопера получить урл). Качаем его, он в формате M4A.

Конвертим m4a в mp3:

Но у меня простецкая китайская магнитола, которая не умеет перематывать треки. А пока она не сломалась - новую я покупать не собираюсь :-)

Для того чтобы с этим как-то жить, при том что миксы которые мне нужны - имеют длительность около часа, - можно нарезать сконвертированные mp3'шки на части вот таким скриптом, взятым вот тут и немного доработанным:


Столкнулся с тем, что не смог назначить запуск Google chrome в определённом тэге. Нужно правильно написать класс окна в awful.rules.rules. Вроде и написал, а браузер упорно не хочет запускаться в нужном теге. Видимо название класса окна таки отличается от предполагаемого.

Нашел как получить параметры окна, среди которых будет инетересующий нас класс -

    Для использвания 'xprop' необходимо:

  • Откройте терминал.
  • Наберите команду xprop и нажмите Enter. Переместите курсор мыши на нужное вам окно.
  • Используя мышь, щелкните на заинтересовавшей вас точке окна. После этого, свойства X Windows для этого окна будут напечатаны в терминале.


Тащемта, придумал способ из консольки отпугивать киряющих и, впоследствии, орущих под окнами мудаков, вспомнив ультразвуковые отпугиватели собак на вокзалах и рынках:

Помимо пеки и консольки - нужен усилитель и колонки на балконе.
Применять дозированно, включая на полчасика.
С частотой надо ещё поиграться, и протестить, как оно снаружи слышно.

UPD: Не сработало :-(