完整的提示信息为： ● 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

虽然 Apache 的 httpd 也可以做反向代理。 但是在效率和配置上确实不如 nginx，因此我们也将我们的反向代理服务换成了 nginx。 在选择版本的时候遇到了：到底是选择 Nginx 还是 Nginx Plus 的问题。 简单来说就是： Nginx Plus 相当于付费版本的 Nginx。 提供了更多的功能，针对企业需要的一些服务进行了优化。 有关功能的比较页面，请参考： Compare Models - NGINX 上面的内容。     结论 对于一般的网站，一天也就几千个 IP 的这种，用不用 Plus 都差不多。 对于复杂网站和自己的网站或者 API 已经有比较明显的性能问题的话，还是可以考虑使用官方 Plus 提供的相关服务的。   https://www.ossez.com/t/nginx-nginx-plus/13950

我们都知道，如果希望将 http 的访问自动切换到 https ，其实有多种方法可以去做。 比如说在 DNS 服务器上直接配置。 主要目的就是让网站只支持 https 的方法。 Nginx 的配置方法 在 Nginx 的虚拟主机配置文件中，只需要下面的 2 句话就可以了。 server { listen 80; server_name src.ossez.com; return 301 https://$host$request_uri; }     如上图的几句话就能够完成 http 到 https 的重定向了。 Listen 80： 这个定义的是将所有的 HTTP 80 端口的流量进行转换 Server_name _;：这个将会是针对所有的主机名，你也可以指定特定的主机名 Return 301:：这个告诉浏览器或者搜索引擎这个重定向是永久的重定向。 https://$host$request_uri: 这个参数配置的是重定向的的目标地址，如果你只是希望换行协议的话，就直接使用上面的配置就行。 https://www.ossez.com/t/nginx-http-https/13949

如果你的 IntelliJ IDEA 在调试的时候越来越慢，那么时候需要增加 IntelliJ IDEA 使用的内存了。 通过 Help | Edit Custom VM Options 路径来打开 VM 的选项。 IJ 将会使用自己的编辑器打开 .vmoptions 文件。 在这个文件中，你需要调整 -Xmx 参数，然后保存重启就可以了。 正常来说 IntelliJ IDEA 应该需要分配至少 4G 的内存。 如果你配置的参数不够的话，那么就增加这个内存配置。   https://www.ossez.com/t/intellij-idea/13947

Gitea 安装成功后，我们希望在部署 Gitea 网站上使用访问跟踪代码，或者其他的一些 JS 脚本的话，这个只能通过自定义模板来实现。 配置路径 首先需要访问 Gitea 的站点管理界面，然后找到 Custom File Root Path 配置属性。     然后的路径就是你需要设置模板的路径，然后在这个路径下面新建 2 个文件夹 templates/custom。 所以完整的路径为： /var/lib/gitea/custom/templates/custom 文件 创建一个 vi header.tmpl 一个文件，然后将需要使用的 JS 跟踪代码放置到这个文件中。 重启 然后重启 Gitea 服务就可以完成针对所有页面的跟踪代码插入了。 校验安装 在完成上面的步骤后，单击右键查看网站源代码。     如果能够看到插入的源代码，那就说明配置已经成功了。 https://www.ossez.com/t/gitea/13944