[linux-l] Virtualisierung

[Steffen Dettmer]

* Volker Grabsch wrote on Tue, Jun 13, 2006 at 14:35 +0200:
> > Es ist wohl kein echtes MS-Produkt, sondern ein Sybase-Abkoemmling,
> > und, nach Meinung des DBA daher besser als jedes ihm bekannte
> > MS-Produkt.

Soweit ich gehört habe, geht dass, was mit MS SQL geht, wohl in der
Regel ganz gut. Hatte mal ein paar SQL Server 7 Handbücher "gelesen",
war damals noch recht beschränkt. Warum man es nicht auf NT4 Workstation
sondern nur auf NT Server installieren kann, weiss wohl nur das
Marketing. Mein Problem war damals eigentlich nur, dass sich wohl einige
"Spezifika" (Bugs) von MS SQL, DAO und MS Access gegenseitig
neutralisiert hatten - eine prima Gelegenheit, unportabel zu schreiben.
Tauschte die DB, geht's nicht. Tauschte DAO oder Access, geht's nicht.
Nimmste PostgreSQL und ODBC, gehts auch unter Windows. Weiss nicht, ob
das Zufall ist, einige Artikel im Internet suggerierten ja eine gewisse
Systematik :)

> > Nach ein paar Jahren Solaris-Oracle-Servern war Linux+freie
> > Datenbanken nicht so richtig ueberzeugend. 

:) Ja, es gibt Grenzen, find ich auch.

Wobei für mich die Frage bleibt, ob Orcale "besser" ist, als DB2. Dachte
immer, DB2 ist der Stern am DB Himmel. Stimmt das nicht? Kennt jemand
DB2 /und/ Oracle? Ich kenn ja beide nicht. Und könnte das wohl auch
nicht einschätzen, klar.

Bei PostgreSQL finde ich nervig, dass man so ein vacuum machen muss.
Eigentlich ganz easy, ich hab nachts vor und hinterm Backup immer
einfach ein vacuum gemacht, aber irgendwie fehlte das wohl oft (und
möglicherweise sind nicht alle Admins in der Lage, einen Cronjob zu
machen, der täglich ein Programm startet. Was man IMHO PostgreSQL nicht
wirklich vorwerfen kann ;)).

> > Und auch nach den letzten Monaten, feststellend, dass es keinen
> > vernuenftigen Weg ausser einer Neuinstallation von Red Hat gibt, von
> > 3.0 zu 4.0 zu gelangen, was bei nur remote erreichbaren Servern
> > schwierig ist, bin ich nicht uebermaessig begeistert.
> 
> Ja, das ist wirklich traurig. Ausgerechnet diese schlecht
> update-baren, schweineteuren Distros werden meist nur unterstützt.
> 
> Dabei würde ich behaupten, Debian/Stable wird sogar länger gepflegt
> als die SuSE- und RedHat-Sachen. Und die Debian-Distros leben länger.

Na ja, ein klassisches Phasenmodell-Release ist ja für /genaue eine/
Platform, und zwar die, auf der man getestet hat. Automatische Updates
"gehen" da eigentlich gar nicht, weil man ja alle möglichen
Kombinationen testen müsste.

(ist mir klar, dass das weder der einzige noch der beste Weg ist)

> Und dass dort eher "ältere" Software läuft, dürfte doch nur in derem
> Interesse liegen .. aber naja, auch hier geht es wohl eher im Macht-
> und Marktanteile als im Qualität. *sigh*

Oder um Geld/Kosten und "Reputation". Obwohl ich es komisch finde (wenn
ich mal den grossen Distros glauben soll), warum ein Linux so schlecht
werden muss, wie Windows, um sich durchzusetzen. Na ja, egal.

> Würden sie Debian unterstützen, würden sich wohl die Kunden beschweren,
> warum sich das gesamte System so nahtlos upgraden lässt, nur Oracle
> ständig Ärger macht. ;-)

Das wäre wirklich denkbar. Obwohl ich auf einem produktiven
Datenbanksystem sicherlich keine automatischen Updates einspielen
würde...

