One might be inclined to think that they are one and the same, pretty much. Well, not quite.
We had this problem whereby the SSH worked fine but SFTP not at all. See the following desription:
SFTP seems to fail for NIS accounts under OpenSSH 5.x
Well, it ended up being a little different. What most of those NIS-based accounts had in common was a particular customisation in their BASH startup scripts (.bashrc, etc.) One .bashrc was removed the SFTP started working again.
Moral of the story? Whenever anything that could have to do with the login procedure goes wrong it might make sense to just maximally simplify the login procedure - such as remove all customisations, for instance - and try again.
Saturday, April 30, 2011
Sunday, April 24, 2011
SANE: fixing an annoying network scan problem
On our network we've got a couple of Canon PIXMA network printer/scanner/FAX devices. Some versions of SANE apparently get confused trying to scan them with "network discovery" activated. The xsane application simply crashes.
After some searching on the web I have discovered what appears to be the fix. At least the fix has worked on a variety of Ubuntu 10.x machines, both 32-bit and 64-bit. I haven's saved the sources I used and can't locate them again so whoever was my inspiration on this one - please accept my apologies for failing to credit you.
So, be it as it may, here's the fix. Got to /etc/sane.d and edit the following file: epson2.conf . Comment out the following line:
net autodiscovery
You are done.
Final notice: after yet another round of updates on a 64-bit Ubuntu 10.10 machine I noticed that even this fix is not necessary it seems. But on slightly different installations this tip may still be of use.
After some searching on the web I have discovered what appears to be the fix. At least the fix has worked on a variety of Ubuntu 10.x machines, both 32-bit and 64-bit. I haven's saved the sources I used and can't locate them again so whoever was my inspiration on this one - please accept my apologies for failing to credit you.
So, be it as it may, here's the fix. Got to /etc/sane.d and edit the following file: epson2.conf . Comment out the following line:
net autodiscovery
You are done.
Final notice: after yet another round of updates on a 64-bit Ubuntu 10.10 machine I noticed that even this fix is not necessary it seems. But on slightly different installations this tip may still be of use.
Thursday, November 19, 2009
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":
Using wget To Download Entire Websites
courtesy Jam's Ubuntu Linux Blog.
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.
Thursday, October 8, 2009
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.
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!
What you do is:
# yum clean all
Yes, it was this simple - at least this time!
Thursday, August 7, 2008
A new mysterious strain of PDF
Just to spice up my life and possibly yours too... here's this out-of-the blue 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!
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!
Monday, June 30, 2008
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:
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!
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!
Labels:
lpd,
networking,
printing,
Solaris,
system administration,
UNIX
Subscribe to:
Posts (Atom)