Hi auch;
Am 10.04.19 um 17:54 schrieb Konrad Rosenbaum:
a) Du hast genug Druckmittel gegenüber den Programmierern - aber auf der
Negativseite hast Du dann auch eine große Fluktuation. Zumindest wenn der Rest
der Arbeitsumgebung nicht absolut phantastisch ist.
b) Du hast hinreichende Mengen
Hallo,
wenn du Logs anders konsumieren willst, dann wirf mal einen Blick auf Kibana.
Da kannst du sie grafisch visualisieren wie immer du magst.
Das ist unabhängig von der Logspeicherung. Die kannst du nach wie vor als
Logdatei vorliegen haben, in einer DB mit "richtigen" records oder wofür
Am Mittwoch, 10. April 2019, 09:54:55 CEST schrieb Thomas Güttler:
> ich habe irgendwie keinen Bock mehr auf "Logging to file".
>
> Mag sein, dass das Unix-Konzept die letzten hundert Jahr gut funktioniert hat,
> aber zB Apache Logs zeilenweise in eine Datei zu schreiben hat deutlich
> Nachteile.
Hi,
On Wednesday, 10 April 2019 13:40:39 CEST Kristian Rink wrote:
> Am 10.04.19 um 13:15 schrieb Konrad Rosenbaum:
> > Bei b) kannst Du entweder eine ganz einfache Lösung oder keine Lösung
> > bekommen. Je schwieriger es ist ein Log zu schreiben umso
> > unwahrscheinlicher ist es dass Du ein Log
Hallo Konrad, *;
Du hast an einigen Punkten durchaus recht, nur zwei kurze Einwürfe:
Am 10.04.19 um 13:15 schrieb Konrad Rosenbaum:
Bei b) kannst Du entweder eine ganz einfache Lösung oder keine Lösung
bekommen. Je schwieriger es ist ein Log zu schreiben umso unwahrscheinlicher
ist es dass
Hi,
ich spiele mal Advokat für den netten Herrn mit Dreizack im roten Jacket...
On Wednesday, 10 April 2019 09:54:55 CEST Thomas Güttler wrote:
> ich habe irgendwie keinen Bock mehr auf "Logging to file".
Wer hat schon Bock auf Log.
Zeilenweise schreiben ist für uns Programmierer aber nun mal
Hi Thomas,
wie sehen denn Anforderungen und Umgebung aus? Grundsätzlich:
Am 10.04.19 um 09:54 schrieb Thomas Güttler:
Frage 1: Könnt ihr die Aussage (Keinen Bock mehr auf "Logging to file")
nachvollziehen?
Jein. "Logging to file" ist für mich eigentlich nur
Implementationsfrage.
> $ tracepath
>
> Das sollte natuerlich auf einem Client im LAB gemacht werden, weil
> bei den Clients im LAN die lokale MTU (Interface) schon auf dem
> IPv6-Minimum (1280) sitzt.
>
Das liefert im fehlerhaften Zustand:
1?: [LOCALHOST] 0.010ms pmtu 1500
...
Resume: pmtu 1470 hops 8 back 8
Und
Hallo Konrad,
> > Das SYN-Paket in lab.dump wird mit mss 1440 gesendet, abgeleitet von der
> > Interface-MTU 1500. Da der Server auch mss 1440 verwendet, sind fuer
> > diese TCP-Verbindung groessere Pakete erlaubt, die dann wahrscheinlich
> > irgendeinem Router auf der Strecke vom Server zum
Hallo Christian,
> Ohne radvd besonders gut zu kennen faellt mir auf, dass Du nur fuer
> eth0 (LAN) die Link-MTU der Clients auf 1280 senkst, bei eth1 (LAB)
> tust Du das nicht. Entsprechend setzen die Clients im LAN ihre
> Interface-MTU auf 1280, waehrend die Clients im LAB die Interface-MTU
>
ich habe irgendwie keinen Bock mehr auf "Logging to file".
Mag sein, dass das Unix-Konzept die letzten hundert Jahr gut funktioniert hat,
aber zB Apache Logs zeilenweise in eine Datei zu schreiben hat deutlich
Nachteile.
1: Logrotate. Nervt.
2: Unstrukturiert. Das Log ist eine einfach
Hallo Konrad,
On Wed, Apr 10, 2019 at 10:13:26 +0200, Konrad Rosenbaum wrote:
> Ist ein DSL-Link oder sowas dazwischen? Dann wäre die Path-MTU maximal
> 1492.
>
> Hier gibt es einen netten Überblick:
>
> http://www.nwlab.net/art/mtu/mtu.html
Und falls ICMPv6 packet too big korrekt zugestellt
Hi,
On 4/10/19 9:41 AM, Christian Perle wrote:
Nun ist es so dass Clients aus dem einen Netz Probleme mit HTTPS haben und
die des anderen Netzes nicht.
Wohl eher mit grossen Paketen, die vom Server kommen.
Das SYN-Paket in lan.dump wird mit mss 1220 gesendet, von der
Interface-MTU 1280
Hallo Ronny,
On Tue, Apr 09, 2019 at 11:47:40 +0200, Ronny Seffner wrote:
> ich habe hier einen Router mit 2 NIC, die je einen IPv6-Adressbereich
> beziehen und an Clients dahinter verteilen.
>
> Nun ist es so dass Clients aus dem einen Netz Probleme mit HTTPS haben und
> die des anderen Netzes
Hallo,
ich habe hier einen Router mit 2 NIC, die je einen IPv6-Adressbereich
beziehen und an Clients dahinter verteilen.
Nun ist es so dass Clients aus dem einen Netz Probleme mit HTTPS haben und
die des anderen Netzes nicht. Schaue ich mir das aus Sicht des Webservers
an, so sendet dieser in
15 matches
Mail list logo