Das ffmpeg-Paket einiger Linux-Distributionen (u.a. OpenSuse) enthält keinen Support für x264. Das Programm ffmpeg kann Videos somit nicht ins h264-Format bringen (encoding). Um ffmpeg mit x264-Unterstützung zu haben, muss man beide Pakete selbst kompilieren.

x264

Zunächst muss man die Quellen herunterladen:

git clone https://code.videolan.org/videolan/x264.git

Danach muss x246 gebaut werden:

./configure --enable-shared; make; make install

Das Programm und die Bibliothek werden unter /usr/local installiert.

FFMpeg

Nun kann ffmpeg heruntergeladen, konfiguriert (inkl. x264-Support), gebaut und installiert werden:

• git clone git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg
• ./configure --enable-gpl --enable-libx264
• make
• make install

Testen

Nach der Installation (unter /usr/local/) können die Unterstützten Codecs gelistet werden:

/usr/local/bin/ffmpeg -codecs

Dabei sollte h264 gelistet sein:

DEV.LS h264 H.264 ... (encoders: libx264 libx264rgb h264_v4l2m2m

Diese Version von ffmpeg enthält deutlich mehr Codecs als die OpenSuse-Version und kann auch deutlich mehr Codecs für das Encoding nutzen.

Mitunter soll ältere Software nochmal zum Laufen gebracht werden. Gründe gibt es mindestens zwei: man will ältere Dokumente lesen und benötigt den entsprechenden Reader oder … „Just4Fun“ …man will nochmal ein altes Spiel von früher Spielen. Ich habe letzteres mit „Mamba“ probiert.

Benötigt wurde dafür Windows 3.11 und ich hatte ein Ubuntu 18.04.

Die Schritte in der Übersicht:

1. DosBox installieren
2. Laufwerk anlegen und einbinden
3. Windows 3.11 installieren
4. Mamba auf das Laufwerk auf und starten

…und nun die Details…

DosBox installieren

Unter Ubuntu reicht hier ein apt-get install dosbox. Danach muss ein Ordner für evtl. Konfigurationen und das Laufwerk angelegt werden: mkdir ~/.dosbox.

Laufwerk anlegen und einbinden

Für das Laufwerk (c:) muss ein Unterverzeichnis in ~/.dosbox und ein Konfiguration (~/.dosbox/dosbox.conf bzw. ~/.dosbox/dosbox-VERSION.conf) angelegt werden:

mkdir ~/.dosbox/drive_c

Die Datei ~/.dosbox/dosbox.conf muss folgenden Inhalt haben:

[autoexec]
mount c ~/.dosbox/drive_c

Windows 3.11 installieren

Zunächst muss man sich die Windows 3.11-Disketten besorgen. Ich hatte 8 Disketten-Images. Diese habe ich einzeln gemounten und in einen Installationsordner kopiert:

mkdir ~/.dosbox/drive_c/install
for i in `seq 1 8`; do
  sudo mount -o loop Disk0$i.img /mnt
  cp /mnt/* ~/.dosbox/drive_c/install
  sudo umount /mnt
done

Nun „dosbox“ starten und dort ins Laufwerk „c:“ und in den Ordner „c:/install“ wechseln. Jetzt kann mit „setup.exe“ die Win3.11-Installation beginnen.

Mamba auf das Laufwerk auf und starten

Zum Schluss wird Mamba in das Verzeichnis ~/.dosbox/drive_c kopiert. Nun Windows hochfahren, den File Manager öffnen und Mamba starten.

Linkliste

1. https://www.dosbox.com/
2. DosBox unter Ubuntu: https://wiki.ubuntuusers.de/DOSBox/
3. Mounten via Loop Device: https://de.wikipedia.org/wiki/Loop_device
4. Windows 3.11 im Internet suchen
5. Mamba

Die bisherigen Fileserver basieren meist auf SAN und NFS: Die Server haben mehrere ZPools über SAN und reichen die enthaltenen ZFS per NFS und Samba wieder raus. Sowohl die Größe als auch die Geschwindigkeit könnte natürlich immer gerne grösser und besser sein. Aus diesem Grund wurden 4 Maschinen beschafft und auf diesen soll nun ein verteiltes Dateisystem.

Details zu den 4 Maschinen:

1. Dell R730 mit 768GB RAM,6 x 8TB HDD, 2 x 120GB SSD, Perc H730P Mini
2. Dell R740 mit 768GB RAM,6 x 8TB HDD, 2 x 240GB SSD, Perc H740P Mini
3. 2 x Dell R740xd mit 768GB RAM,6 x 8TB HDD, 2 x 240GB SSD, Perc H740P Mini

Auf allen läuft ein Ubuntu 18.04.

Die SSD werden einzeln ans das Linux gegeben (nicht als Hardware-Raid) und dort unterteilt:

• 500MB (/boot)
• 30GB LVM mit 20GB root-fs (SW-Raid1 zwischen beiden SSDs)
• Rest wird als SW-Raid0 genutzt

Für die HDDs wurden folgende Konfigurationen getestet:

1. Hardware-Raid50 mit dem Perc und XFS
2. Software-Raid50 (md) und XFS
3. ZFS

Die SSD wurden auch als Cache verwenden. Bei XFS lag dazu ein LVM zwischen Raid und XFS.

Das HW-Raid brachte bei den Tests mit fio die besten Ergebnisse (Lesen(seq): 700-800MB/s; Schreiben(seq):  600-700MB/s). Zwischen den Maschinen gibt es teilw. große Unterschiede. Der Cache brachte nichts. der Cache war mit teilw. nur 400MB/s (Lesen) einfach zu langsam. Da der RAM größer als der SSD-Cache ist, ist der fehlende SSD-Cache in dieser Konfiguration zu verschmerzen.

Die Maschinen erhielten die Namen „dfs[1-4]“ (Distributed Filesystem).Auf allen Maschinen wurde dann die Pakete

• glusterfs-server
• glusterfs-client

installiert. Ein „glusterfs peer probe dfs2; glusterfs peer probe dfs3; glusterfs peer probe dfs4“ auf dfs1 und schon waren alle verbunden. Auf dfs wurde dann ein FS angelegt, gestartet und gemountet:

1. gluster volume create distributed dfs1:/home/tmp/glusterfs/brick/ dfs2:/home/tmp/glusterfs/brick/ dfs3:/home/tmp/glusterfs/brick/ dfs4:/home/tmp/glusterfs/brick/
2. gluster volume start distributed
3. root@dfs1> mount -t glusterfs dfs1:distributed /mnt

Ein Test mit fio lieferte folgendes Ergebnis:

• Seq-Read: ~200MB/s
• Rand-Read: ~300MB/s
• Seq-Write: ~125MB/s
• Rand-Write: ~317MB/s

Das Rand-Read besser ist, liegt vermutlich daran, dass durch das Seq-Rand die Daten bei der Quell-Maschine schon im RAM lagen und beim darauf folgendem Rand-Read schneller ausgeliefert werden konnten. Für die Unterschiede beim Schreiben habe ich noch keine Erklärung.

Die Test müssen auch nochmal in systematische Form durchgeführt werden (inkl. Wiederholungen). Es bleibt also spannend…

Um den reibungslosen Ablauf auf den Compute-Nodes sicher zu stellen, sollen cgroups verwendet werden. Die Nutzer sollen in Mitarbeiter & Studierende gruppiert werden, wobei jeder einzelne Nutzer eine eigene Untergruppe erhält. Der Mitarbeiter X soll also in die cgroup „staff/X„. Die einzelnen Nutzer können dann im Ressourcenverbrauch limitiert werden.

Obwohl systemd allerhand mitbringt, soll zunächst das Paket cgroups-tools zum Einsatz unter OpenSuse Leap 15 kommen:

• libcgroup1
• libcgroup-tools

Nach der Installation mit „rpm -i …“ stehen die Tools cgcreate, cgdelete etc zur Verfügung. Damit die Nutzer direkt nach dem Einloggen in die entsprechende Gruppe gepackt werden, wird pam_exec verwendet. Folgende Zeile wird in die Datei /etc/pam.d/common-session-pc hinzugefügt:

session optional pam_exec.so /PATH_TO/cgroups_pamlogin.sh

Der Pfad muss entsprechend angepasst werden. Das Skript cgroups_pamlogin.sh erzeugt nun beim Starten einer neuen Session (PAM_TYPE=open_session) die entsprechende Gruppe, wenn diese noch nicht vorhanden ist. Danach werden die entsprechenden Limits gesetzt ( 90% des Speichers und der CPU; 95% für die gesamte Gruppe). Zuletzt wird der PAM-Login-Prozess in die Gruppe verschoben, sodass alle folgenden Kind-Prozesse auch in dieser Gruppe sind:

• echo $$ >> /sys/fs/cgroup/memory/tasks
• echo $$ >> /sys/fs/cgroup/cpu/tasks

Die gesamte Konfiguration als tar.gz: pam_cgroups.tar.gz

Die ursprünglichen 2 Server kirk und zentrum wurden durch einen neuen Dell-Server (PowerEdge R330) ersetzt. Dieser übernimmt beide Namen, die IPs und sämtliche Dienste (Poolraum-Management):

• NTP
• DHCP/BOOTP/TFTP
• NFS (echip, /usr/local, /usr/local/adm)
• CUPS
• Statistiken (DNS,Mail)

Der Server ist mit 2x10GBit/s mit dem 21er Netz (PC-Pool) verbunden und mit einer 1GBit/s-Verbindung im 20er Subnetz.

Aus den Mitteln des CIP-Antrages 2017 wurden neue PCs für die Poolräume des Instituts beschafft. Insbesondere wurden die SUN-Rays und Shuttles durch PCs von Dell ersetzt. Genauere Information darüber, welche Rechner jetzt in den einzelnen Räumen stehen, gibt es hier.

Der Drucker „lpemu“ steht nun im Hardware-Pool (Raum 3.209) und ist damit auch außerhalb der Öffnungszeiten mit einer Zugangskarte nutzbar. Papier muss weiterhin selbst mitgebracht werden, wobei gelochtes Papier verboten ist!

Die Hardware des Servers gruenau.informatik.hu-berlin.de wurde ausgetauscht. Es handelt sich nun um ein Dell PowerEdge 2950 (8 Kerne, 16GB RAM), der den alten Dell PowerEdge 1850 ersetzt.

In den Poolräumen und auf den Gruenaus ist nun Matlab 2018b installiert. Die vorherige Version (R2018a) ist z.Z. noch unter „/usr/local/MATLAB/R2018a/“ verfügbar. Entfernt lässt sich Matlab über ssh starten:

ssh -X -C username@gruenau4

Matlab2018b enthält unter anderem einen Live Editor und Simulink.

Im RBG-Blog soll es Beiträge zu aktuellen Themen geben, die von den Technikern und Technikerinnen am Institut für Informatik genauer betrachtet werde.

Die umfasst z.B. neue Software (Betriebssysteme, Tools, …), Beispiel-Konfigurationen usw.