OpenStack Neutron手动安装：从内核参数到OVS流表的深度实践-尧图网络科技

1. 这不是“照着文档敲命令”，而是理解Neutron如何真正接管网络的起点

很多人看到“Neutron手动安装”第一反应是：又是一套复制粘贴的流水线操作，无非就是改改配置文件、跑跑脚本、重启几个服务。我带过十几期OpenStack实训课，几乎每届都有学员在完成这节实训后，面对一个真实部署的云环境时，连“为什么虚拟机ping不通外网”都查不出根源——不是不会用openstack server list，而是根本不知道Neutron的L2 Agent到底在哪个进程里、OVS桥上的流表是谁下发的、Linux内核里的rp_filter参数怎么悄无声息地把回包丢掉了。

这节实训的核心价值，从来就不是“装上Neutron”，而是亲手拆解一个SDN控制平面的最小可运行单元。你将从零开始，在一台干净的Ubuntu 22.04虚拟机上，不依赖DevStack、不调用packstack，只用apt、pip和文本编辑器，把Neutron Server、ML2插件、Open vSwitch Agent、DHCP Agent、L3 Agent这五个核心组件串起来，并让它们与Keystone完成真正的token校验交互。过程中你会被迫直面三个常被自动化脚本掩盖的真相：第一，Neutron Server启动失败90%以上源于数据库连接池超时或Keystone endpoint配置错了一个斜杠；第二，OVS Agent无法注册到Server，往往是因为/etc/neutron/plugins/ml2/ml2_conf.ini里mechanism_drivers写成了openvswitch,linuxbridge却没装对应驱动包；第三，外部网络配置失败，80%的根因藏在/proc/sys/net/ipv4/ip_forward和/proc/sys/net/ipv4/conf/all/rp_filter这两个内核参数里，而它们在系统重启后默认是关闭的。

关键词里虽然没写，但实操中你必须反复打交道的是：Linux内核参数（它决定数据包能否被转发）、Keystone（它不是个可选依赖，而是Neutron所有API调用的身份闸门）、OVS流表（它是Neutron网络策略落地的最终执行者）。这节实训的终点，不是systemctl status neutron-server显示active，而是你能用ovs-ofctl dump-flows br-int清晰读出某条流表规则对应的Neutron端口ID，并能解释为什么这条规则会匹配到某个虚拟机的ARP请求。如果你现在手边正开着一个终端，建议先别急着敲apt install neutron-server——我们先搞懂，当你按下回车那一刻，背后究竟有多少个进程、多少个配置项、多少个内核开关正在被悄然唤醒。

2. 环境准备：为什么Ubuntu 22.04是当前最稳妥的选择，以及那些被忽略的底层依赖

选择操作系统不是拍脑袋决定的。OpenStack Yoga版本（Neutron 20.0+）对Python 3.10有强依赖，而Ubuntu 22.04原生搭载Python 3.10.6，CentOS Stream 9虽也支持，但其systemd-networkd与Neutron L3 Agent的namespace网络管理存在已知冲突，会导致qrouter-xxx命名空间内的路由表无法正确注入。我实测过在Rocky Linux 8.8上部署，光是解决ip netns exec qrouter-xxx ip route返回空结果的问题，就耗掉整整两天排查时间——最后发现是NetworkManager服务劫持了lo接口的sysctl设置。所以，第一步必须锁定Ubuntu 22.04 LTS（内核5.15.0-xx-generic），这是整个实训稳定性的基石。

2.1 内核参数预置：不是“配完就完”，而是“配完要固化”

Neutron的L3 Agent需要在Linux内核层面启用IP转发和禁用反向路径过滤，否则即使OVS桥接正常，三层路由也会静默丢包。很多人只记得执行：

sudo sysctl -w net.ipv4.ip_forward=1 sudo sysctl -w net.ipv4.conf.all.rp_filter=0

但这只是临时生效。系统重启后，这些值会恢复为默认（ip_forward=0,rp_filter=1），导致云环境一夜之间“失联”。真正的做法是写入/etc/sysctl.conf并确保加载：

