Tomcat Web服务器配置与管理

本文集文档发布于灏天文库

4.1 Web 应用部署方式

文档摘要

4.1 Web 应用部署方式 第四章：Web 应用部署 4.1 Web 应用部署方式 4.1.1 复制部署 (Copy Deployment) 复制部署是最简单直接的部署方式，也被称为热部署或直接部署。它指的是将 Web 应用程序的文件（通常是 WAR 文件或展开后的 Web 应用目录）直接复制到 Tomcat 服务器的特定目录下，Tomcat 会自动检测并部署这些应用。 部署原理： Tomcat 服务器在启动或运行时，会定期扫描其配置的 Web 应用部署目录（默认情况下是 目录）。

4.1 Web 应用部署方式

第四章：Web 应用部署

4.1 Web 应用部署方式

4.1.1 复制部署 (Copy Deployment)

复制部署是最简单直接的部署方式，也被称为热部署或直接部署。它指的是将 Web 应用程序的文件（通常是 WAR 文件或展开后的 Web 应用目录）直接复制到 Tomcat 服务器的特定目录下，Tomcat 会自动检测并部署这些应用。

部署原理：

Tomcat 服务器在启动或运行时，会定期扫描其配置的 Web 应用部署目录（默认情况下是 CATALINA_HOME/webapps 目录）。当 Tomcat 检测到新的 WAR 文件或展开的 Web 应用目录时，它会自动执行以下操作：

  1. 解压 WAR 文件（如果部署的是 WAR 文件）： Tomcat 会将 WAR 文件解压缩到一个与 WAR 文件名相同的目录中。例如，如果部署 myapp.war，Tomcat 会在 webapps 目录下创建一个 myapp 目录，并将 WAR 文件内容解压到该目录。

  2. 创建 Web 应用上下文： Tomcat 会为新部署的应用创建一个 Web 应用上下文（Context）。Context 代表了 Tomcat 中运行的一个 Web 应用，它包含了应用的配置信息、资源以及 Servlet 容器。

  3. 加载和初始化 Servlet 和过滤器： Tomcat 会读取 Web 应用的 web.xml 部署描述符文件（或使用 Servlet 3.0+ 的注解配置），加载并初始化 Servlet、过滤器、监听器等组件。

  4. 启动 Web 应用： 完成初始化后，Tomcat 会启动 Web 应用，使其开始接受客户端请求。

部署步骤：

  1. 准备 Web 应用程序： 将开发完成的 Web 应用程序打包成 WAR 文件，或者准备好展开后的 Web 应用目录。

  2. 复制文件到部署目录： 将 WAR 文件或展开后的 Web 应用目录复制到 Tomcat 服务器的 CATALINA_HOME/webapps 目录下。

  3. 等待 Tomcat 自动部署： Tomcat 会定期扫描 webapps 目录，并自动部署新复制的应用。您可以在 Tomcat 的日志文件中查看部署进度和结果。

代码实践 (以部署 WAR 文件为例)：

假设我们有一个名为 mywebapp.war 的 Web 应用程序 WAR 文件。

  1. 确保 Tomcat 服务器正在运行。

  2. 打开文件管理器或命令行终端。

  3. 导航到 mywebapp.war 文件所在的目录。

  4. 复制 mywebapp.war 文件到 Tomcat 的 webapps 目录下。 例如，如果 Tomcat 安装在 /opt/tomcat，则目标目录为 /opt/tomcat/webapps。

    cp mywebapp.war /opt/tomcat/webapps/
​

  5. 查看 Tomcat 日志 (通常是 CATALINA_HOME/logs/catalina.out 或 CATALINA_HOME/logs/localhost.<日期>.log)，确认应用是否成功部署。 您应该能看到类似如下的日志信息：

    INFO: Deploying web application archive [/opt/tomcat/webapps/mywebapp.war]
...
INFO: Deployment of web application archive [/opt/tomcat/webapps/mywebapp.war] has finished in [XXX] ms
​

