ubuntuusers.de

Könnte mal bitte ein Teamviewer Nutzer mit Jammy Jellyfish überprüfen, ob im Artikel auch noch für Jammy Jellyfish der Installationshinweis stimmt? Ich habe Bedenken dass es bei apt-key auf Jammy Jellyfish hakeln könnte.

Ich habe die DEB-Datei immer mit GDebi installiert, da muss man nicht mit apt-key rumhakeln. Die Terminal-Variante müsste nachgearbeitet werden, hier geht's zur passenden Anleitung.

Schlüssel für das WineHQ Repository und auch das CUDA Repository werden in /usr/share/keyrings/ abgelegt, daher fände ich es logisch, dass dort auch dann der entsprechende Schlüssel für TeamViewer abgelegt würde.

So in etwa würde es mir vorschweben:

wget -O- https://download.teamviewer.com/download/linux/signature/TeamViewer2017.asc | gpg --dearmor | sudo tee /usr/share/keyrings/teamviewer.gpg &> /dev/null
sudo sh -c 'echo "deb [signed-by=/usr/share/keyrings/teamviewer.gpg] http://linux.teamviewer.com/deb stable main" >> /etc/apt/sources.list.d/teamviewer.list'

Das ist aber nicht getestet, sondern einfach aus den Erkenntnissen mit WineHQ Repository und CUDA Repository abgeleitet. Das TeamViewer2017.asc ist ebenfalls ein GnuPG v1 PUBLIC KEY wie es auch der alte CUDA Repository Schlüssel war, den man auf diese Art einbauen musste.

trollsportverein schrieb:

Schlüssel für das WineHQ Repository und auch das CUDA Repository werden in /usr/share/keyrings/ abgelegt, daher fände ich es logisch, dass dort auch dann der entsprechende Schlüssel für TeamViewer abgelegt würde.

Das gilt für Schlüssel, die durch das Paket selbst verwaltet werden und theoretisch durch dieses auch verändert werden können. Dies trifft auf den manuell hinzugefügten Schlüssel TeamViewer2017.asc aber nicht zu, weshalb er IMO nach /etc/apt/keyrings/ gehört.

Bitte noch mal genau durchlesen, es geht nicht darum den Schlüssel in /etc/apt/trusted.gpg.d/ unterzubringen! Das unterbringen in /etc/apt/trusted.gpg.d/, oder hinzufügen in den großen Schlüsselbund in /etc/apt/trusted.gpg will der askubuntu Nutzer Askeli vermeiden. Was auch vermieden werden soll, wenn man den askubuntu Thread als Vorlage nimmt, dann ist es das unterbringen vom Schlüssel im Nutzer-Home-Verzeichnis, da dies Manipulationen Tür und Tor öffnen könnte.

Hier mehr zu lesen:

• https://unix.stackexchange.com/questions/463072/why-does-the-apt-key-man-page-advise-against-using-its-add-command/463140#463140

Hier der wesentliche Satz daraus:

The full mechanism that exists now uses separate, not globally trusted, keyring files in /usr/share/keyrings/.

Bezüglich des richtigen Verzeichnisses gibt es wohl Meinungsverschiedenheiten, Meine Meinung wurde aber auch hier vertreten.

Klar ist, dass er nicht nach /etc/apt/trusted.gpg.d/ oder /etc/apt/trusted.gpg gehört.

Das alte Mutterschiff Debian hat auch das /usr/share/keyrings/ Verzeichnis für die nicht global trusted Repositories auserkoren:

• https://wiki.debian.org/DebianRepository/UseThirdParty#Sources.list_entry

Nvidia nutzt ebenfalls das /usr/share/keyrings/ Verzeichnis für den CUDA Repository Schlüssel und das WineHQ macht es auch so. Für Kompatibilität und Übersicht behalten, dürfte es wohl besser sein, das /usr/share/keyrings/ Verzeichnis zu nutzen, das bereits von Debian, vom WineHQ und Nvidia CUDA Repositories für die nicht global trusted Schlüssel genutzt wird.

UlfZibis schrieb:

