分类目录: 数码硬件

HomeServer安装在线Office:Docker安装最新精简版OnlyOffice

最近从这个帖子看到一些有趣的企业软件,其中有一个在线办公软件OnlyOffice,感觉挺有意思的。之前一直为各种自建网盘无法打开Office文档而烦恼,看到FileRun可以集成OnlyOffice DocumentServer,于是就决定开始搭建这个,解决自建网盘直接预览和编辑文档的问题。目前在用的3款网盘软件,还只发现FileRun支持,其他几款如FileBrowser、Cloudreve都还不支持。FileBrowser的Git库上面,有人提交了PR,但是迟迟没有被approve和合入。看起来挺简单的集成功能,不清楚开源owner为什么不合入。

第三方提供的界面总归还是有些不够专业,于是想着自己搭建一个完整的在线Office。经过一番摸索,需要DocumentServer+CommunityServer配合。前者只是一个文档查阅和编辑器,后者提供UI管理文档。当然也可以仅仅只搭建DocumentServer,用第三方的UI来集成,FileRun就算,还有更多的,笔者并没有作更多探索。这里的CommunityServer是一个复杂的办公Workspace,包括一系列的复杂的项目管理、团队管理等套件,这些套件全部包含在内,显得整个docker非常臃肿,资源有限的HomeNAS难以支撑,于是针对这个CommunityServer又做了一些裁剪,主要是把一些感觉用不到的进程停掉了,自己做了docker镜像,也上传到了dockerhub上面。下面开始介绍这两个组件的安装配置过程。

DocumentServer搭建很简单,毕竟依赖的组件少,官方docker镜像也非常简洁,很快就按照官方给的安装命令在HomeNAS上面跑起来了,并且简单配置之后就能在FileRun上面直接查阅和编辑Office文档了。但是发现一个问题,就是DocumentServer为了确保安全,默认启用了jwt_token。token确实有用,可以避免DocumentServer被盗用,被任意其他网络服务拿去使用耗费有限的资源,因此token是UI和Server之间通信的安全保障。有一个问题是,DocumentServer的jwt_token在每次DS重启之后就会重新生成,这样FileRun上面又要重新设置,经过分析,可以用Docker的环境变量指定一个固定的token。然后,如果没有指定外部DB,则DocumentServer会自己启动一个内建的mysql,这个mysql与已有的外部的mysql重复了,没必要,因此我选择使用外部的mysql来公用,节省资源。最终具体的运行命令如下:

docker run –net onlyoffice –name onlyoffice-document-server -d -p 127.0.0.1:12583:80 \
-e DB_TYPE=mysql \
-e DB_HOST=IP_OF_YOUR_DB_HOST \
-e DB_PORT=3306 \
-e DB_NAME=onlyoffice \
-e DB_USER=USERNAME_OF_YOUR_DB \
-e “DB_PWD=PASSWORD_OF_YOUR_DB” \
-e JWT_ENABLED=true \
-e “JWT_SECRET=YOUR_FIX_JWT_TOKEN” \
-v /your/app/path/DocumentServer/logs:/var/log/onlyoffice  \
-v /your/app/path/DocumentServer/data:/var/www/onlyoffice/Data \
onlyoffice/documentserver:latest

上面只开启DS的http端口,同样使用系统统一的一个Nginx反向代理HTTPS对外提供服务。docker启动后,占用的资源非常少。具体的进程列表如下:

document-server

CommunityServer的安装过程就比较坎坷了,主要是想禁用多个暂时不需要的服务,笔者这里主要禁用elasticsearch、内部自带的mysql、还有一堆的Soauth、API、迁移数据、自动清理数据、备份数据、Chat服务等,感觉对于只想体验一下在线Office而言,这些都用不上,禁止之后也没有发现有什么地方运行异常,只用修改run-community-server.sh这个文件,然后重新打镜像即可。如果不做这个裁剪,我的四核6100T的CPU,16G内存,都非常吃力,并且还频繁崩溃重启。最终精简版的进程列表如下:

community-server

修改后的镜像我也上传到了,自己的dockerhub账号下:

https://hub.docker.com/repository/docker/shentar/onlyoffice-community-server

docker pull shentar/onlyoffice-community-server:latest

CommunityServer要使用token访问DocumentServer时,有点坑,找遍了各种设置界面都没看到,网上也没有任何资料介绍,最终在官方给的docker安装脚本中找到了,也是通过一个环境变量来指定。这样只要将该变量指定为DS的token即可。需要注意的是,CommunityServer也有自己的jwt_token,因此这两个都要指定,才能正常运转。具体的环境变量名为:

DOCUMENT_SERVER_JWT_ENABLED
DOCUMENT_SERVER_JWT_SECRET

最终,安装CommunityServer的命令为:

docker run –net onlyoffice -i -t -d –privileged –restart=always \
–name onlyoffice-community-server -p 127.0.0.1:12555:80 \
-e “MYSQL_SERVER_ROOT_PASSWORD=YOUR_MYSQL_PASSWORD” \
-e MYSQL_SERVER_DB_NAME=onlyoffice \
-e MYSQL_SERVER_HOST=YOUR_MYSQL_HOST \
-e MYSQL_SERVER_USER=YOUR_MYSQL_USERNAME \
-e “MYSQL_SERVER_PASS=YOUR_MYSQL_PASSWORD” \
-e JWT_ENABLED=true \
-e “JWT_SECRET=YOUR_FIX_JWT_TOKEN” \
-e “DOCUMENT_SERVER_JWT_ENABLED=true” \
-e “DOCUMENT_SERVER_JWT_SECRET=YOUR_FIX_JWT_TOKEN” \
-v /your/app/path/CommunityServer/data:/var/www/onlyoffice/Data \
-v /your/app/path/CommunityServer/logs:/var/log/onlyoffice \
-v /your/app/path/DocumentServer/data:/var/www/onlyoffice/DocumentServerData \
-v /sys/fs/cgroup:/sys/fs/cgroup:ro \
shentar/onlyoffice-community-server:latest

同样只开启HTTP,利用外部的Nginx来实现HTTPS反向代理,省去了一大堆SSL证书相关的事情。最终运行起来的效果如下图。测试了各项基本功能,都是正常的,精简掉的那些进程暂时用不着。

在线Office

| 1 分2 分3 分4 分5 分 (5.00- 3票) Loading ... Loading ... | 同时归档在:WEB网络, 移动互联, 软件应用 | 标签: , , , , |

开源好用的电子书管理服务Talebook(Calibre网络版)安装使用指南

今天是世界读书日,介绍一款已经用过一段时间的电子书在线管理、阅读服务。Talebook是一个开源的Calibre WEB外壳,源项目地址是:Github项目,我为了方便自己开发,在自己的代码托管服务上放了一份源码,方便存放自己的开发过程代码。也经常将自己用稳定了的特性或者修改的Bug提交MR推送到原作者的项目中。我主要会根据自己的需要开发一些特性和修复我认为比较关键的bug。代码地址为:自用Talebook地址Docker镜像地址。增加了多个特性,如:限制单个IP地址下载书籍的数量限制特性,用来防止爬虫大并发爬取书籍,导致站点不可用。另外还增加了一些统计信息和界面修改等,具体的差异点可以对比两个代码工程的获取。我也会持续跟进源项目的新特性,实时合并,也继续推送自己的修改到源项目。

更新记录列表:

  1. 支持限制单个IP地址下载数量;
  2. 支持随机推荐和最新书籍推荐手动刷新;
  3. 支持个人阅读、访问、下载和推送记录,也支持一键清除,优化历史记录页面;
  4. 新增“我的收藏”功能;
  5. 上传成功的图书即从upload目录删除,避免书籍被保存两份,浪费空间;
  6. 导入页面,在删除导入记录的同时,也删除上传到uploads目录的图书。

跟原项目一样,我也基于仓库代码生成了镜像,推送到了dockerhub,有了Docker镜像,安装使用起来就非常方便:

docker run -d --name calibre \
-p 127.0.0.1:12579:80 \
-v /media/c2/docker/calibre/data:/data \
-E TZ="Asia/Shanghai" \
shentar/talebook:latest

