sndiod opening device in record-only mode

[tomr]

Hi Folks,

I'm struggling to get sndiod working on a Thinkpad X1 Carbon, running a
recent snapshot with stock kernel. Ideally I want concurrency... at the
moment I can't get a single output stream to work.

### start sndiod with debug output:

$ doas sndiod -ddd
snd0 pst=cfg.default: rec=0:1 play=0:1 vol=23170 dup
helper(helper|ini): created
worker(worker|ini): created
listen(/tmp/aucat/aucat0|ini): created

### run `aucat -i recording.wav` in another terminal
### for the first time:

sock(sock|ini): created
helper: recv: cmd = 0, num = 0, mode = 3, fd = -1
helper: send: cmd = 3, num = 0, mode = 0, fd = -1
helper: recv: cmd = 0, num = 0, mode = 1, fd = -1
helper: send: cmd = 3, num = 0, mode = 0, fd = -1
helper: recv: cmd = 0, num = 0, mode = 2, fd = -1
helper: send: cmd = 3, num = 0, mode = 0, fd = 3
sock,rmsg,widl: AUTH message
sock,rmsg,widl: HELLO message
sock,rmsg,widl: hello from , mode = 1, ver 7
sock,rmsg,widl: using snd0 pst=cfg.default, mode = 1
aucat0: overwritten slot 0
snd0 pst=cfg: device requested
worker: send: cmd = 0, num = 0, mode = 3, fd = -1
worker: recv: cmd = 3, num = 0, mode = 0, fd = -1
worker: send: cmd = 0, num = 0, mode = 1, fd = -1
worker: recv: cmd = 3, num = 0, mode = 0, fd = -1
worker: send: cmd = 0, num = 0, mode = 2, fd = -1
worker: recv: cmd = 3, num = 0, mode = 0, fd = 6
warning, device opened in rec-only mode
sio(rsnd/0|ini): created
snd0 pst=ini: 48000Hz, s16le, rec 0:1, 8 blocks of 960 frames
aucat0 vol=127,pst=ini,mmc=off: requested mode not supported
sock,rmsg,widl: closing
sock(sock|zom): destroyed

### every subsequent `aucat -i recording.wav` produces
### output in sndiod like this:

sock(sock|ini): created
sock,rmsg,widl: AUTH message
sock,rmsg,widl: HELLO message
sock,rmsg,widl: hello from , mode = 1, ver 7
sock,rmsg,widl: using snd0 pst=ini.default, mode = 1
aucat1: overwritten slot 1
snd0 pst=ini: device requested
aucat1 vol=127,pst=ini,mmc=off: requested mode not supported
sock,rmsg,widl: closing
sock(sock|zom): destroyed



I guess the messages "warning, device opened in rec-only mode" and
"requested mode not supported" are key here, but I'm stumped as to how
to specify a different mode.

If I kill sndiod, I can get any single programme (aucat, firefox) to
play audio just fine directly to /dev/audio0. Sound in appears to be
okay although I've not looked at it in depth.

TIA for any advice,
Tom


$ mixerctl
inputs.dac-0:1=174,174
inputs.dac-2:3=174,174
record.adc-2:3_mute=off
record.adc-2:3=124,124
record.adc-0:1_mute=off
record.adc-0:1=124,124
inputs.mix_source=mic2,beep
inputs.mix_mic2=120,120
inputs.mix_beep=120,120
inputs.mix2_source=dac-0:1,mix
inputs.mix3_source=dac-2:3,mix
inputs.mic=85,85
outputs.spkr_source=mix3
outputs.spkr_mute=off
outputs.spkr_eapd=on
outputs.hp_source=mix2
outputs.hp_mute=off
outputs.hp_boost=off
outputs.hp_eapd=on
outputs.mic2_source=mix2
outputs.mic2_mute=off
inputs.mic2=85,85
outputs.mic2_dir=input-vr80
record.adc-0:1_source=mic2,beep,mix,mic
record.adc-2:3_source=mic2,beep,mix
outputs.hp_sense=unplugged
outputs.mic2_sense=unplugged
outputs.spkr_muters=hp,mic2
outputs.master=200,200
outputs.master.mute=off
outputs.master.slaves=dac-0:1,dac-2:3,spkr,hp
record.volume=124,124
record.volume.mute=off
record.volume.slaves=adc-2:3,adc-0:1
$ dmesg
OpenBSD 6.0-current (GENERIC.MP) #2345: Tue Aug  9 23:00:50 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8255741952 (7873MB)
avail mem = 8001060864 (7630MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (68 entries)
bios0: vendor LENOVO version "G6ET96WW (2.56 )" date 04/29/2013
bios0: LENOVO 34486T7
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT
ASF! UEFI UEFI MSDM SSDT SSDT UEFI SSDT DBG2
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3)
EHC1(S3) EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 798.32 MHz
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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 798.19 MHz
cpu1:

Re: DPB can't do it's job in 6.0

[Noth]

On 22/08/16 17:29, trondd wrote:

On Mon, August 22, 2016 11:17 am, Noth wrote:

Once that's all sorted out building works as root with dpb subdir/port.
However I can't seem to make it use my list of ports to build, it just
complains about a bad pkgpath.

Where do you have the file containing the list?  Even on 5.9 you can't
have it in certain places (such as /root) because it'll interprete that as
a pkgpath.

Tim.



Hm it is in /root... If I move it to /home it's no longer an issue. Thanks!

Re: DPB can't do it's job in 6.0

[trondd]

On Mon, August 22, 2016 11:17 am, Noth wrote:
> Once that's all sorted out building works as root with dpb subdir/port.
> However I can't seem to make it use my list of ports to build, it just
> complains about a bad pkgpath.

Where do you have the file containing the list?  Even on 5.9 you can't
have it in certain places (such as /root) because it'll interprete that as
a pkgpath.

Tim.

Re: DPB can't do it's job in 6.0

[Noth]

OK I've worked out most of the problem: permissions and ownership of course!

/usr/ports/distfiles must be owned by _pfetch:_pfetch
/usr/ports/logs /usr/ports/packages /usr/ports/plist /usr/ports/pobj 
need to be owned by  _pbuild:_pbuild .


Also, if you're signing with your own key, it must also be owned by 
_pbuild:_pbuild .


Once that's all sorted out building works as root with dpb subdir/port. 
However I can't seem to make it use my list of ports to build, it just 
complains about a bad pkgpath. This functionality worked in 5.9, doesn't 
anymore, which is rather annoying.


Cheers,

Noth

Re: Fwd: spamd question

[Peter N. M. Hansteen]

On Mon, Aug 22, 2016 at 04:06:22PM +0200, Kasper Haitsma wrote:
> I have a question regarding the differences between spamd-
> ???sync???
> on OpenBSD 5.0 and OpenBSD 5.9.
> ??? I read this article
>  ???, but there is
> no indication if this applies to my situation or not.

That's a commit that happened in 2008. OpenBSD 5.0 was released in 2011.

OpenBSD 5.0 has been out of support for a while, but this particular change 
should
not be directly relevant to your particular upgrade scenario.

I see you start your spamds with the -v option. That means that you should be
able to see log entries for syncs wherever your spamd is set up to log to (check
your syslog.conf), something like

Aug 22 16:16:27 skapet spamd[65037]: new entry 216.126.230.221 from 
 to , helo reliefs.herpprotcol.eu

If you see something similar, your're good for that part at least.

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Fwd: spamd question

[Kasper Haitsma]

Hello,

​Although I have 25 + years of unix/linux experience, this is my first
encounter with OpenBSD.​ I have learned a lot over the past weeks, but the
issue below is puzzling me:

I have a question regarding the differences between spamd-
​sync​
on OpenBSD 5.0 and OpenBSD 5.9.
​ I read this article
 ​, but there is
no indication if this applies to my situation or not.


Currently, 2 OpenBSD 5.0 mail-servers sync their spamd entries successfully.
Since these servers need upgrading to OpenBSD 5.9, new servers will be
deployed.
The idea is, to replace them one at a time.

​To get the spamd-synced to a new servers, I added one of them as extra
target (-Y ) to one of the operational hosts.
=
/etc/rc.conf.local  <5.0-1>

