Subject: Re: My take on the Red Hat / Fedora Secure Boot controversy
This is about avoiding a dystopia where Microsoft decides what boots and what doesn't. Perhaps they are allowing Secure UEFI to be disabled on x86 computers *now* but it's a reasonable assumption that for Windows 9 hardware certification they will prohibit the manufacturer from allowing the user to disable secure boot, just like they do now with Windows 8 certification on ARM machines.
If this is allowed to continue, we are only a few years away from the complete extermination of Linux on consumer grade hardware. Computers will become like mobile phones, where it is a difficult hacking job to run any operating system other than the one that was preinstalled.
I don't know what Verisign's involvement is, but if Secure UEFI is allowed to continue then the OEM's need to be persuaded to trust someone else in addition to Microsoft.
Ideally there needs to be a vendor-neutral organization that tests and certifies boot loaders, and the computers would be configuredc to trust any boot loader signed by *that* organization's key. As it stands now, from what I understand, the OEM's are trusting Microsoft's signing key, so the computers will simply boot anything signed by Microsoft and nothing else. This cannot be allowed to continue, and I think anyone who believes otherwise should be violently molested by Richard Stallman until they change their mind.
Subject: Re: My take on the Red Hat / Fedora Secure Boot controversy
Subject: Re: My take on the Red Hat / Fedora Secure Boot controversy
remember css? or the ps one? or the wii? or the xbox? or the iphone? or blueray? or in special the PSIII?
as long as they give the hackers the opportunity to play (a way to turn it off, or like redhat sign bootloaders) its going to survive.
When Sony took away the "other OS" - option for the psIII, it was half a year for their protection to be broken.
while the "otheros" option might have been commercialy questionable (people building clusters with cheap hardware intended to be fully paid by purchasing games) it was the only way for them to remain unhacked for 4 years.
I realy think the same accounts for secure boot.
Subject: Re: My take on the Red Hat / Fedora Secure Boot controversy
Hardware focused open source/free technology projects such as Open Source Ecology (OSE), Research Do-It-Yourself and WikiSpeed are catching on. OSE has four of fifty industry grade machines already completed, available for any settlement to construct from basic tools and materials. The fifty modular machines include tractors, bread ovens and circuit makers. In time, the technology dependency tree will be complete enough to locally produce computational devices. This is when profit-driven corporations will not be able to impose standards.
It starts to become interesting when you apply the free technology movement to the distributed/networked governance movement through the Transition Network, which places settlements as sovereign prosperity regerative enterprises that will require these tools to be as self-reliant as possible.
http://opensourceecology.org http://www.rndiy.org http://www.wikispeed.com http://www.transitionnetwork.org
Subject: Re: My take on the Red Hat / Fedora Secure Boot controversy
MICROSOFT IS SLAUGHTERING BABY PENGUINS AND MUST BE STOPPED !!!
Secure Binder
Don't give permission to any application programs to write the boot sector!
I know. I know. This is MS Windows we're talking about, here. In Linux, you can only write the boot sector if you have root privileges, and it's assumed that if you've got root privileges, you know what you're doing.
It's really about DRM. They want to have a boot chain where every link in the chain is digitally signed... never mind, I think, that on a PC that doesn't really gain you foolproof security because decryption is, I think, still happening in software... doesn't matter because the pinheads at the RIAA/MPAA/NSA demand it.
Of course PC's will still keep the option of booting with disabled Trusted Boot. It's just that eventually your BluRay player will refuse to run unless Trusted Boot is turned on.
Oh, I've got a line-of-code or two contributed to the kernel, and the day that Trusted Boot becomes no-longer-optional is the day that I sue Red Hat to prevent them from distributing my code...
It's definitely time to boycott Hollywood.
Also Bollywood. I want freedom from Bollywood.
The simplest way to get them to go away is to keep pirating their movies (if you really want to watch the latest rehashes of shit that was popular 30 years ago) or don't watch them. I choose to not even watch them.
I would like to actually have something like Secure Boot, but in a way that I can trust it. I boot most of my machines with a kernel and an initrd which contains some cryptsetup/luks stuff in order to open my encrypted containers via password. So I need to trust that noone tampers with the initrd in the meantime. (Using passwdfiles instead of manually entering them doesnt improve this situation very much.)
But with SecureBoot the way it is realised, I need to trust whoever certified the bootloader. And since both stuxnet and flame hat official certs and Verisign got broken into and my general paranoia assures me that at least the NSA or the Aluminium Bavariati have general "All Area" tickets, this whole system is broken by design and possibly the main idea is what IG says.
But like dothebart says, almost no copyright mechanism has ever protected a product from pirates. Especially not mainstream software and when it comes to gaming platforms. I predict that the SecureBoot2 will require your machine to be connected to an onlineserver in order to check if your account is allowed to use it, this time providing real protection!
WRT to the Hollywood issue: Do not even pirate their shyte, do not even ignore it and do not finish reading this sentence! Watch asian movies, they are the opposite of Hollywood movies: The actors all look alike but the plots are pretty unique.... Even the greeks make interesting movies these days (Dogtooth for example.)
If I were a hermit I'd simply avoid them altogether, and if something looked vaguely interesting I'd either wait until it became available via "free download" or sneak into a theater. However, I have a family, so that's not always an option...
http://www.youtube.com/watch?v=MShbP3OpASA#t=49m33s
You'll never see that kind of awesome from Apple or Microsoft.
Subject: Which backup solutions for a single fileserver?
So I have this customer with one fileserver and I have rsnapshot installed as a backup system, but I am totally unhappy with it.
We currently have incremental backups each day and keep a weekly snapshot. The users there tend to delete or overwrite files quite often, so in the future I want to use something different. They are architects, so mostly some very recent files change often, but when the building is finished, files dont really change but are kept for reference, etc.
I want to keep the incremental daily backups and probably four weekly backups, also about 6 monthly incremental backups on the harddisks. But I also want to keep a full backup of the last four weeks on tape seperately or maybe one tape for each whole month. I really haven't set up something like this before.
This is what the disk usage is currently, data isn't really growing much and could be reduced if long time archive tapes or similar would be established.
/dev/mapper/vg_data 493G 269G 199G 58% /srv
/dev/mapper/vg_backup 739G 388G 314G 56% /mnt/backup
rsnapshot doesn't give me the granularity I need, Amanda does not seem to do on-disk backups the way I need them: Users should be able to retrieve files from the on-disk backup via a comfortable samba read-only share.
So, do you have any recommendations? Should I combine some backup tools? Like something for the on-disk backups and amanda for the tape stuff?
Thanks for reading so far
Subject: Re: Which backup solutions for a single fileserver?
I was using the symantec backup solution for some of my consulting clients for a while....but that may be overkill for a single server.
Subject: Re: Which backup solutions for a single fileserver?
The key element: store your backups on a btrfs filesystem. COW snapshots for the win!
I needed a 7-day retention, but you can modify this method accordingly for whatever you need. There isn't much cost to doing daily differentials instead of a g-f-s rotation, because btrfs only tracks the changed blocks on disk instead of requiring an entire new copy of every file that changed.
Here's how I did it. I have a filesystem called /backup which is formatted btrfs. I am naming my snapshots after the day of the week:
dotw=`/bin/date +%A`
First, I delete the snapshot from seven days ago (during the initial seven days this will fail, and we don't care):
btrfs subvolume delete /backup/$dotw
Then we do our snapshot:
btrfs subvolume snapshot /backup /backup/$dotw
After that's done, we simply rsync our data from its live sources to directories underneath /backup; how you do this is up to you. I choose to have a directory underneath /backup with the name of the source host but you can modify this according to your needs.
If I had users who need to be able to access the backups like you do, then it would be trivial to expose /backup as a read-only share.
Now, my method combines backup and retention into a single regime. If all you need is the snapshots, and you're handling backups some other way, you could simply run your primary filesystem on btrfs and take the snapshots there.
In my case, however, the source hosts are at a carrier class data center and the backups are at my home.
Subject: Re: Which backup solutions for a single fileserver?
If you are using rsnapshot already, you might give duplicity a look:
It has had some growing pains over the last few years, but has grown to be a decent solution for me. The best part I have found using duplicity is the ability to change out the back end by simply rsyncing the store to another back end and changing the backup url scheme.
The part I did not like is figuring out how to script it. There are convenience scripts out there that wrapper duplicity, but I don't trust them yet. If you want I could share what I have so far and what I have written for a wrapper for duplicity. It is quite flexible for doing backups where you have different backups to run (especially if you need to backup parts of filesystems on a different schedule as you can split a backup in to parts).