powered by sleep

There are times where I run a command that I needed to only need it again at a later time.  Most of the time I document my steps, but there are those time where I just do things in the heat of the moment to get what I need done.  So what can one do?  Well when you’re in your command shell and looking for that command you once knew, all you need to do is simply type:  history

History will return a log of all the commands you have typed.  So when in doubt, look back at your history and bring back those lost memories.  Good luck

Recently I had a need to install Windows 7 on a computer and I was out of DVD media to use. The only media I had was a 8GB USB Thumb drive. I have done this many of time in Windows itself with various of tools and eve manually. Now I do it in Linux also.

Here is a small list of items one would need:

1. Windows 7 ISO Media
2. 4GB or larger USB Pen Drive
3. And Linux Install with root access (sudo, will work fine)

Open up a terminal and location the device that your USB drive is mounted to.

In my situation I had my USB Pen drive mounted at the following location /media/usb, the device was location at the following location /dev/sdb1

I first unmounted the drive using the following command:

sudo umount /dev/sdb1

I then changed directories until I was in the path of my Windows 7 .ISO image. This is not necessary; I do this out of habit. I then use the ‘dd’ command to copy the .ISO image to the USB Device (USB Pen Drive). Example: dd if=windows7.iso of=/dev/sdb1

After a short while the image is fully copied to the USB Pen Drive and you can then boot from this device to begin the Windows 7 Install

The shred command can be used for destroy files so that their contents are very difficult or even impossible to recover. The shred command accomplishes its destruction by repeatedly overwriting files with data patters designed to do maximum damage. Even the use of high-sensitivity data recovery methods and equipment make it difficult to recover files that have been shredded.

In Linux I often find myself using the ‘rm’ command to delete files, however this does not destroy the data it just destroys the index which lists the location of the file and makes the data blocks available for reuse. In short, a delete of the file does not remove the files and there are utilities that can read the blocks and get the data back. Such a tool is ‘testdisk’ which can image all the blogs on disk and recover deleted files.

Using ‘shred’

shred’s syntax is: shred [option(s) file(s) or device(s)

When using ‘shred’ without any options it will overwrite any file or device 25 times, which is generally sufficient to remove all traces of data. A device can be a partition or even an entire HDD, USB Key, etc.

Example: I would like to use shred to delete a file(s) and cause full destruction. By typing the following ‘shred filename1′ this will shred the file with the default setting of 25 times.

The default number of overwriting can be changed by using the -n option followed by an integer representing the desired number

The most reliable way to destroy data is to ‘shred’ an entire partition. For example, the following would destroy data on a unmounted SD Card: shred /dev/mmcblk0 thats if the device is plunged into this location. The location may be different so please be sure to use the correct one for your situation.

End Notes:

Even after overwriting data, it is possible for someone to take the HDD or other storage device to a specialized data recovery laboratory and use highly sensitive (and expensive) equipment to search for the faint traces of the original data, which can be relatively easy to detect if it has been overwritten only one or a few times. Thus, the best way to remove data on a HDD irretrievably is to physically destroy the media on which it is stored, such as by opening the drive and rubbing the individual platters with sandpaper. However, as this can be tedious, shred provides a alternative that can be almost as good but which requires much less effort and cost.

For some time I have always used tools such as scp sftp to copy files between Linux based systems. Until the growing need to have this process simplified.  I recently fell in love with Linux all over again with the new release of Ubuntu.  I always had known it was possible but never had the direct need to mount ssh file systems remotely.  This is where some Google searching and SSHFS and FUSE came into play on my home systems.

So what are some things I found out?  Well for one; as long as I have SSH access to a remote system I can use SSHGS to mount and use the remote directories as if they were on my local system.  SSHGS require no special software on the remote host so this is good in a hosted situation where you have no control over what gets installed.

This is where I give you the * filler * info on SSHFS.

SSHFS is built upon the FUSE user-space file-system framework project.  FUSE allows user-space software; in my case SSH to present a file-system that is virtually interfaced to the end use.  SSHFS connect to the remote system and does all the necessary operations to provide the look and feel of a regular file-system.

So now what?

First we need to start off by installing sshfs if not already installed.  I am using Ubuntu like I had mentioned above so by typing sudo apt-get install sshfs that installs all I need and supporting requirement.

The fun part.

Create a local directory where you want the files mounted.  This process is similar to mount smb shares from another system.  In my example I will be mounting the directory /home on the remote server to a local path on my system:

“sudo mkdir /mnt/remotehome1”

“sudo sshfs jermsmit.com:/home /mnt/remotehome1

You can also change the owner of the new directory by typing chown ‘yourusername’ /mnt/remotehome1

Please note that the /mnt/remotehome1 directory must exist and be owned by you, so keep in mind when you make (for example) /mnt/remotehome1/ you should assign permissions to your user so that you may access it.

To unmounts the directory, you can use the command fusermount –u.  Example fusermount –u /mnt/remotehome1.  If you get a message about the path being in use make sure that you have change directory out of this path and try again.

That’s about it.  Very clean and simple, and next time I hope to write about setting this up in such a way its auto mounted on startup (aka persistent), but for now this gets the job done.

Again I am working on my server; a virtual machine powered by VMware.  I recalled that I did not have the tools installed; also the virtual server console gave me an additional reminder.  So I decided to install.

There are a few things to do before installing.  First we need to make sure our server (Ubuntu) has compiler tools installed.  Then we must mount the virtual cd containing the VMware drivers and software tools for Linux.  From the command line terminal (I recommend doing this from the local console) as the network tools will drop you from the SSH connection.

Steps

sudo aptitude install build-essential linux-headers-$(uname -r)
cp -a /media/cdrom/VMwareTools* /tmp/
cd /tmp/
tar -vxzf VMwareTools*.gz
cd vmware-tools-distrib/
sudo ./vmware-install.pl

You will be asked a bunch of questions; I personal just accept the defaults and (press ENTER) to each one of them.  When completed, I reboot my server and that is it.  Tools are installed.

After a recent Ubuntu Linux (server) installation inside in a virtual machine, I decided to move the virtual machine to new a new host where I can run it.  After the move I noticed that I could no longer connect to my system via the IP I had assigned.  So the story begins.

With the discovery that I no longer had network connectivity, I did an ‘ifconfig’ and noticed that my eth0 was missing.  So, I tried to force it to start by issuing the command ‘ifup eth0’ and go the following error:

eth0: ERROR while getting interface flags: No such device…
SIOCSIFADDR: No such device
eth0: ERROR while getting interface flags: No such device
eth0: ERROR while getting interface flags: No such device
Bind socket to interface: No such device
Failed to bring up eth0

I did some searching, as I have run into this issue in my past and could not remember for the life of me what I needed to do to correct this problem (the right way).  The method I used in the past was to edit /etc/network/interfaces and change iface eth0 inet (static or dhcp) to eth1  This would change my static or dynamic settings to use the new interface…  This is not what I wanted to; “lazy admin approach”.

What I did do is… wait! Here is some background info:  When a Virtual Machine starts up, it generates a new MAC address and a new UUID for the guest system. My system had already known of a MAC address and thus made a new one.

Back to what I did to correct my problem

Locating the file /etc/udev/rules.d/70-persistent-net.rules, I removed the former MAC address info and modified the new one, changing the existing eth1 to eth0, and issued a restart

Example:
# PCI device 0×8086:0x100f (e1000)
SUBSYSTEM==”net”, DRIVERS==”?*”, ATTRS{address}=”[bad mac]“, NAME=”eth0″