免费图片CDN服务statically.io

发布于
缓存图片：https://cdn.statically.io/img/xxx.com/img/xxx.jpg


抓取网站favicon：https://cdn.statically.io/favicon/xxx.com


抓取网站screenshot：https://cdn.statically.io/favicon/xxx.com/news


评论

发表评论

此博客中的热门博文

Mifare Classic card(M1卡)破解过程记录(准备+理论+获取扇区密钥+数据分析)

发布于
首先认识一下一卡通的类型，市面上常见的一卡通是IC卡的一种，IC卡即集成电路卡，也是广义上的智能卡，准备篇介绍一些智能卡的基础知识，帮助我们确定卡的类型和使用的设备， 目前淘宝上提供了设备和全套软件，确定好方法就可以自动化破解，下面的内容比较详细，不用全部看完也能破解，但了解一下可以提高效率 。 按照使用方式分类： · 接触式IC卡： 符合 ISO 7816 标准，卡片表面包含金属触点，读写需要 IO 线路接触，即需要插卡使用，如手机的 SIM 卡模块 · 非接触式IC卡： 符合 ISO/IEC 14443 标准，由 IC 芯片、感应天线组成，封装在一个标准的 PVC 卡片内，芯片及天线无任何外露 部分，通过 RFID 感应使用，校园卡及身份证都是这一类型。 · 双界面卡IC： 又称组合卡 / 双端口 卡，是 同时兼备接触和非接触两种界面通信的多功能卡 ，将非接触 IC 卡的方便性和接触 IC 卡的安全性融为一体，使之成为一卡多用的极佳载体，代表着未来 IC 卡的主要发展方向，银行卡就是这一类型。 需要注意的是我们平时见到的某些门禁卡虽然也是通过感应使用，但不一定是IC卡，现在有相当一部分便宜的门禁使用的是磁卡和ID卡，ID卡使用RFID射频技术，但其频率一般较低，一般为125KHz,如爱特梅尔的T5577卡，不可写入用户数据，其记录内容仅限卡号只可由芯片厂一次性写入，开发商只可读出卡号加以利用，所以只用于身份识别，不能用于消费，其成本相对非接触式IC卡较低，一般使用字典攻击的方式就能复制。 智能卡按照工作频率分类： 区分ID卡和IC卡——读卡判断法 读卡判断法是判断卡智能卡类型最准确的方法，这需要可识别多类型卡的设备支持，例如手机NFC或者pn532开发板、ACR122U读卡器以及Proxmark3。使用手机NFC是最为便捷的方法，在支持全功能NFC的手机上下载MIFARE Classic Tools，给予权限后将卡片贴在NFC感应区根据提示读取标签后查看标签信息。下面是两种不同容量的IC卡的显示，如果RF技术这栏显示ISO/IEC 14443，说明就是典型的13.56MHz的非接触式IC卡，这也是生活中使用最多的类型。             ...
阅读全文

挖财 Kubernetes 容器化之路

发布于
其实年初的时候就有想过写这篇文章了，不过一拖就拖到了现在，再拖下去就有点说不过去了。 挖财内部对容器化项目的代号为 K2 （乔戈里峰），乔戈里峰是世界第二高峰，但攀登极富挑战，寓意就是面对挑战，勇攀高峰 ；）。项目从 2016 年 11 月到现在已经有三年的时间了，如今挖财内部测试环境早已全部 Docker 容器化，而线上环境也运行着重要的业务。经历从零到一的整个落地过程，回顾下来，这座高峰算是拿下了。再看 K8s 技术本身现在也是遍地开花，早已赢得容器编排的战争，剩下来就是各个企业的落地实践。倒是 Docker 公司最近的境遇，这个创建 Docker 的企业沦落如此，多少有点令人唏嘘，唯有 Respect。 1 时间线 看了一下项目提交的 Git 记录，第一次提交时间是 <2016-11-01 Tue> 。 2016 年 11 月初开启 2017 年 1 月底 V1.0 上线 2017 年 6 月底测试环境全面推开 2017 年 7 月线上机器学习环境线上试点 2017 年 10 月线上业务试点 2018 年 7 月 V2.0 版本 2018 年 9 月挖财云版本（整合运维监控、告警、日志和容器系统） 2018 年 12 月支持多集群管理 2019 年 6 月私有化分支版本上线 2 现状 2.1 测试环境 当前测试环境有一个 K8s 集群（K8s 1.11.x），空间（ namespace ）总数有 500+，应用数（ Deployment + StatefulSet ） 4400+，实例数（ Pod ） 4000+（因为测试环境大部分应用都只有 1 个，有些是处于暂停状态，即 0 个副本，因此实例数少于应用数）。 题外话，话说 K8s 升级的历程也相当血泪，早期的配置变更，向下的兼容性等等，关于升级相关可以参见之前的文章 Kubernetes 版本升级标注 2.2 线上环境 线上环境有三个集群，一个机器学习集群（K8s 1.7.x），一个私有云集群（K8s 1.13.x），有个主体业务集群（K8s 1.13.x），粗率统计了一下，空间数 50+，应用数 500+，实例数 1000+。 测试环境 + 线上环境总体运行有 5000+ ...
阅读全文

