在上一篇博文（《Solid——简介与体验》）中，我简单介绍了Solid的一些基础概念以及体验它所可能遇到的障碍。在其中，我们提到了自行搭建Solid服务器这个选项——出于各种考虑，我们也许会倾向于自行搭建服务器。这篇文章以Solid Community Server为例介绍如何自行搭建Solid服务器。

Solid Community Server（简称为SCS或CSS）是Solid社区最新近构建的Solid服务器软件。其最主要的特点是更佳的模块化，以及更容易定制。大约正是因为这些原因，所以社区在尝试将以前更广泛使用的Node Solid Server（NSS）切换为CSS。CSS的定制化所依靠的是Components.js这个库，不过本文不需要涉及它的细节。

须知与结构

本文将介绍如何在一个Ubuntu 20.04服务器上搭建CSS，会涵盖从头开始到可以完整访问服务器。之所以提到服务器的具体发行版以及版本号，是因为两点： - CSS依赖于12.7版本以上的Node.js；而Ubuntu 20.04仓库中的node.js版本较低，是10.19，所以需要额外处理。 - 不同发行版的防火墙配置工具有所差异。 但原则上，除了这些以外，本文内容适合任何发行版。

由于Solid需要完整的URL以及HTTPS来正常工作，所以本文假设你拥有一个域名（假设叫DOMAIN.NAME），且服务器可以被公网正常访问。

本文主要内容（下一节）围绕搭建CSS服务器的具体步骤展开，主要分为四部分：

1. 构建及运行CSS服务器；
2. 设置Web服务器（Nginx）；
3. 联接Web服务器和CSS服务器（使用反向代理）；
4. 试用CSS的不同配置/默认App。

本文会介绍以及解释每一个步骤，以期不同环境配置的读者都可以用得上。在一些不重要的地方（比如使用Let's Encrypt获取证书过程中的具体回答），本文会介绍要点，但跳过细节。

搭建指导

搭建CSS本体

取决于你的倾向，你可以选择从npm仓库或从源代码构建CSS（参见官方文档）。本文选择从npm仓库安装CSS。

更新node.js版本

如前面所说，Ubuntu 20.04所带的node.js版本过低，我们需要更新node.js版本。我们选择使用NVM来管理它。

第一步：安装nvm（Node Version Manager）：

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash

第二步：加载nvm到你的shell中。你可以重启shell或者执行下面的命令：

export NVM_DIR="$([ -z "${XDG_CONFIG_HOME-}" ] && printf %s "${HOME}/.nvm" || printf %s "${XDG_CONFIG_HOME}/nvm")"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm

第三步：安装一个合适版本的node.js（本文使用16.13.2）

nvm install 16.13.2

安装CSS

第一步：从npm仓库下载CSS：

npm install @solid/community-server

该命令将所有依赖和软件安装到你当前的目录下（node_modules子目录）。取决于你的喜好，你也许会更喜欢加上-g参数来进行全局安装。

第二步：启动CSS来验证它是否正常工作：

npx community-solid-server

该命令会（从node_modules里）启动CSS，并服务在http://localhost:3000。建议访问该URL来验证它是否正常工作——你可以选择直接在服务器上访问，使用SSH隧道，或暴露服务器的3000端口然后从本地访问。如果使用SSH隧道，你可以执行下面的命令，然后在本地访问http://localhost:3000：

ssh -L 3000:localhost:3000 DOMAIN.NAME

注意，在浏览器上打开该URL后，会展示初始化页面。该步骤暂时不需要进行初始化，因为默认配置是将数据保存在内存中，所以你进行的初始化选项会在关闭服务器后丢失。

设置Web服务器（及SSL证书）

本部分没有什么特殊的，就是正常的配置nginx服务器以及（为HTTPS）获取SSL证书。如果你有经验，完全可以不参考本文的做法。但假如没有经验，本部分会让你明白每一步都在做什么，也许可以帮助你触类旁通。

安装nginx

apt-get update && apt-get install -nginx

