Feedback and Hints, December 2002.
If you have a question regarding any of the articles in this journal, or some comments please send them in. If there are any general questions about Unix or Database Administration, I will attempt to answer them.
Feedback for this month:
Hints for this month:
Linux Consultants Ham.
Just recently, I received some e-mail that was decidedly spammy. I still don't know whether I should file it under spam or info. I'll reserve judgement on that for the meantime. Here is the e-mail:
From email@example.com Wed Dec 18 06:51:51 2002 Return-Path: <firstname.lastname@example.org> Received: from hosting.commandprompt.com ([22.214.171.124]) by xxxxxx.xxxx.xxx.xx (8.11.6/8.11.6) with ESMTP id gBHJpns42386 for <email@example.com>; Wed, 18 Dec 2002 06:51:50 +1100 (EST) (envelope-from firstname.lastname@example.org) Received: (from pr@localhost) by hosting.commandprompt.com (8.11.6/8.11.6) id gBHJT4v01939 for email@example.com; Tue, 17 Dec 2002 11:29:04 -0800 Date: Tue, 17 Dec 2002 11:29:04 -0800 From: "Command Prompt PR." <firstname.lastname@example.org> Message-Id: <200212171929.gBHJT4v01939@hosting.commandprompt.com> X-Authentication-Warning: hosting.commandprompt.com: Processed from queue /var/spool/mqueue/ Subject: Consultants Guide Update (Last for the Year) To: undisclosed-recipients:; Hello All, As usual, we are sending out a brief update on the Consultants Guide. In case you haven't noticed we released a new version a couple of weeks ago so you may want to take a look. Also, the survey people are back, and have asked me to forward this the message below along. We would really appreciate it, if you folks would fill out the survey. We get 5.00 for everyone of you that completes the survey, which helps us support the Consultants Guide quite a bit. Thanks for all your support in the past and we hope you are having a great season. Sincerely, Joshua Drake Dear Linux Developer: On behalf of The Linux Review and SurveySite, a third-party independent marketing research firm, we would like to invite you to take a few moments to participate in an online Web survey regarding Linux communities. The survey should take less than 5 minutes to complete. If you complete the survey, we would be pleased to send you a copy of the results when the study is done. Simply enter your e-mail address at the end of the survey to receive a copy of the results. Please note that your answers to this survey will remain private and confidential and you will not be contacted further. If you would like to participate in this important survey, please click on the following link: http://www2.survey-poll.com/email/2166mty.html If your Web browser does not support automatic linking, please type the URL above into the address bar of your browser. Thank you for your input. Your opinion counts! Sincerely, The Linux Review Please direct questions about completing this survey to: email@example.com <mailto:firstname.lastname@example.org>
Ok, strictly speaking, it's not spam ... the return address appears genuine, and provided there is no annoying follow-ups, it could be classified as impolite UCE. But it sails rather close to the edge. Let's just call it ham rather than spam. At first, I thought it might be some rather over-enthusiastic entrepreneur who'd suffered from sudden lapse in cognitive functions, or even a severe bout of temporary insanity, and decided it was a good day to spam some linux consultants. I was inclined to ignore it. Nevertheless, just out of curiosity, I checked the URL http://www2.survey-poll.com/email/2166mty.html. It wouldn't work with w3m. Which didn't surprise me, but the URL seemed suspicious (they used an IIS server for a Survey on Linux ?!). I noticed that the IP address for hosting.commandprompt.com is actually 126.96.36.199 rather than the IP address that is stated in the header (188.8.131.52). Furthermore it was difficult to find contact information for anyone who would actually take responsibility for 184.108.40.206. This raised my spam antennae. By checking on domains, I discovered the following:
Server Name: NS.ACHIEVEMENTRESOURCES.NET IP Address: 220.127.116.11 Registrar: ENOM, INC. Whois Server: whois.enom.com Referral URL: http://www.enom.comThe home page for this URL is http://www.achievementresources.net. It seems to be some sort of financing operation for companies that are having problems with debt. And it seems a bit dodgey. But at least they included name and address information on the site. They are the Achievement Resources Group of 2861 Paseo Zorro, in San Juan Capo, California. The MX record for achievementresources.net lists the host mail.achievementresources.net (18.104.22.168). Interestingly enough, when I check the URL http://22.214.171.124, I get a completely different page. Information about this page is as follows:
Title Debt Solution Centers of America Current URL http://126.96.36.199/ Document Type text/html Last Modified Wed, 11 Dec 2002 18:44:30 GMT Number of lines 42 Transferred bytes 21044 Server: Apache/1.3.23 (Unix) (Red-Hat/Linux) mod_ssl/2.8.7 OpenSSL/0.9.6b DAV/1.0.3 PHP/4.1.2 mod_perl/1.26 mod_jk
The page on this URL seems to be (surprise, surprise) a debt consolidation scheme. The DNS entry is www.debtsolutioncenters.com. The MX record for this domain is (you guessed it) 188.8.131.52. However in the case of www.debtsolutioncenters.com, there is no address or company information on the website -- just a phone number. Why are they so coy about their identity? Both websites have forms asking users to supply personal information. And there are some ingenous reassurances to the effect that this information will not be misused. And I would be all that more ready to believe them, if they supplied a bit of information about themselves. This might be similar to the recent case in Western Australia, where an IT firm claimed to have two arms. And one of those arms wasn't exactly squeeky clean (see last month's edition). In this particular case we may have a similar situation. If this host (184.108.40.206), has two arms (maybe it has many arms), then possibly one of these arms is fiddling around under the table. Could it be achievementresources.net is the (nice) corporate version and debtsolutioncenters.com is the (not so nice) homeowners' version? As far as I can tell both schemes seem to be tailored for the very desperate (or the very foolish). They might even be distant cousins of the Mortgage Bros. Information for debtsolutioncenters.com is:
Domain Name: DEBTSOLUTIONCENTERS.COM Registrar: ALLDOMAINS.COM INC. Whois Server: whois.alldomains.com Referral URL: http://www.alldomains.com Name Server: NS1.SECONDARY.COM Name Server: NS1.COMMANDPROMPT.COM Updated Date: 22-nov-2002
So this seems to be the connection with commandprompt.com (who host them). The information for commandprompt.com is:
Domain Name: COMMANDPROMPT.COM Registrar: TUCOWS, INC. Whois Server: whois.opensrs.net Referral URL: http://www.opensrs.org Name Server: UDNS1.ULTRADNS.NET Name Server: UDNS2.ULTRADNS.NET Name Server: NS1.COMMANDPROMPT.COM Updated Date: 10-dec-2002Which includes the following Administrative contact info:
Drake, Joshua Custom Programming / Linux Managed Services Technical Writing / Application Design 3439 NE Sandy Blvd #127 Portland, OR 97232Which was one of the few real addresses I found in the whole convoluted tin of worms. So Joshua Drake is a real name, and according to the registery, he can be contacted at linuxports.com, which seems above board (after all the e-mail purports to be from The Linux Review). Still, if he was indeed the author of the e-mail, he is keeping some strange company! If he was acting on behalf of The Linux Review, why not send it from their domain? I thought it worth my while to contact him and ask about it. I sent an e-mail, but then realised that I may have blocked his reply (I had added the two IP addresses, mentioned previously, to my blacklist). So I unblocked it and tried again.
Field blocked by Outpost?
On the 19-Nov-2002 at 19:17 (Australian Eastern Summer Time) I was visited by someone who was using a browser that had the following agent string:
Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)As far as I know, this is a version of MS Internet Explorer version 5.5. The interesting thing is that this particular version had been modified by some protection software called Outpost Personal Firewall. One of the protection features that this software offers is removal of the Referer URL. The Referer URL is a feature of many browsers today, and is almost universal. Now it strikes me that this is a singularly unhelpful feature. First of all it is not really doing much in the way of protection, but more important was that the Referer URL contained the URL of the company that provides Outpost Personal Firewall.
Let's think that through ... If Fred Nurk (of Nurk Pty. Ltd.) has found an article on my site, and he thinks Hey this article is not too bad! (to which I would say, thanks Fred) and so he creates a link to it. Then when one of Fred's readers clicks on the link, I might become aware of the fact that Fred has linked to me. (From the logfile -- everyone reads the logfiles -- right?). I will see that the referer is in the nurk.com domain and so I could check Fred's site and maybe even create a link back to his site, if I like what I see.
Obviously I couldn't do this if Fred's URL has been hijacked by the people who make Outpost Personal Firewall!. In this case Fred will get no credit for directing traffic to my site. I am not going to tell you what the Outpost URL is ... they are already trying to generate publicity by over-writing the referer URL, and I won't assist them. I will just wish them very little success in the venture! Quite frankly, I think that anyone who uses such software should take a long hard look at what other protection it offers.
As far as security goes, I admit that omission of the Referer URL makes it difficult to construct an audit trial of which sites a particular web-user has visited. The question is: Who wants to hide this information anyway? Very few honest citizens would want to conceal which site they previously visited. Criminals and crackers, on the other hand, would find it very useful (Although I can't imagine any serious cracker using MSIE 5.5 as a vehicle).
Whichever way I look at it, I can't see a convincing argument for not disclosing where you came from. And even if it was important, I can see no rationale for substituting someone else's URL (It would be more secure to put the the standard empty value). Besides, if you were really concerned about security, MSIE 5.5 would be the second application program to get rid of. (The first would be MS Outlook, which is with out doubt the biggest threat to computer security that the world has ever seen).
Date: 16-Nov-2002 From: Asheu Agent: MSIE 6.0, Windows 2000 Cloning An Oracle Database on Windows NT/2000 By Gerry Patterson correction: must replace REUSE to SET on the first line of ctrl<NEW_SID> file: CREATE CONTROLFILE SET DATABAS... otherwise, you\'ll get ORA-01161 error. A very good article.Thanks for the feedback Asheu. Actually if you followed that instructions slavishly, you won't get the error. That's because you will have renamed the old control file to the new-name. I agree that such action is a bit pointless, since the renamed file would not be any use. However, the reason for this algorithm was a process that could be fully automated. The backup script was originally intended to create a cold backup of an Oracle Database. I modified it to fit in with the current procedure and created a script which automates the cloning process. This is intended to run on a regular basis. If it does then there will always be an existing control file, in which case you must add the REUSE option.
What is the postgres equivalent of the Oracle nvl() function?
The postgres function is called coalesce(). All you postgres gurus knew that of course. And it is in the postgres documentation. Nevertheless, Oracle DBAs will be a bit puzzled that the name should be the same as an oracle command that coalesces fragmented free extents in a tablespace. The format of the postgres coalesce function is:
coalesce(var1,var2,var3 ... default);The variables can repeat as often as you like. So the following command:
coalesce(var1,var2);returns var1 if var1 is not NULL, otherwise it returns var2 if that variable is not NULL. Similarly, the following:
coalesce(var1,var2,'(null)');returns var1 if var1 is not NULL, otherwise it returns var2 if var2 is not NULL and failing that (i.e. both var1 and var2 are null) it will return the string '(null)'.