蒲公英个人版 Docker 安装步骤

1. 下载蒲公英映像

$sudo docker pull bestoray/pgyvpn

2. 配置运行蒲公英容器

 $docker run -d --name pgy \
 --device=/dev/net/tun --net=host --cap-add=NET_ADMIN \
 --env PGY_USERNAME="Oray 用户名或 UID" --env PGY_PASSWORD="Oray 密码" \
 --restart always \
 bestoray/pgyvpn

如希望将日志存储在容器之外,可添加以下参数:

-v 本地路径:/var/log/oray 

如希望将配置存储在容器之外,可添加一下参数:

-v 本地路径:/etc/oray/pgyvpn 

3. 登录并使用蒲公英

3.1 进入蒲公英终端:

$sudo docker exec -it pgy /bin/bash

3.2 登录蒲公英:

#pgyvisitor login

3.3 启用自动登录:

#pgyvisitor autologin -y

Nginx 反向代理 Bitwarden 服务时登录提醒邮件 IP 地址为内网地址的解决方法

在使用 Nginx 方向代理 Bitwarden 服务时,Bitwarden 发送的新设备登录提醒邮件的 IP 地址会显示 172.x.x.x 这样的 Docker 容器的 IP 地址。这样显然不能达到安全提醒邮件的全部作用。

Your Bitwarden account was just logged into from a new device.
Date: Friday, August 13, 2021 at 7:45 PM UTC
IP Address: 172.20.0.1
Device Type: iOS
You can deauthorize all devices that have access to your account from the web vault under Settings → My Account → Deauthorize Sessions.

需要修改 bwdata/config.yml 文件,找到 real_ips,修改为:

real_ips:
- 172.16.0.0/12

保存后,运行 bitwarden.sh rebuild 、 bitwarden.sh start 重建并启动 Bitwarden 即可在提示邮件中显示正确的 IP 地址。

升级 Debian 10 后漏了 PHP 模块导致 Ulysses 无法发布 WordPress

由 Debian 9 升级到 Debian 10 后,PHP 也由 PHP 7.0 升级至 7.3 。升级过程中,PHP 7.3 并不会安装全部原先 7.0 安装的模块。因此导致诸如 Ulysses 等 App 无法通过 XML-RPC 发布文章。

在尝试用 curl 请求 xmlrpc.php 时发现以下错误:

<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
  <fault>
    <value>
      <struct>
        <member>
          <name>faultCode</name>
          <value><int>-32700</int></value>
        </member>
        <member>
          <name>faultString</name>
          <value><string>parse error. not well formed</string></value>
        </member>
      </struct>
    </value>
  </fault>
</methodResponse>

这才发现了问题,安装 php-xml 、 php-xmlrpc 模块后解决。

解决在 Debian 上使用 Unifi Controller 无法检查固件更新的问题

一直在 Debian 上使用 Unifi Controller 控制家中的 Unifi Wi-Fi 设备,打开了自动升级固件却从来没有提示过固件更新,手工点检查固件升级按钮也毫无反应。

之前以为是自动更新有延迟,就没有理睬,然后手工去更新设备,这次等了两周没更新,想看看是怎么回事,打开日志一看,原来有报错:

<webapi-109> WARN  fwupdate - unable to get update info for channel release:
javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
      at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) ~[?:1.8.0_212]

搜了一下,原来是 Debian 的 OpenJDK 11 的 cacerts 文件有问题,可以通过以下方式解决:

$ sudo rm /etc/ssl/certs/java/cacerts
$ sudo update-ca-certificates -f
$ sudo systemctl restart unifi

再次登录 Unifi Controller,立刻各种更新都开始提示了…

(转载)nginx 反向代理,Safari 无法访问网站的解决办法

今天在设置 nginx + apache2 时遇到 Safari 无法访问网站的问题,搜索到此解决方法,作者解释的非常详细,转载记录一下。

原文地址:http://www.ptbird.cn/nginx-apache-safari.html

原文标题:nginx 反向代理,safari 无法访问网站(HTTP/2.0 请求超时)的解决办法。

略微修改了部分格式。


昨天半夜 IOS 端开发者发现请求 API 无法拿到 response,一直是 timeout 。

