Root Server SuSE 10.0 Vs. Debian 3.1

[slkzone]

Hallo an alle,

nachdem mein SuSE 10.0 Server gehackt worden ist, obwohl ich dachte, das ich den Server sicher konfiguriert habe und immer auf den neusten gehalten habe, überlege ich eventuell auf Debian umzusteigen.
Welches Distribution (SuSE 10.0 oder Debian 3.1) ist für den Betrieb Apache(oder Lighttpd), Confixx, MySQL und PHP sicherer ? Bei welcher der beiden Distributionen werden Sicherheitslöcher schneller gestopft?


Vielen Dank

Gruß Lukas

[rootsvr]

Sicherheitslücken werden bei beiden Systemen zeitnah gestopft, schneller kann man schlecht sagen. Ich würde aber vermuten das der Grund deines Hacks nicht am OS, sondern an (PHP)-Scriptproblemen, also unsicherer Websoftware oder nicht aktualisiertem OS liegen, aber das ist alles Dein Problem und wird sich mit nem OS Wechsel nicht ändern.

Wie genau ist der letzte Hack geschehen und was macht dich glauben, dass bei nem OS Wechsel soetwas nicht mehr passiert?

[slkzone]

hi,

ich weiss das bei SuSE beim OnlineUpdate nur die Lücken gestopft werden, beispiel Apache. Aber eine neuere Version wird nicht angeboten. Ich weiss nicht wie es bei Debian ist, ob dort auch nur ein Patch installiert wird oder ob dort eine neuere Verion installiert wird.

[rootsvr]

? Was genau möchstest Du?

Debian ist eine stable Version, d.h. es werden ausschliesslich Sicherheitslücken per backport eingepflegt. Eine neue Version (und neue Features) bekommst du dort nicht, da gegen die release policy. Aber das hat keinerlei Zusammenhang mit deinem Hack (wonach ich gefragt hatte)

Eine Debian Stable 2.0.54-5sarge1 hat die Sicherheitsfixes die auch Apache 2.0.59 eingeführt hat.

Neue Versionen sind nicht sicherer (aber ggf nicht so gut getestet) als gefixte ältere.

[slkzone]

Hallo rootsvr

Ich habe mit SuSE ein schlechtes Gefühl seit dem Novell da mit macht und SuSE wird mir langsam zu kommerziell.
Ich habe von Debian noch nicht soviel Plan, aber da ich mich mit Unix auskenne, vermute ich mal das ich nicht soviel Probleme haben werde.
Ich frage mich nur wenn ich :

Einen SuSE Server 10.0 maximal sicher konfiguriere trotz Server Diensten (Webserver, Datenbank und Mailserver, Confixx)
Und einen Debian Server 3.1 sicher konfiguriere trotz Server Diensten (Webserver, Datenbank und Mailserver, Confixx)
Welcher dann von beiden der sichere Kandidat ist?

Ich weiss das Debian für Stabilität steht da es nicht so aktuell ist,
und SuSE eher aktueller ist.

Ich weiss das Debian 4.0 vor der Tür steht, ist dann ein Update bzw. Upgrade bei einem Root Server möglich ?
Denn bei SuSE ist sowas nur sehr schwer machbar.

[mattiass]

Ich habe mit SuSE ein schlechtes Gefühl seit dem Novell da mit macht und SuSE wird mir langsam zu kommerziell.

Mit openSUSE geht das aber in die andere Richtung...

Einen SuSE Server 10.0 maximal sicher konfiguriere trotz Server Diensten (Webserver, Datenbank und Mailserver, Confixx)
Und einen Debian Server 3.1 sicher konfiguriere trotz Server Diensten (Webserver, Datenbank und Mailserver, Confixx)
Welcher dann von beiden der sichere Kandidat ist?

Der ohne Confixx.

Du solltest auch Ubuntu 6.06 LTS in Erwägung ziehen. Debian-Fundament, etwas aktuellere Software und dennoch langer Support...

[Joe User]

http://www.gentoo.org/proj/en/hardened/index.xml

[rootsvr]

Wie MatthiaS sagte: Der Server ohne Confixx ist der sicherste. *g*

