Diskussionen & Ankündigungen dieses Hubs - netzgemeinde-hub@hub.netzgemeinde.eu

General: This is the home page of a channel. It is similar to someone's profile "wall" in a social network context. Posts created by the channel are displayed according to the observer's viewing permissions.
Create a Post: If you have permission to create posts on the channel page, then you will see the post editor at the top.

Gab's ein Update?

Milky Way, Thu, 14 Feb 2019 22:19:57 +0100

!Diskussionen & Ankündigungen dieses Hubs Ich stelle an verschiedenen Ecken komisches Verhalten von Stream, Links, Benachrichtigungen etc. fest, die ich so bislang nicht kannte:

Links zu Website öffnen plötzlich im selben Fenster
Verbindungsanfragebenachrichtigungen werden nicht auf 0 gesetzt, wenn ich abgelehnt, blockiert oder angenommen habe
Unkontrolliertes Springen: beim Vergeben von Likes finde ich mich irgendwo in der Timeline wieder, nur nicht da, wo ich gerade aktiv gewesen bin. Nicht reproduzierbar, weil ständig andere Sprungziele.

An den Browsereinstellungen habe ich nicht gedreht. Ein automatisches Update scheidet auch aus, weil ich gerne weiß, welche und vor allem wann Updates aufgespielt werden.

mehr anzeigen 8 Kommentare

Carsten Müller

Thu, 14 Feb 2019 22:25:38 +0100

Das unkontrollierte springen kenn ich auch von Hub.libranet.de

Olaf Wendt (Hz)

Thu, 14 Feb 2019 22:26:32 +0100

Immer schon oder erst seit Neuestem?

Carsten Müller

Thu, 14 Feb 2019 22:31:57 +0100

Seit einigen Tagen

Mark Nowiasz

Fri, 15 Feb 2019 07:34:51 +0100

Ist bei mir nicht ganz der Fall. Mal der Reihe nach:

Vor 12 Tagen gab es das Update auf 3.8.9. Eine Änderung betraf auch das Verhalten von Likes:
Fix page jumping when liking collapsed/expanded post
Ich persönlich habe seit der Änderung weniger Sprünge als vorher, vorher bewirkte bei mir ein Like dass der Beitrag wieder ganz oben im Stream einsortiert wurde und ich hatte den Sprungeffekt
Das mit Links im selben Fenster öffnen würde ich eher als Browserproblem sehen. Hatte ich bislang noch nie
Ditto das mit dem Verbindungsanfragezähler.

Ich selbst bin kein Frontendler -wenn überhaupt, dann eher Backendler - für mich (rein ins Blaue geraten, wenn jemand mehr Ahnung hat, möge mich bitte korrigeren) sieht das evtl. nach Javascript/Caching-Problem aus. Wie immer in solchen Fällen (und um das auszuschließen) probiere mal das folgende aus:

Ausloggen, und zwar überall
Den Browsercache löschen
Browser neustarten und einloggen

Guck mal nach ob es damit behoben ist.

Dejan Milosavljevic

Fri, 15 Feb 2019 20:46:39 +0100 via Diaspora

@Olaf Wendt (Hz) Habe ich was verpasst? Hast Du einen eigenen (neuen) Hubzilla-Pod am laufen?

Olaf Wendt (Hz)

Fri, 15 Feb 2019 21:41:51 +0100

@Mark Nowiasz Danke fürs Aufdröseln. Allsooo..., nachdem ich alles

Weil ich das mit den gefixten Like-Sprüngen gelesen hatte, habe ich mich gewundert. Derzeitiges Verhalten (bei Friendica- und Diaspora-Kontakten gleichermaßen): Erster Like > 4 Beiträge Rücksprung. Ent-Like > 2 Beiträge Rücksprung. Erneuter Like > Kein Sprung. ... Ich werde nicht weiter drüber nachdenken, das klingt mir zu sehr nach Mathematik. Das neu Einsortieren wie von Dir beschrieben kannte ich zum Beispiel nicht.
Links als target: _blank -- Funktionieren wieder. Der Tipp, die Browser-Daten löschen war diesmal die Lösugn, selbst Google hatte zuletzt gemotzt.
Ich erhalte derzeit zu wenige Verbindungsanfragen, um den letzten Punkt wieder aufzugreifen.

Mal als Gedankenmodell: Caching-Infos und -Turni werden zunächst mal serverseitig vorgegeben - ist es eventuell sinnvoll, den Cache auf dem Server zu bereinigen, sobald ein Hz-Update eingespielt wurde? Wenn ich meine Fehler-Erlebnisse und deren Lösung so anschaue, könnte es durchaus damit zu tun haben, dass ein Browser durcheinander kommt, wenn er --je nach Verwendungszweck-- Cache-Dateien verarbeiten soll, die aus zwei verschiedenen Programmversionen stammen.

@Dejan Milosavljevic Nö, NOCH nicht. Ist aber auf dem neuen Server zumindest als Klon dieses Kanals geplant

Olaf Wendt (Hz)

Fri, 15 Feb 2019 21:48:00 +0100

Es sollte heißen: "Allsooo..., nachdem ich alles gemacht habe wie angeraten und nach den letzten Tests ergibt sich folgendes Bild:"

Marko_D

Sat, 16 Feb 2019 00:14:30 +0100

was mir auffällt: beim Öffenen des Streams auf dem iPhone funktionieren keinerlei Controls (Aufklappen von Beiträgen und Kommentaren, Kommentare verfassen,...)
Wen ich allerdings auf einen Link einer erhaltenen Statusmail klicke, funktioniert alles normal. Sehr merkwürdig.

einzelne user blockieren

Alexander Goeres

Berlin, Fri, 08 Feb 2019 11:39:06 +0100 zuletzt bearbeitet: Fri, 08 Feb 2019 11:57:53 +0100

!Diskussionen & Ankündigungen dieses Hubs
nur mal eine allgeme frage zur benutzung von hubzilla, weil ich das, was ich gefunde habe, etwas verwirrend finde.

ich habe in einzelnen threads user, die offenbar ihre koprolalie laut hinausschreien müssen, was ich aber nicht sehen will. ich suche nach einer methode, die äußerungen dieser leute wegzufiltern.

das einzige was ich bis jetzt hier gefunden habe, war, in verbindungen eine verbindung zu diesen leute einzurichten und die dann zu blockieren. obwohl ich nicht weiß, ob das dann auch ihre kommentare blockiert.

was mich so verwirrt, ist, dass ich erst eine verbindung einrichten muss um die dann gleich zu blockieren.

gibt es irgendwie eine andere/richtige/leichtere methode, die anfälle einzelner user hier nicht zu gesicht zu bekommen?

mehr anzeigen 12 Kommentare

Mark Nowiasz

Fri, 08 Feb 2019 12:22:07 +0100

Klar, geht ganz einfach - wenn man weiß wie

Das hat mich auch am Anfang verwundert, gibt aber eine ganz einfache Möglichkeit. Du musst dafür das Addon "Superblock" aktivieren.

Danach kannst Du - egal wo - in Diskussionen/Kommentaren auf das Profilfoto desjenigen gehen und Du hast dann die zusätzliche Option "Blockieren" (oder so) -> Problem erledigt. Ich selbst habe schon 4 Leute blockiert.

Alexander Goeres

Fri, 08 Feb 2019 15:21:08 +0100

genau das habe ich gesucht. vielen dank für den hinweis ...

Mark Nowiasz

Fri, 08 Feb 2019 16:37:28 +0100

@Alexander Goeres Kein Problem, exakt genau so wie Dir ging es mir auch bis ich das herausgefunden habe

Olaf Wendt (Hz)

Fri, 08 Feb 2019 17:46:22 +0100 zuletzt bearbeitet: Fri, 08 Feb 2019 17:47:56 +0100

Es geht vielleicht ohne die Holzhammer-Methode Superblock. Anfangs macht diese Methode bestimmt mehr Aufwand, doch wenn es auch Beiträge von diesen Menschen gibt, die man sich antun kann, hilft vielleicht der ff. Ansatz:

