技术

目前单位实施了微信封锁,本文旨在记录绕过封锁的过程. 阶段一: 抓域名 使用了tcpdump抓取各个dns请求, 来获取需要代理的域名列表 sudo tcpdump -i any -n -s 0 port 53 但是抓到域名后加入daed的代理列表中还是无法登陆,怀疑是没抓全. 阶段二: 进程代理 既然抓不全, 那么就对整个微信的进程进行流量代理吧, 在daed中添加规则: pname(WeChatAppEx) -> proxy pname(wechat) -> proxy 这下登陆和发文字消息都正常了, 但是图片的发送和接收有极其严重的延迟, 应该是走了代理导致的. 阶段三: 仅代理登陆相关域名 经过几次实验, 发送单位对微信的封禁主要有两方面: 登陆相关的流量封禁 微信公众号图片相关的流量封禁 那么在搜索到相关域名列表之后,将对应的域名添加到daed规则中,其他的流量不作处理使用直连. domain(keyword:login.weixin,keyword:open.weixin,keyword:mp.weixin,keyword:qpic) -> proxy 重新加载规则, 一切正常.

Deployment and Debugging of Admission Webhook in Kubernetes cluster Intro Dynamic admission control 允许开发者添加自己的逻辑代码来对提交给API Server的对象进行修改和验证, 是非常强大的功能. 本文将部署一组demo admission webhook, 包括一个validating webhook 和一个 mutating webhook, 并介绍webhook的调试方法. 本文主要使用和参考了从0到1开发K8S_Webhook最佳实践, 并通过查阅官方文档对其中的一些不适应新版本k8s的内容进行了修正. 本文使用的集群环境为Kubernetes v1.25.16, 使用minikube创建. 我所在的机器为Arch Linux. 代码仓库为 admission-webhook-example中的v1部分. 在开始之前, 请确保集群的API Server开启了MutatingAdmissionWebhook和ValidatingAdmissionWebhook (一般默认情况下都开启了). Deployment 创建 service account 创建一个用于webhook的service account kubectl apply -f deployment/rbac.yaml 创建证书 API Server调用Webhook的过程是需要HTTPS通信的(其实集群内的通信几乎都是HTTPS), 因此需要为webhook创建证书来对webhook的service进行域名认证. 原博客使用的webhook-create-signed-cert.sh已经过时, 不再适用于1.25.16版本的集群了, 主要出问题的地方如下: # create server cert/key CSR and send to k8s API cat <<EOF | kubectl create -f - apiVersion: certificates.k8s.io/v1beta1 kind: CertificateSigningRequest metadata: name: ${csrName} spec: groups: - system:authenticated request: $(cat ${tmpdir}/server.csr | base64 | tr -d '\n') usages: - digital signature - key encipherment - server auth EOF 根据文档, 在1.22以及之后版本的kubernetes中, certificates.k8s.io/v1beta1 已经被抛弃不可用, 需要修改为certificates.k8s.io/v1, 并且需要在spec中增加signerName, signer的作用是签署证书. k8s内置的signerName 有以下几种: ...

eBPF 是一项革命性的技术, 起源于Linux 内核, 它可以在特权上下文中(如操作系统内核)运行沙盒程序. 它用于安全有效地扩展内核的功能, 而无需通过更改内核源代码或加载内核模块的方式来实现. 从历史上看,由于内核具有监督和控制整个系统的特权,操作系统一直是实现可观测性, 安全性和网络功能的理想场所. 对ebpf慕名许久, 正好趁寒假拜读一下Learning eBPF, 虽然是基于略过时的框架bcc, 但是在这个过程中学到的知识想必依旧可以迁移到别的框架去. Background and pre-knowledge bcc bcc的ebpf c代码不是真正的C, 而是bcc自己定义的一种和C类似的语言. limitation of ebpf program eBPF 程序必须被验证器校验通过后才能执行，且不能包含无法到达的指令； eBPF 程序不能随意调用内核函数，只能调用在 API 中定义的辅助函数； eBPF 程序栈空间最多只有 512 字节，想要更大的存储，就必须要借助映射存储； 在内核 5.2 之前，eBPF 字节码最多只支持 4096 条指令，而 5.2 内核把这个限制提高到了 100 万条； 由于内核的快速变化，在不同版本内核中运行时，需要访问内核数据结构的 eBPF 程序很可能需要调整源码，并重新编译。 tracepoint and kprobe tracepoint其实就是在Linux内核的一些关键函数中埋下的hook点,这样在tracing的时候,我们就可以在这些固定的点上挂载调试的函数,然后查看内核的信息. Tracepoint是在内核中固定的hook点, 并不是在所有的函数中都有tracepoint. 这时候, 我们就需要用到kprobe了. kprobe可以动态地在所有的内核函数(除了inline函数)上挂载probe函数 eBPF virtual machine The ebpf virtual machine uses 10 general-purpose registers (0-9), and additional register 10 which was used as a stack frame pointer (can only be read but not written). As a BPF program is executed, values get stored in these registers to keep track of state. ...

