Category Archives: Fedora

Fedora: Pinephone Status erreicht 100% Enduser Nutzbarkeit

Posted on by

Wow, was fürn Tag heute. Erst bekommen wir Software gegen unerwünschte Anrufer und dann das hier..

Fedora: Pinephone Status erreicht 100% Enduser Nutzbarkeit

Heute Nachmittag konnten Enduser endlich Ihre Korken knallen lassen: Das Pinephone erreicht die 100% auf der Enduser-Benutzerbarkeitsskala als GPS endlich Werte lieferte in Maps. Das die gelieferten Werte eher suboptimal sind, ist bei nebensächlich, da es bis dato unter Phosh gar nicht lief 🙂

Mit GPS ist die letzte in Deutschland übriggebliebene Lücke geschlossen worden, da MMS hier ohnehin bei den meisten Providern schon lange nicht verfügbar sind. Damit sind jetzt alle zu erwartenden Funktion in Betrieb:

– GPS ( Gnome-Maps )
– Sound
– WIFI
– Bluetooth
– Mobile-Data
– SMS ( Calls )
– Voice-Calls
– Email ( Geary )
– Surfen ( Firefox )
– Audio/Videochat ( Matrix )
– Fotos ( Megapixels )
– Filme aufnehmen ( wf-record )
– Musik hören ( via Kopfhörer & Lautsprecher )
– HW Beschleunigtes Videoplayback ( MPV )
– vernünftige Laufzeit ( 3 Tage )
– laufend Updates

Da es noch kein „offizielles“ RPM aus dem Fedora SIG Mobility Copr-Repo gibt, hier ein Build von mir für euch, direkt aus dem RPM Ofen:  modemmanager-agps-1-1.aarch64.rpm

Einen großen Dank an alle die dabei geholfen haben, jetzt wird es Zeit ins Stable zu wechseln und einen Mobility Spin für Fedora zu bauen.

 

Pinephone: Phosh-Antispam gegen Robocalls

Posted on by

Endlich mal wieder was positives vom Pinephone zu berichten. Diesmal geht es um Robocalls und wie man die los wird.

Pinephone: Phosh-Antispam gegen Robocalls

Ich weiß, ich habe lange nicht übers Pinephone berichtet, weil es keine neuen Highlites gab. Die letzten Monate haben wir uns mit Pipewireproblemen rumgeschlagen, die Anrufe unmöglich gemacht haben, weil die Umschaltung in den Telefonmodus nicht funktioniert hat. Wer das Problem noch hat, hier die Lösung:

dnf swap pipewire-pulseaudio pulseaudio

Damit ist wieder Pulseaudio das Maß aller Dinge und Pipewire erstmal wieder draußen. Anrufe sind wieder möglich, was mir dann negativ damit auffiel, daß mein Kingelton weg war 🙂 naja, das ist ein eher privates, unbedeutendes Problem, das leicht gelöst werden kann:

Pinephone: DANKE ModemManager!

Aber jetzt ging es ja um RoboCalls, ein Phänomen das mehr im Rest der Welt ein Problem darstellt, bei dem Werbung, Scamversuche und ähnliches per automatischem Anruf und von Roboterstimmen vorgetragen wird.

Chris Talbot ging das so auf den Keks, daß er „Phosh-Antispam“ geschrieben hat. Damit kann man Anrufe, von Nummern die nicht im Adressbuch stehen, einfach blocken lassen. Seiner realistischen Einschätzung nach, wird ein echter Mensch der einem was zu sagen hat, nochmal anrufen, was dann erkannt und akzeptiert wird. Damit ist das eine Art Greylisting, wie man das vom Emails kennt 😉

Ich war mal so frei ein RPM für Fedora 36 zu bauen:  phosh-antispam.rpm

Kleiner Hinweis: bei der Installation wird Phosh neugestartet, also nicht wundern 😉

Das sieht dann so aus:

„Silence instead of Hangup“ meint, daß der Anruf lautlos durchklingelt, denn normalerweise wird der Anrufer auf die Mailbox umgeleitet, aber ggf. will seinen Anrufbeantworter nicht vollspammen lassen und dem Bot so signalisieren, daß er einen mal ….. kann.

„Allow Callback“ meint, daß je nach Anzahl darunter Anrufen, der Anrufer dann durchkommt. Wer es ersnst meint mit dem Anruf, drückt ja vermutlich sofort auf „Wahlwiederholung“.. so die Theorie 😉

Warum man Anrufer mit unterdrückter Nummer im Jahr 2021 noch durchlassen sollte, entzieht sich mir jetzt, aber bitte, wers braucht.

 

Alles in Allem finde ich das eine Gute Idee, auch wenn ich in 10 Jahren erst einen Robocall hatte und den hat wohl Axel-Springer dann so derbe auf Schadensersatz verklagt, weil die in deren Namen, mit einer Hamburger Nummer die Leute mit einem Gewinnspielversprechen genervt haben 😀

LUKS verschlüsselter Cloud-Raid 10

Posted on by

„Herzlich willkommen zu Ihrem neuen „Ärger den Hoster“ Projekt. Heute wollen wir Ihnen zeigen, wie Sie Webstorageanbieter wie OneDrive oder DropBox in die Knie zwingen können.“  🙂

LUKS verschlüsselter Cloud-Raid 10

Das ist zwar nicht das Ziel unseres kleinen Projekts, könnte aber passieren ;)Beim letzten Linux am Dienstag, hab es ja leider eine kleine Panne bei der Webserverzertifizierung, was uns aber nicht daran gehindert hat, es doch durchzuziehen 😉 In diesem Rahmen habe ich das Projekt schon einmal Live vorgestellt.

Worum geht’s denn eigentlich?

Ihr kennt ja vermutlich den Beitrag, wie man mit SSHFS und Veracrypt einen sicheren Container bei einem Cloudanbieter bauen kann. Das hatten wir ja im Rahmen des letzten LPD 2021.1 vorgestellt. I.d.R. reicht dies für die meisten Sachen völlig aus, hatte aber noch Potential, oder auf Deutsch, ein paar spannende Ecken zum ausforschen, was so geht 😀

Herausgekommen ist eine verschlüsselte, virtuelle Festplatte als RAID 10 mit Spare, die komplett im Netz liegt, aber nur auf dem Lokalen PC vollständig und nutzbar ist. Um die Spannung gleich etwas abzumildern, die Sache mit den Hostern ist, daß sobald sich ein Bit ändert in dem für den Raid genutzten LUKS Container, ist der Container komplett im Backup drin. Wenn der also GBs groß ist, dann belegt das sehr viel Platz im täglichen Backup des Hosters, was Hoster i.d.R. nicht gut finden 😉

Vorteile

  • Es müssen mehrere Hoster ausfallen, bevor das Raid auseinander fällt und Daten verloren gehen.
  • Je kleiner dabei die einzelnen Datenfiles bei den Hostern sind, desto schneller der Rebuild und desto einfacher die Suche nach geeigneten Hosterkandidaten.
  • Das Raid kann von jedem Ort der Welt sicher eingebunden werden.
    Keine Spuren auf dem eigenen PC
    Der Hoster kommt nicht an die Daten ran.

Es sind auch alle anderen Raidformen denkbar, von Raid 1 bis 60 . Denkt mal ein bisschen nach, wieso ich da kein Raid 0 liste.

Nachteile

Ist das Internet nicht erreichbar, oder kommt es auf Netzsegmenten zwischen sich und dem Hoster zu Problemen, fällt das Raid ggf. unabsichtlich aus oder kann gar nicht erst gemountet werden.
Der Raidrebuild ist sehr langsam, langsamer als Ihr jetzt vermuten werdet. Bei Tests 128 KB/s, statt mehreren MB/s.
Keine Redundanz auf dem PC
Das Raid kann immer nur von einem PC aus zusammengesetzt werden. Mehrere würden die Daten zerstören, außer Ihr seid völlig durchgeknallte Datenjongleure 😉

Sinnhaftigkeit

