1-to-1-assistance-antix - defekt ?

[loik]

Hmm ...

aika hatte ja auch gemeint, dass meine Fenster anders aussehen würden.
Wie kann das sein ?

[aika]

Mit unterschiedlichen Fenstergrößen möchte ich mich erst später wieder beschäftigen,
denn wenn Debian-Update mit der neuen Yad-Version nachzieht, kann ich wieder --geometry=700x... einsetzen und das Problem ist schnell erledigt.
Die Kompatibilität der unterschiedlichen Desktop-Environments und Desktop-Themen von Linux ist in der Realität auch nicht unbegrenzt.

... Auf Receiverseite bleibt das Skript nach "ping succeeded" sozusagen "hängen" und man muss erst Return drücken, um irgendwas im Terminal eingeben zu können ...

Hallo gosia, das würde ich gern als Erstes abarbeiten/erledigen, aber ich weiß überhaupt nicht was Du damit meinst ???

Das VNC-Icon in der Leiste unten stellt der X11VNC-Server bereit auf der Receiver-Seite und dort wird das VNC-Passwort zwischengespeichert mit:

Code: Select all

x11vnc -storepasswd $VNC_PASSWORD ~/.vnc/passwd

Theoretisch könnte X11VNC dieses Passwort wiederverwenden, praktisch wird nach neuen Passwort gefragt vor dem auslesen von .vnc/passwd .

---

...
Womit ich bei meinem Wunsch wäre:
Außer den beiden Rezise-Möglichkeiten auch noch eine Möglichkeit geben für "unchanged", weil damit für den Provider die Change besteht, in geschilderten vier-Monitor-Fall, die Bildschirminhalte und Taskleisten in erkannbarer Größe sehen und nutzen zu könne.
...
Bei unchanged könnte der Provider nun den Bildschirm des Receivers auf einen seiner zwei Bildschirme im Vollbildmodus wiedergeben lassen ...

Hallo loik, wo hast Du das gelesen, wie kommst Du darauf? Beispielsweise wäre Receiver "unchanged" bei mir eh' wieder 1360x768 . Ich wollte absichtlich zu hohe Auflösung und zu geringe Auflösung des Receivers abfangen/verhindern und die Sache nicht zu kompliziert machen nach der

... ursprüngliche Philosopie von 1-to-1:
"It is a simple way to privately share the desktop of one system with another system."
je mehr Entscheidungen die Hilfesuchenden treffen müssen, um so mehr entfernt sich IMHO 1-to-1 vom "einfachen Weg" ...

Subjektiv habe ich auch mehr Verständnis für Leute mit älterer Hardware und weniger für Leute mit mehreren Bildschirmen.
loik, nimm das bitte nicht persönlich. Der Programmierer der alten Version von 1-to-1-Assistenz nennt sich anticapitalista.

[loik]

Hallo, aika.

Das mit den Fenstergrößen kann natürlich ganz hinten anstehen.
Wenn es bei Zeiten "einfach" zu korrigieren ist, dann wäre es schön, wenn zumindest das Vinagre-Warn-Info-Fenster für den Provider, bei kleinen Bildschirmen, nicht mehr aus dem Display hängt.
Alles andere Funktioniert ja.
Und Fluxbox hat mich schon immer, mit autonomen, renitenten Fenstern mit unvorhersehbarem Verhalten beglückt.
Da muss man sich bestimmt nicht dran abarbeiten.
Fand ich aber als Rückmeldung erwähnenswert
Von daher, auch nicht schlimm, wenn du dich am Ende entscheidest gar nix mehr an den Fenstern zu machen.


Alte und neue Hardware.
Also, ich habe fast ausschließlich alte Hardware.
Angespülter Schrott der, wenn nicht bei mir gelandet, längst auf dem Wertstoff Hof zerlegt worden wäre.

Und alte Hardware war ja auch der ursprüngliche Grund, warum ich 1-to-1 nutzen wollte.
Von daher bin ich sehr froh, dass du dich der Reparatur angenommen hast.

Aber zugegeben, jemand der sich mit einem Vier-Monitor-Desktop ausstaffiert, wird vermutlich eher Provider als Receiver sein.
Im Falle das er mal Receiver sein sollte, kann man wohl erwarten, dass eine Hardware, die vier Monitore bespielen kann, dann auch andere Fernverbinder, wie TeamViewer, AnyDesk oder NoMachine nutzbar macht.
Also, Ja, meine vier Monitore 1-to-1-kompatibel zu machen brauchen kein Entwicklungsziel zu sein.

Aber das hier bleibt für mich ( im Bezug auf nur einen Monitor auf Receiver Seite ) schon noch interessant bzw. wichtig
Loik:

wenn der Receiver einen Bildschirm von 1920x1080 hat und der Provider gleich zwei davon.
Bei unchanged könnte der Provider nun den Bildschirm des Receivers auf einen seiner zwei Bildschirme im Vollbildmodus wiedergeben lassen, was sicherlich angenehm für die Augen ist.
Das geht aber in der jetzigen Konfiguration nicht.

aika:

Ich wollte absichtlich zu hohe Auflösung und zu geringe Auflösung des Receivers abfangen/verhindern und die Sache nicht zu kompliziert machen nach der

Das ist eine gute Überlegung.

Aber sie verhindert eben, dass der Provider einen Receiver-Desktop von 1920x1080, in voller Auflösung sehen kann, obwohl auf seiner Seite nichts dagegen spräche, wenn er selber einen 1920x1080-Monitor hat.
Wird dem Provider bei geschilderter Konstellation aber maximal eine Auflösung von 1360x768 übermittelt, dann hat der Provider keine Change diese Auflösung zu verbessern.
Zieht er sein Vinagre-Fenster groß und Nutzt "auf Fenstergröße skallieren" oder verwendet Vollbild, erhält er eine Aufgeblähte unscharfe Wiedergabe des Receiver-Desktops.

Hingegen, wenn dem Provider der Receiver-Desktop unchanged übermittelt wird, hat der Provider die Möglichkeit, die zu hohe Auflösung, an sein Vinagre-Fenster mit "auf Fenstergröße skallieren" zu shrinken.
Was in etwa den gleichen Effekt hat, wie wenn die Ansicht vom Receiver bereits vorreduziert übermittelt wird.
Aber bei unchanged behält der Receiver die Kontrolle darüber, wie er den Receiver-Desktop dargestellt haben will.

Hallo loik, wo hast Du das gelesen, wie kommst Du darauf?

Sorry, Ich verstehe diese Frage nicht. Weiß sie nicht zuzuordnen.
Habe ich sie vielleicht schon beantwortet ?


Passwort speichern.
Das würde dann besonders Sinn ergeben, wenn der Receiver ein Server wäre, wo keiner sitzt, der ein Passwort eingeben kann.
Aber eine Automatische Verbindung ist ja darüber hinaus mehrstufig unterbunden.
Selbst, wenn man im Server-Fall davon ausgeht, dass der dauerhaft läuft und 1-to-1 bei ihm nie geschlossen wird, wäre ein gespeichertes Passwort doch wohl nur die halbe Miete. Oder ?
Denn nach dem auf Provider-Seite die Verbindung durch Schließen von Vnagre beendet wurde, wird beim erneuten Kontakt-Aufbau, beim Receiver nicht nur die Eingabe des Passwortes verlangt sondern danach auch noch die IP des Providers.

Also ist 1-to-1 als Server-Steuerung wohl nicht geeignet.

Die Idee ist ja auch Assistenz.
Und die ist auf diese Weise für den Receiver sicher.
Nach Trennen, der Verbindung, kann es nur eine neue Verbindung geben, wenn der Provider in diese wieder Einbezogen wird und ihr zustimmt.
Das erneute eingeben eines Passwortes trägt so zur Sicherheit bei.
Ich finde das ganz gut.




Anticapitalista

Der Programmierer der alten Version von 1-to-1-Assistenz nennt sich anticapitalista

Wenn das der Fall ist, verstehe ich nicht, dass Dolphin_Oracle in Post #22 schreibt

Ich weiß es nicht. Der Schöpfer dieser Einrichtung ist verschwunden

Weil, anticapitalista ist doch bei Antix tätig und dort auch zu erreichen. Hmm, seltsam

[loik]

Dann ist leider doch noch mal eine unerfreuliche neue Erfahrung zu berichten:

Ich habe heute morgen mal versucht mich mit 1-to-1 über die heimischen Netzwerkgrenzen hinweg mit 1-to-1 in einem anderen Netzwerk zu verbinden.
Das soll ja eigentlich der Sinn und Zweck von 1-to-1 sein.

Hat bei mir überhaupt nicht geklappt.

Code: Select all

sudo ufw allow 5900/tcp

Hat daran nicht geändert.

Mein Versuchsaufbau, hatte ich anfangs mit dem Handy erstellt.
Am Handy Mobile Daten genutzt und einen Wlan-Hotspot mit dem Handy erstellt und dann ein Notebook damit verbunden und so im Internet gewesen.
Die WAN-IP unterschied sich dann auch von der meiner Rechner, die mit dem Heim-Router verbunden waren.

Aber, ganz egal wie und in welche Richtung ich versuchte eine 1-to-1-Verbindung herzustellen, es funktionierte nicht.
Nach der Eingabe der jeweiligen WAN-IP und Enter, passierte eine Minute lang gar nix, bis dann die Mitteilung kam, dass der Verbindungsaufbau zu ensprechender IP gescheitert sei und dann wurde mir erneut die Passworteingabe angeboten.

