Tag: self-host

  • 把日常阅读的网页,用 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 逐渐进入某国审查机构的视野,那些几百甚至几十人的实例,未来被封杀的可能性也会急剧增加。相对来说,用个人域名在海外服务器搭建的,个人使用的实例,短期内被封的可能性,还不是很大。自建站的用户不必翻墙,就可以直接通过自己的实例,访问到其它被封实例的内容。——当然,翻墙属于必备技能,所以这也算不上是多大的优点。 自建实例的缺点…