2024年7月更新: 经过了半年的时候, 遇到的问题包括但不限于 1) 微信卡顿 2) 银行类app无法使用 3) system UI经常崩溃 4) 快充消失. 出于可用性考虑, 已经转回coloros 2024年2月更新: Lsposed连同一系列root隐藏模块已经归档无法使用, 为了方便日常使用, 建议卸载magisk, 刷机的时代已经过去了. 不知道从什么时候开始, 往日被冠以高可玩性高自由度的安卓系统逐渐变得封闭, 一步步沦为资本市场的玩物和工具. MIUI也好, ColorOS也罢, 用户总能在使用系统的过程中发现一些去也去不掉的应用和小程序, 看到一些不想看也得看的广告, 而起初, 有些人尽管对此有所不满, 但基本都选择容忍的态度, 但这几年国内的趋势越来越不对劲: 先是某APP在全社会的宣传下或软性或硬性地被安装在了相当大一部分人的手机中监控个人信息(当然, 我理解打击诈骗行为, 保护平民百姓的钱包远比软件自由重要得多), 又是拼多多被爆出利用安卓手机的0day漏洞在所有用户的手机上进行多种恶意行为, 一直到最近, 一则某信部的发文通知将这种 我的手机不归我管 的焦虑感推向了新的高潮. 就目前来看, 这则通知的社会反响并不强烈, 不出意外应该可以顺利推行. 之后最直观的效果就是所有使用国内安卓系统的用户都只能安装指定的app, 不再具备安装推特等软件的能力, 这无异于干掉了安卓最大的特点, 使其沦落为全方位落后于苹果的手机系统. 作为一个经历过安卓app爆发式增长年代的玩家, 我很好奇现在新接触到手机的用户对自己掌中的设备是一个什么样的印象, 是一个拥有无限可能的工具? 还是一个用低质量内容, 广告和充满限制的操作系统来无限吸收注意力, 获取个人隐私并变相管理个人精神世界的资本和政府工具? 万幸的是, 安卓的开源属性为它保留下了一些自由的火种, 那边是第三方rom. 本文主要记录自己安装 lineageos, magisk, Lsposed 以及一些有用软件的过程. 购买机器 查看lineageos支持的设备列表, 出于对一加的偏好和对骁龙888发热的不放心, 我选择以一加8pro作为自己的新设备. 在咸鱼上逛了很久, 筛掉一大批机器贩子和低质量卖家后, 我看中了一位宝妈的二手机并下单. 机器到手后我非常满意, 因为成色实在是很好, 连维修店里给我手机换电池的工程师也赞叹保养得不错, 这1700虽然有点贵, 但还是值得的. ...

现在回头看几年前自己写的插件配置文章, 看着那些曾经用过但后来都纷纷被替代的插件, 我会莫名怀念那段因计算机和终端而兴奋不已的自己. ...

eye candy也是一种生产力! ...

“一个黑暗的形体，像一个匍匐的人一般大小，但是长着长长的蜘蛛一样的肢体……黑暗中的形体以惊人的速度向他奔来。当它靠近时，他看到那蹲坐着的乌黑身体上有一张脸，在身体底部那些多节的腿之间。那张面孔用一种怀疑和质问的可憎表情凝视着他；而当这个大胆的猎人与那小而狡诈的，四周全是毛发的眼睛对视时，恐惧流遍了他的每一根血管。” ...