> Ja, das kenn ich. Wenn man Glück hat, findet man es in ner halben
> Stunde, aber es kann sich auch viele Stunden hinziehen, bis der Tag
> im Eimer ist, und man über Nacht erstmal wieder Ideen sammeln muss,
> bis es am nächsten oder übernächsten Tag endlich wieder klappt.

oder man gibt nach einer Woche auf...

> > Das war vor drei, vier Jahren ein - fuer uns damals wichtiger - Vorteil 
> > von MySQL verglichen mit PostgreSQL.
> 
> schwer sich die Leute getan haben? ... mittlerweile sehe ich das anders:
> Ein CGI-Script sollte unter dem entsprechendem User laufen, und passwortlos
> an Datenbank und Mailsystem herankommen - natürlich nur auf die Bereiche
> des entsprechenden Users.

Wir haben so ein DB Frontend CGI Script, dass verwendet die von User
eingegebenen Daten als Datenbank-Login. Find ich Klasse! Da kann man
dann ggf. über Rules/Trigger nette Sachen machen und nur die Admins
(nicht DB Admin, sondern die laut Frontend/DBconfig) dürfen bestimmte
Aktionen machen. Meldet man sich mit pgaccess oder so an, ist es ganz
genauso. Find ich prima.

Sonst müsste ja jeder User "sein" CGI starten. Überhaupt erstmal ein
$HOME haben usw.

> Aber PostgreSQL kann ich nicht flächendeckend einsetzen, die meisten
> programmieren direkt gegen die MySQL-API. *sigh*

die mySQL API ist nicht SQL? Fein, wurde wieder ein MS Konzept
übernommen :-) SCNR.

> Du siehst, ich kümmere mich eher um klassisches Hosting und kleinere
> Sachen. PostgreSQL finde ich viel angenehmer und einfacher zu
> administrieren als MySQL (z.B. hat PostgreSQL Kommandozeilen-Befehle
> create_user, create_db, ... phpMyAdmin finde ich zu umständlich) Ein
> "perfektes" Hosting-System sollte meiner Meinung nach PostgreSQL mit
> Ident-Authentifikation (und natürlich nur-lokalem Zigriff) haben.
> Web-Applikationen sollten sich weder um Datenbank-Passwörter noch um
> Mail-Passwörter kümmern müssen.

Für mich sind Web-Applikationen einfach nur Applikationen (die zufällig
vielleicht HTML erzeugen). Wenn ich mich da anmelden muss, find ich das
eigentlich logisch, den gleichen User in der DB zu nehmen. Wenn man
keine Passwörter speichern müssen möchte, kann man auch gleich das PW
nehmen. Für'n Hoster würde das natürlich bedeuten, dass man eine
Datenbankinstanz pro "Kunde" braucht (weil der ja User anlegen können
muss). Weiss nicht, was ich heute kriegen würde, wenn ich ne DB
"bestelle". Hab ich dann einen festen User, eine PostgreSQL DB wo ich
immerhin noch Tabellen selbst anlegen kann? Oder kann ich x-DBs mit
x-Usern erzeugen? Hängt vermutlich stark vom Preis ab. Und natürlich von
der Anwendung! Ich glaube, 90% der PHP-Script-LAMP (würg) Konstruktionen
braucht eigentlich keine Datenbank und wäre ohne besser dran und wenn
man eine DB nimmt, sollte man sie richtig benutzen. Aber das ist ein
anderes Thema :)

> (Ausnahme ist natürlich der Zugriff auf z.B. fremde Mailfächer, aber
> dafür gibt's ja dann den normalen Weg über IMAP ... eine der besten
> Eigenschaften von Squirrelmail ist IMHO, dass es nur via IMAP mit dem
> Server kommuniziert, und daher nahtlos in jedes noch so komplexe Mail-
> System integriert werden kann)

... Es sei denn, Du braucht den Exchange-Kalender, weil da angeblich
ständig (ca. einmal im Monat und dann falsch) was einträgt SCNR.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.