Hazard's stuff

• Software

— Posted by hazard @ 15-07-13 00:54

I have released a Smokeping plugin for Mikrotik RouterOS devices. It supports VRFs and connects via SSH. Installation instructions:

• Download the plugin to your server.
• Install by copying the file into lib/Smokeping/probes directory under your smokeping installation (e.g. to /opt/smokeping/lib/Smokeping/probes).
• You might also have to install Net::OpenSSH Perl module, if it's not already installed (check by running " perl -e 'use Net::OpenSSH' ").
• Add the following section to your smokeping config:
  

  + OpenSSHMikrotikPing
  packetsize = [e.g. usual MTU is 1500]
  mikrotikuser = [user]
  mikrotikpass = [pass]
  # feel free to change params below as you wish
  forks = 5
  offset = 50%         
  timeout = 15
  step = 120
  

• Individual targets are configured as follows:

  ++ sample-target
    probe = OpenSSHMikrotikPing
    menu = [menu name]
    title = [title]
    host = [destination IP to ping from Mikrotik device]
    pings = [numer of ICMP pings to send, e.g. 5]
    source = [Mikrotik device to login into]
    vrf = [routing-instance name, optional]
    psource = [Mikrotik interface source IP to ping from, optional]
  

• ssh to the Mikrotik device once from the commmand line from the account of the user who is running smokeping (su -s /bin/sh [username]). On the first connect ssh will ask to add the new host to its known_hosts file, confirm it. Otherwise Smokeping will fail to login as the ssh key of your Mikrotik box is not in the known_hosts file.

Comment |

• Software

— Posted by hazard @ 14-09-25 19:06

** UPDATED SEP 26 2014 FOR CVE-2014-7169 **

Some of us are unlucky enough to run older Linux systems (CentOS 4 and older) and need to fix bash "ShellSock" environment code injection vulnerability.

To make the job easier, you can grab my CentOS 4.x i386 RPM/SRC RPM , as well as Red Hat Linux 6.2 (circa 2000!) RPM/SRC RPM, which may work on older systems as well, such as RH7. SRPM should be buildable on all Red Hat systems.

MD5 sums:

30d76eb29c75ca9bf5dcc4d4903de299  bash-3.0-29centos4_vulnfix.i386.rpm
89f0c72480a2dbe28d61503973e98443  bash-3.0-29centos4_vulnfix.src.rpm
57bb220cc9ac5ef2c445a4dece61814c  bash-3.0-29rh62_vulnfix.i386.rpm
4ab6aa1a5958da0e5290f43134b08f2a  bash-3.0-29rh62_vulnfix.src.rpm

If you want to be 100% sure that the code wasn't tampered with, build your own binary by using src RPM and verify that all patches apart from 140/141 are Red Hat original (140/141 were taken from Oracle's bash patches).

Comment |

• Software

— Posted by hazard @ 14-08-11 10:47

If you upgraded your Linux Skype to 4.3 and face a crash immediately after startup, the fix that worked for me is as follows:

• Make of a backup of your home .Skype directory
• Install sqlite package on your system if it isn't there already
• Run: sqlite3 ~/.Skype/[YOURUSER}/main.db
• DELETE FROM Messages WHERE type=68;
• .quit

You will loose your file transfer history, but chat history will still be there. I found this workaround here. If it doesn't help, you may have to delete/rename your .Skype directory.

Comment |

• Software

— Posted by hazard @ 14-06-27 19:15

If on your Linux PC YouTube wouldn't play more than one second of videos, while flash on other websites has no sound, or you have any other issues with audio in other apps, the likely culprit is Pulseaudio. I could never figure out the reason why the world needed pulseaudio, apart from the fact we have to use everything that Lennart Poettering creates.

Anyway, solution to the pain is easy, just follow excellent 30-second instruction on Mondo Grigio blog.

1 Comments |

• Software

— Posted by hazard @ 14-05-25 12:30

I've been integrating an online spreadsheet functionality into DokuWiki and jQuery.sheet looked like the most suitable candidate. It comes with a number of examples, but there is no server-side backend that will save/load the sheets. As a proof of concept I created a simple jQuery.sheet database backend example in Perl.
 (More)

Comment |

• Stuff

— Posted by hazard @ 14-02-03 00:27

As part of systemd/DBus revolution, newer Fedoras have this annoying feature that all USB disks get mounted into to /run/media/[user]/[diskname] (also /var/run/media, which is a symlink).

