AliCremerU333

Ist normal. Bei mir war es aber ein Nullsummenspiel. Zuerst habe ich die FULLTEXT-Indizes in normale Indizes umgewandelt und dabei ca. 40% bis 50% an Speicherplatz für diese Tabellen in der DB eingespart. Nach der Umstellung auf InnoDB wurden diese Einsparungen wieder verbraucht. Jetzt wird bei mir ungefähr genauso viel Speicherplatz belegt wie vor der Umstellung unter Verwendung von Volltextindizierung. Übrigens scheint Puretec den für die Indizes benötigten Speicherplatz nicht in die max. DB-Größe einzurechnen. Bei den Quota-Ergebnissen und der Anzeige des noch freien DB-Speicherplatzes wird bei mir jedenfalls nur der Verbrauch der eigentlichen Tabellen und nicht deren Indizes angerechnet (habe ich doch gleich mal mit und ohne Indizes nachgerechnet). Der zusätzliche Speicherplatzverbrauch von InnoDB ist ebenfalls nicht enthalten. Gruß, AC

Du solltest aber bedenken, daß derzeit nur geplant ist, im Januar eine erste Version zu veröffentlichen. Das ist dann die erste Beta (von x Betas und RCs) und nicht die Final! Bis die Final fertig ist, dauert es noch etwas länger. Gruß, AC

Ungetestet ist da überhaupt nichts. Bugs sind heutzutage Normalität. Leider! Ich möchte mal diejenige komplexe Software sehen, die keine Bugs oder Sicherheitslücken hat. Das ist beim Umfang des Programmcodes schlichtweg unmöglich! Man kann nur versuchen, die Anzahl Bugs zu minimieren. Genauso wenig wie es absolute Sicherheit gibt, gibt es bugfreie Software. Entwickler werden wissen, was ich meine. Und ein Hoster muß bei jeder neuen Version von MySQL / PHP / etc. erstmal aus den Sourcen die individuell angepaßten Binaries kompilieren. Kein (seriöser) Hoster benutzt vorkompilierte Binaries (sofern es diese für die benutzte Plattform gibt), da diese nicht auf die individuellen Notwendigkeiten und Bedürfnisse angepaßt sind und i.d.R. diverse zusätzliche Funktionen, die zusätzlich einkompiliert werden müssen, nicht beinhalten (z.B. bei MySQL: Unterstützung für transaktionssichere Tabellentypen). Da wird wirklich alles bis zum Erbrechen ausgetestet, protokolliert und analysiert, bevor eine Umstellung für die Kunden gefahrlos und für den Hoster bis auf's letzte Detail optimiert stattfinden kann. Gruß, AC

Ich ebenso. Diesen Editor hätte ich auch gern unter UNIX, bin aber nach wie vor (seit Jahren) auf der Suche nach einem wirklichen Äquivalent. So mächtig emacs & Co. auch sein mögen, genauso unkomfortabel und aufgebläht sind sie. Wenn ich allein schon an die Tastenkombinationen denke, kann ich nur noch mit dem Kopf schütteln. Sowas hat mit Usability einfach nichts mehr zu tun. Wenn jemand einen Editor für UNIX kennt, der sehr nahe an UltraEdit herankommt, der möge bitte laut "hier" schreien und mich von meiner Qual befreien. Danke! Gruß, AC

Puretec wird die Umstellung nur aus einem einzigen Grund gemacht haben: Performance. Die MySQL-Server waren schon immer stark ausgelastet. Und da MySQL 4 nicht nur schneller, sondern auch ressourcenschonender ist, konnten die Admins bei Puretec wohl nicht widerstehen. Mir wäre es auch lieber gewesen, sie hätten noch etwas länger mit der Umstellung gewartet. Sonst ist man bei Puretec in solchen Dingen auch etwas konservativer gewesen ... Bei mir ist er seitdem nicht mehr aufgetreten. Keinerlei Probleme mehr ... Gruß, AC PS: Die sind gerade fleißig beim Updaten. Auf meinem zweiten MySQL-Server läuft bereits 4.0.16, auf dem ersten noch 4.0.15a. Wer weiß, ob der Fehler in 4.0.16 schon gefixt ist. Ich bleibe auf jeden Fall bei InnoDB.

Hallo Christian, wie immer auch hier ein guter Mod! Hab ihn bei mir auch eingebaut. Kleiner Weiterentwicklungsvorschlag: Wie wäre es mit einer Möglichkeit der Zugriffsbeschränkung, z.B. Option "kein Gastzugriff"? Nebenbei: Ist die Reihenfolge 1. Anzahl Postings, 2. Titel / Rang, 3. Grafik / Pips nicht etwas sinnvoller (Bsp.: http://www.u-boote-forum.info/index.php?act=dienstgrade )? Aber kann ja eh jeder im Skin ändern, wie er will ... Gruß, AC

Hihi! Ja ja, Andy, mit der Ironie ist es so eine Sache, nicht wahr? *tropf*tropf*tropf*ausgeruscht* *ggggggggggg

Er braucht die Ersteller von Mods nicht zu fragen, da er nicht einen einzigen Mod von ihnen eingebaut hat. Die Tatsache, daß eine neue Boardversion nun über neue Funktionen verfügt, die vorher nur von einigen Leuten als Mod entwickelt wurden, heißt noch lange nicht, daß diese neuen Funktionen durch den Einbau dieser Mods in das Projekt realisiert wurden. Laut Matt's eigener Aussage hat er noch nie fremden Programmcode ins IPB übernommen. Wenn ihm ein Feature, das im IPB noch nicht integriert war, als sinnvoll und nützlich erschien, dann hat er sich hingesetzt und die Funktionen selbst geschrieben. Damit ist außerdem sichergestellt, daß es wirklich in die gesamte Programmstruktur optimal paßt und vernünftig programmiert ist. Und nicht selten ist die Umsetzung von Matt für eine positive Überraschung gut. Gruß, AC

Ich glaube, Matt braucht einfach den Druck. Wenn man über eine so lange Zeit fast jeden Tag an einem Projekt arbeitet, hat man irgendwann auch mal eine Nullbockphase. Und wenn ihn dann die nervenden User "treten", rafft er sich wieder auf. Und nichts ist motivierender als positives Feedback ... Und Matt wird mit Sicherheit noch das eine oder andere Schmankerl einbauen. Und solange alles als Option an-/ausschaltbar ist, braucht sich niemand zu beschweren. Wer etwas nicht haben will, der aktiviert es einfach nicht. Fertig! Wo ist das Problem?! Ich persönlich freue mich bei fast jeder neuen Version über die immer geringere Notwendigkeit, zusätzliche Mods einbauen zu müssen. So langsam werden die meisten Wünsche erfüllt. Allerdings gefällt mir der Skin der 2.0-Alpha genauso wenig wie die bisherigen IPB-Skins. Aber ist mir auch egal, da ich sowieso meinen eigenen Skin entwerfe und einsetze ... Gruß, AC

Siehe hier: http://www.ipbsupport.de/board/index.php?showtopic=98 Gruß, AC PS: Vielleicht schreibe ich mal ein kleines Tool zum Testen, zur Konvertierung, etc. Das könnte dann auch wunderbar mit meinem Backup-/Restore-Tool für große Datenbanken verbunden werden.

Wenn Schreibvorgänge in Tabellen der Datenbank nicht beendet werden, dann kann (und wird) es zu Datenverlusten bei nicht transaktionssicheren Tabellentypen (wie MyISAM) kommen. Das betrifft dann die jeweiligen Einträge, auf die schreibend zugegriffen wurde. Das ist aber kein Problem des Boards, sondern des MySQL-Daemons. Gerade die MySQL-Version 4.0.15a (und Vorgängerversionen) hat einige Bugs, die den mysqld-Prozeß abstürzen lassen. Wenn dies während eines Schreibzugriffes passiert, dann kommt es eben zu Datenverlust. Das kann in verschiedenen Formen passieren, z.B. defekte Tabellen, die repariert werden müssen oder z.B. das Fehlen eines vorher vorhandenen Eintrags in einer Tabelle etc. Bei MySQL 4.0.15a werden manchmal einzelne Einträge gelöscht, die im Board dann z.B. ein Forum oder ein Thema "verschwinden" lassen. Eine Lösungsmöglichkeit, bis die Bugs in MySQL irgendwann einmal beseitigt sind, ist das Umstellen der Tabellen in der Datenbank auf einen transaktionssicheren Tabellentypen (vorzugsweise InnoDB). Selbst wenn der mysqld-Prozeß hängen bzw. abstürzen sollte während eines Schreibzugriffes, kommt es dann zu keinem Datenverlust, da die Daten (z.B. durch Rollbacks) wiederhergestellt werden. Deshalb heißt dieser Tabellentyp ja auch transaktionssicher. Es wird dafür nur etwas mehr Speicherplatz benötigt, was aber gut zu verschmerzen ist. Ich kann jedem, dessen Hoster MySQL ab Version 4 einsetzt, nur dringend empfehlen, eine Umstellung auf den transaktionssicheren Tabellentypen InnoDB durchzuführen. Ich habe damit nur gute Erfahrungen gemacht und bin von den zahlreichen MySQL4-Problemen seitdem verschont geblieben und hatte seitdem auch keinerlei Datenverluste mehr. Und einen Performance-Unterschied, den man evtl. wegen des Transaktionsoverheads annehmen könnte, gibt es in der Praxis auch nicht. Gruß, AC PS: Die fehlende Unterstützung von Volltext-Indizes kann man ebenso gut verkraften, da man aus dem FULLTEXT-Index einen normalen Index machen kann und in der Praxis keinen Unterschied merkt. Und das, was InnoDB mehr an Speicherplatz benötigt, wird durch die Einsparung des viel Speicherplatz verbrauchenden FULLTEXT-Indexes wieder ausgeglichen. Im Endeffekt ist die DB-Größe dann ungefähr genauso groß ... ;)

Hallo Silaz, auch von mir alles Gute zum Geburtstag und viel Spaß beim Feiern! Gruß, AC

Macht nichts, war ja schon etwas spät. Übrigens ist die Umstellung auf InnoDB gerade für sehr große Boards mit sehr hohen Zugriffszahlen und großer Datenbank zu empfehlen, da gerade bei diesen Boards die Vorteile transaktionssicherer Tabellentypen wie InnoDB besonders zur Geltung kommen, vor allem bei hoher Serverlast. Gruß, AC

Da scheinst du jemanden an der Strippe gehabt zu haben, der nicht wirklich Ahnung hatte und nicht wußte, worum es hier eigentlich geht. Ich glaube, die denken, mit den meisten "dummen" Kunden können sie es ja machen. Genauso glaube ich, daß im Kundensupport viele Leute sitzen, die schlichtweg inkompetent sind. Habe da so meine eigenen Erfahrungen machen und teilweise erstmal eine Lehrstunde erteilen müssen. Interessanterweise werden die Leute dann immer sehr ruhig und klein, wenn sie merken, daß man selbst erheblich mehr Wissen und Know How hat, als sie selbst. Mir hatte man übrigens am Telefon gesagt, daß bereits viele Kunden angerufen und sich über dieses Problem beschwert hätten, daß es sich hierbei um einen Bug in der MySQL-Version 4.0.15a handelt und daß eben nicht die Anwendersoftware daran schuld ist, da dieser Bug in vielen Konstellationen auftritt und nicht nur bei einer Board-Software. Der Hoster schiebt i.d.R. sehr gerne grundsätzlich die Schuld auf die Anwendersoftware und weist jegliche Verantwortung von sich. Dieses Verhalten geht mir extrem gegen den Strich, da es sich nachweislich wirklich um einen Bug in der MySQL-Version handelt. Und was mich dabei am meisten stört, ist, daß man viel zu früh auf eine noch völlig verbugte, instabile und unausgereifte MySQL-Version umgestellt hat, die nunmal wirklich nicht für den produktiven Einsatz geeignet ist. Gruß, AC

Du könntest den Zugriff auf die conf_global.php (und auf das Backup der Datei) und auf die admin.php sichern, indem du entsprechende Einträge in deine .htaccess-Datei machst: AuthType Basic AuthName "Restricted File" AuthUserFile /path/.htpasswd <Files admin.php> require valid user </Files> <Files conf_global.php> require valid user </Files> <Files conf_global-bak.php> require valid user </Files> In deiner .htpasswd-Datei muß dann natürlich ein entsprechender User mit Paßwort angegeben sein. Dieser Dateischutz sorgt dafür, daß bei direktem Zugriff über einen Browser erstmal eine Authentifizierung stattfindet, bevor der Zugriff gestattet wird. Bei der conf_global.php erfolgt zwar keine Ausgabe. Aber sollte mal der Webserver durch einen Fehler ohne PHP-Interpreter laufen (dürfte eigentlich niemals passieren, habe ich aber leider schon mal beobachten müssen), dann wird durch diesen Schutz verhindert, daß diese Datei im Browser als Textdatei ausgegeben werden kann (wenn man sie direkt aufruft) und jeder die DB-Zugangsdaten sehen kann. (Eine vom PHP-Interpreter nicht geparste php-Datei wird im Browser als Text ausgegeben, da eine PHP-Datei nichts anderes als eine Textdatei ist.) Und wenn man sich ins ACP einloggen will, muß man zunächst User + Paßwort angeben, bevor man zur IPB-Login-Seite für das ACP kommt. Mag auf den ersten Blick etwas umständlich sein, sich zweimal zu authentifizieren. Es hat aber den Vorteil, daß kein direkter Brute-Force-Angriff auf den ACP-Login möglich ist, da zunächst die erste Hürde, die Authentifizierung über den Apache-Webserver, zu nehmen ist, was bei vernünftiger Konfiguration des Webservers eigentlich nicht möglich ist. Damit kann man relativ ruhig schlafen, selbst wenn der ACP-Bereich Sicherheitslücken aufweisen sollte, was man nie wirklich ausschließen kann. Außerdem kannst du die Dateirechte der conf_global.php und conf_global-bak.php auf 600 setzen. Damit kann nur noch das Script auf diese Datei zugreifen. Ich persönlich habe den Sourcecode bei Änderungen dieser Datei dahingehend geändert, daß auch nach den Änderungen die Rechte bei 600 bleiben. So muß ich nicht nach jeder Änderung die Rechte manuell von 777 auf 600 zurücksetzen. Gruß, AC

Die o.g. Angabe bezieht sich auf den von InnoDB derzeit reservierten Tabellenplatz, und zeigt an, wieviel von diesem Tabellenplatz derzeit noch für Operationen zur freien Verfügung steht. Das heißt aber nicht, daß die Tabelle nur noch maximal die angegebene Größe des freien Speicherplatzes einnehmen kann, da die Segmente / Daten-Dateien aneinander gehängt / miteinander verknüpft werden und bei Bedarf der eigentliche Tabellenplatz automatisch vergrößert wird. Die Tabellen können also auch erheblich größer werden ... InnoDB hat eine ganz spezielle Speicherplatzverwaltung. Der Hoster muß für InnoDB spezielle Optionen in der Konfigurationsdatei angeben, die u.a. die Größe der Daten-Dateien auf dem Server beeinflussen. (Das sind aber alles Einstellungen, die der Administrator eines DB-Servers zu tätigen hat und den Anwender i.d.R. nicht zu kümmern braucht.) Auf die MySQL-Systemtabellen hat man als Anwender sowieso keinen Zugriff. Das ist eigentlich nur für den Admin des Hosters interessant (oder bei lokalen MySQL-Umgebungen auf dem eigenen Rechner), nicht für die User, die lediglich eine Datenbank bei einem Hoster benutzen. Gruß, AC

Auuuuuutsch, du bist ja brutal ... *g

Auch ein sehr leistungsstarker Editor ist UltraEdit inkl. Syntax Highlighting für diverse Programmiersprachen, dateiübergreifendes Suchen + Ersetzen, Dateienvergleich, internationaler Sprachunterstützung, Unterstützung für UNIX- / Mac- / DOS- / Win-Dateiformate inkl. Konvertierung u.v.m. Zu beziehen über http://www.ultraedit.com/ . Ist zwar Shareware, aber die paar Euros lohnen sich auf jeden Fall. Bin äußerst zufrieden mit dem Programm! Gruß, AC

...

Vielen Dank für das Lob! Meine Erfahrungen damit (als Admin) sind durchweg positiv. Ich hatte lange Zeit den Gästen umfassende Leserechte eingeräumt. Bis auf eine gewisse Zahl an Stammpostern stagnierte aber die Mitgliederzahl mehr oder weniger. Da allerdings der Gastzugriff auf das Board sehr hoch war, habe ich daraus geschlossen, daß trotz der geringen Mitgliederzahl scheinbar dennoch viele Leute großes Interesse an den Themen und Beiträgen im Board haben. Also bot sich diese Maßnahme an, solange für Gäste die Mehrzahl der Foren sichtbar sind und durch die im Index angezeigten Thementitel die Neugierde erhalten bleibt. Und sofort nach dem Entzug der Leserechte für Gäste stieg die Zahl der Registrierungen stark an. Mittlerweile kann ich es mir sogar leisten, völlig inaktive Mitglieder nach einer gewissen Zeit automatisiert zu löschen. Wer Mitglied bleiben möchte, kann entweder posten oder wer nur mitlesen möchte, kann sich in einem speziellen Thread verewigen und sich somit selbst aus dem Delete-Task entfernen. Funktioniert wunderbar. Ups, danke für den Hinweis! Das habe ich wohl übersehen. Werde ich noch ändern. Nö, ist immer auf dem Stand des letzten aktuellen Final-Releases. Ist von mir eben nur individuell geskinnt, modifiziert und erweitert worden. Hihi, und hier fängt schon der IPB-Support an (bitte nicht übelnehmen): Es ist alles mit Bo(a)rdmitteln zu reparieren ... ähm einrichtbar und das schon seit IPB 1.0. Gruß, AC

Da kann ich dir nur zustimmen. Wäre für mich persönlich auch ein Grund, wieder aktiv am Support teilzunehmen, was ich bei ibforen vor langer Zeit aus gewissen Gründen nicht mehr tat. Mal schauen, wie sich dieses Board hier entwickelt. Gute Voraussetzungen sind jedenfalls schon jetzt vorhanden. Mit ein bisschen Glück bringen wir das Schiff schon in den Hafen! Gruß, AC

Ja, man muß sich erstmal etwas daran gewöhnen (und es natürlich zunächst erstmal mitbekommen). Ist aber kein Problem für mich. "Andy" klingt besser, wirkt seriöser und ist persönlicher ... Gruß, AC

Allerdings!!! Siehe Website Die Grauen Wölfe - Deutsches U-Boot- und Marine-Forum. Mit solcherlei Gruppierungen, wie die von dir erwähnte, und deren krankhaften Gedankengut haben weder ich noch mein Team noch meine Mitglieder etwas am Hut. Da passe ich strengstens auf! (Siehe unter Board-Regeln.) Gruß, AC

Na dann möchte ich auch mal meinen Wunsch loswerden: Die Grauen Wölfe Vielen Dank! Gruß, AC

Moin moin, nach den bekannten Vorfällen habe ich mich schon gefragt, wann ein neues deutsches Support-Board eröffnet wird (mit den entsprechenden Team-Mitgliedern). Und nun sehe ich die Antwort. Dann wünsche ich für den Anfang erstmal alles Gute, viel Erfolg und die berühmte Handbreit Wasser unter'm Kiel! Gruß, AC