from:"Jeff"

I appreciate the suggestion but yeah, LDAP is totally overkill here. There's 
really only this one server that needs access to the auth info in the passwd 
file, so LDAP wouldn't really help me.

Re: Options for dealing with DES crypt password file

I completely understand. The running chainsaw analogy is pretty accurate here. 
OpenBSD is as secure as it is because you all remove as many chainsaws as 
possible. We needed to update those hashes anyway someday. I just wasn't 
expecting that day to be today.


Thanks again!


From: Theo de Raadt <dera...@openbsd.org>
Sent: Thursday, January 11, 2018 12:49:33 PM
To: Jeff Zimmerman
Cc: misc@openbsd.org
Subject: Re: Options for dealing with DES crypt password file

> I was hoping that there was some hidden switch somewhere that would turn
> the classic crypt back on. No such luck.

That'd be like leaving a running chainsaw on the floor at a daycare center.

When something is dangerous, we get rid of it.

Re: Options for dealing with DES crypt password file

I know, I'm ashamed to say that yes, this machine has been running (behind a 
restrictive firewall) for all of these years.


I was hoping that there was some hidden switch somewhere that would turn the 
classic crypt back on. No such luck.


But thank you for the quick response. I've been using OpenBSD for a lot of 
years and really appreciate your efforts Theo, and the efforts of everyone 
associated with the project.


From: Theo de Raadt <dera...@openbsd.org>
Sent: Thursday, January 11, 2018 12:29:59 PM
To: Jeff Zimmerman
Cc: misc@openbsd.org
Subject: Re: Options for dealing with DES crypt password file

> I've got an old server (OpenBSD 4.7 old) with a mixed bag of password hashes
> in master.passwd. A majority of the passwords (hundreds) are old salted
> DES crypt format.

bummer

> Am I correct in my research that everything but Blowfish was removed from
> crypt() around OpenBSD 5.7? Are there any workarounds for me using the old
> DES password hashes, or do we need to 'passwd ' for hundreds of users?

There are no workarounds.  The hashes cannot be reversed to make new
passwords, and the legacy methods are removed intentionally because they
are super weak

You been running that on the internet?  the shame!

Options for dealing with DES crypt password file

I've got an old server (OpenBSD 4.7 old) with a mixed bag of password hashes in 
master.passwd. A majority of the passwords (hundreds) are old salted DES crypt 
format.


Am I correct in my research that everything but Blowfish was removed from 
crypt() around OpenBSD 5.7? Are there any workarounds for me using the old DES 
password hashes, or do we need to 'passwd ' for hundreds of users?

Re: Keeping up to date with ports and putting ports/pobj on wxallowed filesystem

2017-11-09 Thread Jeff

On Thu, 9 Nov 2017 22:06:43 +0100
"Christoph R. Murauer" <n...@nawi.is> wrote:

> If I understood your question correct ...
> 
> > Running: OpenBSD6.2-release
> >
> > Goal: To run a secure and functional web server.
> > (the server is currently up and running and used by
> > the public at large)
> 
> If there are security related patches or things needed to be fixed,
> that the package works as it should, you can simple run pkg_add -iu

Thanks for your replay Christoph.

Please correct me if I'm wrong, but as I understand things, this only
works if one is following OpenBSD-current.  I am running -release.
This is an in-use production server; I don't feel wise running -current.

> You can add wxallowed to a already mounted filesystem using mount(8).

In theory, I don't like this;  I would rather keep preventing everything
not mapped from /use/local from being able to have both writable and
executeable pages, even if it's only temporary.

> > Is it not worth it to update ports in this way; meaning, is it better
> > to simply wait for OpenBSD6.3 and stick with binary packages only
> > (as recommended on the openbsd.org site)?
> 
> That depends on your requirements. See above.

My answer also depends.  Ideally, I'd want to jump on any update for
any software for which a security advisory has been issued.  Also,
I do wish to track other non-critical updates to keep the server's
software relatively up-to-date as not to fall behind; picking up 
performance and related enhancements in a bonus.  In practice,
at least for myself and my available time, this isn't always feasible
(e.g. the ports tree doesn't have the latest software available as a port
and it would also be a significant time commitment to build and install
the software from the original source and successfully integrate it into
OpenBSD.)