群晖上查找占用带宽最大的进程的一种解决方案（异常流量排查）

发布于
起因 有天，在群晖的 Web 界面，看到网络监控那里，上传速度竟然有 1-2M/s，漏油器上也看到群晖的上传很高，也就是说流量上传到了外网，卧槽，这到底是哪个进程吃我带宽的，找出来我非得杀掉不可。 可惜，群晖自带的 “资源监控” 无法查看进程对网络的占用。 过程 通常我们在 Linux 上是如何做的呢？ 1 Linux/Mac iftop 通过 iftop ，我们可以找出占用 上传/下载 最高的TCP连接 这里以 Debian 为例吧 安装 iftop 1 apt install iftop 运行 iftop （默认是监听 eth0） 1 iftop 可以通过 -i 来指定其他的网络接口，比如 1 iftop -P -i en8 参数说明 1 2 -i interface 监听指定网络接口 -P 显示主机名及其端口 netstat 上一步查到的 TCP 连接，包含 remote ip 和 端口。 使用 netstat ，可以定位到具体的进程。 1 netstat -pantu | grep [port] 在群晖上 因为群晖的系统，虽然是基于 debian，但是默认没有包管理器，无法通过 apt/yum 安装 iftop。不过群晖支持 docker。 群晖 - 套件中心 - docker - 安装 ssh 连接群晖 janten/iftop 这个镜像为我们提供了 iftop 命令 1 docker run -it --rm --net host janten/iftop -P -i eth0 如果本地没有没有这个镜像，会自动进行拉取，拉取镜像完成后，就可以看到 iftop 的运行界面 使用 netstat 定位进程 1 netstat -pantu | grep [port] 这样就能找到具体的进程了 参考： https://forum.synology.com/enu/viewtopic.php?t=143588 https://askubuntu.com/questions/2411/how-do-i-find-out-which-process-is-eating-up-my-bandwidth 来源：https://...
阅读全文

腾讯云提供的 Composer 国内镜像

发布于
切换镜像指向： composer config -g repos.packagist composer https://mirrors.cloud.tencent.com/composer/ Composer 安装简明教程： 一、下载： wget https://mirrors.cloud.tencent.com/composer/composer.phar 二、安装： mv composer.phar /usr/local/bin/composer  来源：https://mirrors.cloud.tencent.com/help/composer.html
阅读全文

项目管理标准模板

