Re: fuse - bindfs, fuse-zip, strange issues
On Sat, Jun 14, 2014 at 01:33:24PM +0100, Stuart Henderson wrote: what is implemented - sure, see /sys/miscfs/fuse and /usr/src/lib/libfuse ;) These in particular: fuse.c: FUSE_OPT_KEY(-h, KEY_HELP), fuse.c: FUSE_OPT_KEY(--help, KEY_HELP), fuse.c: FUSE_OPT_KEY(-ho, KEY_HELP_WITHOUT_HEADER), fuse.c: FUSE_OPT_KEY(-V, KEY_VERSION), fuse.c: FUSE_OPT_KEY(--version, KEY_VERSION), fuse.c: FUSE_OPT_KEY(max_read=, KEY_MAXREAD), fuse.c: FUSE_OPT_KEY(debug, KEY_STUB), fuse.c: FUSE_OPT_KEY(-d, KEY_STUB), fuse.c: FUSE_OPT_KEY(-f, KEY_STUB), fuse.c: FUSE_OPT_KEY(-s, KEY_STUB), fuse.c: FUSE_OPT_KEY(use_ino, KEY_STUB), fuse.c: FUSE_OPT_KEY(default_permissions, KEY_STUB), fuse.c: FUSE_OPT_KEY(fsname=, KEY_STUB), what is not - there are several implementations of fuse with different capabilities, so compare the above with these .. Linux, see General mount options in e.g. http://manpages.ubuntu.com/manpages/precise/man8/mount.fuse.8.html fuse4bsd (FreeBSD), see struct mntopt mopts in http://mirrors.rit.edu/zi/fuse4bsd/498acaef33b0.tar.gz I would expect `mount' output would show source in the output. I guess you mean you're expecting it to show fsname..? (in linux this defaults to the program name mounting the filesystem though can be changed with a mount option). - fsname isn't implemented yet (stubbed out). # sysctl kern.version kern.version=OpenBSD 5.5-current (GENERIC.MP) #202: Fri Jun 13 12:56:14 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP # fuse-zip /home/jirib/tmp/logs.zip /mnt # mount -v -t fuse fusefs () on /mnt type fuse (rw, local, ctime=Sat Jun 14 12:18:36 2014) With latest amd64 snapshot 'bindfs' even stop working :/ # bindfs /home/jirib/tmp /mnt fuse: unknown option allow_other Not implemented. allow_other is not expected to be accepted by our fuse implementation yet. ^^^ google reveals some /etc/fuse.conf OpenBSD libfuse doesn't support /etc/fuse.conf. # bindfs -d /home/jirib/tmp /mnt fuse: unknown option -d This is something to do with the fact that it's setting up its own options array and calling fuse_opt_parse with that, but I got a bit lost in fuse_opt_parse / parse_opt. btw, your port is not really ugly, but s/GPLv2/GPLv2+/, and the do-install doesn't seem to be useful. But it looks like it relies on quite a lot of things that are not supported in OpenBSD's fuse implementation. Thanks for explanation Stuart. As I'm not a programmer than I will maybe try to resurrect to make bindfs run on OpenBSD when OpenBSD FUSE implemantation would get more features. jirib
Re: Very slow I/O under OpenBSD i386 on qemu-kvm from RHEL7rc
On 16 June 2014 04:19, Mikolaj Kucharski miko...@kucharski.name wrote: Hi, Please CC me in any replies as I'm not subscribed to misc emails. My main question is, do you experience similar slow I/O on OpenBSD i386 on your Qemu/KVM installations? Are you aware of any problem with OpenBSD i386 under Qemu/KVM? Not sure should this report go to RedHat, KVM or to OpenBSD, but I've tested RHEL7rc with CentOS 6.5, NetBSD 6.1.4 installer and OpenBSD current bsd.rd and only OpenBSD i386 seems to have slow I/O problem under latest Enterprise Linux from RedHat. I've decided to report the issue here. I've tested OpenBSD guest with IDE, SCSI and VirtIO disk. SCSI disk currently don't seem to work at all with both amd64 and i386: The problem is the i386 ioapic/apic implementation and how OpenBSD uses the lapic_tpr to block incoming interrupts. Basically if you're using ioapic (and you are), OpenBSD maps the lapic_tpr to the special TPR register to block interrupts everytime you get an interrupt of raise it yourself by splraise()/spl* and so on. You don't suffer this on amd64 since the masking is done purely in software. You can also verify this statement by disabling mpbios on OpenBSD and falling back to the old pic controller, in this case you don't use ioapic, and the pic code does the mask in software, lapic_tpr is still the same variable being touched, but in this code path, it's not mapped to the cpu TPR. To have an ideia of the cost of touching the tpr: real hardware: ~25 cycles. kvm + flexpriority (cpu extension): ~2700 cycles. kvm without flextpriority: 100k+ cycles. So every interrupt you take needs to touch at least lapic_tpr twice, which before would cost ~50cycles, and now it's more than ~200kcycles. Of course these numbers are relevant to the machine I've tested, but you get an idea on how much slower it is.
IPSec w/ and w/o npppd for road warriors
I've managed to setup tunnels (X.509 auth) between the office network an OpenBSD machine (both with dynamic IPs) by using: /etc/ipsec.conf on the DMZ/LAN firewall: ike passive esp from 10.17.18.0/24 to any \ srcid vpn.foobar.org dstid vpn-client.foobar.org I also managed to use npppd for L2TP (iOS and OS X clients) by using: ike passive esp transport proto udp \ from pppoe0 (10.17.19.0/24) to any port 1701 \ main auth hmac-sha1 enc 3des group modp1024 \ quick auth hmac-sha1 enc aes group none \ psk ... on the office gateway's /etc/ipsec.conf (and the appropriate nppp.conf, of course). Again, I've managed to get both setups working perfectly, separately. My question is: (how) can I setup both X.509 IPSec and L2TP/npppd simultaneously? I can't have both entries on the same ipsec.conf file since they both refer to the 'default peer', so I guess I should either run two instances of isakmpd (different ports, different fifo), which sounds messy, or use relayd, of which my current knowledge amounts to the first paragraph of the man page. Does anyone have such a setup? TIA Zé
Re: Squid + OpenBSD 5.4 and 5.5
On 2014-06-15, monahb...@gmail.com monahb...@gmail.com wrote:
Thanks Rodrigo.
The VMWare install is 32 bit, it's only on the sparc64 that it is 64bit.
Will read up on the time_t
This is related to the storage type used for time values.
OpenBSD now uses 64 bit time_t and tv_sec on all architectures
(32-bit *and* 64-bit arches).
client_side_reply.cc: In member function 'void
clientReplyContext::buildReplyHeader()':
client_side_reply.cc:1326: warning: format '%ld' expects type 'long
int', but argument 4 has type 'long long int'
What's the reason why you don't just use the port/package?
Anyway, see the patches in the port, specifically this:
--- src/client_side_reply.cc.orig Tue May 6 04:30:25 2014
+++ src/client_side_reply.ccWed May 7 20:14:52 2014
@@ -1347,7 +1347,7 @@ clientReplyContext::buildReplyHeader()
if (http-storeEntry()-timestamp = squid_curtime) {
// put X-Cache-Age: instead of Age:
char age[64];
-snprintf(age, sizeof(age), %ld, (long int) squid_curtime -
http-storeEntry()-timestamp);
+snprintf(age, sizeof(age), %lld, (long long) squid_curtime -
http-storeEntry()-timestamp);
hdr-putExt(X-Cache-Age, age);
}
} else if (http-storeEntry()-timestamp = squid_curtime) {
openbsd live-cd?
Hi, I would like to try openBSD before installing it on my laptop to check if things works correctly (X server as example). Do you know any liveCD or any methode to try openBSD on some hardware before installing? Regards, -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: openbsd live-cd?
On 06/16/14 21:35, Thuban wrote: Hi, I would like to try openBSD before installing it on my laptop to check if things works correctly (X server as example). Do you know any liveCD or any methode to try openBSD on some hardware before installing? Regards, -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] You'll be testing OpenBSD if you boot install55.iso.
Re: openbsd live-cd?
On 06/16/14 21:38, Gustav Fransson Nyvell wrote: On 06/16/14 21:35, Thuban wrote: Hi, I would like to try openBSD before installing it on my laptop to check if things works correctly (X server as example). Do you know any liveCD or any methode to try openBSD on some hardware before installing? Regards, -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] You'll be testing OpenBSD if you boot install55.iso. I didn't know install55.iso comes with a fully functioning Xorg. :) You might want to try http://liveusb-openbsd.sourceforge.net/. I've only used it to bootstrap my netbook once, so no guarantees about the validity or quality from my end, but it might be what you're looking for.
Re: openbsd live-cd?
Install it to a usb stick. On 06/16/14 15:35, Thuban wrote: Hi, I would like to try openBSD before installing it on my laptop to check if things works correctly (X server as example). Do you know any liveCD or any methode to try openBSD on some hardware before installing? Regards, -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: openbsd live-cd?
* Rodrigo Mosconi open...@mosconi.mat.br le [16-06-2014 16:45:57 -0300]: 2014-06-16 16:35 GMT-03:00 Thuban thu...@yeuxdelibad.net: Hi, I would like to try openBSD before installing it on my laptop to check if things works correctly (X server as example). Do you know any liveCD or any methode to try openBSD on some hardware before installing? You can install it on a USB Flash drive, and test it... see faq: http://www.openbsd.org/faq/faq14.html#flashmemLive I missed it. Thanks -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: openbsd live-cd?
* Gustav Fransson Nyvell gus...@nyvell.se le [16-06-2014 21:38:02 +0200]: On 06/16/14 21:35, Thuban wrote: Hi, I would like to try openBSD before installing it on my laptop to check if things works correctly (X server as example). Do you know any liveCD or any methode to try openBSD on some hardware before installing? Regards, -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] You'll be testing OpenBSD if you boot install55.iso. Of course. Let me re-write my question : how to test openbsd before installing, especially the X server (because network and so cas be tested with install55.iso). -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: signing release files
On Sun, Jun 15, 2014 at 05:09:20PM -0400, Ted Unangst wrote:
On Sun, Jun 15, 2014 at 14:12, Aaron Gomez wrote:
I looked at the signify command but I can't figure out how to check all
the files and then create the SHA256.sig.
I tried signify -S -s myprivatekey.sec -m SHA256 -x SHA256.sig but
that just created a file SHA256.sig with the following contents:
untrusted comment: signature from signify secret key
RWQ/YLxjYycyl9yO0Qz8OyKSG9NnreWqIqIvMrJ64hJ2XqsXcElZB8BW8h/tGfvR44cRyAlIk10pUntzg9R0Z1p5+e+1tHFzkAs=
You need the -e flag to embed the message into the signature.
I then ran sha256 against all of the files and copied the output to the
SHA256.sig file, created a new install cd and tried again. This time it
failed telling me that I used the incorrect key.
The main problem is that the CD will attempt to verify against a key
named openbsd-55-base.pub, which we ship. That's not going to match
the private key you generated and are using.
What do I need to do to make it so the installer can verify my newly
created release files?
The best approach, but it's more work, would be to change install.sh
to look for a key like aaron-55-base.pub and add that to the ramdisk.
The shortcut would be to replace the openbsd key, but that will only
cause confusion later, so I'd try not to.
That said, you probably don't need to sign releases you're building
for yourself, unless they are travelling over untrusted links. We sign
releases because they go from OpenBSD servers to you over the scary
internet. If you control distribution, that's less scary.
Wouldn't something like below make life easier?
Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.775
diff -u -p -r1.775 install.sub
--- install.sub 9 Jun 2014 18:05:55 - 1.775
+++ install.sub 16 Jun 2014 19:55:49 -
@@ -86,6 +86,7 @@ shift $((OPTIND-1))
# MDCDDEVS- '/^cd[0-9][0-9]* /s/ .*//p'assumed if not provided
# MDMTDEVS- '/^[cms]t[0-9][0-9]* /s/ .*//p'
# MDXAPERTURE - set machdep.allowaperture=value in sysctl.conf
+# MDSIGNKEY - path to signify public key
# NCPU- the number of cpus for mp capable arches
. install.md
@@ -1158,6 +1159,7 @@ install_files() {
local _src=$1 _files=$2 _f _sets _get_sets _n _col=$COLUMNS \
_tmpfs _tmpsrc _cfile _fsrc _unver _t _issue _srclocal
+ export
SIGNKEY=${SIGNKEY:-${MDSIGNKEY:-/etc/signify/openbsd-${VERSION}-base.pub}}
# Initialize _sets to the list of sets found in _src, and initialize
# _get_sets to the intersection of _sets and DEFAULTSETS.
#
@@ -1244,7 +1246,7 @@ install_files() {
_issue=Cannot fetch SHA256.sig break
# Verify signature file with public keys
- ! signify -Vep /etc/signify/openbsd-${VERSION}-base.pub \
+ ! signify -Vep ${SIGNKEY} \
-x $_cfile.sig -m $_cfile
_issue=Signature check of SHA256.sig failed break
Re: openbsd live-cd?
On 06/16/14 21:49, Thuban wrote: * Gustav Fransson Nyvell gus...@nyvell.se le [16-06-2014 21:38:02 +0200]: On 06/16/14 21:35, Thuban wrote: Hi, I would like to try openBSD before installing it on my laptop to check if things works correctly (X server as example). Do you know any liveCD or any methode to try openBSD on some hardware before installing? Regards, -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] You'll be testing OpenBSD if you boot install55.iso. Of course. Let me re-write my question : how to test openbsd before installing, especially the X server (because network and so cas be tested with install55.iso). -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] Hi, Well, if you give your specification we can probably answer any questions you have. You won't be playing highly advanced 3D games any time soon, I can give you that. //Gustav
Re: openbsd live-cd?
* Gustav Fransson Nyvell gus...@nyvell.se le [16-06-2014 22:21:44 +0200]: On 06/16/14 21:49, Thuban wrote: * Gustav Fransson Nyvell gus...@nyvell.se le [16-06-2014 21:38:02 +0200]: On 06/16/14 21:35, Thuban wrote: Hi, I would like to try openBSD before installing it on my laptop to check if things works correctly (X server as example). Do you know any liveCD or any methode to try openBSD on some hardware before installing? Regards, -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] You'll be testing OpenBSD if you boot install55.iso. Of course. Let me re-write my question : how to test openbsd before installing, especially the X server (because network and so cas be tested with install55.iso). -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] Hi, Well, if you give your specification we can probably answer any questions you have. You won't be playing highly advanced 3D games any time soon, I can give you that. //Gustav That's not my goal :). I need a system for work, so I have to open pictures, videos and so... Regards -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: openbsd live-cd?
On 06/16/14 22:41, Thuban wrote: * Gustav Fransson Nyvell gus...@nyvell.se le [16-06-2014 22:21:44 +0200]: On 06/16/14 21:49, Thuban wrote: * Gustav Fransson Nyvell gus...@nyvell.se le [16-06-2014 21:38:02 +0200]: On 06/16/14 21:35, Thuban wrote: Hi, I would like to try openBSD before installing it on my laptop to check if things works correctly (X server as example). Do you know any liveCD or any methode to try openBSD on some hardware before installing? Regards, -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] You'll be testing OpenBSD if you boot install55.iso. Of course. Let me re-write my question : how to test openbsd before installing, especially the X server (because network and so cas be tested with install55.iso). -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] Hi, Well, if you give your specification we can probably answer any questions you have. You won't be playing highly advanced 3D games any time soon, I can give you that. //Gustav That's not my goal :). I need a system for work, so I have to open pictures, videos and so... Regards -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] Hi, Oh, you'll be fine, if it's stable, that I can't guarantee. But, better make sure you have an Intel chipset... they're common. //Gustav
Re: openbsd live-cd?
Thuban thu...@yeuxdelibad.net writes: Let me re-write my question : how to test openbsd before installing, especially the X server (because network and so cas be tested with install55.iso). Assuming your system can boot from USB media, one possible approach is to install from whatever medium you have onto an otherwise unused USB thumbdrive. Then you boot your system from the USB drive and do whatever testing and general futzing around you need to do to determine whether your gear is sufficently supported. That way at least you will not be touching anything important such as data on your hard drive. The USB drive doesn't have to be large in modern terms either, most likely a 1GB one will do nicely for a quick test of base system with X (some details have changed since http://bsdly.blogspot.no/2010/01/goodness-of-men-and-machinery.html was written in January 2010, but the size of the sets is in fact smaller today after the comp set got pruned for a bit of old cruft). - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: sendmail cannot deliver to cyrus-imapd(solved?)
You didn't provide a dmesg so I don't know what architecture you're on, but that code will certainly fail on i386 and other ILP32 archs because it assumes time_t is the same size as long. As of OpenBSD 5.5 it's now a long long, which is larger on ILP32 archs. That and other printing/scanning code should be using %lld and casting time_t values to (long long) explicitly, ala: snprintf(buf, sizeof(buf), %u MODSEQ_FMT %lld (%u) %lld %s, record-uid, record-modseq, (long long)record-last_updated, flagcrc, (long long)record-internaldate, message_guid_encode(record-guid)); Yes, I’m on i386 arch. --- OpenBSD 5.5-stable (SATURN) #0: Fri Jun 13 14:39:46 JST 2014 taka...@saturn.takaaki.atnifty.com:/usr/obj/sys/arch/i386/compile/SATURN cpu0: Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz (GenuineIntel 686-class) 2.67 GHz --- I understand that. I delete my patch patch-lib_util_h, and add new patch-imap_maibox_c. --- *** imap/mailbox.c.orig Sun Dec 2 04:57:54 2012 --- imap/mailbox.c Mon Jun 16 17:24:01 2014 *** *** 1960,1969 flagcrc ^= crc32_cstring(buf); } ! snprintf(buf, 4096, %u MODSEQ_FMT %lu (%u) %lu %s, ! record-uid, record-modseq, record-last_updated, flagcrc, ! record-internaldate, message_guid_encode(record-guid)); return crc32_cstring(buf); --- 1960,1969 flagcrc ^= crc32_cstring(buf); } ! snprintf(buf, 4096, %u MODSEQ_FMT %lld (%u) %lld %s, ! record-uid, record-modseq, (long long)record-last_updated, flagcrc, ! (long long)record-internaldate, message_guid_encode(record-guid)); return crc32_cstring(buf); --- rebuilt and worked well, too. But there are many other place that receive time_t value by “%lu” probably …. Thank you very much. --- Takaaki Kobayashi takaaki.kobaya...@nifty.com
Re: Very slow I/O under OpenBSD i386 on qemu-kvm from RHEL7rc
On Mon, Jun 16, 2014 at 11:19:16AM +0200, Christiano F. Haesbaert wrote: On 16 June 2014 04:19, Mikolaj Kucharski miko...@kucharski.name wrote: My main question is, do you experience similar slow I/O on OpenBSD i386 on your Qemu/KVM installations? Are you aware of any problem with OpenBSD i386 under Qemu/KVM? Not sure should this report go to RedHat, KVM or to OpenBSD, but I've tested RHEL7rc with CentOS 6.5, NetBSD 6.1.4 installer and OpenBSD current bsd.rd and only OpenBSD i386 seems to have slow I/O problem under latest Enterprise Linux from RedHat. I've decided to report the issue here. I've tested OpenBSD guest with IDE, SCSI and VirtIO disk. SCSI disk currently don't seem to work at all with both amd64 and i386: The problem is the i386 ioapic/apic implementation and how OpenBSD uses the lapic_tpr to block incoming interrupts. Giving what you wrote, where do you think the problem should be fixed? On OpenBSD side, or on KVM side? Basically if you're using ioapic (and you are), OpenBSD maps the lapic_tpr to the special TPR register to block interrupts everytime you get an interrupt of raise it yourself by splraise()/spl* and so on. You don't suffer this on amd64 since the masking is done purely in software. You can also verify this statement by disabling mpbios on OpenBSD and falling back to the old pic controller, in this case you I cannot find how to enable 'the old pic controller' in libvirt with qemu-kvm. Do you know by any chance how to enable it? don't use ioapic, and the pic code does the mask in software, lapic_tpr is still the same variable being touched, but in this code path, it's not mapped to the cpu TPR. To have an ideia of the cost of touching the tpr: real hardware: ~25 cycles. kvm + flexpriority (cpu extension): ~2700 cycles. kvm without flextpriority: 100k+ cycles. So every interrupt you take needs to touch at least lapic_tpr twice, which before would cost ~50cycles, and now it's more than ~200kcycles. Of course these numbers are relevant to the machine I've tested, but you get an idea on how much slower it is. Thank you for the above explanation. -- best regards q#
Re: signing release files
On 06/16/14 15:56, Jiri B wrote: On Sun, Jun 15, 2014 at 05:09:20PM -0400, Ted Unangst wrote: On Sun, Jun 15, 2014 at 14:12, Aaron Gomez wrote: I looked at the signify command but I can't figure out how to check all the files and then create the SHA256.sig. I tried signify -S -s myprivatekey.sec -m SHA256 -x SHA256.sig but that just created a file SHA256.sig with the following contents: untrusted comment: signature from signify secret key RWQ/YLxjYycyl9yO0Qz8OyKSG9NnreWqIqIvMrJ64hJ2XqsXcElZB8BW8h/tGfvR44cRyAlIk10pUntzg9R0Z1p5+e+1tHFzkAs= You need the -e flag to embed the message into the signature. I then ran sha256 against all of the files and copied the output to the SHA256.sig file, created a new install cd and tried again. This time it failed telling me that I used the incorrect key. The main problem is that the CD will attempt to verify against a key named openbsd-55-base.pub, which we ship. That's not going to match the private key you generated and are using. What do I need to do to make it so the installer can verify my newly created release files? The best approach, but it's more work, would be to change install.sh to look for a key like aaron-55-base.pub and add that to the ramdisk. The shortcut would be to replace the openbsd key, but that will only cause confusion later, so I'd try not to. That said, you probably don't need to sign releases you're building for yourself, unless they are travelling over untrusted links. We sign releases because they go from OpenBSD servers to you over the scary internet. If you control distribution, that's less scary. Wouldn't something like below make life easier? [diff to easily allow different keys] I think focus has been lost. What's the point of signing releases? To say This came from the OpenBSD project. Why? To make sure your release is a pure, untampered with version. Signed releases is not a goal, the goal is an install that is trusted by the installer (you). Signed releases are a way to help reach that goal. Don't forget that. IF your release is from the OpenBSD project, the signing should work fine. If your release is from some other souce...I WANT an alert saying This is not signed by OpenBSD! I don't want to squish the alert. It isn't there to hit a checkbox Code signed by someone. If your use is such that you DO want to certify that YOU created the files in question, that's great, ok, you have got a great mini-fork -- you can easily build your own release with your own keys and manage them appropriately, but a knob to get around the very point of release file signing is not really what I want to see. Nick.
Re: Very slow I/O under OpenBSD i386 on qemu-kvm from RHEL7rc
previously on this list Mikolaj Kucharski contributed: by disabling mpbios on OpenBSD and falling back to the old pic controller, in this case you I cannot find how to enable 'the old pic controller' in libvirt with qemu-kvm. Do you know by any chance how to enable it? I believe he means disabling mpbios at OpenBSD's boot or in boot.conf means KVM will automatically fall back. Virtual hosting companies like arpnetworks generally ask you to do this for OpenBSD. boot -c disable mpbios checkout man boot.conf -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
