MacOS append search-domain

I recently started using a Mac laptop (with MacOS Sierra) for work and one thing soon saw was that the search-domains were not appended when trying to use utilities such as ping or ssh (tough the configuration in the network preferences lists domain.com in the list of search-domains).

So, saying I have host1.domain.com using the following:
ping host1 would not resolve host1 (no search-domain appended)
ping host1.domain.com would resolve host1 (is specified in FQDN)
host host1 would resolve host1 (but that's because host uses its own resolver that is using the search-domain)

Looking for manual page of mDNSResponder - the system wide DNS resolver - this says:

 
OPTIONAL ARGUMENTS
     mDNSResponder accepts the following optional arguments:

     -AlwaysAppendSearchDomains
                                Append search domains for multi-labeled Par-
                                tially Qualified Domain Name as well as sin-
                                gle-labeled Partially Qualified Domain Name.
                                This argument is not recommended because of
                                the extra DNS traffic it generates and its
                                adverse effect on battery life.
..
     To cause mDNSResponder to run with these optional arguments when it
     launches on OS X 10.11 (El Capitan) and later, set the
     AlwaysAppendSearchDomains or NoMulticastAdvertisements boolean keys to
     true in /Library/Preferences/com.apple.mDNSResponder.plist and reboot.

If you're a newb like me on MacOS, the next question is "how do I set the boolean key to true for AlwaysAppendSearchDomains? ". I found the answer here:

sudo defaults write /Library/Preferences/com.apple.mDNSResponder.plist AlwaysAppendSearchDomains -bool YES

Then, as the manual says, reboot. Bouncing the mDNSResponder would probably also work.

DDNS and QNAP NAS

I was looking recently to allow remote access into my home QNAP NAS from remote locations.
My IP address at home is dynamic so I needed a DDNS provider and some port forwarding on the home router.
My setup at home is simple. My internet connection is over a DSL line. I have a DSL router from the ISP serving as an Wifi access point for my devices at home. It also has 4 ethernet ports and to one of them I have my QNAP NAS connected.

After looking throgh a few reviews on the internet, I choosed DuckDNS. What i liked about it the most is their variety support in operating systems and the way the dynamic update is done - through an HTTPS GET request (can use also HTTP GET, but HTTPS is recommended). Secure and implemented in any decent OS. Full specs here.
You log in with one account from various social networks (reddit, G+, facebook, twitter) and you get a token assigned with your account. Further, at this time you can use 5 subdomains.

The QNAP itself can act as a DDNS client for a few providers. The whole list is below. Duckdns is not one of them.

To make use of duckdns on the QNAP NAS I've added in the /etc/config/crontab file an entry to update my IP every 2 hours:

 0 */2 * * * /share/Valentin/duckdns/duck.sh >/dev/null 2>&1

mdadm tips on Linux software RAID

mdadm is a tool for managing, creating and reporting on Linux software RAID arrays.

I will describe some tips which I found useful at the moment.

Improve RAID1 re-sync time with write-intent bitmap
The RAID driver writes out periodically bitmap information recording which areas of the RAID component have been modified since the RAID array was last in sync.

If, for example one of two members of a RAID1 array fails and is removed from the array, md (the multiple disk software RAID drive) will record bits to the bitmap relating to the changes the active member is undertaking since the two members were last in sync. If the same failed/removed drive is re-added to the RAID1 array, md will notice and will recover only the portions indicated by the bitmap. In this way a lengthy re-sync is avoided (a full re-sync is normally needed if the drives are not in sync when the array starts up).

Linux ephemeral port range for TCP/UDP connections over IPv4

The range of ephemeral ports a client program can use (unless otherwise specified by the program) on modern Linux OS distributions by default is from 32768 till 61000 (for systems with more than 128 MB RAM) and from 1024 till 4999 (or even less) for systems with less than 128MB of RAM. This range is defined in the kernel parameter /proc/sys/net/ipv4/ip_local_port_range and it affects both TCP as well as UDP client connections.
Should there will be a need to change this range to extend the range(for example setting the lowest port number to 15000) we cal use:

echo "15000 61000" > /proc/sys/net/ipv4/ip_local_port_range

To make this change persistent after reboots, we can use sysctl.

Duplex mismatches 100BASE-TX

I encountered a situation a few days ago where the two devices were not correctly negotiating the duplex setting. One box was a Cisco 2950 switch, the other was a Linux machine.
Although the ehternet interfaces of the 2 boxes were both capable of 100BASE-TX (full duplex) it was clear that the Linux machine's eth1 was running in half duplex mode
A tool on Linux which can display/change an ethernet card setting is ethtool.
Now for a bit of theory:

The link speed is determined by electrical signaling, so that either end of a link can determine what
the other end is trying to use. If both ends of the link are configured to autonegotiate, they will use
the highest speed that is common to them.
A link’s duplex mode, however, is negotiated through an exchange of information. This means that
for one end to successfully autonegotiate the duplex mode, the other end must also be set to autonegotiate.
Otherwise, one end will never see any duplex information from the other end and won’t
determine the correct common mode.