Hi.
I have a CentOS server (a Dell 860) with two drives in it.
One is running CentOS 6.4 which I want to keep & the bigger 400GB drive has Debian 7 on it which I want to erase & use for backups.
Which is the best way to go about achieving my intended goal? The Debian drive is not mounted when Centos is booted.
Any help appreciated.
Cheers,
Phil...
Burn a DBAN disk. Shutdown, pull out the drive you want to keep. Boot to the dban disk, when prompted type autonuke, wait for the process to complete. Shutdown, reinsert the centos drive you wanted to keep. You will now have your centos main drive, and a blank backup disk. You'll need to run mkfs on the blank drive. Then mount it where you want it.
Phil Dobbin bukowskiscat@gmail.com wrote:
Hi.
I have a CentOS server (a Dell 860) with two drives in it.
One is running CentOS 6.4 which I want to keep & the bigger 400GB drive
has Debian 7 on it which I want to erase & use for backups.
Which is the best way to go about achieving my intended goal? The Debian drive is not mounted when Centos is booted.
Any help appreciated.
Cheers,
Phil...
-- currently (ab)using Arch Linux, CentOS 5.9 & 6.4, Debian Squeeze & Wheezy, Fedora Spherical & That Damn Cat, Lubuntu 12.10, OS X Snow Leopard & Tiger, Ubuntu Quantal, Raring & Saucy GnuGPG Key : http://phildobbin.org/publickey.asc
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Bret Taylor wrote:
Phil Dobbin bukowskiscat@gmail.com wrote:
I have a CentOS server (a Dell 860) with two drives in it. One is running CentOS 6.4 which I want to keep & the bigger 400GB drive has Debian 7 on it which I want to erase & use for backups. Which is the best way to go about achieving my intended goal? The Debian drive is not mounted when Centos is booted.
Any help appreciated.
Burn a DBAN disk. Shutdown, pull out the drive you want to keep. Boot to the dban disk, when prompted type autonuke, wait for the process to complete. Shutdown, reinsert the centos drive you wanted to keep. You will now have your centos main drive, and a blank backup disk. You'll need to run mkfs on the blank drive. Then mount it where you want it.
Then put the dban disk on the shelf over your desk - you *will* want it again (and again, and again....)
Most *excellent* piece of software. Of course, working for a US federal contractor, when I sanitize, I overkill (DoD 5220.22-M)... but I *am* signing my name to the form guaranteeing it's clean.
We, at least, are not going to have accidents with PII and HIPAA data.
mark
Better safe than sorry. Even if people think it's "overkill". There's paranoid, and then there's best practice; in my mind they're one in the same.
m.roth@5-cent.us wrote:
Bret Taylor wrote:
Phil Dobbin bukowskiscat@gmail.com wrote:
I have a CentOS server (a Dell 860) with two drives in it. One is running CentOS 6.4 which I want to keep & the bigger 400GB
drive
has Debian 7 on it which I want to erase & use for backups. Which is the best way to go about achieving my intended goal? The Debian drive is not mounted when Centos is booted.
Any help appreciated.
Burn a DBAN disk. Shutdown, pull out the drive you want to keep. Boot
to
the dban disk, when prompted type autonuke, wait for the process to complete. Shutdown, reinsert the centos drive you wanted to keep. You
will
now have your centos main drive, and a blank backup disk. You'll need
to
run mkfs on the blank drive. Then mount it where you want it.
Then put the dban disk on the shelf over your desk - you *will* want it again (and again, and again....)
Most *excellent* piece of software. Of course, working for a US federal contractor, when I sanitize, I overkill (DoD 5220.22-M)... but I *am* signing my name to the form guaranteeing it's clean.
We, at least, are not going to have accidents with PII and HIPAA data.
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Please don't top post.
Bret Taylor wrote:
m.roth@5-cent.us wrote:
Bret Taylor wrote:
Phil Dobbin bukowskiscat@gmail.com wrote:
I have a CentOS server (a Dell 860) with two drives in it. One is running CentOS 6.4 which I want to keep & the bigger 400GB
drive has Debian 7 on it which I want to erase & use for backups.
Which is the best way to go about achieving my intended goal? The Debian drive is not mounted when Centos is booted.
Any help appreciated.
Burn a DBAN disk. Shutdown, pull out the drive you want to keep. Boot
to the dban disk, when prompted type autonuke, wait for the process to
complete. Shutdown, reinsert the centos drive you wanted to keep. You
will now have your centos main drive, and a blank backup disk. You'll need to run mkfs on the blank drive. Then mount it where you want it.
Then put the dban disk on the shelf over your desk - you *will* want it again (and again, and again....)
Most *excellent* piece of software. Of course, working for a US federal contractor, when I sanitize, I overkill (DoD 5220.22-M)... but I *am* signing my name to the form guaranteeing it's clean.
We, at least, are not going to have accidents with PII and HIPAA data.
Better safe than sorry. Even if people think it's "overkill". There's paranoid, and then there's best practice; in my mind they're one in the same.
The reality is that it's massive overkill. A dozen years ago, seven passes would guarantee cleanliness. These days, the way the data's stored on modern drives, I've seen people argue that one was sufficient, and surely two would be.
But it's no big deal. I usually do four at a time, shove them into an old, decommissioned server that I saved for the purpose, and leave dban in the DVD drive, fire it up, choose that, and the drives, and walk away. The next day, the following Monday, who cares? I'm mostly using them for servers that we're about to surplus.
mark
On Thu, Sep 26, 2013 at 3:47 PM, Paul Heinlein heinlein@madboa.com wrote:
On Thu, 26 Sep 2013, m.roth@5-cent.us wrote:
Burn a DBAN disk [....]
Then put the dban disk on the shelf over your desk [...]
Eh, I don't really think dban is necessary. Probably more than an fdisk and creating a file system is overkill.
Besides there's gnu shred that would do the job from his running CentOS system ... hit the secondary drive with random bits or just a pass of zeros.
# one pass random bits, one pass zero shred -vfz -n1 /dev/<something>
# zeros only shred -vfz -n0 /dev/<something>
Then make it available via PXE, though with a DANGER warning in your PXE menu :-).
Hehehe. ;)
I have dban on a pxe boot server. Initially having it there was a bit disconcerting ... more so that a coworker would stumble upon it. I hid the option in a separate menu and did put a warning in the splash message.
Off-Topic: A coworker of mine modified the dban iso so that it would boot and auto-nuke (no keyboard) ... He left that disc in a server he gave to another coworker ... who we suspect put the disc in a work computer and wiped the drive! :P
-- Paul Heinlein heinlein@madboa.com 45°38' N, 122°6' W _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Thu, 26 Sep 2013, SilverTip257 wrote:
Eh, I don't really think dban is necessary. Probably more than an fdisk and creating a file system is overkill.
My policies are work are simple:
1. Re-use by same employee: stick with filesystem tools. 2. Re-use within company: single-pass zeroing of disk. 3. Retirement of asset: three-pass of random bits.
I've never seen the need for a seven-pass randomization. If pressed, I'd probably agree that a one-pass zeroing is good enough for just about any situation. Asset retirement isn't a time-sensitive task, however, so I always use a three-pass randomization before it heads out the door.
Paul Heinlein heinlein@madboa.com wrote:
On Thu, 26 Sep 2013, SilverTip257 wrote:
Eh, I don't really think dban is necessary. Probably more than an fdisk and creating a file system is overkill.
My policies are work are simple:
- Re-use by same employee: stick with filesystem tools.
- Re-use within company: single-pass zeroing of disk.
- Retirement of asset: three-pass of random bits.
I've never seen the need for a seven-pass randomization. If pressed, I'd probably agree that a one-pass zeroing is good enough for just about any situation. Asset retirement isn't a time-sensitive task, however, so I always use a three-pass randomization before it heads out the door.
You all realize that dban only offers 3 passes, unless you pay for it, right? DBAN is easy, that's why I recommended it.
A fairly simple solution is
dd if=/dev/zero (or urandom) of=/dev/(device)
From: Steve Thompson smt@vgersoft.com
On Thu, 26 Sep 2013, Bret Taylor wrote: I usually hit the disk with a hammer. Satisfying :-)
I disassemble the drives... I keep the shiny platters to scare birds or make sculptures, and I play with the magnets!
JD
Steve Thompson <smt@...> writes:
On Thu, 26 Sep 2013, Bret Taylor wrote:
A fairly simple solution is dd if=/dev/zero (or urandom) of=/dev/(device)
I usually hit the disk with a hammer. Satisfying
-s
I run badblocks in write mode on the drive. badblbocks does four passes (all zeroes, alternating ones and zeroes both ways and all ones). This is sufficient to keep all but a high-end forensics lab from getting anything useful off of the disk and even such a lab will have a hard time. For the OP's question, this lets him know that the disk is both clean and is still good to use.
For me, if badblocks says the disk is good, it goes on the shelf as a spare until it is hopelessly obsolete. Otherwise, the disk gets used for target practice. Also, very satisfying.
Cheers, Dave
On 09/28/2013 04:14 PM, David G. Miller wrote:
Steve Thompson <smt@...> writes:
On Thu, 26 Sep 2013, Bret Taylor wrote:
A fairly simple solution is dd if=/dev/zero (or urandom) of=/dev/(device)
I usually hit the disk with a hammer. Satisfying
-s
I run badblocks in write mode on the drive. badblbocks does four passes (all zeroes, alternating ones and zeroes both ways and all ones). This is sufficient to keep all but a high-end forensics lab from getting anything useful off of the disk and even such a lab will have a hard time. For the OP's question, this lets him know that the disk is both clean and is still good to use.
How about using strong magnet on the drive :)
For me, if badblocks says the disk is good, it goes on the shelf as a spare until it is hopelessly obsolete. Otherwise, the disk gets used for target practice. Also, very satisfying.
On 09/26/13 18:32, Bret Taylor wrote:
Paul Heinlein heinlein@madboa.com wrote:
On Thu, 26 Sep 2013, SilverTip257 wrote:
Eh, I don't really think dban is necessary. Probably more than an fdisk and creating a file system is overkill.
My policies are work are simple:
- Re-use by same employee: stick with filesystem tools.
- Re-use within company: single-pass zeroing of disk.
- Retirement of asset: three-pass of random bits.
I've never seen the need for a seven-pass randomization. If pressed, I'd probably agree that a one-pass zeroing is good enough for just about any situation. Asset retirement isn't a time-sensitive task, however, so I always use a three-pass randomization before it heads out the door.
You all realize that dban only offers 3 passes, unless you pay for it, right? DBAN is easy, that's why I recommended it.
Um, no. It offers DoD 5220.22-M, which it *says* is seven passes, and I've seen that it is. And we normally use a disk until a) it dies, or b) the server it's in dies, and then reuse, or, more likely, sits around until we consider it too small.... On top of which, I *do* need to guarantee that it's clean, as I noted originally. I have *zero* intention of winding up in a news story about someone buying an old surplussed server, and finding all *sorts* of interesting data on the h/d in it.
mark
On Fri, Sep 27, 2013 at 7:11 AM, mark m.roth@5-cent.us wrote:
On 09/26/13 18:32, Bret Taylor wrote:
Paul Heinlein heinlein@madboa.com wrote:
I've never seen the need for a seven-pass randomization. If pressed, I'd probably agree that a one-pass zeroing is good enough for just about any situation. Asset retirement isn't a time-sensitive task, however, so I always use a three-pass randomization before it heads out the door.
You all realize that dban only offers 3 passes, unless you pay for it,
That's only if you just use the "autonuke" option. Press F[234] to check out the other boot options.
right? DBAN is easy, that's why I recommended it.
Um, no. It offers DoD 5220.22-M, which it *says* is seven passes, and I've
There are other dban boot options that offer settings for additional passes (>7 passes). A person could also boot to interactive mode and specify a number of passes.
An example from the isolinux.cfg that could be used as a springboard to concocting one's own wiping recipe. <snippet> LABEL paranoid KERNEL dban.bzi APPEND nuke="dwipe --autonuke --method prng --rounds 8 --verify all" silent </snippet>
seen that it is. And we normally use a disk until a) it dies, or b) the server it's in dies, and then reuse, or, more likely, sits around until we consider it too small.... On top of which, I *do* need to guarantee that it's clean, as I noted originally. I have *zero* intention of winding up in a news story about someone buying an old surplussed server, and finding all *sorts* of interesting data on the h/d in it.
At a former place of employment we would simply not leave hard drives in servers or desktops that were intended to be recycled or junked. The hard drives got disposed of separately (in this case crushed with a hydraulic wedge).
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
In the process of replacing an el5 server, I have installed el6 and scripted the creation of the users. That worked flawlessly. I then imported all the md5 encrypted passwords, and users cannot log in. I see that the new default encryption is sha512, but I thought that only applied to creating new passwords and not the decryption of existing passwords.
A couple of hours of reading man pages and Internet searches has left me clueless. Is there a way to keep sha512 as the default and to enable usage of md5 in addition to sha512?
C
Carl T. Miller wrote:
A couple of hours of reading man pages and Internet searches has left me clueless. Is there a way to keep sha512 as the default and to enable usage of md5 in addition to sha512?
Yes, I'm embarrassed. After asking for help, I double-checked the shadow file and discovered that the single quotes around the encrypted passwords were read into /etc/shadow. s/'//g fixed the problem.
As I suspected, md5 encrypted passwords can co-exist with sha512 passwords.
c
SilverTip257 wrote:
On Fri, Sep 27, 2013 at 7:11 AM, mark m.roth@5-cent.us wrote:
On 09/26/13 18:32, Bret Taylor wrote:
Paul Heinlein heinlein@madboa.com wrote:
I've never seen the need for a seven-pass randomization. If pressed, I'd probably agree that a one-pass zeroing is good enough for just about any situation. Asset retirement isn't a time-sensitive task, however, so I always use a three-pass randomization before it heads out the door.
You all realize that dban only offers 3 passes, unless you pay for it,
That's only if you just use the "autonuke" option. Press F[234] to check out the other boot options.
right? DBAN is easy, that's why I recommended it.
Um, no. It offers DoD 5220.22-M, which it *says* is seven passes, and
<snip>
seen that it is. And we normally use a disk until a) it dies, or b) the server it's in dies, and then reuse, or, more likely, sits around until we consider it too small.... On top of which, I *do* need to guarantee
that
it's clean, as I noted originally. I have *zero* intention of winding up in a news story about someone buying an old surplussed server, and finding all *sorts* of interesting data on the h/d in it.
At a former place of employment we would simply not leave hard drives in servers or desktops that were intended to be recycled or junked. The hard drives got disposed of separately (in this case crushed with a hydraulic wedge).
Hah! When we have one that's failed, it gets deGaussed here. (Except for old, 1.5x height SCSI drives, for which they "don't have a frame". Then we unscrew the thing, and disassemble, and have cool magnets, and pretty disks (which we can bend, or hit with a hammer).
mark
On 9/27/2013 7:05 AM, m.roth@5-cent.us wrote:
At a former place of employment we would simply not leave hard drives in
servers or desktops that were intended to be recycled or junked. The hard drives got disposed of separately (in this case crushed with a hydraulic wedge).
Hah! When we have one that's failed, it gets deGaussed here. (Except for old, 1.5x height SCSI drives, for which they "don't have a frame". Then we unscrew the thing, and disassemble, and have cool magnets, and pretty disks (which we can bend, or hit with a hammer).
ours are collected in a secure area, then once a month or so a chipper truck comes by and grinds them up to dust.
my feelings on disk erasure, based on years and years of being ni this industry (I started programming in 1973 with FORTRAN and punchcards, and worked on disk device drivers in the late 70s, early 80s, and work for a storage company now these last 15 years).
DOD xxxxwhatever is obsolete and meaningless. its not even used by the DOD anymore, they physically destroy anything secret. to reasonably safely erase an modern disk (thats anything since MFM/ESDI became obsolete), one pass of anything (1's is fine) and one pass of zeros is more than sufficient... EXCEPT modern disks have automatic bad block remapping, and its /very/ possible for there to still be readable albeit old data on those bad blocks. if that possibility of data leakage is unacceptable, physical destruction is appropriate.
mark wrote:
On 09/26/13 18:32, Bret Taylor wrote:
Paul Heinlein heinlein@madboa.com wrote:
On Thu, 26 Sep 2013, SilverTip257 wrote:
Eh, I don't really think dban is necessary. Probably more than an fdisk and creating a file system is overkill.
My policies are work are simple:
- Re-use by same employee: stick with filesystem tools.
- Re-use within company: single-pass zeroing of disk.
- Retirement of asset: three-pass of random bits.
I've never seen the need for a seven-pass randomization. If pressed, I'd probably agree that a one-pass zeroing is good enough for just about any situation. Asset retirement isn't a time-sensitive task, however, so I always use a three-pass randomization before it heads out the door.
You all realize that dban only offers 3 passes, unless you pay for it, right? DBAN is easy, that's why I recommended it.
Um, no. It offers DoD 5220.22-M, which it *says* is seven passes, and I've seen that it is. And we normally use a disk until a) it dies, or b) the server it's in dies, and then reuse, or, more likely, sits around until we consider it too small.... On top of which, I *do* need to guarantee that it's clean, as I noted originally. I have *zero* intention of winding up in a news story about someone buying an old surplussed server, and finding all *sorts* of interesting data on the h/d in it.
although this kind of chest-thumping may elicit the occasional chuckle from bored or weary list members on this friday afternoon, it's not much help to the OP who AFAICR was simply asking how to reuse in centos a HDD that is currently used by another OS on the same computer. So basically s/he was asking for fdisk + mkfs + edit /etc/fstab , as suggested by some. No need to digress further on DOD regulations and whatnot on this centos list. Thanks. Sur ce, bon week-end!
Nicolas Thierry-Mieg wrote:
mark wrote:
On 09/26/13 18:32, Bret Taylor wrote:
Paul Heinlein heinlein@madboa.com wrote:
On Thu, 26 Sep 2013, SilverTip257 wrote:
Eh, I don't really think dban is necessary. Probably more than an fdisk and creating a file system is overkill.
My policies are work are simple:
- Re-use by same employee: stick with filesystem tools.
- Re-use within company: single-pass zeroing of disk.
- Retirement of asset: three-pass of random bits.
I've never seen the need for a seven-pass randomization. If pressed, I'd probably agree that a one-pass zeroing is good enough for just
<snip>
Um, no. It offers DoD 5220.22-M, which it *says* is seven passes, and
<snip>
although this kind of chest-thumping may elicit the occasional chuckle from bored or weary list members on this friday afternoon, it's not much help to the OP who AFAICR was simply asking how to reuse in centos a HDD that is currently used by another OS on the same computer. So basically s/he was asking for fdisk + mkfs + edit /etc/fstab , as suggested by some. No need to digress further on DOD regulations and whatnot on this centos list. Thanks.
Hey, I mention that because I figure if it would meet their standards, it's guaranteed for anything I need. And no, I am not now, nor have I ever been under the US DoD, thankyouverymuch....* <g> But the OP did ask about cleaning it, and it's possible that something with sensitive data could go to another dept, and then they get rid of it without cleaning it, which is why all this came up.
mark
* #insert "AlicesRestaurant.h"
On 9/26/2013 11:30 AM, Phil Dobbin wrote:
I have a CentOS server (a Dell 860) with two drives in it.
One is running CentOS 6.4 which I want to keep & the bigger 400GB drive has Debian 7 on it which I want to erase & use for backups.
Which is the best way to go about achieving my intended goal? The Debian drive is not mounted when Centos is booted.
this 400GB drive is /dev/sdb ?
as root... fdisk /dev/sdb and delete all partitions, create a new linux partition thats the full size of the disk, exit fdisk. mkfs.ext3 /dev/sdb1 mkdir /backups
edit /etc/fstab and add a line to the bottom like: /dev/sdb1 /backups ext3 defaults 1 2
now, mount /backups
voila, done. your backups will be mounted as /backups when you reboot.
On Thu, Sep 26, 2013 at 3:33 PM, John R Pierce pierce@hogranch.com wrote:
On 9/26/2013 11:30 AM, Phil Dobbin wrote:
I have a CentOS server (a Dell 860) with two drives in it.
One is running CentOS 6.4 which I want to keep & the bigger 400GB drive has Debian 7 on it which I want to erase & use for backups.
Which is the best way to go about achieving my intended goal? The Debian drive is not mounted when Centos is booted.
this 400GB drive is /dev/sdb ?
as root... fdisk /dev/sdb and delete all partitions, create a new linux partition thats the full size of the disk, exit fdisk. mkfs.ext3 /dev/sdb1 mkdir /backups
edit /etc/fstab and add a line to the bottom like: /dev/sdb1 /backups ext3 defaults 1 2
now, mount /backups
voila, done. your backups will be mounted as /backups when you reboot.
I think this question is asking everyone to make lots of assumptions about your hardware config. I tend to agree with Mr. Pierce above (again, assuming you have 2 separate physical drives and not some sort of weird LVM or Hardware raid in the mix). if you're going to repurpose the drive to backups within the same machine, going to the effort of running 7 pass DOD graded disk wipe utils seems to me at best kinda dumb and very wasteful for time, at worse it'll take more life off an old disk. then again, there's assuming in that answer, too.
On 26/09/13 20:33, John R Pierce wrote:
On 9/26/2013 11:30 AM, Phil Dobbin wrote:
I have a CentOS server (a Dell 860) with two drives in it.
One is running CentOS 6.4 which I want to keep & the bigger 400GB drive has Debian 7 on it which I want to erase & use for backups.
Which is the best way to go about achieving my intended goal? The Debian drive is not mounted when Centos is booted.
this 400GB drive is /dev/sdb ?
as root... fdisk /dev/sdb and delete all partitions, create a new linux partition thats the full size of the disk, exit fdisk. mkfs.ext3 /dev/sdb1 mkdir /backups
edit /etc/fstab and add a line to the bottom like: /dev/sdb1 /backups ext3 defaults 1 2
now, mount /backups
voila, done. your backups will be mounted as /backups when you reboot.
Thanks to everybody for their input but I think I'll go with the method above. The disk is virtually a virgin Debian install so no secret or critical files are aboard & I think this should suffice.
Thanks for your help,
Cheers,
Phil...
On 28/09/13 16:35, Phil Dobbin wrote:
On 26/09/13 20:33, John R Pierce wrote:
On 9/26/2013 11:30 AM, Phil Dobbin wrote:
I have a CentOS server (a Dell 860) with two drives in it.
One is running CentOS 6.4 which I want to keep & the bigger 400GB drive has Debian 7 on it which I want to erase & use for backups.
Which is the best way to go about achieving my intended goal? The Debian drive is not mounted when Centos is booted.
this 400GB drive is /dev/sdb ?
as root... fdisk /dev/sdb and delete all partitions, create a new linux partition thats the full size of the disk, exit fdisk. mkfs.ext3 /dev/sdb1 mkdir /backups
edit /etc/fstab and add a line to the bottom like: /dev/sdb1 /backups ext3 defaults 1 2
now, mount /backups
voila, done. your backups will be mounted as /backups when you reboot.
Thanks to everybody for their input but I think I'll go with the method above. The disk is virtually a virgin Debian install so no secret or critical files are aboard & I think this should suffice.
Thanks for your help,
I went down the GParted route in the end. Booted from System Rescue CD & got shot of the stuff that was on there. Worked a treat.
Cheers,
Phil...
-
Bret Taylor -
Carl T. Miller -
David G. Miller -
John Doe -
John R Pierce -
Ljubomir Ljubojevic -
m.roth＠5-cent.us -
mark
-
Nicolas Thierry-Mieg -
Paul Heinlein -
Phil Dobbin -
SilverTip257 -
Steve Thompson -
zGreenfelder