It may be that the people who run this charity with ties to terrorism want him dead. So perhaps he is somewhat willingly hanging out in solitairy.
This is the single dumbest thing posted on Slashdot so far this year, and that's saying something.
Would it have killed you to read the fucking article, or the Free Mike website?
Mr. Hawash was arrested at gunpoint in his company's parking lot, while armed agents invaded and searched his house.
A free clue: this is not how the Feds protect cooperating witnesses who they think might be in danger from the people they plan to testify against. (When that happens, they check you into a hotel with an armed guard.)
Another free hint: if they thought his life might be in danger, why are they letting his family continue to twist in the wind? You don't think Al Qaeda would think to hurt the wife and kids of someone they thought was an informant?
Last but not least: if he was "hanging out" in solitary confinement (and that phrase right there is a strong contender for "dumbest thing said on Slashdot ever") voluntarily, don't you think his wife or lawyer could have somehow communicated this to the Intel Vice President who is running the 'free Mike' campaign?
Not weird, the app will take 280 megs of ram after running for 10 minutes and launching eny other app while it's running will lock up your machine.
Er, when was the last time you ever used a java client application?
I'm not going to apologize for the bloat and slowness of the original versions of java (1.0-1.2 inclusive): Sun fucked up, and MS cleaned their clock in the market as a result. Spilt milk, no use in crying over it.
I use java client apps (mostly limewire) almost every day on my 2-year-old linux box (not exactly a speed demon by today's standards), and I have never seen the problems you describe. If you are seeing that kind of slowdown just on application launch, you should be complaining loud and hard to your vendor, because something is seriously fucked up.
I know, I know, bitching about rejected articles is off-topic. Obviously, the two stories about the latest Mandrake point release that got published yesterday were a little more important than a network security angle on World War III.
Sorry, i was busy fucking your mom up the ass while writing my last reply.
Yeah, yeah, yeah. You're the terror of the 7th grade playground, I can totally tell. "Fucking my mom up the ass." I bet you pack 'em in every night at the Apollo. You're a regular Stagger Lee, boy! Let me know when your album comes out!
1) fact is that you want a complete from bottom to top desktop environment. 2) now that xfree adopted a lot of gnome shit with 4.3.0 i was assuming you were refering to gnome here as complete desktop from bottom to top. 3) that made me reply the way i did.
Maybe that sounded impressive (or at least coherant) in whatever your native language is?
I repeat: "Allow?" Nobody "allows" anybody to do anything with the X11 codebase. It's free. Allow me to demonstrate by example:
If the syphlitic chimpanzees you optimistically refer to as your parents decide that they want to fork XFree86, they don't have to check with you.
If the doctor who abandoned his responsibility to the human race by not strangling you at birth decides that he wants to merge XFree86 into the QNX kernel, you don't get to vet the decision.
If the makers of the hand cream that is your only sexual partner decide that they want to include a free CD of XF86 with every bottle of their lotion, they won't consult you.
If the crabs that infest your rancid pubic hair develop a group intelligence and decide to replace all of XF86's linked-list functions with wrapper calls to GLIB2, people will mostly feel sorry for the crabs for having had to grow up in such a bad neighborhood, and applaud their initiative.
And last but not least: if a group of people who actually produce working code instead of spending their time posting gibberish flames in broken english to slashdot decide to do anything whatsoever, nobody is going to give a rat's ass whether you think it should be "allowed" or not.
There are two morals to this story, child:
1. Don't complain about code that nobody is forcing you to use when there are plenty of alternatives available.
2. Don't try to play the dozens against strangers when your game is that weak. Come hard, or don't come at all.
Just as Linux, BSD, SCO and a few others all provide implementations of (more or less) the "UNIX" specification on i386 hardware, there are multiple implementations of the X11R6 standard on i386-based unixes.
If you don't like XFree86, the folks at XiG would be happy to sell you a copy of AccelX. MetroLink systems still offers Metro-X (which was the bomb back in the RedHat 4 days...dunno about now), and if you don't have any money to spend, you can still download, compile and use the honest-to-god MIT/XConsortium X11R6.6 server.
If you want a windowing system that's not based on X11, your options are a bit more slender, but they're there. The Fresco project (formerly "Berlin") looks promising, as does PicoGui.
Okay, either you are an excellent troll or a complete fucking idiot. I'm betting on the latter, but let me congratulate you in advance, just in case it's the former.
You mean that unix might actually get a display engine, windowing system, UI toolkit and desktop that is completely integrated from top to bottom? Oh no, we can't have that! That's the evil, evil idea that made Microsoft and Apple all of those billions of dollars of bad, bad money! We must stay pure and true and hold fast to the same awful model that lost Sun, HP, Apollo, SGI, Stardent, Argent and Domain the workstation market! Despite all that tempts us, we will never waver in our determination to become yet another UNIX footnote!
p.s. if there is to be some kind of unified X11/Gnome thingy, it won't be called XFREE. XFree86 is a trademark of the XFree86 Project, Inc, a privately held corporation. The code is free, but the name is not.
p.p.s. Of course if such a project were released, obviously the first side effect would be that the entire XFree86 core team would spontaneously combust, every copy of the XFree86 source tree mysteriously vanish, and every computer running XFree86 automatically update itself to the new system, so I guess I can see your concern.
I do not think that any current or near (5 years) future version of Windows will be ported to MIPS, PPC, or Alpha.
Well, certainly not Alpha, since that's officially a dead architecture.
MIPS and PPC...well, probably not, but the history of the previous ports of NT to those architectures suggests that MS will be happy to update those ports the moment someone shows them the money for it. This isn't as far-fetched as it might sound: remember that they're also pitching "Embedded NT" along with WinCE, and there are a lot of PPC devices in the embedded market.
Windows Server for Itanium is a lock. It might not ever sell more copies than the Alpha and MIPS versions, but it will happen, even if HP and Intel have to underwrite the development costs themselves. They have too much riding on their investment in the ia64 platform to do anything else.
Ahem. Of the 12 CPU architectures you listed, the NT OS (3.51 and 4.0) has already been ported, boxed, shrinkwrapped and shipped to three of them (Alpha, MIPS and PowerPC), and if you think MS isn't going to ever ship an IA64 version of windows at some point, I have some prime real estate that I'd like to sell to you.
Granted that the MIPS and PPC versions of NT were effectively footnotes, but there they were.
Well, I haven't used qmail, but Postfix is braindead simple to replace sendmail with.
Ditto qmail. (Hell, probably ditto every other nextgen MTA as well -- it's not exactly rocket science to duplicate/etc/aliases,.forward and provide a "sendmail" wrapper program.)
I haven't had much luck with DJB's other tools like the inetd replacement though or his tinydns. It works fine for awhile and then just starts hanging. It's enough to keep me using BIND 9.x. Someday I'll have to mess around with it and see what's up since I know tons of people use it so it's probably my fscked up system.;-)
Most likely, yes.:) The djbdns mailing list is usually a good place to ask such questions, just try to document the problem thoroughly (as in: step by step what you did to install it) before posting.
One advantage of Postfix over qmail is that Postfix, from the outside, looks a lot more like Sendmail (which, if you're migrating, is a good thing).
This is not necessarily true. Qmail has officially supported tools to make it look indistinguishable from sendmail for 90% of all users. (e.g. support ".forward" files and/etc/aliases)
Qmail is not Free Software
This is true. Personally I think it's idiotic to consider that to be a "moral" issue, but whatever: assess your needs and choose the appropriate tool.
Wietse Venema is a better human being (aka not a hypocrite) like djb. For those reasons, I will never use qmail, and I advise all others to not use qmail.
This is stupid.
Eric Allman is a nicer guy than Wietse and Dan put together. Hell, probably nicer than the product of Dan's congeniality to the power of Wietse's social skills. I've hung out with him at Usenix conferences, and if I lived in the same area I'd probably invite him to parties.
I still wouldn't run sendmail on a bet.
DJB is an abrasive asshole. I've called him a sociopath directly on at least one occasion. I wouldn't want to be trapped at a cocktail party with him, and if I had a daughter I wouldn't want to date her.
I still ran qmail at companies that I had actual money invested in, because the code is that good.
Cutting off your nose to spite your face is stupid when you're the person who'll get called at 3 in the morning when your box gets rooted. Pick software based on quality and utility, not personality.
(I'd call qmail and postfix to be about equally matched for quality, so it comes down to a question of features and style preference for me.)
Did you fail to notice that this entire article is about yet another remote sendmail root exploit?
Other things that are wrong with sendmail:
- Horrible, horrible resource utilization issues. Fork a new copy of the whole goddamn multimegabyte/usr/lib/sendmail for each new delivery. Copy-on-write swap systems save you some here, but this is circa-1979 engineering at its worst.
- Configuration is a bad joke. The M4 macros are a bandaid slapped on top of a sucking chest wound. The web-based configurators in the commercial sendmails are a gold star slapped on top of the bandaid. Quick: name the four different "MASQUERADE" options supported by sendmail.mc, and explain how they differ and in what situations you would use which combinations of them. Can't do it without referring to the manual? Don't feel bad, neither can I, and I used to manage sendmail for a living.
- Incredibly crappy delivery performance. The hashed queues in recent sendmails have somewhat alleviated this, but qmail, postfix and exim still trounce sendmail for remote delivery speed.
- No VERP support.
- Last I checked (circa 8.11), SSL/TLS/ASMTP was a painful joke, requiring an incredibly fragile collection of third-party libraries to even stand a chance of working, which it usually didn't. (Compare to Courier, which includes all of the above out of the box.)
- Sendmail's monolithic design makes _any_ extensions into a bleeding nightmare. Compare to qmail or postfix, where if you don't like one component (the smtp daemon, the delivery agent, etc etc) it's a snap to swap it with one of your own.
- Bugs, bugs, bugs, bugs, bugs, bugs, bugs.
And that's just off the top of my head. Google for "sendmail problems" and see for yourself.
Have you ever try to run 2 instances of qmail on one machine for exampe?
I believe I speak for the entire oxygen-breathing population of the planet earth when I say "huh?"
First of all, there's actually nothing stopping you from doing this: just compile and install qmail twice, with a different value in "conf-home" each time. Et viola, two distinct qmail installs on the same machine. Then just create a tcpserver instance for each qmail-smtpd, bound to the proper interface.
But second, this is almost certainly the wrong way to solve whatever problem it is you think you're having. Read qmail's documentation for the smtproutes control file: dollars to doughnuts says the functionality you need is in there.
Qmail is anything but rigid, and making it jump through hoops backwards and forwards is usually just a matter of reading the f-ing manual.
"sendmail -d0.1" will give you a dump of a bunch of basic information about your sendmail install, including the version numbers and which external libraries it was linked against.
(You'll have to hit ^c to exit back to the shell; invoking sendmail with -d causes it to wait for a message on stdin to process.)
Of course, what I meant there was "sendmail to qmail migration checklist". Gee, it's a good thing that with all of the millions of dollars of venture funding that VA-Linux has burned through and thousands of man-months of development time that Malda etc have put into slashcode, they didn't do anything kooky or weird like say giving you the ability to edit your posts, like any circa-1987 Commodore 64 BBS program.
You want to replace your entire MTA, one of the most notoriously difficult-to-imlement pieces of software on any internet-connected host, and you want it to work perfectly, but you don't even want to spend a day on the task?
Assuming you haven't done anything really gonzo with your sendmail config, you should have a working system in a few hours. Then go read Life with Qmail so that you'll actually have an idea of what you've just inflicted on yourself.
Excuse me, but what the hell are you talking about? Would you care to support this statement in some fashion?
Moderators, shame on you for giving points to this unsupported drivel.
Unbiased readers: compare and contrast for yourself. Qmail and Postfix are basically feature-equivilant, have roughly comperable performance, and both have stellar security histories. Both have plenty of 3rd-party tools to automate stuff like virtual domains, catch-all users and the like; both integrate nicely into a number of webmail and pop/imap servers.
Deciding between the two is largely a matter of taste: qmail's many small config files versus postfix's few large ones; different methods of handling aliases; etc etc etc.
That is not how copyright works. Full stop. You don't get to "assume" that you are allowed to distribute a copyrighted work just because the author has not told you you can't. Precisely the opposite: it is illegal to do until the copyright holder tells you that you can.
urk urk urk. You really like to make things hard for yourself, don't you?:)
Okay, first-off, a statement of sympathy: djb has gone out of his way to make it difficult to install some of his software in standard places, and yours is a good example of the kind of headaches that result from his intransigence on this issue.
That said, there are much easier ways to do what you're trying to do here, and I suspect that this would have become immediately apparent if you'd taken a bit more time to read through the documentation, play with the tools, and understand what you're working with.
The big fact that you need to keep in mind here is that the collection of tools that usually gets referred to as "djbdns" is actually (assuming you more or less follow the instructions) three seperate software packages:
djbdns is a collection of client and server tools for getting and sending dns information. ucspi-tcp is a collection of tools for making generic TCP clients and servers (sorta like inetd or netcat), and daemontools is a collection of tools for managing persistant programs and their logs. It's entirely possible to run them without each other, but you have to be aware of what each package provides and be willing to roll the functionality yourself.
A few suggestions:
The whole "/package" and "/command" monstrosity is only part of version 0.76 of daemontools. Previous versions (0.70 is still available for download) of daemontools compile in/usr/local/src and install into/usr/local/bin like a sane program should.
There is no requirement that you use the svscan functionality of daemontools. If you know exactly what it is you want started, just execute "supervise/service/whatever" manually or out of an init script.
Likewise, you can dispense with daemontools altogether if you just exec the "/service/whatever/run" scripts directly. Of course, you lose auto-restarting and the like, but you may not care.
If you don't care for the way that daemontools handles logfiles, the "splogger" program from djb's qmail package will take the stdout from a process and pipe it into syslog. (But since tinydns and dnscache log pretty verbosely, you may just want to pipe it to/dev/null.)
Speaking of those "run" files: you really should read them (they're short), since that will give you a much better idea of what's going on, and why.
Of course you need to start tinydns and dnscache as root: how else are they going to bind to a privleged udp port? Check the code; they setuid themselves to an unprivleged user soon after binding. (Axfrdns doesn't have this problem: the tcpserver instance runs as root, while axfrdns does not.)
The contents of/service don't need to be actual directories; a tree of symlinks will do. (This should be a lot easier to build into a ramfs partition than all of the actual subdirs.)
That all said, I find daemontools (modulo the current slashpackage nonsense) to be a very handy utility, and have been slowly converting over most of my long-running daemons to work under it. "Try it, you'll like it."
Small hint: turn off logging. By default, tinydns and dnscache emit multiple log lines per query, turning your logging disk into a bottleneck. Pipe stdout and stderr from the tinydns process into/dev/null for an order of magnitude (or more) performance increase.
Slashdot Mirror
Only Windows 2000/XP support has been dropped.
It may be that the people who run this charity with ties to terrorism want him dead. So perhaps he is somewhat willingly hanging out in solitairy.
This is the single dumbest thing posted on Slashdot so far this year, and that's saying something.
Would it have killed you to read the fucking article, or the Free Mike website?
Mr. Hawash was arrested at gunpoint in his company's parking lot, while armed agents invaded and searched his house.
A free clue: this is not how the Feds protect cooperating witnesses who they think might be in danger from the people they plan to testify against. (When that happens, they check you into a hotel with an armed guard.)
Another free hint: if they thought his life might be in danger, why are they letting his family continue to twist in the wind? You don't think Al Qaeda would think to hurt the wife and kids of someone they thought was an informant?
Last but not least: if he was "hanging out" in solitary confinement (and that phrase right there is a strong contender for "dumbest thing said on Slashdot ever") voluntarily, don't you think his wife or lawyer could have somehow communicated this to the Intel Vice President who is running the 'free Mike' campaign?
Not weird, the app will take 280 megs of ram after running for 10 minutes and launching eny other app while it's running will lock up your machine.
Er, when was the last time you ever used a java client application?
I'm not going to apologize for the bloat and slowness of the original versions of java (1.0-1.2 inclusive): Sun fucked up, and MS cleaned their clock in the market as a result. Spilt milk, no use in crying over it.
I use java client apps (mostly limewire) almost every day on my 2-year-old linux box (not exactly a speed demon by today's standards), and I have never seen the problems you describe. If you are seeing that kind of slowdown just on application launch, you should be complaining loud and hard to your vendor, because something is seriously fucked up.
Wait, let me see if I'm reading you correctly here. You won't buy a working application just because it's written in java/swing/awt?
That's just weird, man.
I know, I know, bitching about rejected articles is off-topic. Obviously, the two stories about the latest Mandrake point release that got published yesterday were a little more important than a network security angle on World War III.
Sorry, i was busy fucking your mom up the ass while writing my last reply.
Yeah, yeah, yeah. You're the terror of the 7th grade playground, I can totally tell. "Fucking my mom up the ass." I bet you pack 'em in every night at the Apollo. You're a regular Stagger Lee, boy! Let me know when your album comes out!
1) fact is that you want a complete from bottom to top desktop environment.
2) now that xfree adopted a lot of gnome shit with 4.3.0 i was assuming you were refering to gnome here as complete desktop from bottom to top.
3) that made me reply the way i did.
Maybe that sounded impressive (or at least coherant) in whatever your native language is?
I repeat: "Allow?" Nobody "allows" anybody to do anything with the X11 codebase. It's free. Allow me to demonstrate by example:
If the syphlitic chimpanzees you optimistically refer to as your parents decide that they want to fork XFree86, they don't have to check with you.
If the doctor who abandoned his responsibility to the human race by not strangling you at birth decides that he wants to merge XFree86 into the QNX kernel, you don't get to vet the decision.
If the makers of the hand cream that is your only sexual partner decide that they want to include a free CD of XF86 with every bottle of their lotion, they won't consult you.
If the crabs that infest your rancid pubic hair develop a group intelligence and decide to replace all of XF86's linked-list functions with wrapper calls to GLIB2, people will mostly feel sorry for the crabs for having had to grow up in such a bad neighborhood, and applaud their initiative.
And last but not least: if a group of people who actually produce working code instead of spending their time posting gibberish flames in broken english to slashdot decide to do anything whatsoever, nobody is going to give a rat's ass whether you think it should be "allowed" or not.
There are two morals to this story, child:
1. Don't complain about code that nobody is forcing you to use when there are plenty of alternatives available.
2. Don't try to play the dozens against strangers when your game is that weak. Come hard, or don't come at all.
Just as Linux, BSD, SCO and a few others all provide implementations of (more or less) the "UNIX" specification on i386 hardware, there are multiple implementations of the X11R6 standard on i386-based unixes.
If you don't like XFree86, the folks at XiG would be happy to sell you a copy of AccelX. MetroLink systems still offers Metro-X (which was the bomb back in the RedHat 4 days...dunno about now), and if you don't have any money to spend, you can still download, compile and use the honest-to-god MIT/XConsortium X11R6.6 server.
If you want a windowing system that's not based on X11, your options are a bit more slender, but they're there. The Fresco project (formerly "Berlin") looks promising, as does PicoGui.
"Allow?"
"Prove?"
"Allow?"
Okay, either you are an excellent troll or a complete fucking idiot. I'm betting on the latter, but let me congratulate you in advance, just in case it's the former.
You mean that unix might actually get a display engine, windowing system, UI toolkit and desktop that is completely integrated from top to bottom? Oh no, we can't have that! That's the evil, evil idea that made Microsoft and Apple all of those billions of dollars of bad, bad money! We must stay pure and true and hold fast to the same awful model that lost Sun, HP, Apollo, SGI, Stardent, Argent and Domain the workstation market! Despite all that tempts us, we will never waver in our determination to become yet another UNIX footnote!
p.s. if there is to be some kind of unified X11/Gnome thingy, it won't be called XFREE. XFree86 is a trademark of the XFree86 Project, Inc, a privately held corporation. The code is free, but the name is not.
p.p.s. Of course if such a project were released, obviously the first side effect would be that the entire XFree86 core team would spontaneously combust, every copy of the XFree86 source tree mysteriously vanish, and every computer running XFree86 automatically update itself to the new system, so I guess I can see your concern.
I do not think that any current or near (5 years) future version of Windows will be ported to MIPS, PPC, or Alpha.
Well, certainly not Alpha, since that's officially a dead architecture.
MIPS and PPC...well, probably not, but the history of the previous ports of NT to those architectures suggests that MS will be happy to update those ports the moment someone shows them the money for it. This isn't as far-fetched as it might sound: remember that they're also pitching "Embedded NT" along with WinCE, and there are a lot of PPC devices in the embedded market.
Windows Server for Itanium is a lock. It might not ever sell more copies than the Alpha and MIPS versions, but it will happen, even if HP and Intel have to underwrite the development costs themselves. They have too much riding on their investment in the ia64 platform to do anything else.
Ahem. Of the 12 CPU architectures you listed, the NT OS (3.51 and 4.0) has already been ported, boxed, shrinkwrapped and shipped to three of them (Alpha, MIPS and PowerPC), and if you think MS isn't going to ever ship an IA64 version of windows at some point, I have some prime real estate that I'd like to sell to you.
Granted that the MIPS and PPC versions of NT were effectively footnotes, but there they were.
D'oh! Sigh, obviously that was meant to say "I wouldn't want him to date her". Serves me right for posting in a frenzy.
These aren't exactly insurmountable problems. Things you could do just off the top of my head:
- reset the moderation of any comments which are post-edited.
- dock one mod point (to no lower than +1) for each post-editing.
- only allow appending; no actual editing of the original text.
- provide a link to the original version in any edits.
Well, I haven't used qmail, but Postfix is braindead simple to replace sendmail with.
/etc/aliases, .forward and provide a "sendmail" wrapper program.)
;-)
:) The djbdns mailing list is usually a good place to ask such questions, just try to document the problem thoroughly (as in: step by step what you did to install it) before posting.
Ditto qmail. (Hell, probably ditto every other nextgen MTA as well -- it's not exactly rocket science to duplicate
I haven't had much luck with DJB's other tools like the inetd replacement though or his tinydns. It works fine for awhile and then just starts hanging. It's enough to keep me using BIND 9.x. Someday I'll have to mess around with it and see what's up since I know tons of people use it so it's probably my fscked up system.
Most likely, yes.
One advantage of Postfix over qmail is that Postfix, from the outside, looks a lot more like Sendmail (which, if you're migrating, is a good thing).
/etc/aliases)
This is not necessarily true. Qmail has officially supported tools to make it look indistinguishable from sendmail for 90% of all users. (e.g. support ".forward" files and
Qmail is not Free Software
This is true. Personally I think it's idiotic to consider that to be a "moral" issue, but whatever: assess your needs and choose the appropriate tool.
Wietse Venema is a better human being (aka not a hypocrite) like djb. For those reasons, I will never use qmail, and I advise all others to not use qmail.
This is stupid.
Eric Allman is a nicer guy than Wietse and Dan put together. Hell, probably nicer than the product of Dan's congeniality to the power of Wietse's social skills. I've hung out with him at Usenix conferences, and if I lived in the same area I'd probably invite him to parties.
I still wouldn't run sendmail on a bet.
DJB is an abrasive asshole. I've called him a sociopath directly on at least one occasion. I wouldn't want to be trapped at a cocktail party with him, and if I had a daughter I wouldn't want to date her.
I still ran qmail at companies that I had actual money invested in, because the code is that good.
Cutting off your nose to spite your face is stupid when you're the person who'll get called at 3 in the morning when your box gets rooted. Pick software based on quality and utility, not personality.
(I'd call qmail and postfix to be about equally matched for quality, so it comes down to a question of features and style preference for me.)
So what is technically wrong with sendmail?
/usr/lib/sendmail for each new delivery. Copy-on-write swap systems save you some here, but this is circa-1979 engineering at its worst.
Did you fail to notice that this entire article is about yet another remote sendmail root exploit?
Other things that are wrong with sendmail:
- Horrible, horrible resource utilization issues. Fork a new copy of the whole goddamn multimegabyte
- Configuration is a bad joke. The M4 macros are a bandaid slapped on top of a sucking chest wound. The web-based configurators in the commercial sendmails are a gold star slapped on top of the bandaid. Quick: name the four different "MASQUERADE" options supported by sendmail.mc, and explain how they differ and in what situations you would use which combinations of them. Can't do it without referring to the manual? Don't feel bad, neither can I, and I used to manage sendmail for a living.
- Incredibly crappy delivery performance. The hashed queues in recent sendmails have somewhat alleviated this, but qmail, postfix and exim still trounce sendmail for remote delivery speed.
- No VERP support.
- Last I checked (circa 8.11), SSL/TLS/ASMTP was a painful joke, requiring an incredibly fragile collection of third-party libraries to even stand a chance of working, which it usually didn't. (Compare to Courier, which includes all of the above out of the box.)
- Sendmail's monolithic design makes _any_ extensions into a bleeding nightmare. Compare to qmail or postfix, where if you don't like one component (the smtp daemon, the delivery agent, etc etc) it's a snap to swap it with one of your own.
- Bugs, bugs, bugs, bugs, bugs, bugs, bugs.
And that's just off the top of my head. Google for "sendmail problems" and see for yourself.
smail has an equally bad security reputation as sendmail, and is essentially abandonware to boot.
If you have fond memories of smail, use Exim instead; it's sorta-kinda descended from smail, and is still under active maintenence.
Have you ever try to run 2 instances of qmail on
one machine for exampe?
I believe I speak for the entire oxygen-breathing population of the planet earth when I say "huh?"
First of all, there's actually nothing stopping you from doing this: just compile and install qmail twice, with a different value in "conf-home" each time. Et viola, two distinct qmail installs on the same machine. Then just create a tcpserver instance for each qmail-smtpd, bound to the proper interface.
But second, this is almost certainly the wrong way to solve whatever problem it is you think you're having. Read qmail's documentation for the smtproutes control file: dollars to doughnuts says the functionality you need is in there.
Qmail is anything but rigid, and making it jump through hoops backwards and forwards is usually just a matter of reading the f-ing manual.
What are you trying to do here anyway?
"sendmail -d0.1" will give you a dump of a bunch of basic information about your sendmail install, including the version numbers and which external libraries it was linked against.
(You'll have to hit ^c to exit back to the shell; invoking sendmail with -d causes it to wait for a message on stdin to process.)
Of course, what I meant there was "sendmail to qmail migration checklist". Gee, it's a good thing that with all of the millions of dollars of venture funding that VA-Linux has burned through and thousands of man-months of development time that Malda etc have put into slashcode, they didn't do anything kooky or weird like say giving you the ability to edit your posts, like any circa-1987 Commodore 64 BBS program.
You want to replace your entire MTA, one of the most notoriously difficult-to-imlement pieces of software on any internet-connected host, and you want it to work perfectly, but you don't even want to spend a day on the task?
Rotsa ruck, man.
The closest I can offer to this: download qmail, along with fastforward and dot-forward.
Install qmail by following the directions in the "INSTALL" documents exactly, then read djb's qmail to sendmail migration checklist and follow it's instructions exactly.
Assuming you haven't done anything really gonzo with your sendmail config, you should have a working system in a few hours. Then go read Life with Qmail so that you'll actually have an idea of what you've just inflicted on yourself.
It's far more powerful than QMail
Excuse me, but what the hell are you talking about? Would you care to support this statement in some fashion?
Moderators, shame on you for giving points to this unsupported drivel.
Unbiased readers: compare and contrast for yourself. Qmail and Postfix are basically feature-equivilant, have roughly comperable performance, and both have stellar security histories. Both have plenty of 3rd-party tools to automate stuff like virtual domains, catch-all users and the like; both integrate nicely into a number of webmail and pop/imap servers.
Deciding between the two is largely a matter of taste: qmail's many small config files versus postfix's few large ones; different methods of handling aliases; etc etc etc.
You would then be promptly sued into oblivion.
That is not how copyright works. Full stop. You don't get to "assume" that you are allowed to distribute a copyrighted work just because the author has not told you you can't. Precisely the opposite: it is illegal to do until the copyright holder tells you that you can.
Okay, first-off, a statement of sympathy: djb has gone out of his way to make it difficult to install some of his software in standard places, and yours is a good example of the kind of headaches that result from his intransigence on this issue.
That said, there are much easier ways to do what you're trying to do here, and I suspect that this would have become immediately apparent if you'd taken a bit more time to read through the documentation, play with the tools, and understand what you're working with.
The big fact that you need to keep in mind here is that the collection of tools that usually gets referred to as "djbdns" is actually (assuming you more or less follow the instructions) three seperate software packages:
- djbdns 1.05
- ucspi-tcp 0.88
- deamontools 0.76
djbdns is a collection of client and server tools for getting and sending dns information. ucspi-tcp is a collection of tools for making generic TCP clients and servers (sorta like inetd or netcat), and daemontools is a collection of tools for managing persistant programs and their logs. It's entirely possible to run them without each other, but you have to be aware of what each package provides and be willing to roll the functionality yourself.A few suggestions:
That all said, I find daemontools (modulo the current slashpackage nonsense) to be a very handy utility, and have been slowly converting over most of my long-running daemons to work under it. "Try it, you'll like it."
Small hint: turn off logging. By default, tinydns and dnscache emit multiple log lines per query, turning your logging disk into a bottleneck. Pipe stdout and stderr from the tinydns process into /dev/null for an order of magnitude (or more) performance increase.