内容详解：

  • WAR 文件 vs. 展开的 Web 应用目录： 复制部署支持两种形式：WAR 文件和展开的 Web 应用目录。

    • WAR 文件 (Web Application Archive)： 是一个 JAR 归档文件，包含了 Web 应用的所有资源，例如 Servlet 类、JSP 文件、静态资源、配置文件等。WAR 文件是 Web 应用的标准打包格式，便于分发和部署。Tomcat 部署 WAR 文件时会自动解压。

    • 展开的 Web 应用目录： 指的是将 WAR 文件解压后得到的目录结构，包含了 WEB-INF 目录、JSP 文件、静态资源等。直接复制展开的目录也可以部署 Web 应用，Tomcat 会直接使用该目录作为 Web 应用的根目录。

  • 部署目录 webapps： webapps 是 Tomcat 默认的 Web 应用部署目录。您可以在 CATALINA_HOME/conf/server.xml 文件中配置 <Host> 元素的 appBase 属性来修改部署目录。

  • 自动部署： 复制部署是一种自动部署方式。Tomcat 会周期性地检查 webapps 目录，并自动部署新的应用。自动部署可以通过 CATALINA_HOME/conf/server.xml 文件中 <Host> 元素的 autoDeploy 属性来控制，默认值为 true，表示启用自动部署。

  • 热部署： 复制部署通常也被称为热部署，因为在大多数情况下，您无需重启 Tomcat 服务器即可完成应用的部署。Tomcat 会在后台完成部署过程，对正在运行的服务器影响较小。但需要注意的是，某些情况下（例如修改了 Tomcat 的全局配置文件），可能仍然需要重启 Tomcat 才能使更改生效。

  • 优点：

    • 简单易用： 复制部署是最简单的部署方式，操作便捷，无需复杂的配置。

    • 快速部署： 部署速度快，尤其对于小型应用或开发环境非常方便。

    • 热部署能力： 支持热部署，无需重启服务器即可部署应用。

  • 缺点：

    • 不适合大型生产环境： 对于大型生产环境，复制部署可能不够灵活和安全。例如，当需要进行灰度发布、版本回滚等操作时，复制部署操作较为繁琐。

    • 依赖文件系统权限： 复制部署依赖文件系统的权限，需要确保 Tomcat 进程对部署目录具有读写权限。

    • 管理性较弱： 相比于其他部署方式，复制部署的管理性较弱，例如，不容易进行应用的启停、版本管理等操作。

Mermaid 图 - 复制部署流程：

4.1.2 Tomcat Manager 应用部署

Tomcat Manager 应用是 Tomcat 自带的一个 Web 应用，提供了通过 Web 界面或命令行工具来管理和部署 Web 应用的功能。Manager 应用提供了比复制部署更丰富的管理功能，例如应用的启停、重新加载、卸载、会话管理等。

部署原理：

Tomcat Manager 应用通过 Tomcat 的管理 API 与服务器进行交互，实现 Web 应用的部署和管理。Manager 应用本身也是一个 Web 应用，默认部署在 /manager 上下文路径。

部署方式：

Tomcat Manager 应用支持多种部署方式，包括：

  1. Web 界面部署： 通过 Manager 应用提供的 Web 界面上传 WAR 文件或指定本地文件系统路径进行部署。

  2. 命令行部署 (使用 curl 或 wget 等工具)： 通过 HTTP 请求调用 Manager 应用的 API 进行部署。

  3. Ant 任务部署： 使用 Apache Ant 构建工具，通过 Tomcat Ant 任务插件调用 Manager 应用的 API 进行部署。

部署步骤 (以 Web 界面部署 WAR 文件为例)：

  1. 启用 Manager 应用访问 (如果尚未启用)： 默认情况下，Tomcat Manager 应用可能需要配置用户名和密码才能访问。您需要在 CATALINA_HOME/conf/tomcat-users.xml 文件中添加具有 manager-gui 或 manager-script 角色的用户。例如：

    <tomcat-users>
  <role rolename="manager-gui"/>
  <role rolename="manager-script"/>
  <user username="manager" password="password" roles="manager-gui,manager-script"/>
