Thread: [Openbsdbinpatch-misc] Patch for /var/db/binpatch stuff

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Here's a patch that creates /var/db/binpatch, creates a file for the patch being 
created and copies the PLIST into it and copies that file to /var/db/binpatch in 
the actual binpatch tarball.

-ME

2007/1/11, Mike Erdely <mi...@er...>:
> Here's a patch that creates /var/db/binpatch, creates a file for the patch being
> created and copies the PLIST into it and copies that file to /var/db/binpatch in
> the actual binpatch tarball.

But, isn't it a job for patch_add?

If we make a difference between a build server (binpatch framework)
and patch tools (patch_*) I think the later should handle
/var/db/binpatch.

-- 
Gerardo Santana

Gerardo Santana G=F3mez Garrido wrote:
> 2007/1/11, Mike Erdely <mi...@er...>:
>> Here's a patch that creates /var/db/binpatch, creates a file for the=20
>> patch being
>> created and copies the PLIST into it and copies that file to=20
>> /var/db/binpatch in
>> the actual binpatch tarball.
>=20
> But, isn't it a job for patch_add?

There currently isn't a(n) (official) patch_add.

> If we make a difference between a build server (binpatch framework)
> and patch tools (patch_*) I think the later should handle
> /var/db/binpatch.

Unless you want to keep it simple and have the binpatch "tools" be option=
al.  If=20
you have all of the components in the tarball, it doesn't matter whether =
you use=20
patch_add or tar, the result should be the same.

-ME

On Fri, 12 Jan 2007, Gerardo Santana G=F3mez Garrido wrote:
> If we make a difference between a build server (binpatch framework)
> and patch tools (patch_*) I think the later should handle
> /var/db/binpatch.

I agree.

--=20
Antoine
Mike Erdely wrote:
> Gerardo Santana G=F3mez Garrido wrote:
>> If we make a difference between a build server (binpatch framework)
>> and patch tools (patch_*) I think the later should handle
>> /var/db/binpatch.
>=20
> Unless you want to keep it simple and have the binpatch "tools" be opti=
onal.  If=20
> you have all of the components in the tarball, it doesn't matter whethe=
r you use=20
> patch_add or tar, the result should be the same.

No comments about this?  I think the goal should be to keep binpatch simp=
le.  As=20
an example, if someone were to write a front-end to PF, you'd still want =
to be=20
able to "vi /etc/pf.conf" and have the same functionality, right?

-ME

On 16/01/07, Mike Erdely <mi...@er...> wrote:
> Mike Erdely wrote:
> > Gerardo Santana G=F3mez Garrido wrote:
> >> If we make a difference between a build server (binpatch framework)
> >> and patch tools (patch_*) I think the later should handle
> >> /var/db/binpatch.
> >
> > Unless you want to keep it simple and have the binpatch "tools" be opti=
onal.  If
> > you have all of the components in the tarball, it doesn't matter whethe=
r you use
> > patch_add or tar, the result should be the same.
>
> No comments about this?  I think the goal should be to keep binpatch simp=
le.  As
> an example, if someone were to write a front-end to PF, you'd still want =
to be
> able to "vi /etc/pf.conf" and have the same functionality, right?
>
> -ME

The patch_* tools could be included in the binpatch distribution as
they're not exactly very big but I agree that we should keep binpatch
simple and let the user use whatever tools they wish to install the
tarballs. Some old-school admins will always use tar no matter what
tools are provided.

2007/1/16, Mike Erdely <mi...@er...>:
> Mike Erdely wrote:
> > Gerardo Santana G=F3mez Garrido wrote:
> >> If we make a difference between a build server (binpatch framework)
> >> and patch tools (patch_*) I think the later should handle
> >> /var/db/binpatch.
> >
> > Unless you want to keep it simple and have the binpatch "tools" be opti=
onal.  If
> > you have all of the components in the tarball, it doesn't matter whethe=
r you use
> > patch_add or tar, the result should be the same.
>
> No comments about this?  I think the goal should be to keep binpatch simp=
le.  As
> an example, if someone were to write a front-end to PF, you'd still want =
to be
> able to "vi /etc/pf.conf" and have the same functionality, right?

