Operating systems - 7

This is a follow-up post on my previous post about Replacing Compaq 615 hard drive with a SSD.

It is obvious, that when you remove the old hard drive from your PC and replace it with a new one, all your stuff won't be on the new drive. "All your stuff" includes Windows operating system, your user profile information, settings, background picture of your desktop, all your precious photos, ... the list goes on. So to succesfully replace the hard drive, some preliminary steps are needed. Even in the best case, where you're prepared to lose all of your files and information, the only thing that you need to transfer is your Windows 7 license. In Microsoft lingo it is called The Activation. This literally means, that your Windows will emulate E.T. and "call home" to verify, that you are allowed to run the installation.

In this particular case following circumstances exist:

• The laptop in question is manufactured by HP/Compaq
• HP/Compaq is a Microsoft OEM partner and they get their Windows 7 licenses with special pricing
• The hardware must has a suitable identification for the OEM partner in its BIOS called SLIC
• Actual Windows 7 license (activation) will be stored on the hard drive, the OEM product key of this installation is not known
• It is impossible to transfer the activation from old hard drive to the new one. It is possible to re-activate on the new drive when the existing OEM product key has been extracted from the old Windows 7 installation.
• There is nothing illegal in this procedure. You bought the hardware, you own the hardware. With hardware you paid for the Windows 7 license. This is NOT software piracy of any kind.

Abandoned options

There are three good possibilities of transferring an existing Windows installation to the new drive. I chose not to use either of those.

It is possible to create a recovery disc from existing installation. This has been covered in articles How do I create recovery discs on a Compaq 615 and Creating Recovery Discs or Saving a Recovery Image to a USB Flash Drive (Windows 7). There was a glitch, though. The HP Backup & Recovery manager was not installed to this Compaq laptop. I found an article Download hp backup & recovery manager which points to softpaq sp45602.exe containing the installer.

Another way would be to use the Windows 7 built-in backup. There is an option to create the system recovery image. Apparently HP/Compaq chooses to go with this on consumer models.

Other possibilities would include Clonezilla, Acronis True Image, or similar to transfer the entire drive with all the partitions.

The reason why I abandoned all of those was that I definitely wanted a fresh start without any old payload. The HP Backup & Recovery would provide the cleanest start, but still there are a number of weird software being installed, which nobody actually needs or wants. Another thing is that Windows 7 fresh install on SSD takes care of setting the TRIM-flag to the partition and aligns the partitions properly on 4096 byte boundaries. Both of those settings differ when installing to a hard drive. These are pretty much the only differences when installing to SSD instead of HD, but I definitely wanted to get all of my performance settings right from the beginning.

Prerequisites for license transfer

When talking about OEM Windows 7 licenses, following license types exist OEM Channel SLP, NONSLP and COA License Product Keys. The difference of those is explained in detail in this article. To put it briefly, in every OEM machine there must be a sticker somewhere. The sticker has the Certificate of Authentication (COA) key. This OEM COA key can be used to activate a Windows 7 installation only via phone. It is a possibility, but not my first choice as there are other options available.

Every OEM Windows 7 also has an OEM System Locked Pre-installation key. The key is not available anywhere. It is hidden intentionally, for the reason that nobody would ever try anything I'm about to describe in this post. To dig out the SLP-key, you will need a special piece of software. My choice is The Magical Jelly Bean Keyfinder. There is a free edition available for download and it just magically tells you your Windows installation key. The smart thing to do is to use the export-option to an USB stick. You can copy/paste your license key from a file later when it is needed.

If you are interested in your settings and data, backup your user profile(s) with Windows Easy Transfer (migwiz.exe). I chose to save the profile data onto an USB hard drive to be restored later.

You must have OEM certificates for this the license activation to work. Download a the certificate bundle from https://docs.google.com/open?id=0Bxj5NEo7I3z9dWx3VndfenZBWVE. Your hardware manufacturer should be in the archive, if it is not, you cannot proceed.

Optional prerequisite is SLIC ToolKit V3.2. You can download one from https://docs.google.com/open?id=0Bxj5NEo7I3z9WE1NS2dVVjc4VEE. Using this tool really helps you in the process, because you can actually see if it would work and you can verify the steps.

Warning!
If you don't know your SLP-key DO NOT remove the old hard drive.

Installing Windows 7 to the new drive

Warning!
If you don't know your SLP-key DO NOT start installing to the new drive. Put the old drive back and use a keyfinder to get your key.

Update 2nd Jan 2016: My recent findings about possibility of recovering the key with USB-dock. With suitable hardware it is possible to read the key from already removed hard drive.

Update 13th Mar 2015: Microsoft took down their Windows 7 downloads from Digital River. They are not available anymore!
All the Windows 7 SP1 installation images are generally available for download. See Official Windows 7 SP1 ISO from Digital River about details. Again: This is not software piracy! You own the license for your Windows 7, you are entitled to own the installation media for it.

Download the exact version of your installation image. Language may be different, but not all OEM licenses are allowed for both 32-bit and 64-bit installations. If you are changing x86 to x64 there will be also issues with Windows Easy Transfer, it documented that the transfer wizard works only on same arcitecture. To see if your OEM license works both on 32-bit and 64-bit you simply have to test it.

