小五的个人杂货铺

免密操控(或者使用sshpass工具,看下面)ps: 免密操控不可以逆向, 就是说可以一个主控方, 多个被控方, 但不可以一个被控方,多个主控方 以下以gitlab-runner账户远程免密登陆root@192.168.56.100为例 先执行su gitlab-runner切换到gitlab-runner账户 在你的主控端机器上使用 ssh-keygen命令创建公钥，使用ssh-keygen -t rsa来创建，程序会问你存放目录，如果不需要修改，直接回车几次即可 将/.ssh目录下id_rsa.pub文件拷贝到受控机器的`/.ssh目录中，然后将文件内容导入到~/.ssh/authorized_keys`文件 1234主控方机器执行：scp ~/.ssh/id_rsa.pub root@192.168.56.100:~/.ssh/id_rsa.pub受控方机器执行：cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys 在受控方机器设置权限：~/.ssh权限...

背景 /var/opt/gitlab所在磁盘资源不足，现在希望将其无感迁移到**/data/opt/gitlab** 软链接方案停止 GitLab 服务1sudo gitlab-ctl stop 迁移数据到新盘目录12sudo mkdir -p /data/opt/gitlabsudo rsync -av --progress /var/opt/gitlab/ /data/opt/gitlab/ rsync 会保留文件权限和软链接，比 cp 安全。 rasync执行完后，使用diff指令确认下是否一致，如果不一致，则使用rsync继续进行迁移，直至无差异 备份原目录（以防回滚）1sudo mv /var/opt/gitlab /var/opt/gitlab.bak 建立软链接1sudo ln -s /data/opt/gitlab /var/opt/gitlab 权限检查1sudo chown -R git:git /data/opt/gitlab GitLab 默认用户是 git，如果你有改过...

转自思否用户@郭艺宾 Reactor模式 Reactor是1995年由道格拉斯提出的一种高性能网络编程模式。由于好多年了，当时的一些概念与现在略有不同，reactor模式在网络编程中是非常重要的，可以说是NIO框架的典型模式，一些经典的框架，比如Mina、Netty、Cindy都是此模式的实现。 我们来看看当年提出的通用模型： 上面的图形中： 1、Handle 可以理解为资源或者文件句柄，放在netty里面就是channel，就是我们实际要处理的东西 2、Event Handler和Concrete Event Handler 就是具体的事件处理器，对应netty中的handler接口和具体的handler 3、Synchronous Event Demultiplexer同步事件多路复用分发器，可以理解为nio中的select 4、Initiation Dispatcher，分发器，可以理解为nio中的循环，也就是netty中的EventLoop，处理各种事件 5、select（handlers）就是真正处理业务的地方 大家注意上面图形中的几个箭头，可以看出各个组件之...

netty Netty是一个高性能的网络编程框架。Netty是一个NIO客户端服务器框架，可以快速轻松地开发协议服务器和客户端等网络应用程序。它极大地简化并简化了TCP和UDP套接字服务器等网络编程。 优点 在设计方面来说： 1）统一的API,适用于不同的协议(阻塞和非阻塞) 2）基于灵活、可扩展的事件驱动模型（SEDA） 3）高度可定制的线程模型 4）可靠的无连接数据Socket支持(UDP) 在性能方面： 1）更好的吞吐量,低延迟 2）更省资源 3）尽量减少不必要的内存拷贝（这也是快的原因之一） 安全方面： 完整的SSL/TLS和STARTTLS的支持 在易用性方面： 1）完善的Java doc,用户指南和样例（个人觉得并不是很完善，国内的书籍也只有一两本还可以） 2）仅依赖于JDK1.6（netty 4.x) netty的主要组件包括： TransportChannel —-对应NIO中的channel EventLoop—- 对应于NIO中的while循环 EventLoopGroup: 多个EventLoop，就是事件循环 ChannelHandl...

