Re: Home NAS

2019-11-17 Thread Janne Johansson
Den lör 16 nov. 2019 kl 22:49 skrev Karel Gardas :

> > I tried a home NAS with ZFS, then BTRFS. Those filesystems needs tons of
> RAM (~1 GB of RAM by TB of disk), preferably ECC.
>
> For NAS you prefer ECC anyway and 1 GB RAM consumption per 1 TB of drive
> is urban legend probably passed by folks using deduplication.


Or people who do not want to swap while doing extensive fsck of huge
partitions with lots of small files in them.
Most recommendations are based on all corner cases and not just the
happy-case when you stash a single movie on a nas over the home network.

Yes, dedup uses ram most of the time if it can, but other things do too.
Also, "excess" ram in these cases turn into read caches so its not lost on
you either.

-- 
May the most significant bit of your life be positive.


Re: Home NAS

2019-11-17 Thread Patrick Marchand
Hi,

On 11/17, Predrag Punosevac wrote:
> Patrick Marchand  wrote:
> > On 11/15, Predrag Punosevac wrote:
> > > Patrick Marchand wrote:
> > > > I'll be playing around with DragonflyBSD Hammer2 (and multiple offsite
> > > > backups) for a home NAS over the next few weeks. I'll probably do a
> > > > presentation about the experience at the Montreal BSD user group
> > > > afterwards. It does not require as many ressources as ZFS or BTRFS,
> > > > but offers many similar features.
> > > >
> > >
> > > Been there, done that!
> > Cool ! I might ping you off-list with questions when I get to it.
> >
>
> Any time. Either this private email or at my work predr...@cs.cmu.edu
> I wish I was a bit closer to Montreal to come to your monthly meeting. I
> love Quebec and Montreal in particular.
Thanks !

> > I'm not planning on using jails much, instead I'll be using the
> > DFly NFS with OpenBSD to experiment with virtualization.
> >
>
>
> I am not sure that I am following. How is DF NFS server related to
> OpenBSD (if I understand correctly) virtualization. Are you trying to
> store OpenBSD vmm images on the NFS share exported from a DF server?
> That is a really, really bad idea.
>
>
> https://marc.info/?l=dragonfly-users=140384130921709=2
MirageOS and PXE booted OpenBSD is what I really want to play with,
but well see as I go along, breaking stuff is kind of the idea here.

>
> > > DragonFly which gets it software RAID discipline through old
> > > unmaintained FreeBSD natacontrol utility. Hardware RAID cards are not
> > > frequently tested and community seems to be keen on treating DF as a
> > > desktop OS rather than a storage workhorse. Having said that HDD are
> > > cheap this days and home users probably don't need anything bigger than
> > > a 12TB mirror.
> > I dont store much anyways, so I'll see as I go.
> >
>
> 12 TB is the sweet spot when it comes GB/dollar for platter HDDs.
As it's more for an experiment and maybe some bsd systems work and
it will be running in my room, I started with a 1TB ssd.



Re: Home NAS

2019-11-17 Thread Predrag Punosevac
Milun Rajkovic wrote:

> Pardon my ignorance and lack of deeper knowledge regarding the matter,
> but since when is XFS not even considered for such uses?
> 

Since 2005 if you are Solaris guy. Since 2008 if you are ZFS on FreeBSD
or Hammer 1 DragonFly guy. XFS is indeed the most stable and reliable
file system for Linux and in principle there is nothing wrong with using
XFS on the top of hardware or software RAID if you don't care about data
integrity, self-healing, COW, snapshots, replication and similar things.
If you put LVM2 between the RAID and XFS you could theoretically get
snapshots of logical volumes and perhaps even restore something. However
LVM2 snapshots are expensive and not really practical contrary to Red
Hat PR debarment claims. Hopefully some of old Irix SGI who are lurking
on this mailing list could tell you more things I don't know or I forgot
since my old Irix days.

Pozdrav,
Pedja


> Cheers
> Milun



Re: Best Practices for growing disk partitions on a server

2019-11-17 Thread Lev Lazinskiy
Hi Edgar, 

Thanks for the response. 
On Sun, Nov 17, 2019 at 04:06:18PM -0600, Edgar Pettijohn wrote:
> 
> On Nov 17, 2019 2:35 PM, Lev Lazinskiy  wrote:
> >
> > Hi folks, 
> >
> > I am new to openBSD, so forgive me if I am missing something obvious. 
> >
> > I recently installed openBSD on a server using the auto-partition layout
> > during installation and am quickly starting to run out of disk space. 
> >
> > I have read the section in the FAQ [1] regarding how to grow a disk
> > partition, but I am confused on the best way to actually do this. 
> >
> > Specifically, I am trying to grow /usr and /home but they are "busy"
> > when I try to follow these steps on a running server. 
> >
> 
> You must umount them first.

Right, the issue is that I am unable to unmount them because they are
actively being used. 
> 
> 
> > Is the assumption that you are supposed to reboot the server with the 
> > ISO attached and pop into a shell to complete these steps?
> >
> > [1] https://www.openbsd.org/faq/faq14.html#GrowPartition
> >
> > -- 
> > Lev Lazinskiy
> >
> 
> If it's a fresh install probably be easier to just reinstall and size 
> partitions how you need them.

This makes sense, but I was curious what the recommended approach is for
a server that you cannot simply reinstall. 

Someone else suggested using single user mode on boot and that approach
seems to work very well. 

> 
> Edgar



Re: Tape drive

2019-11-17 Thread Martin Schröder
Am So., 17. Nov. 2019 um 23:56 Uhr schrieb Pietro Paolini
:
> OpenBSD .my.domain 6.3 GENERIC.MP#9 amd64

Not supported anymore; upgrade to at least 6.5

Best
Martin



Tape drive

2019-11-17 Thread Pietro Paolini
Hi all,

I am currently struggling to get a tape drive to work on a OpenBsd box
I've recently installed, I  must say I am new to this devices (tape
drive) and I have not used them before.

I am running :

OpenBSD .my.domain 6.3 GENERIC.MP#9 amd64

On a x86-64 Dell, the tape drive is an HP StorageWorks Ultrium 960.I
haven't done much to set-up the device and it is apparently getting
recognized as the command sees it:

# mt -f  /dev/rst0 status
SCSI tape drive, residual=0
ds=3
er=0
blocksize: 1024 (1024)
density: 0 (0)

I did set the block type while testing but it does not make any
difference, it seems that I can write with no issues to the device but
I am having issues while reading:

# tar cf /dev/rst0 ./test.txt
# mt -f  /dev/nrst0 rewind
# tar xf /dev/rst0 .out
tar: Failed read on archive volume 1: Input/output error
tar: Unable to recover from an archive read failure.
tar: Sorry, unable to determine archive format.

What can I do to diagnose the problem ? Using other utilities such as
pax did not make any difference.

Thanks,
Pietro



Re: Starting redis fails with 'Bus error (core dumped)'

2019-11-17 Thread Edgar Pettijohn


On Nov 17, 2019 3:21 PM, Consus  wrote:
>
> On 22:05 Sun 17 Nov, Unicorn wrote:
> > On Sun, 2019-11-17 at 23:22 +0300, Consus wrote:
> > > On 16:25 Sun 17 Nov, Unicorn wrote:
> > > > After installing redis (and rspamd), before having modified any
> > > > part of
> > > > redis, starting redis with 'rcctl start redis' fails. I then tried
> > > > running the binary itself in /usr/local/sbin/redis-server, which
> > > > only
> > > > returns 'Bus error (core dumped)'.
> > > > 
> > > > I changed the log level in the '/etc/redis/redis.conf' to debug,
> > > > but do
> > > > not get any more information about the reason for failure. Running
> > > > 'grep -R redis /var/log/' did not give me any information either,
> > > > and
> > > > after changing the log level to debug, the only thing that changed
> > > > is
> > > > an unreadable 'redis-server.core' file appearing in '/var/log'.
> > > 
> > > Please, post the output of
> > > 
> > > # gdb /usr/local/sbin/redis-server /var/log/redis-server.core
> > > 
> > 
> > Output:
> > 
> > GNU gdb 6.3
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and
> > you are
> > welcome to change it and/or distribute copies of it under certain
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for
> > details.
> > This GDB was configured as "arm-unknown-openbsd6.6"...(no debugging
> > symbols found)
> > 
> > Core was generated by `redis-server'.
> > Program terminated with signal 10, Bus error.
> > (no debugging symbols found)
> > Loaded symbols for /usr/local/sbin/redis-server
> > Reading symbols from /usr/lib/libm.so.10.1...done.
> > Loaded symbols for /usr/lib/libm.so.10.1
> > Reading symbols from /usr/lib/libpthread.so.26.1...done.
> > Loaded symbols for /usr/lib/libpthread.so.26.1
> > Reading symbols from /usr/local/lib/liblua5.1.so.5.1...done.
> > Loaded symbols for /usr/local/lib/liblua5.1.so.5.1
> > Reading symbols from /usr/lib/libc.so.95.1...done.
> > Loaded symbols for /usr/lib/libc.so.95.1
> > Reading symbols from /usr/libexec/ld.so...Error while reading shared
> > library symbols:
> > Dwarf Error: wrong version in compilation unit header (is 4, should be
> > 2) [in module /usr/libexec/ld.so]

May need to install egdb from ports. Not sure what the deal is with the damn 
Dwarf but using egdb generally works for me.


> > #0  0x133f3834 in SHA1Final () from /usr/local/sbin/redis-server
> > (gdb) 
>
> Damn it, on Linux it prints backtrace by default. Type `bt' in the gdb
> prompt and post the output.
>



Re: Best Practices for growing disk partitions on a server

2019-11-17 Thread Edgar Pettijohn


On Nov 17, 2019 2:35 PM, Lev Lazinskiy  wrote:
>
> Hi folks, 
>
> I am new to openBSD, so forgive me if I am missing something obvious. 
>
> I recently installed openBSD on a server using the auto-partition layout
> during installation and am quickly starting to run out of disk space. 
>
> I have read the section in the FAQ [1] regarding how to grow a disk
> partition, but I am confused on the best way to actually do this. 
>
> Specifically, I am trying to grow /usr and /home but they are "busy"
> when I try to follow these steps on a running server. 
>

You must umount them first.


> Is the assumption that you are supposed to reboot the server with the 
> ISO attached and pop into a shell to complete these steps?
>
> [1] https://www.openbsd.org/faq/faq14.html#GrowPartition
>
> -- 
> Lev Lazinskiy
>

If it's a fresh install probably be easier to just reinstall and size 
partitions how you need them.

Edgar



Re: Home NAS

2019-11-17 Thread Predrag Punosevac
Patrick Marchand  wrote:

> Hello,
> 
> On 11/15, Predrag Punosevac wrote:
> > Patrick Marchand wrote:
> > > I'll be playing around with DragonflyBSD Hammer2 (and multiple offsite
> > > backups) for a home NAS over the next few weeks. I'll probably do a
> > > presentation about the experience at the Montreal BSD user group
> > > afterwards. It does not require as many ressources as ZFS or BTRFS,
> > > but offers many similar features.
> > >
> >
> > Been there, done that!
> Cool ! I might ping you off-list with questions when I get to it.
> 

Any time. Either this private email or at my work predr...@cs.cmu.edu
I wish I was a bit closer to Montreal to come to your monthly meeting. I
love Quebec and Montreal in particular. 


> > H2 lacks built in backup mechanism. I was hoping that H2 will get some
> > kind "hammer mirror-copy" of H1, or "zfs send/receive". My server is
> > still on H1 and I really enjoy being able to continuously back it up.
> > That's the only thing I am missing in H2. On the positive note H2 did
> > get support for boot environment manager last year.
> >
> > https://github.com/newnix/dfbeadm
> >
> > Also DF jails are stuck in 2004 or something like that. I like their
> > NFSv3.
> I'm not planning on using jails much, instead I'll be using the
> DFly NFS with OpenBSD to experiment with virtualization.
> 


I am not sure that I am following. How is DF NFS server related to
OpenBSD (if I understand correctly) virtualization. Are you trying to
store OpenBSD vmm images on the NFS share exported from a DF server?
That is a really, really bad idea. 


https://marc.info/?l=dragonfly-users=140384130921709=2


> > DragonFly which gets it software RAID discipline through old
> > unmaintained FreeBSD natacontrol utility. Hardware RAID cards are not
> > frequently tested and community seems to be keen on treating DF as a
> > desktop OS rather than a storage workhorse. Having said that HDD are
> > cheap this days and home users probably don't need anything bigger than
> > a 12TB mirror.
> I dont store much anyways, so I'll see as I go.
> 

12 TB is the sweet spot when it comes GB/dollar for platter HDDs. 

Predrag

> Regards



Re: Modifying installXX.iso via script

2019-11-17 Thread chohag
Thomas Bohl writes:
> Am 17.11.2019 um 19:51 schrieb cho...@jtan.com:
> > Thomas Bohl writes:
> >>
> >> Now I want to go the extra step and automate the modification of the
> >> installXX.iso.
> > 
> > I have put an insane amount of work into exactly this, also with
> > an eye to portably directing the process to other operating systems
> > and hosting environments.
>
> Thank you for your quick response. It works now. Even better that the 
> tools in base are enough.
>
> > 
> > I'd be very interested to hear more about what your working on but
>
> Nothing special. Only private stuff. I want to move from to-do lists to 
> scripts. I believe the buzzword is "infrastructure as code" :-)

That is indeed one of the many. Personally I call it "my job" and am doing
my level best to replace myself with a very small shell script. Currently
down to ~3000 lines.

Matthew



Re: Starting redis fails with 'Bus error (core dumped)'

2019-11-17 Thread Consus
On 22:05 Sun 17 Nov, Unicorn wrote:
> On Sun, 2019-11-17 at 23:22 +0300, Consus wrote:
> > On 16:25 Sun 17 Nov, Unicorn wrote:
> > > After installing redis (and rspamd), before having modified any
> > > part of
> > > redis, starting redis with 'rcctl start redis' fails. I then tried
> > > running the binary itself in /usr/local/sbin/redis-server, which
> > > only
> > > returns 'Bus error (core dumped)'.
> > > 
> > > I changed the log level in the '/etc/redis/redis.conf' to debug,
> > > but do
> > > not get any more information about the reason for failure. Running
> > > 'grep -R redis /var/log/' did not give me any information either,
> > > and
> > > after changing the log level to debug, the only thing that changed
> > > is
> > > an unreadable 'redis-server.core' file appearing in '/var/log'.
> > 
> > Please, post the output of
> > 
> > # gdb /usr/local/sbin/redis-server /var/log/redis-server.core
> > 
> 
> Output:
> 
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "arm-unknown-openbsd6.6"...(no debugging
> symbols found)
> 
> Core was generated by `redis-server'.
> Program terminated with signal 10, Bus error.
> (no debugging symbols found)
> Loaded symbols for /usr/local/sbin/redis-server
> Reading symbols from /usr/lib/libm.so.10.1...done.
> Loaded symbols for /usr/lib/libm.so.10.1
> Reading symbols from /usr/lib/libpthread.so.26.1...done.
> Loaded symbols for /usr/lib/libpthread.so.26.1
> Reading symbols from /usr/local/lib/liblua5.1.so.5.1...done.
> Loaded symbols for /usr/local/lib/liblua5.1.so.5.1
> Reading symbols from /usr/lib/libc.so.95.1...done.
> Loaded symbols for /usr/lib/libc.so.95.1
> Reading symbols from /usr/libexec/ld.so...Error while reading shared
> library symbols:
> Dwarf Error: wrong version in compilation unit header (is 4, should be
> 2) [in module /usr/libexec/ld.so]
> #0  0x133f3834 in SHA1Final () from /usr/local/sbin/redis-server
> (gdb) 

Damn it, on Linux it prints backtrace by default. Type `bt' in the gdb
prompt and post the output.



Re: Starting redis fails with 'Bus error (core dumped)'

2019-11-17 Thread Unicorn
On Sun, 2019-11-17 at 23:22 +0300, Consus wrote:
> On 16:25 Sun 17 Nov, Unicorn wrote:
> > After installing redis (and rspamd), before having modified any
> > part of
> > redis, starting redis with 'rcctl start redis' fails. I then tried
> > running the binary itself in /usr/local/sbin/redis-server, which
> > only
> > returns 'Bus error (core dumped)'.
> > 
> > I changed the log level in the '/etc/redis/redis.conf' to debug,
> > but do
> > not get any more information about the reason for failure. Running
> > 'grep -R redis /var/log/' did not give me any information either,
> > and
> > after changing the log level to debug, the only thing that changed
> > is
> > an unreadable 'redis-server.core' file appearing in '/var/log'.
> 
> Please, post the output of
> 
>   # gdb /usr/local/sbin/redis-server /var/log/redis-server.core
> 

Output:

GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "arm-unknown-openbsd6.6"...(no debugging
symbols found)

Core was generated by `redis-server'.
Program terminated with signal 10, Bus error.
(no debugging symbols found)
Loaded symbols for /usr/local/sbin/redis-server
Reading symbols from /usr/lib/libm.so.10.1...done.
Loaded symbols for /usr/lib/libm.so.10.1
Reading symbols from /usr/lib/libpthread.so.26.1...done.
Loaded symbols for /usr/lib/libpthread.so.26.1
Reading symbols from /usr/local/lib/liblua5.1.so.5.1...done.
Loaded symbols for /usr/local/lib/liblua5.1.so.5.1
Reading symbols from /usr/lib/libc.so.95.1...done.
Loaded symbols for /usr/lib/libc.so.95.1
Reading symbols from /usr/libexec/ld.so...Error while reading shared
library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be
2) [in module /usr/libexec/ld.so]
#0  0x133f3834 in SHA1Final () from /usr/local/sbin/redis-server
(gdb) 



Re: Best Practices for growing disk partitions on a server

2019-11-17 Thread Lev Lazinskiy
Hi Brian, 

Thank you very much, I really appreciate the help.
On Sun, Nov 17, 2019 at 03:46:27PM -0500, Brian Brombacher wrote:
> Boot into single user mode.  At the boot loader prompt, type boot -s.  This 
> will drop you to a root shell.
> 
> 
> 
> > On Nov 17, 2019, at 3:39 PM, Lev Lazinskiy  wrote:
> > 
> > Hi folks, 
> > 
> > I am new to openBSD, so forgive me if I am missing something obvious. 
> > 
> > I recently installed openBSD on a server using the auto-partition layout
> > during installation and am quickly starting to run out of disk space. 
> > 
> > I have read the section in the FAQ [1] regarding how to grow a disk
> > partition, but I am confused on the best way to actually do this. 
> > 
> > Specifically, I am trying to grow /usr and /home but they are "busy"
> > when I try to follow these steps on a running server. 
> > 
> > Is the assumption that you are supposed to reboot the server with the 
> > ISO attached and pop into a shell to complete these steps?
> > 
> > [1] https://www.openbsd.org/faq/faq14.html#GrowPartition
> > 
> > -- 
> > Lev Lazinskiy
> > 
> 



Re: Best Practices for growing disk partitions on a server

2019-11-17 Thread Brian Brombacher
Boot into single user mode.  At the boot loader prompt, type boot -s.  This 
will drop you to a root shell.



> On Nov 17, 2019, at 3:39 PM, Lev Lazinskiy  wrote:
> 
> Hi folks, 
> 
> I am new to openBSD, so forgive me if I am missing something obvious. 
> 
> I recently installed openBSD on a server using the auto-partition layout
> during installation and am quickly starting to run out of disk space. 
> 
> I have read the section in the FAQ [1] regarding how to grow a disk
> partition, but I am confused on the best way to actually do this. 
> 
> Specifically, I am trying to grow /usr and /home but they are "busy"
> when I try to follow these steps on a running server. 
> 
> Is the assumption that you are supposed to reboot the server with the 
> ISO attached and pop into a shell to complete these steps?
> 
> [1] https://www.openbsd.org/faq/faq14.html#GrowPartition
> 
> -- 
> Lev Lazinskiy
> 



Re: Home NAS

2019-11-17 Thread Milun Rajkovic
Pardon my ignorance and lack of deeper knowledge regarding the matter, but
since when is XFS not even considered for such uses?
Cheers
Milun

On Sun, Nov 17, 2019, 21:11 Patrick Marchand 
wrote:

> Hello,
>
> On 11/15, Predrag Punosevac wrote:
> > Patrick Marchand wrote:
> > > I'll be playing around with DragonflyBSD Hammer2 (and multiple offsite
> > > backups) for a home NAS over the next few weeks. I'll probably do a
> > > presentation about the experience at the Montreal BSD user group
> > > afterwards. It does not require as many ressources as ZFS or BTRFS,
> > > but offers many similar features.
> > >
> >
> > Been there, done that!
> Cool ! I might ping you off-list with questions when I get to it.
>
> > H2 lacks built in backup mechanism. I was hoping that H2 will get some
> > kind "hammer mirror-copy" of H1, or "zfs send/receive". My server is
> > still on H1 and I really enjoy being able to continuously back it up.
> > That's the only thing I am missing in H2. On the positive note H2 did
> > get support for boot environment manager last year.
> >
> > https://github.com/newnix/dfbeadm
> >
> > Also DF jails are stuck in 2004 or something like that. I like their
> > NFSv3.
> I'm not planning on using jails much, instead I'll be using the
> DFly NFS with OpenBSD to experiment with virtualization.
>
> > DragonFly which gets it software RAID discipline through old
> > unmaintained FreeBSD natacontrol utility. Hardware RAID cards are not
> > frequently tested and community seems to be keen on treating DF as a
> > desktop OS rather than a storage workhorse. Having said that HDD are
> > cheap this days and home users probably don't need anything bigger than
> > a 12TB mirror.
> I dont store much anyways, so I'll see as I go.
>
> Regards
>
>


Best Practices for growing disk partitions on a server

2019-11-17 Thread Lev Lazinskiy
Hi folks, 

I am new to openBSD, so forgive me if I am missing something obvious. 

I recently installed openBSD on a server using the auto-partition layout
during installation and am quickly starting to run out of disk space. 

I have read the section in the FAQ [1] regarding how to grow a disk
partition, but I am confused on the best way to actually do this. 

Specifically, I am trying to grow /usr and /home but they are "busy"
when I try to follow these steps on a running server. 

Is the assumption that you are supposed to reboot the server with the 
ISO attached and pop into a shell to complete these steps?

[1] https://www.openbsd.org/faq/faq14.html#GrowPartition

-- 
Lev Lazinskiy



Re: Moving IKED certificates between routers

2019-11-17 Thread Radek
So.. finally I made it working.

Files to copy:
/etc/iked/ca/ca.crt
/etc/iked/certs/1.2.3.4.crt
/etc/iked/crls/ca.crl
/etc/ssl/vpn/*
/etc/iked/local.pub
/etc/iked/private/local.key

> > If you change the hostname then yes you'll need to a certificate with the
> > new hostname, but then of course you will need to change clients to connect
> > to the new name.
Just for test I changed the hostname to some_new_hostname in /etc/myname and 
rebooted the box. I can still connect to *new* box with my *old* rdk.6501.rac 
certificate.

Tested on Win7 and Win10. 
New box is 6.6/i386.

On Sun, 10 Nov 2019 15:00:58 +0100
Radek  wrote:

> My new box has the same /etc/myname.
> 
> I copied:
> /etc/iked/ca/ca.crt
> /etc/iked/certs/1.2.3.4.crt
> /etc/iked/crls/ca.crl
> /etc/ssl/vpn/*
> 
> What did I do wrong/miss?
> 
> Windows shows error 13826: Failed to verify signature.
> 
> On Sun, 10 Nov 2019 13:30:24 - (UTC)
> Stuart Henderson  wrote:
> 
> > On 2019-11-10, Radek  wrote:
> > > Hi Stuart, 
> > > I have played around with copying them across but no luck (I get error 
> > > 13801 in win7). I don't know what I'm doing wrong.
> > >
> > > Do I need to set the same hostname (/etc/myname) in new box to make old 
> > > certs working?
> > >
> > > In my *old* box certs were created as below:
> > > [1]ikectl ca vpn create #(CN = hostname)
> > > [2]ikectl ca vpn install
> > > [3]ikectl ca vpn certificate 1.2.3.4 create
> > > [4]ikectl ca vpn certificate 1.2.3.4 install
> > > [5]ikectl ca vpn certificate rdk.6501.rac create #(CN = rdk.6501.rac)
> > > [6]ikectl ca vpn certificate rdk.6501.rac export
> > >
> > > What steps do I need to re-run and what exactly files should be 
> > > copied/edited (/etc/ssl/vpn/ /etc/iked/) to make rdk.6501.rac working in 
> > > new box?
> > 
> > Oh, I understood from your email that you were just replacing it 
> > like-for-like.
> > If you change the hostname then yes you'll need to a certificate with the
> > new hostname, but then of course you will need to change clients to connect
> > to the new name.
> > 
> > 
> > >
> > > On Fri, 8 Nov 2019 11:59:56 - (UTC)
> > > Stuart Henderson  wrote:
> > >
> > >> On 2019-11-08, radek  wrote:
> > >> > Hello, 
> > >> >
> > >> > I'm going to replace 6.5 router with new 6.6 box. Is it necessary to 
> > >> > generate new iked certificates in every new installation or there is a 
> > >> > way to move and use "old" certificates in new install? Road warriors 
> > >> > would be happy with that.
> > >> >
> > >> > Thank you for guiding me on this journey.
> > >> >
> > >> 
> > >> Just copy them across.
> > >> 
> > >> 
> > >
> > >
> > 
> 
> 
> -- 
> Radek


-- 
Radek


-- 
Radek



Re: Starting redis fails with 'Bus error (core dumped)'

2019-11-17 Thread Consus
On 16:25 Sun 17 Nov, Unicorn wrote:
> Hello again,
> 
> I am currently setting up redis with rspamd for my mail setup, but I am
> encountering an issue when trying to just start redis.
> For the record, I am following the guide at 
> https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/
> 
> After installing redis (and rspamd), before having modified any part of
> redis, starting redis with 'rcctl start redis' fails. I then tried
> running the binary itself in /usr/local/sbin/redis-server, which only
> returns 'Bus error (core dumped)'.
> 
> I changed the log level in the '/etc/redis/redis.conf' to debug, but do
> not get any more information about the reason for failure. Running
> 'grep -R redis /var/log/' did not give me any information either, and
> after changing the log level to debug, the only thing that changed is
> an unreadable 'redis-server.core' file appearing in '/var/log'.
> 
> I'd very much appreciate your help, thanks in advance!

Please, post the output of

# gdb /usr/local/sbin/redis-server /var/log/redis-server.core



Re: Modifying installXX.iso via script

2019-11-17 Thread Thomas Bohl

Thanks. For completeness what I did for now:
# vnconfig vnd0 install66.iso
# mount -t cd9660 /dev/vnd0c cd/
# cp -r cd cd2

# cp bsd-mod.rd cd2/6.6/amd64/bsd.rd
# cp site66.tgz cd2/6.6/amd64/
# mkhybrid -a -R -T -L -l -d -D -N -o install66a.iso -vv -A "Unofficial 
OpenBSD 6.6 amd64 autoinstall CD" -P "Copyright (c) 2019 Theo de Raadt, 
The OpenBSD project" -p "Thomas Bohl " -V "Unofficial 
OpenBSD/amd64 6.6 CD" -b 6.6/amd64/cdbr -c 6.6/amd64/boot.catalog cd2






Re: Modifying installXX.iso via script

2019-11-17 Thread Thomas Bohl

Am 17.11.2019 um 19:51 schrieb cho...@jtan.com:

Thomas Bohl writes:


Now I want to go the extra step and automate the modification of the
installXX.iso.


I have put an insane amount of work into exactly this, also with
an eye to portably directing the process to other operating systems
and hosting environments.


Thank you for your quick response. It works now. Even better that the 
tools in base are enough.




I'd be very interested to hear more about what your working on but


Nothing special. Only private stuff. I want to move from to-do lists to 
scripts. I believe the buzzword is "infrastructure as code" :-)




meanwhile I think the command you're looking for is some variant
on this:

mkiso() {


Thanks. For completeness what I did for now:
# vnconfig vnd0 install66.iso
# mount -t cd9660 /dev/vnd0c cd/
# cp -r cd cd2
# mkhybrid -a -R -T -L -l -d -D -N -o install66a.iso -vv -A "Unofficial 
OpenBSD 6.6 amd64 autoinstall CD" -P "Copyright (c) 2019 Theo de Raadt, 
The OpenBSD project" -p "Thomas Bohl " -V "Unofficial 
OpenBSD/amd64 6.6 CD" -b 6.6/amd64/cdbr -c 6.6/amd64/boot.catalog cd2




Re: Iked/unbound ~ more info.

2019-11-17 Thread Patrick Dohman


> On Nov 17, 2019, at 11:45 AM, Dale C.  wrote:
> 
> Hi again,
> 
> Still trying to forward DNS to a local unbound resolver on the
> responder of an IKE tunnel.
> 
> Providing more information here. Everything works, but DNS.
> 
> It's worth noting I've tried many, many variations on these configs,
> cannot get DNS to the remote unbound resolver.
> 
> So, my questions are: What is the correct way to forward DNS to a
> local unbound resolver on the responder?
> 
> If there is more information that is helpful, please let me know what
> you need and I'll post it ;)
> 
> Thanks!


Dale
Is it possible to place the ESP nterface in debug?
Can you log PF/UDP traffic on the local unbound?
Regards
Patrick



Re: Home NAS

2019-11-17 Thread Patrick Marchand
Hello,

On 11/15, Predrag Punosevac wrote:
> Patrick Marchand wrote:
> > I'll be playing around with DragonflyBSD Hammer2 (and multiple offsite
> > backups) for a home NAS over the next few weeks. I'll probably do a
> > presentation about the experience at the Montreal BSD user group
> > afterwards. It does not require as many ressources as ZFS or BTRFS,
> > but offers many similar features.
> >
>
> Been there, done that!
Cool ! I might ping you off-list with questions when I get to it.

> H2 lacks built in backup mechanism. I was hoping that H2 will get some
> kind "hammer mirror-copy" of H1, or "zfs send/receive". My server is
> still on H1 and I really enjoy being able to continuously back it up.
> That's the only thing I am missing in H2. On the positive note H2 did
> get support for boot environment manager last year.
>
> https://github.com/newnix/dfbeadm
>
> Also DF jails are stuck in 2004 or something like that. I like their
> NFSv3.
I'm not planning on using jails much, instead I'll be using the
DFly NFS with OpenBSD to experiment with virtualization.

> DragonFly which gets it software RAID discipline through old
> unmaintained FreeBSD natacontrol utility. Hardware RAID cards are not
> frequently tested and community seems to be keen on treating DF as a
> desktop OS rather than a storage workhorse. Having said that HDD are
> cheap this days and home users probably don't need anything bigger than
> a 12TB mirror.
I dont store much anyways, so I'll see as I go.

Regards



Re: Modifying installXX.iso via script

2019-11-17 Thread chohag
Thomas Bohl writes:
>
> Now I want to go the extra step and automate the modification of the 
> installXX.iso.

I have put an insane amount of work into exactly this, also with
an eye to portably directing the process to other operating systems
and hosting environments.

I'd be very interested to hear more about what your working on but
meanwhile I think the command you're looking for is some variant
on this:

mkiso() {
  # Create new iso
  # From src/distrib/amd64/cdfs/Makefile
  if on_openbsd; then
OSREV=$os_version # For easier copy pasta
mkhybrid -a -R -T -L -l -d -D -N -o "$iso_fn" -v -v\
  -A "OpenBSD ${OSREV} amd64 autoinstall CD"   \
  -P "Copyright (c) `date +%Y` Theo de Raadt, The OpenBSD project" \
  -p "Theo de Raadt " \
  -V "OpenBSD/amd64   ${OSREV} boot-only CD"   \
  -b ${OSREV}/amd64/cdbr -c ${OSREV}/amd64/boot.catalog\
  "$s_where"/cd
# -a  all-files
# -R  Rock Ridge
# -T  TRANS.TBL
# -L  Allow .-file
# -l  allow 32char
# -d  Omit trailing period
# -D  not use deep directory relocation, ... Use with caution.
# -N  Omit os_version numbers ... Use with caution.
# -o "$iso_fn"
# -v -v verbose
# -b  boot_image
# -c  boot_catalog

  else
die_unsupported build/target combination
  fi
}

mkhybrid and xorriso are basically the same tool in ways I can't
quite remember right not but could probably be persuaded to. An
invocation of one can be systematically converted into an invocation
of the other.

Enjoy.

Matthew



Modifying installXX.iso via script

2019-11-17 Thread Thomas Bohl

Hello list,

I created an autoinstall bsd.rd (containing auto_install.conf and 
disklabel.conf) and a siteXX.tgz.


For example with the tool isomaster I can manually edit the 
install66.iso and add bsd.rd and site66.tgz to the directory 6.6/amd64. 
This modified ISO can be booted from real and virtual hardware. The 
unattended installation works and is really cool!


Now I want to go the extra step and automate the modification of the 
installXX.iso.


I tried the tool xorriso:
$ ls -l 6.6/amd64/
total 28544
-rwxr-xr-x  1 null  null  10299545 Nov 17 18:00 bsd.rd
-rw-r--r--  1 null  null   4680444 Nov 17 05:03 site66.tgz
$ xorriso -indev install66.iso -outdev install66a.iso -boot_image "any" 
"keep" -add 6.6/amd64/

[1]

This leads to this message when trying to boot:
CD-ROM: E0
Can't find /cdboot

I then moved cdboot from 6.6/amd64 to the root of the CD:
$ xorriso -indev install66.iso -outdev install66a.iso -boot_image "any" 
"keep" -move 6.6/amd64/cdboot cdboot -add 6.6/amd64/


This leads to this message when trying to boot:
CD-ROM: E0
Loading /CDBOOT
probing: pc0 mem[639KB 2046M a20=on]
disk: hd0+ cd0
>> OpenBSD/amd64 CDBOOT 3.44
boot>
cannot open cd0a:/etc/random.seed: No such file or directory
booting cd0a:/6.6/amd64/bsd.rd: open cd0a:/6.6/amd64/bsd.rd: No such 
file or dir

ectory
 failed(2). will try /6.6/amd64/bsd.rd
boot>

When I move bsd.rd to the root of the CD too, I can at least start the 
installation by typing

boot> bsd.rd

But it would be nice if that wouldn't be necessary.

When looking at the ISO files with isomatser, the only difference I can 
find is that

on the modified ISO the publisher information is in all caps.
I'm obviously doing something wrong. Any ideas or alternatives?


[1]
In case the full output is necessary:

$ xorriso -indev install66.iso -outdev install66a.iso -boot_image "any" 
"keep" -add 6.6/amd64/

xorriso 1.4.8 : RockRidge filesystem manipulator, libburnia project.

xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE : 24 nodes read in 1 seconds
xorriso : NOTE : Detected El-Torito boot information which currently is 
set to be discarded

Drive current: -indev 'install66.iso'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Boot record  : El Torito
Media summary: 1 session, 226537 data blocks,  442m data, 62.8g free
Volume id    : 'OpenBSD/amd64   6.6 Install CD'
Drive current: -outdev 'install66a.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 62.8g free
Added to ISO image: directory '/6.6/amd64'='/home/null/OpenBSD66/6.6/amd64'
xorriso : UPDATE : 2 files added in 1 seconds
xorriso : NOTE : Keeping boot image unchanged
xorriso : UPDATE : Writing:   2000s    0.9%   fifo  43%  buf 50%
xorriso : UPDATE : Writing:  23513s   10.3%   fifo  84%  buf 50%   
32.1xD
xorriso : UPDATE : Writing:  45822s   20.0%   fifo  98%  buf 50%   
33.3xD
xorriso : UPDATE : Writing:  68243s   29.8%   fifo  99%  buf 50%   
33.5xD
xorriso : UPDATE : Writing:  93008s   40.6%   fifo 100%  buf 50%   
33.3xD
xorriso : UPDATE : Writing: 114511s   50.0%   fifo  99%  buf 50%   
32.1xD
xorriso : UPDATE : Writing: 133184s   58.2%   fifo  99%  buf 50%   
27.9xD
xorriso : UPDATE : Writing: 154835s   67.6%   fifo 100%  buf 50%   
32.3xD
xorriso : UPDATE : Writing: 176528s   77.1%   fifo  99%  buf 50%   
32.4xD
xorriso : UPDATE : Writing: 197248s   86.1%   fifo  99%  buf 50%   
30.9xD
xorriso : UPDATE : Writing: 218688s   95.5%   fifo 100%  buf 50%   
32.0xD

ISO image produced: 228822 sectors
Written to medium : 228992 sectors at LBA 32
Writing to 'install66a.iso' completed successfully.




Re: Boot failure on XPS 13/9380 (but bsd.rd works)

2019-11-17 Thread chohag
I'd quite like to debug this problem. I'm looking through the code
now to find out where I can inject some sort of printf-like statement
to glean some information about what it's [not] doing and may eventually
even get somewhere.

I'll continue to do this regardless because I'm bored and I just
spent a crapload of money on this thing and I'll be damned if it's
going to not work on me and I want to use _this_ OS goddamnit, but
if anyone can point me to resources to read or other hints about
how to debug code running at such a low level before the OS has had
a chance to take over, they would be greatly appreciated. I've been
coddled for a long time and working on the bare metal like this is
alien to me.

Thanks,

Matthew

ps. Apologies if the list threading is screwed up. I can't reply
to my own messages apparently.



Re: Starting redis fails with 'Bus error (core dumped)'

2019-11-17 Thread Unicorn
On Sun, 2019-11-17 at 16:25 +0100, Unicorn wrote:
> Hello again,
> 
> I am currently setting up redis with rspamd for my mail setup, but I
> am
> encountering an issue when trying to just start redis.
> For the record, I am following the guide at 
> https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/
> 
> After installing redis (and rspamd), before having modified any part
> of
> redis, starting redis with 'rcctl start redis' fails. I then tried
> running the binary itself in /usr/local/sbin/redis-server, which only
> returns 'Bus error (core dumped)'.
> 
> I changed the log level in the '/etc/redis/redis.conf' to debug, but
> do
> not get any more information about the reason for failure. Running
> 'grep -R redis /var/log/' did not give me any information either, and
> after changing the log level to debug, the only thing that changed is
> an unreadable 'redis-server.core' file appearing in '/var/log'.
> 
> I'd very much appreciate your help, thanks in advance!
> 
> Best,
> 
> Unicorn
> 

I forgot to mention that I am running redis on ARMv7, and I think the
issue is that something is broken with ARMv7 and Redis, since it worked
just fine inside a VM on x86_64.

Is there anything I can do to fix this or diagnose it further?

Would really appreciate any suggestions. :)

Best,

Unicorn



Re: Home NAS

2019-11-17 Thread Jean-François Simon
Hi,

I found it, there exist glastree which is available from ports.

Nice small "poor man's" backup as the author qualifies,
though makes incremental backup through hard links:

# if yesterday does not exist or today is newer, copy the file
# else hard link the file to yesterday

Ports: http://ports.su/sysutils/glastree
Source: https://github.com/jeremywohl/glastree

You can simply run it from crontab and even setup a short time daily and long 
time monthly
or what ever else suits best through running the utility with different 
configurations from
multiple crontab lines (daily, monthly, etc ...)

glastree-1.04p0 – poor man's daily snapshot

The poor man's daily snapshot, glastree builds live backup trees, with
branches for each day. Users directly browse the past to recover older
documents or retrieve lost files. Hard links serve to compress out
unchanged files, while modified ones are copied verbatim. A prune
utility effects a constant, sliding window.

Satoru Takabayashi has written a similar program, in Ruby, pdumpfs.

Inspired by Plan9, of course.

Regards,
Jean-Francois

Le 15 nov. 2019 à 11:04, Raf Czlonka a écrit :

> On Fri, Nov 15, 2019 at 08:54:54AM GMT, Andrew Luke Nesbit wrote:
>> On 15/11/2019 10:11, gwes wrote:
>> 
>>> The backup(8) program can assist this by storing deltas so that
>>> more frequent backups only contain deltas from the previous
>>> less frequent backup.
>> 
>> I've not used backup(8) before, thanks for the suggestion.  I will have a
>> look.
>> 
> 
> Hi Andrew,
> 
> There is no backup(8) - gwes either meant a generic "backup" software,
> or dump(8), and restore(8), specifically.
> 
> Regards,
> 
> Raf
> 



Boot failure on XPS 13/9380 (but bsd.rd works)

2019-11-17 Thread chohag
As per the subject, bsd.rd boots and the installation proceeded as
usual. Another laptop saved from ever booting the mess it came
preinstalled with. Yay.

Subsequently rebooting results in the following (bsd.sp does the
same with different addresses):

probing: pc0 mem[632K 475M 255M 208M 137M 150080M]
disk: hd0
>> OpenBSD/amd64 BOOTX64 3.46
boot>
booting hd0a:/bsd: 12748104+2941960+34+0+708608 [986153/


I tried booting the 6.5 installer to see if I could find a point
between in which it broke but it stops every time after the kernel's
penultimate line (between 'scsibus2 at softraid0: 256 targets' and
reporting the root device).

Interestingly 6.6 also did this once which was seemingly related
to having warm-booted immediately prior but it only did it the once
whereas 6.5 seems to be consistent. Nevertheless I wasn't paying
attention to what the 6.6 installer was doing at the time so I'll
look into that some more.

I traced the boot process through to loadfile in libsa so I know
that it's stuck while reading the ELF symbols (it gets at least as
far as the first PROGRESS line after "Now load the symbol sections
themselves") but that's probably obvious to whoever knows the boot
code. Personally I haven't much clue what should be happening and
it's clearly not happening as it should anyway so I don't know what
to poke at to get more clues to fall out.

The below was extracted by running sendbug -P from within the
installed OS (chroot) while running the 6.6 bsd.rd and then doing
whatever crazy thing I'm going to need to do to get them onto here.
It complained about a lack of /var/db/acpi/* so if they're useful
and can be generated from the ramdisk kernel then I can get them
too. The dmesg is from the installer's /var.

Matthew


OpenBSD 6.6 (RAMDISK_CD) #349: Sat Oct 12 11:03:52 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 16924401664 (16140MB)
avail mem = 16407494656 (15647MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xe (101 entries)
bios0: vendor Dell Inc. version "1.5.0" date 06/03/2019
bios0: Dell Inc. XPS 13 9380
acpi0 at bios0: ACPI 6.1
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT BOOT SSDT HPET SSDT SSDT UEFI 
LPIT SSDT SSDT DBGP DBG2 SSDT SSDT MSDM SLIC DMAR SSDT NHLT TPM2 BGRT
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 7517.90 MHz, 06-8e-0c
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus -1 (RP01)
acpiprt5 at acpi0: bus -1 (RP02)
acpiprt6 at acpi0: bus -1 (RP03)
acpiprt7 at acpi0: bus -1 (RP04)
acpiprt8 at acpi0: bus 1 (RP05)
acpiprt9 at acpi0: bus -1 (RP06)
acpiprt10 at acpi0: bus 2 (RP07)
acpiprt11 at acpi0: bus -1 (RP08)
acpiprt12 at acpi0: bus -1 (RP09)
acpiprt13 at acpi0: bus -1 (RP10)
acpiprt14 at acpi0: bus -1 (RP11)
acpiprt15 at acpi0: bus -1 (RP12)
acpiprt16 at acpi0: bus 3 (RP13)
acpiprt17 at acpi0: bus -1 (RP14)
acpiprt18 at acpi0: bus -1 (RP15)
acpiprt19 at acpi0: bus -1 (RP16)
acpiprt20 at acpi0: bus -1 (RP17)
acpiprt21 at acpi0: bus -1 (RP18)
acpiprt22 at acpi0: bus -1 (RP19)
acpiprt23 at acpi0: bus -1 (RP20)
acpiprt24 at acpi0: bus -1 (RP21)
acpiprt25 at acpi0: bus -1 (RP22)
acpiprt26 at acpi0: bus -1 (RP23)
acpiprt27 at acpi0: bus -1 (RP24)
acpiec0 at acpi0
acpiec at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpicpu at acpi0 not configured
acpitz at acpi0 not configured
acpipwrres at acpi0 not configured
"PNP0A08" at acpi0 not configured
acpicmos0 at acpi0
"INT3403" at acpi0 not configured
"INT3403" at acpi0 not configured
"INT3403" at acpi0 not configured
"INT3403" at acpi0 not configured
"INT3403" at acpi0 not configured
"INT34BB" at acpi0 not configured
"ELAN2930" at acpi0 not configured
"DELL08AF" at acpi0 not configured
"INT3403" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured

Starting redis fails with 'Bus error (core dumped)'

2019-11-17 Thread Unicorn
Hello again,

I am currently setting up redis with rspamd for my mail setup, but I am
encountering an issue when trying to just start redis.
For the record, I am following the guide at 
https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/

After installing redis (and rspamd), before having modified any part of
redis, starting redis with 'rcctl start redis' fails. I then tried
running the binary itself in /usr/local/sbin/redis-server, which only
returns 'Bus error (core dumped)'.

I changed the log level in the '/etc/redis/redis.conf' to debug, but do
not get any more information about the reason for failure. Running
'grep -R redis /var/log/' did not give me any information either, and
after changing the log level to debug, the only thing that changed is
an unreadable 'redis-server.core' file appearing in '/var/log'.

I'd very much appreciate your help, thanks in advance!

Best,

Unicorn



Re: Cron not executing @reboot command in crontab

2019-11-17 Thread Unicorn
> At the top of the file you'll see:
> 
>   PATH=/bin:/sbin:/usr/bin:/usr/sbin
> 
> Either {pre,ap}pend /usr/local/{,s}bin or use the full command path.
> 
> Regards,
> 
> Raf
> 

> Use a full path. cran has a very limited default PATH.
>
>   -Otto


Thank you both, it works perfectly now!

Best,

Unicorn



Re: Cron not executing @reboot command in crontab

2019-11-17 Thread Raf Czlonka
On Sun, Nov 17, 2019 at 11:57:44AM GMT, Unicorn wrote:
> Hello,
> 
> I apologize if this is trivial, I genuinely read through all the cron-
> related manpages and tried several things, but this is my issue:
> 
> I want to use 'autossh' to automatically establish reverse port
> forwarding on boot, so (as root) I can 'crontab -e' and added this line
> to the bottom:
> 
> @reboot autossh [all my options]
> 
> After adding the line, running 'crontab -l' shows that the line was
> correctly added; I have also confirmed that the 'autossh ...' part
> works perfectly when I just execute it in a terminal. When I reboot the
> system though, nothing happens.
> 
> Even if I restart cron with rcctl, nothing happens. I even confirmed
> that sshd is started before cron in rc, I have tried everything I could
> come up with, I just have no clue what I'm missing.
> 
> Since I am new to OpenBSD, I would appreciate your advice or any clues
> on what I have done wrong. Regarding system setup, this is a completely
> bare system, I have just run 'sysupgrade -s' and installed autossh.
> 
> Thank you in advance!
> 

At the top of the file you'll see:

PATH=/bin:/sbin:/usr/bin:/usr/sbin

Either {pre,ap}pend /usr/local/{,s}bin or use the full command path.

Regards,

Raf



Re: Cron not executing @reboot command in crontab

2019-11-17 Thread Otto Moerbeek
On Sun, Nov 17, 2019 at 12:57:44PM +0100, Unicorn wrote:

> Hello,
> 
> I apologize if this is trivial, I genuinely read through all the cron-
> related manpages and tried several things, but this is my issue:
> 
> I want to use 'autossh' to automatically establish reverse port
> forwarding on boot, so (as root) I can 'crontab -e' and added this line
> to the bottom:
> 
> @reboot autossh [all my options]
> 
> After adding the line, running 'crontab -l' shows that the line was
> correctly added; I have also confirmed that the 'autossh ...' part
> works perfectly when I just execute it in a terminal. When I reboot the
> system though, nothing happens.
> 
> Even if I restart cron with rcctl, nothing happens. I even confirmed
> that sshd is started before cron in rc, I have tried everything I could
> come up with, I just have no clue what I'm missing.
> 
> Since I am new to OpenBSD, I would appreciate your advice or any clues
> on what I have done wrong. Regarding system setup, this is a completely
> bare system, I have just run 'sysupgrade -s' and installed autossh.
> 
> Thank you in advance!
> 

Use a full path. cran has a very limited default PATH.

-Otto



Cron not executing @reboot command in crontab

2019-11-17 Thread Unicorn
Hello,

I apologize if this is trivial, I genuinely read through all the cron-
related manpages and tried several things, but this is my issue:

I want to use 'autossh' to automatically establish reverse port
forwarding on boot, so (as root) I can 'crontab -e' and added this line
to the bottom:

@reboot autossh [all my options]

After adding the line, running 'crontab -l' shows that the line was
correctly added; I have also confirmed that the 'autossh ...' part
works perfectly when I just execute it in a terminal. When I reboot the
system though, nothing happens.

Even if I restart cron with rcctl, nothing happens. I even confirmed
that sshd is started before cron in rc, I have tried everything I could
come up with, I just have no clue what I'm missing.

Since I am new to OpenBSD, I would appreciate your advice or any clues
on what I have done wrong. Regarding system setup, this is a completely
bare system, I have just run 'sysupgrade -s' and installed autossh.

Thank you in advance!