Re: Is lack of a prompt in shell after building the kernel bad news?
On 2015-08-04, Joel Rees joel.r...@gmail.com wrote: Thought login was freezing after the welcome message, beacause there was no prompt. So I hit the power button, watched it stop CUPS and something else and sync, and moved the old kernel back in for a build with GPT enabled, as a first wild guess. Same results, but I tried a few commands instead of just assuming no prompt meant freeze, and the only problem seems to be lack of prompt. Sort of. Piping to a pager doesn't page either. This kernel and userland are out of sync, there was a change made at some point (I think it was between 5.7 and now but I could be wrong) which did exactly this. IIRC this is the behaviour when you have newer userland and old kernel. Check your CVS trees and make sure they're at the tags you expect (if that's 5.7, cd /usr/src cvs up -Pd -r OPENBSD_5_7, if -current then -A instead of -r tag).
Re: Is lack of a prompt in shell after building the kernel bad news?
On Tue, August 4, 2015 7:09 am, Stuart Henderson wrote: This kernel and userland are out of sync, there was a change made at some point (I think it was between 5.7 and now but I could be wrong) which did exactly this. IIRC this is the behaviour when you have newer userland and old kernel. Check your CVS trees and make sure they're at the tags you expect (if that's 5.7, cd /usr/src cvs up -Pd -r OPENBSD_5_7, if -current then -A instead of -r tag). I can concur. I did this to myself last week when I forgot one of my machines was running -current and I applied the -stable kernel. Tim.
Re: reply-to for blocked packets
Em 04-08-2015 04:52, Kapetanakis Giannis escreveu: I've already have rules for outgoing traffic that utilize route-to. However this applies only for new packets generated from host itself. It does not match on returns. Not necessarily true. You can filter on your outgoing interfaces as this: pass out on $ext_iface1 from ($ext2_iface) route-to ($ext_iface1 $ext1_gw) keep state pass out on $ext_iface2 from ($ext1_iface) route-to ($ext_iface1 $ext1_gw) keep state This will enforce that any rogue packets going out on the wrong if, gets routed to the right gw. Of course this is for natted packets, since I using the external interfaces ip addresses. For routed packets, you will need to write more specific rules. Dropping instead of return would definitely stop it. Routing domains indeed seems they only solution in case I want returns. Not sure if they are the only solution, but it seems to be the easiest one to deploy, in your case. if block rules with return do create a state, why do they not respect the reply-to ? Now you got me. I would need to read the source to answer you, but I believe that reply-to ends up only working for pass rules, not block ones. Cheers, Giancarlo Razzolini
smtpd.conf.5 relay tls | verify
Hi! I maybe have overlooked something, but this syntax mentioned in the manual didn't work: accept from any for domain ... relay backup verify expire 30d ... on the other hand, this has been working: accept from any for domain ... relay backup tls verify expire 30d ... and writing only 'tls' also did work. Index: smtpd.conf.5 === RCS file: /cvs/src/usr.sbin/smtpd/smtpd.conf.5,v retrieving revision 1.126 diff -p -u -r1.126 smtpd.conf.5 --- smtpd.conf.54 Jun 2015 14:23:00 - 1.126 +++ smtpd.conf.54 Aug 2015 13:53:50 - @@ -311,7 +311,7 @@ This parameter may use conversion specif .Op Ic hostname Ar name .Op Ic hostnames No Ns Ar names Ns .Op Ic pki Ar pkiname -.Op Ic tls | verify +.Op Ic tls | tls verify .Ek .Xc .Pp Daniel
SNMP on 5.7/5.8
The broken SNMP on i386/5.7 is preventing me from upgrading. I tried i386/5.8 but I'm still seeing net-snmpd crash with the following error. NET-SNMP version 5.7.3 Error expanding HCInReceives to 64bits in ipSystemStatsTable.ipv4 Error expanding HCInDelivers to 64bits in ipSystemStatsTable.ipv4 Error expanding HCOutRequests to 64bits in ipSystemStatsTable.ipv4 Is amd64 the new i386? Would my energy be best spent migrating my default install to amd64? Thanks. -Steve S.
Re: Is lack of a prompt in shell after building the kernel bad news?
On 04/08/15 11:43, Joel Rees wrote: I did a cvs update yesterday (-rOPENBSD_5_7, previous update toward the end of June) in the middle of network problems. Updated src and then ports and then xenocara. Took from about eight in the morning to about eleven at night. So, without doing a build, I went back and updated ports and then src again, to get everything in sync as best I could. Built the kernel, checking myself against the FAQ. The previous build was with GPT enabled, but this build was plain GENERIC. Thought login was freezing after the welcome message, beacause there was no prompt. So I hit the power button, watched it stop CUPS and something else and sync, and moved the old kernel back in for a build with GPT enabled, as a first wild guess. Same results, but I tried a few commands instead of just assuming no prompt meant freeze, and the only problem seems to be lack of prompt. Sort of. Piping to a pager doesn't page either. set does show that the prompt variable and other such things are set like they're supposed to be. The previous kernel behaves itself, as it should. I'm thinking I'm going to go ahead and try building userland, to see if that restores things, but I thought I'd ask how unusual this kind of behavior between building the kernel and the userland is. I'll post the dmesg from the GPT kernel, at least, before I start the build. I erased the non-GPT kernel without getting a dmesg, but I can build it again if someone tells me I should before then. -- Joel Rees why don't you get the latest snapshot and then build on top of that? G
samba - bad performance
Hi, is anyone running samba with decent performance willing to help? I'm running samba-3.6.15 on OpenBSD 5.8 (amd64) on a Supermicro D525 Atom board with 4GB memory and em(4) nics. When transferring a 1GB file from Windows 7 to samba, it won't exceed 22-25MB/s. After lots of testing, the only thing that helps is increasing the recv/send buffer in smb.conf via socket options. When setting SO_RCVBUF and SO_SNDBUF to 5 i get around 60MB/s. As i'm no fan of very.fast.network=yes knobs like this, i'd like to get more opinions on how to improve performance with samba. Thanks, -Mark -- Mark Patruck ( mark at wrapped.cx ) GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 http://www.wrapped.cx
Re: reply-to for blocked packets
On 03/08/15 16:45, Giancarlo Razzolini wrote: Em 03-08-2015 05:23, Kapetanakis Giannis escreveu: Is there a way to sort this out and route packets to the correct interface? You can try to create enforcing rules. Create 2 rules in your outgoing interfaces that, when they detect a packet leaving a interface but it should be on the other, you force route-to rules (not reply-to) on them. Block rules with return do create states, but as soon as the packet is sent, they enter in TIME_WAIT status (as it should be). Do you really, really, need to return the packets? Perhaps in your case you can benefit from routing domains. Cheers, Giancarlo Razzolini I've already have rules for outgoing traffic that utilize route-to. However this applies only for new packets generated from host itself. It does not match on returns. Dropping instead of return would definitely stop it. Routing domains indeed seems they only solution in case I want returns. Thanks G ps. if block rules with return do create a state, why do they not respect the reply-to ?
Re: Any way to tell what the last cvs module checked before a broken pipe was?
2015/08/04 6:24 dan mclaughlin thev...@openmailbox.org: On Mon, 3 Aug 2015 21:17:12 +0900 Joel Rees joel.r...@gmail.com wrote: I try a cvs update on xenocara and it just sits there for over an hour and then tells me I have a broken pipe. cvs log seems to yield the same behavior, which I might interpret as re-assuring, or I might wonder whether the same network problems are tarpitting the log command. cvs -t just gives me screensfull of Sending [various configure, makefile, aclocal], which doesn't tell me a lot. Anyway (short of looking at every module on cvsweb to prove to myself that there really wasn't anything to update in stable xenocara since June 13th) to check that I got through all the modules? -- Joel Rees [...] IIRC somebody else had a similar problem some months ago, so you might want to check the archives. have you tried other cvs sites? Well I see I am not being careful about what questions I ask, again. The broken pipe is something I am now familiar with, having asked about it before. What I would like to know about is away to tell how far the update got without having to watch the screen for thirty, forty minutes or more. I wasn't remembering tee yesterday, and even tee wouldn't have helped in the case of zero change between updates. If I hadn't been having network problems, I probably wouldn't have thought about it, no news being (usually) good news with cvs update. checking the cvs archives (https://marc.info/?l=openbsd-cvsr=1w=2) shows the last commit to xerocara was on July 30. This would have been helpful yesterday, although it looks like I still (maybe?) end up looking at cvsweb to be sure a particular update is against the -stable label. At least I couldn't see a tag or label spec on the several I looked at going backwards from July 30 just now. (Sometimes I don't see what is right in front of me, though, so I'll check again later.) As it turned out, my connection cleared up a little after eleven last night, and I was able to see it pick up the few updates in xenocara. (And now I have another little riddle I haven't seen before.) Thanks for pointing out the commit list. It's definitely a resource I've been ignoring. -- Joel Rees Computer memory is just fancy paper, CPUs are just fancy pens. All is a stream of text flowing from the past into the future.
Re: Is lack of a prompt in shell after building the kernel bad news?
On Tue, Aug 4, 2015 at 6:22 PM, Kapetanakis Giannis bil...@edu.physics.uoc.gr wrote: On 04/08/15 11:43, Joel Rees wrote: I did a cvs update yesterday (-rOPENBSD_5_7, previous update toward the end of June) in the middle of network problems. Updated src and then ports and then xenocara. Took from about eight in the morning to about eleven at night. So, without doing a build, I went back and updated ports and then src again, to get everything in sync as best I could. Built the kernel, checking myself against the FAQ. The previous build was with GPT enabled, but this build was plain GENERIC. Thought login was freezing after the welcome message, beacause there was no prompt. So I hit the power button, watched it stop CUPS and something else and sync, and moved the old kernel back in for a build with GPT enabled, as a first wild guess. Same results, but I tried a few commands instead of just assuming no prompt meant freeze, and the only problem seems to be lack of prompt. Sort of. Piping to a pager doesn't page either. set does show that the prompt variable and other such things are set like they're supposed to be. The previous kernel behaves itself, as it should. I'm thinking I'm going to go ahead and try building userland, to see if that restores things, but I thought I'd ask how unusual this kind of behavior between building the kernel and the userland is. I'll post the dmesg from the GPT kernel, at least, before I start the build. I erased the non-GPT kernel without getting a dmesg, but I can build it again if someone tells me I should before then. -- Joel Rees why don't you get the latest snapshot and then build on top of that? I do that, too, on an install on a USB3 attached drive. Last Friday or so I had some X11 issues that I still need to look into. In the meantime, I like to keep this box -stable on the internal drive. -- Joel Rees Be careful when you look at conspiracy. Arm yourself with knowledge of yourself, as well: http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html
Is lack of a prompt in shell after building the kernel bad news?
I did a cvs update yesterday (-rOPENBSD_5_7, previous update toward the end of June) in the middle of network problems. Updated src and then ports and then xenocara. Took from about eight in the morning to about eleven at night. So, without doing a build, I went back and updated ports and then src again, to get everything in sync as best I could. Built the kernel, checking myself against the FAQ. The previous build was with GPT enabled, but this build was plain GENERIC. Thought login was freezing after the welcome message, beacause there was no prompt. So I hit the power button, watched it stop CUPS and something else and sync, and moved the old kernel back in for a build with GPT enabled, as a first wild guess. Same results, but I tried a few commands instead of just assuming no prompt meant freeze, and the only problem seems to be lack of prompt. Sort of. Piping to a pager doesn't page either. set does show that the prompt variable and other such things are set like they're supposed to be. The previous kernel behaves itself, as it should. I'm thinking I'm going to go ahead and try building userland, to see if that restores things, but I thought I'd ask how unusual this kind of behavior between building the kernel and the userland is. I'll post the dmesg from the GPT kernel, at least, before I start the build. I erased the non-GPT kernel without getting a dmesg, but I can build it again if someone tells me I should before then. -- Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: Show us your /etc/profile
On Aug 2, 2015, at 8:49 AM, li...@wrant.com wrote:
never
thought of using a shell function in .profile till I read this thread.
...
Functions has always been impressive once you move past the alias
shortcomings (can't handle arguments etc), so also worth a read the
Functions section.
Functions have been amazingly useful and impressive for a very long time. They
are also not limited to ksh. In fact, my introduction to this very useful
aspect of shell programming was from Sun's rcS script, which has this:
# Simulates cat in sh so it doesn't need to be on the root filesystem.
#
shcat() {
while [ $# -ge 1 ]; do
while read i; do
echo $i
done $1
shift
done
}
There have been times when I've been on systems in single user mode without
filesystems, and knowing how to do some things we typically use external
programs for in the shell can be a lifesaver, like echo * as a poor man's
ls.
If your directory isn't *that* large, 'for i in *; do echo $i; done | wc -l'
works well. Well, for some definition of 'well'.
My point is that shell functions allow you to do some fairly complex stuff, and
if you're careful, you can avoid execs. There are places the shell forks,
however. It can be a fun exercise to find them with profiling tools. :-)
Sean
Re: Possible fix for i217 problem
On Wed, Aug 05, 2015 at 02:04:28AM +0200, Hrvoje Popovski wrote: On 4.8.2015. 23:47, Stuart Henderson wrote: On 2015/08/04 22:40, Stefan Fritsch wrote: someone mentioned to me the i217-LM problems that were reported on misc end of May. It is possible that the patch below helps. This fixes my Dell poweredge T20: em0 at pci0 dev 25 function 0 Intel I217-LM rev 0x04: msi, address f8:b1:56:... And doesn't break my X220: em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x04: msi, address f0:de:f1:... I have the same revionsl 82579LM on this new-to-me X220, and I just ran some tcpbench(1) tests through a vlan(4) with the patch. Seems to be fine though I was only testing end-to-end with an Alix using vr(4), so only 100BaseT. the diff is unlikely to affect performance, specifically. it will affect cable plugins, removals, other link layer decisions, etc.
Re: Docker on OpenBSD?
Em 04-08-2015 17:48, Etienne escreveu: Couldn't agree more. And someone else writes it better than I do: http://www.vitavonni.de/blog/201503/2015031201-the-sad-state-of-sysadmin-in-the-age-of-containers.html I truly don't know which is worse: Developers pretending to be sysadmins or sysadmins (if you can call them that) being lazy. I bet that a lot of the good old fashioned admins got replaced by a new devop who can deploy everything really fast cutting every corner possible. And people still want it to be ported to OpenBSD. Cheers, Giancarlo Razzolini
Re: Docker on OpenBSD?
Em 04-08-2015 18:28, openda...@hushmail.com escreveu: a) Discourse is not a conventional Rails app. It has been abstracted to the point of insanity and will require you to make a ton of modifications and disable a ton of stuff if you decide to go that route, Kind figured. To me, any system that need to abstract how it's even deployed, is not a good system. b) if you don't use their official Docker image, the user community will simply refuse to help you over at http://meta.discourse.org. What help? It's a docker container, ain't it? It will never give you problems. ;-) p.s.: I've recently installed gitlab from source and it's also an rails app. But they have a very good documentation on how to do it, and you can understand most of what is happening. Even though they are always advising you to use their Omnibus package.
Re: Docker on OpenBSD?
Hi! On Tuesday, August 04, 2015 at 4:47 PM, Mike Larkin mlar...@azathoth.net wrote: From your first link: Docker on FreeBSD relies heavily on ZFS, jail and the 64bit Linux compatibility layer I think that says enough to answer your question. Sort of, but https://news.ycombinator.com/item?id=8480433 does mention sysjail for OpenBSD. That post is quite old, so maybe things have changed since then? Thanks! O.D.
Re: Possible fix for i217 problem
On 2015/08/04 22:40, Stefan Fritsch wrote:
someone mentioned to me the i217-LM problems that were reported on misc
end of May. It is possible that the patch below helps.
This fixes my Dell poweredge T20:
em0 at pci0 dev 25 function 0 Intel I217-LM rev 0x04: msi, address
f8:b1:56:...
And doesn't break my X220:
em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x04: msi, address
f0:de:f1:...
Readers with I217 / I218 / 82579 devices, please test, especially if network
is currently WORKING for you. We know it fixes various issues but the important
thing is that this isn't at the expense of other systems.
For us, it fixed a problem on a laptop with i217-LM (pci id 8086:153a)
where the receiving of packets would stop until the battery of the laptop
was removed (or until linux or freebsd were booted, which also have this
workaround). A normal reboot or power-cycle without removing the battery
did not help. Interestingly, not even the Intel PXE BIOS has the
workaround.
The problem would happen if the LAN cable was plugged in after the card
had already been initialized. If the LAN cable was always plugged in when
the laptop was powered on, the problem would not appear.
The workaround is part of the e1000_lv_jumbo_workaround_ich8lan() function
in e1000_ich8lan.c in freebsd, but only the part that is used if jumbo
packets are *not* configured. Linux has the same fix as
b20a774495671f037e7160ea2ce87 and da1e2046e5f5ab268e55d30d6b74099ade0aeb6f
with some more info in the commit messages.
This probably has quite some potential to cause regressions with other
boards, so i am not sure if it should go in before 5.8 release.
Cheers,
Stefan
--- a/sys/dev/pci/if_em_hw.c
+++ b/sys/dev/pci/if_em_hw.c
@@ -91,6 +91,7 @@ static int32_t em_id_led_init(struct em_hw *);
static int32_t em_init_lcd_from_nvm_config_region(struct em_hw *,
uint32_t,
uint32_t);
static int32_t em_init_lcd_from_nvm(struct em_hw *);
+static int32_t em_phy_no_cable_workaround(struct em_hw *);
static void em_init_rx_addrs(struct em_hw *);
static void em_initialize_hardware_bits(struct em_hw *);
static boolean_t em_is_onboard_nvm_eeprom(struct em_hw *);
@@ -7018,6 +7019,96 @@ em_read_mac_addr(struct em_hw *hw)
}
/**
+ * Explicitly disables jumbo frames and resets some PHY registers back to hw-
+ * defaults. This is necessary in case the ethernet cable was inserted AFTER
+ * the firmware initialized the PHY. Otherwise it is left in a state where
+ * it is possible to transmit but not receive packets. Observed on I217-LM
and
+ * fixed in FreeBSD's sys/dev/e1000/e1000_ich8lan.c.
+ *
+ * hw - Struct containing variables accessed by shared code
+
*/
+STATIC int32_t
+em_phy_no_cable_workaround(struct em_hw *hw) {
+ int32_t ret_val, dft_ret_val;
+ uint32_t mac_reg;
+ uint16_t data, phy_reg;
+
+ /* disable Rx path while enabling workaround */
+ em_read_phy_reg(hw, I2_DFT_CTRL, phy_reg);
+ ret_val = em_write_phy_reg(hw, I2_DFT_CTRL, phy_reg | (1 14));
+ if (ret_val)
+ return ret_val;
+
+ /* Write MAC register values back to h/w defaults */
+ mac_reg = E1000_READ_REG(hw, FFLT_DBG);
+ mac_reg = ~(0xF 14);
+ E1000_WRITE_REG(hw, FFLT_DBG, mac_reg);
+
+ mac_reg = E1000_READ_REG(hw, RCTL);
+ mac_reg = ~E1000_RCTL_SECRC;
+ E1000_WRITE_REG(hw, RCTL, mac_reg);
+
+ ret_val = em_read_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_CTRL, data);
+ if (ret_val)
+ goto out;
+ ret_val = em_write_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_CTRL,
+ data ~(1 0));
+ if (ret_val)
+ goto out;
+
+ ret_val = em_read_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_HD_CTRL, data);
+ if (ret_val)
+ goto out;
+
+ data = ~(0xF 8);
+ data |= (0xB 8);
+ ret_val = em_write_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_HD_CTRL, data);
+ if (ret_val)
+ goto out;
+
+ /* Write PHY register values back to h/w defaults */
+ em_read_phy_reg(hw, I2_SMBUS_CTRL, data);
+ data = ~(0x7F 5);
+ ret_val = em_write_phy_reg(hw, I2_SMBUS_CTRL, data);
+ if (ret_val)
+ goto out;
+
+ em_read_phy_reg(hw, I2_MODE_CTRL, data);
+ data |= (1 13);
+ ret_val = em_write_phy_reg(hw, I2_MODE_CTRL, data);
+ if (ret_val)
+ goto out;
+
+ /*
+ * 776.20 and 776.23 are not documented in
+ * i217-ethernet-controller-datasheet.pdf...
+ */
+ em_read_phy_reg(hw, PHY_REG(776, 20), data);
+ data = ~(0x3FF 2);
+ data |= (0x8 2);
+ ret_val = em_write_phy_reg(hw, PHY_REG(776, 20), data);
+ if (ret_val)
+ goto out;
+
+ ret_val = em_write_phy_reg(hw,
Re: Possible fix for i217 problem
On 2015/08/04 22:40, Stefan Fritsch wrote: someone mentioned to me the i217-LM problems that were reported on misc end of May. It is possible that the patch below helps. This fixes my Dell poweredge T20: em0 at pci0 dev 25 function 0 Intel I217-LM rev 0x04: msi, address f8:b1:56:... And doesn't break my X220: em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x04: msi, address f0:de:f1:... Readers with I217 / I218 / 82579 devices, please test, especially if network is currently WORKING for you. We know it fixes various issues but the important thing is that this isn't at the expense of other systems. This diff will be in the next snapshots, for rapid testing before release. The most important goal ensuring this does not cause a regression for other chips. Don't test the ones this hopes to fix. Test the ones it shouldn't affect!!!
Re: Possible fix for i217 problem
On 4.8.2015. 23:47, Stuart Henderson wrote: On 2015/08/04 22:40, Stefan Fritsch wrote: someone mentioned to me the i217-LM problems that were reported on misc end of May. It is possible that the patch below helps. This fixes my Dell poweredge T20: em0 at pci0 dev 25 function 0 Intel I217-LM rev 0x04: msi, address f8:b1:56:... And doesn't break my X220: em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x04: msi, address f0:de:f1:... Readers with I217 / I218 / 82579 devices, please test, especially if network is currently WORKING for you. We know it fixes various issues but the important thing is that this isn't at the expense of other systems. don't know if this is relevant but intel i350 seems to work normal after this patches.
Re: smtpd.conf.5 relay tls | verify
On Tue, Aug 04, 2015 at 04:02:10PM +0200, L?VAI D?niel wrote: I maybe have overlooked something, but this syntax mentioned in the manual didn't work: accept from any for domain ... relay backup verify expire 30d ... on the other hand, this has been working: accept from any for domain ... relay backup tls verify expire 30d ... and writing only 'tls' also did work. This looks like the correct documentation fix to me. In usr.sbin/smtpd/parse.y, opt_relay allows TLS or TLS VERIFY. opt_relay_via allows for VERIFY but that's not reachable from RELAY relay. Index: smtpd.conf.5 === RCS file: /cvs/src/usr.sbin/smtpd/smtpd.conf.5,v retrieving revision 1.126 diff -p -u -r1.126 smtpd.conf.5 --- smtpd.conf.5 4 Jun 2015 14:23:00 - 1.126 +++ smtpd.conf.5 4 Aug 2015 13:53:50 - @@ -311,7 +311,7 @@ This parameter may use conversion specif .Op Ic hostname Ar name .Op Ic hostnames No Ns Ar names Ns .Op Ic pki Ar pkiname -.Op Ic tls | verify +.Op Ic tls | tls verify .Ek .Xc .Pp
Re: smtpd.conf.5 relay tls | verify
On Tue, Aug 04, 2015 at 04:00:58PM -0700, Doug Hogan wrote: On Tue, Aug 04, 2015 at 04:02:10PM +0200, L?VAI D?niel wrote: I maybe have overlooked something, but this syntax mentioned in the manual didn't work: accept from any for domain ... relay backup verify expire 30d ... on the other hand, this has been working: accept from any for domain ... relay backup tls verify expire 30d ... and writing only 'tls' also did work. This looks like the correct documentation fix to me. In usr.sbin/smtpd/parse.y, opt_relay allows TLS or TLS VERIFY. opt_relay_via allows for VERIFY but that's not reachable from RELAY relay. Index: smtpd.conf.5 === RCS file: /cvs/src/usr.sbin/smtpd/smtpd.conf.5,v retrieving revision 1.126 diff -p -u -r1.126 smtpd.conf.5 --- smtpd.conf.54 Jun 2015 14:23:00 - 1.126 +++ smtpd.conf.54 Aug 2015 13:53:50 - @@ -311,7 +311,7 @@ This parameter may use conversion specif .Op Ic hostname Ar name .Op Ic hostnames No Ns Ar names Ns .Op Ic pki Ar pkiname -.Op Ic tls | verify +.Op Ic tls | tls verify .Ek .Xc .Pp if this were the case, i'd say we want: [tls [verify]] but the doc currently says: Note that the tls and verify options are mutually exclusive and should only be used in private networks as they will prevent proper relaying on the Internet. so the fix proposed is not enough (or too much ;) jmc
Re: Docker on OpenBSD?
On Tue, Aug 04, 2015 at 09:30:37PM +, openda...@hushmail.com wrote: Hi! On Tuesday, August 04, 2015 at 4:47 PM, Mike Larkin mlar...@azathoth.net wrote: From your first link: Docker on FreeBSD relies heavily on ZFS, jail and the 64bit Linux compatibility layer I think that says enough to answer your question. Sort of, but https://news.ycombinator.com/item?id=8480433 does mention sysjail for OpenBSD. That post is quite old, so maybe things have changed since then? Thanks! O.D. the short answer is no, docker does not work on openbsd. if you are interested in making it work, please do so and send a diff.
Re: new (nasty) spam pattern
On 30/07/2015 23:07, Steve Fairhead wrote: Oooh, nice. Some meat there for me to look into. Thanks. Well, it seems I could have phrased that better... (one private response had me nonplussed until I googled the phrase - refers to a male with a larger than average... errr... never mind.) Thanks to all those who responded - apologies if I haven't responded individually - this old dog has learned some new tricks, which can't be bad. Meanwhile, my database of sinners really should be out there to ... But where? I update it several times a day... Have decided I'll publish the list somewhere on my site soon. Details will include: - domain or email pattern (as /etc/mail/access) - IP address of mailserver (or relayer, as reported in /var/log/maillog) - whois ID of domain (which has proved interesting - it's a small number of players) - datestamp when added to my dbase Hopefully this will help some other admins... Steve -- -- Steve Fairhead fivetrees ltd - for the complete music service www: http://www.fivetrees.com --
Re: Docker on OpenBSD?
Are there any efforts being made to port the FreeBSD Docker port to OpenBSD? Should there be any effort to port some trendy this year marketed commercially supported tool while the entire OpenBSD feature set totally obsoletes the tool on application design stage, or is there any good reason to be this effort? You know complexity and tool mixes enforce complexity and reliability problems to all levels including the personnel installing and maintaining the software stack, despite what marketing material says. Wish I didn't have to ask, but it's the only way I can install Discourse (https://github.com/discourse/discourse) without being shunned by its community (https://forums.docker.com/t/solutions-for-docker-on-freebsd/2082/). Maybe you don't have to ask after all ;-) Let me rephrase: A good idea is to follow the developer instructions and install on Linux and/or FreeBSD, or rather the operating systems and environments used by the application developers, otherwise you're depraving yourself of their help and support, or would you think of it as dependability. Optimistically, OpenBSD has always solved problems elegantly and efficiently, so look forward in the future for the sustainable way to solve the problems your question relates to. This future may be now, depending how good the application developers understand OpenBSD and what this gives us as correct solutions.
Re: Docker on OpenBSD?
On 08/04/2015 07:44 PM, Giancarlo Razzolini wrote: Em 04-08-2015 12:59, openda...@hushmail.com escreveu: Are there any efforts being made to port the FreeBSD Docker port to OpenBSD? Not that I know of, but I'm not a dev and might be wrong. I do follow @tech, and didn't saw anything docker related, ever since I'm on the list. My personal opinion is that OpenBSD shouldn't even get near docker. But hey, it's my opinion. but it's the only way I can install Discourse From what I read on their site, they use off the shelf software that might have a package/port on OpenBSD. You could succeed in installing it outside a docker. Unless their software is stupid and try to verify if you're inside a docker and refuses to run if not. They just use RoR, and it definitely run on OpenBSD.
Re: Docker on OpenBSD?
On Tue, Aug 04, 2015 at 03:59:38PM +, openda...@hushmail.com wrote: Hi! Are there any efforts being made to port the FreeBSD Docker port to OpenBSD? https://wiki.freebsd.org/Docker https://github.com/kvasdopil/docker Wish I didn't have to ask, but it's the only way I can install Discourse (https://github.com/discourse/discourse) without being shunned by its community (https://forums.docker.com/t/solutions-for-docker-on-freebsd/2082/). Thanks! O.D. From your first link: Docker on FreeBSD relies heavily on ZFS, jail and the 64bit Linux compatibility layer I think that says enough to answer your question.
Re: Docker on OpenBSD?
Em 04-08-2015 12:59, openda...@hushmail.com escreveu: Are there any efforts being made to port the FreeBSD Docker port to OpenBSD? Not that I know of, but I'm not a dev and might be wrong. I do follow @tech, and didn't saw anything docker related, ever since I'm on the list. My personal opinion is that OpenBSD shouldn't even get near docker. But hey, it's my opinion. but it's the only way I can install Discourse From what I read on their site, they use off the shelf software that might have a package/port on OpenBSD. You could succeed in installing it outside a docker. Unless their software is stupid and try to verify if you're inside a docker and refuses to run if not. Cheers, Giancarlo Razzolini
Re: Docker on OpenBSD?
Em 04-08-2015 13:50, Gregory Edigarov escreveu: They just use RoR, and it definitely run on OpenBSD. Do you know what these docker ready images sound to me? Laziness. Truth is, we have an avalanche of developers that are empowered by these so called devops tools, puppet, chef, docker ready images, etc. But they grow accustomed with this so called readiness and easiness that they never bother to know what's under the hood. Heck, they don't even bother to know if the under the hood is secure. These tools certainly have their use on the development phase of a project. And puppet and friends certainly make the job of admins easier. The difference, as always, lies on who is using. You see the OP grow so fond of this easiness that he comes to the point of asking on this list (without even searching first) if OpenBSD will import the FreeBSD docker port, so that he can simply take a image and install something, that can, with some work and thinking, be installed on the metal. This is wrong. And is also part of the security problem. Cheers, Giancarlo Razzolini
Possible fix for i217 problem
Hi,
someone mentioned to me the i217-LM problems that were reported on misc
end of May. It is possible that the patch below helps.
For us, it fixed a problem on a laptop with i217-LM (pci id 8086:153a)
where the receiving of packets would stop until the battery of the laptop
was removed (or until linux or freebsd were booted, which also have this
workaround). A normal reboot or power-cycle without removing the battery
did not help. Interestingly, not even the Intel PXE BIOS has the
workaround.
The problem would happen if the LAN cable was plugged in after the card
had already been initialized. If the LAN cable was always plugged in when
the laptop was powered on, the problem would not appear.
The workaround is part of the e1000_lv_jumbo_workaround_ich8lan() function
in e1000_ich8lan.c in freebsd, but only the part that is used if jumbo
packets are *not* configured. Linux has the same fix as
b20a774495671f037e7160ea2ce87 and da1e2046e5f5ab268e55d30d6b74099ade0aeb6f
with some more info in the commit messages.
This probably has quite some potential to cause regressions with other
boards, so i am not sure if it should go in before 5.8 release.
Cheers,
Stefan
--- a/sys/dev/pci/if_em_hw.c
+++ b/sys/dev/pci/if_em_hw.c
@@ -91,6 +91,7 @@ static int32_tem_id_led_init(struct em_hw *);
static int32_t em_init_lcd_from_nvm_config_region(struct em_hw *, uint32_t,
uint32_t);
static int32_t em_init_lcd_from_nvm(struct em_hw *);
+static int32_t em_phy_no_cable_workaround(struct em_hw *);
static voidem_init_rx_addrs(struct em_hw *);
static voidem_initialize_hardware_bits(struct em_hw *);
static boolean_t em_is_onboard_nvm_eeprom(struct em_hw *);
@@ -7018,6 +7019,96 @@ em_read_mac_addr(struct em_hw *hw)
}
/**
+ * Explicitly disables jumbo frames and resets some PHY registers back to hw-
+ * defaults. This is necessary in case the ethernet cable was inserted AFTER
+ * the firmware initialized the PHY. Otherwise it is left in a state where
+ * it is possible to transmit but not receive packets. Observed on I217-LM and
+ * fixed in FreeBSD's sys/dev/e1000/e1000_ich8lan.c.
+ *
+ * hw - Struct containing variables accessed by shared code
+ */
+STATIC int32_t
+em_phy_no_cable_workaround(struct em_hw *hw) {
+ int32_t ret_val, dft_ret_val;
+ uint32_t mac_reg;
+ uint16_t data, phy_reg;
+
+ /* disable Rx path while enabling workaround */
+ em_read_phy_reg(hw, I2_DFT_CTRL, phy_reg);
+ ret_val = em_write_phy_reg(hw, I2_DFT_CTRL, phy_reg | (1 14));
+ if (ret_val)
+ return ret_val;
+
+ /* Write MAC register values back to h/w defaults */
+ mac_reg = E1000_READ_REG(hw, FFLT_DBG);
+ mac_reg = ~(0xF 14);
+ E1000_WRITE_REG(hw, FFLT_DBG, mac_reg);
+
+ mac_reg = E1000_READ_REG(hw, RCTL);
+ mac_reg = ~E1000_RCTL_SECRC;
+ E1000_WRITE_REG(hw, RCTL, mac_reg);
+
+ ret_val = em_read_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_CTRL, data);
+ if (ret_val)
+ goto out;
+ ret_val = em_write_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_CTRL,
+ data ~(1 0));
+ if (ret_val)
+ goto out;
+
+ ret_val = em_read_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_HD_CTRL, data);
+ if (ret_val)
+ goto out;
+
+ data = ~(0xF 8);
+ data |= (0xB 8);
+ ret_val = em_write_kmrn_reg(hw, E1000_KUMCTRLSTA_OFFSET_HD_CTRL, data);
+ if (ret_val)
+ goto out;
+
+ /* Write PHY register values back to h/w defaults */
+ em_read_phy_reg(hw, I2_SMBUS_CTRL, data);
+ data = ~(0x7F 5);
+ ret_val = em_write_phy_reg(hw, I2_SMBUS_CTRL, data);
+ if (ret_val)
+ goto out;
+
+ em_read_phy_reg(hw, I2_MODE_CTRL, data);
+ data |= (1 13);
+ ret_val = em_write_phy_reg(hw, I2_MODE_CTRL, data);
+ if (ret_val)
+ goto out;
+
+ /*
+* 776.20 and 776.23 are not documented in
+* i217-ethernet-controller-datasheet.pdf...
+*/
+ em_read_phy_reg(hw, PHY_REG(776, 20), data);
+ data = ~(0x3FF 2);
+ data |= (0x8 2);
+ ret_val = em_write_phy_reg(hw, PHY_REG(776, 20), data);
+ if (ret_val)
+ goto out;
+
+ ret_val = em_write_phy_reg(hw, PHY_REG(776, 23), 0x7E00);
+ if (ret_val)
+ goto out;
+
+ em_read_phy_reg(hw, I2_PCIE_POWER_CTRL, data);
+ ret_val = em_write_phy_reg(hw, I2_PCIE_POWER_CTRL, data ~(1 10));
+ if (ret_val)
+ goto out;
+
+out:
+ /* re-enable Rx path after enabling workaround */
+ dft_ret_val = em_write_phy_reg(hw, I2_DFT_CTRL, phy_reg ~(1 14));
+ if (ret_val)
+ return ret_val;
+ else
+ return dft_ret_val;
+}
+
Docker on OpenBSD?
Hi! Are there any efforts being made to port the FreeBSD Docker port to OpenBSD? https://wiki.freebsd.org/Docker https://github.com/kvasdopil/docker Wish I didn't have to ask, but it's the only way I can install Discourse (https://github.com/discourse/discourse) without being shunned by its community (https://forums.docker.com/t/solutions-for-docker-on-freebsd/2082/). Thanks! O.D.
Re: Is lack of a prompt in shell after building the kernel bad news?
Thanks for the comments. On Tue, Aug 4, 2015 at 5:43 PM, Joel Rees joel.r...@gmail.com wrote: I did a cvs update yesterday (-rOPENBSD_5_7, previous update toward the end of June) in the middle of network problems. Updated src and then ports and then xenocara. Took from about eight in the morning to about eleven at night. So, without doing a build, I went back and updated ports and then src again, to get everything in sync as best I could. Built the kernel, checking myself against the FAQ. The previous build was with GPT enabled, but this build was plain GENERIC. Thought login was freezing after the welcome message, beacause there was no prompt. So I hit the power button, watched it stop CUPS and something else and sync, and moved the old kernel back in for a build with GPT enabled, as a first wild guess. Same results, but I tried a few commands instead of just assuming no prompt meant freeze, and the only problem seems to be lack of prompt. Sort of. Piping to a pager doesn't page either. set does show that the prompt variable and other such things are set like they're supposed to be. The previous kernel behaves itself, as it should. I'm thinking I'm going to go ahead and try building userland, to see if that restores things, but I thought I'd ask how unusual this kind of behavior between building the kernel and the userland is. I'll post the dmesg from the GPT kernel, at least, before I start the build. I erased the non-GPT kernel without getting a dmesg, but I can build it again if someone tells me I should before then. I tried deleting all the configurations in /usr/src/sys/arch/`machine`/compile and putting the names of the GPT-enabled configurations in .cvsignore in the same directory, but no desired results. Compiling a GENERIC kernel now produces a kernel that just goes into recursive reset within two lines of output after the boot prompt. Compiling a GPT-enabled kernel produces the results I mention above, unprompted shell, etc. I think this is the effect warned about in reference to working with custom kernels, where I get to keep both pieces. (Heh. So much for keeping the box -stable.) I'm debating whether to go ahead and compile userland with the misbehaving shell, but I would end up with a system I think I would have reason to distrust, even if it appeared stable. So, the lesson is that custom kernels are not something one wants to have to upgrade or update, I guess. Patch carefully instead of cvs up with stable. And rebuild for the next OS version. Get the work done quickly. And I should avoid doing this kind of dev work on a box that I'm trying to use as a (portable) workstation. Sorry for the noise. -- Joel Rees Be careful when you look at conspiracy. Arm yourself with knowledge of yourself, as well: http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html
Re: Possible fix for i217 problem
On Tue, Aug 04, 2015 at 07:16:48PM -0600, Theo de Raadt wrote: On Wed, Aug 05, 2015 at 02:04:28AM +0200, Hrvoje Popovski wrote: On 4.8.2015. 23:47, Stuart Henderson wrote: On 2015/08/04 22:40, Stefan Fritsch wrote: someone mentioned to me the i217-LM problems that were reported on misc end of May. It is possible that the patch below helps. This fixes my Dell poweredge T20: em0 at pci0 dev 25 function 0 Intel I217-LM rev 0x04: msi, address f8:b1:56:... And doesn't break my X220: em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x04: msi, address f0:de:f1:... I have the same revionsl 82579LM on this new-to-me X220, and I just ran some tcpbench(1) tests through a vlan(4) with the patch. Seems to be fine though I was only testing end-to-end with an Alix using vr(4), so only 100BaseT. the diff is unlikely to affect performance, specifically. it will affect cable plugins, removals, other link layer decisions, etc. OK, well, plug in/out ran through my ifstated(8) states properly, switching to the rtwn(4) for egress, and switched back. Suspend/resume seemed to behave as before, also.
Re: Docker on OpenBSD?
Hi! On Tuesday, August 04, 2015 at 4:44 PM, Giancarlo Razzolini grazzol...@gmail.com wrote: From what I read on their site, they use off the shelf software that might have a package/port on OpenBSD. You could succeed in installing it outside a docker. Unless their software is stupid and try to verify if you're inside a docker and refuses to run if not. Well, sort of. You can install it outside Docker but a) Discourse is not a conventional Rails app. It has been abstracted to the point of insanity and will require you to make a ton of modifications and disable a ton of stuff if you decide to go that route, b) if you don't use their official Docker image, the user community will simply refuse to help you over at http://meta.discourse.org. Thanks! O.D.
Re: Possible fix for i217 problem
On Wed, Aug 05, 2015 at 02:04:28AM +0200, Hrvoje Popovski wrote: On 4.8.2015. 23:47, Stuart Henderson wrote: On 2015/08/04 22:40, Stefan Fritsch wrote: someone mentioned to me the i217-LM problems that were reported on misc end of May. It is possible that the patch below helps. This fixes my Dell poweredge T20: em0 at pci0 dev 25 function 0 Intel I217-LM rev 0x04: msi, address f8:b1:56:... And doesn't break my X220: em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x04: msi, address f0:de:f1:... I have the same revionsl 82579LM on this new-to-me X220, and I just ran some tcpbench(1) tests through a vlan(4) with the patch. Seems to be fine though I was only testing end-to-end with an Alix using vr(4), so only 100BaseT.
