We’re almost ready.
Big things are coming. Are you ready? 😉
We’re almost ready.
Big things are coming. Are you ready? 😉
Da oggi sono ufficialmente un sistemista Unix certificato BSD-A.
Congratulazioni a me stesso 😉
Ok, ci siamo spostati. Alla fine la pigrizia ha preso il sopravvento ed ho deciso di spostarmi direttamente su WordPress.com, in modo da non dovermi sbattere a mantenere aggiornato WordPress su un mio server 😉
Ora i prossimi focus sono:
Cosette semplici come sempre. Intanto tra pochi giorni parto per una settimana a Groningen!
Questo blog prossimamente si sposterà… dovesse non rispondere per qualche ora sapete perché 🙂
I’m pleased to announce the release 0.4.1 of MySQLfs. This is the first new official version after a long inactivity so please handle it with care. Furthermore this is my first release so, although I have double checked everything, yet I may have done some tremendous mistake.
These are main improvements in this version:
Please note that this is not a production-ready version (yet), but I ask you to test it wildly and please report all the issues that you may have. I’ll try to fix them.
You can download the package here: mysqlfs-0.4.1.tar (232kb).
PLEASE NOTE THAT THE DATABASE SCHEMA HAS BEEN CHANGED FROM 0.4.0 TO 0.4.1!
If your plan is to upgrade from a previous installation my suggestion is to compile the new version alongside the old one, create a new, separated FS, mount the new FS and then copying the datas from the old FS to the new one.
If you really need to do a live upgrade of an 0.4.0 database please take a look at the (unrecommended and incomplete!) upgrade script in the sql subdir.
To install mysqlfs just make sure you have installed fuse and all it’s libs, plus mysql and all his devel libraries, unpack the tar.gz and just run
make install (as root)
Then create a database with proper permissions and use the file schema.sql in the sql dir to create the database definitions.
Run mysqlfs –help to see al the available options.
You’re done. Have fun.
So, actually it was easier than I thought. Here’s a public repo for my updated MySQLfs: https://github.com/skeyby/mysqlfs
It’s a work in progress and I wrote my first C statement 10 days ago, so please be kind 😉
Contributors are welcome. As you see I cloned an already existing repository in order to have all the history imported but didn’t start from the latest commit as I found the new added function a bit confused as of now (well, maybe it’s just me who can’t really understand them…), but I plan to merge them back later as I fix the things that need more attention in my environment right now.
I already spent some talk on this previously but I wrote in Italian, so let’s do a little recap for English readers.
Just recently I became involved in a project where a cluster of machine had to replicate their datas constantly in an active-active fashion and with geographical distribution.
We checked different kinds of solutions based either on drbd or zfs or hast or coda or… Well there’s a lengthy post on this issue just a few posts before this one, so I suggest you checking that.
At the end of our comparison we found the solution that suited us best to be mysqlfs. So I started investigating on that and quickly found some issues that could be improved.
Main points were:
As I digged in the code, I found a pretty good general infrastructure but quite frankly I don’t think mysqlfs was really ever used in a production environment.
Apart from that, the project was quite young (latest official version was 0.4.0) and also pretty “static”, with it’s latest release dating back in 2009.
So, without any knowledge of C or Fuse whatsoever I took the sources of the latest “stable” release and began experimentating with it.
A few weeks has passed and I think I reached a very interesting point. Those are the goal that I reached as of now:
Next steps are…
Right now the modification I made to mysqlfs aren’t public yet, as I couldn’t really understand the status of the project on sourceforge. Furthermore it’s code base on sourceforge is not aligned to the version that was on the installer (the one I started working on), and it’s stored in svn that I don’t absolutely know how to use.
I know the latter ones aren’t big issue, but my spare time is very thin, and I definitely can’t waste time in learning svn or manually merging the “new” code that’s in the svn and that is different from the tgz I started from. If any of you is willing to do it I’ll be glad to help.
My internal git repository isn’t public yet because of laziness and because I’d like to publish something that’s at least usable and I have to fix a couple of problems before it could be defined “idiot proof”.
In the meantime if any of you is willing to try I’d be very glad to share the modified code, or if any of you is willing to contribute then I’d be twice as glad as long as we try to keep development a bit aligned.
Recently I convinced my boss in switching from Windows-based clients to Mac OS X ones. Unfortunately one of the activity we dealt with required the ability of reading P7M files, that’s files that have been digitally signed and encoded in PCKS#7 SMIME Mail.
I searched a lot but wasn’t able to find a P7M viewer for Mac OS X… With Windows Acrobat Reader itself reads the P7M, while Acrobat for Mac doesn’t…, so I started investigating.
The command line to decode a P7M file is pretty easy:
openssl smime -decrypt -in file_in.pdf.p7m -inform DER -verify -noverify -out file_out.pdf
So the deal was to allow any user to view the files without having to deal with the Terminal.
Luckily enough with a great help from my friend Marco Balestra, we quickly hacked an AppleScript Application that can be used to decrypt the P7M, launch the viewer, and then delete the temporary file.
Here you find it attached. Just Unzip it, right click on the P7M and select “Open with…”
Obviously it comes with no warranties of any kind 🙂
Ermh… I forgot the attachment, here it is: OpenP7M
Chiunque abbia lavorato per più di 10 minuti usando SSH conoscerà sicuramente SCP, il comando che permette di copiare un file tra due macchine appoggiandosi ad una sessione ssh. Il principio è semplice: si può copiare un file da un server ssh alla nostra machina locale oppure un file dalla nostra macchina locale al server. Semplice. Un esempio?
Da qui a li:
scp file.txt utente@server:/directory/
Da li a qui:
scp utente@server:/directory/file.txt .
Ciò che in pochi realizzano è che lo stesso comando può essere usato per copiare un file tra due server entrambi remoti. Il principio è semplice;
scp utente1@serverorigine:/directory/file.txt utente2@serverdestinazione:/directory/
Ciò che però la documentazione si scorda di dirvi e che, a differenza di quanto potreste aver pensato, la vostra macchina non farà da ponte (è un feature, non un bug!) bensì farà in modo che il primo server instauri una connessione diretta verso il secondo per copiare il file.
Questo ha delle implicazioni non da poco, nell’ordine: