Viele viele iPhone-Besitzer möchten gerne die Wartezeit bis zur finalen Version überspringen und jetzt schon 4.0 auf ihr iPhone spielen, fast genau so viele machen es auch. Einige davon bezahlen sogar Geld an andere, damit sie den Link für die Beta bekommen, darunter gibt es einige arme Vögel, die nicht wissen, dass die Beta irgendwann abläuft. Bisher überwiegen meiner Ansicht nach ganz klar die Nachteile für Endanwender: viele Bugs, viele Apps funktionieren nicht mehr, es gibt nur einen schweren Weg zurück zu 3.x, kein Jailbreak (wer’s denn braucht), …

Die Vorteile halten sich in Grenzen:

• Multitasking
  Programme werden an der Stelle fortgesetzt, an der Sie beendet wurden. Super? Nein, ich habe noch kein Programm gefunden, bei dem das so richtig Sinn macht, bisher ist es nur die Abkürzung, dass man nicht den Home-Screen braucht, um eine App zu starten – ein doppeltes Drücken öffnet die Liste aller offenen Programme. Wenn das gewünschte nicht schon offen ist, bringt’s auch nichts. Nervig wird’s dann auch ganz schnell: alle Programme, die man mal öffnet, befinden sich jetzt in der besagten Liste, man kann sie zwar komplett beenden, aber das ist umständlich und Zeitaufwändig. Was hier meiner Meinung nach fehlt ist die Möglichkeit ein Programm so zu beenden, dass es nicht im Speicher abgelegt wird, denn die Liste wird ganz schnell voll und unübersichtlich.
• Ordner / Kategorien für Apps
  Wirklich praktisch, aber hier kommt’s manchmal zu Bugs, die nur ein Neustart wieder behebt. Außerdem sollte man nicht in iTunes auf die Programme gehen, denn das kennt diese Funktion noch gar nicht – alle Ordner werden direkt gelöscht und alle Apps fliegen wieder in der Gegend rum.
• Gemeinsamer Posteingang, Thread-Sammlung
  Großartig! Zwar gibt es manchmal Probleme beim Verbinden zu einigen Mailservern, aber vor allem das Gruppieren von zusammengehörigen Nachrichten ist sehr praktisch und übersichtlich.
• SMS Zeichen Zählen
  Naja, jetzt weiß ich wie viele Zeichen ich in einer SMS tippe, das macht den Text nicht automatisch kürzer… Da freuen sich aber wahrscheinlich alle, die lieber lange SMS schreiben als kurz zu telefonieren. (Wenn zwei Parteien iPhones (oder auch Blackberrys, oder auch gemischt) haben, kann ich nur What’s App empfehlen!)
• Hintergrundbild für den Home-Screen
  … unnötig.
• Fotos App
  Ein paar neue Funktionen, besser sortiert, aber auch hier wieder einige Bugs.
• iPod
  Spielt nicht immer, was man will
• Kamera: Zoom
  Schlechte Bildqualität, Digitalzoom halt… lieber näher an’s Ziel gehen…

Viel mehr wird einem nicht auffallen, es gibt noch einige Kleinigkeiten wie die leichtere Zugänglichkeit von Umlauten, Klingeltöne für einzelne Kontakte, usw. – aber dafür eine Beta auf dem Gerät laufen lassen, dass man so oft benutzt und oft auch unbedingt braucht? Muss jeder für sich selbst entscheiden, ich kann nur davon abraten. Wem die Nachteile bewusst sind und wer weiß, was Beta bedeutet – viel Spaß mit iPhone OS4.0!

SVN bietet dazu sogenannte Hooks, die bei verschiedenen Events Skripts ausführen. Templates für Hooks befinden sich bereits im SVN-Repository unter /hooks/ – in diesem Beispiel wird ein Checkout in ein definiertes Verzeichnis ausgeführt, sobald ein Commit / Update erfolgt ist.

Dazu sind folgende Schritte notwendig:

1. Template “post-commit.tpl” in “post-commit” umbenennen
   cd SVNREPO/hooks/
mv post-commit.tpl post-commit
2. post-commit So anpassen, dass das “SVNREPO/hooks/bin/autocheckout.sh” Skript ausgeführt wird
   [...]
