VOIP problemo

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.

Rootless SCOM agent setup

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"] ]
}
}


Manual SCOM agent certificate signing

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

Install SCOM agent on Red Hat Linux

The steps below describe how to install the SCOM agent on Red Hat Linux 5 x64. We don’t like to enroll the agent by using the SCOM Discovery wizard, as you need to enter the super-user (root)credentials and we’re not sure where the application stores those credentials and it’s used for. So we’re still searching for the minimal permissions for the agent to be installed.

It is possile to install the agent, copy the unsigned client-side generated certificate to the SCOM server, sign the certificate on the SCOM server and copy the signed certificate back to the client. Once you have restarted the scx daemon you can use the discovery wizard on the SCOM server to add the server without using super-user credentials in SCOM.

Once you have installed the Cross Platform Cumulative Update 2 for System Center Operations Manager 2007 R2, a newer version of the agent becomes available on the SCOM server in Program Files\System Center Operations Manager 2007\AgentManagement\UnixAgents.


# rpm -ivh scx-1.0.4-258.rhel.5.x64.rpm
Preparing...                ########################################### [100%]
   1:scx                    ########################################### [100%]
Generating certificate with hostname="host001", domainname="example.local"

WARNING!
Could not read 256 bytes of random data from /dev/random. Will revert to less secure /dev/urandom.
See the security guide for how to regenerate certificates at a later time when more random data might be available.

/var/tmp/rpm-tmp.63356: line 163: /usr/lib/lsb/install_initd: No such file or directory
Starting Microsoft SCX CIM Server: [  OK  ]
#

To fix the above problem you can use the following work-around.

rm /dev/random
rm: remove character special file `/dev/random'? y
# mknod -m 644 /dev/random c 1 9
# chown root:root /dev/random
# cd
# rpm -ivh scx-1.0.4-258.rhel.5.x64.rpm
Preparing...                ########################################### [100%]
   1:scx                    ########################################### [100%]
Generating certificate with hostname="host001", domainname="example.local"
/var/tmp/rpm-tmp.10879: line 163: /usr/lib/lsb/install_initd: No such file or directory
Starting Microsoft SCX CIM Server: [  OK  ]
# rm /dev/random
# mknod -m 644 /dev/random c 1 8
# chown root:root /dev/random


Moving into the cloud

Last week I setup a server in a cloud based on Xen virtualization technology. After some hours research I decided to go for the Rackspace cloud. I chose the minimal setup to start with, which is a 256MB memory configuration that comes with 10GB disk space. As stated in the specs, the 256MB plan will get you 1/64 of the CPU allocation. Which is fine to start with for a standard LAMP setup.

For now they only offer a large variety of Linux distributions. I chose Debian 5.0 Lenny, because it makes migration easier as the site is running on Debian 5.0 already. The registration process and setup of the minimal Debian install went very smoothly. In under two hours I had successfully migrated a website. So for the setup part I am totally satisfied, let’s see how the availability part will develop.

Backup Lenny using TSM

The few steps below describe in short how to install Tivoli Storage Manager (TSM) on Debian 5 (Lenny) x64.

1. Download the latest 5.x TSM client

# wget ftp://ftp.wu-wien.ac.at/mirrors/tsm/maintenance/client/v5r5/Linux/LinuxX86/v552/5.5.2.0-TIV-TSMBAC-LinuxX86.tar

2. Install alien and dependencies

# apt-get install alien gawk libstdc++5

3. untar the TSM client software

# tar -xvf 5.5.2.0-TIV-TSMBAC-LinuxX86.tar
NOTICES.TXT
README_enu.htm
README_api_enu.htm
README_hsm_enu.htm
TIVsm-API.i386.rpm
TIVsm-API64.rpm
TIVsm-BA.i386.rpm
TIVsm-HSM.i386.rpm

4. Convert the RPM packages using alien

# alien -g TIVsm-API.i386.rpm
Warning: Skipping conversion of scripts in package TIVsm-API: postinst prerm
Warning: Use the --scripts parameter to include the scripts.
Directories TIVsm-API-5.5.2 and TIVsm-API-5.5.2.orig prepared.
# alien -g TIVsm-BA.i386.rpm
Warning: Skipping conversion of scripts in package TIVsm-BA: postinst prerm
Warning: Use the --scripts parameter to include the scripts.
Directories TIVsm-BA-5.5.2 and TIVsm-BA-5.5.2.orig prepared.

5. Adjust the control files

# mv TIVsm-API-5.5.2/debian TIVsm-API-5.5.2/DEBIAN
# mv TIVsm-BA-5.5.2/debian TIVsm-BA-5.5.2/DEBIAN
# vi TIVsm-API-5.5.2/DEBIAN/control
# vi TIVsm-BA-5.5.2/DEBIAN/control

The control file should like the following:

Source: tivsm-api
Section: non-free
Priority: extra
Maintainer: root <root@localhost>

Package: tivsm-api
Architecture: all
Depends: ${shlibs:Depends}
Description: IBM Tivoli Storage Manager API

6. Build the packages

# dpkg -b TIVsm-API-5.5.2
dpkg-deb: building package `tivsm-api' in `TIVsm-API-5.5.2.deb'.
# dpkg -b TIVsm-BA-5.5.2
dpkg-deb: building package `tivsm-ba' in `TIVsm-BA-5.5.2.deb'.

7. Install the packages

