LG Optimus L3 (E400) – Customizing Hints

Offizielles Material zum E400:
http://www.lg.com/uk/support-mobile/lg-LGE400#manuals

Rooten:
http://gadgetstip.com/root-lg-spectrum-smartphone-method-by-dan-rosenberg/

http://www.mediafire.com/?chbdddn9a02ih5l

ClockWork Mod Recovery via Fastboot einspielen:
http://clockworkmod.com/rommanager

Nandroid Backup erstellen & wegsichern

Image:
Es kommt nur das Modifizieren des StockROMs 2.3.6 in frage, die Batterie hält da am längsten

StockROM – schon gerootet – per CWM flashbar:http://www.shabbypenguin.com/OUDstuff/LG-E400/stockrom+.zip

StockROM – per CWM flashbar:http://www.multiupload.nl/SEC3U8NW54

StockROM – per KDZ Updater flashbar
http://lg-phone-firmware.com/index.php?id_mod=11

App Installationsziel ändern

try using adb shell pm setInstallLocation 2(0/auto, 1/internal, 2/external)
to set back use adb shell --> pm setInstallLocation 0
If your mobile still install to internal memory, reboot it.

OR
Use Link2SD
OR
SD Card Partitioning for Stock ROM (not essential, use without Link2SD App)

described how the partitions should be if you use the LG stock Android rom.
partition #
1 = 10 MB fat16
2 = 1 GB EXT2
3 = fat32

für ICS ROMS sollte ein anderer Kernel zum Einsatz kommen, siehe hier:
http://www.androidworld.it/forum/lg-optimus-l3-259/%5Bkernel%5Doverclocked-1ghz-newgovernor-miuiv4icsmixed-77817/

unroot:
http://www.hackmyandroid.com/how-to-unbrick-lg-optimus-l3-android-phone/1980

OR
unbrick:
http://forum.xda-developers.com/showthread.php?t=883314

weitere hilfe
http://www.android-hilfe.de/lg-e400-optimus-l3-forum/

SPF DNS Record zur Spambekämpfung

Problem:
Ich möchte SPF Policies (http://de.wikipedia.org/wiki/Sender_policy_framework) einsetzen, um Spam zu bekämpfen welcher in meinem Namen verschickt wird bzw werden könnte.

Lösung:
!! Ihr seid selbst für die Modifikationen verantwortlich! Sichert die aktuellen Konfigurationen weg bevor ihr etwas testet! !!

Die validen Mailserver sind via MX Record definiert, mein Webserver, definiert via A Record, darf ebenfalls Mails für die Domain versenden.
Somit sind alle Server im DNS definiert, entweder als A oder MX Record.

Nun kann noch folgende SPF Zeile in die Zonefile eingetragen werden:

@ IN TXT "v=spf1 +a +mx -all"

Der TXT Record ist eigentlich veraltet, man sollte stattdessen SPF schreiben.

@ IN SPF "v=spf1 +a +mx -all"

Mein Provider, Hetzner, unterstützt derzeit leider keine SPF Records. Daher muss ich TXT einsetzen. Jeder sollte selbst prüfen, ob SPF Records unterstützt werden und im Zweifel den TXT Record einsetzen.

Daraus resultiert, dass bei einer Abfrage sowohl die „+a“ Records als auch die „+mx“ Records als valide Versender angenommen werden. „-all“ definiert die verbotenen Absender – also Alle der Zone unbekannten!
Kurzum: Plus erlaubt, Minus verbietet!
Weitere Infos finden sich auf der oben genannten Wiki Seite bzw in den zugehörigen RFCs

Nachdem die Einträge im DNS aktiv sind, kann die Funktionalität über diese Webseite getestet werden.

In das Suchfeld kann direkt via „spf:domain.de“ nach den Einträgen und deren Wirkung gesucht werden.

Tomcat – Redirect auf eine Webapp

Problem:
Ich habe einen Tomcat laufen und im Ordner webapp gibt es nur die eine Webapp. Um die Webapp aufzurufen, muss man den genauen Namen kennen. Ich hätte gerne eine automatische Weiterleitung auf die Webapp sobald ich den Tomcat aufrufe.

Lösung:
Ich erstelle in Webapp einen Ordner ROOT und lege eine index.jsp hinein, welche mich direkt zur Webapp schickt.

mkdir /pfad/zum/tomcat/webapps/ROOT
touch index.jsp

In die index.jsp schreibe ich folgende Zeilen

<% response.sendRedirect("/meineWebapp/login.jsp"); %>

Nach dem Speichern funktioniert die Umleitung direkt, es ist kein Neustart des Tomcats notwendig!

Plesk – Verzeichnis schützen mittels htaccess

Problem:
Ich möchte ein Verzeichnis einer Subdomain über Plesk schützen. Ich verwende Plesk 11.

Lösung:
Im Plesk Backend begebe ich mich zu dem betroffenen „Abonnement“ und verwalte das Hosting, dort gehe ich auf den Reiter „Websites & Domains“. Hier gibt es „etwas versteckt“ den Punkt „Erweiterte Operationen anzeigen“, in dem sich der Menüpunkt „Passwort-geschützte Verzeichnisse“ befindet.

Hier kann man nun die Domain/Subdomain auswählen und im DocumentRoot einen Ordner definieren. Alternativ kann man auch das gesamte DocumentRoot absichern.

Soweit, sogut… nun sollte man den Pfad aufrufen können und die User/Pass abfrage sollte erscheinen.

Ab hier wird es tricky!
Soweit ich das überschauen kann, gibt es unter Plesk keine Möglichkeit die Benutzer und Ihre Passwörter zu pflegen. Das ist manuell zu machen.
Wer Kunde bei HostEurope ist, hat im KIS Backend Zugriff auf einen „Passwortgenerator“, welcher die notwendigen Zeilen für die Passwortdatei generiert. Alternativ kann man auf dem Server selbst auch den Befehl „htpasswd“ zur Erstellung der Zeilen bzw maintainen der Passwortdatei nutzen. Dazu bitte ich um ein genaues Studium der Optionen, sonst ist damit schnell etwas kaputt gemacht.

Man muss jetzt per SSH aufs System und sich in den Hauptordner der Domain/Subdomain bewegen, welche über Plesk gesichert wurde.

Als Beispiel nehme ich jetzt die Subdomain test.example.com

Zuerst schaut man, welche Datei Plesk zur Sicherung vorgesehen hat

grep AuthUserFile /var/www/vhosts/test.example.com/conf/last_httpd.include

Die Ausgabe:

root@example:~# grep AuthUserFile /var/www/vhosts/test.example.com/conf/last_httpd.include
AuthUserFile "/var/www/vhosts/test.example.com/pd/d..httpdocs"

Sollten hier mehrere Dateien genannt werden, dann muss man sich die Datei mit „more“ anschauen, um die jetzt interessante herauszufinden.

more /var/www/vhosts/test.example.com/conf/last_httpd.include

Hat man herausgefunden, welche Datei für die Authentifizierung verantwortlich ist, dann muss diese als „root“ bearbeitet werden. Plesk 11 legt die Datei so an, dass diese nur für den Systemuser „www-data“ lesbar ist.

Mit dem Editor meiner Wahl öffne ich die Datei

vi /var/www/vhosts/test.example.com/pd/d..httpdocs

Wichtig: Pro Zeile ein User, sonst klappt das ganze nicht!

Nach dem Speichern der Modifikation ist das direkt aktiv und man sollte nun das geschützte Verzeichnis mit den eben gespeicherten Wunschdaten betreten können.

Skype 4 installieren auf 64bit Systemen

Problem:
Das neue Skype 4 kann heruntergeladen werden, ist jedoch ein i386 Paket

Lösung:
Im Debian Wiki http://wiki.debian.org/skype ist das ausführlich beschrieben.

Für eine Wheezy 64bit Installation ist als root folgendes zu tun

dpkg --add-architecture i386
apt-get update
apt-get upgrade
apt-get install -f
cd /tmp
wget -O skype-install.deb http://www.skype.com/go/getskype-linux-deb
dpkg -i skype-install.deb

Der letzte Befehl wird nicht erfolgreich ablaufen, da die 32bit Pakete nicht vorhanden sind.


Vorbereitung zum Ersetzen von skype 4.0.0.8-1 (durch skype-install.deb) ...
Ersatz für skype wird entpackt ...
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von skype:
skype hängt ab von libasound2 (>= 1.0.16).
skype hängt ab von libqt4-dbus (>= 4:4.5.3).
skype hängt ab von libqt4-network (>= 4:4.8.0).
skype hängt ab von libqt4-xml (>= 4:4.5.3).
skype hängt ab von libqtcore4 (>= 4:4.7.0~beta1).
skype hängt ab von libqtgui4 (>= 4:4.8.0).
skype hängt ab von libqtwebkit4 (>= 2.1.0~2011week13).
skype hängt ab von libxss1.
skype hängt ab von libxv1.
skype hängt ab von libssl1.0.0.

dpkg: Fehler beim Bearbeiten von skype (--install):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
Trigger für gnome-menus werden verarbeitet ...
Trigger für desktop-file-utils werden verarbeitet ...
Fehler traten auf beim Bearbeiten von:
skype

Hierbei handelt es sich um 32bit Pakete!
Da zu Beginn aber die i386 Architektur bekannt gemacht wurde, genügt nun der folgende Befehl und die gewünschten i386 Pakete werden zur Installation angeboten.

apt-get install -f


Statusinformationen werden eingelesen.... Fertig
Abhängigkeiten werden korrigiert ... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
libasound2:i386 libaudio2:i386 libgstreamer-plugins-base0.10-0:i386 libgstreamer0.10-0:i386 liblcms1:i386 libmng1:i386 liborc-0.4-0:i386 libqt4-dbus:i386
libqt4-network:i386 libqt4-xml:i386 libqtcore4:i386 libqtgui4:i386 libqtwebkit4:i386 libsqlite3-0:i386 libssl1.0.0:i386 libxss1:i386 libxv1:i386
Vorgeschlagene Pakete:
libasound2-plugins:i386 nas:i386 libvisual-0.4-plugins:i386 gstreamer-codec-install:i386 gnome-codec-install:i386 gstreamer0.10-tools:i386
gstreamer0.10-plugins-base:i386 liblcms-utils:i386 libicu48:i386 qt4-qtconfig:i386
Die folgenden NEUEN Pakete werden installiert:
libasound2:i386 libaudio2:i386 libgstreamer-plugins-base0.10-0:i386 libgstreamer0.10-0:i386 liblcms1:i386 libmng1:i386 liborc-0.4-0:i386 libqt4-dbus:i386
libqt4-network:i386 libqt4-xml:i386 libqtcore4:i386 libqtgui4:i386 libqtwebkit4:i386 libsqlite3-0:i386 libssl1.0.0:i386 libxss1:i386 libxv1:i386
0 aktualisiert, 17 neu installiert, 0 zu entfernen und 8 nicht aktualisiert.
1 nicht vollständig installiert oder entfernt.

Die PATH Variable systemweit erweitern unter OSX

Problem:
Ich habe unter /usr/local/anwendungsname Binaries liegen, die ich über Terminal zugreifbar haben möchte ohne jedesmal den Pfad wechseln zu müssen.

Lösung:
Unter OSX 10.6 (und sicher auch späteren Versionen) gibt es extra dafür ein eigenes Verzeichnis, in welchem man eine Datei ablegen kann die einfach nur den Pfad enthält.

In meinem Anwendungsfall handelt es sich um das Android SDK, aber natürlich funktioniert das Vorgehen auch mit anderen Anwendungen 😛

Ich starte ein Terminal und wechsle in das Verzeichnis mit den Binarys. Hier führe ich folgendes aus

sudo su
pwd > /etc/paths.d/anwendungsname
exit

Das wars schon! Die geöffneten Terminals müssen neu geöffnet werden, damit die Modifikation auch bemerkt werden kann.
In dem Fall „Android SDK“ gibt es 2 verschiedene Ordner mit Binaries fürs Terminal, man kann jeden gewünschten Pfad jeweils in eine eigene Zeile schreiben.

Im vorliegenden Fall wechselt man einfach in das nächste Verzeichnis und hängt den Pfad in die nun schon vorhandene Datei ein

pwd >> /etc/paths.d/anwendungsname

Im Prinzip kann man die Datei auch „custom“ nennen und darin einfach alle gewünschten Pfade zentral verwalten. Wichtig: Ein Pfad pro Zeile!

Meine Datei /etc/paths.d/android-sdk schaut also wie folgt aus

/usr/local/android-sdk/platform-tools
/usr/local/android-sdk/tools

Alle darin enthaltenen Executables sind ab sofort für alle Benutzer im Terminal verfügbar!

Weitere Infos zum Thema findet man im Apple Developerbereich