im Ernst: 99% der Hackangriffen kommt zustanden weil z.B. ein altes phpBB oder Mambo genutzt wurde, knapp gefolgt von hirnlosen Admins die root als root Passwort wählen und nicht weil es ein Debian oder SuSE ist.

Ich nutze nur Debian, weil ich yast nicht mag, andere schwören auf SuSE. Im Endeffekt hat das aber wenig Auswirkung auf die Sicherheit.
Debian sollte sich (wenn man Debianpakete nutzt) per Distupgrade auf die neue Version updaten lassen, bei SuSE gibt es imho (wie gesagt keine eigenen Erfahrungen) schnelle Releasezyklen und nicht sooo lange Securityupdates. Debian und Ubuntu LTS sind da unkritischer bei updates und werden länger (Ubuntu LTS 5 Jahre?) gepflegt.

Im Endeffekt trotzdem: wenn Dein SuSE10 System gehackt wurde lag es vermutlich nicht an der Sicherheit von Suse sondern an Fehlerhafter Software oder Schludrigkeit die Du zu verantworten hast.

[oxygen]

Wie MatthiaS sagte: Der Server ohne Confixx ist der sicherste. *g*

Also Confixx hat nicht wirklich einen Einfluss auf die Sicherheit des Systems. Confixx selbst hat in letzter Zeit keine Sicherheitslücken gehabt und es reißt auch keine auf. Da sind schon eher wie bereits erwähnt phpbb, phpnuke + local root exploit die Kandidaten. Aber ob mit oder ohne Confixx macht da keinen Unterschied.

Tendeziell kann man sagen, desdo ungewöhnlicher die Software ist, die man benutzt, desdo geringer ist die Chance das man gehackt wird.
(klingt komisch, is aber so)

[rootsvr]

Nicht so weit verbreitete Software ist halt kein lohnendes Ziel.. Hacker suchen lieber in nem Mambo was auf 200000 Seiten genutzt wird ne Sicherheitslücke, als für Holger sein CMS, was er für seine Homepage geschrieben hat.

Generell tippe ich aber drauf das größere Software besser geschrieben ist und öfter reviewed wird als kleine Projekte - Ausnahmen (M$) bestätigen die Regel.

[paul]

Nach jetzigem Kenntnisstand würde ich ganz klar ein Debian stable aus folgenden Gründen vorziehen:

Es gibt genügend Möglichkeiten ein Debiansystem mit "Hausmitteln" abzusichern.

Geniale Paketverwaltung inkl. Security-Updates.

Ein Upgrade ist möglich und damit "lebenslanger Support" für nicht weniger als 3 Versionen, wovon ich nur eine, und zwar "stable" auf einem Server einsetzen würde.

Hand anlegen muss man immer. Egal welcher Distributor.

[centro]

Also ich bin ja absolut auf Suse eingestellt. Weil ich damit einfach angefangen habe und mich mittlerweile sehr gut eingearbeitet habe.

Gentoo juckt mich nur da blick ich noch viel zu wenig durch.
Debian hat nur APT das Suse auch schon lange kann....

Was mich jetzt eigentlich mehr interessiert da es hier angesprochen wurde.

Aktuelles OS einspielen oder aktuell halten!

Habe Suse 9.3 mit Confixx Prof. ----

Nun S4Y hat momentan noch kein Update auf 10.1 oder 10.0 mit confixx zur verfügung.

Ist es denn Sinnvoll auf 10.0 hoch zu gehen oder ist der Schritt einfach noch nicht so wichtig das man gleich das ganze System platt machen muss?
Mir ist bewusst das 10.0 aktueller ist etc. aber ich mein jetzt speziell ob es sich auf dem Rooti lohnen würde!

[mattiass]

Also ich bin ja absolut auf Suse eingestellt. Weil ich damit einfach angefangen habe und mich mittlerweile sehr gut eingearbeitet habe.

Es spricht auch wenig gegen Suse...

Debian hat nur APT das Suse auch schon lange kann....

Das Vorhandensein von "apt" alleine sagt wenig aus. Wichtig ist auch die Qualität der Paketquellen, deren Pflege etc., da war Debian bislang besser.

Was mich jetzt eigentlich mehr interessiert da es hier angesprochen wurde.

Aktuelles OS einspielen oder aktuell halten!