我这里将容器内的80端口映射到本机的内部随机端口,然后再在宿主机上面使用Nginx反向代理对外提供HTTPS服务。反向代理时,需要注意一些配置:

server {
    listen 6870 ssl http2;
    server_name book.codefine.site;
    index index.html index.htm index.php default.html default.htm default.php;
    root /any/local/path/;
 
    ssl_certificate ***********;
    ssl_certificate_key ***********;
 
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    
    client_max_body_size 500M; 
 
    location / {
        proxy_pass http://127.0.0.1:12579/;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Nginx-Proxy true;
        proxy_set_header X-Scheme $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $http_connection;
    }
 
    access_log on;
}

注意这些Header必须正确设置,否则可能无法正常打开主页。 剩下的就是从网页打开宿主机的6870端口即可访问。我的宿主机是有域名的因此,我的站点的地址就是:https://book.codefine.site:6870,首次打开时,会做一些必要的配置,如私人模式还是多用户模式。admin账号和密码设置等。完成后就可以愉快的使用talebook存取电子书籍了。 对于网络下载的各种电子书文件,元信息可能都不准确,因此需要从豆瓣等刮削元信息。开源社区有一个现成的刮削服务,douban-api-rs:源码地址为:https://github.com/cxfksword/douban-api-rs,这个也提供Docker的安装方式,不过作者并没有在Dockerhub上面放镜像。而是在Github自己的镜像服务上面托管镜像。如果是命令行安装,只需要执行如下命令即可:

docker run -d \
--name=douban-api-rs \
--restart=always \
-p 172.17.0.1:8080:80
ghcr.io/cxfksword/douban-api-rs:latest

如果是群晖等NAS服务,则需要自行配置新的镜像源才能拉去到该镜像。具体笔者没有使用过,需要自行探索。 然后到Talebook的高级配置项目中配置即可:

image

我这里之所以选择使用172.17.0.1作为监听地址,是因为这个地址是我的docker服务的网络的虚拟网关,宿主机也能访问这个IP地址。这样,在Talebook内部就能用这个地址与豆瓣刮削服务通信。上传电子书之后,只要设置正确的书籍名字即可进行全量元数据的抓取了。豆瓣网站不再提供书籍的标签(Tag)了,因此Talebook服务端做了从作者、标题和书籍摘要中匹配Tag的实现,准确率还行。 感谢Talebook作者贡献这么好的开源项目,并且多年来还在积极维护。这个项目也让我初步接触到Vue.js、Node.js、Python3 Tornado等生态,开发WEB项目,使用这些组件,效率极高。什么时候有精力可以把jAlbum的前端好好用这些写一下。

| 1 分2 分3 分4 分5 分 (5.00- 3票) Loading ... Loading ... | 同时归档在:WEB网络, 建站技术, 移动互联 | 标签: , , , , , |

Home NAS 音乐服务解决方案

之前写过使用《使用Emby + Picard管理音乐》的方案,Emby有一个问题,在划词搜索方面,必须前缀或者整词完整匹配,对于港台音乐名和元数据多是繁体字,用简体搜索时,无法匹配,一直希望能够模糊匹配,发现airsonic-advance这方面没问题,完美解决搜索问题。

阅读全文 »

| 1 分2 分3 分4 分5 分 (5.00- 1票) Loading ... Loading ... | 同时归档在:移动互联, 软件应用 | 标签: , , , , |

Home-Server磁盘降温记

由于内存不足,Home-Server上面运行的虚拟Windows主机经常宕机,就想着给Home-Server更换一根16GB内存。小机箱内部空间狭小,部件接合紧密,拆机时把机箱风扇给扯断了。费了老大的劲儿,内存条是装上去了,开机也能识别,但是少了个风扇。

5d230042c5a9454.jpg_e1080 (图片源于网络)