排除了网络的原因,排除了客户端的原因,因为客户端请求其他的 API 都是成功的。


一、问题

iOS 开发使用 NSURLconnection 发送 HTTP POST 请求的时候,一直 timeout 。

继而发现 Safari 无法访问网站,但是 Chrome 和其他的浏览器都没有任何问题。

提前说一下,这个问题出现在 ngixn-1.9.0+/apache2.4 的反向代理上

我的服务器是 LANMP 组合的,其中 nginx 版本是 1.12.0,而 apache 的版本是 2.4


二、排查过程

1. 检查服务器通讯和网络原因

首先发现 iOS 端能够 ping 通服务器,但是新问题出现了 Safari 无法访问网站,同样的网站 Chrome 中能够访问。

2. 客户端排查

iOS 客户端开发者请求同样的 https API ,发现能够拿到 response,只有我的网站不行。

3. 网站系统排查

试了好几个 API 测试平台以及各种浏览器,发现都没有问题,最后发现:

苹果原生的应用 如 Safari,无论是 iOS 的 Safari 还是 macOS 的 Safari 都无法访问网站。

4. 排查 SSL 问题

因为我用的是 Let’s Encrypt 的 SSL 证书,因此测试了我其他使用 SSL 证书网站能否在 Safari 中打开, 发现都没问题。

5. 进一步排查网站系统

在排查过程中,发现当访问纯静态页面,如 https://www.demo.com/index2.html  的时候,没有任何问题,能够正常访问。

但是如果访问动态页面,如 https://www.demo.com/index2.php 的时候,都是错误的,也就是说 phpinfo() 都无法访问。

因此感觉问题可能出现在 nginx 或者是 apache 上。

6. 各种查资料

为此我在 segmentfault.com 上提问的问题也编辑了很多次,问清了 IOS 开发方面的一些概念后,最后确定了问题出现服务器方面。

所以在 stackoverflow 上各种关键字查,主要查的是

  • nginx
  • safari can not open website

在一个提问中发现,HTTP2 可能存在问题,因此我看了一下我的网站的 log,nginx.log 和 apache.log 我都配置了。

不看不知道,吓一跳:

demo.com_apache.log 中都是正常的 200 请求

demo.com_nginx.log 中也都正常,但是需要注意的是请求都是 HTTP/2.0 请求
访问一次网站,会出现好几十甚至一百次链接请求(这个我把日志清空后,访问一次,nginx 访问日志就出现了 N 多条),请求都是 200 的。

7. 确定了问题最终出现在 nginx 上面,而且是反向代理的问题。


三、解决

前后折腾了将近一天,最后在 stackoverflow 上找到了同样的问题,问题说:

Safari 因为使用 HTTP/2.0 请求而拿不到 response

问题地址: https://stackoverflow.com/questions/37762163/safari-fails-to-give-response-when-using-http-2

其中提到了我在别的问题中也看到的一个内容,已经有人在 nginx 中讨论过这个问题:

【”Upgrade” header should not be proxied over h2】

讨论地址:https://trac.nginx.org/nginx/ticket/915
隐藏 Nginx 的 Upgrade header

具体为什么,可以去 nginx 上的讨论看看,很详细。

操作:

修改 nginx proxy 配置中 proxy_hide_header 成 Upgrade

1
proxy_hide_header Upgrade

Debian 9 (Stretch) Apache 开启 HTTP/2

目前 Debian 9.5 默认的 Apache 版本已为 2.4.25,已直接支持 HTTP/2,开启 Apache 对 HTTP/2 的支持非常简单,步骤如下:

  1. 开启 HTTP/2 模块 1
    $sudo a2enmod http2
  2. 修改站点配置文件,增加 1
    Protocols h2 http/1.1
  3. 重启 apache1
    $sudo systemctl restart apache2

因 Debian 9 的 PHP 版本为 7.0,如开启 PHP,所 PHP 7.0 所需的 mpm_prefork 模块不支持 mod_http2,从而导致 Apache 的 HTTP/2 功能失效。如需开启 HTTP/2,可以等待 2019 年 Debian 10 发布后更新至更新版本的 PHP 或使用 nginx 来实现 HTTP/2 的支持。

–EOF–

鲁公网安备 37010202001399号 鲁ICP备18034499号-1