Re: Qubes-OS is "fake" security

[Florian Ermisch]

Sorry, out of herrings. Have a listen to this 
instead: 
"Risky Biz Soap Box: A microvirtualisation 
primer with Bromium co-founder Ian Pratt
(a.k.a. how to run Java plugin on IE8 and 
not die!)"
https://risky.biz/soapbox3/

Am 12. Mai 2017 03:41:05 MESZ schrieb Kim Blackwood 
:
>Hi,
>
>I am at novice level of security, studying and trying to understand
>some of the different aspects of running an OS and applications as
>securely as possible.
>
>I have been running OpenBSD for years and understand a little of what's
>being done to make it more secure, albeit not the technical details of
>programming as much as I am not a C programmer.
>
>A friend of mine, who is computer a scientist with speciality in
>security, suggested Qubes-OS as a secure "solution" to security
>problems related to OS's and applications on a personal computer.
>
>I read up about the project and tested it out, but I am not convinced
>that it is a good solution at all.
>
>I am writing to this list because I know that a lot of people on this
>list is very security-minded.
>
>I found the reading "An Empirical Study into the Security Exposure to
>Hosts of Hostile Virtualized Environments" very insightful.
>
>http://taviso.decsystem.org/virtsec.pdf
>
>First, I cannot really see the difference between an OS and a
>hypervisor. Both runs on the "bare metal" and both perform similar
>tasks. In the specific case with Qubes-OS, there isn't really a
>difference as it's "just" Fedora with Xen.
>
>Possibilities of exploiting the hypervisor isn't lower than
>possibilities of exploiting the OS. And specifically in the case of
>OpenBSD as the OS, that has been developed from the ground up with
>security in mind, the possibilities are much lower than a hypervisor
>that hasn't even been developed with security measures from the
>beginning.
>
>Second, the virtualization part as I see it, just ads another level of
>tons of code.
>
>If I am running Firefox on OpenBSD and Firefox gets exploited, the
>cracker finds himself on a very secure OS that's really hard to
>compromise.
>
>If I am running Firefox in some virtualization container on Qubes-OS
>and Firefox gets exploited, then the cracker finds himself inside a
>container that could possible contain lots of exploitable security
>holes that again runs on a hypervisor with possibly lots of security
>holes, stuff that hasn't been developed with security in mind and has
>perhaps never been audited.
>
>Qubes-OS seems to me as a solution of "patching".
>
>OpenBSD on the other hand is a completely different story.
>
>Rather than running something like Qubes-OS, which IMHO provides a fake
>feeling of security, with it's different "qubes", I would think of
>another situation that's much better.
>
>I either set up 3 different computers, or one computer where I can
>physically change the hard drive and I then have 3 different hard
>drives.
>
>On one box I setup OpenBSD and the most secure-minded browser I can
>find (do such a thing even exist?). On this particular setup I *ONLY*
>do my home banking. Absolutely nothing else.
>
>On the second box I also setup OpenBSD and the most secure-minded email
>client I can find and I do all my email there. I possibly also setup an
>office application for writing letters, etc. I don't use a browser on
>this setup, if someone sends an email with a link, I write the link
>down for latter usage.
>
>And on the third box I also setup OpenBSD with a browser and possible
>other applications like a video player, and this box I use for all the
>other casual stuff, the links from emails, etc. I possibly even run
>this from a non-writeable CD or SD card.
>
>It will be an inconvenience to shift between the drives, but no more
>than using Qubes-OS.
>
>IMHO the setup with the different OpenBSD installations provides a
>much more security alternative than running Qubes-OS.
>
>Am I completely of track here?
>
>Kind regards,
>
>Kim

Re: OpenBSD 6.1: BOOTIA32 3.32 issue

[Michele Curti]

On Fri, May 12, 2017 at 11:05:13AM +0900, YASUOKA Masahiko wrote:
> On Thu, 11 May 2017 23:45:17 +0200
> Michele Curti  wrote:
> 
> All disks are identical in HARDWARE_DEVICE_PATH and ACPI_DEVICE_PATH
> and they all don't have MESSAGING_DEVICE_PATH.  So the boot loader
> mistakenly treats all of them as the bootdisk..
> 
> I'd like to know whether there is a way to distigish those disks.  Can
> you try the diff following?
> 
> diff --git a/sys/arch/amd64/stand/efiboot/efiboot.c 
> b/sys/arch/amd64/stand/efiboot/efiboot.c
> index efa371f2ecd..891b6c75cc9 100644
> --- a/sys/arch/amd64/stand/efiboot/efiboot.c
> +++ b/sys/arch/amd64/stand/efiboot/efiboot.c
> @@ -208,6 +208,14 @@ next:
>   TAILQ_INSERT_HEAD(_disklist, di, list);
>   else
>   TAILQ_INSERT_TAIL(_disklist, di, list);
> +
> + printf("%d\n", i);
> + for (; !IsDevicePathEnd(dp); dp = NextDevicePathNode(dp)) {
> + int ii;
> + for (ii = 0; ii < DevicePathNodeLength(dp); ii++)
> + printf("%x ", *((u_char *)dp + ii));
> + printf("\n");
> + }
>   }
>  
>   free(handles, sz);
> 

0
2 1 c 0 d0 41 3 a 0 0 0 0
1 1 6 0 0 17
1 5 8 0 0 0 0 0
1
2 1 c 0 d0 41 3 a 0 0 0 0
1 1 6 0 0 17
1 5 8 0 1 0 0 0
2
2 1 c 0 d0 41 3 a 0 0 0 0
1 1 6 0 0 17
1 5 8 0 2 0 0 0


The efi_device_path_cmp() compares only a path node.
I tried the following diff just to see if I undestood something, 
hd0 is now set corrctly to the 29GB disk.


Index: efiboot/efiboot.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
retrieving revision 1.17
diff -u -p -r1.17 efiboot.c
--- efiboot/efiboot.c   3 Mar 2017 08:56:18 -   1.17
+++ efiboot/efiboot.c   12 May 2017 05:23:21 -
@@ -233,10 +233,21 @@ efi_device_path_cmp(EFI_DEVICE_PATH *dpa
}
 
if (dpt_a && dpt_b) {
-   cmp = DevicePathNodeLength(dpt_a) - DevicePathNodeLength(dpt_b);
-   if (cmp)
-   return (cmp);
-   return (memcmp(dpt_a, dpt_b, DevicePathNodeLength(dpt_a)));
+   for (;!IsDevicePathEnd(dpt_a);) {
+   cmp = DevicePathNodeLength(dpt_a) - 
DevicePathNodeLength(dpt_b);
+   if (cmp)
+   return (cmp);
+   cmp = memcmp(dpt_a, dpt_b, DevicePathNodeLength(dpt_a));
+   if (cmp)
+   return (cmp);
+   dpt_a = NextDevicePathNode(dpt_a);
+   dpt_b = NextDevicePathNode(dpt_b);
+   cmp = IsDevicePathEnd(dpt_a) - IsDevicePathEnd(dpt_b);
+   if (cmp)
+   return (cmp);
+   }
+
+   return 0;
}
 
return ((uintptr_t)dpt_a - (uintptr_t)dpt_b);

Qubes-OS is "fake" security

[Kim Blackwood]

Hi,

I am at novice level of security, studying and trying to understand
some of the different aspects of running an OS and applications as
securely as possible.

I have been running OpenBSD for years and understand a little of what's
being done to make it more secure, albeit not the technical details of
programming as much as I am not a C programmer.

A friend of mine, who is computer a scientist with speciality in
security, suggested Qubes-OS as a secure "solution" to security
problems related to OS's and applications on a personal computer.

I read up about the project and tested it out, but I am not convinced
that it is a good solution at all.

I am writing to this list because I know that a lot of people on this
list is very security-minded.

I found the reading "An Empirical Study into the Security Exposure to
Hosts of Hostile Virtualized Environments" very insightful.

http://taviso.decsystem.org/virtsec.pdf

First, I cannot really see the difference between an OS and a
hypervisor. Both runs on the "bare metal" and both perform similar
tasks. In the specific case with Qubes-OS, there isn't really a
difference as it's "just" Fedora with Xen.

