ixs' Vodkamelone - Bawue.Net

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.

The missing man page: cyc_ipmicmd - Avocent IPMI power control

andreas@dicp.de (andreas) — Thu, 30 Apr 2015 11:10:38 +0200

Avocent (formerly Cyclades) is a supplier for various datacenter management tools. They are best known for their rackmounted power distribution units and their serial console servers. Both devices run Linux and have been around for years.

Both the now EOL'd devices from Cyclades as well as the newer devices from Avocent can powercycle devices either through a serially attached smart PDU or through IPMI. Every device under the Advanced Console Server (ACS) label can control IPMI devices with a recent firmware.

While the functionality of the attached PDUs is quite well documented, there's no matching documentation for the IPMI interface. The web-interface works but the logic is mostly inside the AcsWeb webserver binary.
There's a cyc_ipmicmd binary but that one doesn't offer any --help functionality to explain how to call it.

For future reference here's the missing man page:

cyc_ipmicmd(1) General Commands Manual cyc_ipmicmd(1) NAME cyc_ipmicmd - utility for power cycling servers via IPMI SYNOPSIS cyc_ipmicmd SERVER COMMAND DESCRIPTION The cyc_ipmicmd utility is a wrapper around /bin/ipmitool which allows to send IPMI power commands such as On, Off, Status and Cycle to configured devices. The server address as well as necessary authentication data is taken from /etc/IPMIServer.conf. CONFIG FILE FORMAT The /etc/IPMIServer.conf file contains the necessary data to successfully send IPMI commands to remote devices. Each line contains one remote server definition with the following colon separated fields: - Numerical server ID (starting at 1) - IP address - Authentication Type (none, password, md2, md5) - Access Level (user, operator, admin) - Username - Password - Alias (human readable name) An example line might look as follows: 1:192.168.0.1:password:operator:user:pass:Example Server: SERVER parameter The server parameter is the numerical server ID taken from the first field of the configuration file. COMMAND parameter The command parameter is numerical code which specifies which command is being sent to the remote IPMI device. 0 Off Poweroff the server 1 On Poweron the server 2 Status Reportpower status 3 Cycle Powercycle the server EXAMPLES: Powercycle the first server: cyc_ipmicmd 1 3 AUTHOR: Andreas Thienemann

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)

Unbricking an Intel Pro/1000 (e1000) network interface

andreas@dicp.de (andreas) — Thu, 16 Oct 2008 23:23:31 +0200

As most readers of this blog are probably aware, pre-releases of the Linux Kernel 2.6.27 are able to trash the NVRAM/EEPROM of certain Intel Network cards. As usual, lwn.net has a nice writeup of the issue including some background information.
I had a similar problem in the past and as a favour for some friends of mine, I've written down a small description to restoring the ethernet firmware in these cards. This guide should serve as a good primer on reflashing your broken nic but probably needs to be adapted for your own use case.

NB: Instead of just giving a command by command description of what I did, I'll try explaining a bit more about the background and the process of fixing the problem at hand. Maybe this gives other people some insight into valuable problem solving skills.

Some years back we bought quite some Tyan S5112 machines for bawue.net.
The idea was to fit these machines with the Tyan m3289 server management card, an IPMI card allowing remotely powercycling of the machines and offering a serial console via the network.

In order to have the whole setup work, the IPMI management module needs support from the network interface in order to receive IP packets while the machine is powered off. After contacting the Tyan support, we were offered a firmware file to flash into the network adapter activating the needed "management mode". This firmware file came in the form of a .bin file and an accompanying eeupdate.exe file for flashing the firmware image.

The mainboard has two ethernet controllers, with the 82547EI one being the controller utilized by the management card. The lspci output on this board looks as follows:
[root@selene ~]# lspci|grep Ethernet 01:01.0 Ethernet controller: Intel Corporation 82547EI Gigabit Ethernet Controller 03:02.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller [root@selene ~]#

The instructions for flashing the firmware were relatively simple: Boot with a DOS bootdisk and execute eeupdate -nic=1 -d 82547EI.eep
After I pressed enter, nothing much happened. The system wasn't reading anything from the disk, there was no progress message on the screen, just the general start-message of the firmware update tool.

When nothing happened after 5 minutes of waiting, I foolishly reset the system. Big mistake!.

On the next boot of the system, there were no PXE messages from the network card and during bootup the e1000 linux driver only threw out the ominous message The EEPROM Checksum Is Not Valid without loading the network interface.
It turns out, I just trashed the firmware of my on-board network interface.
Calling the eeupdate program again did not work as it bailed out because the eeprom was corrupted
At such times, I firmly believe in the use of swearwords accompanied by heavy googling for some advice. Alas, googling told me only that I broke my hardware and needed new one.

