Příspěvky

3136

Vývoj / Re:Zjištění chyby při neúspěchu fwrite()

« kdy: 30. 06. 2018, 18:52:52 »

Je mi líto, ale žádné úžasné řešení asi neexistuje.

Funkce fwrite() je jen alias na php_stream_write() a ten nijak zvlášť neřeší důvod nezápisu.
Funkce file_put_contents() sice zařve, že se nepovedlo zapsat ale přičinu, "possibly out of free disk space" si bohapustě vycucá z prstu. Je fakt, že to bude nejčastější příčina, protože práva etc si zjistíš už při fopen().

Pokud skutečně dojde k chybě (což zjistíte testem, zda hodnota vrácená funkci fwrite() je FALSE), bude nejspíš kód chyby v posix_get_last_error(). PHPčkové fwrite je jenom obálka nad libc fwrite(), která vrací chybu v errno, a tuhle hodnotu vrací právě posix_get_last_error().

3137

Vývoj / Re:Zjištění chyby při neúspěchu fwrite()

« kdy: 30. 06. 2018, 17:38:23 »

Stále nechápu jak by mi mohl alespoň vzdáleně pomoci s mým problémem.

Váš problém je, že si myslíte, že došlo k chybě, ve skutečnosti k žádné chybě nejspíš nedošlo. Zda došlo k chybě otestujete tak, že návratovou hodnotu funkce fwrite() porovnáte s hodnotou FALSE.

Opakování zápisu je použito už v tom kódu

Ne, není. Jak jste přišel na to, že při druhém volání se zapíše vše? Volání se musí opakovat tak dlouho, dokud nejsou zapsaná všechna data. Používají se k tomu cykly.

Cožpak jste ten kód nečetl, než jste psal svou radu?

Přestaňte pořád hledat chyby u jiných, když je ta chyba jenom ve vašem kódu. Četl jste tu poznámku s příkladem v dokumentaci fwrite(), kterou jsem odkazoval? Vidíte tam ten cyklus? Připadá vám, že takový cyklus máte ve svém kódu?

3138

Vývoj / Re:Zjištění chyby při neúspěchu fwrite()

« kdy: 30. 06. 2018, 17:33:31 »

V dokumentaci je napsáno přesně to, co jsem psal, tedy že třetí parametr je v takových případech nutný.

Vy jste napsal jenom kus kódu, žádné vysvětlení, natož něco o „takových případech“. Ty hranaté závorky kolem parametru $length v definici funkce označují, že je parametr nepovinný, pak je to ještě zopakované u samotného parametru: „If the length argument is given…“. Pokud narážíte na to, že přítomnost parametru $length zároveň znamená,že s ebude ignorovat volba magic_quotes_runtime, my nevíme ani co chce zapisovat ani jak má tuto volbu nastavenou.

3139

Vývoj / Re:Zjištění chyby při neúspěchu fwrite()

« kdy: 30. 06. 2018, 16:55:19 »

Kód: [Vybrat]

$len = strlen($s);
$wrote = fwrite($handle, $s, $len);

To by bylo hloupé, ale zkusím to.

Klidně to zkuste, ale ničemu to nepomůže, protože třetí parametr funkce fwrite je nepovinný, a pokud není uveden, zapisuje se celý řetězec. Tedy uvedený kód je ekvivaletní s tímhle:

Kód: [Vybrat]

$wrote = fwrite($handle, $s);

Nebývá špatné přečíst si dokumentaci, pak se nemusíte ptát na věci, které jsou tam napsané.

3140

Vývoj / Re:Zjištění chyby při neúspěchu fwrite()

« kdy: 30. 06. 2018, 16:53:15 »

Přečtěte si prosím nejdříve ten kód, dobře?

Nejprve si vy velmi pomalu přečtěte, co jsem vám napsal ve svém prvním komentáři. Máte tam vysvětlené, jak funguje funkce fwrite a proč máte ten kód špatně. Pak si přečtěte dokumentaci funkce fwrite, abyste to lépe chápal, odkaz jsem vám dával.

