Re: em0: couldn't map interrupt (No support for my Intel NIC?)

[Farid Joubbi]

NetBSD does not work either.
I get the exact same error as with OpenBSD.

CentOS works fine.

On Thu, Jul 5, 2018 at 10:20 PM Farid Joubbi  wrote:

> I am running several virtual machines on top of bhyve. I've got FreeBSD,
> RHEL, Linux Mint and Debian running now.
> I have tried OpenBSD without a passthrough NIC and CentOS.
>
>
> On Thu, Jul 5, 2018, 20:14 Tom Smyth  wrote:
>
>> Farid
>> Can you check if the SR-IOV works by runing another OS  as a vm on top of
>> Bhyve on the host
>>
>> that is what I meant on my previous mail
>> Thanks
>>
>> On 5 July 2018 at 17:49, Farid Joubbi  wrote:
>> > Hi,
>> > The Intel NIC works correctly in the native FreeBSD. I used it there
>> before
>> > I did the passthrough.
>> > The Intel NIC worked correctly natively when I tested the OpenBSD
>> installer.
>> > The Intel NIC works in bhyve if I install FreeBSD.
>> >
>> > The new Broadcom NIC also works normally as long as it's not a OpenBSD
>> > instance in bhyve.
>> >
>> > The NICs are not assigned to other hosts.
>> >
>> > The settings for virtualization on the hardware are correct to my
>> knowledge.
>> > I have several other hosts running in bhyve  without problems.
>> > One FreeBSD host using passthrough the same way as I intend to do with
>> > OpenBSD.
>> >
>> >
>> > On Thu, Jul 5, 2018 at 4:55 PM Tom Smyth 
>> > wrote:
>> >>
>> >> Hello Farid,
>> >>
>> >>
>> >> Can you confirm that other operating systems pick up the Nic ok and
>> >> they function ok
>> >>
>> >> has the Physical Host settings been setup correctly for SR-IOV
>> >>
>> >> is it possible that the nic has been assigned to another vm ?
>> >>
>> >> Hope this helps
>> >>
>> >>
>> >> On 5 July 2018 at 15:38, Farid Joubbi  wrote:
>> >> > I realize now that I wrote a reply to only Mike and not the whole
>> misc
>> >> > earlier.
>> >> >
>> >> > Anyway.
>> >> > The server is running several functions, and it's not popular to do
>> >> > maintenance on it.
>> >> > I went ahead and rebooted it anyway since this is important ;-)
>> >> >
>> >> > I booted the OpenBSD 6.3 install media natively on the hardware.
>> >> > It found all six NICs that I have installed. There are two Broadcom
>> on
>> >> > the
>> >> > mainboard and four on the Intel card.
>> >> > Broadcoms were found as bge and Intel as em. They all seemed to work.
>> >> >
>> >> > I had an extra bge card lying around. I installed it in the server
>> and
>> >> > did
>> >> > PCI passthrough with it as well as the Intel in FreeBSD/bhyve.
>> >> > I get the same result in OpenBSD:
>> >> > bge0 at pci0 dev 5 function 0 "Broadcom BCM5720" rev 0x00, BCM5720 A0
>> >> > (0x572), APE firmware NCSI 1.4.12.0: couldn't map interrupt
>> >> >
>> >> > Conclusion:
>> >> > The problem has to do with the fact that bhyve is between the
>> hardware
>> >> > and
>> >> > OpenBSD.
>> >> >
>> >> > Any ideas?
>> >> >
>> >> > On Thu, Jul 5, 2018 at 2:31 AM Mike Larkin 
>> wrote:
>> >> >
>> >> >> On Thu, Jul 05, 2018 at 03:36:17AM +0200, Farid Joubbi wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > I have a server running bhyve in  FreeBSD. I did PCI passthrough
>> in
>> >> >> > order
>> >> >> > to have exclusive access to one of the network interfaces on the
>> >> >> > server.
>> >> >> > My plan was to use that NIC in OpenBSD. Unfortunately when I boot
>> the
>> >> >> > 6.3
>> >> >> > release installer I get this in dmesg:
>> >> >> > "em0 at pci0 dev 5 function 0 "Intel 82576" rev 0x01: couldn't map
>> >> >> > interrupt".
>> >> >> >
>> >> >> > The installation goes through without errors, but the Intel NIC is
>> >> >> > not
>> >> >> > visible during install or after rebooting the installed system.
>> >> >> >
>> >> >> >

Re: em0: couldn't map interrupt (No support for my Intel NIC?)

[Farid Joubbi]

I am running several virtual machines on top of bhyve. I've got FreeBSD,
RHEL, Linux Mint and Debian running now.
I have tried OpenBSD without a passthrough NIC and CentOS.


