Newsgroup: it.comp.os.linux.iniziare
Titolo: chi e' root

Ho scritto un messaggio precedente che non mi appare, mi scuso per
eventuali duplicati.
Il mio problema e' che non riesco a capire chi e' root sul mio pc. Il mio
account e' l'unico presente e in System>Administration>Users and group
appare il solo e accanto a Account type c'e' scritto amministratore.
Ma allora perche' se nel dubbio do il comando "su -" e poi do la mia
password mi risponde "su: Authentication failure"??
 
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 password mi risponde "su: Authentication failure"??
ubuntu user, I suppose ;-P
r
ps
sudo pswd
-- 
----x----
---- ----
---- ----
                Camminare sulla brina.
---- ----
---- ----
---- ----
Ramapage: 
http://umpf.net/


Perché sei su una distribuzione che immaginiamo essere una ubuntu, cmq 
una di quelle basate sul concetto di "sudo"
Se vuoi davvero diventare root devi dare un
$sudo su
Password:
#
Io però te lo sconsiglio
Quelle distribuzioni sono pensate per passare attraverso il sudo e se lo 
bypassi o sai molto bene quello che fai o è meglio che tu abbia un 
backup recente
A ripensarci è sempre meglio avere un backup recente a prescindere dalla 
distro :)
M
-- 
I fatti mi cosano

 una di quelle basate sul concetto di "sudo"
Grazie, in effetti sono su Ubuntu. Ora ci sono riuscito e ho installato il
programma che mi serviva come root. Per forza cosi', altrimenti non
trovava le librerie che gli servivano, ed era un casino mostruoso.
Ora devo fare in modo che l'utente normale possa usare questo programma
pur non essendo root. Quindi ho tre problemi diversi:
1. far lanciare all'utente ciccio (che non e' root) uno qualsiasi dei
tanti eseguibili che si trovano in /root/programma/bin senza far precedere
ogni volta il tutto da sudo (fermo restando che ho gia' verificato che
sudo /root/programma/bin/pippo viene eseguito correttamente). Questo non
lo so fare.
2. mettere il path /root/programma/bin nel path di ciccio, in modo tale da
dover digitare solo "pippo" o il nome degli altri eseguibili. Questo
credevo di saperlo fare, perche' ho dato il comando "export
PATH=$PATH:/root/programma/bin", ma succede la seguente cosa misteriosa:
$ sudo pippo
sudo: pippo: command not found
$ sudo /root/programma/bin/pippo
pippo funziona regolarmente
3. rendere questa modifica permanente, nel senso che il path non deve
essere rispecificato dopo ogni avvio.
Mi dareste una mano?


 pippo funziona regolarmente
sei sicuro che nel path ci sia la directory dove hai installato il
programma?


Andrea B. wrote:
Quoto,tutto,e aggiungo,se non si e' un "guru" della distribuzione,per quale 
motivo pasticciare con software che al 90% e' gia' disponibile come 
pacchetto?
inoltre se anche non fosse disponibile nei repository,non vedo per quale 
motivo debba stare in /root/
se lanci,
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/lib/java/bin:/usr/lib/kde4/libexec:/usr/lib/qt/bin:/usr/share/texmf/bin:.
capisci dove dovrebbe stare l'eseguibile.
-- 
last-kernel-inside

 password mi risponde "su: Authentication failure"??
Di la verità con windows usi l'utente administrator di default eh?
--
io

 programma?
ripeto:
$ sudo /root/programma/bin/pippo
pippo funziona regolarmente
$ PATH=$PATH:/root/programma/bin
$ sudo pippo
sudo: pippo: command not found
-- 


 capisci dove dovrebbe stare l'eseguibile.
