Příspěvky

1396

Odkladiště / Re:Faktura za Office 365 Home

« kdy: 20. 02. 2019, 20:34:26 »

Pokud bych měl jako "účastníka" pouze bankovní číslo v zahraničí uvedené na výpisu z banky, tak bych byl trochu napjatý co mi na to řekne účetní :-)

PS: Jízdenky na MHD beru jako ceniny a v trafice si vyžádám doklad, kde je jako dodavatel uveden provozovatel trafiky (obchodní jméno + sídlo).

To jste tady ale popletl pojem "účetní doklad". Účetní doklad je zápis, který tvoříte Vy. Tj. Vy do účtárny musíte odevzdat buďto doklad vydaný někým jiným (což je ta tradičnější, jendodušší cesta), nebo všechny rozhodné informace sepíšete a účtárně předáte. Účtárna to pak zaúčtuje na základě Vámi vytvořeného dokladu + materiálů, které jsou k dispozici. Typicky je účetním dokladem cesťák: ten tvoříte Vy a účastníky jste Vy (a zaměstnavatel). Dalším jednostranným dokladem jsou například potvrzení o pracovní neschopnosti, nebo dovolenka.

Doklad na ceniny se bere tam, kde ceninu přestanete držet. Typicky kolek - ten koupíte, olíznete a odevzdáte ho úřadu. Tudíž už neexistuje ta samotná cenina. U jízdenky je to zbytečné, protože označenou jízdenku předáte do účtárny (a doklad už pak jen duplikuje tu samou informaci). Na tomto místě je ještě potřeba připomenout, že nákladová položka nevzniká zakoupením jízdenky či kolku, ale jejich uplatněním. Takže k jízdence musíte uvést účel cesty. Ke kolku musíte doložit, jaký poplatek jím byl uhrazen. (Opět, toto doložení je jen jednostranné, ale slouží jako účetní doklad).

Podle mě jste si zaměnil doklad (jakožto potvrzení od jiné firmy) a účetní doklad (jakožto entitu pro účetnictví), a smluvní strany a účastníky účetního případu.

1397

Server / Re:Nelze vytvořit adresář v /srv běžným uživatelem

« kdy: 20. 02. 2019, 20:26:19 »

Já bych začal tímhle jednoduchým řešením. Podle toho, co píšete, ten skript ani nic nemaže, jenom spouští psql a pg_dump. Oprávnění nastavená tak, aby vám ten skript nemohl jen tak někdo přepsat, předpokládám máte. Takže pravděpodobnost, že ten skript napáchá nějaké škody, je velmi nízká. Vylepšovat to, aby ten skript běžel pod jiným uživatelem, můžete později, až vám ten současný systém bude bezpečně fungovat a budete vědět, že poznáte, když se záloha nevytvořila nebo není kompletní nebo když se tím enterprise řešením neodzálohovala pryč. To jsou mnohem větší rizika.

Já bych možná jen doporučil ten script volat přímo z crontabu uživatele postgres, nikoliv přes su. Tj. crontab -u postgres -e.

1398

Server / Re:Nelze vytvořit adresář v /srv běžným uživatelem

« kdy: 20. 02. 2019, 19:10:06 »

Můžete to klidně dál dělat pod uživatelem postgres.

Moje poznámka byla spíš ke "zdravým návykům", prostě jsem zvyklý to oddělovat a není to žádná práce navíc a střípek bezpečnosti navíc to je.

1399

Odkladiště / Re:Faktura za Office 365 Home

« kdy: 20. 02. 2019, 14:50:40 »

Jo? Já jsem žil v domnění, že u účetního dokladu by jméno dodavatele + adresa být měla.

Náležitosti definuje pouze zákon č. 235/2004 Sb., o dani z přidané hodnoty, § 26 a násl., náležitosti daňového dokladu: https://www.zakonyprolidi.cz/cs/2004-235#cast1-hlava2-dil5.

Pokud ale nechcete uplatňovat DPH, pak se Vás tento zákon vůbec netýká a týká se Vás jen zákon č. 586/1992 Sb., o dani z příjmů, konkrétně § 24: https://www.zakonyprolidi.cz/cs/1992-586#f1459243.

U uplatňování nákladů zákon nestanovuje žádné podmínky. Pouze klade požadavek na průkaznost. Takže pokud máte licenci, máte screenshot ceny na webu, a máte na účtu platbu (ve prospěch Microsoftu), je to průkazné až až.

Příkladem nákladového dokladu, kde nemáte uvedeného prodejce může být např. jízdenka MHD. Tu vám prodává trafika, ale její jméno nikde není. Ale naopak, samotná jízdenka není uznatelný náklad, pokud k ní ještě nedoložíte účel cesty.

