Příspěvky

511

Studium a uplatnění / Re:Zmena kariéry

« kdy: 21. 06. 2020, 22:09:18 »

Celý život jsem programoval pro desktop, ale před pár lety jsem chtěl změnu a nějak se dostat do průmyslu, ke strojařům a programovat tam. Takže trochu opačná cesta. Trvalo to asi rok a půl, kdy mě po různém odmítání oslovila firma, kde jsem se o nic neucházel a od té doby pro ně dělám, když je potřeba. Samozřejmě to stálo spoustu učení.
Z toho, co vidím, je ve strojírenství spousta možností, jak uplatnit strojařské znalosti a spojit to s programováním. Možná bych se začal rozhlížet pod svícnem. Třeba přímo ve firmě kde jsi teď. Často se hodí nějaký menší program, který někde usnadní činnost a lidi okolo ani nenapadne, že by to šlo naprogramovat, jsou smíření s tím, jak to je. Pohledal bych, promyslel řešení a nabídl to. Na tom se dá dost naučit bez stresu, a hlavně, nejvíc se člověk naučí z reálného programování, kde musí být jasný výsledek, kde mu lidi hlásí chyby a stroje klacky pod nohy
Jazyk bych pak vybíral podle toho, co vyžaduje projekt/úkol, to podle mě neni nic klíčového, stejně se člověk spíš učí hromadu věcí okolo.

To OP: Souhlas, dobrej příklad,  akorát ne v té samé firmě kde děláš konstruktéra. Kolegové tě sice budou obdivovat, vedení pochválí ale de facto budeš dělat víc práce za ty stejný peníze. Vyučit se a přejít jinam :-)

512

Server / Re:Přístup k souborům přes SFTP

« kdy: 27. 05. 2020, 11:12:43 »

Je to popsáno v článku Jak nahradit FTP pomocí SFTP a zamknout uživatele.

Deset let starý článek a furt relevantní ?

513

Software / Re:Údajné zneužití licence SW

« kdy: 12. 05. 2020, 12:03:13 »

Uznavam, ze autor prispevku mozna i takticky uvedl polovinu pravdy, ale stejne, to nikdo nemyslite vazne, ze na zaklade nejakeho tvrzeni o udajnych zaznamech sitoveho provozu byste nekdo seriozne uvazoval o uhrade pozadovane castky. Ted vychazejme z toho, ze autor prispevku skutecne dany SW nepouzival jak tvrdi a tedy zadne dalsi dukazy nemuzou existovat. To je smesne...

Podle mne je to scam. Tohle nemá  DS jako renomovaná firma zapotřebí.  Solidworks, Catia, to se dá chránit i jinak. Oni už nepoužívají HW klíč? Seznam zákazníků DS asi někde najít lze, že? Jsem zvědav, jestli za vámi taky budou chtít na vaše náklady přijet, jako za kolegou z odkazu na abclinuxu.

Tady je na to téma moc pěkný video
https://youtu.be/jXRHb4sCM8c

514

Server / Re:PostgreSQL DB na Linuxu roste nad všechny meze

« kdy: 08. 05. 2020, 08:50:53 »

Ahoj, vyznáte se v tom někdo ?
Ve struktuře DB na disku a jak se doptat, co se kam píše …
Potřebuju zjistit, proč mi jeden segment na disku bobtná nade všechny meze.
Nevím o této DB nic.
Dík

Ahoj , díky všem. Hodně jsem se naučil. Po  vakuu jsem ušetřil 2GB , což nestačí, tak jsem nafoukl LV a nechám to být.

515

Server / Re:PostgreSQL DB na Linuxu roste nad všechny meze

« kdy: 07. 05. 2020, 09:42:57 »

Už jsem blízko vakuování, jen dvě otázky:
- má smysl předtím pustit vacuum analyze ?
- tabulka má velikost 14GB, ale místo v / je jen 3.8GB (proto to celé dělám) Dojede to do konce ? pokud ne, vadí to ?
Ještě jednou moc díky

