S/MIME邮件加密

1、创建自签名证书

注意:在弹出对话框勾选“让我覆盖这些默认值”,设置邮箱地址和作为发件人的地址相同,否则在Mail App中无法加密

点击创建,按提示操作即可。完成后会在钥匙串>>我的证书 中多一个证书。

2、在钥匙串中找到新建的证书,然后右键》新建身份偏好设置,填写你的邮箱地址。实测新版的macOS加密不支持身份偏好设置,第一步的填写的邮箱地址和实际发件人地址必须相同。如果一直,可以省略身份偏好设置。

3、使用改邮箱发送邮件给对方,主题右侧的的签名为蓝色表示发送证书签名。小锁符号为灰色,暂时不可用。

4、对方重复1、2、3步

5、双方交换完证书,再次编写邮件时,小锁变成可用状态。

6、已知问题

macOS升级后 Mail app校验更严格,如果发件人地址和证书填写的邮箱地址如果不同,仅仅通过身份偏好设置进行绑定是不能发送加密邮件的。但是可以接收和解密邮件。其他客户端,如安卓邮件、iOS邮件、outlook等校验没那么严格,不一致也可以发送加密邮件。

7、导出证书供其他客户端使用

在钥匙串中,找到第一步我们新建的证书,右键》导出,下面以安卓和iOS自带邮件app为例讲一下如何设置。

8、安卓

打开邮件app,找到设置的齿轮,进入账户设置,点击需要设置的邮箱,找到服务器设置,找到S/MIME开关打开,S/MIME签名打开,点击安装证书,选择步骤7导出的证书文件。S/MIME加密同理。

9、iOS

将步骤7导出的证书通过隔空投送或者U盘、邮件的方式传到iOS设备,点击证书,然后找到通用》VPN与设备管理,找到证书点击进行安装。

安装完成后,邮件》账户,点开需要配置的账户,然后账户设置》高级,拉到最下方找到S/MIME,签名和加密都打开,并分别选择刚刚安装的证书。

10、类似步骤3和对方交换签名证书(公钥)

11、完成公钥证书交换后,发送邮件给对方时,会有蓝色小锁标志或显示已加密等字样。

Npm查看该包的所有版本及最新版本

以jquery为例

npm info jquery

查看npmjs服务器上包的版本信息:

使用npm view jquery versions;这种方式可以查看npm服务器上所有的jquery版本信息;

使用npm view jquery version; 这种方式只能查看jquery的最新的版本是哪一个;

使用npm info jquery ;这种方式和第一种类似,也可以查看jquery所有的版本,但是能查出更多的关于jquery的信息;

查看本地已经安装的包的版本信息:

npm ls jquery 即可(查看某个项目安装的jQuery),命令必须在某个项目下执行

npm ls jquery -g    (查看全局安装的jquery)

Gradle 国内阿里源

buildscript {

    repositories {

        maven { url ‘http://maven.aliyun.com/nexus/content/groups/public/’ }

        maven{ url ‘http://maven.aliyun.com/nexus/content/repositories/jcenter’}

        maven { url ‘http://maven.aliyun.com/repository/google’ }

        }

    dependencies {

        classpath ‘com.android.tools.build:gradle:3.2.1’

    }

}

allprojects {

    repositories {

        maven { url ‘http://maven.aliyun.com/nexus/content/groups/public/’ }

        maven{ url ‘http://maven.aliyun.com/nexus/content/repositories/jcenter’}

        maven { url ‘http://maven.aliyun.com/repository/google’ }

    }

}

iptables 端口转发

1、添加nat策略

此处将8080转到80端口,9000转到90

sudo iptables -t nat -I PREROUTING -p udp –dport 80 -j REDIRECT –to-ports 8080

sudo iptables -t nat -I PREROUTING -p udp –dport 90 -j REDIRECT –to-ports 9000

2、查看端口规则情况

sudo iptables -L -n -t nat –line-number

Chain PREROUTING (policy ACCEPT)

num  target     prot opt source               destination         

1    REDIRECT   17   —  0.0.0.0/0            0.0.0.0/0            udp dpt:90 redir ports 9000

2    REDIRECT   17   —  0.0.0.0/0            0.0.0.0/0            udp dpt:80 redir ports 8080

Chain INPUT (policy ACCEPT)

num  target     prot opt source               destination            

3、删除策略

#删除PREROUTING的第二条已添加规则,这里2代表第几行规则

#PREROUTING 对应 Chain类型,上面2标黄部分

sudo iptables -D PREROUTING 2 

Nginx Stream(TCP/UDP)负载均衡

Nginx 的 TCP/UDP 负载均衡是应用 Stream 代理模块(ngx_stream_proxy_module)和 Stream 上游模块(ngx_stream_upstream_module)实现的。Nginx 的 TCP 负载均衡与 LVS 都是四层负载均衡的应用,所不同的是,LVS 是被置于 Linux 内核中的,而 Nginx 是运行于用户层的,基于 Nginx 的 TCP 负载可以实现更灵活的用户访问管理和控制。

1TCP/UDP 负载均衡

Nginx 的 Stream 上游模块支持与 Nginx HTTP 上游模块一致的轮询(Round Robin)、哈希(Hash)及最少连接数(least_conn)负载均衡策略。Nginx 默认使用轮询负载均衡策略,配置样例如下:

stream {
    upstream backend {
        server 192.168.2.145:389 weight=5;
        server 192.168.2.159:389 weight=1;
        server 192.168.2.109:389 weight=1;
    }

server {
        listen 389;
        proxy_pass backend;
    }
}

哈希负载均衡策略可以通过客户端 IP($remote_addr)实现简单的会话保持,其可将同一 IP 客户端始终转发给同一台后端服务器。

配置样例如下:

stream {
    upstream backend {
        hash $remote_addr;
        server 192.168.2.145:389 weight=5;
        server 192.168.2.159:389 weight=1;
        server 192.168.2.109:389 weight=1;
    }

server {
        listen 389;
        proxy_pass backend;
    }
}

哈希负载均衡策略通过指令参数 consistent 设定是否开启一致性哈希负载均衡策略。Nginx 的一致性哈希负载均衡策略是采用 Ketama 一致性哈希算法,当后端服务器组中的服务器数量变化时,只会影响少部分客户端的请求。

配置样例如下:

stream {
    upstream backend {
        hash $remote_addr consistent;
        server 192.168.2.145:389 weight=5;
        server 192.168.2.159:389 weight=1;
        server 192.168.2.109:389 weight=1;
    }

server {
        listen 389;
        proxy_pass backend;
    }
}

最少连接负载均衡策略,可以在后端被代理服务器性能不均时,在考虑上游服务器组中各服务器权重的前提下,将客户端连接分配给活跃连接最少的被代理服务器,从而有效提高处理性能高的被代理服务器的使用率。

配置样例如下:

stream {
    upstream backend {
        least_conn;
        server 192.168.2.145:389 weight=5;
        server 192.168.2.159:389 weight=1;
        server 192.168.2.109:389 weight=1;
    }

server {
        listen 389;
        proxy_pass backend;
    }
}

2TCP/UDP 负载均衡的容错机制

Nginx 的 TCP/UDP 负载均衡在连接分配时也支持被动健康检测模式,如果与后端服务器建立连接失败,并在 fail_timeout 参数的时间内连续超过 max_fails 参数设置的次数,Nginx 就会将该服务器置为不可用状态,并且在 fail_timeout 参数的时间内不再给该服务器分配连接。当 fail_timeout 参数的时间结束时将尝试分配连接检测该服务器是否恢复,如果可以建立连接,则判定为恢复。

配置样例如下:

stream {
    upstream backend {
        # 10s内出现3次错误,该服务器将被熔断10s
        server 192.168.2.154:8080 max_fails=3 fail_timeout=10s;
        server 192.168.2.109:8080 max_fails=3 fail_timeout=10s;
        server 192.168.2.108:8080 max_fails=3 fail_timeout=10s;
        server 192.168.2.107:8080 max_fails=3 fail_timeout=10s;
    }

server {
        proxy_connect_timeout 5s;           # 与被代理服务器建立连接的超时时间为5s
        proxy_timeout 10s;          # 获取被代理服务器的响应最大超时时间为10s

# 当被代理的服务器返回错误或超时时,将未返回响应的客户端连接请求传递给upstream中的下
        # 一个服务器
        proxy_next_upstream on;
        proxy_next_upstream_tries 3;        # 转发尝试请求最多3次
        proxy_next_upstream_timeout 10s;    # 总尝试超时时间为10s
        proxy_socket_keepalive on;  # 开启SO_KEEPALIVE选项进行心跳检测
        proxy_pass backend;
    }
}

其中的参数及指令说明如下。

  • 指令值参数 max_fails 是指 10s 内 Nginx 分配给当前服务器的连接失败次数累加值,每 10s 会重置为 0;
  • 指令值参数 fail_timeout 既是失败计数的最大时间,又是服务器被置为失败状态的熔断时间,超过这个时间将再次被分配连接;
  • 指令 proxy_connect_timeout 或 proxy_timeout 为超时状态时,都会触发 proxy_next_upstream 机制;
  • proxy_next_upstream 是 Nginx 下提高连接成功率的机制,当被代理服务器返回错误或超时时,将尝试转发给下一个可用的被代理服务器;
  • 指令 proxy_next_upstream_tries 的指令值次数包括第一次转发请求的次数。

TCP 连接在接收到关闭连接通知前将一直保持连接,当 Nginx 与被代理服务器的两个连续成功的读或写操作的最大间隔时间超过 proxy_timeout 指令配置的时间时,连接将会被关闭。在 TCP 长连接的场景中,应适当调整 proxy_timeout 的设置,同时关注系统内核 SO_KEEPALIVE 选项的配置,可以防止过早地断开连接。