Schlagwort: VM

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

Veröffentlicht am 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!

VMWARE ESXI auf Webtropia

Veröffentlicht am von

Update: 12.11.2015 — So funktionierts dann doch mit dem Portforwarding und Zusatz-IPs… falls man nicht an untenstehender Story interessiert ist 🙂

 

Bei Webtropia wird VMWARE Esxi erst ab dem „PowerServer“ zur Verfügung gestellt. Das Schöne daran ist, dass man zwischen der automatischen Installation von ESXI 5.5 und ESXI 6.0 wählen kann. (Nein, man muss kein ISO Image uploaden!)

Als NIC kommen INTEL I350 zum Einsatz. Neben den Intelnetzwerkkarten verrichtet eine Intel Xeon CPU D-1540 @ 2.00 GHZ ihren Dienst und wird dabei von 1TB SSD Festplatten (SATA) unterstützt.

Ein schönes Feature des Powerserver ist, dass ILO (Remote-Management über separate IP) möglich ist. Geht per VMWARE nichts mehr, kann man sich immer noch direkt auf den Server hängen und die Sachlage prüfen.

Netzwerkkonfiguration

Ich gehe hier jetzt gar nicht genauer auf die Installation von virtuellen Maschinen ein, sondern eher auf die Netzwerkeinstellungen.

Grundsätzlich bin ich bislang mit meinem Vorhaben pfSense als Firewall-Router einzusetzen gescheitert. (Dies wiederum liegt nicht unbedingt an Webtropia, vermutlich mache ich einfach irgendwo einen Fehler und komme nicht dahinter).

Die Idee, die ich primär hatte war (ähnlich wie bei meinem Hetzner-Artikel) zumindest eine WAN Schnittstelle und eine DMZ per IPSense zur Verfügung zu stellen und externe Anfragen von aussen (WAN) nach innen (DMZ) gefiltert weiterzuleiten.

Probleme…

Ab Bestellung bekommt man 2 IP Adressen. Eine IP Adresse wird für das ESXI Management „verbraten“, die andre liegt am ILO an.

Die IP, die für den ESXI Host verwendet wird, hat einen entsprechend zugehörigen Gateway im gleichen Subnet.

zusätzliche IP Adressen

Bestellt man sich nun zusätzliche IP Adressen, bekommt man selbige zwar sehr zackig zugeteilt, jedoch befinden sie sich in einem ganz andren Subnet wie die Haupt-IP. Ungeachtet dessen, haben Sie aber den gleichen Gateway wie die Haupt-IP. Der Gateway liegt aber in einem andren Subnetz wie die zusätzliche IP.

Modus der zusätzlichen IP Adressen

Im Kundenbackend von Webtropia hat man bei den zusätzlichen IPs 2 Varianten, wie mit diesen umgegangen werden soll:

1.) Server IP, hier wird geroutet

2.) Virtualisierungs-IP, hier wird gebridged

 

Server-IP Konfiguration

Die Adresse wird als Alias angelegt:

auto eth0:1
iface eth0:1 inet static
address aaa.bbb.ccc.ddd
netmask 255.255.255.255

Virtualisierungs-IP

Die Adresse wird in einem point-to-point Setup angelegt:

auto eth0
iface eth0 inet static
address 10.0.2.100
netmask 255.255.255.255
pointopoint 10.0.1.1
gateway 10.0.1.1

Woran ich mir bislang die Zähne ausbeisse…

Genau hier scheitere ich mit der Konfiguration von pfSense. Ich hätte ja den ESXI auf die Hauptadresse des Server gelegt, denn ich gehe davon aus, dass im routed Modus meine Zusatz-IPs über die Server-IP geroutet werden.

Somit könnte ich eingehende Anfragen je nach IP auf virtuelle Server in der VM / DMZ leiten.

ABER: Sobald ich dem ESXI-Host seine IP wegnehme, ist dieser nicht mehr erreichbar.

Wenn ich ihm eine Zusatz IP gebe, kann ich den ESXI host ebenso nicht mehr erreichen, da hier eine entsprechende Netzwerkkonfiguration (siehe am Beispiel Debian point-to-point) notwendig ist, die ich am ESXI Host direkt nicht umsetzen kann.

 

Update 12.11.2015

  • Router-VM: IPFire (basierend auf „Linux“).
  • Einstellungen im Kundencenter von Webtropia bezogen auf die IP-Adressen: Virtualisierung
  • Verwenden einer zusätzlich bestellten IP (nicht der Haupt-IP auf dem WAN-Interface der Router-VM).
  • Auch wenn der Gateway in einem andren Netzwerk liegt, kann man ihn auf die WAN NIC binden (WAN-NIC = red0) und dann die Standardroute auf das Gateway setzen.

Im Terminal von IPfire:

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