ChannelHandler和ChannelPipeline---对应于NIO中的客户逻辑实现handleRead/handleWrite(interceptor pattern）ByteBuf---- 对应于NIO 中的ByteBuffer业务逻辑要放在handler里面，读写数据用的是ByteBuf。其余的Transport、ServerBootstrap、Channel和EventLoop等等都是套路代码，对于应用程序来说，了解即可，基本上不用管。真正开发过netty项目也知道，项目中大部分都是handler类，其它组件只是占很少一部分。 Transport组件 netty做的比较有适应性的就是，不仅支持NIO，还支持很多传输协议： OIO -阻塞IO（真正开发阻塞IO项目，其实也没必要用netty了。。。） NIO -Java NIO Epoll - Linux Epoll(JNI) Local Transport - IntraVM调用（通讯的双方在同一个虚拟机之内不再走socket） Embedded Transport - 供测试使用的嵌入传输 UDS...

ChannelHandler组件介绍ChannelHandler组件包含了业务处理核心逻辑，是由用户自定义的内容，开发人员百分之九十的代码都是ChannelHandler。Netty提供2个重要的 ChannelHandler 子接口，用来自定义ChannelHandler： ChannelInboundHandler - 处理进站数据和所有状态更改事件（进站指的是读操作等由通道引发的事件） ChannelOutboundHandler - 处理出站数据，允许拦截各种操作（出站指的是写操作等由用户触发的事件，发送到远方服务器的事件） 来看一下ChannelHandler的类层次结构： 上面的类中的Adapter类，提供很多默认操作，比如ChannelHandler中有很多很多方法，我们用户自定义的方法有时候不需要重载全部，只需要重载一两个方法，那么可以使用Adapter类，它里面有很多默认的方法。其它框架中结尾是Adapter的类的作用也大都是如此。所以我们在使用netty的时候，往往很少直接实现ChannelHandler的接口，经常是继承Adapter类。 Cha...

nginx location语法第一优先级 = : 完全匹配。如果这个查询匹配，那么将停止搜索并立即处理此请求。 第二优先级 ^~ : 普通字符匹配。优先使用前缀匹配。如果匹配成功，则不再匹配其他location。 第三优先级 ~ : 区分大小写匹配 第三优先级 !~ : 区分大小写不匹配 第三优先级 ~* : 不区分大小写匹配 第三优先级 !~* : 不区分大小写不匹配 第四优先级 /{uri} : 不带任何修饰符，也表示前缀匹配，但是在正则匹配之后。 第四优先级 / : 通用匹配，任何未匹配到其它location的请求都会匹配到，相当于switch中的default。 123456789101112131415161718192021222324location = / {# 只匹配 / 查询。}location / {# 匹配任何查询，因为所有请求都已 / 开头。但是正则表达式规则和长的块规则将被优先和查询匹配。}location ^~ /p_w_picpaths/ {# 匹配任何已 /p_w_picp...

nginx大全学习网站

listen 后可以指定 IP：port的IP地址和端口 仅IP（端口将默认为80） 仅port，将监听所有接口的这个port 到某个Unix socket的路径（在服务器间转发请求的时候会用到） 在将listen的值与请求进行匹配之前，Nginx会先将listen的值中所缺省的部分补充完整。然后将优先匹配准确的IP，如果不存在完全准确匹配的IP才会匹配到0.0.0.0，如果有多个IP:port匹配度相同，Nginx将会继续检查server_name server_name 指令Nginx将server_name与请求头中的Host进行匹配，匹配的顺序： 优先选择第一个精确匹配到的block。12345server { listen 80; server_name host.example.com; ...} 选择以*开头的进行匹配，并优先选择最长的。12345server { listen 80; server_name *.example.com; ...} 选择以*结尾的进行匹配，并优先选...

例子:如果url符合正则格式并且$temp_flag正则匹配11111,则代理到bbb,否则代理到aaa123456789set $proxy_path aaa;# 此处通过正则获取url第一个括号里的值,赋值给temp_flagif ( $request_uri ~ ^\/([0-9a-z]+)\/(.*) ){ set $temp_flag $1;}if ($temp_flag ~ (^11111$)) { set $proxy_path bbb;}proxy_pass http://$proxy_path; uri和request_uri的区别 request_uri: 这个变量等于从客户端发送来的原始请求URI（最原始的），包括参数，它不可以进行修改。$uri变量反映的是重写后/改变的URI(最终的)，不包括主机名。例如："/foo/bar.php?arg=baz" uri: 这个变量指当前的请求URI，不包括任何参数(见$args)。这个变量反映任何内部重定向或i...