Dlouhou dobu (dnes už to neplatí) mohla být příkladem dohoda o provedení práce. Tam nebyla nařízena písemná forma - prostě jste na ulici mohl oslovit kolemjdoucího, požádat ho, ať Vám pomůže vyložit auto, a dát mu za to 200 Kč. A uznatelný náklad to byl.

Dalším příkladem může být nákup občerstvení pro zaměstnance, pokud jste třeba na firemním výjezdu, z nápojového automatu. Ten Vám taky nevydá žádnou účtenku. Tam bych doporučil zadokumentovat samotný výjezd, jména zaměstnanců, trvání výjezdu (vznik nároku na stravu), a foto s výdejem nápojů. Opět - bude to uznatelný náklad.

Dalším příkladem je kupon na MHD, pokud prokážete, že je pro firmu levnější, než kupování samostatných jízdenek. Tam zase nastává "problém", že je odběratelem jméno zaměstnance (dopravní podniky to tak vyžadují - vím, Praha ne, ale zase má dvojnásobnou cenu). V takovém případě může být uznatelným nákladem firmy i doklad, který je psaný na jiného odběratele (opět, nutno vysvětlit a doložit, proč to jinak nešlo).

1400

Odkladiště / Re:Faktura za Office 365 Home

« kdy: 20. 02. 2019, 14:21:26 »

The service/software may not be used for commercial, non-profit, or revenue-generating activities.
Nesmie byt pouzita na non-profit ucely... WTF ? Takze profit ucely su ok ?

Zde by to chtělo trochu znalosti angličtiny. Non-profit activity znamená cca totéž, jako nezisková organizace u nás. Je to podnikatelský subjekt, který nesmí vyvádět zisky ven, ale musí je obrátit zpátky do aktivit.

1401

Odkladiště / Re:Faktura za Office 365 Home

« kdy: 20. 02. 2019, 13:53:31 »

Jste si tim zcela jist? Zdroj?

Je to v licenčním ujednání, nicméně vedou se spory, na kolik jsou tato ustanovení v evropském právu platná.
Tak či onak, porušení licenčních podmínek nemusí úplně nutně souviset s uplatnitelností DPH a nákladů.

1402

Odkladiště / Re:Faktura za Office 365 Home

« kdy: 20. 02. 2019, 11:55:46 »

Rozumiem - no co sa clovek nenauci.

Ok dakujem - dovolal som s nimi: tvaria sa ze to spravit vedia ako "ticket" a "editnu" fakturu dodatocne ... No uvidime

no tohle by měl podnikatel znát, ale dobře .

Oni Vám musí hlavně vrátit to DPH , nejenom editovat fakturu.

1403

Server / Re:Nelze vytvořit adresář v /srv běžným uživatelem

« kdy: 20. 02. 2019, 11:51:52 »

Ano, to je to jednoduché řešení. Akorát mi připadá zvláštní oddělovat uživatele pro zálohování, aby omylem neodstřelil databázový proces nebo nepřepsal konfiguraci, a zároveň při zálohování používat oprávnění superuživatele.

Na to není nic zas tak zvláštního. Cokoliv, co jde provozovat s oprávněními < root, je vhodné tak činit.

Na druhou stranu, samotný zálohovací proces už nemá na výběr, ten musí být co nejrobustnější. Nechcete riskovat, že se Vám nezazálohuje část dat nebo část nastavení jen kvůli tomu, že Vám nedošlo (nezkontroloval jste, rozpadlo se po updatu), kde je potřeba oprávnění nastavit. Tam už zkrátka není vyhnutí. (Fungují tak všechny zálohovací systémy, ať už pasivní, nebo s agentem, ať už na Linuxu, Unixech či Windows).

Ze stejného důvodu se vždy zálohování dělá systémem "Zálohovat VŠE" mínus "vyjmenované exclusions", protože opačný postup (zálohovat jen vybraná umístění) vede dřív či později k neštěstí.

Omezit zálohovací proces lze např. pomocí SElinux.

1404

Odkladiště / Re:Faktura za Office 365 Home

« kdy: 20. 02. 2019, 11:40:07 »

Nemůžete si vybrat. Pokud chcete DPH, musíte se dopředu domluvit a cena musí být bez DPH. Pokud je DPH už přiražena, nemůžete si ji uplatnit.

Co se týče nákladů, tam nepotřebujete doklad (zákon o dani z příjmů to nevyžaduje), stačí Vám doklad o platbě + doložit za co to bylo (např. licence).

1405

Odkladiště / Re:Faktura za Office 365 Home

« kdy: 20. 02. 2019, 11:33:54 »

