All, The anonymous port SMF manifest has been added to the manifest table under for your review:
http://opensolaris.org/os/community/smf/manifests/ I'd like to extend a big public "thank you" to Rich Miller. Please contact me directly with your mailing address for your very own smf(f) ceramic coffee mug (all the kool kids have them :-) Thanks Again Rich, tasha Rich Miller wrote: > I would like to make the following as a contribution to the collection of > SMF manifest files on opensolaris.org . > > The attached Service Management Facility (SMF) manifest and method files > are intended to cover a situation that occurs fairly commonly with > applications from ISVs. It has been a known practice for a long time in > the UNIX community to allocate network services ports (as defined in > /etc/services or /etc/inet/services) so that an application can > guarantee access to a specific port or ports above the default anonymous > port boundary (typically at 32768). In Solaris, this is done by setting > the kernel variable udp_smallest_anon_port using the ndd command. > > We understand that trying to reserve an anonymous port is bad practice, > but it is also a practice that has been in place for many years, has > been abetted by most vendors (e.g. Solaris' udp_smallest_anon_port), > still works with most UNIX and Linux variants, and would require a > major release from most ISVs to fix. A technique to do so is therefore > required until applications are changed. > > The standard way to do this on a Solaris system in the past has been to > create or modify the file: > /etc/rc2.d/S69inet > with the line: > ndd -set /dev/udp udp_smallest_anon_port 32800 > > This no longer works reliably (notably from Solaris 10 6/06 (update 2)) > as so much has moved to SMF that most system daemons are being started > before S69inet runs (due to its deprecated "legacy" status). Hence, > ports the application expects to be available are not being protected > soon enough in the boot process by the ndd command. In fact what > typically happens is that udp_smallest_anon_port is changed, but not > before some daemon allocates a port that it would not have had access > to later in a system boot. If that port happens to be one that an > application expects to use, then that application will typically fail > to start, often with a rather misleading error message. As of Solaris > 10 11/06 (update 3), the snmpdx, snmpXdmid, and dmispd daemons in > particular will contend for anonymous ports. > > Installation instructions and a copy of the method file are provided in > the manifest file. The manifest file simply makes execution of several > of the critical daemons dependent on the completion of the method file. > The method file just sets udp_smallest_anon_port. > > This manifest does not and cannot guarantee that all possible daemons > are blocked during a system boot until udp_smallest_anon_port is set, > but it does block the most likely system daemons. Additional > "dependent" blocks may be added to the manifest if other (especially > user installed) daemons are allocating anonymous ports in a way that > interferes with applications. > > It is NOT recommended that other system parameters be set from this > method file due to the dependency requirements. A separate manifest and > method should be used for variables that do not require that daemons be > blocked. Such a manifest is already available on the opensolaris.org > website. > > The manifest and method files have been used successfully on a variety > of Sun hardware platforms with Solaris 10 11/06. These include V240, > T2000, Ultra 40, v20z, x4100, and x4600. > > Rich Miller - Sun Microsystems > rich.miller at sun.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > smf-discuss mailing list > smf-discuss at opensolaris.org