Ne, proč? Pokud má bloat faktor vysoký, tak se to může povést, pokud ne, tak se to nepovede a spadne vám to na nedostatek místa na disku. U toho nedostatku místa na disku je relativně malá šance na poškození databáze, pokud byste tam měl nějakou starší neaktualizovanou verzi PG a zároveň dělal další operace. Pokud má tabulka 14GB a místo na disku je 3.8GB, a nic moc jste tam nepromazal (obsah dat je 12-14GB), tak to moc smysl nedává. Pokud budete mít stejně nějakou odstávku, tak můžete podropovat nějaké indexy, tím si uvolníte prostor na disku, a pak je znovu vytvoříte.

A tak si říkám, jak pak asi zálohujete.

Díky moc. ....tak to moc smysl nedává... co nedává smysl, dělat to vacuum ?
S tím zálohováním, já se nechci moc odkopat, ale mám obraz té mašiny, nic jiného ani nejde. Navíc je to clusterované , tak ji v nejhorším přeinstaluju.
Problém je v tom, že ta tabulka pg_largeobject je 40x větší než zbytek databáze, tak není moc co podstatného smazat.
Musím něco udělat s ním, zkusím asi to vacuum ?

Edit .. kdepak, místo došlo asi po minutě. Zkusím napřed nafouknout LV.

Nevite kam si pri tom vacuum full sype ty docasne soubory, ze bych tam primontoval novy LV fs/ ktery bych pak smazal ? Nafukovat / nechci. A velikost pridaneho mista ... 2x jako tabulka ? Nebo = tabulka ?

516

Server / Re:PostgreSQL DB na Linuxu roste nad všechny meze

« kdy: 06. 05. 2020, 20:00:14 »

Už jsem blízko vakuování, jen dvě otázky:
- má smysl předtím pustit vacuum analyze ?
- tabulka má velikost 14GB, ale místo v / je jen 3.8GB (proto to celé dělám) Dojede to do konce ? pokud ne, vadí to ?
Ještě jednou moc díky

Ne, proč? Pokud má bloat faktor vysoký, tak se to může povést, pokud ne, tak se to nepovede a spadne vám to na nedostatek místa na disku. U toho nedostatku místa na disku je relativně malá šance na poškození databáze, pokud byste tam měl nějakou starší neaktualizovanou verzi PG a zároveň dělal další operace. Pokud má tabulka 14GB a místo na disku je 3.8GB, a nic moc jste tam nepromazal (obsah dat je 12-14GB), tak to moc smysl nedává. Pokud budete mít stejně nějakou odstávku, tak můžete podropovat nějaké indexy, tím si uvolníte prostor na disku, a pak je znovu vytvoříte.

A tak si říkám, jak pak asi zálohujete.

Díky moc. ....tak to moc smysl nedává... co nedává smysl, dělat to vacuum ?
S tím zálohováním, já se nechci moc odkopat, ale mám obraz té mašiny, nic jiného ani nejde. Navíc je to clusterované , tak ji v nejhorším přeinstaluju.
Problém je v tom, že ta tabulka pg_largeobject je 40x větší než zbytek databáze, tak není moc co podstatného smazat.
Musím něco udělat s ním, zkusím asi to vacuum ?

Edit .. kdepak, místo došlo asi po minutě. Zkusím napřed nafouknout LV.

517

Server / Re:PostgreSQL DB na Linuxu roste nad všechny meze

« kdy: 06. 05. 2020, 18:42:36 »

+1 

Můžu jen dotaz, zda je důvod spouštět ručně FULL VACUUM když mám zapnuté autovacuum?

Těch důvodů může být více - mohou vám neplánovaně narůst tabulky, které pak chcete promazat, a u kterých nechcete riskovat fullscan, který by zbytečně četl 100násobek balastu - aplikační chyby, dos útok, promazání logů, .. autovacuum, připadně samotné vacuum může být z několika důvodů neefektivní - např. dlouho otevřená transakce. VACUUM FULL jako side efekt je ochranou proti přetečení transakčních ID (což by mi autovacuum zajistilo taky, ale to může VACUUM FREEZE pustit v nevhodnou dobu), a sekundární side efekt je reindexace. VACUUM FULL vám může posloužit i jako kontrola čitelnosti integrity databáze.

VACUUM FULL určitě není rutinní záležitost - ale jednou do roka neuškodí. A když mám nějaké malé databáze, na kterých VACUUM FULL běží do minuty, a mohu si dovolit risk exkluzivního zámku, tak pokud pustíte VACUUM FULL, a následně VACUUM ANALYZE, tak jste dostal databázi do výchozího téměř ideálního stavu a není tam co dál moc administrovat, řešit. Jednou, 2x do roka jednoduchá a pro drtivou většinu případů dostatečná údržba databáze.

