From fd1522763e561724a75892d5e122518590642880 Mon Sep 17 00:00:00 2001 From: Brian Lin Date: Mon, 16 Dec 2024 12:45:43 -0600 Subject: [PATCH 1/2] Clean out various stale docs --- docs/policy/bestman2-retire.md | 32 ---- docs/policy/globus-toolkit.md | 40 ----- docs/policy/gridftp-gsi-migration.md | 89 ----------- docs/policy/gums-retire.md | 52 ------- docs/policy/service-migrations-spring-2018.md | 141 ------------------ docs/policy/voms-admin-retire.md | 103 ------------- docs/projects/sha2-support.md | 23 --- mkdocs.yml | 8 - 8 files changed, 488 deletions(-) delete mode 100644 docs/policy/bestman2-retire.md delete mode 100644 docs/policy/globus-toolkit.md delete mode 100644 docs/policy/gridftp-gsi-migration.md delete mode 100644 docs/policy/gums-retire.md delete mode 100644 docs/policy/service-migrations-spring-2018.md delete mode 100644 docs/policy/voms-admin-retire.md delete mode 100644 docs/projects/sha2-support.md diff --git a/docs/policy/bestman2-retire.md b/docs/policy/bestman2-retire.md deleted file mode 100644 index d68acad91d..0000000000 --- a/docs/policy/bestman2-retire.md +++ /dev/null @@ -1,32 +0,0 @@ - -BeStMan2 Retirement -===================== - -This document provides an overview of the planned retirement of support for BeStMan in the OSG Software Stack. - -Introduction ------------- - -BeStMan2 is a standalone implementation of a subset of the Storage Resource Manager v2 (SRMv2) protocol. SRM was meant to be a high-level management protocol for site storage resources, allowing administrators to manage storage offerings using the abstraction of "storage tokens." Additionally, SRM can be used to mediate transfer protocol selection. - -OSG currently supports BeStMan2 in "gateway mode" -- in this mode, SRM is only used for metadata operations (listing directory contents), listing total space used, and load-balancing GridFTP servers. This functionality is redundant to what can be accomplished with GridFTP alone. - -BeStMan2 has not received upstream support for approximately five years; the existing code base (about 150,000 lines of Java - similar in size to Globus GridFTP) and its extensive set of dependencies (such as JGlobus) are now quite outdated and would require significant investment to modernize. OSG has worked at length with our stakeholders to replace SRM-specific use cases with other equivalents. We believe none of our stakeholders require sites to have an SRM endpoint: this document describes the site transition plan. - -Site Transition Plans ---------------------- - -We have released documentation -for a configuration of GridFTP that takes advantage of Linux Virtual Server (LVS) for load balancing between multiple -GridFTP endpoints. - -Sites should work with their supported VOs (typically, CMS or ATLAS) to identify any VO-specific usage and replacement plans for BeStMan2. - -Timeline --------- - -- March 2017 (completed): - Release load balanced GridFTP documentation -- June 2017 (completed): OSG 3.4.0 is released without BeStMan -- December 2018 (completed): Security-only support for OSG 3.3 series and BeStMan is provided -- May 2018 (completed): Support is dropped for OSG 3.3 series; no further support for BeStMan is provided. diff --git a/docs/policy/globus-toolkit.md b/docs/policy/globus-toolkit.md deleted file mode 100644 index 4091e5399f..0000000000 --- a/docs/policy/globus-toolkit.md +++ /dev/null @@ -1,40 +0,0 @@ -OSG Support of the Globus Toolkit -================================= - -!!! note "Gridftp and GSI Migration Plan" - In December 2019, the OSG developed a plan for migrating the OSG Software stack away from GridFTP and GSI that can - be found [here](gridftp-gsi-migration.md). - -6 June 2017 - -Many in the OSG community have heard the news about the end of support for the open-source Globus Toolkit (formerly -available from https://github.com/globus/globus-toolkit/blob/globus_6_branch/support-changes). - -What does this imply for the OSG Software stack? -Not much: OSG support for the Globus Toolkit (e.g., GridFTP and GSI) will continue for as long as stakeholders need it. -Period. - -Note the OSG Software team provides a support guarantee for all the software in its stack. -When a software component reaches end-of-life, the OSG assists its stakeholders in managing the transition to new -software to replace or extend those capabilities. -This assistance comes in many forms, such as finding an equivalent replacement, adapting code to avoid the dependency, -or helping research and develop a transition to new technology. -During such transition periods, OSG takes on traditional maintenance duties (i.e., patching, bug fixes and support) of -the end-of-life software. -The OSG is committed to keep the software secure until its stakeholders have successfully transitioned to new software. - -This model has been successfully demonstrated throughout the lifetime of OSG, including for example the five year -transition period for the BestMan storage resource manager. -The Globus Toolkit will not be an exception. Indeed, OSG has accumulated more than a decade of experience with this -software and has often provided patches back to Globus. - -Over the next weeks and months, we will be in contact with our stakeholder VOs, sites, and software providers to discuss -their requirements and timelines with regard to GridFTP and GSI. - -Please reach out to [goc@opensciencegrid.org](mailto:goc@opensciencegrid.org) with your questions, comments, and -concerns. - -Change Log ----------- - -**8 October 2020** Add note linking to the GridFTP and GSI migration plan diff --git a/docs/policy/gridftp-gsi-migration.md b/docs/policy/gridftp-gsi-migration.md deleted file mode 100644 index c1db71e446..0000000000 --- a/docs/policy/gridftp-gsi-migration.md +++ /dev/null @@ -1,89 +0,0 @@ -GridFTP and GSI Migration -========================= - -6 December 2019 - -Introduction ------------- - -The GridFTP protocol (for data transfer) and GSI (as an Authentication and Authorization Infrastructure, AAI) were -selected for the OSG ecosystem nearly 15 years ago. -In both cases, approaches are becoming increasingly niche; as they have not become widely adopted - indeed, as the -communities dramatically shrink while the Internet ecosystem grows - the support costs are increasingly directly -shouldered by the OSG. - -For example, we currently use the GridFTP and GSI implementations in the Grid Community Toolkit (GCT). -While the OSG contributes to the GCT (a fork of the abandoned Globus Toolkit) to sustain operations, the long-term plan -is to migrate our community off these approaches. -The end of the Globus Toolkit is a stark reminder of how niche the current ecosystem is: even the original reference -implementation was abandoned. - -Thus, OSG has the opportunity and motivation to evolve toward a data transfer protocol and security techniques that -better fit our needs and allow us to connect to more vibrant software communities. -For the data transfer, we are proposing HTTP; for the AAI, we are proposing the use of bearer tokens, HTTPS, and OAuth2. - -The production-oriented nature of the OSG — and the embedding of OSG-LHC in the WLCG community — means that -careful coordination, communication, and planning are needed whenever we migrate away from production services. -OSG has executed several such technology transitions before and managing the full software lifecycle is part of our -value to stakeholders. This document proposes affected services, replacement technologies, and rough timelines for a -transition. - -Timeline --------- - -The following table contains the major milestones and deliverables for the entire transition. -Detailed migration plans can be found [in this document](https://docs.google.com/a/wisc.edu/document/d/1DAFeAaUmHHVcJGZMTIDUtLs9koCruQRDY1sJq1opeNs/edit?usp=sharing). - -| **Date** | **Milestone or Deliverable** | **Completed** | -|------------|--------------------------------------------------------------------------------------------------------|---------------| -| Aug 2019 | Beginning of OSG 3.5 release series (last release series depending on GCT) | ✅ | -| Aug 2019 | Including HTCondor 8.9.2 in the ‘upcoming’ repository (first HTCondor version with SciTokens support). | ✅ | -| Oct 2019 | OSG no longer carries OSG-specific patches for the GCT. All patches are upstreamed or retired. | ✅ | -| Mar 2020 | "GSI free" site demo. Show, at proof-of-concept / prototype level, all components without use of GCT. | ✅ | -| Sep 2020 | All GCT-free components are in OSG-Upcoming. | ✅ | -| Feb 2021 | OSG series 3.6, without GCT dependencies, is released. | ✅ | -| 1 May 2022 | End of support for OSG 3.5. | ✅ | - -Frequently Asked Questions --------------------------- - -### How does SciTokens interoperate with other token technologies in the WLCG? ### - -The `scitokens-cpp` library used by OSG can transparently use both WLCG JSON Web Tokens (JWTs) and SciTokens. - -### Will a US-LHC migration from GridFTP to XRootD require the same migration for WLCG? ### - -No but we have been working to ensure that we coordinate our activities through the WLCG DOMA group. - -### What role does LCMAPS play with SciTokens? ### - -LCMAPS only works with GSI. -The model for SciTokens is sufficiently more simple for sites that the full complexity of LCMAPS is not needed. - -### What does a SciTokens transition for GlideinWMS mean for European sites? ### - -The only piece that involves European sites is the factory to CE relationship: -given HTCondor-CE 4.0 already supports SciTokens, we have begun to engage with the ARC-CE team. - -### What are the T1s going to do? No SRM? How does tape work with XRootD and HTTPS? ### - -Note that CTA, which CERN is planning to transition to this year, only has XRootD support. - -We don't think there's a clear HTTPS picture here (or a clear dCache picture for SRM-free) so there will need to be -coordination with other groups (e.g. the QoS working group). - -### Can WLCG-FTS handle both SciTokens and x509 certificates at the same time? ### - -Yes. - -### Can PhEDEx handle SciTokens? ### - -Yes. - -Version History ---------------- - -- **2021-03-05**: Updated dates for the initial OSG 3.6 release and the targeted OSG 3.5 retirement -- **2020-03-30**: Completed GSI-free site demonstration -- **2020-03-17**: Highlighted delay in Jan 2020 milestone and new expected completion date of Mar 2020 -- **2020-03-16**: Updated completed items on the overall timeline; added link for detailed document diff --git a/docs/policy/gums-retire.md b/docs/policy/gums-retire.md deleted file mode 100644 index a534ed62c6..0000000000 --- a/docs/policy/gums-retire.md +++ /dev/null @@ -1,52 +0,0 @@ - -GUMS Retirement -=============== - -This document provides an overview of the planned retirement of support for GUMS in the OSG Software Stack. - -Introduction ------------- - -GUMS (Grid User Management System) is an authentication system used by OSG resource providers to map grid credentials to -local UNIX accounts. It provides OSG site adminstrators with a centrally managed service that can handle requests from -multiple hosts that require authentication e.g., HTCondor-CE, GridFTP, and XRootD servers. In discussion with the OSG -community, we have found that sites use the following GUMS features: - -- Mapping based on VOMS attributes -- Host-based mappings -- Banning users/VOs -- Supporting pool accounts - -GUMS is a large Java web application that is more complex than necessary for the subset of features used in the -OSG. Additionally, upstream support has tailed off and as a result, the maintenance burden has largely fallen on the OSG -Software team. - -OSG's plans to retire GUMS has two major components: - -- Find a suitable replacement for GUMS -- Provide documentation, tooling, and support to aid in the transition from GUMS to the intended solution - -Site Transition Plans ---------------------- - -We have released a configuration of the LCMAPS authorization framework that performs distributed verification of VOMS -extensions. This configuration, referred to as the LCMAPS VOMS plugin, supports VOMS attribute based mappings as well as -user and VO banning. Host-based mappings are not supported however, the simplicity of the plugin's installation and -the distributed verification of VOMS extensions makes this feature unnecessary. - -Pool accounts are not supported by the plugin but this feature will be addressed in an upcoming transition-specific -document. The intended solution will revolve around mapping local user accounts via user grid mapfile and we will work -with any site for which this solution does not work. - -LCMAPS VOMS plugin installation and configuration documentation can be -found here (formerly: lcmaps-voms-authentication). - -Timeline --------- - -- April 2017 (completed): `lcmaps-plugins-voms` shipped and supported by OSG. -- May 2017 (completed): `osg-configure` and documentation necessary for using `lcmaps-plugins-voms` is shipped. -- June 2017 (completed): OSG 3.4.0 is released without VOMS-Admin, `edg-mkgridmap`, or GUMS. -- July 2017 (completed): OSG 3.4 CEs can be configured with 3.3 GUMS hosts -- March 2018: Complete transition for sites not using pool accounts -- May 2018: Support is dropped for OSG 3.3 series; no further support for GUMS is provided. diff --git a/docs/policy/service-migrations-spring-2018.md b/docs/policy/service-migrations-spring-2018.md deleted file mode 100644 index 4bf1b4b3bb..0000000000 --- a/docs/policy/service-migrations-spring-2018.md +++ /dev/null @@ -1,141 +0,0 @@ -Service Migrations - Spring 2018 -================================ - -The Open Science Grid (OSG) has transitioned effort from Indiana, requiring a redistribution of support and services. -Some services were retired, most services were migrated to other locations (with minimal expected sites impact), -and some services were migrated that resulted in significant impact on sites. - -This document was intended to guide OSG site administrators through these changes, highlighting where the site -administrator action is required. - -If you have questions or concerns that are not addressed in this document, see the [Getting Help section](#getting-help) -for details. - -Getting Help ------------- - -If you have questions or concerns that are not addressed in this document, please contact us at the usual locations: - -- [help@osg-htc.org](mailto:help@osg-htc.org) -- [software-discuss@opensciencegrid.org](mailto:software-discuss@opensciencegrid.org) - - General discussion of the OSG Software stack - ([subscribe](https://listserv.fnal.gov/scripts/wa.exe?SUBED1=SOFTWARE-DISCUSS&A=1)) -- [Slack channel](https://opensciencegrid.slack.com/messages/osg-software) - if you can't create an account, - send an e-mail to [help@osg-htc.org](mailto:help@osg-htc.org) - -Support Changes ---------------- - -The Footprints ticketing system at `https://ticket.opensciencegrid.org` was used to track support and security issues as -well as certificate and membership requests. -This service was retired in favor of two different ticketing systems, depending on the VOs you support at your site: - -| If your site primarily supports... | Submit new tickets to... | -|------------------------------------|--------------------------------------------------| -| LHC VOs | [GGUS](https://ggus.eu) | -| Anyone else | [Freshdesk](https://support.opensciencegrid.org) | - -If you experience any problems with ticketing, please contact us at -[help@osg-htc.org](mailto:help@osg-htc.org). - -Service-specific details ------------------------- - -### OSG CA ### - -The OSG CA service offered certificate request, renewal, and revocation through the [OIM](#myosg-and-oim) web interface, -the OIM REST API, and the `osg-pki-tools` command-line tool. -This service was retired on May 31 but the OSG CA certificate remains in the IGTF distribution, so any certificates -issued by the OSG CA remain valid until they expire. - -The OSG recommends using the following CA certificate services: - -| For... | We plan to use the following Certificate Authorities... | -|--------------------|-------------------------------------------------------------------------------------| -| Host Certificates | [InCommon](https://www.incommon.org/) and [Let’s Encrypt](https://letsencrypt.org/) | -| User Certificates | [CILogon Basic](https://cilogon.org/) for non-LHC users | -| | LHC users should continue to request their user certificates from CERN. | -| Web-Based services | [Let's Encrypt](https://letsencrypt.org) | - -!!! note - The semantics of Let's Encrypt certificates are different from those of previous CAs. - Please see - [the security team's position on Let's Encrypt](https://www.opensciencegrid.org/security/LetsEncryptOSGCAbundle/) - for the security and setup implications of switching to a Let's Encrypt host or service certificate. - -If you experience any problems acquiring host or service certificates, please contact us at -[help@osg-htc.org](mailto:help@osg-htc.org). - - -### Software Repository ### - -The OSG Software repository includes the YUM repositories, client tarballs, and CA tarballs. -The physical hosting location changed during the migration but was otherwise unchanged. - -If you experience any problems with the OSG Software repository, please contact us at -[help@osg-htc.org](mailto:help@osg-htc.org). - -### MyOSG and OIM ### - -The MyOSG service used to provide web and REST interfaces to access information about OSG resource topology, projects, -and VOs. -The MyOSG web interface was retired but we continue to offer the same REST interface at . - -OIM served as the database for the information used by MyOSG with a web -interface for data updates. -The OIM web interface was retired but its data was migrated to the [topology repository](https://github.com/opensciencegrid/topology/). -Updates to the aforementioned data can be requested via email or pull request. - -!!! note - Please see the [OSG CA](#osg-ca) section for information regarding the OIM certificate service. - -If you experience any problems with MyOSG or the topology repository, please contact us at -[help@osg-htc.org](mailto:help@osg-htc.org). - -### GRACC Accounting and WLCG Accounting ### - -No changes were made to the [GRACC accounting](https://gracc.opensciencegrid.org/d/000000074/gracc-home?orgId=1) -service during the service migration. - -If you experience any problems with GRACC accounting, please contact us at -[help@osg-htc.org](mailto:help@osg-htc.org). - -### OASIS and CVMFS ### - -The OASIS (OSG Application and Software Installation Service) is a service used to distribute common applications and -software to OSG sites via CVMFS. -The OSG hosts a CVMFS Stratum-0 for keysigning, a repository server, and a CVMFS Stratum-1. -The physical hosting location of these services were moved to Nebraska without any other changes. - -If you experience any problems with OASIS or CVMFS, please contact us at -[help@osg-htc.org](mailto:help@osg-htc.org). - -### VOMS Admin Server ### - -The OSG VOMS service was used to sign VOMS attributes for members of the OSG VO and responded to queries for a list of -VO members. -[VOMS Admin Server is deprecated](../policy/voms-admin-retire.md) in the OSG and the OSG VOMS servers were retired as planned. - -### RSV ### - -The central RSV service was a monitoring tool that displayed every service status information about OSG sites that -elected to provide it. -It was retired since there was no longer a need to monitor OSG site status as a whole. -If you would like to monitor your OSG services, you can access the status page of your local -RSV instance. - -### Collector ### - -The central Collector is a central database service that provides details about -pilot jobs currently running in the OSG. -The physical hosting location of the central Collector was moved but there were no other changes. - -If you experience any problems with the central Collector, please contact us at -[help@osg-htc.org](mailto:help@osg-htc.org). - -### Homepage ### - -The [OSG homepage](https://osg-htc.org) was a Wordpress instance that has been moved to a static site. - -If you experience any problems with the homepage, please contact us at -[help@osg-htc.org](mailto:help@osg-htc.org). diff --git a/docs/policy/voms-admin-retire.md b/docs/policy/voms-admin-retire.md deleted file mode 100644 index f4643f8d99..0000000000 --- a/docs/policy/voms-admin-retire.md +++ /dev/null @@ -1,103 +0,0 @@ - -VOMS-Admin Retirement -===================== - -Introduction ------------- - -This document provides an overview of the planned retirement of support for VOMS-Admin -in the OSG Software Stack. - -Support for the VOMS infrastructure has three major components: - -1. *VOMS-Admin*: A web interface for maintaining the list of authorized users in - a VO and their various authorizations (group membership, roles, attributes, etc). -2. *VOMS-Server*: A TCP service which signs a cryptographic extension on an X509 - proxy certificate asserting the authorizations available to the authenticated user. -3. *VOMS Client*: Software for extracting and validating the signed VOMS extension from - an X509 proxy. The validation is meant to be distributed: the VOMS client does not - need to contact the VOMS-Admin server. However, OSG has historically used software - such as GUMS or `edg-mkgridmap` to cache a list of authorizations from the VOMS-Admin - interface, creating a dependency between VOMS client and VOMS-Admin. - -VOMS-Admin is a large, complex Java web application. Over the last -few years, upstream support has tailed off - particularly as OSG has been unable -to update to VOMS-Admin version 3. As a result, the maintenance burden has largely -fallen on the OSG Software team. - -Given that VOMS-Admin is deeply tied to X509 security infrastructure - and is -maintenance-only from OSG Software - there is no path forward to eliminate the use -of X509 certificates in the web browser, a high-priority goal - -In discussions with the OSG community, we have found very few VOs utilize VOMS-Admin -to manage their VO users. Instead, the majority use VOMS-Admin to whitelist a pilot -certificate: this can be done without a VOMS-Admin endpoint. - -OSG's plans to retire VOMS-Admin has three major components: - -- (Sites) Enable distributed validation of VOMS extensions in the VOMS client. -- (VOs) Migrate VOs that use VOMS only for pilot certificates to direct signing - of VOMS proxies. -- (VOs) Migrate remaining VOs to a central `comanage` instance for managing user - authorizations; maintain a plugin to enable direct callouts from VOMS-Server - to `comanage` for authorization lookups. - -Site Transition Plans ---------------------- -We will release a configuration of the LCMAPS authorization framework that performs -distributed verification of VOMS extensions; this verification eludes the need to -contact the VOMS-Admin interface for a list of authorizations. - -In 2015/2016, LCMAPS and GUMS were upgraded so GUMS skips the VOMS-Admin lookup when -LCMAPS asserts the validation was performed. Hence, when GUMS sites update clients to the -latest (April 2017) LCMAPS and HTCondor-CE releases, the callout to VOMS-Admin is no longer -needed. _Note_: In parallel to the VOMS-Admin transition, OSG Software plans to [retire GUMS](../policy/gums-retire.md). -There is no need to complete one transition before the other. - -Sites using `edg-mkgridmap` will need to use its replacement, `lcmaps-plugins-voms` (this -process is documented [here](https://www.osg-htc.org/docs/release/release_series/#migrating-from-edg-mkgridmap-to-lcmaps-voms-plugin)). - -VO Transition Plans -------------------- - -Based on one-to-one discussions, we believe the majority of VOs only use VOMS-Admin to maintain -a list of authorized pilots. For these VOs, we will help convert invocations of `voms-proxy-init`: - -``` -voms-proxy-init -voms hcc:/hcc/Role=pilot -``` - -to an equivalent call to `voms-proxy-fake`: - -``` -voms-proxy-fake -hostcert /etc/grid-security/voms/vomscert.pem \ - -hostkey /etc/grid-security/voms/vomskey.pem \ - -fqan /hcc/Role=pilot/Capability=NULL \ - -voms hcc -uri hcc-voms.unl.edu:15000 -``` - -The latter command would typically be run on the VO's glideinWMS frontend host, requiring the service certificate -currently on the VOMS-Admin server to be kept on the frontend host. The frontend's account may also need access -to the certificate. - -!!! info - See [this documentation](https://osg-htc.org/docs/other/install-gwms-frontend/#proxy-configuration) to - update your GlideinWMS Frontend to use the new proxy generation command. - -We plan to transition more complex VOs - those using VOMS-Admin to track membership in a VO - to `comanage`. It is -not clear there are any such VOs that need support from OSG. If there are, a hosted version of `comanage` is expected -to be available in summer 2017 from the CILogon 2.0 project. If you feel your VO is affected, please contact the -OSG and we will build a custom timeline. If there are no such VOs, we will not need to adopt `comanage` for this -use case (other uses of `comanage` are expected to proceed regardless). - -Timeline --------- - -- April 2017 (completed): `lcmaps-plugins-voms` shipped and supported by OSG. -- May 2017 (completed): `osg-configure` and documentation necessary for using `lcmaps-plugins-voms` is shipped. -- June 2017 (completed): OSG 3.4.0 is released without VOMS-Admin, `edg-mkgridmap`, or GUMS. Sites begin transition - to validating VOMS extensions. -- Summer 2017 (completed): As necessary, VOs are given access to a hosted `comanage` instance. -- March 2017 (completed): First VOs begin to retire VOMS-Admin. -- May 2018 (completed): Support is dropped for OSG 3.3 series; no further support for VOMS-Admin or GUMS is provided. - diff --git a/docs/projects/sha2-support.md b/docs/projects/sha2-support.md deleted file mode 100644 index 422a26396c..0000000000 --- a/docs/projects/sha2-support.md +++ /dev/null @@ -1,23 +0,0 @@ -SHA-2 Compliance -================ - -When a certificate authority signs a certificate, it uses one of several possible hash algorithms. -Historically, the most popular algorithms were MD5 (now retired due to security issues) and the SHA-1 family. -SHA-1 certificates are being phased out due to perceived weaknesses — as of February 2017, a practical attack for generating collisions was demonstrated by [Google researchers](https://shattered.io/static/shattered.pdf). - These days, the preferred hash algorithm family is SHA-2. - -The certificate authorities (CAs), which issue host and user certificates used widely in the OSG, defaulted to SHA-2-based certificates on 1 October 2013; all sites will need to make sure that their software supports certificates using the SHA-2 algorithms. All supported OSG releases support SHA-2. - -The table below denotes indicates the minimum releases necessary to support SHA-2 certificates. - -| Component | Version | In Release | Notes | -|:------------------------|:--------------------------------------------------------------------------------------------------------------------------------------------|:-----------|:------------------------------------------------------------------| -| BeStMan 2 | bestman2-2.3.0-9.osg | 3.1.13 | SHA-2 support; also see jGlobus, below | -| dCache SRM client | dcache-srmclient-2.2.11.1-2.osg | 3.1.22 | Major update includes SHA-2 support | -| Globus GRAM | globus-gram-job-manager-13.45-1.2.osg, globus-gram-job-manager-condor-1.0-13.1.osg, globus-gram-job-manager-pbs-1.6-1.1.osg | 3.1.9 | Critical bug fixes (not SHA-2 specific) | -| GUMS | gums-1.3.18.009-15.2.osg | 3.1.13 | Switched to jGlobus 2 with SHA-2 support; also see jGlobus, below | -| jGlobus (for BeStMan 2) | jglobus-2.0.5-3.osg | 3.1.18 | Fixed CRL refresh bug (not SHA-2 specific) | -| VOMS | voms-2.0.8-1.5.osg | 3.1.17 | SHA-2 fix for voms-proxy-init | - -If a component does not appear in the above table, it already has SHA-2 support. - diff --git a/mkdocs.yml b/mkdocs.yml index d8e9ba75b2..b57e314d68 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -48,7 +48,6 @@ nav: - COManage SOP: 'operations/comanage-sop.md' - COmanage Troubleshooting Guide: 'operations/comanage-troubleshooting-guide.md' - Policy: - - GridFTP and GSI Migration: 'policy/gridftp-gsi-migration.md' - Campus Cyberinfrastructure: 'policy/campus-cyberinfrastructure.md' - Collaborations and Bearer Tokens: 'policy/collab-bearer-tokens.md' - CREAM-CE Support: 'policy/cream-support.md' @@ -66,13 +65,6 @@ nav: - Reviewing Documentation: 'documentation/reviewing-documentation.md' - Markdown Style Guide: 'documentation/style-guide.md' - Publishing OSG pages: 'documentation/publish-osg-pages.md' - - Historical Transitions: - - Service Migrations - Spring 2018: 'policy/service-migrations-spring-2018.md' - - GUMS Retirement: 'policy/gums-retire.md' - - BeStMan2 Retirement: 'policy/bestman2-retire.md' - - VOMS Admin Retirement: 'policy/voms-admin-retire.md' - - SHA-2 Support: 'projects/sha2-support.md' - - Migrating Documents to Markdown: 'documentation/markdown-migration.md' - Meetings: - December 3, 2024: 'meetings/2024/TechArea20241203.md' - November 5, 2024: 'meetings/2024/TechArea20241105.md' From 5db377984f6cb2ccd7ee70b800cc9f2519695a5d Mon Sep 17 00:00:00 2001 From: Brian Lin Date: Mon, 16 Dec 2024 12:47:12 -0600 Subject: [PATCH 2/2] Clean out stale mailing lists There are a few other verboten mailing lists but we need to sort out the replacements with the project office --- docs/policy/campus-cyberinfrastructure.md | 4 ++-- docs/policy/new-ospool-user.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/policy/campus-cyberinfrastructure.md b/docs/policy/campus-cyberinfrastructure.md index 7c242a53b8..14d8e8b3df 100644 --- a/docs/policy/campus-cyberinfrastructure.md +++ b/docs/policy/campus-cyberinfrastructure.md @@ -54,10 +54,10 @@ To contribute computational resources to the OSG, the following will be needed: - Installation of some additional packages on the local cluster, IF the site would like to maximize its ability to support users, including those with large per-job data, containerized software, and/or GPU jobs. -(There ARE some exceptions to the above. [Contact us](mailto:support@opensciencegrid.org) to discuss them!) +(There ARE some exceptions to the above. [Contact us](mailto:support@osg-htc.org) to discuss them!) !!!success "Next steps" - If you are interested in OSG-offered services, please [contact us](mailto:support@opensciencegrid.org) for a + If you are interested in OSG-offered services, please [contact us](mailto:support@osg-htc.org) for a consultation, even if your site does not meet all the conditions as outlined above! Additional Materials diff --git a/docs/policy/new-ospool-user.md b/docs/policy/new-ospool-user.md index fdf964eb2d..3de259061a 100644 --- a/docs/policy/new-ospool-user.md +++ b/docs/policy/new-ospool-user.md @@ -70,4 +70,4 @@ finalized and you will be able to login to the system. Getting Help ------------ -For assistance or questions, please email the support team at +For assistance or questions, please email the support team at