REPOS="$1"
REV="$2"#commit-email.pl "$REPOS" "$REV" commit-watchers@example.org
#log-commit.py --repository "$REPOS" --revision "$REV"
${REPOS}/hooks/bin/autocheckout.sh "$REPOS" "$REV" trunk/ /WEBROOT/MEINPROJEKT
   Die im Template vorhandenen zwei Befehlsaufrufe werden auskommentiert.
3. autocheckout.sh erstellen
   mkdir bin/
wget http://palita.net/blog/wp-content/uploads/autocheckout.txt bin/autocheckout.sh

   Anmerkung: Dieses Skript wurde übernommen von http://larve.net/people/hugo/2007/05/svn-auto-look-and-checkout
4. autocheckout.sh und post-commit anpassen
   chmod a+x post-commit bin/autocheckout.sh
5. Initiales Ausführen & Testen
   sudo -u apache env - ./post-commit WEBROOT/MEINPROJEKT 234
   (234 durch die aktuelle Revision ersetzen, apache durch den Benutzer ersetzen, der Schreibzugriff auf das Webroot hat.)
6. Commit & Test!

Unter Plesk 9 funktioniert es einwandfrei, jedoch muss dafür eventuell das Webverzeichnis mit Schreibrechten für den Benutzer “apache” versehen werden.

Weblinks:

• SVN-Hooks FAQ
• Hook-Debugging FAQ
• Trac

Procmail ist ein Mailprozessor, der zum serverseitigen Filtern von Emails eingesetzt wird. Um einen Procmail-Filter bei einer QMail-Umgebung (sowohl procmail als auch qmail sind bei Plesk standardmäßig integriert) aufzusetzen, bewegt man sich erst mal ins Verzeichnis des Mailnamen.

Für email@domain.com etwa
cd /var/qmail/mailnames/domain.com/email

In diesem Verzeichnis mit dem bevorzugten Editor (vi / nano / …) eine Datei .procmailrc erstellen, und folgenden Inhalt zur Filterung von Server-Mails erstellen:
# .procmailrc
MAILDIR=/var/qmail/mailnames/domain.com/email/Maildir
DEFAULT=${MAILDIR}

# Filter Servermails
:0:
* ^From.*@NERVIGERSERVER.COM
.VERZEICHNIS/new

Dabei NERVIGERSERVER.COM durch die Domain ersetzen, von dem der Server seine Mails sendet, und VERZEICHNIS durch das IMAP-Verzeichnis, in das die Nachricht verschoben werden soll. /new sollte dabei stehen bleiben.

Jetzt die Datei speichern, und die Datei .qmail im selben Verzeichnis editieren.

Die etwa so aussehende Datei

| true
| /usr/bin/deliverquota ./Maildir


wird jetzt so abgeändert, dass neue Emails nicht mehr an Deliverquota sondern an Procmail gesendet werden. Der Veränderte Inhalt der Datei dazu wäre etwa

| true
#| /usr/bin/deliverquota ./Maildir
| preline /usr/bin/procmail -m .procmailrc

Mehr muss nicht unternommen werden. Man sollte natürlich erst mal Testen ob es funktioniert, bevor man sich darauf verlässt, bevor keine Mails mehr ankommen, unter CentOS 5 und Plesk9 sollte es nach dieser Anleitung gar keine Probleme geben. Bei anderen Systemen sind die Pfade eventuell abweichend.

Procmail kann natürlich noch viel mehr, die manpage von procmailex(5) verrät eigentlich alles.

Manpage online: http://www.gsp.com/cgi-bin/man.cgi?section=5&topic=procmailex

Jan 1 00:00:00 hostname qmail-queue-handlers[15388]: possibly qmail-smtpd exited by timeout, reset connection. See "http://pobox.com/~djb/docs/smtplf.html." for get more information.

… hat ein kleines Problem: Emails von einigen Hotmail-Servern werden nicht mehr empfangen. Grund ist ein Fehler der Hotmail-Server, die anstelle vom von QMail erwarteten CRLF (Carriage Return & Line Feed) nur ein LF am ende einer jeden Zeile bekommt. Die Lösung steht bereits in der Plesk Knowledge-Base:

1. Download und compilieren von ucspi-tcp sources:
   http://cr.yp.to/ucspi-tcp/ucspi-tcp-0.88.tar.gz (Quelle und Anweisungen: http://cr.yp.to/ucspi-tcp/install.html)
2. Dateien entpacken und in das neue Verzeichnis wechseln:
   tar xfz ucspi-tcp-0.88.tar.gz
   cd ucspi-tcp-0.88
3. Benötigt wird daraus die Binary aus fixcrio.c, die aber in der Originalversion kein TLS-Support hat. Also sollte man sich eine gepatchte Version von Parallels herunterladen und mit der Originalen ersetzen:
   http://kb.parallels.com/Attachments/11152/Attachments/fixcrio.c
4. Da sonst wahrscheinlich sowieso ein Fehler auftritt, folgendes in der error.h korrigieren:
   die Zeile
   extern int errno;
   durch
   #include <errno.h>
ersetzen.
5. Compilieren:
   make
make setup check
6. Compilierte fixcrio binary nach /var/qmail/bin kopieren und Rechte an die Anderen Dateien angleichen:
   cp fixcrio /var/qmail/bin/
chmod 555 /var/qmail/bin/fixcrio
chgrp qmail /var/qmail/bin/fixcrio
7. Den Eintrag
   /var/qmail/bin/fixcrio
   In den Dateien /etc/xinet.d/smtp_psa und /etc/xinet.d/smtps_psa vor “/var/qmail/bin/qmail-smtpd” einfügen. smtp_psa sähe dementsprechend so aus:
   server_args = -Rt0 /var/qmail/bin/relaylock /var/qmail/bin/fixcrio /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw /var/qmail/bin/true
8. xinet.d neustarten (service xinetd restart)
9. Fertig

Danach sollte der Fehler nicht mehr auftreten.

Links:

• http://kb.parallels.com/en/6763
• http://cr.yp.to/ucspi-tcp/install.html

Behoben wird der kleine Bug entweder mit sa-update oder auch ganz einfach – folgendes am Ende der local.cnf unter /etc/mail/spamassassin/ einfügen:

score FH_DATE_PAST_20XX 0

Weitere Infos dazu auf der Spamassassin Webseite

Ein PDC ist schnell aufgesetzt und funktioniert problemlos, die Benutzer- und Gruppenverwaltung gestaltet sich sehr simpel.

Weitere Funktionen von ClarkConnect ClearOS:

• Firewall (2 Netzwerkkarten benötigt)
• DHCP-Server (2 Netzwerkkarten benötigt)
• VPN: OpenVPN, IPSec, PPTP
• Proxy, Content-Filter, ACL
• Mailserver mit Antispam & Antivirus
• Groupware
• Apache, PHP & MySQL
• Samba-Server
• FTP-Server
• Printserver
• uvm.

Unter Parallels Desktop und VMWare Server funktioniert bei mir alles einwandfrei, auf einem Test-PC gab es Schwierigkeiten mit dem DHCP-Client, was aber gut an einer defekten Netzwerkkarte gelegen haben kann.

Link: http://www.clarkconnect.com/ http://www.clearfoundation.com/

Wer nicht immer die CD einlegen will, oder einfach kein CD-Laufwerk hat, kann sich einen entsprechenden Eintrag in die menu.lst von GRUB schreiben, um Acronis von der /boot Partition zu starten.

Dazu einfach den Inhalt der Acronis-Boot-CD in einen Unterordner von /boot/ kopieren, z.B. /boot/acronis/ und folgenden Eintrag in der /boot/grub/menu.lst hinzufügen (ganz am Ende):

# Acronis
title Acronis TrueImage
uuid uu81uoi1-12uz39
kernel /boot/acronis/kernel.dat vga=791 ramdisk_size=32768
mbrcrcs=on
initrd /boot/acronis/ramdisk.dat /s
boot

wenn man jetzt Acronis in Grub auswählt, kann man mit dem Befehl

product

das Programm selbst starten, vorher befindet man sich in einer Busybox.

