21. září bude sraz! Od 18.00 v restauraci Tradice v Praze u Anděla
Autor Zpráva
sysel
Profil
Prosím o radu. Používám program (AD FTK pod MS-Windows), který využívá databázi (Oracle nebo PostgreSQL), ovšem pouze vlastní instalaci na Windows. Instalace sice může být na nezávislém stroji, ale vzhledem k tomu, že používám výhradně datová úložiště (servery) s Linuxem, pokouším se migrovat PostgreSQL na Linux. Bohužel se mi to nijak nedaří. Zatím jsem sice nevyzkoušel všechny možnosti a také jsem spíše poučeným uživatelem, než datebázovým architektem a vývojářem.
Program (FTK) se prostě ke stroji MS-Windows/PostgreSQL/Python3 připojí a pracuje, ale k čisté instalaci Linux/PostgreSQL/Python3 se sice připojit pokusí a cosi tam i vykoná, ale pak to vzdá a bez vysvětlení pracovat odmítá.
Pokoušel jsem se problém řešit s oficiální podporou, ale buď to opravdu neumějí nebo umět nechtějí. Přitom na přímou otázku: zda je u nich ve firmě "Linux" sprosté slovo? se dušovali, že nikoliv.
Problém je o to složitější, že vedle standardní databáze, přístupné uživateli "postgres" si program vytvoří databázi adg, která je přístupná pouze nově založenému uživateli "adg", jehož heslo není jak získat.
Globálně jsem nějaké rozdíly odhlalil - vnitřní kódování je sice v obou případech utf-8, ale pro porovnávání je na MS/W cp1250; na Linuxu je v souboru pg_hba.conf jsem měl nastaveno "trust", ale na MS-W je požadováno "md5". Ale to mi připadá jako celkem drobné detaily s ohledem na to, že program s databází alespoň zpočátku komunikuje a zprčí se až později.
Zatím mám v plánu, po té, co zharmonisuji základní konfiguráky, podstrčit Postgresu na Linux odpovídající datový adtresář \Pgsql93\ z MS-W.
Za každý nápad budu vděčný.

Díky
Kajman
Profil
Verze jsou stejné?
sysel
Profil
Kajman:
Verzi bych mohl nainstalovat i stejnou (9.3), ale rád bych instaloval tu, která je v aktuální distribuci (9.4 nebo 9.6).
Co jsem zatím načetl, versi snad mohu i podvést, když mám lepší (u pythonu se 2.7 a 3 liší podstatně).
Zatím zápasím s tím přihlašováním, přejít z "trust" na "md5" a to jsem ještě neměl u uživatele postgres heslo zadané vůbec, to mi teď rohodilo všechny fungující procesy.
Zatím jsem si ověřil, že program (FTK) si po spuštění vytvoří nového uživatele (CREATE ROLE adg LOGIN WITH ENCRAPTED PASSWORD) a hned si tímto uživatelem vytvoří novou databázi "adg". No a té se například už nemohu vůbec zbavit?! Tedy ani toho uživatele, abych mohl tento krok zopakovat.
Keeehi
Profil
sysel:
Co třeba proxy? Nedávno jsem měl problém s jedním programem který se připojoval k mysql a k jeho vyřešení mi pomohlo, když jsem měl celý záznam SQL dotazů. Dlouho jsem hledal jednoduchý a funkční způsob, jak ty data dostat až jsem narazil na jednoduchý program který poslouchal na nějakém portu a vše co obdržel vypisoval a zároveň posílal do databáze a výsledky z ní zpět. V programu se mi stačilo připojit na tento port a měl jsem kompletní záznam poslaných SQL dotazů. Ona tedy samotná mysql umí logovat SQL dotazy, což stačí v nastavení jen zapnout, ovšem mně tam ten program posílal dotazy s chybnou syntaxí a ty se tam nelogují.

V tvém případě by možná stačilo PostgreSQL zapnout logování a podívat se, na čem to umírá. Pokud by to nestačilo, nebo by se zdálo, že tam není všechno, zkusil bych se podívat po nějaké proxy pro PostgreSQL.
sysel
Profil
Keeehi:
proxy?
Velmi zajímavá myšlenka. Zkusím, snad bude fungovat i s PostgreSQL. Vzhledem k tomu, že mým cílem je používat program FTK, snažím se o databázích naučit pouze účelově to, co k vyřešení problému nebytně nutně budu potřebovat.

