Wanted to give Alchemy 3.0 a spin, but following the guides doesn’t really get you where you want.
First of all, you need ruby 2.1 installed. Ruby 2.0 doesn’t do the trick.
Then you need to install rails 4.1.1
gem install rails v=4.1.1
after installing the rails gem, create a new project.
rails new foobar
in the projects Gemfile add the alchemy gem AND the alchemy-devise gem!
if you don’t install alchemy-devise you will get an error trying to execute the “alchemy:install” rake task.
gems/activesupport-4.1.1/lib/active_support/inflector/methods.rb:238:in `const_get': uninitialized constant User (NameError)
adding alchemy-devise to the Gemfile solves this issue.
Setting up the first cluster on Debian wheezy (7.0) caused some issues when trying to fence with IPMI.
First issue was that the node tried a “clean” shutdown before really powering down.
To solve this issue, you need to tell GRUB to disable ACPI.
Edit /etc/default/grub and add “acpi=off” to GRUB_CMDLINE_LINUX_DEFAULT
Second issue: I wanted the fencing to just power off the node, not reboot it.
Turns out, Pacemaker prior to version 1.1.10, ignores the ‘action=”…”’ and debian wheezy installs Pacemaker 1.1.7-1.
To solve this, you need to set the pcmk_reboot_action instead. Thanks to clusterlabs.org for this hint.
The CRM configuration would look something like this:
I don’t know what drugs the people at gigaset are consuming, but this is by far the sickest provisioning I have ever seen.
If you can’t use the gigaset provided provisioning server (because you need to use the contact form, to contact gigaset and beg the to create an account for you! wtf?)
So, first of all on your web server you need some special directories.
Let’s assume our provisioning url will be: http://192.168.0.10/device
on your web server under device you need to create sub directories depending on the phone model you want to provision.
In this example I will be using the gigaset N510IP Pro.
This device expects a directory 42/2 to be present. For more details check the gigaset wiki
Looking at the wiki you will see that some files will be requested as well:
So, where do you get the files? Searching through the gigaset wiki there is no reference to the files.
The answer is, you need to download them from the gigaset provisioning server - http://profile.gigaset.net/device
so in our case, if we have a xml file on the server, we will edit it like this:
This will make the gigaset request http://192.168.0.10/device/.xml where will be the MAC address from the phone.
The XML File is some other twisted sick stuff which I will not go into now.
But it’s important to update the version on each edit (see comments in file):
Give the handsets a name.
This would be the first handset:
I’m not really a fan of redhat, neither of sendmail.
Today I had to set up mail send on a Red Hat Enterprise Linux Server release 5.5 where sendmail was already installed.
This was the easy part to fix. First remove sendmail, forcing it to ignore dependencies.
I have delayed this for over a year and every day just clicking away the warning about the expired cert.
Now I finally allocated some time to solve this issue.
The Openfire Web interface doesn’t really tell you what to do and how to paste the certificate contents.
First go to Server Settings -> Server Certificates -> Import
Paste your private key in the first field.
In the certificate field paste your certificate first, followed by the intermediate certificate.
The important part is: you must not have a line break after
—–END CERTIFICATE—– or —–END RSA PRIVATE KEY—–
These lines must be the last line of the text box else the import will fail!
This should save me some time in 2014 :)
If you need a shared object (calender, address book) with multiple users, the best way to do this is by using a distribution list.
So let’s get started. First create a distribution list and add all your users you want to it. You might also want to disable the option “Can receive mail” and also enable “Hide in GAL” to avoid some confusion.
Then create a resource where you will create your shared object. By using a resource you can create your shared calender or address book without wasting a license.
After you created the resource, click on view mail, go to the calender and add a share.
Use the distribution address as email for the share.
Now go back to the distribution list and click edit.
Go to the shares tab and click ob publish shares.
Enter the mail of the resource, click on find shares, select the desired share and click on “Publish selected share”
The advantage of using this method is that newly added users to the distribution list will automatically get permissions for the share and as soon as a user is removed from the distribution list the share permissions will be revoked!
To install a comodo SSL certificate with zimbra you need the certificate of course and also the “Intermediate CA” and “root CA”.
Unfortunately I was only sent a link to the intermediate CA but not the root CA.
So here are the links to the missing two CA.