Controls/gitea-pages
0
2
Fork 0
Code Pull Requests Actions Activity

remove outdated page

Browse Source
This commit is contained in:
ebner
2024-08-07 13:48:48 +02:00
parent 95986aebd7
commit 7f96322e96
2 changed files with 0 additions and 101 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
_toc.yml
View File

@@ -31,7 +31,6 @@ chapters:
- file: admin-guide/architecture/overview
- file: admin-guide/architecture/accounts-and-groups
- file: admin-guide/architecture/authentication-authorization
- file: admin-guide/architecture/networking
- file: admin-guide/architecture/services-cron-etc
- file: admin-guide/architecture/version-control
- file: admin-guide/architecture/security

100
admin-guide/architecture/networking.rst
View File

@@ -1,100 +0,0 @@
============
Networking
============
The PSI network is quite fragmented and traffic is often restricted between
different subnets. As far as the Linux infrastructure is concerned we currently
distinguish two network zones: external (DMZ, Extranet, Tier3) and internal
(everything else).
Each 'zone' is supposed to have one instance of the Linux infrastructure
systems, eg Yum repository. This is not entirely true at this point, but
progress has been made towards this goal.
Within a zone all systems are allowed to connect to the respective
infrastructure systems. This page lists the exact connectivity requirements.
Requirements
============
Configuration Management and Software Distribution
--------------------------------------------------
Eventually there should be a separate Puppet server in the DMZ, but for now we
use the internal one.
======= ======================= ====================== ============= ====================
Source Destination (internal) Destination (external) Ports Purpose
------- ----------------------- ---------------------- ------------- --------------------
any puppet01 puppet01 8080, 8140 Puppet
any repos.psi.ch repos.psi.ch 80, 443 Software Packages
======= ======================= ====================== ============= ====================
Authentication
--------------
We use Active Directory for authentication, so Kerberos and encrypted LDAP
connections must be allowed to the domain controllers:
======= ======================== ====================== ============= ========================
Source Destination (internal) Destination (external) Ports Purpose
------- ------------------------ ---------------------- ------------- ------------------------
any {dc00,dc01,dc02} rodc{00,01} 88, 464, 636 AD authentication/joins
======= ======================== ====================== ============= ========================
Deployment
----------
For the successful deployment of Linux systems, the requirements below must be
met. Systems are currently not deployed in external networks (DMZ, Extranet,
Tier3), so this only applies internally.
- `Configuration Management and Software Distribution`_
- `Authentication`_
In addition, the following:
======= ============ ================ ===================
Source Destination Ports Purpose
------- ------------ ---------------- -------------------
any ??? UDP/69, 80, 443 PXE/Kickstart
======= ============ ================ ===================
Finally, having DHCP is helpful, but not necessary.
Monitoring/Reporting
--------------------
======= ====================== ====================== ============= ======================
Source Destination (internal) Destination (external) Ports Purpose
------- ---------------------- ---------------------- ------------- ----------------------
any influx00 influxdmz00 8086 Performance metrics
any rep N/A 443 Reporting (turned off)
======= ====================== ====================== ============= ======================
Configuration
=============
IPv6
----
Starting with RHEL 7 we do *not* disable IPv6 completely. We leave it on, but do
not configure any addresses. The routers at PSI also don't send router
advertisements, the DHCP server doesn't provide IPv6 addresses.
As a consequence, the network interfaces on these systems only have a link-local
address and IPv6 isn't actually used in practice. The reason for leaving IPv6
enabled is to slowly gain experience with the protocol. So far we have run into
two issues:
- In one network the router *did* send router advertisements, but the route
didn't actually work.
- Some DNS names resolve to IPv6 addresses as well as IPv4 ones. Combined with
the first issue, this caused deployment to fail on a console.