Ever since I got a Mac, I bought VMWare’s Fusion in order to be able to work with software that exists only in the Windows world. The really nice thing that good friend Moses pointed out yesterday, is that Fusion now supports easy installs for Ubuntu too! I had never took notice of that, since I run most of my VMs on VirtualBox.

I am an LXDE fan, so I first tried a Lubuntu install. It went fine, but it was not an Easy Install (in Fusion’s terminology). Then I went ahead and installed normal Ubuntu and afterwards (since I cannot do any real work with Unity) installed LXDE. The Easy Install went smooth and I did not need even need to consider keyboard configurations (something I had to do with Debian-LXDE and VirtualBox). I also changed the available RAM for the VM and now I have a machine that just works.

Oh the fun of using closed software in order to work easier with open source.

For sometime now, my main desktop has been Debian LXDE virtual machine. There is a problem with lxterminal though. Whenever I changed its settings they were not saved. It turns that this is a permission problem. You have to make sure of two things:

  • Directory ~/.config/lxterminal exists and is owned by you. You may find it owned by root. chown this.
  • File ~/.config/lxterminal/lxterminal.conf exists and it is owned by you. You may find that it does not exist. Create it using touch.

I was trying to install a virtual machine using the latest VirtualBox on a Windows 7 Host. The host was also running OpenDNS DNSCrypt 0.0.6 client. The guest operating system should be Debian/LXDE. Installation went fine until the installer tried to contact Debian mirrors to fetch missing packages.

It couldn’t find them. Like the common system administration mantra says:

Everything is a DNS problem.

So at the OpenDNS DNSCrypt client dashboard I (temporarily) disabled the DNS over TCP option and the installation continued smoothly. The same thing does not happen with OS X Mavericks as the host operating system. After the installation is finished, you can reenable DNS over TCP for DNSCrypt. The guest operating system’s resolver sees no issues with this.

I am posting this short note because it may bite others out there.

I bought a 8GB SD card for my Raspberry Pi and happily dd’ed the Raspbian image to it. But it did not boot. @namp and @eliaschr suggested that I re-dd-ed (redid?) the image to the disk. But I know how to run dd(1), right?

Yes and no :(

I run dd.exe from a windows machine:

C:\TEMP> dd.exe if=2013-09-25-wheezy-raspbian.img of=\\.\e:

Ding! The above does not start writing from the beginning of the disk. It starts writing from the beginning of the E:\ partition. I dd-ed the image from a Mac and all boot well.

I suppose (but have not yet checked) that had I used the \\.\path\to\physical\drive path, I would not have bumped into this.

The setup:

– A Windows 2008 R2 server running Exchange 2010

The problem:

– The Domain Administrator’s Password was changed and then forgotten.

So now we are completely locked out of the system. To make things worse, the Offline Windows Password and Registry Editor could not identify the SCSI controller.

The solution:

I bought Active@ Boot Disk and reset the Local Administrator Password (that was gone to oblivion too). Next I booted into «Directory Restore Mode» and followed Petri’s instructions.

Problem solved.

I’m sure I’ve blogged about this before, but I cannot find it right now. Anyway the following tweet:

Beaker RT @etherealmind: Existential Angst 4 Network Engineers: If a Network Device isn’t Monitored, does it really exist? < Does when it goes down

brought to my attention by @DrInfoSec triggered my memory to recall the story of Server 54. A story that I reproduce here thanks to the Internet Archive:

The University of North Carolina has finally found a network server that, although missing for four years, hasn’t missed a packet in all that time. Try as they might, university administrators couldn’t find the server. Working with Novell Inc. (stock: NOVL), IT workers tracked it down by meticulously following cable until they literally ran into a wall. The server had been mistakenly sealed behind drywall by maintenance workers.

Digging a little bit more, one can find a few more discussions on Server 54.

… θα βρεις έναν Έλληνα. Ο Δημήτρης Στάικος, φίλος από τα παλιά, ένα έτος μεγαλύτερος και hacker extraordinaire, αντιπρόεδρος του 1394 Trade Association (Firewire για όποιον δεν τα πάει καλά με τα νούμερα).


Ενημερωθείτε για κάθε νέα δημοσίευση στο email σας.

Μαζί με 1.928 ακόμα followers