Internet

Owncloud bleibt nach Upgrade im Wartungsmodus

von

Immer wiedermal passiert es, dass meine Owncloud nach einem Upgrade (per apt-get) im Wartungsmodus hängen bleibt. Um diesem Umstand entgegen zu wirken, muss man in der config.php, welche sich in der Regel (Debian) unter:

  • /var/www/owncloud/config/config.php

befindet den Wartungsmodus abschalten.

Mit einem Texteditor eurer Wahl editiert ihr also die config.php folgendermaßen:

  • ‚maintenance‘ => true,

ändern in:

  • ‚maintenance‘ => false,

Um sicherzugehen, dass das Upgrade fehlerfrei gelaufen ist, kann man folgende Befehl in der Kommandozeile absetzen, sofern der Wartungsmodus bereits inaktiv geschaltet ist:

  •  sudo -u www-data /var/www/owncloud/occ upgrade

mit einem:

  •  sudo -u www-data /var/www/owncloud/occ status

 

lässt sich der Versionsstatus abrufen. In meinem Fall sieht das dann so aus:

  • – installed: true
  • – version: 9.0.0.19
  • – versionstring: 9.0.0
  • – edition:

VMWARE ESXI auf einem dedicated Server mit IPFire – LAN DMZ und WAN mit Zusatz-IPs

von

Generell würde ich sagen, gehöre ich speziell bezogen auf das IT Umfeld zu einem Menschen, der so gut wie niemals aufgibt. Gut – stimmt nicht – bei Vista und Windows ME habe ich hier eine Ausnahme gemacht ;-).

Geht nicht, gibts nicht…!

Aufgabenstellung:

  • Dedicated Rootserver
  • VMWARE ESXI Version 6.0
  • kompatible NIC (Intel)
  • Servermanagement per Remote (ILO)
  • Einsatz einer Router-VM, um die VMs entsprechend zu schützen und um WAN, LAN und DMZ realisieren zu können.
  • zusätzliche offizielle IP Adressen, um mehrere Server in der DMZ mit IP / FQDN ansprechen zu können.
  • VMs müssen auch ins Internet „raus“ kommen
  • Installation des ESXI sollte auf dem dedicated Server möglichst ohne „Krampf“ durchführbar sein.

Dedicated Rootserver

Ich habe einige bekanntere Rootserver Anbieter getestet. Darunter Hetzner, Server4you und Webtropia.

Server4you

Server4you brüstet sich NICHT damit, ESXI-kompatibel zu sein, bietet aber grundsätzlich recht gute Server und  angenehme Kommunikation. Selbst im Falle einer Kündigung des Vertrages lässt sich dies bequem über das Backend erledigen – keine Bürokratie!

Ein Grund für mich, einen Versuch zu starten…

Wenn ein Rescue-System auf S4Y läuft, könnte man lt. Auskunft (ohne Gewähr) über eine Drittanbieterseite (installserveros) einen Installationsversuch anstossen.

Versucht, gewartet und gescheitert.

Abgesehen davon: Niemand kennt diese Plattform, welches Image würde hier wohl installiert, man muss die Daten des Rescuesystems eingeben, damit die Site Zugriff auf den Server bekommt. Ja und was macht das Script dann? Ich weiß es nicht, …

Die Site funktioniert nicht und ist obendrein eventuell unsicher.

Fazit: Server4you für ESXI – no go!

 

Hetzner

Qualitativ hochwertige Server, sehr professioneller Auftritt. Bereitstellung der Geräte geht normalerweise rasch von der Hand. Mehrmals jedoch scheitere ich an der Verwendung der LARA. Dies ist eine Konsole, mit deren Hilfe man quasi direkten Zugriff auf den Server hat.

Immerwieder reagiert LARA nicht auf Tastatureingaben. Ich muss den Support mehrfach bemühen. (In Summe vergehen hiermit Stunden!).

Nebenbei erwähnt – LARA ist zeitlich limitiert und kostet nach Ablauf des  Gratispensums pro Stunde…

Mit dem Hetznerserver EX40 konnte ich es in weiterer Folge nicht schaffen, eine stabile Verbindung -> EXTERNE Zusatz-IP -> Router-VM -> DMZ -> Owncloud @ Debian zustande zu bringen, obwohl das Routing seitens Hetzner und auch die Konfiguration der Routing-VM stimmig war.

