Small patch for vnconfig/mount_vnd to return the first unused vnd device

[Joe Holden]

Might be useful, particularly in scripting...

Behaves like losetup.

Index: sbin/mount_vnd/mount_vnd.c
===
RCS file: /cvs/src/sbin/mount_vnd/mount_vnd.c,v
retrieving revision 1.20
diff -u -p -r1.20 mount_vnd.c
--- sbin/mount_vnd/mount_vnd.c  24 Jan 2016 06:32:33 -  1.20
+++ sbin/mount_vnd/mount_vnd.c  28 Apr 2017 03:24:44 -
@@ -62,6 +62,7 @@
 #define VND_CONFIG 1
 #define VND_UNCONFIG   2
 #define VND_GET3
+#define VND_FIND   4

 int verbose = 0;
 int run_mount_vnd = 0;
@@ -70,12 +71,13 @@ __dead void  usage(void);
 int config(char *, char *, int, struct disklabel *, char *,
 size_t);
 int getinfo(const char *);
+int findfirst(void);
 char   *get_pkcs_key(char *, char *);

 int
 main(int argc, char **argv)
 {
-   int  ch, rv, action, opt_c, opt_k, opt_K, opt_l, opt_u;
+   int  ch, rv, action, opt_c, opt_k, opt_K, opt_l, opt_u, opt_f = 0;
char*key, *mntopts, *rounds, *saltopt;
size_t   keylen = 0;
extern char *__progname;
@@ -88,7 +90,7 @@ main(int argc, char **argv)
key = mntopts = rounds = saltopt = NULL;
action = VND_CONFIG;

-   while ((ch = getopt(argc, argv, "ckK:lo:S:t:uv")) != -1) {
+   while ((ch = getopt(argc, argv, "ckK:lo:S:t:uv:f")) != -1) {
switch (ch) {
case 'c':
opt_c = 1;
@@ -103,6 +105,9 @@ main(int argc, char **argv)
case 'l':
opt_l = 1;
break;
+   case 'f':
+   opt_f = 1;
+   break;
case 'o':
mntopts = optarg;
break;
@@ -133,6 +138,8 @@ main(int argc, char **argv)

if (opt_l)
action = VND_GET;
+   else if (opt_f)
+   action = VND_FIND;
else if (opt_u)
action = VND_UNCONFIG;
else
@@ -173,6 +180,8 @@ main(int argc, char **argv)
rv = config(argv[0], NULL, action, NULL, NULL, 0);
else if (action == VND_GET)
rv = getinfo(argc ? argv[0] : NULL);
+   else if (action == VND_FIND)
+   rv = findfirst();
else
usage();

@@ -290,6 +299,35 @@ query:
close(vd);

return (0);
+}
+
+int
+findfirst(void)
+{
+   char *vname = DEFAULT_VND;
+   int vd;
+   struct vnd_user vnu;
+
+   vd = opendev((char *)vname, O_RDONLY, OPENDEV_PART, NULL);
+   if (vd < 0)
+   err(1, "open: %s", vname);
+
+   vnu.vnu_unit = -1;
+
+query:
+   if (ioctl(vd, VNDIOCGET, ) == -1)
+   err(1, "ioctl: %s", vname);
+
+   if (!vnu.vnu_ino)
+   fprintf(stdout, "vnd%d\n", vnu.vnu_unit);
+   else {
+   vnu.vnu_unit++;
+   goto query;
+   }
+
+   close(vd);
+
+   return (0);
 }

 int

(cvs diff is dumb)

Re: pledge from command line

[Stuart Henderson]

On 2017-04-27, Ted Unangst  wrote:
> Michael Hendricks wrote:
>> I would like to have pledge on the command line so I can restrict an ad-hoc
>> process during execution.  For example:
>> 
>> $ pledge "stdio" sed -e "s/foo/bar/g" output.txt
>> 
>> I can't modify sed, for example, because I don't always want it pledged
>> that tightly.  Since execve removes pledges, I can't see a way to write
>> this pledge utility myself.  Is it possible?  Is there a better way to
>> impose these kinds of ad-hoc restrictions on a utility?
>
> sed can (should?) reduce the set of permissions after it determines that input
> and output are streams. in fact, it can do so after opening any required
> files.

It would have to parse the command string to decide (r and w functions,
w flag).

Re: Bridged vether interfaces can't talk to each other (multiple routing tables)

[Anders Andersson]

In case someone finds this thread in the future, I would like to add
that I have now received a possible solution to the problem
out-of-band. The solution is to use pair(4):

The following setup works for me, although it is a bit too convoluted:

# cat /etc/hostname.pair0
up

# cat /etc/hostname.pair1
rdomain 1 up patch pair0

# cat /etc/hostname.bridge0
add em2 add vether0 add pair0
!dhclient vether0
!dhclient pair1


In this setup, both vether0 and pair1 gets a separate IP address on
the same network but in different routing domains, but they can still
talk to each other over the patched pair+bridge.

This leads to the following mess, only possible to decipher with a
monospace font:

..-.  10.0.0.1  .-,(  ),-.
| bridge0|   em2   |dhcp server  .-(  )-.
|| (no ip) |--->  gateway   --->(internet)
|'-' __  '-(  ).-'
.---. .---.|[_...__...°] '-.( ).-'
|  vether0  | |   pair0   ||
| rdomain 0 | | rdomain 0 ||
|   dhcp| |  (no ip)  ||
| 10.0.0.2  | '---'|.---.
'---'---^--'|   pair1   |
|   | rdomain 1 |
'---patch---|   dhcp|
| 10.0.0.3  |
'---'

Still not sure if this is a good idea, but it is the solution to my
literal problem so I consider that one solved.







On Sat, Apr 22, 2017 at 3:49 AM, Anders Andersson  wrote:
> === BACKGROUND ===
>
> I'm trying to set up an OpenBSD 6.1 server having two externally visible
> IP numbers through one physical network port, each IP mapping to a
> unique MAC address[1]. I have it mostly working, but my interfaces can't
> talk to each other.
>
> All traffic should use the primary IP, and most services should listen
> on that. The secondary IP should only be used on-demand for one or two
> services.
>
> Thinking that separate routing tables can solve this, I have configured
> my network like this[2][3]:
>
> # cat hostname.em2
> up
>
> # cat hostname.vether0
> lladdr 00:00:00:00:00:02
>
> # cat hostname.vether1
> lladdr 00:00:00:00:00:03 rdomain 1
>
> # cat hostname.bridge0
> add em2 add vether0 add vether1 up
> !dhclient vether0
> !dhclient vether1
>
> # cat sysctl.conf
> net.inet.ip.forwarding=1
>
> Leading to something like this[4]:
> (full post in monospace: http://paste.debian.net/928811 )
>
> ..-.  10.0.0.1  .-,(  ),-.
> | bridge0|   em2   |dhcp server  .-(  )-.
> || (no ip) |--->  gateway   --->(internet)
> |'-' __  '-(  ).-'
> |  |[_...__...°] '-.( ).-'
> .---.  .---.
> |  vether0  |  |  vether1  |
> | rdomain 0 |  | rdomain 1 |
> |   dhcp|  |   dhcp|
> | 10.0.0.2  |  | 10.0.0.3  |
> '---'--'---'
>
> Everything else should be the default, this is on a clean 6.1 install.
>
> This configuration works great, vether0 and vether1 both gets an IP
> number from my DHCP server, all traffic goes out on vether0 by default,
> but I can select vether1 manually:
>
> # traceroute -nvq1 10.0.0.1
> traceroute to 10.0.0.1 (10.0.0.1), 64 hops max, 40 byte packets
>  1  10.0.0.1 48 bytes to 10.0.0.2  0.994 ms
>
> # route -T1 exec traceroute -nvq1 10.0.0.1
> traceroute to 10.0.0.1 (10.0.0.1), 64 hops max, 40 byte packets
>  1  10.0.0.1 48 bytes to 10.0.0.3  0.984 ms
>
> I can also reach each IP from outside the box. They are going in on em2,
> through the bridge, and in to vether0 or vether1 respectively.
>
>
>
>
> === PROBLEM ===
>
> Now to my problem: I have no connection between vether0<->vether1.
>
> # traceroute -nvq1 10.0.0.3
> traceroute to 10.0.0.3 (10.0.0.3), 64 hops max, 40 byte...
>  1  *
>  2  *
> ^C
>
> If I listen with tcpdump on the bridge, I see lots of unanswered arp
> who-has:
>
> # tcpdump -nti bridge0
> tcpdump: listening on bridge0, link-type EN10MB
> arp who-has 10.0.0.3 tell 10.0.0.2
> arp who-has 10.0.0.3 tell 10.0.0.2
> ^C
>
> These packets even go out on em2 to my LAN, but no one ever answers. The
> same thing happens in reverse.
>
> I have experimented with these bridge settings:
> 'blocknonip' - adding or removing on members makes no difference
> 'discover' - should be the default, adding makes no difference
> 'learn' - should be the default, adding makes no difference
>
>
>
> === EXPECTATIONS ===
>
> I expected that someone should answer those arp who-is requests, either
> vether1 directly, or the bridge0 who should know which interfaces it
> has. Is there something I must configure to make this work, or is my
> plan flawed from the start?
>
>
>
>
>
> === INFORMATION ===
>
> Various 

Re: pledge from command line

[Theo de Raadt]

> Michael Hendricks wrote:
> > I would like to have pledge on the command line so I can restrict an ad-hoc
> > process during execution.  For example:
> > 
> > $ pledge "stdio" sed -e "s/foo/bar/g" output.txt
> > 
> > I can't modify sed, for example, because I don't always want it pledged
> > that tightly.  Since execve removes pledges, I can't see a way to write
> > this pledge utility myself.  Is it possible?  Is there a better way to
> > impose these kinds of ad-hoc restrictions on a utility?
> 
> sed can (should?) reduce the set of permissions after it determines that input
> and output are streams. in fact, it can do so after opening any required
> files.

Right.  Ted is pointing out sed does this itself.  Read my previous
mail on "initialization" vs "mainloop", then go look at the code in main.c

That is the groundbreaking idea behind pledge -- that a program itself
knows when to instantiate policy for future instructions.

Re: pledge from command line

[Ted Unangst]

Michael Hendricks wrote:
> I would like to have pledge on the command line so I can restrict an ad-hoc
> process during execution.  For example:
> 
> $ pledge "stdio" sed -e "s/foo/bar/g" output.txt
> 
> I can't modify sed, for example, because I don't always want it pledged
> that tightly.  Since execve removes pledges, I can't see a way to write
> this pledge utility myself.  Is it possible?  Is there a better way to
> impose these kinds of ad-hoc restrictions on a utility?

sed can (should?) reduce the set of permissions after it determines that input
and output are streams. in fact, it can do so after opening any required
files.

Re: pledge from command line

[Theo de Raadt]

That is not possible.

pledge only works on behalf of a process itself.

In the simplest case, a call to pledge is done between the first part
of a program "initialization" and the second part of a program "main
loop".

It serves no purpose if done earlier, and as you noted execve resets
pledge, to serve the large variety or programs which are "shells" or
have selective behaviours where they "shell-out".

> I would like to have pledge on the command line so I can restrict an ad-hoc
> process during execution.  For example:
> 
> $ pledge "stdio" sed -e "s/foo/bar/g" output.txt
> 
> I can't modify sed, for example, because I don't always want it pledged
> that tightly.  Since execve removes pledges, I can't see a way to write
> this pledge utility myself.  Is it possible?  Is there a better way to
> impose these kinds of ad-hoc restrictions on a utility?
> 
> Thanks.

pledge from command line

[Michael Hendricks]

I would like to have pledge on the command line so I can restrict an ad-hoc
process during execution.  For example:

$ pledge "stdio" sed -e "s/foo/bar/g" output.txt

I can't modify sed, for example, because I don't always want it pledged
that tightly.  Since execve removes pledges, I can't see a way to write
this pledge utility myself.  Is it possible?  Is there a better way to
impose these kinds of ad-hoc restrictions on a utility?

Thanks.

relayd splice timeout

[Markus Rosjat]

Hi there,

I was playing arround wit relayd just to get a feeling for it. So I 
started with relaying a ssh connection to a machine behind my gateway.


But it seems there is some kind of config value I miss because after 
like  8 minutes the open ssh connection gets suddenly closed. Running 
relayd in foreground shows a splice timeout.


So question is, can I and if so where can I adjust the timeout value.

SSH might be a bad example for relayd use but its the easiest starting 
point thought. Better to discover stuff befor a setup gets more complicated.


Regards

--
Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de

G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden

http://www.ghweb.de
fon: +49 351 8107220   fax: +49 351 8107227

Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before 
you print it, think about your responsibility and commitment to the 
ENVIRONMENT

Re: torrent downloads

[Christoph R. Murauer]

@Ted : 

Good to know, thanks for details.

@Theo :

I am not the OP of the torrent topic. The topic was from thuban. I have no need 
for a torrent but had only this ideas / doubts about it.


Am 27. April 2017 18:43:29 MESZ schrieb Theo de Raadt :
>> Christoph R. Murauer wrote:
>> > True but let me be a littlebit paranoid. Would it not be possible
>to create a new .fs / .iso with new keys in /etc/signify/* and new
>SHA256 / .sig files to place bad content and distribute it using a
>torrent ? I came across this idea as I readed long time ago some ideas
>how goverments could distribute the here in Europe called trojan of the
>state (Staatstrojaner). 
>> 
>> Don't verify with the key inside the thing you're veriyfing. There is
>some
>> difficulty bootstrapping from nothing, but that's life.
>
>Correct.
>
>And Christoph, you may have noticed I stopped making official CDs
>which did solve that particular problem.  It was too much of a pain
>for the gain.  This feels like a request to handle all this pain for
>torrent people.  I stopped the build process for CDs because it was a
>lot of work for almost no financial gain, and a distraction against
>other things I'd rather do.  Now I'm supposed to continue doing the
>same, for no gain at all?  Allow me to express my disinterest.  As Ted
>said.  Bootstrapping problem is bootstrapping problem.

Re: Problems installing on Dell R830

[Andrew Daugherity]

I think the bootloader is seeing more RAM than is actually there.  Regions
0-15 are contiguous, except for a 256kB hole at 640kB, and total 2.25GB
(2304MB) memory.  Not sure about regions 16 & 17, but they're tiny
(~13MB).  Region 18 is exactly 510GB, so we have 2.25 + 510 = 512.25 GB, or
256MB more memory than is actually installed in the system.

And in relation to Mike's comment, that 510GB region starts at 4GB, so it
does indeed go past 512GB.

For comparison, here's my output from what should be very similar hardware
-- a Dell R230 with 8GB:
>> OpenBSD/amd64 BOOT 3.33
boot> machine memory
Region 0: type 1 at 0x0 for 624KB
Region 1: type 2 at 0x9c000 for 16KB
Region 2: type 2 at 0xe for 128KB
Region 3: type 1 at 0x10 for 2036884KB
Region 4: type 2 at 0x7c625000 for 131104KB
Region 5: type 1 at 0x8462d000 for 145860KB
Region 6: type 4 at 0x8d49e000 for 4KB
Region 7: type 1 at 0x8d49f000 for 2304KB
Region 8: type 2 at 0x8d6df000 for 25132KB
Region 9: type 4 at 0x8ef6a000 for 192KB
Region 10: type 3 at 0x8ef9a000 for 312KB
Region 11: type 1 at 0x8efe8000 for 96KB
Region 12: type 2 at 0x8f00 for 16384KB
Region 13: type 2 at 0xe000 for 262144KB
Region 14: type 2 at 0xe00fd000 for 4KB
Region 15: type 2 at 0xfd00 for 24576KB
Region 16: type 2 at 0xfe00 for 68KB
Region 17: type 2 at 0xfec0 for 4KB
Region 18: type 2 at 0xfed0 for 4KB
Region 19: type 2 at 0xfed1 for 32KB
Region 20: type 2 at 0xfed18000 for 4KB
Region 21: type 2 at 0xfed19000 for 4KB
Region 22: type 2 at 0xfed84000 for 4KB
Region 23: type 2 at 0xfee0 for 4KB
Region 24: type 2 at 0xff40 for 12288KB
Region 25: type 1 at 0x1 for 6029312KB
Low ram: 624KB  High ram: 2036884KB
Total free memory: 8215080KB

(pasted from a serial console, so no typos)

I likewise have 2.25GB (2304MB) at the start, then 256MB in region 13 (the
4kB in region 14 overlaps this), and then 5.75GB (5888MB) in region 25
(regions 15-24 total ~36MB).

Wait a minute, that also adds up to 256MB (+36MB) more RAM than I have
installed (8.25 vs 8 GB), but my system boots fine.  Now I'm more
confused... I don't know what to make of the extra 256MB, but it's possible
your system's crossing the 512GB boundary may be the issue.

-Andrew

OpenBSD 6.1 - Song released

[R0me0 ***]

Great work !


Bryan Adams - Summer of 69 - Parody


Long Life to Puffy

Cheers

Re: torrent downloads

[Theo de Raadt]

> Christoph R. Murauer wrote:
> > True but let me be a littlebit paranoid. Would it not be possible to create 
> > a new .fs / .iso with new keys in /etc/signify/* and new SHA256 / .sig 
> > files to place bad content and distribute it using a torrent ? I came 
> > across this idea as I readed long time ago some ideas how goverments could 
> > distribute the here in Europe called trojan of the state (Staatstrojaner). 
> 
> Don't verify with the key inside the thing you're veriyfing. There is some
> difficulty bootstrapping from nothing, but that's life.

Correct.

And Christoph, you may have noticed I stopped making official CDs
which did solve that particular problem.  It was too much of a pain
for the gain.  This feels like a request to handle all this pain for
torrent people.  I stopped the build process for CDs because it was a
lot of work for almost no financial gain, and a distraction against
other things I'd rather do.  Now I'm supposed to continue doing the
same, for no gain at all?  Allow me to express my disinterest.  As Ted
said.  Bootstrapping problem is bootstrapping problem.

Re: torrent downloads

[Ted Unangst]

Christoph R. Murauer wrote:
> True but let me be a littlebit paranoid. Would it not be possible to create a 
> new .fs / .iso with new keys in /etc/signify/* and new SHA256 / .sig files to 
> place bad content and distribute it using a torrent ? I came across this idea 
> as I readed long time ago some ideas how goverments could distribute the here 
> in Europe called trojan of the state (Staatstrojaner). 

Don't verify with the key inside the thing you're veriyfing. There is some
difficulty bootstrapping from nothing, but that's life. However once you have
one trusted install, you can verify future installs regardless of source.

signify wasn't developed for the express purpose of supporting torrents, but it
was developed to reduce the need to trust mirrors. A torrent is just an 
untrusted
mirror in that world.

Re: torrent downloads

[Christoph R. Murauer]

True but let me be a littlebit paranoid. Would it not be possible to create a 
new .fs / .iso with new keys in /etc/signify/* and new SHA256 / .sig files to 
place bad content and distribute it using a torrent ? I came across this idea 
as I readed long time ago some ideas how goverments could distribute the here 
in Europe called trojan of the state (Staatstrojaner). 

Just a idea and, maybe I am wrong - back to the topic.


Am 27. April 2017 17:43:03 MESZ schrieb Ted Unangst :
>Christoph R. Murauer wrote:
>> Let's say, you provide a torrent for the .fs and .iso files. Who
>trusts a SHA256.sig file from an unofficial torrent ? 
>
>The whole point of signing the SHA256 is you don't have to trust the
>person
>who gives it to you.

Re: torrent downloads

[Thuban]

> yes, but unlike those distros the openbsd installers aren't measured in
> gigabytes.
> 

Of course, the point doesn't apply to miniroot* but to installxx.xx. 
It doesn't remove the problem of long download for some and servers
bandwidth possible issue.
Using miniroot* still requires to download file from a mirror then, and
using its banwidth.
The torrent "idea" here is only relevant for big files, and doesn't
remove the need to check SHA256 as usual.

> The site mentioned by OP (http://openbsd.somedomain.net) is up to date,
> and has the torrents mentioned.
> 

Indeed it is. 
I've been fooled as the first entry is for OpenBSD **6.0 alpha**...
Moreover, as it's not listed in official mirrors, it's harder to trust.

Re: torrent downloads

[Ted Unangst]

Christoph R. Murauer wrote:
> Let's say, you provide a torrent for the .fs and .iso files. Who trusts a 
> SHA256.sig file from an unofficial torrent ? 

The whole point of signing the SHA256 is you don't have to trust the person
who gives it to you.

Re: torrent downloads

[Christoph R. Murauer]

Let's say, you provide a torrent for the .fs and .iso files. Who trusts a 
SHA256.sig file from an unofficial torrent ? 

If you look at the errata page, you see, that you have to patch the system to 
keep it up to date and, there are no official updates of the .fs and .iso files 
after a patch. Even there are sometimes binary patches - this happened not for 
all platforms.

At the end, a torrent is useless if you have to use again a mirror for the 
patches, for cvs or, for firmware updates.

IMHO A better idea would be a mirror - if there is need for one.


Am 27. April 2017 13:55:42 MESZ schrieb Thuban :
>Hello,
>I was wondering if there is any particular reason explaining why there
>is no torrent file to retrieve OpenBSD *.fs and *.iso. 

Re: obsd 6.1

[Andreas Kusalananda Kähäri]

On Thu, Apr 27, 2017 at 11:28:33AM -0300, Friedrich Locke wrote:
> Hi folks,
> 
> i wonder if there is an obsd 6.1 cd set to order ?
> If not, when will it be released ?
> 
> Thanks.
> 


Related: https://marc.info/?l=openbsd-misc=149232307018311=2

obsd 6.1

[Friedrich Locke]

Hi folks,

i wonder if there is an obsd 6.1 cd set to order ?
If not, when will it be released ?

Thanks.

Re: torrent downloads

[Marco Bonetti]

- On Apr 27, 2017, at 2:07 PM, Nicolas Schmidt 
schmi...@mathematik.hu-berlin.de wrote:

> Many distros sport torrents: NetBSD, Debian, and Ubuntu to name some. 
> Rationale
> behind this is simple: torrents download with ridiculous speed if they are
> popular enough.

To be fair, popular downloads need a popular architecture and miniroot61.fs for 
amd64 is just 4.4MB. Plus a bunch of KB for SHA256.sig. 
Maybe a torrent is a bit overkill for both of them?

BTW, might be interesting to know that Tails recently stopped distributing 
torrent files of its releases for security and privacy reasons.
Have a look at 
https://tails.boum.org/install/download/torrents_considered_harmful/ and 
related links https://labs.riseup.net/code/issues/12456 and 
https://biterrant.io/ .

> 
> Best,
> Nicolas
> 
>> Am 27.04.2017 um 14:36 schrieb Markus Rosjat :
>> 
>> Hi,
>> 
>> I think it's kinda pointless to have a torrent for this. You got enough good
>> mirrors to download from anyway. And nowadays it's not a biggy to download a
>> iso or so of somewhat 200mb.
>> 
>> and yes I'm the proud owner of some awesome puffy shirts too (if someone is
>> concerned about the download part :-P )
>> 
>> regards
>> 
>> markus
>> 
>>> Am 27.04.2017 um 13:55 schrieb Thuban:
>>> Hello,
>>> I was wondering if there is any particular reason explaining why there
>>> is no torrent file to retrieve OpenBSD *.fs and *.iso.
>>> 
>>> I've been looking on the list and only found this site that doesn't
>>> seems up to date [1].
>>> 
>>> If the reason is a lack of human ressources, I think I can handle it.
>>> 
>>> Regards.
>>> 
>>> [1] : http://openbsd.somedomain.net/
>>> 
>> 
>> --
>> Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de
>> 
>> G+H Webservice GbR Gorzolla, Herrmann
>> Königsbrücker Str. 70, 01099 Dresden
>> 
>> http://www.ghweb.de
>> fon: +49 351 8107220   fax: +49 351 8107227
>> 
>> Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you
> > print it, think about your responsibility and commitment to the ENVIRONMENT

--
Marco Bonetti

Re: torrent downloads

[Peter Hessler]

yes, but unlike those distros the openbsd installers aren't measured in
gigabytes.

The site mentioned by OP (http://openbsd.somedomain.net) is up to date,
and has the torrents mentioned.

it just seems, nobody cares.



On 2017 Apr 27 (Thu) at 15:07:38 +0200 (+0200), Nicolas Schmidt wrote:
:Many distros sport torrents: NetBSD, Debian, and Ubuntu to name some. 
Rationale behind this is simple: torrents download with ridiculous speed if 
they are popular enough.
:
:Best,
:Nicolas
:
:> Am 27.04.2017 um 14:36 schrieb Markus Rosjat :
:> 
:> Hi,
:> 
:> I think it's kinda pointless to have a torrent for this. You got enough good 
mirrors to download from anyway. And nowadays it's not a biggy to download a 
iso or so of somewhat 200mb.
:> 
:> and yes I'm the proud owner of some awesome puffy shirts too (if someone is 
concerned about the download part :-P )
:> 
:> regards
:> 
:> markus
:> 
:>> Am 27.04.2017 um 13:55 schrieb Thuban:
:>> Hello,
:>> I was wondering if there is any particular reason explaining why there
:>> is no torrent file to retrieve OpenBSD *.fs and *.iso.
:>> 
:>> I've been looking on the list and only found this site that doesn't
:>> seems up to date [1].
:>> 
:>> If the reason is a lack of human ressources, I think I can handle it.
:>> 
:>> Regards.
:>> 
:>> [1] : http://openbsd.somedomain.net/
:>> 
:> 
:> -- 
:> Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de
:> 
:> G+H Webservice GbR Gorzolla, Herrmann
:> Königsbrücker Str. 70, 01099 Dresden
:> 
:> http://www.ghweb.de
:> fon: +49 351 8107220   fax: +49 351 8107227
:> 
:> Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you 
print it, think about your responsibility and commitment to the ENVIRONMENT
:

-- 
Do molecular biologists wear designer genes?

Re: torrent downloads

[Maxim Bourmistrov]

ISO is burned down to the CD you buy.
To install you really just need to PXE.


> 27 apr. 2017 kl. 13:55 skrev Thuban :
> 
> Hello,
> I was wondering if there is any particular reason explaining why there
> is no torrent file to retrieve OpenBSD *.fs and *.iso. 
> 
> I've been looking on the list and only found this site that doesn't
> seems up to date [1].
> 
> If the reason is a lack of human ressources, I think I can handle it.
> 
> Regards.
> 
> [1] : http://openbsd.somedomain.net/
> -- 
>  

Re: torrent downloads

[Nicolas Schmidt]

Many distros sport torrents: NetBSD, Debian, and Ubuntu to name some. Rationale 
behind this is simple: torrents download with ridiculous speed if they are 
popular enough.

Best,
Nicolas

> Am 27.04.2017 um 14:36 schrieb Markus Rosjat :
> 
> Hi,
> 
> I think it's kinda pointless to have a torrent for this. You got enough good 
> mirrors to download from anyway. And nowadays it's not a biggy to download a 
> iso or so of somewhat 200mb.
> 
> and yes I'm the proud owner of some awesome puffy shirts too (if someone is 
> concerned about the download part :-P )
> 
> regards
> 
> markus
> 
>> Am 27.04.2017 um 13:55 schrieb Thuban:
>> Hello,
>> I was wondering if there is any particular reason explaining why there
>> is no torrent file to retrieve OpenBSD *.fs and *.iso.
>> 
>> I've been looking on the list and only found this site that doesn't
>> seems up to date [1].
>> 
>> If the reason is a lack of human ressources, I think I can handle it.
>> 
>> Regards.
>> 
>> [1] : http://openbsd.somedomain.net/
>> 
> 
> -- 
> Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de
> 
> G+H Webservice GbR Gorzolla, Herrmann
> Königsbrücker Str. 70, 01099 Dresden
> 
> http://www.ghweb.de
> fon: +49 351 8107220   fax: +49 351 8107227
> 
> Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you 
> print it, think about your responsibility and commitment to the ENVIRONMENT

Re: acme-client(1) and http_proxy

[Stuart Henderson]

On 2017-04-26, Predrag Punosevac  wrote:
> Adam Thompson wrote:
>
>> I stand by my statement that just buying a cheap SSL cert will, for 
>> anything other than the simple case of an online, directly-connected, 
>> webserver, be cheaper than the labour required to obtain a LetsEncrypt
>> certificate.
>
> A cheap certificate like the one you can buy from GoDaddy will trigger
> browser exception warning just like the self-signed certificates.

They all work just as well as each other unless you have requirements to
support unusual/old clients. Just make sure your server has any necessary
chain certificates as well as the server certificate. Run the ssllabs
checker after setting up (or try connecting with a command-line client),
some browsers hide this problem.

GoDaddy are about 10x too expensive, try ssls.com

Re: Arch and vmd

[Stuart Henderson]

On 2017-04-26, Reyk Floeter  wrote:
> On Wed, Apr 26, 2017 at 11:15:57AM -0700, Mike Larkin wrote:
>> On Wed, Apr 26, 2017 at 06:47:17PM +0200, Karl Pettersson wrote:
>> > Arch Linux works well as a vmd guest. Some notes about my experiences 
>> > installing the system:
>> > 
>> > * The Arch installation can be started from the serial console, see:
>> >   https://wiki.archlinux.org/index.php/Working_with_the_serial_console
>> >   #Installing_Arch_Linux_using_the_serial_console
>> >   However, the installation still tends to be unstable, due to unreliable
>> >   downloads (which has been discussed earlier). Until this is fixed, the 
>> >   installation can be run in QEMU, or in a guest under Linux/KVM (as is
>> >   currently required by distributions with graphical install).
>> > 
>> > * Syslinux has to be used as bootloader, and serial console should be
>> >   enabled: https://wiki.archlinux.org/index.php/Syslinux#Serial_console
>> >   Moreover, the generated config has to be edited to point to the
>> >   correct root device, and if Ext4 is used as root file system, it must
>> >   not be 64bit (which is enabled by default when the file system is
>> >   created): http://www.syslinux.org/wiki/index.php?title=Filesystem
>> > 
>> 
>> Thanks for trying this out and reporting Karl.
>> 
>> The notes about serial console are welcome. Do note that we are working 
>> toward
>> an sgabios + seabios payload so that you will be able to install from media
>> that uses the regular VGA console (sgabios redirects VGA text mode I/O to
>> the serial console). There are a couple of developers working on this, 
>> hopefully
>> it will make it to the tree soon.
>> 
>
> vmd -current is ready to handle sgabios with a different BIOS image.
>
> sthen@ has made an updated sysutils/firmware/vmm port that includes
> sgabios, but it is not available yet,

It's there now. If you're on -current, just run "fw_update".

Re: torrent downloads

[Markus Rosjat]

Hi,

I think it's kinda pointless to have a torrent for this. You got enough 
good mirrors to download from anyway. And nowadays it's not a biggy to 
download a iso or so of somewhat 200mb.


and yes I'm the proud owner of some awesome puffy shirts too (if someone 
is concerned about the download part :-P )


regards

markus

Am 27.04.2017 um 13:55 schrieb Thuban:

Hello,
I was wondering if there is any particular reason explaining why there
is no torrent file to retrieve OpenBSD *.fs and *.iso.

I've been looking on the list and only found this site that doesn't
seems up to date [1].

If the reason is a lack of human ressources, I think I can handle it.

Regards.

[1] : http://openbsd.somedomain.net/



--
Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de

G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden

http://www.ghweb.de
fon: +49 351 8107220   fax: +49 351 8107227

Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before 
you print it, think about your responsibility and commitment to the 
ENVIRONMENT

Re: torrent downloads

[Adam Van Ymeren]

On April 27, 2017 7:55:42 AM EDT, Thuban  wrote:
>Hello,
>I was wondering if there is any particular reason explaining why there
>is no torrent file to retrieve OpenBSD *.fs and *.iso. 
>
>I've been looking on the list and only found this site that doesn't
>seems up to date [1].
>
>If the reason is a lack of human ressources, I think I can handle it.

You are always free to make your own torrent of the openbsd release files :)

>
>Regards.
>
>[1] : http://openbsd.somedomain.net/

torrent downloads

[Thuban]

Hello,
I was wondering if there is any particular reason explaining why there
is no torrent file to retrieve OpenBSD *.fs and *.iso. 

I've been looking on the list and only found this site that doesn't
seems up to date [1].

If the reason is a lack of human ressources, I think I can handle it.

Regards.

[1] : http://openbsd.somedomain.net/
-- 

OpenLDAP and filesystem permission

[Markus Rosjat]

Hi there,

I basically want to know if its okay to set permission on a file or 
directory for a LDAP user even if there is no local user on this machine.


Hope someone understand what I mean, background is setting up a 
mailserver with usermanagement over LDAP. The naive way for me would be 
creating a local user with the same name like the one in the LDAP db. So 
I can set the permissions on the Maildirs for the local user.
This leaves me with maintaining LDAP and Local user but if I could just 
use only the LDAP user this would be nice ( it works at least in my test 
env) but is this considerd secure or should I stick with the LDAP+local 
User approach?


regards

--
Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de

G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden

http://www.ghweb.de
fon: +49 351 8107220   fax: +49 351 8107227

Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before 
you print it, think about your responsibility and commitment to the 
ENVIRONMENT

Re: tinc on openBSD?

[Reyk Floeter]

On Thu, Apr 27, 2017 at 07:51:18AM +0200, Harald Dunkel wrote:
> Hi folks,
> 
> AFAICS tinc is included in the packages for 6.1, but surely
> that doesn't mean its safe to use without looking.
> 
> Are there security concerns against running tinc on an OpenBSD
> gateway as an alternative to IPsec and openvpn in a +50 road
> warriors setup? What is your impression of this tool in daily
> usage? Which VPN solution would you prefer?
> 
> 

I never used tinc and it is not related to OpenBSD; so I cannot judge
on the quality or usability of the software.

But a quick look at source and documentation shows me that --chroot
and --user are not enabled by default (see switchuser and do_chroot in
tind.c).  Who would do that in 2017?

Another question that you should ask yourself: do you trust tinc's
crypto protocol?  It seems a bit dated; but what really matters if you
care about security: did it get a good crypto review recently?

It does show up with examples and documentation in Wikileak's Vault7
documents, but I'm not sure if this is a good or bad thing.

Reyk

Re: tinc on openBSD?

[Uwe Werler]

On 27. Apr  7:51:18, Harald Dunkel wrote:
> Hi folks,
> 
> AFAICS tinc is included in the packages for 6.1, but surely
> that doesn't mean its safe to use without looking.
> 
> Are there security concerns against running tinc on an OpenBSD
> gateway as an alternative to IPsec and openvpn in a +50 road
> warriors setup? What is your impression of this tool in daily
> usage? Which VPN solution would you prefer?
> 
> 
> Every helpful comment is highly appreciated
> Harri
> 

Hi Harri,

running tinc now since ~2 years for my private vpn solution - especially via
proxy out of my company from my OpenBSD vm to my OpenBSD router. Runs like a
charme. It's much easier to configure than e.g. OpenVPN. There are already
some networks running with tinc like https://dn42.net/Home e.g.

Regards Uwe

-- 

Re: tinc on openBSD?

[Pierre Emeriaud]

> Are there security concerns against running tinc on an OpenBSD
> gateway as an alternative to IPsec and openvpn in a +50 road
> warriors setup? What is your impression of this tool in daily
> usage? Which VPN solution would you prefer?

I'm using tinc 1.1pre14 (not the port) with hostname.if in tap mode
(mode = switch) with no issues. Tinc config is very simple, and I
really like the "any to any" approach, even though p2p/p2mp is
achievable with some additional configuration. Not sure about how it
scales on OpenBSD with such a number of nodes, but on the tinc ml
there has been reports of larger clouds.

Re: [vmm] SSL read error: read failed: error:06FFF064:digital envelope routines:CRYPTO_internal:bad decrypt

[Mike Larkin]

On Sun, Apr 16, 2017 at 09:17:44AM +, Paul Chakravarti wrote:
> Hello,
> 
> I am trying out vmm on 6.1 and can setup/boot vm etc. however when I try to
> download a large file using SSL I consistenetly get the following error:
> 
> > SSL read error: read failed: error:06FFF064:digital envelope
> routines:CRYPTO_internal:bad decrypt
> 
> This occasionally (but not always) correlates with the following message in
> the vmd log:
> 
> > vionet queue notify - no space, dropping packet
> 
> Strangely non-SSL and smaller SSL downloads seem to work ok (see below).
> 
> Originally spotted this using installer but can recreate from shell.
> 
> Any ideas?
> 

The diff I just committed should fix this as well as the previously reported
github clone issue. The diff is also already in snaps (as of this morning).

Please update and let me know if you still see this problem.

Thanks for reporting this.

-ml

> # cat /etc/vm.conf                                                           
>                                                        
> vm vm0 {
>   disable
>   memory 512M
>   disk /home/vm/vm0.img
>   kernel /bsd.rd
>   interface { switch uplink }
> }
> 
> switch uplink {
>   interface bridge0
>   add vether0
> }
> 
> # vmctl start vm0 
> vmctl: started vm 11 successfully, tty /dev/ttyp6
> # vmctl status
>ID   PID VCPUS  MAXMEM  CURMEM TTYOWNER NAME
>11 85026 1512M   97.3M   ttyp6 root vm0
> # cu -l /dev/ttyp6
> Connected to /dev/ttyp6 (speed 9600)
> 
> (I)nstall, (U)pgrade, (A)utoinstall or (S)hell? s
> # dhclient vio0                                                             
>  
> DHCPDISCOVER on vio0 - interval 1
> DHCPOFFER from 10.0.0.1 (fe:e1:ba:d3:55:34)
> DHCPREQUEST on vio0 to 255.255.255.255
> DHCPACK from 10.0.0.1 (fe:e1:ba:d3:55:34)
> bound to 10.0.0.105 -- renewal in 21600 seconds.
> #
> # ftp -Vo- http://www.mirrorservice.org/pub/OpenBSD/6.1/amd64/bsd | sha256
> 440311305f27f0efcfcc88116299a21cb3f890fb91ee611c2a79cc9163e8fceb
> # ftp -Vo- http://www.mirrorservice.org/pub/OpenBSD/6.1/amd64/SHA256 | fgrep
> '(bsd)'
> SHA256 (bsd) =
> 440311305f27f0efcfcc88116299a21cb3f890fb91ee611c2a79cc9163e8fceb
> # ftp -Vo- http://www.mirrorservice.org/pub/OpenBSD/6.1/amd64/base61.tgz |
> sha256 
> 5c467ea369b5632d3b057283857d1998fb3dcd26179365291f16c70785a65282
> # ftp -Vo- http://www.mirrorservice.org/pub/OpenBSD/6.1/amd64/SHA256 | fgrep
> '(base61.tgz)'
> SHA256 (base61.tgz) =
> 5c467ea369b5632d3b057283857d1998fb3dcd26179365291f16c70785a65282
> #
> # ftp -Vo- https://www.mirrorservice.org/pub/OpenBSD/6.1/amd64/bsd | sha256
> ftp: SSL read error: read failed: error:06FFF064:digital envelope
> routines:CRYPTO_internal:bad decrypt
> 27ad92f2aaf0279dd125ed54d0b7fbf330a3ecbe2e919b4d2d0ed1d07dccc087
> # ftp -Vo- https://www.mirrorservice.org/pub/OpenBSD/6.1/amd64/base61.tgz |
> sha256
> ftp: SSL read error: read failed: error:06FFF064:digital envelope
> routines:CRYPTO_internal:bad decrypt
> d79f6fd884a839d1fc62dc1b5d40de21f97fd5a50b28319a7b25dd8cd82da887
> 
> [On host]
> 
> # top -d1 all
> load averages:  1.14,  1.16,  1.16x230 10:06:31
> 68 processes: 67 idle, 1 on processor  up 2 days, 11:19
> CPU0 states:  0.2% user,  0.0% nice,  0.5% system,  0.2% interrupt, 99.1%
> idle
> CPU1 states:  4.6% user,  0.0% nice,  8.3% system,  0.0% interrupt, 87.2%
> idle
> CPU2 states:  1.2% user,  0.0% nice,  2.2% system,  0.0% interrupt, 96.6%
> idle
> CPU3 states:  0.8% user,  0.0% nice,  1.1% system,  0.0% interrupt, 98.1%
> idle
> Memory: Real: 470M/1376M act/tot Free: 6261M Cache: 652M Swap: 0K/3562M
> 
>   PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
> 85026 _vmd  280  514M   14M idle  thrslee   1:19 13.53% vmd
> 55104 paulc  20  399M  301M sleep/3   poll  4:09  7.86% firefox
>  1136 paulc  20 1180K 9156K sleep/3   poll  0:23  0.05% i3bar
> 91148 paulc  20   14M   50M sleep/2   select0:24  0.00% Xorg
> 48836 paulc 100  752K 1988K sleep/2   nanosle   0:05  0.00% i3status
> 24227 paulc  20 1032K 2820K sleep/2   select0:04  0.00% sshd
> 66378 paulc  20 1564K   10M idle  poll  0:02  0.00% i3
> 67867 paulc  20 5032K   13M idle  select0:02  0.00% urxvt
> 22018 _syslogd   20  904K 1544K sleep/2   kqread0:02  0.00% syslogd
> 1 root  100  380K  416K idle  wait  0:01  0.00% init
> 43749 _pflogd40  668K  428K sleep/1   bpf   0:01  0.00% pflogd
> 27702 _ntp   2  -20  888K 2344K sleep/2   poll  0:01  0.00% ntpd
> 49491 paulc  20 4972K   13M idle  select0:01  0.00% urxvt
> 76489 _vmd   20 1176K 1672K idle  kqread0:00  0.00% vmd
>  6009 root   20  620K  528K idle  poll  0:00  0.00% dhclient
> 39926 paulc  20 4912K   12M idle  select0:00  0.00% urxvt
>  3807 paulc 180  604K  732K idle  pause 0:00  0.00% ksh
> 76917 root   20  220K