Possibilities of exploiting the hypervisor isn't lower than
possibilities of exploiting the OS. And specifically in the case of
OpenBSD as the OS, that has been developed from the ground up with
security in mind, the possibilities are much lower than a hypervisor
that hasn't even been developed with security measures from the
beginning.

Second, the virtualization part as I see it, just ads another level of
tons of code.

If I am running Firefox on OpenBSD and Firefox gets exploited, the
cracker finds himself on a very secure OS that's really hard to
compromise.

If I am running Firefox in some virtualization container on Qubes-OS
and Firefox gets exploited, then the cracker finds himself inside a
container that could possible contain lots of exploitable security
holes that again runs on a hypervisor with possibly lots of security
holes, stuff that hasn't been developed with security in mind and has
perhaps never been audited.

Qubes-OS seems to me as a solution of "patching".

OpenBSD on the other hand is a completely different story.

Rather than running something like Qubes-OS, which IMHO provides a fake
feeling of security, with it's different "qubes", I would think of
another situation that's much better.

I either set up 3 different computers, or one computer where I can
physically change the hard drive and I then have 3 different hard
drives.

On one box I setup OpenBSD and the most secure-minded browser I can
find (do such a thing even exist?). On this particular setup I *ONLY*
do my home banking. Absolutely nothing else.

On the second box I also setup OpenBSD and the most secure-minded email
client I can find and I do all my email there. I possibly also setup an
office application for writing letters, etc. I don't use a browser on
this setup, if someone sends an email with a link, I write the link
down for latter usage.

And on the third box I also setup OpenBSD with a browser and possible
other applications like a video player, and this box I use for all the
other casual stuff, the links from emails, etc. I possibly even run
this from a non-writeable CD or SD card.

It will be an inconvenience to shift between the drives, but no more
than using Qubes-OS.

IMHO the setup with the different OpenBSD installations provides a
much more security alternative than running Qubes-OS.

Am I completely of track here?

Kind regards,

Kim

Re: Qubes-OS is "fake" security

[Daniel Jakots]

On Fri, 12 May 2017 03:41:05 +0200, Kim Blackwood
 wrote:

> Hi,

