Problem with postgresql-12-crons timezone
Dear community I write as I am not sure if the issue I report is caused by Debian. On 23-10-10 we upgraded our Debian bullseye servers to version 11.8. Along came a new version of postgresql-12-cron: postgresql-12-cron 1.6.0-1.pgdg110+1 pg_cron executes jobs one day too early since then. I opened an issue here: https://github.com/citusdata/pg_cron/issues/290 We reproduced the problem with postgresql 13/ postgresql-13-cron. We could fix the problem temporarily with setting cron.timezone to 'GMT+24' in /etc/postgresql//main/postgresql.conf Thank you in advance for any advice Best, Elke Hofmann Fachhochschule Nordwestschweiz FHNW Hochschule für Life Sciences Prof. Elke Hofmann Leiterin Applikationsentwicklung/Datenmanagement Ausbildung Co-Verantwortliche Studierendenprojekte Hofackerstrasse 30 4132 Muttenz T +41 061 228 54 01 M +41 78 600 47 39 (SMS) elke.hofm...@fhnw.ch<mailto:elke.hofm...@fhnw.ch> www.fhnw.ch/de/personen/elke-hofmann<http://www.fhnw.ch/de/personen/elke-hofmann>
Errors while performing postgresql backup (Was Re: Softraid & partclone)
Hi Testler, On Wed, Aug 24, 2022 at 07:54:03AM +0300, Testler Test wrote: > > Let's see the output of "cat /proc/mdstat". > > The raid status is as follows. No problem appears. > > # cat /proc/mdstat > Personalities : [raid1] > md2 : active raid1 sdb3[1] sda3[0] > 232623424 blocks super 1.2 [2/2] [UU] > bitmap: 1/2 pages [4KB], 65536KB chunk > > md1 : active raid1 sdb2[1] sda2[0] > 523264 blocks super 1.2 [2/2] [UU] > > md0 : active raid1 sdb1[1] sda1[0] > 16759808 blocks super 1.2 [2/2] [UU] Yep, nothing to do there. Whatever problems you are seeing are not likely to be related to the RAID layer. What filesystem are you using on md2? > -% Sda: […] > SMART overall-health self-assessment test result: PASSED > > -% sdb […] > SMART overall-health self-assessment test result: PASSED So, although it says "PASSED" for both of these, it would still be good to look at all the attributes with "smartctl -A". The most interesting thing to know would be the exact text of the error messages that you are seeing (which I assume happen when you fail to back up your database). Are you just doing a pg_dump or are you shutting postgres down and backing up the psql/data directory with usual filesystem tools? Depending on what sort of errors you are seeing you may have a damaged filesystem in which case it would be advisable to set it read only and take an image of it to work with, so as to avoid creating more damage. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Bug a la instal·lació de postgresql?
Moltes gràcies per l'explicació. Toni Mas GPG 3F42A21D84D7E950 Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ El diumenge, 3 de octubre 2021 a les 21:43, julio va escriure: > > Malauradament limitar l'ús de su no és suficient per evitar que > > > > un usuari amb root es pugui convertir fàcilment en un altre o > > > > executar ordres en nom d'un altre: a banda del runuser i setpriv, > > > > qualsevol llenguatge de programació prou genèric permetrà cridar > > > > les funcions del sistema per fer-ho sense passar pel PAM. > > Cert. > > > Se m'acut que la millor forma de què els alumnes tinguin root > > > > però no interfereixin amb d'altres usuaris és que tinguin una > > > > màquina virtual per cadascú. > > Segurament Àlex, però som de la filosofia de que facin servir sistemes reals > i que els trenquin, com a sistema de capçalera, evidentment també fan servir > VMs i Dockers. > > El problema realment és que es loguegin a una màquina on algun despistat ho > hagi fet prèviament, ja que s'haurà muntat per NFS (kerberitzat) el directori > d'aquest usuari despistat. > > Potser el que s'hauria de fer és permetre la exportació de segons quins > directoris a segons quines IPs... > > Merci per les bones idees. > > Julio > > > Salut, > > > > Alex > > > > -- > > > > ⢀⣴⠾⠻⢶⣦⠀ > > > > ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada al...@debian.org > > > > ⢿⡄⠘⠷⠚⠋ Debian Developer log.alexm.org > > > > ⠈⠳⣄ > > Sent from my Android device with K-9 Mail. Please excuse my brevity. signature.asc Description: OpenPGP digital signature
Re: Bug a la instal·lació de postgresql?
> >Malauradament limitar l'ús de su no és suficient per evitar que >un usuari amb root es pugui convertir fàcilment en un altre o >executar ordres en nom d'un altre: a banda del runuser i setpriv, >qualsevol llenguatge de programació prou genèric permetrà cridar >les funcions del sistema per fer-ho sense passar pel PAM. > Cert. >Se m'acut que la millor forma de què els alumnes tinguin root >però no interfereixin amb d'altres usuaris és que tinguin una >màquina virtual per cadascú. Segurament Àlex, però som de la filosofia de que facin servir sistemes reals i que els trenquin, com a sistema de capçalera, evidentment també fan servir VMs i Dockers. El problema realment és que es loguegin a una màquina on algun despistat ho hagi fet prèviament, ja que s'haurà muntat per NFS (kerberitzat) el directori d'aquest usuari despistat. Potser el que s'hauria de fer és permetre la exportació de segons quins directoris a segons quines IPs... Merci per les bones idees. Julio >Salut, >Alex > >-- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada > ⢿⡄⠘⠷⠚⠋ Debian Developer log.alexm.org > ⠈⠳⣄ > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Bug a la instal·lació de postgresql?
Hola, Julio > Quan un d'aquests despistats del grup B, es logueja i s'oblida > de fer kdestroy, el tiquet de kerberos roman durant unes hores > a l'ordinador i en aquest moment, qualsevol usuari amb el compte > local de root pot fer un `su -l usuari_despistat_del_grup_B` Això és el que sospitava, gràcies per explicar-ho amb detall. Malauradament limitar l'ús de su no és suficient per evitar que un usuari amb root es pugui convertir fàcilment en un altre o executar ordres en nom d'un altre: a banda del runuser i setpriv, qualsevol llenguatge de programació prou genèric permetrà cridar les funcions del sistema per fer-ho sense passar pel PAM. Se m'acut que la millor forma de què els alumnes tinguin root però no interfereixin amb d'altres usuaris és que tinguin una màquina virtual per cadascú. Salut, Alex -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada ⢿⡄⠘⠷⠚⠋ Debian Developer log.alexm.org ⠈⠳⣄ signature.asc Description: PGP signature
Re: Bug a la instal·lació de postgresql?
Missatge de Alex Muntada del dia dv., 1 d’oct. 2021 a les 23:37: > Hola, Julio > > > el problema amb Kerberos, és que si no fas un kdestroy o > > l'elimines manualment de /tmp dura no se quantes hores i per > > tant amb l'ordre que hem esmentat pots fer ... > > No entenc quina relació té l'expiració de sessions de kerberos > amb el fet de no permetre que l'usuari root executi el su que > vulgui. Ara ja sabem que també hi ha runuser i, mirant la seva > pàgina de man, he vist que també hi ha setpriv, que ni tan sols > utilitza pam. > La idea és: - els usuaris del grup A fan servir els seus ordinadors amb un compte ordinari ( contra un ldap+kerberos) i amb el compte root local. - els usuaris del grup B no han de fer servir el seu compte als ordinadors del grup A, i ja estan avisats, però sempre hi ha algun despistat. Quan un d'aquests despistats del grup B, es logueja i s'oblida de fer kdestroy, el tiquet de kerberos roman durant unes hores a l'ordinador i en aquest moment, qualsevol usuari amb el compte local de root pot fer un `su -l usuari_despistat_del_grup_B` No sé si m'explico :) Julio -- __ - El 2003 el català era la llengua habitual del 46 % dels catalans. Al 2018 només del 36 %. Si els castellanoparlants no actuem, desapareixerà. - El 3 de novembre representa el moment de l'any en el que les dones deixen de cobrar en comparació amb els homes. Hem d’ajudar a les dones a eliminar aquesta data. - L’administració pública cada any es gasta milions d’euros en llicències de programari privatiu. Utilitzant programari lliure estalviem costos i incentivem l’economia local. *La neutralitat davant les desigualtats acaba accentuant-les.*
Re: Bug a la instal·lació de postgresql?
Hola, Julio > el problema amb Kerberos, és que si no fas un kdestroy o > l'elimines manualment de /tmp dura no se quantes hores i per > tant amb l'ordre que hem esmentat pots fer ... No entenc quina relació té l'expiració de sessions de kerberos amb el fet de no permetre que l'usuari root executi el su que vulgui. Ara ja sabem que també hi ha runuser i, mirant la seva pàgina de man, he vist que també hi ha setpriv, que ni tan sols utilitza pam. Ens pots explicar amb una mica més de detall el problema de fons? Salut, Alex -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada ⢿⡄⠘⠷⠚⠋ Debian Developer log.alexm.org ⠈⠳⣄ signature.asc Description: PGP signature
Re: Bug a la instal·lació de postgresql?
Hola, molt interessant la conversa, com sempre. Tens raó Àlex, això forma part d'una configuració extra que afegim (la línia comentada del pam) per tant efectivament si algú té curiositat ... :) I Toni, el problema amb Kerberos, és que si no fas un kdestroy o l'elimines manualment de /tmp dura no se quantes hores i per tant amb l'ordre que hem esmentat pots fer ... Potser això també és configurable per a que quan un usuari tanqui la seva darrera sessió s'elimini aquest ticket ¿? De fet pensàvem provar-ho manualment a alguns ordinadors posant-ho al logout (si nomes hi ha una sessió d'aquest usuari => kdestroy) però vaja ... Merci, Julio Missatge de Toni Mas Soler del dia ds., 25 de set. 2021 a les 21:26: > Al man su/man runuser hi fa alguna referència. Però no entenc el motiu > perquè és un forat de seguretat si s'usa kerberos (NOTA: jo no faig servir > kerberos). > > Toni Mas > GPG 3F42A21D84D7E950 > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > El dissabte, 25 de setembre 2021 a les 21:00, Eloi > va escriure: > > > El 25/9/21 a les 11:06, Alex Muntada ha escrit: > > > > > Hola, Eloi > > > > > > [...] > > > > > > > Una de les recomanacions que vaig llegir aleshores era usar la > > > > > > > > comanda "runuser" quan qui l'executa ja és root, doncs desescala > > > > > > > > a qualsevol usuari sense demanar autenticació mentre que la > > > > > > > > resta d'usuaris no la poden executar. > > > > > > > > Això no recordo haver-ho llegit però ho acabo de provar i > > > > > > > > funciona bé: no demana contrasenya encara que comenti l'entrada > > > > > > > > del pam_rootok al /etc/pam.d/runuser. > > > > Això és que em faig vell i/o no menjo prou cues de pansa :-) > > > > Jo tampoc he trobat el que recordo haver llegit, segurament deuria ser > > > > una font de tercers, que em deuria enganxar documentant-me i al final he > > > > acabat confonent els orígens. L'única referència explícita que he estat > > > > capaç de trobar amb DDG (DuckDuckGo, no Diari De Girona :-D) dins > > > > debian.org és la següent, que no és el que recordo haver llegit però que > > > > igualment apunta en la mateixa direcció: > > > > https://bugs.debian.org/890862 > > > > Si trobo on redimonis vaig llegir-ho us ho faré saber. -- __ - El 2003 el català era la llengua habitual del 46 % dels catalans. Al 2018 només del 36 %. Si els castellanoparlants no actuem, desapareixerà. - El 3 de novembre representa el moment de l'any en el que les dones deixen de cobrar en comparació amb els homes. Hem d’ajudar a les dones a eliminar aquesta data. - L’administració pública cada any es gasta milions d’euros en llicències de programari privatiu. Utilitzant programari lliure estalviem costos i incentivem l’economia local. *La neutralitat davant les desigualtats acaba accentuant-les.*
Re: Postgresql ODBC driver not found
On Sun, Sep 26, 2021 at 12:10:39AM +0200, Pierre Couderc wrote: > > On 9/25/21 3:46 PM, Henning Follmann wrote: > > > > have you tried to use the odbc lib from unixodbc instead of > > libiodbc? > > > > I think you are right on many other points... > > But particularly on this one ! > > I did remove libodbc2-dev and install unixodbc-dev and now it is OK...!! > > Wow ! > > Thank you very much. > > Let us have a Sunday without any odbc... > > PC > I am glad this worked out. Now I wonder if we should file a bug report against the lib? -H -- Henning Follmann | hfollm...@itcfollmann.com
Re: Postgresql ODBC driver not found
On 9/25/21 3:46 PM, Henning Follmann wrote: have you tried to use the odbc lib from unixodbc instead of libiodbc? I think you are right on many other points... But particularly on this one ! I did remove libodbc2-dev and install unixodbc-dev and now it is OK...!! Wow ! Thank you very much. Let us have a Sunday without any odbc... PC
Re: Bug a la instal·lació de postgresql?
Al man su/man runuser hi fa alguna referència. Però no entenc el motiu perquè és un forat de seguretat si s'usa kerberos (NOTA: jo no faig servir kerberos). Toni Mas GPG 3F42A21D84D7E950 Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ El dissabte, 25 de setembre 2021 a les 21:00, Eloi va escriure: > El 25/9/21 a les 11:06, Alex Muntada ha escrit: > > > Hola, Eloi > > > > [...] > > > > > Una de les recomanacions que vaig llegir aleshores era usar la > > > > > > comanda "runuser" quan qui l'executa ja és root, doncs desescala > > > > > > a qualsevol usuari sense demanar autenticació mentre que la > > > > > > resta d'usuaris no la poden executar. > > > > > > Això no recordo haver-ho llegit però ho acabo de provar i > > > > > > funciona bé: no demana contrasenya encara que comenti l'entrada > > > > > > del pam_rootok al /etc/pam.d/runuser. > > Això és que em faig vell i/o no menjo prou cues de pansa :-) > > Jo tampoc he trobat el que recordo haver llegit, segurament deuria ser > > una font de tercers, que em deuria enganxar documentant-me i al final he > > acabat confonent els orígens. L'única referència explícita que he estat > > capaç de trobar amb DDG (DuckDuckGo, no Diari De Girona :-D) dins > > debian.org és la següent, que no és el que recordo haver llegit però que > > igualment apunta en la mateixa direcció: > > https://bugs.debian.org/890862 > > Si trobo on redimonis vaig llegir-ho us ho faré saber. signature.asc Description: OpenPGP digital signature
Re: Bug a la instal·lació de postgresql?
El 25/9/21 a les 11:06, Alex Muntada ha escrit: Hola, Eloi [...] Una de les recomanacions que vaig llegir aleshores era usar la comanda "runuser" quan qui l'executa ja és root, doncs desescala a qualsevol usuari sense demanar autenticació mentre que la resta d'usuaris no la poden executar. Això no recordo haver-ho llegit però ho acabo de provar i funciona bé: no demana contrasenya encara que comenti l'entrada del pam_rootok al /etc/pam.d/runuser. Això és que em faig vell i/o no menjo prou cues de pansa :-) Jo tampoc he trobat el que recordo haver llegit, segurament deuria ser una font de tercers, que em deuria enganxar documentant-me i al final he acabat confonent els orígens. L'única referència explícita que he estat capaç de trobar amb DDG (DuckDuckGo, no Diari De Girona :-D) dins debian.org és la següent, que no és el que recordo haver llegit però que igualment apunta en la mateixa direcció: https://bugs.debian.org/890862 Si trobo on redimonis vaig llegir-ho us ho faré saber.
Re: Postgresql ODBC driver not found
On Sat, Sep 25, 2021 at 09:16:33AM +0200, Pierre Couderc wrote:
>
> On 9/24/21 5:31 PM, Henning Follmann wrote:
> >
> > and I see you do not do any error checking.
> > This would be a first step to find out where it fails.
> >
> > I added some code...
> >
>
> You hare fully right, I have corrected, but I have the same result and no
> more idea.. :
I do not have much time this weekend, but I will try to set up my
computer to reproduce your setup - maybe on Monday ...
In the meanwhile a few thoughts,
have you tried to use the odbc lib from unixodbc instead of
libiodbc?
Another thing I have myself no clue but, what happens if you do
not set the odbc version?
And just one thought about your loop:
try
do {
/* in there look at SQLSTATE
for anything other than SQL_SUCCESS
I am concerned that SQL_NO_DATA is
not a reliable break indicator */
}while (ret == SQL_SUCCESS || ret == SQL_SUCCESS_WITH_INFO)
>
> nous@pcouderc:~/projets//build$ ./ttest
> D 0.0:ln 19:main(): Start : Compile time : Sep 25 2021 09:03:28
>
> 0x55cee70a5ed0
>
>
>
> nous@pcouderc:~/projets//build$ cat ../main.cpp
> #include
> #include
> #include
> #pragma GCC diagnostic ignored "-Wendif-labels"
> #pragma GCC diagnostic ignored "-Wwrite-strings"
>
>
> #define TDBG clock_t ttdbg=clock();float
> ftdbg=((float)ttdbg)/CLOCKS_PER_SEC;
> #define DBG_(fmt, args...) {TDBG fprintf(stdout,string( string("D%5.1f:ln
> %d:%s(): ")+fmt).c_str(),ftdbg,__LINE__, __func__, ##args);fflush(stdout);}
>
> using namespace std;
> extern "C"
> {
> #include
> #include
> }
> int main(int argc, char **argv)
> {
> DBG_("Start : Compile time : " __DATE__" " __TIME__"\n");
> SQLHENV env;
> SQLCHAR driver[256];
> SQLCHAR attr[256];
> SQLSMALLINT driver_ret;
> SQLSMALLINT attr_ret;
> SQLUSMALLINT direction;
> SQLRETURN ret;
>
> ret=SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, );
> if (ret != SQL_SUCCESS && ret != SQL_SUCCESS_WITH_INFO) {
> cerr << "Failed to allocate handle" << endl;
> return -1;
> }
> ret=SQLSetEnvAttr(env, SQL_ATTR_ODBC_VERSION, (void *) SQL_OV_ODBC3, 0);
> if (ret != SQL_SUCCESS && ret != SQL_SUCCESS_WITH_INFO) {
> cerr << "Failed SQLSetEnvAttr" << endl;
> return -1;
> }
> cout << env< direction = SQL_FETCH_FIRST;
> while(1)
> {
> ret = SQLDrivers(env, direction,
> driver, sizeof(driver),
> _ret,
> attr, sizeof(attr), _ret);
> if(ret==SQL_NO_DATA) break;
> printf("%s - %s\n", driver, attr);
> if (ret == SQL_SUCCESS_WITH_INFO) printf("\tdata truncation\n");
> direction = SQL_FETCH_NEXT;
> }
> return 0;
> }
>
>
>
Have a nice weekend.
-H
--
Henning Follmann | hfollm...@itcfollmann.com
Re: Bug a la instal·lació de postgresql?
Hola, Eloi > Acabo de recordar que fa un temps (oldstable o fins i tot > oldoldstable) hi va haver un canvi important a la comanda su, > bàsicament hi havia dues implementacions i es va canviar d'una > a l'altra per defecte, que tenia algunes subtileses. Crec que > es va documentar a les release notes corresponents, a veure si > quan pugui ho trobo i ho enllaço. Jo també ho recordava però només he trobat aquest petit comentari a les notes d'alliberament de Debian 10 (he remuntat fins a la 8, no he mirat més enrere): https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#su-environment-variables «su has changed semantics in buster and no longer preserves the user environment variables DISPLAY and XAUTHORITY. If you need to run graphical applications with su, you will have to explicitly set them to allow access to your display. See bug #905409 for an extensive discussion.» > Una de les recomanacions que vaig llegir aleshores era usar la > comanda "runuser" quan qui l'executa ja és root, doncs desescala > a qualsevol usuari sense demanar autenticació mentre que la > resta d'usuaris no la poden executar. Això no recordo haver-ho llegit però ho acabo de provar i funciona bé: no demana contrasenya encara que comenti l'entrada del pam_rootok al /etc/pam.d/runuser. > No tinc clar si funcionaria en aquest escenari específic que > s'ha descrit ni si la presumpció que els postinst s'executen > amb permisos de root és sempre certa, per tant no puc valorar > si el canvi de su a runuser seria una solució adequada per al > paquet. Vist que tant su com runuser pertanyen a util-linux, trobo que seria una bona idea suggerir als mantenidors del postgresql que utilitzin runuser enlloc de su per a fer les comprovacions del postinst. En aquest sentit, crec que la millor manera de fer-ho és obrir un bug. Salut, Alex -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada ⢿⡄⠘⠷⠚⠋ Debian Developer log.alexm.org ⠈⠳⣄ signature.asc Description: PGP signature
Re: Postgresql ODBC driver not found
On 9/24/21 5:31 PM, Henning Follmann wrote:
and I see you do not do any error checking.
This would be a first step to find out where it fails.
I added some code...
You hare fully right, I have corrected, but I have the same result and
no more idea.. :
nous@pcouderc:~/projets//build$ ./ttest
D 0.0:ln 19:main(): Start : Compile time : Sep 25 2021 09:03:28
0x55cee70a5ed0
nous@pcouderc:~/projets//build$ cat ../main.cpp
#include
#include
#include
#pragma GCC diagnostic ignored "-Wendif-labels"
#pragma GCC diagnostic ignored "-Wwrite-strings"
#define TDBG clock_t ttdbg=clock();float
ftdbg=((float)ttdbg)/CLOCKS_PER_SEC;
#define DBG_(fmt, args...) {TDBG fprintf(stdout,string(
string("D%5.1f:ln %d:%s(): ")+fmt).c_str(),ftdbg,__LINE__, __func__,
##args);fflush(stdout);}
using namespace std;
extern "C"
{
#include
#include
}
int main(int argc, char **argv)
{
DBG_("Start : Compile time : " __DATE__" " __TIME__"\n");
SQLHENV env;
SQLCHAR driver[256];
SQLCHAR attr[256];
SQLSMALLINT driver_ret;
SQLSMALLINT attr_ret;
SQLUSMALLINT direction;
SQLRETURN ret;
ret=SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, );
if (ret != SQL_SUCCESS && ret != SQL_SUCCESS_WITH_INFO) {
cerr << "Failed to allocate handle" << endl;
return -1;
}
ret=SQLSetEnvAttr(env, SQL_ATTR_ODBC_VERSION, (void *)
SQL_OV_ODBC3, 0);
if (ret != SQL_SUCCESS && ret != SQL_SUCCESS_WITH_INFO) {
cerr << "Failed SQLSetEnvAttr" << endl;
return -1;
}
cout << env< driver, sizeof(driver),
_ret,
attr, sizeof(attr), _ret);
if(ret==SQL_NO_DATA) break;
printf("%s - %s\n", driver, attr);
if (ret == SQL_SUCCESS_WITH_INFO) printf("\tdata
truncation\n");
direction = SQL_FETCH_NEXT;
}
return 0;
}
Re: Bug a la instal·lació de postgresql?
Escric ràpid i de memòria perquè tinc poc temps ara mateix, intentaré documentar la resposta millor quan pugui... El 24/9/21 a les 17:58, Alex Muntada ha escrit: [...] - millorar l'script de postinst de postgres perquè utilitzi algun altre mecanisme per canviar a l'usuari postgres Acabo de recordar que fa un temps (oldstable o fins i tot oldoldstable) hi va haver un canvi important a la comanda su, bàsicament hi havia dues implementacions i es va canviar d'una a l'altra per defecte, que tenia algunes subtileses. Crec que es va documentar a les release notes corresponents, a veure si quan pugui ho trobo i ho enllaço. Una de les recomanacions que vaig llegir aleshores era usar la comanda "runuser" quan qui l'executa ja és root, doncs desescala a qualsevol usuari sense demanar autenticació mentre que la resta d'usuaris no la poden executar. No tinc clar si funcionaria en aquest escenari específic que s'ha descrit ni si la presumpció que els postinst s'executen amb permisos de root és sempre certa, per tant no puc valorar si el canvi de su a runuser seria una solució adequada per al paquet.
Re: Bug a la instal·lació de postgresql?
Hola, Julio > la directiva del fitxer > /etc/pam.d/su > és > # auth sufficient pam_rootok.so > Si la descomentem el postgresql funciona.bé, ja que lògicament > ja no demana el pass Confirmo que comentant la directiva em passa el mateix que a vosaltres. Instal·lant dialog em surten els menús de curses per pantalla però la contrasenya no es pregunta amb dialog i per tant no funciona bé. Se m'acuden diferents opcions a explorar: - potser cal tenir instal·lat o activat algun altre component que integri dialog o el que toqui amb el su - millorar l'script de postinst de postgres perquè utilitzi algun altre mecanisme per canviar a l'usuari postgres - instal·lar el postgresql abans de desactivar el pam_rootok > però llavors tenim un "forat" pel ticket de kerberos :) No tinc experiència amb kerberos i no acabo d'entendre això. Vols dir que desactivar el pam_rootok és un requisit per a tenir kerberos? Tenint en compte que root pot afegir fàcilment aquesta directiva un altre cop al fitxer /etc/pam.d/su, no tinc clar què es resol comentant-la (tret que no permetis que root editi aquest fitxer, és clar). -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada ⢿⡄⠘⠷⠚⠋ Debian Developer log.alexm.org ⠈⠳⣄ signature.asc Description: PGP signature
Re: Postgresql ODBC driver not found
On Thu, Sep 23, 2021 at 11:55:00PM +0200, Pierre Couderc wrote:
> Thenk you, Henning, thank you Gregory .
>
> On 9/23/21 5:49 PM, Gregory Seidman wrote:
> > On Thu, Sep 23, 2021 at 08:18:45AM -0400, Henning Follmann wrote:
> > >
> > I don't see where you ask for the PostgreSQL ODBC connection in particular.
> > Maybe I'm the one missing something?
> You are right, I am not trying to connect (not soon) but trying to get the
> list of available drivers !
> >
> > > isql "PostgreSQL Unicode"
> > >
> > > and perform a minimum check like:
> > > select 1;
> >
> SQL> select 1
> ++
> | ?column? |
> ++
> | 1 |
> ++
> SQLRowCount returns 1
> 1 rows fetched
>
> SQL> quit
>
>
> unixodbc seems to work...
yes
>
> I put here the full c++ source and the full result :
>
and I see you do not do any error checking.
This would be a first step to find out where it fails.
I added some code...
>
> #include
> #include
> #include
> #pragma GCC diagnostic ignored "-Wendif-labels"
> #pragma GCC diagnostic ignored "-Wwrite-strings"
>
> #define TDBG clock_t ttdbg=clock();float
> ftdbg=((float)ttdbg)/CLOCKS_PER_SEC;
> #define DBG_(fmt, args...) {TDBG fprintf(stdout,string( string("D%5.1f:ln
> %d:%s(): ")+fmt).c_str(),ftdbg,__LINE__, __func__, ##args);fflush(stdout);}
>
> using namespace std;
> extern "C"
> {
> #include
> #include
> }
> int main(int argc, char **argv)
> {
> DBG_("Start : Compile time : __DATE__ __TIME__\n");
> SQLHENV env;
> SQLCHAR driver[256];
> SQLCHAR attr[256];
> SQLSMALLINT driver_ret;
> SQLSMALLINT attr_ret;
> SQLUSMALLINT direction;
> SQLRETURN ret;
>
ret =
> SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, );
if (ret != SQL_SUCCESS && ret != SQL_SUCCESS_WITH_INFO) { {
/* most likely the odbc env is not set up properly
write error message and bail */
cerr << "Failed to allocate handle" << endl;
return -1;
}
ret =
> SQLSetEnvAttr(env, SQL_ATTR_ODBC_VERSION, (void *) SQL_OV_ODBC3, 0);
/* again, even this function is not guaranteed to succeed
test ! */
>
> cout << env< direction = SQL_FETCH_FIRST;
/* again here you just use the return value for your loop
I think it might be helpful to test for SQL_SUCCESS and
in case it fails to actually handle the error
for error codes check:
https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqldrivers-function?view=sql-server-ver15
*/
> while(SQL_SUCCEEDED (ret = SQLDrivers(env, direction,
> driver, sizeof(driver),
> _ret,
> attr, sizeof(attr), _ret)))
> {
> direction = SQL_FETCH_NEXT;
> printf("%s - %s\n", driver, attr);
> if (ret == SQL_SUCCESS_WITH_INFO) printf("\tdata truncation\n");
> }
> return 0;
> }
>
>
> Result :
>
> nous@pcouderc:~/projets//build$ ./ttest
> D 0.0:ln 33:main(): Start : Compile time : __DATE__ __TIME__
> 0x55b0948ffed0
> nous@pcouderc:~/projets//build$
>
> and meson.build for completeness :
>
> project('ttest','cpp', default_options : ['cpp_std=c++17'],
> version : '0.1')
> cpp = meson.get_compiler('cpp')
> libiodbc_dep = cpp.find_library('libiodbc')
> incdirs = include_directories('/usr/include/iodbc')
> executable('ttest', 'main.cpp', dependencies : [libiodbc_dep],
> include_directories : incdirs)
>
>
>
--
Henning Follmann | hfollm...@itcfollmann.com
Re: Bug a la instal·lació de postgresql?
Hola Àlex, la directiva del fitxer /etc/pam.d/su és # auth sufficient pam_rootok.so Si la descomentem el postgresql funciona.bé, ja que lògicament ja no demana el pass, però llavors tenim un "forat" pel ticket de kerberos :) ... Has de descomentar la 2a línia. S'entèn? Le 23 septembre 2021 21:38:09 GMT+02:00, Alex Muntada a écrit : >Hola, Julio > >> ... com que a la configuració del nostre pam teníem una >> directiva que obligava a root a demanar password quan feia su >> l'script d'instal·lació es parava demanant un password, però >> tant era el que escriguessis, o que en una altra terminal >> posessis el password a l'usuari postgres. > >Podríeu donar més detalls de la directiva que teníeu al PAM? > >> El fitxer és >> /var/lib/dpkg/info/postgresql-common.postinst >> >> I la instrucció: >> >> * su -s /bin/sh postgres -c "test -O /var/lib/postgresql && >> test -G /var/lib/postgresql" || \chown postgres:postgres >> /var/lib/postgresql* > >Ho he provat en un contenidor de docker i funciona perfectament, >fins i tot si li poso contrasenya a l'usuari postgres. > >> Vam trobar referències a: >> https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/1528822/comments/1 > >Tal com comenten en aquest bug, té pinta que el problema està a >la configuració de PAM i no pas al paquet de postgresql. Si no >passava a la versió 12 pot ser per molts motius, entre els quals >també hi ha que la versió de libpam segurament també és diferent. > >Salut, >Alex > >-- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada > ⢿⡄⠘⠷⠚⠋ Debian Developer log.alexm.org > ⠈⠳⣄ > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Postgresql ODBC driver not found
Thenk you, Henning, thank you Gregory .
On 9/23/21 5:49 PM, Gregory Seidman wrote:
On Thu, Sep 23, 2021 at 08:18:45AM -0400, Henning Follmann wrote:
I don't see where you ask for the PostgreSQL ODBC connection in particular.
Maybe I'm the one missing something?
You are right, I am not trying to connect (not soon) but trying to get
the list of available drivers !
isql "PostgreSQL Unicode"
and perform a minimum check like:
select 1;
SQL> select 1
++
| ?column? |
++
| 1 |
++
SQLRowCount returns 1
1 rows fetched
SQL> quit
unixodbc seems to work...
I put here the full c++ source and the full result :
#include
#include
#include
#pragma GCC diagnostic ignored "-Wendif-labels"
#pragma GCC diagnostic ignored "-Wwrite-strings"
#define TDBG clock_t ttdbg=clock();float
ftdbg=((float)ttdbg)/CLOCKS_PER_SEC;
#define DBG_(fmt, args...) {TDBG fprintf(stdout,string(
string("D%5.1f:ln %d:%s(): ")+fmt).c_str(),ftdbg,__LINE__, __func__,
##args);fflush(stdout);}
using namespace std;
extern "C"
{
#include
#include
}
int main(int argc, char **argv)
{
DBG_("Start : Compile time : __DATE__ __TIME__\n");
SQLHENV env;
SQLCHAR driver[256];
SQLCHAR attr[256];
SQLSMALLINT driver_ret;
SQLSMALLINT attr_ret;
SQLUSMALLINT direction;
SQLRETURN ret;
SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, );
SQLSetEnvAttr(env, SQL_ATTR_ODBC_VERSION, (void *) SQL_OV_ODBC3, 0);
cout << env< driver, sizeof(driver),
_ret,
attr, sizeof(attr),
_ret))) {
direction = SQL_FETCH_NEXT;
printf("%s - %s\n", driver, attr);
if (ret == SQL_SUCCESS_WITH_INFO) printf("\tdata
truncation\n");
}
return 0;
}
Result :
nous@pcouderc:~/projets//build$ ./ttest
D 0.0:ln 33:main(): Start : Compile time : __DATE__ __TIME__
0x55b0948ffed0
nous@pcouderc:~/projets//build$
and meson.build for completeness :
project('ttest','cpp', default_options : ['cpp_std=c++17'],
version : '0.1')
cpp = meson.get_compiler('cpp')
libiodbc_dep = cpp.find_library('libiodbc')
incdirs = include_directories('/usr/include/iodbc')
executable('ttest', 'main.cpp', dependencies : [libiodbc_dep],
include_directories : incdirs)
Re: Bug a la instal·lació de postgresql?
Hola, Julio > ... com que a la configuració del nostre pam teníem una > directiva que obligava a root a demanar password quan feia su > l'script d'instal·lació es parava demanant un password, però > tant era el que escriguessis, o que en una altra terminal > posessis el password a l'usuari postgres. Podríeu donar més detalls de la directiva que teníeu al PAM? > El fitxer és > /var/lib/dpkg/info/postgresql-common.postinst > > I la instrucció: > > *su -s /bin/sh postgres -c "test -O /var/lib/postgresql && > test -G /var/lib/postgresql" || \chown postgres:postgres > /var/lib/postgresql* Ho he provat en un contenidor de docker i funciona perfectament, fins i tot si li poso contrasenya a l'usuari postgres. > Vam trobar referències a: > https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/1528822/comments/1 Tal com comenten en aquest bug, té pinta que el problema està a la configuració de PAM i no pas al paquet de postgresql. Si no passava a la versió 12 pot ser per molts motius, entre els quals també hi ha que la versió de libpam segurament també és diferent. Salut, Alex -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada ⢿⡄⠘⠷⠚⠋ Debian Developer log.alexm.org ⠈⠳⣄ signature.asc Description: PGP signature
Re: Postgresql ODBC driver not found
On Thu, Sep 23, 2021 at 08:18:45AM -0400, Henning Follmann wrote:
> On Thu, Sep 23, 2021 at 08:44:42AM +0200, Pierre Couderc wrote:
> > Thank you very much!
> >
> > See below :
> >
> > On 9/22/21 3:37 PM, Henning Follmann wrote:
> > > On Wed, Sep 22, 2021 at 11:07:28AM +0200, Pierre Couderc wrote:
> > > > It is here I see it/them with:
> > > >
> > > > odbcinst -q -d
> > > >
> > > > but not with :
> > > >
> > > > SQLHENV env;
> > > > SQLCHAR driver[256];
> > > > SQLCHAR attr[256];
> > > > SQLSMALLINT driver_ret;
> > > > SQLSMALLINT attr_ret;
> > > > SQLUSMALLINT direction;
> > > > SQLRETURN ret;
> > > > SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, );
> > > > SQLSetEnvAttr(env, SQL_ATTR_ODBC_VERSION, (void *) SQL_OV_ODBC3, 0);
> > > >
> > > > direction = SQL_FETCH_FIRST;
> > > > while(SQL_SUCCEEDED(ret = SQLDrivers(env, direction,
> > > > driver, sizeof(driver),
> > > > _ret,
> > > > attr, sizeof(attr),
> > > > _ret))) {
> > > > direction = SQL_FETCH_NEXT;
> > > > printf("%s - %s\n", driver, attr);
> > > > if (ret == SQL_SUCCESS_WITH_INFO) printf("\tdata truncation\n");
> > > > }
> > > >
> > > > What do I miss...?
I don't see where you ask for the PostgreSQL ODBC connection in particular.
Maybe I'm the one missing something?
> > > The ability to clearly describe your problem!
> > Sorry I tried to be minimum... But here are more details?
>
> Not sorry, but what do you expect? That everybody has a magic crystal
> bowl to fill in missing information?
Hey, ease up. Missing information makes it harder to diagnose the issue,
but there is no need to be rude about it.
[...]
> > >Did you compile it? And if so, how?
> > Yes, with default tools (gcc under debian bulllseye linked with libodbc)
>
> Are you kidding me? That is not additional information. Just you
> being condescending.
> Strike one.
>
> > >You installed odbcunix I assume.
> > >How did you configure it?
> > Correctly.
>
> Really? REALLY?
> Strike two.
Wow, seriously rude.
[...]
> can you please connect to your database with:
>
> isql "PostgreSQL Unicode"
>
> and perform a minimum check like:
> select 1;
[...]
That's helpful, and I look forward to seeing the response to this.
> -H
>
> --
> Henning Follmann | hfollm...@itcfollmann.com
--Gregory
Re: Postgresql ODBC driver not found
On Thu, Sep 23, 2021 at 08:44:42AM +0200, Pierre Couderc wrote:
> Thank you very much!
>
> See below :
>
> On 9/22/21 3:37 PM, Henning Follmann wrote:
> > On Wed, Sep 22, 2021 at 11:07:28AM +0200, Pierre Couderc wrote:
> > > It is here I see it/them with:
> > >
> > > odbcinst -q -d
> > >
> > > but not with :
> > >
> > > SQLHENV env;
> > > SQLCHAR driver[256];
> > > SQLCHAR attr[256];
> > > SQLSMALLINT driver_ret;
> > > SQLSMALLINT attr_ret;
> > > SQLUSMALLINT direction;
> > > SQLRETURN ret;
> > > SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, );
> > > SQLSetEnvAttr(env, SQL_ATTR_ODBC_VERSION, (void *) SQL_OV_ODBC3, 0);
> > >
> > > direction = SQL_FETCH_FIRST;
> > > while(SQL_SUCCEEDED(ret = SQLDrivers(env, direction,
> > > driver, sizeof(driver),
> > > _ret,
> > > attr, sizeof(attr), _ret))) {
> > > direction = SQL_FETCH_NEXT;
> > > printf("%s - %s\n", driver, attr);
> > > if (ret == SQL_SUCCESS_WITH_INFO) printf("\tdata truncation\n");
> > > }
> > >
> > > What do I miss...?
> > >
> > The ability to clearly describe your problem!
> Sorry I tried to be minimum... But here are more details?
Not sorry, but what do you expect? That everybody has a magic crystal bowl to
fill in missing information?
> >
> > What did you do?
> >I assume you wrote some c code.
> Yes, this code above is written in c (c++ in fact but I have simplified).
That is not c code. This does not compile.
Provide a minimum example which compiles, at least.
> >Did you compile it? And if so, how?
> Yes, with default tools (gcc under debian bulllseye linked with libodbc)
Are you kidding me? That is not additional information. Just you
being condescending.
Strike one.
> >You installed odbcunix I assume.
> >How did you configure it?
> Correctly.
Really? REALLY?
Strike two.
> >What is the output of "odbcinst -q -d"?
>
> Correct :
>
> [PostgreSQL ANSI]
> [PostgreSQL Unicode]
>
all right that is something.
can you please connect to your database with:
isql "PostgreSQL Unicode"
and perform a minimum check like:
select 1;
> > What did you expect?
> That my c program produces the same list
> >
> > What did not work?
> > Include logs, error messages.
>
> Logs and error messages : none (This is the heart of the problem)
>
> >
> > What did you do to solve your problem so far?
> >
> I have reduced my problem - which is much more complex - to the simplest
> test prograam.
>
> And I ask for help, as I have no more idea after many hours.
>
>
You know this is a debian user mailing list, right?
but anyway...
-H
--
Henning Follmann | hfollm...@itcfollmann.com
Re: Postgresql ODBC driver not found
Thank you very much!
See below :
On 9/22/21 3:37 PM, Henning Follmann wrote:
On Wed, Sep 22, 2021 at 11:07:28AM +0200, Pierre Couderc wrote:
It is here I see it/them with:
odbcinst -q -d
but not with :
SQLHENV env;
SQLCHAR driver[256];
SQLCHAR attr[256];
SQLSMALLINT driver_ret;
SQLSMALLINT attr_ret;
SQLUSMALLINT direction;
SQLRETURN ret;
SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, );
SQLSetEnvAttr(env, SQL_ATTR_ODBC_VERSION, (void *) SQL_OV_ODBC3, 0);
direction = SQL_FETCH_FIRST;
while(SQL_SUCCEEDED(ret = SQLDrivers(env, direction,
driver, sizeof(driver), _ret,
attr, sizeof(attr), _ret))) {
direction = SQL_FETCH_NEXT;
printf("%s - %s\n", driver, attr);
if (ret == SQL_SUCCESS_WITH_INFO) printf("\tdata truncation\n");
}
What do I miss...?
The ability to clearly describe your problem!
Sorry I tried to be minimum... But here are more details?
What did you do?
I assume you wrote some c code.
Yes, this code above is written in c (c++ in fact but I have simplified).
Did you compile it? And if so, how?
Yes, with default tools (gcc under debian bulllseye linked with libodbc)
You installed odbcunix I assume.
How did you configure it?
Correctly.
What is the output of "odbcinst -q -d"?
Correct :
[PostgreSQL ANSI]
[PostgreSQL Unicode]
What did you expect?
That my c program produces the same list
What did not work?
Include logs, error messages.
Logs and error messages : none (This is the heart of the problem)
What did you do to solve your problem so far?
I have reduced my problem - which is much more complex - to the simplest
test prograam.
And I ask for help, as I have no more idea after many hours.
Re: Postgresql ODBC driver not found
On Wed, Sep 22, 2021 at 11:07:28AM +0200, Pierre Couderc wrote:
> It is here I see it/them with:
>
> odbcinst -q -d
>
> but not with :
>
> SQLHENV env;
> SQLCHAR driver[256];
> SQLCHAR attr[256];
> SQLSMALLINT driver_ret;
> SQLSMALLINT attr_ret;
> SQLUSMALLINT direction;
> SQLRETURN ret;
> SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, );
> SQLSetEnvAttr(env, SQL_ATTR_ODBC_VERSION, (void *) SQL_OV_ODBC3, 0);
>
> direction = SQL_FETCH_FIRST;
> while(SQL_SUCCEEDED(ret = SQLDrivers(env, direction,
> driver, sizeof(driver), _ret,
> attr, sizeof(attr), _ret))) {
> direction = SQL_FETCH_NEXT;
> printf("%s - %s\n", driver, attr);
> if (ret == SQL_SUCCESS_WITH_INFO) printf("\tdata truncation\n");
> }
>
> What do I miss...?
>
The ability to clearly describe your problem!
What did you do?
I assume you wrote some c code.
Did you compile it? And if so, how?
You installed odbcunix I assume.
How did you configure it?
What is the output of "odbcinst -q -d"?
What did you expect?
What did not work?
Include logs, error messages.
What did you do to solve your problem so far?
-H
--
Henning Follmann | hfollm...@itcfollmann.com
Postgresql ODBC driver not found
It is here I see it/them with:
odbcinst -q -d
but not with :
SQLHENV env;
SQLCHAR driver[256];
SQLCHAR attr[256];
SQLSMALLINT driver_ret;
SQLSMALLINT attr_ret;
SQLUSMALLINT direction;
SQLRETURN ret;
SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, );
SQLSetEnvAttr(env, SQL_ATTR_ODBC_VERSION, (void *) SQL_OV_ODBC3, 0);
direction = SQL_FETCH_FIRST;
while(SQL_SUCCEEDED(ret = SQLDrivers(env, direction,
driver, sizeof(driver), _ret,
attr, sizeof(attr), _ret))) {
direction = SQL_FETCH_NEXT;
printf("%s - %s\n", driver, attr);
if (ret == SQL_SUCCESS_WITH_INFO) printf("\tdata truncation\n");
}
What do I miss...?
(under debian bulllseye linked with libodbc)
Thanks in advance
PC
Re: Bug a la instal·lació de postgresql?
Hola Julio, El que em sorprén en aquella instrucció no es tant el que demani un password > Doncs és precisament això, el que em sorprèn... que demani un password. En principi, des de qualsevol shell de root hauríem de poder connectar-nos a qualsevol usuari amb shell, sense necessitat de proporcionar cap password. I per tant, també a postgres. L'única cosa que puc suggerir, ja que actualment no tinc gaire per la ma això del PAM, és verificar si l'script que conté la instrucció s'executa efectivament amb els permisos de root. Potser podries provar amb la comanda id -u dins l'script. Espero que et serveixi. David Gasa i Castell Linux User #488832
Re: Bug a la instal·lació de postgresql?
Le 21 septembre 2021 08:01:43 GMT+02:00, jordi Perera a écrit : >On 20/9/21 23:56, Julio Amorós wrote: >> Hola, >> ../.. a la configuració del nostre pam teníem una >> directiva que obligava a root a demanar password quan feia su > ../.. >> >> I la instrucció: >> >> * su -s /bin/sh postgres -c "test -O /var/lib/postgresql && >> test -G /var/lib/postgresql" || \ >> chown postgres:postgres /var/lib/postgresql* >> >../.. >> Gràcies per llegir-nos, >> Julio > >Fins on jo se, l'usuari postgres no te password i per seguretat no n'ha >de tenir. > >Potser teniu una situació impossible, el pam obliga a demanar un >password que no existeix. > >No se si dir que és un bug del instal·lador postgres o una "feature" de pam. > Amb Fedora teníem la mateixa situació a Pam i no es donava aquest problema i la única diferència és la versió de Postgresql. Efectivament la 1a cosa que feiem després d'instal•lar postgresql era posar-li un password a postgres. El que em sorprén en aquella instrucció no es tant el que demani un password, sinó perquè no ho rep i després es queixa, sembla com si alguna pipe o caràcter de escape no fes la feina des de l'script. O m'ho sembla a mi. Vagi bé, Julio -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Bug a la instal·lació de postgresql?
On 20/9/21 23:56, Julio Amorós wrote: Hola, ../.. a la configuració del nostre pam teníem una directiva que obligava a root a demanar password quan feia su > ../.. I la instrucció: * su -s /bin/sh postgres -c "test -O /var/lib/postgresql && test -G /var/lib/postgresql" || \ chown postgres:postgres /var/lib/postgresql* ../.. Gràcies per llegir-nos, Julio Fins on jo se, l'usuari postgres no te password i per seguretat no n'ha de tenir. Potser teniu una situació impossible, el pam obliga a demanar un password que no existeix. No se si dir que és un bug del instal·lador postgres o una "feature" de pam. -- Jordi Perera
Bug a la instal·lació de postgresql?
Hola, tencara no tenim tots els grups treballant amb Debian (demà amb sort acabarem) i estem contents, això no treu que ja hem detectat alguns problemes. El més important ja us el comentarem un altre dia (està relacionat amb l'exportació de carpetes mitjançant un NFS kerberitzat, que ara es munten, ara es desmunten de manera màgica ... ) Però us volia preguntar per un possible bug que podria haver en un paquet de postgresql. El cas és que instal·lem la versió que hi ha per defecte a Debian 11, que és la 13 i com que a la configuració del nostre pam teníem una directiva que obligava a root a demanar password quan feia su l'script d'instal·lació es parava demanant un password, però tant era el que escriguessis, o que en una altra terminal posessis el password a l'usuari postgres. Al final, la única manera va ser fent un kill del procès d'aquella instrucció. D'aquest amanera l'script continuava i la instal·lació acabava amb èxit. El fitxer és /var/lib/dpkg/info/postgresql-common.postinst I la instrucció: *su -s /bin/sh postgres -c "test -O /var/lib/postgresql && test -G /var/lib/postgresql" || \chown postgres:postgres /var/lib/postgresql* Vam trobar referències a: https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/1528822/comments/1 Gràcies per llegir-nos, Julio -- __ - El 2003 el català era la llengua habitual del 46 % dels catalans. Al 2018 només del 36 %. Si els castellanoparlants no actuem, desapareixerà. - El 3 de novembre representa el moment de l'any en el que les dones deixen de cobrar en comparació amb els homes. Hem d’ajudar a les dones a eliminar aquesta data. - L’administració pública cada any es gasta milions d’euros en llicències de programari privatiu. Utilitzant programari lliure estalviem costos i incentivem l’economia local. *La neutralitat davant les desigualtats acaba accentuant-les.*
Re: Comparaison de bases de données PostgreSQL
Olivier a écrit : > Quels outils et méthodes me conseillez-vous d'utiliser pour comparer > deux bases de données PostgreSQL Si d'aventure ta question ne trouve aucune réponse sur cette liste, je t'invite à la poser sur la liste ou le forum de la communauté francophone de PostgreSQL : Site : https://www.postgresql.fr/ Forum : https://forum.postgresql.fr/ Liste : https://www.postgresql.org/list/pgsql-fr-generale/ On y croise quelques spécialistes pointus et autres contributeurs de PostgreSQL. Sinon, une rapide recherche m'a montré que l'outil pg_admin proposait une fonction de visualisation des différences entre deux schémas : https://www.pgadmin.org/docs/pgadmin4/development/schema_diff.html Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://www.palabritudes.net/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
Re: Comparaison de bases de données PostgreSQL
On Fri, Jun 04, 2021 at 12:14:51PM +0200, Olivier wrote a message of 49 lines which said: > Quels outils et méthodes me conseillez-vous d'utiliser pour comparer > deux bases de données PostgreSQL (droits, structure, données) pg_dump (avec évidemment les mêmes options des deux côtés) et diff ? Pas sûr que ça marche, car le dump n'est pas forcément dans un ordre déterministe mais ça vaudrait le coup d'essayer.
Comparaison de bases de données PostgreSQL
Bonjour, Quels outils et méthodes me conseillez-vous d'utiliser pour comparer deux bases de données PostgreSQL (droits, structure, données) dans le cas où je souhaite vérifier ma capacité à restaurer sur un nouvel hôte, une base de données PostgreSQL sauvegardée avec barman. L'ancien et le nouvel hôte sont des VM sous Debian Buster tout comme la machine héberge barman. PostgreSQL est la version du dépôt Debian stable. Si l'opération est entièrement scriptable, ça serait apprécié (pour que je puisse régulièrement) vérifier ma capacité de restauration. Est-il possible d'utiliser les mêmes outils et méthodes pour faire la même comparaison, quand un hôte est sous Bullseye ? Slts
PostgreSQL et réplication
Bonjour à tous, Petit problème du jour avec une réplication PostgreSQL (11). J'utilise une base de données conséquentes sur un site A. Sur le site B, distant, j'ai installé une réplication de la base de données en question. Cette réplication fonctionne. Le maître vient de partir en vrille parce que /var était plein... Problème : les fichiers d'archive de la base principale ne sont jamais effacés : postgres@rayleigh:~/11/archive$ ls -1 000100010085 000100010085.0028.backup 000100010086 Tous les jours, je me prends un fichier supplémentaire. Dans la doc de PostgreSQL, je vois qu'on peut utiliser dans le fichier recovery.conf de la réplique la commande archive_cleanup_command = 'pg_archivecleanup /var/lib/postgresql/11/archive %r', ce qui suppose tout de même que l'arborescence du maître est montée sur l'esclave. Cela pourrait se faire, il y a un VPN entre les deux. Mais dans mon cas, les uid/gid des maître et esclave sont différents, donc ça ne va pas pouvoir se faire en claquant des doigts. D'où ma question : existe-t-il un moyen dans PosgreSQL d'indiquer au maître qu'il peut effacer les fichiers d'archive sans en passer par une verrue de style pg_archivecleanup dans un cron ? Bien cordialement, JKB
Re: exemple de ~/.pgpass qui marche (PostGreSQL/Debian/Buster) - et aide souhaitée en OpenStreetMap.
Hello, On Sun, Mar 22, 2020 at 04:34:46PM +0100, Basile Starynkevitch wrote: > S'il y a des gens pour m'aider sur https://github.com/bstarynk/helpcovid ils > sont bienvenus. Mais en anglais s'il vous plait, le contributeur le plus > actif étant indien. J'ai perdu le mail où tu annonces ton projet, mais j'ai l'impression que ça existe déjà sous le nom "en première ligne" (je ne connais pas plus l'application que ça car c'est madame qui s'en ai servi, mais je sais que ça marche déjà) Y.
Re: exemple de ~/.pgpass qui marche (PostGreSQL/Debian/Buster) - et aide souhaitée en OpenStreetMap.
Bonjour, Le dimanche 22 mars 2020, Basile Starynkevitch a écrit... > En français, pour le projet https://github.com/bstarynk/helpcovid (GPLv3+, > en cours d'écriture) j'ai du mal à faire un fichier ~/.pgpass qui marche. Voilà un fichier que j'ai chez moi sur localhost. 127.0.0.1:5433:MYDB:jm:myPassword 127.0.0.1:5433:MYDB:webrequest:anotherPassword J'en ai un autre sur un autre serveur, si celui là ne te suffisait pas. -- jm
exemple de ~/.pgpass qui marche (PostGreSQL/Debian/Buster) - et aide souhaitée en OpenStreetMap.
Bonjour la liste En anglais ma question est https://unix.stackexchange.com/q/574269/50557 En français, pour le projet https://github.com/bstarynk/helpcovid (GPLv3+, en cours d'écriture) j'ai du mal à faire un fichier ~/.pgpass qui marche. La base de donnée, le serveur postgresql, le programme helpcovid sonnt sur localhost et en cours de déboguage, donc on veut éviter sudo. S'il y a des gens pour m'aider sur https://github.com/bstarynk/helpcovid ils sont bienvenus. Mais en anglais s'il vous plait, le contributeur le plus actif étant indien. En particuler, je manque de compétence en OpenStreetMap. Par compétence je veux dire git commit-s. Librement -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France; (mobile phone: cf my web page / voir ma page web...)
Re: Postgresql logging problem
Solved: changing the ownership of the custom log in conf.d solved the problem. Regards Johann On Tue, 3 Dec 2019 at 17:14, Johann Spies wrote: > We have upgraded two servers by installing postgresql(pgpd) 12. Both > servers are running Debian Stable. > > On the problem server we have: > pg_lsclusters > Ver Cluster Port Status OwnerData directory Log file > 11 main5432 online postgres /var/lib/postgresql/11/main > /var/log/postgresql/postgresql-11-main.log > 12 main5434 online postgres /var/lib/postgresql/12/main > /var/log/postgresql/postgresql-12-main.log > > But nothing gets written to the logfiles. In stead the logs appear on the > console when the user postgresql is connecting to the database. > > On the other server: > $ pg_lsclusters > Ver Cluster Port Status OwnerData directory Log file > 11 main5433 down postgres /var/lib/postgresql/11/main > /var/log/postgresql/postgresql-11-main.log > 12 main5432 online postgres /var/lib/postgresql/12/main > /var/log/postgresql/postgresql-12-main.log > > The logging works as expected. > > The postgresql.conf for version 12 is identical on both servers - the > default installed by Debian. > > This is with logging_collector off. > > When switching logging_collector on on the problem server, it logs to > /var/lib/postgresql/11/main/log/. > > Our preference would be to have the logs on both servers in > /var/log/postgresql. > > Where do we look for the cause of this behaviour? On both servers the > configuration for rsyslog seems to be identical. > > Regards. > > Johann > > > > -- > Because experiencing your loyal love is better than life itself, > my lips will praise you. (Psalm 63:3) > -- Because experiencing your loyal love is better than life itself, my lips will praise you. (Psalm 63:3)
Postgresql logging problem
We have upgraded two servers by installing postgresql(pgpd) 12. Both servers are running Debian Stable. On the problem server we have: pg_lsclusters Ver Cluster Port Status OwnerData directory Log file 11 main5432 online postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log 12 main5434 online postgres /var/lib/postgresql/12/main /var/log/postgresql/postgresql-12-main.log But nothing gets written to the logfiles. In stead the logs appear on the console when the user postgresql is connecting to the database. On the other server: $ pg_lsclusters Ver Cluster Port Status OwnerData directory Log file 11 main5433 down postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log 12 main5432 online postgres /var/lib/postgresql/12/main /var/log/postgresql/postgresql-12-main.log The logging works as expected. The postgresql.conf for version 12 is identical on both servers - the default installed by Debian. This is with logging_collector off. When switching logging_collector on on the problem server, it logs to /var/lib/postgresql/11/main/log/. Our preference would be to have the logs on both servers in /var/log/postgresql. Where do we look for the cause of this behaviour? On both servers the configuration for rsyslog seems to be identical. Regards. Johann -- Because experiencing your loyal love is better than life itself, my lips will praise you. (Psalm 63:3)
Re: postgresql-12 - crash. Any hints.
On Di, Nov 05, 2019 at 10:42:28 +0100, Kamil Jońca wrote: I migrate databases, and during last few days I have had 2 server crashes. I have similiar signal 11 crashes after the upgrade (pg_upgradecluster). Maybe you should keep your hands from version 12. Shade and sweet water! Stephan -- |If your life was a horse, you'd have to shoot it.|
Re: postgresql-12 - crash. Any hints.
deloptes writes: > Kamil Jońca wrote: > [...] > > also perhaps consider contacting application maintenance I did. Issued bug at postgres. > > why do you write here? Isn't there a postgres mailing list? To warn someone before premature upgrading :-P KJ -- http://wolnelektury.pl/wesprzyj/teraz/ A man who fishes for marlin in ponds will put his money in Etruscan bonds.
Re: postgresql-12 - crash. Any hints.
Kamil Jońca wrote: > Today was another crash. > Another piece of a puzzle: There is (unlogged) table with 70M+ > rows. After crash this table is empty (but table itself exists.) read documentation fine tune postgres be happy also perhaps consider contacting application maintenance why do you write here? Isn't there a postgres mailing list?
Re: postgresql-12 - crash. Any hints.
kjo...@poczta.onet.pl (Kamil Jońca) writes: > It is home PC box with debian sid. > Recently my postgres was upgraded from version 11 to 12. > I migrate databases, and during last few days I have had 2 server > crashes. > Crashes were during different statements. And after crash these > statements executed successfully. > In log I have: > === > 2019-11-04 00:07:38 CET LOG: server process (PID 19244) was terminated by > signal 11: Segmentation fault > 2019-11-04 00:07:38 CET DETAIL: Failed process was running: update queue set > priority = -3 ; > 2019-11-04 00:07:38 CET LOG: terminating any other active server processes > [...] > 2019-11-04 00:07:39 CET LOG: all server processes terminated; reinitializing > 2019-11-04 00:07:39 CET DEBUG: mmap(150994944) with MAP_HUGETLB failed, huge > pages disabled: Cannot allocate memory > 2019-11-04 00:07:39 CET LOG: database system was interrupted; last known up > at 2019-11-04 00:02:24 CET > === > 2019-11-05 21:43:56 CET LOG: server process (PID 23233) was terminated by > signal 11: Segmentation fault > 2019-11-05 21:43:56 CET DETAIL: Failed process was running: SELECT po_nr > FROM get_free_numbers(999); > 2019-11-05 21:43:56 CET LOG: terminating any other active server processes > [...] > 2019-11-05 21:43:57 CET LOG: all server processes terminated; reinitializing > 2019-11-05 21:43:57 CET DEBUG: mmap(150994944) with MAP_HUGETLB failed, huge > pages disabled: Cannot allocate memory > 2019-11-05 21:43:58 CET LOG: database system was interrupted; last known up > at 2019-11-05 21:43:49 CET > === > > any hints? > > KJ Today was another crash. Another piece of a puzzle: There is (unlogged) table with 70M+ rows. After crash this table is empty (but table itself exists.) KJ -- http://wolnelektury.pl/wesprzyj/teraz/ If A equals success, then the formula is _A = _X + _Y + _Z. _X is work. _Y is play. _Z is keep your mouth shut. -- Albert Einstein
postgresql-12 - crash. Any hints.
It is home PC box with debian sid. Recently my postgres was upgraded from version 11 to 12. I migrate databases, and during last few days I have had 2 server crashes. Crashes were during different statements. And after crash these statements executed successfully. In log I have: === 2019-11-04 00:07:38 CET LOG: server process (PID 19244) was terminated by signal 11: Segmentation fault 2019-11-04 00:07:38 CET DETAIL: Failed process was running: update queue set priority = -3 ; 2019-11-04 00:07:38 CET LOG: terminating any other active server processes [...] 2019-11-04 00:07:39 CET LOG: all server processes terminated; reinitializing 2019-11-04 00:07:39 CET DEBUG: mmap(150994944) with MAP_HUGETLB failed, huge pages disabled: Cannot allocate memory 2019-11-04 00:07:39 CET LOG: database system was interrupted; last known up at 2019-11-04 00:02:24 CET === 2019-11-05 21:43:56 CET LOG: server process (PID 23233) was terminated by signal 11: Segmentation fault 2019-11-05 21:43:56 CET DETAIL: Failed process was running: SELECT po_nr FROM get_free_numbers(999); 2019-11-05 21:43:56 CET LOG: terminating any other active server processes [...] 2019-11-05 21:43:57 CET LOG: all server processes terminated; reinitializing 2019-11-05 21:43:57 CET DEBUG: mmap(150994944) with MAP_HUGETLB failed, huge pages disabled: Cannot allocate memory 2019-11-05 21:43:58 CET LOG: database system was interrupted; last known up at 2019-11-05 21:43:49 CET === any hints? KJ -- http://wolnelektury.pl/wesprzyj/teraz/ we: The single most important word in the world.
Re: duvida postgresql base de usuarios
Le lun. 29 juil. 2019 à 12:39, Vitor Hugo a écrit : > > Adicionando os usuários localmente em /etc/passwd se tem a autenticação > em serviços de RAS, E-Mail e WWW, porem isto não fica centralizado e > fora de uma base de dados SQL. O que você queria seriam serviços de RAS, correio eletrônico e HTTP que usem SQL como base de dados de usuário, certo? Creio que essa é uma função dos programas que oferecem esses serviços. No caso de correio eletrônico, tem o Archiveopteryx <http://archiveopteryx.org/>, que armazena as caixas postais em PostgreSQL. Nunca verifiquei se armazena assim também a base de usuários, mas imagino que sim. -- +55 (61) 3546 7191xmpp:leand...@jabber.org +55 (61) 99302 2691 +55 (61) 3216 3613 Brasília, DF, Brazil GMT−3 https://useplaintext.email/
Re: duvida postgresql base de usuarios
Adicionando os usuários localmente em /etc/passwd se tem a autenticação em serviços de RAS, E-Mail e WWW, porem isto não fica centralizado e fora de uma base de dados SQL. Em 27/07/2019 21:38, Guimarães Faria Corcete DUTRA, Leandro escreveu: > Le ven. 26 juil. 2019 à 21:30, Vitor Hugo a écrit : >> Como criar uma base de usuários (nome/senha) para utilização de >> RAS/E-MAIL/WWW em um banco de dados PostgreSQL? > Podes explicar melhor? > >
Re: duvida postgresql base de usuarios
Le ven. 26 juil. 2019 à 21:30, Vitor Hugo a écrit : > > Como criar uma base de usuários (nome/senha) para utilização de > RAS/E-MAIL/WWW em um banco de dados PostgreSQL? Podes explicar melhor? -- +55 (61) 3546 7191xmpp:leand...@jabber.org +55 (61) 99302 2691 +55 (61) 3216 3613 Brasília, DF, Brazil GMT−3 https://useplaintext.email/
duvida postgresql base de usuarios
Como criar uma base de usuários (nome/senha) para utilização de RAS/E-MAIL/WWW em um banco de dados PostgreSQL?
Re: Upgrading to Buster but keeping Postgresql-9.6
Hi Phil, > Thanks Richard, that looks like the best solution. They even > have a mailing list. I have have really enjoyed using docker for such issues - mix useland as you like it - without interfering with you "main" distribution and without any performance overhead. Br, Clemens Br, Clemens
Re: Upgrading to Buster but keeping Postgresql-9.6
Richard Hector wrote: Another option is to switch to using the pgdg repo for 9.6: https://wiki.postgresql.org/wiki/Apt Thanks Richard, that looks like the best solution. They even have a mailing list. Cheers, Phil.
Re: Upgrading to Buster but keeping Postgresql-9.6
Phil Endecott [2019-07-08T22:24:17+01] wrote:
> Indeed, not upgrading to Buster is a possibility. Also upgrading
> PostgreSQL to version 11 is a possibility. I think I understand the
> issues with each of those options, but I don't have a good
> understanding of the issues with trying to keep pg-9.6 on Buster.
Your PostgreSQL use seems to be far more advanced than mine so don't
take this as recommendation. I will just describe what I remember from
upgrades. I think I have upgraded Debian PostgreSQL three times now and
last time just a couple of days ago from 9.6 (Debian 9) to 11 (Debian
10).
- Debian meta package "postgresql" depends on the supported version of
database server. Debian distribution upgrade from Debian 9 to 10
upgrades the meta package and it brings new version of PostgreSQL.
- On upgrade (install of postgresql-11) the old version
(postgresql-9.6) is kept but the server is shut down and it won't be
started automatically anymore on system boot. All databases remain.
I _think_ that the old version still works.
- After upgrade the new version is started automatically but does not
contain the database cluster(s) of the old version. Clusters must be
upgraded manually with commands:
systemctl stop postgresql # stop v11
pg_dropcluster 11 main # remove v11's default "main" cluster
pg_upgradecluster 9.6 main # convert "main" from v9.6 to v11
systemctl start postgresql # start v11
- If PostgreSQL server software is removed (apt remove postgresql-9.6)
the actual database cluster data still remains under
/var/lib/postgresql directory. If the server software is purged (apt
purge postgresql-9.6) then the data is also removed.
--
/// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
// https://keys.openpgp.org/search?q=tliko...@iki.fi
/ https://keybase.io/tlikonen https://github.com/tlikonen
signature.asc
Description: PGP signature
Re: Upgrading to Buster but keeping Postgresql-9.6
On Lu, 08 iul 19, 22:24:17, Phil Endecott wrote:
> Andrei POPESCU wrote:
> >
> > Is upgrading to buster a necessity? Stretch will be supported by Debian
> > for one more year and probably some more by the LTS effort.
>
> Indeed, not upgrading to Buster is a possibility. Also upgrading PostgreSQL
> to version 11 is a possibility. I think I understand the issues with each
> of those options, but I don't have a good understanding of the issues with
> trying to keep pg-9.6 on Buster.
You can test that yourself as follows:
1. debootstrap buster in an empty directory.
2. chroot to it and add stretch to sources.list[1]
3. try to 'apt install' PostgreSQL forcing the version from stretch
('-t stretch' might work, otherwise you must use package/version)
Or just install buster in a VM.
If you need more help with any of the steps please do post exactly what
you did (full commands and output) as well as the output of
'apt policy'.
In case you get unresolvable dependency conflicts another option might
be to recompile the stretch PostgreSQL package(s) on buster (i.e.
forward-port), if the build dependencies are satisfiable on buster.
[1] setting Default-Release to buster or pinning recommended, but
probably not required, because apt *should* prefer the newer packages,
unless told to do otherwise (i.e. '-t stretch').
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
signature.asc
Description: PGP signature
Re: Upgrading to Buster but keeping Postgresql-9.6
On 9/07/19 9:24 AM, Phil Endecott wrote: > Andrei POPESCU wrote: >> On Lu, 08 iul 19, 20:02:36, Phil Endecott wrote: >>> Dear Experts, >>> >>> Does anyone have any advice about the possibility of upgrading >>> systems from Stretch to Buster, but keeping Postgresql-9.6 for >>> the time being? >> >> Is upgrading to buster a necessity? Stretch will be supported by >> Debian for one more year and probably some more by the LTS effort. > > Indeed, not upgrading to Buster is a possibility. Also upgrading > PostgreSQL > to version 11 is a possibility. I think I understand the issues with each > of those options, but I don't have a good understanding of the issues with > trying to keep pg-9.6 on Buster. Another option is to switch to using the pgdg repo for 9.6: https://wiki.postgresql.org/wiki/Apt I'm not sure if there are any implications of switching the packages for the same version - I don't think so. I believe they're packaged by the same person. Richard signature.asc Description: OpenPGP digital signature
Re: Upgrading to Buster but keeping Postgresql-9.6
Andrei POPESCU wrote: On Lu, 08 iul 19, 20:02:36, Phil Endecott wrote: Dear Experts, Does anyone have any advice about the possibility of upgrading systems from Stretch to Buster, but keeping Postgresql-9.6 for the time being? Is upgrading to buster a necessity? Stretch will be supported by Debian for one more year and probably some more by the LTS effort. Indeed, not upgrading to Buster is a possibility. Also upgrading PostgreSQL to version 11 is a possibility. I think I understand the issues with each of those options, but I don't have a good understanding of the issues with trying to keep pg-9.6 on Buster. (There doesn't seem to be a Debian-Postgresql mailing list, hmmm.) Phil.
Re: Upgrading to Buster but keeping Postgresql-9.6
On Lu, 08 iul 19, 20:02:36, Phil Endecott wrote: > Dear Experts, > > Does anyone have any advice about the possibility of upgrading > systems from Stretch to Buster, but keeping Postgresql-9.6 for > the time being? Is upgrading to buster a necessity? Stretch will be supported by Debian for one more year and probably some more by the LTS effort. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Upgrading to Buster but keeping Postgresql-9.6
Phil Endecott: > > Does anyone have any advice about the possibility of upgrading > systems from Stretch to Buster, but keeping Postgresql-9.6 for > the time being? With previous Debian releases you always had to migrate your cluster to the new Postgres version manually. The new packages are installed, but the old ones stay around and you can pg_upgradecluster when you are ready. J. -- I frequently find myself at the top of the stairs with absolutely nothing happening in my brain. [Agree] [Disagree] <http://archive.slowlydownward.com/NODATA/data_enter2.html> signature.asc Description: PGP signature
Upgrading to Buster but keeping Postgresql-9.6
Dear Experts, Does anyone have any advice about the possibility of upgrading systems from Stretch to Buster, but keeping Postgresql-9.6 for the time being? This is for a couple of cloud servers that are running Postgresql with streaming replication from one to the other. I guess my questions are: (a) will this actually work, i.e. will Postgresql-9.6 continue to run OK with the rest of the system upgraded, and (b) what "apt magic runes" do I need to invoke to make it happen? I guess this is "pinning", is it? That's not something I've ever had to do before. Many thanks for any suggestions. (Please Cc: me in any replies, so I'll see them sooner.) Phil.
Re: Conseils sur la configuration de PostgreSQL
Bonjour, personnellement, je ne mets pas de mot de passe au compte postgres, mais je fais en sorte que seul root puisse se connecter en tant que postgres (su - postgres). Pour scripter des commandes psql, avec un mot de passe, je fais quelque chose comme: PGPASSWORD=motdepasse psql -U compteutilisateur -d basededonnées -c 'commande sql ;' (le tout sur une seule ligne) Une autre solution est de faire exécuter le script par un compte système pour lequel il existe un rôle postgresql avec le même nom et qui se connecte par la méthode peer (comme postgres), ou alors jouer avec le mapping des comptes dans pg_ident.conf. Dans ce cas, plus besoin de fournir la variable PGPASSWORD avant la commande psql Voir aussi man psql pour les autres options fort utiles de psql, notamment par rapport à des exécutions non interactives (sortir les résultats selon un certain formalisme, etc) Je n'ai pas bien compris la question pour pg_hba.conf. Je ne me sers de ce fichier que pour définir quels rôles sont habilités à se connecter sur telle ou telle base, depuis quel(s) hôte(s) et selon quelle méthode (le plus souvent peer ou md5) Le 19/03/2019 à 15:05, Olivier a écrit : > Hello, > > Déformé par des années de pratique (peu intensive) de MySQL, je > découvre PostgreSQL. > > J'ai un peu de mal à me faire une religion sur la façon canonique de > configurer PostgreSQL. > Avez-vous des conseils sur le sujet ? > > 1. Est-ce un bon objectif de configurer un mot de passe pour > l'utilisateur postgres ? Si oui, quelle méthode conseillez-vous pour > scripter (cf [2]) des commandes PostgreSQL ? > 3. Comment maintenir le fichier pg_hba.conf ? En y ajoutant une > directive indiquant un fichier externe (perso.conf, local.conf, ...) > de façon à bien distinguer les paramètres de Debian de ses propres > paramètres ? > > Slts > > [1] https://wiki.debian.org/PostgreSql > [2] > https://blog.sleeplessbeastie.eu/2014/03/23/how-to-non-interactively-provide-password-for-the-postgresql-interactive-terminal/
Conseils sur la configuration de PostgreSQL
Hello, Déformé par des années de pratique (peu intensive) de MySQL, je découvre PostgreSQL. J'ai un peu de mal à me faire une religion sur la façon canonique de configurer PostgreSQL. Avez-vous des conseils sur le sujet ? 1. Est-ce un bon objectif de configurer un mot de passe pour l'utilisateur postgres ? Si oui, quelle méthode conseillez-vous pour scripter (cf [2]) des commandes PostgreSQL ? 3. Comment maintenir le fichier pg_hba.conf ? En y ajoutant une directive indiquant un fichier externe (perso.conf, local.conf, ...) de façon à bien distinguer les paramètres de Debian de ses propres paramètres ? Slts [1] https://wiki.debian.org/PostgreSql [2] https://blog.sleeplessbeastie.eu/2014/03/23/how-to-non-interactively-provide-password-for-the-postgresql-interactive-terminal/
Re: buster upgraded postgresql
On 2018-11-12 13:44, Greg Wooledge wrote: > > > but how to find out what is this "cluster-name" for pg_ctlcluster, > > > pg_dropcluster and pg_upgradecluster ? > > > > OK from the conf files assume cluster-name is '10/main' and '11/main' > > respectively ? > > default cluster name for both clusters should be "main". yes I got there eventually You could also try reading the README.Debian.gz file in /usr/share/doc/postgresql-*/ In stretch, this is /usr/share/doc/postgresql-9.6/README.Debian.gz and it contains the exact steps needed to upgrade from 9.1 to 9.4. Just replace the version numbers with whatever you have. In my defence I've used msql but have no idea about postgresql and thinking there's probably a few things use it I asked. Looked later but didn't know about "zless" and as it was working didn't bother to extract it. I did now so next time I'll be less nervous. mick -- Key ID4BFEBB31
Re: buster upgraded postgresql
> > > > but how to find out what is this "cluster-name" for pg_ctlcluster, > > > > pg_dropcluster and pg_upgradecluster ? > > > > > > OK from the conf files assume cluster-name is '10/main' and '11/main' > > > respectively ? > > > > default cluster name for both clusters should be "main". > yes I got there eventually You could also try reading the README.Debian.gz file in /usr/share/doc/postgresql-*/ In stretch, this is /usr/share/doc/postgresql-9.6/README.Debian.gz and it contains the exact steps needed to upgrade from 9.1 to 9.4. Just replace the version numbers with whatever you have.
Re: buster upgraded postgresql
On 2018-11-11 13:40, Georgi Naplatanov wrote: On 11/11/18 1:00 PM, mick crane wrote: but how to find out what is this "cluster-name" for pg_ctlcluster, pg_dropcluster and pg_upgradecluster ? "pg_dropcluster [--stop] cluster-version cluster-name" "pg_upgradecluster oldversion name [newdatadir]" ? OK from the conf files assume cluster-name is '10/main' and '11/main' respectively ? default cluster name for both clusters should be "main". yes I got there eventually so is "pg_ctlcluster 11 main stop" "pg_dropcluster 11 main" "pg_upgradecluster 10 main /var/lib/postgresql/11/main" "pg_dropcluster 10 main" "sudo -u postgres psql" "SHOW data_directory;" "\q" nothing seems to be broken cheers mick -- Key ID4BFEBB31
Re: buster upgraded postgresql
On 11/11/18 1:00 PM, mick crane wrote: > >> but how to find out what is this "cluster-name" for pg_ctlcluster, >> pg_dropcluster and pg_upgradecluster ? >> >> "pg_dropcluster [--stop] cluster-version cluster-name" >> >> "pg_upgradecluster oldversion name [newdatadir]" ? >> > > OK from the conf files assume cluster-name is '10/main' and '11/main' > respectively ? > default cluster name for both clusters should be "main".
Re: buster upgraded postgresql
but how to find out what is this "cluster-name" for pg_ctlcluster, pg_dropcluster and pg_upgradecluster ? "pg_dropcluster [--stop] cluster-version cluster-name" "pg_upgradecluster oldversion name [newdatadir]" ? OK from the conf files assume cluster-name is '10/main' and '11/main' respectively ? -- Key ID4BFEBB31
Re: buster upgraded postgresql
On 2018-11-11 10:00, Georgi Naplatanov wrote: On 11/11/18 11:52 AM, mick crane wrote: hello this last upgrade buster upgraded postgresql-10 to 11 I'm not sure what uses postgresql. during upgrade think there was a message about pg_upgradecluster or I may have read that in manpage. :~# ps -ef | grep postgre postgres 599 1 0 09:36 ? 00:00:00 /usr/lib/postgresql/10/bin/postgres -D /var/lib/postgresql/10/main -c config_file=/etc/postgresql/10/main/postgresql.conf postgres 600 1 0 09:36 ? 00:00:00 /usr/lib/postgresql/11/bin/postgres -D /var/lib/postgresql/11/main -c config_file=/etc/postgresql/11/main/postgresql.conf shows postgresql-10 and -11 both running after reboot ( I thought reboot might dump 10 if not needed ) should I do "pg_upgradecluster" ? how to find out if 10 is needed and if not needed stop it ? please bear in mind I don't know what I'm doing. mick Hi Mick, I think that you should the following: - drop existing cluster of PostgreSQL 11 - upgrade existing PostgreSQL 10 cluster to 11 - drop existing PostgreSQL 10 - remove PostgreSQL 10 packages You have to use commands: pg_dropcluster and pg_upgradecluster HTH Kind regards Georgi Why do I get the feeling I'm going to break something ? with "pg_ctlcluster" assume cluster-version is "11" and action is "stop" but how to find out what is this "cluster-name" for pg_ctlcluster, pg_dropcluster and pg_upgradecluster ? "pg_dropcluster [--stop] cluster-version cluster-name" "pg_upgradecluster oldversion name [newdatadir]" ? mick -- Key ID4BFEBB31
Re: buster upgraded postgresql
On 11/11/18 11:52 AM, mick crane wrote: > hello > > this last upgrade buster upgraded postgresql-10 to 11 > I'm not sure what uses postgresql. > during upgrade think there was a message about pg_upgradecluster or I > may have read that in manpage. > > :~# ps -ef | grep postgre > postgres 599 1 0 09:36 ? 00:00:00 > /usr/lib/postgresql/10/bin/postgres -D /var/lib/postgresql/10/main -c > config_file=/etc/postgresql/10/main/postgresql.conf > postgres 600 1 0 09:36 ? 00:00:00 > /usr/lib/postgresql/11/bin/postgres -D /var/lib/postgresql/11/main -c > config_file=/etc/postgresql/11/main/postgresql.conf > > shows postgresql-10 and -11 both running after reboot ( I thought reboot > might dump 10 if not needed ) > > should I do "pg_upgradecluster" ? > how to find out if 10 is needed and if not needed stop it ? > > please bear in mind I don't know what I'm doing. > > mick Hi Mick, I think that you should the following: - drop existing cluster of PostgreSQL 11 - upgrade existing PostgreSQL 10 cluster to 11 - drop existing PostgreSQL 10 - remove PostgreSQL 10 packages You have to use commands: pg_dropcluster and pg_upgradecluster HTH Kind regards Georgi
buster upgraded postgresql
hello this last upgrade buster upgraded postgresql-10 to 11 I'm not sure what uses postgresql. during upgrade think there was a message about pg_upgradecluster or I may have read that in manpage. :~# ps -ef | grep postgre postgres 599 1 0 09:36 ?00:00:00 /usr/lib/postgresql/10/bin/postgres -D /var/lib/postgresql/10/main -c config_file=/etc/postgresql/10/main/postgresql.conf postgres 600 1 0 09:36 ?00:00:00 /usr/lib/postgresql/11/bin/postgres -D /var/lib/postgresql/11/main -c config_file=/etc/postgresql/11/main/postgresql.conf shows postgresql-10 and -11 both running after reboot ( I thought reboot might dump 10 if not needed ) should I do "pg_upgradecluster" ? how to find out if 10 is needed and if not needed stop it ? please bear in mind I don't know what I'm doing. mick -- Key ID4BFEBB31
Fwd: Acoplar postgresql con xampp en debian de 64 bits [SOLUCIONADO]
-- Forwarded message - From: Miguel Matos Date: Wed, Oct 24, 2018 at 9:49 AM Subject: Re: Acoplar postgresql con xampp en debian de 64 bits To: debian-user-spanish@lists.debian.org < debian-user-spanish@lists.debian.org> On Tue, Oct 23, 2018 at 11:10 AM Paynalton wrote: > en PHP es común tener lo de undefined index. > > Pregunta: La ejecución se interrumpe después de un tiempo o es > instantáneo > Pasa casi que medio minuto e indica que ha pasado un error, y luego sucede lo que comenté antes. > > Por defecto PHP tiene 30 segundos para ejecutar un script antes de > considerar el proceso como colgado y matar la ejecución. > Posiblemente sea eso, pero no sé exáctamente cómo subirlo. ¿Es en max_execution_time y/o en max_input_time? Pues ambos dos los puse en 600 e igual siguen con el error... > > Como te dicen, activa los mensajes de depuración y revisa el log de apache > para ver que sucede en el preciso instante en que se detiene tu proceso y > encontrar la razón. > Cuando tenga acceso a los logs se los compartiré... > > El mar., 23 de oct. de 2018 a la(s) 09:48, Felix Perez < > felix.listadeb...@gmail.com> escribió: > >> El mar., 23 de oct. de 2018 a la(s) 10:17, Miguel Matos >> (matospmigu...@gmail.com) escribió: >> > >> > On Mon, Oct 22, 2018 at 6:27 PM Felix Perez < >> felix.listadeb...@gmail.com> wrote: >> >> >> >> El lun., 22 de oct. de 2018 a la(s) 18:13, Miguel Matos >> >> (matospmigu...@gmail.com) escribió: >> >> > >> >> > On Mon, Oct 22, 2018 at 11:04 AM Gonzalo Rivero < >> fishfromsa...@gmail.com> wrote: >> >> >> >> >> >> El lun, 22-10-2018 a las 10:26 -0400, Miguel Matos escribió: >> >> >> > Muy buenas, acá vuelvo a plantear una duda muy exótica que me >> surgió: >> >> >> > me han indicado que en una máquina que usa la más reciente >> versión de >> >> >> > debian, la 8 para más señas (pero no tengo más pistas del hardware >> >> >> > que tiene), le quieren instalar el xampp para agregar un software >> >> >> > ERP, pero el caso es que éste trabaja con postgresql y no con >> >> >> > mysql/mariadb. He indagado más o menos, y lo que mejor se >> consigue es >> >> >> > para windows 7/8/10. Me preguntaba si alguno acá se ha instalado >> el >> >> >> > xampp que le haya puesto postgresql para darme más pistas... >> >> >> > >> >> >> >> >> >> apt-get install postgresql-10 php-pgsql >> >> >> >> >> >> >> >> > >> >> > Ya me imaginaba que habrían respuestas así, así que diré "ya existe >> postgresql previamente instalado", pero ya obtuve una nueva perspectiva del >> problema: resulta es que el ERP que usa la empresa tiene un vulgo búlgaro >> problema, que cuando intenta hacer una transacción SQL, la trunca en cierto >> punto, y la tabla resultante sale "cortada" desde el punto donde se corta >> la transacción SQL... por lo que les propusieron instalar el ERP a través >> de XAMPP, pero como ya muchos habrán visto, XAMPP viene es con mysql >> instalado, y el ERP usa postgres... por lo que resolver esto es un paso más >> que vital. Y sí, ya sé que el problema va más a la parte de la programación >> en PHP y Postgresql, pero igual necesitaba algo de asesoría ya que todo se >> está montando sobre debian. >> >> > >> >> >> >> Estimado Miguel, sin mala intención y con todo respeto, pero podría >> >> volver a plantear cual es el problema y el escenario. Redactar bien >> >> solo amerita un poquito de esfuerzo. >> > >> > >> > Hago lo mejor posible porque a mí tambíen me hace jalarme los pelos >> cuando no me dicen exactamente lo que necesitan, por lo que tengo que >> insistir cuatro o más veces que planteen el problema >> >> >> >> >> >> Por lo poco que alcanzo a entender, el instalar a través de XAMPP, >> >> ¿Instalar qué? ¿El ERP?, según tú ¿Eso te solucionaría un problema de >> >> una transacción Postgresql?. O no responde la aplicación o no responde >> >> Postgresql incluso habría que descartar conectividad, aunque si se >> >> pierde la "red" el commit de la transacción, por lo que se, no >> >> quedaría truncado sino que no se realizaría. >> >> >> >> XAMPP, te permite instalar Apache, PHP, MariaDB/Mysql. Si lo quieres >> >> usar, instal
Re: Acoplar postgresql con xampp en debian de 64 bits
Mirate esto: http://php.net/manual/es/function.set-time-limit.php y esto: http://php.net/manual/es/info.configuration.php#ini.max-execution-time El mié., 24 de oct. de 2018 a la(s) 08:50, Miguel Matos < matospmigu...@gmail.com> escribió: > On Tue, Oct 23, 2018 at 11:10 AM Paynalton wrote: > >> en PHP es común tener lo de undefined index. >> >> Pregunta: La ejecución se interrumpe después de un tiempo o es >> instantáneo >> > > Pasa casi que medio minuto e indica que ha pasado un error, y luego sucede > lo que comenté antes. > >> >> Por defecto PHP tiene 30 segundos para ejecutar un script antes de >> considerar el proceso como colgado y matar la ejecución. >> > > Posiblemente sea eso, pero no sé exáctamente cómo subirlo. ¿Es en > max_execution_time y/o en max_input_time? Pues ambos dos los puse en 600 e > igual siguen con el error... > >> >> Como te dicen, activa los mensajes de depuración y revisa el log de >> apache para ver que sucede en el preciso instante en que se detiene tu >> proceso y encontrar la razón. >> > > Cuando tenga acceso a los logs se los compartiré... > >> >> El mar., 23 de oct. de 2018 a la(s) 09:48, Felix Perez < >> felix.listadeb...@gmail.com> escribió: >> >>> El mar., 23 de oct. de 2018 a la(s) 10:17, Miguel Matos >>> (matospmigu...@gmail.com) escribió: >>> > >>> > On Mon, Oct 22, 2018 at 6:27 PM Felix Perez < >>> felix.listadeb...@gmail.com> wrote: >>> >> >>> >> El lun., 22 de oct. de 2018 a la(s) 18:13, Miguel Matos >>> >> (matospmigu...@gmail.com) escribió: >>> >> > >>> >> > On Mon, Oct 22, 2018 at 11:04 AM Gonzalo Rivero < >>> fishfromsa...@gmail.com> wrote: >>> >> >> >>> >> >> El lun, 22-10-2018 a las 10:26 -0400, Miguel Matos escribió: >>> >> >> > Muy buenas, acá vuelvo a plantear una duda muy exótica que me >>> surgió: >>> >> >> > me han indicado que en una máquina que usa la más reciente >>> versión de >>> >> >> > debian, la 8 para más señas (pero no tengo más pistas del >>> hardware >>> >> >> > que tiene), le quieren instalar el xampp para agregar un software >>> >> >> > ERP, pero el caso es que éste trabaja con postgresql y no con >>> >> >> > mysql/mariadb. He indagado más o menos, y lo que mejor se >>> consigue es >>> >> >> > para windows 7/8/10. Me preguntaba si alguno acá se ha instalado >>> el >>> >> >> > xampp que le haya puesto postgresql para darme más pistas... >>> >> >> > >>> >> >> >>> >> >> apt-get install postgresql-10 php-pgsql >>> >> >> >>> >> >> >>> >> > >>> >> > Ya me imaginaba que habrían respuestas así, así que diré "ya existe >>> postgresql previamente instalado", pero ya obtuve una nueva perspectiva del >>> problema: resulta es que el ERP que usa la empresa tiene un vulgo búlgaro >>> problema, que cuando intenta hacer una transacción SQL, la trunca en cierto >>> punto, y la tabla resultante sale "cortada" desde el punto donde se corta >>> la transacción SQL... por lo que les propusieron instalar el ERP a través >>> de XAMPP, pero como ya muchos habrán visto, XAMPP viene es con mysql >>> instalado, y el ERP usa postgres... por lo que resolver esto es un paso más >>> que vital. Y sí, ya sé que el problema va más a la parte de la programación >>> en PHP y Postgresql, pero igual necesitaba algo de asesoría ya que todo se >>> está montando sobre debian. >>> >> > >>> >> >>> >> Estimado Miguel, sin mala intención y con todo respeto, pero podría >>> >> volver a plantear cual es el problema y el escenario. Redactar bien >>> >> solo amerita un poquito de esfuerzo. >>> > >>> > >>> > Hago lo mejor posible porque a mí tambíen me hace jalarme los pelos >>> cuando no me dicen exactamente lo que necesitan, por lo que tengo que >>> insistir cuatro o más veces que planteen el problema >>> >> >>> >> >>> >> Por lo poco que alcanzo a entender, el instalar a través de XAMPP, >>> >> ¿Instalar qué? ¿El ERP?, según tú ¿Eso te solucionaría un problema de >>> >> una transacción Postgresql?. O no responde la aplicación o no responde &
Re: Acoplar postgresql con xampp en debian de 64 bits
On Tue, Oct 23, 2018 at 11:10 AM Paynalton wrote: > en PHP es común tener lo de undefined index. > > Pregunta: La ejecución se interrumpe después de un tiempo o es > instantáneo > Pasa casi que medio minuto e indica que ha pasado un error, y luego sucede lo que comenté antes. > > Por defecto PHP tiene 30 segundos para ejecutar un script antes de > considerar el proceso como colgado y matar la ejecución. > Posiblemente sea eso, pero no sé exáctamente cómo subirlo. ¿Es en max_execution_time y/o en max_input_time? Pues ambos dos los puse en 600 e igual siguen con el error... > > Como te dicen, activa los mensajes de depuración y revisa el log de apache > para ver que sucede en el preciso instante en que se detiene tu proceso y > encontrar la razón. > Cuando tenga acceso a los logs se los compartiré... > > El mar., 23 de oct. de 2018 a la(s) 09:48, Felix Perez < > felix.listadeb...@gmail.com> escribió: > >> El mar., 23 de oct. de 2018 a la(s) 10:17, Miguel Matos >> (matospmigu...@gmail.com) escribió: >> > >> > On Mon, Oct 22, 2018 at 6:27 PM Felix Perez < >> felix.listadeb...@gmail.com> wrote: >> >> >> >> El lun., 22 de oct. de 2018 a la(s) 18:13, Miguel Matos >> >> (matospmigu...@gmail.com) escribió: >> >> > >> >> > On Mon, Oct 22, 2018 at 11:04 AM Gonzalo Rivero < >> fishfromsa...@gmail.com> wrote: >> >> >> >> >> >> El lun, 22-10-2018 a las 10:26 -0400, Miguel Matos escribió: >> >> >> > Muy buenas, acá vuelvo a plantear una duda muy exótica que me >> surgió: >> >> >> > me han indicado que en una máquina que usa la más reciente >> versión de >> >> >> > debian, la 8 para más señas (pero no tengo más pistas del hardware >> >> >> > que tiene), le quieren instalar el xampp para agregar un software >> >> >> > ERP, pero el caso es que éste trabaja con postgresql y no con >> >> >> > mysql/mariadb. He indagado más o menos, y lo que mejor se >> consigue es >> >> >> > para windows 7/8/10. Me preguntaba si alguno acá se ha instalado >> el >> >> >> > xampp que le haya puesto postgresql para darme más pistas... >> >> >> > >> >> >> >> >> >> apt-get install postgresql-10 php-pgsql >> >> >> >> >> >> >> >> > >> >> > Ya me imaginaba que habrían respuestas así, así que diré "ya existe >> postgresql previamente instalado", pero ya obtuve una nueva perspectiva del >> problema: resulta es que el ERP que usa la empresa tiene un vulgo búlgaro >> problema, que cuando intenta hacer una transacción SQL, la trunca en cierto >> punto, y la tabla resultante sale "cortada" desde el punto donde se corta >> la transacción SQL... por lo que les propusieron instalar el ERP a través >> de XAMPP, pero como ya muchos habrán visto, XAMPP viene es con mysql >> instalado, y el ERP usa postgres... por lo que resolver esto es un paso más >> que vital. Y sí, ya sé que el problema va más a la parte de la programación >> en PHP y Postgresql, pero igual necesitaba algo de asesoría ya que todo se >> está montando sobre debian. >> >> > >> >> >> >> Estimado Miguel, sin mala intención y con todo respeto, pero podría >> >> volver a plantear cual es el problema y el escenario. Redactar bien >> >> solo amerita un poquito de esfuerzo. >> > >> > >> > Hago lo mejor posible porque a mí tambíen me hace jalarme los pelos >> cuando no me dicen exactamente lo que necesitan, por lo que tengo que >> insistir cuatro o más veces que planteen el problema >> >> >> >> >> >> Por lo poco que alcanzo a entender, el instalar a través de XAMPP, >> >> ¿Instalar qué? ¿El ERP?, según tú ¿Eso te solucionaría un problema de >> >> una transacción Postgresql?. O no responde la aplicación o no responde >> >> Postgresql incluso habría que descartar conectividad, aunque si se >> >> pierde la "red" el commit de la transacción, por lo que se, no >> >> quedaría truncado sino que no se realizaría. >> >> >> >> XAMPP, te permite instalar Apache, PHP, MariaDB/Mysql. Si lo quieres >> >> usar, instala solo Apache y PHP no instales MariaDb/Mysql y luego >> >> configuras ambos para que se conecten/usen Postgresql. >> >> >> >> Saludos. >> >> >> >> >> >> -- >> >> us
Re: Acoplar postgresql con xampp en debian de 64 bits
On Tue, Oct 23, 2018 at 10:48 AM Felix Perez wrote: > El mar., 23 de oct. de 2018 a la(s) 10:17, Miguel Matos > (matospmigu...@gmail.com) escribió: > > > > On Mon, Oct 22, 2018 at 6:27 PM Felix Perez > wrote: > >> > >> El lun., 22 de oct. de 2018 a la(s) 18:13, Miguel Matos > >> (matospmigu...@gmail.com) escribió: > >> > > >> > On Mon, Oct 22, 2018 at 11:04 AM Gonzalo Rivero < > fishfromsa...@gmail.com> wrote: > >> >> > >> >> El lun, 22-10-2018 a las 10:26 -0400, Miguel Matos escribió: > >> >> > Muy buenas, acá vuelvo a plantear una duda muy exótica que me > surgió: > >> >> > me han indicado que en una máquina que usa la más reciente versión > de > >> >> > debian, la 8 para más señas (pero no tengo más pistas del hardware > >> >> > que tiene), le quieren instalar el xampp para agregar un software > >> >> > ERP, pero el caso es que éste trabaja con postgresql y no con > >> >> > mysql/mariadb. He indagado más o menos, y lo que mejor se consigue > es > >> >> > para windows 7/8/10. Me preguntaba si alguno acá se ha instalado el > >> >> > xampp que le haya puesto postgresql para darme más pistas... > >> >> > > >> >> > >> >> apt-get install postgresql-10 php-pgsql > >> >> > >> >> > >> > > >> > Ya me imaginaba que habrían respuestas así, así que diré "ya existe > postgresql previamente instalado", pero ya obtuve una nueva perspectiva del > problema: resulta es que el ERP que usa la empresa tiene un vulgo búlgaro > problema, que cuando intenta hacer una transacción SQL, la trunca en cierto > punto, y la tabla resultante sale "cortada" desde el punto donde se corta > la transacción SQL... por lo que les propusieron instalar el ERP a través > de XAMPP, pero como ya muchos habrán visto, XAMPP viene es con mysql > instalado, y el ERP usa postgres... por lo que resolver esto es un paso más > que vital. Y sí, ya sé que el problema va más a la parte de la programación > en PHP y Postgresql, pero igual necesitaba algo de asesoría ya que todo se > está montando sobre debian. > >> > > >> > >> Estimado Miguel, sin mala intención y con todo respeto, pero podría > >> volver a plantear cual es el problema y el escenario. Redactar bien > >> solo amerita un poquito de esfuerzo. > > > > > > Hago lo mejor posible porque a mí tambíen me hace jalarme los pelos > cuando no me dicen exactamente lo que necesitan, por lo que tengo que > insistir cuatro o más veces que planteen el problema > >> > >> > >> Por lo poco que alcanzo a entender, el instalar a través de XAMPP, > >> ¿Instalar qué? ¿El ERP?, según tú ¿Eso te solucionaría un problema de > >> una transacción Postgresql?. O no responde la aplicación o no responde > >> Postgresql incluso habría que descartar conectividad, aunque si se > >> pierde la "red" el commit de la transacción, por lo que se, no > >> quedaría truncado sino que no se realizaría. > >> > >> XAMPP, te permite instalar Apache, PHP, MariaDB/Mysql. Si lo quieres > >> usar, instala solo Apache y PHP no instales MariaDb/Mysql y luego > >> configuras ambos para que se conecten/usen Postgresql. > >> > >> Saludos. > >> > >> > >> -- > >> usuario linux #274354 > >> normas de la lista: http://wiki.debian.org/es/NormasLista > >> como hacer preguntas inteligentes: > >> http://www.sindominio.net/ayuda/preguntas-inteligentes.html > >> > > > > El asunto es este: el ERP se llama SIGESP[1], que en este caso es un > software basado en web para la adminstración pública, y usa PostgreSQL para > guardar los datos. Se me olvidó indicarlo, pero ya tanto el apache como el > php y postgres están instalados independiente. Hay un detalle particular > que es cuando se ejecuta cierta transacción de "update", ésta no llega > completa y trunca los datos recibidos, y la tabla que muestra se corta (no > he podido tomar screenshots en donde estoy ejecutando eso porque es remoto > con teamviewer). Les propusieron colocar el sigesp en el xampp, porque > hicieron lo mismo desde wampserver con windows instalado y sí funcionó, y > necesitan que el ERP se ejecute sobre debian, y ya he probado todo lo que > sé y no se me ocurre nada. > > > > Y por si se lo preguntan, alguien me sugirió probar revisar los logs, y > en el de postgresql sale esta línea: > > 2018-10-20 12:35:03 VET SENTENCIA:
Re: Acoplar postgresql con xampp en debian de 64 bits
Hola Miguel, buen día. Es raro que necesites una versión específica de debian lo cual sólo puede ser porque se requiere de una versión particular de alguno de los componentes. Dices que hay una instalación funcionando, ¿puedes ver la versión de apache, php, los módulos y postgresql en la instalación que sí funciona? Ahora, cómo resolverlo, eso dependerá de la razón por la que no funciona y es lo que debemos determinar Saludos, Antonio Galicia Eram quod es, eris quod sum -- El lun., 22 de oct. de 2018 a la(s) 09:27, Miguel Matos ( matospmigu...@gmail.com) escribió: > Muy buenas, acá vuelvo a plantear una duda muy exótica que me surgió: me > han indicado que en una máquina que usa la más reciente versión de debian, > la 8 para más señas (pero no tengo más pistas del hardware que tiene), le > quieren instalar el xampp para agregar un software ERP, pero el caso es que > éste trabaja con postgresql y no con mysql/mariadb. He indagado más o > menos, y lo que mejor se consigue es para windows 7/8/10. Me preguntaba si > alguno acá se ha instalado el xampp que le haya puesto postgresql para > darme más pistas... > > -- > > Ayuda para hacer preguntas inteligentes: http://is.gd/NJIwRz >
Re: Acoplar postgresql con xampp en debian de 64 bits
en PHP es común tener lo de undefined index. Pregunta: La ejecución se interrumpe después de un tiempo o es instantáneo Por defecto PHP tiene 30 segundos para ejecutar un script antes de considerar el proceso como colgado y matar la ejecución. Como te dicen, activa los mensajes de depuración y revisa el log de apache para ver que sucede en el preciso instante en que se detiene tu proceso y encontrar la razón. El mar., 23 de oct. de 2018 a la(s) 09:48, Felix Perez < felix.listadeb...@gmail.com> escribió: > El mar., 23 de oct. de 2018 a la(s) 10:17, Miguel Matos > (matospmigu...@gmail.com) escribió: > > > > On Mon, Oct 22, 2018 at 6:27 PM Felix Perez > wrote: > >> > >> El lun., 22 de oct. de 2018 a la(s) 18:13, Miguel Matos > >> (matospmigu...@gmail.com) escribió: > >> > > >> > On Mon, Oct 22, 2018 at 11:04 AM Gonzalo Rivero < > fishfromsa...@gmail.com> wrote: > >> >> > >> >> El lun, 22-10-2018 a las 10:26 -0400, Miguel Matos escribió: > >> >> > Muy buenas, acá vuelvo a plantear una duda muy exótica que me > surgió: > >> >> > me han indicado que en una máquina que usa la más reciente versión > de > >> >> > debian, la 8 para más señas (pero no tengo más pistas del hardware > >> >> > que tiene), le quieren instalar el xampp para agregar un software > >> >> > ERP, pero el caso es que éste trabaja con postgresql y no con > >> >> > mysql/mariadb. He indagado más o menos, y lo que mejor se consigue > es > >> >> > para windows 7/8/10. Me preguntaba si alguno acá se ha instalado el > >> >> > xampp que le haya puesto postgresql para darme más pistas... > >> >> > > >> >> > >> >> apt-get install postgresql-10 php-pgsql > >> >> > >> >> > >> > > >> > Ya me imaginaba que habrían respuestas así, así que diré "ya existe > postgresql previamente instalado", pero ya obtuve una nueva perspectiva del > problema: resulta es que el ERP que usa la empresa tiene un vulgo búlgaro > problema, que cuando intenta hacer una transacción SQL, la trunca en cierto > punto, y la tabla resultante sale "cortada" desde el punto donde se corta > la transacción SQL... por lo que les propusieron instalar el ERP a través > de XAMPP, pero como ya muchos habrán visto, XAMPP viene es con mysql > instalado, y el ERP usa postgres... por lo que resolver esto es un paso más > que vital. Y sí, ya sé que el problema va más a la parte de la programación > en PHP y Postgresql, pero igual necesitaba algo de asesoría ya que todo se > está montando sobre debian. > >> > > >> > >> Estimado Miguel, sin mala intención y con todo respeto, pero podría > >> volver a plantear cual es el problema y el escenario. Redactar bien > >> solo amerita un poquito de esfuerzo. > > > > > > Hago lo mejor posible porque a mí tambíen me hace jalarme los pelos > cuando no me dicen exactamente lo que necesitan, por lo que tengo que > insistir cuatro o más veces que planteen el problema > >> > >> > >> Por lo poco que alcanzo a entender, el instalar a través de XAMPP, > >> ¿Instalar qué? ¿El ERP?, según tú ¿Eso te solucionaría un problema de > >> una transacción Postgresql?. O no responde la aplicación o no responde > >> Postgresql incluso habría que descartar conectividad, aunque si se > >> pierde la "red" el commit de la transacción, por lo que se, no > >> quedaría truncado sino que no se realizaría. > >> > >> XAMPP, te permite instalar Apache, PHP, MariaDB/Mysql. Si lo quieres > >> usar, instala solo Apache y PHP no instales MariaDb/Mysql y luego > >> configuras ambos para que se conecten/usen Postgresql. > >> > >> Saludos. > >> > >> > >> -- > >> usuario linux #274354 > >> normas de la lista: http://wiki.debian.org/es/NormasLista > >> como hacer preguntas inteligentes: > >> http://www.sindominio.net/ayuda/preguntas-inteligentes.html > >> > > > > El asunto es este: el ERP se llama SIGESP[1], que en este caso es un > software basado en web para la adminstración pública, y usa PostgreSQL para > guardar los datos. Se me olvidó indicarlo, pero ya tanto el apache como el > php y postgres están instalados independiente. Hay un detalle particular > que es cuando se ejecuta cierta transacción de "update", ésta no llega > completa y trunca los datos recibidos, y la tabla que muestra se corta (no > he podido tomar screenshots en donde es
Re: Acoplar postgresql con xampp en debian de 64 bits
El mar., 23 de oct. de 2018 a la(s) 10:17, Miguel Matos (matospmigu...@gmail.com) escribió: > > On Mon, Oct 22, 2018 at 6:27 PM Felix Perez > wrote: >> >> El lun., 22 de oct. de 2018 a la(s) 18:13, Miguel Matos >> (matospmigu...@gmail.com) escribió: >> > >> > On Mon, Oct 22, 2018 at 11:04 AM Gonzalo Rivero >> > wrote: >> >> >> >> El lun, 22-10-2018 a las 10:26 -0400, Miguel Matos escribió: >> >> > Muy buenas, acá vuelvo a plantear una duda muy exótica que me surgió: >> >> > me han indicado que en una máquina que usa la más reciente versión de >> >> > debian, la 8 para más señas (pero no tengo más pistas del hardware >> >> > que tiene), le quieren instalar el xampp para agregar un software >> >> > ERP, pero el caso es que éste trabaja con postgresql y no con >> >> > mysql/mariadb. He indagado más o menos, y lo que mejor se consigue es >> >> > para windows 7/8/10. Me preguntaba si alguno acá se ha instalado el >> >> > xampp que le haya puesto postgresql para darme más pistas... >> >> > >> >> >> >> apt-get install postgresql-10 php-pgsql >> >> >> >> >> > >> > Ya me imaginaba que habrían respuestas así, así que diré "ya existe >> > postgresql previamente instalado", pero ya obtuve una nueva perspectiva >> > del problema: resulta es que el ERP que usa la empresa tiene un vulgo >> > búlgaro problema, que cuando intenta hacer una transacción SQL, la trunca >> > en cierto punto, y la tabla resultante sale "cortada" desde el punto donde >> > se corta la transacción SQL... por lo que les propusieron instalar el ERP >> > a través de XAMPP, pero como ya muchos habrán visto, XAMPP viene es con >> > mysql instalado, y el ERP usa postgres... por lo que resolver esto es un >> > paso más que vital. Y sí, ya sé que el problema va más a la parte de la >> > programación en PHP y Postgresql, pero igual necesitaba algo de asesoría >> > ya que todo se está montando sobre debian. >> > >> >> Estimado Miguel, sin mala intención y con todo respeto, pero podría >> volver a plantear cual es el problema y el escenario. Redactar bien >> solo amerita un poquito de esfuerzo. > > > Hago lo mejor posible porque a mí tambíen me hace jalarme los pelos cuando no > me dicen exactamente lo que necesitan, por lo que tengo que insistir cuatro o > más veces que planteen el problema >> >> >> Por lo poco que alcanzo a entender, el instalar a través de XAMPP, >> ¿Instalar qué? ¿El ERP?, según tú ¿Eso te solucionaría un problema de >> una transacción Postgresql?. O no responde la aplicación o no responde >> Postgresql incluso habría que descartar conectividad, aunque si se >> pierde la "red" el commit de la transacción, por lo que se, no >> quedaría truncado sino que no se realizaría. >> >> XAMPP, te permite instalar Apache, PHP, MariaDB/Mysql. Si lo quieres >> usar, instala solo Apache y PHP no instales MariaDb/Mysql y luego >> configuras ambos para que se conecten/usen Postgresql. >> >> Saludos. >> >> >> -- >> usuario linux #274354 >> normas de la lista: http://wiki.debian.org/es/NormasLista >> como hacer preguntas inteligentes: >> http://www.sindominio.net/ayuda/preguntas-inteligentes.html >> > > El asunto es este: el ERP se llama SIGESP[1], que en este caso es un software > basado en web para la adminstración pública, y usa PostgreSQL para guardar > los datos. Se me olvidó indicarlo, pero ya tanto el apache como el php y > postgres están instalados independiente. Hay un detalle particular que es > cuando se ejecuta cierta transacción de "update", ésta no llega completa y > trunca los datos recibidos, y la tabla que muestra se corta (no he podido > tomar screenshots en donde estoy ejecutando eso porque es remoto con > teamviewer). Les propusieron colocar el sigesp en el xampp, porque hicieron > lo mismo desde wampserver con windows instalado y sí funcionó, y necesitan > que el ERP se ejecute sobre debian, y ya he probado todo lo que sé y no se me > ocurre nada. > > Y por si se lo preguntan, alguien me sugirió probar revisar los logs, y en el > de postgresql sale esta línea: > 2018-10-20 12:35:03 VET SENTENCIA: UPDATE spg_cuentas SET > distribuir='0', enero=0.00, febrero=0.00, marzo=0.00, > abril=0.00, mayo=0.00, junio=0.00, > julio=0.00, agosto=0.00, septiembre=, octubre=, > novie
Re: Acoplar postgresql con xampp en debian de 64 bits
On Mon, Oct 22, 2018 at 6:27 PM Felix Perez wrote: > El lun., 22 de oct. de 2018 a la(s) 18:13, Miguel Matos > (matospmigu...@gmail.com) escribió: > > > > On Mon, Oct 22, 2018 at 11:04 AM Gonzalo Rivero > wrote: > >> > >> El lun, 22-10-2018 a las 10:26 -0400, Miguel Matos escribió: > >> > Muy buenas, acá vuelvo a plantear una duda muy exótica que me surgió: > >> > me han indicado que en una máquina que usa la más reciente versión de > >> > debian, la 8 para más señas (pero no tengo más pistas del hardware > >> > que tiene), le quieren instalar el xampp para agregar un software > >> > ERP, pero el caso es que éste trabaja con postgresql y no con > >> > mysql/mariadb. He indagado más o menos, y lo que mejor se consigue es > >> > para windows 7/8/10. Me preguntaba si alguno acá se ha instalado el > >> > xampp que le haya puesto postgresql para darme más pistas... > >> > > >> > >> apt-get install postgresql-10 php-pgsql > >> > >> > > > > Ya me imaginaba que habrían respuestas así, así que diré "ya existe > postgresql previamente instalado", pero ya obtuve una nueva perspectiva del > problema: resulta es que el ERP que usa la empresa tiene un vulgo búlgaro > problema, que cuando intenta hacer una transacción SQL, la trunca en cierto > punto, y la tabla resultante sale "cortada" desde el punto donde se corta > la transacción SQL... por lo que les propusieron instalar el ERP a través > de XAMPP, pero como ya muchos habrán visto, XAMPP viene es con mysql > instalado, y el ERP usa postgres... por lo que resolver esto es un paso más > que vital. Y sí, ya sé que el problema va más a la parte de la programación > en PHP y Postgresql, pero igual necesitaba algo de asesoría ya que todo se > está montando sobre debian. > > > > Estimado Miguel, sin mala intención y con todo respeto, pero podría > volver a plantear cual es el problema y el escenario. Redactar bien > solo amerita un poquito de esfuerzo. > Hago lo mejor posible porque a mí tambíen me hace jalarme los pelos cuando no me dicen exactamente lo que necesitan, por lo que tengo que insistir cuatro o más veces que planteen el problema > > Por lo poco que alcanzo a entender, el instalar a través de XAMPP, > ¿Instalar qué? ¿El ERP?, según tú ¿Eso te solucionaría un problema de > una transacción Postgresql?. O no responde la aplicación o no responde > Postgresql incluso habría que descartar conectividad, aunque si se > pierde la "red" el commit de la transacción, por lo que se, no > quedaría truncado sino que no se realizaría. > > XAMPP, te permite instalar Apache, PHP, MariaDB/Mysql. Si lo quieres > usar, instala solo Apache y PHP no instales MariaDb/Mysql y luego > configuras ambos para que se conecten/usen Postgresql. > > Saludos. > > > -- > usuario linux #274354 > normas de la lista: http://wiki.debian.org/es/NormasLista > como hacer preguntas inteligentes: > http://www.sindominio.net/ayuda/preguntas-inteligentes.html > > El asunto es este: el ERP se llama SIGESP[1], que en este caso es un software basado en web para la adminstración pública, y usa PostgreSQL para guardar los datos. Se me olvidó indicarlo, pero ya tanto el apache como el php y postgres están instalados independiente. Hay un detalle particular que es cuando se ejecuta cierta transacción de "update", ésta no llega completa y trunca los datos recibidos, y la tabla que muestra se corta (no he podido tomar screenshots en donde estoy ejecutando eso porque es remoto con teamviewer). Les propusieron colocar el sigesp en el xampp, porque hicieron lo mismo desde wampserver con windows instalado y sí funcionó, y necesitan que el ERP se ejecute sobre debian, y ya he probado todo lo que sé y no se me ocurre nada. Y por si se lo preguntan, alguien me sugirió probar revisar los logs, y en el de postgresql sale esta línea: 2018-10-20 12:35:03 VET SENTENCIA: UPDATE spg_cuentas SET distribuir='0', enero=0.00, febrero=0.00, marzo=0.00, abril=0.00, mayo=0.00, junio=0.00, julio=0.00, agosto=0.00, septiembre=, octubre=, noviembre=, diciembre= WHERE codemp='0001' AND codestpro1='AC-02' AND codestpro2='1' AND codestpro3='5' AND codestpro4='0' AND codestpro5='0' AND estcla='A' AND spg_cuenta = '403100100' Y en el apache sale algo tipo undefined index (variable) at (localizacion de archivo) linea (tal), como 400 veces... y desde el lugar donde se encuentra el '403100100' se truncan los datos y sale horrible... Es seguro que el problema es más de php que de debian, pero si puedo alivianarlo en el debian instalado sería más que satisfactorio para mí porque no tendría que preocuparme por instalar el postgresql sobre xampp. -- Ayuda para hacer preguntas inteligentes: http://is.gd/NJIwRz
Re: Acoplar postgresql con xampp en debian de 64 bits
El lun., 22 de oct. de 2018 a la(s) 18:13, Miguel Matos (matospmigu...@gmail.com) escribió: > > On Mon, Oct 22, 2018 at 11:04 AM Gonzalo Rivero > wrote: >> >> El lun, 22-10-2018 a las 10:26 -0400, Miguel Matos escribió: >> > Muy buenas, acá vuelvo a plantear una duda muy exótica que me surgió: >> > me han indicado que en una máquina que usa la más reciente versión de >> > debian, la 8 para más señas (pero no tengo más pistas del hardware >> > que tiene), le quieren instalar el xampp para agregar un software >> > ERP, pero el caso es que éste trabaja con postgresql y no con >> > mysql/mariadb. He indagado más o menos, y lo que mejor se consigue es >> > para windows 7/8/10. Me preguntaba si alguno acá se ha instalado el >> > xampp que le haya puesto postgresql para darme más pistas... >> > >> >> apt-get install postgresql-10 php-pgsql >> >> > > Ya me imaginaba que habrían respuestas así, así que diré "ya existe > postgresql previamente instalado", pero ya obtuve una nueva perspectiva del > problema: resulta es que el ERP que usa la empresa tiene un vulgo búlgaro > problema, que cuando intenta hacer una transacción SQL, la trunca en cierto > punto, y la tabla resultante sale "cortada" desde el punto donde se corta la > transacción SQL... por lo que les propusieron instalar el ERP a través de > XAMPP, pero como ya muchos habrán visto, XAMPP viene es con mysql instalado, > y el ERP usa postgres... por lo que resolver esto es un paso más que vital. Y > sí, ya sé que el problema va más a la parte de la programación en PHP y > Postgresql, pero igual necesitaba algo de asesoría ya que todo se está > montando sobre debian. > Estimado Miguel, sin mala intención y con todo respeto, pero podría volver a plantear cual es el problema y el escenario. Redactar bien solo amerita un poquito de esfuerzo. Por lo poco que alcanzo a entender, el instalar a través de XAMPP, ¿Instalar qué? ¿El ERP?, según tú ¿Eso te solucionaría un problema de una transacción Postgresql?. O no responde la aplicación o no responde Postgresql incluso habría que descartar conectividad, aunque si se pierde la "red" el commit de la transacción, por lo que se, no quedaría truncado sino que no se realizaría. XAMPP, te permite instalar Apache, PHP, MariaDB/Mysql. Si lo quieres usar, instala solo Apache y PHP no instales MariaDb/Mysql y luego configuras ambos para que se conecten/usen Postgresql. Saludos. -- usuario linux #274354 normas de la lista: http://wiki.debian.org/es/NormasLista como hacer preguntas inteligentes: http://www.sindominio.net/ayuda/preguntas-inteligentes.html
Re: Acoplar postgresql con xampp en debian de 64 bits
On Mon, Oct 22, 2018 at 11:04 AM Gonzalo Rivero wrote: > El lun, 22-10-2018 a las 10:26 -0400, Miguel Matos escribió: > > Muy buenas, acá vuelvo a plantear una duda muy exótica que me surgió: > > me han indicado que en una máquina que usa la más reciente versión de > > debian, la 8 para más señas (pero no tengo más pistas del hardware > > que tiene), le quieren instalar el xampp para agregar un software > > ERP, pero el caso es que éste trabaja con postgresql y no con > > mysql/mariadb. He indagado más o menos, y lo que mejor se consigue es > > para windows 7/8/10. Me preguntaba si alguno acá se ha instalado el > > xampp que le haya puesto postgresql para darme más pistas... > > > > apt-get install postgresql-10 php-pgsql > > > Ya me imaginaba que habrían respuestas así, así que diré "ya existe postgresql previamente instalado", pero ya obtuve una nueva perspectiva del problema: resulta es que el ERP que usa la empresa tiene un vulgo búlgaro problema, que cuando intenta hacer una transacción SQL, la trunca en cierto punto, y la tabla resultante sale "cortada" desde el punto donde se corta la transacción SQL... por lo que les propusieron instalar el ERP a través de XAMPP, pero como ya muchos habrán visto, XAMPP viene es con mysql instalado, y el ERP usa postgres... por lo que resolver esto es un paso más que vital. Y sí, ya sé que el problema va más a la parte de la programación en PHP y Postgresql, pero igual necesitaba algo de asesoría ya que todo se está montando sobre debian. PD.: Por ahora tiene que ser Debian 7, no 8 ni 9 (mala mía), por particularidades de este ERP, que funciona sólamente con estos SO's -- Ayuda para hacer preguntas inteligentes: http://is.gd/NJIwRz
Re: Acoplar postgresql con xampp en debian de 64 bits
El lun, 22-10-2018 a las 10:26 -0400, Miguel Matos escribió: > Muy buenas, acá vuelvo a plantear una duda muy exótica que me surgió: > me han indicado que en una máquina que usa la más reciente versión de > debian, la 8 para más señas (pero no tengo más pistas del hardware > que tiene), le quieren instalar el xampp para agregar un software > ERP, pero el caso es que éste trabaja con postgresql y no con > mysql/mariadb. He indagado más o menos, y lo que mejor se consigue es > para windows 7/8/10. Me preguntaba si alguno acá se ha instalado el > xampp que le haya puesto postgresql para darme más pistas... > apt-get install postgresql-10 php-pgsql
Re: Acoplar postgresql con xampp en debian de 64 bits
On Monday, October 22, 2018 10:26:14 AM -03 Miguel Matos wrote: > Muy buenas, acá vuelvo a plantear una duda muy exótica que me surgió: me > han indicado que en una máquina que usa la más reciente versión de debian, > la 8 para más señas (pero no tengo más pistas del hardware que tiene), le > quieren instalar el xampp para agregar un software ERP, pero el caso es que > éste trabaja con postgresql y no con mysql/mariadb. He indagado más o > menos, y lo que mejor se consigue es para windows 7/8/10. Me preguntaba si > alguno acá se ha instalado el xampp que le haya puesto postgresql para > darme más pistas... > > -- > > Ayuda para hacer preguntas inteligentes: http://is.gd/NJIwRz buenas no se te entiende mucho pero empecemos que el ultimo debian stable es el 9 stretch y si preguntas si existe postgresql para debian la respuesta es si.. postgresql-9.6 en debian 9 saludos
Acoplar postgresql con xampp en debian de 64 bits
Muy buenas, acá vuelvo a plantear una duda muy exótica que me surgió: me han indicado que en una máquina que usa la más reciente versión de debian, la 8 para más señas (pero no tengo más pistas del hardware que tiene), le quieren instalar el xampp para agregar un software ERP, pero el caso es que éste trabaja con postgresql y no con mysql/mariadb. He indagado más o menos, y lo que mejor se consigue es para windows 7/8/10. Me preguntaba si alguno acá se ha instalado el xampp que le haya puesto postgresql para darme más pistas... -- Ayuda para hacer preguntas inteligentes: http://is.gd/NJIwRz
Re: Postgresql and DRBD
I've had good experiences running RedHat Cluster Services (corosync, pacemaker) for the GFS2 filesystem and databases on top of it. It performed and recovered well. However that was not with Postgresql. Most of my database work is with Oracle and mysql, but I have found Postgres separately to be excellent overall. On Tue, Apr 17, 2018 at 1:01 AM, Veli Cakmak <veli.li...@gmail.com> wrote: > Hello dear liste, > > I have really important database and it should not lost any data. Is it safe > Postgresql, DRBD, Pacemaker, Corosyn structure. ? > > Thanks, Best.
Re: Postgresql and DRBD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Apr 17, 2018 at 09:01:45AM +0300, Veli Cakmak wrote: > Hello dear liste, > > I have really important database and it should not lost any data. Is it > safe Postgresql, DRBD, Pacemaker, Corosyn structure. ? PostgreSQL has its own replication mechanisms [1] (WAL shipping, etc). Look into those, they are worth it. Just replicating the storage "behind" the database (e.g. with DRBD), without the database being aware of it doesn't seem to make much sense. Cheers [1] https://wiki.postgresql.org/wiki/Streaming_Replication - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlrVmSUACgkQBcgs9XrR2kYfvQCfTPSzRzzlSn6mnEC6dU7zfCNn DYoAnitl+FheV50wwCERIklZIMhMqLTP =+zyY -END PGP SIGNATURE-
Postgresql and DRBD
Hello dear liste, I have really important database and it should not lost any data. Is it safe Postgresql, DRBD, Pacemaker, Corosyn structure. ? Thanks, Best.
Server did not start after upgrade to postgresql 10
When I upgraded from postgresql 9.6 to 10, the postgres server failed to start. Error message: 'max_wal_senders must be less than max_connections'. The configuration file /etc/postgresql/10/main/postgresql.conf has the line #max_wal_senders = 0 suggesting that 0 is a default value. When I removed the comment symbol, effectively including this setting, I could start the server. This is different from 9.6. Is this a known problem, or should I report it as a bug? Simon
Re: Package postgresql-9.6 is not configured yet
Tried to solve it by looking at the configuration script but with no
success. I gave up and, after securing my database and configuration
file, I did an apt-get purge of all postgresql. Then I re-installed it
again.
Unfortunately the purge had left the /var/lib/postgres/9.6 and this
prevented the correct installation (/etc/postgresql/9.6 was missing). An
other purge and rm -rf /var/lib/postgres/9.6. Now the install went
correct. After copying back the config files and database files I was
back in business.
Problem CLOSED.
Op 27-08-17 om 10:46 schreef Marco DE BOOIJ:
The script stops at: invoke-rc.d postgresql start $VERSION #
systemd: argument ignored, starts all versions
This is the last step in the configure_version() function. Is this
really necessary when you use systemctl? Can I comment it safely just
to finish the configuration?
The server has already started a few times so I am sure that
postgresql restarts. Here is information on the postgresql service:
root:~# systemctl status postgresql
● postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/lib/systemd/system/postgresql.service; enabled)
Active: active (exited) since Fri 2017-08-25 08:08:22 CEST; 2 days ago
Main PID: 1269 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/postgresql.service
Aug 25 08:08:22 jessie systemd[1]: Started PostgreSQL RDBMS.
root:~#
Op 23-08-17 om 19:13 schreef Greg Wooledge:
On Wed, Aug 23, 2017 at 11:28:14AM -0400, Cindy-Sue Causey wrote:
On 8/23/17, Marco DE BOOIJ <marco.maill...@debooy.eu> wrote:
root:~# dpkg --configure postgresql-9.6
Setting up postgresql-9.6 (9.6.4-1.pgdg80+1) ...
dpkg: error processing package postgresql-9.6 (--configure):
subprocess installed post-installation script returned error exit
status 102
Errors were encountered while processing:
postgresql-9.6
A search attempt on the Net landed me the possibility that I'm
thinking of:
dpkg --configure -a
Yes, that's probably the first thing to try. But if that fails (again),
then the problem appears to be in the postinst script itself, or more
precisely whatever command the postinst script executes.
I don't have a stretch box with postgresql-9.6 installed at the moment,
but looking at a jessie box with -9.4, the postinst is simply this:
=
#!/bin/sh
set -e
VERSION=9.4
if [ "$1" = configure ]; then
. /usr/share/postgresql-common/maintscripts-functions
configure_version $VERSION "$2"
fi
=
Following the trail, the configure_version function is defined in
/usr/share/postgresql-common/maintscripts-functions and looks like:
=
configure_version() {
VERSION="$1"
# Create a main cluster for given version ($1) if no cluster
already exists
# for that version and we are installing from scratch.
[ "$VERSION" ] || { echo "Error: configure_version: need version
parameter" >&2; exit 1; }
if [ ! -d "/etc/postgresql/$VERSION" ] || [ -z "$(ls
/etc/postgresql/$VERSION)" ] || \
[ -z "$(ls /etc/postgresql/$VERSION/*/postgresql.conf
2>/dev/null)" ]; then
# skip creating the main cluster when this is not the first
install, or
# when explicitely disabled ($create is 1/0/"")
create=$(perl -I/usr/share/postgresql-common -mPgCommon -e
'print PgCommon::config_bool(PgCommon::get_conf_value 0, 0,
"createcluster.conf", "create_main_cluster")')
if [ -z "$2" ] && [ "$create" != "0" ]; then
set_system_locale
/usr/bin/pg_createcluster -u postgres $VERSION main ||
echo "Error: could not create default cluster.
Please create it manually with
pg_createcluster $VERSION main --start
or a similar command (see 'man pg_createcluster')." >&2
fi
fi
_link_manpages "$VERSION" postmaster.1.gz "postgresql-$1"
"postgresql-contrib-$1"
if [ -x /etc/init.d/postgresql ] && [ ! -x
/etc/init.d/postgresql-$VERSION ]; then
if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
invoke-rc.d postgresql start $VERSION || exit $?
else
/etc/init.d/postgresql start $VERSION || exit $?
fi
fi
}
=
Of course the stretch version may be different. Assuming Marco is
even running stretch; he didn't say.
So, to figure out what's breaking, what I would do is put "set -x" at
the
start of the configure_version function, and "set +x" at the end of it.
Then try dpkg --configure -a once again. That should give you a shell
trace of the commands being executed in that function, so you can see
which one breaks.
Assuming Marco's versions of these scripts look basically like jessie's.
Re: Package postgresql-9.6 is not configured yet
The script stops at: invoke-rc.d postgresql start $VERSION #
systemd: argument ignored, starts all versions
This is the last step in the configure_version() function. Is this
really necessary when you use systemctl? Can I comment it safely just to
finish the configuration?
The server has already started a few times so I am sure that postgresql
restarts. Here is information on the postgresql service:
root:~# systemctl status postgresql
● postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/lib/systemd/system/postgresql.service; enabled)
Active: active (exited) since Fri 2017-08-25 08:08:22 CEST; 2 days ago
Main PID: 1269 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/postgresql.service
Aug 25 08:08:22 jessie systemd[1]: Started PostgreSQL RDBMS.
root:~#
Op 23-08-17 om 19:13 schreef Greg Wooledge:
On Wed, Aug 23, 2017 at 11:28:14AM -0400, Cindy-Sue Causey wrote:
On 8/23/17, Marco DE BOOIJ <marco.maill...@debooy.eu> wrote:
root:~# dpkg --configure postgresql-9.6
Setting up postgresql-9.6 (9.6.4-1.pgdg80+1) ...
dpkg: error processing package postgresql-9.6 (--configure):
subprocess installed post-installation script returned error exit
status 102
Errors were encountered while processing:
postgresql-9.6
A search attempt on the Net landed me the possibility that I'm thinking of:
dpkg --configure -a
Yes, that's probably the first thing to try. But if that fails (again),
then the problem appears to be in the postinst script itself, or more
precisely whatever command the postinst script executes.
I don't have a stretch box with postgresql-9.6 installed at the moment,
but looking at a jessie box with -9.4, the postinst is simply this:
=
#!/bin/sh
set -e
VERSION=9.4
if [ "$1" = configure ]; then
. /usr/share/postgresql-common/maintscripts-functions
configure_version $VERSION "$2"
fi
=
Following the trail, the configure_version function is defined in
/usr/share/postgresql-common/maintscripts-functions and looks like:
=
configure_version() {
VERSION="$1"
# Create a main cluster for given version ($1) if no cluster already exists
# for that version and we are installing from scratch.
[ "$VERSION" ] || { echo "Error: configure_version: need version parameter"
>&2; exit 1; }
if [ ! -d "/etc/postgresql/$VERSION" ] || [ -z "$(ls
/etc/postgresql/$VERSION)" ] || \
[ -z "$(ls /etc/postgresql/$VERSION/*/postgresql.conf 2>/dev/null)" ];
then
# skip creating the main cluster when this is not the first install, or
# when explicitely disabled ($create is 1/0/"")
create=$(perl -I/usr/share/postgresql-common -mPgCommon -e 'print
PgCommon::config_bool(PgCommon::get_conf_value 0, 0, "createcluster.conf",
"create_main_cluster")')
if [ -z "$2" ] && [ "$create" != "0" ]; then
set_system_locale
/usr/bin/pg_createcluster -u postgres $VERSION main ||
echo "Error: could not create default cluster. Please create
it manually with
pg_createcluster $VERSION main --start
or a similar command (see 'man pg_createcluster')." >&2
fi
fi
_link_manpages "$VERSION" postmaster.1.gz "postgresql-$1"
"postgresql-contrib-$1"
if [ -x /etc/init.d/postgresql ] && [ ! -x /etc/init.d/postgresql-$VERSION
]; then
if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
invoke-rc.d postgresql start $VERSION || exit $?
else
/etc/init.d/postgresql start $VERSION || exit $?
fi
fi
}
=
Of course the stretch version may be different. Assuming Marco is
even running stretch; he didn't say.
So, to figure out what's breaking, what I would do is put "set -x" at the
start of the configure_version function, and "set +x" at the end of it.
Then try dpkg --configure -a once again. That should give you a shell
trace of the commands being executed in that function, so you can see
which one breaks.
Assuming Marco's versions of these scripts look basically like jessie's.
Re: Package postgresql-9.6 is not configured yet
The dpkg --configure -a gives the same result. I will look into the
scripts that you included and try them since I am on jessie. I will go
to stretch as soon as this problem is solved. Do not think that it is
not a good idea to do this now.
BTW Postgresql 9.6 is running well.
Marco
Op 23-08-17 om 19:13 schreef Greg Wooledge:
On Wed, Aug 23, 2017 at 11:28:14AM -0400, Cindy-Sue Causey wrote:
On 8/23/17, Marco DE BOOIJ <marco.maill...@debooy.eu> wrote:
root:~# dpkg --configure postgresql-9.6
Setting up postgresql-9.6 (9.6.4-1.pgdg80+1) ...
dpkg: error processing package postgresql-9.6 (--configure):
subprocess installed post-installation script returned error exit
status 102
Errors were encountered while processing:
postgresql-9.6
A search attempt on the Net landed me the possibility that I'm thinking of:
dpkg --configure -a
Yes, that's probably the first thing to try. But if that fails (again),
then the problem appears to be in the postinst script itself, or more
precisely whatever command the postinst script executes.
I don't have a stretch box with postgresql-9.6 installed at the moment,
but looking at a jessie box with -9.4, the postinst is simply this:
=
#!/bin/sh
set -e
VERSION=9.4
if [ "$1" = configure ]; then
. /usr/share/postgresql-common/maintscripts-functions
configure_version $VERSION "$2"
fi
=
Following the trail, the configure_version function is defined in
/usr/share/postgresql-common/maintscripts-functions and looks like:
=
configure_version() {
VERSION="$1"
# Create a main cluster for given version ($1) if no cluster already exists
# for that version and we are installing from scratch.
[ "$VERSION" ] || { echo "Error: configure_version: need version parameter"
>&2; exit 1; }
if [ ! -d "/etc/postgresql/$VERSION" ] || [ -z "$(ls
/etc/postgresql/$VERSION)" ] || \
[ -z "$(ls /etc/postgresql/$VERSION/*/postgresql.conf 2>/dev/null)" ];
then
# skip creating the main cluster when this is not the first install, or
# when explicitely disabled ($create is 1/0/"")
create=$(perl -I/usr/share/postgresql-common -mPgCommon -e 'print
PgCommon::config_bool(PgCommon::get_conf_value 0, 0, "createcluster.conf",
"create_main_cluster")')
if [ -z "$2" ] && [ "$create" != "0" ]; then
set_system_locale
/usr/bin/pg_createcluster -u postgres $VERSION main ||
echo "Error: could not create default cluster. Please create
it manually with
pg_createcluster $VERSION main --start
or a similar command (see 'man pg_createcluster')." >&2
fi
fi
_link_manpages "$VERSION" postmaster.1.gz "postgresql-$1"
"postgresql-contrib-$1"
if [ -x /etc/init.d/postgresql ] && [ ! -x /etc/init.d/postgresql-$VERSION
]; then
if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
invoke-rc.d postgresql start $VERSION || exit $?
else
/etc/init.d/postgresql start $VERSION || exit $?
fi
fi
}
=
Of course the stretch version may be different. Assuming Marco is
even running stretch; he didn't say.
So, to figure out what's breaking, what I would do is put "set -x" at the
start of the configure_version function, and "set +x" at the end of it.
Then try dpkg --configure -a once again. That should give you a shell
trace of the commands being executed in that function, so you can see
which one breaks.
Assuming Marco's versions of these scripts look basically like jessie's.
Re: Package postgresql-9.6 is not configured yet
On Wed, Aug 23, 2017 at 11:28:14AM -0400, Cindy-Sue Causey wrote:
> On 8/23/17, Marco DE BOOIJ <marco.maill...@debooy.eu> wrote:
> > root:~# dpkg --configure postgresql-9.6
> > Setting up postgresql-9.6 (9.6.4-1.pgdg80+1) ...
> > dpkg: error processing package postgresql-9.6 (--configure):
> > subprocess installed post-installation script returned error exit
> > status 102
> > Errors were encountered while processing:
> > postgresql-9.6
> A search attempt on the Net landed me the possibility that I'm thinking of:
>
> dpkg --configure -a
Yes, that's probably the first thing to try. But if that fails (again),
then the problem appears to be in the postinst script itself, or more
precisely whatever command the postinst script executes.
I don't have a stretch box with postgresql-9.6 installed at the moment,
but looking at a jessie box with -9.4, the postinst is simply this:
=
#!/bin/sh
set -e
VERSION=9.4
if [ "$1" = configure ]; then
. /usr/share/postgresql-common/maintscripts-functions
configure_version $VERSION "$2"
fi
=
Following the trail, the configure_version function is defined in
/usr/share/postgresql-common/maintscripts-functions and looks like:
=
configure_version() {
VERSION="$1"
# Create a main cluster for given version ($1) if no cluster already exists
# for that version and we are installing from scratch.
[ "$VERSION" ] || { echo "Error: configure_version: need version parameter"
>&2; exit 1; }
if [ ! -d "/etc/postgresql/$VERSION" ] || [ -z "$(ls
/etc/postgresql/$VERSION)" ] || \
[ -z "$(ls /etc/postgresql/$VERSION/*/postgresql.conf 2>/dev/null)" ];
then
# skip creating the main cluster when this is not the first install, or
# when explicitely disabled ($create is 1/0/"")
create=$(perl -I/usr/share/postgresql-common -mPgCommon -e 'print
PgCommon::config_bool(PgCommon::get_conf_value 0, 0, "createcluster.conf",
"create_main_cluster")')
if [ -z "$2" ] && [ "$create" != "0" ]; then
set_system_locale
/usr/bin/pg_createcluster -u postgres $VERSION main ||
echo "Error: could not create default cluster. Please create it
manually with
pg_createcluster $VERSION main --start
or a similar command (see 'man pg_createcluster')." >&2
fi
fi
_link_manpages "$VERSION" postmaster.1.gz "postgresql-$1"
"postgresql-contrib-$1"
if [ -x /etc/init.d/postgresql ] && [ ! -x /etc/init.d/postgresql-$VERSION
]; then
if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
invoke-rc.d postgresql start $VERSION || exit $?
else
/etc/init.d/postgresql start $VERSION || exit $?
fi
fi
}
=
Of course the stretch version may be different. Assuming Marco is
even running stretch; he didn't say.
So, to figure out what's breaking, what I would do is put "set -x" at the
start of the configure_version function, and "set +x" at the end of it.
Then try dpkg --configure -a once again. That should give you a shell
trace of the commands being executed in that function, so you can see
which one breaks.
Assuming Marco's versions of these scripts look basically like jessie's.
Re: Package postgresql-9.6 is not configured yet
On 8/23/17, Marco DE BOOIJ <marco.maill...@debooy.eu> wrote: > I recently did an apt-get upgrade and it did not want to install a newer > version of postgresql-contrib-9.6. I searched the web and tried to > reinstall it (with remove and install because I did not want to loose my > database) but did did not solve it. Before I will try to purge and > install it I want to ask if there is an 'easier' way. I also tried dpkg > --configure postgresql-9.6 but this fails: > > root:~# dpkg --configure postgresql-9.6 > Setting up postgresql-9.6 (9.6.4-1.pgdg80+1) ... > dpkg: error processing package postgresql-9.6 (--configure): > subprocess installed post-installation script returned error exit > status 102 > Errors were encountered while processing: > postgresql-9.6 > root:~# > > I checked the logfiles dpkg.log and alternatives.log but I saw no clear > information. > > dpkg.log: > > 2017-08-23 15:45:28 startup packages configure > 2017-08-23 15:45:28 configure postgresql-9.6:amd64 9.6.4-1.pgdg80+1 > 2017-08-23 15:45:28 status half-configured postgresql-9.6:amd64 > 9.6.4-1.pgdg80+1 > > alternatives.log showed only update-alternatives 2017-08-23 15:45:29: > run with --install with all files for *man*. > > Recently I removed version 9.5. Perhaps this is the reason for the > problem. Some information on the installation: > > root:~# dpkg-query -l | grep postgres > ii pgdg-keyring 2017.1 > iU postgresql 9.6+184.pgdg80+1 > iF postgresql-9.69.6.4-1.pgdg80+1 > ii postgresql-client-9.6 9.6.4-1.pgdg80+1 > ii postgresql-client-common 184.pgdg80+1 > ii postgresql-common 184.pgdg80+1 > iU postgresql-contrib 9.6+184.pgdg80+1 > iU postgresql-contrib-9.69.6.4-1.pgdg80+1 > root:~# apt-get install postgresql postgresql-contrib > Reading package lists... Done > Building dependency tree > Reading state information... Done > postgresql is already the newest version. > postgresql-contrib is already the newest version. > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > 4 not fully installed or removed. > After this operation, 0 B of additional disk space will be used. > Do you want to continue? [Y/n] > Setting up postgresql-9.6 (9.6.4-1.pgdg80+1) ... > dpkg: error processing package postgresql-9.6 (--configure): > subprocess installed post-installation script returned error exit > status 102 > dpkg: dependency problems prevent configuration of postgresql: > postgresql depends on postgresql-9.6; however: >Package postgresql-9.6 is not configured yet. That "4 not fully installed or removed." is one part of whatever is going on. I've had that happen if I CTRL+C cancel a command before it's finished, but there could be any number of other reasons why it happens, I'm sure. There's a command that you can run, but I forget what it is that *usually* cleans up house for me. ONCE in a while it's a bigger battle than just that, though. A search attempt on the Net landed me the possibility that I'm thinking of: dpkg --configure -a I took that back to "man dpkg" which additionally references "dpkg-reconfigure". PLEASE do *NOT* try these without researching what they do. I *have*, yes, had success, and those sound familiar of part of that success. Maybe someone else has insight based on those *if* they're appropriate to consider as one option in your instance.. Good luck with your situation.. Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with duct tape *
Package postgresql-9.6 is not configured yet
I recently did an apt-get upgrade and it did not want to install a newer version of postgresql-contrib-9.6. I searched the web and tried to reinstall it (with remove and install because I did not want to loose my database) but did did not solve it. Before I will try to purge and install it I want to ask if there is an 'easier' way. I also tried dpkg --configure postgresql-9.6 but this fails: root:~# dpkg --configure postgresql-9.6 Setting up postgresql-9.6 (9.6.4-1.pgdg80+1) ... dpkg: error processing package postgresql-9.6 (--configure): subprocess installed post-installation script returned error exit status 102 Errors were encountered while processing: postgresql-9.6 root:~# I checked the logfiles dpkg.log and alternatives.log but I saw no clear information. dpkg.log: 2017-08-23 15:45:28 startup packages configure 2017-08-23 15:45:28 configure postgresql-9.6:amd64 9.6.4-1.pgdg80+1 2017-08-23 15:45:28 status half-configured postgresql-9.6:amd64 9.6.4-1.pgdg80+1 alternatives.log showed only update-alternatives 2017-08-23 15:45:29: run with --install with all files for *man*. Recently I removed version 9.5. Perhaps this is the reason for the problem. Some information on the installation: root:~# dpkg-query -l | grep postgres ii pgdg-keyring 2017.1 iU postgresql9.6+184.pgdg80+1 iF postgresql-9.69.6.4-1.pgdg80+1 ii postgresql-client-9.6 9.6.4-1.pgdg80+1 ii postgresql-client-common 184.pgdg80+1 ii postgresql-common 184.pgdg80+1 iU postgresql-contrib9.6+184.pgdg80+1 iU postgresql-contrib-9.69.6.4-1.pgdg80+1 root:~# apt-get install postgresql postgresql-contrib Reading package lists... Done Building dependency tree Reading state information... Done postgresql is already the newest version. postgresql-contrib is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 4 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] Setting up postgresql-9.6 (9.6.4-1.pgdg80+1) ... dpkg: error processing package postgresql-9.6 (--configure): subprocess installed post-installation script returned error exit status 102 dpkg: dependency problems prevent configuration of postgresql: postgresql depends on postgresql-9.6; however: Package postgresql-9.6 is not configured yet. dpkg: error processing package postgresql (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of postgresql-contrib-9.6: postgresql-contrib-9.6 depends on postgresql-9.6 (= 9.6.4-1.pgdg80+1); however: Package postgresql-9.6 is not configured yet. dpkg: error processing package postgresql-contrib-9.6 (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of postgresql-contrib: postgresql-contrib depends on postgresql-contrib-9.6; however: Package postgresql-contrib-9.6 is not configured yet. dpkg: error processing package postgresql-contrib (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: postgresql-9.6 postgresql postgresql-contrib-9.6 postgresql-contrib E: Sub-process /usr/bin/dpkg returned an error code (1) root:~# cat /etc/apt/sources.list.d/pgdg.list deb http://apt.postgresql.org/pub/repos/apt/ jessie-pgdg main root:~# systemctl | grep postgres srv-postgres.mount loaded active mounted /srv/postgres postgresql.service loaded active exitedPostgreSQL RDBMS postgresql@9.6-main.service loaded active running PostgreSQL Cluster 9.6-main system-postgresql.slice loaded active active system-postgresql.slice root:~#
Re: systemd & postgresql - flooding system log
On Sun, 16 Jul 2017, Erwan David wrote: > Le 07/16/17 à 18:32, Don Armstrong a écrit : > > If you don't care about this in your log, then you can either filter it, > > or comment out pam_unix in /etc/pam.d/common-session-noninteractive. > > Commenting it will remove authentication methods ? No. That's a session module, not an auth module. If you comment it out from /etc/pam.d/common-auth, *then* bad things will happen. Quoting from pam_unix(8): "The session component of this module logs when a user logins or leave the system." You can read the source yourself, too: http://sources.debian.net/src/pam/1.1.8-3.6/modules/pam_unix/pam_unix_sess.c/#L99 -- Don Armstrong https://www.donarmstrong.com "A one-question geek test. If you get the joke, you're a geek: Seen on a California license plate on a VW Beetle: 'FEATURE'..." -- Joshua D. Wachs - Natural Intelligence, Inc.
Re: systemd & postgresql - flooding system log - SOLUTION
On Sun, Jul 16, 2017 at 12:32:22PM +0200, Václav Ovsík wrote: >... > With su is /var/log/auth.log flooded too, I didn't noticed > before :-/ (logcheck was filtering this). So the last chance is probably > the utility setpriv mentioned in the runuser manpage. Unfortunately the > utility is in the optional package with the same name and must by > installed additionally. I will try tomorrow and write about it. The setpriv is the final solution I hope. Replacement su by setpriv using the command: sed -r 's/su - \$DBUSER -c/setpriv --euid $DBUSER bash -c/g;' in the mk_postgres [1] quiets all log messages from pam and systemd. [1] http://git.mathias-kettner.de/git/?p=check_mk.git;a=blob;f=agents/plugins/mk_postgres;h=1de9b6de2d536b5d254888e6188fa3ec8b64c9bc;hb=HEAD Cheers -- Zito
Re: systemd & postgresql - flooding system log
Le 07/16/17 à 18:32, Don Armstrong a écrit : > On Sun, 16 Jul 2017, Václav Ovsík wrote: >> On Sun, Jul 16, 2017 at 12:01:56PM +0200, Václav Ovsík wrote: >>> OMG, I don't looked into /var/log/auth.log :( >>> >>> Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session closed for >>> user postgres >>> Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session opened for >>> user postgres by (uid=0) >>> Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session closed for >>> user postgres >>> Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session opened for >>> user postgres by (uid=0) >>> Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session closed for >>> user postgres >>> >>> No, I'm going back to LogLevel notice setting of systemd. :( > > This is not systemd logging this, but pam_unix.so. > >> With su is /var/log/auth.log flooded too, I didn't noticed before :-/ >> (logcheck was filtering this). > > If you don't care about this in your log, then you can either filter it, > or comment out pam_unix in /etc/pam.d/common-session-noninteractive. > > Commenting it will remove authentication methods ? Following that logic you could also tell to just stop the machine...
Re: systemd & postgresql - flooding system log
On Sun, 16 Jul 2017, Václav Ovsík wrote: > On Sun, Jul 16, 2017 at 12:01:56PM +0200, Václav Ovsík wrote: > > OMG, I don't looked into /var/log/auth.log :( > > > > Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session closed for > > user postgres > > Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session opened for > > user postgres by (uid=0) > > Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session closed for > > user postgres > > Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session opened for > > user postgres by (uid=0) > > Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session closed for > > user postgres > > > > No, I'm going back to LogLevel notice setting of systemd. :( This is not systemd logging this, but pam_unix.so. > With su is /var/log/auth.log flooded too, I didn't noticed before :-/ > (logcheck was filtering this). If you don't care about this in your log, then you can either filter it, or comment out pam_unix in /etc/pam.d/common-session-noninteractive. -- Don Armstrong https://www.donarmstrong.com Religion is religion, however you wrap it, and like Quell says, a preoccupation with the next world clearly signals an inability to cope credibly with this one. -- Richard K. Morgan "Broken Angels" p65
Re: systemd & postgresql - flooding system log
On Sun, Jul 16, 2017 at 12:01:56PM +0200, Václav Ovsík wrote: > OMG, I don't looked into /var/log/auth.log :( > > Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session closed for > user postgres > Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session opened for > user postgres by (uid=0) > Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session closed for > user postgres > Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session opened for > user postgres by (uid=0) > Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session closed for > user postgres > > ...flooding moved into /var/log/auth.log. > > No, I'm going back to LogLevel notice setting of systemd. :( With su is /var/log/auth.log flooded too, I didn't noticed before :-/ (logcheck was filtering this). So the last chance is probably the utility setpriv mentioned in the runuser manpage. Unfortunately the utility is in the optional package with the same name and must by installed additionally. I will try tomorrow and write about it. -- Zito
Re: systemd & postgresql - flooding system log
On Sun, Jul 16, 2017 at 12:32:22AM +0200, Václav Ovsík wrote: > Bingo! This helped runuser instead of su. > > su - $DBUSER -c [...] > to > runuser -c [...] $DBUSER OMG, I don't looked into /var/log/auth.log :( Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session closed for user postgres Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session opened for user postgres by (uid=0) Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session closed for user postgres Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session opened for user postgres by (uid=0) Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session closed for user postgres ...flooding moved into /var/log/auth.log. No, I'm going back to LogLevel notice setting of systemd. :( -- Zito
Re: systemd & postgresql - flooding system log
On Fri, Jul 14, 2017 at 05:07:22PM -0500, Don Armstrong wrote: >... > This plugin is horribly designed, and runs su - $DBUSER -c [...] for its > functioning. > > It should instead just su $DBUSER -c [...]; or better yet, not actually > su to the database user, and instead run as a user which only has the > ability to read the appropriate tables and cannot also write to. > > If you fix that so that it doesn't start a login session, you'll fix > the excessive number of sessions created. Unfortunately removing `-' didn't helped. On Sat, Jul 15, 2017 at 12:30:41AM +0200, Michael Biebl wrote: > Am 15.07.2017 um 00:07 schrieb Don Armstrong: > > This plugin is horribly designed, and runs su - $DBUSER -c [...] for its > > functioning. > > Indeed. > > > It should instead just su $DBUSER -c [...]; or better yet, not actually > > su to the database user, and instead run as a user which only has the > > ability to read the appropriate tables and cannot also write to. > > There is an alternative utility called runuser which is more suitable > for such cases. > It uses a different pam config and doesn't start a systemd logind session. Bingo! This helped runuser instead of su. su - $DBUSER -c [...] to runuser -c [...] $DBUSER Thanks -- Zito
Re: systemd & postgresql - flooding system log
On Fri, 14 Jul 2017, Jonathan de Boyne Pollard wrote: > Don Armstrong: > > Something like this (untested) > > When you do test it (-: you will discover the rather drastic > side-effect on all of the repeated SSH logins of suddenly running them > in a completely different control group with completely different > settings. The systemd PAM hook does quite a lot of things. Taking it > out does rather more than only the thing that is wanted here. That configuration does *not* take pam_systemd out. It just skips it for users which have a shell of /bin/false or /usr/sbin/nologin. -- Don Armstrong https://www.donarmstrong.com My spelling ability, or rather the lack thereof, is one of the wonders of the modern world.
Re: systemd & postgresql - flooding system log
Am 15.07.2017 um 00:07 schrieb Don Armstrong: > This plugin is horribly designed, and runs su - $DBUSER -c [...] for its > functioning. Indeed. > It should instead just su $DBUSER -c [...]; or better yet, not actually > su to the database user, and instead run as a user which only has the > ability to read the appropriate tables and cannot also write to. There is an alternative utility called runuser which is more suitable for such cases. It uses a different pam config and doesn't start a systemd logind session. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: systemd & postgresql - flooding system log
On Sat, 08 Jul 2017, Václav Ovsík wrote: > On Fri, Jul 07, 2017 at 10:34:20PM +0200, Michael Biebl wrote: > >... > > You create 19 PAM sessions for the postgres user per minute. What > > exactly are you doing here? > > This morning refreshed my mind :) > I completely forget about monitoring of the host yesterday. > There was installed plugin for Postgres in CheckMK agent monitoring agent. > http://mathias-kettner.com/checkmk.html > http://git.mathias-kettner.de/git/?p=check_mk.git;a=blob;f=agents/plugins/mk_postgres;h=1de9b6de2d536b5d254888e6188fa3ec8b64c9bc;hb=HEAD > The plugin can be improved the switch to database user will be done only > one time per run probably. This plugin is horribly designed, and runs su - $DBUSER -c [...] for its functioning. It should instead just su $DBUSER -c [...]; or better yet, not actually su to the database user, and instead run as a user which only has the ability to read the appropriate tables and cannot also write to. If you fix that so that it doesn't start a login session, you'll fix the excessive number of sessions created. -- Don Armstrong https://www.donarmstrong.com He no longer wished to be dead. At the same time, it cannot be said that he was glad to be alive. But at least he did not resent it. He was alive, and the stubbornness of this fact had little by little begun to fascinate him -- as if he had managed to outlive himself, as if he were somehow living a posthumous life. -- Paul Auster _City of Glass_