spamd_flags="-4 -G25:4:864 -h <5.0-1> -l127.0.0.1 -n \"Sendmail
8.11.4/8.11.1\" -S10 -s1 -v -w1 -y bnx0 -Y  -Y "
spamd_black=NO
spamlogd_flags="-I -i lo0"

/etc/rc.conf.local  <5.9-1>

spamd_black=NO
spamd_flags="-4 -G25:4:864 -h <5.9-1> -l127.0.0.1 -n \"Sendmail
8.11.4/8.11.1\" -S10 -s1 -v -w1 -y bge1 -Y "
spamlogd_flags="-I -i lo0"
​=​

​host <5.0-1> is successfully ​sending spamd-sync packets to host <5.9-1>
​=​
​root@<5.9-1> ~# tcpdump -i bge1 port 8025
tcpdump: listening on bge1, link-type EN10MB
15:44:21.056732 <5.0-1>.spamd-sync > <5.9-1>.spamd-sync: udp 164
15:44:22.679540 <5.0-1>.spamd-sync > <5.9-1>.spamd-sync: udp 132
15:44:23.453386 <5.0-1>.spamd-sync > <5.9-1>.spamd-sync: udp 132
15:44:23.804945 <5.0-1>.spamd-sync > <5.9-1>.spamd-sync: udp 148
15:44:24.242281 <5.0-1>.spamd-sync > <5.9-1>.spamd-sync: udp 132

^C
2475 packets received by filter
0 packets dropped by kernel
root@<5.9-1> ~#
=​





Thanks,
Kasper

Re: Upgrading from 5.8 to 5.9: Can't install patches

[Stuart Henderson]

On 2016-08-19, Jay Hart  wrote:
>> On 2016/08/19 14:48, Jay Hart wrote:
>>>
>>> Thank You Stuart. I can get moving ahead and will file this as a new 
>>> process moving forward.
>>>
>>> One last item: When sysmerge ran the only 'file' it came up with to merge 
>>> was the cert file. I
> installed the new temp file as presented to me.  Are there other files I need 
> to check?  Did I
> do
>>> right?
>>
>> In most cases, if you didn't edit a config file, sysmerge can update it 
>> automatically without
> you having to do anything, so there aren't usually many to merge by hand. Do 
> check over the
> upgrade notes if you haven't already though.
>>
>>
>
> Are the upgrade notes (referenced above) the notes associated on the openbsd 
> page for upgrading
> say, from 5.8 to 5.9?

Yes e.g. http://www.openbsd.org/faq/upgrade59.html

> I noticed there are a significant number of patches that require a kernel 
> rebuild.  Can I apply
> all patches and then do one kernel compile at the end?  If I go this route, I 
> assume I need to
> apply/compile all the patches that do not require a kernel compile, then do 
> the one kernel compile
> last?
>
> I usually just install the patches as they come out (usually don't have 25 to 
> do), hence why I'm
> asking.
>
> I'm currently compiling patch #2, and would like to avoid a very lengthy 
> process.

You can apply the patches and do one kernel compile. (Although
after you've done one, it shouldn't take too long to do another as
most of the source files will be the same).

> DDclient: sysmerge stated I needed to check the config file.  I noticed that 
> the user may be
> different from original user (I have to check this) but I consider this a 
> minor item I can deal
> with in a few days.  Reboot will take care of short-term issues, if any...

I have no idea about ddclient.

Re: multiple python version

[lists]

