Dimensionierung Webserver

Okay... geschafft, nun weitere Fragen ;-)


Das heisst aber auch ich muss immer erst via putty den Tunnel aufbauen mit dem Port-Forwarding und dann anschließend via VNC connecten.

Der Dateitransfer via scp oder sftp funzt ebenfalls, das bringt ja der openssh-server mit.

Muss ich eigentlich bei den beiden Paketen ssh und openssh-server noch etwas konfigurieren? Schlüssellänge oder einen Algorhithmus?

Gibt es einen Unterschied zw. scp und sftp der beim Dateitransfer irgendwie sicherheitstechnisch bedenklich wäre?

Danke!
 
SCP und SFTP sind einfach nur Protokolle die eine Ebene über SSH laufen und die Verschlüsselung / Authentifizierung davon benützen.

Was du benütz ist eigentlich Jacke wie Hose.
Unix -> Unix natürlich SCP.
Win -> Unix nehm ich zu 99% WinSCP.
 
Okay, beides läuft nun.

Ich muss noch mit ein paar Fragen nerven zum Schluß:

Wie würdet ihr denn mehrere Domains serverseitig organisieren?

Ich habe 3 Domains welche ich hosten möchte. Ich kann ja nun hergehen und einfach alle 3 Domains auf einen Server und diese intern mittels vHosts ansprechen.
Hierzu brauche ich ja lediglich einen WAN Port meiner Firewall und eine NIC am Server.


Oder ist es günstiger pro Domain ein eigenes Netz zu bauen und diese dann an physikalisch getrennten Ports über die Firewall und an eigenen Netzwerkadaptern des Servers zu betreiben. Hierzu brauche ich dann einen WAN Port an der FW und eben 3 Ports für die Domain plus 3x NIC am Server.

Abgesehen vom höheren Update, Wartungs- und Sicherungsaufwand.

Welches Konzept würdet Ihr wählen??

So und zuletzt. Wenn ich mich via IPSec mit der FW verbinde also:

WAN -- IPSec -- FW -- LAN

Ist es dann nicht unnötig sich via WAN und SSH per VNC anzumelden? Dann ist die offene Shell nach außen doch gar nicht nötig oder? Dann könnte ich doch den SSH so einstellen, dass nur der IP-Kreis des VPN zugelassen wird. Angriffe von quasi fremd sind dann ausgeschlossen.

Danke für die Hilfe
 
iceview schrieb:
Wie würdet ihr denn mehrere Domains serverseitig organisieren?

Ich habe 3 Domains welche ich hosten möchte. Ich kann ja nun hergehen und einfach alle 3 Domains auf einen Server und diese intern mittels vHosts ansprechen.
Hierzu brauche ich ja lediglich einen WAN Port meiner Firewall und eine NIC am Server.

Vhosts sollten die angenehmere Variante sein. Solange die Domain-Zuordnungen stimmen geht das butterweich. Über SuPHP kannste dann sogar noch einen ordentlichen Zacken Sicherheit ins System bringen. Wenn du das von mir verlinkte Perfect Server - Tutorial abgearbeitet hast, dann hast du ISPConfig vielleicht gleich mit installiert. Darüber kannst du einerseits den Serverstatus (Festplattenbelegung, laufende Dienste,...) überwachen, andererseits kannst du kinderleicht weitere VHosts nebst SSH-Login, FTP-Zugang, Datenbank,... anlegen.
 
Ich kämpfe mich derzeit durch die Apache Konfiguration. Ich kenne es auf den Xampp Konfigurationen, dass man dort eine vHosts.conf included und dort die einzelnen Hosts administriert.

Unter Unix ist dies ein wenig anders habe ich gemerkt. Man kann sich mittels a2ensite ja einiges an Arbeit ersparen. Mir ist nur nicht klar, warum wird dieser Weg mit den Symblinks gewählt. In sämtlichen Tutorials findet man diese vorgehensweise. Bei mir läuft auch alles, inkl. eingebundenen SSL Zertifikaten. Nur verstehe ich den Sinn oder Unterschied zw. Xampp und Apache unter Ubuntu noch nicht.

Ich könnte sicherlich doch auch für jede Seite eine host-x.conf schreiben und diese manuell einbinden...

Und... wenn man nur eine Domain auf dem Server betreibt und keine vHosts nutzt, muss / sollte man dann dennoch einen vHost mit a2ensite anlegen?


Und noch zum Schluß, auch auf die Gefahr hin gesteinigt zu werden. Irgendwann möchte ich gerne mal die CACert Zertifikate gegen ein Zertifikat eines der Globalplayer austauschen.

Worin unterscheiden sich denn Domain von Organisations Zertifikaten?

Danke
 