</tomcat-users>
​

    注意： 在生产环境中，请务必设置强密码，并根据安全策略限制 Manager 应用的访问权限。

  2. 访问 Manager 应用 Web 界面： 在浏览器中输入 http://<Tomcat服务器IP或域名>:<Tomcat端口>/manager/html，使用配置的用户名和密码登录。默认端口为 8080。

  3. 在 "Deploy" (部署) 部分，选择 "WAR file to deploy" (要部署的 WAR 文件)。

  4. 选择 "WAR file on your computer" (计算机上的 WAR 文件) 并点击 "Browse..." (浏览...) 按钮，选择要部署的 WAR 文件。 或者，您可以选择 "WAR file URL" (WAR 文件 URL) 并输入 WAR 文件的 URL 地址。

  5. 在 "Context Path" (上下文路径) 输入框中，输入要部署应用的上下文路径。 例如，输入 /myapp 将使应用部署在 http://<Tomcat服务器IP或域名>:<Tomcat端口>/myapp。 如果留空，则默认使用 WAR 文件名作为上下文路径（去除 .war 后缀）。

  6. 点击 "Deploy" (部署) 按钮开始部署。

  7. 部署完成后，您将在 "Applications" (应用) 列表中看到已部署的应用。 您可以点击应用的 "Start" (启动)、 "Stop" (停止)、 "Reload" (重新加载)、 "Undeploy" (卸载) 等按钮进行管理。

代码实践 (命令行部署 WAR 文件 - 使用 curl)：

假设我们要使用 curl 命令部署 mywebapp.war 文件到 Tomcat 服务器。

  1. 确保 Manager 应用已启用并配置了可用于脚本访问的用户 (例如，具有 manager-script 角色的用户)。

  2. 打开命令行终端。

  3. 使用 curl 命令发送 HTTP POST 请求到 Manager 应用的部署 API。

    curl --user 'manager:password' \
     --upload-file mywebapp.war \
     "http://localhost:8080/manager/text/deploy?path=/myapp"
​

    • --user 'manager:password': 指定用于身份验证的用户名和密码。替换 manager 和 password 为您在 tomcat-users.xml 中配置的用户名和密码。

    • --upload-file mywebapp.war: 指定要上传的 WAR 文件。

    • "http://localhost:8080/manager/text/deploy?path=/myapp": Manager 应用的部署 API 地址。path=/myapp 参数指定应用的上下文路径为 /myapp。

  4. 执行命令后，您将收到 Tomcat 服务器的响应。 如果部署成功，响应内容通常会包含 "OK - Deployed application at context path /myapp"。如果部署失败，响应内容会包含错误信息。

内容详解：

  • Manager 应用功能： Tomcat Manager 应用提供了丰富的 Web 应用管理功能，包括：

    • 部署 (Deploy)： 部署新的 Web 应用，支持 WAR 文件上传和本地路径指定。

    • 启动 (Start)： 启动已停止的 Web 应用。

    • 停止 (Stop)： 停止正在运行的 Web 应用。

    • 重新加载 (Reload)： 重新加载 Web 应用，通常用于在不重启整个 Tomcat 服务器的情况下更新应用。

    • 卸载 (Undeploy)： 卸载已部署的 Web 应用。

    • 会话管理 (Sessions)： 查看和管理 Web 应用的会话信息。

    • 应用列表 (List)： 显示当前已部署的应用列表及其状态。

    • 服务器信息 (Server Info)： 显示 Tomcat 服务器的版本、操作系统、JVM 信息等。

  • 安全配置： Tomcat Manager 应用提供了强大的管理功能，因此必须进行严格的安全配置，以防止未经授权的访问。主要的安全措施包括：

    • 用户认证： 配置用户名和密码，并为用户分配合适的角色 (manager-gui, manager-script)。

    • IP 地址限制： 通过 Tomcat 的 Valve 或防火墙等机制，限制可以访问 Manager 应用的客户端 IP 地址。

    • HTTPS 访问： 建议使用 HTTPS 加密协议访问 Manager 应用，保护用户名、密码和管理操作的安全性。

  • 优点：

    • 功能强大： 提供丰富的 Web 应用管理功能，方便进行应用的部署、启停、重新加载、卸载等操作。

    • 多种部署方式： 支持 Web 界面、命令行、Ant 任务等多种部署方式，灵活适应不同的使用场景。

    • 远程管理： 可以通过网络远程管理 Tomcat 服务器上的 Web 应用。

  • 缺点：

    • 安全风险： 如果 Manager 应用配置不当，可能会带来安全风险，例如被恶意用户利用进行攻击。

    • 需要额外配置： 使用 Manager 应用需要进行额外的配置，例如启用用户认证、配置角色等。

    • 依赖 Manager 应用本身： 部署过程依赖于 Manager 应用的正常运行，如果 Manager 应用出现故障，则无法进行部署操作。

Mermaid 图 - Manager 应用部署流程 (Web 界面部署 WAR 文件)：