Myslel jsem, že budu moci přetáhnout existující balík s daty z Windows do Linuxového souborového systému a v pg-configu na nový adresář nasměrovat položku "data_directory=". Hm, tak snadno to asi nepůjde ;-(
Existuje pg_dumpall, ale nějak se v parametrech nemůžu dopídit zadání password (-U tam je, ale na heslo se mě nezeptá). Problém je, že to vpadá, jokoby se databáze "adg" uživatelem "postgres" nedala vydumpovat. Zkusím, ještě různé možnosti autentizace (anpříklad trust), no a uvidíme.
TomášK.
Profil *
... a to jsem ještě neměl u uživatele postgres heslo zadané vůbec,
To je poměrně běžné, v pg_hba.conf bývá nastavená metoda ident, které využívá heslo uživatele v OS.

postgres je administrátorský účet. Může tedy třeba smazat databázi nebo uživatele adg, vytvořil jiného uživatele, který do ní bude mít přístup, vytvořit další administrátorský učet, atp.

Přetahování souborů bych se vyhnul. I pro upgrade z jedné verze na druhou se (aspoň u menších databází) používá pg_dumpall > outputfile a psql -d postgres -f outputfile, vhodné dělat jako uživatel postgres. Na heslo by se měl zeptat, jen pokud ho potřebuje. Na linuxu většinou jde sudo -u postgres psql, má-li uživatel nastavené sudo.
sysel
Profil
Zatím jsem ještě nerozchodil "proxy", ale i wiresharkem se dá ledacos odposlechnout. Zatím jsem našel nesrovnalost v parametru "LC_COLLATE" a "LC_CTYPE", což se na obou typech OS doplňuje dle místních zvyklostí (předpokládám, že se jedná o vliv LOCALES na řazení abecedy, datumy a desetiné tečky/čárky). Windowsí klient se snaží vnutit "Czech_Czech Republic.1250" na čemž SQL příkaz CREATE DATABASE okamžitě zkolabuje, protože pod Linuxem je to "cs_CZ.UTF-8". Nevím, zda lze toto nějak podvést na straně serveru, ptotože do klienta prostě nevidím. Inu kompatibilita je mocná čarodějka. Ostatně na nějakém blogu se nešťastník svěřoval, že při pg_dump(MS-W) -> pg_restore(Linux) musel, byť v angličtině, tento parametr opravit na standardní "C", a teprve pak mu zafungovalo pg_restore. Asi to bude boj, ale moc bych ho potřeboval dobojovat vítězně.
sysel
Profil
sysel:
wireshark
Trochu jsem se vzdělal v analytických možnostech tcpdump(u) a našel jsem možnosti, jak extrahovat SQL query pomocí CLI aplikace tshark. Takže komunikaci už vpodstatě umím odposlechnout v případě fungující komunikace program <--> pgsql(MS-Windows). Teď se pokusím totéž zajistit pro kolabující komunikaci program <--> pgsql(Linux).
-
Po několika pokusech jsem o nic moudřejší nebyl, program dokázal několikrát databázi zcela vykolejit takže "odmítá spojení" přestože běží a na portu naslouchá. Nic se nezlepšilo ani po restartu služby, ani po restartu systému. Nakonec jsem musel databázi přeinstalovat včetně kompletní likvidace všech souborů.
Vše nasvědčuje, že problém je v nastavení. Pokusil jsem se zatím "opsat" pg_hba.conf z MS-W do Linuxu. Také jsem musel nastavit alespoň nějaké heslo pro user postgres, protože programu se evidentně prázdné heslo nezdá být správně vyplněnou kolonkou. V konfiguraci postgres.conf jsem ještě zkusil změnit ssl=off, protože na MS-W nic o ssl nebylo. Ale skončil jsem opět na tom, že postgresql odmítá spojení (a to ani z řádkového klienta psql). Takže mě čeká znovu přeinstalace postgresu, protože už je nejspíš zauzlená.
sysel
Profil
Hm, tak se zdá, že bylo všechno v pečlivém nastavení konfigurací. Předně je nutné věrně napodobit pg_hba z ms-windows instalace:
local   all   postgres                     trust
host    all   all        127.0.0.1/32      md5
host    all   all        0.0.0.0/0         md5
V linuxové konfiguraci postgres.conf nejlépe funguje parametr:
listen_addresses = '*'
Možná se ještě pokusím tento parametr změnit na '192.168.x.y,127.0.0.1' (někde jsem četl, že localhost je nutný). Rovněž ssl = false je dobře nebo alespoň neškodí.
Jak jsem se byl zmínil, je nutné vytvořit heslo pro uživatele "postgres", protože program při prvním připojení musí použít toto uživatelské jméno a neumožňuje odeslat prázdní heslo. To se mi podařilo v Linuxové řádce pomocí psql klienta.
Čistá instalace programu se pak konečně připojila a podařilo se jí vytvořit si své uživatele, databáze a tabulky, pomocí kterých se připojuje při dalších spuštěních.
Jedna, dosud nezmíněná součást instalace na ms-w má možná vliv, je instalace python 3, která je však na Linuxu automatická.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0