Habe Suse 9.3 mit Confixx Prof. ----

Nun S4Y hat momentan noch kein Update auf 10.1 oder 10.0 mit confixx zur verfügung.

Wenn das Ding jetzt läuft, dann lasse es erst einmal laufen. Wenn ein Rechner aber sowieso frisch installiert werden muss, würde ich gleich auf Suse 10.1 gehen¹.

10.1 sollte allerdings per Online-Installation (bei Rootservern üblich) drübergebügelt werden, weil sonst ein Bug im Paketmanagement Updates verhindert. Ideal natürlich, wenn Du auf 10.2 (Dezember oder Januar) warten kannst: beim Paketmanagement haben sich noch einige Korrekturen ergeben und Du kannst die Zeit, in der 9.3 noch mit Fixes unterstützt wird, besser ausnutzen.

Rechne aber nicht damit, dass dann ein 10.2-Image mit Confixx dann für Deinen Server bereitsteht: einige Anbieter von Rootservern versuchen durch die Nicht-Zurverfügungstellung aktueller Images einen sanften Druck zum Upgrade auf einen neuen Server auszuüben, der zwar schneller und oft nur wenig teurer ist, aber teils 50 bis 100€ "Wechselgebühren" verursacht. Zudem hilft dieser Umstiegsdruck, alte Server auszumisten, deren sinkende Zahl den Wartungsaufwand in die Höhe treibt.