Getestete Routing-VMs: pfSense (mehrfach neu installiert), IP-Cop, ipFire.

Nicht ganz klar war mir, ob die Problematik vielleicht an der verbauten Realtek NIC lag.

Da Hetzner grundsätzlich wirklich gute Geräte anbietet, wollte ich noch einen weiteren Versuch mit einem PX60 (mit Intel-NIC) starten, gab dann aber schließlich auf, nachdem mich die LARA wieder zur Weißglut brachte.

Das Verhalten liegt lt. Hetzner daran, dass es Probleme mit der Einbindung des virtuellen Datenträgers gibt. O-Ton: „Kann funktionieren, aber muss nicht…“

Alternative: Man bittet den Support darum, das ISO File auf USB zu kopieren — Kostenpunkt allerdings EUR 25.00

 

Webtropia

Weiterer Anlauf, anderer Hoster. Wie im vorhergehenden Beitrag erwähnt, bietet meiner Meinung nach auch Webtropia recht gute Hardware. Vor allem Intel NICs (I350). Beim Server, der grundsätzlich als kompatibel zu ESXI 5.5 und 6.0 beschrieben ist, ist ein integriertes Management mit dabei, welches über separate IP und Webinterface (JAVA) ansprechbar ist.

Der Clou dabei: Es funktionierte bislang immer, ohne Ausnahme.

Webtropia bietet einen schönen Installer für diverse OS – und auch ESXI 5.5 und 6.0, der entweder per Backend angestoßen werden kann, oder per Bootmenu! — sehr schön, wie ich finde!

Somit sind die Kriterien:

 

  • Dedicated Rootserver
  • VMWARE ESXI Version 5.5 / 6.0
  • kompatible NIC (Intel)
  • Servermanagement per Remote (z.b. ILO)
  • Installation des ESXI sollte auf dem dedicated Server möglichst ohne „Krampf“ durchführbar sein.

erfüllt.

Konfiguration ESXI

Ich will mehrere Server in der DMZ (mehrere öffentliche IPs, die in die DMZ geroutet werden)

Genau genommen, habe ich mittlerweile aufgrund von Vererbung schon recht wenig Haare am Kopf. Nun, nach der ganzen Aktion habe ich definitiv noch weniger ;-). Nicht, dass es irgendein Problem seitens dem Anbieter (Webtropia) gab… Vielleicht hatte ich einfach einen Knoten im Hirn…

 

Switches und Netzwerk im ESXI

Das Managementnetzwerk ist auf die Haupt-IP gebunden und kann über diese IP über den Browser aufgerufen werden. Zu beachten ist hierbei, dass in der Grundkonfiguration JEDER aus dem Internet zumindest bis zum Login kommt.

Schnelle Abhilfe wäre, per Sicherheitsprofil den Zugriff per vSphereclient + sofern aktiv SSH-Server einzuschränken:

sicherheitsprofilesxi

Später sollte man das Managementnetz auf einen „internen Switch“ — (LAN) verlegen und ein VPN aufbauen, um darauf zuzugreifen.

Switches

Wir haben in der Grundkonfiguration 1x vSwitch0 (Managementnetzwerk). vSwitch0 ist an die physische NIC angebunden. Einen weiteren Switch für das LAN + einen Switch für die DMZ. LAN und DMZ-Switches sind sog. isolierte Switches. D.h. sie sind an keine Netzwerkkarte angebunden.

Das sieht dann so aus:

switchesipfire

 

To do, im Webtropia Backend

Über das Backend bei Webtropia bestellen wir uns zusätzliche IP Adressen. (ich hab mir 2 bestellt).

Wichtig: Bei den IPs kann man den Modus im Webtropia-Backend einstellen. Dieser Modus MUSS auf Virtualisierungs-IP stehen!

Noch viel Wichtiger: Man muss dem Support per Ticket mitteilen, dass alle weiteren bestellten Zusatz-IPs bitte auf die IP zu routen sind, die man auf dem WAN (red0) Port des IPfire vergeben hat. Also eine Zusatz-IP ist IPFire und jede weitere muss man auf die IP-Fire-IP routen lassen! Danke Herr Stevens! (Webtropia Support)

