Helgelandsfjellet ligg i Førre, og turen opp startar i Førresdalen. Parkering på kveldstid og i helger ved Førresdalen barnehage. På dagtid i vekedagar kan ein stå langs vegen inn til barnehagen. Følg vegen videre nedover Førresdalen forbi caravansenteret til ein kjem til balløkke/lekeplass. Følg akebakken opp til toppen, ta til høgre på toppen av akebakken og følg stien til topps. På toppen (219 moh) er det flott utsikt! Turen opp tar ca 30 min. (Hentet fra brosjyren til Tysvær Kommune)

Da er det endelig duket for en ny post i kategorien “På tur”

Jeg har vært på Helgelandsfjellet før, men det må være over 15 år siden, sannsynligvis lenge før dagens tursti var påtenkt. Mens dagens tursti går i lett terreng fra vest, husker jeg at jeg tok turen fra sør-øst hvor det er både skog og steinrøyser.

Turen er ikke særlig lang, ei heller særlig krevende, til gjengjeld gir den deg god utsikt over både Aksdal, Førre og Frakkagjerd. Sånn sett er den en fin familietur, og det er noe særegen med å se bebyggelse ovenfra. Man får et helt annet syn på både avstandsforhold og hvordan byggninger og byggefelt ligger i forhold til hverandre.

Fra bunn av akebakken hvor man går opp og til toppen er det circa 500 meter i luftlinje, så jeg vil anslå at turen opp (om man følger stien) er et sted mellom 700-800 meter. I tillegg kommer jo alt fra hvor man parkerer utenom, hvis man da ikke velger å gå hjemmefra for de som har muligheten til det.

På toppen står den kjente “Frisk i friluft”-postkassen med kodeordet. Til forskjell fra alle andre turer jeg har gått, så står det ikke noe trivia på arket i postkassen, kun stedsnavn og kodeord. Så da får jeg hoste opp noe trivia selv.

Helgelandsfjellet ligg 219 moh, og gir utsikt både mot Aksdal, Førre og noen andre plasser. For 100 år siden var bebyggelsen her noe ganske annet enn den er i dag.

Sånn, da var det gjort. Da er det vel bare å ønske dere en god tur.

Yesterday I logged into a Windows server and found that some programs were missing (python among others). No big deal. I just assumed that someone else had removed them to free up space or something. Then I found a few files I knew I had both edited and deleted. And the files I knew I had touched suddenly had a timestamp dating back to 2008. Luckily this isn’t a critical production machine, but never the less, how could this happen?

When I checked the vCenter log, I found that the virtual hardware on this particular VM was updated just short of 24 hours earlier. The VM also contained a system generated snapshot dated 2008. The Windows event log, however, where having a gap from 2010 till 2012 (current day).

What has happened is this:

• The VM was powered off.
• The virtual hardware was upgraded.
• When the machine was turned back on, the system reverted back to a previous snapshot (without logging it), thus overwriting the current image.

There are several things here that I find “scary”. The first is that the VM went back using an older system state without even logging it.

The second “scary” thing is that the system generated snapshot was wrongly labeled with the year 2008, when it clearly contained data from 2010 (We actually tested this by reverting to this image just to check. We had nothing to loose anyway).

(Sorry in advance to everyone anyone searching for actual information about ITIL.)

For the record; I’m using Windows 7 (64-bit) with Service Pack 1.

To make a long story short. I search the internet, and found various answers. My first break through was when I disabled the network card, the wired one. The second came from a friend of mine.

So what I ended up doing, in this order, was downgrade the network driver, since the newest driver wasn’t working properly (duh). Searching for Intel 82579LM eventually led me to HPs website. I’ve tried two or three versions from Lenovo’s site, and two other directly from Intel, with only minor improvements. Turns out that the old driver from HP (SP52209.exe), dated 2010, is the best driver I’ve tested so far. Also, I disabled the ATA Channel 3, and eventually Channel 4 as well. I did try the newest network driver with the two ATA Channels disabled, but the problem reappeared.

So there you have it, my solution to the problem, disable a couple of ATA Channels and downgrade the network driver to an old version fresh from HP.com.

Error 1611: This error may indicate a hardware issue with your device.

This upgrade being done on a Windows machine, I did the most obvious thing second; restarted the computer. The first thing I tried was to close and reopen iTunes.

I search online and found a few posts regarding this issue, both on Mac and Windows. And most of them mentioned uninstalling iTunes and removing a few key files, then reinstall the lastest version of iTunes.

However; I did notice Windows complaining about an unknown device being plugged in. Knowing how Windows handle device drivers, I decided to try one more thing before reinstalling iTunes.

