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

James Courtier-Dutton james.dutton at gmail.com
Tue Dec 17 11:18:09 UTC 2013


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
>




More information about the GLLUG mailing list