If you need the language files see Windows 7 SP1 Language Packs Direct Download Links and the utility needed to install them Vistalizator. The language packs are different for 32-bit and 64-bit installations, so choose carefully. Windows 7 Ultimate can change languages from control panel, no special tweaks are needed for it.

During installation, choose not to enter a license key. You will end up having a non-activated Windows installation. The technical term is that your activation is on a "grace period". This is what we want to do. Activate later.

Re-activating the license on the new drive

Third warning: You will need your SLP-key for the re-activation to work.

In your Computer properties, there is an option to "Change Product Key". None of your OEM-keys will work there, no matter how much you try. Any activation attempts will yield something like this:

Activation Error code: 0XC004E003 (Product key already in use). There is a lengthy discussion of Clean OEM Windows 7 install returns 0xc004e003 @ Microsoft.

What you need to do is follow instructions from activating windows 7 OEM way. Open a Command Prompt (cmd.exe) and run it as Administrator.

First we confirm that the BIOS has required information in it. It definitely should as the machine had a working Windows 7 in it, but still ... run the SLIC tool to confirm:

It should say "Dump OK!". On the Advanced-tab you can confirm, that there are issues with the activation:

The SLIC status is on green and is valid, but private key and certificate have issues and display a red cert. error.

To fix this, my sequence differs a bit from the article. The first thing to do is to set your SLP-key, say something like this into your command prompt (no, that is not really my SLP-key):

slmgr.vbs -ipk J7JHT-BC3HD-73CQT-WMFJ-XXXXX

It should respond after a delay:

Next install your manufacaturer certificate, this will take a while:

slmgr.vbs -ilc HP-COMPAQ.xrm-ms

It should respond after a lengthy delay with something like this:

The last thing to do is to rebuild the certificate store, to start using all these changes:

slmgr.vbs -rilc

That should respond with a simple "Ok". Now you can confirm your activation status with a:

slmgr.vbs -dli

The response should be something like:

If you failed in this process, the response will look more like:

Upon success, the SLIC tool will also display the status as:

Slmgr.vbs is volume activation tool installed into all Windowses. See more details about it from Slmgr.vbs Options for Volume Activation @ Technet.

The successful activation can be confirmed also from Computer properties. At no part of this activation any network traffic to Microsoft or any other party is required.

Both Microsoft and your PC's manufacturer would like for you not to know anything about this. Both of their businesses rely on the fact, that hardware vendors and their partners will do all the maintenance for your PC while making money at it. Since hacking is about learning how computer stuff works, this is a prime example of hacking. With this information you can hack your own laptop.

Any comments are welcome!

Windows 8 (or 8.1) is one of the not-so-popular operating systems. Even Microsoft employees admit Windows 8 is 'the new Vista'. Ok, they failed on that. Perhaps Windows 9 will be better.

Now that we have that out, there are a number of weird things in that OS. The one bugging me most is the fact that the full screen app icons that appear when you move the cursor to the top-left corner of your desktop are failing to display. This happens to me very often. It seems to have something to do with sleep/hibernate on my Win8 laptop. It should look like this:

But it looks like this instead:

Not cool.
There are some shadows from the icons, but nothing usable or nothing that I could use to identify which icon is for which app.

I don't know what's the problem, but I found a fix. The culprit is your classic explorer.exe. The fix is simple. Zap your Windows Explorer with a magic kill process -wand and create a new better one. The new explorer won't know anything about already running full-screen apps, but it will sure learn if you manage to get into one.

Here is the fix. First start the Task Manager. Since the idea is to kill explorer.exe, you'll need a tool to eradicate the old one and make sure you can start a new one. The sequence starts from Task Manager's Details tab-sheet:

After that your explorer will be back and your icons will be back after you visit all of your apps.

Today, this tuesday, is the last time Windows XP gets security updates from Microsoft. Apparently Dutch and UK governments are willing to pay seven figure sums per year to keep their XPs running, but the rest of us, anything smaller than a government we don't get to have those. Last autumn I visited Windows 8.1 release in Helsinki and there a Microsoft MVP said "Microsoft is not that evil company, they just might release something really critical if it comes down to that". There was some chuckling in the crowd. Anyway, very interesting things will happen to XP, see the CVE-list for non-fixed flaws.

In Finnish media, the XP has gotten a lot of media coverage all year. I guess it got to the point of scaring regular users in the national TV. This I figured when my mother called me about her Windows 7. The another thing was at my neighbor's computer. She has an old XP-box with really poor specs. She asked for my help, but after initial assessment there was nothing I could do with her old computer. I happened to have an old Dell OptiPlex GX260 desktop computer with steroids, a SSD-drive in a ATA-to-SATA -adapter. I was about to do the decent thing and comply with EU 2002/96/EC directive, aka. throw the electronic junk where all electronic junk ends up at. The computer has only 512 MiB memory, but given the 2,0 GHz Pentium 4 CPU, it runs 2009 released Windows 7 in a reasonable acceptable manner. The best part for my neighbor was, that I promised to donate the hardware free of charge. It was only a matter of getting a license key for Windows 7.

My old OptiPlex booted from installation DVD without problems, I must say I was amazed about that. Any old low-quality CD/DVD-drive typically has issues with dust in the lens and the read head eventually deteriorates to the point, that the drive refuses to read anything. Anyway, the Windows 7 installer found the SATA-connected SSD-drive, the installer copied the files, booted for the initial Out-Of-the-Box-Experience. Everything seemed to be ok, I had network connectivity and even some sound.

What every legacy PC does after install is, that the display resolution is something unbelievable. This case I had a VGA 640x480. It sure looked nice on my 22" LCD-screen!
The thing is: no W7 drivers for my Dell. It seems to have a built-in Intel 82845G graphics adapter in it. The Dell support knows about my machine and the display driver in its Download Center, but the latest supported OS they have is Windows XP. WDDM driver model was introduced in Vista and XDDM drivers was the last one Intel ever did for 82845G. This was confirmed in Microsoft TechNet's Windows 7 IT Pro forums discussion How do I get Windows 7 Graphic driver for the Intel 82845G Graphics Controller?

Lucky for me, somebody had posted a link to another article For Older Hardware to Run on Windows 7 How to Install intel 82845G graphics driver on Window 7, and there was a solution for my exact problem. I didn't realize that it was possible to still use XDDM drivers, but it is possible. In device manager, there is a Add Legacy hardware:

I took the 82845G driver package 14.10.3, unzipped it and Windows 2000 XDDM driver installed. After rebooting the Windows 7, everything was ok. The driver actually claims it can go up to 2048x1536, but given the analog VGA-connector I chose not to go that far.

Finally, I installed Microsoft Security Essentials into it and I was done. My neighbor had a nice "new" computer till year 2020. I'm wishing people would upgrade before that, but knowing that doing nothing is always the preferred action on non-hackers, so plenty of people will be taken by surprise when Windows 7 updates run out.

I don't have a Windows-domain at home, so the Internet time client (NTP) is on relaxed settings. Your typical Microsoft documentation about NTP will have phrases like: "The default value for domain members is 10. The default value for stand-alone clients and servers is 15" in it. So, it really makes a difference if the computer is in a domain or not.

It is a well established fact, that the hardware clock on your computer is quite inaccurate. On a modern computer, there is no point in using expensive hardware to make the clock run smoothly, you can always set the time from a reliable clock source from Internet. That's what the NTP was made decades ago, to make sure that everybody has the same time in their boxes.

The real question here is: Why does my Windows 7 clock skew so much? I have set up the internet time, but it still is inaccurate.

As a Linux-guy I love doing my stuff on the command-line. To question about the clock skew I'll do:

w32tm /monitor /computers:-the-NTP-server-

... and it will respond something like NTP: -0.7900288s offset from local clock. So it's almost a second behind the accurate time source.

The initial fix is easy, force it to get the accurate time from the configured time server:

w32tm /resync

But I cannot be doing that all the time. Why cannot the computer maintain a well disciplined clock like I configured it to do? There must be something fishy about that.

A command like:

w32tm /query /status

will say that Poll Interval: 10 (1024s), but I cannot confirm that requests for every 1024 seconds (or less). It simply does not do that. There is a TechNet article with the title of Windows Time Service Tools and Settings describing a registry setting of MaxPollInterval located in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config, but that has no real relevance here. The update mechanism does not obey that setting.

However, Microsoft's knowledge base article 884776 titled How to configure the Windows Time service against a large time offset gives more insight about the update interval. It describes a registry value of SpecialPollInterval located in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient for manual peers. I'm guessing I have a manual peer, whatever that means. I don't have a domain and I did set the server manually. The original value seems to be 604800 seconds, making that 7 days or a week. Whoa! Way too much for me.

While sniffing the network traffic with the Wireshark, indeed I can confirm that putting a small value into that will make my Windows 7 to poll on that interval. I put 10 seconds there, and it seems to work. For any real life scenario 10 seconds to update time is ridiculous. For a computer on a domain, the value is 3600 seconds, making the updates for every hour. I chose to use that.

Please note that changing the registry value requires a restart for the Windows time client. From a command line a:

net stop w32time
net start w32time

will do the trick and start using the newly set registry value. You can also restart the Windows Time service from GUI.

Now my computer's time seems to stick with a reasonable accuracy. I'm still considering of purchasing a GPS-time box of my own. They seem to be quite expensive, though.

Most people don't much care about their Linux-boxes' security. You install it, you run it, you use it and occasionally run some system updates into it. Not me. When I have a box running against the wild wild Net, I absolutely positively plan to make the life of anybody cracking into one of my boxes as difficult as possible (with some usability left for myself). See Mr. Tan's article about Security-Functionality-Usability Trade-Off.

So, my choice is at the Functionality - Security -axis with less on the Ease-of-use. The rationale is that, a web application needs to run as safely as possible and can have the ease-of-use in it. The system administrator is a trained professional, he doesn't need the easy-part so much. However, there is a point, when things are set up too tight:

Image courtesy of Dilbert by Scott Adams

So, I voluntarily run software designed and implemented by NSA, SElinux. I even run it in the the Enforcing-mode which any even remotely normal system administrator thinks as being totally insane! Any small or even a tiny slip-up from the set security policy will render things completely useless. Mordac steps in and stuff simply does not work anymore.

On my Fedora-box there was a bug in BIND, the name server and an update was released to fix that. After running the update, the DNS was gone. As in, it didn't function, it didn't respond to any requests and the service didn't start. All it said was:

# systemctl status named-chroot.service --full
named-chroot.service - Berkeley Internet Name Domain (DNS)
   Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled)
   Active: failed (Result: timeout)

Any attempt to start the service resulted in a 60 second wait and a failure. dmesg-log had nothing about the issue, nor BIND's own log had nothing about the issue in it. So I started suspecting a SElinux-permission issue. My standard SElinux debugging always starts with a:

cat /var/log/audit/audit.log | audit2allow -m local

... to see if SElinux's audit logger is logging any permission-related audit faults. Indeed it did:

require {
        type named_conf_t;
        type named_t;
        class dir write;
}

#============= named_t ==============
allow named_t named_conf_t:dir write;

That reads:
A process running in named_t security context is trying to access a directory with named_conf_t security context to gain a write access, but is denied while doing so.
It is obvious that the process in question must be the BIND name server. No other process has the named_t security context in it. When starting up, BIND name server was about to write into its own configuration directory, which is a big no no! When you write, you write only to designated directories, nowhere else (remember: running in enforcing-mode is insanity).

That is definitely a reason for a daemon not to start or to timeout while starting. Further investigation showed that also Fedora's SElinux policy had been updated a week ago: selinux-policy-3.12.1-74.19.fc19.

At this point I had all the pieces for the puzzle, it was simply a matter of putting it all together. The recently released SElinux policy has a bug in it, and nobody else was there to fix it for me.

The exact audit-log line is:

type=AVC msg=audit(1395481575.712:15239): avc:
denied  { write } for
pid=4046 comm="named" name="named" dev="tmpfs" ino=14899
scontext=system_u:system_r:named_t:s0
tcontext=system_u:object_r:named_conf_t:s0 tclass=dir

So, my chrooted BIND-damon was trying to write into a tmpfs. There aren't that many of those in a system. I've even touched the tmpfs-subject earlier when I wrote a systemd-configuration into my own daemon. To find the tmpfs-usage, I ran:

# mount | fgrep tmpfs
tmpfs on /var/named/chroot/run/named type tmpfs

BIND's chroot-environment has one. That is very likely the culprit. That can be confirmed:

# ls -Z /var/named/chroot/run/
drwxrwx---. named named system_u:object_r:named_conf_t:s0 named

Yep! That's it. The directory has incorrect security context in it. To compare into system's non-chrooted one:

# ls -Zd /run/
drwxr-xr-x. root root system_u:object_r:var_run_t:s0   /run/

There is a difference between named_conf_t and var_run_t. You can write temporary files into latter, but not to the first one. The fix is very simple (assuming, that you speak fluent SElinux):

semanage fcontext -a -t var_run_t "/var/named/chroot/run(/.*)?"
restorecon -R -v named/

The two commands are:
First, re-declare a better security-context for the directory in question and then start using the new definition. Now my BIND started and was fully operational! Nice.

My investigation ran further. I needed to report this to Fedora-people. I looked into the policy-file of /etc/selinux/targeted/contexts/files/file_contexts and found the faulty line in it:

/var/named/chroot/var/run/named.*       system_u:object_r:named_var_run_t:s0

That line almost works. The directory in question has only two files in it. One of them even has a matching name. The problem, obviously, is that the another one does not:

# ls -l /var/named/chroot/run/named/
total 8
-rw-r--r--. 1 named named   5 Mar 22 12:02 named.pid
-rw-------. 1 named named 102 Mar 22 12:02 session.key

See Bug 1079636 at Red Hat Bugzilla for further developments with this issue.

One day my laptop shut itself down while I was getting a cup of coffee. No big deal, I thought. I'll just plug it into charger and things will be ok again. It took me by surprise to see, that the battery was 80% charged and the laptop had done a "crash landing". Apparently it chose to turn itself off. I'm guessing to avoid an over-heating situation.

Couple of weeks later I realized that a machine that does not do anything, chews about 25% CPU constantly. The natural guess would be a virus scanner, but it turned out to be a process called IEWebSiteLogon.exe:

I've never heard of such an application. Google didn't reveal anything useful, but the process properties revealed that the file was located at C:\Program Files\Lenovo Fingerprint Reader\x86\, so the conclusion is that my fingerprint reader's software is running a piece of software to eat up a lot of CPU-resources to do exactly nothing.

The file name gave me a hint, that it has something to do with Internet Explorer. I was running IE 11:

I opened the add ons manager:

and there it was. My initial idea of disabling the stupid thing didn't pan out. The Disable-button is grayed out. Searching The Net revealed two interesting pieces of information: How to Remove Unneeded Plug-Ins in Internet Explorer By Andy Rathbone from Windows 8 For Dummies, which proved to be useless, it instructs to disable the add on. The second yielded results: Can't remove Internet Explorer Add-On. It described a way to track down the component by its class ID. Nice, but not nice enough. Somewhere there is a piece of code to attempt to load the missing component. Why not remove the requirement?

