op之路

ip 网络配置工具 补充说明 ip命令 用来显示或操纵Linux主机的路由、网络设备、策略路由和隧道，是Linux下较新的功能强大的网络配置工具。 语法 ip(选项)(对象) Usage: ip [ OPTIONS ] OBJECT { COMMAND | help } ip [ -force ] -batch filename 对象 OBJECT := { link | address | addrlabel | route | rule | neigh | ntable | tunnel | tuntap | maddress | mroute | mrule | monitor | xfrm | netns | l2tp | macsec | tcp_metrics | token } -V：显示指令版本信息； -s：输出更详细的信息； -f：强制使用指定的协议族； -4：指定使用的网络层协议是IPv4协议； -6：指定使用的网络层协议是IPv6协议； -0：输出信息每条记录输出一行，即使内容较多也不换行显示； -r：显示主机时，不使用IP地址，而使用主机的域名。 选项 OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve] | -h[uman-readable] | -iec | -f[amily] { inet | inet6 | ipx | dnet | bridge | link } | -4 | -6 | -I | -D | -B | -0 | -l[oops] { maximum-addr-flush-attempts } | -o[neline] | -t[imestamp] | -ts[hort] | -b[atch] [filename] | -rc[vbuf] [size] | -n[etns] name | -a[ll] } 网络对象：指定要管理的网络对象； 具体操作：对指定的网络对象完成具体操作； help：显示网络对象支持的操作命令的帮助信息。 实例 ip link show # 显示网络接口信息 ip link set eth0 up # 开启网卡 ip link set eth0 down # 关闭网卡 ip link set eth0 promisc on # 开启网卡的混合模式 ip link set eth0 promisc offi # 关闭网卡的混合模式 ip link set eth0 txqueuelen 1200 # 设置网卡队列长度 ip link set eth0 mtu 1400 # 设置网卡最大传输单元 ip addr show # 显示网卡IP信息 ip addr add 192....

自动切换DHCP的Gateway https://zhuanlan.zhihu.com/p/341954106 #!/bin/bash default_gateway='192.168.0.4' auxiliary_gateway='192.168.0.1' # Use 8.8.8.8 up_gateway='8.8.8.8' pkt_num=3 check_ip_available(){ ping -c $pkt_num $1 | grep packets | awk '{print $4}' } # If the gateway of the up close, the network is completely unusable res=`check_ip_available $up_gateway` echo $res if [ $((res)) -eq 0 ]; then echo "up_gateway unusable" exit 1 fi cur_gateway=`/bin/nvram get dhcp_gateway_x` # get current gateway if [ "$cur_gateway" = "$default_gateway" ]; then echo "cur is default_gateway" res=`check_ip_available $auxiliary_gateway` if [ $(($res)) -eq 0 ]; then echo "auxiliary_gateway not avaliable, abort" exit 1 fi res=`check_ip_available $cur_gateway` if [ $(($res)) -eq $pkt_num ]; then echo "default_gateway works fine, skip" exit 1 fi echo "switch to auxiliary" # to switch /bin/nvram set dhcp_gateway_x=$auxiliary_gateway /bin/nvram set dhcp_dns1_x=$auxiliary_gateway /bin/nvram set dhcp_dns2_x="" /bin/nvram commit /sbin/rc rc_service restart_net_and_phy exit 0 fi if [ "$cur_gateway" = "$auxiliary_gateway" ]; then echo "cur is auxiliary_gateway" res=`check_ip_available $auxiliary_gateway` if [ $(($res)) -eq 0 ]; then echo "auxiliary_gateway not avaliable, abort" exit 1 fi res=`check_ip_available $default_gateway` if [ $(($res)) -eq 0 ]; then echo "default_gateway still not works, skip" exit 1 fi echo "default_gateway works fine now" echo "switch to default" # to switch /bin/nvram set dhcp_gateway_x=$default_gateway /bin/nvram set dhcp_dns1_x=$default_gateway /bin/nvram set dhcp_dns2_x=$auxiliary_gateway /bin/nvram commit /sbin/rc rc_service restart_net_and_phy exit 0 fi echo "nothing change" 参考 How to add cron job on Asuswrt Merlin Wifi Router

在 kubernetes 集群中运行比特币节点 前 最近在研究矿池的架构的K8s上的迁移，在尝试在集群上运行比特币节点。 通过K8s来跑节点存在的一些收益： 共用Prometheus系统来监控的比特币节点状态。 可以和其他的服务快速的集成通过Service 对比专用实例独立部署的话需要更少的资源 到目前为止，节点的pod 已经运行超过 164 天，没有遇到中断问题。下图是 bitcoind pod 状态： 资源准备 B基础镜像 使用dockerhub 的基础镜像ruimarinho/bitcoin-core 时刻保持和官网的最新版本的同步更新 磁盘大小和类型 到 2020 年初，比特币数据的大小约为 333GB [1] 。 所以节点需要分配了一个 600 GB 的 EBS 卷来作为存储。 使用sc1 EBS 类型。虽然速度不是最快。但是节点完全同步之后，IO 需求就会大大减少，后面就足够使用了 硬盘空间目前是足够使用的后面还需要进行继续的扩容。但我们需要再次扩展该卷 集群节点规格 目前所有的 k8s 节点都使用m5.xlarge节点。 所以 bitcoind pod 在m5.xlarge上运行。没有专用节点 部署 SVC bitcoind RPC服务 暴露的yaml 文件： kind: Service apiVersion: v1 metadata: name: bitcoind-mainnet spec: selector: app: bitcoind-mainnet ports: - name: rpc port: 8332 - name: zmq port: 28332 Deploy bitcoind Deployment 的 yaml文件...

前 这篇用来记录下自己备考CKA考试的这段时间的学习感悟以及提升。虽然考试不难，最后也是95分通过了。但是在备考的过程中还是学到不少的东西，所以用这篇文章来记录一下。 通过前面学习，也逐渐的领悟了 K8s 的设计哲学。当然这里只是自己的理解 它是一个按照Linux “一切皆文件”设计的宏观系统。实现了”一切皆资源“ 基础通识 考试内容 考试涉及的知识大抵下面的这些： 关于service，ingress。你要设立service，然后创建ingress。 关于pv，pvc 关于service account，cluster role，rolebinding 关于nodehealth，troubleshoot kubeadm升级 etcd backup/restore。 deoloyment，pod multi container pod pod中container的log搜索。 技巧 # 用来切换 kube环境 kubectl config use-context xxx # 获取标签 kubectl get ns --show-labesls kubectl get pod,sve -o wide # 来创建对应的服务。 ubectl expose pod curl --port=80 --target-port=8000 Short name Full name sts statefulSet cm configmaps ds daemonsets deploy deployments ep endpoints ev events hpa horizontalpodautoscalers ing ingresses limits limitranges ns namespaces no nodes pvc persistentvolumeclaims pv persistentvolumes po pods rs replicasets rc replicationcontrollers quota resourcequotas sa serviceaccounts svc services 使用 kubectl top 的时候的需要安装 Kubernetes Metrics Server，使用yam 文件来进行一键安装...

