Dirk-Jan's blog

I would like to share my experience with webOS in combination with Zimbra Collaboration Suite. For the past two years I’m using Zimbra Open Source edition and I am pretty satisfied with it. It handles my email, contacts, calendar and tasks very well. Call me paranoid, but I don’t like Google or Yahoo! to watch over my personal data. All was working well till I received my first webOS device, an HP TouchPad, which I wanted to connect to my Zimbra server to manage email, appointments, contacts and tasks. Doing some searches I discovered it is possible to use Exchange (ActiveSync) with Zimbra Mobile, but I had the wrong edition of Zimbra. It appeared Zimbra Mobile is available for all Zimbra editions except for the Open Source edition I was using, that’s how they earn their money. I chose to go for the Zimbra Appliance Basic Free Edition. This free edition allows you to create up to 10 mailboxes, which is enough for myself and some family members.

I am using VirtualBox virtualization software, which works with the VMDK from the ZCA zip file. The configuration and migration from one Zimbra edition to the other went relatively smooth. The first thing to test was to setup my HP TouchPad and HP Pre3 smartphone (both collectors items now) and both are connected without a glitch.

One last catch, be careful with the Zimbra default mobile policy. Remote wipe works extremely well if you enter four incorrect your pin codes.

After all I am pretty pleased the way it’s working.

My specs:

• VirtualBox 4.1 on Debian 5 (Lenny)
• ZCA 6.0.13 (Installed) upgraded to 6.0.14 (6.0.15 is on it’s way to be released shortly)
• HP TouchPad 3.0.5
• HP Pre3 2.2.4

This week I decided it was time to upgrade my home server. The main reasons, lack of 64-bit support and virtualization technology (VT-x) in my existing setup. The performance gain was also a nice side effect. I have come up with the following new components:

• Intel DQ67EPB3, S1155, Q67, 2xDDR3, mITX
• Intel Core i3-2120T, 2.60GHz, 3MB, HD2000, S1155
• Kingston ValueRam 8GB(2x4GB) DDR3 1333MHz CL9

The Intel motherboard claims to be energy efficient and the i3 processor has a max thermal design power (TDP) of 35W. I think this is a nice balanced setup to do low-end virtualization with low-power consumption in mind. I might do a power consumption measurement one day.

Once all was installed and the new system booted it appeared networking did not come up in Debian 5 (Lenny).

I had to download and build the driver manually, see the instructions below:

lspci showed: Ethernet controller: Intel Corporation Device 1502 (rev 04)

Look for the “Intel® 82579 Gigabit Ethernet Controller” on the http://downloadcenter.intel.com website.

tar xvzf e1000e-1.9.5.tar.gz
cd e1000e-1.9.5/src
make install
modprobe e1000e
ifconfig eth0 up

Cumulative Update 5 for System Center Operations Manager 2007 R2 brings support for Red Hat 6. This update is release on August 4, 2011. Red Hat Enterprise Linux 6 was release on November 10, 2010. So Microsoft managed to put out an update with support for RHEL6 9 months later. This new management pack is not included in the update, you have to download en and import it separately.

It’s been 1,5 year since I build a new home server. I’m quite happy with this system, but lately I am running out of hard disk space. This is mainly caused by HD movie editing which I’m recently into. That’s why I bought two new 2 TB hard disks (WD20EARS) today to replace the current 1 TB ones (WD10EVVS).

I’ve done my hard disk setup with Linux soft raid 1 (mirror). So the plan is to break the mirror switch one pair of disks, rebuild the mirror and repeat this for the other pair.

It essentially comes down to the following commands having two disks, sda and sdb, both with two partitions.

Break the mirror:

# mdadm /dev/md0 --set-faulty /dev/sdb1
mdadm: set /dev/sdb1 faulty in /dev/md0
# mdadm /dev/md0 --remove /dev/sdb1
mdadm: hot removed /dev/sdb1
# mdadm /dev/md1 --set-faulty /dev/sdb2
mdadm: set /dev/sdb2 faulty in /dev/md0
# mdadm /dev/md1 --remove /dev/sdb2
mdadm: hot removed /dev/sdb2

Shutdown the system, and swap disks. Be sure to swap the correct disk, the one that have been removed from the mirror.

Power on the system and partition the newly added disk. This is where I had to pay attention. It appears the new Western Digital disks are 4096-byte per sector disks instead of the traditional 512-byte sector disks. In order to have good performing disks I had to correct the alignment of the new disk. This covered in greater detail on this page.

Partition the disks (ensure that you’re root filesystem is bootable):

Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              64         126      506047+  fd  Linux raid autodetect
/dev/sdb2             134       12292    97667167+  fd  Linux raid autodetect

Add the new disk to the mirror and watch the sync progress:

# mdadm /dev/md0 --add /dev/sdb1
# watch cat /proc/mdstat
# mdadm /dev/md1 --add /dev/sdb2
# watch cat /proc/mdstat

Install grub on the new disk and  repeat the above steps for the other disk.

After the sync is completed run the grow command:

# mdadm /dev/md1 --grow --size=max

Finishing steps:

# pvresize --verbose /dev/md0
# lvresize --verbose -L <SIZE> /dev/mapper/VG-LV
# resize2fs /dev/mapper/VG-LV

Today I encountered a strange problem when I tried making a phone call using my home VOIP telephone. I could dial out, but there was no sound coming through, which is pretty confusing. At first I thought it had something to do with the firmware update I did recently on my Siemens A580 IP. After spending half an hour troubleshooting it appeared to be my VOIP provider uses another sip server to talk back to my Asterisk server. After adding this new server ip to my firewall configuration the sound is coming through again, which is the essence of telephony.