N.SFW App installieren, falls noch nicht geschehen (Menü > Apps installieren)
N.SFW App konfigurieren (Menü > Apps installieren > [Manage Apps] > aufs verlinkte Wort "N.SFW" klicken
Dort die "gängigsten" Begriffe, Links, Dateiendungen und Tags kommagetrennt sammeln

Im Stream erscheinen die Beiträge zwar immer noch, sind jedoch platzsparend eingeklappt und mit einem Button versehen, der mit genau dem ersten gefilterten Wort beschriftet ist. Filtert man also f*ck, steht auch f*ck auf dem Button - nicht super ideal, aber immerhin erleichtert es die Übersicht.

Ich filtere zum Beispiel auch Bildformate und Foto-Plattformen, so kann ich "gucken oder nicht" je nach Autor entscheiden und muss besonders am schmalen Smartphone nicht scrollen, bis der Orthopäde kommt.

Olaf Wendt (Hz)

Fri, 08 Feb 2019 17:52:30 +0100

PS: Ich sehe gerade, auf Kommentare hat der Filter leider keinen Einfluss.

Mark Nowiasz

Fri, 08 Feb 2019 18:04:46 +0100

Ja, OK. Ich blocke normalerweise auch nicht sofort, ich habe z.B. jemanden in meinem Stream, der durchaus mal interessante Sachen postet - aber auch Verschwörungstheorien. Letztere ignoriere ich dann eher mental als ihn ganz zu blocken

Alexander Goeres

Fri, 08 Feb 2019 19:46:21 +0100 zuletzt bearbeitet: Fri, 08 Feb 2019 19:53:45 +0100

sofort blockieren ist ja auch nicht hilfreich. ich will ja nicht immer nur die sachen hören, die ich sowieso schon kenne. manchmal ist es aber doch wünschenswert.

bei g+ habe ich es meistens erreicht, dass die spinner mich irgendwann von sich aus blockiert haben, wenn man nur lang genug vernünftig auf sie eingeredet hat. hier aber im fediverse, mit den ganzen komischen nebeneffekten zwischen den unterschiedlichen protokollen, will ich einfach nur mal die leute los werden, die hier ihre schizoiden schübe ausleben. mit solchen menschen kann man sowieso nicht diskutieren, da ist die blockliste die gesündere und hilfreichere maßnahme.

PS: ach ja, und superblock funktioniert genau so, wie gewollt! danke nochmal für den tip!

Mark Nowiasz

Fri, 08 Feb 2019 19:52:55 +0100 zuletzt bearbeitet: Fri, 08 Feb 2019 20:05:16 +0100

Nee, es geht mir gar nicht um andere Meinungen - im Gegenteil, ich mag es mir konträre Meinungen anzuhören und darüber nachzudenken, nur so kann man auch an sich arbeiten - sondern um Leute, die nicht anständig diskutieren wollen und auf jegliche rationale Argumentation, die gegen ihre Meinung ist, aggressiv und unsachlich reagieren 🙄Wutbürger halt, egal welcher Couleur. Dafür fehlt mir die Geduld.

Olaf Wendt (Hz)

Fri, 08 Feb 2019 20:02:51 +0100

Hier habe ich zum Glück noch keine derartig negative Erfahrungen machen müssen. Vielleicht bin ich übervorsichtig, aber meine Verbindungsliste wird weiter laaangsam und organisch wachsen. Was mir (besonders bei Diaspora) langsam Sorgen bereitet, sind Fake-Profile, die mit ihren 0815 Bios und geklauten Bildern wie Pilze aus dem Boden schießen.
Auf den ersten Blick habe ich bei Dir @Alexander Goeres auch gleich eines gefunden, mittlerweile das fünfte "Book Collector" Profil mit Profilbildern von hübschen Hippie-Mädchen, die aus einem spanischen Modemagazin geklaut sind. Da werden nur Katzenfotos und Memes geteilt. (irgendwas auf dem nerdica.ch Pod, den genauen Namen habe ich mir nicht gemerkt).

Alexander Goeres

Fri, 08 Feb 2019 20:23:46 +0100

@Olaf Wendt (Hz) der, den ich blockiert habe, hat seine tourette-rants auch über ein nerdpol.ch profil abgelassen. aber solange die leute nur irgendwelche robert-crumb-bildchen psten, finde ich es nicht sonderlich störend.

aber es ist doch irgendwie niedlich, wenn man merkt, dass das fediverse im internet angekommen ist, dadurch dass man auf einmal facbook- und gplus-ähnliche fakeprofile sieht.

ich hatte neulich sogar schon meinen ersten spammer via diaspora. das war ein wenig, wie die erste fliege am fenster zu sehen, nach einem langen harten winter ...

Olaf Wendt (Hz)

Fri, 08 Feb 2019 20:34:43 +0100

Ja, @Alexander Goeres , ich glaube wir hatten den gleichen Spammer (blaues Jacket vor Weihnachtsbaum, wollte billige Kredite vermitteln?).

Ich befürchte schon, dass ich zu Zap wechseln muss, wenn mir das hier alles zu "mainstream" wird. Und GNU social gibt's ja auch noch

Mark Nowiasz

Fri, 08 Feb 2019 20:42:40 +0100

Ach was, auch zu den besten Zeiten des Usenets (IMHO so Ende der 90er) gab es ähnliche Spinner und Spammer. Den Kreditspammer von framosphere hatte ich auch 😒

Wartung/Maintence 2018-02-06 7:30-8:30

Mark Nowiasz

Tue, 05 Feb 2019 12:38:32 +0100

!!Diskussionen & Ankündigungen dieses Hubs
Hi, zwei Sachen, eine generelle und eine konkrete:

Dieser Hub hat sich wirklich gut entwickelt. Da immer mehr User den Hub nutzen - was im Sinne des Erfinders ist -, anderseits ab und zu Wartungsarbeiten erforderlich sind, werde ich dies auch etwas professionalisieren: Es gibt wöchentlich jeden Mittwoch zwischen 7:30 und 8:30 ein planmäßiges Wartungsfenster. Dies werde ich keinesfalls immer nutzen, aber wenn Probleme auftauchen (Seite nicht erreichbar, neues Einloggen) in dem Zeitraum dann bin ich am warten Davon unbenommen sind natürlich außerplanmäßige Notfallwartungen,
Konkret morgen: Die Sessions im RAM funktionieren wunderbar, allerdings ist die Lebensdauer ein bisschen hoch (14 Tage). Ich werde diese auf 2 Tage reduzieren. Das bedeutet nur dass - wenn Ihr innerhalb von zwei Tage nnciht mit der Seite interagiert habt - ihr Euch ggfls. neu einloggen müsst. Sobald ihr irgendwas macht startet quasi der Timer wieder neu. Sollte also keine großen Auiswirkungen haben. Dafür muss ich allerdings PHP-FPM neustarten, was in diesem Fall ein kompletten Verlust aller Sessions zur Folge haben wird. Bei der Gelegenheit kann ich auch gleich den Server komplett rebooten um den Kernel upzudaten.

mehr anzeigen 5 Kommentare

Mark Nowiasz

Wed, 06 Feb 2019 08:33:28 +0100

Ja, bin noch dabei, hab weas übersehen

Carsten Müller

Wed, 06 Feb 2019 08:35:30 +0100

ah gut dachte schon ist so ein sinnloser Bug in Riot :)

Mark Nowiasz

Wed, 06 Feb 2019 08:43:23 +0100

Läuft nun wieder sauber. Die Umstellung von Python 2.7 auf 3.x war nicht ganz so einfach wie die Doku es darstellt. rsync hier, cp da, hier Pfade anpassen... egal, läuft nun sauber und python3

Wartungsfenster/Maintenance Window

Beginnt: Mittwoch, 06. Februar 2019, 07:30

Endet: Mittwoch, 06. Februar 2019, 08:30

Diskussionen & Ankündigungen dieses Hubs

Tue, 05 Feb 2019 12:24:39 +0100

Update to 3.8,9

Mark Nowiasz

Sun, 03 Feb 2019 18:07:37 +0100

!!Diskussionen & Ankündigungen dieses Hubs

Ich habe soeben Hubzilla auf 3.8.9. upgedated. Keine Probleme aufgetreten, funktioniert alles wie gewohnt