发布于
 之前写了一篇 《技术管理标准模板》 ，其中项目管理部分并没有具体深入，而这一技能不仅仅是对于技术Leader的要求，从我的经验看来，只要是程序员，具有项目管理能力都是如虎添翼的，即使你走的是专业路线。本文即基于自己的经验，从项目的启动和迭代阶段总结了敏捷项目管理的一些标准动作。 启动阶段 相关干系人沟通，同步项目背景、业务价值等 启动会议：召集相关干系人，明确业务相关信息，确定相关流程制度等 需求收集和分析-> 总体需求文档 ，概括性的功能与非功能需求列表 初步的产品规划-> 每一轮迭代的需求列表、发布时间 创建项目基础设施-> 可持续交付到测试环境的基础项目 ，包括各个端的代码库、到测试环境的流水线等。 迭代阶段 两周为一迭代，包括需求、设计、开发、测试、发布。关键点在于需求的拆分、优先级以及并行化。 1. 需求评审 对本轮迭代的需求尽心评审确认。 前置条件 ：产品经理对此轮迭代进行需求确认，产出需求条目，按 优先级 排列；需求需要拆的足够小，把大需求拆成一个个 能够独立开发测试发布 的小需求 2. 工作规划 根据本轮迭代需求做WBS任务分解 WBS工作项分解: 甘特图 里程碑结点: 表格或者里程碑图 风险管理：风险点预估、严重程度、可能性、应对措施 3. 设计/技术评审 分别对交互设计和技术设计进行评审 前置条件 ：设计师需要输出设计图；技术部分做概要设计和系统设计，随着每一轮迭代进行更新维护 4. 测试用例评审 由QA安排，会前需要提前将测试用例文档发给产品经理与研发，提前标注有疑问的用例。 5. 开发、测试过程的监控 持续交付：开发和迭代测试，需求开发完成后即测试并进行缺陷跟踪。 会议 每日站会：全员站会，了解整体状况，对暴露出的风险和问题作出集体决策。 项目周会：10人以上团队。解决整体计划层面、跨团队协同配合的问题。 项目周报 汇总项目总体状况，回答三个问题 项目的整体进展状态到底如何？ 风险可控吗？ 目标达成有没有问题？ 6. 版本全量测试 对所有已经开发完的功能进行交叉测试、全量测试、埋点测试、回归测试、第三方云测。 7. 验包发布 此迭代所有功能开发测试完成后，提交审核流程，各流程审核人验收通过后发布。 ...
阅读全文

如何防止Cloudflare CDN背后的图片被盗连(Hotlink Protection)？

发布于
「Hotlink Protection」(直接链接保护)是经营网站经常需要去注意的一块，但为什么我们会需要「Hotlink Protection」呢？身为图文并茂的网络文章作家，最担心得就是自己的文章被别人整篇连文带图地拷贝粘贴到其它地方了。此时如果图片有套用「Hotlink Protection」的话，就可以让被盗用的图片在其它网站上「不被正常显示」出来，如此一来，就能使其它误入盗文页面的访客可以知道该篇文章是篇被盗用的文章。不同的网站架构有不同的「Hotlink Protection」的设置方式，如果您的网站有打开Cloudflare的CDN服务的话，可以参考这篇文章，来实现「Hotlink Protection」的功能。 我的网站服务器是用Nginx或Apache，难道不能直接对它们做设置吗？ 很遗憾，只要我们有激活Cloudflare的CDN服务，就无法有效地通过自己的服务器程序来设置Hotlink Protection。这是因为网页浏览器在打开您网站的图片时，会去链接Cloudflare的CDN服务器，而非我们自己的服务器，所以就算我们有在自己的服务器上制作Hotlink Protection的功能，也根本不会被触发到。 既然有Cloudflare CDN，为什么还要Hotlink Protection？被盗连的图，其流量不是不会算在我们头上吗？ 的确，有了Cloudflare CDN之后，就算图片被盗连，它主要也还是会去吃Cloudflare CDN服务器的流量。但是，您真的愿意让您文章中的图片原封不动地在盗文网站上显示出来吗？所以还是设置一下Hotlink Protection吧！ Cloudflare内置的Hotlink Protection开关 Cloudflare的控制后台中，其实就有提供一个一键套用Hotlink Protection的开关，只要打开来，就可以让有激活CDN功能的网域拥有Hotlink Protection的功能。这个开关藏在Cloudflare控制后台的「Scrape Shield」分页中。 这个Hotlink Protection一旦打开，整个有打开Cloudflare CDN服务的网域(包含子网域)下的图片链接，就只能在这整个网域(包含子网域)下打开，否则的话会直接回传HTTP的403...
阅读全文

ShareX上传工具及公用上传空间配置导入

