编译的那点事

由于想利用网络的各种服务器,在网络中做了一台openwrt软路由,里面各种功能插件方便好用。最开始是直接从互联网上下载一些玩家共享的固件,也能比较好地使用,但总感觉有时功能配置不是太合适,或者也有点担心,是不是有后门之类。在学习一段时间后开始了自己编译固件,一年多来经过多次实践,说几点心得体会吧,我是直接用群晖NAS来完成所有工作的。

一、在GitHub上开源的几个主要源码肯定都能编译成功

现在GitHub上有多个固件源,很多个的插件源,从使用过的源码看均能编译成功,过程中可能会有冲突之类,但做一定调整之后能够编译,这说明这些共享本身并没有大的问题。如果编译不能通过主要还是要从自身的系统去找问题。

二、可以采用Docker容器做编译平台,减少了搭建编译平台的复杂性和工作量,中间做文件修改和传递也十分方便。

1、在NAS套件中下载ubuntu20.04官方镜像,用ubuntu20.04镜像建立容器,不做任何额外设置。

2、SSH进入容器后台更换为中科大源并安装编辑工具nano,为ubuntu添加普通用户,并增加sudo权限

sed -i ‘s/archive.ubuntu.com/mirrors.ustc.edu.cn/g’ /etc/apt/sources.list

apt-get update

apt-get upgrade

apt-get install nano

由于编译环境要求不使用root用户编译,所以需要增加一个普通用户

useradd -mk /home/openwrt -s /bin/bash openwrt

passwd openwrt

nano /etc/sudoers

3、将硬盘上一个准备用来保存源码的文件夹映射到上述建立的用户主目录中

三、可以在NAS的管理系统中修改源码配置文件,如feeds.conf.default。

四、按各源码官方说明在容器后台进行编译。

五、第一次无法正常编译,提示各种错误

第一次编译很多人会出现无法正常运行,提示各种错误的问题,这个问题主要来自三方面原因

一是编译平台搭建有问题,就是Linux没有正确的编译环境,解决这个比较简单,就是安装运行源码官方的依赖,确保系统提示都已经安装,没有任何错误,只要提示错误就要全部解决。

二是部分插件之间有冲突

三是编译中各种库文件没有按要求下载到本地,看似下载完成,其实有缺失文件。

1、 不要过多添加其他的源,这样基本可以避免插件冲突问题

2、 make menuconfig中尽量选择默认

3、 正式编译前各步骤要基本没有错误提示,否则重新执行,直到无错误提示。

其中 make -j8 download 下载dl库,非常关键,需要反复执行并确认无误,因为网络关系经常无法完全下载好。

在第一次编译时,不能只看每一步的执行结果,要翻查屏幕中执行显示的反馈信息,如果中间有错误或下载超时等提示,肯定是不能通过的。

总之,没有下载好相关文件是编译不正常的主要原因,在编译过程中要从世界各地服务器下载相关文件,由于网络的原因有些人很难下载到这些必要的文件。

六、部分警告提示可以忽略,一般能够正常编译,似乎警告信息都不会产生严重错误。

很有可能编译成功后,再次进行编译又提示错误,这是因为开始编译后,系统仍然要与各源码网站和库文件通讯,有可能会部分更新一些文件,从而与原有系统产生冲突,如无法调试消除错误,可以删除整个编译文件系统重新下载相关文件后再编译。

群晖Docker中的Nextcloud挂载任意本地存储

最近升级到21.0版的Nextcloud,在挂载外部存储时遇到了麻烦,无论是本地还是远程使用效果都不理想。本地挂载时,直接利用文件服务能挂载的只有SMB,FPT或SFTP均不能连接,但SMB有时出现运行资源消耗高的问题,读正常但编辑文件有时会出现不能写入的问题。用FTP挂载同城远程共享时系统反应很慢,而群晖本身挂载同一个共享却可以秒开,这说明Nextcloud的网络配置有严重问题。这也许是新版本的问题或群晖DSM7.0的问题,因为以前版本挂载非常方便,一般用SFTP直接挂共享文件夹,简单方便无需复杂配置。

如果把Nextcloud作为生产力工具来使用,必然要解决频繁生成文件和编辑文件,也就是要连续快速的读取和写入,挂载远程效果差,用文件服务器挂载本地效果也很差。经过大量探索,成功实现不用文件服务器直接挂载群晖NAS上的任意共享文件夹。

实现这个功能的基本原理是,利用Nextcloud的本地挂载功能,挂载一个内部的本地目录,这个目录是容器内的;再利用容器的卷映射将挂载的容器目录映射到要实际存储的目录上;第三步是更新Nextcloud的数据库,让Nextcloud记录实际存储目录的结构信息并关联到自身的文件管理系统中。

