Bash can handle any colour the terminal it's being displayed by can. Just send the terminal escape codes, and it's all set. So if you terminal supports 3 or 6 char RGB colours, bash can do that fine.
"When I quit my job because my boss is an asshole, I called the maker of this software I know they pirated. The guy who answered the phone laughed so hard it sounded like he was going to die, then hung up. What the hell?"
Let's also not forget, as someone who works for a newspaper, that it's not easy to make money in the newspaper business at all. The whole industry seems to be feeling the pinch these days.
I think that question has been pretty well answered, but I'll give a practical example.
I depressingly frequently get an email from some twit with no decent excuse (ESL, etc) that reads like this:
i am having this problem with my email adn it doest work please help me i need ti onw... i installed cyurs but it wont let me loggin... im new to linux im using gentoo and the cbs version of cirrus hepl pls
When I get something like that and am feeling irritable or they're being unreasonable ("FIX IT NOW!" when asking for free support on a mailing list, etc), I tend to reply with the original text quoted and FIXED, like this:
[I] am having [a] problem with my email[. It] [doesn't] work[,] please help me[. I] need [it now. I] installed [Cyrus] but it won[']t let me [log in. I'm] new to linux [I']m using [G]entoo and the [CVS] version of [Cyrus, help please.]
The point here, which sadly probably goes "whoosh" over the heads of most recipients, is that email is not a license to attempt to best the next guy in the illiteracy competition, nor an excuse not to bother to fix typos. My time is important too, especially when they're not paying me for the use of it.
I only tend to do this to people who really need to be beaten with the "here's the shift key - use it" bat, among several hundred others.
There is a shift key. Use it. No! Not the caps lock key, the shift key.
The full stop key does not have to be hit three times in succesion, not should it be most of the time.
Three full stops do not equal one comma.
A message should almost always contain more than one sentence.
The enter key is important. I promise.
You have a backspace key for a reason (oh - it's the one with the left-pointing arrow near the top right). Along with the fact that your computer displays what you type, it lets you fix typographical errors. This opportunity should not be ignored. If you insist on using your computer like a broken keyboard that's not connected to anything, I'll be happy to provide you with a real one.
I know a lot of users who hate upgrades, as they'll inevitably mean slower, more bloated and often less reliable software that makes it harder, not easier, to do the things they need to do.
That's if the upgrade even works.
Many people "upgrade" only when forced kicking and screaming by external factors such as format and protocol changes or hardware failures. I don't blame them, though personally I'll often prefer to upgrade.
I'm sure that's all very nice, and there are times I like that sort of thing. For example, I'm really looking forward to improvements in OO.o forms to make it usable with rich text editing for a simple CMS.
On the other hand, when I just want A WORD PROCESSOR it seems to be nigh-impossible to find one that WORKS and KEEPS OUT OF THE DAMN WAY.
A fully customisable, programmable office suite is something I can see a use for, and I've heard great things about Word 2k3 from others in that regard, too. I do they'd make it cross-platform so we could use it on all our desktops, though, as if I have to pick between word 2k3 (nice) and OpenOffice (shit, but runs on all our systems) I'll pick OpenOffice.
I just get frustrated when what I need is a simple word processor, and I can't find one that isn't shit. Give me styles, a spelling checker, and NO HARRASSMENT and I'll be happy.
My personal opinion is that they're all EVIL and they're out to RUIN MY GODAMM LIFE.
I've used Word - various versions of, from Word 5 for Mac to Word XP. I've used OpenOffice from pre-1.0 to 1.9-m47 . I've used kword, I've used Abiword. I HATE THEM ALL.
I swear, word processors are the one type of software that appears doomed to go from bad to worse to awful.
If I had to use a word processor, it'd be Word 5. Even if I had to run it in Basilisk under a virtual MacOS 7. Failing that, prob'ly Abiword.
I absolutely loathe OO.o . It's like a clone of Word done even worse, and the 1.9 alphas literally make me want to reach out and start strangling them. Toolbars popping into existence from nowhere and moving the working frame around; autoformat that's even more overzealous than before, etc. *arrggh*. I've been trying to test it, as we use OO.o at work, but I literally haven't been able to stand it for long enough.
I have to say that Word is evil in a somewhat more competent way. Somewhat. I think the UI is a lot better than OO.o's - mostly because OO.o's UI is a crap clone of Word's, rather than because Word's is good. I do love the way that an accidental keystroke can make seriously freaky shit happen - like making the app hide all its toolbars and menus, but not in a way that can be restored by the normal full-screen key - I eventually had to run it as winword/a to recover. Love it. Right. Word makes Windows 98 with no virus scanner look fun to support.
I seriously question the concept current word processors work on. I hate the way formatting works in every single one of them - it's like you fight the program more often than it helps you. When I seriously begin thinking about using LaTeX for a quick purchase order (and I don't know LaTeX very well at all) I begin to wonder if word processors are even a good idea.
Perhaps I should try out WordPerfect. It seems that it might at least help restore sanity to the formatting task.
I'm going to unclench my teeth and go do something not involving word processors (*twitch* *twitch*) now.
The purpose of spam is to attract a response from a reader. This requires delivery and viewing. It also often requires a direct response, such as clicking on a link, though the response may simply be remembering the message if it's, say, an advertisment.
On the other hand, a spammer being paid to spam for someone else will have different goals. They will care more about deliveries, or web-bug hits, etc than real effects - because the chances are that's how their pay is calculated. For those people, I think you're at least partially right - the purpose is still to be read, but the goal and method of measuring success is deliveries or views.
It's for that reason that many ultra-high-end CRTs are unavailible in the southern hemisphere. It's just not worth makign the variant. I understand they can be converted after manufacture at some expense, however.
I work for a newspaper and we need _good_ monitors for colour correction. I'm all too familiar with this issue (and the issue of not having the money for the monitors we need anyway... *sigh*).
Or, for that matter, the wonderful 'SEARCH' command supported by good mailservers like Cyrus IMAPd. Server-side keyword-indexed searches through message bodies are all good.
Actually, I think WinXP users would have a harder time getting online and staying online and uncracked long enough to get the security updates.
I've had to rebuild XP boxes, and the only ways that seem to work is to either sit them behind something that does NAT (or a firewall if the user has one - yeah, right) or install ZoneAlarm off a CD before connecting it to the 'net.
Even on dial-up. A worm doesn't really care if you're on dialup.
One of the things that surprised me in this article was the report that the problems only started once the user got a broadband service. (a) Really, worms don't care. (b) I was unaware that win9x had any remotely exploitable security holes. Outlook and IE holes aplenty, yes, but listening, exploitable services?
Most likely the MD5sums don't match because tar is storing the access times on the files. The access time will change when tar reads the file. To work around it, use the 'noatime' mount option on the FS or pass the appropriate parameters to tar so that it doesn't record atimes or resets them after reading the file.
You make a good point there. Tape storage is far from cheap and still needs many of the same things worried about, but compared to on-line storage of large volumes of data it's a lot more affordable.
Of course, that assumes you're not accessing it particuarly often. With PATRIOT etc that may not be a safe assumption, and it may even turn out cheaper to maintain live data instead. I doubt it though - a good robotic tape storage room, indexed tapes and a well indexed library should do the job well enough.
Alas, my company is too small for that sort of thing - we need better automation and responsiveness than manual tape access, but don't really need fully online access times. Nonetheless we've gone for on-line storage as robo-tape systems etc are well out of our league. *sigh*.
Agreed - I used an NT based mail server before we migrated to Linux+Sendmail+Cyrus. It never did work right - used to lose mail in some invisible queue until it was restarted, used to make the whole machine unstable, and used to thrash nearly to death whenever we got spamflooded. *shudder*
Postfix (which is on our Internet-exposed front-end), Sendmail and Cyrus work like a dream - they just never, ever go wrong.
Still, it'd be nice to reduce the initial setup pain a bit too, would it not? One could get on with configuring things for the specific site rather than trying to make the various parts of the mail sytem talk to each other. What a thought.
[before I continue, note: it's 2:15 AM here now and I can't sleep after a _long_ day at work. So I may not be as coherent as I could be.]
The only thing even close is dcop under KDE, and that's not really implemented on most things that a server admin will be scripting.
Yes, Windows needs COM etc more than *NIX because apps are normally immmense single programs compared to the (ideal but far from universal) many small programs on *NIX, but even so there are times when you can just get "into the guts" of a server in a way you often can't do under *nix. When daemons provide good 'control' programs it helps (think apachectl, rndc) but they never seem to be as powerful or rich as what can be done with COM.
It's a bit of an odd reversal, actually. For once, I find myself cursing the designers of a UNIX app for not designing in ways to use it for things they hadn't thought of, where I can get much more control of a similar Windows server app. The opposite is almost always true. Of course, for things the *nix app designers anticipated, it's a million times quicker, easier and more reliable - I don't/like/ COM on tiny, teensy bit, and prefer to use basically anything else. It's just nice to have it there.
I'd love to see something like dcop move into the *nix server space. Yes, I know there's nothing like that under Windows either (the Mac has the closest with AppleScript). Think 'dcop $DAEMON reload_config' where the script doesn't even have to care what DAEMON is, so long as it understands 'reload_config'.
Imagine if you could write something like this:
for DAEMON in $DAEMONS; do
# Hold any more disk-related activity
# once any in-progress operations like
# mail deliveries have completed. We don't
# want to have anything like a mailbox with
# a delivered message but no updated index
# file, after all.
dcop $DAEMON pause
# Sync all buffers on open files so the
# disk snapshot is consistent at the
# application level.
dcop $DAEMON sync_all done # Now take the filesystem snapshot, the # LVM will do the actual FS->disk sync # for us lvcreate -s -n var_snap/dev/OS/var # Let the daemons resume using the disk # now that the snapshot's been taken for DAEMON in $DAEMONS ; do
dcop $DAEMON unpause
LVM snapshots are great, you see, but only cover the lower levels. LVM makes sure that the filesystem is synced, that there are no in-flight writes, etc. It doesn't ensure consistent snapshots at the application level for applications that may be half-way through a non-atomic operation, such as updating an indexed mail folder, though. This is really annoying, as you have to risk possibly inconsistent snapshots or stop and restart all your server processes. Ick. Wouldn't it be nice if there was a standard interface to ask them "please hold what you're doing with your disk storage" instead?
Another use would be getting activity stats out of apps, as this seems to be increasingly neglected these days, and it's often hard or impossibe to build things with support for SNMP or other monitoring.
I prefer the *nix scripting environment (a lot), and usually I can get more done in it. Mainly because I'm not frightened to go near it, and don't have to dedicate a week. (It's worth noting that I'm an _awful_ COM programmer, though). I can get things done with UNIX scripting much more quickly and usually more reliably, but somtimes I do wish for the real ability to get into the guts that COM provides - but on UNIX.
To start with, get rid of mailscanner. It doesn't play safe with Postfix.
Hmm. I should clarify at this point that that was only an example - I do not use mailscanner, though I several others who do.
I currently use Postfix on my internet-exposed mailhost. It does some basic checks (address in the LDAP directory, alias valid, source domain valid, and not a relay request) then forwards it to our internal Sendmail box. That machine uses mimedefang (which in turn calls out to spamassassin) and clamav-milter do do our checks and scanning. The message is then delivered to Cyrus IMAPd over LMTP where it's processed by sieve and delivered. Phew.
Our mail system works very well and wasn't _too_ excruciating to set up. Putting postfix on a front end has made things run a _lot_ smoother, too:-) . However, I do wish it was possible to do away with bits of glue like amavisd-new - IMHO the fewer components in the mail system the better, especially if there are components that only exist to make other components able to talk.
Regarding Cyrus IMAPd, I agree that getting SASL authentication going the first time is a little prickly. It's really not that complex though, and works really well. Most of the problem comes down to the traditional CMU *cough*documentation*cough*.
I'm currently using
sasl_pwcheck_method: saslauthd
and running saslauthd with -a pam, so it talks to my LDAP directory that way. I'm planning on moving to auxprop with ldap soon though, as all the users are now in LDAP.
Be aware that if you use saslauthd with "-a pam" you need to be careful what PAM modules are being used. Some leak horrifically, and will do very unpleasant things to saslauthd. The mysql module seems to be particularly bad according to folks on info-cyrus. A workaround is to run saslauthd with -n 0 to force saslauthd to fork a new process for every auth request, but this isn't desirable on busy servers.
I've been meaning to write up some docs on the Cyrus Wiki on "common SASL setup recipes" that also ccovers "WTF is SASL" and "So how does this nightmare web fit together anyway?". It's just a matter of finding the time - I've done a fair bit of docs work on that wiki already. I've done up a map of the various possible SASL authentication "paths" (which is scary, by the way) but it still needs polishing and some proper explanation to go with it. *sigh*.
I do wish it was a little simpler to just install an MTA, an IMAP/POP server, and a mail scanner/filter and have them all work sensibly in a basic configuration out of the box. That's really all the frustration is about - I'd like to be able to spend my setup time configuring it to our environment, not trying to coax the packages to talk to each other.
Agreed. The contrast between sendmail and postfix, for example, is pretty shocking - you couldn't configure them using the same files. I wouldn't mind seeing more standard file locations and default paths, though -/etc/mailname is a good example of what we could use more of. Yes, that and most other things break down for vhosting, but a somewhat less painful out-of-the-box setup wouldn't hurt.
On the other hand, one/could/ try to standardise on their interfaces to other parts of the mail system a bit more. LMTP is helping a _lot_ there, but there's a lot of room for improvement when it comes to configuring the order of the delivery chain (MTA->spam->virus->POPd/IMAPd/local_spool ). I'd also love to see the ability to have a message pass through the LMTP chain without having to be repeatedly written and flushed to disk, by the final delivery program notifying the MTA when the message has been safely delivered. Less disk thrashing would just be peachy;-)
When it comes to standard interfaces, I'm more interested in seeing a 'mail filter' interface that can be used with all MTAs without needing glue or wrappers. The requirement for messes of (usually Perl) glue to messily stick a virus scanner, spam filter, and MTA into a working unit seems... unfortunate to me. I'm excepting Sendmail here, because if you use milter everything "just works"... so long as all you need is sendmail.
Meh. It's really late over here (Western Australia), I'm tired, and I'm probably not making much sense anymore.
Yeah, I know what you mean about multiple apps. Our NT4 server now only handles file serving (well, it also runs Sybase 5.1 DB server but that's near zero load and barely counts). It runs for months and months without even being looked at. Eventually it goes a bit funny and has to be rebooted, but it usually ends up beating the Linux servers' uptimes.
On the other hand, our core Linux server runs 12 LTSP thin client users, our mail hub (inc Cyrus IMAPd for IMAP/POP), increasing amounts of our Windows and mac file services, several intranet web applications, DHCP, DNS, two databases (mostly used by said intranet web apps), and probably more that I can't remember right now. Would I like to split out some of the functionality - hell yes, downtime on that box gives the horrible cold shivers. On the other hand, it runs very reliably and reasonably fast (given it's slow disk subsystem) and hasn't tried to nosedive yet.
The fact that I have off-site disk snapshots, nightly tape backups, critical data mirrored on other machines, and a cold spare helps the sanity, too.
From experience, I know that doing that many things on NT4... well, it really doesn't work. I can't speak for newer Windows servers, as I haven't spent enough time working with them in production to really have the knowledge.
I'll admit to not having looked into cfengine in detail yet. It strikes me as overkill, for one thing. I do need to check it out, though, you're quite right.
As for the inheritance issue, I think that can ONLY be tackled with cooperation from the application. The day I can set defaults for all users in/etc/default/appname (for example) and see them inherited by all users, or set overrides in/etc/override/appname (again, for example) and see users's control of some settings locked, I'll be a very happy admin. Especially if the app has the brains to use/usr/share/config/appname for it's configuration, and read that before my/etc/default/appname settings.
Yes, I know that the user can get past overrides easily - just use LD_PRELOAD to fake out/etc/override, recompile the app, or probably just run it with --no-overrides -- that's not the point, the point is to prevent (usually accidental, unwitting, or... witless) config changes. KDE is the only thing I've seen with this ability, and I like the way it does it.
As for the LSB, I would be very, very happy to see some sort of 'libconfig' in LSB if it implemented the stuff I talked about above (and was designed to work well with configuration version managment). We're talking dancing naked in the streets here (trust me, you don't want to see that, so perhaps I should say "promising not to go dancing naked in the streets..."). A close second would be 'libfiledialogui'.
Yeah, quite a few people do it. I'd just like to see it built in to distros, preferably with something bit better suited for config management than CVS, which isn't really designed for that.
There are definitely issues. I do version quite a few of my configs using CVS, I just wish it was easier and nicer to do.
I think you're making a bit of a big jump from "availible tools" to "transparent, filesystem-based, versioning system". I think a versioning and management system designed for managing configuration, rather than concurrent software development, would do quite well enough.
I love mail servers under Linux. Honest. Really. Like cleaning a boil under my big toe.
Admittedly, I honestly do love it once it's all set up and running and the pain is gone, you can just forget it's there and it keeps on working, but the process of getting it there is... unpleasant.
Given n MTAs, o spam filters, p virus scanners, q IMAP/POP servers, and r webmail systems, how many different combinations do you think is possible - assuming (naievely and oversimplisticly) that you can only have one of each? Just going by the software I know of in each category, I'm counting hundreds of combinations - and that's with a reasonably common set of software. The worst thing is that many of those combinations require totally different ways of hooking everything together - often badly documented ways.
We really need standardised interfaces between the MTA, webmail (OK, so that's mostly there with IMAP + LDAP), IMAP/POP server, and any filters such as virus scanners and spam checkers. At least that way we'd have a massive variety of software to learn how to configure, but wouldn't have to do battle with figuring how the f**k postfix plugged into Cyrus and and mailscanner with spamassassin and clamav (daemon mode).
I don't mind (no, I like) variety, I just wish the variety would learn to read the same configuration for common options, and try to talk the same language where possible.
Scripting becomes a whole new learning experience if you're moving from *nix scripting. You can do SO much more, but ad-hoc scripting is a screaming f**ing nightmare, so it's often just easier to do it manually, or not automate that task that could maybe be automated.
Then there's handling software that doesn't like to live together on the same server.
I'm very far from deluded enough to believe that Linux is perfect, or even particularly good, and the MS systems do have some serious advantages. On the other hand, I think they have as much of a problem with overconfigurability as Linux, just in different ways. With Linux, I feel like I'm forced to do a lot of the OS engineer's job. With windows, I feel trapped as soon as I try to go outside the bounds of the pre-designed capabilities of the system.
Let's call them both broken and pick whichever is least excruciatingly broken for the task at hand.
Slashdot Mirror
I think the subject says it all - and would, if /. would let me leave the body blank. Oh well.
Remember, don't smoke in the library.
Bash can handle any colour the terminal it's being displayed by can. Just send the terminal escape codes, and it's all set. So if you terminal supports 3 or 6 char RGB colours, bash can do that fine.
"When I quit my job because my boss is an asshole, I called the maker of this software I know they pirated. The guy who answered the phone laughed so hard it sounded like he was going to die, then hung up. What the hell?"
*grin*
Let's also not forget, as someone who works for a newspaper, that it's not easy to make money in the newspaper business at all. The whole industry seems to be feeling the pinch these days.
That's really Australian - I'm pretty sure anyway. I live in Australia but grew up in New Zealand. The full traditional text would be:
;-)
"She'll be right, mate".
More New-Zealand-ish (at least in the semi-rural Northland where I grew up) is the inclination to postfix everything with "eh, kuz?"
Talking to my brother, who lives in Dunedin (South island of NZ) is an interesting and new experience every time
I depressingly frequently get an email from some twit with no decent excuse (ESL, etc) that reads like this:
When I get something like that and am feeling irritable or they're being unreasonable ("FIX IT NOW!" when asking for free support on a mailing list, etc), I tend to reply with the original text quoted and FIXED, like this:
The point here, which sadly probably goes "whoosh" over the heads of most recipients, is that email is not a license to attempt to best the next guy in the illiteracy competition, nor an excuse not to bother to fix typos. My time is important too, especially when they're not paying me for the use of it.
I only tend to do this to people who really need to be beaten with the "here's the shift key - use it" bat, among several hundred others.
There is a shift key. Use it. No! Not the caps lock key, the shift key.
The full stop key does not have to be hit three
times in succesion, not should it be most of the time.
Three full stops do not equal one comma.
A message should almost always contain more than one sentence.
The enter key is important. I promise.
You have a backspace key for a reason (oh - it's the one with the left-pointing arrow near the top right). Along with the fact that your computer displays what you type, it lets you fix typographical errors. This opportunity should not be ignored. If you insist on using your computer like a broken keyboard that's not connected to anything, I'll be happy to provide you with a real one.
Frustrated?
Just a little.
I know a lot of users who hate upgrades, as they'll inevitably mean slower, more bloated and often less reliable software that makes it harder, not easier, to do the things they need to do.
That's if the upgrade even works.
Many people "upgrade" only when forced kicking and screaming by external factors such as format and protocol changes or hardware failures. I don't blame them, though personally I'll often prefer to upgrade.
I'm sure that's all very nice, and there are times I like that sort of thing. For example, I'm really looking forward to improvements in OO.o forms to make it usable with rich text editing for a simple CMS.
On the other hand, when I just want A WORD PROCESSOR it seems to be nigh-impossible to find one that WORKS and KEEPS OUT OF THE DAMN WAY.
A fully customisable, programmable office suite is something I can see a use for, and I've heard great things about Word 2k3 from others in that regard, too. I do they'd make it cross-platform so we could use it on all our desktops, though, as if I have to pick between word 2k3 (nice) and OpenOffice (shit, but runs on all our systems) I'll pick OpenOffice.
I just get frustrated when what I need is a simple word processor, and I can't find one that isn't shit. Give me styles, a spelling checker, and NO HARRASSMENT and I'll be happy.
My personal opinion is that they're all EVIL and they're out to RUIN MY GODAMM LIFE.
/a to recover. Love it. Right. Word makes Windows 98 with no virus scanner look fun to support.
I've used Word - various versions of, from Word 5 for Mac to Word XP. I've used OpenOffice from pre-1.0 to 1.9-m47 . I've used kword, I've used Abiword. I HATE THEM ALL.
I swear, word processors are the one type of software that appears doomed to go from bad to worse to awful.
If I had to use a word processor, it'd be Word 5. Even if I had to run it in Basilisk under a virtual MacOS 7. Failing that, prob'ly Abiword.
I absolutely loathe OO.o . It's like a clone of Word done even worse, and the 1.9 alphas literally make me want to reach out and start strangling them. Toolbars popping into existence from nowhere and moving the working frame around; autoformat that's even more overzealous than before, etc. *arrggh*. I've been trying to test it, as we use OO.o at work, but I literally haven't been able to stand it for long enough.
I have to say that Word is evil in a somewhat more competent way. Somewhat. I think the UI is a lot better than OO.o's - mostly because OO.o's UI is a crap clone of Word's, rather than because Word's is good. I do love the way that an accidental keystroke can make seriously freaky shit happen - like making the app hide all its toolbars and menus, but not in a way that can be restored by the normal full-screen key - I eventually had to run it as winword
I seriously question the concept current word processors work on. I hate the way formatting works in every single one of them - it's like you fight the program more often than it helps you. When I seriously begin thinking about using LaTeX for a quick purchase order (and I don't know LaTeX very well at all) I begin to wonder if word processors are even a good idea.
Perhaps I should try out WordPerfect. It seems that it might at least help restore sanity to the formatting task.
I'm going to unclench my teeth and go do something not involving word processors (*twitch* *twitch*) now.
The purpose of spam is to attract a response from a reader. This requires delivery and viewing. It also often requires a direct response, such as clicking on a link, though the response may simply be remembering the message if it's, say, an advertisment.
On the other hand, a spammer being paid to spam for someone else will have different goals. They will care more about deliveries, or web-bug hits, etc than real effects - because the chances are that's how their pay is calculated. For those people, I think you're at least partially right - the purpose is still to be read, but the goal and method of measuring success is deliveries or views.
It's for that reason that many ultra-high-end CRTs are unavailible in the southern hemisphere. It's just not worth makign the variant. I understand they can be converted after manufacture at some expense, however.
I work for a newspaper and we need _good_ monitors for colour correction. I'm all too familiar with this issue (and the issue of not having the money for the monitors we need anyway... *sigh*).
My preferred solution:
.muttrc
$ grep imap
set spoolfile=imap://127.0.0.1/inbox
Admittedly that's at work, but still. I'm a big fan of running my own mail (especially, I suppose, since they pay me to do it anyway).
Or, for that matter, the wonderful 'SEARCH' command supported by good mailservers like Cyrus IMAPd. Server-side keyword-indexed searches through message bodies are all good.
Actually, I think WinXP users would have a harder time getting online and staying online and uncracked long enough to get the security updates.
I've had to rebuild XP boxes, and the only ways that seem to work is to either sit them behind something that does NAT (or a firewall if the user has one - yeah, right) or install ZoneAlarm off a CD before connecting it to the 'net.
Even on dial-up. A worm doesn't really care if you're on dialup.
One of the things that surprised me in this article was the report that the problems only started once the user got a broadband service. (a) Really, worms don't care. (b) I was unaware that win9x had any remotely exploitable security holes. Outlook and IE holes aplenty, yes, but listening, exploitable services?
XP, on the other hand....
Most likely the MD5sums don't match because tar is storing the access times on the files. The access time will change when tar reads the file. To work around it, use the 'noatime' mount option on the FS or pass the appropriate parameters to tar so that it doesn't record atimes or resets them after reading the file.
You make a good point there. Tape storage is far from cheap and still needs many of the same things worried about, but compared to on-line storage of large volumes of data it's a lot more affordable.
Of course, that assumes you're not accessing it particuarly often. With PATRIOT etc that may not be a safe assumption, and it may even turn out cheaper to maintain live data instead. I doubt it though - a good robotic tape storage room, indexed tapes and a well indexed library should do the job well enough.
Alas, my company is too small for that sort of thing - we need better automation and responsiveness than manual tape access, but don't really need fully online access times. Nonetheless we've gone for on-line storage as robo-tape systems etc are well out of our league. *sigh*.
Agreed - I used an NT based mail server before we migrated to Linux+Sendmail+Cyrus. It never did work right - used to lose mail in some invisible queue until it was restarted, used to make the whole machine unstable, and used to thrash nearly to death whenever we got spamflooded. *shudder*
Postfix (which is on our Internet-exposed front-end), Sendmail and Cyrus work like a dream - they just never, ever go wrong.
Still, it'd be nice to reduce the initial setup pain a bit too, would it not? One could get on with configuring things for the specific site rather than trying to make the various parts of the mail sytem talk to each other. What a thought.
[before I continue, note: it's 2:15 AM here now and I can't sleep after a _long_ day at work. So I may not be as coherent as I could be.]
The only thing even close is dcop under KDE, and that's not really implemented on most things that a server admin will be scripting.
Yes, Windows needs COM etc more than *NIX because apps are normally immmense single programs compared to the (ideal but far from universal) many small programs on *NIX, but even so there are times when you can just get "into the guts" of a server in a way you often can't do under *nix. When daemons provide good 'control' programs it helps (think apachectl, rndc) but they never seem to be as powerful or rich as what can be done with COM.
It's a bit of an odd reversal, actually. For once, I find myself cursing the designers of a UNIX app for not designing in ways to use it for things they hadn't thought of, where I can get much more control of a similar Windows server app. The opposite is almost always true. Of course, for things the *nix app designers anticipated, it's a million times quicker, easier and more reliable - I don't
I'd love to see something like dcop move into the *nix server space. Yes, I know there's nothing like that under Windows either (the Mac has the closest with AppleScript). Think 'dcop $DAEMON reload_config' where the script doesn't even have to care what DAEMON is, so long as it understands 'reload_config'.
Imagine if you could write something like this:LVM snapshots are great, you see, but only cover the lower levels. LVM makes sure that the filesystem is synced, that there are no in-flight writes, etc. It doesn't ensure consistent snapshots at the application level for applications that may be half-way through a non-atomic operation, such as updating an indexed mail folder, though. This is really annoying, as you have to risk possibly inconsistent snapshots or stop and restart all your server processes. Ick. Wouldn't it be nice if there was a standard interface to ask them "please hold what you're doing with your disk storage" instead?
Another use would be getting activity stats out of apps, as this seems to be increasingly neglected these days, and it's often hard or impossibe to build things with support for SNMP or other monitoring.
I prefer the *nix scripting environment (a lot), and usually I can get more done in it. Mainly because I'm not frightened to go near it, and don't have to dedicate a week. (It's worth noting that I'm an _awful_ COM programmer, though). I can get things done with UNIX scripting much more quickly and usually more reliably, but somtimes I do wish for the real ability to get into the guts that COM provides - but on UNIX.
Hmm. I should clarify at this point that that was only an example - I do not use mailscanner, though I several others who do.
I currently use Postfix on my internet-exposed mailhost. It does some basic checks (address in the LDAP directory, alias valid, source domain valid, and not a relay request) then forwards it to our internal Sendmail box. That machine uses mimedefang (which in turn calls out to spamassassin) and clamav-milter do do our checks and scanning. The message is then delivered to Cyrus IMAPd over LMTP where it's processed by sieve and delivered. Phew.
Our mail system works very well and wasn't _too_ excruciating to set up. Putting postfix on a front end has made things run a _lot_ smoother, too
Regarding Cyrus IMAPd, I agree that getting SASL authentication going the first time is a little prickly. It's really not that complex though, and works really well. Most of the problem comes down to the traditional CMU *cough*documentation*cough*.
I'm currently usingand running saslauthd with -a pam, so it talks to my LDAP directory that way. I'm planning on moving to auxprop with ldap soon though, as all the users are now in LDAP.
Be aware that if you use saslauthd with "-a pam" you need to be careful what PAM modules are being used. Some leak horrifically, and will do very unpleasant things to saslauthd. The mysql module seems to be particularly bad according to folks on info-cyrus. A workaround is to run saslauthd with -n 0 to force saslauthd to fork a new process for every auth request, but this isn't desirable on busy servers.
I've been meaning to write up some docs on the Cyrus Wiki on "common SASL setup recipes" that also ccovers "WTF is SASL" and "So how does this nightmare web fit together anyway?". It's just a matter of finding the time - I've done a fair bit of docs work on that wiki already. I've done up a map of the various possible SASL authentication "paths" (which is scary, by the way) but it still needs polishing and some proper explanation to go with it. *sigh*.
I do wish it was a little simpler to just install an MTA, an IMAP/POP server, and a mail scanner/filter and have them all work sensibly in a basic configuration out of the box. That's really all the frustration is about - I'd like to be able to spend my setup time configuring it to our environment, not trying to coax the packages to talk to each other.
Agreed. The contrast between sendmail and postfix, for example, is pretty shocking - you couldn't configure them using the same files. I wouldn't mind seeing more standard file locations and default paths, though - /etc/mailname is a good example of what we could use more of. Yes, that and most other things break down for vhosting, but a somewhat less painful out-of-the-box setup wouldn't hurt.
/could/ try to standardise on their interfaces to other parts of the mail system a bit more. LMTP is helping a _lot_ there, but there's a lot of room for improvement when it comes to configuring the order of the delivery chain (MTA->spam->virus->POPd/IMAPd/local_spool ). I'd also love to see the ability to have a message pass through the LMTP chain without having to be repeatedly written and flushed to disk, by the final delivery program notifying the MTA when the message has been safely delivered. Less disk thrashing would just be peachy ;-)
... unfortunate to me. I'm excepting Sendmail here, because if you use milter everything "just works" ... so long as all you need is sendmail.
On the other hand, one
When it comes to standard interfaces, I'm more interested in seeing a 'mail filter' interface that can be used with all MTAs without needing glue or wrappers. The requirement for messes of (usually Perl) glue to messily stick a virus scanner, spam filter, and MTA into a working unit seems
Meh. It's really late over here (Western Australia), I'm tired, and I'm probably not making much sense anymore.
Yeah, I know what you mean about multiple apps. Our NT4 server now only handles file serving (well, it also runs Sybase 5.1 DB server but that's near zero load and barely counts). It runs for months and months without even being looked at. Eventually it goes a bit funny and has to be rebooted, but it usually ends up beating the Linux servers' uptimes.
... well, it really doesn't work. I can't speak for newer Windows servers, as I haven't spent enough time working with them in production to really have the knowledge.
On the other hand, our core Linux server runs 12 LTSP thin client users, our mail hub (inc Cyrus IMAPd for IMAP/POP), increasing amounts of our Windows and mac file services, several intranet web applications, DHCP, DNS, two databases (mostly used by said intranet web apps), and probably more that I can't remember right now. Would I like to split out some of the functionality - hell yes, downtime on that box gives the horrible cold shivers. On the other hand, it runs very reliably and reasonably fast (given it's slow disk subsystem) and hasn't tried to nosedive yet.
The fact that I have off-site disk snapshots, nightly tape backups, critical data mirrored on other machines, and a cold spare helps the sanity, too.
From experience, I know that doing that many things on NT4
I'll admit to not having looked into cfengine in detail yet. It strikes me as overkill, for one thing. I do need to check it out, though, you're quite right.
/etc/default/appname (for example) and see them inherited by all users, or set overrides in /etc/override/appname (again, for example) and see users's control of some settings locked, I'll be a very happy admin. Especially if the app has the brains to use /usr/share/config/appname for it's configuration, and read that before my /etc/default/appname settings.
/etc/override, recompile the app, or probably just run it with --no-overrides -- that's not the point, the point is to prevent (usually accidental, unwitting, or ... witless) config changes. KDE is the only thing I've seen with this ability, and I like the way it does it.
As for the inheritance issue, I think that can ONLY be tackled with cooperation from the application. The day I can set defaults for all users in
Yes, I know that the user can get past overrides easily - just use LD_PRELOAD to fake out
As for the LSB, I would be very, very happy to see some sort of 'libconfig' in LSB if it implemented the stuff I talked about above (and was designed to work well with configuration version managment). We're talking dancing naked in the streets here (trust me, you don't want to see that, so perhaps I should say "promising not to go dancing naked in the streets..."). A close second would be 'libfiledialogui'.
Yeah, quite a few people do it. I'd just like to see it built in to distros, preferably with something bit better suited for config management than CVS, which isn't really designed for that.
There are definitely issues. I do version quite a few of my configs using CVS, I just wish it was easier and nicer to do.
I think you're making a bit of a big jump from "availible tools" to "transparent, filesystem-based, versioning system". I think a versioning and management system designed for managing configuration, rather than concurrent software development, would do quite well enough.
I love mail servers under Linux. Honest. Really. Like cleaning a boil under my big toe.
... unpleasant.
Admittedly, I honestly do love it once it's all set up and running and the pain is gone, you can just forget it's there and it keeps on working, but the process of getting it there is
Given n MTAs, o spam filters, p virus scanners, q IMAP/POP servers, and r webmail systems, how many different combinations do you think is possible - assuming (naievely and oversimplisticly) that you can only have one of each? Just going by the software I know of in each category, I'm counting hundreds of combinations - and that's with a reasonably common set of software. The worst thing is that many of those combinations require totally different ways of hooking everything together - often badly documented ways.
We really need standardised interfaces between the MTA, webmail (OK, so that's mostly there with IMAP + LDAP), IMAP/POP server, and any filters such as virus scanners and spam checkers. At least that way we'd have a massive variety of software to learn how to configure, but wouldn't have to do battle with figuring how the f**k postfix plugged into Cyrus and and mailscanner with spamassassin and clamav (daemon mode).
I don't mind (no, I like) variety, I just wish the variety would learn to read the same configuration for common options, and try to talk the same language where possible.
Scripting becomes a whole new learning experience if you're moving from *nix scripting. You can do SO much more, but ad-hoc scripting is a screaming f**ing nightmare, so it's often just easier to do it manually, or not automate that task that could maybe be automated.
Then there's handling software that doesn't like to live together on the same server.
I'm very far from deluded enough to believe that Linux is perfect, or even particularly good, and the MS systems do have some serious advantages. On the other hand, I think they have as much of a problem with overconfigurability as Linux, just in different ways. With Linux, I feel like I'm forced to do a lot of the OS engineer's job. With windows, I feel trapped as soon as I try to go outside the bounds of the pre-designed capabilities of the system.
Let's call them both broken and pick whichever is least excruciatingly broken for the task at hand.