发布于
下载： https://getsharex.com/downloads/ 自定义上传配置： SM.MS图片上传 {   "Name": "SMMS",   "Version": "12.4.1",   "DestinationType": "ImageUploader",   "RequestMethod": "POST",   "RequestURL": "https://sm.ms/api/upload",   "Body": "MultipartFormData",   "Arguments": {     "ssl": "true",     "format": "json"   },   "FileFormName": "smfile",   "URL": "https://i.loli.net/$json:data.path$",   "DeletionURL": "$json:data.delete$" } Cat.box文件上传 {   "Version": "12.4.1",   "Name": "catbox",   "DestinationType": "ImageUploader, TextUploader, FileUploader",   "RequestMethod": "POST",   "RequestURL": "https://catbox.moe/user/api.php",   "Body": ...
阅读全文

使用 WireGuard 无缝接入内网

发布于
去年心血来潮想搞个 NAS 放在家里，奈何囊肿羞涩，最终只能捡垃圾捡了个蜗牛星际，又因为种种原因吃了近一年的灰。最近又比较心血来潮，想起来了在角落中已经蒙尘的蜗牛星际。 在某宝上买的机子已经由卖家预装了黑群晖，用起来也是完全的傻瓜式操作，免去了自己折腾各种软件浪费时间。目前仅仅作为一个  samba  文件服务器，在局域网中共享一些视频或者其他资源。 OK，开始正题。现在需要支持在外面远程控制 NAS 下载一些东西。目前有这么几种方案： 直接端口映射到内网的 NAS 这种方案需要你有一个公网 IP，在路由器中将需要外网访问的端口直接映射到内网的 NAS 对应的端口上即可，操作也比较简单，速度则取决于你的上行带宽。 使用  frp  之类的内网穿透工具 这种方案需要一个拥有公网 IP 的服务器，可以将内网的端口映射到这台服务器指定的端口，在外面直接访问服务器的端口即可。具体的配置方法也比较简单，在此不再赘述，这个方案的速度却决于你的这台服务器的带宽。 直接上 VPN 这种方案也需要一个拥有公网 IP 的服务器，相较上面两种方案，这个可能不是那么的方便。但有个好处就是可以透明地访问整个内网的任意主机，速度也是取决于这台服务器的带宽。 考虑到后面可能会折腾好多东西(虽然目前就这一个)，干脆将搞个 VPN 直接支持整个内网的访问吧，这样也不用一个端口一个端口地去映射了。但缺点也显而易见，访问内网就得连接 VPN，还是有那么一点点麻烦。 那么用哪个 VPN 方案呢？ OpenVPN PPTP L2TP&IPSec WireGuard 先说 OpenVPN，这个安全性是毋庸置疑的，可以说是非常安全。但缺点是配置繁琐，而且性能可能不大好。 PPTP 和 L2TP 在大部分平台中都有内置，配置起来非常方便，性能也挺好的，但不是很安全。 WireGuard 是一个极其迅速而且简单的 VPN，它的目标是更快，更简单，更小，并且比 IPSec 更好用(来自 WireGuard 官网)。目前 WireGuard 已经合并进入了 Linux 内核。 可以看一下性能对比(来自  WireGuard 官网 ) 话不多说，开始安装吧。网络拓扑大致如下。 其中： 1.1.1.1  为服务器的公网 IP 192.168.1.0/24 ...
阅读全文

简单的PHP搭建WebDAV(无需数据库)-phpEasyVCS

发布于
很久以前发现了小玩意phpEasyVCS，这是一个带有简单的版本控制系统（VCS）和WebDAV服务器的小工具，无需数据库，只需要服务器环境在php5.2以上即可，可以 去官网看看 。 有时候使用WebDAV需要搭建的东西比较多，很臃肿，比如NextCloud，Cloudreve，使用phpEasyVCS就很轻量化了。 phpEasyVCS项目主页： http://phpeasyvcs.sourceforge.net/ 不完全汉化版： https://github.com/cyqsd/phpEasyVCS-zh_CN 来源：https://www.cyqsd.cn/8087.html 这里还有另一个，有机会可以研究下 https://github.com/sabre-io/dav/tree/1.8
阅读全文