pkg_add -u and unneeded updates
Folks, I noticed that, when I update my packages using pkg_add -u, some unneeded re-installation are performed; in particular (examples below are with the latest snapshot, Oct 23): - when a dependency needs update, all the dependencies and the package itself are updated: cups-1.7.5p2:openjpeg-1.5.1-1.5.1: ok cups-1.7.5p2:poppler-0.26.5-0.26.5: ok cups-1.7.5p2:poppler-utils-0.26.5-0.26.5: ok cups-1.7.5p2:foomatic-db-engine-4.0.11p0-4.0.11p0: ok cups-1.7.5p2:cups-filters-1.0.60-1.0.61: ok cups-1.7.5p2-1.7.5p2: ok - some packages are updated even if version is unchanged: xloadimage-4.1.22v0-4.1.22v0: ok xpdf-3.04-3.04: ok xzgv-0.9p4-0.9p4: ok According to pkg_add's man page the update signature of the candidate is compared to the signature of the already installed package: identical signatures mean no update needed so I think that signatures of those packages have changed w.r.t. the previous snapshot, but what's the rationale here? Thanks for any clarifications. All the best -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
Re: HEADS-UP: issues with chromium in -current
Hello! This is an older (still gtk+2 based) version of chromium: it doesn't have this bug. The bug started manifesting itself, when they switched to the new Aura toolkit (since version 37 iirc). It happened _after_ the switch to Aura which was in 36.0.1985.125 which is the version that will be in 5.6 release packages, that one was ok. Looking at chat logs, I first mentioned it in September, and I recall that the problem definitely existed with the version immediately before the use GPU accelerated cross process image transport on openbsd as well commit - as I was hoping that might fix it :-). I'm not totally sure because of the lock and lack of snapshots, but I think 36.0.1985.143 is probably okay. I can approve this, as I'm using Chromium 36.0.1985.143 (287914) on: OpenBSD 5.6-current (GENERIC.MP) #2: Fri Sep 5 15:59:11 EEST 2014 with Fluxbox for almost two months now, and it's working rock solid without any issues whatsoever. -- Karlis
Re: Libretto 70CT
Hi, Nick Holland wrote: Really, that's about when 16M became Just Too Little, it has been a long time. And...you know, I'm not going to apologize for that. :) 2.7 worked pretty well on 16M RAM, iirc. By 3.4, I'm pretty sure you were swapping before you completed a login. As a labor of love, you could strip a lot of stuff out of the kernel and see if you could make something that worked, but it really isn't worth it. Stripping the kernel helps quite a bit. Granted, I have 32MB of ram on my little OmniBook, but I can almost tare to run X11+xterm after I slimmed down the kernel to about half of its size. http://multixden.blogspot.it/2014/02/tailoring-openbsd-for-old-strange.html Riccardo
Re: Question about FAQ section 10.3
On 2014-10-24 Fri 15:29 PM |, Worik Stanton wrote: I installed postgresql (with pkg_add) and it did not change this, I had to change /etc/rc.local by hand. Is there some reason why postgresql should not be started after a reboot? Have I completely got the wrong end of the stick? You're very close. $ man rc.conf: ... .. It is advisable to leave rc.conf untouched, and instead create and edit a new rc.conf.local file. Variables set in this file will override variables previously set in rc.conf. The man page then gives an example of dhcpd. /etc/rc 'starts' /etc/rc.d/dhcpd, but its default flag in /etc/rc.conf is 'NO', so it doesn't start. To actually start dhcpd, override its flags in /etc/rc.conf.local $ fgrep dhcpd /etc/rc* /etc/rc:start_daemon relayd dhcpd dhcrelay mrouted dvmrpd /etc/rc.conf:dhcpd_flags=NO # for normal use: /etc/rc.conf.local:dhcpd_flags='' Then the man page then covers the 'pkg_scripts' variable, responsible for starting and stopping daemons installed from packages. -- Craig Skinner | http://twitter.com/Craig_Skinner | http://linkd.in/yGqkv7
Re: Question about FAQ section 10.3
On 14-10-24 03:57 AM, Craig R. Skinner wrote: On 2014-10-24 Fri 15:29 PM |, Worik Stanton wrote: I installed postgresql (with pkg_add) and it did not change this, I had to change /etc/rc.local by hand. Is there some reason why postgresql should not be started after a reboot? Have I completely got the wrong end of the stick? You're very close. $ man rc.conf: Adding to Craig's comments, no, OpenBSD packages generally do NOT modify /etc/rc.conf.local for you. Until very recently, /etc.rc.conf.local was executed as a shell script, so arbitrarily modifying things in a (possibly completely custom) shell script would be a Very Bad Thing. Recent changes mean that /etc/rc.conf.local is now parsed instead of being executed; the format syntax are now much more constrained, and AFAIK it would be possible for packages to now automatically make changes in a safe(r) way. However, I still don't expect to see that happen - it just doesn't feel like the OpenBSD way. If you want to run a process, you should have to perform some manual step to cause it to run. Processes that unexpectedly spring into existence at the next reboot are also considered (at least by me) a Bad Thing. -- -Adam Thompson athom...@athompso.net
Re: pkg_add -u and unneeded updates
Hi Alessandro, Alessandro DE LAURENZIS wrote on Fri, Oct 24, 2014 at 08:25:59AM +0200: I noticed that, when I update my packages using pkg_add -u, some unneeded re-installation are performed; Almost certainly not unneeded; Marc Espie@ has spent a lot of effort on getting that right. At least, you don't show any evidence for that claim, or for any bug in this area. [...] - some packages are updated even if version is unchanged: xloadimage-4.1.22v0-4.1.22v0: ok xpdf-3.04-3.04: ok xzgv-0.9p4-0.9p4: ok According to pkg_add's man page the update signature of the candidate is compared to the signature of the already installed package: identical signatures mean no update needed so I think that signatures of those packages have changed w.r.t. the previous snapshot, but what's the rationale here? packages(7): The full version (package name and dependency names) is known as the `update signature', and can be queried with pkg_info -S, for packages, or make print-update-signature for ports. Try it: $ pkg_info -S xpdf Information for inst:xpdf-3.04 Signature: xpdf-3.04, @ghostscript-fonts-8.11p2,@openmotif-2.3.4p0,@png-1.6.13, ICE.10.0,SM.9.0,X11.16.0,Xext.13.0,Xm.6.0,Xpm.9.0,Xt.11.0,c.77.2, freetype.22.0,m.9.0,png.17.2,pthread.18.1,stdc++.57.0,z.5.0 So, packages are automatically updated when new versions are available compiled again newer libraries or newer dependencies, even if the Makefile of the package itself (and hence its own version number) did not change. That prevents .libs-* packages from needlessly accumulating on your system. Yours, Ingo
Re: 2 VoIP phones on one line
On 2014/10/24 11:00, Rod Whitworth wrote: None of the STUN etc that have arrived, since I last looked, any good? STUN can help with weak forms of NAT as used on some simpler routers but won't help with a symmetric NAT (i.e. one that checks both the port numbers and addresses, like PF - if you're only used to PF NAT then reading a description of full cone NAT might come as a surprise ;) For symmetric NAT, one way or another you need the call media to come from a known point that the side behind NAT communicates with. The simple way to do this is by ignoring the addresses in SIP/SDP headers, using the packet addresses instead, and always proxying call audio (media), replying to the same port that they see your media coming from. comedia mode. This is quite commonly used in voip providers (either on their SIP registration servers, or via separate SBCs - session border controller appliances). There are other ways to do it, which can reduce (or at least spread) resource use on the provider side in situations with weak NAT / fully open SIP devices, but they mean 1) several different methods used on the provider side used in different situations (harder to debug) and 2) relying on the client to correctly implement more modern protocols. If I was a big voip provider I would likely only want to use these methods if I controlled the client side software as well as the server. In any event they only optimize decreasingly common cases. It's a different case for wholesale providers rather than the type of provider you'd use directly for phones - in that situation, it's fairly important for them to be able to split media and signalling (both for flexibility and to reduce latency) but making it easy for clients behind NAT isn't really a concern. Even in those cases you can often still work behind NAT without any special protocols (most phones/ATAs let you set your known external IP to use in headers, send frequent keepalives, and choose a particular port range for RTP - then port forwarding takes care of the rest). Summary: try it the easy way first - ignore all this stuff, just put the phone behind NAT without anything special, and see if it works. If it doesn't then try plan B. If it still doesn't work, you can get clues by watching pflog and the SIP messages (it's a text based protocol; tcpdump -s 1500 -A port 5060 will be readable, though ngrep -d iface -W byline port 5060 is probably easier on the eye).
Lakeside Townhouses - High Demand in Somerset West
[IMAGE] View in your browser | Unsubscribe How do you turn a good Somerset West investment into a great one? Just add water! 2 3 Bedroom Sectional Title Townhouses Now Selling from R1,3 million Including VAT. No transfer duty. Townhouse images (display images to view) YOUR ASSET 128 PROPERTIES SOLD! ⢠From 100 square metres to 145 square metres ⢠2 Bedroom homes include 2 covered parking bays outside your front door ⢠3 Bedroom homes include a garage and a covered bay outside your front door ⢠Your own private garden and patio ⢠High quality finishes include Hansgrohe taps and Gres Porcelain tiles Somerset lakes Your Estate Beach THE PROPOSITION Somerset lakes YOUR PEACE OF MIND ⢠Co-developed by Investec Specialist Bank ⢠Huge shortage of secure, quality rental accommodation in area ⢠Limited stock means outstanding capital growth in sought-after Somerset West ⢠Upmarket new shopping centre (Woolworths, Checkers, Clicks) just 900m from entrance gate [IMAGE] To have a professional property consultant contact you, please REPLY to this email or click one of the buttons below: EMAIL A CONSULTANT PLEASE CALL ME [IMAGE] Investec logo Somerset lakes logo 021 202 2200 ⢠sa...@somersetlakes.co.za ⢠www.somersetlakes.co.za [IMAGE][IMAGE]
Binat purpose?
Hi @misc, I've a topology which you can see at http://www.imagesup.net/?di=1214141397880 Modems are in bridge mode. OpenBSD is getting public addresses via pppoe. 1.1.1.1 is default gateway on OpenBSD. I'm trying to reach https server behind 2.2.2.2 ip address on pppoe1. So i have this rule for this aim: pass log quick from 192.168.101.168 to any binat-to 2.2.2.2 I see packets are reaching at 192.168.101.168 but no response. I think it's about reply-to / route-to but got no success with my tries. Can anyone tell me how to handle this issue please? -- Thanks Theron
5.6 arrived
OpenBSD 5.6 arrived Swansea UK today, 24 Oct 2014.
Re: Libretto 70CT
On Thursday, October 23, 2014 22:59 CEST, Fred open...@crowsons.com wrote: Hi Sebastian, I've just installed -current on my Libretto 70CT - as you can see from the output below it stoped with: kernel: integer divide fault trap, code=0 Rebooted it and disable it, schsio and softraid and it has now made it to the end of boot - but it has not yet made it to a login prompt. Last time I tried this I left it running for about a week - and still did not make it to a login prompt. As I wrote on ports@, my Libretto 60 with 32 MB RAM, and disabled it and schsio works, slow but, flawlessly. However no X, since ISA cards are not supported by xorg anymore. Sebastian hth Fred PS I've CC misc@ for the archives rather than clog up ports@ Script started on Thu Oct 23 21:10:34 2014 port:fred ~ cu -l /dev/cuaU0 Connected to /dev/cuaU0 (speed 9600) OpenBSD/i386 BOOT 3.26 boot \|/-\|/booting hd0a:/bsd: -\|/-9699132\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\+1067500 [72+403280|/-\|/-\|/-\|/-\|/-\|/-\+397651|/-\|/-\|/-\|/-\|/-\|/-\|]=0xb083b0 entry point at 0x200120 [ using 801416 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.6-current (GENERIC) #415: Wed Oct 22 11:33:32 MDT 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium/MMX (GenuineIntel 586-class) 121 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,MMX real mem = 16412672 (15MB) avail mem = 3915776 (3MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/11/97 apm0 at bios0: Power Management spec V1.2 pcibios at bios0 function 0x1a not configured bios0: ROM list: 0xe4000/0xc000 cpu0 at mainbus0: (uniprocessor) cpu0: F00F bug workaround installed isa0 at mainbus0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 vga0 at isa0 port 0x3b0/48 iomem 0xa/131072 wsdisplay0 at vga0 mux 1: console (80x25, vt100 emulation), using wskbd0 wsdisplay0: screen 1-5 added (80x25, vt100 emulation) wdc0 at isa0 port 0x1f0/8 irq 14 wd0 at wdc0 channel 0 drive 0: IBM-DDLA-21620 wd0: 16-sector PIO, LBA, 1551MB, 3177216 sectors wd0(wdc0:0:0): using BIOS timings sb0 at isa0 port 0x220/24 irq 5 drq 1: dsp v3.01 midi0 at sb0: SB MIDI UART audio0 at sb0 opl at sb0 not configured wss0 at isa0 port 0x530/8 irq 10 drq 0: CS4231 or AD1845 (vers 4) audio1 at wss0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 pcic0 at isa0 port 0x3e0/2 iomem 0xd/65536 pcic0 controller 0: Intel 82365SL rev 1 has sockets A and B pcmcia0 at pcic0 controller 0 socket 0 xe0 at pcmcia0 function 0 Xircom, CreditCard 10Base-T, PS-CE2-10 port 0x340/16, irq 9: address 00:80:c7:42:37:d9 pcmcia1 at pcic0 controller 0 socket 1 pcic0: irq 11, polling enabled vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets kernel: integer divide fault trap, code=0 Stopped at cpu_switchto+0x64: popl%ebx ddb ps PID PPID PGRPUID S FLAGS WAIT COMMAND 13605 0 0 0 2 0x14200crypto 21232 0 0 0 2 0x14200pfpurge 18646 0 0 0 2 0x14200pcic0,0,1 14390 0 0 0 2 0x14200pcic0,0,0 28330 0 0 0 2 0x14200apm0 1636 0 0 0 2 0x14200systqmp 12593 0 0 0 2 0x14200systq 9503 0 0 0 2 0x14200syswq 25602 0 0 0 1 0x14200idle0 2351 0 0 0 2 0x14200kmthread *1 0 0 0 7 0swapper 0 -1 0 0 3 0x10200 wdccmd
Re: Question about FAQ section 10.3
On 10/23/14 22:28, Worik Stanton wrote: On 24/10/14 14:53, Nick Holland wrote: On 10/23/14 21:36, worik wrote: Processes local and package scripts in /etc/rc.d is listed as the last thing rc does after boot. What does Processes mean in this context? like processing food -- do whatever needs to be done. (not my best analogy, I'll admit) [snip] Look at the /etc/rc script...yes it does execute each of the rc.d scripts, and yes it DOES pass start to them: [snip] now look how start_daemon is invoked... Interesting. In /etc/rc start_daemon is called for specific named scripts. Except that (at line 520) it runs it for all scripts in $pkg_scripts note here, because I get this confused myself: pkg_scripts are for added PACKAGES. Not stock stuff. PLUS...stock stuff is enabled in one way (daemon_flags=) vs. being added to pkg_scripts. My shell scripting is really bad (I am going to have to up my game there if I am going to stick around here) but it seems it is set to an empty string in rc.conf yep. Now it exists...but is empty. YOU get to set that. (Mis)reading the FAQ I thought it meant *all* scripts in /etc/rc.d were Processed. . It actually says ...local and packaged scripts So if a package wants to be sure it is run at startup does it write that into the rc.conf where mine says... processed...as appropriate. That may mean ignore. :) # rc.d(8) packages scripts # started in the specified order and stopped in reverse order pkg_scripts= I installed postgresql (with pkg_add) and it did not change this, I had to change /etc/rc.local by hand. Is there some reason why postgresql should not be started after a reboot? Have I completely got the wrong end of the stick? read through that section closer... for things you want to start and stop in the normal OpenBSD way, put them in rc.conf.local. rc.local is for things that the normal way isn't appropriate for. For example, I maintain a system where there is a daemon installed that is not perfectly stable -- it just shuts down once in a while. It would work just fine from its rc.d script -- until it stops. So, I've got a little script that runs it in a loop; when it crashes, wait a few seconds, then re-launch, and that's invoked in rc.local. Yes, there are lots of reasons why various packages should not be started at boot, and even more reasons why the ORDER of applications starting is critical, and something that only an administrator will know. For reasons of order alone, I don't think you will ever see pkg_add start daemons automatically. I know many DBAs who prefer that database engines are started manually. I'm not personally in agreement with that, I like my systems to fire up automatically at boot (something about enjoying uninterrupted vacations), but whatever, and having seen some really unstable apps, in some cases there might be good arguments for this, though the better logic would be fix your damn app!. Other packages have both daemon and userland modes -- rsync is one of those. You certainly don't want rsync running as a daemon just because you installed rsync. In a hostile network environment, you don't want unconfigured apps starting at boot. Install, configure, test, THEN configure to start at boot (then reboot to make sure it really works). Nick.
OpenBSD 5.6 Disks
Hi misc@ Just received my 5.6 disks in the post! Thanks to all the developers for your continued work in making another great OpenBSD release. Cheers Fred -- 5.6 in the wild: https://twitter.com/fcbsd/status/525618236667482112
Re: Question about FAQ section 10.3
athom...@athompso.net (Adam Thompson), 2014.10.24 (Fri) 11:19 (CEST): On 14-10-24 03:57 AM, Craig R. Skinner wrote: On 2014-10-24 Fri 15:29 PM |, Worik Stanton wrote: I installed postgresql (with pkg_add) and it did not change this, I had to change /etc/rc.local by hand. Is there some reason why postgresql should not be started after a reboot? Have I completely got the wrong end of the stick? You're very close. $ man rc.conf: Adding to Craig's comments, no, OpenBSD packages generally do NOT modify /etc/rc.conf.local for you. and now there's rcctl(8), so there is almost no reason to touch rc.conc.local(8) manually anymore. But be warned (it's biting me a bit): using ``rcctl disable xx'' doesn't just remove xx from pkg_scripts, it removes the xx_flags as well. In case you had carefully crafted command line parameters there, the simple ``rcctl disable'' command might make you unhappy. (rcctl disable is not reversed by rcctl enable, that is.) Question: why does rcctl disable xx not just remove xx from pkg_scripts? (But also removes xx_flags.) Removing the xx_flags could be done via ``rcctl disable xx flags '' if really wanted, no? And while I'm in asking mode: the rcctl(8) ``default'' command cannot have values for non-base services/daemons, right? Bye + TIA, Marcus Until very recently, /etc.rc.conf.local was executed as a shell script, so arbitrarily modifying things in a (possibly completely custom) shell script would be a Very Bad Thing. Recent changes mean that /etc/rc.conf.local is now parsed instead of being executed; the format syntax are now much more constrained, and AFAIK it would be possible for packages to now automatically make changes in a safe(r) way. However, I still don't expect to see that happen - it just doesn't feel like the OpenBSD way. If you want to run a process, you should have to perform some manual step to cause it to run. Processes that unexpectedly spring into existence at the next reboot are also considered (at least by me) a Bad Thing. !DSPAM:544a19e1213124755513058!
Re: pkg_add -u and unneeded updates
On Fri, Oct 24, 2014 at 08:25:59AM +0200, Alessandro DE LAURENZIS wrote: Folks, I noticed that, when I update my packages using pkg_add -u, some unneeded re-installation are performed; in particular (examples below are with the latest snapshot, Oct 23): - when a dependency needs update, all the dependencies and the package itself are updated: cups-1.7.5p2:openjpeg-1.5.1-1.5.1: ok cups-1.7.5p2:poppler-0.26.5-0.26.5: ok cups-1.7.5p2:poppler-utils-0.26.5-0.26.5: ok cups-1.7.5p2:foomatic-db-engine-4.0.11p0-4.0.11p0: ok cups-1.7.5p2:cups-filters-1.0.60-1.0.61: ok cups-1.7.5p2-1.7.5p2: ok - some packages are updated even if version is unchanged: xloadimage-4.1.22v0-4.1.22v0: ok xpdf-3.04-3.04: ok xzgv-0.9p4-0.9p4: ok According to pkg_add's man page the update signature of the candidate is compared to the signature of the already installed package: identical signatures mean no update needed so I think that signatures of those packages have changed w.r.t. the previous snapshot, but what's the rationale here? Look, either you use it as as simple user, and then you trust the tool. Or you want to really understand what's going on and you have to dig deeper. What pkg_add shows you *by default* is the simple story. Try pkg_add -v for more details. You'll figure it out.
Re: The Dao of pf?
On Fri, Oct 24, 2014 at 12:52 AM, Jack Woehr jwo...@softwoehr.com wrote: Steve Litt wrote: This time, I'd like to understand what I'm doing a little more. What are some broad principles of pf? Does pf have an overarching philosophy or architecture? Read the book :) http://www.amazon.com/Book-PF-No-Nonsense-OpenBSD-Firewall/dp/1593275897/ref=asap_B001JPCK0S_1_1?s=booksie=UTF8qid=1414126274sr=1-1 -- Jack Woehr # There's too much emphasis on things Box 51, Golden CO 80402 # like pawn structure in modern chess. http://www.softwoehr.com # Checkmate ends the game. - N. Short The book is what you need/want. Got 3rd version last week. No regret. -- - () ascii ribbon campaign - against html e-mail /\
Re: Question about FAQ section 10.3
Hi Marcus, Marcus MERIGHI wrote on Fri, Oct 24, 2014 at 02:22:55PM +0200: But be warned (it's biting me a bit): using ``rcctl disable xx'' doesn't just remove xx from pkg_scripts, it removes the xx_flags as well. In case you had carefully crafted command line parameters there, the simple ``rcctl disable'' command might make you unhappy. (rcctl disable is not reversed by rcctl enable, that is.) Question: why does rcctl disable xx not just remove xx from pkg_scripts? (But also removes xx_flags.) It's a carefully pondered design decision. The rcctl(8) utility is intended for use by management frameworks taking care of many machines at once. In such a context, it is useful to keep configuration files in a clean, normalized state, and information stored on individual machines is not only useless; in general, it even tends to obstruct automated changes. You don't have your carefully crafted flags in rc.conf.local(8) on one single machine, but in some central place. Of course, you are welcome to run it manually, too, but the requirements of management frameworks constrain the design quite a bit, so there is not that much room left for decisions to improve convenience for manual use. Removing the xx_flags could be done via ``rcctl disable xx flags '' if really wanted, no? Well, in case we would implement saving flags for disabled services, the quotes would be useless. Remember: rcctl enable identd flags - identd_flags=# in /etc/rc.conf.local - identd will start without flags rcctl enable identd flags - identd_flags= - identd will start with default flags (-e) rcctl enable identd - no change if already enabled - enable with default flags if disabled But i don't think we will support saving flags for disabled daemons. It's just additional complexity for little gain, and there is a risk to confuse people who look at /etc/rc.conf.local and don't remember whether it's a base or a package daemon. Besides, if you really want to keep the flags when disabling, firing up sudoedit(8) and manually editing pkg_scripts is not significantly more keystrokes than rcctl disable xx. And while I'm in asking mode: the rcctl(8) ``default'' command cannot have values for non-base services/daemons, right? It can: $ rcctl default wesnothd -d $ rcctl default saslauthd -a getpwent Yours, Ingo
Re: Question about FAQ section 10.3
Hello Ingo, first of all: thanks for taking the time! schwa...@usta.de (Ingo Schwarze), 2014.10.24 (Fri) 15:00 (CEST): Marcus MERIGHI wrote on Fri, Oct 24, 2014 at 02:22:55PM +0200: But be warned (it's biting me a bit): using ``rcctl disable xx'' doesn't just remove xx from pkg_scripts, it removes the xx_flags as well. In case you had carefully crafted command line parameters there, the simple ``rcctl disable'' command might make you unhappy. (rcctl disable is not reversed by rcctl enable, that is.) Question: why does rcctl disable xx not just remove xx from pkg_scripts? (But also removes xx_flags.) It's a carefully pondered design decision. The rcctl(8) utility is intended for use by management frameworks taking care of many Alright, thanks for the clue, this explains... (But I think I've carefully read everything publicly available wrt rcctl(8) lately. Are you guys hanging out on h..k..s@, again? ;-) Are you talking about existing (non-base) management frameworks or are you heading for an in-base management framework and rcctl is only the first step? (Talking about a ``management framework'' in base OpenBSD feels strange.) machines at once. In such a context, it is useful to keep configuration files in a clean, normalized state, and information stored on individual machines is not only useless; in general, it even tends to obstruct automated changes. You don't have your carefully crafted flags in rc.conf.local(8) on one single machine, but in some central place. Just started my central place. Of course, you are welcome to run it manually, too, but the I've seen instructions to do so on current.html. requirements of management frameworks constrain the design quite a bit, so there is not that much room left for decisions to improve convenience for manual use. ACK Removing the xx_flags could be done via ``rcctl disable xx flags '' if really wanted, no? Well, in case we would implement saving flags for disabled services, the quotes would be useless. Remember: rcctl enable identd flags - identd_flags=# in /etc/rc.conf.local - identd will start without flags rcctl enable identd flags - identd_flags= - identd will start with default flags (-e) rcctl enable identd - no change if already enabled - enable with default flags if disabled 1) *_flags= = no flags, not even default 2) *_flags= = default flags from rc.d/* script daemon_flags 3) *_flags=-param = use specified flags, not default But i don't think we will support saving flags for disabled daemons. ACK It's just additional complexity for little gain, and there is a risk to confuse people who look at /etc/rc.conf.local and don't remember whether it's a base or a package daemon. The gain for me would be little, but you guys usually have the broader picture. Besides, if you really want to keep the flags when disabling, firing up sudoedit(8) and manually editing pkg_scripts is not significantly more keystrokes than rcctl disable xx. Right, but from the point of view of rcctl I'm putting rc.conf.local in an inconsistent state then. But rcctl handles this gracefully, after manual removal of a service from pkg_scripts and leaving service_flags untouched a ``rcctl service enable'' just adds the service back to pkg_scripts and leaves service_flags alone. Since rcctl(8) appends the service to the pkg_scripts, the order of your ``rcctl enable xx flags '' commands might matter. And while I'm in asking mode: the rcctl(8) ``default'' command cannot have values for non-base services/daemons, right? It can: $ rcctl default wesnothd -d $ rcctl default saslauthd -a getpwent You cought me there; the default values are the daemon_flags within the individual rc.d(8) script. I assumed (yes, I know...) these were in rc.conf. Again, thanks for your time and knowledge! Bye, Marcus !DSPAM:544a4d8a299169175019724!
Re: 5.6 arrived
On Fri, 24 Oct 2014 12:21:15 +0100 Maurice McCarthy m...@mythic-beasts.com wrote: OpenBSD 5.6 arrived Swansea UK today, 24 Oct 2014. So does this mean I should download and install 5.6 to power my OpenBSD/pf firewall/NAT/router? SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance
Re: 5.6 arrived
sl...@troubleshooters.com (Steve Litt), 2014.10.24 (Fri) 17:41 (CEST): On Fri, 24 Oct 2014 12:21:15 +0100 Maurice McCarthy m...@mythic-beasts.com wrote: OpenBSD 5.6 arrived Swansea UK today, 24 Oct 2014. So does this mean I should download and install 5.6 to power my OpenBSD/pf firewall/NAT/router? The requested URL /pub/OpenBSD/5.6/ was not found on this server. Buying CDs and fast shipping makes a difference. Twice a year. Bye, Marcus
Re: 5.6 arrived
sl...@troubleshooters.com (Steve Litt), 2014.10.24 (Fri) 17:41 (CEST): On Fri, 24 Oct 2014 12:21:15 +0100 Maurice McCarthy m...@mythic-beasts.com wrote: OpenBSD 5.6 arrived Swansea UK today, 24 Oct 2014. So does this mean I should download and install 5.6 to power my OpenBSD/pf firewall/NAT/router? The requested URL /pub/OpenBSD/5.6/ was not found on this server. Buying CDs and fast shipping makes a difference. Twice a year. Yes, that is how it works. For almost 20 years, the CDs have arrived in people's mail a few days before OpenBSD arrives on the Internet. If we did it the other way around, it wouldn't arrive on the Internet at all.
Re: Libretto 70CT
On Thu, Oct 23, 2014 at 10:08:31PM -0400, Nick Holland wrote: On 10/23/14 19:17, Fred wrote: On 10/23/14 23:30, Mike Larkin wrote: On Thu, Oct 23, 2014 at 09:59:04PM +0100, Fred wrote: Hi Sebastian, I've just installed -current on my Libretto 70CT - as you can see from the output below it stoped with: kernel: integer divide fault trap, code=0 Rebooted it and disable it, schsio and softraid and it has now made it to the end of boot - but it has not yet made it to a login prompt. Last time I tried this I left it running for about a week - and still did not make it to a login prompt. hth Fred PS I've CC misc@ for the archives rather than clog up ports@ Script started on Thu Oct 23 21:10:34 2014 port:fred ~ cu -l /dev/cuaU0 Connected to /dev/cuaU0 (speed 9600) OpenBSD/i386 BOOT 3.26 boot \|/-\|/booting hd0a:/bsd: -\|/-9699132\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\+1067500 [72+403280|/-\|/-\|/-\|/-\|/-\|/-\+397651|/-\|/-\|/-\|/-\|/-\|/-\|]=0xb083b0 entry point at 0x200120 [ using 801416 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.6-current (GENERIC) #415: Wed Oct 22 11:33:32 MDT 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium/MMX (GenuineIntel 586-class) 121 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,MMX real mem = 16412672 (15MB) avail mem = 3915776 (3MB) For what it's worth, 16MB doesn't appear to be enough anymore. qemu with 16MB hangs at the same place as you're reporting, but configuring it for 20MB RAM seems to boot ok. It's pretty slow but it does work. -ml Memory is definately an issue on my Libretto 70CT - but I think there might be more to it especially when you go back to 4.4 when if first displayed this issue... I might consign it to OpenBSD 4.3 :~) Really, that's about when 16M became Just Too Little, it has been a long time. And...you know, I'm not going to apologize for that. :) 2.7 worked pretty well on 16M RAM, iirc. By 3.4, I'm pretty sure you were swapping before you completed a login. As a labor of love, you could strip a lot of stuff out of the kernel and see if you could make something that worked, but it really isn't worth it. Nick. It isn't. We will all laugh at you if you change GENERIC/GENERIC.MP and then post a bug.
X11 screen blanking issue
on a thinkpad X60s this works: xset dpms force off this doesnt: xset +dpms xset dpms 0 0 300 anybody has an idea how can i make the screen blanking work? OpenBSD 5.6-current (GENERIC.MP) #442: Thu Oct 23 13:25:47 MDT 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM) Duo CPU L2400 @ 1.66GHz (GenuineIntel 686-class) 1.67 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF real mem = 2137354240 (2038MB) avail mem = 2090131456 (1993MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 03/31/11, BIOS32 rev. 0 @ 0xfd690, SMBIOS rev. 2.4 @ 0xe0010 (67 entries) bios0: vendor LENOVO version 7BETD8WW (2.19 ) date 03/31/2011 bios0: LENOVO 1705CTO acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT SSDT SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) DURT(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 166MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) Duo CPU L2400 @ 1.66GHz (GenuineIntel 686-class) 1.67 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xf000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus 4 (EXP2) acpiprt5 at acpi0: bus 12 (EXP3) acpiprt6 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB7 acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 97 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 42T4629 serial 327 type LION oem SANYO acpibat1 at acpi0: BAT1 not present acpibat2 at acpi0: BAT2 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) bios0: ROM list: 0xc/0xea00! 0xcf000/0x1000 0xd/0x1000 0xe/0x1! cpu0: Enhanced SpeedStep 1663 MHz: speeds: 1667, 1333, 1000 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82945GM Host rev 0x03 vga1 at pci0 dev 2 function 0 Intel 82945GM Video rev 0x03 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1024x768 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel 82945GM Video rev 0x03 at pci0 dev 2 function 1 not configured azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: msi azalia0: codecs: Analog Devices AD1981HD, 0x/0x, using Analog Devices AD1981HD audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 1 int 20 pci1 at ppb0 bus 2 em0 at pci1 dev 0 function 0 Intel 82573L rev 0x00: msi, address 00:16:d3:b6:19:57 ppb1 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: apic 1 int 21 pci2 at ppb1 bus 3 ath0 at pci2 dev 0 function 0 Atheros AR5212 rev 0x01: apic 1 int 17 ath0: AR5424 10.3 phy 6.1 rf5424 10.2 eeprom 5.3, WOR2W, address 00:19:7e:4c:f7:1f ppb2 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x02: apic 1 int 22 pci3 at ppb2 bus 4 ppb3 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x02: apic 1 int 23 pci4 at ppb3 bus 12 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 1 int 16 uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x02: apic 1 int 17 uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x02: apic 1 int 18 uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x02: apic 1 int 19 ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x02: apic 1 int 19 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb4 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xe2 pci5 at ppb4 bus 21 cbb0 at pci5 dev 0 function 0 Ricoh 5C476 CardBus rev 0xb4: apic 1 int 16 Ricoh 5C552 Firewire rev 0x09 at pci5 dev 0 function 1 not configured sdhc0 at pci5 dev 0 function 2 Ricoh 5C822 SD/MMC rev 0x18: apic 1 int 18 sdmmc0 at sdhc0 cardslot0 at cbb0 slot 0 flags 0 cardbus0 at cardslot0: bus 22 device 0 cacheline 0x8, lattimer 0xb0 pcmcia0 at cardslot0 ichpcib0 at pci0 dev
Re: X11 screen blanking issue
ok, it seems a paused mplayer could be the reason. is that expected? -f -- if you stand up to be counted someone will take your seat.
Re: X11 screen blanking issue
On 2014-10-24, frantisek holop min...@obiit.org wrote: ok, it seems a paused mplayer could be the reason. is that expected? Yes. MPlayer disables screen blanking. When you watch a movie, you usually don't press keys or move the mouse, but you still don't want your screen to switch off. MPlayer restores the screen blanker on exit. It usually manages to do so when crashing, too. -- Christian naddy Weisgerber na...@mips.inka.de
Re: X11 screen blanking issue
Christian Weisgerber, 24 Oct 2014 21:46: On 2014-10-24, frantisek holop min...@obiit.org wrote: ok, it seems a paused mplayer could be the reason. is that expected? Yes. MPlayer disables screen blanking. When you watch a movie, you usually don't press keys or move the mouse, but you still don't want your screen to switch off. i agree, but usually the screen moves :) i think the state should be restored also upon pausing the movie, at least it makes sense to me. -f -- in hell, you can't send people to hell...
Re: X11 screen blanking issue
On 10/24/14 20:57, frantisek holop wrote: Christian Weisgerber, 24 Oct 2014 21:46: On 2014-10-24, frantisek holop min...@obiit.org wrote: ok, it seems a paused mplayer could be the reason. is that expected? Yes. MPlayer disables screen blanking. When you watch a movie, you usually don't press keys or move the mouse, but you still don't want your screen to switch off. i agree, but usually the screen moves :) i think the state should be restored also upon pausing the movie, at least it makes sense to me. I'd say this falls very much under the category of personal preference. Sounds like you are assuming if you pause the movie, that no one cares what is on the screen -- i.e., bathroom trip, answer the phone, etc. While often the case, there's a whole different reason: Because you wish to see and examine what is on the screen at that moment. You really don't want a display in the middle of a discussion of the fine points of composition of the scene to suddenly go blank because the computer decided you are having a long stop at the bathroom, right? That's somewhat of a long-standing tradition: I have a 60+ year old movie projector which does much the same thing -- when you pause the movie, a heat filter is put in between the projector bulb and the film to keep the bulb from melting the film, and if I recall properly, the fan kicks up in speed a bit to keep the air moving past the film and the filter from over heating. You COULD just power down the projector, too...but that's the off switch, not the pause lever. Personally, I'm slowly losing interest in screen blanking. LCD screens draw little power when on, they don't burn like CRTs did. I do often let the blanker turn the screens off for me, but that's mostly because I know it will, if I'm not lazy, I'll hit the power switches on the monitors. A laptop plugged into the wall...why power down the screen at all? A laptop running on batteries...if you aren't going to use it, why not just suspend it? No, I don't fully embrace what I'm advocating there, but I'm having trouble explaining to myself why I don't. I find myself annoyed by blanking far more often than I say, I'm so glad my screen just blanked, and I'm inclined to think that means I'm doing it wrong. Nick.
Re: multiple calls to OpenSSL_add_all_algorithms
On 10/23/14 11:33, Stuart Henderson wrote:
On 2014-10-22, Martijn van Duren martijn...@gmail.com wrote:
I'm currently trying to write a library that heavily relies on
libcrypto. Because I don't want applications linking to it, to have to
call OpenSSL_add_all_algorithms, for convenience, I added those calls to
the appropriate places in my library. Because of this nature, the
function is called multiple times, and even if I shielded it within my
library it could still be called outside of it by an application using
my library.
fwiw, Asterisk ran into this, this was the result:
http://reviewboard.asterisk.org/r/1006/
Sorry, forgot that misc@ removed attachments.
This time inline:
Index: ./objects/o_names.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/objects/o_names.c,v
retrieving revision 1.18
diff -u -p -r1.18 o_names.c
--- ./objects/o_names.c 12 Jun 2014 15:49:30 - 1.18
+++ ./objects/o_names.c 23 Oct 2014 21:30:33 -
@@ -94,6 +94,8 @@ obj_name_cmp(const void *a_void, const v
const OBJ_NAME *a = (const OBJ_NAME *)a_void;
const OBJ_NAME *b = (const OBJ_NAME *)b_void;
+ if (a == NULL || b == NULL)
+ return -1;
ret = a-type - b-type;
if (ret == 0) {
if ((name_funcs_stack != NULL)
Re: multiple calls to OpenSSL_add_all_algorithms
On Sat, Oct 25, 2014 at 07:00, Martijn van Duren wrote:
On 10/23/14 11:33, Stuart Henderson wrote:
On 2014-10-22, Martijn van Duren martijn...@gmail.com wrote:
I'm currently trying to write a library that heavily relies on
libcrypto. Because I don't want applications linking to it, to have to
call OpenSSL_add_all_algorithms, for convenience, I added those calls to
the appropriate places in my library. Because of this nature, the
function is called multiple times, and even if I shielded it within my
library it could still be called outside of it by an application using
my library.
fwiw, Asterisk ran into this, this was the result:
http://reviewboard.asterisk.org/r/1006/
Sorry, forgot that misc@ removed attachments.
This time inline:
Index: ./objects/o_names.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/objects/o_names.c,v
retrieving revision 1.18
diff -u -p -r1.18 o_names.c
--- ./objects/o_names.c 12 Jun 2014 15:49:30 - 1.18
+++ ./objects/o_names.c 23 Oct 2014 21:30:33 -
@@ -94,6 +94,8 @@ obj_name_cmp(const void *a_void, const v
const OBJ_NAME *a = (const OBJ_NAME *)a_void;
const OBJ_NAME *b = (const OBJ_NAME *)b_void;
+ if (a == NULL || b == NULL)
+ return -1;
ret = a-type - b-type;
if (ret == 0) {
if ((name_funcs_stack != NULL)
This can't be correct. That will sometimes sort NULL objects to the
front and sometimes to the back. It has to be one way or the other
(and that's assuming it's not an error to sort NULL objects in the
first place).
