Liebe Leute,
früher, ganz früher, da hatten wir hier relativ gut ausgestattete Rechner ("Server"), die gleichzeitig von mehreren Nutzern verwendet wurden. Dazu saßen die Nutzer nicht direkt am Server, sondern an einem X-Terminal.
Das möchte ich jetzt gerne so ähnlich reproduzieren. Als Server käme ein unter Tumbleweed laufender Rechner zum Einsatz, statt eines X-Terminals möchte ich einen Raspberry Pi verwenden.
Doch leider habe ich überhaupt nicht mehr im Kopf, wie man so etwas konfigurieren muss. Was muss ich dem Server, was dem Terminal sagen, damit sie sich richtig verhalten? Ein einfaches "startx -- <ip vom Server>" hat jedenfalls nicht funktioniert.
Gibt es irgendwo eine Beschreibung? Wenn ich nach Raspberry Pi und X oder X11 suche, bekomme ich nur antworten, wie man sich von einem Rechner auf dem Pi per ssh so einloggt, dass man X-Anwendungen grafisch nutzen kann. Ich will's ja umgekehrt haben und ohne ssh.
Wer weiß noch, wie das geht?
Herzliche Grüße Jan
HallooAm Mittwoch, den 12.04.2017, 10:12 +0200 schrieb Handwerker, Jan (IMK):
Liebe Leute,
früher, ganz früher, da hatten wir hier relativ gut ausgestattete Rechner ("Server"), die gleichzeitig von mehreren Nutzern verwendet wurden. Dazu saßen die Nutzer nicht direkt am Server, sondern an einem X-Terminal.
Das möchte ich jetzt gerne so ähnlich reproduzieren. Als Server käme ein unter Tumbleweed laufender Rechner zum Einsatz, statt eines X-Terminals möchte ich einen Raspberry Pi verwenden.
Doch leider habe ich überhaupt nicht mehr im Kopf, wie man so etwas konfigurieren muss. Was muss ich dem Server, was dem Terminal sagen, damit sie sich richtig verhalten? Ein einfaches "startx -- <ip vom Server>" hat jedenfalls nicht funktioniert.
Gibt es irgendwo eine Beschreibung? Wenn ich nach Raspberry Pi und X oder X11 suche, bekomme ich nur antworten, wie man sich von einem Rechner auf dem Pi per ssh so einloggt, dass man X-Anwendungen grafisch nutzen kann. Ich will's ja umgekehrt haben und ohne ssh.
Wer weiß noch, wie das geht?
buh ja das war schon lange her ich hatte am client XDMCP oder xdm oder so am laufen da konnte man dann zwischen mehreren XServer auswählen die im Netz verfügbar waren. In der xdm-config musste man noch 3 Dinge freischlaten Xservers und Xaccess oder so.
Es gibt von SuSE aber auch ein Kiwi Projekt zu Thin Clients und Diskless Clients https://doc.opensuse.org/projects/kiwi/doc/#chap.pxe
Gruß Torsten
Handwerker, Jan (IMK) schrieb:
Liebe Leute,
früher, ganz früher, da hatten wir hier relativ gut ausgestattete Rechner ("Server"), die gleichzeitig von mehreren Nutzern verwendet wurden. Dazu saßen die Nutzer nicht direkt am Server, sondern an einem X-Terminal.
Gibt es irgendwo eine Beschreibung? Wenn ich nach Raspberry Pi und X oder X11 suche, bekomme ich nur antworten, wie man sich von einem Rechner auf dem Pi per ssh so einloggt, dass man X-Anwendungen grafisch nutzen kann. Ich will's ja umgekehrt haben und ohne ssh.
Wer weiß noch, wie das geht?
einfach mit VNC?
auf dem Server mit Yast -Administration entfernter Rechner aktivieren auf den Clients ein VNC-Client deiner Wahl ....
Beste Grüße
Lutz
Hallo Lutz,
Am 12.04.2017 um 10:28 schrieb Lutz Nülle:
Handwerker, Jan (IMK) schrieb:
Liebe Leute,
früher, ganz früher, da hatten wir hier relativ gut ausgestattete Rechner ("Server"), die gleichzeitig von mehreren Nutzern verwendet wurden. Dazu saßen die Nutzer nicht direkt am Server, sondern an einem X-Terminal.
einfach mit VNC?
das ist zu wenig performant. VNC überträgt ja den Bildschirm als Grafik. Eine echte X-Verbindung würde X-Befehle schicken, die deutlich schneller ausgeführt werden können. Außerdem habe ich mit VNC dann schlecht Erfahrungen, wenn man z.B. die Alt-Taste mal gedrückt hat. Dann muss man sie oft noch einmal drücken, bevor man wieder normal im VNC-Fenster arbeiten muss. - Leute, die das nicht wissen, verzweifeln dann.
Trotzdem vielen Dank, dass Du über mein Problem nachgedacht hast.
Herzliche Grüße Jan
Am Mittwoch, den 12.04.2017, 10:12 +0200 schrieb Handwerker, Jan (IMK):
Liebe Leute,
früher, ganz früher, da hatten wir hier relativ gut ausgestattete Rechner ("Server"), die gleichzeitig von mehreren Nutzern verwendet wurden. Dazu saßen die Nutzer nicht direkt am Server, sondern an einem X-Terminal.
Das möchte ich jetzt gerne so ähnlich reproduzieren. Als Server käme ein unter Tumbleweed laufender Rechner zum Einsatz, statt eines X-Terminals möchte ich einen Raspberry Pi verwenden.
Doch leider habe ich überhaupt nicht mehr im Kopf, wie man so etwas konfigurieren muss. Was muss ich dem Server, was dem Terminal sagen, damit sie sich richtig verhalten? Ein einfaches "startx -- <ip vom Server>" hat jedenfalls nicht funktioniert.
Gibt es irgendwo eine Beschreibung? Wenn ich nach Raspberry Pi und X oder X11 suche, bekomme ich nur antworten, wie man sich von einem Rechner auf dem Pi per ssh so einloggt, dass man X-Anwendungen grafisch nutzen kann. Ich will's ja umgekehrt haben und ohne ssh.
Wer weiß noch, wie das geht?
ah hier kann man das jetzt Einstellen /etc/sysconfig/displaymanager
DISPLAY_MANAGER_REMOTE_ACCESS PORT und Remote Root
Hallo.
On Wednesday 12 April 2017 10:12:35 Handwerker, Jan (IMK) wrote:
Liebe Leute,
früher, ganz früher, da hatten wir hier relativ gut ausgestattete Rechner ("Server"), die gleichzeitig von mehreren Nutzern verwendet wurden. Dazu saßen die Nutzer nicht direkt am Server, sondern an einem X-Terminal.
Das möchte ich jetzt gerne so ähnlich reproduzieren. Als Server käme ein unter Tumbleweed laufender Rechner zum Einsatz, statt eines X-Terminals möchte ich einen Raspberry Pi verwenden.
Doch leider habe ich überhaupt nicht mehr im Kopf, wie man so etwas konfigurieren muss. Was muss ich dem Server, was dem Terminal sagen, damit sie sich richtig verhalten? Ein einfaches "startx -- <ip vom Server>" hat jedenfalls nicht funktioniert.
Gibt es irgendwo eine Beschreibung? Wenn ich nach Raspberry Pi und X oder X11 suche, bekomme ich nur antworten, wie man sich von einem Rechner auf dem Pi per ssh so einloggt, dass man X-Anwendungen grafisch nutzen kann. Ich will's ja umgekehrt haben und ohne ssh.
Wer weiß noch, wie das geht?
Herzliche Grüße Jan
Ich habe hier einige aeltere Workstations unter Debian Linux laufen, meist ohne angeschlossenen Monitor.
Auf der Serverseite (in meinem Fall Sun-Workstation) musst Du den Display Manager so konfigurieren, dass er Remote-Verbindungen via XDMCP zulaesst. Ist unterschiedlich, je nachdem ob Du xdm, kdm, gdm, lightdm verwendest, sie funktionieren aber alle.
Clientseitig starte ich die Verbindung dann von der grafischen Oberflache (bei mir meist XFCE4) aus einem Terminalfenster, bei XFCE z.B. xfce4-terminal. Zuerst fuer dieses Fenster root werden, dann Verbindungsaufbau ueber XDMCP:
X :1 -query <hostname>
Damit kriegst du auf dem virtuellen Bildschilm hinter z.B. <CTRL><ALT>F8 ein zweites X mit Anmeldefenster fuer den Server, da springt die Anzeige auch direkt hin. Zurueck auf's lokale X dann mit <CTRL><ALT>F7 (Die F-Nummern sind nicht immer die hier angegebenen).
Funktioniert auch mit dem Raspberry Pi, allerdings nutze ich's umgekehrt: kein Monitor am Raspberry Pi.
Gruss,
Hartwig
Hallo!
----------------------- Am Mittwoch, 12. April 2017 um 12:00 schrieb Hartwig Atrops:
Auf der Serverseite (in meinem Fall Sun-Workstation) musst Du den Display Manager so konfigurieren, dass er Remote-Verbindungen via XDMCP zulaesst. Ist unterschiedlich, je nachdem ob Du xdm, kdm, gdm, lightdm verwendest, sie funktionieren aber alle.
Clientseitig starte ich die Verbindung dann von der grafischen Oberflache (bei mir meist XFCE4) aus einem Terminalfenster, bei XFCE z.B. xfce4-terminal. Zuerst fuer dieses Fenster root werden, dann Verbindungsaufbau ueber XDMCP:
X :1 -query <hostname>
Damit kriegst du auf dem virtuellen Bildschilm hinter z.B. <CTRL><ALT>F8 ein zweites X mit Anmeldefenster fuer den Server, da springt die Anzeige auch direkt hin. Zurueck auf's lokale X dann mit <CTRL><ALT>F7 (Die F-Nummern sind nicht immer die hier angegebenen).
Kann man dem X Client irgendwie mitteilen, auf welche IP Adresse er sich verbinden soll?
Ich möchte das über VPN betreiben und der Client möchte sich mit meiner LAN-IP verbinden. Die gibt es jenseits der VPN ebenso wenig wie eine Route zu mir.
Gruß
Richard
Moin, moin.
On Wednesday 12 April 2017 22:33:16 Richard Hafenscher wrote:
Hallo!
Am Mittwoch, 12. April 2017 um 12:00 schrieb Hartwig Atrops:
Auf der Serverseite (in meinem Fall Sun-Workstation) musst Du den Display Manager so konfigurieren, dass er Remote-Verbindungen via XDMCP zulaesst. Ist unterschiedlich, je nachdem ob Du xdm, kdm, gdm, lightdm verwendest, sie funktionieren aber alle.
Clientseitig starte ich die Verbindung dann von der grafischen Oberflache (bei mir meist XFCE4) aus einem Terminalfenster, bei XFCE z.B. xfce4-terminal. Zuerst fuer dieses Fenster root werden, dann Verbindungsaufbau ueber XDMCP:
X :1 -query <hostname>
Damit kriegst du auf dem virtuellen Bildschilm hinter z.B. <CTRL><ALT>F8 ein zweites X mit Anmeldefenster fuer den Server, da springt die Anzeige auch direkt hin. Zurueck auf's lokale X dann mit <CTRL><ALT>F7 (Die F-Nummern sind nicht immer die hier angegebenen).
Kann man dem X Client irgendwie mitteilen, auf welche IP Adresse er sich verbinden soll?
Ich möchte das über VPN betreiben und der Client möchte sich mit meiner LAN-IP verbinden. Die gibt es jenseits der VPN ebenso wenig wie eine Route zu mir.
Gruß
Richard
Hm, mit VPN habe ich keine Erfahrung. Aber Du kannst als Parameter entweder den Hostname oder die IP-Adresse angeben, also z.B.:
X :1 -query tralala
oder
X :1 -query 192.168.47.11
Schreib mal, was rausgekommen ist, VPN muss ich mir demnaechst auch ansehen.
Gruss,
Hartwig
Hallo,
----------------------- Am Donnerstag, 13. April 2017 um 08:37 schrieb Hartwig Atrops:
Moin, moin.
On Wednesday 12 April 2017 22:33:16 Richard Hafenscher wrote:
Hallo!
Am Mittwoch, 12. April 2017 um 12:00 schrieb Hartwig Atrops:
Auf der Serverseite (in meinem Fall Sun-Workstation) musst Du den Display Manager so konfigurieren, dass er Remote-Verbindungen via XDMCP zulaesst. Ist unterschiedlich, je nachdem ob Du xdm, kdm, gdm, lightdm verwendest, sie funktionieren aber alle.
Clientseitig starte ich die Verbindung dann von der grafischen Oberflache (bei mir meist XFCE4) aus einem Terminalfenster, bei XFCE z.B. xfce4-terminal. Zuerst fuer dieses Fenster root werden, dann
Verbindungsaufbau ueber XDMCP: X :1 -query <hostname>
Damit kriegst du auf dem virtuellen Bildschilm hinter z.B. <CTRL><ALT>F8 ein zweites X mit Anmeldefenster fuer den Server, da springt die Anzeige auch direkt hin. Zurueck auf's lokale X dann mit <CTRL><ALT>F7 (Die F-Nummern sind nicht immer die hier angegebenen).
Kann man dem X Client irgendwie mitteilen, auf welche IP Adresse er sich verbinden soll?
Ich möchte das über VPN betreiben und der Client möchte sich mit meiner LAN-IP verbinden. Die gibt es jenseits der VPN ebenso wenig wie eine Route zu mir.
Gruß
Richard
Hm, mit VPN habe ich keine Erfahrung. Aber Du kannst als Parameter entweder den Hostname oder die IP-Adresse angeben, also z.B.:
X :1 -query tralalaoder
X :1 -query 192.168.47.11
Schreib mal, was rausgekommen ist, VPN muss ich mir demnaechst auch ansehen.
den Rechner, mit dem ich mich verbinden wollte, habe ich natürlich eh angegeben, meine eigene IP wollte ich mitgeben, damit der sich mit meinem X Server verbindet. Der X Server schickt nämlich standardmäßig meine LAN-IP mit, die wird aber im Remote-Netz nicht geroutet (VPN), weil unbekannt. Ich muss daher meine VPN-IP mitgeben.
Wenn man sich aber die Mühe macht und die Help liest, findet man das auch heraus. ;-) Muss ich erst übersehen haben.
So gehts: X :1 -query <Remote-Host> -from <eigene IP>
Dann noch meine Firewall geöffnet und ich sehe den Remote-Desktop. :-)
Gruß
Richard
Hi.
On Thursday 13 April 2017 22:25:22 Richard Hafenscher wrote:
Hallo,
Am Donnerstag, 13. April 2017 um 08:37 schrieb Hartwig Atrops:
Moin, moin.
On Wednesday 12 April 2017 22:33:16 Richard Hafenscher wrote:
Hallo!
Am Mittwoch, 12. April 2017 um 12:00 schrieb Hartwig Atrops:
Auf der Serverseite (in meinem Fall Sun-Workstation) musst Du den Display Manager so konfigurieren, dass er Remote-Verbindungen via XDMCP zulaesst. Ist unterschiedlich, je nachdem ob Du xdm, kdm, gdm, lightdm verwendest, sie funktionieren aber alle.
Clientseitig starte ich die Verbindung dann von der grafischen Oberflache (bei mir meist XFCE4) aus einem Terminalfenster, bei XFCE z.B. xfce4-terminal. Zuerst fuer dieses Fenster root werden, dann
Verbindungsaufbau ueber XDMCP: X :1 -query <hostname>
Damit kriegst du auf dem virtuellen Bildschilm hinter z.B. <CTRL><ALT>F8 ein zweites X mit Anmeldefenster fuer den Server, da springt die Anzeige auch direkt hin. Zurueck auf's lokale X dann mit <CTRL><ALT>F7 (Die F-Nummern sind nicht immer die hier angegebenen).
Kann man dem X Client irgendwie mitteilen, auf welche IP Adresse er sich verbinden soll?
Ich möchte das über VPN betreiben und der Client möchte sich mit meiner LAN-IP verbinden. Die gibt es jenseits der VPN ebenso wenig wie eine Route zu mir.
Gruß
Richard
Hm, mit VPN habe ich keine Erfahrung. Aber Du kannst als Parameter entweder den Hostname oder die IP-Adresse angeben, also z.B.:
X :1 -query tralalaoder
X :1 -query 192.168.47.11
Schreib mal, was rausgekommen ist, VPN muss ich mir demnaechst auch ansehen.
den Rechner, mit dem ich mich verbinden wollte, habe ich natürlich eh angegeben, meine eigene IP wollte ich mitgeben, damit der sich mit meinem X Server verbindet. Der X Server schickt nämlich standardmäßig meine LAN-IP mit, die wird aber im Remote-Netz nicht geroutet (VPN), weil unbekannt. Ich muss daher meine VPN-IP mitgeben.
Wenn man sich aber die Mühe macht und die Help liest, findet man das auch heraus. ;-) Muss ich erst übersehen haben.
So gehts: X :1 -query <Remote-Host> -from <eigene IP>
Dann noch meine Firewall geöffnet und ich sehe den Remote-Desktop.
:-)
Gruß
Richard
Prima, dann klappt's ja. Und wir haben auch gleich noch ein Problem geloest, von dem ich noch gar nicht wusste, dass ich es demnaechst haben werde ;-)
Gruss,
Hartwig
Liebe Leute,
vielen Dank für die vielen Antworten zum Thema. Ich habe insbesondere mit zwei Vorschlägen länger experimentiert, leider ohne Erfolg:
Wenn ich auf einem Client
startx -- -query <Server-IP>
starte, dann startet tatsächlich eine grafische Bedienoberfläche. Allerdings erscheint nur links oben ein
"Could not sync environment to dbus."
Auch ein "export $(dbus-launch)" vor dem startx-Aufruf hat daran nichts geändert.
Versuche ich es stattdessen mit
X :1 -query <Server-IP>
dann bekomme ich einen ganz schwarzen grafischen Bildschirm. Hier habe ich ein wenig den Verdacht, die auf dem Server eingestellte Grafikauflösung könnte den Monitor des Clients überfordern.
In beiden Fällen aber sehe ich auf dem Server keinerlei Aktivität die mir andeuten würde, dass es überhaupt eine Verbindung zwischen Client und Server gibt. So bleibt z.B. ein "journalctl -f" ohne Einträge, die auf eine Verbindung von außen hindeuten würden.
An die Firewall auf dem Server habe ich schon gedacht. Die war vollständig deaktiviert bei meinen Experimenten.
Hat noch jemand einen heißen Tipp?
Herzliche Grüße Jan
Hallo.
On Monday 24 April 2017 16:08:24 Handwerker, Jan (IMK) wrote:
Liebe Leute,
vielen Dank für die vielen Antworten zum Thema. Ich habe insbesondere mit zwei Vorschlägen länger experimentiert, leider ohne Erfolg:
Wenn ich auf einem Client
startx -- -query <Server-IP>
starte, dann startet tatsächlich eine grafische Bedienoberfläche. Allerdings erscheint nur links oben ein
"Could not sync environment to dbus."
Auch ein "export $(dbus-launch)" vor dem startx-Aufruf hat daran nichts geändert.
Versuche ich es stattdessen mit
X :1 -query <Server-IP>
dann bekomme ich einen ganz schwarzen grafischen Bildschirm. Hier habe ich ein wenig den Verdacht, die auf dem Server eingestellte Grafikauflösung könnte den Monitor des Clients überfordern.
In beiden Fällen aber sehe ich auf dem Server keinerlei Aktivität die mir andeuten würde, dass es überhaupt eine Verbindung zwischen Client und Server gibt. So bleibt z.B. ein "journalctl -f" ohne Einträge, die auf eine Verbindung von außen hindeuten würden.
An die Firewall auf dem Server habe ich schon gedacht. Die war vollständig deaktiviert bei meinen Experimenten.
Hat noch jemand einen heißen Tipp?
Herzliche Grüße Jan
Schwarzen Bildschirm erzeugen mit
X :1 -query <Server-IP>
kann ich auch. Z.B. wenn der Server aus ist.
Hast Du denn auf dem Server die Einstellungen fuer den Window-Manager (xdm, kdm, ...) vorgenommen? Die machen XDMCP nicht ohne Aenderung der Konfiguration.
Wenn der Server auf XDMCP-Anfragen nicht reagiert, gibt's eben 'nen schwarzen Bildschirm.
Ich habe mir zu den verschiedenen Window-Managern notiert, was ich aendern muss. Welchen verwendest Du?
Gruss,
Hartwig
Hallo Hartwig, Am 24.04.2017 um 20:19 schrieb Hartwig Atrops:
On Monday 24 April 2017 16:08:24 Handwerker, Jan (IMK) wrote:
Versuche ich es stattdessen mit
X :1 -query <Server-IP>
dann bekomme ich einen ganz schwarzen grafischen Bildschirm. Hier
Schwarzen Bildschirm erzeugen mit
X :1 -query <Server-IP>
kann ich auch. Z.B. wenn der Server aus ist.
Hast Du denn auf dem Server die Einstellungen fuer den Window-Manager (xdm, kdm, ...) vorgenommen? Die machen XDMCP nicht ohne Aenderung der Konfiguration.
Du meinst den DISPLAYMANAGER? Das ist zunächst ein SDDM. Ich habe das mal auf xdm umgestellt und dann den XServer neu gestartet (ausgeloggt/eingeloggt). Ich war erstaunt, dass sich Plasma unverändert gezeigt hat.
Für DISPLAYMANAGER_REMOTE_ACCESS hatte ich schon lange "yes" eingetragen. Allerdings gibt es im Hilfetext zu diesem Eintrag den netten, mir nicht wirklich verständlichen Hinweis: "Please note that a modified kdm or xdm configuration, e.g. by KDE control center will not be changed." Weiß ich doch nicht, wie "original" oder von Suse angepasst meine xdm configuration ist.
Window_manager ist plasma5.
Wenn der Server auf XDMCP-Anfragen nicht reagiert, gibt's eben 'nen schwarzen Bildschirm.
Das ist genau was ich befürchte.
Ich habe mir zu den verschiedenen Window-Managern notiert, was ich aendern muss. Welchen verwendest Du?
Wie gesagt: Standardmäßig war sddm eingestellt. Ich kann mir auch vorstellen, auf xdm oder kdm umzustellen.
Gruß Jan
Am 12.04.2017 um 10:12 schrieb Handwerker, Jan (IMK):
Das möchte ich jetzt gerne so ähnlich reproduzieren. Als Server käme ein unter Tumbleweed laufender Rechner zum Einsatz, statt eines X-Terminals möchte ich einen Raspberry Pi verwenden.
Willst du wirklich für ein Server ein Betriebsssystem verwenden, welches wie Tumbleweed ständig nicht nur updates sondern auch upgrades bekommt?
Gruß Peter
Hallo Peter,
Am 12.04.2017 um 12:02 schrieb Peter Mc Donough:
Am 12.04.2017 um 10:12 schrieb Handwerker, Jan (IMK):
Das möchte ich jetzt gerne so ähnlich reproduzieren. Als Server käme ein unter Tumbleweed laufender Rechner zum Einsatz, statt eines X-Terminals möchte ich einen Raspberry Pi verwenden.
Willst du wirklich für ein Server ein Betriebsssystem verwenden, welches wie Tumbleweed ständig nicht nur updates sondern auch upgrades bekommt?
das habe ich mich anfangs auch gefragt. Aber ich war dieses Neuinstallieren nach jedem Dreivierteljahr echt satt. Und so habe ich es mal probiert. "Es ist ja nur für die Familie."
Und bisher kann ich sagen, dass das wunderbar funktioniert. Auf der Arbeit verwendet unsere Administratorin lieber Leap 42.2, aber ich habe nicht den Eindruck, dass es zwischen beiden Systemen in punkto Zuverlässigkeit einen Unterschied gibt.
Hast Du andere Erfahrungen?
Gruß Jan
Am 24.04.2017 um 16:14 schrieb Handwerker, Jan (IMK):
Am 12.04.2017 um 12:02 schrieb Peter Mc Donough:
Am 12.04.2017 um 10:12 schrieb Handwerker, Jan (IMK):
... Als Server käme ein unter Tumbleweed laufender Rechner zum Einsatz ...
Willst du wirklich für ein Server ein Betriebsssystem verwenden, welches wie Tumbleweed ständig nicht nur updates sondern auch upgrades bekommt?
das habe ich mich anfangs auch gefragt. Aber ich war dieses Neuinstallieren nach jedem Dreivierteljahr echt satt. ...
Und bisher kann ich sagen, dass das wunderbar funktioniert. Auf der Arbeit verwendet unsere Administratorin lieber Leap 42.2, aber ich habe nicht den Eindruck, dass es zwischen beiden Systemen in punkto Zuverlässigkeit einen Unterschied gibt. Hast Du andere Erfahrungen?
Nein, hier läuft Tumbleweed/KDE ohne Probleme, als Desktop! Bei einem Server würde ich eine Distri nehmen, die lange ohne Updates auskommt. z.B. Ubuntu, centOS oder Debian, alle voraussichtlich bis oder nach 2020.
Gruß Peter
Am 25.04.2017 um 16:44 schrieb Peter Mc Donough:
Am 24.04.2017 um 16:14 schrieb Handwerker, Jan (IMK):
Am 12.04.2017 um 12:02 schrieb Peter Mc Donough:
Am 12.04.2017 um 10:12 schrieb Handwerker, Jan (IMK):
... Bei einem Server würde ich eine Distri nehmen, die lange ohne Updates auskommt.
Sorry, das soll ohne Upgrades heißen.
Gruß Peter
On 24.04.2017 15:14, Handwerker, Jan (IMK) wrote:
das habe ich mich anfangs auch gefragt. Aber ich war dieses Neuinstallieren nach jedem Dreivierteljahr echt satt.
Das kann man so auch nicht sagen, ich hab hier auf meinem cloud server eine 42.2 drauf, die hat eigentlich mal als 13.1 angefangen, immer brav mit zypper geupdated, keine probleme.
die 42.2 auf meinem laptop war auch urspruenglich eine 13.x, ist inzwischen nicht mal mehr auf der orginal platte drauf, ohne probleme von HD nach SSD umgezogen, auch da immer schoen zypper dup... und ich hab hier 25 repositories aktiv.
Kann man bei bedarf bei mir aufm dem blog nachlesen wie das geht >:-)
cheers Mathias
Handwerker, Jan (IMK) [24.04.2017 16:14]:
Hallo Peter,
Am 12.04.2017 um 12:02 schrieb Peter Mc Donough:
Am 12.04.2017 um 10:12 schrieb Handwerker, Jan (IMK):
Das möchte ich jetzt gerne so ähnlich reproduzieren. Als Server käme ein unter Tumbleweed laufender Rechner zum Einsatz, statt eines X-Terminals möchte ich einen Raspberry Pi verwenden.
Willst du wirklich für ein Server ein Betriebsssystem verwenden, welches wie Tumbleweed ständig nicht nur updates sondern auch upgrades bekommt?
das habe ich mich anfangs auch gefragt. Aber ich war dieses Neuinstallieren nach jedem Dreivierteljahr echt satt. Und so habe ich es mal probiert. "Es ist ja nur für die Familie."
Und bisher kann ich sagen, dass das wunderbar funktioniert. Auf der Arbeit verwendet unsere Administratorin lieber Leap 42.2, aber ich habe nicht den Eindruck, dass es zwischen beiden Systemen in punkto Zuverlässigkeit einen Unterschied gibt.
Hast Du andere Erfahrungen?
Ja, doch, etwas. Hängt natürlich davon ab, was man so einspielt, und wie oft man das macht.
Bei mir im Büro laufen alle SAP-Systeme auf SLES - wer SAP zahlt, hat auch das Geld für SLE ;). Mein Arbytesplatz ist Leap 42.2 - quasi SLE ohne Support. Was da über die Update-Repos kommt, läuft i.d.R. auch. Bei Paketen aus anderen Repos - naja, Vertrauenssache.
Updates in diesem Sinn gibt es bei Tumbleweed nicht. Tumbleweed ist das Factory-Release. Wenn Du da ein neues Paket einspielst, können eher Regressionen auftreten als bei den "traditionellen" Distros, weil es i.d.R. eben neue Software ist und kein Backport auf eine bekannt-stabile Version. War bei mir auf einem Laptop mal ein Kernel, der auf 32-Bit Systemen einen dysfunktionalen Bootloader produzierte. So etwas - also ein Schaden, der sich wirklich auf das System auswirkt und nicht nur auf einen eventuell davorsitzenden User - ist aber sehr selten.
Bei Tumbleweed würde ich mit einem "zypper up" (oder dup) immer etwas warten und die Factory-Mailingliste lesen, ob da Regressionen bekannt werden ;) Ein lokaler Mirror, der mehrere Versionen vorhält, kann da helfen.
Übrigens habe ich kaum einmal neu installiert. Meist habe ich des Bedienkomforts wegen "yast2 sw_single &" benutzt statt "zypper dup", aber ein System wird nur alle 4 Jahre neu aufgesetzt, beim Hardwarewechsel des Arbytesplatzes :) Meine SAP-Systeme laufen teilweise seit 2009 mit den unterschiedlichsten SLES-Versionen. Natürlich räume ich nach einem Versionsupdate das Softwareverzeichnis nochmal manuell auf, weil doch etliche Leichen bleiben, die nicht durch die automatischen Abhängigkeiten entfernt werden.
Gruß Werner
Am 26.04.2017 um 08:23 schrieb Werner Flamme:
... Bei Tumbleweed würde ich mit einem "zypper up" (oder dup) immer etwas warten und die Factory-Mailingliste lesen, ob da Regressionen bekannt werden ;) Ein lokaler Mirror, der mehrere Versionen vorhält, kann da helfen.
...
Bei Tumbleweed scheint
zypper refresh und zypper dup --no-allow-vendor-change
die bevorzugte Variante zu sein, weil gelegentlich neuere/bessere Pakete in andern Repros aufgenommen werden. Letztens gab es da mit packman-Paketen Konflikte. Da muss man halt nachsehen.
Für Tumbleweed-Hinweise sollte man ein Auge auf die Gruppe opensuse-factory@opensuse.org haben.
Gruß Peter
Am 12.04.2017 um 10:12 schrieb Handwerker, Jan (IMK):
Liebe Leute,
früher, ganz früher, da hatten wir hier relativ gut ausgestattete Rechner ("Server"), die gleichzeitig von mehreren Nutzern verwendet wurden. Dazu saßen die Nutzer nicht direkt am Server, sondern an einem X-Terminal.
Das möchte ich jetzt gerne so ähnlich reproduzieren. Als Server käme ein unter Tumbleweed laufender Rechner zum Einsatz, statt eines X-Terminals möchte ich einen Raspberry Pi verwenden.
Doch leider habe ich überhaupt nicht mehr im Kopf, wie man so etwas konfigurieren muss. Was muss ich dem Server, was dem Terminal sagen, damit sie sich richtig verhalten? Ein einfaches "startx -- <ip vom Server>" hat jedenfalls nicht funktioniert.
Gibt es irgendwo eine Beschreibung? Wenn ich nach Raspberry Pi und X oder X11 suche, bekomme ich nur antworten, wie man sich von einem Rechner auf dem Pi per ssh so einloggt, dass man X-Anwendungen grafisch nutzen kann. Ich will's ja umgekehrt haben und ohne ssh.
Wer weiß noch, wie das geht?
Das habe ich vor Jahrzehnten nur mals so aus Neugier verwendet. War mir aber zu langsam und konnte keine Sessions offenhalten.
Verwende heute immer noch X2Go (nachdem NX von nomachine.com leider vermurkst wurde und die ältere Version 3.x nicht mehr so richtig lief - die konnte auch Shadowing), ist viel schneller dank NX Bibliotheken und man kann Sessions pausieren und ggf. an einem anderen Rechner fortsetzen
Gruß Manfred
Am 12.04.2017 um 14:36 schrieb Manfred Kreisl:
Am 12.04.2017 um 10:12 schrieb Handwerker, Jan (IMK):
Liebe Leute,
früher, ganz früher, da hatten wir hier relativ gut ausgestattete Rechner ("Server"), die gleichzeitig von mehreren Nutzern verwendet wurden. Dazu saßen die Nutzer nicht direkt am Server, sondern an einem X-Terminal.
Das möchte ich jetzt gerne so ähnlich reproduzieren. Als Server käme ein unter Tumbleweed laufender Rechner zum Einsatz, statt eines X-Terminals möchte ich einen Raspberry Pi verwenden.
Doch leider habe ich überhaupt nicht mehr im Kopf, wie man so etwas konfigurieren muss. Was muss ich dem Server, was dem Terminal sagen, damit sie sich richtig verhalten? Ein einfaches "startx -- <ip vom Server>" hat jedenfalls nicht funktioniert.
Gibt es irgendwo eine Beschreibung? Wenn ich nach Raspberry Pi und X oder X11 suche, bekomme ich nur antworten, wie man sich von einem Rechner auf dem Pi per ssh so einloggt, dass man X-Anwendungen grafisch nutzen kann. Ich will's ja umgekehrt haben und ohne ssh.
Wer weiß noch, wie das geht?
Das habe ich vor Jahrzehnten nur mals so aus Neugier verwendet. War mir aber zu langsam und konnte keine Sessions offenhalten.
Verwende heute immer noch X2Go (nachdem NX von nomachine.com leider vermurkst wurde und die ältere Version 3.x nicht mehr so richtig lief
- die konnte auch Shadowing), ist viel schneller dank NX Bibliotheken
und man kann Sessions pausieren und ggf. an einem anderen Rechner fortsetzen
Gruß Manfred
Hallo, habe das bei mir am laufen! Aber, du brauchst einen schnellen Rechner mit viel RAM. Bei einen I7 mit 64GB Ram. Dann geht es Gruss Bernd
Am 12.04.2017 um 15:23 schrieb Bernhard Junk:
[..]
Verwende heute immer noch X2Go (nachdem NX von nomachine.com leider vermurkst wurde und die ältere Version 3.x nicht mehr so richtig lief
- die konnte auch Shadowing), ist viel schneller dank NX Bibliotheken
und man kann Sessions pausieren und ggf. an einem anderen Rechner fortsetzen
Gruß Manfred
Hallo, habe das bei mir am laufen!
Was denn genau? Ich habe 3 Alternativen erwähnt
Aber, du brauchst einen schnellen Rechner mit viel RAM. Bei einen I7 mit 64GB Ram.
Falls Du X2Go meinst, kann ich das nicht bestätigen. Ich greife damit dann und wann auf mein Headless 1GHz Dualcore ARM Serverchen zu, komme damit wirklich gut zurecht. Nur JDownloader2 damit zu bedienen macht keine wahre Freude ;)
Gruß Manfred
Hallo Manfred,
1. Sorry wegen der PM. War keine Absicht, habe einmal auf die falsche Stelle geklickt.
2. Für alle noch meine Antwort:
Am 12.04.2017 um 14:36 schrieb Manfred Kreisl:
Am 12.04.2017 um 10:12 schrieb Handwerker, Jan (IMK):
Liebe Leute,
früher, ganz früher, da hatten wir hier relativ gut ausgestattete Rechner ("Server"), die gleichzeitig von mehreren Nutzern verwendet wurden. Dazu saßen die Nutzer nicht direkt am Server, sondern an einem X-Terminal.
Verwende heute immer noch X2Go (nachdem NX von nomachine.com leider vermurkst wurde und die ältere Version 3.x nicht mehr so richtig lief - die konnte auch Shadowing), ist viel schneller dank NX Bibliotheken und man kann Sessions pausieren und ggf. an einem anderen Rechner fortsetzen
Jepp. Das könnte eine saubere Lösung des Problems sein. Allerdings müsste ich dazu auf dem Server Software installieren, die bei Tumbleweed nicht dabei ist. Da zöger ich doch etwas, weil ich Sorge habe, mir den Server schon im Versuchsstadium zu "zerschießen". Dazu ist mir die Sache wieder nicht wichtig genug.
Danke Dir trotzdem!
Gruß Jan
Am 24.04.2017 um 16:38 schrieb Handwerker, Jan (IMK):
Hallo Manfred,
- Sorry wegen der PM. War keine Absicht, habe einmal auf die
falsche Stelle geklickt.
- Für alle noch meine Antwort:
Am 12.04.2017 um 14:36 schrieb Manfred Kreisl:
Am 12.04.2017 um 10:12 schrieb Handwerker, Jan (IMK):
Liebe Leute,
früher, ganz früher, da hatten wir hier relativ gut ausgestattete Rechner ("Server"), die gleichzeitig von mehreren Nutzern verwendet wurden. Dazu saßen die Nutzer nicht direkt am Server, sondern an einem X-Terminal.
Verwende heute immer noch X2Go (nachdem NX von nomachine.com leider vermurkst wurde und die ältere Version 3.x nicht mehr so richtig lief - die konnte auch Shadowing), ist viel schneller dank NX Bibliotheken und man kann Sessions pausieren und ggf. an einem anderen Rechner fortsetzen
Jepp. Das könnte eine saubere Lösung des Problems sein. Allerdings müsste ich dazu auf dem Server Software installieren, die bei Tumbleweed nicht dabei ist. Da zöger ich doch etwas, weil ich Sorge habe, mir den Server schon im Versuchsstadium zu "zerschießen". Dazu ist mir die Sache wieder nicht wichtig genug.
Hmmm, kann ich nicht so recht nachvollziehen. Einerseits verwendest Du eine 'Basteldistribution', die niemals fertig wird, andererseits scheust Du dich etwas daran zu experimentieren. Seltsam, aber deine Entscheidung. Ein kurze Suche brachte gleich folgendes Ergebnis zutage, das sieht mir nicht so aus als würde man damit sein System gleich zerschießen ;)
https://software.opensuse.org/package/x2goserver
Gruß Manfred
Danke Dir trotzdem!
Keine Ursache
-
Bernhard Junk -
Handwerker, Jan (IMK) -
Hartwig Atrops -
Lutz Nülle -
Manfred Kreisl -
Mathias Homann -
Peter Mc Donough -
Richard Hafenscher -
Torsten Rosenberger -
Werner Flamme