ubuntu-post-install

848 Commits 2 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
Claude	9e5a84f4f5	Don't blindly overwrite existing Samba config; stop clobbering shared account passwords Reported live: the tool unconditionally reconfigured Samba even though "Samba already installed on the home box" was already correctly detected — that check only ever covered whether the smbd package exists, never whether a share for the requested path (or the Samba account itself) was already set up. Two real problems, not just a UX one: 1. Every run appended/replaced a [share] block and reset the target account's password unconditionally, even against a share the user had already configured by hand. 2. Since the Samba account is the SSH username (shared across every mount from the same home box), setting up a SECOND mount from the same box would silently reset the account's password — breaking the FIRST mount's already-saved credentials file with no warning. Now: checks the remote smb.conf for an existing share exporting the exact requested path first (via a plain SSH+awk query) and offers to reuse it as-is (prompting for its real credentials, since a Samba password is stored hashed and can't be read back) instead of overwriting it. If creating a new share, checks whether this tool already set a password for the same user+host pair (from another mount) and reuses it instead of resetting the account; if the account exists with an unknown password (set up some other way), asks rather than silently clobbering it. _vdm_find_remote_share/_vdm_find_existing_smb_password/_vdm_prompt_password are all called via command substitution by their caller, so none of them call log_info/log_warning/etc. internally — those all write to stdout in this codebase, which would corrupt the captured value. Verified the awk share-lookup and the fstab-tag password lookup against sample data.	2026-08-10 19:15:11 +00:00
Claude	28252b97d3	Fix vpn-data-mount's guest-mount errno 79 bug, add per-share SMB accounts, host naming, and chain-in from filebrowser/audiobookshelf/emby Reported live: "mount error(79): Can not access a needed shared library" on the local CIFS mount step. That message is misleadingly worded — errno 79 is ENOKEY, not a real missing-library problem, and a plain `guest` mount with no explicit `sec=` hitting it against a real Samba server is a known cifs-utils/kernel-cifs rough edge in the anonymous-session keyring path. Fixed as a side effect of switching away from guest access per direct request (real per-share Samba accounts, not root/guest, matching "user accounts for data directories"): each mount now gets a dedicated Samba account (reusing the SSH username — that Unix account already exists on the home box) with a generated password, remotely provisioned via smbpasswd over the same SSH trust, and mounted locally via a root-only credentials file (same convention tools/mount-network-drive.sh already uses) plus an explicit sec=ntlmssp instead of guest. Host naming: entering a raw IP now offers to name it in /etc/hosts, then uses that name for everything from then on (SSH commands, the CIFS mount address, and re-runs against the same IP). Deliberately /etc/hosts, not ~/.ssh/config — an SSH Host alias only helps the `ssh` command resolve a name, mount.cifs never consults ~/.ssh/config at all, so an alias alone wouldn't get the actual mount using a name. Still offers to also add a matching SSH Host alias on top (pure convenience — skips typing the username for interactive ssh use) when services/ssh-config.sh's helpers are available. Chain-in: filebrowser/audiobookshelf/emby now offer to run vpn-data-mount first if their data is on a home box that isn't mounted yet, and default their own directory prompt to whatever was just mounted (VDM_LAST_MOUNT_POINT, explicitly unset before each chain call so an unrelated earlier vpn-data-mount run in the same setup.sh session can't leak its mount point in as a stale default).	2026-08-10 18:37:59 +00:00
Claude	0e42de1cda	Add vpn-data-mount: SMB mount from a NetBird-connected home box Offered right after NetBird setup during required/base setup, matching the requested flow (base packages -> NetBird -> data mount). Repeatable by design rather than a one-shot step, since different services can have data on different home boxes — asks for a home box IP every time and can be run again for additional boxes/shares. Flow: test for existing passwordless SSH first (covers "both boxes already share a key via GitHub import, or any other means" for free — if it already works, nothing else runs). If not, generate an SSH keypair and offer ssh-copy-id or a manual/GitHub-import fallback (ssh-import-id, the same mechanism base.sh's own SSH setup already uses) — needed because a home box that took base.sh's "disable password login" option won't accept ssh-copy-id at all. Once passwordless SSH works, use it to remotely install and configure Samba on the home box for a chosen path, then mount it locally over CIFS with a tagged /etc/fstab entry. SMB over NFS/SSHFS per this session's direction: not a "huge" speed gap for normal use, and SSHFS's own encryption is redundant overhead once the VPN tunnel already encrypts everything. Guest-accessible (no separate Samba credentials) since the VPN is the real access control — only NetBird-connected peers can reach the home box's NetBird IP at all. Also: - cifs-utils added to base.sh's always-installed packages, same reasoning as Docker/Compose being unconditional there instead of installed lazily on first mount. - is_installed()/install_count() in setup.sh gained a vpn-data-mount case (state lives in tagged /etc/fstab entries, not $DOCKER_DIR, since this isn't a Docker service) — mirrors wordpress's "count real instances" handling rather than a flat 0/1. - Every SSH call in the new service explicitly runs as $ACTUAL_USER (sudo -u), not root — the script itself runs as root throughout, but the SSH key lives in $ACTUAL_HOME/.ssh, so a bare `ssh` call would silently use root's own ~/.ssh instead and never find it. Caught by review before this shipped, not after. - UNATTENDED mode skips outright with a message instead of spinning forever on prompt_text's always-blank default under --unattended, since none of this flow's prompts (home box IP, remote path, ...) have a sane non-interactive default.	2026-08-10 17:56:50 +00:00

Author

SHA1

Message

Date

Claude

9e5a84f4f5

Don't blindly overwrite existing Samba config; stop clobbering shared account passwords

Reported live: the tool unconditionally reconfigured Samba even though
"Samba already installed on the home box" was already correctly detected —
that check only ever covered whether the smbd package exists, never
whether a share for the requested path (or the Samba account itself) was
already set up. Two real problems, not just a UX one:

1. Every run appended/replaced a [share] block and reset the target
   account's password unconditionally, even against a share the user had
   already configured by hand.
2. Since the Samba account is the SSH username (shared across every mount
   from the same home box), setting up a SECOND mount from the same box
   would silently reset the account's password — breaking the FIRST
   mount's already-saved credentials file with no warning.

Now: checks the remote smb.conf for an existing share exporting the exact
requested path first (via a plain SSH+awk query) and offers to reuse it
as-is (prompting for its real credentials, since a Samba password is
stored hashed and can't be read back) instead of overwriting it. If
creating a new share, checks whether this tool already set a password for
the same user+host pair (from another mount) and reuses it instead of
resetting the account; if the account exists with an unknown password
(set up some other way), asks rather than silently clobbering it.

_vdm_find_remote_share/_vdm_find_existing_smb_password/_vdm_prompt_password
are all called via command substitution by their caller, so none of them
call log_info/log_warning/etc. internally — those all write to stdout in
this codebase, which would corrupt the captured value. Verified the awk
share-lookup and the fstab-tag password lookup against sample data.

2026-08-10 19:15:11 +00:00

Claude

28252b97d3

Fix vpn-data-mount's guest-mount errno 79 bug, add per-share SMB accounts,

host naming, and chain-in from filebrowser/audiobookshelf/emby

Reported live: "mount error(79): Can not access a needed shared library"
on the local CIFS mount step. That message is misleadingly worded — errno
79 is ENOKEY, not a real missing-library problem, and a plain `guest`
mount with no explicit `sec=` hitting it against a real Samba server is a
known cifs-utils/kernel-cifs rough edge in the anonymous-session keyring
path. Fixed as a side effect of switching away from guest access per
direct request (real per-share Samba accounts, not root/guest, matching
"user accounts for data directories"): each mount now gets a dedicated
Samba account (reusing the SSH username — that Unix account already
exists on the home box) with a generated password, remotely provisioned
via smbpasswd over the same SSH trust, and mounted locally via a
root-only credentials file (same convention tools/mount-network-drive.sh
already uses) plus an explicit sec=ntlmssp instead of guest.

Host naming: entering a raw IP now offers to name it in /etc/hosts, then
uses that name for everything from then on (SSH commands, the CIFS mount
address, and re-runs against the same IP). Deliberately /etc/hosts, not
~/.ssh/config — an SSH Host alias only helps the `ssh` command resolve a
name, mount.cifs never consults ~/.ssh/config at all, so an alias alone
wouldn't get the actual mount using a name. Still offers to also add a
matching SSH Host alias on top (pure convenience — skips typing the
username for interactive ssh use) when services/ssh-config.sh's helpers
are available.

Chain-in: filebrowser/audiobookshelf/emby now offer to run
vpn-data-mount first if their data is on a home box that isn't mounted
yet, and default their own directory prompt to whatever was just mounted
(VDM_LAST_MOUNT_POINT, explicitly unset before each chain call so an
unrelated earlier vpn-data-mount run in the same setup.sh session can't
leak its mount point in as a stale default).

2026-08-10 18:37:59 +00:00

Claude

0e42de1cda

Add vpn-data-mount: SMB mount from a NetBird-connected home box

Offered right after NetBird setup during required/base setup, matching
the requested flow (base packages -> NetBird -> data mount). Repeatable
by design rather than a one-shot step, since different services can have
data on different home boxes — asks for a home box IP every time and can
be run again for additional boxes/shares.

Flow: test for existing passwordless SSH first (covers "both boxes already
share a key via GitHub import, or any other means" for free — if it
already works, nothing else runs). If not, generate an SSH keypair and
offer ssh-copy-id or a manual/GitHub-import fallback (ssh-import-id, the
same mechanism base.sh's own SSH setup already uses) — needed because a
home box that took base.sh's "disable password login" option won't accept
ssh-copy-id at all. Once passwordless SSH works, use it to remotely
install and configure Samba on the home box for a chosen path, then mount
it locally over CIFS with a tagged /etc/fstab entry.

SMB over NFS/SSHFS per this session's direction: not a "huge" speed gap
for normal use, and SSHFS's own encryption is redundant overhead once the
VPN tunnel already encrypts everything. Guest-accessible (no separate
Samba credentials) since the VPN is the real access control — only
NetBird-connected peers can reach the home box's NetBird IP at all.

Also:
- cifs-utils added to base.sh's always-installed packages, same reasoning
  as Docker/Compose being unconditional there instead of installed lazily
  on first mount.
- is_installed()/install_count() in setup.sh gained a vpn-data-mount case
  (state lives in tagged /etc/fstab entries, not $DOCKER_DIR, since this
  isn't a Docker service) — mirrors wordpress's "count real instances"
  handling rather than a flat 0/1.
- Every SSH call in the new service explicitly runs as $ACTUAL_USER
  (sudo -u), not root — the script itself runs as root throughout, but the
  SSH key lives in $ACTUAL_HOME/.ssh, so a bare `ssh` call would silently
  use root's own ~/.ssh instead and never find it. Caught by review before
  this shipped, not after.
- UNATTENDED mode skips outright with a message instead of spinning
  forever on prompt_text's always-blank default under --unattended, since
  none of this flow's prompts (home box IP, remote path, ...) have a
  sane non-interactive default.

2026-08-10 17:56:50 +00:00