For example, moving to php v7.1.11 or 7.2 fall into this category
(see: http://www.securityfocus.com/bid/101745)
.
Looking at what the ports system has to do to make the php 7.0.23
package, I'd be spending my life getting 7.2 to build and work properly
and I feel this is better left to those with more OpenBSD porting
experience.

Some software builds and integrates from original sources more easilym
that is, the usual:
./configure {reasonable options} -> make -> make install
procedure goes off withotu a hitch, or at least without too many edits.

> > Also, is there an easy/sane way to remove packages that were only
> > required for building once the ports have been updated?
> 
> A port is a package. See make clean and so on for builded ports and
> pkg_delete -a for packages. IMHO Who say, that something unneeded is
> installed ? It also has no effect to the system if build deps. are
> kept in the ports tree.

I understand that the ports system first builds and packages a port,
and then installs it.

I could be doing something wrong, but it seems that some ports install
dependencies to the system (pkg_add-style) that are required to *build*
the package from source, but that aren't required to *run* the package
(e.g. cmake).

So, I definitely don't mind leaving the built packages in the ports
tree, but I *do* mind leaving them installed on the system.

-- 
Jeff <j...@grayspace.ca>

Re: Keeping up to date with ports and putting ports/pobj on wxallowed filesystem

2017-11-09 Thread Jeff

On Thu, 9 Nov 2017 14:04:39 -0500
Jeff <j...@grayspace.ca> wrote:

> Is it not worth it to update ports in this way; meaning, is it better
> to simply wait for OpenBSD6.3 and stick with binary packages only
> (as recommended on the openbsd.org site)?

It is has been pointed out to me that my meaning here is unclear.
I will attempt to clarify:

openbsd.org says:
The ports tree is meant for advanced users.
Everyone is encouraged to use the pre-compiled binary packages.

I do not imply that openbsd.org recommends waiting for the next release
and not patching software.

A better statement would possibly have been:

Is it not worth it to update ports in this way; meaning,
is it better to simply wait for OpenBSD6.3 and stick with
binary packages?

The openbsd.org site says:
The ports tree is meant for advanced users.
Everyone is encouraged to use the pre-compiled
binary packages.

I'm looking for the advice of those more experienced than myself.

-- 
Jeff <j...@grayspace.ca>

Keeping up to date with ports and putting ports/pobj on wxallowed filesystem

2017-11-09 Thread Jeff

Hello all,

Is this the sane/correct thing to do?  What is the impact?

Running: OpenBSD6.2-release

Goal: To run a secure and functional web server.
(the server is currently up and running and used by
the public at large)

Previously: Only installing needed packages as binaries via pkg_add.

Now: The thought is that the third-party packages being used
by the server should be kept up to date.

Ports tree via:
$ cvs -qd anon...@anoncvs4.usa.openbsd.org:/cvs\
  checkout -rOPENBSD_6_2 -P ports

Problem: Some out of date packages found via 'out-of-date' e.g.:
$ /usr/ports/infrastructure/bin/out-of-date
...
Outdated ports:

databases/mariadb,-main# 10.0.32v1 -> 10.0.33v1
databases/mariadb,-server  # 10.0.32v1 -> 10.0.33v1
...

complain when running 'make update' (in this case mariadb). e.g.:
Fatal: /usr/ports/pobj must be on a wxallowed filesystem\
  (in lang/python/2.7)

To solve this issue, this is what I've done:

$cat /etc/mk.conf
SUDO=/usr/bin/doas
WRKOBJDIR=/usr/local/ports/pobj <---

(since /usr/local is on a wxallowed filesystem)

Is this a rational solution to the problem? I'm somewhat regretting
going this route as, unlike with pkg_add, building some ports from the
tree pulls in more dependencies than via pkg_add (I am assuming that
these are build dependencies and not run-time dependencies; please
correct me if this is not so)

Is it not worth it to update ports in this way; meaning, is it better
to simply wait for OpenBSD6.3 and stick with binary packages only
(as recommended on the openbsd.org site)?

Also, is there an easy/sane way to remove packages that were only
required for building once the ports have been updated?

I'm loathe to do something like build the packages on another system
and then install them as binary packages on the server; this seems like
a lot of effort and, at least for myself might be prone
to introduce other issues.

Thank-you in advance; advice is appreciated.

-- 
Jeff <j...@grayspace.ca>

Re: acme-client(1) and http_proxy

2017-04-26 Thread Jeff Ross


On 4/26/17 12:41 PM, Theo de Raadt wrote:


I haven't seen anyone mention acme.sh yet--a shell script for
letsencrypt with no external dependencies.

https://github.com/Neilpang/acme.sh

No external dependencies, and no security foundations.

No privsep, no clear seperation.

Using pretty much every unsafe pattern tied to security holes in the past.

Using the openssl command *GO READ THAT CODE SOMETIME*, don't go read
the libressl one, go read upstream openssl command source.

No attempt at security.

Just doing the job, and assuming every mistake later can be

It's like constructing jetliners from foundational components, and by
that I mean sticks and stones.

I'm sorry, but I don't get it.  It is crazy to recommend something
that hasn't been STUDIED to ensure it dutifully tries to only perform
the task and creates no new risk.


Always good to hear from you, Theo!

acme.sh does not require root/sudoer access.  For sure I run it as an 
unprivileged user and hope you do as well!


Jeff

Re: acme-client(1) and http_proxy

2017-04-26 Thread Jeff Ross


On 4/26/17 11:02 AM, Stuart Henderson wrote:


On 2017-04-25, Adam Thompson <athom...@athompso.net> wrote:

On 2017-04-25 05:27, Stuart Henderson wrote:


* If you want to do dns-01 challenge with acme-client, you'll need to
use Kristaps' version for now, base acme-client only supports the
standard http challenge type. The UI isn't the simplest; use
'-t dns-01', then it outputs "dns-01 domainname token.key", then
you convert token.key into a suitable format for a DNS TXT record:
   "echo -n token.key | sha256 -b | tr -d = | tr + - | tr / _"
Get the record to the nameserver, then send the whole "dns-01
domainname token.key" line back to acme-client, and cross fingers.
If there are too many errors you'll lock yourself out for a period,
so test with the staging server first.


I haven't seen anyone mention acme.sh yet--a shell script for 
letsencrypt with no external dependencies.


https://github.com/Neilpang/acme.sh

It was trivial for me to write a dns api script for djbdns--very handy 
to have to bootstrap a new domain without previously setting up http in 
apache2 first.


I'd send that out to anyone interested--ask me off list.

Jeff

Re: Bad kernel for OpenBSD 6.1 sparc64 ?

2017-04-25 Thread Jeff


On Sun, 23 Apr 2017, Stefan Sperling wrote:
> On Sat, Apr 22, 2017 at 04:31:02PM -0600, Jeff wrote:
> > Booting from sr0a seemed to do the trick to get my system upgraded to
> > 6.1.  Unfortunately, it's now panicing frequently with, "panic:
> > psycho0: uncorrectable DMA error" but on different commands each time.
>
> Please follow the steps in https://www.openbsd.org/report.html
> In the past we have found bugs in drivers where the hardware ends up
> doing an out of bounds access during DMA transactions. On most platforms
> those bugs don't get noticed but psycho on sparc64 is catching them
> which results in this panic.

Due to the criticality of my system, I installed 6.1 from scratch on
a spare V120.  That system seems to be working great.  I was going
to wait a few days and rebuild the first system to try and determine
if it has a hardware issue but I'll wait and submit a bug report first.

> > Question: After upgrading to 6.1, it's still booting with "OpenBSD
> > BOOT 1.7" but I noticed when booting from the burned install61.iso
> > CD, it reports BOOT 1.9.  I tried running "installboot sd2"  but
> > there's no change.  Is there another method I'm overlooking to
> > update the boot image?
>
> Is sd2 your softraid disk? What does installboot -n -v sd2 say?
>

# installboot -n -v sd2
Using / as root
would install bootstrap on /dev/rsd2c
using first-stage /usr/mdec/bootblk, second-stage /usr/mdec/ofwboot
boot block is 5840 bytes (12 blocks @ 512 bytes = 6144 bytes)
sd2: softraid volume with 2 disk(s)
sd0d: installing boot blocks on /dev/rsd0c
would write boot block to disk /dev/rsd0c
sd1d: installing boot blocks on /dev/rsd1c
would write boot block to disk /dev/rsd1c

# ls -l /usr/mdec
total 428
-rw-r--r--  1 root  bin5840 Apr  1 16:21 bootblk
-r--r--r--  1 root  bin  101048 Apr  1 16:21 ofwboot
-r--r--r--  1 root  bin   53608 Apr  1 16:21 ofwboot.net
-r--r--r--  1 root  bin   53320 Apr  1 16:21 ofwbootfd

Based on the timestamps, things seem to be in order.

Thanks!

-Jeff

Re: Bad kernel for OpenBSD 6.1 sparc64 ?

2017-04-22 Thread Jeff

On Fri, 21 Apr 2017, Jeff wrote:

> On Fri, 21 Apr 2017, Stefan Sperling wrote:
>
> > On Thu, Apr 20, 2017 at 06:13:47PM -0600, Jeff wrote:
> > > Hi,
> > >
> > > I have a Sunfire V120 (Sparc) with mirrored disks running OpenBSD 6.0.
> > > I attempted to update to OpenBSD 6.1 using the files first from:
> > >
> > > http://mirrors.sonic.net/pub/OpenBSD/6.1/sparc64
> > >
> > > Then from:
> > >
> > > https://ftp3.usa.openbsd.org/pub/OpenBSD/6.1/sparc64
> > >
> > > First I tried to copy bsd.rd to / and boot from it.  When I boot
> > > using 6.1 bsd.rd (boot /bsd.rd), the boot messages still show
> > > OpenBSD 6.0.
> >
> > Did you actually type '/boot bsd.rd'?
> > When booting from softraid you need to pass the virtual 'sr' drive
> > as part of the boot path. Try again with: boot sr0a:/bsd.rd
> >
> > >From the boot_sparc64(8) man page:
> >
> >  To boot from a softraid(4) volume by default, boot-device must be set 
> > to
> >  a disk device hosting a chunk of the softraid volume:
> >
> >ok setenv boot-device disk0
> >
> >  and boot-file must contain the (sr) device name of the softraid volume
> >  and optionally a partition letter and/or kernel:
> >
> >ok setenv boot-file sr0a:/bsd
> >
>
> Hi Stefan,
>
> Thanks!
>
> I must have missed that man page when I originally installed 6.0.
> Booting with sr0a:/bsd* did work but it took a much longer time
> loading the symbols with both bsd & bsd.rd.  I'll be sure to read
> that man page and try again later today after I'm done working (in
> case I muck it up again).
>
> Using a non-standard name for the bsd.rd file seems to help clarify
> things.
>
> ok printenv boot-device
> boot-device = disk1:a /pci@1f,0/pci@1/scsi@8/disk@1,0:a
>
> ok boot disk1:a /bsd.rd.61
> ...
> Executing last command: boot disk1:a /bsd.rd.61
> Boot device: /pci@1f,0/pci@1/scsi@8/disk@1,0:a  File and args:
> /bsd.rd.61
> OpenBSD IEEE 1275 Bootblock 1.4
> ..>> OpenBSD BOOT 1.7
> Can't read disk label.
> Can't open disk label package
> Drive not ready
> Can't read disk label.
> Can't open disk label package
> sr0*
> open /pci@1f,0/pci@1/scsi@8/disk@1,0:a/etc/random.seed: No such file or 
> directory
> open /pci@1f,0/pci@1/scsi@8/disk@1,0:a/bsd.rd.61: No such file or directory
>
> Boot:
>
> lom> reset
>
> ok boot sr0a:/bsd.rd.61
> Boot device: /pci@1f,0/pci@1/scsi@8/disk@1,0:a  File and args:
> sr0a:/bsd.rd.61
> OpenBSD IEEE 1275 Bootblock 1.4
> ..>> OpenBSD BOOT 1.7
> Can't read disk label.
> Can't open disk label package
> Drive not ready
> Can't read disk label.
> Can't open disk label package
> sr0*
> Booting sr0:a/bsd.rd.61
> 4045496@0x100+1352@0x13dbab8+3251904@0x180+942400@0x1b19ec0
> symbols @ 0xfff42300 120 start=0x100
> console is /pci@1f,0/pci@1,1/isa@7/serial@0,3f8
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2017 OpenBSD. All rights reserved.
> https://www.OpenBSD.org
> OpenBSD 6.1 (RAMDISK) #55: Sat Apr  1 17:41:52 MDT 2017
> dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/RAMDISK
>
>

