Yast suse enterprise 10 packetquellen

[ArnulfB]

Hallo
Ich habe einen Suse enterprise server übertragen bekommen.
Leider hatte ich mit suse sogut wie nie etwas zu tun.
Jedenfalls sagt er bei System Update:


Das installierte Produkt ist nicht kompatiblel zum Produkt auf dem Installationsmedium. Wenn sie mit dem derzeitigen Installationsmedium aktualisieren, wird das System möglicherweise nicht starten oder einige Applikationen werden möglicherweise nicht richtig funktionieren.

Software installieren oder löschen:

Keine Installationsquelle definiert

mit apt wüsste ich welche quellen in nehmen könnte, aber bei einem suse enterprise server - da finde ich keine quellen die ich mit yast benutzbar sind.
Also kann ich ja "installationsquelle wechseln", aber wo finde ich für meinen Server aktuelle packete?

Welcome to SUSE Linux Enterprise Server 10 (x86_64) - Kernel \r (\l).

[honkstar]

Wenn der Server per Novell Customer Center einmal bei Novell registriert wurde, sollten die Quellen automatisch eingetragen werden. Habt ihr den irgendne Lizenz von Novell für den SLES?

[ArnulfB]

Tja wenn ich das wüsste
ich hab zwar eine doku bekommen, aber keine lizenz für den suse enterprise.
ob es jemals eine gab weiß ich leider auch nicht.
Wir haben nur einen weiteren SLES server übernommen bei dem ein login existiert und die quellen auch angegeben sind.
ich wollte die schon klonen - bin mir aber unsicher...
ich frage mich auch ob ich open suse quellen verwenden kann zum beispiel:
http://ftp.gwdg.de/pub/opensuse/distribution/11.0/repo/oss

oder ähnliches.
Es ist auch möglich, dass ich den kunden informieren muss, dass keine lizenz vorhanden ist.

[marce]

Wir haben nur einen weiteren SLES server übernommen bei dem ein login existiert und die quellen auch angegeben sind.
ich wollte die schon klonen - bin mir aber unsicher...
Keine gute Idee - das wird nicht funktionieren.


ich frage mich auch ob ich open suse quellen verwenden kann zum beispiel:
http://ftp.gwdg.de/pub/opensuse/distribution/11.0/repo/oss
Auch das wird nicht funktionieren.

[ArnulfB]

nagut dann bitte ich um alternativen.
1. server migrieren auf open suse oder gleich debian.
2. lizenz bei novell kaufen und packetquellen eintragen.
3. ?????

oder sehe ich das falsch?

[marce]

1. server migrieren auf open suse
OS ist für Produktiveinsatz eigentlich nicht geeignet - keine qualifizierten Patches und zu kurze Lifetime


oder gleich debian.
Auch wenn mich viele nun hassen werden: Debian hat sich in den letzen Jahren eigentlich für den professionellen Servereinsatz qualifiziert.

Kann man aber machen - auch je nach dem, was auf dem Ding laufen muss...


2. lizenz bei novell kaufen und packetquellen eintragen.
Die einfachste Lösung.


3. ?????
z.B. Umstieg auf ein anderes Enterprise-OS oder einen freien Clon davon, z.B. CentOS, ...

[ArnulfB]

herzlichen dank.
ich wusste mit dem novell server nichts anzufangen :)

lg
Arnulf

[newton]

Oder Du probierst
http://demeter.uni-regensburg.de/.

[ArnulfB]

hm ... darf ich das?
wir werden wohl migrieren, aber trotzdem scheinen die quellen zu funktionieren.

lg
Arnulf

[newton]

hm ... darf ich das?
Gute Frage, wuerde mich auch mal interessieren.
Oder, um die Frage anders zu stellen: Duerfen DIE das?

[marce]

Prinzipiell steht auch der SLES (großteils) unter der GPL. Das heißt, das Suse für die entsprechenden Programme die Quellen zur Verfügung stellen muss (ebenso wie z.B. RH beim RHEL).

Aus diesen Quellen kann natürlich jeder die entsprechenden Pakete bauen. Dagegen kann nichts gesagt werden - es entspricht der Lizenz.

Ob diese Pakete dann id. zu den originalen SLES-Paketen sind oder nicht kann ohne direkten Vergleich aber keiner sagen.

Ob es rechtens wäre, einfach ein Spiegel des originalen SLES-Repos dort abzulegen kann ich nicht sagen - vermutlich aber nein.

Wie diese Pakete auf dem o.g. System zustande kommen - keine Ahnung.


Disclaimer: Dieser Beitrag ist keine Rechtsberatung und stellt keine rechtsgültige Informationsquelle dar.

[Rain_maker]

Von der rechtlichen Lage mal abgesehen, wenn man sich mal anschaut, was da genau auf dem Server liegt, sind sie allerdings eh keine Lösung für Produktivsysteme.

Da liegen die originalen Installationsquellen und die Servicepacks, für die Versorgung mit _aktuellen_ Sicherheitsupdates also vollkommen unzureichend.

//Edit:

Ein paar einzelne Patches findet man auch, nur das sind 100%ig nicht alle und Repositories, welche man im Paketmanager einbinden kann, sind es ebenfalls keine.