这篇文章是对我从ext4文件系统转换到btrfs过程中的一些操作记录, 便于日后参考. 前置准备 制作arch linux 启动盘, 版本越新越好. 备份重要文件 我个人在转换前会把大文件(例如虚拟机文件)转移到移动硬盘里, 让转换过程更快一些 转换 进入LiveCD 系统, 对主分区进行转换 btrfs-convert /dev/nvme0n1p2 等待一段时间之后, 显示conversion complete就表示没有问题, 接下来还需要做三件事情才可以进入系统 修改fstab 首先将转换成功后的分区挂载到/mnt下 mount /dev/nvme0n1p2 /mnt 使用lsblk -f命令查看分区的UUID号, 拍个照片记一下 编辑/mnt/etc/fstab, 修改这个分区类型为btrfs, 将最后的两列数字都改成0, 保存退出 重建内存盘 先挂载, 然后进入chroot环境 mount -t proc none /mnt/proc mount -t sysfs none /mnt/sys mount -o bind /dev /mnt/dev chroot /mnt bash 然后执行下列命令来为所有内核重建内存盘 mkinitcpio -P 最后重建grub引导, 按照道理应该要把引导分区/dev/nvme0n1p1挂载到/mnt/boot之后才可以, 但是我记得自己执行的时候没有挂载? grub-mkconfig -o /boot/grub/grub.cfg 重建grub引导 在上一步的chroot环境中, 执行下列命令, 记得把引导分区挂载到/mnt/boot grub-mkconfig -o /boot/grub/grub.cfg 大功告成, 退出chroot, 重启电脑就可以进入你的系统了, 唯一的不同是它已经是btrfs了. ...

对于我这种英语不好的人来说, 翻译是离不开的工具, 但是众所周知, Linux的日用软件生态相比较windows和macos来说相差甚远, 别说目前正处于发展阶段的wayland, 就连成熟透了的x11下也没有拿得出手的翻译软件. 作为一个英语不好的Linux爱好者, 缺少翻译软件必定会对日常的使用造成一定的影响, 于是开始思考怎么样解决这个问题. 我的第一个思路, 也就是见到最多的划词翻译软件的样子, 选中文本之后, 在被选中的文本周围的某块区域中绘制一个窗口, 在其中展示翻译结果. 但是问题来了, 要如何绘制这样的窗口呢? 在wayland中, 窗口的位置交给了compositor进行管理, 这种能够自己决定显示位置的能力, 据我所知, 在wayland下仅有fcitx5做到了, 于是我翻阅了一下它的源代码, 并没有看懂, 但是应该没有借助于Qt和GTK来绘制, 而是使用wayland-client. 对我这样一个连Qt GTK开发经历都没有的人来说, 理解wayland编程开发中的那些概念实在有些困难. 于是紧接着又有一个问题出现了: 能否绕开wayland? 就我思考这个问题的时候, linux QQ给我发了一个系统通知, 我的电脑上的系统通知服务原先只是为了让linux qq不崩溃才安装的, 然而这个时候, 它给了我一个新的解决方案: 使用系统通知来呈现翻译结果. 于是搜了一下如何发送系统通知, 发现竟然意外的简单. notify-send "title" "content" 那么接下来的问题: 如何获取选中文本的内容? 这个问题, 我原本计划通过阅读wl-clipboard来学习的, 但是我想先尽快用上翻译, 把优化放到以后再说, 于是决定直接使用wl-clipboard来获取选中文本内容, 那么至此思路理清, 大致如下: 使用剪切板获取到选中文本的内容, 可以使用wl-paste -p来获取 获取文本之后, 将换行符替换成空格 (这块可以有更好的处理方法, 简单起见就全换掉了), 使用sed 文本处理完毕后, 将文本输入进translate.js中进行翻译, (这块可以使用别的现成工具) 翻译结果出来之后, 将结果以系统通知的形式呈现出来, 当然, 系统通知必须要有, 可以是dunst, mako, swaync, 以及kde或者gnome的桌面消息通知都可以. 发送翻译结果使用命令notify-send "标题" "翻译内容" 以我的划词翻译为案例, 我在~/.config/sway/config中加入了这么一行作为划词翻译触发按键 ...