​ 大多数的Nginx安装指南告诉你如下基础知识——通过apt-get安装，修改这里或那里的几行配置，好了，你已经有了一个Web服务器了！而且，在大多数情况下，一个常规安装的nginx对你的网站来说已经能很好地工作了。然而，如果你真的想挤压出nginx的性能，你必须更深入一些。在本指南中，我将解释Nginx的那些设置可以微调，以优化处理大量客户端时的性能。需要注意一点，这不是一个全面的微调指南。这是一个简单的预览——那些可以通过微调来提高性能设置的概述。你的情况可能不同。 基本的 (优化过的)配置 我们将修改的唯一文件是nginx.conf，其中包含Nginx不同模块的所有设置。你应该能够在服务器的**/etc/nginx**目录中找到nginx.conf。首先，我们将谈论一些全局设置，然后按文件中的模块挨个来，谈一下哪些设置能够让你在大量客户端访问时拥有良好的性能，为什么它们会提高性能。本文的结尾有一个完整的配置文件。 高层的配置 nginx.conf文件中，Nginx中有少数的几个高级配置在模块部分之上。 user www-data; pid /var/run/nginx.pid; worker_processes auto; worker_rlimit_nofile 100000; user和pid应该按默认设置 - 我们不会更改这些内容，因为更改与否没有什么不同。 worker_processes 定义了nginx对外提供web服务时的worder进程数。最优值取决于许多因素，包括（但不限于）CPU核的数量、存储数据的硬盘数量及负载模式。不能确定的时候，将其设置为可用的CPU内核数将是一个好的开始（设置为“auto”将尝试自动检测它）。 worker_rlimit_nofile 更改worker进程的最大打开文件数限制。如果没设置的话，这个值为操作系统的限制。设置后你的操作系统和Nginx可以处理比“ulimit -a”更多的文件，所以把这个值设高，这样nginx就不会有“too many open files”问题了。 Events模块 events模块中包含nginx中所有处理连接的设置。 events { worker_connections 2048; multi_accept on; use epoll; } worker_connections设置可由一个worker进程同时打开的最大连接数。如果设置了上面提到的worker_rlimit_nofile，我们可以将这个值设得很高。 记住，最大客户数也由系统的可用socket连接数限制（~ 64K），所以设置不切实际的高没什么好处。 multi_accept 告诉nginx收到一个新连接通知后接受尽可能多的连接。 use 设置用于复用客户端线程的轮询方法。如果你使用Linux 2.6+，你应该使用epoll。如果你使用*BSD，你应该使用kqueue。想知道更多有关事件轮询？看下维基百科吧（注意，想了解一切的话可能需要neckbeard和操作系统的课程基础） （值得注意的是如果你不知道Nginx该使用哪种轮询方法的话，它会选择一个最适合你操作系统的） HTTP 模块 HTTP模块控制着nginx http处理的所有核心特性。因为这里只有很少的配置，所以我们只节选配置的一小部分。所有这些设置都应该在http模块中，甚至你不会特别的注意到这段设置。 http { server_tokens off; sendfile on; tcp_nopush on; tcp_nodelay on; ... } server_tokens 并不会让nginx执行的速度更快，但它可以关闭在错误页面中的nginx版本数字，这样对于安全性是有好处的。 sendfile可以让sendfile()发挥作用。sendfile()可以在磁盘和TCP socket之间互相拷贝数据(或任意两个文件描述符)。Pre-sendfile是传送数据之前在用户空间申请数据缓冲区。之后用read()将数据从文件拷贝到这个缓冲区，write()将缓冲区数据写入网络。sendfile()是立即将数据从磁盘读到OS缓存。因为这种拷贝是在内核完成的，sendfile()要比组合read()和write()以及打开关闭丢弃缓冲更加有效(更多有关于sendfile) tcp_nopush 告诉nginx在一个数据包里发送所有头文件，而不一个接一个的发送 tcp_nodelay 告诉nginx不要缓存数据，而是一段一段的发送–当需要及时发送数据时，就应该给应用设置这个属性，这样发送一小块数据信息时就不能立即得到返回值。...

CKA 模拟题目的学习，虽然比较难。但是感觉都是值得学习的。 这里做完一次模拟之后用这篇文章来复习一下模拟题目 考前技巧 alias k=kubectl # will already be pre-configured export do="--dry-run=client -o yaml" # k create deploy nginx --image=nginx $do export now="--force --grace-period 0" # k delete pod x $now vimrc 编辑， set tabstop=2 set expandtab set shiftwidth=2 常见的资源缩写 deploy ds sts sa 正题 Q1 获取当前拥有哪些kube的环境。这个基本是送分题。第二个猪一下sed 的用法。**** kubectl config get-contexts -o name > /opt/course/1/contexts cat ~/.kube/config | grep current | sed -e "s/current-context: //" Q2 Create a single Pod of image httpd:2....

替换状态中的默认provider terraform state replace-provider -auto-approve "registry.terraform.io/-/cloudflare" "registry.terraform.io/cloudflare/cloudflare" terraform { required_providers { cloudflare = { version = "~> 3.26.0" source = "cloudflare/cloudflare" } } } 删除不兼容的资源状态以及TF资源 在.tf文件中删除对应的资源。并且删除其状态。 terraform state list terraform state rm cloudflare_record.tfer--A_diglp-002E-cf_4ef5c2378c973b50caeb9c229e99e0fe terraform state rm cloudflare_record.tfer--A_diglp-002E-cf_4ef5c2378c973b50caeb9c229e99e0fe terraform state rm cloudflare_record.tfer--A_diglp-002E-cf_d53999bbb78ab2ee5440cb12f3ac9a84 参考 Terraform 导入指南 Terraform Error message when executing terraform : Incompatible API version with plugin. Plugin version: 4, Client versions: [5] https://www.pulumi.com/ 使用编程语言进行的动态资源部署

