Re: strftime's %c warning?
2008/10/9 Sean C. Farley [EMAIL PROTECTED]: On Wed, 8 Oct 2008, Ivan Voras wrote: str.c: In function 'ltime': str.c:141: warning: '%c' yields only last 2 digits of year in some locales on non-BSD systems *** Error code 1 Since the code I'm developing is definitely BSD-only (patch to pkg_* infrastructure), should I: a) stop using locale-based %c and choose my own date/time format b) remove WFORMAT from the Makefile? The same warning/error is generated by %x and %X, and %+ described in the strftime man page isn't recognized. You are hitting a gcc builtin. Have you tried adding -fno-builtin-strftime? The code im working on is part of FreeBSD and uses FreeBSD's infrastructure for building. I can avoid the warning by defining WFORMAT to be 0 but I don't know how to add -fno-builtin-strftime except directly into CFLAGS. I don't think the original author (John Hubbard) is around anymore so the question is - should I just remove WFPORMAT from this Makefile? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strftime's %c warning?
On Wed, Oct 08, 2008 at 10:20:00PM +0200, Ivan Voras wrote: I'm trying to use the %c formatter in strftime(3), documented as: %cis replaced by national representation of time and date. ... which looks useful, except that in code in which WFORMAT is defined as 1 I get this error: str.c: In function 'ltime': str.c:141: warning: '%c' yields only last 2 digits of year in some locales on non-BSD systems *** Error code 1 Since the code I'm developing is definitely BSD-only (patch to pkg_* infrastructure), should I: a) stop using locale-based %c and choose my own date/time format b) remove WFORMAT from the Makefile? The same warning/error is generated by %x and %X, and %+ described in the strftime man page isn't recognized. Yes. In FreeBSD 4.x, gcc was patched not to warn about these, so compiling with -Werror was possible even when using this. Since FreeBSD 5.x, this patch wasn't applied anymore. If you only want it to compile on your own system with -Werror, you can use this patch (and probably adapt it to %c, %x and %X as well): http://www.stack.nl/~marcolz/FreeBSD/gcc-strftime-format-freebsd7.patch.txt Marc signature.asc Description: Digital signature
Re: Sockstress
This is the wrong mailing list, you should send this to the -security list. By the way, this kind of attack isn't really new (as far as I can tell from the few information that have been made public so far). One way to mitigate it is to limit the number of open connections per remote IP address; you can easily do that with PF or IPFW (limit option). Best regards Oliver Lukasz Jaroszewski [EMAIL PROTECTED] wrote: Hi, I am wondering about sockstres informations recently published. I cant really figure what new they could found. Do we have anything to worry about? ;-) http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1332898,00.html ``(...)Sockstress computes and stores so-called client-side SYN cookies and enables Lee and Louis to specify a destination port and IP address. The method allows them to complete the TCP handshake without having to store any values, which takes time and resources. We can then say that we want to establish X number of TCP connections on that address and that we want to use this attack type, and it does it, Lee said.(...)'' ``(...)Lee said that when and _if_ specific vendors develop workarounds for the issues, they will release details of those issues.(...)'' Was FreeBSD team contacted? ;) -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Unix gives you just enough rope to hang yourself -- and then a couple of more feet, just to be sure. -- Eric Allman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: continuous backup solution for FreeBSD
Evren Yurtesen wrote: Shaun Amott wrote: On Tue, Oct 07, 2008 at 12:31:58AM +0300, Evren Yurtesen wrote: so FreeBSD could be supported also. As you can imagine, it is not only important that data can be restored when a box hardware failure etc. it is also important that data can be restored if deleted by accidents etc. While traditional backup programs provide this functionality, you cant really go back to 10 min or 1h ago, often they take daily backups and have to scan whole filesystem for changed files every time the backup is taken which stresses out the systems. This can (more or less) be achieved with snapshots: you can cheaply maintain old versions of the file system, and mount an old snapshot at any time. Hourly is about as fine-grained as you can expect though. The documentation says one cant do more than 20 snapshots. http://www.freebsd.org/doc/en/books/handbook/snapshots.html I wouldn't use UFS snapshots for this purpose. They have a few well-known disadvantages. However, ZFS snapshots should work very well for this. They're not limited to 20, and you can create them very quickly and with low overhead. You could create a new snapshot every 5 minutes if you want. Then you can use the zfs send command to produce a stream that contains the incremental differences between the snapshot and the previous snapshot, i.e. the stream represents the changes to the filesystem within the past five minutes (or whatever snapshot interval you choose). You can store that stream in a file, on backup medium, or send it with ssh to a different continent. Every once in a while you should make a full backup from a snapshot, of course. Basically it works like any other incremental backup mechanism, except that you can make the time interval between incremental backups very small (like five minutes in the above example), so you get a nearly continous backup solution. By the way, if you accidentally deleted something, you can of course simply copy it back from a snapshot. You can even revert the whole file system to a previous snapshot using the zfs rollback command. This is like going back in time. There is no need to touch your backups for that. These features are readily available right now on FreeBSD. You don't have to code anything. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: continuous backup solution for FreeBSD
Zaphod Beeblebrox wrote: Oliver Fromme wrote: However, ZFS does exist on FreeBSD, and I think it wouldn't be impossible to add similar features to ZFS. Possibly even as a ZFS module? This might be something better addressed at the ZFS project level --- but the next question is: does FreeBSD support ZFS modules? I'm sorry I don't know. But also see my other reply regarding ZFS snapshots ans zfs send. Another possibility would be to extend gjournal by adding time stamps to journal transactions and a possibility to feed the journal to a pipe, socket or whatever. And of course a client-side implementation that does something useful with the journal stream. This might even be a good SoC project. Now this interests me. Firstly, I thought that gjournal might only be responsible for the meta-data (but I'm happy to be wrong on this point). Nope, gjournal handles _all_ data, i.e. meta data and file contents. Secondly, is it a) sufficient and b) efficient to attempt to time-travel UFS with the gjournal log? I almost don't dare to mention DragonFly BSD again, but they do have a UFS journaling implementation that does exactly that: http://leaf.dragonflybsd.org/cgi/web-man?command=mountctl http://leaf.dragonflybsd.org/cgi/web-man?command=jscan However, I think the implementation was abandoned because it was obsoleted by the development of the HAMMER file system. But the basic functionality is there and works. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd IRIX is about as stable as a one-legged drunk with hypothermia in a four-hundred mile per hour wind, balancing on a banana peel on a greased cookie sheet -- when someone throws him an elephant with bad breath and a worse temper. -- Ralf Hildebrandt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Sockstress
Hi, I am wondering about sockstres informations recently published. I cant really figure what new they could found. Do we have anything to worry about? ;-) http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1332898,00.html ``(...)Sockstress computes and stores so-called client-side SYN cookies and enables Lee and Louis to specify a destination port and IP address. The method allows them to complete the TCP handshake without having to store any values, which takes time and resources. We can then say that we want to establish X number of TCP connections on that address and that we want to use this attack type, and it does it, Lee said.(...)'' ``(...)Lee said that when and _if_ specific vendors develop workarounds for the issues, they will release details of those issues.(...)'' Was FreeBSD team contacted? ;) -- Regards/Pozdrawiam LVJ -- They must find it difficult, those that take authority as truth, instead of truth as the authority ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
setkey panic freebsd7
i wonder people ran into similar issue on setkey with freebsd7 that panic at ~/crypto/sha1.c:263 within sha1_result() digest[0] = ctxt-h.b8[3]; digest[1] = ctxt-h.b8[2]; on the following sadb add with setkey: add 192.168.0.101 192.168.0.110 esp-old 0x10001 -m any -E des-cbc 12345678 -A keyed-sha1 12345678123456781234 thanks in advance on any hints. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: continuous backup solution for FreeBSD
Go here: http://forums.mysql.com/read.php?28,197644,197644 There are a ton of ways to maintain mysql backups without having to replay the entire log. Google some keywords. With regards to solutions based on filesystem snapshots, such as partial log replaying (snapshot + new-log, then replay from snapshot after crash), HAMMER and ZFS are your only real choices in the BSD world. UFS snapshots have all sorts of issues that make them unsuitable. Block level snapshots are unreliable. When interacting with a high level program for crash recovery purposes you really want to use a filesystem's native snapshot capability (e.g. HAMMER or ZFS. UFS's isn't good enough). You do not need to explicitly backup the filesystem to other media. That is, you of course still make such backups, but they would only be used in case of a catastrophic loss of the production filesystem, not for simple crash recovery which can be done from the same-media snapshots. -- In anycase, HAMMER has two native backup solutions. Both are easy to use. (1) Just use cpdup. This works nicely as the source filesystem, if HAMMER, can be snapshotted, and then used as a stable cpdup source. cpdup to the target and let HAMMER manage the history for you. No hardlink trick needed or anything like that. Use HAMMER's snapshots on the target to determine what history you want to retain. Advantages: Extremely convenient, target storage is reasonably efficient. Great if sources are mixed filesystem types. Disadvantages: Runs cpdup so you are scanning the directory hierarchy on both. Inode numbers not retained, so not suitable for fallback. (this sort of methodology can be used w/ ZFS too). (2) For HAMMER-to-HAMMER you can use HAMMER's native mirroring. Simply create a PFS (pseudo hammer filesystem) slave on the target, which takes 2 seconds, then use the 'hammer mirror-copy' or 'hammer mirror-stream' directives (which can take remote host specifications and will run ssh) to mirror from source to target. HAMMER's mirroring is incremental from the protocol right down to the media accesses. No pre-scan occurs is needed. Advantages: Provides bandwidth-controlled incremental streaming, near-realtime operation (30-60 second lag though finer-grained operation is possible). Extremely robust (can be ^C'd and restarted, or left offline for long periods of time, etc). Mirrors all fine-grained history on source and can be re-pruned on the target to the desired interval. Has little effect on production machines (no queues means backups can't feed-back and effect the performance of the production box). Mirrors inode numbers etc. Mirroring target can become a new master in a pinch (but can't be made a slave again, sorry). Should serve the same NFS fsid, etc. Disadvantages: Must mirror the entire PFS, only works between HAMMER filesystems. Near-real-time (30-60 second lag) is not real time, but it's probably close enough. (ZFS has a way to do something similar but I do not know what the various advantages or disadvantages of using the feature are). DragonFly also has real-time journaling at the VFS layer, which is not HAMMER-specific, but it requires queuing and isn't really suitable on a production environment for off-machine copying because the queue can fill up and block the filesystem. HAMMER's mirroring is far more robust. -Matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD support for HP DL180/G5
Does anyone have experience running FreeBSD 6.x and 7.x on an HP DL180/G5? The company I work for is looking to get a number of these to be put in production. Your general impressions would be a good start. Josef -- Josef Grosch | Another day closer to a | FreeBSD 6.3 [EMAIL PROTECTED] | Micro$oft free world | Berkeley, Ca. pgpnMvf1U1n1F.pgp Description: PGP signature
Re: setkey panic freebsd7
Hi. On Thu, Oct 09, 2008 at 08:46:32AM -0700, alan yang wrote: i wonder people ran into similar issue on setkey with freebsd7 that panic at ~/crypto/sha1.c:263 within sha1_result() digest[0] = ctxt-h.b8[3]; digest[1] = ctxt-h.b8[2]; on the following sadb add with setkey: add 192.168.0.101 192.168.0.110 esp-old 0x10001 -m any -E des-cbc 12345678 -A keyed-sha1 12345678123456781234 thanks in advance on any hints. I guess most people just don't use static SAs anymore :-) Can you reproduce the bug ? Are you using /sbin/setkey (provided by FreeBSD), /usr/local/sbin/setkey (provided by ipsec-tools), or does it crash with both ? If you can reproduce it, please fill in a PR, Bjoern or I will take it. Anyways, I'll have a look asap at that part of the code, to see if I can find something. Any extra information on how to reproduce the bug is welcome ! :-) Yvan. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD support for HP DL180/G5
HP produces pretty good boxes and historically I have been able to get them working without any troubles. However I would say DL180 is a pretty non customizable box. The hardware works perfectly with FreeBSD 7.0. I didnt try it with 6.3, so cant comment on that. However I would say DL380 is a better off. The main advantage of DL3xx boxes are there is a lot of room to play with add-on cards. Also not all the latest and greatest processors are available with DL1xx family of servers. Also make sure that you go for an external RAID controller like 3ware or Areca. I prefer Areca more :-D. The HP RAID controller cant take the beating I give to it. Thanks Subhro On Fri, Oct 10, 2008 at 1:55 AM, Josef Grosch [EMAIL PROTECTED]wrote: Does anyone have experience running FreeBSD 6.x and 7.x on an HP DL180/G5? The company I work for is looking to get a number of these to be put in production. Your general impressions would be a good start. Josef -- Josef Grosch | Another day closer to a | FreeBSD 6.3 [EMAIL PROTECTED] | Micro$oft free world | Berkeley, Ca. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: continuous backup solution for FreeBSD
On Thu, Oct 9, 2008 at 3:40 PM, Matthew Dillon [EMAIL PROTECTED]wrote: (ZFS has a way to do something similar but I do not know what the various advantages or disadvantages of using the feature are). The only current way to do this on ZFS is to snapshot (very cheap) and stream the differences between the current snapshot and the previous snapshot to the remote host. The remote host can store the flat files or store the filesystem (that is: the streams can feed into new snapshots of the filesystem on the remote machine). Like Hammer, this gives history on both the local machine and the remote machine and is amazingly efficient. Unlike hammer, the process is not automated by the filesystem. You need a script that does zfs snaphot... followed by zfs send ... | ssh remote zfs receive ... --- such that each individual backup is a job rather than the connection approach you discribe for Hammer. Unlike Hammer, ZFS doesn't, by default, keep all history. I was speculating earlier that this might be possible to make as a ZFS module, though. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: continuous backup solution for FreeBSD
Quoting Oliver Fromme [EMAIL PROTECTED]: These features are readily available right now on FreeBSD. You don't have to code anything. Well with 2 downsides, The fact that I still would need to take full backups once in a while if I do this and Linux users do not have to because the CDP software on Linux does not need to do this. The software expires the old data automatically and you only need a full backup at first run only. The bigger problem is that I have to convert all my filesystems to ZFS. Can one convert UFS2 to ZFS easily even? I dont wanna spend a large part of the year doing such job while Linux users can just do this on 'any' filesystem they use. How am I suppose to compete with companies which use Linux otherwise if I am doing this sort of tasks all the time? Thanks for all the advices but my original question was if somebody can give inside information to a company(for example r1soft) which is writing CDP backup solutions so they could implement such solution on FreeBSD also. Do you know such person? I am not really looking for alternatives because there is none. You cant just expect commercial companies to convert to a new filesystem to add a feature which other OSes manage without going to such measures. Can you imagine the monetary cost if all FreeBSD users had to convert to ZFS (or another filesystem) to take near cdp level backups? This simply would make people think 'I wish I used Linux from the beginning'. Thanks, Evren ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: continuous backup solution for FreeBSD
On Fri, 10 Oct 2008 02:34:28 +0300 [EMAIL PROTECTED] wrote: Quoting Oliver Fromme [EMAIL PROTECTED]: These features are readily available right now on FreeBSD. You don't have to code anything. Well with 2 downsides, Once you actually try and implement these solutions, you'll see that your downsides are largely figments of your imagination. The fact that I still would need to take full backups once in a while Every time you started backing up a new file system. This is a requirement of all backup solutions. After that, never again. The bigger problem is that I have to convert all my filesystems to ZFS. Can one convert UFS2 to ZFS easily even? I didn't have any trouble. And once you do it, you have advantages that the poor schmucks using Linux can only dream about: like self-healing file systems that are so cheap and easy to create that it makes sense to put each application or jail on it's own file system, one that's tuned for the application. The ability to set up raid and mirror devices without ever having to deal with LLVM (worth the cost of entry all by itself), not having to worry about allocating partitions, and - well, the list just goes on and on. Having converted to ZFS on my FreeBSD boxes, the only thing I feel for my clients still using Linux file systems is pity. this on 'any' filesystem they use I seriously doubt that it supports things like GMailFS. How am I suppose to compete with companies which use Linux otherwise if I am doing this sort of tasks all the time? Well, once you've done the conversion, by outproducing them while they waste time dealing with LLVM, partitions, and other such crap that ZFS frees you from. Thanks for all the advices but my original question was if somebody can give inside information to a company(for example r1soft) which is writing CDP backup solutions so they could implement such solution on FreeBSD also. Do you know such person? The only inside information here is held by the company (for example rlsoft) providing the CDP software. On the FreeBSD side, the source and documentation are all freely available to anyone who wants to look at it. But it doesn't matter how well you know FreeBSD, you aren't going to get anywhere unless you also you know what the software from that company needs in order to operate. If said company wanted to hire someone to either write this or to help get their people started working with FreeBSD, then the thing to do is send mail to [EMAIL PROTECTED] announcing the position. If they aren't interested in hiring someone, but hope to get it done for free, then they should set up a web page providing the technical details that someone who knows FreeBSD (or is willing to learn it) needs to do the job. If all you want is a CDP solution and you don't care where it comes from - well, you pretty much get the same two choices. It's an interesting enough problem that you might get someone to build it for free, but don't expect it to use proprietary software from some company that already provides such a thing for other systems. Nor - if you don't provide any incentive for meeting your requirements - should you expect it to actually meet them. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: continuous backup solution for FreeBSD
:The fact that I still would need to take full backups once in a while =20 :if I do this and Linux users do not have to because the CDP software =20 :on Linux does not need to do this. The software expires the old data =20 :automatically and you only need a full backup at first run only. You have to do this anyway. Nobody in their right mind trusts a single storage solution for all of their backups. CDP is a brute-force block-level continuous backup mechanism and while it works, to a point, it also has all the drawbacks that ANY block level backup system has... it is discontinuous from the high level filesystem structure and while you can pretty much guarantee that it is possible to recover from a disaster eventually, the filesystem you choose to run on top of that block device still matters a lot. On top of that being a client-server solution CDP is going to have some significant bottlenecks too. Even more telling is the fact that block level storage solutions tend to migrate corruption instead of detect it early. Big oopses can wind up stealthily winding their way through all your backups when you use a block-level solution. I stopped using block-level solutions almost 10 years ago... that's how little I trust them. Only a 'modern' linux filesystem (ext3 or the upcoming ext4, reiser, xfs, and few others), or something like ZFS or HAMMER, really have the ability to reliably recover from a point-in-time block level snapshot. Filesystems such as ZFS and HAMMER also give you insanely good snapshotting solutions that are far, FAR more flexible then what CDP gives you. You can upgrade between EXT filesystems without having to copy, but if you decided the best filesystem for you was one of the other many Linux filesystems, such as Reiser4 or XFS, and you were running EXT3, then you would have to copy. There are massive lists of pluses and minuses to each of the linux filesystem choices. Data expiration is a non-issue. You have to think about it either way. You have to test that the backup system actually works. You have to carefully control the backup policy and in particular not allow heavy disk I/O (such as a hacker DD'ing to your filesystem for 24 hours) to blow out your ability to recover the system. It requires time and effort no matter how well automated it is. :The bigger problem is that I have to convert all my filesystems to =20 :ZFS. Can one convert UFS2 to ZFS easily even? I dont wanna spend a =20 :large part of the year doing such job while Linux users can just do =20 :this on 'any' filesystem they use. How am I suppose to compete with =20 :companies which use Linux otherwise if I am doing this sort of tasks =20 :all the time? I converted our main developer machine from UFS to HAMMER in about 12 hours. 99% of that time simply waiting for the cpdup to finish copying a few hundred gigabytes from the old filesystem to the new. I think we're talking a few days here... time enough to learn how the filesystem works and play with it, make a few test copies (as you would with ANY new system that you did not have previous experienced with), and then do it for real. Linux users cannot just do this with a flip of a switch either. The new filesystem has to be constructed and the old data copied over. The old data set has to be retained, you cannot convert in-place, it's just too dangerous. It takes a certain amount of time to copy the data no matter what OS you are running, based on the amount of data you have. Some filesystem transitions such as going from ext2 to ext3 or ext3 to ext4 (if I remember right) are forwards compatible and do not require copying, but that sort of transition is NOT to a new filesystem, it's to a newer version of the same filesystem. With storage capacities increasing so quickly and mandating the replacement of whole disk subsystems (for running and electricity cost more then anything else, and more convenience, and less maintainance) it is a small convenience at best if you are going to copy the data anyway. Frankly, even if I were upgrading from ext2 to ext3 the last thing I would do is run it in-place. There's just too high a chance of software bugs creeping in. I would want a fresh ext3 and I would want my old ext2 data sitting on a shelf for a few days in case something were to go terribly wrong. I'd copy there too, just for safety. What is a few extra hours compared to blowing up the life-blood of your company? :I am not really looking for alternatives because there is none. You =20 :cant just expect commercial companies to convert to a new filesystem =20 :to add a feature which other OSes manage without going to such =20 :measures. Can you imagine the monetary cost if all FreeBSD users had =20 :to convert to ZFS (or another
Re: setkey panic freebsd7
that single line of adding SA in a setkey.conf file with /sbin/setkey -f setkey.conf would fail 100% from all my try. /usr/local/sbin/setkey just tried, failed also. 'fill in PR' haven't done that before, could you please advise. thanks for looking into! On Thu, Oct 9, 2008 at 1:56 PM, VANHULLEBUS Yvan [EMAIL PROTECTED] wrote: Hi. On Thu, Oct 09, 2008 at 08:46:32AM -0700, alan yang wrote: i wonder people ran into similar issue on setkey with freebsd7 that panic at ~/crypto/sha1.c:263 within sha1_result() digest[0] = ctxt-h.b8[3]; digest[1] = ctxt-h.b8[2]; on the following sadb add with setkey: add 192.168.0.101 192.168.0.110 esp-old 0x10001 -m any -E des-cbc 12345678 -A keyed-sha1 12345678123456781234 thanks in advance on any hints. I guess most people just don't use static SAs anymore :-) Can you reproduce the bug ? Are you using /sbin/setkey (provided by FreeBSD), /usr/local/sbin/setkey (provided by ipsec-tools), or does it crash with both ? If you can reproduce it, please fill in a PR, Bjoern or I will take it. Anyways, I'll have a look asap at that part of the code, to see if I can find something. Any extra information on how to reproduce the bug is welcome ! :-) Yvan. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
