kasia in a nutshell

Most of the things I normally compile for unix involves "configure, make, make install" with the occasional sprinkling of "make test" for good measure. That's pretty typical. Then there are the more complex packages that actually require reading instructions before you can compile them, sure.. reading is good for you. But why, in the name of all that is holy, would you include installation instructions in an html document for something that needs to be compiled on a command line? Especially when it's *just text*. I don't care about pretty gifs and paragraph formatting! I just want to compile and install!

Damnit.

Posted by kasia at 10:51 AM | Permalink | Comments (7)

I have four invitations left, so for those who want them just post your name and use a real email address (I don't display them).

(Btw, brilliant marketing scheme for gmail, Google.. )

Posted by kasia at 04:14 PM | Permalink | Comments (34)

Next time you reboot your remote server in a datacenter accross the country remember things like a months-ago-scheduled fsck (for that next reboot) before you panic over how long it takes the server to come back online.

Posted by kasia at 08:55 PM | Permalink | Comments (8) | TrackBacks (1)

1. Add it to services
   

   In /etc/services:
   svnserve 3690/tcp # Subversion svnserve
   svnserve 3690/udp # Subversion svnserve

2. Create the xinetd configuration file for svnserve
   

   In /etx/xinetd.d/svnserve:
   

   # default: on
   # Subversion server
   
   service svnserve
   {
           socket_type     = stream
           protocol        = tcp
           user            = svnadmin
           wait            = no
           disable         = no
           server          = /usr/local/bin/svnserve
           server_args     = -i
           port            = 3690
   }

   Of course, adjust the above for port, file location, user, etc.

3. Restart xinetd service
   

   kill -SIGUSR2 `cat /var/run/xinetd.pid`

4. Verify svnserve is listening
   

   # netstat -anp | grep LISTEN | grep 3690
   tcp 0 0 0.0.0.0:3690 0.0.0.0:* LISTEN 3303/xinetd

   
   
   - or -
   
   

   # telnet localhost 3690
   Trying 127.0.0.1...
   Connected to localhost.
   Escape character is '^]'.
   ( success ( 1 2 ( ANONYMOUS ) ( edit-pipeline ) ) )
   

Posted by kasia at 02:45 PM | Permalink | Comments (3)

Providing a webservice free of charge is work intensive and it costs money. We all know that, but users sometimes forget that behind every website there's a frustrated administrator, a large bandwidth bill and tired hardware. Running a busy, public website requires either money to hire a competent administrator or security and systems knowledge - otherwise it'll be hacked before you can say "google ads".

Why do this at all then? People do it for various reason.. exposure, name recognition, often just the satisfaction of providing a service that others find effective and desirable - even if only because it's free (as in beer).

So now that we covered it's grueling, thankless work, let's cover the other side. Responsibility.

As soon as you have at least one regular user that depends on your service, you are no longer the only person affected by the site. Yes, you still own it, yes, it's still yours and yours alone to do with what you please, but now you have an ethical obligation to the users. Most community websites survive based on content supplied by users. That makes users a vital part of the website, after all, who would visit an empty site? Face it, an Internet site without traffic is like a postman without mail. Sad, lonely and largely useless.

Things happen, sometimes unexpectedly, that may require you to stop providing the free service to your users. We all understand that free to us does not mean someone else isn't paying for it and that sometime maybe that person will no longer wish to do so. That's fine and dandy, Here are a few ethical and pain-free (well, relatively) ways to discontinue the free service with as little discomfort to the users as possible. After all, just because they took advantage of a free service it does not mean they don't deserve a notice and a chance to find a replacement.

• An announcement ahead of time stating the service will be discontinued is vital. We all know things happen, but nobody wakes up at 7am and decides to pull the plug on a busy site before their first cup of coffee. There's a period of time before a decision is reached. The users deserve to know the service is going away - this is particularly important if the website contains content they may wish to retain.
• Offer to transfer the ownership of the website to someone who has the resources to continue the free service. This would, of course, have to be done with a long list of terms to prevent a bad guy, or worse, a large corporation taking over the site just for the user base.
• Ask the users for help before things become dire. This one may even help you keep the site afloat after all! It's amazing how many technically competent people are willing to work for free just to keep their favorite site going. Many users of free services are very willing to donate money to prevent discontinuation as well. Taking advantage of a free service does not make anyone a free-loader.
• If all else fails - offer the contents of the site to volunteers to be hosted on mirror servers. Not next month, not even in two weeks but the day the power light goes off on the server.

The worst thing you could possibly do is just turn the site off without a warning. Not because of bad press, but because the users depended on it.

Posted by kasia at 08:44 PM | Permalink | Comments (7) | TrackBacks (4)

A nasty cold full of sinus pressure, achy throat, runny nose, icky cough and back pain in the middle of June. Fever, I forgot about fever too.

Posted by kasia at 07:20 PM | Permalink | Comments (7)

Our mail server at dslreports sustained a pretty impressive dictionary attack last night. Over 100K messages from an ISP in Spain. These guys are not amatuers, so of course, first step is checking of blacklists & such, after all, we filter against them - it helps to stop quantities of the spam. The ISP is indeed blacklisted on several IP blocks.. but not the one that attacked us. Which is interesting considering a google search produces an impressive list of spam reports directed at them. Obviously they got a new IP block and are already putting it to use to host a professional spam operation (well, at least one).

Spammers are taking over the web, clogging networks with worthless traffic, flooding servers and inboxes. Why are organizations like RIPE assigning new IP blocks to ISPs that are already heavily blacklisted for hosting spam operations? Wouldn't it be in their best interest to keep these guys confined to their existing assignment? Sometimes I wonder about these organizations.

RIPE (Réseaux IP Européens) is a collaborative forum open to all parties interested in wide area IP networks. The objective of RIPE is to ensure the administrative and technical coordination necessary to enable the operation of the Internet within the RIPE region.

We're facing an IP shortage, but apparently it's not an issue for spammers to get new IPs assigned. These 'collaborative organizations' are not exactly working for the benefit of the Internet.. maybe I'm just naive in thinking that is what their goal should be.

I'm not holding my breath waiting to hear back from the various abuse departments I reported this to.

Posted by kasia at 01:52 PM | Permalink | Comments (7)

I've written about referer spam before and sadly things haven't changed much. My site, as do many others, still gets hit on regular basis by referer spam bots in their never-ending quest to increase google ranking. Unfortunately, bandwidth is cheap and they don't appear to care that hitting my site is not going to help them - google does not index my statistics pages, so appearing there doesn't help anyone get a better pagerank.

I use mod_rewrite and what is now a forest of rules to deny them http access.
Worst offenders by far:

RewriteCond %{HTTP_REFERER} allinternal\.biz [OR]
RewriteCond %{HTTP_REFERER} djhits\.com [OR]
RewriteCond %{HTTP_REFERER} ass-traffic\.biz [OR]
RewriteCond %{HTTP_REFERER} drtushy\.biz [OR]
RewriteCond %{HTTP_REFERER} asstraffic\.biz
RewriteRule .* - [F,L]

Helpfully, this particular bot comes from one IP. Thanks guys, that's very thoughtful of you..

iptables -A INPUT -p tcp -s 69.31.79.2 -j REJECT

Of course, my iptables are full of these entries from flood-comment spammers already.. Most of these are proxies, but many appear to be hijacked machines on dsl and cable connections. People without firewalls suck.

212.21.228.22
adsl-68-122-118-202.dsl.pltn13.pacbell.net
233-cust-102.venturenet.net
82-41-114-38.cable.ubr05.dund.blueyonder.co.uk
195.38.93.230
mail.tsp-diffusion.com
160.80.2.236
200.222.12.98
c414-2.impsat.com.co
81.192.204.166
208.60.60.3
24-117-149-192.cpe.cableone.net
80.58.33.172.proxycache.rima-tde.net
sys53.3fn.net
i-195-137-51-66.freedom2surf.net
200.223.11.155
pi15.krosno.sdi.tpnet.pl
mikrotik-noc-eth0.antelecom.net
210.95.104.2
206-10.istrength.net
208.32.128.15
210.8.211.138
host83-54.pool81113.interbusiness.it
alfaproxy.pai.net.pl
mail2.westsiderc.org
216.94.87.66
ddsl-216-68-163-214.fuse.net
eul0600086-pip.eu.verio.net
alfaproxy.pai.net.pl
srv.vibehosting.com

Posted by kasia at 10:13 AM | Permalink | Comments (0)

I'm researching switching our source control tool from the feature-rich and appropriately expensive Rational ClearCase to the open source and apparently quite nice and stable now, Subversion.

It appears that conversion scripts from CVS to Subversion are a dime a dozen, however I've been having a hard time finding any information on converting from ClearCase to Subversion.. I suppose it wouldn't be particularly hard to make a script to convert all our history.. but I'm more interested in finding out about pitfalls and things to watch out for from people who have done this before.

Anyone have any info?

Posted by kasia at 10:48 AM | Permalink | Comments (7) | TrackBacks (1)

That's a bad title, it really should be "stupid cron mistakes" or "when idiots set up cron jobs, tonight on Fox!" or maybe "I'm Polish, but really, I'm not blonde".

Last week I set up a cron job to email our VP of engineering with some information on the first of every month. I've done cron jobs hundreds, nah, thousands of times, how hard can this be? It wasn't.. really.. piece of cake..

* * 1 * * mail important_boss_person@tickets.com

No problem.. that is, until this morning as I get an email requesting the damn flood of emails stop. Thank god the first wasn't on a weekend..

--- Added later ---

I've been asked by the less-cron-literate to explain what in the world is funny about this. It's like this, see.. in the cron world, there are 5 basic ways to describe when a job should fire off.. They live on one line, in the form of numbers, separated by a space.

Let's pretend these things below are numbers not the friendly, descriptive words they realy are.

Minute Hour Day-of-Month Month Day-of-Week

That's the most simplistic view, there are some very complicated and confusing ways of using all this, but for the purposes of illustrating my blonded-ness (is that a word?) this will suffice. For a wildcard (at any possible-value for this column) you'd use, of course an asterisk (*). So say, if I want something to run on the 1st of every month, at a quarter after 3, i would do something like...

15 3 1 * * Run-little-cron-run

As opposed, to say, if I wanted something to run every minute of every hour on the first of the month.. then i would use, eh, you see it above.

Posted by kasia at 07:45 PM | Permalink | Comments (4) | TrackBacks (1)

No, this isn't the old one, it's a brand spanking new one. Mine's upgraded.. spent all of five minutes on it too. Phew, life is rough.

Side benefit of using open source software, all those nice script kiddies and hacker-wannabes work hard and long hours to discover security issues for us. Thanks guys, warm fuzzies.

[via David]

Posted by kasia at 07:41 PM | Permalink | Comments (1) | TrackBacks (1)