|
|
|
|
| Zitat von GandalfDerPinke
In C kann man einem cli Programm ja einfach Argumente übergeben und diese landen dann in dem argv array (oder wie auch immer man das Ding nennt).
| |
jup, dass heist so. da gibts keinen richtigen namen für.
| Zitat von GandalfDerPinke
Wenn man aber etwas in das Programm pipen will, müsste das ja über stdin laufen.
| |
das stimmt auch. das läuft über stdin.
| Zitat von GandalfDerPinke
Wie deckt man üblicherweise beides ab?
| |
das behindert sich beides gegenseitig überhaupt nichts. die commandline parameter haben nichts mit stdin zu tun. die werden von der libc start routine aufgenommen, "geparsed" und via diesem array an deine main methode weitergereicht.
der kram der via stdin rein kommt läuft halt über den stdin stream / file descriptor.
als kleines beispiel (auf osx geschrieben, falls es nicht ohne weiteres compiled, die ioctl und numBytes sachen auskommentieren):
|
Code: |
#include <stdio.h>
#include <stdbool.h>
#include <sys/ioctl.h>
#include <unistd.h>
int main(int argc, char* argv[])
{
printf("argc: %d\n", argc);
for (int i=0; i<argc; ++i)
{
printf("argv[%d]: %s\n", i, argv[i]);
}
printf("=====\n");
int numBytes = 0;
ioctl(STDIN_FILENO, FIONREAD, &numBytes);
printf("The following was piped-in using the stdin stream.\n");
printf("===== STDIN =====\n\n");
while (!feof(stdin) && numBytes > 0)
{
char buffer[1024] = {};
size_t bufferSize = fread(buffer, sizeof(char), sizeof(buffer), stdin);
if (bufferSize == 0)
{
break;
}
fwrite(buffer, sizeof(char), bufferSize, stdout);
}
return 0;
}
|
|
|
|
|
|
|
|
|
Ah, ich glaube ich verstehe.
Wird beides unabhängig voneinander verarbeitet und nicht verwurschtelt.
Danke
|
|
|
|
|
|
|
| die werden von der libc start routine aufgenommen, "geparsed" und via diesem array an deine main methode weitergereicht. | |
Das ist nur unter Windows so gelöst (CreateProcess() und WinMain haben hier auch nur einen Parameter für die Command Line), unter Unices wird das klassischerweise Ende-zu-Ende als echtes Array gehandhabt soweit ich weiß.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 12.08.2017 0:13]
|
|
|
|
|
|
ja, ok, dass war ein wenig zu einfach erklärt.
du hast in soweit recht, dass das unter unix (mehr spezifisch linux) etwas anders abläuft.
das parsen der command line übernimmt hier die shell, also z.b. die bash, die wiederum ruft den syscall execve mit den entsprechenden parametern auf, hier sind wir dann erstmal im kernel space. das wiederum führt dazu, dass der kernel dafür (vereinfacht) nen prozess baut, nach dem entsprechenden binary parser schaut und dessen entry funktion aufruft.
ab hier sind wir dann wieder im user space, hier wird die __start methode der binary aufgerufen, die ein paar register befüllt und dann __libc_start_main aufruft, die alle möglichen lustigen sachen macht, damit ein programm überhaupt laufen kann und diverse system features nutzen kann. diese methode wiederum ruft dann die C main funktion mit ihren parametern auf.
was korrekt ist, ist das hier ein array und auch die grösse dieses arrays von der konsole zum kernel und wieder zurück an den loader gereicht wird, bis das ganze dann schluss endlich in deiner main funktion ankommt.
ob das jetzt wirklich ende zu ende ist, sei mal dahingestellt, weils halt nach wie vor irgendwo geparst wird. das ist dann aber mehr philosophisch.
unter windows hängt das ganze davon ab, ob du nen programm hast, was gegen die CRT gelinkt ist oder nur gegen win32.
im fall von ersterem wird ein einzelner string in der crt_main (oder wie auch immer das teil hiess, ist im SDK enthalten) tokenized und dann an deine main weitergereicht, so dass das standardkonform ist.
im fall von einem reinen win32 programm bekommst du lediglich diesen einzelnen string rein und darfst den selber verarbeiten.
hier sollte man dann allerdings auch bedenken, dass das im fall von windows verhältnismässig selten genutzt wird und es auch win32 APIs gibt, die dir diesen string tokenizen.
wenn ich mich da nicht gerade irre, war es zumindest bis XP so (letzter kernel / loader code den ich gesehen habe), dass hier auch eigentlich nen tokenized string von der shell (nicht konsole) ankam, den dann der loader wieder in einen einzelnen string verwandelt hat.
das wird vermutlich einer der teile sein, den man hier seit ewigen zeiten mitgeschleppt hat, weil das absolut irrelevanter und uninteressanter code ist.
es gibt übrigens auch systeme, bei denen die konsole da nichts zerhackt und auch einfach nur nen einzelner string im loader ankommt. da macht der loader das zerhacken dann und gibt das ganze direkt an deine main weiter.
---
das was ich ursprünglich mit
| die (command line parameter) werden von der libc start routine aufgenommen, "geparsed" und via diesem array an deine main methode weitergereicht. | |
meinte, war halt, dass deine main von einer anderen methode der libc, welche vor deiner main läuft, aufgerufen wird und die dafür sorgt, dass du die parameter entsprechend dem standard bekommst, genauso wie nen sauberes environment und die entsprechenden stdio streams (in, out, error) bekommst.
wie das wiederum auf den einzelnen systemen im genauen abläuft wollte ich da nicht mal unbedingt reinschreiben, weil das eigentlich für die meisten sachen irrelevant ist, weil man da nahezu keinen einfluss drauf hat und auch nicht braucht.
|
|
|
|
|
|
|
:)
Was passiert wenn man "borgbackup.org" in Chrome eingibt?
http://borgbackup.org
Response: 301, Location: https://borgbackup.org
https://borgbackup.org
Response: 301, Location: http://www.borgbackup.org
http://www.borgbackup.org
Response: 301, Location: https://www.borgbackup.org
(160 ms bis hier hin)
https://www.borgbackup.org
Response: 200
(30 ms)
¯\_(ツ)_/¯
Die Seite wird von Github Pages gehostet mit maximal-aggressiv cachendem Cloudflare davor, weil GHP kein SSL auf eigene Domains kann und öfter mal schlechte Ladezeiten hat.
Ich versuche gerade herauszufinden, warum ca. 1/3 aller Requests nicht gecached werden. Ein bisschen was war wohl ein falsch referenziertes favicon.ico, was 404er verursacht hat, die natürlich nicht gecached werden. Sonst sehe ich aber mit einem sauberen Profil keine Requests die abnormal sind, und alle Seiten haben CF-Cache-Status: HIT. Ich vermute daher, dass diese 301er vielleicht als ungecached gezählt werden.
Gibt es vielleicht noch andere Pfade, die von manchen Browsern (Mobil? iOS?) auf Verdacht abgerufen werden?
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von csde_rats am 12.08.2017 11:07]
|
|
|
|
|
|
Ihr wisst aber, dass vermutlich auch 1/3 aller potentiellen Nutzer abspringen, nachdem sie diese Seite in prallem 1997-Charme da sehen, oder? Natürlich sagt das nichts über die Qualität des Produkts aus, aber wenn der erste Eindruck schon meh ist.
|
|
|
|
|
|
|
Ich weiß nicht. Ich bin kein Designer, aber sowas ist ja auch irgendwo Kommunikation. Ich habe da z.B. bewusst kein Hipster-CSS-JS-SPA mit Ladebalken und animiertem Hintergrund benutzt, weil a) ich das gar nicht kann b) die Software hinter der Hipsterwebsite oft gar nicht so toll ist. Dagegen hat viele tolle Software (gerade im Sysadmin-Bereich) meist ganz simple Websiten (oder gar keine).
So ist das halt ein total simples (wahrscheinlich doch schon zu einfaches und hässliges) Design. Auf / gibt es die wesentlichen Kernpunkte was das ist und große Links wo es weitergeht. Das Prinzip scheint grob zu funktionieren nach den begrenzten Statistiken, die ich habe (CF-Stats + Github-Stats).
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 12.08.2017 11:28]
|
|
|
|
|
|
| Zitat von csde_rats
Hipster-CSS-JS-SPA
| |
Na, nicht gleich p0tten. Es gibt noch ein paar Stufen zwischen Plaintext und Web4.9-Hipstercrap.
Ich bin ganz bei dir, dass für so ein Tool eine simple Seite das beste ist. Aber die sieht halt aus, als hätte ich sie gemacht. :*
|
|
|
|
|
|
|
Mit Hugo und passendem Theme die Seite statisch generieren.
Ich muss mich jetzt aber auch mal unbedingt an Borg setzen. Ich bin was Backups angeht nicht so geil aufgestellt.
|
|
|
|
|
|
|
Internet wie 1997 gefällt mir. Danke für die neue Signatur!
|
|
|
|
|
|
|
Hahahahahahaa.
|
|
|
|
|
|
|
|
|
|
|
| Zitat von Rufus
Ihr wisst aber, dass vermutlich auch 1/3 aller potentiellen Nutzer abspringen, nachdem sie diese Seite in prallem 1997-Charme da sehen, oder? Natürlich sagt das nichts über die Qualität des Produkts aus, aber wenn der erste Eindruck schon meh ist.
| |
naja, das hellgrün auf weis verleitet einen jetzt zwar nicht direkt zum weiterklicken aber mich persönlich stösst sowas wesentlich mehr ab
gepaart mit der sache dass es bei mir die ersten zwei mal einfach nicht laufen wollte wie dokumentiert :/
|
|
|
|
|
|
|
Ich finde Tarsnap bekommt den Spagat zwischen Admin-Streetcred und anschaubar eigentlich ganz gut hin. Die Monit-Homepage ist in der Tat herausragend scheisse.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von B0rG* am 12.08.2017 17:32]
|
|
|
|
|
|
Das Logo kommt allerdings nicht von mir
Linkfarben sind notiert.
Abgeschaut ist die Idee btw. bei zmq
e: Wenn jemand mit Webzeugs kann und Lust hat das CSS besser zu machen... Patches nehme ich gern an (src)
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 12.08.2017 18:20]
|
|
|
|
|
|
| Zitat von csde_rats
e: Wenn jemand mit Webzeugs kann [...]
| |
das ist sicherlich ne falle!
|
|
|
|
|
|
|
Nein, gar nicht
|
|
|
|
|
|
|
Nach drüber Schlafen weiß ich jetzt, was mich da so "gestört" hat: Es ist auf den ersten Blick klar, dass das Grün ein #00xx00 ist (mit x=x obviously). Das geht halt nicht, und auch zmq machen das nicht mit ihrem Rot. Und siehe da, habe das spaßhalber einfach gegen bißchen dunkleres Grün ersetzt und schon war das Eww weitgehend weg.
|
|
|
|
|
|
|
#44D02E?
e: "Luminous Green" (irgendwas um #22bb45 - #00b51a) schaut gut aus.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 13.08.2017 15:31]
|
|
|
|
|
|
In meinen Logs steht sowas:
|
Code: |
net-fw DROP IN=eno1 OUT= MAC=xxx SRC=125.212.217.214 DST=MEINE_IP LEN=40 TOS=0x00 PREC=0x00 TTL=110 ID=24384 PROTO=TCP SPT=46640 DPT=4443 WINDOW=35627 RES=0x00 SYN URGP=0
net-fw DROP IN=eno1 OUT= MAC=xxx SRC=52.36.168.148 DST=MEINE_IP LEN=87 TOS=0x00 PREC=0x00 TTL=233 ID=14443 DF PROTO=TCP SPT=443 DPT=53428 WINDOW=114 RES=0x00 ACK PSH URGP=0
net-fw DROP IN=eno1 OUT= MAC=xxx SRC=192.241.178.125 DST=MEINE_IP LEN=83 TOS=0x00 PREC=0x00 TTL=51 ID=40522 DF PROTO=TCP SPT=443 DPT=54422 WINDOW=11 RES=0x00 ACK PSH URGP=0 |
|
SPORT=443 (https) und DPORT!=443.. Was heißt das? Da wird ein incoming request auf https gedropped? Was ist das für eine Nummer bei DPORT?
|
|
|
|
|
|
|
Der Source Port ist egal und im Prinzip beliebig. Der kann auch 443 oder 80 oder 21 sein, das bedeutet erstmal nichts.
4443 ist wohl irgendein Messenger mit Lücken, 53428 und 54422 sind wohl irgendwas von Apple. Ich tippe auf Scan auf verwundbare Software. Source Port könnte hier absichtlich so gewählt worden sein, um den Admin beim Logs durchschauen zu verwirren.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 14.08.2017 11:16]
|
|
|
|
|
|
Da ich sowieso alle requests bis auf wenige ports droppe, brauche ich die ja auch nicht loggen, oder? Sowas spamt mir nämlich die logs voll.
|
|
|
|
|
|
|
Firewall-Logs ... brauch ich ned. Nur eine weitere Sache, wo im Zweifel das Dateisystem vollläuft und einloggen nicht mehr richtig geht.
Ach nehmt sie einfach alle! https://http.cat
|
CrashMonkey works by recording all the IO from running a given
workload, then *constructing* possible crash states (while honoring
FUA and FLUSH flags). A crash state is the state of storage after an
abrupt power failure or crash. For each crash state, CrashMonkey runs
the filesystem-provided fsck on top of the state, and checks if the
file-system recovers correctly. Once the file system mounts correctly,
we can run further tests to check data consistency. The work was
presented at HotStorage 17. The workshop paper is available at [2] and
the slides at [3]. | |
neat-o.
[1] https://github.com/utsaslab/crashmonkey
[2] http://www.cs.utexas.edu/~vijay/papers/hotstorage17-crashmonkey.pdf
[3] http://www.cs.utexas.edu/~vijay/papers/hotstorage17-crashmonkey-slides.pdf
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 14.08.2017 18:38]
|
|
|
|
|
|
| Zitat von csde_rats
Firewall-Logs ... brauch ich ned. Nur eine weitere Sache, wo im Zweifel das Dateisystem vollläuft und einloggen nicht mehr richtig geht.
| |
dat is der grund, warum man /var/log auf nen separates volume packt.
oder wenn man ganz wahnsinnig ist in nen virtuellen speicherbereich der nen ringbuffer als backing store hat.
|
|
|
|
|
|
|
Oder die Logs gleich an einen besonders gesicherten syslog-Server schicken. Rentiert sich halt erst ab einer bestimmten Zahl von Rechnern.
|
|
|
|
|
|
|
| Zitat von Oli
Da ich sowieso alle requests bis auf wenige ports droppe, brauche ich die ja auch nicht loggen, oder? Sowas spamt mir nämlich die logs voll.
| |
Letzteres ist halt kein Argument, siehe Posts vor mir. Allerdings hast du auch recht, dass du wahllose port requests auch wegschmeißen kannst, sofern du eh nicht auf Anomalien auswertest. Anstatt das Logging deswegen komplett abzuschalten würde ichs halt auf relevante Sachen (!= Port Scans) beschränken.
|
|
|
|
|
|
|
|
|
|
|
Was will mir GPG/Enigmail mit "Kein gültiger Unterschlüssel" sagen? Schlüssel existiert, hat korrekte Mail drin, ist nicht abgelaufen und hat totales Vertrauen.
--
Nachdem Sie den "Jetzt KAUFEN" Button angeklickt haben, wird eine sichere Verbindung zu "PayPal" hergestellt und Sie können die Zahlung vornehmen.
"PayPal"
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 16.08.2017 13:13]
|
|
|
|
|
|
|
|
|
|
Eigentlich nicht so cool, dass das sooo einfach geht.
Einfach eine neue Env-Variable injecten und alle SessionKeys abgreifen ist schon bisschen spooky. Da sollte der Browser zumindest die ganze Zeit in einem roten "WATCH OUT WHAT YOU ARE DOING HERE" Modus laufen (ähnlich wie wenn man manche Filebrowser als root startet).
|
|
|
|
|
|
Thema: Der Linux-Thread 100 // 0x23 ( const int MAX_POST = 30 * 100; // 0x23 ) |