ClusterSSh

About:

How 'ovpnstatd' works.

ovpnstatd is a status collector daemon for OpenVPN. ovpnstatd can be started either interactively at the console or as a daemon in the background (--daemon).

Use "--help", to get a brief listing of available options.

If started interactively, all connected users and their update-events will be shown on the console-display. This start-mode is merely meant for testing/debugging.

A tcp-port (50505) will be opened, by which a very simple but useful web page can be viewed (http://yourhost:50505). There you get an entry for every OpenVPN-user, whose status-data is available as a result of a connect-event since ovpnstatd's startup. Users who are online, appear as a light-green(ish) entry, disconnected users are shown in grey/white.

The web page will remain empty, as long as no users have connected since startup of ovpnstatd.

The web page is intended for internal (administrator) use only - no "mass media", as ovpnstatd is not a multi-threaded program.

Should ovpnstatd already be running in the background, then you would have to change the port number (--tcp-port <NNNNN>) for your interactive session (if you really want it twice).

Only if started as daemon, ovpnstatd will serve its main purpose, it will collect data of all connect, disconnect, update events, which are reported by any OpenVPN server-process, and write history in csv-format, that can easily be loaded into a database or viewed in a spread-sheet.

In the same time, this data is also written to a FIFO-file "/<status_dir>/send_nsca_data" (/var/run/openvpn/send_nsca_data) in a format suitable for nagios's "send_nsca" utility.

The default location, where collector-data is written, is /srv/www/apps/ovpnstat/datacol - it can be changed with:
"--collect-dir <path-to-your-collector-directory>".

The location where event-data of OpenVPN-hooks is expected, is "/var/run/openvpn". This can be changed with the option:
"--status-dir <path-to-Your-status-directory>".

NOTE: For this to work, you also have to turn on status-logging in OpenVPN config-file(s): "status <path-to-status-data.status>" AND activate the hooks: "client-connect <your-con-script.sh>" and: "client-disconnect <your-dis-script.sh>"

Into the hook-script "your-script.sh" simply place/add the following echo command:

into "client-connect.sh" add the lines
echo -e "OVPN_PID=$PPID\n`env`" \
>/var/run/openvpn/${common_name}.con

into "client-disconnect.sh" add the lines
echo -e "OVPN_PID=$PPID\n`env`" \
>/var/run/openvpn/${common_name}.dis

NOTE: The extension of hook output-files has to be
     .con for client-connect data-files
     .dis for client-disconnect data-files
     .status for status data-files given in OpenVPN config-file
otherwise those files will not be recognized by ovpnstatd.

You can display your favoured icon as a header of the web page.

As default for this, a built-in OpenVPN-icon is displayed.

If you want to replace the default icon in the source (ovpnstatd.h) look for variable "def_web_img64" and substitute its assignment by the output of "base64 -w0 <your-preferred-image>".
But only take tiny images for this !!!

If the TUN/TAP device driver control is not "/dev/net/tun" on your Linux-System, change it with: "--dev-node <Your tun/tap ctrl>"

In case you want to raise the debug-level, use "--debug <N>"
Level 0 = off, 1 = default, 2 = all

Installation:

      # assuming that You've downloaded the tar-file to /usr/local/src
      # proceed als follows:

      cd /usr/local/src
      tar -xjvf ovpnstat.tar.bz2
      cd ovpnstat
      make clean
      make

      # Now for a test start openvpn status collector daemon interactively :
      bash ovpnstatd-test.sh
      
      # If You got an OpenVPN server up and running on the same host
      # then You can already take a look on the web-page

      firefox http://your-host-name:12345/

      # But NOTE: ovpnstatd must run on the SAME HOST, where openvpn-server is on

      # Also note, that collector-data is only written, if the program
      # is started in the background (--daemon ) .

      # So to start it for "normal" usage copy file into place:
      cp init-ovpnstatd /etc/init.d/ovpnstatd
      cp ovpnstatd /usr/sbin/ovpnstatd

      # only if You want to send data to Nagios, otherwise leave this away:
      cp send_nsca.sh

      # You also will have to create the collector directory
      # if this location does not meet Your needs, just modify STARTOPTS
      # in /etc/init.d/ovpnstatd and set --collect-dir to Your favoured 
      mkdir -p /srv/www/apps/ovpnstat/datacol

      # then start openvpn status daemon
      /etc/init.d/ovpnstatd start
	  
	  

Special hints:

Regarding Nagios NSCA:

Before you use the Nagios notification script "send_nsca.sh", you need to edit it - change the ip of the Nagios host therein - have a look if all the path-names are suiting your needs - AND install the "send_nsca" binary. It comes with package nagios-nsca-<version>

Once you have installed nagios-nsca on the Nagios server, you may just copy send_nsca from there to your openvpn-server (including its config-file) - that's all it needs.

Also add a Nagios configuration - a hostname entry for your openvpn-server where ovpnstatd will be running (must match exactly the output of 'hostname' and a service entry for each common-name (service_description must match common-name), that you want to monitor passively.

An example of a passive service config also is included here.

Regarding collector data:

The collector data is in csv format which allows you to easily load it into some database for your own web application.

Bugs (and the like creepers):

ovpnstatd is tested valgrind-clean and is running stable since quite a couple of months now on my openvpn-server.

Description

Table of Contents
• Update Instructions
• Installation Instructions
• Using Supportconfig
• Reporting Bugs
• Novell Support Advisor

The updateSupportutils command compares the current versions of supportutils and its plugins to those installed on your server. Those that are outdated or missing are automatically downloaded and installed. Only those plugins that apply to your server are installed. The command supports creating a weekly or monthly cron entry to automatically check and update the supportutils package and its plugins. Click here to see a list of the current supportutils and plugin packages. The updateSupportutils command help screen follows:

################################################################
# Supportutils Auto Update Client
################################################################

Usage: updateSupportutils [OPTION]

Description
  Makes sure the supportutils and supportutils plugin packages are
  installed and current.

Options
  -m  Install a monthly cron for updateSupportutils
  -w  Install a weekly cron for updateSupportutils
  -d  Delete all installed cron entries for updateSupportutils
  -l  List all cron entries for updateSupportutils
  -u  Force RPM update on applicable packages
  -p  Exclude supportutils plugin packages
  -v  Verbose mode
  -h  This screen

Note: Detailed system information and logs are collected and organized in a manner that helps reduce service request resolution times. Private system information can be disclosed when using this tool. If this is a concern, please prune private data from the log files. Several startup options are available to exclude more sensitive information. Refer to the supportconfig(8) man page to see these options.

Update Instructions

Run updateSupportutils as root.

If you do not already have the supportutils-plugin-updater package installed, refer to the Installation Instructions below. If your server does not have network connectivity to http://download.opensuse.org, then install using the Option B (Manual) method.

Installation Instructions

Option A (Automated)

1. Download the supportutils-plugin-updater
2. Login as root
3. Install the updater package
   # rpm -Uvh supportutils-plugin-updater-*.noarch.rpm
4. Run updateSupportutils as root
   # updateSupportutils

Option B (Manual)

1. Download the supportutils and any applicable supportutils plugin packages for your server.
2. Login as root
3. Install the supportutils-X.XX-XX.XX.noarch.rpm
   # rpm -Uvh supportutils-X.XX-XX.XX.noarch.rpm
4. Install the supportutils-plugin-*-X.X-X.X.norarch.rpm packages you want
   # rpm -Uvh supportutils-plugin-*-X.X-X.X.norarch.rpm

Using Supportconfig

To upload a supportconfig to Novell, run supportconfig -ur $srnum; where $srnum is your 11 digit service request number. You can also just run supportconfig for local use. By default, supportconfig saves its information in /var/log/nts_hostname_date_time.tbz.

Consider using the Novell Support Advisor to perform an initial analysis of your servers. It will generate an HTML report that links you to Technical Information Documents that directly relate to any server issues identified.

Reporting Bugs

Updates to Supportconfig Version 2.25-320:

• Fixed HA error when cibadmin -Q doesn't connect
• Fixed ldapsearch search on non-default port
• Added systool base output to sysfs.txt
• Added getappcore tool to gather application core files
• Added analyzevmcore tool for kernel core analysis
• Supportconfig includes analyzevmcore files in crash.txt
• /etc/services included in network.txt

Updates to Supportconfig Version 2.25-314:

• Changed to systool for sysfs.txt
• Added local binary list to rpm.txt
• Added nlvm to novell-nss.txt for OES11
• Updated copyright years
• Added curl check for update registrations to update.txt
• Fixed conf file execution in plugins directory
• Added a supportconfig summary in summary.xml
• Added /etc/init.d/halt.local to boot.txt
• Added OPTION_UFILES for fs-files-additional.txt. [see supportconfig.conf(5)]
• Fixed fslist_info order
• Added kdump rpm check for sles11sp1
• Added plugin-icommand to scplugin.rc for internal bash commands

Johannes Renner, one of the developers in our SUSE Manager team, recently posted a very useful blog post about using SUSE Studio to create Linux images. The latest update for SUSE Manager makes this a lot simpler.

He wrote:

You already know that it’s possible to use SUSE Studio for creating Linux images that will automatically register with SUSE Manager once deployed to a virtual host and booted for the first time.

From now on you can make use of this feature in a much more convenient way. The final piece of the integration between the two SUSE products is now included with the latest update for SUSE Manager.

Starting up a new virtual system using SUSE Manager can now be simplified to the following steps:

1. Choose the image from a list.
2. Specify deployment parameters.
3. Go for it.

For the details, read this post.

As the event owner for ATT Live, I want to reach out and extend one last invite to this year's ATT Live conference in Las Vegas Nevada - May 15th-18th. For as long as I can remember, this has been a December conference, with an occasional repeat in the early spring based on demand. However, this year... the sunshine and warm weather of May are awaiting us in Vegas, and it could not be more welcomed!

If you have not attended ATT Live in the past 10 years, I encourage you to check it out. You can link to the live landing page at www.novell.com/attlive. Over the years, we have made this the premier technical conference and each year we listen to our attendee's feedback making each year an improvement on the previous. This year is no exception!

I wanted to share some highlights of this year's conference for your consideration, and if you are looking for that last attempt to get approval these things might just help.

• Additional hands-on sessions - We have extended our tracks from 10 to 12, offering a good mix of sessions across the three Business Units. You will find 6 tracks focused on Novell ZENworks, Open Enterprise Server and GroupWise. Three tracks on NetIQ, both legacy Novell Identity and Security products and legacy NetIQ products, giving you a great opportunity to explore some new products in this space, and last, but not least, three full tracks on Suse Linux. Check out the full schedule here - http://www.novell.com/training/attlive/sessions.html
• We have invited more product experts - In order to extend our tracks, we have invited more services employees to help deliver these sessions, adding their product knowledge and real world experience to the sessions. Product managers will also be coming to explore product roadmaps and take your feedback back to the office.
• Certification and Practicum - Whether you are seeking certifications to validate your knowledge, seek a career advancement or just test your knowledge, certification has been included in the price of the event. We ran out of seats last year, so we opened up more sessions this year to make sure all those wanting a chance to test, have the chance. The Linux practicum will also be available in limited slots to help you get that professional Linux certification. Of course we would want you to pass, but because there is no additional charge, no one has to know if you fail.... nothing is harder than submitting a failed exam on your expense report.
• More food, more afternoon sleeping - The M resort is known for its excellent food, buffets, and restaurants, so we are taking what worked well for us last year and have extended our buffet vouchers for lunch, giving you your choice and quantity of food, not ours. If you have any complaints on the food, you can only blame yourself for filling up your plate with the wrong things.
• First ever Alumni event, a thanks to those who always support us - If you are an ATT Live Alumni we want to welcome you to our first Alumni event on Tuesday night. We are excited to have the M Resort open up the Winery for our use. Make sure if you are registered that you plan to join us on Tuesday night. Check out the venue here - http://www.themresort.com/dining/hostilegrape.html
• Low travel costs. Vegas always offers the most affordable travel costs of anywhere I know. Seems you get more for your money when you keep it in your pocket and off the tables. However, I thank those that put the money down, seems to keep the expenses for the rest of us to a minimum (as if... I keep my money in my wallet). We have worked hard to keep the costs of the hotel down, with a low rate, and travel to and from the airport included.

There are plenty of reasons for coming, and we look forward to "filling" the hotel during the week. We will have one of the highest attendances yet, and look forward to seeing you there. If you have considered attending, don't wait, it will be well worth your time and investment.

If you have any questions or comments, you can reach my team at training@novell.com. We will be watching the inbox for your interest and will do what we can to get you there, and home happy that you came.

Thanks -
Jeff McMurdie

(Note: To see a list of all the sessions planned for ATT Live 2012, go to http://bit.ly/Asgjo4.)

At ATT Live 2012, Dr Bjoern Lotz, the designer and creator of the CLP 11 exam scenarios and evaluation scripts, will be presenting 3 sessions on the various common issues and mistakes that most often make the difference between passing and failing the SUSE Certified Linux Professional (CLP) 11 Practicum Exam. These sessions are:

• Dr. L's Treatment for the CLP Pain Points #1: Scripting in the CLP
• Dr. L's Treatment for the CLP Pain Points #2: NFSv4 and Syslog-ng
• Dr. L's Treatment for the CLP Pain Points #3: Apache and Samba

These sessions will be especially helpful for SLES 11 server administrators who want to achieve the SUSE CLP 11 certification. And ATT Live 2012 is a prime opportunity to get this certification because the CLP 11 practicum exam will be offered for free on days 3 and 4 of the event.

I asked Bjoern to provide a bit of useful information from each session that would give you an idea of what to expect if you're interested in taking advantage of this opportunity to prepare for and take the CLP 11 exam. The following information is just a taste of what you'll learn in these sessions. You'll really need to come to ATT Live if you want the full learning experience--demonstrations, hands-on labs, interaction with the instructor, etc.

Scripting in the CLP

One of the common issues that comes up when performing scripting tasks in the CLP exam is that the script does not execute without errors. Among the steps you can take to make sure the script executes properly is to use the following script troubleshooting techniques:

If you do not immediately see why a script is returning errors, you can

• Add set -x at the top of your script - when executing the script you see additional information that can help you find the error
• Put echo in front of commands – that way they are not executed but displayed in the output
• Put read into your script to pause it – hit enter to continue it
• If you don't want to run the whole script, put exit at the point where you want it to end
• Don't forget to remove (or change into a comment with #) the above when you are done

NFSv4 and Syslog-ng

The common mistakes made when performing Syslog-ng tasks in the CLP exam arise from not knowing how to create filters or modify existing ones. Filtering rules that will help you in performing these tasks successfully include the several criteria that can be used for filtering:

• Facility:
  filter f_news { facility(news); };
• Priority
  filter f_alert { level(alert); };
• Program (regular expression)
  filter f_dhcpd { program(“dhcpd”); };
• String (regular expression)
  filter f_firewall { match(“IN=”): };
• Hostname (regular expression)
  filter f_gateway { host(gateway); };
• Elements can be combined:
  filter f_errcrit { level(err, crit); };
  filter f_mailnews { facility(mail, news); };
  filter f_iptables { match(“IN=”) and match(“OUT=”) ; };

Apache and Samba

A common mistake seen in the exam related to the CLP 11 Practicum Apache tasks is there are missing elements in the virtual host configuration. Some tips to keep in mind to perform these tasks successfully are:

• The configuration is distributed across several files in /etc/apache2/, including
  • httpd.conf
  • default-server.conf
  • vhost.d
  • listen.conf
  • error.conf
  • Some configuration options are contained in /etc/sysconfig/apache2, which are used to create configuration files in /etc/apache2/sysconfig.d/
• Virtual hosts are used to provide the Web pages of several domains on one IP address
• To create a virtual host, you need to create a configuration file in the /etc/apache2/vhsots.d/ directory
• The file name has to end in .conf
• The /etc/apache2/vhosts.d/vhost.template file lists the needed parameters with comments explaining their use. You can copy that file and edit it for your virtual host

Register today for the event and for Dr L's CLP 11 Pain Point sessions before they fill up at: www.novell.com/attlive!

ATT Live 2012
May 15-18, 2012
Henderson (Las Vegas), NV
4 days of instructor-led, hands-on advanced technical training for only $1,750

Please follow Novell, SUSE, and NetIQ Training on:
http://twitter.com/novell_training
http://www.facebook.com/NovellTraining