On Thu, Jul 5, 2018, 20:14 Tom Smyth  wrote:

> Farid
> Can you check if the SR-IOV works by runing another OS  as a vm on top of
> Bhyve on the host
>
> that is what I meant on my previous mail
> Thanks
>
> On 5 July 2018 at 17:49, Farid Joubbi  wrote:
> > Hi,
> > The Intel NIC works correctly in the native FreeBSD. I used it there
> before
> > I did the passthrough.
> > The Intel NIC worked correctly natively when I tested the OpenBSD
> installer.
> > The Intel NIC works in bhyve if I install FreeBSD.
> >
> > The new Broadcom NIC also works normally as long as it's not a OpenBSD
> > instance in bhyve.
> >
> > The NICs are not assigned to other hosts.
> >
> > The settings for virtualization on the hardware are correct to my
> knowledge.
> > I have several other hosts running in bhyve  without problems.
> > One FreeBSD host using passthrough the same way as I intend to do with
> > OpenBSD.
> >
> >
> > On Thu, Jul 5, 2018 at 4:55 PM Tom Smyth 
> > wrote:
> >>
> >> Hello Farid,
> >>
> >>
> >> Can you confirm that other operating systems pick up the Nic ok and
> >> they function ok
> >>
> >> has the Physical Host settings been setup correctly for SR-IOV
> >>
> >> is it possible that the nic has been assigned to another vm ?
> >>
> >> Hope this helps
> >>
> >>
> >> On 5 July 2018 at 15:38, Farid Joubbi  wrote:
> >> > I realize now that I wrote a reply to only Mike and not the whole misc
> >> > earlier.
> >> >
> >> > Anyway.
> >> > The server is running several functions, and it's not popular to do
> >> > maintenance on it.
> >> > I went ahead and rebooted it anyway since this is important ;-)
> >> >
> >> > I booted the OpenBSD 6.3 install media natively on the hardware.
> >> > It found all six NICs that I have installed. There are two Broadcom on
> >> > the
> >> > mainboard and four on the Intel card.
> >> > Broadcoms were found as bge and Intel as em. They all seemed to work.
> >> >
> >> > I had an extra bge card lying around. I installed it in the server and
> >> > did
> >> > PCI passthrough with it as well as the Intel in FreeBSD/bhyve.
> >> > I get the same result in OpenBSD:
> >> > bge0 at pci0 dev 5 function 0 "Broadcom BCM5720" rev 0x00, BCM5720 A0
> >> > (0x572), APE firmware NCSI 1.4.12.0: couldn't map interrupt
> >> >
> >> > Conclusion:
> >> > The problem has to do with the fact that bhyve is between the hardware
> >> > and
> >> > OpenBSD.
> >> >
> >> > Any ideas?
> >> >
> >> > On Thu, Jul 5, 2018 at 2:31 AM Mike Larkin 
> wrote:
> >> >
> >> >> On Thu, Jul 05, 2018 at 03:36:17AM +0200, Farid Joubbi wrote:
> >> >> > Hi,
> >> >> >
> >> >> > I have a server running bhyve in  FreeBSD. I did PCI passthrough in
> >> >> > order
> >> >> > to have exclusive access to one of the network interfaces on the
> >> >> > server.
> >> >> > My plan was to use that NIC in OpenBSD. Unfortunately when I boot
> the
> >> >> > 6.3
> >> >> > release installer I get this in dmesg:
> >> >> > "em0 at pci0 dev 5 function 0 "Intel 82576" rev 0x01: couldn't map
> >> >> > interrupt".
> >> >> >
> >> >> > The installation goes through without errors, but the Intel NIC is
> >> >> > not
> >> >> > visible during install or after rebooting the installed system.
> >> >> >
> >> >> > Man pages suggest that the problem is a fatal initialization error.
> >> >> >
> >> >> > The NIC works without problems installing FreeBSD.
> >> >> > In FreeBSD the NIC uses the igb driver.
> >> >> >
> >> >> > https://man.openbsd.org/FreeBSD-11.1/igb.4
> >> >> >
> >> >> > The OpenBSD man page for em lists 82576EB as supported.
> >> >> >
> >> >> > The NIC is an Intel Gigabi ET2 quad:
> >> >> >
> >> >>
> >&g

Re: em0: couldn't map interrupt (No support for my Intel NIC?)

[Farid Joubbi]

Hi,
The Intel NIC works correctly in the native FreeBSD. I used it there before
I did the passthrough.
The Intel NIC worked correctly natively when I tested the OpenBSD installer.
The Intel NIC works in bhyve if I install FreeBSD.

The new Broadcom NIC also works normally as long as it's not a OpenBSD
instance in bhyve.

The NICs are not assigned to other hosts.

