Stuxnet... the origin... and implications...

Wow! I was reading Jeffrey Carr's post in which he admits being wrong about Stuxnet origin, and he references this article that made him change is minde. It is definitely a fascinating read about Stuxnet, how it was conceived, developed and used. I recommend that you take a time and read it! Namely, for several years now you'll find all over the Internet accusations that Chinese government is attacking western companies and governments. But this shows that other governments aren't sitting and doing nothing. Moreover, this article shows that malware has been brought to a new level of use in which it is used as attack weapon, to cite the article: Somebody crossed the Rubicon.

I suppose this will have a huge impact and lot of implications:

1. Russia is pushing towards some kind of international treaty that would regulate use of cyberweapons. One of the advocates of this is Kaspersky, but there are also critiques. Anyway, this article gives a push to Russian government intentions.
2. What impact will this have to closed source software? Because, no one can never be sure what's in there, especially if the company producing this software is under control of foreign country. Now, Microsoft already gave access to source code of, I think India among others, but this also means that Indian secret services can find bugs and use it against other countries? Sounds like Games without frontiers...
3. Antivirus software, NIDS, HIDS and usual protection doesn't help here! They relay on a mass, i.e. someone gets infected but this allows anti virus companies to analyze threat, to create signatures and to update anti virues software so that huge majority is protected. These are, in a way, custom made attack programs.
4. With a backup of government agencies, these attacks can be very sophisticated. But note that anyone with enough resources (i.e. reach enough) can do the same.

All in all, very interesting and far reaching developments...

Fedora 17, XeLaTeX and Beamer...

I decided to write this post about XeLaTeX and my attempts to process one presentation written using Beamer class into PDF file. The reason is that I certainly lost few hours trying to resolve the set of errors, and maybe someone finds this information/experience helpful.

The first problem I had after starting xelatex was the following error:

! Package pgfsys Error: Driver file ``pgfsys-xetex.def'' not found..

See the pgfsys package documentation for explanation.
Type  H   for immediate help.
 ...                                             
                                                 
l.847 ...ver file ``\pgfsysdriver'' not found.}{}}
                                                 
? X
No pages of output.

So, I tried to find out which package provides this file using yum. But, no luck there. Then, I continued with google-fu. I found many links, but nothing that could be applied to my case, until I stumbled on this solution which basically tells me to copy one existing pgfsys file into the missing file, without any changes. What this post doesn't tell you explicitely is that you have to run texhash after that so that tex's file database is rebuilt.

When I again started xelatex, this time it seemed as if it will work! It was processing files and constantly giving some output. But no! At one point it stopped and I got the following error:

(/usr/share/texmf/tex/latex/beamer/themes/font/beamerfontthemeserif.sty)
! Font \zf@basefont="TeX Gyre Cursor" at 10.0pt not loadable: Metric (TFM) file
 or installed font not found.
\zf@fontspec ...ntname \zf@suffix " at \f@size pt
                                                  \unless \ifzf@icu \zf@set@...
l.80 ...d,NoCommon,NoContextual}]{TeX Gyre Cursor}
                                                 
?

