Hi Tom, Comments inline.
Sorry for the delayed response as I was on vacation. A quick inspection of the repository structure for GT6 versus GT5 eliminates a number of my complaints.
http://toolkit.globus.org/ftppub/gt5/5.2/ <http://toolkit.globus.org/ftppub/gt5/5.2/> (e.g. I believe stable points to 5.2.2)
http://toolkit.globus.org/ftppub/gt6/stable/deb/ <http://toolkit.globus.org/ftppub/gt6/stable/deb/>
deb http://toolkit.globus.org/ftppub/gt6/stable/deb <http://toolkit.globus.org/ftppub/gt6/stable/deb> wheezy contrib
deb http://toolkit.globus.org/ftppub/gt6/testing/deb <http://toolkit.globus.org/ftppub/gt6/testing/deb> wheezy contrib
would be
deb http://toolkit.globus.org/ftppub/gt6/deb <http://toolkit.globus.org/ftppub/gt6/deb> wheezy contrib
deb http://toolkit.globus.org/ftppub/gt6/deb <http://toolkit.globus.org/ftppub/gt6/deb> wheezy testing
But this is a major improvement to the old directory structure. So kudos!
Thanks!
Comment 1: when you're managing N machines, it's much easier to know the sources.list entries and the signing key. Automated provisioning software (Foreman + preseed, for example) tend to be unfriendly toward unsigned packages. Not impossible, but it's much easier when the documentation just tells you the right path and points you to the key and you don't have to export it manually from the GPG file. I can see why a .deb is easier for Joe Sixpack walking up with one computer, but it's not easier for me.
This is mostly a documentation issue. We can pubish a directory of the repo configuration files and gpg key and include a link to that from the documentation in addition to the repo packages. I created an issue for this. Weâll add this to our todoâs.
https://globus.atlassian.net/browse/GT-626 <https://globus.atlassian.net/browse/GT-626>
Comment 2: Do you intend for the stable repositories to contain the past history of releases even when they have been superseded? I hope so as this facilitates version pinning without being accidentally left behind.
We keep older versions in the repository. So, you can specify an older version in case you need to back out from an update that goes bad, or stay pinned to a specific version if need be.
Comment 3: What is the closest repository to "proposed" in Debian-speak? i.e. a release that is going into the wild that, should no bug reports be filed, will be moved unchanged into stable.
We have âStableâ, âUnstableâ and âTestingâ repos for each GT release version. Described here:
http://toolkit.globus.org/toolkit/docs/latest-stable/admin/install/#idp36524752
The Testing repo would be the closest to Debian âproposedâ. Once we/Globus developers determine packages are ready, packages move from Testing to Stable. âproposedâ could be an email announcement and delay of those packages in the Testing repo in order to allow the Globus community to do additional testing. I donât know if we actually want to do this delay, just thinking out loud.
I am not sure how much consider gsisshd to be a part of the Toolkit, but it's the most important part of the toolkit that I use, with gridftp being one step down in importance. I believe that a lot of these problems still exist, at least in the latest 5.2 series releases. We (LIGO, the scientific collaboration for whom I work) repackage your packages to get around the bugs.
https://globus.atlassian.net/browse/GT-492 <https://globus.atlassian.net/browse/GT-492>
Yeah, we think we have these resolved in GT6. Let us know if you find otherwise.
I am dealing with a number of physical plant issues in the data center right now, so I can't step through and re-create them on GT6. However, I was just standing over my coworker's shoulder and was surprised to see that GT6's gsi-openssh-server still installed it's startup/shutdown script into /etc/init.d on Debian 8, otherwise now on systemd.
This has been in our backlog, but a low priority since the non-systemd methods still normally work.
--
Tom Downes
Senior Scientist and Data Center Manager
Center for Gravitation, Cosmology and Astrophysics
University of Wisconsin-Milwaukee
414.229.2678
Post by j***@upel.edu.veI agree with Tom.
Maybe you could comment more specifically on what you intend for admins of OSes such as Debian 7 Wheezy which appear to include GT 5.2 based libraries but also promise security support through 201X, X>5?
Sorry for the delayed response. Iâve been thinking about this some and plan to reply once the Globus team gets a chance to discuss this some more.
Post by j***@upel.edu.veI have not always found the globus.org <http://globus.org/> repositories to be Debian-friendly so I'm not sure 5.2.X from debian.org <http://debian.org/> to 6.X from globus.org <http://globus.org/> is a clean upgrade path.
Iâd encourage you to give the Globus GT6 repo a try. We'd be very motivated to help work through any problems you run into. We definitely want the Globus repos to be "Debian-friendly".
Post by j***@upel.edu.veTom
Dear GT users,
We are announcing an end-of-life date for GT 5.2.5. Starting November 1, 2015, we will no longer support or maintain GT 5.2.5 or earlier versions of the Globus Toolkit. We believe this is sufficient notice for users of GT 5.2.5 to plan and complete their upgrade to GT6.
GT 6 was released in September 2014 and we are encouraging all users to move to this version as it provides multiple benefits over past releases. In particular, GT 6 has significantly simplified the building, testing, and distributing of the Toolkit, making it much easier for the developers to generate updates with bug fixes and new features, and for admins to install and maintain. We are currently working with package maintainers for EPEL, Fedora, Debian, and Ubuntu to ensure that the latest updates to GT6 are available quickly and included in these distributions. The latest GT release may be downloaded from: http://toolkit.globus.org/toolkit/downloads/6.0/ <http://toolkit.globus.org/toolkit/downloads/6.0/>.
Note that a GT release that is at end of life is: not supported, not receiving any updates (no minor, major, security fixes of any kind), and is not being built or tested on new OS versions. As with most open source projects, we have limited resources and many competing priorities so it is not possible for us to cost-effectively maintain multiple past releases if we are to continue delivering new features and improvements.
Thanks for your continued support of Globus.