1、SSH进入群晖后台,并取得管理员权限。

2、进入Nextcloud容器,建立挂载文件夹。

docker exec -it nextcloud bash

cd /var/www

mkdir file1

3、登录Nextcloud,以管理员身份挂载file1文件夹

其中file是显示在Nextcloud中的名字,可以自定义,将挂载的文件指定给授权的user1用户。

4、关闭Nextcloud容器,建立存储空间映射

4.1 打开群晖的docker套件,关闭Nextcloud容器

4.2 将要使用的目录映射到被挂载的目录

其中target文件就是我们实际要用于工作中存储文件的文件夹,可以是群晖中任意一个文件夹。

5、启动容器,更新数据库

5.1 启动容器,并SSH进入群晖后台

5.2 扫描Nextcloud挂载的所有文件系统

docker exec –user www-data nextcloud php occ files:scan –all

5.3 以普通用户身份user1登录Nextcloud,检查系统是否正确显示并列出target目录下所有的文件,尝试新建文件并编辑保存相关文件。

为避免系统的权限和文件保护问题,target目录尽量不要是NAS的共享根目录,并授于合适的权限。

由于本地挂载的是NAS的文件夹,直接通过映射来读写数据,与直接使用群晖的filestation是一样的,完全没有延迟的问题,只要网络正常体验是所有连接中最好的。

DSM7.0的升级和Nextcloud的恢复

最近在使用群晖的时候遇到了一点困难,解决过程耗费了不少精力,但也有所得,记录一下,也许对有类似经历的人会有所帮助。

1、事情的起因

前段时间,看到群晖提醒有DSM7.0更新,很多人都不建议升级,特别是dcoker不兼容,考虑docker一旦出问题,它上面运行的大量服务都有麻烦,这个处理过程会累死人的,所以选择忽视,但群晖每天提醒,强迫症犯了,选择更新,有几个套件有点问题,按网络上的方法基本解决了,docker各项服务运行正常并没有报错,但在启动nextcloud用onlyoffice编辑文章时,出现以前编辑文章无法保存的问题,表现为文件的打开、关闭、保存动作一切过程都能进行,且没有报错,但将保存过的文件重新打开,发现新写入的数据并没有真正保存下来,新建文章却正常,反复确认系统各方面功能设置都没有问题,网络上找了半天也没有相关资料,初步认为是DSM造成的。

没有其它解决办法,想到的唯一方法就是先onlyoffice升级,升级过程正常,但升级后仍然有该问题,再考虑是nextcloud的问题,选择nextcloud升级,但进行升级后系统提示版本跨度太大,无法升级,也无法进入nextcloud工作界面。

2、重装nextcloud

2.1 利用最新的镜像重新建立nextcloud容器,始终无法连接MD10数据库,折腾了一天被迫改用sqlite数据库,系统正常安装完成。

2.2 重新集成onlyoffice,系统正常运行,不能保存问题解决。

3、恢复以前数据,问题重现

3.1 考虑到以前较长时间使用nextcloud,有不少老数据,尝试如何恢复,中间经历了无数次挫折,终于找到恢复数据的关键所在。

a 关闭容器,进入nextcloud的映射数据文件夹,删除除config文件夹和单个文件外的所有文件夹

b 用Hyperback从以前备份的数据中还原以上删除的文件夹

c 启动容器,进入系统,相关文件和组件基本都恢复,可能有的组件因版本升级无法兼容,如果用以前相同版本的镜像进行恢复,效果会非常好。

3.2 重新进入系统,编辑以前的文件,不能保存的问题重新出现。

这说明,恢复的文件中有限制onlyoffice的相关数据。

4、解决onlyoffice不能保存问题

这个问题网络上没有任何相关资料,只能自己研究nextcloud的相关配置和文件,经过摸索,找到解决办法。

在映射文件data/user项下的数据文件:

其中的onlyoffice、files_versions、files_trashbin中都有以前工作中保留的数据,files_versions大概就是历史版本信息,把这几个文件夹中的数据全部删除。

其中files_versions中保留了以前编辑文章的所有历史版本。

可能是nextcloud内部存在文件安全机制,DSM系统更新后新生成的数据写入请求不能被以前编辑的文章认可,禁止写入。

5、完整恢复nextcloud

虽然以上简单恢复了数据,但整个nextcloud并没有完全安装好,一是数据库没有恢复,以前的配置没有了,二是一直有报警,使用sqlite数据库不合适,三是用最新的镜像建立容器,很多组件无法运行。

5.1 重新下载以前版本的镜像,并建立容器,连接好MD10 数据库,按上述方法恢复运行。

5.2 关闭容器

a 按上述方法将映射数据中的相关文件夹删除,并按上述方法从备份中还原被删除的文件。

b 打开数据库,将nextcloud数据库导出为sql文件。

c 将nextcloud的数据库删除,再新建同名空数据,导入以上备份的数据库。

5.3 运行容器,基本除邮件外所有帐户信息均保留下来,问题最终解决。

小结:

1、DSM7.0 总体上没有大的问题,除了两个github上的专门应用无法更新,各项应用均较好运行,但似乎系统消耗比6.2版本要大一些。

2、 onlyoffice文件编辑中的不能保存问题由系统不兼容和文件写入权限造成,nextcloud的写保护问题只需要删除nextcloud保存的部分历史信息,解除系统对已经编辑过的文件的封锁。如果遇到文件写入权限问题在filestation中解决,升级DSM7.0后,权限管理与前版不同,这个也是造成这次困难的一个重要因素,解决问题大家多试试可以找出答案,因为不能写入的文件全部位于外挂存储中,以文件服务形式接入群晖就存在权限管理问题。

其实根本没有必要升级和重装onlyoffice及nextcloud,浪费了大量的时间和精力。

3、nextcloud安装中几个问题的解决

3.1 提示没有安装SMB,无法挂载SMB/CIFS外部存储,进入nextcloud系统后台,安装samba客户端,网络上有教程。

3.2 编辑文章时提示没有正确的解密文件私钥,原因是启用了客户端的文件解密,进入设置、应用,禁用系统默认的文件加密模块组件。

根据自己的理解,nextcloud有两套文件数据保护措施,一套是加密和解密机制,系统中启用加密服务器,在终端上利用私钥进行解密,这样编辑过的文件在系统外是不能打开的。另一套措施是系统内保护,在编辑文章时,系统记录了版本信息,也记录了系统和客户端的特有信息,当系统升级破坏了这些信息的认证,就表现为锁定原有文件,起到保护作用,如果将文件拷贝到系统外,能够被任何终端修改。

3.3 尝试过用nextcloud21、22等版本建立容器,各种方法都无法连接MD10数据库,但更早的版本很容易连接数据库,所以最后是利用原镜像恢复了系统,再升级到更新的版本。

3.4 建议升级新版本的onlyoffice,新版本对中文的支持很好,同时集成了相关插件,其中的google翻译是神器。

3.5 新版的nextcloud网络方面可能存在问题,外挂存储非常困难,原来SFTP可以用局域网地址连接,现在无法使用,外网用域名很难连接,偶尔网络可以通,基本连不上,只好改用IP地址,但公网IP几天就变一次很麻烦。另外用SMB连接出现dcoker莫名高负荷运行、提示网络连接不上,虽然外挂是正常的,但体验感觉非常不好。

追加记录

又经过了大概一个月的使用,期间做了大量的优化配置,回过头来再试一试上述遇到的问题,特别是SFTP的挂载问题,经过比较发现,可能以前的一些判断和结论是错误的,这里就不修改以前写的东西了,虽然是错误但这是一次值得记忆的经验。

升级以后,系统共享连接和外部挂载出现严重问题,一方面是群晖DSM进行了安全升级,SMB共享接入要求提高,很多以前的应用都反应连接不上。另一方面是nextcloud与DSM之间网络连接稳定性下降。所以基本上可以判断,nextcloud挂载连接不上和onlyoffice编辑中经常出现更名、保存时好时坏的原因是网络问题。

解决这个问题的思路不是改变两个系统的网络连接,而是要从nextcloud工作的基本原理上去改进。因为两个系统网络连接遵守基本的协议,如果不从底层进行重新配置是无法改变两者的基本连接,显然这个解决方案是不可行。

nextcloud工作基本原理与本地应用不同,它是基于网络和web的技术,从终端接受内容后先将数据写入缓存,然后再写入存储和变更数据库,读取内容也是通过网络协议请求读取数据存储并读取数据库中记录的状态。而本地应用工作时是通过操作系统直接写入存储。也就是说nextcloud的写入和读取都是间接的,中间要通过网络进行数据缓存和协议转发,如果网络出问题则读写操作会出问题,同时如果缓存出问题也会导致读写失败,或者两者配合不好也不行。

经过了系统优化后成功用SFTP进行外部存储挂载,并且工作稳定,期间的主要改变就是给nextcloud连接了redis缓存数据库,不但实现了稳定连接,且文件读取反应迅速,远程编辑时几乎接近了本地读写的速度,体验大幅提高。

这里也想到为什么独立的公有云办公体验是可以的,而个人搭建的云办公一般效果不太好,最主要是硬件、软件和系统配套都要跟上,个人很难在预算和知识有限的条件下建立一个保证性能的系统。