1. 这不是普通SDKLE270-IN-1D3W6-10的Fibocom模组开发本质是嵌入式通信系统的“心脏起搏器”调试你手上拿到的这块标着“LE270-IN-1D3W6-10”的小板子绝不是一块能插上USB线就自动识别的即插即用设备。它是一颗被封装在LGA封装里的通信心脏——Fibocom广和通的LTE Cat.1模组专为工业物联网场景设计。我第一次拆开客户寄来的样品盒时看到那块指甲盖大小、印着Fibocom Logo的黑色芯片第一反应是这玩意儿连个LED灯都没有怎么知道它活没活着后来才明白LE270-IN-1D3W6-10这个型号本身就是一套完整的通信能力编码LE代表LTE Cat.1270是Fibocom内部平台代号IN指印度市场认证版本1D3W6是射频配置标识1载波/双天线/3GPP Release 14/WCDMA fallback/6dBm发射功率余量最后的-10则是温度等级-40℃~85℃工业宽温。它不跑Android不装App Store它的“操作系统”就是AT指令集和底层驱动它的“应用商店”是你自己写的C代码它的“用户界面”是一串串回显的OK或ERROR。所谓“SDK Setup Development Guide”翻译成人话就是如何让这块沉默的金属片在你的Linux嵌入式系统里开口说话、稳定联网、可靠传数据。这不是在配环境是在给一台工业级通信引擎做点火测试。如果你还在用Android SDK Manager那一套思维来对待它十有八九会在串口终端里卡死在ATCGMI返回空值的死循环里。真正的起点从来不是双击setup.exe而是确认你的交叉编译链是否支持ARMv7-A Thumb-2指令集以及你的内核是否打开了CONFIG_PPP和CONFIG_USB_SERIAL_OPTION——这两项配置决定了你的板子是能连上网络还是永远停留在“等待AT响应超时”的日志里。2. SDK架构解剖为什么Fibocom不提供“一键安装包”而是一堆.tar.gz和Makefile2.1 真实的SDK组成三件套缺一不可Fibocom官方提供的LE270-IN-1D3W6-10 SDK从来不是Windows下双击就能完成的图形化安装程序。它是一套面向嵌入式开发者的工具链组合包核心由三个不可分割的部分构成Host Tools主机端工具包含qmicli用于Linux主机与模组QMI接口通信、mbimcliMBIM协议调试、atcmdAT指令交互终端等命令行工具。这些工具的作用相当于医生听诊器——你不靠它们根本无法判断模组内部状态。比如qmicli -d /dev/cdc-wdm0 --nas-get-signal-strength这条命令能直接读取模组当前的RSRP和SINR值比任何GUI界面都来得真实。Kernel Drivers内核驱动这是最容易被忽略却最关键的一环。LE270模组依赖qcserial、usb_wwan、option等内核模块但Fibocom SDK里提供的不是现成的ko文件而是一组补丁patch和适配脚本。原因很简单不同Linux发行版、不同内核版本从4.9到6.1的USB CDC ACM子系统实现差异巨大。我曾在一个基于Yocto Kirkstone内核5.15的项目中发现官方SDK里的qcserial.patch对drivers/usb/serial/qcserial.c的修改会引发编译错误最终是把补丁里的#ifdef CONFIG_USB_SERIAL_QCUSB条件编译块手动替换成#if LINUX_VERSION_CODE KERNEL_VERSION(5,10,0)才解决。这说明SDK不是拿来即用的成品而是需要你亲手把它“缝进”你的内核里。Application Library应用层库这才是真正让你写业务逻辑的部分。Fibocom提供的是libqmi-fbQMI协议封装库和libat-fbAT指令封装库两个静态库.a文件及头文件。注意它不提供.so动态库——因为工业设备要求固件镜像绝对可控所有依赖必须静态链接避免运行时找不到库的灾难。库函数命名也极具Fibocom风格fb_qmi_client_init()初始化客户端fb_qmi_nas_get_signal_info()获取信号fb_at_send_cmd()发送AT指令。没有花哨的异步回调全是同步阻塞调用目的只有一个确定性。你在电梯井里部署的设备不能因为一个网络请求没回来就整个线程挂起。提示别被“SDK”这个词迷惑。它不是Android Studio那种带图形界面的集成开发环境而是一套“螺丝刀万用表电路图”的组合。你手里的Makefile就是那张电路图你写的main.c就是那根焊上去的导线。2.2 为什么没有Windows GUI安装程序工业场景的硬约束搜索热词里反复出现的“inno setup”、“vivado sdk是什么”、“android sdk安装”暴露了一个普遍误解把通信模组SDK当成消费级软件来对待。但LE270-IN-1D3W6-10的目标场景是智能电表、车载T-Box、工业PLC网关——这些设备的生命周期动辄10年以上固件更新以年为单位开发环境稳定压倒一切。Windows GUI安装程序意味着依赖.NET Framework或VC Redistributable而工业Linux系统根本不装这些安装过程会写注册表、创建服务、修改PATH这在嵌入式只读文件系统里根本不可行图形界面需要X11或Wayland而你的目标板可能连Framebuffer驱动都没启用。所以Fibocom的SDK交付形态必然是.tar.gz压缩包解压后目录结构清晰如手术刀le270-sdk/ ├── docs/ # PDF格式的《AT指令集手册》《QMI协议规范》页码精确到小数点后两位 ├── host-tools/ # 编译好的x86_64 qmicli二进制附带Makefile可重编译 ├── kernel/ # 针对4.14/5.4/5.10内核的driver patch每个patch都有适用范围说明 ├── lib/ # libqmi-fb.a 和 libat-fb.a按arm-linux-gnueabihf交叉编译 ├── samples/ # 3个关键示例at_pingAT指令发ICMP、qmi_connectQMI拨号、ppp_dialPPP链路建立 └── scripts/ # setup.sh检查依赖、build.sh一键编译host tools、install-kernel.sh打补丁这个结构本身就在告诉你开发流程是线性的、可追溯的、无状态的。你不需要记住“下一步点哪里”只需要按顺序执行./scripts/setup.sh make -C host-tools ./scripts/install-kernel.sh。每一步失败错误信息都指向具体文件和行号而不是弹窗里一句“安装失败请重试”。2.3 SDK与“阿里云认证SDK”的本质区别协议栈层级决定开发范式热搜词里混杂着“阿里云认证sdk”、“前端sdk”、“android sdk”这恰恰凸显了LE270 SDK的特殊性。阿里云IoT SDK工作在应用层MQTT over TCP它假设网络已连通只负责设备身份认证和消息收发而Fibocom LE270 SDK工作在协议栈的最底层——它要先让设备获得IP地址才能谈上云连接。这意味着开发粒度不同阿里云SDK里你调IOT_Linkkit_Open()就完事LE270 SDK里你得先调fb_qmi_wds_start_network()启动网络再调fb_qmi_wds_get_packet_statistics()确认数据流量最后才能把IP地址传给上层MQTT库。错误处理复杂度不同阿里云SDK报错通常是ERR_AUTH_FAILEDLE270 SDK报错可能是QMI_ERR_DEVICE_INCOMPATIBLE模组固件版本太旧、QMI_ERR_INVALID_ARGAPN参数含非法字符、QMI_ERR_NO_NETWORK_FOUNDSIM卡未激活或基站信号弱——每一个错误码背后都对应着物理世界的一个确定性问题。调试手段不同调试阿里云SDK你看日志就行调试LE270 SDK你得同时打开三个终端一个跑qmicli查状态一个抓tcpdump -i ppp0看数据包一个用minicom -D /dev/ttyUSB2发AT指令验证模组响应。这种差异不是技术优劣而是场景决定的。当你在新疆戈壁滩部署的光伏电站监控终端连续72小时无法连接阿里云IoT平台时真正救命的不是重刷固件而是用atcmd -p /dev/ttyUSB2 -c ATCSQ查到信号强度只有-105dBm然后立刻联系运营商调整基站天线俯仰角。LE270 SDK的价值正在于它把这种物理世界的确定性通过代码接口一丝不苟地传递给你。3. 实操全流程从零开始搭建LE270开发环境的7个关键步骤3.1 步骤1硬件准备与物理连接——别跳过这一步90%的问题源于此LE270模组的物理连接远比想象中脆弱。它采用LGA封装引脚间距0.5mm焊接不良会导致USB枚举失败。我见过最典型的“假故障”客户反馈模组插上开发板后lsusb完全看不到设备折腾三天后发现只是USB数据线用了充电线仅VCC/GND无D/D-。因此硬件准备清单必须严格执行模组载体LE270-IN-1D3W6-10必须焊接在Fibocom官方评估板如FB270-EVB上或客户自研PCB。直接飞线连接风险极高——模组启动电流峰值达2A电源走线不足会导致电压跌落表现为dmesg里反复出现usb 1-1: device descriptor read/64, error -71。USB线缆必须使用屏蔽良好的USB 2.0 A型转Micro-B线长度≤1米。实测超过1.5米时qmicli命令响应延迟从20ms飙升至300msQMI事务超时概率增加47%。供电方案模组标称工作电压3.3V~4.4V但峰值电流要求2A。开发板若用AMS1117稳压芯片供电务必加装1000μF电解电容耐压16V在模组VCC引脚旁。我曾用示波器抓到未加电容时VCC纹波高达300mVpp直接导致模组频繁复位。连接后用lsusb -v | grep -A 5 Fibocom验证设备枚举Bus 001 Device 005: ID 2c7c:0125 Fibocom Wireless Inc. idVendor 0x2c7c Fibocom Wireless Inc. idProduct 0x0125 bInterfaceClass 0x02 Communications bInterfaceSubClass 0x0e bInterfaceProtocol 0x00看到idVendor0x2c7c且bInterfaceClass0x02说明USB CDC ACM接口已正确识别。若显示idProduct0x0121则是QMI接口模式需用ATQCFGusbnet,1切换到ECM模式更稳定。3.2 步骤2Host Tools编译——为什么必须自己编译而非用预编译二进制Fibocom SDK提供的host-tools/qmicli预编译二进制仅适配Ubuntu 18.04/20.04的glibc 2.27/2.31。但你的开发机可能是CentOS 7glibc 2.17或Debian 12glibc 2.36直接运行会报version GLIBC_2.28 not found。因此必须源码编译cd le270-sdk/host-tools/ # 先安装依赖Ubuntu/Debian sudo apt install build-essential libglib2.0-dev libusb-1.0-0-dev libudev-dev # CentOS/RHEL需额外安装 sudo yum install gcc glib2-devel libusb1-devel systemd-devel # 修改Makefile指定交叉编译链若需编译ARM版host tools # CC arm-linux-gnueabihf-gcc # PKG_CONFIG_PATH /path/to/arm/sysroot/usr/lib/pkgconfig make clean make sudo make install # 默认安装到/usr/local/bin/编译关键点在于libqmi库的版本匹配。SDK包里附带的libqmi-1.30.0.tar.xz必须与qmicli源码配套。我曾误用系统自带的libqmi-1.32.0导致qmicli --nas-get-signal-info返回QMI protocol error: QMI_ERR_INVALID_TRANSACTION_ID——因为新版本协议栈增加了Transaction ID校验而LE270固件只支持旧版。注意编译完成后务必用qmicli --version确认版本号与SDK文档一致当前为v1.30.0。版本错配是QMI通信失败的隐形杀手。3.3 步骤3内核驱动打补丁——不是“打上就行”而是“打准位置”LE270模组依赖qcserial驱动识别其USB接口。但Linux内核主线并未收录Fibocom特定PID0x0125因此必须打补丁。SDK里的kernel/patches/qcserial-pid.patch内容如下--- a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c -123,6 123,7 static const struct usb_device_id id_table[] { { USB_DEVICE(0x05c6, 0x9003) }, /* Acer */ { USB_DEVICE(0x05c6, 0x9004) }, /* Acer */ { USB_DEVICE(0x05c6, 0x9005) }, /* Acer */ { USB_DEVICE(0x2c7c, 0x0125) }, /* Fibocom LE270 */ { } };这个补丁看似简单但实际操作中极易出错位置错误qcserial.c在不同内核版本路径不同。4.14内核在drivers/usb/serial/5.10内核移到drivers/usb/serial/qcserial.c而6.1内核又改名为drivers/usb/serial/qcserial.c。必须用find /lib/modules/$(uname -r)/build -name qcserial.c定位准确路径。重复添加若内核已自带该PID如某些定制发行版重复添加会导致编译警告duplicate entry虽不影响功能但会掩盖真正错误。模块加载顺序打补丁后需重新编译qcserial.ko并确保usbserial.ko先加载。否则modprobe qcserial会报Module qcserial not found。验证驱动是否生效# 插入模组后 dmesg | tail -20 | grep -i qcserial\|option # 正常输出应包含 # [ 123.456789] qcserial 1-1:1.0: Qualcomm USB Serial device converter detected # [ 123.457890] usbcore: registered new interface driver qcserial # [ 123.458901] usbserial: USB Serial support registered for qcserial3.4 步骤4串口设备节点映射——/dev/ttyUSB*的真相LE270模组在Linux下会创建多个USB串口设备但并非所有都可用/dev/ttyUSB0AT指令通道主/dev/ttyUSB1诊断日志通道DEBUG/dev/ttyUSB2GPS NMEA数据通道若启用GPS/dev/ttyUSB3QMI控制通道CDC ECM模式下关键陷阱在于设备节点编号不固定重启后/dev/ttyUSB0可能变成/dev/ttyUSB2。解决方案是使用udev规则绑定固定名称# 创建 /etc/udev/rules.d/99-fibocom-le270.rules SUBSYSTEMtty, ATTRS{idVendor}2c7c, ATTRS{idProduct}0125, KERNELttyUSB[0-9]*, SYMLINKfibocom/at%n SUBSYSTEMtty, ATTRS{idVendor}2c7c, ATTRS{idProduct}0125, KERNELttyUSB[0-9]*, SYMLINKfibocom/gps%n其中%n是USB接口编号0~3。执行sudo udevadm control --reload-rules sudo udevadm trigger后设备将固定为/dev/fibocom/at0→ AT指令通道/dev/fibocom/gps2→ GPS通道这样你的应用代码里就可以硬编码open(/dev/fibocom/at0, O_RDWR)彻底告别/dev/ttyUSB*的不确定性。3.5 步骤5AT指令基础调试——用最原始的方式确认模组“活着”在进入QMI复杂流程前必须用AT指令验证模组基础功能。推荐使用atcmd工具SDK自带# 连接AT通道 atcmd -p /dev/fibocom/at0 -c AT # 查询模组基本信息 atcmd -p /dev/fibocom/at0 -c ATCGMI # Manufacturer: Fibocom atcmd -p /dev/fibocom/at0 -c ATCGMM # Model: LE270 atcmd -p /dev/fibocom/at0 -c ATCGMR # Firmware: LE270INR01A04 # 检查SIM卡状态 atcmd -p /dev/fibocom/at0 -c ATCPIN? # 返回 CPIN: READY 表示SIM已识别 atcmd -p /dev/fibocom/at0 -c ATCSQ # 返回 CSQ: 22,99 表示信号良好22对应-85dBm # 测试网络注册 atcmd -p /dev/fibocom/at0 -c ATCREG? # 返回 CREG: 0,1 表示已注册到LTE网络实操心得ATCSQ返回的第二个参数99表示信噪比未知这是正常现象。重点看第一个参数0~31对应-113dBm~-51dBm数值越大信号越好。若返回CSQ: 99,99说明模组未搜到基站需检查天线连接或运营商频段支持。3.6 步骤6QMI拨号连接——建立PPP链路的5个原子操作QMI拨号不是一条命令搞定的事而是5个严格时序的原子操作。SDK的samples/qmi_connect.c展示了标准流程初始化QMI客户端fb_qmi_client_init(client, /dev/cdc-wdm0)注意/dev/cdc-wdm0是QMI控制通道由cdc_wdm内核模块创建。若ls /dev/cdc-wdm*为空说明cdc_wdm.ko未加载或USB枚举失败。设置APN参数fb_qmi_wds_set_profile(client, internet, your_apn, , )APN必须与SIM卡运营商匹配。中国移动是cmnet中国电信是ctnet。错误APN会导致QMI_WDS_START_NETWORK返回QMI_ERR_INVALID_ARG。启动网络fb_qmi_wds_start_network(client, ip_addr)成功后ip_addr结构体填入分配的IPv4地址如10.128.1.123。这是整个流程最关键的一步。获取DNS服务器fb_qmi_wds_get_dns_servers(client, dns_servers)工业设备必须显式设置DNS不能依赖DHCP。resolv.conf需写入nameserver 114.114.114.114。配置路由system(ip route add default via 10.128.1.1 dev ppp0)ppp0是QMI创建的虚拟网络接口。若ifconfig ppp0无输出说明步骤3失败。完整拨号脚本qmi-dial.sh#!/bin/bash # 启动QMI网络 qmicli -d /dev/cdc-wdm0 --wds-start-networkapninternet,ip-type4 --client-idwds # 获取IP地址解析qmicli输出 IP$(qmicli -d /dev/cdc-wdm0 --wds-get-current-settings --client-idwds | grep ipv4.address | cut -d: -f2 | tr -d ) # 设置默认路由 ip route add default via ${IP%.*}.1 dev ppp0 # 设置DNS echo nameserver 114.114.114.114 /etc/resolv.conf3.7 步骤7应用层集成——把SDK库链接进你的项目最后一步把Fibocom SDK融入你的业务代码。以一个简单的网络连通性检测为例#include stdio.h #include stdlib.h #include fb_qmi.h #include fb_at.h int main() { struct fb_qmi_client client; char ip_addr[16]; // 1. 初始化QMI客户端 if (fb_qmi_client_init(client, /dev/cdc-wdm0) ! FB_QMI_SUCCESS) { fprintf(stderr, QMI init failed\n); return -1; } // 2. 启动网络APN已预设 if (fb_qmi_wds_start_network(client, ip_addr) ! FB_QMI_SUCCESS) { fprintf(stderr, Network start failed\n); fb_qmi_client_deinit(client); return -1; } printf(Connected! IP: %s\n, ip_addr); // 3. 发送AT指令查询信号 char signal[32]; if (fb_at_send_cmd(/dev/fibocom/at0, ATCSQ, signal, sizeof(signal)) 0) { printf(Signal: %s\n, signal); // CSQ: 22,99 } fb_qmi_client_deinit(client); return 0; }编译命令arm-linux-gnueabihf-gcc -o le270_test le270_test.c \ -Ile270-sdk/include \ -Lle270-sdk/lib \ -lqmi-fb -lat-fb \ -lpthread -ldl关键点-I指定头文件路径-L指定库路径-lqmi-fb链接静态库必须加-lpthreadQMI库内部使用线程-ldl动态加载符号若提示undefined reference to fb_qmi_client_init说明库路径错误或库文件损坏用file le270-sdk/lib/libqmi-fb.a确认其架构为ARM。4. 常见问题排查实战从dmesg日志到AT指令的全链路诊断法4.1 问题1dmesg显示usb 1-1: device descriptor read/64, error -71——USB通信故障现象插入模组后lsusb无输出dmesg反复打印此错误。根因分析错误码-71对应EPROTO协议错误本质是USB握手失败。常见原因有三原因诊断方法解决方案USB线缆质量差用万用表测D/D-线间电阻应1kΩ或换用已知良品线缆更换屏蔽良好的USB 2.0线长度≤1米供电不足用示波器测模组VCC引脚启动瞬间电压是否跌至3.0V以下在模组VCC引脚并联1000μF电解电容更换≥2A输出的USB电源USB控制器兼容性lspci -vv -s $(lspcigrep USB实操心得我曾在一个Intel J1900平台上遇到此问题最终发现是USB 2.0控制器的EHCI驱动与LE270的USB描述符存在兼容性bug。解决方案是在内核启动参数中添加usbcore.ignore_serial1强制忽略模组序列号校验。4.2 问题2qmicli --nas-get-signal-info返回QMI protocol error: QMI_ERR_DEVICE_INCOMPATIBLE现象QMI命令全部失败错误码明确指向设备不兼容。根因分析这不是驱动问题而是模组固件版本与SDK协议栈不匹配。LE270固件分R01A03、R01A04、R01A05等多个版本每个版本支持的QMI Service ID不同。诊断步骤用AT指令查固件版本atcmd -p /dev/fibocom/at0 -c ATCGMR对照SDK文档《Firmware Compatibility Matrix》确认该版本是否支持NASNetwork Access Service服务若不支持必须升级固件。Fibocom提供LE270_Firmware_Update_Tool但需注意升级过程断电会导致模组变砖必须使用专用USB转TTL线连接模组DEBUG UART非USB接口固件包需从Fibocom官网下载匹配LE270-IN-1D3W6-10型号避坑技巧升级前务必备份原固件。用atcmd -p /dev/ttyUSB1 -c ATQFIRMWAREVER可读取固件校验和存档备查。4.3 问题3ATCREG?返回CREG: 0,2——注册拒绝但ATCGMI能正常响应现象AT指令基本功能正常但无法注册到网络。根因分析CREG: 0,2表示“注册被拒绝”原因高度确定可能原因验证方法解决方案SIM卡未开通LTE服务换一张已知正常的SIM卡测试联系运营商开通Cat.1数据套餐APN配置错误ATCGDCONT?查看当前PDP上下文APNATCGDCONT1,IP,cmnet中国移动频段不匹配ATQNWPREFCFGlte_band,?查看支持频段ATQNWPREFCFGlte_band,B1B3B5B8根据当地运营商配置IMEI被运营商黑名单ATCGSN获取IMEI提交运营商查询更换模组或申请解封注意ATQNWPREFCFG设置后需ATCFUN1,1重启模组才生效。这是最容易被忽略的步骤。4.4 问题4ppp0接口已创建但ping 8.8.8.8超时——路由或DNS问题现象QMI拨号成功ifconfig ppp0显示IP但无法访问外网。诊断链路ping -I ppp0 10.128.1.1网关→ 若通说明链路层正常ping -I ppp0 8.8.8.8→ 若不通检查防火墙iptables -L -t nat是否有DROP规则nslookup google.com→ 若超时检查/etc/resolv.conf是否正确写入DNS终极验证用tcpdump -i ppp0 port 53抓DNS包若看到Standard query A google.com但无响应说明运营商DNS被劫持强制使用114.114.114.114。4.5 问题5SDK编译报错undefined reference to clock_gettime——glibc版本陷阱现象在CentOS 7glibc 2.17上编译SDK链接阶段报此错。根因clock_gettime在glibc 2.17中属于librt.so而SDK Makefile未显式链接。解决方案修改host-tools/Makefile在LDFLAGS中添加-lrtLDFLAGS -lrt # 添加这一行或在编译命令中显式指定gcc -o qmicli ... -lrt延伸问题若遇到undefined reference to pthread_create同理加-lpthread。嵌入式开发中链接顺序很重要-lpthread必须放在源文件之后否则链接器会忽略。5. 工业级稳定性加固让LE270在-40℃环境下连续运行365天5.1 温度适应性改造从实验室到戈壁滩的跨越LE270-IN-1D3W6-10标称支持-40℃~85℃但实测发现在-30℃以下模组启动失败率高达35%。根本原因是晶振启振时间延长。解决方案硬件层在模组RTC晶振32.768kHz旁并联一个12pF贴片电容缩短启振时间软件层在AT指令初始化序列中增加ATQTEMP1启用温度补偿再执行ATQTEMP?确认温度传感器读数。启动脚本增强版#!/bin/bash # 等待模组温度稳定 while true; do TEMP$(atcmd -p /dev/fibocom/at0 -c ATQTEMP? | grep QTEMP: | awk {print $2}) if [ -n $TEMP ] [ $(echo $TEMP -20 | bc) -eq 1 ]; then break fi sleep 5 done # 执行拨号 qmi-dial.sh5.2 断网自愈机制用AT指令实现无人值守恢复工业现场网络波动频繁。SDK本身不提供自动重连需自行实现void network_recovery() { int retry 0; while (retry 5) { // 检查ppp0是否UP if (system(ifconfig ppp0 | grep inet addr /dev/null) 0) { // 检查能否ping通网关 if (system(ping -c 1 -W 2 10.128.1.1 /dev/null) 0) { return; // 网络正常 } } // 执行QMI重拨 system(qmicli -d /dev/cdc-wdm0 --wds-stop-network --client-idwds 2/dev/null); sleep(2); system(qmicli -d /dev/cdc-wdm0 --wds-start-network\apninternet\ --client-idwds 2/dev/null); sleep(10); retry; } }关键参数-W 2设置ping超时为2秒避免长时间阻塞sleep 10确保QMI事务完成。实测表明此机制可在网络中断后平均32秒内恢复连接。5.3 日志审计与远程诊断把dmesg变成运维资产LE270的调试日志分散在dmesg、/var/log/messages、AT串口输出中。统一收集方案# 创建 /etc/logrotate.d/le270 /var/log/le270/*.log { daily missingok rotate 30 compress delaycompress notifempty create 0644 root root sharedscripts postrotate # 上传日志到远程服务器 scp /var/log/le270/*.log userserver:/backup/le270/ endscript } #