记得回答y。

允许nginx服务的端口通过防火墙

ufw allow 'Nginx Full'

该步骤使用了Ubuntu特有的ufw命令来配置防火墙。

（可选）验证nginx是否正常工作

你可能会希望先检查一下nginx是否在正常工作，以便在出问题时更容易排查。

最简单的方法是修改/etc/nginx/sites-available/default中的服务器配置，并更新server_name的值为你的域名：

server_name DOMAIN.NAME;

然后重启nginx：

systemctl restart nginx

访问http://DOMAIN.NAME，看看你是否可以看到nginx默认的欢迎页面。

获取HTTPS所需的SSL证书

本文使用Let's Encrypt来获取证书。它的命令行程序名称叫做certbot，我们首先要安装它：

apt-get install certbot

然后，我们通过它获取证书。比如下面的命令会为DOMAIN.NAME和*.DOMAIN.NAME获取证书，并使用DNS考察（challenge）来验证你的确拥有该域名：

certbot -d DOMAIN.NAME -d *.DOMAIN.NAME --manual --preferred-challenges dns certonly

执行命令过程中，你会看到要做什么的提示：

1. 同意条款，以及提供一些基本信息。
2. 设置DNS TXT（文本）记录以通过DNS考察。你需要逐次添加两条记录——两条需要同时存在（DNS允许这种行为），不要用第二个覆盖第一个。

成功执行后，你会被分配对应证书。它们会位于/etc/letsencrypt/DOMAIN.NAME/。

如果你以前没有用过Let's Encrypt的话，需要注意一下证书的有效期。Let's Encrypt证书是免费的，自始至终都是这样（除非它们放弃了）。但它分配的证书只有90天的有效期，到期后需要我们自行重新获取。certbot有对应的命令以方便地重新获取，也可以设置计划任务（比如使用cron脚本）自动进行。网上对这些东西有很多说明，我就不再赘述了。

配置nginx使用HTTPS

现在需要配置nginx使用前面获取到的证书，以使得服务器可以接受HTTPS连接。这里使用Let's Encrypt提供的工具来自动修改nginx配置。

使用该工具需要先安装一个依赖：

apt-get install python3-certbot-nginx

然后执行下面的命令来自动更新nginx配置：

certbot --nginx -d DOMAIN.NAME -d *.DOMAIN.NAME

过程中注意按提示走。它会修改你在其间所指定的nginx配置。

如果你是全新安装且跟随了前面的教程，这里最好重启nginx，并可以检查HTTPS是否正常工作。

systemctl restart nginx

让Web服务器和CSS配合工作

想让Web服务器和CSS配合工作，需要分别配置两边：

1. 在Web服务器部分，设置反向代理至CSS（http://localhost:3000）；
2. 设置CSS接受来自代理的连接。

下面介绍如何在前述配置（nginx）下达成该工作。

设置反向代理

CSS官网给了如何在nginx设置反向代理的示例。其内容比较充实，下面的内容正是基于它。但这里不会全盘重写，有的地方仍然需要参照原文（主要是配置文件内容）。

这里假设你的服务器配置文件是/etc/nginx/sites-available/default。

CSS官网示例中的修改内容，核心是这两部分：

