Re: load average question
On Fri, 22 Nov 2002 23:51, Scott St. John wrote: > A few weeks ago we talked about me moving a server from BSDi to Debian. As > luck > would have it that BSDi server gave out last Monday and I had to move fast > to replace > it. Knowing I can do a RH install in about 30 minutes I went the route of > familiar > territory and installed 7.2 with Sendmail/QPopper/Apache/OpenWebMail. I am > paying > for that now with a huge performance problem. I am seeing Load Averages > spiking > above 6 during the day. Hardware is a Dual P3-600 with a gig of ram on a > IBM Netfinity Raid 5 controller. > > The owner of the company wants to go back to BSD, but I want to pursue > Debian. So the question is: is anyone running a similar set up with either > Sendmail or Posrtfix servicing 2,000+ email accounts with any performance > issues? Apart from webmail that should be a trivial load. Webmail systems seem to take up lots of resources in my experience, is it an option to have a separate machine for webmail? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DNS servers
On Fri, 22 Nov 2002 23:35, Toni Mueller wrote: > Like checking all the reverse-mapping hassle that's going on on > the Internet. Most people don't do it right, no? Doing it right > with BIND is work. Doing it right with djbdns comes for free > if someone likes to delegate the reverse mapping to you, and/or > accepts to pull it from you. For a large number of zones forward and reverse are handled by different servers and this won't solve the problem (only reduce it's prevalence). dlint is the way to solve the problem. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DNS servers
On Fri, 22 Nov 2002 22:58, Toni Mueller wrote: > > LDAP or SQL backed DNS isn't an option unless performance is not > > required. A LDAP or SQL query takes far longer than I want my DNS > > lookups to take. > > Here I'd like to re-use the words of DJB: "Profile, don't speculate." > > Apart from the fact that LDAP (and SQL) performance varies wildly > across different servers - eg. Fefe once claimed that his LDAP server > ran several orders of magnitude faster than OpenLDAP at a time, and > in a special situation that was important for him - we already know > about tinydns' ability to serve some 6000 requests per second on > decent dual cpu PC hardware, and we also know that on average, the > ldapdns by Mrs. Brisby runs twice as fast as tinydns using OpenLDAP. > This software serves it's data directly from the LDAP backend to the > best of my knowledge - having no intermediate format was a design > goal. How fast do you need to get? Last time I benchmarked OpenLDAP for user authentication (basically checking user names and comparing the hashed password strings - nothing advanced) it didn't deliver nearly that performance. I've spent quite a bit of time benchmarking OpenLDAP in various ways, last time I was testing it I found the performance much lower than I wanted from a DNS server. I guess that if the DNS server agressively caches the data it gets from LDAP then performance should be fine though. > > Of course that plan doesn't work so well if you are hired by a company > > that doesn't see the value of a lab and provides no decent resources for > > testing. > > Hmmm... A company that has no idea of the value of a lab??? Yes. > > There was one time I was setting up some fully loaded E4500 machines as > > LDAP servers and I had to use my Thinkpad for some tests because there > > was nothing else that I could use. A Thinkpad running Linux is not much > > good for testing the client and server sides of an operation that will be > > deployed on an E4500, but it was the best I had. > > Ouch! > > Ok, define 'lab'... > > Having some spare equipment that can be used to set up experimental > networks to check things out is not only a basic business requirement, > but also (mostly) cheap. True. But you need space for it, electricity, and it produces noise (humming of cooling fans etc). Most companies would rather give the space to managers or marketting people. Allocating 3 times the space per person to the technical team that other teams get so that they can run a lab is something that usually doesn't happen. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ssh and pam_mkhomedir
Simce I'm well on my way to being fully LDAP, I decided to try the pam_mkhomedir module with ssh on a machine that actually will allow a limited number of users shell access (controlled by the host attribute). Well, it doesn't work, I think because of the priv. separation that the Debian package defaults to. The only way to have the /home mode 777, or owned by sshd, neither of which I'm real keen on. Anyone else run into this, and actually found a way around it? Tim -- >< >> Tim Sailer (at home) >< Coastal Internet,Inc. << >> Network and Systems Operations >< PO Box 671 << >> http://www.buoy.com >< Ridge, NY 11961 << >> [EMAIL PROTECTED][EMAIL PROTECTED] >< (631)924-3728 (888) 924-3728 << >< -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DNS servers
[...] TM> ... When I turned TM> from BIND to djbdns, I discovered that I had several errors in TM> my name server setup, despite the fact that I thought I had TM> double-checked each time I messed with the server. [...] Just out of curiosity, what kind of errors were these? [...] TM> Just the matter of handling the various dots right, and not TM> forgetting the serial number, makes for a lot of chances to TM> mess things up, especially if you're tired. Of course, but don't be root when you are that tired. Don't even sudo. Surely djbdns can't help there to the extent you imply. [...] TM> Like checking all the reverse-mapping hassle that's going on TM> on the Internet. Most people don't do it right, no? Doing it TM> right with BIND is work. [...] Doing it right usually entails reading RFC-2317 these days. You will find that many admins are illiterate when it comes to this, so they screw it up. This is not a config file format issue, IMHO. TM> Doing it right with djbdns comes for TM> free if someone likes to delegate the reverse mapping to you, TM> and/or accepts to pull it from you. [...] Ok, I admit I don't see how. I'll go read the site when I get a chance. I'd love to see the problem I allude to above solved for free. Or maybe you mean generating PTR records automatically when A records are defined, in which case I kinda regret wasting time on this. cheers, BM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
load average question
Hi Gang: A few weeks ago we talked about me moving a server from BSDi to Debian. As luck would have it that BSDi server gave out last Monday and I had to move fast to replace it. Knowing I can do a RH install in about 30 minutes I went the route of familiar territory and installed 7.2 with Sendmail/QPopper/Apache/OpenWebMail. I am paying for that now with a huge performance problem. I am seeing Load Averages spiking above 6 during the day. Hardware is a Dual P3-600 with a gig of ram on a IBM Netfinity Raid 5 controller. The owner of the company wants to go back to BSD, but I want to pursue Debian. So the question is: is anyone running a similar set up with either Sendmail or Posrtfix servicing 2,000+ email accounts with any performance issues? Thank you for your time. -Scott --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.419 / Virus Database: 235 - Release Date: 11/13/2002
Re: DNS servers
Hi, On Fri, Nov 22, 2002 at 10:00:07AM +1100, Craig Sanders wrote: > no, there is at least one other unix nameserver that reads them. NSD. ok - taken already. I've skimmed their web pages but wasn't overly fascinated in an instant. But I'll expect to keep an eye on it. > there have been no arguments brought forward against the bind zonefile > format. a few people have claimed that it sucks but without providing > any reason or evidence. djbdns doesn't support it and djb doesn't like > it - that means that it's broken, right? No. Well, I may have missed that arguments against the BIND file format have not been brought forward on this list, but I've seen numerous complaints about it over the passage of time, and also have my own experience with it. When I turned from BIND to djbdns, I discovered that I had several errors in my name server setup, despite the fact that I thought I had double-checked each time I messed with the server. In a different message I wrote about helping a guy to get his name server up (BIND, too). I didn't like to wade through his 50+ domains, totalling a few hundred records, and decided to set up tinydns and pull them over. Doing it revealed a few dozen errors in his zone files that were not really obvious while consuming about half an hour. He was working on his files for several weeks already... Just the matter of handling the various dots right, and not forgetting the serial number, makes for a lot of chances to mess things up, especially if you're tired. > why, then, did that file format work for years before djbdns came along? Well, it worked, and still works in a certain sense. Sendmail also still works, and I'm about certain that I can power up a machine that runs 8.6.12 and would be able to receive and deliver mail. Is that any indication about that being a desirable, or at least satisfactory, state of affairs? I don't think so... Like checking all the reverse-mapping hassle that's going on on the Internet. Most people don't do it right, no? Doing it right with BIND is work. Doing it right with djbdns comes for free if someone likes to delegate the reverse mapping to you, and/or accepts to pull it from you. > because i prefer plain text files, i am "ignoring" certain tools? You made several statements that went like "I want my BIND files because I'm familiar with them, and can't read the obscure djbdns files." The tinydns data file _is_ a plain text file, you only compile it to a cdb file that the name server uses. And yes, there's a design difference between BIND and tinydns. An analogy is BSD using a compilation of the passwd file in db format, for faster lookups, where Linux traditionally uses a flat plain text file. Not _that_ much of a difference unless you want to claim that the tinydns-data compiler doesn't work correctly. If you use tools, you can be pretty ignorant about what format the application data is stored in. So, if the data file isn't plain text enough for you, you can't be using tools. (I also use version controll for my DNS data, but wouldn't call that a tool in this context). If you wanted to use tools, you should have been able to find and/or write them. They are there... > what universe do you live in? I'm in the same universe as you are. Or are you from outer space? > > No, all other Unix DNS software I am aware of can't do it as well. > NSD. That's still only one, compared to some 10+ other servers that can't. It's a very new one, too. So what was your real argument? Didn't you volunteer to post a patch to tinydns that makes it read BIND zone files directly? > > There could be a reason in _that_. > > laziness? > ignorance? > an irrational compulsion to reinvent wheels that work well enough (i.e. > Not-Invented-Here syndrome)? I don't think so. Most people are lazy, yes. If doing it BIND style would be easy, I'm sure many more people had adopted that way just to save them work. After all, if your tools work well enough, why throw them away? I venture to claim that all people who went away from the (ubiquitiously preinstalled) BIND have not done so because they didn't feel the need for an alternative, ie, they felt that BIND is a very significant PITA, too much to stand. > > How do you think about the multitude of SQL- and LDAP-backed DNS- (or > > anything-) servers out there? That's all crap because they don't work > > with BIND zone files and sendmail.cf? > try arguing against what *I* say, not what you claim that i say. You said that not using BIND zone files in a name server software is a stupid thing to do, and that doing it the conservative way requires sticking with BIND zone files, and you also brought forward the same argument for inetd and syslog. I only extended that to sendmail as well, which is also a piece of legacy software. So I rephrase the questions: How do you think about the multitude of SQL- and LDAP-backed DNS servers out there? That's all crap because they don't work with BIND zone files? > i really don
Re: DNS servers
Hi, On Thu, Nov 21, 2002 at 06:55:52PM +0100, Russell Coker wrote: > On Thu, 21 Nov 2002 17:53, Toni Mueller wrote: > > There is only one Unix way to use them (fortunately), and that's BIND. > There is also nsd. I've spent about 10 minutes playing with nsd and it looks > very promising, I've put in some bind zone files and they work. It was ok - I didn't know about nsd. > LDAP or SQL backed DNS isn't an option unless performance is not required. A > LDAP or SQL query takes far longer than I want my DNS lookups to take. Here I'd like to re-use the words of DJB: "Profile, don't speculate." Apart from the fact that LDAP (and SQL) performance varies wildly across different servers - eg. Fefe once claimed that his LDAP server ran several orders of magnitude faster than OpenLDAP at a time, and in a special situation that was important for him - we already know about tinydns' ability to serve some 6000 requests per second on decent dual cpu PC hardware, and we also know that on average, the ldapdns by Mrs. Brisby runs twice as fast as tinydns using OpenLDAP. This software serves it's data directly from the LDAP backend to the best of my knowledge - having no intermediate format was a design goal. How fast do you need to get? > Of course that plan doesn't work so well if you are hired by a company that > doesn't see the value of a lab and provides no decent resources for testing. Hmmm... A company that has no idea of the value of a lab??? > There was one time I was setting up some fully loaded E4500 machines as LDAP > servers and I had to use my Thinkpad for some tests because there was nothing > else that I could use. A Thinkpad running Linux is not much good for testing > the client and server sides of an operation that will be deployed on an > E4500, but it was the best I had. Ouch! Ok, define 'lab'... Having some spare equipment that can be used to set up experimental networks to check things out is not only a basic business requirement, but also (mostly) cheap. Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LDAP and email
Me and my fellow admins have a decent working solution using debian, exim, openldap, tied into pam with uw-imap and pop3, also uses all administered through apache w/ php. You are more than welcome to take a look at the current stable release (ugly but works) or our developement stuff, doesn't work but the code is readable. We are currently administering email for 40+ domains on this and it works well and is fairly easy to implement on a debian box. Cheers, Ehren System Administrator Echostar Solutions [EMAIL PROTECTED] wrote: Has anyone LDAPized their email system, along with /etc/aliases? If so, can you give me a pointer how you did that? Thanks, Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: DNS servers
apt-cache search djbdns djbdns-installer - Source only package for building djbdns is that what you're looking for? Was quite easy to install (like the equiv qmail deb package). Todd On Fri, 2002-11-22 at 13:48, Matt Andreko wrote: > Pardon my ignorance, but why is tinydns/qmail/etc under a restrictive > license? I've been very interested in running tinydns (I run bind now > because there are debian packages) but I run the debianized(src package) > qmail because I think it's the best server out there for my purpose. I > really don't like bind's configuration, and lack of security, so I've > been looking at switching to tinydns for some time, however having to > compile by source on debian has given me problems before, so I was > hoping for a debianized package, even if it's another src package. > > Is it just so that no trojans can be popped into the source as we've > been seeing much of recently, and DJB getting falsely blamed? Or is it > another reason? > > -- > Matt Andreko > > > -Original Message- > From: Jeff S Wheeler [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 22, 2002 10:47 AM > To: D. J. Bernstein > Cc: [EMAIL PROTECTED] > Subject: Re: DNS servers > > The draconian license you use to distribute tinydns and other software > is problematic for me. I can accept different zone file syntax with > ease, and can even adapt myself to the notion that the filesytem is used > as a configuration database. I can also understand that your resistance > to a license that would allow binary distribution, or distribution of > patched sources, is well-intentioned, but I cannot agree with it. > > -- > Jeff S Wheeler <[EMAIL PROTECTED]> > > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: DNS servers
Pardon my ignorance, but why is tinydns/qmail/etc under a restrictive license? I've been very interested in running tinydns (I run bind now because there are debian packages) but I run the debianized(src package) qmail because I think it's the best server out there for my purpose. I really don't like bind's configuration, and lack of security, so I've been looking at switching to tinydns for some time, however having to compile by source on debian has given me problems before, so I was hoping for a debianized package, even if it's another src package. Is it just so that no trojans can be popped into the source as we've been seeing much of recently, and DJB getting falsely blamed? Or is it another reason? -- Matt Andreko -Original Message- From: Jeff S Wheeler [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 10:47 AM To: D. J. Bernstein Cc: [EMAIL PROTECTED] Subject: Re: DNS servers The draconian license you use to distribute tinydns and other software is problematic for me. I can accept different zone file syntax with ease, and can even adapt myself to the notion that the filesytem is used as a configuration database. I can also understand that your resistance to a license that would allow binary distribution, or distribution of patched sources, is well-intentioned, but I cannot agree with it. -- Jeff S Wheeler <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DNS servers
Sanders writes:
> the alleged documentation for tinydns-data is atrocious too, it's ALL
> done by example, no syntax definition, no overview.
In fact, http://cr.yp.to/djbdns/tinydns-data.html contains the syntax
definition, a bunch of examples, and a link to a tutorial page.
[ the tinydns data syntax is ``bizarre and broken'' because ]
> the PTR record is automagically created when you create the A record
In fact, you're perfectly free to create just an A record (+fqdn:ip),
just a PTR record (^blah.arpa:fqdn), just an MX record (@fqdn::mx), just
an NS record (&fqdn::ns), just an SOA record (Z...), etc. You can play
with TTLs, serial numbers, and so on, in as much detail as with BIND.
Or you can work with slightly higher-level concepts such as hosts
(=fqdn:ip, creating A+PTR), mail exchangers (@fqdn:ip, creating MX+A),
and name servers (.fqdn:ip, creating SOA+NS+A)---concepts that BIND
doesn't support because they can involve more than one zone.
> get this, it really takes the cake, either or both of the A & PTR
> records are completely ignored unless there are appropriately
> corresponding NS records somewhere in the file.
In fact, the text you're talking about---``Remember to specify name
servers for some suffix of fqdn; otherwise tinydns will not respond to
queries about fqdn''---refers to a basic part of the DNS architecture.
The equivalent BIND rule is that every record needs to be in a zone.
> you can't find the A records for a given hostname just by searching
> for the "=" lines, you also have to parse every other line in case an
> A record is automagically defined elsewhere, e.g. in "&" or "." or "@"
> lines.
If you want a program to work with A records rather than higher-level
concepts, you can use tinydns-get to do a particular address lookup, or
you can use the following script to print out every address and name:
#!/bin/sh
sed 's/[ ]*$//' /service/tinydns/root/data | awk -F: '
function printx(type) {
if (!match($3,/\./)) $3 = $3 "." type "." substr($1,2)
sub(/^\./,"",$3)
print $2,$3
}
/^@/ { if ($2) printx("mx") }
/^[\.&]/ { if ($2) printx("ns") }
/^[=+]/ { if ($2) print $2,substr($1,2) }
'
This is another example of how easy it is to parse the tinydns
configuration syntax. Can you show me a script for BIND that reliably
does the same thing? Parse named.conf to figure out the active zone
files; parse the zone files; don't forget to deal with $ORIGIN and
$INCLUDE and $GENERATE ...
Of course, the above script can easily be modified to change a selected
IP address, or to start your editor on the appropriate line in the data
file, or to adjust TTLs, etc.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: routing policy
On Fri, 22 Nov 2002 17:19:47 +0100, mathias daus <[EMAIL PROTECTED]> wrote: >i wonder if there is a debian policy how to handle routing on boot time. >is there any solution as ifupdown? > >i read something about iproute. but i'm not sure if i like it. > >till now i have a self made script called /etc/init.d/route. it's simply >adding all routes. Add your routes in the up and down clause in /etc/network/interfaces. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DNS servers
On Fri, 22 Nov 2002 14:45, Johann Botha wrote: > even though i did enjoy reading your message i think running the Buggy > Internet Name Daemon is like kicking a dead whale down the beach.. not very > productive. > > i like djbdns. > > the question is very simple: would'nt it be nice if nobody had to worry > about BIND exploits ? I expect nsd to solve the security issues for authoritative name servers and it has a good upgrade path from BIND. That leaves me to just find a good caching server. I'll talk to my contacts regarding getting some partial funding for such development work by the same people who did nsd. From what I've seen of nsd they have done an excellent job, paying them to do the same for a caching name server is probably the best thing that could happen. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
routing policy
hi folks! i wonder if there is a debian policy how to handle routing on boot time. is there any solution as ifupdown? i read something about iproute. but i'm not sure if i like it. till now i have a self made script called /etc/init.d/route. it's simply adding all routes. i will be glad for any comments and suggestions. mathias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DNS servers
The draconian license you use to distribute tinydns and other software is problematic for me. I can accept different zone file syntax with ease, and can even adapt myself to the notion that the filesytem is used as a configuration database. I can also understand that your resistance to a license that would allow binary distribution, or distribution of patched sources, is well-intentioned, but I cannot agree with it. -- Jeff S Wheeler <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Being new to Debian...
On 22 Nov 2002 14:58:41 +0100, ÷ÁÓÉÌ ëÏÌÅ× <[EMAIL PROTECTED]> wrote: > That was true before woody became stable, the new policy is that when >there is a security alert, the secrity team releases for >potato,woody,sarge, and sid, you can check the latest DSAs. So, to be no >the no-so-bleeding edge, you can use testing with security updates, and >live happy :) http://www.debian.org/security/faq#handling Q: How is security handled for testing and unstable? A: The short answer is: it's not. Testing and unstable are rapidly moving targets and the security team does not have the resources needed to properly support those. If you want to have a secure (and stable) server you are strongly encouraged to stay with stable. However, the security secretaries will try to fix problems in testing and unstable after they are fixed in the stable release. The web page dates Nov 14, 2002. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DNS servers
Before I will start defending Craig, I would like to point out that the discussion is NOT just about taste. The boat left, and you weren't on it. It's about how the software is build up, what is put in to the package, and why the hell people have to think that they are better then the rest by non-quoting, non-reading, and displaying these featurs in a obnoxious way by thinking they have a point. We got 2 packs here, djbdns and bind. The first obnoxious part I'm reffering to is the attitude of the maintainer, and the "crew" building the djbdns pack. The second part I find extremly irritating is the amount of people getting exited by words on their screen, telling them it's way better, fantastic to work with etc..etc.. And as you have seen I havn't even referred to any technical spec what so ever wich was/is in debate right now. IMO this discussie went astray when the "quoting" started. If you start ripping pieces of text apart, and start quoting what you please, you're you have missed the context and the point. With this said, I stand with Craig for the full 100%, and would love to see some improvements. I might not be the best Sysadmin to go in to a discussion on the specs, but I sure as hell know when people are screwing with each other. The reason I singned up for this was to enjoy the occasional flamewar, get a bit of info, and try to add a bit where I could. Strange huh.. a friggn' rookie opening his mouth, asking politly to not piss each other of by manipulating words. Mark On Fri, Nov 22, 2002 at 02:14:17PM +, Fred Clausen wrote: > Hi All, > > I think this thread is becoming less a thread about which nameserver to > use and more people defending the time, money and effort they have > spent learning/writing the particular software package they use. > > Of course nobody is going to instantly change their software package and > have to re-learn how it is implemented in the new one. People should > certainly be aware about what is available and feel free to try other > pieces of software but nobody is obligated to use one or the other. People > must accept that different people have different needs (tastes even) and > so may use something else. A comprehensive analysis of what is required in > *your* organisation is needed, then pick software based on that. And if > someone else likes something else, then fine, good for him/her. They may > have different requirements. > > To conclude, nobody is forcing anyone to use one software package or the > other. Cool headed analysis is required, not name calling. > > Cheers, Fred. > > -- > Fred Clausen - Systems Administrator > Unique Interactive, part of UBC Media Group plc > Winners of the 2002 CRCA NTL New Media Award > > http://www.ubcmedia.com > http://www.uniqueinteractive.co.uk > T: +44 (0)20 7453 1677 F: +44 (0)20 7486 5081 > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- -- Mark Lijftogt -- http://sans.rondom.org -- http://www.lijftogt.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to upgrade dozens of debian servers
On Mon, 18 Nov 2002 11:28:14 -0800, "Kirk Ismay" <[EMAIL PROTECTED]> wrote: >In a cron job I use the following to alert me when new packages are >available for my systems: > ># update Debian package list >0 2 * * * /usr/bin/apt-get -q update > ># This produces a report of updated Debian packages >30 10 * * * /usr/bin/apt-get -s dist-upgrade | /bin/grep Inst > >This sends me an email for each system, so I know what needs an upgrade. When you think about it, it's already in Debian. See the cron-apt package which does a pretty similiar job. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Being new to Debian...
Âàñèë Êîëåâ wrote: Íà ïò, 2002-11-22 â 12:20, Marc Haber çàïèñà: On Fri, 15 Nov 2002 15:22:27 -0600, Sonny Kupka <[EMAIL PROTECTED]> wrote: Being new to Debian distro, I was just wondering what people's thoughts were on running testing in a ISP environment on a main server.. Don't do this. testing is the worst choice when you have to worry about security. Security-wise, stable is best (the security team taking care of it). unstable is next since the package maintainer can upload security updates. These security updates take at least three days until they migrate to testing, leaving you vulnerable in the mean time. That was true before woody became stable, the new policy is that when there is a security alert, the secrity team releases for potato,woody,sarge, and sid, you can check the latest DSAs. So, to be no the no-so-bleeding edge, you can use testing with security updates, and live happy :) Hello Marc, can you point us to a reference explaining this recent change of policy? I was under the impression that a stable's security is handled for maybe a month after it's replaced with a newest distribution, and never heard anything about a change. Thanks. -- Robin Y. Millette (aka Lord D. Nattor) http://rym.waglo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DNS servers
Hi All, I think this thread is becoming less a thread about which nameserver to use and more people defending the time, money and effort they have spent learning/writing the particular software package they use. Of course nobody is going to instantly change their software package and have to re-learn how it is implemented in the new one. People should certainly be aware about what is available and feel free to try other pieces of software but nobody is obligated to use one or the other. People must accept that different people have different needs (tastes even) and so may use something else. A comprehensive analysis of what is required in *your* organisation is needed, then pick software based on that. And if someone else likes something else, then fine, good for him/her. They may have different requirements. To conclude, nobody is forcing anyone to use one software package or the other. Cool headed analysis is required, not name calling. Cheers, Fred. -- Fred Clausen - Systems Administrator Unique Interactive, part of UBC Media Group plc Winners of the 2002 CRCA NTL New Media Award http://www.ubcmedia.com http://www.uniqueinteractive.co.uk T: +44 (0)20 7453 1677 F: +44 (0)20 7486 5081 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Being new to Debian...
Íà ïò, 2002-11-22 â 12:20, Marc Haber çàïèñà: > On Fri, 15 Nov 2002 15:22:27 -0600, Sonny Kupka <[EMAIL PROTECTED]> > wrote: > >Being new to Debian distro, I was just wondering what people's thoughts > >were on running testing in a ISP environment on a main server.. > > Don't do this. testing is the worst choice when you have to worry > about security. Security-wise, stable is best (the security team > taking care of it). unstable is next since the package maintainer can > upload security updates. These security updates take at least three > days until they migrate to testing, leaving you vulnerable in the mean > time. > That was true before woody became stable, the new policy is that when there is a security alert, the secrity team releases for potato,woody,sarge, and sid, you can check the latest DSAs. So, to be no the no-so-bleeding edge, you can use testing with security updates, and live happy :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DNS servers
Hi Mr Craig >@2002.11.22_14:51:18_+0200 > > Sanders claims that I'm telling people to ignore the possibility of > > that's *Mr* Sanders to you, scumbag. > > i find your tone to be annoying and insulting, welcome to my killfile. > > that will be all. LOL even though i did enjoy reading your message i think running the Buggy Internet Name Daemon is like kicking a dead whale down the beach.. not very productive. i like djbdns. i dont edit the data file by hand, i have an LDAP interface which makes administration a pleasure. the question is very simple: would'nt it be nice if nobody had to worry about BIND exploits ? DJB for president (; -- Regards Johann 'Simplicity is the ultimate sophistication.' - Leonardo da Vinci Johann L. Botha Frogfoot Networks ISP [EMAIL PROTECTED] http://www.frogfoot.net/ +27.82.562.6167 Built and Managed with Attention to Detail +27.21.683.1563 http://blue.frogfoot.net/ msg07316/pgp0.pgp Description: PGP signature
Re: Perl module for Apache configuration
Craig Sanders <[EMAIL PROTECTED]> writes: > On Thu, Nov 21, 2002 at 10:34:20AM -0500, Gene Grimm wrote: >> Are there any Perl modules that can help modify a configuration file >> for Apache? > > libapache-configfile-perl can parse apache config files. for writing > them, you're on your own AFAIK (not very hard, it's plain text with a > well-defined format, easy to generate). BTW Apache::Admin::Config does the job with respect of the file indentation. It's not part of Debian but you can find the debian package at: ftp://ftp.rhapsodyk.net/pub/devel/perl/Apache-Admin-Config/. This module is 1 year old, and it's ready for production use. Feedback is welcome. -- __ O l i v i e rP o i t r e y -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DNS servers
On Fri, Nov 22, 2002 at 10:43:50AM -, D. J. Bernstein wrote: > Sanders claims that I'm telling people to ignore the possibility of that's *Mr* Sanders to you, scumbag. i find your tone to be annoying and insulting, welcome to my killfile. that will be all. before you go, i'll take the time to correct a few of your lies. > Sanders claims that the tinydns configuration syntax isn't ``any > easier for programs'' than the BIND configuration syntax. That's > ludicrous. yes, it is ludicrous. words stuffed into other people's mouths and/or selectively taken out of context often are. that's generally the reason why lowbrow jerks resort to such underhanded tactics. what i actually said was: : parsing bind zonefiles is slightly more difficult than parsing tinydns. : : *generating* bind zonfiles, however, isn't particularly difficult. no : more difficult than generating any other text file. the closest thing i said to what you claim was (in an earlier message): : it doesn't make it any easier for programs either. : i've had no problems writing scripts to maintain either zonefiles or : named.conf. [example of scripts i've written snipped] in it's original context, it's nowhere near as absolute as the statement you ascribe to me. > Where's the equivalent of add-host for BIND zone files? there are numerous tools available for editing bind zone files. the fact is, though, that most people don't use them because bind zone files are actually human-readable - you don't need a special tool to edit them, it's easy enough to do with any text editor. > Nate Campi pointed out a few of the complications of the BIND > zone-file syntax that are avoided by the tinydns syntax. Sanders > responds that ``programs should do the extra work.'' Gee: I thought he > was claiming a moment ago that there wasn't any extra work. that was in the same message where i said "parsing bind zone files is slightly more difficult than tinydns", so you can't claim that you didn't see me saying it. in other words, you've just proven yourself to be a liar. even here you can't resist lying by quoting me out of context. what i actually said was: : human readable & editable config files should be optimised for human : use, not for machine use. programs should do the extra work to : convert on-the-fly if required, not humans. which has a quite different meaning than the selective excerpt you quoted. your intellectual dishonesty is appalling. your position is so feeble that you can't even argue your case on it's own merits, you have to lie about what others say and then argue against your own lies. i'm sure you must find that extremely satisfying - a form of intellectual masturbation akin to playing chess against yourself so that you can cheat. craig -- craig sanders <[EMAIL PROTECTED]> Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bind8 to Bind9
On Sat, 16 Nov 2002 15:19:02 -0500, Peter Billson <[EMAIL PROTECTED]>
wrote:
> I am planning the move from Bind8 to Bind9 on woody and was wondering if anyone has
>any tips, gotchas or pointers I should know before the move.
Here is the script that I intend to use for bind8 to bind9 migration
(moving from a normal bind8 to a chroot-non-root bind9 in the
process). Use at your own risk, and keep a backup of your
configuration.
#!/bin/bash
set -v
set -e
cd /var/local/
mkdir bind
cd bind/
mkdir dev
cp -a /dev/random dev/
chmod 444 dev/random
mkdir -p usr/share/zoneinfo/Europe
cp -a /usr/share/zoneinfo/Europe/Berlin usr/share/zoneinfo/Europe/
mkdir -p var/cache/bind var/run/bind
adduser --ingroup nogroup --uid 130 --disabled-password --gecos
"bind,,," --shell /bin/false bind
chown bind:nogroup var/cache/bind var/run/bind
mkdir etc
cd etc/
ln -s /usr/share/zoneinfo/Europe/Berlin localtime
mv /etc/bind/ .
apt-get --download-only install bind9
dpkg --purge bind
apt-get install bind9
sleep 1
kill $(cat /var/run/named.pid)
rm -rf /etc/bind
ln -s /var/local/bind/etc/bind /etc/bind
rndc-confgen > bind/rndc.conf
echo 'pid-file "/var/run/bind/named.pid";' >
bind/rndc.addition
< bind/rndc.conf sed -n '/^# Use with the following/,/# End of
named.conf/{/^# U
se with the following/d;/^# End of named.conf/d;s/^# //;p;}' >>
bind/rndc.additi
on
jed bind/named.conf bind/rndc.addition
rm bind/rndc.addition
cat > /etc/default/bind9 <<"EOF"
CHROOT="/var/local/bind"
USER="bind"
OPTS=""
[ -n $USER ] && OPTS="$OPTS -u $USER"
[ -n $CHROOT ] && OPTS="$OPTS -t $CHROOT"
EOF
cat > /etc/init.d/bind9 <<"EOF"
#!/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
# for a chrooted server: "-u nobody -t /var/lib/named"
OPTS=""
test -f /etc/default/bind9 && . /etc/default/bind9
test -x /usr/sbin/named || exit 0
case "$1" in
start)
echo -n "Starting domain name service: named"
start-stop-daemon --start --quiet \
--pidfile /var/run/named.pid --exec /usr/sbin/named --
$OPTS
echo "."
;;
stop)
echo -n "Stopping domain name service: named"
/usr/sbin/rndc stop
echo "."
;;
reload)
/usr/sbin/rndc reload
;;
restart|force-reload)
$0 stop
sleep 2
$0 start
;;
*)
echo "Usage: /etc/init.d/bind
{start|stop|reload|restart|force-reload}" >&2
exit 1
;;
esac
exit 0
EOF
/etc/init.d/bind9 start
The script will drop you into an editor, asking you to manually
incorporate a "pidfile" line, and the rndc configuration into
named.conf.
Be aware that you will be without name service for the run time of the
script.
Greetings
Marc
--
-- !! No courtesy copies, please !! -
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Being new to Debian...
On Fri, 15 Nov 2002 15:22:27 -0600, Sonny Kupka <[EMAIL PROTECTED]> wrote: >Being new to Debian distro, I was just wondering what people's thoughts >were on running testing in a ISP environment on a main server.. Don't do this. testing is the worst choice when you have to worry about security. Security-wise, stable is best (the security team taking care of it). unstable is next since the package maintainer can upload security updates. These security updates take at least three days until they migrate to testing, leaving you vulnerable in the mean time. If you absolutely must have later versions of certain packages than in stable, take the unstable package and try building them on a stable system (effectively backporting them). Then track them yourself, security wise. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DNS servers
I just wanna add my 2c's here. > We're discussing the example > >cd /service/tinydns/root >./add-host lion.x.mil 1.2.3.4 >make 1) Why do you need to use /service? 2) Whats wrong with inetd ? 3) What prevents debian from packaging djbdns in your licence? I'm reluctant to use djbdns because of this thread and the fact that none of your software is packaged for Debian. Wouldn't it make sense to change the way your licence is worded? [DISCLAIMER: I use bind8, im happy with bind8 and only host ~100 domains, I'm nobody special.] -- Brad Lay ([EMAIL PROTECTED]) Systems Administrator Samford Net P) +61 7 3855 2233 F) +61 7 3289 5458 W) http://www.samford.net "You will contract a disease for which the cure is so expensive that you will die of poverty." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DNS servers
We're discussing the example
cd /service/tinydns/root
./add-host lion.x.mil 1.2.3.4
make
from http://cr.yp.to/djbdns/blurb/easeofuse.html. These commands will
automatically stop and display a message if there are any syntax errors,
disk-write errors, etc. (Of course, there won't be any syntax errors
added by add-host, but maybe you edited the data manually.)
The ``DNS and BIND'' book says that you have to check syslog because
otherwise ``you might never notice'' syntax errors. That's true for
BIND, but it's not true for djbdns. The extra step of checking logs is
unnecessary for djbdns.
Sanders claims that I'm telling people to ignore the possibility of
errors introduced by editing. That claim is completely incorrect. I'm
saying---and, in fact, the same web page mentions a little later---that
these errors are automatically put on your screen in response to your
commands. (Exactly as you would expect from normal UNIX commands.)
Other helpful djbdns features illustrated by the same example:
* you can simply run a program instead of manually editing files;
* you don't have to repeat the host information in PTR format;
* the add-host program automatically stops if the name or IP address
was used before (if you want repetitions, use add-alias);
* the update is saved to disk (atomically!) just in case there's a
power outage;
* you don't have to worry about serial numbers;
* you don't have to worry about trailing dots.
A bunch of little improvements like this add up to a quite noticeable
overall improvement in ease of use: time saved, errors avoided,
confidence gained. (By the way, when Sanders claims that ease of use is
inherently subjective, he's ignoring decades of UI research.)
A more subtle point illustrated by this example is how easy the tinydns
data format is for programs to parse. The add-{host,alias,mx,ns,childns}
scripts, and the tinydns-edit program that they use, are small and
straightforward.
Sanders claims that the tinydns configuration syntax isn't ``any easier
for programs'' than the BIND configuration syntax. That's ludicrous.
Where's the equivalent of add-host for BIND zone files? To do the job
right, you'd have to parse named.conf in enough detail to reliably
locate the relevant forward and reverse zone files, then parse those
files in enough detail to check for prior use of the name and address,
update serial numbers, and so on. Yes, BIND can do all this parsing, but
BIND is a huge piece of code!
Nate Campi pointed out a few of the complications of the BIND zone-file
syntax that are avoided by the tinydns syntax. Sanders responds that
``programs should do the extra work.'' Gee: I thought he was claiming a
moment ago that there wasn't any extra work.
Talking to Sanders is like talking to Microsoft users who don't
understand why so few UNIX programs read Microsoft's document formats.
Some of those users scream that the UNIX people aren't paying attention
and don't care about compatibility. When programmers try to explain that
the limited software choice is caused by the unnecessary complexity of
the file format, the users respond that it's the programmer's job to
deal with that complexity. What's really sad is that they continue
blithely creating files in overly complicated formats.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
P.S. I wonder whether Sanders is bothered by the ``magic'' filenames in
the cron file hierarchy, and the terminfo file hierarchy, and the init
system, and many other UNIX configuration mechanisms. Is it so hard to
grasp the concept that the filesystem is a database?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
