Geschichte/Server/top4: Unterschied zwischen den Versionen

Aus UUGRN
K (Sdk verschob die Seite UUGRN:Server/top4 nach Geschichte/Server/top4)
 
(2 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 3: Zeile 3:
{{Navigationsleiste Systeme}}
{{Navigationsleiste Systeme}}
__TOC__
__TOC__
== Server Forschung nach Rabe ==
'''2019-02-07 (~sdk) - Mail Setup'''
Mails (port 25) erreichen das Jail uug_mail und dort den sendmail daemon. Die sendmail konfiguration befindet sich in /etc/mail. UUGRN Mailadressen werden in /etc/mail/virtusertable.d/virtusertable_static gepflegt. Danach das Script /etc/mail/virtusertable.d/update.sh ausführen, welches die Einträge in /etc/mail aktualisiert.
Die Mails die an Listen geschickt werden, werden an den sendmail daemon in jail uug_lists weitergereich. Sendmail in uug_lists gibt die mails an procmail für den user "hyperm" weiter. User hyperm hat eine .procmailrc mit Regeln, die die Mail direkt durch hypermail pipen und ein Archiv HTML erzeugen und nach /data/www/lists.uugrn.org/htdocs/uugrn/ schiebt.
Das führt dazu, dass es KEINE mbox oder Maildir von den Mails gibt. Das HTML Archiv ist damit die primäre Ablage und kann nicht neu generiert werden!
'''2018-10-22 (~sdk) - Noch mehr Server'''
Ich habe beim rumspielen entdeckt, dass das stadtwiki (ist das == rhein-neckar-wiki?) auf stwserv3.stwserv.de läuft. Dort kommt man von top aus drauf.
Dann gibts noch srv01.sigsys.de, worauf wir aber zur Zeit (afaik) keinen Zugriff haben.
Wir sollen vielleicht gemeinsam mit dwalin mal den domain block durchgehen und uns anschauen welche Domains über die uugrn/rabe Infrastruktur versorgt werden.
IP Block:
http://ipv4info.com/domains-in-block/s3cc070/164.177.168.0-164.177.175.255.html
'''2018-10-22 (~sdk) - Admin ML'''
Es gibt nun eine admin Mailing Liste: http://mailman.uugrn.org/mailman/listinfo/admin
Hmm, ich stelle grade fest, das dort auch alle cron jobs hin reporten. Will man das?
----
'''2018-10-22 (~sdk) - Offsite Backup? Wanted? Traffic?'''
Weiß jemand ob es für Top ein Offsite Backup gibt? Ich bin mir ziemlich sicher, dass top seine Daten nirgends hin pusht. Ob eine andere Maschine die Backups pullt kann ich nicht nachvollziehen.
----
'''2018-10-21 (~sdk) -  Platte voll wegen Backup... was tun?'''
Wir haben aktuell das Problem, dass auf top immer mal wieder die Platte voll läuft und viele Dienste und Jails dann nicht mehr ordnungsgemäß arbeiten.
Täglich läuft ein cronjob, der das script <code>/root/bin/zfs_backup3.sh</code> ausführt. Dieses Script erzeugt Snapshots und sichert diese zusätzlich in <code>/data/backup/uugrn.org/</code>.
Ich verstehe nicht, warum Snapshots zusätzlich nach <code>/data/backup/uugrn.org</code> gesichert werden, da dieses Verzeichnis auf dem selben Festplattenverbund liegt.
Mein Vorschlag wäre dieses selbstgebastelte Konzept gegen <code>zfs-auto-snapshot</code> auszutauschen.
Vorschlag für einen crontab Eintrag für <code>zfs-auto-snapshot</code>:
<pre>
15,30,45 *  *  *  *  root  /usr/local/sbin/zfs-auto-snapshot frequent 3
0        *  *  *  *  root  /usr/local/sbin/zfs-auto-snapshot hourly  24
7        0  *  *  *  root  /usr/local/sbin/zfs-auto-snapshot daily    7
14      0  *  *  7  root  /usr/local/sbin/zfs-auto-snapshot weekly  4
28      0  1  *  *  root  /usr/local/sbin/zfs-auto-snapshot monthly  12
</pre>
`zfs-auto-snapshot` managed darufhin die snapshots auf dataset ebene und kann pro dataset an und abgeschaltet werden (über ein zfs attribut). Die Zahl rechts neben hourly/daily/weekly etc. gibt an wie viele des entsprechdenen Snapshot-Typs erhalten bleiben sollen.
Auf eine zusätzliche, zweite Sicherung der Snapshots würde ich verzichten.
Mit diesem Konzept steigt die Speicherlast nicht sprungartig an, sondern lediglich Speicher gelöschter Dateien wird erst 12 Monate später frei gegeben. Ggf. können wir das auf 6 Monate reduzieren.
Wissen die Mitglieder eigentlich, dass sie Zugriff auf die Snapshots über das versteckte Verzeichnis <code>/.zfs</code> haben?
----
== -------------- ==


== Hardware ==
== Hardware ==

Aktuelle Version vom 9. April 2022, 14:46 Uhr

top4.uugrn.org ist der aktuelle (neue) Vereinsserver von UUGRN e.V. Es handelt sich um einen Mietserver.

[ Verein: Server: • top4 • higgsBeta ]
[ Vereinsjails: mail • mx1 • mysql • lists • wiki • blogs • pad • proxy • uugrn • shell • irc • bnc • news • ftp • fbsd9 • gitAlpha • calendarAlpha ]
[ Mitglieder-Jails: shell • mile • rabe • trickster • che • friedel • shl • hdi • ltrn ]

Hardware[Bearbeiten]

CPU
Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz (3300.12-MHz K8-class CPU)
RAM
16GB
HDD
ada0: <WDC WD10JFCX-68N6GN0 82.00A82> ATA-9 SATA 3.x device / Serial Number WD-WXN1EC4CK0LC
ada1: <WDC WD10JFCX-68N6GN0 82.00A82> ATA-9 SATA 3.x device / Serial Number WD-WXN1EC4E8PPE
ada2: <KINGSTON SH103S3120G 580ABBF0> ATA-8 SATA 3.x device / Serial Number 50026B725206BAE7
ada3: <TOSHIBA THNSNJ128GCSU JURA0101> ATA-9 SATA 3.x device / Serial Number 45PS10BQTB3W
Die Storage-Devices sind Eigentum von UUGRN e.V., der Server drumherum ein Mietserver von TWX

OS[Bearbeiten]

Jails[Bearbeiten]

Es werden Jails gehostet Details unter /Jailkonzept.

Storage Konzept[Bearbeiten]

Der Server verfügt über 2x2.5" Platten zu je 1TB (953869MB), die als bootfähiger zpool (mirror) namens "zroot" betrieben werden. Zusätzlich existieren 2 unterschiedliche SSDs, die für SWAP, ZIL(mirror) und L2ARC verwendet werden.

Mehr unter /Storagekonzept.

Ausblick[Bearbeiten]

Aufgrund der Verfügbarkeit der erforderlichen CPU-Features für Virtualisierung soll bhyve[1] getestet werden. Die erforderlichen Komponenten werden durch das OS bereits mitgeliefert[2]. Mit Hilfe von bhyve können alternative Betriebssysteme betrieben werden, z.B. OpenBSD oder Linux[3]

Details[Bearbeiten]

Geschichte[Bearbeiten]

2015-07-01
Nachdem die Mitgliederversammlung die Server-Modernisierung beschlossen hat, wurde für den Migrationszeitrraum ein 2. Mietserver beauftragt. Dieser befindet sich im gleichen VLAN wie der vorige Vereinsserver und ermöglichst so die sukzessive Übernahme der Jails. Nach der Migration der Jails und Services von top3offline auf top4 werden die Platten aus top4 wieder in die HW von top3 übernommen, der zusätzliche Mietserver besteht also nur zum Zwecke der Migration. Der Server wird dann als "top4.uugrn.org" weiter betrieben.

Administratives[Bearbeiten]

Quellen, Weblinks[Bearbeiten]

  1. ↑ Offizielle Webpräsenz „bhyve”
  2. ↑ FreeBSD Handbook: 22.4. FreeBSD as a Host with bhyve
  3. ↑ bhyve FAQ: Q: What VM operating systems does bhyve support?
Abgerufen von „https://wiki.uugrn.org/index.php?title=Geschichte/Server/top4&oldid=13464“