# dpkg -i TIVsm-API-5.5.2.deb
Selecting previously deselected package tivsm-api.
(Reading database ... 146642 files and directories currently installed.)
Unpacking tivsm-api (from TIVsm-API-5.5.2.deb) ...
Setting up tivsm-api (5.5.2) ...
# dpkg -i TIVsm-BA-5.5.2.deb
Selecting previously deselected package tivsm-ba.
(Reading database ... 146716 files and directories currently installed.)
Unpacking tivsm-ba (from TIVsm-BA-5.5.2.deb) ...
Setting up tivsm-ba (5.5.2) ...
#

8. Post install issues

# echo "/opt/tivoli/tsm/client/ba/bin" >> /etc/ld.so.conf
# ldconfig
# ln -s /opt/tivoli/tsm/client/lang/en_US /opt/tivoli/tsm/client/ba/bin/

And you’re done installing TSM. You’re now ready to proceed to the configuration. The TSM configuration files are located in /opt/tivoli/tsm/client/ba/bin. You can start by copying the sample files.

# cd /opt/tivoli/tsm/client/ba/bin
# cp dsm.opt.smp dsm.opt
# cp dsm.sys.smp dsm.sys

Have a look at the IBM docs for the configuration options.

vsftpd and SSL

This howto describes how to configure vsftpd to enable SSL using so called intermediate/ chaining certificates.

Edit vsftpd.conf so that SSL is enabled:

ssl_enable=YES
rsa_cert_file=/usr/share/ssl/certs/vsftpd.pem
force_local_data_ssl=NO
force_local_logins_ssl=NO

It is very important to construct the certificate file /usr/share/ssl/certs/vsftpd.pem with the correct certificate order. The fist Your certificate file has to be a .pem file. If you also received an Intermediate Certificate then you have to concatenate this with the Domain Certificate and your Private Key file into one single .pem file. Make sure all the information is included, without any spaces or blanks, see below.

-----BEGIN CERTIFICATE-----
 (your_domain_name.crt)
-----END CERTIFICATE KEY-----
-----BEGIN CERTIFICATE-----
 (chaining certificate 3)
-----END CERTIFICATE KEY-----
-----BEGIN CERTIFICATE-----
 (chaining certificate 2)
-----END CERTIFICATE KEY-----
-----BEGIN CERTIFICATE-----
 (chaining certificate 1)
-----END CERTIFICATE KEY-----
-----BEGIN RSA PRIVATE KEY-----
 (your_domain_name.key)
 -----END RSA PRIVATE KEY-----

This is how to check a SSL enabled FTP service (FTP Secure). See the result below:

$ lftp -u username localhost -e "debug;set ftp:ssl-protect-data true;ls;exit"
Password:
---- Connecting to ftp.student.vu.nl (130.37.129.243) port 21
<--- 220 Welcome to the Storage FTP service.
---> FEAT
<--- 211-Features:
<---  AUTH SSL
<---  AUTH TLS
<---  EPRT
<---  EPSV
<---  MDTM
<---  PASV
<---  PBSZ
<---  PROT
<---  REST STREAM
<---  SIZE
<---  TVFS
<---  UTF8
<--- 211 End
---> AUTH TLS
<--- 234 Proceed with negotiation.
---> OPTS UTF8 ON
Certificate: C=NL,O=Vereniging VU-Windesheim,OU=UC-IT,CN=ftp.student.vu.nl
 Issued by:        C=NL,O=TERENA,CN=TERENA SSL CA
 Checking against: C=NL,O=TERENA,CN=TERENA SSL CA
  Trusted
Certificate: C=NL,O=TERENA,CN=TERENA SSL CA
 Issued by:        C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware
 Checking against: C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware
  Trusted
Certificate: C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware
 Issued by:        C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root
 Checking against: C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root
  Trusted
Certificate: C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root
 Issued by: C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root
  Trusted
<--- 200 Always in UTF8 mode.
---> USER xxx330
<--- 331 Please specify the password.
---> PASS XXXX
<--- 230 Login successful.
---> PWD
<--- 257 "/"
---> PBSZ 0
<--- 200 PBSZ set to 0.
---> PROT P
<--- 200 PROT now Private.
---> PROT P
<--- 200 PROT now Private.
---> PASV
<--- 227 Entering Passive Mode (130,37,129,243,196,139).
---- Connecting data socket to (130.37.129.243) port 50315
---- Data connection established
---> LIST
<--- 150 Here comes the directory listing.
Certificate: C=NL,O=Vereniging VU-Windesheim,OU=UC-IT,CN=ftp.student.vu.nl
 Issued by:        C=NL,O=TERENA,CN=TERENA SSL CA
 Checking against: C=NL,O=TERENA,CN=TERENA SSL CA
  Trusted
Certificate: C=NL,O=TERENA,CN=TERENA SSL CA
 Issued by:        C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware
 Checking against: C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware
  Trusted
Certificate: C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware
 Issued by:        C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root
 Checking against: C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root
  Trusted
Certificate: C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root
 Issued by: C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root
  Trusted
---- Got EOF on data connection
---- Closing data socket
drwxrwsr-x    3 72745    513          4096 Oct 23 14:28 public_html
<--- 226 Directory send OK.
---> QUIT
---- Closing control socket
$

License to rdesktop

Today I recieved a strange message when I tried to open a RDP connection.

$ rdesktop windows.server.local
Autoselected keyboard map en-us
disconnect: No valid license available.

To resolve this issue you need to add the client hostname.

$ rdesktop -n hostname windows.server.local
Autoselected keyboard map en-us
WARNING: Remote desktop does not support colour depth 24; falling back to 16

This happens with rdeskop version 1.6.0 on Fedora 11 (rdesktop-1.6.0-4.fc11.x86_64).