|
|
|
|
|
|
|
|
|
|
|
|
|
Ich tu mich gerade schwer zu Googeln.
Wenn ich ein Verzeichnis via NFS4 auf mehreren Servern gemountet habe und gleichzeitig die gleiche Datei im Append Modus öffne und einzelne Zeilen rein schreibe, kann ich da Probleme kriegen? In welcher Reihenfolge die Zeilen erscheinen, ist mir egal, die Zeilen dürfen nur nich kaputt gehen.
(Mit anderen Worten, kann ich eine NFS Datei zum Loggen von mehreren Servern verwenden)
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 24.04.2020 13:18]
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
Wenn ich ein Verzeichnis via NFS4 auf mehreren Servern gemountet habe und gleichzeitig die gleiche Datei im Append Modus öffne und einzelne Zeilen rein schreibe, kann ich da Probleme kriegen?
| |
ja.
| | Zitat von Oli
In welcher Reihenfolge die Zeilen erscheinen, ist mir egal, die Zeilen dürfen nur nich kaputt gehen.
| |
das wird funktionieren oder auch nicht.
| | Zitat von Oli
(Mit anderen Worten, kann ich eine NFS Datei zum Loggen von mehreren Servern verwenden)
| |
ist ne ganz schlechte idee.
das problem liegt darin, dass nfs kein coherency kann. schau dir die "cto / nocto" sache an.
nfs geht davon aus, dass du nicht gleichzeitig in ein und die selbe datei schreibst. von daher ist es mehr als undefiniert, was da passiert, solltest du das doch machen.
im besten fall, bei wenigen clients und gut verteilten write ops wird das vermutlich funktionieren, aber wenn da nen bischen druck hinter ist, dann wird dir das um die ohren fliegen.
wie bei allen sachen die nicht synchronisiert sind und damit nicht kohärent sind kann das funktionieren, aber es muss nicht. in der realität wird es eher nicht gut gehen.
wenn das fürs logging sein soll, dann nimm lieber irgendwas(!) was dafür gemacht ist oder bastel dir kurz nen simplen udp daemon, der einfach sachen entgegen nimmt und in ne datei nagelt. falls du da mehr als 1000 bytes pro paket erwartest oder das nicht garantieren kannst, dann kannst du dafür auch tcp nutzen.
den ganzen kram gibt es aber seit jahren schon in fertig. von daher würde ich den nehmen, wenn du da nicht sehr aussergewöhnliche anforderungen hast.
|
|
|
|
|
|
|
|
|
|
|
Hat hier schonmal mit USB eine Geräteerkennung für Plug und Unplug unter Windows geschrieben? Ich finde keine API die mir gefällt. Es läuft auf den Gerätmanager hinaus und entweder muss man als GUI Anwendung eine Handle auf das Anwendungsfenster übergeben oder einen eigenen Dienst laufen lassen.
Unter Linux gibt es gleich mehrere Möglichkeiten:
- Direkt im Kernel
- virtuelles Dateisystem über /proc oder /sys
- LIBUSB
- UDEV, mein neuer Schatz
Zu UDEV habe ich ein kurzes Beispiel bei Github gefunden, hier mal als Pseudocode:
| |
| Code: |
#include <libudev.h>
udev_new()
udev_monitor_new_from_netlink();
udev_monitor_filter_add_match_subsystem_devtype();
udev_monitor_enable_receiving();
udev_monitor_get_fd(mon);
loop {
select(); // poll() oder epoll() oder was schickes neues?
struct udev_device* dev = udev_monitor_receive_device(mon);
when udev_device_get_devnode() {
udev_device_get_action(dev);
udev_device_get_sysattr_value(dev, "idVendor");
udev_device_get_sysattr_value(dev, "idProduct");
udev_device_get_subsystem(dev),
udev_device_get_devtype(),
udev_device_get_devnode());
}
udev_device_unref
}
udev_unref(udev);
|
|
Um es vollständig rund zu machen, muss ich mir von logind (bzw. DBUS) noch Suspend & Resume mitteilen lassen. Träume etwas zu viel von tollen Features 
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 24.04.2020 15:35]
|
|
|
|
|
|
|
|
|
Danke Traxer!
Direkt noch eine Frage. Ich habe einen einfachen TCP Server an den ich JSON schicke. Auf Client Seite habe ich bisher einfach "./mein_programm > /dev/tcp/server.address/port" gemacht. Funktioniert auch. Jetzt überlege ich aber das Senden an den Server direkt in "mein_programm" zu schreiben. Abgesehen davon, dass ich das C Interface für socket connect, addrinfo etc. ziemlich anstrengend finde; hätte ich Vor- oder Nachteile davon, /dev/tcp/... zu ersetzen? Spricht was dagegen, sowas produktiv zu nutzen?
|
|
|
|
|
|
|
|
|
|
|
Ich benütze es nur um die TCP Verbindung in Shellscripten zu testen. Ist das nicht ein spezifisches Feature der Bash? Dann wärst du schon mal unabhängig von der verwendeten Shell. Traxer hat dazu sicher klügeres zu sagen 
Grüße von inet_addr(), äh, inet_aton(), ich meine - inet_pton()
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von hoschi am 24.04.2020 15:31]
|
|
|
|
|
|
|
|
|
|
Wenn es nur inet_pton wäre, ich will aber auch einen Hostname angeben können.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
| | Zitat von Farbkuh
e: Wo ich grad deine Bilder oben sehe: Ich glaube das könnte bei mir auch noch mal helfen. Mein Gerät wird auch ziemlich heiß in letzter Zeit und der Lüfter ist ziemlich laut. Ich organisiere mir mal Wärmeleitpaste und mach den hier auch mal auf.
| |
Wenn das nicht demnächst im "Hass" oder "Ich brauch was neues" mündet
| |
Hatte ihn gestern offen und habe, aus Ermangelung von Wärmeleitpaste einfach mal alles gereinigt und mit Druckluft ausgeblasen. Lüfter schon mal leiser und Gerät fühlt sich kühler an. Läuft auch wieder. Hätte ja eigentlich gerne was neues, kanns mir aber nicht leisten 
|
|
|
|
|
|
|
|
|
|
|
Langsam wäre neues Gerät hier auch toll, aber mein X220 ist in guter Verfassung.
| | Zitat von Oli
Wenn es nur inet_pton wäre, ich will aber auch einen Hostname angeben können.
| |
Ich wollte gerne schreiben, dass es da doch nur gethostbyname() gibt, bis ich die man page geöffnet habe. Geschwisterfunktionen für die Angabe der gewünschten Addressfamilie und Wiedereintrittsfähigkeit. Wenn man da durch ist, solltest es schöner werden?
Ich war damals überrascht, dass MinGW kein inet_pton() kannte.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 24.04.2020 16:01]
|
|
|
|
|
|
|
|
|
| |
| Code: |
int connect(std::string hostname, int port) {
addrinfo* addrs = NULL;
addrinfo hints = {};
int sd;
hints.ai_family = AF_INET;
hints.ai_socktype = SOCK_STREAM;
sockaddr_in res;
int err = getaddrinfo(hostname.c_str(), std::to_string(port).c_str(), &hints, &addrs);
if (err != 0) {
fprintf(stderr, "%s: %s\n", hostname.c_str(), gai_strerror(err));
exit(1);
}
for(struct addrinfo *addr = addrs; addr != NULL; addr = addr->ai_next) {
sd = socket(addr->ai_family, addr->ai_socktype, addr->ai_protocol);
if (sd == -1) {
err = errno;
break;
}
if (connect(sd, addr->ai_addr, addr->ai_addrlen) == 0)
break;
err = errno;
close(sd);
sd = -1;
}
freeaddrinfo(addrs);
if (sd == -1) {
fprintf(stderr, "%s: %s\n", hostname.c_str(), strerror(err));
exit(1);
}
return sd;
} |
|
Deshalb liebe ich Python.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
hmmm weiss nicht, bin garnicht so davon überzeugt weil das serverseitig immer die graphen rendert.
da ist alle fünf minuten immer gut CPU last auffem system nur wegen munin, selbst wenn ich die dinger einmalig im monat nur anschau.
oder hat sich das mittlerweile geändert?
| |
Nope, da ändert sich nix. Deshalb läuft der Mist einfach 
Du kannst die Graphen aber auch in demand rendern lassen, dann sollte sich die Last sehr in Grenzen halten.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
Ich habe einen einfachen TCP Server an den ich JSON schicke. Auf Client Seite habe ich bisher einfach "./mein_programm > /dev/tcp/server.address/port" gemacht. Funktioniert auch.
| |
zum testen ist das ok. wenn du damit was anderes machen willst, es "portabel" haben willst, dann lass das besser.
| | Zitat von Oli
Abgesehen davon, dass ich das C Interface für socket connect, addrinfo etc. ziemlich anstrengend finde; hätte ich Vor- oder Nachteile davon, /dev/tcp/... zu ersetzen? Spricht was dagegen, sowas produktiv zu nutzen?
| |
ja, türlich spricht da was gegen. es ist nicht wirklich dafür gedacht. die ausnahme wären halt kurzlebige bash scripte. woanders wird das vermutlich nicht unbedingt oder anders funktionieren.
das ganze socket zeugs in C ist tatsächlich nicht sonderlich toll. das liegt einfach daran, dass es alt ist und es nie jemand wirklich anfassen wollte. ideen das zu verändern gab und gibt es viele. ich hab da auch so meine variante von, wirklich akzeptiert werden die aber halt nur von sehr wenigen leuten, weil das halt so ein teil code ist, von dem viele sagen das der irrelevant ist, weil man den nur einmal schreibt und danach nicht mehr anfasst.
die realität ist da halt leider wie häufig mit diesen speziellen sachen etwas anders. spassig wird das vor allem, wenn man auf app seite anfangen muss "sockets" zu tunen oder TCP an gewisse anforderungen anzupassen oder man "features" der netzwerkkarten nutzen will (multiqueue, filter, etc).
ist für deinen fall alles nicht sonderlich wichtig oder relevant. du willst ja effektiv "nur" nen paar strings hin und her schicken.
socket programmierung (TCP) folgt eigentlich in etwa dieser vorgehensweise:
- namen auflösen >getaddrinfo<
- socket erstellen >socket<
- (optional) setzten von socket options >fcntl, ioctl, setsockopt<
- socket an irgendwas binden >bind<
- (client) socket irgendwohin verbinden >connect<
- (server) socket in den server modus versetzen >listen<
- (server) clients akzeptieren und verarbeiten >select, poll, accept<
- daten hin und her schicken >send, recv<
- socket schliessen >close<
wenn du nen client programmierst, dann willst du in aller regel irgendwelche namen auflösen, dafür hat man früher mal >gethostbyname< und so genutzt. inzwischen sollte man, sofern man nichts aus dem performance bereich macht, >getaddrinfo< nutzen. die funktion ist sehr nett, weil sie dir direkt die sockaddr structure liefert, die die infos für den socket und bind/connect call liefert.
die beispiele in der manpage von getaddrinfo sind soweit okay. halt sehr kurz gehalten, aber ok.
du willst da aber vermutlich ein wenig mehr in der schleife machen, die die resultate der namensauflösung verarbeitet. was du wiederum nicht unbedingt machen willst ist diesen ganzen code mehrfach in der lebenszeit deines programms aufrufen, wenn es sich vermeiden lässt. das kann nämlich nen paar sekunden dauern, je nachdem wie schnell dein DNS server so arbeitet.
was ich dir einfach raten würde ist, schreib dir mal an nem ruhigen nachmittag oder so ne kleine sammlung von funktionen, die diesen ganzen voodoo zusammenfasst und die du einfach so in den code schmeissen kannst. dann muss man sich damit nicht jedes mal neu auseinandersetzen.
man kann natürlich auch vorhandene libs nutzen. wenn man sich mit deren vorgehensweisen anfreunden kann.
WARNUNG: das windows socket system ist kaputt, seit jahrzehnten.
die windows variante von >poll< (WSAPoll) ist dafür berühmt berüchtigt in bezug auf ihr verhalten ein RNG zu sein. gelegentlich macht sie was man erwartet, gelegentlich auch nicht. gelegentlich crasht dir deine app, gelegentlich passieren andere sehr komische sachen. das verhalten kann sich nach jedem windows patch ändern. ohne vorwarnung. es kann sich auch auf grund der sternenkonstellation, der uhrzeit und den bitreihenfolgen in deinen caches ändern. genau so wie durch den quantum zustand jedes elektrons in deinem computer.
auf windows sollte man die I/O Completion Ports nutzen, was ne ganz andere kategorie von bullshit ist. guter bullshit, aber trotzdem bullshit.
|
|
|
|
|
|
|
|
|
|
|
|
Blöde Frage: Was für einen PDF-Reader nimmt man unter Mint xfce? Hab jetzt nach kurzer Recherche mupdf installiert, aber das kann ja außer anzeigen sonst nichts.
|
|
|
|
|
|
|
|
|
|
|
So wie überall: Okular. Einzig brauchbarer PDF Reader! (Na gut, Evince ist halbwegs akzeptabel, aber…
All diese schlanken Reader sind kacke meiner Erfahrung nach.
|
|
|
|
|
|
|
|
|
|
|
Alle wie wild am vim penetrieren aber dann ist der PDF Reader nicht klickibunti genug.
llpd!
/e: Traxer, deinen Post lese ich Montag in Ruhe, wenn ich wieder arbeiten darf. Danke für die Mühe!
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 24.04.2020 23:05]
|
|
|
|
|
|
|
|
|
| | Zitat von audax
So wie überall: Okular. Einzig brauchbarer PDF Reader! (Na gut, Evince ist halbwegs akzeptabel, aber…
All diese schlanken Reader sind kacke meiner Erfahrung nach.
| |
Da isn Haufen KDE Kram mit in den dependencies. Bringt das nicht potentiell Probleme, wenn ich xfce nutze?
|
|
|
|
|
|
|
|
|
|
|
|
Afaik nicht, vor allem nicht mit "--no-install-recommends". Wenn dir das wirklich sorgen macht, dann kannst du Okular auch als Snap installieren, dann ist es komplett getrennt: https://snapcraft.io/okular
|
|
|
|
|
|
|
|
|
|
|
|
Okular. Nutzbare Anwendungen > ein paar libs die nicht stören.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von audax
Afaik nicht, vor allem nicht mit "--no-install-recommends".
| |
jetzt mal ernsthaft, gibt es wirklich leute die nicht als erstes folgendes in ihre APT config schreiben?
| |
| Code: |
APT::Install-Recommends "false";
APT::Install-Suggests "false";
|
|
das ist mit das erste was ich auf nem frisch installierten system mache.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Traxer
| | Zitat von audax
Afaik nicht, vor allem nicht mit "--no-install-recommends".
| |
jetzt mal ernsthaft, gibt es wirklich leute die nicht als erstes folgendes in ihre APT config schreiben?
| |
| Code: |
APT::Install-Recommends "false";
APT::Install-Suggests "false";
|
|
das ist mit das erste was ich auf nem frisch installierten system mache.
| |
Ich wusste nicht, dass auch Pakete installiert werden die nicht unbedingt benötigt werden. Wo finde ich die config bei Mint?
|
|
|
|
|
|
|
|
|
|
|
Das X1 ist ein hervorragendes Arbeitslaptop. IBM nutzt intern aber hauptsächlich Macbooks seit einigen Jahren.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Farbkuh
Ich wusste nicht, dass auch Pakete installiert werden die nicht unbedingt benötigt werden. Wo finde ich die config bei Mint?
| |
kleiner hinweis:
bei debian (und debian basierten system) liegt diese config in
/etc/apt/apt.conf.d/
der rest bleibt als transferaufgabe dem geneigten leser überlassen
|
|
|
|
|
|
|
|
|
|
|
crosspost von mir aus nem internen channel, aber der rant muss raus:
|
|
|
|
|
|
|
|
|
|
|
|
is schon klar, die haben hinter download nen cdn stehen mit was weiss ich, aber grade den gpg key, der als trustanchor fungieren soll, nicht per https und nichtmal auf der homepage ne key signature veröffentlichen. ich mein, dann lassts doch gleich bleiben leute und sagt dass man euch ne rootshell per telnet zugänglich machen soll und ihr erledigt den rest für einen.
|
|
|
|
|
|
|
|
|
|
|
halleluja, wenigstens gibts hier ne checksumme. aber das ist doch grob fahrlässig sowas.
das kriegen selbst die ganzen
curl ... | bash leute hin, dass da wenigstens immer nen https dransteht.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
| | Zitat von Farbkuh
Ich wusste nicht, dass auch Pakete installiert werden die nicht unbedingt benötigt werden. Wo finde ich die config bei Mint?
| |
kleiner hinweis:
bei debian (und debian basierten system) liegt diese config in
/etc/apt/apt.conf.d/
der rest bleibt als transferaufgabe dem geneigten leser überlassen
| |
Danke, habs gefunden. Ich bin immer noch nicht so recht durch die Ordnerstruktur durchgestiegen
Waren aber beide schon auf "false". Werde jetzt Okular testen. Danke für die Tipps.
|
|
|
|
|
|
|
|
|
|
|
|
Die Lage bei den bisherigen ThinkPads mit AMD Prozessoren scheint sich verbessert zu haben. Dabei fehlt noch die Unterstützung für AMD CPPC oder so.
|
|
|
|
|
|
|
|
|
|
|
Ich will in unserem Server ein RAID1 vergrößern. Bisher sind das 2 Intel SSDs mit 256 GB. Das würde ich gerne durch 2x 1TB ersetzen.
Welche SSDs nimmt man denn da aktuell? Macht man mit Samsung 860 Pro was falsch?
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