Kód: [Vybrat]

    $len = strlen($s);
    $wrote = fwrite($handle, $s);
    if ($len !== $wrote) {
        echo "\n\nERROR: Nesedí počet zapsaných bytů. C1 {$wrote} ~ {$len}\n\n"; // "419 ~ 2096"

Konkrétně tady jsou špatně ty poslední dva řádky, protože to, že se zapsalo méně bajtů, než kolik jich bylo k dispozici, není chyba, je to standardní chování funkce fwrite.

3141

Vývoj / Re:Zjištění chyby při neúspěchu fwrite()

« kdy: 30. 06. 2018, 16:42:54 »

Nechápu, jak to souvisí s mojí otázkou?

Máte ten kód špatně. Porovnáváte počet zapsaných bajtů s počtem bajtů k zapsání, a když nesouhlasí, považujete to za chybu. Ale ona to chyba není, počet zapsaných bajtů může být v rozmezí 0 až počet bajtů k zapsání. fwrite prostě zapíše tolik bajtů, kolik zrovna zapsat může, a vy si musíte zkontrolovat, zda už zapsal všechno, a když ne, tak to otočit v cyklu a zapsat další část. Podívejte se na dokumentaci fwrite, tammáte hned v první poznámce příklad, jak má zápis do souboru vypadat správně.

3142

Vývoj / Re:Zjištění chyby při neúspěchu fwrite()

« kdy: 30. 06. 2018, 15:45:53 »

Funkce fwrite negarantuje, že zapíše všechny znaky. Musíte si posouvat ukazatel v řetězci a opakovat funkci tak dlouho, dokud nezapíše vše. Pokud by došlo k chybě, vrací fwrite FALSE.

3143

Vývoj / Re:Typový system versus unittesty

« kdy: 29. 06. 2018, 16:28:58 »

Přijde mi zajímavější, aby ukázkové příklady generoval nástroj na základě specifikace.

Což ovšem význam ukázkových příkladů staví na hlavu. Ukázkové příklady mají ten význam, že je velmi jednoduché je vytvořit a pochopit, řádově jednodušší, než vytvořit správnou specifikaci. Proto je u nich také mnohem větší pravděpodobnost, že budou správně. Když se budou tvořit z té složité specifikace, budou pro její kontrolu k ničemu. Kdybyste chtěl vygenerovat ze specifikace hezké ukázkové příklady, které zkontroluje někdo neznalý programování, bude to ještě podstatně složitější (jak automaticky poznáte ty „hezké“ příklady?), a i pokud by se vám to podařilo, bude existovat velké nebezpečí, že programátor sestaví specifikaci tak, aby mu vycházely ty hezké příklady, a zbytek bude špatně. To je přece známý problém testů (a velké problémy s tím má třeba školství nebo věda), že když něco testujete stále stejnými testy, má to tendency degenerovat a uzpůsobit se tak, aby to perfektně procházelo těmi testy – a nic jiného rozumného to nedělá.

3144

Server / Re:HTTPS certifikát v interní síti

« kdy: 29. 06. 2018, 16:08:32 »

Existují i pěkně zasviněný sítě, kde vládne bordel a chaos a každý si tam dělá, co chce. Opravdu ideální políčko pro šíření různých havětí mezi desktopy

Vnucování vlastní certifikační autority určitě zabrání šíření havěti mezi desktopy…

Stav veřejných autorit myslím známe všichni a snad všichni rozumní lidé už ví, že je to jeden průser za druhým a ty vaše ověřené autority si vydávají co chtějí. Proto vznikl certificate transparency.

Ano, právě že stav veřejných autorit všichni známe. Je nad nimi taková kontrola, a přesto je to jeden průser za druhým, jak píšete. Jak asi vypadají interní autority, nad kterými žádná kontrola není.

3145

Software / Re:Se sudo se nepřihlásím na SSH klíčem

« kdy: 29. 06. 2018, 15:44:50 »

Vyřešil jsem pomocí sshpass.

To chce ale hodně velké uvozovky kolem toho „vyřešil“.

3146

Server / Re:HTTPS certifikát v interní síti

« kdy: 29. 06. 2018, 15:00:41 »

Zaprvé, autor dotazu jasně napsal, že se jedná o interní síť

Interní síť ovšem automaticky neznamená síť, kde má správce sítě plně pod kontrolou veškerá zařízení v síti.

z dotazu je myslím patrné, jak to myslel

Ano, je to patrné. Explicitně psal o Let's Encrypt, tedy o všeobecně uznávané certifikační autoritě.

resp. to vypadá, že o možnosti vlastní CA a distribuci CA ani nevěděl

To je jen vaše fabulace.

NASka většinou také ne (většinou slouží jen jako SMB storage, málokdo dává přístup uživatelům přes web)

Aha, a proto má třeba Synology spoustu webových aplikací běžících na jejich NAS (třeba prohlížeč fotek) a má k otmu dokonce mobilní aplikace.

protože já napsal, jak to mám já ve firemní síti, kterou spravuji.

Bohužel zapomínáte na to, že vaše síť není jediná, a existují sítě, kde to funguje jinak.

Vy jste reagoval na to, jak to mám já nastaveno a jak to provozuji.

Ohledně vaší sítě jsem reagoval na jediné tvrzení, a to že vy osobně své certifikační autoritě věříte. Pouze jsem k tomu podotkl, že uživatelé ve vaší síti mohou důvěryhodnost vaší autority vnímat jinak.

Pokud narážíte na víceúrovňový level support, tak vlastní CA většinou řeší ty poslední levely, který právě přístup mají skoro ke všemu.

Ne, narážím na to, že uznávané certifikační autority musejí projít auditem a jsou pod neustálou veřejnou kontrolou, zatímco interní CA taky může vypadat tak, že někdo slavně zvítězil nad OpenSSL a s vydatnou pomocí Google splácal nějaké shell skripty. Nemusí to být váš případ, ale já nemám jak to poznat, když mi budete certifikát své CA vnucovat do systému.

No nic, to je jedno, vy upřednostňujete volnost, aby si každý ve vaší síti dělal, co chtěl.

Ano. Ať si každý dělá, co uzná za vhodné, pokud tím neomezuje ostatní.

Já upřednostňuji plnou kontrolu nad vším, co ve firmě běží a co se do ní v rámci interní sítě připojuje (navíc bez AD s GPO by onomu uživateli stejně nic nefungovalo, resp. s PC v AD se uživatel přihlásí pod sebou a vše mu jede, vše má namapované, povytvářené zástupce, funguje SSO atd.). BYOD povoluji, ale jen v rámci VPN a splněných policy (=musí si uživatel nainstalovat náš konfigurační balíček, který mu přednastaví VPN, nahraje CA a další věci.).

Ok, vaše věc.

Všimněte si ale, že tazatel chce důvěryhodné certifikáty pro dvě zařízení. Moje doporučení je nechat si je vystavit od Let's Encrypt. Vy nabízíte možnost uzavřené interní sítě, ve které je provozována vlastní certifikační autorita a AD s GPO která tlačí na Windows stanice certifikáty té certifikační autority. Do mobilu si pak uživatel taky musí nahrát kořenový certifikát. A tohle celé by měl někdo dělat kvůli dvěma serverovým certifikátům…

Navíc si živě představuju, jak ta vaše certifikační autorita splňuje všechny požadavky současných prohlížečů na důvěryhodné autority – vydává certifikáty se jmény v extenzích a ne v CN, podepisuje SHA-2, publikuje do Certificate transparency…

3147

Software / Re:Se sudo se nepřihlásím na SSH klíčem

« kdy: 29. 06. 2018, 11:58:07 »

Samozřejmě kopírovat adresář .ssh i parametr "ssh -i" jsem zkoušel bez kýženého sukcesu. Asi bude nějaký problém v tom, jak funguje sudo.   

Pokud jste adresář .ssh zkopíroval k sobě, nebo jste použil ssh -i (a ověřil si, že můžete daný soubor přečíst), žádné sudo jste přece nespouštěl.

Prostě zapomeňte na zbytečné sudo, pouštějte ssh klienta ze svého účtu a pokud potřebujete použít klíč jiného uživatele, zařiďte to prostředky ssh.

3148

Vývoj / Re:Typový system versus unittesty

« kdy: 29. 06. 2018, 11:42:12 »

Kvadratická rovnice je definovaná jako ax^2 + bx +c = 0. Takže když se člověk zeptá "kompilátore, řeší tenhle vzoreček ax^2+bx+c=0, tak se ptá, jestli řeší kvadratickou rovnici jazykem, kterému kompilátor rozumí. Když tam dá jiný (neekvivalentní) vzoreček, tak se na to neptá.

No, a když si programátor bude myslet, že kvadratická rovnice je definovaná jako ax^2 + bx = 0, tak se zeptá „kompilátore, řeší tenhle vzoreček ax^2+bx=0?“, tak si bude myslet, že se ptá, jestli řeší kvadratickou rovnici, jazykem, kterému kompilátor rozumí. Programátor pak odevzdá naprogramovanou funkci pro výpočet kvadratické rovnice, kompilátor nebude hlásit žádnou chybu – akorát ta funkce bude ve spoustě případů počítat špatně.

No, takže fakt říkáte, že když kompilátor nepožádám, aby ověřil, že funkce řeší kvadratickou rovnici, tak to kompilátor neověří. Bingo.

Ne, kompilátor nepožádáte, aby ověřil, že funkce řeší kvadratickou rovnici. Protože kompilátor neví, co je kvadratická rovnice. Kompilátor ví, co je ax^2 + bx = 0 nebo ax^2 + bx + c = 0. Že něco z toho je kvadratická rovnice mu musí říct programátor. A může mu to říct špatně.

3149

Server / Re:HTTPS certifikát v interní síti

« kdy: 29. 06. 2018, 11:35:02 »

Nesouhlasím s vaší argumentací. Fabulujete čistě na teoretické úrovni, která ani nedává smysl.
Pokud mi tvrdíte, že je bezpečnostní riziko pro uživatele to, když admin sítě, který spravuje všechny PC, má k nim admin přístup atd. (a nejen k nim, má přístup síti a všemu okolo), vystaví vlastní CA a tu distribuuje, tak jste fakt mimo. Nevím, zda si ze mně děláte srandu, nebo to opravdu myslíte vážně. Osobně doufám v to první.
Zdar Max

Fabulujete vy. V dotazu nebylo řečeno, že se jedná o síť, kde má admin plnou kontrolu nad všemi PC. Vaše představy o počítačových sítích jsou dost omezené, když si dokážete představit jen takovouhle síť. A to jsem výslovně psal o soukromých mobilních telefonech, takže vás to mohlo napadnout, že existují i sítě, kam se připojují i zařízení uživatelů, nad kterými správce sítě samozřejmě žádnou kontrolu nemá.

3150

Server / Re:HTTPS certifikát v interní síti

« kdy: 29. 06. 2018, 07:40:18 »

To samé můžete tvrdit o CA, které jsou distribuovány v rámci OS, prohlížečů atd. Není v tom rozdíl.

Je v tom rozdíl, protože ty CA distribuované v rámci OS nebo prohlížečů můžu jako vlastník daného počítače spravovat, tj. můžu je označit za nedůvěryhodné. Pokud mi správce vnutí CA přes AD, obvykle znemožní i správu těch certifikátů.

Navíc sám běžný uživatel ani o tom, že nějaký CA je, neví, natož zda tomu má důvěřovat nebo ne.

Ale někteří uživatelé to vědí. Navíc pak provozovatel té CA spoléhá na uživatelovu neznalost a na to, že mu CA stejně vnutí – takž emotivace tu CA nějak zabezpečit a nezneužívat jí je hodně nízká. Jediné, co takovému provozovateli interní CA brání vydat certifikát pro *.google.com je to, že se mu do toho nechce.

Proč by měla být odpojená od netu? Prostě existuje interní komunikace a komunikace z venku.

Aby bylo zajištěno, že ta interní CA nebude zneužita k vydání certifikátů pro něco venku.

Pokud jde o BYOD, tak opět není problém distribuovat cert směrem k uživateli takového zařízení.

A to je přesně to, co v žádném případě nechci – instalovat si do svého mobilu nebo na svůj počítač jako důvěryhodnou nějakou certifikační autoritu, o jejímž fungování ví akorát správce dané sítě a jeho zástupce.

Pokud máte nějakou home síť a aplikujete zkušenosti z provozu z ní na korporátní síť, tak chápu, že můžete mít značně zkreslené představy.

Že se jedná o korporátní síť je jen vaše fabulace. A vaše představa o korporátní síti, ve které je správce neomezeným vládcem, může vše a uživatelé včetně ředitele korporace mohou akorát srazit podpatky a poslouchat, sice odpovídá některým korporátním sítím, ale ne všem.