Diese Konfiguration wird jedoch nicht gespeichert und sollte u.U. per Skript / Konfiguration (bei Systemstart) hinterlegt werden. Wird IPFire eingesetzt, sind diese 2 Zeilen in die Datei /etc/sysconfig/rc.local einzufügen.

Ein Interessanter Beitrag zum Thema „Gateway befindet sich in anderem Subnet“: http://blog.magiksys.net/pfsense-firewall-default-gateway-different-subnet

 

Was kann man nun mit dieser Konfiguration erreichen

 

  • IP-Fire lauscht auf einer der zusätzlichen IPs.
  • Portforwarding von extern in die DMZ ist ohne weiteres möglich.

 

Fazit zu Webtropia

Generell muss ich bislang festhalten, dass der Server recht schnell zur Verfügung gestanden ist. Bislang habe ich keinerlei Probleme.

Der Support antwortet recht zügig und gibt sich Mühe, um Probleme zu lösen.

VMWare Esxi auf Hetznerservern – Routervm – pfsense

Veröffentlicht am von

Generell vergibt Hetzner bei der Serverbestellung nur eine offizielle IP Adresse. Hat man vor, ESXI auf dem Hetznerserver zu betreiben, sollte man gleich noch eine weitere IP Adresse dazu bestellen. Wie in vielen anderen Tutorials erwähnt, sollte man bei Bestellung unbedingt angeben, dass die zweite IP Adresse für Virtualisierungszwecke verwendet wird (Router-VM).

Anmerkung: Ich denke jedoch, wenn man per pfSense ein Portforwarding WAN <-> LAN realisiert, reicht auch eine offizielle IP. So kann man z.B. Anfragen die auf Port 80 kommen per pfSense an eine bestimmte IP (VM) innerhalb des „LAN“ weiterreichen, auf der ein Webserver läuft, Port 25 auf eine VM, auf der ein SMTP Server lauscht etc.

Grundsätzliche Idee

Installation von VMWARE ESXI 5.1 (bitte dieses Image zur Installation verwenden) mit Upgrade auf 5.5, da zumindest in dem von uns verwendeten Server (EX40) eine Realtekkarte läuft, die sonst nicht (ohne ein Customimage) erkannt wird.

Ich gehe hier nicht auf die grundlegende Installation ein. Kurz zusammengefasst: ESXI kann nicht per Robot installiert werden, sondern muss per LARA, nach Einbindung eines entsprechenden ISO-Files installiert werden. (Stichwort Virtual Media).

Die ISO-Files liegen auf einem Mirror von Hetzner, der in der LARA entsprechend konfiguriert werden muss.

Meiner Erfahrung nach (und auch nach Aussagen des Supportes), gibt es wohl immer wiedermal Probleme mit der Einbindung des ISOs per Lara. Konkret funktioniert sporadisch die Tastatur nicht mehr in der Remote Konsole der „LARA“, wenn ein Virtual Media eingebunden ist. Dies wiederum macht eine Installation unmöglich.

Lösung: Dem Support mitteilen, dass das ISO bitte auf einen USB-Stick „gebannt“ und an den Server angesteckt wird.

Dann kann per Lara (F11-Bootmenü-> Boot from USB-Stick) die Installation gestartet werden. Der Haken dabei ist, dass diese Aktion zur Zeit EUR 25,00 (einmalig) kostet.

Managementnetzwerk im Internet und Sicherheit

Anfangs wird das Managementnetzwerk (Vsphere Client) über die offizielle IP angesprochen, welche von Hetzner standardmäßig bei der Bestellung vergeben wird. (Dies wird jedoch aus Sicherheitsgründen geändert und auf Zugriff per Openvpn umgestellt – d.h. kein Zugriff mehr aus dem Internet direkt!).

Abgesehen vom Zugriff über VPN könnte man in der Hostkonfiguration das Sicherheitsprofil insofern anpassen, dass Zugriffe auf u.a. den vSphereclient nur von fixen IP Adressen zugelassen wird.

Wenn pfSense (weiter unten) dann mal läuft: So installiert man Openvpn in pfSense. 

Anmerkung: In dieser Konfiguration ist ein Zugriff auf das Managementnetzwerk nur möglich, wenn a.) Der VPN Tunnel steht und b.) die pfSense-VM läuft. Man sollte daran denken, die pfSense-VM in den Autostart zu geben.

Mehrere VMs, obwohl nur eine NIC vorhanden ist

Pfsense wird u.a. als Routervm, aber auch für Openvpn, diverse Portforwardingregeln und vieles mehr genutzt. So kann man, wenn alles eingerichtet ist, sowohl eine PAT als auch ein NAT auf verschiedene VMs innerhalb des LAN bewerkstelligen.

pfSense Installation

Das Bindeglied zwischen dem isolierten vSwitch (LAN) und dem zweiten vSwitch (WAN) bildet pfsense. (Router/Firewallfunktionalität).