¹ http://wiki.hetzner.de/index.php/Suse_U ... 8Remote%29
(ich werde diesen Artikel aus dem Hetzner-Wiki wahrscheinlich demnächst dreist kopieren und etwas detailliert und allgemeiner entweder in einen Printartikel oder ins http://blog.rootserverexperiment.de/ packen)

[flo]

¹ http://wiki.hetzner.de/index.php/Suse_U ... 8Remote%29
(ich werde diesen Artikel aus dem Hetzner-Wiki wahrscheinlich demnächst dreist kopieren und etwas detailliert und allgemeiner entweder in einen Printartikel oder ins http://blog.rootserverexperiment.de/ packen)

<OT>
Ach, Du bist das? :-)
</OT>

Bin auch gerade auf der Suche nach neuer Distri für einen Opteron - Favoriten Debian, Ubuntu, Gentoo - in der Reihenfolge.

Ich ziehe SuSE noch nicht einmal in Erwägung - sind aber keine wirklich rationalen Gründe, liegt eher daran, daß die Standard-Versionen von SuSE mir eher Desktop-lastig erscheinen, mit YaST komme ich wohl noch zurecht, aber meine SuSE-Zeiten sind vorbei.

RedHat mag ich überhaupt nicht, auch wenn diese wesentlich an ihren Distris gearbeitet haben, da habe ich aber in letzter Zeit - auch per Fedora - nur Desktops installiert.

Ubuntu bietet sehr nette Features, vor allem der Long-Term-Support ist ein durchaus professionelles Feature, wobei im Rootserverbereich ehr irrelevant - bei der Preisentwicklung würde ich wohl keinen Server länger als 18 bis 24 Monate am Stück betreiben. Dazu das Debian-Paketmanagement.

Gentoo bietet natürlich die Möglichkeit, den Rechner durchzuoptimieren - da ich an einem dedizierten MySQL-Server interessiert bin, ist das kein unwesentlicher Vorteil. Auf dem Opteron dürfte die Installation auch in zwei bis drei Stunden druch sein, wenn überhaupt.

Bei Debian fühle ich mit seit 2003 irgendwie zuhause - ich kenne die Paketwerkzeuge, hab die Remoteinstallation schon öfter gemacht als mir eigentlich lieb war, aber großer Vorteil: Es gibt inzwischen bei den meisten Providern Images dafür. Der Nachteil von Debian - der Apache ist mir zu "verkonfiguriert" - da setze ich lieber eine eigene Variante ein.

Grüße,

flo.

[mattiass]

¹ http://wiki.hetzner.de/index.php/Suse_U ... 8Remote%29
(ich werde diesen Artikel aus dem Hetzner-Wiki wahrscheinlich demnächst dreist kopieren und etwas detailliert und allgemeiner entweder in einen Printartikel oder ins http://blog.rootserverexperiment.de/ packen)

<OT>
Ach, Du bist das? :-)
</OT>

Ja, wer soll es auch sonst sein?

Ich ziehe SuSE noch nicht einmal in Erwägung - sind aber keine wirklich rationalen Gründe, liegt eher daran, daß die Standard-Versionen von SuSE mir eher Desktop-lastig erscheinen, mit YaST komme ich wohl noch zurecht, aber meine SuSE-Zeiten sind vorbei.

rug ist mal was richtig feines. Hat IMHO mehr Potential als apt.

... bei der Preisentwicklung würde ich wohl keinen Server länger als 18 bis 24 Monate am Stück betreiben. Dazu das Debian-Paketmanagement.

Ich habe jetzt eine Kiste, die fast vier Jahre lang immer brav aktualisiert wurde und auch schon einen Hardwarewechsel hinter sich hat. Erst vor ein paar Wochen alle Kunden auf einen Jail gepackt und auf einen anderen Server geschoben um den Rechner mal platt machen zu können. Mit dem richtigen Betriebssystem kein Problem. Hint: Linux ist es nicht.

Gentoo bietet natürlich die Möglichkeit, den Rechner durchzuoptimieren - da ich an einem dedizierten MySQL-Server interessiert bin, ist das kein unwesentlicher Vorteil. Auf dem Opteron dürfte die Installation auch in zwei bis drei Stunden druch sein, wenn überhaupt.

Bei Gentoo mag nich nicht, dass die Trennung in eine stabile Basis und einen aktuellen Rest fehlt. Da ist das Original weit pflegeleichter.

Bei Debian fühle ich mit seit 2003 irgendwie zuhause - ich kenne die Paketwerkzeuge, hab die Remoteinstallation schon öfter gemacht als mir eigentlich lieb war, aber großer Vorteil: Es gibt inzwischen bei den meisten Providern Images dafür.

...die aber in den seltensten Fällen wirklich gut sind!

Gedankennotiz: endlich mal das Tutorial schreiben, wie man auf Linux-Rootservern das Linux wegmacht und richtige Betriebssysteme installiert!

[flo]

Erst vor ein paar Wochen alle Kunden auf einen Jail gepackt und auf einen anderen Server geschoben um den Rechner mal platt machen zu können. Mit dem richtigen Betriebssystem kein Problem. Hint: Linux ist es nicht.

Bis wohl so ein BSD'ler???? :-) Ich ja irgendwie auch ... unterm GUI :-)

Bei Gentoo mag nich nicht, dass die Trennung in eine stabile Basis und einen aktuellen Rest fehlt. Da ist das Original weit pflegeleichter.

Das nervt mich z.B. auf dem Desktop - USE-Flag vergessen und einfach mal über Nacht kompilieren lassen müssen.

...die aber in den seltensten Fällen wirklich gut sind!

Aber brauchbarer als die meisten SuSE-Images, bei denen ist nämlich i.d.R. auch noch Plesk und Serveradmin und wie sie alle heißen, dabei. :-(

Im Ernst - Images, die einfach eine 08/15-Basisinsallation neu abbilden, gibt es wohl genügend, aber wird sind bei Rootservern nunmal in zwei Fraktionen aufgeteilt. Diejenigen, die eh spezielle Ansprüche stellen (Partitionierung usw.) werden durch ein providerseitiges Image nie zufriedengestellt. Und den anderen kommen Images für die Neuinstallation nach dem gehackt-werden einfach gelegen.

flo.

[oxygen]

Bei Gentoo mag nich nicht, dass die Trennung in eine stabile Basis und einen aktuellen Rest fehlt. Da ist das Original weit pflegeleichter.

Verstehe ich nicht ganz. Das ist doch gerade der Vorteil gegenüber Debian/SuSE/etc. Man installiert sich ein stabiles Basis System, also alles x86 und wenn man vereinzelt neuere Versionen von Paketen braucht z.B. Kernel oder PHP installiert man davon die ~x86 Version.
Man muss sich nicht mit Backports rumschlagen und alle Abhängigkeiten werden trotzdem korrekt aufgelöst. Außerdem hat man dann auch anderen Anwendungen gegen die aktuellen Libary kompiliert (z.B. in PHP die aktuelle MySQL Client Libary). Mit einem PaketSystem wie rug oder apt ist das nicht möglich. Da müsste man dann wieder zum selbst kompilieren greifen...

[mattiass]

Bei Gentoo mag nich nicht, dass die Trennung in eine stabile Basis und einen aktuellen Rest fehlt. Da ist das Original weit pflegeleichter.

Verstehe ich nicht ganz. Das ist doch gerade der Vorteil gegenüber Debian/SuSE/etc. Man installiert sich ein stabiles Basis System, also alles x86 und wenn man vereinzelt neuere Versionen von Paketen braucht z.B. Kernel oder PHP installiert man davon die ~x86 Version.
Man muss sich nicht mit Backports rumschlagen und alle Abhängigkeiten werden trotzdem korrekt aufgelöst. Außerdem hat man dann auch anderen Anwendungen gegen die aktuellen Libary kompiliert (z.B. in PHP die aktuelle MySQL Client Libary). Mit einem PaketSystem wie rug oder apt ist das nicht möglich. Da müsste man dann wieder zum selbst kompilieren greifen...

Mit dem Original meine ich FreeBSD.

Du fährst dort 6.1 als Basis und aktualisierst immer auf das aktuelle Patchlevel und hast damit die Garantie, dass Dein Basissystem (Kernel, C-Bibliothek, grundlegendes Userland, Toolchain und einige kleineren Daemonen) zusammenpassen. Den Rest installierst Du aus den tagesaktuellen Ports, die Dir auch die Wahl lassen, php4 oder php5 oder mysql41, mysql50 oder mysql51 zu verwenden.

Aber die Trennung ist ganz klar und viel deutlicher als wenn Du bei Gentoo einzelne Pakete auf einzelnen Versionsständen festnagelst und nach einem Update avon 6.1 auf 7.0 weisst Du, dass wenigstens das Basissystem sauber läuft. Dass Du möglichwerweise alle Ports rekursiv durchkompilieren musst, ist eine andere Geschichte (ich bereite dann immer Packages in einem Jail zuhause vor und synce die auf die Produktivmaschine um Downtimes gering zu halten.

Gentoo ist nett, aber eben weit frickeliger als FreeBSD. Das dürfte die Ursache sein, dass man über mehr FreeBSD-Kisten als über Gentoo-Server stolpert... 8)

[oxygen]

Mir ist schon klar, dass du FreeBSD meinst und ich weiß auch wie es funktioniert, da ich es selbst eine Zeit lang benutzt hab. So Version 4 rum. Aus meiner Sicht waren die Ports da viel frickeliger.
Mehr schlecht als recht funktionierende Paketabhängigkeiten.
umständliche und unzuverlässige Deinstallation.
Nicht vorhandes apt-get upgrade / emerge -uD world.
Auch fehlt ein feature wie revdep-rebuild, dass nach eine Version Upgrade abhängige Pakete findet und neukompiliert. Da bleibt bei FreeBSD nur wie du selbst sagst "alle Ports rekursiv durchkompilieren".

Vielleicht hat FreeBSD ein robusteres Basis System (ich hatte mit beidem nie Probleme), aber auf das ganze System bezogen ist die Paketverwaltung von Gentoo stabiler. Es hat zwar eine sehr hohen Grad an Automatisierung, das die Verwaltung unkompliziert und zügig macht und außerdem wenig Fehler zulässt, bietet doch aber 100%ige Kontrolle über die Pakete.

[mattiass]

Mehr schlecht als recht funktionierende Paketabhängigkeiten.
umständliche und unzuverlässige Deinstallation.
Nicht vorhandes apt-get upgrade / emerge -uD world.
Auch fehlt ein feature wie revdep-rebuild, dass nach eine Version Upgrade abhängige Pakete findet und neukompiliert. Da bleibt bei FreeBSD nur wie du selbst sagst "alle Ports rekursiv durchkompilieren".

Ich wüsste nicht, wo das Problem bei "portupgrade" ist? Es kennt upward-recursive und downward-recursive, was ein zuviel an kompilierten Paketen in der Regel erspart und geänderte Schnittstellen berücksichtigt.

Code: Select all

cvsup -L 2 -g /etc/cvsup.ports
portsdb -Uu
portupgrade -akpRr

aktualisiert Portstree und Portsdatenbank und baut dann alle aktualisierten Ports neu, rekursiv in beide Richtungen -- würde ich ein "-f" hinzufügen, würde er wirklich alle Pakete neu bauen. Es werden dabei Pakete erstellt, die auf Rechnern mit dem gleichen Softwarebedarf (und per NFS oder nullfs eingemountetem Portstree vom Master) mit

Code: Select all

portupgrade -akPRr

dann installiert werden. Erleichtert ganz stark die Wartung vieler ähnlich konfigurierter Jails.

Schnittstellenänderungen zwischen Basissystem und aufgesetzten Ports kommen extrem selten vor, so dass praktisch nie nach für Sicherheitsupdates durchgeführtem...

Code: Select all

cvsup -L 2 -g /etc/cvsup.base
cd /usr/src
make buildworld
make buildkernel
make installkernel
make installworld

...Ports rekompiliert werden müssen.

Alle Ports rekursiv durchzukompilieren ist allerdings auch bei Linux nach ganz massiven Änderungen an der C-Bibliothek nötig. Ich wüsste nicht, wie Du sonst nach einem Update der Glibc von 2.2 auf 2.4 Dein OS stabil halten möchtest...

Vielleicht hat FreeBSD ein robusteres Basis System (ich hatte mit beidem nie Probleme), aber auf das ganze System bezogen ist die Paketverwaltung von Gentoo stabiler. Es hat zwar eine sehr hohen Grad an Automatisierung, das die Verwaltung unkompliziert und zügig macht und außerdem wenig Fehler zulässt, bietet doch aber 100%ige Kontrolle über die Pakete.

Nun. Das was Ihr Gentooler USE-Flags nennt, gibt es bei FreeBSD auch: zum einen systemweit in der /etc/make.conf, zum anderen portspezifisch in der /usr/local/etc/pkgtools.conf. So wird gerade die Paketverwaltung unter FreeBSD stabiler als die von Gentoo.

Ja, portupgrade gab es bei 3.x noch nicht, aber zu dieser Zeit gab es auch noch kein Gentoo, gegen das FreeBSD anstinken musste.

[blnsnoopy26]

Hi,

Suse 10.1 hat ja auch das apt standardmässig mit drinnen.
hab mir das heute mal unter vmware installiert und ist sehr komfortable :)

Bietet den selben Komfort, wie unter Debian

[mattiass]

Suse 10.1 hat ja auch das apt standardmässig mit drinnen.
hab mir das heute mal unter vmware installiert und ist sehr komfortable :)

