RaumZeitLabor Wiki - Benutzerbeiträge [de]

Netzwerk

2020-02-18T19:43:59Z

Lordeis: /* 172.22.36.0/23 */

{{ProjektInfoBox
|name = Netzwerk
|status = stable
|image = Rzl-19.jpg
|description =
|category = Infrastruktur
|author =
|maintainer = NOC-Team
|owner =
|username =
|location =
|download =
}}
[[Image:Network-2013-02-10.svg|thumb|600px|Inzwischen aktuelles Netzwerkdiagramm]]
Hier wird/ist die Netzwerkstruktur im Raum dokumentiert.

== Ansprechpartner ==
Bei jeglichen Fragen zum Netz bitte das [[NOC-Team]] ansprechen, auf keinen Fall selbst Änderungen an Router oder Verkabelung vornehmen und keine IP-Adressen selber zuweisen!

== Aktuelle Probleme ==
Derzeit keine Probleme bekannt. Bitte Probleme an das [[NOC-Team]] melden.

== Rack ==
[[Datei:IMG_0336.JPG|thumb|right|x300px]]
Das [[Rack]] befindet sich in der [[E-Ecke]] und enthält das Patchpanel, unseren Switch, unseren Router sowie diverse andere Hardware, z.B. für die Türsteuerung.

== Uplink ==
Wir haben mittlerweile eine eigene Leitung. Mehr dazu gibt es unter [[Internet]].

=== IPv4 ===

Geht derzeit **direkt** raus über die Deutsche Telekom.

=== IPv6 ===

Ging früher über docsteel, wegen MTU Problemen jetzt aber über sixxs.net (Account von else). Wir announcen 2001:4dd0:fd3f::/64. Noch schöner wäre HE.net mit BGP Routing, allerdings benötigt man hierzu einen statischen IPv4 Endpoint.

'''Alle Geräte im RaumZeitLabor sind bei aktiviertem IPv6 direkt aus dem Internet erreichbar und bekommen einen festen Hostnamen'''
* z.B. ipv6-00000a1196fffe3eb30c.nutzer.raumzeitlabor.org

IPv6 reverse DNS läuft über premium.raumzeitlabor (eigener DNS).

* Reverse Delegation ist in sixxs.net gepflegt (Else)
* wird über [http://all-knowing-dns.zekjur.net/ all-knowing-dns] abgewickelt (läuft auf eigener IPv6, ipv6-rdns.raumzeitlabor.de)
* Zone für rDNS ist ipv6-*.nutzer.raumzeitlabor.org

== Sicherheit ==
Wenn du im Netzwerk (mit oder ohne Kabel) hängst, ist dein Computer im dn42.net und via IPv6 öffentlich (!) erreichbar.

== dn42 ==
Das dn42 ist ein VPN, welches Chaostreffs, Hackerspaces und sonstige Chaoten vernetzt. Siehe [http://dn42.net dn42.net]

Wir nehmen als AS64636 teil mit 9 verschiedenen Peerings (zu jchome, ichdasich, welterde, mittagessen, nobody, docsteel, Felicitus, hax404, nazco).

== WLAN ==
Unser WLAN ist WPA-verschlüsselt. Der Key hängt im Raum aus, oder wird dir gerne auf Nachfrage mitgeteilt :)

=== Aktive Access Points ===
* 2x UniFi Pro (2,4GHz und 5GHz simultan): "RZL-hardcore", "RZL-hardcore5"(5GHz only) sowie "RZL-hardcore24"(2.4GHz only).
** Liegt auf der Beamerplattform und im Nebenraum.
** Läuft mit original Firmware.
** POE über LAN Port 9 am Patchfeld(kommt auf der Plattform auf Port 10 raus, Label sind vertauscht) und Nebenraum Uplink 4.

== Hosts ==

=== Netzwerkinfrastruktur ===
* IP-Adresse bitte via DHCP beziehen, feste IP-Adressen bitte bei den obigen [[Netzwerk#Ansprechpartner|Ansprechpartnern]] anfragen.
* Subnetzmaske: 255.255.254.0
* Gateway: 172.22.36.1
* DNS-Server: '''172.22.36.250''' (direkt auf mate.rzl)
* NTP-Server: 172.22.36.1
* DHCP-Server: 172.22.36.1

=== 2001:4dd0:fd3f::/64 ===

{| class="wikitable" width="100%"
|-----
! IP-Adresse || Hostname || Beschreibung
|-----
| 2001:4dd0:fd3f:0:ba27:ebff:fe50:fafc || pinpad-main || Pinpad Haupttür
|}

=== 172.22.36.0/23 ===

{| class="wikitable" width="100%"
|-----
! IP-Adresse || Hostname || Beschreibung
|-----
| 172.22.36.1 || [[firebox]] || Router
|-----
| 172.22.36.2 || ''reserved'' || Reserviert für Infrastruktur
|-----
| 172.22.36.3 || printer0 || [[Drucker#Samsung_SCX-5530FN|Laserdrucker (Samsung SCX-5530FN)]]
|-----
| 172.22.36.4 || wlanap-01 || WLAN AP 2,4+5 GHz
|-----
| 172.22.36.5 || wlanap-02 || WLAN AP 2,4+5 GHz
|-----
| 172.22.36.6 || wlanap-03 || WLAN AP 2,4+5 GHz
|-----
| 172.22.36.6 || [[blackbox]] || [[Blackbox]] Server
|-----
| 172.22.36.7 || [[Premium_(Server)|premium]] || vServer bei Vollmar
|-----
| 172.22.36.8 || ikea-gw || IKEA TRÅDFRI Gateway
|-----
| 172.22.36.9 || cashpoint || RZL Cashpoint
|-----
| 172.22.36.10 || [[Volt]] || (neuer) VM-Host
|-----
| 172.22.36.11 || [[raspbmc]] || RPi mit Raspbmc
|-----
| 172.22.36.12 || [[cookiemonster]] || Cookiemonster (Backup-Server)
|-----
| 172.22.36.13 || [[Beamer|beamer]] || [[Beamer]]
|-----
| 172.22.36.14 || fritzbox || Fritzbox (ISDN<->SIP Ersatz)
|-----
| 172.22.36.15 || pinpad-main || [[Pinpad]] Haupttür

|-----
| 172.22.36.'''16 - 108''' || ''reserved'' || Derzeit ungenutzt
|-----
| 172.22.36.100 || skalarwelle || MikroTik POE Switch
|-----
| 172.22.36.101 || chemtrail || MikroTik 24 Port Switch
|-----
| 172.22.36.109 || r929 || [[Benutzer:nicoduck|nicoduck]]
|-----
| 172.22.36.110 || ultimaker || [[Ultimaker#Octoprint|Ultimaker]]
|-----
| 172.22.36.111 || heizung || [[Heizungssteuerung]]
|-----
| 172.22.36.112 || oszi || Rigol MSO5074
|-----
| 172.22.36.113 || ''reserved'' || Reserviert für Infrastruktur
|-----
| 172.22.36.114 || [[Fnordcredit|cashdesk]] || [[Fnordcredit|Cashpoint Backend Server]]
|-----
| 172.22.36.115 || helios || [[Benutzer:Docsteel|docsteel]]
|-----
| 172.22.36.116 || analogsprech || CISCO SPA112 Adapter für [[Raumtelefon]]
|-----
| 172.22.36.117 || artnet || DMX-Wifi-Client von s1lvester
|-----
| 172.22.36.118 || stream || Steam/Streaming Rechner am Beamer
|-----
| 172.22.36.119 || liteshow || [[InFocus LiteShow II]]
|-----
| 172.22.36.120 || nopfbook || Notebook jiska
|-----
| 172.22.36.121 || openelec || RasPi TabascoEye
|-----
| 172.22.36.122 || esper-alarm || Sonoff mit esper-Firmware für den !ping -a
|-----
| 172.22.36.123 || dance-master-5k || AVR Onkyo TX-NR646
|-----
| 172.22.36.124 ||esper-fliegenbrat || Sonoff mit esper-Firmware für das Fliegenbratgerät
|-----
| 172.22.36.125 || abrock-spike || Netbook von ABrock zum Luftfeuchtigkeitsmonitoring
|-----
| 172.22.36.126 || Chromecast || Chromecast. Hängt an einem HDMI-Eingang des Dancemaster 5k
|-----
| 172.22.36.127 || [[InfoScreen|infoscreen]] || [[InfoScreen]] auf dem Kühlschrank
|-----
| 172.22.36.128 || Leechbox || MacMini als Apple-Update-Cache
|-----
| 172.22.36.129 || fazz0r || RaspberryPI im FaZzZ0r
|-----
| 172.22.36.130 || ovencam || MR3020 am Backofen
|-----
| 172.22.36.131 || pingiepie || [[Busanzeigen|Pingie Pie++]]
|-----
| 172.22.36.132 || [[Drucker#Brother_MFC-9840CDW|guttenberg]] || Brother MFC-9840CDW aufm Olymp
|-----
| 172.22.36.133 || annette || XEROX-Drucker auf Olymp
|-----
| 172.22.36.134 || [[DMX#Spark|spark]] || DMX-Mastercontroller
|-----
| 172.22.36.135 || mpd2.rzl/iona.rzl || MPD auf dem Olymp (das Netbook im Regal).
|-----
| 172.22.36.136 || logcam.rzl || WIFI SD
|-----
| 172.22.36.'''137 - 199''' || ''reserviert'' || Ungenutzt
|-----
| 172.22.36.'''200 - 235''' || ''IP-Netz für VMs'' || IP-Adressen für die virtuellen Maschinen auf [[Mate (Server)]]
|-----
| 172.22.36.200 || [[Mate_(Server)/Datengrab|Datengrab]] || Das Datengrab
|-----
| 172.22.36.201 || [[Mate_(Server)/PartKeepr|PartKeepr]] || PartKeepr
|-----
| 172.22.36.202 || [[Mate_(Server)/Infra|Infra]] || Infra
|-----
| 172.22.36.203 || [[Mate_(Server)/DB|DB]] || DB
|------
| 172.22.36.204 || [[Mate_(Server)/freeswitch.vm.rzl|Mate_(Server)/freeswitch.vm.rzl]] || Freeswitch
|------
| 172.22.36.205 || [[Mate_(Server)/yate.vm.rzl]] || VM für Telefonanlage
|------
| 172.22.36.206 || [[Mate_(Server)/icinga.vm.rzl]] || Icinga Monitoring
|-----
| 172.22.36.207 || [[Mate_(Server)/ranlvor.vm.rzl]] || Mitglieder-VM (ranlvor)
|-----
| 172.22.36.208 || [[Mate_(Server)/kunterbunt.vm.rzl]] || Mitglieder-VM
|-----
| 172.22.36.209 || [[Mate (Server)/0xb4dc0d3d.vm.rzl]] || Mitglieder-VM
|-----
| 172.22.36.210 || ''reserviert für VMs'' || Ungenutzt
|-----
| 172.22.36.211 || ''reserviert für VMs'' || Ungenutzt
|-----
| 172.22.36.212 || ''reserviert für VMs'' || Ungenutzt
|-----
| 172.22.36.213 || ''reserviert für VMs'' || Ungenutzt
|-----
| 172.22.36.214 || ''reserviert für VMs'' || Ungenutzt
|-----
| 172.22.36.215 || ''reserviert für VMs'' || Ungenutzt
|-----
| 172.22.36.216 || ''reserviert für VMs'' || Ungenutzt
|-----
| 172.22.36.217 || [[Mate_(Server)/s1lvester.vm.rzl]] || Mitglieder-VM (s1lvester)
|-----
| 172.22.36.218 || [[Mate_(Server)/rami.vm.rzl]] || Mitglieder-VM (rami)
|-----
| 172.22.36.219 || [[Mate_(Server)/evilsadnes.vm.rzl]] || Mitglieder-VM (evilsadnes)
|-----
| 172.22.36.220 || [[Mate_(Server)/abrock.vm.rzl|abrock.vm.rzl]] || Mitglieder-VM (beta)
|-----
| 172.22.36.221 || [[Mate_(Server)/tiefpunkt.vm.rzl|tiefpunkt.vm.rzl]] || Mitglieder-VM (beta)
|-----
| 172.22.36.222 || [[Drucker#Labeldrucker]] || VM für die Labeldrucker-Software
|-----
| 172.22.36.223 || [[Mate_(Server)/yate.vm.rzl]] || VM für Telefonanlage
|-----
| 172.22.36.224 || [[Mate_(Server)/blabber.vm.rzl]] || Mitglieder-VM (beta)
|-----
| 172.22.36.225 || [[Mate_(Server)/slowpoke.vm.rzl]] || Mitglieder-VM (beta)
|-----
| 172.22.36.235 || [[Mate_(Server)/qrgo.vm.rzl]] || [[qrgo]] Mitglieder-VM für qrgo-Projekt von cheatha (beta)
|-----
| 172.22.36.236 || [[Mate_(Server)/bernd.vm.rzl]] || Mitglieder-VM
|-----
| 172.22.36.237 || [[Mate_(Server)/jailbackup.vm.rzl]] || Jailbackup-VM
|-----
| 172.22.36.238 || [[Mate_(Server)/unifi.vm.rzl]] || Ubiquiti Unifi Management VM
|-----
| 172.22.36.239 || [[Mate_(Server)/muzy.vm.rzl]] ||Mitglieder-VM muzy
|-----
| 172.22.36.240 || ''reserved'' || Reserviert für Geräte
|-----
| 172.22.36.241 || ''reserved'' || Reserviert für Geräte
|-----
| 172.22.36.242 || fon_pv || fonera nicoduck
|-----
| 172.22.36.243 || cis-phone-01 || Cisco VoIP Phone 01
|-----
| 172.22.36.244 || [[Mate_(Server)/lutoma.vm.rzl]] || Mitglieder-VM (beta)
|-----
| 172.22.36.245 || cis-phone-02 || Cisco VoIP Phone 02
|-----
| 172.22.36.246 || cis-phone-03 || Cisco VoIP Phone 03
|-----
| 172.22.36.247 || cis-phone-04 || Cisco VoIP Phone 04
|-----
| 172.22.36.248 || cis-phone-05 || Cisco VoIP Phone 05
|-----
| 172.22.36.249 || [[pokeduino]] || pokeduino.rzl
|-----
| 172.22.36.250 || [[Mate (Server)]] || Mate (Server)
|-----
| 172.22.36.251 || [[Mate (Server)/Monitoring]] || Mate/Monitoring
|-----
| 172.22.36.252 || [[Mate (Server)]] || Mate [http://h17007.www1.hp.com/us/en/enterprise/servers/management/ilo/index.aspx#.UoEbpXXWGCg ILO Port]
|-----
| 172.22.36.253 || SSH-Türöffner || Bei Fragen: Docsteel oder NOC-Team
|-----
| 172.22.36.254 || ''reserved'' || Reserviert für Geräte
|-----
| 172.22.37.'''10 - 110''' || '''dhcp''' || DHCP-Range (unfiltered)
|}

=== 10.23.42.0/24 ===

Management-Netzwerk für Switches und Access Points.

{| class="wikitable" width="100%"
|-----
! IP-Adresse || Hostname || Beschreibung
|-----
| 10.23.42.1 || [[firebox]] || Router
|-----
| 10.23.42.2 || [[Cisco SG 500]] || Switch-Stack im Hauptraum
|-----
| 10.23.42.3 || [[EdgeSwitch PoE 24]] || Switch im Nebenraum
|-----
| 10.23.42.4 || Netgear ProSAFE || Switch auf dem Hauptraumtisch, Mitte
|-----
| 10.23.42.5 || Netgear ProSAFE || Switch auf dem Hauptraumtisch, bei Rednerpult
|}

== VLANs ==
{| class="wikitable" width="100%"
|-----
! VLAN-ID || Beschreibung
|-----
| 42 || IOT
|-----
| 666 || Uplink
|-----
| 2342 || [[Netzwerk#10.23.42.0.2F24|Management-Netz]]
|}

== Vorgehensweisen ==
=== Host hinzufügen/entfernen ===
* Eintrag Tabelle oben drüber; Gibts eine Wikiseite?
* (r)DNS-Zonen gibts auf [[Mate_(Server)|Mate]] unter /var/lib/bind/
* statisches DHCP gibts auf der [[firebox]]

Plenum

2020-01-05T13:24:45Z

Lordeis: /* Neuanschaffungen/Ausgaben */

{{EventInfoBox
|name = Plenum
|status = stable
|image =
|description = Neuigkeiten und Diskussionen
|author =
|username =
|rhythm = monatlich
|day = Erster Sonntag im Monat nach dem [[Wipe & Defrag]]
|time =
|preis =
}}

= Themen für das nächste Plenum =

== Realitätsabgleich ==
===== Was mir aufgefallen ist, was herrenlos rumsteht =====

===== Was ich seit dem letzten Plenum im Space gemacht hab =====

===== Was ich bis zum nächsten Plenum im Space vorhabe =====

===== Was mich im Space geärgert hat =====
* es stinkt nach dem Kochen/Essen bestialisch, keiner lüftet gerne und man muss seine Klamotten im Anschluss waschen. --[[Benutzer:Helix|Helix]] ([[Benutzer Diskussion:Helix|Diskussion]]) 22:47, 1. Jan. 2020 (CET)

===== Was mich im Space erfreut hat =====

===== Was ich gerne lernen würde =====

(Allgemeiner Hinweis auf [[Vorträge#Gewünscht]])

===== Was im Space getan werden müsste (+Tickets anlegen) =====

===== Beschlüsse aus dem letzten Plenum =====
* Meta-Plenum: Doodle zur optimalen Plenum-Terminfindung
* Congress: Was haben wir gemacht?
* Stühle
* Heizlüfter
* Kartendrucker: Druckkopf

== Neuanschaffungen/Ausgaben ==
* Unifi UAP-AC-HD
** weil der AP im Nebenraum lahm ist. → Nebenraum durch Hauptraum-AP ersetzen, Hauptraum-AP durch HD ersetzen --[[Benutzer:Helix|Helix]] ([[Benutzer Diskussion:Helix|Diskussion]]) 23:04, 31. Dez. 2019 (CET)
* Patchpanel für die Lan Verkabelung der Werkstatt
** Zum beispiel dieses: [https://www.amazon.de/deleyCON-Patchpanel-Verteilerfeld-Port-Servermontage/dp/B01N5OB4B2/ref%3Dsr_1_4?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=3VYNP23DYV9L9&keywords=patchpanel%2Bcat%2B6%2B24%2Bport&qid=1577560089&sprefix=patchpanel%2Bcat%2B6%2B%2Caps%2C161&sr=8-4 deleyCON CAT 6 Patchpanel] [[Benutzer:Lordeis|Lordeis]] ([[Benutzer Diskussion:Lordeis|Diskussion]]) 14:24, 5. Jan. 2020 (CET)
* Neuer Switch für den Verteiler im FabLab
** Da momentan nur ein 100 Mbit Poe Switch als Ersatz eingebaut ist und der ursprüngliche Ubiquity seit ein paar Monaten erfolglos auf eine Reparatur wartet würde ich vorschlagen einen neuen Switch zu besorgen. Aus eigener Erfahrung und auf Grund des guten Preis Leistung Verhältnis würde ich diesen Switch vorschlagen: [https://www.omg.de/mikrotik/routerboard/mikrotik-routerboard-crs328-24p-4s-rm/a-14454/ MikroTik Cloud Router Switch - CRS328-24P-4S+RM] [[Benutzer:Lordeis|Lordeis]] ([[Benutzer Diskussion:Lordeis|Diskussion]]) 14:24, 5. Jan. 2020 (CET)
* Neue Hardware für den RZL Server.
** Das NOC Team hat sich den bestehenden Server angeschaut. Leider ist die bestehende Hardware zu alt das es sich noch lohnen würde diesen zu upgraden. Hier haben wir einige Möglichkeiten für neue Hardware vorbereitet diese würden wir gerne auf dem Plenum vorstellen und dann gemeinsam entscheiden welches die beste Option ist. [[Benutzer:Lordeis|Lordeis]] ([[Benutzer Diskussion:Lordeis|Diskussion]]) 14:24, 5. Jan. 2020 (CET)

== Sonstiges ==
* Ich würde gerne alles von [https://github.com/raumzeitlabor/ Github.com] und [https://gitlab.com/raumzeitlabor Gitlab.com] was RZL betrifft auf unser [https://git.raumzeitlabor.org/ self-hosted gitlab] umziehen. --[[Benutzer:Helix|Helix]] ([[Benutzer Diskussion:Helix|Diskussion]]) 22:47, 1. Jan. 2020 (CET)

[[Kategorie:Plenum]]
[[Kategorie:Protokoll]]

Mate (Server)

2019-12-29T18:16:52Z

Lordeis: /* reboot */

{{ProjektInfoBox
|name = Mate (Server)
|status = beta
|image = RaumZeitLabor - Logo - Schwarz.svg
|description =
|category = Infrastruktur
|subcategory = Netz
|author = [[NOC Team|NOC-Team]]
|username =
|version =
|update =
|platform =
|hostname = mate.rzl
|license =
|download =
}}

'''Mate''' ist ein Server, der als Ersatz der [[Blackbox]] und [[Datengrab]] dient. Er wird über unsere [[USV]] geschützt.

==Technische Daten ==
{| class="wikitable va-top"
|Produkt
|[http://www8.hp.com/de/de/products/proliant-servers/product-detail.html?oid=5379860#!tab=features HP Proliant MicroServer Gen8]
|-
|CPU
|[http://ark.intel.com/De/products/65732/Intel-Xeon-Processor-E3-1230-v2-8M-Cache-3_30-GHz Xeon E3 1230v2] 4x 3.3GHz + Hyperthreading
|-
|RAM
|1x 8GB Kingston DDR3 ECC sowie 1x 4GB Original HP DDR3 ECC
|-
|HDDs
|3x3TB (WD30EFRX) RAID5 über alle Platten, 6TB nutzbar, LVM, Platten werden über smartd gemonitort und an netzwerk (ät) rzl dot de im Fehlerfalle geschickt 1x 64GB SSD
|-
|USB
|1x Onboard, 2x USB 2.0 hinten, 2x USB 3.0 hinten, 2x USB 2.0 vorne
|-
|Verbrauch
|60W Volllast / 31W idle (Messung mit einem schlechten Messgerät, jeweils ohne Platten) jede Platte: 4.1W aktiv, 3W idle (laut Datenblatt) Insgesamt Idle: 40W Insgesamt Volllast: 72.3W
|-
|Virtualisierung
|libvirt/KVM
|}

== Unterseiten ==
Auf allen Kern-VMs läuft _möglichst_ nur pakettierte Software (Debian). Möchtest Du etwas auf den Systemen installiert haben, dann paketiere es bitte. Auf den Mitglieder-VMs kann alles so installiert werden, wie gewünscht.

== Reboot Fest / Zabbix Agent ==
(stand 12-2019)

Rebootfest gibt an, ob die Dienste innerhalb der VM nach einem Reboot der VM von alleine sauber hoch kommen. Rebootfest sagt nicht zwingend, dass die VM einen Reboot von Mate sauber übersteht.

{| class="wikitable" valign="top"
! VM
! Rebootfest
! Anmerkungen
! Monitoring Agent
! Monitoring Anmerkung
|-
| [[Mate (Server)/0xb4dc0d3d.vm.rzl]]
| unbekannt
|
| Ja
|
|-
| [[Mate (Server)/abrock.vm.rzl]]
| unbekannt
| verliert beim Host-Reboot vermutlich das USB-Device zum Stromzähler
| Ja
|
|-
| [[Mate (Server)/cashdesk.rzl]]
| ja
|
| Nein
|
|-
| [[Mate (Server)/datengrab.rzl]]
| nein
|
| Nein
|
|-
| [[Mate (Server)/db.rzl]]
| ja
|
| Nein
|
|-
| [[Mate (Server)/freeswitch.vm.rzl]]
| ja
|
| Nein
|
|-
| [[Mate (Server)/infra.rzl]]
| ja
| verliert beim Host-Reboot vermutlich das USB-Device zu den [[Funksteckdosen]]
| Nein
|
|-
| [[Mate (Server)/kunterbunt.vm.rzl]]
| nein
| MQTT -> Graphite-Bridge muss manuell gestartet werden
| Ja
|
|-
| [[Mate (Server)/lutoma.vm.rzl]]
| unbekannt
|
| Nein
|
|-
| [[Mate (Server)/partkeepr.rzl]]
| ja
|
| Nein
|
|-
| [[Mate (Server)/qrgo.vm.rzl]]
| unbekannt
|
| Nein
|
|-
| [[Mate (Server)/rami.vm.rzl]]
| unbekannt
|
| Nein
|
|-
| [[Mate (Server)/ranlvor.vm.rzl]]
| ja
|
| Nein
|
|-
| [[Mate (Server)/s1lvester.vm.rzl]]
| unbekannt
|
| Ja
|
|-
| [[Mate (Server)/unifi.vm.rzl]]
| ja
| Braucht zum Start große Mengen Zufall. Geduld oder ping -f 172.22.36.238 hilft.
| Nein
|
|}
[[Benutzer:Lordeis|Lordeis]] ([[Benutzer Diskussion:Lordeis|Diskussion]]) 19:16, 29. Dez. 2019 (CET)

== VMs ==
{| class="wikitable" valign="top"
! VM
! Arbeitsspeicher
! Plattenplatz
|-
| [[Mate (Server)/0xb4dc0d3d.vm.rzl]]
| 768 MB
| 20 GB
|-
| [[Mate (Server)/abrock.vm.rzl]]
| 512 MB
| 30 GB
|-
| [[Mate (Server)/cashdesk.rzl]]
| 512 MB
| 20 GB
|-
| [[Mate (Server)/datengrab.rzl]]
| 512 MB
| 2720 GB
|-
| [[Mate (Server)/db.rzl]]
| 512 MB
| 30 GB
|-
| [[Mate (Server)/freeswitch.vm.rzl]]
| 368 MB
| 20 GB
|-
| [[Mate (Server)/infra.rzl]]
| 3072 MB
| 40 GB
|-
| [[Mate (Server)/kunterbunt.vm.rzl]]
| 768 MB
| 20 GB
|-
| [[Mate (Server)/lutoma.vm.rzl]]
| 256 MB
| 20 GB
|-
| [[Mate (Server)/partkeepr.rzl]]
| 512 MB
| 30 GB
|-
| [[Mate (Server)/qrgo.vm.rzl]]
| 256 MB
| 10 GB
|-
| [[Mate (Server)/rami.vm.rzl]]
| 256 MB
| 20 GB
|-
| [[Mate (Server)/s1lvester.vm.rzl]]
| 256 MB
| 20 GB
|-
| [[Mate (Server)/unifi.vm.rzl]]
| 750 MB
| 20 GB
|-
| '''Gesamt'''
| '''9310 MB / 12001 MB (77.58% belegt)'''
| '''2.9 TB / 5.3 TB (55.93% belegt)'''
|}

Automatisch geupdatet von [[Benutzer:Matebot]] am: 2019-12-18 00:00:02

== Unterseiten ==
<splist />

[[Kategorie:Hardware]]

NOC Team/To-Dos

2019-12-29T17:10:17Z

Lordeis: /* Serverhardware */

== Tagebuch ==

Wichtiger Punkt: Dokumentation was bisher getan wurde. Was ergab sich aus der Freifunk-Diskussion heute, was aus Verm.+Pfalzkom+Politik, was machen wir mit dem Cisco-Stack hinsichtlich des Tschisko-Fuckups mit Self-Signed Certificates (ist zwar scheisse, macht aber jeder(tm), auch wir?) '''''vor''''' Januar 2020? Was habe ich vergessen?

Cisco siehe auch [https://www.cisco.com/c/en/us/support/docs/field-notices/704/fn70489.html FN 70489].

• [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 21:35, 27. Dez. 2019 (CET)

Und noch ein wichtiger Punkt: Entscheid Serverhardware, Anbringung des Kostenpunkts im Plenum Anfang Januar.

== Netzwerk ==

=== DNS rzl.so ===
Alle internen Dienste enden auf .rzl, was keine Domain ist, die uns gehört. Wäre cool, wenn das stattdessen .rzl.so wäre.

→ Split-DNS?

--[[Benutzer:Helix|Helix]] 14:35, 27. Dez. 2019 (CET)

=== SSL-Zertifikate ===
Für nur intern verfügbare Dienste wäre auch ein SSL-Zertifikat sinnvoll.

Letsencrypt *.rzl.so würde die internen Dienste dann nicht nach [https://crt.sh crt.sh] | [https://www.entrust.com/ct-search/?domain=raumzeitlabor.de&includeExpired=true&exactMatch=false entrust.com/ct-search] leaken, daher würde ich das vorschlagen.

Für extern verfügbare Dienste kann man dann ja je FQDN ein normales Cert holen. Eventuell auf [https://letsencrypt.org/docs/rate-limits/ Rate Limits] aufpassen.

--[[Benutzer:Helix|Helix]] 14:35, 27. Dez. 2019 (CET)

Aufbauend darauf (Obacht: Rate Limits are a real thing): Automatisierung der Zertifikate. LE-Zerts halten nur 3 Monate, da ist Rumgammeln keine Option mehr. Und die Faustregel heißt: ist es rein interner Kram? Wirklich? Wenn nein --> Non-Wildcard und SAN. Wildcard-Zerts sind obsolete Tech, machen wir nur zur Obfuscation. Doku essentiell, SAN-Zusammenfassung und -Stepping!

Zur Disk. im NOC-Meeting. Bei weiteren Diskussionspunkten diese Zeile löschen und bitte die Diskussionsseite dieses Artikels nutzen. • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 20:38, 27. Dez. 2019 (CET)

=== Inventur Internetleitung ===

Welche Leitungen haben wir, welche Möglichkeiten zum Upgrade gibt es?

Aktuelle Leitung:
: Telekom Hybrid 50Mbit
: 16 Mbit DSL
: Rest geht über im Router verbaute Sim Karte (Nur mit Telekom Router Kompatibel)

Geimeinsame Klärung mit der Spedition erstrebenswert.

=== Holzwerkstatt ===

Wurde geklärt es muss definitiv ein Patchpanel für die neue Werkstatt angeschafft werden, z.B.: [https://www.amazon.de/deleyCON-Patchpanel-Verteilerfeld-Port-Servermontage/dp/B01N5OB4B2/ref%3Dsr_1_4?__mk_de_DE=ÅMÅŽÕÑ&crid=3VYNP23DYV9L9&keywords=patchpanel%2Bcat%2B6%2B24%2Bport&qid=1577560089&sprefix=patchpanel%2Bcat%2B6%2B%2Caps%2C161&sr=8-4 Amazon-Link, deleyCON Patchpanel]

Außerdem noch ein Switch da der momentane Ersatz ein relikt aus den 90ern ist. Beispiel: [https://www.omg.de/mikrotik/routerboard/mikrotik-routerboard-crs328-24p-4s-rm/a-14454/ Mikrotik Routerboard CRS328 (24-Port) auf omg]. Oder jemand repariert den Ubiquity der seit Monaten in der Werkstatt liegt.

(alles unsigniert von [[Benutzer:Lordeis|Lordeis]])

=== Freifunk + IPv6 ===

Zukunft ab 01.01.2020? Kübler Glasfaser? 
Fürs erste wenn möglich über das /56 Netz, das am Telekom Router anliegt. - [[Benutzer:Lordeis|Lordeis]] 
Update vom 27.12.19: 
Laut [[Benutzer:cheatha|@cheatha]] wird gerade die Freifunk Infrastruktur umgezogen was uns ein wenig zeit ins neue jahr gewähren sollte. 
[[Benutzer:Lordeis|Lordeis]] ([[Benutzer Diskussion:Lordeis|Diskussion]]) 18:00, 29. Dez. 2019 (CET)

=== Switches ===
Inventur aller Switche und Firmware Stand prüfen

==== Cisco Stack E Werkstatt ====
Update von Cisco verfügbar: '''1.4.11.02''' 
Diskussion ob Update durchgeführt werden soll - [[Benutzer:Lordeis|Lordeis]] 
'''Wichtig:''' 
'''Prüfen ob die Switche von dem Cisco Zertifikats Fuckup betroffen sind.'''

=== Benutzer-DB ===

TLS-Renewal. Details nach Fertigstellung.

=== Router ===
==== Ubiquity ====
# Auseinandersortieren der Netzwerkverbindungen.
# Reverse Engineering und Dokumentieren der Konfiguration.
# IPv6 Konfiguration.

==== Speedport (Telekom) ====
# Reverse Engineering und Dokumentieren der Konfiguration.
# IPv6 Konfiguration.

Kommentar Ranlvor: Sollte ziemlich Standard sein, nur eventuell ein paar Regeln drin, die versuchen sollen Telefonie-Traffic auf DSL zu zwingen (weil das weniger schlecht tut als via LTE).

=== WIFI Access Points ===
==== Ubiquity ====
# Reverse Engineering und Dokumentieren der Konfiguration.
# Auseinadersortieren der SSIDs:
## Prüfen ob alle SSIDs nötig sind.
## Diskutieren ob Band Steering Sinvoll Wäre.
## Prüfen ob Layer 3 Roaming Sinnig ist.
# Prüfung ob ein zusätzlicher Unify AP für die Werkstatt sinn macht.
# Auslagern des RZL IOT WLAN auf anderen AP.

==== IOT Accesspoint ====
# Extra AP verwenden da Performance Probleme.
# Ich habe noch einen Lancom Rumliegen den ich Spenden würde - [[Benutzer:Lordeis|Lordeis]]

=== Verkabelung ===

# Die zwei Tische an der E/Ä-Ecke sind vorbildlich verkabelt, wenn man sie als autonome Hackrepublik innerhalb des RZL betrachtet. --> Uplink-Kabel setzen.
## Update: Hab' mal Kabel geordert, Kanäle haben wir noch da. Könnte auch beim Umbau 2020 hilfreich sein. • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 18:34, 28. Dez. 2019 (CET)

== Hypervisor ==

=== RAM ===

Welche Möglichkeiten zum Update gibt es? Kurzfristiger Punkt, da der RAM erschöpft ist. AUf jeden Fall mögliches Upgrade wären zusätzliche 4 GiB für 30-40 Euronen, wenn wir in den Server reingeschaut haben wissen wir aber ob noch mehr als die dann 16GiB gehen.

Aktuelles To-Do: Dokumentation Hardwaremöglichkeiten - [[Benutzer:0xb4dc0d3d|0xb4dc0d3d]]

Update: Macht das noch Sinn? Siehe Punkt Server-Hardware weiter unten in diesem Kapitel. • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 22:10, 27. Dez. 2019 (CET)

=== Rechtekonzept ===

User sollten ihre VMs durchstarten können. Geht Hand in Hand mit dem Gedanken, nicht mehr überall als root zu springen und alles als root zu tun, stattdessen Nutzung sudo und mittelfristig ggf. Anbindung an [[UserDB|UserDB]].

Person mit Hut: [[Benutzer:0xb4dc0d3d|0xb4dc0d3d]]

=== Hypervisor-Software ===

# HV bleibt KVM. Helix erwähnte heute Cockpit, das scheint also auch ohne das ganze oVirt-Debakel zu gehen, und wäre dann prima. Geht als Frontend dann mit dem Rechtekonzept Hand in Hand. Alternative: Proxmox als Aufsatz, nicht(!!!) als Basis.

# OS sollte CentOS sein: der Hypervisor hat dumm zu sein (CA-Verwaltung, Automatisierung etc. darf da nicht laufen), also genügt CentOS, und wir gewinnen den Benefit SELinux. (Alternative wäre Arch, aber Rolling Release in bedingt gewarteter aber produktiver Umgebung? Meh. Willstenich.)

Gesamtes Kapitel zur Diskussion, habe ich ad hoc so niedergeschrieben • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 21:13, 27. Dez. 2019 (CET)

=== VM-Inventur ===

Prüfen, was noch aktiv ist, und nach einer geordneten(!) Inventarisierung Mitglieder bei Bedarf anschreiben. Im Zweifelsfall Downtime und einen Zeitraum X auf Reaktion warten.

=== VM-Struktur ===

Ordnung schaffen: Sind Dinge(tm) produktiv, sollten diese auf dedizierte VMs, gutes Beispiel hier: [[cashdesk.rzl]] (leider auch gutes Beispiel für undoumentierte VM).

Kommentar Ranlvor: cashdesk ist ein schlechtes Beispiel, da das eigentlich mal eine MemberVM war und neben cashdesk auch den Infoscreen hosted.

=== Serverhardware ===

Zukunft: Redundanz? Idee: KVM over 2 Nodes mit GlusterFS.

# Ob wir 2 Nodes brauchen oder 1 reicht, sollten wir in NOC-Meeting und Plenum diskutieren.
# Basis: Nunja, 32 oder 64GiB RAM, mind. 64 GiB Platte und schauen wo die 3-4 TiB VM-Store hinkommen. Alos Basisrahmen, zur Diksussion und Anpassung hier. • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 18:31, 27. Dez. 2019 (CET)

Erneuerung unumgänglich, RAM-Erweiterung ist nur Lebenserhaltungsmaßnahme bei einer designierten Leiche.

Optionen:
# Eigenkonfiguration auf Basis eines Supermicro Boards und einer AMD Epyc CPU. Koniguration hier: [https://git.raumzeitlabor.org/NOC/server-hardware/ Hardware Konfiguration] [[Benutzer:Lordeis|Lordeis]] ([[Benutzer Diskussion:Lordeis|Diskussion]]) 18:10, 29. Dez. 2019 (CET)
# [https://www.thomas-krenn.com/de/produkte/einsatzzweck/software-defined-storage/storage-spaces-direct/s2d-micro-cluster/s2d-micro-cluster-advanced.html Thomas-Krenn-Storage-Cluster]: 240GB SSD OS, 3TB Nested Mirror, SuperMicro, 32GiB DDR4 ECC, max. 185W/Server, 13.100 Euro für zwei Server
# [[Benutzer:Kite|Kite]] kann eventuell einen PowerEdge R510 startklarmachen. Er gibt noch bescheid, Basis-Specsheet [https://www.dell.com/downloads/global/products/pedge/R510_Spec_Sheet.pdf hier].

Übersicht --> [[NOC Team/To-Dos/Serverhardware Q1 2020]]

== Services ==

=== Mailserver ===

==== Spamfilter ====

Überarbeitung und Erweiterung. Wir bekommen keine Viagramails, aber einiges an Werbung. ''Erst'' Spamfilter, ''dann'' Unterpunkt Blocklisten ;-)

==== Mailman ====
lists.raumzeitlabor.de benutzt Mailman v2.1.18 vom 6.5.2014.

Eine [https://docs.mailman3.org/en/latest/migration.html Migration von 2.1 auf 3.x] ist möglich.

--[[Benutzer:Helix|Helix]] ([[Benutzer Diskussion:Helix|Diskussion]]) 14:07, 28. Dez. 2019 (CET)

=== Gitlab ===

# Root-Passwort unbekannt, Version zu alt und damit insecure.
# AutoDevops und CI-Runner sind aktiviert ohne Instanz, nerven also bei jedem neuen Projekt wieder. Das anzuschalten ohne es zu konfigurieren ist nicht gerade clever. Sollte man beseitigen oder nachfragen warum das überhaupt angedacht wurde.

NOC Team/To-Dos

2019-12-29T17:00:57Z

Lordeis: /* Freifunk + IPv6 */

== Tagebuch ==

Wichtiger Punkt: Dokumentation was bisher getan wurde. Was ergab sich aus der Freifunk-Diskussion heute, was aus Verm.+Pfalzkom+Politik, was machen wir mit dem Cisco-Stack hinsichtlich des Tschisko-Fuckups mit Self-Signed Certificates (ist zwar scheisse, macht aber jeder(tm), auch wir?) '''''vor''''' Januar 2020? Was habe ich vergessen?

Cisco siehe auch [https://www.cisco.com/c/en/us/support/docs/field-notices/704/fn70489.html FN 70489].

• [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 21:35, 27. Dez. 2019 (CET)

Und noch ein wichtiger Punkt: Entscheid Serverhardware, Anbringung des Kostenpunkts im Plenum Anfang Januar.

== Netzwerk ==

=== DNS rzl.so ===
Alle internen Dienste enden auf .rzl, was keine Domain ist, die uns gehört. Wäre cool, wenn das stattdessen .rzl.so wäre.

→ Split-DNS?

--[[Benutzer:Helix|Helix]] 14:35, 27. Dez. 2019 (CET)

=== SSL-Zertifikate ===
Für nur intern verfügbare Dienste wäre auch ein SSL-Zertifikat sinnvoll.

Letsencrypt *.rzl.so würde die internen Dienste dann nicht nach [https://crt.sh crt.sh] | [https://www.entrust.com/ct-search/?domain=raumzeitlabor.de&includeExpired=true&exactMatch=false entrust.com/ct-search] leaken, daher würde ich das vorschlagen.

Für extern verfügbare Dienste kann man dann ja je FQDN ein normales Cert holen. Eventuell auf [https://letsencrypt.org/docs/rate-limits/ Rate Limits] aufpassen.

--[[Benutzer:Helix|Helix]] 14:35, 27. Dez. 2019 (CET)

Aufbauend darauf (Obacht: Rate Limits are a real thing): Automatisierung der Zertifikate. LE-Zerts halten nur 3 Monate, da ist Rumgammeln keine Option mehr. Und die Faustregel heißt: ist es rein interner Kram? Wirklich? Wenn nein --> Non-Wildcard und SAN. Wildcard-Zerts sind obsolete Tech, machen wir nur zur Obfuscation. Doku essentiell, SAN-Zusammenfassung und -Stepping!

Zur Disk. im NOC-Meeting. Bei weiteren Diskussionspunkten diese Zeile löschen und bitte die Diskussionsseite dieses Artikels nutzen. • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 20:38, 27. Dez. 2019 (CET)

=== Inventur Internetleitung ===

Welche Leitungen haben wir, welche Möglichkeiten zum Upgrade gibt es?

Aktuelle Leitung:
: Telekom Hybrid 50Mbit
: 16 Mbit DSL
: Rest geht über im Router verbaute Sim Karte (Nur mit Telekom Router Kompatibel)

Geimeinsame Klärung mit der Spedition erstrebenswert.

=== Holzwerkstatt ===

Wurde geklärt es muss definitiv ein Patchpanel für die neue Werkstatt angeschafft werden, z.B.: [https://www.amazon.de/deleyCON-Patchpanel-Verteilerfeld-Port-Servermontage/dp/B01N5OB4B2/ref%3Dsr_1_4?__mk_de_DE=ÅMÅŽÕÑ&crid=3VYNP23DYV9L9&keywords=patchpanel%2Bcat%2B6%2B24%2Bport&qid=1577560089&sprefix=patchpanel%2Bcat%2B6%2B%2Caps%2C161&sr=8-4 Amazon-Link, deleyCON Patchpanel]

Außerdem noch ein Switch da der momentane Ersatz ein relikt aus den 90ern ist. Beispiel: [https://www.omg.de/mikrotik/routerboard/mikrotik-routerboard-crs328-24p-4s-rm/a-14454/ Mikrotik Routerboard CRS328 (24-Port) auf omg]. Oder jemand repariert den Ubiquity der seit Monaten in der Werkstatt liegt.

(alles unsigniert von [[Benutzer:Lordeis|Lordeis]])

=== Freifunk + IPv6 ===

Zukunft ab 01.01.2020? Kübler Glasfaser? 
Fürs erste wenn möglich über das /56 Netz, das am Telekom Router anliegt. - [[Benutzer:Lordeis|Lordeis]] 
Update vom 27.12.19: 
Laut [[Benutzer:cheatha|@cheatha]] wird gerade die Freifunk Infrastruktur umgezogen was uns ein wenig zeit ins neue jahr gewähren sollte. 
[[Benutzer:Lordeis|Lordeis]] ([[Benutzer Diskussion:Lordeis|Diskussion]]) 18:00, 29. Dez. 2019 (CET)

=== Switches ===
Inventur aller Switche und Firmware Stand prüfen

==== Cisco Stack E Werkstatt ====
Update von Cisco verfügbar: '''1.4.11.02''' 
Diskussion ob Update durchgeführt werden soll - [[Benutzer:Lordeis|Lordeis]] 
'''Wichtig:''' 
'''Prüfen ob die Switche von dem Cisco Zertifikats Fuckup betroffen sind.'''

=== Benutzer-DB ===

TLS-Renewal. Details nach Fertigstellung.

=== Router ===
==== Ubiquity ====
# Auseinandersortieren der Netzwerkverbindungen.
# Reverse Engineering und Dokumentieren der Konfiguration.
# IPv6 Konfiguration.

==== Speedport (Telekom) ====
# Reverse Engineering und Dokumentieren der Konfiguration.
# IPv6 Konfiguration.

Kommentar Ranlvor: Sollte ziemlich Standard sein, nur eventuell ein paar Regeln drin, die versuchen sollen Telefonie-Traffic auf DSL zu zwingen (weil das weniger schlecht tut als via LTE).

=== WIFI Access Points ===
==== Ubiquity ====
# Reverse Engineering und Dokumentieren der Konfiguration.
# Auseinadersortieren der SSIDs:
## Prüfen ob alle SSIDs nötig sind.
## Diskutieren ob Band Steering Sinvoll Wäre.
## Prüfen ob Layer 3 Roaming Sinnig ist.
# Prüfung ob ein zusätzlicher Unify AP für die Werkstatt sinn macht.
# Auslagern des RZL IOT WLAN auf anderen AP.

==== IOT Accesspoint ====
# Extra AP verwenden da Performance Probleme.
# Ich habe noch einen Lancom Rumliegen den ich Spenden würde - [[Benutzer:Lordeis|Lordeis]]

=== Verkabelung ===

# Die zwei Tische an der E/Ä-Ecke sind vorbildlich verkabelt, wenn man sie als autonome Hackrepublik innerhalb des RZL betrachtet. --> Uplink-Kabel setzen.
## Update: Hab' mal Kabel geordert, Kanäle haben wir noch da. Könnte auch beim Umbau 2020 hilfreich sein. • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 18:34, 28. Dez. 2019 (CET)

== Hypervisor ==

=== RAM ===

Welche Möglichkeiten zum Update gibt es? Kurzfristiger Punkt, da der RAM erschöpft ist. AUf jeden Fall mögliches Upgrade wären zusätzliche 4 GiB für 30-40 Euronen, wenn wir in den Server reingeschaut haben wissen wir aber ob noch mehr als die dann 16GiB gehen.

Aktuelles To-Do: Dokumentation Hardwaremöglichkeiten - [[Benutzer:0xb4dc0d3d|0xb4dc0d3d]]

Update: Macht das noch Sinn? Siehe Punkt Server-Hardware weiter unten in diesem Kapitel. • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 22:10, 27. Dez. 2019 (CET)

=== Rechtekonzept ===

User sollten ihre VMs durchstarten können. Geht Hand in Hand mit dem Gedanken, nicht mehr überall als root zu springen und alles als root zu tun, stattdessen Nutzung sudo und mittelfristig ggf. Anbindung an [[UserDB|UserDB]].

Person mit Hut: [[Benutzer:0xb4dc0d3d|0xb4dc0d3d]]

=== Hypervisor-Software ===

# HV bleibt KVM. Helix erwähnte heute Cockpit, das scheint also auch ohne das ganze oVirt-Debakel zu gehen, und wäre dann prima. Geht als Frontend dann mit dem Rechtekonzept Hand in Hand. Alternative: Proxmox als Aufsatz, nicht(!!!) als Basis.

# OS sollte CentOS sein: der Hypervisor hat dumm zu sein (CA-Verwaltung, Automatisierung etc. darf da nicht laufen), also genügt CentOS, und wir gewinnen den Benefit SELinux. (Alternative wäre Arch, aber Rolling Release in bedingt gewarteter aber produktiver Umgebung? Meh. Willstenich.)

Gesamtes Kapitel zur Diskussion, habe ich ad hoc so niedergeschrieben • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 21:13, 27. Dez. 2019 (CET)

=== VM-Inventur ===

Prüfen, was noch aktiv ist, und nach einer geordneten(!) Inventarisierung Mitglieder bei Bedarf anschreiben. Im Zweifelsfall Downtime und einen Zeitraum X auf Reaktion warten.

=== VM-Struktur ===

Ordnung schaffen: Sind Dinge(tm) produktiv, sollten diese auf dedizierte VMs, gutes Beispiel hier: [[cashdesk.rzl]] (leider auch gutes Beispiel für undoumentierte VM).

Kommentar Ranlvor: cashdesk ist ein schlechtes Beispiel, da das eigentlich mal eine MemberVM war und neben cashdesk auch den Infoscreen hosted.

=== Serverhardware ===

Zukunft: Redundanz? Idee: KVM over 2 Nodes mit GlusterFS.

# Ob wir 2 Nodes brauchen oder 1 reicht, sollten wir in NOC-Meeting und Plenum diskutieren.
# Basis: Nunja, 32 oder 64GiB RAM, mind. 64 GiB Platte und schauen wo die 3-4 TiB VM-Store hinkommen. Alos Basisrahmen, zur Diksussion und Anpassung hier. • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 18:31, 27. Dez. 2019 (CET)

Erneuerung unumgänglich, RAM-Erweiterung ist nur Lebenserhaltungsmaßnahme bei einer designierten Leiche.

Optionen:
# SuperMicro-Server laut [[Benutzer:Lordeis|Lordeis]] (bitte ergänzen)
# [https://www.thomas-krenn.com/de/produkte/einsatzzweck/software-defined-storage/storage-spaces-direct/s2d-micro-cluster/s2d-micro-cluster-advanced.html Thomas-Krenn-Storage-Cluster]: 240GB SSD OS, 3TB Nested Mirror, SuperMicro, 32GiB DDR4 ECC, max. 185W/Server, 13.100 Euro für zwei Server
# [[Benutzer:Kite|Kite]] kann eventuell einen PowerEdge R510 startklarmachen. Er gibt noch bescheid, Basis-Specsheet [https://www.dell.com/downloads/global/products/pedge/R510_Spec_Sheet.pdf hier].

Übersicht --> [[NOC Team/To-Dos/Serverhardware Q1 2020]]

== Services ==

=== Mailserver ===

==== Spamfilter ====

Überarbeitung und Erweiterung. Wir bekommen keine Viagramails, aber einiges an Werbung. ''Erst'' Spamfilter, ''dann'' Unterpunkt Blocklisten ;-)

==== Mailman ====
lists.raumzeitlabor.de benutzt Mailman v2.1.18 vom 6.5.2014.

Eine [https://docs.mailman3.org/en/latest/migration.html Migration von 2.1 auf 3.x] ist möglich.

--[[Benutzer:Helix|Helix]] ([[Benutzer Diskussion:Helix|Diskussion]]) 14:07, 28. Dez. 2019 (CET)

=== Gitlab ===

# Root-Passwort unbekannt, Version zu alt und damit insecure.
# AutoDevops und CI-Runner sind aktiviert ohne Instanz, nerven also bei jedem neuen Projekt wieder. Das anzuschalten ohne es zu konfigurieren ist nicht gerade clever. Sollte man beseitigen oder nachfragen warum das überhaupt angedacht wurde.

NOC Team/To-Dos

2019-12-28T19:04:16Z

Lordeis: /* Holzwerkstatt */

== Tagebuch ==

Wichtiger Punkt: Dokumentation was bisher getan wurde. Was ergab sich aus der Freifunk-Diskussion heute, was aus Verm.+Pfalzkom+Politik, was machen wir mit dem Cisco-Stack hinsichtlich des Tschisko-Fuckups mit Self-Signed Certificates (ist zwar scheisse, macht aber jeder(tm), auch wir?) '''''vor''''' Januar 2020? Was habe ich vergessen?

Cisco siehe auch [https://www.cisco.com/c/en/us/support/docs/field-notices/704/fn70489.html FN 70489].

• [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 21:35, 27. Dez. 2019 (CET)

Und noch ein wichtiger Punkt: Entscheid Serverhardware, Anbringung des Kostenpunkts im Plenum Anfang Januar.

== Netzwerk ==

=== DNS rzl.so ===
Alle internen Dienste enden auf .rzl, was keine Domain ist, die uns gehört. Wäre cool, wenn das stattdessen .rzl.so wäre.

→ Split-DNS?

--[[Benutzer:Helix|Helix]] 14:35, 27. Dez. 2019 (CET)

=== SSL-Zertifikate ===
Für nur intern verfügbare Dienste wäre auch ein SSL-Zertifikat sinnvoll.

Letsencrypt *.rzl.so würde die internen Dienste dann nicht nach [https://crt.sh crt.sh] | [https://www.entrust.com/ct-search/?domain=raumzeitlabor.de&includeExpired=true&exactMatch=false entrust.com/ct-search] leaken, daher würde ich das vorschlagen.

Für extern verfügbare Dienste kann man dann ja je FQDN ein normales Cert holen. Eventuell auf [https://letsencrypt.org/docs/rate-limits/ Rate Limits] aufpassen.

--[[Benutzer:Helix|Helix]] 14:35, 27. Dez. 2019 (CET)

Aufbauend darauf (Obacht: Rate Limits are a real thing): Automatisierung der Zertifikate. LE-Zerts halten nur 3 Monate, da ist Rumgammeln keine Option mehr. Und die Faustregel heißt: ist es rein interner Kram? Wirklich? Wenn nein --> Non-Wildcard und SAN. Wildcard-Zerts sind obsolete Tech, machen wir nur zur Obfuscation. Doku essentiell, SAN-Zusammenfassung und -Stepping!

Zur Disk. im NOC-Meeting. Bei weiteren Diskussionspunkten diese Zeile löschen und bitte die Diskussionsseite dieses Artikels nutzen. • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 20:38, 27. Dez. 2019 (CET)

=== Inventur Internetleitung ===

Welche Leitungen haben wir, welche Möglichkeiten zum Upgrade gibt es?

Aktuelle Leitung:
: Telekom Hybrid 50Mbit
: 16 Mbit DSL
: Rest geht über im Router verbaute Sim Karte (Nur mit Telekom Router Kompatibel)

Geimeinsame Klärung mit der Spedition erstrebenswert.

=== Holzwerkstatt ===
Wurde geklärt es muss definitiv ein Patchpanel für die neue Werkstatt angeschafft werden. 
Zb.: https://fckaf.de/SY9 
Außerdem noch ein Switch da der momentane Ersatz ein relikt aus den 90ern ist. 
Am liebsten dieser: https://fckaf.de/dnS 
Oder jemand repariert den Ubiquity der seit Monaten in der Werkstatt liegt. 
- [[Benutzer:Lordeis|Lordeis]]

=== Freifunk + IPv6 ===

Zukunft ab 01.01.2020? Kübler Glasfaser? 
Fürs erste wenn möglich über das /56 Netz, das am Telekom Router anliegt. - [[Benutzer:Lordeis|Lordeis]]
Update vom 27.12.19: 
Laut [[Benutzer:cheatha|@cheatha]] wird gerade die Freifunk Infrastruktur umgezogen was uns ein wenig zeit ins neue jahr gewähren sollte.

=== Switches ===
Inventur aller Switche und Firmware Stand prüfen

==== Cisco Stack E Werkstatt ====
Update von Cisco verfügbar: '''1.4.11.02''' 
Diskussion ob Update durchgeführt werden soll - [[Benutzer:Lordeis|Lordeis]] 
'''Wichtig:''' 
'''Prüfen ob die Switche von dem Cisco Zertifikats Fuckup betroffen sind.'''

=== Benutzer-DB ===

TLS-Renewal. Details nach Fertigstellung.

=== Router ===
==== Ubiquity ====
# Auseinandersortieren der Netzwerkverbindungen.
# Reverse Engineering und Dokumentieren der Konfiguration.
# IPv6 Konfiguration.

==== Speedport (Telekom) ====
# Reverse Engineering und Dokumentieren der Konfiguration.
# IPv6 Konfiguration.

Kommentar Ranlvor: Sollte ziemlich Standard sein, nur eventuell ein paar Regeln drin, die versuchen sollen Telefonie-Traffic auf DSL zu zwingen (weil das weniger schlecht tut als via LTE).

=== WIFI Access Points ===
==== Ubiquity ====
# Reverse Engineering und Dokumentieren der Konfiguration.
# Auseinadersortieren der SSIDs:
## Prüfen ob alle SSIDs nötig sind.
## Diskutieren ob Band Steering Sinvoll Wäre.
## Prüfen ob Layer 3 Roaming Sinnig ist.
# Prüfung ob ein zusätzlicher Unify AP für die Werkstatt sinn macht.
# Auslagern des RZL IOT WLAN auf anderen AP.

==== IOT Accesspoint ====
# Extra AP verwenden da Performance Probleme.
# Ich habe noch einen Lancom Rumliegen den ich Spenden würde - [[Benutzer:Lordeis|Lordeis]]

=== Verkabelung ===

# Die zwei Tische an der E/Ä-Ecke sind vorbildlich verkabelt, wenn man sie als autonome Hackrepublik innerhalb des RZL betrachtet. --> Uplink-Kabel setzen.
## Update: Hab' mal Kabel geordert, Kanäle haben wir noch da. Könnte auch beim Umbau 2020 hilfreich sein. • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 18:34, 28. Dez. 2019 (CET)

== Hypervisor ==

=== RAM ===

Welche Möglichkeiten zum Update gibt es? Kurzfristiger Punkt, da der RAM erschöpft ist. AUf jeden Fall mögliches Upgrade wären zusätzliche 4 GiB für 30-40 Euronen, wenn wir in den Server reingeschaut haben wissen wir aber ob noch mehr als die dann 16GiB gehen.

Aktuelles To-Do: Dokumentation Hardwaremöglichkeiten - [[Benutzer:0xb4dc0d3d|0xb4dc0d3d]]

Update: Macht das noch Sinn? Siehe Punkt Server-Hardware weiter unten in diesem Kapitel. • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 22:10, 27. Dez. 2019 (CET)

=== Rechtekonzept ===

User sollten ihre VMs durchstarten können. Geht Hand in Hand mit dem Gedanken, nicht mehr überall als root zu springen und alles als root zu tun, stattdessen Nutzung sudo und mittelfristig ggf. Anbindung an [[UserDB|UserDB]].

Person mit Hut: [[Benutzer:0xb4dc0d3d|0xb4dc0d3d]]

=== Hypervisor-Software ===

# HV bleibt KVM. Helix erwähnte heute Cockpit, das scheint also auch ohne das ganze oVirt-Debakel zu gehen, und wäre dann prima. Geht als Frontend dann mit dem Rechtekonzept Hand in Hand. Alternative: Proxmox als Aufsatz, nicht(!!!) als Basis.

# OS sollte CentOS sein: der Hypervisor hat dumm zu sein (CA-Verwaltung, Automatisierung etc. darf da nicht laufen), also genügt CentOS, und wir gewinnen den Benefit SELinux. (Alternative wäre Arch, aber Rolling Release in bedingt gewarteter aber produktiver Umgebung? Meh. Willstenich.)

Gesamtes Kapitel zur Diskussion, habe ich ad hoc so niedergeschrieben • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 21:13, 27. Dez. 2019 (CET)

=== VM-Inventur ===

Prüfen, was noch aktiv ist, und nach einer geordneten(!) Inventarisierung Mitglieder bei Bedarf anschreiben. Im Zweifelsfall Downtime und einen Zeitraum X auf Reaktion warten.

=== VM-Struktur ===

Ordnung schaffen: Sind Dinge(tm) produktiv, sollten diese auf dedizierte VMs, gutes Beispiel hier: [[cashdesk.rzl]] (leider auch gutes Beispiel für undoumentierte VM).

Kommentar Ranlvor: cashdesk ist ein schlechtes Beispiel, da das eigentlich mal eine MemberVM war und neben cashdesk auch den Infoscreen hosted.

=== Serverhardware ===

Zukunft: Redundanz? Idee: KVM over 2 Nodes mit GlusterFS.

# Ob wir 2 Nodes brauchen oder 1 reicht, sollten wir in NOC-Meeting und Plenum diskutieren.
# Basis: Nunja, 32 oder 64GiB RAM, mind. 64 GiB Platte und schauen wo die 3-4 TiB VM-Store hinkommen. Alos Basisrahmen, zur Diksussion und Anpassung hier. • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 18:31, 27. Dez. 2019 (CET)

Erneuerung unumgänglich, RAM-Erweiterung ist nur Lebenserhaltungsmaßnahme bei einer designierten Leiche.

Optionen:
# SuperMicro-Server laut [[Benutzer:Lordeis|Lordeis]] (bitte ergänzen)
# [https://www.thomas-krenn.com/de/produkte/einsatzzweck/software-defined-storage/storage-spaces-direct/s2d-micro-cluster/s2d-micro-cluster-advanced.html Thomas-Krenn-Storage-Cluster]: 240GB SSD OS, 3TB Nested Mirror, SuperMicro, 32GiB DDR4 ECC, max. 185W/Server, 13.100 Euro für zwei Server
# [[Benutzer:Kite|Kite]] kann eventuell einen PowerEdge R510 startklarmachen. Er gibt noch bescheid, Basis-Specsheet [https://www.dell.com/downloads/global/products/pedge/R510_Spec_Sheet.pdf hier].

Übersicht --> [[NOC Team/To-Dos/Serverhardware Q1 2020]]

== Mailserver ==

=== Spamfilter ===

Überarbeitung und Erweiterung. Wir bekommen keine Viagramails, aber einiges an Werbung. ''Erst'' Spamfilter, ''dann'' Unterpunkt Blocklisten ;-)

=== Mailman ===
lists.raumzeitlabor.de benutzt Mailman v2.1.18 vom 6.5.2014.

Eine [https://docs.mailman3.org/en/latest/migration.html Migration von 2.1 auf 3.x] ist möglich.

--[[Benutzer:Helix|Helix]] ([[Benutzer Diskussion:Helix|Diskussion]]) 14:07, 28. Dez. 2019 (CET)

NOC Team/To-Dos

2019-12-28T18:51:53Z

Lordeis: /* Cisco Stack E Werkstatt */

== Tagebuch ==

Wichtiger Punkt: Dokumentation was bisher getan wurde. Was ergab sich aus der Freifunk-Diskussion heute, was aus Verm.+Pfalzkom+Politik, was machen wir mit dem Cisco-Stack hinsichtlich des Tschisko-Fuckups mit Self-Signed Certificates (ist zwar scheisse, macht aber jeder(tm), auch wir?) '''''vor''''' Januar 2020? Was habe ich vergessen?

Cisco siehe auch [https://www.cisco.com/c/en/us/support/docs/field-notices/704/fn70489.html FN 70489].

• [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 21:35, 27. Dez. 2019 (CET)

Und noch ein wichtiger Punkt: Entscheid Serverhardware, Anbringung des Kostenpunkts im Plenum Anfang Januar.

== Netzwerk ==

=== DNS rzl.so ===
Alle internen Dienste enden auf .rzl, was keine Domain ist, die uns gehört. Wäre cool, wenn das stattdessen .rzl.so wäre.

→ Split-DNS?

--[[Benutzer:Helix|Helix]] 14:35, 27. Dez. 2019 (CET)

=== SSL-Zertifikate ===
Für nur intern verfügbare Dienste wäre auch ein SSL-Zertifikat sinnvoll.

Letsencrypt *.rzl.so würde die internen Dienste dann nicht nach [https://crt.sh crt.sh] | [https://www.entrust.com/ct-search/?domain=raumzeitlabor.de&includeExpired=true&exactMatch=false entrust.com/ct-search] leaken, daher würde ich das vorschlagen.

Für extern verfügbare Dienste kann man dann ja je FQDN ein normales Cert holen. Eventuell auf [https://letsencrypt.org/docs/rate-limits/ Rate Limits] aufpassen.

--[[Benutzer:Helix|Helix]] 14:35, 27. Dez. 2019 (CET)

Aufbauend darauf (Obacht: Rate Limits are a real thing): Automatisierung der Zertifikate. LE-Zerts halten nur 3 Monate, da ist Rumgammeln keine Option mehr. Und die Faustregel heißt: ist es rein interner Kram? Wirklich? Wenn nein --> Non-Wildcard und SAN. Wildcard-Zerts sind obsolete Tech, machen wir nur zur Obfuscation. Doku essentiell, SAN-Zusammenfassung und -Stepping!

Zur Disk. im NOC-Meeting. Bei weiteren Diskussionspunkten diese Zeile löschen und bitte die Diskussionsseite dieses Artikels nutzen. • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 20:38, 27. Dez. 2019 (CET)

=== Inventur Internetleitung ===

Welche Leitungen haben wir, welche Möglichkeiten zum Upgrade gibt es?

Aktuelle Leitung:
: Telekom Hybrid 50Mbit
: 16 Mbit DSL
: Rest geht über im Router verbaute Sim Karte (Nur mit Telekom Router Kompatibel)

Geimeinsame Klärung mit der Spedition erstrebenswert.

=== Holzwerkstatt ===

Braucht das Netzwerk? V.a. braucht das Netzwerk langfristig? 
Gespräch mit Spike am Dienstag 10.12.19 - [[Benutzer:Lordeis|Lordeis]]

=== Freifunk + IPv6 ===

Zukunft ab 01.01.2020? Kübler Glasfaser? 
Fürs erste wenn möglich über das /56 Netz, das am Telekom Router anliegt. - [[Benutzer:Lordeis|Lordeis]]
Update vom 27.12.19: 
Laut [[Benutzer:cheatha|@cheatha]] wird gerade die Freifunk Infrastruktur umgezogen was uns ein wenig zeit ins neue jahr gewähren sollte.

=== Switches ===
Inventur aller Switche und Firmware Stand prüfen

==== Cisco Stack E Werkstatt ====
Update von Cisco verfügbar: '''1.4.11.02''' 
Diskussion ob Update durchgeführt werden soll - [[Benutzer:Lordeis|Lordeis]] 
'''Wichtig:''' 
'''Prüfen ob die Switche von dem Cisco Zertifikats Fuckup betroffen sind.'''

=== Benutzer-DB ===

TLS-Renewal. Details nach Fertigstellung.

=== Router ===
==== Ubiquity ====
# Auseinandersortieren der Netzwerkverbindungen.
# Reverse Engineering und Dokumentieren der Konfiguration.
# IPv6 Konfiguration.

==== Speedport (Telekom) ====
# Reverse Engineering und Dokumentieren der Konfiguration.
# IPv6 Konfiguration.

Kommentar Ranlvor: Sollte ziemlich Standard sein, nur eventuell ein paar Regeln drin, die versuchen sollen Telefonie-Traffic auf DSL zu zwingen (weil das weniger schlecht tut als via LTE).

=== WIFI Access Points ===
==== Ubiquity ====
# Reverse Engineering und Dokumentieren der Konfiguration.
# Auseinadersortieren der SSIDs:
## Prüfen ob alle SSIDs nötig sind.
## Diskutieren ob Band Steering Sinvoll Wäre.
## Prüfen ob Layer 3 Roaming Sinnig ist.
# Prüfung ob ein zusätzlicher Unify AP für die Werkstatt sinn macht.
# Auslagern des RZL IOT WLAN auf anderen AP.

==== IOT Accesspoint ====
# Extra AP verwenden da Performance Probleme.
# Ich habe noch einen Lancom Rumliegen den ich Spenden würde - [[Benutzer:Lordeis|Lordeis]]

=== Verkabelung ===

# Die zwei Tische an der E/Ä-Ecke sind vorbildlich verkabelt, wenn man sie als autonome Hackrepublik innerhalb des RZL betrachtet. --> Uplink-Kabel setzen.
## Update: Hab' mal Kabel geordert, Kanäle haben wir noch da. Könnte auch beim Umbau 2020 hilfreich sein. • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 18:34, 28. Dez. 2019 (CET)

== Hypervisor ==

=== RAM ===

Welche Möglichkeiten zum Update gibt es? Kurzfristiger Punkt, da der RAM erschöpft ist. AUf jeden Fall mögliches Upgrade wären zusätzliche 4 GiB für 30-40 Euronen, wenn wir in den Server reingeschaut haben wissen wir aber ob noch mehr als die dann 16GiB gehen.

Aktuelles To-Do: Dokumentation Hardwaremöglichkeiten - [[Benutzer:0xb4dc0d3d|0xb4dc0d3d]]

Update: Macht das noch Sinn? Siehe Punkt Server-Hardware weiter unten in diesem Kapitel. • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 22:10, 27. Dez. 2019 (CET)

=== Rechtekonzept ===

User sollten ihre VMs durchstarten können. Geht Hand in Hand mit dem Gedanken, nicht mehr überall als root zu springen und alles als root zu tun, stattdessen Nutzung sudo und mittelfristig ggf. Anbindung an [[UserDB|UserDB]].

Person mit Hut: [[Benutzer:0xb4dc0d3d|0xb4dc0d3d]]

=== Hypervisor-Software ===

# HV bleibt KVM. Helix erwähnte heute Cockpit, das scheint also auch ohne das ganze oVirt-Debakel zu gehen, und wäre dann prima. Geht als Frontend dann mit dem Rechtekonzept Hand in Hand. Alternative: Proxmox als Aufsatz, nicht(!!!) als Basis.

# OS sollte CentOS sein: der Hypervisor hat dumm zu sein (CA-Verwaltung, Automatisierung etc. darf da nicht laufen), also genügt CentOS, und wir gewinnen den Benefit SELinux. (Alternative wäre Arch, aber Rolling Release in bedingt gewarteter aber produktiver Umgebung? Meh. Willstenich.)

Gesamtes Kapitel zur Diskussion, habe ich ad hoc so niedergeschrieben • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 21:13, 27. Dez. 2019 (CET)

=== VM-Inventur ===

Prüfen, was noch aktiv ist, und nach einer geordneten(!) Inventarisierung Mitglieder bei Bedarf anschreiben. Im Zweifelsfall Downtime und einen Zeitraum X auf Reaktion warten.

=== VM-Struktur ===

Ordnung schaffen: Sind Dinge(tm) produktiv, sollten diese auf dedizierte VMs, gutes Beispiel hier: [[cashdesk.rzl]] (leider auch gutes Beispiel für undoumentierte VM).

Kommentar Ranlvor: cashdesk ist ein schlechtes Beispiel, da das eigentlich mal eine MemberVM war und neben cashdesk auch den Infoscreen hosted.

=== Serverhardware ===

Zukunft: Redundanz? Idee: KVM over 2 Nodes mit GlusterFS.

# Ob wir 2 Nodes brauchen oder 1 reicht, sollten wir in NOC-Meeting und Plenum diskutieren.
# Basis: Nunja, 32 oder 64GiB RAM, mind. 64 GiB Platte und schauen wo die 3-4 TiB VM-Store hinkommen. Alos Basisrahmen, zur Diksussion und Anpassung hier. • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 18:31, 27. Dez. 2019 (CET)

Erneuerung unumgänglich, RAM-Erweiterung ist nur Lebenserhaltungsmaßnahme bei einer designierten Leiche.

Optionen:
# SuperMicro-Server laut [[Benutzer:Lordeis|Lordeis]] (bitte ergänzen)
# [https://www.thomas-krenn.com/de/produkte/einsatzzweck/software-defined-storage/storage-spaces-direct/s2d-micro-cluster/s2d-micro-cluster-advanced.html Thomas-Krenn-Storage-Cluster]: 240GB SSD OS, 3TB Nested Mirror, SuperMicro, 32GiB DDR4 ECC, max. 185W/Server, 13.100 Euro für zwei Server
# [[Benutzer:Kite|Kite]] kann eventuell einen PowerEdge R510 startklarmachen. Er gibt noch bescheid, Basis-Specsheet [https://www.dell.com/downloads/global/products/pedge/R510_Spec_Sheet.pdf hier].

Übersicht --> [[NOC Team/To-Dos/Serverhardware Q1 2020]]

== Mailserver ==

=== Spamfilter ===

Überarbeitung und Erweiterung. Wir bekommen keine Viagramails, aber einiges an Werbung. ''Erst'' Spamfilter, ''dann'' Unterpunkt Blocklisten ;-)

=== Mailman ===
lists.raumzeitlabor.de benutzt Mailman v2.1.18 vom 6.5.2014.

Eine [https://docs.mailman3.org/en/latest/migration.html Migration von 2.1 auf 3.x] ist möglich.

--[[Benutzer:Helix|Helix]] ([[Benutzer Diskussion:Helix|Diskussion]]) 14:07, 28. Dez. 2019 (CET)

NOC Team/To-Dos

2019-12-28T18:45:54Z

Lordeis: /* Freifunk + IPv6 */

== Tagebuch ==

Wichtiger Punkt: Dokumentation was bisher getan wurde. Was ergab sich aus der Freifunk-Diskussion heute, was aus Verm.+Pfalzkom+Politik, was machen wir mit dem Cisco-Stack hinsichtlich des Tschisko-Fuckups mit Self-Signed Certificates (ist zwar scheisse, macht aber jeder(tm), auch wir?) '''''vor''''' Januar 2020? Was habe ich vergessen?

Cisco siehe auch [https://www.cisco.com/c/en/us/support/docs/field-notices/704/fn70489.html FN 70489].

• [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 21:35, 27. Dez. 2019 (CET)

Und noch ein wichtiger Punkt: Entscheid Serverhardware, Anbringung des Kostenpunkts im Plenum Anfang Januar.

== Netzwerk ==

=== DNS rzl.so ===
Alle internen Dienste enden auf .rzl, was keine Domain ist, die uns gehört. Wäre cool, wenn das stattdessen .rzl.so wäre.

→ Split-DNS?

--[[Benutzer:Helix|Helix]] 14:35, 27. Dez. 2019 (CET)

=== SSL-Zertifikate ===
Für nur intern verfügbare Dienste wäre auch ein SSL-Zertifikat sinnvoll.

Letsencrypt *.rzl.so würde die internen Dienste dann nicht nach [https://crt.sh crt.sh] | [https://www.entrust.com/ct-search/?domain=raumzeitlabor.de&includeExpired=true&exactMatch=false entrust.com/ct-search] leaken, daher würde ich das vorschlagen.

Für extern verfügbare Dienste kann man dann ja je FQDN ein normales Cert holen. Eventuell auf [https://letsencrypt.org/docs/rate-limits/ Rate Limits] aufpassen.

--[[Benutzer:Helix|Helix]] 14:35, 27. Dez. 2019 (CET)

Aufbauend darauf (Obacht: Rate Limits are a real thing): Automatisierung der Zertifikate. LE-Zerts halten nur 3 Monate, da ist Rumgammeln keine Option mehr. Und die Faustregel heißt: ist es rein interner Kram? Wirklich? Wenn nein --> Non-Wildcard und SAN. Wildcard-Zerts sind obsolete Tech, machen wir nur zur Obfuscation. Doku essentiell, SAN-Zusammenfassung und -Stepping!

Zur Disk. im NOC-Meeting. Bei weiteren Diskussionspunkten diese Zeile löschen und bitte die Diskussionsseite dieses Artikels nutzen. • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 20:38, 27. Dez. 2019 (CET)

=== Inventur Internetleitung ===

Welche Leitungen haben wir, welche Möglichkeiten zum Upgrade gibt es?

Aktuelle Leitung:
: Telekom Hybrid 50Mbit
: 16 Mbit DSL
: Rest geht über im Router verbaute Sim Karte (Nur mit Telekom Router Kompatibel)

Geimeinsame Klärung mit der Spedition erstrebenswert.

=== Holzwerkstatt ===

Braucht das Netzwerk? V.a. braucht das Netzwerk langfristig? 
Gespräch mit Spike am Dienstag 10.12.19 - [[Benutzer:Lordeis|Lordeis]]

=== Freifunk + IPv6 ===

Zukunft ab 01.01.2020? Kübler Glasfaser? 
Fürs erste wenn möglich über das /56 Netz, das am Telekom Router anliegt. - [[Benutzer:Lordeis|Lordeis]]
Update vom 27.12.19: 
Laut [[Benutzer:cheatha|@cheatha]] wird gerade die Freifunk Infrastruktur umgezogen was uns ein wenig zeit ins neue jahr gewähren sollte.

=== Switches ===
Inventur aller Switche und Firmware Stand prüfen

==== Cisco Stack E Werkstatt ====
Update von Cisco verfügbar: '''1.4.11.02''' 
Diskussion ob Update durchgeführt werden soll - [[Benutzer:Lordeis|Lordeis]]

=== Benutzer-DB ===

TLS-Renewal. Details nach Fertigstellung.

=== Router ===
==== Ubiquity ====
# Auseinandersortieren der Netzwerkverbindungen.
# Reverse Engineering und Dokumentieren der Konfiguration.
# IPv6 Konfiguration.

==== Speedport (Telekom) ====
# Reverse Engineering und Dokumentieren der Konfiguration.
# IPv6 Konfiguration.

Kommentar Ranlvor: Sollte ziemlich Standard sein, nur eventuell ein paar Regeln drin, die versuchen sollen Telefonie-Traffic auf DSL zu zwingen (weil das weniger schlecht tut als via LTE).

=== WIFI Access Points ===
==== Ubiquity ====
# Reverse Engineering und Dokumentieren der Konfiguration.
# Auseinadersortieren der SSIDs:
## Prüfen ob alle SSIDs nötig sind.
## Diskutieren ob Band Steering Sinvoll Wäre.
## Prüfen ob Layer 3 Roaming Sinnig ist.
# Prüfung ob ein zusätzlicher Unify AP für die Werkstatt sinn macht.
# Auslagern des RZL IOT WLAN auf anderen AP.

==== IOT Accesspoint ====
# Extra AP verwenden da Performance Probleme.
# Ich habe noch einen Lancom Rumliegen den ich Spenden würde - [[Benutzer:Lordeis|Lordeis]]

=== Verkabelung ===

# Die zwei Tische an der E/Ä-Ecke sind vorbildlich verkabelt, wenn man sie als autonome Hackrepublik innerhalb des RZL betrachtet. --> Uplink-Kabel setzen.
## Update: Hab' mal Kabel geordert, Kanäle haben wir noch da. Könnte auch beim Umbau 2020 hilfreich sein. • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 18:34, 28. Dez. 2019 (CET)

== Hypervisor ==

=== RAM ===

Welche Möglichkeiten zum Update gibt es? Kurzfristiger Punkt, da der RAM erschöpft ist. AUf jeden Fall mögliches Upgrade wären zusätzliche 4 GiB für 30-40 Euronen, wenn wir in den Server reingeschaut haben wissen wir aber ob noch mehr als die dann 16GiB gehen.

Aktuelles To-Do: Dokumentation Hardwaremöglichkeiten - [[Benutzer:0xb4dc0d3d|0xb4dc0d3d]]

Update: Macht das noch Sinn? Siehe Punkt Server-Hardware weiter unten in diesem Kapitel. • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 22:10, 27. Dez. 2019 (CET)

=== Rechtekonzept ===

User sollten ihre VMs durchstarten können. Geht Hand in Hand mit dem Gedanken, nicht mehr überall als root zu springen und alles als root zu tun, stattdessen Nutzung sudo und mittelfristig ggf. Anbindung an [[UserDB|UserDB]].

Person mit Hut: [[Benutzer:0xb4dc0d3d|0xb4dc0d3d]]

=== Hypervisor-Software ===

# HV bleibt KVM. Helix erwähnte heute Cockpit, das scheint also auch ohne das ganze oVirt-Debakel zu gehen, und wäre dann prima. Geht als Frontend dann mit dem Rechtekonzept Hand in Hand. Alternative: Proxmox als Aufsatz, nicht(!!!) als Basis.

# OS sollte CentOS sein: der Hypervisor hat dumm zu sein (CA-Verwaltung, Automatisierung etc. darf da nicht laufen), also genügt CentOS, und wir gewinnen den Benefit SELinux. (Alternative wäre Arch, aber Rolling Release in bedingt gewarteter aber produktiver Umgebung? Meh. Willstenich.)

Gesamtes Kapitel zur Diskussion, habe ich ad hoc so niedergeschrieben • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 21:13, 27. Dez. 2019 (CET)

=== VM-Inventur ===

Prüfen, was noch aktiv ist, und nach einer geordneten(!) Inventarisierung Mitglieder bei Bedarf anschreiben. Im Zweifelsfall Downtime und einen Zeitraum X auf Reaktion warten.

=== VM-Struktur ===

Ordnung schaffen: Sind Dinge(tm) produktiv, sollten diese auf dedizierte VMs, gutes Beispiel hier: [[cashdesk.rzl]] (leider auch gutes Beispiel für undoumentierte VM).

Kommentar Ranlvor: cashdesk ist ein schlechtes Beispiel, da das eigentlich mal eine MemberVM war und neben cashdesk auch den Infoscreen hosted.

=== Serverhardware ===

Zukunft: Redundanz? Idee: KVM over 2 Nodes mit GlusterFS.

# Ob wir 2 Nodes brauchen oder 1 reicht, sollten wir in NOC-Meeting und Plenum diskutieren.
# Basis: Nunja, 32 oder 64GiB RAM, mind. 64 GiB Platte und schauen wo die 3-4 TiB VM-Store hinkommen. Alos Basisrahmen, zur Diksussion und Anpassung hier. • [[User:0xb4dc0d3d| 0xb4dc0d3d ]][[Benutzer Diskussion:0xb4dc0d3d| wtf?]] • 18:31, 27. Dez. 2019 (CET)

Erneuerung unumgänglich, RAM-Erweiterung ist nur Lebenserhaltungsmaßnahme bei einer designierten Leiche.

Optionen:
# SuperMicro-Server laut [[Benutzer:Lordeis|Lordeis]] (bitte ergänzen)
# [https://www.thomas-krenn.com/de/produkte/einsatzzweck/software-defined-storage/storage-spaces-direct/s2d-micro-cluster/s2d-micro-cluster-advanced.html Thomas-Krenn-Storage-Cluster]: 240GB SSD OS, 3TB Nested Mirror, SuperMicro, 32GiB DDR4 ECC, max. 185W/Server, 13.100 Euro für zwei Server
# [[Benutzer:Kite|Kite]] kann eventuell einen PowerEdge R510 startklarmachen. Er gibt noch bescheid, Basis-Specsheet [https://www.dell.com/downloads/global/products/pedge/R510_Spec_Sheet.pdf hier].

Übersicht --> [[NOC Team/To-Dos/Serverhardware Q1 2020]]

== Mailserver ==

=== Spamfilter ===

Überarbeitung und Erweiterung. Wir bekommen keine Viagramails, aber einiges an Werbung. ''Erst'' Spamfilter, ''dann'' Unterpunkt Blocklisten ;-)

=== Mailman ===
lists.raumzeitlabor.de benutzt Mailman v2.1.18 vom 6.5.2014.

Eine [https://docs.mailman3.org/en/latest/migration.html Migration von 2.1 auf 3.x] ist möglich.

--[[Benutzer:Helix|Helix]] ([[Benutzer Diskussion:Helix|Diskussion]]) 14:07, 28. Dez. 2019 (CET)

NOC Team/To-Dos

2019-12-08T20:23:45Z

Lordeis: /* Netzwerk */

== Netzwerk ==

=== Inventur Internetleitung ===

Welche Leitungen haben wir, welche Möglichkeiten zum Upgrade gibt es? 
-Lordeis-
Aktuelle Leitung:
Telekom Hybrid 50Mbit
16 Mbit DSL
Rest geht über im Router verbaute Sim Karte (Nur mit Telekom Router Kompatibel)

Geimeinsame klärung mit der Spedition erstrebenswert.

=== Holzwerkstatt ===

Braucht das Netzwerk? V.a. braucht das Netzwerk langfristig? 
Gespräch mit Spike am Dienstag 10.12.19 -Lordeis

=== Freifunk + IPv6 ===

Zukunft ab 01.01.2020? Kübler Glasfaser? 
Fürs erste wenn möglich über das /56 Netz dass am Telekom Router anliegt. -Lordeis

=== Switches ===
Inventur aller Switche und Firmware Stand prüfen

==== Cisco Stack E Werkstatt ====
Update von Cisco verfügbar: '''1.4.11.02''' 
Diskussion ob Update durchgeführt werden soll? -Lordeis

=== Router ===
==== Ubiquity ====
Auseinandersortieren der Netzwerkverbindungen. 
Reverse Engineering und Dokumentieren der Konfiguration.
IPv6 Konfiguration.

==== Speedport (Telekom) ====
Reverse Engineering und Dokumentieren der Konfiguration.
IPv6 Konfiguration.

=== WIFI Access Points ===
==== Ubiquity ====
Reverse Engineering und Dokumentieren der Konfiguration. 
Auseinadersortieren der SSIDs:
Prüfen ob alle SSIDs nötig sind.
Diskutieren ob Band Steering Sinvoll Wäre.
Prüfen ob Layer 3 Roaming Sinnig ist.

Prüfung ob ein zusätzlicher Unify AP für die Werkstatt sinn macht. 
Auslagern des RZL IOT WLAN auf anderen AP.

==== IOT Accesspoint ====
Extra AP verwenden da Performance Probleme. 
Ich habe noch einen Lancom Rumliegen den ich Spenden würde? -Lordeis

== Hypervisor ==

=== RAM ===

Welche Möglichkeiten zum Update gibt es? Kurzfristiger Punkt, da der RAM erschöpft ist. AUf jeden Fall mögliches Upgrade wären zusätzliche 4 GiB für 30-40 Euronen, wenn wir in den Server reingeschaut haben wissen wir aber ob noch mehr als die dann 16GiB gehen.

Aktuelles To-Do: Dokumentation Hardwaremöglichkeiten - [[Benutzer:0xb4dc0d3d|0xb4dc0d3d]]

=== Rechtekonzept ===

User sollten ihre VMs durchstarten können. Geht Hand in Hand mit dem Gedanken, nicht mehr überall als root zu springen und alles als root zu tun, stattdessen Nutzung sudo und mittelfristig ggf. Anbindung an [[#UserDB|UserDB]].

Person mit Hut: [[Benutzer:0xb4dc0d3d|0xb4dc0d3d]]

=== VM-Inventur ===

Prüfen, was noch aktiv ist, und nach einer geordneten(!) Inventarisierung Mitglieder bei Bedarf anschreiben. Im Zweifelsfall Downtime und einen Zeitraum X auf Reaktion warten.

=== VM-Struktur ===

Ordnung schaffen: Sind Dinge(tm) produktiv, sollten diese auf dedizierte VMs, gutes Beispiel hier: [[cashdesk.rzl]] (leider auch gutes Beispiel für undoumentierte VM).

=== Serverhardware ===

Zukunft: Redundanz? Idee: KVM over 2 Nodes mit GlusterFS. Keinen DAU-kompatiblen Kram wie oVirt, wir sollten bei KVM bleiben.

== UserDB ==

Redundanter Punkt. Vielleicht realisieren wir in NOC-Kommunikation etwas und führen das dann zusammen.

== Mailserver ==

=== Spamfilter ===

Überarbeitung und Erweiterung. Wir bekommen keine Viagramails, aber einiges an Werbung. ''Erst'' Spamfilter, ''dann'' Unterpunkt Blocklisten ;-)

NOC Team/To-Dos

2019-12-08T17:50:51Z

Lordeis: /* Netzwerk */

NOC Team/To-Dos

2019-12-08T17:47:13Z

Lordeis: /* Netzwerk */

== Netzwerk ==

=== Inventur Internetleitung ===

Welche Leitungen haben wir, welche Möglichkeiten zum Upgrade gibt es?
Aktuelle Leitung: Telekom Hybrid 50Mbit
16 Mbit DSL
Rest geht über im Router verbaute Sim Karte (Nur mit Telekom Router Kompatibel)

Geimeinsame klärung mit der Spedition erstrebenswert.

=== Holzwerkstatt ===

Braucht das Netzwerk? V.a. braucht das Netzwerk langfristig? 
Gespräch mit Spike am Dienstag 10.12.19

=== Freifunk + IPv6 ===

Zukunft ab 01.01.2020? Kübler Glasfaser? 
Fürs erste wenn möglich über das /56 Netz dass am Telekom Router anliegt.

== Hypervisor ==

=== RAM ===

Welche Möglichkeiten zum Update gibt es? Kurzfristiger Punkt, da der RAM erschöpft ist. AUf jeden Fall mögliches Upgrade wären zusätzliche 4 GiB für 30-40 Euronen, wenn wir in den Server reingeschaut haben wissen wir aber ob noch mehr als die dann 16GiB gehen.

Aktuelles To-Do: Dokumentation Hardwaremöglichkeiten - [[Benutzer:0xb4dc0d3d|0xb4dc0d3d]]

=== Rechtekonzept ===

User sollten ihre VMs durchstarten können. Geht Hand in Hand mit dem Gedanken, nicht mehr überall als root zu springen und alles als root zu tun, stattdessen Nutzung sudo und mittelfristig ggf. Anbindung an [[#UserDB|UserDB]].

Person mit Hut: [[Benutzer:0xb4dc0d3d|0xb4dc0d3d]]

=== VM-Inventur ===

Prüfen, was noch aktiv ist, und nach einer geordneten(!) Inventarisierung Mitglieder bei Bedarf anschreiben. Im Zweifelsfall Downtime und einen Zeitraum X auf Reaktion warten.

=== VM-Struktur ===

Ordnung schaffen: Sind Dinge(tm) produktiv, sollten diese auf dedizierte VMs, gutes Beispiel hier: [[cashdesk.rzl]] (leider auch gutes Beispiel für undoumentierte VM).

=== Serverhardware ===

Zukunft: Redundanz? Idee: KVM over 2 Nodes mit GlusterFS. Keinen DAU-kompatiblen Kram wie oVirt, wir sollten bei KVM bleiben.

== UserDB ==

Redundanter Punkt. Vielleicht realisieren wir in NOC-Kommunikation etwas und führen das dann zusammen.

== Mailserver ==

=== Spamfilter ===

Überarbeitung und Erweiterung. Wir bekommen keine Viagramails, aber einiges an Werbung. ''Erst'' Spamfilter, ''dann'' Unterpunkt Blocklisten ;-)

Tardis

2015-01-14T17:16:33Z

Lordeis: /* Tardis1 */

[[Kategorie:Infrastruktur]]{{ProjektInfoBox
|name = TARDIS
|status = stable
|description = Technisch Aussehende Rätselhafte Dinge Im Schrank
|author =
|username =
|version =
|update =
|platform =
|license =
|download =
}}

== Fakten ==

=== Pro Schublade ===
* Breite gesamt: 38,5 cm
* Breite (Staubreite mit Mittelteiler): ca. 16,5cm
* Höhe (Stauhöhe): 10 cm
* Tiefe (Stautiefe): 113 cm

Es passen 66 Pollin H1-Kisten pro Schublade rein.

'''Das Nutzungsrecht für eine Schublade kostet 10€ (keine Rückerstattung!). Leute, die für die Schrankanlage gespendet haben, erhalten den Spendenwert in Schubladen.'''

=== Tardis1 ===

* im Hauptraum
* 17 Schubladen hoch, 6 Schubladen breit.
* mit Beleuchtung
* Im Heptadezimalsystem nummeriert

{| class="wikitable"
|0x00 Laborant: Alexander
|0x10 Laborant: Lordeis
|0x20 Laborant: Dr. Ahti
|0x30 Laborant: slowpoke
|0x40 Laborant: slowpoke
|0x50 Laborant: Inte
|0x60 Laborant: oko
|-
|0x01 Laborant: Alexander
|0x11 Laborant: blabber
|0x21 Laborant: Dr. Ahti
|0x31 Laborant: slowpoke
|0x41 Laborant: slowpoke
|0x51 Laborant: Inte (leer)
|0x61 Projekt: Buchscanner
|-
|0x02 Laborant: Alexander
|0x12 Laborant: sebi
|0x22 Laborant: drahti
|0x32 Laborant: evil_sadness
|0x42 Laborant: slowpoke
|0x52 Laborant: Inte
|0x62 Laborant: docsteel
|-
|0x03 Laborant: echox
|0x13 Laborant: nicoduck
|0x23 Laborant: drahti
|0x33 Laborant: hog
|0x43 Laborant: yocky96
|0x53 Laborant: Inte
|0x63 Laborant: docsteel
|-
|0x04 Laborant: echox
|0x14 Laborant: nicoduck
|0x24 Laborant: nicoduck
|0x34 Gehäuse
|0x44 Kleber
|0x54 Laborant: Inte
|0x64 Team R.E.T.R.O
|-
|0x05 Laborant: thinkJD
|0x15 Laborant: hax404
|0x25 Laborant: hax404
|0x35 Elektro-Bauteile
|0x45 Laborant: cheatha
|0x55 Laborant: d0n
|0x65 Laborant: d0n
|-
|0x06 Laborant: Dashie
|0x16 Laborant: thinkJD
|0x26 Elektro-Bauteilkästen
|0x36 E-Bauteile/Strom
|0x46 Laborant: Kristian
|0x56 Laborant: Felicitus
|0x66 Laborant: danny
|-
|0x07 Laborant: Dashie (schwergängig!)
|0x17 Diverses und Lüfter
|0x27 Elektro-Bauteilkästen
|0x37 Elektro-Bauteile (lose)
|0x47 Laborant: zwetschgo
|0x57 Laborant: Felicitus
|0x67 Laborant: whilo
|-
|0x08 Laborant: lutoma
|0x18 Laborant: Felicitus
|0x28 Elektro-Bauteilkästen
|0x38 Kabel
|0x48 Laborant: hexelena
|0x58 Laborant: Felicitus
|0x68 Laborant: steeph
|-
|0x09 Laborant: lutoma
|0x19 Notebooks
|0x29 Bauteile / Mikroständer
|0x39 Kabel
|0x49 Laborant: Kisl
|0x59 Felicitus
|0x69 steeph
|-
|0x0A Batterien / Kreidespray
|0x1A ABS / Staubsaugerzubehör
|0x2A PC-Netzteile / Bausätze
|0x3A Laborant: else
|0x4A Laborant: muckel
|0x5A Laborant: Felicitus
|0x6A Laborant: Freestate
|-
|0x0B Laborant: echox
|0x1B Platinenmaterial
|0x2B Bauteilkästen
|0x3B Laborant: talynrae
|0x4B Laborant: muckel
|0x5B Laborant: DaFo
|0x6B Laborant: Jiska
|-
|0x0C Druckverschlussbeutel
|0x1C Laborant: Thst
|0x2C Malerzeug
|0x3C Bauteile
|0x4C Laborant: tabascoeye
|0x5C Laborant: Dafo
|0x6C Laborant: Jiska
|-
|0x0D Elektroinstallation
|0x1D Luftpolstertaschen (leer)
|0x2D Bauteile
|0x3D Laborant: BFritz
|0x4D Laborant: tabascoeye
|0x5D Laborant: DaFo
|0x6D Laborant: rami
|-
|0x0E Steckernetzteile
|0x1E Lichtsteuerung
|0x2E Infrastruktur/NOC
|0x3E Dübel und Schrauben
|0x4E Laborant: doozer
|0x5E Laborant: kite
|0x6E Laborant: rami
|-
|0x0F USB-Netzteile / E-Zigaretten
|0x1F Resr
|0x2F Druckerzubehör / Laminiergerät
|0x3F Infrastruktur / Festplatten
|0x4F Laborant: mxf
|0x5F Laborant: Unicorn
|0x6F Laborant: Unicorn
|-
|0x0G Elektroinstallation
|0x1G Netzwerkkabel
|0x2G Telefone
|0x3G Laborant: Anna
|0x4G Laborant: mxf
|0x5G Laborant: Unicorn
|0x6G defekt
|-
|}

=== Tardis2 ===

* im Fablab
* 17Schubladen hoch, 4 Schubladen breit
* ohne Beleuchtung
* die Schubladen mit Klebeband-Stücken vorne drauf müssen noch ausgewaschen werden
* sollte für Projekte und Fablab-Material vorbehalten bleiben

{| class="wikitable"
|0x70 '''free'''
|0x80 '''free'''
|0x90 '''free'''
|0xA0 '''free'''
|-
|0x71 '''free'''
|0x81 '''free'''
|0x91 '''free'''
|0xA1 '''free'''
|-
|0x72 '''free'''
|0x82 '''free'''
|0x92 '''free'''
|0xA2 Kinder-Farben
|-
|0x73 Netzteil
|0x83 Holz-Lager
|0x93 Holz-Reste
|0xA3 Pinsel & Farben
|-
|0x74 Walsonde
|0x84 Holzponies
|0x94 Holzponies
|0xA4 leer
|-
|0x75 E-Bauteile
|0x85 Bausätze BS0001
|0x95 Bausätze BS0005
|0xA5 Bausätze BS0009
|-
|0x76 Stempel
|0x86 Bausätze BS0002
|0x96 Bausätze BS0006
|0xA6 Bausätze BS0010
|-
|0x77 Magnetkartenleser/-schreiber
|0x68 Bausätze BS0003
|0x97 Bausätze BS0007
|0xA7 Bausätze BS0011
|-
|0x78 Laborant: zero_dtime
|0x88 Bausätze BS0004
|0x98 Bausätze BS0008
|0xA8 Bausätze BS0012
|-
|0x79 Elektroinstallation
|0x89 Kartendrucker
|0x99 19" Harware / Dafo / Felicitus
|0xA9 Torrorists
|-
|0x7A Kabel / KVM-Switches
|0x8A SDR / HackRF
|0x9A Winkel / Haken / Mech. Bauteile
|0xAA Schneidplotter
|-
|0x7B Adapter
|0x8B Fnordcordia
|0x9B Lochbohrer
|0xAB Ultimaker
|-
|0x7C Türschließer
|0x8C '''free'''
|0x9C MRMCD
|0xAC Ultimaker
|-
|0x7D '''free'''
|0x8D Agenda Diplom
|0x9D Stickbedarf
|0xAD Stoffkrams
|-
|0x7E Laborant: naddie
|0x8E Stickrahmen
|0x9E Stickbedarf
|0xAE Stickbeispiele
|-
|0x7F '''free'''
|0x8F Stickrahmen
|0x9F Stoff (?)
|0xAF Stickzubehör
|-
|0x7G '''free'''
|0x8G Aufnäher Trägerstoffe
|0x9G Folie (?)
|0xAG Schubladenteile (kunststoff+Schrauben; die Blechteile sind im Textillager)
|-
|}