Anmerkung: Es werden im HowTo 3 NICs konfiguriert, ich habe das mit 2 NICs realisiert.

Konfiguration des Netzwerkes

Die pfSense-VM bekommt 2 virtuelle NICs zugeordnet (im Beispiel: VMNetwork und Intranet):

pfsense_settings

Auf dem ESXI Server benötigen wir einen Vswitch (im Bild unten VM Network) der mit der physischen NIC verbunden ist. pfSense liegt hier mit dem WAN-Port an, dem die zweite offizielle IP, die wir von Hetzner angefordert haben, zugeordnet ist.

Dem isolierten vSwitch (vSwitch ohne NIC) ist schließlich die vNIC „Intranet“ (LAN) des pfsense zugeordnet. Hier werden dann auch alle VMs angeschlossen. (Im Beispiel eine Ubuntu-VM).

netzkonfigswitches

Anmerkung: In der obigen Darstellung ist das Managementnetzwerk bereits auf das interne Netzwerk verschoben (IP: 192.168.1.2). D.h. der vSphere Client ist von aussen nicht mehr erreichbar. (Zuvor muss eine VPN-Verbindung aufgebaut werden!)

Das Managementnetzwerk wird „verschoben“ in dem man einen neuen VMkernelport erstellt:

vmkernel

und diesen dann dem isolieten vSwitch zuweist (in unsrem Fall vSwitch2):

vmkernel_switch

In den vSwitcheinstellungen (Eigenschaften) muss dann bei der Konfiguration des VMKernelports die korrekte interne IP + korrektem internen Gateway angegeben werden:

vmkernelkonfig

 

Mittels Bearbeiten / Reiter IP Einstellungen müssen die korrekten Werte für IP/Subnet/Gateway hinterlegt werden:

ipsettings

Danach sollte mittels vSphereclient, nach Aufbau der VPN Verbindung, ein Management über die IP 192.168.1.2 möglich sein. Erst wenn dass verifiziert worden ist, kann das Managementnetzwerk, welches noch auf dem vSwitch0 anliegt und bei der Installation des ESXI automatisch installiert wurde, entfernt werden. Dies unterbindet dann den Zugriff über die offizielle IP.

Obwohl ich wie immer versucht habe, an alle Eventualitäten zu denken, kann ich keine Garantie für die Sicherheit dieser Konfiguration übernehmen!

Update: Wie sich zumindest bei mir herausgestellt hat, funktioniert die Einbindung des Subnet nicht stabil. Sprich die Subnet-IPs sind mal erreichbar, dann wieder nicht. Ein installiertes Owncloudserver auf einem Debian funktioniert zwar grundsätzlich, jedoch verliert u.a. der Owncloud-Client immer wieder die Verbindung.

Ich habe zwar schon einige Recherchen betrieben und auch bei Hetzner nachgefragt, doch bin zu keiner Zufriedenstellenden Lösung gekommen…

Installation Opensuse 11

Veröffentlicht am von

Installation von Opensuse 11 in Virtualbox

Wie vor einigen Tagen berichtet, gelang es mir nicht, Opensuse 11.0 auf Vmware zu installieren. Es wurde kein Festplattenkontroller erkannt. Daraus resultierend natürlich auch keine Festplatte.

Mittlerweile hat man Gott sei Dank die Qual der Wahl in Sachen Virtualisierungssoftware.  Ich habe mich dazu entschlossen mit Virtualbox (www.virtualbox.org) einen weiteren Versuch zu starten. Und siehe da, es funktioniert. (Bitte auf weiterlesen klicken, um den gesamten Artikel lesen zu können.) Weiterlesen

Opensuse 11 in Vmware (die Zweite)

Veröffentlicht am von

Leider doch daneben gelegen

Nachdem ich mir nun das Opensuse-Image erneut von de.opensuse.org heruntergeladen habe und die Überprüfung des Images keinen Fehler ergab, startete ich einen erneuten Versuch, Opensuse in meiner VM zu installieren.

Ich war mir eigentlich sicher, dass es diesmal klappen würde, dennoch machte sich eine gewisse Anspannung bemerkbar, als der Punkt „Festplattenerkennung“ angesteuert wurde.

Es stellte sich schließlich heraus, dass ich nicht ohne Grund „nervös“ wurde, denn leider findet Opensuse 11 in meiner VM wieder keine Festplatte / Partition, auf der eine Installation hätte stattfinden können.

Ich suche weiter… Sollte sich mittlerweile jemand finden, der das hier liest und die Lösung parat hat, wäre ich dankbar für einen Tip 🙂

Zur Verbesserung des Service werden anonymisierte Nutzerdaten mittels Google Analytics verarbeitet. Falls Sie das nicht wünschen - > Hier klicken um dich auszutragen.