Mon, 22 Aug 2016 16:39:13 +0530 Jay Patel 
> Hi Anton,
> 
> what i did was:
> 1. mkdir /home/user/pyv2710
> 
> 2. wget  http::/url-to-py-2.7.10.tgz
> 
> 3. extract tar
> 
> 4. ./configure --prefix=$HOME/user/pyv2710  && make && make install
> 
> now used this installed binary with virtualenv
> 
> 5. virtualenv  -p $HOME/user/pyv2710/bin/python2.7  venv
> 
> Regards,
> 
> Jay
> 
> 
> On Mon, Aug 22, 2016 at 3:03 PM,  wrote:
> 
> > Mon, 22 Aug 2016 13:19:07 +0530 Jay Patel   
> > > Hi .. solution fron John works fperfect with OpenBSD 5.9 :D
> > >
> > > On Mon, Aug 22, 2016 at 1:57 AM,  wrote:
> > >  
> > > > Wed, 17 Aug 2016 11:06:30 +0530 Jay Patel   
> > > > > Thanks scott. I will look into it. I found john's solution easy  
> > though.  
> > > >
> > > > Well, search for the tools that allow you the language environment
> > > > setup rather then demand that from the operating system, until you
> > > > find that language operating system aware enough to implement main
> > > > security mitigation measures on top of CPU features.  Good luck!!!
> > > >
> > > > I.E. Try the environment setup in your $HOME for your chosen lang.
> > > >  
> >
> > Hi Jay,
> >
> > It seems that post is either missing or unclear, are you referring to
> > pyenv, virtualenv, or some other method, please specify or post link.
> >
> > Kind regards,
> > Anton
> >  

Hi Jay,

Very well, that's what I figured you would've done (virtualenv direct)
too.  I'd have proceeded very similarly and wanted it for the archives
as a reusable tip for others should they need it, thanks for replying.

If there'd be a better ('pythonic' here) lang specific way to proceed,
using pkg_tols, anyone have that, please add something to this thread?

Kind regards,
Anton

Re: multiple python version

[lists]

Mon, 22 Aug 2016 13:19:07 +0530 Jay Patel 
> Hi .. solution fron John works fperfect with OpenBSD 5.9 :D
> 
> On Mon, Aug 22, 2016 at 1:57 AM,  wrote:
> 
> > Wed, 17 Aug 2016 11:06:30 +0530 Jay Patel   
> > > Thanks scott. I will look into it. I found john's solution easy though.  
> >
> > Well, search for the tools that allow you the language environment
> > setup rather then demand that from the operating system, until you
> > find that language operating system aware enough to implement main
> > security mitigation measures on top of CPU features.  Good luck!!!
> >
> > I.E. Try the environment setup in your $HOME for your chosen lang.
> >  

Hi Jay,

It seems that post is either missing or unclear, are you referring to
pyenv, virtualenv, or some other method, please specify or post link.

Kind regards,
Anton

Re: DUMP: fopen on /dev/tty fails: Device not configured

[Jan Stary]

On Aug 22 10:54:38, h...@stare.cz wrote:
> On Aug 22 00:34:49, guent...@gmail.com wrote:
> > On Mon, 22 Aug 2016, Jan Stary wrote:
> > > Occasionally, this what tha daily dump of my 5.9-beta/i386 says:
> > ...
> > 
> > > >   DUMP: Volume 1 started at: Mon Aug 22 01:30:25 2016
> > > >   DUMP: dumping (Pass III) [directories]
> > > >   DUMP: dumping (Pass IV) [regular files]
> > > >   DUMP: End of tape detected
> > ...
> > > The daily.local is below - basically just a wrapper
> > > around the dumps and tars. The dump call itself is
> > >   
> > >   dump -$l -a -u -f - $fs > $f 2> $BKPLOG
> > 
> > The "End of tape detected" message means write() failed or repeatedly 
> > refused to write the full output.  For a disk file like you're using, that 
> > probably means one of these errors:
> >  - ENOSPC: file system full (out of disk blocks)
> >  - EDQUOT: reached user's disk quota
> >  - EFBIG: reached the file size limit (ala ulimit -f)
> >  - EIO: disk is dying
> > 
> > If you're sure that it *can't* be any of those, then I suppose you could 
> > hack dump to report the exact error...
> 
> Ah, I forgot I had this problem before:
> https://www.mail-archive.com/misc@openbsd.org/msg135224.html
> 
> I tend to think now it's the disk space. This was a Monday morning dump,
> when the /backup is "most full" with the previous week's dumps.[0-6].
> I rm(1) them before doing the fresh dump, but that space probably
> only becomes available a bit later due to softdeps (I think).

... and so dump(8) wants to ask about the next volume,
but there is no terminal, as this is a crin job
- resulting in the err msg.

Re: DUMP: fopen on /dev/tty fails: Device not configured

[Jan Stary]

On Aug 22 00:34:49, guent...@gmail.com wrote:
> On Mon, 22 Aug 2016, Jan Stary wrote:
> > Occasionally, this what tha daily dump of my 5.9-beta/i386 says:
> ...
> 
> > >   DUMP: Volume 1 started at: Mon Aug 22 01:30:25 2016
> > >   DUMP: dumping (Pass III) [directories]
> > >   DUMP: dumping (Pass IV) [regular files]
> > >   DUMP: End of tape detected
> ...
> > The daily.local is below - basically just a wrapper
> > around the dumps and tars. The dump call itself is
> >   
> > dump -$l -a -u -f - $fs > $f 2> $BKPLOG
> 
> The "End of tape detected" message means write() failed or repeatedly 
> refused to write the full output.  For a disk file like you're using, that 
> probably means one of these errors:
>  - ENOSPC: file system full (out of disk blocks)
>  - EDQUOT: reached user's disk quota
>  - EFBIG: reached the file size limit (ala ulimit -f)
>  - EIO: disk is dying
> 
> If you're sure that it *can't* be any of those, then I suppose you could 
> hack dump to report the exact error...

Ah, I forgot I had this problem before:
https://www.mail-archive.com/misc@openbsd.org/msg135224.html

I tend to think now it's the disk space. This was a Monday morning dump,
when the /backup is "most full" with the previous week's dumps.[0-6].
I rm(1) them before doing the fresh dump, but that space probably
only becomes available a bit later due to softdeps (I think).
I will see whether it happens other then Mondays.

Thanks for the hints.

Jan



> 
> ...
> > >   DUMP: fopen on /dev/tty fails: Device not configured
> > >   DUMP: The ENTIRE dump is aborted.
> ...
> > I wonder how exactly does dump find /dev/tty "not configured". Is the 
> > redirection of stdout what makes dump deal with tty in the first place?
> > When I log into the machine an run sh /etc/daily.local manually,
> > everything goes fine. Most nights, the daily.local cronjob goes fine too.
> 
> When a process opens /dev/tty, the kernel (mostly) acts like it opened its 
> controlling terminal device, whichever that is.  If it doesn't have a 
> controlling terminal then you get that error.  c.f. cttyopen() and the 
> cttyvp() macro in sys/kern/tty_tty.c
> 
> 
> Philip Guenther

Re: DUMP: fopen on /dev/tty fails: Device not configured

[Philip Guenther]

On Mon, 22 Aug 2016, Jan Stary wrote:
> Occasionally, this what tha daily dump of my 5.9-beta/i386 says:
...

> >   DUMP: Volume 1 started at: Mon Aug 22 01:30:25 2016
> >   DUMP: dumping (Pass III) [directories]
> >   DUMP: dumping (Pass IV) [regular files]
> >   DUMP: End of tape detected
...
> The daily.local is below - basically just a wrapper
> around the dumps and tars. The dump call itself is
>   
>   dump -$l -a -u -f - $fs > $f 2> $BKPLOG

The "End of tape detected" message means write() failed or repeatedly 
refused to write the full output.  For a disk file like you're using, that 
probably means one of these errors:
 - ENOSPC: file system full (out of disk blocks)
 - EDQUOT: reached user's disk quota
 - EFBIG: reached the file size limit (ala ulimit -f)
 - EIO: disk is dying

If you're sure that it *can't* be any of those, then I suppose you could 
hack dump to report the exact error...


...
> >   DUMP: fopen on /dev/tty fails: Device not configured
> >   DUMP: The ENTIRE dump is aborted.
...
> I wonder how exactly does dump find /dev/tty "not configured". Is the 
> redirection of stdout what makes dump deal with tty in the first place?
> When I log into the machine an run sh /etc/daily.local manually,
> everything goes fine. Most nights, the daily.local cronjob goes fine too.

When a process opens /dev/tty, the kernel (mostly) acts like it opened its 
controlling terminal device, whichever that is.  If it doesn't have a 
controlling terminal then you get that error.  c.f. cttyopen() and the 
cttyvp() macro in sys/kern/tty_tty.c


Philip Guenther

DUMP: fopen on /dev/tty fails: Device not configured

[Jan Stary]

Occasionally, this what tha daily dump of my 5.9-beta/i386 says:

