31–40 of 60 posts
Related to this, is there a tool like this, but that can show some kind of simple analytics, for example page views over a period of time from an access log produced by python html server.
Yes, you can use → https://goaccess.io/
Earlier quoted context omitted.
It would be as hard as writing the file {n} number of times again. So if one created a 1MB log file and then did a 3 pass wipe that would write 3MB. Number of passes would really just depend on the system being worked on. If PCI I would expect 7 passes and I am sure that would just be factored into the cost of the servers for that environment. Shred also isn't perfect as it has no concept of the file systems journal…
Shred doesn't work at all on SSDs because wear leveling will spray the writes all over the drive, rather than overwriting the blocks you intended to. Your random bytes will end up in new blocks, not overwriting the original blocks. Trying to shred individual files is a totally pointless exercise on SSDs. It isn't doing what you want it to do.
Either way one should also use filesystem and file level encryption for sensitive files and encrypt sensitive attributes inside databases. Swap must also be encrypted as it may contain sensitive data. Datacenter bad-drive mishaps do happen as in not shredding the physical drive as a few government and military agencies have recently been embarrassed by.
I do agree with pinkorchid that ultimately drives should be destroyed physically.
Related to this, is there a tool like this, but that can show some kind of simple analytics, for example page views over a period of time from an access log produced by python html server.
You can see it in action here: https://www.logviewplus.com/docs/create_a_custom_report.html
Earlier quoted context omitted.
Shred doesn't work at all on SSDs because wear leveling will spray the writes all over the drive, rather than overwriting the blocks you intended to. Your random bytes will end up in new blocks, not overwriting the original blocks. Trying to shred individual files is a totally pointless exercise on SSDs. It isn't doing what you want it to do.
I've also seen people say that and to instead use "blkdiscard -sz" but that also does not write to specific blocks. I still can not find a definitive source saying that shred is not able to write to specific blocks on a SSD and it is not clear to me that wear leveling actually prevents shred from writing to specific blocks. But I agree that I have seen people say this repeatedly on StackExchange, ServerFault and Redd…
This behavior is fundamental; it's what wear leveling is and why it exists. Wear leveling exists to prevent you from writing to the same block repeatedly, which is exactly what you're trying to do with shred.
I'm not sure what other source you're looking for, but I hope you find it. Perhaps, at least, the number of people "on StackExchange, ServerFault and Reddit" and now also HackerNews telling you the same thing is sufficient evidence to stop spreading the idea that shred might work on SSDs. Do what you want on your own systems, of course, but this is dangerously misleading guidance to be offering on an open forum.
Related to this, is there a tool like this, but that can show some kind of simple analytics, for example page views over a period of time from an access log produced by python html server.
With caddy server
For Windows users, there is LogViewPlus. (I am the author). https://www.logviewplus.com/ It has a similar feature set (tail, syntax highlighting, SQL reporting) with a focus on accessing files remotely.
Related to this, is there a tool like this, but that can show some kind of simple analytics, for example page views over a period of time from an access log produced by python html server.
If you want to write more complicated queries, lnav exposes log data through SQLite vtables[1]. So, you can do a SQL query and get a simple bar chart visualization.
[1] - https://docs.lnav.org/en/latest/sqlext.html#sqlite-interface
For example the http 403/404 is red but it does not stand out. Also why a 404 would be red in the first place.