Hi Jim, first of all thanks for your efforts! Although I don't have a clear picture here, my biggest concern would be breaking upstream compatibility for fairly special case. Would we run that risk?
Cheers Stefan ________________________________________ Von: Jim Klimov [jimkli...@cos.ru] Gesendet: Dienstag, 26. November 2013 23:19 An: openindiana-discuss@openindiana.org Betreff: Re: [OpenIndiana-discuss] Split-root installations On 2013-11-26 19:23, Irek Szczesniak wrote: > cut, cat and grep are ksh builtins. Use builtin <cmdname> (run builtin > --man to read details) to enable them by default and then remove the > absolute paths so the shell doesn't search PATH for them. > Most nawk usage can be replaced by ksh pattern matching, leaving > sort(1) as the only command to worry about. Thanks for the suggestions, and they did help me convert the scripts for iptun and physical:default into code that does not complain when run without /usr (certainly not an exhaustive test, but at least the near-default cases work well now). Scripts did become uglier a bit, especially when NAWK was replaced by bulkier shell constructs, but in exchange there is one less subprocess type to fork :) For good old ipconfig based on /etc/hostname.* files (and DHCP) this can easily be made to work with a minimal root filesystem and ksh93. For ipadm and for NWAM - not so, a working /usr is needed by those. The NWAM method script is heavily dependent on /usr, with calls to SMF admin commands, LDAP client and so on, and there is no easy way to make it fully executable in absence of /usr (possibly one might carve out some pre- and post- /usr logic to split into two services... but what for?) I wonder how (un)acceptable would it be to enhance the fs-root script instead - when it makes sure that /usr/bin is available (the /usr is mounted), it could invoke "svcadm restart" of the active instance of the network/physical service (if any) and perhaps iptun which depends on this. This would probably be proper after the script calls devfsadm to detect devices for newly mounted drivers (which may include more NICs than were available on rootfs). In the end, I think this problem boils down to specific cases with opposite dependencies, since the "clean" way to do this is with SMF somehow: 1) / and /usr are local (ZFS, UFS, whatever) and don't depend on the network (NFS, iSCSI, whatever) - then "network/physical" should depend on "filesystem/root"; 2) these filesystems (both or one) depend on networking to be active and provided by the OS (i.e. GRUB which TFTP/PXE-boots a miniroot over LAN is probably not the use-case) - then the filesystems' SMF services should depend on networking services. Although it can be argued that /etc/fs/nfs/mount depends on at least /usr/lib/libsmbios.so.1, so the miniroot which boots the server and mounts the NFS root would (by default) have some /usr of its own... Ultimately, these can be (and are) different "root" service instances which can have very different dependency graphs... What would the esteemed community experts suggest? Thanks, //Jim _______________________________________________ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ________________________________ Acando GmbH, Millerntorplatz 1, 20359 Hamburg, Germany | Geschäftsführer: Guido Ahle | Amtsgericht Hamburg, HRB 76048 | Ust.Ident-Nr.:DE208833022 _______________________________________________ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