当天晚上,重新还原各个部件到机箱内部,后来太晚了,机箱就没有封盖,准备第二天早上再弄,心想少一个机箱风扇应该也没多大事。结果,第二天早上,准备关机装机箱盖,运行了一晚的服务器,发现磁盘烫手,都有开水的温度了。不对劲,赶紧安装hddtemp检查磁盘温度,发现竟然达到70多度。这样太危险了,影响磁盘寿命,赶紧某宝下单一个宣称4K转速20元包邮的机箱风扇(最终实际能跑到3100转,但是已经够用了。)。历经3天,快递终于到了。装到机箱后,默认是自动调速模式,声音大的有点像置身机房,这样放在家里,肯定难以接受。研究了半天,将/sys/class/hwmon/hwmon2/pwm1_enable置为1,然后设置/sys/class/hwmon/hwmon2/pwm1的值尽可能小,以降低转速,发现最小转速就是1500多,再小风扇就停止转动。1500转,声音小多了,噪音可以接受了,温度也还正常。

在这个过程中,还研究了一下使用Grafana监控磁盘温度的方法,Prometheus官方提供的node-exporter没有提供hddtemp相关的功能,找了半天,也没有人提供能用的基于hddtemp的监控exporter,于是写了一个循环运行的Shell脚本+PushGateWay实现了一个磁盘温度的exporter。

经过一番折腾,磁盘温度降到能接受的40度左右的范围了,对比效果见下面的监控图。在没有风扇的时候,发现不仅磁盘温度非常高,磁盘温度还会将CPU温度拉高。把磁盘挪开,则CPU温度在正常范围。SAS盘温度高真不虚。这次拆装机颠覆了我对磁盘温度的认识。之前一直认为磁盘运转过程中不需要风扇,机箱风扇是给整个机箱内部的除CPU外的部件散热,但重点不是磁盘,没想到在小机箱里面磁盘是发热量的大头。

image
| 1 分2 分3 分4 分5 分 (5.00- 2票) Loading ... Loading ... | 同时归档在:软件应用 | 标签: , , , , , |

介绍一个照片管理工具:PhotoPrism

最近发现一个跟jAlbum功能高度一致的相册工具,PhotoPrism,安装步骤不复杂,这里不作介绍。准备拿来跟jAlbum对比一下。看了官网的Demo,发现跟我之前做jAlbum时预想的功能完全一致:照片分类、人脸识别、照片日历还有照片打Tag,最重要的是,我一直不会做的界面,这个工具的要好用很多。赶紧docker安装试用了一下,挂载Home Server下的图片目录,在照片比较少时,完成加载很快,但是照片一但多了,就很慢。下面从各个维度对比一下,以打分的方式比较 :-)

比较项 jAlbum PhotoPrism
人脸识别 借助于第三方系统,识别精确特别是人脸对比方面精准。
5分
使用Pigo,All In One的方式,识别准确率较低。
3分
图片场景识别 不支持 支持识别图片场景,自动打标签,准确率不高
3分
备份照片到远端 支持对象存储(华为OBS和Amazon S3)
4分
使用Webdav协议备份。某些云盘支持WebDAV,因此可以网云盘备份照片。
4分
视频管理 支持
4分
支持,支持从照片中抽帧并做图片分析。
4分
界面 简陋
2分
界面精美,动态页面非常好用,支持编辑元数据,指定人像名字,编辑人像。
5分
客户端 浏览器 浏览器,有准备推出手机端的应用。
自动识别新增文件 支持
4分
需要手动点击分析图片文件按钮。
2分
支持上传照片 不支持 支持
支持自动备份手机照片 不支持 不支持
访问安全 支持简单的发放Token方式,支持Https 支持单账号登录。
照片分享 不支持 支持
功能定制 支持通过服务端参数定制很少的页面行为。
2分
支持在界面配置各种功能。
5分
性能 流畅
4分
页面响应明显卡顿。
2分
技术栈 Java、少量JS、处理EXIF信息、FFmpeg、SQLite。
更多依赖第三方服务。
Golang、Vue.js、SQLite、处理EXIF信息、FFmpeg、WebDAV。
All In One,几乎不依赖第三方
开发规模 个人玩具 ^_^,16年基本完成,后面没在大规模开发。 形成规模的开源社区,多人协作开发,正在商业化的路上。18年开始在Github开源,具体开始时间不详。
| 1 分2 分3 分4 分5 分 (5.00- 1票) Loading ... Loading ... | 同时归档在:WEB网络 | 标签: , , , , |