4.1.3 自动部署 (Auto-Deployment)

自动部署是 Tomcat 的一个特性，它允许 Tomcat 在服务器运行时自动检测和部署新的 Web 应用或更新已部署的应用。复制部署实际上也是一种自动部署方式，但自动部署的概念更广泛，除了复制文件到 webapps 目录外，还可以通过其他方式触发自动部署。

部署原理：

Tomcat 的自动部署功能由 org.apache.catalina.startup.HostConfig 组件负责实现。HostConfig 组件会定期扫描配置的 Web 应用部署目录，并根据配置的策略自动部署或更新应用。

配置方式：

自动部署的主要配置参数位于 CATALINA_HOME/conf/server.xml 文件中 <Host> 元素的属性：

  • autoDeploy="true" (默认值)： 启用自动部署。当设置为 true 时，Tomcat 会定期扫描 appBase 目录（默认 webapps），并自动部署新的 WAR 文件、展开的 Web 应用目录或 Context XML 文件。

  • deployOnStartup="true" (默认值)： 在 Tomcat 服务器启动时执行部署操作。当设置为 true 时，Tomcat 在启动时会扫描 appBase 目录，并部署已存在的 Web 应用。

  • deployXML="true" (默认值)： 启用部署 Context XML 文件。当设置为 true 时，Tomcat 会扫描 appBase 目录及其子目录，查找 Context XML 文件（文件名通常为 <应用名>.xml 或 META-INF/context.xml），并根据 Context XML 文件中的配置部署 Web 应用。

  • unpackWARs="true" (默认值)： 启用自动解压 WAR 文件。当设置为 true 时，Tomcat 会自动解压部署的 WAR 文件。设置为 false 时，Tomcat 将直接从 WAR 文件运行 Web 应用，但性能通常会降低。

  • watchDir="${catalina.base}/conf/${hostName}" 和 watchEnabled="true"： 用于监控 Context XML 配置文件目录的变化。当 watchEnabled 为 true 时，Tomcat 会监控 watchDir 目录下的 Context XML 文件，并在文件发生变化时自动重新加载或部署应用。

部署触发方式：

除了复制文件到 webapps 目录触发自动部署外，以下操作也会触发自动部署：

  1. 服务器启动时： 当 deployOnStartup="true" 时，Tomcat 在启动时会扫描 appBase 目录并部署已存在的应用。

  2. Context XML 文件变化： 当 deployXML="true" 和 watchEnabled="true" 时，如果 Context XML 文件发生变化（例如修改、添加、删除），Tomcat 会自动重新加载或部署应用。

  3. 通过 Manager 应用部署： 使用 Tomcat Manager 应用部署 Web 应用时，实际上也是一种触发自动部署的方式。Manager 应用会调用 Tomcat 的管理 API，最终由 HostConfig 组件执行部署操作。

代码实践 (配置 autoDeploy 属性)：

  1. 打开 CATALINA_HOME/conf/server.xml 文件。

  2. 找到 <Host> 元素 (通常是 <Host name="localhost" appBase="webapps" ... >)。

  3. 修改 autoDeploy 属性的值。 例如，禁用自动部署，将 autoDeploy 设置为 false：

    <Host name="localhost"  appBase="webapps"
      unpackWARs="true" autoDeploy="false">
  ...
</Host>
​

  4. 保存 server.xml 文件并重启 Tomcat 服务器。

  5. 验证配置是否生效。 当 autoDeploy="false" 时，即使您复制新的 WAR 文件到 webapps 目录，Tomcat 也不会自动部署该应用，除非您手动触发部署 (例如，通过 Manager 应用)。

