Ist das eigentlich bei Whatsapp immer noch so, dass die eigene Kontaktiliste ausgelesen und von denen genutzt wird und zudem die eigenen Nummer wie wild an andere verteilt wird, ohne dass man groß was dagegen machen kann?
Ja
Beiträge von Paul
-
-
NUE is available too. I can confirm that from my own experience
-
Warum willst du den Webserver denn überhaupt neu starten (lassen)? Falls du aktuell ein Problem hast, gibt es evtl. auch eine andere Lösung. Ein Neustart betrifft ja alle Kunden auf diesem Host und ist eigentlich selten die Lösung für das eigentliche Problem. Daher wird Netcup den nicht so ohne weiteres einfach neu starten.
-
kann mir jemand erklären was die Geschichte mit den monatlichen Sammelrechnung jetzt bringt?
hat jemand z.B. 12 Produkte, welche alle ein ganzes Jahr im vorhinein zu bezahlen sind,
und das zufällig in den selben Monat fällt?
Ich begrüße die neuen Sammelrechnungen sehr. Bis jetzt musste ich mehrmals im Monat kleinere Beträge an Netcup bezahlen. Das war immer etwas nervig. Bei mir kam z.B. am 1. eine Rechnung, am 9. eine Rechnung, am 14. kamen 2 Rechnungen. Ab und zu kam dann noch eine am 21., mal am 28.,...Manche Produkte wurden monatlich abgerechnet, andere alle 3 Monate. Hinzu kommen unzählige Domains, die natürlich auch alle an einem anderen Tag das Jahr über abgerechnet wurden. Ab sofort habe ich maximal 12 Rechnungen pro Jahr. Ich hatte alleine in 2024 bis jetzt 44(!) Rechnungen zu begleichen. Das ist sowohl für Netcup als auch für mich als Kunde unnötiger Aufwand.
-
Das wäre natürlich in dringenden Fällen nicht so geschickt. Wie handhabt ihr das?
Die Sorge hatte ich grundsätzlich auch. Du kannst das Secret aber in beliebig vielen Tools einrichten (z.B. einmal in der TOTP App auf dem Smartphone, dann einmal im Passwort Manager wie Proton Pass oder Bitwarden und dann nochmal ganz normal als Secret in deinem Password Safe, falls du es neu einrichten musst). Lege dir einfach so viele Backup an bis du dich wohl fühlst
. Ich persönlich habe das Secret in 2 Passwort Managern und in 1 TOTP App auf dem Smartphone, für welche ich auch nochmal Backups habe. -
As this is only a customer forum, we unfortunately don't know that either. It's a bit strange that the servers run out even before a discount event. So the question is surely fair. The only obvious answer is probably that there are currently supply shortages of hardware.
-
Im Zweifel würde ich x86 vorziehen. An sich läuft Nextcloud auf beiden Architekturen einwandfrei. Das macht keinen Unterschied. Nur wenn man viele Plugins einsetzt, könnte es eine Rolle spielen. Manche Plugins bringen eigene Binaries mit (z.B. Memories). Diese sind aber in der Regel x86 Binaries. Da muss man dann in der Konfiguration den Pfad auf das ARM Binary ändern. Funktioniert dann zwar auch, kann aber ein Stolperstein sein, wenn man es nicht weiß oder rechtzeitig merkt.
-
Ich habe schon so viele Linux Distributionen ausprobiert und Fedora ist mit Abstand die stabilste und zuverlässigste Distribution, die mir unter gekommen ist. Ich habe Fedora Server, die laufen schon seit Jahren und haben unzählige dnf system-upgrades hinter sich. Auch meine berufliche Workstation läuft schon ewig mit Fedora, weil ich mich da auf ein stabiles OS verlassen will, was aber trotzdem einigermaßen aktuelle Software bietet. Privat läuft bei mir zwar primär Archlinux, weil ich da die unkomplizierte Installation von unfreien Treibern und Software bevorzuge (das ist das einzige, was mich wirklich etwas an Fedora stört), habe aber trotzdem ein paar Fedora Testsysteme (Gerade die Atomic Varianten probiere ich hin und wieder mal aus).
-
Und warum das Ganze: Nur weil netcup jetzt so einen Schmu mit den vormals, im Vergleich, wundervollen Storage-Werten macht.
Merkst du die fehlende Performance denn in der Praxis? Mal abseits von Benchmarks ist das ja oft nur sehr schwer zu beurteilen. Ich habe das ja auch. So ist das nicht. Mein RS lässt mittlerweile in der IO Performance auch stark nach. Aber in der Praxis merkt man das nicht wirklich. Die Nextcloud läuft z.B. immer noch so schnell wie vorher, auch wenn die Benchmarkwerte um 60% niedriger sind. Man lastet die Disk ja selten wirklich über einen längeren Zeitpunkt so aus, dass dies eine Rolle spielen würde. Gerade in einer Storage Cloud liegen die meisten Daten ja nur auf der Disk ohne gelesen oder beschrieben zu werden. Man muss da auch immer etwas aufpassen, dass man hier zwischen theoretischer Leistung und praktischer Anforderung unterscheidet.
-
Normalerweise sollte bei einem Rätsel das Lösungswort nicht schon im ersten Post direkt vorkommen. Daher fände ich es etwas schade, wenn es tatsächlich Kaffee wäre (etwas sehr offensichtlich). Aber vieles spricht halt doch dafür.
-
Mein Tipp: COLA
-
Das ist ja auch okay, solange mit dem Refresh Token dann ein neuer Access Token beantragt wird.
Ich hatte zum Test auch mal die Refresh Token Lifetime auf 5 Minuten reduziert und die Access Token Lifetime auf 2 Minuten. Trotzdem bin ich Tage später immer noch eingeloggt. Ich muss aber auch zugegeben, dass mir hier etwas die Motivation fehlt, hier intensiver zu debuggen. Wenn ich mal Zeit habe, werde ich das machen. Aber das Eingeloggt bleiben stört mich jetzt auch weniger als das Problem mit dem fehlenden Cookie bei Gitea. Hier werde ich mal weitere Tests mit LDAP unternehmen.
-
Wenn das störend ist, kann die Dauer des Access Tokens reduziert werden, und stattdessen über den Refresh Token kontrolliert werden, wenn die Tokens ihr Gültigkeit verlieren sollen. Das ausstellende Portal sollte hierfür Einstellungsmöglichkeiten haben (z.B. Token Lifetime 5 Minuten).
Danke. Ich glaube, das ist auch mein Problem damit. Die Apps ignorieren die Token Lifetime einfach. Innerhalb dieser Litetime würde ich es voll verstehen und das wäre auch mein gewünschtes Verhalten. Aber das die Token Lifetime keinen Einfluss auf die Login Dauer hat, stört mich etwas.
-
Nur meine Meinung. der Aufwand einen Vaultwarden Server selbst zu betrieben ist so gering das ich meine Daten keinem anderen gebe und schon gar nicht einem US Unternehmen
Es gibt auch durchaus europäische Anbieter (wie z.B. Proton Pass). Die Wahl hat man also schon.
Das mit dem Aufwand würde ich so nicht ganz unterschreiben. Das sollte man wirklich nur machen, wenn man sich zu 100% sicher fühlt in diesem Bereich und auch schon Erfahrungen mit anderen Apps/Services gesammelt hat. Denn es ist und bleibt ein Passwort Manager. Wenn mit dem mal was sein sollte, hat man echt ein Problem. Ein richtig großes Problem. Das ist somit eigentlich das heikelste, was man überhaupt selbst hosten kann. Daher würde ich das auch nur Profis empfehlen. Im Zweifel lieber eine lokale App (Enpass, Keepass) ohne Cloud Anbindung nutzen. Ganz egal wie einfach die Installation am Anfang scheint. Die Installation ist in der Regel nie das große Problem. Der Betrieb ist es, vor allem der sichere Betrieb. Das kann heute wunderbar laufen und morgen hat man ein riesen Problem, weil man eine Sicherheitslücke nicht gepatcht hat. Und da liegen halt alle Passwörter drin, meistens auch Zugänge zu Banken und Kreditkarten. Da ist absolute Vorsicht geboten!Wer dann sagt, dass er lieber einen Services nutzen möchte, weil er sich das selbst nicht zutraut, macht das absolut richtig! Selbstüberschätzung ist ist den meisten Fällen nicht so schlimm, manchmal aber schon. Daher Respekt an alle, die das realistisch sehen und nicht einfach nur denken, dass es schon gut gehen wird.
-
Hallo zusammen,
ich wollte das erst im "längsten Thema" ansprechen, dachte mir aber, dass es dort evtl. etwas untergeht und durchaus ein eigenes Thema verdient hätte (schon alleine wegen der Länge). Im Grunde geht es um die ganze SSO Thematik bei selbst gehosteten Services (z.B. Gitea, Nextcloud, Wikijs, ...). Jetzt speziell im privaten oder Vereinsumfeld. Im geschäftlichen Umfeld kommt man ja meist sowieso an Microsoft AD nicht vorbei. Aber auch für den kleineren Bereich gibt es ja einige vielversprechende Lösung wie
* Authelia (Simpel, aber schlecht skalierbar, da alles über ein großes YAML File konfiguriert wird)
* Authentik (Vielversprechend, komplex, hat aber einige Probleme zu denen ich später noch komme)
* Keycloak (Sehr komplex, eher für das Enterprise Umfeld geeignet, schwierige Updates)* Zitadel (neu, weniger Features, schwierige Installation)
Das Protokoll, was man aktuell wohl einsetzen will, ist OpenID Connect (kurz OIDC), das auf OAuth 2.0 aufbaut. Ähnlich zu SAML, was aber durch die XML Struktur sehr komplex ist und daher schwierig is zu implementieren.
Was mich jetzt mal interessieren würde: Hat es jemand schon geschafft das wirklich zufriedenstellend zu implementieren? Mich beschäftigt dieses Thema schon so lange, baue mir immer wieder einen PoC, den ich aber immer wieder verwerfe, da ich wiederholt mit den gleichen Problemen zu kämpfen habe, für die ich einfach keine Lösung finde.1. User bleiben nicht eingeloggt
Dieses Problem beschäftigt mich vor allem mit Gitea. Das ist im Grunde einer meiner wichtigsten App. Die Integration des OIDC Providers funktioniert im Grunde problemlos. Einmal konfiguriert, können sich User dort anmelden und beim ersten Mal einen bestehende Account verknüpfen (falls vorhanden) oder einen neuen erstellen. Während aber lokale User mit einem Cookie eingeloggt bleiben, werden für OIDC User keine Cookies gesetzt. Sprich diese User müssen sich mit jeder Session neu anmelden. Das ist in der Praxis natürlich sehr nervig. Das passiert mit anderen Apps zum Teil auch, aber oft haben die einen automatischen Redirect zum OIDC Provider und der Login wird automatisch vollzogen. In Gitea muss man z.B. erst auf "Anmelden" klicken, dann auf den Provider und wird anschließend erst wieder eingeloggt.
Link zum Gitea Issue: https://github.com/go-gitea/gitea/issues/28394
2. User bleiben eingeloggtDas zweite Problem beschreibt im Grunde genau das Gegenteil. Das beobachte ich bei allen Apps, bei denen das mit dem Cookie klappt und User in der App eingeloggt bleiben, nachdem sie sich einmal erfolgreich am OIDC Provider authentifiziert habe. Und zwar bleiben die User auch dann noch eingeloggt, wenn diese sich aus dem eigentlichen OIDC Provider oder aus einer anderen Apps ausgeloggt haben. Entsprechend bleiben diese User auch dann noch eingeloggt, wenn der User sogar im zentralen OIDC Provider gesperrt oder gelöscht wurde. Das stellt aus meiner Sicht ein klares Sicherheitsrisiko da. Als Beispiel verlinkte ich da mal ein Issue bei Authentik:
Link zum Authentik Issue: https://github.com/goauthentik/authentik/issues/2023
Jetzt bin ich mal sehr gespannt auf eure Erfahrungen mit dem Thema. Gerade was die zwei genannten Probleme betrifft, die mich wirklich davon abhalten, dass ich das produktiv einsetzen kann. Ich vermute ja fast, dass an dem OIDC Protokoll an sich liegen könnte. Wie macht ihr das?
Gruß
Paul -
Mal ein Schuss ins Blaue: Wie sieht denn der Log Auszug bei den Servern aus, die kein changed anzeigen? Könnte es evtl. an der Sprache liegen? Ich habe jetzt auch den 2. Task bei mir mal getestet. Aber ich kann das Problem nicht reproduzieren. Bei mir ist die Sprache auf dem Server aber auch in Englisch. Ich könnte mir durchaus vorstellen, dass Ansible die deutschen Begriffe nicht richtig interpretiert. Denn dein diff aus dem Log Auszug wirkt seltsam.
So sieht das auf meinem Testsystem aus (Output ist in yaml, aber das macht sonst keinen Unterschied)Code
Alles anzeigenok: [host] => changed=false invocation: module_args: allow_change_held_packages: false allow_downgrade: false allow_unauthenticated: false autoclean: false autoremove: true cache_valid_time: 0 clean: false deb: null default_release: null dpkg_options: force-confdef,force-confold fail_on_autoremove: false force: false force_apt_get: true install_recommends: null lock_timeout: 60 only_upgrade: false package: null policy_rc_d: null purge: false state: present update_cache: null update_cache_retries: 5 update_cache_retry_max_delay: 12 upgrade: 'yes' msg: |- Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. stderr: '' stderr_lines: <omitted> stdout: |- Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. stdout_lines: <omitted>Ansonsten könntest du es natürlich auch nochmal mit der neusten Ansible Version versuchen.
-
Enpass ist super. Das habe ich auch lange genutzt. Etwas nervig ist da nur die Browser Extension, weil man dafür die Enpass App öffnen muss und die Extension dann über einen lokalen Port kommuniziert. Das ist mit einem Cloud Dienst natürlich etwas komfortabler. Empfehlenswert ist wohl auch Proton Pass. Da sitzt die Firma in der Schweiz, was schon mal ein Vorteil gegenüber allen US basierten Lösungen ist. Da habe ich aber nur mal die kostenlose Version angetestet und keine Langzeiterfahrung. Macht aber einen guten Eindruck.
Edit: Ganz vergessen. Im self-hosted Bereich ist ja Bitwarden bzw. Vaultwarden sehr beliebt. Das muss man aber nicht selbst hosten. Man kann auch den Cloud Dienst von Bitwarden selbst nutzen. Der ist im Vergleich zu anderen Diensten sogar recht günstig. So unterstützt man zumindest den Open Source Bereich etwas. -
Achso, welcher Task wird denn überhaupt als changed markiert? Der erste oder der zweite? Beim zweiten könnten es auch zurückgehaltene Pakete oder fehlerhafte dpkg-configure Tasks sein, die immer wieder gemacht werden. Auch da bietet es sich an, wenn man den upgrade Befehl direkt auf dem Server ausführt und sich den Ouput anschaut. Gerade wenn das ein Debian mit GUI ist, sind dort ja viel mehr Pakete installiert, die ggfs. Probleme machen könnten. Vielleicht gibt es auch andere Repos, die konfiguriert sind und dadurch Paket Konflikte auslösen. Gerade hier sind die Ausgaben von dpkg/apt manchmel sehr verbesserungswürdig.
-
Hm. Welche Ansible Version hast du denn im Einsatz? Ich habe deinen Task hier mal kurz gegen ein Debian 12 laufen lassen. Hier funktioniert es aber wie es soll. Beim ersten Mal ist der Task noch "changed", beim zweiten Mal ist alles ok. Du kannst das Playbook auch mal mit -Dvvv laufen lassen. Damit bekommst du etwas mehr Output. Du könntest ein apt update auch mal direkt auf dem Server ausführen. Evtl bekommst du dort noch andere Warnings oder Fehlermeldungen, die Ansible vielleicht unterdrückt.
Code
Alles anzeigenok: [host] => changed=false cache_update_time: 1730914435 cache_updated: false invocation: module_args: allow_change_held_packages: false allow_downgrade: false allow_unauthenticated: false autoclean: false autoremove: false cache_valid_time: 3600 clean: false deb: null default_release: null dpkg_options: force-confdef,force-confold fail_on_autoremove: false force: false force_apt_get: true install_recommends: null lock_timeout: 60 only_upgrade: false package: null policy_rc_d: null purge: false state: present update_cache: true update_cache_retries: 5 update_cache_retry_max_delay: 12 upgrade: null PLAY RECAP ************* host : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 -
Wenn du das Playbook zwei Mal direkt hintereinander ausführst, zeigt er dann trotzdem den ersten Task als "changed" an? Das sollte er eigentlich nicht, wenn das Modul richtig funktioniert. Beim ersten Durchlauf wird er es natürlich machen, weil
Codeupdate_cache: yesja den apt cache aktualisiert und damit eine Änderung macht. Falls dann auch Updates vorliegen sollten, würde auch der 2. Task ein "changed" zurückgeben. Aber wenn du das Playbook direkt nochmal ausführst, dann sollte eigentlich die cache_valid_time greifen und er sollte den cache dann nicht aktualisieren. Hast du dieses Szenario mal durchgespielt?