# 追加到 /etc/sysctl.conf 末尾 echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf echo "net.ipv4.conf.all.rp_filter = 0" | sudo tee -a /etc/sysctl.conf echo "net.ipv4.conf.default.rp_filter = 0" | sudo tee -a /etc/sysctl.conf # 立即应用并验证 sudo sysctl -p sudo sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter

提示：conf.default.rp_filter这一行常被遗漏。当新创建网络命名空间（如qrouter-xxx）时，内核会从default模板继承参数。若此处未设为0，该命名空间内的rp_filter仍为1，导致SNAT后的回包被丢弃——这是L3 Agent配置外部网络后虚拟机无法访问外网的最高频原因。

2.2 数据库与消息队列：MySQL 8.0.33+与RabbitMQ 3.11的兼容性陷阱

Neutron依赖数据库存储网络、子网、端口等资源状态，依赖消息队列实现Server与Agent间的异步通信。Ubuntu 22.04源默认提供MySQL 8.0.33，这很好，但必须注意MySQL 8.0的默认认证插件已从mysql_native_password改为caching_sha2_password，而Neutron 20.x的SQLAlchemy驱动尚未完全适配后者。若跳过此步，你会在neutron-server日志里看到大量Access denied for user 'neutron'@'localhost'错误，即使密码完全正确。

解决方案是创建用户时显式指定旧插件：

-- 登录MySQL后执行 CREATE USER 'neutron'@'localhost' IDENTIFIED WITH mysql_native_password BY 'NEUTRON_DBPASS'; GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'localhost'; FLUSH PRIVILEGES;

RabbitMQ方面，Ubuntu 22.04源提供3.11.13，需确认其rabbitmq_management插件已启用，因为Neutron Agent的健康检查会通过HTTP API查询队列状态：

sudo rabbitmq-plugins enable rabbitmq_management sudo systemctl restart rabbitmq-server # 验证：curl -u guest:guest http://127.0.0.1:15672/api/nodes

2.3 Python环境与Pip源：为什么不能直接`pip install neutron`

OpenStack组件对Python包版本极其敏感。例如oslo.config>=8.7.0,<9.0.0与stevedore>=4.0.0,<5.0.0之间存在传递依赖冲突。若直接pip install neutron，pip会尝试安装最新版，大概率触发pkg_resources.DistributionNotFound。正确做法是使用OpenStack官方发布的requirements文件：

# 克隆OpenStack Neutron仓库的stable/yoga分支 git clone -b stable/yoga https://opendev.org/openstack/neutron.git cd neutron # 安装项目级依赖（含精确版本约束） pip install -r requirements.txt # 再安装Neutron本身（此时版本已由requirements锁定） pip install -e .

注意：-e参数表示“开发模式安装”，它会将当前目录软链接到Python site-packages，后续修改代码可立即生效，这对调试Agent行为至关重要。很多学员跳过这步，用pip install neutron装完发现/usr/local/bin/neutron-server脚本缺失，就是因为标准安装不包含可执行入口点。

3. 核心组件安装与配置：从Neutron Server到OVS Agent的五层链路打通

Neutron不是一个单体服务，而是一个由Server（控制平面）、Plugin（业务逻辑）、Agent（数据平面）构成的分层架构。手动安装的本质，是把这五层像搭积木一样严丝合缝地拼接起来。我们按启动依赖顺序逐个击破。

3.1 Keystone对接：Token校验失败的97%都源于endpoint URL格式

Neutron Server启动的第一件事，就是向Keystone申请admin token以获取自身服务的endpoint信息。若此步失败，neutron-server进程会立即退出，日志里只有一行keystoneauth1.exceptions.auth_plugins.MissingAuthPlugin: An authentication plugin is required to fetch a token。这不是认证插件缺失，而是/etc/neutron/neutron.conf中[keystone_authtoken]段配置错误。

关键参数只有三个，但极易出错：

[keystone_authtoken] www_authenticate_uri = https://controller:5000 auth_url = https://controller:5000 memcached_servers = controller:11211 auth_type = password project_domain_name = Default user_domain_name = Default project_name = service username = neutron password = NEUTRON_PASS

致命细节：

