Preisfrage
Geizhals » Forum » Programmierung » Preisfrage (143 Beiträge, 1084 Mal gelesen) Top-100 | Fresh-100
Du bist nicht angemeldet. [ Login/Registrieren ]
.....
Re(5): Preisfrage
03.01.2006, 15:22:53
Ahem...

Falsche - unpassende - Antworten ;-)

IMHO kennt sogar MySQL Isolation Levels... Wenn du eine DB programmierst, ist das eines der /grundsätzlichen/ Fragen, in welchen Isolation Level das ganze spielen soll... READ COMMITTED ? SERIALIZABLE ?
Deine Kenntnisse in DB-Design brauchen also noch ein bißchen Nachhilfe - oder du solltest da jemand fragen. Welche Normalform hast du übrigens für die DB verwendet ? ACID steht übrigens für Atomar, Consistent, Isolation, Durability... Entscheidend wichtige Kriterien für eine DB.


C2-Security:
Benutzer-Login mit Sessions ? Das sagt nichts über den Security-Level aus... Denn das ist von A-Level bis No Security denkbar. Lies dich also besser mal da ein. Hint: Sowohl Linux Out-Of-the-Box als auch Windows bieten nur C2... Wobei Windows das IMHO bestmögliche Regelwerk für C2-Security hat, das ich je gesehen habe.

Availability:
Was macht dein Rechner bei einem Festplattencrash ? Was, wenn das Motherboard oder Ram oder sonstwas entscheidendes aufgibt ? Das sind Themen von Availability... Nutzt du VirtualIP oder sonstige Lösungskonzepte ?
Warum ? In welchem Umfang ? Wie sieht deine Risikoabschätzung für Totalausfall aus ?

Wöchentliches Backup ????
Seeehr mutig - aber immerhin eine Entscheidung. Hoffentlich nicht auf denselben Rechner [könnte ja sein, daß er ausbrennt]...

EDIT: Und ad HA - und zu meinem Lösungsvorschlag c-jdbc...
Bitte sag nicht, daß deine Lösung grob so aussieht:

  • 1 LAMP/WAMP-System - eine Festplatte, eine 100Mbit-Karte.
  • Benutzer surft via HTTP darauf
  • PHP baut via mysql_connect oder so eine Verbindung zur MySQL auf.
  • Benutzer kann sich produkte aus DB aussuchen
  • 1x in der Woche passiert ein Backup der DB-Files auf DVD

Denn dann kommt mir /echt/ das kotzen.

Versteh' mich nicht falsch, als Hobby-Gschichterl ist das eh nett und eine gute Leistung. Als kommerzielles Produkt... NEIN. BitteBitte sag mir, daß deine Lösung ganz anders aussieht - und grob wie ;-)




03.01.2006, 15:33 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier
Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
.......
Re(7): Preisfrage
03.01.2006, 15:40:50
Hi !

Der Server ist also gemietet... eh ok. Zumindest dürfte damit die USV-Versorgung sichergestellt sein. Gut. [Ich nehm' mir immer ServerHousing für meine - daher kenn ich da die Situation net so ;-)]

Sind die Platten auf einem Raid ? Bekommst du mit, wenn der Spiegel bricht ?

Das mit dem 2. Rechner ist auch gut... Nur: willst du wirklich nur 1x in der Woche backuppen ? Willst wirklich Kundendaten einer Woche verlieren können ?
Wenn du eh über's Netz auf einem 2. Rechner arbeiten kannst - warum nutzt du nicht Technologien wie 2-phase-commit ? Warum keinen DB-Cluster ? Oder als Alternative eine Standby-DB ? Was waren deine Entscheidungskriterien ?

Versteh' mich nicht falsch... Ich will deine Leistung keinesfalls schmälern. Wirklich nicht. Ich befürchte nur echt, daß es einfach viel gibt [daß es aus gutem Grund gibt], daß du einfach noch nicht kennst... Ähnlich wie ich von mir schrieb "Anfangs dachte ich, daß ich alles kann" ;-)

Achja, eines noch zur Kundenbuchung:
Ich vermute mal, daß du den Standard-Weg beschreitest und dem neuen Kunden eine eMail schickst, anhand der er sich seine email-Addy authentifizieren kann. Dir ist aber eh bewußt, daß Mail-Server-Gschichtn (egal ob sendmail, postfix, ..) extrem viel Wissen erfordern - und eine wirklich saubere Config sauschwer ist (das wäre eines der Klassikerthemen, das ich selbst nicht anrühre, weil es eine eigene [und nicht meine] Welt ist) ?


Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
.........
Re(9): Preisfrage
03.01.2006, 16:08:11
Du sprichst immer von der Applikation - und ich von der Architektur, drum reden wir aneinander vorbei ;-)

Buchen in /EINE/ DB ist [fast] immer eine schlechte Idee. Ich mein, ok, wenn deine Datenbank ein Oracle-Rac ist oder von mir aus eine DB2 auf nem Sysplex - dann kann man das so lösen. Beides trifft hier wohl nicht zu ;-)