Se stesse altrove a me farebbe solo un piacere. Ma ho dovuto combattere
con librerie che non trovava e permessi che non gli piacevano, e alla fine
si e' installato li' dove e'. E posso pure usarlo. Il mio problema si
riduce a come evitare di digitare per tutta la giornata:
$ sudo /root/programmamondodisney/bin/pippo
(dare password)
pippo sta funzionando
$ sudo /root/programmamondodisney/bin/paperino
(dare password)
paperino sta funzionando
$ sudo /root/programmamondodisney/bin/pluto
(dare password)
pluto sta funzionando
e sostituire il tutto con: 
$ pippo
pippo sta funzionando 
$ paperino
paperino sta funzionando 
$ pluto
pluto sta funzionando 


 PATH=$PATH:/root/programma/bin", ma succede la seguente cosa misteriosa:
modifichi /home/tuoutente/.bashrc e aggiungi il path alla dichiarazione:
PATH=/bin:/usr/bin:...:/usr/local/tuoprogramma/bin
O, più semplicemente, se il programma l'hai installato con un ./config, 
make, make install dai sorgenti, l'eseguibile si sarà installato per 
default in /usr/local/bin, in questo caso in PATH non dovrai avere altro 
che /usr/local/bin (che forse già c'è) e ti andrà già bene per *tutti* i 
programmi che installerai in quel modo.
Ah, suggerimento: in questo caso - se non hai problemi di spazio - i 
sorgenti che hai compilato per l'installazione, *tienili* così come 
erano dopo aver fatto "make install". Di solito prevedono anche 
un'opzione "make uninstall" che ti può tornare utile per non dover dare 
la caccia a tutti i file installati un giorno che vuoi togliere quel 
programma (magari perché intanto è arrivata la versione "pacchettizzata" 
e vuoi utilizzare quella).
-- 
Massimo Bacilieri AKA Crononauta

 Di la verità con windows usi l'utente administrator di default eh?
Ti dico la verita': non lo so. Sono sicuro al 99.9% di si', ma non lo so. 
Pero' ora faccio una domanda io a te: che c'e' di tanto strano? Sono dieci
anni che faccio questo lavoro, 8 ore al giorno in rete. Sto attento ad
avere antivirus e browser aggiornato, e prendo le piccole normali
precauzioni quotidiani (tipo non aprire allegati di posta strani o non
installare tutte le schifezze che trovo). Aggiorno il sistema operativo
quando me lo chiede, di solito una volta alla settimana. Non devo mai dare
la password.
Mai un virus, mai un sistema non funzionante. In dieci anni.
Su Ubuntu sto sempre a dare la password. Se devo aggiornare (mediamente
una volta al giorno). Se devo controllare se c'e' un programma disponibile
(se c'e' il programma, non per installarlo!). L'ho appena data? Devo darla
di nuovo. Controllo un altro programma? Altra password. Sara' pure piu'
sicuro... ma... Mah!
Senza polemica, eh! Come vedi, uso Ubuntu, e faccio il tifo per Linux.



E proprio qui sta il problema
se ci dici qual è il software in questione magari ti diamo una mano a 
farlo funzionare da utente normale
Di base non si usa l'account root nei sistemi linux, non per fare 
compiti ordinari
Normalmente quando installi da sorgenti fai un ./configure seguito da 
make come utente normale
poi dai un make install come root
Questo perché l'install mette i file in posti dove solo root può scrivere
altrimenti puoi configurare con --prefix, il che fa sì che l'install ti 
piazzi i file in --prefix (di solito si usa la tua home)
M

 Per quello che serve a te c'è /usr/local.
Posso umilmente chiedere come mai questa regola cosi' ferrea? Cosa c'e' di
male ad avere un programma in /root, e poi accederci come utente? Tra
l'altro come ho fatto io e' esattamente come consigliato
nell'installazione del programma. Ed e' infatti il motivo per cui sono
*riuscito* ad installare: usando i default del programma, altrimenti mi
perdevo tra librerie che non trovava e permessi che non gli garbavano.
E poi un'altra cosa: secondo te dovrei installare in /usr/local ma fare
l'installazione come root, vero? Ho capito bene?


 piazzi i file in --prefix (di solito si usa la tua home)
Provero' a rifare secondo quanto mi dici. Pero' una domanda preliminare:
posso installare tutto in /usr/local ma facendo sia il ./configure e sia
il make come root? Cioe', intendo, so che lo *posso* fare, ma e' corretto,
oppure facciamo poi che mi dite che anche quello non va bene per qualche
motivo strano? 
In tutti i casi, non sono del tutto convinto. Ti ripeto, sto seguendo le
istruzioni del programma. E secondo me il motivo per cui le istruzioni
sono tali e' che una volta installato poi qualsiasi utente puo' *usare* il
programma dal suo specifico account. Facevo prima l'esempio su Windows
dell'installazione di Word. Su un sistema con 20 utenti e un
amministratore, immagino che l'amministratore installi Word sul suo
account e consenta di usare il programma a tutti gli utenti. Almeno credo,
no?!


 l'installazione come root, vero? Ho capito bene?
Sì. Ovviamente per *installare* in /usr/local hai bisogno dei permessi 
di root. Lì però gli utenti possono tranquillamente accedere *in 
lettura*, quindi potranno tranquillamente usare il programma senza avere 
privilegi amministrativi.


 no?!
Guarda che è concettualmente identico a quello che avviene in Windows.
I Windows il programma viene installato a disposizione di tutti gli 
utenti in c:\Programmi, poi ogni utente avrà nella sua "Application 
Data" dentro la sua cartella utente le configurazioni personalizzate 
dell'applicazione.
Qui è uguale, l'*applicativo* è comune a tutti in /usr/local e poi ogni 
utente avrà le sue configurazioni personali in $HOME/.programma (o 
semplicemente $HOME/.programmarc nei casi più semplici. Oppure se usi 
ambienti grafici dipendenti da xfdesktop, le configurazioni potrebbero 
stare in $HOME/.config).
Ah, nota che in questo caso, che è la prassi per i programmi di ambienti 
tipo Unix, nessuno ha bisogno di permessi amministrativi per eseguire il 
programma, a tutto vantaggio della sicurezza.


 sudo: pippo: command not found
da man sudo
To prevent command spoofing, sudo checks "." and "" (both denoting
current directory) last when searching for a command in the user's PATH
(if one or both are in the PATH).  Note, however, that the PATH
environment variable is further modified in Debian because of the use of
the SECURE_PATH build option.
--------^^^^^^^^^^
Io proporrei nell'ordine:
1) usa la versione che hai nei repository (si lo so che che con Windows
hai sempre l'ultima versione però ogni tanto quando installi un
programma e gli altri smettono di funzionare);
2) installa l'ultima versione nei posti giusti (ho visto che ti hanno
già dato dei consigli);
3) metti un soft link in una directory già nel path.

 bisogno di particolari privilegi.
