Re: autoinstall with local file

[Ed Ahlsen-Girard]

On Fri, 13 Jan 2017 12:01:36 -0700
"Theo de Raadt"  wrote:

>  [...]  
> 
> That is yet another example of interactive use, of an installer
> feature designed for NON-INTERACTIVE USE.
> 
> I feel like we're being pushed to support a set of use cases which
> are not core functionality.
> 
> The installer will keep improving in various ways, but these narrow
> use cases will be first up against the wall (due to being ignored
> during development, they'll be fragile due to subtle changes).
> 
> It's a complicated shell script.  It doesn't deliver pizza, either.
>  

That's fine, I misunderstood, and I am not pushing for an extension. At
all.

-- 

Edward Ahlsen-Girard
Ft Walton Beach, FL

Re: autoinstall with local file

[Ed Ahlsen-Girard]

On Fri, 13 Jan 2017 18:06:35 +
Robert Peichaer  wrote:

> On Fri, Jan 13, 2017 at 06:20:25AM -0600, Ed Ahlsen-Girard wrote:
>  [...]  
> 
> The installer looks at the filesystem provided by bsd.rd itself, not
> the filesystem on disk.
> 

Thanks.

-- 

Edward Ahlsen-Girard
Ft Walton Beach, FL

Vultr support for OpenBSD

[Troy Frericks]

Vultr now has direct support for #*OpenBSD*
. Launch your OpenBSD
environment easily from our deploy panel at http://Vultr.com
 ! #*Cloud*


https://twitter.com/Vultr

Re: Small Business email server using OpenSMTPD

[Mark Carroll]

On 13 Jan 2017, aretes wrote:

> I'm trying to move a small business email server from an older OpenBSD using
> sendmail to one with OpenBSD 6.0 using OpenSMTPD.
>
> The current email server has:
> - a certificate (used by StartTLS)

You can use openssl to set up keys and put pki directives into
smtpd.conf.

> - MS Outlook clients using pop3 to retrieve their mail

I use dovecot for this kind of thing. Pay especial attention to its
10-auth.conf and 10-ssl.conf.

> - OpenWebmail for non-local client access

Never tried it.

> I've not found the correct search results to show to how to do this. What I'd
> really like to find is an example "smtpd.conf" showing the required entries.
>
> Can anyone point me in the correct direction?

Don't first rely on search results, take a *good* look through the
manpages and example configuration files provided in the base system,
they're pretty great. If you have any questions after reading them
then read them again and search for the specific issue in this list's
archives. Good luck!

-- Mark

Re: Small Business email server using OpenSMTPD

[Vijay Sankar]

  Quoting aretes27...@mypacks.net:

> I'm trying to move a small business email server from an older OpenBSD
> using sendmail to one with OpenBSD 6.0 using OpenSMTPD.
>
> The current email server has:
> - a certificate (used by StartTLS)
> - MS Outlook clients using pop3 to retrieve their mail
> - OpenWebmail for non-local client access
>
> I've not found the correct search results to show to how to do this.
> What I'd really like to find is an example "smtpd.conf" showing the
> required entries.
>
> Can anyone point me in the correct direction?
> Thanks, Joe

I am assuming you are looking for just smtpd.conf and not suggestions like
"use dovecot and httpd for pop and webmail".

man page is very informative about the different options. May be all you
need is to just change some of the stanzas below taken from the example
section of 'man 5 smtpd.conf'
-- 
Vijay Sankar, M.Eng., P.Eng.
ForeTell Technologies Limited
vsan...@foretell.ca

Small Business email server using OpenSMTPD

[aretes27884]

I'm trying to move a small business email server from an older OpenBSD using 
sendmail to one with OpenBSD 6.0 using OpenSMTPD.

The current email server has:
- a certificate (used by StartTLS)
- MS Outlook clients using pop3 to retrieve their mail
- OpenWebmail for non-local client access

I've not found the correct search results to show to how to do this. What I'd 
really like to find is an example "smtpd.conf" showing the required entries.

Can anyone point me in the correct direction?

Thanks, Joe

Re: autoinstall with local file

[Raf Czlonka]

On Fri, Jan 13, 2017 at 07:21:12PM GMT, Theo de Raadt wrote:
> > Given that there is no official supported way to put an
> > auto_upgrade.conf onto an existing bsd.rd, what would be a suggested
> > way to achieve the same end result - in this case, an automated
> > non-interactive, off-line upgrade?
> 
> Hack up a solution however you like.
> 
> But understand it isn't within our mandate to keep your hack working.

Sure, I understand that.

> So basically, it will break because it is relying on behaviours which
> are not a mainline requirement.

Yes, I'm prepared to deal with it.

> It will break, like it just did.
> 

Oh, no - it works absolutely fine, had been since day one.
I'm must've not been very clear, sorry.

Cheers,

Raf

Re: autoinstall with local file

[Theo de Raadt]

> Given that there is no official supported way to put an
> auto_upgrade.conf onto an existing bsd.rd, what would be a suggested
> way to achieve the same end result - in this case, an automated
> non-interactive, off-line upgrade?

Hack up a solution however you like.

But understand it isn't within our mandate to keep your hack working.

So basically, it will break because it is relying on behaviours which
are not a mainline requirement.

It will break, like it just did.

Re: autoinstall with local file

[Sebastien Marie]

On Fri, Jan 13, 2017 at 11:14:16AM -0700, Theo de Raadt wrote:
> 
> I would be very surprised to hear that people are using
> vnconfig+mount+vnconfig+mount, to add such a file.

I am still using this (unsupported) method for auto_upgrading all
openbsd hosts I administrate. As all are running -current, it means I
use it very regulary.

> And while doing so
> potentially running low on space issues (it isn't just a matter of
> the file fitting, there must be some slop left over because the
> installer needs a bit of /tmp)

As installer has sane defaults, the config file is generally small (from
84 to 161 bytes in my environment).

But yes, it could interfere with installer. I wouldn't report a bug on
it without be able to reproduce with interactive method.

> Should everything work in every way?  I'm not so sure.  My truck
> still doesn't fly.

autoinstall is a great possibility. But depending the network
environnement, it could be not possible to netboot, and so to trigger
autoinstall not-interactively. Fetching file using DHCP options isn't
the hard part in my context: I would have only one host without control
of the network.

but I didn't ask for making it a "supported" method. I know I use only a
trick.
-- 
Sebastien Marie

Re: autoinstall with local file

[Raf Czlonka]

On Fri, Jan 13, 2017 at 06:14:16PM GMT, Theo de Raadt wrote:
> > On Fri, Jan 13, 2017 at 06:20:25AM -0600, Ed Ahlsen-Girard wrote:
> > > The man page seems to indicate that autoinstall will work with an
> > > auto_upgrade.conf file on the local machine, but specifying the path as:
> > > 
> > > /auto_upgrade.conf
> > > or
> > > file://auto_upgrade.conf
> > > or
> > > file:auto_upgrade.conf
> > > 
> > > do not work.
> > > 
> > > Is this still a "watch this space!" feature?
> > 
> > It does work. However, / is the root of bsd.rd, not the root of the
> > system you want to upgrade (this would have to be guessed and the
> > upgrade script doesn't do guessing without asking for confirmation).
> > It's a bit of a pain to get the file there, and I don't think there's
> > any official documentation. semarie@ wrote some instructions a while
> > back:
> > https://marc.info/?l=openbsd-misc&m=141552533922277&w=2
> > see also:
> > https://marc.info/?l=openbsd-misc&m=146890249418788&w=2
> > where he indicates that there are more posts to be found on misc (but I
> > don't know where).
> 
> I would be very surprised to hear that people are using
> vnconfig+mount+vnconfig+mount, to add such a file.  And while doing so
> potentially running low on space issues (it isn't just a matter of
> the file fitting, there must be some slop left over because the
> installer needs a bit of /tmp)
> 
> Should everything work in every way?  I'm not so sure.  My truck
> still doesn't fly.
> 

OK, so I'll admit that I've been using Sebastien's tip for a couple of
years now but, it seem that, I have been lucky it always worked -
probably due to the fact that my auto_upgrade.conf file is only
three lines long (it was two-line long for a while):

Location of sets = disk
Is the disk partition already mounted = yes
Pathname to the sets = $DIR

Given that there is no official supported way to put an
auto_upgrade.conf onto an existing bsd.rd, what would be a suggested
way to achieve the same end result - in this case, an automated
non-interactive, off-line upgrade?

Cheers,

Raf

Re: autoinstall with local file

[Theo de Raadt]

> On my actual disk at / I have auto_upgrade.conf and when I start the
> upgrade process at boot, I press s.
> This will allow me to mount /dev/wd0a mnt; cp mnt/auto_upgrade .; autoinstall

That is yet another example of interactive use, of an installer
feature designed for NON-INTERACTIVE USE.

I feel like we're being pushed to support a set of use cases which
are not core functionality.

The installer will keep improving in various ways, but these narrow
use cases will be first up against the wall (due to being ignored
during development, they'll be fragile due to subtle changes).

It's a complicated shell script.  It doesn't deliver pizza, either.

Re: Unable to boot encrypted drive

[Timo Myyrä]

Joel Sing  writes:

> On Friday 06 January 2017 15:23:32 Timo Myyrä wrote:
>
>> Here's the output of installboot on running system:
>> $ doas installboot -v sd1
>> Using / as root
>> installing bootstrap on /dev/rsd1c
>> using first-stage /usr/mdec/biosboot, second-stage /usr/mdec/boot
>> sd1: softraid volume with 1 disk(s)
>> sd1: installing boot loader on softraid volume
>> /usr/mdec/boot is 6 blocks x 16384 bytes
>> sd0a: installing boot blocks on /dev/rsd0c, part offset 1104
>> master boot record (MBR) at sector 0
>> partition 0: type 0xEF offset 64 size 960
>> partition 3: type 0xA6 offset 1024 size 1000205876
>> /usr/mdec/biosboot will be written at sector 1024
>>
>> and heres from bsd.rd shell:
>> Using /mnt as root
>> installing bootstrap on /dev/rsd1c
>> using first-stage /mnt/usr/mdec/biosboot, second-stage /mnt/usr/mdec/boot
>> sd1: softraid volume with 1 disk(s)
>> sd1: installing boot loader on softraid volume
>> /mnt/usr/mdec/boot is 6 blocks x 16384 bytes
>> sd0a: installing boot blocks on /dev/rsd0c, part offset 1104
>> master boot record (MBR) at sector 0
>>  partition 0: type 0xEF offset 64 size 960
>>  partition 3: type 0xA6 offset 1024 size 1000205876
>> /mnt/usr/mdec/biosboot will be written at sector 1024
>>
>> Looking at the output it seems to just copy the regular boot files and
> skips
>> processing EFI stuff. And as the system boots with EFI it uses the old
>> bootloader and hence the problems with opening the crypto volume.
>
> Correct - it is installing the MBR/PBR boot block and boot loader, rather
than
> the EFI one.
>
>> Should there be check to see if the booted device has i partition with efi
>> folder and copy the EFI bootloader in that case?
>
> The code in question is the findgptefisys() function in
> src/usr.sbin/installboot/i386_installboot.c. It is likely that there is
> something up with your disk configuration (missing protective MBR,
incorrect
> GPT header, incorrect GPT signature, corrupt checksum, etc) that is making
it
> think that this is an MBR system, rather than a GPT one. That said, it is
also
> possible that it is a bug/corner case...
>
> If you're able to sprinkle some printf's through that function and
determine
> what check is failing, it would help narrow down the issue. You probably
also
> want to check the MBR and GPT to see what is actually on the disk.
>

Yeah, printfs and (also running fdisk) showed that I was missing the
protective
MBR. Shortly after I also learned that this is not fixed by running "fdisk -ig
sd0"
on a running system... At least I did backups before running it.
After reinstalling  I don't have the issue anymore.

Timo

Re: autoinstall with local file

[Theo de Raadt]

> The original idea of this was to allow ...
> 
>Welcome to the OpenBSD/amd64 6.0 installation program.
>(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? s
># cat <<_EOF >/auto_install.conf
>> system hostname = hostA
>> password for root = whateversecurepassword
>> http server = ftp.hostserver.de
>> _EOF
># exit
>erase ^?, werase ^W, kill ^U, intr ^C, status ^T
>
>Welcome to the OpenBSD/amd64 6.0 installation program.
>(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? a

That strikes me as a little silly, and I wonder how many people
will decide to do that.

Why create a file to answer the prompts *interactively*, in lieu of
simply hitting return and answering the questions a moment later.

The key point here is the example is interactive.

> If the system had internet access during installation, it's even enough
> to create an empty /auto_upgrade.conf, because the last used mirror will
> be used automatically.
> 
>Welcome to the OpenBSD/amd64 6.0 installation program.
>(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? s
># >/auto_upgrade.conf
># exit
>erase ^?, werase ^W, kill ^U, intr ^C, status ^T
>
>Welcome to the OpenBSD/amd64 6.0 installation program.
>(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? a

Another example of interactive use.

Re: autoinstall with local file

[jungle Boogie]

On 13 January 2017 at 04:20, Ed Ahlsen-Girard  wrote:
> The man page seems to indicate that autoinstall will work with an
> auto_upgrade.conf file on the local machine, but specifying the path as:
>
> /auto_upgrade.conf
> or
> file://auto_upgrade.conf
> or
> file:auto_upgrade.conf
>
> do not work.
>
> Is this still a "watch this space!" feature?
>

On my actual disk at / I have auto_upgrade.conf and when I start the
upgrade process at boot, I press s.
This will allow me to mount /dev/wd0a mnt; cp mnt/auto_upgrade .; autoinstall



> --
>
> Edward Ahlsen-Girard
> Ft Walton Beach, FL
>



-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info

Re: autoinstall with local file

[Robert Peichaer]

On Fri, Jan 13, 2017 at 11:14:16AM -0700, Theo de Raadt wrote:
> > On Fri, Jan 13, 2017 at 06:20:25AM -0600, Ed Ahlsen-Girard wrote:
> > > The man page seems to indicate that autoinstall will work with an
> > > auto_upgrade.conf file on the local machine, but specifying the path as:
> > > 
> > > /auto_upgrade.conf
> > > or
> > > file://auto_upgrade.conf
> > > or
> > > file:auto_upgrade.conf
> > > 
> > > do not work.
> > > 
> > > Is this still a "watch this space!" feature?
> > 
> > It does work. However, / is the root of bsd.rd, not the root of the
> > system you want to upgrade (this would have to be guessed and the
> > upgrade script doesn't do guessing without asking for confirmation).
> > It's a bit of a pain to get the file there, and I don't think there's
> > any official documentation. semarie@ wrote some instructions a while
> > back:
> > https://marc.info/?l=openbsd-misc&m=141552533922277&w=2
> > see also:
> > https://marc.info/?l=openbsd-misc&m=146890249418788&w=2
> > where he indicates that there are more posts to be found on misc (but I
> > don't know where).
> 
> I would be very surprised to hear that people are using
> vnconfig+mount+vnconfig+mount, to add such a file.  And while doing so
> potentially running low on space issues (it isn't just a matter of
> the file fitting, there must be some slop left over because the
> installer needs a bit of /tmp)
> 
> Should everything work in every way?  I'm not so sure.  My truck
> still doesn't fly.

The original idea of this was to allow ...

   Welcome to the OpenBSD/amd64 6.0 installation program.
   (I)nstall, (U)pgrade, (A)utoinstall or (S)hell? s
   # cat <<_EOF >/auto_install.conf
   > system hostname = hostA
   > password for root = whateversecurepassword
   > http server = ftp.hostserver.de
   > _EOF
   # exit
   erase ^?, werase ^W, kill ^U, intr ^C, status ^T
   
   Welcome to the OpenBSD/amd64 6.0 installation program.
   (I)nstall, (U)pgrade, (A)utoinstall or (S)hell? a


If the system had internet access during installation, it's even enough
to create an empty /auto_upgrade.conf, because the last used mirror will
be used automatically.

   Welcome to the OpenBSD/amd64 6.0 installation program.
   (I)nstall, (U)pgrade, (A)utoinstall or (S)hell? s
   # >/auto_upgrade.conf
   # exit
   erase ^?, werase ^W, kill ^U, intr ^C, status ^T
   
   Welcome to the OpenBSD/amd64 6.0 installation program.
   (I)nstall, (U)pgrade, (A)utoinstall or (S)hell? a


-- 
-=[rpe]=-

Re: autoinstall with local file

[Theo de Raadt]

> On Fri, Jan 13, 2017 at 06:20:25AM -0600, Ed Ahlsen-Girard wrote:
> > The man page seems to indicate that autoinstall will work with an
> > auto_upgrade.conf file on the local machine, but specifying the path as:
> > 
> > /auto_upgrade.conf
> > or
> > file://auto_upgrade.conf
> > or
> > file:auto_upgrade.conf
> > 
> > do not work.
> > 
> > Is this still a "watch this space!" feature?
> 
> It does work. However, / is the root of bsd.rd, not the root of the
> system you want to upgrade (this would have to be guessed and the
> upgrade script doesn't do guessing without asking for confirmation).
> It's a bit of a pain to get the file there, and I don't think there's
> any official documentation. semarie@ wrote some instructions a while
> back:
> https://marc.info/?l=openbsd-misc&m=141552533922277&w=2
> see also:
> https://marc.info/?l=openbsd-misc&m=146890249418788&w=2
> where he indicates that there are more posts to be found on misc (but I
> don't know where).

I would be very surprised to hear that people are using
vnconfig+mount+vnconfig+mount, to add such a file.  And while doing so
potentially running low on space issues (it isn't just a matter of
the file fitting, there must be some slop left over because the
installer needs a bit of /tmp)

Should everything work in every way?  I'm not so sure.  My truck
still doesn't fly.

Re: autoinstall with local file

[Theo Buehler]

On Fri, Jan 13, 2017 at 06:20:25AM -0600, Ed Ahlsen-Girard wrote:
> The man page seems to indicate that autoinstall will work with an
> auto_upgrade.conf file on the local machine, but specifying the path as:
> 
> /auto_upgrade.conf
> or
> file://auto_upgrade.conf
> or
> file:auto_upgrade.conf
> 
> do not work.
> 
> Is this still a "watch this space!" feature?

It does work. However, / is the root of bsd.rd, not the root of the
system you want to upgrade (this would have to be guessed and the
upgrade script doesn't do guessing without asking for confirmation).
It's a bit of a pain to get the file there, and I don't think there's
any official documentation. semarie@ wrote some instructions a while
back:
https://marc.info/?l=openbsd-misc&m=141552533922277&w=2
see also:
https://marc.info/?l=openbsd-misc&m=146890249418788&w=2
where he indicates that there are more posts to be found on misc (but I
don't know where).

Re: autoinstall with local file

[Robert Peichaer]

On Fri, Jan 13, 2017 at 06:20:25AM -0600, Ed Ahlsen-Girard wrote:
> The man page seems to indicate that autoinstall will work with an
> auto_upgrade.conf file on the local machine, but specifying the path as:
> 
> /auto_upgrade.conf
> or
> file://auto_upgrade.conf
> or
> file:auto_upgrade.conf
> 
> do not work.
> 
> Is this still a "watch this space!" feature?
> 
> -- 
> 
> Edward Ahlsen-Girard
> Ft Walton Beach, FL
> 

The installer looks at the filesystem provided by bsd.rd itself, not the 
filesystem on
disk.

-- 
-=[rpe]=-

autoinstall with local file

[Ed Ahlsen-Girard]

The man page seems to indicate that autoinstall will work with an
auto_upgrade.conf file on the local machine, but specifying the path as:

/auto_upgrade.conf
or
file://auto_upgrade.conf
or
file:auto_upgrade.conf

do not work.

Is this still a "watch this space!" feature?

-- 

Edward Ahlsen-Girard
Ft Walton Beach, FL

radicale and httpd

[Jan Lambertz]

Hi,

having Problems for some time now with the webserver in python2/3 and
radicale, i tried to get it working with httpd.

installed flup. python is working in the chroot.

here's my work so far but i'm not getting any further. anyone got this
working ?

Jan

# cat /etc/httpd.conf
server "default" {
listen on * tls port 5233
#   authenticate with "/radicale/htpasswd"

location "*radicale.fcgi" {
fastcgi socket "/radicale/run/radicalefcgi.sock"
root "/radicale/cgi-bin"
}

tcp {
nodelay
}


tls {
certificate "/etc/radicale/server.crt"
key "/etc/radicale/private/server.key"
}
}




slowcgi -d -p /var/www/ -s /var/www/radicale/run/radicalefcgi.sock


# cat /var/www/radicale/cgi-bin/radicale.fcgi
#!/usr/local/bin/python
try:
from flup.server.fcgi import WSGIServer
except ImportError:
from flipflop import WSGIServer
import radicale
radicale.log.start()
radicale.log.LOGGER.info("Starting Radicale FastCGI server")
WSGIServer(radicale.Application()).run()
radicale.log.LOGGER.info("Stopping Radicale FastCGI server")



/var/www/log/error.log says

Traceback (most recent call last):
  File "/radicale/cgi-bin/radicale.fcgi", line 9, in 
WSGIServer(radicale.Application()).run()
  File "/usr/local/lib/python2.7/site-packages/flup/server/fcgi.py",
line 113, in run
ret = ThreadedServer.run(self, sock)
  File "/usr/local/lib/python2.7/site-
packages/flup/server/threadedserver.py", line 84, in run
clientSock, addr = sock.accept()
socket
.
error   
:
[Errno 22] Invalid argument




chroot -g daemon -u www /var/www/ /usr/local/bin/python /radicale/cgi-
bin/radicale.fcgi

says 

Status: 200 OK
Content-Length: 54
Content-type: text/html


RadicaleRadicale works!#





slowcgi says 

slowcgi: socket: /var/www/radicale/run/radicalefcgi.sock
slowcgi: slowcgi_user: www  
slowcgi: chroot: /var/www/  
slowcgi: inflight incremented, now 1
slowcgi: version: 1 
slowcgi: type:1  
slowcgi: requestId:   1 
slowcgi: contentLength:   8   
slowcgi: paddingLength:   0 
slowcgi: reserved:0 
slowcgi: role 1 
slowcgi: flags0 
slowcgi: version: 1 
slowcgi: type:4 
slowcgi: requestId:   1 
slowcgi: contentLength:   448  
slowcgi: paddingLength:   0 
slowcgi: reserved:0
slowcgi: env[0], PATH_INFO= 
slowcgi: env[1], SCRIPT_NAME=/radicale.fcgi
slowcgi: env[2], SCRIPT_FILENAME=/radicale/cgi-bin/radicale.fcgi
slowcgi: env[3], QUERY_STRING=  
slowcgi: env[4], DOCUMENT_ROOT=/radicale/cgi-bin
slowcgi: env[5],
DOCUMENT_URI=/radicale.fcgi
slowcgi: env[6], GATEWAY_INTERFACE=CGI/1.1
slowcgi: env[7], HTTP_HOST=127.0.0.1:5233  
slowcgi: env[8], HTTP_USER_AGENT=OpenBSD ftp   
slowcgi: env[9], HTTPS=on  
slowcgi: env[10], REMOTE_ADDR=127.0.0.1
slowcgi: env[11], REMOTE_PORT=22318
slowcgi: env[12], REQUEST_METHOD=GET
slowcgi: env[13], REQUEST_URI=/radicale.fcgi
slowcgi: env[14], SERVER_ADDR=127.0.0.1
slowcgi: env[15], SERVER_PORT=5233 
slowcgi: env[16], SERVER_NAME=default
slowcgi: env[17], SERVER_PROTOCOL=HTTP/1.0  
slowcgi: env[18], SERVER_SOFTWARE=OpenBSD httpd 
slowcgi: version: 1 
slowcgi: type:4 
slowcgi: requestId:   1 
slowcgi: contentLength:   0 
slowcgi: paddingLength:   0  
slowcgi: reserved:0 
slowcgi: fork: /radicale/cgi-bin/radicale.fcgi
slowcgi: version: 1 
slowcgi: type:5 
slowcgi: requestId:   1 
slowcgi: contentLength:   0 
slowcgi: paddingLength:   0 
slowcgi: reserved:0 
slowcgi: resp version: 1
slowcgi: resp type:7   
slowcgi: resp requestId:   1
slowcgi: resp contentLength:   35
slowcgi: resp paddingLength:   5
slowcgi: resp reserved:0   
slowcgi: resp version: 1
slowcgi: resp type:7
slowcgi: resp requestId:   1
slowcgi: resp
contentLength:   62
  
slowcgi: resp paddingLength:   2  
slowcgi: resp reserved:0   
slowcgi: resp version: 1   
slowcgi: resp type:7   
slowcgi: resp requestId:   1   
slowcgi: resp contentLength:   4   
slowcgi: resp paddingLength:   4
slowcgi: resp reserved:0
slowcgi: resp version: 1   
slowcgi: resp type:7   
slowcgi: resp requestId:   1 
slowcgi: resp contentLength:   41  

Re: openiked and PAM or RADIUS

[Stuart Henderson]

On 2017-01-13, Piotr Soróbka  wrote:
> Hi,
> can openiked send EAP requests to a PAM module or directly to RADIUS server?

In a word: no.

OpenBSD doesn't use PAM at all, and the only EAP method implemented
in iked is MSCHAPv2 using a local database of passwords (as the server
needs access to the plaintext for MSCHAPv2, these must be stored in
the clear). It doesn't talk to radius.

npppd (used for IKEv1+L2TP) *can* talk to radius for PAP/CHAP, there
is also some code in the source tree for EAP but this is hidden behind
a #define which is not enabled on OpenBSD, I'm not sure what would be
needed in order to use that.

openiked and PAM or RADIUS

[Piotr Soróbka]

Hi,
can openiked send EAP requests to a PAM module or directly to RADIUS server?

Re: OpenBGPd - Multi-home ISP : DDoS Protection

[Peter Hessler]

On 2017 Jan 12 (Thu) at 11:18:58 +0100 (+0100), Uday MOORJANI wrote:
:Dear OpenBSD-Misc,
:
:First of all, awesome work on the OpenBGPd and BFD code. I'm working on a
:WAN setup for an enterprise and we are migrating from static route WAN to a
:full fledge BGP transit in a multi home environment for the specific
:purpose of providing the best possible path/route to our service catalogue.
:The service catalogue within the enterprise is orchestrated by a private
:vmware cloud with added software defined networking (micro-segmentation)
:capabilities within the private cloud via NSX.
:
:My concern is about DDoS protection from the ingress traffic, in my logic
:it makes no sense to contract a service such as Imperva or Cloudflare as
:DDoS protection on the network level, as  proper PF (firewall) rules in
:place should protect us at line rate. My doubts are:
:

There are basically two types of DDoS seen in the wild.

The first type is "overload the pipes".  Lots of massive packets, 50Gbps
and larger, etc, etc.  This is the kind that hits the news.  By
definition, you cannot defend against this on-site.

The other type is "overload the application".  Small packets, usually.
Something that is "too small" to be detected by your anti-DDoS
mechanisms, but is painful for the end application.  A common method is
SYNs without ACKs, overloading the sockets or state table on a web
server.

OpenBSD cannot help with the first type, as the pipes to the OpenBSD
system are already full.

OpenBSD *can* help with the second type, depending on how many pps the
system can handle.  If the OpenBSD machine can protect at the line rates
needed, then you can set up rules that protect.

For upsream DDoS protection, there are also two types.  Block.  Scrub.
Blocking is usually included in your transit provider and is pretty
limited.  You announce the victim IP with a blackhole community, and
your upstream provider blocks traffic to that destination at their edge.
Depending on your provider, this can be granular to the Country or
Region you are in; or even to specific Protocol/Port combinations.

Scrubbing services will take all of the traffic, use $$$ magic to figure
out what is safe and what isn't, charge you, then send the "clean"
traffic to the original destination.


:- Are the rules provided for anti-ddos sufficient? Is there a good soul to
:share some rulesets?
:- Am I out of my mind for choosing OpenBGPd/OpenBSD for my transit WAN? I
:love the fact that we're sandboxed and hyperthreaded and am particularly
:content with the resolution of convergence time problems (
:http://undeadly.org/cgi?action=article&sid=20151106171337&mode=expanded)

At work we use OpenBSD/OpenBGPd on most of our edge routers, and are
very happy with them.  They perform well enough for our traffic
requirements.

:- Is there a way to contract a support in case sh*t hits the fan with

Yes, there are several listed at http://www.openbsd.org/support.html.
The company I work for also has support available.


:OpenBGPd?
:- What are the best tools to supervise and test bed the performance of an
:OpenBGPd instance? (most the definately the dumbest question)
:

This is surprisingly complicated.  There are lots of potential things to
test performance.  Most likely the one you care about is how many
packets-per-second the router can handle, and for that you just need a
packet blasting system.  There are commercial entities and there are
free software tools.  For testing BGP itself, I use either self-written
scripts using exabgp/bird, or live internet traffic by updating one of
our edge routers.


:Again, love the fact I can get some sleep with OpenBSD/OpenBGPd, please do
:get back to me for commercial support to calm the nerves.
:
:Sincerely,
:
:Uday MOORJANI
:

-- 
There are no games on this system.

Re: IPv6 OSPF

[z3rgl1ngz]

Not sure how I missed that.
Thank you :)


> On 13 Jan 2017, at 14:10, Peter Hessler  wrote:
>
> On 2017 Jan 13 (Fri) at 13:48:13 +0200 (+0200), Claudiu Popescu wrote:
> :Hi,
> :
> :First of all, hopefully I managed to send this email to the correct list
:)
> :I am pretty new to OpenBSD but so far I managed to get everything
> :working for a router without IPv6 OSPF.
> :I have ospfd and ospf6d running but I did not figure out how to check
> :against ospf6d with ospfctl.
> :I tried:
> :# ospfctl -s /var/run/ospf6d.sock show neighbor
> :ID  Pri StateDeadTime Address Iface Uptime
> :
>
> That won't work, you need to use "ospf6ctl show neighbor".
>
>
> --
> An American's a person who isn't afraid to criticize the President but
> is always polite to traffic cops.

Re: IPv6 OSPF

[Peter Hessler]

On 2017 Jan 13 (Fri) at 13:48:13 +0200 (+0200), Claudiu Popescu wrote:
:Hi,
:
:First of all, hopefully I managed to send this email to the correct list :)
:I am pretty new to OpenBSD but so far I managed to get everything
:working for a router without IPv6 OSPF.
:I have ospfd and ospf6d running but I did not figure out how to check
:against ospf6d with ospfctl.
:I tried:
:# ospfctl -s /var/run/ospf6d.sock show neighbor
:ID  Pri StateDeadTime Address Iface Uptime
:

That won't work, you need to use "ospf6ctl show neighbor". 


-- 
An American's a person who isn't afraid to criticize the President but
is always polite to traffic cops.

IPv6 OSPF

[Claudiu Popescu]

Hi,

First of all, hopefully I managed to send this email to the correct list :)
I am pretty new to OpenBSD but so far I managed to get everything
working for a router without IPv6 OSPF.
I have ospfd and ospf6d running but I did not figure out how to check
against ospf6d with ospfctl.
I tried:
# ospfctl -s /var/run/ospf6d.sock show neighbor
ID  Pri StateDeadTime Address Iface Uptime

But all I get is that line and after it waits and no more output. So
the command does not return, gets stuck. I am able to cancel with ctrl
+ c though.
When issuing the command against ospfd.sock it works just fine.
Thing is that I see the neighbor connected through OSPF on my other routers.
And when starting it with: ospf6d -vd -f /etc/ospf6d.conf, the service
runs fine and I see from output that it looks ok. Nothing strange..

Maybe I am trying to access it wrong with ospfctl?
Not sure where to go from here so any suggestion would be of great help.

Thank you.