Hi,

Booting from sr0a seemed to do the trick to get my system upgraded to
6.1.  Unfortunately, it's now panicing frequently with, "panic:
psycho0: uncorrectable DMA error" but on different commands each time.
I know this is old hardware so I'm trying to swap out hardware to see
if it's hardware related but it's been pretty stable until I attempted
to upgrade from 6.0.  Thus far, I've swapped out the DIMMs.  I think
I'm going to try installing 6.1 on a spare V120 partially to see if
I still have issues and partially to have a backup system.

Question: After upgrading to 6.1, it's still booting with "OpenBSD
BOOT 1.7" but I noticed when booting from the burned install61.iso
CD, it reports BOOT 1.9.  I tried running "installboot sd2"  but
there's no change.  Is there another method I'm overlooking to
update the boot image?

Thanks!

-Jeff

Re: Bad kernel for OpenBSD 6.1 sparc64 ?

2017-04-21 Thread Jeff

On Fri, 21 Apr 2017, Stefan Sperling wrote:

> On Thu, Apr 20, 2017 at 06:13:47PM -0600, Jeff wrote:
> > Hi,
> >
> > I have a Sunfire V120 (Sparc) with mirrored disks running OpenBSD 6.0.
> > I attempted to update to OpenBSD 6.1 using the files first from:
> >
> > http://mirrors.sonic.net/pub/OpenBSD/6.1/sparc64
> >
> > Then from:
> >
> > https://ftp3.usa.openbsd.org/pub/OpenBSD/6.1/sparc64
> >
> > First I tried to copy bsd.rd to / and boot from it.  When I boot
> > using 6.1 bsd.rd (boot /bsd.rd), the boot messages still show
> > OpenBSD 6.0.
>
> Did you actually type '/boot bsd.rd'?
> When booting from softraid you need to pass the virtual 'sr' drive
> as part of the boot path. Try again with: boot sr0a:/bsd.rd
>
> >From the boot_sparc64(8) man page:
>
>  To boot from a softraid(4) volume by default, boot-device must be set to
>  a disk device hosting a chunk of the softraid volume:
>
>ok setenv boot-device disk0
>
>  and boot-file must contain the (sr) device name of the softraid volume
>  and optionally a partition letter and/or kernel:
>
>ok setenv boot-file sr0a:/bsd
>

Hi Stefan,

Thanks!

I must have missed that man page when I originally installed 6.0.
Booting with sr0a:/bsd* did work but it took a much longer time
loading the symbols with both bsd & bsd.rd.  I'll be sure to read
that man page and try again later today after I'm done working (in
case I muck it up again).

Using a non-standard name for the bsd.rd file seems to help clarify
things.

ok printenv boot-device
boot-device = disk1:a /pci@1f,0/pci@1/scsi@8/disk@1,0:a

ok boot disk1:a /bsd.rd.61
...
Executing last command: boot disk1:a /bsd.rd.61
Boot device: /pci@1f,0/pci@1/scsi@8/disk@1,0:a  File and args:
/bsd.rd.61
OpenBSD IEEE 1275 Bootblock 1.4
..>> OpenBSD BOOT 1.7
Can't read disk label.
Can't open disk label package
Drive not ready
Can't read disk label.
Can't open disk label package
sr0*
open /pci@1f,0/pci@1/scsi@8/disk@1,0:a/etc/random.seed: No such file or 
directory
open /pci@1f,0/pci@1/scsi@8/disk@1,0:a/bsd.rd.61: No such file or directory

Boot:

lom> reset

ok boot sr0a:/bsd.rd.61
Boot device: /pci@1f,0/pci@1/scsi@8/disk@1,0:a  File and args:
sr0a:/bsd.rd.61
OpenBSD IEEE 1275 Bootblock 1.4
..>> OpenBSD BOOT 1.7
Can't read disk label.
Can't open disk label package
Drive not ready
Can't read disk label.
Can't open disk label package
sr0*
Booting sr0:a/bsd.rd.61
4045496@0x100+1352@0x13dbab8+3251904@0x180+942400@0x1b19ec0
symbols @ 0xfff42300 120 start=0x100
console is /pci@1f,0/pci@1,1/isa@7/serial@0,3f8
Copyright (c) 1982, 1986, 1989, 1991, 1993
   The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2017 OpenBSD. All rights reserved.
https://www.OpenBSD.org
OpenBSD 6.1 (RAMDISK) #55: Sat Apr  1 17:41:52 MDT 2017
dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/RAMDISK

Bad kernel for OpenBSD 6.1 sparc64 ?

2017-04-20 Thread Jeff

Hi,

I have a Sunfire V120 (Sparc) with mirrored disks running OpenBSD 6.0.
I attempted to update to OpenBSD 6.1 using the files first from:

http://mirrors.sonic.net/pub/OpenBSD/6.1/sparc64

Then from:

https://ftp3.usa.openbsd.org/pub/OpenBSD/6.1/sparc64

First I tried to copy bsd.rd to / and boot from it.  When I boot
using 6.1 bsd.rd (boot /bsd.rd), the boot messages still show
OpenBSD 6.0.

I selected update, selected my mirrored boot/root device but it would
only give options to update bsd, bsd.rd & bsd.mp.  I selected http and
it defaulted to a URL that had /6.0/ in the path.  I changed it to 6.1
but it wouldn't list any of the *61.tgz files.

After rebooting normally (using the new /bsd), it would still show
that I'm running 6.0 (and BOOT 1.7).

Then I tried burning the install61.iso to a CD and booting from it.
The boot messages would show OpenBSD 6.1 (and BOOT 1.9) and it gave
me the option of updating with the *61.tgz files.  Everything seemed
to install just fine.

However, upon rebooting with /bsd, the boot messages showed I was
still running 6.0 (and BOOT 1.7).  To make matters worse, my IP
filters wouldn't load yielding the error:

pfctl: DIOCADDRULE: Operation not supported by device

Also, pkg_add -u gave the following error:

Couldn't find updates for bash-4.3.46 gettext-0.19.7 libiconv-1.14p3
  libidn-1.32p1 libpsl-0.13.0 libunistring-0.9.7 pcre-8.38p0
  pkglocatedb-1.2 sudo-1.8.17.1 vim-7.4.1467p1-no_x11 wget-1.18

This, of course, broke internet access from my internal network.  I
tried upgrading again from the CD and also tried manually upgrading
using the manual upgrade steps.  All this still resulted in the above
error.

I finally decided to roll back by following the manual update steps
but with the files from the install60.iso media.  My firewall rules
are working again.

Could there be something wrong with the kernel files (bsd, bsd.rd)
available for the OpenBSD 6.1 sparc64 release or am I missing a step?

Thanks!

-Jeff

P.S. As an aside, after downgrading to 6.0, I ran add_pkg -u but
forgot to change the URL in my /etc/pkg.conf back to 6.0 from 6.1.  I
let the packages install but should I do a full manual rollback to 6.0
before reattempting another 6.1 upgrade?

Re: PostgreSQL problem with mod_perl2 and Apache2

2017-03-20 Thread Jeff Ross


On 3/19/17 8:26 PM, Chris Bennett wrote:

I have been switching over to mod_perl2 and Apache2.
I finally found some good info to fill in the blanks. Sigh.

Everything seems to be pulling into place fine, but I may still have
some stuff messed up or should I upgrade to a fresher snap?

OpenBSD 6.1-beta (GENERIC.MP) #220: Thu Mar  9 06:40:02 MST 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4277862400 (4079MB)
avail mem = 4143546368 (3951MB)

I can send a full dmesg if helpful.

I am running Apache2 error_log at debug.

I get this message, is it important?

[Sun Mar 19 21:04:41.049481 2017] [core:notice] [pid 45788] AH00052:
child pid 17244 exit signal Bus error (10)

But I get a 500 error on a perfectly good page. Stopping and restarting
PostgreSQL fixes problem.

[Sun Mar 19 20:53:33.137631 2017] [perl:error] [pid 4540] [client
192.168.0.8:42252] DBI
connect('dbname=benconphotos;host=127.0.0.1;port=5432','bencon',...)
failed: FATAL:  sorry, too many clients already at
/usr/local/libdata/perl5/site_perl/MyPerl/PortableBuildingsGuide.pm line
59.\n, referer:
http://192.168.0.8/customer/portable_buildings/Metal_Roofing.html

This occurs randomly on any page. I am not running Firefox 52 yet.

I am the only client, so that isn't the problem.

I added
kern.seminfo.semmni=60  # PostgreSQL
kern.seminfo.semmns=1024# PostgreSQL


Could the fact that I don't have crap for memory be the problem?

Any help appreciated!

Chris Bennett


I use this on a server with 8G ram:

# For PostgreSQL Port
kern.seminfo.semmni=512
kern.seminfo.semmns=4096
kern.shminfo.shmall=65536
kern.shminfo.shmmax=536870912

But the error suggests that you are making too many connections to 
postgres.  What is max_connections in postgresql.conf set to?


By default is is set at 100--I have mine set at:

jross@luna:/home/jross $ psql -d template1
Null display is "NULL".
Timing is on.
psql (9.5.3)
Type "help" for help.

jross@template1 localhost# show max_connections;
 max_connections
-
 80
(1 row)

Time: 0.643 ms

and this is a fairly busy webserver running apache2 (no mode_perl though).

If you really are running out of connections (check the postgres logs to 
make sure) I'd suggest adding a connection pooler like pgbouncer in 
front of postgres rather than just blindly bumping up max_connections.


Jeff

Re: Making sense of ktrace

2016-11-24 Thread Jeff Ross


On 11/23/16 8:25 PM, Jeremie Courreges-Anglas wrote:

"Andy Bradford" <amb-open...@bradfords.org> writes:


Thus said Jeff Ross on Wed, 23 Nov 2016 15:42:08 -0700:


The  stack may  indeed  be too  damaged--I get  the  following but  it
doesn't look very helpful:


More likely the symbols were stripped.

Assuming this was installed from sources,  edit conf-cc and add -g, then
edit conf-ld and remove the -s:

$ head -1 conf-cc
cc -O2 -g
$ head -1 conf-ld
cc


Better add -g here too.


$

Then recompile  and try  again (e.g.  get a  new core  file and  run gdb
again).

Andy




I made the change to conf-cc and conf-ld and indeed, I got a core file 
that showed the source and the point of failure.


Thanks Andy and Jeremie!

Jeff

Re: Making sense of ktrace

2016-11-23 Thread Jeff Ross


On 11/23/16 1:16 PM, Otto Moerbeek wrote:

On Wed, Nov 23, 2016 at 12:37:12PM -0700, Jeff Ross wrote:


Hi all,

I've got a program that seg faults on OpenBSD 6.0 AMD64 release that runs
fine on 5.9 i386.

I'm checking to see if will also run on 5.9 AMD64 right now but it doesn't
appear to be w^x related.  To be sure I've mounted that partition with
wxallowed.

Here are the last few lines from kdump--would sure appreciate it if someone
could shed some light on what's happening.

 47868 fastforward CALL
