[RISOLTO]Devo dare i permessi di scrittura a tutte le cartelle?

[ritz2]

L'unico problema è che non posso entrare come admin,

Anzi secondo me sto dentro, per esempio se sulla barra una volta fatto il login scrivo: miosito/administrator/index.php?option=com_messages, (o altro indirizzo administrator) si sposta di pagina senza dare l'errore di pagina non trovata, ma vedo sempre la pagina di login, che stranezza 
Anche perché vorrei sistemare dei componenti che non funzionano e prendere pratica prima di spostarmi su un host/professional.

[ritz2]

Risolto, il problema risiede nel configuration.php, ho trovato in rete un conf.php standard ho messo i miei dati, chiuso con un editor di testo più tecnico et voilà ha iniziato a funzionare.

[frascan]

Comunque, senza permessi di scrittura, non riesci neanche ad aggiungere un articolo a joomla

credo di capire lo spirito di questa tua affermazione che è un'iperbole stilisticamente parlando, però ti inviterei a tenere presente che in rete, ed il forum di joomla.it non fa eccezione, non si è tutti allo stesso livello di competenze e conoscenze quindi è meglio evitare affermazioni che possano generare confusione nelle persone meno esperte.

come certamente sai gli articoli di joomla vengono salvati nel database mysql su cui si appoggia e non c'entrano i permessi su files e cartelle in questo caso specifico.

giusto per dovere di chiarezza e per evitare confusione.

[santograz]

Una piccola (ed ultima) precisazione:

Quando, nel corso di questa discussione, ho parlato di "cambiare i permessi alle cartelle", mi riferivo esclusivamente a quelle cartelle indicate dal manuale d'installazione di Joomla ed evidenziate dal test in info->permessi cartelle.

[frascan]

Quando, nel corso di questa discussione, ho parlato di "cambiare i permessi alle cartelle", mi riferivo esclusivamente a quelle cartelle indicate dal manuale d'installazione di Joomla ed evidenziate dal test in info->permessi cartelle.

e questo è verissimo infatti e nessuno dice il contrario
la divergenza di opinioni è sul chmod da dare a files e cartelle 775 piuttosto che 777.
ma questo non per polemica o altro ma per il fatto che tu sai come muoverti e sai cosa implica dare un chmod 777 ma persone meno esperte possono fare grossi danni modificando a casaccio i permessi su files e cartelle; soprattutto in ambienti di hosting condiviso.
ci si preoccupa tanto di risolvere possibili bug di sicurezza negli scripts per poi mettere a repentaglio il tutto con un chmod troppo permissivo. questa la mia preoccupazione e questa è la motivazione che mi ha spinto a fare le mie precisazione.
e poi il confronto di idee è il sale della vita e non può che farci crescere ed imparare tutti insieme.
un saluto

[santograz]

Questo post diventerà un best seller!

Io non so "per dove" sei passato tu
Personalmente (ed in questo momento sto lavorando con almeno 6 provider, anche grossi, oltre che con 2 server dedicati) non ho veramente mai trovato un provider che faccia girare apache (e quindi gli script PHP) sotto lo stesso gruppo di tutti gli user. Di conseguenza, ormai, sono rassegnato a quel 777 che, per la mia esperienza, è diventato inevitabile.

Quanto al caso (755) in cui tutti gli user e lo stesso apache si chiamano "pippo", mi sembra fantascientifico, se non in locale. Questo non mi è piaciuto dell'articolo citato che tratta la configurazione user/apache sotto lo stesso UID come "Una configurazione tipica".

[mmleoni]

visto che sono continuamente tirato in ballo:

http://httpd.apache.org/docs/2.0/suexec.html

configurazione tipica negli hosting condivisi. oltre a suexec, che è universalmente conosciuto tra i sistemisti, esistono altre alternative per fare ciò che scrivevo, del resto su linux un processo può essere fatto girare con qualsiasi uid:gid. ma l'articolo non poteva essere una guida alla configurazione di un server.

chi si rivolge a questo forum in cerca di aiuto non è certo un sistemista e bisogna stare sempre attenti a dare consigli, soprattutto se non si è proprio ferratissimi.

io non ho dovuto mai modificare i permessi, se non per restringerli con nessuno dei provider con cui lavoro, forse sono fortunato, forse so come funziona una macchina.

e speriamo che l'argomento sia chiuso.
marco

[monica3]

Eh eh,
succede anche a me: il dito (sulla tastiera) è più veloce del cervello

lo hai detto proprio tu e ultimamente mi sembra si verifichi sempre più spesso.

monica

[mmleoni]

speravo lasciaste cadere la vicenda nel dimenticatoio, ma vedo che così non è.

http://help.joomla.org/content/view/40/132/
questa è una guida all'installazione di joomla 1.0 ed illustra l'istallazione base di un sistema, con un solo sito ed un solo utente, il cui ultimo aggiornamento risale a marzo 2007... chissà di quando è la prima stesura; configurare un server attuale con una guida di anni fa è un po' come voler attraversare roma con lo stradario di giulio cesare.

comunque vorrei far notare che qui è stato consigliato proprio il metodo sconsigliato dall'articolo. la prima impostazione, ovvero quella consigliata, anche se al contrario, ovvero facendo girare php come fosse l'utente, è quella adottata dalla pressoché totalità dei providers italiani e della vecchia europa.

comunque questo articolo dice di cambiare i permessi a 707, ovvero azzerare i permessi del gruppo.

http://www.netadmintools.com/art560.html
questo dice di cambiare il gruppo cui appartengono i files e di impostarlo a quello cui appartiene apache, dopo di che di dare i permessi di scrittura al gruppo.
esattamente il contrario di ciò che dice il precedente.

in ambo i casi vi è da chiedersi chi è l'utente alle prime armi che fa un ssh sul server.

ciò che va tenuto presente è che entrambi i testi sono corretti perché presuppongono la conoscenza di utente e gruppo: in difetto di tale informazione parlare di permessi non ha senso, ma serve solo a rendere insicuro il server.

in joomla 1.5 infatti la gestione dei permessi è stata eliminata dall'amministrazione e sostituita dal layer ftp in quanto:
Using the FTP Layer eliminates the need to make directories and files writable and thus improves overall security of the installation and server.


e speriamo di non doverci tornare, basta PM per cortesia.
marco