Back to google-fu! Still, for this one it was easier to identify what's the problem. Namely, the font is missing (Metric (TFM) file or installed font not found). Again, using yum I found out that this font isn't packaged with Fedora 17 but it can be obtained from here. I downloaded zip archive, unpacked it, and moved all the font files into /usr/share/fonts/otf directory (before that I created otf subdirectory as it didn't exist). Afterwards, everything worked and presentation was successfully created. Note that I initially tried to place those fonts into /usr/share/texmf/fonts/opentype/public/tex-gyre/ directory. But that didn't work for unknown reason!

And guess what?! Now the source tex file was successfully transformed into PDF file.

While googling to find out solutions to problems I had, I realized that TeXLive distribution in Fedora 17 is 2007, while the newest version is 2011 with 2012 in development. Furthermore, I found out that  there is a plan for Fedora 18 to update TeXLive to at least version 2012. Since beta (or alpha) packages are readily available for F17, and I felt bold enough, I decided to give it a try.  So I installed repository per instructions on a given page and run 'yum update', and after a long wait, I tried again to run xelatex on the beamer presentation. This time I was completely out of luck:

kpathsea: Running mktexfmt xelatex.fmt
I can't find the format file `xelatex.fmt'!

For some reason, there was no xelatex.fmt file. As usual, first thing was to run 'yum whatprovides' to find out which package provides that file. But, none does! It seems to be a 'bug' in packages, so I had to revert texlive distribution. This was also a kind of a trial and error process, but to cut the story short what I did was: disabled texlive repository with experimental packages. Then, I used rpm to force removal of existing texlive packages, and then using yum I reinstalled the old ones (note that yum downgrade didn't work!). Finally, I used 'yum check/install' to fix any unresolved dependencies.

Upgrade to Fedora 17...

I upgraded to Fedora 17 using preupgrade tool few days ago. This is writeup with experiences of that process. Maybe it helps someone out there... :)

As I didn't want to reinstall everything from scratch, I decided to use preupgrade tool. Additional benefit of this tool is that it first downloads all the necessary packages and then start the upgrade proces. So, I started preupgrade in a mid of the day and it started to download all the necessary packages. Then, it asked me to reboot machine in order for upgrade to start. Since there were over 6000 packages to upgrade I decided to start the upgrade process in the evening when I' going to sleep so that the next morning the laptop is ready for use. Thus, I declined upgrade at that moment and continued to work as normal.

In the evening I started again preupgrade tool. This time, for some unknown reason, it complained because of third party repositories I'm using (more specifically, because of rpmfusion). So, I disabled all but Fedora's repositories and restarted preupgrade. Well, it went almost without any problem. The only thing that happened is that installer stuck somewhere around 1/3rd of the installation process and I only discovered it when I woke in the morning. After reboot it continued as if nothing happened so the only consequence was that I had to wait in the morning for it to finish. Otherwise, everything was OK.

Next, I decided to recompile OMNeT++ since I'm using it for some simulations. I'm using the newest version, 4.2.2. There was a minor problem because of newer gcc (it is 4.7.0) but quick googling gave solution immediately. It could be that if you are using some older version you'll have much more problems because of changes in the C++ compiler shipped with Fedora.

Then, I started yum in order to see what new gnome-shell plugins are available. As I started installation of one plugins, after the installation finished, yum showed a lot of errors like the following ones:

389-ds-base-libs-1.2.11.1-1.fc17.x86_64 is a duplicate with 389-ds-base-libs-1.2.10.6-1.fc16.x86_64

ConsoleKit-0.4.5-2.fc17.x86_64 has installed conflicts filesystem < ('0', '3', None): filesystem-2.4.44-1.fc16.x86_64

Obviously, something went wrong with preupgrade process. So, first I tried package-cleanup tool, but without any success. It wanted to remove packages, which a) isn't what I wanted, and b) it didn't managed to remove them anyway. Then, I tried recipe from this link. That one didn't work either. So, I ended up manually removing packages with yum and then installing them again. This took me several hours, not the best way to spend your time.

Finally, after solving that problem everything else seems to work. There is one thing that annoys me. gnomines is very slow to react on clicks. At the initial opening it takes 1 or 2 seconds to start, and after each click there is a noticeable delay. I don't know what causes it, but I certainly do hope that they will fix it soon. :)

Update 1 [20120605]
Ok, there is one additional issue I found out. But this one occurs every time I install new version of Fedora, so I already know what to do. :) Namely, if you are on a network where domain name ends in .local (e.g. server.local.) then DNS is not invoked but mdns4 is used. This is manifested in a way that those servers are inaccessible with a message Server not found, or something similar. Anyway, the root cause is in the file /etc/nsswitch.conf, i.e. the line that defines how host names are resolved is set to:

hosts:      files mdns4_minimal [NOTFOUND=return] dns myhostname

you should remove mdns4_minimal and the content within square brackets, so it should look like this:

hosts:      files dns myhostname

And that's it!

Update 2 [20120614]
Well, it seems that VMWare Workstation isn't working with a new Fedora. I'm using kernel 3.4.0-1.fc17.x86_64. Anyway, when I start vmware, it tells me that it has to configure vmware and then, during build process, the following error while building blocking FS appears:

make: Entering directory `/tmp/vmware-root/modules/vmblock-only'
make -C /lib/modules/3.4.0-1.fc17.x86_64/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
  MODULEBUILDDIR= modules
make[1]: Entering directory `/usr/src/kernels/3.4.0-1.fc17.x86_64'
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/dbllnklst.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/file.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/block.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/inode.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/super.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/control.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/filesystem.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/module.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/stubs.o
  CC [M]  /tmp/vmware-root/modules/vmblock-only/linux/dentry.o
/tmp/vmware-root/modules/vmblock-only/linux/filesystem.c: In function ‘FsOpReadSuper’:
/tmp/vmware-root/modules/vmblock-only/linux/filesystem.c:528:4: error: implicit declaration of function ‘d_alloc_root’ [-Werror=implicit-function-declaration]
/tmp/vmware-root/modules/vmblock-only/linux/filesystem.c:528:15: warning: assignment makes pointer from integer without a cast [enabled by default]
cc1: some warnings being treated as errors
make[2]: *** [/tmp/vmware-root/modules/vmblock-only/linux/filesystem.o] Error 1
make[1]: *** [_module_/tmp/vmware-root/modules/vmblock-only] Error 2
make[1]: Leaving directory `/usr/src/kernels/3.4.0-1.fc17.x86_64'
make: *** [vmblock.ko] Error 2
make: Leaving directory `/tmp/vmware-root/modules/vmblock-only'

The solution for this I found here. Basically, the function d_alloc_root has been renamed to d_make_root and that search/replace operation should be done within the archive vmblock.tar (in /usr/lib/vmware/modules/source/). Actually, there is only one occurence of d_make_root in file linux/filesystem.c.

Update 3 [20120822]
I had problem with Python setuptools because of upgrade. See here for details.