HZW Documentation

From hzw wiki
Revision as of 12:29, 19 May 2020 by Ori (talk | contribs) (Outsourced Ansible part)
Jump to navigation Jump to search
Documentation. Lots of documentation.

The documentation of all things HZW has the following philosophy:

  1. General information, processes, methods and how-to's get documented in this Wiki
  2. Physical and Logical Resources like Servers, IPs, Networks, Services, VLANs etc. get documented in Netbox
  3. Projects and changes get tracked using Kanboard


Organizational Documentation

Chat

Our primary tool for communication and coordination is matrix.

To join our matrix server matrix.kabelsalat.it you need a matrix client like riot.

On this Matrix server, there is the "hzw admins" channel.


Plase report there and ask if it's ok If you make changes that have an impact.

Example:

"Hey guys, did $Something at the Database server. Can I reboot it to test it's reboot persistency?"

Answer: "No! $Important-thingy does $important-thing and cannot be disrupted right now! Wait one more hour please!"


Video Conferences

For means of faster communication and collaborative working we use our video conferencing solutions, if needed.

There are no regular hzw meetings. We get together when the need arises.


Coordinate projects

We use kanboard to plan, coordinate and track almost all of our activities.


Kanboard.png


Please open a ticket in our Kanban Board "team_hzw" if you want to:

  • report a bug
  • request a change
  • think I would be cool to have $thing (even if you don't want to spend time implementing it or don't know how to do it)


Technical Documentation

Our Root Server

We are unsing a Root Server hosted at Strato.

Technical Details

Server CPU Cores / Frequency Hard Drives RAM
Root Server

Linux C6-62

Intel® Xeon® E5-1650v3

Haswell

6 x 3,5 GHz

(max. Turbo: 3,8 GHz)

2 x 2.000 GB &

2 x 240 GB SSD

128 GB

DDR 4 ECC


Installed Software

There is only KVM and Ansible installed on the server.

We do NOT want to have stuff running on the Server besides KVM and Ansible.

If you want to do something in the HZW environment, create a VM for it.


Disks and Partitions

There are 2x  ~200GB SSDs (sda/sdb) and 2 ~2TB HDDs running in RAID 1.

The Mountpoint "/boot" is on partition md0, that consists of sda1 and sdb1 (SSD).

The Mountpoint "/" is on partition md1, that consists of sda3 and sdb3 (SSD).

SPAP Space is on sda2 and sdb2.

The Mountpoint "/data" is on partition md2, that consists of sdc1 and sdd1 (HDD).

Partitions.png


Network

Interface Configuration

The interfaceconfig of the server is written in netplan.

/etc/netplan/01-netcfg.yaml

CONTENT KOMMT, WENN DIE OFFENE KARTE https://kb.kabelsalat.it/?controller=TaskViewController&action=show&task_id=443&project_id=14 ERLEDIGT IST

NAT (Port Forwardings)

We are using iptables on this server to perform NAT.

Here is a little script I wrote so you can generate a list of the currently enabled portforwardings.

/scripts/kvm_get_portforwardings.sh

CONTENT KOMMT, WENN DIE OFFENE KARTE https://kb.kabelsalat.it/?controller=TaskViewController&action=show&task_id=443&project_id=14 ERLEDIGT IST

HA Proxy

Port 80 and 443 of incomming traffic is beeing sent to a haproxy.

The Haproxy VM is documented here.

Haproxy is using ALCs based on the SNI Field to route the traffic to VMs in the backend.

This makes it possible multiple VMs using those ports.

This is what the haproxy configuration looks like for the site you are looking at right now:

/etc/haproxy/haproxy.cfg

CONTENT KOMMT, WENN DIE OFFENE KARTE https://kb.kabelsalat.it/?controller=TaskViewController&action=show&task_id=443&project_id=14 ERLEDIGT IST

Virtual Machines

All virtual Machines providing services (e.g. not for testing purposes) should be linux have had the basic ansible playbook run on them.


Netbox

We are using Netbox to document all physical and Logical Resources like Servers, IPs, Networks, Services, VLANs etc.

Netbox



What is Netbox?

NetBox is an open source web application designed to help manage and document computer networks.

Initially conceived by the network engineering team at DigitalOcean, NetBox was developed specifically to address the needs of network and infrastructure engineers.

It encompasses the following aspects of network management:

  • IP address management (IPAM) - IP networks and addresses, VRFs, and VLANs
  • Equipment racks - Organized by group and site
  • Devices - Types of devices and where they are installed
  • Connections - Network, console, and power connections among devices
  • Virtualization - Virtual machines and clusters
  • Data circuits - Long-haul communications circuits and providers
  • Secrets - Encrypted storage of sensitive credentials


What NetBox Is Not

While NetBox strives to cover many areas of network management, the scope of its feature set is necessarily limited. This ensures that development focuses on core functionality and that scope creep is reasonably contained. To that end, it might help to provide some examples of functionality that NetBox does not provide:

  • Network monitoring
  • DNS server
  • RADIUS server
  • Configuration management
  • Facilities management

That said, NetBox can be used to great effect in populating external tools with the data they need to perform these functions.


Design Philosophy

NetBox was designed with the following tenets foremost in mind.


Replicate the Real World

Careful consideration has been given to the data model to ensure that it can accurately reflect a real-world network. For instance, IP addresses are assigned not to devices, but to specific interfaces attached to a device, and an interface may have multiple IP addresses assigned to it.


Serve as a "Source of Truth"

NetBox intends to represent the desired state of a network versus its operational state. As such, automated import of live network state is strongly discouraged. All data created in NetBox should first be vetted by a human to ensure its integrity. NetBox can then be used to populate monitoring and provisioning systems with a high degree of confidence.


Keep it Simple

When given a choice between a relatively simple 80% solution and a much more complex complete solution, the former will typically be favored. This ensures a lean codebase with a low learning curve.

Guides

Guide to documenting with Mediawiki

Guide to documenting with Kanboard

Guide to documenting with Netbox