Ok, proviamo a seguire questa strada canonica, passo per passo...
$ echo HOME
/home/ciccio
Prima domanda, dove devo installare il mio programma? In
/home/ciccio/programma, oppure in /usr/local/programma? Nota che ciccio e'
l'unico account presente su questo pc, ed e' "account type: administrator".
Nell'attesa della risposta, ecco un tipico esempio di quello che mi
succede se provo ad installare in /usr/local/programma. Per installare il
mio programma ho bisogno preliminarmente di installare openmpi. 
$ export SOFT=/usr/local/programma
$ cd openmpi-1.4.3 
$ ./configure --prefix=$SOFT && make && make install
/configure: line 2888: config.log: Permission denied
/configure: line 2898: config.log: Permission denied


 /home/ciccio
Spiacente, era in realta':
$ echo $HOME
/home/ciccio
Ma credo si fosse capito lo stesso.


 /configure: line 2898: config.log: Permission denied
Per forza. Quando arriva al make install vuole *scrivere* i file del 
programma compilato dentro /usr/local, e lì "ciccio" non ha i permessi.
E poi, openmpi-1.4.3 dove si trova? Per compilare occorre potere 
scrivere dentro la cartella, quindi deve essere in un'area dove l'utente 
ha permesso di scrittura.
Per esempio in /home/ciccio/src/openmpi-1.4.3
Detto questo, l'ordine corretto è:
$ cd openmpi-1.4.3
$ ./configure --prefix=/usr/local
$ make
$ sudo su
# make install
e vedrai che la vita ti sorriderà!
Ah, anche il ./configure e il make io li faccio sempre in due comandi 
separati, anziché concatenarli. È sempre bene guardare prima il 
risultato del ./configure, prima di lanciare un make che poi non si sa 
se è corretto.


 # make install
