How to disable CDP-4-NATIVE_VLAN_MISMATCH (native vlan mismatch)

October 27th, 2009

Cisco switches support CDP and use it to help us in a number of ways. One of them is to detect native VLAN mismatch between two connected ports. For 99% of the time this is a “good thing to do” ™ but there are some corner cases where this is not what you want.

For example, if you have a switch that is connected with another switch and their connected ports are configured as access ports (and not trunk ports) then this message doesn’t make much sense.

Well… it does…

Cisco switches also support VTP which eases the VLAN management task. For VTP to work, switches that are under the same “local network” are also under the same “VTP domain”. A VTP domain logically groups switches.

Now, here is the problem: Two switches connected using access mode that are in the same VTP domain should share the same VLAN configuration, even if they are configured as transparent.

What to do: To bypass this problem you have to change the vtp domain on those switches so that it doesn’t match. If you haven’t changed that already, they most probably are not in any VTP domain at all or they are in the same VTP domain.

The solution:

  1. Configure at least one of the two switches to be in transparent mode. You may not want that, but if you don’t know what this means then just do it:

    Switch(config)# vtp mode transparent
  2. Change the VTP domain of that switch:

    Switch(config)# vtp domain a_unique_name

    (you may want to use the hostname)

… and this annoying message:


Oct 27 12:16:29.352 EET: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet2/6 (2), with sw-el0 GigabitEthernet0/8 (1).

will be gone

Why I like Linux (and KDE4)

October 25th, 2009

This video illustrates why Linux is superb:

MP4, 80MB: http://www.v13.gr/files/videos/kde4-1/kde4-1-3.mp4
MP4, 40MB: http://www.v13.gr/files/videos/kde4-1/kde4-1-2.mp4
AVI, 40MB: http://www.v13.gr/files/videos/kde4-1/kde4-1-2.avi

In the video you see: KDE 4.3, mplayer, tvtime, konqueror, KVM, nexuiz, wine.
The video was made with kdenlive

The Day The Routers Died

September 17th, 2009

Great video!

And don’t forget to visit the IPv4 address report.

Plus a net-geeky video and how the three finger salute started.

hal-acl-tool, pam and high cpu usage

August 25th, 2009

For a long time now i see my CPU usage rising and falling back every some seconds. This is very annoying and it really slows things down. Finally, I found (to some extend) what causes this problem. Using “udevadm monitor” I show that the CPU was rising whenever a uid-add event was created by the kernel:

$ udevadm monitor
KERNEL[1250930556.085871] add      /kernel/uids/111 (uids)
UDEV  [1250930556.087481] add      /kernel/uids/111 (uids)
KERNEL[1250930556.099782] remove   /kernel/uids/111 (uids)
UDEV  [1250930556.099818] remove   /kernel/uids/111 (uids)

I also found that the program that causes the CPU load is “hal-acl-tool” but not directly. In fact, hal-acl-tool wasn’t consuming a lot of CPU and top wasn’t showing anything. With process accounting I found that there are 1000s of invocations of /usr/lib/policykit/polkit-read-auth-helper:

$ lastcomm |grep polkit-read-aut | wc -l
61161

in a couple of minutes (!). This seems to be a bug that troubles other people too.

Finaly, I concluded that the problem is not related to uid-add events but to session creation. The problem is caused by console kit and its pam hook: pam_ck_connector.so. For newer debian versions (read: testing) you can disable this by running (as root) pam-auth-update and deselecting the “ConsoleKit Session Management”.

WARNING: I’m not aware of the drawbacks of disabling “ConsoleKit Session Management”, so do this at your own risk.

php foreach by reference

June 13th, 2009

Here’s an interesting “feature” (bug?) for php. Recent PHP versions support this syntax for foreach:

foreach ($myarray as &$v)
  $v['koko']=’lala’;

This allows easy changes to the actual table by using references and not acting on a copy.

- but -

If you do this:

$myarray=array(array('a'=>1), array('a'=>2), array('a'=>3));

foreach ($myarray as &$v)
  $v['b']=1;

foreach ($myarray as $v);

print_r($myarray);

You manage to remove the last element of $myarray (!!!). This is the output:

Array
(
    [0] => Array
        (
            [a] => 1
            [b] => 1
        )

    [1] => Array
        (
            [a] => 2
            [b] => 1
        )

    [2] => Array
        (
            [a] => 2
            [b] => 1
        )

)

Now, if you change the code to:

$myarray=array(array('a'=>1), array('a'=>2), array('a'=>3));

foreach ($myarray as &$v)
  $v['b']=1;

foreach ($myarray as $v2);

print_r($myarray);

The bug is gone. The output is correct:

Array
(
    [0] => Array
        (
            [a] => 1
            [b] => 1
        )

    [1] => Array
        (
            [a] => 2
            [b] => 1
        )

    [2] => Array
        (
            [a] => 3
            [b] => 1
        )
)

To my knowledge, this happens because $v is kept as a reference to the last element when the first foreach is finished. Then, when the second foreach is ran, some assignments are performed to $v, destroying its last element.

KAutostart and python

March 7th, 2009

This one took me many hours to debug:

For KDE 4 and python there can be a hard to debug problem with KAutostart usage.

Suppose you have a window class

class MyWindow(KDialig, Ui_Dialog):
  def __init__(self):
    self.kas = KAutostart('myapp')
    self.kas.setAutostarts(True)

You may find that the setAutostarts() doesn’t actually work. This is because MyWindow references kas and kas references MyWindow (as the parent object) (or the application - I’m not sure). The problem is that KAutostart() stores the information when it is deleted (in it’s destructor) and since it is never deleted it won’t store anything.

You need to understand that the destructors won’t be called even when the program exits, because of the circular reference.

To solve the problem call:

self.kas=None

at some point.

Have a look here for more on python and its destructors.

Loans

January 17th, 2009

Here’s an example about how loans seem to currently work and what they mean to the society:

Suppose we have two persons (Ann and Bob) and a Bank. The Bank has no money at all, Ann has 10.000 euros (or dollars or whatever) and Bob has two cars which is willing to sell for 8.000 euros each.

Ann gives Bob 8.000 euros and she buys the first car. Now Ann has 2.000 euros and Bob has 8.000 euros. Bob goes to the bank and deposits the money, so the Bank now has 8.000 euros.

Ann goes to the bank and gets a 6.000 euros loan which she will repay as 7.000 euros in two years. Now Ann has 8.000 euros (6.000 from the loan and 2.000 pre-existing cash) which she uses to buy the second car. Bob gets the 8.000 euros and deposits them to the bank too.

At this point:

  • Ann has two cars and a dept of 6.000 euros to the bank that she may not repay
  • Bob has 16.000 euros in deposits
  • The bank has 10.000 euros and a loan for 6.000 euros (that will become 7.000 after two years)

The 1.000.000 dollars question is: Does bob have 16.000 euros ?

The fact is that Bob actually thinks that he has 16.000 euros which he can use but in fact he only has 10.000.

What’s going on?

This is a clever way to rename future money (the 6.000 euros) to current money. You can see this problem as an issue of tagging where money should be tagged either as “existing” or “loaned/future/not-yet-available” money. Currently this isn’t possible since loans are given in cash and not in another kind of debt bills and the fact is that we (the sum of all humans) currently have much less money than we actually think we have.

Debian i386 to amd64 conversion

October 9th, 2008

After doing this two times, I finally conclude that it *is* possible to convert an i386 debian installation to an amd64 one. At the end of the procedure most of the system will work. Here is how:

NOTE: Don’t do anything that is mentioned here unless you fully understand what you are doing. You will most probably need to customize this procedure a bit!

You’ll need enough free space for the procedure to work.

While you still have a working system, print this document and download the latest debian netinst image. This can be used as a rescue disk if something goes wrong. It is trivial to restore your system using a rescue CD since we will not delete anything at all.

Step 1: Backup

I cannot stress this enough. Backup all your data, especially databases and anything binary that needs an executable file to be accessed. Most probably files at your home directory don’t risk at all but better be safe than sorry.

It is absolutely essential to backup your PostgreSQL database if you have one. The i386 and amd64 disk formats are not compatible (bad postgre… bad bad) and you’ll need to restore the database. This most probably comes to:

# # Backup:
# su - postgres
$ pg_dumpall > mydump
# # Restore
$ cat mydump | psql template0

I’ve done this procedure twice without backing up anything :-) except from the PostgreSQL database which is required. The reason I didn’t backed-up anything is that I was sure I could rollback to my old system using a rescue CD. If you don’t know how just backup.

Step 2: Install an amd64 kernel
You’ll need to boot your i386 with an amd64 kernel. Do:

# apt-get install libc6-amd64 linux-image-2.6-amd64
# # Most probably you would like to have X working while you run this procedure so install your favorite closed-source modules too:
# apt-get install nvidia-kernel-2.6-amd64

and reboot

Step 3: Install a base amd64 system.

# mkdir /amd64
# dpkg --get-selections '*' > /amd64/sel1
# debootstrap --arch=amd64 lenny /amd64 http://myproxy/

(NOTE: The above code was corrected to include “–arch=amd64″ which I forgot to include. Thanks to Slawek Wernikowski)

Step 4: Install an identical amd64 system
Since this is a time consuming procedure and many things can go bad, I suggest you run this under “screen”. This way, if the X server crashes you will not loose what you’ve done.

# chroot /amd64 /bin/bash
# vi /etc/apt/sources.list
# # Add all sources.list entries that exist in your main system but not the CDs
# vi /etc/apt/apt.conf
# # Add the line: APT::Default-Release "your-release";
# # if needed
# apt-get install locales
# mount /proc
# mount /sys
# mount -t devpts none /dev/pts
# export TERM=xterm
# dpkg --set-selections < /sel1

Now run the following lines until everything is installed. Most probably parts of the installation may fail and you’ll need to rerun those commands. It should be OK. At the end there can be some packages that will not be configured. Just ignore them for now.

# apt-get -o 'Dpkg::Options={"--force-confdef";"--force-confnew"};' dselect-upgrade
# dpkg --configure --force-confdef --force-confnew -a

I repeat: You’ll have to repeat the above commands until everything is installed. If you have trouble just fix it yourself. Don’t forget that you’re working in a chrooted amd64 system.

Step 5: Change the system
This is the part that I don’t have written so there might be some this missing. Key points are here and you should be able to figure what you need to do if something goes wrong. It is really a very simple procedure:

# init 1
# mkdir /i386

# # Move /usr
# mv /usr /i386
# mv /amd64/usr /

# # Backup etc
# cp -pR /etc /i386

# # Move /lib32 and /lib64 away if they exist
# mv /lib32 /i386
# mv /lib64 /i386

# # Create links
# ln -s /lib /lib64
# ln -s /emul/ia32-linux/lib /lib32

## Move other dirs
# mv /amd64/emul /
# mv /sbin /i386
# mv /amd64/sbin /

Now is the tricky part where you move /lib and /bin:

# # /bin is easy
# mv /bin /i386
# /i386/bin/mv /amd64/bin /
# # Don't forget that you can only run commands from /i386 from now on until /lib is replaced.
# # So, to do ls just write: /i386/bin/ls

# # Time for /lib
# mv /lib /i386
# # At this point you cannot execute anything at all but don't panic. Just run everything using the runtime linker. This is what happens whenever you run a command.
# export LD_LIBRARY_PATH=/i386/lib
# /i386/lib/ld-2.7.so /i386/bin/mv /amd64/lib /
# # TATA! Welcome to your amd64 system!
# ls

Step 6: Fix /var
This step is highly dependent on what you have installed. Most probably you can remove old /var and keep the new one. If you’d like to keep the old one there are some dirs that you need to replace:

# cd /var
# mv cache cache.i386
# mv /amd64/var/cache .
# # I suggest that you replace the whole /var/lib tree:
# mv lib lib.i386
# mv /amd64/var/lib .

Whatever you do you should know that you should replace /var/lib/dpkg and /var/cache/apt with the new one.

Step 7: Make system bootable
Finally you should ensure that your system is bootable. A nice approach is to clean your /boot from whatever kernel is installed (don’t forget that with your new system, no package will own existing kernels) and force-reinstall your current kernel:

# cd /boot
# mkdir i386
# mv System* initrd* vmlinuz* config* i386
# apt-get install --reinstal linux-image-2.6.26-amd64
# # Replace linux-image-2.6.26-amd64 with your current kernel

This is it. Unless I’ve forgotten something you should just reboot to your know system. After rebooting you will have to fix the unconfigured packages and possible rerun dselect-upgrade:

# dpkg --configure -a
# apt-get dselect-upgrade

Finally, restore your PostgreSQL database and you’re done.
MySQL doesn’t need dump and restore but wou’ll have to copy/move old files from /var/lib.i386/myslq to /var/lib/mysql.

VMWare Server 2 RC2 fails to boot VMs

September 29th, 2008

For a couple of days now, VMWare Server 2 RC2 was refusing to start virtual machines. It kept waiting at 95%.

It turns out that VMWare cannot boot virtual machines (or upgrade them) when kernel modules kvm_intel, kvm etc are loaded.

Here is the error message from hostd.log:

Question info: The virtualization capability of your processor is already in use. Disable any other running hypervisors before running VMware Server.

Of course the obvious solution is to rmmod the kvm related modules:

# lsmod |grep kvm
# rmmod kvm_intel
# rmmod kvm_amd
# rmmod kvm

The modules are most probably auto-loaded by /etc/init.d/kvm (but there may be other reasons too).

Run secureley wireshark as a user

September 21st, 2008

Sometimes there is the need to allow normal users to run wireshark and capture packets from the network. Running wireshark with sudo is a security hole since anyone can overwrite any file.

A secure one-liner that solves this problem is:

# (sudo dumpcap -w -) | wireshark -k -i -

Assuming that sudo is configured to allow the user to run “dumpcap -w -” as root.

This should be 100% secure (except from the traffic monitoring issue) and will work well in (for example) labs.