收录: 一个更新很勤快的破解版宝塔. 很干净.

https://blog.cxinyun.cn/825.html

删除/www/server/panel/BTPanel/templates/default/index.html第287行的js引用以关闭小广告.

收录: 最后一个没有广告的portainer版本

docker pull portainer/portainer:1.24.2

proxmox去除弹窗:/usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js

搜索data.status 然后把整个判断改成false. 这样是最彻底的做法.

pve国内源: deb https://mirrors.ustc.edu.cn/proxmox/debian/pve buster pve-no-subscription

我很喜欢pve, 也很喜欢pve这种佛系的商业宣传: '想删就删吧, 我不管你'

比某些那什么打着开源旗号处处宣传收费版的好多了.

如果你需要用一个虚拟化系统, 我强烈推荐pve, 别用esxi了.

论坛魔改版rocketchat: https://disk.monika.love/s/K38cP

对应的永久企业许可证(仅适用于这个魔改版, 正常pull的不能用)

q5dH1kKGtpuvXB9nfbk81gj4IczFQh4bE9b3uxHHx6+QbDCukuNQ/swjTXMhpiqT/24IX6erDx9lRi6WNAYb2ASrwHMhmoSMFnHRSDykrM1RPke0gU5UwkrROCq/pLBMpXmIsxE5Dgycv0DZXsUjQAoGsaxH8CJpzhD9kUI+0U2j2ciIC0SpqOttx6h6UXDFfTLdB4qg/aXLsXwisyOzA8BnBVrsxWzvsmLh5rstsug28BJAvUn+YmARnnK0YHXIl+0EwBdFdnaYxs0XYStRRgibE2XUcbt82D+ziCiJkABiQm0/oxNSxyd51mfIgU7gz5JbLbcq3JDDEkFxHpcm6g==

收录: 阿里云dcdn全站加速 自动刷新证书: https://disk.monika.love/s/Wb5UD

脑瘫阿里为了促销他的证书不给letsencrypt自动续签, 故出此计

需要一台能自动续签证书的联网服务器(装个宝塔就行), 需要创建阿里accesskey.

阿里云dcdn全站加速 自动刷新缓存: https://disk.monika.love/s/rDAhv

用他们的sdk工具做的, 兴许有时候有点用

需要自己做crontab. 我设置为服务器每次重启自动刷新一次.

需要部署在业务服务器上, 也需要阿里的key.

收录: 目前为止见过最全面的megacli指令: https://www.cnblogs.com/machangwei-8/p/10403626.html

我知道现在没什么人用raid卡了 但是万一呢?

论坛魔改版cloudreve: https://disk.monika.love/s/bwpIm

编译源码: https://disk.monika.love/s/9gJuW

破解了pro功能, 编入了论坛专用的登录系统, 修改了各种资源文件.

反正数据库是对内的, 账号密码什么的也不算机密了.

魔改版rocketchat的公钥:

-----BEGIN PUBLIC KEY-----

MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAqWSskd9/6zRx8kyPcics

b32w2wxVuw7yBT96rQ/8D+yMeCMO9wSSpHa/9nFywowEtigpt/wroPN+VGSwbtwP

FXBeqElBndGFAl86e5+EliH8Kz/hGnCmJNmXpxEK2RE03X4IxsYX7DDB7Mtx/iqs

cjB/OuvSBkjiSleS7blNIT/dA7K4/CJ3oiu02bL4ExclCHepzqNMeP3wUZgpxOnf

NOud8IXYK73zScuE8E157YwpzCKpVaHX7ZJf8QuNsOO5W/aIjKl3L6269+eIOErG

wONmaHnzfg9FLpJhzgpO38aVn76vD5KKjBajWskY+4a2gSQmKNeFqaqOozyEFM0e

cFWZVVZ3Leh4vEMoYVPyIzx96x8f2/ymPnhIuvQv5wN4fyepa7EY5UCcp71z8kfP

4FcUzPA0IDWyMihXR/G6XgQQZ4Gb/qBBhvrviJCFzfYDcJgL7FegFYHP3PGL07Qg

vLevMK+iQZPrxrbxySqdPOkgurKjVrXTUr4A9TgiLyIX5UlJq3E/RV7mfOqZnLTa

SCVXHBhuPlnCGZR01ToTCfKhMG1u0CFnL2+15hC9fqOmWv9Qke43qlJ0PgF3VJ/X

ux/mTpnk9gnbG9JH+mfH39RoFvTNinYwSMvYzutVOn69sOzdwhDla90l3ACh4xCV

K7JOX+uHkoNu3g2iVxiZUM0CAwEAAQ==

-----END PUBLIC KEY-----

在存储中加了一层base64

当初破解的时候参考的教程找不到了, 现在得想办法自己逆向自己的工程. 简单记录下.

这玩意脑血栓就脑血栓在它是私钥加密-公钥解密的, 很多在线工具用不了.

破解的方案是自己生成一对公私钥, 改代码里的公钥, 用自己生成的私钥生成证书, 然后填进去.

证书的格式是个json串, 但是我自己一则忘了当初的私钥是什么, 二则也没找到解密的工具.

这是加密过的证书, 什么时候实在要用再想办法拆开看格式吧, 不想折腾了.

q5dH1kKGtpuvXB9nfbk81gj4IczFQh4bE9b3uxHHx6+QbDCukuNQ/swjTXMhpiqT/24IX6erDx9lRi6WNAYb2ASrwHMhmoSMFnHRSDykrM1RPke0gU5UwkrROCq/pLBMpXmIsxE5Dgycv0DZXsUjQAoGsaxH8CJpzhD9kUI+0U2j2ciIC0SpqOttx6h6UXDFfTLdB4qg/aXLsXwisyOzA8BnBVrsxWzvsmLh5rstsug28BJAvUn+YmARnnK0YHXIl+0EwBdFdnaYxs0XYStRRgibE2XUcbt82D+ziCiJkABiQm0/oxNSxyd51mfIgU7gz5JbLbcq3JDDEkFxHpcm6g==

当然也有更暴力的方法, 很好想: 把decrypt方法的结果直接照证书格式写进去.

好吧, 我log了一下把解密结果弄出来了.

{"version":2,"url":"chat.monika.love","expiry":"2199-12-01","maxRoomsPerGuest":9999,"modules":["enterprise:*"],"tag":{"name":"Enterprise","color":"#F3BE08"},"meta":{"trial":false,"workspaceId":"64de2ab1ffb98e3ae038a510"}}

该替换改写的东西挺明显的, 这里只需要注意一下workspaceId是个什么.

你从rocketchat控制台里面下载参数, 获得的json里面就有这个东西.

一定记住证书是用私钥加密的!

其实我感觉这些东西可以传吾爱的, 但是懒. 有人愿意帮转载的话十分感谢.

至于cloudreve, 我就是找了个现成的破解版源码简单编译了下, 不太清楚原理.

说实话这个应该比rocketchat难, 一方面白嫖版的代码和pro不一样, 不花钱没法拿到手.

另外一方面是也没有试用版之类的东西可以参考.

不过拿到手的这个破解版其实也算挺新的, 此后的除了选择软硬删除之外没什么新功能.

软硬删除的意义也不大.

这份代码的来路也挺离谱的, 据说是官方的人随意撤销已经购买的用户的许可, 导致其愤而吾爱.

当然正版不贵, 但是花了钱买了许可还能被撤销这事也挺逆天的. 不想补票了.

我希望我们的坛友用到最好的服务. 要骂我目无法纪就骂吧.

mailcow-dockerize的安装配置

首先说明: 我尝试了ubuntu, kali和centos, 也尝试了代理和代理旁路游, 结论是它的compose文件里面带的mailcow/unbound这个东西是坏的, 根本用不了.

最后发现这一点的时候差点没把我气死, 浪费了几个小时.

所以unbound是什么? 就是一个dns服务器. mailcow非常画蛇添足地把这个dns服务器打包进了它的配置, 然后强制所有docker用这个dns. dns隔离的想法很美好, 但是好就好在他好他妈了个逼.

怎么检查这个问题发没发生呢?

前面的步骤按官方教程来, docker compose up -d之后等个几分钟, 然后docker ps. 如果你看到容器mailcow/unbound的健康检查显示为(unhealthy), 那就是跟我一样的问题.

怎么办? 其实不要想太复杂, 这个unbound里面没有任何特殊的主机名配置等等, 它就是一个标准的dns服务器, 跟路由器里面的一样. 办法也很简单:

破坏性最小的办法是另找一个能提供dns服务的docker, 然后在compose里面换上去就行. 我觉得太麻烦了.

其次是把一个dns服务器部署在本机上(比如bind9), 然后改一下compose里面的dns, 改到主机ip. 更扯了.

最后最简单的就是把所有跟dns有关的配置全部注释了, 让容器各回各家. 我这样做了, 也终于成功了.

然后呢? 然后你测试邮件的时候会发现邮件发不出去. 我不卖关子了, 这是postfix/mailcow的问题.

如果你再检查一遍compose, 会发现postfix这个容器要求unbound健康状态正常才会运作, 脑血栓得很.

一样注释掉或者删掉就行了. 再重新up -d, 然后基本上就正常了. 如果还不正常, 自己检查各个容器的网络对不对.

听着是挺容易的, 但是邮件服务器这个东西实打实地卡住了我好几天. 可能是我太笨了.

累了, 气死了, 歇会歇会.

这样直接暴露dns有没有隐患? 设计上的隐患我不知道, 但是至少可以用了. 安全上的隐患忽略就行.

你实在不放心就给你的路由器配置一个靠谱的dns, 比单独用docker方便多了.

收录 宝塔美化之一: https://blog.imlazy.ink:233/index.php/archives/38/

虽然宝塔这垃圾确实没什么打扮的必要, 但是万一呢?

实测可以适配创信破解的8.0.3.

无论什么组件项目崩溃了, 你至少可以先看看腿子.

更新: 8.0往后别用这个了, 会导致网站详细信息显示不出来!

10.29的整大活: synopsis的问题

我已经提交issue了, 作者今年还看过issue, 说不定能修一下或者查查问题.

链接在 https://github.com/imorland/synopsis/issues/15 .

我猜测, 这个问题是synopsis和官方功能mentions共同导致的.

至于怎么导致的:

• 触发条件是: 一个帖子, 其中一层楼回复了另外一层楼.
• 被回复的楼当然会首先被加载, 然后回复的楼会引用它.
• synopsis在打开帖子的时候似乎会尝试"扫描"帖子一遍.
• 如果设置为"最新贴", synopsis的扫描会是从后向前的.
• 于是回复贴就先于原帖被加载了出来. 但这样显然是没法加载出来的.
• 然后toSlug功能就读到了一个空的引用, 出现r.slug is not a function的情况.
• 然后找不着北的render模块渲染混乱就好理解了.

值得注意的是, 在帖子内刷新(直接获取html)会绕过这个问题, 因此在有问题的帖子里刷新会加载正常.

至于如果通过编辑等手段, 让前面的帖子引用后面的帖子, 会不会让正向扫描的synopsis也崩溃?

我不知道, 我应该现在去试试看.

更新: 试了一下, 并不会. 毕竟只是我猜测的.

希望作者给一个方案吧. 我不想费劲去翻别人写的东西了.