ixs' Vodkamelone - Unix

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)

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'

A little shell spinner

andreas@dicp.de (andreas) — Tue, 13 Sep 2011 11:03:05 +0200
Sometimes you want to see if a connection to a remote system is still alive or you just want to keep it alive by transmitting some data. I've found the following little shell one-liner to be quite useful:
$ while true; do for i in '|' '/' '-' '\'; do echo -n $i; sleep 0.25; echo -ne '\b'; done; done
This will create a little ascii spinner and keep a line spinning until you press CTRL-C.

Monitoring a Snom phone with MRTG through SNMP

andreas@dicp.de (andreas) — Fri, 28 Jan 2011 10:58:57 +0100

Snom is the maker of pretty decent VoIP phones running Linux. I have had a Snom 360 for some time now and am reasonably happy with it.

The Snom phones do support SNMP but their SNMP daemon is severly limited. It only supports GETs on a small number of OIDs, doesn't support WALK and standard MIBs like the system-MIB are not supported. The Snom Wiki has a list of the supported OIDs and a description how to enable SNMP on the phones.
The limited support makes autodetection by network management systems or MRTG's cfgmaker fail. In order to chart this data, a manually created template is therefore needed.

Traffic Monitoring (bytes) a Snom Phone
The Snom phone exports all it's interfaces aggregated. This means all vlans and locally generated traffic. The only traffic not exported is the traffic generated on the loopback interface and the traffic bypassing the phone completely via the internal switch. The latter means that the traffic of the machine connected to the PC/passthrough port is not monitored. The MRTG template to chart the incoming and outgoing bytes is the following. The IP Address 192.168.2.124 would have to be changed, as well as the descriptive details.

######################################################################
# System: Snom360
# Description: Snom VoIP Phone
# Contact: System Administration <root@localhost>
# Location: Amsterdam, The Netherlands
######################################################################

### Interface Net >> Descr: 'Net' | Name: 'Net Port' | Ip: '192.168.2.124' | Eth: '' ###

Target[192.168.2.124_Net_byte]: 1.3.6.1.2.1.7526.2.1.1&1.3.6.1.2.1.7526.2.2.1:public@192.168.2.124
RouterUptime[192.168.2.124_Net_byte]: 1.3.6.1.2.1.7526.2.8:public@192.168.2.124
SetEnv[192.168.2.124_Net_byte]: MRTG_INT_IP="" MRTG_INT_DESCR="Net"
MaxBytes[192.168.2.124_Net_byte]: 12500000
Title[192.168.2.124_Net_byte]: Traffic Analysis for Net -- 192.168.2.124
PageTop[192.168.2.124_Net_byte]: <h1>Traffic Analysis for Net -- 192.168.2.124</h1>
<div id="sysdetails">
<table>
<tr>
<td>System:</td>
<td>192.168.2.124 in Amsterdam</td>
</tr>
<tr>
<td>Maintainer:</td>
<td>root@localhost</td>
</tr>
<tr>
<td>Description:</td>
<td>Net Port</td>
</tr>
<tr>
<td>ifType:</td>
<td>ethernetCsmacd (6)</td>
</tr>
<tr>
<td>Max Speed:</td>
<td>100.0 Mbits/s</td>
</tr>
</table>
</div>

Traffic Monitoring (packets) a Snom Phone
The setup to monitor packets is basically the same as for traffic. MRTG can do this out of the box and only needs labels changed.

######################################################################
# System: Snom360
# Description: Snom VoIP Phone
# Contact: System Administration <root@localhost>
# Location: Amsterdam, The Netherlands
######################################################################

### Interface Net >> Descr: 'Net' | Name: 'Net Port' | Ip: '192.168.2.124' | Eth: '' ###