前 今天遇到一个很有趣的问题，如何找到一个网站的真实IP，来获得可能存在的实际地区等信息。 目前的站点为了安全多半都是接入了CF/或者其他云服务商的代理服务，用来进行源站的保护。域名直接解析出来的是CF的边缘节点的地址，或者其他CDN的CNAME。 看起来拿到真实IP不大可行。 但是有一点，互联网上的变化是有迹可循的。这里的有迹可循指得是 DNS的历史记录以及可能配置成源站地址的旁站地址 正文 其实这个技巧本身是没有什么难度的，主要就是使用工具来进行情报收集以及分析工作。下面是整理的相关的搜索工具。提供了旁站搜索或者是DNS历史记录检索功能。 dnsdb 全球DNS搜索引擎 viewdns.info 令站长十分蛋疼的DNS历史记录网站，记录了几年内的更改记录。 securitytrails.com 庞大的DNS历史数据库，可以查出几年内网站用过的IP/机房信息数据量庞大。 search.censys.io 十分强大的安全搜索引擎，可以直接搜到IP/域名等等的相关数据得到所需信息 Shodan 别称“屎蛋”，老牌的安全搜索工具。提供的数据非常的全面。包括各种外部扫描出现的CVE。 censys.io 查询示例 https://www.shodan.io/domain/qq.com https://sitereport.netcraft.com/?url=http://qq.com https://viewdns.info/iphistory/?domain=qq.com 参考 超简单查询 获取套CF（Cloudflare）的网站真实源IP 绕过网站CDN查找网站真实ip方法大全

​ 在某台新服务器上，发现Nginx启动/重启耗时非常长。相同的配置复制到其他服务器，几乎在瞬间就能完成启动/重启操作，说明新服务器的行为不正常。进一步测试，nginx -t测试命令耗时也很长。为了不影响Nginx正常使用，需要找到原因解决问题。 使用strace命令跟踪进程的系统调用，从而排查可能出问题的位置。由于nginx -t的耗时也很长，就从这个单次命令看看能不能找出问题关键。 执行命令strace -T nginx -t，其中-T参数打印耗时，在进程卡住的地方看到如下输出： connect(7, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("x.x.x.x")}, 16) = 0 <0.000037> poll([{fd=7, events=POLLOUT}], 1, 0) = 1 ([{fd=7, revents=POLLOUT}]) <0.000029> sendmmsg(7, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\223\310\1\0\0\1\0\0\0\0\0\0\4ocsp\10digicert\3com\0\0"..., iov_len=35}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=35}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov= [{iov_base="I\320\1\0\0\1\0\0\0\0\0\0\4ocsp\10digicert\3com\0\0"..., iov_len=35}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=35}], 2, MSG_NOSIGNAL) = 2 <0.000090> poll([{fd=7, events=POLLIN}], 1, 5000) = 0 (Timeout) <5.005221> 根据行尾输出，poll系统调用耗时5.005221秒，大概率就是问题所在。那么上面的输出信息能看出什么呢？ 首先看connect这行中的sin_port=htons(53)，我们知道53是DNS查询端口，说明系统发起了DNS查询；再看第二行sendmmsg中的iov_base="\223\310\1\0\0\1\0\0\0\0\0\0\4ocsp\10digicert\3com，携带了证书的OCSP域名，猜测是向DNS服务器发起查询请求；最后的一行poll有Timeout提示，表明查询超时，并汇报等待了5.005221秒。 总结上述信息：系统向x.x.x.x发起证书OCSP域名的DNS查询请求，但是DNS超时未响应，导致耗时很长。 终端ping该DNS服务器的IP地址，无法ping通；打开/etc/resolv.conf，看到该IP地址写在第一行，顺手将其注释掉。 接下来再运行nginx -t命令，瞬间完成；接着测试启动、重启Nginx，几乎也是瞬间完成，说明问题解决。

如何使用Curl命令来测试接口HTTP是否启用了长连接的功能。偶得一命令记录之 curl \ -w "\nusing %{local_ip}:%{local_port} %{method} %{remote_ip}:%{remote_port}\n" --request GET \ --url http://httpbin.org/headers \ --header 'Content-Type: application/json' \ --data '{"N": 8}' \ --next \ -w "\nusing %{local_ip}:%{local_port} %{method} %{remote_ip}:%{remote_port}\n" --request GET \ --url http://httpbin.org/headers \ --header 'Content-Type: application/json' \ --data '{"N": 8}' \ --next \ -w "\nusing %{local_ip}:%{local_port} %{method} %{remote_ip}:%{remote_port}\n" --request GET \ --url http://httpbin.org/headers \ --header 'Content-Type: application/json' \ --data '{"N": 8}' { "headers": { "Accept": "*/*", "Content-Length": "8", "Content-Type": "application/json", "Host": "httpbin....