使用域名访问群晖服务器上的网站的时候，报告500错误（直接使用IP地址访问的时候，不会报错），如下图：
分类： NAS
利用Ubuntu 18.04恢复群晖(Synology)NAS Raid1(DSM 6.x)硬盘数据
如果 Synology NAS 出现故障，则可以使用计算机和 Ubuntu live CD 轻松恢复其硬盘上存储的数据。确保 Synology NAS 硬盘上运行的文件系统是 EXT4 或 Btrfs，然后按照以下步骤恢复数据。此处我们以 Ubuntu 18.04 版本为例。
群晖(Synology) DS718+希捷酷狼(Seagate IronWolf)12TB空闲发出持续噪声
群晖(Synology) DS718+ 使用希捷酷狼(Seagate IronWolf) 双12TB组成RAID1阵列，结果每隔几秒就会发出一阵子咳咳咳的噪声（有人说是炒豆子声音），尤其是夜深人静的时候，简直无法容忍。
网上查询了很久，发现这个问题非常普遍。
|
1 2 3 4 5 |
【硬盘噪音的由来】 噪音虽然不是直接衡量硬盘性能的标准，但是经常听到一阵阵硬盘乱响毕竟不是一件让人舒心的事。纵观硬盘的发展历史，可以发现硬盘的噪音实际上和硬盘的转速是成正比的：转速每提高一个档次，噪音等级都会相应提高。 尽管现在7200转的硬盘已经改进不少，成为了市场的主流，但噪音仍然是要高于5400转的硬盘。通常硬盘内部有两个电机，一个是驱动硬盘旋转的主轴电机，该电机过去是主要的噪音和热量源，但是现在有很多厂家开始使用液态轴承电机，它使用的是黏膜液油轴承，以油膜代替滚珠，可有效的降低因金属磨擦而产生的噪声和发热问题。 同时液油轴承也可有效的吸收震动，使硬盘的抗震能力得到提高，由此硬盘的寿命与可靠性也可以得到提高。 但是另外还有一寻道电机，由于技术和成本上的原因，该电机还没有采用液态轴承电机，我们平时听到硬盘发出的“答，答”声，就是由它发出的。 |
如果是DSM 6.2之前的系统，存在一个磁头反复复位唤醒的BUG，导致磁盘寿命明显缩短。这个原因是由于磁头的复位次数是有上限的，超过上限就容易故障。这个问题的表现就是SMART信息中的Load_Cycle_Count(Load/Unload_Count)异常增高。噪声的一个原因也就是磁头的复位声。
通常，硬盘制造商规定的Load_Cycle_Count(Load/Unload_Count)数目上限是600,000次，要是超过300,000次就会影响到正常的读写，再多的话就差不多要报废了。
参考群晖论坛的讨论 Seagate NAS drives constant clicking noises when idle
但是我的系统是DSM 6.2.2-24922 Update 4，这个问题已经被修复了，目前观察了一下，这个数字已经不再增长了。
这个噪声其实是读写频率低的情况下，磁头默认会回到一个安全区，在这个安全区，即使由于硬盘的意外震动，磁头发生磕碰，也不会磕碰到磁盘区域，提升震动安全。但是带来的问题是磁头进入或者离开安全区的时候，会发出一阵噪声。这个声音非常吵。这也就是为什么官方网站在回应 对于噪声很大的磁盘驱动器我应该怎么办？ 说这个问题没办法解决的原因。
上述故障的典型表现是 当磁盘负载很高的时候，噪声低很多，低负载的时候，每隔几秒就会发出非常高的噪声。
当年，迈拓的硬盘存在一个名为AMM的技术，可以通过一些指令如ATA指令或专用软件对它进行操作，使得寻道时的噪音跟空闲时差不多。但是，AMM降低了硬盘在速度变化瞬间的启动速度，在突发数据传输率上会对硬盘造成一定影响，使得硬盘的性能出现短暂下降。不过，从平均工作性能来说，由于持续传输率并不受启动速度的唯一影响，因此在整体性能上来说问题不大。 迈拓的Acoustic Management(声音管理)设置工具。
可惜，希捷酷狼(Seagate IronWolf)12TB已经不支持这个功能了。
亚马逊有个回答
|
1 2 3 |
Short answer: No Seagate Ironwolf Pro HDD's do not support the obsolete AAM protocols. They have rotational vibration sensors and dampers which make the drive quiet. Long answer: Automatic Acoustic Management (AAM) was a feature popularized by WD in which the spin up rate of the disks in a HDD was slowed down to reduce vibration and noise. This feature was declared obsolete in the 2010 ATA protocols because it made the drive spin up slowly and increased access times. Seagate Ironwolf Pro NAS drives are made to run 24/7/365 @ 7200 rpm. These drives spin up as quickly as any HDD that I ever tried including 15,000 rpm drives. They are not "green drives" which spin down and back up to conserve energy. The drives have rotational vibration sensors and self correct for drive eccentricities. The result is that the Ironwolf and Ironwolf Pro HDD's are very quiet. I have WD Reds, HGST's, and Toshiba drives along with Seagate Ironwolf and Ironwolf Pro 4TB, 6TB, 8TB, 10TB and 12 TB drives. The Seagate Ironwolf and Ironwolf Pro drives are the quietest drives of all the drives I own. |
虽然发出评论的人否认自己是托，但是从我一张12TB的WD红盘跟Ironwolf的对比来看，WD红盘安静的根本听不到噪声，Ironwolf吵得很。
虽然不支持AMM，但是官方提供的控制工具SeaChestUtilities （本站链接 SeaChestUtilities）中的SeaChest_Configure工具（这个工具解压缩到群晖chmod +x后就可以执行）提供了一个名为 --lowCurrentSpinup 的参数，这个参数的说明如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
Low Current SpinUP After System Up, Each time they go StandBy, it stop spinning the plates, and park its heads.. But the problem is, Each time you request access, they will need to start spinning the plates, and moving heads to read/write.. This start process, is painful, for power Consumption, and creates more vibration( it pushs several Amps in spikes for that.. ).. So to minimise it, Seagate Disks have a Feature, to start spinning in a progressive way, instead of abrupt way. |
看上去这个参数可以实现降噪功能，实际上没什么效果！执行命令如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
$ sudo ./SeaChest_Configure_1170_11923_64 -d /dev/sg0 --lowCurrentSpinup low ========================================================================================== SeaChest_Configure - Seagate drive utilities - NVMe Enabled Copyright (c) 2014-2019 Seagate Technology LLC and/or its Affiliates, All Rights Reserved SeaChest_Configure Version: 1.17.0-1_19_23 X86_64 Build Date: Jun 10 2019 Today: Sun May 17 22:26:50 2020 ========================================================================================== /dev/sg0 - ST12000VN0008-2JH101 - ZHZ4XKKY - ATA Set Low Current Spinup Successfully Enabled Ultra Low Current Spinup! A power cycle is required to complete this change. |
low ,ultra两个参数都试过，没明显感觉到不同。
接下来，想在电源管理上看一下是不是能解决问题，比如降低转速等，结果依旧没用。老的Advanced Power Management (APM)被新的Extended Power Controls (EPC)功能取代了，具体解释如下：
|
1 2 3 4 5 6 7 8 |
There are, roughly, three general frameworks for disk drive power management. The earlier specification is part of Advanced Power Management (APM) which provided controls over many devices in a system, including disk drives. APM has since been replaced by a new framework called Extended Power Controls (EPC). Seagate's implementation of EPC began to phase in starting in 2010 and is named by the marketing term "PowerChoice". Seagate PowerChoice technology'specifically developed for enterprise environments'offers more energy efficiency and control over the amount of power hard drives consume. |
尝试用工具中的电源管理模块，结果依旧根本设置不了,如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
$ sudo ./SeaChest_PowerControl_1100__11923_64 -d /dev/sg0 --EPCfeature disable ========================================================================================== SeaChest_PowerControl - Seagate drive utilities - NVMe Enabled Copyright (c) 2014-2019 Seagate Technology LLC and/or its Affiliates, All Rights Reserved SeaChest_PowerControl Version: 1.10.0-1_19_23 X86_64 Build Date: Jun 10 2019 Today: Sat May 16 23:05:56 2020 ========================================================================================== /dev/sg1 - ST12000VN0008-2JH101 - ZHZ54BTB - ATA Failed to send EPC command to /dev/sg1. EPC Feature set might not be supported. Or EPC Feature might already be in the desired state. |
工具的功能挺全的，能查到硬盘的很多信息，如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 |
$ sudo ./SeaChest_Configure_1170_11923_64 -d /dev/sg1 -i ========================================================================================== SeaChest_Configure - Seagate drive utilities - NVMe Enabled Copyright (c) 2014-2019 Seagate Technology LLC and/or its Affiliates, All Rights Reserved SeaChest_Configure Version: 1.17.0-1_19_23 X86_64 Build Date: Jun 10 2019 Today: Sun May 17 22:25:00 2020 ========================================================================================== /dev/sg1 - ST12000VN0008-2JH101 - ZHZ54BTB - ATA Model Number: ST12000VN0008-2JH101 Serial Number: ZHZ54BTB Firmware Revision: SC60 World Wide Name: 5000C500C3DDC97B Drive Capacity (TB/TiB): 12.00/10.91 Native Drive Capacity (TB/TiB): 12.00/10.91 Temperature Data: Current Temperature (C): 38 Highest Temperature (C): 48 Lowest Temperature (C): 31 Power On Time: 5 days 2 hours Power On Hours: 122.00 MaxLBA: 23437770751 Native MaxLBA: 23437770751 Logical Sector Size (B): 512 Physical Sector Size (B): 4096 Sector Alignment: 0 Rotation Rate (RPM): 7200 Form Factor: 3.5" Last DST information: Time since last DST (hours): 22.00 DST Status/Result: 0x0 DST Test run: 0x2 Long Drive Self Test Time: 19 hours 14 minutes Interface speed: Max Speed (Gb/s): 6.0 Negotiated Speed (Gb/s): 6.0 Annualized Workload Rate (TB/yr): 2018.24 Total Bytes Read (TB): 15.98 Total Bytes Written (TB): 12.13 Encryption Support: Not Supported Cache Size (MiB): 256.00 Read Look-Ahead: Enabled Write Cache: Enabled Low Current Spinup: Ultra Low Enabled SMART Status: Unknown or Not Supported ATA Security Information: Supported Firmware Download Support: Full, Segmented, Deferred Specifications Supported: ACS-4 ACS-3 ACS-2 ATA8-ACS ATA/ATAPI-7 ATA/ATAPI-6 ATA/ATAPI-5 SATA 3.2 SATA 3.1 SATA 3.0 SATA 2.6 SATA 2.5 SATA II: Extensions SATA 1.0a ATA8-AST Features Supported: Sanitize SATA NCQ SATA Rebuild Assist SATA Software Settings Preservation [Enabled] SATA Device Initiated Power Management Power Management Security SMART [Enabled] 48bit Address PUIS GPL Streaming SMART Self-Test SMART Error Logging Write-Read-Verify DSN AMAC EPC Sense Data Reporting SCT Write Same SCT Error Recovery Control SCT Feature Control SCT Data Tables Host Logging Set Sector Configuration Storage Element Depopulation Seagate In Drive Diagnostics (IDD) |
有个缩写简单记录一下
|
1 |
AMAC(Accessible Max Address Configuration feature set) |
根据论坛上 教你一招解决NAS噪音及速度问题！的经验，第1盘位是默认的系统盘，这导致硬盘不停的发出咳咳咳的寻道声。为了解决这个问题，（918+）遂决定在1、2盘位安装两块SSD，并将两块酷狼8TB转移到3、4盘位，这样一来，HDD不再是系统盘，在闲置状态下，便可启动休眠功能，大大降低噪音。
可惜718+只有两个盘位，918+的解决方法显然是行不通的。
我自己的群晖的噪声来源主要有如下几个
- MariaDB 10开启了主从复制，主服务器上数据更新，会被自动同步到群晖上的MariaDB 10，导致磁盘被频繁唤醒，而磁盘寻道噪声很大！！
- 群晖开启了SMB服务，局域网内的机器会自动连接导致磁盘被唤醒，虽然没有写入，但是网络请求会导致磁盘唤醒，依旧出现寻道声。
- 系统盘安装在硬盘上，系统会定期唤醒磁盘执行读写操作。目前测试发现，关闭MariaDB 10, SMB 之后，硬盘可顺利休眠。
按理说，上面的问题，可以通过群晖的 SSD 缓存加速功能缓解，结果718+没有M.2插口，918+有两个内置的M.2插口。而外置通过eSata的接口挂载硬盘，是不能作为SSD 缓存加速的。具体信息参考 Synology’s DS718+ SSD caching is crippled/Which Synology NAS models support SSD cache?
目前能想到的办法是
Synology(群晖)常见的配置项以及命令项
Apache2.2 相关配置与常见命令
|
1 2 3 4 5 6 7 8 9 10 11 |
# 目录相同链接位置 /usr/local/etc/apache22/conf/httpd22.conf $ sudo vim /volume1/@appstore/Apache2.2/usr/local/etc/apache22/conf/httpd22.conf # 重启 Apache2.2,有时候重启无效，此时请重启服务器 $ sudo /usr/syno/bin/synopkg restart httpd2.2 # 查看访问日志 $ sudo tail -f /var/log/httpd/apache22-access_log # 查看错误日志 $ sudo tail -f /var/log/httpd/apache22-error_log |
Apache2.4 相关配置与常见命令
|
1 2 3 4 5 6 7 8 9 10 11 |
# 目录相同链接位置 /usr/local/etc/apache24/conf/httpd24.conf $ sudo vim /volume1/@appstore/Apache2.4/usr/local/etc/apache24/conf/httpd24.conf # 重启 Apache2.4,有时候重启无效，此时请重启服务器 $ sudo /usr/syno/bin/synopkg restart httpd2.4 # 查看访问日志 $ sudo tail -f /var/log/httpd/apache24-access_log # 查看错误日志 $ sudo tail -f /var/log/httpd/apache24-error_log |
Nginx相关配置与常见命令
|
1 2 3 4 5 6 7 8 9 10 11 |
# nginx 配置文件 $ sudo vim /etc/nginx/nginx.conf # nginx 配置信息存储位置 $ sudo ls /usr/local/etc/nginx/conf.d # 重启nginx $ sudo synoservicecfg --restart nginx # 查看日志 $ sudo tail -f /var/log/nginx/error.log |
Web Station 相关配置与常见命令
|
1 2 3 |
# 默认网页服务器根目录 /volume1/web |
OpenMediaVault SMB/CIFS报错,无法连接,日志输出错误NT_STATUS_ACCESS_DENIED
OpenMediaVault SMB/CIFS配置完成之后，打开某些目录提示错误"找不到链接"，其他目录正常。
修改配置文件"/etc/samba/smb.conf"中的"log level = 3",然后观察日志"tail -f /var/log/syslog",
观察到如下日志输出：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
Aug 31 23:54:34 openmediavault smbd[2389]: [2019/08/31 23:54:34.006550, 3] ../source3/smbd/service.c:102(set_current_service) Aug 31 23:54:34 openmediavault smbd[2389]: chdir (/media/6357625f-xxxx-xxxx-xxxx-xxxxxxxxxxxx/MyCloud) failed, reason: 权限不够 Aug 31 23:54:34 openmediavault smbd[2389]: [2019/08/31 23:54:34.006667, 3] ../source3/smbd/smb2_server.c:3097(smbd_smb2_request_error_ex) Aug 31 23:54:34 openmediavault smbd[2389]: smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_ACCESS_DENIED] || at ../source3/smbd/smb2_server.c:2449 Aug 31 23:54:34 openmediavault smbd[2389]: [2019/08/31 23:54:34.012733, 3] ../source3/smbd/service.c:1098(close_cnum) Aug 31 23:54:34 openmediavault smbd[2389]: longskys-mbp (ipv4:10.10.10.116:54656) closed connection to service IPC$ Aug 31 23:54:34 openmediavault smbd[2389]: [2019/08/31 23:54:34.014028, 3] ../source3/smbd/service.c:102(set_current_service) Aug 31 23:54:34 openmediavault smbd[2389]: chdir (/media/6357625f-xxxx-xxxx-xxxx-xxxxxxxxxxxx/MyCloud) failed, reason: 权限不够 Aug 31 23:54:34 openmediavault smbd[2389]: [2019/08/31 23:54:34.014151, 3] ../source3/smbd/smb2_server.c:3097(smbd_smb2_request_error_ex) Aug 31 23:54:34 openmediavault smbd[2389]: smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_ACCESS_DENIED] || at ../source3/smbd/smb2_server.c:2449 Aug 31 23:54:34 openmediavault smbd[2389]: [2019/08/31 23:54:34.017951, 2] ../source3/smbd/service.c:1098(close_cnum) Aug 31 23:54:34 openmediavault smbd[2389]: longskys-mbp (ipv4:10.10.10.116:54656) closed connection to service MainBackup |
不管如何修改，都搞不定，观察目录权限以及所有者信息，如下：
|
1 2 3 4 5 6 7 8 9 |
root@openmediavault:~# ls -la /media/ 总用量 20 drwxr-xr-x 6 root root 4096 8月 25 00:03 . drwxr-xr-x 24 root root 4096 8月 30 23:23 .. drwxrwx--- 1 root 1000 164 6月 2 14:37 6357625f-xxxx-xxxx-xxxx-xxxxxxxxxxxx drwxrwsr-x+ 4 root users 4096 8月 15 2017 9b5fcef5-xxxx-xxxx-xxxx-xxxxxxxxxxxx drwxr-xr-x 2 root root 4096 5月 26 2015 cdrom lrwxrwxrwx 1 root root 4 5月 26 2015 usb -> usb0 drwxr-xr-x 2 root root 4096 5月 26 2015 usb0 |
观察到正常的目录的权限是 root:users 而不正常的目录权限是 root:1000,于是执行权限修改，如下：
|
1 2 3 4 5 6 7 8 9 10 |
root@openmediavault:~# sudo chown root:users /media/6357625f-xxxx-xxxx-xxxx-xxxxxxxxxxxx/ root@openmediavault:~# ls -la /media/ 总用量 20 drwxr-xr-x 6 root root 4096 8月 25 00:03 . drwxr-xr-x 24 root root 4096 8月 30 23:23 .. drwxrwx--- 1 root users 164 6月 2 14:37 6357625f-xxxx-xxxx-xxxx-xxxxxxxxxxxx drwxrwsr-x+ 4 root users 4096 8月 15 2017 9b5fcef5-xxxx-xxxx-xxxx-xxxxxxxxxxxx drwxr-xr-x 2 root root 4096 5月 26 2015 cdrom lrwxrwxrwx 1 root root 4 5月 26 2015 usb -> usb0 drwxr-xr-x 2 root root 4096 5月 26 2015 usb0 |
之后就可以正常访问了。
参考链接
群晖DS718+增加内存
群晖 DS718+,系统默认自带2GB的内存,平时使用足够了，但是随着软件的增加，内存有些捉襟见肘，需要增加一些内存。
群晖 DS718+ 的内存型号信息如下图：
继续阅读群晖DS718+增加内存
家里ADSL上网无固定外网IP的群晖NAS安全实现与公网MySQL服务器主从同步
家里 ADSL 上网，没有办法分配固定外网 IP ，现在想使用群晖自带的MariaDB 安全实现与公网 MySQL 服务器主从同步。
最大的问题实际上是如果暴漏 MySQL 服务器的端口，但是不限制来源 IP 地址的话，会造成非常大的安全隐患。
但是， ADSL 恰恰不能提供固定的 IP 地址，我们需要解决这个问题。如果通过在公网数据库服务器上搭建 OpenVPN 服务器的方式，我们恰恰可以把内外网的设备影射到同一个子网中，而且 OpenVPN 提供的加密服务支持，刚刚好满足我们的安全需求。
注意：一旦配置主从同步，磁盘的休眠会被MySQL的同步写入打断，导致磁盘不能正常休眠，毕竟正常情况下数据库是持续写入的，不存在很长时间的停顿。这样会导致磁盘周期性的咔咔寻道声，尤其是晚上。
噪声问题，参考 群晖(Synology) DS718+希捷酷狼(Seagate IronWolf)12TB空闲发出持续噪声
1. 参考 Ubuntu架设OpenVPN实现内网穿透 搭建整个的 OpenVPN 服务器。映射完成后，设备上会新增一个名为 tun0 的网卡设备。同时所有连接到 VPN 服务器的设备都被被影射到 10.8.0.X 的网段。 公网服务器的地址默认是 10.8.0.1，本文中， 群晖NAS的地址被设定为 10.8.0.7。
2. 配置防火墙规则，许可来自指定网卡指定地址的设备的访问。注意，此处一定要指定网卡为 OpenVPN 创建的虚拟网卡，否则造成安全隐患。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
$ export slave_ip=10.8.0.7 #删除可能已经存在的配置，避免出现多条重复记录 $ sudo iptables -D INPUT -i tun0 -p tcp -s $slave_ip --dport 3306 -j ACCEPT #增加配置，只允许特定地址访问数据库端口 $ sudo iptables -I INPUT -i tun0 -p tcp -s $slave_ip --dport 3306 -j ACCEPT $ sudo iptables -L -n -v #保存配置 $ sudo apt-get install iptables-persistent $ sudo netfilter-persistent save #配置被保存到/etc/iptables/rules.v4 /etc/iptables/rules.v6这两个文件下面， #最好确认一下实际保存的内容，尤其是安装了denyhosts等其他安全软件的情况下， #可能会记录了多余的规则，需要手工删除 |
3. 参照 ubuntu 16.04配置基于SSL的MySQL主从同步 配置服务器
4. 接下来是群晖NAS的配置
首先是群晖服务器上没有 MySQL，需要安装 MariaDB ，如下图：
继续阅读家里ADSL上网无固定外网IP的群晖NAS安全实现与公网MySQL服务器主从同步
群晖DSM 6.2增加zgrep命令
群晖 DSM 6.2 系统上执行 zgrep 命令的时候提示找不到命令，其他平台系统(ARM )，需要手工编译安装ZUtils，来提供。但是如果是 X86 系统的话（比如 DS718+ )，可以直接使用交叉编译环境里的工具，直接拷贝到系统即可。
首先参考 搭建群晖交叉编译环境(DS718+/ubuntu 16.04.6/DSM 6.2.1-23824 Update 6) 搭建群晖 DSM 6.2 的编译环境。
DS718+ 执行如下：
|
1 2 3 4 5 6 7 |
$ cd ~/toolkit//build_env/ds.x64-6.2/ $ scp -r ./bin/zgrep username@10.10.10.111:~/ $ ssh 10.10.10.111 -l username $ sudo mv ~/zgrep /usr/local/bin/ |
需要编译的(ARM 芯片版本)，执行如下命令编译：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
$ cd ~/toolkit/pkgscripts-ng # 下载 ZUtils 1.8 $ sudo wget http://deb.debian.org/debian/pool/main/z/zutils/zutils_1.8.orig.tar.xz -O ../build_env/ds.x64-6.2/root/zutils_1.8.orig.tar.xz # 也可以本站下载 sudo wget https://www.mobibrw.com/wp-content/uploads/2019/04/zutils_1.8.orig_.tar.xz -O ../build_env/ds.x64-6.2/root/zutils_1.8.orig.tar.xz $ sudo chroot ../build_env/ds.x64-6.2/ $ cd root $ export PREFIX="/root/build_libs" $ export HOST="x86_64-linux-gnu" $ mkdir -p $PREFIX # 编译 ZUtils 1.8 $ tar xvf zutils_1.8.orig.tar.xz $ cd zutils-1.8/ $ PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig/ \ LD_LIBRARY_PATH=$PREFIX/lib/ \ ./configure \ --prefix=$PREFIX $ make clean $ make $ make install |
对于编译好的程序，复杂的可以自己制作安装包，简单的可以直接通过SSH推送到设备的/usr/local/bin目录下即可。
比如本次编译结果：
|
1 2 3 4 5 6 |
# 暂时只需要zgrep,因此只安装 zgrep $ scp -r $PREFIX/bin/zgrep username@10.10.10.111:~/ $ ssh 10.10.10.111 -l username $ sudo mv ~/zgrep /usr/local/bin/ |
参考链接
ESXi 6.7 使用NUT Client连接群晖UPS服务器
近来增加了一台工控机，上面跑了软路由等业务，万一突然断电 ESXi 坏了启不了，估计就得废好大劲折腾了。以前有给群晖配过一台 APC BK650 的 UPS，目前 UPS 的 COM 数据输出直接给到了群晖，毕竟无论如何也得优先保障群晖的可靠性。在群晖的设置里面看到过 UPS 服务器的选项，所以想着 ESXi 能不能连接群晖的 UPS 服务器，实现断电自动关机以保证数据安全。
解决Btrfs文件系统ext2_saved文件磁盘占用异常
最近在 OpenMediaVault 4.1.22-1(Arrakis) 进行磁盘文件占用分析的时候，发现磁盘空间异常占用问题，如下：
|
1 2 3 4 5 6 7 8 |
root@openmediavault:/media/6357625f-c966-49ba-9c90-9e8f8ff50433# du -ah --max-depth=1 0 ./lost+found 1.5T ./MyCloud 8.0K ./aquota.user 8.0K ./aquota.group 1.3T ./ext2_saved 4.0K ./WDMyCloudSync.sh 2.7T . |
这个 1.3T ./ext2_saved 文件是不存在的，并且没办法通过常规命令删除。
这个文件产生的原因是，执行过 从 EXT3/4 转换转化分区到 Btrfs :
|
1 |
$ btrfs-convert /media/6357625f-c966-49ba-9c90-9e8f8ff50433 |
完成转换需要删除备份的 ext2_saved 子卷,否则空间会不能释放。 请注意，如果没了它(备份子卷)，你将没办法还原回 EXT3/4 文件系统。
|
1 2 3 4 |
$ sudo apt-get install btrfs-tools # 执行，然后无视报错 $ btrfs subvolume delete /media/6357625f-c966-49ba-9c90-9e8f8ff50433/ext2_saved |
可能会报错：
|
1 |
ERROR: cannot access subvolume /media/6357625f-c966-49ba-9c90-9e8f8ff50433/ext2_saved: No such file or directory |
无视这个报错即可。
完成后再次查询文件占用空间：
|
1 2 3 4 5 6 7 |
root@openmediavault:/media/6357625f-c966-49ba-9c90-9e8f8ff50433# du -ah --max-depth=1 0 ./lost+found 1.5T ./MyCloud 8.0K ./aquota.user 8.0K ./aquota.group 4.0K ./WDMyCloudSync.sh 1.5T . |
可以看到空间已经被释放了。