Posts Tagged Linux

Recover Un-mountable VMWare ESXi Volume

After upgrading to VMWare ESXi 5 from 4.1, I found one of my datastore volumes would no longer mount. The disk would show up as a device, but there were a series of errors whenever I tried to mount the volume.

After trying a variety of things, I still couldn’t get the volume to mount, so I decided to try to recover the virtual machines off the drive before wiping it.

The first step is to configure the un-mountable disk as a raw passthrough. This will allow a guest OS to access the disk. Instructions for these steps can be found here:
http://rand0mbits.blogspot.com/2010/12/esxi-raw-disk-pass-through.html

After converting the disk to a raw passthrough, assign it to a virtual machine on your ESXi host. I chose Gentoo Linux.

By default, most linux distributions don’t ship with VMFS support, however Christophe Fillot and Mike Hommey have developed a tool called vmfs-tools that allows mounting of VMFS partitions. If you have Debian or Ubuntu you can simply install the package. Since I was using Gentoo I had to build from source:

You may have to emerge some of the prerequisites if you do not have them. See the vmfs-tools site for details.

wget http://glandium.org/projects/vmfs-tools/vmfs-tools-0.2.1.tar.gz
tar -xf vmfs-tools-0.2.1.tar.gz
cd vmfs-tools-0.2.1
./configure
make && make install

Now that we have vmfs-fuse installed, we can mount our volume:

#Ensure the fuse kernel module is loaded
modprobe fuse
 
#Mount the device to the desired mountpoint
vmfs-fuse /dev/sdd1 /mnt/vmfs
 
#copy files off of mounted vmfs
cp -Rv /mnt/vmfs /tmp

, , ,

No Comments

Pre-Eden XBMC-live on Ubuntu 10.04 Lucid

I wanted to try out some of the new features in the upcoming XBMC Eden release.

The problem is that I am running XMBC-live on Ubuntu 10.04 Lucid and the Eden xbmc-live package requires the uxlaunch package which is only available in newer versions of Ubuntu. However, it is still possible to get a working xbmc-live setup by manually configuring the system startup.

NOTICE: This guide describes how I was able to upgrade my existing Ubuntu 10.04 XMBC-live system to work with Eden nightlies. I have no idea if this process works on fresh installs or different versions of Ubuntu. If you are running Ubuntu 10.04, I would recommend installing the stable version of XBMC-live prior to attempting this guide.

First, add the XBMC nightly PPA. The official PPA is provided by Team-XBMC and can be found here: ppa:team-xbmc/unstable.
However, at time of writing, the official PPA was having some problems with the build servers, so I ended up using a ppa recommended on XBMCFreak located here: ppa:nathan-renniewaldock/xbmc-nightly.

The first step is to install the new PPA and update your sources.

sudo add-apt-repository ppa:nathan-renniewaldock/xbmc-nightly
sudo apt-get update

Next, upgrade the xbmc packages:

apt-get upgrade xbmc xbmc-bin

During this process, some of the old xbmc packages will be removed, including xbmc-data and xbmc-standalone.

Now we should have the new version of xbmc installed, however, when we boot the system, X will not start automatically and we will be left with a login prompt.

The final step is to edit the startup script. This script is located at /etc/init/xbmc-live.conf and probably already exists if you already had a previous version of XMBC-live installed. There is a simple change to make to the script to point it at the new executable.

Open the script:

sudo nano /etc/init/xbmc-live.conf

Scroll down to the script section and change the exec from /usr/bin/runXBMC to /usr/bin/xbmc-standalone:

script
        if ! grep -i -q autostart /tmp/xbmcliveParams ; then
                exit
        fi
 
        exec /bin/su xbmc -c "/usr/bin/startx /etc/X11/Xsession /usr/bin/xbmc-standalone"
end script

Restart your system and XMBC should come up. Switch to the confluence skin to see the new features.

Here is the full script for completeness:

# xbmc-live
#
# init XBMC environment and starts XBMC in fullscreen (if asked to do so)
 
#      Copyright (C) 2005-2008 Team XBMC
#      http://www.xbmc.org
#
#  This Program is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2, or (at your option)
#  any later version.
#
#  This Program is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#  GNU General Public License for more details.
#
#  You should have received a copy of the GNU General Public License
#  along with XBMC; see the file COPYING.  If not, write to
#  the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
#  http://www.gnu.org/copyleft/gpl.html
 
