Nobreakspace
Ausstattung
Dienste
Chaotikum
Nobreakspace
Ausstattung
Dienste
Chaotikum
Dies ist eine alte Version des Dokuments!
Case ist der Server im Rack. Auf diesem läuft ein Proxmox zur Verwaltung der VMs. Grundsätzlich können Mitglieder mit Chaotikum-Account Zugriff erhalten um eigene VMs zu erstellen. Dazu ist es notwendig den Chaotikum-Account einmal von einem Admin freischalten zu lassen.
Das Webinterface ist unter https://case.nobreakspace.org:8006 verfügbar.
Laufende VMs
Derzeit nicht laufende VMs
Auf case wird Open vSwitch eingesetzt. Deswegen findest du vermutlich nicht direkt alle Interfaces so, wie du es erwarten würdest. Hier findest du einen Cheat Sheet zu Open vSwitch.
Folgende Menschen haben administrativen Zugang:
Auf dem Proxmox wird LDAP unter Datacenter → Permissions → Authentication → ldap konfiguriert.
Das findet sich unter Datacenter → Permissions → Realms. Dort muss man auch auf sync klicken sobald sich was ändert. Proxmox kann das leider noch nicht online.
Derzeit:
Unter „Sync Options“ steht die Gruppe in welcher sich alle User befinden müüssen (freigeschaltet) und in der anderen UI
Wenn man die Fehlermeldung „user name is too short (500)“ erhält, liegt das daran, dass man nicht als Root eingeloggt ist. Das ist ja auch klar ersichtlich. Muss man selbst drauf kommen…
Das Servermainboard besitzt ein Managementinterface. Dieses ist unter https://172.23.208.4 erreichbar. Dort ist u.a. eine virtuelle Konsole erreichbar, sodass man keinen Monitor anschließen muss um beispielsweise das System eines Tages neu zu installieren.
Um das Managementinterface zu erreichen, ist es aktuell nötig auf dem Switch Port 45 aus der Link Aggregation zu entfernen, da es sich den Port mit dem Server teilt.
Port | Verbunden mit | Funktion |
---|---|---|
p0 | Switch | Uplink |
p1 | (frei) | |
p2 | (frei) | |
p3 | (frei) |
Produktive
Dashboards | Dashboards Verantwortung ? Container ? W. Ports keine OS ? Server case Zustand Produktiv |
IceBox | IceBox Verantwortung TVLuke Container icbox? W. Ports keine OS docker mischmasch Server case moby Zustand |
Kubernetes Cluster im nbsp | Kubernetes Cluster im nbsp Zwei Container auf case: * kubernetes-master (verwaltet den Cluster) * kubernetes01 (Worker node) Storage: Storage wird erstmal als Local Persistent Volume umgesetzt: <https://kubernetes.io/blog/2019/04/04/kubernetes-1.14-local-persistent-volumes-ga/> container case productive |
nbspeventbot | nbspeventbot Verantwortung Malte Container nbspeventbot W. Ports keine OS OpenJDK 12 Docker Base Image Server moby Zustand Produktiv |
nbspstatus | nbspstatus Verantwortung Malte Container nbspstatus W. Ports keine OS Debian 11.9 Server case Zustand Produktiv |
Sound-Setup | Sound-Setup Verantwortung Paul Container docker container auf moby02 W. Ports keine OS docker Server case Zustand Produktiv |
Im Test
Space Automation | Space Automation Verantwortung ? Container ? W. Ports keine OS ? Server case Zustand Testing |
Deaktiviert
tuerstatus | tuerstatus Verantwortung ? Container tuerstatus W. Ports keine OS ? Server case Zustand Produktiv |
alter Namingscheme
Die Lüfter können mittels IPMI gesteuert werden:
# CPU FAN1 FAN2 ipmitool raw 0x3a 0x01 0x00 0x00 0x00 0x00 0x01 0x01 0x00 0x00 /etc/systemd/system/luefter.service [Unit] Description=Lüftergewschwindigkeit der Gehäuselüfter reduzieren [Service] ExecStart=/usr/bin/ipmitool raw 0x3a 0x01 0x00 0x00 0x00 0x00 0x01 0x01 0x00 0x00 Type=oneshot [Install] WantedBy=multi-user.target
Slot (von links) | Festplatte | Model | Status | Eingebaut | Ausgebaut | Kommentar |
---|---|---|---|---|---|---|
ZDH449L8 | ST4000VN008-2DR166 | defekt | 2018 | 2021-07-19 | ||
1 | ZDH41SG0 | ST4000VN008-2DR166 | ok in-use | 2018 | ||
ZDH40YJH | ST4000VN008-2DR166 | defekt | 2018 | 2021-07-14 | ||
ZGY9B6GJ | ST4000VN008-2DR166 | defekt | 2021-07-19 | 2023-01-25 | ||
4 | ZGY9B5C5 | ST4000VN008-2DR166 | ok in-use | 2021-07-14 | ||
3 | ZDHBM8P5 | ST4000VN008-2DR166 | ok in-use | 2023-01-25 | ||
im Regal | ZDHBM9WF | ST4000VN008-2DR166 | spare | |||
im Regal | ZGY91K0L | ST4000VN008 | spare | für ZGY9B6GJ erhalten |
Die neue Festplatte wurde als /dev/sdd erkannt. Ich habe folgende Befehle ausgeführt:
Als erstes kopieren wir die Partitionstabelle mithilfe von sgdisk von der defekten auf die neue Festplatte. Als Quelle eignet sich jede Platte im RAID.
# zpool status pool: rpool state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://zfsonlinux.org/msg/ZFS-8000-9P scan: scrub repaired 20K in 0 days 11:08:47 with 0 errors on Mon Jul 12 23:00:44 2021 config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 ata-ST4000VN008-2DR166_ZDH40YJH-part3 ONLINE 0 0 2 ata-ST4000VN008-2DR166_ZDH449L8-part3 ONLINE 0 0 3 ata-ST4000VN008-2DR166_ZDH41SG0-part3 ONLINE 0 0 0 errors: No known data errors # sgdisk -R /dev/sdd /dev/disk/by-id/ata-ST4000VN008-2DR166_ZDH449L8 The operation has completed successfully. # sgdisk -G /dev/sdd The operation has completed successfully.
Nun schauen wir nach Model und Seriennummer der neuen Festplatte und verwenden dies für die weiteren Befehle.
# hdparm -I /dev/sdd /dev/sdd: ATA device, with non-removable media Model Number: ST4000VN008-2DR166 Serial Number: ZGY9B5C5 [...]
Nun kopieren wir die Boot- und die EFI-Partition von der defekten (oder eine der anderen Platten) auf die neue:
# dd if=/dev/disk/by-id/ata-ST4000VN008-2DR166_ZDH449L8-part1 of=/dev/disk/by-id/ata-ST4000VN008-2DR166_ZGY9B5C5-part1 2014+0 records in 2014+0 records out 1031168 bytes (1.0 MB, 1007 KiB) copied, 0.103471 s, 10.0 MB/s # dd if=/dev/disk/by-id/ata-ST4000VN008-2DR166_ZDH449L8-part2 of=/dev/disk/by-id/ata-ST4000VN008-2DR166_ZGY9B5C5-part2 1048576+0 records in 1048576+0 records out 536870912 bytes (537 MB, 512 MiB) copied, 15.9042 s, 33.8 MB/s
Anschließend weisen wir ZFS an die defekte Platte durch die neue zu ersetzen. Dieser Befehl ist am kritischsten. Achtet bitte ganz genau auf die Syntax:
usage: replace [-f] [-o property=value] <pool> <device> [new-device]
Unser Pool heißt rpool
. Das device
, das wir ersetzen wollen, ist in unserem Fall ata-ST4000VN008-2DR166_ZDH449L8-part3
und das new-device
heißt (konstruiert aus der Ausgabe von hdparm) ata-ST4000VN008-2DR166_ZGY9B5C5-part3
.
Wir führen also folgendes aus und kontrollieren den Vorgang mit zpool status
.
# zpool replace rpool ata-ST4000VN008-2DR166_ZDH449L8-part3 ata-ST4000VN008-2DR166_ZGY9B5C5-part3 Make sure to wait until resilver is done before rebooting. # zpool status pool: rpool state: ONLINE status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scan: resilver in progress since Wed Jul 14 23:11:30 2021 28.1G scanned at 1.56G/s, 2.70G issued at 154M/s, 2.77T total 0B resilvered, 0.10% done, 0 days 05:14:19 to go config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 ata-ST4000VN008-2DR166_ZDH40YJH-part3 ONLINE 0 0 2 replacing-1 ONLINE 0 0 0 ata-ST4000VN008-2DR166_ZDH449L8-part3 ONLINE 0 0 3 ata-ST4000VN008-2DR166_ZGY9B5C5-part3 ONLINE 0 0 0 ata-ST4000VN008-2DR166_ZDH41SG0-part3 ONLINE 0 0 0 errors: No known data errors
Jetzt warten wir ein paar Stunden. Anschließend kann die alte Festplatte ausgebaut werden.