Du hast unter /etc/apache2 die ganzen Config-Files vom Apache2 (haste ja sicher gemerkt). Darin schwirren im Ordner sites-available die Config-Files (mit frei wählbarem Dateinamen, aber sinnig sollt er sein) für alle VHosts rum. a2ensite macht nun nix anderes, als einen Symlink von einer der Config-Dateien in den /etc/apache2/sites-enabled zu legen. Die zentrale Config-File (in /etc/apache2) bindet einfach alle Scripte ein, die in /etc/apache2/sites-enabled liegen.

Der Vorteil liegt auf der Hand: Du kannst einen Haufen Sites im "available" vorbereiten und, sobald dein Kunde (als Webhoster) seine Rechnung bezahlt hat, einfach mit a2ensite (oder manuell per ln -s ...) ins enabled linken. Kurzer Service-Restart, schon läuft die Seite (oder eben nicht mehr, wenn der Kunde die Zeche prellt)


Aber wenn es dir um ersparte Arbeit bei den VHosts geht, dann empfehle ich definitiv die Installation von ISPConfig. Mächtig, relativ leicht zu begreifen und vor allem Open Source.
 
Hi,

danke für da geduldige Helfen zunächst mal :)

Ja Tools wie Webmin oder ISPConfig habe ich mir angesehen. Das ist sicherlich eine prima Hilfe, allerdings muss/möchte ich vorger verstehen was dort passiert. Dann kann ich diese Tools ein wenig sicherer einsetzen.

Mit dem Apache... also es ist wenn ich es richtig verstehe eigentlich egal, ob ich z.B. eine conf Datei selber schreibe und diese an beliebiger Stelle include oder aber über a2ensite die Seite als vHost implementiere. Das zweite ist ist die sicherlich professionellere Lösung, welche bei einem Server zum Einsatz kommt auf dem mehr als eine Seite gehostet wird.

Ich hoffe ich hab das soweit verstanden.

Sind beide Lösungen eigentlich "updatesicher"? Oder werden mir bei einem Apacheupdate alle Configs überschrieben?
 
iceview schrieb:
Ja Tools wie Webmin oder ISPConfig habe ich mir angesehen. Das ist sicherlich eine prima Hilfe, allerdings muss/möchte ich vorger verstehen was dort passiert. Dann kann ich diese Tools ein wenig sicherer einsetzen.
Im Endeffekt legen die Tools einen User nebst Gruppe an für jede Seite, die im System laufen soll. Irgendwo, z.B. in /var/www, landet dann ein Ordner für diesen User und seine Files. Dazu legen die Tools automatisiert Datenbank-User nebst Datenbank, FTP-User, WebDAV-Zugänge und nicht zuletzt die hässlichen Files für /etc/apache2/sites-available an.
Klar, kann man alles per Hand machen, sollte man auch per Hand kontrollieren können, falls mal was spinnt, aber das Leben wird halt viel einfacher, wenn man 5 Webseiten eines Servers von einer zentralen Stelle mit n paar Klicks abschalten kann, weil der Kunde einfach nicht zahlt.

Mit dem Apache... also es ist wenn ich es richtig verstehe eigentlich egal, ob ich z.B. eine conf Datei selber schreibe und diese an beliebiger Stelle include oder aber über a2ensite die Seite als vHost implementiere. Das zweite ist ist die sicherlich professionellere Lösung, welche bei einem Server zum Einsatz kommt auf dem mehr als eine Seite gehostet wird.
a2ensite ist im Prinzip nur ein Tool, dass auf eine conf aus aus sites-available n Simlink nach sites-enabled legt.
Du kannst problemlos deine eigenen .conf's irgendwo hinlegen und z.B. über die httpd.conf includen. Du kannst auch jeden VHost direkt in der httpd.conf deklarieren, ist nur endlos unübersichtlich. Die saubere Variante ist halt, für jeden VHost eine conf in sites-available zu legen und entweder selbst mit ln -s oder über a2ensite den Symlink nach sites-enabled zu werfen (da in regulären Konfigurationen eben alle .conf's aus sites-enabled included werden). Ist dasselbe Spiel wie bei Apache-Modulen, nur heißen die Ordner da halt mods-available und -enabled und das Tool a2enmod

Sind beide Lösungen eigentlich "updatesicher"? Oder werden mir bei einem Apacheupdate alle Configs überschrieben?
Bisher blieb mir meine httpd.conf immer erhalten, wenn ich über die Paketverwaltung aktualisiert habe. Frag mich aber nicht, was passiert, wenn du dir n Apache selbst kompilierst *G*
Aber im Zweifel gehst du auf Nummer Sicher: Kein Updater wird auf die Idee kommen, dir dein sites-available/enabled - Verzeichnisse zu leeren oder darin rumzupfuschen. Oh, und wenn doch: Die ganzen Webmin/Config - Tools sind Datenbank-basiert. Solange es dir die DB nicht zerballert halten die Tools per Cronjob die ganze Server-Config konsistent. Heißt natürlich auch, dass du nicht ohne weiteres manuell drin rumpfuschen kannst.
 
Zurück
Oben