不管火狐的市场份额多么拉胯, 对于Linux wayland用户来说, 目前体验最好的浏览器依旧是Firefox. 本篇记录我的FIrefox配置, 包括浏览器设置和插件设置. 外观 titlebar 为了让标题栏中的内容可以更加紧凑, 一个好办法是进入about:config, 设置browser.compactmode.show为true, 然后进入custom toolbar, 设置Density为Compact 对于wm用户, 一个推荐的设置是勾选上上图中的Title Bar选项, 为什么要这么设置呢, 因为这样子做, 那些按钮(最大最小化, 关闭窗口)就会出现到title bar中, 然后title bar会被wm吃掉, 这样就可以给火狐的标题栏留出更多的空间 ps: 我用的主题名字叫做tokyonight Firefox-UI-Fix 使用Firefox-UI-Fix来个性化Firefox的界面 Addon Vimium 该插件将vim的操作方式带入到浏览器中, 能够让用户更少依赖鼠标. 默认情况下, firefox出于安全考虑会在一些页面中禁用Addon, 为了让该插件能够在更多的页面上使用, 需要在about:config中进行以下设置 extensions.webextensions.restrictedDomains清空掉 privacy.resistFingerprinting.block_mozAddonManager设置为true,来让插件在所有页面上都可以使用 以下是我的Vimium键位设置. # Insert your preferred key mappings here. unmapAll map H previousTab map J previousTab map L nextTab map K nextTab map <c-j> scrollPageDown map <c-k> scrollPageUp map <c-o> goBack map <c-i> goForward map o Vomnibar.activateInNewTab map b Vomnibar.activateBookmarksInNewTab map t Vomnibar.activateTabSelection map M LinkHints.activateModeToOpenInNewTab map m LinkHints.activateModeToOpenInNewForegroundTab map gi focusInput map gg scrollToTop map G scrollToBottom map j scrollDown map k scrollUp map h scrollLeft map l scrollRight map x removeTab map X restoreTab map ? showHelp map yy copyCurrentUrl map p openCopiedUrlInNewTab Tip: 如果在某次更新之后发现插件不可用了, 那么可以考虑临时切换到另一个类似的插件 Vimium C , 把相同的键位复制进去就行啦. ...

不知不觉使用sway已经整整一年了，于是来谈一谈自己这一年的使用感受，顺便回顾了一下过去。 起因 2019年，在一次编程作业的时候，同专业的另一个老哥向我展示了vim的代码h补全，我立刻被这种简陋但是扩展性极强的代码编辑器吸引了，于是当时还是个刚转入计算机专业的小白就开始哼哧哼哧地学习vim的配置和插件的安装。当然，这些都发生在我的Kali Linux虚拟机中。 那个时候我正接触CTF，很多时候都要开着虚拟机，于是有一天动起了把电脑系统直接装成linux的想法。因为自己的第一台笔记本是暗夜精灵2，游戏本装Linux，第一个要考虑的就是兼容性和稳定性，在权衡各个发行版的优势和流行程度后，我选择了ubuntu18.04。笔记本重装完毕后除了风扇转个不停竟然一切运行正常，这让我实在有些惊喜，而风扇问题是英伟达独显导致的，在ubuntu上，只需要一条sudo ubuntu-drivers autoinstall就完美解决了。当时的自己很开心，仿佛打开了一道新世界的大门。 后来，我去吉林参加了第一次线下赛，ubuntu没有掉链子，帮我拿了一个一血，我很满意。直到一次上课，手贱执行了apt upgrade，升级完电脑竟然无法开机了，一整个无语，而当时临近期末，我已经没有时间再去折腾系统了，于是紧急安装了windows应付期末复习，顺便下单了一台对Linux更加友好的笔记本Thinkpad T480。 期末考试结束后，我听说了Arch Linux 的大名，但是出于畏难情绪，我选择将ubuntu18.04安装在我的thinkpad t480上，然后去参加xman的夏令营。在夏令营期间，我的电脑在连接wifi一段时间后就再也连接不上了，第一次我选择了重装，但是第二次还是同样的问题，我只好绝望地回到windows10，事后分析的时候，我觉得应该是驱动的问题，thinkpad t480是2018年下半年发布的，ubuntu18.04的驱动可能确实没覆盖到它的网卡。 之后的好几个月里，我都乖乖用着windows10和WSL2，实习的时候全程在虚拟机里面写代码。等到实习结束、保研也结束的时候，我又开始了新一轮的折腾。 2020年下半年，我将自己的主力电脑全面迁移到了Manjaro Linux下，那个时候qv2ray还很活跃，我的科学上网也很依赖它，但是有好几次在更新的时候发生了Manjaro特有的问题：软件的版本更新上来了，但是软件的依赖没有更新上来，这种问题也影响了trilium等软件，虽然不能怪manjaro，但是我还是愤而转向了Arch Linux，一直到今天我也还在用。 转到Arch Linux之后，我基本上不再改变自己的发行版了，只是会在图形界面折腾一些。2020年-2021年上半年我使用的都是KDE，好看是真好看，但是Bug也是真的致命，这其中我亲身经历过的至少三次重复出现在不同电脑（thinkpad T480出现过，thinkbook 14p 出现过）的bug就是盒盖睡眠失败，我不知道是谁引起的，是plasma还是conky还是别的什么组件，我不知道，我在日志里也查不到。别看这个问题好像没什么，但是作为一个笔记本用户，盒盖后放进包里是一个非常自然的行为，回到宿舍没有第一时间拿出电脑而是休息一会也是很正常的行为，但是休息完后发现自己的电脑在包里变成了一个铁板烧就不是一个正常的现象了。嘴硬的人当然会说thinkpad不是有指示灯吗？你看指示灯判断是否睡眠成功不就行了？且不说我后来的电脑thinkbook 14p是没有指示灯的，单就系统质量而言，一个系统每次使用的时候都需要用户小心翼翼盯着指示灯看，是否已经说明了这是一个糟糕的系统了？为什么换成thinkbook？就是因为这个bug把我的thinkpad的主板烧坏了！我曾以为这是thinkpad独有的问题，可是当thinkbook也发生同样问题的时候我对KDE彻底失望了，是的，这是一个很漂亮的桌面环境，定制性强又有很多特效，可是这一切都建立在一些不稳定的bug上的时候，这些特效会更多扮演起bug的导火索角色。 经历过KDE的bug后，我对复杂的桌面环境产生了恐惧，他们就像是一枚不定时炸弹。在这个前提背景下，我接触并开始使用SwayWM，一直到今天，我也还在使用，而那个致命Bug，已经离我远去。 体验 得益于Arch Linux庞大的用户群，Arch 的软件包生态在一众发行版中可以说是称王称霸了，我举一个例子，你能想象在Linux的软件仓库中会出现deepin-wine魔改后的腾讯系软件吗？ 每次看到其他发行版用户手动下载deb然后安装的时候，我都会产生一种他们是不是在用windows的错觉，并不是看不起别的发行版，只是各有分工和侧重点，比如Arch的定位是桌面端用户，而很多别的发行版的定位是服务器，我不会用别的发行版当作我的桌面系统，就像我不会把Arch装在服务器上一样。用统一的包管理器管理软件包肯定是有好处的，能够大大减轻用户的心智负担。 至于网络上提到的Arch Linux不稳定、容易滚挂的问题，不好意思，我用了两年Arch了，每天都执行yay -Syyu，从来没有出现滚挂的问题，相反，我目前所遇到的半数Linux相关问题，都是因为系统软件或者依赖库过于老旧而导致的，更新后就可以解决。Linux不是Windows，如果你不想要更新，那么有两种选择，第一种，锁定自己的软件版本，然后在每次安装新软件的时候单独解决依赖问题；第二种，回去用windows。 说完了Arch Linux，再来说说Sway，这是一个简单的wayland窗口管理器，为什么用wayland，因为我不希望自己的图形界面建立在一个老旧而难以维护的基础设施之上，那给我的感觉就好像我在使用另一个plasma。诚然，wayland还有很长的一段路要走，很多桌面软件都不得不借助xwayland才能在其上运行，经过实际使用，除了在4k屏幕上xwayland有问题之外，其他情况下还是可以完美工作的。当然，部分软件是有问题的，比如腾讯会议的桌面共享功能，但是也已经有了曲线救国的办法，所以现在wayland的生态已经比之前要好一些了，当我看到linux qq内测群里有人提出wayland下的问题以及要求兼容wayland的时候，我就相信未来还会更好。 Sway是一个窗口管理器，开发者做的事情是在wayland下复刻一个i3wm出来。窗口管理器的好处是我现在更多依赖键盘而不是鼠标了，可以减少对视觉聚焦于鼠标这种行为的依赖，转而更多依赖自己的触觉，另外，更少的特效和更简洁的设计不仅让我的系统大大增强了稳定性（据一位用KDE的同学说，直到今天，用KDE只要一周不关机就必定会崩溃），还让我自己更加专注于手头的工作（平铺式窗口管理器的统一好处）。不好的地方当然也有不少，比如初次接触的时候要花很多时间去配置和适应，比如每次修改操作键位的时候都需要一定时间去重新适应，比如fcitx5在某些软件下面无法工作或者是有缺陷（这不是fcitx5的锅），比如它让我认识到自己是一个很笨蛋的人，使用了一年了，让我时不时就发现自己的操作习惯可以有优化空间，比如： 在按win+数字键的时候，用大拇指去按是很扭曲的姿势，**一个更加自然的姿势是用左手的掌心左下（手背视角）的部分去压win键，然后用手指去按数字键。**如果要按ctrl+win，就用同样的部位压住两个键，这个难度会大一些，大概确实还可以优化的。 调整窗口大小的时候，进入resize模式然后用键盘去按是很低效的行为，相反，这种时候依赖鼠标不是什么坏事，通过把鼠标悬停在窗口上然后按住右键进行拖拽就可以实现快速的窗口大小调整。 scratchpad中更适合使用tab模式。 有的时候在两个workspace之间切换会很频繁，这个时候更适合用workspace back_and_forth而不是一直执着于用数字键去切换，或者使用鼠标的滚轮来切换，这也是一个不错的主意。 除此之外还有一个小的优点，在sway下可以给不同键盘换上不同的布局，这点对我而言是刚需，但是在xorg下面，这种操作往往只能将同一个布局应用于所有的键盘，一旦布局出现了问题导致键盘不可用，那么所有的键盘都会变得不可用。 最后，我和大部分的geek用户不一样，我比较笨，只是一个普通用户，我做不到也不想去和他们一样视鼠标如洪水猛兽，相反，sway下我还是会频繁使用鼠标，对我来说用鼠标去交互两个窗口的位置依旧是比用键盘更加高效的操作。所以我想说的是，追求属于自己的实用性，你可以去参考别人的建议，但是最终还是要找到属于你自己的习惯。 对于我个人来说， 我也完全不排除在plasma的bug修复后回到plasma的可能性，毕竟老牌桌面。 列出我使用的软件： 桌面环境 SwayWM（窗口管理） waybar（信息展示栏） 终端 alacritty 浏览器 firefox-developer-edition （主力） chrome 输入法 fcitx5 代码编辑 Neovim（主力） Vscode（副手） Jetbrains 做笔记 Neovim-qt zotero 文件浏览器 ranger dolphin 看论文 zotero okular 游戏 steam（泰拉瑞亚、黑暗之魂……） waydroid（明日方舟） HMCL（minecraft） 工具替代 exa 替代 ls zoxide 替代 cd scp 替代 cp Trouble Shooting 关机的时候出现 a stoping job is running for xxx hangout 修改/etc/systemd/system.conf ...