deutsch english

Slight changes in sessions/Kleine Änderungen in Sessions

Mark Nowiasz

Wed, 30 Jan 2019 12:43:14 +0100

!!Diskussionen & Ankündigungen dieses Hubs
Hi,
die Umstellung auf Files bei den Session war so weit erfolgreich und funktioniert ganz gut, allerdings sind mir zwei Sachen aufgefallen:

Beim Neustart von PHP (FPM) sind alle alten Sessions ungültig. Leider ist dies ab und zu notwendig, wie gestern beim Debuggen des Channel-Problems von @Olaf Wendt (Hz). Das ist blöd, zumal Updates von PHP/Änderungen der Konfiguration ggfls. einen Neustart erfordern
DIe Default Einstellung der Sessions bei PHP ist ein wenig knapp: 24 Minuten. Wenn Ihr 24 Minuten nicht mit der Seite interagiert habt gibt es eine Wahrscheinlichkeit von 1%, dass die Session gelöscht wird und Ihr Euch neu einloggen musst. Mich trifft das immer wieder wenn ich per mobile zugreife, bei Desktop jedoch nicht (warum auch immer). Das ist nervig.

Für beides gibt es Abhilfe, die mindestens genauso schnell ist wie FIle-Sessions (in /tmp) - meine ursprüngliche Idee, memcached. Die Sessiondaten werden in ein reinen RAM-Datenbank gespeichert und sind - während der Laufzeit des memcacheds - persistent, ein Reboot des Servers (oder Neustart des memcacheds) führt natürlich wieder zu Sessionverlusten. Gleichzeitig werde ich die Sessionlebensdauer auf 14 Tage(!) erhöhen - damit solltet Ihr mindestens(!) 14 Tage Ruhe vor dem Neueinloggen haben, wobei es auch hier Ausnahmen gibt: Wenn extrem viele Sessions eröffnet werden wird der memcached die ältesten Einträge löschen, egal wie die Laufzeit ist.

Da die Umstellung mal wieder mit Sessionverlusten verbunden ist, wollte ich die Änderung ankündigen - ich werde morgen früh so gegen 7:30 (früher oder später) die Änderung tätigen, wenn Ihr Euch neueinloggen müsst, wisst Ihr warum

deutsch english

mehr anzeigen 10 Kommentare

Alexander Goeres

Wed, 30 Jan 2019 12:49:45 +0100

ist memcached schneller als eine ram-disk im /tmp?

Mark Nowiasz

Wed, 30 Jan 2019 13:00:40 +0100 zuletzt bearbeitet: Wed, 30 Jan 2019 13:01:15 +0100

@Alexander Goeres Vermutlich ja, denn memcached ist eine simple Key-Value-Datenbank, während tmpfs ein Dateisystem simulieren muss. Ist aber eine reine Vermutung - ich glaube allerdings kaum dass der Unterschied zwischen beiden spürbar bemerkbar ist, im Gegensatz zu Sessions in der DB. Mein kleiner Patch dazu ist im übrigen angenommen worden und dürfte beim nächsten Release von Hubzilla ausgerollt werden

Mark Nowiasz

Thu, 31 Jan 2019 07:31:19 +0100

So, erledigt. Mal schauen wie das nun weiter geht

Olaf Wendt (Hz)

Thu, 31 Jan 2019 10:11:12 +0100

Läuft bis jetzt ohne sichtbare Kollateralschäden

Mark Nowiasz

Thu, 31 Jan 2019 10:13:17 +0100

Ich selbst bin nicht einmal (mobile, bei Desktop war das nie der Fall) herausgeflogen

D.H. das stimmt nicht ganz: Ich hatte noch einen alten Browsertab mit der entsprechenden ungütligen Session. Im Zweifelsfall einfach alle entsprechenden Browsertabs mit älteren Sessions schließen (oder einfach den Browser neustarten), dann sollte Ruhe einkehren

Mark Nowiasz

Thu, 31 Jan 2019 10:52:44 +0100

Dreck, ich habe es wieder umgestellt auf FIle-Based-Sessions - ich hatte ganz merkwürdige Effekte, die ich persönlich vorher bei memcached-Sessions nie erlebt hatte: Mein Strom hat neu geladen, kurz was angezeigt, dann neu-- und das mehrmals. Dann bin ich plötzlich ausgeloggt worden. OK, hat keinen Sinn so, muss das mal genauer auf meinem Testhub debuggen.

Welche Änderungen allerdings geblieben ist: Die Session-Dauer von 14 Tagen, sowie eine noch geringe Chance des Garbage Collectors. So sollte das Ausloggen behoben sein

Olaf Wendt (Hz)

Thu, 31 Jan 2019 10:59:50 +0100

Ah, daher die Rausschmisse. Jetzt ist wieder gut. (10:59)

Mark Nowiasz

Thu, 31 Jan 2019 11:01:52 +0100

Jau. Eine Theorie: Die Größe der Hashs ist zu gering, so dass es zu Kollisionen kommt, ich meine mich dunkel daran zu erinnern dass das was war. Egal, ist nun wieder auf file-based umstellt

Olaf Wendt (Hz)

Fri, 01 Feb 2019 00:55:25 +0100

Ich wollte mal gucken, warum Du zwei Kategorien "deutsch" und "english" für diesen Beitrag verwendet hattest: [observer.language=de/en] etc. sind ja echt tolle Feature! Ich habe jetzt erst begriffen, was Mario derletzt in einem Kommentar-Thread zum Versions-Update meinte, nachdem ich hier in die <Quelle> gucken konnte. Hätte er doch gleich auf /help/de-de/member/bbcode#Hubzilla_specific_codes verlinkt

Doch eines finde ich unlogisch: Ich kann hier alles tun, solange dieser Beitrag auf der Kanalseite "Diskussionen und Ankündigungen..." in Reihe mit den anderen Beiträgen des Forums steht: Quelltext angucken, kommentieren, liken, ... aber wenn ich auf den Titel bzw. beim Zahnrad auf "Link zur Quelle" [´] klicke, geht zwar der Link https://hub.netzgemeinde.eu/channel/buckaroo/?f=&mid=064e29e19185e73d461f47d5ff07bbb94cdad18fca4a5ce6666f8bf73da4147f@hub.netzgemeinde.eu auf, aber ich bekomme angezeigt:

Berechtigung verweigert

Ist die !! mention für Foren dermaßen restriktiv, dass ich solch einen Beitrag nicht einzeln ansehen darf? Im Quelltext sind ja keine Bedingungen für Authentifizierung per [observer=1] oder [observer=0] gesetzt, und selbst wenn..?

Olaf Wendt (Hz)

Fri, 01 Feb 2019 01:18:48 +0100

Eine Viertelstunde später fiel der Groschen: Per "!!" Mention hast Du Dich beim Posten dafür entschieden, diesen Beitrag ausschließlich im Forum anzeigen zu lassen, sozusagen One Way Ticket ohne Rückfahrschein. Logisch, dass ich jetzt als Außenstehender nicht entscheiden darf, diesen Beitrag dennoch in Deinem Kanal anzusehen, selbst wenn Du ihn von dort aus geschrieben hast.

Wollte man Korinthen zählen, müsste eigentlich der "Link zur Quelle" hinterm Options-Rädchen deaktiviert werden, weil es keinen Sinn macht, eine "Kopie" öffnen zu wollen, für welche niemand zum Ansehen berechtigt ist, aber sei's drum.

Enter the Matrix, Teil 2

Mark Nowiasz

Mon, 28 Jan 2019 11:02:07 +0100 zuletzt bearbeitet: Mon, 28 Jan 2019 11:04:29 +0100

!Diskussionen & Ankündigungen dieses Hubs

Ich habe seit einiger Zeit einen Matrix-Homeserver laufen, kurze Erklärung was Matrix ist: Eine Art verteilter Messengerdienst inklusive Video- und Audiochat, (optionaler) End-zu-End-Verschlüsselung sowie IRC-ähnliche Funktionen wie Räume/Kanäle, es gibt dort auch einen Hubzilla-Kanal