The settings for virtualization on the hardware are correct to my knowledge.
I have several other hosts running in bhyve  without problems.
One FreeBSD host using passthrough the same way as I intend to do with
OpenBSD.


On Thu, Jul 5, 2018 at 4:55 PM Tom Smyth 
wrote:

> Hello Farid,
>
>
> Can you confirm that other operating systems pick up the Nic ok and
> they function ok
>
> has the Physical Host settings been setup correctly for SR-IOV
>
> is it possible that the nic has been assigned to another vm ?
>
> Hope this helps
>
>
> On 5 July 2018 at 15:38, Farid Joubbi  wrote:
> > I realize now that I wrote a reply to only Mike and not the whole misc
> > earlier.
> >
> > Anyway.
> > The server is running several functions, and it's not popular to do
> > maintenance on it.
> > I went ahead and rebooted it anyway since this is important ;-)
> >
> > I booted the OpenBSD 6.3 install media natively on the hardware.
> > It found all six NICs that I have installed. There are two Broadcom on
> the
> > mainboard and four on the Intel card.
> > Broadcoms were found as bge and Intel as em. They all seemed to work.
> >
> > I had an extra bge card lying around. I installed it in the server and
> did
> > PCI passthrough with it as well as the Intel in FreeBSD/bhyve.
> > I get the same result in OpenBSD:
> > bge0 at pci0 dev 5 function 0 "Broadcom BCM5720" rev 0x00, BCM5720 A0
> > (0x572), APE firmware NCSI 1.4.12.0: couldn't map interrupt
> >
> > Conclusion:
> > The problem has to do with the fact that bhyve is between the hardware
> and
> > OpenBSD.
> >
> > Any ideas?
> >
> > On Thu, Jul 5, 2018 at 2:31 AM Mike Larkin  wrote:
> >
> >> On Thu, Jul 05, 2018 at 03:36:17AM +0200, Farid Joubbi wrote:
> >> > Hi,
> >> >
> >> > I have a server running bhyve in  FreeBSD. I did PCI passthrough in
> order
> >> > to have exclusive access to one of the network interfaces on the
> server.
> >> > My plan was to use that NIC in OpenBSD. Unfortunately when I boot the
> 6.3
> >> > release installer I get this in dmesg:
> >> > "em0 at pci0 dev 5 function 0 "Intel 82576" rev 0x01: couldn't map
> >> > interrupt".
> >> >
> >> > The installation goes through without errors, but the Intel NIC is not
> >> > visible during install or after rebooting the installed system.
> >> >
> >> > Man pages suggest that the problem is a fatal initialization error.
> >> >
> >> > The NIC works without problems installing FreeBSD.
> >> > In FreeBSD the NIC uses the igb driver.
> >> >
> >> > https://man.openbsd.org/FreeBSD-11.1/igb.4
> >> >
> >> > The OpenBSD man page for em lists 82576EB as supported.
> >> >
> >> > The NIC is an Intel Gigabi ET2 quad:
> >> >
> >>
> https://ark.intel.com/products/series/46841/Intel-Gigabit-ET-Server-Adapter-Series
> >> >
> >> > Could it be that the quad variant of the NIC is not supported by
> OpenBSD?
> >> > Is there anything I can do to make it work?
> >> > Is it possible to use the igb driver in OpenBSD somehow?
> >> >
> >> > Thanks.
> >>
> >> Before anyone at all spends any time on this, please verify if this
> works
> >> without bhyve in the way. Eg, boot natively on this hardware and see.
> >>
> >> Or did you already do that? In which case the commentary about bhyve is
> >> extraneous.
> >>
> >> -ml
> >>
>
>
>
> --
> Kindest regards,
> Tom Smyth
>
> Mobile: +353 87 6193172
> The information contained in this E-mail is intended only for the
> confidential use of the named recipient. If the reader of this message
> is not the intended recipient or the person responsible for
> delivering it to the recipient, you are hereby notified that you have
> received this communication in error and that any review,
> dissemination or copying of this communication is strictly prohibited.
> If you have received this in error, please notify the sender
> immediately by telephone at the number above and erase the message
> You are requested to carry out your own virus check before
> opening any attachment.
>

Re: em0: couldn't map interrupt (No support for my Intel NIC?)

[Farid Joubbi]

I realize now that I wrote a reply to only Mike and not the whole misc
earlier.

Anyway.
The server is running several functions, and it's not popular to do
maintenance on it.
I went ahead and rebooted it anyway since this is important ;-)

I booted the OpenBSD 6.3 install media natively on the hardware.
It found all six NICs that I have installed. There are two Broadcom on the
mainboard and four on the Intel card.
Broadcoms were found as bge and Intel as em. They all seemed to work.