Bietet den selben Komfort, wie unter Debian

Ja, aber man sollte eher "rug" nutzen. Das Meta-Paketmanagementwerkzeug kann recht gut die unterschiedlichen Paketquellen nutzen: Verzeichnis mit RPMs, Yast-Paketquelle, Yum-Paketquelle, Apt-Repository...

Leider sind "rug" und der "zmd" etwas lahmarschig...

[blnsnoopy26]

Kann ich jetzt nicht so beurteilen, daher unter vmware es generell etwas langsamer ist mit dem paket Managment oder ich hab ein lahmen Mirror ...k.a.

Jedenfalls teste ich da mal ein wenig rum und mal schaun, was sich da alles neu ist

Derzeit fahre ich ja noch mit suse 9.3.
Hab auch noch unter vmware nen Debian Server aufgesetzt, aber irgendwie komme ich da nie richtig mit zurecht :-D

Aber dank SuSE 10.1 kann ich apt und yast verwenden. Bei den vorherigen versionen (9.3) konnte man sich das auch installieren, aber dann gabs Probleme mit yast.

Unter SuSE kann ich nun beides ausprobieren und was ich bisher sah - war recht gut, aber mal sehn was so weitere tests ergeben.

Hab die Network Install und Minimal Installation genommen - also ein recht schlankes System derzeit.