Siehe dazu auch https://matrix.org/blog/home/
Bislang nutze ich diesen - zusammen mit @Marcus Wißmann - alleine, da dieser eine sqlite-DB nutzte welche recht ineffizient ist.

Nun habe ich im Zuge der Umstellung (zusätzlichen Datenbank-Master auf SSD) auf dem Host, wo der Matrix-Server läuft, Kapazitäten für einen eigenständigen Datenbankserver frei (der MySQL-Slave, der dort lief, ist nun auf dem ehemaligen Master) und ich habe dort nun eine PostgreSQL laufen, synapse von sqlite auf PostgreSQL umgestellt und der Geschwindigkeits-/Effizienzschub ist schon beeindruckend. Deshalb kann ich nun die Instanz für Registrierungen freischalten

Die Adresse des Matrix-Servers ist https://matrix.netzgemeinde.eu/.

Ursprünglich gab es auch einen eigenen, kleinen Webclient, dieser ist mit dem letzten Update leider flöten gegangen, deshalb braucht Ihr einen eigenen Client (auch für die Registrierung), diese findet Ihr unter https://matrix.org/docs/projects/try-matrix-now.html#clients, ich selbst habe diverse ausprobiert und festgestellt dass der Riot-Client (Desktop, Browser, Android) der Beste mit den meisten Features ist.

Um das ganze zu testen ohne direkt Software zu installieren genügt der Javascript-Webclient unter https://riot.im/app/ völlig aus - darüber kann man sich auch registrieren: "Benutzerdefinierter Server -> Heimserver-URL: https://matrix.netzgemeinde.eu/)

Die Usernamen haben dann die Form @user:@netzgemeinde.eu, ich bin @pastor:@netzgemeinde.eu

Achtung: Ich habe den Registrierungsprozess - der nun theoretisch offen ist - noch nicht ausprobiert. Wenn es Probleme gibt, bitte Bescheid sagen. Was ich ebenfalls noch nicht getestet habe: Serverübergreifende Audio- oder Videochats. Ist zwar alles nach Anleitung konfiguriert, aber ungetestet. Audi-/Videochat auf dem Server selbst funktionieren tadellos.

Ich habe auch einen Kanal (#netzgemeinde:netzgemeinde.eu) eingerichtet für Diskussionen über die Hubzilla oder Matrix-Instanz, primär gerichtet (logischerweise) an die User der Insanzen, aber der Kanal ist für alle offen.

In diesem Sinne: Man sieht sich in der Matrix

deutsch Matrix

mehr anzeigen 8 Kommentare

Sophie

Mon, 28 Jan 2019 11:19:05 +0100

Farlion

Mon, 28 Jan 2019 11:25:23 +0100

Das klingt ziemlich spannend. :)

Mark Nowiasz

Mon, 28 Jan 2019 11:30:41 +0100

Es ist ein wenig wie Hubzilla: Dezentrales Netzwerk, jeder kann homeserver aufsetzen und sich verbinden, ist nicht ganz so schön poliert wie kommerzielle Clients, hat auch die eine oder andere Macke (das Laden der Raumliste von matrix.org dauert teilweise Ewigkeiten), aber: Es ist gut nutzbar, man ist unabhängig von kommerziellen Anbietern/single points of failure.

Mark Nowiasz

Mon, 28 Jan 2019 12:00:11 +0100

Und gerade ausprobiert: via https://riot.im/app/ kann man auch ohne direkt zu registrieren mal ein wenig herumspielen und auch auf besagten Channel zugreifen.

Farlion

Mon, 28 Jan 2019 12:13:05 +0100

Schau ich mir demnächst mal an. Ich bin gerade zu beschäftigt, meine alten Projekte wieder hochzufahren und aufzufrischen. :)

RockyIII

Mon, 28 Jan 2019 12:50:33 +0100

Hi Markus
Audi-/Videochat auf dem Server selbst funktionieren tadellos.

hast du irgenwo was ofizilles zur Hardwareanforderungen für Audi-/Videochat bei synapse gefunden?

Mark Nowiasz

Mon, 28 Jan 2019 12:55:15 +0100

Keine Ahnung, die dürften aber nicht so hoch sein, weil synapse ja meines Wissens nach nicht codiert/umkodiert, sondern einfach die entsprechenden Ströme verwaltet, die Kodierung/Dekodierung entsteht ja bei den Clients, ich habe auch nirgendwo eine Einstellung für evtl. Transkodierungen gefunden. Das könnte eher eine Frage der Anbindung/Bandbreite sein.

RockyIII

Mon, 28 Jan 2019 14:01:12 +0100

Das könnte eher eine Frage der Anbindung/Bandbreite sein.

ja - so wird es wohl sein DANKE

Test eine Änderung/Experimental changes

Mark Nowiasz

Thu, 24 Jan 2019 10:59:52 +0100

!!Diskussionen & Ankündigungen dieses Hubs

Hi,
morgen früh werde ich - nachdem es problemlos auf meinem Testhub funktioniert hat - eine (eigene) experimentelle Änderung im Hubzillacode auch auf diesem Hub einspielen. Diese wird - so vermute ich es - Hubzilla noch mehr beschleunigen (wobeies nach der Umstellung auf DB-Server mit SSD schon massiv besser geworden ist, Geschwindigkeit kann man nie genug haben

). Es sollte(!) keine Auswirkungen haben (neben potentiellen Geschwindkeitsgewinn), allerdings ist es möglich dass ihr nach der Umstellung ausgeloggt seit und Euch noch mal einloggen müsst. Das ist aber auch alles.

Wenn diese Änderung funktioniert werde ich einen Arikel darüber schreiben und die - minimalen - Codeänderung offiziell einreichen.

Sollte nach der Änderung Probleme auftreten, bitte hier kommentieren.

deutsch englisch

mehr anzeigen 37 Kommentare

Mark Nowiasz

Fri, 25 Jan 2019 07:39:37 +0100

Erledigt, wie erwartet musste ich mich auch neu anmelden

Sonst scheint alles zu funktionieren, mal gucken ob das was gebracht hat, das wird sich anhand der Zabbix-Graphen in den nächsten Stunden zeigen.

Mark Nowiasz

Fri, 25 Jan 2019 08:50:04 +0100

Gibt es bei Euch negative Auswirkungen (von der Tatsache abgesehen dass Ihr Euch auf allen Clients neu anmelden musstet)? In meinem Fall zeigte Nomad - der Androidclient - seltsame Effekte, ich musste mich ständig neu einloggen und wurde mit einem Fehler wieder 'rausgeworfen, nach einem Löschen des Caches und der Daten von Nomad stürzte Nomad bei EIngabe der Daten für den Hub permanent ab. Das muss nichts zu bedeuten haben, letzteren Bug (Dauerabsturz) hatte ich vorher auch schon gehabt, war ein Wunder dass Nomad so lange funktioniert hat

Wie sieht es bei Euch aus? Und wie kommt Euch nun generell die Geschwindkeit des Hubs vor?

Alexander Goeres

Fri, 25 Jan 2019 10:15:56 +0100

die geschwindigkeit hat sich deutlich verbessert, allerdings schon seit deiner ssd-spende für die db. bei deiner letzten änderung ist es noch einen tick besser geworden, könnte aber auch einbildung meinerseits sein. über nomad kann ich nichts sagen, da der bei mir noch nie richtig funktioniert hat und ich den infolgedessen nicht benutze.

Mark Nowiasz

Fri, 25 Jan 2019 10:21:36 +0100 zuletzt bearbeitet: Fri, 25 Jan 2019 10:23:08 +0100

Sehr schön

Bislang sagen die Daten/Graphen ähnliches, wobei die SSD die Änderung ein verdeckt. Vermutlich bewirkt die Änderung eine Verzehnfachung (mindestens) der Datenbankgeschwindigkeit, eher mehr - das wird aber durch die schnelle SSD-DB nicht ganz sichtbar. Ich warte nun noch ein wenig dann schreibe ich/veröffentliche einen Artikel dazu. Ist nur ein kleiner Patch, den reiche ich dann auch mal ein. Ganz ohne falsche Bescheidenheit: Vermutlich habe ich nun den schnellsten Hub im Fediverse

Hanno Gardemann hz

Fri, 25 Jan 2019 23:05:19 +0100

Also ich kann über die Geschwindigkeit wirklich nicht meckern, bin aber auch eher der geduldige Typ.
Müsste mal mit meinem noch immer unfertigen Standardhub bei den Serverprofis vergleichen.
Via Nomad komme ich gerade nicht auf Deinen Hub.

Mark Nowiasz

Fri, 25 Jan 2019 23:13:35 +0100

@Hanno (Wowbagger) Gardemann Nomad scheint ein Glücksspiel zu sein. Bei mir hat Nomad eine Zeit nicht funktioniert, danach ging es plötzlich gut, und nun wieder nicht mit den gleichen Symptomen wie vorher: Nach dem Eingeben der Hubabdresse schmiert Nomad sofort ab, und danach eine Schleife Start und sofortiger Absturz. Bei anderen Leuten hat Nomad noch nie funktioniert, bei @Marcus Wißmann dagegen problemlos 🤷‍♂️

Das hat auch nichts mit der Änderung zu tun die ich durchgeführt habe: Ich habe diese auf meinem Testhub rückgängig gemacht, dennoch funktioniert Nomad da nicht.

Hanno Gardemann hz

Fri, 25 Jan 2019 23:22:41 +0100 zuletzt bearbeitet: Fri, 25 Jan 2019 23:23:47 +0100

@Mark Nowiasz
Nomad verweigert jetzt auch bei mir (AndroidOne, Android 9.0) die Zusammenarbeit mit der Meldung "Berechtigung verweigert".

Mark Nowiasz

Fri, 25 Jan 2019 23:28:14 +0100

@Hanno (Wowbagger) Gardemann Hatte ich auch direkt nach der Umstellung der Sessions gehabt (klar, logisch, war zu erwarten - die Session/der Cookie, in dem die SessionID gespeichert war, wurde ja ungültig). Danach habe ich versucht das Problem zu beheben in dem ich den Cache und die Daten der App gelöscht habe, danach taten dann die altbekannten Symptome auf: Dauercrash.

Das ist aber nicht so schlimm, weil Nomad nichts anderes als ein Browser gemacht hat. Deshalb habe ich nun als Workaround die Startseite des Hubs auf den Androidstartbildschirm gelegt, so dass praktisch kein Unterschied zu Nomad (außer dass man sich nun ab und zu einloggen muss) besteht.

Hanno Gardemann hz

Sat, 26 Jan 2019 00:13:36 +0100

Ich hab Nomad mal deinstalliert und neu installiert.
Jetzt finde ich Deinen Hub nicht mehr in der Liste!
Derzeit bin ich mit Smartphone und Firefox hier.
Das geht problemlos @Mark Nowiasz .

Mark Nowiasz

Sat, 26 Jan 2019 00:23:34 +0100 zuletzt bearbeitet: Sat, 26 Jan 2019 00:24:39 +0100

@Hanno (Wowbagger) Gardemann Die Daten des Hubs muss man manuell in Nomad eingeben, ich weiß gar nicht was das für eine Liste ist, die Nomad da mitbringt - sonderlich gepflegt sieht sie nicht aus. Defacto gibt es kaum einen Unterschied zwischen Nomad und mobilem Browser, der Hauptunterschied ist dass Nomad permanent läuft und damit ein Ausloggen durch Löschen des Cookies, was eine Laufzeit von 0 hat, vermeidet, während der Browser das Cookie beim Beenden (und sei es durch Android) löscht und damit ausgeloggt ist. Sprich: im Browser muss man häufiger einloggen, bei Nomad reichte ein mal alle Jubeljahre aus

Hanno Gardemann hz

Sat, 26 Jan 2019 00:30:22 +0100