Ich habe die DEB-Datei immer mit GDebi installiert, da muss man nicht mit apt-key rumhakeln.

Mittlerweile, zumindest auf 22.04, produziert GDebi bei anschließend ausgeführtem audo apt update nun auch die Warnungen, auch für Skype:

W: https://linux.teamviewer.com/deb/dists/stable/InRelease: Schlüssel ist im veralteten Schlüsselbund trusted.gpg gespeichert (/etc/apt/trusted.gpg), siehe den Abschnitt MISSBILLIGUNG in apt-key(8) für Details.
W: https://repo.skype.com/deb/dists/stable/InRelease: Schlüssel ist im veralteten Schlüsselbund trusted.gpg gespeichert (/etc/apt/trusted.gpg), siehe den Abschnitt MISSBILLIGUNG in apt-key(8) für Details.

Tja, die Maintainer der Pakete haben leider noch keine Zeit gefunden, um sich an die neuen Bedingungen auf Debia/Ubuntu anzupassen. Zumindest WinzigWeich hat ja zur Zeit bedeutungsschwangere Welt-Aufgaben zu lösen.

Interessant ist, dass Google Chrome scheinbar einen von Debian/Ubuntu akzeptierten Schlüssel verwendet, denn da kommt keine Warnung, obwohl der unter /etc/apt/trusted.gpg.d/ abgelegt ist.

trollsportverein schrieb:

Schlüssel für das WineHQ Repository und auch das CUDA Repository werden in /usr/share/keyrings/ abgelegt, daher fände ich es logisch, dass dort auch dann der entsprechende Schlüssel für TeamViewer abgelegt würde.

So in etwa würde es mir vorschweben:

wget -O- https://download.teamviewer.com/download/linux/signature/TeamViewer2017.asc | gpg --dearmor | sudo tee /usr/share/keyrings/teamviewer.gpg &> /dev/null
sudo sh -c 'echo "deb [signed-by=/usr/share/keyrings/teamviewer.gpg] http://linux.teamviewer.com/deb stable main" >> /etc/apt/sources.list.d/teamviewer.list'

Das ist aber nicht getestet, sondern einfach aus den Erkenntnissen mit WineHQ Repository und CUDA Repository abgeleitet. Das TeamViewer2017.asc ist ebenfalls ein GnuPG v1 PUBLIC KEY wie es auch der alte CUDA Repository Schlüssel war, den man auf diese Art einbauen musste.

Bis auf die Wahl des Verzeichnisses würde ich Dir zustimmen.

Die von WineHQ vorgeschlagene Installationsweise ist leider fehlerhaft, siehe: https://bugs.winehq.org/show_bug.cgi?id=53356

Hallo,

ich würde gerne den Artikel um das Thema Datenschutz erweitern: Datenschutz

Datenschutz¶

Durch die Installation des Programms stimmt der Benutzer den Datenschutzbestimmungen von Teamviewer zu.

Welche Daten bei Teamviewer speichert und auswertet findet Ihr hier.

Darunter fallen z.B.:

- Verarbeitung von Kontakten, die im Adressbuch des Benutzers gespeichert sind, um Meetings zu organisieren Benutzerkontoverwaltung und -administration, z.B. Speichern und Freigeben von Benutzerprofilen, Kontodetails, Freundesliste, Kontaktinformationen, Chat-Verlauf, Dateianhänge.

- Verwaltung und Managementdaten des Firmenprofils, z.B. Firmenprofil, Firmenrichtlinien, Zuordnungen zu Benutzerkonten, Verwaltung des Benutzerzugangs, Verbindungsberichte.

- Geräteinformationen (z.B. Gerätename, Maschinenname, Festplattenspeicherplatz, Online-Stand, Ereignisse, CPU-Auslastung usw. wie in den Produktspezifikationen beschrieben); Historische Alarmdaten pro Gerät, z.B. verdächtige Alarme oder Ereignisse, wie sie durch die individuellen Einstellungen des Kunden definiert sind; Scripting Daten, z.B. Gerätename, Benutzeranmeldeinformationen, ausgeführte Skripte pro Gerät (je nachdem, wie der Kunde das jeweilige Skript ausführen möchte); Inhalt der Verbindungen zwischen der Remote Management Konsole und verwalteten Geräten.