Agreed, totally.

the patch_* tools would be a pair of convenient scripts, nothing more,
that handle patch information as mentioned before.

We can package those scripts in a binpatch package as you suggest, but
it will not prevent anybody to just untar them.

And still I think that a patch_add script should handle /var/db/binpatch.

What I would like to see next is z0mbix's scripts making use of your
idea of optional mirrors for downloading binpatches, as well as
verifying signatures.

--=20
Gerardo Santana

Here's what I've knocked up so far if you want to test it out:

#!/bin/sh
#
# This is just a wrapper script that installs binpatch patches and logs the
# date and time and a list of what files were installed. See the binpatch
# website for more information on binary patching your OpenBSD system:
#
# http://openbsdbinpatch.sourceforge.net/
#
# Author: z0mbix (zombie | at | zombix | dot | org)
# Date:   19/01/06
#
# Version: 0.5 - Added support for downloading binpatches and gzsig verific=
ation
#

RELEASE=3D`uname -r`
ARCH=3D`machine`
DATE=3D`date '+%b %d %Y %T'`
PATCHNO=3D$1
PATCHDBDIR=3D/var/db/binpatch
DBFILE=3D${PATCHDBDIR}/install.log
PATCHFILE=3Dbinpatch-$RELEASE-$ARCH-$PATCHNO.tgz
SIGNKEY=3D~/.ssh/id_rsa.pub       # Set to NO if not required