Lets fire it up – IPFire Installation

Wir erstellen uns im ESXI eine neue VM für die Installation von IPFire. Hierbei wählen wir „anderes Linux 2.6.x Linuxsystem – 64 Bit“ und folgende Konfiguration:

ipfireesxi

Wie man sieht 3x NICs / 3 Zonen…

Wichtig: Notiert euch die MAC-Adressen der NICs, welche man – während die VM läuft – über die Eigenschaften aufrufen kann. Dies braucht ihr nämlich, um -während des Setup von ipFire- die Interfaces korrekt zuzuordnen!

Netzwerkkonfig (Zonen)

In IPFire wählen wir während des Setup (welches man nach erfolgter Installation immer wieder mit dem Befehl „setup“ in der IPFire Konsole aufrufen kann die Netzwerkkonfiguration: GREEN (LAN) + RED (WAN) + ORANGE (DMZ).

NIC – Zuordnung

Hier werden die MAC Adressen schlagend. Darauf achten, dass die NICs den entsprechenden Zonen zugeordnet sind, sonst läuft nachher nichts!

nics_ipfire

IP –  Adressenzuordnung

WAN: Eine der georderten Zusatzadressen inkl. Gateway lt. Vorgabe des Hosters.
DMZ: Beliebiger interner IP Bereich. Ich hab hier 10.0.0.0/24 genommen. Gateway = Ipfire = 10.0.0.1
LAN: Ebenso beliebig. Meine Range: 192.169.1.0/24. Gateway = Ipfire = 192.168.1.1.

Hier könnte man dann noch in IP-Fire einen DHCP Server aktivieren, dann wirds ganz bequem. 🙂

DNS: Unbedingt angeben. Dies kann der vom Hoster bereitgestellte DNS sein, oder zb. auch der von Google. (Wenn man das mag…).

Standardgateway: Der Standardgateway zeigt auf den Gateway, der der Haupt-IP zugeordnet ist. (Die Zusatzip hat keinen expliziten Gateway!)

Der Gateway ist aber in einem andren Subnet

In IPFire muss man den Gateway an das red0 (WAN) Port binden und dann eine entsprechende Route setzen. Dies gelingt ausschließlich über die Konsole.

Um die Einstellungen persistent zu machen (Einstellungen überleben auch einen Neustart) ist mittels IPFire Konsole die Datei

/etc/sysconfig/rc.local

zu editieren und folgende Zeilen einzufügen:

route add -host  <Gateway> dev red0
route add default gw <Gateway>

Anmerkung: red0 = WAN-Port.

Nach einem Neustart des IPFire sollte diese Geschichte gegessen sein. Auch wenn er während des Bootvorganges meckert. Es funktioniert.

Versucht bitte nach erfolgtem Neustart eine IP zu pingen. Zb. den Standardgateway, der der Haupt-IP zugeordnet ist. Oder auch den Google-DNS – 8.8.8.8 (was hab ich nur mit Google?)

Der Routingtable des ipFire sieht bei mir dann so aus:

routing_fire

So, jetzt wo IPFire on fire ist, wirds Zeit für den Zugriff auf die GUI.

IP-Fire GUI Einstellungen – Firewallregeln

IP-Fire ist vom LAN aus von der entsprechend zugeordneten IP auf Port 444 über https zu erreichen.

Ich installiere mir in ESXI also eine VM (Linux Mint in meinem Falle), welche ich auf den LAN-VSwitch hänge. Ist ein DHCP Server konfiguriert, sollte Mint sich von selbst die korrekte IP Adresse holen. ACHTUNG: Es ist wichtig, dass auch der DNS stimmt, sonst liegt man bei Versuch eines WWW-Wellenrittes auf dem trockenen!

Kein DHCP: OK, dann bitte die LAN-IP + Gateway + DNS manuell zuordnen!

Ein Webserver in der DMZ

Weiters installiere ich ein Debian  „LAMP“ in ESXI und ordne es Netzwerkseitig der DMZ zu. Die IP von Debian ist 10.0.0.3 (Anm: Gateway = DMZ-Port von IPFire: 10.0.0.1)

So nun notiere ich mir die zweite Zusatz-IP die ich vom Hoster bekommen habe. Diese lautet in meinem Falle: 89.163.249.243

 

Zurück zur IPFire Gui

In der VM „Linuxmint“ rufe ich per Browser: https://192.168.1.1:444 auf (klick for bigger-Image):

ipfireonfire

Über Netzwerk –> Aliase lege ich dann einen Alias mit meiner Zusatz-IP an:

firealiasund gehe dann auf Firewall -> Firewallregeln -> Neue Regel:

rulesexternal

Weiter unten darauf achten, dass die Regel aktiv ist. (Haken gesetzt).

Der Firewall-Rulesbereich sieht dann so aus. (Anmerkung: ich habe hier noch weitere Rules, die Anfragen „abfangen“ und umleiten die direkt auf die IP von IPFire kommen. Bitte nicht beachten. Unsere Regel ist in Zeile 3 zu sehen:

rules_for_fire

 

Wenn man nun von einem beliebigen PC aus, die dem Webserver zugeordnete offizielle IP – in dem Fall also 89.163.249.243 – aufruft sollte sich Folgendes tun (klick for bigger view):

debian_fire

Tja, das wars dann mal soweit… Die Finger glühen, der Kopf raucht 🙂

Have fun!

Dankeschön + weiterführende Infos

PS: Danke an den Support von Hetzner, Server4you und Webtropia. So muss das laufen. TOP! Sehr bemüht, freundlich und schnell!

Nachsatz: Ein weiterführender Beitrag eines Bloggingkollegen bezogen auf Hetzner (nice!): https://virtpro.eu/vmware-esxi-hetzner-ex4-vorbereitung/

Opensource rules!

Danke an alle Entwickler und Unterstützer! You are awesome!

IPFire: http://www.ipfire.org/
PfSense: https://www.pfsense.org/
IPCop: http://www.ipcop.org/

Nicht vergessen möchte ich in diesem Zusammenhang auch VMWARE – (ESXI) für die unglaublich gute Virtualisierungsplattform!

Zarafaclient Outlookupdate KB3055041 – shared Kalender funktionieren nicht mehr

von

Dass Microsoft Office- bzw. Outlookupdates die Funktionalität des Outlook-Zarafaclient desöfteren einschränken, oder komplett „abdrehen“ ist weitestgehend bekannt. So verhält es sich nun offenbar auch mit dem Outlookupdate KB3055041.

Um die Funktionalität von Zarafa wiederherzustellen, muss der zarafaclient-7.2.1-51355.msi installiert werden, der zur Zeit allerdings in der Betaversion angeboten wird (aber funktioniert!).

 

Neue DHL Malware per Email unterwegs

von

Paketbenachrichtigungen sind eine praktische Sache, keine Frage. Dumm wird es nur, wenn man eigentlich nichts bestellt hat und dennoch eine Info über den Zustellungsstatus eines vermeintlichen Paketes erhält.

In so einem Fall, kann man zu 100% annehmen, dass es sich um Malware handelt.

Zur Zweit schwirrt wieder eine hohe Anzahl von FAKE-DHL Mails durchs Netz. Waren es Anfangs noch Emails mit ZIP-Anhang, ist man jetzt dazu übergegangen, eine offenbar nicht infizierte PDF Datei als Anhang zu senden. In dieser PDF Datei wiederum befindet sich ein Link, der auf eine Seite mit Malware (genaugenommen einem ZIP-Download) zeigt.

Ladet man sich das File herunter und öffnet es, hat man vermutlich ein Problem. Die Malware die man sich mit dem Öffnen der Datei einfängt, wird nämlich nicht von allen Virenkillern erkannt.

Der Inhalt des PDF sieht wie folgend aus und kann vermutlich variieren:

dhlVorgangsweise beim Erhalt derlei Emails

Die grauen Zellen bemühen! Hat man nichts bestellt, bekommt man keine Benachrichtigungen! Ich bin mir nicht mal sicher, ob DHL überhaupt per Email über den Status einer Lieferung informiert.

Jedenfalls sollten solche Emails SOFORT und UNGEÖFFNET gelöscht werden, dann erspart man sich so einigen Wirbel.

Ein paar Gedanken zu Joomlamigrationen (aktuell von 2.5.x auf Version 3.4.x)

von

Egal, wie man denn nun auf die neue Version von J! kommen will – an aller erster Stelle steht ein komplettes Backup der Files (z.b. Download der GESAMTEN Verzeichnisstruktur der J! Installation vom Webserver per FTP) und natürlich ein Backup der verwendeten J!-Datenbank.

Für das Datenbankbackup ziehe ich immer phpmyadmin heran.

Hat man das Backup ordnungsgemäß „gezogen“, kann man sich im nächsten Schritt überlegen, wie man denn die Migration angehen will. J! bietet eine Migrationsanleitung an. Ist der verwendete Webspace entsprechend konfiguriert, funktioniert das wohl auch recht gut. Leider jedoch, gibt es immer noch Konfigurationen – ja ich  spreche auch die Hoster an – die ein derart einfaches Upgrade bzw. eine einfache Migration nicht zulassen.

Da kann man sich dann auch die -sagen wir- „One-klick-Migration“ getrost in die Haare schmieren. Ja, es könnte sogar passieren, dass man sich Letztere rauft, wenn man mit einem Frontend „Weißer Adler auf weißem Grund“  konfrontiert wird…

Langer Rede kurzer Sinn: Wenn der Webspace nicht mitspielt, ist es meiner Erfahrung nach ein Martyrium J! wieder in die Gänge zu bekommen. (Vor allem, wenn man keinen Zugriff auf die Logdateien des Webserver hat!).

Einige Varianten

Natürlich sollte man zuerst die Hinweise der Migrationsanleitung beachten, diverse inkompatible Plugins etc. abschalten und checken, ob denn das Template überhaupt kompatibel ist. Danach wären folgende Varianten möglich:

  • Per Backend – Komponenten Joomlaaktualisierung: Wenn es klappt, die schönste Lösung (meiner Meinung nach).
  • Per Erweiterungen installieren: Man ladet sich das entsprechende Update/Upgradepaket herunter und uploaded es dann per „Erweiterungen – Erweiterungen – Paket hochladen“ hoch. (Scheitert oft an diversen Limits der PHP Konfiguration)
  • Per Erweiterungen aus Verzeichnis installieren: (Empfohlene Methode, wenn alles oben stehende scheitert): Lokales entpacken des J! Update Paketes – Hochladen in den tmp Ordner und Aufruf per Erweiterungen – Erweiterungen – Aus Verzeichnis installieren – Angeben des tmp Ordner.
  • Per FTP (nicht empfohlen): Man ladet sich das Upgradepaket herunter, entpackt es lokal und spielt es per FTP über die Joomlainstallation am Webserver. (wobei man bestehende Dateien überschreibt). Dies ist allerdings KEINE EMPFOHLENE VARIANTE MEHR… NEIN, sie ist verpönt! Dennoch bleibt Webhoster geplagten Webmastern oft kein anderer Weg…

Auswirkungen „per FTP“

Wenn man wirklich auf das letzte Mittel – dem Upload per FTP – zurückgreifen muss, hat dies natürlich auch entsprechende Auswirkungen auf die Installation. Die gravierenste ist meiner Meinung nach die, dass Dateileichen nicht entfernt werden. Hierfür ist ein Skript mit Namen script.php zuständig (administrator/components/com_admin/script.php), dass allerdings beim Upgrade/Update per FTP nicht aufgerufen wird…

Allein innerhalb der Version 3.x bis 3.4.1 gibt es unzählige Dateien und Ordner die eigentlich entfernt werden müssten.

Es verhält sich zwar so, dass die Dateien nicht direkt aufgerufen werden können – es macht also quasi nichts, wenn sie „liegen bleiben“ – schön ist es allerdings nicht. Ich bin mir nach wie vor nicht sicher, wie es hier bezogen auf die Sicherheit aussieht. Meine Meinung wäre allerdings: All das was nicht benötigt wird, hat auf dem Webspace nichts verloren.

Gerade deshalb wäre es wirklich eine gute Idee, seitens J! eine Bereinigungsfunktion (im Backend) anzubieten.

Bislang ist das jedoch eine ganz klare Fehlanzeige… leider… schade…