So, here’s my tip. Try unpluging your iDevice, and reconnect it to another USB port. This will force Windows to detect this as a new device, and reinstall the necessary drivers. Worked for me.

You have not chosen to trust [certificate] the issuer of the server’s security certificate (SSL error 61)

Both the problem and the solution is the same as before, only the name and the path is different. The path depends on whether you installed the client/receiver as a normal user, or root, also known as the superuser.

I’ve used Ubuntu 11.04 here, but I reckon it’ll work on any Linux distribution.

The problem is this; When you install the Citrix Receiver, it will only install a handful of certificate files, and we’ll have to provide the rest. Now, where can we find a reliable source of SSL certificates? Well, it turns out that we most likely have that already. The same source our browser is using.

 /usr/share/ca-certificates/mozilla/

Just copy those .crt files over to the Citrix keystore, and we should be done. If the client is installed under /opt/Citrix/ICAClient/, run this command in a terminal:

sudo cp /usr/share/ca-certificates/mozilla/* \
/opt/Citrix/ICAClient/keystore/cacerts/

If it’s installed in your home directory, this command should work:

cp /usr/share/ca-certificates/mozilla/* \
$HOME/ICAClient/linuxx86/keystore/cacerts/

If you are using a home made certificate, or for some reason this doesn’t work for you, you’ll have to track down the correct .crt files yourself. But at least now you’ll know where to place them.

• Removing the server from the old domain
• Changing the IP-address on the server
• Adding the server to the new domain controller
• Making sure the ESX hosts found its “new” owner

Careful planning is the key to success in such operations. Up front, all the ESX hosts had been upgraded and configured in such a way that they already utilised the new infrastructure.

However, a few quirks did arrive, and these are the ones that I will outline here. My guess is that 80% of the people arriving here from a search engine got these problems.

Feel free to jump to that section right away.

For the record; I’m using vCenter Server version 4.1.0, build 258902 on Windows Server 2008 R2 Standard (64-bit).

Sections

• Step by step guide
• vCenter still contains references to the old server or domain name
• Sources

Step by Step

There is only a few things you need to make sure before you begin, otherwise you might get a nasty surprise when all your virtual machines reboot.

Also, if you are going to change the IP-address on the vCenter Server, make sure that all your ESX hosts can communicate with the new address range.

The ESX hosts should be able to survive without a panic when the vCenter Server goes down for maintenance. But this can depend on how you have configured your vCenter Server.

1. Remove the vCenter Server from old domain

Log into the vCenter Server with Remote Desktop (or via a console) and remove it form the old domain. Reboot.

2. Change IP-address on the vCenter Server (optional)

Next step depends if you actually need to change the IP-address. If you don’t, you don’t. If you do, have in mind that you will lose connection once you click “ok” or “apply”. Don’t forget to change the gateway and DNS-server addresses as well.

In my case I had to change the VLAN bindings on the switch port. We keep out two domains on separate VLANs.

3. Add vCenter Server to new domain

Add the vCenter Server to the new domain. No surprise here either. Complete the process with a reboot.

4. Update configuration files on ESX hosts (may depend on step 2)

The ESX hosts will most likely acknowledge the vCenter Server before you get to this step because of fingerprints and other magic. But nonetheless, log into the ESX server with ssh and edit the vpxa.cfg file. All the commands here has to be executed as the root user.

(Before you start; log into each ESX host with the vSphere Client and add a user with rights to log in remote via ssh.)

#nano /etc/opt/vmware/vpxa/vpxa.cfg

(Actually this only applies to those who changed the IP-address in step 2)

Change the IP-address listed between the <serverIP> tags in the file, like so:

<serverIp>192.168.20.20</serverIp>

Given that the new vCenter Server address is 192.168.20.20. Save using Ctrl+X.

Also, check the hosts file for any references to the old address or domain name.

#nano /etc/hosts

In my case I changed it from

192.168.10.10  vcenter   vcenter.domain.com

to the following

192.168.20.20  vcenter   vcenter.domain.lan

and save using Ctrl+X. (Yeah, we change from a .com domain to a .lan domain)

If you have changed the vpxa.cfg file you will also have to restart two management agents on the ESX hosts.

Make sure you haven’t configured auto start/stop on the Virtual Machines at this point. If you have, disable it. Restarting services may lead to an unexpected reboot of all the virtual machines running on the ESX host.

#service mgmt-vmware restart

#service vmware-vpxa restart

5. Restart VMware Virtual Center Service

Log into the vCenter Server and start the services console. Just type “services.msc” in the run dialog.

Find and select the VMware VirtualCenter Server service and restart it. It may also drag another service with itself in the process. No problem.

6. Log in using vSphere Client

Start the vSphere Client and log in using the new domain name and your administrator credentials.

Hopefully everything is up and running and all the ESX hosts are connected. I would advice you to take a look at the KB-articles in the last section before you actually attempt to follow this guid. They will give you a better understanding about how this works.

Now; vCenter Server still contains some references to the old server and/or domain name. So keep reading.

vCenter Still Contains References to the old Server or Domain Name

This can, and mostly will, happen to you too. And the way I found out was when I tried to log into the vCenter Server using vSphere Client and VMware Update Manager (a plugin) complained about being unable to reach the server, referring to the old domain name.

There was an error connection to VMware vCenter Update Manager. The request failed because the server name could not be resolved.

Turns out that the old name is soft coded into different configuration files and registries.

I had to make changes to the following files and places:

• VMware vSphere Client
• Windows Registry
• vci-integrity (only if Update Manager is installed)
• ADSI Edit

1. vSphere Client changes

In the menu, choose Administration and vCenter Server Settings.

If you are using a license server, and the service is installed on the same machine as the vCenter Server, you have to check the settings under Licensing.

vCenter Server Name also has to be changed under Runtime Settings.

And under Advanced Settings you may have to change the following keys:

• VirtualCenter.InstanceName
• VirtualCenter.VimAPiUrl
• VirtualCenter.VimWebServicesUrl

2. Windows Registry

Using regedit from the run menu, navigate to the following places:

HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VirtualCenter

Check the string named VCInstanceId.

Also check the following place:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VMware, Inc.\VMware Update Manager

and update the data on the string VUMServer.

3. Update vci-integrity.xml

This file is found at C:\Program Files (x86)\VMware\Infrastructure\Update Manager\vci-integrity.xml (only if Update Manager is installed on the server).

Search for the tag <vpxdLocation> and make sure the address is correct. It’s either an IP-address or a FQDN. Save the file and exit.

4. ADSI Edit

This little gem is located under Administrative Tools. Start it up and right click on the object ADSI Edit. Choose Connect and use the following settings…

• Name: VC (not important actually)
• Connection Point: dc=virtualcenter,dc=vmware,dc=int
• Computer: localhost:389

Some of the objects here will have unique names, so they will be named differently on your system. So in the simplest form, go through each and every object under OU=ComponentSpecs and OU=Instances and right click and select Properties.

Scroll through the list and edit every attribute that contains a reference to the old server name.

When all this is done, restart the VMware services or just reboot the vCenter Server. I would recommend a full reboot to make sure the all the changes are active.

Sources

• http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1001493
• http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1003490
• http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1000163
• http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1003312
• http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1003895
• http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1003895
• http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1003490
• http://communities.vmware.com/thread/226681

Here is a clip from the series.

Check out his personal website here:
http://humanplanet.com/timothyallen/

…and his BBC page here:
http://timothyallen.blogs.bbcearth.com/

Max Sync Speed

Normally the Canon 5D has a max sync speed of 1/200 of a second, rather than the more usual 1/250, since it has a full frame sensor. When using the RF-602s, the max sync speed is reduced to 1/160 of a second. These numbers may vary depending on your equipment.

As a general rule I would recommend to test this before you go out shooting. Especially if you’re using a new camera, a new set of receivers or flashes.

Connecting the Receiver to the Flash Using a Cable

While the RF-602s works more or less flawlessly when the flash is connected using the hot-shoe on the receiver, using a cable (as shown in the image), may result in some strange behavior. In my case, for example, the receiver will no longer be able to wake up the flash from sleep. I’ve tested this on both my Canon Speedlite 580EX II with the same result.

This can be solved by disabling the sleep function on the flash unit.

Another thing I have observed on a few occasions is that the receivers stop working. I can be resolved by either turning of the flash unit and then turn it back on, or in some cases turn of the receiver and then turn it back on. Again, this seems to be a problem when using a cable instead of the hot-shoe mount.

Securing the Receiver on a Flash Stand

Based on what I’ve written above, you might wonder why I don’t simply use the hot-shoe on the receiver instead of the cable.

While connecting the flash unit to the receiver is no problem, connecting the receiver to a mount is a whole different story. Actually, the problem consists of securing the receiver to the mount. And the last thing you want is your expensive flash hitting the ground because your cheap receiver couldn’t hold on to the flash stand.

However, if you use a screw (like the one used when connection your camera to a tripod) instead of a hot-shoe mount, this shouldn’t be a problem. The important part is to make sure your flash is secure. Do not compromise.