分享一个追最新外语电影的RSS

国内的Torrent分享网站越来越少了,无意中发现https://www.demonoid.is/可以下载到最新的高清/超清电影。但是有点比较讨厌,就是弹窗有点过份,不是我白嫖了种子还不愿支持广告,真是弹窗太过三俗刺眼,难以忍受。于是试着分析了网页内容,自己抓取电影种子文件链接,并添加Google搜索IMDB的链接,制作了RSS订阅链接。本来还想找一下有没有类似的Torrent分享站点,发现demonoid是与海盗湾齐名的,之前排名前几的站点已经都无法打开了,只剩这一个,切用且珍惜吧  :-) 源站地址:链接,经过抓取清洗和加工后生成的RSS链接为:https://photo.codefine.site:12524/rssfactory/demonoid-movies,只抓取了1080P及其以上质量的电影。 https://www.demonoid.is/

订阅后的呈现效果:

 image

同时也制作了HTML版的独立网页:

https://movie.codefine.site:12524/

movie list.

电影详情页,包含两个torrent下载地址,IMDB和豆瓣搜索链接。

movie detail.

| 1 分2 分3 分4 分5 分 (5.00- 1票) Loading ... Loading ... | 同时归档在:WEB网络, 移动互联, 软件应用 | 标签: , , |

使用Emby + Picard管理音乐

最近把NAS上面累积下来的音乐都整理了一下,用emby建了一个音乐集。emby自带musicbrainz的插件,能从这个强大的音乐库中搜索MP3的元数据信息。然后从多个维度对音乐进行分类呈现。但是有个问题,很多MP3经过各个二道贩子编辑后,关键元数据信息都跟音乐本身没有任何关联了,因此自动搜索出来的元数据匹配存在一些问题,甚至有的MP3文件经过转码后,只剩下音乐本身,tag元数据全部丢失。只能人工填写,一两千个文件,逐一搜索排查可想而知难度有多大。找到了picard这个工具,可以自行匹配,然后没有匹配的再人工搜索,这样极大提高了准确率。比emby自动但是做了的错误的匹配要好的多。经过picard处理后的音乐文件再导入到emby中,就能准确识别歌手,专辑等信息,进而补充下载专辑唱片封面图等。

难得的是,picard在Win、Linux和Mac平台都能使用。对于Ubuntu 20,使用官方给出的命令很快就能安装成功:

sudo add-apt-repository ppa:musicbrainz-developers/stable
sudo apt-get update
sudo apt install picard

软件界面截图:
picard

导入/emby的效果:
emby

| 1 分2 分3 分4 分5 分 (5.00- 1票) Loading ... Loading ... | 同时归档在:移动互联, 软件应用, 软件技术 | 标签: , , , |

基于Dlib、Flask和Sqlite的人脸检测和识别服务

这个十一原定的计划取消了,没有做好备份计划,也就不打算出远门了,关在家里,把一直都想做的一个本地化的人脸识别服务整了一下。提供人脸分析的开源服务似乎很多年都没有大的变化了,一直都是Dlib和OpenCV,对比了一下,Dlib更容易使用。一直没有正经写过Python代码,翻出N年前买的Python编程书,边翻书Google、边写代码。基本的代码流程比较简单,Dlib官方也有例子,很容易运行起来,但是要服务化,要做人脸比对,并且是增量的人脸比对和识别,并不容易。说做就做,最终整个服务形成如下架构。

架构图:
image

代码和部署使用方法在如下git工程:https://git.codefine.site:3000/Shentar/facerec

首先需要将探测的过的“人脸”存储起来,然后能输入一张人脸返回与该人脸近似的所有人脸,这样客户端好做人脸归集。很快做好了一个初步的框架:使用Flask提供REST接口接收照片,在响应中返回人脸的特征标识,使用SHA256对人脸68点位的描述向量进行HASH,返回给客户端。同时将HASH值和实际的token存储到Sqlite。第一天大概就完工了这个功能。

