Posts Tagged Linux

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

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


Please ensure that you have ClearOS 5.2 installed and have completed the guide at

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.


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


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


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 {
 #  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 {
 #  MSCHAP authentication.
 Auth-Type MS-CHAP {
 #  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.
 # 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.
 Auth-Type LDAP {


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.

, , , , , ,

1 Comment

Fakemail for Developers

The other day when I was setting up email notifications for a Zend Framework application, I stumbled across Fakemail.

From the developers website:

fakemail is a fake mail server that captures emails as files for acceptance testing. This avoids the excessive configuration of setting up a real mail server and trying to extract mail queue content.

I am quite impressed with this handy little script (written in both Python and Perl), as it works exactly as advertised: taking out the time required to properly configure a SMTP server and saving the hassle of having dozens of test messages showered across inboxes. Instead of forwarding emails on to their recipients, it simply saves a raw copy of the email to the specified directory.

The script has a windows installer that bundles the script with python and will run on all flavors of Linux and Unix assuming that they have perl or python installed.

To configure Zend_Mail use fakemail place the following in your bootstrapper or common config file:
[php]Zend_Mail::setDefaultTransport(new Zend_Mail_Transport_Smtp(‘localhost’,array(
‘port’ => 10025

The ‘localhost’ variable is the address of the computer that fakemail is running on (likely the local machine). The port number is the port that is specified when fakemail is run on the command line.

For more information about fakemail, binaries, and a usage guide. Visit the developers website at Sourceforce:

, ,

1 Comment

Gentoo init Script

I have several servers which run an assortment of http, svn, ssh, and ftp services. One of the largest annoyances are automated breaking scripts pounding my services. Recently, I have been looking into a handy python script written by Reto Glauser, which monitors syslog-ng logs looking for possible break-in attempts. The script uses iptables to block future traffic from suspicious IP’s for a specified amount of time.

After I got the script setup and running I wanted a Gentoo init script that would automatically start the script on boot. After reading through some examples in my /etc/init.d/ directory I seem to have managed to cook up something that works: Read the rest of this entry »

, , ,