Gary Winiger writes: > I'm assuming you're not asking me to separate this into a number > of cases for the announcement, but are asking if the announcement > and removal could be bundled into the same case(s).
Right, and only for clarity. I don't think it's necessary. > The thrust of all the changes is to have all the auditd service > configuration reside in smf properties, to enable and disable > Audit via svcadm, to configure properties with svccfg or auditconfig, > with no more editing of /etc/security files. Sounds good. > Without knowing how upgrade from S10 to OpenSolaris is intended > to function, the project team is still working out details. It > would be a great help to the project team if the committee could > point the team to guidance for upgrade from S10 to OpenSolaris. > It's unclear to the project team where and whether Major or Minor > Release Binding rules are to be applied. Sigh. This is a big problem, and this isn't the only project affected by it. I don't think anybody knows the particulars around upgrade (or even whether upgrade will ever be supported), or exactly what release binding the OpenSolaris distribution has (or even if it has "releases" as we know them at all). I wish we could provide that sort of guidance. In order to do it, we'd have to have more details on what OpenSolaris *is* and how it is intended to work. We don't have those details (gang of four issue?), so we're just haphazardly applying guesses based on what we've done in the past. > I don't believe this case is about creating that guidance. I wouldn't think so, either. > > > This case also requests approval for the removal/replacement of > > > bsmrecord(1M) > > > in a Minor release. bsmrecord(1M) is to be replaced with auditrecord(1M). > > > This consists renaming of the existing bsmrecord source, binary and man > > > page > > > and replacing docs references. > > > > Would anyone be using bsmrecord in a script? Reading through the man > > page, it seems like it was intended to be used as a CGI program. If > > so, would a link to the old name be appropriate so that existing > > consumers don't break on removal? > > In the project team's experience bsmrecord is not widely used. > Its purpose is to document the contents of audit records so > docs.sun.com wouldn't require changing for every new event > added to the system. bsmrecord is usually used interactively > by the admin when analyzing the audit trail. Someone certainly > could have built a web tool that used it. Leaving a symlink > is certainly doable, but defeats the purpose of getting rid of > administrative interfaces with "bsm" in them. Again committee > guidance of Major/Minor Release Binding rules would be appreciated. I suggest the link at least because the "-h" option produces HTML, and I can't see how that'd be terribly useful outside of some sort of scripted environment -- either a CGI script or something that generates batches of files for browser inspection. I detest seeing HTML goop in email messages; I can't imagine what sort of infarction I'd suffer if I got it from an interactive command as well. ;-} I certainly don't mind if the obscure letters "bsm" disappear from all of the documentation, or if the command appears under a new name, or if the source code changes, or if the error messages it produces use a new name, but I don't think that the directory contents of /usr/sbin is itself a form of documentation, so I don't think leaving behind a link is a harmful thing for the renaming project, and it would avoid direct incompatibilities -- regardless of whether OpenSolaris has a Major or Minor release binding. As best I understand it, Major release (if that's what we indeed have) means that we "can" have incompatibilities where we need to. It doesn't mean that we "should." If the argument is just that nobody uses it, so there's no point in providing any compatibility, then as long as the project team has done the due diligence here and checked for users, I'm happy; nuke away. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
