Come impostare proprietà dell’utente (come lo wysiwyg editor) da bash script

Ecco un semplice script da lanciare da bash per impostare velocemente delle proprietà utente, come ad esempio il Wysiwyg editor, per tutti gli utenti, in caso di migrazione a plone4.

• senza external method
• senza ZMI
• senza blueprint
• senza browser view
• senza particolari permessi (manager o altro)

Create un file nella root del vostro buildout, ad esempio “setDefaultEditor.py” e popolatelo con il seguente codice:

from zope.app.component.hooks import setSite
from transaction import commit

portal=app.MyPlone
setSite(portal)

pm = portal.portal_membership

for memberId in pm.listMemberIds():
   member = pm.getMemberById(memberId)
   editor = member.getProperty('wysiwyg_editor', None)
   if editor == 'TinyMCE':
       print('%s: TinyMCE already selected, leaving alone' % memberId)
   else:
       member.setMemberProperties({'wysiwyg_editor': 'TinyMCE'})
       print('%s: TinyMCE has been set' % memberId)

commit()
app._p_jar.sync()

Dopodichè semplicemente lanciare a shell:

$ bin/instance run setDefaultEditor.py

Questo è tutto. Efficace e veloce.

libmysqlclient.18.dylib + mysql + plone + macosx

Su MacOs X una volta installato MySQL e messo su il vostro bel buildout è possibile che Plone fallisca a causa di un errore di questo tipo:

ImportError: dlopen(/Users/.../MySQL_python-1.2.3-py2.6-macosx-10.6-x86_64.egg/_mysql.so, 2): Library not loaded: libmysqlclient.18.dylib
 Referenced from: /Users/.../MySQL_python-1.2.3-py2.6-macosx-10.6-x86_64.egg/_mysql.so

 

E’ un problema di variabili d’ambiente legate alle librerie MySQL su Mac Os.

Per ovviare basta inserire nel buildout.cfg:

[instance]
..
zope-conf-additional=
  <environment>
  DYLD_LIBRARY_PATH /usr/local/mysql/lib/
  </environment>

 

Naturalmente questo percorso funziona se avete installato il MySQL lasciando intatti i parametri al momento del setup.

Vito

Diazo come standalone server: skin da urlo per Plone 2 e 3

Arrivo subito al dunque: un committente con un portale Plone 3.3 pienamente funzionante vuole una nuova skin complessa senza toccare la logica del portale (alias “non vuole spendere assai” -.-). Un plonista contemporaneo pensa subito alla soluzione: Diazo!
Diazo funziona alla grande in accoppiata con plone.app.theming però… questo pacchetto è compatibile con Plone 4.1!

Quali potrebbero essere le strade da intraprendere:

• utilizzare XDV e collective.xdv

• pro: pienamente compatibile e configurabile l’integrazione plone con xdv (tramite appunto il collective.xdv)
• contro: xdv non è più supportato e sviluppato, offre meno potenzialità rispetto a Diazo

utilizzare e cablare Diazo per Plone 3:

• pro: si potrebbe cablare l’integrazione plone-diazo con collective.xdv
• contro: collective.xdv è stato scritto per XDV quindi bisognerebbe forkare il pacchetto e ottimizzarlo per Diazo. Cui prodest?

migrare il portale a Plone 4.1

• pro: utilizzo di plone.app.theming (il successore di collective.xdv) per ottenere perfetta integrazione Diazo-plone
• contro: vuoi proprio fare una migrazione tra major releases gratis??

Problemi con PIL (su linux o mac) quando installi il Plone?

Nessun problema, finalmente un fork funzionante

http://pypi.python.org/pypi/Pillow/1.7.5

La soluzione si chiama Pllow! E’ un egg come gli altri, da inserire nel buildout.cfg, ma risolve un po’ di sbattimento con libjpeg, zlib e compagnia.

Supervisor recipe per pound, varnish, zeo cluster e Plone 4.0.5

Questa mattina ho configurato il mio buildout arricchendolo della recipe di supervisore (collective.recipe.supervisor), un ottimo strumento per avere il nostro cluster di produzione sotto controllo.

Mi sono tuttavia imbattuto in una serie di problemi dovuti probabilmente alla documentazione di questa ricetta non ancora aggiornata su pypi.

Ecco come ho risolto…

LinguaPlone4 e Plone4: che bella novità :)

Finalmente trovo il tempo di scrivere qualche nuova riga sul blog.

In questi giorni, dopo un annetto di “astinenza” da siti multilingua, ho dovuto cimentarmi nella realizzazione di un nuovo sito bilingue.
“Ottima occasione per testare il nuovo Plone4 con LinguaPlone” mi son detto…

Ebbene, ho scoperto che anche LinguaPlone è arrivato alla release numero quattro e con un bella novità (della quale ero all’oscuro).

Plone 4.0.2 buildout

Questa mattina ho creato exnovo un buildout per l’appena rilasciato Plone 4.0.2.

con sorpresa ho avuto questo errore:

