One of the facts about modern computing which many people take for granted, is a LAN which can be browsed. Without such an ability, a Local Area Network only consists of IP addresses, and unless we have made special preparations otherwise, those IP addresses can also be reassigned by our router. Yet, this view of the LAN has prevailed under Linux for some time, where specific services need to be configured with text-files, and where users have made entries in the file ‘/etc/hosts’, such that specific host-names are associated with specific IP addresses, that are defined manually.
There exists a Linux solution to this problem, which can be installed with the package ‘avahi-daemon’. In short, this daemon provides in a Linux-friendly way, what the old ‘NetBIOS’ used to provide under Windows. It associated packages, ‘avahi-utils’, ‘avahi-ui-utils’, and ‘avahi-discover’ , provide a GUI that allows the local computer to browse graphically. Additionally, the package ‘libnss-mdns’ allows for the host-names on the LAN to receive the suffix ‘.local’, so that regular Linux programs can refer to those host-names and connect to their IP addresses transparently, without requiring manual configuration.
dirk@Phoenix:~$ ping Mithral.local PING Mithral.local (192.168.2.10): 56 data bytes 64 bytes from 192.168.2.10: icmp_seq=0 ttl=128 time=0.183 ms 64 bytes from 192.168.2.10: icmp_seq=1 ttl=128 time=0.266 ms 64 bytes from 192.168.2.10: icmp_seq=2 ttl=128 time=0.275 ms 64 bytes from 192.168.2.10: icmp_seq=3 ttl=128 time=0.374 ms 64 bytes from 192.168.2.10: icmp_seq=4 ttl=128 time=0.281 ms 64 bytes from 192.168.2.10: icmp_seq=5 ttl=128 time=0.302 ms 64 bytes from 192.168.2.10: icmp_seq=6 ttl=128 time=0.465 ms 64 bytes from 192.168.2.10: icmp_seq=7 ttl=128 time=0.280 ms ^C--- Mithral.local ping statistics --- 8 packets transmitted, 8 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.183/0.303/0.465/0.078 ms dirk@Phoenix:~$
Some people have noted problems getting this latter feature to work, but on my LAN, it just seems to work out-of-the-box.
It should be noted though, that if we install this to a computer which is not used to it, there can be some stability issues, and ‘avahi-daemon’ may not be compatible with arrangements some users have already made, to resolve their host-names. There was a specific problem I ran in to myself, after installing this on a laptop, according to which a list of available printers had become unstable, as viewed from one application.
In general, because SMB shares were invented by Microsoft, Linux tries to avoid depending on ‘Samba’, which is the Linux recreation of the file-browsing capability offered by SMB. If we want that under Linux, the way to obtain it is still to install the full Samba suite, which will show NetBIOS-compatible host-names, as best they can be manufactured, and that do not end in the suffix ‘.local’. Hence, ‘avahi-daemon’ will also not display any printers that were shared via SMB…
But, avahi displays shared printers out-of-the-box, which were provided by the CUPS servers on other computers.
Further, in the directory ‘/etc/avahi/services’, there should be one file for each additional service the local avahi-daemon is supposed to report to the network. These files can be custom-written, but there is an example in the documentation for avahi, in the directory ‘/usr/share/doc/avahi-daemon/examples’, named ‘ssh.service’, which shows admins how to make local SSH servers visible to the LAN, for graphical browsing. They will appear in the avahi-GUI-browser for SSH, if that file is just copied into ‘/etc/avahi/services’. I have been able just to click on one of the entries in this GUI, and obtain an instant SSH client-session to the advertized server, without having to type in any text.
Aside from that, this daemon can go some distance into transforming our LAN into an Intranet, since an Intranet is not only a contrast to the Extranet, but is also a LAN big enough to have its own DNS server. And, there may be more packages that extend its features, such as ‘avahi-dnsconfd’ . By the time we have installed that extension however, we have made deep changes to how our Intranet works, that may not be compatible anymore at all, with how many home-users have set up their LAN. And so I, too, have avoided installing ‘avahi-dnsconfd’ .
I should point out, that the indicated service “Remote Disk Management” requires that a client obtain SSH access, but nevertheless bothers some avahi admins, just because it is being advertized on the LAN. It goes with a pure GNOME package named ‘gnome-disk-utility’ , that would allow a remote GNOME-based client to manage local disks via SSH. If it offends some users, the file ‘udisks.service’ can simply be deleted from ‘/etc/avahi/services’ . Doing so will stop avahi from reporting this feature on the LAN, but will not change the fact, that If a hypothetical attacker has obtained SSH access, he or she has already compromised the local computer fully, with or without avahi being part of the situation.
dirk@Phoenix:~$ cd /etc/avahi/services dirk@Phoenix:/etc/avahi/services$ ls phpmyadmin.service ssh.service udisks.service dirk@Phoenix:/etc/avahi/services$
Also, I suspect that in order for this feature to work, ‘sudo’ needs to be set up rather liberally on the host, which it is under Ubuntu, since the feature works by SSH, yet an SSH log-in is only a user-log-in by default.