We all know how good is Plone for building complex sites in an intuitive way. Perhaps not everyone knows that upgrading it can be a real nightmare… like a lot of software packages out there, but with the added complexity of the underlying world of Zope/Python/related libraries.
I have a web site build with Plone 2.0.5 that runs well, but I decided to upgrade my openSUSE from 10.1 to 10.2; to make a long story short, I hoped to upgrade to Plone 2.5.x, but I have no time to study how to do it, so I decided to run Plone 2.0.5. I downloaded Python 2.3.6 and Zope 2.7.9 and compiled it, then I run my old Plone instance with only small modifications to conf file and run scripts.
Recently I stumbled upon an apparently unsolvable network problem (at least unsolvable for me, I’m not an expert in “very very low level” networking) and the solution involved the creation of a vlan on my SuSE 10.1 server. The problem was very simple: I wanted my Grandstream HandyTone 286/386 to log to syslog on my server. I configured the devices (simply I put my server address in the correct field and choose the log level) but nothing appeared on syslog. After some unsuccessful Internet research (where I found that probably it was a bug of the devices), I noted that another strange thing was that the devices were pingable from my Windows box but not from my Linux and Mac OS X boxes.
So I ran Ethereal and observed that the devices’ log packets were there and contained an “802.1q” layer with a “0” (zero) label which is the ID of the vlan. So I researched again and found the Linux 802.1q VLAN package and, after some tweaking, I was up and running with the devices’ logging and pinging: then the mysterious network problem was due to the fact that the devices use always the vlan and there isn’t a way to tell them not to use it.
After a restart of my server, the vlan was not working again because the server “forgot” the vlan configuration because it was not permanent. Then I discovered that on SuSE you have a very simple way to create and make permanent a vlan configuration. For the explanation, type
follow the instruction and you’re done. If you want, here follows the simple steps:
Save and than you can issue a ifup vlan0 command to bring up the interface and also an ifconfig if you want to see it working.
Note that the 0 (zero) in the file name is the ID of the vlan; in ETHERDEVICE put the name of the interface of the network where the vlan is (usually eth0); the IP address is not so important if you don’t have another IP network (i.e. the 192.168.2.x is not directly useful on my network) but it permits to the server to be seen on the vlan, either with its original IP or with the new one.
In a previous post, I asked a question about the future of Venkman.
There seem to be no official response yet, so I did a simple search: I’ve gone on Mozilla Module Owners page and searched for Venkman owner info. There are related maintainer, peers, newsgroups and pages.
So I looked for newsgroups: if you go on the official newsgroup, you’ll find that it is officially closed and you have to go on the new one. Here you find a message from Aleks Totic on 2006/2/14 that says that he has a patch to solves some known bugs of version .85 and bumps the version number to .87. Here you find also a link to the related bug in bugzilla (and a link to his xpi). Besides that, you can find two versions numbered .86, one by James Ross on official Mozilla Addons site and the one already known to all us by Joe.
The most interesting news are from the bug comments, where there is clearly stated that
“Venkman has been effectively unowned for months (and still is in many respects)“.
So we have a sort of an official answer to my question, but Aleks did a good work (it’s sad that he gave up at some point), James Ross and other people peered for the module, so seems that Venkman is not dead.
I’m writing an email to all people involved (to my knowledge) with Venkman also at Mozilla Foundation to ask if they know what is going with Venkman.
In my continuous quest to fight spam, I think I’ve found a simple solution to an aspect of this problem. It isn’t the definitive one, and we can consider it a variation on the theme of the captcha, even if there’s no image involved, because there must be a “human intelligence” involved in the interaction.
We know that one of the problems behind spam are mail-harvesters: servers that search for email addresses in the Internet (see Project Honey Pot). I don’t know exactly how they work, but I think that they find a web server someway (trying IPs or searching for HTTP addresses on search engines), then they start to suck every accessible page on it and search in the HTML text for acceptable email addresses. But we know that a web page can have a behaviour, too: I think it’s very difficult that mail-harvesters “run” the pages they get, because that would be very resource intensive and slow. Besides running them, they should fire all registered events and follow their consequences: definitely too much work.
That said, my idea is simple: manually encrypt your email and embed the encrypted string in the page; it will be decrypted on demand based on user action and opportunity. An example is the link with my name under “Author” in the sidebar of my blog site: when you pass on it with the mouse, an event is fired that decrypts my email and puts it in the href attribute with the mailto protocol; then you can click on it and send me an email with your email client.
It seems at least strange that a harvester can do these actions in a timely fashion.
If you want to use this trick, you can encrypt your text here , and copy the result from here directly in your page source.
Then use this code (or a similar one):
<a data="...encrypted string..."
I’ve just grabbed the beta update 126.96.36.199 of Firefox and, surprise, Venkman is disabled again. So I’ve done what someone else did here for Firefox 1.5 (thanks!): I’ve grabbed the jw2 version and changed the max version number to 1.6.
Note that I’ve not tested it throughly, so there are no garantees.
And now the most important question: what will be the future of Venkman?
[EDIT 2006/02/01] From the date of publication (on 26 january), hits on my site are more than doubled and Venkman was downloaded more than 500 times! I’m glad that my small hack helped so many people in the developer community. My only worry is that none seems to know what the future of Venkman will be: does someone know it?
I’ve just found two short articles that quickly explains how to use SSH tunnels to bypass over-security and maybe preserve your privacy: the first one is the shortest but effective, the second one is longer but explains more deeply the concepts behind the tunnels.
In questo articolo de La Stampa si parla della valenza legale per l’e-mail finalmente definita da una legge dello Stato (DPR 11 febbraio 2005, n. 68). Nell’articolo si dice che, tuttavia, la cosa si potrà toccare con mano non prima che venga definito un elenco dei “gestori del servizio” abilitati a trasmettere email certificata e l’ente preposto, il CNIPA, non lo aveva ancora fatto al momento della pubblicazione (29/12/2005). Incredibile ma vero, invece il CNIPA ha abilitato i primi gestori il 22 dicembre 2005! Mettendo un momento da parte questo attimo di incredibile efficienza ed agilità dello Stato italiano, è rilevante il fatto che da oggi è possibile mandare l’equivalente di una raccomandata con ricevuta di ritorno direttamente dal computer, più o meno come si manda una normale email, ed evitando eventualmente le Poste Italiane (cioè appoggiandosi ad altri gestori.) Inoltre, visto l’obbligo per la pubblica amministrazione di dotarsi di caselle di posta apposite, dovrebbe essere più semplice comunicare tra cittadini e PA (e forse anche meno oneroso per le nostre tasche.)
[Edit] Se avevate per caso pensato che fosse una buona idea per una nuova attività, beh, sono d’accordo con voi… se, oltre ai soldi per l’investimento tecnologico, avete almeno un milione di Euro da investire, più qualche altra decina di migliaia per l’assicurazione industriale (come indicato qui al paragrafo LA NORMATIVA DI RIFERIMENTO, punto secondo.)