phaqphaq

Well, well, I just feel like 14 years ago, playing around with my rather aged SGI O2, which I didnt touch for years, doing a fresh reinstall of IRIX and some apps.

While flipping through my CDs I stumbled accross SoftWindows95 for IRIX. I just couldn’t resist and put the flipper in, having the software installed just minutes later, only to see that I didn’t have the license any more

After some searching I found a Usenet article with a valid license of SoftWindows95. Well, I think it’s fair enough to republish this, as for one, Insignia has sold-off SoftWindows about 10 years ago, and the successor company FWB Software stopped development in 2001, furthermore that company doesn’t exist anymore as it has been sold-off, too. Well, not even SGI is able to provide a license key for a software, which is 14 years old … hm…. Well, I _think_ it’s ok, otherwise let me know …

To activate SoftWindows95 just place this text into /usr/lib/SoftWindows95/FLEXlm/license.dat:

FEATURE Insignia_SoftWindows95 insignia 4.000 01-jan-0 0 \
ECE41259D5BE4700DC27 VENDOR_STRING=”5100 0100 0000 0001″ \
HOSTID=ANY vendor_info=SOFTWINDOWS95 ISSUER=”Silicon Graphics, \
Inc.”

The license won’t show up from the GUI _but_ SoftWindows95 will work.

Considering the age of the O2 and it’s dated 200 MHz MIPS CPU the emulation speed isnt’t too bad.
I remembered it being worse than thaz, but maybe that’s just the “geekness” of having gotten something very old to work again

Today a colleague of mine faced a very weird problem.
While parsing XML output from an HP ILO into Perl, his code constantly broke with the message:

FILE.XML:123 parser error : PCDATA invalid Char value 1

While the message itself states clearly that there is an unexpected character value (Char value 1, ASCII SOH) on one hand, it doesn’t tell the character position on the other.

Looking at the input string itself on the console, it wasn’t obvious either:

<EVENT SEVERITY=”Caution” LAST_UPDATE=”08/03/2009 22:20″ INITIAL_UPDATE=”08/03/2009 22:20″ COUNT=”1″ DESCRIPTION=”POST Error: ” />

So I proposed to add some lines to help identify the character position on the given input string, which was basically this:

@array = unpack(”C*”, $_my_input_var);
foreach (@array) {
printf(”char \”%s\” is ord %s\n”, chr($_), $_);
}

This led to the following output:

char “<" is ord 60
char "E" is ord 69
char "V" is ord 86
--- some output omitted ---
char ":" is ord 58
char " " is ord 32
char "" is ord 1
char """ is ord 34
char " " is ord 32
char "/" is ord 47
char ">” is ord 62

So looking at this we saw that ASCII char 1 (which is an unprintable character, it will be represented as ^A in some editors like vi) was the fifth character before the end of the string.

Well, basically the solution to this is to apply an additional input filter to remove ASCII char 1 like this:

$_my_input_var =~ s/\x01//g;

While this solves just _this_ problem, a more solid solution is to remove all non-printable characters as well, given the list of ASCII characters at http://www.asciitable.com/.

So a filter like this may apply, removing all non-printable characters, leaving just a few control characters 1×08 to 1×1F (Tab, Carriage Return, Line Feed and a few others) and the printable characters in it.

$_my_input_var =~ s/[\x00-\x08\x0B-\x1F\x7F-\xFF]//g;

This february I had my 30th birthday. My boss surprised me with an eeePC 1000H as an unexpected as well as also a very cool gift

Ok, I must admit, that I took a glimpse at the tiny netbooks more than once. My dream was to actually run it with OS X instead of Windows or Linux.

So, just the next-day my netbook was OS X-ified (a topic, which I’ll cover later on), only to notice some more or less annoying issues.

One of the most annoying issues was the stock WiFi, which required a very ugly 3rd party tool for configuration and was so absoluty not OS X-alike.
Read the rest of this entry »

Well, well, well …

I just stumbled accross a minor difference between Cisco and Foundry, the latter being mostly Cisco-alike.

To update an ACL on Cisco devices (at least the ones I encountered so far) I usually do this:

conf t
!
no ip access-list extended MY_ACCESS_LIST
!
ip access-list extended MY_ACCESS_LIST
    my permit/deny list entries
!
end

This results in immediate application of the access list, so we’re just fine and happy.

Doing the same on a Foundry results in… nothing.
Well, not quiet, at least the changes are applied in terms of “visibility” in the running config or with a “sh access-list name MY_ACCESS_LIST” statement, but they are not enabled.

Once more RTFM holds true, especially when talking about “familiar devices”, which we usually understand well enough to work with easily (which usually holds for most Cisco-alikes), but ommit reading the entire manual for exact THAT reason. Honestly, how many of you REALLY (I mean REALLY!) do this ….?

In this case I learned from the manual, that a Foundry/Brocade devices needs an implicit reload of the access lists after modying them (Dough!).

The command line should effectively read:

conf t
!
no ip access-list extended MY_ACCESS_LIST
!
ip access-list extended MY_ACCESS_LIST
    my permit/deny list entries
!
ip rebind-acl all
!
end

So, I could have saved me 15 minutes if I HAD actually read the manual section about ACL before …

Yesterday I started digging around for a solution to create per-user or per-database statistics on MySQL, one of the more important peaces I was missing from it for a long time.

Luckily enough, some guys over there had already done some work on this topic, so I wouldn’t have to start over from scratch

It took me only little time to port over the patch from MySQL 5.0.51 to the more current 5.0.83 release within the FreeBSD ports tree, however not soon after starting a build I would encounter this error message:

[root@bld-bsd-224-221 /usr/ports/databases/mysql50-server]# make build
[ - some output omitted - ]
/bin/sh ../ylwrap sql_yacc.yy y.tab.c sql_yacc.cc y.tab.h sql_yacc.h y.output sql_yacc.output --  -d -d --debug --verbose
-d: not found
*** Error code 1

At first I thought the port was corrupted so I refetched the package and reapplied the patch, to no avail.
So I tried again using the original port without having the patch applied, which worked flawlessly.

At second glance I checked for the file list from above command and noticed that it included the file named sql_yacc.yy, one of which had been altered by the previously applied patch.
My conclusion was that the file had been wrongly patched, containing a syntax error or such alike.
I then extracted the unpatched package once more to do a clean rebuild without patches.
I checked the compilation output for the above command line, only to note that it wasn’t actually there!

The question was: Why would the command line “/bin/sh ../ylwrap sql_yacc.yy ….” not get invoked when doing a build on a clean, unpatched package?
I double-checked my patches to see if the command was introduced by itself, which was not the case. That single command actually belongs to the stock MySQL Makefile.

At that stage I decided to just add a single whitespace to the file sql_yacc.yy and run the command manually:

[root@bld-bsd-224-221 /usr/ports/databases/mysql50-server/work/mysql-5.0.83/sql]# make
/bin/sh ../ylwrap sql_yacc.yy y.tab.c sql_yacc.cc y.tab.h sql_yacc.h y.output sql_yacc.output --  -d -d --debug --verbose
-d: not found
*** Error code 1

Interestingly enough that command actually only seems to get involved when the contents of the sql_yacc.yy file is altered.
As such the error was indeed not caused by the patch itself.

So I digged deeper in analyzing the “ylwrap” script file, which is included with the MySQL package. Oh well, at that time I really felt like an idiot!
When I realized that this seemed to by a wrapper script for YACC I also noticed the double-hyphen, which is really an indicator for subsequent command line arguments to be passed on to a sub-process.
Having said that I supposed there was actually missing something in between here: “– {HERE} -d -d”
Could it be that it’s missing the command name of the YACC sub-processor?

Well, do I have YACC installed?

bld-bsd-224-221.genotec.ch:/usr/ports/databases/mysql50-server# which yacc
/usr/bin/yacc

Well, I do … the only catch is: MySQL depends on bison, not on YACC.
To make things worse, neither the FreeBSD port Makefile nor the MySQL configure script check on that dependency, most likely as it is *usually* not required.

Good catch, after having installed bison from the ports tree MySQL compiled like a charm even with all my patches applied