运行起来,发现单纯的Flask不能并发,第二个请求会报错,一次只能接受和处理一个请求。于是又按照网上的经验,使用Gunicorn和Gevent来做多线程的方案,因为习惯了单进程多线程的方式,多线程访问Sqlite需要加锁,按照通用的做法,使用一个队列来管理Sqlite实例。继续验证,发现多线程并不能加速Detect的效率,貌似Dlib不支持多线程加速。调整为多进程,四个CPU都能运用起来。

1d2dd2b5bcde40b6a563996821d84843

终于找到了一个能将这个3.2GHZ的四核CPU跑满的业务了 ^_^

Architecture: x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   39 bits physical, 48 bits virtual
CPU(s):                          4
On-line CPU(s) list:             0-3
Thread(s) per core:              2
Core(s) per socket:              2
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           94
Model name:                      Intel(R) Core(TM) i3-6100T CPU @ 3.20GHz

人脸检测的效果还不错,错误率的话,自己家用是够了。特别是在侧脸检测上面,比较准确。在人脸比对方面,错误率就要高一些了,反复验证,发现0.36的比对阀值比较合适。侧脸虽然检测率高,但是在比对上面,只用通用的拟合范数,结果会表现为差异很大。因此这里应该是需要有定制化的比对实现,只做部分比对。这块需要深入到人脸检测技术内部,去分析128D的特征值向量的每一个值,短时间内没办法去研究透了。

由于采用了多进程,因此没法共用一个Sqlite运行时实例,强行并发读写访问会导致数据库错乱,不得不又做了一个服务来封装Sqlite,多个检测进程输出的人脸特征值都发给该服务来顺序存储,同时也返回给客户端。两个服务之间同样采用REST接口交互。

准备大规模上量,将jAlbum目前使用的线上人脸识别服务切换到这个本地服务上面,又发现检测时长非常高,一张4M的图片,大概需要几秒的时间,并且还有些非常小的区块被检测到了。对于检测慢的问题,考虑降低输入的照片的像素,图片减小后,长宽的像素点都相应减少了,但是人脸的特征点并不会损失太多。因此先对图片进行降低像素和尺寸,识别完成后,对识别到的人脸在照片上的位置也要相应做缩放,对比了一下,原始大小检测和缩放后检测,再对结果做相反的缩放,最终结果误差不大,但是这样能极大提速。对于非人脸和质量不高的人脸被检测到的问题,做了一些粗浅的限制,人脸长宽必须大于100的阀值才认为是正常的人脸。Dlib应该有正统的输出人脸的质量的参数,查了很久,没有找到合适的方法,就只能先这样吧。在比对方面,还有一些重要的概念,没有弄明白,如人脸对齐、年龄、性别检测等,不清楚我的代码里面是否已经有调用已经做了这块。

具体的处理代码:

data = np.frombuffer(data, np.uint8) 
if data is None: 
    raise Exception('image is required.') 

zoom_ratio = 1 
if data.size > 6 * 1024 * 1024: 
    img = cv2.imdecode(data, cv2.IMREAD_REDUCED_COLOR_4) 
    zoom_ratio = 4 
elif data.size > 4 * 1024 * 124: 
    img = cv2.imdecode(data, cv2.IMREAD_REDUCED_COLOR_2) 
    zoom_ratio = 2 
else: 
    img = cv2.imdecode(data, cv2.IMREAD_COLOR) 

faces = [] 
dets = detector(img, 1)

总的来说,开源项目,适合做一下Demo,如果要尽善尽美,那么就要深入到源码,有针对性的去优化检测和比对模型。作为个人的实验和家用还是很不错的。至少在快速编程和服务化这方面。

| 1 分2 分3 分4 分5 分 (5.00- 2票) Loading ... Loading ... | 同时归档在:WEB网络, 架构设计, 移动互联, 软件应用 | 标签: , , , , , |

Ubuntu 20.04桌面体验