• upstream
• location / {

首先将upstream部分复制到你的服务器配置文件中，放在server{}部分之前即可（放在开头也一样）。

第二步是在server{}块之内找到location /这一部分。注意这里说的server{}块是指使用443端口（HTTPS默认端口）的那部分配置。然后将CSS官网示例中location /{}部分的内容复制到你的配置文件中，放在刚刚找到的部分。原来的location /{}部分应当是有内容的，替换掉它们即可。

这其实就已经完成了。示例中提到的/etc/nginx/snippets/https.conf文件似乎并不重要，因为它的绝大多数内容都已经在certbot自动配置的时候写好了（但写在certbot自己的文件下）。虽然实际上仍然有一小部分不在此列，但似乎并不影响。

现在可以访问https://DOMAIN.NAME来查看效果了，应当可以看到Solid的网页。

当然了，此时你应该会同时看到错误信息。这是正常现象，因为我们还需要执行下面这一部分。

修改CSS配置

前面的错误是因为CSS不接受所配置的反向代理传来的连接，因为它认为域名不匹配。我们需要在启动CSS时同时告诉它域名应当是谁。这需要通过-b（或者--basrUrl）参数实现：-b https://DOMAIN.NAME/。

同时，你也很可能会希望可以持久化你的数据，也就是将它们存在硬盘上而非内存中。要达成这个效果，你需要指定一个合适的配置文件，以及选择你要存储在的目录。例如，你可以使用-c @css:config/file.json -f ~/Documents/来告诉CSS载入它预制的config/file.json配置，并将文件（服务器设置和用户数据）存在~/Documents/目录下。实际上CSS预制了许多配置，拥有很强大的定制性。不过这些都是进阶使用和配置的部分了，本文就不详述了。

有了这些准备，我们可以停下/打断之前的CSS服务，然后使用下面的参数来再次启动它：

npx community-solid-server -b https://DOMAIN.NAME/ -c @css:config/file.json -f ~/Documents/

启动完毕后，从浏览器访问https://DOMAIN.NAME/，你应当看到正常的CSS初始化界面。这时候可以跟随它完成剩下的部分。这样，你的CSS就初始化好了，你也可以使用它了。

如果以后对用户数据或配置不满，或者是由于任何原因数据损坏，可以考虑删掉~/Documents/并重新初始化（不过希望你不会遇到这一天）。

配置不同的默认应用/界面

跟随上面的步骤，我们得到了一个正常运行的Solid服务器。但你应当也发现了，通过网页暂时没什么可做的，功能十分有限。这是因为CSS出于模块化的目的，只配备了最基础的功能——一个Solid服务器（以及初始化及注册账号）。但既然已经是一个Solid服务器了，那么你就可以使用任意的Solid Apps（应用）来管理和使用它了。

当然，你很可能会希望像 https://solidcommunity.net 等（使用NSS的）网站那样，给你的Solid服务器提供一个基本的交互界面（如它们所用的mashlib），或者说设置一个默认应用。

CSS开发者们也想到这点了，并且为此制作了一些配方，放在CSS配方仓库中。该仓库也包含了对应的指导，以协助你进行基本配置/使用。你可以跟随它们的说明，然后在启动服务器时调整参数，以和前面所用参数匹配。

例如使用mashlib的话，你可以使用下面的命令以启动（mashlib配方的）CSS：

npx community-solid-server -b https://DOMAIN.NAME/ -c config-mashlib.json -f ~/Documents/

启动完毕后，访问https://DOMAIN.NAME/应当会看到mashlib界面。这时候的体验应当就和 https://solidcommunity.net 很接近了。

注意，目前设计中，如果你在初始化完成后还想注册新用户，需要在「登录」界面点击「注册」，而不是直接在右上角点「注册一个Solid账号」（它会将你带到Solid官网的服务器列表页面）。当然，你也可以直接访问对应的URL：https://DOMAIN.NAME/idp/register/。注意其最后的斜线不能漏。

结语

本文介绍了如何自行搭建一个Solid Community Server（CSS）。它是Solid社区新近开发并打算切换为主力的服务器实现，最主要的优点是模块化和可定制性。由于它的模块化和定制性，它默认只有很简单的界面，所以本文也简单介绍了如何使用配方来提供默认应用。

总的来说，CSS的搭建并不复杂，主要是正常的Web服务器及反向代理配置；但CSS有自己的特点和选项，需要额外进行说明。

不过说到底，CSS只是一个Solid服务器。之所以自己搭建，是为了将数据更安全的存放，或是提供更方便的Solid服务。但如在《Solid——简介与体验》中介绍的那样，使用Solid的核心是Solid App（应用），搭建了服务器后仍然需要使用恰当的App。从这个角度看，服务器在哪并没有那么重要。