Der Verdacht, lag nahe, dass die Anroid-Schnittstelle, also die Verbindung über das Handy hierfür nicht geeignet sein könnte.

Deshalb entschied ich, so frei zu sein, mir eines der unverschlüsselten Wlans der Nachbarschaft auszuleihen.
Habe mich mit einem Notebook mit entsprecht freiem Wlan Verbunden.
Hatte nachweislich Internet und bekam wieder eine andere WAN-IP angegeben.

Ich konnte dennoch keine Verbindung herstellen.

Ich bin auch Überrascht, dass nur die WAN-IP reichen soll.
Weil das ist ja der Router.
Zu dem will aber nicht.
Der soll mich doch nur durchlassen zu der eigentlichen Zieladresse in seinem Netzwerrk.

Deshalb hätte ich erwartet, dass ich in so einem Fernverbindungsfall in das Adressfeld beim Receiver eine Adressenkombination aus WAN-IP und IPv4 ( Netzwerkadresse ) eingeben müsse, damit die Verbindung ein definiertes Ziel hat.

Da ich aber Netzwerk nun mal nicht begreife, muss das bitte jemand anders testen.

[gosia]

Hallo aika,

ich weiß überhaupt nicht was Du damit meinst ???

ja, da habe ich mich blöd ausgedrückt. Es gibt beim Receiver Meldungen im Terminal (nach Eingabe vom Passwort und der IP des Providers):

Code: Select all

gn@china:~ $ stored passwd in file: /home/gn/.vnc/passwd
starting gui, trying display: :0
05/02/2025 16:33:39 icon_mode_file=/tmp/x11vnc.tray.zvkHyg

05/02/2025 16:33:39 gui: got SIGUSR1
05/02/2025 16:33:39 gui: ping succeeded.

und nach der Meldung, dass der ping zum Provider erfolgreich war "gui: ping succeeded." würde ich erwarten, dass das Terminal zu meinem Prompt

Code: Select all

gn@china:~ $

zurückkehrt. Macht es aber nicht, sondern ich muss selbst Return/Enter drücken, um den Prompt zu erhalten. Ist keine grosse Sache und wohl nicht so dringend der Mühe wert, jedenfalls nicht unbedingt für Platz 1 in der Anforderungsliste.
Ist es jetzt klarer?

viele Grüsse gosia

[aika]

... zugegeben, jemand der sich mit einem Vier-Monitor-Desktop ausstaffiert, wird vermutlich eher Provider als Receiver sein.
...
Aber das hier bleibt für mich ( im Bezug auf nur einen Monitor auf Receiver Seite ) schon noch interessant bzw. wichtig
Loik:

wenn der Receiver einen Bildschirm von 1920x1080 hat und der Provider gleich zwei davon.
Bei unchanged könnte der Provider nun den Bildschirm des Receivers auf einen seiner zwei Bildschirme im Vollbildmodus wiedergeben lassen, was sicherlich angenehm für die Augen ist.
Das geht aber in der jetzigen Konfiguration nicht.

aika:

Ich wollte absichtlich zu hohe Auflösung und zu geringe Auflösung des Receivers abfangen/verhindern und die Sache nicht zu kompliziert machen nach der

Das ist eine gute Überlegung.

Aber sie verhindert eben, dass der Provider einen Receiver-Desktop von 1920x1080, in voller Auflösung sehen kann, obwohl auf seiner Seite nichts dagegen spräche, wenn er selber einen 1920x1080-Monitor hat.
Wird dem Provider bei geschilderter Konstellation aber maximal eine Auflösung von 1360x768 übermittelt, dann hat der Provider keine Change diese Auflösung zu verbessern.
Zieht er sein Vinagre-Fenster groß und Nutzt "auf Fenstergröße skallieren" oder verwendet Vollbild, erhält er eine Aufgeblähte unscharfe Wiedergabe des Receiver-Desktops.
...
...

Der Programmierer der alten Version von 1-to-1-Assistenz nennt sich anticapitalista

Wenn das der Fall ist, verstehe ich nicht, dass Dolphin_Oracle in Post #22 schreibt

Ich weiß es nicht. Der Schöpfer dieser Einrichtung ist verschwunden

Weil, anticapitalista ist doch bei Antix tätig und dort auch zu erreichen. Hmm, seltsam

Hallo loik, Deinen "unchanged"-Wunsch werde ich überdenken, kann ich jetzt besser nachvollziehen.
Bezüglich anticapitalista schau mal diesen Post vom 13.Januar 2025 => viewtopic.php?p=805073#p805073
Aber zur neuen Version von 1-to-1-Assistenz hatte er noch keine Meinung. Erst wenn das Ding fertig ist, ohne Kinderkrankheiten, schreibe ich ihn evtl. mal an.

