[GLLUG] The best way to decommission a remote server?

[tid]

I recommend never typing rm -rf /* - I have seen/heard others who forgot to
unmount nfs shares / fusefs & unplug USB disks etc.

shred and dd are much safer.




On 17 December 2013 11:18, James Courtier-Dutton <james.dutton at gmail.com>wrote:

> Ah!  When deleting the .vmdk file would be the easiest solution...
> An alternative:
> Lets call the one you want to delete the "bad" one.
> Create a new clean install VM. Call that the "good" one.
> Stop the bad VM.
> Start the good VM.
> Mount the bad .vmdk somewhere on the good VM.
> You can then delete the contents of the bad .vmdk from within thee good VM.
>
> James
>
>
>
> On 17 December 2013 11:06, Oliver Howe <ojhowe at gmail.com> wrote:
> >
> > Well, piece of mind for my managers really. As the host is a VM the
> client
> > could have veam'd it or made a snapshot without us knowing and would be
> able
> > to restore it elsewhere even after I have wiped the existing VM. I dont
> have
> > access to the ESX host, I only have SSH access.
> >
> >
> >
> > On Tue, Dec 17, 2013 at 10:37 AM, Alain Williams <addw at phcomp.co.uk>
> wrote:
> >>
> >> On Tue, Dec 17, 2013 at 09:59:40AM -0000, Martin A. Brooks wrote:
> >> > On Tue, December 17, 2013 09:57, Oliver Howe wrote:
> >> > > Anyone have a better way?
> >> >
> >> > dd is likely to be more successful.
> >>
> >> What are you trying to achieve ? Presumably protect stuff from being
> >> grabbed by
> >> whoever subsequently has access to the hardware.
> >>
> >> What stuff - customer data or operating system programs that everyone
> has
> >> access
> >> to ?
> >>
> >> How much effort do you think someone will put into to try to recover the
> >> customer data ? If a lot then 'rm' just puts blocks back onto the file
> >> system free
> >> list, you might want to use a program like 'shred' to overwrite blocks
> >> first.
> >>
> >> Customer data is the most important. This is likely to be under /home or
> >> /var or similar.
> >> I would concentrate of clearing that first. Then worry about things like
> >> passwords in /etc/shadow.
> >>
> >> Beware doing 'dd if=/dev/zero of=/dev/hard-disk'  The dd program has
> >> several
> >> libraries dynamically linked into it, on one *nix a few years ago when I
> >> overwrote a file that was memory mapped (dump doing a restore), the
> >> program died
> >> when part of its memory image got replaced by zeros.
> >>
> >>
> >>
> >> Also think about where the backups are done to.
> >>
> >> --
> >> Alain Williams
> >> Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer,
> IT
> >> Lecturer.
> >> +44 (0) 787 668 0256  http://www.phcomp.co.uk/
> >> Parliament Hill Computers Ltd. Registration Information:
> >> http://www.phcomp.co.uk/contact.php
> >> #include <std_disclaimer.h>
> >>
> >> _______________________________________________
> >> GLLUG mailing list
> >> GLLUG at mailman.lug.org.uk
> >> https://mailman.lug.org.uk/mailman/listinfo/gllug
> >
> >
> >
> > _______________________________________________
> > GLLUG mailing list
> > GLLUG at mailman.lug.org.uk
> > https://mailman.lug.org.uk/mailman/listinfo/gllug
> >
>
> _______________________________________________
> GLLUG mailing list
> GLLUG at mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/gllug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20131218/131c34dd/attachment.html>