fail2ban:

fail2ban ist ein in der Installation und Benutzung sehr einfaches Tool, geschrieben in Python, um nach fehlerhaften Loginversuchen eine Sperre in iptables einzutragen. Im Daemon-Mode überwacht er Logdateien und kann eine terminierte Sperre eintragen, sodass den Bruteforce-Attacken schonmal gut vorgebeugt ist. Unter Debian / Ubuntu einfach
sudo apt-get install fail2ban
Oder besser: Neueste .deb über die Webseite laden und mit
dpkg -i fail2ban*.deb
installieren.

Unter CentOS auch nicht schwerer: im epel-Repository ist fail2ban enthalten und kann mit
yum --enablerepo epel install fail2ban
installiert werden.

Nach der Installation ist standardmäßig eine Regel für SSH aktiv, einstellen kann man alles unter /etc/fail2ban/jail.conf .

Der Dienst muss noch mit
sudo /etc/init.d/fail2ban start
gestartet werden. Bei einer Sperre wird (sofern jail.conf angepasst wurde) per Email benachrichtigt, außerdem wird es unter /var/log/fail2ban.log geloggt.

/etc/ssh/sshd_config:

eine denkbar einfache, aber auch nicht sehr effektive Methode: SSH-Port ändern. Einfach in der Config “Port 22″ durch einen anderen Port ersetzen – kann aber natürlich durch jeden Portscanner wieder gefunden werden.

Worauf aber unbedingt geachtet werden sollte: Protokoll Version 1 deaktivieren! Version 2 ist wesentlich sicherer. In der Config sollte “Protocol 2,1″ auskommentiert und “Protocol 2″ aktiv sein.

Ebenfalls sehr effektiv: Passwort-Logins deaktivieren und mit Private- und Publickeyverfahren einloggen.

Weblinks:
Main Page – Fail2ban.

PHP Warning: Unknown: open_basedir restriction in effect. File(/var/www/[...]/index.php) is not within the allowed path(s): (h\xc3\x15\x90+\xe4rr\n) in Unknown on line 0
PHP Fatal error: Unknown: Failed opening required '/var/www/[...]/index.php' (include_path='.:') in Unknown on line 0, referer: http://[...]

Damit konnte man erst mal nicht so viel anfangen, vor allem weil der Fehler nicht immer auftrat.

Die Lösung war einfach: PHP wieder auf PHP5.2.10 Downgraden. Aber ein Downgrade mit yum ist zunächst nicht vorgesehen. Auch das yum-Modul AllowDowngrade war dafür nicht geeignet. So weit auch noch kein Problem: PHP löschen, PHP installieren und 5.3 verbieten, zum Glück ist die 5.2 ja noch im Repository. Ging aber auch nicht: hätte ich PHP gelöscht, wären viele andere Pakete auch gelöscht worden und das alles korrekt und funktionierend wieder herzustellen wäre zu viel Arbeit + zu viel Ausfallzeit.

Also zur gefährlicheren Variante gegriffen: rpm –nodeps. Nicht wirklich zu empfehlen, aber hier ging es leider nicht anders.

Lösung:

-> Gegebenenfalls nachsehen, was von PHP alles in Version 5.3 installiert ist, z.B. mit
yum list installed php* | grep 5.3

PHP-Pakete mit RPM löschen:
rpm -e php-mbstring php-pdo php-cli php-common php-imap php-xml php-mysql php-gd --nodeps

und dann schnell hinterher mit yum nachinstallieren:
yum --enablerepo=remi --exclude=php*5.3* install php php-mbstring php-pdo php-cli php-common php-imap php-xml php-mysql php-gd
service httpd restart

Damit sollten wieder die 5.2er Versionen installiert sein (keine Garantie!!! Kann natürlich auch mächtig schiefgehen!)

Wer ebenfalls das Remi-Repo hat, und auch keine Lust hat auf PHP5.3, kann es in der /etc/yum.conf verbieten:

[main]
cachedir=/var/cache/yum
keepcache=0
[...]
exclude=php*5.3*
# Note: yum-RHN-plugin doesn't honor this.
metadata_expire=1h
[...]

Viel Erfolg