Author Archives: ralph
Tomcat9 auf Ubuntu 18.4
https://www.digitalocean.com/community/tutorials/install-tomcat-9-ubuntu-1804
Dualboot System mit Ubuntu und Windows – Zeit nicht korrekt
Auf meinen Dualboot-System ist Ubuntu und Windows installiert.
Die beiden Betriebssysteme interpretieren die Hardware-Clock nicht gleich. Linux interpretiert die Hardware-Clock als UTC. Windows aber als “Local-Time”. Daraus resultiert, dass in dem einen Betriebssystem die Zeit korrekt gesetzt wird und im anderen falsch angezeigt wird.
Ich korrigiere dies, indem ich Ubuntu beibringe die Local-Zime zu verwenden:
- Im Bios die HW-Clock auf die aktuelle Local-Zeit einstellen
- Dann im Linux die Local-Zeit konfigurieren
1sudo timedatectl set-local-rtc 1
Man könnte dies auch so korrigieren, indem man Windows beibringt, die UTC zu verwenden. Aber umständlicher als die Korrektur über Linux.
Links
https://askubuntu.com/questions/169376/clock-time-is-off-on-dual-boot
Mailtest
Wenn man einen Mailserver für diverse Domains betreibt, möchte man nach Erstellung einer neuen Domain überprüfen, ob alles (Mailserver, DNS, etc.) auch korrekt konfiguriert ist und Mails von der neuen Domäne nicht irgendwo von einen Spam-Filter o.ä. abgefangen werden. Dafür gibt es ein tolles Web-Tool:
Hier kann man sich einen Mail-Empfänger generieren lassen, auf welchen dann ein Mail von der zu überprüfenden Mail-Adresse gesendet werden kann. Das Web-Tool listet dann den Score auf und zeigt was verbessert werden kann.
WordPress “Nativ-Installation” nach Docker Container umziehen
Nachdem ich nun meine WordPress Docker Container am laufen habe, ist es an der Zeit meine alten WordPress-Installationen umzuziehen. Der Use-Case ist simple:
- Die WordPress-Installation, welche bisher “nativ” auf www.meinedomäne.ch lief soll nun neu vom neu erstellen Docker-Container beliefert werden.
Das Umziehen einer bestehenden WordPress-Installation war kniffliger als erwartet. Auf diesem Wege hat es dann für mich funktioniert:
- Als Erstes einen Docker-Container erstellen. Siehe hier. Wichtig war, dass der Container erst ohne die SSL-Erweiterung (inkl. wp–init.sh und apache2–vhosts.conf) gestartet wurde.
- Das so erstellte Image ist nun über http://lokaleIp:port erreichbar.
- Nun die Installations-Routine von WordPress durchlaufen.
- Nun auf der WordPress-Installation, welche umgezogen werden soll, das Plugin “All-in-One WP Migration” installieren und damit die WordPress-Export (in ein File) erstellen.
- Nun wieder auf die Docker-Wordpress Installation wechseln, auch hier das Plugin “All-in-One WP Migration” installieren und anschliessend einen WordPress-Import aus dem erstellten File durchführen.
- Damit sollte der Umzug schon erledigt sein.
- Ich habe dann noch das Plugin “SSL Insecure Content Fixer” installiert um sicherzustellen, dass die noch folgende SSL-Aktivierung sicher funktioniert => Das ist evtl. aber gar nicht nötig…
- Nun Kann die Docker-Instanz gestoppt und wp–init.sh und apache2–vhosts.conf im yml-File aktiviert werden. Anschliessend die Docker-Instanz wieder starten:
123docker-compose down--- Änderung an yml-File vornehmen (wp-init.sh und apache2-vhosts.conf) ----docker-compose up -dDamit ist nun auch SSL aktiviert, so dass der Docker-Container über SSL die Seite ausliefert.
Photon 3.0 auf ESXi 5.5
Photon 3.0 installieren
- Photon kann unter https://vmware.github.io/photon/ heruntergeladen werden. Ich habe mich für die ISO-Install Variante entschieden.
- Bei der Installation kann nach dem Guide vorgegangen werden: https://vmware.github.io/photon/assets/files/html/1.0-2.0/Running-Photon-OS-on-vSphere.html
Netzwerk einrichten
|
1 |
vi /etc/systemd/network/99-dhcp-en.network |
Das File updaten
|
1 2 3 4 5 6 7 8 |
[Match] Name=e* [Network] Address=x.x.x.x/xx Gateway=x.x.x.x DNS=x.x.x.x Domains=name |
Nach dem anschliessend Reboot sollte das Netzwerk erreichbar sein
|
1 |
reboot |
root-login auf ssh erlauben
Natürlich ist es keine gute Idee, den root-User auf SSH zu erlauben. Damit man aber einigermassen angenehem die Konfigurationen vornehmen kann (über die ssh Konsole), wird dieser aktiviert. Sobald weitere User eingereichtet sind, kann der root-access wieder eingeschränkt werden.
Damit man sich als root per ssh einloggen kann muss man das File
|
1 |
vi /etc/ssh/sshd_config |
editieren:
|
1 |
PermitRootLogin yes |
Anschliessend den Service restarten
|
1 |
systemctl restart sshd |
Root Passwort ändern
Beim Installieren von Photon gebe ich ein einfaches Passwort ein, weil die locale (Tastatur-Layout) nicht wirklich für Deutsch funktioniert. Anschliessen, sobald über SSH connected werden kann, setze ich ein stärkeres Passwort:
|
1 |
passwd |
Upgrade PhotonOS
PhotonOS upgraden
|
1 |
tdnf distro-sync |
Docker aktivieren
|
1 |
systemctl enable docker |
Neuer User erstellen
Nun werden neue User erstellt.
|
1 2 3 |
useradd -m -U username passwd username usermod -aG docker username |
Anschliessend rebooten
|
1 |
reboot |
Ab sofort kann man sich mit dem neue erstellen User per SSH einloggen.
Root-User Rechter erhält man ab sofort mit
|
1 |
su - |
Docker Compose installieren
Nun wird Docker Compose installiert. Bitte darauf achten, dass die neueste Version installiert wird.
Siehe auch https://github.com/docker/compose/releases/
|
1 2 3 4 5 |
su - curl -L https://github.com/docker/compose/releases/download/1.23.1/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose chmod +x /usr/local/bin/docker-compose chgrp docker /usr/local/bin/docker-compose exit |
Root wieder deaktivieren
Nun kann das Root-Login über SSH wenn gewünscht wieder deaktiviert werden.
|
1 |
vi /etc/ssh/sshd_config |
|
1 |
PermitRootLogin yes |
|
1 |
systemctl restart sshd |
Ubuntu 18.4: Default Klang-Wiedergabegerät setzen
Mein Ubuntu setzt nach einem Reboot immer das falsche Klang-Wiedergabegerät. Das Default Wiedergabegerät kann folgendermassen gesetzt werden, so dass es auch nach einem Reboot noch gesetzt ist:
Als erstes die vorhandenen Wiedergabegeräte auflisten:
|
1 |
pacmd list-sinks |
Dies listet die “Indexe” der Wiedergabegeräte auf. Der mit * markierte Index ist das aktuell als Default gesetzte Wiedergabegerät.
Nun den Index des gewünschten Default Wiedergabegerätes merken (bei mir ist es die “2”) und eintragen in
|
1 |
sudo vi /etc/pulse/default.pa |
|
1 2 |
### Make some devices default set-default-sink 2 |
Nach einem Reboot ist das Wiedergabegerät Nr. 2 automatisch gesetzt.
Links
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/DefaultDevice/
WordPress Container auf Docker
Dieser Blog-Eintrag beschreibt, wie man auf WordPress auf einem Docker-Host installieren und damit mehrere WordPress-Instanzen auf einem Host betreiben kann.
Ich betreibe die Docker-Container hinter einem Proxy-Server, der aber nicht als Container läuft. Der Proxy-Server leitet die HTTPS-Requests an die entsprechenden Docker-Container weiter.
Dieser Beitrag setzt ein vorinstalliertes Photon 3.0 inkl. Docker und Docker-Compose voraus. Siehe hier.
Die Docker-Container können über diverse Befehle gemanaged werden. Siehe dazu eine kleine Übersicht hier.
WordPress installieren
Wir installieren WordPress mit Hilfe von Docker Compose. Dazu erstellen wir ein template:
|
1 2 3 |
mkdir wordpress cd wordpress vi docker-compose.yml |
Im yml-Script erstellen wir eine WordPress- inkl. DB-Instanz.
WordPress-Instanz
- Die WordPress-Instanz hat eine Abhängigkeit zur DB.
- Die WordPress-Files werden unter /var/www/html abgelegt
- der Host-Port 80 wird zur wordpress-Instanz port 80 weitergeleitet (“80:80”)
- Die DB ist über Port 3306 anzusprechen (WORDPRESS_DB_HOST: db:3306)
- Der DB-User ist wordpress (WORDPRESS_DB_USER: wordpress)
- Das DB-Passowort ist zu setzen: WORDPRESS_DB_PASSWORD: <wordpress_db_password>
DB-Instanz
- Die DB-Files werden hier abgelegt: db_data:/var/lib/mysql
- Passort setzen: MYSQL_ROOT_PASSWORD: <mysql root password>
- Datenbank definieren: MYSQL_DATABASE: wordpress
- User definieren: MYSQL_USER <wordpress>
- DB-Passwort setzen: MYSQL_PASSWORD: (wordpress db password)
Die letzten beiden Linien restellen lokale Verzeichnisse auf dem Photon-Host. Hier werden die WordPress- und SQL-Files abgespeichert. Diese Files überleben somit, wenn der container zerstört und neu generiert wird.
Die Volumes werden unter
|
1 |
cd /var/lib/docker/volumes |
erstellt und bleiben bestehen. Dies solange bis die Volumes mittels
|
1 |
docker-compose down -v |
zerstört werden.
WordPress Container starten
Nun kann der Container einfach gestartet werden. Dank Docker Compose braucht man nur noch einen Befehl. Docker Compose erkennt automatisch das YAML im aktuellen Verzeichnis, durchläuft die Konfiguration und startet die Container-Anwendung:
|
1 |
docker-compose up -d |
Den Prozess kann man anzeigen lassen
|
1 |
docker ps |
Nun ist über http://<ip>:8080 auf die WordPress-Instanz zugegriffen werden.
WordPress Container mit SSL erweitern
Das so bereitgestellte Container-Image bietet WordPress “out-of-the-Box” über Port 80 an. Port 443 ist nicht aktiviert. Man geht dabei davon aus, dass die Verschlüsselung (https) eine zusätzliche, neue Funktion darstellt und damit über einen weiteren Container abzubilden ist. Dazu kann ein Proxy-Container aufgebaut werden, für den es auch bereits fertige Docker-Images gibt. Architektonisch mag das Sinn machen.
Ich möchte das aber nicht so umsetzen. Ich betreibe bereits einen Proxy-Server und dieser soll auch so weiter beibehalten werden. Ich verzichte also auf einen Proxy-Container und erweitere das WordPress-Image durch die SSL-Funktionalität. Damit das geht, muss ich das docker-compose.yml bzw. die WordPress-Container Beschreibung erweitern.
Als erstes erstelle ich ein zusätzliches File
|
1 |
vi wordpress/wp-init.sh |
|
1 2 3 4 5 6 7 8 |
!/usr/bin/env bash apt-get update apt-get install -y --no-install-recommends ssl-cert rm -r /var/lib/apt/lists/* a2enmod ssl a2dissite 000-default.conf a2ensite apache2-vhosts.conf docker-entrypoint.sh apache2-foreground |
Dieses Bash-Script soll bei jedem Starten des Containers ausgeführt werden. Mittels diesem Script wird
– SSL nachinstalliert
– Die Default Konfig “000-default.conf” auf dem Apachen entfernt und stattdessen
– eine neue Konfig “apache2-vhosts.conf” installiert.
– Anschliessend wird der Apache neu gestartet.
Damit das Script funktioniert braucht es noch eine Apache-Config. Diese Config wird in den WordPress-Container gemappt und beim Container-Start aktiviert. Damit kann ich von ausserhalb des Containers, die Apache-Config manipulieren:
|
1 |
vi wordpress/apache2-vhosts.conf |
|
1 2 3 4 5 6 7 8 9 10 11 |
NameVirtualHost * <VirtualHost *:443> ServerName domain.ch DocumentRoot /var/www/html/ DirectoryIndex index.php Options -Indexes SSLEngine On SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key SSLCACertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem </VirtualHost> |
Nun ist das das docker-compose.yml zu erweitern (siehe die markierten Erweiterungen):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
version: '3.3' services: wordpress: depends_on: - db_node image: wordpress:latest volumes: - wordpress_files:/var/www/html - ./wp-init.sh:/usr/local/bin/apache2-custom.sh - ./apache2-vhosts.conf:/etc/apache2/sites-available/apache2-vhosts.conf ports: - "8080:80" - "8443:443" restart: always environment: WORDPRESS_DB_HOST: db_node:3306 WORDPRESS_DB_USER: wordpress WORDPRESS_DB_PASSWORD: (wordpress db password) container_name: wordpress_web command: "bash -c apache2-custom.sh" db_node: image: mysql:5.7 command: '--default-authentication-plugin=mysql_native_password' volumes: - db_data:/var/lib/mysql ports: - 6601:3306 restart: always environment: MYSQL_ROOT_PASSWORD: (wordpress root password) MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: (wordpress db password) container_name: wordpress_db volumes: wordpress_files: db_data: |
Wie man sieht wird
– das wp-init.sh Skript in den Container gemappt
– Die Apache-Config apache2-vhosts.conf in den Container gemappt.
– Der Container um den Port 8443 erweitert, der Container-Intern auf 443 routet und
– Das Commando “bash -c apache2-custom.sh” bei starten ausgeführt.
Damit startet der Container ab sofort mit aktiviertem SSL und der Apache-Container kann über das File apache2-vhosts.conf konfiguriert werden.
Reverse Proxy
Auf dem Reverse-Proxy wird nun einfach eine Reverse-Rule für den Container eingeführt. Der Reverse-Proxy leitet die HTTPS-Anfragen intern an den Container-Host mit Port 8443 weiter. Diese kann so aussehen:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
<VirtualHost serverIp:80> ServerAdmin info@domain.ch ServerName www.domain.ch ServerAlias domain.ch RewriteEngine on ReWriteCond %{SERVER_PORT} !^443$ RewriteRule ^/(.*) https://www.domain.ch/$1 [NC,R,L] </VirtualHost> <VirtualHost serverIp:443> ServerAdmin info@domain.ch ServerName www.domain.ch #aktiviert SSL Unterstuetzung SSLEngine On SSLProxyEngine on SSLProxyVerify none SSLProxyCheckPeerCN off SSLProxyCheckPeerName off SSLProxyCheckPeerExpire off SSLCertificateKeyFile /etc/letsencrypt/live/www.domain.ch/privkey.pem SSLCertificateFile /etc/letsencrypt/live/www.domain.ch/cert.pem SSLCertificateChainFile /etc/letsencrypt/live/www.domain.ch/chain.pem # Regeln zum umleiten auf den internen Server ProxyPreserveHost On ProxyRequests Off ProxyPass / https://www.domain.ch:8443/ ProxyPassReverse / https://www.domain.ch:8443/ RequestHeader unset Accept-Encoding ErrorLog /var/log/apache2/error.log # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn CustomLog /var/log/apache2/access.log combined ServerSignature On </VirtualHost> |
SMTP auf WordPress-Container
Ich betreibe einen eigenen Mailserver. Ich stellte rasch fest, dass WordPress keine Mails über diesen Server versenden kann. Dies, weil das WordPress-Image einerseits grundsätzlich keinen SMTP-Agent mit dabei hat und andererseits mein Mailserver auch nicht aus dem Container heraus erreichbar war:
- https://github.com/docker-library/php/issues/135
- https://github.com/docker-library/wordpress/issues/30
Um das Problem zu lösen habe ich mir einfach das Plugin “WP Mail SMTP” installiert. Dieses erweitert WordPress um die Mailfunktion. Das Connectivity-Problem konnte ich mit einer einfach Erweiterung von /etc/hosts lösen:
|
1 |
192.168.xx.xx mx.domain.ch |
Man beachte, dass ich die interne IP des Mailservers verwende.
Damit diese Erweiterung auch bei einem neuen Create des Containers übernommen wird, muss wordpress/wp-init.sh noch modifiziert werden:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
#!/usr/bin/env bash # modify /etc/hosts with mx.intelli.ch cat >> /etc/hosts <<-EOF /* mx.intelli.ch */ 192.168.xx.xx mx.domain.ch EOF apt-get update apt-get install -y --no-install-recommends ssl-cert # SSL rm -r /var/lib/apt/lists/* a2enmod ssl a2dissite 000-default.conf a2ensite apache2-vhosts.conf # finally execute default command docker-entrypoint.sh apache2-foreground |
Links
Hot-Backup von ESXi VMs
Um Backups von ESXi VMs im laufenden Zustand machen zu können, braucht es
- Verständnis was VmWare unter einem Snapshot versteht
- Das Scipt ghettoVCB.sh => ghettoVCB
Exkurs VMWare-Snapshot
Bei einem VMware Snapshot wird eine weitere Festplattendatei erstellt welche ab Zeitpunkt des Snapshots alle geänderten Blöcke aufnimmt. Gleichzeitig wird der Exklusiv Zugriff auf die Basis Festplatte aufgehoben so das andere Prozesse lesen koennen.
Dieses “lesen” kann ein Kopierbefehl einens Backupprogramms sein. Da keine Schreibzugriffe mehr in die Datei erfolgen ist der Zustand also konsistent. Snapshots sind also keine Backups. Ein Snapshot “friert” lediglich einen Zustand ein (Basis Festplatte) und schreibt alle ab diesem Zeitpunkt anfallenden Änderungen in eine neue Snapshot Datei (Delta).
- Die Basisplatte und der bzw. die Snapshots zusammen ergeben den akt. Stand. Fehlt ein Element in der Kette ist kein vollstaendiges Restore mehr moeglich. Beides muss zur gleichen Zeiten fuer den HOST zugaenglich sein.
- Snapshots wachsen bis zur max. konfigurierten Festplattengroesse heran. Die Groesse des Datastores ist also zu ueberwachen.
- Beim löeschen von mehr als 2 Snapshots ist zu bedenken das ein Helper angelegt wird und immer die Groesse der zusammen zufuehrenden Snaps benoetigt wird.
- Laufende Snaps kosten ein wenig Performance. Die Gefahr von Fragmentierierung ignorieren wir da die Snaps immer in 16MB Bloecken wachsen.
- Grosse Snaps loeschen, hier versteht VMware das einpflegen der Aenderungen, dauert lange
Beispiel:
- Basisplatte
- Snapshot1
- Snapshot2
- Snapshot3
- Snapshotx
Löscht man jetzt Snapshotx wird dieser (und damit alle davorigen Snapshots) in die Basisplatte eingepflegt.
Löscht man Snapshot2 wird dessen Zustand und der von Snapshot1 in die Basisplatte eingepflegt und Snapshot3 usw. werden zu Snapshot1 usw,
Die .VMDK-Files (Virtuell Maschine Disk Files) können im laufenden Betrieb nicht kopiert oder verschoben werden, da sie ja in Gebrauch sind. Dies sieht aber nach einem Snapshot anders aus. Bei einem Snapshot werden die .VMDK-Files im Prinzip gekappt und neue Files (VMSN und VMSD) angelegt, in welche die kompletten Änderungen des Snapshots geschrieben werden. Wenn man ein Snapshot der VM macht, wird die Basis-Festplatte in den Read-Only Modus gesetzt, wordurch diese nun, da konsisten, kopiert werden kann. Das Verhalten von Snapshots kann also ausgenutzt werden um Backups im laufenden System erstellen zu können (Hilfsmittel zum Backup):
Komplettbackup 1
- Das Konfigurations-File der VM sichern/kopieren (VMX-File)-> nach dem Snaphsot der vituellen Maschine ändern sich die Verweise in der Konfiguration.
- Man erstellt einen ersten Snapshot einer VM. Es bestehen anonsten keine Snapshots dieser VM. Der Snapshot wird also gemacht, und die Basis-Festplatte kopiert. Anschliessend den Snapshot wieder loeschen. Dieses Vorgehen benötigt entsprechend viel Platz, wenn mehrere Backups der gleichen VM notwendig sind.
Komplettbackup 2
- Man macht täglich einen Snapshot und sicherst den Snapshot des Vortages. Bedeutet weniger Platz da quasi nur Aenderungen dann noch anfallen. Aber ein Restore erfordert Knowhow und dein ESX wird mehr belastet.
Soweit der Exkurs… Um ein Backup zu erstellen, können wir das mit den Snapshots manuell machen oder aber mit dem ghettoVCB-Script arbeiten. Das macht nämlich genau das oben beschriebene.
Installation von ghettoVCB
Die Installation ist simple. Einfach ein Verzeichnis auf dem ESXi-Datastore erstellen und die ghettoVCB-Scripts hineinkopieren. Das wird ganz schön auf Youtube gezeigt: http://www.youtube.com/watch?v=mVrjxzKEEu4
ghettoVCB konfigurieren und Backup durchführen
Die Konfigurationsmölgichkeiten findet man hier: http://communities.vmware.com/docs/DOC-8760
ghettoVCB.conf File
Ich habe mein ghettoVCB.conf File folgendermassen konfiguriert (ist eingentlich alles Standard):
|
1 2 3 4 5 6 7 8 9 10 11 |
VM_BACKUP_VOLUME=/vmfs/volumes/65d7a6db-6bc8d65a/VmBackups DISK_BACKUP_FORMAT=thin VM_BACKUP_ROTATION_COUNT=1 POWER_VM_DOWN_BEFORE_BACKUP=0 ENABLE_HARD_POWER_OFF=0 ITER_TO_WAIT_SHUTDOWN=3 POWER_DOWN_TIMEOUT=5 ENABLE_COMPRESSION=0 VM_SNAPSHOT_MEMORY=0 VM_SNAPSHOT_QUIESCE=0 SNAPSHOT_TIMEOUT=15 |
VMs zum Backup
Habe ein File “vms_to_backup” erstellt, welches eine Liste der Namen der VMs beinhaltet. Bei den Namen handelt es sich um die Namen, welche auch im vSphereClient angezeigt werden:
|
1 |
TestVM32Bit |
Backup run
Nun kann die VM im laufenden Zustand gebackuped werden (Option -d dryrun führt einen Testlauf durch):
|
1 |
./ghettoVCB.sh -f vms_to_backup -g ./ghettoVCB.conf -d dryrun |
Backup automatisch durchführen (Cron-Tab)
Um das Backup automatisch durchzuführen, kann dies in der Cron-Tab von ESXi konfiguriert werden:
In Crontab registrieren, Job soll jeden Donnerstag um 17:00 Uhr durchgeführt werden
|
1 |
echo "0 17 * * 4 /vmfs/volumes/4a6bb65f-eb654b7b-2525-d8d385ab5bd2/ghettoVCB/ghettoVCB.sh -f /vmfs/volumes/4a6bb65f-eb654b7b-2525-d8d385ab5bd2/ghettoVCB/vms_to_backup -g /vmfs/volumes/4a6bb65f-eb654b7b-2525-d8d385ab5bd2/ghettoVCB/ghettoVCB.conf > /tmp/ghettoVCB.log" >> /var/spool/cron/crontabs/root |
Wenn man dies Ausführt, wird der crontab automatisch an die richtige Datei angehängt.
Nun muss crond neu gestartet werden:
ESXi 4.1
|
1 |
/bin/kill $(cat /var/run/crond.pid) |
|
1 |
/bin/busybox crond |
Die Cron-Tab von ESXi wird bei jedem Start wieder neu geschrieben. Um die Zeile deswegen bei jedem Start auszuführen, muss diese noch in die /etc/rc.local eingetragen werden. Meine rc.local sieht anschliessend so aus:
|
1 |
vi /etc/rc.local |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
#! /bin/ash export PATH=/sbin:/bin log() { echo "$1" logger init "$1" } #execute all service retgistered in /etc/rc.local.d if [ -d /etc/rc.local.d ]; then for filename in `find /etc/rc.local.d/ | sort` do if [ -f $filename ] && [ -x $filename ]; then log "running $filename" $filename fi done fi /bin/kill $(cat /var/run/crond.pid) /bin/echo "0 17 * * 4 /vmfs/volumes/4a6bb65f-eb654b7b-2525-d8d385ab5bd2/ghettoVCB/ghettoVCB.sh -f /vmfs/volumes/4a6bb65f-eb654b7b-2525-d8d385ab5bd2/ghettoVCB/vms_to_backup -g /vmfs/volumes/4a6bb65f-eb654b7b-2525-d8d385ab5bd2/ghettoVCB/ghettoVCB.conf > /tmp/ghettoVCB.log" >> /var/spool/cron/crontabs/root crond |
ESXi 5.5
|
1 |
kill $(cat /var/run/crond.pid) |
|
1 |
crond |
Die Cron-Tab von ESXi wird bei jedem Start wieder neu geschrieben. Um die Zeile deswegen bei jedem Start auszuführen, muss diese noch in die /etc/rc.local eingetragen werden. Meine rc.local sieht anschliessend so aus:
|
1 |
vi /etc/rc.local.d/local.sh |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
#!/bin/sh # local configuration options # Note: modify at your own risk! If you do/use anything in this # script that is not part of a stable API (relying on files to be in # specific places, specific tools, specific output, etc) there is a # possibility you will end up with a broken system after patching or # upgrading. Changes are not supported unless under direction of # VMware support. /bin/kill $(cat /var/run/crond.pid) echo "0 17 * * 4 /vmfs/volumes/54016b12-54a601dc-1d3c-d43d7e942aae/ghettoVCB/ghettoVCB.sh -f /vmfs/volumes/54016b12-54a601dc-1d3c-d43d7e942aae/ghettoVCB/vms_to_backup -g /vmfs/volumes/54016b12-54a601dc-1d3c-d43d7e942aae/ghettoVCB/ghettoVCB.conf > /tmp/ghettoVCB.log" >> /var/spool/cron/crontabs/root crond exit 0 |
Nun nur noch autobackup durchführen, das ganze in der ESXi Konfuguration zu speichern:
|
1 |
/sbin/auto-backup.sh |
Das wars! Jetzt werden die VMs automatisch regelmässig gesichert.
Restore durchführen
Um einen Restore druchzuführen, habe ich ein file vms_to_restore erstellt, wobei dieses pro Linie einen Restore-Parameter mit folgendem Format enthalten muss:
|
1 2 3 4 5 6 |
";;" # DISK_FORMATS # 1 = zeroedthick # 2 = 2gbsparse # 3 = thin # 4 = eagerzeroedthick |
z.B.:
|
1 |
"/vmfs/volumes/QnapTSDatastore/VmBackups/TestVM32Bit/TestVM32Bit-2013-01-03_13-25-54;/vmfs/volumes/ESXi Raid1/TestVM;3" |
Anschliessend kann das Restore folgendermassen gestartet werden (Option -d 2 = Dryrun):
|
1 |
./ghettoVCB-restore.sh -c vms_to_restore -d 2 |
Dies stellt das von ghettoVCB erstellte Backup “TestVM32Bit-2013-01-03_13-25-54” unter dem Pfad “/vmfs/volumes/ESXi Raid1/TestVM” her bzw. kopiert diese dahin und registriert die VM neu beim ESXi-Host.
Die Fileformate
zeroedthick (default)
vmdk wird in voller Groesse angelegt – dieser Typ wird bei der Erstellung nicht mit Nullen ueberschrieben – das passiert erst spaeter im Betrieb
eagerzeroedthick
vmdk wird in voller Groesse angelegt – dieser Typ wird bei der Erstellung mit Nullen ueberschrieben
thick
vmdk wird in voller Groesse angelegt – und nie genullt
thin
vmdk waechst nach Bedarf – dies ist ein Feature des VMFS dateisystems – und ist auf den meisten NFS-servern nicht moeglich
2gbsparsed
vmdk wird in maximal 2 Gb grosse Stuecke aufgeteilt – die jeweils nach Bedarf wachsen – dieses Format ist it Workstation kompatibel
Firefox Security
Plugins
Folgende Plugins sind für Firefox empfehlenswert um spurenarmer zu surfen:
- μBlock Origin (Empfehlung: Wie das Addon eingestellt werden sollte)
- NoScript
- Cookie Controller
- HTTPS-Everywhere
- Smart Referer
- CanvasBlocker
- Privacy Settings => dort »Full Privacy« aktivieren
Firefox about:config Anpassungen
Suchfeld rechts oben wieder anzeigen
|
1 |
browser.search.widget.inNavBar = true |
Anzeige von Vorschlägen bei der Eingabe deaktivieren
|
1 2 |
browser.urlbar.suggest.searches = false browser.urlbar.suggest.openpage = false |
Suchvorschläge deaktivieren
|
1 2 |
browser.urlbar.suggest.bookmark = false browser.urlbar.suggest.history = false |
Unterbinden, dass Firefox nach Hause telefoniert um festzustellen aus welchem Land man stammt. Das benutzt Firefox um zu entscheiden, welche Suchmaschine standardmässig genutzt werden soll (USA = Yahoo und alle anderen mit Google)
|
1 2 3 |
browser.search.countryCode = CH browser.search.geoSpecificDefaults = false browser.search.geoip.url = "" (leerer String) |