The details of the add on are:

Now I had the class ID of {8590886E-EC8C-43C1-A32C-E4C2B0B6395B}. According to SystemLookup.com is a valid piece of software, they say: "This entry is classified as legitimate". That class ID can be found in my Windows system's registry from the following locations:

• HKEY_CLASSES_ROOT\CLSID\
• HKEY_CLASSES_ROOT\Wow6432Node\CLSID\
• HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\
• HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Approved Extensions
• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\

The interesting ones are the system setting of Browser Helper Objects and user setting of Approved Extensions. Removing the helper object surely will disable the add on completely. Also it will be a good idea to make it a not-approved extension. And to un-register the component. All that should give the stupid add on a decisive blow and make it not waste my precious CPU-cycles.

The following PowerShell-commands run with administrator permissions will do the trick:

Remove-Item -path
  "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\{8590886E-EC8C-43C1-A32C-E4C2B0B6395B}"
Remove-Item -path
  "HKCU:\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{8590886E-EC8C-43C1-A32C-E4C2B0B6395B}"
Remove-ItemProperty -path
  "HKCU:\Software\Microsoft\Internet Explorer\Approved Extensions" -name "{8590886E-EC8C-43C1-A32C-E4C2B0B6395B}"

If you don't have admin-permissions, the commands will fail. Also please note that every time Internet Explorer is started, it will make sure that permissions in the registry HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Approved Extensions are set so, that user is denied any modification access. See this:

I tried to remove the deny ACL with PowerShell, but it seems to be impossible. The API is not mature enough.

After removing the deny ACL and running the PowerShell-commands and finally stopping and starting the Internet Explorer, the add on was gone. I managed to "disable" it completely.

OpenSuse 13.1 was released November 2013. During Christmas holidays I started a project of upgrading my previous installation.

Since I'm running on a MacBook 1,1 it was obvious that I was looking for trouble. Previously I had rEFIt running just to get a GRUB 2 -prompt. This time I decided to start from a clean slate. Literally. I ran
dd if=/dev/zero of=/dev/sda
for the 10 first MiB of the drive to make sure, that it definitely has no trace of any of my previous settings. Since rEFIt has been abandoned years ago, I went for the replacement project rEFInd. I approached the author Mr. Roderick W. Smith and he was very helpful, but no matter what I did, I could not get rEFInd running on my very old 32-bit Mac. So, I had two options left: to go back to abandonware or see what would happen without a Boot Manager.

I failed on the installer settings-dialog, by trying to out-smart OpenSuse logic. My completed installation didn't boot. On 2nd try I simply went with the flow. As Mr. Smith instructed me, I didn't touch the most critical thing: MBR is not the way to go on a Mac! Here are my settings:

And guess what, it worked! OpenSuse 13.1 installer has enough logic to create a bootable Linux-installation to a completely blank hard drive. Nice!

The installer was pretty smart. Wi-Fi network was configured properly, it worked out-of-the-box. Apple-keys work: screen brightness, volume, etc. work as is. Also the typical trouble-makers sleep (on RAM) / hibernate (to disk), battery info, sound, and what not. There were only two minor issues: iSight does not work without the Apple proprietary firmware and the keyboard Apple-keys don't do anything usable.

To get the iSight camera working, see ift-extract -tool at Apple Built-in iSight Firmware Tools for Linux. It can dig the guts out of Mac OS X iSight-driver and equip your Linux with a functioning camera. The keyboard is a trivial one. Like previously, I just keyfuzz'ed the keys into something useful. See the OpenSuse 12.3 installation blog entry for details.

There is one thing you may want to check. If you enable SSHd, like I always do on all servers. As default /etc/sysconfig/SuSEfirewall2.d/services/sshd defines as TCP/22 to be open. That is the general idea, but apparently there is so much SSHd bombing going on, that I always tar pit my installations. For some strange reason Suse engineers chose not to allow that in a specific service definition file, but it has to be in the classic /etc/sysconfig/SuSEfirewall2 file, section FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
I urge everyone of you to rename the services/sshd into something else and add the above line. This makes bombing your SSH-port so much more difficult. And it does not affect your own login performance, unless you choose to bomb it yourself.

You may want to check OpenSuse's hardware compatibility list for details about Apple Laptops. The HCL has info about what works and what doesn't.

In general OpenSuse folks did a very good job with this one. There was a real improvement on ease installation. Thanks Roderick W. Smith for his help during my installation and thanks to Novell for giving this great distro for free!

The ancient tar is de-facto packing utility in all *nixes. Originally it was used for tape backups, but since tape backups are pretty much in the past, it is used solely for file transfers. Pretty much everything distributed for a *nix in the net is a single compressed tar-archive. However, there is a hidden side-effect in it. Put a colon-character (:) in the filename and tar starts mis-behaving.

Example:

tar tf 2014-02-04_12\:09-59.tar
tar: Cannot connect to 2014-02-04_12: resolve failed

