Re: Optimizing chmod(1)
On 16-03-13 11:11 PM, Michael McConville wrote: It seems that chown(1) will write to a file even if it already has the desired ownership. The below patch causes it to skip the write when there would be no change. The best I could tell, the fts_read(3) and fchownat(3) logic agree on whether to follow symlinks in all cases, so there's no need to execute a useless write when certain options are specified. I get a speedup of 5-10% on SSDs, and probably more on a slow storage HD. This is when all the files are already owned by the specified user. I think this is a common case, as chown is often used to "comb out" offending files, ensure that a server can access everything in /var/www, etc. The APIs involved are not simple and there's potential for subtle breakage, so this only an initial patch. I'm interested to hear what more experienced people think. If it's worthwhile, a similar approach can probably be applied to chmod(1) et al. as well. If this becomes the default behaviour, please allow a way to revert to the previous behaviour, as this change would break several real systems I'm aware of, including one I currently manage. There are many NFS implementations where chown(2)/chmod(2) do magic on the back end, ranging from "clearing the UID/GID translation cache" (huh?) to resetting the file to default ACLs (e.g. Sun/Oracle "Fishworks"-series NAS systems). To rephrase: chown(file,$owner,$gid) when the file is already owned by $owner:$gid is _not necessarily_ a no-op on all filesystems. As an extra option, though, sure; I know which filesystems this behaviour matters on and which it doesn't, but there's no realistic way to embed that knowledge into chmod - there's no standard query to ask an NFS server "do you practice voodoo?", for better or for worse... GNU already uses "-c" for a somewhat-related behaviour (modifies the output of -v, but not the internal behaviour IIRC); I can't quickly find anything similar anywhere else. FWIW, full support for NFSv4 and NFS ACLs would eliminate the dependency on chown/chmod/etc. doing voodoo on the remote NFS server, but there are other, non-NFS, remote filesystems that do similar things. I can't remember if OpenBSD still supports any of them, though. -Adam
Re: Make uftdi(4) support aftermarket FTDI devices
On 2016-02-21 04:16 PM, Gregor Best wrote: On Sun, Feb 21, 2016 at 12:41:06PM -0700, Theo de Raadt wrote: It makes no sense to renumber the FT232_1 entry. That is just creating churn. As to the 0x entry, I'm wondering whether it should be named something like the following, as a historical reminder: +product FTDI FT232_JERKS 0x Serial [...] Nice idea. I've added the "bricked" device as FT232_JERKS, with a slightly longer description that hints at the reasoning behind the name: While I agree that bricking the pirated device was a step too far on FTDI's part, FT232_PIRATED would be a more appropriate name. They did quickly rescind that driver, and it was after all a direct (if clueless and inappropriate) reaction to blatant criminal activity against them. If you want to immortalize their faux pas, FT232_CLUELESS_COMPANY would be more accurate than _JERKS. Yes, I'm defending FTDI - up to a point, anyway. (There are only two hard things in programming: naming.) -Adam
Re: Thinkpad active cooling
On 2015-07-14 09:13 PM, Michael McConville wrote: On Wed, Jul 15, 2015 at 03:04:07AM +0200, Tobias Ulmer wrote: Theo is asking for affected models, so lets compile a list. All my Thinkpads can be provoked into shutdown due to overtemp because the fan doesn't spin up: T60 T61 X201 I've had it happen on my X201, but only once in the ~6 months I've had it. I was building a Coq library with all four cores in a hot lab. It's survived many other build beatings without issue, and I've never noticed a problem with the fans. I'm not questioning that it could be improved, though. FWIW, the X201t can trivially hit thermal throttling under Windows 7 (using the OEM image, even) if you exercise the GPU (easiest way: play a Flash game), although not into complete thermal shutdown. It's a hardware design flaw, not a firmware problem. I've never had my x201t actually hit the thermal limit under OpenBSD - at least not that I've noticed. I don't use it for CPU-intensive work, and I'm not even sure how I would go about exercising the GPU under OpenBSD without Adobe Flash :-). Although I agree the fan speed handling under OpenBSD still has room for improvement... I haven't run OpenBSD on it for any significant amount of time since the ~recent changes to improve Thinkpad power usage. -- -Adam Thompson athom...@athompso.net
Re: [DIFF] /etc/rc: gracefully shut down base daemons too
On 2015-02-20 11:12 AM, Ingo Schwarze wrote: Hi Craig, Craig Skinner wrote on Fri, Feb 20, 2015 at 04:41:17PM +: Changed to skip pflogd, syslogd check /var/run/rc.d/ No, we don't want it, and we have given reasons: It makes the code longer, more fragile, and provides no known benefit whatsoever. Fixing the most blatant downsides does not change that. Which problem are you trying to solve? Yours, Ingo Two daemons that would very much matter are ospfd and bgpd. Normally, doing a clean shutdown of bgpd is the LAST thing I want, because that would break BGP graceful-restart - that capability relies on BGP simply disappearing. If I shut down BGPd, I withdraw all my prefixes. A clean shutdown of BGP can take several minutes; only very rarely would I want to sit and wait for BGPd to shut down before rebooting. (Ospfd would be similarly affected IIRC.) And by the time we get to special-casing half the daemons in base, what's the point? Doing a clean shutdown of nfsd (or lockd or statd) would be harmful to certain clients that would otherwise survive the nfsd reboot. Ditto for iked, sasyncd, iscsid, ldpd, and possibly even ntpd (not sure about that one). Client-server protocols are generally written to retry on, or otherwise be resilient to, failure; signalling shutdown when I have to kick the server in the head for some reason (which, yes, even happens with OpenBSD :-)) would be a bad thing for some to many clients. -- -Adam Thompson athom...@athompso.net
Re: ksh version lies
On 2015-02-17 08:06 PM, John Merriam wrote: I definitely agree that the silliness of checking a version string to possibly use some exotic or non-standard feature of a particular flavor of a particular family of shells is not a good idea when writing a shell script. If you can't do what you want without relying on that particular feature then maybe what you're writing shouldn't be a shell script. If it's a bug in a particular flavor of a shell, then instead of checking for and working around it, report the bug to the author/maintainer. Jumping in late in the conversation... This is not an academic point; as an ISV, I've had to do this sort of thing in the past, and will have to do so again in the future. There is no standard or universal way to detect what version of what shell happened to get invoked on what operating system, so an ISV must rely on tricks and silliness like checking the version string to make what amounts to an educated guess. For example, I have a customer that must run a specific (non-current) version of HP-UX due to hard dependencies in a mission-critical line-of-business app. Yes, that means there's a foundational problem, but it would cost ~$100M to fix now. Not going to happen. Report the bug to the author/maintainer is all very well, but HP isn't going to issue a patch for an old version of HP-UX just because one customer complains about /bin/ksh behaving badly. (Actually, they very well might, given sufficient financial incentive, but that's another story altogether...) Meanwhile, portable shell scripts must continue to run - portably - across multiple OSes. Array handling is the big bugbear I run into; if I can handle arrays inside the shell, I don't have to resort to using tmpfiles and fork/exec'ing multiple external utilities to simulate the functionality. Which means, firstly, determining if I'm inside something ksh-like or bash-like, or if I'm running in a simple POSIX shell. There are virtually no safe assumptions that can be made in portable shell scripting - how was the script invoked? Sourced? Hash-bang? Explicit /bin/sh script invocation? It's a mess, despite POSIX' attempt to unify things; the choice is to either code for lowest-common-denominator, which typically results in payloads up to 10x larger and that run up to 10x slower, or to probe for advanced features and exit cleanly and safely if they're absent. -- -Adam Thompson athom...@athompso.net +1 (204) 291-7950 - cell +1 (204) 489-6515 - fax
PATCH: ntpctl.8, ntpd.c
Fix a minor typo in the ntpctl help output, and same semantic mistake in the manpage. Currently says (to be pedantic) that '-s' only works with 'all', which is not the case: '-s' is required with all options. Apologies if I've got the patch format wrong, I don't do this often... -Adam --- ntpd.c_r1.92Fri Feb 13 21:43:39 2015 +++ ntpd.c Fri Feb 13 21:43:49 2015 @@ -90,7 +90,7 @@ if (strcmp(__progname, ntpctl) == 0) fprintf(stderr, - usage: ntpctl [-s all | peers | Sensors | status]\n); + usage: ntpctl -s [all | peers | Sensors | status]\n); else fprintf(stderr, usage: %s [-dnSsv] [-f file]\n, __progname); --- ntpctl.8_r1.7 Fri Feb 13 21:39:53 2015 +++ ntpctl.8Fri Feb 13 21:40:32 2015 @@ -22,7 +22,8 @@ .Nd control the Network Time Protocol daemon .Sh SYNOPSIS .Nm ntpctl -.Op Fl s Cm all | peers | Sensors | status +.Fl s +.Op Cm all | peers | Sensors | status .Sh DESCRIPTION The .Nm -- -Adam Thompson athom...@athompso.net +1 (204) 291-7950 - cell +1 (204) 489-6515 - fax
Re: Should we allow to configure twice the same IP?
On 14-10-28 05:55 AM, Martin Pieuchot wrote: There's nothing that prevent you to configure the same IPv4 address on different interfaces in the same routing domain. But does it make sense? Index: netinet/in.c === RCS file: /home/ncvs/src/sys/netinet/in.c,v retrieving revision 1.106 diff -u -p -r1.106 in.c --- netinet/in.c7 Oct 2014 08:47:28 - 1.106 +++ netinet/in.c28 Oct 2014 10:23:07 - @@ -616,6 +616,10 @@ in_ifinit(struct ifnet *ifp, struct in_i splsoftassert(IPL_SOFTNET); + /* Make sure this address does not exist in the given rdomain. */ + if (ifa_ifwithaddr(sintosa(sin), ifp-if_rdomain)) + return (EEXIST); + if (newaddr) TAILQ_INSERT_TAIL(in_ifaddr, ia, ia_list); It might be needful when reconfiguring networks; if I swap two interfaces' IP addresses in /etc/hostname.* and re-run /etc/netstart instead of rebooting, I suspect this might break - I believe there would be a very brief overlap where two interfaces had the same IP address. Come to think of it, I'm not even sure whether this even works or not as-is; any opinions on what would be the canonical approach to swapping IPs between interfaces on a live system? Just do it by hand? Write your own script? Use netstart? Or just reboot? -- -Adam Thompson athom...@athompso.net
Re: lynx: disable old protocols
For the rest of us who prefer to use software instead of demanding changes, this simply means using OpenBSD in a strictly-isolated environment becomes a bit more difficult. I'm still not willing to use Linux LiveCDs in certain environments for the most part, and I'll just get used to having the ports I absolutely need (probably elinks or Firefox, at this point, not lynx!) on a pre-burned CD. Related question: what happened to putting the most commonly-used pkgs on the CDs? Did we just run out of room? My 5.5 CD set has a grand total of about 8 packages IIRC. Most of us get that you're all hacking on OpenBSD primarily to scratch a personal itch and secondarily to provide something good to the rest of the world. I recall reading somewhere a summary of the tech@ attitude, which boiled down to if you can use our code, great, otherwise go away and stop bothering us. I'll keep providing opinions and feedback, but even (sizeable) donations to the foundation don't earn me the *right* to be heeded. Apologies for the noise on tech@, but moving to misc would be even worse. -Adam On July 16, 2014 4:08:09 PM CDT, STeve Andre' and...@msu.edu wrote: On 07/16/14 17:00, Shawn K. Quinn wrote: On Wed, 2014-07-16 at 13:56 -0500, patric conant wrote: I'd also like to point out that Shawn has broken the social contract here, it's well known that it's generally considered rude to direct developers, in this forum. Every single free or open-source software project I have ever used has been shaped by user feedback. Most take it seriously when users say they still use functionality that's being slated for removal. So Patric, you can take this social contract of yours and shove it up your ass. I don't recognize it as anything but toilet paper. Shawn, I'm sorry but that's really out of line. Lynx will move to ports, which is the best of both worlds. It may be of questionable quality, so not in base, but with lots of other software, also of questionable quality *but available to all*. So that's it. Case closed, in a reasonable manner, I think. --STeve Andre' -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: lynx: disable old protocols
I would know of its existence, but likely not install it. As I said, I have workarounds. I remember how bad the code was years ago, so I agree with the idea in general, but it will be a pain in the butt for me every once in a while :-(. -Adam On July 11, 2014 4:03:29 AM CDT, Theo de Raadt dera...@cvs.openbsd.org wrote: If lynx was removed from base, and only available in ports... how many of you would even know of it's existance and use it? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: lynx: disable old protocols
As a user, not a developer...
I still use finger, gopher, and news URLs at least once a year each. As a
user, I disagree with turning support for those schemes off completely.
Finger and news I can use another tool, and I'd concede that no-one really
*needs* a news reader in base. (I still find having a finger client of some
sort in base useful at one site, however.)
Gopher, however, is not as dead as everyone assumes.
I believe I can re-enable tn3270 and telnet schemes manually, which is fine. I
still use both of those fairly often.
The other protocols are irrelevant to me.
-Adam
On July 10, 2014 10:05:45 PM CDT, Daniel Dickman didick...@gmail.com wrote:
Patch below turns off the following ancient protocols built into lynx:
bibp, finger, gopher, and news.
For some urls, lynx will invoke an external command. Turn off telnet,
rlogin and tn3270 urls by defining them to false(1) as documented in
the
lynx manual.
Finally, turn off the file editor which can be accessed with
g.enter
using the --disable-dired switch.
ok to commit?
Index: Makefile.bsd-wrapper
===
RCS file: /home/cvs/src/gnu/usr.bin/lynx/Makefile.bsd-wrapper,v
retrieving revision 1.24
diff -u -p -u -r1.24 Makefile.bsd-wrapper
--- Makefile.bsd-wrapper 15 Apr 2014 20:55:42 - 1.24
+++ Makefile.bsd-wrapper 11 Jul 2014 02:47:31 -
@@ -5,7 +5,10 @@ CLEANFILES+= lynx.1
DPADD=${LIBSSL} ${LIBCRYPTO}
GNUCFLAGS= CC=${CC} CFLAGS=${CFLAGS} ${COPTS} ${OPT}
LDFLAGS=${LDFLAGS}
-CONFIGURE_ARGS= --with-ssl=/usr --enable-widec --enable-ipv6
--enable-debug
+CONFIGURE_ARGS= --with-ssl=/usr --enable-widec --enable-ipv6
--enable-debug \
+ --disable-bibp-urls --disable-finger --disable-gopher
--disable-news
\
+ --disable-dired
+
HTMLDIR= /usr/share/doc/html
HELPFILES= keystrokes/alt_edit_help.html keystrokes/bookmark_help.html
\
keystrokes/cookie_help.html keystrokes/dired_help.html \
@@ -39,12 +42,18 @@ config: .FORCE
PATH=/bin:/usr/bin:/sbin:/usr/sbin \
${GNUCFLAGS} \
INSTALL_PROGRAM=${INSTALL} ${INSTALL_COPY} ${INSTALL_STRIP} \
+ TELNET=/usr/bin/false \
+ RLOGIN=/usr/bin/false \
+ TN3270=/usr/bin/false \
sh ${.CURDIR}/configure --prefix=/usr --sysconfdir=/etc
--disable-color-style ${CONFIGURE_ARGS}
config.status:
PATH=/bin:/usr/bin:/sbin:/usr/sbin \
${GNUCFLAGS} \
INSTALL_PROGRAM=${INSTALL} ${INSTALL_COPY} ${INSTALL_STRIP} \
+ TELNET=/usr/bin/false \
+ RLOGIN=/usr/bin/false \
+ TN3270=/usr/bin/false \
sh ${.CURDIR}/configure --prefix=/usr --sysconfdir=/etc
--disable-color-style ${CONFIGURE_ARGS} ${CF}
lynx.1: ${.CURDIR}/lynx.man
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: lynx: disable old protocols
Pretty standard thing in several companies I do work for is to have an intranet page with http://, ssh://, telnet:// and finger:// (amazingly) links to various devices on the network. Having to read the source and escape to a shell would be somewhat worse than what I get on a base install today. IIRC, finger was how we got a quick status overview from... some piece of ATM switching gear? And yes, I actually do spend a noticeable amount of time at the text console, with no ports installed, when inside a foreign network. -Adam [Original message deleted] -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
growfs error message, lack of comprehension
On 5.4-RELEASE, I'm trying to use growfs to expand a root filesystem. I've grown the disk from 2GB to 10GB, I've used disklabel(8) to adjust the OpenBSD area and the size of partition 'a'. All those numbers line up. Rebooting into bsd.rd, copying /sbin/growfs to the ramdisk, and then using it (successfully, more or less), I still see this error: new filesystem size is: 3411480 frags Warning: 376928 sector(s) cannot be allocated. growfs: not enough new space I can see in growfs.c where that messages is being emitted, and I see the comment there that says The space in the new last cylinder group is too small, so revert back. I lack, however, a sufficiently low-level understanding of FFS internals to understand _why_ the space in the new last cylinder group is too small. dumpfs(8) reports cylgrp dynamic inodes 4.4BSD fslevel 3, which I vaguely understood to mean that cylinder groups were now dynamically-sized things...? So, per growfs, what is the space too small _for_ ? Too small for another cylinder group? How would I go about calculating how much more (or less) disk space I would need to make growfs happy, and not wasting ? Now waiting incoming cluebats :-( -- -Adam Thompson athom...@athompso.net
Re: procfs to die [was: CVS: cvs.openbsd.org: src]
I do use it occasionally, and I don't run -current so I wouldn't have noticed any breakage yet. I don't rely on it, however, it's a convenience feature that I very occasionally use, and only manually when I do. I can live without it if it dies; it was never a fully-featured implementation IMHO anyway. -Adam On June 22, 2014 4:22:16 PM CDT, Philip Guenther guent...@gmail.com wrote: If you're currently using procfs, please respond with exactly what parts of it are actually needed by the programs you run. Without a good reason to keep it, it'll be deleted, as I broke listing of /proc back in January and no one has noticed, suggesting that no one is actually using it... Philip Guenther -- Forwarded message -- From: Philip Guenther guent...@cvs.openbsd.org Date: Sun, Jun 22, 2014 at 2:15 PM Subject: CVS: cvs.openbsd.org: src To: source-chan...@cvs.openbsd.org CVSROOT:/cvs Module name:src Changes by: guent...@cvs.openbsd.org2014/06/22 15:15:51 Modified files: sys/arch/i386/conf: GENERIC Log message: PROCFS has been broken for months without complaints, so stop building it suggested by sthen@ -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: ftp(1) User-Agent
On 2014-06-12 11:32, Alexander Hall wrote:
On June 11, 2014
6:18:19 AM CEST, Lawrence Teo l...@openbsd.org wrote:
This diff
allows ftp(1) to change the User-Agent for HTTP(S) URL requests via the
FTPUSERAGENT environment variable (personally I prefer HTTPUSERAGENT but
FTPUSERAGENT is what's used by ftp(1) on other BSDs). This is useful
when fetching URLs that are sensitive to the User-Agent, such as sites
that send different content if you're using a mobile browser/device.
I generally dislike passing options as environment variables. The use
case you describe does not really strike me as something I'd have in my
$ENV.
Does any of the other ftp's have a corresponding switch for
it?
There are conflicting precedents.
curl provides -A/--user-agent
and wget provides -U/--user-agent, and neither appears to obey any
environment variable for setting the user agent string. OpenBSD, FreeBSD
and NetBSD's ftp(1) all use -A to mean something else, and none of
them appear to have a -U option yet.
As the OP mentioned, however,
{Net,Free}BSD's ftp(1) already uses $FTPUSERAGENT.
As a user, I don't
really care which way it happens. I can trivially either run ftp -U
$FTPUSERAGENT ... or (not assuming any particular shell) env
FTPUSERAGENT=blah ftp ... depending on what I'm trying to accomplish.
If I were trying to write something without checking the man page,
which would be rather unsmart, I would probably assume that OpenBSD
behaves like the other BSDs.
-Adam
Re: IPv6 by default
On Tue 29 Apr 2014 09:04:36 PM CDT, Theo de Raadt wrote: I know that what I proposed cannot go in at the moment. It's my end goal. The goal is ridiculous. If anything, it should be sorted by the best addresses first. Today the best addresses are IPv4. There is no dynamic method to determine best, but measurements all over the world show that IPv4 is better in every respect. Change that, then we can talk. ... Apply these kinds of changes to your entire production network, and report back in 6 months if you are still running them. You're right for almost all residential customers today and most business customers of incumbent providers. However, based on available evidence, IPv4 is not better than IPv6 in every respect for everyone. My IPv6 transit is free, and runs at 1Gbit/sec. (Thank you, Hurricane Electric. Yes, I know this will change someday.) My IPv4 transit is definitely not free, and runs at 100Mbit/sec. I have a /48 of IPv6 addresses, whereas I have only a /24 of IPv4 addresses. Both address blocks cost the same amount; the $/IP ratio is clear. IPv6 is clearly better for me, because I've taken steps to obtain native IPv6 transport. That fact skews my results. My own measurements show that for many services, Amazon's cloud being a notable example, native IPv6 provides noticeably lower latency than IPv4 - even when taking the same AS path. IPv4 routes tend to have higher hop-counts than the corresponding IPv6 routes. Using cpercival's tarsnap service as a test endpoint: from my workstation, the IPv4 route is 15 hops long and exhibits RTT in the 54msec range, whereas the IPv6 route is 9 hops long and 33msec. Google's public DNS servers are 13 [v4] vs. 11 [v6] hops and identical latency (32msec). Akamai is 8 [v4] vs. 6 [v6] hops, and nearly-identical latency, once I get past the local cache. My data (not just these two examples) shows native IPv6 having a noticeable performance advantage over IPv4. (It's not because of the 1Gb/100Mb links, either; my workstation is at the far end of a 20Mbit radio link from my routers.) In every case I can find, IPv6 is now at least as good as IPv4, and is often better in every respect. That conclusion does still flip 180 degrees around, for obvious reasons, when the only IPv6 connectivity is through a tunnel. I've been fully[*] dual-stacked for almost a year, and well over a year since I started preferring my IPv6 tunnel wherever possible. The redundant OpenBSD-based BGP routers were installed October 26th 2013 and were routing IPv6 shortly thereafter. The topology has changed several times over that period of time, and the addition of IPv6 has not created problems for me any more significant than IPv4 has. (Renumbering is exactly as much a PITA in v6 as v4, despite what some optimists still claim.) Yes, I have had to choose software that supports IPv6, but that's not difficult nowadays... the lack of DHCPv6 in base OpenBSD is the only major gap that I've had trouble filling. Overall, OpenBSD supports IPv6 extremely well, more than well enough to run my network, which is why I don't understand the determination to passive-agressively not endorse it. I don't know anyone who seriously believes, by this point, that IPv6 is not going to take over eventually. Yes, the entire industry is doomed to repeat its mistakes, that's blazingly obvious. Yes, IPv6 has some serious flaws, and as a protocol suite, it sucks rocks in many ways. Does that mean you have to actively resist fostering IPv6 adoption? OpenBSD is already the only free OS that handles IPv6 fragmentation correctly... and it certainly wouldn't be the first OS to prefer IPv6. (That would actually be Windows Vista, I believe. OK, that's not a glowing endorsement...) [*] except for one software management console that doesn't support IPv6 at all. My printers, my WiFi APs, even my CEPH cluster are all IPv6-native. The worst network-stack stupidity I've seen so far was on the WiFi AP, and it only affected IPv4. -- -Adam Thompson athom...@athompso.net
Re: IPv6 by default
On April 28, 2014 5:43:34 PM CDT, Kenneth Westerback kwesterb...@gmail.com wrote: On 28 April 2014 18:05, Simon Perreault si...@per.reau.lt wrote: Tech, Now that my AI_ADDRCONFIG diff is in, it's time to reveal my evil master plan: make getaddrinfo() return IPv6 results first by default. Why is the burden on everyone to provide 'valid' objections? Should not the burden be on you to at least hint at a point to this change? Given the miniscule IPv6 usage out there, why should IPv6 come first? Ken The diff below would be the end goal. I guess people will have valid objections to it. I'd like to know what they are. Would it be necessary/desirable to check all calls to getaddrinfo() in base and add AI_ADDRCONFIG to hints.ai_flags where needed? (i.e. pretty much everywhere except special cases which right now I can't think of any) Thanks, Simon Index: lib/libc/asr/asr.c === RCS file: /cvs/src/lib/libc/asr/asr.c,v retrieving revision 1.33 diff -u -p -r1.33 asr.c --- lib/libc/asr/asr.c 26 Mar 2014 18:13:15 - 1.33 +++ lib/libc/asr/asr.c 28 Apr 2014 21:43:52 - @@ -518,8 +518,8 @@ asr_ctx_create(void) ac-ac_options = RES_RECURSE | RES_DEFNAMES | RES_DNSRCH; ac-ac_refcount = 1; ac-ac_ndots = 1; - ac-ac_family[0] = AF_INET; - ac-ac_family[1] = AF_INET6; + ac-ac_family[0] = AF_INET6; + ac-ac_family[1] = AF_INET; ac-ac_family[2] = -1; ac-ac_hostfile = DEFAULT_HOSTFILE; Index: share/man/man5/resolv.conf.5 === RCS file: /cvs/src/share/man/man5/resolv.conf.5,v retrieving revision 1.44 diff -u -p -r1.44 resolv.conf.5 --- share/man/man5/resolv.conf.514 Jul 2013 19:44:39 - 1.44 +++ share/man/man5/resolv.conf.528 Apr 2014 21:43:52 - @@ -217,8 +217,8 @@ For example: .It Cm family Specify which type of Internet protocol family to prefer, if a host is reachable using different address families. -By default IPv4 addresses are queried first, -and then IPv6 addresses. +By default IPv6 addresses are queried first, +and then IPv4 addresses. The syntax is: .Bd -ragged -offset indent .Cm family Ar family Op Ar family While I'm aware this post is futile, you just answered your own question. The point of making such a change is to help change that situation. This is somewhat like saying the burden should be on all browser users to manually enable support for TLSv1.2, because hardly any web servers use it. Someone has to take the first/next step, and that's a very traditional role for OpenBSD. Having said all that, I'm on the fence about this - nice idea in theory, but the timeout issue is difficult to live with, and adds an unnecessary barrier to new OpenBSD users. And before you ask, I *have* put my money where my mouth is - I'm 100% native IPv6 all the way to the 'net (at 5x the cost of just getting a much faster IPv4 service). At present, over 10% of my traffic is v6, but only *after* I manually edited resolve.conf to default to v6. -Adam -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: ffs2 boot
Given the single-threaded nature of much of the kernel, what applications do you run where multiple CPUs makes much of a difference to OpenBSD? Also, switching from IDE to any of the supported SCSI, SAS or SATA disk types also produces a noticeable improvement. I'm not sure if those are available in every KVM implementation or just the Proxmox-integrated version... IIRC they're available in RHEV too, so most likely they're standard. -Adam On April 17, 2014 11:34:19 AM CDT, Giancarlo Razzolini grazzol...@gmail.com wrote: Em 17-04-2014 07:34, Abel Abraham Camarillo Ojeda escreveu: On Thu, Apr 17, 2014 at 5:31 AM, Brandon Mercer yourcomputer...@gmail.com wrote: It will take me about that long to newfs the 10 kvm's I plan on using ;) On Thu, Apr 17, 2014 at 5:09 AM, Otto Moerbeek o...@drijf.net wrote: On Wed, Apr 16, 2014 at 11:16:00PM -0700, Philip Guenther wrote: On Thursday, April 17, 2014, Otto Moerbeek o...@drijf.net wrote: ... But bear in mind that ffs2 has more overhead in terms of metadata. IMO, making it the default is not a good idea. You have fewer than 24 years left to enjoy FFS v1... and I plan to enjoy every minute of that period! -Otto I found it really fast to work with kvm/openbsd if you use -drive ...,if=virtio ... like 4x-5x times faster than if=ide -the default- I use everything virtio and the performance difference is quite notable. The only complain is that openbsd won't see more than one processor, no matter what you do. -- Giancarlo Razzolini GPG: 4096R/77B981BC -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: ffs2 boot
Yes, but the very nature of the discussion concerns VMs, where the point is to multiplex the physical CPUs into multiple VMs in user-controllable chunks. A VM with one vCPU is perfectly reasonable and normal. I've found that having multiple cores available can speed up a desktop, and certain classes of cpu-bound server applications, and not much else. Those applications are not many; databases (sometimes), web servers (sometimes), application servers (often). The fact my router has 8 cores available doesn't really help it very much. (Maybe BGP converges a little bit faster?) Ditto for my DNS servers, my mail server, my proxy server, etc. So, I would like to know what application Giancarlo has where he actually notices the lack of multiple cores. -Adam On April 17, 2014 12:23:44 PM CDT, Otto Moerbeek o...@drijf.net wrote: On Thu, Apr 17, 2014 at 12:22:44PM -0500, Adam Thompson wrote: Given the single-threaded nature of much of the kernel, what applications do you run where multiple CPUs makes much of a difference to OpenBSD? Come on, a machine runs multiple processes... Also, switching from IDE to any of the supported SCSI, SAS or SATA disk types also produces a noticeable improvement. I'm not sure if those are available in every KVM implementation or just the Proxmox-integrated version... IIRC they're available in RHEV too, so most likely they're standard. -Adam On April 17, 2014 11:34:19 AM CDT, Giancarlo Razzolini grazzol...@gmail.com wrote: Em 17-04-2014 07:34, Abel Abraham Camarillo Ojeda escreveu: On Thu, Apr 17, 2014 at 5:31 AM, Brandon Mercer yourcomputer...@gmail.com wrote: It will take me about that long to newfs the 10 kvm's I plan on using ;) On Thu, Apr 17, 2014 at 5:09 AM, Otto Moerbeek o...@drijf.net wrote: On Wed, Apr 16, 2014 at 11:16:00PM -0700, Philip Guenther wrote: On Thursday, April 17, 2014, Otto Moerbeek o...@drijf.net wrote: ... But bear in mind that ffs2 has more overhead in terms of metadata. IMO, making it the default is not a good idea. You have fewer than 24 years left to enjoy FFS v1... and I plan to enjoy every minute of that period! -Otto I found it really fast to work with kvm/openbsd if you use -drive ...,if=virtio ... like 4x-5x times faster than if=ide -the default- I use everything virtio and the performance difference is quite notable. The only complain is that openbsd won't see more than one processor, no matter what you do. -- Giancarlo Razzolini GPG: 4096R/77B981BC -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: dd gigabytes
GNU dd definitely has it (along with the wholly-expected proliferation of other useless units). It's definitely not called for by POSIX. IIRC, Solaris supports some units but not others. HPUX doesn't support any units at all. Don't know what other BSDs or AIX support. -Adam On March 23, 2014 6:20:29 PM CDT, Theo de Raadt dera...@cvs.openbsd.org wrote: Fine with me. dd is often used in portable scripts. Do we need to document this as an extension, or has it already arrived in other implimentations? A gigabyte is like a megabyte, except it's bigger and better. This adds support for g/G suffixes. It also updates and corrects the comments in the source. Also move the goto label out of the if. Index: args.c === RCS file: /cvs/src/bin/dd/args.c,v retrieving revision 1.22 diff -u -p -r1.22 args.c --- args.c 12 Feb 2014 01:18:36 - 1.22 +++ args.c 23 Mar 2014 22:16:58 - @@ -312,13 +312,12 @@ f_conv(char *arg) /* * Convert an expression of the following forms to a size_t - * 1) A positive decimal number. - * 2) A positive decimal number followed by a b (mult by 512). - * 3) A positive decimal number followed by a k (mult by 1024). - * 4) A positive decimal number followed by a m (mult by 1048576). - * 5) A positive decimal number followed by a w (mult by sizeof int) - * 6) Two or more positive decimal numbers (with/without k,b or w). - * separated by x (also * for backwards compatibility), specifying + * 1) A positive decimal number, optionally followed by + * b - multiply by 512. + * k, m or g - multply by 1024 each. + * w - multiply by sizeof int + * 2) Two or more of the above, separated by x + * (or * for backwards compatibility), specifying * the product of the indicated values. */ static size_t @@ -341,18 +340,24 @@ get_bsz(char *val) goto erange; ++expr; break; -case 'k': -case 'K': +case 'g': +case 'G': t = num; num *= 1024; if (t num) goto erange; -++expr; -break; +/* fallthrough */ case 'm': case 'M': t = num; -num *= 1048576; +num *= 1024; +if (t num) +goto erange; +/* fallthrough */ +case 'k': +case 'K': +t = num; +num *= 1024; if (t num) goto erange; ++expr; @@ -374,23 +379,24 @@ get_bsz(char *val) t = num; num *= get_bsz(expr + 1); if (t num) -erange: errx(1, %s: %s, oper, strerror(ERANGE)); +goto erange; break; default: errx(1, %s: illegal numeric value, oper); } return (num); +erange: +errx(1, %s: %s, oper, strerror(ERANGE)); } /* * Convert an expression of the following forms to an off_t - * 1) A positive decimal number. - * 2) A positive decimal number followed by a b (mult by 512). - * 3) A positive decimal number followed by a k (mult by 1024). - * 4) A positive decimal number followed by a m (mult by 1048576). - * 5) A positive decimal number followed by a w (mult by sizeof int) - * 6) Two or more positive decimal numbers (with/without k,b or w). - * separated by x (also * for backwards compatibility), specifying + * 1) A positive decimal number, optionally followed by + * b - multiply by 512. + * k, m or g - multply by 1024 each. + * w - multiply by sizeof int + * 2) Two or more of the above, separated by x + * (or * for backwards compatibility), specifying * the product of the indicated values. */ static off_t @@ -413,18 +419,24 @@ get_off(char *val) goto erange; ++expr; break; -case 'k': -case 'K': +case 'g': +case 'G': t = num; num *= 1024; if (t num) goto erange; -++expr; -break; +/* fallthrough */ case 'm': case 'M': t = num; -num *= 1048576; +num *= 1024; +if (t num) +goto erange; +/* fallthrough */ +case 'k': +case 'K': +t = num; +num *= 1024; if (t num) goto erange; ++expr; @@ -446,10 +458,12 @@ get_off(char *val) t = num; num *= get_off(expr + 1); if (t num) -erange: errx(1, %s: %s, oper, strerror(ERANGE)); +
Re: httpd and nginx in base
On 13-11-11 07:06 PM, Stuart Henderson wrote: Help identify which ports currently rely on Apache from base, work out which ones can use nginx and move them across (updating READMEs etc where necessary), which can use apache2 from ports and move them across, and which (if any) won't work with either of these and require a port of the modified apache from base. smokeping. I still can't figure out how to get the CGI part to work under nginx/slowcgi. -- -Adam Thompson athom...@athompso.net
Re: Re : Re: Improve routing functions
On 13-11-04 05:09 PM, Claudio Jeker wrote: On Mon, Nov 04, 2013 at 10:36:39AM -0600, Adam Thompson wrote: The change I think we're both asking for is that in .../usr/sbin/bgpd/kroute.c, on line 505 (5.4-RELEASE), where we see kr-r.priority = RTP_BGP;, we need a way to override that value in (presumably) bgpd.conf. (Ditto for the IPv6 function.) Yes, this is the way to go. One thing to consider in some way is what you want to do if somebody changes the prio and the reloads the config. Or, in bgpd.conf(8) note under fib-priority that Changes to fib-priority will only take effect when bgpd(8) is restarted. Yeah, not ideal, but better than nothing. ldpd is a special beast and does not need to be changed but the other should be. (routed is dead, ripd ospfd and ospf6d all use a similar kroute.c file that also is used by bgpd so once one is done the others should be easier). ldpd does not insert new routes it only extends them with the MPLS info. Yes, it's unfortunate that routed(8) got removed from base. RIPv2 is a perfectly workable routing protocol in many situations. Wow, I didn't realize it's been missing since 4.4-release! Please someone not as overworked as me should just add the knobs to the routing deamons to allow setting a different prio. For example just a simple: fib-priority 45 would work. I can do doc changes, but I think you really, *really* don't want me writing much C code... I can perhaps do some of the initial, trivial, legwork, at best. Now, if bgpd(8) were written in Bourne/Korn shell, I'd be the guy to do this! -- -Adam Thompson athom...@athompso.net
Re: Re : Re: Improve routing functions
On 13-11-05 10:12 AM, Adam Thompson wrote:
I can do doc changes, but I think you really, *really* don't want me
writing much C code... I can perhaps do some of the initial, trivial,
legwork, at best. Now, if bgpd(8) were written in Bourne/Korn shell,
I'd be the guy to do this!
I recall now that I've never used yacc... Here's what I *can*
contribute, which is not much.
I wonder about including it as a global, per-neighbour, and per-match,
but it seems to be consistent with what's already implemented.
It would be acceptable to have it only as an attribute;
It would be more reasonable to have it as a global config item and an
attribute;
And at that point it may as well be settable on a neighbour basis, too.
--
-Adam Thompson
athom...@athompso.net
Index: bgpd.conf.5
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
retrieving revision 1.129
diff -u -p -r1.129 bgpd.conf.5
--- bgpd.conf.5 19 Oct 2013 15:04:25 - 1.129
+++ bgpd.conf.5 5 Nov 2013 17:45:23 -
@@ -206,6 +206,14 @@ dump all out /tmp/all-out-%H%M 300
dump updates out /tmp/updates-out-%H%M 300
.Ed
.Pp
+.It Ic fib-priority Ar priority
+If set, override the route priority value used to insert BGP routes
+into the kernel routing table. The default is
+.Ic RTP_BGP
+as defined in /usr/include/sys/net/route.h.
+.Pp
+Currently not implemented.
+.Pp
.It Xo
.Ic fib-update
.Pq Ic yes Ns | Ns Ic no
@@ -459,6 +467,14 @@ should be set to
.Ar rt
for best compatibility with other implementations.
.Pp
+.It Ic fib-priority Ar priority
+If set, override the route priority value used to insert BGP routes
+into the kernel routing table. The default is
+.Ic RTP_BGP
+as defined in /usr/include/sys/net/route.h.
+.Pp
+Currently not implemented.
+.Pp
.It Xo
.Ic fib-update
.Pq Ic yes Ns | Ns Ic no
@@ -757,6 +773,14 @@ The default value for IBGP peers is
otherwise the default is
.Ic yes .
.Pp
+.It Ic fib-priority Ar priority
+If set, override the route priority value used to insert BGP routes
+into the kernel routing table. The default is
+.Ic RTP_BGP
+as defined in /usr/include/sys/net/route.h.
+.Pp
+Currently not implemented.
+.Pp
.It Ic holdtime Ar seconds
Set the holdtime in seconds.
Inherited from the global configuration if not given.
@@ -1365,6 +1389,14 @@ bdc BGP Data Collection
.Pp
Not all type and subtype value pairs are allowed by IANA and the parser
will ensure that no invalid combination is created.
+.Pp
+.It Ic fib-priority Ar priority
+If set, override the route priority value used to insert BGP routes
+into the kernel routing table. The default is
+.Ic RTP_BGP
+as defined in /usr/include/sys/net/route.h.
+.Pp
+Currently not implemented.
.Pp
.It Ic localpref Ar number
Set the
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/bgpd/parse.y,v
retrieving revision 1.268
diff -u -p -r1.268 parse.y
--- parse.y 19 Oct 2013 15:04:25 - 1.268
+++ parse.y 5 Nov 2013 17:45:23 -
@@ -171,6 +171,7 @@ typedef struct {
%}
%token AS ROUTERID HOLDTIME YMIN LISTEN ON FIBUPDATE RTABLE
+%token FIBPRIORITY
%token RDOMAIN RD EXPORTTRGT IMPORTTRGT
%token RDE RIB EVALUATE IGNORE COMPARE
%token GROUP NEIGHBOR NETWORK
@@ -2139,6 +2140,7 @@ lookup(char *s)
{ evaluate, EVALUATE},
{ export-target, EXPORTTRGT},
{ ext-community, EXTCOMMUNITY},
+ { fib-priority, FIBPRIORITY},
{ fib-update, FIBUPDATE},
{ from, FROM},
{ group, GROUP},
Re: Re : Re: Improve routing functions
On 13-11-03 02:27 PM, Loïc BLOT wrote: then to explain my draft here is my own configuration, and why it could be useful to set custom priorities: [...] Without the possibility to change the priorities (and dynamically is better than recompile the kernel and change constant values, it would be a great function to everybody want), it's impossible to solve this routing loop (i have patched ospfd to refuse adding some specific routes from specific hosts but it's not a proper solution, whereas it worked...). FWIW, I agree with Loïc on this; a router administrator should be able to have fine-grained control over route preference. I've run into this in the past, where in a strange topology I wound up with a router (not OpenBSD) learning the same route via EIGRP, OSPF and BGP - each with a different next-hop. Only one of those used the preferred (low-latency, high-bandwidth) path, I don't recall which, but we did have to manually adjust the local preference of one of the protocols in order to make it win. Policy routing would not (could not) have solved the problem, since it was all dynamic routes. I'm about to re-build something similar, actually, using BGP and OSPF (or possibly BGP and static routes), where I will need the ability to control which routing protocol takes precedence. I'll have a route learned via BGP that I want used first, and a route learned by OSPF that I want used only if the BGP route vanishes. (It's a partial overlay network, with backup link over VPN to maintain control functions in the case of an outage on the main link which talks BGP to its peer.) However... in reading route(8), I see the -priority flag exists. Delving a bit deeper into .../net/route.h, I see that the routing table *already has* exactly the support I need (and that I think Loïc needs) in rt_priority and the associated macros. The change I think we're both asking for is that in .../usr/sbin/bgpd/kroute.c, on line 505 (5.4-RELEASE), where we see kr-r.priority = RTP_BGP;, we need a way to override that value in (presumably) bgpd.conf. (Ditto for the IPv6 function.) Similarly, in .../usr/sbin/ospfd/kroute.c:257, where we have kn-r.priority = RTP_OSPF;, and presumably the same sort of thing in routed(8), ripd(8), ospf6d(8), possibly even ldpd(8)... I believe all the support we need is already in the kernel, what we lack is a user-exposed knob to fiddle with those (for now) constant values. I believe they should be default values, not constant values. I believe it is possible to work around this problem currently with route change, but doing so is a very, very ugly idea (worse in Loïc's case than mine, I think). You'd have to have a script/daemon of your own watching the output from route monitor and executing route change every time a route gets inserted with the wrong priority. This leads to much duplication of routing logic, since the correct route is not always known a priori. -- -Adam Thompson athom...@athompso.net
unable to down vlan(4) interfaces in 5.4-RELEASE
In 5.4-RELEASE, I just noticed that even when an interface is down (i.e. ifconfig vlan7 down), the link-local route remains active. According to ifconfig(8), in the section talking about the down subcommand: This action automatically disables routes using the interface. ...yet that isn't happening for me. Here's (hopefully) all the information anyone's going to ask for right now ===hostname.vlan7=== description MBIX_BGP vlan 7 vlandev trunk0 inet 206.72.208.16/24 inet6 2001:504:26::6:2752:1/64 down ===netstat -rn -f inet=== Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default198.51.75.2UGS4 1745 - 8 vlan5 10.0.1/24 link#16UC 00 - 4 vlan6 127/8 127.0.0.1 UGRS 00 33144 8 lo0 127.0.0.1 127.0.0.1 UH 00 33144 4 lo0 184.70.48.184/29 link#12C 00 - 4 vlan2 192.168.160/24 link#15UC 10 - 4 vlan4 192.168.160.88 00:24:a5:af:25:18 UHLc 0 14 - 4 vlan4 198.51.75/24 link#9 UC 10 - 4 vlan5 198.51.75.2f2:f2:be:d0:0e:67 UHLc 10 - 4 vlan5 204.16.160.160/29 link#14UC 00 - 4 vlan207 206.72.208/24 link#17C 00 - 4 vlan7 224/4 127.0.0.1 URS00 33144 8 lo0 **Note 206.72.208/24 route via vlan7 is still present. ** ===ping 206.72.208.12 [which is up and alive at the moment]=== PING 206.72.208.12 (206.72.208.12): 56 data bytes ping: sendto: Network is down ping: wrote 206.72.208.12 64 chars, ret=-1 ===ping 8.8.8.8 [just to prove my default gateway works]=== PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=48 time=49.026 ms ===ifconfig vlan7=== vlan7: flags=8842BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:26:6c:f1:58:b4 description: MBIX_BGP priority: 0 vlan: 7 parent interface: trunk0 groups: vlan status: active inet6 fe80::226:6cff:fef1:58b4%vlan7 prefixlen 64 scopeid 0x11 inet 206.72.208.16 netmask 0xff00 broadcast 206.72.208.255 inet6 2001:504:26::6:2752:1 prefixlen 64 **Note distinct lack of UP flag. I'm not sure why status=active, nor precisely what that means.** Weirder... if I re-display the v4 routes, I now see 206.72.208/24 link#17C 30 - 4 vlan7 206.72.208.1 link#17HLc01 - 4 vlan7 206.72.208.11 link#17HLc03 - 4 vlan7 206.72.208.12 link#17HLc01 - 4 vlan7 That's definitely not supposed to happen on a down'ed interface. Ah, crap. And arp(8) is showing me incompletes. So, basically, you can't ever down a vlan(4) interface??? (Yeah, I just tried ifconfig vlan7 down and re-tested. Same results. Ack.) I want the link down because my layer 1 connection to that network doesn't exist right now but I don't want to completely remove the interface configuration. I must be missing something here... (I don't have any other multihomed hosts to test this on at the moment. 5.4-RELEASE installed from CD.) Help!? -- -Adam Thompson athom...@athompso.net
