Re: document ldapd schema files
I can't really comment on the accuracy because I'm trying to avoid learning about LDAP at all cost, but this gives me enough info to start searching with, so I think it's a great addition. What is the technical reason behind not wanting to learn about LDAP? I'd be interested to hear feedback/input from you and the rest of the list.
Re: document ldapd schema files
On second thought, I should answer with a little less snark, though I think this one attribute sums it up pretty well. I enjoyed the first response but thanks for the follow-up. First, some committee sat around and tried to come up with all the things needed to describe a person, like license plates and pager numbers and who your secretary is. It's like it's custom built for handling the personnel records of IBM management. They made all this nonsense optional thankfully, but who's to say there aren't other attributes you need to store in your organization? Now you're off making your own schema. Adios interop! I've found LDAP useful in simple situations and barely tolerable in big organizations for reasons you highlighted. A lot of people have to justify their existence and some can do it by managing a directory server. On the flip side, I recently used LDAP for a guest wireless application and saved us from having to rely on Active Directory (definitely not something I like but for some organizations they think they need a directory system). I've tried to ponder how one might lobby managers in an organization to not go the single sign on route or use Active Directory (and AD like solutions) but I'm always faced with the ... it's easy and it works with everything counterpoints (and no it doesn't work with everything). I was hoping maybe some of you could shed light on approaches to solving the how do I manage users across multiple operating systems and application domains problem that faces a lot of organizations but I imagine that's a question better asked on a different mailing list. That question is why I asked you about your decision earlier. Second, the file formats seem purpose designed to be incomprehensible. Third, just doing something as simple as putting a single user record into the db using ldapadd involved an insane amount of typing of magic incantations. This is not entirely the tool's fault, there's just so much stuff involved it bubbles up to the user whether they like it or not. Yup, it's a bit of a mess and nearly impossible to create good and powerful abstractions for admins when faced with so many permutations. On the whole, infinite flexibility is pretty much synonymous with infinite complexity. This is where I led myself to on the whole discussion of identify management in an enterprise.
Re: Add support to AR5424
Full patch against latest I assume b/c of the 1.51 version tag of ar5212.c. I'll need to update before I test, but I'll try to test soon. Thanks.
Re: $LINENO in trap
Comments? ...snip... After a quick read, it looks good to me, but I've not built it and tested it because I don't have access to my openbsd system at the moment.
Re: Add support to AR5424
The previous patches you sent me off list gave me this: ath0 at pci2 dev 0 function 0 Atheros AR5424 rev 0x01: apic 2 int 17 (irq 10) ath0: AR5424 14.2 phy 7.0 rf 10.2, WOR0W, address XX:XX:XX:XX:XX:XX I'm going to evaluate the new ones tonight and will let you know.
Atheros AR5424 rev 0x01 hal error
When I attempt to use my wireless card (AR5424) I get the following:
ath0: unable to reset hardware; hal status 3520208968
The number at the end changes when I try again.
I believe I've traced where the error message is thrown to a section of code
in src/sys/dev/ic/ath.c:
if (!ath_hal_reset(ah, ic-ic_opmode, hchan, AH_TRUE, status)) {
printf(%s: unable to reset hardware; hal status %u\n,
ifp-if_xname, status);
error = EIO;
goto done;
}
I'm going to recompile with ATH_DEBUG=10 and see if I can get more
information. I'm also trying to trace down the ath_hal_reset function
to see if I can't find something in that area.
Does anyone that's worked on a similar error have any pointers? Thanks.
Re: Add support to AR5424
I have a card to test with and am trying to solve the problem on my eeepc laptop. Luis, are you still around and interested in working on this?
Re: Add support to AR5424
Lines identifying the card: ath0 at pci2 dev 0 function 0 Atheros AR5424 rev 0x01: apic 2 int 17 (irq 10) ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W, address XX:XX:XX:XX:XX:XX I have the version the other folks had that had issues with your patch. I can still attempt to use the patch if you'd like... On Tue, Apr 20, 2010 at 11:31 AM, Luis Henriques luis.hen...@gmail.comwrote: On Tue, Apr 20, 2010 at 4:06 PM, Adam M. Dutko dutko.a...@gmail.com wrote: I have a card to test with and am trying to solve the problem on my eeepc laptop. Luis, are you still around and interested in working on this? Yep, still around. But not sure how I can help without the actual HW. Sometime ago I submited a patch that is working for my card: ath0 at pci4 dev 0 function 0 Atheros AR5424 rev 0x01: apic 2 int 19 (irq 11) ath0: AR5424 10.2 phy 6.1 rf 6.0, WORAW, address XX:XX:XX:XX:XX:XX I'm using a CVS head kernel with this patch on my laptop, but some other guys tried the same patch with different revs of the card without success: http://marc.info/?l=openbsd-techm=126437914024661w=2 Try the patch to see what happens. Ah, and send the dmesg (at least the lines identifing the card. -- Luis
Source Overview
The obvious answer to this questions is Just read the source... but I still want to ask if someone is aware of a good overview of the OpenBSD source code? I've watched several presentations by Ted Unangst, Jason Dixon and co. and there seems to be a good amount of information spread across the web, but not a single canonical reference besides the source code (yes, I know source is very important). I know the base of code is very very large, so maybe instead of the whole repository, how about important parts/subsystems? Are any of you aware of such a document or documents? Are there areas that are easier for relative newbies to start in versus other areas? (eg. wireless drivers vs. SMP) Is there something like an openbsd janitors project where newbies can start? Thanks in advance. -Adam
Re: Source Overview
On Mon, Apr 19, 2010 at 10:57 AM, Bret S. Lambert blamb...@openbsd.orgwrote: ... snip ... Hopefully this is useful for somebody. It is, thank you. With regard to the other questions I peppered everyone with... :-) 1) Are there areas that are easier for relative newbies to start in versus other areas? I know this depends on a lot of things, to include experience. Hypothetically, someone that has some C experience, but not a lot of kernel (and subsystem) experience. Is it better to start from the bottom up like bootstrap to init? or is it better to start with memory management? network drivers? What is usually the best area from a learning and future utility perspective? 2) Is there something like an openbsd janitors project where newbies can start contributing small patches? similar to the Linux janitors project? Thanks again.
