Hacker's ramblings

Something weird happens in OS X Terminal locale settings. Whenever I open an SSH-connection to one of my Linux-boxes, they refuse to properly set up an UTF-8 locale.

The session goes something like this. Checking locale settings on OS X terminal:

$ locale
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

Open SSH-connection and check locale settings on Linux end:

~> locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LC_CTYPE=UTF-8
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Aow come on! Something went wrong.

The fix on the OS X end is not to set the environment variables. In the Terminal settings, there is:

The setting Set locale environment variables on startup needs to be UNset. It is checked out-of-the-box. Then it yields:

$ locale
LANG=
LC_COLLATE="C"
LC_CTYPE="C"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

The LC_CTYPE is not set. Over SSH-connection to Linux, it yields:

~> locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Now there are no error messages. The next thing to do is to try to find somebody responsible. Whose job it is to fix this.

The H-Security blog wrote about Skype reading all the messages you type. They had seen weird traffic into their website after posting the URL into Skype. Read all about it from their blog entry "Skype with care – Microsoft is reading everything you write". There is also Ed Bott's article about how H-Security guys got it wrong the first time, meaning that they don't check your links.

Anyway, this is absolutely something I had to check out. A perfect candidate for this is our Development Lab test server. In testing phase we're in public Internet so that all the parties can test our upcoming version. There are 0 links to the site, but for some reason Google has indexed a number of pages from there. The information I got is from http://www.wholinks2me.com/

What's strange here is that I had to change the domain names couple of weeks ago, to make our testing process more exact what version we're testing. Also, knowing our people I'm pretty sure that nobody publishes the test-server links in any of their wesites, I know I don't. So, the question raises: where did Google get the new address from?

When I changed the domain, I did send an e-mail about it. Yep, you got it right, our team is using Google Mail. For the purpose of full discousre: on the site there is also Google AdSense advertisements and Google Translate tool.

I investigated 10 days worth of web-server logs. In that there are 18 distinct IP-addresses where the server was accessed from. A short investigation of all 18 addresses revealed that 8 of them can be easily explained. They are home and office IP-addresses of our team. What was strange that 5 of them were from Amazon EC2 and Google networks. I have no reasonable explanation why they are accessing my site. So it is very easy to come up with couple of conspiracy theories when something like that happens.

Earlier I wrote about Linux 3.8 SCSI failing to operate under Hyper-V. Finally Microsoft has done something about it. After all, they are the biggest contributor for Linux kernel when it comes to running as a Hyper-V guest.

There is a patch-set fixing number of issues, for example: "Update the storage protocol to the win8 level." This means that they have seriously investigated the problems and fixed them. Also in the patch-set there are some new features, however, which are directed towards datacenters, not nerds like me running a Linux-box in the corner.

Great work from Mr. Srinivasan from Microsoft! Thank you for that.

I'm a big Dojo fan. Its loading system makes it really fast on front-end. Also Dojo integrates well with Zend Framework.

ZF 1 is being phased out, but I haven't found the time to migrate into version 2 yet. Meanwhile Dojo / Dijit / Dojox will get updates, but they're not being compensated into ZF 1.

Here is my Zend Framework 1 patch to make Dijit components AMD-loading compatible. It makes Zend Framework Dijit-modules to use the slash-notation in paths. Especially in Dojo 1.9 using dots will yield errors like:

mixin #1 is not a callable constructor.

or

base class is not a callable constructor.

The errors vary depending of what you're calling. Pretty much your JavaScript ceases to execute. The problem comes from the fact that Dijit does not function exactly the same way it used to do before 1.9.

Failing example:

<div data-dojo-type="dijit.MenuSeparator"></div>

Working example:

<div data-dojo-type="dijit/MenuSeparator"></div>

The difference is minimal, but makes everything tick again.

It seems that out-of-the-box Serendipity does not support X-Forwarded-For -header. It means that any proxy in between loses original client information.

Here is my suggested patch to fix the issue:

--- serendipity/include/functions_comments.inc.php.orig 2013-01-25 14:10:03.058973150 +0200
+++ serendipity/include/functions_comments.inc.php      2013-05-14 11:34:35.302389894 +0300
@@ -782,7 +782,13 @@

     $title         = serendipity_db_escape_string(isset($commentInfo['title']) ? $commentInfo['title'] : '');
     $comments      = $commentInfo['comment'];