www_authenticate_uri必须是https且端口为5000（Keystone的public端口），auth_url同理。若写成http://controller:35357（旧版admin端口）或漏掉s，Server会因SSL握手失败或连接拒绝而崩溃。
project_name必须是service，这是Keystone中为Neutron预创建的服务项目名。若误写为admin，Server会拿到admin token，但后续调用其他服务（如Nova）时因权限不足而失败。
memcached_servers地址必须可解析。若controller主机名未在/etc/hosts中映射到本机IP（如127.0.0.1 controller），token缓存将失效，导致每秒数百次重复认证，拖垮Keystone。

验证Keystone连通性的最简方法，不启动Neutron：

# 使用curl模拟token请求 curl -i \ -H "Content-Type: application/json" \ -d '{"auth": {"identity": {"methods": ["password"],"password": {"user": {"name": "neutron","domain": {"name": "Default"},"password": "NEUTRON_PASS"}}},"scope": {"project": {"name": "service","domain": {"name": "Default"}}}}}' \ https://controller:5000/v3/auth/tokens # 成功时返回HTTP 201及X-Subject-Token头

3.2 ML2插件配置：Mechanism Driver与Type Driver的协同逻辑

ML2（Modular Layer 2）是Neutron的主力插件，它通过Mechanism Driver（机制驱动）控制数据平面设备（如OVS），通过Type Driver（类型驱动）定义网络类型（如vxlan、vlan）。配置文件/etc/neutron/plugins/ml2/ml2_conf.ini是整个网络策略的中枢。

常见错误是混淆两者职责。例如，想用VXLAN网络，却只在[ml2]段启用type_drivers = vxlan，却忘了在[ml2_type_vxlan]段配置vni_ranges = 1001:2000。此时Neutron Server能启动，但创建网络时会报No network type driver found for 'vxlan'。

更隐蔽的坑在[ml2]的tenant_network_types：

[ml2] type_drivers = flat,vlan,vxlan tenant_network_types = vxlan mechanism_drivers = openvswitch,l2population extension_drivers = port_security,qos

tenant_network_types必须包含vxlan，否则租户网络只能创建flat/vlan，无法使用overlay网络。
mechanism_drivers若写成openvswitch,linuxbridge，则必须同时安装neutron-linuxbridge-agent包，否则OVS Agent会因找不到linuxbridge模块而注册失败。

3.3 OVS Agent：Bridge Mapping与物理网卡绑定的硬性约束

OVS Agent负责在计算节点上创建br-int（集成桥）、br-ex（外部桥）等OVS网桥，并将物理网卡（如ens33）绑定到br-ex。其配置文件/etc/neutron/plugins/ml2/openvswitch_agent.ini中，[ovs]段的bridge_mappings是成败关键：

[ovs] integration_bridge = br-int tunnel_bridge = br-tun local_ip = 10.0.0.101 # 控制节点的管理IP（用于VXLAN隧道） bridge_mappings = provider:br-ex

硬性约束：

local_ip必须是控制节点的管理网络IP（非127.0.0.1），因为VXLAN隧道需要此IP作为VTEP地址。若填错，br-tun桥无法建立隧道端口。
bridge_mappings格式为<provider_network_name>:<ovs_bridge_name>。provider是外部网络创建时指定的provider:physical_network值（如openstack network create --provider-network-type flat --provider-physical-network provider ext-net），br-ex是OVS上实际存在的网桥名。若二者不一致，虚拟机流量无法到达外部网络。

验证OVS Agent是否成功注册：

# 查看Neutron Server数据库中的agents表 mysql -uneutron -pNEUTRON_DBPASS neutron -e "SELECT binary,host,alive,configurations FROM agents WHERE binary='neutron-openvswitch-agent';" # 正常输出应为：neutron-openvswitch-agent,controller,1,{"bridge_mappings": "provider:br-ex", ...}

3.4 DHCP Agent：dnsmasq进程隔离与namespace网络的真相

DHCP Agent为租户网络提供IP地址分配服务。它并非直接在宿主机上运行dnsmasq，而是为每个子网创建独立的Linux网络命名空间（如qdhcp-xxx），并在其中启动dnsmasq。这意味着ps aux | grep dnsmasq看到的进程，其网络栈与宿主机完全隔离。

配置文件/etc/neutron/dhcp_agent.ini中，[DEFAULT]段的interface_driver必须与ML2插件匹配：

[DEFAULT] interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq enable_isolated_metadata = true

