Tag: self-host

  • 寻找适合的自建聊天工具

    到现在为止，并没有找到最合适的解决方案（目前最靠谱的是 Nextcloud Talk 和 Voce Chat）。先把过程中考虑到的一些因素，记录下来，作为借鉴。 我的目的，是如何更便捷地，和墙内小范围的朋友、家人，保持联系，在对话中不受信息审查。现有的聊天软件，能够不翻墙使用的，几乎没有了，即使有，也不是长久之计。所以最靠谱的方式，大概只有通过一台海外的 vps，自建服务，供小范围的人使用。如果传播范围不大，除非 gfw 变成白名单，否则应该都可以长期使用。 下面是选择各种自建聊天工具时，会考虑到的因素。这些因素之间，有些是互相冲突的。对不同需求的人，在这些因素之间考虑的权重，也不一样。对于我上述的需求来说， 首先，我希望这是一个可以挂机的聊天工具，可以在收到信息时，从手机接收到通知；而不仅仅是个网页聊天室，只能在专门打开网站时，才能聊天： 要联系的人，并不擅长电脑技术和操作，因此 这些人，可能并不属于同一个群体。所以，需要为不同的人群，架设不同的服务地址，互相分开。 安全性方面： 架设系统的便利程度： 对聊天功能的需求： ……………还有什么要补充的吗？ 已经考察过的工具 其实最理想的，应该是一个 php 的聊天室……能通过 chrome 在手机桌面接收消息通知就可以。轻量化、可以塞到任何目录下、没有中文我自己汉化也可以。但是，真的没找到靠谱的…………求推荐！！！ ps，如果联系人有一定电脑常识，也懂英文的话，用 mycryptochat 做临时沟通，蛮好用的。 目前最合适的，是 Nextcloud Talk，用 docker + sqlite + nginx，是可以做到快速部署的；占用内存不到 300MB，勉强可以接受（所以开销更高的方案，基本不考虑了）；而 nextcloud 作为一个庞大的办公平台，其 web 界面对于非技术人士，未免有些眼花缭乱。 xmpp 和 matrix 服务器，可以做到开销更小，但也在 100MB 以上，还涉及独占端口的调整，部署起来繁琐很多。似乎也可以把跨实例通信的功能关掉，做成封闭社区，配置和开销会简单一些。但还没仔细研究。 各种协同平台类，如 Mattermost、Rocket.Chat，系统开销过大，就算了。 这两年有个国人开发的 VoceChat 工具，评价很不错。可以 docker + nginx 部署，内存…

  • 把日常阅读的网页，用 RSS 推荐给好友

    虽然大家写 blog 的频率都没那么勤了，但是，RSS 还是有其它可以玩的方式的！ 很多人都有用各种 read it later、或者书签类工具，把有意思的网页保存下来。在这些工具里，可以通过某些手法，把一些想要分享的网页，生成 rss。其他好友订阅这个 rss 地址，就可以自动刷新，看到你推荐的文章啦！ 下面介绍一些，常见的书签网站，生成 rss 的方式。但首先—— 我的 RSS 分享地址是： 有兴趣和我分享的，欢迎留言或私信交换！！ Instapaper 免费版 感觉 Instapaper 生成 RSS 的功能是最好用的，可以把特定的文件夹设为公开，直接得到它的 rss，形如： Pocket 免费版 好像 Pocket 的免费用户，内容都只能是公开的（无语…），只要知道了用户名，就可以通过 RSS 查看全部的内容（所以生成的 rss 需要转录才安全）。而且不能自定义分类，只有默认的： 最后一条 …/read 会返回所有 Archived 了的文章，可以勉强用它作为分类的手段。 Readwise 这个只有收费版，我就不去试了。有它家的用户，可以帮忙把生成 rss 的方法分享一下？ Wallabag 我在用 Wallabag，可以自建，也有收费的服务可用。生成的 rss 是全文输出，效果很好。在 Config – Feed 里，生成一个 token，然后点开任何一个 tag，点击列表上方的…

  • 图床

    趁着服务器搬家，打算把死掉很多年的摄影网站，重新恢复起来。把如今流行的自建图库程序看了一圈：piwigo、lychee……仍然没有哪个很靠谱。 其实我在浏览这些程序之前，并没有太多具体的需求，只是期待，快 10 年没看这类东西了，会不会有什么让我惊艳的产品。——并没有。而且，在体验每个程序时，都迅速地发现一些，让我觉得很不爽的点。于是，所谓自己的需求，就是在这个不断吐槽的过程中形成的。 除了最基本的 之外， 如果，我要的是一个图床，那么我需要—— 照片的 url 和我本地储存的目录结构和文件名是一致的，类似于 https://…./blog/20230909_1.jpghttps://…./blog/20230910_cat.jpg 而不是 https://…./21/27/4c1b46114f8.jpg 这样的东西。前者的文件名，在编辑文章时便于管理。而且，以后迁移图床时，可以统一替换图片 url 的前缀，实现无缝迁移。 如果，我要的是一个摄影作品的展示网站，那么我需要—— ！！！不要在网页的任何地方，显示多余的 exif 信息！！！ 感觉这十年来，所有的图库程序，都把心思花在，如何去识别各种图片格式的内嵌 exif，然后把它们各种花式归档、搜索、展示……展示在网页边角、在动态的弹出菜单、甚至悬浮在照片上面。——我不需要啊！谁要在摄影作品上，标明照片的 exif 是哪天拍的，甚至是哪天上传的啊！！我连标题都不想展示啊！ 甚至，各路图库程序比拼的重点，已经变成了如何调用外部地图软件，然后把照片根据 GPS 信息显示在地图上。（翻白眼 如果，我要的是一个管理图片的工具，能够便捷地挑出一些照片来展示。那么我需要—— 在一个相册里，可以便捷地拖动更改，照片之间的顺序。而不是靠手动修改文件名这种粗糙的排序方式。 没有。能够满足这些需求的哪怕其中之一的，都没有。有一些静态网站生成程序，能够把已经彻底整理好的照片，生成看着还行的展示网站。但与其一个个试过来，再试着根据自己需求去魔改各种瑕疵；我觉得我还是在 wordpress 上慢慢拼吧…… 于是又变成了 打算做点啥 → 考察相关的工具 → 做不成，开始吐槽各种工具…… 以及，在这些干扰下，想趁此机会整理从前照片的希望，大概又落空了……不仅仅是在一些照片里的人，我不想去回顾。也包括，在翻看以前照片时，仍然能够识别出的，自己当年用摄影的视角，去凝视世界的方式，以及对这种方式本身的思考和改变。——我现在是否适合，把这种方式，重新调用起来？

  • Mastodon: 将媒体文件存放在本地（docker 版）

    本攻略适用于—— 这个搭配虽然不多见，但其实用起来满爽的。很多人用的 s3 服务都是在薅羊毛，而 mastodon 那个变态的，把别人家的媒体文件缓存到自家的架构，流量的吞吐其实很大的（开了 relay 就更夸张），薅羊毛时很容易就超出了。反而是 vps 本身的流量上限很高。对于个人建站而言，媒体文件总量通常 <50GB，某些 vps 自带 200GB 硬盘，足够用了。 缺点是，除了数据库定期备份外，也要考虑媒体文件的异地备份问题。但其实只需要备份存储本地附件的 media_attachments，而 cache 是不需要备份的，所以工作量也不大。 两年前我把媒体文件转移到本地时，参照了 antisocial science 的设置。但因为我用 docker，官方默认的设置，docker 内外权限不一致，无法将媒体文件写到本地。于是匆匆又在本地建了个 minio s3 来中转……这样其实很浪费资源了，minio 的开销也不小。所以最近趁着搬家，又试了一下，终于把 docker + 本地存储 跑通了。 1. 在 docker-compose.yml 里， web 和 sidekiq 容器中，已经预设了媒体文件的卷映射 这个不用动。——也可以改成其它的路径，但要和后面的设置一致（本文用相同的颜色标明）。 2. 修改 .env.production PAPERCLIP_ROOT_URL 是服务器的所有媒体文件链接的子文件夹名称，形如： 默认值是 /system；但是建议改成独特一些的名字，而且建议和 S3_BUCKET 一致。以后需要在本地存储和 s3 之间转换时，可以省一点心。（所以要独特一些，防止回头在 s3 上和别人撞名）…

  • Fediverse: 是否要自建实例？

    之前和人聊到，自建 fediverse 实例时，和在其它实例做注册用户相比，一些不同的体验。然后发现，谈到的许多东西，对于没有自建经历的网友，还是很新鲜的。所以索性在这里列出来，让大家了解一下。 自建实例的优点 1. （可能）更好的稳定性 是的，自建并不是「不稳定」的代名词；恰恰相反，如果技术能力达标，个人实例因为开销相对较少，稳定性反而比很多中小型实例要高。即使我完全有能力，担任几百名用户的实例管理员；和维护一个我自己用的实例相比，我也是对后者的稳定性更有信心的。 而另一方面，现有实例的站长们，也未必都是很靠谱的。他们会因为各种技术、非技术、甚至搞笑的原因，导致站点无法访问。常见例子包括： 目前 fediverse 更换一次账号，还是满麻烦的；也并没有旧帐号数据的导入功能。所以，如果想要让自己的账号，长久地存在下去，自建可能是更好的选择。 以及，自建实例有更好的安全性。——像 fediverse 这类的程序，暴露出的系统漏洞，其中相当大一部分，都是通过「站内用户的恶意攻击」来触发的（譬如上传会包含代码的媒体文件）。如果这个站点只有你自己在使用，那么，这类漏洞，对你来说是无关紧要的。 2. 更好的隐私控制 之前写过一篇《Fediverse 站长都能看到什么？》。普通用户的很多未公开信息，对于所在实例的站长，技术上都是可见的。如果你在这些隐私方面有所顾虑，或者打算把 fediverse 账号当成私密日记来用，那么，自己建站，信息被不相干的人看到的可能性，会更少一些。 3. 管理自己的全部数据 现有的 fediverse 服务程序，为普通用户提供了数据导出功能，但导出的数据内容很有限。譬如 mastodon 导出的数据中，包括： 但并不包括： 其它程序的数据导出，也都大同小异（twitter 也差不多）；有的甚至会更少，譬如支持和 fedi 账号互 fo 的，图书管理程序 bookwyrm，用户能导出的，只能用惨烈来形容（只有书的链接；没有书的标题和简介！没有你的书评！）。如果你希望未来也能够看到这些自己交互过的信息，而不是随着网站的消失而听天由命，那么，可能一开始就选择自建比较好。 另外，mastodon 的搜索功能，做的很差劲的（尤其是中文）。elastic search 的开销极其巨大，效果也不好。虽然我也很少用搜索功能，但一旦真的有什么信息，需要精确查找，直接在自己建的站里用 SQL 搜索数据库，要舒适很多。 4. 更少的站内约束 很多 fediverse 实例，是有其内部的聊天「氛围」的。一些和氛围不合拍的发言，可能会遭到实例其它用户的抵制，甚至举报。很多时候，这样的分歧可能无关对错，但多少会对发言者产生困扰和拘束。又或者，站长决定，或者通过「民主表决」的方式，让全站屏蔽了某个实例，而你可能并不希望这样。如果是自建的话，做自己的站长，这样的约束可能会少一些。——虽然偶尔还是会看到一些来自外站的举报，但跨站举报本来就没有相应的处理和交互机制，无视就可以了。以及，我并不是指，自建站就可以肆无忌惮地发色情或者仇恨言论，那可能会让你的整个站点，被其它实例屏蔽的。 5. 使用自己的个性域名作为账号 这样看起来比较酷。但也仅仅是比较酷而已。 6. 免翻墙 随着 fediverse 逐渐进入某国审查机构的视野，那些几百甚至几十人的实例，未来被封杀的可能性也会急剧增加。相对来说，用个人域名在海外服务器搭建的，个人使用的实例，短期内被封的可能性，还不是很大。自建站的用户不必翻墙，就可以直接通过自己的实例，访问到其它被封实例的内容。——当然，翻墙属于必备技能，所以这也算不上是多大的优点。 自建实例的缺点…