$ cd openmpi-1.4.3
$ echo $SOFT
/usr/local/programmadisney
$ ./configure --prefix=$SOFT
/configure: line 2888: config.log: Permission denied
/configure: line 2898: config.log: Permission denied
-- 


 si e' installato li' dove e'.
hai letto la documentazione? ad es. troveresti delle note simili:
By default, `make install' will install the package's files in
/usr/local/sbin and /usr/local/man. You can specify an installation
prefix other than `/usr/local' by giving `configure' the option
`--prefix=PATH'. Usually good installation paths are `--prefix=/usr'
and `--sbindir=/sbin'.
r
-- 
eh-ho!
[Alan Sorrenti: Come un vecchio incensiere all'alba di un villaggio deserto]
tutto sui Pentangle: 
http://umpf.net/

 root;
Scusami, non mi sono spiegato bene. A me sta bene che Synaptic mi chieda
la password per *installare* un pacchetto. Penso invece che sia ridicolo
chiedere la password per verificare la *disponibilita'* di un pacchetto.
In altri termini, la password secondo me dovrebbe essere legata alle
operazioni delicate eventualmente compiute da Synaptic. E non a Synaptic
tout-court. 


 la password per *installare* un pacchetto.
sì, avevo capito;
forse è una scelta di Ubuntu, se non ricordo male in Debian la pass è 
richiesta solo se si vuole installare/rimuovere i pacchetti;
r
-- 
spiacente, ma non scarico i msg che iniziano per R:
[firma 1.0 freeware]
Ramapage: 
http://umpf.net/

 
No. Il lancio di sinaptic richiede diritti amministrativi.
E non è sbagliato.
Tu, pezzente, non puoi sapere cosa dio root ha installato sulla
macchina che benignamente ti concede in uso. ;-)
Che dici? tu e root siete la stessa persona?
Non è che c'entra anche una colomba, in questa storia?
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 Pero' ora faccio una domanda io a te: che c'e' di tanto strano? Sono dieci
Di strano c'è che se da utente normale fai rm -rf * ti fai del danno.
Se lo fai da root, fai del danno a tutto il sistema, e linux nasce al
servizio di più utenti, l'uso desktop è solo un sottoinsieme.



Facebook: Massimo Bacilieri

 Senza polemica, eh! Come vedi, uso Ubuntu, e faccio il tifo per Linux.
e fai male (non per linux che é il kernel) fai male ad usare ubuntu, usa 
debian e ti renderai conto che é tutta un altra musica.
--
old

 digitare la password. E' una cosa ridicola.
adesso passo per tifoso debian, ma non é come dici tu.
[cut]
--
old

 adesso passo per tifoso debian, ma non é come dici tu.
allora ricordavo bene e synaptic permette di vedere i pacchetti a un 
semplice utente?
anche se penso debba appartenere a un gruppo apposito, forse root;
r
-- 
Nonchè gli Oasis facessero testi impegnati ma almeno non mi fanno venire
il vomito come i Beatles.
[Davide Ripamonti]
Ramapage: 
http://umpf.net/

 anche se penso debba appartenere a un gruppo apposito, forse root;
é una questione di permessi e punti di vista, un semplice utente avrà 
pure il diritto di "vedere" e chiedere all'amministratore del sistema di 
installare se lo ritiene opportuno un pacchetto che gli serve o siamo in 
dittatura e l'utente semplice si deve opprimere e pregare dio che gli si 
installi tale pacchetto, cosa che se non riesce neanche a vederlo non sa 
nemmeno che esiste e quindi non può neanche chiederlo supplicando 
all'amministratore del sistema.
ma come ragioni?
--
old

 ma come ragioni?
Ragiona.
Utente ha necessità e chiede a sysadmin.
Sysadmin valuta e offre a utente programma per necessità.
AUGH!


 AUGH!
scusami ma mi sembri imbecille nel senso che imbelli :-).
ragiona tu, io ho bisogno di un vestito e tu me lo compri a caxxi tuoi 
sensa sapere se a me piace o se devo andare in montagna o al mere; che 
male c'é a vedere cosa offre il repository se posso accedere ad internet 
e vederlo comunque?
bye bye!
--
old

 e vederlo comunque?
E' che tu vedi le cose, legittimamente, dalla prospettiva dell'utente
che ha il SUO computer e ci vuole fare quello che vuole.
Il male non è che si possano vedere i repository ma sta nel fatto che
synaptic è pensato per amministrare la configurazione della macchina.
Infatti in gnome c'è una applicazione apposita (il software center) per
la ricerca del software disponibile che NON richiede l'accesso
amministrativo.

 e vederlo comunque?
Che non sai cosa IO ho installato per tenerti d'occhio, pericoloso
sovversivo che non sei altro!
[*] Se io fossi un sysadmin democratico[**] potremmo discuterne: Tu
mi dici cosa devi fare, io ti propongo alcune soluzioni, tu mi dici
se di queste ne conosci qualcuna e io ti fornisco volentieri quella
che conosci già, sarai più produttivo!
[**] Ossimoro, credo si dica, in italiano.



http://imagebank.ipcmedia.com/imageBank/s/shaved%20cat.jpg
Già, il povero gatto c'ha proprio l'espressione di uno che dice "mi hai
reso ridicolo, ma quando finiranno di ricucirti sarò già tornato quello 
di prima!" :D

 Se io sono il sysadmin, la macchina è MIA e ne son RESPONSABILE IO.
Questa me la dovrei stampare ed attaccare in ufficio...
Enrico

 LOL, pensavo ti fossi rincoglionito tutto assieme :D
Impossibile,non si smette mai di essere admin dentro :-)
-- 
last-kernel-inside

 Questa me la dovrei stampare ed attaccare in ufficio...
Ci mettiamo poi d'accordo sui diritti di edizione.
ACH! siamo su icoli, mi toccherà di rilasciarla in GPL.
Ok, qui il sorgente:
#include <stdio.h>
  int main()
  {
         printf("Se io sono il sysadmin, la macchina è MIA ");
         printf("e ne son RESPONSABILE IO.");
         return 0;
  }
The software is released as is, no warranty and no liability ....


 LOL, pensavo ti fossi rincoglionito tutto assieme :D
No, poco alla volta, rassicurati. :-P
Adesso, cerchiamo di fare un discorso serio.(il "tu" è generico, lo
so che tu lo sai)
Il sysadmin di solito è bastardo dentro, fuori e anche per un metro
e mezzo tutt'intorno (alcuni arrivano anche a tre metri) ma di rado
è scemo, e se può ti farà usare un programma che conosci, così sarà
più facile che tu sia produttivo da subito.
Ma di solito ha una visione globale del problema, non è sempre solo
per divertirsi che mette dei paletti agli utenti.
Il sysadmin sa quanto gli costa gestire una accozzaglia di software
sparso per le sue decine/centinaia di macchine, ad esempio.
Sa di cosa ha licenze in abbondanza e di cosa no.
Sa un mucchio di altre cose sull'infrastruttura che, di solito, gli
utenti ignorano, e che potrebbero avere un peso rilevante anche nel
dare la preferenza ad un software piuttosto che ad un altro.
Se preferite, sostituite "dovrebbe sapere" a "sa".


 [**] Ossimoro, credo si dica, in italiano.
non so io sono oriundo
--
old

 imputare ad altri quello che siete/fate voi.
Non c'è nulla da scoprire.
Gli utenti di un sistema informatico debbono dividersi in categorie.
Le categorie sono funzionali alle mansioni, e prevedono diritti diversi
sia per fare che per vedere.
Come dicevo prima, questa è teoria.
Quando io sono sysadmin di me stesso, oltre a mettermi i bastoni tra le
ruote, mi imbroglio assegnandomi diritti e facilitazioni.
[*] "sudo e i sudoers" mi sembra il nome di un gruppo musicale anni 70.


 sia per fare che per vedere.
appunto dicevo
--
old