# Check for one argument:
if [ $# !=3D 1 ]; then
        echo "usage: patch_add 001"
        exit 1
fi

# Try to get from BINPATCH_PATH if it doesn't exist in cwd:
if [ ! -f $PATCHFILE ]; then
        # Use standard ftp in non-verbose mode and save in cwd:
        ftp -VEa $BINPATCH_PATH/$PATCHFILE
fi

# Try to install from cwd:
if [ -f $PATCHFILE ]; then
        # Check if the user wants to check gzsig:
        if [ "${SIGNKEY}" !=3D "NO" ]; then
                # Check gzsig and exit if not verified:
                if ! gzsig verify -q ${SIGNKEY} $PATCHFILE; then
                        echo "$PATCHFILE NOT verified with key
${SIGNKEY}. Exiting!"
                        exit 1
                else
                        echo "$PATCHFILE verified with key ${SIGNKEY}"
                fi
        fi

        # Create db directory if it does not exist:
        if [ ! -d ${PATCHDBDIR}/$RELEASE/$PATCHNO ]; then
                mkdir -p ${PATCHDBDIR}/$RELEASE/$PATCHNO

                # Create file list for this binpatch:
                tar tzf $PATCHFILE > ${PATCHDBDIR}/$RELEASE/$PATCHNO/FILES

                # Check if binpatch includes kernel updates:
                if grep "^./bsd$"
${PATCHDBDIR}/$RELEASE/$PATCHNO/FILES > /dev/null; then
                        echo "Kernel Update!"
                        echo " Backing up /bsd to /bsd.old"
                fi

                if grep "^./bsd.mp$"
${PATCHDBDIR}/$RELEASE/$PATCHNO/FILES > /dev/null; then
                        cp /bsd.mp /bsd.mp.old
                fi

                # Actually unpack the binpatch tarball in /:
                tar xzpvf "$PATCHFILE" -C /

                # Update install file with new patch details:
                echo "$RELEASE-$ARCH-$PATCHNO installed: ${DATE}" |
tee -a ${DBFILE}

                # Cleanup binpatch file:
                rm $PATCHFILE
        else
                echo "Directory ${PATCHDBDIR}/$RELEASE/$PATCHNO already exi=
sts!"
                echo "If you are re-installing this patch, remove this
directory"
                echo "and re-run patch_add $PATCHNO"
        fi
else
        echo "Could not find: $PATCHFILE"
fi

I'll tidy this up some more tomorrow, but atleast a simple
implementation so far. Just set BINPATCH_PATH in your shell.

Cheers z0mbix

On 17/01/07, Gerardo Santana G=F3mez Garrido <ger...@gm...> wr=
ote:
> 2007/1/16, Mike Erdely <mi...@er...>:
> > Mike Erdely wrote:
> > > Gerardo Santana G=F3mez Garrido wrote:
> > >> If we make a difference between a build server (binpatch framework)
> > >> and patch tools (patch_*) I think the later should handle
> > >> /var/db/binpatch.
> > >
> > > Unless you want to keep it simple and have the binpatch "tools" be op=
tional.  If
> > > you have all of the components in the tarball, it doesn't matter whet=
her you use
> > > patch_add or tar, the result should be the same.
> >
> > No comments about this?  I think the goal should be to keep binpatch si=
mple.  As
> > an example, if someone were to write a front-end to PF, you'd still wan=
t to be
> > able to "vi /etc/pf.conf" and have the same functionality, right?
>
> Agreed, totally.
>
> the patch_* tools would be a pair of convenient scripts, nothing more,
> that handle patch information as mentioned before.
>
> We can package those scripts in a binpatch package as you suggest, but
> it will not prevent anybody to just untar them.
>
> And still I think that a patch_add script should handle /var/db/binpatch.
>
> What I would like to see next is z0mbix's scripts making use of your
> idea of optional mirrors for downloading binpatches, as well as
> verifying signatures.
>
> --
> Gerardo Santana
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share y=
our
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> Openbsdbinpatch-misc mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openbsdbinpatch-misc
>

Gerardo Santana G=F3mez Garrido wrote:
> 2007/1/16, Mike Erdely <mi...@er...>:
>> I think the goal should be to keep binpatch simple.
> Agreed, totally.
>=20
> the patch_* tools would be a pair of convenient scripts, nothing more,
> that handle patch information as mentioned before.

If that's the case, creation of the /var/db/binpatch files should not dep=
end on=20
things available just for convenience, IMO.

> We can package those scripts in a binpatch package as you suggest, but
> it will not prevent anybody to just untar them.
 > And still I think that a patch_add script should handle /var/db/binpat=
ch.

What you're suggesting, though is that using a script and using tar will =
present=20
different results.

-ME

2007/1/17, Mike Erdely <mi...@er...>:
> Gerardo Santana G=F3mez Garrido wrote:
> > 2007/1/16, Mike Erdely <mi...@er...>:
> >> I think the goal should be to keep binpatch simple.
> > Agreed, totally.
> >
> > the patch_* tools would be a pair of convenient scripts, nothing more,
> > that handle patch information as mentioned before.
>
> If that's the case, creation of the /var/db/binpatch files should not dep=
end on
> things available just for convenience, IMO.
>
> > We can package those scripts in a binpatch package as you suggest, but
> > it will not prevent anybody to just untar them.
>  > And still I think that a patch_add script should handle /var/db/binpat=
ch.
>
> What you're suggesting, though is that using a script and using tar will =
present
> different results.
>
> -ME

I see your point.

Our difference arises probably from my belief that /var/db/binpatch is
a convenience too.

But even if I were the first patchtools enthusiast and supporter, I'd
look back to the ports subsystem. I don't see a target in bsd.port.mk
that handles /var/db/pkg directly; it's the pkgtools that handle
/var/db/pkg.

--=20
Gerardo Santana

Gerardo Santana G=F3mez Garrido wrote:
> I see your point.
>=20
> Our difference arises probably from my belief that /var/db/binpatch is
> a convenience too.
>=20
> But even if I were the first patchtools enthusiast and supporter, I'd
> look back to the ports subsystem. I don't see a target in bsd.port.mk
> that handles /var/db/pkg directly; it's the pkgtools that handle
> /var/db/pkg.

Even before "make install" ran pkg_add in ports, /var/db/pkg was created =
using=20
bsd.port.mk.

I guess it doesn't matter.  If it's not imported into CVS for bsd.binpatc=
h.mk,=20
I'll just patch my local copy.

-ME