Update example IPs as per RFC 5737

https://datatracker.ietf.org/doc/rfc5737/

doc/administration/geo/replication/troubleshooting.md

@@ -622,7 +622,7 @@ This happens on wrongly-formatted addresses in `postgresql['md5_auth_cidr_addres
 ```
 
 To fix this, update the IP addresses in `/etc/gitlab/gitlab.rb` under `postgresql['md5_auth_cidr_addresses']`
-to respect the CIDR format (that is, `1.2.3.4/32`).
+to respect the CIDR format (for example, `10.0.0.1/32`).
 
 ### Message: `LOG:  invalid IP mask "md5": Name or service not known`
 
@@ -634,7 +634,7 @@ This happens when you have added IP addresses without a subnet mask in `postgres
 ```
 
 To fix this, add the subnet mask in `/etc/gitlab/gitlab.rb` under `postgresql['md5_auth_cidr_addresses']`
-to respect the CIDR format (that is, `1.2.3.4/32`).
+to respect the CIDR format (for example, `10.0.0.1/32`).
 
 ### Message: `Found data in the gitlabhq_production database!` when running `gitlab-ctl replicate-geo-database`
 
@@ -1295,7 +1295,7 @@ When [Geo proxying for secondary sites](../secondary_proxy/index.md) is enabled,
 Check the NGINX logs for errors similar to this example:
 
 ```plaintext
-2022/01/26 00:02:13 [error] 26641#0: *829148 upstream sent too big header while reading response header from upstream, client: 1.2.3.4, server: geo.staging.gitlab.com, request: "POST /users/sign_in HTTP/2.0", upstream: "http://unix:/var/opt/gitlab/gitlab-workhorse/sockets/socket:/users/sign_in", host: "geo.staging.gitlab.com", referrer: "https://geo.staging.gitlab.com/users/sign_in"
+2022/01/26 00:02:13 [error] 26641#0: *829148 upstream sent too big header while reading response header from upstream, client: 10.0.2.2, server: geo.staging.gitlab.com, request: "POST /users/sign_in HTTP/2.0", upstream: "http://unix:/var/opt/gitlab/gitlab-workhorse/sockets/socket:/users/sign_in", host: "geo.staging.gitlab.com", referrer: "https://geo.staging.gitlab.com/users/sign_in"
 ```
 
 To resolve this issue:
@@ -1345,15 +1345,8 @@ To fix this issue, set the primary site's internal URL to a URL that is:
 - Unique to the primary site.
 - Accessible from all secondary sites.
 
-1. Enter the [Rails console](../../operations/rails_console.md) on the primary site.
-
-1. Run the following, replacing `https://unique.url.for.primary.site` with your specific internal URL.
-   For example, depending on your network configuration, you could use an IP address, like
-   `http://1.2.3.4`.
-
-   ```ruby
-   GeoNode.where(primary: true).first.update!(internal_url: "https://unique.url.for.primary.site")
-   ```
+1. Visit the primary site.
+1. [Set up the internal URLs](../../../user/admin_area/geo_sites.md#set-up-the-internal-urls).
 
 ### Secondary site returns `Received HTTP code 403 from proxy after CONNECT`
 

doc/administration/gitaly/praefect.md

@@ -1107,8 +1107,8 @@ For more information on Gitaly server configuration, see our
    ```ruby
    # Configure the gitlab-shell API callback URL. Without this, `git push` will
    # fail. This can be your front door GitLab URL or an internal load balancer.
-   # Examples: 'https://gitlab.example.com', 'http://1.2.3.4'
-   gitlab_rails['internal_api_url'] = 'http://GITLAB_HOST'
+   # Examples: 'https://gitlab.example.com', 'http://10.0.2.2'
+   gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
    ```
 
 1. Configure the storage location for Git data by setting `gitaly['configuration'][:storage]` in

doc/ci/ssh_keys/index.md

@@ -156,7 +156,7 @@ trusted network (ideally, from the private server itself):
 ssh-keyscan example.com
 
 ## Or use an IP
-ssh-keyscan 1.2.3.4
+ssh-keyscan 10.0.2.2
 ```
 
 Create a new [file type CI/CD variable](../variables/index.md#use-file-type-cicd-variables)

doc/integration/kerberos.md

@@ -442,7 +442,7 @@ above error message.
 
 To fix this, ensure that the forward and reverse DNS for your GitLab server
 match. So for instance, if you access GitLab as `gitlab.example.com`, resolving
-to IP address `1.2.3.4`, then `4.3.2.1.in-addr.arpa` must be a `PTR` record for
+to IP address `10.0.2.2`, then `2.2.0.10.in-addr.arpa` must be a `PTR` record for
 `gitlab.example.com`.
 
 #### Missing Kerberos libraries on browser or client machine

doc/topics/autodevops/prepare_deployment.md

@@ -54,17 +54,17 @@ Auto DevOps requires a wildcard DNS `A` record matching the base domains. For
 a base domain of `example.com`, you'd need a DNS entry like:
 
 ```plaintext
-*.example.com   3600     A     1.2.3.4
+*.example.com   3600     A     10.0.2.2
 ```
 
-In this case, the deployed applications are served from `example.com`, and `1.2.3.4`
+In this case, the deployed applications are served from `example.com`, and `10.0.2.2`
 is the IP address of your load balancer, generally NGINX ([see requirements](requirements.md)).
 Setting up the DNS record is beyond the scope of this document; check with your
 DNS provider for information.
 
 Alternatively, you can use free public services like [nip.io](https://nip.io)
 which provide automatic wildcard DNS without any configuration. For [nip.io](https://nip.io),
-set the Auto DevOps base domain to `1.2.3.4.nip.io`.
+set the Auto DevOps base domain to `10.0.2.2.nip.io`.
 
 After completing setup, all requests hit the load balancer, which routes requests
 to the Kubernetes pods running your application.

doc/topics/autodevops/requirements.md

@@ -71,17 +71,17 @@ Auto DevOps requires a wildcard DNS `A` record that matches the base domains. Fo
 a base domain of `example.com`, you'd need a DNS entry like:
 
 ```plaintext
-*.example.com   3600     A     1.2.3.4
+*.example.com   3600     A     10.0.2.2
 ```
 
-In this case, the deployed applications are served from `example.com`, and `1.2.3.4`
+In this case, the deployed applications are served from `example.com`, and `10.0.2.2`
 is the IP address of your load balancer, generally NGINX ([see requirements](requirements.md)).
 Setting up the DNS record is beyond the scope of this document; check with your
 DNS provider for information.
 
 Alternatively, you can use free public services like [nip.io](https://nip.io)
 which provide automatic wildcard DNS without any configuration. For [nip.io](https://nip.io),
-set the Auto DevOps base domain to `1.2.3.4.nip.io`.
+set the Auto DevOps base domain to `10.0.2.2.nip.io`.
 
 After completing setup, all requests hit the load balancer, which routes requests
 to the Kubernetes pods running your application.

doc/user/project/remote_development/connect_machine.md

@@ -26,7 +26,7 @@ To connect a remote machine to the Web IDE, you must:
 
 To generate Let's Encrypt certificates:
 
-1. Create an `A` record to point a domain to your remote machine (for example, from `example.remote.gitlab.dev` to `1.2.3.4`).
+1. Create an `A` record to point a domain to your remote machine (for example, from `example.remote.gitlab.dev` to `10.0.2.2`).
 1. Install [Certbot](https://certbot.eff.org/) to enable HTTPS:
 
    ```shell