一个全栈攻城狮的纯技术干货分享 ~
搜索到
121
篇与
的结果
-
为Hyper-V虚拟机开启Trunk模式 我是非常喜欢Linux的，但是终究还是逃离不了Windows，昨天为了给一台Hyper-v虚拟机开启Trunk模式，折腾了将近1个小时。先直接上结果Set-VMNetworkAdapterVlan -VMName test -Trunk -AllowedVlanIdList 1-4094 -NativeVlanId 0以下为我实验的一些命令，供大家参考显示虚拟机test的所有网卡状态Get-VMNetworkAdapterVlan -VMName test设置lan网卡为不打标Set-VMNetworkAdapterVlan -VMName test -VMNetworkAdapterName lan -Untagged设置lan网卡为access口vlan1Set-VMNetworkAdapterVlan -VMName test -VMNetworkAdapterName lan -Access -VlanId 1设置lan网卡为trunk口Set-VMNetworkAdapterVlan -VMName test -VMNetworkAdapterName lan -Trunk -AllowedVlanIdList 1-4094 -NativeVlanId 0启用lan网卡MAC地址欺骗Set-VMNetworkAdapter -VMName test -VMNetworkAdapterName lan -MacAddressSpoofing On关闭lan网卡MAC地址欺骗Set-VMNetworkAdapter -VMName test -VMNetworkAdapterName lan -MacAddressSpoofing Off官方文档https://docs.microsoft.com/en-us/powershell/module/hyper-v/?view=windowsserver2019-ps -
解决Typescript文件被识别为视频的问题 概念引入TypeScript 是微软开发的一个开源的编程语言，通过在JavaScript的基础上添加静态类型定义构建而成Transport Stream 即传输流，是一种常见的视频封装格式，基于MPEG-2的封装格式（所以也叫MPEG-TS）TypeScript和Transport Stream的文件扩展名均为ts问题现象在Windows操作系统上.ts被默认标记为Transport Stream，对于普通用户来讲这完全没有问题，但对于TypeScript开发者来说简直就是个灾难了：用文件浏览器打开一个.ts文件较多的项目时，系统需要把所有文件扫描一遍，并尝试识别视频的封面，这个过程几乎就是逐帧动画，严重影响工作效率。解决办法要解决这个问题，必然是要修改Windows的注册表，将下面的代码保存为typescript.reg，然后双击导入注册表，重启系统即可。Windows Registry Editor Version 5.00 [-HKEY_CLASSES_ROOT\.ts] [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Kindmap] ".ts"="document"恢复视频模式那有人可能要说了，如果哪天我想恢复回去怎么办？下面给出恢复用的注册表代码：Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\.ts] "Content Type"="video/vnd.dlna.mpeg-tts" "PerceivedType"="video" [HKEY_CLASSES_ROOT\.ts\OpenWithProgids] "AppX6eg8h5sxqq90pv53845wmnbewywdqq5h"=hex(0): [HKEY_CLASSES_ROOT\.ts\ShellEx] [HKEY_CLASSES_ROOT\.ts\ShellEx\{BB2E617C-0920-11D1-9A0B-00C04FC2D6C1}] @="{9DBD2C50-62AD-11D0-B806-00C04FD706EC}" [HKEY_CLASSES_ROOT\.ts\ShellEx\{e357fccd-a995-4576-b01f-234630154e96}] @="{9DBD2C50-62AD-11D0-B806-00C04FD706EC}" [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Kindmap] ".ts"="video"
-
腾讯云轻量服务器 Matomo 镜像常见使用问题 上一篇文章 《免费网站统计步入末路，自建统计系统势在必行》发布后，收集了几个大家比较关心的问题，这里一一作答。重要提示由于 Lighthouse 的应用都安装在 /usr/local/lighthouse/softwares/ 目录，故下文中所有非/开头的路径均以此目录为参照。配置域名 和 https当前正在通过不安全的 HTTP 使用 Matomo，这会让 Matomo 容易受到安全漏洞的攻击。 这可能还违反了隐私法，因为某些功能（包括选择退出 Cookie）将无法使用。 我们建议您将 Matomo 设置为使用 SSL（HTTPS）以提高安全性。安装完 Matomo，进入后台，会有上述提示，按照下面的方法配置 https 可解决此问题：修改 Matomo 配置文件 matomo/config/config.ini.php，在 [General] 配置段添加自己的域名trusted_hosts[] = "ma.rehiy.com"编辑 Nginx 配置文件 nginx/conf/include/matomo.conf，替换 listen 80 default_server; 为下面的内容listen 80; listen 443 ssl; server_name ma.rehiy.com; ssl_certificate certs/rehiy.com.cer; ssl_certificate_key certs/rehiy.com.key;重新加载 Nginx 配置systemctl reload nginx获得客户真实 ip 地址如果为 Matomo 配置了 CDN，则可能出现无法获取客户端真实 IP 地址的情况。可参照如下方法解决：提示：下文的腾讯云CDN地址列表可能有变动，可以从自己的控制台获取下最新的列表。如果使用了其他CDN也可以按照格式添加条目。创建 Nginx 配置文件 nginx/conf/http.d/real-ip.conf，内容如下：real_ip_recursive on; real_ip_header X-Forwarded-For; # private ip list set_real_ip_from 10.0.0.0/8; set_real_ip_from 127.0.0.0/8; set_real_ip_from 169.254.0.0/16; set_real_ip_from 172.16.0.0/12; set_real_ip_from 192.168.0.0/16; # tencent cloud cdn set_real_ip_from 101.89.27.0/24; set_real_ip_from 101.89.32.0/24; set_real_ip_from 101.89.34.0/24; set_real_ip_from 101.91.24.0/24; set_real_ip_from 112.53.38.0/24; set_real_ip_from 116.128.128.0/24; set_real_ip_from 119.188.19.0/24; set_real_ip_from 120.221.167.0/24; set_real_ip_from 120.221.168.0/24; set_real_ip_from 121.51.191.0/24; set_real_ip_from 121.51.90.0/24; set_real_ip_from 121.51.93.0/24; set_real_ip_from 122.97.142.0/24; set_real_ip_from 122.97.143.0/24; set_real_ip_from 123.151.144.0/24; set_real_ip_from 140.249.67.0/24; set_real_ip_from 182.254.58.0/24; set_real_ip_from 220.194.88.0/24; set_real_ip_from 223.166.151.0/24; set_real_ip_from 27.155.114.0/24; set_real_ip_from 27.155.115.0/24; set_real_ip_from 36.152.58.0/24; set_real_ip_from 36.248.2.0/24; set_real_ip_from 58.217.244.0/24; set_real_ip_from 58.217.245.0/24; set_real_ip_from 58.251.121.0/24; set_real_ip_from 59.36.117.0/24; set_real_ip_from 59.36.119.0/24; set_real_ip_from 59.36.120.0/24; set_real_ip_from 59.36.95.0/24; set_real_ip_from 61.151.164.0/24;重新加载 Nginx 配置systemctl reload nginx添加 ICP 备案号编辑文件 matomo/plugins/Login/templates/layout.twig，在 Template.pageFooter 后面一行添加下面的代码<div style="text-align:center"> <a href="https://beian.miit.gov.cn">京ICP备00000000号-0</a> </div>最后保存，记得要把文件编码更改为 utf-8，编码不正确会出现乱码。注意：这样做会导致后台系统检查提示：文件完整性检查失败，并报告一些错误。虽然可以通过修改系统的完整性校验文件来绕过提示，但这里不再给出方法，毕竟这样可以提示你修改过哪些文件，便于升级时处理兼容性。当统计数据量足够多时，你可能还需要下面的操作用 Matomo/Piwik 定时导入日志实现统计网站访问情况手动删除 Matomo/Piwik 历史日志（MySQL删除大量数据）
-
基于 nginx 搭建 jsdelivr 镜像站 最近 jsdelivr 可谓国内站长圈的头条常客，这不，又双叒叕（yòu shuāng ruò zhuó）打不开了。如何解决这个问题？最简单的方法当然是使用别人建立的jsd镜像站，但是稳定性和可靠性就只能看镜像站长的心情了吧。自己动手丰衣足食，还是自己搞个镜像吧。创建 jsdelivr 镜像站首先，你需要有一台安装了 nginx 的服务器。推荐使用腾讯云轻量服务器的Matomo镜像，其中集成了最新稳定版 nginx、php、mariadb、Matomo 等服务端软件。把下面的 nginx 配置保存为 jsdelivr.conf，然后上传到你的 nginx 站点配置目录中， 一般为 /etc/nginx/include 或者 /etc/nginx/http.d。使用上面提到的 Matomo 镜像，请上传到 /usr/local/lighthouse/softwares/nginx/conf/include 目录使用宝塔镜像，可以替换下其生成的站点配置server { listen 80; listen 443 ssl http2; # 请更改为你的证书路径 ssl_certificate certs/default.cer; ssl_certificate_key certs/default.key; # 请更改为你的镜像域名 server_name jsd.rehiy.com; location / { proxy_pass https://cdn.jsdelivr.net; proxy_set_header Host $proxy_host; proxy_set_header Accept-Encoding ''; proxy_ssl_server_name on; proxy_ssl_name $proxy_host; proxy_redirect / /; # Proxy Cache proxy_cache jsdelivr; proxy_cache_lock on; proxy_cache_lock_timeout 15s; proxy_cache_use_stale updating; proxy_cache_background_update on; proxy_cache_key $host$request_uri; proxy_cache_valid 200 301 302 30d; proxy_cache_valid 500 501 502 503 15s; proxy_cache_valid any 5m; # Replace Domain sub_filter_once off; sub_filter_types application/javascript application/json text/xml text/css; sub_filter '$proxy_host' '$host'; } } # 缓存路径请根据需要更改 proxy_cache_path /var/tmp/nginx/jsdelivr levels=1:2 use_temp_path=off keys_zone=jsdelivr:300m inactive=30d max_size=30g;使用 jsdelivr 镜像站在你的站点源码中批量替换 cdn.jsdelivr.net 为 jsd.rehiy.com 即可使用自己的jsd镜像了。当然，也可以把下面的代码插入到你的站点 nginx 配置中，不修改站点源码替换为自己的镜像站。sub_filter_once off; sub_filter_types application/javascript application/json text/xml text/css; sub_filter 'cdn.jsdelivr.net' 'jsd.rehiy.com';
-
云服务器开启虚拟内存 SWAP 云服务器一般默认禁止虚拟内存，我们可以通过 shell 快速开启虚拟内存。bs=1M count=4096 表示创建一个4G（1M*4096）大小的块文件。swappiness=0 表示最大限度使用物理内存，然后才是swap空间。swappiness＝100 表示积极的使用swap分区，并且把内存上的数据及时的搬运到swap空间里面。# 创建虚拟内存文件 dd if=/dev/zero of=/mnt/swap bs=1M count=4096 chmod 0600 /mnt/swap mkswap /mnt/swap swapon /mnt/swap # 写入自动挂载参数 if ! grep -q swap /etc/fstab; then echo "/mnt/swap swap swap defaults 0 0" >> /etc/fstab fi # 设置虚拟内存使用率 if ! grep -q swappiness /etc/sysctl.conf; then echo "vm.swappiness = 10" >> /etc/sysctl.conf else sed -i 's/vm.swappiness = 0/vm.swappiness = 10/' /etc/sysctl.conf fi # 使配置生效 sysctl -p
-
记一次私有 git 仓库恢复事件 今日一个私有 git 仓库突然无法访问，查阅日志得知错误为：error: object file .git/objects/* is empty ...溯源首先对运行在 Longhorn 上仓库磁盘做个快照。继续检查上游日志，发现15分钟前 DroneCI 提交编译结果时，仓库磁盘由于性能问题，正好发生了迁移事件。事件溯源到此，先解决仓库访问问题，再来查看磁盘问题吧。解决思路1、由于是文件写入失败导致的问题，故而只要删除仓库里的空文件即可，进入仓库目录后执行下面的命令。# 查看有问题的存储对象 git fsck --full # 删除仓库下的所有空文件 find . -type f -empty -delete -print2、由于删除了最后提交的文件，分支标记将会失效，我们先来查找孤立的提交，再关联到分支。# 命令结束后拿到 `angling commit` 的值 xxxxxx git fsck --full # 关联到当前分支 git update-ref HEAD xxxxxx3、如果有多个分支，可以查阅本地的 commit hash 与分支的对应关系，然后关联到指定分支。# 分别对 `angling commit` 进行关联 git update-ref refs/heads/branch-1 xxxxxx git update-ref refs/heads/branch-2 yyyyyy结束语至此，仓库已经恢复。此次事件，让我对分布式文件系统的可靠性产生了一丝丝的动摇。但无论如何，对生产数据进行妥善备份才是最重要的。
-
Kubernetes 领进门 | 使用 Ingress-nginx 反向代理外部站点 本文旨在展示如何使用 ingress-nginx 作为反向代理加速集群外部服务原理。下文以反向代理 github 为例，读者自行修改域名即可。创建外部服务及路由描述1、修改 github.com 为目标域名2、修改 gh.rehiy.com 为预期域名3、将下列内容保存为 gh-proxy.yamlkind: Service apiVersion: v1 metadata: name: gh-proxy spec: type: ExternalName externalName: github.com ports: - name: https port: 443 --- kind: Ingress apiVersion: networking.k8s.io/v1 metadata: name: &name gh-proxy annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/proxy-body-size: 100m nginx.ingress.kubernetes.io/proxy-send-timeout: "600" nginx.ingress.kubernetes.io/proxy-read-timeout: "600" nginx.ingress.kubernetes.io/backend-protocol: HTTPS nginx.ingress.kubernetes.io/upstream-vhost: github.com spec: rules: - host: gh.rehiy.com http: paths: - path: / pathType: Prefix backend: service: name: *name port: name: https tls: - secretName: gh.rehiy.com为避免阅读障碍，详细的优化参数并未包含在内，如有需求可自行琢磨。应用变更操作完成后，即可通过 gh.rehiy.com 访问 github.com 的内容kubectl apply -f gh-proxy.yaml
-
Kubernetes 领进门 | 安装 longhorn 持久存储 Longhorn 提供了简单、易于部署和升级的100% 开源云原生持久化块存储解决方案，大大降低了采用专有软件的成本本教程适用于 Alpine/CentOS/Debian/Ubuntu 等内核版本大于4的操作系统，部分特别声明的步骤在其他操作系统可以忽略1a、环境准备（所有 Alpine 节点执行）# 安装依赖 mount --make-rshared / apk add bash lsblk nfs-utils open-iscsi # 设置启动参数（主服务器） if [ -x /etc/init.d/k3s ]; then sed -i 's#start_pre() {#start_pre() {\nmount --make-rshared /#' /etc/init.d/k3s fi # 设置启动参数（边缘节点） if [ -x /etc/init.d/k3s-agent ]; then sed -i 's#start_pre() {#start_pre() {\nmount --make-rshared /#' /etc/init.d/k3s-agent fi1b、环境准备（仅 CentOS/Debian/Ubuntu 主节点执行）# 安装 iscsi kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.2.4/deploy/prerequisite/longhorn-iscsi-installation.yaml # 安装 nfs-clinet kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.2.4/deploy/prerequisite/longhorn-nfs-installation.yaml这两条命令将在所有节点安装 iscsi 和 nfs-client若无法自动安装，请手动在所有节点安装上述依赖包2、安装 Longhorn 存储# 安装存储服务 kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.2.4/deploy/longhorn.yaml # 监控安装进度（CTRL+C退出） kubectl -n longhorn-system get pods --watch3、配置访问域名及密码# 账号密码 export MY_AUTH_USERNAME=admin export MY_AUTH_PASSWORD=PASSW0RD # 访问域名 export MY_LONGHORN_HOST=longhorn.example.org # 生成密钥 export MY_SECRET_CODE=`echo $MY_AUTH_USERNAME:$(echo $MY_AUTH_PASSWORD | openssl passwd -stdin -apr1) | base64` # 应用模板 cat <<EOF | kubectl apply -f - kind: Secret apiVersion: v1 metadata: name: basic-auth namespace: longhorn-system data: auth: $MY_SECRET_CODE --- apiVersion: traefik.containo.us/v1alpha1 kind: Middleware metadata: name: longhorn-basic-auth namespace: longhorn-system spec: basicAuth: secret: basic-auth --- kind: IngressRoute apiVersion: traefik.containo.us/v1alpha1 metadata: name: longhorn-dashboard namespace: longhorn-system spec: entryPoints: - websecure routes: - kind: Rule match: Host(\`$MY_LONGHORN_HOST\`) middlewares: - name: longhorn-basic-auth services: - kind: Service name: longhorn-frontend namespace: longhorn-system port: 80 tls: certResolver: default EOF请注意修改域名 longhorn.example.org若未配置自动签发证书，请删除 tls 的两行配置配置完成后，可以通过 https://longhorn.example.org 访问存储管理系统4、自动备份到S3对象存储# S3参数 export MY_S3_ACCESS_KEY_ID=key-id export MY_S3_SECRET_ACCESS_KEY=secret-key export MY_S3_ENDPOINTS=https://your-s3-domain # 保存密钥 cat <<EOF | kubectl apply -f - kind: Secret apiVersion: v1 metadata: name: s3-backup namespace: longhorn-system type: Opaque data: AWS_ACCESS_KEY_ID: $(echo -n $MY_S3_ACCESS_KEY_ID | base64) AWS_SECRET_ACCESS_KEY: $(echo -n $MY_S3_SECRET_ACCESS_KEY | base64) AWS_ENDPOINTS: $(echo -n $MY_S3_ENDPOINTS | base64) EOF修改S3参数变量，应用变更；然后登录存储管理系统进入 Setting - General 页面，填写下面选项Backup Target 格式为s3://存储桶@区域/子目录，例如 s3://[email protected]/longhornBackup Target Credential Secret 填写上面创建的密钥名 s3-backup进入Recurring Job 页面，点击 Create Recurring Job 创建自动备份任务其他章节根据本站Tag查阅 《Kubernetes 领进门》 系列文章
