LinuxWave 2.6.3

Release Note 更新日志

本次改的是共享安装的写法：/home/linuxwave/.linuxwave 改成 Linuxbrew 式组共享，装包不再需要 sudo。

改了什么

1. 共享安装（选项 4）自动做成组共享

以前装完共享安装，只有 linuxwave 账号和 root 能装包，普通用户必须写 sudo /home/linuxwave/.linuxwave/lib/wave install <package> 这种全路径命令（sudo wave … 还必然失败，因为 sudo 用的是它自己那套 PATH）。

现在安装器会自己把这件事做完：

• 建 linuxwave 组（已存在就跳过）；
• 把运行安装器的人加进该组；
• chgrp -R 把安装树交给该组，chmod -R g+w 打开组写位；
• 给所有目录加上 setgid —— 不加的话组员新建的文件会落回他自己的主组，下一个组员就改不动了。

于是装包既不用 sudo，也不用全路径：

wave install <package>

2. 一句必须说清的话：组身份要重新登录才生效

组身份只在新的登录会话里生效。所以装完（或后来被 usermod -aG 加进组）之后，要退出重登一次，或在当前 shell 里跑 newgrp linuxwave，装包才会成功——在那之前树依然是写不进去的。这不是实现缺陷，是 Unix 的组语义。安装器的收尾提示、以及写不进树时的报错，都会把这一点讲明白。

3. 写不进树时的报错重写了

新增/改写后的提示会给出：

• 一条能跑通的 sudo 全路径命令；
• 如果安装树的属组不是 root，再加一条 sudo usermod -aG <组> <你>，并点明「刚被加进组、还没重登」正是最常见的原因——不说这句，用户会以为是装坏了；
• 组名是按 gid 反查出来的，不是写死的。树属 root:root（/opt、/usr/local 这类系统级安装）时故意不提组，免得建议用户去加入 root 组。

4. usermod 失败不会毁掉整个安装

账号由 LDAP/SSSD 管理、/etc/group 里有重复条目等情况下 usermod 会失败。这时安装照常成功（树已经装好、也仍然能用），只是如实报告并打出手工命令。

升级路径

当前版本	目标	行为
2.5.0 ~ 2.6.2	2.6.3	执行自更新 ✅
2.6.3	2.6.3	已是最新，短路退出

本次不涉及目录结构变更，updatedata/2.6.3/dir_structure_change 显式声明为 N，自更新会跳过迁移步骤。

wave selfupdate

已经装好的共享安装要额外做一步

自更新不会让原有的共享安装树变成组共享：selfupdate.sh 只替换代码文件（外加把下载来的脚本 chmod +x），不动属组与权限。想要这套权限，两条路：

• 重新跑一次安装器并选共享安装（选项 4）；或
• 按 .templates/SPECIAL/INSTALL_BY_INTERNET.md 末尾「可选：让多个用户都能安装软件包」的手工步骤配一次（groupadd / usermod -aG / chgrp / g+w / setgid），然后重新登录。

另外，wave selfupdate 仍然需要 sudo，与写权限无关：它要重写 root 属主的 /etc/linuxwave_config/VERSION.json。

代价（照实说）

组内成员可以改动整棵树，包括 lib/ 里的 wave 本体。这是 INSTALL_BY_INTERNET.md 早就写明的那笔代价，本次只是把它自动化了。如果不需要多人装包，只做「读 + 执行」那一档（不要组共享写）即可。

验证方式

三条互相独立的证据：

1. 回归套件：隔离命名空间里的断言从 117 条扩到 133 条，全绿（133 PASS / 0 FAIL / 0 SKIP）。新增覆盖：调用者被加进组、树目录打开组写位、目录带 setgid、提示写明需重新登录、重复安装不再谎称刚入组、usermod 失败时安装仍成功并如实报告、root:root 的树不劝人加入 root 组、组名反查判定。
2. 权限模型对照实验（真实非 root 用户，全程无 sudo）：不成组时写入被拒（EACCES）；按新方式设好权限后，downloads/、bin/、pkg/、links/、deps/ 五个数据目录全部可写，且新文件自动继承组。
3. 端到端安装：以非 root 用户真实跑 wave install jq，下载 2.3 MB → sha256 校验 → 解包 → 装二进制 → 建版本链接与不带版本的软链接，退出码 0，输出里 sudo 出现 0 次，装出来的 jq --version 可正常运行。

其他改动

