My contribution to this heavy day for our rss readers is:
The April's Fool Centipede !
.:/ .:/ .:/
,,///;, ,;/,,///;, ,;/,,///;, ,;/
o:::::::;;///o:::::::;;///o:::::::;;///
>::::::::;;\\\::::::::;;\\\::::::::;;\\\
''\\\\\'" ';\''\\\\\'" ';\''\\\\\'" ';\
beware, don't believe all news today :)
Since I use puppet to manage my machines (and the machines of customers), I noticed that I had more packages installed then before, I noticed also obviously the same behavior in packages to update and bandwidth consumption during updates.
I realize that on 64bits machines, most of the time, the 32bits version of the packages managed by puppet were also installed.
This is what I did in my recipes before:
package { "corosync":
ensure => "installed",
require => Yumrepo["clusterlabs"];
}
This kind of package declaration installed then the two version of the package, in this case corosync and the dependencies too.
To avoid this I added the fact hardwaremodel and used the alias to keep my recipes consistent:
package { "corosync.$hardwaremodel":
ensure => "installed",
alias => "corosync",
require => Yumrepo["clusterlabs"];
}
Hope this could help people having noticed the same behavior... or not :-)
Since I tested it 4 years ago, I like Open-Xchange (even if I'm not a java app fan). I like the layout and also all the feature it provides. The calendar is very complete.
For a customer where I set it up 4 years ago, I've migrated this service to a cluster running the last version.
The machines are fully installed via kickstart from a pxeboot (using cobbler)
This post describes the solution. The setup is based on CentOS and use the pair corosync / pacemaker as cluster.
The solution consists in two nodes where only one machine provides the service.
The components are :
- one ip balancing between the two nodes
- apache running on the "active/master" server (the server providing the service)
- open-xchange running on one node at the time
- funambol running on one node at the time
- openldap running on both machines in mirroring
- cyrus running on both machines as master/slave
- mysql running on both machines as master/master replication.
This is an overview of the crm:
Most of the needed steps are put in some puppet recipes to help the provisioning (you can find them on my github account)
With the cyrus-imapd delivered by default on redhat/centos, when the cyrus master starts without the slave running, cyrus won't reply for a long time... the bug we are hitting here as been resolved in newer version. I use cyrus-imapd 2.4.6, package from Simon Matter. You can find the source of this package here
Like last year I'll be present at the MySQL & Friends Meetup on Saturday evening of the Fosdem.
If you wanna share some experience around MySQL, please join !
You can register here
I will be present at the devops meetup of Fosdem 2011.
It will take place the Friday 4th February.
I hope to see you there if your are in the devops mind and if you wanna share some experience with us !
As MySQL Community Manager, I am an employee of Oracle and the views expressed on this blog are my own and do not necessarily reflect the views of Oracle.
You can find articles I wrote on Oracle’s blog.