Sky calendar 2006

Tammy Plotner created a sky calendar with the most remakable things in the night sky for 2006. You can download the PDF file on the site of Universe Today. Stunningly beautiful !

Uptime


# w
2:51pm up 852 day(s), 18:35, 2 users, load average: 0.77, 0.61, 0.33

# init 0

I guess this is a record. I was afraid the server would reboot with fsck errors, but it came back online without a glitch. This is a Netra server running Solaris 7. My heart bleeds every time I must do this, but patching is a necessary thing...

Aaarghhh

Aaarghh ! The Aargh Page is a visual representation of the relative frequencies of aarghh. The number of ways one can write aaarghhh is aarghuable, off course. Would there be other words written like that ? Hmmmm...

Plooiwerk

Het wordt ondertussen aftellen naar het huwelijksfeest. Nog een kleine maand te gaan, en ondertussen is zowat alles geregeld. De misboekjes zijn gekopieerd, en het zelf plooien en nieten van zo'n 60 boekjes is toch wat meer werk als gedacht. Ook het noteren van wie nu komt naar de receptie en naar het avondfeest is een dagelijkse bezigheid geworden.

Net terug ook van de Lovers4ever trouwbeurs in de Mechelse Nekkerhal; de bedoeling was om wat meer adressen te krijgen voor de trouwringen, en de huwelijksreis, maar de beurs zelf was door zijn kleine opzet een beetje een ontgoocheling. Allee, we hebben toch een afspraak met een goudsmid deze week, maar qua trouwringen is het toch lastig kiezen. Niet moeilijk, als je weet dat de meeste trouwringen zo'n lelijk bladnerfmotief dragen tegenwoordig.

How do I REALLY delete a file ?

Do you know that deleting a file really doesn't delete the file content on your disk ? In Unix, a file delete (rm) unlinks the inode, but doesn't actually zero-out the data blocks associated with the file. How can you really destroy the contents of a file? What if you're doing a rm -r of hundreds of files? Deleting files on disk-level can be very interesting if you have highly sensitive data on your disks. Many people who are using Unix know GNU shred, but the docs state "that shred relies on a very important assumption: that the filesystem overwrites data in place." This is the traditional way to do things, but many modern filesystem designs [such as Solaris' UFS] do not satisfy this assumption. ZFS is even trickier, as it uses Copy On Write, so overwriting data actually never happens !

I'll present some ways of deleting data on your disks.

  1. The safest option for really deleting a file is to remove the hard drive and physically destroy it. While I relish the thought of beating Sun equipment with hammers, actual physical destruction of hardware is not always an option. Your employer may have very specific policies that must be followed.
  2. If you have a degausser laying around, you could degauss the disks. In addition to wiping the contents of the platters themselves, degaussing can render the drives unusable by destroying timing tracks, server motors, and spindle
    motors. Spectrumwest.com had some interesting details.
  3. Low-level formats :
    This approach assumes you want to delete an entire disk drive or at least an entire file system. These could not be used to target specific files while leaving the rest of the file system intact. Definately worth including though: Sun Blueprint scrubbing disks.
  4. Alternatives :
    Repeatedly format > analyze > [purge|write|compare]

    Overwrite raw device with something such as:
    dd if=/dev/zero of=/dev/rdsk/c#t#d#s#

  5. Fill up the file system :
    A safe way of cleaning a drive is to delete all the files/data we wanted destroyed. Then, fill the file system with junk. One problem with this approach is that it assumes we already know ALL of the sensitive files that should be deleted and don't forget one. Unless all of your sensitive data is positively stored in a known area, you risk leaving a file alive by mistake.

    a. Remove all files of interest.
    This will leave disk blocks on the free list which may contain some data that you'd rather not see leave your custody.

    b. AS ROOT, run this on each filesystem where the files from (a) used to live:
    yes > junk
    and let it run until the filesystem is completely full. Why "as root"? Because the last 10% of the actual free space on each filesystem is reserved for root. (See "tunefs".) This allows root user to manipulate the filesystem and recover from some space exhaustion problems -- even when the filesystem appears to be "full" from the viewpoint of end users.

    c. Of course, "yes > junk" is rather simple-minded and relatively slow - something that did block writes would run a heck of a lot faster. So for example, you might want to use something a notch more sophisticated, along these general lines:
    touch junk
    while (1)
    dd if=/some/big/file/full/of/crud bs=20k >> junk
    end

    to do 20K writes. This should run considerably faster, and of course you could also do your variant of this with shell, perl, C, python, whatever you wish. The general idea though, is that you want to force the system to allocate every (currently) free block so that you can scribble on it. This should put recovery of the data beyond the ability of most people.