interface_driver若误设为neutron.agent.linux.interface.BridgeInterfaceDriver（对应Linux Bridge），而实际用OVS，则DHCP namespace内的qg-xxx端口无法创建，导致DHCP Offer包发不出去。
enable_isolated_metadata = true是必须的。它让DHCP响应中包含metadata server（169.254.169.254）的路由，否则虚拟机无法获取cloud-init配置。

3.5 L3 Agent：Router Namespace与Floating IP的NAT链路

L3 Agent实现三层路由和浮动IP（Floating IP）功能。它为每个路由器创建qrouter-xxx命名空间，并在其中配置IP地址、路由表和iptables规则。浮动IP的SNAT/DNAT规则就在此namespace内生效。

关键配置在/etc/neutron/l3_agent.ini：

[DEFAULT] interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver external_network_bridge = br-ex

external_network_bridge必须与OVS Agent的bridge_mappings中br-ex一致，否则qrouter-xxx内的qg-xxx端口无法接入外部网络。
若使用VXLAN网络，还需在[ovs]段添加agent_mode = dvr_snat（分布式虚拟路由），否则所有南北向流量都经控制节点集中转发，成为性能瓶颈。

验证L3 Agent工作状态：

# 进入router namespace查看路由和iptables sudo ip netns exec qrouter-<router_id> ip route sudo ip netns exec qrouter-<router_id> iptables -t nat -S # 应看到类似：-A POSTROUTING -s 10.0.1.0/24 -d 10.0.1.0/24 -j ACCEPT # 和：-A floatingip -d <floating_ip> -j DNAT --to-destination <fixed_ip>

4. 外部网络配置实战：从Flat网络到Floating IP的全链路验证

外部网络（External Network）是租户网络通往互联网的出口。手动配置它的难点不在命令本身，而在于理解每一层网络设备的职责边界。我们以最简单的Flat网络为例，走完从物理网卡绑定到浮动IP生效的完整链路。

4.1 物理网卡与OVS桥的绑定：为什么`ovs-vsctl add-port br-ex ens33`会失败

在控制节点上，需将物理网卡（如ens33）添加到br-ex网桥：

sudo ovs-vsctl add-port br-ex ens33

但此命令常失败，报错ovs-vsctl: no port named ens33。原因有二：

ens33已被NetworkManager或systemd-networkd接管，处于UP状态但未分配IP。OVS要求端口处于DOWN状态才能接管。
ens33已配置了IP地址（如192.168.100.101/24），OVS不允许在已有IP的接口上创建桥接。

正确流程：

# 1. 关闭网卡并清除IP sudo ip link set ens33 down sudo ip addr flush dev ens33 # 2. 将ens33添加为br-ex的端口 sudo ovs-vsctl add-port br-ex ens33 # 3. 为br-ex分配IP（原属于ens33的IP现在属于br-ex） sudo ip addr add 192.168.100.101/24 dev br-ex sudo ip link set br-ex up # 4. 添加默认路由（确保控制节点自身能访问外网） sudo ip route add default via 192.168.100.1 dev br-ex

注意：br-ex获得IP后，ens33接口不再有IP，所有流量经br-ex转发。这是OVS桥接的标准行为，也是浮动IP能工作的前提——外部流量先抵达br-ex，再由L3 Agent的qg-xxx端口接收并DNAT。

4.2 创建Provider网络与子网：`--provider:physical_network`的语义陷阱

创建外部网络时，命令如下：

openstack network create --share \ --provider-network-type flat \ --provider-physical-network provider \ --external \ ext-net

其中--provider-physical-network provider的provider，必须与OVS Agent配置文件中bridge_mappings = provider:br-ex的左侧key完全一致。若OVS Agent配的是physnet1:br-ex，此处就必须写--provider-physical-network physnet1，否则Neutron Server无法将网络映射到正确的OVS桥。

创建子网时，--no-dhcp是必须的，因为外部网络不提供DHCP服务：

openstack subnet create --network ext-net \ --allocation-pool start=192.168.100.200,end=192.168.100.250 \ --dns-nameserver 8.8.8.8 \ --gateway 192.168.100.1 \ --subnet-range 192.168.100.0/24 \ ext-subnet

