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

Oliver Howe ojhowe at gmail.com
Tue Dec 17 11:06:09 UTC 2013


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20131217/fd40df7f/attachment.html>


More information about the GLLUG mailing list