Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
avvio postgresql
241 views
Skip to first unread message
Alessandro Baggi
Feb 8, 2014, 1:50:01 PM2/8/14
to
Salve lista,
stavo facendo delle prove con postgresql e volevo provare a configurare
l'accesso su postgres con l'inserimento di password, che sia in
localhost oppure con Unix-domain socket (da utente postgres).
Ho modificato nel file pg_hba.conf, il metodo della riga relativa
all'utente postgres da:
local all postgres peer
a
local all postgres md5
Il risultato dovrebbe essere che tutti gli accessi su db, che siano su
localhost oppure tramite Unix-domain socket richiedano una password.
Al successivo riavvio di postgresql, ottengo un sfilza di:
root@hostname:/etc/postgresql/9.1/main# /etc/init.d/postgresql start
[....] Starting PostgreSQL 9.1 database server: main[....] The
PostgreSQL server failed to start. Please check the log output:
2014-02-08 19:25:25 CET LOG: il database ? stato arrestato alle
2014-02-08 19:24:59 CET 2014-02-08 19:25:25 CET LOG: il database ?
pronto ad accettare connessioni 2014-02-08 19:25:25 CET LOG: esecutore
di autovacuum avviato 2014-02-08 19:25:25 CET LOG: pacchetto di avvio
incompleto 2014-02-08 19:25:26 CET FATALE: autenticazione con password
fallita per l'utente "postgres" 2014-02-08 19:25:26 CET FATALE:
autenticazione con password fallita per l'utente "postgres" 2014-02-08
19:25:27 CET FATALE: autenticazione con password fallita per l'utente
"postgres" 2014-02-08 19:25:27 CET FATALE: autenticazione con password
fallita per l'utente "postgres" 2014-02-08 19:25:28 CET FATALE:
autenticazione con password fallita per l'utente "postgres" 2014-02-08
19:25:28 CET FATALE: autenticazione con password fallita per l'utente
"postgres" 2014-02-08 19:25:29 CET FATALE: autenticazione con password
fallita per l'utente "postgres" 2014-02-08 19:25:29 CET FATALE:
autenticazione con password fallita per l'utente "postgres" 2014-02-08
19:25:30 CET FATALE: autenticazione con password fallita per l'utente
"postgres" 2014-02-08 19:25:30 CET FATALE: autent[FAILone con password
fallita per l'utente "postgres" 2014-02-08 19:25:31 CET FATALE:
autenticazione con password fallita per l'utente "postgres" ... failed!
failed!
e dal log:
2014-02-08 19:30:18 CET LOG: il database ? stato arrestato alle
2014-02-08 19:30:11 CET
2014-02-08 19:30:18 CET LOG: il database ? pronto ad accettare connessioni
2014-02-08 19:30:18 CET LOG: esecutore di autovacuum avviato
2014-02-08 19:30:18 CET LOG: pacchetto di avvio incompleto
2014-02-08 19:30:18 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
2014-02-08 19:30:19 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
2014-02-08 19:30:19 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
2014-02-08 19:30:20 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
2014-02-08 19:30:20 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
2014-02-08 19:30:21 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
2014-02-08 19:30:21 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
2014-02-08 19:30:22 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
2014-02-08 19:30:22 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
2014-02-08 19:30:23 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
2014-02-08 19:30:24 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
ottenendo pero il risultato desiderato. Quindi, postgresql viene avviato
e per qualsiasi login viene richiesta la password.
Ora ho diversi dubbi al riguardo:
1) Quale č l'operazione che viene eseguita e che riporta errore durante
l'avvio? Ho provato a vedere in
/usr/share/postgresql-common/init.d-functions ma non ne vengo a capo
(sempre se č il punto giusto da cui iniziare)
2) La richiesta della password in fase di autenticazione per l'utente
postgres tramite unix socket domain, aumenta la sicurezza, oppure non
serve assolutamente a niente, o magari peggiora le cose?
Vi ringrazio in anticipo.
Un saluto.
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-ital...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listm...@lists.debian.org
To UNSUBSCRIBE, email to debian-ital...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/52F67A3E...@gmail.com
stavo facendo delle prove con postgresql e volevo provare a configurare
l'accesso su postgres con l'inserimento di password, che sia in
localhost oppure con Unix-domain socket (da utente postgres).
Ho modificato nel file pg_hba.conf, il metodo della riga relativa
all'utente postgres da:
local all postgres peer
a
local all postgres md5
Il risultato dovrebbe essere che tutti gli accessi su db, che siano su
localhost oppure tramite Unix-domain socket richiedano una password.
Al successivo riavvio di postgresql, ottengo un sfilza di:
root@hostname:/etc/postgresql/9.1/main# /etc/init.d/postgresql start
[....] Starting PostgreSQL 9.1 database server: main[....] The
PostgreSQL server failed to start. Please check the log output:
2014-02-08 19:25:25 CET LOG: il database ? stato arrestato alle
2014-02-08 19:24:59 CET 2014-02-08 19:25:25 CET LOG: il database ?
pronto ad accettare connessioni 2014-02-08 19:25:25 CET LOG: esecutore
di autovacuum avviato 2014-02-08 19:25:25 CET LOG: pacchetto di avvio
incompleto 2014-02-08 19:25:26 CET FATALE: autenticazione con password
fallita per l'utente "postgres" 2014-02-08 19:25:26 CET FATALE:
autenticazione con password fallita per l'utente "postgres" 2014-02-08
19:25:27 CET FATALE: autenticazione con password fallita per l'utente
"postgres" 2014-02-08 19:25:27 CET FATALE: autenticazione con password
fallita per l'utente "postgres" 2014-02-08 19:25:28 CET FATALE:
autenticazione con password fallita per l'utente "postgres" 2014-02-08
19:25:28 CET FATALE: autenticazione con password fallita per l'utente
"postgres" 2014-02-08 19:25:29 CET FATALE: autenticazione con password
fallita per l'utente "postgres" 2014-02-08 19:25:29 CET FATALE:
autenticazione con password fallita per l'utente "postgres" 2014-02-08
19:25:30 CET FATALE: autenticazione con password fallita per l'utente
"postgres" 2014-02-08 19:25:30 CET FATALE: autent[FAILone con password
fallita per l'utente "postgres" 2014-02-08 19:25:31 CET FATALE:
autenticazione con password fallita per l'utente "postgres" ... failed!
failed!
e dal log:
2014-02-08 19:30:18 CET LOG: il database ? stato arrestato alle
2014-02-08 19:30:11 CET
2014-02-08 19:30:18 CET LOG: il database ? pronto ad accettare connessioni
2014-02-08 19:30:18 CET LOG: esecutore di autovacuum avviato
2014-02-08 19:30:18 CET LOG: pacchetto di avvio incompleto
2014-02-08 19:30:18 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
2014-02-08 19:30:19 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
2014-02-08 19:30:19 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
2014-02-08 19:30:20 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
2014-02-08 19:30:20 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
2014-02-08 19:30:21 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
2014-02-08 19:30:21 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
2014-02-08 19:30:22 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
2014-02-08 19:30:22 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
2014-02-08 19:30:23 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
2014-02-08 19:30:24 CET FATALE: autenticazione con password fallita per
l'utente "postgres"
ottenendo pero il risultato desiderato. Quindi, postgresql viene avviato
e per qualsiasi login viene richiesta la password.
Ora ho diversi dubbi al riguardo:
1) Quale č l'operazione che viene eseguita e che riporta errore durante
l'avvio? Ho provato a vedere in
/usr/share/postgresql-common/init.d-functions ma non ne vengo a capo
(sempre se č il punto giusto da cui iniziare)
2) La richiesta della password in fase di autenticazione per l'utente
postgres tramite unix socket domain, aumenta la sicurezza, oppure non
serve assolutamente a niente, o magari peggiora le cose?
Vi ringrazio in anticipo.
Un saluto.
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-ital...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listm...@lists.debian.org
To UNSUBSCRIBE, email to debian-ital...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/52F67A3E...@gmail.com
Federico Di Gregorio
Feb 9, 2014, 2:40:02 PM2/9/14
to
On 08/02/2014 19:41, Alessandro Baggi wrote:
> stavo facendo delle prove con postgresql e volevo provare a configurare
> l'accesso su postgres con l'inserimento di password, che sia in
> localhost oppure con Unix-domain socket (da utente postgres).
> Ho modificato nel file pg_hba.conf, il metodo della riga relativa
> all'utente postgres da:
Cosě, per sapere, perché? L'utente postgres in peer su UNIX socket č
> stavo facendo delle prove con postgresql e volevo provare a configurare
> l'accesso su postgres con l'inserimento di password, che sia in
> localhost oppure con Unix-domain socket (da utente postgres).
> Ho modificato nel file pg_hba.conf, il metodo della riga relativa
> all'utente postgres da:
sicuro almeno quanto la macchina su cui sta girando. Non c'č bisogno di
password.
federico
--
Federico Di Gregorio federico....@dndg.it
Di Nunzio & Di Gregorio srl http://dndg.it
The only thing I see is if you are pumping so much data into the
database all the time when do you expect to look at it?
-- Charlie Clark
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-ital...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listm...@lists.debian.org
To UNSUBSCRIBE, email to debian-ital...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
dea
Feb 9, 2014, 4:00:02 PM2/9/14
to
> Così, per sapere, perché? L'utente postgres in peer su UNIX socket è
> sicuro almeno quanto la macchina su cui sta girando. Non c'è bisogno
> di password.
>
> federico
+1 e non solo perchè lo dice FOG !
:)
Luca
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-ital...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listm...@lists.debian.org
To UNSUBSCRIBE, email to debian-ital...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Alessandro Baggi
Feb 10, 2014, 4:20:02 AM2/10/14
to
On 09/02/2014 21:51, dea wrote:
>
>> Così, per sapere, perché? L'utente postgres in peer su UNIX socket è
>> sicuro almeno quanto la macchina su cui sta girando. Non c'è bisogno
>> di password.
>>
>> federico
>
> +1 e non solo perchè lo dice FOG !
>
> :)
>
> Luca
>
>
Salve Federico e Luca,
>
>> Così, per sapere, perché? L'utente postgres in peer su UNIX socket è
>> sicuro almeno quanto la macchina su cui sta girando. Non c'è bisogno
>> di password.
>>
>> federico
>
> +1 e non solo perchè lo dice FOG !
>
> :)
>
> Luca
>
>
il motivo è relativo al fatto che molti asseriscono che un sistema sia
sicuro di per se, semplicemente per fede, anche con il mondo installato
sopra e questo non è sempre vero. Ora tralasciando la sicurezza legata a
Debian e i possibili errori di un admin, stavo provando ad entrare nel
mondo postgresql e stavo considerando le acl di pg.
Supponendo che il sistema non sia cosi sicuro, l'utilizzo di una
politica del genere (forse paranoica) porterebbe dei vantaggi oppure è
solo una perdita di tempo (del tipo tanto in un modo o nell'altro ci si
arriva sempre sul db)?
Per quanto riguarda l'errore riportato, e considerando che la
configurazione sia utile al nostro scopo, da cosa può dipendere?
Un saluto Alessandro.
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-ital...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listm...@lists.debian.org
To UNSUBSCRIBE, email to debian-ital...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Gian Uberto Lauri
Feb 10, 2014, 4:50:01 AM2/10/14
to
Alessandro Baggi writes:
> Ora tralasciando la sicurezza legata a
> Debian e i possibili errori di un admin, stavo provando ad entrare nel
> mondo postgresql e stavo considerando le acl di pg.
> Supponendo che il sistema non sia cosi sicuro, l'utilizzo di una
> politica del genere (forse paranoica) porterebbe dei vantaggi oppure è
> solo una perdita di tempo (del tipo tanto in un modo o nell'altro ci si
> arriva sempre sul db)?
Ammetto che non ho capito che password vuoi far usare (quelle
> Ora tralasciando la sicurezza legata a
> Debian e i possibili errori di un admin, stavo provando ad entrare nel
> mondo postgresql e stavo considerando le acl di pg.
> Supponendo che il sistema non sia cosi sicuro, l'utilizzo di una
> politica del genere (forse paranoica) porterebbe dei vantaggi oppure è
> solo una perdita di tempo (del tipo tanto in un modo o nell'altro ci si
> arriva sempre sul db)?
dell'utente Unix? Quelle dell'utente postgres?), la sicurezza è troppa
quando costa di più dell'oggetto che protegge.
--
Gian
Friends will be friends
right to the end!
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-ital...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listm...@lists.debian.org
To UNSUBSCRIBE, email to debian-ital...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Alessandro Baggi
Feb 10, 2014, 5:20:01 AM2/10/14
to
On 10/02/2014 10:49, Gian Uberto Lauri wrote:
> Alessandro Baggi writes:
> > Ora tralasciando la sicurezza legata a
> > Debian e i possibili errori di un admin, stavo provando ad entrare nel
> > mondo postgresql e stavo considerando le acl di pg.
> > Supponendo che il sistema non sia cosi sicuro, l'utilizzo di una
> > politica del genere (forse paranoica) porterebbe dei vantaggi oppure è
> > solo una perdita di tempo (del tipo tanto in un modo o nell'altro ci si
> > arriva sempre sul db)?
>
> Ammetto che non ho capito che password vuoi far usare (quelle
> dell'utente Unix? Quelle dell'utente postgres?), la sicurezza è troppa
> quando costa di più dell'oggetto che protegge.
>
Per la password intendo quelle dell'utente superuser postgres del db.
> Alessandro Baggi writes:
> > Ora tralasciando la sicurezza legata a
> > Debian e i possibili errori di un admin, stavo provando ad entrare nel
> > mondo postgresql e stavo considerando le acl di pg.
> > Supponendo che il sistema non sia cosi sicuro, l'utilizzo di una
> > politica del genere (forse paranoica) porterebbe dei vantaggi oppure è
> > solo una perdita di tempo (del tipo tanto in un modo o nell'altro ci si
> > arriva sempre sul db)?
>
> Ammetto che non ho capito che password vuoi far usare (quelle
> dell'utente Unix? Quelle dell'utente postgres?), la sicurezza è troppa
> quando costa di più dell'oggetto che protegge.
>
Concordo con:
> la sicurezza è troppa
>> quando costa di più dell'oggetto che protegge.
posto questa domanda e cercavo di capire quanto realmente fosse utile e
gli errori che ricevevo in avvio di pg.
Alessandro.
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-ital...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listm...@lists.debian.org
To UNSUBSCRIBE, email to debian-ital...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Federico Di Gregorio
Feb 10, 2014, 5:30:02 AM2/10/14
to
On 10/02/2014 10:19, Alessandro Baggi wrote:
> il motivo è relativo al fatto che molti asseriscono che un sistema sia
> sicuro di per se, semplicemente per fede, anche con il mondo installato
> sopra e questo non è sempre vero. Ora tralasciando la sicurezza legata a
> Debian e i possibili errori di un admin, stavo provando ad entrare nel
> mondo postgresql e stavo considerando le acl di pg.
> Supponendo che il sistema non sia cosi sicuro, l'utilizzo di una
> politica del genere (forse paranoica) porterebbe dei vantaggi oppure è
> solo una perdita di tempo (del tipo tanto in un modo o nell'altro ci si
> arriva sempre sul db)?
Caro Alessandro,
> il motivo è relativo al fatto che molti asseriscono che un sistema sia
> sicuro di per se, semplicemente per fede, anche con il mondo installato
> sopra e questo non è sempre vero. Ora tralasciando la sicurezza legata a
> Debian e i possibili errori di un admin, stavo provando ad entrare nel
> mondo postgresql e stavo considerando le acl di pg.
> Supponendo che il sistema non sia cosi sicuro, l'utilizzo di una
> politica del genere (forse paranoica) porterebbe dei vantaggi oppure è
> solo una perdita di tempo (del tipo tanto in un modo o nell'altro ci si
> arriva sempre sul db)?
in questo caso, forzare una password per la connessione su socket UNIX
dell'utente amministratore (postgres) non è più sicuro che lasciarla in
"peer" (anzi, forse meno).
Se metti una password CHIUNQUE la conosca può accedere (anche in rete,
se ho ben capito la configurazione che vuoi dalla tua email iniziale).
Se lasci "peer" solo root (via "su - postgres") può accedere e solo
dalla macchina locale: l'utente postgres non ha password e non può fare
il login (ne in locale ne dalla rete).
> Per quanto riguarda l'errore riportato, e considerando che la
> configurazione sia utile al nostro scopo, da cosa può dipendere?
ai vari script pg_xxx. Immagino che questi accedano a PostgreSQL
utilizzando l'amministratore e nel tuo caso non ci riescano.
Per maggiori informazioni puoi guardare lo script direttamente coinvolto
nello start/stop:
$ less $(which pg_ctlcluster)
A desobediência é uma virtude necessária à criatividade. -- Raul Seixas
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-ital...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listm...@lists.debian.org
To UNSUBSCRIBE, email to debian-ital...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Alessandro Baggi
Feb 10, 2014, 6:00:02 AM2/10/14
to
On 10/02/2014 11:05, Federico Di Gregorio wrote:
> Caro Alessandro,
>
> in questo caso, forzare una password per la connessione su socket UNIX
> dell'utente amministratore (postgres) non è più sicuro che lasciarla in
> "peer" (anzi, forse meno).
>
> Se metti una password CHIUNQUE la conosca può accedere (anche in rete,
> se ho ben capito la configurazione che vuoi dalla tua email iniziale).
>
> Se lasci "peer" solo root (via "su - postgres") può accedere e solo
> dalla macchina locale: l'utente postgres non ha password e non può fare
> il login (ne in locale ne dalla rete).
>
>> Per quanto riguarda l'errore riportato, e considerando che la
>> configurazione sia utile al nostro scopo, da cosa può dipendere?
>
> In Debian l'avvio di PostgreSQL (e la gestione dei cluster) è delegata
> ai vari script pg_xxx. Immagino che questi accedano a PostgreSQL
> utilizzando l'amministratore e nel tuo caso non ci riescano.
>
> Per maggiori informazioni puoi guardare lo script direttamente coinvolto
> nello start/stop:
>
> $ less $(which pg_ctlcluster)
>
> federico
>
Ciao Federico,
> Caro Alessandro,
>
> in questo caso, forzare una password per la connessione su socket UNIX
> dell'utente amministratore (postgres) non è più sicuro che lasciarla in
> "peer" (anzi, forse meno).
>
> Se metti una password CHIUNQUE la conosca può accedere (anche in rete,
> se ho ben capito la configurazione che vuoi dalla tua email iniziale).
>
> Se lasci "peer" solo root (via "su - postgres") può accedere e solo
> dalla macchina locale: l'utente postgres non ha password e non può fare
> il login (ne in locale ne dalla rete).
>
>> Per quanto riguarda l'errore riportato, e considerando che la
>> configurazione sia utile al nostro scopo, da cosa può dipendere?
>
> In Debian l'avvio di PostgreSQL (e la gestione dei cluster) è delegata
> ai vari script pg_xxx. Immagino che questi accedano a PostgreSQL
> utilizzando l'amministratore e nel tuo caso non ci riescano.
>
> Per maggiori informazioni puoi guardare lo script direttamente coinvolto
> nello start/stop:
>
> $ less $(which pg_ctlcluster)
>
> federico
>
grazie mille per la risposta. Hai centrato in pieno quello che intendevo.
Quindi risulta solo in una complicazione della configurazione senza un
reale miglioramento.
Grazie ancora.
Un saluto Alessandro.
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-ital...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listm...@lists.debian.org
To UNSUBSCRIBE, email to debian-ital...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Tino Sino
May 2, 2015, 7:10:03 AM5/2/15
to
> Alessandro Baggi writes:
> > Ora tralasciando la sicurezza legata a
> > Debian e i possibili errori di un admin, stavo provando ad entrare nel
> > mondo postgresql e stavo considerando le acl di pg.
> > Supponendo che il sistema non sia cosi sicuro, l'utilizzo di una
> > politica del genere (forse paranoica) porterebbe dei vantaggi oppure è
> > solo una perdita di tempo (del tipo tanto in un modo o nell'altro ci si
> > arriva sempre sul db)?
>
> Ammetto che non ho capito che password vuoi far usare (quelle
> dell'utente Unix? Quelle dell'utente postgres?), la sicurezza è troppa
> quando costa di più dell'oggetto che protegge.
Oh. Se richiami il vecchio adagio d'economia manca la moltiplicazione per la
> > Ora tralasciando la sicurezza legata a
> > Debian e i possibili errori di un admin, stavo provando ad entrare nel
> > mondo postgresql e stavo considerando le acl di pg.
> > Supponendo che il sistema non sia cosi sicuro, l'utilizzo di una
> > politica del genere (forse paranoica) porterebbe dei vantaggi oppure è
> > solo una perdita di tempo (del tipo tanto in un modo o nell'altro ci si
> > arriva sempre sul db)?
>
> Ammetto che non ho capito che password vuoi far usare (quelle
> dell'utente Unix? Quelle dell'utente postgres?), la sicurezza è troppa
> quando costa di più dell'oggetto che protegge.
probabilità che la sicurezza venga violata (e.g. 25% => P(v) = moltiplica per
0.25) ;) quindi può essere "troppa" anche prima. Ma non chiedermi come
calcolare P(v) senza usare la statistica! :(
>
> --
> Gian
> Friends will be friends
> right to the end!
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-ital...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listm...@lists.debian.org
To UNSUBSCRIBE, email to debian-ital...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages