Update links under users, providers and internal sections (#502)

sebastian-luna-valero · gwarf · web-flow · commit 15ed0b800ecf · 2022-09-06T17:53:10.000+02:00
* Fix links, run prettier

Co-authored-by: Baptiste Grenier &lt;baptiste.grenier@egi.eu&gt;
diff --git a/content/en/internal/_index.md b/content/en/internal/_index.md
@@ -28,4 +28,4 @@ considered when developing a product for the EGI Federation.
 ## Request for information
 
 You can ask for more information about the internal EGI services
-[on our site](https://www.egi.eu/more-information).
+[on our site](https://www.egi.eu/contact-us).
diff --git a/content/en/internal/helpdesk/account-and-privileges/_index.md b/content/en/internal/helpdesk/account-and-privileges/_index.md
@@ -69,8 +69,8 @@ from the GGUS team (usually) confirming their supporter privileges.
 ### Registration with the EGI AAI account
 
 Users who do not have a valid X509 certificate can access GGUS via
-[EGI Check-in](../../../users/check-in). For getting support privileges the user
-needs to be member of the
+[EGI Check-in](../../../users/aai/check-in). For getting support privileges the
+user needs to be member of the
 [ggus-supporters](https://aai.egi.eu/registry/co_petitions/start/coef:69) group
 in EGI Check-in. However the user should fill in the
 [registration form](https://ggus.eu/?mode=register_info) for creating an account
diff --git a/content/en/internal/monitoring/_index.md b/content/en/internal/monitoring/_index.md
@@ -17,7 +17,8 @@ the user interface in a user-friendly way. It provides automated reporting tools
 with minimal development or operational effort for setting up monitoring.
 
 {{% alert title="Note" color="info" %}} Documentation for Service Monitoring is
-available [on the ARGO site](https://argo.egi.eu/egi/documentation).
+available
+[on the ARGO site](https://argoeu.github.io/argo-monitoring/docs/intro/).
 {{% /alert %}}
 
 ## Accessing the monitoring information
diff --git a/content/en/internal/monitoring/service-information/_index.md b/content/en/internal/monitoring/service-information/_index.md
@@ -23,6 +23,6 @@ type: "docs"
 | Source code                             | https://github.com/ARGOeu                                             |
 | Issue tracker for developers            | https://github.com/ARGOeu                                             |
 | License                                 | Apache 2.0                                                            |
-| Privacy Policy                          | https://argo.egi.eu/egi/policies                                      |
+| Privacy Policy                          | https://argo.egi.eu/egi/Critical/policies                             |
 
 <!-- markdownlint-enable no-inline-html no-bare-urls -->
diff --git a/content/en/internal/operations-portal/service-information/_index.md b/content/en/internal/operations-portal/service-information/_index.md
@@ -23,6 +23,6 @@ type: "docs"
 | Source code                             | https://gitlab.in2p3.fr/opsportal/sf3                                                              |
 | Issue tracker for developers            | https://gitlab.in2p3.fr/opsportal/sf3/-/issues                                                     |
 | License                                 | Apache 2                                                                                           |
-| Privacy Policy                          | https://operations-portal.egi.eu/home/a/termsofuse                                                 |
+| Privacy Policy                          | https://operations-portal.egi.eu/home/a/aup                                                        |
 
 <!-- markdownlint-enable no-inline-html no-bare-urls -->
diff --git a/content/en/providers/joining/core-service/_index.md b/content/en/providers/joining/core-service/_index.md
@@ -28,7 +28,7 @@ type: "docs"
 - Differently from services with a distributed nature such as HTC, Cloud, and
   Storage, they cannot be ordered through the Marketplace, but they become
   available as soon as a user joins the infrastructure (e.g., the access to the
-  [EGI Helpdesk](../../../../internal/helpdesk) service).
+  [EGI Helpdesk](../../../internal/helpdesk) service).
 
 ## Selection of the providers and registration
 
@@ -45,10 +45,10 @@ At this point, steps, similar to the ones for
 regular day-to-day operation of the service, such as:
 
 - registration in the
-  [Configuration Database](../../../../internal/configuration-database) and
+  [Configuration Database](../../../internal/configuration-database) and
   certification;
 - definition of the Support Unit in the
-  [Helpdesk](../../../../internal/helpdesk) system to handle incidents and
+  [Helpdesk](../../../internal/helpdesk) system to handle incidents and
   service requests;
 - enabling of the monitoring;
 - periodic performance reports as defined in the given OLA to verify that the
diff --git a/content/en/providers/joining/federated-resource-centre/_index.md b/content/en/providers/joining/federated-resource-centre/_index.md
@@ -25,7 +25,7 @@ the Research Infrastructure Provider (RP) existing in its country. A RP is a
 legal organisation, part of the EGI Resource Infrastructure, responsible for
 managing and operating a number of operational services at national level,
 supporting EGI RCs and user communities. Please have a look at the
-[Operations Start Guide](../../operations-start-guide) to get familiar with the
+[Operations Start Guide](../../operations-manuals/operations-start-guide/) to get familiar with the
 terms mentioned above, and to have a complete picture of the several actors
 participating in our landscape.
 
@@ -44,21 +44,21 @@ Firstly, the RC will be asked to read, understand, and accept:
   fulfilled and enforced.
 
 Secondly, the RC should be registered in the EGI
-[Configuration Database](../../../../internal/configuration-database): the
+[Configuration Database](../../../internal/configuration-database): the
 provided information, from the generic contacts and roles of people to the
 service endpoints details, is needed to trigger the daily operations of other
 services and activities provided by the EGI Infrastructure such as the
-[Monitoring](../../../../internal/monitoring) of the resources, the
-[Accounting](../../../../internal/accounting), the
-[Support](../../../../internal/helpdesk), and the
-[Security](../../../../internal/security-coordination) activities.
+[Monitoring](../../../internal/monitoring) of the resources, the
+[Accounting](../../../internal/accounting), the
+[Support](../../../internal/helpdesk), and the
+[Security](../../../internal/security-coordination) activities.
 
 ![Diagram of the RCs status flow](SiteStatusFlow.png)
 
 Once the entry in the Configuration Database is complete, the RP changes the RC
 status from “Candidate” to “Uncertified”, and the certification procedure can
 start: it comprises a
-[series of technical controls](../../../operations-manuals/howto04_site_certification_manual_tests)
+[series of technical controls](../../operations-manuals/howto04_site_certification_manual_tests/)
 to verify that the provided services work according to the expectations defined
 in the RC OLA. Any identified issue is notified by the RP operators to the RC
 and investigated until its solution.
@@ -80,7 +80,7 @@ in the management and oversight of the infrastructure.
 As defined in the RC OLA, the RC will handle
 [incidents](https://confluence.egi.eu/display/EGIG/Incident) and
 [service requests](https://confluence.egi.eu/display/EGIG/Service+request)
-registered as tickets in the [EGI Helpdesk](./../../../../internal/helpdesk)
+registered as tickets in the [EGI Helpdesk](../../../internal/helpdesk)
 service, with the expectation to acknowledge and process any notified issue,
 within the agreed response time associated with the priority of the ticket.
 
@@ -153,7 +153,7 @@ vulnerability. The status is closely monitored by the security team and
 accessible to the affected RCs.
 
 Using this information correlated with the one from
-[Pakiti](../../../../internal/security-coordination/monitoring/pakiti), the
+[Pakiti](../../../internal/security-coordination/monitoring/pakiti), the
 patch management service collecting information about the patches deployed at
 the various High Throughput Compute RCs, the Incident Response Task Force (IRTF)
 on duty Security Officer will open tickets against the impacted sites according
@@ -208,7 +208,7 @@ pay-for-use model.
 
 The result of the negotiation is a ‘Service Level Agreement’ (SLA), and several
 ‘Operation Level Agreements’ (OLA), one with each contributing provider. (See
-[https://documents.egi.eu/public/ListBy?topicid=65](SLAs-OLAs examples).)
+[SLAs-OLAs examples](https://documents.egi.eu/public/ListBy?topicid=65).)
 
 SLAs and OLAs are typically signed for at least 1 year, and are automatically
 renewed, as long as the provider(s) or the customer do not express a decision to
diff --git a/content/en/providers/joining/new-provider/_index.md b/content/en/providers/joining/new-provider/_index.md
@@ -10,10 +10,10 @@ To become a provider of one of the
 in the EGI Portfolio, you first have to become provider of a
 [federated resource centre](../federated-resource-centre). This first step
 typically requires you to become either an
-[EGI High Throughput Compute (HTC)](../../../high-throughput-compute) provider,
+[EGI High Throughput Compute (HTC)](../../high-throughput-compute) provider,
 by deploying Compute and Storage capabilities, or a Cloud service provider, by
 deploying OpenStack and federating it into the
-[EGI Cloud Compute](../../../cloud-compute) service.
+[EGI Cloud Compute](../../cloud-compute) service.
 
 Once such a foundational role is fulfilled you can configure/deploy the
 additional service within your resource centre.
diff --git a/content/en/providers/joining/technology-provider/_index.md b/content/en/providers/joining/technology-provider/_index.md
@@ -28,7 +28,7 @@ of the integration of the new piece of middleware with the infrastructure is
 reviewed and assessed.
 
 After the creation of the request in the
-[EGI Helpdesk](../../../../internal/helpdesk), with details about the
+[EGI Helpdesk](../../../internal/helpdesk), with details about the
 technology, the contacts, the expected customers, and the motivation, the
 integration steps cover the following areas (where possible, steps can be done
 in parallel):
@@ -43,16 +43,16 @@ in parallel):
 - Information System: evaluating if the new technology should publish
   information in the Information System according to the
   [GLUE Schema](http://www.ogf.org/documents/GFD.147.pdf).
-- [Monitoring](../../../../internal/monitoring): the new technology should allow
+- [Monitoring](../../../internal/monitoring): the new technology should allow
   external monitoring. If particular aspects of the technology need to be
   monitored, specific monitoring probes should be provided by the TPs and
   deployed on the EGI Monitoring service.
 - Support: the Support Unit where incidents and service requests will be
   addressed needs to be defined in the
-  [EGI Helpdesk](../../../../internal/helpdesk), associated to the
+  [EGI Helpdesk](../../../internal/helpdesk), associated to the
   [Quality of Support](https://confluence.egi.eu/display/EGISLM/Service+Level+Target+-+Quality+of+Support)
   defined in the UA.
-- [Accounting](../../../../internal/accounting): the need to gather usage data,
+- [Accounting](../../../internal/accounting): the need to gather usage data,
   which depends on the technology itself and on the infrastructure requirements
   and will be published in the
   [EGI Accounting Portal](https://accounting.egi.eu/).
@@ -66,4 +66,4 @@ in parallel):
   be provided and may be added to the [EGI Documentation](https://docs.egi.eu/).
 - Security: a security assessment of the software is required according to a
   number of guidelines defined by the
-  [EGI Security team](../../../../internal/security-coordination).
+  [EGI Security team](../../../internal/security-coordination).
diff --git a/content/en/users/_index.md b/content/en/users/_index.md
@@ -14,11 +14,11 @@ This section offers an [introduction](getting-started) to the
 [EGI services](https://www.egi.eu/services/), together with
 [tutorials](tutorials) about how to set up, use, and combine these services.
 
-{{% alert title="Note" color="info" %}} See the [Service Providers](../providers)
-section for details on how to integrate providers into the EGI Federation.
-{{% /alert %}}
+{{% alert title="Note" color="info" %}} See the
+[Service Providers](../providers) section for details on how to integrate
+providers into the EGI Federation. {{% /alert %}}
 
 ## Request for information
 
 You can ask for more information about the public EGI services
-[on our site](https://www.egi.eu/more-information).
+[on our site](https://www.egi.eu/contact-us).
diff --git a/content/en/users/data/management/rucio/admin/_index.md b/content/en/users/data/management/rucio/admin/_index.md
@@ -7,13 +7,11 @@ description: >-
   Help Rucio admins understand and perform actions for their VO
 ---
 
-Within Rucio there are several levels of administrators. There are the
-**super admins**,
-which are the staff that runs Multi-VO Rucio.
-Then there are virtual organisation (VO) specific admins that will look after
-the day-to-day operations of thier VO.
-Below are some of the tasks that VO admins will need to do to
-set up and maintain their VO.
+Within Rucio there are several levels of administrators. There are the **super
+admins**, which are the staff that runs Multi-VO Rucio. Then there are virtual
+organisation (VO) specific admins that will look after the day-to-day operations
+of thier VO. Below are some of the tasks that VO admins will need to do to set
+up and maintain their VO.
 
 ## Creating Accounts, Identities, and Quotas
 
@@ -24,7 +22,7 @@ authentication methods. The identities bind authentication methods and
 permissions to the account. The account you want to create identities for is
 input as an argument. Accounts will have different permissions and access (such
 as how much data they can store on a particular
-[RSE](https://rucio.readthedocs.io/en/latest/overview_Rucio_Storage_Element.html)).
+[RSE](https://rucio.cern.ch/documentation/rucio_storage_element)).
 
 ### CLI Example
 
@@ -64,7 +62,7 @@ True
 
 ## Creating RSE(s)
 
-[Rucio Storage Elements](https://rucio.readthedocs.io/en/latest/overview_Rucio_Storage_Element.html)
+[Rucio Storage Elements](https://rucio.cern.ch/documentation/rucio_storage_element)
 (RSEs) are how Rucio represents the physical storage available to your VO. As
 with many aspects of Rucio there are a lot of optional attributes that can be
 set for an RSE, but as a minimum a protocol for transfers need to be added
@@ -195,9 +193,9 @@ documentation or the help for the function in question.
 
 Most operations in Rucio (such as transfers, deletions, rule evaluation) require
 one or more of the
-[daemons](https://rucio.readthedocs.io/en/latest/man/daemons.html) to be running
-in order to take effect. For a multi-VO instance, these should be running for
-all VOs already. However, on new VO's joining Rucio some updating of the daemons
+[daemons](https://rucio.cern.ch/documentation/main_components) to be running in
+order to take effect. For a multi-VO instance, these should be running for all
+VOs already. However, on new VO's joining Rucio some updating of the daemons
 will be neccessary.
 
 If it seems like it is not quite right please contact the Rucio team through
@@ -206,11 +204,11 @@ If it seems like it is not quite right please contact the Rucio team through
 ## Uploading Data
 
 In Rucio files and their replicas are represented by Data IDentifiers
-([DIDs](https://rucio.readthedocs.io/en/latest/overview_File_Dataset_Container.html)),
-which are composed of a scope and name. Furthermore, multiple files can be
-attached to a dataset, which in turn can be attached to a container (which can
-be attached to another container and so on). Datasets and containers are also
-represented by DIDs.
+([DIDs](https://rucio.cern.ch/documentation/file_dataset_container)), which are
+composed of a scope and name. Furthermore, multiple files can be attached to a
+dataset, which in turn can be attached to a container (which can be attached to
+another container and so on). Datasets and containers are also represented by
+DIDs.
 
 Scopes are always associated with a particular Rucio account, and must be added
 to Rucio using an admin account. If no scope is provided when uploading, Rucio
@@ -305,8 +303,8 @@ True
 
 Once a DID exists within the Rucio catalogue, replicas of that file, dataset or
 collection are created and maintained by
-[Replication rules](https://rucio.readthedocs.io/en/latest/overview_Replica_management.html).
-By uploading a file to a particular RSE, a replication rule is created for that
+[Replication rules](https://rucio.cern.ch/documentation/replica_management). By
+uploading a file to a particular RSE, a replication rule is created for that
 file, however rules can also be added for existing DIDs. As a minimum an RSE and
 number of copies must be specified, but further options such as lifetime of the
 rule and selecting RSEs based on user set attributes are also possible.
diff --git a/content/en/users/data/management/rucio/getting-started/_index.md b/content/en/users/data/management/rucio/getting-started/_index.md
@@ -9,16 +9,16 @@ description: >-
 
 ## Rucio terms
 
-- [**Rucio Storage Element**](https://rucio.readthedocs.io/en/latest/overview_Rucio_Storage_Element.html)
+- [**Rucio Storage Element**](https://rucio.cern.ch/documentation/rucio_storage_element)
   (RSE) is another name for an endpoint, or storage solution.
-- [**Rules**](https://rucio.readthedocs.io/en/latest/replication_rules_examples.html)
-  are an instruction to Rucio to do a certain thing. This can be to ensure file
-  _x_ has at least 1 copy at _storagesite1_, or ensure file _y_ is on tape, or
-  even on tape at more than one location, or even file _z_ has 2 copies at any
-  site within a selection of sites. How you set up the RSE and the attributes
-  you give them allows for many different strategies to transfer and ordanise
-  data. Once a rule is created, Rucio will get to work to ensure that the rule
-  is satisfied at all times.
+- [**Rules**](https://rucio.cern.ch/documentation/replica_management) are an
+  instruction to Rucio to do a certain thing. This can be to ensure file _x_ has
+  at least 1 copy at _storagesite1_, or ensure file _y_ is on tape, or even on
+  tape at more than one location, or even file _z_ has 2 copies at any site
+  within a selection of sites. How you set up the RSE and the attributes you
+  give them allows for many different strategies to transfer and ordanise data.
+  Once a rule is created, Rucio will get to work to ensure that the rule is
+  satisfied at all times.
 - **File** is single file within Rucio.
 - **Dataset** is a collection of files, which may be a collection or related
   results, or data.
diff --git a/content/en/users/dev-env/binder/_index.md b/content/en/users/dev-env/binder/_index.md
@@ -12,11 +12,11 @@ description: >
 
 Binder allows the re-creation of a custom computing environment for reproducible
 execution of notebooks (and potentially many other types of applications). Users
-who create their own notebooks in the [EGI Notebooks](../notebooks/)
-to analyze data can easily create a shareable link for those notebooks in the
-form of a GitHub repository. Based on this link, anyone can then reproduce the
-same data analysis using the link in the
-[EGI Binder](https://binder.notebooks.egi.eu) service.
+who create their own notebooks in the [EGI Notebooks](../notebooks/) to analyze
+data can easily create a shareable link for those notebooks in the form of a
+GitHub repository. Based on this link, anyone can then reproduce the same data
+analysis using the link in the [EGI Binder](https://binder.notebooks.egi.eu)
+service.
 
 The service builds on [BinderHub](https://github.com/jupyterhub/binderhub), an
 Open Source tool that allows to build docker images from a Git repository and
@@ -29,14 +29,14 @@ additional features:
 - Access with academic user accounts: login via [Check-in](../../aai/check-in)
   that’s connected to eduGAIN and social media accounts.
 - Access to scalable storage: selected storage spaces of EGI DataHub are
-  directly available under the `datahub` folder, simplifying the access to shared
-  data from Binder notebooks.
+  directly available under the `datahub` folder, simplifying the access to
+  shared data from Binder notebooks.
 - Guaranteed capacity: environments have 2GB of RAM guaranteed and can reach 4GB
   as maximum.
 - Persistent sessions: There is no hard limit on the session time per user,
   although sessions will be shut down automatically after 1 hour of inactivity
   (see
-  [session limitations at the public mybinder.org service](https://mybinder.readthedocs.io/en/latest/about/about.html#using-the-mybinder-org-service)).
+  [session limitations at the public mybinder.org service](https://mybinder.readthedocs.io/en/latest/about/user-guidelines.html)).
 - Access to the rest of EGI services: a personal access token is available in
   the Binder session to interact with the rest of the EGI infrastructure.
 - Community Binder environments: User communities can have their customized
@@ -63,7 +63,8 @@ Binder facilitates the sharing and reproducibility of digital data analysis:
 ## Access to the service
 
 [EGI's Binder](https://binder.notebooks.egi.eu/) has the same access conditions
-as the [centrally operated Notebooks service from EGI](../notebooks/#service-modes).
+as the
+[centrally operated Notebooks service from EGI](../notebooks/#service-modes).
 Before using the service, you need to have an EGI account and be a member of
 [one of the supported resource pools](../notebooks/#notebooks-for-researchers)
 (alias Virtual Organisations). Follow the instructions on the
diff --git a/content/en/users/dev-env/notebooks/_index.md b/content/en/users/dev-env/notebooks/_index.md
diff --git a/content/en/users/dev-env/notebooks/kernels/matlab/_index.md b/content/en/users/dev-env/notebooks/kernels/matlab/_index.md
diff --git a/content/en/users/getting-started/_index.md b/content/en/users/getting-started/_index.md
diff --git a/content/en/users/getting-started/architecture/_index.md b/content/en/users/getting-started/architecture/_index.md
diff --git a/content/en/users/getting-started/cli/_index.md b/content/en/users/getting-started/cli/_index.md