在消磨三年时光之后，我终于明白这个编辑器还远远称不上稳定，在道路的尽头之前，我能做的其实只有观望。 ...

在争取自由这个宏大命题下, 上网自由可以算得上一件"小事", 然而越是小事, 越与我们的日常息息相关. ...

环境问题, 一生之敌. ...

采用的是版本较新的idea2020.2, 使用的操作系统为MANJARO LINUX, 其中的过程挺迷迷糊糊的就水一篇来记录一下. File --> New --> Project --> Java --> Nextnext 新建一个项目 右键Project --> open module setting --> 点击+号 --> 导入tomcat8的Servlet-api.jar 右键项目 --> Add Frameworks Support --> 选中web application 选中后会多出来几个东西, 如下图, 多了WEB-INF目录和index.jsp Web-INF里面有只有一个web.xml, 什么是WEB-INF? 根据百度百科的介绍 WEB-INF是Java的WEB应用的安全目录。所谓安全就是客户端无法访问，只有服务端可以访问的目录。如果想在页面中直接访问其中的文件，必须通过web.xml文件对要访问的文件进行相应映射才能访问。 WEB-INF文件夹下除了web.xml外，还存一个classes文件夹，用以放置 *.class文件，这些 *.class文件是网站设计人员编写的类库，实现了jsp页面前台美工与后台服务的分离，使得网站的维护非常方便。web.xml文件为网站部署描述XML文件，对网站的部署非常重要。 Web-Inf文件夹中除了有classes文件夹和一个web.xml文件外、还有lib文件夹（用于存放需要的jar包）（用于配置，比如说用来配置过滤器等。） /WEB-INF/src/ 源码目录，按照包名结构放置各个java文件。 /WEB-INF/database.properties 数据库配置文件 /WEB-INF/tags/ 存放了自定义标签文件，该目录并不一定为 tags，可以根据自己的喜好和习惯为自己的标签文件库命名，当使用自定义的标签文件库名称时，在使用标签文件时就必须声明正确的标签文件库路径。例如：当自定义标签文件库名称为 simpleTags 时，在使用 simpleTags 目录下的标签文件时，就必须在 jsp 文件头声明为：<%@ taglibprefix=“tags” tagdir="/WEB-INF /simpleTags" % >。 /WEB-INF/jsp/ jsp 1.2 以下版本的文件存放位置。改目录没有特定的声明，同样，可以根据自己的喜好与习惯来命名。此目录主要存放的是 jsp 1.2 以下版本的文件，为区分 jsp 2.0 文件，通常使用 jsp 命名，当然你也可以命名为 jspOldEdition 。 ...

