[Sturmovik]

Moin,

ich sitz grad an dem Problem, dass ich eine REST-API mit Daten füttern will, aus der Powershell heraus.

Da Invoke-WebRequest mit dem https-Zertifikat rumspinnt (selbsterstelltes Zertifikat, wird aufs erbrechen nicht von dem Server importiert), und ich die Syntax von dem .net-Webclient absolut nicht raffe, hab ich mir ne aktuelle Version von cUrl gezogen (http://winampplugins.co.uk/curl/ die 64bit-Version)

Abfragen über die API funktionieren, es kommt sauberes JSON an, ConvertFrom-Json kapiert die Struktur auch.
Post-Requests schlagen aber immer fehl, entweder taucht da in dem JSON-String plötzlich ein Zeilenumbruch (\n) auf oder ein Minus mittendrin wird von cUrl als Parameter interpretiert.

Mein Verdacht: falsches Quoting (Ich bin das Verhalten der Bash gewöhnt, PS und cmd sind für mich noch eher Neuland) oder ich muss irgendwelche Zeichen escapen.

Hier mein Aufruf:

.\curl.exe -k -s -u user:passwd -H 'Accept: application/json' -X POST 'https://server:port/v1/actions/process-check-result?service=xxxx!yyy'  -d '{ "exit_status": 0, "plugin_output": "looks good", "performance_data": [ "dirsize=123456c;223456;323456;0;500000" ],"check_source": "filer.domain.tld" }'

Ergebnis:
{"error":400.0,"status":"Invalid request body: Error: lexical error: invalid char in json text.\n { 'exit_status': 0, 'plugin_ou\n (right her
e) ------^\n\n"}

Bei einem anderen Test mit dem Inhalt "plugin_output": "OK - bla" wurde das "-" als Parameter interpretiert.

Der gleiche Aufruf unter Linux funktioniert wunderbar.

Wer kann mir auf die Sprünge helfen?

edit: Ich hab mir jetzt mal einen Hashtable in PS erzeut und dann mit Convertto-Json übergeben, der gleiche Schei*
Was hier allerdings auffällt: nach exakt 30 Zeichen kommt der fehlerhafte Char

---

Edit2: Das hat sich wohl erledigt. Wenn ich innerhalb des JSON-Strings alle doppelten Ausführungszeichen mit nem Backslash escape, dann funktionierts. Nur kann ich jetzt wohl kein Powershell-Objekt mittels Convertto-Json da reinschieben, das macht den Rest von dem Script komplizierter. :|
Für das letzte "Teilproblem" sind also immer noch Anregungen willkommen

Dieser Beitrag wurde von Sturmovik bearbeitet: 18. August 2016 - 20:11

[RalphS]

- Invoke-WebRequest schreibt den heruntergeladenen Stream in eine Variable ($var =Invoke-WebRequest ... ).

- PS interpretiert alles mit Minus als eigenen Parameter. Wenn Du also cURL von PS aus aufrufen willst, muß jeder einzelne Parameter als String übergeben werden. Also zB

curl '-O' 'output' 'http://url'

.

Sauberer übrigens als Start-Process -FilePath 'C:\path\to\curl.exe' -ArgumentList <ArgumentList>, wobei <ArgumentList entweder ein String ('-O out http://....') oder eine Liste (wie vorstehend, aber kommagetrennt) sein kann.

- Irgendein Grund, daß Du den JSON-String so übergibst? Mit PS könntest Du auch ein Objekt erstellen und das dann durch ConvertTo-Json filtern und so den JSON-String generieren lassen.

Dieser Beitrag wurde von RalphS bearbeitet: 17. August 2016 - 19:36

[Sturmovik]

 Zitat (RalphS: 17. August 2016 - 19:36)

- Invoke-WebRequest schreibt den heruntergeladenen Stream in eine Variable ($var =Invoke-WebRequest ... ).

Wie schon gesagt, ich hab mit Invoke-WebRequest nur Probleme wegen dem Serverzertifikat. Ich kann das noch so oft in den Windows-Zertifikatsspeicher importieren, die Maschine raffts nicht.
Deswegen hab ich da schon bei den simplen Abfragen aufgegeben und erstmal den Webclient ausprobiert, aber hier ist mir die Syntax zu grützig. (PS find ich schon affig genug)
Ich weiß nicht, ob MS erwartet, dass ein Powershellnutzender Sysadmin gleichzeitig .net/C# Entwickler ist und diese Art von Syntax fließend spricht.

Also nutze ich lieber ein Programm, was funktioniert und verständlich dokumentiert ist => cURL.

Zitat

- PS interpretiert alles mit Minus als eigenen Parameter. Wenn Du also cURL von PS aus aufrufen willst, muß jeder einzelne Parameter als String übergeben werden. Also zB

curl '-O' 'output' 'http://url'

.

Hm, das hat interessanterweise auch so ganz gut geklappt, eben bis zum Json-Teil

Zitat

Sauberer übrigens als Start-Process -FilePath 'C:\path\to\curl.exe' -ArgumentList <ArgumentList>, wobei <ArgumentList entweder ein String ('-O out http://....') oder eine Liste (wie vorstehend, aber kommagetrennt) sein kann.

Das schau ich mir morgen mal genauer an

Zitat

- Irgendein Grund, daß Du den JSON-String so übergibst? Mit PS könntest Du auch ein Objekt erstellen und das dann durch ConvertTo-Json filtern und so den JSON-String generieren lassen.

Siehe Edit1: Ich hab mir nen Hashtable generiert in der Art

$hash = @{ 'key ' = 'wert'; 'nochnkey' = 'nochwert' } 

und durch Convertto-json geschoben, kein Erfolg. PS macht beim Konvertieren Doublequotes rein, die dann beim cURL-Aufruf anscheinend weggeworfen werden.
Letztlich ist son Hash doch mit nem Objekt vergleichbar oder?
(Der geneigte Leser merkt sicher, dass ich mit PS noch nicht allzu warm bin)


Zweiter Grund: Wir ham da noch ein paar Eisen, die ne Powershell < v3 laufen haben, da gibts noch kein JSON. Nur deswegen will ich da kein PS-Upgrade machen und eventuell ältere Scripte zerschießen.



Was am Ende rauskommen soll:
Ein Script (bzw. ein CMD-Let) grast das Filesystem ab und misst die Größe verschiedener Verzeichnisse, entweder per COM oder über Missbrauch von Robocopy, falls die Pfadlängen größer 248 Zeichen sind.
Das ganze funktioniert schon prima und spuckt das ganze als PS-Objekte raus.
Das soll dann über die API ins Monitoringsystem gepumpt werden.
Dazu muss ich das zurückgegebene Objekt ein bischen umbauen, dass wollt ich erst morgen angehen, vorher wollt ich erstmal den API-Call an sich testen.

Aber ich seh schon, dass ich mich heute noch im Firmennetz anmelden werde und solange weitermache, bis ich ruhig schlafen kann

Dieser Beitrag wurde von Sturmovik bearbeitet: 17. August 2016 - 20:10

[RalphS]

Mh.

Was das JSON-Objekt angeht, das macht PS schon richtig. Die Doublequotes gehören da zur JSON-Syntax, von wegen "Key":value und wenn Value ein String ist, muß das auch in Doublequotes.

Denke, das beißt sich mit der Übergabe an cURL und Du schreibst ja auch, wenn Du die durch nen Filter schiebst, daß es dann paßt.

Problem was PS tatsächlich hat ist die Zusammenarbeit mit "normalen" Applikationen. Denn PS will ja Objekte lesen und schreiben und "normale" Applikationen geben aber keine Objektdaten aus, logischerweise.

Was "ginge" wäre daß Du ein kleines Wrappermodul baust (oder, soweit verfügbar, irgendwo runterlädst); einfach eine kleine .ps1 Datei die curl.exe aufruft und eingegebene -PSArgumente auf CurlArgumente mappt und entsprechend (so gewünscht) auch Ausgabe(elemente) auf PS-Objektfelder mappt, damit die dann weiter verarbeitet werden können.

Was das Zertifikat angeht, mh. Gute Frage, ohne da ein Auge drauf zu haben. Wenn ich davon ausgehen darf daß Du das in den Computerkontext gesteckt hast und das auch ordentlich unter Vertrauenswürdige Etcs steckt, wäre meine nächste Vermutung, daß es eine Zertifikatskette gibt und Windows diese aber nicht nachverfolgen kann. Oder anders gesagt, hast Du auch dasjenige Zertifikat der CA installiert, die das von Dir bewußte Zertifikat ausgestellt hat? Bzw alle darüber? Ein Blick in den Zertifikatsspeicher gibt da leider nicht immer Auskunft, da steht dann das Zertifikat ganz oben und man soll riechen daß es da noch eine übergeordnete CA gab.
Wenn Du das natürlich in den Benutzerzertifikatsspeicher gepackt hast und das aber ein anderer Benutzerkontext war


Ansonsten scheinst Du aber recht zu haben. PS kann wahnsinnig viel, aber wenn man nicht an C# oder dergleichen ran will (oder kann) werden einem Mauern in den Weg gestellt. PS ist da, um das mal so zu formulieren, eher eine Art Interface; und wenn es noch kein Modul gibt welches Windowsfunktion X auf PS-CMDlet Y abbildet dann kann man hundertmal wissen daß es gehen "würde" nur wenn man halt kein C# will oder kann bleibt einem das verwehrt.

[Sturmovik]

Grad nochmal versucht, das mit Invoke-Webrequest zu machen.
ca.crt importiert, server.crt importiert (Windows hats sogar als Gültig bezeichnet)

Invoke-WebRequest -uri $url ergibt:

Invoke-WebRequest : The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
At line:1 char:1
+ Invoke-WebRequest -uri $url
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

Am anderen Ende steht im Log:

[2016-08-17 22:06:49 +0200] warning/TlsStream: TLS stream was disconnected.
[2016-08-17 22:06:49 +0200] critical/ApiListener: Client TLS handshake failed
Context:
        (0) Handling new API client connection

Irgendwo aufm Stackoverflow hab ich was gefunden, dass Invoke-Webrequest standardmäßig nur TLS1.0 spricht und man deswegen den Webclient nutzen sollte. Da kann man das auf TLS1.2 umschalten.
Das haben meine gestrigen Versuche auch bestätigt. So wies aussieht weigert sich meine API dagegen, mit gammligen SSL-Varianten zu arbeiten.
Nur, wie gesagt, die Webclient-Syntax ist mir zu hochgestochen, da seh ich gar nicht durch.

---

Grad gefunden: http://stackoverflow.com/a/36266139
Kurz: Powershell 4.0 kann kein TLS>1.0
Peinlich. Also weiter mit cURL.

---

Sorry für den Rant, aber wenn ich sowas lese:
"Powershell's Invoke-WebRequest does wait for a 401 response before sending the credentials"
und mir dann das Verfahren zum Encoden der Credentials angucke, dann wird mir ehrlich gesagt schlecht. Eine Shell ist eigentlich dafür gedacht, effizient arbeiten zu können, aber PS macht irgendwie alles unnötig kompliziert.

Dieser Beitrag wurde von Sturmovik bearbeitet: 17. August 2016 - 21:30

[RalphS]

*kopfschüttel*

Die 5 ist ja raus (WMF 5.0). Nützt Dir aber sicher nicht viel, wenn das auf vielen Maschinen laufen soll; besonders wenn da noch v3 drauf läuft und das nicht mal eben aktualisiert werden kann.

Wobei ich da fast der Meinung bin daß Du da mit Batch besser dastehn könntest. Dann mußt Du Dich nämlich nicht mit den PS-gegen-den-Rest-der-Welt-Problemen rumärgern.

[Sturmovik]

Batch hat jetzt schon verloren. Mit der Syntax komm ich noch weniger klar.
Außerdem will ich mal bischen PS lernen, sonst hätt ich einfach kackendreist Perl auf die Kisten installiert.

Ich hab schonmal versucht diese Verzeichnisgrößenausmesserei zu machen, ich in VBS, ein Kollege in Batch, aber wir sind immer an ACLs oder zu langen Pfadnamen gescheitert. Oder an der Laufzeit.
Wir reden hier von nem Windows-Filecluster mit ~20TB und ich brauchstündliche Ergebnisse damit die Verlaufsdaten sauber aufgezeichnet werden.

Aktuell fahr ich die Quick and dirty Brechstangenlösung (achtung Kinners, nicht zuhause nachmachen, sonst gibts Haue vom Netzwerkadmin):
Nachts werden die Shares in Linux gemounted, dann rennt 'du' drüber und schreibt alles in ne csv, die dann stündlich gelesen wird.
Vorteil: du stört sich nicht an ACLs (dann is das Verzeichnis halt 0Byte groß) und rennt weiter (die VBS-Lösung ist da immer hängengeblieben) und Pfadlängen sind wumpe.
Doof ist halt der Netzwerktraffic, daher nur einmal nachts.

Deswegen hab ich mich die Woche mal aufgerafft, das neu zu machen.
Erster Ansatz war

Get-ChildItem | Measure-Object -Sum Length | Select-Object Count, Sum

Aber hier schlägt das 255-Zeichen-limit zu. Willkommen in 1985.

Jetzt nutze ich das Ding hier: http://www.powershel..._Blazingly_Fast
Funktioniert, bleibt nicht an ACLs kleben und weicht bei zu langen Pfaden (also eigentlich immer) auf Robocopy aus. Und es braucht nur ~5min pro Terabyte, beim zweiten Lauf dank Index sogar noch schneller.

Ergo: Ich mach das ganze in PS. Auch wenn ich am Ende in der Klappse lande.

Dieser Beitrag wurde von Sturmovik bearbeitet: 17. August 2016 - 21:54

[RalphS]

20TB so schnell wie möglich, mh.

Würd ich persönlich schauen das DB-gestützt zu machen. Egal ob als Flatfile oder als zB sqlite oder nochwas anderes. Besonders dann, wenn das viele Verzeichniseinträge sind (bringt nicht so viel, wenn das sinngemäß 20 je 1TB große Dateien sind).

Je nach Umfang und ggf Leistungsfähigkeit auch per ConvertTo/From-XML. Oder JSON.

Dann könntest Du:

- Per Get-ChildItem -Recurse eine Baseline erstellen, zB mit Pfad als Schlüssel und LastWriteTime als Attributwert. Das Ergebnis davon wär eine Liste, entweder von Verzeichnissen oder von Dateien, je nach Wunsch.

- Stündlich ein Get-ChildItem -Recurse | ? {$_.Path -Eq $csv.Path -And $_.LastWriteTime > $csv.LastWriteTime} basteln und hättest so eine Teilmenge aller Verzeichnisse - nämlich derer, die sich geändert haben. Evtl noch dafür sorgen, daß neu angelegte Verzeichnisse mit berücksichtigt werden.

- Dann müßtest Du das nur noch abgleichen mit der Baseline und immer dann wenn notwendig (oder gewollt) auf dessen Basis eine neue Baseline generieren.


- Was VBS angeht, so sollte dieses mit Try/Catch klarkommen. Falls nicht, Jscript; gibt paar Dinge die hier gehen und da nicht, aber müßte grad passen ob Try/Catch dazugehört oder nicht.

- Ansonsten - bilde ich mir ein - ist Get-ChildItem zumindest rekursiv in der Lage, bis >255 Zeichen runterzukommen. Dann müßtest Du natürlich hinterher alle Ergebnisse zusammenzählen.

Dieser Beitrag wurde von RalphS bearbeitet: 17. August 2016 - 22:49

[Sturmovik]

War irgendwie klar, dass du ne DB ins Spiel bringst

Wie schon geschrieben, an beiden Enden ist alles fertig, das Vermessen der Verzeichnisse funzt, die Datenbank hinter der API wartet auf Futter.
Ich muss den Kram nur noch zusammenlöten. Aktuell bin ich soweit, dass die Zuordnung klappt, jetzt fehlt nur noch der JSON-Kram und hier muss nur eins der Felder variabel werden. Und grade eben hab ich noch das Escapen per Backtick entdeckt, damit solltes klappen.

Nu aber erstmal ne Mütze Schlaf.
Bis morgen.

[RalphS]

Naja, das Problem ist halt, so wenig wie möglich angucken zu müssen; son Traversal dauert eine Weile. Besonders, wenn das nicht (mehr) im Cache zu finden ist.

Wenn's geht, ist es ja gut.

[Sturmovik]

Joa, schaumermal wie lange das am Ende wirklich dauert. Der scheint das Ganze ja zu indizieren oder zu cachen, so flott wies ab dem zweiten Durchgang geht.

Deine Idee mit der Baseline + Änderung schau ich mir jedenfalls auch noch an. Jetzt muss der Kram erstmal funktionabel werden.

[Sturmovik]

Sodele, nach ein paar Stunden mehr ?WTF? und Konsultation einiger Powershell-kundiger Kollegen, die am Ende genauso ratlos waren wie ich, hab ich ne Lösung.
Zur Erleuchtung von Leuten, die irgendwann mal vor nem ähnlichen Problem stehen, mal der komplette Geistesblitz:

Irgendwie hatte ich am Ende cURL im Verdacht, dass es irgendwie falsch überträgt.
Also zur Sicherheit den JSON-Teil in ne Textdatei gemeißelt und beim Aufruf auf die Datei verwiesen:

$json |Out-File json.txt
Start-Process -FilePath $curl -ArgumentList '-k','-s','-u', $creds, '-H "Accept: application/json"', '-X', 'POST', $url, '-d', '@json.txt'

Wieder wurden illegale Chars angemeckert.

Nun wurdes mir zu bunt und ich hab mir die Datei mal in Linux angeguckt:

cat -e /mnt/json.txt
M-^?M-~{^@^M^@$
^@"^@e^@x^@i^@t^@_^@c^@o^@d^@e^@"^@:^@ ^@0^@,^@^M^@$
^@"^@p^@l^@u^@g^@i^@n^@_^@o^@u^@t^@p^@u^@t^@"^@:^@ ^@1^@2^@3^@4^@5^@^M^@$
^@}^@^M^@$

Das ist alles andere als UTF-8 => wahrscheinlich mein Problem
Mit Encodingproblemen ist schließlich jeder geplagt, der in beiden Welten (Win/Unix) unterwegs ist.

Also nochmal:

$json |Out-File -Encoding utf8 json.txt

Wieder nix. Lustig aussehende illegale Chars direkt am Anfang: 

cat -e sagte: M-oM-;M-?'{"exit_code":0,"plugin_output":12345}'^M$

Die Lösung hab ich hier gefunden: http://stackoverflow...without-the-bom
Ich musste also nur noch das BOM loswerden

[System.IO.File]::WriteAllLines($file, $text)

Ergebnis: Saubere Datei, sauberer Input in die API.
Wieder mal ein winziges Problem, was massiv Zeit gefressen hat.

Jetz werd ich mal bei nem Bierchen schaun, wofür dieses bescheuerte BOM gut ist.

Dieser Beitrag wurde von Sturmovik bearbeitet: 18. August 2016 - 20:12

[RalphS]

BOM= Byte Order Mark. Sagt, ob BE oder LE. FFFE oder FEFF. Oder irgendwie so.

Für UTF8 eigentlich uninteressant, gibts aber als "Kompatibilität", weil alle anderen Codierungstypen von Unicode den BOM mitbringen.

Wenn ich mir die Ausgabe von cat(1) so anschau geh ich mal davon aus daß das UTF16 war, mit MSB first, also BE.

Was mich grad bissel wundert. Normal schreibt Windows eigentlich LE. War mir zumindest so.

Dieser Beitrag wurde von RalphS bearbeitet: 18. August 2016 - 21:03

[Sturmovik]

Jap, das ist UTF-16. Damit hatte ich schon früher mal Ärger, weil das das Standardoutput von PS ist.
Nur hätte ich bei simplen Textfiles kein BOM erwartet. Sowas bin ich aus der unixoiden Welt nicht gewöhnt, da wird sauberer Text weggeschrieben.

Naja, jedenfalls bin ich um eine Erfahrung reicher und mein Stundenkonto ebenfalls
Wenn ich das morgen den Kollegen erzähle wirds sicher in paar Facepalms geben.

[RalphS]

Eh, UTF-Codierungen > 8 haben alle BOMs (weil klar sein muß, wie die Multibytestrings zu interpretieren sind), und Unicode *sind* Textdateien.

UTF8 kennt das nicht, da gibt kein UTF8BE oder LE, was den BOM überflüssig macht. Aber es gibt halt auch so ein paar Honks, die UTF8 ungefragt mit BOM schreiben und dann kommt halt son Käse raus wie Du weiter oben meintest.

Standard ist, zumindest UTF8 betreffend, "BOM-frei".