• 版本号 2.6.2 → 2.6.3，构建号 281D0052
• 文档同步：README（中英）、官网、INSTALL_BY_INTERNET.md、PROJECT_CONTEXT.md

---

Release Notes

This release changes how a shared install works: /home/linuxwave/.linuxwave is now a Linuxbrew-style group install, so installing packages needs no sudo.

What changed

1. A shared install (option 4) is now set up as a group install automatically

Previously, after a shared install only the linuxwave account and root could install packages; everyone else had to spell out sudo /home/linuxwave/.linuxwave/lib/wave install <package> (and sudo wave … cannot work at all, because sudo searches its own PATH).

The installer now does that work itself:

• creates the linuxwave group (skipped if it already exists);
• adds the user who ran the installer to it;
• chgrp -Rs the tree to that group and opens the group write bits with chmod -R g+w;
• sets setgid on every directory - without it, a file created by one member lands back in that member's own primary group and the next member cannot touch it.

So installing needs neither sudo nor a full path:

wave install <package>

2. One thing that has to be said plainly: group membership needs a new login

Group membership only takes effect in a new login session. So after the install (or after being added to the group later with usermod -aG), log out and back in, or run newgrp linuxwave in the current shell, before installing. Until then the tree is still unwritable. That is not an implementation defect - it is Unix group semantics. Both the installer's closing notes and the error you get when writing fails say this explicitly.

3. The write-permission error was rewritten

The message now gives you:

• a sudo command with the full path that actually works;
• if the tree's group is not root, also sudo usermod -aG <group> <you>, and it points out that "just added to the group, not re-logged-in yet" is the most common reason - without that sentence users assume the install is broken;
• the group name is looked up by gid, not hard-coded. When the tree is root:root (system-level installs such as /opt or /usr/local) the group suggestion is deliberately omitted, so nobody is told to join the root group.

4. A failing usermod no longer ruins the install

usermod fails when the account is managed by LDAP/SSSD, when /etc/group has duplicate entries, and so on. The install now still succeeds (the tree is installed and remains usable) and simply reports the failure with the manual command.

Upgrade path

From	To	Behaviour
2.5.0 - 2.6.2	2.6.3	self-update runs ✅
2.6.3	2.6.3	already up to date, exits early

No directory structure change is involved - updatedata/2.6.3/dir_structure_change states N explicitly - so the self-update skips the migration steps.

wave selfupdate

An existing shared install needs one extra step

Self-update will not turn an existing shared tree into a group install: selfupdate.sh only replaces code files (plus chmod +x on the scripts it downloads) and never touches ownership or permissions. To get the new permissions, either:

• re-run the installer and choose the shared install (option 4); or
• follow the manual steps in .templates/SPECIAL/INSTALL_BY_INTERNET.md, section "optional: let several users install packages" (groupadd / usermod -aG / chgrp / g+w / setgid), then log out and back in.

Also, wave selfupdate still needs sudo, independently of write permissions: it rewrites /etc/linuxwave_config/VERSION.json, which is root-owned.

The cost, stated plainly

Members of the group can modify the whole tree, lib/wave itself included. That is the cost INSTALL_BY_INTERNET.md has always documented; this release only automates it. If you do not need several users installing packages, stay on the read-and-execute-only level (no group write).

How this was verified

Three independent pieces of evidence:

1. Regression suite: assertions in the isolated namespace grew from 117 to 133, all green (133 PASS / 0 FAIL / 0 SKIP). New coverage: the caller joins the group, the tree opens its group write bits, directories carry setgid, the notes say a re-login is needed, a second install no longer claims a fresh group change, a failing usermod still leaves the install successful and reported, a root:root tree is not told to join the root group, and the gid-to-name lookup.
2. Permission-model control experiment (a real non-root user, no sudo anywhere): writing is refused without the group (EACCES); with the new permission scheme all five data directories - downloads/, bin/, pkg/, links/, deps/ - are writable and newly created files inherit the group.
3. End-to-end install: as a non-root user, wave install jq really ran - 2.3 MB downloaded, sha256 verified, unpacked, binary installed, versioned link and unversioned symlink created, exit code 0, sudo appearing 0 times in the output, and the installed jq --version runs.

Other Changes

• Version 2.6.2 → 2.6.3, build number 281D0052
• Documentation synced: READMEs (English and Chinese), the website, INSTALL_BY_INTERNET.md, PROJECT_CONTEXT.md

---

安装

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

Install

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"