Re: Generate CA & Certificates key
Generating certificates and a CA (focused on web but the concept works for whatever SSL situation you are using): http://it.toolbox.com/blogs/securitymonkey/howto-securing-a-website-with-client-ssl-certificates-11500 Once you get the concept of certificate generation then look into the OpenVPN and OpenSSL documentation. Assuming you've done that and can read a script then you should be able to make it work from there. On 2-Feb-09, at 10:45 PM, sonjaya wrote: how to generating certificates keys and CA in openbsd ? i will use certificates and keys for server also for the client . last time follow openvpn script not working. -- Sean
Re: drift in ntpd may not catch up on bad clock and keep slipping.
I've seen this happen too but ended up just shutting off ntpd entirely and croned an rdate in it's place. In my case the clock goes WAAY out and even when I fix it it flys way out on the next NTP interval. Even if I restart NTPD the damned thing flies way out again a while later. I'm sure the clock is totally screwed on this machine but ntpd didn't help _AT ALL_ just made things worse. A cron'd rdate is keeping things in check now that I've turned off ntpd (waiting to replace the hardware). I was under the impression that ntpd should be keeping things straight but it wasn't at all (hence turfing it). One of this days I'll spend the time to figure out what ntpd actually does. :P Snippet from /var/log/daemon: daemon:Nov 25 07:16:24 mail ntpd[3292]: reply from 209.139.209.82: negative delay -0.021739s, next query 3211s daemon:Nov 25 07:29:04 mail ntpd[3292]: reply from 209.139.208.96: negative delay -0.026221s, next query 3000s daemon:Nov 25 07:45:01 mail ntpd[3292]: reply from 204.174.89.240: negative delay -0.000481s, next query 3273s daemon:Nov 25 07:48:18 mail ntpd[1183]: adjusting local clock by 59320.679282s daemon:Nov 25 08:10:02 mail ntpd[3292]: reply from 209.139.209.82: negative delay -0.020042s, next query 3267s daemon:Nov 25 08:19:04 mail ntpd[3292]: peer 209.139.208.96 now valid daemon:Nov 25 08:39:34 mail ntpd[1183]: adjusting local clock by 59329.014887s daemon:Nov 25 08:43:41 mail ntpd[1183]: adjusting local clock by 59319.361513s daemon:Nov 25 08:45:46 mail ntpd[1183]: adjusting local clock by 59314.438839s daemon:Nov 25 08:47:26 mail ntpd[1183]: adjusting local clock by 59310.402041s daemon:Nov 25 08:51:13 mail ntpd[1183]: adjusting local clock by 59301.408815s daemon:Nov 25 08:52:49 mail ntpd[1183]: adjusting local clock by 59297.653276s daemon:Nov 25 08:57:01 mail ntpd[1183]: adjusting local clock by 59287.549873s daemon:Nov 25 08:59:44 mail ntpd[1183]: adjusting local clock by 59281.201113s daemon:Nov 25 09:01:18 mail ntpd[1183]: adjusting local clock by 59277.545620s daemon:Nov 25 09:01:51 mail ntpd[1183]: adjusting local clock by 59276.293823s daemon:Nov 25 09:04:29 mail ntpd[3292]: peer 209.139.209.82 now valid daemon:Nov 25 09:05:03 mail ntpd[1183]: adjusting local clock by 59268.871698s daemon:Nov 25 09:06:38 mail ntpd[1183]: adjusting local clock by 59265.077072s daemon:Nov 25 09:10:59 mail ntpd[1183]: adjusting local clock by 59254.692520s daemon:Nov 25 09:14:16 mail ntpd[1183]: adjusting local clock by 59247.127138s daemon:Nov 25 09:18:01 mail ntpd[1183]: adjusting local clock by 59238.282543s daemon:Nov 25 09:19:43 mail ntpd[1183]: adjusting local clock by 59234.406758s daemon:Nov 25 09:23:33 mail ntpd[1183]: adjusting local clock by 59225.631214s daemon:Nov 25 09:27:19 mail ntpd[1183]: adjusting local clock by 59216.849676s daemon:Nov 25 09:30:24 mail ntpd[1183]: adjusting local clock by 59209.675600s daemon:Nov 25 09:33:14 mail ntpd[1183]: adjusting local clock by 59203.072213s daemon:Nov 25 09:35:53 mail ntpd[1183]: adjusting local clock by 59196.728028s daemon:Nov 25 09:39:06 mail ntpd[1183]: adjusting local clock by 59189.182660s daemon:Nov 25 09:42:55 mail ntpd[1183]: adjusting local clock by 59179.901572s daemon:Nov 25 09:45:04 mail ntpd[1183]: adjusting local clock by 59174.749391s daemon:Nov 25 09:48:18 mail ntpd[1183]: adjusting local clock by 59167.009772s daemon:Nov 25 09:50:28 mail ntpd[1183]: adjusting local clock by 59161.774410s daemon:Nov 25 09:54:15 mail ntpd[1183]: adjusting local clock by 59152.951333s daemon:Nov 25 09:58:28 mail ntpd[1183]: adjusting local clock by 59142.836328s daemon:Nov 25 10:00:36 mail ntpd[1183]: adjusting local clock by 59137.816565s daemon:Nov 25 10:02:13 mail ntpd[1183]: adjusting local clock by 59133.771875s daemon:Nov 25 10:06:33 mail ntpd[1183]: adjusting local clock by 59123.468998s daemon:Nov 25 10:07:39 mail ntpd[1183]: adjusting local clock by 59120.812184s daemon:Nov 25 10:10:07 mail ntpd[3292]: peer 69.77.167.215 now invalid daemon:Nov 25 10:10:16 mail ntpd[1183]: adjusting local clock by 59114.600294s daemon:Nov 25 10:13:02 mail ntpd[1183]: adjusting local clock by 59107.913735s daemon:Nov 25 10:17:00 mail ntpd[3292]: peer 209.139.209.82 now invalid On 10-Dec-07, at 3:07 PM, Daniel Ouellet wrote: Hi, Looking a the code, I am trying to understand something on some servers that just don't stay sync in the latest kernel (current). I see some changes were done to the drift, and a few other things. What is really the logic in the daemon to actually send a sync message and more importantly to write the /var/db/drift file to then start to adjust the clock. I am asking, because looks like some clock drift more then the correction done to it. I can see the clock get sync for may be 1 or 2 minutes only after one to three hours trying and then continuing to try to catch up and no drift file are written.
Re: What crypto card to buy?
In my experience I would say not to bother with one unless you intend on doing high throughput SSL. I've had nothing but issues using them on Soekris gear (but that was many releases ago). As for no blowfish, well that is a blessing as when the card locks up and is very far away (like in another country) killing all forms of crypto and related services (ie. ssh) and you can't get into manage it, well that unaccelerated cipher saves your lunch (ie. ssh -c blowfish [EMAIL PROTECTED]). Sure this saving grace was my fix to the previous issue so YMMV. On 1-Apr-08, at 9:00 AM, Khalid Schofield wrote: Hi, I'm wondering what is the best crypto card to buy to use with openbsd to do AES and blowfish and the SSL encryption. Is this the best buy? http://www.soekris.com/vpn1401.htm It mentions AES but not blowfish. thanks khalid
Re: Disk performance/benchmarking
If it is doing anything but the benchmark the results will be useless but you probably already know that. Assuming the machine is completely idle with no services currently running (other than the one used to log in) then just try a bunch of test cases for the usage pattern you expect to see (or want to use) and interpret the numbers accordingly. Reducing the variables that interact with what you are metering is the first step. If you want a 'generic' (ie. not real usage) benchmark then try the iogen port. But with any benchmarks don't put a lot of trust in the numbers especially if you only run one test set. Run a bunch and pull out that old Stats 1 text and take the results with a big huge grain of salt and realize you are not benchmarking OpenBSD you are benching your hardware and configuration. http://www.openbsd.org/cgi-bin/cvsweb/ports/sysutils/iogen/pkg/DESCR? rev=1.2&content-type=text/x-cvsweb-markup "iogen is an i/o generator. It forks child processes that each run a mix of reads and writes. The idea is to generate heavily fragmented files to make the hardware suffer as much as possible. This tool has been used to test filesystems, drivers, firmware and hardware devices. It is by no means meant as a performance measuring tool since it tries to recreate the worst case scenario i/o." You may already have considered all of the above but included in case others on the list have not. On 27-Jun-06, at 7:57 AM, Gabriel George POPA wrote: Could someone tell me which is the most used disk-benchmarking solution for OpenBSD 3.8? I'm running a small production server and I don't want to disrupt (too much) its activity. I would like of course to perform non-destructive tests. I think there's somethink wrong with my disk/os performance but I don't know where to start. I think a benchmark utility will be good (SMART neveals nothing). He he he. I think all people are concerned about OpenBSD performance these days... -- Sean
Re: Disk performance/benchmarking
dd(1) and iogen should give you said rough estimation. As for transmission issues. First take a look on either side for network 'errors'.. $ netstat -I hme0 NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls hme0150008:00:20:c2:5f:f0 1498294 0 74211510 99837 Ierrs and Oerrs should be really low. Colls are collissions. If files get corrupted over the wire make a test file and hash [md5 (1)] it before transfer on test machine and after it has been transfered hash it on the target machine. That will determine if the file corruption happened during transit. For packet loss... ping the target machine then generate a lot of traffic to it (tcpblast, dd+netcat, etc.). Then stop ping and the stats at the end will give you the relative packet loss (to ping). Change target machine's switch port and try again. Change testing machine's switch port and try again. Try a different switch. On 27-Jun-06, at 8:53 AM, Gabriel George POPA wrote: I was mainly wanting to see a rough estimation of disk throughput (MB/sec). And now I am interested to see if packets get lost over my wide LAN here (I think a switch is deffective, but I don't know what). What should I do? -- Sean
Re: /usr/bin/ssh: can't load library 'libcrypto.so.14.0' on ALIX board
cp /usr/lib/libcrypto.so.13.0 /usr/lib/libcrypto.14 Don't knock it, it works. As well if you are having libm issues (ie. things (like httpd) can't find isnan or isinf symbols) check to see if you have /usr/ibm.3.0 and of so just move /usr/lib/libm.so.2.4 out of the way (like to /root). The directions on openbsd.org/faq/current.html HELP but they don't give you the entire picture. The snapshot was hosed all day yesterday and once I figured out the above I didn't bother trying again (as everything works as expected again). These are the dangers of tracking -current and I enjoyed the challenge (though going through "make build" six times get to be on the annoying side when it take 1.5 hours each run :P ). On 25-Jul-08, at 10:53 PM, Emilio Perea wrote: I imagine the next snapshot will fix that (the one currently available does not contain libcrypto.so.14.0). If you have another PC available to build a current release, that should also work. I just did that myself on an amd64. (If you try that, note there are some additional library building steps before the final build as shown on http://www.openbsd.org/faq/current.html.)
Re: pre-orders
On 9-Mar-06, at 1:06 PM, Harry Putnam wrote: Considering your input to this thread about donations wouldn't it be smart to make it a little easier to find the donations pages? I see nothing about where to do donations there or anywhere in this thread. It is pretty obvious where to look: http://www.openbsd.org/donations.html -- Sean
Re: A joke
On 1-Jun-06, at 10:22 AM, Andrew Pinski wrote: On Jun 1, 2006, at 1:44 AM, Rico wrote: Manager: George, I need a program to output the string Hello World! You forgot one: a lazy person #!/bin/sh echo "Hello World!" Why waste an extra shell process not to mention all that extra typing? #!/bin/echo 'Hello World!' :P -- Sean
fatal: evp_crypt: EVP_Cipher failed
I have been having issues lately with the HiFn based crypto cards locking up in 3.7 and 3.8. They are usually fine but under some undefined load they lock up and it seems rather random as to when it happens and how much load causes it. The cards are used to help out with a VPN between a few far flung machines but they are all i386. I've encountered this on two Soekris NET4501's and on a single Athlon machine. The only real clue is in the authlog where sshd reports: sshd []: fatal: evp_crypt: EVP_Cipher failed SSHD and isakmpd are both seeminly locked up but I can get into the machine if I use the blowfish protocol which isn't supported on the HiFn card thereby leading me to think there is a bug in the driver or the card itself where it's not servicing an interrupt or is stuck waiting for an interrupt which will never come. The dmesg on the machines have the following line: hifn0 at pci0 dev 13 function 0 "Hifn 7955/7954" rev 0x00: LZS 3DES ARC4 MD5 SHA1 RNG AES PK, 32KB dram, irq 9 As well the cards in question are the VPN1401 (PCI) and VPN1411 (MiniPCI). Since there is no kernel panic I'm sort of at a loss as to how to track this down better. As far as the kernels go, I am using 3.8_GENERIC on the Athlon and a stripped (via flashdist) version of 3.8 on the NET4501's. Again these lockups are always under some sort of load over the VPN (VNC, file transfers ) and are for the most part random. Does anyone have any suggestions on how to track this down? My current solution is just 'ssh somehost -c blowfish reboot' though that is obviously far from optimal. -- Sean
Re: OpenBSD hardware router
I am using a 4501 with the accelerator and when it works I agree it can easily saturate a T1/E1. The only problem is the card randomly wedges (personal observations on 3.7 to current) so I've been advised to effectively shut the card off (kern.usercrypto=0). On 4-Feb-06, at 12:43 PM, Siegbert Marschall wrote: Hi, On 2006/02/03 20:34, Josh Tolley wrote: All that being said, we 1) didn't have an encryption accelerator in the box that would tend to make things worse anyway - you'll just increase the rate of interrupts and that seems to be the main problem. for a something fast like "aes" it might be true, for 3des this statement ist wrong. never did stuff with the 45xx but I can remember that for pushing 1mbit/s 3des I needed 133MHz on old 486er CPU and a P1-166MMX could barely handle 2mbit/s. so with the accelerater you can handle T1/E1 easily, without it you are lost. some benchmarks from years ago... bye, siggi. -- Sean