raimund schrieb:

ich würde gerne den Artikel um das Thema Datenschutz erweitern:

Dafür ist das Lesen vor Zustimmung von AGB da.

Auch nicht diesen Riesentext in den dazu verhältnismäßig kleinen Wiki-Artikel. Es sollte doch wohl ausreichend sein, darauf hinzuweisen, daß angegebene und anfallende Daten von der TeamViewer AG verarbeitet werden. Das muß man in einem Wiki-Artikel noch nicht mal, denn wer anderes annimmt, ist verdammt naiv.

Deine Begeisterung für RustDesk in allen Ehren, Du mußt jetzt aber nicht im selben Atemzug Konkurrenten, hier auch, quasi an den Pranger stellen.

Ich finde TeamViewer eh nicht mehr besonders interessant. Zum einen kann man es nur noch benutzen, wenn mindestens einer der Partner eine bezahlte Lizenz hat, und zum anderen war mir die Paketgröße schon immer ein Dorn im Auge. Eine speziell getunte Wine-Version wird da mitinstalliert, statt die schon im System vorhandene zu nutzen.

So bin ich längst auf AnyDesk umgestiegen. Es läuft auf schwachen Systemen flüssiger, was sicher auch daran liegt, dass das Paket nur ein Zehntel so groß ist und nativ unter Linux läuft.

Schön, wenn es jetzt Rustdesk voll in Open-Source gibt, auch wenn da noch manches geklärt werden muss, wie die Vorredner schon schrieben.

UlfZibis schrieb:

Zum einen kann man es nur noch benutzen, wenn mindestens einer der Partner eine bezahlte Lizenz hat

Das kann ich nicht bestätigen. Ich kann zwar nicht unzählige Clients supporten, aber meine 3-4 People, das geht schon. Ich als Supporter bin lediglich registriert und habe einen Account, habe Zugriff auf den PC meiner Mutti und meiner Schwester und wenn mal ein neuer hinzukommt geht das auch.

Hallo,

ich würde gerne den Artikel um das Thema Datenschutz erweitern: Datenschutz

-1

Im 1. Satz im Wikiartikel steht, dass TeamViewer proprietär ist. Dazu kommen die von von.wert bereits erwähnten AGBs.

Das Wiki ist _nicht_ dafür das Kreuzzüge für freie Software und gegen proprietäre Software zu starten und erst recht nicht, diese zu bewerten. Jeder darf für sich selber entscheiden, was er mit welcher Konsequenz für sich selber einsetzt.

von.wert schrieb:

Deine Begeisterung für RustDesk in allen Ehren, Du mußt jetzt aber nicht im selben Atemzug Konkurrenten, hier auch, quasi an den Pranger stellen.

+1. Und bring' doch erstmal den RustDesk Artikel auf ein vernünftiges Niveau, bevor versucht, gegen die gegen Marktbegleiter zu schießen.

Steve_ schrieb:

UlfZibis schrieb:

Zum einen kann man es nur noch benutzen, wenn mindestens einer der Partner eine bezahlte Lizenz hat

Das kann ich nicht bestätigen.

Richtig, es gibt eine kostenlose Variante, siehe https://www.teamviewer.com/de/download/free-download-with-license-options/. Die hat zwar Einschränkungen, aber für ein bisschen privaten Support reicht das AFAIK aus.

Gruß, noisefloor

UlfZibis schrieb:

Eine speziell getunte Wine-Version wird da mitinstalliert,

Das ist aber schon ewig her, soweit erinnerlich, seit Version 8 nicht mehr, seitdem nativ. Das hat man damals auch an der Filesize sehen können.

statt die schon im System vorhandene zu nutzen.

"Im System vorhanden" ist wine nicht. Du kannst es installieren (und das ist einiges mehr als damals nur die in teamviewer.deb verpackte Datei wine) und dann die Windows-Version von TeamViewer hinterher, wenn das irgendeinen Vorteil brächte.