What resolve! The filename is there! Why there is a need to resolve anything?

Browsing the tar manual at chapter 6.1 Choosing and Naming Archive Files reveals following info: "If the archive file name includes a colon (‘:’), then it is assumed to be a file on another machine" and also "If you need to use a file whose name includes a colon, then the remote tape drive behavior can be inhibited by using the ‘--force-local’ option".

Right. Good to know. The man-page reads:

Device selection and switching:
--force-local
              archive file is local even if it has a colon

Let's try again:

tar --force-local tf 2014-02-04_12\:09-59.tar
tar: You must specify one of the `-Acdtrux' or `--test-label'  options

Hm.. something wrong there. Another version of that would be:

tar -t --force-local f 2014-02-04_12\:09-59.tar

Well, that hung until I hit Ctrl-d. Next try:

tar tf 2014-02-04_12\:09-59.tar --force-local

Whooo! Finally some results.

I know that nobody is going to change tar-command to behave reasonably. But who really would use it over another machine (without a SSH-pipe)? That legacy feature makes things overly complex and confusing. You'll get my +1 for dropping the feature or changing the default.

This puzzled me for a while. It is almost impossible to install the root certificate from own CA into openSUSE Linux and make it stick. Initially I tried the classic /etc/ssl/certs/-directory which works for every OpenSSL-installation. But in this case it looks like some sort of script cleans out all weird certificates from it, so effectively my own changes won't last beyond couple of weeks.

This issue is really poorly documented. Also searching the Net yields no usable results. I found something usable in Nabble from a discussion thread titled "unify ca-certificates installations". There they pretty much confirm the fact that there is a script doing the updating. Luckily they give a hint about the script.

To solve this, the root certificate needs to be in /etc/pki/trust/anchors/. When the certificate files (in PEM-format) are placed there, do the update with update-ca-certificates -command. Example run:

# /usr/sbin/update-ca-certificates
2 added, 0 removed.

The script, however, does not process revocation lists properly. I didn't find anything concrete about them, except manually creating symlinks to /var/lib/ca-certificates/openssl/ -directory.

Example of verification failing:

# openssl verify -crl_check_all test.certificate.cer
test.certificate.cer: CN = test.site.com
error 3 at 0 depth lookup:unable to get certificate CRL

To get this working, we'll need a hash of the revocation list. The hash value is actually same than the certificate hash value, but this is how you'll get it:

openssl crl -noout -hash -in /etc/pki/trust/anchors/revoke.crl

Then create the symlink:

ln -s /etc/pki/trust/anchors/revoke.crl \
  /var/lib/ca-certificates/openssl/-the-hash-.r0

Now test the verify again:

# openssl verify -crl_check_all test.certificate.cer
test.certificate.cer: OK

Yesh! It works!
Funny how openSUSE chose a completely different way of handling this... and then chose not to document it enough.

Microsoft announced version 3.5 of Linux Integration Services for Hyper-V. An ISO-image is available for download at Mirosoft's site.

In one of my earlier articles I was wondering if it really matters when Hyper-V indicates the Linux guest status as degraded and tells that an upgrade is required. This version does not change that. Looks like they just added some (weird) new features and improved set of virtulization features for Windows Server 2012 R2, but didn't touch the network code. However, there is a promise of TRIM-support for 2012 R2.

So, the bottom line is: not worth upgrading.

Speedtest.net has pretty much gained The-place-to-test-your-connection-speed -status. It's like Google for doing web searches. There simply is no real competition available.

Mr. Matt Martz (while throwing hot coals) did study their JavaScript-code enough to write their client-API with Python.

The installation into proper directory (recommended: /usr/local/bin/) with proper permissions is this simple:

wget -O speedtest-cli \
 https://raw.github.com/sivel/speedtest-cli/master/speedtest_cli.py
chmod +x speedtest-cli

The built-in automatic detection of nearest server does not work for me very well. Their recommended nearest server is not in the country I live (Finland), but on Russian side. The network connections over their border aren't that good and it simply does not yield reliable measurements. Not to worry, the CLI-version can do following:

speedtest_cli --list | fgrep Finland
864) Nebula Oy (Helsinki, Finland) [204.35 km]

Now that we know the server ID of a proper point, we can do:

speedtest_cli --server 864

It will yield:

Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Finland Oyj (80.80.80.80)...
Hosted by Nebula Oy (Helsinki) [204.35 km]: 14.782 ms
Testing download speed........................................
Download: 92.69 Mbit/s
Testing upload speed..................................................
Upload: 4.32 Mbit/s

Nice!

Again, thanks Matt for sharing your work with all of us.

PLD RescueCD is my new favorite Linux rescue CD. It has a ton of stuff in it, even the ipmitool from OpenIPMI-project. One of these days, it so happened that I lost my IPMI network access due to own mis-configuration. I just goofed up the conf and oops, there was no way of reaching management interface anymore. If the operating system on the box would have been ok, it might have been possible to do some fixing via that, but I chose not to. Instead I got a copy of PLD and started working.

The issue is, that PLD RescueCD comes as ISO-image only. Well, erhm... nobody really boots CDs or DVDs anymore. To get the thing booting from an USB-stick appeared to be a rather simple task.

Prerequisites

• A working Linux with enough root-access to do some work with USB-stick and ISO-image
• syslinux-utility installed, all distros have this, but not all of them install it automatically. Confirm that you have this or you won't get any results.
  
• GNU Parted -utility installed, all distros have this. If yours doesn't you'll have to adapt with the partitioning weapon of your choice.
  
• An USB-stick with capacity of 256 MiB or more, the rescue CD isn't very big for a Linux distro
• WARNING! During this process you will lose everything on that stick. Forever.
• Not all old USB-sticks can be used to boot all systems. Any reasonable modern ones do. If you are failing, please try again with a new stick.
  
• PLD RescueCD downloaded ISO-file, I had RCDx86_13_03_10.iso
• You'll need to know the exact location (as in directory) for the file
• The system you're about to rescue has a means of booting via USB. Any reasonable modern system does. With old ones that's debatable.
  

Assumptions used here:

• Linux sees the USB-stick as /dev/sde 
• ISO-image is at /tmp/
• Mount location for the USB-stick is /mnt/usb/
• Mount location for the ISO-image is /mnt/iso/
• syslinux-package installs it's extra files into /usr/share/syslinux/
• You will be using the 32-bit version of PLD Rescue

On your system those will most likely be different or you can adjust those according to your own preferences.

Information about how to use syslinux can be found from SYSLINUX HowTos.

Steps to do it

1. Insert the USB-stick into your Linux-machine
   
2. Partition the USB-stick
• NOTE: Feel free to skip this if you already have a FAT32-partition on the stick
• Steps:
1. Start GNU Parted:
   parted /dev/sde
2. Create a MS-DOS partition table to the USB-stick:
   mktable msdos
   
3. Create a new 256 MiB FAT32 partition to the USB-stick:
   mkpart pri fat32 1 256M
   
4. Set the newly created partition as bootable:
   set 1 boot on
5. End partitioning:
   quit
   
3. Format the newly created partition:
   mkfs.vfat -F 32 /dev/sde1
   
4. Copy a syslinux-compatible MBR into the stick:
   dd if=/usr/share/syslinux/mbr.bin of=/dev/sde conv=notrunc bs=440 count=1
   
5. Install syslinux:
   syslinux /dev/sde1
   
6. Mount the USB-stick to be written into:
   mount /dev/sde1 /mnt/usb/
   
7. Mount the ISO-image to be read:
   mount /tmp/RCDx86_13_03_10.iso /mnt/iso/ -o loop,ro
   
