dato che mi sono scontrato con il problema di dover far andare ssmtp con gmail e che google mi ha proposto configurazioni non funzionanti, vi posto quella che a me funziona:

/etc/ssmtp/ssmtp.conf:
root=tuo_username@gmail.com # altrimenti inviando mail da root il mittente e' "root"
mailhub=smtp.gmail.com:465 # o :587
UseTLS=YES
AuthUser=tuo_username # senza @gmail.com
AuthPass=tua_password
FromLineOverride=YES # per settare correttamente il subject

io sto utilizzando questa configurazione per una webapp che invia in automatico delle mail

ieri dopo un’ora di tentativi di fare un bridge dell’adapter vmware e della mia scheda di rete, ho trovato su google che nelle famose patch any-any-update di cui vi dicevo l’altra volta il bridge su interfacce wireless non e’ supportato:

But vmware-any-any-update patchs do not support bridge networking with wireless network cards. It can be read in the source of module vmnet.tar, smac_linux.x386.c:

KERN_WARNING vmnet: You are trying to use wireless networking bridged together with vmware-any-any-update. This configuration is not supported, and your wireless bridge will probably not work

After investigating a bit, the problem is this function is only supported in vmnet.tar module that comes with the original vmware, which includes precompiled binaries smac_linux.x386.o_shipped and smac_linux.x86_64.o_shipped which support this function. But the original modules are not worth because they do not compile in the kernel 2.6.24

La “soluzione” proposta dalla stessa pagina che ho trovato googlando consiste nel prendere pezzi di vmnet originale e schiaffarci dentro pezzi di any-any-update-115 per generare un micro mostro che pare funzioni; io non l’ho provato, dubito che il micro mostro funzioni sul kernel 2.6.26 (dato che e’ basato sulle patch 115 e a me servivano le 117d)

Nell’attesa che cambi qualcosa (magari con l’uscita di ws 6.5), rimane funzionante il bridge con le ethernet

per chi non riuscisse piu’ a far andare vmware col kernel 2.6.26, ci sono delle patch che permettono di far compilare correttamente i moduli… ecco come fare:

• procuratevi il file vmware-any-any-update117d.tar.gz da http://groups.google.com/group/vmkernelnewbies/files
• scompattate il tar.gz di vmware dove vi pare
• prendete i file vmmon.tar, vmblock.tar, vmnet.tar da vmware-any-any-update e copiateli in vmware-distrib/lib/modules/source
• fate l’installazione di vmware

a me questa procedura ha funzionato, ricordo di togliere altre eventuali patch messe magari dalla vostra distribuzione

mi sono gia’ piu’ volte lamentato della mentalita’ di certi sviluppatori che amano troppo stravolgere tutto quanto fatto in precedenza

si, mi riferisco di nuovo ad archlinux e al nuovo pacman 3.1

1. non si riesce piu’ a lavorare sui pacchetti solo da root. pazzesco. pacman lavora ancora abbastanza bene da root, makepkg invece e’ ora solo per gli utenti a meno di forzarne l’uso da root con uno switch da riga di comando. a me sfugge il discorso sicurezza se il mio utente e’ in sudoers…
2. abs non e’ piu’ incluso — va installato come pacchetto a parte
3. i mirror sono stati riuniti in un’unica lista — altro lavoro di vim per sistemare pacman.conf
4. il db di pacman e’ stato spostato — utile eh

ora pero’ installando roba mi sono imbattuto in una problematica che affligge tutti gli utenti, tanto che e’ stato aperto un bug che spiega tutto… e a parte la solita scusa degli sviluppatori “This is not a bug, this is a feature” possiamo leggere la cosa che piu’ mi sconcerta di tutto cio’:

Some background: we cannot modify packages to the new provision scheme until users don’t change to the new pacman (i.e. it appears in core).

dunque: fate una nuova versione del programma, abbastanza incompatibile con la struttura del resto (parlo specialmente di AUR), non dite niente a nessuno perche’ per fare le modifiche dovete comunque aspettare che il pacchetto sia marcato “stabile”. e chi usa testing? deve tenersi una roba mezza incompatibile? deve ricordarsi di editare a manina tutti i pacchetti in modo da renderli usufruibili dal nuovo pacman?

e quando verra’ passato in core, tutto sto casino tocchera’ a quelli che non usano testing ovviamente, che si ritrovano a dover fare tutti sti passaggi… mah

perche’ invece esce una versione nuova di portage alla settimana e l’utente non deve fare mai niente?

ho installato compiz-fusion 0.6.0 su kde 3.5.8, e mi sono trovato davanti a qualche problema, risolti in gran parte con l’aiuto di forum vari… passo quindi in rassegna i problemi e le soluzioni, sperando che possano essere utili a qualcuno

• superkaramba — se come me avete un widget di superkaramba sul desktop vi sarete accorti che questo non viene moltiplicato sui desktop virtuali (le facce del cubo); per risolvere questo, andate sul ccsm, attivate il plugin regole finestre (categoria gestione finestre) e sul campo Adesive scrivete class=Superkaramba & type=dock et voila’, ora il widget comparira’ su tutti i desktop virtuali
• ALT+F2 non funziona — sempre dal ccsm, su opzioni generali, campo commands, nella riga di comando 0 scrivete dcop kdesktop KDesktopIface popupExecuteCommand e da key bindings, esegui comando 0 associatelo ad alt+f2. attenzione: probabilmente verrete avvertiti di un possibile conflitto, selezionate pure disattiva esegui finestra di dialogo esegui applicazione che tanto non sembra funzionare

