Linux系统监视器Conky配置
安装
1 |
|
传感器数据样例
1 | acpitz-virtual-0- |
:TODO conky 默认运行效果截图
conky默认以一个弹窗的形式运行,并使用位于/etc/conky/conky.conf的基础配置文件
集成到桌面
1 | cp /etc/conky/conky.conf /home/$USER/.conkyrc # 复制默认配置文件 |
OpenSSL生成自签名证书
名词解释
CA(Certificate Authority)
证书授权机构, 负责发放和管理数字证书的权威机构,有自己的证书,可以拿自己的证书给别人签名。
RootCA
根证书,权威机构持有的证书,安装根证书意味着对这个证书机构的信任,所有其他证书都由这个根证书来签发。只需要把这个根证书添加到受信任的根证书,所有其他由此根证书签发的证书都会被自动信任。
SubCA
中间证书机构,由权威机构签发的证书,
CSR(Certificate Signing Request)
证书请求文件,证书申请者在申请数字证书时生成私钥的同时也生成证书请求文件,证书申请者只要把CSR文件提交给证书颁发机构后,证书颁发机构使用其根证书给私钥签名就生成了证书公钥文件,也就是颁发给用户的证书。
常用后缀名
格式 | 说明 |
---|---|
.crt,.cer | 证书文件 |
.key | 私钥文件 |
.csr | 证书签名请求文件 |
.pem | base64编码证书文件,可以单独放证书或密钥,也可以同时放两个。Apache 和 NGINX 服务器偏向于使用这种编码格式,也是 openssl 默认采用的信息存放方式。 |
.der | 二进制证书文件,可包含所有私钥、公钥和证书,是大多数浏览器的缺省格式,常见于 Windows 系统中的证书格式。 |
证书链
在证书链中,通常分为三级结构,分别是根证书、中间证书、服务器证书。正确的证书链顺序中服务器证书处在最底端,里面包含服务器域名域名服务器公钥和签名值等。服务器证书的上一级是中间证书,可以由多张证书组合在一起,最上级是根证书。对服务器身份进行校验时,需要验证一整个证书链。每一级证书都有签名值,根证书使用自己的根CA公钥验证自己的签名,也用来验证中间证书的签名值,中间证书的公钥用来验证下一级证书的签名值。
生成根证书
生成根私钥
1 | # 生成CA认证机构的证书密钥 |
第一次生成的私钥,是带有 passphrase 的。这带来一个副作用,就是需要在使用过程中输入密码。这对于一些特定场景来说会带来一些问题。比如:Apache 的自动启动过程,或者一些工具,甚至有没有提供输入 passphrase 的机会。其实是可以将 3DES 的加密从秘钥中移除的,这样,使用的过程中就不再需要输入 passphrase。这也带来另一个问题,如果其他人获取到了未加密的私钥,对应的证书也需要被吊销,以避免带来危害。
生成自签名的根证书请求
-subj 参考证书请求文件参数说明
1 | # 生成根证书自签名请求 |
生成自签名根证书
1 | # 参数说明 |
生成中间证书
如果不是复杂场景可以跳过此步骤,使用根证书直接生成客户端证书
使用root-ca签发sub-ca的证书签名请求,中间证书指的是可以允许继续生成下级证书,否则的话默认生成终端证书,即使可以用中间证书生成下一级客户端和服务端等用户证书,最终验证的无法通过。
生成中间证书私钥
1 | # 生成私钥,方式1(参考根证书私钥) |
生成中间证书请求
-subj参考证书请求文件参数说明
1 | # 生成中间证书自签名请求 |
生成中间证书
1 | # 生成证书 |
验证中间证书
1 | openssl verify -CAfile root-ca.crt mid-ca.crt |
生成终端证书
假设服务器域名为example.io
生成终端证书私钥
1 | # 生成私钥,方式1(参考根证书私钥) |
生成终端证书请求
-subj 参考证书请求文件参数说明
1 | # 生成终端证书自签名请求 |
生成终端证书
1 | # 生成证书,如果不使用中间证书可把mid-ca.crt替换为root-ca.crt |
v3.ext参考X.509扩展配置
验证终端证书
1 | openssl verify -CAfile root-ca.crt example.io.crt |
查看证书信息
1 | # 查看公钥的内容,如果为.PEM ,则会以 base 64 明文方式显示 |
证书有效性验证
可以利用openssl
的s_server
命令来模拟一个服务端,要使用到证书管理员生成的证书client.crt
,以及申请人在创建csr
时生成的 client.key
1 | openssl s_server -cert example.io.crt -key example.io.key -debug -HTTP -accept 443 |
然后浏览器访问 https://ip地址
来查看证书是否有效(要先导入根证书到
信任的根证书颁发机构)。
吊销证书
一般由于用户私钥泄露等情况才需要吊销一个未过期的证书。
假设需要被吊销的证书文件为 cert.pem
1 | # 生成证书吊销列表文件 |
附件
证书请求文件参数说明
参数 | 说明 | |
---|---|---|
/C | Country Name (2 letter code) | 两字母的国家代码,例如 “CN”。 |
/ST | State or Province Name | 州或省的全名。 |
/L | Locality Name (e.g., city) | 城市或地区的全名。 |
/O | Organization Name (e.g., company) | 公司或组织的全名。 |
/OU | Organizational Unit Name (e.g., section) | 部门或单位的全名。 |
/CN | Common Name (e.g., your name or your server’s hostname) | 通常是你的服务器的主机名。 |
emailAddress | Email Address | 电子邮件地址,用于证书联系。 |
这些信息将用于填写证书请求文件。在实际情况中,一些字段可能不是必需的,具体取决于你的使用场景和证书颁发机构(CA)的要求。通常,“Common Name” 是最重要的字段,应该设置为与你的服务器域名或主机名相匹配的值。其他字段的值可以根据实际情况填写。
示例
1 | /C=CN/ST=Tianjin/L=Tianjin/O=Example/OU=DEV/CN=example.com/emailAddress=dev@example.com |
X.509扩展配置
v3.ext
1 | authorityKeyIdentifier=keyid,issuer |
extendedKeyUsage 可以指定证书目的,即用途,一般有
serverAuth 保证远程计算机的身份
clientAuth 向远程计算机证明你的身份
codeSigning 确保软件来自软件发布者,保护软件在发行后不被更改
emailProtection 保护电子邮件消息
timeStamping 允许用当前时间签名数据,如果不指定,则默认为 所有应用程序策略
SubjectAlternativeName
DNS.1用来确保网站的域名必须时*.example.com
,
IP.1用来确保网站的IP地址,如果证书里面的内容和实际对应不上,浏览器就会报错。
参考
构建安全的X.509三级证书体系:OpenSSL实战指南-百度开发者中心 (baidu.com)
KVM常用命令
添加删除
1 | # 查看虚拟机 |
开关机
1 |
|
备份克隆
1 |
|
快照
1 | # 创建快照 |
Hexo 增加站内文章链接
使用markdown的链接语法
使用markdown的语法指定url创建站内链接,有绝对地址和相对地址两种方式,绝对地址与相对地址的区别在于是否以/
开头:
使用绝对地址
代码如下:
1 | # 格式 [标题](文章地址) |
示例中,
Hexo-增加站内文章链接
使用的是文章对应的md文件名,使用hexo n创建post时,空格会转换为中划线-。/Hexo
是为了文章管理方便在_posts
目录下增加的子目录,Hexo-增加站内文章链接.md
位于_posts/Hexo/
目录下。
结果如下:
Hexo对绝对地址和相对地址的处理方式是不一样的。对于绝对地址/Hexo/Hexo-博客配置
,生成的目标url不会变化。
使用相对地址
代码如下:
1 | [Hexo 增加站内文章链接](Hexo/Hexo-增加站内文章链接) |
对于相对地址Hexo/Hexo-增加站内文章链接
,生成的目标URL会叠加文章的的URL,结果是/Hexo/Hexo/Hexo-增加站内文章链接
,这显然不是期望的结果。但是如果是文章内的锚点链接,使用这种方式非常合适。
代码如下:
1 | # 格式 [标题](#文章内要跳转的标题) |
结果如下:
跳转文章内测试锚点
生成的URL可以正确的跳转到文章内的锚点。注意,标题中的空格用-
代替。
使用post_link标签
由于Hexo文章的URL规则是可以配置的,在_config.yml
中可以配置URL自动添加日期、目录等信息。如果使用markdown语法的链接规则多有不便,一方面需要知道目标URL,一方面如果规则修改或者站点迁移,对应的内容需要修改。
好在Hexo提供了post_link
标签解决这个问题。
代码如下:
1 | # 格式 {% post_link 以_post下文件路径 '显示链接名'%} |
示例中,
Hexo-博客配置
使用的是文章对应的md文件名,使用hexo n创建post时,空格会转换为中划线-。Hexo
是为了文章管理方便在_posts
目录下增加的子目录,Hexo-博客配置.md
位于_posts/Hexo
目录下。
结果如下:
Hexo 博客配置这样的链接会自动适配_config.yml
中的文章URL规则。
小结
对比markdown语法和post_link
标签,推荐在文章链接到站内文章时优先使用post_link
,链接到文章内锚点时优先使用markdown语法。
测试文章内跳转锚点
文章内锚点跳转示例
Awesome桌面
.NET 6.0使用Identity实现JWT身份认证与授权
使用 Visual Studio 2022 创建 ASP.NET Core Web API
可以从 Visual Studio 2022 中选择 ASP.NET Core Web API 或 ASP.NET Core gRPC模板
安装依赖库,可以使用NuGet安装或使用DotNet CLI
1 | dotnet add package Microsoft.EntityFrameworkCore.SqlServer --version 6.0.33 |
在appsettings.json
中添加配置
1 | { |
准备Model
1 | using Microsoft.AspNetCore.Identity; |
Fluent API重定义数据库表名,字段
1 | using Sample.Identity.Model; |
新建DataContext
1 | using Microsoft.AspNetCore.Identity.EntityFrameworkCore; |
添加ViewModel
1 | using System.ComponentModel.DataAnnotations; |
添加Controller
1 | using Sample.Identity.ViewModels; |
修改Program中添加
1 | using Sample.Identity; |
执行数据迁移
1 | add-migration L0 |
制作Helm镜像
K3s配置内网域名解析
K3s 启动后,会自动帮我们安装好 CoreDNS,不需要手动安装。如果你想修改 CoreDNS 的配置,常用的有两种方式:
- 直接修改 CoreDNS 的 configmap 来调整 CoreDNS 的参数,例如:
kubectl -n kube-system edit configmap coredns
- 修改 K3s manifests 中的 CoreDNS 配置文件,文件位置:
/var/lib/rancher/k3s/server/manifests/coredns.yaml
这两种方式虽然简单,但都有相同的弊端:当你重启 K3s 服务或者升级 K3s 时,由于 K3s 会重新初始化 manifests 中的 CoreDNS 等配置,所以会覆盖掉你通过以上两种方式修改的 coredns 配置。
如果你想修改 K3s 中 CoreDNS 中的配置,并且持久生效的话,可以通过额外的 coredns-custom
configmap 安装到 CoreDNS 容器中,并从包含的文件中导入覆盖和额外的 CoreDNS 配置。
1 | apiVersion: v1 |
ConfigMap 的 name 一定刚要是 coredns-custom
才能够被 coredns 的 deployment 识别并挂载。
在其他Pod中验证CoreDNS配置是否生效
1 | kubectl create deploy nginx --image=nginx:latest # 创建deploy |