追新2023，goland激活码快速激活至2099年！

文章目录 1 2 3 4 5 6 7 8 9 10 11 一、简介 1. MinGW 和 MinGW-W64 区别和联系 二、下载 1. 从 sourceforge.net 下载 2. 从 github 下载 3. 从 镜像站点 下载 三、安装与配置 1. 在线安装 2. 离线安装 3. 环境配置 四、总结 一、简介 MinGW 和 MinGW-W64 区别和联系 MinGW和MinGW-W64都是用于Windows平台的轻量级GNU工具链，用于开发和编译C和C++程序。 MinGW（Minimalist GNU for Windows）是一个32位的GNU工具链，它提供了一套基于GNU的开发环境，包括GCC编译器和一些GNU库，可以用来编译Windows下的C和C++程序。但MinGW只支持32位程序的编译。 MinGW-W64是一个64位的GNU工具链，是MinGW的升级版，原本它是MinGW的分支，后来成为独立发展的项目，它支持同时编译32位和64位程序。它包括了一系列的GNU库和工具，例如GCC、Binutils、GDB等，还支持一些实用工具和库，如OpenMP、MPI等。

1.nginx 301跳转问题背景 在使用hugo部署博客，部署方案nginx+docker,在浏览器地址使用url访问静态资源目录时，发现默认跳转到了http协议的地址。 调出浏览器发现客户端发送的http请求收到了一个301状态码的响应，并且响应头中的Location字段便是跳转到的http协议的地址。 2.原因分析 为啥服务端会返回301呢？首先需要弄清楚状态码的含义。HTTP协议中3xx开头的状态响应码都是表示重定向的响应。根据RFC的定义： 301 Moved Permanently 302 Found 303 See Other 307 Temporary Redirect 301是永久重定向。如果使用Nginx作为HTTP服务器，那么当用户输入一个不存在的地址之后，基本上会有两种情况：1.返回404状态码，2.返回301状态码和重定向地址。404 Not Found不做讨论，只说下301 Moved Permanently的处理过程。 首先需要明确的问题是，301重定向在什么情况下会被触发呢？ 答案是：Nginx负责设置301 Moved Permanently状态码。但nginx.conf控制Nginx如何处理301 Moved Permanently状态码！ 换句话说，要不要进行页面重定向，和怎么重定向，完全是用户配置的结果！ Nginx主动设置301 Moved Permanently状态码只有一种情况，当用户在浏览器输入了一个url地址，末尾部分是一个文件目录且不以斜杠”/“结尾，比如 “www.test.com/index” 。 Nginx没有找到index这个文件，但发现了index是个目录。于是本次访问的返回状态码就会被设置成301 Moved Permanently。 浏览器与Nginx的通信过程如下所示： 一般情况下，我们会在nginx.conf中配置absolute_redirect ，server_name_in_redirect和port_in_redirect，以便到达个性化的重定向功能。其中absolute_redirect控制Location url的生成方式。 absolute_redirect设置成on，则生成绝对路径作为Location url。 absolute_redirect设置成off，则生成相对路径作为Location url。 只有absolute_redirect设置为on时，另外两个配置才会生效。 3. 解决方法 设置absolute_redirect为off，构造相对路径作为Location url，示例如下：

1. 将service端口暴露到本地 比如将生产环境的redis暴露到本地6379端口 1 kubectl port-forward service/redis -n [namesplace] 6379:6379 2. 进入容器中 kubectl exec -it [pod] -n [namesplace] -- bash 3. 查看日志 查看最后1行的日志 kubectl logs -f --tail 1 [pod] -n [namesplace] 查看最后一分钟的所有日志 kubectl -n [namesplace] logs [pod] --since=1m 查看指定时间 kubectl -n -n [namesplace] logs -f [pod] --since-time="2022-10-24T02:54:03.467+01:00" 4. 查看配置： kubectl get pod product-6b5c98478b-rpgr6 --namespace=product-prod -o yaml kubectl describe pods product-6b5c98478b-rpgr6 --namespace=product-prod 5.

1. gitlab安装前准备 系统版本：Ubuntu 22.04.1 LTS 1.1 更新系统环境 sudo apt update sudo apt upgrade 1.2 安装和配置必须的依赖项 1 2 sudo apt-get install -y curl openssh-server ca-certificates tzdata perl sudo apt-get install curl 2.下载和安装gitlab 2.1 下载指定的版本 1 curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash 2.2 开始安装 注意：localhost为访问gitlab的地址，85为访问gitlab的端口号 1 sudo EXTERNAL_URL="http://localhost:85" apt-get install gitlab-ce=15.9.3-ce.0 除非您在安装过程中指定了自定义密码，否则将随机生成一个密码并存储在 /etc/gitlab/initial_root_password文件中(出于安全原因，24 小时后，此文件会被第一次 gitlab-ctl reconfigure 自动删除， 因此若使用随机密码登录，建议安装成功初始登录成功之后，立即修改初始密码）。使用此密码和用户名 root 登录。

CND转发到v2ray服务 环境: 域名一个 aws cloudfront服务 数据转发流程 A.example.com->cloudfront->B.example.com->ip.ec2.port 注意事项 踩过的坑： v2ray-plugin报错 http: TLS handshake error from 64.252.173.97:23912: read tcp 172.21.0.3:443->64.252.173.97:23912: read: connection reset by peer 原因为2层(EC2,cloudfront)TLS证书不一致; 第一个想法就是将两个证书整成一致，然后cloudfront就上传"Let’s Encrypt自签的证书，发现使用自上传的证书cloudfront根本不转发数据了;得出一个结论:cloudfront必须使用它请求生成的tls证书； 解决方案：A.example.com->cloudfront->ip.ec2.port转发流程修改为A.example.com->cloudfront->B.example.com->ip.ec2.port v2ray-plugin报错not found in 'Sec-Websocket-Version' header 1 cloudfront ws一直是v2ray.com/core/transport/internet/websocket: failed to convert to WebSocket connection > websocket: unsupported version: 13 not found in 'Sec-Websocket-Version' header 原因是cloudfront没有配置转发HTTP请求头,CloudFront 预设并不会转发所有的 HTTP request headers， 有些 request headers 在经过 CloudFront 之后就被丟掉了导致 v2ray 无法识别到必要的数据。 需要更改 origin request policies 為 Managed-AllViewer，這樣它才會轉發所有的 headers。 - 解决方案：cloudfront设置源请求策略为```Managed-AllViewer``` cloudfront转发数据到源失败，解决方法是需要更改行为策略->缓存策略名称(Managed-CachingDisabled)->源请求策略名称(Managed-AllViewerExceptHostHeader) 源服务器没有接收到数据,错误的提示： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 root@localhost ~ # curl -v https://proxy.