Hi Dennis et al,

Perhaps the incompatible changes to Sun internal interfaces
which required an IP Filter change could be cross-referenced
to the Sun BugIDs and/or change request IDs?
(the patch READMEs will refer to the Bug IDs and Change Requests).

These in turn can be checked at install time against PatchIDs via
"patchadd -p" and/or the Solaris build/update in the /etc/release
file,
and the correct ipf/pfil build installed or linked to.

Depends on how many variations there would be to build:
if there's lots that could be way more effort than it's worth!
It might also mean there would need to be a boot script to check
whether the environment had changed post-patch/update,
and/or a symlink adjustment to the correct kernel module variant.
Yuck. Reminds me of VxVM private copies of /usr/lib/libXXX in root...

Sounds simpler to wait until the interface settles down,
then state that the Solaris 10 pre-built binary only applies
after update (i.e. patch) such-and-such!


FYI at the moment we build one binary package for Solaris 9/SPARC.
That is distributed to all our Solaris 9/SPARC servers, which covers
most of our production systems (just under 100). So far this works
fine
(maybe we've got lucky, although there's been little/no? fundamental
change in the Solaris 9 IP stack interfaces).

On Solaris 10 we've used the versions as shipped/patched by Sun,
although we may migrate to 4.1.24 shortly. Fortunately we only
run a couple of combinations of Solaris 10 updates/patch levels,
so would probably only have 2 variants to build, and we expect
to resync them again in the next couple of months.

It's nice that Darren's Makefiles build packages with versioning
updated correctly - at least it makes it easy to track pkg versions
across all systems, e.g. with CST or whatever, even if pfil+ipf
may need to be separately built and installed on each.


A few comments in Sun bug reports state the Sun and "public"
versions (for want of a better term) have diverged quite a bit.
Just curious: is there a plan to re-converge them,
or at least cross-apply patches between each?

Rgds, Stuart.


>>> On 07-Jul-07 at 1:38 am, in message
<[EMAIL PROTECTED]>, "Dennis
Clarke"
<[EMAIL PROTECTED]> wrote:

>> Dennis Clarke wrote:
>>> ...
>>>   Better late than never.
>>>
>>>   I intended to issue a "index ipfilter" command there but messed
up. I
>>> wondered if this mail list server would also provide the source
tarballs
>>> but clearly not.   IPFilter version 4.1.24 should be released this
weekend
>>> and I thought that I could fetch it.  Ah well.
>>>
>>>   I'll wait for the release and then look at building it with
Studio 12 on
>>> Solaris 10 as well as Studio 11 on Solaris 8 and 9.  Packages to
be
>>> released via Blastwave.org etc etc.
>>>
>>
>> I'm in two minds about that...
>>
>> Quite often the open source version of ipfilter has needed a
recompile
>> after patching
>> the Solaris kernel because the networking guys changed/added
something.
>> In the
>> end, I only made sure it compiled on the latest update for any
>> particular release
>> of Solaris.
> 
>   Sounds like the pkgadd command will need to fire off a preinstall
script
> which in turns checks for the existence of a specific kernel patch.
If
> that patch is not present then return a failure.
> 
>   Sounds like a package maintainance nightmare because every package
for x86
> and Sparc would need a re-package with every kernel patch release
across
> Solaris 8 and 9 and 10.
> 
> Dennis

Reply via email to