4.3 路由器关联与浮动IP分配：`qrouter`namespace内的路由黑洞

创建路由器并关联内外网：

openstack router create router1 openstack router set --external-gateway ext-net router1 openstack router add subnet router1 private-subnet

此时，L3 Agent会在qrouter-<id>namespace内创建两个端口：

qr-xxx：连接租户网络（private-subnet），IP为子网网关（如10.0.1.1）
qg-xxx：连接外部网络（ext-net），IP从ext-subnet的allocation pool中分配（如192.168.100.200）

关键验证点：进入qrouternamespace，检查路由表：

sudo ip netns exec qrouter-<id> ip route # 正常输出应包含： # 10.0.1.0/24 dev qr-xxx proto kernel scope link src 10.0.1.1 # 192.168.100.0/24 dev qg-xxx proto kernel scope link src 192.168.100.200 # default via 192.168.100.1 dev qg-xxx

若缺少default via ...，说明L3 Agent未正确注入默认路由，浮动IP的SNAT将失效。

分配浮动IP：

openstack floating ip create ext-net openstack server add floating ip <server_id> <floating_ip>

此时，qrouternamespace内的iptables规则会自动添加DNAT：

sudo ip netns exec qrouter-<id> iptables -t nat -S floatingip | grep DNAT # 应看到：-A floatingip -d <floating_ip> -j DNAT --to-destination <fixed_ip>

4.4 端到端连通性测试：从虚拟机内部ping通外网的七步诊断法

当虚拟机无法ping通外网时，按以下顺序逐层排查（每步失败即定位问题层）：

虚拟机内部：ip a确认eth0获得租户网络IP（如10.0.1.10），ip route确认默认路由指向10.0.1.1（qr-xxx端口）。
租户网络：在控制节点，sudo ip netns exec qrouter-<id> ping 10.0.1.10，验证qr-xxx到虚拟机的二层连通性。
路由器内部：sudo ip netns exec qrouter-<id> ping 192.168.100.1（外部网关），验证qg-xxx到网关的连通性。
外部网络：ping 192.168.100.1（从控制节点宿主机），验证br-ex到网关的连通性。
浮动IP DNAT：sudo ip netns exec qrouter-<id> curl -I http://<floating_ip>，验证DNAT规则是否生效（应返回目标虚拟机的HTTP响应）。
反向路径过滤：sudo ip netns exec qrouter-<id> sysctl net.ipv4.conf.qg-xxx.rp_filter，必须为0，否则回包被丢弃。
OVS流表：sudo ovs-ofctl dump-flows br-int | grep "nw_dst=10.0.1.10"，确认有匹配虚拟机IP的流表，且actions包含output:<port_no>。

实操心得：第6步rp_filter是最高频的隐形杀手。很多教程只提all.rp_filter，却忽略qg-xxx端口的独立设置。qrouternamespace是独立的网络栈，其rp_filter值不继承自all，必须单独关闭：sudo ip netns exec qrouter-<id> sysctl -w net.ipv4.conf.qg-xxx.rp_filter=0。

5. 故障排查：从`neutron-server`日志到`ovs-ofctl`流表的深度追踪

当服务启动失败或功能异常时，日志是唯一真相来源。但Neutron日志分散在多个位置，需建立系统化排查路径。

5.1 日志层级与定位：`/var/log/neutron/`下的四类关键日志

Neutron各组件日志默认位于/var/log/neutron/，但内容侧重不同：

server.log：Neutron Server的REST API处理日志，记录所有HTTP请求、数据库操作、Keystone token校验结果。查找500错误、数据库连接失败、Keystone认证失败的首选。
openvswitch-agent.log：OVS Agent的日志，记录OVS网桥状态、端口创建、流表下发。排查虚拟机无法获取IP、网络不通的起点。
dhcp-agent.log：DHCP Agent日志，记录dnsmasq进程启停、DHCP Offer/ACK日志。虚拟机卡在DHCP获取阶段时必查。
l3-agent.log：L3 Agent日志，记录router namespace创建、IP地址分配、iptables规则更新。浮动IP不生效、路由丢失时的核心依据。

高效日志分析技巧：