Jde o to, kdo Vám to prodává. Microsoft některé transakce účtuje z Irska, pak by měl vystavit daňový doklad.
Pokud jste plátce DPH, stejně si ho neuplatníte, protože jste měl dopředu jim předat VAT ID, oni by si pak strhli částku bez DPH a DPH se vyúčtovává v režimu reverse charge.

Pokud to prodávali např. z USA, tam DPH není (někdy píší, že cena je vč. DPH - ikdyž tím mají na mysli 0 % - aby nemátli spotřebitele).

V USA je to dost běžné, že žádný doklad nedostanete. Pro účely daně z příjmu bych do účetnictví dokladoval platbu a obdržený licenční e-mail, to by mělo stačit.

1406

Odkladiště / Re:Faktura za Office 365 Home

« kdy: 20. 02. 2019, 11:27:49 »

Pokud se transakce týká DPH, má prodávající povinnost vystavit daňový doklad.

Pokud se ale netýká DPH, zákon nenařizuje vystavit konkrétní prodejní doklad. V takovém případě za doklad slouží např. kupní smlouva (+ platba), objednávka (+ platba), ... Velmi často, zejména ze zemí mimo EU nedostanete žádný jiný doklad, než prostě potvrzení o objednávce a je to zcela v pořádku.

Kdyby se platba týkala DPH, tak je to porušení povinností na straně prodávajícího a můžete se daňového dokladu domáhat. Kdyby ho přesto nevydal, tak si bohužel z platby nebudete moci uplatnit DPH, nicméně pro účely daně z příjmů se to bude chovat stejně, jako v prvním popsaném případě.

1407

Server / Re:Nelze vytvořit adresář v /srv běžným uživatelem

« kdy: 20. 02. 2019, 10:32:45 »

Něco jiného je zase databázový uživatel – ten rozhoduje o tom, k jakým databázovým objektům bude mít zálohovací skript přístup. Zde je zase z hlediska bezpečnosti nevhodný postup, pokud zálohování spouštíte pod uživatelem, který má v databázi práva superuživatele – je to jako kdybyste v systému spouštěl zálohovací skript s právy roota. Je to jednoduché – nemusíte nastavovat oprávnění, ale zároveň máte mnohem silnější oprávnění, než k zálohování potřebujete. Pro zálohování není potřeba umět žádné objekty v databázi zapisovat, mazat nebo je spouštět, ke všemu potřebujete jen práva pro čtení.

1. Databázový uživatel = "role". Bylo by lepší držet se tohoto pojmenování.
2. Bez superusera nezazálohujete systémové databáze (globalobjects). Běžný uživatel může zálohovat pouze databáze, ke kterým má přístup. I tak to ale nebude dokonalé, protože např. zcela běžný CREATE EXTENSION bez superusera neuděláte.
3. OS je zvykem zálohovat jako root, jinak se Vám může lehce stát, že se zálohovací proces nedostane k některým souborům.

Ale pokud chcete pro bezpečnost vašich dat udělat něco důležitého, začněte tím, že zálohy budete hned na místě šifrovat veřejným klíčem a privátní klíč budete mít někde off-line. To je mnohem důležitější, než jaké účty pro zálohování použijete.

Uff, šifrování ochrání data před zneužitím, ale nezvyšují bezpečnost ve smyslu "neztratím data". Naopak šifrování (pokud uděláte chybu) riziko ztráty dat zvyšuje.

====

Kdybychom šli do důsledku, tak ideální způsob zálohy dat je kopírování souboru databáze + WAL (write ahead logs). Na to už zase je naopak potřeba mít práva číst datové soubory - a zde bych naopak ACL jako řešení doporučoval. Odpadá tím potřeba mít v databázi jakoukoliv roli (natož superusera), databázi to neblokuje v provozu. Popis je zde: https://www.postgresql.org/docs/11/continuous-archiving.html

Jako systém na zálohování a zároveň šifrování (a zároveň ne moc složitý) je podle mě Borg Backup https://borgbackup.readthedocs.io/en/stable/, plně šifrované repo se vytvoří "borg init --encryption=keyfile-blake2". Jedinou nevýhodou je, že nepodporuje pull backup, takže když zálohování selže, jediný způsob jak to zjistit je všimnout si, že nechodí logy, nebo během pravidelných údržeb. (Na pull backup existují scripty přes ssh, ale přímo podporovaná cesta to není).

1408

Server / Re:Nelze vytvořit adresář v /srv běžným uživatelem

« kdy: 20. 02. 2019, 09:36:14 »

Když bych vytvořil pgmaint, mohl bych zálohovat jen ty databáze, kterých je owner pgmaint ne? Tím pádem přístup k databázím vytvořeným jiným uživatelem by neměl přístup ne? Nebo by pgmaint převzal všechno co umí i postgres výjimkou samotného běhu postgresql procesu?