8. Copy the ISO-image contents to the USB-stick:
   cp -r /mnt/iso/* /mnt/usb/
   
9. Convert the CD-boot menu to work as USB-boot menu:
   mv /mnt/usb/boot/isolinux /mnt/usb/syslinux
10. Take the 32-bit versions into use:
    cp /mnt/usb/syslinux/isolinux.cfg.x86 /mnt/usb/syslinux/syslinux.cfg
    
11. Umount the USB-stick:
    umount /mnt/usb
    
12. Umount the ISO-image:
    umount /mnt/iso
    
13. Un-plug the USB-stick and test!

Result

Here is what a working boot menu will look like:

Like always, any comments or improvements are welcome. Thanks Arkadiusz for your efforts and for the great product you're willing to share with rest of us. Sharing is caring, after all!

This is my 2nd attempt of trying to clarify how to get Dolby Digital 5.1 output via HDMI. The previous attempt can be found here. All the information I can find on this subject shows that for some people multi-channel audio works fine, nothing special is required, but then again for some of us this is a pain and its almost impossible to get this working.

Here is my setup:

The problem, like presented earlier is depicted here:

The Audio MIDI setup clearly displays as Sony TV being the HDMI output device. The problem is, that it actually isn't. Here is another screen capture of Audio MIDI setup from my brother's computer:

Whoa! His Mac Mini displays his A/V amp as the HDMI destination. Totally different from what my Mac displays. The only explanation for this is, that my Yamaha takes the TV's spec from the HDMI and proxies it to the Mac and his Onkyo doesn't take anything, it simply presents itself as the destination. If you'd ask me, Onkyo's solution is much better than Yamaha's. Anyway, the amp has to pick up the audio signal to be sent to loudspeakers and do a stereo mixdown of a multi-channel signal to be sent for the TV. So there will be a lot of processing at the amp, why not declare itself as the destination for the Mac. It seems to be confusing.

The Solution

Here is what I did to get proper 5.1 channel sound working from my Mac Mini. The problem is, that I cannot get it back to the broken mode again, it simply stays fully functional no matter what I do. There must be something going on at the amp end and something else going on at the Mac end. For some reason they don't match or they do match and there is very little I can do to control it. But anyway, here are my steps with Audio MIDI Setup utility:

1. In the Mac, set HDMI to Use this device for sound output and Play alerts and sound effects trough this device
2. Confirm that the speaker setup is correct and click the speakers to confirm that test tone does not output as expected
3. In the amp, make sure that the input HDMI is decoding multi-channel audio as expected
• Auto-detect or stereo won't work
• Previously my instructions stopped here
4. In the Mac, at the HDMI, in Format set it as Encoded Digital Audio, the Hz setting is irrelevant
   
5. This will effectively unset HDMI as output device and set Built-in Output as the output device. It also pretty much makes all sounds in the system non-functional.
6. Again at the HDMI, in Format select 8ch-24bit Integer, it will reset the HDMI to Use this device for sound output and Play alerts and sound effects trough this device
7. Re-confirm that speaker setup is correct. At this point the test tone should work from the speaker correctly.
8. You're done!

This fix and pretty much everything about Mac Mini's HDMI audio output is bit fuzzy. Any real solution should be reproducible somehow. This isn't. But I can assure you, that now my multi-channel audio really works as expected.

Any feedback about this solution is welcome!

Update 1st Jan 2014:
The number of channels configured into Audio Setup does not reflect the actual number of speakers you have. That is done in Configure Speakers. I have 8ch (or 8 speakers) configured in the Audio Setup, but this is a screenshot of my speaker setup:

They have different number of speakers! It still works. That's how it is supposed to be.

That should be an easy task, right? You guessed it. If I'm writing about it, it isn't. Once in a while I still test with a real IE8. The IE10 and IE11 emulators should be good enough, but they aren't. Here are the stats from this blog:

People seem to run with IE8 a lot. They shouldn't but ... they do.

Here is what I did:

1. List of Windows updates installed on the computer:
   
2. Managed to find Internet Explorer 9 in it (on Windows 7, that's pretty normal):
   
3. Un-install starts:
   
4. Yep. It took a while and hung. Darn!
   
5. I waited for 20 minutes and rebooted the hung piece of ...
6. Reboot did some mopping up and here is the result. No IE anywhere:
   
7. Guess who cannot re-install it. On a normal installation it is listed in Windows features, like this:
   
   In my case, no:
   
   

No amount of reboots, running sfc.exe or anything I can think of will fix this. This is what I already tried:

1. Attempt fix with Windows Resource Checker:
   PS C:\Windows\system32> sfc /scannow
   
   Beginning system scan.  This process will take some time.
   
   Beginning verification phase of system scan.
   Verification 100% complete.
   
   Windows Resource Protection did not find any integrity violations.
   It simply fails to restore the files, because all the bookkeeping says, that IE8 shouldn't be there!
   
2. Let' just download the installation package and re-install manually. Download Center - Internet Explorer 8
   
3. Ok, we're not going to do that, because the IE 8 installation package for Windows 7 does not exist. Reason is very simple. Win 7 came with IE8. It is an integral part of the OS. You simply cannot run the Windows 7 without some version of IE. No installation packages necessary, right? Internet Explorer 8 for Windows 7 is not available for download
   
4. Right then. I took the Windows Vista package and ran the installation anyway. All the compatiblity modes and such yield the same result. Internet Explorer 8 is not supported on this operating system
   
   
5. Re-installation instructions, part 1: Reinstalling IE8 on Windows 7. Not much of a help. The
   
6. Re-installation instructions, part 2: How to Reinstall Internet Explorer in Windows 7 and Vista. No help there either.
7. Registry tweaking into HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions to see if {7B849a69-220F-451E-B3FE-2CB811AF94AE} and {CF7639F3-ABA2-41DB-97F2-81E2C5DBFC5D} are still there as suggested by How to Uninstall IE8. Nope. No help with that either. That article mentions "European Windows 7". What could the difference be?
8. Perhaps re-installing Service Pack 1 would help? But well... in Windows 7 SP1 cannot be re-installed like it was possible in Windows XP. That actually did fix a lot of operating systems gone bad at the XP-era.
   

The general consensus seems to be, that you simply cannot lose IE from Windows 7. Magically I did. Just based on the Wikipedia article about removing IE, it is possible.

Some of the symptoms I'm currently having is Windows Explorer Refuses to Open Folders In Same Window. Some of the necessary DLLs are not there and Windows Explorer behaves funnily.

I don't know what to attempt next.

Why doesn't my setting of NOT installing important updates automatically stick? Every once in a while it seems to pop itself back to the stupid position and does all kinds of nasty things in the middle of the night. From now on I'll start a counter how many times I'll go there to reset the setting back to the one I as system administrator chose.

All this rant is for the simple reason: I've lost data and precious working time trying to recover it. This morning I woke up and while roaming in the house in a semi-conscious state attempting to regain a thought, I noticed couple of LEDs glimmering in a place there shouldn't be any. My desktop PC was on and it shouldn't be. On closer inspection at 3 am it chose to un-sleep for the sake of installing Windows updates. This is yet another stupid thing for a computer to be doing (see my post about OS X waking up).

The bottom line is that the good people (fucking idiots) at Microsoft don't respect my decisions. They choose to force feed me theirs based on the assumption that I accidentally chose not to do a trivial system administration taks automatically. I didn't. I don't want to lose my settings, windows, documents, the list goes on.

The only real option for me would be to set up a Windows Domain. In Active Directory there would be possibility of fixing the setting and making it un-changeable. I just don't want to do it for a couple of computers. Idiots!