From boxbackup at fluffy.co.uk Sun Feb 1 09:06:32 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Sun, 1 Feb 2004 09:06:32 +0000 Subject: [Box Backup] How to include a single file? In-Reply-To: References: <2D50070E-5436-11D8-A3E0-003065F8EC8E@fluffy.co.uk> Message-ID: On 31 Jan 2004, at 21:59, Eduardo Alvarenga wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sat, 31 Jan 2004, Ben Summers wrote: > >>> I'm trying to backup "/bsd" (single file) and it is not working: >> >> The "Path" must be a directory, not a file. I suggest you create a >> directory on the same filesystem as the file you want to back up, and >> hard link the file into it (not symlink). Then backup that directory. >> >> Is this a major limitation? > > Sure. I want to backup some files without touching them. I have some > directories which I want only some files to be backuped (temp files > come to mind). Regex will be welcome too. You have a version which does Regex excludes. > > If you mind, please change "Path =" to something like "Include =" > beeing it a directory or not. > > If you have time today, (an of course, IF want to make it) please send > me a new snapshot, I have to implement the backup schema today since > today is saturday and no one is working here. Actually, I spoke too soon. It is possible to do exactly what you want by use of regular expressions -- set the path to be the containing directory and exclude all the things you don't want to back up. For example... root-for-bsd { Path = / ExcludeDirsRegex = . ExcludeFilesRegex = ^[^b][^s][^d] } Of course, this is a little clumsy (and this example won't actually work in the general case, just in the case of a normal root directory), and would be easier if I added way of saying "not" a regular expression. > > And, how about splitting boxbackup into 2 files? A server and a client > one? The distribution files would be about the same size. I see little point, especially as you don't have to make the parcel you don't want. make parcels/boxbackup-0.03-backup-client-OpenBSD.tgz But... given that they share so much code, making the server if you've made the client doesn't take much longer, so I didn't think it would be worth making this neater. Ben From boxbackup at fluffy.co.uk Sun Feb 1 09:30:12 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Sun, 1 Feb 2004 09:30:12 +0000 Subject: [Box Backup] Success stories? Message-ID: <3C0AC921-5499-11D8-A6FD-003065F8EC8E@fluffy.co.uk> Hi everyone, I've heard about quite a few problems people have been having with Box Backup, but no reports of success. Has anyone got it running successfully? How's it working out? Thanks! Ben From boxbackup at fluffy.co.uk Sun Feb 1 11:22:17 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Sun, 1 Feb 2004 11:22:17 +0000 Subject: [Box Backup] Revised web site Message-ID: I've just uploaded a revised version of the web site. Hopefully it answers most of the queries we've discussed so far. http://www.fluffy.co.uk/boxbackup/ I would appreciate any comments. Thanks, Ben From boxbackup at fluffy.co.uk Sun Feb 1 18:16:57 2004 From: boxbackup at fluffy.co.uk (Pascal Lalonde) Date: Sun, 1 Feb 2004 13:16:57 -0500 Subject: [Box Backup] Danger of files being erased Message-ID: <20040201181657.GA19903@plasma.doom.und> I've been thinking... What happens if a box running the BoxBackup client gets broken into? What if that person has bad intentions, or worse, is filled with intentions of the purest evil, decides to use the BoxBackup client to log in the server and destroy your backup? Is it possible to somehow delete all backupped files using the client? If so, it is quite frightening. I'm not saying that I'm expecting my servers to be compromised, but you can never be 100% safe. Maybe there should be an additionnal protection when it comes to deleting files. For example, the server could refuse deleting any files unless the client supplies a specific passphrase. And also is it possible to lock the backup key, like putting a passphrase on it? Of course the passphrase has to be entered before using the key, which means when bbackupd or bbackupquery is started. And I was also thinking about some maintenance functions. After a while, the server may be filled with a lot of old data. Maybe there should be a utility which removes all data that is X days or older, unless there is only one version of the file, of course. This is yet another suggestion, which I don't have a need for right now, but it could be handy someday. Consider a big user base which works with big data files that are updated often, maybe within a few months the data on the server would grow too big. Aside from that, I haven't played a lot with BoxBackup yet. But here are the good points I noticed: - The server hasn't crashed. It runs on OpenBSD 3.3. It doesn't seem to be leaking, having run for a few days. (Although the data backed up it pretty small, it may not be significant). From ps aux: _bbstored 2040 0.0 0.5 1340 1328 ?? S Wed06PM 0:00.74 bbstored: server (bbstored) _bbstored 28541 0.0 1.0 2980 2624 ?? S Wed06PM 0:13.02 bbstored: housekeeping, idle (bbstored) - Same for the client. It hasn't crashed: root 14512 0.0 0.8 1016 2164 ?? I Thu01AM 0:10.28 bbackupd: idle (bbackupd) - It was a little tricky to install, but I suspect the next version will fix a lot of that. Once it is installed though, you can forget about it and it just runs, silently. - I like the way files are restored, although a little search command could be useful someday. - I'm really considering running it on every machine I own. I'm just waiting to get more disk space. - Especially useful with a laptop! I don't backup a lot of data yet, so I can't really say more than that for now, and maybe with more data other problems will arise. Oh, and I noticed a typo in bbackupquery: Unrecognised command -> Unrecognized command 'z', not 's'. Pascal Lalonde From boxbackup at fluffy.co.uk Sun Feb 1 18:28:36 2004 From: boxbackup at fluffy.co.uk (Jesus Climent) Date: Sun, 1 Feb 2004 19:28:36 +0100 Subject: [Box Backup] Danger of files being erased In-Reply-To: <20040201181657.GA19903@plasma.doom.und> References: <20040201181657.GA19903@plasma.doom.und> Message-ID: <20040201182836.GD555@reypastor.hispalinux.es> On Sun, Feb 01, 2004 at 01:16:57PM -0500, Pascal Lalonde wrote: > > Oh, and I noticed a typo in bbackupquery: > Unrecognised command -> Unrecognized command > 'z', not 's'. With "s" is British English. With "z" is American. J -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.24|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 Problem? I haven't got a problem. I've got fucking problems. Plural. --Ted the Bellhop (Four Rooms) From boxbackup at fluffy.co.uk Sun Feb 1 22:10:18 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Sun, 1 Feb 2004 22:10:18 +0000 Subject: [Box Backup] Danger of files being erased In-Reply-To: <20040201181657.GA19903@plasma.doom.und> References: <20040201181657.GA19903@plasma.doom.und> Message-ID: <6B6177A0-5503-11D8-B39D-003065F8EC8E@fluffy.co.uk> On 1 Feb 2004, at 18:16, Pascal Lalonde wrote: > > I've been thinking... > > What happens if a box running the BoxBackup client gets broken into? > What if that person has bad intentions, or worse, is filled with > intentions > of the purest evil, decides to use the BoxBackup client to log in the > server and destroy your backup? > > Is it possible to somehow delete all backupped files using the client? No. > If so, it is quite frightening. I'm not saying that I'm expecting my > servers to be compromised, but you can never be 100% safe. Maybe there > should be an additionnal protection when it comes to deleting files. > For > example, the server could refuse deleting any files unless the client > supplies a specific passphrase. The client cannot actually delete any files from the server, it can merely mark them as deleted. In the worst case scenario, the malicious attacker marks all you files deleted. But since you're not over the storage limit on the server, the server will not actually delete any of them. If it does, it will only delete a few of the oldest versions. The restore utility has an option to recursively restore deleted directories and files. You might get files *you* deleted restored in error, but you won't have lost anything. > And also is it possible to lock the > backup key, like putting a passphrase on it? Of course the passphrase > has to be entered before using the key, which means when bbackupd or > bbackupquery is started. There's not much point in doing this. It would add little to the security of the system, and provide a false sense of security. Seeing as the key and the data on the computer you've just broken into are effectively equivalent, there is no reason to protect the key. An attacker would just read the decrypted data. Of course, there is the problem that if they broke in to your computer and stole the keys, they could then use the backup server to get copies of your files whenever they wanted. But this could be solved by changing the certificate -- and you would notice the break-in, wouldn't you? Security is about reacting, as well as preventing. > > And I was also thinking about some maintenance functions. After a > while, > the server may be filled with a lot of old data. Maybe there should be > a > utility which removes all data that is X days or older, unless there is > only one version of the file, of course. This is yet another > suggestion, > which I don't have a need for right now, but it could be handy someday. > Consider a big user base which works with big data files that are > updated > often, maybe within a few months the data on the server would grow too > big. This is already implemented. There are two bbstored processes, one accepts connections from clients, the second is a housekeeping process which does exactly what you describe. It's aim is to keep the size of the store just below the soft limit by removing old files. There's an order of priority of deletion which aims to ensure that you delete the least useful data first. > > Aside from that, I haven't played a lot with BoxBackup yet. But here > are > the good points I noticed: > > - The server hasn't crashed. It runs on OpenBSD 3.3. It doesn't seem to > be leaking, having run for a few days. (Although the data backed up > it > pretty small, it may not be significant). From ps aux: > _bbstored 2040 0.0 0.5 1340 1328 ?? S Wed06PM 0:00.74 > bbstored: server (bbstored) > _bbstored 28541 0.0 1.0 2980 2624 ?? S Wed06PM 0:13.02 > bbstored: housekeeping, idle (bbstored) Looks about right. The housekeeping process shouldn't increase in size much. > > - Same for the client. It hasn't crashed: > root 14512 0.0 0.8 1016 2164 ?? I Thu01AM 0:10.28 > bbackupd: idle (bbackupd) Good -- it should stay at about that level of memory usage. > > - It was a little tricky to install, but I suspect the next version > will > fix a lot of that. Once it is installed though, you can forget about > it and it just runs, silently. Yes, I'm learning a lot about installation from the discussions on this list! > > - I like the way files are restored, although a little search command > could be useful someday. I agree, and am planning to do something far more useful than the primitive bbackupquery -- which is really intended for sysadmin use only. I will be writing "brestored" which will accept connections from users, and allow them to get old versions, restore (only) their files, that sort of thing. > > - I'm really considering running it on every machine I own. I'm just > waiting to get more disk space. Thanks! > > - Especially useful with a laptop! You can leave it running on the laptop, regardless of whether it's connected or not. If it fails to connect, it'll try again every 100 seconds until it succeeds. > > I don't backup a lot of data yet, so I can't really say more than that > for now, and maybe with more data other problems will arise. If you could verify the backup occasionally, that would be very useful. > > Oh, and I noticed a typo in bbackupquery: > Unrecognised command -> Unrecognized command > 'z', not 's'. Er, that's not a spelling mistake. My locale is en-UK. :-) Thanks for using it and reporting back! Feedback from users is essential for completing this project successfully. Ben From boxbackup at fluffy.co.uk Sun Feb 1 23:23:23 2004 From: boxbackup at fluffy.co.uk (Alaric B Snell) Date: Sun, 01 Feb 2004 23:23:23 +0000 Subject: [Box Backup] Danger of files being erased In-Reply-To: <6B6177A0-5503-11D8-B39D-003065F8EC8E@fluffy.co.uk> References: <20040201181657.GA19903@plasma.doom.und> <6B6177A0-5503-11D8-B39D-003065F8EC8E@fluffy.co.uk> Message-ID: <401D8A6B.1050400@alaric-snell.com> Ben Summers wrote: >> And also is it possible to lock the >> backup key, like putting a passphrase on it? Of course the passphrase >> has to be entered before using the key, which means when bbackupd or >> bbackupquery is started. > > There's not much point in doing this. It would add little to the > security of the system, and provide a false sense of security. Seeing as > the key and the data on the computer you've just broken into are > effectively equivalent, there is no reason to protect the key. An > attacker would just read the decrypted data. > > Of course, there is the problem that if they broke in to your computer > and stole the keys, they could then use the backup server to get copies > of your files whenever they wanted. But this could be solved by changing > the certificate -- and you would notice the break-in, wouldn't you? > > Security is about reacting, as well as preventing. Is there a danger they could compromise system data, and then upload the new compromised versions to the backups? Worse than setting the deleted flag :-) What's done about multiple historic versions of files in the backups? Interestingly, the clever upload-only-changes thing could well be used to help clear up after an exploit - reboot from a clean OS to get past the rootkit, then ask the bbackupquery tool to list which files were modified since the last backup run, and then hand-vet the changes... >> - I'm really considering running it on every machine I own. I'm just >> waiting to get more disk space. > > Thanks! > Personally, I'm limited by bandwidth between my machines, which are all at different ISPs (with bandwidth charges) or on ADSL - which is why my trusty tape drives are still whirring away for now; I can use sneakernet for my high bandwidth backup transfers ;-) I'm wondering about performing gross trickery and taking a laptop into each rack in turn, running the server, to do the initial upload-everything onto, then transferring the server install to a real server machine to then handle subsequent incrementals... > > Ben > ABS From boxbackup at fluffy.co.uk Mon Feb 2 10:03:18 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Mon, 2 Feb 2004 10:03:18 +0000 Subject: [Box Backup] Danger of files being erased In-Reply-To: <401D8A6B.1050400@alaric-snell.com> References: <20040201181657.GA19903@plasma.doom.und> <6B6177A0-5503-11D8-B39D-003065F8EC8E@fluffy.co.uk> <401D8A6B.1050400@alaric-snell.com> Message-ID: <067C5E9B-5567-11D8-9CCC-003065F8EC8E@fluffy.co.uk> On 1 Feb 2004, at 23:23, Alaric B Snell wrote: > Ben Summers wrote: >>> And also is it possible to lock the >>> backup key, like putting a passphrase on it? Of course the passphrase >>> has to be entered before using the key, which means when bbackupd or >>> bbackupquery is started. >> There's not much point in doing this. It would add little to the >> security of the system, and provide a false sense of security. Seeing >> as the key and the data on the computer you've just broken into are >> effectively equivalent, there is no reason to protect the key. An >> attacker would just read the decrypted data. >> Of course, there is the problem that if they broke in to your >> computer and stole the keys, they could then use the backup server to >> get copies of your files whenever they wanted. But this could be >> solved by changing the certificate -- and you would notice the >> break-in, wouldn't you? >> Security is about reacting, as well as preventing. > > Is there a danger they could compromise system data, and then upload > the new compromised versions to the backups? Yes. > Worse than setting the deleted flag :-) The current security model assumes that access to the client machine and it's data is equivalent to access to the backups -- which I feel is reasonable since an attacker can just read the unencrypted files. However, future versions will have a system of "marking" snapshots, so you'll easily be able to go back in time before the compromise. There's roughly the same problem with any other backup system -- if you don't notice and rotate so the good data is deleted, you've lost the backup. > What's done about multiple historic versions of files in the backups? They are all available, if in a slightly non-user friendly way. http://www.fluffy.co.uk/boxbackup/retrieve.html Although I will make this better in the future. > > Interestingly, the clever upload-only-changes thing could well be used > to help clear up after an exploit - reboot from a clean OS to get past > the rootkit, then ask the bbackupquery tool to list which files were > modified since the last backup run, and then hand-vet the changes... Interesting... :-) > >>> - I'm really considering running it on every machine I own. I'm just >>> waiting to get more disk space. >> Thanks! > > Personally, I'm limited by bandwidth between my machines, which are > all at different ISPs (with bandwidth charges) or on ADSL - which is > why my trusty tape drives are still whirring away for now; I can use > sneakernet for my high bandwidth backup transfers ;-) > > I'm wondering about performing gross trickery and taking a laptop into > each rack in turn, running the server, to do the initial > upload-everything onto, then transferring the server install to a real > server machine to then handle subsequent incrementals... Yes, that would work. Ben From boxbackup at fluffy.co.uk Mon Feb 2 10:17:41 2004 From: boxbackup at fluffy.co.uk (Alaric B Snell) Date: Mon, 02 Feb 2004 10:17:41 +0000 Subject: [Box Backup] Danger of files being erased In-Reply-To: <067C5E9B-5567-11D8-9CCC-003065F8EC8E@fluffy.co.uk> References: <20040201181657.GA19903@plasma.doom.und> <6B6177A0-5503-11D8-B39D-003065F8EC8E@fluffy.co.uk> <401D8A6B.1050400@alaric-snell.com> <067C5E9B-5567-11D8-9CCC-003065F8EC8E@fluffy.co.uk> Message-ID: <401E23C5.7080609@alaric-snell.com> Ben Summers wrote: > The current security model assumes that access to the client machine and > it's data is equivalent to access to the backups -- which I feel is > reasonable since an attacker can just read the unencrypted files. > However, future versions will have a system of "marking" snapshots, so > you'll easily be able to go back in time before the compromise. > > There's roughly the same problem with any other backup system -- if you > don't notice and rotate so the good data is deleted, you've lost the > backup. Yep. You can only undo changes within a finite timeframe, and the length of that timeframe (in the case of incremental backups) may depend on the rate of change of data, meaning an attacker may even deliberately shorten it by having his rootkit create and frequently update a 1GB file somewhere :-) I presume the bbstored protocol doesn't allow any other way of getting rid of a backed up file than uploading changes to that file as fast as you can until the good version is expired, right? If so, then all you need is a reasonable upload bandwidth limitation and an easy way of getting old versions by date and/or getting "diffs" of the live system to see what's changed, and it could be a valuable un-rootkitting tool too! > > Interesting... :-) > Let's discuss this tomorrow! > > Ben > ABS From boxbackup at fluffy.co.uk Mon Feb 2 10:36:10 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Mon, 2 Feb 2004 10:36:10 +0000 Subject: [Box Backup] Danger of files being erased In-Reply-To: <401E23C5.7080609@alaric-snell.com> References: <20040201181657.GA19903@plasma.doom.und> <6B6177A0-5503-11D8-B39D-003065F8EC8E@fluffy.co.uk> <401D8A6B.1050400@alaric-snell.com> <067C5E9B-5567-11D8-9CCC-003065F8EC8E@fluffy.co.uk> <401E23C5.7080609@alaric-snell.com> Message-ID: <9E1A04B6-556B-11D8-9CCC-003065F8EC8E@fluffy.co.uk> On 2 Feb 2004, at 10:17, Alaric B Snell wrote: > Ben Summers wrote: > >> The current security model assumes that access to the client machine >> and it's data is equivalent to access to the backups -- which I feel >> is reasonable since an attacker can just read the unencrypted files. >> However, future versions will have a system of "marking" snapshots, >> so you'll easily be able to go back in time before the compromise. >> There's roughly the same problem with any other backup system -- if >> you don't notice and rotate so the good data is deleted, you've lost >> the backup. > > Yep. You can only undo changes within a finite timeframe, and the > length of that timeframe (in the case of incremental backups) may > depend on the rate of change of data, meaning an attacker may even > deliberately shorten it by having his rootkit create and frequently > update a 1GB file somewhere :-) > > I presume the bbstored protocol doesn't allow any other way of getting > rid of a backed up file than uploading changes to that file as fast as > you can until the good version is expired, right? Correct. Although because the server is implemented within my "as simple as possible (but no simpler)" philosophy -- easy to write, less bugs, etc -- you could simply modify this 1Gb file by adding a byte, and it would use an extra 1Gb on the server. > If so, then all you need is a reasonable upload bandwidth limitation > and an easy way of getting old versions by date and/or getting "diffs" > of the live system to see what's changed, and it could be a valuable > un-rootkitting tool too! I think it could be as simple as having a paranoid mode where 1) When you successfully connect to the server, you're then prohibited from logging on again for a defined interval 2) Only allowing a file to be updated once per session. Releasing this system has been very interesting -- new uses have been proposed, and new ways of working have been suggested which make it useful even in scenarios I hadn't anticipated it being able to be used. I'm keeping notes! Ben From boxbackup at fluffy.co.uk Mon Feb 2 18:44:52 2004 From: boxbackup at fluffy.co.uk (Eduardo Alvarenga) Date: Mon, 2 Feb 2004 15:44:52 -0300 (BRT) Subject: [Box Backup] in server child, exception Server (3/45) Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm getting this error in every backup sync: -- Feb 2 15:30:36 cvs bbstored[29498]: Incoming connection from 172.16.0.4 p= ort 17822 (handling in child 10272) Feb 2 15:30:37 cvs bbstored[10272]: Certificate CN: BACKUP-0000007=20 Feb 2 15:30:37 cvs bbstored[10272]: Login: Client ID 00000007, Read/Write Feb 2 15:30:37 cvs bbstored[10272]: Session finished Feb 2 15:31:39 cvs bbstored[29910]: in server child, exception Server (3/= 45) -- terminating child Feb 2 15:32:08 cvs bbstored/hk[23051]: Starting housekeeping Feb 2 15:32:08 cvs bbstored/hk[23051]: Finished housekeeping Feb 2 15:32:40 cvs bbstored[29498]: Incoming connection from 172.16.0.8 p= ort 2423 (handling in child 188) Feb 2 15:32:40 cvs bbstored[188]: Certificate CN: BACKUP-0000009=20 Feb 2 15:32:40 cvs bbstored[188]: Login: Client ID 00000009, Read/Write Feb 2 15:33:19 cvs bbstored[188]: in server child, exception Server (3/45= ) -- terminating child -- It happens with EVERY machine I have. Apparently the backups are ok,=20 but I very doubt this is a normal behavior. Best Regards, --=20 Eduardo A. Alvarenga=20 Analista de Suporte Centro Estrat=E9gico Integrado / SEGUP-PA (91) 259-0555 / 8116-0036 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (OpenBSD) iD8DBQFAHpqmpKK2uJoGDlMRAgFPAKC5/RI35gjHhVKxXSghP6rIpz1vaQCePwLz epEIY3YTrq6UAXMtfo4ktu0=3D =3DpAqP -----END PGP SIGNATURE----- From boxbackup at fluffy.co.uk Mon Feb 2 19:01:08 2004 From: boxbackup at fluffy.co.uk (Eduardo Alvarenga) Date: Mon, 2 Feb 2004 16:01:08 -0300 (BRT) Subject: [Box Backup] How to include a single file? In-Reply-To: References: <2D50070E-5436-11D8-A3E0-003065F8EC8E@fluffy.co.uk> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 1 Feb 2004, Ben Summers wrote: > > Sure. I want to backup some files without touching them. I have > > some directories which I want only some files to be backuped (temp=20 > > files come to mind). Regex will be welcome too. >=20 > You have a version which does Regex excludes. I don't mean Regex EXCLUDES. I mean Regex INCLUDES. > > If you mind, please change "Path =3D" to something like "Include =3D" > > beeing it a directory or not. > > > Actually, I spoke too soon. It is possible to do exactly what you want > by use of regular expressions -- set the path to be the containing > directory and exclude all the things you don't want to back up. This is not quite a nice solution. I personally (and I thing anyone=20 else) prefers to just tell bbackupd to backup a single file instead of=20 telling it to backup the result of an expensive and obviously not=20 necessary regex calculation. This behavior is not user friendly. Please take my idea, It'll be much=20 more welcome. > root-for-bsd > { > =09Path =3D / > =09ExcludeDirsRegex =3D . > =09ExcludeFilesRegex =3D ^[^b][^s][^d] > Of course, this is a little clumsy (and this example won't actually=20 > work in the general case, just in the case of a normal root directory),= =20 > and would be easier if I added way of saying "not" a regular=20 > expression. THIS is what I mean. Imagine a file with a name such as=20 "this_is_my_litte_script_with_a_large_name". This will be too expensive and slow. And totally ridiculous to configure. I DO REALLY prefer: "Path =3D /bsd", "Path =3D /usr/local/script/foo*" instead of 3 lines of= =20 regex for EACH file. Put yourself on my shoes. --=20 Eduardo A. Alvarenga=20 Analista de Suporte Centro Estrat=E9gico Integrado / SEGUP-PA (91) 259-0555 / 8116-0036 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (OpenBSD) iD8DBQFAHp52pKK2uJoGDlMRAvlTAKCL8wSDkURr6fhIO6NV3tJu8FFoWgCgiZ99 DfLK1O+36t4kLIL3HvrE/kU=3D =3DRtso -----END PGP SIGNATURE----- From boxbackup at fluffy.co.uk Mon Feb 2 19:07:04 2004 From: boxbackup at fluffy.co.uk (Eduardo Alvarenga) Date: Mon, 2 Feb 2004 16:07:04 -0300 (BRT) Subject: [Box Backup] Success stories? In-Reply-To: <3C0AC921-5499-11D8-A6FD-003065F8EC8E@fluffy.co.uk> References: <3C0AC921-5499-11D8-A6FD-003065F8EC8E@fluffy.co.uk> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 1 Feb 2004, Ben Summers wrote: > I've heard about quite a few problems people have been having with Box > Backup, but no reports of success. >=20 > Has anyone got it running successfully? How's it working out? I've implemented boxbackup on 12 servers here. It is working OK until now. Some minor issues about installation have been encountered but all=20 fixed. The performance is fine, considering the data is crypted, the speed is=20 awesome. I'm using 100Mbits LAN for the backup process, but I'm planning to=20 expand the usage of the system to intestate-wide (WAN) servers as soon=20 as boxbackup gets more mature and stable with more features and=20 documentation. I'm not the unique system administrator in my company,=20 so I can't risk now. Congratulation Ben, you're making a nice software ;-) Best Regards, --=20 Eduardo A. Alvarenga=20 Analista de Suporte Centro Estrat=E9gico Integrado / SEGUP-PA (91) 259-0555 / 8116-0036 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (OpenBSD) iD8DBQFAHp/cpKK2uJoGDlMRAlHwAJ9C4WIW3wLYdbyI2dabWU+Jw6kD1gCdGC4V VKHUnGvtwLImOGLVvm0r4z8=3D =3DM8yl -----END PGP SIGNATURE----- From boxbackup at fluffy.co.uk Mon Feb 2 19:14:36 2004 From: boxbackup at fluffy.co.uk (Eduardo Alvarenga) Date: Mon, 2 Feb 2004 16:14:36 -0300 (BRT) Subject: [Box Backup] Danger of files being erased In-Reply-To: <9E1A04B6-556B-11D8-9CCC-003065F8EC8E@fluffy.co.uk> References: <20040201181657.GA19903@plasma.doom.und> <6B6177A0-5503-11D8-B39D-003065F8EC8E@fluffy.co.uk> <401D8A6B.1050400@alaric-snell.com> <067C5E9B-5567-11D8-9CCC-003065F8EC8E@fluffy.co.uk> <401E23C5.7080609@alaric-snell.com> <9E1A04B6-556B-11D8-9CCC-003065F8EC8E@fluffy.co.uk> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 2 Feb 2004, Ben Summers wrote: > > If so, then all you need is a reasonable upload bandwidth > > limitation and an easy way of getting old versions by date and/or > > getting "diffs" of the live system to see what's changed, and it > > could be a valuable un-rootkitting tool too! >=20 > I think it could be as simple as having a paranoid mode where >=20 > 1) When you successfully connect to the server, you're then prohibited=20 > from logging on again for a defined interval This connection means Read/Write or anything? I think Read/Write=20 must be prohibited, but Read-Only no. =20 > 2) Only allowing a file to be updated once per session. You have to thing about performance, creating 2 sockets for each file=20 will be to overkilling. =20 Best Regards, --=20 Eduardo A. Alvarenga=20 Analista de Suporte Centro Estrat=E9gico Integrado / SEGUP-PA (91) 259-0555 / 8116-0036 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (OpenBSD) iD8DBQFAHqGepKK2uJoGDlMRAgEoAJ90JBwAy8wmXMmWsvCc+BPAwbOPuwCghnRO StoInHjScCn1bNAOzT9T+4M=3D =3DBvRs -----END PGP SIGNATURE----- From boxbackup at fluffy.co.uk Mon Feb 2 20:01:12 2004 From: boxbackup at fluffy.co.uk (Juan Vera) Date: Mon, 02 Feb 2004 17:01:12 -0300 Subject: [Box Backup] even more feature requests Message-ID: <401EAC88.50007@coresecurity.com> hello let me start by making clear that I didn't install BoxBackup yet, so maybe I'll have more requests later; also excuse my english :) this was sent to Ben privatelly and he asked me to post in the mailing list: Yes, that is exactly what I need: a server on internal network fetching backups from other internal and some external servers. The reason is mainly firewalling, but I do also backup remote servers that have no way to get into the internal network (and should stay in that way :). Plus I like the idea of a "closed to everyone" backup server more than the "public area to backup", no matter that it is still possible talk to that server when it connects to each box. And now another question comes to my mind. What about off site backups? Can I burn Box Backup's repositories to dvd and restore then latter? I have on-line backups now but I still need to have the posibility to have them offsite, in case of fire, earth quakes, etc, you know. Other than that, Box Backup does exactly what I'm doing now manually using an ssh/tar/gpg/scripts mix that I'd really would like to replace. Thanks Juan From boxbackup at fluffy.co.uk Mon Feb 2 20:56:30 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Mon, 2 Feb 2004 20:56:30 +0000 Subject: [Box Backup] in server child, exception Server (3/45) In-Reply-To: References: Message-ID: <46F43CFE-55C2-11D8-86F7-003065F8EC8E@fluffy.co.uk> On 2 Feb 2004, at 18:44, Eduardo Alvarenga wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I'm getting this error in every backup sync: > > -- > Feb 2 15:30:36 cvs bbstored[29498]: Incoming connection from > 172.16.0.4 port 17822 (handling in child 10272) > Feb 2 15:30:37 cvs bbstored[10272]: Certificate CN: BACKUP-0000007 > Feb 2 15:30:37 cvs bbstored[10272]: Login: Client ID 00000007, > Read/Write > Feb 2 15:30:37 cvs bbstored[10272]: Session finished > Feb 2 15:31:39 cvs bbstored[29910]: in server child, exception > Server (3/45) -- terminating child > Feb 2 15:32:08 cvs bbstored/hk[23051]: Starting housekeeping > Feb 2 15:32:08 cvs bbstored/hk[23051]: Finished housekeeping > Feb 2 15:32:40 cvs bbstored[29498]: Incoming connection from > 172.16.0.8 port 2423 (handling in child 188) > Feb 2 15:32:40 cvs bbstored[188]: Certificate CN: BACKUP-0000009 > Feb 2 15:32:40 cvs bbstored[188]: Login: Client ID 00000009, > Read/Write > Feb 2 15:33:19 cvs bbstored[188]: in server child, exception Server > (3/45) -- terminating child > -- > > It happens with EVERY machine I have. Apparently the backups are ok, > but I very doubt this is a normal behavior. I wouldn't expect to see this particular error at all. Could you turn on extended logging, and see what happens just before this error? (see the config files, uncomment the ExtendedLogging line) Thanks, Ben From boxbackup at fluffy.co.uk Mon Feb 2 21:05:50 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Mon, 2 Feb 2004 21:05:50 +0000 Subject: [Box Backup] Danger of files being erased In-Reply-To: References: <20040201181657.GA19903@plasma.doom.und> <6B6177A0-5503-11D8-B39D-003065F8EC8E@fluffy.co.uk> <401D8A6B.1050400@alaric-snell.com> <067C5E9B-5567-11D8-9CCC-003065F8EC8E@fluffy.co.uk> <401E23C5.7080609@alaric-snell.com> <9E1A04B6-556B-11D8-9CCC-003065F8EC8E@fluffy.co.uk> Message-ID: <946FD658-55C3-11D8-86F7-003065F8EC8E@fluffy.co.uk> On 2 Feb 2004, at 19:14, Eduardo Alvarenga wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mon, 2 Feb 2004, Ben Summers wrote: > >>> If so, then all you need is a reasonable upload bandwidth >>> limitation and an easy way of getting old versions by date and/or >>> getting "diffs" of the live system to see what's changed, and it >>> could be a valuable un-rootkitting tool too! >> >> I think it could be as simple as having a paranoid mode where >> >> 1) When you successfully connect to the server, you're then prohibited >> from logging on again for a defined interval > > This connection means Read/Write or anything? I think Read/Write > must be prohibited, but Read-Only no. Yes, read only would be fine. > >> 2) Only allowing a file to be updated once per session. > > You have to thing about performance, creating 2 sockets for each file > will be to overkilling. Why would it create two sockets for each file? All that would be necessary was a record of which files were touched during the session, and only allow that to happen once. Alternatively, only allow updates of files whose last modification time is greater than a set time interval. This wouldn't even need any state to be kept, as the data already exists in the store. Ben From boxbackup at fluffy.co.uk Mon Feb 2 21:09:51 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Mon, 2 Feb 2004 21:09:51 +0000 Subject: [Box Backup] How to include a single file? In-Reply-To: References: <2D50070E-5436-11D8-A3E0-003065F8EC8E@fluffy.co.uk> Message-ID: <23FF6C12-55C4-11D8-86F7-003065F8EC8E@fluffy.co.uk> On 2 Feb 2004, at 19:01, Eduardo Alvarenga wrote: > > >>> If you mind, please change "Path =" to something like "Include =" >>> beeing it a directory or not. >>> >> Actually, I spoke too soon. It is possible to do exactly what you want >> by use of regular expressions -- set the path to be the containing >> directory and exclude all the things you don't want to back up. > > This is not quite a nice solution. I personally (and I thing anyone > else) prefers to just tell bbackupd to backup a single file instead of > telling it to backup the result of an expensive and obviously not > necessary regex calculation. > > This behavior is not user friendly. Please take my idea, It'll be much > more welcome. I've added it to the list. Shouldn't be very much extra work. However, you'll have to specify a location as a directory, as you do now, and then just explicitly say what you want from it. That fits in with the current design a lot better than allowing files to be specified as locations. Ben From boxbackup at fluffy.co.uk Mon Feb 2 21:23:29 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Mon, 2 Feb 2004 21:23:29 +0000 Subject: [Box Backup] even more feature requests In-Reply-To: <401EAC88.50007@coresecurity.com> References: <401EAC88.50007@coresecurity.com> Message-ID: <0B7179D5-55C6-11D8-86F7-003065F8EC8E@fluffy.co.uk> On 2 Feb 2004, at 20:01, Juan Vera wrote: > hello > > let me start by making clear that I didn't install > BoxBackup yet, so maybe I'll have more requests later; > also excuse my english :) > > this was sent to Ben privatelly and he asked me to > post in the mailing list: > > To fill in a possible gap in the narrative, Juan asked if the servers could be used in "pull" mode, where the backup server connects to the backup clients, rather than the more conventional way around. > > Yes, that is exactly what I need: a server on internal network > fetching backups from other internal and some external servers. > > The reason is mainly firewalling, but I do also backup remote > servers that have no way to get into the internal network (and > should stay in that way :). Plus I like the idea of a "closed to > everyone" backup server more than the "public area to backup", > no matter that it is still possible talk to that server when it > connects to each box. I hadn't ever really considered this, as I'd always anticipated the backup servers being "publicly accessible" as there's nothing of value to an attacker stored on it. Denial of service attacks are possible, though. However, this would be a nice addition, and something which isn't too difficult to do. It's just really reversing the connection direction, then everything happens as it does now. Both ends are authenticated anyway. I have added it to my ever growing list of things to do! > > And now another question comes to my mind. What about off site > backups? Can I burn Box Backup's repositories to dvd and restore > then latter? I have on-line backups now but I still need to have > the posibility to have them offsite, in case of fire, earth quakes, > etc, you know. Yes, simply archive the contents of the "backup" directories under the raid file directories. You should only need to archive two of them, and the raid system will recover the data properly from that, or archive each to a separate DVD for redundancy. > > Other than that, Box Backup does exactly what I'm doing now > manually using an ssh/tar/gpg/scripts mix that I'd really > would like to replace. Let me know what happens if you try it! Ben From boxbackup at fluffy.co.uk Mon Feb 2 22:47:43 2004 From: boxbackup at fluffy.co.uk (Eduardo Alvarenga) Date: Mon, 2 Feb 2004 19:47:43 -0300 (BRT) Subject: [Box Backup] in server child, exception Server (3/45) In-Reply-To: <46F43CFE-55C2-11D8-86F7-003065F8EC8E@fluffy.co.uk> References: <46F43CFE-55C2-11D8-86F7-003065F8EC8E@fluffy.co.uk> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 2 Feb 2004, Ben Summers wrote: > > Feb 2 15:33:19 cvs bbstored[188]: in server child, exception Server > > (3/45) -- terminating child > > -- > > > > It happens with EVERY machine I have. Apparently the backups are ok, > > but I very doubt this is a normal behavior. >=20 > I wouldn't expect to see this particular error at all. Could you turn=20 > on extended logging, and see what happens just before this error? Here it is: Feb 2 19:45:20 cvs bbstored[13898]: Receive ListDirectory(0x6b6,0xfffffff= f,0xc,true) Feb 2 19:45:20 cvs bbstored[13898]: Send Success(0x6b6) Feb 2 19:45:20 cvs bbstored[13898]: Sending stream, size 1457 Feb 2 19:45:20 cvs bbstored[13898]: Receive ListDirectory(0x6cb,0xfffffff= f,0xc,true) Feb 2 19:45:20 cvs bbstored[13898]: Send Success(0x6cb) Feb 2 19:45:20 cvs bbstored[13898]: Sending stream, size 985 Feb 2 19:45:21 cvs bbstored[13898]: Receive StoreFile(0x6cb,0x3ce26838f99= b0,0x3ce26838f99b0,0x0,OPAQUE) Feb 2 19:45:21 cvs bbstored[13898]: Receiving stream, size uncertain Feb 2 19:45:27 cvs bbstored[13898]: Send Error(0x3e8,0x6) Feb 2 19:45:27 cvs bbstored[13898]: in server child, exception Server (3/= 45) -- terminating child I suspect in the "size uncertain" message. I have very huge files here +500MB. Any issues? Best Regards, --=20 Eduardo A. Alvarenga=20 Analista de Suporte Centro Estrat=E9gico Integrado / SEGUP-PA (91) 259-0555 / 8116-0036 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (OpenBSD) iD8DBQFAHtORpKK2uJoGDlMRAvnHAKCMJ3zkuWdkUnCcdCO0jeM5hUbJzgCgoWYS X8TwVV/YNqeC9F2WViMi4cg=3D =3DlB4n -----END PGP SIGNATURE----- From boxbackup at fluffy.co.uk Tue Feb 3 08:48:13 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Tue, 3 Feb 2004 08:48:13 +0000 Subject: [Box Backup] in server child, exception Server (3/45) In-Reply-To: References: <46F43CFE-55C2-11D8-86F7-003065F8EC8E@fluffy.co.uk> Message-ID: On 2 Feb 2004, at 22:47, Eduardo Alvarenga wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mon, 2 Feb 2004, Ben Summers wrote: > >>> Feb 2 15:33:19 cvs bbstored[188]: in server child, exception Server >>> (3/45) -- terminating child >>> -- >>> >>> It happens with EVERY machine I have. Apparently the backups are ok, >>> but I very doubt this is a normal behavior. >> >> I wouldn't expect to see this particular error at all. Could you turn >> on extended logging, and see what happens just before this error? > > Here it is: > > Feb 2 19:45:20 cvs bbstored[13898]: Receive > ListDirectory(0x6b6,0xffffffff,0xc,true) > Feb 2 19:45:20 cvs bbstored[13898]: Send Success(0x6b6) > Feb 2 19:45:20 cvs bbstored[13898]: Sending stream, size 1457 > Feb 2 19:45:20 cvs bbstored[13898]: Receive > ListDirectory(0x6cb,0xffffffff,0xc,true) > Feb 2 19:45:20 cvs bbstored[13898]: Send Success(0x6cb) > Feb 2 19:45:20 cvs bbstored[13898]: Sending stream, size 985 > Feb 2 19:45:21 cvs bbstored[13898]: Receive > StoreFile(0x6cb,0x3ce26838f99b0,0x3ce26838f99b0,0x0,OPAQUE) > Feb 2 19:45:21 cvs bbstored[13898]: Receiving stream, size uncertain > Feb 2 19:45:27 cvs bbstored[13898]: Send Error(0x3e8,0x6) > Feb 2 19:45:27 cvs bbstored[13898]: in server child, exception > Server (3/45) -- terminating child > > > I suspect in the "size uncertain" message. This is nothing to worry about, it simply means that the size of the data the client is sending isn't known when it starts. (This is because it compresses the data as it sends it.) > I have very huge files here +500MB. Any issues? Possibly. I'll try out some large files. But in the meantime, could you 1) Enable ExtendedLogging on the clients. You should then see what file they're failing on, as the client will show the actual filename instead of "OPAQUE" -- the server can't tell what the filenames are. 2) Verify a store, and see if it's missing anything. Thanks, Ben From boxbackup at fluffy.co.uk Thu Feb 5 09:16:11 2004 From: boxbackup at fluffy.co.uk (Juan Vera) Date: Thu, 5 Feb 2004 09:16:11 +0000 Subject: [Box Backup] interactive bbackupquery Message-ID: <20040205091611.GA22291@corest.com> I finally instaled Box Backup on a couple of boxes. Builing was fine and installation of clients was easy. Parcels were nice on machines w/o compiler and bbackupd-config was pretty simple. On one machine I ran it with args server-hostname working-dir in the inverse order, I didn't notice it until the signed cert&rootCA were installed on the client, and nameserver logs showed queries for a path.mydomain :) Exceptions are ugly, yes; but luckily enabling extended logging was enougth to solve the problems I had. As a cosmetic note, note upper vs lower 'e': Feb 5 04:42:44 furia bbackupd[4492]: Exception caught (3/47), reset state and waiting to retry... Feb 5 04:47:06 furia bbackupd[28683]: exception Server (3/25) -- terminating What I didn't like was the unfriendly interactive bbackupquery: # /usr/local/bin/bbackupquery Box Backup Query Tool v0.03, (c) Ben Summers 2003, 2004 * Commercial service provision using this software prohibited, see license. Using configuration file /etc/box/bbackupd.conf Connecting to store... Handshake with store... Login to store... Login complete. query > ? Unrecognised command: ? query > ls Unrecognised command: ls query > help Unrecognised command: help query > quit Logging off... Session finished. # got me back to web page :( there I saw that the command is 'list'. Would you add 'ls' as an alias for 'list'? Anyway, readline is nice, and restoring files was really simple. New questions: Why It is not recommended that you backup the {etc,root} directory of your disc? Is it a technical restriction or just a warning until the beta stage is done? How can I force bbackupd to upload changes whenever I want? Tried with kill -1 but it ignored some files, I think because of the BackupInterval and/or MaxUploadWait. Are you considering to implement server to client connections? In case you are -and I hope you do- maybe it would be even better to be able to handle both ways in the same server simultaneaously: some machines connecting to the server and the server connecting to some other. While I don't have that need, I think it gives some more flexibility to the software. Resuming: I like Box Backup more now that I tried it than while it was just docs influence. I think it will be a new parter :) From boxbackup at fluffy.co.uk Thu Feb 5 22:27:23 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Thu, 5 Feb 2004 22:27:23 +0000 Subject: [Box Backup] interactive bbackupquery In-Reply-To: <20040205091611.GA22291@corest.com> References: <20040205091611.GA22291@corest.com> Message-ID: <78250D4E-582A-11D8-90B1-003065F8EC8E@fluffy.co.uk> On 5 Feb 2004, at 09:16, Juan Vera wrote: > > I finally instaled Box Backup on a couple of boxes. > Builing was fine and installation of clients was easy. > Parcels were nice on machines w/o compiler and > bbackupd-config was pretty simple. I'm glad you found it OK... > On one machine > I ran it with args server-hostname working-dir in > the inverse order, I didn't notice it until > the signed cert&rootCA were installed on the client, > and nameserver logs showed queries for a path.mydomain > :) I'll modify the script to validate these. > > Exceptions are ugly, yes; but luckily enabling extended > logging was enougth to solve the problems I had. > > As a cosmetic note, note upper vs lower 'e': > > Feb 5 04:42:44 furia bbackupd[4492]: Exception caught (3/47), reset > state and waiting to retry... > Feb 5 04:47:06 furia bbackupd[28683]: exception Server (3/25) -- > terminating > > What I didn't like was the unfriendly interactive > bbackupquery: I am going to do a lot of work to improve this, and give better alternatives to using bbackupquery, which really is a sysadmin tool. > > # /usr/local/bin/bbackupquery > Box Backup Query Tool v0.03, (c) Ben Summers 2003, 2004 > * Commercial service provision using this software prohibited, see > license. > Using configuration file /etc/box/bbackupd.conf > Connecting to store... > Handshake with store... > Login to store... > Login complete. > query > ? > Unrecognised command: ? > query > ls > Unrecognised command: ls > query > help > Unrecognised command: help > query > quit > Logging off... > Session finished. > # > > got me back to web page :( there I saw that the > command is 'list'. Would you add 'ls' as an > alias for 'list'? Yes. It annoys me too! > Anyway, readline is nice, and > restoring files was really simple. > > New questions: Why It is not recommended that > you backup the {etc,root} directory of your disc? I want to avoid backing up the keys -- just to be very careful about things. And the root directory is likely to contain many mounted filesystems, and having a mount point within a backup location is a Bad Thing because it ruins file and directory tracking (to handle renames efficiently). > > Is it a technical restriction or just a warning > until the beta stage is done? /etc I will sort by putting in an exclude for the keys files, and the filesystems thing, bbackupd will refuse to run if you break this restriction. > > How can I force bbackupd to upload changes whenever > I want? Tried with kill -1 but it ignored some > files, I think because of the BackupInterval and/or > MaxUploadWait. Yes, I'm afraid you can't do this at the moment, but I'm planning to change things so that you can issue a command, and it will bring everything absolutely up to date. > > Are you considering to implement server to client > connections? Yes. > In case you are -and I hope you do- > maybe it would be even better to be able to handle both > ways in the same server simultaneaously: some machines > connecting to the server and the server connecting to > some other. While I don't have that need, I think it > gives some more flexibility to the software. If you're going to do something, you might as well do it properly. So yes, it'll do both -- it's really not that much more work. I can't promise when it'll be done, of course. > > Resuming: I like Box Backup more now that I tried it > than while it was just docs influence. I think it will > be a new parter :) I'm glad it's working out for you so far, I look forward to the longer term results! Thanks, Ben From boxbackup at fluffy.co.uk Thu Feb 5 22:51:20 2004 From: boxbackup at fluffy.co.uk (Juan Vera) Date: Thu, 05 Feb 2004 19:51:20 -0300 Subject: [Box Backup] interactive bbackupquery In-Reply-To: <78250D4E-582A-11D8-90B1-003065F8EC8E@fluffy.co.uk> References: <20040205091611.GA22291@corest.com> <78250D4E-582A-11D8-90B1-003065F8EC8E@fluffy.co.uk> Message-ID: <4022C8E8.9000100@coresecurity.com> Ben Summers wrote: >> What I didn't like was the unfriendly interactive >> bbackupquery: > > > I am going to do a lot of work to improve this, and give better > alternatives to using bbackupquery, which really is a sysadmin tool. no, I'm sorry. I was trying to be ironic, I just missed the help/usage banner and the 'ls' command, other than that, the whole operation with bbackupquery was pretty simple and friendly. >> New questions: Why It is not recommended that >> you backup the {etc,root} directory of your disc? > > > I want to avoid backing up the keys -- just to be very careful about > things. understandable, but, if I did the offsite copy of the keys, in the worst case I just would have to restore (download) the whole backup again, right? > > And the root directory is likely to contain many mounted filesystems, > and having a mount point within a backup location is a Bad Thing > because it ruins file and directory tracking (to handle renames > efficiently). I'm not sure I understand this. Suppose I have this mount points: /dev/wd0a on / type ffs (local, softdep) /dev/wd0d on /tmp type ffs (local, softdep) /dev/wd0e on /usr type ffs (local, softdep) /dev/wd0f on /var type ffs (local, softdep) is it wrong to backup /root and /var? or the problem would be if I have another directory mounted on /var/log? >> I want? Tried with kill -1 but it ignored some >> files, I think because of the BackupInterval and/or >> MaxUploadWait. > > How can I force bbackupd to upload changes whenever > > Yes, I'm afraid you can't do this at the moment, but I'm planning to > change things so that you can issue a command, and it will bring > everything absolutely up to date. ok, no big deal, I just went to sleep and everything is in place right now :) > >> >> Are you considering to implement server to client >> connections? > > > Yes. > >> In case you are -and I hope you do- >> maybe it would be even better to be able to handle both >> ways in the same server simultaneaously: some machines >> connecting to the server and the server connecting to >> some other. While I don't have that need, I think it >> gives some more flexibility to the software. > > > If you're going to do something, you might as well do it properly. So > yes, it'll do both -- it's really not that much more work. > super! > I can't promise when it'll be done, of course. :) Thanks From boxbackup at fluffy.co.uk Fri Feb 6 10:15:13 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Fri, 6 Feb 2004 10:15:13 +0000 Subject: [Box Backup] interactive bbackupquery In-Reply-To: <4022C8E8.9000100@coresecurity.com> References: <20040205091611.GA22291@corest.com> <78250D4E-582A-11D8-90B1-003065F8EC8E@fluffy.co.uk> <4022C8E8.9000100@coresecurity.com> Message-ID: <5A500486-588D-11D8-BF14-003065F8EC8E@fluffy.co.uk> On 5 Feb 2004, at 22:51, Juan Vera wrote: > Ben Summers wrote: > >>> What I didn't like was the unfriendly interactive >>> bbackupquery: >> >> >> I am going to do a lot of work to improve this, and give better >> alternatives to using bbackupquery, which really is a sysadmin tool. > > > no, I'm sorry. I was trying to be ironic, I just missed the > help/usage banner and the 'ls' command, other than that, > the whole operation with bbackupquery was pretty simple > and friendly. I will put in ls and help, though. > >>> New questions: Why It is not recommended that >>> you backup the {etc,root} directory of your disc? >> >> >> I want to avoid backing up the keys -- just to be very careful about >> things. > > understandable, but, if I did the offsite copy of the > keys, in the worst case I just would have to restore (download) > the whole backup again, right? Absolutely right. There is no point in backing up the encryption keys with Box Backup, because you can only restore if you have a copy of the keys. In addition, it would be bad cryptographic practice to store in an encrypted form a key, encrypted by itself. It would give an attacker too much of a chance to recover the key. > >> >> And the root directory is likely to contain many mounted filesystems, >> and having a mount point within a backup location is a Bad Thing >> because it ruins file and directory tracking (to handle renames >> efficiently). > > > I'm not sure I understand this. Suppose I have this mount points: > > /dev/wd0a on / type ffs (local, softdep) > /dev/wd0d on /tmp type ffs (local, softdep) > /dev/wd0e on /usr type ffs (local, softdep) > /dev/wd0f on /var type ffs (local, softdep) > > is it wrong to backup /root and /var? Not with that setup. > or the problem would > be if I have another directory mounted on /var/log? Yes, you should not backup /var if you have something mounted on /var/log . > >>> I want? Tried with kill -1 but it ignored some >>> files, I think because of the BackupInterval and/or >>> MaxUploadWait. >> >> How can I force bbackupd to upload changes whenever >> >> Yes, I'm afraid you can't do this at the moment, but I'm planning to >> change things so that you can issue a command, and it will bring >> everything absolutely up to date. > > ok, no big deal, I just went to sleep and everything is in > place right now :) It's a slightly different way of doing backups than other systems. Better for the situations I designed it for, but not others. So I'll be adding the ability to behave in a traditional manner too. I trust that you're doing a "verify" occasionally, and it checks out OK? Ben From boxbackup at fluffy.co.uk Tue Feb 10 06:50:25 2004 From: boxbackup at fluffy.co.uk (Pascal Lalonde) Date: Tue, 10 Feb 2004 01:50:25 -0500 Subject: [Box Backup] interactive bbackupquery In-Reply-To: <5A500486-588D-11D8-BF14-003065F8EC8E@fluffy.co.uk> References: <20040205091611.GA22291@corest.com> <78250D4E-582A-11D8-90B1-003065F8EC8E@fluffy.co.uk> <4022C8E8.9000100@coresecurity.com> <5A500486-588D-11D8-BF14-003065F8EC8E@fluffy.co.uk> Message-ID: <20040210065025.GA27429@plasma.doom.und> On Fri, Feb 06, 2004 at 10:15:13AM +0000, Ben Summers wrote: > > >> > >>And the root directory is likely to contain many mounted filesystems, > >>and having a mount point within a backup location is a Bad Thing > >>because it ruins file and directory tracking (to handle renames > >>efficiently). > > > > > >I'm not sure I understand this. Suppose I have this mount points: > > > >/dev/wd0a on / type ffs (local, softdep) > >/dev/wd0d on /tmp type ffs (local, softdep) > >/dev/wd0e on /usr type ffs (local, softdep) > >/dev/wd0f on /var type ffs (local, softdep) > > > >is it wrong to backup /root and /var? > > Not with that setup. > > > or the problem would > >be if I have another directory mounted on /var/log? > > Yes, you should not backup /var if you have something mounted on > /var/log . Maybe you should make the client not cross filesystems, like 'du -x' does, or 'dump'. Of course, this would be clearly indicated in the documentation, and users will expect this behavior. But having bbackupd give warnings each time could become annoying. Is that what you were planning? So far so good. 'compare -a' shows that everything is in order. I finally found a machine to use as a more permanent backup server. I'm just waiting to get a bigger hard drive and a little UPS. Soon we will start using it (me and some friends) for backupping our personnal stuff. This way I'll be able to see how it goes with a bigger volume (+/- 40gigs), with 5 different users, and a few linux clients also. Would the client run in Cygwin? And would it handle spaces in file and directory names? I talked to some friends, and they would really like to see this working on Win32, so maybe Cygwin could fill the gap while the native Win32 client comes out. I'll give it a try if I have the time... Of course the permission would be "cygwinized", but in many cases people don't even have backups, so it's better than nothing. How is the "exclude" snapshot? Stable enough to make a 0.04 ? :-) Pascal Lalonde From boxbackup at fluffy.co.uk Tue Feb 10 17:31:08 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Tue, 10 Feb 2004 17:31:08 +0000 Subject: [Box Backup] interactive bbackupquery In-Reply-To: <20040210065025.GA27429@plasma.doom.und> References: <20040205091611.GA22291@corest.com> <78250D4E-582A-11D8-90B1-003065F8EC8E@fluffy.co.uk> <4022C8E8.9000100@coresecurity.com> <5A500486-588D-11D8-BF14-003065F8EC8E@fluffy.co.uk> <20040210065025.GA27429@plasma.doom.und> Message-ID: On 10 Feb 2004, at 06:50, Pascal Lalonde wrote: > On Fri, Feb 06, 2004 at 10:15:13AM +0000, Ben Summers wrote: >> >>>> >>>> And the root directory is likely to contain many mounted >>>> filesystems, >>>> and having a mount point within a backup location is a Bad Thing >>>> because it ruins file and directory tracking (to handle renames >>>> efficiently). >>> >>> >>> I'm not sure I understand this. Suppose I have this mount points: >>> >>> /dev/wd0a on / type ffs (local, softdep) >>> /dev/wd0d on /tmp type ffs (local, softdep) >>> /dev/wd0e on /usr type ffs (local, softdep) >>> /dev/wd0f on /var type ffs (local, softdep) >>> >>> is it wrong to backup /root and /var? >> >> Not with that setup. >> >>> or the problem would >>> be if I have another directory mounted on /var/log? >> >> Yes, you should not backup /var if you have something mounted on >> /var/log . > > Maybe you should make the client not cross filesystems, like 'du -x' > does, or 'dump'. Of course, this would be clearly indicated in the > documentation, and users will expect this behavior. But having bbackupd > give warnings each time could become annoying. Is that what you were > planning? I was planning to just refuse to run with error messages on stdout and in the log. Of course, I should do more sophisticated rename tracking, but I don't think the effort and the decrease in performance will be justified. I prefer simple code, because there's less to go wrong. > > So far so good. 'compare -a' shows that everything is in order. I > finally found a machine to use as a more permanent backup server. I'm > just waiting to get a bigger hard drive and a little UPS. Soon we > will start using it (me and some friends) for backupping our personnal > stuff. This way I'll be able to see how it goes with a bigger volume > (+/- 40gigs), with 5 different users, and a few linux clients also. That's great news! Thanks. > > Would the client run in Cygwin? I don't see any reason why it should be difficult to do a quick Cygwin port. The now-free MS UNIX emulation layer might be interesting as well: http://www.microsoft.com/windows/sfu/default.asp > And would it handle spaces in file and > directory names? Absolutely! I'm testing it on a server which backs up files served using Samba, and all the Windows filenames are handled without problems. > I talked to some friends, and they would really like to > see this working on Win32, so maybe Cygwin could fill the gap while the > native Win32 client comes out. I'll give it a try if I have the time... > Of course the permission would be "cygwinized", but in many cases > people > don't even have backups, so it's better than nothing. Windows doesn't actually encourage permissions to be used, so it may not be terribly useful to do anything with them anyway -- when restored, the permissions would have the wrong user IDs unless you used some other backup software to back up the system configuration. > > How is the "exclude" snapshot? Stable enough to make a 0.04 ? :-) Seems fine to me, however, I want to do a little more with it before doing a 0.04. I've just been a bit busy with other stuff recently, so haven't had much time to do any work on this. Things should be cleared up in the next few days though. Ben From boxbackup at fluffy.co.uk Tue Feb 10 18:41:00 2004 From: boxbackup at fluffy.co.uk (Pascal Lalonde) Date: Tue, 10 Feb 2004 13:41:00 -0500 Subject: [Box Backup] interactive bbackupquery In-Reply-To: References: <20040205091611.GA22291@corest.com> <78250D4E-582A-11D8-90B1-003065F8EC8E@fluffy.co.uk> <4022C8E8.9000100@coresecurity.com> <5A500486-588D-11D8-BF14-003065F8EC8E@fluffy.co.uk> <20040210065025.GA27429@plasma.doom.und> Message-ID: <20040210184100.GA17111@plasma.doom.und> On Tue, Feb 10, 2004 at 05:31:08PM +0000, Ben Summers wrote: > > On 10 Feb 2004, at 06:50, Pascal Lalonde wrote: > > >On Fri, Feb 06, 2004 at 10:15:13AM +0000, Ben Summers wrote: > >> > >>>> > >>>>And the root directory is likely to contain many mounted > >>>>filesystems, > >>>>and having a mount point within a backup location is a Bad Thing > >>>>because it ruins file and directory tracking (to handle renames > >>>>efficiently). > >>> > >>> > >>>I'm not sure I understand this. Suppose I have this mount points: > >>> > >>>/dev/wd0a on / type ffs (local, softdep) > >>>/dev/wd0d on /tmp type ffs (local, softdep) > >>>/dev/wd0e on /usr type ffs (local, softdep) > >>>/dev/wd0f on /var type ffs (local, softdep) > >>> > >>>is it wrong to backup /root and /var? > >> > >>Not with that setup. > >> > >>>or the problem would > >>>be if I have another directory mounted on /var/log? > >> > >>Yes, you should not backup /var if you have something mounted on > >>/var/log . > > > >Maybe you should make the client not cross filesystems, like 'du -x' > >does, or 'dump'. Of course, this would be clearly indicated in the > >documentation, and users will expect this behavior. But having bbackupd > >give warnings each time could become annoying. Is that what you were > >planning? > > I was planning to just refuse to run with error messages on stdout and > in the log. > > Of course, I should do more sophisticated rename tracking, but I don't > think the effort and the decrease in performance will be justified. I > prefer simple code, because there's less to go wrong. > Maybe my question wasn't too clear. What I mean is: I don't mind if bbackupd does not cross mount points. What I would like is a way to stop it from complaining (a command-line flag maybe?). This way, when it encounters a mount point, it silently skips over it, and continues with the next file/directory. This is just to spare us from specifying every mount point as exclude patterns, thus keeping the config file cleaner by not having very long exclude patterns specifications. It is common that I see a lot of stuff mounted under /var, like /var/www, /var/mail, /var/log, /var/postgresql, /var/tmp, etc. I have no idea of the complexity of doing this, though, so maybe that's what you mean when you say you want to keep the code clean. Pascal Lalonde From boxbackup at fluffy.co.uk Tue Feb 10 21:40:33 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Tue, 10 Feb 2004 21:40:33 +0000 Subject: [Box Backup] interactive bbackupquery In-Reply-To: <20040210184100.GA17111@plasma.doom.und> References: <20040205091611.GA22291@corest.com> <78250D4E-582A-11D8-90B1-003065F8EC8E@fluffy.co.uk> <4022C8E8.9000100@coresecurity.com> <5A500486-588D-11D8-BF14-003065F8EC8E@fluffy.co.uk> <20040210065025.GA27429@plasma.doom.und> <20040210184100.GA17111@plasma.doom.und> Message-ID: On 10 Feb 2004, at 18:41, Pascal Lalonde wrote: > On Tue, Feb 10, 2004 at 05:31:08PM +0000, Ben Summers wrote: >> >> On 10 Feb 2004, at 06:50, Pascal Lalonde wrote: >>> >>> Maybe you should make the client not cross filesystems, like 'du -x' >>> does, or 'dump'. Of course, this would be clearly indicated in the >>> documentation, and users will expect this behavior. But having >>> bbackupd >>> give warnings each time could become annoying. Is that what you were >>> planning? >> >> I was planning to just refuse to run with error messages on stdout and >> in the log. >> >> Of course, I should do more sophisticated rename tracking, but I don't >> think the effort and the decrease in performance will be justified. I >> prefer simple code, because there's less to go wrong. >> > Maybe my question wasn't too clear. What I mean is: I don't mind if > bbackupd does not cross mount points. What I would like is a way to > stop > it from complaining (a command-line flag maybe?). This way, when it > encounters a mount point, it silently skips over it, and continues with > the next file/directory. This is just to spare us from specifying every > mount point as exclude patterns, thus keeping the config file cleaner > by > not having very long exclude patterns specifications. It is common that > I see a lot of stuff mounted under /var, like /var/www, /var/mail, > /var/log, /var/postgresql, /var/tmp, etc. I have no idea of the > complexity of doing this, though, so maybe that's what you mean when > you say you want to keep the code clean. Oh, I see! Have an option to automatically exclude all directories mounted within the location specified? Shouldn't be too hard. Or messy. Ben From boxbackup at fluffy.co.uk Wed Feb 11 04:18:54 2004 From: boxbackup at fluffy.co.uk (Pascal Lalonde) Date: Tue, 10 Feb 2004 23:18:54 -0500 Subject: [Box Backup] interactive bbackupquery In-Reply-To: References: <20040205091611.GA22291@corest.com> <78250D4E-582A-11D8-90B1-003065F8EC8E@fluffy.co.uk> <4022C8E8.9000100@coresecurity.com> <5A500486-588D-11D8-BF14-003065F8EC8E@fluffy.co.uk> <20040210065025.GA27429@plasma.doom.und> <20040210184100.GA17111@plasma.doom.und> Message-ID: <20040211041854.GA31077@plasma.doom.und> On Tue, Feb 10, 2004 at 09:40:33PM +0000, Ben Summers wrote: > > > Oh, I see! Have an option to automatically exclude all directories > mounted within the location specified? > > Shouldn't be too hard. Or messy. > Yes. That's how I should've explained it. Thanks, Pascal Lalonde From boxbackup at fluffy.co.uk Thu Feb 12 10:00:39 2004 From: boxbackup at fluffy.co.uk (Bo Rasmussen) Date: Thu, 12 Feb 2004 11:00:39 +0100 Subject: [Box Backup] databases Message-ID: <2C4E0A87C4F1514E86629F9972656E392EAFC0@cads1.CADesign.dk> Hey, Just to let you know Ben, that I have successfully completed a setup with a FreeBSD 4.8 client backing up around 1GB data to a OpenBSD 3.4 server, I will let you know if there is any problems. BTW. Ben, should there be any problems backing up open or closed mysql = databases with the lastest 0.03 version ? I can't seem to find any clues regarding = this. Regards Bo Rising Rasmussen it/security consultant brr at cadesign.dk cadesign ------------------------ rosensgade 26 postboks 579 8100 =E5rhus c tlf +45 8730 0000 fax +45 8620 5484 www.cadesign.dk From boxbackup at fluffy.co.uk Thu Feb 12 10:28:05 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Thu, 12 Feb 2004 10:28:05 +0000 Subject: [Box Backup] databases In-Reply-To: <2C4E0A87C4F1514E86629F9972656E392EAFC0@cads1.CADesign.dk> References: <2C4E0A87C4F1514E86629F9972656E392EAFC0@cads1.CADesign.dk> Message-ID: <251B61E4-5D46-11D8-B0B4-003065F8EC8E@fluffy.co.uk> On 12 Feb 2004, at 10:00, Bo Rasmussen wrote: > Hey, > > Just to let you know Ben, that I have successfully completed a setup > with a FreeBSD 4.8 client backing up around 1GB data to a OpenBSD 3.4 > server, I will let you know if there is any problems. Good news! > > BTW. Ben, should there be any problems backing up open or closed mysql > databases > with the lastest 0.03 version ? I can't seem to find any clues > regarding this. Closed -- not a problem. Open -- depends. All backup systems have problems with files being modified while they're being backed up. MySQL should be able to repair any damage caused by this, but it's not an ideal solution. I am intending to have code which detects writes during a backup operation, and aborts if changes have been made. This should avoid the problem, but again, is not ideal. (Expect this in the next version.) The best solution with MySQL, if you have the disc space, is not to back up the databases directly. Instead, do a mysqldump of the entire database into a file with a cron job, and back up the dumps instead. This will result in less disc space needed for the backup because you'll only be backing up the data, not the indices. But as I said, this problem is common to all backup systems. But because of the nature of Box Backup, I'm going to take extra precautions and detect changes. Thanks for trying it out. Ben From boxbackup at fluffy.co.uk Thu Feb 12 12:54:15 2004 From: boxbackup at fluffy.co.uk (Bo Rasmussen) Date: Thu, 12 Feb 2004 13:54:15 +0100 Subject: [Box Backup] databases Message-ID: <2C4E0A87C4F1514E86629F9972656E392EAFC3@cads1.CADesign.dk> > -----Original Message----- > From: boxbackup-admin at fluffy.co.uk=20 > [mailto:boxbackup-admin at fluffy.co.uk] On Behalf Of Ben Summers > Sent: Thursday, February 12, 2004 11:28 AM > To: boxbackup at fluffy.co.uk > Subject: Re: [Box Backup] databases > > Closed -- not a problem. Great ! > Open -- depends. > But as I said, this problem is common to all backup systems.=20 > But because of the nature of Box Backup, I'm going to take=20 > extra precautions and detect changes. Thats totally great Ben !!!! We have talked a little about the possibillity of something like backing up to 3 different external physical harddisks/SAN. So instead of backing up to 3 harddisks in raid then backup to 3 SANS in raid .. Is this a possibillity ? I know that it sounds a little long fetched :) > Thanks for trying it out. No problem, I'm also trying to make it compile on my 2 HPPA machines, but without much luck yet ... Regards Bo From boxbackup at fluffy.co.uk Thu Feb 12 13:04:03 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Thu, 12 Feb 2004 13:04:03 +0000 Subject: [Box Backup] databases In-Reply-To: <2C4E0A87C4F1514E86629F9972656E392EAFC3@cads1.CADesign.dk> References: <2C4E0A87C4F1514E86629F9972656E392EAFC3@cads1.CADesign.dk> Message-ID: On 12 Feb 2004, at 12:54, Bo Rasmussen wrote: >> Open -- depends. >> But as I said, this problem is common to all backup systems. >> But because of the nature of Box Backup, I'm going to take >> extra precautions and detect changes. > > Thats totally great Ben !!!! > > We have talked a little about the possibillity > of something like backing up to 3 different external physical > harddisks/SAN. So instead of backing up to 3 harddisks in raid > then backup to 3 SANS in raid .. Is this a possibillity ? > > I know that it sounds a little long fetched :) I'm not sure I entirely follow. However, if you can mount three filesystems, you can do userland raid. What those three filesystems are doesn't really matter. They could be NFS mounts, RAID arrays, external hard drives, whatever you want. So if you can arrange to have three filesystems which don't live on the same physical hardware, the answer is yes. If they do live on the same physical hardware, then there's hardly any point. > >> Thanks for trying it out. > > No problem, I'm also trying to make it compile on my 2 HPPA > machines, but without much luck yet ... Which OS is this? What errors do you get? Ben From boxbackup at fluffy.co.uk Thu Feb 12 13:17:44 2004 From: boxbackup at fluffy.co.uk (Bo Rasmussen) Date: Thu, 12 Feb 2004 14:17:44 +0100 Subject: [Box Backup] databases Message-ID: <2C4E0A87C4F1514E86629F9972656E392EAFC4@cads1.CADesign.dk> > -----Original Message----- > I'm not sure I entirely follow. However, if you can mount=20 > three filesystems, you can do userland raid. What those three=20 > filesystems are doesn't really matter. They could be NFS=20 > mounts, RAID arrays, external hard drives, whatever you want. Yes, thats what i meant .. Great, we will try with some NFS mounts from 3 Windows 2000/2003 servers to a OpenBSD 3.4 :) =20 > So if you can arrange to have three filesystems which don't=20 > live on the same physical hardware, the answer is yes. If=20 > they do live on the same physical hardware, then there's=20 > hardly any point. Exactly. > Which OS is this? What errors do you get? OpenBSD 3.4 - HP9000/700/60 It's the client which barfs on compilation, I don't have the computer turned on now, but I will try to compile it this weekend. Regards Bo From boxbackup at fluffy.co.uk Sat Feb 14 06:04:20 2004 From: boxbackup at fluffy.co.uk (Pascal Lalonde) Date: Sat, 14 Feb 2004 01:04:20 -0500 Subject: [Box Backup] Error message (3/41) In-Reply-To: <200402140400.i1E402W8026267@claymore.overnet.und> References: <200402140400.i1E402W8026267@claymore.overnet.und> Message-ID: <20040214060420.GA29874@plasma.doom.und> Feb 13 22:09:02 claymore bbstored[28253]: Login: Client ID 00000001, Read/Write Feb 13 22:20:36 claymore bbstored/hk[18538]: Starting housekeeping Feb 13 22:20:36 claymore bbstored/hk[18538]: Finished housekeeping Feb 13 22:25:29 claymore bbstored[28253]: in server child, exception Server (3/41) -- terminating child Feb 13 22:35:36 claymore bbstored/hk[18538]: Starting housekeeping Feb 13 22:35:37 claymore bbstored/hk[18538]: On housekeeping, sizes in store do not match calculated sizes, correcting Feb 13 22:35:37 claymore bbstored/hk[18538]: different (store,calc): acc 0x00000001, used (586742,586951), old (79540,79745), deleted (9114,9114), dirs (3315,3315) Feb 13 22:35:37 claymore bbstored/hk[18538]: Finished housekeeping I guess this means the connection between the client and the server was interrupted, for example the ISP maybe have had a little problem. Then, the server noticed and inconsistency, and corrected it. I'm just trying to make sure. So everything should be in order right? This is normal behavior? Pascal Lalonde From boxbackup at fluffy.co.uk Sat Feb 14 11:54:57 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Sat, 14 Feb 2004 11:54:57 +0000 Subject: [Box Backup] Error message (3/41) In-Reply-To: <20040214060420.GA29874@plasma.doom.und> References: <200402140400.i1E402W8026267@claymore.overnet.und> <20040214060420.GA29874@plasma.doom.und> Message-ID: <9C0178BC-5EE4-11D8-833E-003065F8EC8E@fluffy.co.uk> On 14 Feb 2004, at 06:04, Pascal Lalonde wrote: > Feb 13 22:09:02 claymore bbstored[28253]: Login: Client ID 00000001, > Read/Write > Feb 13 22:20:36 claymore bbstored/hk[18538]: Starting housekeeping > Feb 13 22:20:36 claymore bbstored/hk[18538]: Finished housekeeping > Feb 13 22:25:29 claymore bbstored[28253]: in server child, exception > Server (3/41) -- terminating child > Feb 13 22:35:36 claymore bbstored/hk[18538]: Starting housekeeping > Feb 13 22:35:37 claymore bbstored/hk[18538]: On housekeeping, sizes in > store do not match calculated sizes, correcting > Feb 13 22:35:37 claymore bbstored/hk[18538]: different (store,calc): > acc > 0x00000001, used (586742,586951), old (79540,79745), deleted > (9114,9114), dirs (3315,3315) > Feb 13 22:35:37 claymore bbstored/hk[18538]: Finished housekeeping > > > I guess this means the connection between the client and the server was > interrupted, for example the ISP maybe have had a little problem. > Then, the server noticed and inconsistency, and corrected it. Yes, the client connection timed out, and the server process was terminated. > > I'm just trying to make sure. So everything should be in order right? > This is normal behavior? Absolutely. The store has a "store info" file for each account, which gives information on last object IDs used, size of files, etc. It doesn't have to be absolutely up to date for things to work correctly, so is written lazily after every few transactions for performance reasons. When an error occurs everything is cleaned up nicely, but the store info it isn't written back (as it might cause more errors) and so is then out of date. This doesn't matter, as the code is tolerant. However, housekeeping needs accurate sizes. It scans everything anyway, so calculates the correct values and adjusts the store info file if they are wrong -- this is what you're seeing. Ben From boxbackup at fluffy.co.uk Sat Feb 14 15:54:31 2004 From: boxbackup at fluffy.co.uk (Bo Rasmussen) Date: Sat, 14 Feb 2004 16:54:31 +0100 Subject: [Box Backup] databases Message-ID: <2C4E0A87C4F1514E86629F9972656E39359743@cads1.CADesign.dk> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F312.D5833EF1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ok Ben, Now I have some compile output on a hppa - (HP9000/712/60) with OpenBSD = 3.4-stable. Hope you can get something out of this :) Bo -- ../../release/lib/crypto/crypto.o(.rodata+0x250): undefined reference to = `EVP_CipherFinal_ex' ../../release/lib/crypto/crypto.o: In function `L$C0461': ../../release/lib/crypto/crypto.o(.rodata+0x2b8): undefined reference to = `EVP_CipherInit' ../../release/lib/crypto/crypto.o: In function `L$C0505': ../../release/lib/crypto/crypto.o(.rodata+0x2f0): undefined reference to = `EVP_CipherInit' ../../release/lib/crypto/crypto.o: In function `L$C0547': ../../release/lib/crypto/crypto.o(.rodata+0x2fc): undefined reference to = `EVP_CIPHER_CTX_set_padding' ../../release/lib/crypto/crypto.o: In function `L$C0092': ../../release/lib/crypto/crypto.o(.rodata+0x408): undefined reference to = `MD5_Init' ../../release/lib/crypto/crypto.o: In function `L$C0097': ../../release/lib/crypto/crypto.o(.rodata+0x414): undefined reference to = `MD5_Update' ../../release/lib/crypto/crypto.o: In function `L$C0098': ../../release/lib/crypto/crypto.o(.rodata+0x418): undefined reference to = `MD5_Update' ../../release/lib/crypto/crypto.o: In function `L$C0099': ../../release/lib/crypto/crypto.o(.rodata+0x41c): undefined reference to = `MD5_Final' ../../release/lib/crypto/crypto.o: In function `L$C0033': ../../release/lib/crypto/crypto.o(.rodata+0x508): undefined reference to = `RAND_pseudo_bytes' ../../release/lib/backupclient/backupclient.o: In function `L$C1356': ../../release/lib/backupclient/backupclient.o(.rodata+0x10c0): undefined = reference to `deflateEnd' ../../release/lib/backupclient/backupclient.o: In function `L$C1393': ../../release/lib/backupclient/backupclient.o(.rodata+0x10f8): undefined = reference to `deflateInit_' ../../release/lib/backupclient/backupclient.o: In function `L$C1462': ../../release/lib/backupclient/backupclient.o(.rodata+0x115c): undefined = reference to `deflate' ../../release/lib/backupclient/backupclient.o: In function `L$C1496': ../../release/lib/backupclient/backupclient.o(.rodata+0x1190): undefined = reference to `inflateEnd' ../../release/lib/backupclient/backupclient.o: In function `L$C1533': ../../release/lib/backupclient/backupclient.o(.rodata+0x11c8): undefined = reference to `inflateInit_' ../../release/lib/backupclient/backupclient.o: In function `L$C1602': ../../release/lib/backupclient/backupclient.o(.rodata+0x122c): undefined = reference to `inflate' ../../release/lib/server/server.o: In function `L$C0089': ../../release/lib/server/server.o(.rodata+0xdfc): undefined reference to = `ERR_get_error' ../../release/lib/server/server.o: In function `L$C0090': ../../release/lib/server/server.o(.rodata+0xe00): undefined reference to = `ERR_error_string_n' ../../release/lib/server/server.o: In function `L$C0147': ../../release/lib/server/server.o(.rodata+0x13a0): undefined reference = to `BIO_free' ../../release/lib/server/server.o: In function `L$C0165': ../../release/lib/server/server.o(.rodata+0x1408): undefined reference = to `BIO_s_socket' ../../release/lib/server/server.o: In function `L$C0166': ../../release/lib/server/server.o(.rodata+0x140c): undefined reference = to `BIO_new' ../../release/lib/server/server.o: In function `L$C0170': ../../release/lib/server/server.o(.rodata+0x1418): undefined reference = to `BIO_int_ctrl' ../../release/lib/server/server.o: In function `L$C0550': ../../release/lib/server/server.o(.rodata+0x15d4): undefined reference = to `X509_free' ../../release/lib/server/server.o: In function `L$C0553': ../../release/lib/server/server.o(.rodata+0x15e0): undefined reference = to `X509_get_subject_name' ../../release/lib/server/server.o: In function `L$C0554': ../../release/lib/server/server.o(.rodata+0x15e4): undefined reference = to `X509_NAME_get_text_by_NID' collect2: ld returned 1 exit status --- FORM_OPENBSD -DBOX_VERSION=3D"\"0.03\"" -c BackupClientContext.cpp -o = ../../release/bin/bbackupd/BackupClientContext.o g++ -DNDEBUG -O2 -Wall -I../../lib/common -I../../lib/compress = -I../../lib/crypto -I../../lib/server -I../../lib/backupclient -DPLAT FORM_OPENBSD -DBOX_VERSION=3D"\"0.03\"" -c BackupClientDeleteList.cpp -o = ../../release/bin/bbackupd/BackupClientDeleteList.o g++ -DNDEBUG -O2 -Wall -I../../lib/common -I../../lib/compress = -I../../lib/crypto -I../../lib/server -I../../lib/backupclient -DPLAT FORM_OPENBSD -DBOX_VERSION=3D"\"0.03\"" -c = BackupClientDirectoryRecord.cpp -o = ../../release/bin/bbackupd/BackupClientDirectoryRecord.o g++ -DNDEBUG -O2 -Wall -I../../lib/common -I../../lib/compress = -I../../lib/crypto -I../../lib/server -I../../lib/backupclient -DPLAT FORM_OPENBSD -DBOX_VERSION=3D"\"0.03\"" -c BackupClientInodeToIDMap.cpp = -o ../../release/bin/bbackupd/BackupClientInodeToIDMap.o g++ -DNDEBUG -O2 -Wall -I../../lib/common -I../../lib/compress = -I../../lib/crypto -I../../lib/server -I../../lib/backupclient -DPLAT FORM_OPENBSD -DBOX_VERSION=3D"\"0.03\"" -c BackupDaemon.cpp -o = ../../release/bin/bbackupd/BackupDaemon.o g++ -DNDEBUG -O2 -Wall -I../../lib/common -I../../lib/compress = -I../../lib/crypto -I../../lib/server -I../../lib/backupclient -DPLAT FORM_OPENBSD -DBOX_VERSION=3D"\"0.03\"" -c bbackupd.cpp -o = ../../release/bin/bbackupd/bbackupd.o g++ -o ../../release/bin/bbackupd/bbackupd -lcrypto -lz -lssl = ../../release/lib/crypto/crypto.o ../../release/lib/compress/compress. o ../../release/lib/backupclient/backupclient.o = ../../release/lib/server/server.o ../../release/lib/common/common.o = ../../release/b in/bbackupd/BackupClientContext.o = ../../release/bin/bbackupd/BackupClientDeleteList.o = ../../release/bin/bbackupd/BackupClientDirecto ryRecord.o ../../release/bin/bbackupd/BackupClientInodeToIDMap.o = ../../release/bin/bbackupd/BackupDaemon.o ../../release/bin/bbackup d/bbackupd.o *** Error code 1 Stop in /home/vrou/boxbackup-0.03/bin/bbackupd (line 38 of Makefile). *** Error code 1 Stop in /home/vrou/boxbackup-0.03 (line 21 of Makefile). -----Original Message----- From: boxbackup-admin at fluffy.co.uk on behalf of Bo Rasmussen Sent: Thu 2/12/2004 2:17 PM To: boxbackup at fluffy.co.uk Subject: RE: [Box Backup] databases > Which OS is this? What errors do you get? OpenBSD 3.4 - HP9000/700/60 It's the client which barfs on compilation, I don't have the computer turned on now, but I will try to compile it this weekend. Bo _______________________________________________ boxbackup mailing list boxbackup at fluffy.co.uk http://lists.warhead.org.uk/mailman/listinfo/boxbackup ------_=_NextPart_001_01C3F312.D5833EF1 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IiUPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAGwAAAFJFOiBbQm94IEJhY2t1cF0g ZGF0YWJhc2VzABAJAQWAAwAOAAAA1AcCAA4AEAA2AB8ABgBWAQEggAMADgAAANQHAgAOABAANgAf AAYAVgEBCYABACEAAABFNEVCQTIwODIxQzY4MTQ2QTMwRTY1M0MyRjVBQzIzRAAuBwEDkAYA3A4A ADgAAAADACYAAAAAAAMANgAAAAAAQAA5APE+g9US88MBHgA9AAEAAAAFAAAAUkU6IAAAAAACAUcA AQAAAC0AAABjPXVzO2E9IDtwPUNBREVTSUdOO2w9Q0FEUzEtMDQwMjE0MTU1NDMxWi03NAAAAAAe AEkAAQAAABsAAABSRTogW0JveCBCYWNrdXBdIGRhdGFiYXNlcwAAQABOAABMdplq8cMBHgBaAAEA AAAdAAAAYm94YmFja3VwLWFkbWluQGZsdWZmeS5jby51awAAAAACAVsAAQAAAFcAAAAAAAAAgSsf pL6jEBmdbgDdAQ9UAgAAAABib3hiYWNrdXAtYWRtaW5AZmx1ZmZ5LmNvLnVrAFNNVFAAYm94YmFj a3VwLWFkbWluQGZsdWZmeS5jby51awAAAgFcAAEAAAAiAAAAU01UUDpCT1hCQUNLVVAtQURNSU5A RkxVRkZZLkNPLlVLAAAAHgBdAAEAAAANAAAAQm8gUmFzbXVzc2VuAAAAAAIBXgABAAAAOgAAAAAA AACBKx+kvqMQGZ1uAN0BD1QCAAAAAEJvIFJhc211c3NlbgBTTVRQAGJyckBjYWRlc2lnbi5kawAA AAIBXwABAAAAFQAAAFNNVFA6QlJSQENBREVTSUdOLkRLAAAAAB4AZgABAAAABQAAAFNNVFAAAAAA HgBnAAEAAAAdAAAAYm94YmFja3VwLWFkbWluQGZsdWZmeS5jby51awAAAAAeAGgAAQAAAAUAAABT TVRQAAAAAB4AaQABAAAAEAAAAGJyckBjYWRlc2lnbi5kawAeAHAAAQAAABcAAABbQm94IEJhY2t1 cF0gZGF0YWJhc2VzAAACAXEAAQAAACAAAAABw/Fo1GUxIG3LWPJJ9LticMSYPHl1AAAiBOAAaPID 5h4AdAABAAAAFwAAAGJveGJhY2t1cEBmbHVmZnkuY28udWsAAB4AGgwBAAAADQAAAEJvIFJhc211 c3NlbgAAAAAeAB0OAQAAABcAAABbQm94IEJhY2t1cF0gZGF0YWJhc2VzAAACAQkQAQAAAFsIAABX CAAALxwAAExaRnUnAtW5AwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/ CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFAz CwkBZDM2FlALpiBP6GsgQgnwLAqiCoQKgCRObwfgSSAT4HZlnCBzA3AesAWgbXADEHMesAhgdHAf sB+QA6BhBR5wcAqwIC0gKEhIUDkwIRAvNw4gL0kcMCkgA/B0aBzgcAEJ8EJTRCAzLjQsLXMBkR9w Lh1qSG+5IjAgeQhgHxADkWcUIDcewyHwC4BnH5IfkGYgkyVhBCA6KR1qQm8dZMQtLR1qLi4vKMEY IAUfcGEUEC9saWIvFQUAeQUwbynVLm8oEi4DYGRhAZArMHjDDjAhoDogdW4BAQuAtQmAIBggZgSQ CfBjHrABKiAgYEVWUF9DtQUgaASQRguAB0BfDsBeJyhvKX8qgyvASQOgZhEr4GN0aSARYEwkgEMw NDYxJzoun/MvryqPYjgrvyzPLdExIL8h4C6PM48wrzG2K5A1Mm//OW80jytwATA13zbvN/88//M6 HzsuNDc8T0NPPm8/cQZjP79AzUlQSEVSUS2QVFhfFBFfCrBkPmQlgUJPR09EbzG2MDmOMkYvTe9I T3g0MDXP4UC5TUQ1X0IPUa9Oz59P3EYfV19S31PhMTRUP+lVTFVwKxFlVm9bb1iP/VAYOFpPYQ9c b11xVC9ev+9fz2TPYe9P3Dlj72qvZg//XXFJj1U9LgNpr26va89QF9wzM22PdD9vr3grkGdPYUC5 UkFORExgFBB1oGRvX2J5DrBzcz+FeDZiANBrdXBjeHAdCfB0fst1nzHxMTM1HjZ3H35Pf18quzEw Y98/r0C5AQELYA6wRYZgfU/vgw+EH4B/gYI5dw+Jb4p/rYUOZnp/hy9lViJfiH//jj+PT4uvgYEy MFC/lL+Vz/mFDTE1cO+SX2mfmX+aj/uW75fzOYHfn7+gz5uOIQD/nK9AyAuAh/+kD6UfoX+BCd41 dv+q36vvpn9jkU+or/+Tb69fsG+sz4EnHDCYX7Y/87dPhQ0yMpyfs9+ev3gndRQQch6gcsHFuG9Q UzhvbX/BP8JGKtlkSX9Ki1LXS9Ak4S5QcgNgcsBPxU+7wm9QGDDEL8sfxk94CmBvp5/IncnDTCB0 BRAlkF/+bsofzx/MPzG2XZBaP9UvM9APhcEzYdFfQLlCSfxPXwNQCeDUP9k/1l/XZ342PD/ev9ov hcFUD9x/c/1MIG+7oBQg3c/iz9/v4Ph/o1/oj+O/5MPHj9yd74B37+ef7J/pv9dnN83v8g/tj7/k wmc/3I4LgExQMYBycy//9g/zLzuIK5D0//vv9x+F0Kw1ZF2vQLlYK5A53X///5/8v/3Nro8FfwDf AeLRMAcCTwNdyYJzdWJqZfsxgNQQYR7wBI8Jjwav/hh+NAhvD+8KjwuSAj8DTk7YQU1FyXPAIHi1 IHzw2RgwSUQO5R8gbB9wMYCKMhZQbNISdHVyFtJ8MSAuYFZAHsAi8BrgcwcdaifgJ/tGT1JNXxBP UEVOImItREIqT0wQVkvAU91QTj3AIlxcIjAuduAfkaIiHpBjIEK8Y0O784ZDdmAY0i5jcHAekDvd EBNMYnLwvEC7hGQvxyCPIZEndWcrKx6RfFCQRUJVRx6QTzIekGpXLjBsHpBJE0R4c28sbW12YScN cARQc3N/Jvx4wyb7EHQm+7uKHpFQeExBVB1/Ho8fnyQIRPO60cAgTGkbwCG/Is8j2/8xqSUvJj8n TyhfKW8qfyuP3yyfLa8uvy/PMNxpBFBFQNnJ8HlSDmDJ8GQyTzNf/zRsQn017zb/OA85HzovOz// PE89Xz5vP39AjyB7EYBdAIhlVG8ZYE1hcENf/0RvI9tTy0dPSF9Jb0p/S49/TJ9Nr06/T89Q31Hv IHVE/GFlWxFUj1WfI9VkZVhP/1lfWm9bf1yPXZ9er1+/YM/7Yd9i7yBWJmTPZd9WF2e7L3RvdX8j oXGQbGzmbHr/edFr8GmAE09s1WzVxpB7D/treGuHLhLkfR+7X7xrf+//FE+Cz2pGalWEwXeeEuRm P/8kPnefiI8034p/i49F3BLk/0a4jc+O31cfWCGRv5LPZ1ZPlR+WJxLkdh8KKprQIHpFydIgGfAW kBtAHCpTx0KwdDAWwCAvaGpwgLBKdsngdbxAb3hvRC0zY0KV+yAobdAW0CAz4Dggb2YgVFDnYBaw /YBwKX9lmt+b75z/ngifdb4yG1CgHxxmHC0c4E/T0N5nFsBpYKXQa+FhyYCoAxtwdcngbRZQnchh ZG2FFsBAtKB1ZmZ5dAAZfPB1a6Wgw4BiZWhXaWClwKWxQt0QUoCQbTscAICgbqKlgaEWUFRoSnWl cC+94C8yw+A0xaVwOvTAIFBNEuRUEJ+qSatboqUONBZQUkUWUMpbrQB4IHVdIMbyb0ADgKAcGz4g V2hpY7BoIE9To0BsAHS1UHxzP7UxxwAbYMnSbABkVd0QeaQAIMmBPxwqTyZw3LBxYjMur0AtIGxI UM3Qw+Av9NC5wDZ6MBwqSeeAteLc4G+ld/O1U29AcmZsAMNxa5KgkPvHAP4BLBFwtxHUIBugrIDv FQC7QhmWa7B1IXBuYBrla8NxU9B3vaBiv2C9sXf3oJBpgNPAeReivPTc4BuR/7YCu/AEYOdgFoCm e60AEuQ+X8SPxZ/GahLknccgbf5hoJDT4RqAMhHHfbEPEyDAaHR0cDovbcEbwD1/UHcTALtgqwDQ YHJnfavxL8hyyHCWIMjyFsBmJ3yAncem7wp9z+AAHgA1EAEAAAA7AAAAPDJDNEUwQTg3QzRGMTUx NEU4NjYyOUY5OTcyNjU2RTM5MzU5NzQzQGNhZHMxLkNBRGVzaWduLmRrPgAAHgBHEAEAAAAPAAAA bWVzc2FnZS9yZmM4MjIAAAsA8hABAAAAHwDzEAEAAABCAAAAUgBFACUAMwBBACAAWwBCAG8AeAAg AEIAYQBjAGsAdQBwAF0AIABkAGEAdABhAGIAYQBzAGUAcwAuAEUATQBMAAAAAAALAPYQAAAAAEAA BzAxsoMkDfPDAUAACDBL75PVEvPDAQMA3j+vbwAAAwDxPwkAAAAeAPg/AQAAAA0AAABCbyBSYXNt dXNzZW4AAAAAAgH5PwEAAABbAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPUNBREVT SUdOL09VPUZJUlNUIEFETUlOSVNUUkFUSVZFIEdST1VQL0NOPVJFQ0lQSUVOVFMvQ049QlJSAAAe APo/AQAAABUAAABTeXN0ZW0gQWRtaW5pc3RyYXRvcgAAAAACAfs/AQAAAB4AAAAAAAAA3KdAyMBC EBq0uQgAKy/hggEAAAAAAAAALgAAAAMA/T/kBAAAAwAZQAAAAAADABpAAAAAAAMAHUAAAAAAAwAe QAAAAAAeADBAAQAAAAQAAABCUlIAHgAxQAEAAAAEAAAAQlJSAB4AMkABAAAAHQAAAGJveGJhY2t1 cC1hZG1pbkBmbHVmZnkuY28udWsAAAAAHgAzQAEAAAAQAAAAYnJyQGNhZGVzaWduLmRrAB4AOEAB AAAABAAAAEJSUgAeADlAAQAAAAIAAAAuAAAAAwB2QP////8LACkAAAAAAAsAIwAAAAAAAwAGEPBa u7IDAAcQnxQAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABPS0JFTixOT1dJSEFWRVNPTUVD T01QSUxFT1VUUFVUT05BSFBQQS0oSFA5MDAwLzcxMi82MClXSVRIT1BFTkJTRDM0LVNUQUJMRUhP UEVZT1VDQU5HRVRTT01FVEhJTkdPVVRPAAAAAAIBfwABAAAAOwAAADwyQzRFMEE4N0M0RjE1MTRF ODY2MjlGOTk3MjY1NkUzOTM1OTc0M0BjYWRzMS5DQURlc2lnbi5kaz4AAAXg ------_=_NextPart_001_01C3F312.D5833EF1-- From boxbackup at fluffy.co.uk Sat Feb 14 16:00:42 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Sat, 14 Feb 2004 16:00:42 +0000 Subject: [Box Backup] databases In-Reply-To: <2C4E0A87C4F1514E86629F9972656E39359743@cads1.CADesign.dk> References: <2C4E0A87C4F1514E86629F9972656E39359743@cads1.CADesign.dk> Message-ID: On 14 Feb 2004, at 15:54, Bo Rasmussen wrote: > Ok Ben, > > Now I have some compile output on a hppa - (HP9000/712/60) with > OpenBSD 3.4-stable. > > Hope you can get something out of this :) > > Bo > -- > > ../../release/lib/crypto/crypto.o(.rodata+0x250): undefined reference > to `EVP_CipherFinal_ex' > ../../release/lib/crypto/crypto.o: In function `L$C0461': That's all very odd -- it's trying to link with the OpenSSL libraries, but is failing somehow. I'm not sure how this would happen without something bad having happened to your system. If you do cd bin/bbstored make -D RELEASE and cd bin/bbstored make and cd bin/bbackupd make do you get similar errors? Thanks, Ben From boxbackup at fluffy.co.uk Sun Feb 15 09:10:41 2004 From: boxbackup at fluffy.co.uk (Bo Rasmussen) Date: Sun, 15 Feb 2004 10:10:41 +0100 Subject: [Box Backup] databases Message-ID: <2C4E0A87C4F1514E86629F9972656E39359745@cads1.CADesign.dk> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F3A3.E24FC6F5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I get the same errors with all three compiles, and I have tried to fetch a new tar package. I could try my other hppa box, but I don't think that it is something with the os to do. Any other ideas ? Bo -----Original Message----- From: boxbackup-admin at fluffy.co.uk on behalf of Ben Summers Sent: Sat 2/14/2004 5:00 PM To: boxbackup at fluffy.co.uk Subject: Re: [Box Backup] databases =20 On 14 Feb 2004, at 15:54, Bo Rasmussen wrote: > Ok Ben, > > Now I have some compile output on a hppa - (HP9000/712/60) with=20 > OpenBSD 3.4-stable. > > Hope you can get something out of this :) > > Bo > -- > > ../../release/lib/crypto/crypto.o(.rodata+0x250): undefined reference=20 > to `EVP_CipherFinal_ex' > ../../release/lib/crypto/crypto.o: In function `L$C0461': That's all very odd -- it's trying to link with the OpenSSL libraries,=20 but is failing somehow. I'm not sure how this would happen without=20 something bad having happened to your system. If you do cd bin/bbstored make -D RELEASE and cd bin/bbstored make and cd bin/bbackupd make do you get similar errors? Thanks, Ben _______________________________________________ boxbackup mailing list boxbackup at fluffy.co.uk http://lists.warhead.org.uk/mailman/listinfo/boxbackup ------_=_NextPart_001_01C3F3A3.E24FC6F5 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjMJAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAGwAAAFJFOiBbQm94IEJhY2t1cF0g ZGF0YWJhc2VzABAJAQWAAwAOAAAA1AcCAA8ACgAKACkAAAApAQEggAMADgAAANQHAgAPAAoADAAx AAAAMwEBCYABACEAAAAzNjM0MDhFNkNGNTE3RDQwQTg5MERCQTk2MDFCOEE5MAAeBwEDkAYA0AoA ADgAAAADACYAAAAAAAMANgAAAAAAQAA5ANnkoJWj88MBHgA9AAEAAAAFAAAAUkU6IAAAAAACAUcA AQAAAC0AAABjPXVzO2E9IDtwPUNBREVTSUdOO2w9Q0FEUzEtMDQwMjE1MDkxMjQ5Wi03NgAAAAAe AEkAAQAAABsAAABSZTogW0JveCBCYWNrdXBdIGRhdGFiYXNlcwAAQABOAAAxbrIT88MBHgBaAAEA AAAdAAAAYm94YmFja3VwLWFkbWluQGZsdWZmeS5jby51awAAAAACAVsAAQAAAFcAAAAAAAAAgSsf pL6jEBmdbgDdAQ9UAgAAAABib3hiYWNrdXAtYWRtaW5AZmx1ZmZ5LmNvLnVrAFNNVFAAYm94YmFj a3VwLWFkbWluQGZsdWZmeS5jby51awAAAgFcAAEAAAAiAAAAU01UUDpCT1hCQUNLVVAtQURNSU5A RkxVRkZZLkNPLlVLAAAAHgBdAAEAAAAMAAAAQmVuIFN1bW1lcnMAAgFeAAEAAAA6AAAAAAAAAIEr H6S+oxAZnW4A3QEPVAIAAAAAQmVuIFN1bW1lcnMAU01UUABiZW5AZmx1ZmZ5LmNvLnVrAAAAAgFf AAEAAAAWAAAAU01UUDpCRU5ARkxVRkZZLkNPLlVLAAAAHgBmAAEAAAAFAAAAU01UUAAAAAAeAGcA AQAAAB0AAABib3hiYWNrdXAtYWRtaW5AZmx1ZmZ5LmNvLnVrAAAAAB4AaAABAAAABQAAAFNNVFAA AAAAHgBpAAEAAAARAAAAYmVuQGZsdWZmeS5jby51awAAAAAeAHAAAQAAABcAAABbQm94IEJhY2t1 cF0gZGF0YWJhc2VzAAACAXEAAQAAABsAAAABw/MTv/WRdVucBSBHT468OH5ddD57ACP1asMAHgB0 AAEAAAAXAAAAYm94YmFja3VwQGZsdWZmeS5jby51awAAHgAaDAEAAAANAAAAQm8gUmFzbXVzc2Vu AAAAAB4AHQ4BAAAAFwAAAFtCb3ggQmFja3VwXSBkYXRhYmFzZXMAAAIBCRABAAAATQQAAEkEAABC BwAATFpGdUe3WGkDAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQey ESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAUDMLCQFk MzYWUAumIEkEIGcUICB0aGUgdHNhB4AgBJADYBQAIHsD8B1QIAdAAyAdUAnRIFkFoG1wAxAHkCwe kG7WZBzhE+B2HXB0CIELMcMKwAqAdG8gZhQgE9B5HpAgbgfRAZAFwAqwY/RrYR0QLiDkIOQc8AWg jHVsIAAgkHkgbSRQpm8dUQXAaHAKsCAG4LJ4H8BidQVAHPBkAiDWJx0yC4BrHUFhBUAeYHUnAHMg 5HMDcBQgJnFnex5EHVJvBCAhQSYAIutBqm4khmkBAGEEID8i+qxCbyL6IOQtLVJPBRD+ZwuAB0AF 0AeQHZAdEC1TVSDkRgNhOiVCYiKBdSBwLWFkbQuAQGaTCkABIHkuBaAudSagywIgJUBlE+BsZiSQ MgDmQgnwBgB1bQeAFAAg5B8GYAIwL5AGEAVAMi8xBDQvAdAwNCA1OpE0YCBQTSDkVG8vmWMwqzMF dWJqBZAzkVJqZS+QWywQeDJAL/Nd/yXwJuABoCsQB5Ag5ArjIzaGTwOgNCAgRmViM/DXNGEfwQVA MTSgNTuhLBCzB/ArEG11BBAyYXcDYMUOsDoi+j4gTyagMlHmLD4FPgZObwfgICUnwvcfNiSQJbBw JbExgSHQJQNALSAoSFA5NGAw1C83DiAvHDApHkQ+BwJwCfBCU0QgMy54NC1zAZEfkCLlP1dI8m9E cCB5CGAfMAORHRKfJ8hBYTISJmEEIDopPv2PLBY+YC7WP1cuLi9LsQcYIB+QOWEvbGliLxUFAHkF MG9MxS5vKMYuA2A5EisweA4wQ2C9L5B1H/ABEAuACYAgGCBzIXAYIG5jHXA+BiFBYGBFVlBfQwUg JMFG9S3iXw7AJ0s/TE9NVS+QWkkDoGZO0DfAaTGBYIhMJEM0cDYxJz2b+lQm0ScEIB6iIGAkQQRw /yAALVAnAVcRJDEoIiFBU2BHJpEoZ0RiU1NMWSFifnIKwAiQH7Eg5CWiSMFmrwtwWTEoQCfCaD/w Lhzg/CdtIeAkoB2ACHAdcFzR/UiUdyPjE+AlED0SHmFIMvcnbi/gXsJ2KCJe5E9BIUGTRtEFwHN5 RSBlbSLsfzIARtImACw7AZEfMCAAYvELgC9iYkUgBbAgxmUTFQDAax1wLUTAUkVM8EVBU0Ui+h/h ZF9lb/9me2f/aQ9qFS/zat8jCSYA/0bDR1MHcAMQCsEd5CtLVtG/JpAfsCtbCfAsPyNFX3W//3bP d5pbRS/GZvFcNFNgRSAXeK02TwqAaAJAcDov41NRRSBzLncKwB1gMFDpTaByZzFBL3miA4F8458L gAIQalAvxnSfCn2BEAAAAB4ANRABAAAAOwAAADwyQzRFMEE4N0M0RjE1MTRFODY2MjlGOTk3MjY1 NkUzOTM1OTc0NUBjYWRzMS5DQURlc2lnbi5kaz4AAB4ARxABAAAADwAAAG1lc3NhZ2UvcmZjODIy AAALAPIQAQAAAB8A8xABAAAAQgAAAFIARQAlADMAQQAgAFsAQgBvAHgAIABCAGEAYwBrAHUAcABd ACAAZABhAHQAYQBiAGEAcwBlAHMALgBFAE0ATAAAAAAACwD2EAAAAABAAAcw2eSglaPzwwFAAAgw o7Jb4qPzwwEDAN4/r28AAAMA8T8JAAAAHgD4PwEAAAANAAAAQm8gUmFzbXVzc2VuAAAAAAIB+T8B AAAAWwAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1DQURFU0lHTi9PVT1GSVJTVCBB RE1JTklTVFJBVElWRSBHUk9VUC9DTj1SRUNJUElFTlRTL0NOPUJSUgAAHgD6PwEAAAAVAAAAU3lz dGVtIEFkbWluaXN0cmF0b3IAAAAAAgH7PwEAAAAeAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAA AAAAAC4AAAADAP0/5AQAAAMAGUAAAAAAAwAaQAAAAAADAB1AAAAAAAMAHkAAAAAAHgAwQAEAAAAE AAAAQlJSAB4AMUABAAAABAAAAEJSUgAeADJAAQAAAB0AAABib3hiYWNrdXAtYWRtaW5AZmx1ZmZ5 LmNvLnVrAAAAAB4AM0ABAAAAEQAAAGJlbkBmbHVmZnkuY28udWsAAAAAHgA4QAEAAAAEAAAAQlJS AB4AOUABAAAAAgAAAC4AAAADAHZA/////wsAKQAAAAAACwAjAAAAAAADAAYQYpCmTgMABxCeAwAA AwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAAAElHRVRUSEVTQU1FRVJST1JTV0lUSEFMTFRIUkVF Q09NUElMRVMsQU5ESUhBVkVUUklFRFRPRkVUQ0hBTkVXVEFSUEFDS0FHRUlDT1VMRFRSWU1ZT1RI RVJIUFBBQk9YLEJVVEkAAAAAAgF/AAEAAAA7AAAAPDJDNEUwQTg3QzRGMTUxNEU4NjYyOUY5OTcy NjU2RTM5MzU5NzQ1QGNhZHMxLkNBRGVzaWduLmRrPgAAOsc= ------_=_NextPart_001_01C3F3A3.E24FC6F5-- From boxbackup at fluffy.co.uk Sun Feb 15 19:04:43 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Sun, 15 Feb 2004 19:04:43 +0000 Subject: [Box Backup] databases In-Reply-To: <2C4E0A87C4F1514E86629F9972656E39359745@cads1.CADesign.dk> References: <2C4E0A87C4F1514E86629F9972656E39359745@cads1.CADesign.dk> Message-ID: On 15 Feb 2004, at 09:10, Bo Rasmussen wrote: > I get the same errors with all three compiles, and I have tried > to fetch a new tar package. > > I could try my other hppa box, but I don't think that it is > something with the os to do. > > Any other ideas ? Do you get any results from grep EVP_CipherFinal_ex /usr/lib/* ? Ben From boxbackup at fluffy.co.uk Sun Feb 15 20:40:21 2004 From: boxbackup at fluffy.co.uk (Bo Rasmussen) Date: Sun, 15 Feb 2004 21:40:21 +0100 Subject: [Box Backup] databases Message-ID: <2C4E0A87C4F1514E86629F9972656E39359746@cads1.CADesign.dk> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F403.F7D927C5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hey, Here you go : nielsen4:vrou {101} grep EVP_CipherFinal_ex /usr/lib/* Binary file /usr/lib/libcrypto.a matches Binary file /usr/lib/libcrypto_p.a matches Bo -----Original Message----- From: boxbackup-admin at fluffy.co.uk on behalf of Ben Summers Sent: Sun 2/15/2004 8:04 PM To: boxbackup at fluffy.co.uk Subject: Re: [Box Backup] databases =20 On 15 Feb 2004, at 09:10, Bo Rasmussen wrote: > I get the same errors with all three compiles, and I have tried > to fetch a new tar package. > > I could try my other hppa box, but I don't think that it is > something with the os to do. > > Any other ideas ? Do you get any results from grep EVP_CipherFinal_ex /usr/lib/* ? Ben _______________________________________________ boxbackup mailing list boxbackup at fluffy.co.uk http://lists.warhead.org.uk/mailman/listinfo/boxbackup ------_=_NextPart_001_01C3F403.F7D927C5 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IiYUAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAGwAAAFJFOiBbQm94IEJhY2t1cF0g ZGF0YWJhc2VzABAJAQWAAwAOAAAA1AcCAA8AFQAoABUAAAA+AQEggAMADgAAANQHAgAPABUAKAAl AAAATgEBCYABACEAAABBRDA0ODA3NTA3REJBMDQzQjQxM0U0MUUwQ0VFMTA5NwAZBwEDkAYAnAkA ADgAAAADACYAAAAAAAMANgAAAAAAQAA5AGODIu4D9MMBHgA9AAEAAAAFAAAAUkU6IAAAAAACAUcA AQAAAC0AAABjPXVzO2E9IDtwPUNBREVTSUdOO2w9Q0FEUzEtMDQwMjE1MjA0MDM3Wi03OQAAAAAe AEkAAQAAABsAAABSZTogW0JveCBCYWNrdXBdIGRhdGFiYXNlcwAAQABOAIDXypH288MBHgBaAAEA AAAdAAAAYm94YmFja3VwLWFkbWluQGZsdWZmeS5jby51awAAAAACAVsAAQAAAFcAAAAAAAAAgSsf pL6jEBmdbgDdAQ9UAgAAAABib3hiYWNrdXAtYWRtaW5AZmx1ZmZ5LmNvLnVrAFNNVFAAYm94YmFj a3VwLWFkbWluQGZsdWZmeS5jby51awAAAgFcAAEAAAAiAAAAU01UUDpCT1hCQUNLVVAtQURNSU5A RkxVRkZZLkNPLlVLAAAAHgBdAAEAAAAMAAAAQmVuIFN1bW1lcnMAAgFeAAEAAAA6AAAAAAAAAIEr H6S+oxAZnW4A3QEPVAIAAAAAQmVuIFN1bW1lcnMAU01UUABiZW5AZmx1ZmZ5LmNvLnVrAAAAAgFf AAEAAAAWAAAAU01UUDpCRU5ARkxVRkZZLkNPLlVLAAAAHgBmAAEAAAAFAAAAU01UUAAAAAAeAGcA AQAAAB0AAABib3hiYWNrdXAtYWRtaW5AZmx1ZmZ5LmNvLnVrAAAAAB4AaAABAAAABQAAAFNNVFAA AAAAHgBpAAEAAAARAAAAYmVuQGZsdWZmeS5jby51awAAAAAeAHAAAQAAABcAAABbQm94IEJhY2t1 cF0gZGF0YWJhc2VzAAACAXEAAQAAABsAAAABw/P2nw6AzrmKX4dMRZqr6nvHt3HlAANTxRAAHgB0 AAEAAAAXAAAAYm94YmFja3VwQGZsdWZmeS5jby51awAAHgAaDAEAAAANAAAAQm8gUmFzbXVzc2Vu AAAAAB4AHQ4BAAAAFwAAAFtCb3ggQmFja3VwXSBkYXRhYmFzZXMAAAIBCRABAAAAGgMAABYDAAAa BQAATFpGdduY3o8DAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQey ESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAUDMLCQFk MzYWUAumIEj4ZXksCqIKhAqAHPAYIAQgeQhgIGdvIDoTHToDAGVsFBBuNDqGdgNgHmBcezEwAFAG fR5wGCBwIEVWUNRfQwUgaASQRguAB0ACXw7AIC91c3IvoGxpYi8qHTRCIeHwcnkgZgMQHiAiZyKx hQUAeQUwby5hIADAPnQT0AeQIw8kHyUgX3BbJU4l5W8dOh00LSriTx0FEGch4gXQB5BzYWeWZSrj HTRGA2E6IAbgBHhiANBrdXAtYWRkbQuAQGYKQAEgecIuBaAudWsgAiAtMLJlE+BsZi8AL5BCCfD5 BgB1bQeAFAAdNAZgAjAHLSAwIAOgMi8xNS9BAdAwNCA4OjIBUHJNHTRUby0pLjswlXVMYmoFkDEh UmUtIFuLKaAiQEItg10gZCWAvQGgYRQQJdUK4x12TwOgYTGwIEZlYjGAMfEswiAlgCAwOToggDlA NymgB/A28G0icB/BIHfHA2AOsB67PiBJHnAUILQgdCGgICvwB4AgBJC3A2AUADrAaTxwOVBsAyBL PHAJ0SAFoG1wJsFzWTlBbmQ8ARPgdh4gdP8IgQsxO7QlICagFCAT0DlQ/CBuB9EBkAXACrAtkCwB zi47lTuYBaB1bD8gP7C9JpBtJpA68CGhP1BwCrCzLTI5QGJ1BUA8EGQCIP4nPFILgC7wPHA5YT2A RnC7JdU78HMDcBQgReFnPWQ9PHJvBCBAgUVwQi5Bbk1D9mkBADbwID8dOkS/HpAeQzxBAHAmkBgg c0Ng/nQEIANSKcsBkSDfIe8i9e8dNEsLL+EdOl9TP1RPVRo/HTQtRyVhAxBHsiKwc3QXVi0z3wqA aAJAcDov4yKhV8BzLncKwE9QLeDqLgWwZy7RL1ciA4FaY5sLgAIQLy1HKc8KfV6QAAAeADUQAQAA ADsAAAA8MkM0RTBBODdDNEYxNTE0RTg2NjI5Rjk5NzI2NTZFMzkzNTk3NDZAY2FkczEuQ0FEZXNp Z24uZGs+AAAeAEcQAQAAAA8AAABtZXNzYWdlL3JmYzgyMgAACwDyEAEAAAAfAPMQAQAAAEIAAABS AEUAJQAzAEEAIABbAEIAbwB4ACAAQgBhAGMAawB1AHAAXQAgAGQAYQB0AGEAYgBhAHMAZQBzAC4A RQBNAEwAAAAAAAsA9hAAAAAAQAAHMA0hIO4D9MMBQAAIMHMT5fcD9MMBAwDeP69vAAADAPE/CQAA AB4A+D8BAAAADQAAAEJvIFJhc211c3NlbgAAAAACAfk/AQAAAFsAAAAAAAAA3KdAyMBCEBq0uQgA Ky/hggEAAAAAAAAAL089Q0FERVNJR04vT1U9RklSU1QgQURNSU5JU1RSQVRJVkUgR1JPVVAvQ049 UkVDSVBJRU5UUy9DTj1CUlIAAB4A+j8BAAAAFQAAAFN5c3RlbSBBZG1pbmlzdHJhdG9yAAAAAAIB +z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAuAAAAAwD9P+QEAAADABlAAAAA AAMAGkAAAAAAAwAdQAAAAAADAB5AAAAAAB4AMEABAAAABAAAAEJSUgAeADFAAQAAAAQAAABCUlIA HgAyQAEAAAAdAAAAYm94YmFja3VwLWFkbWluQGZsdWZmeS5jby51awAAAAAeADNAAQAAABEAAABi ZW5AZmx1ZmZ5LmNvLnVrAAAAAB4AOEABAAAABAAAAEJSUgAeADlAAQAAAAIAAAAuAAAAAwB2QP// //8LACkAAAAAAAsAIwAAAAAAAwAGELOI9A4DAAcQbwIAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAA AGUAAABIRVksSEVSRVlPVUdPOk5JRUxTRU40OlZST1UxMDFHUkVQRVZQQ0lQSEVSRklOQUxFWC9V U1IvTElCLypCSU5BUllGSUxFL1VTUi9MSUIvTElCQ1JZUFRPQU1BVENIRVNCSU5BAAAAAAIBfwAB AAAAOwAAADwyQzRFMEE4N0M0RjE1MTRFODY2MjlGOTk3MjY1NkUzOTM1OTc0NkBjYWRzMS5DQURl c2lnbi5kaz4AALpY ------_=_NextPart_001_01C3F403.F7D927C5-- From boxbackup at fluffy.co.uk Mon Feb 16 20:33:27 2004 From: boxbackup at fluffy.co.uk (Ben Lovett) Date: Mon, 16 Feb 2004 12:33:27 -0800 Subject: [Box Backup] databases In-Reply-To: <2C4E0A87C4F1514E86629F9972656E39359746@cads1.CADesign.dk> References: <2C4E0A87C4F1514E86629F9972656E39359746@cads1.CADesign.dk> Message-ID: <6020388D-60BF-11D8-9137-000A956A6972@tilderoot.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 15, 2004, at 12:40 PM, Bo Rasmussen wrote: > nielsen4:vrou {101} grep EVP_CipherFinal_ex /usr/lib/* > Binary file /usr/lib/libcrypto.a matches > Binary file /usr/lib/libcrypto_p.a matches Could it be that you boxbackup is depending on shared libraries? IIRC, hppa currently doesn't support shared libraries under OpenBSD. - --ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFAMSkaKFNEnl68h4URAheIAJ0Y0Asu07audObVTekiK5+TQZ9NlwCcDklO WjPz4G1VAgsrE+x5GRgmKeQ= =lPN6 -----END PGP SIGNATURE----- From boxbackup at fluffy.co.uk Mon Feb 16 20:45:38 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Mon, 16 Feb 2004 20:45:38 +0000 Subject: [Box Backup] databases In-Reply-To: <6020388D-60BF-11D8-9137-000A956A6972@tilderoot.com> References: <2C4E0A87C4F1514E86629F9972656E39359746@cads1.CADesign.dk> <6020388D-60BF-11D8-9137-000A956A6972@tilderoot.com> Message-ID: <13964C0E-60C1-11D8-9FB9-003065F8EC8E@fluffy.co.uk> On 16 Feb 2004, at 20:33, Ben Lovett wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Feb 15, 2004, at 12:40 PM, Bo Rasmussen wrote: >> nielsen4:vrou {101} grep EVP_CipherFinal_ex /usr/lib/* >> Binary file /usr/lib/libcrypto.a matches >> Binary file /usr/lib/libcrypto_p.a matches > > Could it be that you boxbackup is depending on shared libraries? IIRC, > hppa currently doesn't support shared libraries under OpenBSD. That was going to be my suggestion too. Looks like there's going to have to be an option to not require shared libraries. I do intend to eventually go to an autoconf setup (which is quite a bit of work) to make supporting all these platforms a bit easier. Originally I just targeted i386 OpenBSD and Darwin, and then when I decided to open source it, obviously a few more platforms were required. Ben From boxbackup at fluffy.co.uk Tue Feb 17 07:52:40 2004 From: boxbackup at fluffy.co.uk (Bo Rasmussen) Date: Tue, 17 Feb 2004 08:52:40 +0100 Subject: [Box Backup] databases Message-ID: <2C4E0A87C4F1514E86629F9972656E392EAFD5@cads1.CADesign.dk> > -----Original Message----- > From: boxbackup-admin at fluffy.co.uk=20 > [mailto:boxbackup-admin at fluffy.co.uk] On Behalf Of Ben Summers > I do intend to eventually go to an autoconf setup (which is=20 > quite a bit of work) to make supporting all these platforms a=20 > bit easier.=20 > Originally I just targeted i386 OpenBSD and Darwin, and then=20 > when I decided to open source it, obviously a few more=20 > platforms were required. Sounds nice Ben! Looking forward for this, and in the meantime I'll just try to make some other tests. Bo From boxbackup at fluffy.co.uk Thu Feb 19 13:47:45 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Thu, 19 Feb 2004 13:47:45 +0000 Subject: [Box Backup] Any last feature requests before 0.04? Message-ID: <3272965A-62E2-11D8-8C7B-003065F8EC8E@fluffy.co.uk> I've been adding a few features to Box Backup. I think I've got all I want for 0.04, and am now going to get it going on platforms other than OpenBSD, and chase down a little bug. But is there any other (relatively small) thing anyone really wants as soon as possible? Changes so far: * regex exclude (and exception to exclusions, as requested) * bbackupquery: alias 'ls', add help in program * config programs: excludes keys file if it might be backed up, validates config much much more to catch the common problems seen so far * improved flexibility with backup timing, including the ability to do snapshot backups (emulates more traditional backup systems) * bbackupctl program for controlling bbackupd daemon * bbstoreaccounts takes sizes in blocks, Mb or Gb with unit suffix * bug fixes * work around memory over-consumption issues with STL < v3 Basically, a few fixes, ease of use things, and the snapshot backups to make it easier for people to adopt over other systems. Ben From boxbackup at fluffy.co.uk Thu Feb 19 19:15:45 2004 From: boxbackup at fluffy.co.uk (Juan Vera) Date: Thu, 19 Feb 2004 16:15:45 -0300 Subject: [Box Backup] Any last feature requests before 0.04? In-Reply-To: <3272965A-62E2-11D8-8C7B-003065F8EC8E@fluffy.co.uk> References: <3272965A-62E2-11D8-8C7B-003065F8EC8E@fluffy.co.uk> Message-ID: <40350B61.3080100@coresecurity.com> Ben Summers wrote: > > I've been adding a few features to Box Backup. I think I've got all I > want for 0.04, and am now going to get it going on platforms other > than OpenBSD, and chase down a little bug. > > But is there any other (relatively small) thing anyone really wants as > soon as possible? Hello please include a Medium log level that won't print every sent/received packet but will keep the other details, thanks Juan From boxbackup at fluffy.co.uk Fri Feb 20 10:04:41 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Fri, 20 Feb 2004 10:04:41 +0000 Subject: [Box Backup] Any last feature requests before 0.04? In-Reply-To: <40350B61.3080100@coresecurity.com> References: <3272965A-62E2-11D8-8C7B-003065F8EC8E@fluffy.co.uk> <40350B61.3080100@coresecurity.com> Message-ID: <3317070B-638C-11D8-8895-003065F8EC8E@fluffy.co.uk> On 19 Feb 2004, at 19:15, Juan Vera wrote: > Ben Summers wrote: > >> >> I've been adding a few features to Box Backup. I think I've got all I >> want for 0.04, and am now going to get it going on platforms other >> than OpenBSD, and chase down a little bug. >> >> But is there any other (relatively small) thing anyone really wants >> as soon as possible? > > please include a Medium log level that won't print every > sent/received packet but will keep the other details, What details do you want in particular? ExtendedLogging = yes only dumps the commands it sends and receives. With it set to no, all the other information including logins and logouts is still logged. Ben From boxbackup at fluffy.co.uk Fri Feb 20 20:24:54 2004 From: boxbackup at fluffy.co.uk (Juan Vera) Date: Fri, 20 Feb 2004 17:24:54 -0300 Subject: [Box Backup] Any last feature requests before 0.04? In-Reply-To: <3317070B-638C-11D8-8895-003065F8EC8E@fluffy.co.uk> References: <3272965A-62E2-11D8-8C7B-003065F8EC8E@fluffy.co.uk> <40350B61.3080100@coresecurity.com> <3317070B-638C-11D8-8895-003065F8EC8E@fluffy.co.uk> Message-ID: <40366D16.9060500@coresecurity.com> What details do you want in particular? ExtendedLogging = yes only dumps the commands it sends and receives. With it set to no, all the other information including logins and logouts is still logged. > > Ben I'd like to have the whole details (for debugging purposes mostly) of ExtendedLogging w/o the transmit packets that make tail -f scroll too much :) thanks From boxbackup at fluffy.co.uk Sat Feb 21 17:09:18 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Sat, 21 Feb 2004 17:09:18 +0000 Subject: [Box Backup] Any last feature requests before 0.04? In-Reply-To: <40366D16.9060500@coresecurity.com> References: <3272965A-62E2-11D8-8C7B-003065F8EC8E@fluffy.co.uk> <40350B61.3080100@coresecurity.com> <3317070B-638C-11D8-8895-003065F8EC8E@fluffy.co.uk> <40366D16.9060500@coresecurity.com> Message-ID: On 20 Feb 2004, at 20:24, Juan Vera wrote: > What details do you want in particular? ExtendedLogging = yes only > dumps the commands it sends and receives. With it set to no, all the > other information including logins and logouts is still logged. > >> >> Ben > > I'd like to have the whole details (for debugging purposes > mostly) of ExtendedLogging w/o the transmit packets that > make tail -f scroll too much :) I'm still not sure I quite follow what you want. Perhaps you could send me an edited log which shows exactly what you want? If you're debugging, surely the full information would be more useful anyway? Ben From boxbackup at fluffy.co.uk Wed Feb 25 00:53:30 2004 From: boxbackup at fluffy.co.uk (Pascal Lalonde) Date: Tue, 24 Feb 2004 19:53:30 -0500 Subject: [Box Backup] Nice new web site Message-ID: <20040225005330.GA5152@plasma.doom.und> The website's new layout looks good. No bloat, functionnal, and with a nice, simple design. I like it... Pascal Lalonde From boxbackup at fluffy.co.uk Wed Feb 25 10:29:33 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Wed, 25 Feb 2004 10:29:33 +0000 Subject: [Box Backup] Nice new web site In-Reply-To: <20040225005330.GA5152@plasma.doom.und> References: <20040225005330.GA5152@plasma.doom.und> Message-ID: <80C6AD78-677D-11D8-962E-003065F8EC8E@fluffy.co.uk> On 25 Feb 2004, at 00:53, Pascal Lalonde wrote: > > The website's new layout looks good. No bloat, functionnal, and with > a nice, simple design. > > I like it... I'm very pleased with the way the 0.04 release is shaping up, so I thought the web site could do with a better look to project a more professional image. One of my web designer friends kindly produced that rather nice design for me! I was wondering how long it'd take someone to notice. A day isn't bad. Ben From boxbackup at fluffy.co.uk Thu Feb 26 12:02:56 2004 From: boxbackup at fluffy.co.uk (Eduardo Alvarenga) Date: Thu, 26 Feb 2004 09:02:56 -0300 (BRT) Subject: [Box Backup] Any last feature requests before 0.04? In-Reply-To: <3272965A-62E2-11D8-8C7B-003065F8EC8E@fluffy.co.uk> References: <3272965A-62E2-11D8-8C7B-003065F8EC8E@fluffy.co.uk> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 19 Feb 2004, Ben Summers wrote: > I've been adding a few features to Box Backup. I think I've got all I=20 > want for 0.04, and am now going to get it going on platforms other than= =20 > OpenBSD, and chase down a little bug. >=20 > But is there any other (relatively small) thing anyone really wants as=20 > soon as possible? >=20 > Changes so far: >=20 > * regex exclude (and exception to exclusions, as requested) > * bbackupquery: alias 'ls', add help in program > * config programs: excludes keys file if it might be backed up,=20 > validates config much much more to catch the common problems seen so=20 > far > * improved flexibility with backup timing, including the ability to do=20 > snapshot backups (emulates more traditional backup systems) > * bbackupctl program for controlling bbackupd daemon > * bbstoreaccounts takes sizes in blocks, Mb or Gb with unit suffix > * bug fixes > * work around memory over-consumption issues with STL < v3 How about *single* file backup instead of *directories* ? Remember? Best Regards, --=20 Eduardo A. Alvarenga=20 Analista de Suporte Centro Estrat=E9gico Integrado / SEGUP-PA (91) 259-0555 / 8116-0036 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (OpenBSD) iD8DBQFAPeBypKK2uJoGDlMRAsxLAJ92TD8gs9kKxntlVJAazYnGep/62ACePPTq Ei5imodH3g2/mqoVsisVF24=3D =3DK8Nm -----END PGP SIGNATURE----- From boxbackup at fluffy.co.uk Thu Feb 26 12:13:50 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Thu, 26 Feb 2004 12:13:50 +0000 Subject: [Box Backup] Any last feature requests before 0.04? In-Reply-To: References: <3272965A-62E2-11D8-8C7B-003065F8EC8E@fluffy.co.uk> Message-ID: <3C919595-6855-11D8-BF62-003065F8EC8E@fluffy.co.uk> On 26 Feb 2004, at 12:02, Eduardo Alvarenga wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thu, 19 Feb 2004, Ben Summers wrote: > >> I've been adding a few features to Box Backup. I think I've got all I >> want for 0.04, and am now going to get it going on platforms other >> than >> OpenBSD, and chase down a little bug. >> >> But is there any other (relatively small) thing anyone really wants as >> soon as possible? >> >> Changes so far: >> >> * regex exclude (and exception to exclusions, as requested) >> * bbackupquery: alias 'ls', add help in program >> * config programs: excludes keys file if it might be backed up, >> validates config much much more to catch the common problems seen so >> far >> * improved flexibility with backup timing, including the ability to do >> snapshot backups (emulates more traditional backup systems) >> * bbackupctl program for controlling bbackupd daemon >> * bbstoreaccounts takes sizes in blocks, Mb or Gb with unit suffix >> * bug fixes >> * work around memory over-consumption issues with STL < v3 > > How about *single* file backup instead of *directories* ? Remember? ExcludeFilesRegex = . AlwaysIncludeFile = /home/user/some-important-file There will be a "preview" of a version which supports this available for download this afternoon. Ben From boxbackup at fluffy.co.uk Thu Feb 26 12:59:01 2004 From: boxbackup at fluffy.co.uk (Eduardo Alvarenga) Date: Thu, 26 Feb 2004 09:59:01 -0300 (BRT) Subject: [Box Backup] Any last feature requests before 0.04? In-Reply-To: <3C919595-6855-11D8-BF62-003065F8EC8E@fluffy.co.uk> References: <3272965A-62E2-11D8-8C7B-003065F8EC8E@fluffy.co.uk> <3C919595-6855-11D8-BF62-003065F8EC8E@fluffy.co.uk> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 26 Feb 2004, Ben Summers wrote: > > How about *single* file backup instead of *directories* ? Remember? >=20 > ExcludeFilesRegex =3D . > AlwaysIncludeFile =3D /home/user/some-important-file >=20 > There will be a "preview" of a version which supports this available=20 > for download this afternoon. Will it be a single addon to 0.03 or a pre-0.04 version? Best Regards, --=20 Eduardo A. Alvarenga=20 Analista de Suporte Centro Estrat=E9gico Integrado / SEGUP-PA (91) 259-0555 / 8116-0036 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (OpenBSD) iD8DBQFAPe2XpKK2uJoGDlMRAo0bAJ4uV12vj5wDi+j6kS2lxKrxnlabvwCgsdsv vyAn+n2hRuhx8NER4w372ak=3D =3DcxpW -----END PGP SIGNATURE----- From boxbackup at fluffy.co.uk Thu Feb 26 13:36:44 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Thu, 26 Feb 2004 13:36:44 +0000 Subject: [Box Backup] Pre-0.04 version -- please use! Message-ID: Hi, I will shortly be doing a 0.04 release, and I'm very pleased with the improvements I've made. However, I would like to try it out with a few people, and wait about a week before doing a public release. I would be very grateful if you could download and install this new version. It shouldn't take too long, and has some important bug fixes and handy new features (see below). http://www.fluffy.co.uk/boxbackup/bin/boxbackup-0.03PLUS.tgz The configuration for bbackupd has changed a little, and so is not compatible with old configuration files. Also, I've much improved the configuration scripts, so I'd like them to be tested too (mainly by catching the common problems and telling you about them.) The best way of upgrading is to * Kill old running versions * Compile and install * Move the /etc/box directory out of the way * Run the *-config scripts as appropriate * From the old /etc/box/* directories, copy the key and certificate files. (basically the subdirectories can be copied back, but bbackupd has a new file in there) * Restart the new daemons. bbackupd-config has a new parameter, it's now bbackupd-config config-dir backup-mode account-num server-hostname working-dir \ backup-dir [more backup directories] backup-mode is either 'lazy' or 'snapshot'. Choose 'lazy' for the current behaviour. Choose snapshot if you would like to use the new bbackupctl program as a cron job to say exactly when you want to take a snapshot of your file system. (The first mode is good for collections of documents, the second is good for backing up servers.) Thanks for all your support. Ben * regex exclude (with exception to exclusions -- see generated bbackupd.conf for more instructions) * work around memory issues with STL < v3 * bbackupquery, alias 'ls', help in program * config programs, excludes keys file if it might be backed up, validates config more * bug fixes + code clean up * improved flexibility with backup timing, including the ability to do snapshot backups * bbackupctl program for controlling bbackupd daemon * bbstoreaccounts takes sizes in blocks, Mb or Gb with unit suffix * start of sync times recorded in bbackupd working dir ("last_sync_start" and "last_sync_end") * bbackupquery compares check last mod time to see if this explains a difference * script run to alert administator that store is full From boxbackup at fluffy.co.uk Thu Feb 26 13:43:12 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Thu, 26 Feb 2004 13:43:12 +0000 Subject: [Box Backup] License Message-ID: Hi, I'm considering moving to a plain BSD license. I believe the current one is putting people off, and it's certainly preventing me from getting an account on sourceforge and all the publicity that entails. The reason I'm not using one now is that I am trying to earn a living out of this software. By preventing others from using it to provide commercial services, I am protecting one particular option for myself. However, in the long term I don't need this, and it's beneficial to my project to have lots of people using it. And I'm not sure how likely anyone would be to pick it up and use it on a huge scale -- it would need some extra tools I'm developing to do that easily. I would appreciate any thoughts on the matter. I think the software is now almost ready for a wider audience, and I'd like to get it out there. Thanks, Ben From boxbackup at fluffy.co.uk Sun Feb 29 02:11:50 2004 From: boxbackup at fluffy.co.uk (Pascal Lalonde) Date: Sat, 28 Feb 2004 21:11:50 -0500 Subject: [Box Backup] Multiple machines on the same account Message-ID: <20040229021150.GA14941@plasma.doom.und> Is it safe to use the same account to store data for multiple machines? Must I give different names for backup locations? Can they all use the same client certificate (In fact, I think they must) ? For example, on host A: BackupLocations { home-A { Path = /home } } And on host B: BackupLocations { home-B { Path = /home } } The reason for this is that I have a few friends for whom I will backup data. I want to set quotas for each of them, but they may have more than one machine to backup. For example, if I set a quota of 5G for Bob, and he decides to backup his 3 machines, I don't want him to exceed a total of 5G of data, without having to care how much each machine uses. Am I safe with the above setup? Can the server handle multiple connections on the same account? Also I noticed a few minor things which could need improvement/corrections: - In bbackupquery, when you type the help command, the "ls" command does not get shown. - The output of a few "help " could be formatted to fit nicely on a 80 characters wide terminal. For example, "help get". - "help get" misses a newline on the first line: get []get -i ^^ - Same goes for "help compare". - In the documentation, maybe add something about servers behind a firewall (which are not directly on the net, via NAT). I had to modify the /etc/box/bbstored.conf file so the ListenAddress points to the IP of the server on the LAN, even if the hostname used by the clients is in fact the hostname of the firewall. I issued the bbstored-config command with the hostname of the firewall (as instructed on the website). I figured it out by looking for exception 3/16 in ServerException.h (BindError), by it might be good to mention it. And should we exclude /var/bbackupd from our backups? Is there a point to back it up? Thanks, Pascal Lalonde From boxbackup at fluffy.co.uk Sun Feb 29 03:40:13 2004 From: boxbackup at fluffy.co.uk (Pascal Lalonde) Date: Sat, 28 Feb 2004 22:40:13 -0500 Subject: [Box Backup] License In-Reply-To: References: Message-ID: <20040229034013.GA9391@plasma.doom.und> Of course I'd prefer it to be under a BSD license. Where I work my superiors would be glad to use BoxBackup to backup our customer's data. The thing is, we are not a large company, and we need to get something out of it to be able to maintain the extra servers. Our big customers don't really need it, since they have well established backup procedures with tape drives (still, I wouldn't be surprised to discover a certain lack of discipline). But smaller offices have poor, or almost non-existent backup procedures, can't afford it, and we can't afford going there each week with portable harddrives to take a snapshot of their data. If your program gets adopted by larger companies, maybe you'll get funding to add features, port it to other platforms, make it more stable, more scalable, whatever. Like you say, putting it under a BSD license would certainly reassure a lot of people, and you would get a lot more users. A lot of bugs will be discovered and fixed, and maybe people will try test its security to find flaws in the design. The product will surely benefit from this. Just an advice though: be sure to add more comprehensive error reporting before you do this, because your mailbox will be flooded from user's questions ;-) On the downside, you lose the exclusivity. But those who had the idea of charging for backups will probably turn to other ideas, like rsync over SSH, even if it's not quite the same. So in the end, I don't think you would gain much more by leaving the license as it is. It may seem like I'm just waiting for you to put it under a BSD license so we can get rich by charging for backups, but I'm not really that type. And the price must be under what it costs for tape drives and cartriges. And using BoxBackup means the customer needs a reasonable bandwidth, and preferably no upload quota (my ISP charges an extra 30$ CAN to remove the 5Gb limit, and raise the upload rate from 360Kbits to 640Kbits). The monthly fee would have to be quite low, because most customers are quick on x12 multiplications. I'm not a finance expert, but I don't think much profit could be made by charging for backups, unless one has many, many customers. So yes, I'd like BoxBackup to be put under a BSD license, but remember that BoxBackup is yours, and that you are free to do as you will. That's my opinion. Pascal Lalonde From boxbackup at fluffy.co.uk Sun Feb 29 09:21:11 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Sun, 29 Feb 2004 09:21:11 +0000 Subject: [Box Backup] Multiple machines on the same account In-Reply-To: <20040229021150.GA14941@plasma.doom.und> References: <20040229021150.GA14941@plasma.doom.und> Message-ID: <9D2D74B6-6A98-11D8-ADFE-003065F8EC8E@fluffy.co.uk> On 29 Feb 2004, at 02:11, Pascal Lalonde wrote: > > Is it safe to use the same account to store data for multiple machines? > Must I give different names for backup locations? Can they all use the > same client certificate (In fact, I think they must) ? > > For example, on host A: > BackupLocations > { > home-A > { > Path = /home > } > } > > And on host B: > BackupLocations > { > home-B > { > Path = /home > } > } > > > The reason for this is that I have a few friends for whom I will backup > data. I want to set quotas for each of them, but they may have more > than > one machine to backup. For example, if I set a quota of 5G for Bob, and > he decides to backup his 3 machines, I don't want him to exceed a total > of 5G of data, without having to care how much each machine uses. > > Am I safe with the above setup? Well, you're safe, but not efficient. (The answers to the original questions are: Yes (but very inefficient), Yes, Yes (they must)) Whenever the client detects that someone else has modified the store, it does a full scan of the account, downloading listings for every directory. This isn't particularly good, and should be avoided. It's just not designed for this -- you'll need to create multiple accounts and ask bob how the 5Gb should be split up. > Can the server handle multiple > connections on the same account? Yes, as long as only one is read/write. So the store can be updated while you're using bbackupquery. > > > Also I noticed a few minor things which could need > improvement/corrections: > > - In bbackupquery, when you type the help command, the "ls" command > does > not get shown. > - The output of a few "help " could be formatted to fit nicely > on a 80 characters wide terminal. For example, "help get". > - "help get" misses a newline on the first line: > get []get -i > > ^^ > - Same goes for "help compare". > > - In the documentation, maybe add something about servers behind a > firewall (which are not directly on the net, via NAT). I had to > modify the /etc/box/bbstored.conf file so the ListenAddress points to > the IP of the server on the LAN, even if the hostname used by the > clients is in fact the hostname of the firewall. > I issued the bbstored-config command with the hostname of the > firewall (as instructed on the website). > I figured it out by looking for exception 3/16 in ServerException.h > (BindError), by it might be good to mention it. I'll get these all sorted -- extremely helpful of you, thanks! > > And should we exclude /var/bbackupd from our backups? Is there a point > to back it up? Exclude it. Backing it up isn't useful, and it'll be changed after every run so it's just going to waste bandwidth. Of course, /etc/box/bbackupd should be backed up onto traditional media multiple times, and this media carefully looked after! Ben From boxbackup at fluffy.co.uk Sun Feb 29 12:43:59 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Sun, 29 Feb 2004 12:43:59 +0000 Subject: [Box Backup] License In-Reply-To: <20040229034013.GA9391@plasma.doom.und> References: <20040229034013.GA9391@plasma.doom.und> Message-ID: I think I'm tending towards a BSD license. Maybe with enlarging the advertising clause to request a link to the web site? As you point out, another good argument for it is that if people start using it, at least they're going to be using mine rather than another system. Which gives me opportunities that I wouldn't have otherwise. Ben On 29 Feb 2004, at 03:40, Pascal Lalonde wrote: > > Of course I'd prefer it to be under a BSD license. Where I work > my superiors would be glad to use BoxBackup to backup our customer's > data. The thing is, we are not a large company, and we need to get > something out of it to be able to maintain the extra servers. > Our big customers don't really need it, since they have well > established > backup procedures with tape drives (still, I wouldn't be surprised to > discover a certain lack of discipline). But smaller offices have poor, > or almost non-existent backup procedures, can't afford it, and we > can't afford going there each week with portable harddrives to take a > snapshot of their data. > > If your program gets adopted by larger companies, maybe you'll get > funding to add features, port it to other platforms, make it more > stable, more scalable, whatever. > > Like you say, putting it under a BSD license would certainly reassure a > lot of people, and you would get a lot more users. A lot of bugs will > be > discovered and fixed, and maybe people will try test its security to > find > flaws in the design. The product will surely benefit from this. > Just an advice though: be sure to add more comprehensive error > reporting > before you do this, because your mailbox will be flooded from user's > questions ;-) > > On the downside, you lose the exclusivity. But those who had the idea > of > charging for backups will probably turn to other ideas, like rsync over > SSH, even if it's not quite the same. So in the end, I don't think you > would gain much more by leaving the license as it is. > > It may seem like I'm just waiting for you to put it under a BSD license > so we can get rich by charging for backups, but I'm not really that > type. And the price must be under what it costs for tape drives and > cartriges. And using BoxBackup means the customer needs a reasonable > bandwidth, and preferably no upload quota (my ISP charges an extra 30$ > CAN to remove the 5Gb limit, and raise the upload rate from 360Kbits to > 640Kbits). The monthly fee would have to be quite low, because most > customers are quick on x12 multiplications. I'm not a finance expert, > but I don't think much profit could be made by charging for backups, > unless one has many, many customers. > > So yes, I'd like BoxBackup to be put under a BSD license, but remember > that BoxBackup is yours, and that you are free to do as you will. > That's my opinion. > > Pascal Lalonde > > _______________________________________________ > boxbackup mailing list > boxbackup at fluffy.co.uk > http://lists.warhead.org.uk/mailman/listinfo/boxbackup > From boxbackup at fluffy.co.uk Sun Feb 29 17:09:30 2004 From: boxbackup at fluffy.co.uk (Pascal Lalonde) Date: Sun, 29 Feb 2004 12:09:30 -0500 Subject: [Box Backup] License In-Reply-To: References: <20040229034013.GA9391@plasma.doom.und> Message-ID: <20040229170930.GA27242@plasma.doom.und> On Sun, Feb 29, 2004 at 12:43:59PM +0000, Ben Summers wrote: > > I think I'm tending towards a BSD license. Maybe with enlarging the > advertising clause to request a link to the web site? > I really think you should stick with a standard BSD license. People generally don't like being compelled in any way by a license. But you could ask/suggest people before downloading your software that they put a banner on their website, a mention in their product, stuff like that. Of course not everyone will do it, but still. A lot of people know about RSync even if you don't see "Sync'ed with RSync" on their website. Like you said, just putting it on sourceforge might be something in itself. I think I know what worries you: Companies could start using BoxBackup and keep it a secret, so that people don't know about the product, thus getting a limited exclusivity. Then if you ask "could you put a link on your page please?", their only anwser is: "Ha, it is *you* who decided to put it under that license". It pisses me off too. These people are truly not helping opensource software to evolve. They only profit from it. But, deep down, I still don't think adding an advertisement clause would be the right thing to do. I, for sure, will do everything I can to convince my superiors to put that link on the webpage (if I'm lucky, that might even be easy). By the way, are you planning to do small banners, like those "Powered by ..." or "Just VIM it!", that we could put on our websites ? I was thinking, maybe something like "With BoxBackup, sleep peacefully". English is not first language, and I have a hard time finding the exact words for what I mean, and I fear this one can be interpreted as "With BoxBackup, rest in peace" ;-) What I truly mean is: "Dormez tranquille avec BoxBackup" meaning that with BoxBackup you can go to sleep without worrying about your data. Maybe "Sleep easy with BoxBackup" ? I'd put it right under my "Powered by OpenBSD"... Pascal Lalonde From boxbackup at fluffy.co.uk Sun Feb 29 19:30:15 2004 From: boxbackup at fluffy.co.uk (Ben Summers) Date: Sun, 29 Feb 2004 19:30:15 +0000 Subject: [Box Backup] License In-Reply-To: <20040229170930.GA27242@plasma.doom.und> References: <20040229034013.GA9391@plasma.doom.und> <20040229170930.GA27242@plasma.doom.und> Message-ID: On 29 Feb 2004, at 17:09, Pascal Lalonde wrote: > On Sun, Feb 29, 2004 at 12:43:59PM +0000, Ben Summers wrote: >> >> I think I'm tending towards a BSD license. Maybe with enlarging the >> advertising clause to request a link to the web site? >> > I really think you should stick with a standard BSD license. People > generally don't like being compelled in any way by a license. But you > could ask/suggest people before downloading your software that they put > a banner on their website, a mention in their product, stuff like that. > Of course not everyone will do it, but still. A lot of people know > about > RSync even if you don't see "Sync'ed with RSync" on their website. Like > you said, just putting it on sourceforge might be something in itself. > > I think I know what worries you: > Companies could start using BoxBackup and keep it a secret, so that > people don't know about the product, thus getting a limited > exclusivity. > Then if you ask "could you put a link on your page please?", their only > anwser is: "Ha, it is *you* who decided to put it under that license". > It pisses me off too. These people are truly not helping opensource > software to evolve. They only profit from it. But, deep down, I still > don't think adding an advertisement clause would be the right thing to > do. It was more making it easier to find people offering stuff based upon it by using Google. > > I, for sure, will do everything I can to convince my superiors to put > that link on the webpage (if I'm lucky, that might even be easy). > > By the way, are you planning to do small banners, like those "Powered > by ..." or "Just VIM it!", that we could put on our websites ? > I was thinking, maybe something like "With BoxBackup, sleep > peacefully". > English is not first language, and I have a hard time finding the exact > words for what I mean, and I fear this one can be interpreted as > "With BoxBackup, rest in peace" ;-) What I truly mean is: > "Dormez tranquille avec BoxBackup" > meaning that with BoxBackup you can go to sleep without worrying about > your data. Maybe "Sleep easy with BoxBackup" ? > I'd put it right under my "Powered by OpenBSD"... Actually I was want commercial backup services to put the link on their web sites. However... defining a commercial backup service may be tricky, so I might as well not bother. Ben