对于Ubuntu桌面的印象还停留在很多年前,当年的感觉是,比较容易崩溃,需要修改配置文件的地方太多,一不小心系统就崩溃了。家里近10年前的笔记本,几次操作系统自动升级后,已经变得一打开Win10系统就开始呼呼叫。像是一个年迈的老人,稍微快步走路就气喘一样。想试一下最新的Ubuntu,装系统很容易,直接下载镜像,写入U盘,制作成启动盘,引导安装。最可贵的是,居然自动识别老的Win10系统,做成了双系统,需要的时候还能进入Win10。用了几天,感觉Gnome桌面的整体风格跟Mac越来越像了,几乎不需要手动修改配置。自动发现U盘、界面连接Wifi、安装软件等体验都不错。其实日常家里使用笔记本也就是看看文档、浏览网页、看看开源代码,还有一些常用的社交应用的网页版,无缝访问家里的NAS系统。Ubuntu生态里面,离完全满足这些应用还有距离,但是在性能体验上面,已经远远超出Windows了,特别是硬件资源不足的情况。生态欠缺也是硬伤,如:微信微博等没有linux版本客户端,没有一些通用的轻量级代码编辑器:Nodepad++和VSCode等。好在现在越来越多的东西都可以在Web页面上解决。

阅读全文 »

| 1 分2 分3 分4 分5 分 (5.00- 2票) Loading ... Loading ... | 同时归档在:软件应用, 软件技术 | 标签: , |

Home NAS上可以运行哪些有趣的服务?

一、jAlbum

“自研”的相册管理程序,介绍和部署方法参考《jAlbum——Java WEB版相片管理系统 》。

二、代码托管服务器

国内访问github总是非常慢,所以把代码托管到HomeNas上面。使用gogs

三、文件备份工具

接收各个终端上面备份的视频、照片文件。使用sync搭建,目前墙内无法访问该工具的官方网站。现在有开源免费的替代方案:Syncthing

四、Everything

everything本来是一个Windows系统的本地文件搜索工具,以其高效而著称,在IT从业人员中使用非常广泛。其开放WEB访问方式,支持远程搜索和下载文件,远程办公时访问HomeServer上面的文件非常方便。遗憾的是,至今其都不支持HTTPS方式访问,并且用于认证的用户密码机制非常原始。可能是作者为了保持该软件的健壮和简单,不愿意加入更多的小众化功能。

五、Emby Server

媒体管理平台,支持各大平台部署Server端,支持众多的终端部署客户端应用。免费版本的客户端限制较多。当然网上也流传着各种破解方法。 在HomeServer上面部署Emby主要用于管理电视剧、小孩子看的动画片、无损音乐和超清电影,没有广告干扰的娱乐时光还是很惬意的:) 其中电影自动搜索字幕比较有用。但是对于非电影文件,按照电影去搜索元数据时,会出现匹配错乱的问题,因此非电影文件的库都是禁用自动更新元数据。

六、RSSHub

这年头,RSS源越来越少了,只能自行部署一个RSSHub,目前主要用这个工具的客户端快速提取正在访问的网页中的RSS Feed。服务端能起的作用似乎还有限,也可能是还没有完全整明白这个该怎么用。

七、博客静态文件托管服务

在香港的一个主机提供商那里购买的丐版空间,只有1G的文件存储容量,博客中日积月累的各种图片和PDF已经将空间耗尽,还有Reader和博客的数据库文件其实也是分享的这1G的空间,而各大公由云的对象存储又收费,想着家里的NAS每天开机也是闲着,就再承担点负载。将网站的所有静态文件都从“自研”的托管服务上面出,模拟主流对象存储的API实现了类似镜像存储的机制。将所有图片本地保存。这样可以定期清理博客托管服务服务上面的图片和附件等。 当然还有最基本的NAS文件共享服务、远程访问服务、偶尔当梯子给其它终端代理、作为下载机等普通功能都不在话下。 不知不觉家里一个小小的Server上都部署了十来个服务。其实,HomeServer就缺了一个完整的80和443等端口,如果国内电信服务提供商开放这些端口,那么都不用购买任何网站托管服务了,直接在HomeServer上面运行所有网站相关的任务。这样不仅省钱,还便于管控。不过话也说回来,电信封了很多端口,对HomeServer的维护来说,也解决了网络安全的问题。

八、WebDAV服务