mmap(0,0x1000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
 47868 fastforward RET   mmap 9049032314880/0x83ae45b5000
 47868 fastforward CALL
mmap(0,0x1000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
 47868 fastforward RET   mmap 9049215606784/0x83aef482000
 47868 fastforward CALL
mmap(0,0xa000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
 47868 fastforward RET   mmap 9047796883456/0x83a9ab82000
 47868 fastforward CALL  mprotect(0x83b09fd2000,0x1000,0x1)
 47868 fastforward RET   mprotect 0
 47868 fastforward CALL  munmap(0x83a9ab82000,0xa000)
 47868 fastforward RET   munmap 0
 47868 fastforward CALL  mprotect(0x83870f07000,0x1000,0x1)
 47868 fastforward RET   mprotect 0
 47868 fastforward CALL  getthrid()
 47868 fastforward RET   getthrid 1047868/0xffd3c
 47868 fastforward CALL  __set_tcb(0x83b14ce3600)
 47868 fastforward RET   __set_tcb 0
 47868 fastforward CALL
mmap(0,0x1000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
 47868 fastforward RET   mmap 9049102131200/0x83ae884a000
 47868 fastforward CALL  mprotect(0x83ae884a000,0x1000,0x1)
 47868 fastforward RET   mprotect 0
 47868 fastforward CALL
mprotect(0x83ae884a000,0x1000,0x3<PROT_READ|PROT_WRITE>)
 47868 fastforward RET   mprotect 0
 47868 fastforward CALL  mprotect(0x83ae884a000,0x1000,0x1)
 47868 fastforward RET   mprotect 0
 47868 fastforward CALL  sigaction(SIGPIPE,0x7f7cdec0,0)
 47868 fastforward STRU  struct sigaction { handler=SIG_IGN, mask=0<>,
flags=0<> }
 47868 fastforward RET   sigaction 0
 47868 fastforward PSIG  SIGSEGV SIG_DFL code SEGV_MAPERR<1> addr=0x71008620
trapno=6
 47868 fastforward NAMI  "fastforward.core"


The program is aborted by a SIGSEGV. Thta means it is accessing a
memory location that is not  allocated by the program.



I've re-compiled this also with what I found on the internet to make a core
file that gdb can use but that's even more of a mystery to me than ktrace.
Is there a better debugger that I can use?

Thanks,

Jeff Ross


$ gdb fastforward fastforward.core
then type the command bt, should give you some clue, if the stack isn't
damaged too much.

-Otto


Thank you, Otto!

The stack may indeed be too damaged--I get the following but it doesn't 
look very helpful:


jross@luna:/package/mail/sqmail/sqmail-3.2.13 $ sudo gdb 
/var/qmail/bin/fastforward fastforward.core

GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.0"...(no debugging 
symbols found)


Core was generated by `fastforward'.
Program terminated with signal 11, Segmentation fault.
(no debugging symbols found)
Loaded symbols for /var/qmail/bin/fastforward
Reading symbols from /usr/lib/libc.so.88.0...done.
Loaded symbols for /usr/lib/libc.so.88.0
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
#0  0x0115d4803035 in ?? () from /var/qmail/bin/fastforward
(gdb) bt
#0  0x0115d4803035 in ?? () from /var/qmail/bin/fastforward
#1  0x0115d4802545 in ?? () from /var/qmail/bin/fastforward
#2  0x0115d48015f2 in ?? () from /var/qmail/bin/fastforward
#3  0x in ?? ()
(gdb)

I built fastforward with

cc -g -O0  -include /usr/include/errno.h -pipe

is there a better incantation?

Thanks again!
Jeff

Making sense of ktrace

2016-11-23 Thread Jeff Ross


Hi all,

I've got a program that seg faults on OpenBSD 6.0 AMD64 release that 
runs fine on 5.9 i386.


I'm checking to see if will also run on 5.9 AMD64 right now but it 
doesn't appear to be w^x related.  To be sure I've mounted that 
partition with wxallowed.


Here are the last few lines from kdump--would sure appreciate it if 
someone could shed some light on what's happening.


 47868 fastforward CALL 
mmap(0,0x1000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)

 47868 fastforward RET   mmap 9049032314880/0x83ae45b5000
 47868 fastforward CALL 
mmap(0,0x1000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)

 47868 fastforward RET   mmap 9049215606784/0x83aef482000
 47868 fastforward CALL 
mmap(0,0xa000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)

 47868 fastforward RET   mmap 9047796883456/0x83a9ab82000
 47868 fastforward CALL  mprotect(0x83b09fd2000,0x1000,0x1)
 47868 fastforward RET   mprotect 0
 47868 fastforward CALL  munmap(0x83a9ab82000,0xa000)
 47868 fastforward RET   munmap 0
 47868 fastforward CALL  mprotect(0x83870f07000,0x1000,0x1)
 47868 fastforward RET   mprotect 0
 47868 fastforward CALL  getthrid()
 47868 fastforward RET   getthrid 1047868/0xffd3c
 47868 fastforward CALL  __set_tcb(0x83b14ce3600)
 47868 fastforward RET   __set_tcb 0
 47868 fastforward CALL 
mmap(0,0x1000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)

 47868 fastforward RET   mmap 9049102131200/0x83ae884a000
 47868 fastforward CALL  mprotect(0x83ae884a000,0x1000,0x1)
 47868 fastforward RET   mprotect 0
 47868 fastforward CALL 
mprotect(0x83ae884a000,0x1000,0x3<PROT_READ|PROT_WRITE>)

 47868 fastforward RET   mprotect 0
 47868 fastforward CALL  mprotect(0x83ae884a000,0x1000,0x1)
 47868 fastforward RET   mprotect 0
 47868 fastforward CALL  sigaction(SIGPIPE,0x7f7cdec0,0)
 47868 fastforward STRU  struct sigaction { handler=SIG_IGN, mask=0<>, 
flags=0<> }

 47868 fastforward RET   sigaction 0
 47868 fastforward PSIG  SIGSEGV SIG_DFL code SEGV_MAPERR<1> 
addr=0x71008620 trapno=6

 47868 fastforward NAMI  "fastforward.core"

I've re-compiled this also with what I found on the internet to make a 
core file that gdb can use but that's even more of a mystery to me than 
ktrace.  Is there a better debugger that I can use?


Thanks,

Jeff Ross

Re: Redirect all traffic to new server

2016-10-31 Thread Jeff Ross


On 10/31/16 11:48 AM, Jeff Ross wrote:

On 10/31/16 7:54 AM, Jan Stary wrote:

On Oct 30 11:28:55, jr...@openvistas.net wrote:

Hi all,

I'm moving to a new server hosted at m5 and I'm ready to pull the
trigger on
making the switch.

In the past doing this sort of move I've run into dns update
delays--even
with the ttl on my dns set to 300, there is a lot of e-mail
especially that
continues to attempt to deliver to the old server long after the dns
update
has taken place.

It seems like I should be able to use pf to redirect all inbound traffic
except ssh to the new server.  I tried redirecting web traffic as a test
with the following rule in pf.conf:

#pass all non-ssl web traffic to luna
pass in quick proto tcp to port www rdr-to luna.openvistas.net port 80

but that doesn't work--the connection never completes.  httpd is for
sure
working on the new server--I've been using an /etc/hosts file to test
from
my home Mac and the web sites all work fine.


The rule references the name.
Are you sure it resolves to the new address already?
Would it be safer to just hardcode the IP address for the transition?

Also, this is probably not your _entire_ pf.conf
For example, there is no rule letting the redirected packet out.

Jan



Yes, the domain name resolves.

I followed the example that Philipp pointed me toward and that fixed the
issue of redirecting web traffic.

Thanks for the reply!

Jeff



Update:

I found a tutorial on relayd on calomel.org that helped me better 
understand relayd.  I know full what what the openbsd community thinks 
(and rightfully so most of the time) about these sorts of articles and 
how fast they become outdated and worthless but this one helped me 
better understand relayd.


https://calomel.org/relayd.html

Based on that, I saw that I needed a very simple TCP port relay.  This 
relayd.conf file redirected all web traffic from my existing server to 
the new server hosted at m5:


## Macros
#
varley_addr="64.85.162.217"
luna_addr="207.158.15.155"
www="80"
## TCP port relay and forwarder
#
protocol "tcp_service" {
   tcp { nodelay, socket buffer 65536 }
   }

   relay "www_forwarder" {
   listen on $varley_addr port $www
   protocol "tcp_service"
   forward to $luna_addr port $www
   }


I will also note that the relayd.conf man page also has all of this 
information--see the second relay example--and now that I better 
understand relayd as a whole the rest of the man page makes more sense 
as well.


I've further extended my initial configuration to include smtp, smtps, 
submission and imaps with this configuration:


prefork 10

## Macros
#
varley_addr="64.85.162.217"
luna_addr="207.158.15.155"
www="80"
smtp="25"
imaps="993"
smtps="465"
submission="587"

## TCP port relay and forwarder
#
protocol "tcp_service" {
   tcp { nodelay, socket buffer 65536 }
   }

   relay "www_forwarder" {
   listen on $varley_addr port $www
   protocol "tcp_service"
   forward to $luna_addr port $www
   }
   relay "smtp_forwarder" {
   listen on $varley_addr port $smtp
   protocol "tcp_service"
   forward to $luna_addr port $smtp
   }
   relay "imaps_forwarder" {
   listen on $varley_addr port $imaps
   protocol "tcp_service"
   forward to $luna_addr port $imaps
   }
   relay "smtps_forwarder" {
   listen on $varley_addr port $smtps
   protocol "tcp_service"
   forward to $luna_addr port $smtps
   }
   relay "submission_forwarder" {
   listen on $varley_addr port $submission
   protocol "tcp_service"
   forward to $luna_addr port $submission
   }

relayd -n -f /etc/relayd.conf says the configuration is OK so after peak 
business hours for my clients I'll turn on relayd and see what happens.


If you are familiar with relayd and see something wrong with my 
configuration, please chime in.  I'll report success and any possible 
glitches I run across for the archives.


Thanks for your help and for reading!

Jeff Ross

Re: Redirect all traffic to new server

2016-10-31 Thread Jeff Ross


On 10/31/16 7:54 AM, Jan Stary wrote:

On Oct 30 11:28:55, jr...@openvistas.net wrote:

Hi all,

I'm moving to a new server hosted at m5 and I'm ready to pull the trigger on
making the switch.

In the past doing this sort of move I've run into dns update delays--even
with the ttl on my dns set to 300, there is a lot of e-mail especially that
continues to attempt to deliver to the old server long after the dns update
has taken place.

It seems like I should be able to use pf to redirect all inbound traffic
except ssh to the new server.  I tried redirecting web traffic as a test
with the following rule in pf.conf:

#pass all non-ssl web traffic to luna
pass in quick proto tcp to port www rdr-to luna.openvistas.net port 80

but that doesn't work--the connection never completes.  httpd is for sure
working on the new server--I've been using an /etc/hosts file to test from
my home Mac and the web sites all work fine.


The rule references the name.
Are you sure it resolves to the new address already?
Would it be safer to just hardcode the IP address for the transition?

Also, this is probably not your _entire_ pf.conf
For example, there is no rule letting the redirected packet out.

Jan



Yes, the domain name resolves.

I followed the example that Philipp pointed me toward and that fixed the 
issue of redirecting web traffic.


Thanks for the reply!

Jeff

Re: Redirect all traffic to new server

2016-10-31 Thread Jeff Ross


On 10/31/16 12:10 AM, Philipp Buehler wrote:

Am 30.10.2016 18:28 schrieb Jeff Ross:

It seems like I should be able to use pf to redirect all inbound
traffic except ssh to the new server.  I tried redirecting web traffic
as a test with the following rule in pf.conf:

#pass all non-ssl web traffic to luna
pass in quick proto tcp to port www rdr-to luna.openvistas.net port 80


I just assume that the incoming interface is the same that would be needed
to reach luna.openvistas.net?
If so, please see pf.conf(5) in Translation/rdr-to along the 'received-on'
example.

The rdr-to (as of now) will likely send the SYN to the the desired address,
but the src-ip-address will still be of the initial one ("browser") and
thus
the SYN-ACK (emitted from luna) goes there where it'll be ignored for not
being legit.

The example with received-on will fix this.

HTH,


That worked--I'll try to extend that for the other types of traffic I 
have on the existing server.


Thanks!

Jeff

Redirect all traffic to new server

2016-10-30 Thread Jeff Ross


Hi all,

I'm moving to a new server hosted at m5 and I'm ready to pull the 
trigger on making the switch.


In the past doing this sort of move I've run into dns update 
delays--even with the ttl on my dns set to 300, there is a lot of e-mail 
especially that continues to attempt to deliver to the old server long 
after the dns update has taken place.


It seems like I should be able to use pf to redirect all inbound traffic 
except ssh to the new server.  I tried redirecting web traffic as a test 
with the following rule in pf.conf:


#pass all non-ssl web traffic to luna
pass in quick proto tcp to port www rdr-to luna.openvistas.net port 80

but that doesn't work--the connection never completes.  httpd is for 
sure working on the new server--I've been using an /etc/hosts file to 
test from my home Mac and the web sites all work fine.


This morning it occurred to me that this could probably be done better 
with relayd.  I read (and re-read) the relayd man pages but I'll be the 
first to admit that this sort of networking is not my cup of tea and I 
really don't want to botch this.


Would relayd be the correct solution to redirect all traffic except ssh 
to my new server?  If so, a clue-by-four as to what to put in 
relayd.conf would be greatly appreciated!


Thanks,

Jeff Ross

Re: i386 or amd64?

2016-09-21 Thread Jeff Ross


On 9/21/16 2:15 PM, Christian Weisgerber wrote:


On 2016-09-20, Jeff Ross <jr...@openvistas.net> wrote:


Subject: i386 or amd64?

If the hardware supports it, run amd64.


If I have 8GB, I for sure want to use it all.

You will need amd64 for that.  But even if you have less memory,
the larger address space is beneficial.  Also, AES-NI support is
only implemented for amd64.  And some crypto algorithms are just
faster on 64 bits.


amd64 has this caveat: "(Some Intel
processors lack support for important PAE NX bit, which means those
machines will run without any W^X support -- it is thus safer to run
those machines in i386 mode)."

That is true but very misleading.  It concerns only some rare early
CPUs.  The only ones I can find in Wikipedia's lists of Intel CPUs
are the "Nocona" Xeons from 2004.

I have now removed that caveat from the page.


Hello and thanks to all that responded!

I'll install amd64 on my server--it is being configured right now. dmesg 
to follow.


Thank you naddy for clarifying the amd64.html page and making OpenBSD's 
already superb documentation even better.


Jeff

I've had a server with corenetworks for quite a few years now but after
changes at corenetworks (their recent name change after acquisition by
another company, no current servers available, no communication about
the change of ownership with existing customers and an email exchange
with sales@), I've decided it is best jump ship now rather than wait for
a hard and possibly immediate deadline.

I've just rented a server with 8GB of ram from m5hosting (based in large
part from the many recommendations I read while searching misc@ on
marc.info). Now the question is: i386 which is what I've always run on
my 2 GB ram server, or amd64? http://www.openbsd.org/amd64.html and
http://www.openbsd.org/i386.html are curiously silent on the amount of
ram that can be accessed. If I have 8GB, I for sure want to use it all.

I know there was a time when i386 was limited to the amount of ram it
can access (32 bit) but now amd64 has this caveat: "(Some Intel
processors lack support for important PAE NX bit, which means those
machines will run without any W^X support -- it is thus safer to run
those machines in i386 mode)." How does this fit with the recent work
in 6.0+? How can I tell if the Xeon 3220 processor has the PAE NX bit?
I see nothing in the tech sheet about PAE NX.
http://ark.intel.com/products/28034/Intel-Xeon-Processor-X3220-8M-Cache-2_40-GHz-1066-MHz-FSB

I have a little less than 2 weeks to make the transition so not a lot of
time for install and try.

Thanks in advance for any suggestions--dmesgs supplied once I get access.

Jeff Ross

Open Vistas Networking

Installing php-5.6.18-ap2 alongside php.5.6.18

2016-07-30 Thread Jeff Ross


Hi all,

Running 5.9 and preparing for moving to apache2 in advance of 6.0.

I'm running apache-httpd-openbsd-1.3.20140502p6 currently with 
php-5.6.18 and quite a few php modules.  I'm trying to get 
apache-httpd-2.4.18p1 running on port 81 so I can test all of my vhosts 
before I pull the plug on apache-httpd-openbsd.


Is it possible to install php-5.6.18-ap2 at the same time as php-5.6.18 
without building from source?


I've tried sudo pkg_add -B /usr/local/apache2/ php-5.6.18-ap2 but that 
fails:


#pkg_add -B /usr/local/apache2/ php-5.6.18-ap2
Can't install php-5.6.18-ap2 because of conflicts (php-5.6.18)
--- php-5.6.18-ap2 ---
Can't install php-5.6.18-ap2: conflicts

If I have to build from source to test that's okay--just hoping for a 
pointer to a quicker method that isn't yet obvious to me.


Thanks,

Jeff Ross

Re: [OT] Cloud storage accessible via sftp or rsync/ssh?

2016-07-20 Thread Jeff Ross


On 7/20/16 8:31 AM, Sam Hays wrote:


2016-07-20 11:27 GMT+02:00 John Long <codeb...@inbox.lv>:

Can anybody recommend a good cloud storage provider that has access
via sftp or rsync tunneled through ssh? Everything I have found seems
targeted at Windows, Linux, phones etc. with no platform-agnostic interface.


Consider AWS / S3?  I believe there is an OpenBSD port for aws-cli.  I do 
realize this isn't 1:1 for what you asked, hard to beat the pricing and 
flexibility, though.

Sam

s3cmd is a python script that includes the ability to "sync" directories 
and S3 buckets.  Not quite rsync but close.  I use it to sync a local 
directory on my server storing level 0 through 7 dump files with an S3 
bucket.  Works great, easy to script.


https://sourceforge.net/projects/s3tools/files/s3cmd/

For easy, graphical access to your S3 buckets, try S3 Organizer (used to 
be s3fox), a firefox extension.


Jeff

Re: syslogd on 6.0-beta


Hi Tim,

I await with bated breath to see where the problem is--can't be because 
the version of OpenBSD is too old.


Jeff


On 5/25/16 4:54 PM, trondd wrote:

On Wed, May 25, 2016 6:39 pm, Jeff Ross wrote:

Hello again,

syslogd doesn't actually work for me on 6.0-beta either.

OpenBSD 6.0-beta (GENERIC.MP) #1768: Wed May 18 12:01:43 MDT 2016
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP

I had been running a May 16th snapshot and didn't have a problem that I
noticed.  I just now updated to a May 25th snapshot and still don't have
this problem.

Tim.

syslogd on 6.0-beta

  63699 logger   RET   mprotect 0
  63699 logger   CALL mprotect(0x2a9f3000,0x1000,0x1)
  63699 logger   RET   mprotect 0
  63699 logger   CALL  munmap(0x87d73000,0x5000)
  63699 logger   RET   munmap 0
  63699 logger   CALL mprotect(0x3bc51000,0x190,0x3<PROT_READ|PROT_WRITE>)
  63699 logger   RET   mprotect 0
  63699 logger   CALL 
mprotect(0x1bc51000,0x125d,0x7<PROT_READ|PROT_WRITE|PROT_EXEC>)
  63699 logger   RET   mprotect 0
  63699 logger   CALL mprotect(0x3bc51000,0x190,0x1)
  63699 logger   RET   mprotect 0
  63699 logger   CALL mprotect(0x1bc51000,0x125d,0x5<PROT_READ|PROT_EXEC>)
  63699 logger   RET   mprotect 0
  63699 logger   CALL mprotect(0x3bc53000,0x1000,0x1)
  63699 logger   RET   mprotect 0
  63699 logger   CALL 
mmap(0,0x1000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
  63699 logger   RET   mmap 2146504704/0x7ff11000
  63699 logger   CALL 
mmap(0,0x1000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
  63699 logger   RET   mmap -2061213696/0x85246000
  63699 logger   CALL  getthrid()
  63699 logger   RET   getthrid 1063699/0x103b13
  63699 logger   CALL  __set_tcb(0x7ff11640)
  63699 logger   RET   __set_tcb 0
  63699 logger   CALL  kbind(0xcf7ef088,12,0xe755f07f323e9b25)
  63699 logger   RET   kbind 0
  63699 logger   CALL 
mmap(0,0x1000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
  63699 logger   RET   mmap 2093277184/0x7cc4e000
  63699 logger   CALL mprotect(0x7cc4e000,0x1000,0x1)
  63699 logger   RET   mprotect 0
  63699 logger   CALL  kbind(0xcf7ef048,12,0xe755f07f323e9b25)
  63699 logger   RET   kbind 0
  63699 logger   CALL mprotect(0x7cc4e000,0x1000,0x3<PROT_READ|PROT_WRITE>)
  63699 logger   RET   mprotect 0
  63699 logger   CALL mprotect(0x7cc4e000,0x1000,0x1)
  63699 logger   RET   mprotect 0
  63699 logger   CALL  kbind(0xcf7eec08,12,0xe755f07f323e9b25)
  63699 logger   RET   kbind 0
  63699 logger   CALL  kbind(0xcf7eec08,12,0xe755f07f323e9b25)
  63699 logger   RET   kbind 0
  63699 logger   CALL  getlogin_r(0x2aa04100,32)
  63699 logger   RET   getlogin_r 0
  63699 logger   CALL  kbind(0xcf7eec08,12,0xe755f07f323e9b25)
  63699 logger   RET   kbind 0
  63699 logger   CALL  kbind(0xcf7eec08,12,0xe755f07f323e9b25)
  63699 logger   RET   kbind 0
  63699 logger   CALL  close(1)
  63699 logger   RET   close 0
  63699 logger   CALL  kbind(0xcf7eec08,12,0xe755f07f323e9b25)
  63699 logger   RET   kbind 0
  63699 logger   CALL  pledge(0x3bc510ae,0)
  63699 logger   STRU  pledge request="stdio"
  63699 logger   RET   pledge 0
  63699 logger   CALL  kbind(0xcf7eec08,12,0xe755f07f323e9b25)
  63699 logger   RET   kbind 0
  63699 logger   CALL  kbind(0xcf7eec08,12,0xe755f07f323e9b25)
  63699 logger   RET   kbind 0
  63699 logger   CALL  kbind(0xcf7eec08,12,0xe755f07f323e9b25)
  63699 logger   RET   kbind 0
  63699 logger   CALL  kbind(0xcf7ebca8,12,0xe755f07f323e9b25)
  63699 logger   RET   kbind 0
  63699 logger   CALL  kbind(0xcf7ebc68,12,0xe755f07f323e9b25)
  63699 logger   RET   kbind 0
  63699 logger   CALL  kbind(0xcf7ebca8,12,0xe755f07f323e9b25)
  63699 logger   RET   kbind 0
  63699 logger   CALL  kbind(0xcf7ebca8,12,0xe755f07f323e9b25)
  63699 logger   RET   kbind 0
  63699 logger   CALL  sendsyslog(0xcf7ec807,23,0<>)
  63699 logger   RET   sendsyslog -1 errno 57 Socket is not connected
  63699 logger   CALL  kbind(0xcf7eec08,12,0xe755f07f323e9b25)
  63699 logger   RET   kbind 0
  63699 logger   CALL mprotect(0x7cc4e000,0x1000,0x3<PROT_READ|PROT_WRITE>)
  63699 logger   RET   mprotect 0
  63699 logger   CALL mprotect(0x7cc4e000,0x1000,0x1)
  63699 logger   RET   mprotect 0
  63699 logger   CALL mprotect(0x7cc4e000,0x1000,0x3<PROT_READ|PROT_WRITE>)
  63699 logger   RET   mprotect 0
  63699 logger   CALL mprotect(0x7cc4e000,0x1000,0x1)
  63699 logger   RET   mprotect 0
  63699 logger   CALL  munmap(0x7cc4e000,0x1000)
  63699 logger   RET   munmap 0
  63699 logger   CALL  exit(0)

Highlighting the appropriate part:
  63699 logger   CALL kbind(0xcf7ebca8,12,0xe755f07f323e9b25)
  63699 logger   RET   kbind 0
  63699 logger   CALL  sendsyslog(0xcf7ec807,23,0<>)
  63699 logger   RET   sendsyslog -1 errno 57 Socket is not connected
  63699 logger   CALL  kbind(0xcf7eec08,12,0xe755f07f323e9b25)
  63699 logger   RET   kbind 0 63699 logger   CALL 
mprotect(0x7cc4e000,0x1000,0x3<PROT_READ|PROT_WRITE>)

How long has this firewall been up?

jross@fw:/home/jross $ uptime
  4:31PM  up 34 mins, 1 user, load averages: 1.34, 1.28, 1.12


So, how do I re-connect the sendsyslogsocket?

dmesg follows

Jeff Ross

ross@fw:/home/jross $ dmesg
OpenBSD 6.0-beta (GENERIC.MP) #1768: Wed May 18 12:01:43 MDT 2016
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz ("GenuineIntel" 686-class) 
1.84 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,S

Re: syslog on 5.6

Thank you, Theo.

I know this is true.  I was tempted to jump right to 5.9 but decided to
heed the directions on

http://www.openbsd.org/faq/upgrade56.html

"

*Note: Upgrades are only supported from one release to the release
immediately following it. Do not skip releases. If you got lucky skipping
releases in the past, you may not this time."*


On Wed, May 25, 2016 at 1:39 PM, Theo de Raadt <dera...@cvs.openbsd.org>
wrote:

> We only "support" the last release, and we only make errata available
> for the last two releases.  We don't maintain old code because none of
> us run it.
>
> 5.6 is end-of-life, so you are on your own.
>
> > So far I haven't been able to get syslog to log anything other than it's
> > startup message.
> >
> > I'm using the stock syslog.conf file.
> >
> > logger test message does nothing so I ktraced it.
> >
> > The interesting part is:
> >
> > 22461 logger   RET   sigprocmask ~0x10100<SIGKILL|SIGSTOP>
> >  22461 logger   CALL  sendsyslog(0xcfbda6a8,0x27)
> >  22461 logger   RET   sendsyslog -1 errno 57 Socket is not connected
> >  22461 logger   CALL  sigprocmask(SIG_BLOCK,~0<>)
> >  22461 logger   RET   sigprocmask 0<>
> >  22461 logger   CALL
> mprotect(0x39cd6000,0x1000,0x3<PROT_READ|PROT_WRITE>)
> >
> > So how would I re-connect sendsyslog?
> >
> > Rebooted a couple of times after upgrading to 5.6--I'll be glad to get
> past
> > all of these hurdles so I can get up to 5.9!
> >
> > Thanks,
> >
> > Jeff Ross

syslog on 5.6

So far I haven't been able to get syslog to log anything other than it's
startup message.

I'm using the stock syslog.conf file.

logger test message does nothing so I ktraced it.

The interesting part is:

22461 logger   RET   sigprocmask ~0x10100<SIGKILL|SIGSTOP>
 22461 logger   CALL  sendsyslog(0xcfbda6a8,0x27)
 22461 logger   RET   sendsyslog -1 errno 57 Socket is not connected
 22461 logger   CALL  sigprocmask(SIG_BLOCK,~0<>)
 22461 logger   RET   sigprocmask 0<>
 22461 logger   CALL  mprotect(0x39cd6000,0x1000,0x3<PROT_READ|PROT_WRITE>)

So how would I re-connect sendsyslog?

Rebooted a couple of times after upgrading to 5.6--I'll be glad to get past
all of these hurdles so I can get up to 5.9!

Thanks,

Jeff Ross

pf sanity check

Hi all,

I am incrementally bringing my server up to date.  I was on 5.5-current so
following the instructions I upgraded to 5.6 stable.

I re-wrote  my pf.conf to remove the oldqueue rules and to simplify the
rule set.

Checks okay for syntax but it doesn't seem to be redirecting mail to
spamd.  If I telnet to my server on port 25 I do not see the stutter of the
banner at all.

Here's my current pf.conf for other eyes--maybe I've made a thinko in these
new ruless

# $OpenBSD: pf.conf,v 1.49 2009/09/17 06:39:03 jmc Exp $
#
# See pf.conf(5) for syntax and examples.
# Remember to set net.inet.ip.forwarding=1 and/or net.inet6.ip6.forwarding=1
# in /etc/sysctl.conf if packets are to be forwarded between interfaces.
ext_if="re0"  # External Public Interface
tcp_services = "{ 22,53,113,25,993,465,80,443 }"
udp_services = "{ domain, ntp, 1194 }"
icmp_types = "{ echoreq, unreach }"
table  persist
table  persist
set block-policy return
set loginterface $ext_if
set skip on { lo, tun }
match on $ext_if inet all scrub (no-df max-mss 1398)

# filter rules and anchor for ftp-proxy(8)
anchor "ftp-proxy/*"
pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021

# anchor for relayd(8)
block log all
block in log quick proto tcp from  to any
# rules for spamd(8)
table  persist
table  persist file "/etc/mail/nospamd"
pass in log on egress proto tcp from any to any port smtp \
rdr-to 127.0.0.1 port spamd
pass in log on egress proto tcp from  to any port smtp
pass in log on egress proto tcp from  to any port smtp
pass out log on egress proto tcp to any port smtp

pass in log quick on egress proto tcp to port $tcp_services
pass in log quick on egress proto udp to port $udp_services
pass out log quick on egress from any to any

Thanks!

Jeff Ross

Re: apache-httpd-openbsd?


On 5/9/16 4:26 PM, Daniel Jakots wrote:


On Mon, 9 May 2016 15:03:30 -0600, Jeff Ross <jr...@openvistas.net>
wrote:


Trying to install apache-httpd-openbsd in -current

https://marc.info/?l=openbsd-ports-cvs=146186762111571=2

Hmm--I went through all of the ports@ messages looking for a removal 
announcement but didn't find one.


Thank you, Daniel!

Jeff

Re: apache-httpd-openbsd?


On 5/9/16 4:25 PM, Fred wrote:


On 05/09/16 22:58, Jeff Ross wrote:

On 5/9/16 3:21 PM, arrowscr...@mail.com wrote:


try pkg_add
http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/apache-httpd-2.4.20p1.tgz 





That's apache 2.4, I want the 1.3.9 version that is, as my subject line
says, apache-httpd-openbsd.

Jeff



It was removed 11 days ago:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/apache-httpd-openbsd/Attic/Makefile 



You'll need a cvs version before 28 Apr 16 if you want to build it 
yourself.


Cheers

Fred


Thanks, Fred!  That explains the missing package!

Jeff

Re: apache-httpd-openbsd?


On 5/9/16 4:30 PM, Stuart Henderson wrote:


On 2016-05-09, Jeff Ross <jr...@openvistas.net> wrote:

Trying to install apache-httpd-openbsd in -current and it seems the
package is no longer available.

Correct.

Options:

- (preferred) migrate your configuration to a maintained http
server version.


I need mod_rewrite so I guess I'm headed for apache2.

- install 5.9 release.

- checkout an old version of the port (mkdir -p
/usr/ports/mystuff/www; cd /usr/ports/mystuff/www; cvs get -D \
2016/04/01 -d apache-httpd-openbsd ports/www/apache-httpd-openbsd)
and build it yourself; things will break again at some point though.


I cvs uped my src and ports and built
the system from source but when I try to install apache-httpd-openbsd
from ports I'm getting the "reading plist|Error: unknown fragment SHARED
at /usr/libdata/perl5/OpenBSD/Subst.pm line 109, <$fh> line 2." error.

that's not unexpected; the PFRAG.shared complexity has been removed
from ports now that vax is no longer a supported arch.

Okay--I think this must be above my pay grade because I can't see how 
vax is related, nor do I think I need to know ;-)


Thank you, Stuart, as always!

Jeff

Re: apache-httpd-openbsd?


On 5/9/16 3:21 PM, arrowscr...@mail.com wrote:


try pkg_add 
http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/apache-httpd-2.4.20p1.tgz

That's apache 2.4, I want the 1.3.9 version that is, as my subject line 
says, apache-httpd-openbsd.


Jeff

apache-httpd-openbsd?