Crypted backup Looking for suggestions
Hey, Im looking for some suggestions about how to keep a backup in a remote (shared) PC. I got 20GB of srcs and images in my pc (PCBSD) and i got access to 100GB in a shared DFBSD2.2 server (all hammerFS). I want to use the server to keep a backup of my files in a remote location (in a daily basis) I dont mind if other users can see the name of the files, but i will like to keep the contents private and be spacewise. My first attemp was create an asymetric key pair, copy the full tree to a temp location, crypt every file in the second tree and rsync the content to server, after that if i need to restore the info in another pc, i download in a temp tree, then decrypt and copy to the real location. I know there should be a easier way. Thanks for any suggestion. Sdav
Re: Installing DragonFly
Colin Adams wrote: I couldn't use Windows anything - that is banned from my house. Good news, that. Should reduce your long-term rosk of stroke or hear attack. ;-) Equally, I can't use a Linux fdisk (for instance), because I can't boot the computer at all if the disk is plugged in. If I remove uncable the disk, then I can boot from the DragonFly live DVD (or any other live CD/DVD presumably). But then I can't do anything to the disk because it isn't plugged in. Suggestion (from 'bitter' experience) - get your hands on another HDD, (temporarily) make that one the 'primary' and set it up with (at least) one or more *BSD and a low-hassle Linux. My mix of choice is FreeBSD, NetBSD, DFLY & Vector Linux 5.9 Std edition. (It often helps to see how, or IF 'the other guy' reads your MBR and disklabel) You should then be able to attach the problematic disk - before or after boot. (Suspicion - is your BIOS set ot boot form it? and if so, can that be changed?) Further - RAID quite aside, FreeBSD atacontrol, DFLY natacontrol have convenient utilities to list, attach/detach, re-scan, ATA chanels and devices et al w/o reboot. fdisk and disklabel / bsdlabel, then newfs should let you re-slice etc to clean up the problematic HDD. Presuming thet HDD is the newer/larger/faster or otherwise more desirable device, you should then be able to reverse the process and do further experimentation on the 'other' less-valuable HDD as a secondary. It can be helpful to have multiple versions of /etc/fstab on each that can be 'cp'ed into place rather than edited to either/both get desired dev ID's to fit detached/swapped situations, and/or do only partial mounting with the rest done manually or by script other-than-fstab. Thereafter, DFLY/FreeBSD boot manager should handle the rest painlessly. You *can* 'get there from here' with a Live CD - but a fully-functional HDD install give you a richer toolset and more flexibility for relatively low cost in time and hardware - especially if the 'other' HDD can be USB-attached. HTH, Bill Hacker 2009/4/15 Simon 'corecode' Schubert : I bet this is the "set all bits to one on CHS overflow" thing in fdisk. I'd really like to know how we are supposed to handle this (better). Colin, sorry for trashing your computer. I think we are well aware of this issue, but we simply don't know exactly how to deal with it. Could you maybe use window's fdisk to create a large partition on the drive and then report back how the partition table looks like? In this case we could adjust our fdisk so that this won't happen again. thanks simon Colin Adams wrote: What appears to have happened is that in some way it has trashed my disk-drive - I can still get the machine to boot from the live CD, but only if I physically disconnect the hard-disk first. 2009/4/8 Hasso Tepper : Colin Adams wrote: Well, if that is the case the ISO should not be available for download - there should be a fixed version. Well. It shouldn't be any way fatal, but in general I agree - we should release 2.2.1 ASAP, really. -- Hasso Tepper
Re: Installing DragonFly
You can try booting a linux live cd, then plugging in the hdd after the bios screen, but before the linux kernel starts running. cheers simon Colin Adams wrote: I couldn't use Windows anything - that is banned from my house. Equally, I can't use a Linux fdisk (for instance), because I can't boot the computer at all if the disk is plugged in. If I remove uncable the disk, then I can boot from the DragonFly live DVD (or any other live CD/DVD presumably). But then I can't do anything to the disk because it isn't plugged in. 2009/4/15 Simon 'corecode' Schubert : I bet this is the "set all bits to one on CHS overflow" thing in fdisk. I'd really like to know how we are supposed to handle this (better). Colin, sorry for trashing your computer. I think we are well aware of this issue, but we simply don't know exactly how to deal with it. Could you maybe use window's fdisk to create a large partition on the drive and then report back how the partition table looks like? In this case we could adjust our fdisk so that this won't happen again. thanks simon Colin Adams wrote: What appears to have happened is that in some way it has trashed my disk-drive - I can still get the machine to boot from the live CD, but only if I physically disconnect the hard-disk first. 2009/4/8 Hasso Tepper : Colin Adams wrote: Well, if that is the case the ISO should not be available for download - there should be a fixed version. Well. It shouldn't be any way fatal, but in general I agree - we should release 2.2.1 ASAP, really. -- Hasso Tepper
Re: Installing DragonFly
I couldn't use Windows anything - that is banned from my house. Equally, I can't use a Linux fdisk (for instance), because I can't boot the computer at all if the disk is plugged in. If I remove uncable the disk, then I can boot from the DragonFly live DVD (or any other live CD/DVD presumably). But then I can't do anything to the disk because it isn't plugged in. 2009/4/15 Simon 'corecode' Schubert : > I bet this is the "set all bits to one on CHS overflow" thing in fdisk. I'd > really like to know how we are supposed to handle this (better). > > Colin, sorry for trashing your computer. I think we are well aware of this > issue, but we simply don't know exactly how to deal with it. Could you > maybe use window's fdisk to create a large partition on the drive and then > report back how the partition table looks like? In this case we could > adjust our fdisk so that this won't happen again. > > thanks > simon > > Colin Adams wrote: >> >> What appears to have happened is that in some way it has trashed my >> disk-drive - I can still get the machine to boot from the live CD, but >> only if I physically disconnect the hard-disk first. >> >> >> 2009/4/8 Hasso Tepper : >>> >>> Colin Adams wrote: Well, if that is the case the ISO should not be available for download - there should be a fixed version. >>> >>> Well. It shouldn't be any way fatal, but in general I agree - we should >>> release 2.2.1 ASAP, really. >>> >>> >>> -- >>> Hasso Tepper >>> > >
Re: Installing DragonFly
I bet this is the "set all bits to one on CHS overflow" thing in fdisk. I'd really like to know how we are supposed to handle this (better). Colin, sorry for trashing your computer. I think we are well aware of this issue, but we simply don't know exactly how to deal with it. Could you maybe use window's fdisk to create a large partition on the drive and then report back how the partition table looks like? In this case we could adjust our fdisk so that this won't happen again. thanks simon Colin Adams wrote: What appears to have happened is that in some way it has trashed my disk-drive - I can still get the machine to boot from the live CD, but only if I physically disconnect the hard-disk first. 2009/4/8 Hasso Tepper : Colin Adams wrote: Well, if that is the case the ISO should not be available for download - there should be a fixed version. Well. It shouldn't be any way fatal, but in general I agree - we should release 2.2.1 ASAP, really. -- Hasso Tepper
Re: One more pkgsrc problem
Hasso Tepper wrote: > Building devel/libgweather fails 100% during bulk build with "Out of > memory" message. It took some time to find out why the heck it builds > fine on my development machine (PIV with 256MB memory), but fails 100% > on my bulk build machine (Core2 with 2GB memory). But the point is > chroot. Building in chroot environment fails. Any ideas? Is there > memory limits specific to chroot? There is another package which fails to build in chroot, but builds just fine in normal environment - www/firefox3. The message isn't memory related though: nsIConsoleListener.idl ../../dist/bin/xpidl -m header -w -I. -I../../dist/idl -o _xpidlgen/nsIConsoleListener nsIConsoleListener.idl ** (process:79087): WARNING **: Parse of nsIConsoleListener.idl failed: unknown error (9) make[4]: *** [_xpidlgen/nsIConsoleListener.h] Error 1 make[4]: Leaving directory `/usr/pkgsrc/www/firefox3/work/mozilla/xpcom/base' make[3]: *** [export] Error 2 While libgweather has shown similar failures before (at some point it just didn't fail any more), firefox3 failure is new and appeared after libc changes. Any (I really mean it) ideas? -- Hasso Tepper
Re: Consequences of major libc changes
Peter Avalos wrote: > Is there any advantage that libc_r has over libthread_xu? Not nowadays. It's been already discussed and all agreed that we should remove it. http://leaf.dragonflybsd.org/mailarchive/kernel/2008-12/msg00023.html I don't have resources to dig into it though. I planned to do it myself, but I'm several weeks behind my schedule even with my pkgsrc work, therefore I'm asking for help. AFAICS it's libc_r removal + introducing new symbols into libpthread wrapper (we shouldn't remove that) + some manpages work (Sascha will take care of it). -- Hasso Tepper
Re: Consequences of major libc changes
On Mon, Apr 13, 2009 at 02:20:13PM +0300, Hasso Tepper wrote: > A short list of problems based on first bulk build ... > > * It introduced some new _POSIX defines in unistd.h which are clearly > wrong for us - _POSIX_BARRIERS and _POSIX_SPIN_LOCKS are such examples. > I hope that Peter will fix these ASAP, but ... > > Although libthread_xu implements barriers, we can't use these because > libc_r doesn't. In fact it's the main reason why I vote fro libc_r > removal. Any takers for this task? Is there any advantage that libc_r has over libthread_xu? --Peter pgpuIpDF5SyVx.pgp Description: PGP signature
