Re: Kerberos URL
On Sat, May 07, 2011 at 09:28:48PM -0500, Markus Peloquin wrote: On Fri, 2011-05-06 at 16:20 +0100, Jason McIntyre wrote: On Fri, May 06, 2011 at 09:39:48AM -0500, Vijay Sankar wrote: man 8 kerberos has the following URL http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html It should be http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html kerberos docs are maintained by the kerberos (heimdal) project. you should check whether their latest source has this problem and send them your fix if it does. jmc For some reason, OpenBSD is six releases behind on heimdal (0.8, 1.0, ..., 1.4). It strikes me as odd, especially when heimdal is using a liberal license (unlike gcc which was forked before GPLv4). Too much work to update it at this point? it's simple. someone has to do the work. jmc
Re: Kerberos URL
On Sun, May 08, 2011 at 08:26:04AM +0100, Jason McIntyre wrote: On Sat, May 07, 2011 at 09:28:48PM -0500, Markus Peloquin wrote: On Fri, 2011-05-06 at 16:20 +0100, Jason McIntyre wrote: On Fri, May 06, 2011 at 09:39:48AM -0500, Vijay Sankar wrote: man 8 kerberos has the following URL http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html It should be http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html kerberos docs are maintained by the kerberos (heimdal) project. you should check whether their latest source has this problem and send them your fix if it does. jmc For some reason, OpenBSD is six releases behind on heimdal (0.8, 1.0, ..., 1.4). It strikes me as odd, especially when heimdal is using a liberal license (unlike gcc which was forked before GPLv4). Too much work to update it at this point? it's simple. someone has to do the work. Yes indeed. Somebody who feels the need. I know the name of at least one person. -Otto
setting lladdr on a vlan
I have a vlan on top of a vlan on an em. It connects to a remote switch that requires me to use a specified lladdr. Everything works just fine if I change the lladdr on em0, or run tcpdump to switch it to promiscuous mode, but I need another lladdr on the other vlans. Setting the lladdr on the outer vlan does not help, either. Any pointers, except dedicating an interface per lladdr?
Re: setting lladdr on a vlan
On 2011-05-08, Jussi Peltola pe...@pelzi.net wrote: I have a vlan on top of a vlan on an em. It connects to a remote switch that requires me to use a specified lladdr. Everything works just fine if I change the lladdr on em0, or run tcpdump to switch it to promiscuous mode, but I need another lladdr on the other vlans. Setting the lladdr on the outer vlan does not help, either. Any pointers, except dedicating an interface per lladdr? trunk(4) switches parent interfaces into promiscuous mode. So, as a workaround, you could run a trunk on the em (no need for a second interface), then run vlans on the trunk. This should probably get done automatically though..
Re: Kerberos URL
On 2011-05-08, Jason McIntyre j...@cava.myzen.co.uk wrote: On Sat, May 07, 2011 at 09:28:48PM -0500, Markus Peloquin wrote: On Fri, 2011-05-06 at 16:20 +0100, Jason McIntyre wrote: On Fri, May 06, 2011 at 09:39:48AM -0500, Vijay Sankar wrote: man 8 kerberos has the following URL http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html It should be http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html kerberos docs are maintained by the kerberos (heimdal) project. you should check whether their latest source has this problem and send them your fix if it does. jmc For some reason, OpenBSD is six releases behind on heimdal (0.8, 1.0, ..., 1.4). It strikes me as odd, especially when heimdal is using a liberal license (unlike gcc which was forked before GPLv4). Too much work to update it at this point? it's simple. someone has to do the work. note that someone doesn't have to be someone who is already an OpenBSD developer.
Re: User not listed under guest group
On Sat, 7 May 2011 20:33:33 +0300 Michael Sioutis wrote: And apparently a user needs to have a secondary group membership in group wheel to have sudo powers :) Not quite, it does what it says on the tin. If you want to give ship steering permissions then group wheel is good but there is no need about it. You can still give very specific sudo permissions via sudoers or another group.
Re: uaudio
On May 07 12:21:30, Alexandre Ratchov wrote: On Sat, May 07, 2011 at 10:52:09AM +0200, Jan Stary wrote: I just bought me the new M-Audio USB MobilePre (MK-II): uaudio0 at uhub2 port 2 configuration 1 interface 0 M-Audio MobilePre rev 1.10/10.00 addr 2 uaudio0: audio rev 1.00, 0 mixer controls audio0 at uaudio0 Indeed, 'mixerctl -a' shows nothing; but aucat -u -C 0:1 -e s24le -r 48000 -o in.wav seems to be recording anyway (and the sound is very good). Cool. Is it OK for an uaudio(4) device to have 0 mixer controls? I can control the respective inputs/outputs with the device's (hardware) knobs, but having 0 (software) mixerctl variables still seems a bit strange. Is it possible that the device really has 0 controls to expose via USB audio (and uaudio just correctly reports that), or is this a sign that the dovice is not fully supported (or possibly not class-compliant)? FWIW, above command will convert everything to 16-bit, and then back to 24-bit, truncating lower 8 bits. To record 24-bit with no precision loss, you have to recompile aucat in 24-bit mode. make COPTS=-DADATA_BITS=24 Thank you. Is this documented somewhere? Is the 24bit functionality still considered experimental? I was trying to somehow 'test' that the device really can record 24bit samples as advertised (that's why I bought it). Running aucat -u -C 0:1 -e s24le -r 48000 -o in.wav records a 24bit file all right; anyway, the running aucat server (aucat -l) would resample/reformat for me even if the device could not do 24b/48kHz, right? So I killed the aucat server and run the above command again, resulting in a 24bit file again. Would the aucat command (without aucat -l running) also resample/reformat into the desired format even of the device cannot do it? I very much doubt that this is the correct way to find out of course. What would be the correct way to find out what the device can physically do? All I know about is .../cap.c somewhere in the audio source tree. Is there a 'real' tool, exposed and documented? Thank you for your time Jan
pfctl: DIOCADDRULE: Operation not supported by device
After an update to -current yesterday Internet access was lost as pf.conf could not be loaded. The error message was: pfctl: DIOCADDRULE: Operation not supported by device This error occurred after upgrading the kernel and then rebooting. After userland was brought up to date as well and the system rebooted everything was fine. The system in question was local so outside of being offline for the amount of time it took to build userland there wasn't a lot to worry about. What I'm concerned with is this being an issue on a remote system where not being able to get back in after rebooting with just an updated kernel would (if it happened) be a serious issue. Is there a good way to avoid this? Is it safe to skip rebooting between the kernel build and userland build? Or would it work to manually build and install pfctl before the reboot after the kernel build? Or something else that hasn't occurred to me yet? Thanks, Chris
Re: uaudio
On Sun, 8 May 2011, Jan Stary wrote: Is it OK for an uaudio(4) device to have 0 mixer controls? I can control the respective inputs/outputs with the device's (hardware) knobs, but having 0 (software) mixerctl variables still seems a bit strange. Is it possible that the device really has 0 controls to expose via USB audio (and uaudio just correctly reports that), or is this a sign that the dovice is not fully supported (or possibly not class-compliant)? Accidentaly, I am recording at this very moment from a firewire audio interface (using another OS) and the device does not provide any mixer controls in software. Only the hardware buttons on the box. This fact is confirmed by the docs of the device. So, I would not be surprised that this is possible with USB audio devices too. Regards, David
Re: pfctl: DIOCADDRULE: Operation not supported by device
On Sun, May 08, 2011 at 02:54:21PM -0400, Chris Smith wrote: After an update to -current yesterday Internet access was lost as pf.conf could not be loaded. The error message was: pfctl: DIOCADDRULE: Operation not supported by device This error occurred after upgrading the kernel and then rebooting. After userland was brought up to date as well and the system rebooted everything was fine. The system in question was local so outside of being offline for the amount of time it took to build userland there wasn't a lot to worry about. What I'm concerned with is this being an issue on a remote system where not being able to get back in after rebooting with just an updated kernel would (if it happened) be a serious issue. Is there a good way to avoid this? Is it safe to skip rebooting between the kernel build and userland build? Or would it work to manually build and install pfctl before the reboot after the kernel build? Or something else that hasn't occurred to me yet? Thanks, Chris NO, it's not always safe to skip rebooting, not is it always safe to reboot, as you have exerrienced. The advise in http://www.openbsd.org/faq/faq5.html 5.2, last paragraph is there for a reason. -Otto
Re: pfctl: DIOCADDRULE: Operation not supported by device
On 2011-05-08, at 1:54 PM, Chris Smith wrote: After an update to -current yesterday Internet access was lost as pf.conf could not be loaded. The error message was: pfctl: DIOCADDRULE: Operation not supported by device This error occurred after upgrading the kernel and then rebooting. After userland was brought up to date as well and the system rebooted everything was fine. The system in question was local so outside of being offline for the amount of time it took to build userland there wasn't a lot to worry about. What I'm concerned with is this being an issue on a remote system where not being able to get back in after rebooting with just an updated kernel would (if it happened) be a serious issue. Is there a good way to avoid this? Is it safe to skip rebooting between the kernel build and userland build? Or would it work to manually build and install pfctl before the reboot after the kernel build? Or something else that hasn't occurred to me yet? Thanks, Chris Hi, Following the upgrade.html document may be the best approach. What I typically do is build the release on a system (build kernel as well as all binaries and do a make release) and then follow the upgrade.html approach for remote systems after I am sure nothing at the remote branch will break. In our case the remote branch in question is within driving distance and that makes it less risky for me but the procedure has not failed me for close to 10 years. Before 4.x I used to follow a slightly different approach (pax) but since 4.2 or so I have been following the update.html document verbatim. Vijay Vijay Sankar vsan...@foretell.ca
Re: pfctl: DIOCADDRULE: Operation not supported by device
On Sun, 8 May 2011 14:54:21 -0400 Chris Smith obsd_m...@chrissmith.org wrote: Is there a good way to avoid this? Is it safe to skip rebooting between the kernel build and userland build? Or would it work to manually build and install pfctl before the reboot after the kernel build? Or something else that hasn't occurred to me yet? Yes, just skip the reboot. Isn't adviced anymore in upgradeXX.html. Remember to save the old reboot binary as a precaution before building base when running -current or upgrading releases from source.
Re: uaudio
On Sun, May 08, 2011 at 08:18:39PM +0200, Jan Stary wrote: On May 07 12:21:30, Alexandre Ratchov wrote: On Sat, May 07, 2011 at 10:52:09AM +0200, Jan Stary wrote: I just bought me the new M-Audio USB MobilePre (MK-II): uaudio0 at uhub2 port 2 configuration 1 interface 0 M-Audio MobilePre rev 1.10/10.00 addr 2 uaudio0: audio rev 1.00, 0 mixer controls audio0 at uaudio0 Indeed, 'mixerctl -a' shows nothing; but aucat -u -C 0:1 -e s24le -r 48000 -o in.wav seems to be recording anyway (and the sound is very good). Cool. Is it OK for an uaudio(4) device to have 0 mixer controls? I can control the respective inputs/outputs with the device's (hardware) knobs, but having 0 (software) mixerctl variables still seems a bit strange. Is it possible that the device really has 0 controls to expose via USB audio (and uaudio just correctly reports that), or is this a sign that the dovice is not fully supported (or possibly not class-compliant)? There might be software knobs not exposed by the driver. But I wouldn't be completely surprised if there are none. They are not necessary on a device that already has hardware knobs. FWIW, above command will convert everything to 16-bit, and then back to 24-bit, truncating lower 8 bits. To record 24-bit with no precision loss, you have to recompile aucat in 24-bit mode. make COPTS=-DADATA_BITS=24 Thank you. Is this documented somewhere? not yet, I'll probably try to write a faq entry when I get some free time. Basically COPTS=-DADATA_BITS=24 switches aucat's internal representation of samples from 16-bit to 24-bit integers. Since aucat defaults are such that no format conversions are required, default precision of files becomes 24-bit. So: aucat -o file.wav will generate a 24-bit file unless '-e s16' is specified. That's the only difference. Is the 24bit functionality still considered experimental? It's not experimental, I use it daily since around 6 months it's only disabled because it cannot coexist with 16-bit mode yet. I mean we can't have the same binary using 16-bit and 24-bit processing yet. I was trying to somehow 'test' that the device really can record 24bit samples as advertised (that's why I bought it). Running aucat -u -C 0:1 -e s24le -r 48000 -o in.wav records a 24bit file all right; anyway, the running aucat server (aucat -l) would resample/reformat for me even if the device could not do 24b/48kHz, right? Yes, it will work on 16-bit devices, and 16-bit apps will still work. BTW, that's the setup on my audio machines, it behaves as before, except that it uses more cpu. So I killed the aucat server and run the above command again, resulting in a 24bit file again. Would the aucat command (without aucat -l running) also resample/reformat into the desired format even of the device cannot do it? Yes. Server and non-server commands are the same, except that the server dynamically creates streams by accepting connections, while non-server commands use streams provided on the command line (files). But the processing is the same. I very much doubt that this is the correct way to find out of course. What would be the correct way to find out what the device can physically do? All I know about is .../cap.c somewhere in the audio source tree. Is there a 'real' tool, exposed and documented? There's no tool to explore capabilities mostly by lack of time and motivation. I often use -ddd to see what the precision is: $ aucat -ddd -r 48000 -f sun:0 sun:0: recording s24le4msb,0:1,48000 sun:0: playing s24le4msb,0:1,48000 ... This shows that the device is doing 24-bit stereo at 48kHz. The same for a 16-bit card gives: $ aucat -ddd -r 48000 -f sun:1 sun:1: recording s16le,0:1,48000 sun:1: playing s16le,0:1,48000 ... -- Alexandre
Re: pfctl: DIOCADDRULE: Operation not supported by device
Op 8-5-2011 21:16, roberth schreef: On Sun, 8 May 2011 14:54:21 -0400 Chris Smithobsd_m...@chrissmith.org wrote: Is there a good way to avoid this? Is it safe to skip rebooting between the kernel build and userland build? Or would it work to manually build and install pfctl before the reboot after the kernel build? Or something else that hasn't occurred to me yet? Yes, just skip the reboot. Isn't adviced anymore in upgradeXX.html. Remember to save the old reboot binary as a precaution before building base when running -current or upgrading releases from source. You are aware that this question concerns following -current? And that you are strongly advised to follow the FAQ when building -current as others already pointed out?
Re: uaudio
Jan Stary h...@stare.cz wrote: you have to recompile aucat in 24-bit mode. make COPTS=-DADATA_BITS=24 Thank you. Is this documented somewhere? No. Is the 24bit functionality still considered experimental? It requires significantly more CPU than 16-bit processing and few people need it. I very much doubt that this is the correct way to find out of course. What would be the correct way to find out what the device can physically do? audioctl(1)? -- Christian naddy Weisgerber na...@mips.inka.de
Re: pfctl: DIOCADDRULE: Operation not supported by device
On Sun, 08 May 2011 21:48:25 +0200 Erik o...@vanwesten.net wrote: You are aware that this question concerns following -current? And that you are strongly advised to follow the FAQ when building -current as others already pointed out? Building from source. Got error after kernel reboot. Dude, rtfaq! Kernel and userland out of sync. Build base and reboot... Uhum. Sure that's a way to approach this. That's the supported way. With that ammount of support required. Fine with that. On the otherhand, i have been running -current for years and never have had any problem with building source with the previouse kernel (without reboot) that i can remember. Maybe my 3 digit amount of builds isn't enough or i built at the wrong states of the tree. So let me rephrase, ... Follow the FAQ and do it that way, because then you can come to the list and ask. (Like OP did.) So take my just build base without rebooting as personal advice. Never said anything about this being the project endorsed way. But it works for me, maybe it does for you, too... Don't come asking for help onlist, if you didn't follow the faq thou, might lose you karma. Just try again as the faq says and ask after that. Even if something breaks in the worst way because of not rebooting, simply updating with a snapshot will get you back on track. Concerning remote-updates, from source will run into more problems than from a known good set of tarballs. That's simple statistics, because of how many binarys are involved. (remote console access helps, but still might mess up your sla.)
Re: uaudio
On Sun, May 08, 2011 at 08:18:39PM +0200, Jan Stary wrote: On May 07 12:21:30, Alexandre Ratchov wrote: On Sat, May 07, 2011 at 10:52:09AM +0200, Jan Stary wrote: I just bought me the new M-Audio USB MobilePre (MK-II): uaudio0 at uhub2 port 2 configuration 1 interface 0 M-Audio MobilePre rev 1.10/10.00 addr 2 uaudio0: audio rev 1.00, 0 mixer controls audio0 at uaudio0 Indeed, 'mixerctl -a' shows nothing; but aucat -u -C 0:1 -e s24le -r 48000 -o in.wav seems to be recording anyway (and the sound is very good). Cool. Is it OK for an uaudio(4) device to have 0 mixer controls? absolutely. I can control the respective inputs/outputs with the device's (hardware) knobs, but having 0 (software) mixerctl variables still seems a bit strange. Is it possible that the device really has 0 controls to expose via USB audio (and uaudio just correctly reports that), or is this a sign that the dovice is not fully supported (or possibly not class-compliant)? if there are hardware controls, then there probably aren't software controls. they would sorta conflict otherwise, no? What would be the correct way to find out what the device can physically do? All I know about is .../cap.c somewhere in the audio source tree. Is there a 'real' tool, exposed and documented? faq 13.1. hmm, maybe that should also have an explicit example of '$ audioctl encodings'. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: pfctl: DIOCADDRULE: Operation not supported by device
On Sun, May 8, 2011 at 3:25 PM, roberth rob...@openbsd.pap.st wrote: Uhum. Sure that's a way to approach this. That's the supported way. With that ammount of support required. Fine with that. I usually build the new kernel, major utilities that require the new kernel as per http://openbsd.org/faq/current.html and http://openbsd.org/upgrade*.html. Then reboot to the new kernel, and build userland. I assume the machine is out of production until it's done. On the otherhand, i have been running -current for years and never have had any problem with building source with the previouse kernel (without reboot) that i can remember. The occasional problem exists. Mostly due to a kernel call after a library is installed before the userland is upgraded. Concerning remote-updates, from source will run into more problems than from a known good set of tarballs. That's simple statistics, because of how many binarys are involved. (remote console access helps, but still might mess up your sla.) I always build release from an already upgraded master build server, so there's no potentially off binaries being distributed. jb
