|
|
|
|
|
|
|
Darf man eigentlich
nehmen?
Beim grob drüberscrollen war's mal so, mal anders, und ich kenn's bisher nur mit
…und ich vermute, dass auch der Beispiel-py-Code das im Request dann tatsächlich auch so absetzt, nachdem man's dort ja auch als Hashes übergibt.
Muss hier nicht das Problem sein, aber vielleicht macht's das auch nicht einfacher, wenn Curl (oder remote) dann schon bei
| |
| Code: |
Accept:application/json
|
|
die Segel streicht.
/edit
| |
| Code: |
#!/bin/bash
access_token=ich_bin_ein_token
curl -X POST -v -H "Authorization: Bearer $access_token" localhost:8080
|
|
Funktioniert bei mir, zumindest seitens curl, tadellos. Was auch immer da also sonst das Problem sein mag.
| |
| Code: |
POST / HTTP/1.1
Host: localhost:8080
User-Agent: curl/7.69.1
Accept: */*
Authorization: Bearer ich_bin_ein_token
|
|
/edit
geht auch mit whitespaces oder sonstigem im token sauber durch
| |
| Code: |
#!/bin/bash
access_token='ich bin ein token'
curl -X POST -v -H "Authorization: Bearer $access_token" localhost:8080
access_token="ich bin ' ' token"
curl -X POST -v -H "Authorization: Bearer $access_token" localhost:8080
|
|
| |
| Code: |
# ...
Authorization: Bearer ich bin ein token
# ...
Authorization: Bearer ich bin ' ' token
|
|
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von FuSL am 05.04.2020 13:53]
|
|
|
|
|
|
|
|
|
Wenn ein Invalides Header Feld das Problem wäre würde er einen 400 Bad Request zurück bekommen oder das Felder einfach ignoriert werden.
In diesem Fall bricht das Quoting so dass der Token dann von Curl als Host und nicht mehr als Teil des Headers interpretiert wird. Afaik ist der Space nach dem Colon nicht mandatory heißt aber nicht dass auch jeder Endpunkt damit klarkommt  würd ich hier aber wie gesagt Ausschließen da das Fehlverhalten ein anderes wäre.
|
|
|
|
|
|
|
|
|
|
|
Stimmt, da war ja noch 'n 401. /o\
Aber gut, zumindest bei mir™ klappt's mit stark vereinfachtem Quoting [siehe edits] ja ganz entspannt, also ist bash bei mir entweder magisch, oder ich weiß auch nicht 
|
|
|
|
|
|
|
|
|
|
|
|
Ah ich seh grade bash betreibt da word splitting durch das Leerzeichen und fügt selbst die '' und die Felder ein..
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hypnotica
| | Zitat von Interruptor
Kann ich jetzt so nicht bestätigen, bei mir mir connecten sich alle Geräte (Android, LinuxMint, Windows 7, Windows 10) mit ESP Devices die im HotSpot Modus sind.
Ich hatte allerdings des öfteren mal Probleme mit anfälligeren ESPs bei denen ich mehrfach den Speicher löschen musste, bis darauf anständig wieder ein anderer Sketch lief.
Gibt's das Binary File von der Uhr zum flashen irgendwo zum Download?
| |
Leider nein, die machen da ein ziemliches Geheimnis drum.
| |
Kann man den ESP denn tauschen? Man kann ja mit esptool (python) zb das Ding auslesen und testweise in einen anderen flashen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von NucUlaR
Ah ich seh grade bash betreibt da word splitting durch das Leerzeichen und fügt selbst die '' und die Felder ein..
| |
Genau das ist das Problem.
|
|
|
|
|
|
|
|
|
|
|
Entweder ich denke gerade völligen Unsinn zusammen, oder ich verstehe nicht, wo es nun genau hängen soll, oder eben nicht mit splitting & co.
möglichst nah am original:
| |
| Code: |
#!/bin/bash
access_token="much_token_very_auth ' ' blah"
sessionId=1337
requestId=2269
api_prefix_complete=localhost:8080
curl -X POST -v \
-H "Accept: application/json" \
-H "Authorization: Bearer $access_token" \
-H "x-http-request-info: {\"clientRequestId\": {\"sessionId\": \"$sessionId\", \"requestId\": \"$requestId\"}}" \
-H "Content-Type: application/json" \
$api_prefix_complete/session/clients/user/v1/sessions
|
|
curl-output:
| |
| Code: |
* Trying 127.0.0.1:8080...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> POST /session/clients/user/v1/sessions HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.69.1
> Accept: application/json
> Authorization: Bearer much_token_very_auth ' ' blah
> x-http-request-info: {"clientRequestId": {"sessionId": "1337", "requestId": "2269"}}
> Content-Type: application/json
|
|
andere Seite (nc):
| |
| Code: |
POST /session/clients/user/v1/sessions HTTP/1.1
Host: localhost:8080
User-Agent: curl/7.69.1
Accept: application/json
Authorization: Bearer much_token_very_auth ' ' blah
x-http-request-info: {"clientRequestId": {"sessionId": "1337", "requestId": "2269"}}
Content-Type: application/json
|
|
geht doch 
|
|
|
|
|
|
|
|
|
|
|
Jep, gerade getestet. Mit deinem Code geht es. Auch, wenn ich res_22=$(deinCode) mache. Geil.
Vermutlich war das Problem "Fehlermaskierung"; dadurch, dass ich weiter oben erst mitten im Debuggen das Problem mit access_token=$(echo response | jq -r .access_token) entdeckt hatte (dort hat -r gefehlt). Das sorgte dafür, dass schon um den Token-String herum " waren. Das habe ich unbewusst versucht, mit dem Code, den wir hier besprochen haben, zu mitigieren und nachdem mir der Fehler aufgefallen wir, bin ich nicht noch einmal, so wie du es hier gerade gezeigt hast, zurück zu Square One gegangen, sondern habe mit meinen Verrenkungen, die ich bis dahin hatte, weitergemacht.
Merci, ihr beiden!
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Vorhang am 05.04.2020 17:23]
|
|
|
|
|
|
|
|
|
Ah. OK, ich dachte schon, ich hätte selbst ein Brett vorm Kopf.
Das passiert mir selbst beim Fehlersuchen auch viel zu oft, dass man dann (aus welchen Gründen auch immer) beim "ersten schnellen Fix-Versuch" irgendwas kaputt macht, dann aber in irgend 'ne andere Richtung sucht, vielleicht schon das Ursprungsproblem behoben hat aber dann trotzdem alles schrecklich ist /o\
Und Shell-/String-Escaperei ist manchmal echt eklig. Ich hab schon mindestens >9000 Jahre Lebenszeit mit sed-Regexes und der Shell verloren, glaube ich /o\
Aber schön, dass es nun klappt 
|
|
|
|
|
|
|
|
|
|
|
|
Auf jeden Fall. Und da arbeite ich hier schon mit git und whatnot. Man müsste nur einmal nach dem Finden eines Bugs quasi mechanisch "git reset --hard" machen, um sowas auszuschließen. Das wäre easy as fuck. Aber dazu bräuchte man ja Diszipliiiiin.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Vorhang am 05.04.2020 18:12]
|
|
|
|
|
|
|
|
|
Mir fehlt offenbar Basiswissen. Nehmen wir an, ich habe zwei Server. Auf einem läuft eine Webanwendung, auf der anderen liegt die DB der Webapplikation. Wenn ich jetzt Transportverschlüsselung mit TLS zwischen App- und DB-Server machen möchte: Muss der DB-Server dann als Voraussetzung unter einer Domain errechbar sein? Anders gefragt: Kann man TLS auch auf Basis einer festen IP und nicht auf Basis eines Domainnamens einrichten?
// Es spricht eine PHP-Anwendung, die mysqli nutzt, mit einem MySQL-Server.
// Meinst du mit "OV" "selbstsignierte Zertifikate"?
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Vorhang am 07.04.2020 10:01]
|
|
|
|
|
|
|
|
|
|
Ich glaube nur OV Zertifikate.
|
|
|
|
|
|
|
|
|
|
|
Du musst den jeweiligen Serven zumindest irgendwie klarmachen, dass sie dem anderen Cert vertrauen sollen; normalerweise läuft das eben so, dass du für 'ne Domain durch irgendeine übergestellte vertrauenswürdige Authority bestätigt ein Cert signiert/bestätigt bekommst, und OS/Browser dem dadurch vertrauen.
Hierbei geht das nicht so einfach, ich glaube™, dass dir kaum ein Anbieter 'ne IP als common name(?) bestätigt, falls dass überhaupt noch gemacht wird/werden darf – theoretisch ist's aber möglich (gewesen?).
Hier müsstest du also wahrscheinlich was selbst signiertes nehmen und dem dann explizit vertrauen.
Ooooooooder du machst es einfach nicht über TLS, sondern z.B. über Wireguard o.ä. ^^
/edit
Oha: https://sectigostore.com/page/ssl-certificate-for-ip-address/
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von FuSL am 07.04.2020 10:49]
|
|
|
|
|
|
|
|
|
Aw shit. Die IPs gehören bei uns dem RZ-Betreiber. Das fällt also raus. Also geht OV nicht. Mist.
Dann wirds wohl doch 'ne eigene Domain für das Backend werden müssen. 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Vorhang am 07.04.2020 12:30]
|
|
|
|
|
|
|
|
|
Ich weis nicht was ihr genau für Software einsetzt ich würde an eurer Stelle versuchen zu Vermeiden die DB öffentlich erreichbar zu machen. Wenn die Server im gleichen RZ stehen kann der RZ betreiber sicher dafür sorgen, dass die über LAN miteinander reden dürfen.
Selbst signierte Zertifikate sind per se nicht unsicherer als solche die von einer öffentlichen CA signiert wurden nur wird ihnen einfach pauschal erst mal nicht getraut. Du kannst das ändern in dem du dem Client sagst er soll explizit dem von dir erstellten Zertifikat trauen oder allen Zertifikaten die von deiner eigenen RootCA signiert wurden, solange du nicht pauschal allen self signed zertifikaten traust wird das ganze nicht weniger sicher als mit einer öffentlichen CA.
Solltest du dich dennoch für einen Namen entscheiden für den du das Zertifikat austellen willst noch der Hinweis dass du bei Letsencrypt über DNS Validation (sofern dein DNS Provider unterstützt wird) für beliebige (sub)domains Zertifikate austellen kannst ohne, dass dafür der Name Tatsächlich öffentlich aufgelöst werden kann.
|
|
|
|
|
|
|
|
|
|
|
Danke für deine Rückmeldung. Es ist so, dass ich gerade dabei bin, für ein Uniprojekt unsere Webapplikation dazu zu bewegen, sich automatisiert in einem georedundanten "Cluster" hochverfügbar installieren zu lassen. Wir werden das bei Hetzner machen, weil die gerade mit der hcloud-API (https://docs.hetzner.cloud/) etwas ziemlich Cooles an den Start gebracht haben. (Wir können Gcloud und AWS aufgrund der Kundenanforderungen nicht nutzen; DSGVO-Thema). Auf dem folgende Screenshot siehst du das momentane Setup aus Applikationssicht (ohne Monitoring, SSH, etc.).*
Du siehst, dass direkt nach der ersten virtuellen IP, die bei Bedarf umhergeschubst wird (via deren API; dahinter ist wohl eine MQTT-Queue und dann wird einfach mit BGP das Routing aktualisiert), alles in einem eigenen Subnetz - auch über die RZs an unterschiedlichen Standorten hinweg - bei Hetzner gerouted wird. Deswegen müssen die Zertifikate selfsigned sein, weil die Server nicht mit draußen reden können sollen. Hetzner schließt aber nicht aus, dass die eingentlich von denen nochmal eingepackten Pakete im Subnetz nicht doch mal jemand zu Gesicht bekommt (wenn bspw. ein Mitarbeiter dicke Finger hat, oder so).
Also werde ich mal versuchen, wie ihr vorgeschlagen habt, den App-Servern quasi explizit zu sagen, dass den DB-Server-Zertifikaten getraut werden darf. VPN wollte ich vermeiden, weil da der Overhead mmn nochmal größer wäre, als bei bloßem TLS, lasse ich aber gerne eines Besseren belehren. Die beiden App-Server bekommen jeweils ein Let's Encrypt-Zertifkat. Das geht bei denen auch schön unattended zu installieren und validieren.
Am Ende gibt's dann in jedem RZ zusätzlich noch jeweils einen Jumphost. Die beiden Kisten sind die einzigen, über die man via SSH in das Netz reinkommt. Und dort auch nur mit minimalen Userprivileges und auch ohne als User bei den sudoern bei zu sein. Alle Server nehmen nur von diesen beiden Kisten SSH-Verbindungen an - auch nur mit Usern ohne Privs.
* Ja, ich weiß, dass man für Galera eigentlich mindestens drei Server haben will, um zumindest einen Arbiter dabei zu haben. Ist bei uns aber nicht nötig, da es zwar ein Master-Master-Setup ist, jedoch immer nur auf einen DB-Server schreibend _und_ lesend zugegriffen wird. Der andere ist ledlich Hot-Standby und kann auch erst ganz praktisch von dem dann anderen Appserver angesprochen werden, wenn die DB-VIP ebenfalls rerouted wurde. Dann ist aber auch die Verbindung zu dem alten DB-Server schlicht nicht mehr möglich. Nein, wir wollen keinen Hickhack mit keepalived, haproxy und sqlproxy anfangen. Diese VIPs werden zusammen mit der Hetzner API georedundant zwischen den beiden RZs vorgehalten und die RZs verfügen über mehrere Wege zueinander. Wenn das komplett ausfällt, nehm ich auch gerne in Kauf, dass unser Kram down ist. KISS, weil kleine Bude und soll möglichst einfach für alle zu verstehen sein.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Vorhang am 07.04.2020 20:00]
|
|
|
|
|
|
|
|
|
Kleine Frage zu zsh:
Wenn ich "sudo !!" mache dann schreibt mir die shell den vorigen Befehl nochmal inkl. sudo nach stdout.
Ich hätte gerne, dass dieser Befehl direkt mit sudo ausgeführt wird ohne nochmal Enter zu drücken.
Find leider nicht wirklich was dazu :/
|
|
|
|
|
|
|
|
|
|
|
Hab's jetzt nicht selbst ausprobiert und auch keine passende Lösung für sudo !! gefunden, aber eine Alternative (SO):
| | I use zsh instead of bash and have this in my ~/.zshrc, so pressing Alt+S inserts sudo at the beginning of the command line:
| |
| Code: |
insert_sudo () { zle beginning-of-line; zle -U "sudo " }
zle -N insert-sudo insert_sudo
bindkey "^[s" insert-sudo |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von b4ckspin
Kleine Frage zu zsh:
Wenn ich "sudo !!" mache dann schreibt mir die shell den vorigen Befehl nochmal inkl. sudo nach stdout.
Ich hätte gerne, dass dieser Befehl direkt mit sudo ausgeführt wird ohne nochmal Enter zu drücken.
Find leider nicht wirklich was dazu :/
| |
Ich mag https://github.com/ohmyzsh/ohmyzsh/blob/master/plugins/sudo/sudo.plugin.zsh (geht auch ohne oh-my-zsh-monster); zwei mal escape drücken macht aus dem aktuellen oder letztausgeführten befehl sudo $whatever (oder entfernt sudo), und wenn $editor am anfang steht, dann sudoedit. Aber Enter musst du trotzdem noch drücken – kannst das script aber sicherlich anpassen ^^
Ggf. auch in die richtige Richtung:
https://github.com/nvbn/thefuck – der "instant mode" insbesondere ^^
--
@Vorhang: Bei sowas würde ich glaube ich eher mit VPN ansetzen (Wireguard und so), oder ggf. gleich schauen, ob man da Kubernetes oder sowas draufwirft – ich meine™, dass da die Übertragung, wenn korrekt konfiguriert, auch ordentlich abgesichert getunnelt wird.
Beides ist aber möglicherweise unter den Hetzner-RZ-Subnetz-Bedingungen wieder schwierig.
|
|
|
|
|
|
|
|
|
|
|
Eigentlich wollte ich ja selbst was fragen /o\
Überlegung: Applikation, Zugriff über Browser. Hierbei sollen bestimmte Daten niemals unverschlüsselt auf dem Server landen, sondern mittels Public-Key-Kryptographie verschlüsselt werden (da potenziell mehrere Nutzer auf Daten Zugriff haben sollen, dabei aber eben wirklich nur auf Verschlüsselungsebene "zugelassene"). Nett wäre natürlich, reproduzierbar beim Login / mit zweitem Passwort die Schlüssel beim Nutzer zu (re-)generieren, realistischer ist aber wahrscheinlich die Lösung, dass die Private Keys verschlüsselt auf dem Server liegen, und nur mit korrektem PW (und verm. PBKDF* o.ä.) lokal beim Nutzer entschlüsselt werden – quasi wie bei Protonmail & Co.
Um natürlich möglichst wenig selbst zu machen (weil da ja das Verkackungspotenzial besonders immens ist), wäre eine vorgefertigte Lösung toll. Einzig finden konnte ich (aktuell, maintained und reviewed) nur openpgp.js (von Protonmail, mittlerweile) – damit ginge das sicherlich, meine Überlegung war nur, da es ja relativ Mail-Zentriert ist, ob es nicht bessere Lösungen ohne "OpenPGP"-Altlasten gibt, oder ob das trotzdem die beste Lösung wäre; mit ECC & Co. sollte das ja trotzdem alles recht schmal bleiben, und man hätte zumindest einen ausreichend "etablierten" Unterbau.
|
|
|
|
|
|
|
|
|
|
|
Ich möchte in der Raspbian-Kommandozeile mehrere Zip-Archive nacheinander entpacken, mit nur einem Befehl.
Die Archive bestehen jeweils aus mehreren Dateien und sehen wie folgt aus:
| |
| Code: |
DateinameXY.Index01.part1.rar
DateinameXY.Index01.part2.rar
DateinameXY.Index01.part3.rar
DateinameXY.Index02.part1.rar
DateinameXY.Index02.part2.rar
DateinameXY.Index02.part3.rar
DateinameXY.Index03.part1.rar
DateinameXY.Index03.part2.rar
DateinameXY.Index03.part3.rar
|
|
Aktuell mach ich immer für jedes Archiv:
| |
| Code: |
7z e DateinameXY.Index01.part1.rar
für das nächste:
7z e DateinameXY.Index02.part1.rar
für das übernächste:
7z e DateinameXY.Index03.part1.rar |
|
Funktioniert auch alles, ist nur sehr unpraktisch. Wie kann ich das auf einmal machen?
| |
| Code: |
7z e Datei1 Datei2 Datei3 |
|
funktioniert schonmal nicht.
|
|
|
|
|
|
|
|
|
|
|
Gehen wildcards oder RegExp?
7z e DateinameXY.Index03.part*.rar
oder sowas wie
7z e DateinameXY\.Index03\.part\d.rar
?
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von derSenner am 08.04.2020 22:23]
|
|
|
|
|
|
|
|
|
Gute Idee.
Ich hatte nur Angst, dass er dann ein Archiv so oft entpackt, wie es Blöcke hat.
|
|
|
|
|
|
|
|
|
|
|
|
Was soll schon passieren™.
|
|
|
|
|
|
|
|
|
|
|
|
for f in Datei*.rar; do 7z e $f; done
|
|
|
|
|
|
|
|
|
|
|
Ansonsten halt
| |
| Code: |
#!/bin/bash
for file in *.rar
do
7z e $file
done |
|
// Tja.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von derSenner am 08.04.2020 22:29]
|
|
|
|
|
|
|
|
|
Mit * als Wildcard:
no files to process
everything is okay
|
|
|
|
|
|
|
|
|
|
|
|
Kann mein 4K-TV von Medion echt nur 29 Hz haben und bedeutet das "29 FPS max."?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Thema: Lnformatiker helfen PC Neulingen ( EigentlichTM müsste das funktionieren. ) |