-    $ip            = serendipity_db_escape_string(isset($commentInfo['ip']) ? $commentInfo['ip'] : $_SERVER['REMOTE_ADDR']);
+    $ip            = serendipity_db_escape_string(isset($commentInfo['ip']) ?
+                        $commentInfo['ip'] :
+                        (
+                            isset($_SERVER['HTTP_X_FORWARDED_FOR']) ?
+                            $_SERVER['HTTP_X_FORWARDED_FOR'] :
+                            $_SERVER['REMOTE_ADDR']
+                        ));
     $commentsFixed = serendipity_db_escape_string($commentInfo['comment']);
     $name          = serendipity_db_escape_string($commentInfo['name']);
     $url           = serendipity_db_escape_string($commentInfo['url']);

This works on 1.6.2 and 1.7.0.

My choice for creating PDFs is PDF creator from pdfforge.org. The price is right (free), all the functionality I need is there, operation is robust and source code is available.

However, something weird happens occasionally after a new version is updated. Printing fails with an error stating that MSCOMCTL.OCX has failed. The failure is strange, as it is simply about ActiveX-component registration that has been lost. Also fix is simple, run following commands as administrator:

cd C:\Windows\SysWOW64
regsvr32 MSCOMCTL.OCX
regsvr32 MSCOMCT2.OCX

Then operations continue as expected.

Note that the directory is 32-bit on 64-bit Windows.

Earlier I wrote about getting a Linux-based NAS-box to host Apple Time Machine backups.

I was reviewing my settings on the Mac and realized the text in the Time Machine:

Well... I have lots of disk space there. Not all of it is can be taken by my Mac's backups, so ... Something needed to be done.

I mounted the AFP-share and confirmed the max size of my sparsebundle:

hdiutil imageinfo Mac\ mini.sparsebundle/

It said (unsurprisingly):

Size Information:
 Total Bytes: 8855484092416

That is 8+ TiB!! Oh my! There is no way that I can afford to have that much of Apple backups. Luckily there is a way to reduce the size:

hdiutil resize -size 500g -shrinkonly Mac\ mini.sparsebundle/

Now checking the size will yield something reasonable (500 GiB):

Size Information:
 Total Bytes: 537214885888

That is something, that I can easily accept.

The information came from:

• http://untoro.wordpress.com/2011/06/07/how-to-limit-space-used-by-time-machine/
• http://nikhilhaas.com/blog/limit-size-of-time-machine-backup-on-wd-my-book-live/

Also I did this to limit the size. I have no idea if it actually does anything.

defaults write /Library/Preferences/com.apple.TimeMachine MaxSize 405600

Perhaps somebody can comment this.

This is a follow up for my earlier post about Acronis experiences.

So, I decided to get a new motherboard/CPU/memory -triplet. I did what I usually do, except this time I was using Acronis and this time my computer had fake RAID-1 drive from ICH10R-chip. At the time I didn't think none of this matters, I just went forward with the hardware upgrade. New components booted the first time without any real issues. I re-configured the existing drives with the RAID-1 and booted to the Windows for the first time.

My boot drive is SSD, and I have large RAID-1 array for files. I got into Windows, logged in, plenty of grievance as expected. Lots of new devices found, RAID-missing, etc. no real surprises there. I re-partitioned the RAID-1 drive and started Acronis. The idea was to do a restore of my previous data and go forward with configuring the new parts. To my surprise, Acronis announced that it cannot do a restore into my D:-drive. Initially I didn't think much of it, since Acronis said, that it needs to reboot and restore will continue. Sounds good to me.

After the reboot I was in a Linux-environment with Acronis pretty much automatically doing everything. The only choice was to abort the restore and two checkboxes. Shutdown after restore or reboot after restore. There was 800 GiB of data and estimate was 7 hours. I checked the shutdown and left.

Next day I came back to see what happened. PC was shut down. Most likely the restore succeeded and shut down after completion. I booted into Windows to see that there was no D:-drive. The partition was gone too. WTF?!