description     "XBMCLive"
author          "Luigi Capriotti"
 
start on (filesystem and stopped udevtrigger)
 
stop on runlevel [06]
 
emits starting-x
 
pre-start script
	get_opt() {
		echo "$@" | cut -d "=" -f 2
	}
 
	clear >/dev/tty7 || true
 
	CMDLINE=$(cat /proc/cmdline)
 
	#Process command line options
	XBMC_PARAMS=""
	for i in ${CMDLINE}; do
		case "${i}" in
		xbmc\=*)
		      XBMC_PARAMS=$(get_opt $i)
		      ;;
		esac
	done
	echo $XBMC_PARAMS > /tmp/xbmcliveParams
 
	if grep "boot=live" /proc/cmdline ; then
		# Relies on init scripts to mount boot device on a specified directory
		BOOTMEDIAMOUNTPOINT="/live/image"
	fi
 
	BOOTHOOKSDIRECTORY="/etc/xbmc"
 
	xbmcUser=xbmc
	# Read configuration variable file if it is present
	[ -r /etc/default/xbmc-live ] && . /etc/default/xbmc-live
	if ! getent passwd $xbmcUser >/dev/null; then
		xbmcUser=$(getent passwd 1000 | sed -e 's/\:.*//')
	fi
 
	# Executes pre-hooks (if any) in the System "Hooks" directory
	if [ -d $BOOTHOOKSDIRECTORY/live.d ]; then
	  for hook in $(find $BOOTHOOKSDIRECTORY/live.d -type f -perm /u=x,g=x,o=x | sort)
	  do
	        $hook $BOOTMEDIAMOUNTPOINT $XBMC_PARAMS  || true
	  done
	fi
 
	# Executes pre-hooks (if any) in the user "Hooks" directory
	if [ -d /home/$xbmcUser/.xbmc/live.d ]; then
	  for hook in $(find /home/$xbmcUser/.xbmc/live.d -type f -perm /u=x,g=x,o=x | sort)
	  do
	        $hook $BOOTMEDIAMOUNTPOINT $XBMC_PARAMS  || true
	  done
	fi
 
	if [ -f /home/$xbmcUser/.xsession ] ; then
		rm /home/$xbmcUser/.xsession
	fi
	if [ -f /tmp/noRestartXBMC ] ; then
		rm /tmp/noRestartXBMC
	fi
end script
 
script
	if ! grep -i -q autostart /tmp/xbmcliveParams ; then
		exit
	fi
 
	exec /bin/su xbmc -c "/usr/bin/startx /etc/X11/Xsession /usr/bin/xbmc-standalone"
end script
 
pre-stop script
	touch /tmp/noRestartXBMC
	rm /tmp/xbmcliveParams
 
	# Clean up the console before we switch to it, to avoid text flicker
	if [ -x /usr/bin/tput ] ; then
		tput -Tlinux reset > /dev/tty1 || true
		tput -Tlinux reset > /dev/tty8 || true
	fi
 
	# Clear VT 1 & 8 of any console messages
	clear >/dev/tty1 || true
	clear >/dev/tty8 || true
end script

, , ,

No Comments

Enable OpenVPN Management Interface on ClearOS

The OpenVPN config file structure on ClearOS is non-standard (For example there is no server.conf), so I was unsure where to put the directive. However, as it turns out enabling the Management console is as simple as adding the following to /etc/openvpn/clients.conf:

management localhost 7505

The port is arbitrary: any unused port will do. Localhost restricts connections to the local machine, which is smart if you do not have a password to secure the connection.

To access the management interface using telenet, issue the following from the clearOS box:

telnet localhost 7505
 
#When the prompt comes up, issue a command such as "status"

, ,

No Comments

Jenkins CI Slave on Ubuntu 10.04 Lucid LTS Howto

Install Sun Java:

sudo add-apt-repository ppa:sun-java-community-team/sun-java6
sudo apt-get update
sudo apt-get install sun-java6-jdk

Ensure a SSH server is installed

sudo apt-get install openssh-server