((-: Nicht bei mir.
Ich bin berüchtigter HintergrundAppKiller.

Olaf Wendt (Hz)

Sat, 26 Jan 2019 10:45:37 +0100 zuletzt bearbeitet: Sat, 26 Jan 2019 10:46:16 +0100

Oh, diesen Thread habe ich gerade erst gesehen, kurz zuvor beim anderen Beitrag kommentiert, siehe dort.

Kurze Zusammenfassung auf Deutsch: Am Desktop werde/wurde ich ständig rausgeschmissen. Mein üblicher Weg, zuerst via /notifications bei Hz einzusteigen, ist verbaut, weil die Authentifizierung fehlschlägt. Finde ich einen Link und lese dessen Artikel auf einer anderen Website, konnten bislang wenige Minuten "Abwesenheit" schon ausreichen, dass der Timeout wieder zuschlägt. Folge: Startseite aufrufen und über den Stream wieder zu der Stelle klicken, die ich vorher noch auf dem Bildschirm hatte - mehrere Seitenaufrufe, und nicht gerade toll, wenn man auf einen mobilen Hotspot mit begrenzter Flatrate angewiesen ist.

Für die Hub-interne, weiterführende Diskussion würde ich gerne hier weitermachen, auf Deutsch tippe ich auch ein bisschen schneller. Nach einer weiteren Optimierung durch @Mark ist eh erst mal Warten und Testen angesagt. Und vielleicht ein bisschen Daumen drücken

Hanno Gardemann hz

Sat, 26 Jan 2019 11:04:22 +0100

@Olaf Wendt (Hz)
Ich habs nicht ganz verstanden. Du gehst am Desktop via Nomad zu Hubzilla? Nee, kann doch nicht sein.
Du wirst also rausgeschmissen, wenn Du via Browser zu Hubzilla gehst?
Das ist mir erinnerlich noch nie passiert.
Mark und ich haben Probleme mit Nomad,
Per Browser ist bei mir alles paletti. Egal ob auf dem Smartphone (Android 9.0), dem Tablet (Android 7.1) oder dem Desktop/Laptop via W10 oder Fedora mit Chromium, Chrome oder Firefox.

Olaf Wendt (Hz)

Sat, 26 Jan 2019 11:14:53 +0100

@Hanno (Wowbagger) Gardemann Am Desktop ja, via Nomad nein.

Auf die App verzichte ich schon seit einiger Zeit, die mobile Seite reicht mir.

Win 10 mit Opera 57. Mark ist ja mit Mini Patches an der Problembeseitigung dran, vielleicht löst sich bald alles in Wohlgefallen auf.

Mark Nowiasz

Sat, 26 Jan 2019 11:39:56 +0100

Ich versuche das mal zu erklären

Wenn ich so technisch - oder zu laienhaft - erkläre, möge man mir das bitte nachsehen

HTTP(s) ist ein zustandsloses Protokoll. Vereinfacht gesagt, für den Server macht es keinen Unterschied ob ich von Seite A zu Seite B wechsle oder Seite B direkt aufrufe - bei jedem Seitenwechsel wird ein komplett neuer Kontext aufgebaut, alle Variablen des Skripts sind leer usw usf. Um das Problem zu umgehen (sonst müsste man sich jederzeit neu einloggen) gibt es besagte Session. Dort werden Daten gespeichert (z.B. ob man eingeloggt ist, wie die IP war/ist, auf welcher Seite man gerade ist, welchen Kommentar man gerade schreibt, usw. usf.).

Diese Session werden (müssen alleine aus Sicherheitsgründen) auf dem Server gespeichert, vorher Datenbank, jetzt Dateien. Auf der Clientseite wird ein Cookie gesetzt mit einer SessionID, anhand dererer kann dann PHP die Sessiondaten wieder abrufen (ist der User eingeloggt? Wo kam er her? Welche Spracheinstellung? usw.).

Nun müssen diese Sessiondaten natürlich irgendwann gelöscht werden, weil die wenigstens Sessions werden sauber beendet (Ausloggen, was auch immer) und im Laufe der Zeit sammeln sich so mehr und mehr alte Sessiondaten an. Dafür gibt es den Garbage Collector in PHP - dieser räumt alte Sessiondaten weg. Getuned wird er (u.a.) durch zwei Einstellungen (gc_probability und gc_divisor), die Division beider Werte ergibt die Wahrscheinlichtkeit wann er zuschlägt: Default in PHP (und nun bei mir) ist 1 und 100, sprich: 1% Chance. Hubzilla allerdings hat 50/100 eingestellt gehabt, sprich: 50/50 Chance dass er aktiv wurde und eigentlich hätte das gleiche wie bei @Olaf Wendt (Hz) passieren müssen: Häufiges ausloggen. Die Hubzilla-Entwickler haben das umgangen, in dem sie in ihrem Datenbank-Sessionhandler Session ein zusätzliches Feld ("Expires") hinzugefügt haben - es wurden nur Session gelöscht, die älter als das Expire-Datum waren, egal wie oft der Garbage Collector lief.

Ich habe das nun so geändert, dass statt 50/50 1/100 (PHP default) als Wahrscheinlichkeit gesetzt wird, damit sollte das Problem gemildert sein.

Hanno Gardemann hz

Sat, 26 Jan 2019 12:19:35 +0100

Nicht, dass es wichtig wäre aber warum bin ich noch nie im Browser rausgeflogen?
Weil ich brav bin und mich immer überall da, wo ich mich einlogge, dann auch wieder auslogge?

Olaf Wendt (Hz)

Sat, 26 Jan 2019 12:38:42 +0100

Wenn Deine Session Cookies beim Ausloggen gelöscht werden und Server respektive Datenbank oder /tmp Speicher dadurch kein "Material" zum Bereinigen haben, wäre das eine logische Erklärung, wenigstens eine, die mir als Datenbank-n00b einleuchten würde.

Olaf Wendt (Hz)

Sat, 26 Jan 2019 14:40:13 +0100

Okay, also 2-3 Stunden später ist noch keine wirkliche Besserung in Sicht. Ich habe mir die Cookie-Info in Opera mal angeschaut: Das Cookie PHPSESSID

soll Gültigkeit haben "Ende der Browsersitzung" (passt eigentlich)
kommt von der Domain hub.netzgemeinde.eu (passt)
Pfadangabe ist "/" (passt das? Würde ich auch "/tmp" sehen, sehen dürfen?)

In der Praxis habe ich vorhin ein paar Minuten an einem Kommentar geschrieben, für den ich mehrere Links in anderen Tabs zusammensuchen bzw. recherchieren musste, auch auf einer anderen Hubzilla-Seite in separatem Tab. Ich flog während des Editierens 1x deswegen und 1x beim Aktivieren des Vorschaubuttons aus der Sitzung. Sicherheitshalber hatte ich ständig eine Kopie des Inhalts in der Zwischenablage. Ein drittes Mal wurde ich abgemeldet, als ich den Kommentar gepostet hatte und anschließend auf den Browser-Button "zurück im Verlauf" klickte.

Mark Nowiasz

Sat, 26 Jan 2019 15:02:54 +0100

Das ist alles sehr seltsam, Du bist der einzige mit solchen Problemen. Ich selbst z.B. bin seit heute morgen eingeloggt und nicht einmal 'rausgeworfen worden. Hast Du evlt. irgendein ominöses Browserplugin oder Cookie-Einstellungen die da zwischenfunken?

Die Cookie-Daten sind korrekt so, Pfad auch (der bezeichnet Webpfad, nicht den Dateipfad, man kann mehrere Cookies haben, einen für /, einen /app.. was auch immer).

Hast Du schon mal versucht alle Browserdaten (ganz speziell Cookies) und den Cache zu löschen? Ich kenne ansonsten solche seltsamen Probleme nur wenn das Profil irgendwie kaputt ist..

Mark Nowiasz

Sat, 26 Jan 2019 15:10:01 +0100

Ich habe mal die Sessions im /tmp durchgeschaut - es gibt 5 Sessions mit "one2hire" im Inhalt (neben anderen Daten), sprich: Das neue Sessionhandling kann es eigentlich nicht sein, die Sessiondaten existieren ja noch auf der Platte.

Kann es sein dass die verschiedenen Tabs verschiedene Sessions haben und dadurch das Durcheinander entsteht?

Alexander Goeres

Sat, 26 Jan 2019 15:16:40 +0100

es kann auch nicht generell ein problem mit dem session-handling sein. ich habe zb. überhaupt keine probleme wie @Olaf Wendt (Hz) ... ein generelles problem, müssten doch eigentlich bei allen auffallen ...

Olaf Wendt (Hz)

Sat, 26 Jan 2019 15:19:02 +0100

Uno momento, ich hab da so 'ne Idee.

Die Hubzilla-Entwickler haben das umgangen, in dem sie in ihrem Datenbank-Sessionhandler Session ein zusätzliches Feld ("Expires") hinzugefügt haben - es wurden nur Session gelöscht, die älter als das Expire-Datum waren, egal wie oft der Garbage Collector lief.

Was genau liefert denn dieses "Expires" Feld an den Handler aus: "NULL" oder ein Integer, vermutlich "0", denn ...

Das Cookie PHPSESSID [...] soll Gültigkeit haben "Ende der Browsersitzung"

Im Falle von "0" wäre jedes Datum, mit dem der Garbage Collector vergleicht, aktueller als der im Cookie verankerte Wert, nicht nur das heutige. Folge: Das Cookie wird immer als Müll entsorgt. Bei "NULL" weiß ich nicht, ob es genauso zutrifft. Eigentlich müsste es ein Integer sein, damit PHP damit rechnen kann.

Workaround 1: Jedem Session Cookie ein Datum mitgeben, z.B. heute() +14 Tage (.googlecontent.com -Cookies wären z.B. bis mindestens Ende April gültig, wenn ich sie nicht blockiert hätte).

Workaround 2: Eine Bedingung so ähnlich wie wenn "Expire" gleich "0" [/NULL], dann Exit, sonst Vergleich mit tatsächlichem Datum

Falls meine rudimentären Programmier-Fantasien allzu realitätsfremd sind, hoffe ich wenigstens, dass ich Euch zum Lachen bringen konnte.

Mark Nowiasz

Sat, 26 Jan 2019 15:20:39 +0100

Das einzige was vielleicht auch noch möglich wäre: Ständig wechselnde IPs, wie bei DS-Lite. DS-Lite sollte aber kein Problem darstellen sofern V6 aktiv ist - meine Server sind alle per IpV6 erreichbar.

Mark Nowiasz

Sat, 26 Jan 2019 15:25:20 +0100

@Olaf Wendt (Hz) Das sind zwei verschiedene Dinge

Klar könnte man dem Cookie eine lange Expire-Zeit mitgeben, würde aber nichts bringen wenn der Browser das Cookie lange speichert, aber auf Serverseite die Sessions durch den Garbage-Collector entsorgt wurden. Jetzt ist die Frage wo das Problem genau liegt - auf Serverseite oder auf Clientseite? Ich würde mittlerweile zu Client tendieren..

Olaf Wendt (Hz)

Sat, 26 Jan 2019 15:25:44 +0100

Okay, das war Cross-Posting vom feinsten. Hier meine Cookie-Einstellungen:

Websites dürfen Cookiedaten speichern und lesen (empfohlen) - JA
Lokale Daten nach Schließen des Browsers löschen - NEIN
Drittanbieter-Cookies blockieren - JA

Es werden keine Cookies auf URL-Basis blockiert, bei "nach Beenden löschen" ist keine Eintragung und auch sonst ist alles recht geschmeidig.

An der Konfiguration von Hubzilla habe ich nichts geschraubt, hätte als Nutzer eh wenige Eingriffsmöglichkeiten. Ich habe das Problem auch bei keiner anderen Seite, und hier auf hub.netzgemeinde.eu definitiv erst seit der Umstellung des Cookie-Handlings.

Eine recht teuer erkaufte Performance-Steigerung, wenn man bedenkt, wieviele Leute wieviel Zeit damit schon verbraten..?

Olaf Wendt (Hz)

Sat, 26 Jan 2019 15:28:28 +0100

Ich habe seit Tagen sehr stabile IP's. Ich weiß das, weil ich gerade an einem Projekt arbeite, wo mich die Baustelle nur mit einer IP vorbei lässt, die in der .htaccess steht, bin also definitiv ständig auf ip-lookup.net

Mark Nowiasz

Sat, 26 Jan 2019 15:37:29 +0100

OK, testweise stelle ich mal wieder auf DB um, das wird dazu führen dass Ihr Euch alle wieder neu einloggen musst. Wenn das Problem nun weiter auftritt dann sollte klar sein, dass es nicht an den Sessions liegt.

Hanno Gardemann hz

Sat, 26 Jan 2019 15:42:26 +0100

Also ich lasse alle meine Browser alle aufgesammelten Daten beim Beenden löschen und Cookies nur von besuchten Seiten zu. Sie werden aber wie gesagt beim Beenden gelöscht.
Das nur nebenbei.
Könntest Du eventuell Dein Profil mal zu nem anderen Hub umziehen und dann testen @Olaf Wendt (Hz) oder ist das zu abwegig?

Mark Nowiasz

Sat, 26 Jan 2019 16:09:10 +0100

Gibt es denn nun Änderungen zu vorher, @Olaf Wendt (Hz)?

Olaf Wendt (Hz)

Sat, 26 Jan 2019 16:42:47 +0100

@all Okay, ich bekomme hier langsam ein Zeitproblem. Gut möglich, dass ich deshalb etwas angespannter formuliert habe als der Sache dienlich ist. Sorry dafür. Jetzt geht's wieder.

Ich bin mit dem Opera Browser unterwegs, insofern ein "bunter Hund". Der basiert aber wie Chrome auf der Blink Engine, daher glaube ich, dass hiervon kaum Probleme herrühren.

Allerdings: Wie an anderer Stelle schon besprochen, habe ich (und da bin ich definitiv der einzige) ein Problem mit main.js, meine Channel-Seite braucht ca. 3 Minuten zum Laden. Danke @Mark Nowiasz und @Hanno (Wowbagger) Gardemann für die Unterstützung in diesem Bereich. Dieser Problematik müsste ich auch mal auf den Grund gehen, das schaffe ich am WoE aber nicht mehr. Nicht auszuschließen, dass es hier Querverbindungen gibt.

@Alexander Goeres Ich suche auch immer erst nach Ursachen, die bei mir liegen könnten.

Nachdem nun mehrere Leute meinen, dass ich der einzige mit diesen Problemen bin, habe ich folgendes getan:

Opera: Alle Browserdaten gelöscht.
Opera: Updates geprüft - keine ausstehend
Chrome: Alle Browserdaten gelöscht
Chrome ist auch aktuell

Durch die neueste Umstellung von Dir, @Mark Nowiasz , musste ich mich gerade neu einloggen, das ist völlig logisch.

Stresstest 1 folgte: Neben diesem Beitrag sah ich noch eine weitere Benachrichtigung. Diesen Beitrag habe ich in einem weiteren Tab geöffnet, ein Like vergeben und wieder geschlossen. Anschließend hier begonnen zu kommentieren. --> Bislang keine Probleme.

Stresstest 2: Copy&Paste dieser Zeilen, Reload der Artikelseite. ... Aha, interessant, ich kam auf der eben erwähnten, anderen Artikelseite raus, aber ich wurde nicht ausgeloggt. Das ist eine Verbesserung.

Diese Verbesserungen können nun aber an drei Dingen liegen: Am Zurückziehen des Patches, am Neustart des bereinigten Opera Browsers oder am Neustart von Windows (man weiß ja nie).

Mein Plan:

Weiter gucken, aber nicht mehr so intensiv wie zuletzt; geht leider zeitlich nicht.
Wenn es mit Opera nicht hinhaut, dann steige ich auf einen bereinigten Chrome Browser um.
Auf beiden browsern testen, warum meine Channel-Seite hub.netzgemeinde.eu/channel/one2hire immer drei Minuten (2+1) zum Laden braucht, egal auf welchem der 4 getesteten Browser, inkl. FF und Edge.
Dieses Problem möglichst lösen

@Hanno (Wowbagger) Gardemann Sobald ich diese Listen abgearbeitet habe, dürfte sich ein Umzug wahrscheinlich erübrigen.

Nochmal danke @Mark Nowiasz fürs Engagement, mir macht's normalerweise einen Heiden Spaß, solche Sachen auszuknobeln. Das Timing kann man sich halt manchmal nicht aussuchen, und da muss ich leider für den Rest des WoE passen. Ich werde mich schnellstmöglich an die o.g. Hausaufgaben machen.

Olaf Wendt (Hz)

Sat, 26 Jan 2019 16:46:31 +0100

Nachtrag: Aktuelle Session ID lautet 7kf4o7jtqdjcuruj4ek0osvdn7

Das ist definitiv eine andere als zu Beginn meines letzten Kommentars vor ein paar Minuten. Leider habe ich diese nicht auch kopiert und oben reingeschrieben. Ich habe mich zwischenzeitlich weder ausgeloggt noch wurde ich rausgeworfen..?

Mark Nowiasz

Sat, 26 Jan 2019 16:52:39 +0100 zuletzt bearbeitet: Sat, 26 Jan 2019 17:02:37 +0100

@Olaf Wendt (Hz) Dann liegt es an Deinem Browser - BTW, ich dachte DU wärst per Desktop unterwegs?
Laut Session Data kommst Du von (gelöscht) und benutzt/bekommst das mobile_theme theme|s:19:"redbasic:Focus-Boxy";mobile_theme.

Irgendwas macht Dein Browser oder Javascript massiv falsch. Anscheinend bekommst Du ständig eine neue Session, was die Probleme erklärt - und wieso Du ein mobiles Thema bekommst, ist mir auch unklar... die Session-Daten entsprachen auch denen der vorigen File-Sessiondaten.

Olaf Wendt (Hz)

Sat, 26 Jan 2019 17:01:38 +0100 zuletzt bearbeitet: Sat, 26 Jan 2019 17:47:18 +0100

Das stimmt, ich nutze Vodafone als Hotspot - daher werden Reloads zum Kostenfaktor. (Kannst Du bitte diese IP bitte gleich noch rauseditieren)?

Mein Hubzilla sieht wie folgt aus, es wäre schon möglich, dass ich wegen des Vodafone-Zugangs auf mobile umgeschaltet werde. Andere Oberflächen kenne ich gar nicht, weil ich immer schon so eingeloggt war. Ich kann aber versichern, dass ich an zwei Bildschirmen arbeite.

[Bild wieder gelöscht]

Mark Nowiasz

Sat, 26 Jan 2019 17:08:54 +0100

OK, gelöscht. Mobile Theme war meine Fehler, ist 0. Soweit so gut, dennoch - wenn Du ständig neue Sessions generierst - sieht das tatsächlich nach einem Problem des Browsers aus... oder (wie gesagt) DS-Lite, wo sich mehrere Leute die selbe IP teilen. OK, an dem Sessionhandler liegt es offensichtlich nicht.

Olaf Wendt (Hz)

Sat, 26 Jan 2019 17:25:27 +0100

Okay, danke @Mark Nowiasz

Momentan (17:19 - 17:24) läuft es wirklich top stabil, die Session ID hat sogar zwei Neustarts des Browsers (ohne voriges Log-out, logisch) überlebt und lautet immer noch 7kf... Wenn ich es mir aussuchen dürfte, würde ich es gerne so lassen

Aber gut, wenn mein Hotspot das Problem ist, muss ich eh darüber nachdenken, wie und welche Plattform ich künftig verwende(n kann), da kann sich ein Hubmin/Podmin noch so die Beine ausreißen.

Mark Nowiasz

Sat, 26 Jan 2019 17:31:22 +0100

OK, dann schalte ich mal wieder um auf FIles als Sessionhandler.. wie immer Leute, ihr müsst Euch wieder ein-/ausloggen. Irgendwas ist halt mit Deinem Channel merkwürdig, auch die Ladezeit von 2-3 Minuten..

Olaf Wendt (Hz)

Sat, 26 Jan 2019 17:51:12 +0100

Öhm, ja. An den Channel gehe ich kommende Woche dran, Hubzilla-Apps an- und ausknipsen. Das wird spannend.

So, gleich noch meinen eigenen Fail beseitigt: Erst motz' ich, dass die IP im Kommentar steht, dann poste ich ein Bild damit: [gelöscht]. Oh man...! 😆 Schönen Feierabend Euch allen

Maintenance done/Wartung abgeschlossen

Mark Nowiasz

Tue, 22 Jan 2019 09:12:11 +0100

!!Diskussionen & Ankündigungen dieses Hubs

Hi,
die Wartung/der Datenbankumzug ist abgeschlossen, funktioniert soweit alles wieder

Es gibt eine - minimale - Änderung: Ich habe nun (wie auf den meisten anderen Hubs auch) die Einstellung:

Setze den Zeitraum (in Tagen), ab wann importierte (aus dem Netzwerk) Inhalte ablaufen sollen

aktiviert und auf 90 Tage gesetzt. Das betrifft ausschließlich externe Inhalte in den jeweiligen Streams, nicht die eigenen Inhalte - ein 3 Monate zurückliegender Stream sollte reichen

, und auch das betrifft nur Inhalte die in den letzten 7 Tagen nicht kommentiert wurde. Die Datenbank ist mittlerweile über 10 GB groß und auf dem neuen DB-Server ist nicht so viel Platz, das sollte aber vermutlich niemanden tangieren/auffallen.

deutsch englisch

mehr anzeigen 4 Kommentare

Mark Nowiasz

Tue, 22 Jan 2019 09:24:54 +0100

Seit 13. Oktober ist das Teil öffentlich - und 69 Konten/Kanäle, wovon natürlich nicht alle aktiv sind, aber dennoch Content erhalten.

10 GB finde ich jetzt nicht sooo viel, das liegt aber auch an meiner speziellen Sichtweise

Ich bin teilweise Datenbanken zwischen 50GB und 10TB (letztere natürlich eine massive Ausnahme) gewohnt, so 100GB+ ist nicht ungewöhnliches für mich

Alexander Goeres

Tue, 22 Jan 2019 09:43:12 +0100

klar gibt es größere, aber ich habe schon echt schlechte erfahrungen mit mysql-dbs über 10G gemacht. ist allerdings eine weile her ...

Mark Nowiasz

Tue, 22 Jan 2019 09:48:37 +0100

Och, das geht, wenn man ein paar Dinge beachtet - u.A. wenn irgendwie möglich innodb im RAM (innodb_buffer_pool_size = DB größe), klar, irgendwann wird es hier auch schwierig (so ab 96 GB Ram z.B.), und natürlich wenn möglich (wie nun geschehen) auf SSD.

BTW, gefühlt reagiert der Hub nun schneller, das wird sich aber im Laufe der Zeit zeigen ob das Gefühl trügt

Maintenance / Wartung & Unicode problems

Mark Nowiasz

Sun, 20 Jan 2019 23:11:59 +0100

!!Diskussionen & Ankündigungen dieses Hubs

Hi all,
zwei Sachen:

1. Wartung am Dienstag, 22.01.2019 (ab 7:30)

Ich habe festgestellt dass dieser Hub teilweise langsam wurde bis zu Verbindungsabbrüchen. Nicht immer, aber immer häufiger. Als Ursache habe ich die Datenbank ausgemacht. CPU und RAM ist der Server mehr als gut ausgestattet, allerdings liegt das Dateisystem auf einem herkömmlichen SAS-Raid (sprich: rotierende Platten), und dieses bildet nun den Flaschenhals - die MySQL kann nicht so schnell schreiben/lesen wie sie könnte, was zu besagten Verzögerungen führt. Deshalb habe ich einen weiteren Server (noch nicht vollständig) aufgesetzt, der nur als Datenbankserver fungieren wird und der eine SSD hat. Dadurch glaube ich die Probleme gelöst zu haben, und vermutlich habe ich dann (etwas unfreiwillig) den schnellsten Hub im Feidverse

Die Umstellung erfordert allerdings eine gewisse Downtime, schwer zu sagen wie lange, ich gehe mal von 7:30 bis 10:00 aus, sprich: wenn der Hub nicht erreichbar ist in der Zeit ist alles OK, dann stelle ich gerade um

2. Probleme mit Unicode

Es ist vorgekommen dass (externe) Kommentare/Postings nicht angekommen sind. Dies war dann der Fall wenn diese bestimmte Unicodezeichen, insbesondere emojis enthielten. Das Problem ist nun identifiziert und ein Workaround gefunden, so dass es in Zukunft nicht mehr auftreten dürfte.

deutsch englisch

mehr anzeigen 4 Kommentare

Alexander Goeres

Mon, 21 Jan 2019 13:28:08 +0100

danke für die warnung!

Olaf Wendt (Hz)

Mon, 21 Jan 2019 14:25:25 +0100

Ja, Hanno hat recht, diesem Dank kann ich mich nur anschließen. netzgemeinde.eu ist ein gutes Social Home!

Hanno Gardemann hz

Tue, 22 Jan 2019 17:32:58 +0100

Ein viel besseres als mein eigener Hub zum Beispiel!
Ich hab z. B. zwar Zugang via Bash aber Angst, etwas an den Rechten zu ändern und bekomme die Addons nicht installiert (Permission denied).
((-;
Bin zu schissig für den Job!

Update: 3.8.8

Diskussionen & Ankündigungen dieses Hubs

Sun, 23 Dec 2018 11:02:20 +0100

Der Hub wurde auf 3.8.8 aktualisiert. Sollte alles wie gewohnt laufen

Update: 3.8.7.

Diskussionen & Ankündigungen dieses Hubs

Sat, 15 Dec 2018 10:16:55 +0100

Der Hub wurde auf 3.8.7 upgedated. Sollte alles wie gewohnt laufen

Update to 3.8.6

Diskussionen & Ankündigungen dieses Hubs

Mon, 03 Dec 2018 12:41:13 +0100 zuletzt bearbeitet: Mon, 03 Dec 2018 12:48:17 +0100

Der Hub wurde nun auf Version 3.8.6. upgedatet, sollte sauber funktionieren

Serverreboot

Diskussionen & Ankündigungen dieses Hubs

Mon, 03 Dec 2018 10:19:40 +0100

Morgen (4.12.) in der Zeit zwischen 7h und 8h werde ich den Server wegen Kernelupdates neustarten. Im Idealfall bekommt man davon nichts mit, weil der Reboot in der Regel unter einer Minute erledigt ist

Diskussionen & Ankündigungen dieses Hubs

Tue, 04 Dec 2018 06:12:30 +0100

Done

Update to 3.8.5

Diskussionen & Ankündigungen dieses Hubs

Mon, 19 Nov 2018 11:57:27 +0100

Der Hub wurde erfolgreich auf 3.8.5. aktualisiert. Alles gut, keine Probleme

Update to 3.8.4

Diskussionen & Ankündigungen dieses Hubs

Wed, 14 Nov 2018 11:51:16 +0100

Der Hub wurde erfolgreich auf 3.8.4 aktualisiert, ein Grund war eine Sicherheitsproblem. Update lief problemlos, sollte alles wieder funktionieren

Update to 3.8.3

Diskussionen & Ankündigungen dieses Hubs

Mon, 05 Nov 2018 10:52:09 +0100

Der Hub wurde erfolgreich auf 3.8.3 aktualisiert. Sollte alles wieder sauber laufen

Wartung/Maintence, server reboot

Diskussionen & Ankündigungen dieses Hubs

Mon, 05 Nov 2018 08:32:32 +0100

Durch einige Updates (inklusive Kernel) wird der Server, auf dem Hubzilla läuft, neugestartet. Sollte keine großartigen Auswirkungen haben, nur 1-2 Minuten (wenn überhaupt) Downtime

Diskussionen & Ankündigungen dieses Hubs

Mon, 05 Nov 2018 08:46:49 +0100

Done, all is well

Update to 3.8.2.

Diskussionen & Ankündigungen dieses Hubs

Mon, 29 Oct 2018 15:33:07 +0100

Der Hub wurde erfolgreich auf Version 3.8.2. aktualisiert. Neben Bugfixes sollte sich nichts geändert haben

Update to 3.8.1.

Diskussionen & Ankündigungen dieses Hubs

Sun, 21 Oct 2018 09:55:06 +0200

Der Hub wurde erfolgreich Version auf 3.8.1. aktualisiert, welches auch ein Sicherheitsupdate beinhaltete. Sonst hat sich nichts geändert außer Bugfixes und dem besagten Sicherheitsupdate