During following days I repeated the process 3 more times with varying parameters from restore. No results. Windows saw my RAID-1 mirror as a raw partition each time. No files, no resonable results. It would be fair to say that I was pissed. What a piece of crap backup software! The value of backup is in the possibility of doing a restore of it. This "fine" product didn't deliver. Unbelievable!

Next I got a Fedora Linux 18 Live DVD to see how my drives were visible there. Then the idea hit me! In out-of-the-box Linux, a fake RAID ICH10R mirror is seen as two physical drives. Not as single RAID-1 volume. Sure, the volume can be configured into Linux too, but out-of-the-box it didn't do that. What are the chances Acronis' restore Linux does the same? I'd bet serious money on that.

So, apparently in ICH10R there is offset in the drive if it is configured as RAID-drive. Many real RAID-controllers don't do that. A RAID-mirror is two physical drives mirrored and you can take either one of those and it will work as JBOD.

Acronis' knowledge base recommended doing the restore in Windows (sorry, I lost the articlea already). So, The next thing I did was to purchase a True Image 2013 Plus Pack. I got Windows 7 AIK, installed it, installed the newly purchased Plus Pack and started to create a Windows restore image. The image maker did something for a while and then "Error occurred while creating the image". Nothing more. No details. No log-file. No nothing. Completely useless piece of crap!

So, I spent around 9 days while trying to get my data back. I had purchased even more crappy software from Acronis, and had no joy from my new parts.

I went back to square one. Why doesn't the partition restore start in Windows? Why does it say, that it needs to reboot and go to Linux? WTF?! I investigated more and realized that whenever I create a D:-drive, it gets locked by operating system right after it get's ready. That must be the reason for Acronis to want a reboot.

SOLUTION:
I created the RAID-1 array, quick-formatted it as NTFS, but assigned it as H:-drive. Now Windows didn't want to lock that. Apparently my yet-to-be-restored data had something the OS wanted. The data wasn't available, but OS happily locked the drive while hoping for the data to appear. I did a restore to the H:-drive. This time it took 10 hours. Apparently Linux restore is much faster (or they both took 10 hours, I don't know).

After the restore completed, I just re-arranged the drive letters so that my succesfully restored RAID-1 mirror got the D:-letter again. A reboot and everything was fine! Uuu-jeah! Oh happy, oh joy!

PS. If anyone is interested. There are 3D Mark 20111 results from my box publicly available.

I'm a fan of Trac wiki / issue tracker. It has the correct price (free) combined with all the features I need in software development. Since all my Linux-development is done in RHEL / CentOS -environment, getting a Trac to run requires tweaking. Also after our production server hit the 10k-connection limit and we had to change to Nginx, I don't have any Apache daemons running. Given that constraint, I definitely need some tweaking of my own.

Software needed:

• Nginx, get my RPM from http://opensource.hqcodeshop.com/CentOS/6%20x86_64/Nginx/
  
• uWSGI, get my RPM from http://opensource.hqcodeshop.com/CentOS/6%20x86_64/uWSGI/
• Trac, get my RPM from http://opensource.hqcodeshop.com/Trac/
  

Setup:

Traci is built with Python, but it is typically installed anyway. uWSGI is the glue between Nginx and a Python app. My uWSGI should run out of the box. It defaults to seeing Python apps in directory /var/www/uwsgi/, so make sure to create the Trac parent file trac_env_parent.py into it:

# -*- coding: utf-8 -*-

# file: trac_env_parent.wsgi

import sys
sys.stdout = sys.stderr

import os
os.environ['TRAC_ENV_PARENT_DIR'] = '/var/www/uwsgi/trac'
os.environ['PYTHON_EGG_CACHE'] = '/var/www/uwsgi/.egg-cache'

import trac.web.main
application = trac.web.main.dispatch_request

Also it is a good idea to make sure, that uwsgi-user can write into the .egg-cache-directory. Permissions should be:

drwxr-xr-x.  2 uwsgi uwsgi  4096 Jan  8  2012 .egg-cache

Then bind Nginx into uWSGI-app. In my case I defined a virtual host for that. Fragment of nginx.conf:

server {
    listen [::]:80;
    server_name my.trac.own.com;

    location / {
        include        uwsgi_params;
        uwsgi_pass     127.0.0.1:9001;
    }
}

The file /etc/nginx/uwsgi_params is something out of a default Nginx source. I didn't change anything in it.

After that it's only getting the Trac properly configured with your DB-backend and filesystem.

What others are doing:

• http://projects.unbit.it/uwsgi/wiki/Example
• http://mediacorecommunity.org/docs/install/nginx-uwsgi.html

Dojo JavaScript framework has a nice system of packaging the library for your own app. During packaging you may minify the library, reduce the number of files being loaded and leave unnecessary parts out from it. However, ever since Dojo 1.7 the build system is pretty complex and documentation is almost non-existent. There is zero beginner documentation, the existing documentation is aimed towards those, who already know their way around.

The prerequisites for doing a Dojo build is Node.js and Java runtime. The rumour is that build would work with either one of those, but I most definitely cannot confirm that. My production and development boxes have CentOS 6.4, so initially I did not have either one of those installed. To comply with requirements, I installed my own build of Node.js 0.10.4 and for Java OpenJDK 1.7.0 (the package is called java-1.7.0-openjdk in CentOS).

My CentOS 6 RPMs of Node.js are available at http://opensource.hqcodeshop.com/Node.js/ if you need them.

Then to the Dojo-build. There is the IMHO crappy docs at http://dojotoolkit.org/reference-guide/1.8/build/. Most of the stuff I needed to figure out, I had to Google or look from the source. When you unpack the source-package you'll end up having an util/buildscripts/profiles/ directory, which does not exist in the release (minified) package.

A build profile is kind of a makefile. It instructs the build what to package and how. To my great surprise they changed the profile style and you'll find two different styles:

1. Old style:
   • dependencies = { / A JavaScript object definition here / }
2. New Style:
   • var profile = (function(){ / A JavaScript object definition here / });

A standard Dojo release build is done with profile named standard (no surprises there, huh?). The command for doing that would be, for example:

./util/buildscripts/build.sh profile=standard version=1.3.2-dev \
 releaseName=dojo-release-1.3.2-dev cssOptimize=comments.keepLines \
 optimize=shrinksafe.keepLines cssImportIgnore=../dijit.css action=release

I tried to emulate that with a new-style profile file of my own. The profile-file has most of the command-line parameter in it, so running it will be much simpler, copy the profile into profiles-directory and something like this will do:

./util/buildscripts/build.sh profile=Dojo-JaTu cssOptimize=comments.keepLines \
 cssImportIgnore=../dijit.css action=release

There are number of choices you may do with the profile, for example you may choose not to minimize it, by changing following:

mini: false,
optimize: false,
layerOptimize: false,

This produces a built, but debuggable file which is much nearer to release than the source-package. You see, the build will replace number of options with structures like
if (1) { / then something / }, which initially look strange, but in reality just reflect the hard-coded changes you made during build. The release version will have those anyway, no matter which release version you'll use. Doing your own custom build, you'll have a control over which parts of the code are in and which are out.

I still haven't grasped the "layer"-concept fully. A layer is a single file containing a number of Dojo-modules. Anyway, that definitely is something worth studying. It will yield much faster loading web pages.

Trying to wrangle Dojo and struggling with its build system took me a nice working week. That was time well spent. Now I can make my own tailored Dojo-packages for a production site which loads really fast.

Earlier I've studied Chinese domain name scams (part 1 and part 2).

A while ago I read about a study made by Mr. Giovane César Moreira Moura. Actually, the study is his PhD thesis and it is available from his page at University of Twente, Netherlands. Anyway, he claims that roughly 50% of the crap in the Internet is originating from 20 rogue networks. He researched 42.000+ ISPs and found out that e-mail spam, scam attempts, etc. are originated pretty much from the same places. He does not do much finger-pointing, but provides the idea how to produce the results.

His study inspired me to investigate the origin networks of all the crap my honey pot was receiving and do some finger-pointing (I don't have any restrictions about that ). My "honey pot" is a 20+ year old e-mail address. It is in every imaginable spammer/scammer/crap magnet -list. My results are badly skewed: when it receives junk, I'll manually tag it and report it to SpamCop (a spam-protecting service owned by Cisco Systems, Inc.), and eventually blocking the IP-address as a spammer. Since the mail server uses SpamCop blocking-list I won't receive any more junk from the IP, which for studying spammers is not good.

There is lot of evidence that most crap originates from hijacked computers, but not all. Some of spam arriving to me originates from VPS-boxes. I dunno if they are rented with real or stolen credit cards. Anyway, most spam I receive have some sort of forging attempt in the mail headers. So I'm utilizing  tracing of non-forged e-mail origin with SpamCop's reporting tool. In his thesis Mr. Moura writes that the ultimate origin is almost always not discoverable. Hiding one's real location is way too easy in the Internet. Closing the sending IP typically helps, but leaves the criminal unidentified.

Anyway, here's my list:

1. 30, IRINN-BROADCAST-ADDRESSES, India
2. 9, GOOGLE, USA
3. 8, PAET-FSS-IMPLI-1, USA
4. 5, FR-OVH, France
5. 3, 66-132-128-0-NET, USA
6. 3, EGIHOSTING-4, USA
7. 2, 1AN1-NETWORK, USA
8. 2, DROPBOX, USA
9. 2, NLYR-ARIN-BLK5, USA

The number is number of e-mails originating from that network followed by the network name. The list was gathered during 90 day period. In the list there were additional 80 networks with only single e-mail originating from them.

Most of the crap I receive originates from India. 2nd biggest seems to be Google. Also a huge virtual server renting company OVH-net is in the 4th place. Others I cannot explain. Another conclusion I can draw from these is that the 20 worst networks are not the ones bothering me.

My gaming-PC is couple years old and one day it didn't want to sleep anymore. Which is pretty weird. It has been working ok since I built it, but now something really weird happened. I Googled a couple of articles with keywords "windows 7 random wake from sleep" to confirm that it's not just my breaking down hardware, but a real issue.

Normally I don't shut down my PC, I just let it sleep when not being used. It is pretty modern piece of hardware and does not consume very much electricity during sleep. It also "boots" from the sleep pretty fast on a mouse or keyboard click. My initial fix was to reboot it and shut it down, and even turn off the power supply power to make sure it stays down. No matter what I tried, it just keeps popping up after random period of time. It could be 15 minutes or couple or hours.

Mr. Jack Ukleja found the actual reason for this behaviour. He has an execellent article in his blog. It appears that network adapter's Wake on pattern caused this. He also describes a way to see why Windows was woken last time. In my case Windows power configuration somehow gets it wrong. When I do a:

 powercfg -lastwake

from command line, it gives me:

Wake History Count - 1
Wake History [0]
  Wake Source Count - 1
  Wake Source [0]
    Type: Device
    Instance Path: PCI\VEN_8086&DEV_1503&SUBSYS_849C1043&REV_05\3&11583659&0&C8
    Friendly Name:
    Description: Intel(R) 82579V Gigabit Network Connection
    Manufacturer: Intel

... which most certainly is not the case here. I tapped a mouse button to wake this up.

Anyway, in his case he had a Realtek Gigabit Ethernet NIC and fixed the issue by disabling Wake on pattern from NIC's advanced settings. Even though I have an Intel Gigabit NIC, I had to try the same. It helped. I don't know if it is a factor, that in my PC there are two NICs and the another one is a Realtek Gigabit NIC. Anyway, now my PC is back in order. It stays sleep when I put it to sleep the way it is supposed to do.

My cloud storage choice has been LaCie's (the hard drive company) Wuala. The main reason why I did choose Wuala is in their Privacy Policy:

2. Stored Content

Wuala encrypts all your files before they leave your computer. They are encrypted such that only you and those you have authorized can decrypt them. Even LaCie cannot decrypt them unless you have made them public or share them by secret weblink and access them with your web browser. In the latter case, the encryption key is temporarily sent to our web server as part of the URL for the purpose of serving the requested data.

They do exactly like Kim's MEGA. They encrypt everything so that even they can not access it (or at least that's what they claim to do, nobody has yet proven that wrong, though). That is: unless you choose not to encrypt the data, or publish the decryption key, but then it is an another story.

The sad thing is that they use Java on client-side to do the access. Java Runtime has been described as a disease in an article in the Forbes magazine. They're right. It is a disease. In Wuala's own discussion forum there are a number of happy customers pleading to stop using Java.

What really pisses me off is that on my 64-bit Windows 7, the only reason to have a 32-bit JRE is Wuala. All my other software utilizes the 64-bit version I also have installed. Whenever a new JRE version comes out, I need to update both versions. Also I simply cannot use Wuala on all of my computers. For security reasons, I refuse to install Java Runtime into them.

Wuala: Stop using Java now! Please.

Earlier I wrote about Hyper-V crashing with BSOD. The entire project was doomed from the beginning. After I managed get the Windows not to crash, all I managed to do is get the Linux installer to hang whenever it attempted to anything major on the hard drive. I configured Hyper-V to provide the hard drive from a .vhdx-file, so I initially suspected that old .vhd-file might help, but no, nothing helped. Any minor operations succeeded, but any sort of normal usage made the Linux to hang.

Symptoms include:

• Console message: "INFO: task jbd2/sda blocked for more than 120 seconds" and instruction to deactivate the warning with:
  echo 0 > /proc/sys/kernel/hung_task_timeout_secs
  Example:
  • http://helpinlinux.com/tag/echo-0-proc-sys-kernel-hung_task_timeout_secs/
• Repeated "Sense Key" -messages in dmesg, example:
  • http://forums.gentoo.org/viewtopic-t-734696-view-next.html?sid=64f39476a9b96703e2a2c998023729b9
• No change in /sys/block/sda/stat:
  • Kernel documentation about block-device stat says that columns 3 and 6 contain the number of sectors read and written.
  • In my hung box, the values don't increase.

I was puzzled about this for a very long time. It took me several hours to bump into Linux-SCSI mailing list's discussion about the issue. There Mr. Olaf Hering describes an issue "storvsc loops with No Sense messages".

Luckily Mr. Hering realized what's going on and made a patch to fix the problem. Unfortunately the fix is not yet pushed into mainstream Linux kernel.

Since I was about to install ArchLinux, I took the trouble of compiling the necessary kernel module of hv_storvsc.ko into following kernel versions:

• 3.8.4, used in installation ISO-image:
  • SHA-1 sum: 74d2a5de73a4c7d963b649eb34b171eba86a268c
• 3.8.6, the version that got installed when I got my install done:
  • SHA-1 sum: 57a4216fc6749085820703d47cd87dcce47b1739
• 3.8.7, the version that it upgraded into when I did a system update:
  • SHA-1 sum: 3f8757ab69c97a6389c7c83a8ef57f16e9caa85d

All of the packages are available for you to download at http://opensource.hqcodeshop.com/ArchLinux/2013.04.01/. Your only trick is to get them replaced into initial RAM-disk -image. I just replaced the original file at /usr/lib/modules and re-ran the mkinitrd-command.

There was an update to my Fedora 17 Linux and among others, I got a new kernel. I didn't notice it at the time, but the reboot ate one of my Ethernet interfaces. There are two NICs on the motherboard, but on top of those, I have an Intel multi-port NIC. So in the end, there are more than your usual dose of ports.

Traffic to one particular LAN didn't function and I started to investigate:

# ifconfig -a
...
rename5: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether 90:e2:ba:1d:33:f1  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0xfe7e0000-fe800000

Well... I don't remember which one of my Ethernet-ports was rename5 after installation. Typically they are something like eth0, eth1 and so forth. Modern Linuxes tend to add more complexity with names like p2p2 or so, but I've never seen rename5-type naming.

From that I concluded that udev goofed up something. Fedora 17 does not create the /etc/udev/rules.d/70-persistent-net.rules-file which would solve my problem. Lot of Googling later, I found this page, it contains very useful Perl-script to dig enough system information and report it in udev-compatible format, in my case it yields:

# perl /root/bin/write_udev
...
# Added by 'write_udev' for detected device 'rename5'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="90:e2:ba:1d:33:f1", NAME="rename5"

I created the persistent rule -file and added above into it. I just edited the NAME-part and renamed the interface properly.

Getting the rules to take effect was bit tricky. None of these worked:

udevadm trigger
udevadm control --reload-rules
udevadm trigger --attr-match=address='90:e2:ba:1d:33:f1'
udevadm trigger --sysname rename5

The trick was to get the full path with udevadm trigger --verbose --sysname rename5 -command and use the test-command with the full path:

udevadm test --action=add /sys/devices/pci0000:00/0000:00:06.0/0000:02:00.1/net/rename5

Then I got my new rule to take effect immediately and my interface up and working.