Re: PC Engines APU alternative for OpenBSD - 2022h2

2022-09-28 Thread Vincent Legoll
Hello,

what about a Pine64 RockPro64, it has a PCIe slot where
you can put a multiport ethernet card or other things
depending on your project...

There's certainly a serial port usable as console on those
too.

Looks supported, according to :
https://www.openbsd.org/arm64.html

But you may want to wait for comments from someone
with actual real world experience of openbsd on those,
I don't own one.

Regards

-- 
Vincent Legoll



Re: Installing sets from /

2022-07-14 Thread Vincent Legoll
Hello,

On Wed, Jul 13, 2022 at 11:17 PM Nick Holland
 wrote:
> > I expected the setup to look at the / (from the ramdisk), but it
> > searched in /mnt2 instead.
>
> As a user, I'd expect the response there to be "As would be seen
> on the running system."

For an upgrade that would be a good assumption, but for an install,
the running system is the installer, the target filesystem is not even
existing yet.

> As a user, I expect it to go something like this:
> I put the install sets someplace on the running systemm, say
> /home/upgrade or /usr/rel.  I rebooted into bsd.rd, chose
> "install" or "upgrade", I expect to answer exactly where I put
> the files. How the upgrader or installer does the upgrade or
> install, I really don't care."
>
> The installer happens to mount the system hanging off /mnt2,
> but I shouldn't have to know that.  I definitely shouldn't have to
> include that in my answer (in my opinion)

Yeah, I'm not arguing about that.

I came to ask about this after reading the installer code, where
comments are telling:

* Accept a valid /mnt2 or /mnt relative path.
* Accept a valid absolute path.

Which (at least as I interpreted it) implies that you would give
"home/upgrade" or "./usr/rel" for your use cases. But the second
comment, and the way it is implemented, made me think the
absolute pathes should work for ramdisk content.

And the way the installer checks it makes '/' not search where
the comment tells it should.

So the modifications may just be to fix the comment and not
change behavior.

> > Is this in need for a modification, or is it good as-is ?
> > I can submit a patch if you think it is useful.
>
> Speaking only for myself, I think it is working exactly as I'd
> hope right now.
>
> I would spend some time thinking about why you are stuffing the
> install files into the ramdisk rather than from an existing
> file system or other more supported option.  I think the "proper"
> answers will work better for you all around.

I am stuffing a siteXX.tgz in the ramdisk of bsd.rd, alongside the
auto_install.conf file to do an automatic install on a VM.

I want to avoid manual interactions with the VM, so the use of
auto_install.conf, and the install.site script contained in the
siteXX.tgz is for further customizations.

-- 
Vincent Legoll



Installing sets from /

2022-07-13 Thread Vincent Legoll
Hello,

I was trying to autoinstall OpenBSD 7.1 on a VM when I stumbled upon
something unexpected (to my uneducated eyes) in the installer.

What I'm trying to do may very well fall in the "unsupported" basket,
just tell me. But still, I think I can at least ask if this is
actually intended behavior.

When I used the following answers:

[...]
Location of sets = disk
Is the disk partition already mounted = yes
Pathname to the sets = /
[...]

I expected the setup to look at the / (from the ramdisk), but it
searched in /mnt2 instead.

The error message was helpful:

Looked at file:///mnt2// and found no OpenBSD/amd64 [...]

After having had a look at install_mounted_fs() in
distrib/miniroot/install.sub I can see why it happened like that.

But the comments in the install.sub file say that it should "# Accept
a valid absolute path.".

But as this is only checked after the /mnt2 & /mnt tests, it may do
something different whether they contain something related to your
answer or not.

I managed to workaround this by telling it to use ../ instead of /,
and it worked, so I have a solution for my needs.

Is this in need for a modification, or is it good as-is ?
I can submit a patch if you think it is useful.

Thanks

--
Vincent Legoll



Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread Vincent Legoll
On Sat, Apr 27, 2019 at 3:32 PM Igor Podlesny  wrote:
> On Sat, 27 Apr 2019 at 18:09, Marc Espie  wrote:
> > Man, you have some really strange delusions about how to harden things.
>
> %  man malloc.conf | grep -i security
>  S   Enable all options suitable for security auditing.
>
> Oh, those hypocrite wankers here and there..

Looks like auditing and hardening are not exactly the same thing.

-- 
Vincent Legoll



Re: migrate python script from sudo to doas

2018-10-30 Thread Vincent Legoll
Hello,

On Tue, Oct 30, 2018 at 12:33 PM Markus Rosjat  wrote:
>   exit = subprocess.check_call(['doas', 'useradd', '-u %s' % user_id,
> '-g =uid',
> '-s /sbin/nologin',
> '-d %s' % mb_parent_dir,
> user_name])

Maybe you should try like the following:

cmd = ['doas', 'useradd',
  '-u', user_id,
  '-g', '=uid',
  '-s', '/sbin/nologin',
  '-d', mb_parent_dir,
  user_name]
exit = subprocess.check_call(cmd)



Re: How to copy n bytes from stdin to stdout?

2018-06-21 Thread Vincent Legoll
Hello,

The man page did not say bs has to be a power of 2.

On a very old macppc openbsd box:

vince@mini:~$ dd count=1 bs=123456789 < /dev/zero > zero.bin
1+0 records in
1+0 records out
123456789 bytes transferred in 9.833 secs (12554493 bytes/sec)

On a much more recent core i7 linux:

vince@dell:~$ dd count=1 bs=123456789 < /dev/zero > zero.bin
1+0 records in
1+0 records out
123456789 bytes (123 MB, 118 MiB) copied, 0,0703818 s, 1,8 GB/s


This may not work with huge bs though...


-- 
Vincent Legoll