[loik]

Hallo, aika.
Schön dass ich mein Anliegen verständlich machen konnte.


Ja, eben anticapitalista ist doch da.
Verstehe halt die Auskunft von dolphin_oracle nicht, das der der Erschaffer von 1-to-1 nicht auffindbar sei.

Das du den Entwicklern, deine 1-to-1 Überarbeitung erst übergeben willst, wenn es keine Macken mehr hat, ist verständlich.


Macken.
Könnt ihr euch mit 1-to-1 in anderen Netzwerken verbinden ?

[m_pav]

Übersetzungs-Engine geändert, hoffentlich zum Besseren.

Ich werde versuchen, dies in den einfachsten Worten zu erklären, und ich meine die einfachsten möglichen Begriffe und ich spreche so viel wie möglich in der Hoffnung, dass es den Zweck erreicht, für den es geschrieben wurde. Bitte nehmen Sie sich die Zeit, dies zu lesen und zu verarbeiten, da es nahezu unmöglich ist, es zu vereinfachen, und es einer Übersetzungsmaschine unterzogen wurde

WAN <------> NAT <------> LAN

Das WAN steht für Wide Area Network, in dem öffentliche IP-Adressen verwendet werden und Millionen/Milliarden von Adressen verwendet werden.

Das NAT stellt einen Übersetzer bereit, der es Maschinen (Knoten) innerhalb eines privaten Netzwerks ermöglicht, auf das WWW zuzugreifen und dabei privat zu bleiben.

Das LAN ist ein privates Netzwerk und wird von den meisten hier für ihre Remote-Desktop-Verbindungen verwendet, wobei Remote eine Verbindung über ein LAN-Netzwerk ist.

Es spielt keine Rolle, in welchem ​​LAN sich die einzelnen Maschinen befinden. Sofern sich beide Maschinen im gleichen „Segment und Subnetz“ befinden, sollte ein Verbindungsaufbau möglich sein, sofern die verwendeten Ports durch die einzelnen Firewalls zugänglich gemacht werden.

Zum Beispiel

192.168.1.0 sieht insgesamt 256 IP-Adressen vor, 0 und 255 sind jedoch für bestimmte Zwecke reserviert, sodass wir innerhalb dieses privaten Segments 254 mögliche Adresskombinationen haben.

Wenn man die ersten drei Dezimalstellen mit Punkt ignoriert, können alle Knoten, deren IP-Adressen auf einen Wert von 1 bis 254 enden, miteinander kommunizieren, sodass jede Maschine mit offenem Port 5900 für VNC erkannt werden kann und eine erfolgreiche VNC-Verbindung möglich ist.

Beim Herstellen einer Verbindung zu einem Mobiltelefon-Hotspot werden die verwendeten IP-Adressen normalerweise durch eine Funktion namens Subnetting eingeschränkt, die eine geringere Anzahl von IP-Adressen bereitstellt, sodass die IP-Adressen möglicherweise etwa wie folgt aussehen:
172.16.0.241, 172.16.0.246

Obwohl sich das Obige von den 192.168.x.x-Adressen unterscheidet, gilt die gleiche Regel und alle verbundenen Knoten befinden sich im selben privaten Segment. Daher sollte jeder Knoten in der Lage sein, mit allen anderen Knoten im Segment zu kommunizieren.

Als letztes sollten Sie bedenken, dass in einigen privaten Netzwerken die IP-Isolierung aktiviert ist, wodurch alle anderen Knoten unsichtbar und eine Verbindung unmöglich werden.

Dies alles bedeutet, dass Benutzer kein Problem damit haben sollten, sie miteinander zu kommunizieren, vorausgesetzt, alle Maschinen befinden sich im selben Netzwerk und Subnetz. Verbindungen zwischen zwei verschiedenen privaten Netzwerken erfordern eine Portweiterleitung und möglicherweise externe Dienste. Denken Sie immer daran, dass es nicht möglich ist, mit einer Maschine innerhalb desselben Netzwerks/Subnetzes zu kommunizieren, indem Sie über ein NAT eine Verbindung herstellen und versuchen, in dasselbe private Netzwerk zurückzukehren.

Wenn Sie all dies im Hinterkopf behalten, können Sie eventuelle Unklarheiten darüber beseitigen, wie oder warum eine Remote-Verbindung nicht funktioniert.

[fehlix]

Vertaald met DeepL.com (gratis versie)

Dies ist nicht auf Deutsch (German), sondern auf Niederländisch (Dutch).

[m_pav]

Entschuldigung, mein Fehler jetzt behoben