介绍
本指南旨在为DigitalOcean教程的作者总结已确立的最佳实践和强有力的建议,旨在为DigitalOcean教程的一致性、技术正确性和易用性提供基础。
本指南本质上既是一个正在进行的工作,也是一份有意见的文件,基于内部技术作家和编辑,社区经理和工程师的日益增长的经验,其建议有可能发生变化,并专门为教育内容撰写,考虑到广泛的读者和最终用户。
软件来源和安装
许多教程将依赖现有教程作为先决条件. 将文章的所有先决条件(包括任何先决条件的先决条件)放入文章中,而不是有深切的先决条件列表。
最喜欢的来源
在粗糙的、下降的顺序下,最好使用以下安装机制:
许多项目迅速变化,建议超越官方存储库,但一些安装(如curlannoo bash模式)需要对是否使用它们进行判断
2 项目特定的包存库(例如,Nginx为当前的发行和发布提供了自己的存储库
3 语言特定的官方包裹(NPM、CPAN、PIP、RubyGems、Composer等)
4 项目特定的包存库(例如,Nginx为最新版本提供自己的存储库)或在Ubuntu上,一个值得信赖的PPA。确保这些来自一个值得信赖的来源,如项目的开发者或Debian/Ubuntu包裹维护者。
首选安装地点
一般来说,避免不必要的并发症. 对于从源或二进制软件安装的未包装软件,您通常应该接受默认安装前缀,除非它非常不寻常或引入冲突。
对于面向服务的软件,应提供符合官方发行建议的 init 脚本,如果不是由包或其他安装方法提供的。
在 Linux 系统中,将自包含的二进制文件或目录放入 /opt 和独立的脚本放入 /usr/local/bin。
软件和系统维护
Ubuntu 和 Debian 系统应该有未经监督的升级,至少安装和配置了安全更新,我们不建议自动重新启动或自动更新,考虑到背景。
我们一般建议在Ubuntu 18.04 和更高版本中使用apt命令。更改apt-get和apt-cache以使用apt。当更新 apt 命令时,不要使用-y旗;读者应该通过任何必要的输入和提示进行指导。
对于 CentOS 和 Rocky Linux 教程,我们现在建议使用dnf,它已经取代了yum,并提供更好的性能。
如果教程依赖于最新的更新,请在步骤 1 设置期间或根据需要拨打更新。首先拨打更新,以便您的服务器引导最新版本的软件包。当包括升级,该软件下载和安装每个软件包的新版本时,请注意一些用户可能会选择将某些软件包保留在更低版本中。
服务管理
例如,使用「sudo systemctl start [service_name]」即使「sudo service [service_name] start」會起動。
提供有关如何启用或禁用服务在启动时启动的信息,说明如何检查服务相关命令的结果,当接口不明确表示时(‘journalctl -u’、‘systemctl status’等)。
在大多数情况下,确保已知状态比避免分秒服务中断更重要,并且在完全服务故障的情况下重新启动也更有用。
Bootstrapping 系统
除非它是配置管理工作流的一部分,否则您可以选择用户数据脚本,并且在大多数情况下更愿意使用 cloudinit 脚本来混合用户数据中的脚本。
仓库和故障解决
解释在哪里以及如何访问已安装的服务日志。在适当的情况下,解释systemctl和journalctl命令来检查服务状态和日志输出。
确保处理日志旋转的任何情况下,它不是由包或其他安装机制处理。
若要跟踪单词日志文件,请使用尾巴 -F,而不是尾巴 -f,因为后者不会跟踪文件的姓名,如果日志在用户观看时旋转,可能会引起混淆。
用户与组管理
创建sudo用户,而不是直接使用root,请参考适当的初始服务器设置指南,这些指南将此任务解释为前提。
在基于 Debian 的发行版中,分别添加和删除使用者使用adduser sammy和deluser -remove-home sammy;在基于 RHEL 的发行版中,使用adduser sammy (必要时用passwd sammy设置密码)和userdel -r sammy。
现代版本使用usermod -aG wheel sammy,但某些版本需要visudo首先不评论wheel组权限。具体地说,在CentOS 5,sudo需要安装,和wheel**组需要未评论visudo;在CentOS 6,sudo已经安装,但wheel**需要未评论;CentOS 7有sudo和wheel**组已经设置。
若要通过sudo传输环境变量,请使用sudo -E command_to_run(如果信任整个环境)或sudo FOO=BAR command_to_run。对于需要根壳的实例,请使用sudo -i。
最喜欢的工具
对于交互式壳,假设在GNU/Linux系统上使用Bash,在相关情况下明确提到。
对于文本编辑器,我们包括使用 [偏好] 或您最喜欢的文本编辑器的副本,并在这些复制和粘贴的命令中包括以下初学者友好的编辑器。
对于文件传输,我们通常建议sftp在大多数情况下用于交互式和 scp 类似的用途,尽管它缺乏推功能,所以scp也是可以接受的。rsync对于备份和大型传输(或许多小文件)是有用的。在任何情况下不要使用 FTP。
在配备iproute2实用程序的机器上,我们更喜欢net-tools套件,这被认为是过时的(http://lartc.org/howto/lartc.iproute2.html)。一般来说,iproute2实用程序如ss将更好地支持多个接口,IPv6,新的内核功能等。
脚本
在系统管理教程的背景下,一般要避免长的自定义脚本和长的壳脚本。
作者撰写的脚本(以及可能的其他资源)应该生活在GitHub社区帐户的每篇文章存储库中,并链接到已发布的教程。 遵循良好的脚本实践一般。 例如,将用户需要填写的任何变量放在脚本的顶部,最好是在一个标记好的部分。 在需要提供可人读脚本的场合提供线上评论。 确保您的代码描述不是在评论中独家提供的,但您还提供比在评论中出现的进一步解释的散文描述。
使用 shell 和 coreutils/standard Unix 工具进行小任务;除非有实质性的好处,否则不要为粘贴语言的任务引入新的依赖性;选择#!/usr/bin/env interpreter到#!/path/to/interpreter。
一般来说,使用cron来安排重复任务,但系统d 计时器也是可以接受的。
文件系统位置
在可能的情况下,使用your_server_ip和your_domain代替文档 IP 范围或example.com。
在下载脚本或数据时,请确保用户位于可编写的目录中,或者路径被明确指定。对于应该可用于参考或重复使用的文件,请使用用户的主目录,除非它们属于文件系统其他地方的一些标准明确路径(如/opt或/etc).对于丢弃文件,请使用/tmp。
当教程依赖特定目录时,请确保在运行命令之前提供将读者路由到该目录的cd命令。
网站服务器
我们建议以 Debian 风格的配置目录用于默认方式不这样构建的发行版。 始终测试配置更改(Apache 使用 sudo apachectl configtest, Nginx 使用 sudo nginx -t)。
/var/www/html 应该作为所有 Web 服务器的文档根。
对于 Apache 或 Nginx 教程,使用专用的虚拟主机块,而不是编辑默认配置文件。
安全
加密和验证系统之间的所有连接,不要鼓励用户(明示或暗示)在清晰中发送凭证或传输非公开数据。
具体来说,密码和关键材料不应通过不受保护的连接传输,数据库连接、日志、集群管理和其他服务在任何时候都应该被加密。
基于 Web 的控制面板必须是 通过 HTTPS 连接提供服务,并且 TLS/SSL 应该用于支持的服务。 所有 Web 服务器都应该具有 HTTPS 功能(或至少能够)。 使用 certbot 提供 SSL 认证的先决条件。 允许使用普通 HTTP 等面向公众的服务,因为用户可能仍然想要或需要提供它们,但应该在一般情况下强烈阻止,特别是对于动态内容。 对于提供简单 HTTP 连接的文章,添加一个注释或警告标签来阻止普通 HTTP 并鼓励 HTTPS。
避免通过模糊或戏剧化构成低效安全的做法,例如更改默认SSH端口。 设置防火墙。 我们的分布特定的建议是Ubuntu的ufw,Debian的iptables,CentOS的firewalld。
SSH 的
保持默认 SSH 端口作为标准,只应在特定情况下进行端口更改,如果这是一个主要问题。
禁用密码身份验证,并使用只使用密钥的 root 身份验证,或替代使用 完全禁用 root 登录. 使用强大的 SSH 密钥:至少 2048 位 RSA 但建议 4096; ECDSA 不再推荐出于技术原因; Ed25519 和圆曲线算法不受广泛支持。
使用任何交互式密钥的密码语句,但不用于非交互式流程。设置或复制并将 SSH 密钥的所有权从根帐户更改到用户主目录。
请注意,虽然SSH Agent Forwarding对于CoreOS等平台的正常工作流程是必要的,但它带来了一些安全问题。
SSL 或 TLS
我们强烈鼓励使用 Let’s Encrypt 以便于使用,并建议使用 TLS. 使用强大的 SSL 安全性;请查看 https://cipherli.st/ (现代和传统推荐)。
对于没有域名的主机,我们建议使用足够强大的自签证书。再一次,请查看 https://cipherli.st/ 以及在 此 Nginx 自签证书指南 等指南中使用的自签证书创建。 在启用加密时,设置强大的 Diffie-Hellman 密钥,如在 Apache 上的自签 SSL 证书 和 Nginx。
VPN 的
我们建议VPN作为服务器之间的通用加密通信的解决方案。VPN在服务器之间需要保护多个服务时变得越来越有价值;而不是单独加密每个服务,所有内部通信都可以被导向VPN。
我们通常建议Tinc over OpenVPN用于服务器对服务器的通信,您可以阅读关于Ansible和Tinc的这篇文章(https://andsky.com/tech/tutorials/how-to-use-ansible-and-tinc-vpn-to-secure-your-server-infrastructure)以了解更多细节和实施。
结论
技术变化很快,我们在DigitalOcean尽力跟上,但如果你注意到任何错误或有反馈,我们将监视下面的评论。