I had an extra bge card lying around. I installed it in the server and did
PCI passthrough with it as well as the Intel in FreeBSD/bhyve.
I get the same result in OpenBSD:
bge0 at pci0 dev 5 function 0 "Broadcom BCM5720" rev 0x00, BCM5720 A0
(0x572), APE firmware NCSI 1.4.12.0: couldn't map interrupt

Conclusion:
The problem has to do with the fact that bhyve is between the hardware and
OpenBSD.

Any ideas?

On Thu, Jul 5, 2018 at 2:31 AM Mike Larkin  wrote:

> On Thu, Jul 05, 2018 at 03:36:17AM +0200, Farid Joubbi wrote:
> > Hi,
> >
> > I have a server running bhyve in  FreeBSD. I did PCI passthrough in order
> > to have exclusive access to one of the network interfaces on the server.
> > My plan was to use that NIC in OpenBSD. Unfortunately when I boot the 6.3
> > release installer I get this in dmesg:
> > "em0 at pci0 dev 5 function 0 "Intel 82576" rev 0x01: couldn't map
> > interrupt".
> >
> > The installation goes through without errors, but the Intel NIC is not
> > visible during install or after rebooting the installed system.
> >
> > Man pages suggest that the problem is a fatal initialization error.
> >
> > The NIC works without problems installing FreeBSD.
> > In FreeBSD the NIC uses the igb driver.
> >
> > https://man.openbsd.org/FreeBSD-11.1/igb.4
> >
> > The OpenBSD man page for em lists 82576EB as supported.
> >
> > The NIC is an Intel Gigabi ET2 quad:
> >
> https://ark.intel.com/products/series/46841/Intel-Gigabit-ET-Server-Adapter-Series
> >
> > Could it be that the quad variant of the NIC is not supported by OpenBSD?
> > Is there anything I can do to make it work?
> > Is it possible to use the igb driver in OpenBSD somehow?
> >
> > Thanks.
>
> Before anyone at all spends any time on this, please verify if this works
> without bhyve in the way. Eg, boot natively on this hardware and see.
>
> Or did you already do that? In which case the commentary about bhyve is
> extraneous.
>
> -ml
>

em0: couldn't map interrupt (No support for my Intel NIC?)

[Farid Joubbi]

Hi,

I have a server running bhyve in  FreeBSD. I did PCI passthrough in order
to have exclusive access to one of the network interfaces on the server.
My plan was to use that NIC in OpenBSD. Unfortunately when I boot the 6.3
release installer I get this in dmesg:
"em0 at pci0 dev 5 function 0 "Intel 82576" rev 0x01: couldn't map
interrupt".

The installation goes through without errors, but the Intel NIC is not
visible during install or after rebooting the installed system.

Man pages suggest that the problem is a fatal initialization error.

The NIC works without problems installing FreeBSD.
In FreeBSD the NIC uses the igb driver.

https://man.openbsd.org/FreeBSD-11.1/igb.4

The OpenBSD man page for em lists 82576EB as supported.

The NIC is an Intel Gigabi ET2 quad:
https://ark.intel.com/products/series/46841/Intel-Gigabit-ET-Server-Adapter-Series

Could it be that the quad variant of the NIC is not supported by OpenBSD?
Is there anything I can do to make it work?
Is it possible to use the igb driver in OpenBSD somehow?

Thanks.

Re: PHP error running ownclouds occ

[Farid Joubbi]

I figured out that it's easier to disable the documents app directly in the
database than trying to get occ to work.
A kind person sent me an e-mail off this list and pointed me in the right
direction.

Anyway, if someone has the same problem, here is what I did:
# psql owncloud owncloud
owncloud=> update oc_appconfig set configvalue = 'no' where appid =
'documents' and configkey = 'enabled';

Thank you OpenBSD and misc@openbsd.org !

On Mon, Oct 16, 2017 at 9:57 AM, Farid Joubbi <djfa...@gmail.com> wrote:

> Hi,
> I upgraded my OpenBSD installation from 6.1 to 6.2.
> In the upgrade process I also upgraded the ownCloud package to 10.0.3.
> Now when I browse to the ownCloud page, it wants to upgrade.
> The upgrade fails with this message:
>
>
>
> Repair warning: You have incompatible or missing apps enabled that
> could not be found or updated via the marketplace.
> Repair warning: Please install or update the following apps manually
> or disable them with: occ app:disable documents
> Repair warning: For manually updating, see https://doc.owncloud.org/
> server/10.0/go.php?to=admin-marketplace-apps
>
>
>
> So I figured that I will do as it says and run the occ command.
> But the command fails, and I don't understand why.
>
>
> su -l -s /bin/sh www
>
> $ cd /var/www/owncloud/
> $ ./occ
> PHP Warning: Module 'curl' already loaded in Unknown on line 0
> PHP Warning: Module 'gd' already loaded in Unknown on line 0
> PHP Warning: Module 'intl' already loaded in Unknown on line 0
> PHP Warning: Module 'zip' already loaded in Unknown on line 0
> The process control (PCNTL) extensions are required in case you want to
> interrupt long running commands - see http://php.net/manual/en/book.
> pcntl.php
> ownCloud or one of the apps require upgrade - only a limited number of
> commands are available
> You may use your browser or the occ upgrade command to do the upgrade
> Cannot create "data" directory
> This can usually be fixed by giving the webserver write access to the root
> directory.
>
> {"reqId":"uds8VWpXGYWCkIjzmcjW","level":3,"time":"2017-10-14T22:40:06+
> 00:00","remoteAddr":"","user":"--","app":"PHP","method":"--","url":"--","message":"Module
> 'zip' already loaded at Unknown#0"}
> An unhandled exception has been thrown:
> exception 'Exception' with message 'Environment not properly prepared.' in
> /var/www/owncloud/lib/private/Console/Application.php:134
> Stack trace:
>
> 0 /var/www/owncloud/console.php(105): OC\Console\Application->
> loadCommands(Object(Symfony\Component\Console\Input\ArgvInput),
> Object(Symfony\Component\Console\Output\ConsoleOutput))
>
> 1 /var/www/owncloud/occ(11): require_once('/var/www/ownclo...')
>
> 2 {main}$
>
> $ ls -l
> total 316
> -rw-r--r-- 1 root bin 8859 Sep 15 16:43 AUTHORS
> -rw-r--r-- 1 root bin 25213 Sep 15 16:43 CHANGELOG.md
> -rw-r--r-- 1 root bin 34520 Sep 15 16:43 COPYING
> drwxr-xr-x 37 www www 1024 Oct 14 21:40 apps
> drwxr-x--- 2 www www 512 Oct 14 21:37 config
> -rw-r--r-- 1 root bin 4345 Sep 15 16:42 console.php
> drwxr-xr-x 17 root daemon 1024 Oct 14 21:37 core
> -rw-r--r-- 1 root bin 4969 Sep 15 16:42 cron.php
> drwxr-x--- 6 www www 512 Nov 30 2016 data
> -rw-r--r-- 1 root bin 30898 Sep 15 16:42 db_structure.xml
> -rw-r--r-- 1 root bin 179 Sep 15 16:42 index.html
> -rw-r--r-- 1 root bin 3898 Sep 15 16:42 index.php
> drwxr-xr-x 3 root daemon 512 Oct 14 21:37 l10n
> drwxr-xr-x 6 root daemon 512 Oct 14 21:37 lib
> -rwxr-xr-x 1 root bin 289 Oct 2 20:10 occ
> drwxr-xr-x 2 root daemon 512 Oct 14 21:37 ocs
> drwxr-xr-x 2 root daemon 512 Oct 14 21:37 ocs-provider
> -rw-r--r-- 1 root bin 3197 Sep 15 16:42 public.php
> -rw-r--r-- 1 root bin 5481 Sep 15 16:42 remote.php
> drwxr-xr-x 4 root daemon 512 Apr 25 09:42 resources
> drwxr-xr-x 12 root daemon 512 Oct 14 21:37 settings
> -rw-r--r-- 1 root bin 1757 Sep 15 16:42 status.php
> drwxr-xr-x 6 root daemon 512 Oct 14 21:37 updater
> -rw-r--r-- 1 root bin 278 Oct 2 20:10 version.php
> $
>
> Any ideas?
> I have read the owncloud manual and all the file permissions seem to be ok.
> Could it be that I am missing some OpenBSD specific thing that makes it
> fail?
> Thanks in advance for any kind of help or pointers.
>
>

PHP error running ownclouds occ

[Farid Joubbi]

Hi,
I upgraded my OpenBSD installation from 6.1 to 6.2.
In the upgrade process I also upgraded the ownCloud package to 10.0.3.
Now when I browse to the ownCloud page, it wants to upgrade.
The upgrade fails with this message:



Repair warning: You have incompatible or missing apps enabled that
could not be found or updated via the marketplace.
Repair warning: Please install or update the following apps manually or
disable them with: occ app:disable documents
Repair warning: For manually updating, see
https://doc.owncloud.org/server/10.0/go.php?to=admin-marketplace-apps



So I figured that I will do as it says and run the occ command.
But the command fails, and I don't understand why.


su -l -s /bin/sh www

$ cd /var/www/owncloud/
$ ./occ
PHP Warning: Module 'curl' already loaded in Unknown on line 0
PHP Warning: Module 'gd' already loaded in Unknown on line 0
PHP Warning: Module 'intl' already loaded in Unknown on line 0
PHP Warning: Module 'zip' already loaded in Unknown on line 0
The process control (PCNTL) extensions are required in case you want to
interrupt long running commands - see
http://php.net/manual/en/book.pcntl.php
ownCloud or one of the apps require upgrade - only a limited number of
commands are available
You may use your browser or the occ upgrade command to do the upgrade
Cannot create "data" directory
This can usually be fixed by giving the webserver write access to the root
directory.

{"reqId":"uds8VWpXGYWCkIjzmcjW","level":3,"time":"2017-10-14T22:40:06+00:00","remoteAddr":"","user":"--","app":"PHP","method":"--","url":"--","message":"Module
'zip' already loaded at Unknown#0"}
An unhandled exception has been thrown:
exception 'Exception' with message 'Environment not properly prepared.' in
/var/www/owncloud/lib/private/Console/Application.php:134
Stack trace:

0 /var/www/owncloud/console.php(105):
OC\Console\Application->loadCommands(Object(Symfony\Component\Console\Input\ArgvInput),
Object(Symfony\Component\Console\Output\ConsoleOutput))

1 /var/www/owncloud/occ(11): require_once('/var/www/ownclo...')

2 {main}$

$ ls -l
total 316
-rw-r--r-- 1 root bin 8859 Sep 15 16:43 AUTHORS
-rw-r--r-- 1 root bin 25213 Sep 15 16:43 CHANGELOG.md
-rw-r--r-- 1 root bin 34520 Sep 15 16:43 COPYING
drwxr-xr-x 37 www www 1024 Oct 14 21:40 apps
drwxr-x--- 2 www www 512 Oct 14 21:37 config
-rw-r--r-- 1 root bin 4345 Sep 15 16:42 console.php
drwxr-xr-x 17 root daemon 1024 Oct 14 21:37 core
-rw-r--r-- 1 root bin 4969 Sep 15 16:42 cron.php
drwxr-x--- 6 www www 512 Nov 30 2016 data
-rw-r--r-- 1 root bin 30898 Sep 15 16:42 db_structure.xml
-rw-r--r-- 1 root bin 179 Sep 15 16:42 index.html
-rw-r--r-- 1 root bin 3898 Sep 15 16:42 index.php
drwxr-xr-x 3 root daemon 512 Oct 14 21:37 l10n
drwxr-xr-x 6 root daemon 512 Oct 14 21:37 lib
-rwxr-xr-x 1 root bin 289 Oct 2 20:10 occ
drwxr-xr-x 2 root daemon 512 Oct 14 21:37 ocs
drwxr-xr-x 2 root daemon 512 Oct 14 21:37 ocs-provider
-rw-r--r-- 1 root bin 3197 Sep 15 16:42 public.php
-rw-r--r-- 1 root bin 5481 Sep 15 16:42 remote.php
drwxr-xr-x 4 root daemon 512 Apr 25 09:42 resources
drwxr-xr-x 12 root daemon 512 Oct 14 21:37 settings
-rw-r--r-- 1 root bin 1757 Sep 15 16:42 status.php
drwxr-xr-x 6 root daemon 512 Oct 14 21:37 updater
-rw-r--r-- 1 root bin 278 Oct 2 20:10 version.php
$

Any ideas?
I have read the owncloud manual and all the file permissions seem to be ok.
Could it be that I am missing some OpenBSD specific thing that makes it
fail?
Thanks in advance for any kind of help or pointers.

Re: httpd weirdness ("connection max request body")

[Farid Joubbi]

Does anyone know if I should report this as a bug (or is it me being
incompetent)?

On Fri, Dec 16, 2016 at 3:17 PM, Farid Joubbi <djfa...@gmail.com> wrote:

> Hello,
>
> I noticed a weird thing which I can not explain.
> To me it feels like a bug with httpd, or some feature that I have
> misunderstood.
>
> I have a server running 6.0 -stable.
> It runs httpd with both the roundcube and owncloud ports.
> The server has only one NIC with only one public IP address.
>
> Sometimes owncloud did not sync some files that I tried to sync with the
> client.
> It was always the same files that failed, but I was not able to see a
> pattern of which files failed.
>
> I noticed lines like this in /var/www/logs/access.log for the failed files:
> mail.example.se 6.6.6.6 - - [16/Dec/2016:11:17:25 +0100] "PUT
> /owncloud/remote.php/webdav/ebooks/A%2520Planet%2520of%2520Viruses.epub
> HTTP/1.1" 413 0
>
> The strange thing with this log entry is that the owncloud client syncs to
> the address https://cloud.example.se/owncloud but the log entry states
> mail.example.se
> All the succesfully synced files had status 2xx with the correct
> cloud.exampe.se address.
>
> mail.example.se is the address to roundcube.
> cloud.example.se is the address to owncloud.
> HTTP response code 413 is entity too large.
>
> I added
> connection max request body 10737418240
> to mail.example.se in httpd.conf, and the problem went away.
> I already had that line for cloud.example.se since before.
>
> Now this:
> # grep Viruses.epub /var/www/logs/access.log
> mail.example.se 6.6.6.6 - - [16/Dec/2016:11:17:25 +0100] "PUT
> /owncloud/remote.php/webdav/ebooks/A%2520Planet%2520of%2520Viruses.epub
> HTTP/1.1" 413 0
> mail.example.se 6.6.6.6 - - [16/Dec/2016:11:17:26 +0100] "PUT
> /owncloud/remote.php/webdav/ebooks/A%2520Planet%2520of%2520Viruses.epub
> HTTP/1.1" 413 0
> mail.example.se 6.6.6.6 - - [16/Dec/2016:11:17:26 +0100] "PUT
> /owncloud/remote.php/webdav/ebooks/A%2520Planet%2520of%2520Viruses.epub
> HTTP/1.1" 413 0
> cloud.example.se 6.6.6.6 - - [16/Dec/2016:12:05:07 +0100] "PUT
> /owncloud/remote.php/webdav/ebooks/A%20Planet%20of%20Viruses.epub
> HTTP/1.1" 201 0
> #
>
> So the last log entry shows the successful sync with the correct FQDN and
> the same IP address as with the wrong FQDN earlier.
> I would have expected this line to have the same wrong FQDN since all I
> did was to change the "connection max request body" for the wrong FQDN.
>
> Now my questions.
> Why did owncloud sync some files to mail.example.se instead of
> cloud.example.se?
> Why does it work as supposed to after me raising the file upload limit for
> mail.example.se?
> Is it possible to have different "connection max request body" for the
> different servers?
> Am I doing something wrong in httpd.conf?
>
> Here is my httpd.conf:
> # cat /etc/httpd.conf
>
>
> # $OpenBSD: httpd.conf,v 1.14 2015/02/04 08:39:35 florian Exp $
>
> #
> # Macros
> #
> ext_addr="*"
>
> #
> # Global Options
> #
> # prefork 3
>
> #
> # Servers
> #
>
>
> # Include MIME types instead of the built-in ones
> types {
> include "/usr/share/misc/mime.types"
> #   include "/var/www/etc/mime.types"
> }
> server "mail.example.se" {
> listen on * tls port 443
> root "/roundcubemail"
> directory index index.php
>
> location "*.php" {
> fastcgi socket "/run/php-fpm.sock"
> }
> tls certificate "/etc/ssl/acme/fullchain.pem"
> tls key "/etc/ssl/acme/private/privkey.pem"
> # Set max upload size to 10GiB (in bytes)
> connection max request body 10737418240 #This line was added to
> solve this particular problem, even though the problem has nothing to do
> with roundcubemail.
>
> }
>
> server "server.example.se" {
> listen on * tls port 443
> root "/htdocs"
> tls certificate "/etc/ssl/acme/fullchain.pem"
> tls key "/etc/ssl/acme/private/privkey.pem"
> }
>
>
> server "cloud.example.se" {
> listen on * tls port 443
>
> # Set max upload size to 10GiB (in bytes)
> connection max request body 10737418240
>
> # First deny access to the specified files
> location "/db_structure.xml" { block }
> location "/.ht*" { block }
> location "/README"   { block }
> location "/data*"   

Re: OpenBSD Stable

[Farid Joubbi]

I found this very informative:
http://daemonforums.org/showthread.php?t=9374

On Wed, Jan 18, 2017 at 2:29 PM, Maurice McCarthy 
wrote:

> On Wed, Jan 18, 2017 at 01:55:36PM +0200 or thereabouts, Kapetanakis
> Giannis wrote:
> > On 18/01/17 12:36, George wrote:
> > > Its the stable version that im trying to install. I installed the
> > > release version but i wanted to update to stable mostly for the
> security
> > > patches.
>
> ...
>
> >
> > I'm not sure about the update procedure for packages in stable.
> > I only use snapshots and update with
> > pkg_add -u
> >
> > For stable you probably have to recompile them yourself from ports,
> since I see in mirror servers that they are not updated.
> >
> > G
> >
>
> https://www.mtier.org/solutions/apps/openup/

httpd weirdness ("connection max request body")

[Farid Joubbi]

Hello,

I noticed a weird thing which I can not explain.
To me it feels like a bug with httpd, or some feature that I have
misunderstood.

I have a server running 6.0 -stable.
It runs httpd with both the roundcube and owncloud ports.
The server has only one NIC with only one public IP address.

Sometimes owncloud did not sync some files that I tried to sync with the
client.
It was always the same files that failed, but I was not able to see a
pattern of which files failed.

I noticed lines like this in /var/www/logs/access.log for the failed files:
mail.example.se 6.6.6.6 - - [16/Dec/2016:11:17:25 +0100] "PUT
/owncloud/remote.php/webdav/ebooks/A%2520Planet%2520of%2520Viruses.epub
HTTP/1.1" 413 0

The strange thing with this log entry is that the owncloud client syncs to
the address https://cloud.example.se/owncloud but the log entry states
mail.example.se
All the succesfully synced files had status 2xx with the correct
cloud.exampe.se address.

mail.example.se is the address to roundcube.
cloud.example.se is the address to owncloud.
HTTP response code 413 is entity too large.

I added
connection max request body 10737418240
to mail.example.se in httpd.conf, and the problem went away.
I already had that line for cloud.example.se since before.

Now this:
# grep Viruses.epub /var/www/logs/access.log
mail.example.se 6.6.6.6 - - [16/Dec/2016:11:17:25 +0100] "PUT
/owncloud/remote.php/webdav/ebooks/A%2520Planet%2520of%2520Viruses.epub
HTTP/1.1" 413 0
mail.example.se 6.6.6.6 - - [16/Dec/2016:11:17:26 +0100] "PUT
/owncloud/remote.php/webdav/ebooks/A%2520Planet%2520of%2520Viruses.epub
HTTP/1.1" 413 0
mail.example.se 6.6.6.6 - - [16/Dec/2016:11:17:26 +0100] "PUT
/owncloud/remote.php/webdav/ebooks/A%2520Planet%2520of%2520Viruses.epub
HTTP/1.1" 413 0
cloud.example.se 6.6.6.6 - - [16/Dec/2016:12:05:07 +0100] "PUT
/owncloud/remote.php/webdav/ebooks/A%20Planet%20of%20Viruses.epub HTTP/1.1"
201 0
#

So the last log entry shows the successful sync with the correct FQDN and
the same IP address as with the wrong FQDN earlier.
I would have expected this line to have the same wrong FQDN since all I did
was to change the "connection max request body" for the wrong FQDN.

Now my questions.
Why did owncloud sync some files to mail.example.se instead of
cloud.example.se?
Why does it work as supposed to after me raising the file upload limit for
mail.example.se?
Is it possible to have different "connection max request body" for the
different servers?
Am I doing something wrong in httpd.conf?

Here is my httpd.conf:
# cat /etc/httpd.conf


# $OpenBSD: httpd.conf,v 1.14 2015/02/04 08:39:35 florian Exp $

#
# Macros
#
ext_addr="*"

#
# Global Options
#
# prefork 3

#
# Servers
#


# Include MIME types instead of the built-in ones
types {
include "/usr/share/misc/mime.types"
#   include "/var/www/etc/mime.types"
}
server "mail.example.se" {
listen on * tls port 443
root "/roundcubemail"
directory index index.php

location "*.php" {
fastcgi socket "/run/php-fpm.sock"
}
tls certificate "/etc/ssl/acme/fullchain.pem"
tls key "/etc/ssl/acme/private/privkey.pem"
# Set max upload size to 10GiB (in bytes)
connection max request body 10737418240 #This line was added to
solve this particular problem, even though the problem has nothing to do
with roundcubemail.

}

server "server.example.se" {
listen on * tls port 443
root "/htdocs"
tls certificate "/etc/ssl/acme/fullchain.pem"
tls key "/etc/ssl/acme/private/privkey.pem"
}


server "cloud.example.se" {
listen on * tls port 443

# Set max upload size to 10GiB (in bytes)
connection max request body 10737418240

# First deny access to the specified files
location "/db_structure.xml" { block }
location "/.ht*" { block }
location "/README"   { block }
location "/data*"{ block }
location "/config*"  { block }

location "/*.php*" {
root { "/owncloud", strip 1 }
fastcgi socket "/run/php-fpm.sock"
}

location "/*" {
root { "/owncloud", strip 1 }
}
tls certificate "/etc/ssl/acme/fullchain.pem"
tls key "/etc/ssl/acme/private/privkey.pem"

}
server "default" {
listen on * port 80

location "/.well-known/acme-challenge/*" {
root "/acme"
root strip 2
}
}


NOTE I have censored the IP addresses and the domain names.

Thanks in advance!

snmpd(8) - configuration

[Farid Joubbi]

Hi,

I have two questions about the snmpd base:

1. Is there a way to disable the write community? I do not want to
have snmp write enabled at all.

2. Is it possible to restrict snmp reads based on source address? I
want to allow snmp read from only one single machine.
(I know that I could do this with pf)


Thanks,
Farid