Už jsem blízko vakuování, jen dvě otázky:
- má smysl předtím pustit vacuum analyze ?
- tabulka má velikost 14GB, ale místo v / je jen 3.8GB (proto to celé dělám) Dojede to do konce ? pokud ne, vadí to ?
Ještě jednou moc díky

518

Server / Re:PostgreSQL DB na Linuxu roste nad všechny meze

« kdy: 06. 05. 2020, 17:52:25 »

+1 

Můžu jen dotaz, zda je důvod spouštět ručně FULL VACUUM když mám zapnuté autovacuum?

Těch důvodů může být více - mohou vám neplánovaně narůst tabulky, které pak chcete promazat, a u kterých nechcete riskovat fullscan, který by zbytečně četl 100násobek balastu - aplikační chyby, dos útok, promazání logů, .. autovacuum, připadně samotné vacuum může být z několika důvodů neefektivní - např. dlouho otevřená transakce. VACUUM FULL jako side efekt je ochranou proti přetečení transakčních ID (což by mi autovacuum zajistilo taky, ale to může VACUUM FREEZE pustit v nevhodnou dobu), a sekundární side efekt je reindexace. VACUUM FULL vám může posloužit i jako kontrola čitelnosti integrity databáze.

VACUUM FULL určitě není rutinní záležitost - ale jednou do roka neuškodí. A když mám nějaké malé databáze, na kterých VACUUM FULL běží do minuty, a mohu si dovolit risk exkluzivního zámku, tak pokud pustíte VACUUM FULL, a následně VACUUM ANALYZE, tak jste dostal databázi do výchozího téměř ideálního stavu a není tam co dál moc administrovat, řešit. Jednou, 2x do roka jednoduchá a pro drtivou většinu případů dostatečná údržba databáze.

Dopracoval jsm se ke zjištění, že ta mrcha velká je table pg_largeobject. Co dál ? Cílem je zjistit, kdo do ní píše, třeba podle toho co je tam zapsáno. Abych věděl, která aplikace se zbláznila. P.S. DB je moje, ne zákazníka, ale je produkční, momentálně standby a mám zálohu.
Díky

519

Server / Re:PostgreSQL DB na Linuxu roste nad všechny meze

« kdy: 06. 05. 2020, 16:57:45 »

Na to ho nepotrebujes. By default ma do ni pristup juzr “postgres”, proste jen tim ze jim ses (sudo nebo su), pac ma autentizaci “ident”, resp. “peer”. Vic v pg_hba.conf.

Diky. Na co že to heslo nepotřebuju ?
pg_hba.conf mam takto:
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    cpm             all             127.0.0.1/32            password
local   cpm             all                                 password
host    postgres             all             127.0.0.1/32            password
local   postgres             all                                 password
host    monitoring             all             127.0.0.1/32            password
local   monitoring             all                                 password
local   template1             all                                 password

Jsem tam :-)

520

Server / Re:PostgreSQL DB na Linuxu roste nad všechny meze

« kdy: 06. 05. 2020, 16:39:48 »

Postgres boptna, protoze se chova k prostoru na disku podobne jako Java k pameti, "naalokuje co muze". Resp. kdyz budete mit tabulku, kde mate hodne UPDATE a DELETE tak se zachovavaji transakce i data, postgres si oznaci data jako smazane, ale neuvolni misto na disku pro system. Cili to pak vypada, ze vam vytece z disku, ale on nevytece, v pripade, ze zacne mit kriticky malo mista na disku, 1-2GB tak teprve potom zacne tyhle "sektory" pouzivat znovu, sam pro sebe. Autovacuum vam nepomuze, resp. ted nevim jestli je to od verze 11 nebo 12, ale doporucuju udelat FULL VACUUM, bohuzel to ma exklusivni locky, takze opatrne (u 12 ma prikaz vacuumdb moznost nezamikat tabulky - viz manual). Doporucuju vybrat "top 10" nejvetsich databazi, seradit vzestupne dle velikosti, per databazi pak udelat to same s tabulkama a pustit full vacuum per tabulka. Kdyz zacnete s mensima, uvolni to misto na vacuuming vetsich tabulek. Pocitejte, ze na tabulky 1GB je treba 2GB na disku na full vacuum, proto zacinat od mensich, uvolni misto pro vetsi.

