Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Pujdu proti proudu.
Pokud mam takovou konfiguraci a hw raid mi to podporuje pak nevidim jediny duvod proc se morit se ZFS. Udelal bych raid 5 plus mirror (pokud bych nechtel spare), lvm + fs dle meho vyberu a jdu dom. Snapshoty si resim na kvm/proxmoxu. ZFS je fajn pokud nemam slusny raid. Znackovej raid karty nejsou vubec zle, napriklad hpeckova smart array maji genezi snad 30 let jeste z dob compaqu a jsou to spolehlive karty, s vicemene stejnymi tooly a filosofii. Dell na tom bude imo podobne (nemam zkusenost) - zkus pohledat po forech.
on je rozdíl v provozu, pokud mám raid 5+0 (ať už SW nebo HW), tak největší problém je používání v degraded stavu, prostě to musím nejprve obnovit a obnova u 5 trvá snad ze všech možností nejdéle.
Skvělé na zfs je schopnost ověřit stav na disku a případně chyby opravit, to u jiných řešení není tak běžné.
Pokud jde o řešení uložiště, hlavní rozhodování by mělo být podle toho, jak se to chová v případě problémů a ne když vše funguje jak má, pak není skoro co porovnávat, že?
Také spravuji servery, které 20+ let fungují nad jediným diskem a běží stabilně, ale přece na základě toho nebudu říkat, že raid je k ničemu. Stejně tak mám pod rukama clustery s tisíci disky, kde každý týden se nějaký disk mění, z toho ale také nemohu vyvozovat, že disky jsou k ničemu a bez raidu si ani nevrznu.
HW Raid skryje před ZFS cenná data o chování disků a přidává falešné flushe, tj. zvyšuje se riziko ztráty dat.
Qemu a jeho qcow sice poskytuje podobné funkce pokud jde o snapshoty, ale jeho stabilita a rychlost jsou naprosto tristní.
. Bohuzel muj mozek ma zafizovan vzorec “deti >> prace”, takze pri sebemensim audio sumu pripominajici plac ci detskou nelibost je moje soustredeni v haji. .
Vypadá to na nějaký problém na straně Fakturoidu, protože to invalid_client a 401 hlásí i když je dotaz vytvořen přesně podle dokumentace nebo podle toho, jak by ho vytvořila jejich oficiální PHP knihovna.
- resp. tipuju ze v dokumentaci neco chybi
{
"access_token": "26e53aa3244b4c0aed56cb54a0223484e9c4aea49b09a03e4600ba995811b6af06428afc223c4c0c",
"token_type": "Bearer",
"expires_in": 7200
}Before you start go to your Fakturoid account and download your Client ID and Client Secret from your user screen Settings → User account.
aaa jasny, nevsim sem si ze ten odkaz na ten POST v fakturuid dokumentaci pro cloent credentials je klikaci a je tam priklad kde maj bejt jaky hodnoty. Bohuzel ted nejsem u pocitace, zkuste to sam a kdyby to neslo pastnu to vecer
Tak jsem se v těch složenejch zavorkach, jednoduchejch a dvojitejch uvozovkach dočista ztratil, furt mi to píše hlášku o invalidním JSON :-/
Mohl bych vas tedy poprosit o ukazku spravneho formatovani? moc díky!
$ curl -X POST "https://app.fakturoid.cz/api/v3/oauth/token" -H "Content-Type: application/json" -H "Authorization: Basic bXVqY2xpZW50Om1vanNlY3JldAo=" -H "Accept: application/json" --data '{"grant_type": "client_credentials"}' -v
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 174.138.100.186...
* TCP_NODELAY set
* Connected to app.fakturoid.cz (174.138.100.186) port 443 (#0)
.
> POST /api/v3/oauth/token HTTP/1.1
> Host: app.fakturoid.cz
> User-Agent: curl/7.64.1
> Content-Type: application/json
> Authorization: Basic <BASE64 client_id:client:secret>
> Accept: application/json
> Content-Length: 36
>
* upload completely sent off: 36 out of 36 bytes
< HTTP/1.1 401 Unauthorized
.
.
* Connection #0 to host app.fakturoid.cz left intact
{"error":"invalid_client"}* Closing connection 0
Za ty prachy můžu mít dneska stejnou kapacitu na SSD...
Teď úplně nerozumím, o čem píšete. O kterém flow vlastně píšete. V případě Authorization Code Flow vám cUrl nepomůže, protože tam se musí uživatel v prohlížeči autentizovat a může to dělat třeba pomocí biometrie. Pokud píšete o Client Credentials Flow, tam zase nejsou dvě volání – hned prvním voláním dostanete Access Token. Redirect není proto, aby to mohl dělat backend – redirect je způsob, jakým se zpátky aplikaci, která zahájila přihlašování, předá řízení a hlavně jí předá údaje použitelné pro získání Access Tokenu.Proč tedy ze supportu píšou "link pro přesměrování bude VOLÁN FAKTUROIDEM během autorizace". Nebo tím myslí "javascriptem fakturoidu běžícím v browseru"?Na ten link bude Fakturoidem přesměrován prohlížeč uživatele.Navíc jsem už psal že u mě teď žádný browser nehraje roli, vše se děje pomocí scriptů. Třeba výpisy se tahají schedulovaně na pozadí... "user" (token) je stále stejný (dokud exepiruje). Prostě necháput tu roli browseru v tom procesu, přece se to musí dát udělat nějak "neiteraktivně".Role prohlížeče je ta, že přes něj se přihlásí uživatel Fakturoidu a udělí vám přístup. Na základě toho vám Fakturoid (při tom přesměrování) předá token, který budete používat pro přístup jménem toho uživatele.
Pokud to má být dlouhodobý přístup, možná ty tokeny budou dva – refresh token, který bude mít dlouho platnost a uživatel ho může zneplatnit, a ten pak v okamžiku komunikace vyměníte za access token, který bude mít platnost jen pár minut nebo možná hodin, a ten použijete teprve při samotném volání API.
Nainteraktivně to nejde, Fakturoid vám přece nemůže dát přístup k datům všech uživatelů. Musí tam být interakce uživatele, který schválí, že vaše aplikace má mít přístup k jeho údajům.
Neinteraktivne to pochopitelne v tomhle pripade take jde
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2025 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.