wget and robots.txt

Well, the webmasters are trying to ward off robots... meanwhile robots are getting smarter and smarter. A natural competition, it seems.

Here's what you do to bypass the "robot police":

So what if you don't want wget to obey by the robots.txt file? You can simply add -e robots=off to the command like this:

wget -r -p -e robots=off http://www.example.com

Using wget To Download Entire Websites
courtesy Jam's Ubuntu Linux Blog.

Solaris the tree killer no more

In one of my earlier posts I complained about being unable to turn off the banner page for print jobs sent from a Solaris print client to a printer controlled by a Linux print server. Soon thereafter we found a solution which I have been forgetting to talk about in this space... But, as they say, better late than never.

The solution is basically to tell the server (Linux) machine to forget that banner page. The way to do that is as follows.

1) Make sure you have cups-lpd installed. Solaris seems to only speak lpd, I am not sure how one could enable it to interface to a cups server directly.

2) On our CentOS machine we had to use the following syntax in /etc/xinetd.d/cups:

service printer
{
socket_type = stream
protocol = tcp
wait = no
user = lp
group = sys
passenv =
server = /usr/lib/cups/daemon/cups-lpd
server_args = -o document-format=application/octet-stream -o job-sheets=none
}

Emphasis on the "-o job-sheets=none" part.

A good yum tip

Apparently works on CentOS when you are trying to run an update/upgrade and dependency issues pop up. Don't know if it works under all circumstances - but definitely worked for both Shahbaz Javeed here and for yours truly just a few minutes ago. Like Shahbaz, I am also running CentOS 5.3 on the machine in question.

What you do is:

# yum clean all

Yes, it was this simple - at least this time!

A new mysterious strain of PDF

Just to spice up my life and possibly yours too... here's this out-of-the blue surprise.

Surprise

This looks, at the first glance, like a regular PDF file. file command on a Linux box identifies it as "PDF document, version 1.4". It opens fine in pretty much any PDF reader (Acroread, KPDF, evince, whatever). However, if you decide to print it then it becomes a whole different ballgame.

It prints very slowly when it does. From Acroread 8 it does not print at all. That was checked on both OpenSuSE Linux 10.3 and MS Windows Vista so I have reason to believe that the problem at hand is most likely OS-agnostic.

It does print using the system print (lp) on OpenSuSE Linux 10.3. It prints on OpenSuSE Linux in Acroread 7, CentOS 5 Linux under Acroread 5 as well as on MacOS 10 under Preview. When converted to Postscript via pdftops it yields a humongous (100+ MB) Postscript file which is quite impressive given that the PDF file being converted is only a less-than-a-megabyte 13-page document.

If you know what this mystery PDF file is about or have encountered this mutation of PDF yourself - shout, and together we shall prevail!

Solaris the tree killer

Now how's this for a fun experience - I have got this Solaris 8 machine which for some reason finds it necessary to send a title page with every print job. It does not run its own spooler and prints via a print server instead so I am clueless as to where to look for relevant setting to turn this on. So, in the spirit of waste and insanity so characteristic of our times, the machine seems poised to turn a whole forest to waste in no time as it sends quite a few print jobs.

The only configuration it seems to have is contained in the /etc/printers.conf file which looks roughly like the following:

#
# If you hand edit this file, comments and structure may change.
# The preferred method of modifying this file is through the use of
# lpset(1M)
#
caslon:\
:bsdaddr=kiev,caslon:

garamond:\
:bsdaddr=kiev,garamond,Solaris:

bodoni:\
:bsdaddr=kiev,bodoni:\
:job-sheets-default=none

_default:\
:use=gutenberg:

gutenberg:\
:bsdaddr=nrims-fs,gutenberg:

Now exactly where to tell it to knock off that title page nonsense is anybody's guess... But if you know feel free to tell me in the comments and I will be eternally grateful!

Yes, it does look like ReiserFS may at times be losing data

A little while ago we had an experience that made me suspect that ReiserFS may be "forgetful" - in other words, that files under it might at times go missing. Based on a few peoples' experiences that I have recently read about it appears that my suspicions may have been not entirely without merit.

So the practical advice to be derived from this appears to be the following: unless there is a compelling reason to use ReiserFS use ext3 instead.

Extra! Extra! Expert Help Wanted!

Yes, this is for real! If you are an expert in SuSE Linux there is a potential part-time consulting opportunity for you in Cambridge, MA. And at a unique Harvard-affiliated lab at that!

Basically, we are pretty technically-savvy as it is but sometimes we hit things in SuSE which we just don't know how to deal with. And SuSE (or OpenSuSE, to be precise) being our platforom of choice, it is important that we deal with issues we discover. And that is where your expertise will come in. So in short I would guess we are looking for someone who not only is well-versed in Linux/UNIX, networking and IT in general but also has some serious experience specifically with SuSE Linux under their belt.

This will be consulting on an as-needed basis. We will do our best not to bore you with trivial problems!

So if you think this is something you are interested in please respond in the comments section or e-mail me directly.