Re: [SLUG] spelunkers of the world ...
On Thu, Feb 17, 2011 at 01:36:58PM +0800, James wrote: My kingdom to anyone who can id the parts U15 and U16 They are marked '44108' 'SA1delta' 'W97k' http://tigger.ws/downloads/img_1329.jpg SST441 N-Channel JFET Monolithic Dual - calogic corporation ? Maybe a compatible chip from a different manufacturer? Nick. -- PGP Key ID = 0x418487E7 http://www.nick-andrew.net/ PGP Key fingerprint = B3ED 6894 8E49 1770 C24A 67E3 6266 6EB9 4184 87E7 -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] DHCP - DDNS not updating
(Hi I'll reply to this thread as there seems to be a couple of threads going on the same subject) I've had a very similar setup to you in the past. I never had this much trouble. I had only centos 5.x servers. You've got split DNS. Internally, DNS resolves to your internal DNS server from your clients and you can see what you have allowed from internal as it's all internal. Externally, the world goes to dnsmadeeasy.com as your domains are delegated to this (i'm presuming). So if for example you are hosting a webserver, then dnsmadeeasy would point that domain to your MODEM external ip address. On your modem you would have a virtual server setup with port 80 forwarded to your internal webserver ip address. So from internal you get to the clients webserver from your internal DNS. From external you get to your clients webserver from being redirected through dnsmadeeasy to your external IP of your modem and then from your modem forwarded to your webserver. You could even have your internal clients all point to the modem for DNS. The modem would ask dnsmadeeasy where that domain was, it would point to your modem and then the modem would port forward them all back into your internal webserver. I never had any issues with dns key files or dnssec or whatever as I never needed to use it/them. I would recommend removing all these until the basics are working solidly. Have you tried using webmin to setup dns on your internal dns server? Thanks, Ben Donohue On 17/02/2011 3:16 PM, Kyle wrote: Peter, exactly!! THAT IS MY ISSUE I believe. But I have not yet found a log to give me sufficient info to nut out WHY. All my config files are presently up for the world to see at; https://www.centos.org/modules/newbb/viewtopic.php?topic_id=30159 And from what I've read (LOTS in the last couple of days), they're picture perfect. Kind Regards Kyle On 17/02/11 3:02 PM, pe...@chubb.wattle.id.au wrote: I strongly suspect that the key setup is incorrect. .it will fail because of an authorisation problem. Peter C -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] [SOLVED] DHCP - DDNS not updating
And the gold star goes to John. Thanks John for thinking with me. And of course thanks also go to everyone else who kicked in. For posterity and by way of explanation: Because of the views and the fact the update was coming from dhcpd on localhost, the 'localhost_resolver' view was taking over and disallowing the update because it couldn't find the key matched to the internal zone anywhere, as of course neither could the rest of the www where it was further forwarding the request. Once I included the internal zones into the 'localhost_resolver' view, hey presto! I created the views pretty much carbon copy from the sample file in /usr/share/doc that comes with this dist. of BIND. That file states (verbatim); // All BIND 9 zones are in a view, which allow different zones to be served // to different types of client addresses, and for options to be set for groups // of zones. // // By default, if named.conf contains no view clauses, all zones are in the // default view, which matches all clients. // // If named.conf contains any view clause, then all zones MUST be in a view; // so it is recommended to start off using views to avoid having to restructure // your configuration files in the future. The sample file does also state; // These are your authoritative internal zones, and would probably // also be included in the localhost_resolver view above : But doesn't state when/why/etc. Nor does the manpage. In fact, nothing I read anywhere made any determination of difference between running a DHCP-DDNS setup on a single box or separate boxes. What the hell does probably mean in that context? To be fair, I had already tried including the internal zones in the 'localhost_resolver' view on my original host, but when I started BIND thereafter, syslog showed each defined zone being loaded twice, so I had discounted that as being not good (obviously something else going on on the original host). And no level of debugging log BIND enabled me to set up provided any clues (any mortal could fathom anyway) as to why it wasn't authorised. Thanks again all. It's easy when you know how. Kind Regards Kyle On 17/02/11 6:24 PM, John Clarke wrote: This is just a guess because I've pretty much hit the limits of my knowledge, and I've never used BIND's views, but could it be something to do with the different views you've configured? You're trying to do the update from localhost, so that matches the view localhost_resolver, but updates aren't allowed in that view configuration. Updates are allowed in the view internal, which also matches localhost, but I wonder if BIND is simply using the first match and thus disallowing updates? -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] [SOLVED] DHCP - DDNS not updating
On Fri, Feb 18, 2011 at 09:23:07AM +1100, Kyle wrote: And the gold star goes to John. Thanks John for thinking with me. Thanks, but it was really just a lucky guess at the time ;-) John -- I'd miss the BBC, but not if I had time to reload. -- Terry Pratchett 13/01/2001 -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
