我们都知道 node_modules 文件夹中包含了大量的 node 需要的依赖库。 如果直接使用 Windows 的删除的话，非常耗时。 好在我们可以使用 node 自己提供的一个库来删除。 安装 rimraf rimraf 包的作用：以包的形式包装rm -rf 命令，就是用来删除文件和文件夹的，不管文件夹是否为空，都可以删除。 运行下面的命令来进行全局安装 rimraf npm install rimraf -g 进入需要清理的项目中，运行下面的命令： rimraf node_modules 就可以进行快速删除了。     上面的命令都是在命令行工具上执行的。   https://www.ossez.com/t/node-modules/13959

提示的错误信息为： javax.xml.bind.annotation does not exist     错误原因 这是因为针对这个老的项目，我们是使用 JDK 11 进行编译的。 但是 JDK 11 中已经没有： javax.xml.bind 这个包。 需要在 POM 的依赖中添加下面的内容： <dependency> <groupId>javax.xml.bind</groupId> <artifactId>jaxb-api</artifactId> <version>2.3.0</version> </dependency> <dependency> <groupId>com.sun.xml.bind</groupId> <artifactId>jaxb-core</artifactId> <version>2.3.0</version> </dependency> <dependency> <groupId>com.sun.xml.bind</groupId> <artifactId>jaxb-impl</artifactId> <version>2.3.0</version> </dependency>     添加上面的依赖到 POM 文件中就可以解决编译的错误了。   https://www.ossez.com/t/java-javax-xml-bind-annotation-does-not-exist/13958

完整的提示信息为： ● gitea.service - Gitea (Git with a cup of tea) Loaded: loaded (/etc/systemd/system/gitea.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Fri 2020-12-04 17:11:57 CET; 3s ago Process: 3443 ExecStart=/usr/local/bin/gitea web --config /etc/gitea/app.ini (code=exited, status=203/EXEC) Main PID: 3443 (code=exited, status=203/EXEC) 根据启动日志查看，应该是权限问题。     解决办法 解决办法是通过修改目标目录的目录的权限，然后重新启动就可以了。 运行的命令为： chown -R git:git /var/lib/gitea/ chown -R git:git /var/lib/gitea/ 在完成安装后，你可以使用下面的命令： chmod 750 /etc/gitea chmod 640 /etc/gitea/app.ini 来修改权限为不可写的权限。   https://www.ossez.com/t/gitea-code-exited-status-203-exec/13957

Nginx 的日志主要有 2 个，一个是 access.log， 一个是 error.log。 如果你不进行任何配置的话，这 2 个日志将会使用默认的日志配置，这个日志将会位于 /var/log/nginx 目录中。 针对虚拟主机的配置 如果你使用了 Nginx 为虚拟主机的话。 那么你可以在你的虚拟主机的配置文件中配置针对每一个特定的虚拟主机输出的日志路径。     例如我们针对虚拟主机的配置。 这样针对这个虚拟主机的所有访问将会把日志设置到你设定的文件中了。 同时我们也建议使用 /var/log/nginx/ 这个目录中。 因为有时候 SELinux 的配置可能会提示你的日志文件无法生成。   https://www.ossez.com/t/nginx/13956

我们都知道 Nginx 是常用的反向代理服务器。 但是什么是正向代理，什么是反向代理有时候概念好像不太好理解。 我们画了一个不好看的图来解释代理和反向代理     代理的理解 我们的简单理解就是这个代理是正向还是反向与代理服务器设置的位置有关。 这个代理服务器可能就是你计算机或者服务器上的进程。 正向代理 举例来说就是如果代理服务器离你很近，如果没有这个服务器你就没有办法访问网站，你必须要通过这个服务器才能访问所有的互联网资源的话，这个就是代理服务器。 比如说曾经的校园网，你没有办法直接通过校园网访问网络，你的所有访问必须要通过一个服务器转发后才能访问，那这个服务器就是正向代理服务器。 简单来说就是正向代理是为了客户服务的。 反向代理 反向代理更加靠近服务器一端。 反向代理等于在实际提供资源的服务器上提供一个屏障，所有外部的访问要获取服务器的资源之前，必须要通过这个反向代理才能获得这个服务器的资源。 对用户来说，就是如果不安装这个 反向代理服务器，用户还是可以任意访问互联网上的资源的。 简单来说就是反向代理是为服务器服务的。     结论 通常我们会为实际提供服务的服务器之前配置反向代理。 目前的反向代理服务器通常使用 Nginx，Apache 也是可以使用的，但 Apache 显得有点笨重，同时配置没有 Nginx 灵活，资源消耗更高。 我们也在逐步将反向代理服务器切换到 Nginx 上。   https://www.ossez.com/t/topic/13955

SSL 是目前网站的标配了，如果你还需要使用 Google 或者 Apple 的服务的话，你的网站要求必须使用 SSL。 Nginx 配置需要的文件 Niginx 配置需要 2 个文件。 Key 文件 Crt 文件 Key 文件是你自己生成的，或者使用 SSL 签发网站使用的 key 文件。 Crt 是 CA 机构根据你提供的 Key 文件通过校验后签发给你的，你需要将 Key 和 Crt 文件同时安装到的你的 Nginx 服务器上。 Nginx 配置路径 如果你为你的站点配置了虚拟服务器的话，那么你需要在你的虚拟服务器上有关 443 端口配置下面的内容： server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name src.ossez.com; client_max_body_size 500m; location / { proxy_pass http://localhost:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } ssl_certificate /etc/pki/tls/ossez_com/ossez_com.ca.crt; ssl_certificate_key /etc/pki/tls/ossez_com/ossez_com.key; ssl_session_cache shared:SSL:1m; ssl_session_timeout 10m; ssl_ciphers PROFILE=SYSTEM; ssl_prefer_server_ciphers on; } 在上面的内容中，我们可以看到了 2 个 文件的安装路径。 当然你也可以配置你自己的路径。 根据上面的说明，key 是你自己生成的文件，crt 是你收到 CA 为你签发的文件。 文件内容 如果你收到了 2 个 crt 文件，例如我们使用的签发机构为我们签发了： ca-bundel 和 crt 文件。 如下面图片中显示的内容。 在你将最后的 crt 部署到服务器上之前，你需要将 ca-bundel 和 crt 文件合并成一个 crt 文件。 简单来说就是将 crt 的内容添加到 ca-bundel 文件前面。 合并后的 crt 文件看起来和下面一样。     是一堆很长的秘钥，直接将这个文件替换掉 Nginx 配置 ssl_certificate 中指定的文件内容即可。 重启 Nginx 在完成上面配置后，重启 Nginx 服务器。 然后访问网站查看你的 SSL 的证书是否被配置正确了。     例如我们网站上面的签名信息。 如果你能通过浏览器看到所有的签名，就说明配置成功了。   https://www.ossez.com/t/nginx-ssl/13953

Apache 配置 SSL 需要 3 个文件。 Nginx 配置 SSL 只需要 2 个文件。 原因 这是因为 Nginx 将 Apache 配置需要的 3 个文件中的 2 个文件合并成一个文件了。 Apache Apache 配置需要的 3 个文件为： SSLCertificateKeyFile /etc/pki/tls/ossez_com/ossez_com.key SSLCertificateFile /etc/pki/tls/ossez_com/ossez_com.crt SSLCertificateChainFile /etc/pki/tls/ossez_com/ossez_com.ca.crt 如果上面的 Apache 配置参数的内容。 SSLCertificateKeyFile： 为我们自己创建的，这个被用于签发 CA SSLCertificateFile： 为 CA 为我们签发的一个 crt 文件 SSLCertificateChainFile： 为 CA 为我们签发的一个 STAR.ossez.com.ca-bundle 文件。 上面的图片中显示了我们对应的配置和文件。 Nginx Nginx 的配置为： ssl_certificate_key /etc/pki/tls/ossez_com/ossez_com.key; ssl_certificate /etc/pki/tls/ossez_com/ossez_com.ca.crt; ssl_certificate_key： 为我们自己创建的，这个被用于签发 CA ssl_certificate：为 CA 为我们签发的 crt 文件 从这里看到 Nginx 的配置少了文件，和 Apache 对比起来就是将 CA 签发给我们的 2 个文件 crt 和 ca-bundle 合并成一个 crt 文件就可以了。 这个文件名可以随便命名，但是为了方便和识别，我们使用 crt 为后缀。 合并方法是首先将 CA 签发的 crt 文件打开，然后将 ca-bundle 文件中的内容全部拷贝添加到 打开的 crt 文件后面。 这样结果就是你会得到一个很长的 crt 文件，然后将这个文件上传到服务器上，再重启服务器就可以了。 结论 本文对如何在 Apache 和 Nginx 中进行 SSL 签名文件的配置进行了说明。 如果按照文本的说明，你应该很容易就完成配置了。 https://www.ossez.com/t/nginx-apache-ssl/13954

如下图显示中的内容。     单击左侧最下部分的按钮可以对左侧的菜单进行折叠和展开。   https://www.ossez.com/t/wordpress/13952

在美国领事馆换发护照的时候，有一个美国居住地证明中的要求： 申请人最近一次出入美国境记录     上面的表述是：申请人最近一次出入美国境记录 这个是不准确的，其实领事馆要求的是历史记录的列表。 如下面图片显示的内容：     如果你按照最后一次出入境记录打印的话，可能领事馆会要求你重新补充材料。   https://www.usreio.com/t/topic/220

如果你只是正常的护照换发，看看官方的换发流程就足够了。 还是需要仔细阅读下上面的文章： 中华人民共和国驻纽约总领事馆-首页 其实很多流程已经简化很多了，最主要的是要下载中国领事 APP。 这个 APP 做得还可以，没有那么难用，基本上都能很流畅的把流程走完。 但是还是发现有几个小问题。     护照号码可能识别错误 在你使用 APP 识别护照的时候，护照号码中的数字 1 可能会被识别成字母 I。 你需要自己确认下护照号码是不是被识别正确了，这个应该是一个软件设计上面的 Bug。 回复信息链接问题 如果回复的消息中有链接的话，这个链接没有办法直接打开。 你可能需要一个字母一个字母的敲，这个有点麻烦。 其他来说这个 APP 都不错，能够非常方便和领事馆的工作人员沟通。 如果缺材料的话，直接按照上面的要求补充材料就可以了。 审核时间 根据每个人的情况不一样，现在的审核时间是 1 天左右。 有时候半天左右也能得到回复。 不得不说，确实方便了不少。   https://www.usreio.com/t/topic/219