From: Martin Hanson 
To: misc 
Subject: Why would I need a container like Docker?!
Date: Wed, 10 May 2017 05:53:07 +0200
X-Mailer: Yamail [ http://yandex.ru ] 5.0


From: Kim Blackwood 
To: misc@openbsd.org
Subject: Qubes-OS is "fake" security
Date: Fri, 12 May 2017 03:41:05 +0200
X-Mailer: Yamail [ http://yandex.ru ] 5.0


Is it the holidays or something?

Re: OpenBSD 6.1: BOOTIA32 3.32 issue

[YASUOKA Masahiko]

On Thu, 11 May 2017 23:45:17 +0200
Michele Curti  wrote:
> On Wed, May 10, 2017 at 08:35:28PM +0200, Patrick Wildt wrote:
>> 
>> I don't think this is the correct fix.  It might solve your issue, but I
>> don't think it's completely right.  So EFI has those so called device
>> paths.  A path is basically a list of nodes.  To compare two paths you
>> need to compare the whole path and not just a single node of it.  If you
>> store dp instead of dp0 you will basically only save a part of the path,
>> not the full path.
>> 
>> What you can do is print the full path of efi_bootdp like..
>> 
>> for (dp = efi_bootdp; !IsDevicePathEnd(dp);
>> dp = NextDevicePathNode(dp)) {
>> printf("%x %x - ", DevicePathType(dp), DevicePathSubType(dp));
>> }
>> printf("\n");
>> 
>> And do the same for the DPs that are being put into the
>> efi_device_path_cmp function.  That will at least print the types, but
>> not the content of the nodes.  That's a start into figuring out why it
>> does not correctly compare the paths.
>> 
>> Maybe there's a bug in the compare code?
> 
> Sorry, only now I understood what you said... Got
> 
> 2 1 - 1 1 - 1 5 - 4 1 -
> 
> (2 1) (2 1) da db cmp da db cmp diff bootdev 1
> (2 1) (2 1) da db cmp da db cmp diff bootdev 1
> (2 1) (2 1) da db cmp da db cmp diff bootdev 1
> 
> with the following diff

All disks are identical in HARDWARE_DEVICE_PATH and ACPI_DEVICE_PATH
and they all don't have MESSAGING_DEVICE_PATH.  So the boot loader
mistakenly treats all of them as the bootdisk..

I'd like to know whether there is a way to distigish those disks.  Can
you try the diff following?

diff --git a/sys/arch/amd64/stand/efiboot/efiboot.c 
b/sys/arch/amd64/stand/efiboot/efiboot.c
index efa371f2ecd..891b6c75cc9 100644
--- a/sys/arch/amd64/stand/efiboot/efiboot.c
+++ b/sys/arch/amd64/stand/efiboot/efiboot.c
@@ -208,6 +208,14 @@ next:
TAILQ_INSERT_HEAD(_disklist, di, list);
else
TAILQ_INSERT_TAIL(_disklist, di, list);
+
+   printf("%d\n", i);
+   for (; !IsDevicePathEnd(dp); dp = NextDevicePathNode(dp)) {
+   int ii;
+   for (ii = 0; ii < DevicePathNodeLength(dp); ii++)
+   printf("%x ", *((u_char *)dp + ii));
+   printf("\n");
+   }
}
 
free(handles, sz);

Re: OpenBSD 6.1: BOOTIA32 3.32 issue

[Michele Curti]

On Wed, May 10, 2017 at 08:35:28PM +0200, Patrick Wildt wrote:
> 
> I don't think this is the correct fix.  It might solve your issue, but I
> don't think it's completely right.  So EFI has those so called device
> paths.  A path is basically a list of nodes.  To compare two paths you
> need to compare the whole path and not just a single node of it.  If you
> store dp instead of dp0 you will basically only save a part of the path,
> not the full path.
> 
> What you can do is print the full path of efi_bootdp like..
> 
> for (dp = efi_bootdp; !IsDevicePathEnd(dp);
> dp = NextDevicePathNode(dp)) {
> printf("%x %x - ", DevicePathType(dp), DevicePathSubType(dp));
> }
> printf("\n");
> 
> And do the same for the DPs that are being put into the
> efi_device_path_cmp function.  That will at least print the types, but
> not the content of the nodes.  That's a start into figuring out why it
> does not correctly compare the paths.
> 
> Maybe there's a bug in the compare code?

Sorry, only now I understood what you said... Got

2 1 - 1 1 - 1 5 - 4 1 -

(2 1) (2 1) da db cmp da db cmp diff bootdev 1
(2 1) (2 1) da db cmp da db cmp diff bootdev 1
(2 1) (2 1) da db cmp da db cmp diff bootdev 1

with the following diff


Index: efiboot/efiboot.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
retrieving revision 1.17
diff -u -p -r1.17 efiboot.c
--- efiboot/efiboot.c   3 Mar 2017 08:56:18 -   1.17
+++ efiboot/efiboot.c   11 May 2017 21:39:14 -
@@ -89,6 +89,8 @@ efi_main(EFI_HANDLE image, EFI_SYSTEM_TA
if (status == EFI_SUCCESS) {
for (dp = dp0; !IsDevicePathEnd(dp);
dp = NextDevicePathNode(dp)) {
+   printf("%x %x - ", DevicePathType(dp),
+   DevicePathSubType(dp));
if (DevicePathType(dp) == MEDIA_DEVICE_PATH &&
DevicePathSubType(dp) == MEDIA_HARDDRIVE_DP) {
bios_bootdev = 0x80;
@@ -96,6 +98,7 @@ efi_main(EFI_HANDLE image, EFI_SYSTEM_TA
break;
}
}
+   printf("\n");
}
 
 #ifdef __amd64__
@@ -199,10 +202,18 @@ efi_diskprobe(void)
(void **));
if (EFI_ERROR(status))
goto next;
+   printf("(%x %x) (%x %x) ",
+   DevicePathType(efi_bootdp),
+   DevicePathSubType(efi_bootdp),
+   DevicePathType(dp),
+   DevicePathSubType(dp)
+   );
if (!efi_device_path_cmp(efi_bootdp, dp, HARDWARE_DEVICE_PATH)&&
!efi_device_path_cmp(efi_bootdp, dp, ACPI_DEVICE_PATH) &&
!efi_device_path_cmp(efi_bootdp, dp, MESSAGING_DEVICE_PATH))
bootdev = 1;
+
+   printf("bootdev %d\n", bootdev);
 next:
if (bootdev)
TAILQ_INSERT_HEAD(_disklist, di, list);
@@ -222,12 +233,14 @@ efi_device_path_cmp(EFI_DEVICE_PATH *dpa
for (dp = dpa; !IsDevicePathEnd(dp); dp = NextDevicePathNode(dp)) {
if (DevicePathType(dp) == dptype) {
dpt_a = dp;
+   printf("da ");
break;
}
}
for (dp = dpb; !IsDevicePathEnd(dp); dp = NextDevicePathNode(dp)) {
if (DevicePathType(dp) == dptype) {
dpt_b = dp;
+   printf("db ");
break;
}
}
@@ -236,8 +249,11 @@ efi_device_path_cmp(EFI_DEVICE_PATH *dpa
cmp = DevicePathNodeLength(dpt_a) - DevicePathNodeLength(dpt_b);
if (cmp)
return (cmp);
+   printf("cmp ");
return (memcmp(dpt_a, dpt_b, DevicePathNodeLength(dpt_a)));
}
+
+   printf("diff ");
 
return ((uintptr_t)dpt_a - (uintptr_t)dpt_b);
 }

Re: Status of OpenCVS

[Ingo Schwarze]

Hi,

multiplex'd wrote on Thu, May 11, 2017 at 04:48:36PM +0100:

> I recently stumbled across the OpenCVS webpages and I was wondering
> what the status of the project is.

It is dormant.  While it is *almost* ready for production,
actually trying to use it in production revealed instabilities
that were non-trivial to debug, and nobody did the work to get
if from "almost ready" to "reliable".  Nobody can predict how
much work that would require.  If somebody seriously tried,
it might get done in a month, or take a year, or fail completely.

It is not typical for OpenBSD projects that they go dormant
shortly before being ready for production, but this is one of the
sad cases where that did happen.

> The webpage says that it is to be released soon,
> however commits to the CVS tree seem to be few and far between.
> Is the codebase in a state where it could be ported to other
> operating systems yet?

Porting OpenBSD userland code to other operating systems (that are
reasonably similar to POSIX) is in general not a big problem if you
follow the practices established by OpenSSH and mandoc and LibreSSL,
unless that code heavily relies on special OpenBSD kernel facilities,
which certainly isn't the case here.

You can certainly port it and run it elsewhere.  But i wouldn't
expect it to be more stable than on OpenBSD, so using it to manage
important data is risky, unless you pay very close attention and
are prepared to fix non-trivial bugs yourself (and send patches).

Yours,
  Ingo

Re: Compaq nx6310 does not suspend/resume

[Mike Larkin]

On Thu, May 11, 2017 at 01:50:58PM +0200, Jan Stary wrote:
> On May 10 14:28:16, mlar...@azathoth.net wrote:
> > On Wed, May 10, 2017 at 05:19:04PM +0200, Jan Stary wrote:
> > > This is current/i386 on a Compaq nx6310 laptop (dmesg below).
> > 
> > This machine is notoriously bad. Did this ever work for you?
> 
> I just got the machine, so this is a first install on it.
> 

This particular model and a few like it have never worked well. And if it's
the same one I'm thinking about, it doesn't resume properly in Linux either
(could be wrong).

I'd say just use ZZZ. None of the developers has one of these anymore as
far as I know, so any debugging would be difficult. I posted a message to
tech or misc last year about how to troubleshoot resume issues, if you want
to dig into it yourself. Follow those troubleshooting steps and come back when
you've found the device or operation that is hanging the resume.

-ml

> > 
> > > Mostly works, but I experience trouble with suspend/resume.
> > > 
> > > apmd(8) is running with apmd_flags="-A", but closing the lid does nothing,
> > > eventhough machdep.lidsuspend=1 and machdep.lidaction=1
> > > Trying to suspend manually with Fn+F3 does nothing as well.
> > > Trying to suspend with apm(8)'s options does this:
> > > 
> > > apm -S says
> > > 
> > >   May 10 16:12:32 hp apmd: system entering standby
> > >   May 10 16:12:33 hp /bsd: uhub1 detached
> > >   May 10 16:12:33 hp /bsd: uhub2 detached
> > >   May 10 16:12:33 hp /bsd: uhub3 detached
> > > 
> > > and, presumably, goes into standby. The power led is blinking.
> > > It will not resume: pressing the power button makes the power led
> > > light up again, but that's it. Even the display backlight
> > > stays turned off. The machine is not accessible remotely
> > > and needs to be forcefully restarted.
> > > /etc/apm/standby does not get called.
> > > 
> > > apm -z says
> > > 
> > >   May 10 16:31:26 hp apmd: system suspending
> > >   May 10 16:31:28 hp /bsd: uhub1 detached
> > >   May 10 16:31:28 hp /bsd: uhub2 detached
> > >   May 10 16:31:28 hp /bsd: uhub3 detached
> > > 
> > > and, presumably, goes to suspend, but never resumes.
> > > The symptoms are the same as with apm -S.
> > > /etc/apm/suspend does not get called.
> > > 
> > > apm -Z puts the system into hibernation, and it works.
> > > After pressing the power button, the machine boots,
> > > and unhibernates at the end of the boot sequence.
> > > /etc/apm/{hibernate,resume} get called.
> > > 
> > > How can I help debug this?
> > > 
> > > http://stare.cz/dmesg/compaq-nx6310.20170509
> > > http://stare.cz/dmesg/compaq-nx6310.acpidump.tar
> > > http://stare.cz/dmesg/compaq-nx6310.pcidump
> > > 
> > >   Jan
> > > 
> > > 
> > > OpenBSD 6.1-current (GENERIC) #0: Tue May  9 17:46:04 CEST 2017
> > > h...@hp.stare.cz:/usr/src/sys/arch/i386/compile/GENERIC
> > > cpu0: Intel(R) Celeron(R) M CPU 430 @ 1.73GHz ("GenuineIntel" 686-class) 
> > > 1.73 GHz
> > > cpu0: 
> > > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,NXE,SSE3,MWAIT,TM2,xTPR,PDCM,PERF,SENSOR
> > > real mem  = 1601519616 (1527MB)
> > > avail mem = 1558122496 (1485MB)
> > > mpath0 at root
> > > scsibus0 at mpath0: 256 targets
> > > mainbus0 at root
> > > bios0 at mainbus0: date 04/17/07, BIOS32 rev. 0 @ 0xf, SMBIOS rev. 
> > > 2.4 @ 0xf38eb (23 entries)
> > > bios0: vendor Hewlett-Packard version "68YDU Ver. F.0D" date 04/17/2007
> > > bios0: Hewlett-Packard 30AA
> > > acpi0 at bios0: rev 2
> > > acpi0: sleep states S0 S3 S4 S5
> > > acpi0: tables DSDT FACP SLIC HPET APIC MCFG TCPA SSDT SSDT SSDT SSDT
> > > acpi0: wakeup devices C096(S5) C0F1(S3) C0F8(S3) C0F9(S3) C0FA(S3) 
> > > C0FB(S3) C102(S5) C22B(S5) C115(S5) C22C(S5) C118(S5) C22C(S5)
> > > acpitimer0 at acpi0: 3579545 Hz, 24 bits
> > > acpihpet0 at acpi0: 14318179 Hz
> > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > > cpu0 at mainbus0: apid 0 (boot processor)
> > > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> > > cpu0: apic clock running at 132MHz
> > > cpu0: mwait min=64, max=64, C-substates=0.1.1.1, IBE
> > > ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
> > > acpimcfg0 at acpi0 addr 0xf800, bus 0-63
> > > acpiprt0 at acpi0: bus 2 (C096)
> > > acpiprt1 at acpi0: bus 8 (C102)
> > > acpiprt2 at acpi0: bus 24 (C115)
> > > acpiprt3 at acpi0: bus 32 (C118)
> > > acpiprt4 at acpi0: bus 0 (C002)
> > > acpiec0 at acpi0
> > > acpicpu0 at acpi0: !C3(250@17 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1 
> > > halt)
> > > acpipwrres0 at acpi0: C1F0, resource for C1EC
> > > acpipwrres1 at acpi0: C1FD, resource for C1F1
> > > acpipwrres2 at acpi0: C21A, resource for C218
> > > acpipwrres3 at acpi0: C222, resource for C121
> > > acpipwrres4 at acpi0: C321, resource for C325
> > > acpipwrres5 at acpi0: C322, resource for C326
> > > acpipwrres6 at acpi0: C323, resource for C327
> > > acpipwrres7 at acpi0: C324, resource for C328
> > > acpitz0 at acpi0: 

Re: What does it mean this error when I try install a package?

[Stuart Henderson]

On 2017-05-11, Ajitabh Pandey  wrote:
> I got a similar message when I try to install python, but upong
> investigating I realise that python was already installed - perhaps as a
> pre-requisite for glib2. I am not using PKG_PATH, rather I use
> /etc/installurl for specifying a list of my mirrors (man installurl(5) for
> details)

/etc/installurl is for specifying a *single* mirror, not a list. As the
manual says, "The /etc/installurl file contains a single line specifying
an OpenBSD mirror..."

> $ doas pkg_add python-2.7.13p0
> quirks-2.304 signed on 2017-04-02T15:01:33Z
> https://ftp.openbsd.org/pub/OpenBSD/6.1/packages-stable/amd64/python-2.7.13p0.tgz:
> ftp: Error retrieving file: 404 Not Found
> signify: gzheader truncated

Error text could be improved, but this error is occurring because you
have specified a full package name including version, and that doesn't
exist (in 6.1, it's 2.7.13p1).

I suggest either "pkg_add python%2.7" as shown in the pkg_add(1) manual,
or just "pkg_add python" and choose from the list.

> For a very long time I was trying to understand why pkg_add is looking for
> package in packages-stable directory when this directory does not exists on
> any of the mirrors. I checked the standard directory paths for mirror on
> OpenBSD website and this directory was not there also.
> 
> Can someone help me understand why it is so, or point to some relevant
> document.

/packages-stable *might* be used sometime in the future.

> Also, I had to run the following commands as recommended by pkg_info python
> 
> $ doas ln -sf /usr/local/bin/python2.7 /usr/local/bin/python
> $ doas ln -sf /usr/local/bin/python2.7-2to3 /usr/local/bin/2to3
> $ doas ln -sf /usr/local/bin/python2.7-config /usr/local/bin/python-config
> $ doas ln -sf /usr/local/bin/pydoc2.7  /usr/local/bin/pydoc
>
> Do we have any alternatives management system in OpenBSD like we have in
> linux or this has to be done by hand.

You don't have to do this, nothing in packages expects this, they look for
the full name including version. It's only needed if you have programs
from another source that expect to have the symlinks.

Status of OpenCVS

[multiplex'd]

Hello all,

I recently stumbled across the OpenCVS webpages and I was wondering what the
status of the project is. The webpage says that it is to be released soon,
however commits to the CVS tree seem to be few and far between. Is the codebase
in a state where it could be ported to other operating systems yet?

Thanks,
multiplex'd

Re: What does it mean this error when I try install a package?

[Ron Georgia]

Ajitabh,
Could you copy and paste the /etc/installurl here? I can try to do the same 
thing on my PC to see if I get the same error.
Normally I simply pkg_add python, then pick the version I want to install, as 
was already suggested. I run python 2.7 and 3.6 on all my machines. I typically 
do not follow the suggestion from the pkg_info exactly. I usually create a 
/usr/local/bin/python2 and python3 to cover my pythonic cravings. Actually, the 
best way to develop using python is to use their virtual environment. My 
experience is that OpenBSD has provided an excellent platform for your python 
development experience.
I know I did not explain ‘why’ you could not install python-2.7.13p0.tgz, but 
hopefully you have enough to install and start coding. Love python. 

> On May 11, 2017, at 4:46 AM, Ajitabh Pandey  wrote:
> 
> Hi,
> 
> I got a similar message when I try to install python, but upong
> investigating I realise that python was already installed - perhaps as a
> pre-requisite for glib2. I am not using PKG_PATH, rather I use
> /etc/installurl for specifying a list of my mirrors (man installurl(5) for
> details)
> 
> $ doas pkg_add python-2.7.13p0
> quirks-2.304 signed on 2017-04-02T15:01:33Z
> https://ftp.openbsd.org/pub/OpenBSD/6.1/packages-stable/amd64/python-2.7.13p0.tgz:
> ftp: Error retrieving file: 404 Not Found
> signify: gzheader truncated
> 
> For a very long time I was trying to understand why pkg_add is looking for
> package in packages-stable directory when this directory does not exists on
> any of the mirrors. I checked the standard directory paths for mirror on
> OpenBSD website and this directory was not there also.
> 
> Can someone help me understand why it is so, or point to some relevant
> document.
> 
> Also, I had to run the following commands as recommended by pkg_info python
> 
> $ doas ln -sf /usr/local/bin/python2.7 /usr/local/bin/python
> $ doas ln -sf /usr/local/bin/python2.7-2to3 /usr/local/bin/2to3
> $ doas ln -sf /usr/local/bin/python2.7-config /usr/local/bin/python-config
> $ doas ln -sf /usr/local/bin/pydoc2.7  /usr/local/bin/pydoc
> 
> Do we have any alternatives management system in OpenBSD like we have in
> linux or this has to be done by hand.
> 
> Regards.
> --
> ~ajitabhpandey
> 
> On Mon, Apr 17, 2017 at 5:57 PM, Jiri B  wrote:
> 
>> On Mon, Apr 17, 2017 at 09:37:56PM +1000, Steven McDonald wrote:
>>> On Mon, 17 Apr 2017 11:02:37 +
>>> "C. L. Martinez"  wrote:
>>> 
 pkg_add -v python-2.7
>>> 
>>> There is no package called python-2.7. The package you want is called
>>> python-2.7.13p0. You have a few options:
>>> 
>>> 1. pkg_add python, then select the version you want.
>>> 2. pkg_add python-2.7.13p0
>>> 3. pkg_add -z python-2.7 (fuzzy matching, see pkg_add(1))
>> 
>>  ^ or use 'python%2.7'
>> 
>> j.
>> 
>> 
> 
> 
> -- 
> Ajitabh Pandey
> http://ajitabhpandey.info/ | http://unixclinic.net/ |
> http://buddingthoughts.info
> ICQ - 150615062
> Registered Linux User - 240748

Re: OpenBSD 6.1: BOOTIA32 3.32 issue

[Michele Curti]

On Thu, May 11, 2017 at 05:48:34PM +0900, YASUOKA Masahiko wrote:
> Hi,
> 
> Thank you for your tests,
> 
> On Thu, 11 May 2017 07:40:42 +0200
> 
...
> > So I can use the stock bootloader without changes but I must do a 
> > 
> > boot> set device hd2a
> 
> I'm not clear whether we still have a problem.
> 
> Does the boot loader select the booted disk as "hd0" correctly?
> 
> If you booted from 29GB disk, "machine diskinfo" must be:
> 
>   DiskBlkSiz  IoAlign SizeFlags   Checksum
>   hd0 512 1   29GB0x2 0xad4a42c3
>   hd1 512 1   4MB 0x0 0x0
>   hd2 512 1   4MB 0x0 0x0
>

There is still a problem because I booted from the 29GB disk, the 
bootloader selects hd0, but the machine diskinfo order is:
DiskBlkSiz  IoAlign SizeFlags   Checksum
hd0 512 1   4MB 0x0 0x0
hd1 512 1   4MB 0x0 0x0
hd2 512 1   29GB0x2 0xad4a42c3

I don't know if it is related but a problem is probably 
(efiboot.c, line 87) here:
status = EFI_CALL(BS->HandleProtocol, imgp->DeviceHandle,
_guid, (void **));

where status is EFI_SUCCESS but dp0 remains NULL, so the following 
for loop loops through invalid device paths until a causal 
IsDevicePathEnd() true.

I not sure of what I'm saying because I have not investigated yet, 
I have to read some EFI documentation first to understand what's 
happening.


Thank you for the help,
Michele
 
> --yasuoka

Re: smtpd aliases file issue

[Edgar Pettijohn]

Just for the record using a flat "file" for aliases you don't need to run 
newaliases.

⁣Sent from BlueMail ​

On May 11, 2017, 2:30 AM, at 2:30 AM, Gilles Chehade  wrote:
>Much better :-)
>
>You don’t need to restart the daemon, you simply need to tell it
>through smtpctl that the table aliases needs to be reloaded:
>
>   $ doas smtpctl update table aliases
>
>Gilles
>
>
>> On 11 May 2017, at 08:17, Ajitabh Pandey 
>wrote:
>>
>> Hi Gilles,
>>
>> I did not change anything from the default. But I realise all may not
>be
>> using default file like me and may not know what is in it. Here is a
>copy
>> of the contents just for reference. The problem is solved by
>restarting the
>> smtpd as sugested by Edgar.
>>
>> $ doas cat /etc/mail/smtpd.conf
>>
>> table aliases file:/etc/mail/aliases
>> listen on lo0
>> accept for local alias  deliver to mbox
>> accept from local for any relay
>>
>> Regards.
>> --
>> ~ajitabhpandey
>>
>> On Wed, May 10, 2017 at 5:25 PM, Gilles Chehade 
>wrote:
>>
>>> On Wed, May 10, 2017 at 04:32:55PM +0530, Ajitabh Pandey wrote:

 If my understanding about how this should work incorrect? If not
>then
>>> what
 am I doing wrong?

>>>
>>> What you are doing wrong is not showing your configuration file so
>we're
>>> able to check if it does what you think it is doing
>>>
>>>
>>> --
>>> Gilles Chehade
>>>
>>> https://www.poolp.org
>@poolpOrg
>>>
>>
>>
>>
>> --
>> Ajitabh Pandey
>> http://ajitabhpandey.info/ | http://unixclinic.net/ |
>> http://buddingthoughts.info
>> ICQ - 150615062
>> Registered Linux User - 240748

Re: Compaq nx6310 does not suspend/resume

[Jan Stary]

On May 10 14:28:16, mlar...@azathoth.net wrote:
> On Wed, May 10, 2017 at 05:19:04PM +0200, Jan Stary wrote:
> > This is current/i386 on a Compaq nx6310 laptop (dmesg below).
> 
> This machine is notoriously bad. Did this ever work for you?

I just got the machine, so this is a first install on it.

> 
> > Mostly works, but I experience trouble with suspend/resume.
> > 
> > apmd(8) is running with apmd_flags="-A", but closing the lid does nothing,
> > eventhough machdep.lidsuspend=1 and machdep.lidaction=1
> > Trying to suspend manually with Fn+F3 does nothing as well.
> > Trying to suspend with apm(8)'s options does this:
> > 
> > apm -S says
> > 
> > May 10 16:12:32 hp apmd: system entering standby
> > May 10 16:12:33 hp /bsd: uhub1 detached
> > May 10 16:12:33 hp /bsd: uhub2 detached
> > May 10 16:12:33 hp /bsd: uhub3 detached
> > 
> > and, presumably, goes into standby. The power led is blinking.
> > It will not resume: pressing the power button makes the power led
> > light up again, but that's it. Even the display backlight
> > stays turned off. The machine is not accessible remotely
> > and needs to be forcefully restarted.
> > /etc/apm/standby does not get called.
> > 
> > apm -z says
> > 
> > May 10 16:31:26 hp apmd: system suspending
> > May 10 16:31:28 hp /bsd: uhub1 detached
> > May 10 16:31:28 hp /bsd: uhub2 detached
> > May 10 16:31:28 hp /bsd: uhub3 detached
> > 
> > and, presumably, goes to suspend, but never resumes.
> > The symptoms are the same as with apm -S.
> > /etc/apm/suspend does not get called.
> > 
> > apm -Z puts the system into hibernation, and it works.
> > After pressing the power button, the machine boots,
> > and unhibernates at the end of the boot sequence.
> > /etc/apm/{hibernate,resume} get called.
> > 
> > How can I help debug this?
> > 
> > http://stare.cz/dmesg/compaq-nx6310.20170509
> > http://stare.cz/dmesg/compaq-nx6310.acpidump.tar
> > http://stare.cz/dmesg/compaq-nx6310.pcidump
> > 
> > Jan
> > 
> > 
> > OpenBSD 6.1-current (GENERIC) #0: Tue May  9 17:46:04 CEST 2017
> > h...@hp.stare.cz:/usr/src/sys/arch/i386/compile/GENERIC
> > cpu0: Intel(R) Celeron(R) M CPU 430 @ 1.73GHz ("GenuineIntel" 686-class) 
> > 1.73 GHz
> > cpu0: 
> > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,NXE,SSE3,MWAIT,TM2,xTPR,PDCM,PERF,SENSOR
> > real mem  = 1601519616 (1527MB)
> > avail mem = 1558122496 (1485MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: date 04/17/07, BIOS32 rev. 0 @ 0xf, SMBIOS rev. 2.4 
> > @ 0xf38eb (23 entries)
> > bios0: vendor Hewlett-Packard version "68YDU Ver. F.0D" date 04/17/2007
> > bios0: Hewlett-Packard 30AA
> > acpi0 at bios0: rev 2
> > acpi0: sleep states S0 S3 S4 S5
> > acpi0: tables DSDT FACP SLIC HPET APIC MCFG TCPA SSDT SSDT SSDT SSDT
> > acpi0: wakeup devices C096(S5) C0F1(S3) C0F8(S3) C0F9(S3) C0FA(S3) C0FB(S3) 
> > C102(S5) C22B(S5) C115(S5) C22C(S5) C118(S5) C22C(S5)
> > acpitimer0 at acpi0: 3579545 Hz, 24 bits
> > acpihpet0 at acpi0: 14318179 Hz
> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> > cpu0: apic clock running at 132MHz
> > cpu0: mwait min=64, max=64, C-substates=0.1.1.1, IBE
> > ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
> > acpimcfg0 at acpi0 addr 0xf800, bus 0-63
> > acpiprt0 at acpi0: bus 2 (C096)
> > acpiprt1 at acpi0: bus 8 (C102)
> > acpiprt2 at acpi0: bus 24 (C115)
> > acpiprt3 at acpi0: bus 32 (C118)
> > acpiprt4 at acpi0: bus 0 (C002)
> > acpiec0 at acpi0
> > acpicpu0 at acpi0: !C3(250@17 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1 
> > halt)
> > acpipwrres0 at acpi0: C1F0, resource for C1EC
> > acpipwrres1 at acpi0: C1FD, resource for C1F1
> > acpipwrres2 at acpi0: C21A, resource for C218
> > acpipwrres3 at acpi0: C222, resource for C121
> > acpipwrres4 at acpi0: C321, resource for C325
> > acpipwrres5 at acpi0: C322, resource for C326
> > acpipwrres6 at acpi0: C323, resource for C327
> > acpipwrres7 at acpi0: C324, resource for C328
> > acpitz0 at acpi0: critical temperature is 256 degC
> > acpitz1 at acpi0: critical temperature is 105 degC
> > acpitz2 at acpi0: critical temperature is 105 degC
> > acpitz3 at acpi0: critical temperature is 105 degC
> > acpitz4 at acpi0: critical temperature is 110 degC
> > "PNP0A06" at acpi0 not configured
> > "PNP0303" at acpi0 not configured
> > "SYN0112" at acpi0 not configured
> > "HPQ0006" at acpi0 not configured
> > acpibat0 at acpi0: C1BC model "Primary" serial 08083 2016/11/05 type LIon 
> > oem "Hewlett-Packard"
> > acpibat1 at acpi0: C1BB not present
> > acpiac0 at acpi0: AC unit online
> > acpibtn0 at acpi0: C23F
> > acpibtn1 at acpi0: C238
> > "PNP0C14" at acpi0 not configured
> > "PNP0C0B" at acpi0 not configured
> > "PNP0C0B" at acpi0 not configured
> > "PNP0C0B" at acpi0 not 

Re: smtpd aliases file issue

[Ajitabh Pandey]

Thanks Giles.

Regards.
-- 
~ajitabhpandey

On Thu, May 11, 2017 at 12:59 PM, Gilles Chehade  wrote:

> Much better :-)
>
> You don’t need to restart the daemon, you simply need to tell it through
> smtpctl that the table aliases needs to be reloaded:
>
> $ doas smtpctl update table aliases
>
> Gilles
>
>
> > On 11 May 2017, at 08:17, Ajitabh Pandey 
> wrote:
> >
> > Hi Gilles,
> >
> > I did not change anything from the default. But I realise all may not be
> > using default file like me and may not know what is in it. Here is a copy
> > of the contents just for reference. The problem is solved by restarting
> the
> > smtpd as sugested by Edgar.
> >
> > $ doas cat /etc/mail/smtpd.conf
> >
> > table aliases file:/etc/mail/aliases
> > listen on lo0
> > accept for local alias  deliver to mbox
> > accept from local for any relay
> >
> > Regards.
> > --
> > ~ajitabhpandey
> >
> > On Wed, May 10, 2017 at 5:25 PM, Gilles Chehade 
> wrote:
> >
> >> On Wed, May 10, 2017 at 04:32:55PM +0530, Ajitabh Pandey wrote:
> >>>
> >>> If my understanding about how this should work incorrect? If not then
> >> what
> >>> am I doing wrong?
> >>>
> >>
> >> What you are doing wrong is not showing your configuration file so we're
> >> able to check if it does what you think it is doing
> >>
> >>
> >> --
> >> Gilles Chehade
> >>
> >> https://www.poolp.org
> @poolpOrg
> >>
> >
> >
> >
> > --
> > Ajitabh Pandey
> > http://ajitabhpandey.info/ | http://unixclinic.net/ |
> > http://buddingthoughts.info
> > ICQ - 150615062
> > Registered Linux User - 240748
>
>


-- 
Ajitabh Pandey
http://ajitabhpandey.info/ | http://unixclinic.net/ |
http://buddingthoughts.info
ICQ - 150615062
Registered Linux User - 240748

[solved] Re: build amd64 kernel fails

[Heiko]

That works. Thank you :)

Am 11.05.2017 um 10:08 schrieb Theo Buehler:
> On Thu, May 11, 2017 at 10:04:42AM +0200, Heiko Zimmermann wrote:
>> Hello Theo,
>>
>> Am 11.05.2017 um 09:58 schrieb Theo Buehler:
>>> On Thu, May 11, 2017 at 09:18:05AM +0200, Heiko wrote:
 Hello List,

 I get this error:

 uvm_init.o: In function `uvm_init':
 /sys/uvm/uvm_init.c:145: undefined reference to `uvm_km_page_lateinit'
 *** Error 1 in /sys/arch/amd64/compile/GENERIC.MP (Makefile:869 'bsd':
 @echo ld -T /sys/arch/amd64/conf/ld.script -X --warn-common -nopie -o...)
 cmp -s bsd /bsd || ln -f /bsd /obsd
 cp bsd /nbsd
 cp: bsd: No such file or directory
 *** Error 1 in /sys/arch/amd64/compile/GENERIC.MP

>>>
>>> Make sure you have /sys/uvm/uvm_km.c r1.130 before you try again.
>>>
>>
>> There is this file:
>>
>> /usr/src/sys/uvm/uvm_km.c
>> /*  $OpenBSD: uvm_km.c,v 1.129 2017/05/11 00:42:05 dlg Exp $
>>
>> How can I get r1.130 ?
> 
> Your cvs mirror probably hasn't synced yet (they usually do every hour
> or every 2 hours). It's on cvsweb already:
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/uvm/uvm_km.c
> 

Re: OpenBSD 6.1: BOOTIA32 3.32 issue

[YASUOKA Masahiko]

Hi,

Thank you for your tests,

On Thu, 11 May 2017 07:40:42 +0200
Michele Curti  wrote:
> On Wed, May 10, 2017 at 08:35:28PM +0200, Patrick Wildt wrote:
>> On Wed, May 10, 2017 at 03:14:30PM +0200, Stefan Sperling wrote:
>> > On Tue, May 09, 2017 at 09:47:14PM +0200, Michele Curti wrote:
>> > > On Tue, May 09, 2017 at 09:36:02PM +0200, Michele Curti wrote:
>> > > > On Tue, May 09, 2017 at 10:20:03AM +0200, Michele Curti wrote:
>> > > > > Hi all, I tried to upgrade to OpenBSD 6.1 on an Asus X205TA (bay
>> > > > > trail, 32 bit efi, 64 bit os) but the bootloader do not correctly
>> > > > > detect the internal disk.
>> > > > > 
>> > > > > I also tried a fresh install, but things do not change.  Boot fails
>> > > > > and when I do a "machine diskinfo" I got a lot of "?" symbols (a 
>> > > > > video
>> > > > > here https://www.youtube.com/watch?v=fsomNX-oFTQ )
>> > > > > 
> 
> Thanks to yasuoka fix I just noted that using dp0 instead of dp 
> changes the diskinfo disks order

Yes,

> # setting efi_bootdp = dp;
> 
> Disk  BlkSiz  IoAlign SizeFlags   Checksum
> hd0   512 1   29GB0x2 0xad4a42c3
> hd1   512 1   4MB 0x0 0x0
> hd2   512 1   4MB 0x0 0x0
> 
> # setting efi_bootdp = dp0;
> 
> Disk  BlkSiz  IoAlign SizeFlags   Checksum
> hd0   512 1   4MB 0x0 0x0
> hd1   512 1   4MB 0x0 0x0
> hd2   512 1   29GB0x2 0xad4a42c3
> 
> So I can use the stock bootloader without changes but I must do a 
> 
> boot> set device hd2a

I'm not clear whether we still have a problem.

Does the boot loader select the booted disk as "hd0" correctly?

If you booted from 29GB disk, "machine diskinfo" must be:

  Disk  BlkSiz  IoAlign SizeFlags   Checksum
  hd0   512 1   29GB0x2 0xad4a42c3
  hd1   512 1   4MB 0x0 0x0
  hd2   512 1   4MB 0x0 0x0

--yasuoka

Re: What does it mean this error when I try install a package?

[Ajitabh Pandey]

Hi,

I got a similar message when I try to install python, but upong
investigating I realise that python was already installed - perhaps as a
pre-requisite for glib2. I am not using PKG_PATH, rather I use
/etc/installurl for specifying a list of my mirrors (man installurl(5) for
details)

$ doas pkg_add python-2.7.13p0
quirks-2.304 signed on 2017-04-02T15:01:33Z
https://ftp.openbsd.org/pub/OpenBSD/6.1/packages-stable/amd64/python-2.7.13p0.tgz:
ftp: Error retrieving file: 404 Not Found
signify: gzheader truncated

For a very long time I was trying to understand why pkg_add is looking for
package in packages-stable directory when this directory does not exists on
any of the mirrors. I checked the standard directory paths for mirror on
OpenBSD website and this directory was not there also.

Can someone help me understand why it is so, or point to some relevant
document.

Also, I had to run the following commands as recommended by pkg_info python

$ doas ln -sf /usr/local/bin/python2.7 /usr/local/bin/python
$ doas ln -sf /usr/local/bin/python2.7-2to3 /usr/local/bin/2to3
$ doas ln -sf /usr/local/bin/python2.7-config /usr/local/bin/python-config
$ doas ln -sf /usr/local/bin/pydoc2.7  /usr/local/bin/pydoc

Do we have any alternatives management system in OpenBSD like we have in
linux or this has to be done by hand.

Regards.
--
~ajitabhpandey

On Mon, Apr 17, 2017 at 5:57 PM, Jiri B  wrote:

> On Mon, Apr 17, 2017 at 09:37:56PM +1000, Steven McDonald wrote:
> > On Mon, 17 Apr 2017 11:02:37 +
> > "C. L. Martinez"  wrote:
> >
> > > pkg_add -v python-2.7
> >
> > There is no package called python-2.7. The package you want is called
> > python-2.7.13p0. You have a few options:
> >
> >  1. pkg_add python, then select the version you want.
> >  2. pkg_add python-2.7.13p0
> >  3. pkg_add -z python-2.7 (fuzzy matching, see pkg_add(1))
>
>   ^ or use 'python%2.7'
>
> j.
>
>


-- 
Ajitabh Pandey
http://ajitabhpandey.info/ | http://unixclinic.net/ |
http://buddingthoughts.info
ICQ - 150615062
Registered Linux User - 240748

pf: pfi_kif_unref: rules refcount <= 0

[Comète]

Hi,

I run OpenBSD 6.0 GENERIC.MP#4 amd64 on a firewall and I recently discovered 
lots of these messages in
dmesg:

pf: pfi_kif_unref: rules refcount <= 0

do you know what it is ?

Thanks

Morgan

Re: strange behaviour with etherip bridge over IPSEC and UDP queries

[Comète]

28 mars 2017 16:40 "Scott Bonds"  a écrit:

> Interesting. I may have a similar problem and was planning to post about it 
> soon...in my case I've
> been playing with rdomains, using PF to NAT
> between them, and ikedv2. I've found that when I use ikedv2 to layer IPSEC on 
> top of my NATing
> traffic between rdomains, TCP passes fine, UDP does not, though I can see 
> requests and replies
> moving across enc0 (DNS requests that show the answer in the tcpdump output). 
> So, host -T
> google.com 8.8.8.8 (TCP DNS lookup) works but host google.com 8.8.8.8 (UDP 
> DNS lookup) does not.
> 
> On 03/28, Comète wrote:
> 
>> Hi,
>> 
>> I'm trying to build an IPSEC encrypted tunnel that works as a bridge. For
>> this, I use isakmpd and etherip, vether, bridge interfaces. On each VPN 
>> server
>> (Host A and B), I've got PF running on the external interface (em2). Both
>> hosts run OpenBSD 6.0 stable amd64.
>> Host A is my main server and host B is the
>> client.
>> 
>> Now the strange part:
>> 
>> - If PF is running on each host (A and B),
>> UDP queries from B to A network don't work (UDP only, TCP is ok. But I can 
>> see
>> UDP packets with tcpdump going from B to A and coming back but they don't go
>> out from the interface)
>> 
>> - I disable PF on Host B only with "rcctl disable pf
>> && reboot", all is working after reboot, all queries (dns, ntp...) are well
>> sent from B to A through the VPN. Now, I enable PF again without rebooting
>> with "pfctl -e && pfctl -f /etc/pf.conf" and it's still working. Then I start
>> "rcctl enable pf" and reboot, and it doesn't work anymore for UDP queries...
>> So to resume, if PF is started automatically at boot on host B (rcctl enable
>> pf) then UDP don't pass but if I start it manually (pfctl -e && pfctl -f
>> /etc/pf.conf), it works.
>> 
>> I've tried tcpdump -nettti pflog0 during DNS/NTP
>> queries but I don't see anything blocked. As I said, if I try tcpdump -nettti
>> em0 I can even see the answer from the DNS server coming back but dig doesn't
>> get it.
>> 
>> I just don't understand why my UDP packets don't pass, so if you have
>> a idea, you're welcome ;)
>> 
>> thanks.
>> 
>> This my setup on Host B (Host A is
>> similar)
>> 
>> ipsec.conf:
>> ---
>> 
>> ike active esp proto etherip from $local_gw
>> to $remote_gw \
>> main auth "hmac-sha1" enc "aes-128" group modp2048
>> lifetime 1800 \
>> quick enc "aes-128-gcm" group modp2048 lifetime 1200 \
>> srcid $local_gw
>> 
>> ipsecctl -sa
>> ---
>> ipsecctl -sa
>> FLOWS:
>> flow esp in
>> proto etherip from 10.65.12.10 to 10.65.13.10 peer 10.65.12.10 srcid
>> 10.65.13.10/32 dstid 10.65.12.10/32 type use
>> flow esp out proto etherip from
>> 10.65.13.10 to 10.65.12.10 peer 10.65.12.10 srcid 10.65.13.10/32 dstid
>> 10.65.12.10/32 type require
>> 
>> SAD:
>> esp tunnel from 10.65.13.10 to 10.65.12.10
>> spi 0xd5acc570 enc aes-128-gcm
>> esp tunnel from 10.65.12.10 to 10.65.13.10 spi
>> 0xe19efd9f enc aes-128-gcm
>> 
>> pf.conf:
>> 
>> ext_if = "em2"
>> int_if =
>> "internal"
>> 
>> match in all scrub (no-df random-id max-mss 1200)
>> antispoof for {
>> $ext_if, $int_if } inet
>> set skip on { lo, enc, $int_if }
>> set loginterface
>> $ext_if
>> match out on $ext_if from any to any nat-to ($ext_if)
>> block log all
>> pass quick on em0
>> 
>> # VPN
>> pass in on $ext_if proto udp from any to $ext_if port
>> { isakmp, ipsec-nat-t }
>> pass out on $ext_if proto udp from $ext_if to any port
>> { isakmp, ipsec-nat-t }
>> pass in on $ext_if proto esp from any to $ext_if
>> pass
>> out on $ext_if proto esp from $ext_if to any
>> 
>> /etc/hostname.bridge0:
>> --
>> link2
>> add etherip0
>> add vether0
>> add em0
>> group "internal"
>> up
>> 
>> /etc/hostname.etherip0
>> --
>> tunnel 10.65.13.10
>> 10.65.12.10
>> group internal
>> up
>> 
>> /etc/hostname.vether0
>> -
>> inet 10.14.254.35 255.255.0.0 NONE
>> description "Interconnexion"
>> group
>> "internal"
>> up
>> 
>> /etc/hostname.em0
>> --
>> up
>> 
>> /etc/hostname.em2
>> --
>> inet 10.65.13.10 255.255.255.0 NONE
>> description "Evil
>> Network"
>> group "external"
>> up
>> !route add -inet 10.65.12.0/24 10.65.13.1
>> /etc/sysctl.conf
>> 
>> net.inet.ip.forwarding=1
>> net.inet.etherip.allow=1


Problem resolved. I did all my tests without pluging the internal physical 
interface (em0) on Host B which is a member of the bridge0. As soon as I 
plugged it in a switch, everything worked !
So, it seems that even if the vether interface in the bridge is active, you 
also need to activate the physical one to make it work.

Strange because only UDP requests are concerned in this case...

Re: build amd64 kernel fails

[Theo Buehler]

On Thu, May 11, 2017 at 09:18:05AM +0200, Heiko wrote:
> Hello List,
> 
> I get this error:
> 
> uvm_init.o: In function `uvm_init':
> /sys/uvm/uvm_init.c:145: undefined reference to `uvm_km_page_lateinit'
> *** Error 1 in /sys/arch/amd64/compile/GENERIC.MP (Makefile:869 'bsd':
> @echo ld -T /sys/arch/amd64/conf/ld.script -X --warn-common -nopie -o...)
> cmp -s bsd /bsd || ln -f /bsd /obsd
> cp bsd /nbsd
> cp: bsd: No such file or directory
> *** Error 1 in /sys/arch/amd64/compile/GENERIC.MP
> 

Make sure you have /sys/uvm/uvm_km.c r1.130 before you try again.

Re: smtpd aliases file issue

[Gilles Chehade]

Much better :-)

You don’t need to restart the daemon, you simply need to tell it through 
smtpctl that the table aliases needs to be reloaded:

$ doas smtpctl update table aliases

Gilles


> On 11 May 2017, at 08:17, Ajitabh Pandey  wrote:
> 
> Hi Gilles,
> 
> I did not change anything from the default. But I realise all may not be
> using default file like me and may not know what is in it. Here is a copy
> of the contents just for reference. The problem is solved by restarting the
> smtpd as sugested by Edgar.
> 
> $ doas cat /etc/mail/smtpd.conf
> 
> table aliases file:/etc/mail/aliases
> listen on lo0
> accept for local alias  deliver to mbox
> accept from local for any relay
> 
> Regards.
> -- 
> ~ajitabhpandey
> 
> On Wed, May 10, 2017 at 5:25 PM, Gilles Chehade  wrote:
> 
>> On Wed, May 10, 2017 at 04:32:55PM +0530, Ajitabh Pandey wrote:
>>> 
>>> If my understanding about how this should work incorrect? If not then
>> what
>>> am I doing wrong?
>>> 
>> 
>> What you are doing wrong is not showing your configuration file so we're
>> able to check if it does what you think it is doing
>> 
>> 
>> --
>> Gilles Chehade
>> 
>> https://www.poolp.org  @poolpOrg
>> 
> 
> 
> 
> -- 
> Ajitabh Pandey
> http://ajitabhpandey.info/ | http://unixclinic.net/ |
> http://buddingthoughts.info
> ICQ - 150615062
> Registered Linux User - 240748

Re: smtpd aliases file issue

[Gilles Chehade]

Obviously you don’t need to restart the daemon to pickup new aliases.

If you are using a plain file aliases map it can be reloaded atomically at 
runtime using smtpctl.
If you are using a db file, it can be rebuilt using the newaliases / makemap 
utility.

I can’t tell you which one to use because you still didn’t show your config,
but just for documentation purpose: you’re not doing it right.

Gilles


> On 11 May 2017, at 08:13, Ajitabh Pandey  wrote:
> 
> Thanks Edgar. That worked. This is what I was missing.
> 
> I actually removed my .forward from the user01 account now and directly
> updated the aliases file to forward email to external email address.
> 
> Just for documentation purpose, here are the steps -
> 
> $ doas vi /etc/mail/aliases file
> $ doas newaliases
> $ doas rcctl restart smtpd
> 
> Regards.
> -- 
> ~ajitabhpandey
> 
> On Wed, May 10, 2017 at 4:58 PM, Edgar Pettijohn  >
> wrote:
> 
>> Did you restart smtpd?
>> 
>> Sent from BlueMail > >
>> On May 10, 2017, at 6:03 AM, Ajitabh Pandey > >
>> wrote:
>>> 
>>> Hello,
>>> 
>>> On an OpenBSD 6.1, I have default smtpd setup.
>>> 
>>> I placed a .forward file in root's home and am able to receive the emails
>>> on an external address.
>>> 
>>> I then removed the .forward from root's home and then placed a .forward in
>>> the home directory of normal user account (say user01). Emails directly
>>> send to user01 are being forwarded to external email address as expected.
>>> 
>>> Next I edited the /etc/mail/aliases file and uncomment the line with root's
>>> name in it and placed an entry like -
>>> 
>>> root: user01
>>> 
>>> After saving the file, I ran newaliases to generate /etc/mail/aliases.db
>>> file.
>>> 
>>> This should forward all email's destined for root to user01 and
>>> consequently to external email address as user01's home has a .forward file
>>> in it.
>>> 
>>> This is not happening. Any email sent to root is being delivered to the
>>> mailbox of root and the smtpd logs in /var/log/maillog confirmed the same.
>>> 
>>> If my understanding about how this should work incorrect? If not then what
>>> am I doing wrong?
>>> 
>>> Thanks and Regards.
>>> 
>>> 
> 
> 
> -- 
> Ajitabh Pandey
> http://ajitabhpandey.info/  | 
> http://unixclinic.net/  |
> http://buddingthoughts.info 
> ICQ - 150615062
> Registered Linux User - 240748

build amd64 kernel fails

[Heiko]

Hello List,

I get this error:

uvm_init.o: In function `uvm_init':
/sys/uvm/uvm_init.c:145: undefined reference to `uvm_km_page_lateinit'
*** Error 1 in /sys/arch/amd64/compile/GENERIC.MP (Makefile:869 'bsd':
@echo ld -T /sys/arch/amd64/conf/ld.script -X --warn-common -nopie -o...)
cmp -s bsd /bsd || ln -f /bsd /obsd
cp bsd /nbsd
cp: bsd: No such file or directory
*** Error 1 in /sys/arch/amd64/compile/GENERIC.MP


I did this before:

# also tried new src from today
# rm -rf /usr/src/*
   # cd /usr

 # cvs -qd
anon...@anoncvs.ca.openbsd.org:/cvs get -P src

# rm -rf /usr/obj/*
# cd /usr/src/gnu/usr.bin/cc
# make obj
# make depend
# make
# make install

# rm -rf /usr/obj/*
# cp /bsd /bsd.old
   # cd
/sys/arch/$(machine)/compile/GENERIC.MP
  # make obj


# make config
   # make



What I'm doing wrong?
Thank you.

Heiko

Re: smtpd aliases file issue

[Ajitabh Pandey]

Hi Gilles,

I did not change anything from the default. But I realise all may not be
using default file like me and may not know what is in it. Here is a copy
of the contents just for reference. The problem is solved by restarting the
smtpd as sugested by Edgar.

$ doas cat /etc/mail/smtpd.conf

table aliases file:/etc/mail/aliases
listen on lo0
accept for local alias  deliver to mbox
accept from local for any relay

Regards.
-- 
~ajitabhpandey

On Wed, May 10, 2017 at 5:25 PM, Gilles Chehade  wrote:

> On Wed, May 10, 2017 at 04:32:55PM +0530, Ajitabh Pandey wrote:
> >
> > If my understanding about how this should work incorrect? If not then
> what
> > am I doing wrong?
> >
>
> What you are doing wrong is not showing your configuration file so we're
> able to check if it does what you think it is doing
>
>
> --
> Gilles Chehade
>
> https://www.poolp.org  @poolpOrg
>



-- 
Ajitabh Pandey
http://ajitabhpandey.info/ | http://unixclinic.net/ |
http://buddingthoughts.info
ICQ - 150615062
Registered Linux User - 240748

Re: smtpd aliases file issue

[Ajitabh Pandey]

Thanks Edgar. That worked. This is what I was missing.

I actually removed my .forward from the user01 account now and directly
updated the aliases file to forward email to external email address.

Just for documentation purpose, here are the steps -

$ doas vi /etc/mail/aliases file
$ doas newaliases
$ doas rcctl restart smtpd

Regards.
-- 
~ajitabhpandey

On Wed, May 10, 2017 at 4:58 PM, Edgar Pettijohn 
wrote:

> Did you restart smtpd?
>
> Sent from BlueMail 
> On May 10, 2017, at 6:03 AM, Ajitabh Pandey 
> wrote:
>>
>> Hello,
>>
>> On an OpenBSD 6.1, I have default smtpd setup.
>>
>> I placed a .forward file in root's home and am able to receive the emails
>> on an external address.
>>
>> I then removed the .forward from root's home and then placed a .forward in
>> the home directory of normal user account (say user01). Emails directly
>> send to user01 are being forwarded to external email address as expected.
>>
>> Next I edited the /etc/mail/aliases file and uncomment the line with root's
>> name in it and placed an entry like -
>>
>> root: user01
>>
>> After saving the file, I ran newaliases to generate /etc/mail/aliases.db
>> file.
>>
>> This should forward all email's destined for root to user01 and
>> consequently to external email address as user01's home has a .forward file
>> in it.
>>
>> This is not happening. Any email sent to root is being delivered to the
>> mailbox of root and the smtpd logs in /var/log/maillog confirmed the same.
>>
>> If my understanding about how this should work incorrect? If not then what
>> am I doing wrong?
>>
>> Thanks and Regards.
>>
>>


-- 
Ajitabh Pandey
http://ajitabhpandey.info/ | http://unixclinic.net/ |
http://buddingthoughts.info
ICQ - 150615062
Registered Linux User - 240748