Über die Sinnhaftigkeit eines Cloudbasierten virtuellen Raid 10 muß man sich keine großen Gedanken machen, da es nur eine Grenzfallbetrachtung ist.

Auf der anderen Seite, ein Raid 1 mit einem lokalen Bein und einem, oder mehreren, bei einem Cloudhoster, ist schon deutlich sinnvoller. Das lokale Bein (so nennt man eine Seite des Raids ) hat eine extrem hohe Schreib- und Lesegeschwindigkeit (weil im Tests wars eine NVME ), im Vergleich zum Netzwerk. Das führte bei Tests des Systems zu einer schnellen Reaktion, wie bei einer normalen Platte, und im Hintergrund wurde das dann langsaaaammmm synchronisiert. Das fällt dem Nutzer erst dann auf die Füße, wenn er was ins Raid schreibt und dann das Laptop oder den PC abschaltet, bevor das Raid komplett gesynct ist.

Das Raid würde sich beim nächsten mal zwar reparieren, meistens in dem das Spare genutzt wird, so vorhanden, in ganz wenigen Fällen auch einfach weiter syncen. Eine gute Idee ist es definitiv nicht.

Alternativen

Wer Daten vom PC zu einem Cloudanbieter so spiegeln will, daß eine Backupkopie verhanden ist, sollte dort einen LUKS oder VeraCrypt-Container hinterlegen, den per SSFS anbinden, öffnen und dann mit RSYNC oder einem Clusterfilesystem arbeiten.

Zurück zum Raid 10 in der Cloud

Da ich keine Lust habe, den 45 Minuten Vortrag nochmal zu tippen, hier die Quelle:

Click to access LAD-Raid-10-in-der-Cloud.pdf

Quelle: https://linux-am-dienstag.de/archiv/LAD-Raid-10-in-der-Cloud.pdf

Noch ein paar Anmerkungen

Man kann das auch mit ZFS bauen. Wie gut da die Krypto ist, kann ich nicht beurteilen. Außerdem ist es nicht auf jedem System drauf und es ist definitiv eher auf physikalische Datenträger ausgerichtet.

Die Sache mit dem kpartx ist eine Nummer, die sich nicht jedem sofort erschließt. Ich rate dazu, wenn Ihr das nachbaut, ein Terminal offen zu haben, das „watch -n 1 lsblk“ anzeigt. Damit wird einiges einfacher zu verstehen.

Die Failzeiten des SSHFS sind willkürlich gewählt, wie es meinem Gusto entsprach. Ihr könnt natürlich selbst entscheiden, ob Ihr da 3 Sekundenoder 30 Sekunden bis zum Fail angebt. Im Vergleich zur Dauer eines Rebuild mit 128 KB/s, sind diese exemplarischen 27 Sekunden natürlich nur eine kurze Zeitspanne.(50 MB Raidfiles => ca. 90 Minuten Rebuild )

Ein Raid 1 mit mehr als einem Cloudhoster ist vermutlich die bessere Wahl, kommt aber aufs Szenario an, welches man abdecken möchte.

Die Doppelte Lage LUKS könnte man auch durch eine LUKS ( Webhoster ) – VeraCrypt – Kombination ersetzen, was andere Verschlüsselungsalgorithmen beinhalten würde, was das brechen der Gesamtverschlüsselung deutlich erschwert. Auch könnte es einem in den Sinn kommen, die LuksFormatierung für jedes Datenfile einzeln zu machen, damit dort andere Kryptokeys im Einsatz sind. Weil, nach dem obigen Plan, sind die alle gleich. Bricht also ein LUKS-Container auf, gehen alle auf. Deswegen wäre es eine gute Idee, die planetenweit zu verteilen, was das Ergreifen der Daten deutlich erschwert.

Von Experimenten wie dem Speichern der Daten auf dem Draht der Netzwerkverkabelung ist dringend abzuraten, weil sich da kein LUKS Container drauf abbilden läßt 😉 Das ist ein echt höchst instabiles Speichermedium, wie unsere Tests bei Linux am Dienstag gezeigt haben 😀