As returning hardware because of a problem is akin to giving up, which is generally unacceptable, I decided to look into the issue a bit more and find a workable solution to unbrick the network interface.
To recap, I had the following:

One on-board network interface with a corrupted nvram

One eeprom image for said network interface (For reference: 82547EI.EEP)

No working flash program

No working driver

One working Linux system without network

One working Linux notebook with network

Luckily, the working Linux system and network access is all I needed:

The first step was getting the sources of the e1000 driver from the project page. As this was a few years ago, I chose the version 7.3.15 which was current at this time.

After untaring the sources, a quick grep -R 'The EEPROM Checksum Is Not Valid' e1000-7.3.15 turned up one hit in e1000-7.3.15/src/e1000_main.c:

/* make sure the EEPROM is good */

if (e1000_validate_eeprom_checksum(&adapter->hw) < 0) {
DPRINTK(PROBE, ERR, "The EEPROM Checksum Is Not Valid\n");
err = -EIO;
goto err_eeprom;
}

So there is a function called e1000_validate_eeprom_checksum responsible for checking the validity of the eeprom. During the main initialization of the card this function is called and in case the checksum is not valid, the error handler err_eeprom is executed which aborts the module load.
On a hunch, I removed the whole check logic containted in this function located in e1000-7.3.15/src/e1000_hw.c. After I was done, the whole function body consisted only of a "return 0" statement meaning that the checksum check will always succeed.

Building the modified module by calling make in the src dir resulted in a e1000.ko file which could be loaded into the running kernel by executing "insmod ./e1000". (Note, this will probably not work with current kernels as the buildscripts have changed. Use a current version of the e1000 driver instead.)
To my great relief the driver returned the following message:

Intel(R) PRO/1000 Network Driver - version 7.3.15
Copyright (c) 1999-2006 Intel Corporation.
e1000: 0000:01:01.0: e1000_probe: (PCI:33MHz:32-bit) ff:ff:ff:ff:ff:ff
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: 0000:03:02.0: e1000_probe: (PCI:33MHz:32-bit) 00:e0:81:55:f2:01
e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection

So even though the mac address of the card is broken, at least the card is somewhat detected and I can work on restoring the eeprom.

For modifying low-level settings of network interfaces under Linux one can usually use the fabulous ethtool utility.
Using the -e parameter dumps the eeprom values of the specified network interface onto the screen. This is great for getting a backup of the eeprom:

[root@selene ~]# ethtool -e eth1 | head -n 5
Offset		Values
------		------
0x0000		00 e0 81 55 f2 01 10 02 ff ff 06 20 ff ff ff ff 
0x0010		ff ff ff ff 0b 64 76 10 86 80 76 10 86 80 84 b2 
0x0020		dd 20 22 22 00 00 90 2f 80 23 12 00 20 1e 12 00 
[root@selene ~]#

Even better is the -E parameter as it allows changing a single byte at a specified address in the eeprom:

[root@selene ~]# ethtool -E eth0 magic 0x10198086 offset 0x0 value 0x00
[root@selene ~]#

This command would change the byte at the address 0x0 (the first byte) into the value 0x00. The 0x10198086 value is the "magic" value needed to "unlock" this write operation. Depending on the driver and the card this value is different for each system. In the case of the intel e1000 driver, the magic value is the Device ID and Vendor ID of the selected network card. This value can be gathered by examining the lspci -n output.
As I was in a hurry back then to get the machine working again, I didn't try to find out what exactly the magic value was but just commented out this check in the e1000_ethtool.c file.
For reference, the patch of my modifications to the e1000 driver are e1000-repair.patchdownloadable as a unified diff.

Now, that I could change single values in the eeprom, it was time to take a look at the Tyan provided eeprom file:

[root@localhost root]# head -n 5 82547.eep 
E000 2A81 0855 0A10 FFFF FFFF FFFF FFFF 
FFFF FFFF 640B 1019 8086 1019 8086 B200 
1F35 002A 0E00 0012 0E00 20DD 7777 1F95 
0001 1F73 0098 1F72 3FB0 0009 1200 3649 
00CF 8FA7 290E 0305 0CCA FFFF FFFF FFFF

Comparing this eeprom file with the dump taken earlier from the second network interface in the machine showed that the .eep file from intel was in "mixed-endian" format, meaning I had to shuffle the values around a bit before being able to rewrite the image. The file contains the eeprom values as groups of two bytes each in reversed order. The first four byte-values in the file are 0xe0 0x00 0x2a 0x81 while in the eeprom they would be 0x00 0xe0 0x81 0x2a.

After I found the correct byte ordering, I could simply call ethtool -E manually with the correct addresses and just write each byte into the eeprom or automate this and reduce the possibility of mistakes. Naturally, automation it is. Back then I chose to do this script in PHP as a small exercise in command-line-interface programming.
The PHP script can be downloaded as eepromer.php and executed by calling php eepromer.php on the shell.
In order to explain it's working, the code is printed below:

<?php
$file = "82547.eep";

$handle = {FNAMEL}">fopen($file, "r");
$contents = {FNAMEL}">fread($handle, {FNAMEL}">filesize($file));
{FNAMEL}">fclose($handle);

$tok = {FNAMEL}">strtok($contents, " \n\r");
$eepdata = "";

$i = 0;
while ($tok !== false) {
$eepdata .= {FNAMEL}">substr($tok, 2,2).' ';
$eepdata .= {FNAMEL}">substr($tok, 0,2).' ';
$tok = {FNAMEL}">strtok(" \n\r");
$i++;
}

$tok = {FNAMEL}">strtok($eepdata, " ");
$i = 0;
while ($tok !== false) {
$offset = {FNAMEL}">sprintf("%x", $i);
{FNAMEL}">echo "ethtool -E eth0 magic 0x00 offset 0x$offset value 0x$tok\n";
$tok = {FNAMEL}">strtok(" ");
$i++;
}
?>

At the start, the variable file contains the filename to read in. This file is then opened and read into memory as it is only 6K large. The PHP String Tokenizer function is used to extract the values from the script and the bytes in each extracted group are then swapped around to put them into big endian byte-order. When the eeprom file has been completely parsed the ethtool commands to write the gathered data into the eeprom are printed to STDOUT:

[root@localhost root]# php eepromer.php | head -n 5
ethtool -E eth0 magic 0x00 offset 0x0 value 0x00
ethtool -E eth0 magic 0x00 offset 0x1 value 0xE0
ethtool -E eth0 magic 0x00 offset 0x2 value 0x81
ethtool -E eth0 magic 0x00 offset 0x3 value 0x2A
ethtool -E eth0 magic 0x00 offset 0x4 value 0x55
[root@localhost root]#

By piping the output of this quick-and-dirty script into a shell (php eepromer.php | sh), the content of the .eep file is written for real into the eeprom. The last step is changing the first 6 bytes of the eeprom (offset 0x0 to 0x5) to the original mac address of the network interface.
After this has been done, the network card is considered repaird or unbricked.

Now, this explanation should give anyone some hints on fixing his network card's eeprom should this be needed because of problems with the kernel releases mentioned in the beginning. It is unlikely that following the procedure above to the letter is going to have any usable results as every system and situation is different.
The major problem would be, that not everyone has a working .eep file from Intel available after his own card is trashed. My suggestion would be to look for a friend who has exactly the same card. This can be achieved by using lspci:

[root@selene ~]# lspci | grep Ethernet
01:01.0 Ethernet controller: Intel Corporation 82547EI Gigabit Ethernet Controller
03:02.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller
[root@selene ~]# lspci -n | grep '01:01\.0'
01:01.0 0200: 8086:1019
[root@selene ~]#

If a friend has the same network card as indicated by the Vendor and Device ID (8086 == Intel, 1019 == 82547EI Gigabit Ethernet Controller in my example) he should be able to take eeprom dump by calling ethtool -e [device] > /tmp/eeprom-[device].dump.:

[root@selene ~]# ethtool -e eth0 | head -n 8
Offset		Values
------		------
0x0000		00 e0 81 55 f2 00 10 0a ff ff ff ff ff ff ff ff 
0x0010		ff ff ff ff 0b 64 19 10 86 80 19 10 86 80 00 b2 
0x0020		35 1f 2a 00 00 0e 12 00 00 0e dd 20 77 77 95 1f 
0x0030		01 00 73 1f 98 00 72 1f b0 3f 09 00 00 12 49 36 
0x0040		cf 00 a7 8f 0e 29 05 03 c8 0c ff ff ff ff ff ff 
0x0050		ff ff ff ff ff ff ff ff ff ff ff ff ff ff 02 06 
[root@selene ~]#

This dump file can then be written into your own nvram by an easier procedure then described above. After all, no endianness swapping is necessary as ethtool already returned the data correctly. A bit of reformatting of the import is necessary however but can be accomplished in a simple bash script:

span style="color: #ff0000;">"\n"

This script, which can be written as one single line, will remove the header and other superfluous data from the dumpfile, leaving only the values itself which are then echoed to STDOUT in the form of an ethtool command.

