OT - "Intel Management Engine" security issues
While this isn't specifically an OpenBSD issue, since OpenBSD emphasizes security this seems like a good place to ask. As far as I can tell the "Intel Management Engine" (IME) is a gaping backdoor into every recent Intel-based system. My searches on the 'net haven't turned up much useful information about it. I'd really like to find documentation on how to configure and use it, though I'd settle for just enough to know how to lock it down or disable it such that it can't be used to attack me from the 'net. While this wouldn't work for a laptop, for desktop systems it might be sufficient to use an add-in NIC rather than the built-in one -- but the limited info I've found suggests that the IME may be able to snoop on all devices and so defeat this tactic. Does anyone here know? Thanks for any information, Dave -- Dave Anderson
Re: What is you motivational to use OpenBSD
On Wed, 28 Aug 2019, Mohamed salah wrote: >I wanna put something in discussion, what's your motivational to use >OPENBSD what not other bsd's what not gnu/Linux, if something doesn't work >fine on openbsd and you love this os so much what will do? The emphasis on security and correctness. -- Dave Anderson
pf questions
I’m setting up on 6.9-release a (for now) IPv4-only firewall with multiple public addresses and multiple subnets behind it, and have a couple of questions related to connections originating from the firewall itself to which I haven’t found definitive answers. When not overridden (for example, by ‘ftp-proxy -a ’) which of the public addresses will be chosen as the source address for connections to the Internet originating on the firewall? It would make sense to me for the one address not declared as an alias to always be chosen, but I haven’t found anything that states this to be true. I want to (for example) keep traffic from systems I control separate from that from the WiFi subnet (which I’ll NAT to a different public address). I plan to use tags to control policy, initially tagging each new connection based mostly (but not entirely) on which interface it arrives through. But, unless I’m missing something, connections originating on the firewall can’t be tagged this way since they don’t arrive through any interface. Which also seems to mean that all policy decisions must be made outbound, since that’s the only time that connections originating on the firewall will pass through an interface. And I haven’t found any way of filtering on untagged connections (something like ‘! tagged any’ would be nice). I’m sure that my setup isn’t unique, so there must be a good way of dealing with this, but I’ve no idea what it might be. Suggestions, please! -- Dave Anderson d...@daveanderson.com
Re: pf questions
> On Jun 1, 2021, at 16:50, Stuart Henderson wrote: > > On 2021-05-30, Dave Anderson wrote: >> I’m setting up on 6.9-release a (for now) IPv4-only firewall with multiple >> public addresses and multiple subnets behind it, and have a couple of >> questions related to connections originating from the firewall itself to >> which I haven’t found definitive answers. >> >> When not overridden (for example, by ‘ftp-proxy -a ’) which of the >> public addresses will be chosen as the source address for connections to the >> Internet originating on the firewall? It would make sense to me for the one >> address not declared as an alias to always be chosen, but I haven’t found >> anything that states this to be true. I want to (for example) keep traffic >> from systems I control separate from that from the WiFi subnet (which I’ll >> NAT to a different public address). > > The interface address associated with the route used to reach the > destination. See "if address" in "route -n get $IP". > >> I plan to use tags to control policy, initially tagging each new connection >> based mostly (but not entirely) on which interface it arrives through. But, >> unless I’m missing something, connections originating on the firewall can’t >> be tagged this way since they don’t arrive through any interface. Which also >> seems to mean that all policy decisions must be made outbound, since that’s >> the only time that connections originating on the firewall will pass through >> an interface. And I haven’t found any way of filtering on untagged >> connections (something like ‘! tagged any’ would be nice). I’m sure that my >> setup isn’t unique, so there must be a good way of dealing with this, but >> I’ve no idea what it might be. Suggestions, please! > > You might find "!received-on any" useful to allow a rule to match only > locally originated connections. I guess you could do something like > "match !received-on any tag local" if you want to attach a tag to those. I should have noticed that; evidently I was too fixated on tags. Once I’ve identified the local connections I can NAT them to the address I want, so which source address is used by default doesn’t matter. Thanks!
man.openbsd.org failure?
Safari isn’t providing much useful information, but starting today I’m consistently getting a “server stopped responding” error when trying to access the online man pages at man.openbsd.org. www.openbsd.org is working fine. Dave Anderson d...@daveanderson.com
Re: man.openbsd.org failure?
Oops! I did see that message but forgot that it mentioned man.openbsd.org. Apologies for the noise. (But that Safari error message sucks!) Dave Anderson d...@daveanderson.com > On Dec 21, 2023, at 21:55, Daniel Jakots wrote: > > On Thu, 21 Dec 2023 21:22:49 -0500, Dave Anderson wrote: > >> Safari isn=E2=80=99t providing much useful information, but starting today >> I=E2=80=99m consistently getting a =E2=80=9Cserver stopped responding=E2= > =80=9D error when >> trying to access the online man pages at man.openbsd.org. >> www.openbsd.org is working fine. > > Yes, it's a maintenance: > https://marc.info/?l=3Dopenbsd-misc&m=3D170301839017559&w=3D
Re: man.openbsd.org failure?
“Server stopped responding” implies that it did provide some response before stopping. “Server did not respond” would be more accurate and less confusing. Dave Anderson d...@daveanderson.com > On Dec 23, 2023, at 07:27, hahahahacker2...@airmail.cc wrote: > > On 2023-12-22 10:39, Dave Anderson wrote: >> Oops! I did see that message but forgot that it mentioned >> man.openbsd.org. Apologies for the noise. (But that Safari error >> message sucks!) >> Dave Anderson >> d...@daveanderson.com >> > On Dec 21, 2023, at 21:55, Daniel Jakots wrote: >> > >> > On Thu, 21 Dec 2023 21:22:49 -0500, Dave Anderson wrote: >> > >> > > Safari isn=E2=80=99t providing much useful information, but starting >> > > today >> > > I=E2=80=99m consistently getting a =E2=80=9Cserver stopped responding=E2= >> > =80=9D error when >> > > trying to access the online man pages at man.openbsd.org. >> > > www.openbsd.org is working fine. >> > >> > Yes, it's a maintenance: >> > https://marc.info/?l=3Dopenbsd-misc&m=3D170301839017559&w=3D > The website is simply down. So it cannot just respond. >
Re: Why on earth would online voting be insecure?
[Off-topic; sorry. It's important to remind people of this issue, but I won't follow up any further.] This sort of security, no matter how well done, doesn't address one of the very important but often forgotten features of voting in person at a polling place: it makes it very difficult to buy or extort votes, since there's no way to reliably confirm how someone actually voted. With online (or by mail, etc) voting there's nothing to prevent someone from watching while a vote is cast. Dave On Mon, 14 Nov 2016, Alan Corey wrote: This sounds like heel-dragging to me, or they're trying to do it under Windows or something: https://www.washingtonpost.com/news/post-nation/wp/2016/05/17/more-than-30-states-offer-online-voting-but-experts-warn-it-isnt-secure/ It seems simple to me, you use firewalls and only make the results writeable by the process that should be writing to it, probably nothing needs to have read access in the short term. As far as security after the election, mount the servers in a Brinks truck or something, it just sounds like a ludicrous excuse. Something like: for each election the town government mails you a random number that's your key to vote that election. You go to a website and put in your town, name, SSN, and the key. If somebody steals the mail they won't have your SSN. If Russian hackers or whoever tries to impersonate you online they won't have the key. It's bringing those 2 pieces of information plus your name and town together that makes it secure. Just guessing. Did I overlook anything? -- Dave Anderson
Advice requested -- how best to copy a disk
My apologies for what seems to be a rather simple and not really OpenBSD specific question, but searching hasn't found any good answers. I've got an old PC running i386 OpenBSD which is dying; the disk seems to be good, but I need to replace the rest of the hardware. Usually I'd just move the disk to the new system, but the old system is EIDE and the new one is SATA -- so I need to copy the old disk (which I can put in an external enclosure and connect to the new system via USB) to the new one (which is a different size and probably a different geometry, so the new and old partitions probably won't be exactly the same sizes). It's clearly possible to boot the new system from an install CD (or, if necessary, a USB stick with a full install on it) then fdisk and disklabel the new disk and newfs / dump|restore the partitions one by one, followed up by installboot, editing the duids in /etc/fstab, and fixing up /etc/hostname.*, but I'm hoping that there's a better way. Thanks in advance for any suggestions (or confirmations that there is no better way). Dave -- Dave Anderson
Re: Fund raising
On Fri, 27 Mar 2015, Theo de Raadt wrote: >>On Fri, Mar 27, 2015 at 2:25 AM, Theo de Raadt >>wrote: >> >>> >I'm actually wearing an openbsd shirt now with an openssh poster >>> >behind me on the wall. >>> > >>> >What's the URL to the legacy store? I want to see what remains in >>> >their inventory. >>> >>> Note: >>> >>> Recent difficulties have resulted in zero (Z E R O) of the proceeds >>> from Austin's shop going towards OpenBSD. And it may have been >>> happening for a while before that. >>> >>> (history repeats itself) >>> >>> >>But the new shop is alright ? > >Yes, the new shop is fine. Transparency, accountability, honourable >behaviour, etc. Excellent relationship. Few bumps at adapting their >ordering system to the people ordering from all over the world, but >we'll get there step by step I hope. I hit a couple of those bumps on my first order from them, and they were _very_ good about analyzing and fixing them. Dave -- Dave Anderson
FYI - 5.2 CDs just arrived near Boston, Mass.
-- Dave Anderson
Problem building -current userland
I recently upgraded to the 2 December 2012 amd64 snapshot, then at about 11am EST today (4 December) updated my source tree to -current. After compiling and installing a new kernel and rebooting, my attempt to rebuild userland aborted with a slew of errors in /usr/src/usr.sbin/smtpd/smtpd/../dns.c. In case this was a short-term glitch I re-updated my source tree at about 4pm EST and tried again, with the same result. Is this a known problem, or have I managed to screw something up? I'm using the same build procedure as I've successfully used before, and didn't see anything in the current version of the 'building from source' section of the FAQ that would require changing it or see anything relevant in 'following current'. The sequence of commands I used is: cd /usr/src && cvs -z 9 -d$CVSROOT -q up -Pd cd /usr/src/sys/arch/`machine`/conf && config GENERIC.MP && cd ../compile/GENERIC.MP make clean && make make install reboot cd /usr/obj && touch junk && mkdir -p .old && mv * .old && rm -rf .old & cd /usr/src && make obj && cd /usr/src/etc && env DESTDIR=/ make distrib-dirs cd /usr/src && make build Thanks for any help, Dave -- Dave Anderson
Re: Problem building -current userland
On Tue, 4 Dec 2012, Amit Kulkarni wrote: >> rebuild userland aborted with a slew of errors in >> /usr/src/usr.sbin/smtpd/smtpd/../dns.c. In case this was a short-term >> glitch I re-updated my source tree at about 4pm EST and tried again, >> with the same result. >> >> Is this a known problem, or have I managed to screw something up? > >I built everything on amd64 around 2pm CST today. So definitely a cvs >update or other issue. > >> cd /usr/src && cvs -z 9 -d$CVSROOT -q up -Pd > >Use cvs up -APd (-A updates to latest version without any release >tags, since you mention following -current) Thanks for the suggestion; I'll give it a try -- and double-check that the cvs update worked properly. Dave -- Dave Anderson
Re: Problem building -current userland
On Tue, 4 Dec 2012, Dave Anderson wrote: Problem solved; PEBCAK. I didn't fully understand what 'cvs update' was doing, and managed to create a source tree containing a mixture of old and current files. Apologies for the noise. Dave >I recently upgraded to the 2 December 2012 amd64 snapshot, then at about >11am EST today (4 December) updated my source tree to -current. After >compiling and installing a new kernel and rebooting, my attempt to >rebuild userland aborted with a slew of errors in >/usr/src/usr.sbin/smtpd/smtpd/../dns.c. In case this was a short-term >glitch I re-updated my source tree at about 4pm EST and tried again, >with the same result. > >Is this a known problem, or have I managed to screw something up? > >I'm using the same build procedure as I've successfully used before, and >didn't see anything in the current version of the 'building from source' >section of the FAQ that would require changing it or see anything >relevant in 'following current'. > >The sequence of commands I used is: > > cd /usr/src && cvs -z 9 -d$CVSROOT -q up -Pd > > cd /usr/src/sys/arch/`machine`/conf && config GENERIC.MP && cd > ../compile/GENERIC.MP > make clean && make > make install > reboot > > cd /usr/obj && touch junk && mkdir -p .old && mv * .old && rm -rf .old & > cd /usr/src && make obj && cd /usr/src/etc && env DESTDIR=/ make distrib-dirs > cd /usr/src && make build > >Thanks for any help, > > Dave -- Dave Anderson
Re: OpenBSD 5.7 release -- CD2 issues
On Fri, 15 May 2015, Theo de Raadt wrote: >Sadly, CD2 of the OpenBSD 5.7 shipped in a broken fashion due to >errors at the manufacturing plant. Two mistakes were made. > >In the rush after the first error, this error was not caught in time. >Many people have received (or will soon receive) their package with >this broken disc. Orders which have not yet shipped are being held >back... because... > >A repaired disc is on the way from the plant. > >This will be shipped out to everyone, and will be inserted into the >orders not yet shipped. Thanks for the update. As usual, you're doing the right thing -- and we appreciate it. I hate to think of the likely mess if this sort of error had happened with some commercial software package. Dave -- Dave Anderson
Re: e-commerce framework suggestion? medoc?
On Wed, 24 Feb 2016, arrowscr...@mail.com wrote: I'm currently deciding to do a "e-commerce" website. I noticed that OpenBSD Store use a software from medoc.com. If not medoc, do you guys have any other suggestion for e-commerce framework? It have to be open source, because I can't pay a service now (and I woudn't trust them anyway). The idea is to be secure as possible (I know it's difficult with all this sql/php madness). I'll, of course, use httpd(8) on -stable. Regards. Be _very_ careful about this. You don't say where you live or work, but (at least in the U.S.) a whole bunch of laws and regulations pop up to make your life miserable if you start dealing with credit card info, etc. (I'm no expert on this, but am involved in an organization which uses a commercial e-commerce service to shield itself from all this and have overheard quite a bit of discussion on the subject.) I'd strongly recommend that, before doing anything about this, you carefully investigate what your responsibilities and liabilities would be. Dave -- Dave Anderson
Re: e-commerce framework suggestion? medoc?
On Thu, 25 Feb 2016, li...@wrant.com wrote: Wed, 24 Feb 2016 23:51:10 +0100 arrowscr...@mail.com So, I'll probably use Ubercart. Thanks everyone. The "Django" software seems good too 'Mariano', I'll read more on that. About the laws and regulations 'Dave', I will need to see that. Here in my country we have all these regulations too. Thanks for the advice. Don't fall for regulation scare talks, there should be no reason to put something outside local premises except payment processing which is a well developed monetary system service from banks etc. Don't fall for "it's all a scare tactic" either. Investigate, then make your own decision based on whatever laws and regulations apply to you. Good luck. Dave Run your own systems, make sure you protect your clients personal details, separate databases and storage layers, use sound security and encryption, and update your software regularly plus plan for disaster. This includes dirty play from the competing parties which want to suck your data into their system with the "cloud" services. Web based software is multiple reliability nightmares yet running it internally with limited outside connectivity and reliable (static) web front end site is an option for control of this critical aspect. At that point you're as good as a personal self sustained service. -- Dave Anderson
Re: OT: True hardware UNIX terminal
On Mon, 4 Apr 2016, ropers wrote: On 4 April 2016 at 02:06, Adam Thompson wrote: On 2016-04-01 11:07, ropers wrote: And if anyone has ever operated the OpenBSD installer via a teleprinter, I want to hear that story. I think there's still a first-generation TI Silent 700 somewhere in my parents' basement. If, when they either die and/or move out to a seniors' residence prior to that certain event, I should run across it, and I can find a compatible telephone (acoustic handset coupler, remember!), and can find a compatible 300bps modem to dial into, and can find an honest-to-god POTS phone line (I expect this to be the hardest part) and can find a compatible system with a serial console that can be stepped down to 300bps, and the thermal paper is still viable, I'll do a fresh install just so I can mail you the ~3-4m of thermal paper I suspect that would generate. Would that be close enough for you? :-) YES! I'd be extremely honoured to receive something like that. But, I think there are probably more worthy recipients. Computer museums, even. (Actually, it just occurred to me that I don't need the phone line as long as I can also find the old PENRIL modem that can start training on a front-panel button-press instead of a -90v ring signal. Or maybe the local museum will have a 300bps acoustic-coupler modem I can borrow?) Wikipedia currently says that at least some Silent 700s could be locally connected: https://en.wikipedia.org/wiki/Silent_700 Of course, that technically sort of takes away the tele- part from the teleprinter (which is not to say that the device was now just a printer), but I definitely think that an install to a locally attached teleprinter counts. The key here is that it's monitorless, so not a glass terminal; the paper is the only place where you get to see output. I love it, btw., that the Wikipedia article speaks of "the new high-speed interactive computing environment" -- at 1200 baud. :) That was advanced stuff. I remember how pleased we were when we upgraded to blazingly fast 300 baud 'glass teletypes' from 110 baud KSR35 teletypes. Dave Those were days when actual interactive use of a computer was not unlike getting telescope time at a major observatory -- and before time-sharing allowed concurrent multi-user access, it must have been almost exactly alike. Like Woz said in the Youtube video I linked: "Your use on these company computers, it was so far above us in value." I vaguely recall once doing an OpenBSD install where the "console" path was: Local VT220 -> multiplexer -> modem -> DATAPAC 3101 (Canadian X.25 service) PAD -> remote PAD -> remote dial-out service -> another modem -> another multiplexer -> serial line into, IIRC, ttyA on a Sun system I was helping someone repurpose. The entire install completed successfully off a network boot in about an hour at 2400bps (*and* simultaneously 2400baud, all you pedants out there...). Wow. -- Dave Anderson
Help requested tracking down a problem running 5.5-release.
6 Series PCIE" rev 0xb5: msi pci3 at ppb2 bus 13 rtsx0 at pci3 dev 0 function 0 "Realtek RTS5209 Card Reader" rev 0x01: msi sdmmc0 at rtsx0 "Realtek RTS5209 Card Reader" rev 0x01 at pci3 dev 0 function 1 not configured ppb3 at pci0 dev 28 function 3 "Intel 6 Series PCIE" rev 0xb5: msi pci4 at ppb3 bus 19 "NEC xHCI" rev 0x04 at pci4 dev 0 function 0 not configured ehci1 at pci0 dev 29 function 0 "Intel 6 Series USB" rev 0x05: apic 0 int 20 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1 pcib0 at pci0 dev 31 function 0 "Intel HM65 LPC" rev 0x05 ahci0 at pci0 dev 31 function 2 "Intel 6 Series AHCI" rev 0x05: msi, AHCI 1.3 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct fixed naa.5000c50044718f26 sd0: 715404MB, 512 bytes/sector, 1465149168 sectors cd0 at scsibus0 targ 5 lun 0: ATAPI 5/cdrom removable ichiic0 at pci0 dev 31 function 3 "Intel 6 Series SMBus" rev 0x05: apic 0 int 19 iic0 at ichiic0 spdmem0 at iic0 addr 0x50: 2GB DDR3 SDRAM PC3-10600 SO-DIMM spdmem1 at iic0 addr 0x52: 4GB DDR3 SDRAM PC3-10600 SO-DIMM isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pms0: Synaptics touchpad, firmware 7.5 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 uhub2 at uhub0 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2 ugen0 at uhub2 port 1 "Validity Sensors product 0x0018" rev 1.10/0.78 addr 3 uvideo0 at uhub2 port 2 configuration 1 interface 0 "SuYin HP TrueVision HD" rev 2.00/1.10 addr 4 video0 at uvideo0 uhub3 at uhub1 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2 vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets root on sd0a (c3ffcff67dc13a92.a) swap on sd0b dump on sd0b -- Dave Anderson
Help, please, understanding AHCI error on amd64
pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pms0: Synaptics touchpad, firmware 7.5 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 uhub2 at uhub0 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2 ugen0 at uhub2 port 1 "Validity Sensors product 0x0018" rev 1.10/0.78 addr 3 uvideo0 at uhub2 port 2 configuration 1 interface 0 "SuYin HP TrueVision HD" rev 2.00/1.10 addr 4 video0 at uvideo0 uhub3 at uhub1 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2 vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets root on sd0a (c3ffcff67dc13a92.a) swap on sd0b dump on sd0b -- Dave Anderson
Re: Help, please, understanding AHCI error on amd64
On Mon, 25 Aug 2014, Adam Thompson wrote: >On 14-08-25 03:49 PM, Dave Anderson wrote: >> My amd64 notebook (full dmesg below) has started reporting an error >> which I don't adequately understand. Any explanations or ideas as to >> how to figure out exactly what is broken would be greatly appreciated. > >Your hard disk is in the process of (hopefully slowly!) breaking. > >> This started while untarring the ports tree from the source CD >> immediately after upgrading from 5.4-release to 5.5-release (from CD). >> I initially guessed that it was related to some change in 5.5, but >> testing while booted from install CDs for 5.4-release, 5.6-20140822 and >> a 4.7-release I had handy all give the same result. > >Normal. It won't matter what software you're running because it's a >hardware issue. > >> The error appears to be tied to a particular spot on the disk (it seems >> to occur when, e.g., I try to 'ls' a particular directory) > >Yes. It'll be some particular sector that the disk controller is having >difficulty reading. No matter what version of the OS you boot, those >directory entries still reside on the same sector on disk. > >> but it looks >> to me like it could be a controller error or perhaps a controller quirk >> which OpenBSD doesn't handle well. The only information about it I can >> find is these two messages in /var/log/messages: >> >> Aug 18 14:08:08 minya /bsd: ahci0: attempting to idle device >> Aug 18 14:08:08 minya /bsd: ahci0: couldn't recover NCQ error, failing all >> outstanding commands. > >Nope. The "quirk" is that your HDD is taking too long to read that >sector (normally because of too many retries), the AHCI stack times out, >and the only sane thing to do with timing out a request is to pretend >all the other pending commands have also failed - otherwise you could >get undefined results (i.e. even worse errors). > >Presumably the HDD eventually manages to read the sector, and succeeds >the time the VFS or block-cache or whatever I/O layer resubmits the >request for that data. Otherwise you'd see other error messages >following the two you mention. > >> I've hunted through all the other log files I can think of without >> finding anything that looks related. Other than this, the system >> appears to be running normally (though I haven't been doing much with it >> other than poking around trying to understand this problem). > >Nope - this is the only symptom you're likely to see, unless you happen >to be running some sort of SMART monitor and you happen to be monitoring >"correctable read errors" in that tool. > > From the hard disk's standpoint, all is well - you asked for a sector, >and it (eventually) gave it to you. The only problem is that your >software is too impatient, from a certain point of view. That all makes sense. Thanks. It would be nice if that error message mentioned the timeout -- I think that would have convinced me that it was definitely the disk that was dying rather than it possibly being something else. > From a real-world point of view, however, you probably should make sure >everything on that disk is backed up. Then you should either do a >low-level format (almost impossible nowadays[1]) and still not trust it >for important data, or just replace it. > >-Adam > >[1] While low-level formatting is not really possible nowadays unless >you work in the manufacturer's lab, a few "ATA Secure Erase" passes >might resuscitate the disk for a while if you really, really, REALLY >don't want to replace it right now for some reason. Most people boot a >Linux CD to do this, but atactl(8) appears to support the "secerase" >command. There are all sorts of things that could prevent you from >doing this, and if you can't work past them, you probably should just >throw the drive away. Yup, time for a new disk. I'm off to do some research on who makes the most reliable ones these days. [Suggestions from anyone knowledgable are welcome.] Dave -- Dave Anderson
5.5 CDs arriving
Just got mine, near Boston, Mass. My thanks to everyone involved. Dave -- Dave Anderson
Re: 5.5 CDs arriving
On Wed, 30 Apr 2014, JJ Jumpercables wrote:
>On Wed, Apr 30, 2014 at 12:56 PM, Dave Anderson wrote:
>> Just got mine, near Boston, Mass.
>>
>
>Jut curious... how long ago did you order?
As soon as I saw the announcement that orders were open -- I don't
remember exactly when, but it was within a day after the announcement
went up.
Dave
--
Dave Anderson
Re: I can't download OpenBSD 4.5, "550 /pub/OpenBSD/4.5: Permission denied."
On Thu, 16 Apr 2009, Juan Jimenez Galdos wrote: >Hi. I want download OPenBSD 4.5 but i can't. I try to enter in the directory >but it says "550 /pub/OpenBSD/4.5: Permission denied." The others >directories work well. > >Thank you very much. It's not released yet! Wait for May 1st. Dave -- Dave Anderson
Re: autowhitelister for spamd needs testing
On Wed, 22 Apr 2009, jared r r spiegel wrote: >On Thu, Apr 23, 2009 at 12:30:28AM +, Stuart Henderson wrote: > >> I see a tiny little problem with this method... sometimes people send >> spam from domains whose DNS they control. > > +1 > > i think part of the success i experience using SPF as a means to create > whitelists is in the fact that i maintain the list of domains i fancy > whitelisting. unfortunately, it would be trivial for someone to take > advantage of an spf-based automatic whitelist to slip right on thru > spamd(8). > > it's a pisser. What might make sense is to alter the script to generate a list of canditates for whitelisting, but only apply any of them after they are manually approved. Dave -- Dave Anderson
iPad2 and iPhone4S USB messages
A few days ago someone posted info about what happened when a couple of
Apple devices were plugged into a USB port on an OpenBSD system. I just
had the opportunity to try this with an iPad2 and an iPhone4S on an
amd64 system running current (source tree updated to about 2200 EST
2011/12/20 before rebuilding the system); here are the results.
Insert iPad2:
uaudio0 at uhub3 port 1 configuration 2 interface 0 "Apple Inc. iPad" rev
2.00/0.01 addr 3
uaudio0: audio rev 1.00, 0 mixer controls
audio1 at uaudio0
uhidev0 at uhub3 port 1 configuration 2 interface 2 "Apple Inc. iPad" rev
2.00/0.01 addr 3
uhidev0: iclass 3/0, 21 report ids
uhid0 at uhidev0 reportid 1: input=5, output=0, feature=0
uhid1 at uhidev0 reportid 2: input=9, output=0, feature=0
uhid2 at uhidev0 reportid 3: input=13, output=0, feature=0
uhid3 at uhidev0 reportid 4: input=17, output=0, feature=0
uhid4 at uhidev0 reportid 5: input=25, output=0, feature=0
uhid5 at uhidev0 reportid 6: input=49, output=0, feature=0
uhid6 at uhidev0 reportid 7: input=95, output=0, feature=0
uhid7 at uhidev0 reportid 8: input=193, output=0, feature=0
uhid8 at uhidev0 reportid 9: input=257, output=0, feature=0
uhid9 at uhidev0 reportid 10: input=385, output=0, feature=0
uhid10 at uhidev0 reportid 11: input=513, output=0, feature=0
uhid11 at uhidev0 reportid 12: input=767, output=0, feature=0
uhid12 at uhidev0 reportid 13: input=0, output=5, feature=0
uhid13 at uhidev0 reportid 14: input=0, output=9, feature=0
uhid14 at uhidev0 reportid 15: input=0, output=13, feature=0
uhid15 at uhidev0 reportid 16: input=0, output=17, feature=0
uhid16 at uhidev0 reportid 17: input=0, output=25, feature=0
uhid17 at uhidev0 reportid 18: input=0, output=49, feature=0
uhid18 at uhidev0 reportid 19: input=0, output=95, feature=0
uhid19 at uhidev0 reportid 20: input=0, output=193, feature=0
uhid20 at uhidev0 reportid 21: input=0, output=255, feature=0
Remove iPad2:
audio1 detached
uaudio0 detached
uhid0 detached
uhid1 detached
uhid2 detached
uhid3 detached
uhid4 detached
uhid5 detached
uhid6 detached
uhid7 detached
uhid8 detached
uhid9 detached
uhid10 detached
uhid11 detached
uhid12 detached
uhid13 detached
uhid14 detached
uhid15 detached
uhid16 detached
uhid17 detached
uhid18 detached
uhid19 detached
uhid20 detached
uhidev0 detached
Insert iPhone4S:
ugen1 at uhub3 port 1 "Apple Inc. iPhone" rev 2.00/0.01 addr 3
Remove iPhone4S:
ugen1 detached
Dave
--
Dave Anderson
Re: iPad2 and iPhone4S USB messages
On Fri, 23 Dec 2011, Brynet wrote: >Yup, >Any new iDevice will show up as uaudio/uhid, dhill@ already committed >something so they'll attach as ugen(4) instead. For the iPhone, yes, but evidently not for the iPad2. >If you want to use libusb ports (..like gphoto2), you'll need to add similars >quirks for the iPad2. > >You didn't post the product ID. I assumed (perhaps foolishly) that this was already known since the device was recognized as '"Apple Inc. iPad" rev 2.00/0.01'. And I don't _have_ the product ID anywhere I know of (other than by looking in the source). >-Bryan. Dave -- Dave Anderson
Re: iPad2 and iPhone4S USB messages
On Fri, 23 Dec 2011, Brynet wrote: >On Fri, Dec 23, 2011 at 09:30:44PM -0500, Dave Anderson wrote: >> For the iPhone, yes, but evidently not for the iPad2. > >Yes, it will be a manual effort for as long as Apple releases new devices. > >> >If you want to use libusb ports (..like gphoto2), you'll need to add >> >similars >> >quirks for the iPad2. >> > >> >You didn't post the product ID. >> >> I assumed (perhaps foolishly) that this was already known since the >> device was recognized as '"Apple Inc. iPad" rev 2.00/0.01'. And I don't >> _have_ the product ID anywhere I know of (other than by looking in the >> source). > >That is the product name obtained from the device itself, you'll need to add it >to usbdevs and regen first. Patches for other iDevices are on the lists, it >should be easy enough for you to find them in the archives. > >Each model has it's own product ID, AFAIK they're not published by Apple. > >Look at usbdevs(8), specifically the verbose option. Ungh. I think I was confusing what appears in the dmesg for PCI devices with what appears for USB devices. Apologies to all. I'll run usbdevs and report the product ID when I get the chance. There's no urgency from my side; I'm not trying to do anything with this (yet). Dave -- Dave Anderson
Re: I want buy labtop ,work OpenBSD, wireless network must work
On Fri, 30 Dec 2011, Mostaf Faridi wrote: >Hello all guys, >After long time I want buy labtop and I want use it in my work place , in >my work place we have only wireless network and we do not have wire network >and we have linksys router and other guys connect to linksys and use >network .other guys use Windows ,but I want use OpenBSD , and I do not know >which models ,I must buy .my new labtop must work in wireless network . >Please help me which model I must buy . I can find Lenovo and Asus in here >and I can find some model of Sony too. >I want use OpenBSD with GNOME and I want use it as Desktop. >Please guide me which model I must buy ? My notebook or my labtop must has >6 gigabytes of RAM and has very powerful CPU This can be very difficult to deal with since most manufacturers not only won't tell you exactly what parts they're using but will change them without notice. What I did was to install the latest amd64 snapshot to a USB stick, boot that on the demo machines in stores, and save the dmesg to the stick so I could analyze it later for unsupported hardware. Most (but not all) stores here were willing to let me do this. I eventually found a model where everything I cared about worked. Dave -- Dave Anderson
'pkg_add -u' question
I have a notebook with a couple of devices which require non-free firmware. When I installed 5.0-release (amd64 from CD) it asked me if I wanted those files downloaded on first boot; when I said YES it proceeded to find and download them and everything 'just worked'. (This was very convenient; my thanks to the developers who made it happen.) But when I upgraded to a 5.0-current snapshot (and later rebuilt from source, most recently as of 9 January 2012) and then ran 'pkg_add -ui' it was unable to update those files: "Couldn't find updates for uvideo-firmware-1.2p0, iwn-firmware-5.6p0". I'd expect that making 'pkg_add -u' able to find these files would be fairly simple (either by giving it access to the same data used by the installer or by recording where it was found with any package added from a source not in PKG_PATH), and it would certainly make life a bit more convenient when upgrading. Am I missing something important, is this on someone's TODO list, do the installer and pkg_add developers not talk to each other, or what? Thanks in advance for any information. Dave PS: Before someone jumps all over me, I am _not_ demanding that anyone drop everything and implement this immediately; I'd just like to understand why this doesn't work and whether it's likely to start working anytime soon. And I recognize "we've got more urgent/important things to do" as a good reason for leaving this alone. I haven't looked into the pkg_add source myself because it's large, complicated and (especially) under active development. -- Dave Anderson
Re: 'pkg_add -u' question
On Sat, 14 Jan 2012, Ingo Schwarze wrote: >Hi Dave, > >Dave Anderson wrote on Sat, Jan 14, 2012 at 12:14:57PM -0500: > >> and then ran 'pkg_add -ui' it was unable to update those files: >> "Couldn't find updates for uvideo-firmware-1.2p0, iwn-firmware-5.6p0". > >The firmwares live in a different package repository, >that's why pkg_add(1) doesn't find them by default. > >If you do want to check for new firmwares, take the above >message as a reminder to run > > $ sudo fw_update > >manually. But note that's not necessarily related to doing an >operating system upgrade. Thanks for the pointer; fw_update looks like it's exactly what I need. >> I'd expect that making 'pkg_add -u' able to find these files would be >> fairly simple (either by giving it access to the same data used by the >> installer or by recording where it was found with any package added from >> a source not in PKG_PATH), > >I'm not sure i would want pkg_add(1) to look outside the PKG_PATH. > >> and it would certainly make life a bit more convenient when upgrading. >> Am I missing something important, is this on someone's TODO list, > >The only (potential, minor) problem i see is that people might run >pkg_add(1), see the "couldn't find", and not know about fw_update(1). >That's probably what happened to you. Yes. >I'm not sure how to improve that. Messages printed by programs >should be terse, so i don't think pkg_add(1) should print a >suggestion to run fw_update(1) when it sees *-firmware-* packages >it can't update. Most people will know that anyway, and there is >no strong reason to check for firmware updates at that particular >time. > >Maybe it could be mentioned in the pkg_add(1) manual. >Then again, that manual doesn't document the "Couldn't find updates" >diagnostic at all, so far. Perhaps when the 'Install non-free firmware files on first boot' option is selected the installer should mention fw_update? And/or 'pkg_add -u' should mention it as a possible solution if it issues the "couldn't find" message? I probably should have tried 'apropos firmware', but was fixated on pkg_add and didn't think to look for a different tool. _Some_ sort of more prominent mention of fw_update appears to be desirable. Dave >> do the installer and pkg_add developers not talk to each other, > >Actually, i have met all of krw@, halex@ and espie@ at least twice >during hackathons, but never together; so you may have a point... :-D > > >But no, that's not the root cause of the issue. > >Yours, > Ingo > -- Dave Anderson
Long delay updating xenocara source tree?
I've run into this problem perhaps a dozen times over the past several months while running amd64-current, most recently at 15:53 2012/1/26 EST while running a system built from source updated at about 14:30 2012/1/21 EST: when trying to update the xenocara source tree there is a very long (perhaps infinite) delay between issuing the 'cvs ...' command and the start of any visible activity. In this most recent case the delay was about 9 hours. Updating the src and ports source trees at about the same time and using the same CVSROOT has always worked OK; there's some delay but not a really long one. And sometimes the xenocara update has worked without any problem. When it doesn't, 'rm -rf /usr/xenocara' followed by reloading from the 5.0-release CD has always allowed a subsequent cvs update to work. The command I'm using is # cd /usr/xenocara && cvs -d$CVSROOT -q up -Pd (except for the working directory, exactly the same as the command for updating the src or ports tree). This has happened with several different values for CVSROOT, currently # echo $CVSROOT anon...@anoncvs1.usa.openbsd.org:/cvs I am very confused by this. Any clues would be greatly appreciated. Dave -- Dave Anderson
Re: Long delay updating xenocara source tree?
On Fri, 27 Jan 2012, Philip Guenther wrote: >On Fri, Jan 27, 2012 at 12:10 PM, Dave Anderson >wrote: >> I've run into this problem perhaps a dozen times over the past several >> months while running amd64-current, most recently at 15:53 2012/1/26 EST >> while running a system built from source updated at about 14:30 >> 2012/1/21 EST: when trying to update the xenocara source tree there is a >> very long (perhaps infinite) delay between issuing the 'cvs ...' command >> and the start of any visible activity. In this most recent case the >> delay was about 9 hours. Updating the src and ports source trees at >> about the same time and using the same CVSROOT has always worked OK; >> there's some delay but not a really long one. And sometimes the >> xenocara update has worked without any problem. When it doesn't, 'rm >> -rf /usr/xenocara' followed by reloading from the 5.0-release CD has >> always allowed a subsequent cvs update to work. >> >> The command I'm using is >> # cd /usr/xenocara && cvs -d$CVSROOT -q up -Pd >> (except for the working directory, exactly the same as the command for >> updating the src or ports tree). > >I bet it'll be faster if you don't use the -P or -d options. > >The -d option to "cvs up" requires the cvs server to walk directories >that are present on the server but not present on the client. That >includes directories which are now empty because all their files have >been removed (ala "cvs rm")...of which there are a bunch in the >xenocara tree. > >The -P option requires extra work too, though it's not as bad as the >-d option, IIRC. > >Personally, I use the rule of thumb of only using -d and -P when I >have reason to believe directories have been added or removed, either >from seeing the commit email or from a build failing because a >directory is missing... Thanks for the info. I've been using -Pd because <http://www.openbsd.org/anoncvs.html> says to use them; I haven't yet had a chance to look into how cvs works beyond reading the man page, faq, etc. Dave -- Dave Anderson
Re: 5.0 kernel won't compile on 4.9 i386 system
_SACK -DTCP_ECN -DTCP_SIGNATURE -DFIFO >-DINET -DALTQ > -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DMROUTING -DPIM -DBOOT_CONFIG >-DUSER_PCICONF -DKVM86 -DUSER_LDT -DPROCFS -DRAMDISK_HOOKS >-DMINIROOTSIZE="0x18000" > -DNKPTP="0x10" -DCOMCONSOLE -DCONSPEED="0x9600" -DBUFCACHEPERCENT="1" >-DPCIVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD >-DWSDISPLAY_D >EFAULTSCREENS="6" -DWSDISPLAY_COMPAT_PCVT -DMAXUSERS=32 -D_KERNEL -MD -MP > -c ioconf.c >cc1: warnings being treated as errors >ioconf.c:218: warning: excess elements in struct initializer >ioconf.c:218: warning: (near initialization for 'cfdata[0]') >ioconf.c:220: warning: excess elements in struct initializer >ioconf.c:220: warning: (near initialization for 'cfdata[1]') >ioconf.c:222: warning: excess elements in struct initializer >ioconf.c:222: warning: (near initialization for 'cfdata[2]') >ioconf.c:224: warning: excess elements in struct initializer >ioconf.c:224: warning: (near initialization for 'cfdata[3]') >ioconf.c:226: warning: excess elements in struct initializer >ioconf.c:226: warning: (near initialization for 'cfdata[4]') >ioconf.c:228: warning: excess elements in struct initializer >ioconf.c:228: warning: (near initialization for 'cfdata[5]') >ioconf.c:230: warning: excess elements in struct initializer >ioconf.c:230: warning: (near initialization for 'cfdata[6]') > >The last ones continue for many more lines for 68 members of the array >before the make process exits. > >Now this has happened twice, on brand new systems, also I've found other >list posts describing the same errors but no solutions applying to my >situation. So what do I do to get 5.0 compiled? > >-- >Hdlsningar / Greetings > >Stefan Midjich >[De omnibus dubitandum] > -- Dave Anderson
Re: iPad2 and iPhone4S USB messages
On Sat, 24 Dec 2011, Dave Anderson wrote: >On Fri, 23 Dec 2011, Brynet wrote: > >>On Fri, Dec 23, 2011 at 09:30:44PM -0500, Dave Anderson wrote: >>> For the iPhone, yes, but evidently not for the iPad2. >> >>Yes, it will be a manual effort for as long as Apple releases new devices. >> >>> >If you want to use libusb ports (..like gphoto2), you'll need to add >>> >similars >>> >quirks for the iPad2. >>> > >>> >You didn't post the product ID. >>> >>> I assumed (perhaps foolishly) that this was already known since the >>> device was recognized as '"Apple Inc. iPad" rev 2.00/0.01'. And I don't >>> _have_ the product ID anywhere I know of (other than by looking in the >>> source). >> >>That is the product name obtained from the device itself, you'll need to add >>it >>to usbdevs and regen first. Patches for other iDevices are on the lists, it >>should be easy enough for you to find them in the archives. >> >>Each model has it's own product ID, AFAIK they're not published by Apple. >> >>Look at usbdevs(8), specifically the verbose option. > >Ungh. I think I was confusing what appears in the dmesg for PCI devices >with what appears for USB devices. Apologies to all. I'll run usbdevs >and report the product ID when I get the chance. There's no urgency >from my side; I'm not trying to do anything with this (yet). Rather belatedly: # usbdevs -v Controller /dev/usb0: addr 1: high speed, self powered, config 1, EHCI root hub(0x), Intel(0x8086), rev 1.00 port 1 addr 2: high speed, self powered, config 1, Rate Matching Hub(0x0024), Intel(0x8087), rev 0.00 port 1 addr 3: full speed, power 100 mA, config 1, product 0x0018(0x0018), vendor 0x138a(0x138a), rev 0.78, iSerialNumber 723ca8ccb3ec port 2 addr 4: high speed, power 500 mA, config 1, HP TrueVision HD(0xd281), S uYin (0x064e), rev 1.10, iSerialNumber HF1016-A821-OV011-VH-R01.01.00 port 3 powered port 4 powered port 5 powered port 6 powered port 2 powered Controller /dev/usb1: addr 1: high speed, self powered, config 1, EHCI root hub(0x), Intel(0x8086), rev 1.00 port 1 addr 2: high speed, self powered, config 1, Rate Matching Hub(0x0024), Intel(0x8087), rev 0.00 port 1 addr 3: high speed, power 500 mA, config 2, iPad(0x129f), Apple Inc.(0x05ac), rev 0.01, iSerialNumber 0180f6af0eec5919c2d1b373dc8253afcabd1925 port 2 powered port 3 powered port 4 powered port 5 powered port 6 powered port 2 powered # Dave -- Dave Anderson
Re: Long delay updating xenocara source tree?
On Sat, 28 Jan 2012, Nick Holland wrote: >On 01/28/12 09:12, Dave Anderson wrote: >> Thanks for the info. I've been using -Pd because >> <http://www.openbsd.org/anoncvs.html> says to use them; I haven't yet >> had a chance to look into how cvs works beyond reading the man page, >> faq, etc. > >and please continue to use them. >-Pd is the RIGHT way. I plan to. Dropping them felt kind of iffy; thanks for the confirmation that it isn't the way to go. >Apparently, Philip gets away with it, but he's a developer and he knows >this stuff pretty well, we don't expect ordinary users to clean up the >mess it can make. I'll defer to his expertise on coding and probably >CVS, but there are many things in many parts of the tree where a lack of >a -Pd will hurt you in ways other than slow updates. There are >thousands of ways to use cvs incorrectly, -Pd is the correct way to do >updates (or maybe -PAd under some circumstances). > > >And none of this has anything to do with your real problem. I run far >slower hardware than most people, and xenocara updates don't take nine >hours (and if I understand you, that was nine hours then you gave up and >killed it). This has NOTHING TO DO WITH COMMAND LINE OPTIONS. I wrote >the FAQ you used, I use that FAQ, and I do it on hardware like mac68k >and sparc, and it works, it does not take nine hours to update xenocara >(it just feels like it...) No, it was about 9 hours from issuing the cvs update command until there was any visible action; the update ran to completion in a total of about 11 hours. I've killed some other update attempts which ran even longer without any visible action. >If you could...next time you see this, use a > CVSROOT=anon...@obsd.cec.mtu.edu:/cvs >and see if things run better. NOTE: DO NOT GET USED TO USING THIS >MIRROR, IT IS BEING SHUT DOWN VERY SOON. But, being it's been being >advertised as being shut down, it's pretty lightly loaded, and it >handles the CVS temp directory as an mfs, which really really helps >(this is on the server end. Nothing you can do about it on your side). >My hunch, as a soon-to-be former mirror operator is that you are having >a problem with your mirror of choice, not a problem on your end, and it >may be a problem with multiple mirrors. I've tried 3 or 4 different servers, and have had this problem with all of them (at least some of the time). >I just checked out xenocara from that mirror, and then did an update on >my amd64 system, the update took less than one minute. Your results >will vary, but not to nine hours, unless you are using dialup. :) I do have a slowish ADSL link (384Kbps/1536Kbps) which would limit me to very roughly 1MB/min outbound, so I took advice to use '-z 9' to compress data and that reduced the total time for a xenocara source tree update from about 11 hours to about 2.5 hours. (Though I discovered that not all servers support compression.) Then I did a test update of xenocara against your server (still using -z 9), and the entire process took barely 1 minute. I then retried that upgrade against the server I've been using (anoncvs.comstyle.com), and the total time was just under 3 minutes. As a final (for the moment) test I did (against my usual server and with -z 9) an update of my entire source tree and the total times were src: 7:37, xenocara: 3:55, ports: 41:58, and www: 2:39 -- for a total of about 55 minutes. I've no idea why I'm suddenly getting so much faster responses. Does cvs update send a potentially large but extremely variable amount of data from my system to the server? If so, that (plus my slowish uplink) might explain some of these timings. But the cause of these massive variations is not at all obvious from where I sit. Thanks for any further info. Dave -- Dave Anderson
Re: Long delay updating xenocara source tree?
On Fri, 3 Feb 2012, Otto Moerbeek wrote: >On Thu, Feb 02, 2012 at 03:15:29PM +0100, Steffen Daode Nurpmeso wrote: > >> Henning Brauer wrote: >> > there aren't all that many repositories the size of ours out there. >> >> That's true. >> But no Henning, i don't believe it's that; >> you know, it's just that i don't have anything to say, because >> i have no knowledge about the internals of cvs(1). >> >> I always thought of this as some kind of misbehaviour in between >> OpenCVS and GNU cvs, because i would think of cvs(1) as something >> like this: >> >> cvs up . >> | >> read CVS/Entries >> | >> for those files with diff. timestamps, checksum file >> | >> send list [+ checksums] to server >> | >> server compare revision/timestamp/[checksum] >> - client unmodified: send diff (expected final checksum?) >> - client modified: send full file (if size < treshold), >> otherwise do blockwise checksumming etc. (i.e. rsync-like) >> [I don't really believe cvs(1) does the latter though.] >> | >> integrate diffs / replace locally modified files >> >> Wether cvs(1) does do some rsync-like block-checksumming for >> locally modified files or not, uploading 10% of the repositories >> size or more before any data is sent from the server just can't be >> correct anyhow. Even more for my usage case because there were no >> locally modified files at all. >> >> And also the problem goes away if you do specify files directly, >> as with a file glob, so it makes a difference wether you say >> $ cvs -fz9 up -PAC . >> or >> $ cvs -fz9 up -PAC *.* >> I don't remember wether i've used -d or not. >> >> So for me this turned out as either "look into the code, >> instrument some functions and try to fix it" or "turn over to >> cvsync". >> And GNU cvs is hard to look at, with a lot of comments which refer >> to some (numeric or so) error reports. But it would surely be >> interesting to know what is going wrong. >> >> --steffen > >I like to say that long delays I have seen when using cvs had to do >with multiple different values of CVS/Root files in my local tree. > >Those different entries can be created when doing a cvs up -d that >creates a new dir. If a cvs -d option is used at the same time, the >CVS/Root entry for tht dir wil be different than the other's. > >The exact cause of the slowdown is not known to me. But when you are >switch repositories once in a while it's easy to get this case. > >I repair this by find . -name Root | xargs rm and using a explicit cvs >root. > > -Otto Hmmm. That doesn't seem to [fully] explain the slowdowns I've seen, since I always use an explicit cvs root (following the FAQ) though I certainly have switched repositories from time to time. Dave -- Dave Anderson
/etc/daily bug? altroot vs DUIDs
I've got a system running amd64/mp -current (latest source update on
February 1st) and have noticed (for quite a while, actually) that the
nightly backup of / to /altroot wasn't working. I finally got around to
looking into this and discovered that the /etc/daily script was
explicitly checking for /dev/whatever in the /altroot fstab entry -- but
I've been using DUIDs (as set up by the installer).
Shouldn't the daily script be updated to handle DUIDs as well as
explicit devices in /etc/fstab?
Dave
--
Dave Anderson
Re: /etc/daily bug? altroot vs DUIDs
On Tue, 7 Feb 2012, Kenneth R Westerback wrote:
>On Tue, Feb 07, 2012 at 09:42:07AM -0500, Dave Anderson wrote:
>> I've got a system running amd64/mp -current (latest source update on
>> February 1st) and have noticed (for quite a while, actually) that the
>> nightly backup of / to /altroot wasn't working. I finally got around to
>> looking into this and discovered that the /etc/daily script was
>> explicitly checking for /dev/whatever in the /altroot fstab entry -- but
>> I've been using DUIDs (as set up by the installer).
>>
>> Shouldn't the daily script be updated to handle DUIDs as well as
>> explicit devices in /etc/fstab?
>>
>> Dave
>
>Does this diff work for you? Test with duid and without would be
>nice. :-)
>
>And don't be bashful. Anybody can test!
>
> Ken
That works for me, both ways.
Thanks,
Dave
>Index: daily
>===
>RCS file: /cvs/src/etc/daily,v
>retrieving revision 1.72
>diff -u -p -r1.72 daily
>--- daily 6 Dec 2011 21:02:39 - 1.72
>+++ daily 7 Feb 2012 20:14:26 -
>@@ -90,20 +90,20 @@ if [ -f /var/account/acct ]; then
> fi
>
> # If ROOTBACKUP is set to 1 in the environment, and
>-# if filesystem named /altroot is type ffs, on /dev/* and mounted "xx",
>+# if filesystem named /altroot is type ffs and mounted "xx",
> # use it as a backup root filesystem to be updated daily.
> next_part "Backing up root filesystem:"
> while [ "X$ROOTBACKUP" = X1 ]; do
>- rootbak=`awk '$2 == "/altroot" && $1 ~ /^\/dev\// && $3 == "ffs" && \
>- $4 ~ /xx/ \
>- { print substr($1, 6) }' < /etc/fstab`
>+ rootbak=`awk '$2 == "/altroot" && $3 == "ffs" && $4 ~ /xx/ \
>+ { print $1 }' < /etc/fstab`
> if [ -z "$rootbak" ]; then
> echo "No xx ffs /altroot device found in the fstab(5)."
> break
> fi
>- bakdisk=${rootbak%[a-p]}
>+ rootbak=${rootbak#/dev/}
>+ bakdisk=${rootbak%%?(.)[a-p]}
> sysctl -n hw.disknames | grep -Fqw $bakdisk || break
>- bakpart=${rootbak#$bakdisk}
>+ bakpart=${rootbak##$bakdisk?(.)}
> baksize=`disklabel $bakdisk 2>/dev/null | \
> awk -v "part=$bakpart:" '$1 == part { print $2 }'`
> rootdev=`mount | awk '$3 == "/" && $1 ~ /^\/dev\// && $5 == "ffs" \
--
Dave Anderson
Re: /etc/daily bug? altroot vs DUIDs
On Wed, 8 Feb 2012, Dave Anderson wrote:
>On Tue, 7 Feb 2012, Kenneth R Westerback wrote:
>
>>On Tue, Feb 07, 2012 at 09:42:07AM -0500, Dave Anderson wrote:
>>> I've got a system running amd64/mp -current (latest source update on
>>> February 1st) and have noticed (for quite a while, actually) that the
>>> nightly backup of / to /altroot wasn't working. I finally got around to
>>> looking into this and discovered that the /etc/daily script was
>>> explicitly checking for /dev/whatever in the /altroot fstab entry -- but
>>> I've been using DUIDs (as set up by the installer).
>>>
>>> Shouldn't the daily script be updated to handle DUIDs as well as
>>> explicit devices in /etc/fstab?
>>>
>>> Dave
>>
>>Does this diff work for you? Test with duid and without would be
>>nice. :-)
>>
>>And don't be bashful. Anybody can test!
>>
>> Ken
>
>That works for me, both ways.
>
>Thanks,
>
> Dave
Aaargh! Not quite, it turns out. This superficially appears to work,
and does seem to work in the non-DUID case, but I evidently didn't look
at the results carefully enough. In the DUID case, rather than copying
/ to the altroot partition it copies it to /dev/r.!
My bad. Apologies to all.
I remember seeing a commit which sounds like it might tweak some
low-level functions to translate DUIDs into devices; I'll upgrade to a
current -current and see if this problem goes away.
Dave
>>Index: daily
>>===
>>RCS file: /cvs/src/etc/daily,v
>>retrieving revision 1.72
>>diff -u -p -r1.72 daily
>>--- daily 6 Dec 2011 21:02:39 - 1.72
>>+++ daily 7 Feb 2012 20:14:26 -
>>@@ -90,20 +90,20 @@ if [ -f /var/account/acct ]; then
>> fi
>>
>> # If ROOTBACKUP is set to 1 in the environment, and
>>-# if filesystem named /altroot is type ffs, on /dev/* and mounted "xx",
>>+# if filesystem named /altroot is type ffs and mounted "xx",
>> # use it as a backup root filesystem to be updated daily.
>> next_part "Backing up root filesystem:"
>> while [ "X$ROOTBACKUP" = X1 ]; do
>>- rootbak=`awk '$2 == "/altroot" && $1 ~ /^\/dev\// && $3 == "ffs" && \
>>- $4 ~ /xx/ \
>>- { print substr($1, 6) }' < /etc/fstab`
>>+ rootbak=`awk '$2 == "/altroot" && $3 == "ffs" && $4 ~ /xx/ \
>>+ { print $1 }' < /etc/fstab`
>> if [ -z "$rootbak" ]; then
>> echo "No xx ffs /altroot device found in the fstab(5)."
>> break
>> fi
>>- bakdisk=${rootbak%[a-p]}
>>+ rootbak=${rootbak#/dev/}
>>+ bakdisk=${rootbak%%?(.)[a-p]}
>> sysctl -n hw.disknames | grep -Fqw $bakdisk || break
>>- bakpart=${rootbak#$bakdisk}
>>+ bakpart=${rootbak##$bakdisk?(.)}
>> baksize=`disklabel $bakdisk 2>/dev/null | \
>> awk -v "part=$bakpart:" '$1 == part { print $2 }'`
>> rootdev=`mount | awk '$3 == "/" && $1 ~ /^\/dev\// && $5 == "ffs" \
>
>
--
Dave Anderson
AHCI0 errors with 5.1-current
acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (PEG0) acpiprt11 at acpi0: bus -1 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiprt13 at acpi0: bus -1 (PEG3) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpicpu2 at acpi0: C3, C2, C1, PSS acpicpu3 at acpi0: C3, C2, C1, PSS acpicpu4 at acpi0: C3, C2, C1, PSS acpicpu5 at acpi0: C3, C2, C1, PSS acpicpu6 at acpi0: C3, C2, C1, PSS acpicpu7 at acpi0: C3, C2, C1, PSS acpitz0 at acpi0: critical temperature is 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: PWRB acpibat0 at acpi0: BAT0 model "8850" serial Li4402A type Li oem " Hewlett-Packard " acpiac0 at acpi0: AC unit online acpidock0 at acpi0: DOCK not docked (0) acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD02 cpu0: Enhanced SpeedStep 1995 MHz: speeds: 2001, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09 vga1 at pci0 dev 2 function 0 "Intel GT2 Video" rev 0x09 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xb000, size 0x1000 inteldrm0 at vga1: apic 0 int 16 drm0 at inteldrm0 "Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x05: apic 0 int 16 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 "Intel 6 Series HD Audio" rev 0x05: msi azalia0: codecs: IDT 92HD81B1X, Intel/0x2805, using IDT 92HD81B1X audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 6 Series PCIE" rev 0xb5: msi pci1 at ppb0 bus 1 re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E-VL (0x2c80), apic 0 int 16, address 2c:41:38:62:07:07 rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 5 ppb1 at pci0 dev 28 function 1 "Intel 6 Series PCIE" rev 0xb5: msi pci2 at ppb1 bus 7 iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 1000" rev 0x00: msi, MIMO 1T2R, BGS, address 74:e5:0b:1f:01:62 ppb2 at pci0 dev 28 function 2 "Intel 6 Series PCIE" rev 0xb5: msi pci3 at ppb2 bus 13 "Realtek RTS5209 Card Reader" rev 0x01 at pci3 dev 0 function 0 not configured sdhc0 at pci3 dev 0 function 1 "Realtek RTS5209 Card Reader" rev 0x01: apic 0 int 19 sdmmc0 at sdhc0 ppb3 at pci0 dev 28 function 3 "Intel 6 Series PCIE" rev 0xb5: msi pci4 at ppb3 bus 19 "NEC xHCI" rev 0x04 at pci4 dev 0 function 0 not configured ehci1 at pci0 dev 29 function 0 "Intel 6 Series USB" rev 0x05: apic 0 int 20 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1 pcib0 at pci0 dev 31 function 0 "Intel HM65 LPC" rev 0x05 ahci0 at pci0 dev 31 function 2 "Intel 6 Series AHCI" rev 0x05: msi, AHCI 1.3 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct fixed naa.5000c50044718f26 sd0: 715404MB, 512 bytes/sector, 1465149168 sectors cd0 at scsibus0 targ 5 lun 0: ATAPI 5/cdrom removable ichiic0 at pci0 dev 31 function 3 "Intel 6 Series SMBus" rev 0x05: apic 0 int 19 iic0 at ichiic0 spdmem0 at iic0 addr 0x50: 2GB DDR3 SDRAM PC3-10600 SO-DIMM spdmem1 at iic0 addr 0x52: 4GB DDR3 SDRAM PC3-10600 SO-DIMM isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pms0: Synaptics touchpad, firmware 7.5 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 mtrr: Pentium Pro MTRR support uhub2 at uhub0 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2 ugen0 at uhub2 port 1 "vendor 0x138a product 0x0018" rev 1.10/0.78 addr 3 uvideo0 at uhub2 port 2 configuration 1 interface 0 "SuYin HP TrueVision HD" rev 2.00/1.10 addr 4 video0 at uvideo0 uhub3 at uhub1 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2 vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets root on sd0a (c3ffcff67dc13a92.a) swap on sd0b dump on sd0b -- Dave Anderson
Re: AHCI0 errors with 5.1-current
On Mon, 27 Feb 2012, Dave Anderson wrote: >I recently upgraded an HP dv7-6b63us notebook (dmesg below) to amd64/mp >5.1-current as of about 11:30 EST 25 February 2012 (rebuilt from source >several times since installing a 7 February snapshot) and have started >seeing > > ahci0: attempting to idle device > ahci0: couldn't recover NCQ error, failing all outstanding commands. > >messages on the console and in the dmesg buffer; their timing doesn't >correlate with anything obvious to me. If anyone has test code to run >or other suggestions for how to track this down I'll be happy to help. In the absence of any response, I've brought my source tree up to 5.1-current as of about 14:15 EST on 3 March and rebuilt my system; if the errors continue I'll report back. Dave >OpenBSD 5.1-current (GENERIC.MP) #1: Sat Feb 25 23:04:41 EST 2012 >r...@minya.daveanderson.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP >real mem = 6387134464 (6091MB) >avail mem = 6202941440 (5915MB) >mainbus0 at root >bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe67b0 (33 entries) >bios0: vendor Hewlett-Packard version "F.02" date 10/03/2011 >bios0: Hewlett-Packard HP Pavilion dv7 Notebook PC >acpi0 at bios0: rev 2 >acpi0: sleep states S0 S3 S4 S5 >acpi0: tables DSDT FACP ASF! HPET APIC MCFG SLIC SSDT BOOT ASPT SSDT SSDT SSDT >SSDT >acpi0: wakeup devices P0P1(S3) LID_(S3) GLAN(S4) EHC1(S3) EHC2(S3) HDEF(S0) >PXSX(S4) RP01(S4) PXSX(S4) RP02(S3) PXSX(S4) RP03(S3) PXSX(S4) RP04(S3) >PXSX(S4) RP05(S3) PXSX(S4) RP06(S3) PXSX(S4) RP07(S3) PXSX(S4) RP08(S3) >PEG0(S4) PEGP(S4) PEG1(S4) PEG2(S4) PEG3(S4) PWRB(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) i7-2630QM CPU @ 2.00GHz, 1995.75 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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF >cpu0: 256KB 64b/line 8-way L2 cache >cpu0: apic clock running at 99MHz >cpu1 at mainbus0: apid 1 (application processor) >cpu1: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz >cpu1: >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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF >cpu1: 256KB 64b/line 8-way L2 cache >cpu2 at mainbus0: apid 2 (application processor) >cpu2: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz >cpu2: >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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF >cpu2: 256KB 64b/line 8-way L2 cache >cpu3 at mainbus0: apid 3 (application processor) >cpu3: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz >cpu3: >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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF >cpu3: 256KB 64b/line 8-way L2 cache >cpu4 at mainbus0: apid 4 (application processor) >cpu4: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz >cpu4: >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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF >cpu4: 256KB 64b/line 8-way L2 cache >cpu5 at mainbus0: apid 5 (application processor) >cpu5: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz >cpu5: >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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF >cpu5: 256KB 64b/line 8-way L2 cache >cpu6 at mainbus0: apid 6 (application processor) >cpu6: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz >cpu6: >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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF >cpu6: 256KB 64b/line 8-way L2 cache >cpu7 at mainbus0: apid 7 (application processor) >cpu7: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz >cpu7: >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,SBF,SSE3,PCLMUL,
Re: My OpenBSD 5.0 installation experience (long rant)
On Wed, 7 Mar 2012, Stuart Henderson wrote: >On 2012-03-07, Leonardo Sabino dos Santos wrote: >> On Wed, Mar 7, 2012 at 1:43 PM, Dmitrij D. Czarkoff >> wrote: >>> On Wed, 2012-03-07 at 13:26 +0100, Leonardo Sabino dos Santos wrote: >>>> Next, the disk stuff comes up. A lot of partition information appears >>>> on the screen, followed by the question: >>>> >>>> Use (W)hole disk or (E)dit the MBR? [whole] >>>> >>>> At this point I'm actually trying to remember if there's a way to >>>> scroll back the console, because some information has scrolled of the >>>> screen. I try PageUp, PageDown, Ctrl-UpArrow, Ctrl-DownArrow, but >>>> nothing works, so I press Enter. >>> >>> You were asked whether you want to edit MBR or use the whole disk, and >>> you chose using the whole disk. This resulted in your disk being >>> occupied by single A6 partition. >>> >>> So, what went wrong? What kind of confirmation did you want? >> >> I pressed Enter by mistake there (and realized my mistake a couple of >> seconds too late). The kind of confirmation I expected is something >> like: "This will erase all partitions, are you sure (y/n)?", or an >> opportunity to review the settings before committing to the install. > >The thing is, then you'll want another after you edit disklabel, >and another before running newfs (which is the first part which is >likely to be really tough to recover from). And then when the OS >is booted maybe you'll want rm to ask for confirmation, etc. To be fair (which is a bit difficult given the tone of the original message) he has identified what may be the only place in the install process where a single wrong keystroke can do major damage. Everyplace else I can think of there's at least an opportunity to abort the installation after making a mistake but before the damage is done. I've no great love for 'are you sure' questions, but they may be appropriate where they prevent a single easy-to-make mistake from causing serious damage. Dave -- Dave Anderson
Re: About Xen: maybe a reiterative question but ..
On Wed, 24 Oct 2007, L. V. Lammert wrote: >Virtualization provides near absolute security - DOM0 is not visible to >the user at all, only passing network traffic and handling kernel calls. >The security comes about in that each DOMU is totally isolated from the >the others, while the core DOM0 is isolated from any attacks. In theory, you're correct. In practice there are (at least) four questions which all must be answered in the affirmative for this to be true: 1) Does the hardware architecture provide all of the hooks needed to implement virtualization? 2) Does the specific hardware correctly implement that architecture? 3) Does the virtualization software architecture properly implement virtualization? 4) Does the specific software correctly implement that architecture? Answering any of those questions takes both a lot of work and, all too often, access to information which is not generally available. And if any of the answers is 'no', the security of anything run under that virtualization may be fatally compromised -- no matter how secure that software may be when run standalone. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: [Fwd: Open-Hardware]
On Sun, 6 Jan 2008, Richard Stallman wrote: >In the case of hardware, it would mean it is too expensive to copy... >which it could be... so does that mean freedom to copy something >became irrelevant as the cost of copying becomes relatively expensive? > >When something is impractical to copy, then the question of whether we >are free to do so is purely academic, and I see no reason to fight >about it. When something is feasible to copy, then the question of >whether we are free to do so makes a real difference. Isn't this attitude more than a bit short-sighted? I certainly understand the benefits of reserving one's resources for dealing with issues that "can happen", but many of the technology-related problems we have today are arguably due (at least in large part) to people ignoring them as "not possible" until they had already become established practice (and so, almost impossible to undo). Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Real men don't attack straw men
On Sun, 6 Jan 2008, Richard Stallman wrote: >I don't think OpenBSD users understand what you mean by "recommend >non-free software", > >I explained it earlier in this thread. > > so if you could, please, give an example by >showing where OpenBSD (web-site?) says that it recommend non-free >software and the URL. > >In OpenBSD the recommendation for certain non-free programs >is in the recipes for installing them. IMO, a big part of the problem here is that when you say "recommend" in this context what you actually mean appears (based on the discussion here) to be something that most people would express as "not deliberately erect barriers against". If you were to consistently express yourself using the common definitions of words rather than your own perverse definition of "recommend", I expect that most of this discussion would end. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: avoiding a mac address filter
On Mon, 7 Jan 2008, Pau Amaro-Seoane wrote: >loosen up a bit, you're too tight up... I just want to check my >emails, I don't want to download p0nr movies Theft of service is theft, regardless of how much or little service you're stealing. If someone's gone to the trouble of filtering on MAC addresses, they've clearly indicated that they're not a public service -- and no amount of weasel-wording will get around that. Dave >2008/1/7, Josh Grosse <[EMAIL PROTECTED]>: >> On Mon, 7 Jan 2008 13:39:01 +0100, Targus Neoprene wrote >> > Hi, >> > >> > in my flat I can "see" a lot of "open" connection points. They do not >> > require a password and, in principle, I can log in every time... but >> > they seem to be protected with a mac filter, because I cannot get an >> > IP address via dhclient >> > >> > I have a naive question: Is there any way to avoid that? I mean: is >> > there a way to surpass the mac filter and get an ip? >> >> Do I understand this correctly? You are asking how to *defeat* someone >> else's >> SOHO NAT router, using its MAC filter as their only security? >> >> If so, I'm appalled by your lack of ethics. -- Dave Anderson <[EMAIL PROTECTED]>
Re: [Fwd: Open-Hardware]
On Tue, 8 Jan 2008, Sunnz wrote: >7 Jan 2008 07:58:04 -0800, Unix Fan <[EMAIL PROTECTED]>: >>These firmwares are just the same as "Microcode" in modern processors, >>It's "NOT" tainting the kernel at all... unlike "binary blob" drivers >>that are very common in the > >Just wondering... what could be the worse thing that could happen if >the firmware is badly written, say for a wireless device? Could it be >possible to bring the whole system down? Or would it just crash the >device itself, as if the hardware had a defect? On some architectures, some devices have access to all of main memory -- so malicious firmware could do just about anything. And most devices can at least lock up a bus and so hang the system. But this is true of _all_ device firmware, whether it's loaded by the system, upgradable (e.g., EEPROM) or permanent (e.g., ROM) -- it's just easier to provide a malicious firmware file for loading than it is to convince someone to replace a ROM chip. Even for a pure-hardware device, with no firmware at all, you still have to trust the manufacturer to avoid bugs which can harm the system as a whole. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Real men don't attack straw men
On Mon, 7 Jan 2008, Richard Stallman wrote: >Quick question, do we really need an endorsement from Richard Stallman and > the >FSF for OpenBSD? > >If OpenBSD does not need my endorsement, then OpenBSD developers >should not need to argue with me that I owe them an endorsement. I don't recall seeing any of them claiming that. Many of them _have_ (quite reasonably) objected to your spreading misinformation about OpenBSD. And making statements which are true only if common words are given non-standard meanings certainly amounts to spreading misinformation. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Real men don't attack straw men
On Mon, 7 Jan 2008, Richard Stallman wrote: >IMO, a big part of the problem here is that when you say "recommend" in >this context what you actually mean appears (based on the discussion >here) to be something that most people would express as "not >deliberately erect barriers against". > >The evidence of this discussion shows that's not a good description >for what I am saying. You've apparently been reading a very different set of responses from the ones I've read. AFAICT from their messages, most of the people responding here to this issue agree with me. > Many of the people on this list were told that >I want OpenBSD to "erect barriers against" installing non-free >programs. That's the only plausible conclusion I can draw from your own words. AFAICT from your messages, the absolute minimum that would satisfy you is for OpenBSD to never mention anywhere, in any manner (except perhaps a negative one), anything which is non-free (by your definition). Since this would require explicitly rejecting any proposed addition to the ports collection which would install something which is 'non-free', you do require erecting barriers. > And their words show that they think this means designing >the system so that installing non-free programs is impossible. (I >have not suggested such a thing.) > >My usage of the "recommend" fits in normal usage. Sorry, but that's nonsense. "Mentioning" and "recommending" are very different things, and what OpenBSD does is no more than mentioning. > If you include >program FOO in a list of programs that could be installed, implicitly >that recommends installing FOO as an option for people to consider. > >Perhaps "implicitly recommend" would be a clearer description of this >particular case. It would be closer to reality, but would still massively overstate the case. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Real men don't attack straw men
On Tue, 8 Jan 2008, Richard Stallman wrote: >>If OpenBSD does not need my endorsement, then OpenBSD developers >>should not need to argue with me that I owe them an endorsement. > >I don't recall seeing any of them claiming that. > >Many of the messages have argued (or even demanded) that I >change my criteria and endorse OpenBSD. In the past two days, >several people tried to argue that I should change my position >regarding firmware. AFAICT most of the people on this list are users, not developers. I don't recall anyone I recognize as being a developer demanding that you endorse OpenBSD. Developers certainly have demanded that you change what you say about OpenBSD, since what you have said is misleading. They've also pointed out apparent inconsistencies between how you treat OpenBSD and how you treat more-favored systems. But that's quite different from demanding an endorsement. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Real men don't attack straw men
On Tue, 8 Jan 2008, Richard Stallman wrote: >You've apparently been reading a very different set of responses from >the ones I've read. AFAICT from their messages, most of the people >responding here to this issue agree with me. > >Most of the people responding here, yes, but that doesn't >mean _most people_ would see it that way. Not necessarily, but since you've provided no evidence whatsoever that anyone other than FSFers agrees with you the way to bet is that the general public would mostly agree with me. The group participating here is a lot more diverse than just the FSF. >> Many of the people on this list were told that >>I want OpenBSD to "erect barriers against" installing non-free >>programs. > >That's the only plausible conclusion I can draw from your own words. > >I would not call this a "barrier against installing" those programs. I'm sure you wouldn't, but it is one nonetheless. >AFAICT from your messages, the absolute minimum that would satisfy you >is for OpenBSD to never mention anywhere, in any manner (except perhaps >a negative one), anything which is non-free (by your definition). > >That's a little more than my standard. Many applications talk >about some non-free programs in passing. I don't object to that. >But you see what _kind_ of thing I'm concerned about. > >Since this would require explicitly rejecting any proposed addition to >the ports collection which would install something which is 'non-free', > >Yes. > >you do require erecting barriers. > >I would not call this a "barrier". But, whatever we call it, at >least you understand concretely what I mean. It's something which makes it harder for the user to install a 'non-free' program than it is for him to install a 'free' program. That's the essence of a barrier. Claiming anything else is, at best, weasel-wording. >One reason I do not want to call this a "barrier" is that it suggests >other things. Many people thought I objected to the general capability >of the ports system to install any program. That misunderstanding >seems to come words like "barrier". Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: : Zombie Network Spam Attack
On Fri, 8 Feb 2008, Raimo Niskanen wrote: >Now I am trying to improve the Greyscanner. I noticed it did not >trap hosts using an empty envelope sender, unless there were >more than one entry from that host. I regarded it as a bug >and fixed it. I hope an empty envelope sender really >is suspicious or disallowed. Read the RFCs rather than guessing. 'Mail From: <>' is not merely allowed but is _required_ when a delivery-failure message is sent. You're throwing away most legitimate notifications of errors delivering messages which originated on your server. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: : Zombie Network Spam Attack
On Fri, 8 Feb 2008, Peter N. M. Hansteen wrote: >Raimo Niskanen <[EMAIL PROTECTED]> writes: > >> If a backscatter gets through to sendmail, and it is to an invalid >> user, what is the proper thing for sendmail to do? My sendmail >> most probably does the default, which I guess is to bounce the mail. > >yes, if you receive a message intended for a non-existing user, you >most likely bounce with 'unknown user' or the equivalent. it's the >other end, where spam apparently gets delivered, that's making more >noise than necessary by bouncing messages that should have simply been >forwarded to /dev/null instead. While I agree with most of what you're saying, quietly dropping messages identified as spam is _not_ the best way of handling them -- since it's rarely possible to be 100% certain that a message really is spam, and it's harmful to not notify the sender that a legitimate message has not been delivered. We'd all be a lot better off if everyone running a mail server went to the extra effort of configuring their server to reject as many problem messages as possible during the SMTP session rather than accepting them and then having to either drop them without notice or send a failure message to the 'from' header address. That way the sender of legitimate messages gets notified of any problems, but the server doesn't contribute to the 'distributed mail-bombing' caused by forged 'from' header addresses in spam. While it's not possible to do this in _all_ cases, bad addresses can be handled at the SMTP 'rcpt to' command with (usually) very little effort and greylisting (and associated tools) can reject a large fraction of spam messages at this stage. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: : Zombie Network Spam Attack
On Fri, 8 Feb 2008, Stuart Henderson wrote: >On 2008/02/08 11:35, Dave Anderson wrote: >> On Fri, 8 Feb 2008, Peter N. M. Hansteen wrote: >> >> >Raimo Niskanen <[EMAIL PROTECTED]> writes: >> > >> >> If a backscatter gets through to sendmail, and it is to an invalid >> >> user, what is the proper thing for sendmail to do? My sendmail >> >> most probably does the default, which I guess is to bounce the mail. >> > >> >yes, if you receive a message intended for a non-existing user, you >> >most likely bounce with 'unknown user' or the equivalent. it's the >> >other end, where spam apparently gets delivered, that's making more >> >noise than necessary by bouncing messages that should have simply been >> >forwarded to /dev/null instead. >> >> While I agree with most of what you're saying, quietly dropping messages >> identified as spam is _not_ the best way of handling them -- since it's >> rarely possible to be 100% certain that a message really is spam, and >> it's harmful to not notify the sender that a legitimate message has not >> been delivered. > >If you do this, and people forward mail to your machine, or you list >a backup MX which accepts some spam that your machine doesn't, your >policy results in backscatter to the envelope sender address. As I stated in the part of my message that you didn't quote, it's not a 100% solution -- but it would drastically reduce the amount of backscatter if everyone did it. And, IMO, some backscatter is a much less serious problem than _any_ legitimate message disappearing without a trace. >There's no right answer... There's no _perfect_ answer (short of a complete redesign of SMTP), but there are certainly ones which improve on the current state of affairs. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: pf tag goes missing post sshd tcp decapsulization
On Fri, 7 Mar 2008, Konrad wrote:
>>> Nice, you probably want to keep the application/kernel tag name spaces
>>> distinct though. Otherwise it would be easy for any local user/program
>>> to mess with pf.conf generated tags and bypass filtering etc. It could
>>> be as easy as adding a prefix ("APP_" ?) to all application generated
>>> tags.
>
>>actually you have a point here... sockets don't even require root.
>
>That is true, my point is that to change the tags in the kernel is not
>a nice way. A programm which set the tag "VPN1" and will get
>"APP_VPN1" ?? This is not a good behavior, IMHO.
Why not just require that any application-generated tag must start with
some fixed string ("APP_" or "@" or whatever)?
Dave
--
Dave Anderson
<[EMAIL PROTECTED]>
Re: pf tag goes missing post sshd tcp decapsulization
On Fri, 7 Mar 2008, Henning Brauer wrote:
>* Dave Anderson <[EMAIL PROTECTED]> [2008-03-07 17:34]:
>> On Fri, 7 Mar 2008, Konrad wrote:
>>
>> >>> Nice, you probably want to keep the application/kernel tag name spaces
>> >>> distinct though. Otherwise it would be easy for any local user/program
>> >>> to mess with pf.conf generated tags and bypass filtering etc. It could
>> >>> be as easy as adding a prefix ("APP_" ?) to all application generated
>> >>> tags.
>> >
>> >>actually you have a point here... sockets don't even require root.
>> >
>> >That is true, my point is that to change the tags in the kernel is not
>> >a nice way. A programm which set the tag "VPN1" and will get
>> >"APP_VPN1" ?? This is not a good behavior, IMHO.
>>
>> Why not just require that any application-generated tag must start with
>> some fixed string ("APP_" or "@" or whatever)?
>
>not enough, you don't want an app started by joe random to assign the
>same packet as, say, ftp-proxy...
Interesting point. Exactly what separation of namespaces does need to
be enforced? Applications running with root privileges presumably
should be able to set any tag. How many different namespaces are needed
for all the non-root processes, and how do they get assigned to the
appropriate namespace? Do we need one per user plus one per group to
provide flexibility while preventing interference? If so, using
prefixes like "@U_" and "@G_" would be
simple for both the application designer and the person crafting the pf
rules to understand. Or should this, at least for the moment, be
limited to root processes?
Dave
--
Dave Anderson
<[EMAIL PROTECTED]>
FYI: Discrepancy between pf FAQ and man pf.conf(5)
I've been working on the pf configuration for my home firewall, and have reviewed a lot of documentation in the process. I've noticed that, when discussing queueing, the pf FAQ mentions only CBQ and PRIQ while man pf.conf(5) also defines HFSC. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Flexibility of pf rules created by ftp-proxy?
I've been working on the pf configuration for my home firewall,
including setting up ftp-proxy. I've noticed that the command is
getting cluttered with options to adjust the rules it creates to the
needs of different pf configurations. Has any thought been given to
allowing arbitrary nat, rdr and pass rules to be specified in a
configuration file (in the same syntax as for pf.conf) with macros
defined for the server, client and proxy addresses (as in the examples;
also, perhaps, a few other macros -- such as for the interfaces through
which the client and server are reachable)?
I'm not asking (let alone demanding) that anyone implement this, but
would like to know if it's been considered and rejected for some
reason, is on someone's to-do list, has never been thought about, or
whatever. It seems to me to be a good way both to avoid needing more
and more options to tweak the generated rules and to avoid the delay
involved in modifying the program whenever someone comes up with a new
need.
Thanks in advance for any info,
Dave
--
Dave Anderson
<[EMAIL PROTECTED]>
Re: FYI: Discrepancy between pf FAQ and man pf.conf(5)
On Mon, 17 Mar 2008, Peter N. M. Hansteen wrote: >"Dave Anderson" <[EMAIL PROTECTED]> writes: > >> that, when discussing queueing, the pf FAQ mentions only CBQ and PRIQ >> while man pf.conf(5) also defines HFSC. > >It's probably a matter of coming up with an example configuration that >is simple enough to present well within the probable reader's >attention span and fits document's format, corresponds reasonably well >to a situation a prospective reader would regognize, and with the >characteristics to demonstrate what makes HFSC stand out as the better >algorithm for that particular application, in an example that is >sophisticated enough to demonstrate a reasonably complete set of >significant parameters while keeping the reader's focused on the >relative strengths of the algorithm rather than getting lost in >potentially confusing detail. > >That just about sums up why writing up something along those lines is >still on my list of things to do, rather than written and published >already. I will keep trying, the general task juggling allowing. That's all true, and anyone who would depend on the FAQ without also looking at the man pages is probably better off not trying to use HFSC. It's just that my sense of the quality of OpenBSD documentation is offended by the fact that HFSC isn't mentioned at all in text which appears to discuss all of the options. >I realize this probably sounds terribly condescending, that's not what >I intended. It's just that some subjects are in fact very hard to >write well. Not a problem. Dave -- Dave Anderson <[EMAIL PROTECTED]>
A few questions for which I haven't found answers...
I've been working on the pf configuration for my home firewall (which has a single static public IP address, hides half a dozen other systems behind NAT, and is being upgraded to OpenBSD 4.2), and have come up with some questions for which I can't find answers in the documentation. (I've searched the mailing list archives and (re)read the 4.2 pf FAQ, the 4.2 man pages for pf(4), bpf(4), ip(4), inet(3), netintro(4), socket(2), route(4), connect(2), bind(2), ifconfig(8), ftp-proxy(8), ftp(1), pf.conf(5) and the man page for the 4.2 package for ftpsesame.) The pf FAQ states that for the 'urpf-failed' source "the source IP address of the packet is looked up in the routing table. If the outbound interface found in the routing table entry is the same as the interface that the packet just came in on, then the uRPF check passes"; this is basically what I'd expect, but I haven't found confirmation of it in any of the man pages. [Also, what happens if the interface found by the lookup is not a hardware interface?] This should mean that this rule block drop in log quick from urpf-failed to any would make this rule block drop in log quick from no-route to any redundant, and would also eliminate the need for all 'antispoof' rules. Are these inferences correct? 'ftp-proxy' will handle FTP connections to external servers from the systems behind the firewall, but I don't see any way to make it also handle connections from the firewall itself. The best tool I've found for that is 'ftpsesame' (in packages), despite the fact that it apparently suffers from race conditions when setting up rules, but I don't see any obvious way to configure it to only process the FTP control connections which have not already been dealt with by ftp-proxy. 'ftpsesame' uses bpf (which apparently, but I haven't been able to confirm this, sees inbound packets before pf does and sees outbound packets after pf is finished with them) with, by default, a filter to select only TCP packets directed to port 21. Since tags and other metadata added by pf are apparently not available to the bpf filter, I don't see any way of distinguishing between control connections from systems behind the firewall that are being handled via ftp-proxy and those originating from the firewall itself. If there's something I'm missing, or if there's a better tool than ftpsesame to use, I'd love to hear about it -- since I'd really like to make FTP 'just work' everywhere. I actually do have one idea about how to handle FTP, but it raises another question for which I can't find an answer. I have a second static IP address available which I could add as an alias on the external interface (I've been planning to use it that way as a secondary MX for spamd) and direct ftp-proxy to use that alias as its source address -- so that ftpsesame could select only those connections from the main address. But I'd need to control which of the two addresses was used for each outbound connection since, while most of the resources I use on the net don't care where a connection comes from, a few do. This isn't a problem for anything behind the firewall (since nat / rdr / binat rules specify the external address) and shouldn't be a problem for incoming connections (since they will use the original destination address as the source address for return traffic), but I can't find any information about what source address is used by default on outgoing connections when one or more aliases are present on the external interface. Is there some way of marking one of the addresses assigned to an interface as preferred, so that programs needing a source address for a new connection on an interface will use it unless told to do otherwise? I may be able to get by with just understanding which alias will be chosen as the source address when a program uses INADDR_ANY, but that doesn't seem to be documented either. I need to know how this is designed to work rather than just how it appears to work at the moment, since a 'solution' which might change when I upgrade (or even just reboot) is not acceptable. Thanks in advance for either direct answers or pointers to relevant bits of documentation that I've missed. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Flexibility of pf rules created by ftp-proxy?
On Mon, 17 Mar 2008, Stuart Henderson wrote: >On 2008-03-17, Dave Anderson <[EMAIL PROTECTED]> wrote: >> I've been working on the pf configuration for my home firewall, >> including setting up ftp-proxy. I've noticed that the command is >> getting cluttered with options to adjust the rules it creates to the >> needs of different pf configurations. > >it would be better to turn this on its head, and handle these in >the anchor definition in pf.conf (i.e. define options which should >be applied to all rules under that anchor: log, tag, queue, label, >rtable, blah blah blah). Upon consideration, I at least partially agree with you (and note that 4.3 is moving in this direction) -- but some things can't be applied to all of the rules in the anchor. I haven't thought it through carefully enough to know whether this is a significant issue but, as a minor example, I like to specify the interface in each rule (possibly overkill for these particular rules, but I'd expect it to at least reduce the total number of rule comparisons) and that will certainly differ from rule to rule (since I have both a DMZ and an internal network). >doing this in ftp-proxy(/tftp-proxy/ftpsesame/pptp-proxy/wherever >else you might want it) would be an inefficient way of handling this >and annoying to keep eveything in-sync. Is this really a problem in practice? I'd think it likely that, since all of these are parsing text into a structure suitable for using in an ioctl on the pf device, they could all use a common procedure to perform that action. (I haven't examined the code, so there could be something which prevents this; if you have examined it and know that there is such a problem, I'll defer to your greater knowledge.) Dave
Re: Flexibility of pf rules created by ftp-proxy?
On Tue, 18 Mar 2008, Camiel Dobbelaar wrote: >Dave Anderson wrote: >> I've been working on the pf configuration for my home firewall, >> including setting up ftp-proxy. I've noticed that the command is >> getting cluttered with options to adjust the rules it creates to the >> needs of different pf configurations. Has any thought been given to >> allowing arbitrary nat, rdr and pass rules to be specified in a >> configuration file (in the same syntax as for pf.conf) with macros >> defined for the server, client and proxy addresses (as in the examples; >> also, perhaps, a few other macros -- such as for the interfaces through >> which the client and server are reachable)? >> >> I'm not asking (let alone demanding) that anyone implement this, but >> would like to know if it's been considered and rejected for some >> reason, is on someone's to-do list, has never been thought about, or >> whatever. It seems to me to be a good way both to avoid needing more >> and more options to tweak the generated rules and to avoid the delay >> involved in modifying the program whenever someone comes up with a new >> need. > >Now that the 'tag' option is available I don't expect ftp-proxy to gain >any more options wrt. to the pf rules it creates, because you can >implement those yourself using 'tagged'. Only if exactly the same thing should be done for all rules in the anchor, since only one tag can be specified. I can't think offhand of any cases where this makes an important difference, but how sure can we be that there are none? >The history behind the current implementation is that I wanted it to be >simple. Having a configuration file with pf rules means that you either >have: >- embed a full parser, which is a lot of code >- run pfctl, which makes it harder to chroot Or tweak the existing code in pfctl so it could be used (perhaps as a library routine) from ftp-proxy and anyplace else that wanted to make similar use of anchors. (I haven't examined the pfctl code, so I realize that this might turn out to be impractical.) >Also, the FTP protocol is complex. Having the nat and rdr rules under >user control would easily break things. Certainly true, for those who use the flexibility. >So it would be a lot of extra code for not much gain. If using the code from pfctl is practical it shouldn't be all that much extra code, and the amount of gain depends on whether someone comes up with a real need for this sort of flexibility (I don't have anything specific to propose at this time). But I might well have made the same decision you did if it had been mine to make. Thanks for the discussion, Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Disable IPv6 on OpenBSD 4.0
** Reply to message from carlopmart <[EMAIL PROTECTED]> on Sun, 17 Dec 2006 17:31:03 +0100 > Somebody knows if exists some option to put on rc.conf file like >FreeBSD does with ipv6_enable="NO" option to disable IPv6 support on >OpenBSD 4.0? Or do I need to recompile kernel, modify sendmail.cf, etc, >etc, etc ...?? In other owrds, do I need to reconfigure all process that >need ipv6 to startup?? Why do you think you need to do this? That is, what problem is the presence of IPv6 support causing you? If you just don't want to deal with the possibility of IPv6 traffic, you could easily configure PF to block all IPv6. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Disable IPv6 on OpenBSD 4.0
** Reply to message from Jason Dixon <[EMAIL PROTECTED]> on Sun, 17 Dec 2006 15:17:01 -0500 >On Dec 17, 2006, at 2:51 PM, carlopmart wrote: > >> Yes, my security staff orders to disable IPv6 protocol on all our >> firewalls ... > >Your security staff is clueless. I bet they like to block icmp echo- >request too. Unfortunately, the fact that they're clueless doesn't make it possible to ignore their demands. Fortunately, it's almost trivial to configure PF to block all incoming and outgoing IPv6 on your external interface (or on all of your interfaces). The question is, can you convince the powers-that-be that doing this is sufficient? It clearly should be, since it prevents any possibility of communicating via IPv6. Good luck, Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: sendmail w/ virtual mailboxes
** Reply to message from Alexander Hall <[EMAIL PROTECTED]> on Mon, 01 Jan 2007 22:07:55 +0100 >Jacob Yocom-Piatt wrote: >> i have been a postfix user for several years and have decided i should learn >> to >> use sendmail. making a very basic setup that has 1 virtual mailbox (i.e. a >> mailbox for a user that does not have shell account on the mailserver) is >> giving >> me grief and i have not been able to fix this issue after reading all the >> docs i >> could find. i fully expect the answer is that i missed something trivial. > >I think you need to have a local user to deliver to if you use this >approach or sendmail would not know where to deliver. We create an >account (with no ssh access etc) for each mail account. > >If not, how is the user supposed to access his/her mail if there is no >account? This depends on your 'local' mail-delivery program definition in sendmail.cf. IIRC the standard program will only deliver to real users. I'm using maildrop (from packages) to allow delivery to virtual users (who access their mail via POP); there are undoubtedly other such programs available. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: weird PF behavior
** Reply to message from Ryan Corder <[EMAIL PROTECTED]> on
Fri, 16 Mar 2007 14:01:38 -0500
>very simply, this thread could have ended a day or two ago if the
>following process would have taken place:
>
>1) is my syntax wrong? YES
>2) OK, what is wrong with it? Pointed out and understood.
Evidently, *not* understood.
>3) Good, now what is the correct syntax?
>
>number 3 is where we sit. I understand that the {} syntax is for text
>expansion. What I don't understand is whether when someone use {}, is
>the list evaluated as a logical AND or a logical OR?
Neither. It does text expansion, as several people have already told
you. *All* it does is transform one rule into several rules;
evaluation is exactly the same as if the original ruleset included the
resulting rules -- there's no AND or OR involved. The *effect* (in
this case) is the same as if the {} construct were evaluated as an OR
within a single rule, but that's not how it's implemented.
Dave
PS: I'm definitely *not* a pf/pfctl expert, but I believe that I do
understand how this bit of it works. If I'm wrong, I'm sure that I'll
be corrected quickly.
--
Dave Anderson
<[EMAIL PROTECTED]>
Re: No Blob without Puffy
** Reply to message from Karel Kulhavy <[EMAIL PROTECTED]> on Mon, 19 Mar 2007 15:04:46 +0100 >On Mon, Mar 19, 2007 at 12:06:31AM +0100, SW wrote: > >I have a feeling that the campaign means "We don't want vendors to require >us to use a blob but we'll ocassionally use them when we have to other way", >while Theo means "I don't want vendors to require us to use a blob and I refuse >to use them even when no other way". > >And that the heated words stem from the subtle difference. Politics instead of >developing. It's the vendors who decide about the blobs and they may or may not >take your complaints into account. Your invested time may or may not return. You've left out the extremely important fact that many vendors interpret acceptance of blobs by any "free" OS as validating their position of not releasing adequate documentation -- so accepting blobs (even when "there's no other choice") actively harms the anti-blob campaign. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: NOOP and Spamd
** Reply to message from Bob Beck <[EMAIL PROTECTED]> on Mon, 19 Mar 2007 09:40:52 -0600 >* Sid Carter <[EMAIL PROTECTED]> [2007-03-19 03:25]: > >> > Regardless, if NOOP is in the SMTP standard, and spamd does not handle >> > it correctly, that is a bug that needs to be fixed. > > Bullshit. that's not a good enough reason - spamd does not >implement all of smtp, and never will. saying "it's in the smtp >standard" is the wrong way to get anything into spamd :) > > OTOH, if there is real stuff from the century of the fruit bat >that uses this I'll put it in. If it's someone's BBS mailer from >the century of Def Leppard and Mullets I'm not bloating the code one line >to deal with it. I've asked the poster for details. Anyone else who >can confirm real stuff needing NOOP please let me know. I certainly don't want to see spamd (or anything else) made overcomplicated by "somebody might need that" code, but wouldn't it make sense to include anything which is both in the standards and truly trivial to implement sufficiently for spamd's purposes? It seems to me that in those cases the cost to implement and maintain is so low as to be worthwhile even if it only avoids relatively unlikely problems. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: OT Strange Punishment
On Tue, 28 Aug 2007, Lars Hansson wrote: >On 8/28/07, Die Gestalt <[EMAIL PROTECTED]> wrote: >> Why doesn't he run the monitoring software in a virtual machine? > >Because it would violate his parole? Who cares anyway? >If you can't do the time don't do the crime. We should all care, because there's actually an important question buried in this: to what extent is it acceptable for 'the government' to demand that someone make substantial or expensive changes in their life merely for its convenience? Note that he isn't complaining about being required to run monitoring software, just about being required to run Windows rather than his accustomed OS (presumably because Windows is the only OS that the government's preferred monitoring software will run on). Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: OT Strange Punishment
On Tue, 28 Aug 2007, Gilles Chehade wrote: >On Tue, Aug 28, 2007 at 11:19:40AM -0400, Dave Anderson wrote: >> On Tue, 28 Aug 2007, Lars Hansson wrote: >> >> >On 8/28/07, Die Gestalt <[EMAIL PROTECTED]> wrote: >> >> Why doesn't he run the monitoring software in a virtual machine? >> > >> >Because it would violate his parole? Who cares anyway? >> >If you can't do the time don't do the crime. >> >> We should all care, because there's actually an important question >> buried in this: to what extent is it acceptable for 'the government' to >> demand that someone make substantial or expensive changes in their life >> merely for its convenience? > >It is acceptable to the extent that the guy did something illegal, is >being punished for it and should consider himself happy that he is >allowed to use a computer still. > >If he were using his ubuntu in a constructive way, he would not be >forced to run Windows today. Tough luck. But, as I understand the issue, this is _not_ part of his specified punishment -- it's just a side-effect of the manner in which the government wants to impose a portion of his punishment. There appears to be no real reason for it other than the government's convenience. You appear to be arguing that someone convicted of a crime should lose rights under the law beyond those which the law specifies as being taken away. Is this a correct inference? Whether or not you hold that opinion, I certainly don't agree with it -- it's essentially encouraging vigilanteeism. Anyone who thinks that the penalties specified by law don't go far enough should work to change the law, not just ignore it. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: OT Strange Punishment
On Tue, 28 Aug 2007, Emilio Perea wrote: >On Tue, Aug 28, 2007 at 12:49:56PM -0400, Dave Anderson wrote: >> But, as I understand the issue, this is _not_ part of his specified >> punishment -- it's just a side-effect of the manner in which the >> government wants to impose a portion of his punishment. There appears >> to be no real reason for it other than the government's convenience. > >As I understand the issue, he agreed to have the goverment monitor all >his computer activity. This requires that he run an operating system >that will allow that. Does Ubuntu? I guess it's possible, and in that >case it would be reasonable to request that the goverment monitor his >current OS. Otherwise he needs to change OS or go back to jail. Wasn't >that what he agreed to? > >I'm sorry to say that I suspect him to have known all the time that his >parole officer would not be able to monitor his current system, and >therefore had no intention to keep his side of the bargain. You may be right; all the information I have is what's shown up in this thread, and I've no idea whether anyone has implemented suitable monitoring software for Linux (or exactly how the 'monitoring' requirement was arrived at). But this incident does raise the question of what sort of presumably unintended costs 'the government' should be allowed to impose on _anyone_ at its whim -- and _that_ issue is one which should interest all of us (lest we find ourselves at its sharp end). Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Scaling DNS with CARP + pf (+ hoststated ?)
On Tue, 28 Aug 2007, reje wrote: >On the other side, I really need to introduce >_additional_ availability of DNS servers/resolvers. >This is especially true for resolvers as they are the >first layer users are facing. Assume the situation >when ordinary Windows user tries to access a web page >not yet cached in his box local DNS cache. From my >experience, it's needed up to 15 seconds for Windows >box to contact the other resolver. And that is >something I'm trying to avoid by using >high-availability and load-balancing. > >As already seen, it cannot be done (yet) using >hoststated or "rdr" alone because packet payload >inspection and modification is needed for it to work, >and it is a hack, etc.etc. > >I was also reading about new features of IP-based >load-balancing in carp(4) in the upcoming release of >OpenBSD (4.2). It seems that it would be enough to >install a farm of OpenBSD resolver boxes with CARP and >IP load balancing enabled on the boxes themselves. No >external load-balancing boxes, no packet modifications >required. Altough, it seems that it does require some >extra configuring depending on network equipment being >used. Also, IP load-balancing imposses additional load >to network equipment. (I'm dealing with Cisco Catalyst >6500 series switches) > >To conclude my goals: >- remove 15 second timeout for end users, I'm not a DNS guru, nor do I play one on the 'net, but it seems to me that if you're routinely taking 15 seconds to get a response to a DNS query, something is broken! >- deal with only 2 resolver addresses, >- use more than 2 resolver boxes. Am I correct in inferring that the problem here is that the Windows boxes can't handle more than 2 resolver addresses? If so, and if they're getting their DNS-server information via DHCP, it might be much easier and almost as effective to hack the DHCP server to have a large pool of DNS-server addresses and randomly(?) select two of them to provide in each response it sends. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: OT Strange Punishment
On Wed, 29 Aug 2007, Lars Hansson wrote: >> But, as I understand the issue, this is _not_ part of his specified >> punishment -- it's just a side-effect of the manner in which the >> government wants to impose a portion of his punishment. > >If he don't like it he could always take the alternative; going to jail. >All things considered, being forced to run Windows for a few months >isn't all that big a sacrifice when the alternative is sharing cell >with Bubba. > >> You appear to be arguing that someone convicted of a crime should lose >> rights under the law beyond those which the law specifies as being taken >> away. Is this a correct inference? > >I don't think think running Linux is a basic human right. This looks remarkably like a "yes" answer to my question. We've gotten pretty far off-topic, so I'm going to stop polluting this list. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: That whole "Linux stealing our code" thing
On Sun, 2 Sep 2007, Hannah Schroeter wrote: >On Sat, Sep 01, 2007 at 02:25:49PM -0600, Theo de Raadt wrote: >>[...] > >>Bullshit. The license retains ANY RIGHTS which are in Copyright law, >>a body of law that PRECEDES the decleration. That body of law is >>pulled in the MOMENT a "Copyright (c) YYMM author" decleration is >>made. > >In some legislations, especially in Europe, copyright law applies >*automatically*, even without an explicit copyright statement/assertion. >Just by creating something that's copyrightable. IIRC this is true for any country which has adopted the Berne Convention, which is currently almost every country which has any copyright law in place. It includes the U.S. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: That whole "Linux stealing our code" thing
On Sun, 2 Sep 2007, Rui Miguel Silva Seabra wrote:
>Haha, show me proof. Where does it say so? Come on, don't hide behind
>assumptions. Where it the text below does it say so? Don't give me any
>interpretation blablabla, just put some ^^^ underneath the words...
>
> * Copyright (c) 2007 Jiri Slaby <[EMAIL PROTECTED]>
> * All rights reserved.
> *
> * Redistribution and use in source and binary forms, with or without
> * modification, are permitted provided that the following conditions
> * are met:
> * 1. Redistributions of source code must retain the above copyright
> *notice, this list of conditions and the following disclaimer,
> *without modification.
> * 2. Redistributions in binary form must reproduce at minimum a disclaimer
> *similar to the "NO WARRANTY" disclaimer below ("Disclaimer") and any
> *redistribution must be conditioned upon including a substantially
> *similar Disclaimer requirement for further binary redistribution.
> * 3. Neither the names of the above-listed copyright holders nor the names
> *of any contributors may be used to endorse or promote products derived
> *from this software without specific prior written permission.
> *
> * Alternatively, this software may be distributed under the terms of the
> * GNU General Public License ("GPL") version 2 as published by the Free
> * Software Foundation.
The basis of your argument appears to be that you interpret the last
paragraph above (starting with "Alternatively") as explicit permission
to replace all of the previous material (starting with "Redistribution
and use") with the GPLv2. Is this inference correct?
IANAL, so I'm not going to speculate on the correct legal interpretation
of this text; I will grant that, if it were ordinary speech, I can see
how someone who tried hard enough could believe that interpretation.
However, in the case that started this discussion, the original author's
intent has, IIRC, been clearly and authoritatively stated to exclude
that interpretation -- so anyone who is aware of this yet still changes
the license text in this case is, at the very least, behaving
unethically.
Dave
--
Dave Anderson
<[EMAIL PROTECTED]>
Re: SMTP flood + spamdb
On Wed, 26 Sep 2007, Liviu Daia wrote: >On 26 September 2007, Craig Skinner <[EMAIL PROTECTED]> wrote: >> Liviu Daia wrote: >> > >> > How does spamd distinguish between a legitimate retry and a >> > re-injection of the same message with the same Message-Id, sender >> > etc.? >> >> It doesn't. >> >> Just what you described would probably be within the default 25 mins >> grey period. > >Why should it? The second copy is sent in a separate run, that's >the whole point. The only thing the bot has to figure out is how long >to wait until the second run. A smart one would send a second copy >after 10 minutes, and a third one after, say, 35 minutes. > >> Another delivery attempt would be needed after this time to pass >> spamd. > >Moral: randomize the greylisting time... Or take advantage of the (by default) 25 minute window to use other means to detect that this address is sending spam. Perhaps spamd should be extended to look for excessive attempts to send messages from an address during that period? (How often do spammers' lists contain only one or two addresses from a domain?) Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Difficult routing problem
On Sat, 6 Oct 2007, Layne Evans wrote: >Hello all, > >I am having some trouble with a routing situation that is difficult for >me to explain, so if you need more info let me know. > >vendor -->vendor router<-- Internal LAN Location A -->OBSD GW A<-- Internet > VPN Between >Internet -->OBSD GW B<-- Internal LAN Location B > > From the above I will try and describe the situation. A vendor has a >private T1 that terminates through NAT to the customers Internal LAN at >location A, the IP addresses that this vendor is using are part of there >public IP space but they are not routable over the Internet just through >the T1. I have a OpenBSD box at that location that provides internet >access and routes the block of IPs belonging to the vendor to the >vendor's router. > >There is a VPN between the OpenBSD boxes at both locations which is >performing fine and I can contact both internal LANs from the other. > >The problem that I have not been able to solve is that the workstations >at location B need to get to the vendor's router at location A using the >public IPs of the vendor. I have tried using route-to in pf and some >ideas I had in the routing table, but so far nothing has routed the >packets over the VPN. I am sure I am missing something basic, but so far >I have not been able to see it. > >Some info: (these are representative IPs) >Vendor's IP block that need to go over their T1: 207.12.0.0/18 >Internal LAN A: 10.74.10.0/24 >Vendor router Internal LAN IP: 10.74.10.245 >OpenBSD A Internal IP: 10.74.10.254 >OpenBSD A External IP: a.b.c.d >OpenBSD B Internal IP: 10.76.10.254 >OpenBSD B External IP: w.x.y.z > >Any pointers will sure be appreciated. Maybe I'm missing something, but (given that everything else is working and assuming that the systems on LAN B have a default route directed to GW B) wouldn't a static route on GW B for 207.12.0.0/18 pointing to 10.74.10.245 do the job? Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: [side thread] security implcations of multiple kernel threads?
On Tue, 9 Oct 2007, Douglas A. Tutty wrote: >On Tue, Oct 09, 2007 at 08:03:18PM +0200, Henning Brauer wrote: >> * Florin Andrei <[EMAIL PROTECTED]> [2007-10-09 19:34]: >> >> next, you don't want SMP for such tasks. take out the second CPU and give >> >> it to somebody who can use it, and run the uniprocessor kernel. >> > So, assuming the box is a pure firewall / static router (so just pf and >> > static routes), even with multiple interfaces, all those tasks run in a >> > single kernel thread? >> >> yup > >Why is this? Is there a security reason why the kernel is >single-thread; is it OBSD resource limitations (no developer time, no >hardware, etc); is it not enough interest yet? I'm not an OpenBSD developer, but I'd bet that the reason is that BSD was originally written single-threaded (both because that's much easier than multi-threaded and because multi-cpy systems were rare back then) and has not [yet] been changed because changing to a multi-threaded kernel requires a lot of very finicky work (with innumerable opportunities to introduce very subtle bugs). Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: named on udp ports only
** Reply to message from "Constantine A. Murenin" <[EMAIL PROTECTED]> on Tue, 20 Jun 2006 16:07:25 +0100 >Hello, > >I'm running an sshd on port 53 (domain) as there is some convenient >wireless hot-spot that allows for both udp and tcp connection on this >port without any authentication. :) > >(Yes, there is not even a need for NSTX!) > >How do I tell my named(8) to only listen on udp ports, and leave tcp >ports for sshd(8)? Is this at all possible with named.conf alone? I've >glanced through named.conf(5), but didn't find the desired option >there... If you look at the RFCs defining DNS you'll quickly discover that TCP access is *required* for all servers. While it's mostly used for zone transfers, *any* request whose answer is too large to fit in a single UDP packet must be retried via TCP. In other words, it's not possible to do what you want. (It can *appear* to work, but you'll have obscure problems where some requests quietly fail for no obvious reason.) Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: dns query
** Reply to message from riwanlky <[EMAIL PROTECTED]> on Mon, 07 Aug 2006 14:58:52 +0700 >I don't know if it is the right place to write about this problem. >I am running OpenBSD 3.9, however it seem to me that my OpenBSD >box always send a DNS query for: >- email sending (from internal and external) I had tried to add in my >resolv.conf to use nameserver localhost. So that @mcojaya.com >will not go to other DNS server for query. I use /etc/hosts to add >127.0.0.1 mcojaya.com >I have problem that when the internet is down, my local users were >not able to send email because of DNS query check. >- nagios. I use check_ping, and it seem that it will always query >DNS for every ip address (host) that I setup to check_ping. > >I did not modify any inetd.conf Sending email requires more than just an IP address. When sending a message to @, the mailer first checks where it should be sent by looking for an 'MX' (Mail eXchanger) record for -- and 'MX' records can only be suppied via DNS. The typical setup is something like: domain.example IN MX 10,mail-server.domain.example mail-server.domain.example IN A192.168.13.57 So if you want this to work when your internet connection is down you need to either set up your own DNS server (it's not all that hard, but is certainly not trivial) or find a mailer (if one exists) that does some special hackery to avoid DNS queries for locally-addressed messages. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Is it possible that source spoof IP bypass the three step handshake of the TCP connection to apache in an attack?
** Reply to message from Daniel Ouellet <[EMAIL PROTECTED]> on Wed, 23 Aug 2006 22:05:53 -0400 >In my database right now I am up to 5241 IP's starting at 2PM today only. > >I sure can publish it as it's fair game. > >But what's interesting to me is the signature. > >If I follow this idea, then every single compromise computers in my list >have to be Windows, all with the same service pack, browser, etc. >Obviously if all the same then all have the same bug and can be >compromise the same way. But still. You seem to be assuming that whatever malware is involved is using the software installed on the hijacked computer. More likely, it is opening a connection to your web server itself and sending whatever request and supplementary information it wants (which is the same in all cases, since it's the same malware). Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Missing section in FAQ - 6 Networking ?
** Reply to message from Nick Holland <[EMAIL PROTECTED]> on Sun, 03 Sep 2006 11:40:27 -0400 >Bruno Carnazzi wrote: > >> There is a numbering problem or a missing section in FAQ - 6 >> Networking : http://www.openbsd.org/faq/faq6.html#6.8 > >Not quite sure how that's a problem. > >Things get added and removed. > >I have an aversion to renumbering articles excessively... Even though >one of the early things I did in the FAQ was breaking the tie between >section numbers and links, I still tend to think of articles by the >section number...as apparently you do, as well. Have you considered having a vestigal section (something like '6.8: [removed]') to make it obvious that there's no error with very little extra work on your part? Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: DNS confusion about www.oorexx.org
On Thu, 2 Oct 2008, Jack Woehr wrote: >My DNS server is OpenBSD 4.3 and I'm running the default bind. > >The website http://www.oorexx.org 9 times out of ten does not resolve >for me. > >I'm asking "why does it itermittently resolve" not because I suspect an >OpenBSD problem (I don't) but because people on this list understand >this stuff well. > >The ObjectRexx team keeps insisting everything is fine, but I've >followed the WHOIS down to the ISP and the name server they give and >tried nslookup against it rather than against my local server and the >same result. > >The ORexx team insists I'm out of my mind (which may be true, albeit >irrelevant). > >Can anyone please explain to me what's going on? Something here is very strange: $ dig @bos.speakeasy.net oorexx.org ns ; <<>> DiG 9.3.0 <<>> @bos.speakeasy.net oorexx.org ns ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16593 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;oorexx.org.IN NS ;; ANSWER SECTION: oorexx.org. 2560IN NS ns1.planetdomain.com. oorexx.org. 2560IN NS ns2.planetdomain.com. ;; Query time: 298 msec ;; SERVER: 66.92.64.2#53(bos.speakeasy.net) ;; WHEN: Thu Oct 2 13:38:45 2008 ;; MSG SIZE rcvd: 80 $ dig @ns1.planetdomain.com www.oorexx.org a ; <<>> DiG 9.3.0 <<>> @ns1.planetdomain.com www.oorexx.org a ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42548 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.oorexx.org.IN A ;; ANSWER SECTION: www.oorexx.org. 86400 IN A 208.34.240.200 ;; Query time: 281 msec ;; SERVER: 202.131.95.2#53(ns1.planetdomain.com) ;; WHEN: Thu Oct 2 13:39:34 2008 ;; MSG SIZE rcvd: 48 $ dig @ns1.planetdomain.com www.oorexx.org ns ;; Warning: Message parser reports malformed message packet. ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.3.0 <<>> @ns1.planetdomain.com www.oorexx.org ns ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17790 ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.oorexx.org.IN NS ;; ANSWER SECTION: www.oorexx.org. 86400 IN CNAME 208.34.240.200. ;; AUTHORITY SECTION: oorexx.org. 2560IN SOA ns1.planetdomain.com. hostmaster.planetdomain.com. 2007042001 10800 3600 604800 3600 ;; Query time: 741 msec ;; SERVER: 202.131.95.2#53(ns1.planetdomain.com) ;; WHEN: Thu Oct 2 13:40:08 2008 ;; MSG SIZE rcvd: 127 $ dig @ns1.planetdomain.com www.oorexx.org any ; <<>> DiG 9.3.0 <<>> @ns1.planetdomain.com www.oorexx.org any ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3496 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.oorexx.org.IN ANY ;; ANSWER SECTION: www.oorexx.org. 86400 IN A 208.34.240.200 ;; Query time: 289 msec ;; SERVER: 202.131.95.2#53(ns1.planetdomain.com) ;; WHEN: Thu Oct 2 13:42:44 2008 ;; MSG SIZE rcvd: 48 Where did that CNAME come from, why does it have what looks like an IPv4 address as its value (rather than an FQDN, as is IIRC required), and why doesn't it show up when we request all information? Dave -- Dave Anderson <[EMAIL PROTECTED]>
4.4 arriving in the U.S.
Today's mail delivered the 4.4 CDs near Boston, Mass. Many thanks to the developers, Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Packet Filter: how to keep device names on hardware failure?
On Fri, 7 Nov 2008, Harald Dunkel wrote: >Peter N. M. Hansteen wrote: >> Harald Dunkel <[EMAIL PROTECTED]> writes: >> >>> Sorry to wake this thread up again, but this problem is a severe >>> security risk. IMHO it is unacceptable that a hardware failure on >>> one NIC of a firewall can put the whole network at risk, just because >>> the mapping between NICs and interface names gets mixed up, and PF >>> suddenly treats the Internet as a subnet of the company LAN. >> >> Semi-random reordering of network interfaces would be a severe >> problem, no doubt. However, my hazy memory was that reordering would >> not occur as you describe, but ICBW, please correct me if this has >> actually been demonstrated to happen. > >I can post 2 dmesg logs of the same machine with the NIC >names mixed up. Somehow 2 NICs disappeared on a reboot. On >the next reboot they were back. Attached is the diff. > >In the bad configuration the NIC with 00:30:48:d2:9a:06 is >called "em2", in the good one it is called "em4". Maybe you >can imagine how PF screws up, if this NIC would have been >physically connected to the Internet. > >Surely it is unusual that a NIC "disappears" somehow. Maybe >there is something wrong with my hardware, but this can always >happen. I would like to have a secure setup even if there is a >hardware failure. Network configuration has bugged me a bit ever since I started using OpenBSD, not just the real security issue that Harald Dunkel points out but general ease of administration issues. For example, on a typical single-NIC system one ought to be able to set up a standard configuration and not care which make/model of NIC is installed. Perhaps most of these issues could be dealt with by changing the network configuration procedure to have a hierarchy of interface-configuration files rather than just hostname.. If hostname. were used if the hardware MAC matches, then hostname., then (say) hostname.only if there's only one NIC found, the sysadmin could assign interfaces to groups and use those group names everywhere, and so not need to use the actual interface names at all. This appears to be a fairly simple change. Does it sound reasonable to people with more knowledge of OpenBSD networking? Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Packet Filter: how to keep device names on hardware failure?
On Fri, 7 Nov 2008, Ted Unangst wrote: >On Fri, Nov 7, 2008 at 12:44 PM, Dave Anderson <[EMAIL PROTECTED]> wrote: >> Network configuration has bugged me a bit ever since I started using >> OpenBSD, not just the real security issue that Harald Dunkel points out >> but general ease of administration issues. For example, on a typical >> single-NIC system one ought to be able to set up a standard >> configuration and not care which make/model of NIC is installed. > >This is where "pound enter until done" in the installer just works. True if you're installing; I _like_ the OpenBSD installation procedure. But it doesn't help if you replace a NIC in an already-built system with a different make/model or need to move one to a different slot. Do note that I consider the single-NIC ease-of-use issue to be a minor one; it just came up as fallout from thinking about the more-important unexpected-name-change issue. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Packet Filter: how to keep device names on hardware failure?
On Fri, 7 Nov 2008, Theo de Raadt wrote: >> >Peter N. M. Hansteen wrote: >> >> Harald Dunkel <[EMAIL PROTECTED]> writes: >> >> >> >>> Sorry to wake this thread up again, but this problem is a severe >> >>> security risk. IMHO it is unacceptable that a hardware failure on >> >>> one NIC of a firewall can put the whole network at risk, just because >> >>> the mapping between NICs and interface names gets mixed up, and PF >> >>> suddenly treats the Internet as a subnet of the company LAN. >> >> >> >> Semi-random reordering of network interfaces would be a severe >> >> problem, no doubt. However, my hazy memory was that reordering would >> >> not occur as you describe, but ICBW, please correct me if this has >> >> actually been demonstrated to happen. >> > >> >I can post 2 dmesg logs of the same machine with the NIC >> >names mixed up. Somehow 2 NICs disappeared on a reboot. On >> >the next reboot they were back. Attached is the diff. >> > >> >In the bad configuration the NIC with 00:30:48:d2:9a:06 is >> >called "em2", in the good one it is called "em4". Maybe you >> >can imagine how PF screws up, if this NIC would have been >> >physically connected to the Internet. >> > >> >Surely it is unusual that a NIC "disappears" somehow. Maybe >> >there is something wrong with my hardware, but this can always >> >happen. I would like to have a secure setup even if there is a >> >hardware failure. >> >> Network configuration has bugged me a bit ever since I started using >> OpenBSD, not just the real security issue that Harald Dunkel points out >> but general ease of administration issues. For example, on a typical >> single-NIC system one ought to be able to set up a standard >> configuration and not care which make/model of NIC is installed. > >You are joking right? In that case you use the "egress" interface >group. It works perfectly on all machines with one network interface, >and follows the default route. Maybe I'm just confused, but my recollection is that one needs to set up the appropriate hostname. to enable the interface before the "egress" interface group works. This single-NIC case is admittedly a minor one, but it would eliminate one of the few (that I can think of) things about running a basic OpenBSD system that requires any "arcane" setup. >Or would you rather use eth0? Since I never mentioned eth0, the answer is pretty obviously "no". >> Perhaps most of these issues could be dealt with by changing the network >> configuration procedure to have a hierarchy of interface-configuration >> files rather than just hostname.. > >Oh, like eth0 and eth1 and eth2? See above. >> If hostname. >> were used if the hardware MAC matches, then hostname., >> then (say) hostname.only if there's only one NIC found, the sysadmin >> could assign interfaces to groups and use those group names everywhere, >> and so not need to use the actual interface names at all. > >So right now you have hardware that is disappearing. What happens when >you get hardware where the MAC reading is not 100% reliable. New problem, >and a new solution? Actually, it's other people who have the problem. I was just speculating on how to minimize its harmful effects. One can always postulate a hardware (or other) failure which can't be dealt with by whatever the current software may be; the question is whether it happens often enough and is serious enough to be worth doing something about. Or if it suggests a change which is worthwhile in itself and also solves the problem. >> This appears to be a fairly simple change. Does it sound reasonable to >> people with more knowledge of OpenBSD networking? > >No, it is not reasonble. You are inventing problems at a very high >level just because some very low level pci-related bug is making some >of your devices not reliably show themselves. No, I'm thinking about a general way for those people who care about it to tie pf rules, etc, to specific physical interfaces, regardless of what other devices are installed or configured in a system. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Packet Filter: how to keep device names on hardware failure?
On Fri, 7 Nov 2008, Chris Kuethe wrote: >On Fri, Nov 7, 2008 at 3:55 PM, Dave Anderson <[EMAIL PROTECTED]> wrote: >> Maybe I'm just confused, but my recollection is that one needs to set up >> the appropriate hostname. to enable the interface before >> the "egress" interface group works. >> ... > >haven't tried this, but maybe you can use the "add" command in ukc / >config to create the constant device mappings you expect... maybe. I'm not "expecting" anything, just thinking about how to better handle those cases where it's important that pf rules, etc, operate on a specific physical interface (regardless of what other devices are installed or configured in the system). I've never yet had occasion to tinker with config/ukc, but in looking at its manpage and experimenting with it a bit I don't see any obvious way of specifying a particular physical device regardless of what slot it's in -- so I don't think this could accomplish what I'm looking to do. What's needed is a unique identifier for each physical device and a way to key off of it; for ethernet and fiber NICs, at least, the hardware MAC address is the only obvious candidate for such an ID. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Packet Filter: how to keep device names on hardware failure?
On Fri, 7 Nov 2008, johan beisser wrote: >On Nov 7, 2008, at 9:44 AM, Dave Anderson wrote: >> >> Perhaps most of these issues could be dealt with by changing the >> network >> configuration procedure to have a hierarchy of interface-configuration >> files rather than just hostname.. If hostname. >> were used if the hardware MAC matches, then hostname., >> then (say) hostname.only if there's only one NIC found, the sysadmin >> could assign interfaces to groups and use those group names >> everywhere, >> and so not need to use the actual interface names at all. >> This appears to be a fairly simple change. Does it sound reasonable >> to >> people with more knowledge of OpenBSD networking? > >It's not a simple change. Having now looked at /etc/netstart, it's clearly not as simple as I'd hoped -- but it doesn't look all that difficult. The only issue I don't (yet) see a solution for is how to get the original hardware MAC address for an interface (rather than the current MAC address, which appears to be what ifconfig reports). I could parse the dmesg from the most recent boot, but that feels wrong -- especially since I'm not certain that that information will always be available, complete and unaltered. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: /dev/random as (chrooted) named's entropy source [current]
On Thu, 3 Apr 2008, Jan Stary wrote: >Trying to give named its own random-source, I stopped named, did > ># cd /var/named/dev/ ># /dev/MAKEDEV arandom ># ls -l >total 0 >crw-r--r-- 1 root wheel 45, 4 Apr 3 14:16 arandom >srw-rw-rw- 1 root wheel 0 Apr 3 13:51 log >crw-r--r-- 1 root wheel 45, 3 Apr 3 14:16 prandom >crw-r--r-- 1 root wheel 45, 0 Apr 3 14:16 random >crw-r--r-- 1 root wheel 45, 1 Apr 3 14:16 srandom >crw-r--r-- 1 root wheel 45, 2 Apr 3 14:16 urandom > >and started named again. Now the log says > >named[25688]: /usr/src/usr.sbin/bind/lib/isc/unix/errno2result.c:111: >unexpected error: >named[25688]: unable to convert errno to isc_result: 6: Device not configured >named[25688]: could not open entropy source /dev/arandom: unexpected error >named[25688]: using pre-chroot entropy source /dev/arandom > >So why is /var/named/dev/arandom "not configured". Is there something >that needs to be done beside MAKEDEV? Is /var marked 'nodev' in /etc/fstab? Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Got 'em
The 4.3 CD set arrived today near Boston, Mass. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Kernel trap with custom ramdisk
On Tue, 29 Apr 2008, B A wrote: >> You tried building a custom ramdisk and then came to misc asking >> for help despite the archives are full of detailed instructions telling >> you NOT TO DO THAT. > >This is the funniest reason I ever hear. >So if something dosn't work, do not do that. >Nice :-) OpenBSD comes with excellent documentation, and the developers (and just about everyone else here) expect you to read the relevant parts before posting here. If you've read the FAQ, you have no excuse for not knowing that (unlike, e.g., Linux) OpenBSD is an integrated system with its options and configuration chosen by the developers to work well together in essentially all cases, so tinkering is not supported -- if you go there, you're on your own. Because of this, questions like yours are taken as an indication that you haven't done your homework and are trying to get other people to do it for you. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Kernel trap with custom ramdisk
On Tue, 29 Apr 2008, B A wrote: >Surely I have read FAQ, >especially '5 - Building the System from Source' >but there is no section about building custom ramdisk. >Probably one should be included, so you see less *dumb* >questions about it. Obviously people need to build them >for many reasons, like completely in RAM internet kiosk >and so on. You appear to have missed FAQ section 5.6: 5.6 - Why do I need a custom kernel? Actually, you probably don't. A custom kernel is a kernel built with a configuration file other than the provided GENERIC configuration file. A custom kernel can be based on -release, -stable or -current code, just as a GENERIC kernel can be. While compiling your own GENERIC kernel is supported by the OpenBSD team, compiling your own custom kernel is not. The standard OpenBSD kernel configuration (GENERIC) is designed to be suitable for most people. More people have broken their system by trying to tweak their kernel than have improved system operation. There are some people that believe that you must customize your kernel and system for optimum performance, but this is not true for OpenBSD. Only the most advanced and knowledgeable users with the most demanding applications need to worry about a customized kernel or system. Some reasons you might want or need to build a custom kernel: * You really know what you are doing, and want to shoe-horn OpenBSD onto a computer with a small amount of RAM by removing device drivers you don't need. * You really know what you are doing, and wish to remove default options or add options which may not have been enabled by default (and have good reason to do so). * You really know what you are doing, and wish to enable experimental options. * You really know what you are doing, and have a special need that is not met by GENERIC, and aren't going to ask why it doesn't work if something goes wrong. Some reasons why you should not build a custom kernel: * You do not need to, normally. * You will not get a faster system. * You are likely to make a less reliable machine. * You will not get any support from developers. * You will be expected to reproduce any problem with a GENERIC kernel before developers take any problem report seriously. * Users and developers will laugh at you when you break your system. * Custom compiler options usually do a better job of exposing compiler problems than improving system performance. Removing device drivers may speed the boot process on your system, but can complicate recovery should you have a hardware problem, and is very often done wrong. Removing device drivers will not make your system run faster by any noticeable amount, though can produce a smaller kernel. Removing debugging and error checking can result in a measurable performance gain, but will make it impossible to troubleshoot a system if something goes wrong. Again, developers will usually ignore bug reports dealing with custom kernels, unless the problem can be reproduced in a GENERIC kernel as well. You have been warned. Dave >29.04.08, 19:13, "Dave Anderson" <[EMAIL PROTECTED]>: > >> OpenBSD comes with excellent documentation, and the developers (and just >> about everyone else here) expect you to read the relevant parts before >> posting here. If you've read the FAQ, you have no excuse for not >> knowing that (unlike, e.g., Linux) OpenBSD is an integrated system with >> its options and configuration chosen by the developers to work well >> together in essentially all cases, so tinkering is not supported -- if >> you go there, you're on your own. Because of this, questions like yours >> are taken as an indication that you haven't done your homework and are >> trying to get other people to do it for you. -- Dave Anderson <[EMAIL PROTECTED]>
Re: Decipering "Understanding IP addressing"
On Wed, 21 May 2008, Kendall Shaw wrote: >In the networking section of the OpenBSD FAQ it suggests reading >"Understanding IP addressing": > >http://www.3com.com/other/pdfs/infra/corpinfo/en_US/501302.pdf > >I'm having a hard time understanding it. In many places they use 2 >numbers, e.g. 2(21) or 232 (4,294,967,296). Can you understand what they >are saying? > >For example, on page 3: > >"IPv4 defines a 32-bit address which means that there are >only 232 (4,294,967,296) IPv4 addresses available." > >232 what? > >On page 11: > >"The first step in the planning process is to take the maximum number of >subnets required and round up to the nearest power of two. For example, >if an organization needs nine subnets, 23 (or 8) will not provide >enough subnet addressing space, so the network administrator will >need to round up to 24 (or 16)." > >23 or 8 what? Bits? What are 23 and 8 alternatives of? 24 or 16 looks >like alternative prefix lengths for class A or B networks, but I don't >get 23 or 8. Somewhere along the line the exponentiation operator (^) has been dropped from the text. 232 should be 2^32, 23 should be 2^3, 24 should be 2^4, etc. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: Zeroconf / Howl Problems.
On Mon, 9 Jun 2008, Jeremy Karlson wrote: >Has anyone had any success setting up Howl (Zeroconf) on OpenBSD 4.3. >I've done a lot of Googling and read the (minimal) docs, but I can't get >it working. I'm unable to determine if I'm doing something incorrectly, >or if it is a problem with Howl, or something else. I'm looking for >suggestions on where to start. IIRC, multicast processing must be explicitly enabled. Have you done that? Dave >Background: Fresh install of OpenBSD 4.3 i386 within the last couple of >days. All software is installed from packages. I'm using a Linksys >EG1032v3 network card with the RE driver. Starting Howl in debug mode >seems to indicate that it's sending the multicast packets to somewhere I >can't explain - 224.0.0.251. > ># ifconfig re0 >re0: flags=8843 mtu 1500 >lladdr 00:14:bf:54:f7:df >groups: egress >media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) >status: active >inet6 fe80::214:bfff:fe54:f7df%re0 prefixlen 64 scopeid 0x1 >inet 192.168.2.11 netmask 0xff00 broadcast 192.168.2.255 > ># cat /etc/mDNSResponder.conf >Galactica _ssh._tcp local. 22 > ># mDNSResponder -d -f /etc/mDNSResponder.conf >[howl] registered interface 192.168.2.11 (23126) >[howl] starting up... (23126) >[howl] registered Galactica (23126) >[assert] error: 64 (Host is down) >[assert] where: "socket.c", "sw_socket_udp_really_sendto", line: 969 >[howl] error sending packet to 224.0.0.251 (23126) >[assert] error: 64 (Host is down) >[assert] where: "socket.c", "sw_socket_udp_really_sendto", line: 969 >[howl] error sending packet to 224.0.0.251 (23126) >[assert] error: 64 (Host is down) >[assert] where: "socket.c", "sw_socket_udp_really_sendto", line: 969 >... > >Thanks. > >-- Jeremy > -- Dave Anderson <[EMAIL PROTECTED]>
Re: UPDATE: mozilla-firefox-3.0
On Thu, 17 Jul 2008, Marco Peereboom wrote: >On Thu, Jul 17, 2008 at 09:47:31AM -0400, Daniel Barowy wrote: >> On Wed, 16 Jul 2008, Marco Peereboom wrote: >>> Somehow the word Java comes to mind... >>> >>> Tell me again how that one runtime meme worked for them again. >> >> Are you saying that Java is not being used widely? All of the fundamental >> courses in my CS department are taught using Java, and I don't think my >> department is an exception. Seems like a home run to me-- I'm sure that >> Sun considers Java a great success. > >I am saying that each java app requires its own java runtime because the >previous/next version is incompatible. Nothing new here. Interesting! In my (admittedly limited) experience, software built with an older version of Java nearly always runs just fine with a later version of the Java runtime. The only exceptions I'm aware of involve one of the rare and well publicized API changes in the class libraries or Microsoft's pseudo-Java, which was deliberately incompatible (in violation of the Java licence) as a marketing move. Dave -- Dave Anderson <[EMAIL PROTECTED]>
No DMA? What's going on here?
If I'm reading it correctly, this bit of the dmesg says that my hard
drive is not using DMA -- and so is running very inefficiently:
wdc0 at isa0 port 0x1f0/8 irq 14
wd0 at wdc0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 9765MB, 1728 sectors
wd0(wdc0:0:0): using BIOS timings
This isn't a big deal, since the system (a light-duty home firewall
built from old junk I had lying around) can handle the presented load
despite this issue -- but I'd like to understand what's happening.
AFAIK all of the hardware involved is DMA-capable. The system is a
Dell Dimension P90 (model XPSP90MT, service ID 463HN) with a larger
disk swapped in; one additional glitch is that the BIOS apparently
doesn't believe in disks this large, resulting in a delay at boot time
(the root partition is at the beginning of the disk, within the area
that the BIOS does understand). [Pointers to] any information on how
to figure out what's really happening would be appreciated.
Thanks,
Dave
The full dmesg is:
OpenBSD 3.7 (GENERIC) #50: Sun Mar 20 00:01:57 MST 2005
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium (P54C) ("GenuineIntel" 586-class) 88 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8
cpu0: F00F bug workaround installed
real mem = 83468288 (81512K)
avail mem = 68882432 (67268K)
using 1044 buffers containing 4276224 bytes (4176K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 09/08/95, BIOS32 rev. 0 @
0xfd8f0
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI BIOS has 4 Interrupt Routing table entries
pcibios0: no compatible PCI ICU found
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc/0x8000 0xed000/0x1000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 2 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82434LX/NX PCI/Cache/DRAM" rev
0x11
"PC Technology RZ1000" rev 0x01 at pci0 dev 1 function 0 not configured
pcib0 at pci0 dev 2 function 0 "Intel 82378IB ISA" rev 0x03
vga1 at pci0 dev 6 function 0 "ARC Logic 2000PV" rev 0x00
wsdisplay0 at vga1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
rl0 at pci0 dev 12 function 0 "D-Link Systems 530TX+" rev 0x10: irq 9
address 00:0d:88:22:00:91
rlphy0 at rl0 phy 0: RTL internal phy
rl1 at pci0 dev 14 function 0 "D-Link Systems 530TX+" rev 0x10: irq 10
address 00:0d:88:24:47:53
rlphy1 at rl1 phy 0: RTL internal phy
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0 (mux 1 ignored for console): console keyboard, using
wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
wdc0 at isa0 port 0x1f0/8 irq 14
wd0 at wdc0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 9765MB, 1728 sectors
wd0(wdc0:0:0): using BIOS timings
wdc1 at isa0 port 0x170/8 irq 15
atapiscsi0 at wdc1 channel 0 drive 1
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: SCSI0 5/cdrom
removable
cd0(wdc1:0:1): using BIOS timings
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
sysbeep0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: using exception 16
cpu0: WARNING: Pentium FDIV bug detected!
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
isapnp0 at isa0 port 0x279: read port 0x203
ne3 at isapnp0 "Ethernet PnP ISA Card /S , AXE2201, PNP80D6, " port
0x240/32 irq 5
ne3: NE2000 Ethernet
ne3: address 00:40:05:c0:ad:75
biomask e945 netmask ef65 ttymask ffe7
pctr: 586-class performance counters and user-level cycle counter
enabled
dkcsum: wd0 matched BIOS disk 80
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302
--
Dave Anderson
<[EMAIL PROTECTED]>
Re: No DMA? What's going on here?
** Reply to message from "Todd C. Miller" <[EMAIL PROTECTED]> on Sat, 09 Jul 2005 18:55:03 -0600 >In message <[EMAIL PROTECTED]> > so spake "Dave Anderson" (dave): > >> If I'm reading it correctly, this bit of the dmesg says that my hard >> drive is not using DMA -- and so is running very inefficiently: > >The IDE controller on that machine does not have working PCI-based >IDE so you are stuck with PIO ISA IDE. If memory serves the >controller claims to support it but it is horribly buggy. If you >really want DMA, drop in a cheapo PCI IDE controller and hook the >drives up to that. Thanks for the info. The system has no free PCI slots, so I'll either live with it as is or look for a slightly-less-old junk system to use. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: No DMA? What's going on here?
** Reply to message from Nick Holland <[EMAIL PROTECTED]> on
Sun, 10 Jul 2005 00:16:57 -0400
>Something I have had good luck with on SOME old Dell BIOSs is to
>hard-code the drive parameters as 1024/16/63 (504M), rather than
>autodetecting. As long as your root partition is in that first 504M,
>the system will boot without problem or delay, as it won't try to detect
>the disk parameters at all, and OpenBSD will properly detect the entire
>disk.
Thanks for the detailed info, and especially for this hint -- which I
will certainly try.
Dave
--
Dave Anderson
<[EMAIL PROTECTED]>