Vůbec ne. Pgmaint bude superuser databáze - bude mít k databázím stejný přístup, jako uživatel postgres.
(Od toho je parametr "-s" ve volání createuser).

Rozdíl mezi uživatelem postgres a pgmaint bude "jen" v tom, že pgmaint nebude mít oprávnění upravovat konfiguraci postgresu, nebude mít možnost poškodit datové soubory posgresu, nebude moci shodit proces postgresu.

1409

Server / Re:Nelze vytvořit adresář v /srv běžným uživatelem

« kdy: 20. 02. 2019, 09:19:15 »

Vy se na to ovšem díváte z opačné strany. Systémový uživatel postgres je jediný způsob, jak se (na Linuxu) do čerstvě nainstalované databáze můžete přihlásit. Nebo-li systémový účet postgres je ten účet, který je určený pro administraci databáze. Můžete použít mapování systémových uživatelů na databázové uživatele, ale opět je to nestandardní konfigurace. Běžné distribuce ale tenhle účet postgres „zneužívají“ i k tomu, že pod ním spouští databázový server.

Ono je to ale přesně naopak. Základem bezpečnosti je, že musíte mít dedikovaný účet pro běh serveru. Tím bývá uživatel posgres, někdy třeba psql. Vůbec ale neplatí, že by "role" postgres musela existovat a být superuserem.

https://www.postgresql.org/docs/11/app-initdb.html - viz parametr --username=:

Kód: [Vybrat]

-U username
--username=username

Selects the user name of the database superuser. This defaults to the name of the effective user running initdb. It is really not important what the superuser's name is, but one might choose to keep the customary name postgres, even if the operating system user's name is different.

Poté je běžné provést su - postgres -c "createuser -s -P jmeno_spravce"

Podle situace se pak v pg_hba.conf (https://www.postgresql.org/docs/11/auth-pg-hba-conf.html) nastaví mechanismus autentikace. Je možné zvolit peer, kdy lokální uživatel téhož usernamu nebude tázán na heslo. Já raději (právě i kvůli tomu, že často se využívá externí připojení) doporučuji i na lokální připojení využívat scram-sha-256 (případně md5 kvůli kompatibilitě se staršími klienty) a heslo ukládat v .pgpass. Je to lepší návyk, předejde se tím možnostem oponinutí bezpečnosti.

Já s vámi souhlasím, že principiálně správně je mít dva účty – jeden pro správu databáze a druhý, pod kterým poběží databázový server. A ideálně ještě další, třeba samostatný účet pro zálohování. Běžné linuxové distribuce to ale pokud vím nerozlišují a pro vše používají účet postgres.

Dívám se na Debian, dívám se na FreeBSD, ale nevidím tam, že by distribuce dělala cokoliv. V minulosti (v době dřevěné, pre-autovacuum) se volala údržba databáze (a debian měl heslo uložené v souboru). Dnes už tam není žádný task:

Kód: [Vybrat]

root:~# crontab -u postgres -l
no crontab for postgres

Kód: [Vybrat]

root:~# find /etc/cron* -type f -exec grep "postgres" {} \;
root:~#

1410

Server / Re:Nelze vytvořit adresář v /srv běžným uživatelem

« kdy: 20. 02. 2019, 07:47:50 »

Jenom jsem upozorňoval na to, že to použití jiného uživatele jde nad rámec toho, s čím počítá např. oficiální dokumentace PostgreSQL, protože tam se počítá s jedním uživatelem postgres, který slouží jak k běhu serveru, tak pro jeho správu. Takže pokud použijete uživatele dva (nebo více), musíte na to myslet i v budoucnosti a používat toho správného uživatele pro konkrétní činnosti.

Toto bych ale považoval za samozřejmost správy. Na systému nepracujete stále s uživatelem root, ale povyšujete práva podle potřeby. Na postgresu nepracujete s uživatelem postgres, ale taky jen povyšujete práva jiného uživatele. To je základní koncept bezpečnosti, o kterém se nemusí psát. (Podobně není v dokumentaci napsáno, že nemáte zakládat uživatele s právy superusera zbytečně, nebo že si nemáte psát hesla na papírek na monitoru.)

Před užíváním uživatele posgtgres na binárky (tj. rozšířeně i na scripty) se v dokumentaci varuje - právě kvůli přepisu jich samých (a potažmo i dat, samozřejmě): https://www.postgresql.org/docs/11/postgres-user.html.

Zde https://www.postgresql.org/docs/11/backup-dump.html se popisuje zálohování, s tím, že jsou potřeba práva superusera. O tom, že by se tato operace měla dělat uživatelem postgres (vlastníkem procesu), zde není ani zmínka, byť by to bylo to nejjednodušší, co by mohli doporučit.