Create a new Jenkins user and create the /var/jenkins directory – this will be our working directory.

sudo useradd -m jenkins
sudo mkdir /var/jenkins
sudo chown jenkins:jenkins /var/jenkins

Generate a public / private keypair and set the public key as an allowed host

ssh-keygen
#Enter file in which to save the key (/root/.ssh/id_rsa):
/var/jenkins/private.key
#Do not enter a Passphrase
 
#You should now have two files in /var/jenkins: a private.key and a private.key.pub, we want to cat the public key into our authorized keys file
su jenkins
cat private.key.pub > ~/.ssh/authorized_keys

The private key must be transfered to an accessible directory on the primary build server. Eg: C:\private.key or a more suitably protected location.

Login to your Jenkins install, select the plugin manager and install the SSH Slaves plugin. After restarting Jenkins to complete the install, click on Manage Jenkins followed by Manage Nodes and create a new dumb node with a name of your liking.

Configuration parameters:

Remote FS Root: /var/jenkins
Launch Method: Launch slave agents on Unix machines via SSH

Host: <Ubuntu Hostname>
Username: jenkins
Private key file: File of the private key (eg: C:\private.key)

When you press save, the slave should attempt to start automatically. If the start fails, check the log provided by jenkins and the server log.

, , ,

No Comments

Wifi RADIUS authentication with LDAP on ClearOS 5.2

This guide will help you setup WPA Enterprise authentication using the RADIUS functionality built into ClearOS 5.2.

The tutorial on the ClearOS wiki page is a good starting point to get radius authenticating off of the LDAP user directory, however it stops short of setting up RADIUS encryption which is required when using WIFI.

Preconditions

Please ensure that you have ClearOS 5.2 installed and have completed the guide at http://www.clearfoundation.com/docs/howtos/setting_up_radius_to_use_ldap.

Throughout this guide, it is assumed that ClearOS can be accessed at http://localhost:81. If you are connecting from a remote machine, please updated your url accordingly.

Generating Certificates

Navigate to https://localhost:81/admin/certificates.php.
When initially setting up ClearOS a Certificate Authority should have been created by default. If this isn’t the case, checkout the ClearOS docs for more information.

We are going to be generating a Secure Server Certificate for use with the RADIUS server.
The default Certificate parameters should work, just be sure to include a proper email address in the email field.
After clicking generate, a new certificate should be visible, click view to review the contents of the certificate. Be sure to note the filename as we will be needing that in a moment. Mine is “/etc/ssl/usr-1-cert.pem”

Now that we have the certificates generated, we are going to softlink them into the radius certs folder and update the permissions so the daemon can read them.

cd /etc/raddb/certs
#softlink the generated certificate
ln -s /etc/ssl/usr-1-cert.pem usr-1-cert.pem
#softlink the generated private key
ln -s /etc/ssl/private/usr-1-key.pem usr-1-key.pem
 
#update the file ownership
chown nobody:radiusd usr-1-cert.pem usr-1-key.pem

RADIUS Configuration

Now that we have the certificates generated, its time to modify the RADIUS configuration files. Remember, the files should have already been modifed as per the wiki article.

/etc/raddb/eap.conf

In the eap.conf file we will be wanting to enable TLS (using our generated certs) and PEAP.
So un-comment out tls and fill in the corresponding information.

The private key file should be set to the key-file softlinked to the /etc/ssl/private directory. (No password is required)

private_key_file = ${raddbdir}/certs/usr-1-key.pem

The certificate file is the cert file softlinked to the /set/ssl/ directory

certificate_file = ${raddbdir}/certs/usr-1-cert.pem

The Trusted root CA list should be the CA certificate for our server

CA_file = /etc/ssl/ca-cert.pem

Additinally, be sure to un-comment the dh_file and the random_file.