2020-8-9更新:增加WebDAV服务,使用go编写的caddy和webdav插件搭建。主要服务于跨平台的笔记服务:Joplin,除了界面不如印象笔记,功能上已经够用。有了WebDav,能做的事情就比较多了,如: 1、管理个人密码的keepass; 2、备份油猴配置和脚本; 3、当作网盘直接在桌面系统中挂载使用。

九、Cockpit服务

2020-8-27更新:增加cockpit服务,并替换自签名证书。

十、部署VMPlayer

用于运行两个虚拟机: 一个是Win10系统:1、用于搭建科学上网的客户端,给其他设备提供代理服务,科学上网这块在Win生态下的工具远比Linux系列的丰富和易用。这样不用每个终端都安装各种工具,只需要配置代理指向该Win系统即可。2、安装迅雷,现在下载没有迅雷,啥资源都是Kbytes/s的速度,难以忍受,毋庸置疑,资源都已经被迅雷垄断了,迅雷充当了CDN的作用。 另外虚拟化了一个黑群晖,主要用于体验群晖系统,其实群晖能做的事情,在这个HomeNAS上面都有了,只是想体验一下群晖的易用性。惊奇的发现,在虚拟机里面虚拟化出来的磁盘(600GB),磁盘落在EXT4文件系统上面,然后再经过群晖的文件共享出来使用,这个共享跟NAS上面原来的共享在性能上面没有任何差异,甚至更稳定,写速率稳定在112MB/s,是不是经过Vmware和EXT4文件系统两级缓存之后,速度跟均衡。装一个空壳的宿主机,把所有硬盘都交给虚拟机的黑群晖管理,也不失为一种新的NAS玩法。

十一、部署Docker

安装docker,并配置远程访问,dockerd监听本地端口,配置TLS证书。运行portainer,实现远程管理docker实例。运行wiz笔记程序,体验不同于joplin风格的为知笔记,该笔记在抓取网页方面有所欠缺,但是界面还有性能上面非常不错。

十二、人脸识别服务

参考《基于Dlib、Flask和Sqlite的人脸检测和识别服务》。

十三、FileRunFileBrowser

可以将HomeNAS瞬间变网盘,主要用于解决文件分享、带校验码分享的场景。另外也可以用这个来直接通过页面操作远端文件的增、删、改、查。参考链接安装 FileRun,HomeNAS 秒变网盘

十四、Grafana

使用docker部署Grafana、普罗米修斯和Node-exporter监控服务器的磁盘、CPU、内存和网络等消耗。

十五、Chevereto图库服务

部署图库服务,可以作为图床、相册等使用。简单高效管理图片。

十六、为知笔记

一个界面非常友好,功能强大的多设备、多用户,跨网络同步的笔记服务。

十七、RSS阅读器

参考《架设Tiny Tiny RSS(TTRSS)阅读器,找回Google Reader!

十八、自研爬虫

运行各种新闻和电影BT下载爬虫程序。

十九、音乐服务

参考《Home NAS 音乐服务解决方案

二十、在线电子书库

安装基于Calibre的电子书在线阅读和管理服务:源码Docker仓库,本站书库:代码人生

二十一、MinIO

自托管的对象存储服务,兼容Amazon S3。安装指导:链接

二十二、Transfer.sh

一个非常好用的临时文件共享服务,客户端和服务端均使用最简洁的HTTP请求上传下载文件。可在此试用本站的Transfer.sh服务:链接

二十三、Matomo

非常好用的站点统计工具,Google Analytics的自建替代品,自建站点统计服务。对于Wordpress博客,甚至可以直接使用插件集成所有服务端的功能。

二十四、OnlyOffice

在线Office,可以完全替代本地的Office。官网的文档介绍太弱,安装过程中有一些坑,并且官方提供的镜像太臃肿,我做了少量精简。安装过程总结如下:《HomeServer安装在线Office:Docker安装最新精简版OnlyOffice》

服务列表

| 1 分2 分3 分4 分5 分 (5.00- 2票) Loading ... Loading ... | 同时归档在:WEB网络, 建站技术, 移动互联 | 标签: , , , , , , , , , , , , , , |
返回顶部