Target[192.168.2.124_Net_pkts]: 1.3.6.1.2.1.7526.2.1.2&1.3.6.1.2.1.7526.2.2.2:public@192.168.2.124
RouterUptime[192.168.2.124_Net_pkts]: 1.3.6.1.2.1.7526.2.8:public@192.168.2.124
SetEnv[192.168.2.124_Net_pkts]: MRTG_INT_IP="" MRTG_INT_DESCR="Net"
MaxBytes[192.168.2.124_Net_pkts]: 10000000
Title[192.168.2.124_Net_pkts]: Traffic Analysis (packets) for Net -- 192.168.2.124
YLegend[192.168.2.124_Net_pkts]: Pkts per Second
Legend1[192.168.2.124_Net_pkts]: Avg Input Unicast Packets
Legend2[192.168.2.124_Net_pkts]: Avg Output Unicast Packets
Legend3[192.168.2.124_Net_pkts]: Maximal Input Unicast Packets
Legend4[192.168.2.124_Net_pkts]: Maximal Output Unicast Packets
LegendI[192.168.2.124_Net_pkts]:  ifInUcastPkts: 
LegendO[192.168.2.124_Net_pkts]:  IfOutUcastPkts: 
ShortLegend[192.168.2.124_Net_pkts]: p/s
PageTop[192.168.2.124_Net_pkts]: <h1>Traffic Analysis (packets) for Net -- 192.168.2.124</h1>
<div id="sysdetails">
<table>
<tr>
<td>System:</td>
<td>192.168.2.124 in Amsterdam</td>
</tr>
<tr>
<td>Maintainer:</td>
<td>root@localhost</td>
</tr>
<tr>
<td>Description:</td>
<td>Net Port</td>
</tr>
<tr>
<td>ifType:</td>
<td>ethernetCsmacd (6)</td>
</tr>
</table>
</div>

Some other values worth charting could be CPU load and free memory or the number of registered extensions. This could be useful for tracking down errors. Unfortunately, mrtg is unable to chart this correctly out of the box and needs some help converting the data.
This is therefore left as an excercise to the reader.

VirtualBox USB support on Fedora. The right way.

andreas@dicp.de (andreas) — Sun, 7 Nov 2010 14:08:29 +0100

The proprietary version of Oracle VirtualBox does offer USB support.
This means that the guest operating system can access USB devices plugged into the host system.

This USB passthrough feature is also available with many other desktop virtualization solutions, e.g. KVM and Qemu. Nevertheless it seems VirtualBox is favoured by a large number of users who are installing VirtualBox only to find that they cannot actually make their USB devices visible to the guest operating system. The common problem seems to be that they checkboxes next to the devices are grayed out, preventing the user from marking them to be added to the guest.

There are a large number of forum articles and blog posts available which all claim to have a solution to the issue. Very often the suggested solution is to change the mount options for /proc/bus/usb in fstab or add an appropriate entry. Sometimes it is suggested to mount usbdevfs to /sys/bus/usb/drivers. Some report success by editing certain udev rules so that files the in the procfs belong to the user executing the VirtualBox binary.

All these solutions have one thing in common:
They are all wrong!
The fact that they are mindlessly repeated by posters in a large number of user-centric web forums does not help at all.
It is still wrong!
I said it before but it still is true: Web forums are full of cargo-cult users: No idea what they are doing but trying and talking about it in the hope that it will achieve something.

The right solution is actually very simple. All that is needed is to add the user running VirtualBox to the vboxusers group:
[root@minos ~]# usermod -a -G vboxusers athienemann [root@minos ~]# groups athienemann athienemann : athienemann vboxusers [root@minos ~]#

That's all. The user athienemann now can add and remove USB devices from VirtualBox guests.
Wasn't that easy? No fiddling with udev or fstab needed.

BTRFS und die Lizenz...

andreas@dicp.de (andreas) — Mon, 27 Jul 2009 00:20:33 +0200

Mein geschätzter Kollege Kris schreibt etwas über Unix und Standards. Neben der Tatsache dass das schöne an Standards ist, dass es so viele gibt und man sich einen aussuchen kann, erwähnte Kris auch die Befürchtung dass BTRFS möglicherweise relizensiert werden könnte.

Die Gefahrt dass BTRFS relizensiert wird besteht nicht.
Zwar wurde die BTRFS Entwicklung bzw. der BTRFS-Haupt-Entwickler durch Oracle finanziert, der Code selber befindet sich jedoch mittlerweile im Upstream-Tree des Kernels. Damit gilt die GPL2 und diese Lizensierung kann nachträglich nicht geändert werden.
Eine andere Lizenz würde nur für zukünftige Versionen relevant sein.

In diesem Fall kann die relizensierte Version als Fork angesehen werden und die bekannten Probleme kommen dann zur Geltung.
Der Spruch mit Eiche und Sau dürfte in diesem Fall nicht unangebracht sein.
Passend dazu hat die aktuelle Ausgabe der Linux Weekly News eine schöne Erklärung der technischen Features und der Architektur von BTRFS und erklärt nebenbei die Entstehungsgeschichte und warum es viel besser ist als ZFS.

Installing OpenWrt on a Microtik Routerboard RB433

andreas@dicp.de (andreas) — Thu, 13 Nov 2008 23:56:00 +0100

A friend of mine wanted a small embedded linux router. After evaluating several options such as Routerboard, Soekris or ALIX systems, he decided to get himself a Microtik Routerboard 433.

