Random thoughts

The trouble with having remote access to a computer is that most of the time it fails miserably when you really need to fix that computer. For instance, you can't connect through LogMeIn to a computer started in Safe Mode (with Networking). I did a test today and if you start a PC in Safe Mode with Networking and you go to the Services application, if you try to right click and start the "LogMeIn" process, it will say it can't be started in safe mode. Bummer. Thankfully, there is a solution for that - you add the service to the trusted list of processes for Safe Mode, and presto, you can start it. You just need to add a key in the registry using this rather obscure command (start a new command prompt), and you are almost done: reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SafeBoot\Network\LogMeIn" /VE /T REG_SZ /D "Service" (one line). The output should be like in the next picture Now, the process can be started in safe m...

Samplicator looks like a great UDP fan-out tool for Linux/Unix. Unfortunately, it doesn't have proper startup/shutdown scripts. Here are, for your convenience such startup scripts adapted from apmd (currently tested only on Linux). Dependencies are: GNU grep and perl (to emulate a PID mechanism). #!/bin/sh # # chkconfig: 2345 26 74 # description: samplicator is a daemon to fanout UPD packets # processname: samplicator-syslog # Source function library. . /etc/init.d/functions RETVAL=0 SERVICE="syslog" UDPLISTENPORT=514 SOURCEIP="10.0.250.131" DESTINATIONS="10.0.250.132/514 10.0.250.61/514"; PIDFILE="samplicator-$SERVICE.pid" start() { echo -n $"Starting up samplicator-$SERVICE daemon: " daemon --check samplicator-$SERVICE /usr/bin/samplicate -f -p $UDPLISTENPORT -s $SOURCEIP -b 8388608 -S $DESTINATIONS; netstat -upan | grep -P "$SOURCEIP:$UDPLISTENPORT.*samplicate" | perl -e 'my $line= ; $line=~/([0-9]+)\/...

I've had a hard time trying to debug a problem on a Vector layer that had tooltips as well as regular popups. It worked fine but from time to time Firebug would log an error message like the following: element is null if(!google.gears){google.gears={factory:...setWidth,height:element.offsetHeight};}\n OpenLayers.js (line 228) I'm running OpenLayers 2.8. This error messed up javascript - zooming and panning were broken, the current popup would remain un-close-able, but other markers seemed to work just fine. I managed to track this problem to a null element in Element.js. I'm not sure why the element is null at that point, but it may be a safe thing to do to check if the element exists before trying to change its style... I attached a patch that should solve this (adds an if before setting the style): --- lib/OpenLayers/BaseTypes/Element.js.original 2009-08-04 15:42:45.000000000 +0300 +++ lib/OpenLayers/BaseTypes/Element.js 2009-08-04 15:40:43.000000000 +0300 @@ -4...

I've been searching the internet for a script/program that can automatically summarize CIDR classes that I pass to it. I haven't found one, but I found a perl module ( Net::CIDR::Lite ) that does just this. I wrote a small script that takes the CIDR classes and summarizes them and then outputs the summarized classes. This is useful for generating a routing table for a management server and basically you have to copy the classes from a router, summarize them and paste them on the server. Here's the script - copy/paste it in a perl file and make it executable: #!/usr/bin/perl use strict; use warnings; use Net::CIDR::Lite; my $ipv4String='[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}'; if(defined $ARGV[0] && $ARGV[0] eq '-h'){ print "usage: $0 This script summarizes your IP classes (if possible). Input IPs with mask one per line. End with CTRL+D. Optionally, redirect a file to stdin like so: $0 exit; } print "Enter IP/Mask one per line (1.2...

I wanted to edit the crontab on a Solaris 10 box, but when I tried to execute crontab -e, it didn't take me to the vi editor. This is what I got instead: # crontab -e 434 No matter what I typed, I couldn't use this edit mode. Turns out my terminal wasn't exported properly and vi started in 'one line' mode. Here's how to get the default vi back - you need to have the properly variables set in your shell: # EDITOR=vi # export EDITOR # TERMINAL=xterm # export TERMINAL (for bash). Now, try crontab -e again, and vi should be 'full screen'.

Recently I experienced very long delays while connecting to remote mysql databases, without any apparent reason. The connect would stall while connecting, before issuing querries and would wait for about 15-20 seconds before working. I managed to find out why: The mysqld server uses reverse DNS queries to find out the name of the calling host. If the DNS is unavailable at the server side (as was my case), it takes a while for the query to time out. To solve this, you must add your ip and hostname in the /etc/hosts of your mysql server, so it is able to resolve your IP (or get the DNS working). More info here: http://dev.mysql.com/doc/refman/5.0/en/dns.html

This post is just for testing purposes. I'm new to this 'blogging' thing!