来看看互联网世界的基石 通信过程的简化模型 第一阶段: 服务器向CA发起证书签名请求 服务器组织生成一个私钥 openssl genrsa -out target.key 1024 从私钥文件中得到公钥, 这个公钥会被用于给CA签名 openssl rsa -in target.key -pubout -out target_pub.key 使用私钥生成一个证书签名请求, 在生成过程中需要填写证书申请人的一些信息 openssl req -new -key target.key -out target.csr 生成完成后, 可以运行下面命令看看这个证书签名请求文件里都有什么 openssl req -text -in target.csr -verify 例如: 可以看到公钥也在里面. 接下来把证书签名请求文件提交给CA, CA审核通过后对该文件进行签名 openssl x509 -in target.csr -out target.crt -req -signkey ca.key -days 365 target.crt就是签名成功后的证书. 对于常见的自签名场景来说, ca.key就是target.key, 用自己的密钥去签名自己的证书请求, 自签名请求命令就是 openssl x509 -in target.csr -out target.crt -req -signkey target.key -days 365 然后CA将target.crt以及由Root CA签名的CA证书一同返回给申请人. 如下图所示: ...

基础修改 修改 _config.yml，写上网站的标题 title: subtitle: description: 选择主题 theme: next hexo 插件 字数统计和阅读时长统计 https://github.com/theme-next/hexo-symbols-count-time 在 _config.yml 中添加 symbols_count_time: symbols: true time: true total_symbols: true total_time: true exclude_codeblock: false awl: 4 wpm: 275 suffix: "mins." 在Next主题中的 _config.yml中添加 symbols_count_time: separated_meta: true item_text_post: true item_text_total: true git 部署 在你的github账户上创建仓库yourusername.github.io，必须是用户名开头命名，否则github page不会生效。 首先生成个人公私钥 cd ssh-keygen -t rsa -C "your_email@example.com" 然后将公钥粘贴进github账户的个人设置里面 ssh -T git@github.com git config --global user.name "username" git config --global user.email "email" 在博客目录下下载： npm install hexo-deployer-git --save 修改网站根目录下的_config.yml文件 deploy: - type: git#注意git的前面要加空格否则不生效 repo: https://github.com/example/example.github.io.git branch: master 保存退出后执行命令： ...

ch3n9w 的 vim 本篇文章中的插件均已过时, 不推荐使用 《程序员修炼之道》中有一句话:最好是精通一种编辑器，并将其用于所有编辑任务。如果不坚持使用一种编辑器，可能会面临现代的巴别特大混乱。 ，实质今日，深以为然。而自从接触vim之后我一直都保持着有空折腾折腾的好习惯，它的简洁和高度自由让人着迷，围绕着vim衍生出的插件数不胜数。奈何插件繁多的同时也意味着选择的困难和配置的繁琐。为了准备以后可能出现的突发情况比如配置丢失或者重新安装，特在此以实现特定功能为主题，记录自己配置vim的过程。 ...