Re: Home NAS
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
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&m=140384130921709&w=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
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
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
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
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)'
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
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
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&m=140384130921709&w=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
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)'
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)'
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
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
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
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
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
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)'
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
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
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.
> 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
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
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
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)
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)'
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
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)
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)'
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
> 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
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
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
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!