The bind packages places the directories where zone files are stored in /var, more specifically: dir /var/bind/pri obj /var/bind/pri/127.zone obj /var/bind/pri/localhost.zone dir /var/bind/sec obj /var/bind/sec/.keep obj /var/bind/named.ca sym /var/bind/root.cache -> ../../var/bind/named.ca Shouldn't these files be in _/etc/bind_ rather than in /var? After all, these are _config files_, which need to be edited (for the master zones) and archived. I can see, why you'd put the slave zones to /var, since those are generated files. I can live with that, though I personally would locate them in /etc/bind anyway, since those are config files of bind too, after all. Also, I'd like to suggest the names "master" and "slave" rather than "pri" and "sec". Reproducible: Always Steps to Reproduce: 1. 2. 3.
I definately agree with your "master" and "slave" reccomendation. As I've only recently taken over maintainership of BIND, I haven't had the time (or gumption) to make such a sweeping change without user input first. As to the zonefiles, I believe they are all considered "variable" data by nature. The root "hint" file, while relatively static, does change (vis, the recent change of, if I recall, F's IP address). Keeping in mind that /etc/ should be mountable 'read-only' according to the LFS. I'll take input, check general conventions and see what I can do.
No. The zone files are NOT config files. They are zone files, containing, essentially, database data. The zonefiles are expected to change with regularity on any nameserver that is not just functioning as a recursive nameserver for clients. Primary zones will be updated, secondary zones will as well. As stewart commented, /etc contains configuration files, and: "A "configuration file" is a local file used to control the operation of a program; it must be static and cannot be an executable binary." That's from the Filesystem Hierarchy Standard, located at http://www.pathname.com/fhs/pub/fhs-2.3.html. Basically, anything in /var is expected to change at any time, as a result of a program's operation (think a database server). Files in /etc however, are only changed by the system administrator by hand. Personally, i have symlinks in my /etc/bind/ directory. /etc/bind/pri points to /var/lib/bind/pri. This would satisfy the reporters concern, i think. The convenience of having things closely located, while adhering to the rules of filesystem layout. This, in turn, brings me to my next point. According to the FHS, /var/bind/ should not exist. To wit, "Applications must generally not add directories to the top level of /var. Such directories should only be added if they have some system-wide implication, and in consultation with the FHS mailing list." The most logical place for it then, from my reading, is /var/lib/bind, and place subdirectories as required within that. As for primary/secondary versus master/slave, i personally think this is more a matter of preference. However, it is interesting to note that prior to BIND 8, zones were primary or secondary. With BIND 8, the wording changed to master and slave. I'm referring to the configuration words in named.conf. Therefore, for modern versions of bind (which gentoo obviously uses) master and slave might seem more appropriate. (btw, why /chroot/dns? It would make more sense as /chroot/bind)
> No. The zone files are NOT config files. They are zone > files, containing, essentially, database data. Well, I don't know ... Following that logic, /etc/ssh/sshd_config is not a config file either. It's database data telling the SSH daemon how to operate. And while we are at it, why doesn't /etc/passwd lie in /var? That certainly _is_ a database. Or is it a config file for the login program? Anyway, my point is that I want to be able to back-up a machine's /etc directory and know that I can reproduce the complete configuration with that. I do not want to have to maintain a list of obscure directories like /usr/X11R6/lib/X11/xdm, /var/bind/pri, and so on. I don't care about slave zones, but the DNS master zone files are part of the BIND configuration, so they should be located somewhere near the other bind config files. I don't see what they should do in /var. It's not like BIND changes them, the _admin_ changes them.
> And while we are at it, why doesn't /etc/passwd lie in /var? > That certainly _is_ a database. Or is it a config file for > the login program? I'd say the answer to that is historical reasons. Obviously no one is going to change /etc/passwd any time soon. For any rule there are exceptions, especially in a system we inherited from 30 years ago. > I don't care about slave zones, but the DNS master zone > files are part of the BIND configuration, so they should be > located somewhere near the other bind config files. I don't > see what they should do in /var. It's not like BIND changes > them, the _admin_ changes them. Well see, that's not entirely true. You can use tools to update these files. Automated tools. DDNS, (dynamic dns that updates dns when DHCP leases are granted) webmin, other custom apps. It should be obvious that any zone with a significant number of changing hosts will not be edited by hand, as root, by the admin. > Anyway, my point is that I want to be able to back-up a > machine's /etc directory and know that I can reproduce the > complete configuration with that. Really sorry to sound harsh, but why should the distro care what you specfically want? It should do the right thing(tm), which is, IMHO, to follow the FHS. And also, that idea breaks down if you have any databases using config files stored in /etc/. Or what about apache? It's config files are in /etc/apache/, but the data it serves is elsewhere, often in /var/www/. BIND is a database of sorts, and will actually cease to operate if there is no data, which is what's bugging you. While other data serving deamons may be more forgiving about missing data, they will still be missing the data, and unable to do anything useful until you replace it. I see what you would like to do, but the problem is your solution would be limited, and improper in many situations. Besides, if you really want do put the zonefiles in /etc/bind, go right ahead. But i think it would be unwise and shortsighted for Gentoo to package BIND like that.
> I'd say the answer to that is historical reasons. You missed my point: I wanted to illustrate how the distinction between "config files" and "databasa data" is completely arbitrary, IMHO. > You can use tools to update these files. So what? I can use tools to update pretty much _any_ file on the hard disc. That's not a special property of master zones files. (And BTW: Dynamic DNS do not change the zone files, the changes are kept in separate journal files, which you should, I agree, place in /var.) My point is that a master zone file is absolutely not the same thing as an deferred e-mail in /var/spool/mqueue. It will not go away after a time-out, it will not be modified by BIND, and BIND will not be able to start-up properly, when it's missing. > Really sorry to sound harsh [...] Don't worry about sounding harsh. We're all on the same side, right? :-) Just say what you think, do the same. > why should the distro care what you specfically want? I'm trying to explain why there are good reasons for my preferred directory layout. If you don't agree, well, then that's fine. I know how to change the paths. We are arguing about something that's a matter of taste, not a matter of fact. I can distinguish between those two concepts. > The right thing(tm) [is IMHO] to follow the FHS. I personally don't care much for the FHS. I'll follow it where it makes sense and I'll ignore it when it doesn't. Besides, I don't think your interpretation of the FHS applies to DNS master zone files. > [That] idea breaks down if you have any databases using > config files stored in /etc/. I don't think I understand that statement. > Or what about apache? I don't see how Apache has anything to do with this matter. Besides, you might want to look at #33476 for proof that I'm not advocating to put everything into /etc at all. On the contrary. :-) > I see what you would like to do, but the problem is your > solution would be limited, and improper in many situations. I have been running BIND that way for several years and I have never found the solution to be "improper". Could you give a concrete example, where having the master zone files in /etc causes problems?
There seems to be little interest in this topic except from my side. So I'll close the bug report, doesn't seem to be useful any more.