Zuerst mußt mal den Rechner (inkl. OS) sauber hinkriegen. Hardenen, wo nur geht. Bei Linux gibt's genug Möglichkeiten, daß dir nicht mal mehr Schaden entsteht, wenn der Angreifer eine rootshell auf deinem Rechner "ergattert" hat - lcap und selinux sind da dein Freund. Das kriegst auch auf dem gemieteten Rechner hin - eben in einer uml. Normalerweise baust du bei eCommerce gleich einen Cluster - eben 2 Rechner, die transparent Sessions übernehmen. Bei einem Webshop macht das auch schon Sinn... Man muß nur wissen, was man tut - dann kriegt man das mit OpenSource kostenfrei hin. Aber lassen wir mal das Thema und vermuten, daß die Server aus HW-Sicht ausfallsicher sind (was keiner ist).

Die Datenbank würde ich aber jedenfalls parallelisieren - denn in Wirklichkeit würde Dir im Recovery dann ja reichen, wenn deine PHP-Scripts gesichert sind und die DB.

Ich habe keine Ahnung, ob die MySQL 2-phase-commits kann (PostgreSQL kanns). Das funktioniert grob so:

Ein Benutzer(hier Apache/PHP) steigt in der DB ein und setzt zB
UPDATE X set a=2
ab.
Die DB würde das Update mal durchführen - soweit sogut. Wenn es nicht klappte - gibt sie eine Fehlermeldung aus und Schluß [bisher also Standard-Verhalten].
Direkt nach dem Update würde die DB selbst über das Netz auf einer anderen DB dasselbe Kommando absetzen. Erst wenn dieses Statement auch klappte, würde sie ein "ok" zurückmelden.

Das ist jetzt echt grob vereinfacht, du müßtest dich zwischen sync/asyn entscheiden, ...

Der Vorteil ist, daß du ein Backup der dann nicht brauchst. Du hast 2 Datenbanken auf verschiedenen Rechnern, die immer genau denselben Stand haben. Wenn Rechner 1 ausfällt (egal ob HW oder SW), so hast am 2. Rechner alle commitierten Daten sofort verfügbar - nix kommitiertes verloren.

Alternative wäre eben ein DB-Cluster wie Oracle-RAC zu fahren. Als "RAC für Arme" könntest Dir echt c-jdbc ansehen... Das klappt fein mit allen Datenbanken, die jdbc können - also wohl auch MySQL. Du würdest zusätzlich Performance-Vorteile erzielen (die hier wohl wurscht sind).

Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
.....
Vorschlag zur Güte...
03.01.2006, 15:55:37
Das Produkt hast eh schon "verkauft" - ok. Hoffen wir mal, daß nix passiert ;-).

Aber nutze das gleich, um deinem Onkel Updates liefern zu können - kostenfrei. Er hat ja schon genug bezahlt ;-)

Aaaaalso:
Ich bin mir jetzt nicht sicher, ob das System unter Win oder Lin läuft.
Wenn es Linux ist - sieh' Dir unbedingt selinux an. Ein Lösungsansatz wäre [weil gemieteter Server... brrr] das ganze in einer UML gebridget laufen zu lassen.

Wenn es ein Windows-System ist - kümmer Dich von den Dateisystemoperationen aufwärts um wirklich alle OS-Sicherheit, die möglich ist (auch nicht meine Baustelle)

Wenn dein Betriebssystem absolut sicher scheint - spiel die ganzen Fälle durch: Was passiert, wenn der Apache nun Scripts eines Angreifers ausführen kann. Was kann er tun, welche Kennwörter kann er lesen, .... - und wie kannst du das verhindern. Ist kein "Pro-Forma-Thema". Wenn ich Kinderpornos anbieten würde, würde ich das auch ganz sicher nicht von meinem Server aus machen - sondern erst in andere einbrechen. Genauso wenn ich DDoS fahren wollte. Und JA, du /haftest/ dafür - oder dein Onkel, weil's ja mehr nach "Schwarzarbeit" klingt.

Nächstens kümmer dich um Intrusion Detection... Wie erkennst du Angriffsversuche.

Lies dich parallel echt mal in das Konzept von Standby-Databases ein - VirtualIP wird bei dem Provider ja so nicht möglich sein. Du verlierst minimst Performance - gewinnst aber gute Backup-qualität.

Transparentes Failover wird hier eh unmöglich sein (weil gemietet) - willst du wirklich drauf verzichten ? Sooo hoch sind die Kosten fürs housen net - und ich vermute mal, daß es auch Mietserveranbieter gibt, die das ermöglichen.

Wenn du das hast - kümmer' dich echt um deine Mail-Config. Sonst haben wir nur einen Spam-Server mehr (praktischerweise wohl schnell angebunden).

Die ganzen Standard-PHP-Hacks hast übrigens eh unterbunden, oder ? Beginnend mit register_globals in der php.ini, ... - glaub mal schon.

Nochmal zur DB: Welche Normalform hast echt gewählt ? Wenn nicht die dritte... mußt du genau wissen, was du tust - oder du solltest da noch was ändern...

Nutze das echt als Anlaßfall und acker' dich von unten nach oben durch. Wenn Teile davon durch das Mieten eh schon "outgesourced" sind - Umso besser, prüfe es nur nach ;-)

Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
 

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung