moviez.to – blog

Ein Relaunch mit einem (aus meiner Sicht) schrecklichen Design, ist ja die einte Sache. Aber dann auch gleich noch die beliebte Underground Topliste unangekündigt in ein Blog/Twitter Verzeichnis zu verwandeln die Andere.

Gulli wird zum 0815 Portal – Schade!

Nach dem Gulli Börsen Debakel nun auch noch dies – absehbar war es aber ja schon lange.

Ein Stück Underground ist nun entgültig Geschichte.

Zum Glück gibt es massig Alternativen wie raidrush.ws (diese wirds bestimmt freuen..)

Im Gulli:Board wird desweitern auch schon massiv protestiert – sogar erste Protestgruppen haben sich gebildet.  Ob Gulli dem Druck nachgeben wird? Ich denke nicht.

Gestern haben wir das Burning Board 3.0.9 auf die neue (kostenpflichtige) Version 3.1 updated. Der Preis für dieses Update betrug 49€, welche sich aber alleweil lohnen, wenn man sich die Featurelist anschaut.

Das Update gestaltet sich sehr einfach – im Mitgliederbereich die Update .tar.gz downloaden und im ACP das Burning Board Package auswählen und “aktualisieren” anwählen.  Nun muss die .tar.gz hochgeladen werden und schwup läuft das update schon.

Ich empfehle allerdings, die Kompatibilität der Extensions / Plugins zu überprüfen und diese vorgängig zu deaktivieren, falls (noch) nicht kompatibel. Somit erspart ihr euch eine Menge Ärger.

Mehr zum Update in unserem Board.

Kurzer Tipp des Tages:

Ihr könnt euer LV (logical volume)  bzw. LVM einfach und bequem per:

# lvextend -L+100GB /dev/VGxy/LV1
# resize2fs /dev/VGxy/LV1

vergrössern. Praktisch, nicht?

Kein umounten und weitere nervige Dinge nötig..

Einer der zentralen Punkte eines Webservers ist die Sicherheit des SSH-Logins. Deshalb möchten wir kurz darauf eingehen.  Folgendes Szenario verwendet Moviez.To:

- Fail2ban

- Login per VPN

- SSH-Auth per Keyfiles

Kurz zur Erläuterung:

fail2ban: fehlerhafte Logins werden geloggt und führen ab einer gewissen Anzahl falscher Logins zu einem automatischen Ban der IP in den iptables

VPN: Um sich per SSH auf dem Server einzuloggen, muss zuerst eine VPN Verbindung auf den Server hergerstellt werden.  (nur vordefinierte IP-Adressen können per VPN verbinden)

SSH-Auth per Keyfiles: Login auf dem Server ist nur per Key-File Authentifizierung möglich. Dies bietet zusätzliche Sicherheit, da es eine Bruteforce Attacke praktisch ausschliesst und die das Login nur möglich ist, wenn man im Besitz des PrivateKeys ist.

Dieser Trend zeichnete sich schon vor Jahren ab und geht immer weiter.

Als interessanter Vergleich schicken wir folgende Portale in den Ring:

- die 2. grössten Torrent Portale vs.

- die 2 grössten Filehoster vs.

- die 2 grössten deutschen 1kh Warezsites

Natürlich kommen noch andere Einflussfaktoren dazu:

- Alexa verbesserte seine Traffic-Messwerte (wodurch vorallem rapidshare einbüsste)

- Downtimes (torrent.to, bitreactor, sj)

Insgesammt ist aber der Trend klar, Filehosting legt weiter zu P2P verliehrt an User. Die Gründe sind klar:

- Filehosting ist sicherer

- Filehosting ist schneller

- Filehosting ist bequemer

Darum setzt Moviez.to auch weiterhin auf daruf Und auch unser Alexa Rank kann sich sehen lassen:

in diesem Sinne: Happy leeching!

Mehr zu diesem Thema überigens auf: http://www.gulli.com/news/filesharing-filehoster-verdr-2009-10-12/

Hier eine kurze Zusammenfassung von unserem Backupkonzept:

1) Daily Backup der Datenbank auf externen Server

2) Weekly Backup der kompletten Umgebung auf externen Server

3) Backup des Backupservers auf Backupservers des Hosters

Das ganze läuft per Cronjob, mysqldump, shellscripts und FTP.

Als kurze Beschreibung hier das SQL Backupscript:

date=`date -I`
/path/to/mysql/bin/mysqldump –all-databases -uroot -pPASSWORD | gzip > /path/to/backup/backup-$date.sql.gz

1. Zeile: das Datum wird generiert

2. Zeile: die Datenbank wird gedumpt und zum gewählten Pfad gespeichert: Beispiel des erstellten Filenames: backup-2009-10-09.sql.gz

Damit das täglich ohne Aufwand läuft, wird ein cronjob erstellt, welches das Script automatisch täglich um 1:59Uhr ausführt:

#backup cronjobs
59 1    * * *   root    /home/mysql_backup.sh

Das Backup bringt auf dem Server natürlich nicht viel, wenn der Server komplett crashed oder hochgenommen wird. Daher das Backup auf einen anderen Host:

HOST=’hostname”
USER=’backupuser’
PASSWD=’password’
date=`date -I`
FILE=backup-$date.sql.gz

ftp -n $HOST <<END_SCRIPT
quote USER $USER
quote PASS $PASSWD
put $FILE
quit
END_SCRIPT
exit 0

Und auch dafür wieder ein Cronjob (um 2:59 – damit genügend Zeit bleibt für den SQL Dump)

59 2   * * *   root    /home/ftp_sql.sh

Soweit so gut – jetzt noch das Backup der kompletten Webumgebung:

date=`date -I`
tar –exclude=/directory/to/exclude/from/backup -czf /path/to/backup/full_backup_$date.tar.gz /path/to/store/backup

Die Anpassung für die Crons und FTP-Upload Scripts sind selbsterklärend..

eAccelerator 0.9.6-rc1

The theme of this release is: back to basics! All non essential functions are removed from eAccelerator.

Das tönt doch wunderbar – noch mehr Performance. Natürlich wurde das Teil in der der dev Umgebung ausführlich getestet und es kam zu keinen Problemen. Daher haben wir uns entschlossen, die neue Version zu installieren, auch wenn sie erst ein RC ist. (Somit haben wir nun auch die Möglichkeit auf php 5.3 zu upgraden)

Das Upgrade gestaltet sich einfach:

http://www.eaccelerator.net/wiki/InstallFromSource

phpize
./configure
make
make install
php -v

und schon wissen wir: 

PHP 5.2.10 (cli) (built: Jul 31 2009 23:33:22)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
 with eAccelerator v0.9.6-rc1, Copyright (c) 2004-2007 eAccelerator, by eAccelerator