ixs' Vodkamelone - Teh Intarweb

Better UX on the Nagios web interface using the corewindow parameter

andreas@dicp.de (andreas) — Sun, 25 Feb 2024 11:17:31 +0100

Nagios is probably one of the most used network monitoring systems around. Especially in environments that have been around for a while and contain a lot of on-premises nodes.

I've recently started to upgrade an existing installation which included a lot of automation and updating from Nagios Core 3.x to Nagios Core 4.x. This resulted in an updated Web Interface with more PHP code and a more modern design.

One main gripe I have about the Nagios interface however is the use of Frames. The problem has not changed since the 3.x days:

Nagios uses frames
This means that the browser only ever shows the base url (https://example.com/nagios/) in the location bar
When navigating to a specific service, e.g. /nagios/cgi-bin/extinfo.cgi?type=2, the location bar is unchanged and still points at the base URL.
If I want to share a specific service status I need to copy the URL of the frame and send it to a colleague.
Said colleague will only see the service status when opening that URL, no navigation bar will be shown, because that's in a different frame which we're bypassing.

This is a common issue with framesets and a complaint that basically came up 5 minutes after the introduction of frames in 1996.

Despite these complaints, frames can actually be very useful in many cases. When developing your own software, there are multiple options available to work around these frameset limitations. When using third-party software such as Nagios however, there's fewer options available.
For Nagios Core 3.x I had replaced the Nagios provided index.html page with my own index.php page that takes an optional parameter for the address of the main frame which allowed to construct URLs that open the regular Nagios interface with the navigation bar on the left frame and a e.g. specific service opened on the main frame to the right.

When porting this functionality I stumbled the fact that Nagios Core 4.x is already using PHP for some files and the default index.php already seems to have a parameter called "corewindow" that seems to offer this functionality. Unfortunately, there is barely any documentation around for this parameter. The first thing I found is a ChangeLog entry (https://www.nagios.org/projects/nagios-core/4x/) indicating this functionality is disabled by default due to a potential security vulnerability:

4.3.0 02/21/2017
Security
Fix for CVE-2016-6209 The corewindow parameter (as in http://localhost/nagios?corewindow=www.somewhere.com) has been disabled by default. See the UPGRADING document for how to enable it.

Well, Duh. If you take random URLs and use them to build a frameset defintion, this can indeed be "misused" to open a random URL inside your Frameset.
Personally, I wouldn't consider this a case of "works as designed" and not as a security issue but of course hapless users might be confused. Probably depends a lot on the users.

But this is exactly the functionality we need except it's disabled. The UPGRADING document states that one can re-enable the corewindow functionality using the --enable-corewindow Parameter when building Nagios.
But re-enabling said functionality is even easier. Just change line 4 in the index.php file from

if ("no"== "yes" && isset($_GET['corewindow'])) {

if ("yes"== "yes" && isset($_GET['corewindow'])) {

Done, that's the same thing the --enable-corewindow parameter does.
On my system, that file is found at /usr/share/nagios/html/index.php. Your system might be different.

If you now open /nagios/index.php?corewindow=nagios/tac.cgi the index file will open the Tactical Overview screen. Nice!

Functionality restored using the default installation. Perfect!

But can we improve things?

While looking for documentation for the corewindow parameter, I stumbled over Custom CGI Headers and Footers on the Nagios documentation. It seems the CGIs can load files and embed them in the HTML page...

This is brilliant. We can use some low key JavaScript logic to automatically update the browser location bar to add the corewindow parameter with the right link to the CGI.
This way, the location bar will always show a link to the specific view we're looking at right now and can be easily copy and pasted. No more right-click->frames->copy-frame-link dance.

This means we can create a file /usr/share/nagios/html/ssi/common-header.ssi drop some Javascript in there that handles the updates of the location bar and we're done. Awesome. The code needed is super simple:
<script> /* * Update the browser location bar to ensure ?corewindow= always contains the URI * to the current page. * * This allows a reload to reload the same page rather than going back to the main * frameset. */ // Get the current URL of the parent window (assuming the frame is nested within it) var parentUrl = window.parent.location.href; // Get the path of the file from the current URL of the frame var filePath = window.location.pathname; // Remove the first slash from the path name filePath = filePath.substring(1); // Get any query string parameters passed to the file var queryString = window.location.search; // Remove any existing corewindow parameter from the query string queryString = queryString.replace(/(?:&|\?)corewindow=[^&]*&?/g, ''); // Construct the new query string with corewindow as the first parameter var newQueryString = 'corewindow=' + filePath; // Append any existing query string parameters if (queryString) { // Emcode only the '?' and the '&' component of the path. newQueryString += encodeURIComponent('?') + queryString.substring(1).split('&').join('%26'); } // Construct the updated URL with the new query string var updatedUrl = parentUrl.split('?')[0] + '?' + newQueryString; // Replace the URL of the parent window with the updated URL window.parent.history.replaceState(null, null, updatedUrl); </script>

And done, now clicking inside the Nagios interface will update the location bar to URLs such as https://nagios.example.com/nagios/?corewindow=nagios/cgi-bin/extinfo.cgi%3Ftype=2%26host=filer-cluster%26service=fs_%2Fdev%2Fvg%2Barc_vol_000%2Flv%2Bn%2Blvarc_vol_00000 which is a link that opens the fs_/dev/vg+arc_vol_000/lv+n+lvarc_vol_00000 service on the filer-cluster host. Easy to share. Perfect.

Unfortunately, this solution is as close to perfect as we can build it using the shipped functionality, but it's not 100% perfect.

This only works for .cgi files. The main.php file will not load the SSI file and thus it won't update the URL.
Not problematic in the grand scheme of things but a minor nitpic.

Not all .cgis actuall load the SSI files. The map.cgi doesn't.
Also not super problematic because the map is not really used by us. But YMMV.

But overall, still a massive UX improvement.

Further reading:
Other people also have been using the SSI functionality to embed funky Javascript functionality. https://theezitguy.wordpress.com/2015/08/16/nagios-improve-user-experience-with-ssi-and-javascript/ is a good example.

Avocent PM webinterface issues

andreas@dicp.de (andreas) — Sat, 7 Sep 2019 19:27:00 +0200

At bawue.net we are using several Avocent PM 3000 power distribution units to connect our servers.
A nice feature of these PDUs is that they work great with our existing Cyclades console servers.

In addition to the serial console and the SSH interface, these devices also offer a web interface. This interface never worked with Chrome or Chromium where it only shows a blank page. It does however work with Firefox, or so I thought at least.
I recently needed to verify something and found out that with the latest Firefox the webinterface on these devices is now not broken. Empty page, same as with Chrome.

As there is no firmware upgrade, I tried figuring out what is going on.

It turns out, the web interface was written using the JavaScript document.load() function to fetch content from the device. Unfortunately, this function was never standardized, never supported on Chrome or Safari and has by now been removed from Firefox as well.
Bummer!

But thanks to Greasemonkey or Tampermonkey it is possible to make the web interface work again. We just need to provide a document.load() function that uses AJAX/XHR Requests to load data from the device and all is good.

Such a userscript can be found on my public github gist.

dss_cli, an Open-E Data Storage Server command line interpreter

andreas@dicp.de (andreas) — Thu, 16 May 2013 22:15:18 +0200

Introduction

dss_cli is a small command line program written in Python which can serve as the base for automating tasks on the Open-E Data Storage Server. A sysadmin can use it to control regular maintainance from the shell instead of having to log into the web-interface through a browser.
It can access the existing API via SSH and provides missing functionality by interfacing with the web-server on the DSS appliance. It is using both mechanize and Beautiful Soup to make it resiliant to changes in the webinterface. While it was originally written on a DSS v6, initial tests showed that it mostly works on the DSS v7 release as well.

Background

The "Data Storage Server" from Open-E is a linux based software appliance. After installing the software on a server, the server can then offer NAS and iSCSI storage to attached clients and is manageable through a web-interface.

One interesting feature of the appliance is, that it does offer failover for both iSCSI exported block devices as well as for NFS shared folders, something which makes it very interesting for Bawue.Net. The active/passive failover pair should give us better availability for maintenance as one half of the failover pair can be taken down for maintenance without affecting the virtual machines using the filer as a storage.

During testing of the DSS v6 system we did notice however a certain lack of functionality: The webinterface is great to manage the servers, create volumes, export these and set them up for replication. But using the webinterface is a manual process full of repetitive steps while the tasks at hand call for automation to reduce operator errors and to allow configuration through tools like puppet.

In order to help with automation, the DSS appliance offers an API/CLI access via ssh: Generate a key, connect to the server via ssh and pass some commands:
$ ssh -p 22223 -i filer1.key -l api 192.168.2.220 get_driveslist -v Unit Size(GB) Serial Number Status S001 1862.64 4096e40371761527 vg,arc_vol_000 S002 279.40 4096e41532029185 vg,arc_vol_001
Unfortunately, the API is incomplete: It does allow for a lot of automation tasks, it does not export all the functionality to create working failover volumes and destroy them again. If there are plans to use the DSS filer as a storage backend for any kind of automated creation of virtualized servers these functions are sorely needed to prevent the need for manual interaction.

In order to address this lack of functionality, I wrote dss_cli, a command line client aimed at owners and administrators of DSS appliances in order to support all daily administration tasks needed on these filers.

Future plans

Provide a second tool to combine common steps for creation of iSCSI and NAS targets in a cluster.
Otherwise I am also taking nominations for needed functionality.

Installation

The current code is available on GitHub::ixs/dss_cli and is published under the GPLv2. Preqrequisites to running the dss_cli command is a recent Python installation with the Paramiko module for SSH connectivity and mechanize and Beautiful Soup for the web-scraping functionality.
Installation is simple: Download the latest code, unzip it in a new directory and edit config.ini to reflect your environment.
The [failovergroup] section contains your failover pairs, one group per line.
The example below defines one failovergroup called main, containing the dss1 and the dss2 filer.
The [dss1] and [dss2] section define their address, their admin passwords, the ssh_key needed for the API functionality and whether they are the primary or the secondary host in the failover group.

[failovergroups] main = dss1 dss2 [dss1] address = 192.168.220.1 password = admin sshkey = dss1_api.key mode = primary [dss2] address = 192.168.220.2 password = admin sshkey = dss2_api.key mode = secondary

Usage

./dss_cli --help Usage: dss_cli [options] Command Line Interface to interact with an Open-E DSS Storage Server Options: -h, --help show this help message and exit -f FILE, --file=FILE Configuration file to use -l, --list List all commands available -g, --failovergroup List all configured failover groups -d, --debug Use --list to get a list of all supported commands. Each command should support the --help parameter to get a list of accepted arguments.

Running ./dss-cli -l dss1 does give a list of all commands supported on that device:

$ ./dss_cli -l filer1 build - Lists and sets default build. check_mk_agent - Returns information from check_mk monitor create_iscsilv - Creates a logical iSCSI Volume. create_naslv - Creates a logical NAS volume. date - Sets time and date; please use the following format: yyyy-mm-dd hh:mm:ss failover - This function allows you to stop, run or change the operation mode for the given server. failover_task - Manage a failover task get_TXbytes - Returns total number of bytes transmitted for the given interface. get_TXpackets - Returns total number of packets transmitted for the given interface. get_driveslist - Fetches a list of drives. get_hwstatus - Returns information from system hardware monitor. get_memorystatus - Fetches memory status. get_nichealth - Fetches the status of the given Network Interface Card. get_nicslist - Lists Network Interface Cards. get_raidstatus - Returns information about RAID. help - Lists all available methods iscsi_target_access - Configure Target IP access iscsi_target_assign - Assign lv with given name to existing iSCSI target. iscsi_target_create - Creates a new iSCSI target. iscsi_target_list - Lists iSCSI targets (syntax: alias;name). iscsi_target_remove - Remove an existing iSCSI target iscsi_target_restart - Restart iSCSI target service. iscsi_target_sessions - Shows and manages iSCSI target sessions. iscsi_target_status - Lists the parameters of the selected target. iscsi_target_unassign - Unassign from given iSCSI target lvname. lv_remove - Remove a logical volume nas_settings_http - Enables and disables access to shares via HTTP. nas_share_access_afp - Modifies AFP share access. nas_share_access_ftp - Enables and disables access to shares via FTP nas_share_access_http - Enables and disables access to shares via HTTP. nas_share_access_nfs - Enables and disables access to the given share via NFS. nas_share_access_smb - Modifies SMB/AFP share access. nas_share_create - Create share on specified volume. nas_share_details - Display detailed configuration of share nas_share_edit - Changes share location or comment. nas_share_groups - Groups manipulation functions. nas_share_list - Lists shares nas_share_remove - Removes the given share. nas_share_toggle_smb - Enable or disable SMB support for a share nas_share_users - Users manipulation functions. nas_user_add - Create user in the system. nas_user_groups - Adding and removing users to groups. nas_user_remove - Removes the given user from the system. nas_user_rename - Rename NAS user. ntp - Fetches the time and date from an NTP server. reboot - Reboots the system. set_nic - Configures Network Interface Cards. set_powersettings - Sets the power button action scheme. shutdown - Shuts the system down. snapshot_task - Starts and stops snapshots. task - This function allows you to start task. test - Generates an example of a help message. unit_manager - Creates new volume group or adds unit(s) to existing volume group. update - Initiates and checks the status of software update. version - Fetches the software version. volume_group_status - Lists Volume Groups. volume_iscsi_remove - Removes a logical iSCSI volume volume_replication - Adds and removes replication to volume. volume_replication_mode - Set volume replication mode to source or destination volume_replication_remove - Removes replication from Volume volume_replication_task_create - Create a volume replication task volume_replication_task_remove - Remove a replication task volume_replication_task_status - Status of a replication task volume_replication_task_stop - Stop a replication task volume_status - Displays storage info.

Example

The following commands would serve to create a failover iSCSI volume on dss1 and dss2:

Create the logical volumes on both filers as part of the arc_vol_000 volume group. Command line arguments are create_iscsilv <vg_name> <size> blockio
The size argument is specified in 32MB blocks. 150GB * 1024 / 32 = 4800.

$ ./dss_cli filer1 create_iscsilv arc_vol_000 4800 blockio lvarc_vol_00000 $ ./dss_cli filer2 create_iscsilv arc_vol_000 4800 blockio lvarc_vol_00000

Enable volume replication for both logical volumes on both filers and set the logical volume on filer2 to be a secondary volume/replication destination.

$ ./dss_cli filer1 volume_replication add lvarc_vol_00000 $ ./dss_cli filer2 volume_replication add lvarc_vol_00000 $ ./dss_cli filer2 volume_replication_mode lvarc_vol_00000 secondary

Create, start and monitor the replication task on the primary filer and give it 80MBps bandwidth for initial synchronisation.

$ ./dss_cli filer1 volume_replication_task_create lvarc_vol_00000 lvarc_vol_00000 failover_iscsi_target0 80 $ ./dss_cli filer1 task --start VREP failover_iscsi_target0 $ ./dss_cli filer1 volume_replication_task_status failover_iscsi_target0

Create the iSCSI targets on both systems.

$ ./dss_cli filer1 iscsi_target_create target0 $ ./dss_cli filer2 iscsi_target_create target0

Assign the created volume to the just created iSCSI target on both systems. The server will report back with a randomly generated SCSI id for the LUN. Make sure to pass this one when assigning the volume on the secondary system. These ids need to be the same.
$ ./dss_cli filer1 iscsi_target_assign target0 lvarc_vol_00000 lvarc_vol_00000:target0:0:wt:Dgp5VLni08UGb5W5 $ ./dss_cli filer2 iscsi_target_assign target0 lvarc_vol_00000 -s Dgp5VLni08UGb5W5 lvarc_vol_00000:target0:0:wt:Dgp5VLni08UGb5W5

Add the replication task to the list of active failover tasks and make sure that failover services are started.

$ ./dss_cli filer1 failover_task failover_iscsi_target0 enable $ ./dss_cli filer1 failover --start

Contact
Find me as "ixs" on the usual IRC networks. (IRCnet, EFnet, oftc, freenode)

Automatischer Login für Deutsche Telekom Hotspots

andreas@dicp.de (andreas) — Sun, 10 Jun 2012 03:46:48 +0200

Es passiert regelmässiger, dass ich unterwegs bin und dort ein Telekom Hotspot vorhanden ist. Aktuell ist dies z.B. im Novotel Karlsruhe der Fall.

Telekom Hotspots haben wie die meisten öffentlichen Hotspots ein sogenantes Captive Portal durch das die Authentifizierung stattfindet.

Ich bin glücklicher Besitzer einer Telekom Hotspot Flatrate und möchte diesen Account gerne verwenden. Allerdings ist die regelmässig wiederkehrende Authentifizierung sehr nervig. Obwohl der Browser Login und Passwort nicht speichert wäre es dennoch schön wenn diese Anmeldung automatisch geschehen könnte.

Gesagt, getan. Hier ein kleines Python Script dass genau diese Aufgabe übernimmt:

#!/usr/bin/python

import BeautifulSoup, re
from mechanize import Browser

url = 'http://www.bawue.de/checkip.php?simple'
user = 'user@t-online.de'
password = 'secret'

br = Browser()
br.open(url)
response = br.response().read()
#if br.title().startswith('HotSpot'):
if br.geturl().startswith('https://hotspot.t-mobile.net/wlan/'):
print 'HotSpot captive portal detected'

br.select_form(name='f_login')
br['username'] = user
br['password'] = password

br.submit()

if br.geturl() == 'https://hotspot.t-mobile.net/wlan/welcome.do':
print 'Login successful'
print 'Status page: https://hotspot.t-mobile.net/wlan/start.do'

br.open(url)
response = br.response().read().strip()

print 'IP Address: %s' % (response)

else:
print 'Login failure'

else:
print 'Not a Telekom HotSpot'

Liebe Gefährderinnen und Gefährder...

andreas@dicp.de (andreas) — Sat, 21 Feb 2009 17:30:38 +0100

Den üblichen Verächtigen dürfte bekannt sein, dass unsere nicht vertrauenswürdige Familienministerin gerade dabei ist die Weichen für das neue, kindersichere und reingewaschene Internet zu stellen.

Böse Zeitgenossen nehmen gerne das ebenso böse Wort "Zensur" in den Mund und vergessen dabei an die Kinder zu denken. Frau von der Leyens Internetsperren weisen jedoch den richtigen Weg.

Da dies ja ein hauptsächlich technisches Blog ist, hier also ein kleines Rezept für mod_rewrite um Besuchern der eigenen Webseite schonmal einen kleinen Vorgeschmack zu geben auf die Zukunft des deutschen Internets:

RewriteEngine on RewriteCond %{HTTP_REFERER} ![den_eigenen_domainnamen_bitte_hier_einfügen] [NC] RewriteCond %{HTTP_REFERER} !bmi\.pifo\.biz [NC] RewriteRule ^(.*)$ http://bmi.pifo.biz/?http://%{HTTP_HOST}/$1 [R,L]

Sobald dieser Konfigurationsschnipsel in einer .htaccess Datei im Webroot einer Webseite abgelegt wurde, wird die Funktionsweise der bundesdeutschen Filterliste realitätsnah simuliert. Der Besucher wird beim ersten Aufruf einer Webseite auf eine täuschen echte Simulation der STOP Seite für gefährliche Internetangebote umgeleitet.

Sobald er sich von dieser humoristischen Seite auf die eigentlich besuchte Seite durchgeklickt hat, kann er diese jedoch normal durchklicken... Eigetnlich auch nicht anders als die blauen Free-Speech Schleifchen, die man vor vielleicht 12 Jahren überall im Web vorfand.

Ein kleines Beispiel für die in Zukunft sicher regelmäßig auftretenden, jedoch sehr bedauerliche Einzelfällen von Fehlkategorisierungen: blog.vodkamelone.de auf der Sperrliste. :-)

Spass mit OpenSSH

andreas@dicp.de (andreas) — Thu, 4 May 2006 13:03:00 +0200

Aktuell geht wohl gerade das Gerücht um, dass mal wieder ein neuer OpenSSH Exploit im Umlauf ist, für den es noch kein Advisory gibt.
Dem Gerücht zufolge wurde damit wohl ein IRC Server aufgemacht, was , sofern das stimmt, ziemlich unschön ist, weil selbst der dümmste Mensch nicht seine eigene Infrastruktur angreift.
Nur machen das Scriptkiddies wohl regelmässig.

Naja, halten wir uns also mal für ein neues OpenSSH Advisory bereit. Das betreffende Kiddie wollte nicht so viel zum Exploit sagen, ausser:

< scriptkid> but... < scriptkid> SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4 < scriptkid> cannot still fix < scriptkid> advisory is not out :)

UPDATE: Inzwischen hat sich rausgestellt, dass das Scriptkiddie ein wenig übertrieben hat. Nicht ssh war das Problem, sondern Social Engineering führte zum Aufmachen des Servers.
Das freut uns alle nämlich, dass wir unsere Kisten _nicht_ updaten müssen.

Strato als Serverhoster - Ganz ganz schlechte Idee.

andreas@dicp.de (andreas) — Sun, 28 Aug 2005 12:34:00 +0200

Kris hat gerade viel Spass mit Strato. Die Firma hat ohne vorherige Ankündigung seinen Rootserver gesperrt. Er kann zwar noch per Out-of-Band Console von Cyclades darauf zugreifen, aber direkter TCP'/IP Zugriff ist nicht möglich.

Das ist insofern ziemlich unangenehm, da Kris auf der Maschine unter anderem auch den List-Server für FITUG betreibt.
GPF hat das schön zusammengefasst.

Mal davon abgesehen, dass es für Kris ziemlich unangenehm ist, ich halte das für eine absolut katastrophale Methode. Es gab wohl Fälle, da wurde der Server aufgrund einer automatisierten Mail von einem durchgeknallten IDS System gesperrt, dass sich über einen Traceroute beschwerte.
Ansich ist das ein sehr gutes Zeichen, dass man keine Server bei Strato mieten will. Man stelle sich doch mal die potentiellen Umsatzeinbussen vor, wenn Strato am Freitag den Server abschaltet, und man da einen Shop drauf hat, der am meisten Umsatz am Wochenende erzeugt...
Weil am Wochenende is ja keiner da, um den Server wieder freizugeben.
Vollprofis.

Netscape zensiert

andreas@dicp.de (andreas) — Sat, 5 Mar 2005 21:45:54 +0100

JWZ oder besser bekannt als Jamie Zawinski hat eine imposante Auswahl an Rants über Gott und die Welt und Mozilla bzw. Netscape im besonderen.

Das letzte mal habe ich irgendwann '99 oder so reingeschaut und als ich heute mal wieder vorbeischaute habe ich etwas richtig nettes dort gefunden:
Die gesammelten Obzönitäten des Netscape Quellcodes bevor er als Mozilla veröffentlicht wurde und diese Perlen rausgeworfen wurden.

Dort findet man perlen wie void AppleSucks ( void ); oder auch den Standard Kommentar /∗ WHY THE FUCK DOESN'T THIS WORK??????? ∗/.

Sehr amüsant zu lesen jedenfalls.

Gmail Spam

andreas@dicp.de (andreas) — Mon, 21 Feb 2005 20:58:45 +0100

Ich habe hier noch ungefähr 50 GMail Invites rumfliegen, die ich loswerden will bevor ich meinen orkut und den gmail account lösche.

Falls also jemand nen gmail Account will, Name und Mailadresse an ixs[klammeraffe]jabber.bawue.net jabbern oder hier in den Kommentaren hinterlassen. Ansonsten geht auch ixs im ircnet nen query zukommen zu lassen.