After some digging, I found that this is done supposedly for security reasons and being taken care of by udisks2 daemon. I'm still not sure what extra security this gives since 99% of Fedora desktops are not accessed by untrusted users, while admins of untrusted multiuser machines usually understand the risks. Nevermind. What I'm sure though, is that it breaks guest access to USB disks from Samba and breakes old scripts which were using /media.

To return old behavior back and make udisks2 change mount point to /media, create a file /etc/udev/rules.d99-usb-shared-media.rules:

ENV{ID_FS_USAGE}=="filesystem", ENV{UDISKS_FILESYSTEM_SHARED}="1"

udev should notice and read this file automatically. After this, just unplug and plug your USB drive back to see it in good old /media.

Comment |

• Software

— Posted by hazard @ 13-12-01 19:07

I have hacked together a Smokeping plugin for Juniper JunOS devices that supports VRFs (routing-instance) and logical systems.

• Download the plugin to your server.
• Install by copying the file into lib/Smokeping/probes directory under your smokeping installation (e.g. to /opt/smokeping/lib/Smokeping/probes).
• You might also have to install Net::OpenSSH Perl module, if it's not already installed (check by running "perl -e 'use Net::OpenSSH'").
• Add the following section to your smokeping config:
  

  + OpenSSHJunOSPing
  packetsize = [in JunOS 1472 is the max for 1500 L3 MTU]
  junospass = [pass]
  junosuser = [user]
  # feel free to change params below as you wish
  forks = 5
  offset = 50%         
  timeout = 15
  step = 120
  

• Individual targets are configured as follows:

  ++ sample-target
    probe = OpenSSHJunOSPing
    menu = [menu name]
    title = [title]
    host = [destination IP to ping from JunOS device]
    pings = [numer of ICMP pings to send, e.g. 5]
    source = [JunOS device to login into]
    logicalsystem = [logical system name, optional]
    vrf = [routing-instance name, optional]
  

• ssh to the JunOS device once from the commmand line from the account of the user who is running smokeping (su -s /bin/sh [username]). On the first connect ssh will ask to add the new host to its known_hosts file, confirm it. Otherwise Smokeping will fail to login as the ssh key of your JunOS box is not in the known_hosts file.

Comment |

• Stuff

— Posted by hazard @ 13-01-12 02:13

I've always thought that OSPF was one of the rotten tomatoes in the generally nicely-looking suite of core IP protocols. Its architecture is simply not suited well for real-life carrier networks. OSPF tries to impose its own rules on how the network should be built, instead of providing flexibility to adjust the protocol to the network. However, instead of throwing OSPF out and concentrating on a better IGP (e.g. something EIGRP-like), Internet/IETF community kept adding more and more band-aids to it. As a result, we've got a number of monstrous and complex specifications, which even vendors don't fully understand, resulting in bugs and incompatibilities between implementations, as well as lots of confusion to engineers.

A few days ago I got hit by another case which re-enforced my beliefs. I had to implement an OSPF network which had both Type 5 LSA E2 and Type 7 N2 routes for the same prefix. Moreover, there was a mix of IOS and JUNOS speakers in the same network. So, what is the route selection algorithm in that scenario? Google and you'll find at least three different answers. An incorrect answer from one of very reputable sources will say that E2 route will win over N2 no matter what the cost is. Another answer is that E2 route will be preferred if it has the same or lower metric than N2 route. And the third answer is the opposite: N2 route will win over E2 if it has the same or lower metric.

Well, to ease the pain of future generations, I'll say that the correct answer is that N2 route will win unless E2 has lower cost. That is, unless that future generation lives in a world where they have released an RFC to supersede RFC 3101, since things might change the same way as they did since RFC 1587, which apparently specified opposite behavior. If you're using Cisco IOS, it depends on which IOS you use, many IOSes will prefer E2, as they follow the behavior from RFC 1587, even though they were released much later than RFC 3101. Other IOSes will prefer N2.

I rest my case.

Long live OSPF, the reason for late-night maintenance headaches! As well as an additional source of revenue for network engineer certifications. :)

Comment |

• Software

— Posted by hazard @ 12-01-07 19:23

I've decided to upgrade my FC14 to FC16. Along the way, I decided to do it using a method that I've never used before - preupgrade. Supposedly it's one of the easiest and less time consuming methods. Not in Cyprus ... (More)

2 Comments |

• Software

— Posted by hazard @ 11-08-28 18:33

A few days ago I was asked to help with a DDoS attack against a website. The DDoS itself was pretty generic, a small zombie network hammering particular URLs from the websites with GET requests. The websites were running on Apache, and despite that the target page was static, the DDoS was bringing Apache to its knees. System administrators tried to utilize various Apache modules and configuration tricks to protect against DDoS, but to no avail.

There was only one solution to this on my mind - install nginx. And that really helped. nginx is asynchronous by design and therefore handles load much much better. Whilst Apache was failing with several hundred simultaneous connections, nginx easily scaled to 10k caused by DDoS, whilst using only 20% CPU.

The first website was completely moved to nginx, with PHP being served through PHP/FastCGI. For the second website, the nginx was configured in proxy mode, so that it would forward all requests to the Apache, whilst enforcing limits against DDoS - 1 unique page request per IP per second, as well as blocking certain user agents. Below is an example configuration I created, relevant for CentOS/RHEL.
 (More)

2 Comments |

• Software

— Posted by hazard @ 10-06-29 05:00

We had an issue with a database server running Greenplum (commercial Postgresql for large-scale datawarehousing). Greenplum was starting, but attempts to do anything in the database were resulting in the following errors:

INFO: Crash recovery broadcast of the distributed transaction 'Commit Prepared' broadcast succeeded for gid = 1265880453-0032866370.
INFO: Crash recovery broadcast of the distributed transaction 'Abort Prepared' broadcast succeeded for gid = 1265880453-0032866371��C
psql: FATAL: DTM Log recovery failed. There are still unresolved in-doubt transactions on some of the segment databaes that were not able to be resolved for an unknown reason. (cdbtm.c:2829)
DETAIL: Here is a list of in-doubt transactions in the system: List of In-doubt transactions remaining across the segdbs: ("1265880453-0032866371��C" , )
HINT: Try restarting the Greenplum Database array. If the problem persists an Administrator will need to resolve these transactions manually.

Of course, manuals/forums/Google did not provide any useful ideas as regards to how 'to resolve these transactions manually'. Morever there was no backup handy (and the db was huge). I didn't care about two lost transactions, I just wanted to start the database. After an hour of attempts, eventually I succeeded. The trick was to delete files from pg_twophase/ subdirectories.

I'm blogging this in the hope that when somebody else faces this problem, he would be able to find this post through Google, saving his nerves. :-)

28 Comments |

• Cyprus

— Posted by hazard @ 10-06-23 14:33

Great music but a boo for customer service. I don't like being told "I don't give a shit" by supervisors. Having spent there a few hundred euros in a week, the least I want is to be handled politely. Fix yourself or you'll end up only with drunken kids. The atmosphere has been degrading ever since the move to a new place.

6 Comments |

• Stuff

— Posted by hazard @ 10-03-19 14:39

It's been a while I posted something here, so as well it might be a rant.

TODAY:

• Confortel Atrium hotel in Madrid tried to put 60 EUR worth of bar/restaurant charges on me, ignoring the fact that they were dated BEFORE the date I arrived.
• Aegean airlines screwed up web check-in Madrid-Athens-Larnaca. I managed to check in for Madrid-Athens, but then the system would not let me check-in to Larnaca.
• Aegean airlines did not manage to register me to Larnaca even in Madrid airport registration desk. "We use different systems". It should be mentioned that my transfer time in Athens was planned to be just one hour, which is already tight, without having to obtain a boarding pass...
• ... and then the flight to Athens was delayed.
• The duty-free in Madrid didn't put the bottle of wine I purchased in a sealed bag. So the bottle was happily confiscated by Athens airport security.
• My passport got damaged (peeled off) just on the place where my photo is.
• It seems I caught a cold.

Well, it could be worse, right ??

12 Comments |

• Software

— Posted by hazard @ 09-02-28 14:31

In case someone wants to run a recent Linux kernel on an FC8 box, I have made an RPM for 2.6.28.7 and you can download it here. Should also install on CentOS 5/RHEL 5 if you use --force.

12 Comments |

• Space

— Posted by hazard @ 09-02-02 16:28

This breathtaking photo was taken next to a space communication facility near Ussuriysk, Russia. The biggest RT-70 radiotelescope has a 70m diameter antenna with an area of 2500 sq. m! The telescope stands over 100m high, can rotate 360 degrees and weights over 24 thousand tons [1] [2]. Impressive gadget :) Sadly, not used nowadays, due to lack of financing and deep space missions.

10 Comments |