You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@vcl.apache.org by Josh Thompson <jo...@ncsu.edu> on 2015/03/26 15:34:14 UTC
[DISCUSS] distribution of install and upgrade scripts
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
When creating the vcl-install.sh and vcl-upgrade.sh scripts, I planned to be
able to distribute them separately from the release artifacts (in addition to
being within the artifacts) so that someone only needs to download the script,
and the script will handle downloading and validating the artifact. It makes
sense to distribute them from the same dist location as the release artifacts
since that is the official release location. The scripts contain the version
number to install. Because they have a version number, they need to be
updated in the dist location for each release. However, for the same reason
that we couldn't update the 2.4 release after the bug was found in it before
we announced it, we can't just update the files with each release without
triggering a possible security issue.
As a solution, I thought maybe we could have scripts in the dist location that
have a version number as part of the file name and use symlinks to point to
the latest version, updating the symlinks at each release. However, this
doesn't work for the signature files, since the signature files have the
original filename in them (that includes the version number). So, when an
attempt to verify the signature is done, the file listed in the signature is
not found. As an example:
download vcl-install.sh (which is a symlink to vcl-install-2.4.1.sh)
download vcl-install.sh.sha1 (which is a symlink to vcl-install-2.4.1.sh.sha1)
verify .sha1 file: sha1sum -c vcl-install.sh.sha1
sha1sum: vcl-upgrade-2.4.1.sh: No such file or directory
Interestingly, verifying the .asc GnuPG signature still works.
Before attempting yet another solution that may not work, I thought I'd bring
it up on the list to seek input. What I'm thinking to do now is to add a
'scripts' directory under the dist folder. Then, add version number folders
under there, with the install and upgrade scripts in each version number
folder, like:
dist/vcl/scripts/2.4.1/vcl-install.sh
dist/vcl/scripts/2.4.1/vcl-install.sh.sha1
dist/vcl/scripts/2.4.1/vcl-install.sh.asc
dist/vcl/scripts/2.4.1/vcl-upgrade.sh
dist/vcl/scripts/2.4.1/vcl-upgrade.sh.sha1
dist/vcl/scripts/2.4.1/vcl-upgrade.sh.asc
When the next version comes out, we would just add a new release number under
the scripts folder.
Does this sound like a good idea? Other suggestions?
Thanks,
Josh
- --
- -------------------------------
Josh Thompson
VCL Developer
North Carolina State University
my GPG/PGP key can be found at pgp.mit.edu
All electronic mail messages in connection with State business which
are sent to or received by this account are subject to the NC Public
Records Law and may be disclosed to third parties.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlUUGOwACgkQV/LQcNdtPQPvTwCbBfQkNbODUBJ+q+ix6oqqvRs2
S4gAn33QxEo37/+3SS1+YGqM+hca6w7K
=2aUo
-----END PGP SIGNATURE-----
Re: [DISCUSS] distribution of install and upgrade scripts
Posted by Josh Thompson <jo...@ncsu.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I like this idea. It is straightforward and commonly used, not just at ASF.
I don't see any reason we can't go ahead and move existing files under their
own version folders. We would may need to update some documentation pages for
installs and upgrades if they link directly to downloads.
If we go this route, I'd like to go ahead and move the 2.4.1 release soon so
that things are already in place using the version folders when we announce
2.4.1.
Josh
On Thursday, March 26, 2015 12:34:38 PM Andy Kurth wrote:
> There is some flexibility in how a project's dist directory is organized.
> It seems pretty common for projects to create a directory for each
> version. We could begin doing this and put the script files in each
> version directory:
> dist/vcl/2.4.2/vcl-install.sh
> dist/vcl/2.4.2/vcl-install.sh.sha1
> dist/vcl/2.4.2/vcl-install.sh.asc
>
> We could then create a symlink named something like "current" which points
> to the most recent release:
> dist/vcl/current -> dist/vcl/2.4.2/
>
> Correct me if I'm wrong because I'm no signing expert, but wouldn't things
> work correctly if someone were to download:
> dist/vcl/current/vcl-install.sh
> dist/vcl/current/vcl-install.sh.sha1
> dist/vcl/current/vcl-install.sh.asc
>
> There is a precedent for using symlinks. See:
> https://archive.apache.org/dist/flume/
> https://archive.apache.org/dist/pig/ (using "stable" and "latest")
> https://archive.apache.org/dist/zookeeper/ (using "current" and "stable")
>
> If something like this is agreed upon, would there be anything preventing
> us from moving existing releases into directories?
>
> -Andy
>
> On Thu, Mar 26, 2015 at 10:34 AM, Josh Thompson <jo...@ncsu.edu>
>
> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > When creating the vcl-install.sh and vcl-upgrade.sh scripts, I planned to
> > be
> > able to distribute them separately from the release artifacts (in addition
> > to
> > being within the artifacts) so that someone only needs to download the
> > script,
> > and the script will handle downloading and validating the artifact. It
> > makes
> > sense to distribute them from the same dist location as the release
> > artifacts
> > since that is the official release location. The scripts contain the
> > version
> > number to install. Because they have a version number, they need to be
> > updated in the dist location for each release. However, for the same
> > reason
> > that we couldn't update the 2.4 release after the bug was found in it
> > before
> > we announced it, we can't just update the files with each release without
> > triggering a possible security issue.
> >
> > As a solution, I thought maybe we could have scripts in the dist location
> > that
> > have a version number as part of the file name and use symlinks to point
> > to
> > the latest version, updating the symlinks at each release. However, this
> > doesn't work for the signature files, since the signature files have the
> > original filename in them (that includes the version number). So, when an
> > attempt to verify the signature is done, the file listed in the signature
> > is
> > not found. As an example:
> >
> > download vcl-install.sh (which is a symlink to vcl-install-2.4.1.sh)
> > download vcl-install.sh.sha1 (which is a symlink to
> > vcl-install-2.4.1.sh.sha1)
> > verify .sha1 file: sha1sum -c vcl-install.sh.sha1
> > sha1sum: vcl-upgrade-2.4.1.sh: No such file or directory
> >
> > Interestingly, verifying the .asc GnuPG signature still works.
> >
> > Before attempting yet another solution that may not work, I thought I'd
> > bring
> > it up on the list to seek input. What I'm thinking to do now is to add a
> > 'scripts' directory under the dist folder. Then, add version number
> > folders
> > under there, with the install and upgrade scripts in each version number
> > folder, like:
> >
> > dist/vcl/scripts/2.4.1/vcl-install.sh
> > dist/vcl/scripts/2.4.1/vcl-install.sh.sha1
> > dist/vcl/scripts/2.4.1/vcl-install.sh.asc
> > dist/vcl/scripts/2.4.1/vcl-upgrade.sh
> > dist/vcl/scripts/2.4.1/vcl-upgrade.sh.sha1
> > dist/vcl/scripts/2.4.1/vcl-upgrade.sh.asc
> >
> > When the next version comes out, we would just add a new release number
> > under
> > the scripts folder.
> >
> > Does this sound like a good idea? Other suggestions?
> >
> > Thanks,
> > Josh
> > - --
> > - -------------------------------
> > Josh Thompson
> > VCL Developer
> > North Carolina State University
> >
> > my GPG/PGP key can be found at pgp.mit.edu
> >
> > All electronic mail messages in connection with State business which
> > are sent to or received by this account are subject to the NC Public
> > Records Law and may be disclosed to third parties.
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2
> >
> > iEYEARECAAYFAlUUGOwACgkQV/LQcNdtPQPvTwCbBfQkNbODUBJ+q+ix6oqqvRs2
> > S4gAn33QxEo37/+3SS1+YGqM+hca6w7K
> > =2aUo
> > -----END PGP SIGNATURE-----
- --
- -------------------------------
Josh Thompson
VCL Developer
North Carolina State University
my GPG/PGP key can be found at pgp.mit.edu
All electronic mail messages in connection with State business which
are sent to or received by this account are subject to the NC Public
Records Law and may be disclosed to third parties.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlUURpEACgkQV/LQcNdtPQORvgCfagVxMOjczEtIEVHqtJwrvyIH
vowAniZxTw0eYubSx83/IF6tEmLejN8z
=7Bif
-----END PGP SIGNATURE-----
Re: [DISCUSS] distribution of install and upgrade scripts
Posted by Andy Kurth <an...@ncsu.edu>.
There is some flexibility in how a project's dist directory is organized.
It seems pretty common for projects to create a directory for each
version. We could begin doing this and put the script files in each
version directory:
dist/vcl/2.4.2/vcl-install.sh
dist/vcl/2.4.2/vcl-install.sh.sha1
dist/vcl/2.4.2/vcl-install.sh.asc
We could then create a symlink named something like "current" which points
to the most recent release:
dist/vcl/current -> dist/vcl/2.4.2/
Correct me if I'm wrong because I'm no signing expert, but wouldn't things
work correctly if someone were to download:
dist/vcl/current/vcl-install.sh
dist/vcl/current/vcl-install.sh.sha1
dist/vcl/current/vcl-install.sh.asc
There is a precedent for using symlinks. See:
https://archive.apache.org/dist/flume/
https://archive.apache.org/dist/pig/ (using "stable" and "latest")
https://archive.apache.org/dist/zookeeper/ (using "current" and "stable")
If something like this is agreed upon, would there be anything preventing
us from moving existing releases into directories?
-Andy
On Thu, Mar 26, 2015 at 10:34 AM, Josh Thompson <jo...@ncsu.edu>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> When creating the vcl-install.sh and vcl-upgrade.sh scripts, I planned to
> be
> able to distribute them separately from the release artifacts (in addition
> to
> being within the artifacts) so that someone only needs to download the
> script,
> and the script will handle downloading and validating the artifact. It
> makes
> sense to distribute them from the same dist location as the release
> artifacts
> since that is the official release location. The scripts contain the
> version
> number to install. Because they have a version number, they need to be
> updated in the dist location for each release. However, for the same
> reason
> that we couldn't update the 2.4 release after the bug was found in it
> before
> we announced it, we can't just update the files with each release without
> triggering a possible security issue.
>
> As a solution, I thought maybe we could have scripts in the dist location
> that
> have a version number as part of the file name and use symlinks to point to
> the latest version, updating the symlinks at each release. However, this
> doesn't work for the signature files, since the signature files have the
> original filename in them (that includes the version number). So, when an
> attempt to verify the signature is done, the file listed in the signature
> is
> not found. As an example:
>
> download vcl-install.sh (which is a symlink to vcl-install-2.4.1.sh)
> download vcl-install.sh.sha1 (which is a symlink to
> vcl-install-2.4.1.sh.sha1)
> verify .sha1 file: sha1sum -c vcl-install.sh.sha1
> sha1sum: vcl-upgrade-2.4.1.sh: No such file or directory
>
> Interestingly, verifying the .asc GnuPG signature still works.
>
> Before attempting yet another solution that may not work, I thought I'd
> bring
> it up on the list to seek input. What I'm thinking to do now is to add a
> 'scripts' directory under the dist folder. Then, add version number
> folders
> under there, with the install and upgrade scripts in each version number
> folder, like:
>
> dist/vcl/scripts/2.4.1/vcl-install.sh
> dist/vcl/scripts/2.4.1/vcl-install.sh.sha1
> dist/vcl/scripts/2.4.1/vcl-install.sh.asc
> dist/vcl/scripts/2.4.1/vcl-upgrade.sh
> dist/vcl/scripts/2.4.1/vcl-upgrade.sh.sha1
> dist/vcl/scripts/2.4.1/vcl-upgrade.sh.asc
>
> When the next version comes out, we would just add a new release number
> under
> the scripts folder.
>
> Does this sound like a good idea? Other suggestions?
>
> Thanks,
> Josh
> - --
> - -------------------------------
> Josh Thompson
> VCL Developer
> North Carolina State University
>
> my GPG/PGP key can be found at pgp.mit.edu
>
> All electronic mail messages in connection with State business which
> are sent to or received by this account are subject to the NC Public
> Records Law and may be disclosed to third parties.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iEYEARECAAYFAlUUGOwACgkQV/LQcNdtPQPvTwCbBfQkNbODUBJ+q+ix6oqqvRs2
> S4gAn33QxEo37/+3SS1+YGqM+hca6w7K
> =2aUo
> -----END PGP SIGNATURE-----
>
>