[mattiass]

Aber dank SuSE 10.1 kann ich apt und yast verwenden. Bei den vorherigen versionen (9.3) konnte man sich das auch installieren, aber dann gabs Probleme mit yast.

Probier mal das:

http://en.opensuse.org/Using_rug

[blnsnoopy26]

Hab mal das Beispiel dort eingegeben:

Code: Select all

linux:~ # rug ping
ZMD 7.1.1, Copyright (C) 2006 Novell, Inc.
Started at 09/08/2006 13:38:33 (uptime: 0 days, 0 hours, 43 minutes)
RSS size: 23872
Network Connected: Yes
Running on Mono 1.1.13.8

OS Target: SUSE Linux 10.1 (i586)

Module Name        | Description
-------------------+------------------------------------------
NetworkManager     | NetworkManager support
Package Management | Package Management module for Linux
ZENworks Server    | SOAP methods used by a ZENworks server
XML-RPC interface  | Export ZMD public interfaces over XML-RPC

Code: Select all

linux:~ # rug service-list

# | Status | Type | Name                                       | URI
--+--------+------+--------------------------------------------+----------------
1 | Active | ZYPP | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 | ftp://134.76...

Code: Select all

linux:~ # rug search apache2

S | Catalog                                    | Bundle | Name                             | Version  | Arch
--+--------------------------------------------+--------+----------------------------------+----------+-----
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2                          | 2.2.0-21 | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-debuginfo                | 2.2.0-21 | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-devel                    | 2.2.0-21 | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-doc                      | 2.2.0-21 | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-example-pages            | 2.2.0-21 | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-mod_auth_mysql           | 3.0.0-14 | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-mod_auth_mysql-debuginfo | 3.0.0-14 | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-mod_fcgid                | 1.07-14  | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-mod_fcgid-debuginfo      | 1.07-14  | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-mod_macro                | 1.1.6-19 | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-mod_macro-debuginfo      | 1.1.6-19 | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-mod_perl                 | 2.0.2-14 | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-mod_perl-debuginfo       | 2.0.2-14 | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-mod_php5                 | 5.1.2-27 | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-mod_python               | 3.1.3-60 | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-mod_python-debuginfo     | 3.1.3-60 | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-mod_scgi                 | 1.9-15   | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-mod_tidy                 | 0.5.5-13 | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-mod_tidy-debuginfo       | 0.5.5-13 | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-mod-apparmor             | 2.0-21   | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-prefork                  | 2.2.0-21 | i586
  | SUSE-Linux-10.1-FTP-10.1-0-20060908-114201 |        | apache2-worker                   | 2.2.0-21 | i586

Code: Select all

linux:~ # rug install apache2
Resolving Dependencies...

The following packages will be installed:
  apache2 2.2.0-21 (ftp://134.76.11.100/%2fpub/opensuse/distribution/SL-10.1/inst-source?alias=SUSE-Linux-10.1-FTP-10.1-0-20060908-114201)
  apache2-prefork 2.2.0-21 (ftp://134.76.11.100/%2fpub/opensuse/distribution/SL-10.1/inst-source?alias=SUSE-Linux-10.1-FTP-10.1-0-20060908-114201)
    apache2-prefork-2.2.0-21.i586[SUSE-Linux-10.1-FTP-10.1-0-20060908-114201] needed by apache2-2.2.0-21.i586[SUSE-Linux-10.1-FTP-10.1-0-20060908-114201]

  libapr1 1.2.2-11 (ftp://134.76.11.100/%2fpub/opensuse/distribution/SL-10.1/inst-source?alias=SUSE-Linux-10.1-FTP-10.1-0-20060908-114201)
    libapr1-1.2.2-11.i586[SUSE-Linux-10.1-FTP-10.1-0-20060908-114201] needed by apache2-2.2.0-21.i586[SUSE-Linux-10.1-FTP-10.1-0-20060908-114201]

  libapr-util1 1.2.2-13 (ftp://134.76.11.100/%2fpub/opensuse/distribution/SL-10.1/inst-source?alias=SUSE-Linux-10.1-FTP-10.1-0-20060908-114201)
    libapr-util1-1.2.2-13.i586[SUSE-Linux-10.1-FTP-10.1-0-20060908-114201] needed by apache2-2.2.0-21.i586[SUSE-Linux-10.1-FTP-10.1-0-20060908-114201]


Proceed with transaction? (y/N)

ganz net gemacht :lol:
Konkurenz zu apt oder wie? :lol: