Strategiefrage: SuSE als Sever-BS ja oder nein... :-(
Hallo an alle,
ich muss hier mal meinen Unmut loswerden:
wir setzen auf unseren Servern hauptsächlich SuSE in den Versionen 6.4
bis 7.2 ein - aber langsam überlege ich mir, ob ich nicht Order
erlasse, langsam auf Debian oder etwas anderes umzustellen.
Grund:
Entweder man bleibt beim SuSE-RPM-System und installiert brav
SuSE-Packages, _oder_ man generiert die wichtigen Serverapplikationen
aus den Quellen heraus.
Aber ein Gemisch davon ist meistens katastrophal.
Wenn man wie wir bestimmte Anforderungen an z.B. Apache-Server hat,
_können_ wir nur aus den Quellen neu übersetzen.
Versucht man jetzt man beispielsweise, Apache / PHP4 / mod_ssl /MySQL
aus den Quellen zu generieren, greift aber bei den zugrundeliegenden
Paketen (openssl, openssh , zlib etc. pp. ) auf SuSE-pakete zurück, hat
man _jedesmal_ einen nicht geringen Aufwand, die Pfade der libs und
header per Hand in die makefiles einzubinden, da nicht alle Parameter
beim Configure-lauf mit übergeben werden können.
Die Hauptursache liegt darin, dass viele Pakete sich unter
/usr/local/<Paketname> installieren, mit eigenem SubTree.
Klappt beim Zusammenführen der Sources meist hervorragend.
(wir müssen PHP4 zur Zeit mit jeweils ca. 23 Optionen übersetzen und
als Modul für Apache bereitstellen - da sind dann einige Betas
dabei...)
Standard hin oder her - SuSE verteilt dagegen immer schön nach
Vorschrift alles gemeinsam in den /usr-Baum.
Sind wir die Einzigen, die solche Probleme haben?
Oder gibts da ähnliche Erfahrungen?
mit freundlichem Gruss
Andre Ruppert
Leitung Technik
Am Mit, 30 Jan 2002 schrieb Andre Ruppert:
Entweder man bleibt beim SuSE-RPM-System und installiert brav SuSE-Packages, _oder_ man generiert die wichtigen Serverapplikationen aus den Quellen heraus. Aber ein Gemisch davon ist meistens katastrophal.
Das ist wohl bei keiner Distribution anders.
Wenn man wie wir bestimmte Anforderungen an z.B. Apache-Server hat, _können_ wir nur aus den Quellen neu übersetzen. Versucht man jetzt man beispielsweise, Apache / PHP4 / mod_ssl /MySQL aus den Quellen zu generieren, greift aber bei den zugrundeliegenden Paketen (openssl, openssh , zlib etc. pp. ) auf SuSE-pakete zurück, hat man _jedesmal_ einen nicht geringen Aufwand, die Pfade der libs und header per Hand in die makefiles einzubinden, da nicht alle Parameter beim Configure-lauf mit übergeben werden können.
Warum verwendet ihr nicht die SuSE-Source-RPMS, paßt die Spec-Files an Eure Bedürfnisse an, nehmt evtl. neuere Sourcen und kompiliert Euch daraus Eure eigenen RPM-Packages.
Die Hauptursache liegt darin, dass viele Pakete sich unter /usr/local/<Paketname> installieren, mit eigenem SubTree. Klappt beim Zusammenführen der Sources meist hervorragend. (wir müssen PHP4 zur Zeit mit jeweils ca. 23 Optionen übersetzen und als Modul für Apache bereitstellen - da sind dann einige Betas dabei...)
Und das läßt sich nicht über --prefix steuern? Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
On 30-Jan-02 , ar@vision-net.de wrote:
Entweder man bleibt beim SuSE-RPM-System und installiert brav SuSE-Packages, _oder_ man generiert die wichtigen Serverapplikationen aus den Quellen heraus. Aber ein Gemisch davon ist meistens katastrophal.
Ich bin mit der Situation auch nicht sehr zufrieden. Ich hatte seinerzeit nach aktuellen Samba-RPMs beim Support nachgefragt. Als Antwort wurde mir mitgeteilt, dass man nur bei Security-Fehlern neue Pakete bauen wuerde. Um jetzt die Systeme sauber zu halten, verwende ich checkinstall (http://asic-linux.com.mx/~izto/). Ich kompiliere auf einer Referenzmaschine und erstelle mir mittels checkinstall automatisch RPM-Pakete, die ich dann auf den Produktionsmaschinen installiere. Kind Regards -- Frank Zündorff
Hi, "Andre Ruppert (by way of Andre Ruppert )" wrote:
Hallo an alle,
ich muss hier mal meinen Unmut loswerden:
wir setzen auf unseren Servern hauptsächlich SuSE in den Versionen 6.4 bis 7.2 ein - aber langsam überlege ich mir, ob ich nicht Order erlasse, langsam auf Debian oder etwas anderes umzustellen.
Soweit bin ich (noch) nicht.
Grund:
Entweder man bleibt beim SuSE-RPM-System und installiert brav SuSE-Packages, _oder_ man generiert die wichtigen Serverapplikationen aus den Quellen heraus. Aber ein Gemisch davon ist meistens katastrophal.
Ja,vor allen Dinge, wenn man nicht 100% sicher ist ob man noch Altlasten mit sich rumschleppt.
Wenn man wie wir bestimmte Anforderungen an z.B. Apache-Server hat, _können_ wir nur aus den Quellen neu übersetzen. Versucht man jetzt man beispielsweise, Apache / PHP4 / mod_ssl /MySQL aus den Quellen zu generieren, greift aber bei den zugrundeliegenden Paketen (openssl, openssh , zlib etc. pp. ) auf SuSE-pakete zurück, hat man _jedesmal_ einen nicht geringen Aufwand, die Pfade der libs und header per Hand in die makefiles einzubinden, da nicht alle Parameter beim Configure-lauf mit übergeben werden können.
Die Hauptursache liegt darin, dass viele Pakete sich unter /usr/local/<Paketname> installieren, mit eigenem SubTree.
Und das finde ich auch gut, das ist ordentlich und man kann das "per Hand" deinstallieren, auf einen Schlag, und es gibt das "Altlasten"-Problem nicht. Ich mach das grundsätzlich so. Da viele Pakete (ich mein jetzt nicht rpm, sondern *.tar.gz & tgz) kein "make uninstall" kennen (Beispiel: Xfree Sourcen) müßte man in diesen Fällen mühsam suchen ..
Klappt beim Zusammenführen der Sources meist hervorragend. (wir müssen PHP4 zur Zeit mit jeweils ca. 23 Optionen übersetzen und als Modul für Apache bereitstellen - da sind dann einige Betas dabei...)
Standard hin oder her - SuSE verteilt dagegen immer schön nach Vorschrift alles gemeinsam in den /usr-Baum.
Sind wir die Einzigen, die solche Probleme haben? Oder gibts da ähnliche Erfahrungen?
Nee, sihste ja hiermit :o)
mit freundlichem Gruss
Andre Ruppert Leitung Technik
Harry
Hi, Am Mit, 2002-01-30 um 14.58 schrieb Andre Ruppert:
Hallo an alle,
ich muss hier mal meinen Unmut loswerden:
wir setzen auf unseren Servern hauptsächlich SuSE in den Versionen 6.4 bis 7.2 ein - aber langsam überlege ich mir, ob ich nicht Order erlasse, langsam auf Debian oder etwas anderes umzustellen.
es gibt auch noch andere Alternativen. Schon mal über BSD nachgedacht? Auch das Softwaremanagement unter BSD sucht seinesgleichen. Habe auch erst von Suse auf Debian umgestellt und jetzt laufen auch einige Server mit BSD-Systemen. ciao dieter -- registered linuxuser 199810 it's time to close windows
Hallo Dieter, Am Mittwoch, 30. Januar 2002 17:13 schrieb dieter franzke:
es gibt auch noch andere Alternativen. Schon mal über BSD nachgedacht?
Nö, zu meiner Schande noch nicht. Habe zwischenzeitlich Versuche mit Trustix angestellt (eine Serverdistribution völlig ohne GUI) - war aber auch nicht so das Gelbe vom Ei.
Auch das Softwaremanagement unter BSD sucht seinesgleichen.
Hm, hm
Habe auch erst von Suse auf Debian umgestellt und jetzt laufen auch einige Server mit BSD-Systemen.
Das hört sich doch mal gut an...
Ich werde es mir in jedem Fall mal ansehen....
Danke für den Tip...
mit freundlichem Gruss
Andre Ruppert
Leitung Technik
Hi, On 30 Jan 2002 at 17:13, dieter franzke wrote:
es gibt auch noch andere Alternativen. Schon mal über BSD nachgedacht?
Auch das Softwaremanagement unter BSD sucht seinesgleichen.
Habe auch erst von Suse auf Debian umgestellt und jetzt laufen auch einige Server mit BSD-Systemen.
seine Probleme wird er so nicht los. Wenn er nicht compilieren willhelfen ihm die BSDs auch nicht viel. Ich habe weder mit Linux noch mit NetBSD Probleme, bei beiden kommt die wichtige Software per Hand drauf, nebensächlichkeiten (Apache etc.) installiere ich von den SuSE Cds/Ftp. Was mich stört, sind die vielen unnötigen Datein, die sich für gewöhnlich auf der Platte tummeln wenn man SUSE hat. An so Kleinigkeite, daß mit SuSEconfig die suse_add_modules mit einer Version, die nicht alle Module enthält überschreibt, habe ich mich bereits gewöhnt. Tom
Hallo Thomas, am Mittwoch, 30. Januar 2002 17:57 schrieb Thomas Michael Wanka:
Habe auch erst von Suse auf Debian umgestellt und jetzt laufen auch einige Server mit BSD-Systemen.
seine Probleme wird er so nicht los. Wenn er nicht compilieren willhelfen ihm die BSDs auch nicht viel. Ich habe weder mit Linux noch mit NetBSD Probleme, bei beiden kommt die wichtige Software per Hand drauf, nebensächlichkeiten (Apache etc.) installiere ich von den SuSE Cds/Ftp.
Neenee, langsam, gegen Compilieren haben wir überhaupt nichts - es geht
um die o.a. gemischten Systeme. Man sollte vielleicht nicht ausser Acht
lassen, das jeglicher Aufwand ja irgendwie Zeit und Geld kostet. Und
das sollte man ja wohl tunlichst minimieren...
Der Apache ist für uns z.B. keine "Nebensächlichkeit" - mit den
Systemen verdienen wir u.a. unser Gehalt ;-). Und dabei geht es nicht
so seht um Pipapo-Webpräsenzen, sondern eher um verschlüsselte
Web-Transaktionen.
Mit "Servern" meine ich also Systeme ohne GUI wie KDE oder Gnome oder
sonstwas, ebenso ohne allen Schnickschnack, den man als Normaluser so
braucht. Die Kisten haben nur ein paar Jobs zu erfüllen - und wir
schmeissen grundsätzlich alles runter, was nicht zur Erfüllung eben
dieser Jobs gehört. --> also das genaue Gegenteil von eierlegenden
Vollmilchsäuen.
mit freundlichem Gruss
Andre Ruppert
Leitung Technik
Hi, On 30 Jan 2002 at 18:35, Andre Ruppert wrote:
Der Apache ist für uns z.B. keine "Nebensächlichkeit" - mit den Systemen verdienen wir u.a. unser Gehalt ;-). Und dabei geht es nicht so seht um Pipapo-Webpräsenzen, sondern eher um verschlüsselte Web-Transaktionen.
für mich ist der Apache eben nur als Applikationsserver in meist kleinen Netzen (Büroumgebung) mit wenigen Arbeitsplätzen zuständig, da ist SQL et al der relevante Teil.
Mit "Servern" meine ich also Systeme ohne GUI wie KDE oder Gnome oder sonstwas, ebenso ohne allen Schnickschnack, den man als Normaluser so braucht. Die Kisten haben nur ein paar Jobs zu erfüllen - und wir schmeissen grundsätzlich alles runter, was nicht zur Erfüllung eben dieser Jobs gehört. --> also das genaue Gegenteil von eierlegenden Vollmilchsäuen.
Das wollte ich nicht ausdrücken. Die SuSE bietet eben auch für Server wichtige Vereinfachungen, user mit Yast1 per SSH anzulegen geht wirklich flott zur Hand, um nur ein Beispiel zu nennen. Mich stört, daß theoretisch ein Unix mit Apache, Samba, Mysql und SSH keine 100MB verbrauchen dürfte, aber das bekommt man (besser ich) bei SuSE nicht hin (meine IPX hatte ein SunOS mit X und CDE auf einer 200MB Platte!). Die Schwierigkeiten bei der SuSE sind mE., daß die Vereinfachungen für den Desktop User kaum aus dem System zu bekommen sind. Im Problemfall stößt man immer wieder auf Dateien, darin steht "Diese Datei nicht editieren sondern dort", der "dort"ige Sysntax deckt sich aber oft nicht mit den Beschreibungen, die für andere Distributionen gemacht wurden. Tom
Hallo,
Entweder man bleibt beim SuSE-RPM-System und installiert brav SuSE-Packages, _oder_ man generiert die wichtigen Serverapplikationen aus den Quellen heraus. Aber ein Gemisch davon ist meistens katastrophal.
also dass das Gemisch katastrophal ist, kann ich nicht bestätigen. Wenn man das richtige Konzept hat, dann geht das recht problemlos, zumindest nach meinen Erfahrungen. In einer Antwort ist schon das "--prefix" erwähnt worden, aber ich wollte es noch etwas detaillieren. Wir machen es folgendermaßen: Ich packe die Apache-Sourcen aus nach /software/apache-1.3.22/src. Danach konfiguriere ich mit ./configure --prefix=/software/apache-1.3.22 Das --prefix bewirkt, daß alle Dateien unterhalb des Prefixes installiert werden und überhaupt nicht mit dem normalen Baum vermischt werden. Danach "make" und "make install". Außerdem lege ich einen Link namens "apache" auf apache-1.3.22 an, womit man eine Standardversion bekommt und auch die Möglichkeit hat, mehrere Versionen parallel zu betreiben. Danach hat man die folgende Dateistruktur: / software apache-1.3.22 bin apachectl ... conf httpd.conf ... libexec ... src Makefile configure ... apache-1.x.x bin ... (wie oben) apache (Link auf die Standardversion) Nun kann man noch /software/apache/bin in den PATH aufnehmen und /software/apache/man in den MANPATH, so daß jeder Benutzer ohne grosses Aufhebens die Standardversion bekommt (dies ist für andere Softwarepakete wohl interessanter als bei Apache). Letzlich ist damit alles, was man braucht unterhalt von /software und kann auch leicht auf einen anderen Rechner übertragen werden. Und es beisst sich nicht mit den SuSE-Paketen. Man muß nur in /etc/rc.config die SuSE-Dienste nicht starten lassen. Nachdem ich oft mehrere Instanzen einer Apache-Version laufen lasse (z.B. auf mehreren Servern, die /software über NFS mounten oder auch auf verschiedenen Ports) mache ich noch folgendes (was bei Apache besonders gut geht): Wenn ich mehrere Instanzen starten möchte, dann kann ich durchaus das gleiche bin, libexec, man, etc. verwenden. Wo es Überschneidungen gibt ist conf, cgi-bin, htdocs und log. Nun kann man diese aber leicht im httpd.conf ändern. Ich starte also /software/apache/bin/httpd -f /etc/httpd1/httpd.conf und /software/apache/bin/httpd -f /etc/httpd2/httpd.conf Und die Konfigurationsdateien sind so gestaltet, daß die Logs nach /var/log/httpd1 bzw. /var/log/httpd2 gehen und daß auch htdocs und cgi-bin unterschiedlich sind. Durch den Aufruf mit /software/apache/bin/httpd werden diese Webserver immer mit der Apache-Version gestartet, die ich durch den Link /software/apache als Standard gekennzeichnet habe. Muß eine Instanz mit einer anderen Version laufen, dann ruft man sie wie folgt auf: /software/apache-1.3.21/bin/httpd -f /etc/httpd3/httpd.conf Dadurch, daß man beim Übersetzen das Prefix auf /software/apache-1.3.21 gesetzt hat wird von dieser Version auch automatisch auf das richtige libexec, etc. zugegriffen. Also letztlich, wenn man sich ein gutes Schema überlegt, dann hat man keine Probleme :-). Sollte jemand dieses Schema nützlich finden oder Verbesserungsvorschläge habe, dann bitte ich um Feedback :-). Grüße Michael
Michael Gengenbach wrote:
Danach hat man die folgende Dateistruktur:
/ software apache-1.3.22 bin apachectl ... conf httpd.conf ... libexec ... src Makefile configure ... apache-1.x.x bin ... (wie oben) apache (Link auf die Standardversion)
Das was Du mit /software machst, wird üblicherweise mit /opt gemacht. Genau das selbe. Es gibt Software, die per default auf prefix /usr/local eingestellt ist und es gibt Software, die auf /opt/<softwarename> eingestellt ist. Ist dann nurnoch die Frage, was sinnvoller ist. Hat wohl beides seine Vor- und Nachteile. Unter opt ist es aufgeräumter, ls /opt/ zeigt auf einen Blick, welche Software installiert ist und deinstallieren geht einfach mit rm -r. Dafür muss man für jedes Softwarepaket einen Eintrag in $PATH machen oder ein Symlink nach /usr/local/bin legen oder die Software nur mit absolutem Pfad aufrufen. Ciao, Magnum -- begin http://www.informatik.uni-muenchen.de/~_rosenbau/
Hallo & Guten Morgen, Am Mittwoch, 30. Januar 2002 20:02 schrieb Michael Gengenbach:
Wir machen es folgendermaßen:
... ich habe das hier aus Platzgründen gecuttet ;-)
Also letztlich, wenn man sich ein gutes Schema überlegt, dann hat man keine Probleme :-). Sollte jemand dieses Schema nützlich finden oder Verbesserungsvorschläge habe, dann bitte ich um Feedback :-).
Sei hiermit geschehen:
Grundsätzlich kann ich Deinem Gedankenweg folgen, und der macht auch
Sinn, passt aber leider nicht ganz auf unsere Probleme.
Gegenbeispiel: (wirklich nur als Beispiel)
Unser Apache läuft immer mit einer ziemlich umfangreichen libphp4.a,
die ca. alle 1-2 Wochen neu generiert wird, um neue Funktionen
einzubinden.
Also: Apache aus Sourcen generieren, ist ok.
Jetzt mod_ssl aus Sourcen dazubauen.
Und schon gehts los, wenn man das zugrundeliegende openssl bis dahin
als RPM installiert hatte. Unser libphp4 braucht das und kommt mit dem
RPM zurecht - mod_ssl überhaupt nicht, und das ist nicht mit --prefix
zu lösen, weil libs, header und binaries nicht in einem
zusammenhängenden Baum stecken. Wenn mod_ssl seine Struktur in den
Apache-Sourcebaum (.../apache-xxx/src/modules/...) einhängt, kommt er
mit der RPM-Variante überhaupt nicht klar, auch wenn man den
RPM-Sourcebaum der SuSE auch installiert hat uns als Parameter übergibt.
Installiert man dagegen OpenSSL auch aus der Source, klappt das
wunderbar. Um das System sauberzuhalten, muss man jetzt aber das
OpenSSL-Paket von SuSE deinstallieren.
Wer bekommt jetzt Probleme? Richtig, libphp4.
Zusammengefasst sind das alles lösbare Probleme, aber Sie kosten
einfach Zeit, und irgendwann nervt das...
Ich denke, die meisten haben schon geflucht, wenn Sie lib- und
header-Abhängigkeiten per Hand in den Makefiles auflösen mussten ;-)
mit freundlichem Gruss
Andre Ruppert
Leitung Technik
Hi Andre, On 31 Jan 2002 at 8:57, Andre Ruppert wrote:
Unser Apache läuft immer mit einer ziemlich umfangreichen libphp4.a, die ca. alle 1-2 Wochen neu generiert wird, um neue Funktionen einzubinden.
Also: Apache aus Sourcen generieren, ist ok. Jetzt mod_ssl aus Sourcen dazubauen. Und schon gehts los, wenn man das zugrundeliegende openssl bis dahin als RPM installiert hatte. Unser libphp4 braucht das und kommt mit dem RPM zurecht - mod_ssl überhaupt nicht, und das ist nicht mit --prefix zu lösen, weil libs, header und binaries nicht in einem zusammenhängenden Baum stecken. Wenn mod_ssl seine Struktur in den Apache-Sourcebaum (.../apache-xxx/src/modules/...) einhängt, kommt er mit der RPM-Variante überhaupt nicht klar, auch wenn man den RPM-Sourcebaum der SuSE auch installiert hat uns als Parameter übergibt.
Installiert man dagegen OpenSSL auch aus der Source, klappt das wunderbar. Um das System sauberzuhalten, muss man jetzt aber das OpenSSL-Paket von SuSE deinstallieren.
Wer bekommt jetzt Probleme? Richtig, libphp4.
Zusammengefasst sind das alles lösbare Probleme, aber Sie kosten einfach Zeit, und irgendwann nervt das...
Ich denke, die meisten haben schon geflucht, wenn Sie lib- und header-Abhängigkeiten per Hand in den Makefiles auflösen mussten ;-) mit freundlichem Gruss
Mmmh, es wäre wohl günstiger etwas anderes als SuSE als Grundlage für Server zu verwenden. Ich verwende Deabian und bin recht zufrieden damit. SuSE verzettelt sich eben. Der Versuch eine Distribution für alles zu machen, kann nicht funktionieren. SuSE ist nett wenn man sich am Anfang befindet, weil es eigendlich alles fertig vorkonfiguriert gibt. Bei ernsthaften Projekten kann man SuSE allerdings nicht einsetzen. Das gilt im Übrigen auch für die Server-linie. Sobald Du selber Dinge kompilieren willst/musst würde ich keine 'fette' SuSE mehr einsetzen. mit freundlichen Grüßen Jörg Zimmermann -- .xsiteing agentur für netzkommunikation 42117 wuppertal - friedrich-ebert-str. 141b tel: 0202/3097070 - fax: 0202/3097072
Hi, On 31 Jan 2002 at 8:57, Andre Ruppert wrote:
Zusammengefasst sind das alles lösbare Probleme, aber Sie kosten einfach Zeit, und irgendwann nervt das...
störender ist, daß die SuSEconfig mE. nicht ausreichend dokumentiert ist. Selbst wenn ich per Yast den SuSE Apache deaktiviere versucht SuSEconfig apachebezogene Dateien zu manipulieren )ebenso wenn ich z.B. X11 deaktiviert habe). Ich habe keine Infos zur händischen Manipulation von SuSEconfig gefunden, aber vielleicht bin ich auch nur zu blöd dazu. Tom
Am Don, 31 Jan 2002 schrieb Thomas Michael Wanka:
Hi,
On 31 Jan 2002 at 8:57, Andre Ruppert wrote:
Zusammengefasst sind das alles lösbare Probleme, aber Sie kosten einfach Zeit, und irgendwann nervt das...
störender ist, daß die SuSEconfig mE. nicht ausreichend dokumentiert ist. Selbst wenn ich per Yast den SuSE Apache deaktiviere versucht SuSEconfig apachebezogene Dateien zu manipulieren )ebenso wenn ich z.B. X11 deaktiviert habe). Ich habe keine Infos zur händischen Manipulation von SuSEconfig gefunden, aber vielleicht bin ich auch nur zu blöd dazu.
Ich gebe Dir insofern recht, daß SuSEconfig nicht gut dokumentiert ist (ist glaube ich auch in SuSEs Sinne, die wollen nicht, daß man daran rumspielt). Andererseits ist der Code IIRC einigermaßen kommentiert und ich habe schon einige Veränderungen an SuSEconfig vorgenommen, mit ein paar greps hat man eigentlich gefunden, wo was passiert. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Am Mittwoch, 30. Januar 2002 14:58 schrieb Andre Ruppert:
Hallo an alle,
ich muss hier mal meinen Unmut loswerden:
wir setzen auf unseren Servern hauptsächlich SuSE in den Versionen 6.4 bis 7.2 ein - aber langsam überlege ich mir, ob ich nicht Order erlasse, langsam auf Debian oder etwas anderes umzustellen.
Dies ist nur ein Nachtrag.
Ich habe mich aufgrund der hier gegebenen Anregungen mit FreeBSD
befasst (besser: tue es noch) und zwei Server laufen jetzt unter V4.5.
Ich kann nur sagen - Hut ab. Der Administrationsaufwand hat sich
_jetzt_ schon spürbar verringert .... und die Binärkompatibilität zu
Linux ist bislang völlig ok.
mit freundlichem Gruss
Andre Ruppert
Leitung Technik
participants (9)
-
Andre Ruppert -
Christoph Maurer -
dieter franzke -
Frank Zündorff -
Harry Rüter -
Jörg Zimmermann -
Magnus Rosenbaum -
Michael.Gengenbach＠t-online.de -
Thomas Michael Wanka