[root@selene ~]# magic=0x0; j=0; for i in `sed -e '1,2d' /tmp/eeprom-[device].dump | cut -c 9- |
tr -d "\n"`; do echo ethtool -E magic $magic offset 0x$(printf %x ${j}) value 0x${i}; j=$(($j + 1)); done | head -n 5
ethtool -E magic 0x0 offset 0x0 value 0x00
ethtool -E magic 0x0 offset 0x1 value 0xe0
ethtool -E magic 0x0 offset 0x2 value 0x81
ethtool -E magic 0x0 offset 0x3 value 0x55
ethtool -E magic 0x0 offset 0x4 value 0xf2
[root@selene ~]#

Piping this into a shell will restore your eeprom meaning only the mac address has to be reverted to the old one. The correct working of the above bash line should be tested however, as the output of ethtool differs depending on the card and the driver.

Should the network interface not even be visible on the PCI bus anymore (possible due to the usage of the ibautil.exe tool mentioned on some webpages) reflashing the main bios might work for some systems. The flashrom utility from the coreboot project might come in handy for this.
Otherwise it might be necessary to rewrite the necessary part of the eeprom first through the SPI, a serial programming interface, in order to have it enumerate again on the pci bus.
Should this be the case, it might be easier to just return your mainboard for repair though.
Should you be willing however, to try your luck and certainly void any little bit of warranty you had left, Intel offers a nice manual explaining the firmware format of it's ICH8 system.

Mein Internetprovider hat jetzt ein blog...

andreas@dicp.de (andreas) — Wed, 2 Jul 2008 20:44:58 +0200

Die Tatsache, dass Mailinglisten inzwischen nicht mehr das Mittel der Wahl zur Kommunikation sind, hat sich mittlerweile auch bei Internet Provider meiner Wahl herumgesprochen.

Die hohe Anzahl von unerwünschten Werbemails verleitet nicht nur mich dazu, einerseits extrem rigeros zu filtern, andererseits dennoch nur noch höchst widerwärtig in meinen E-Mail Client zu schauen.

Was liegt also näher, zur Kommunikation mit den Vereinsmitgliedern - aber auch mit den normalen Benutzern - ein Blog zu verwenden?

Die Wahl fiel auf Serendipity da es sowohl bereits bekannt ist, als auch einen Mehrbenutzermodus anbietet, bei dem verschiedene Personen Einträge bloggen können.

Zu finden ist das ganze unter http://blog.bawue.net. Ein paar Inhalte habe ich auch schon hinzugefügt, warten wir mal ab, ob das Konzept denn auch angenommen wird.

Als Bonus der ganzen Aktion habe ich mittlerweile herausbekommen, wie man ein Serendipity Template schreibt und habe auch wieder Einblick in den Code mancher Plugins gewonnen... Eine lohnenswerte Aktion also...

Using the Canon ScanFront 220/220P with Firefox

andreas@dicp.de (andreas) — Wed, 2 Jan 2008 16:29:16 +0100

We've gotten a new document scanner for bawue.net in order to better handle our documents and our snail-mail communication.
The Canon ScanFront 220P is a network scanner which does (among other things) optical character recognition and is able to send the resulting document as a PDF via e-Mail or upload it to a FTP Server or a SMB Network share.

The device itself is running Windows CE in order to accomplish all that which is fine as it therefore needs no computer connected to it as some other scanners do.

A real problem for the Linux user howerver is that Canon seems to have handed the development of the scanner's web interface to some clueless and moronic developers.
There's simply no excuse for designing a web interface which only works with Internet Explorer and doesn't even allow a Firefox user to log into the interface.
I'd expect MUCH better from a global company such as Canon, especially when the scanner in question costs about US$ 2,150.00

If the device would have been running Linux and the sources would have been delivered as requested by the GPL I'd have a working scanner here and Canon's development team would have had a nice unified diff in the mail fixing their problems. That way, all they are getting is an acrid mail.
Another reason to favour open source operating systems for any development work. Some companies seem to clearly get this.

In the meantime tough I need a working scanner. Greasemonkey to the rescue: I've written a small GPL3 licensed Greasemonkey User script fixing the problems in the ScanFront webinterface. Naturally, one has to have greasemonkey installed to use this script.

It currently fixes the login prompt, makes the "New User" button work, fixes an onload-recursion in the address book and makes the job-control window work when selecting the destination address for a scanjob.
Most of these problems stem from the fact that the Internet Explorer XML parser seems to be somewhat sloppy and does not make a difference by getElementById and getElementsByName.
My userscript works around these issues but a real fix can only be delivered by Canon.

Fun with vmware-server

andreas@dicp.de (andreas) — Thu, 4 Jan 2007 14:23:00 +0100

I tried the free as in beer vmware-server on our new quad opteron and probably got exactly what I deserved when using tainted modules. :-)

general protection fault: e040 [1] SMP
<Jan/04 01:48 am>last sysfs file: /class/scsi_host/host0/stats
<Jan/04 01:48 am>CPU 0
<Jan/04 01:48 am>Modules linked in: ipmi_devintf ipmi_si ipmi_msghandler vmnet(U) vmmon(U) ipv6 
ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables
x_tables video sbs i2c_ec i2c_core button battery asus_acpi ac parport_pc lp parport st sg e100
serio_raw pcspkr ide_cd k8_edac mii cdrom edac_mc floppy tg3 shpchp dm_snapshot dm_zero dm_mirror
dm_mod sym53c8xx scsi_transport_spi 3w_9xxx sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
<Jan/04 01:48 am>Pid: 2317, comm: vmware-vmx Tainted: P      2.6.18-1.2747.el5xen #1
<Jan/04 01:48 am>RIP: e030:[<ffffffff88395db1>]  [<ffffffff88395db1>] :vmmon:Task_Switch_S1B1+0x183/0x976
<Jan/04 01:48 am>RSP: e02b:ffff8801e79c7bb8  EFLAGS: 00010282
<Jan/04 01:48 am>RAX: ffff820000000000 RBX: ffffc2000003d000 RCX: 000000000000e040
<Jan/04 01:48 am>RDX: ffff82000000e040 RSI: 0000000000000000 RDI: ffff8801e9bf6000
<Jan/04 01:48 am>RBP: 00002aaaada80a80 R08: 7fffffff00000001 R09: 0000000000000000
<Jan/04 01:48 am>R10: ffff8801e79c7e98 R11: 0000000000000048 R12: ffffffff8058e000
<Jan/04 01:48 am>R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000660
<Jan/04 01:48 am>FS:  00002aaaada80a80(0000) GS:ffffffff8058e000(0063) knlGS:0000000000000000
<Jan/04 01:48 am>CS:  e033 DS: 002b ES: 002b
<Jan/04 01:48 am>Process vmware-vmx (pid: 2317, threadinfo ffff8801e79c6000, task ffff8801ee6fd040)
<Jan/04 01:48 am>Stack:  736282f99c4145dc  000000009d53f5e8  ffff8801e9bf6000  0000000000000246
<Jan/04 01:48 am> 000000008005003b  00002aaaabb65290  00000000b41c1cc3  0000006300005eaf
<Jan/04 01:48 am> 820000000000efff  ef980ea576c5ffff
<Jan/04 01:48 am>Call Trace:
<Jan/04 01:48 am> [<ffffffff883994eb>] :vmmon:Vmx86_RunVM_S1B1+0x3f/0x1a8
<Jan/04 01:48 am> [<ffffffff8838c21e>] :vmmon:__LinuxDriver_Ioctl+0x387/0xd35
<Jan/04 01:48 am> [<ffffffff8027f6f0>] __wake_up_common+0x3e/0x68
<Jan/04 01:48 am> [<ffffffff8022e141>] __wake_up+0x38/0x4f
<Jan/04 01:48 am> [<ffffffff80260729>] _spin_lock_irqsave+0x9/0x14
<Jan/04 01:48 am> [<ffffffff802976dd>] futex_wake+0xc6/0xd5
<Jan/04 01:48 am> [<ffffffff803045f9>] avc_has_perm+0x43/0x55
<Jan/04 01:48 am> [<ffffffff8838daf7>] :vmmon:LinuxDriver_Ioctl+0x529/0x583
<Jan/04 01:48 am> [<ffffffff8030512d>] inode_has_perm+0x56/0x63
<Jan/04 01:48 am> [<ffffffff803045f9>] avc_has_perm+0x43/0x55
<Jan/04 01:48 am> [<ffffffff8026a78d>] monotonic_clock+0x35/0x7b
<Jan/04 01:48 am> [<ffffffff803051ce>] file_has_perm+0x94/0xa3
<Jan/04 01:48 am> [<ffffffff8838db74>] :vmmon:LinuxDriver_CompatIoctl+0x23/0x36
<Jan/04 01:48 am> [<ffffffff802d7230>] compat_sys_ioctl+0xc5/0x2b1
<Jan/04 01:48 am> [<ffffffff8025d54d>] ia32_sysret+0x0/0xa
<Jan/04 01:48 am> [<ffffffff8025d4e2>] ia32_syscall+0x1e/0x6b


<Jan/04 01:48 am>Code: 0f b6 42 05 83 e0 0f 83 f8 0b 75 0c 8a 42 05 83 e0 f0 83 c8
<Jan/04 01:48 am>RIP  [<ffffffff88395db1>] :vmmon:Task_Switch_S1B1+0x183/0x976
<Jan/04 01:48 am> RSP <ffff8801e79c7bb8>
<Jan/04 01:48 am> <0>Kernel panic - not syncing: Fatal exception
<Jan/04 01:48 am> (XEN) Domain 0 crashed: rebooting machine in 5 seconds.

I fear I'll have to look into xen a bit more and use that in the meantime.

UPDATE: Turns out, it's currently impossible to do what I want:

Xen and VMware are impossible to run at the same time
Running ia32 guest inside of a x86_64 Xen instance does not work. It seems to be a planned feature though.
qemu is slow and the binary kernel accelerator does not work on x86_64

I guess I'll just have to disable Xen for now and go with vmware until I have new hardware for the soon to be virtualized host. :(

Zurücksetzen eines Elmeg VoIP-VPN Gateway

andreas@dicp.de (andreas) — Fri, 7 Jul 2006 15:41:00 +0200

Für die Elmeg ICT-Serie von Telefonanlagen gibt es ein sogenanntes VoIP-VPN Gateway, dass der Telefonanlage SIP Fähigkeiten beibringt.

Die interessanten Features des Moduls sind:

Nutzung von maximal 10 SIP Providern als "Amtsleitung"
Anschluss von SIP-fähigen Telefonen als interne Nebenstelle
IPSec VPN Verbindungen
- Voice-over-VPN möglich um externe Telefone als interne Nebenstelle zu nutzen
- Zusammenschaltung von mehreren dieser Telefonanlagen über VPN Verbindungen um z.B. Niederlassungen günstig an das Hauptbüro anzuschliessen.
Router Funktion
- Mini Switch mit 3 internen Ports und einem WAN Anschluss.
- Internetzugang über PPPoE, ISDN und PPtP, DHCP etc. möglich
- Interner DHCP Server
- Stateful Inspection Firewall oder Packet Filter
- IP-Masquerading/NAT
- RAS-Server und -Callback
- Netzwerkweite LAN-CAPI Funktionalität

Diese Features können realisiert werden, da das VoIP-VPN Gateway ein modifizierter Bintec Router ist.

Das schöne daran ist, dass die Telefonanlage deswegen einen Telnet-Daemon laufen hat und man sich dort mit dem Login "admin" und dem Passwort "fec" einloggen kann und somit das Gerät wesentlich umfangreicher konfigurieren kann als über die vorgesehenen Windows Administrations Tools der Telefonanlage. z.B. für ordentliche IPSec Konfiguration ist das notwendig, oder wenn man Portforwardings aktivieren will.
Das unschöne ist, dass man die Konfiguration über Telnet so sehr vermurksen kann, dass das Gerät nicht mehr viel macht und sich direkt aufhängt.
Bei mir ging zwar noch der Login per telnet, aber sollte man dann versuchen "setup" oder einen anderen Befehl an der Shell einzugeben, so war erstmal Schluss.

Der Funkwerk Support kennt in dem Fall die einfache Lösung, wie man das Problem beseitigen kann: Einschicken, wir reparieren das dann.

Danke, aber das war die falsche Antwort.

Aber es gibt ja genügend Stecker auf dem Board, einer wird schon helfen.

"Zurücksetzen eines Elmeg VoIP-VPN Gateway" vollständig lesen

Spass mit der Rittal CMC-TC PUII

andreas@dicp.de (andreas) — Thu, 29 Jun 2006 14:15:00 +0200

[Note to english speaking readers, aggregating this blog: The following article is written in german about gaining root on a piece of embedded server monitor hardware from Rittal and configuring ssh access. If there is demand, I'll translate this article in english as well.]

Ich hatte zuvor ja schon hier und hier ein wenig über das Rittal CMC-TC System gesprochen, dass wir verwenden um unseren Serverschrank zu überwachen.

Das System selber ist soweit ja sehr schön, und hat auch ein paar nette Features, aber leider fehlt z.B. der ssh Zugang. Telnet anzubieten ist doch schon ein wenig schwach heutzutage. Das ganze wäre ja kein Problem, würde Rittal sich an die GPL Lizenz halten, und mir den Sourcecode und die Buildumgebung zur Verfügung stellen, die gebraucht wird um sich einen eigenen sshd zu installieren.
Nunja, mal schauen was das noch wird.

Nun will ich aber dennoch einen ssh Daemon auf dem Gerät haben, was sich auch nicht als sonderlich kompliziert rausstellt. Man muss das Gerät nur booten und den vorhandenen sshd starten.

Aber fangen wir vorne an.

Schauen wir uns also mal die Bootmeldungen an:

U-Boot 1.1.3 (Jun  8 2005 - 15:08:40)

U-Boot code: 20F00000 -> 20F1A868  BSS: -> 20F1EE48
RAM Configuration:
Bank #0: 20000000 16 MB
Board: CMC-PU2 (Rittal GmbH)
Flash:  8 MB
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
no DHCP
## Booting image at 10030000 ...
   Image Name:   ARM Linux-2.4.27
   Created:      2005-04-22   4:52:03 UTC
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    698499 Bytes = 682.1 kB
   Load Address: 20008000
   Entry Point:  20008000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel ...

Linux version 2.4.27-vrs1 (mkr@s020403) (gcc version 2.95.4 20010319 (prerelease/franzo/20011204)) #2
     Fri Apr 22 06:49:12 CEST 2005
CPU: Arm920Tid(wb) revision 0
Machine: ATMEL AT91RM9200
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/mtdblock3 ro ethaddr=00:d0:93:12:34:56 ip=192.168.0.190::::
     CMC-TC-PU2::off console=ttyS0,9600
mtdparts=cmc_pu2:128k(uboot)ro,64k(environment),768k(linux),4096k(root),-
Calibrating delay loop... 89.70 BogoMIPS
Memory: 16MB = 16MB total
Memory: 14452KB available (1382K code, 275K data, 60K init)
Dentry cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
CPU: Testing write buffer: pass
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications AB.
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
 Amd/Fujitsu Extended Query Table v1.3 at 0x0040
number of CFI chips: 1
cfi_cmdset_0002: Disabling fast programming due to code brokenness.
Creating 5 MTD partitions on "CMC PU2 flash":
0x00000000-0x00020000 : "uboot"
0x00020000-0x00030000 : "environment"
0x00030000-0x000f0000 : "linux"
0x000f0000-0x004f0000 : "root"
0x004f0000-0x00800000 : "Partition_004"
i2c-core.o: i2c core module version 2.6.1 (20010830)
i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830)
ttyS0 at MMIO 0xfefc0000 (irq = 6) is a AT91_SERIAL
ttyS1 at MMIO 0xfefc4000 (irq = 7) is a AT91_SERIAL
ttyS2 at MMIO 0xfefc8000 (irq = 8) is a AT91_SERIAL
ttyS3 at MMIO 0xfefcc000 (irq = 9) is a AT91_SERIAL
ttyS4 at MMIO 0xfefff200 (irq = 1) is a AT91_SERIAL
eth0: Link now 100-FullDuplex
eth0: AT91 ethernet at 0xfefbc000 int=24 100-FullDuplex (00:d0:93:12:34:56)
eth0: Davicom 9196 PHY (Copper)
AT91 Watchdog Timer enabled (5 seconds)
Found AT91 i2c
I2C: RS5C372 RTC driver successfully loaded
CMC buzzer driver $Revision: 0.2 $
CMC digital IO driver $Revision: 0.2 $
Serial driver version 0.03 (2004-12-17) with no serial options enabled
ttyS5 at 0xc2084000 (irq = 29) is a TI16752
ttyS6 at 0xc2086000 (irq = 30) is a TI16752
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
eth0: Link now 100-FullDuplex
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
      device=eth0, addr=192.168.0.190, mask=255.255.255.0, gw=255.255.255.255,
     host=CMC-TC-PU2, domain=, nis-domain=(none),
     bootserver=255.255.255.255, rootserver=255.255.255.255, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NetWinder Floating Point Emulator V0.97 (double precision)
VFS: Mounted root (cramfs filesystem) readonly.
Freeing init memory: 60K
serial console detected.  Disabling virtual terminals.
init started:  BusyBox v0.60.2 (2002.10.10-17:17+0000) multi-call binary
eth0: ROVR error
eth0: ROVR error
Startup CMC
no update..
CMC Applications
rs422, Version: V2.00, Build Date: Mon Sep 19 18:01:58 2005
eeprom, Version: V2.00, Build Date: Mon Sep 19 18:00:03 2005

rs232, Version: V2.00, Build Date: Mon Sep 19 18:39:00 2005

CMC-TC-PU2 Thu Jan 1  1970 00:00:15, User 0
CMC-TC-PU2 login: VCC status = OK
cmc_main, Version: V2.15, Build Date: Wed Nov 16 15:20:38 2005
No Options..

Setting up clock 18:03:30 15.06.2006

CMC-TC-PU2 Thu Jun 15  2006 18:03:35, User 0
CMC-TC 192.168.0.190 login:

Eindeutig. Ein Linux mit einer BusyBox Shell. Eine im Embedded-Bereich sehr verbreitete Kombination. In diesem Fall leider ein Lizenzverstoss.

Jetzt stellt sich die Frage, wie man root wird. Als Login hat man naemlich nur cmc und admin zur Verfügung, die beide normale Useraccounts sind und anstelle einer Shell ein fertiges Menü starten.

Im Nachhinein, nachdem man sich auf dem Gerät umgeschaut hat, fallen mir verschiedene Möglichkeiten ein, aber die einfachste ist dem Bootloader zu sagen, dass ich gerne eine Shell hätte.
Mehr Details gibt es im Rest des Artikels.

"Spass mit der Rittal CMC-TC PUII" vollständig lesen

Sesam öffne dich per SNMP

andreas@dicp.de (andreas) — Mon, 10 Oct 2005 15:19:16 +0200

In Ein Heim für Server hatte ich ja bereits auf die Türsteuerung per SNMP verwiesen.

Hier ist mal ein kleiner Hack, wie sich sowas in PHP realisieren lässt.

"Sesam öffne dich per SNMP" vollständig lesen

Ein Heim für Server

andreas@dicp.de (andreas) — Thu, 6 Oct 2005 16:25:00 +0200

Manche von Euch, die mich im RL kennen, werden es schon wissen: Bawue.Net, der beste Internetprovider von Welt, hat sich vor kurzem ein neues Rack geordert.
Da das nicht alle Tage vorkommt, lässt man sich natürlich nicht lumpen, und nimmt gleich mal mit eines mit der besseren Ausstattung.

Das hier rechts ist es. Ein Rittal TS8 Modell in den Traummassen 80cm Breite, 100cm Tiefe und 2200cm Höhe. Damit passt selbst unsere StorageTek DLT-Library hinein, die ja ein wenig länger ist und unsere beiden Cyclades PM 20i an der Seite.

Das besonders schicke an dem Schrank ist die Schranküberwachung von Rittal:
Das Gerät ganz oben im Schrank sind drei CMC-TC Einheiten, die mehrere Temperatursensoren und einen Rauchmelder überwachung und gleichzeitig auch die Schranktüren und Seitenteile überwachen.
Werden die Türen geöffnet oder die Sensoren bemerken eine zu hohe Temperatur oder sollte der Rauchmelder anschlagen (bitte nicht), so kann je nach Konfiguration Alarm ausgelöst werden, alle Verbraucher abgeschaltet werden oder eine optionale Racklöschung angeschaltet werden. Die Racklöschung in 3HE wollten wir dann aber doch nicht mehr haben, schliesslich ist sie bei den Gittertüren verlorene Liebesmühe.

Besonders praktisch an dem CMC-TC System ist, dass man über ein WebInterface oder SNMP Befehle die Türen entriegeln kann, und dann ohne Schlüssel an den Schrank herankommt.
Der Befehl dafür lautet wie folgt: "snmpset -v 1 -c $community $ip unit1OutputSet.2 i 3" zum Öffnen der vorderen Tür und entsprechend "snmpset -v 1 -c $community $ip unit1OutputSet.5 i 3" zum Öffnen der hinteren Tür.

Beim seriellen Zugriff auf das Gerät begrüsst einen netterweise ein Linux mit BusyBox. Ich habe gleich mal bei Rittal angefragt, woher ich denn die Sourcen bekomme, weil mir telnet ein wenig unangenehm ist für den Netzwerkzugriff. SSH mit dropbear wäre schon angebracht.

Mal abwarten wie die Reaktion ist. Dementsprechend kann ich immer noch auf GPL etc. verweisen.

Büromöbel

andreas@dicp.de (andreas) — Tue, 17 May 2005 20:41:49 +0200

Heute war ich einkaufen. Und zwar 8 Stühle und einen Konferenztisch (Fotos gibt es dann wenn die Teile geliefert sind) für das Bawue.Net Büro.

Erschreckend fand ich, dass von den ungefähr 80 verschiedenen Stuhmodellen, die für einen Konferenztisch geeignet sind (also keine Rollen, kein "Chefsessel", kein Fuß in Sternform, nicht drehbar etc.) nur *ein einziges* Modell annehmbar war.

Das fängt an bei der wohl aktuellen Unsitte Stühle mit einer halbhoen Lehne zu fertigen und endet bei garantierten Rückenschmerzen.

Update: Jetzt mit Foto

"Büromöbel" vollständig lesen

b0rken openldap back-sql templates for MySQL

andreas@dicp.de (andreas) — Thu, 5 May 2005 18:26:15 +0200

If one is testing the sql backend functionality of openldap in connection with a MySQL Database, it is likely that slapd will not start. The following error can be observed when starting slapd with debugging enabled by using the -d 1 parameter:

backsql_load_schema_map(): error executing at_query:
Return code: -1
   Native error code: 1054
   SQL engine state:  S0022
   Message:           [unixODBC][TCX][MyODBC]
                      Unknown column 'sel_expr_u' in 'field list'
==>backsql_free_db_conn()
backsql_free_db_conn(): closing db connection

This error appears as the MySQL Templates shipped with openldap 2.2 are broken and have been so for quite some time. :-(

The short workaround ist adding the sel_expr_u row to your ldap_attr_mappings table as follows:

ALTER TABLE `ldap_attr_mappings` ADD `sel_expr_u` VARCHAR( 255 ) AFTER `sel_expr` ;

However, there are more problems...

"b0rken openldap back-sql templates for MySQL" vollständig lesen