Please remember to reply to the mailing list, not the original sender: http://gnudip2.sourceforge.net/#mailinglist
+++++++++ Devin Reade wrote: > > > Since you seem to have some experience (with Perl?), perhaps you would > > like to get involved in maintaining GnuDIP? This could be your first > > GnuDIP project. > > Heh. I was afraid that was going to be the answer. :) > > Sure, if you wouldn't mind addressing the MX issue when you get the > chance (no rush, I've just put on my web pages "don't use secondary > MXes, they're broken"), I will do it in the next few days. As I have explained to others on this list though, I have fallen into the bad habit of just making bug fixes to the 2.3.5 release. Because the clients are part of the whole package, and share the release number, and because the release number appears in many places in the documentation, bumping the release number is a hassle. I should add an item to the "To Do" list to rethink the existing framework. > I'll put the "back to the top" button on my > stack. How soon I get to it will depend on how much it annoys me > compared to other things I have on my plate. > > As far as the experience goes, I am a very experienced UNIX systems > programmer (>10 years), and have been programming in general for > about 17 years. I have good perl4-ish skills, but tend to avoid > object oriented perl5-isms, so I'd say only intermediate in that > area. GnuDIP does not use Perl objects. The files that that get "include"-ed aren't even modules! They communicate by global variables. I have had hate mail from Perl mongers (not really). I broke it out into multiple files simply because it got too big to edit managably. With multiple files I could have several files open at once. Using multiple files also provides each file with its own name space for variables (not functions though!!), which was a convenience. I used "include" rather than "require" because "require" is delayed. I wanted to be able to use the Perl compiler and have it all compile. With "require", only the tiny script at the "top" would get compiled! The Perl compiler turned out out to be do bug ridden to be helpful, but I use a static FastCGI server on my site, and because "include" is used all of the files get compiled when Apache starts. > I don't do Windows. I hope that I will not have to learn any more about Windows than I currently do. But I have not been able to avoid Windows. > > The design is that only one "foreign" MX can be specified. > > I don't understand the concept of a "foreign" MX here. What do > you mean by that? And are you referring to the design of GnuDIP > or the DNS dynamic updates protocol? (The latter with which I as > yet have only passing familiarity -- my own package predated > dynamic updates). I just pulled the word out of the air as I wrote it. What I meant is that GnuDIP maintains two MX records. Each is either present or not present, independently of each other. One is the the user's own dynamic domain name (if the user selects "Backup Mail Exchanger"). The other is the one the user can type in (which I called "foreign"). The one for the user's domain name was supposed to have higher priority, so that the one the user typed in would only be used as a back up. The user can have an MX record for their own domain name, without the back up MX. This is just a "no-op" because of the way DNS works. > > But as I have said, I have little interest in adding new features. > > Again would you like to? > > Depends on whether you would classify what I'm looking for as > a weird agenda :) > > My operating environment is BIND 9 and Apache. If I were to > get involved, some of they key things I would be looking for > are: > - permitting a single update to affect multiple hosts > (which I believe is already on your wish list) > - permitting an update to result in multiple 'A' records > rather than just one, thus winding up with entries > like this: > host.example.com. IN A 192.168.1.10 > IN A 10.10.5.18 > IN MX 100 mx1.example.com. > IN MX 200 mx2.example.com. > Think of the case where you have a multiply-homed site > where at least one of the interfaces is on dhcp. The > "fix my particular problem" case is allowing for one > IP via dhcp, and one IP which is static. The general > case would be two or more, any of which can be dynamic > or static. I am not sure I follow the details of this scenario. > I realize that these would almost certainly involve a change to > the on-the-wire protocol and thus would have to be planned with > backward compatibility in mind. As long as backwards compatibilty is allowed for, fine. In Open Source, he who is willing to write code makes the final decisions. If you want people to use your system though, you have to excercise some discipline. I certainly tried to do this when I took GnuDIP from Mike Machado. I got his blessing first. If I had done my own system from scratch would anyone have used it? Mike had promoted GnuDIP very well and it was successful, but he was tired of working on it. There were certainly things that I would have liked to do differently, but by signing on to GnuDIP I had to worry about backwards compatibility and providing convenient upgrades. I also carried GUI features into my rewrite that I did not like simply because they were significant features of Mike's original system. I only removed things that were a very serious problem when moving to using the "nsupdate" interface. Also, the success of Mike's original version suggested that he must have some incite. It would have been naive and arrogant of me to think that I could easily do something better. > My own package (which I am abondoning) permitted the update of > entire zone files for selected subdomains, but the fact is that > I was the only person ever to use it (in support of a split DNS). > That, combined with "views" that have been introduced to BIND > make me consider this to be a feature that is no longer required, > so you need not worry about me trying to add *that* feature ... > > My timeline for doing changes like the above would probably be > sometime in the next few months rather than the next few days > or weeks. In other words, they're something that I want rather > than something that is keeping me from having a working system. That's cool with me. Although I don't plan to make major extensions to GnuDIP (at least not on my own), I don't plan to abandon it either. I will be here. -- Creighton MacDonnell http://macdonnell.ca/ -- GnuDIP Mailing List http://gnudip2.sourceforge.net/#mailinglist