使用journalctl实时跟踪：sudo journalctl -u neutron-server -f -o cat（-o cat去除时间戳，聚焦日志内容）。
搜索关键错误码：grep -i "error\|fail\|exception" /var/log/neutron/server.log | tail -20。
关联进程ID：日志中每行开头的[PID]，可用ps aux | grep <PID>确认进程归属。

5.2`neutron-server`启动失败的三大根因与修复

根因一：数据库连接池超时现象：server.log中反复出现sqlalchemy.exc.TimeoutError: QueuePool limit of size 5 overflow 10 reached。原因：MySQL连接数不足或Neutron配置的max_overflow过大。修复：

# 在 /etc/neutron/neutron.conf 的 [database] 段 max_retries = 10 retry_interval = 2 max_overflow = 5 # 降低至5，避免耗尽MySQL连接

根因二：Keystone endpoint不可达现象：server.log中keystoneauth1.exceptions.connection.ConnectFailure: Unable to establish connection to https://controller:5000/v3。原因：controller主机名未解析，或防火墙阻断5000端口。修复：

# 测试Keystone连通性 curl -k https://controller:5000/v3 # 若失败，检查 /etc/hosts 是否有 127.0.0.1 controller # 或临时关闭防火墙：sudo ufw disable

根因三：ML2插件配置语法错误现象：server.log中neutron.common.exceptions.InvalidInput: Invalid input for field/attribute mechanism_drivers。原因：ml2_conf.ini中mechanism_drivers值包含不存在的驱动（如openvswitch拼错为openvswtich）。修复：sudo ovs-vsctl show确认OVS已安装，dpkg -l | grep openvswitch确认openvswitch-switch包已安装。

5.3 OVS流表分析：读懂`ovs-ofctl dump-flows`的十六进制密码

OVS流表是Neutron网络策略的最终执行者。ovs-ofctl dump-flows br-int输出的每一行，都是一个匹配-动作规则。例如：

cookie=0x0, duration=3600.123s, table=0, n_packets=120, n_bytes=8640, priority=3,tcp,ip_src=10.0.1.10,tp_dst=22 actions=output:2

table=0：流表编号，Neutron主要使用table 0（匹配）、table 20（L2学习）、table 21（L3路由）。
priority=3：优先级，数值越大越优先匹配。priority=100的规则会覆盖priority=3。
tcp,ip_src=10.0.1.10,tp_dst=22：匹配条件，源IP为10.0.1.10且目的端口为22（SSH）。
actions=output:2：动作为输出到端口2，即虚拟机的tap设备。

关键诊断场景：

虚拟机无法获取DHCP：检查table 0是否有匹配udp,tp_dst=67的规则，actions是否为CONTROLLER（将DHCP请求发给Neutron Server）。
浮动IP不生效：检查br-ex上的流表，ovs-ofctl dump-flows br-ex | grep "nw_dst=<floating_ip>"，确认有actions=mod_nw_dst:<fixed_ip>,output:<port>规则。

5.4 Agent状态异常：`neutron agent-list`背后的数据库真相

openstack network agent list显示的Alive状态，来源于Neutron Server定期向Agent发送心跳请求。若显示False，不代表Agent进程已死，而是其上报的心跳时间戳超过agent_down_time阈值（默认30秒）。

深层排查步骤：

检查Agent进程是否存活：ps aux | grep neutron-openvswitch-agent。
检查Agent日志末尾是否有Starting periodic task字样，确认主循环已启动。
查询数据库确认最后心跳时间：
```
SELECT binary,host,created_at,started_at,heartbeat_timestamp,alive FROM agents WHERE binary='neutron-openvswitch-agent';
```
若heartbeat_timestamp为空或远早于当前时间，说明Agent未成功上报心跳，需检查/etc/neutron/plugins/ml2/openvswitch_agent.ini中[DEFAULT]的rpc_response_timeout是否过小（建议设为60）。

最后分享一个血泪教训：某次实训中，所有Agent状态均为False，但进程全部存活。排查三天后发现，是/etc/neutron/neutron.conf中[oslo_messaging_rabbit]的rabbit_ha_queues = true被误开启，而单节点RabbitMQ不支持HA队列，导致心跳消息无限重试直至超时。关闭此选项后，Agent瞬间全部变绿。这提醒我们：Agent状态异常，永远先查消息队列配置，而非日志。