★ FEATURED ARTICLE 做 Linux 服务器初始化这活干得多了之后,你会发现一件事:真正高频用到的基础操作翻来覆去就那么几个。开启 root 权限、换软件源、开 SSH、改主机名、调时区,这套组合拳打完,一台能正经干活 Ubuntu 服务器才算真正“能用”。这篇东西不玩虚的,直接把这套操作拆开揉碎,讲讲每一步为什么要这么做、怎么做最稳、哪些坑我替你踩过了。1. 开局之前:这套初始化到底在解决什么问题1.1 哪些场景需要这套“套餐”先对号入座。如果你属于下面这几类情况,那这篇文章就是给你准备的:刚买了一台云服务器,系统装的是 Ubuntu Server,开机后想赶紧把它变成能远程登录、能正常装软件的生产环境。本地虚拟机里装了个 Ubuntu,想把它当开发服务器用,需要固定主机名、统一时区、能通过 SSH 从外部连进来操作。公司测试环境、实验室机器、甚至树莓派上刷了 Ubuntu,都需要先过一遍这些基础设置再上应用。这类场景的共同特点是:机器本身是“裸”的,而我们要做的是把它初始化到一个“可用且顺手”的状态。注意关键词是“顺手”——不同人偏好不同,比如有人死活不用 root,有人坚持只用 apt-get 不用 apt,这都正常。但作为一套通用的初始化流程,我给出的方案是大多数场景下平衡得比较好的那一种。1.2 动手前的准备与风险认知在动任何配置之前,先确认手里有什么:Ubuntu 系统的版本号,不同版本某些配置文件的写法略有差异。16.04 及以前用 init 脚本,18.04 之后基本都是 systemd。下文操作以 18.04 以上版本为例,现在还在用老版本的建议尽早升级。是否有 sudo 权限的普通用户。默认安装 Ubuntu Server 时会创建一个普通用户,这个用户通常具备 sudo 权限。如果你的机器只能 root 登录,也问题不大。是否知道你将要修改的文件的作用。换源、改 SSH 配置这类操作,万一写错可能导致系统异常。所以我会反复强调一个习惯:动配置文件之前,先备份。风险认知这件事,干得越久越胆小。早期我改源的时候直接覆盖/etc/apt/sources.list,结果写错一个地址,apt update 直接报一堆 404。现在我的习惯是永远保留一份.bak文件,配置出错随时回滚。这不是磨叽,是花时间换省事。另外提一句:下面所有操作里,凡是涉及网络连接的配置,请确保你的机器能正常访问外网。如果网络环境本身特殊,可能需要走内网镜像或离线方案,这个不在今天的讨论范围内。2. 搞懂 apt 与 apt-get,顺便把软件源换成国内镜像2.1 apt 和 apt-get 到底有什么区别这是新手最容易困惑的问题之一。简单说,apt是apt-get的“现代化改进版”,它整合了apt-get、apt-cache等工具最常见的使用场景,输出更友好、进度条更直观、还多了些彩色提示。日常装包、卸包、升级,用apt就够了。但脚本里、自动化任务里,apt-get更稳定——它的输出格式变化少,行为更“死板”,不容易因为版本更新导致脚本解析失败。我自己的习惯是:命令行交互操作全用apt,写脚本或文档里涉及自动化运维时用apt-get。两者底层其实是同一套 dpkg 体系和同一个软件源列表,并不存在“apt 装不了的东西 apt-get 能装”这种区别。软件源列表主要存在两个地方:/etc/apt/sources.list—— 传统的主源文件。/etc/apt/sources.list.d/目录下的.list文件 —— 推荐的扩展方式,第三方源、独立软件源往往放在这里。Ubuntu 18.04 之后,系统默认的源配置可能分散在这两个位置,换源时建议都检查一下。2.2 换源的完整操作与备份习惯为什么要换国内镜像源?原因很现实:Ubuntu 官方源服务器在国外,国内直连延迟高、速度不稳定。尤其执行apt update和安装大型软件包时,官方源可能会让人等到怀疑人生。国内主流的镜像站有阿里云、清华、中科大等,选择哪家差别不大,关键是选一个你网络环境下稳定且快的。换源的完整流程我按步骤走一遍。第一步,备份原配置:sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak.$(date %Y%m%d)如果/etc/apt/sources.list.d/下面有 Ubuntu 官方的源文件,也一并备份或禁用。注意$(date %Y%m%d)会自动拼上当前日期,这样你随时知道这份备份是哪天留的。第二步,编辑源文件。用你顺手的编辑器,我一般用 vim:sudo vim /etc/apt/sources.list把文件里原有内容全部注释掉或清空,然后写入新的镜像源地址。以阿里云镜像站为例,Ubuntu 22.04 (jammy) 的源配置大概是这样的:deb https://mirrors.aliyun.com/ubuntu/ jammy main restricted universe multiverse deb https://mirrors.aliyun.com/ubuntu/ jammy-updates main restricted universe multiverse deb https://mirrors.aliyun.com/ubuntu/ jammy-backports main restricted universe multiverse deb https://mirrors.aliyun.com/ubuntu/ jammy-security main restricted universe multiverse如果你的系统是 20.04(focal)、24.04(noble),把jammy换成对应的代号即可。注意jammy-security这一行,有的镜像站路径是ubuntu-security开头的,不过现在主流镜像站都已经统一了路径,直接用上面的格式问题不大。不同镜像站对 Ubuntu 源的支持格式不完全一致,最稳妥的做法是打开镜像站首页,找到“Ubuntu”对应的帮助文档,复制它提供的现成配置。这比自己记地址靠谱得多。第三步,更新索引:sudo apt update这个命令会把源列表里的软件索引同步到本地,执行时应该能看到下载速度明显快于官方源。看到类似Reading package lists... Done且没有报错,就说明源已经生效了。注意:如果之前系统从未执行过apt update,第一次执行时可能会提示缺少公钥或签名验证失败。这类问题通常是 GPG key 缺失,处理方式一般是导入对应签名密钥,而不是粗暴地跳过验证。2.3 update 和 upgrade 别乱用apt update和apt upgrade是两个容易混的操作。update只是刷新软件列表,不升级任何软件;upgrade才是真正执行升级。很多人刚接触 Linux 时,看到教程说“先 update 再 upgrade”,就条件反射式地每次装环境前来一套。这本身问题不大,但要注意:在已经跑着线上服务的机器上执行apt upgrade,有可能会触发内核更新、服务重启,进而导致短暂的服务中断。生产环境务必评估影响后再操作。升级前最好看一眼会升级什么:sudo apt list --upgradable。大版本跨版本升级(Ubuntu 18.04 升 20.04)更不能用apt upgrade硬来,需要使用do-release-upgrade之类的专门工具。日常场景下,我的建议是:新机器拿到手,apt update必须做,apt upgrade看情况做。如果只是为了装一个 Nginx、MySQL,源更新好了直接装即可,没必要非得先全量升级一遍系统。3. root 与 SSH:最容易被吐槽但也最常用的两个开关3.1 root 账号策略:开还是不开,怎么开关于 Ubuntu 的 root 账号,有一个很多人不知道的细节:Ubuntu 默认并没有给 root 设置密码,而是通过 sudo 机制把管理员权限授权给普通用户。这意味着你无法直接su root切到 root,因为你根本没有 root 的密码。这种做法出于安全考虑,本意是好的:强制你以普通用户身份操作,每条命令前加个sudo,审计记录里也能看到是谁干了什么。但实际使用中,尤其是云服务器、测试服务器场景下,root 直接登录能省掉很多麻烦——比如一些自动化脚本、某些运维工具需要 root 权限,而交互式执行 sudo 又不方便。如果你确实想启用 root 账号,操作如下:sudo passwd root系统会让你输入两次新密码。这一步完成之后,root 账号就算激活了。以后可以用su -切换到 root,也可以在 SSH 登录时直接用 root 用户连接。但我必须把“是否开启 root 登录”这件事说透。我的建议是:个人开发机、测试虚拟机:开启 root 登录问题不大,图省事。生产环境、有公网 IP 的云服务器:不建议直接开启 root 远程登录。根因很简单:root 是系统最高权限,一旦密码泄露或被暴力破解成功,后果是灾难性的。配合公网环境里每分钟都在发生的 SSH 扫描爆破,风险更高。折中的方案是:本地保留普通用户 sudo,SSH 层面禁用 root 登录,所有管理操作都通过普通用户 sudo 完成。如果觉得 sudo 密码麻烦,可以配置 SSH 密钥登录并给用户配置 NOPASSWD 的 sudo 规则,既安全又顺手。3.2 开启 SSH 服务Ubuntu Server 默认可能没装 SSH 服务端。先检查:systemctl status ssh如果提示Unit ssh.service could not be found,说明还没装,装一下:sudo apt install openssh-server装好后启动并设为开机自启:sudo systemctl enable --now ssh注意包名是openssh-server,但服务名可能是ssh也可能是sshd,取决于发行版。Ubuntu 上一般叫ssh。有些教程里写systemctl start sshd,在 Ubuntu 上会报错,别被误导。验证 SSH 服务是否在监听:ss -lntp | grep 22如果能看到类似LISTEN 0 128 0.0.0.0:22的输出,说明服务已经起来了。此时从另一台机器尝试连接:ssh 用户名服务器IP第一次连接会提示确认主机指纹,输入yes回车即可。这里面有个小坑:如果你改了 SSH 配置(后面马上要讲),比如改了端口、禁用了 root 登录,一定要在确认新配置能正常连接之前,不要断开当前 SSH 会话。正确做法是开两个终端,一个改配置,一个保留现场,确认没问题再退出,否则容易把自己锁在外面。3.3 建议补充:SSH 密钥登录既然提到 SSH,顺手讲一个和初始化强相关的点:密钥登录。新机器初始化时配好密钥登录,后面就不用每次输密码了,也更安全。生成密钥对(在本机执行,不是服务器):ssh-keygen -t ed25519 -C your_comment一路回车即可,默认生成在~/.ssh/id_ed25519和~/.ssh/id_ed25519.pub。然后把公钥拷到服务器上:ssh-copy-id 用户名服务器IP它会自动把公钥追加到服务器的~/.ssh/authorized_keys文件里。之后再用 SSH 连接就不需要输密码了。如果你想彻底禁用密码登录,改 SSH 配置文件/etc/ssh/sshd_config:PasswordAuthentication no改完重启 SSH 服务:sudo systemctl restart ssh这里有个重要提醒:禁用密码登录前,务必确认密钥登录已经能正常工作。否则密钥配置有误,又关了密码通道,那就只能去控制台走 VNC 或者重置密码的流程了。4. hostname 与时区:平时看不见,关键时刻坑人的两个配置4.1 修改主机名主机名这东西,平时用处不大,但出问题的时候很关键。比如你开了好几台服务器,日志里、监控系统里、告警通知里全是ip-172-31-20-4这种默认主机名,排查问题时根本分不清谁是谁。改成一个有辨识度的名字,比如web-prod-01、db-backup-02,管理和排障都能省心不少。查看当前主机名:hostnamectl这会显示当前的主机名、操作系统版本、内核版本等信息。修改主机名,最规范的方式是用hostnamectl:sudo hostnamectl set-hostname 新主机名比如:sudo hostnamectl set-hostname web-prod-01这个命令会自动更新/etc/hostname文件,同时触发 systemd 更新运行时主机名。执行完用hostnamectl或者hostname验证一下。不过只改这一处不一定够。在很多系统里,/etc/hosts文件会把旧主机名映射到 127.0.1.1,如果不改,某些程序(比如 sudo)解析主机名时可能报错。建议把/etc/hosts里对应行也改掉:sudo vim /etc/hosts找到类似这行:127.0.1.1 旧主机名改成:127.0.1.1 新主机名为什么是127.0.1.1而不是127.0.0.1?这是 Ubuntu 的一个特点,它用 127.0.1.1 作为系统主机名的回环地址,专门用于 Ubuntu 桌面或某些服务的主机名解析,而127.0.0.1保留给localhost。这个细节网上很多教程都没提,但实际运维中遇到过sudo变慢、提示“unable to resolve host”之类的问题,十有八九就是这里没改干净。如果系统里还在用hostname命令临时改主机名,注意这只对当前会话有效,重启即失效,真正持久化还是要改配置文件。4.2 时区修改时区问题在服务器上尤其阴险。默认情况下,很多云服务器的系统时区是 UTC,跟北京时间差 8 个小时。你写个定时任务,日志时间戳,数据库时间,全都跟着偏移。白天看日志还好,一旦凌晨排查问题,看着一堆“凌晨 4 点”的记录,而实际是中午 12 点,神仙也懵。查看当前时区:timedatectl输出里包含Local time、Universal time、Time zone等字段。如果Time zone不是Asia/Shanghai,说明时区不对。把时区改成上海(北京时间):sudo timedatectl set-timezone Asia/Shanghai执行完再timedatectl验证,输出里的Time zone会变成Asia/Shanghai (CST, 0800),本地时间和 UTC 时间差 8 小时,这就对了。这个命令本质上会创建一个符号链接,把/etc/localtime指向/usr/share/zoneinfo/Asia/Shanghai。所以更古老的做法是手动ln -sf去链接,但timedatectl已经把这事封装好了,没必要再走手动流程。如果没装timedatectl(某些精简系统确实可能缺),也可以用:sudo ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime改完时区还有个连带问题:有些应用(比如 Java 类应用、数据库)会缓存时区信息,改完系统时区后,最好重启相关服务,甚至重启机器,确保所有进程都拿到新的时区。比如 MySQL 运行时读取的时区可能是启动时缓存的,不重启就会继续用旧时区给你“制造”时间错乱。5. 常见问题与排查实录这套初始化流程看着简单,但实际操作中,几乎每一步都有对应的“翻车现场”。我梳理几个典型的,做个速查。问题可能原因排查思路apt update报错404 Not Found源地址写错、Ubuntu 版本代号不对、镜像源上该版本已下线检查/etc/apt/sources.list里的代号(如 focal/jammy/noble)是否和系统版本匹配,核对镜像站文档apt update报 GPG 签名错误缺少对应源的公钥从源官网获取并导入公钥,或者使用镜像站提供的添加公钥命令SSH 连接超时或拒绝SSH 服务未启动、防火墙拦截、端口没放开systemctl status ssh看服务状态,ss -lntp看监听端口,检查 iptables/ufw 和安全组规则root 登录 SSH 被拒绝sshd_config里PermitRootLogin为 no改配置后重启 ssh 服务;注意确认密钥已配置再禁密码sudo报unable to resolve host/etc/hosts里主机名映射不一致检查hostname和/etc/hosts里的主机名是否一致定时任务时间不对系统时区为 UTCtimedatectl set-timezone Asia/Shanghai,并重启相关服务修改主机名后 bash 提示符没变当前 shell 仍缓存旧主机名重新登录 SSH 或执行exec bash刷新apt安装软件极慢源仍为官方源,或镜像源所在线路不佳换源,或者换一个合适的镜像站,用apt update重新同步再说几个脚本化、批量操作才容易遇到的坑。一是批量初始化多台服务器时,如果用了同一个镜像源地址,记得确认这些服务器都分布在同一网络环境下。跨地域的机器访问同一个镜像站,速度差异可能很大,最好按区域分别选源。二是修改 SSH 配置时,批量推送容易出问题。比如你推了一个错误配置到 20 台机器,然后统一重启 SSH 服务,结果 20 台全部连不上,运维事故直接就来了。我在批量操作时,会先在 1 台机器上验证配置,再分批次下发,同时保留至少一个带外管理通道(比如云控制台的 VNC)。三是时区问题在容器和虚拟化环境下的“传染性”。你改好了宿主机的时区,但容器如果挂载了宿主机的/etc/localtime,那容器时间也是对的;如果你用的是 Docker,很多基础镜像默认 UTC,需要在 Dockerfile 或运行参数里单独设置时区。这是另外一摊子事,但原理相通:凡是时间相关的问题,先查系统时区,再查应用层时区配置。6. 一点实操体会整套流程做完,建议最后做一次“体检”:hostnamectl # 主机名和时区 timedatectl # 时区确认 ss -lntp | grep 22 # SSH 监听状态 cat /etc/apt/sources.list # 源配置是否正常这几条命令跑一遍,基本能确认初始化状态是干净的。从实际运维角度说,这几项配置最好是机器刚拿到手时就一次性弄完,别拖到部署完应用再搞。因为那时候再改主机名、换时区,影响的就不只是系统本身了,还涉及应用配置、日志路径、监控采集,牵一发动全身。初始化阶段把这些基础项定好,后面所有东西都建立在一致的环境上,能省掉大量无意义的排查时间。如果非要给个操作顺序建议,我会这么排:先改时区、再改主机名、然后换源并 update、接着装并开启 SSH,最后根据需求决定是否启用 root 登录和密钥认证。这个顺序的好处是,网络配置和基础系统配置先搞定,后面每一步操作都在一个正常的网络环境里进行,不容易因为源的问题导致装包失败。这套东西难吗?真不难,都是基础操作。但基础操作能做得干净、规范、可追溯,才是后面省心的前提。
阅读完成 · 觉得有帮助？