内容详解：

  • HostConfig 组件： HostConfig 是 Tomcat 中负责 Host 级别配置管理的组件，自动部署是其主要职责之一。HostConfig 组件会监听 Host 的生命周期事件，并在合适的时机执行部署操作。

  • 部署扫描周期： Tomcat 默认的部署扫描周期是 5 秒。这意味着 Tomcat 每隔 5 秒会检查 appBase 目录是否有新的应用需要部署或已部署的应用需要更新。扫描周期可以通过配置 Tomcat 内部的资源管理器来调整，但通常不需要修改默认值。

  • Context XML 部署与自动部署： 当 deployXML="true" 时，Tomcat 会自动检测和部署 Context XML 文件。Context XML 文件可以定义 Web 应用的上下文路径、文档根目录、资源、Realm、Valve 等配置信息。通过 Context XML 文件部署应用，可以实现更精细的部署配置。

  • 优点：

    • 自动化部署： 减少了手动部署的步骤，提高了部署效率。

    • 动态更新： 支持动态更新已部署的应用，例如，当 Context XML 文件或 Web 应用文件发生变化时，Tomcat 可以自动重新加载或部署应用。

    • 简化开发流程： 在开发环境中，自动部署可以简化开发流程，开发者只需将应用文件复制到部署目录，Tomcat 即可自动部署并运行应用。

  • 缺点：

    • 性能开销： 定期扫描部署目录会带来一定的性能开销，尤其是在部署目录文件较多时。

    • 可能引起意外重启： 如果配置不当，例如 watchEnabled="true" 且监控目录下的文件频繁变化，可能会导致 Web 应用频繁重新加载，影响应用稳定性。

    • 安全性考虑： 在生产环境中，自动部署可能需要谨慎使用，需要确保部署目录的安全性，防止未经授权的用户通过修改部署目录文件来部署恶意应用。

Mermaid 图 - 自动部署流程 (基于文件系统扫描)：

4.1.4 Context XML 部署

Context XML 部署是通过在 Tomcat 的配置文件中定义 Context XML 文件来部署 Web 应用的方式。Context XML 文件是一个 XML 格式的文件，用于描述 Web 应用的配置信息，包括上下文路径、文档根目录、资源、Realm、Valve 等。

部署原理：

Tomcat 在启动或自动部署过程中，会解析 Context XML 文件，并根据文件中的配置信息创建和配置 Web 应用的 Context。Context XML 文件提供了比复制部署和 Manager 应用更灵活和精细的部署配置方式。

部署方式：

Context XML 文件可以放置在以下两个位置：

  1. ${CATALINA_BASE}/conf/[enginename]/[hostname]/<应用名>.xml： 这种方式将 Context XML 文件放置在特定 Host 和 Engine 的配置目录下，文件名必须与应用名相同，并以 .xml 结尾。例如，对于 Host localhost 和应用名 myapp，Context XML 文件应放置在 ${CATALINA_BASE}/conf/Catalina/localhost/myapp.xml。

  2. ${CATALINA_BASE}/webapps/<应用名>/META-INF/context.xml： 这种方式将 Context XML 文件放置在 Web 应用的 WAR 文件或展开目录的 META-INF 目录下，文件名必须为 context.xml。这种方式将 Context 配置与 Web 应用打包在一起，更便于应用的迁移和分发。

部署步骤 (以第一种方式 - ${CATALINA_BASE}/conf/[enginename]/[hostname]/<应用名>.xml 为例)：

  1. 创建 Context XML 文件： 创建一个 XML 文件，文件名为 <应用名>.xml，例如 myapp.xml。文件内容需要符合 Tomcat Context XML 文件的格式。

  2. 配置 Context XML 文件： 在 Context XML 文件中配置 Web 应用的上下文路径、文档根目录等信息。例如：

    <?xml version="1.0" encoding="UTF-8"?>
<Context path="/myapp" docBase="/path/to/mywebapp" reloadable="true">
    <!-- 其他 Context 配置，例如资源、Realm、Valve 等 -->
</Context>
​

    • path="/myapp": 指定 Web 应用的上下文路径为 /myapp。

    • docBase="/path/to/mywebapp": 指定 Web 应用的文档根目录。需要替换 /path/to/mywebapp 为实际的 Web 应用目录路径。

    • reloadable="true": 启用自动重新加载。当 Web 应用的类或资源文件发生变化时，Tomcat 会自动重新加载应用。在开发环境中通常设置为 true，在生产环境中建议设置为 false 以提高性能和稳定性。

  3. 将 Context XML 文件放置到指定目录： 将创建的 myapp.xml 文件放置到 ${CATALINA_BASE}/conf/Catalina/localhost/ 目录下 (假设 Host name 为 localhost，Engine name 为 Catalina)。

  4. 将 Web 应用文件 (WAR 或展开目录) 放置到 docBase 属性指定的目录。 例如，如果 docBase 设置为 /path/to/mywebapp，则需要将 Web 应用的 WAR 文件或展开目录放置到 /path/to/mywebapp 目录下。

  5. 启动或重启 Tomcat 服务器。 Tomcat 会在启动时解析 Context XML 文件，并部署 Web 应用。

