Tag: background wissen

die history funktion in der bash shell ist ja schon geil (pfeil nach oben/unten), aber es geht noch besser! wenn man diese zeilen in die datei ~/.inputrc schreibt:


# pfeil (cursortaste) nach oben:
# gehe zu der vorherigen zeile in der history
# die mit den eingetippten buchstaben beginnt
"\e[B": history-search-forward
# pfeil nach unten: das gegenteil von pfeil nach oben
"\e[A": history-search-backward


nach einem erneuten login steht dann die funktion zur verfuegung. als beispiel:
gib “ssh” ein und druecke die cursortaste nach oben und du “scrollst” durch die history, aber nur die eintraege, die mit “ssh” beginnen.

ich finds genial…

ich hatte gestern einen server von einem rootkit zu befreien… zumindest nach bestem wissen und gewissen, damit die kiste wieder laeuft und keinen unfug mehr macht. an einer neuinstallation geht da sowieso nichts dran vorbei… sicher ist sicher.

auf jeden fall kann man da auch mal schmunzeln, wenn einem sowas unterkommt:

# lsattr /bin/ls
suS-iadAc--------- /bin/ls

# chattr -suSiadAc /bin/ls

was nur die susi mit dem adac hat…

wens interessiert… das sind flags im ext2 dateisystem. wikipedia schreibt dazu:

Das Flags-Feld enthält einige ext2-spezifische Flags, die nicht beispielsweise durch chmod beeinflusst werden können. Diese Flags können mit dem Programm lsattr gelistet werden und mit chattr geändert werden. Diese Flags erlauben einer Datei besonderes Verhalten, welches über die POSIX-Dateiflags nicht darstellbar ist: Es gibt Flags für sicheres Löschen, Unlöschbarkeit, Kompression, synchrone Updates, Schreibschutz, indizierte Verzeichnisse, Journaling und einiges mehr. Nicht alle Flags werden jedoch vom ext2-Treiber im Kernel umgesetzt.

bei selflinux.org gibts leicht verstaendliche erklaerungen auf deutsch dazu, die ich einfach mal hier reinkopiert hab:

s (Secure Delete)

Wenn das System diese Datei löscht, werden alle Datenblöcke auf dem Datenträger zufällig überschrieben.

u (Undelete)

Wenn eine Anwendung das Löschen der Datei fordert, soll das System die Datenblöcke so “konservieren”, dass das Löschen der Datei auch wieder rückgängig gemacht werden kann. Diese Funktion ist derzeit noch nicht impementiert.

S (Sync)

Wenn eine Anwendung gerade den Schreibprozess durchführt, soll das System alle Änderungen sofort und ungepuffert auf dem physischen Datenträger abspeichern.

i (Immutable)

Das System verbietet jegliche Änderungen an der Datei. Im Falle eines Verzeichnisses können Dateien, die in diesem Verzeichnis bereits existieren, verändert werden. Weder das Löschen noch das Anlegen von Dateien ist möglich.

a (Append Only)

Das System erlaubt das Öffnen dieser Datei nur zum Zwecke der Erweiterung und verbietet explizit allen Prozessen das Überschreiben bzw. Löschen bereits gespeicherter Daten (sinnvoll bei log-Dateien). Ebenfalls untersagt ist das Löschen, Umbenennen, Verschieben und “hartes” Linken der Datei. Wird das Flag auf einem Verzeichnis angewendet, dürfen darin keine Dateien angelegt oder gelöscht werden.

d (No Dump)

Das dump Programm soll diese Datei beim Backup ignorieren.

A (Atime)

Das System soll die “atime” (access time) dieser Datei nicht aktualisieren.

c (Compress)

Das System soll diese Datei “transparent” komprimieren. Beim Schreiben in die Datei wird deren Inhalt komprimiert und erst danach auf dem physischen Datenträger abgelegt, beim Lesen der Datei werden jedoch stets dekomprimierte Daten zurückgegeben. Diese Funktion ist derzeit noch nicht implementiert.

das stand schon lange auf meiner liste der “sachen, die ich unbedingt nachschlagen muss”: die grub konfiguration bei einem software raid1 unter linux. und jetzt bin ich rein zufaellig beim hostbogger drueber gestolpert: “Insbesondere ist es wichtig, sicherzustellen, dass beim Totalausfall eines physikalischen Laufwerks von der nächsten (meist einzigen) anderen, die in diesem Falle dann zur ersten wird, gebootet werden kann.”

• /boot/grub/device.map editieren:

(hd0) /dev/sda
(hd0) /dev/sdb
(hd0) /dev/sd

• in der Grub-Shell

root (hd0,1) # Natürlich die /boot-Partition angeben
setup (hd0)
setup (hd1)
setup (hd)

Das Ganze hat den Hintergrund, dass sich beim Booten mit fehlendem Laufwerk die Nummerierung ändert, aber immer ein hd0 vorhanden ist.

es gibt mehrere wege, mit einer wordpress installation mehrere blogs zu betreiben. wordpress 3.0 soll das von haus aus koennen, aber momentan befindet sich diese version noch im beta stadium. ich will hier eine moeglichkeit beschreiben, welche eine installation in einem unterverzeichnis voraussetzt, wie in meinem falle z.b. http://www.domain.tld/wp/.

der “hack” findet in der config datei statt, in der fuer jedes blog anhand der URL ein anderer prefix fuer die tabellen in der datenbank benutzt wird. man kann auch andere wege gehen, in dem man z.b. unterschiedliche datenbanken benutzt. dazu ist nur ein kleines bischen code in der config datei noetig. ja, dann ists keine reine config datei mehr, aber so ists halt nun mal…

fuer jedes weitere blog, das man hizufuegen will legt man dann einfach einen link parallel zu dem eigentlichen verzeichnis an (hier das alte verzeichnis “wp” und das neue “neuesblog”):

cd /var/www/webroot/
ln -s wp neuesblog

damit das funktioniert, muss natuerlich in der apache konfiguration fuer den vhost die option “followsymlinks” aktiviert sein.

in der datei wp-config.php muss an der stelle mit dem “$table_prefix” ein paar zeilen drumherum hinzufuegen. jedes blog bekommt anhand des verzeichnisses in der aufgerufenen URL einfach einen anderen prefix fuer die tabellen.


$arrWP = explode( "/", $_SERVER["REQUEST_URI"] );
if ( $arrWP[1] == 'wp' )
{ $table_prefix = 'wp_'; }
elseif ( $arrWP[1] == 'neuesblog' )
{ $table_prefix = 'neuesblog_'; }
else { exit(); }

der “table_prefix” kann beliebig gewaehlt werden. es wird sogar empfohlen, den nicht so zu bennen, wie das blog heisst, sondern besser irgendwelche wahllosen buchstaben und zahlen zu nehmen.

theoretisch wars das schon. das “neuen” blog sollte nun unter http://www.domain.tld/neuesblog/ aufrufbar sein. beim ersten aufruf wird das setup ausgefuehrt und die tabellen werden angelegt. der ordnung halber sollte man aber fuer die media dateien jedes blogs einen unterordner in dem standardmaessigen verzeichnis wp-content/uploads anlegen und diesen im backend in den settings eintragen.

installierte plugins und themes koennen von den blogs gemeinsam und unabhaengig voneinander genutzt werden. vorrausgesetzt natuerlich, dass alles sauber programmiert ist und nirgends in dateien absolute pfade und so ein murks eingetragen sind.

diese loesung eignet sich logischerweise nicht fuers shared hosting, sonder lediglich fuer eigene blogs auf dem eigenen webspace/server.

da man nun unter einer domain mehrere blogs hat, muessen bei benutzung von sitemaps auch verschiedene sitemaps fuer jedes blog angelegt und per robots.txt oder z.b. den google webmaster tools bekannt gegeben werden.

ich denke das wars. vorteil eines solchen setups ist z.b., dass man nur ein blogs mit plugins etc. auf dem aktuellen softwarestand halten muss.

jemand trat mit einem 0815 fehler an mich ran. dieser fehler ist erstmal nichts neues oder gar spektakulaeres:

Fatal error: Allowed memory size of 262144 bytes exhausted (tried to allocate 19456 bytes) in….

oft genug kam mir das unter und ich weiss eigentlich genau, was da zu tun ist. diesmal hat das nur nichs gebracht. je nachdem, was man alles davon in google eingibt, kommen bis zu 5 millionen ergebnisse dazu. in der dazugehoerigen php.ini war der eintrag memory_limit auf 128MB gesetzt, was ein phpinfo() auch genau so ausgegeben hat. aber diese “262144 bytes” aus der fehlermeldung passen aber nicht im geringsten zu den 128MB aus der php.ini.
nach stundenlangem suchen und rumprobieren an mehreren tagen (insgesamt vermutlich mehr als 10 – 15 stunden meiner wertvollen abendstunden) ist es mir dann wie schuppen von den augen gefallen. in der php.ini stand:

memory_limit = 128MB

was aber eigentlich nur

memory_limit = 128M

heissen sollte. au mann. das tut weh. ich hab beim probieren immer nur die zahlen vor den buchstaben geaendert, was mir das phpinfo() auch immer schoen korrekt anzeigte. das ueberfluessige “B” am ende kam aber nicht von mir, sondern von dem, der mir den fehler gemeldet hatte… au weia

vor ein paar tagen verfasste ich eine email an tengelmann, warum denn die biobananen in plastikfolie eingeschweisst waeren und kein herkunftsland angegeben ist. unabhaengig vom inhalt moechte ich die erstmal loben, dass sie so eine anfrage in aller ausfuehrlichkeit beantworten! hier nun die email:

“zurückkommend auf Ihre Kundenanfrage vom 16.06.2009 bezüglich der Umverpackung unserer Naturkind-Produkte möchten wir Ihnen Folgendes mitteilen:

Gerne würden wir unsere Naturkind-Produkte ohne die von Ihnen beschriebenen Verpackungen zum Kauf anbieten. Allerdings ist dies in der Praxis nicht durchführbar, da wir unsere Bio-Ware von der herkömmlichen Ware trennen müssen, um einen eventuellen Kontakt zu der Nicht-Bioware vermeiden zu können.

Würden wir herkömmliche und Bio-Ware beide unverpackt zum Kauf anbieten, könnte eine Verwechslung, Vermischung oder Kontamination der Produkte nicht ausgeschlossen werden. Sei es, dass unser Marktpersonal die Ware falsch zuordnet, unsere Kunden beide Waren anfassen, oder womöglich die Produkte miteinander vermischen könnten.

Damit dies ausgeschlossen werden kann und unsere Bio-Ware auch bio bleibt, wird diese in den entsprechenden recyclebaren Verpackungsmaterialien ausgeliefert und zum Kauf angeboten.

Wir bitten hierbei also um Ihr Verständnis, da wir keine andere Möglichkeit sehen, eine Kontamination der Bio-Produkte ausschließen zu können. Natürlich sind wir stets bestrebt, unsere Waren in unbedenklichen und recyclebaren Umverpackungen anzubieten. Einige unserer Produkte konnten wir schon auf ein aus Maisstärke bestehendes Verpackungsmaterial umstellen, welches aussieht wie eine durchsichtige Plastikfolie.
Diese Umverpackungen erkennen Sie an unten angefügtem Symbol und können sie bedenkenlos auf Ihren Bio-Kompost geben.

Um diese Folie auf allen Bio-Produkten anwenden zu können, muss die individuelle Zusammensetzung zur Produktion der Folie ermittelt und getestet werden, da die Produkte unterschiedliche Eigenschaften besitzen und diese Folie daran angepasst werden muss (z.B. muss die Folie bei schweren Bananen reißfest sein). Sobald weitere Folien entwickelt sind, werden wir diese an unseren Bio-Produkten zum Einsatz bringen.

Zu Ihrer Frage nach der nicht deklarierten Herkunftsangabe können wir Ihnen mitteilen, dass es hierzu keine gesetzliche Verpflichtung gibt und eine Angabe der Herkunft bei Bananen optional erfolgen kann.

Wir danken Ihnen herzlich für Ihr Interesse an unseren Produkten und freuen uns, Sie auch weiterhin als zufriedenen Stammkunden in unseren Tengelmann-Filialen begrüßen zu dürfen. ”

ahja… jetzt bin ich schlauer. wobei jeder fuer sich oekobilanztechnisch nochmal drueber nachdenken kann, ob bio-bananen aufgrund des enormen transportweges ueberhaupt “bio” sein koennen.

screenshots faelschen war ja schon immer so aufwaendig 😉
das geht viel einfacher! einfach in die adressleiste diesen befehl eingeben:
javascript:document.body.contentEditable='true'; document.designMode='on'; void 0
u.a. hier gesehen.

kann mir irgendwer erklaeren, warum in der registry normale guids als “compressed guid” abgespeichert werden? zumal das “compressed” sich eigentlich nur auf die fehlenden bindestriche und klammern beschraenkt. richtig beschraenkt finde ich allerdings die art und weise, wie die zeichenkette stueck fuer stueck umgekehrt werden. abschnittsweise erst der komplette abschnitt und nach dem dritten abschnitt immer paarweise. hier ein beispiel:

ausser leute damit zu verwirren und das suchen nach bestimmten guids in der regsitry zu erschweren bezweckt das meiner meinung nach nichts. falls es doch eine mathematische oder sonst irgendwie logische erklaerung dafuer gibt, dann bitte bei mir melden….