Suchergebnisse

Ich meine da wäre eine übernahmen der Erkenntnisse in das Wiki besser… Ich halte ein Forum zum Aufbau einer Knowledge DB für genauso ungeeignet wie ein Ticket innerhalb eines Ticketsystem.

Ich bin mir nicht sicher ob eine Antwort auf einen 2,5 Jahre alten Thread und für ein ehemaliges Mitglied des Forums so wirklich Sinn macht.

Hatte ich glaub gestern gesehen und mir gedacht… aha also kein messbarer Vorteil und kein Grund mit älteren kleinen Partitionen dahin zu wechseln solange man noch nicht in die Nähe von 2038 kommt. Meine APU2's haben schon ein paar jährchen auf dem Buckel und werden wohl nicht kein 17 Jahre mehr...

2038 Das würde ich jetzt nicht so als messbaren Vorteil ansehen… newfs soll ausserdem etwas schneller laufen. Da wäre die Frage ob das FS allgemein etwas schneller ist… hab aber z.Z. leider nicht das equipment um das zu testen… es sei denn ein USB 3 Stick könnte schon Ergebnisse liefern

Moin. Mit 6.7 wurde für newfs FFS2 als default gesetzt… wobei es früher (4.8 bis 6.6) default für Partitionen/disklabel grösser 1 TB war. Allerdings wird z.B. in der fstab etc. sowohl FFS als auch FFS2 nur als ffs angezeigt. Gibt eine Möglichkeit zu prüfen, welches FFS verwendet wurde? Und 2te...

Ich harder noch ein wenig mit mir eine zu holen… ne kleine scheint mir für das was ich machen will zu klein… und eine Grosse zu Kosten intensiv um dann zu failen wenn das Betriebssystem der Wahl nicht tut.

Ich finde es schon sehr ungewöhnlich, dass noch nicht mal die https://www.openbsd.org/67.html existiert, normal kam die afaik auch schon einige Tage vor dem release… Der ftp Folder 6.7 wurde auch erst am 01.05. angelegt. Allerdings hab ich was von wegen Hardware Problemen in den letzten Wochen...

Ich hatte den /etc/hosts Eintrag nur auf dem Empfänger eingetragen. Bin davon ausgegangen dass das logisch sei, da der Sender ja seinen eigenen Name nicht mitschickt, wenn man ihm das nicht explizit befiehlt. Vielleicht kann man das beim logger oder sendendem syslogd irgendwie einstellen. Ist...

Er hatte es halt nur temporär beschrieben. Also bis zum nächsten neustart der Maschine

Hatte erst nach der änderung der /etc/hosts syslogd gestarte, als ich das getestet habe. Ein restart von syslogd kann imho nicht schaden So bzw. so ähnlich (weil er den schritt in die rc.local nicht beschrieben hat oder ich das nicht gesehen habe bisher) wurde es von Peter N.M. Hansteen...

z.B. mit nem Eintrag in der /etc/hosts

Darf man fragen welche du bestellt hast?

Nicht unbedingt es sei denn du schaltest sowas wie eine debug Modus ein Die letzten 4 Einträge meiner übertragenen /var/log/messages Sahen vor 10 Minuten wie folgt aus Apr 30 19:15:38 puffy1 syslogd[28544]: start Apr 30 20:00:01 puffy1 syslogd[28544]: restart May 1 05:00:01 puffy1...

@Andy_m4 der Ton macht die Musik… Eine Aussage das man tls oder ein vpn verwenden solle als "an Nutzlosigkeit kaum zu übertreffen" zu bezeichnen dann aber eine Art auf TLS basierendes VPN drunter hängt (wobei syslog selbst tls unterstützt) Ist halt etwas, dass mich extremst nervt.

Ich bin kein Netzwerk Spezialist… wenn ich trotzdem mal bei einem Kunden etwas z.B. auf ner pfSense testen oder fixen muss, kommen tools wie tcpdump und telnet ins Spiel (ist mir in den letzten 7 Jahren 3x passiert, kein einziges mal hatte ich das Attribut udp benötigt). Eines dieser beiden...

Das mit dem tcpdump sieht doch schonmal garnicht so schlecht aus… die Zahl am Schluss sind afaik die verschickten Byte. .syslog gibt den udp port 514 an. (wobei es etwas komisch ist, wenn du nc verwendest, dass beim ersten .syslog in der Zeile dieser Port verwendet wird, anyway) Vielleicht liegt...

Nachdem es bei mir auch so ausschaut und er Daten überträgt würde ich sagen nein… Aber man kann ja relativ einfach ausprobieren ob er grundsätzlich syslog Daten übertragen würde: 2 Terminals zur OpenBSD Maschine aufmachen, oder auf der OpenBSD Maschine tmux verwenden Im einen Fenster tcpdump -i...

Nur noch so als Hinweis: FreeBSD Anleitungen sind oft nicht 1zu1 auf OpenBSD anwendbar. Dass ich tcpdump mit telnet verwechselt habe kommt leider öfter vor… Asche auf mein Haupt. Mit tcpdump -i <interface> host 192.168.1.1 and udp and port 514 bekam ich Ergebnisse Und Andy hats jetzt wieder auf...

aber tcpdump erwartet halt TCP Pakete. UDP arbeitet ein wenig anders. Innerhalb eines LAN's (wie du es tust) halte ich den Schutz per Verschlüsselung für unnötig. Will man das über das Internet versenden sollte man das ganze per tls oder durch ein vpn schützen

Also bei meinen Tests mit 2 OpenBSDs 6.7 APUs funktioniert es… Ein tcpdump dürfte sich bei einem UDP Versand allerdings generell etwas schwer tun. Ich hab es so getestet. auf der Empfänger Kiste syslogd in rc.d gestoppt und händisch mit dem Parameter -u gestartet. Danach ein tail -f...

Auch wenn es vielleicht ein wenig affig ist… ich hab da mal ein ansible script geschrieben, damit man statt sshpass (wenn man kein root ist kriegt man das nicht gut nachinstalliert…) pexpect (kriegt man z.B. in einer virtualenv umgebung per pip nachinstalliert) benutzen kann um den ssh pubkey zu...

Und was ich auch grad noch gesehen habe (zwar schonmal gewusst aber wieder vergessen bis seit ich neue Rechner habe)… man braucht sshpass für die externe passwort eingabe… was nicht gerade den besten Ruf hat

Ich würde so wenig wie möglich mit den Inventory files auf systemebene arbeiten… Das ist immer blöd zu debuggen… -m raw ist eigentlich nur sinnvoll wenn man weiss oder glaubt, das die andere Seite kein python vorhanden hat… ist bei einem Linux recht unwahrscheinlich… bei einem OpenBSD kommt das...

Ein Bekannter hat Jitsi für sowas am Start. Gestern war ich mit der kostenlosen iOS app damit verbunden, problemlos. Technik affin sollte eigentlich nur der Betreiber sein. Über https://meet.zilium.de