Added firewall rule:

access-list 101 permit udp host 83.143.188.182 host <my asterisk server ip>
access-list 101 permit udp host 83.143.188.186 host <my asterisk server ip>

I think this could be useful for other Budgetphone VOIP users experiencing the same.

Today we recieved a new system to enroll our Linux operating system on. It comes with two six core Intel Xeon processors with hyperthreading enabled. When the installation was finished I fired up top and switched to SMP view, which didn’t worked. It displayed the following message (have a look at the picture). I had to enlarge the terminal to have all 24 cpu’s displayed. Too funny!
Do we get ahead of Moore’s law?

The setup of a SCOM agent without having to enter the root password in the SCOM management console is actually very simple. At first I thought it would be necessary to export the key by which the client certificates are signed to do the signing on the system used to roll out new Linux systems.

I have described the the process below in a few steps.

1. Install the agent.
You can find the manual installation instructions on this site.

2. Create a new user on the Linux client, in my case ‘scom’.
This user and password must match the action account credentials you have entered somewhere in the SCOM administration section.

# useradd scom
# passwd scom

3. Change ownership and permissions on /etc/opt/microsoft/scx/ssl/scx-host-[hostname].pem

# chown scom: /etc/opt/microsoft/scx/ssl/scx-host-[hostname].pem
# chmod 644 /etc/opt/microsoft/scx/ssl/scx-host-[hostname].pem

4. Start the discovery wizard, add your host and uncheck ‘Enable SSH based discovery’.
Under the host information enter the scom user and the corresponding password. Check the ‘This is a superuser account’ check box.
Make sure the SCOM server can communicate on port 1270/tcp, otherwise discovery will fail.

5. Discovery will report the current (self-signed) certificate is invalid and will suggest to sign the certificate with the SCOM CA key.
Once this step is finished it will report no results, but the certificate is signed. You can verify this with OpenSSL.

6. Restart the scx daemon on the Linux system.

# /opt/microsoft/scx/bin/tools/scxadmin -restart

This will initialize the modified certificate.

7. Re-issue a discovery of the same host (press the previous button two times).
In this final step the host is discovered successfully without having entered the root password.

I have created a Puppet recipe for the above to automate the roll-out of SCOM on Linux:

class scom {

package { scx:
ensure => installed
}

service { scx-cimd:
ensure => true,
enable => true,
hasrestart => true,
hasstatus => true,
subscribe => [ File["/etc/init.d/scx-cimd"], Package[scx] ]
}

file { "/etc/init.d/scx-cimd":
owner => root,
group => root,
mode => 744,
require => Package["scx"],
}

file { "/etc/opt/microsoft/scx/ssl/scx-host-$hostname.pem":
owner => scom,
group => scom,
mode => 644,
checksum => md5,
notify => service[scx-cimd],
require => [ Package["scx"], User["scom"] ]
}

user { "scom":
ensure => present,
name => "scom",
uid => "6004",
comment => "SCOM monitoring agent",
shell => "/bin/bash",
home => "/var/opt/microsoft/scx",
managehome => "true",
password => '$1$vS1boUVQ$vMmabY1rt4FQokoweKvXw/',
require => [ Class["users"], Package["scx"] ]
}
}

The SCOM Linux agent (scx) uses a SSL certificate to trust communication between the SCOM server and Linux agents. The SCOM server communicates with the agent running on port 1270/tcp.

Normally you will deploy the agent by using the discovery wizard. The SCOM server initially makes a SSH connection to the agent and tries to detect which Linux distribution and version it’s dealing with. Then it will push (sftp) and install the scx package. At the end of the installation it will create a certificate. This certificate needs to be signed by the SCOM server, so the server will fetch the certificate, signs it and delivers it back to the client. At the end the agent will restart to initialize the newly created certificate and agent communication over port 1270/tcp is trusted. The above described actions are executed using the privileged account.

It is also possible to manually sign the certificate created during manual installation of the scx package. This process is described below.

1. Copy the output of the following command including ‘—–BEGIN CERTIFICATE—–’ and ‘—–END CERTIFICATE—–’ to your paste buffer.

$ cat /etc/opt/microsoft/scx/ssl/scx-host-[hostname].pem

By using the following command you can view the contents of the certificate:

$ openssl x509 -noout -text \
-in /etc/opt/microsoft/scx/ssl/scx-host-[hostname].pem

2. Create a new file on the SCOM server ‘scx-host-[hostname].pem’, paste the certificate data into it and save this file.

3. Open a windows console and execute the following:

scxcertconfig -sign scx-host-[hostname].pem scx_signed.pem

This command will sign your certificate (scx-host-[hostname].pem) and save it to a new file.

4. Copy the contents of the signed certificate to the paste buffer.

5. Open the ‘/etc/opt/microsoft/scx/ssl/scx-host-[hostname].pem’ on the Linux server, delete it’s contents and paste the newly created certificate data from the paste buffer.

6. Restart the agent by running the following command.

# /opt/microsoft/scx/bin/tools/scxadmin -restart

This will initialize the new certificate.

The last step is open the SCOM management console and walk through the discovery wizard to register the agent. A super-user account is probably not required anymore.

After the installation of the scx package you need to create a action account user. The SCOM agent will be run under this user.

Related article: install-scom-agent-on-red-hat-linux