I was REALLY impressed by your make-system, where "make package" produces a Solaris package. very very slick. SMF integration ontop of that.. GET OUT!!! (Redonkulous as Tyra would say) But alas I found a bug I'd like to report. -- Basically if you install the package directly into a sparse-zone, SMF can't go putting things in /lib///// as that is a read-only directory/fs that it can't write into. If we're in a sparse-root local zone (and that could be anytime really), only /var, /opt, and potentially /etc are in play. To be clear -- the manifest appears to load well, and looks good in /var/svc -- its the location of the start-method defined in the openSSH manifest that isn't sparse-root zone compatible. <exec_method name='start' type='method' exec='/lib/svc/method/site/opensshd start' <--- bad mojo timeout_seconds='60'> <method_context/> </exec_method> Adjusting to: exec='/opt/OpenSSH/lib/svc/method/site/opensshd start' (where /opt/OpenSSH is the --prefix) does the trick [ Aug 4 23:42:54 Executing start method ("/lib/svc/method/site/opensshd start") ] /sbin/sh: /lib/svc/method/site/opensshd: not found
(In reply to comment #0) > Basically if you install the package directly into a sparse-zone, SMF > can't go putting things in /lib///// as that is a read-only > directory/fs that it can't write into. If we're in a sparse-root local > zone (and that could be anytime really), only /var, /opt, and > potentially /etc are in play. If you want to install the package directly into a sparse-zone, you will need to crate a package with the start/stop script in a different location. Create your openssh-config.local file with SMF_METHOD_DIR=/some/other/writable/dir
using: SMF_METHOD_DIR=/some/other/writable/dir to override the default seems a good way to go. I'm checking to see if there is a STANDARD/CONVENTION in terms of where to write method files in sparse-zone situations. If there is, a ./configuration variable of "--sparsezone=yes" could facilitate some of this for users. thanks, -- MikeE
(In reply to comment #2) > If there is, a > ./configuration variable of "--sparsezone=yes" could facilitate some of > this for users. I am not sure it is worth adding complexity to the configure script for purely packaging issues.
The packaging needs some TLC: - zones should be using 'pkgcond' to check for writability - sparse zones should perhaps be inheriting global-zone installations via SUNW_PKG_ALLZONES=true and SUNW_PKG_THISZONE=false