ed ora la cosa forse piu’ importante: come avviare compiz-fusion e fusion-icon al login in automatico.

da root eseguite quanto segue:

echo "fusion-icon" > /usr/bin/compiz-fusion
chmod +x /usr/bin/compiz-fusion

poi create il seguente file: /opt/kde/env/start_dbus_session.sh

# test for an existing bus daemon, just to be safe
if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
# if not found, launch a new one
eval `dbus-launch --sh-syntax --exit-with-session`
fi

create poi il seguente file nella home del vostro utente: ~/.kde/Autostart/fusion-icon-tray.desktop

[Desktop Entry]
Encoding=UTF-8
Exec=fusion-icon-tray
StartupNotify=false
Terminal=false
Type=Application
X-KDE-autostart-after=kdesktop

a questo punto non rimane che settare l’ambiente per usare compiz come window-manager:

echo "export KDEWM=compiz-fusion" >> ~/.bashrc

ora quando effettuate il login, dovrebbe partire l’icona di fusion nel tray e compiz-fusion come decoratore delle finestre… potete divertirvi coi temi e coi plugin!

Venerdi non avevo proprio un cazzo da fare e da bravo cazzone che si cerca i guai, con le mie manine piene di dita mi sono detto: “per dindirina aggiorniamo il wordpress del sito www.xxx.yyy, ci saranno tanti fix e bug risolti nella nuova release!!”.
Daphiel sei un coglione, esci e vai a drogarti non aggiornare mai più wordpress!

Ora vi spiego cosè successo, anche se mi sto offendendo non è stata colpa mia, sia ben chiaro sto postando questa cosa per i poveracci che si imbatteranno in questa situazione.

Scenario: Hosting Aruba (non dite niente…), piattaforma Wordpress, supporto PHP et simili, MySQL.
Uppo il mio nuovo wp, seguo le istruzioni, cancello i files che mi dice l’howto ufficiale, punto alla pagina upgrade.php…e…

500 Internal Server Error

Perbacco mi dico, qualcosa è andato storto, punto all’index.php e ancora…

500 Internal Server Error

uhm… faccio un po’ di prove, ricontrollo i files… niente.

Nel panico più totale decido di fare rollback alla versione di prima, uppo tutto, sistemo le dir e i files…e…

500 Internal Server Error

PERCHE’??! cerco su internet… compaiono post confusi alcuni dicono mod_rewrite, altri .htaccess altri ancora i permessi. Chiedo ad amici, niente, SQL è integro (fiuuu…).

Mi viene una curiosità, dopo aver letto un post dove un ragazzo aveva il mio stesso problema con la stessa situazione e il medesimo Aruba… e dove lo stesso scrive “Risolto, Aruba vuole 755″ mi metto in moto e comincio a controllare tutte le dir e TAC, la dir Avatars ha dei permessi che non sono 755. Provo con il link fornito da Aruba nel pannello per resettare i permessi, niente, provo a manella con lftp…niente… provo a cancellare, rinominare, fuckkare…niente!!!! (l’esaurimento è vicino)

Apro un ticket disperato descrivendo la situazione, stamattina (lunedi) le cose sono tornate a posto, e la dir avatar ha i permessi 755. In bocca al lupo amici, preghiamo.

:: pacman ha rilevato una versione più recente di “pacman”.
:: Si consiglia di consentire a pacman di aggiornarsi
:: prima e poi riavviare l’operazione con la versione più recente.
::
:: Aggiornare pacman adesso? [Y/n]
risoluzione delle dipendenze in corso… fatto.
ricerca dei conflitti incrociati in corso… fatto

Pacchetti: pacman-3.0.6-1

Dimensione totale dei pacchetti: 0,85 MB

Procedere con l’installazione? [Y/n]
:: Recupero dei pacchetti da current…
pacman 872,0K 67,7K/s 00:00:13 [#####################] 100%
controllo dell’integrità dei pacchetti in corso… fatto.
pulizia in corso… fatto.
(1/1) controllo dei conflitti in corso [#####################] 100%
(1/1) aggiornamento in corso di pacman [#####################] 100%
>>> VERY IMPORTANT <<<
>>> We have changed our repo layout:

>>> The current repo is gone and has been replaced by the new core repo.

>>> IT IS IMPORTANT TO CHANGE THE ENTRIES FOR THE CURRENT REPO TO CORE REPO
>>> IN YOUR /etc/pacman.conf to keep on getting updates. This is also
>>> important to satisfy dependencies of new packages in the extra repo.

io DAVVERO non capisco l’utilita’ di cambiare nome a un repository.

il linux e’ strano.

installi un linux, crea tutti i suoi bei device, eth0 la scheda di rete ethernet eth1 la firewire eth2 la wireless ok che bello sistemiamo tutti i file di configurazione per la wireless…

aggiorni il kernel, tutto tranquillo. continui ad aggiornare kernel (col passare dei mesi), tutto tranquillo.

aggiorni da 2.6.21 a 2.6.22, la morte: eth2 diventa eth1. cosi’. a caso. non so perche’.

PS: non e’ un grosso problema, si risolve in 3 minuti netti, ma non capisco perche’ i numeri debbano cambiare cosi’, sua sponte

…evidentemente chi fa il LiveCD e’ un tipo poco sveglio:

evviva OpenSUSE! evviva KIWI!