代码实践 (Context XML 文件示例 - ${CATALINA_BASE}/conf/Catalina/localhost/myapp.xml)：

假设 Web 应用目录位于 /opt/mywebapp，我们创建一个 Context XML 文件 myapp.xml 放在 ${CATALINA_BASE}/conf/Catalina/localhost/ 目录下，文件内容如下：

<?xml version="1.0" encoding="UTF-8"?>
<Context path="/myapp" docBase="/opt/mywebapp" reloadable="true">
    <Resource name="jdbc/mydb" auth="Container" type="javax.sql.DataSource"
              driverClassName="com.mysql.cj.jdbc.Driver"
              url="jdbc:mysql://localhost:3306/mydb?serverTimezone=UTC"
              username="dbuser" password="dbpassword"
              maxActive="20" maxIdle="10" maxWait="-1"/>
</Context>
​

内容详解：

  • Context XML 文件结构： Context XML 文件的根元素是 <Context>，它包含了一系列子元素和属性，用于配置 Web 应用的各个方面。常见的 Context XML 配置项包括：

    • path： Web 应用的上下文路径。

    • docBase： Web 应用的文档根目录，可以是 WAR 文件路径或展开目录路径。

    • reloadable： 是否启用自动重新加载。

    • <Resource>： 定义 JNDI 资源，例如数据源、邮件会话等。

    • <Realm>： 配置安全 Realm，用于用户认证和授权。

    • <Valve>： 配置 Valve，用于请求处理的拦截器和过滤器。

    • <Loader>： 配置类加载器。

    • <Manager>： 配置会话管理器。

    • <Parameter>： 定义 Web 应用初始化参数。

    • <Environment>： 定义环境变量。

  • Context XML 文件优先级： 当同一个 Web 应用同时存在 ${CATALINA_BASE}/conf/[enginename]/[hostname]/<应用名>.xml 和 ${CATALINA_BASE}/webapps/<应用名>/META-INF/context.xml 两种 Context XML 文件时，${CATALINA_BASE}/conf/[enginename]/[hostname]/<应用名>.xml 的优先级更高。

  • server.xml 中的 <Context> 元素： 除了独立的 Context XML 文件外，Context 配置也可以直接在 CATALINA_HOME/conf/server.xml 文件的 <Host> 元素中通过 <Context> 子元素进行配置。例如：

    <Host name="localhost"  appBase="webapps" ... >
    <Context path="/myapp" docBase="/opt/mywebapp" reloadable="true">
        <!-- Context 配置 -->
    </Context>
</Host>
​

    在 server.xml 中配置 <Context> 元素与独立的 Context XML 文件效果类似，但独立的 Context XML 文件更易于管理和维护。

  • 优点：

    • 配置灵活： Context XML 文件提供了非常灵活的 Web 应用配置方式，可以配置应用的各个方面，例如资源、安全、会话管理等。

    • 精细控制： 可以对每个 Web 应用进行精细的配置控制，满足复杂的部署需求。

    • 易于管理： 独立的 Context XML 文件更易于管理和维护，可以将配置与应用分离。

  • 缺点：

    • 配置复杂： Context XML 文件配置较为复杂，需要熟悉 Tomcat Context XML 文件的语法和配置项。

    • 部署步骤相对繁琐： 相比于复制部署，Context XML 部署步骤相对繁琐，需要创建和配置 XML 文件。

    • 学习成本较高： 需要一定的学习成本才能掌握 Context XML 部署方式。

Mermaid 图 - Context XML 部署流程：

4.1.5 JNDI Realm 部署 (简要介绍)

JNDI Realm 部署并非一种独立的 Web 应用部署方式，而是一种结合 JNDI (Java Naming and Directory Interface) 和 Realm (安全 Realm) 的高级部署配置。Realm 用于用户认证和授权，JNDI 提供了访问命名和目录服务的接口。通过 JNDI Realm，可以将用户认证信息存储在外部目录服务（例如 LDAP, Active Directory）中，实现集中式的用户管理和身份验证。

作者与出处
原作者： 灏天文库
来源：灏天文库
整理： 灏天文库整理
由灏天文库平台收录，内容或由平台用户上传，仅供学习交流
发布者: 作者: 灏天文库 转发
评论区 (0)
U
0/500