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
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-binDuring 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 scriptRestart 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
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 7505The 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"
Jenkins CI Slave on Ubuntu 10.04 Lucid LTS Howto
Posted by Dustin in How-To, Linux, Uncategorized on June 18, 2011
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.
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 & Certificate are located in # the same file, then private_key_file & # 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 <CA certs&CRLs Directory>'. # 'c_rehash' is OpenSSL's command. # 3) Add 'CA_path=<CA certs&CRLs directory>' # 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.