tls {
 #       private_key_password = whatever
 #       private_key_file = ${raddbdir}/certs/cert-srv.pem
 private_key_file = ${raddbdir}/certs/usr-1-key.pem
 
 #  If Private key &amp; Certificate are located in
 #  the same file, then private_key_file &amp;
 #  certificate_file must contain the same file
 #  name.
 #       certificate_file = ${raddbdir}/certs/cert-srv.pem
 certificate_file = ${raddbdir}/certs/usr-1-cert.pem
 
 #  Trusted Root CA list
 #       CA_file = ${raddbdir}/certs/demoCA/cacert.pem
 CA_file = /etc/ssl/ca-cert.pem
 
 dh_file = ${raddbdir}/certs/dh
 random_file = ${raddbdir}/certs/random
 
 #
 #  This can never exceed the size of a RADIUS
 #  packet (4096 bytes), and is preferably half
 #  that, to accomodate other attributes in
 #  RADIUS packet.  On most APs the MAX packet
 #  length is configured between 1500 - 1600
 #  In these cases, fragment size should be
 #  1024 or less.
 #
 #       fragment_size = 1024
 
 #  include_length is a flag which is
 #  by default set to yes If set to
 #  yes, Total Length of the message is
 #  included in EVERY packet we send.
 #  If set to no, Total Length of the
 #  message is included ONLY in the
 #  First packet of a fragment series.
 #
 #       include_length = yes
 
 #  Check the Certificate Revocation List
 #
 #  1) Copy CA certificates and CRLs to same directory.
 #  2) Execute 'c_rehash &lt;CA certs&amp;CRLs Directory&gt;'.
 #    'c_rehash' is OpenSSL's command.
 #  3) Add 'CA_path=&lt;CA certs&amp;CRLs directory&gt;'
 #      to radiusd.conf's tls section.
 #  4) uncomment the line below.
 #  5) Restart radiusd
 #       check_crl = yes
 
 #
 #  If check_cert_issuer is set, the value will
 #  be checked against the DN of the issuer in
 #  the client certificate.  If the values do not
 #  match, the cerficate verification will fail,
 #  rejecting the user.
 #
 #       check_cert_issuer = "/C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd"
 
 #
 #  If check_cert_cn is set, the value will
 #  be xlat'ed and checked against the CN
 #  in the client certificate.  If the values
 #  do not match, the certificate verification
 #  will fail rejecting the user.
 #
 #  This check is done only if the previous
 #  "check_cert_issuer" is not set, or if
 #  the check succeeds.
 #
 #       check_cert_cn = %{User-Name}
 #
 # Set this option to specify the allowed
 # TLS cipher suites.  The format is listed
 # in "man 1 ciphers".
 #       cipher_list = "DEFAULT"
}

Setting up peap is easy: just uncomment the directives

peap {
 #  The tunneled EAP session needs a default
 #  EAP type which is separate from the one for
 #  the non-tunneled EAP module.  Inside of the
 #  PEAP tunnel, we recommend using MS-CHAPv2,
 #  as that is the default type supported by
 #  Windows clients.
 default_eap_type = mschapv2
 
 #  the PEAP module also has these configuration
 #  items, which are the same as for TTLS.
 copy_request_to_tunnel = no
 use_tunneled_reply = no
 
 #  When the tunneled session is proxied, the
 #  home server may not understand EAP-MSCHAP-V2.
 #  Set this entry to "no" to proxy the tunneled
 #  EAP-MSCHAP-V2 as normal MSCHAPv2.
 proxy_tunneled_request_as_eap = yes
}

/etc/raddb/ldap.attrmap

This file needs an additional line added. Directly before the checkItem $GENERIC$ … line, add
checkItem    User-Password            userPassword

so the file now looks like:

checkItem    User-Password            userPassword
 
checkItem    $GENERIC$            radiusCheckItem
replyItem    $GENERIC$            radiusReplyItem
 
checkItem    Auth-Type            radiusAuthType
checkItem    Simultaneous-Use        radiusSimultaneousUse
checkItem    Called-Station-Id        radiusCalledStationId
checkItem    Calling-Station-Id        radiusCallingStationId
checkItem    LM-Password            sambaLMPassword
checkItem    NT-Password            sambaNTPassword
checkItem    SMB-Account-CTRL-TEXT        sambaAcctFlags
checkItem    Expiration            radiusExpiration
checkItem    NAS-IP-Address            radiusNASIpAddress
 
replyItem    Service-Type            radiusServiceType
replyItem    Framed-Protocol            radiusFramedProtocol
replyItem    Framed-IP-Address        radiusFramedIPAddress
replyItem    Framed-IP-Netmask        radiusFramedIPNetmask
replyItem    Framed-Route            radiusFramedRoute
replyItem    Framed-Routing            radiusFramedRouting
replyItem    Filter-Id            radiusFilterId
replyItem    Framed-MTU            radiusFramedMTU
replyItem    Framed-Compression        radiusFramedCompression
replyItem    Login-IP-Host            radiusLoginIPHost
replyItem    Login-Service            radiusLoginService
replyItem    Login-TCP-Port            radiusLoginTCPPort
replyItem    Callback-Number            radiusCallbackNumber
replyItem    Callback-Id            radiusCallbackId
replyItem    Framed-IPX-Network        radiusFramedIPXNetwork
replyItem    Class                radiusClass
replyItem    Session-Timeout            radiusSessionTimeout
replyItem    Idle-Timeout            radiusIdleTimeout
replyItem    Termination-Action        radiusTerminationAction
replyItem    Login-LAT-Service        radiusLoginLATService
replyItem    Login-LAT-Node            radiusLoginLATNode
replyItem    Login-LAT-Group            radiusLoginLATGroup
replyItem    Framed-AppleTalk-Link        radiusFramedAppleTalkLink
replyItem    Framed-AppleTalk-Network    radiusFramedAppleTalkNetwork
replyItem    Framed-AppleTalk-Zone        radiusFramedAppleTalkZone
replyItem    Port-Limit            radiusPortLimit
replyItem    Login-LAT-Port            radiusLoginLATPort
replyItem    Reply-Message            radiusReplyMessage

/etc/raddb/radiusd.conf

I found that in the default configuration, the Auth-Type LDAP appeared before the eap in the authenticate section. As a result, the server would cast the request as an LDAP auth type, and fail to parse it as an eap, which would cause the encrypted request from the WIFI access point to fail.
To fix this, I simply swapped the order of the two values, so if the server can’t match against any auth type, it will default to ldap, but most importantly, it will try EAP first.

So the authentication part of the file should look like the following:

authenticate {
 #
 #  PAP authentication, when a back-end database listed
 #  in the 'authorize' section supplies a password.  The
 #  password can be clear-text, or encrypted.
 Auth-Type PAP {
 pap
 }
 
 #
 #  Most people want CHAP authentication
 #  A back-end database listed in the 'authorize' section
 #  MUST supply a CLEAR TEXT password.  Encrypted passwords
 #  won't work.
 Auth-Type CHAP {
 chap
 }
 
 #
 #  MSCHAP authentication.
 Auth-Type MS-CHAP {
 mschap
 }
 
 #
 #  If you have a Cisco SIP server authenticating against
 #  FreeRADIUS, uncomment the following line, and the 'digest'
 #  line in the 'authorize' section.
#    digest
 
 #
 #  Pluggable Authentication Modules.
#    pam
 
 #
 #  See 'man getpwent' for information on how the 'unix'
 #  module checks the users password.  Note that packets
 #  containing CHAP-Password attributes CANNOT be authenticated
 #  against /etc/passwd!  See the FAQ for details.
 #  
 unix
 
 # Uncomment it if you want to use ldap for authentication
 #
 # Note that this means "check plain-text password against
 # the ldap database", which means that EAP won't work,
 # as it does not supply a plain-text password.
 #Auth-Type LDAP {
 #    ldap
 #}
 
 #
 #  Allow EAP authentication.
 eap
 
 Auth-Type LDAP {
 ldap
 }
}

/etc/raddb/users

Comment out the DEFAULT Auth-Type and fallthrough directive, so we aren’t always trying to default to ldap:

DEFAULT LDAP-Group != "radius_users", Auth-Type := Reject
#DEFAULT Auth-Type := LDAP
#      Fall-Through = 1

In Conclusion

You should run service radiusd stop && radiusd -X -A to do your testing with the debug log, as suggested on the ClearOS Wiki.
I found that the radtest still worked as well as authentication from wireless clients using PEAP with MSCHAPv2.
You may want to distribute the usr-1-cert.pem that was generated in the certificates step to wireless clients, however, since we are using password authentication this isnt strictly necessary.

Please let me know in the comments if I have included any redundant or unnecessary steps.

, , , , , ,

No Comments