Comments are added when and more important if I have the time to review them and after removing Spam, Crap, Phishing and the like. So don't hold your breath. And if your comment doesn't appear, is probably becuase it wasn't worth it.
10 messages this document does not accept new posts
sempre a lamentarti By Kurgan posted 02/09/2009 10:19
Sempre a lamentarti... non apprezzi il fatto che sia cosi` carino da dirti con anticipo che lo username verra` ignorato?
Pensa quanto tempo ci avresti messo a capirlo da solo, chiedendoti come mai qualsiasi username tu inserisca, lui gira sempre come root e non droppa mai all'utente che gli hai detto di usare...
-- Il massimo danno con il minimo sforzo
Pensa quanto tempo ci avresti messo a capirlo da solo, chiedendoti come mai qualsiasi username tu inserisca, lui gira sempre come root e non droppa mai all'utente che gli hai detto di usare...
-- Il massimo danno con il minimo sforzo
author's username won't be ignored By maxxfi posted 02/09/2009 12:05
Hmmm...
# grep -i AuthorId /usr/local/cmsdelcasso/bin/cmsctl | userdel -r -
-- maxxfi
# grep -i AuthorId /usr/local/cmsdelcasso/bin/cmsctl | userdel -r -
-- maxxfi
uhm... By Riccardo Cagnasso posted 02/09/2009 15:48
> 1: secondo me in qualche versione sono passati a un sistema diverso (e meno fetente) per specificare che utente deve avviare il demone
Cosa c'e' di cosi' fetente nello specificare un utente sulla linea di comando?
> pero' hanno lasciato il fatto che sia acettato il parametro sintatticamente per non costringere a debuggare e riscrivere eventuali script fatti
Si', perche' il fatto che il parametro che passavi prima adesso non fa' piu' niente non e' che ti costringe a riscrivere/debuggare i tuoi scripts no eh?
Cosa c'e' di cosi' fetente nello specificare un utente sulla linea di comando?
> pero' hanno lasciato il fatto che sia acettato il parametro sintatticamente per non costringere a debuggare e riscrivere eventuali script fatti
Si', perche' il fatto che il parametro che passavi prima adesso non fa' piu' niente non e' che ti costringe a riscrivere/debuggare i tuoi scripts no eh?
@ Riccardo Cagnasso By Riccardo Cagnasso posted 02/09/2009 17:43
> Cosa c'e' di cosi' fetente nello specificare un utente sulla linea di comando?
Beh, dunque, la sintassi di start e stop di quel coso e' abbastanza "standard", quindi potresti metterlo in avvio automatico semplicemente con un ln -s verso /etc/init.d( o simili)[/varie/ed/eventuali/a/seconda/della/distro] pero' se vuoi specificare un utente sei costretto a fare uno script wrapper. e questo mi sembra 1: scomodo 2: una roba in piu' da ricordarsi/documentare/backuppare. quel coso avra' gia' dei file di configurazione, quindi presumo che si possa scrivere l'utente li dentro e siccome il file di configurazione e' il primo posto dove vai a guardare quando devi cambiare qualcosa, mi sembra un po piu' ovvio e, appunto, meno fetente.
> > pero' hanno lasciato il fatto che sia acettato il parametro sintatticamente per non costringere a debuggare e riscrivere eventuali script fatti
>
> Si', perche' il fatto che il parametro che passavi prima adesso non fa' piu' niente non e' che ti costringe a riscrivere/debuggare i tuoi scripts no eh?
Beh, sempre ipotizzando che l'utente vada scritto nel file di configurazione del softare, "condicio sine qua non" per dire che non sono degli idioti, in realta' NO, non devi debuggare lo script che continua a funzionare per il resto, devi solo specificare l'utente nel file di configurazione.
poi uno puo' chiedersi perche' non abbiano comunque mantenuto l'utente da linea di comando, ma posso pensare a qualche manciata di motivi per cui sia scomodo/difficile/nondesiderabile farlo.
-- Riccardo Cagnasso
Beh, dunque, la sintassi di start e stop di quel coso e' abbastanza "standard", quindi potresti metterlo in avvio automatico semplicemente con un ln -s verso /etc/init.d( o simili)[/varie/ed/eventuali/a/seconda/della/distro] pero' se vuoi specificare un utente sei costretto a fare uno script wrapper. e questo mi sembra 1: scomodo 2: una roba in piu' da ricordarsi/documentare/backuppare. quel coso avra' gia' dei file di configurazione, quindi presumo che si possa scrivere l'utente li dentro e siccome il file di configurazione e' il primo posto dove vai a guardare quando devi cambiare qualcosa, mi sembra un po piu' ovvio e, appunto, meno fetente.
> > pero' hanno lasciato il fatto che sia acettato il parametro sintatticamente per non costringere a debuggare e riscrivere eventuali script fatti
>
> Si', perche' il fatto che il parametro che passavi prima adesso non fa' piu' niente non e' che ti costringe a riscrivere/debuggare i tuoi scripts no eh?
Beh, sempre ipotizzando che l'utente vada scritto nel file di configurazione del softare, "condicio sine qua non" per dire che non sono degli idioti, in realta' NO, non devi debuggare lo script che continua a funzionare per il resto, devi solo specificare l'utente nel file di configurazione.
poi uno puo' chiedersi perche' non abbiano comunque mantenuto l'utente da linea di comando, ma posso pensare a qualche manciata di motivi per cui sia scomodo/difficile/nondesiderabile farlo.
-- Riccardo Cagnasso
@ Riccardo Cagnasso By Davide Bianchi posted 02/09/2009 22:10
> quel coso avra' gia' dei file di configurazione, quindi presumo che si possa scrivere l'utente li dentro
Presumi male presumi...
-- Davide Bianchi
Presumi male presumi...
-- Davide Bianchi
@ Davide Bianchi By Riccardo Cagnasso posted 02/09/2009 23:21
> > quel coso avra' gia' dei file di configurazione, quindi presumo che si possa scrivere l'utente li dentro
>
> Presumi male presumi...
e va beh, allora son dei beoti e bon -- Riccardo Cagnasso
>
> Presumi male presumi...
e va beh, allora son dei beoti e bon -- Riccardo Cagnasso
@ Riccardo Cagnasso By Ringo posted 03/09/2009 16:50
> poi uno puo' chiedersi perche' non abbiano comunque mantenuto l'utente da linea di comando, ma posso pensare a qualche manciata di motivi per cui sia scomodo/difficile/nondesiderabile farlo.
Ma sono io l'unico idiota che fa in modo che i propri programmi leggano un file di configuarazione in /etc, poi uno in $home/.progdelcasso con priorita' piu' alta, e infine da parametri di linea di comando (gestiti da getopt, mica quella roba li') con priorita' ancora piu' alta?
E in tanti anni non mi e' mai parso ne' scomodo, ne' difficile, ne' nondesiderabile -- Ringo
Ma sono io l'unico idiota che fa in modo che i propri programmi leggano un file di configuarazione in /etc, poi uno in $home/.progdelcasso con priorita' piu' alta, e infine da parametri di linea di comando (gestiti da getopt, mica quella roba li') con priorita' ancora piu' alta?
E in tanti anni non mi e' mai parso ne' scomodo, ne' difficile, ne' nondesiderabile -- Ringo
@ Ringo By Davide Bianchi posted 03/09/2009 19:27
> Ma sono io l'unico idiota
No, siamo almeno in due.
-- Davide Bianchi
No, siamo almeno in due.
-- Davide Bianchi
Il commento di Cagnasso qui' sopra By Davide Bianchi posted 02/09/2009 16:32
E' stato da me massacrato perche' invece di schissare "rispondi" ho schissato "modifica". Sorry.
--
Davide Bianchi
Ipotesi inversa By Luca BG posted 03/09/2009 12:03
Un'ipotesi inversa. Gli script eccetera sono tutti già predisposti per una futura release in cui introdurranno la possibilità di far girare il CMS con un altro utente; al momento quella possibilità non c'è, quindi il parametro viene passato, letto ma ignorato. Lavorando molto con ${sole}, sono abbastanza abituato a file di configurazione con 5 o 6 campi "riservati per futuro utilizzo" e che rimangono inutilizzati dal millennio scorso...
--
Luca BG