Getting distribution for 'Plone==4.0.2'.
While:
Installing instance.
Getting distribution for 'Plone==4.0.2'.
Error: Couldn't find a distribution for 'Plone==4.0.2'.

Nella sezione find-links del buildout.cfg leggo
find-links =

http://dist.plone.org/release/4.0.2

Puntando il browser tale indirizzo indirizzo vengo rediretto allo stesso server su una porta diversa dalla 80.
Ho quindi ipotizzato di avere problemi col proxy (essendo la mia rete aziendale filtrata da un proxy)

Ho notato che lo stesso link seguito da un ultimo ‘/’ rimane sulla porta 80 mostrando correttamente tutto il contenuto di release.

Quindi ho sostituito la linea find-links con:
find-links =

http://dist.plone.org/release/4.0.2/

Risolto il problema

Il buildout scarica/compila/runna tutto correttamente.

Enjoy la vostra fiammante Plone 4.0.2.

Plone4 e WingIDE

Tempo fa ho provato ad utilizzare l’IDE WingIDE per scrivere e debuggare i miei prodotti plone e devo dire che mi sono trovato abbastanza bene.

E’ un buon editor e cosa piu’ importante, ti permette di settare al volo breakpoint nel tuo codice per interrogare variabili o iniettare codice a runtime.

Con l’avvento di Plone4 (in realta’ per “colpa” di Zope2.12) sono sorti dei problemi di compatibilita’ per cui il wing debugger non si avviava o se si avviava andava in errore gia’ in fase di configurazione.

Questo fino ad oggi, quando ho trovato l’articolo di encolpe a questa pagina. Vediamo di cosa si stratta.

Problemi di sincronizzazione Zeo Client (frontend e backend)

Ingredienti:

1. ZEO client sparsi su macchine diverse
2. Cache-Fu
3. reverse proxy (squid/varnish/ecc)
4. 2 domini d’accesso (front e backend) in bilanciamento su diversi ragruppamenti di zeoclient
5. Aggiornamento di un oggetto magari vista predefinita di un folder o che debba comparire come risultato di una collezione.

Risultato:

1. Pagine aggiornate su un dominio
2. pagine obsolete sull’altro
3. apparentemente nessuna manovra risolve la situaizone tra cui:

• modifica ulteriore della pagina;
• del suo contenitore;
• aggiornamento del catalogo;
• dello stato dell’oggetto;
• di purging del proxy cache;
• di manomissione delle politiche di cache-fu;
• riavvio degli zeoclient che presentano info obsolete.

Possibile SOLUZIONE (triviale ma maledettamente subdola):

- Controllare e sincronizzare le DATE DEI SERVER su cui poggiano gli zeoclient. Nel mio caso quelli che presentavano info obsolete avevano un time arretrato di poco piu’ di un’ora.

- Se i server sono in reti che sottostanno a politiche di sicurezza particolarmente restrittive, il protocollo NTP di sincronizzazione con i time server online potrebbe non funzionare… da cio’ il resto.

Viaggio per nuovi orizzonti: Relstorage (aggiornato al 04-06-2010)

“Cari Paolo, Manuela e Uan: io ho un problema…”

Cosi’ si aprivano pressoche’ tutte le letterine che ciascun bambino inviava a Bim Bum Bam, la trasmissione per bambini piu’ seguita degli anni ’80: e chi se la dimentica! Potessi scrivere loro una letterina io ora, potrei continuare e chiedere loro:

“…ma perche’ un’istanza zeoserver con tre zeoclient presenta conflict errors anche su un server bi processore xeon 2.4Ghz con 4 GiB di memoria ram e HDD ultra wide scsi in raid 0+1, con appena 10 utenze concorrenti in scrittura??”

La loro risposta, sono sicuro, sarebbe o “bambino, fatti esorcizzare da uno bravo” oppure “hai provato con RelStorage”?

Eccomi qui, allora a tentare questo nuovo viaggio tecnologico: l’esorcism….. ehm Relstorage.

Leggo un po’ di documentazione ingiro, googolando, e trovo questo e quest’altro articolo. Sono introduttivi e mi fanno ben sperare. Sembra tutto oramai alla portata di chiunque: 4-5 righe di buildout, un easy_install e via…

Installo postgresql8.4 (server e dev) da pacchetti della mia distro preferita Sabayon!!

Installo psycopg2 nel python2.4: non mi viene mai funzionante da easy_install, cosi’ scarico i buoni vecchi sorgenti che si compilano/installano lisci lisci.

Modifico il buildout.cfg aggiungendo “relstorage” agli eggs e la sezione rel-storage nella [instance] contenente i parametri di connessione e via… funzionera?

$ bin/buildout -nvv …. bin/instance fg….

Manco per li broccoli! Argh! sembrava tutto troppo bello.

Zope si e’ avviato, mi ha chiesto il login per la ZMI come sempre ma il frame principale riporta:

Site Error

An error was encountered while publishing this resource.

Error Type: AttributeError
Error Value: ‘module’ object has no attribute ‘VersionBase’

---

Troubleshooting Suggestions

• The URL may be incorrect.
• The parameters passed to this resource may be incorrect.
• A resource that this resource relies on may be encountering an error.

e “stuff like that… bla bla bla” (cfr. qualcuno)

Gli altri frame, come il menu’, invece sembrano funzionare correttamente. Cosi’ navigo nel Control_panel/database/main… Altro errore:

Il verbose security riporta, nel caso tenti di aprire Control_Panel/database/main/manage_workspace:

[...]user_roles=getUserRolesInContext(context.user, value))

File "/home/sauzher/buildouts/plone3/parts/zope2/lib/python/AccessControl/ImplPython.py", line 808, in raiseVerbose

raise Unauthorized(text)

Unauthorized: Your user account does not have the required permission.  Access to 'title_or_id' of (DatabaseChooser at /Control_Panel/Database) denied. Your user account, Anonymous User, exists at (unknown). Access requires one of the following roles: ['Manager']. Your roles in this context are ['Anonymous'].

user_roles=getUserRolesInContext(context.user, value))  File "/home/sauzher/buildouts/plone3/parts/zope2/lib/python/AccessControl/ImplPython.py", line 808, in raiseVerbose    raise Unauthorized(text)Unauthorized: Your user account does not have the required permission.  Access to 'title_or_id' of (DatabaseChooser at /Control_Panel/Database) denied. Your user account, Anonymous User, exists at (unknown). Access requires one of the following roles: ['Manager']. Your roles in this context are ['Anonymous'].

—-

Brutto affare.

Facciamo un passo indietro.

Controllo su postgresql e le tabelle sono state inizializzate quindi deduco che il problema non e’ su postgres.

Googolo l’errore e raggiungo questa pagina: http://packages.willowrise.org/ . In effetti, in uno dei due articoli precedenti veniva impostato questo sito tra le risorse find-links nel buildout. Questa risorsa propone qualche versione dello ZODB3 in qualche modo adattata a seconda delle esigenze… si parla proprio di relstorage.

Faccio anche caso che:

1. non sto utilizzando plone4 con lo zope2.12 bensi’ plone3.3.5 con la sua dipendenza da zope2.10
2. ho dimenticato alla grande di pinnare la versione dello ZODB3 nel mio buildout.cfg. In questo modo buildout ha scaricato l’ultima versione dello ZODB3 e potrebbe non essere il caso dato il punto precedente.

Pinno quindi secondo l’articolo del buon miziodel lo ZODB3:

[versions]
ZODB3 = 3.8.1-polling-serial

$bin/buildout -nvv … sacricamento… compilazione… ready!

$bin/instance fg … eeeee kaboom! un altro errore. Un bel traceback che si conclude con:

 File "/home/sauzher/buildouts/plone3/eggs/ZODB3-3.8.1_polling_serial-py2.4-linux-i686.egg/ZODB/blob.py", line 41, in ?
    from zope.proxy.decorator import SpecificationDecoratorBase
ImportError: No module named decorator

Non mi demoralizzo… penso di essere sulla buona strada (chissa’ perche’).

Torno su http://packages.willowrise.org/. Ci sono tante versioni dello ZODB3 alcune piu’ nuove, altre piu’ vecchie rispetto alla 3.8.1-polling-serial… beh vuoi che una non faccia al caso mio?

Risultato: le 3.8.4, 3.8.3, 3.8.1-polling e polling-serial mi hanno dato tutte lo stesso errore di decorator; la 3.7.3 invece e’ OK!

[versions]
ZODB3 = 3.7.3-polling

$bin/buildout… $bin/instance fg…. ed ho il mio nuovo plone3.3.5 su relstorage con il mio bel fidato postgres che si popola di contenuti… creo un plonesite… creo oggetti. Tutto sembra funzionare.

Aggiornamento al 04.06.2010

Risolto il problema delle versioni di ZODB. E’ necessario (con Plone3.3.5 lo ricordo) pinnare anche lo zope.proxy.
La sezione Versions a questo punto risulta come segue:

[versions]
ZODB3 = 3.8.4-polling
zope.proxy = 3.6.0

??Interrogativi??

A questo punto mi domando: Puo’ essere utile separare il Catalog come si faceva col Filestorage? Non sembra ci sia nulla di simile in rete. Probabilmente con relstorage, viene meno la motivazione di separare il catalog su sito a medio-alto traffico… indaghero’.

Appena possibile provero’ a lanciare qualche benchmark con funkload e, cosa piu’ importante, tentero’ la migrazione dei contenuti del portalone di cui mi occupo (4Gib di Data.fs e Catalogo separato) O_o

L’altro interrogativo di fine giornata e’: perche’ le versioni piu’ nuove di ZODB3 non funzionano? Non sara’ che vale il vecchio rimbrotto “Newer is not always better!”. Sinceramente non credo. Probabilmente ci sara’ da pinnare qualche altro egg di zope per far si’ che le cose non scoppino e rimangano compatibili tra loro… vai a scoprire cosa pero’! I commenti sono ben accetti

Come andra’ a finire? stay tuned!