The RB433 is a small MIPS board based on the Atheros AR7100 chipset with a 300MHz CPU, 64MB RAM, 3 100Base-TX ethernet ports and three slots for MiniPCI Cards.

The Routerboard manufacturer Microtik delivers these systems with a software called "RouterOS". I haven't looked any closer at it but it seems to be Linux based system with some proprietary userspace management applications. RouterOS seems mostly to be just a Nortel-ish command line interface and a fugly webinterface. Some people claim that RouterOS is kinda nifty, but it's definitely not hackable enough considering the plans my friend had with his device.

To solve his dilemma, we did what everyone else does in a similar situation, we put a real Linux on it:
OpenWrt to the rescue!

Getting to know the Routerboard

When connecting the power to the Routerboard, the system beeps after a short time and outputs some status messages to the serial port. In order to read these, one has to connect to the serial port via a serial crossover cable and use a terminal program.

Minicom is one such terminal program. Personally though, I prefer cu from the uucp package as it is rather lightweight. All one has to type is cu -l ttyS0 -s 115200 and the bootup messages from the routerboard connected to COM1 will be visible. If you're using any other terminal program, the console settings are the usual 115200bps, 8 data bits, No parity bits and 1 stop bit.

RouterBOOT booter 2.15 RouterBoard 433 Authorization: Passed CPU frequency: 300 MHz Memory size: 64 MB Press any key within 2 seconds to enter setup

Now is a good time to press any key to enter the setup mode in order to see what the device can do.
You'll be presented with the following screen:

RouterBOOT-2.15 What do you want to configure? d - boot delay k - boot key s - serial console o - boot device u - cpu mode f - cpu frequency r - reset booter configuration e - format nand g - upgrade firmware i - board info p - boot protocol x - exit setup your choice:

Change the bootmode to tell the device _not_ to boot from the local flash chip (called NAND) but from the network. To do that, press "o" and "e".
Afterwards press "x" to leave the setup.
The device will try to boot and get its kernel from the network.

RouterBOOT booter 2.15 RouterBoard 433 Authorization: Passed CPU frequency: 300 MHz Memory size: 64 MB Press any key within 2 seconds to enter setup trying dhcp protocol........................................................... kernel loading failed

So it seems the device is looking for a kernel.
Let's build one for it to boot sucessfully from...

Building OpenWrt Kamikaze

In order to correctly install the OpenWrt system a linux host is needed to build the kernel image on. I've been using Fedora 9 from the Fedora Project which did the job perfectly. Any other recent distribution should work equally well.

First, check out the current development code via Subversion to have the greatest and latest code:
[athienem@localhost ~]$ mkdir ~/openwrt [athienem@localhost ~]$ cd ~/openwrt [athienem@localhost openwrt]$ svn co https://svn.openwrt.org/openwrt/trunk/ [...] Updated to revision 13193. [athienem@localhost openwrt]$

In order to install the system correctly we'll be needing two different OpenWrt images:
One image is a JFFS2 or SquashFS image to install onto the target device.
The other image is the so called ramdisk image which can be booted over the network and contains a minimal shell. This image will be used to install the JFFS2 or SquashFS image onto the device and will never again be used. Think of it as a "rescue image".

Both images are basically built the same way.
First, change to the svn checkout directory called trunk and execute make menuconfig to configure the OpenWrt image.

[athienem@localhost openwrt]$ cd trunk/ [athienem@localhost trunk]$ make menuconfig

This command will start the ncurses interface to generate a .config file. It should look familiar to people having built kernels before.
Make sure that "Atheros AR71xx [2.6]" is selected as the target system:

This will make sure that the resulting kernel is bootable on the Routerboard 433.

The next step is to select the target image format, chose ramdisk for now:

Now select "< Exit >" in the main menu and confirm that you want to save your new OpenWrt configuration.

The next step is to actually build the image by calling "make
*** End of OpenWrt configuration. *** Execute 'make' to build the OpenWrt or try 'make help'. [athienem@localhost trunk]$ make Checking 'working-make'... ok. Checking 'case-sensitive-fs'... ok. Checking 'working-gcc'... ok. Checking 'working-g++'... ok. Checking 'ncurses'... ok. Checking 'zlib'... ok. Checking 'gawk'... ok. Checking 'bison'... ok. Checking 'flex'... ok. Checking 'unzip'... ok. Checking 'bzip2'... ok. Checking 'patch'... ok. Checking 'perl'... ok. Checking 'wget'... ok. Checking 'gnutar'... ok. Checking 'autoconf'... ok. Checking 'non-root'... ok. Collecting target info: done Collecting package info: done Checking 'bison'... ok. Checking 'automake'... ok. make[2] tools/install [...] make[2] target/install make[3] -C target/linux install make[2] package/index [athienem@localhost trunk]$

