Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
> The main issue as I see it is regulatory compliance. It's your customer, you calls the issue. > The man page for > the GNU coreutils "shred" command mentions that it's not guaranteed > to work on journaled or log-structured filesystems, or on RAID volumes. Yup, anything that makes it harder to accidentally trash the data makes it harder to intentionally trash irretrievably, even if it appears so to a naive and trusting user. > ITAR it's not just ITAR. PCI, HIPAA, USGovt Classified, lots of data is too sensitive to trust to 'rm' legally. > reside on our normal customer server due to this, so I now need to build > a separate server for customer ... data. Or add a non-Raid non-Jfs filesystem for their data on existing server ? A Partition per customer that mounted as their directory and device-shreded ( 'dd /dev/zero' 'dd /dev/random' 'dd /dev/zero' ?) might be workable. LVM pseudo-partitions might not be safe if they rebalance; if they fixed allocate actual sector blocks, that would be ok too. -- Bill [hidden email] [hidden email] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Discuss mailing list [hidden email] http://lists.blu.org/mailman/listinfo/discuss
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |