The Substantially Similar Weblog

A couple of annoyances that have appeared with recent upgrades—any suggestions? A quick scan of debian-user archives suggest others have similar problems but I haven’t seen a clear solution:

• udev no longer creates CD-ROM symlinks. /proc/sys/dev/cdrom/info and /etc/udev/scripts/cdsymlinks.sh are in place, and everything appears to be configured properly, but it’s just not happening. Why aren’t they created under the default configuration?
• NFS drives no longer automount at boot-up. I have no idea why this is happening—they mount fine manually. Any clues?

I’ve released randomplay 0.47. randomplay is my command-line ‘itch a scratch’ music player. It is most useful for maintaining a random shuffle over many sessions—for example, I use it to make sure I don’t ever hear the same song in any three month period.

The new version announces the current track and artist using xosd, if you have it installed. See this screenshot to see the effect (see lower right hand corner).

If you’re using the ssh_login_blocker script I posted on Monday, please upgrade to the current version. I actually posted an old version by accident. The primary differences are that the current version works even when your auth.log file is rotated, and the “bad username” and “bad password” checks both reset after an arbitrary time period (by default 5 minutes). If you don’t have this “reset time” set, ten bad passwords over a week could lock you out.

Sorry for posting the wrong version before!

Anyone who has a run a GNU/Linux server on the Internet for more than a few weeks has probably noticed that they will occasionally get “hammered” by a robot attempting to make an ssh connection using common usernames and passwords. Usually these are not truly “brute force” attacks—they try 20-30 times, rather than thousands—but either way they are annoying.

These attacks are rarely successful with a properly configured system, but they can use up bandwidth and system resources, and perhaps more troublesome is that they clog your log files so it is more difficult to detect a bona fide system attack. I suspect that at least some of these random ssh login attempts are accompanied by attacks on other known vulnerabilities, with the hope that the sysadmin won’t notice the more devious attack because the stupid attack is going on at the same time.

Strangely, there is no “canonical” solution to guarding against these attacks. A few people have written up their own hack solutions, and here is mine.

It’s called ssh_login_blocker. It’s very simple—just drop it in /etc/init.d and make symlinks to the proper /etc/rc?.d directories (or just start it running from the command line). It must be run as root. You can configure it to allow a certain number of bad passwords or bad usernames before it blocks an IP address. You can also configure it to “reset” the bad username/password count after a certain amount of time has passed. Just look at the first few lines of code and adjust the settings accordingly.

If you are running it on a system to which you don’t have physical access, you should whitelist at least one IP address where you will be able to get in from in case something goes awry.

• See the code
• Download it here

There are many improvements I’d like to make. For example, it should use libfile-tail-perl rather than running a shell for tail. It should have a “temporary blacklist” feature in addition to the current “permanent blacklist” feature. It should have an auto-whitelist function such that “known good” IP addresses get marked up. It should use something other than /etc/hosts.deny to block ip addresses—for example, iptables. It doesn’t do any of these things, but it works pretty well, and it makes me happy that my log files are not currently clogged with spurious login attempts.

Oops.

Apparently, the salonify package I released a few days ago worked fine for upgrades, but not new installations.

The new version should work better. Sorry for anyone who tried it once and gave up. :)

• tarball
• Sample Gallery

Get the latest version of salonify as a tarball (v0.82, released 9/15/05). Or read the changelog.

salonify is a free software web-based image gallery system written by Adam Rosi-Kessel in perl 5.8. Here is a sample installation with a few images. The Electronic Privacy Information Center serves photos with a stripped down version for their Observing Surveillance website. I hope other people will find it useful.

salonify generates thumbnails and a slideshow based on an entire directory hierarchy of images. The slideshow takes advantage of JavaScript features, but it works perfectly well with JavaScript turned off. The viewer can also choose from three image sizes and rotate images if they are not properly oriented. The presentation is reasonably consistent across all browsers; it even renders well in w3m–img. It also permits anybody looking at the images to add or modify the captions, turning the act of viewing the photos into more of a participatory activity. In future versions, the administrator will be able to selectively allow certain people to change captions or turn off the feature entirely (right now, the administrator can turn captioning on or off for everyone as desired).

Please email me with a link if you use salonify, and let me know whether I can list your site here.

salonify is listed on freshmeat.net.

There is an old Debian package for salonify, but it needs to be redone and updated for the latest version. For now, I would suggest using the tarball.

A more complete feature list and some more information will appear here some day. For now, get the tarball above, which includes some documentation. Also check out the sample installation.

Contents (full package):

• salonify, the main script (or download it)
• make_salonify, generates thumbnails and indexes (or download it)
• config, salonify configuration file
• fix_permissions, a quick hack to make your files writable by salonify
• README, main documentation file
• USAGE, tells you how to use salonify
• RCSHOWTO, a one-minute primer on RCS for editing your files manually
• BUGS, known bugs
• TODO, future improvements (help is welcome!)
• changelog, updates to salonify
• style.css, sample stylesheet
• up.png, the “up” icon for collapsible lists
• down.png, the “down” icon for collapsible lists
• right.png, the “right” icon for collapsible lists
• index.txt, sample HTML for header

I’ve released salonify 0.80, my photo gallery script. Check out the sample installation and the changelog. Most of the improvements are on the index page: nested folders are now collapsible, and you can edit the descriptions of the folders through the web. Unfortunately, the Debian package is not quite up-to-snuff, so I would just recommend the tarball for the time being.

It seems to me there is a “free support gap” (that is, a gap in free support, not a support gap which is free), for users who are not beginners but are also not master developers—for example, myself. Just about any GNU/Linux question that arises that can be answered by a manpage or googling, I can figure out myself. But for trickier problems (for example, see my null oddity issue from yesterday), there doesn’t seem to be anywhere to go. Most of the helpful subscribers on debian-user are not much more knowledgeable than I am. I run my own linux-disciples list where I can answer most questions but seldom is there anyone to help out with my own questions. Similarly, there is a perl-beginners list, but no “perl-intermediate” or “perl-advanced” list. I’ve also not had much luck writing directly to developers with questions, outside of Debian.

Just a couple cases in point:

• Using File::Find to follow symlinks — posted to perl beginners, but no response:
  
  

  I’d like to use File::Find, or some alternative, to follow symlinks; regardless of whether the file/directory has already been traversed in some other location. In other words, if there I have directories x and y, and the file a is in x and symlinked into y, I want the find &wanted function to be called on file a in both x and y.

  Possible? Do I have to write my own find function from scratch? None of the follow-find=> options seem to accomplish what I want.

  I’ve also noticed that the &wanted function is not called even *once* in some cases where there are duplicate symlink files (i.e., it is not even called on the “real” file). Switching from find to finddepth seems to fix this, but I really don’t understand what’s going on. Any pointers?

  Update: after discussing off-line with a helpful blog reader, I’ve isolated the problem to the following directory structure:

   .: y/ ./y: 1/ 3/ a.jpg ./y/1: a.jpg -> (...full path...)/y/a.jpg ./y/3: 1 -> ../1 

  In other words, a.jpg is in y/. There are two symlinks to that file, one directly — y/1/a.jpg ; the other indirectly, since y/3 contains a symlink to y/1. Perl’s find function only traverses the second instance, not the first. I would like it to do both.

• growisofs problems — write fails frequently — there doesn’t seem to be any canonical mailing list or support for growisofs, so users are directed to Debian’s cdwrite list:
  
  

  I’m using growisofs from dvd+rw-tools 5.21.4.10.8-1 from Debian Sarge on an IBM Thinkpad X40 with a DVD writer that reports itself as: “MATSHITADVD-RAM UJ-812.”

  Sometimes I will try 10 or 15 times in a row to burn a DVD and it fails each time with something like:

  :-[ WRITE@LBA=1c970h failed with SK=4h/ASC=03h/ACQ=00h]: Input/output error
  builtin_dd: 117104*2KB out @ average 1.0x1385KBps
  :-( write failed: Input/output error
  /dev/dvd: flushing cache
  /dev/dvd: updating RMA
  /dev/dvd: closing disc
  :-[ CLOSE DISC failed with SK=5h/ASC=72h/ACQ=04h]: Input/output error
  /dev/dvd: reloading tray

  In this example, I had forced the write speed to 1 (it defaults to 2) to see if it makes any difference—it didn’t.

  I would suspect bad media, except that it seems to consistently fail in exactly the same place for a given DVD image to burn. For example, this one keeps failing at 6.13% done. Another failed repeatedly at 47.47%.

  Any ideas what’s going on? Troubleshooting tips? I hate to throw away so many DVDs.

Thus, I throw myself on the mercy of my readers, in particular the Planet Debian crowd. I’ve actually had more luck in the past posting questions to my blog and letting people come to me, rather than seeking out an appropriate forum to ask the question. There seems to something backwards about that.

Inexplicable oddity of the day: X was hanging after log in. It looked like it got stuck on xrdb.

Inexplicable solution: /dev/null was not readable. (Not only do I not know why /dev/null being unreadable caused the problem, I also don’t know why /dev/null lost its world-readable bit).

There’s a first time for everything, I guess, and this is the first time /dev/null has been the crucial point in fixing my system.

I’m not sure I’d ever be able to explain how to diagnose and fix problems like this to newbies.

I’m sure I’m not the first one to have this complaint, but I really wish there was a list somewhere of the Best (x) that Just Works under GNU/Linux, where (x) is a device or card. Right now, I just want a good analog video capture card (for editing and converting VHS home videos to DVD). I keep coming across webpages that say, “I’ve gotten this to work under kernel 2.2…”

I’d just like for every hardware buying experience to not be a four or five hour expedition. Just tell me what I want, and I’ll find just choose the lowest price from pricewatch and call it a day.

And, hey, while I’m complaining: does anyone have any idea why tcextract locks up vim for several seconds at a time even when run at nice 19?

Update: I should clarify if anyone actually wants to answer my video capture question that it is for a laptop, so it either needs to be a USB2, Firewire, or PCMCIA device.