DevilDawn

PHP... http://de2.php.net/split

list($user,$domain) = split("@",$mailadress) Zugangsdaten gehören in ein include das ausserhalb des DocumentRoot liegt, und per include() eingebunden. Dennoch, solange der Webserver .php Dateien korrekt interpretiert kommt man da ohne weiteres nicht ran. Eine Misskonfiguration - und wenn nur für kurze Zeit - kann deine Daten aber der öffentlichkeit zugänglich machen. Weiterhin sollte der DB-User den du nutzt natürlich nicht der Admin-User sein und nur von localhost zugreifen können (GRANT ALL ON database.* TO user@localhost IDENTIFIED BY 'password')

Wenn es dir nur um die Verschlüsselung geht bietet sich vielleicht eher stunnel an.

Ja. Genauer, die Sessiondaten werden auf jeden Fall nicht beim User gespeichert. Ob die Sessiondaten nun lokal auf dem Server liegen oder z.b. auf einem zentralen Datenbankserver (bei geeigneten session handlern) sei dahingestellt. Out-of-the-Box liegen die Sessiondaten Server-Lokal in Dateien vor.

Wenn du damit meinst das die gespeicherten Werte per Cookie beim User abgespeichert werden: Ganz klar Falsch. Sinn einer Session ist es, den User zu identifizieren aber die Daten der Session in einem vertrauenswürdigem Bereich abzulegen. Daten die vom User kommen sind grundsätzlich nicht zu Vertrauen. PHP legt die Sessions defaultmässig als Files ab. Du kannst alternativ eigene Handler dafür schreiben und benutzen (vergl session_set_save_handler())

Vermutlich nicht. Diversity Antennen dienen dazu auch bei unglücklichen Reflexionen oder störenden Hindernissen den Empfang zu halten. Nur eine der Antennenstäbe kann dabei jeweils aktiv sein. Es funktioniert gemeinhin nicht, zwei verschiedene Antennen gleichzeitig anzuschliessen. Wie gesagt, technisch gesehen hat das gerät nur eine Antenne.

Google wäre dein Freund gewesen http://www.dlink.com/corporate/article.asp?prid=4 Technisch gesehen natürlich trotzdem nur eine (Diversity-)Antenne.

So per se vergleichst du Äpfel mit Birnen. Denn im Prinzip ist ein Proxy auch nur ein Client. Der Proxy reduziert deine Probleme insofern das er der einzige Client ist der ins Netz geht. D.h. du musst - gegen Connects von aussen - nur diesen Client härten, da er ja stellvertretend für die anderen ins Netz geht. Es ist ausserdem Sicherer insofern, das man den Leuten im LAN diverse Unfugsoftware abgewöhnen kann Im Prinzip willst du also beides: (Clients) <- -> Proxy <- -> Router <- -> { grosses böses Internet } wobei der Router NUR den Proxy NATtet, und zwar Hiding-NAT. Just my 2 cents.

Der Apache Hauptprozess läuft als root. Er startet Childs, die die eigentlichen Connects annehmen. Die Childs laufen nicht als root, sondern als genau der User den man in der Config mit der User xyz Group abc Direktive angibt. Aufgerufene Scripts laufen ebenfalls unter diesem User. Virtuelle Hosts können Scripte unter eigenen Usern laufen lassen wenn der Apache mit suEXEC Support übersetz worden ist. Ich sag ja, kaum ein Unterschied.

Würde mich interessieren wie der IIS sich so tief ins System einbetten kann ohne Systemrechte? Der IIS läuft vermutlich auch als System oder Administrator und wechselt den User später. http://httpd.apache.org/docs/misc/security_tips.html Ich glaube kaum das es hier grosse Unterschiede gibt.

Viel spaß wenn dein Systembefehl in eine Firewall rennt. Dann hängt dein PHP Script erst mal bis zum Timeout. Ausserdem werden deine Besucher nicht erbaut sein wenn ihre Firewall jedesmal ne Warnung ausspuckt wenn sie auf deine Seite gehen. 'finger' ist nach aussen immer dicht. NBT-Protokolle sollten das auch sein. Womit die ganzen Bemühungen umsonst sind. Letztendlich wäre das auch keine Abfrage "mit PHP" sondern mit externen Programmen.

Ich hab den 2. DB-Durchlauf vermieden indem ich einfach ein lokales Schlagwort-Array beim Parsen gebaut habe. d.h. ich habe mit ###LEXn### nicht die DB-id referenziert, sondern den Index eines lokalen Arrays mit gefundenen Schlagworten. Hängt natürlich von der Anwendung ab welche Methode vernünftiger ist. Ganz extrem: Schon in der Datenbank alle Schlagworte durch Tokens ersetzen Dafür hat man dann aber das gerangel wenn Einträge hinzugefügt oder gelöscht werden... Andererseits ist es für den Anwender dann schneller Nunja war als Ansatz gedacht. Spaß ist, was du daraus machst [tm]

Ähnliches Problem hatte ich mal bei der Implementation von einfachem Syntaxhighlighting. Ich habe einfach die gefundenen Bereiche vorläufig durch Tokens ersetzt und erst nach Abschluss der Suche diese Tokens wieder in die ursprüngliche Textstelle verwandelt. Beispiel: Schlagwort: "Steuerung Bauart Heusinger" Hat in der DB die eindeutige id 237 Wird ersetzt zu ###LEX237### Damit entgeht dieser Text jedem weiteren Replacement. Ist die Schlagwortsuche abgeschlossen wird aus ###LEX[0-9]*### dann "<lex>".$schlagwort[$sid]."</lex>" gemacht. Das ist zwar eine Phase mehr, dafür funktioniert das aber. Mag aber sicher bessere Methoden geben. Hoffe, das war halbwegs verständlich...

Nein, und das ist auch gut so[tm]

Zum einlesen: http://www.php.net/file Zum splitten der Daten: http://www.php.net/explode $wholefile = file("daten.txt"); reset($wholefile); while (current($wholefile)) { $dataset = explode("\t",current($wholefile)); # do something with array $dataset # print, modify, whatever next($wholefile); } Etwas umfangreicher wirds wenn deine Daten auch mit mehreren Tabs oder anderen Whitespaces getrennt sein dürfen.

Variablen in functions sind i.d.R. lokal zur Funktion. Der Rest des Scripts bekommt sie nicht mit. Es gibt die Möglichkeit über das $GLOBALS-Hash: function bla() { $GLOBALS["yy"] = "Wert"; } oder über das global-Statement: function bla() { globa $yy; $yy = "Wert"; } oder halt über eine Rückgabe: function bla() { $result = "Wert"; return $result; } $yy = bla();

" und ' sind quotes Du escapest quotes bei dir: echo "<a href=\"bla.php\">Bla</a>"; Die \ vor den " dienen zum escapen (d.h. das " soll nicht von der Sprache interpretiert werden). Das alles spart man sich mit ?> <a href="bla.php">Bla</a> <? Was imho die Übersichtlichkeit drastisch erhöht und auch Flüchtigkeitsfehler reduziert. Alternative: echo '<a href="bla.php">Bla</a>'; Mit ' ... ' aussenrum kannst du also auch " pur einsetzen - Aber keine Variablen mehr, die werden dann auch nur als Namen ausgegeben. Da müsste man den quote dann beenden : echo '<a href="'.$URL.'">Bla</a>';

Dann frage ich mich warum deine Function eingabe zwar ganz toll viele Variablen baut, aber kein return Statement hat. Wozu ist die gut? Offensichtlich steht im HTML-Source später $yy nicht drin, weil die Variable nur lokal zur function eingabe ist. Schon mal global $yy; versucht?

host:~/shelltest # ls -1 . .. bla.log foo.log mumpfpuffel.log test.sh host:~/shelltest # ./test.sh cp bla.log bla.log20020930-1421-1 cp foo.log foo.log20020930-1421-2 cp mumpfpuffel.log mumpfpuffel.log20020930-1421-3 Der Code dazu ist simpel: #!/bin/sh MYDATE=`date +%Y%m%d-%H%M` MYCOUNT=1 MYPATTERN='*.log' ls -1 ${MYPATTERN} | ( while read MYFILE do MYNEWFILE=${MYFILE}${MYDATE}-${MYCOUNT} echo cp $MYFILE $MYNEWFILE MYCOUNT=`expr $MYCOUNT + 1` done ) Wie man sieht echo'd das Script im Moment nur den Copy-Befehl.

Erstmal ist Quelltextausgabe mit echo schlechter Stil, weil schlecht lesbar. Anstelle von echo '<a href="$value">Blabla</a>'; machst du lieber ?> <a href="<? print $value;?>">BlaBla</a> <? Da bekommst du auch keine Probleme mit dem escapen von Quotes. Dann benutze die "PHP-Normalform" : *HTMLHeader* <? function show_Form() { # Formularausgabe mit Werten } function do_Form() { # Formulareingabe verwursten } if (isset($submitname)) { do_Form(); } show_Form(); ?> *HTMLFooter* Dazu sollte dein Submit-Button aber einen Namen tragen <form action="<? print $PHP_SELF; ?>" method="GET"> ... <input type="submit" name="submitname" value="Absenden"> </form> HTH

Nun ja 4GB ist ja nicht gerade üppig Platz. Bei 40 GB hätte ich was anderes gesagt Ich Partitioniere für gewöhnlich: / -> OS /var -> Logfiles und andere variable Daten /opt (/usr/local ist symlink auf /opt) -> Usersoftware /home -> User homes SWAP /opt und /usr/local lege ich deswegen Zusammen weil sich einige Programme nicht einigen können ob sie lieber in /opt oder in /usr/local liegen wollen. Ich arbeite viel mit Solaris, und dort benutze ich /opt für eigene Packages. Ist mehr oder minder Geschmackssache. Die Frage ist, was du alles für den User installieren willst. Mit KDE und Gnome und noch ein paar Windowmanagern wirds doch schnell voll. Wenn du auch lokal Webserver und mysql DB laufen lassen willst wird auch /var gerne mal belastet. Und schließlich und endlich willst du ja auch genug Platz im $HOME.

Generell würde ich für einen nicht-Server nur eine Swap-Partition abspalten und den Rest zusammenlassen... Man ärgert sich später sonst nur das man für /var viel zuviel angesetzt hat oder für /opt bzw. /usr/local zuwenig usw... Keep it simple. -> swap 512 (oder was auch immer, je nach kiste) -> / rest

http://www.google.com/search?q=syntax+highlighting+javascript -> PHPEdit -> HTMLPad -> EditPlus usw...

Hängt IMHO immer noch vom Medium ab. Token Ring (Copper): http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/tokenrng.htm FDDI/CDDI (Fibre/Copper): http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/fddi.htm Mehr Ring-Typen fallen mir nicht ein

Nicht ganz. Dein Mailprogramm muss auch den Content Type korrekt setzen, und der wird normal text/plain sein. Dann kannst du soviel HTML eingeben wie du willst, der Zielmailer wird das als Text anzeigen. Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lies mal was nach über MIME Mails...