ppt.cc/fVjECx ppt.cc/fEnHsx ppt.cc/fRZTnx ppt.cc/fSZ3cx ppt.cc/fLOuCx ppt.cc/fE9Nux ppt.cc/fL5Kyx ppt.cc/fIr1ax ppt.cc/f71Yqx tecmint.com linuxcool.com linux.die.net linux.it.net.cn ostechnix.com unix.com ubuntugeek.com runoob.com man.linuxde.net bit.ly/2EzoUDo bit.ly/2tW6eYT bit.ly/2X6vadl bit.ly/2viLpHU linuxprobe.com linuxtechi.com howtoforge.com linuxstory.org systutorials.com ghacks.net linuxopsys.com v.gd/2P9wTx v.gd/FtfpqE v.gd/eMfHsm v.gd/Ub7mqv v.gd/RReVk0 v.gd/vS3uTI v.gd/4Zxmba
Total Pageviews
Monday 30 September 2024
使用Rust,通过 TCP转发 DNS 协议
之前一直使用 coredns 做 DNS 的 TCP 转发。最近在重构一个项目的时候,看了一眼 DNS 的协议。发现基于 TCP 的 DNS 的查询其实和 UDP 是一样的,只是加了 16bit 的长度描述而已。所以干脆用 rust 写了一个简单的组件供项目使用。当然也可以独立使用。详见下方链接。
links:
https://github.com/ffff-official/dns-forward-over-tcp
https://crates.io/crates/dns-forward-over-tcp
使用 iptables 转发 dns 服务
最近发现手里的一个动态域名经常在需要访问的时候查询不到 IP 地址。这个域名服务器是自己部署在海外的。所以最开始出现的时候以为可能是国内的访问海外服务器不顺畅的问题。但最近越来越频繁的遇到,有点干扰正常的工作了。所以决定看一下怎么回事。
一路排除最后才发现原来声明的两个 NS 记录地址,其中有一个弃用了。但是忘记改ns记录了。所以就可能导致其他查询服务轮询到这个地址的时候会出现不可访问的情况。
解决这个问题也很简单,删掉那个没有使用的ns记录即可。不过为了避免国内访问海外不顺畅的问题,所以另外再部署一台服务器。但是这个 dns 服务器会访问数据库,如果部署多个实例可能会带来数据同步的问题。最后决定做一个简单数据转发即可。
基本情况
A服务器公网地址:100.0.0.1
B服务器公网地址:100.0.0.2
B服务器内网地址: 192.168.1.3(eth0)
配置 B 服务器
iptables -A PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to-destination 100.0.0.1:53
iptables -A POSTROUTING -p udp -d 100.0.0.1 --dport 53 -j SNAT --to-source 192.168.1.3
这是一个典型的数据转发,也很简单。这个时候从外部发起查询应该是会获得正确的 dns 数据。
dig @100.0.0.2 test.com
但是没有任何反应。直到 timeout。
检查了 net.ipv4.ip_forward
,也是正确启用的。
百思不得其解的时候,突然发现了 iptables-save
输出的数据中。FORWARD
默认是全部 drop
的。将 eth0
设置为 accept
即可。
iptables -A FORWARD -i eth0 -j ACCEPT
Sunday 29 September 2024
html5音/视频播放器
HTML5对于网站建设来说是一项具有革命性的技术,未来的应用程序都将基于HTML5。HTML5加CSS3一起可以打造出非常美观和先进的网站,未来的网页设计就是他们的天下。下面是一些基于HTML5技术的免费音视频播放器,可以嵌入到WordPress或者其它网站中。
1.MooTools HTML5 Audio Player一个跨浏览器的音频播放器和JavaScript框架。https://github.com/gruis/mtAudioPlayer
2.jPlayer代码开源,可将跨平台的音频和视频加到您的网页,可通过API创建自己的播放器。
3.Degradable HTML5音视频插件 一个不错的WordPress插件,音视频都可播放。
4. https://github.com/kolber/audiojs允许在任何地方使用HTML5的audio标签.
https://github.com/jedfoster/AudioJS
5.HTML5 Audio Player非常轻量级的音频播放器 HTML5,CSS3和jQuery打造,不支持Flash。
(https://scottandrew.bandcamp.com/, https://scottandrew.bandcamp.com/album/save-you-from-yourself)
6.SoundManager 2使用JavaScript播放音频。
7.JME支持音频/视频。
8. https://speakker.com/create-your-website-with-blocks/ ,提供多个播放选项控制。
9. https://github.com/elfuego/oiplayer
10.Media Element采用纯HTML5和CSS编写。
11. https://ableplayer.github.io/ableplayer/, 跨浏览器的媒体播放器。
CSS代码实现网站变成全灰色
为了表示对重庆东方之星客轮长江翻沉事故中遇难者哀悼,腾讯网整个网站显示成全灰色。看了下腾讯网的源代码,实现很简单,在CSS样式表中加入全局webkit-filter: grayscale灰度值即可,同时考虑不同浏览器的兼容性。
CSS代码如下:
<style>
body *{
-webkit-filter: grayscale(100%); /* webkit */
-moz-filter: grayscale(100%); /*firefox*/
-ms-filter: grayscale(100%); /*ie9*/
-o-filter: grayscale(100%); /*opera*/
filter: grayscale(100%);
filter:progid:DXImageTransform.Microsoft.BasicImage(grayscale=1);
filter:gray; /*ie9- */
}
</style>
秋雨夜眠 白居易〔唐代〕
凉冷三秋夜,安闲一老翁。
卧迟灯灭后,睡美雨声中。
灰宿温瓶火,香添暖被笼。
晓晴寒未起,霜叶满阶红。
译文
秋天的夜晚带着阵阵寒意,只有我一个老头安宁自在的在家。
熄灯之后迟迟才躺下睡觉,在秋雨声中渐渐进入梦乡。
烘瓶里的燃料经夜已化为灰烬,不得不起床加点火烘烤被子。
早上天空晴朗,但寒气未消不想起床,只看到秋雨把霜叶打落得到处都是。
注释
三秋:指秋季。七月称孟秋、八月称仲秋、九月称季秋、合称三秋。
安闲:安宁清闲,安宁自在的样子。
宿(xiǔ):夜。瓶:烤火用的烘瓶。
晓:拂晓,天刚亮的时候。
阶:台阶
科学上网的思路
目前的主要方法是通过中转服务器来和目标网站建立连接,在这个过程中想办法隐藏中转服务器的信息,客户端的信息以及我们访问目标网站的信息。 整个过程都是TLS1.3加密,还是安全的。当然如果使用超级计算机,对加密信息进行特征提取,深度学习,还是容易被攻克。可以参见文末附录的几种已申请专利的方法。 所以还是要低调,自己用就好,不存在调用资源,使用超级计算机对你进行深度破解的必要性。
绑定域名,然后使用SSL证书。
传输层,HTTPS,TLS1.3加密。客户端与服务端之间强制TLS1.3加密访问。
CDN分发。CDN服务商与源站之间强制TLS1.3加密访问。CDN服务使用国外的,源站即使被封,CDN与源站之间还能访问,还是能通信。
附录
- 维基百科
- 一种数据包频度分析的网络代理加密流量特征提取方法
- 一种代理上网行为识别与检测方法
- 一种基于卷积神经网络的***流量检测方法
- github
- * / * 传输方式哪个好?(原理对比)
- 关于***+CDN,目前相对最安全的科学手段。-基本原理
--------------------------------------------------------------------------
关于科学上网方法的一些记录
- 安装
1 | bash <(curl -sL http://cdn.jsdelivr.net/gh/littleyz/v2ray/go.sh) |
得到Port及UUID,记录之。
- 转发
通过TLS给数据安全性提供保障。将上一步得到的Port转发到的443端口,即可通过https://domain.com 代替IP:port的方式使用科学上网。
在Nginx配置文件中添加以下代码,进行端口转发。
1 | location /path { # 与 V2Ray 配置中的 path 保持一致 |
- /etc/v2ray/config.json配置文件
1 | { |
- 常用命令
停用并卸载服务(systemd)
1 | systemctl stop v2ray |
删除多余的文件
1 | #(配置文件删除) |
1 | # 查询程序是否运行 |
命令可以查看v2ray是否正在运行。如果输出为空,大概率是被selinux限制了,禁用selinux即可。
1 | # 禁用selinux |
1 | # 设置开机启动 |
- 其他问题
端口是否被禁用。在对应的vps管理里防火墙放行需要的端口。或使用以下命令:
1 | # firewalld放行端口(适用于CentOS7/8) |
时间同步,服务端和客户端的时间一定要一致,相差不能超过2分钟。
服务器选择,就近原则。比如香港服务器肯定优于美国,实际应用中,香港服务器正常ping值10ms左右,使用科学上网以后ping值能在100-200ms以内,而美国服务器比如洛杉矶的,正常ping值200ms左右,使用科学上网以后,大约在400-500ms。网络延时太久,对下载速度影响不大,但是对上传速度影响太大,不知何故!(可能是使用了转发的缘故,如对安全性要求不高,可以不用转发。另一方面可能和服务器本身有关,使用科学上网以后,阿里云香港服务器/轻量云服务器上传速度均不理想,但是腾讯云香港轻量服务器上传速度就很好。)
SSL证书的相关知识
想起自己经常需要更新部署SSL证书的一个痛点。每次只是按部就班的操作,这次停下来,全面了解下关于SSL证书的来龙去脉及相关知识。
SSL/TLS协议
Netscape在1994年推出其首版网页浏览器-Netscape Navigator时,推出https协议,以SSL(Secure Sockets Layer,安全套接层)对传输数据进行加密,这是SSL的起源。
SSL利用数据加密技术,可确保数据在网络传输过程中不会被截取,从而能保证数据的安全性和完整性。SSL 协议位于 TCP/IP 协议与各种应用层协议之间。
1999 年经过 IETF(The Internet Engineering Task Force,国际互联网工程任务组)讨论和规范后,SSL改名为TLS(Transport Layer Security)。发展至今已经有TLS1.0,TLS1.1,TLS1.2等多个版本,目前最新版本是TLS1.3。
SSL协议发展历程
协议 发布时间 状态
SSL 1.0 未公布 未公布
SSL 2.0 1995年 已于2011年弃用
SSL 3.0 1996年 已于2015年弃用
TLS 1.0 1999年 于2021年弃用
TLS 1.1 2006年 于2021年弃用
TLS 1.2 2008年
TLS 1.3 2018年
(数据来源:维基百科:传输层安全性协议,2024年1月17日访问)
SSL协议的基础是公钥基础设施(Public Key Infrastructure,PKI),而公钥基础设施普遍商业运营。
主流浏览器对TLS v1.3的支持情况
SSL证书
SSL证书就是遵守SSL协议的服务器数字证书,通过验证域名、服务器身份后,由受信任的数字证书授权机构(Certificate Authority,CA)颁发,具有给通过https等协议进行数据传输的各方(主要是浏览器与服务端)进行身份验证和数据传输加密等功能。
在PKI中,CA是负责发放和管理数字证书的权威机构,承担公钥体系中公钥的合法性检验的责任。
SSL证书的有效期
SSL证书在诞生时并没有效期的限制,可以是5年,10年甚至更久,但随着SSL证书的广泛使用,特别是2005年5月17日由VeriSign和Comodo牵头成立国际标准组织–CA/Browser Forum后,出台了一系列标准,SSL证书的有效期开始缩短。
关于CA/Browser Forum
Organized in 2005, we are a voluntary group of certification authorities (CAs), vendors of Internet browser software, and suppliers of other applications that use X.509 v.3 digital certificates for SSL/TLS, code signing, and S/MIME.
2018年3月,有浏览器厂商试图将SSL证书的有效期从3年缩短到1年,但在CA的抵制下妥协为2年。
2019年,浏览器厂商再次提出同样的提案,再次遭受了几乎所有CA的抵制。
2020年2月,苹果公司在违反CA/Browser Forum标准操作程序,没有呼吁投票的情况下,单方面宣布,决定在其设备上将可以使用的SSL证书有效期缩短为398天(一年时间加上一个月的缓冲期),数周后火狐就宣布跟进,而数月后谷歌的跟进则使得CA机构的抵制没有什么实际意义了。
2023年3月,谷歌仿效苹果曾经的操作,在其“共同前进”(Moving Forward, Together)路线图中宣布,将SSL证书的最长有效期从现有的398天减少到90天,甚至准备向10天的目标迈进。
SSL证书有效期
浏览器厂商为什么一直在推动SSL证书有效期缩短呢?其实谷歌在其“共同前进”路线图对其动机进行了一些阐述:
缩短SSL证书生命周期一方面是为了鼓励证书部署自动化。证书自动化将推动https生态系统摆脱“巴洛克式”(巴洛克式是一种艺术风格,巴洛克的本意就是不规则的,不常规的意思),耗时且容易出错的颁发流程,降低人力成本和工作难度规避人为失误导致的事故。
另一方面,SSL证书有效期的减少,促使网站更频繁地续订证书,而续订的证书会采用最新的算法并进行密钥的轮换,从而将生态系统快速过渡到具备抗量子算法所需的加密敏捷性。
总结起来就是,缩短SSL证书的有效期,可以提高SSL证书的安全性和可信度。
Google网站现用证书的有效期确实只有90天
SSL证书自动化部署
SSL证书有效期缩短,提高可靠性和安全性的同时,却给网络运维人员带了需要频繁更新证书的压力。随着证书有效期可能缩短到10天,证书部署自动化将是未来大势。
对于独立服务器,采用acme协议,可以实现自动申请,验证,签发,安装(更新续签)证书。acme目前已支持很多CA机构,其中包括比较著名的提供免费证书的Let’s Encrypt以及Google Trust Services。宝塔面板等很多第三方续签证书功能的实现基本都是依托acme协议。
对于CDN服务,自动续签证书目前没有太多的好办法。但是一般CDN服务商会提供证书自动续签的功能。阿里云,腾讯云的CDN服务里要实现自动续签证书,需要付费版的证书。又拍云CDN提供免费的Let’s Encrypt DV SSL 单域名证书的自动续签功能。
对于serveless服务(比如netlify,vercel等),一般可以使用其默认的https服务,无需自己部署更新证书。
对于CDN,对象云储存等部署的站点,免费证书如何自动化部署更新?在Github上找到几个不错的开源方案:certd,acme-qcloud-scf及Tencent CDN Cert Manager。
CertD能部署到自己服务器上,支持从Let’s Encrypt申请证书(支持通配符域名,域名解析支持阿里云,腾讯云,华为云等),全自动部署到阿里云,腾讯云等云服务及主机,证书自动续期更新,所有过程支持邮件通知。
CertD支持的部署功能
而acme-qcloud-scf主要借助腾讯云云函数实现通过acme协议的Let’s Encrypt证书的自动部署和更新(Node.js 版本)。证书生成后能自动上传到腾讯云 SSL 托管平台并绑定到相关 CDN 加速域名(如上,腾讯云自带的SSL证书管理更新是付费证书才能支持的功能)。
Tencent CDN Cert Manager,顾名思义就是支持给腾讯云CDN绑定的CDN域名自动更新证书的服务,支持Docker部署。证书提供商自然也是Let’s Encrypt。
扩展阅读:
- 谷歌对根CA策略的“共同前进”建议:更频繁地轮换ICA
- 阿里云将免费SSL证书的有效期调整为3个月
- 腾讯云SSL证书自动化管理方案
- 维基百科:根证书,公开密钥认证
- 又拍云SSL证书服务
- digicert:TLS/SSL证书的有效期有多长?
- Google:Automate Public Certificates Lifecycle Management via RFC 8555 (ACME)
My App Defaults
也分享一些自己喜欢的工具。 📨
Mail Client: Spark
📮 Mail Server: Exchange Server(MS Outlook) and MXroute
📝 Notes: Obsidian + Obsidian Sync and Drafts
✅ To-Do: Things 3
🎨 Photo editing: Darkroom and Acorn 7
📆 Calendar: Apple Calendar and Dato
📁 Cloud File Storage: iCloud and Nutstore (WebDAV)
Bookmarks: DEVONthink
📑 Read It Later: Readwise Reader and Zotero (Research)
🛒 Shopping Lists: Drafts
🍴 Meal Planning: wanna give Mela a shot.
📰 News: Readwise Reader (RSS feeds and Newsletter), Twitter and Buzzing
Podcasts: Castro
Password Management: Enpass
Launcher: Alfred
Text input: Squirrel
Translation app: Bob
App Defaults 让我想起了一个很久以前离线团队做的项目:利器。这个项目采访了很多有趣的人,收集大家所珍爱的工具,探索人和物之间的联系。比较可惜的是 2019 年之后就没有新的文章更新了。
但这个项目的生命力很强,即使现在读,也会有很多收获。因为这些分享中不仅有工具,还有受访者的经验和体会。
Send text/password securely
https://horuspass.com/send
How it works:
Passwords are sent as an expiring encryted package that can only be read once.
- The password is encrypted in-browser using 2 related tokens issued by the server (the encrypted password is never sent to the server).
- A shareable URL is generated with the encrypted password package as a hash parameter (so it isn't sent to any server) and the first of the two tokens as a query.
- Once the link is shared with the recipient and they open it a request is made to the token server with the one token from the parameter. This retrieves the second token from the token server and the token pair is used to decrypt the password.
- When the second token is requested both tokens are deleted from the server meaning the encrypted password can only be decrypted once.
from https://horuspass.com/send
域名的DNS解析优化
如何提高,优化博客域名的解析时间,决定分理论和实验两步走。理论方面,全面学习了解下关于域名DNS解析的知识;实验方面,试用下常见的一些DNS域名解析服务(当然主要是免费的DNS域名解析服务)。
理论
当我们访问一个网站,在浏览器里输入网站的域名,相应的域名解析服务器(DNS服务器)会将域名解析成对应的ip地址,然后返回给浏览器。我们访问一个网站,实际是在访问一个基于ip地址提供的web服务(互联网早期三大经典应用ftp,www,e-mail背后都是ip地址)。
互联网里域名解析的体系及流程是这样的:
1.用户在浏览器中输入域名“mydomain.com”, 若本地浏览器没有缓存,则向LocalDNS发起请求。所谓LocalDNS一般为网络运营商提供的DNS服务,比如电信运营商的经典的114.114.114.114,各地区运营商的DNS(比如广东电信的202.96.128.86)。LocalDNS是域名解析的起点,电信运营商在这个领域有先天优势(他们提供的权威DNS解析服务能更快)。从这个角度考虑,这可能是众多云服务商都想推广自己的公共DNS的原因。比如百度云的180.76.76.76,阿里云的223.5.5.5,腾讯云(DNSPod)的119.29.29.29。
2-1.若LocalDNS服务器里缓存有域名mydomain.com对应的IP地址信息,则直接向用户返回IP地址信息,如此即完成了一次域名查询解析服务。可以看出这个过程时间会非常短,对于个人博客,这是最好的情况。LocalDNS返回最终的结果(IP地址信息)给用户,这个过程被称为递归查询。
域名对应IP地址信息缓存在LocalDNS服务器的时间,是由TTL控制,TTL即time to live,是我们在域名解析(即使用权威域名服务器)时设置的,一般可以设置成几秒到几分钟不等,最长可以设置24小时(86400s)。
2-2.LocalDNS若完全无缓存,则采用迭代查询的方法,向各域名服务器进行查询。
2-2.1LocalDNS最开始向根域名服务器查询。根域名服务器并不知道mydomain.com这个域名对应的具体IP,只是告知应该向.org TLD(Top Level Domain,顶级域名)查询。
2-2.2LocalDNS则紧接着询问.org顶级域名服务器,被告知应该询问AliDNS(mydomain.com这个域名使用AliDNS提供的权威域名解析服务),它知道。
2-2.3LocalDNS则转向AliDNS这个权威域名服务器,获知了mydomain.com域名对应的IP地址信息。
2-2.3.1LocalDNS将获取到的mydomain.com对应的IP地址信息反馈给用户,并遵循TTL设置,将结果缓存起来。
综合以上,域名解析过程有这些要点:
各层级的域名服务器都会缓存域名解析信息;
不同地区的访问者越多,域名解析信息越能及时被缓存,用户感知到的解析时间会越短。TTL设置的越长(缓存时间越久),可能需求的解析时间也会越短;
从域名解析时间角度考虑,个人博客站点(尤其首页)使用CDN可能并不是总是好的。因为访问量并不大,CDN IP地址多,如果没有及时缓存,可能致解析时间多变,久;
电信运营商来做域名解析(权威域名服务器),有先天优势。用户的LocalDNS多用他的,路近道宽。实践中发现 www.ctyun.cn (电信天翼云)这个域名各地解析时间平均只需几十毫秒,甚至多个节点只需几毫秒。作为对比,阿里云( www.aliyun.com ),腾讯云( cloud.tencent.com )都是100-200ms,逊色不少。比较可惜,天翼云的DNS解析没有免费版;
DNS DDOS攻击多发生于权威域名服务器端;
DNS劫持多发生于LocalDNS服务器端;
国外的权威域名解析服务(比如Cloudflare)有其优势,比如可能更靠近根域名服务器或者部分顶级域名服务器,但国内使用,单独看解析时间仍不理想。节点多位于中国境外,解析服务器与境内连接有网络带宽的瓶颈。
实验
通过前面理论分析,对于个人博客站点,要优化自己域名解析时间,唯一能做的就是选用合适的(解析速度快的)权威域名解析服务。主要是免费的域名解析服务。
目前提供免费域名解析服务(权威域名解析服务)的有:
阿里云的云解析 DNS
腾讯云的DNSPod
华为云的云解析服务 DNS
Cloudflare的DNS
其中DNSPod应该是国内解析量最大的,日均解析量为1700亿次,其次是阿里云的云解析,日均解析量大约是1000亿次。Cloudflare的数据量不清楚,可能是世界范围内规模最大的域名解析服务。华为云的云解析服务可以免费使用其他家收费才提供的各种高级功能。
除了以上,其实各提供公有云服务的IDC均会提供域名解析服务,为快速实验比较计,仅测试以上主流的四种。
实验前提:
通过Whois查询工具,收集到使用不同域名解析服务的个人博客域名,同时加入使用对应收费版的域名解析服务的网站作为对比。因各博客及网站域名解析里的TTL缓存时间不明确,因而采用不同时间段,多次访问被测站点的办法测试,时间跨度持续约3个星期,以尽可能排除缓存干扰。
测速平台:https://tool.chinaz.com/speedtest/ (仅评估域名解析时间,连接时间及下载时间忽略)
实验结果:
(测试时间2024.4.10-4.30)
样本网站 DNS解析服务商 DNS服务器 服务器地域 解析耗时
Q博客 DNSPod免费版 cotangent.dnspod.net,group.dnspod.net 香港,日本,新加坡等地域 100-150ms
W博客 DNSPod免费版 clean.dnspod.net,clifford.dnspod.net 境内IP 100-150ms
M博客 DNSPod免费 kama.dnspod.net,lake.dnspod.net Cloudflare 500-800ms
Z网站 DNSPod付费版 ns3.dnsv5.com,ns4.dnsv5.com 境内CDN 50-100ms
S博客 阿里云DNS免费版 dns11.hichina.com,dns12.hichina.com 境内IP 200-300ms
H网站 阿里云DNS付费版 vip3.alidns.comvip4.alidns.com 境内CDN 100-150ms
J博客 华为云DNS解析 ns1.huaweicloud-dns.com, ns1.huaweicloud-dns.cn 境内IP 200-300ms
I博客 Cloudflare DNS jay.ns.cloudflare.com, kara.ns.cloudflare.com Cloudflare 500-800ms
(实验过程省略。)
上面解析耗时数据可以不用过多关注(不够严谨),直接看下面的结论。
结论
(主要针对个人博客站长)
免费版域名解析服务解析时间波动较大(一般上午解析更快,下午及晚上较慢。当然解析服务本身是否稳定是另一个不确定因素),收费版的比较稳定;
使用国外CDN(比如Cloudflare),服务器,所需域名解析时间会更久。使用临近中国大陆地域的服务器,比如中国香港,新加坡,日本等,所需解析时间会较短;
更高级的收费功能(华为云DNS解析免费提供,其他家收费提供),比如负载均衡,更多的解析线路,更细致的地区划分,对于个人博客意义不大(个人博客不会部署那么多服务器);
CDN有种种好处,但从域名解析角度看,单IP更好;
个人博客可以设置更长的TTL时间(24小时,86400s),以达到最好的缓存效果;
使用某家的云服务器,然后使用同一家的域名解析服务,可能有更短的解析延时,更稳定的表现;
现在回到最开始的问题,我大概从2010年前后开始使用DNSPod的域名解析服务,彼时DNSPod还没有被腾讯收购。习惯使然或者其他因素,一直没考虑过更换或者尝试使用其他的域名解析服务。直到这次发现DNSPod延时居然这么久,测试一段时间后发现,各家免费的域名解析服务效果,性能,稳定性其实都差不太多。而DNSPod被我发现表现差,可能正巧这段时间其服务不太稳定。DNSPod对外公开的系统状态监控证实了我的这种猜想。可以看出DNSPod日正常解析量在1800亿次上下,而我测试期间(4月10-30日),有多次波动很大,最低到1400亿-1500亿次,最多减少了22%左右。
如此看来,免费的权威DNS服务器用得人多,对于服务商并非一定是好事(服务跟上,服务器数量,布局合理,技术更新等都需要花钱。当然想办法将免费用户转换成付费用户又是另一方面了)。对于云服务提供商,与传统电信运营商去竞争LocalDNS可能更有价值.
Montaigne可以使用 Apple Notes 搭建轻博客
https://montaigne.io/
https://app.montaigne.io/auth/signin
https://montaigne.io/pricing ,提供free plan
(https://alto.so/)
需要有美区的 apple id.
轻博客服务:bearblog.dev
官网:https://bearblog.dev/
https://bearblog.dev/signup/
https://bearblog.dev/accounts/login/
https://docs.bearblog.dev/
我的示例:https://brite.bearblog.dev/
my login id: briteming#gmail.com
它支持发表180kb的长文。
free plan不支持嵌入一般性的html code,只支持嵌入youtube video的html code。
此处https://github.com/HermanMartinus/bearblog/,作者说“Bear Blog has been built as a platform and not as an individual blog generator. It is more like Substack than Hugo. Due to this it isn't possible to individually self-host a Bear Blog.”,难道https://github.com/HermanMartinus/bearblog/不是bearblog程序的源代码吗?
Saturday 28 September 2024
Thursday 26 September 2024
《习主席之歌》— 讽刺搞笑歌曲。根据蒋大为的《牡丹之歌》改编
这视频要是被猪头看到了,估计会气的七窍流血。哈哈
Wednesday 25 September 2024
Tuesday 24 September 2024
流程可视化开源Web应用-FUXA
Web-based Process Visualization software.
https://frangoteam.org/
FUXA is a web-based Process Visualization (SCADA/HMI/Dashboard) software. With FUXA you can create modern process visualizations with individual designs for your machines and real-time data display.
- Devices connectivity with Modbus RTU/TCP, Siemens S7 Protocol, OPC-UA, BACnet IP, MQTT, Ethernet/IP (Allen Bradley)
- SCADA/HMI Web-Editor - Engineering and Design completely web-based
- Cross-Platform Full-Stack - Backend with NodeJs and Frontend with Web technologies (HTML5, CSS, Javascript, Angular, SVG)
Here is a live demo example of FUXA editor.
FUXA is developed with NodeJS (backend) and Angular (frontend).
See the Wiki for more details about installing and getting started
Install from NPM
You need to have installed Node Version 18.
WARNING In linux with nodejs Version 18 the installation could be a challenge. If you don't intend communicate with Siemens PLCs via S7 (node-snap7 library) you can install from NPM @frangoteam/fuxa-min
npm install -g --unsafe-perm @frangoteam/fuxa
fuxa
Download the latest release and unpack it
You need to have installed Node Version 18.
WARNING In linux with nodejs Version 18 the installation could be a challenge. If you don't intend communicate with Siemens PLCs via S7 you can remove the node-snap7 library from the server/package.json
cd ./server
npm install
npm start
Open up a browser (better Chrome) and navigate to http://localhost:1881
Electron is a framework for building cross-platform desktop applications using web technologies. An Electron application is standalone, meaning it can be run independently on your desktop without needing a web browser.
To create the Electron application, you need to have node.js 18 installed. Follow these steps:
Build Server and Client First
cd ./server
npm install
cd ../client
npm install
npm run build
Packaging
cd ./app
npm install
npm run package
After following these steps, you will have a standalone Electron application for FUXA. The application can be found in the ./app directory.
- Look the guide in wiki pages
- Look video from frangoteam
- Look video from Fusion Automate - Urvish Nakum
Install and start to serve the frontend
cd ./client
npm install
npm start
\
from https://github.com/frangoteam/FUXA
-----
FUXA是一款开源的流程可视化 Web 应用,可快速构建和部署可扩展的 SCADA,HMI,仪表板或 IIoT 系统的实时数据,构建多种不同设计风格的可视化流程图。支持创建具有个性化设计可视化面板,以及自动化工业工厂的控制仪表。项目基于Typscript编写,遵守MIT开源协议。
功能特色:
设备与 Modbus RTU/TCP、西门子 S7 协议、OPC-UA、BACnet IP、MQTT、以太网/IP (Allen Bradley) 的连接.
SCADA/HMI Web 编辑器 – 完全基于 Web 的工程和设计.
跨平台全栈 – 使用 NodeJs 的后端和使用 Web 技术(HTML5、CSS、Javascript、Angular、SVG)的前端.
源代码:https://github.com/frangoteam/FUXA
用Pingvin Share自建文件分享平台
开源文件分享平台项目「Pingvin Share」可以用来代替 WeTransfer 等的分享网站,如果你有自己的服务器,可以支持通过 Docker 部署或者 Stand-alone 部署。
功能介绍
完全自建:轻松使用私有服务器搭建文件共享平台
完全隐私:你的文件只属于你!不要将它放到第三方文件平台
完全无限:想上传多大都可以,硬盘容量的大小是唯一的限制
功能特性
通过可自定义后缀的链接分享文件
可自定义任意大小的文件上传限制 (受制于托管所在的硬盘大小)
对共享链接设置有效期限
对共享链接设置访问次数和访问密码
通过邮件自动发送共享链接
整合 ClamAV 进行反病毒检查
项目地址:
https://github.com/stonith404/pingvin-share
(https://stonith404.github.io/pingvin-share/introduction)
演示地址:
https://pingvin-share.dev.eliasschneider.com
------------------
A self-hosted file sharing platform that combines lightness and beauty, perfect for seamless and efficient file sharing.
https://stonith404.github.io/pingvin-share/
For more installation options and advanced configurations, please refer to the documentation.
from https://github.com/stonith404/pingvin-share?tab=readme-ov-file
-------------------------------
Stand-alone Installation
Required tools:
git clone https://github.com/stonith404/pingvin-share
cd pingvin-share
# Checkout the latest version
git fetch --tags && git checkout $(git describe --tags `git rev-list --tags --max-count=1`)
# Start the backend
cd backend
npm install
npm run build
pm2 start --name="pingvin-share-backend" npm -- run prod
# Start the frontend
cd ../frontend
npm install
npm run build
API_URL=http://localhost:8080 # Set the URL of the backend, default: http://localhost:8080
pm2 start npm --name "pingvin-share-frontend" -- run start
Uploading Large Files: By default, Pingvin Share uses a built-in reverse proxy to reduce the installation steps. However, this reverse proxy is not optimized for uploading large files. If you wish to upload larger files, you can either use the Docker installation or set up your own reverse proxy. An example configuration for Caddy can be found in ./reverse-proxy/Caddyfile
.
The website is now listening on http://localhost:3000
, have fun with Pingvin Share 🐧!
from https://stonith404.github.io/pingvin-share/setup/installation#stand-alone-installation