Project

General

Profile

Bug #4361

Fix network/physical SMF methods to work in absence of /usr filesystem

Added by Jim Klimov over 5 years ago. Updated over 5 years ago.

Status:
New
Priority:
Normal
Assignee:
Category:
cmd - userland programs
Start date:
2013-11-26
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

Currently many routines in /lib/svc/method/net-nwam, net-physical and net-iptun as well as /lib/svc/share/* scripts rely on programs from /usr/bin. Some of these programs may have equivalents in the system shell (ksh93) builtins, others can be replaced with equivalent logic based on shell capabilities.

Due to the currently defined SMF dependencies it is problematic to cause the "network/physical" services to depend on "filesystem/root" (circular dependencies arise), and networking startup fails when /usr is a separate filesystem (see #829) due to unexecutable instructions in the method scripts.

At the moment "physical:default" starts with errors, but works for both static files and DHCP, and "physical:nwam" fails completely, during the initial startup. They do restart (on request) and complete without errors after the OS is fully up and has mounted the separated child filesystems of the rootfs.

History

#1

Updated by Jim Klimov over 5 years ago

Related issues:
  • #4367 - Move SMF management commands and libraries into root filesystem /sbin and /lib
  • #4351 - Fix packaging for ksh93 so it is delivered into /sbin/sh not as a symlink

The SMF method scripts net-physical and net-iptun, and include-scripts smf_include.sh and net_include.sh, can be amended to use ksh93 builtin commands instead of external binaries (such as cat, grep, uniq and many others), others can be replaced with shell constructs (sort, nawk in many use-cases here).

The SMF method net-nwam and likely the actual work of the daemon depends on a properly available operating environment filesystem (as in filesystem/minimal), since it can manage LDAP and NIS configurations in /var/* subdirectories.

#3

Updated by Jim Klimov over 5 years ago

This is not a proper venue to discuss the /usr split (rather, the issue #829 is, or the mailing list).

Still, my main issue is, despite what all the progress says, the image on-disk size. One way or another, I work with smallish systems with constrained disk space; at the very least, a predefined rpool size is a limiting factor for the lifetime of the installation. This ranges from old servers to small Home-NAS rigs (with expensive and thus often minimal-sized SSDs for root) to VMs... Smaller on-disk size translates into smaller cache requirements, less IOPS and less bandwidth to service the OS, as well.

The /usr filesystem contains the bulk of the OS and grows somewhat unpredictably with installed software, and even in a default installation it contains lots of well-compressible files (X11 and Java resources, etc.). With the root filesystem (the "bootfs") not supporting substantial compression, splitting off /usr and /var into gzip-9 datasets allows to save 2Gb off of a default OI GUI installation - before any application software is installed. Any substantial rewrite of this dataset, such as upgrade to a new release, wastes (monoroot) or saves (split-root) about as much, which is especially important on developer/test systems which update often and might need to keep many branches. On SSD's I'd rather find another use for these 2Gb*Num(BE's) than storing bloatware.

And, despite the decade-long dismissal of the subject (aiming for mono-root systems), the separated /usr support is still mostly in place, and things "just work". There are pretty few pieces that got out of hand as of oi_151a8 and need a chisel and hammer to also work without a /usr, all related to the routines done before the system gets to single-user milestone (such as this race between filesystem mounting and network configuration, with chicken-and-egg loops due to possibility of networked boots).

Also available in: Atom PDF