Memes's questions

My setup : small home server with Asrock H67M-ITX, CPU : i3-2120T, PERC H310 RAID with 7 disks all passthrough (I use MDADM for the raid functionality). The system (Ubuntu 20.04) is on a SSD connected to the MB SATA.

Just got a new CPU : E3-1275 v2

I did change the CPU and to have it work, I had to update MB BIOS from v1.30 to v2.20.

Now, when I arrive in Ubuntu, the disks connected to the LSI H310 are not visible at all. the LSI BIOS shows the 7 disks properly.

I have no idea where to start looking. How should I start debug.

Should I update the LSI BIOS too?

Edit 1 : output of lspci shows the LSI card (3rd from the end)

user@server:~$ lspci
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/Ivy Bridge DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5)
00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b5)
00:1c.5 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 6 (rev b5)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation H67 Express Chipset LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port Desktop SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)
01:00.0 RAID bus controller: Broadcom / LSI MegaRAID SAS 2008 [Falcon] (rev 03)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
04:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01)

Edit 2 : From the LSI BIOS, I have the following info

Product Name : PERC H310 Adapter
Package : 20.10.2-0002
FW Version : 2.120.14-1504
BIOS Version : 4.29.00_4.12.05.00_0x05110000
Boot Block Version : 2.02.00.00-0001
Security Capable : No
Controller ID : 0
PCI Bus : 0x01
PCI Device : 0x00
PCI Function : 0x00
PCI Slot ID : 0x11

My home server is running Ubuntu (with the Desktop Environment installed). It hosts several docker containers for some services that are managed by web interface (Transmission, Sickrage, Openhab, Unifi controller,...).

Per preference, I used the following for the networking of the containers :

--net=macvlan
--ip=192.168.0.211 

This way, I do not have the port issue (install the first one on port 8080, then next one uses by default 8080 too but then I need to put to 8081, but then I want to install a new service which has 8081 by default but still, I need to change it to something else...), here, I just take next available IP address for next service and voila.

When it comes to outside access, for security reason, I opened only one port for SSH access to my homeserver from the outside, then through tunneling, I have a VNC access available as well.

My problem : I can access my containers web interface from any computer in the local network except for the homeserver itself. Containers can access each others too. At home, that is not a big issue, but when accessing from outside it is.

As a result, I can not use my VNC access to administer those services.

How can I solve this issue?

I have been looking into RAID5 Vs RAID6 lately and I keep seeing that RAID5 is not secure enough anymore because of the URE ratings and increasing size of the drives. Basically, most of the content I found says that in RAID5, in case you have a disk failure, if the rest of your array is 12TB, then you have almost 100% chance to meet a URE and to lose your data.

The 12TB figure comes from the fact that disks are rated at 10^14 bits read to reach one URE.

Well, there is something I do not get here. A read is done by the head going on the sector, what can make the reading failed is either the head dies or the sector dies. it can also be that the reading does not work for some other reason (I don't know, like a vibration made the head jumps...). so, let me address all 3 situations :

• the reading does not work : that is not unrecoverable, right? it can be tried again.
• the head dies : this would for sure be unrecoverable, but, that also means the full platter (or at least the side) would be unreadable, it would be more alarming, no?
• the sector dies : as well totally unrecoverable, but here I do not understand why the 4TB disk is rated at 10^14 for the URE and the 8TB is as well rated at 10^14 for the URE, that would mean the sectors on the 8TB (most likely newer tech) are half as reliable as the ones on the 4TB, that does not make sense.

As you see, from the 3 failure points I identify, none makes sense. So what exactly is an URE, I mean concretely?

Is there somebody who can explain that to me?

Edit 1

After first wave of answers, it seems the reason is the sector failing. Good thing is that firmware, RAID controller and OS + filesystem have procedure in place to early detect that and reallocate sectors.

Well, I now know what is a URE (actually, the name is quite self-explanatory :) ).

I am still puzzled by the underlying causes and mostly the stable rating they give.

Some attributed the failing sector to external sources (cosmic waves), I am then surprised that the URE rate is then based on the reading count and not on the age, the cosmic waves should indeed impact more an older disk simply because it has been exposed more, I think this is more of a fantasy though I might be wrong.

Now comes the other reason that relates to the wear of the disk and some pointed out that higher densities give weaker magnetic domains, that totally makes sense and I would follow the explanation. But As it is nicely explained here, the newer disks different sizes are obtained mostly by putting more or less of the same platter (and then same density) in the HDD chassis. The sectors are the same and all should have the very same reliability, so bigger disks should then have a higher rating than smaller disks, the sectors being read less, this is not the case, Why? That would though explain why the newer disks with newer tech get no better rating than the old ones, simply because the better tech gain is offseted by the loss due to higher density.

The setup :

• a Ubuntu server with samba shares to 25 users all with Windows (different locales).
• the Ubuntu server then has a daily cron job executed as Admin (not root) running rsync to backup the shared folders to a Synology NAS. the report of this sync is sent by email.
• the Synology NAS is mounted through /etc/fstab on the Ubuntu server using the admin account credentials, the rsync is from local folder to mounted folder.

Here my /etc/fstab line

//192.168.0.30/NetBackup /mnt/SynologyNAS/NetBackup cifs credentials=/home/admin/.nascredentials,iocharset=utf8,gid=1000,uid=1000,file_mode=0777,dir_mode=0777,rw 0 0

The problem : I have quite a few files that are copied everyday, generating a 2MB report email instead of few kB. those files are those who have a owner that is not admin.

For instance :

• Admin creates a file in the samba-shared folder Public, it will then be backed up by the cron job. The owner of the file in the backup folder is Admin. Following day, no copy happens.
• UserNotAdmin creates a file in the samba-shared folder Public, it will then be backed up by the cron job. The owner of the file in the backup folder is Admin. Following day, copy happens again, and so on.

Here is my rsync line

rsync -av --no-perms --no-owner --no-group --delete /share/localFolder/ /mnt/SynologyNAS/NetBackup/remoteFolder

I also already tried

rsync -avO --delete /share/localFolder/ /mnt/SynologyNAS/NetBackup/remoteFolder

and

rsync -vrltD --delete /share/localFolder/ /mnt/SynologyNAS/NetBackup/remoteFolder

How to setup everything so that they are copied once and for all?

I would like to monitor server bandwidth usage.

The server OS is Windows Server 2012

This should give me as result the amount of data over a certain period of time and separate it by protocol and by remote IP.

Protocol to discriminate would be HTTP, FTP and RDP at least.

How can I do this?

disclaimer at first : this question is from a noob on IPv6 topic.

Our web server initially had IPv6 active and Nginx not configure properly so the users with IPv6 got an error and website did not load.

After configuration of Nginx to listen on IPv6, website loads properly but for the users with IPv6, the geolocation fails (we use Maxmind free database), they are then all Geolocated in USA.

I then disabled the IPv6 support, and now it appears to work well, even with client who is with IPv6, my website see an IPv4 and then geolocalize it in the right country.

Question is then :

• What really happens when an IPv6 client queries my website? If he has an IPv4 too, then it defeats the purpose of having IPv6 (which was because we were running out of IPv4)?
• Is the geolocation based on that IPv4 reliable?
• Is there any drawback of not being IPv6 ready?