Jak na to vsechno viz dokumentace: https://wiki.postgresql.org/wiki/Disk_Usage

Takto se to samozřejmě nechová. V detailech jste úplně mimo. Nic ve zlém, ale pokud něčemu nerozumím, tak je lepší mlčet. Bohužel internet je zaplněný špatnými dobrými radami.

Bez přihlášení do db žádnou administraci neuděláte. Lze něco detekovat na souborovém systému, ale je to dost pracnější, a navíc hloupost - pokud zákazník si databázi neadministruje sám, a ani nezplnomocní k tomu Vás, tak to jednou musí dopadnout špatně a je to signál, že něco ve vztahu vy, váš zákazník je špatně.

Podívejte se do tabulky pg_stat_activity jestli nenajdete neuzavřenou transakci - state: "idle in transaction". To blokuje VACUUM, a pokud VACCUUM neaktualizuje mapu volného místa v datovém souboru, tak engine neví, že tam volné místo a zvětšuje soubor. Zkontrolujte log - dost často se jedná o aplikační chybu - čistící funkce padají na syntaktických chybách, timeoutech, ..  Podívejte se jestli nějaké tabulky nejsou přefouklé https://wiki.postgresql.org/wiki/Show_database_bloat - pak aplikujte VACUUM FULL. Zkontrolujte jestli si zákazník nevypnul autovacuum.

Diky moc. Jak prectu pg_stat_activity ? Nemam heslo

521

Server / Re:PostgreSQL DB na Linuxu roste nad všechny meze

« kdy: 06. 05. 2020, 16:37:39 »

Na to ho nepotrebujes. By default ma do ni pristup juzr “postgres”, proste jen tim ze jim ses (sudo nebo su), pac ma autentizaci “ident”, resp. “peer”. Vic v pg_hba.conf.

Diky. Na co že to heslo nepotřebuju ?
pg_hba.conf mam takto:
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    cpm             all             127.0.0.1/32            password
local   cpm             all                                 password
host    postgres             all             127.0.0.1/32            password
local   postgres             all                                 password
host    monitoring             all             127.0.0.1/32            password
local   monitoring             all                                 password
local   template1             all                                 password

522

Server / Re:PostgreSQL DB na Linuxu roste nad všechny meze

« kdy: 05. 05. 2020, 23:14:03 »

Díky moc, vypadá to, že stejně nedostanu z vendora heslo do DB :-(

523

Server / PostgreSQL DB na Linuxu roste nad všechny meze

« kdy: 05. 05. 2020, 13:56:05 »

Ahoj, vyznáte se v tom někdo ?
Ve struktuře DB na disku a jak se doptat, co se kam píše …
Potřebuju zjistit, proč mi jeden segment na disku bobtná nade všechny meze.
Nevím o této DB nic.
Dík

524

Sítě / Re:Bezpečnostní úskalí RDP

« kdy: 23. 03. 2020, 21:50:40 »

No mě taky ne, ale připadá mi to nereálné ve scopu původního tazatele, který na takovou systematickou akci při vší úctě není připraven. Natlačili ho do ne zrovna ideálního rohu, odkud se teď snaží operovat.

S tím taky souhlasím. Blbý je, že za úspěch ho nikdo nepochválí, ale průšvih odsere. Jako my všichni tady.
Mějte se hezky, dobrou noc

525

Sítě / Re:Bezpečnostní úskalí RDP

« kdy: 23. 03. 2020, 21:33:09 »

Jako jestli souhlasim s otazkou? Nic jineho v citovanem postu nebylo nezli otazky :-)

S pripojovanim soukr notebooku do jakekoli VPN nesouhlasim kategoricky. Aby clovek dovedl opravdu dobre ochranit interni sit pred hrozbami z VPN, musi sakra dobre vede co dela, mit velmi dobry prehled o provozu a potrebach site a mit nejaky rozumny cas na implementaci.

V tom se naprosto shodneme. Připadá vám to nereálné? Mně ne, tomu se říká odbornost :-)
Kromě toho to taky chce kvalitní technologie.