LinuxWave 2.6.5

Release Note 更新日志

本次修一处提示判断错误：判断「要不要重新登录」时查错了地方。

问题

安装器与 selfupdate 都会在需要重新登录时提示用户。判断依据原本写成了 id -G <用户名>，但 id 的两种形式语义不同（已用隔离实验确认）：

形式	实际读的是什么	后果
id -G <用户名>	/etc 数据库	把用户写进 /etc/group 后立刻就报出该组，看不见会话
id -G（不带参数）	当前会话的进程组	写进库也不认，必须重登才生效

于是「已被写进组、但当前 shell 还没重登」的用户会被告知「已经在组里，无需重登」——而实际上那一刻安装树对他依然是写不进去的。影响不大、而且会自愈（他随后 wave install 失败时报错信息会明确说明要重登），但这是句错话。

修法

两个判断各用各的语义，不再混用：

• 要不要 usermod → 用 id -G <用户名>（查库：此人配在组里了吗）；
• 要不要重新登录 → 用 id -G 不带参数（看会话：这个 shell 真的具备该组身份了吗）。

代码里对这一点留了注释，PROJECT_CONTEXT.md 也记了这条陷阱。

一并带上 2.6.4 / 2.6.3 的内容

从更早版本升上来的话，本版同时包含：

• 2.6.4：selfupdate.sh 也会配好共享写 —— 交回安装树属主（下载是拿 root 跑的，新文件以前会落成 root 属主），并给共享安装树补上组共享写（groupadd / usermod -aG / chmod -R g+w / 目录 setgid）。于是存量共享安装升级一次就到位，不必重装。
• 2.6.3：共享安装本身改成 Linuxbrew 式组共享，装包不再需要 sudo，也不需要写全路径。

wave selfupdate

装完之后要不要重新登录？

情形	要不要重登
这次才把你加进组	要 —— 重登，或在当前 shell 跑 newgrp linuxwave
你已在组里，但当前 shell 是入组之前开的	要 —— 同上
你已经入组、并且入组之后重登过	不要 —— 权限位与组身份都已生效

chgrp / chmod g+w / setgid 是立即生效的，只有「你个人的组身份」要等新的登录会话。

升级路径

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

本次不涉及目录结构变更，updatedata/2.6.5/dir_structure_change 显式声明为 N。

为什么必须抬版本号：selfupdate 在「当前版本不低于线上版本」时直接短路。不抬版本的话，已经升到 2.6.4 的用户跑 wave selfupdate 只会被回一句「已是最新」，永远走不到修正后的 selfupdate.sh。

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

验证方式

• id 两种语义的隔离实验：在用户命名空间里建影子 /etc，把用户写进一个新组，然后对比 id -G <用户名>（立刻报出新 gid）与 id -G 不带参数（不报，必须重登）—— 修正正是基于这个结论。
• 回归套件：隔离命名空间里 133 条断言全绿（133 PASS / 0 FAIL / 0 SKIP）。沙箱里 linuxwave 组的 gid 只能是 0、而命名空间内 root 的会话本来就带 gid 0，所以「会话里还没有该组」这一分支在沙箱里走不到，已在 PROJECT_CONTEXT.md 的「已知限制」里写明，并由上面的隔离实验覆盖。
• bash -n：install.sh、selfupdate.sh、sandbox_test.sh 通过。

其他改动

• 版本号 2.6.4 → 2.6.5，构建号 281D0135

---

Release Notes

This release fixes one wrong decision: "do you need to log in again?" was looking in the wrong place.

The bug

Both the installer and selfupdate tell you when a re-login is needed. The check was written as id -G <user>, but the two forms of id mean different things (confirmed with an isolated experiment):

Form	What it actually reads	Consequence
id -G <user>	the /etc database	writing the user into /etc/group shows up immediately - it cannot see the session
bare id -G	the current session's process groups	a database change is not seen until you re-login

So a user already written into the group but not yet re-logged-in was told "already in the group; nothing to re-login for" - while at that moment the tree was still unwritable for them. The impact is small and self-correcting (the next wave install fails and its error message explains the re-login), but the sentence was wrong.

The fix

Each question now uses the form that answers it:

• whether to run usermod → id -G <user> (the database: is this person configured in the group?);
• whether a re-login is needed → bare id -G (the session: does this shell actually have the group?).

The code carries a comment about it, and PROJECT_CONTEXT.md records the trap.

This also carries 2.6.4 and 2.6.3

Coming from an older version, this release also includes:

• 2.6.4: selfupdate.sh now sets up shared write as well - it hands the tree's ownership back (downloads run as root, so new files used to land root-owned) and gives a shared tree its group write access (groupadd / usermod -aG / chmod -R g+w / setgid on directories). So an existing shared install gets this from one update, with no reinstall.
• 2.6.3: a shared install became a Linuxbrew-style group install, so installing a package needs neither sudo nor a full path.

wave selfupdate

Do you need to log in again afterwards?

Situation	Re-login needed?
This is what added you to the group	Yes - log out and back in, or run newgrp linuxwave
You are in the group, but this shell predates that	Yes - same as above
You are in the group and have logged in since	No - both the permission bits and your group identity are in place

chgrp / chmod g+w / setgid take effect immediately; only your group identity waits for a new login session.

Upgrade path

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

No directory structure change is involved - updatedata/2.6.5/dir_structure_change states N explicitly.

Why the version had to be bumped: selfupdate exits early when the installed version is not older than the published one. Without a bump, a user already on 2.6.4 running wave selfupdate would just be told "already up to date" and would never reach the corrected selfupdate.sh.

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

How this was verified

• Isolated experiment on the two id semantics: inside a user namespace with a shadow /etc, a user was written into a new group and the two forms compared - id -G <user> reported the new gid immediately, bare id -G did not until a re-login. The fix rests on that result.
• Regression suite: all 133 assertions pass in the isolated namespace (133 PASS / 0 FAIL / 0 SKIP). In the sandbox the linuxwave group's gid can only be 0, and root's session inside the namespace already carries gid 0, so the "this session lacks the group" branch is unreachable there; that is recorded in the "known limitations" of PROJECT_CONTEXT.md and covered by the experiment above.
• bash -n: install.sh, selfupdate.sh and sandbox_test.sh parse.

Other Changes

• Version 2.6.4 → 2.6.5, build number 281D0135

---

安装

/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)"