Everything went fine and there should be a ramdisk image in elf format:
[athienem@localhost trunk]$ ls -all bin/openwrt-ar71xx-vmlinux-initramfs.elf -rwxrwxr-x 1 athienem athienem 3735060 2008-11-13 22:27 bin/openwrt-ar71xx-vmlinux-initramfs.elf [athienem@localhost trunk]$

The next step is to build the system image to be installed on the device. Execute make menuconfig again but this time select either squashfs or jffs2 as the target image format instead of ramdisk:
After saving the config, execute make again. This time, it should be much faster as nearly everything is already compiled.

# # using defaults found in .config # *** End of OpenWrt configuration. *** Execute 'make' to build the OpenWrt or try 'make help'. [athienem@localhost trunk]$ make ++ mkdir -p /home/athienem/openwrt/trunk/staging_dir/toolchain-mips_gcc4.1.2 ++ cd /home/athienem/openwrt/trunk/staging_dir/toolchain-mips_gcc4.1.2 ++ mkdir -p bin lib include stamp make[1] world [...] make[2] target/install make[3] -C target/linux install make[2] package/index [athienem@localhost trunk]$

Now the bin/ directory should be filled with some files:

[athienem@localhost trunk]$ ls -all bin/ total 23656 drwxrwxr-x 3 athienem athienem 4096 2008-11-08 18:25 . drwxrwxr-x 15 athienem athienem 4096 2008-11-13 22:44 .. -rw-rw-r-- 1 athienem athienem 710 2008-11-13 22:46 md5sums -rw-rw-r-- 1 athienem athienem 1499367 2008-11-08 18:25 openwrt-ar71xx-rootfs.tgz -rw-rw-r-- 1 athienem athienem 1441792 2008-11-08 18:25 openwrt-ar71xx-root.squashfs -rw-rw-r-- 1 athienem athienem 2492740 2008-11-13 22:46 openwrt-ar71xx-uImage.gz -rwxrwxr-x 1 athienem athienem 2248838 2008-11-08 18:25 openwrt-ar71xx-vmlinux.bin -rwxrwxr-x 1 athienem athienem 2258096 2008-11-08 18:25 openwrt-ar71xx-vmlinux.elf -rw-rw-r-- 1 athienem athienem 1048576 2008-11-08 18:25 openwrt-ar71xx-vmlinux.gz -rwxrwxr-x 1 athienem athienem 3725815 2008-11-13 22:46 openwrt-ar71xx-vmlinux-initramfs.bin -rwxrwxr-x 1 athienem athienem 3735072 2008-11-13 22:46 openwrt-ar71xx-vmlinux-initramfs.elf -rw-rw-r-- 1 athienem athienem 2555904 2008-11-13 22:46 openwrt-ar71xx-vmlinux-initramfs.gz -rw-rw-r-- 1 athienem athienem 2293760 2008-11-13 22:46 openwrt-ar71xx-vmlinux-initramfs.lzma -rw-rw-r-- 1 athienem athienem 786432 2008-11-08 18:25 openwrt-ar71xx-vmlinux.lzma drwxrwxr-x 3 athienem athienem 4096 2008-11-08 17:50 packages [athienem@localhost trunk]$

Booting OpenWrt on the RouterBoard

To boot the routerboard, a dhcp server is needed to tell the bootloader on the Routerboard which IP address it should use and where to get it's bootable kernel image.
The tftp server is needed to actually serve said image to the RouterBoard.

Under Fedora linux, installing both just needs the command yum install -y dhcp tftp-server. To activate both services, chkconfig can be used as root:

[root@localhost ~]# chkconfig dhcpd on [root@localhost ~]# chkconfig tftp on

The configuration for the dhcpd needs to be adapted to the local circumstances. The setup I've been using was a crosslinked cable between the notebook and the Routerboard with a manually configured IP address of 192.168.23.254/24. All that is configured in that file is to assign the RouterBoard an IP address and tell it to boot the file vmlinux. Adapt the following file as needed for your own circumstances:

[root@localhost ~]# cat /etc/dhcpd.conf # Global Parameters authoritative; max-lease-time 604800; default-lease-time 3100; ddns-update-style none; ddns-ttl 7200; allow booting; allow bootp; one-lease-per-client true; subnet 192.168.23.0 netmask 255.255.255.0 { option routers 192.168.23.254; option subnet-mask 255.255.255.0; option broadcast-address 192.168.23.255; ignore client-updates; } group { host routerboard { hardware ethernet 00:0c:42:32:43:8a; next-server 192.168.23.254; fixed-address 192.168.23.2; filename "vmlinux"; } } [root@localhost ~]#

Start the dhcp server by calling service dhcpd start, if there are any problems, look into /var/log/messages and fix the issues noted there.

The tftp-server has already been activated earlier but might need a service xinetd restart to be really started. Do that.
Then copy the ramdisk image named openwrt-ar71xx-vmlinux-initramfs.elf to the tftproot. This is /tftpboot on older systems or /var/lib/tftpboot/ on newer systems. Name the copied file vmlinux.

If everything is working fine, the system should boot:

RouterBOOT booter 2.15 RouterBoard 433 Authorization: Passed CPU frequency: 300 MHz Memory size: 64 MB Press any key within 2 seconds to enter setup... trying dhcp protocol... OK resolved mac address 00:1C:23:03:AA:F8 Gateway: 192.168.23.254 transfer started ............................ transfer ok, time=1.68s setting up elf image... OK jumping to kernel code Linux version 2.6.26.7 (athienem@localhost.localdomain) (gcc version 4.1.2) #1 Sat Nov 8 18:11:40 CET 2008 console [early0] enabled CPU revision is: 00019374 (MIPS 24K) Determined physical RAM map: memory: 04000000 @ 00000000 (usable) Initrd not found or empty - disabling initrd Zone PFN ranges: Normal 0 -> 16384 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0 -> 16384 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: root=/dev/mtdblock2 rootfstype=squashfs,yaffs,jffs2 noinitrd console=ttyS0,115200 init=/etc/preinit Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes. Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes Writing ErrCtl register=000227c0 Readback ErrCtl register=000227c0 PID hash table entries: 256 (order: 8, 1024 bytes) Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 60768k/65536k available (1762k kernel code, 4700k reserved, 312k data, 1572k init, 0k highmem) SLUB: Genslabs=6, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Mount-cache hash table entries: 512 net_namespace: 484 bytes NET: Registered protocol family 16 MIPS: machine is MikroTik RouterBOARD 433/AH registering PCI controller with io_map_base unset PCI: mapping irq 33 to pin1@0000:00:13.0 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered NET: Registered protocol family 1 squashfs: version 3.0 (2006/03/15) Phillip Lougher Registering mini_fo version $Id$ JFFS2 version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. yaffs Nov 8 2008 18:08:56 Installing. msgmni has been set to 118 io scheduler noop registered io scheduler deadline registered (default) Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0x18020000 (irq = 11) is a 16550A console handover: boot [early0] -> real [ttyS0] ag71xx_mdio: probed eth0: Atheros AG71xx at 0xba000000, irq 5 eth1: Atheros AG71xx at 0xb9000000, irq 4 NAND flash driver for RouterBoard 4xx series version 0.1.10 NAND SPI clock 25000 kHz (AHB 150000 kHz / 6) FLASH SPI clock 25000 kHz (AHB 150000 kHz / 6) NAND device: Manufacturer ID: 0xad, Chip ID: 0x76 (Hynix NAND 64MiB 3,3V 8-bit) Scanning device for bad blocks Bad eraseblock 828 at 0x00cf0000 Creating 3 MTD partitions on "NAND 64MiB 3,3V 8-bit": 0x00000000-0x00040000 : "booter" 0x00040000-0x00400000 : "kernel" 0x00400000-0x04000000 : "rootfs" mtd: partition "rootfs" set to be root filesystem split_squashfs: no squashfs found in "NAND 64MiB 3,3V 8-bit" Atheros AR71xx SPI Controller driver version 0.2.2 Atheros AR71xx hardware watchdog driver version 0.1.0 Registered led device: rb4xx:yellow:user TCP vegas registered NET: Registered protocol family 17 802.1Q VLAN Support v1.8 Ben Greear All bugs added by David S. Miller Freeing unused kernel memory: 1572k freed Algorithmics/MIPS FPU Emulator v1.5 [sighandler]: No more events to be processed, quitting. [cleanup]: Waiting for children. [cleanup]: All children terminated. - preinit - Press CTRL-C for failsafe Please press Enter to activate this console. br-lan: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature. device eth0 entered promiscuous mode PPP generic driver version 2.4.2 ip_tables: (C) 2000-2006 Netfilter Core Team nf_conntrack version 0.5.0 (1024 buckets, 4096 max) wlan: trunk ath_hal: module license 'Proprietary' taints kernel. ath_hal: 2008-10-02 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, REGOPS_FUNC, DFS, XR) ath_rate_minstrel: Minstrel automatic rate control algorithm 1.2 (trunk) ath_rate_minstrel: look around rate set to 10% ath_rate_minstrel: EWMA rolloff level set to 75% ath_rate_minstrel: max segment size in the mrr set to 6000 us wlan: mac acl policy registered ath_pci: trunk PCI: Enabling device 0000:00:13.0 (0000 -> 0002) Atheros HAL provided by OpenWrt, DD-WRT and MakSat Technologies wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: turboA rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: H/W encryption support: WEP AES AES_CCM TKIP ath_pci: wifi0: Atheros 5212: mem=0x10000000, irq=33 eth0: link up (100Mbps/Full duplex) br-lan: port 1(eth0) entering learning state br-lan: topology change detected, propagating br-lan: port 1(eth0) entering forwarding state BusyBox v1.11.2 (2008-11-08 17:55:16 CET) built-in shell (ash) Enter 'help' for a list of built-in commands. _______ ________ __ | |.-----.-----.-----.| | | |.----.| |_ | - || _ | -__| || | | || _|| _| |_______|| __|_____|__|__||________||__| |____| |__| W I R E L E S S F R E E D O M KAMIKAZE (bleeding edge, r13141) ------------------- * 10 oz Vodka Shake well with ice and strain * 10 oz Triple sec mixture into 10 shot glasses. * 10 oz lime juice Salute! --------------------------------------------------- root@OpenWrt:/#

If something didn't work out, check your system log to see what happens. Adding the "-s" parameter to the tftpd binary might be useful as it will log single requests.

Permanently installing OpenWrt on the RouterBoard

As we have an accessible Linux system running now on the RouterBoard the available tools such as scp and mtd can be used to copy the needed files onto the NAND device and thus permanently install OpenWrt on the device.

Under Linux the NAND device is partitioned and can be accessed through the mtd framework which exports some information to userspace through the /proc filesystem:
root@OpenWrt:/# cat /proc/mtd dev: size erasesize name mtd0: 00040000 00004000 "booter" mtd1: 003c0000 00004000 "kernel" mtd2: 03c00000 00004000 "rootfs"

As can easily be seen, there are three "partitions" available. Leave the one called "booter" alone, it might be important and contain the bootloader. I haven't checked. All we're interested in is "kernel" and "rootfs". The former contains the kernel, the latter the root filesystem.

To install the elf kernel binary named openwrt-ar71xx-vmlinux.elf, it has to be transferred onto the RouterBoard and written onto the second mtd partition. Make sure that the file is called kernel.
Note: OpenWrt configures its IP address to be 192.168.1.1 on bootup. You might have to change this with ifconfig.

root@OpenWrt:/# scp athienem@192.168.23.254:openwrt/trunk/bin/openwrt-ar71xx-vmlinux.elf /tmp/ root@OpenWrt:/# mount /dev/mtdblock1 /mnt/ yaffs: dev is 32505857 name is "mtdblock1" yaffs: passed flags "" yaffs: Attempting MTD mount on 31.1, "mtdblock1" root@OpenWrt:/# mv /tmp/openwrt-ar71xx-vmlinux.elf /mnt/kernel root@OpenWrt:/# ls /mnt kernel lost+found root@OpenWrt:/# umount /mnt/ save exit: isCheckpointed 0 root@OpenWrt:/#

The kernel image is installed.
The rootfs is even easier, as the mtd-device does not need to be mounted at all to write the squashfs image called openwrt-ar71xx-root.squashfs in my case.
This just needs to be written as is onto the mtd block device named rootfs:

root@OpenWrt:/# scp athienem@192.168.23.254:openwrt/trunk/bin/openwrt-ar71xx-root.squashfs /tmp/ root@OpenWrt:/# cat /tmp/openwrt-ar71xx-root.squashfs > /dev/mtdblock2 root@OpenWrt:/#

After a few seconds the squashfs image has been written and the device can be rebooted. Don't forget to disable the network boot in the Bios:

root@OpenWrt:/# reboot root@OpenWrt:/# br-lan: port 1(eth0) entering disabled state device eth0 left promiscuous mode br-lan: port 1(eth0) entering disabled state eth0: link down Restarting system. RouterBOOT booter 2.15 RouterBoard 433 Authorization: Passed CPU frequency: 300 MHz Memory size: 64 MB Press any key within 2 seconds to enter setup.. RouterBOOT-2.15 What do you want to configure? d - boot delay k - boot key s - serial console o - boot device u - cpu mode f - cpu frequency r - reset booter configuration e - format nand g - upgrade firmware i - board info p - boot protocol x - exit setup your choice:

Press "o" twice and "x" once to continue booting normally from the NAND.

RouterBOOT booter 2.15 RouterBoard 433 Authorization: Passed CPU frequency: 300 MHz Memory size: 64 MB Press any key within 2 seconds to enter setup.. loading kernel from nand... OK setting up elf image... OK jumping to kernel code Linux version 2.6.26.7 (athienem@localhost.localdomain) (gcc version 4.1.2) #2 Sat Nov 8 18:25:41 CET 2008 console [early0] enabled CPU revision is: 00019374 (MIPS 24K) Determined physical RAM map: memory: 04000000 @ 00000000 (usable) Initrd not found or empty - disabling initrd Zone PFN ranges: Normal 0 -> 16384 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0 -> 16384 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: root=/dev/mtdblock2 rootfstype=squashfs,yaffs,jffs2 noinitrd console=ttyS0,115200 init=/etc/preinit Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes. Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes Writing ErrCtl register=000227c0 Readback ErrCtl register=000227c0 PID hash table entries: 256 (order: 8, 1024 bytes) Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 62208k/65536k available (1762k kernel code, 3252k reserved, 312k data, 124k init, 0k highmem) SLUB: Genslabs=6, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Mount-cache hash table entries: 512 net_namespace: 484 bytes NET: Registered protocol family 16 MIPS: machine is MikroTik RouterBOARD 433/AH registering PCI controller with io_map_base unset PCI: mapping irq 33 to pin1@0000:00:13.0 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered NET: Registered protocol family 1 squashfs: version 3.0 (2006/03/15) Phillip Lougher Registering mini_fo version $Id$ JFFS2 version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. yaffs Nov 8 2008 18:08:56 Installing. msgmni has been set to 121 io scheduler noop registered io scheduler deadline registered (default) Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0x18020000 (irq = 11) is a 16550A console handover: boot [early0] -> real [ttyS0] ag71xx_mdio: probed eth0: Atheros AG71xx at 0xba000000, irq 5 eth1: Atheros AG71xx at 0xb9000000, irq 4 NAND flash driver for RouterBoard 4xx series version 0.1.10 NAND SPI clock 25000 kHz (AHB 150000 kHz / 6) FLASH SPI clock 25000 kHz (AHB 150000 kHz / 6) NAND device: Manufacturer ID: 0xad, Chip ID: 0x76 (Hynix NAND 64MiB 3,3V 8-bit) Scanning device for bad blocks Bad eraseblock 828 at 0x00cf0000 Creating 3 MTD partitions on "NAND 64MiB 3,3V 8-bit": 0x00000000-0x00040000 : "booter" 0x00040000-0x00400000 : "kernel" 0x00400000-0x04000000 : "rootfs" mtd: partition "rootfs" set to be root filesystem split_squashfs: no squashfs found in "NAND 64MiB 3,3V 8-bit" Atheros AR71xx SPI Controller driver version 0.2.2 Atheros AR71xx hardware watchdog driver version 0.1.0 Registered led device: rb4xx:yellow:user TCP vegas registered NET: Registered protocol family 17 802.1Q VLAN Support v1.8 Ben Greear All bugs added by David S. Miller VFS: Mounted root (squashfs filesystem) readonly. Freeing unused kernel memory: 124k freed Please be patient, while OpenWrt loads ... Algorithmics/MIPS FPU Emulator v1.5 - preinit - Press CTRL-C for failsafe - init - Please press Enter to activate this console. br-lan: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature. device eth0 entered promiscuous mode PPP generic driver version 2.4.2 ip_tables: (C) 2000-2006 Netfilter Core Team nf_conntrack version 0.5.0 (1024 buckets, 4096 max) wlan: trunk ath_hal: module license 'Proprietary' taints kernel. ath_hal: 2008-10-02 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, REGOPS_FUNC, DFS, XR) ath_rate_minstrel: Minstrel automatic rate control algorithm 1.2 (trunk) ath_rate_minstrel: look around rate set to 10% ath_rate_minstrel: EWMA rolloff level set to 75% ath_rate_minstrel: max segment size in the mrr set to 6000 us wlan: mac acl policy registered eth0: link up (100Mbps/Full duplex) br-lan: port 1(eth0) entering learning state br-lan: topology change detected, propagating br-lan: port 1(eth0) entering forwarding state ath_pci: trunk PCI: Enabling device 0000:00:13.0 (0000 -> 0002) Atheros HAL provided by OpenWrt, DD-WRT and MakSat Technologies wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: turboA rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: H/W encryption support: WEP AES AES_CCM TKIP ath_pci: wifi0: Atheros 5212: mem=0x10000000, irq=33 BusyBox v1.11.2 (2008-11-08 17:55:16 CET) built-in shell (ash) Enter 'help' for a list of built-in commands. _______ ________ __ | |.-----.-----.-----.| | | |.----.| |_ | - || _ | -__| || | | || _|| _| |_______|| __|_____|__|__||________||__| |____| |__| W I R E L E S S F R E E D O M KAMIKAZE (bleeding edge, r13141) ------------------- * 10 oz Vodka Shake well with ice and strain * 10 oz Triple sec mixture into 10 shot glasses. * 10 oz lime juice Salute! --------------------------------------------------- root@OpenWrt:/#

Done.

OpenWrt has been installed on the device and can be used and configured as usual.

For more information about configuring, using and customizing OpenWrt see the Kamikaze Manual, the OpenWrt Wiki or use the source. For network related configuration issues, /lib/network/config.sh and the files in /lib/wifi/ are a good start.

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

libgarfield not found

andreas@dicp.de (andreas) — Wed, 29 Mar 2006 16:34:05 +0200

Ich schrieb früher schon einmal von einem interessanten Erlebnis beim compilieren von Nautilus.

Nun habe ich eben gerade beim kompilieren von mboxgrep, einem Tool zum gezielten greppen nach Mails in einem Mailspool, eine andere nette Nachricht im Configure-Script gefunden:

checking for gzopen in -lz... yes checking for BZ2_bzopen in -lbz2... yes checking for like_monday in -lgarfield... no

Man beachte die letzte Zeile. Dazu passt es ja ganz hervorragend, dass ./configure --help folgendes bietet:

Optional Packages: --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) [...] --without-sense-of-humor If you have no sense of humor

LinuxTag Gedanken

andreas@dicp.de (andreas) — Tue, 28 Jun 2005 20:28:01 +0200

Mit Interesse habe ich bei Jörg seine Kritik am LinuxTag gelesen.

Jörg meint, dass der LinuxTag mal eine ordentliche Imageberatung bräuchte und überhaupt mal kräftig überarbeitet gehört. Einerseits ist die Präsentation der Community katastrophal, andererseits ist der LinuxTag inzwischen thematisch uninteressant und man geht eigentlich nur noch hin um andere Leute zu treffen.

"LinuxTag Gedanken" vollständig lesen

LinuxTag Freitag, Tag 3 - Teil 1

andreas@dicp.de (andreas) — Sat, 25 Jun 2005 23:59:00 +0200

Endlich ausgeschlafen. Ich habe mich dann doch entschieden erst gegen 13:30 auf dem LinuxTag aufzutauchen. Das Vormittagsprogramm war dann doch nicht soooo wichtig. ;-D Ausgeschlafen (heute war es zum Glück ein wenig kühler), frisch geduscht ging es dann los mit dem Ziel erstmal Pizza oder sowas zu jagen.

Netterweise traf ich auf dem Vorplatz ein paar Red Hat Leute die meinten ich solle einfach zum Stand gehen, sie hätten noch was zu essen.
Lecker. Mozarella, Tomate und Salat plus Brötchen.
Sogar ein sehr interessantes Zubereitung. Muss ich bei Gelegenheit mal selber probieren. Ein halbes Brötchen, mit Frischkäse oder Butter beschmiert, dann ein Salatblatt und oben drüber dann den Belag. Es gab Käse, Pute, Lachs, Mozarelle und Tomate.
Das ganze dann natürlich entsprechend verziert. Wallnuss und Kräuterbutter beim Käse, Petersilie beim Rest. Lecker!

Gesättigt ging es dann weiter auf dem Linuxtag.

"LinuxTag Freitag, Tag 3 - Teil 1" vollständig lesen

LinuxTag Freitag, Tag 3 - Teil 2

andreas@dicp.de (andreas) — Sat, 25 Jun 2005 23:59:00 +0200

Wie sehr sich Pläne doch ändern können.
Eigentlich war ja angedacht nach dem LinuxTag 2005 noch mit dem CCC Stuttgart und dem CCC Karlsruhe/Entropia gemeinsam zu grillen.

Pustekuchen.

Nach Ende der Messe hing ich kurz am RedHat Stand rum, um mir was zu trinken zu holen, kurz aufräumen zu helfen und anschliessend zu schauen ob man noch tolle Sachen zum abgreifen findet. (Fand ich nicht.).
Als das dann erledigt war, meinte lx noch, man würde sich nachher noch im Hotel treffen und dann essen gehen, und ich solle doch mitkommen.
Der Beginn eines langen abends...

"LinuxTag Freitag, Tag 3 - Teil 2" vollständig lesen