Malformed request shuts down httpd
Hello! I know a lot is happening to httpd lately, so maybe this is not
an issue anymore. I've noticed that a malformed HTTP request such as
$ printf 'GET /file\r\n\r\n'| nc myhost 80
doesn't just silently fail, but rather shuts down httpd. My
/etc/httpd.conf is minimal:
server default {listen on egress port 80}
Has anybody else tried this?
Thanks and cheers,
Ezequiel
Re: Packet Filter router i368 vs 64bit
On 11/28/14 01:32, Blaise Hizded wrote: On 11/28/2014 06:01 AM, Brad Smith wrote: On 11/27/14 23:50, jungle Boogie wrote: Hi, On 27 November 2014 at 20:38, thev...@openmailbox.org wrote: you can just use old hardware for these purposes. from the man who literally wrote the book on pf (from pf tutorial via http://home.nuug.no/~peter/pf/en/long-firewall.html): I have not seen comparable tests performed recently [3.1 era], but in my own experience and that of others, the PF filtering overhead is pretty much negligible. As one data point, the machine which gateways between one of the networks where I've done a bit of work and the world is a Pentium III 450MHz with 384MB of RAM. When I've remembered to check, I've never seen the machine at less than 96 percent 'idle' according to top. Yes, that's true! But less fun. ;) I do have some Dell dimensions machine with OpenBSD -current running now that I could easily get two NICs but its kinda old and slow to update current. I'll measure the power to see how much it uses. With the fact that old hardware, why would the APU be OK and not good? I don't see anyone claiming it would not be good. It's more like if you happen to have some old hw around that it would probably be good enough for what you're describing but the APU system would also do the job just fine. I run the previous generation ALIX 2D13 with OpenBSD 5.6 on it for a home firewall with 10MB WAN broadband and 100MB between computers. All is fine: low temperature, low consumption, same speed as with a basic 100MBB switch. So I guess the APU1C is fast enought for a home network. The APU1C works fine for a home network. The only 2 things I dislike are the CPU temperature and the link LED's are off when the Ethernet ports are linked at 1 gig. I've complained about the link LED issue on the PC Engines support forum, but I guess there's no desire to fix it. Oh well. # sysctl hw hw.machine=amd64 hw.model=AMD G-T40E Processor hw.ncpu=2 hw.byteorder=1234 hw.pagesize=4096 hw.disknames=sd0:ec53da01dd2f4a0e,sd1: hw.diskcount=2 hw.sensors.km0.temp0=51.50 degC hw.cpuspeed=1000 hw.setperf=100 hw.vendor=PC Engines hw.product=APU hw.version=1.0 hw.serialno=843042 hw.physmem=2098520064 hw.usermem=2098503680 hw.ncpufound=2 hw.allowpowerdown=1 hw.perfpolicy=manual Stan
Re: Malformed request shuts down httpd
On 28 November 2014 at 13:26, Ezequiel Garzon m...@ezequiel-garzon.net wrote:
Hello! I know a lot is happening to httpd lately, so maybe this is not
an issue anymore. I've noticed that a malformed HTTP request such as
$ printf 'GET /file\r\n\r\n'| nc myhost 80
doesn't just silently fail, but rather shuts down httpd. My
/etc/httpd.conf is minimal:
server default {listen on egress port 80}
Has anybody else tried this?
Thanks and cheers,
Ezequiel
Hello Ezequiel,
is that on release, stable or in current and on which hardware architecture?
--
Thanks,
Ville
Re: Malformed request shuts down httpd
Ezequiel Garzon wrote :
Hello! I know a lot is happening to httpd lately, so maybe this is not
an issue anymore. I've noticed that a malformed HTTP request such as
$ printf 'GET /file\r\n\r\n'| nc myhost 80
doesn't just silently fail, but rather shuts down httpd. My
/etc/httpd.conf is minimal:
server default {listen on egress port 80}
Has anybody else tried this?
Thanks and cheers,
Ezequiel
No crash in current, I get a HTTP/1.0 500 Internal Server Error response from
the server. However in the server logs I get different error messages as I
repeat the request:
Undefined error: 0 (500 Internal Server Error)
then:
Resource temporarily unavailable (500 Internal Server Error)
then:
No such file or directory (500 Internal Server Error)
That doesn't sound right.
-b
Re: sensorsd, upd, and state changes
On Fri, Nov 28, 2014 at 2:45 AM, Marcus MERIGHI mcmer-open...@tor.at wrote: What I have now: $ getcap -a -f /etc/sensorsd.conf hw.sensors.upd0.indicator0:low=1:high=2:command=/etc/sensorsd/upd.sh \ %l %n %s %x %t %2 %3 %4 hw.sensors.upd0.indicator1:low=1:high=2:command=/etc/sensorsd/upd.sh \ %l %n %s %x %t %2 %3 %4 hw.sensors.upd0.indicator2:low=1:high=2:command=/etc/sensorsd/upd.sh \ %l %n %s %x %t %2 %3 %4 hw.sensors.upd0.indicator3:low=1:high=2:command=/etc/sensorsd/upd.sh \ %l %n %s %x %t %2 %3 %4 hw.sensors.upd0.indicator4:low=1:high=2:command=/etc/sensorsd/upd.sh \ %l %n %s %x %t %2 %3 %4 hw.sensors.upd0.percent0:low=10:high=100:command=\ /etc/sensorsd/upd-capacityremaining.sh %l %n %s %x %t %2 %3 %4 hw.sensors.upd0.percent1:low=95:high=100:command=/etc/sensorsd/upd.sh \ %l %n %s %x %t %2 %3 %4 Do you mind saying what type of USB you have, and what these sensors map are for your hardware? I have: uhidev0 at uhub1 port 2 configuration 1 interface 0 American Power Conversion Back-UPS ES 750 FW:841.I3 .D USB FW:I3 rev 1.10/1.01 addr 2 uhidev0: iclass 3/0, 146 report ids upd0 at uhidev0 Which only appears to provide: hw.sensors.upd0.indicator3=Off (ShutdownImminent), OK Thanks. --david
Re: sensorsd, upd, and state changes
I have two different APC units... uhidev0 at uhub1 port 1 configuration 1 interface 0 American Power Conversion Smart-UPS 1500 FW:601.3.D USB FW:1.3 rev 1.10/0.06 addr 2 uhidev0: iclass 3/0, 54 report ids upd0 at uhidev0 $ sysctl | grep upd hw.sensors.upd0.indicator0=Off (Charging), OK hw.sensors.upd0.indicator1=Off (Discharging), OK hw.sensors.upd0.indicator2=On (ACPresent), OK hw.sensors.upd0.indicator3=On (BatteryPresent), OK hw.sensors.upd0.indicator4=Off (ShutdownImminent), OK hw.sensors.upd0.percent0=100.00% (FullChargeCapacity), OK hw.sensors.upd0.percent1=100.00% (RemainingCapacity), OK uhidev0 at uhub7 port 2 configuration 1 interface 0 APC Back-UPS ES 550G FW:904.W1 .D USB FW:W1 rev 1.10/1.06 addr 2 uhidev0: iclass 3/0, 123 report ids upd0 at uhidev0 $ sysctl | grep upd hw.sensors.upd0.indicator0=Off (Charging), OK hw.sensors.upd0.indicator1=Off (Discharging), OK hw.sensors.upd0.indicator2=On (ACPresent), OK hw.sensors.upd0.indicator3=On (BatteryPresent), OK hw.sensors.upd0.indicator4=Off (ShutdownImminent), OK hw.sensors.upd0.percent0=100.00% (RemainingCapacity), OK hw.sensors.upd0.percent1=100.00% (FullChargeCapacity), OK -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of David Higgs Sent: Friday, November 28, 2014 9:43 AM To: misc@openbsd.org Subject: Re: sensorsd, upd, and state changes Do you mind saying what type of USB you have, and what these sensors map are for your hardware? I have: uhidev0 at uhub1 port 2 configuration 1 interface 0 American Power Conversion Back-UPS ES 750 FW:841.I3 .D USB FW:I3 rev 1.10/1.01 addr 2 uhidev0: iclass 3/0, 146 report ids upd0 at uhidev0 Which only appears to provide: hw.sensors.upd0.indicator3=Off (ShutdownImminent), OK
Small fix at openbsd.org/policy.html
Hello, first time contributing to this wonderful project (if you may consider this silly thing as contributing). On openbsd.org/policy.html, it reads as it follows: For historical reasons, the OpenBSD base system still includes the following GPL-licensed components: the GNU compiler collection (GCC) with supporting binutils and libraries, GNU CVS, GNU texinfo, the lynx text browser, the mkhybrid file system creation tool, and the readline library. And according to http://www.openbsd.org/faq/upgrade56.html#ToPorts , 'lynx' has been recently removed from base. I hope I'm doing this in the right way. Thank you for your time.
Re: smtpd: mail stuck in queue
On Fri, Nov 28, 2014 at 01:31:53AM +0100, Alexander Hall wrote: Hi, I noticed a box of mine having had a misconfigured mail relay, resulting in lots of mail queuing up. Now, after fixing the configuration, new mail are properly sent. However, it seems the invalid 'mta-relay' setting, as seen in the envelopes of the queued mail does not get revised while issuing 'smtpctl schedule ...'. Thus, the old mail stays in the queue. Any pointers on how to proceed is appreciated, possibly including cluesticks as of why the observed behaviour might be the proper one. The observed behaviour may not be the proper one, but at some point we had to take a decision as to how smart the daemon should try to be: You send a mail, OpenSMTPD accepts it and tells you it will take care of it. Now, you change the ruleset, how far should OpenSMTPD go to determine itself what needs to be changed ? Are aliases it expanded still valid, should they be reprocessed or removed ? If reprocessed, we may end up sending mail to people who originally were not meant to receive it, if removed we may end up deleting mail that some people were meant to receive. How do we decide what is the right behaviour ? If a mail that was accepted would be discarded now, do you still send it, or do you trash it despite the fact you acknowledge you would send it before ? There are many other cases, such as local deliveries turning into relaying, or the opposite, which lead to funky situations where there's no way we can figure out how to automagically fix the envelopes. So from there, we have two paths: 1- we consider that an envelope is processed according to the rule it has matched when it was accepted; 2- we reevaluate the rules every time we process an envelope and we try to guess what most people expect in every possible combination of a config change ... I can tell you right away that last time we discussed this, we couldn't even get 3 people to agree on the action to take in one of the simplest case ... I prefer 1- because: a- changing your config in incompatible ways that cause an envelope to no longer be routable is not something you do on a regular basis, and the clusterfuck kludge required to add smartness to cope with these few times will be a pain for everyone for very small arguable gain. b- if you change your config and it leads to a situation where smtpd is no longer able to route an envelope, then it's probably up to the admin and not the software to decide if/how the envelope should be dealt with. some admins will want mails to be routed, others will not, there's no way for the software to automatically decide what the correct answer is. c- no matter what changes you make, the behaviour is predictible: an envelope is processed the way it was told to process it when the daemon accepted it. things may change and may no longer be what you want, but there's no guessing how things will be handled. Now do we want to prevent you from reevaluating mails that are already in queue ? Nope, but IMO the proper fix is not to turn the daemon into a smart guesser but rather to enhance smtpctl so that when an admin makes a config change, (s)he can decide to reevalute or not some envelopes or not. -- Gilles Chehade https://www.poolp.org @poolpOrg
Re: smtpd: mail stuck in queue
On Thu, Nov 27, 2014 at 10:00:19PM -0500, Hugo Villeneuve wrote: On Fri, Nov 28, 2014 at 01:31:53AM +0100, Alexander Hall wrote: Hi, I noticed a box of mine having had a misconfigured mail relay, resulting in lots of mail queuing up. Now, after fixing the configuration, new mail are properly sent. However, it seems the invalid 'mta-relay' setting, as seen in the envelopes of the queued mail does not get revised while issuing 'smtpctl schedule ...'. Thus, the old mail stays in the queue. I saw that too while configuring my first smtpd attempt (5.6-stable/sparc). It made me realize that smtpd is still a young MTA. Any pointers on how to proceed is appreciated, possibly including cluesticks as of why the observed behaviour might be the proper one. No, it is not proper behavior. As a store and forward system with potentially 4-5 days between submission and delivery, any MTA needs to be able to adapt in configuration changes across a long period. So, because a MTA configuration may change across a long period of time and that during these changes sometimes someone will decide that a mail that used to be ok to relay no longer is or should no longer be relayed the same way, you're advocating that we should add logic to the MTA for taking guesses at what it should do and adapt to all possible changes ? If a configuration change means that no envelopes is routable anymore, should the software decide to adapt and trash the entire queue without an admin intervention ? are you comfortable with that ? If the admin is already changing the config, doesn't it make more sense that ... (s)he decides what to do with envelopes that are affected by these changes ? I haven't tested the HEAD release yet and didn't found anything in smptd and smtpctl manual page how to fix it in stable. My guess is that you will have to resubmit them. Parse smtpctl show queue output, pick field 1,5,6 and then refeed the output of smtpctl show message field1 to sendmail -f field5 -- field6 for each line. Then delete the stuck ones. (Yeah test that first.) Good luck. Hopefully it will get fixed. As I wrote in the other mail, I think the proper fix is to provide admin the right tool. -- Gilles Chehade https://www.poolp.org @poolpOrg
Re: Small fix at openbsd.org/policy.html
On 11/28/14 10:32, Mariano Baragiola wrote: Hello, first time contributing to this wonderful project (if you may consider this silly thing as contributing). On openbsd.org/policy.html, it reads as it follows: For historical reasons, the OpenBSD base system still includes the following GPL-licensed components: the GNU compiler collection (GCC) with supporting binutils and libraries, GNU CVS, GNU texinfo, the lynx text browser, the mkhybrid file system creation tool, and the readline library. And according to http://www.openbsd.org/faq/upgrade56.html#ToPorts , 'lynx' has been recently removed from base. I hope I'm doing this in the right way. works. :) Works great, actually. The fancy way is to check out a copy of the www/ repository (see faq5.html for details), make the changes, then do a cvs diff -u of your changed file against the original, and send us the diff, either to misc@ (as you did) or to faq@ (if related to the FAQ). However, what you did was fine -- you provided context so we could find the problem you are referring to, you indicated why you felt it was wrong and backed it up with documentation. Nick.
Re: sensorsd, upd, and state changes
On Fri, November 28, 2014 2:45 am, Marcus MERIGHI wrote:
j...@entropicblur.com (Joe Gidi), 2014.11.27 (Thu) 16:41 (CET):
I just spent some more time poking at this and I'm still unable to get
So did I...
sensorsd to recognize upd state changes. This is a bit of a frustrating
regression from my point of view, since I can no longer use apcupsd
unless
I disable uhidev in the kernel.
Does anyone have a working example configuration for sensorsd/upd?
What I have now:
$ getcap -a -f /etc/sensorsd.conf
hw.sensors.upd0.indicator0:low=1:high=2:command=/etc/sensorsd/upd.sh \
%l %n %s %x %t %2 %3 %4
hw.sensors.upd0.indicator1:low=1:high=2:command=/etc/sensorsd/upd.sh \
%l %n %s %x %t %2 %3 %4
hw.sensors.upd0.indicator2:low=1:high=2:command=/etc/sensorsd/upd.sh \
%l %n %s %x %t %2 %3 %4
hw.sensors.upd0.indicator3:low=1:high=2:command=/etc/sensorsd/upd.sh \
%l %n %s %x %t %2 %3 %4
hw.sensors.upd0.indicator4:low=1:high=2:command=/etc/sensorsd/upd.sh \
%l %n %s %x %t %2 %3 %4
hw.sensors.upd0.percent0:low=10:high=100:command=\
/etc/sensorsd/upd-capacityremaining.sh %l %n %s %x %t %2 %3 %4
hw.sensors.upd0.percent1:low=95:high=100:command=/etc/sensorsd/upd.sh \
%l %n %s %x %t %2 %3 %4
The ``command=/etc/sensorsd/upd.sh'' lines are just informational.
The workhorse is command=/etc/sensorsd/upd-capacityremaining.sh:
#!/bin/sh -e
if [[ X${1} == Xbelow ]]; then
logger -t UPD-capacityremaining SHUTDOWN (${@})
shutdown -hp +1
else
logger -t UPD-capacityremaining NON-SHUTDOWN (${@})
fi
I did some testing (plug/unplug, wait for hw.sensors.upd0.percent0 to go
below low=) and left it as working.
Bye, Marcus
Hi Marcus,
Thanks for this! The percent0 example will be useful. Were you able to get
any useful results with the other indicator sensors? The 'low=1:high=2'
attributes don't seem to do anything for me.
Thanks again,
--
Joe Gidi
j...@entropicblur.com
You cannot buy skill. -- Ross Seyfried
Re: Confused about authpf real world usage
On 2014-11-28, thev...@openmailbox.org thev...@openmailbox.org wrote: If say machine 192.168.0.2 and 192.168.0.3 needs unrestricted access to the net, then wont it be as easy as Joe changing his machines IP address to 192.168.0.2 to gain access without authentication? theoretically this is possible, but only if the original machine holding the ip was down. just as a nameserver converts to an ip, the ip is converted to a MAC-address, which is associated with the NIC. if you want you can permantly associate an ip with a mac, that way another machine cannot use that ip address, even if the rightful holder is down. see arp(8). But that other machine can also take on the same MAC address. Neither IP nor MAC address reliably authenticate a machine. If you need authenticated traffic, the tool is IPsec. Use isakmpd or iked to set up an authenticated security association and configure pf to only pass (1) IKE negotiation and (2) decapsulated traffic from the enc interface. Or tag on enc and filter on the tag. -- Christian naddy Weisgerber na...@mips.inka.de
Re: sensorsd, upd, and state changes
On Fri, November 28, 2014 9:43 am, David Higgs wrote: On Fri, Nov 28, 2014 at 2:45 AM, Marcus MERIGHI mcmer-open...@tor.at wrote: What I have now: $ getcap -a -f /etc/sensorsd.conf hw.sensors.upd0.indicator0:low=1:high=2:command=/etc/sensorsd/upd.sh \ %l %n %s %x %t %2 %3 %4 hw.sensors.upd0.indicator1:low=1:high=2:command=/etc/sensorsd/upd.sh \ %l %n %s %x %t %2 %3 %4 hw.sensors.upd0.indicator2:low=1:high=2:command=/etc/sensorsd/upd.sh \ %l %n %s %x %t %2 %3 %4 hw.sensors.upd0.indicator3:low=1:high=2:command=/etc/sensorsd/upd.sh \ %l %n %s %x %t %2 %3 %4 hw.sensors.upd0.indicator4:low=1:high=2:command=/etc/sensorsd/upd.sh \ %l %n %s %x %t %2 %3 %4 hw.sensors.upd0.percent0:low=10:high=100:command=\ /etc/sensorsd/upd-capacityremaining.sh %l %n %s %x %t %2 %3 %4 hw.sensors.upd0.percent1:low=95:high=100:command=/etc/sensorsd/upd.sh \ %l %n %s %x %t %2 %3 %4 Do you mind saying what type of USB you have, and what these sensors map are for your hardware? I have: uhidev0 at uhub1 port 2 configuration 1 interface 0 American Power Conversion Back-UPS ES 750 FW:841.I3 .D USB FW:I3 rev 1.10/1.01 addr 2 uhidev0: iclass 3/0, 146 report ids upd0 at uhidev0 Which only appears to provide: hw.sensors.upd0.indicator3=Off (ShutdownImminent), OK Thanks. --david Hi David, I have the same UPS as you on one of my machines, with the same result: only indicator3 shows up. On the server that started this thread, I have: uhidev3 at uhub3 port 5 configuration 1 interface 0 APC Back-UPS ES 450 FW:844.K2 .D USB FW:K2 rev 1.10/1.06 addr 2 uhidev3: iclass 3/0, 123 report ids upd0 at uhidev3 Which does report all the expected sensors. -- Joe Gidi j...@entropicblur.com You cannot buy skill. -- Ross Seyfried
Re: Confused about authpf real world usage
On Fri, Nov 28, 2014 at 03:27:38PM +0100, Martin Hanson wrote: theoretically this is possible, but only if the original machine holding the ip was down. just as a nameserver converts to an ip, the ip is converted to a MAC-address, which is associated with the NIC. if you want you can permantly associate an ip with a mac, that way another machine cannot use that ip address, even if the rightful holder is down. see arp(8). But wouldn't that be very easy to break? First I would scan the network for MACs and matching IPs, then I would spoof one at a time until I am out. How does one secure against MAC/IP spoofing? Is there a way to prevent this. You secure againt it by segmenting your untrusted machines/users from your trusted platforms. Three ways: * Separate Ethernet segments. * Separate VLANs. They work just like separate segments. * Use IPSec for your trusted platforms. If you don't trust Joe not to spoof his IP address or his MAC, keep him and his platform on an untrusted tier. If he authenticates, then you can permit him the authority that particular authentication permits. Regardless what IP address or MAC address he's using.
Re: Packet Filter router i368 vs 64bit
On Fri, Nov 28, 2014 at 12:00 AM, Edgar Pettijohn pettijo...@hotmail.com wrote: This is something I've been interested in trying, but I would want it as a wireless access point as well and not sure what cards are supported and work well. Does anyone know of any good choices? I went with an athn card in my APU: http://www.amazon.com/gp/r.html?R=1VP5WEM85ZPGNC=3JNG5JOTKOGN0H=TKW2F041FODZDC3VUWNULCCNSVUAT=CU=http%3A%2F%2Fwww.amazon.com%2Fdp%2FB005HMZ8B2%2Fref%3Dpe_385040_121528360_TE_dp_3 It's half sized, so it'll need an adapter to full size to mount in the APU. There are other usable options if you check the wifi man pages and make sure Host AP mode is supported. Tim.
Re: smtpd: mail stuck in queue
On 11/28/14 17:04, Gilles Chehade wrote: On Thu, Nov 27, 2014 at 10:00:19PM -0500, Hugo Villeneuve wrote: On Fri, Nov 28, 2014 at 01:31:53AM +0100, Alexander Hall wrote: Hi, I noticed a box of mine having had a misconfigured mail relay, resulting in lots of mail queuing up. Now, after fixing the configuration, new mail are properly sent. However, it seems the invalid 'mta-relay' setting, as seen in the envelopes of the queued mail does not get revised while issuing 'smtpctl schedule ...'. Thus, the old mail stays in the queue. I saw that too while configuring my first smtpd attempt (5.6-stable/sparc). It made me realize that smtpd is still a young MTA. Any pointers on how to proceed is appreciated, possibly including cluesticks as of why the observed behaviour might be the proper one. No, it is not proper behavior. As a store and forward system with potentially 4-5 days between submission and delivery, any MTA needs to be able to adapt in configuration changes across a long period. So, because a MTA configuration may change across a long period of time and that during these changes sometimes someone will decide that a mail that used to be ok to relay no longer is or should no longer be relayed the same way, you're advocating that we should add logic to the MTA for taking guesses at what it should do and adapt to all possible changes ? If a configuration change means that no envelopes is routable anymore, should the software decide to adapt and trash the entire queue without an admin intervention ? are you comfortable with that ? If the admin is already changing the config, doesn't it make more sense that ... (s)he decides what to do with envelopes that are affected by these changes ? I haven't tested the HEAD release yet and didn't found anything in smptd and smtpctl manual page how to fix it in stable. My guess is that you will have to resubmit them. Parse smtpctl show queue output, pick field 1,5,6 and then refeed the output of smtpctl show message field1 to sendmail -f field5 -- field6 for each line. Then delete the stuck ones. (Yeah test that first.) Good luck. Hopefully it will get fixed. As I wrote in the other mail, I think the proper fix is to provide admin the right tool. Indeed, that makes sense. Even just re-injecting the mails might fix it, but then they arrive from localhost rather than from the original source, so they might be routed differently than they would in the first place... I ended up w/ ~ # mailq | cut | xargs perl -pi Email is hard, let's go shopping. :) /Alexander
Re: Confused about authpf real world usage
On 2014-11-28, Martin Hanson greencopperm...@yandex.com wrote: How does one secure against MAC/IP spoofing? Is there a way to prevent this. 1. You separate the traffic so that potential attackers cannot access this network segment. a. Physically: Run a wire. b. Logically: Use a separate VLAN. 2. Authenticate with IPsec. I'll venture a guess and say that (1b) is the most common choice in practice, although it requires you to trust your switch infrastructure. -- Christian naddy Weisgerber na...@mips.inka.de
Re: Confused about authpf real world usage
On Fri, Nov 28, 2014 at 03:27:38PM +0100, Martin Hanson wrote: First I would scan the network for MACs and matching IPs, then I would spoof one at a time until I am out. Don't forget about the differentiation between authpf and authpf-noip. The latter can make things interesting for some use cases with SSH tunnels. Utilizing the user keyword in pf.conf is a nice addition.
Re: CUPS printer problems - #!/bin/bash
On Fri, 28 Nov 2014 17:38:46 +0100 Antoine Jacoutot ajacou...@bsdfrog.org wrote: On Fri, Nov 28, 2014 at 09:23:41AM -0700, Duncan Patton a Campbell wrote: On Fri, 28 Nov 2014 11:15:26 +0100 Antoine Jacoutot ajacou...@bsdfrog.org wrote: On Thu, Nov 27, 2014 at 03:54:10PM -0700, Duncan Patton a Campbell wrote: On Thu, 27 Nov 2014 15:01:44 -0700 Duncan Patton a Campbell campb...@neotext.ca wrote: The kludge that killz (bugz;): # cd /bin # ln -s sh bash And now my printer works! Yes but the Print Self-Test Page does not. Cups claims it does but foomatic says something else (attached). The Shell sez bash but it's pointing to /bin/sh. The problem could some shell diff between ksh and bash, or something entirely else I don't see how bash ended up in the process... Foomatic was patched to use ksh. You sure you don't have an old foomatic configuration around? I just spotted a misused of bash in cups-filters actually, but it's for the textonly filter, so that does not concern that particular issue. bash has _been_ on the system before, so it must be going out and finding some dead config. I've been doing installs not upgrades on the system and then hooking up the user disks after the fact. Looking in the most recent foomatic code I find statements like 2003-12-21 Till Kamppeter till.kamppe...@gmx.net * Makefile.in: Fixed compatibility for non-bash systems: Used VAR=VALUE; export VAR instead of export VAR=VALUE (Thanks to Florian Diesch die...@spamfence.net). 2006-10-03 Till Kamppeter till.kamppe...@gmail.com * foomatic-rip.in: Fixed bashism. but also Unfortunately, this technique does not work for `CONFIG_SHELL' due to an Autoconf bug. Until the bug is fixed you can use this workaround: CONFIG_SHELL=/bin/bash /bin/bash ./configure CONFIG_SHELL=/bin/bash Yeah but that has nothing to do with why your foomatic is trying to invoke /bin/bash. You are mixing apples and oranges here. I only used that to point out that there's bashisms thruout the codebase... but I'd guess that somewhere Fruitco is conflating apples and oranges into the round_fruit set (as distinct from long_fruit like bananas and pine cones). If I build foomatic from net sources I get # ./foomatic-rip -v foomatic rip version 4.0.12.246 man foomatic-rip for help. # # pkg_info| grep foom foomatic-db-4.0.20131218 Foomatic PPD data foomatic-db-engine-4.0.11 Foomatic PPD generator but that's NOT what the package installs: # foomatic-rip -v foomatic-rip of cups-filters version 1.0.54 man foomatic-rip for help. This is the version in the /tmp/foomatic*.log files. I just removed the /bin/bash - sh link and got the same log file: foomatic-rip version 1.0.54 running... ... Error: Executing /bin/bash So cups is installing old filtre code imported from foo-1.0.54 but the foo-packages think they're at 4.0.? Something is funky here, and it goes further than my machine. Dhu -- Antoine -- Ne obliviscaris, vix ea nostra voco.
Ancient source-changes archive
Does anyone happen to have a personal archive of the source-changes mailing list going back at least as far as September 1997? Please contact me off-list. I have a code archaeology question that my Google-fu is too weak to answer. Thanks in advance!
Re: Confused about authpf real world usage
theoretically this is possible, but only if the original machine holding the ip was down. just as a nameserver converts to an ip, the ip is converted to a MAC-address, which is associated with the NIC. if you want you can permantly associate an ip with a mac, that way another machine cannot use that ip address, even if the rightful holder is down. see arp(8). But wouldn't that be very easy to break? First I would scan the network for MACs and matching IPs, then I would spoof one at a time until I am out. How does one secure against MAC/IP spoofing? Is there a way to prevent this.
Re: CUPS printer problems - #!/bin/bash
I only used that to point out that there's bashisms thruout the codebase... but I'd guess that somewhere Fruitco is conflating apples and oranges into the round_fruit set (as distinct from long_fruit like bananas and pine cones). If I build foomatic from net sources I get What net sources? I am not interested about external non official sources. I am only interested in fixing out packages. The only official net source of foomatic-rip is cups-filters. The one from openprinting is not maintained anymore. $ pkglocate foomatic-rip cups-filters-1.0.61p1:print/cups-filters:/usr/local/bin/foomatic-rip cups-filters-1.0.61p1:print/cups-filters:/usr/local/libexec/cups/filter/foomatic-rip cups-filters-1.0.61p1:print/cups-filters:/usr/local/man/man1/foomatic-rip.1 Sorry but I will not help with locally compiled external softwares, only with official ports/packages. -- Antoine
Re: Ancient source-changes archive
Hi Kent, Kent R. Spillner wrote on Fri, Nov 28, 2014 at 10:57:21AM -0600: Does anyone happen to have a personal archive of the source-changes mailing list going back at least as far as September 1997? Please contact me off-list. I have a code archaeology question that my Google-fu is too weak to answer. Wrong approach, OpenBSD documentation is not supposed to require Google-fu. Use ftp://ftp.openbsd.org/pub/OpenBSD/Changelogs/ or any mirror. For developers, the same is available in /cvs/CVSROOT/ChangeLog*. Yours, Ingo
Re: Ancient source-changes archive
Use ftp://ftp.openbsd.org/pub/OpenBSD/Changelogs/ or any mirror. For developers, the same is available in /cvs/CVSROOT/ChangeLog*. Ah, but these files lack about one month of changes in 1996.
Re: Malformed request shuts down httpd
On 2014-11-28, Ezequiel Garzon m...@ezequiel-garzon.net wrote:
Hello! I know a lot is happening to httpd lately, so maybe this is not
an issue anymore. I've noticed that a malformed HTTP request such as
$ printf 'GET /file\r\n\r\n'| nc myhost 80
doesn't just silently fail, but rather shuts down httpd. My
/etc/httpd.conf is minimal:
server default {listen on egress port 80}
Has anybody else tried this?
Thanks and cheers,
Ezequiel
httpd in 5.6 was very early code, I think this problem should be fixed in
http://ftp.openbsd.org/pub/OpenBSD/patches/5.6/common/009_httpd.patch.sig
BTW, this is not malformed, it's a valid HTTP 0.9 request.
Re: Ancient source-changes archive
On 2014-11-28, Ingo Schwarze schwa...@usta.de wrote: For developers, the same is available in /cvs/CVSROOT/ChangeLog*. For anybody mirroring the repository. -- Christian naddy Weisgerber na...@mips.inka.de
Staying -current with cvsup or cvsync
Hello All, For the last several updates I've applied to my system, I've used plain CVS: cvs -q up -Pd This is pretty slow for some reason, but I understand that's just how CVS works. Michael W. Lucas' book Absolute OpenBSD (first edition) talks about using CVSup to update the local copy against the remote repo. (Page 344) I also found this page: http://www.openbsd.gr/cvsup.html (notice that this is NOT .org.) the .org site doesn't have the same page: http://www.openbsd.org/cvsup.html But the problem is I can't find cvsup in /usr/ports/net nor anywhere else: # make search key=cvsup # Does this mean cvssup is no longer used? Then I came across cvsync: http://www.openbsd.org/cvsync.html Is cvsync preferred now? If so, could you advise what to use for collections if you want to have the same effect of: cd /usr/src cvs -q up -Pd The example file displays: name openbsd release rcs But I don't know if that will yield the desired outcome. Thanks for any assistance. Best, j.b. -- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si
Re: Confused about authpf real world usage
On 2014-11-28, Christian Weisgerber na...@mips.inka.de wrote: On 2014-11-28, Martin Hanson greencopperm...@yandex.com wrote: How does one secure against MAC/IP spoofing? Is there a way to prevent this. 1. You separate the traffic so that potential attackers cannot access this network segment. a. Physically: Run a wire. b. Logically: Use a separate VLAN. 2. Authenticate with IPsec. I'll venture a guess and say that (1b) is the most common choice in practice, although it requires you to trust your switch infrastructure. There may be other options depending on the switches used, there are various types of port security available - hard-coded MAC/port assignments, DHCP snooping, 802.1x, etc.
Re: Malformed request shuts down httpd
I upgraded to 5.6-STABLE (amd64) on November 26th and when I ran this against
my httpd instance it returned:
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
html
head
title500 Internal Server Error/title
style type=text/css!--
body { background-color: white; color: black; font-family: 'Comic Sans MS',
'Chalkboard SE', 'Comic Neue', sans-serif; }
--/style
/head
body
h1Internal Server Error/h1
div id='m'/div
hraddressOpenBSD httpd at {ADDRESSREMOVED} port 80/address
/body
/html
httpd process still running happily, and valid pages are still being served.
- Eric
On Nov 28, 2014, at 3:26 AM, Ezequiel Garzon m...@ezequiel-garzon.net wrote:
Hello! I know a lot is happening to httpd lately, so maybe this is not
an issue anymore. I've noticed that a malformed HTTP request such as
$ printf 'GET /file\r\n\r\n'| nc myhost 80
doesn't just silently fail, but rather shuts down httpd. My
/etc/httpd.conf is minimal:
server default {listen on egress port 80}
Has anybody else tried this?
Thanks and cheers,
Ezequiel
Re: Staying -current with cvsup or cvsync
Am 28.11.2014 21:33, schrieb Jungle Boogie:
Hello All,
For the last several updates I've applied to my system, I've used plain
CVS: cvs -q up -Pd
This is pretty slow for some reason, but I understand that's just how
CVS works.
Michael W. Lucas' book Absolute OpenBSD (first edition) talks about
using CVSup to update the local copy against the remote repo. (Page 344)
I also found this page: http://www.openbsd.gr/cvsup.html (notice that
this is NOT .org.)
On the footer of this site you will find
-- Quote --
This site Copyright © 1996-2009 OpenBSD.
$OpenBSD: index.html,v 1.605 2009/12/01 18:13:58 ajacoutot Exp $
-- end Quote --
so it's out of date and thus probably not authoritative.
the .org site doesn't have the same page:
http://www.openbsd.org/cvsup.html
But the problem is I can't find cvsup in /usr/ports/net
nor anywhere else:
# make search key=cvsup
#
Does this mean cvssup is no longer used?
Yes.
Then I came across cvsync: http://www.openbsd.org/cvsync.html
Is cvsync preferred now?
If so, could you advise what to use for collections if you want to have
the same effect of:
cd /usr/src
cvs -q up -Pd
The example file displays: name openbsd release rcs
But I don't know if that will yield the desired outcome.
Thanks for any assistance.
Best,
j.b.
The example file /usr/local/share/examples/cvsync/cvsync.conf
installed by the cvsync package also has
# # alternatively, fetch only selected parts
# collection {
# name openbsd-cvsroot release rcs
# }
# collection {
# name openbsd-ports release rcs
# }
# collection {
# name openbsd-src release rcs
# }
# collection {
# name openbsd-www release rcs
# }
# collection {
# name openbsd-xenocara release rcs
# }
#
# # the X11 and XF4 trees are of historical interest only
# collection {
# name openbsd-x11 release rcs
# }
# collection {
# name openbsd-xf4 release rcs
# }
so the third collection in this list
name openbsd-src release rcs
should be sufficient for you.
HTH
rru
Re: Staying -current with cvsup or cvsync
Dear Einfach,
From: Einfach Jemand rru@gmail.com
Sent: Fri, 28 Nov 2014 22:30:29 +0100
To: misc@openbsd.org
Subject: Re: Staying -current with cvsup or cvsync
On the footer of this site you will find
-- Quote --
This site Copyright © 1996-2009 OpenBSD.
$OpenBSD: index.html,v 1.605 2009/12/01 18:13:58 ajacoutot Exp $
-- end Quote --
so it's out of date and thus probably not authoritative.
Yes, I noticed that, too!
the .org site doesn't have the same page:
http://www.openbsd.org/cvsup.html
But the problem is I can't find cvsup in /usr/ports/net
nor anywhere else:
# make search key=cvsup
#
Does this mean cvssup is no longer used?
Yes.
Thank you for the confirmation, I'll disregard this section from the book and
see what the updated book (edition 2) has to say about updates.
Then I came across cvsync: http://www.openbsd.org/cvsync.html
The example file /usr/local/share/examples/cvsync/cvsync.conf
installed by the cvsync package also has
# # alternatively, fetch only selected parts
# collection {
# name openbsd-cvsroot release rcs
# }
# collection {
# name openbsd-ports release rcs
# }
# collection {
# name openbsd-src release rcs
# }
# collection {
# name openbsd-www release rcs
# }
# collection {
# name openbsd-xenocara release rcs
# }
#
# # the X11 and XF4 trees are of historical interest only
# collection {
# name openbsd-x11 release rcs
# }
# collection {
# name openbsd-xf4 release rcs
# }
so the third collection in this list
name openbsd-src release rcs
should be sufficient for you.
Ah, the example was very close to what I was trying. I tried many variations
to have src in the collection but it wouldn't work.
I'll give this a shot and see how much faster the update is with cvsync!
HTH
rru
Best,
j.b.
--
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
Re: Malformed request shuts down httpd
Thanks for all the replies. Ville, I'm using -release, on the i386 architecture... inside a VPS. I can gather from the replies that indeed httpd is changing quite fast right now, so it doesn't seem very useful to report on -release. (In fact, apologies for my question a few days ago on the Last-Modified header: I can see in the -current changelog that it has already been implemented.) Maybe I'll roll up my sleeves and learn how to have a -current system. Thanks, Stuart, too. I didn't now my malformed example was not malformed after all! Cheers, Ezequiel
Re: Staying -current with cvsup or cvsync
Am 28.11.2014 22:38, schrieb Jungle Boogie: [...] I'll give this a shot and see how much faster the update is with cvsync! You are aware that this might not be much faster since - first you synchronize your local repository with cvsync, which takes some time - then you synchronize your working copy /usr/src with your local repository doing cvs up, which takes time as well. See also http://marc.info/?l=openbsd-miscm=138652306002368w=2 Cheers, rru
Re: Ancient source-changes archive
Thanks guys, but this is for the same problem I was complaining about on icb ~1 month ago. There's a tiny discrepancy between the ChangeLogs and CVS history, and I'm hoping some long-time user that is also a pack rat might have a private archive that would help figure out which is correct. On Nov 28, 2014, at 14:29, Christian Weisgerber na...@mips.inka.de wrote: On 2014-11-28, Ingo Schwarze schwa...@usta.de wrote: For developers, the same is available in /cvs/CVSROOT/ChangeLog*. For anybody mirroring the repository. -- Christian naddy Weisgerber na...@mips.inka.de
Re: making firefox less insecure
On Thu, Nov 27, 2014 at 01:07, Jonathan Thornburg wrote: Summary --- As described in another thread (http://marc.info/?l=openbsd-miscm=141677224322425w=1), I'm trying to run firefox as a non-privileged user _firefox, talking to my X server (no Xephyr yet) via an ssh tunnel. But I've discovered a serious flaw in this scheme: cut-n-paste is completely broken. In fact, it looks like cut-n-paste from any X client with a diferent uid/gid than the X server is broken. :( My basic question is, is there any way to fix this? That is by design. Secure X sessions do not permit access. If you want to grant full access to the X session, use ssh -Y for an insecure connection. The fact that basically every X client application crashes in this case is somewhat less by design, but as a practicaly matter, nothing handles these errors appropriately.
Re: CUPS printer problems - #!/bin/bash
On Fri, 28 Nov 2014 19:34:35 +0100 Antoine Jacoutot ajacou...@bsdfrog.org wrote: I only used that to point out that there's bashisms thruout the codebase... but I'd guess that somewhere Fruitco is conflating apples and oranges into the round_fruit set (as distinct from long_fruit like bananas and pine cones). If I build foomatic from net sources I get What net sources? I am not interested about external non official sources. I am only interested in fixing out packages. The only official net source of foomatic-rip is cups-filters. The one from openprinting is not maintained anymore. I'm not running that code. As I pointed out the official openbsd foomatic packages are NAME/NUMBERED like like the openprinting version 4.012, but inside they are something else branched from a much older version: version 1.1 is from circa 2002. This is version 1.0.54 # which foomatic-rip /usr/local/bin/foomatic-rip l /usr/local/bin/foomatic-rip lrwxr-xr-x 1 root wheel 43 Nov 26 11:44 /usr/local/bin/foomatic-rip - /usr/local/libexec/cups/filter/foomatic-rip # l /usr/local/libexec/cups/filter/foomatic-rip -r-xr-xr-x 1 root bin 108536 Jul 31 07:06 /usr/local/libexec/cups/filter/foomatic-rip /usr/local/bin/foomatic-rip -v foomatic-rip of cups-filters version 1.0.54 man foomatic-rip for help. The code from openprinting returns foomatic rip version 4.0.12.246 $ pkglocate foomatic-rip that's netbsd. are these packages xcompiled? cups-filters-1.0.61p1:print/cups-filters:/usr/local/bin/foomatic-rip cups-filters-1.0.61p1:print/cups-filters:/usr/local/libexec/cups/filter/foomatic-rip cups-filters-1.0.61p1:print/cups-filters:/usr/local/man/man1/foomatic-rip.1 Sorry but I will not help with locally compiled external softwares, only with official ports/packages. It's the Official port/package that is CALLING BASH. # pkg_info | grep cups cups-1.7.4p2Common Unix Printing System cups-filters-1.0.54p2 OpenPrinting CUPS filters cups-libs-1.7.4 CUPS libraries and headers # pkg_info | grep foom foomatic-db-4.0.20131218 Foomatic PPD data foomatic-db-engine-4.0.11 Foomatic PPD generator Dhu -- Antoine -- Ne obliviscaris, vix ea nostra voco.
Re: CUPS printer problems - #!/bin/bash
I'm not running that code. As I pointed out the official openbsd foomatic packages are NAME/NUMBERED like like the openprinting version 4.012, but inside they are something else branched from a much older version: version 1.1 is from circa 2002. This is version 1.0.54 # which foomatic-rip /usr/local/bin/foomatic-rip l /usr/local/bin/foomatic-rip lrwxr-xr-x 1 root wheel 43 Nov 26 11:44 /usr/local/bin/foomatic-rip - /usr/local/libexec/cups/filter/foomatic-rip # l /usr/local/libexec/cups/filter/foomatic-rip -r-xr-xr-x 1 root bin 108536 Jul 31 07:06 /usr/local/libexec/cups/filter/foomatic-rip /usr/local/bin/foomatic-rip -v foomatic-rip of cups-filters version 1.0.54 man foomatic-rip for help. The code from openprinting returns foomatic rip version 4.0.12.246 How is that relevant to the bash issue; you confuse me... did I miss something? $ pkglocate foomatic-rip that's netbsd. are these packages xcompiled? What do you mean that's netbsd? And what do you mean by xcompiled? cups-filters-1.0.61p1:print/cups-filters:/usr/local/bin/foomatic-rip cups-filters-1.0.61p1:print/cups-filters:/usr/local/libexec/cups/filter/foomatic-rip cups-filters-1.0.61p1:print/cups-filters:/usr/local/man/man1/foomatic-rip.1 Sorry but I will not help with locally compiled external softwares, only with official ports/packages. It's the Official port/package that is CALLING BASH. Nowhere in the installed cups-filters code I can see it calling bash... Just grep for it yourself and you'll see. So there must be something specific on your system. Did you make sure you don't have an old config laying around? -- Antoine
Re: CUPS printer problems - #!/bin/bash
On Sat, 29 Nov 2014 00:34:17 +0100 Antoine Jacoutot ajacou...@bsdfrog.org wrote: I'm not running that code. As I pointed out the official openbsd foomatic packages are NAME/NUMBERED like like the openprinting version 4.012, but inside they are something else branched from a much older version: version 1.1 is from circa 2002. This is version 1.0.54 # which foomatic-rip /usr/local/bin/foomatic-rip l /usr/local/bin/foomatic-rip lrwxr-xr-x 1 root wheel 43 Nov 26 11:44 /usr/local/bin/foomatic-rip - /usr/local/libexec/cups/filter/foomatic-rip # l /usr/local/libexec/cups/filter/foomatic-rip -r-xr-xr-x 1 root bin 108536 Jul 31 07:06 /usr/local/libexec/cups/filter/foomatic-rip /usr/local/bin/foomatic-rip -v foomatic-rip of cups-filters version 1.0.54 man foomatic-rip for help. The code from openprinting returns foomatic rip version 4.0.12.246 How is that relevant to the bash issue; you confuse me... did I miss something? $ pkglocate foomatic-rip that's netbsd. are these packages xcompiled? What do you mean that's netbsd? And what do you mean by xcompiled? pkglocate is a netbsd utility. I didn't know it had been ported. xcompiled == cross-compiled. cups-filters-1.0.61p1:print/cups-filters:/usr/local/bin/foomatic-rip cups-filters-1.0.61p1:print/cups-filters:/usr/local/libexec/cups/filter/foomatic-rip cups-filters-1.0.61p1:print/cups-filters:/usr/local/man/man1/foomatic-rip.1 Sorry but I will not help with locally compiled external softwares, only with official ports/packages. It's the Official port/package that is CALLING BASH. Nowhere in the installed cups-filters code I can see it calling bash... Just grep for it yourself and you'll see. So there must be something specific on your system. Did you make sure you don't have an old config laying around? Not that I can find, but what you're saying here is what I'm seeing: bash _was_ on the system for a short time a while back when it was needed to get grolog to run on OBSD64. Afterward it was removed. But cups-foomatic is going out when it gets installed, and finding some bashism, preferentially configures for it. In newer versions of foom* this becomes an explicitly configurable param. Dhu -- Antoine -- Ne obliviscaris, vix ea nostra voco.
Re: CUPS printer problems - #!/bin/bash
Not that I can find, but what you're saying here is what I'm seeing: bash _was_ on the system for a short time a while back when it was needed to get grolog to run on OBSD64. Afterward it was removed. But cups-foomatic is going out when it gets installed, and finding some bashism, preferentially configures for it. In newer versions of foom* this becomes an explicitly configurable param. If that were to be the case, it would have called /usr/local/bin/bash, not /bin/bash... -- Antoine
Re: smtpd: mail stuck in queue
On 28 November 2014, Gilles Chehade gil...@poolp.org wrote: On Thu, Nov 27, 2014 at 10:00:19PM -0500, Hugo Villeneuve wrote: [...] No, it is not proper behavior. As a store and forward system with potentially 4-5 days between submission and delivery, any MTA needs to be able to adapt in configuration changes across a long period. So, because a MTA configuration may change across a long period of time and that during these changes sometimes someone will decide that a mail that used to be ok to relay no longer is or should no longer be relayed the same way, you're advocating that we should add logic to the MTA for taking guesses at what it should do and adapt to all possible changes ? [...] No: the original HELO, FROM, and RCPT TO should be saved in the queue file, and there should be a command to re-queue the message. Then when a message is re-queued the entire envelope is resolved again from scratch, according to the current config: problem solved. This is essentially what Postfix does, and I have yet to hear anybody arguing it should do something else. :) Regards, Liviu Daia
rdomain != 0 lo0 in table
When an interface is given an IP6 address in anew rdomain, lo0 is named in various routes when that table is queried via netstat -r -f inet Does the pseudo-interface lo0 actually exist in multiple routing tables simultaneously, or does the name 'lo0' signify an otherwise anonymous point to hang the extra routes defined when any address is configured in a rdomain? - river:5626$ sudo ifconfig re2 rdomain 3 river:5627$ netstat -rn -f inet6 -T 3 Routing tables river:5629$ sudo ifconfig re2 inet6 2002:1234:4567::0 prefixlen 64 rdomain 3 river:5630$ netstat -rn -f inet6 -T 3 Routing tables Internet6: DestinationGateway Flags Refs Use Mtu Prio Iface 2002:1234:4567:: 00:30:18:ab:ee:49 HL 00 - 4 lo0 2002:1234:4567::/64link#3 C 00 - 4 re2 fe80::%re2/64 link#3 C 00 - 4 re2 fe80::230:18ff:feab:ee49%re2 00:30:18:ab:ee:49 HL 00 - 4 lo0 ff01::%re2/32 link#3 C 00 - 4 re2 ff02::%re2/32 link#3 C 00 - 4 re2 -- In a more complex case, lo0 exists with a route but was never configured in this rdomain. This is part of my implementation of an ip6 tunnel endpoint. The endpoint IP6 address must not be used as a source address from my net so that address is in a separate routing domain. pf transfers packets between the domains. -- netstat -rn -f inet6 -T 1 Routing tables Internet6: DestinationGateway Flags Refs Use Mtu Prio Iface default2001:4830::xxx::1 UGS0 427 - 8 gif0 ::1link#7 UHL00 - 4 lo0 2001:4830::xxx::1 2001:4830::xxx::2 UH 1 61 - 4 gif0 2001:4830::xxx::2 link#10 UHL00 - 4 lo0 fe80::%lo1/64 fe80::1%lo1 U 00 - 4 lo1 fe80::1%lo1link#7 UHL00 - 4 lo0 fe80::%gif0/64 link#10 UC 00 - 4 gif0 fe80::230:18ff:feab:ee47%gif0 link#10 UHL00 - 4 lo0 ff01::%lo1/32 fe80::1%lo1 UC 00 - 4 lo1 ff01::%gif0/32 link#10 UC 00 - 4 gif0 ff02::%lo1/32 fe80::1%lo1 UC 00 - 4 lo1 ff02::%gif0/32 link#10 UC 00 - 4 gif0 If this is not the intended behavior, I can dig into the code - this would be in the ip6 route add code? If it should be sent there I'll copy this to tech@ thanks Geoff Steckel
Re: Staying -current with cvsup or cvsync
Dear Einfach, From: Einfach Jemand rru@gmail.com Sent: Fri, 28 Nov 2014 22:59:05 +0100 To: misc@openbsd.org Subject: Re: Staying -current with cvsup or cvsync Am 28.11.2014 22:38, schrieb Jungle Boogie: [...] I'll give this a shot and see how much faster the update is with cvsync! You are aware that this might not be much faster since - first you synchronize your local repository with cvsync, which takes some time - then you synchronize your working copy /usr/src with your local repository doing cvs up, which takes time as well. See also http://marc.info/?l=openbsd-miscm=138652306002368w=2 This helped out! I'll stick with the traditional way. Cheers, rru -- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si
Error while building current
Not terribly concerned just wanted to let the powers that be know about this error. Will try and update src and rebuild tomorrow. === usr.sbin/httpdcc -O2 -pipe -Wall -I/usr/src/usr.sbin/httpd -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wshadow -Wpointer-arith -Wsign-compare -c parse.c/usr/src/usr.sbin/httpd/parse.y: In function 'yyparse':/usr/src/usr.sbin/httpd/parse.y:289: error: expected expression before '' token/usr/src/usr.sbin/httpd/parse.y:293: error: expected expression before '==' token/usr/src/usr.sbin/httpd/parse.y:300: error: expected expression before '' token/usr/src/usr.sbin/httpd/parse.y:442: error: expected expression before '' token/usr/src/usr.sbin/httpd/parse.y:461: error: expected expression before '==' token/usr/src/usr.sbin/httpd/parse.y:484: error: expected expression before '' token*** Error 1 in usr.sbin/httpd (sys.mk:87 'parse.o')*** Error 1 in usr.sbin (bsd.subdir.mk:48 'all')*** Error 1 in . (bsd.subdir.mk:48 'all')*** Error 1 in /usr/src (Makefile:82 'build') Here is dmesg if anyone wants it. OpenBSD 5.6-current (GENERIC) #1: Fri Nov 28 19:05:15 CST 2014 r...@sandbox.my.domain:/usr/src/sys/arch/amd64/compile/GENERICreal mem = 3721445376 (3549MB)avail mem = 3618578432 (3450MB)mpath0 at rootscsibus0 at mpath0: 256 targetsmainbus0 at rootbios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe9590 (50 entries)bios0: vendor American Megatrends Inc. version V2.0 date 02/04/2013bios0: MSI MS-7786acpi0 at bios0: rev 2acpi0: sleep states S0 S3 S4 S5acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDTacpi0: wakeup devices SBAZ(S4) PS2K(S3) PS2M(S3) P0PC(S4) UHC1(S4) UHC2(S4) USB3(S4) UHC4(S4) USB5(S4) UHC6(S4) UHC7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) BR12(S4) [...]acpitimer0 at acpi0: 3579545 Hz, 32 bitsacpimadt0 at acpi0 addr 0xfee0: PC-AT compatcpu0 at mainbus0: apid 0 (boot processor)cpu0: AMD A4-3400 APU with Radeon(tm) HD Graphics, 2695.42 MHzcpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3D NOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKIN IT,ITSCcpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cachecpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associativecpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associativecpu0: AMD erratum 721 detected and fixedcpu0: smt 0, core 0, package 0mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed rangescpu0: apic clock running at 199MHzcpu at mainbus0: not configuredioapic0 at mainbus0: apid 3 pa 0xfec0, version 21, 24 pinsacpimcfg0 at acpi0 addr 0xe000, bus 0-255acpihpet0 at acpi0: 14318180 Hzacpiprt0 at acpi0: bus 0 (PCI0)acpiprt1 at acpi0: bus 2 (P0PC)acpiprt2 at acpi0: bus -1 (PE20)acpiprt3 at acpi0: bus -1 (PE21)acpiprt4 at acpi0: bus -1 (PE22)acpiprt5 at acpi0: bus -1 (PE23)acpiprt6 at acpi0: bus -1 (BR12)acpiprt7 at acpi0: bus 1 (BR14)acpiprt8 at acpi0: bus -1 (BR15)acpiprt9 at acpi0: bus -1 (BR17)acpiprt10 at acpi0: bus -1 (BR16)acpicpu0 at acpi0: C2acpibtn0 at acpi0: PWRBpci0 at mainbus0 bus 0pchb0 at pci0 dev 0 function 0 AMD AMD64 12h Host rev 0x00radeondrm0 at pci0 dev 1 function 0 ATI Radeon HD 6410D rev 0x00drm0 at radeondrm0radeondrm0: msiazalia0 at pci0 dev 1 function 1 ATI Radeon HD 6500D HD Audio rev 0x00: msiazalia0: no supported codecsppb0 at pci0 dev 4 function 0 AMD AMD64 12h PCIE rev 0x00: msipci1 at ppb0 bus 1re0 at pci1 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E-VL (0x2c80), msi, address d4:3d:7e:ba:37:33rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 5ahci0 at pci0 dev 17 function 0 AMD Hudson-2 SATA rev 0x40: apic 3 int 19, AHCI 1.3scsibus1 at ahci0: 32 targetssd0 at scsibus1 targ 1 lun 0: ATA, ST500DM002-1BD14, KC48 SCSI3 0/direct fixed naa.5000c50066b38e26sd0: 476940MB, 512 bytes/sector, 976773168 sectorscd0 at scsibus1 targ 2 lun 0: HL-DT-ST, DVDRAM GH24NSB0, LN01 ATAPI 5/cdrom removableohci0 at pci0 dev 18 function 0 AMD Hudson-2 USB rev 0x11: apic 3 int 18, version 1.0, legacy supportehci0 at pci0 dev 18 function 2 AMD Hudson-2 USB2 rev 0x11: apic 3 int 17usb0 at ehci0: USB revision 2.0uhub0 at usb0 AMD EHCI root hub rev 2.00/1.00 addr 1ohci1 at pci0 dev 19 function 0 AMD Hudson-2 USB rev 0x11: apic 3 int 18, version 1.0, legacy supportehci1 at pci0 dev 19 function 2 AMD Hudson-2 USB2 rev 0x11: apic 3 int 17usb1 at ehci1: USB revision 2.0uhub1 at usb1 AMD EHCI root hub rev 2.00/1.00 addr 1piixpm0 at pci0 dev 20 function 0 AMD Hudson-2 SMBus rev 0x14: pollingiic0 at piixpm0spdmem0 at iic0 addr 0x53: 4GB DDR3 SDRAM PC3-10600pciide0 at pci0 dev 20 function 1 AMD Hudson-2 IDE rev 0x00: DMA, channel 0 configured to compatibility, channel 1 configured to compatibilityazalia1 at pci0 dev 20 function 2 AMD Hudson-2 HD Audio rev 0x01: apic 3 int 16azalia1: codecs: Realtek/0x0887audio0 at azalia1pcib0 at pci0 dev 20 function 3 AMD Hudson-2 LPC rev 0x11ppb1 at pci0 dev 20
Re: Error while building current
On 11/28/14 20:52, Edgar Pettijohn wrote: Not terribly concerned just wanted to let the powers that be know about this error. Will try and update src and rebuild tomorrow. === usr.sbin/httpdcc -O2 -pipe -Wall -I/usr/src/usr.sbin/httpd -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wshadow -Wpointer-arith -Wsign-compare -c parse.c/usr/src/usr.sbin/httpd/parse.y: In function 'yyparse':/usr/src/usr.sbin/httpd/parse.y:289: error: expected expression before '' token/usr/src/usr.sbin/httpd/parse.y:293: error: ^^ expected expression before '==' token/usr/src/usr.sbin/httpd/parse.y:300: ^^ error: expected expression before '' ^^ token/usr/src/usr.sbin/httpd/parse.y:442: error: expected expression before '' token/usr/src/usr.sbin/httpd/parse.y:461: error: expected expression before '==' token/usr/src/usr.sbin/httpd/parse.y:484: error: expected expression before '' token*** Error 1 in usr.sbin/httpd (sys.mk:87 'parse.o')*** Error 1 in usr.sbin (bsd.subdir.mk:48 'all')*** Error 1 in . (bsd.subdir.mk:48 'all')*** Error 1 in /usr/src (Makefile:82 'build') the powers that be don't care about local errors. ;) the , == and errors pretty well indicate you have a CVS conflict in that directory. Most likely, you have some local changes which conflicted with something new, if you run cvs up -Pd in that directory, you will probably see an M or C in front of at least parse.y Either reconcile your local changes with the ones in tree, or delete the files with M and C chars in the beginning of the CVS output and update again. Here is dmesg if anyone wants it. We love dmesg porn. Unfortunately, your mail client mangled that pretty completely. :( Nick.
Re: Ancient source-changes archive
Or barring that does anyone happen to recall the full name of pierre@? On Nov 28, 2014, at 14:43, Kent R. Spillner kspill...@acm.org wrote: Thanks guys, but this is for the same problem I was complaining about on icb ~1 month ago. There's a tiny discrepancy between the ChangeLogs and CVS history, and I'm hoping some long-time user that is also a pack rat might have a private archive that would help figure out which is correct. On Nov 28, 2014, at 14:29, Christian Weisgerber na...@mips.inka.de wrote: On 2014-11-28, Ingo Schwarze schwa...@usta.de wrote: For developers, the same is available in /cvs/CVSROOT/ChangeLog*. For anybody mirroring the repository. -- Christian naddy Weisgerber na...@mips.inka.de