On Aug 22 01:31:17, r...@gw.stare.cz wrote:
> OpenBSD 5.9-beta (GENERIC) #1462: Wed Dec 23 18:11:06 MST 2015
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> 
>  1:31AM  up 152 days, 14:26, 0 users, load averages: 2.74, 0.92, 0.39
> 
> Running daily.local:
> 
> Backing up into /backup/gw.stare.cz
> 
> errors dumping /var/log:
>   DUMP: Date of this level 0 dump: Mon Aug 22 01:30:24 2016
>   DUMP: Date of last level 0 dump: the epoch
>   DUMP: Dumping /dev/rwd0g (/var/log) to standard output
>   DUMP: mapping (Pass I) [regular files]
>   DUMP: mapping (Pass II) [directories]
>   DUMP: estimated 118923 tape blocks.
>   DUMP: Volume 1 started at: Mon Aug 22 01:30:25 2016
>   DUMP: dumping (Pass III) [directories]
>   DUMP: dumping (Pass IV) [regular files]
>   DUMP: End of tape detected
>   DUMP: Volume 1 completed at: Mon Aug 22 01:31:00 2016
>   DUMP: Volume 1 took 0:00:35
>   DUMP: Volume 1 transfer rate: 3213 KB/s
>   DUMP: Change Volumes: Mount volume #2
>   DUMP: fopen on /dev/tty fails: Device not configured
>   DUMP: The ENTIRE dump is aborted.

The daily.local is below - basically just a wrapper
around the dumps and tars. The dump call itself is
  
dump -$l -a -u -f - $fs > $f 2> $BKPLOG

I wonder how exactly does dump find /dev/tty "not configured".
Is the redirection of stdout what makes dump deal with tty in the first place?
When I log into the machine an run sh /etc/daily.local manually,
everything goes fine. Most nights, the daily.local cronjob goes fine too.

Jan


#!/bin/sh

umask 077

err() {
echo $@ >&2
}

# We distinguish two kinds of backups:
# BKPDUMP are dump(8)s of entire filesystems - level 0
# on Monday mornings, incerementals during the week.
# These are typically very big, and we store them to
# a dedicated backup disk; typically nfs:/backup
# BKPTAR are tarballs of certain directories (/etc),
# that are tupically much smaller and we rotate them.
# TODO: rotate the old ones out of existence.
# If BKPSCP is defined, we also scp them there. This
# requires an unattended login via a ssh key.

BKPUSR=hans
BKOGRP=wheel
BKPLOG=/tmp/dump.$$.log
BKPDIR=/backup/`hostname`

BKPDMP="/ /var /var/log /home"
BKPTAR="/root /etc /var/backups"
BKPSCP="h...@stare.cz:$BKPDIR"
#BKPSCP="h...@biblio.stare.cz:$BKPDIR"

bkpdmp() {
# $1 is the dump level
l=$1
for fs in $BKPDMP; do
[ "$fs" = "/" ] && fsname=".root" || fsname=`echo $fs | tr / .`
[ "x$l" = "x0" ] && \
 rm -f $BKPDIR/dump$fsname.?
f=$BKPDIR/dump$fsname.$l
> $f && chown $BKPUSR:$BKPGRP $f && chmod 600 $f
dump -$l -a -u -f - $fs > $f 2> $BKPLOG \
|| { err errors dumping $fs: ; cat $BKPLOG >&2 ; }
rm -f $BKPLOG
done
{ cd $BKPDIR ; ls -lh dump.* ; }
}

bkptar() {
for dir in $BKPTAR; do
f=$BKPDIR/`echo ${dir#/} | tr / -`-`date +%Y%m%d%H%M`.tar.gz
> $f && chown $BACKUPUSR:$BACKUPGRP $f && chmod 600 $f
tar czf $f $dir 2> /dev/null 
# TODO: md5
{ cd $BKPDIR ; ls -lh ${f##*/} ; }
scp -q $f $BKPSCP
done
}

if test -d $BKPDIR ; then
echo; echo Backing up into $BKPDIR; echo
bkpdmp $((`date +%u` - 1)) 
bkptar
else
err Backup directory $BKPDIR does not exist
fi