Incoming FTP directory config

I guess this task is quite usual, however, I've never done this before, and had to do some googling to make it work as I wanted.

Requirements:

• user public should be able to create new files and subdirs under /home/joe/incoming/
• only joe and nobody else should be able to read the contents of, rename and delete from /home/joe/incoming

After some finetuning, the addition to proftpd.conf is the following:

<Directory /home/joe/incoming>
 Umask   002     002
  <Limit STOR CWD MKD XMKD>
   AllowAll
  </Limit>
  <Limit READ RMD XRMD DELE SITE_CHMOD RNFR RNTO>
   AllowUser joe
   DenyAll
  </Limit>
</Directory>

Also, user joe is in the same group as user public.

Quite a boring post, I admit, but I want to save some time next time I have to do it.

screen for dummies ...

... like me. screen is an oldschool, yet very useful package to handle multilple jobs. This post will not list all of its functions - which can be find almost everywhere - just serves as a virtual post-it note for myself with the for the most basic features.

1. Start a program in the background with screen:

   screen -dmS sessionname prgname

   - this will start prgname in a background screen named sessionname.
2. See what's going on in a background screen:

   screen -r sessionname

   - this will put you on the screen of the session named sessionname.
3. Put the foreground screen back to the background: CTRL+A and then D (for detach).

How to backup all your incoming and outgoing mails?

It's so simple I'm wondering why I haven't thought of it before. GMail. Set up a new account, like yournamebackup@gmail.com. Add it to the automatic bcc: setting of your favourite email client(s). Set up an autoforward (keep mails on server) on your email host. (I go for the least work, so I just made a .forward file like this in my home directory:

myusername
mynamebackup@gmail.com

- so just a copy of my mails are forwarded to gmail.)

Voilá, you have 2 GBytes (and growing) backup of all your incoming and outgoing emails. Neat.

All kinds of file uploads to MediaWiki

I'm using a MediaWiki install to work on the always-changing documentation of a current project. The default install doesn't allow file uploads at all. Here's what I had to do:

First, chmod a+w images in the wiki root directory. Now users can upload all kinds of files that are not blacklisted in MediaWiki. Unfortunately we need to store .doc Word documents too in the wiki, so I needed another step. After some googling I've found the info in an archive of the wikitech-list:

# If this is turned off, 
# users may override the warning for files not
# covered by $wgFileExtensions.
$wgStrictFileExtensions = true;

These lines are from the DefaultSettings.php file, but you're not advised to make changes there. Instead, just copy them to LocalSettings.php, and set the variable to false.

After this, uploads of any file format are immediately available to every user of the wiki. Since I'm controlling access at the Apache level, that's exactly what I wanted.

Moving a site

I wake up in the morning, 8AM, very early for me, and what do I see? The site's DNS I expected to change during the night displays another user's site. This is crazy, the new server is supposed to host the site well, I've tested that yesterday night, so what's wrong? After a coffe and two cigarettes, I've found it:

• The DNS got changed during the night as I expected, just TTL was quite high, and my laptop had the old address cached
• But not the old server
• And add to the chaos that apache got restarted on the old server too
• Which meant that if somebody requested the site from the old server got another page, because the server didn't think he's supposed to serve pages for this domain
• Which is exactly what happened to me
• (And to a few other visitors too, unfortuantely)

Quick'n'dirty solution: I've lied to the old server that he's still in charge of this domain name by adding a line to /etc/hosts... After an apache restart, all's fine now, regardless of how fresh or how old your DNS record is. Now off to have a breakfast.

Understanding Linux memory issues

Just found a nice support page at a hosting company on troubleshouting memory usage. Blognote to self: finetune apache and mysql configs!

Rescue / burn-in boot cds

A friend of mine is having a new laptop today (the bastard) and I advised him to "burn-in" the beast before installing anything on it. And of course I didn't remember the name of the tool I use for this, so after some googleing I assembled this list, so next time I can just look it up here. (If I remember that I've posted it. Whatever.)

• The Ultimate BootCD - all kinds of burn-in tests for RAM, CPU, HDD, etc.
• KNOPPIX Linux LiveCD - there are thousands of different Linux LiveCDs out there now, but this I actually used before, and found out with great pleasure that it reads NTFS and burns CDs. Probably the others do too.
• UBCD for Windows - Sideproject of The Ultimate BootCD, with a live windows (you'll need your install to build the cd) running from the cd itself. Sounds promising, but fortunately I never needed it yet.

Spambot = DOS

This is getting serious. Yesterday night a spammer put 245 comments in less than 2 minutes to some MovableType blogs I host. The result: the server got overloaded in no time and the kernel started a great massacre in there. After the smoke cleared up crond, named and munin-node were killed - for the whole night, I just restarted them. It's really pissing me off, an automated process can bring down a server in 2 minutes, I'll have to do something about this. Ideas:

• upgrade to MT3, check how it's done there
• disable comments for old posts (is it possible in MT2.6?)
• hack comments.cgi not to allow more than 1 comment / 1 minute / 1 IP
• replace MTBlackList with a better protection tool

That's all I can think of. Together with the previous trouble with MT2.6 I think it might be time to upgrade.

Strange debian-mysql-apache-mod_perl problem

This got me. I was adding a new script to an already working mod_perl site, and when I found it working on my Windows box, I "released" it to the live Linux server.

It didn't work. Without getting into too much details, I could summarize what caused the problem:

use DBI;
print "Content-type: text/html\n\n OK!";
print eval{ 
 DBI->connect("DBI:mysql:database=dbname",'user','pass', 
 { RaiseError => 1, PrintError => 1, AutoCommit => 1 }) 
};

The above script nicely connects through the command line, but when loaded into the browser, it returns 0 bytes and closes the connection. If I comment out the connection line(s), the whole thing works OK from mod_perl too.

The site's error log gets the following messages:

free(): invalid pointer 0x917cb90!

Strange. Add to the frustration that the other parts of the site use the database connection without a problem.

No happy end: I moved the new function under CGI, there it works.

Sometimes I really wish I was a baker or something.

Resizable textarea

Just a reminder for myself, next time I'll need a textarea being able to contain lots of info, I should make it resizable. Or maybe just allow the user to edit the contents of the page.

Backslashes in php regular expressions

Damn this was frustrating! Trying to match a \ character in php? Don't expect the usual Perl behavior, finding \\ - it won't work. You have to search for \\\ ! And the solution was only found in a source code with google:

  function deslash($content) {
    // Note: \\\ inside a regex denotes a single backslash.

    // Replace one or more backslashes followed by a single
    // quote with a single quote.
    $content = preg_replace("/\\\+'/", "'", $content);

    // Replace one or more backslashes followed by a double
    // quote with a double quote.
    $content = preg_replace('/\\\+"/', '"', $content);

    // Replace one or more backslashes with one backslash.
    $content = preg_replace("/\\\+/", "\\", $content);

    return $content;
  }

2 hours wasted...

Backing up an ftp-only site

One of my new sites has an ftp account only, but still, I'm only sleeping well if I can back everything up. I thought a simple mirror would be enough, and when I have the files on a more controllable box, I can put them into my regular backups. That's exactly what I did:

1. Installed the mirror package with aptitude (by the way, it kicks the ass of apt-get)


2. Created the following mini package file, saved as /home/someserver_backup/someserver_mirror_package:
   

   package=someserver.com
   site=ftp.someserver.com
   local_dir=/home/someserver_backup/someserver.com/
   remote_user=someftpuser
   remote_password=someftppassword
   remote_dir=/
   passive_ftp=true
   get_patt=(^http|^cgi)



3. Tested it with mirror -n /home/someserver_backup/someserver_mirror_package (if you see filenames running on the screen, you're probably ok)


4. Added /usr/bin/mirror
   /home/someserver_backup/someserver_mirror_package to backup2l.conf's PRE_BACKUP section


5. Ran backup2l -b to see if everything's ok


6. Smiled

MovableType monthly archive problems

I just moved my MT blog to a new server, and found that the monthly archive page does some weird stuff. </MTMonthHeader> appearing in the rendered page's source was a sign that one of the plugins (MTDateHeaders to be specific) is not working. Of course, no errors during rebuilding.

I rememberd a similar issue with AWStats, where after all it turned out that one of the plugins were missing a perl module. Some googling showed that this module uses Date::Calc, and I didn't have it on the new box! Until now, at least...

But no help, this module still doesn't work. And - maybe it's just me, but - I cannot find the original plugin to download and check what else it misses. I gave up here yesterday night, today I might just update the whole MT package to 3.15, and find out how to do the MonthHeader thing differently.

Update: I've recently upgraded to the latest MovableType (3.17), with a clean install, but the problem was still there. OK, this time hardcore googling. Finally I've found a forum post where the author of the MTDateHeaders explained some install issues. One thing stroke me: he was referring an MTDateHeaders.pm file too, together with the usual pl. Sparks above head. That's going to be it!

Fortunately I still had access to the old server where everything was working ok. Did a quick'n'dirty find:

find / -name MTDateHeaders.pm

And there it was, this nasty, bad bad bad module under /usr/local/share/perl/5.8.3! Moved to the new server, and there it goes, everything works nicely.

Before I finish, let me summarize: there's a software on the server, MovableType. There's a small plugin for it, MTDateHeaders. MT has a nice extlib directory for all the modules she and the plugins might need. Added all these together, a question rises: How the hell dares this plugin touch the base perl library directory?! And if it's unavoidable (it is not), why cannot he complain if his vital module is missing?! Wonders of the world, I guess.

Restarting updated services

This script posted to the debian security list by Frans Pop seems to be very useful. It checks for services that are depending on recently updated libraries, and therefore should be restarted. Now I just have to remember to restart the whole server whenever there's a new kernel installed.

Update: I've found out that the debian-goodies package contains a script called checkrestart which does exactly the same. Well, now I know.