Re: quirks "unsigned package," "Can't find CONTENTS"
On Thu, Oct 6, 2016 at 11:48 PM, Foo74 wrote: > > Thanks for posting the response. Do you know what from the error message > shows that it was a -current build? I think I would have spent days figuring > that out. :) Replying to list as well- There were two clues. One was how uname -a reported the kernel as GENERIC.MP#2172 - that number on the end would tell someone more "in the know" that it wasn't the right build for either "release" or "current" The other hint was in the error itself, as Josh emailed this morning: "Just to briefly elaborate, the development branch (-current) recently had updates to signed package management, and to signify(1), and these developments are both still ongoing / evolving." Which makes me think- that name that says "GENERIC"- would be good to have the flavor in it.
Re: quirks "unsigned package," "Can't find CONTENTS"
>Your package path points to 6.0- release. But your error messages > indicate you've installed a snapshot of -current, the development > breach. Use snapshot packages, or install the release. Thanks! You're right, I had intended to install 6.0 from release, but ended up getting a snapshot ISO. I'll get them back in sync.
quirks "unsigned package," "Can't find CONTENTS"
I'm installing OpenBSD i386 on a fresh new hard drive, I've set PKG_PATH, and I can't add packages- my tries give errors about quirks. Trying a bare "pkg_add quirks" tells me: # pkg_add quirks Error from http://mirrors.mit.edu/pub/OpenBSD/6.0/packages/i386/quirks-2.241.tgz unsigned package Can't find CONTENTS from http://mirrors.mit.edu/pub/OpenBSD/6.0/packages/i386/quirks-2.241.tgz Error from http://mirrors.mit.edu/pub/OpenBSD/6.0/packages/i386/quirks-2.241.tgz unsigned package Can't find CONTENTS from http://mirrors.mit.edu/pub/OpenBSD/6.0/packages/i386/quirks-2.241.tgz --- quirks-2.241 --- Can't install quirks-2.241: bad package Can't install quirks-2.241: bad package # uname -a OpenBSD elided.example.org 6.0 GENERIC.MP#2172 i386 Turning up the verbosity with -vvv it shows another error, "Can't load quirk: Can't load OpenBSD/Quirks.pm in @INC" I feel like I'm missing something very basic. Any ideas on debugging, fixing pkg_add on this install? -y
Re: Best filesystem & options for large drive
Thanks all for the tuning flags & the example. I'll take a look at the man pages and file set. Doesn't look like the 4TB FFS2 will be a problem on this machine after all.
Best filesystem & options for large drive
I'm setting up an openBSD 5.6 box with a 4TB raid to back up a video editing cluster. I'll be using BackupPC which likes to have a single large volume so it can de-duplicate files using hard links. Thus the main volume will be all the 4TB. I know FFS2 can handle that size easily, but I'm worried about fsck taking forever. This machine will have 1.5GB RAM, from what I've read that's not enough memory to fsck a 4TB volume without painful swapping. Is there some filesystem-plus-options for recent OpenBSD that guarantees the disk will always be in a consistent state, even after a crash, so that fsck won't be necessary? (Yes I'll be testing out the RAID before deploying, would like to start with the right filesystem on it from the outset. And yes it will be on a UPS with graceful shutdown. I don't trust myself to get it all right, and bad things still happen...) -y
Re: Fixing pkg_add "Fatal error: can't parse object version" error after 4.9 upgrade
>On Tue, Jun 07, 2011 at 11:57:42AM -0700, yary wrote: >> I have installed my own build of perl into /usr/local which might be >> the cause- though it can also happen with the system perl, All one has >> to do is install a binary/XS version of a library that system perl has >> a non-binary version of, in a directory that the system perl uses. > > Ariane van der Steldt wrote: >Don't do that. No, it can't happen with the system perl, we control that. It happens, though I'm not sure why or how to prevent it. Note that in 4.9 the system perl looks in some /usr/local directories before /usr/libdata - $ /usr/bin/perl -e 'print join "\n",@INC' /usr/local/libdata/perl5/site_perl/i386-openbsd /usr/libdata/perl5/site_perl/i386-openbsd /usr/local/libdata/perl5/site_perl /usr/libdata/perl5/site_perl /usr/libdata/perl5/i386-openbsd/5.12.2 /usr/local/libdata/perl5/i386-openbsd/5.12.2 /usr/libdata/perl5 /usr/local/libdata/perl5 The right way to fix this is to have all the /usr/libdata paths before any /usr/local paths in the system perl's @INC. Order them like so: /usr/libdata/perl5/site_perl/i386-openbsd /usr/libdata/perl5/site_perl /usr/libdata/perl5/i386-openbsd/5.12.2 /usr/libdata/perl5 /usr/local/libdata/perl5/site_perl/i386-openbsd /usr/local/libdata/perl5/site_perl /usr/local/libdata/perl5/i386-openbsd/5.12.2 /usr/local/libdata/perl5 Here's a scenario- and I don't have a 4.8 system to test it on, just from memory- In OpenBSD 4.8, using only the system perl, install the XS version of Digest::SHA. OBSD 4.8 uses perl 5.10. This isn't so farfetched. Even if 4.8 comes with a binary Digest::SHA, it may have an update that you want. Perl decides to put it under /usr/local/libdata/perl5/site_perl/i386-openbsd/ Upgrade the same machine to OpenBSD 4.9. It uses perl 5.12 which is not binary-compatible with perl 5.10 Now any system utilities that use Digest::SHA will get the version in /usr/local/libdata/perl5/site_perl/i386-openbsd , at the top of @INC. Not sure if that's what happened to me (or the other poster at http://comments.gmane.org/gmane.os.openbsd.misc/185763 ) but it's my most plausible guess
Fixing pkg_add "Fatal error: can't parse object version" error after 4.9 upgrade
Hi, I saw another message about getting a perl error 'Fatal error: can't parse object version..." after an upgrade to 4.9, and have a fix and an explanation. Fix: add this line: no lib qw(/usr/local/libdata/perl5 /usr/local/libdata/perl5/i386-openbsd/5.12.2 /usr/local/libdata/perl5/site_perl /usr/local/libdata/perl5/site_perl/i386-openbsd); to the start of these libs, near the "package" declaration: /usr/libdata/perl5/OpenBSD/Error.pm /usr/libdata/perl5/OpenBSD/Paths.pm Explanation: In a /usr/local directory is a shared library from a different version of perl- Digest::SHA- and it's a binary (aka XS or .so) version. I have installed my own build of perl into /usr/local which might be the cause- though it can also happen with the system perl, All one has to do is install a binary/XS version of a library that system perl has a non-binary version of, in a directory that the system perl uses. System perl programs only need libraries in these directories, which yo probably will never install anything into- /usr/libdata/perl5 /usr/libdata/perl5/i386-openbsd/5.12.2 /usr/libdata/perl5/site_perl /usr/libdata/perl5/site_perl/i386-openbsd My "no lib" solution tells systerm Perl programs to ignore the /usr/local perl libraries. Not sure if those two modules cover all system perl programs, but it works for the pkg_* ones for sure. -y
Re: Do you virtualize w/OpenBSD as host?
On 22/01/07, Joachim Schipper <[EMAIL PROTECTED]> wrote: On Mon, Jan 22, 2007 at 12:42:03PM -0800, yary wrote: For real virtual stuff, qemu works well - although not exactly swiftly. It's usable for testing, but don't try to run it in production. If you can handle being a little less virtual, chroot + systrace allows you to build specialized mini-systems with good security and performance. This can be rather useful for running, for instance, several disconnected daemons on a single server; OTOH, it's completely useless if you are trying to do kernel development work. So it depends on what you are trying to do; however, since very few of those virtualization systems will allow you to run a different kernel from the one you are running on the host, this is not that big a loss. Finally, while OpenBSD does not run many virtualization environments, it does run *in* most virtualization environments. At least VMWare should work, and Xen is being developed [1]. Joachim [1] Or might be ready, or might be abandoned - I'm afraid I'm not certain here. I have two uses in mind, one is trying out/debugging network scenarios, the other is creating a virutal machine where a couple trusted users can set up some network services (webserver, svn repository) separate from my own. The first pretty much requires some kind of virutalization, and the second is much easier with it, AFAIK. For now, I don't have any pressing network problems, and I'm just going to set up a separate machine from surplus hardware for my friends. Would like to have some VM stuff to play with so have the experience if/when I need it (plus, it seems "fun"), prefer to stay within OpenBSD, easier on my brain.
Re: Do you virtualize w/OpenBSD as host?
On 22/01/07, Stuart Henderson <[EMAIL PROTECTED]> wrote: qemu is less elegant than, say, dfbsd virtual kernels but it works pretty well. Hadn't heard about DragonFly virtual kernels, they do look cool, but they aren't yet ready for prime time and there isn't anything like it in OpenBSD! Still thanks for the tip, will keep my eyes on it.
Do you virtualize w/OpenBSD as host?
Hello, wondering what state-of-the-art is for running virtual machines under OpenBSD. I don't see anything with particularly good performance (like Solairs "zones"), which would be great, but anything resonable would work for my purposes- I don't really need the blazing speed. I want to run a few virutal OpenBSD servers under my "real" OpenBSD 4.0 server for testing and some light work, and am wondering about qemu/bochs/other choices? If you're using virtual-OpenBSDs under real-OpenBSD, let me know your preferred setup!
Re: pre-orders
You want more donations, you put the donations link in more places. Yes it's easy for someone looking for it to find it- but how about the businessman whose sysadmin just said "we should look at openBSD 3.9"- he'll search for & see that 3.9 release page, and not know that his department is about to get some software that needs monetary support. If each release page contained a blurb: "This release was made possible by private donations and businesses' monetary support. Please click here to see how you can help fund developer's work for your next release, OpenBSD 4.0" (or whatever the next release is)- it would raise awareness of OpenBSDs reliance on donations, and would bring it to the attention of some who never see the home page. Which will probably bring more money in, for not very much incremental effor.
Re: OBSD 3.8: bash, libiconv, libintl in rc.securelevel
On 3/7/06, Chris 'Xenon' Hanson <[EMAIL PROTECTED]> wrote: > yary wrote: > > Pardon me for giving what may be a naive answer, but how about putting > > /usr/local/lib into the LD_LIBRARY_PATH env variable before starting > > the wanrouter script? > >It's an obvious answer, but I figured there must be a good reason > (security?) that > /usr/local/lib _isn't_ in the LD_LIBRARY_PATH at that stage, and it didn't > seem like a > good idea for an installer to tamper with the system's LD_LIBRARY_PATH. > Partly I'm looking > for insight as to why it is the way it is currently. I can see it being a security thing, but you only have to set that environment variable for the subshell that's starting the wanrouter, not for the whole system at that stage of boot. This seems to work for /bin/sh: $ (export fff=rrr && echo $fff) rrr $ echo $fff $ You have to trust /usr/local enough to run the port/package in the first place... so try launching wanrouter with "(export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib && /bin/bash /usr/local/bin/wanrouter)" - your startup script will add the local libs to its search path but the rest of that bootup stage won't. And if that's incorrect someone will surely point out the error of my ways! -y
Re: OBSD 3.8: bash, libiconv, libintl in rc.securelevel
On 3/7/06, Chris 'Xenon' Hanson <[EMAIL PROTECTED]> wrote: >I'm working on getting the Sangoma WANPIPE driver working under OpenBSD > 3.8 (mostly > working) and ran into a couple of little problems that I'm trying to find the > "right" way > to solve. > >The preferred setup is to run their "wanrouter" bash script in the > rc.securelevel > script, to load the driver module before securelevel is raised to where > module loading is > no longer permitted. > >So, the wanrouter script requires bash, which in turn requires libiconv > and libintl. > Libiconv and libintl normally install into /usr/local/lib, where bash finds > them just fine > once the system is fully booted. But, it seems that running the wanrouter > bash script from > rc.securelevel fails because at that point bash can't find libiconv and > libintl. I presume > that /usr/local/lib is not in the lib search path at that point. Pardon me for giving what may be a naive answer, but how about putting /usr/local/lib into the LD_LIBRARY_PATH env variable before starting the wanrouter script?
Re: EPIA issues...
I'll second the observation that hot machines flake in odd ways. It's not just the processor- hot memory is also unpredictable- hard drive controllers- "northbridge"- you name it- there are many essential parts that can overheat and cause you hard-to-diagnose grief. If cooling your machine doesn't work, could be a power supply issue, they seem to die before the rest of the computer and sometimes do so slowly. Low power also causes erratic behavior.
Re: dhcpd and static arp
On 2/16/06, yo2lux <[EMAIL PROTECTED]> wrote:
> I have a dhcp server with following configuration:
>
> /etc/dhcpd.conf
>
> shared-network LOCAL-NET {
>option domain-name "my.domain";
>option domain-name-servers 193.231.249.1;
>
>subnet 192.168.10.0 netmask 255.255.255.0 {
>option routers 192.168.10.1;
>
>range 192.168.10.32 192.168.10.127;
>}
> }
>
> host zoltan{
> hardware ethernet 00:50:FC:9D:81:E7;
> fixed-address 192.168.10.127;
> option host-name "zoltan";
> }
>
> 192.168.10.127 is my desktop pc (Windows box with mac address:
> 00:50:fc:9d:81:e7). I get IP 192.168.10.127 using DHCP.
So that part is working fine. dhcpd is doing what you asked it to- it
is assigning 192.168.10.127 to a machine with mac address
00:50:fc:9d:81:e7
> The problem is, when i set a manual IP address on Windows box for
> example 192.168.10.126 the connection between gateway and Windows box work.
dhcpd only assigns addresses, it doesn't set up network filters.
> I want to allow only IP adrress 192.168.10.127 with mac address:
> 00:50:fc:9d:81:e7 to reach the gateway. I need to use a static ARP?
no, static ARP isn't for filtering either.
I'm not quite sure what you want to happen. Here's my guess:
You want to specify which MAC addresses get which IP addresses- that
much you have working.
You want only those MAC & IP addresses assigned by DHCP to work with
your gateway. If an authorized machine changes their IP address, you
want the gateway to ignore its traffic. That part, I don't know how to
do either.
If you look at pf.conf you'll see it's easy to only allow traffic for
IP addresses in a given range, but it doesn't filter by MAC address-
that's not level 3 (if I have the jargon correct) it can be filtered
on a bridge, but adding a bridge is artificial, and anyway, how would
you tell dhcpd to add/remove filters as it granted/expired licenses?
Write a program to poll dhcpd.leases every few seconds? Ugly!
And you still have a problem- what if you have two authorized
machines, and the users switch their IP addresses...
If you really want this level of security (and I'm not sure that you
really do), what you want is the "user" option of pf.conf. I haven't
tried it, serch the pf list's archives for examples.
Re: Interface ranges in pf.conf (i.e. tun[0-10])
On 2/13/06, yary <[EMAIL PROTECTED]> wrote:
> Now, can one use a group name to set up a pool? eg:
> rdr on $ext_if proto tcp from any to any port 80 { httpd_ifs_group }
> round-robin
just read the referenced post from Henning- looks like my answer is "yes"!
Re: Interface ranges in pf.conf (i.e. tun[0-10])
On 2/13/06, Ray Lai <[EMAIL PROTECTED]> wrote:
...
> In this example ifconfig(8) shows that I have groups ``lo'' and
> ``egress'', so in the pf.conf you can stick an interface group
> (almost?) anywhere you can stick an interface. (Actually there's
> a missing interface group in this example: ``enc''. I'm not sure
> if it's a bug in ifconfig(8).) You can also add your own groups
> using ifconfig(8).
>
> pf.conf(5) doesn't describe interface groups, but you can find a
> description in ifconfig(8) under ``group''.
fascinating. Seems like I could do away with macros for interface
names in pf.conf- create groups with my symbolic names for the various
links and use those instead. Then pf.conf doesn't have to change when
NICs change, just the hostname.if files (which have to change anyway.)
Though I fiddle with my pf.conf far more often than I replace NICs.
Now, can one use a group name to set up a pool? eg:
rdr on $ext_if proto tcp from any to any port 80 { httpd_ifs_group } round-robin
Re: PF, anchors and macros
You can search for a thread on this list with the subject "how to manage big pf-rulesets in a comfortable way" - someone posted their makefile for adding a macro set to the start of pf rulesets.
Re: openbsd's future plans?
It's been a while since I've had the opportunity to code in RPG. Implementing an SMP kernel in an old IBM report generating language is an interesting challenge, and would open up the possibility of running OpenBSD 4.0 on card-sorting machines.
Re: Mixed internal network traffic, separated multiple ISPs, help?
My longish question left out critical pieces- the actual /etc/ files (pf.conf, hostname.*, bridgename.*) and tcpdump logs, I apologize. Thanks for reading and replying despite that. I'll be going another round tonight, and will follow up with concrete examples to the pf list, with a brief summary here to wrap it up. 'Til then here are my responses to the email so far- Stuart Henderson : >> If we could make all the phones go to one switch, connect that to one >> internal NIC, and all the PCs go to another switch, and into the >> second internal NIC, then this would be easy. I think. But we don't >> have the space or the hardware. > >You could run vlans, if your switch supports them. That's probably >the cleanest way. Ah, if only... there's only one port per office cube. PC plugs into a port on the phone, phone plugs into the wall jack, carries traffic for both VOIP and PC. So the vlans would have to be set on the individual PCs and the phones. I don't think the phones support VLAN. Not positive on that though. I am pretty sure that as a temporary consultant, it would break after I left, unless the VLAN could be assigned to everyone DHCP. I don't see that in dhcpd-options (and it seems strange to serve non-vlan dhcp requests, telling all requestors to get themselves onto a specific vlan...) >> a smaller problem- how to specify what remote host to route-to in >> pf-conf when the interface is configured via DHCP? > >You don't.., use the normal routing table for this instead. In the original context, "route-to ($ext_if 44.33.22. 1)" worked, "route-to ($ext_if)" did not, nor did the pass rule without any route-to. But that's not very helpful without the full setup, and I would like to use the normal routing table as you suggest... That "small problem" can be restated: The best example I can find using route-to is at http://www.openbsd.org/faq/pf/pools.html - it uses a syntax like "route-to ($ext_if $ext_gw)" where $ext_gw2 is the remote gateway for $ext_if, defined as a dot-address macro. For what that example is doing, it can't "use the normal routing table instead," apparently. That page doesn't cover the case where $ext_if has a dynamic address. As far as I can tell, it can't be easily rewritten for an ISP that assigns a varying IP address/network. >From Tihomir Koychev: >Use PF specific pf@benzedrine.cx >Your question is there.There are a lots of mail with route-to, reply-to >and evil NAT.Forward you e-mail there and search with google or >http://marc.theaimsgroup.com/ (mailing list archive). Yup, that mailing list is being helpful, giving me more ideas to try out tonight. On 1/16/06, Todd T. Fries <[EMAIL PROTECTED]> wrote: > you do have a 20.0.0.x IP configured on the OpenBSD box as an 'inet alias' > in /etc/hostname.yourint_if, right?? I tried that without success. It doesn't make much sense to add that address as an alias anyway, when the OpenBSD box is supposed to transparently bridge traffic on the 20.0.0.x net. (My followup to "misc" mentioned that, my initial mis-post to "tech" didn't.) more later, stay tuned...
Mixed internal network traffic, bridge+NAT separated to multiple ISPs, help?
I've struggled for a couple days configuring an OpenBSD router/firewall and would like some help from the experts. Short version: There's an internal network with voice-over-IP phones and PCs. The phones have publicly routable addresses, and for them, the OpenBSD router should act like an addressless bridge. The router also all assigns PCs private addresses via DHCP, and gives them access to the big bad internet via pf's NAT. I can get the bridge to work for the phones, I can get the NAT to work for the PCs, but not both at the same time reliably. If you've done this please tell me how. Longer version: VOIP Phones (public 20.0.0.x/24) mixed with Office PCs (private 192.168.1.x/24) ||| \V/ HW switch | $int_if OpenBSD router (192.168.1. 1) | +--- $ext_if for "PCs ISP" (configured via dhclient) +--- $voip_if for "Phone ISP" (either no addy or 20.0.0. 225, route to 20.0.0. 1) The OpenBSD router has 3 NICs- $int_if faces the single internal switch that all the VOIP phones and office PCs connect to. $voip_if faces an ISP that's assigned us public IPs for all the phones, and we can use one of those for $voip_if itself. $ext_if faces another ISP, and gets its address, gateway, and DNS servers via DHCP. The VOIP phones have publicly routable addresses, all assigned from the 20.0.0. 0/24 CIDR block. The office PCs get their addresses via DHCP from the OpenBSD router in the private 192.168.1. 0/24 network. All the VOIP traffic is to flow through the OpenBSD router, between $voip_if and $int_if. All other external traffic is to travel over $ext_if. The router itself needs to be ssh'able, serve DHCP to the internal network, and provide other services later. Plugging the VOIP ISP directly into our internal switch works, but then we're bypassing our OpenBSD router for that traffic. We want to tweak that traffic later, after the basic setup works, so bypassing is not an option. Tried so far: A. http://www.openbsd.org/faq/pf/pools.html looked promising. I set up pf so that 20.0.0. 0/24 "route-to" ($voip_if 200.0.0. 1) and !20.0.0. 0/24 "route-to" ($ext_if 44.33.22. 1), with a nat on $ext_if from 192.168.1. 0/24 -> ($ext_if) This worked great for all the PCs, they could see the outside world just fine. But the phones got no traffic at all. "tcpdump -i $int_if net 20.0.0. 0/24" showed no traffic. My guess is that the OpenBSD box didn't advertise that $int_if was a route for that traffic. And why should it? $int_if has the address 192.168.1. 1, that's not on the 20.0.0. 0/24 net. a smaller problem- how to specify what remote host to route-to in pf-conf when the interface is configured via DHCP? ($ext_if) will resolve to a changing interface address, but there's no way I can find to symbolicly use that interface's remote router. I had to look up its address in /var/db/dhclient.leases.$ext_if and hard-code that (44.33.22. 1 in our example). If our upstream ISP decides to change what network it assigns to us, then the router on the other end changes, and the "route-to" breaks B. Add a bridge for the phone traffic. "ifconfig bridge0 create; brconfig bridge0 add $int_if add $voip_if up" - created /etc/bridgename.bridge0 to do just that at boot. Added rules to pf.conf so only 20.0.0. 0/24 traffic would flow through $voip_if. Keep the route-to for the PC traffic so it keeps going to $ext_if. With the bridge the phones work great! Can call out, can recieve incoming calls. And the PCs work too! For a while... when the phones are unused, everything is great. But pick up a phone, and some of PCs lose all connections. They can't even get responses to "ping 192.168.1. 1" And hanging up/disconnecting the phones after doesn't fix the problem. I can't predict which PCs will lose connections or when, it seems random. Some PCs continue to work! tcpdump shows some 192.168.1.x traffic "leaking" onto bridge0. Even traffic for "ping 192.168.1. 1" sometimes shows up on bridge0. I tried changing pf.conf to have just the required NAT and "pass all", loaded that with pfctl -F all -f pf.conf, that didn't fix it. In act of desparation tried to add a rule to pf.conf by IP address on bridge0 itself, but pfctl -vs rules showed that it never matched. I know that brconfig can add rules at the bridge level to filter on MAC address, but that seems difficult to maintain when adding/swapping phones regularly. I tried adding a 200.0.0.x address as an alias to $int_if, which didn't seem to make any difference. I'm lost. I suspect my difficulties stem from a my lack of route(8) knowledge. A co-worker is building another OpenBSD box with 4 NICs, so there can be one internal NIC for VOIP traffic, and another for the office PCs. While that seems conceptually cleaner, all the traffic will be going through the same HW switch- and I forsee similar issues. If we could make all the phones go to one switch, connect that to one internal NIC, and all the PCs go to another switch, and into the second i
