Hi,
da ein paar Griechen bei mir ein Holzpferd stehenlassen haben muss ich meinen Server neu aufsetzen und koennte noch ein paar Tipps gebrauchen:
*Was muss ich bei der Migration von Cyrus-Mailboxen beachten?
*Kann man Mailman-Listen (incl. Archive) irgendwie aus einer Installation in die andere uebertragen?
*Ist Postgres/MySQL Dump-einspielen problemlos oder ist was zu beachten?
*Laufen PHP4-Scripte problemlos auf PHP5? (Ich habe bisher PHP immer auf einer 4.x zurueckgehalten statt ein komplettes Upgrade zu machen.)
*Kann man den Kernel irgendwie versiegeln? So dass keine weiteren Module mehr geladen werden koennen und auch sonst kein Schreibzugriff auf den Kernelspace (/dev/kmem) moeglich ist. Nach Moeglichkeit wuerde ich trotzdem gerne weiter den Debian-Kern verwenden.
*Ich habe gehoert es gibt Probleme mit User-ID-Filtern in IPTables von Kernel 2.6.x. Ist das noch aktuell? (Diese Filter haben dieses mal verhindert, dass eine Katastrophe ausbricht - ich wuerde sie also gerne behalten.)
Konrad
am Fri, dem 09.02.2007, um 13:15:25 +0100 mailte Konrad Rosenbaum folgendes:
*Ist Postgres/MySQL Dump-einspielen problemlos oder ist was zu beachten?
^^^^^^^^
Aufpassen, daß alle benötigten Sprachen verfügbar sind.
Andreas
Hallo,
*Laufen PHP4-Scripte problemlos auf PHP5? (Ich habe bisher PHP immer auf einer 4.x zurueckgehalten statt ein komplettes Upgrade zu machen.)
Falls Du Klassen benutzt nein, da von PHP4 zu PHP5 es da viele Änderungen vor allem im Bereich des Handling von Referenzen bzw. Objekten gab.
Grüße aus Frankfurt, David
Hi Konrad,
*Kann man Mailman-Listen (incl. Archive) irgendwie aus einer Installation in die andere uebertragen?
Sieh dich mal unter /var/lib/mailman/ um - ein Verzeichnis archive und ein paar conf-Dateien in Berkeley-DB-Format sollten dein Interesse finden.
*Kann man den Kernel irgendwie versiegeln? So dass keine weiteren Module mehr geladen werden koennen und auch sonst kein Schreibzugriff auf den Kernelspace (/dev/kmem) moeglich ist. Nach Moeglichkeit wuerde ich trotzdem gerne weiter den Debian-Kern verwenden.
Afaik nur durch Modifikationen des Kernels (grsec etc.). Ansatzweise durch einen Kernel ohne Modulsupport.
mfg, Fabian
Konrad Rosenbaum konrad@silmor.de (Fr 09 Feb 2007 13:15:25 CET):
da ein paar Griechen bei mir ein Holzpferd stehenlassen haben muss ich meinen Server neu aufsetzen und koennte noch ein paar Tipps gebrauchen:
*Was muss ich bei der Migration von Cyrus-Mailboxen beachten?
~cyrus/ mitnehmen und /var/lib/cyrus
*Ist Postgres/MySQL Dump-einspielen problemlos oder ist was zu beachten?
MySQL-Dump bisher ja. (Probleme gab's bei uns mal blödem Quoting und einer Übertragung von Windows zu Linux.)
On Fri, Feb 09, 2007 at 01:15:25PM +0100, Konrad Rosenbaum wrote:
Hi,
Hi Konrad,
*Kann man den Kernel irgendwie versiegeln? So dass keine weiteren Module mehr geladen werden koennen und auch sonst kein Schreibzugriff auf den Kernelspace (/dev/kmem) moeglich ist. Nach Moeglichkeit wuerde ich trotzdem gerne weiter den Debian-Kern verwenden.
Du kannst dir ein Modul schreiben was einfach den insmod() call in der syscall Tabelle auf eine Funktion verbiegt die nix tut... Nachdem du dieses Modul geladen hast laufen alle nachfolgenden insmod aufrufe also ins Leere.
Ciao, Tobias
Am Freitag, 9. Februar 2007 16:36 schrieb Tobias Koenig:
Du kannst dir ein Modul schreiben was einfach den insmod() call in der syscall Tabelle auf eine Funktion verbiegt die nix tut... Nachdem du dieses Modul geladen hast laufen alle nachfolgenden insmod aufrufe also ins Leere.
www-data@localhost$ # hm.... www-data@localhost$ make_root_exploit.sh localhost% # hm.... jetzt weiter localhost% modprobe hackermod insmod: I'm schutzmod, you cannot do this, hahaha localhost% rmmod schutzmod localhost% modprobe hackermod insmod: you're 0wned...
Josef
P.S. natürlich würdest du rmmod() auch mit verbiegen :)
P.P.S. heißt glaube ich {create,delete}_module
On Fri, Feb 09, 2007 at 05:37:17PM +0100, Josef Spillner wrote:
Am Freitag, 9. Februar 2007 16:36 schrieb Tobias Koenig:
Hi Josef,
Du kannst dir ein Modul schreiben was einfach den insmod() call in der syscall Tabelle auf eine Funktion verbiegt die nix tut... Nachdem du dieses Modul geladen hast laufen alle nachfolgenden insmod aufrufe also ins Leere.
www-data@localhost$ # hm.... www-data@localhost$ make_root_exploit.sh localhost% # hm.... jetzt weiter localhost% modprobe hackermod insmod: I'm schutzmod, you cannot do this, hahaha localhost% rmmod schutzmod localhost% modprobe hackermod insmod: you're 0wned...
Josef
P.S. natürlich würdest du rmmod() auch mit verbiegen :)
Nein, ich würde das Modul nicht 'hackermod' nennen, sondern rtl8139 ;)
Ciao, Tobias
Tobias Koenig tokoe@kde.org wrote:
*Kann man den Kernel irgendwie versiegeln? So dass keine weiteren Module mehr geladen werden koennen und auch sonst kein Schreibzugriff auf den Kernelspace (/dev/kmem) moeglich ist. Nach Moeglichkeit wuerde ich trotzdem gerne weiter den Debian-Kern verwenden.
Du kannst dir ein Modul schreiben was einfach den insmod() call in der syscall Tabelle auf eine Funktion verbiegt die nix tut... Nachdem du dieses Modul geladen hast laufen alle nachfolgenden insmod aufrufe also ins Leere.
Ist zwar Hardcore, aber man könnte sich immer noch mit direkter Arbeit an /dev/mem in den Kernelspace bringen. Das funktioniert sogar noch, wenn keine Module zugelassen sind. Für sowas ist grsec da, da sind die "security-batteries" included.
mfg, Fabian
Hi Konrad,
On Fri, Feb 09, 2007 at 13:15:25 +0100, Konrad Rosenbaum wrote:
*Kann man den Kernel irgendwie versiegeln? So dass keine weiteren Module mehr geladen werden koennen und auch sonst kein Schreibzugriff auf den Kernelspace (/dev/kmem) moeglich ist. Nach Moeglichkeit wuerde ich trotzdem gerne weiter den Debian-Kern verwenden.
Ohne Patchen des Kernels wird das wohl nicht gehen. Da auf silmor.de kein X laeuft (oder doch) wird /dev/mem jedenfalls nicht gebraucht. Alle char-major-1 Geraete wird man nicht wegwerfen koennen, da auch /dev/null und /dev/zero dazu zaehlen.
*Ich habe gehoert es gibt Probleme mit User-ID-Filtern in IPTables von Kernel 2.6.x. Ist das noch aktuell? (Diese Filter haben dieses mal verhindert, dass eine Katastrophe ausbricht - ich wuerde sie also gerne behalten.)
Soweit ich weiss, beschraenken sich die Probleme auf die Kombination SMP-Kernel / Owner Match Modul. Mit Uniprozessor-Kernels sollte es gehen. Wichtig bei Owner Match ist wohl, dass iptables gegen die Header des laufenden Kernel gebaut sein muss, da es die task-Struktur genau kennen muss.
Gruss, Chris
Hallo Konrad,
was lange wärt, wird endlich gut ;-).
Am Freitag, 9. Februar 2007 13:15 schrieb Konrad Rosenbaum:
*Laufen PHP4-Scripte problemlos auf PHP5? (Ich habe bisher PHP immer auf einer 4.x zurueckgehalten statt ein komplettes Upgrade zu machen.)
Kommt drauf an, wie die Skripte programmiert sind. Wenn die Software ein erfahrener Programmierer geschrieben hat der PHP3 für eine chemische Formel hält, dann zu 98% ja. Ich habe schon einige PHP4-Programme unter PHP5 getestet und sie funktionierten ohne Probleme. Was genau macht dir denn Bauchschmerzen?
Tschau,
Falk
On Mon, February 19, 2007 15:19, Falk Döring wrote:
Am Freitag, 9. Februar 2007 13:15 schrieb Konrad Rosenbaum:
*Laufen PHP4-Scripte problemlos auf PHP5? (Ich habe bisher PHP immer auf einer 4.x zurueckgehalten statt ein komplettes Upgrade zu machen.)
Kommt drauf an, wie die Skripte programmiert sind. Wenn die Software ein erfahrener Programmierer geschrieben hat der PHP3 für eine chemische Formel hält, dann zu 98% ja. Ich habe schon einige PHP4-Programme unter PHP5 getestet und sie funktionierten ohne Probleme. Was genau macht dir denn Bauchschmerzen?
...die Moeglichkeit der Inkompatibilitaet...
Ich weiss jetzt dass ich testen muss, also wird sich die Umstellung auf PHP5 noch weiter verzoegern bei mir. Ohne gravierenden Grund nehme ich mir nicht so schnell die Zeit fuer die notwendigen Tests.
...es gibt genug Baustellen ohne PHP5.
Konrad
Konrad Rosenbaum schrieb:
*Laufen PHP4-Scripte problemlos auf PHP5?
Diese Frage habe ich derzeit auch und bin bereits auf ein Problem gestoßen: date_format ist eine neue PHP-Funktion ab der Version 5.2 und existiert als User-Funktion in der Phorum-Software 3.4.1 Fatal error: Cannot redeclare date_format() in...
Leider habe ich noch keine Liste mit Problem-Software gefunden und bei selbsterstellten Scripten hilft ohnehin nur selber testen. Dafür kann eine zweite Apache/PHP-Instanz auf einem anderen Port parallel laufen.
Gruß René Thiel (Rennkuckuck) mailto:reti@rennkuckuck.de -- http://rennkuckuck.de - Die Rumänien-Seiten http://rtol.de - Dynamische Webseiten mit PHP, mySQL und CSS
Morgen!
Am Montag, 19. Februar 2007 21:57 schrieb Rene Thiel:
Konrad Rosenbaum schrieb:
*Laufen PHP4-Scripte problemlos auf PHP5?
Diese Frage habe ich derzeit auch und bin bereits auf ein Problem gestoßen: date_format ist eine neue PHP-Funktion ab der Version 5.2 und existiert als User-Funktion in der Phorum-Software 3.4.1 Fatal error: Cannot redeclare date_format() in...
Da bewahrheitet sich immer wieder: Immer schön mit Prefix arbeiten!
Meine zwei Groschen,
Falk
lug-dd@mailman.schlittermann.de
-
A. Kretschmer -
Christian Perle -
David Seidel -
Fabian Hänsel -
Falk Döring -
Heiko Schlittermann -
Josef Spillner -
Konrad Rosenbaum -
Rene Thiel -
Tobias Koenig