This is a question about DNS root nameservers.

In order to resolve DNS queries, to obtain nameservers for the first stage of the process, the root nameservers must be consulted.

There are 13 and the IP addresses of these servers can be viewed at http://www.internic.net/zones/named.root

My understanding is that when a new device connects to the internet, it (probably) uses the nameservers provided by the ISP. (I don't actually know how the IP addresses of these devices are obtained. Presumably some software in the router/hardware provided by the ISP?)

The ISP then knows the IP addresses of the root nameservers.

The question is what happens if those IP addresses change? Is this possible?

Taking a look at http://www.internic.net/zones/named.root the IP addresses seem to be somewhat arbitrary.

Presumably they are static and decided by ICANN. Can the IP addresses of the root nameservers change? If so, what happens?

I attempted to move a mdadm raid 1 array to a different system this evening.

I took the 2 SSDs out of one system and put them in another, then booted that system.

I opened gparted to check what the disks appeared as. They showed up as being blank (unallocated) drives.

I then shut down this system and moved the drives back to the original system, and booted.

sudo mdadm --assemble --scan --verbose

reported that no raid superblocks were found on sdg or sgh, which is where I would expect the data to be.

I thought this should be a fairly trivial process, but I'm now not sure what to do.

Any help would be appreciated, it's kind of important I don't loose the data on these drives...

This is the (approximate) output of sudo mdadm --misc --examine /dev/sd[efgh]

sde/sdf report the expected output, starts with Magic a92b4efc... then prints a bunch of info about this raid 1 array.

sdg/h simply produce mbr magic aa55 and then partition[0]: 1953525167 sectors at 1 (type ee)

I really have no idea what this means but I have a feeling from an issue I was having with another system that there is some conflict between the mdadm raid information and a gpt parition table? Is my guess right, if so what should I do about this? Perhaps assemble the raid in a degraded state and see if the data can be read?

fdisk -l

sde/f make up md1, md0 is missing - should be sdg/h.

Disk /dev/sde: 931.5 GiB, 1000207286272 bytes, 1953529856 sectors
Disk model: WDC WDS100T2G0A-
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/md1: 931.4 GiB, 1000072019968 bytes, 1953265664 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sdf: 931.5 GiB, 1000207286272 bytes, 1953529856 sectors
Disk model: WDC WDS100T2G0A-
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sdg: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 860 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 76628399-779F-47D5-BF40-91930ECC85C8


Disk /dev/sdh: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 860 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 0A316DF5-1431-44D5-8328-16960E7206B5

I'm very confused by some issues I'm having with a raid setup with mdadm.

I have a Debian 10 system, which I installed a KVM VM on, to use as a NAS server. I had problems with the raid superblocks dissappearing when rebooting, and never got to the bottom of the issue, so I started doing some more tests today, without the VM.

I tried to create a raid 1 array with mdadm on the host system. (Not on a VM)

I then rebooted the system, and again the raid superblocks appear to have dissappeared or somehow been wiped blank?

The system is using a LSI pci-e SAS card, flashed in IT mode, with a few 1TB Toshiba SATA drives.

Anyway, here's a list of commands run from this morning...

  184  sudo mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda /dev/sdb
  185  sudo mkdir -p /mnt/md0
  188  cat /proc/mdstat

At this point the raid finishes initializing

  189  sudo update-initramfs -u
  190  sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf 
  191  cat /etc/mdadm/mdadm.conf

Seems ok

  193  echo '/dev/md0 /mnt/md0 ext4 defaults,nofail,discard 0 0' | sudo tee -a /etc/fstab 
  194  sudo mount /dev/md0 /mnt/md0

Can read data on drives ok, still there from last raid configuration

  195  cat /proc/mdstat

... reboot, no md0 device started or mounted

  197  sudo mdadm --detail --scan

blank!

  198  cat /etc/mdadm/mdadm.conf 
  199  cat /proc/mdstat

blank!

  200  sudo mdadm --assemble --scan

does nothing

I'm extremely confused by what is going on here - and I have no clue how to start diagnosing the problem further.

I'm trying to run the following commmand on my Raspbian system

sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 2222 -j DNAT --to-destination 192.168.2.241:22

iptables says:

iptables v1.8.2 (nf_tables): unknown option "--to-destination"
Try `iptables -h' or 'iptables --help' for more information.

Same issue if I change --to-destination to --to.

I'm fairly new to iptables etc, and I haven't been able to track down the issue with internet search.

I understand that at some point iptables is changing into "nf_tables"? Has this already happened in Raspbian? Is that the source of my problem?

I am working with some source files from a desktop computer. The source files compile and run on a remote server.

As there is a significant delay between me and the server, I have decided to use rsync to copy the files down to my computer, edit them, and then sync them back up, again using rsync.

However there is a problem... rsync doesn't update the files when I sync them back up to the server after editing them at my end. The incremental file list is sent, but the file contents are unmodified.

Here is a full output of my bash session which will explain in detail what happens.

• I have some files on my local machine. I edit one of those files, using an editor such as vim. The file structure is fairly generic. I have a project root directory called 2016-07-01, which contains many subfolders and source files. The folder is just named with the date as a method of version control.

(bash)

$ rsync -av ./2016-07-01 user@server:./path-to-project/2016-07-01
user@server's password: [enter password] 
sending incremental file list
2016-07-01/subfolder/
2016-07-01/subfolder/main.cpp

sent 2,238 bytes  received 272 bytes  557.78 bytes/sec
total size is 632,957  speedup is 252.17

• It looks like main.cpp has been updated, but when I ssh into the server and open it with vim I see that it is unchanged. Why is this happening?

• I then run the same command again and the following output is produced...

(bash)

$ rsync -av ./2016-07-01 user@server:./path-to-project/2016-07-01
user@server's password: [enter password] 
sending incremental file list

sent 1,342 bytes  received 36 bytes  110.24 bytes/sec
total size is 632,957  speedup is 459.33

• This time no incremental file list is sent - I am not sure why - it is as if rsync thinks it has updated the files already and therefore does nothing when it has not...

• If I check main.cpp at my end it has definitely been changed.

• main.cpp on the server side is unchanged.

I have also tried using the -c flag for checksums rather than date-time-stamps, again the same result is seen.